[
  {
    "path": ".containerignore",
    "content": "# Ignore node_modules directory\nnode_modules\n\n# Ignore any log files\n*.log\n\n# Ignore Containerfile and .containerignore itself\nContainerfile\n.containerignore\n\n# Ignore git repository files\n.git\n.gitignore\n\n# Ignore temporary files\ntmp\n*.tmp\n\n# Ignore build output\ndist\nbuild\nresources\napp\n"
  },
  {
    "path": ".editorconfig",
    "content": "root = true\n\n[*]\nend_of_line = lf\ninsert_final_newline = true\n\n[Makefile]\nindent_style = tab\n\n[*.{html,js,json,md,sass,scss,yaml}]\nindent_style = space\nindent_size = 2\n"
  },
  {
    "path": ".github/workflows/build.yml",
    "content": "name: build\n\non:\n  push:\n    paths:\n      - sdkexamples/**\n    branches:\n      - main\n  pull_request:\n    paths:\n      - sdkexamples/**\n    branches:\n      - main\n\npermissions:\n  contents: read\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    strategy:\n      fail-fast: true\n    steps:\n      - name: Checkout\n        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # pin@v4.2.2\n      - name: Setup Go sdkexamples/go.mod file\n        uses: actions/setup-go@41dfa10bad2bb2ae585af6ee5bb4d7d973ad74ed # pin@5.1.0\n        with:\n          go-version-file: 'sdkexamples/go.mod'\n          check-latest: true\n      - name: Build sdkexamples\n        run: make sdkexamples\n"
  },
  {
    "path": ".github/workflows/stale.yml",
    "content": "name: \"Close stale issues and prs\"\non:\n  schedule:\n  - cron: \"0 0 * * *\"\n\njobs:\n  stale:\n    runs-on: ubuntu-latest\n    steps:\n    - uses: actions/stale@5f858e3efba33a5ca4407a664cc011ad407f2008 # v10.1.0\n      with:\n        repo-token: ${{ secrets.GITHUB_TOKEN }}\n        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.'\n        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.'\n        exempt-issue-labels: 'keep open,v4.x,in progress'\n        days-before-stale: 90\n        days-before-close: 30\n        operations-per-run: 200\n"
  },
  {
    "path": ".github/workflows/typos.yml",
    "content": "name: typos\n\non:\n  push:\n    branches:\n      - main\n  pull_request:\n    branches:\n      - main\n\npermissions:\n  contents: read\n\njobs:\n  typos:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # pin@v4.2.2\n      - name: Check for typos\n        uses: crate-ci/typos@v1.38.1\n"
  },
  {
    "path": ".github/workflows/update-community-docs.yml",
    "content": "name: Update Community Documentation\n\non:\n  schedule:\n    # Run weekly on Mondays at 3 AM UTC\n    # Adjust frequency as needed - could be nightly: '0 3 * * *'\n    - cron: '0 3 * * 1'\n  workflow_dispatch: # Allows manual triggering\n\npermissions:\n  contents: write\n  pull-requests: write\n\njobs:\n  update-community-docs:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Checkout repository\n        uses: actions/checkout@v4\n\n      - name: Setup Node.js\n        uses: actions/setup-node@v4\n        with:\n          node-version-file: '.nvmrc'\n          cache: 'yarn'\n\n      - name: Install dependencies\n        run: yarn install --frozen-lockfile\n\n      - name: Update community docs\n        run: yarn download-remote-community\n\n      - name: Create or Update Pull Request\n        uses: peter-evans/create-pull-request@v7\n        with:\n          token: ${{ secrets.GITHUB_TOKEN }}\n          commit-message: 'chore(community): update docs from upstream'\n          signoff: true\n          title: 'chore(community): update docs from helm/community'\n          body: |\n            ## 🔄 Automated Community Documentation Update\n\n            Updates community documentation from [helm/community](https://github.com/helm/community) repository.\n\n            ### What this does:\n            - Downloads latest docs from helm/community\n            - Applies transformations (frontmatter, links, etc.)\n            - Creates PR if there are changes\n\n            ### Review checklist:\n            - [ ] Verify docs render correctly with `yarn start`\n            - [ ] Check that no local files were overwritten\n\n            ---\n            *This is an automated PR. See `.github/workflows/update-community-docs.yml` for details.*\n          branch: upstream-community-changes\n          delete-branch: true\n          labels: |\n            docs\n            community\n"
  },
  {
    "path": ".gitignore",
    "content": "# Dependencies\n/node_modules\n\n# Production\n/build\n\n# Generated files\n.docusaurus\n.cache-loader\n\n# Misc\n.DS_Store\n.env.local\n.env.development.local\n.env.test.local\n.env.production.local\n\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\n\n# SDKExamples build output\nsdkexamples/sdkexamples\n\n# JetBrains IDEs (GoLand, IntelliJ, ...) config folder\n.idea\n\n# Obsidian IDE config folder\n.obsidian\n\n# Link checker artifacts\nbin/\ntmp/\n\n# Migration source files\norig/\n.claude\nCLAUDE.md\n"
  },
  {
    "path": ".markdownlint.json",
    "content": "{\n    \"default\": true,\n    \"MD013\": {\n        \"code_block_line_length\": 999,\n        \"tables\": false\n    },\n    \"MD014\": false,\n    \"MD025\": false,\n    \"MD026\": false,\n    \"MD033\": false\n}\n"
  },
  {
    "path": ".netlify/state.json",
    "content": "{\n\t\"siteId\": \"bbe72dce-fa74-4199-abb2-6bdfe2b4d08c\"\n}"
  },
  {
    "path": ".nvmrc",
    "content": "22\n"
  },
  {
    "path": ".typos.toml",
    "content": "[default]\nextend-ignore-re = [\n  # Hex color codes in SCSS/CSS\n  \"F[0-9A-F]{2,4}\",\n]\n\n[default.extend-words]\n# Company/Publisher names\nPackt = \"Packt\"\nSkippBox = \"SkippBox\"\nSkipp = \"Skipp\"\nKOMMA = \"KOMMA\"\nHashi = \"Hashi\"  # HashiCorp\n\n# Icon/variable names\nstange = \"stange\"\nmutliple = \"mutliple\"  # May be intentional in legacy code\nmultiplebgs = \"multiplebgs\"\npsuedo = \"psuedo\"  # Legacy typo in vendor code\n\n# Technical terms\nAKS = \"AKS\"  # Azure Kubernetes Service\nba = \"ba\"\nede = \"ede\"  # Git commit hash\n\n# German words in translations\nPaket = \"Paket\"  # German for \"package\"\n\n[files]\nextend-exclude = [\n  # Internationalization files (Docusaurus i18n directory)\n  \"i18n/\",\n  # Go dependencies\n  \"sdkexamples/go.mod\",\n  \"sdkexamples/go.sum\",\n  # v4 changelog (don't want to change commit messages)\n  \"docs/changelog.md\",\n  # v2 docs\n  \"versioned_docs/version-2/*\",\n  # Ignore typos on files imported from remote repos (fix upstream instead)\n  # See docusaurus.config.js customFields.communityDocs.remoteDocs[] for full list\n  \"community/art/\",\n  \"community/hips/\",\n  \"community/meeting-notes/\",\n]\n"
  },
  {
    "path": ".vscode/launch.json",
    "content": "{\n  // Use IntelliSense to learn about possible attributes.\n  // Hover to view descriptions of existing attributes.\n  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387\n  \"version\": \"0.2.0\",\n  \"configurations\": [\n    {\n      \"type\": \"chrome\",\n      \"request\": \"launch\",\n      \"name\": \"Launch Chrome against localhost\",\n      \"url\": \"http://localhost:8080\",\n      \"webRoot\": \"${workspaceFolder}\"\n    }\n  ]\n}"
  },
  {
    "path": "AGENTS.md",
    "content": "# AGENTS.md\n\nThis file provides guidance to AI coding agents working with the helm.sh website repository.\n\n## Overview\n\nThis 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.\n\n### Technology Stack\n- Docusaurus (static site generator)\n- React (component framework)\n- Node.js/Yarn (package management)\n- Netlify (hosting and deployment)\n\n## Quick Start\n\n```bash\n# Install dependencies\nyarn install\n\n# Start development server\nyarn start\n\n# Build for production\nyarn build\n\n# Serve production build locally\nyarn serve\n```\n\n## Repository Structure\n\n### Content Organization\n- `docs/` - Current version documentation (unversioned)\n- `versioned_docs/version-N/` - Versioned documentation snapshots\n- `blog/` - Blog posts and announcements\n- `i18n/{lang}/` - Internationalized content for supported languages\n- `src/` - React components and custom pages\n- `static/` - Static assets (images, files)\n\n### Configuration\n- `docusaurus.config.js` - Main Docusaurus configuration\n- `sidebars.js` - Documentation sidebar structure\n- `versions.json` - Available documentation versions\n- `netlify.toml` - Netlify deployment configuration\n\n### Languages\nSupported: English (en), German (de), Spanish (es), French (fr), Japanese (ja), Korean (ko), Portuguese (pt), Russian (ru), Ukrainian (uk), Chinese (zh)\n\n## Build and Test Commands\n\n### Development\n```bash\n# Start dev server (usually port 3000)\nyarn start\n\n# Start with specific locale\nyarn start --locale ko\n\n# Clear cache if needed\nyarn clear\n```\n\n### Production Build\n```bash\n# Build all locales\nyarn build\n\n# Build specific locale\nyarn build --locale en\n\n# Build without minification (faster for testing)\nyarn build --no-minify\n```\n\n### Quality Checks\n```bash\n# Type checking (if TypeScript is added)\nyarn typecheck\n\n# Link checking\nmake check-links-ci\n\n# Spell checking\ntypos\n```\n\n## Architectural Documentation\n\nThis 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:\n\n1. **Document architectural decisions** in `ARCHITECTURAL_DECISIONS.md` with clear reasoning\n2. **Include requirements** that drove the decision\n3. **Link to relevant Docusaurus documentation** when applicable\n4. **Keep explanations concise** but comprehensive enough for future contributors\n\nThis helps maintain consistency and guides future development decisions.\n\n### Writing Guidelines for ARCHITECTURAL_DECISIONS.md\n\nWhen updating architectural decisions:\n- **Describe current state** - Document what exists now, not proposals or ideas\n- **Keep it concise** - One paragraph per topic, link to external docs instead of repeating them\n- **Focus on the \"why\"** - Explain decisions that aren't obvious from the code\n- **Help contributors** - Write for developers who need to understand the codebase quickly\n- **Avoid duplication** - Link to Docusaurus docs rather than explaining Docusaurus features\n\nExample: Don't explain what CSS modules are, but DO explain why we chose them over other styling approaches for this specific project.\n\n## Content Management\n\n### Documentation\n\n#### Adding/Editing Docs\n1. Edit files in `docs/` for current version\n2. For versioned docs, edit in `versioned_docs/version-N/`\n3. Frontmatter format:\n```yaml\n---\ntitle: \"Page Title\"\nsidebar_label: \"Short Label\"\nsidebar_position: 1\n---\n```\n\n#### Creating New Versions\n```bash\n# Create new version snapshot\nyarn docusaurus docs:version 3.18.0\n```\nThis creates:\n- `versioned_docs/version-3.18.0/` - Snapshot of current docs\n- `versioned_sidebars/version-3.18.0-sidebars.json` - Sidebar config\n- Updates `versions.json`\n\n#### CLI Reference Documentation\nLocated in `docs/helm/` (and versioned equivalents). To update:\n1. Uninstall all helm plugins: `helm plugin uninstall`\n2. Navigate to appropriate docs directory\n3. Run: `HOME='~' helm docs --type markdown --generate-headers`\n4. Commit changes\n\n### Blog Posts\n\nCreate in `blog/` directory with naming: `YYYY-MM-DD-slug/index.md`\n\nFrontmatter format:\n```yaml\n---\ntitle: \"Post Title\"\nauthors:\n  - name: Author Name\n    url: https://author.link\ntags: [tag1, tag2]\n---\n\nPost summary appears here.\n\n<!--truncate-->\n\nFull post content here.\n```\n\nImages go in the same directory as the blog post or in `blog/assets/`.\n\n### Internationalization\n\n#### Adding Translations\n1. Extract strings: `yarn write-translations --locale ko`\n2. Translate files in `i18n/{locale}/`\n3. Content structure:\n   - `i18n/{locale}/docusaurus-plugin-content-docs/` - Docs translations\n   - `i18n/{locale}/docusaurus-plugin-content-blog/` - Blog translations\n   - `i18n/{locale}/code.json` - UI strings\n\n#### Translation Guidelines\n- Maintain consistent terminology across versions\n- Test with `yarn start --locale {locale}`\n- Ensure all navigation and UI elements are translated\n\n## Code Style and Conventions\n\n### Markdown\n- Use semantic line breaks (one sentence per line preferred for diffs)\n- Code blocks should specify language: ```yaml, ```bash, ```go\n- Use relative links for internal pages: `[text](../path/to/page.md)`\n- Images: `![alt text](./image.png)` or from static: `![alt text](/img/image.png)`\n\n### Frontmatter Standards\n- Required: `title`\n- Recommended: `sidebar_label`, `sidebar_position`, `description`\n- Blog posts: Use `authors` array, not `author` string\n\n### Component Usage\n- Use Docusaurus components when available: `<Tabs>`, `<TabItem>`, `<Admonition>`\n- Custom components in `src/components/`\n- Import at top of MDX files: `import ComponentName from '@site/src/components/ComponentName'`\n\n### File Naming\n- Docs: Use descriptive names, lowercase with hyphens: `getting-started.md`\n- Blog: Date prefix required: `YYYY-MM-DD-title/index.md`\n- Assets: Descriptive names, avoid spaces\n\n## Deployment\n\n### Netlify Configuration\n- **Build command**: `yarn install && make build`\n- **Publish directory**: `build`\n- **Node version**: Specified in `netlify.toml`\n- **Auto-deploys**: From `main` branch\n- **Preview deploys**: Automatic for PRs\n\n### Build Process\n1. Netlify clones repository\n2. Installs dependencies with yarn\n3. Runs `make build` which executes `yarn build`\n4. Deploys `build/` directory contents\n5. Runs post-build plugins (link checking, etc.)\n\n### Environment Considerations\n- Build timeout: 15 minutes\n- Memory: Standard Netlify build environment\n- Cache: `node_modules/` and `.docusaurus/` cached between builds\n\n## Contributing Guidelines\n\n### Requirements\n- **Signed commits**: All commits must include DCO sign-off (`git commit -s`)\n- **PR approval**: Requires maintainer review\n- **Testing**: Build locally before submitting PR\n\n### Workflow\n1. Fork repository and create feature branch from `main`\n2. Make changes following existing patterns\n3. Test locally: `yarn build && yarn serve`\n4. Commit with sign-off: `git commit -s -m \"description\"`\n5. Submit PR with clear description\n6. Address review feedback\n\n### Commit Messages\n- Use conventional commits format when possible\n- Be descriptive but concise\n- Reference issues: `fixes #123` or `relates to #456`\n- Sign all commits with `-s` flag\n\n### Content Approval Process\n- **Documentation**: Any maintainer can approve\n- **Blog posts**: Require core maintainer approval\n- **Configuration changes**: Require thorough review and testing\n\n## Common Tasks\n\n### Updating Helm Version References\n1. Update `docusaurus.config.js` - Search for version strings\n2. Update relevant documentation pages\n3. Consider creating new version snapshot if major release\n4. Update `versions.json` if needed\n\n### Adding New Documentation Section\n1. Create directory in `docs/`\n2. Add index page: `docs/new-section/index.md`\n3. Update `sidebars.js` to include new section\n4. Add translations to `i18n/{locale}/` directories\n\n### Fixing Broken Links\n1. Run link checker: `make check-links-ci`\n2. Review output for broken links\n3. Fix links in source files\n4. Verify in both current and versioned docs if applicable\n\n### Migration from Hugo\nIf encountering Hugo-specific syntax or structure:\n- Hugo shortcodes -> Docusaurus components or MDX\n- Hugo frontmatter -> Docusaurus frontmatter (mostly compatible)\n- Hugo content organization -> Docusaurus docs structure\n- See `HELM2-TO-DOCUSAURUS.md` and `HELM3-TO-DOCUSAURUS.md` for migration details\n\n## Security Considerations\n\n### Content Security\n- Never commit secrets or credentials\n- Be cautious with external links and embeds\n- Validate all user-contributed content\n- Use HTTPS for all external resources\n\n### Build Security\n- Dependencies audited via Dependabot\n- Use exact versions in `package.json` where security-critical\n- Review dependency updates before merging\n\n### Deployment Security\n- Netlify handles HTTPS/SSL certificates\n- No server-side code execution (static site)\n- Environment variables kept in Netlify dashboard, not in repo\n\n## Troubleshooting\n\n### Common Issues\n\n**Build fails with \"Cannot find module\"**\n- Solution: `rm -rf node_modules .docusaurus && yarn install`\n\n**Changes not reflecting in dev server**\n- Solution: `yarn clear && yarn start`\n\n**Version mismatch errors**\n- Solution: Ensure Node.js version matches `.nvmrc` or `netlify.toml`\n\n**Broken links after content move**\n- Solution: Search for old path, update all references, run link checker\n\n**Translation missing strings**\n- Solution: `yarn write-translations --locale {locale}` to regenerate\n\n### Getting Help\n- GitHub Issues: https://github.com/helm/helm-www\n- Kubernetes Slack: #helm-users and #helm-dev channels\n- Documentation: https://docusaurus.io/docs\n\n## Special Notes for AI Agents\n\n### When Making Changes\n1. Always build and test locally before considering work complete\n2. Check both English and at least one translated version if touching i18n\n3. Verify changes in both current docs and latest versioned docs if applicable\n4. Run link checker before finalizing PR\n5. Ensure all commits are properly formatted and signed\n\n### File Generation\n- CLI reference docs are auto-generated - note this in commits\n- Don't manually edit generated files without noting the generation source\n- If regenerating docs, ensure clean helm environment (no plugins)\n\n### Be Aware Of\n- This is a versioned documentation site - changes may need to apply to multiple versions\n- Blog posts are part of permanent site history - be extra careful with edits\n- Some content may be in multiple languages - coordinate changes across translations when needed\n- External links should be checked periodically as they can break over time\n"
  },
  {
    "path": "ARCHITECTURAL_DECISIONS.md",
    "content": "# Architectural Decisions - Helm Website\n\nThis 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).\n\n## Homepage Hero Height Management\n\n### Helm-Specific Requirement\n\nThe Helm homepage hero needs to fill the full viewport height minus the navbar for a clean presentation.\n\n### Solution\n\nUses a [Docusaurus client module](https://docusaurus.io/docs/advanced/client#client-modules): `src/client-modules/heroHeightCalculator.js`\n\n**Handles:** Window resize, orientation change, client-side navigation (SPA routing), and development hot reloading\n\n**Why client modules instead of static scripts:** Integrates with Docusaurus build process and avoids file serving issues in different deployment environments.\n\n## Homepage Component Organization\n\n### Helm-Specific Requirement\n\nSplit the homepage into focused components so contributors can easily find and edit specific sections.\n\n### Component Structure\n\n```\nsrc/components/\n├── HomeHeader/          # Hero section\n├── HomeAbout/           # \"What is Helm?\" section\n├── HomeFeatures/        # Feature cards\n├── HomeGettingStarted/  # Installation tabs\n└── HomeCommunity/       # Community links\n```\n\n**Shared CSS modules:** `src/css/home-*.module.css` for common patterns across components.\n\n**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.\n\n## Hero Responsive Design\n\n### Helm-Specific Requirement\n\nHero content must never be hidden behind navbar or waves, especially on mobile landscape or small windows.\n\n### Key Solutions\n\n**Extreme height constraint (< 380px):** Switches to side-by-side layout instead of stacked\n**Text scaling:** Uses CSS `clamp()` for smooth scaling while maintaining readability\n**Container bounds:** Absolute positioning keeps content above wave animations\n\n## CLI Documentation Generation Script\n\n### Helm-Specific Requirement\n\nRegenerate Helm CLI documentation for each release with consistent formatting and Docusaurus-compatible structure.\n\n### Solution\n\nUses an ESM Node.js script: `scripts/regenerate-cli-docs.mjs`\n\n**Why ESM over CommonJS:** Modern package compatibility (ora, p-limit) and consistency with future Node.js direction while maintaining parallel processing capabilities for performance.\n\n**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.\n\nSee `src/components/HomeHeader/styles.module.css` for implementation details.\n\n## React Hydration Warning Suppression\n\n### Helm-Specific Requirement\n\nThe HomeCommunity component displays event dates using locale-specific formatting, which causes unavoidable hydration mismatches between server and client rendering.\n\n### Solution\n\nFollowing [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 `<span>` elements in `src/components/HomeCommunity/index.js`.\n\n**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.\n\n**Implementation:** Added `suppressHydrationWarning` prop to both date range and single date `<span>` elements in the CustomDate component.\n\n## Boat and Wave Animation\n\n### Helm-Specific Requirement\n\nBoat must appear to float on waves across all screen sizes while using minimal space in the hero section.\n\n### Key Solutions\n\n**Scaling:** Uses `max(rem, vw)` for viewport-proportional scaling with minimum readable sizes\n**Space efficiency:** Boat can overflow above a compact wave container to maximize hero content space\n**Animation sync:** Boat bob animation coordinates with wave heights for consistent floating appearance\n\nSee `src/components/Boat/styles.module.css` for implementation.\n\n## CSS Organization\n\n### Helm-Specific Requirement\n\nHomepage styles should only load on homepage, not other pages.\n\n### Solution\n\nUses [CSS Modules](https://docusaurus.io/docs/styling-layout#css-modules) with strategic sharing:\n- `src/css/home-*.module.css` - Shared patterns (sections, cards)\n- Component `styles.module.css` - Component-specific styles\n\n**Why this approach:** Only homepage components import homepage CSS, so other pages don't load unnecessary styles.\n\n## Blog and Docs Layout Consistency\n\n### Why This Change Was Made\n\nBlog 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.\n\n### Key Files for Maintainers\n\n**Core Components (don't delete):**\n```\nsrc/theme/BlogLayout/              # Makes blog look like docs\nsrc/theme/BlogBreadcrumbs/         # \"Home → Blog → Post\" navigation\nsrc/theme/BlogListBreadcrumbs/     # \"Home → Blog\" navigation\nsrc/theme/DocBreadcrumbs/          # \"Home → Docs → Page\" navigation\nsrc/theme/TOCCollapsible/          # Mobile \"On this page\" menu\n```\n\n### Expected Navigation Patterns\n\n- **Blog listing:** Home → Blog\n- **Blog post:** Home → Blog → Post Title\n- **Docs page:** Home → Docs → Category → Page\n\n### Common Issues\n\n**Blog breadcrumbs broken?** Check `src/theme/BlogBreadcrumbs/index.js`\n\n**Mobile TOC not working?** Verify `src/theme/TOCCollapsible/` and that blog posts use proper headers (##, ###)\n\n**Missing \"Docs\" in breadcrumbs?** Check `src/theme/DocBreadcrumbs/index.js` has the \"Docs\" link\n\n**Layout looks wrong?** Don't add custom CSS - edit the React components instead\n\nSee [Docusaurus swizzling docs](https://docusaurus.io/docs/swizzling) for how these theme components work.\n\n## Markdown Links\n\nThis section provides guidance for working with markdown links in the Helm docs site.\n\n### Absolute paths required\n\nAbsolute 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).\n\nThe sections below include more information about how and when to use absolute file paths or URL paths.\n\n#### Linking within docs or blogs\n\nWhen linking from one doc page to another or from one blog post to another, use the _absolute file path_:\n   \n* Exclude `/blog/` or `/docs/` from the path\n* 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/`)\n* Include the `.md` or `.mdx` file extension\n\nExamples:\n\n```markdown\n✅ GOOD (doc to doc link): [Advanced Topics](/topics/advanced.md)\n✅ GOOD (blog to blog link): [Helm at KubeCon/CloudNativeCon SLC](/2024-10-07-kubecon-na-24/index.md)\n❌ AVOID (relative file path): [Advanced Topics](../topics/advanced.md)\n❌ AVOID (relative file path): [Advanced Topics](advanced.md)\n❌ AVOID (adding /docs): [Advanced Topics](/docs/topics/advanced.md)\n❌ AVOID (absolute URL path, no .md/.mdx): [Advanced Topics](/docs/topics/advanced)\n```\n\n#### Linking across docs and blogs\n\nWhen linking to a doc from a blog, or from a blog to a doc, use the _absolute URL path_:\n   \n* Include `/blog/` or `/docs/`\n* Exclude the `.md` or `.mdx` file extension\n* If the doc or blog has a `slug` defined in its front matter, use the slug in the URL path instead of the filename\n\nExamples:\n\n```markdown\n✅ GOOD (file name without .md extension when no slug is in front matter): [See this blog post](/blog/2024-01-01-title)\n✅ GOOD (when slug is in front matter): [See this blog post](/blog/my-slug)\n❌ AVOID (don't use the file extension):  [Advanced Topics](/docs/topics/advanced.md)\n```\n\n### Anchor links to headings\n\nAnchor 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. \n\nFor example:\n\n```markdown\nEnglish: ## Storage backends  → #storage-backends\nChinese: ## 后端存储         → #后端存储 (different anchor ID)\n```\n\nTo avoid broken anchor links, add explicit IDs to headings in all translations. For example:\n\n```markdown\n## Storage backends {#storage-backends}\n## 后端存储 {#storage-backends}\n```\n\nIn this case, anchor links to the given ID will work across all locales since the anchor ID itself remains the same in all translations.\n\n### Troubleshoot broken links\n\nYou 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:\n\n```bash\nBroken link on source page path = /docs/faq/changes_since_helm2\n   -> linking to /topics/charts.md\n```\n\nTo 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.\n\n## Netlify Redirects Strategy\n\n### Hugo to Docusaurus Migration Requirements\n\nDuring the migration from Hugo to Docusaurus, several legacy URL patterns needed to be preserved to avoid breaking existing links and integrations.\n\n### Redirect Processing Order\n\n[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**.\n\n### Go Module Import Support\n\nHugo 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`.\n\n### Docusaurus Implementation\n\nDocusaurus replicates this functionality using static HTML files in `/static/`:\n\n- `/static/helm/index.html`\n- `/static/helm/v2/index.html`\n- `/static/helm/v3/index.html`\n- `/static/helm/v4/index.html`\n- `/static/chartmuseum/index.html`\n\nEach file provides:\n1. **Go import meta tags**: `<meta name=\"go-import\" content=\"...\">` for Go module proxy\n2. **Go source meta tags**: `<meta name=\"go-source\" content=\"...\">` for source code navigation\n3. **Client-side redirect**: `<meta http-equiv=\"refresh\">` for browser users\n4. **Fallback link**: HTML body with link to GitHub repository\n\n### Go Package Import Compatibility\n\nInternal redirects handle Go module proxy requests:\n\n```toml\n[[redirects]]\n  from = \"/helm/v3/*\"\n  to = \"/helm/v3\"\n  status = 200\n\n[[redirects]]\n  from = \"/helm/v2/*\"\n  to = \"/helm/v2\"\n  status = 200\n```\n\n### Helm v2 Documentation Redirects\n\nLegacy Helm v2 documentation from `https://v2.helm.sh/docs/*` redirects to the new combined site at `/docs/2/*`. These redirects:\n\n1. **URL format changes**: Map old underscore URLs to new dash URLs (e.g., `using_helm/` → `using-helm/`)\n2. **Category-level only**: Target section landing pages (fragments not supported by Netlify)\n3. **Temporary status**: Use 302 status during migration phase for easy rollback if issues discovered\n4. **Script-managed**: Generated by `scripts/helm2-to-docusaurus.js` for consistency\n\n```toml\n# TODO: Change status codes from 302 to 301 after cutover verification\n[[redirects]]\n  from = \"https://v2.helm.sh/docs/using_helm/\"\n  to = \"/docs/2/using-helm/\"\n  status = 302\n```\n\n### Status Code Strategy\n\n- **302 (temporary)** during testing/migration phase - allows easy rollback if issues are discovered\n- **301 (permanent)** after Docusaurus site cutover is verified - provides SEO benefits and signals permanent move\n\nThis follows [Netlify's best practices](https://docs.netlify.com/routing/redirects/redirect-options/#http-status-codes) for safe migrations.\n\n## Documentation Migration Automation\n\n### Helm-Specific Requirement\n\nMigrating legacy Helm documentation (v2 from Hugo, v3 from existing content) to Docusaurus while preserving URLs and fixing broken links.\n\n### Solution\n\n**Migration Orchestrators:** `scripts/migrate-v2-docs.js` and `scripts/migrate-v3-docs.js` with corresponding `yarn migrate:v2` and `yarn migrate:v3` commands.\n\n**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.\n\n**Key Features:**\n- **Fresh start capability:** Each migration clears and rebuilds from source\n- **Menu generation:** Extracts navigation structure from live Helm v2 site\n- **Link path correction:** Shared `scripts/util/href-diffs-process.js` applies version-specific link fixes from JSON configuration files\n- **Missing file handling:** Adds helm commands not present in original navigation but available in source\n\n**Why this approach:** Enables repeatable, testable migrations while maintaining URL compatibility and fixing legacy Hugo-to-Docusaurus link issues.\n\n**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.\n\n**Detailed operational guides:**\n- [HELM2-TO-DOCUSAURUS.md](./HELM2-TO-DOCUSAURUS.md) - v2 migration procedures\n- [HELM3-TO-DOCUSAURUS.md](./HELM3-TO-DOCUSAURUS.md) - v3 migration procedures\n\n## Hugo Legacy Files Cleanup\n\n### Files to Remove Post-Migration\n\nOnce the Docusaurus migration is complete and verified, these Hugo-specific files should be removed:\n\n- **`config.toml`** - Hugo configuration file, replaced by `docusaurus.config.js`\n- **`themes/` directory** - Hugo theme files, replaced by Docusaurus theme components\n- **`content/en/code/` directory** - Hugo code metadata files, functionality replaced by Netlify redirects\n\n### Migration Strategy\n\nKeep these files during the migration phase to:\n1. Reference Hugo configuration when setting up Docusaurus equivalents\n2. Understand legacy URL patterns for redirect configuration\n3. Maintain ability to rollback if needed during testing\n\nRemove them only after:\n1. Docusaurus site cutover is verified\n2. All redirects are tested and working\n3. No rollback scenarios require Hugo functionality\n\n## Community Documentation Import\n\n### Helm-Specific Requirement\n\nThe 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.\n\n### Solution\n\nUses [docusaurus-plugin-remote-content](https://github.com/rdilweb/docusaurus-plugin-remote-content) to import and transform content at build time.\n\n**Architecture:**\n- **Multi-instance docs:** Community docs are a separate Docusaurus docs plugin instance with `id: \"community\"`, creating `/community/*` URLs\n- **Content transformation:** Custom functions in `src/utils/communityDocsTransforms.js` handle all content processing\n- **Configuration:** Centralized in `docusaurus.config.js` under `customFields.communityDocs`\n- **Files committed to Git:** Imported files are tracked in version control to maintain clean git status and avoid complex .gitignore management\n- **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))\n\n### Content Transformation Features\n\n**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.\n\n**HIP (Helm Improvement Proposal) formatting:** HIP documents get special treatment:\n- Metadata fields (hip, authors, created, status, etc.) displayed as a markdown table\n- Sidebar labels include HIP number for easy navigation (e.g., \"0023: Utilize Server Side Apply\")\n- Frontmatter cleaned to remove duplicate metadata\n\n**Plain text file handling:** `.txt` files (like meeting notes) are automatically:\n- Converted to `.md` files during import\n- Title extracted from content headers\n- Content wrapped in code blocks to preserve formatting\n\n**Link transformations:** Only applied for configured exceptions - most links work as-is since the file structure mirrors the source repository.\n\n### Why imported files are committed to Git\n\nThe `/community` directory mixes imported files from helm/community with locally-maintained community docs. Committing imported files to Git:\n\n1. **Avoids complex .gitignore patterns** - No need to maintain a parallel list of which specific files to ignore\n2. **Provides clean git status** - Contributors don't see dozens of untracked files during development\n3. **Enables offline development** - With `noRuntimeDownloads: true`, `yarn start` works without network access\n4. **Simplifies mental model** - All files in `/community` are tracked, regardless of source\n\nThe tradeoff of content duplication is acceptable since these files rarely change structure and the import notices clearly indicate they shouldn't be edited locally.\n\n### Commands\n\n- `yarn download-remote-community` - Fetch and transform latest content from helm/community repository\n- `yarn clear-remote-community` - Remove imported files (useful for testing)\n\n### Automated Updates\n\nA GitHub Action (`.github/workflows/update-community-docs.yml`) runs weekly to:\n1. Check for updates in helm/community repository\n2. Apply transformations and import changes\n3. Create or update a PR if there are changes\n4. Skip if an identical PR already exists\n\nThe workflow can also be triggered manually through GitHub Actions UI.\n\n### For Contributors\n\nTo add new community documents:\n1. Add entry to `customFields.communityDocs.remoteDocs` in `docusaurus.config.js`\n2. Include optional `meta` field for frontmatter overrides\n3. Add link exceptions only if specific links need custom mapping\n4. Run `yarn download-remote-community` to test import locally\n\nTo modify transformation logic:\n1. Edit `src/utils/communityDocsTransforms.js` for content processing\n2. Test changes with `yarn download-remote-community`\n\n## Netlify Build Caching\n\n### Problem\nDocusaurus builds take ~11 minutes. Need faster builds for development workflow.\n\n### Solution\nCustom Netlify plugins cache `.docusaurus/`, `node_modules/`, and `build/` directories.\n\n**Current:** `cache-docusaurus-dirs-file` (stable, 2-4 minute builds)\n**Future:** `cache-docusaurus-dirs-api` (beta, potentially 10x faster)\n\n### Build Pipeline Changes\nChanged from `make build` (runs destructive `clean`) to `make netlify-build` (preserves cache).\n\n### Cache Strategy\n- **Production/branches:** Isolated per branch\n- **PR previews:** Shared across PRs via `CACHE_PER_BRANCH=false`\n- **Auto-invalidation:** `yarn.lock` changes, `CACHE_VERSION` environment variable\n\nSee `netlify-plugins/README.md` for configuration details.\n"
  },
  {
    "path": "CONTRIBUTING-ko.md",
    "content": "# 기여 가이드라인\n\nhelm.sh 웹사이트 및 문서에 대한 기여 가이드입니다. 헬름의 기본 프로젝트는 [helm/helm](https://github.com/helm/helm/blob/main/CONTRIBUTING.md)으로 이동하세요.\n\n---\n\n헬름은 GitHub 풀 리퀘스트를 통해 기여를 받습니다. 이 문서는 기여하는 데 도움이 되는 프로세스를 간략히 설명합니다.\n\n## 보안 이슈 신고\n\n대부분의 경우 헬름에서 버그를 발견하면 [GitHub 이슈](https://github.com/helm/helm/issues)를\n사용하여 신고해야 합니다. 그러나 _보안 취약성_ 을 신고하는 경우\n[cncf-kubernetes-helm-security@lists.cncf.io](mailto:cncf-kubernetes-helm-security@lists.cncf.io)\n이메일로 신고해주세요. 이것은 이슈가 악용되기 전에 해결할 수 있는\n기회를 줄 것입니다.\n\n## 당신의 작업에 서명해주세요\n\n서명(sign-off)은 커밋 메시지 끝에 있는 간단한 줄입니다. 모든 커밋은 서명이\n있어야 합니다. 귀하의 서명은 패치를 작성했거나 자료를 기여할 권한이 있음을\n증명합니다. 아래 개발자 증명서([developercertificate.org](https://developercertificate.org/)에서 발췌)에\n동의하는 경우, 규칙은 매우 간단합니다.\n\n```\n원본 개발자 증명서\n버전 1.1\n\nCopyright (C) 2004, 2006 The Linux Foundation and its contributors.\n1 Letterman Drive\nSuite D4700\nSan Francisco, CA, 94129\n\n모든 사용자는 이 라이센스 문서의 사본을 복사하여\n배포할 수 있지만 변경할 수는 없습니다.\n\n원본 개발자 증명서 1.1\n\n본 프로젝트에 기여함으로써 저는 다음 사항을 보증합니다:\n\n(a) 해당 기여의 전부 또는 일부를 제가 작성했으며,\n    파일에 명시된 오픈 소스 라이센스에 따라\n    제출할 권리가 있습니다. 또는\n\n(b) 해당 기여는 제가 아는 한 적합한 오픈 소스\n    라이센스에 따라 적용되었으며, 해당 라이센스에\n    따라 (다른 라이센스로 제출할 수 있는 권한이\n    없는 경우) 파일에 표시된 것과 동일한 오픈\n    소스 라이센스로 제가 작성한 전부 또는 일부의\n    수정 작업을 제출할 권리가 있습니다.\n    또는\n\n(c) 해당 기여는 (a), (b) 또는 (c)를 인증한\n    다른 사람이 직접 제공했으며, 제가 수정하지\n    않았습니다.\n\n(d) 저는 해당 프로젝트와 기여를 공개하고 기여\n    기록(본인의 서명과 함께 제출한 모든 개인\n    정보 포함)이 무기한 유지되며 해당 프로젝트\n    또는 관련 오픈 소스 라이센스와 일치하도록\n    재배포될 수 있음을 이해하고 동의합니다.\n```\n\n모든 git 커밋 메시지에 한 줄을 추가하기만 하면 됩니다.\n\n    Signed-off-by: Joe Smith <joe.smith@example.com>\n\n실명을 사용해주세요. (죄송하지만, 가명 또는 익명의 기여는 허용되지 않습니다.)\n\n`user.name` 과 `user.email` git config를 설정하면 `git commit -s` 로\n자동으로 커밋에 서명할 수 있습니다.\n\n참고: git 설정 정보가 올바르게 지정된 경우 `git log` 를 보면\n커밋 정보가 다음과 같습니다.\n\n```\nAuthor: Joe Smith <joe.smith@example.com>\nDate:   Thu Feb 2 11:41:15 2018 -0800\n\n    Update README\n\n    Signed-off-by: Joe Smith <joe.smith@example.com>\n```\n\n`Author` 와 `Signed-off-by` 줄이 일치하는 것에 주목해주세요. 만약 일치하지\n않는다면 자동 DCO 검사에서 PR을 거부할 것입니다.\n\n## 지원 채널\n\n당신이 사용자 혹은 기여자라면 공식 지원 채널은 다음과 같습니다.\n\n- [이슈](https://github.com/helm/helm/issues)\n- 슬랙:\n  - 사용자: [#helm-users](https://kubernetes.slack.com/messages/C0NH30761/details/)\n  - 기여자: [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG/)\n\n새로운 이슈를 열거나 새로운 풀 리퀘스트를 보내기 전에 해당 프로젝트를 검색하는 것이 도움이 됩니다. 사용자가 겪은 이슈를 다른 사용자가 이미 보고했거나 저희가 이미 알고 있는 이슈일 수 있습니다. 슬랙 채널에서 물어보는 것도 도움이 될 수 있습니다.\n\n## 이슈\n\n이슈는 헬름 프로젝트와 관련된 모든 항목을 추적하는 기본 방법으로 사용됩니다.\n\n### 이슈 유형\n\n5가지 유형의 이슈가 있습니다(각 이슈마다 해당 [레이블](#labels)이 있음).\n\n- `question/support`: 향후 참조를 위해 기록하기를 원하는 지원 또는 기능 관련\n문의가 있습니다. 일반적으로 슬랙 채널에 저장하기에 너무 복잡한 또는 큰 질문이거나\n커뮤니티 전체에서 특별한 관심을 갖는 질문입니다. 논의에 따라 `feature` 또는 `bug`\n이슈로 바뀔 수 있습니다.\n- `proposal`: 대규모 커뮤니티 논의가 필요한 새로운 아이디어 또는 기능을 제안하는\n(이 글과 같은) 이슈에 사용됩니다. 이렇게 하면 기능이 실제로 개발되기 전에\n커뮤니티의 다른 사용자로부터 피드백을 받을 수 있습니다. 해당 레이블은 작은 이슈에\n필요하진 않습니다. 기능의 제안 필요 여부 결정은 핵심 관리자에게 달려 있습니다.\n모든 제안 이슈는 해당 레이블과 \"Proposal: [제목의 나머지 부분]\" 이라는 제목이\n있어야 합니다. 제안은 `feature` 가 될 수 있으며 마일스톤은 필요하지 않습니다.\n- `feature`: 이 이슈는 완료될 때까지 특정 기능 요청 및 아이디어를 추적합니다.\n`proposal` 에서 바뀔 수도 있고 이슈 사이즈에 따라 개별적으로 제출될 수 있습니다.\n- `bug`: 코드와 함께 버그를 추적하는 이슈입니다.\n- `docs`: 문서 관련 문제(예: 누락 또는 미완)를 추적합니다.\n\n### 이슈 생명 주기\n\n이슈 생명 주기는 주로 핵심 관리자에 의해 관리되지만, 헬름에 기여하는 사람들에게도 좋은 정보입니다.\n모든 유형의 이슈는 동일한 생명 주기를 따릅니다. 차이점은 아래에 설명되어 있습니다.\n\n1. 이슈 생성\n2. 분류\n    - 분류를 담당하는 관리자가 해당 이슈에 대한 적절한 레이블을 적용합니다.\n    여기에는 우선 순위, 유형, 메타데이터(예: `good first issue`)\n    레이블이 포함됩니다. 저희가 추적할 유일한 이슈 우선 순위는 이 이슈가\n    \"중요한지\" 여부입니다. 향후 추가 레이블이 필요하면 추가하겠습니다.\n    - (필요한 경우) 간결하고 명확하게 이슈를 설명하기 위해 제목을 정리하세요.\n    또한 제안의 제목은 \"Proposal: [제목의 나머지 부분]\"으로 서두를 떼야 합니다.\n    - 이슈를 올바른 마일스톤에 추가합니다. 질문 이슈일 경우, 질문에\n    답변할 때까지 이슈를 마일스톤 추가하는 것에 대해 염려하지 마세요.\n    - 저희는 작업일에 적어도 한 번 이상 이 과정을 시도합니다.\n3. 논의\n    - `feature` 또는 `bug` 로 레이블이 지정된 이슈는 이를 해결하는 PR에 연결해야 합니다.\n    - `feature` 또는 `bug` 이슈를 작업하는 사람(관리자 또는 커뮤니티의 누군가)은\n    해당 이슈를 직접 자신에게 배정하거나 해당 이슈를 처리하고 있다는 내용의 코멘트를\n    작성해야 합니다.\n    - `proposal` 및 `support/question` 이슈는 해결될 때까지 또는 30일 이상 활발하지 않은\n    경우에도 계속 열려 있어야 합니다. 이렇게 하면 이슈 대기열을 관리 가능한 크기로 유지하고 잡음을\n    줄일 수 있습니다. 이슈가 계속 열려 있어야 하는 경우 `keep open` 레이블을 추가할 수 있습니다.\n4. 이슈 종결\n\n## 패치에 기여하는 방법\n\n1. 아직 서명하지 않은 경우 기여자 라이센스 계약에 서명하세요(위 세부 정보 참조).\n2. 원하는 저장소를 포크하여 코드 변경 사항을 개발하고 테스트하세요.\n3. 풀 리퀘스트를 보내주세요.\n\n코딩 규약 및 표준은 [공식 개발자 문서](/community/developers)에 설명되어 있습니다.\n\n## 풀 리퀘스트\n\n모든 좋은 오픈 소스 프로젝트와 마찬가지로, 저희는 PR(풀 리퀘스트)을 사용하여 코드 수정을 추적합니다.\n\n### PR 생명 주기\n\n1. PR 생성\n    - PR은 일반적으로 이슈를 해결하기 위해 생성되거나 특정 이슈를 해결하는 다른 PR의 하위 집합이 됩니다.\n    - 저희는 현재 진행 중인 PR을 환영합니다. 아직 진행 중이지만 다른 사람들이 보기에\n    유용한 중요 작업을 추적할 수 있는 좋은 방법입니다. PR이 진행 중인 작업의 경우\n    **반드시** \"WIP: [제목]\"으로 제목을 시작해야 합니다. PR을 리뷰할 준비가 되면\n    제목에서 \"WIP\"를 제거합니다.\n    - 특정 이슈와 관련된 PR을 보내는 것이 바람직하지만 필수 사항은 아닙니다.\n    해당 PR이 급한 해결책이라면 이슈가 적절하지 않게 종결될 수 있는 상황이 있을\n    수 있습니다. 이 경우 PR 설명란에 세부 정보를 넣어주세요.\n2. 분류\n    - 분류를 담당하는 관리자가 해당 이슈에 대한 적절한 레이블을 적용합니다. 모든 레이블이\n    적용된 후에는 최소한 사이즈 레이블, `bug` 또는 `feature`, `awaiting review` 가 포함되어야 합니다.\n    레이블 정의에 대한 자세한 내용은 [레이블 섹션](#레이블)을 참조합니다.\n    - PR을 올바른 마일스톤에 추가합니다. 이는 PR이 닫는 이슈와 동일해야 합니다.\n3. 리뷰 배정\n    - 리뷰에 `awaiting review` 라는 레이블이 표시되면 관리자는 스케줄이 허용하는 대로 리뷰합니다.\n    이슈를 제기한 관리자는 리뷰에 대해 자체 요청(self-request)해야 합니다.\n    - `size/large` 레이블이 있는 PR은 병합하기 전에 관리자로부터 2개의 리뷰 승인이 필요합니다.\n    `size/medium` 또는 `size/small` 인 경우 관리자의 판단에 따릅니다.\n4. 리뷰/논의\n    - 모든 리뷰는 GitHub 리뷰 도구를 사용하여 완료됩니다.\n    - \"Comment(주석)\" 리뷰는 답변해야 하는 코드 관련 질문이 있을 때 사용해야 하지만 코드 변경은\n    포함되지 않습니다. 이러한 유형의 리뷰는 승인에 포함되지 않습니다.\n    - \"Changes Requested(변경 요청)\" 리뷰는 코드를 병합하기 전에 수정해야 함을 나타냅니다.\n    - 리뷰어는 필요에 따라 레이블을 갱신해야 합니다(예: `needs rebase`).\n5. 질문에 답변하거나 코드를 수정하여 의견을 반영합니다.\n6. LGTM (Looks good to me)\n    - 리뷰어가 리뷰를 완료하고 코드가 병합될 준비가 된 것으로 보이면 \"Approve(승인)\"\n    리뷰는 기여자와 다른 관리자에게 코드를 리뷰한 후 병합 준비가 완료되었음을 알리는 데\n    사용됩니다.\n7. 병합(merge) 또는 종결(close)\n    - PR은 병합될 때까지 또는 30일 이상 활발하지 않은 경우 열려 있어야 합니다. 이렇게 하면\n    PR 대기열을 관리 가능한 크기로 유지하고 잡음을 줄일 수 있습니다. PR이 계속 열려 있어야\n    하는 경우 (WIP의 경우처럼), `keep open` 레이블을 추가할 수 있습니다.\n    - PR을 병합하기 전에 PR에 한 개 이상의 LGTM이 필요한지 여부를 결정하기 위해\n    아래 [사이즈 레이블](#사이즈-레이블) 항목을 참조하세요.\n    - PR 소유자가 `OWNERS` 파일에 포함되어 있는 경우 해당 사용자는 반드시 자신의 PR을 병합하거나\n    다른 OWNER에게 명시적으로 요청해야 합니다.\n    - PR의 소유자가 `OWNERS`에 포함되어 있지 않은 경우, 모든 핵심 관리자가 PR을 병합할 수 있습니다.\n\n#### 문서 PR\n\n문서 PR은 다른 PR과 동일한 수명 주기를 따릅니다. 또한 `docs` 레이블로\n레이블이 지정됩니다. 문서의 경우 철자, 문법, 명료성에 특히 주의를 기울여야\n합니다(코드의 주석*만큼* 중요하지 않음).\n\n## 분류자 (Triager)\n\n매주 목요일 공개 스탠드업 회의를 시작으로 핵심 관리자 중 한 명이 \"분류자\"\n역할을 하게 됩니다. 이 담당자는 일주일 내내 새로운 PR 및 이슈에 대한 분류를\n담당하게 됩니다.\n\n## 레이블\n\n다음 표에서는 헬름에 사용되는 모든 레이블 유형을 정의합니다. 카테고리별로 나뉩니다.\n\n### 공통 레이블\n\n| 레이블 | 설명 |\n| ----- | ----------- |\n| `bug` | 이슈를 버그 또는 PR을 버그 수정으로 표시합니다. |\n| `critical` | 이슈 또는 PR을 중요한 것으로 표시합니다. 이것은 PR이나 이슈를 다루는 것이 최우선이며 가능한 한 빨리 해결되어야 한다는 것을 의미합니다. |\n| `docs` | 이슈 또는 PR이 문서 변경임을 나타냅니다. |\n| `feature` | 이슈를 기능 요청으로 표시하거나 PR을 기능 구현으로 표시합니다. |\n| `keep open` | 이슈 또는 PR을 30일간 사용되지 않는 상태로 열어 둬야 함을 나타냅니다. |\n| `refactor` | 이슈가 코드 개선이며 버그를 고치거나 추가 기능을 추가하지 않음을 나타냅니다. |\n\n### 이슈용 레이블\n\n| 레이블 | 설명 |\n| ----- | ----------- |\n| `help wanted` | 이슈를 해결하기 위해 커뮤니티의 도움이 필요하다고 표시합니다. |\n| `proposal` | 이슈를 제안으로 표시합니다. |\n| `question/support` | 이슈를 요청이나 질문으로 표시합니다. |\n| `good first issue` | 이슈를 헬름을 처음 접하는 사용자에게 좋은 첫 이슈로 표시합니다. |\n| `wont fix` | 이슈가 논의되었으며 구현되지 않을 것임(또는 제안의 경우 받았음)을 나타냅니다. |\n\n### PR용 레이블\n\n| 레이블 | 설명 |\n| ----- | ----------- |\n| `awaiting review` | PR이 분류되었으며 다른 사용자가 리뷰할 준비가 되었음을 나타냅니다 |\n| `breaking` | PR이 코드를 변경한다는 것을 나타냅니다 (예: API 변경) |\n| `in progress` | 아직 리뷰되지 않았어도 관리자가 PR을 보고 있음을 나타냅니다 |\n| `needs rebase` | PR이 병합되기 전 리베이스(rebase)할 필요가 있음을 나타냅니다 |\n| `needs pick` | PR이 기능 브랜치(일반적으로 버그 수정 브랜치)로 체리픽(cherry-pick)할 필요가 있음을 나타냅니다. 체리픽했다면 `picked` 레이블을 적용하고 해당 레이블을 제거해야 합니다 |\n| `picked` | 해당 PR은 기능 브랜치로 체리픽했다는 것을 나타냅니다 |\n\n#### 사이즈 레이블\n\n사이즈 레이블은 PR이 얼마나 \"위험\"한지를 나타내는 데 사용됩니다.\n아래 가이드라인은 레이블을 배정하는 데 사용되지만, 궁극적으로 관리자에 의해 변경 될\n수 있습니다. 예를 들어 PR이 한 파일에서 30 줄만 변경하더라도 주요 기능이 바뀐다면\n여러 명의 서명이 필요하므로 `size/L` 로 레이블이 지정될 가능성이 높습니다.\n반대로 작은 기능을 추가하지만 모든 경우를 다루기 위해 150 줄의 테스트가 필요한 PR은\n줄 수가 아래에 정의된 것보다 많더라도 `size/S` 로 레이블을 지정할 수 있습니다.\n\n핵심 관리자에 의해 제출되는 PR은 사이즈에 상관없이 한 명의 추가 관리자 승인만 필요로\n합니다. 이렇게 하면 코드베이스(codebase)에 도입된 중요한 PR을 알고 있는 관리자가\n두 명 이상 있게 됩니다.\n\n| 레이블 | 설명 |\n| ----- | ----------- |\n| `size/XS` | 생성된 파일은 무시하고 0~9줄을 변경하는 PR을 나타냅니다. 변경 사항에 따라 테스트가 거의 필요하지 않을 수 있습니다. |\n| `size/S` | 생성된 파일은 무시하고 10-29줄을 변경하는 PR을 나타냅니다. 소량의 수동 테스트만 필요할 수 있습니다. |\n| `size/M` | 생성된 파일은 무시하고 30-99줄을 변경하는 PR을 나타냅니다. 수동 유효성 검사가 필요합니다. |\n| `size/L` | 생성된 파일은 무시하고 100-499줄을 변경하는 PR을 나타냅니다. 이 작업은 병합하기 전에 철저히 테스트해야 하며 항상 2개의 승인이 필요합니다. |\n| `size/XL` | 생성된 파일은 무시하고 500-999 줄을 변경하는 PR을 나타냅니다. 이 작업은 병합하기 전에 철저히 테스트해야 하며 항상 2개의 승인이 필요합니다. |\n| `size/XXL` | 생성된 파일은 무시하고 1000개 이상의 행을 변경하는 PR을 나타냅니다. 이 작업은 병합하기 전에 철저히 테스트해야 하며 항상 2개의 승인이 필요합니다. |\n"
  },
  {
    "path": "CONTRIBUTING.md",
    "content": "# Contributing Guidelines\n\nThis 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.\n\n---\n\nHelm accepts contributions via GitHub pull requests. This document outlines the process to help get your contribution accepted.\n\n## Reporting a Security Issue\n\nMost of the time, when you find a bug in Helm, it should be reported\nusing [GitHub issues](https://github.com/helm/helm/issues). However, if\nyou are reporting a _security vulnerability_, please email a report to\n[cncf-kubernetes-helm-security@lists.cncf.io](mailto:cncf-kubernetes-helm-security@lists.cncf.io). This will give\nus a chance to try to fix the issue before it is exploited in the wild.\n\n## Sign Your Work\n\nThe sign-off is a simple line at the end of the explanation for a commit. All\ncommits needs to be signed. Your signature certifies that you wrote the patch or\notherwise have the right to contribute the material. The rules are pretty simple,\nif you can certify the below (from [developercertificate.org](https://developercertificate.org/)):\n\n```\nDeveloper Certificate of Origin\nVersion 1.1\n\nCopyright (C) 2004, 2006 The Linux Foundation and its contributors.\n1 Letterman Drive\nSuite D4700\nSan Francisco, CA, 94129\n\nEveryone is permitted to copy and distribute verbatim copies of this\nlicense document, but changing it is not allowed.\n\nDeveloper's Certificate of Origin 1.1\n\nBy making a contribution to this project, I certify that:\n\n(a) The contribution was created in whole or in part by me and I\n    have the right to submit it under the open source license\n    indicated in the file; or\n\n(b) The contribution is based upon previous work that, to the best\n    of my knowledge, is covered under an appropriate open source\n    license and I have the right under that license to submit that\n    work with modifications, whether created in whole or in part\n    by me, under the same open source license (unless I am\n    permitted to submit under a different license), as indicated\n    in the file; or\n\n(c) The contribution was provided directly to me by some other\n    person who certified (a), (b) or (c) and I have not modified\n    it.\n\n(d) I understand and agree that this project and the contribution\n    are public and that a record of the contribution (including all\n    personal information I submit with it, including my sign-off) is\n    maintained indefinitely and may be redistributed consistent with\n    this project or the open source license(s) involved.\n```\n\nThen you just add a line to every git commit message:\n\n    Signed-off-by: Joe Smith <joe.smith@example.com>\n\nUse your real name (sorry, no pseudonyms or anonymous contributions.)\n\nIf you set your `user.name` and `user.email` git configs, you can sign your\ncommit automatically with `git commit -s`.\n\nNote: If your git config information is set properly then viewing the\n `git log` information for your commit will look something like this:\n\n```\nAuthor: Joe Smith <joe.smith@example.com>\nDate:   Thu Feb 2 11:41:15 2018 -0800\n\n    Update README\n\n    Signed-off-by: Joe Smith <joe.smith@example.com>\n```\n\nNotice the `Author` and `Signed-off-by` lines match. If they don't\nyour PR will be rejected by the automated DCO check.\n\n## Support Channels\n\nWhether you are a user or contributor, official support channels include:\n\n- [Issues](https://github.com/helm/helm/issues)\n- Slack:\n  - User: [#helm-users](https://kubernetes.slack.com/messages/C0NH30761/details/)\n  - Contributor: [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG/)\n\nBefore 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.\n\n## Issues\n\nIssues are used as the primary method for tracking anything to do with the Helm project.\n\n### Issue Types\n\nThere are 5 types of issues (each with their own corresponding [label](#labels)):\n\n- `question/support`: These are support or functionality inquiries that we want to have a record of for\nfuture reference. Generally these are questions that are too complex or large to store in the\nSlack channel or have particular interest to the community as a whole. Depending on the discussion,\nthese can turn into `feature` or `bug` issues.\n- `proposal`: Used for items (like this one) that propose new ideas or functionality that require\na larger community discussion. This allows for feedback from others in the community before a\nfeature is actually developed. This is not needed for small additions. Final word on whether or\nnot a feature needs a proposal is up to the core maintainers. All issues that are proposals should\nboth have a label and an issue title of \"Proposal: [the rest of the title].\" A proposal can become\na `feature` and does not require a milestone.\n- `feature`: These track specific feature requests and ideas until they are complete. They can evolve\nfrom a `proposal` or can be submitted individually depending on the size.\n- `bug`: These track bugs with the code\n- `docs`: These track problems with the documentation (i.e. missing or incomplete)\n\n### Issue Lifecycle\n\nThe issue lifecycle is mainly driven by the core maintainers, but is good information for those\ncontributing to Helm. All issue types follow the same general lifecycle. Differences are noted below.\n\n1. Issue creation\n2. Triage\n    - The maintainer in charge of triaging will apply the proper labels for the issue. This\n    includes labels for priority, type, and metadata (such as `good first issue`). The only issue\n    priority we will be tracking is whether or not the issue is \"critical.\" If additional\n    levels are needed in the future, we will add them.\n    - (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure\n    that proposals are prefaced with \"Proposal: [the rest of the title]\".\n    - Add the issue to the correct milestone. If any questions come up, don't worry about\n    adding the issue to a milestone until the questions are answered.\n    - We attempt to do this process at least once per work day.\n3. Discussion\n    - issues that are labeled as `feature` or `bug` should be connected to the PR that resolves it.\n    - Whoever is working on a `feature` or `bug` issue (whether a maintainer or someone from\n    the community), should either assign the issue to themself or make a comment in the issue\n    saying that they are taking it.\n    - `proposal` and `support/question` issues should stay open until resolved or if they have not been\n    active for more than 30 days. This will help keep the issue queue to a manageable size and\n    reduce noise. Should the issue need to stay open, the `keep open` label can be added.\n4. Issue closure\n\n## How to Contribute a Patch\n\n1. If you haven't already done so, sign a Contributor License Agreement (see details above).\n2. Fork the desired repo, develop and test your code changes.\n3. Submit a pull request.\n\nCoding conventions and standards are explained in the [official developer docs](https://helm.sh/docs/developers/).\n\n## Pull Requests\n\nLike any good open source project, we use Pull Requests (PRs) to track code changes.\n\n### PR Lifecycle\n\n1. PR creation\n    - PRs are usually created to fix or else be a subset of other PRs that fix a particular issue.\n    - We more than welcome PRs that are currently in progress. They are a great way to keep track of\n    important work that is in-flight, but useful for others to see. If a PR is a work in progress,\n    it **must** be prefaced with \"WIP: [title]\". Once the PR is ready for review, remove \"WIP\" from\n    the title.\n    - It is preferred, but not required, to have a PR tied to a specific issue. There can be\n    circumstances where if it is a quick fix then an issue might be overkill. The details provided\n    in the PR description would suffice in this case.\n2. Triage\n    - The maintainer in charge of triaging will apply the proper labels for the issue. This should\n    include at least a size label, `bug` or `feature`, and `awaiting review` once all labels are applied.\n    See the [Labels section](#labels) for full details on the definitions of labels.\n    - Add the PR to the correct milestone. This should be the same as the issue the PR closes.\n3. Assigning reviews\n    - Once a review has the `awaiting review` label, maintainers will review them as schedule permits.\n    The maintainer who takes the issue should self-request a review.\n    - Any PR with the `size/large` label requires 2 review approvals from maintainers before it can be\n    merged. Those with `size/medium` or `size/small` are per the judgement of the maintainers.\n4. Reviewing/Discussion\n    - All reviews will be completed using GitHub review tool.\n    - A \"Comment\" review should be used when there are questions about the code that should be\n    answered, but that don't involve code changes. This type of review does not count as approval.\n    - A \"Changes Requested\" review indicates that changes to the code need to be made before they will be merged.\n    - Reviewers should update labels as needed (such as `needs rebase`)\n5. Address comments by answering questions or changing code\n6. LGTM (Looks good to me)\n    - Once a Reviewer has completed a review and the code looks ready to merge, an \"Approve\" review is used\n    to signal to the contributor and to other maintainers that you have reviewed the code and feel that it is\n    ready to be merged.\n7. Merge or close\n    - PRs should stay open until merged or if they have not been active for more than 30 days.\n    This will help keep the PR queue to a manageable size and reduce noise. Should the PR need\n    to stay open (like in the case of a WIP), the `keep open` label can be added.\n    - Before merging a PR, refer to the topic on [Size Labels](#size-labels) below to determine if\n      the PR requires more than one LGTM to merge.\n    - If the owner of the PR is listed in the `OWNERS` file, that user **must** merge their own PRs\n    or explicitly request another OWNER do that for them.\n    - If the owner of a PR is _not_ listed in `OWNERS`, any core maintainer may merge the PR.\n\n#### Documentation PRs\n\nDocumentation PRs will follow the same lifecycle as other PRs. They will also be labeled with the\n`docs` label. For documentation, special attention will be paid to spelling, grammar, and clarity\n(whereas those things don't matter *as* much for comments in code).\nFor additional style guidelines, see [Documentation Style Guide](style-guide.md).\n\n## The Triager\n\nEach week, one of the core maintainers will serve as the designated \"triager\" starting after the\npublic stand-up meetings on Thursday. This person will be in charge triaging new PRs and issues\nthroughout the work week.\n\n## Labels\n\nThe following tables define all label types used for Helm. It is split up by category.\n\n### Common\n\n| Label | Description |\n| ----- | ----------- |\n| `bug` | Marks an issue as a bug or a PR as a bugfix |\n| `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 |\n| `docs` | Indicates the issue or PR is a documentation change |\n| `feature` | Marks the issue as a feature request or a PR as a feature implementation |\n| `keep open` | Denotes that the issue or PR should be kept open past 30 days of inactivity |\n| `refactor` | Indicates that the issue is a code refactor and is not fixing a bug or adding additional functionality |\n\n### Issue Specific\n\n| Label | Description |\n| ----- | ----------- |\n| `help wanted` | Marks an issue needs help from the community to solve |\n| `proposal` | Marks an issue as a proposal |\n| `question/support` | Marks an issue as a support request or question |\n| `good first issue` | Marks an issue as a good starter issue for someone new to Helm |\n| `wont fix` | Marks an issue as discussed and will not be implemented (or accepted in the case of a proposal) |\n\n### PR Specific\n\n| Label | Description |\n| ----- | ----------- |\n| `awaiting review` | Indicates a PR has been triaged and is ready for someone to review |\n| `breaking` | Indicates a PR has breaking changes (such as API changes) |\n| `in progress` | Indicates that a maintainer is looking at the PR, even if no review has been posted yet |\n| `needs rebase` | Indicates a PR needs to be rebased before it can be merged |\n| `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 |\n| `picked` | This PR has been cherry-picked into a feature branch |\n\n#### Size labels\n\nSize labels are used to indicate how \"dangerous\" a PR is. The guidelines below are used to assign the\nlabels, but ultimately this can be changed by the maintainers. For example, even if a PR only makes\n30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as `size/L`\nbecause it requires sign off from multiple people. Conversely, a PR that adds a small feature, but requires\nanother 150 lines of tests to cover all cases, could be labeled as `size/S` even though the number of\nlines is greater than defined below.\n\nPRs submitted by a core maintainer, regardless of size, only requires approval from one additional\nmaintainer. This ensures there are at least two maintainers who are aware of any significant PRs\nintroduced to the codebase.\n\n| Label | Description |\n| ----- | ----------- |\n| `size/XS` | Denotes a PR that changes 0-9 lines, ignoring generated files. Very little testing may be required depending on the change. |\n| `size/S` | Denotes a PR that changes 10-29 lines, ignoring generated files. Only small amounts of manual testing may be required. |\n| `size/M` | Denotes a PR that changes 30-99 lines, ignoring generated files. Manual validation should be required. |\n| `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. |\n| `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. |\n| `size/XXL` | Denotes a PR that changes 1000+ lines, ignoring generated files. This should be thoroughly tested before merging and always requires 2 approvals. |\n"
  },
  {
    "path": "Containerfile",
    "content": "FROM node:20-alpine\n\nWORKDIR /src\n\n# Tools needed by Make targets\nRUN apk update && apk add --no-cache make\n\n# Use existing Yarn; install deps with lockfile for reproducibility\nCOPY package.json yarn.lock ./\nRUN yarn install --frozen-lockfile\n\n# Copy project files\nCOPY . .\n\n# Docusaurus dev server port\nEXPOSE 3000\n\n# Make targets run inside the container (serve, build, etc.)\nENTRYPOINT [\"make\"]\n"
  },
  {
    "path": "HELM2-TO-DOCUSAURUS.md",
    "content": "# Helm v2 to Docusaurus Migration Guide\n\nAutomated 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.\n\n## Key Features\n\n- **Complete Structure Analysis** - Analyzes live v2.helm.sh to capture exact sidebar structure\n- **Missing File Integration** - Adds helm commands not present in navigation but available in source\n- **Link Path Correction** - Fixes broken internal links using shared href processing utility\n- **Image Path Replacement** - Updates all image references to `/img/helm2/` format\n- **H2 Heading Removal** - Removes redundant first H2 headings from helm command files\n- **Index File Creation** - Generates proper Docusaurus landing page with DocCardList\n- **Proper Positioning** - Maintains v2.helm.sh hierarchical organization\n- **Fully idempotent** - Safe to re-run multiple times\n\n## Usage\n\n**Simple command:**\n```bash\nyarn migrate:v2\n```\n\n**Manual steps (if needed):**\n\n1. **Run complete migration:**\n   ```bash\n   node scripts/migrate-v2-docs.js\n   ```\n\n2. **Copy images (if not already present):**\n   ```bash\n   cp -r helm2/docs/images static/img/helm2\n   ```\n\nThe migration command handles all steps automatically including:\n- Cloning helm2 source repository\n- Generating navigation structure\n- Processing and copying files\n- Applying link path corrections\n\n## What It Does\n\nThe migration process includes:\n\n1. **Fresh Start**: Clears existing v2 documentation and helm2 source\n2. **Source Setup**: Clones Helm v2 repository (release-2.17 branch)\n3. **Structure Analysis**: `scripts/v2/menu-generate.js` fetches and analyzes complete v2.helm.sh sidebar structure\n4. **Content Processing**: `scripts/v2/copy-files.js` processes all files:\n   - Removes UTF-8 BOM characters\n   - Replaces image paths from `(images/` to `(/img/helm2/`\n   - Removes first H2 headings from helm command files\n   - Creates proper Docusaurus frontmatter with hierarchical positioning\n   - Adds missing helm commands (helm get notes, helm inspect readme)\n5. **Link Correction**: `scripts/util/href-diffs-process.js` fixes broken internal links using `scripts/v2/href-diffs.json`\n6. **Structure Creation**: Generates `versioned_docs/version-2/` with proper category organization\n7. **Index Generation**: Creates `index.mdx` landing page with DocCardList component\n\n## Output Structure\n\n```\nversioned_docs/version-2/     # Complete Docusaurus v2 docs\n├── index.mdx                 # Landing page (position 1)\n├── using_helm/               # Basic usage (position 2)\n├── helm/                     # CLI reference (position 3, 45 commands)\n├── developing_charts/        # Chart development (position 4)\n├── chart_template_guide/     # Template guides (position 5)\n├── chart_best_practices/     # Best practices (position 6)\n└── [5 top-level files]       # architecture, developers, etc. (positions 7-11)\n\nstatic/img/helm2/             # All migrated images\n```\n\n## Validation & Maintenance\n\n**Verify after running:**\n- Navigation matches v2.helm.sh structure with correct positioning (1,2,3,4,5,6,7-11)\n- All images display correctly (`/img/helm2/` paths)\n- Index files use parent category labels in sidebar\n- First H2 headings removed from all helm command files\n- Netlify redirects handle v2 → v3 category mapping\n\n**Key paths:**\n- Migration orchestrator: `scripts/migrate-v2-docs.js`\n- Component scripts: `scripts/v2/menu-generate.js`, `scripts/v2/copy-files.js`\n- Link correction: `scripts/util/href-diffs-process.js` with `scripts/v2/href-diffs.json`\n- Generated data: `scripts/v2/menu.json`\n- Source: `helm2/docs/` (auto-cloned)\n- Output: `versioned_docs/version-2/` and `static/img/helm2/`\n\nThe migration is fully automated and idempotent - safe to re-run multiple times.\n\n**Link path corrections:** Managed via `scripts/v2/href-diffs.json` - add entries here to fix additional broken links discovered in migrated content.\n"
  },
  {
    "path": "HELM3-TO-DOCUSAURUS.md",
    "content": "# Helm v3 to Docusaurus Migration Guide\n\nAutomated migration of Helm v3 documentation from existing Hugo content to Docusaurus versioned documentation format, applying comprehensive text transformations and link corrections.\n\n## Key Features\n\n- **Hugo to Docusaurus Conversion** - Transforms Hugo content structure to Docusaurus versioning\n- **Hugo Shortcode Processing** - Converts `{{< ref \"path\" >}}` and `{{< highlightexamplego file=\"path\" >}}` to standard links\n- **Link Path Correction** - Fixes broken internal links using shared href processing utility\n- **Alias Removal** - Removes Hugo aliases that conflict with Docusaurus routing\n- **SDK Section Migration** - Imports and processes Go SDK examples with transformations\n- **DocCardList Integration** - Adds navigation cards to index pages\n- **Netlify Redirect Generation** - Creates redirects for removed aliases\n- **Fully idempotent** - Safe to re-run multiple times\n\n## Usage\n\n**Simple command:**\n```bash\nyarn migrate:v3\n```\n\n**Manual steps (if needed):**\n\n1. **Run complete migration:**\n   ```bash\n   node scripts/migrate-v3-docs.js\n   ```\n\nThe migration command handles all steps automatically including:\n- Fresh start with clean slate\n- Moving docs from Hugo structure to Docusaurus versioning\n- Processing Hugo shortcodes and text replacements\n- Applying link path corrections\n- Removing conflicting aliases\n- Adding navigation components\n\n## What It Does\n\nThe migration process includes:\n\n1. **Fresh Start**: Clears existing v3 documentation and restores from git main\n2. **Docusaurus Setup**: Creates `versioned_docs/version-3/` structure\n3. **Content Migration**: Moves docs from `content/en/docs/` to versioned structure\n4. **Content Cleanup**: Deletes files marked with deprecated frontmatter section\n5. **File Renaming**: Converts `index.md` files to `index.mdx` for React component support\n6. **Frontmatter Conversion**: Replaces Hugo `weight` with Docusaurus `sidebar_position`\n7. **Index Metadata**: Adds proper metadata to main index file\n8. **SDK Migration**: `scripts/v3/migrate-sdk-section.js` imports Go SDK examples with transformations\n9. **Text Processing**: `scripts/util/util-text-replacements.js` handles:\n   - Hugo shortcode conversion (`{{< ref \"path\" >}}` → `path`)\n   - Link path correction using `scripts/v3/href-diffs.json`\n10. **Helm File Processing**: `scripts/v3/process-helm-files.js` removes redundant H2 headings and adds metadata\n11. **Alias Removal**: `scripts/v3/remove-aliases.js` removes conflicting Hugo aliases\n12. **Navigation Enhancement**: `scripts/util/util-migration.js` adds DocCardList components to index pages\n13. **Redirect Generation**: `scripts/v3/add-netlify-redirects.js` creates redirects for removed aliases\n\n## Output Structure\n\n```\nversioned_docs/version-3/     # Complete Docusaurus v3 docs\n├── index.mdx                 # Landing page with DocCardList\n├── intro/                    # Introduction section\n├── topics/                   # Advanced topics\n├── chart_template_guide/     # Template development\n├── chart_best_practices/     # Best practices\n├── community/                # Community resources\n├── helm/                     # CLI reference\n└── [other sections]          # Additional documentation areas\n\nnetlify.toml                  # Updated with v3 redirects\n```\n\n## Validation & Maintenance\n\n**Verify after running:**\n- Navigation structure matches expected Docusaurus layout\n- Hugo shortcodes converted to standard markdown links\n- All `index.mdx` files have proper DocCardList components\n- CLI reference files have clean headings (no redundant H2s)\n- Netlify redirects handle removed aliases\n- No Hugo aliases remain in frontmatter\n\n**Key paths:**\n- Migration orchestrator: `scripts/migrate-v3-docs.js`\n- 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`\n- Text processing: `scripts/util/util-text-replacements.js`, `scripts/util/util-migration.js`\n- Link correction: `scripts/util/href-diffs-process.js` with `scripts/v3/href-diffs.json`\n- Source: `content/en/docs/` (Hugo structure)\n- Output: `versioned_docs/version-3/` (Docusaurus structure)\n\nThe migration is fully automated and idempotent - safe to re-run multiple times.\n\n**Link path corrections:** Managed via `scripts/v3/href-diffs.json` - add entries here to fix additional broken links discovered in migrated content.\n\n**SDK examples:** The migration includes Go SDK examples from `sdkexamples/` with automatic transformations for Docusaurus compatibility."
  },
  {
    "path": "LICENSE",
    "content": "The MIT License (MIT)\n\nCopyright (c) 2017 Microsoft Corporation\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n"
  },
  {
    "path": "Makefile",
    "content": "SITE_URL ?= http://localhost:3000\nBASE_URL ?= /\n\nclean:\n\trm -rf node_modules/ build/ .docusaurus .cache-loader\n\ninstall:\n\tyarn install --frozen-lockfile\n\nbuild: clean install\n\tSITE_URL=$(SITE_URL) BASE_URL=$(BASE_URL) yarn run build\n\n# Cache-friendly install - only runs if dependencies missing or yarn.lock is newer\ninstall-if-needed:\n\t@if [ ! -f \"node_modules/.bin/docusaurus\" ] || [ \"yarn.lock\" -nt \"node_modules\" ]; then \\\n\t\techo \"Installing dependencies...\"; \\\n\t\tyarn install --frozen-lockfile; \\\n\telse \\\n\t\techo \"Dependencies up to date, skipping install\"; \\\n\tfi\n\n# Cache-friendly build for Netlify - preserves cached directories\nnetlify-build: install-if-needed\n\tSITE_URL=$(SITE_URL) BASE_URL=$(BASE_URL) yarn run build\n\n.PHONY: sdkexamples\nsdkexamples:\n\tmake -C sdkexamples\n\nserve:\n\tSITE_URL=$(SITE_URL) BASE_URL=$(BASE_URL) yarn run start --host 0.0.0.0\n\nIMAGE_NAME ?= helm-www\n\nimage:\n\tpodman build -t $(IMAGE_NAME) -f Containerfile .\n\n# Default target executed inside the container if none specified\nCONTAINER_TARGET = $(if $(filter-out image-run,$(MAKECMDGOALS)),$(filter-out image-run,$(MAKECMDGOALS)),serve)\n\n# Podman run: pass env for both build and serve targets\nimage-run: image\n\tpodman run --rm --init -it \\\n\t\t-p 3000:3000 \\\n\t\t-v $(PWD):/src:Z \\\n\t\t-e BASE_URL=\"$(BASE_URL)\" \\\n\t\t-e SITE_URL=\"$(SITE_URL)\" \\\n\t\t--name $(IMAGE_NAME)-run \\\n\t\t$(IMAGE_NAME) $(CONTAINER_TARGET)\n"
  },
  {
    "path": "OWNERS",
    "content": "maintainers:\n  - gjenkins8\n  - karenhchu\n  - mattfarina\n  - paigecalvert\n  - scottrigby\n  - technosophos\n  - TerryHowe\n  - yxxhero\nemeritus:\n  - angellk\n  - bacongobbler\n  - bridgetkromhout\n  - flynnduism\n  - hickeyma\n  - jdolitsky\n  - thomastaylor312\n"
  },
  {
    "path": "README-ko.md",
    "content": "![github-banner-helm-helmwww](https://user-images.githubusercontent.com/686194/68531441-f4ad4e00-02c6-11ea-982b-74d7c3ff0071.png)\n\n여기서 [헬름](https://github.com/helm/helm) 프로젝트의 웹 사이트 [helm.sh](https://helm.sh/)를 구성하는 모든 것을 확인할 수 있습니다. 문서를 편집하거나 웹 사이트 버그를 보고하거나 새 블로그 게시물을 작성하려는 경우 잘 찾아오셨습니다!\n\n## 개발\n\nHelm.sh는 간단한 [Docusaurus](https://docusaurus.io/) 정적 사이트입니다. 웹 사이트를 로컬에서 실행하려면 먼저 의존성을 설치해야 합니다.\n\n```\nyarn\n```\n\n그런 다음 사이트를 로컬에서 컴파일하고 실행할 수 있습니다.\n\n```\nyarn start\n```\n\n## 배포 [![Netlify Status](https://api.netlify.com/api/v1/badges/8ffabb30-f2f4-45cc-b0fa-1b4adda00b5e/deploy-status)](https://app.netlify.com/sites/helm-merge/deploys)\n\n변경 사항을 `main` 브랜치에 병합하면 [넷틀리파이(Netlify)](https://app.netlify.com/sites/helm-merge/deploys)에 자동으로 배포됩니다. 빌드 로그는 [여기](https://app.netlify.com/sites/helm-merge/deploys)에서 확인할 수 있습니다.\n\n---\n\n## 기여\n\n누구나 풀 리퀘스트(PR)를 제출하여 Helm.sh을 편집할 수 있습니다. 커밋을 위해서는 서명이 필요합니다. [기여 가이드](https://github.com/helm/helm/blob/main/CONTRIBUTING.md#sign-your-work)를 참조하세요.\n\n풀 리퀘스트는 병합되기 전에 [관리자](https://github.com/helm/helm-www/blob/main/OWNERS)의 승인이 필요합니다.\n\n### 헬름 문서를 편집하는 방법\n\n헬름 v4 문서는 이 저장소의 `/docs/` 에 있습니다. 헬름 v4 문서의 사이드바는 `sidebars.js`에 있습니다.\n\n헬름 v3 문서는 `versioned-docs/version-3` 에 있습니다. 헬름 v3 문서의 사이드바는 `versioned-sidebars/sidebars-version-2.js`에 있습니다.\n\n이전 버전의 경우, [기본 헬름 저장소](https://github.com/helm/helm/tree/dev-v2/docs)의 dev-v2 브랜치를 참조합니다.\n\n### 헬름 CLI 레퍼런스 문서 업데이트\n\n헬름 CLI 명령어 목록에 대한 문서는 기본 헬름 프로젝트 저장소에서 [내보내지고](https://github.com/helm/helm/blob/a6b2c9e2126753f6f94df231e89b2153c2862764/cmd/helm/root.go#L169), [여기](https://helm.sh/docs/helm)에서 레퍼런스로 제공됩니다.\n\n문서를 업데이트하려면 다음을 수행해야 합니다.\n\n1. `helm plugin uninstall` 을 실행하여 현재 설치된 모든 플러그인을 제거합니다.\n2. `content/en/docs/helm/` 으로 이동합니다.\n3. 기존 마크다운 파일을 대체하여 새로운 마크다운 문서 파일을 생성하기 위해 `HOME='~' helm docs --type markdown --generate-headers`를 실행합니다. **참고:** 문서를 빌드하려는 helm 버전을 실행해야 합니다 (예: 올바른 태그를 체크아웃하고 빌드)\n4. 변경 내용을 커밋하고 PR을 만들어 웹 사이트를 업데이트합니다.\n\n### 블로그 게시물을 작성하는 방법\n\n블로그 게시물은 풀 리퀘스트를 통해 만들어집니다. 다음 단계를 사용하여 추가합니다.\n\n1. `/blog/` 디렉터리에 게시 날짜와 제목이 파일명인 새 파일을 추가합니다. 파일은 마크다운 형식이어야 합니다. 형식 예시는 기존 제목을 참조합니다.\n2. 이 형식을 사용하여 파일에 헤더 메타데이터를 추가합니다.\n\n   ```yaml\n   ---\n   title: \"Blog Title\"\n   slug: \"blog-slug\"\n   # from /blog/authors.yml\n   authors: [\"firstlast\"]\n   date: \"YYYY-MM-DD\"\n   ---\n   ```\n\n3. 이 저자의 첫 번째 블로그 게시물인 경우, `/blog/authors.yml`을 업데이트하여 새 저자 레코드를 추가합니다.\n   ```yaml\n   # authors.yml\n   johndoe:\n     name: John Doe\n     image_url: https://github.com/johndoe.png\n     page: true\n     socials:\n       github: johndoe\n       linkedin: johndoe\n       website: http://johndoe.com/\n   ```\n4. `---` 아래에 마크다운으로 내용을 추가합니다. 이 섹션에는 제목을 포함할 필요가 없습니다.\n5. 모든 이미지는 `/blog/images/` 디렉토리에 두어야 합니다. 이미지 크기를 줄이려면 무손실 압축되어야 합니다. [ImageOptim](https://imageoptim.com/)와 같은 도구를 사용할 수 있습니다.\n6. 블로그 인덱스 페이지의 내용을 요약하려면 마크다운 파일에 `<!--truncate-->` 구분자를 넣습니다. 이렇게 하면 _더 읽기_ 링크로 내용 끝을 자릅니다.\n\n블로그 PR은 병합되기 전에 주요 헬름 [관리자](https://github.com/helm/helm/blob/main/OWNERS)들의 승인이 필요합니다.\n\n### 버전 관리\n\n이 저장소의 다음 파일들이 버전 관리를 제어하는 데 사용됩니다:\n\n- 버전 관리된 문서는 `versioned_docs`에 있습니다.\n- 각 버전에 해당하는 사이드바는 `versioned_sidebars`에 있습니다.\n- 버전 관리 동작은 `docusaurus.config.js` 파일에서 관리됩니다:\n\n  ```js\n  export default {\n    presets: [\n      '@docusaurus/preset-classic',\n      docs: {\n      // lastVersion = 최신 릴리스 버전 (/versioned_docs의 특정 버전 또는 'current')\n      // 최신으로 나열되지 않은 버전의 경우, 사용자가 오래되었거나 사전 릴리스 문서를 보고 있다는 경고 배너가 자동으로 표시됩니다\n        lastVersion: '3',\n        versions: {\n          // current = 최상위 /docs 디렉토리의 문서. 이것들은 사전 릴리스이거나 최신 릴리스 버전일 수 있습니다\n          // label = 네비게이션 바 드롭다운에 표시되는 버전 레이블\n          current: { label: '4.0.0-alpha.1 🚧' },\n          // 번호가 매겨진 버전은 /versioned_docs의 디렉토리에 해당합니다\n          '3': { label: '3.19.0' },\n          '2': { label: '2.17.0' },\n        },\n      },\n    ],\n  };\n  ```\n\n- 사용 가능한 버전 목록은 `versions.json`에서 유지됩니다.\n\n아래 표는 이 저장소의 버전 관리된 문서에 매핑되는 버전 레이블과 URL 경로를 설명합니다:\n\n| 저장소 경로                            | 버전                 | URL 경로            |\n| -------------------------------------- | -------------------- | ------------------- |\n| `versioned_docs/version-2/filename.md` | 2.17.0               | /docs/2/filename    |\n| `versioned_docs/version-3/filename.md` | 3.19.0 (최신)        | /docs/filename      |\n| `docs/filename.md`                     | 4.0.0-alpha.1 (현재) | /docs/next/filename |\n\n#### 사전 릴리스 문서를 GA로 이동하는 방법\n\nDocusaurus는 _사전 릴리스_ (알파, 베타) 문서 게시를 지원합니다. 기본적으로 사전 릴리스 문서는 helm.sh/docs/next에서 게시되며 이 저장소의 최상위 `/docs` 디렉토리에서 제공됩니다. 또한 Docusaurus는 사용자가 릴리스되지 않은 문서를 보고 있다는 것을 알리기 위해 모든 사전 릴리스 문서에 자동으로 배너를 적용합니다.\n\nHelm의 사전 릴리스 버전이 GA로 승격될 때, 사전 릴리스 문서를 helm.sh/docs/next에서 helm.sh/docs로 이동하려면 다음을 수행합니다:\n\n1. `docusaurus.config.js`를 업데이트하여 `lastVersion`을 `'current'`로 설정합니다. 이렇게 하면 메인 `/docs` 폴더의 내용이 helm.sh`/docs`에 게시됩니다.\n\n   ```js\n   // docusaurus.config.js\n   lastVersion: 'current',\n   ```\n\n1. `current` 버전의 네비게이션 바 `label`을 업데이트합니다. 예를 들어:\n\n   ```js\n   // docusaurus.config.js\n   current: { label: '4.0.0' },\n   ```\n\n1. 변경사항을 테스트하기 위해 로컬 미리보기를 시작합니다. \"릴리스되지 않음\" 배너가 현재 버전에서 제거되고 현재 버전이 helm.sh/docs/next가 아닌 helm.sh/docs에서 사용할 수 있게 되는 것을 확인해야 합니다.\n\n#### 새로운 사전 릴리스 버전을 만드는 방법\n\n새 버전 만들기는 `/docs` 디렉토리 내용을 `versioned_docs`의 버전 관리된 폴더로 복사하는 것을 의미합니다. 새로운 _주요_ 사전 릴리스 버전의 문서를 게시할 준비가 되었을 때 버전을 만듭니다. 이는 일반적으로 Helm의 새로운 알파 버전이 개발되고 문서화할 준비가 되었을 때입니다.\n\n**참고:** Helm의 사전 릴리스 버전이 개발되고 문서화할 준비가 될 때까지는 새 버전 만들기를 권장하지 않습니다. 그렇지 않으면 문서를 두 곳에서 유지해야 하므로(둘 다 `/docs`와 최신 `/versioned_docs` 폴더), 관리자가 동기화 상태를 유지하기 위해 추가 작업을 해야 합니다. 대신 아래의 *사전 릴리스 문서를 GA로 이동하는 방법*을 참조하세요.\n\n새 버전을 만들려면:\n\n1. `<version>`이 주요 Helm 버전에 해당하는 정수인 `yarn docusaurus docs:version <version>`을 실행합니다. 예를 들어, Helm v5에 대한 새로운 사전 릴리스 문서를 게시하려면 v4 문서 내용을 새로운 `version-4` 폴더로 복사하기 위해 `yarn docusaurus docs:version 4`를 실행할 수 있습니다.\n\n   이 명령은 다음을 수행합니다:\n\n   - 전체 `docs/` 폴더 내용을 새로운 `versioned_docs/version-<version>/` 폴더로 복사합니다.\n   - `versioned_sidebars/version-<version>-sidebars.json`에 버전 관리된 사이드바 파일을 생성합니다.\n   - `versions.json`에 새 버전 번호를 추가합니다.\n\n1. `docusaurus.config.js` 파일을 업데이트합니다:\n\n   1. `lastVersion`을 최신 GA 버전으로 설정합니다. 이렇게 하면 helm.sh/docs의 문서가 최신 versioned_docs 폴더에서 제공됩니다. 그리고 helm.sh/docs/next의 문서가 메인 `/docs` 폴더에서 제공됩니다.\n\n      예를 들어, Helm v4 문서를 `versioned_docs/version-4/` 디렉토리로 만들고 Helm v5.0.0-alpha.1에 대한 사전 릴리스 문서를 게시하려면 `lastVersion`을 `'4'`로 설정합니다.\n\n   1. `current` 버전의 네비게이션 바 `label`을 업데이트합니다. 예를 들어, 현재(사전 릴리스) 버전을 `5.0.0-alpha.1`로 레이블링하려면 다음과 같이 레이블을 업데이트합니다:\n\n      ```js\n      current: { label: '5.0.0-alpha.1 🚧' },\n      ```\n\n1. 변경사항을 테스트하기 위해 로컬 미리보기를 시작합니다. 드롭다운에서 새 버전을 보고, helm.sh/docs/next에서 사전 릴리스 문서에 액세스할 수 있으며, 모든 사전 릴리스 문서 상단에 \"릴리스되지 않음\" 배너가 표시되는 것을 확인해야 합니다.\n\n새 문서 버전 만들기에 대한 자세한 정보는 Docusaurus 문서의 [버전 관리](https://docusaurus.io/docs/versioning)를 참조하세요.\n\n### 국제화 & 번역\u001f\n\n**우리 사이트와 문서의 컨텐츠 번역을 환영합니다** 전 세계에서 Helm에 대한 접근을 확장하는 데 도움이 되도록 합니다.\n\nHelm.sh는 여러 언어를 지원합니다. 해외 사용자를 위한 컨텐츠 번역과 구성 가이드는 [헬름 문서 현지화\u001d](/community/localization)를 참조하세요.\n\n---\n\n### 행동 강령\n\n헬름 커뮤니티 참여는 헬름 [행동 강령](https://github.com/helm/helm/blob/main/code-of-conduct.md)을 따릅니다.\n\n### 감사합니다!\n\n웹 사이트 및 문서 기여에 감사드립니다! :clap:\n"
  },
  {
    "path": "README.md",
    "content": "![github-banner-helm-helmwww](https://user-images.githubusercontent.com/686194/68531441-f4ad4e00-02c6-11ea-982b-74d7c3ff0071.png)\n\nThis 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!\n\n## Development\n\nHelm.sh is a simple [Docusaurus](https://docusaurus.io/) static site. To run the website locally, you'll need to first install the dependencies:\n\n```\nyarn\n```\n\nYou can then compile and run the site locally:\n\n```\nyarn start\n```\n\n## 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)\n\nChanges 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).\n\n---\n\n## Contributing\n\nAnyone 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).\n\nPull requests require [maintainer](https://github.com/helm/helm-www/blob/main/OWNERS) approval before merge.\n\n### Style Guide\n\nFor Helm documentation style guidelines, see [Documentation Style Guide](style-guide.md).\n\n### How to Edit The Helm Docs\n\nHelm v4 documentation is located in this repo under `/docs/`. The sidebar for the Helm v4 docs is located at `sidebars.js`.\n\nHelm 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`\n\nFor earlier versions, see the dev-v2 branch of the main Helm repo [here](https://github.com/helm/helm/tree/dev-v2/docs).\n\n### Community Documentation\n\nThe Community section imports content from the [helm/community](https://github.com/helm/community) repository. To manage these imported docs:\n\n#### Download/Update Community Docs\n```bash\nyarn download-remote-community\n```\nThis command fetches the latest community documentation from the helm/community repository and applies transformations for proper integration.\n\n#### Clear Community Docs\n```bash\nyarn clear-remote-community\n```\nThis removes the imported community documentation files (useful before re-importing or for troubleshooting).\n\nThe imported docs configuration is defined in `docusaurus.config.js` under `customFields.communityDocs`. See `ARCHITECTURAL_DECISIONS.md` for details on the implementation.\n\n### Updating the Helm CLI Reference Docs\n\nThe 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.\n\n#### Using the automated script\n\nThe automated script regenerates and properly formats the CLI documentation:\n\n```bash\nnode scripts/regenerate-cli-docs.mjs <helm-version> <target-directory>\n\n# Examples:\nnode scripts/regenerate-cli-docs.mjs v3.19.0 versioned_docs/version-3  # → versioned_docs/version-3/helm/\nnode scripts/regenerate-cli-docs.mjs v4.0.0-rc.1 docs                  # → docs/helm/\nnode scripts/regenerate-cli-docs.mjs v4.0.0 versioned_docs/version-4   # → versioned_docs/version-4/helm/\n```\n\nThe script will:\n- Download the specified Helm version\n- Generate documentation in `<target-directory>/helm/`\n- Apply all necessary post-processing (frontmatter cleanup, link conversion, etc.)\n\n### How to Write a Blog Post\n\nBlog posts are created via pull requests. The following steps are used to add them:\n\n1. 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\n2. Add the header meta-data to the file using this format.\n\n   ```yaml\n   ---\n   title: \"Blog Title\"\n   slug: \"blog-slug\"\n   # from /blog/authors.yml\n   authors: [\"firstlast\"]\n   date: \"YYYY-MM-DD\"\n   ---\n   ```\n\n3. If this is the first blog post by this author, update `/blog/authors.yml` to add a new author record.\n   ```yaml\n   # authors.yml\n   johndoe:\n     name: John Doe\n     image_url: https://github.com/johndoe.png\n     page: true\n     socials:\n       github: johndoe\n       linkedin: johndoe\n       website: http://johndoe.com/\n   ```\n4. Add the content below the `---` as Markdown. The title does not need to be included in this section\n5. 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.\n6. To summarize the content on the blog index page, insert a `<!--truncate-->` break in your markdown. This will truncate the content with a _Read More_ link.\n\nBlog PRs require approval from the core Helm [maintainers](https://github.com/helm/helm/blob/main/OWNERS) before merge.\n\n### Versioning\n\nThe following files in this repo are used to control versioning:\n\n- Versioned documentation is located in `versioned_docs`.\n- The corresponding sidebar for each version is located in `versioned_sidebars`.\n- Versioning behavior is managed in the `docusaurus.config.js` file:\n\n  ```js\n  export default {\n    presets: [\n      '@docusaurus/preset-classic',\n      docs: {\n      // lastVersion = the latest released version (either a specific version from /versioned_docs or 'current')\n      // 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\n        lastVersion: '3',\n        versions: {\n          // current = docs from the top-level /docs directory. These can be pre-release or the latest released version\n          // label = the version label displayed in the navbar dropdown\n          current: { label: '4.0.0-alpha.1 🚧' },\n          // numbered versions correspond to directories in /versioned_docs\n          '3': { label: '3.19.0' },\n          '2': { label: '2.17.0' },\n        },\n      },\n    ],\n  };\n  ```\n\n- The list of available versions is maintained in `versions.json`.\n\nThe table below explains the version labels and URL paths that map to versioned docs in this repo:\n\n| Repo Path                              | Version                 | URL Path            |\n| -------------------------------------- | ----------------------- | ------------------- |\n| `versioned_docs/version-2/filename.md` | 2.17.0                  | /docs/2/filename    |\n| `versioned_docs/version-3/filename.md` | 3.19.0 (latest)         | /docs/filename      |\n| `docs/filename.md`                     | 4.0.0-alpha.1 (current) | /docs/next/filename |\n\n#### How to move pre-release docs to GA\n\nDocusaurus 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.\n\nWhen 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:\n\n1. Update `docusaurus.config.js` to set `lastVersion` to `'current'`. This publishes the content of the main `/docs` folder to helm.sh`/docs`.\n\n   ```js\n   // docusaurus.config.js\n   lastVersion: 'current',\n   ```\n\n1. Update the navbar `label` for the `current` version. For example:\n\n   ```js\n   // docusaurus.config.js\n   current: { label: '4.0.0' },\n   ```\n\n1. 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.\n\n#### How to cut a new pre-release version\n\nCutting 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.\n\n**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.\n\nTo cut a new version:\n\n1. Run `yarn docusaurus docs:version <version>`, where `<version>` 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`.\n\n   This command does the following:\n\n   - Copies the full `docs/` folder contents into a new `versioned_docs/version-<version>/` folder.\n   - Creates a versioned sidebars file in `versioned_sidebars/version-<version>-sidebars.json`.\n   - Appends the new version number to `versions.json`.\n\n1. Update the `docusaurus.config.js` file:\n\n   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.\n\n      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'`.\n\n   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:\n\n      ```js\n      current: { label: '5.0.0-alpha.1 🚧' },\n      ```\n\n1. 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.\n\nFor more information about cutting new docs versions, see [Versioning](https://docusaurus.io/docs/versioning) in the Docusaurus documentation.\n\n### Internationalization & Translation\n\n**We welcome content translations** to our site and our docs, to help expand access to Helm around the world.\n\nHelm.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.\n\n---\n\n### Code of Conduct\n\nParticipation in the Helm community is governed by the Helm [Code of Conduct](https://github.com/helm/helm/blob/main/code-of-conduct.md).\n\n### Thank You!\n\nWe appreciate your contributions to our website and our documentation! :clap:\n"
  },
  {
    "path": "blog/2018-06-01-cncf.md",
    "content": "---\ntitle: \"Helm Enters the CNCF\"\nslug: \"helm-enters-the-cncf\"\nauthors: [\"mattbutcher\"]\ndate: \"2018-06-01\"\n---\n\nToday 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.  <!-- truncate -->\n\nWe 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.\n\nHelm 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.\n\nThank 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.\n\nWe 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.\n"
  },
  {
    "path": "blog/2018-07-23-bring-helm-home.md",
    "content": "---\ntitle: \"Bringing Helm Home\"\nslug: \"bringing-helm-home\"\nauthors: [\"mattbutcher\"]\ndate: \"2018-07-23\"\n---\n\nEarlier 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).  <!-- truncate -->\n\nFun 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.\n\nSince 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.\n\nAlong 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.\n\nThis 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.\n"
  },
  {
    "path": "blog/2018-07-24-helm-emeritus-rimus.md",
    "content": "---\ntitle: \"Helm Emeritus Maintainer Rimas Mocevicius\"\nslug: \"helm-emeritus-maintainer-rimas-mocevicius\"\nauthors: [\"mattbutcher\"]\ndate: \"2018-07-24\"\n---\n\nRimas Mocevicius ([rimusz](https://github.com/rimusz)) has become the fourth Helm Emeritus Maintainer.<!-- truncate --> 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.\n\nCheck out Rimas' latest blog post on [Tillerless Helm](https://rimusz.net/tillerless-helm).\n"
  },
  {
    "path": "blog/2018-08-27-helm-switch-dco.md",
    "content": "---\ntitle: \"Helm Moves To DCO\"\nslug: \"helm-dco\"\ndate: \"2018-08-27\"\n---\n\nWhen 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.  <!-- truncate -->\n## What Does This Solve? Why Switch?\n\nMaking 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.\n\nWhen 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.\n\nWe wanted to make it simpler to contribute.\n\n## What Is A DCO?\n\nA 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.\n\nThe full text of the DCO can be found at https://developercertificate.org. It reads:\n\n> Developer Certificate of Origin\n> Version 1.1\n>\n> Copyright (C) 2004, 2006 The Linux Foundation and its contributors.\n> 1 Letterman Drive\n> Suite D4700\n> San Francisco, CA, 94129\n> \n> Everyone is permitted to copy and distribute verbatim copies of this\n> license document, but changing it is not allowed.\n> \n> \n> Developer's Certificate of Origin 1.1\n> \n> By making a contribution to this project, I certify that:\n> \n> (a) The contribution was created in whole or in part by me and I\n>     have the right to submit it under the open source license\n>     indicated in the file; or\n> \n> (b) The contribution is based upon previous work that, to the best\n>     of my knowledge, is covered under an appropriate open source\n>     license and I have the right under that license to submit that\n>     work with modifications, whether created in whole or in part\n>     by me, under the same open source license (unless I am\n>     permitted to submit under a different license), as indicated\n>     in the file; or\n> \n> (c) The contribution was provided directly to me by some other\n>     person who certified (a), (b) or (c) and I have not modified\n>     it.\n> \n> (d) I understand and agree that this project and the contribution\n>     are public and that a record of the contribution (including all\n>     personal information I submit with it, including my sign-off) is\n>     maintained indefinitely and may be redistributed consistent with\n>     this project or the open source license(s) involved.\n\nAn example signed commit message might look like:\n\n> An example commit message\n> \n> Signed-off-by: Some Developer <somedev@example.com>\n\nGit has a flag that can sign a commit for you. An example using it is:\n\n```\n$ git commit -s -m 'An example commit message'\n```\n\nIn 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.\n\n## FAQs\n\n### What About Existing Pull Requests Under The CLA\n\nIf 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.\n\n### What About The Other Elements Of A CLA\n\nThe 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.\n\n### What About Commits With Multiple Contributors\n\nIf more than one person works on something it's possible for more than one person to sign off on it. For example,\n\n> An example commit message\n> \n> Signed-off-by: Some Developer <somedev@example.com>\n> Signed-off-by: Another Developer <anotherdev@example.com>\n\n### If I Contribute As An Employee Does My Employer Need To Sign Anything\n\nNope. The DCO assumes you are authorized to submit the code. This is what makes the contributor experience simpler for many people.\n\n### What If I Forget To Sign-off On A Commit\n\nThere 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.\n\nTo update the last commit message with a sign off you can use the command:\n\n```\n$ git commit --amend -s\n```\n\nThe `-s` flag is short for `--signoff`.\n\nIf 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.\n"
  },
  {
    "path": "blog/2018-09-07-new-gov-and-elections.md",
    "content": "---\ntitle: \"New Governance And Elections\"\nslug: \"new-gov-and-elections\"\ndate: \"2018-09-07\"\n---\n\nBeing 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.  <!-- truncate -->\n\nThe 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).\n\n## Two Types of Maintainers\n\nThe 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.\n\nThe 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.\n\n## Next Step: Selecting Helm Org Maintainers\n\nThe 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.\n\nAfter 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.\n\nTo 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.\n\nIf you have questions about the process, or how to nominate someone, please use the [Helm mailing list](https://lists.cncf.io/g/cncf-helm).\n"
  },
  {
    "path": "blog/2018-09-25-chart-testing-intro.md",
    "content": "---\ntitle: \"Using the Community Chart Testing Tools Yourself\"\nslug: \"chart-testing-intro\"\ndate: \"2018-09-25\"\n---\n\nThe 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.  <!-- truncate -->\n\nThese 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.\n\nThis 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.\n\n## Example: Locally on Mac\n\nOne 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:\n\n    $ /path/to/chart-testing/examples/docker-for-mac/my_test.sh\n\nTo 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:\n\n    Cluster \"docker-for-desktop-cluster\" set.\n    Cluster \"docker-for-desktop-cluster\" set.\n    Switched to context \"docker-for-desktop\".\n\n    --------------------------------------------------------------------------------\n    Environment:\n    REMOTE=k8s\n    TARGET_BRANCH=master\n    CHART_DIRS=stable incubator\n    EXCLUDED_CHARTS=common\n    CHART_REPOS=incubator=https://kubernetes-charts-incubator.storage.googleapis.com/\n    TIMEOUT=600\n    LINT_CONF=/testing/etc/lintconf.yaml\n    CHART_YAML_SCHEMA=/testing/etc/chart_schema.yaml\n    VALIDATE_MAINTAINERS=true\n    GITHUB_INSTANCE=https://github.com\n    CHECK_VERSION_INCREMENT=true\n    --------------------------------------------------------------------------------\n\n    Charts to be installed and tested: stable/mariadb\n    Initializing Helm client...\n    Creating /root/.helm\n    Creating /root/.helm/repository\n    Creating /root/.helm/repository/cache\n    Creating /root/.helm/repository/local\n    Creating /root/.helm/plugins\n    Creating /root/.helm/starters\n    Creating /root/.helm/cache/archive\n    Creating /root/.helm/repository/repositories.yaml\n    Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com\n    Adding local repo with URL: http://127.0.0.1:8879/charts\n    $HELM_HOME has been configured at /root/.helm.\n    Not installing Tiller due to 'client-only' flag having been set\n    Happy Helming!\n    \"incubator\" has been added to your repositories\n\n    --------------------------------------------------------------------------------\n    Processing chart 'stable/mariadb'...\n    --------------------------------------------------------------------------------\n\n    Validating chart 'stable/mariadb'...\n    Checking chart 'stable/mariadb' for a version bump...\n    Chart version on k8s/master : 5.0.3\n    New chart version:  5.0.3\n    ERROR: Chart version not ok. Needs a version bump.\n    Linting 'stable/mariadb/Chart.yaml'...\n    Linting 'stable/mariadb/values.yaml'...\n    Validating Chart.yaml\n    Validating /workdir/stable/mariadb/Chart.yaml...\n    Validation success! 👍\n    Validating maintainers\n    Verifying maintainer 'bitnami-bot'...\n    ERROR: Chart validation failed.\n    Building dependencies for chart 'stable/mariadb'...\n    No requirements found in stable/mariadb/charts.\n    Chart does not provide test values. Using defaults...\n    Linting chart 'stable/mariadb'...\n    ==> Linting stable/mariadb\n    Lint OK\n\n    1 chart(s) linted, no failures\n    --------------------------------------------------------------------------------\n    ✖︎ stable/mariadb\n    --------------------------------------------------------------------------------\n\nYou'll notice the chart failed to pass testing because the version was not incremented.\n\n## Configurable\n\nWhile 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).\n\nFor 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.\n\n## Example: Using It with CircleCI\n\nLinting, without trying to operate the chart, is easy to incorporate into a workflow. The following is a simple example CircleCI configuration to do so:\n\n    version: 2\n    jobs:\n      lint-charts:\n        docker:\n          - image: quay.io/helmpack/chart-testing:v1.1.0\n        steps:\n          - checkout\n          - run:\n              name: lint\n              command: |\n                chart_test.sh --config .testenv --no-install\n    workflows:\n      version: 2\n      lint:\n        jobs:\n          - lint-charts\n\nIn 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:\n\n    # The name of the Git remote\n    REMOTE=k8s\n\n    # The name of the Git target branch\n    TARGET_BRANCH=master\n\n    # Chart directories separated by a space\n    CHART_DIRS=(\n        stable\n        incubator\n    )\n\n    # Charts that should be skipped\n    EXCLUDED_CHARTS=(\n        common\n    )\n\n    # Additional chart repos to add (<name>=<url>), separated by a space\n    CHART_REPOS=(\n        incubator=https://kubernetes-charts-incubator.storage.googleapis.com/\n    )\n\n    TIMEOUT=600\n\n## Try It in Your Workflow\n\nThis 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.\n"
  },
  {
    "path": "blog/2018-10-04-helm-org-maintainers.md",
    "content": "---\ntitle: \"Introducing the Helm Org Maintainers\"\nslug: \"intro-helm-org-maintainers\"\ndate: \"2018-10-04\"\n---\n\nThe 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.  <!-- truncate -->\n\nIn alphabetical order, by first name, they are:\n\n* Adam Reese (adamreese)\n* Adnan Abdulhussein (prydonius)\n* Josh Dolitsky (jdolitsky)\n* Matt Butcher (technosophos)\n* Matt Farina (mattfarina)\n* Matt Fisher (bacongobbler)\n* Reinhard Nägele (unguiculus)\n* Scott Rigby (scottrigby)\n* Vic Iglesias (viglesiasce)\n\nThanks to everyone who ran. Helm is off to a great start under the CNCF and this is another step in our journey.\n\n## What Do Org Maintainers Do?\n\nOrg 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.\n"
  },
  {
    "path": "blog/2018-12-11-helm-hub.md",
    "content": "---\ntitle: \"Introducing the Helm Hub\"\nslug: \"intro-helm-hub\"\ndate: \"2018-12-11\"\n---\n\nHelm 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.\n\nWith 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. <!-- truncate -->\n\n![Helm Hub](https://helm.sh/img/blog/helm-hub.png)\n\nHelm 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.\n\nIf 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.\n\nThe 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.\n\nWe look forward to the Helm Hub ushering in a new phase of chart development and sharing.\n"
  },
  {
    "path": "blog/2019-01-14-chartmuseum-security-notice.md",
    "content": "---\ntitle: \"ChartMuseum Vulnerability: Authorization Bypass [CVE-2019-1000009]\"\nslug: \"chartmuseum-security-notice-2019\"\ndate: \"2019-01-14\"\n---\n\nSecurity 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.\n\nWhen 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.\n<!-- truncate -->\n\nAdditionally, 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.\n\nWe are unaware of any public exploits caused by this issue.\n\n## Details\n\nWhen 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.\n\nWhen 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.\n\n## Fix\n\nUpdate to ChartMuseum >= 0.8.1\n\nTo 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.\n"
  },
  {
    "path": "blog/2019-01-14-helm-security-notice.md",
    "content": "---\ntitle: \"Helm Vulnerability: Client Unpacking Chart that Contains Malicious Content [CVE-2019-1000008]\"\nslug: \"helm-security-notice-2019\"\nauthors: [\"mattbutcher\"]\ndate: \"2019-01-14\"\n---\n\nSecurity 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.\n\nA specially crafted chart may be able to unpack content into locations on the filesystem outside of the chart’s path, potentially overwriting existing files.\n<!-- truncate -->\n\nNo version of Tiller is known to be impacted. This is a client-only issue.\n\nThe following Helm commands may unsafely unpack malformed charts onto a local folder: `helm fetch --untar` and `helm lint some.tgz`.\n\n\nWe are unaware of any public exploits caused by this issue.\n\n## Details\n\nDuring 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.\n\nNo 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.\n\n## Workarounds\n\nUnpack 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.\n\n## Fix\n\nUpdate to Helm >= 2.12.2.\n\nAs 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.\n\nFrom 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.\n"
  },
  {
    "path": "blog/2019-04-18-helm-summit-eu-2019.md",
    "content": "---\ntitle: \"Helm Summit EU 2019\"\nslug: \"helm-summit-eu-2019\"\nauthors: [\"karenchu\"]\ndate: \"2019-04-18\"\n---\n\nWe'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.<!-- truncate -->\n\nInterested in... \n\n* 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. \n\n* 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. \n\n* Sponsoring? Sponsorships are now open and in limited quantity. Please reach out to sponsor@cncf.io for the sponsorship prospectus. \n\nIn the mean time, make sure to follow us on [Twitter](https://twitter.com/HelmPack) for the most up-to-date news on #HelmSummit! \n"
  },
  {
    "path": "blog/2019-04-22-helm-3-preview-pt1.md",
    "content": "---\ntitle: \"Helm 3 Preview: Charting Our Future – Part 1: A History of Helm\"\nslug: \"helm-3-preview-pt1\"\nauthors: [\"mattfisher\"]\ndate: \"2019-04-22\"\n---\nOn 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.\n\nIn 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.<!-- truncate -->\n\nIn order, I'll discuss:\n\n1. The history of the creation of Helm\n2. A Gentle Farewell to Tiller\n3. Chart Repositories\n4. Release Management\n5. Changes to Chart Dependencies\n6. Library Charts\n7. What’s Next?\n\n### A History of Helm\n\nLet'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.\n\n#### Helm was Born\n\nHelm 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.\n\nIn 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.\n\nModeled 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.\n\nOur 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.\n\nFor example, to substitute a field in a YAML file, one would add the following to a manifest:\n\n```\n#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml\n```\n\nMakes you really happy that template languages exist today, eh?\n\nFor 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.\n\nLearning from our past mistakes, we started designing Helm 2.\n\n#### Designing Helm 2\n\nAs 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?\n\nIn 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.\n\nOur goal was to maintain Helm's ease of use, but add the following:\n\n- Chart templates for customization\n- In-cluster management for teams\n- A first-class chart repository\n- A stable and signable package format\n- A strong commitment to semantic versioning and retaining backward compatibility version-to-version\n\nTo 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.\n\nSince 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.\n\nThroughout 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.\n\nThis 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. \n\n"
  },
  {
    "path": "blog/2019-04-25-helm-3-preview-pt2.md",
    "content": "---\ntitle: \"Helm 3 Preview: Charting Our Future – Part 2: A Gentle Farewell to Tiller\"\nslug: \"helm-3-preview-pt2\"\nauthors: [\"mattfisher\"]\ndate: \"2019-04-25\"\n---\n\nThis 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/).)\n\nDuring 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.<!-- truncate -->\n\nWith 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.\n\nAfter 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.\n\nTiller’s primary goal could be accomplished without Tiller, so one of the first decisions we made regarding Helm 3 was to completely remove Tiller.\n\nWith 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.\n\nRead 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.\n \n"
  },
  {
    "path": "blog/2019-04-29-helm-3-preview-pt3.md",
    "content": "---\ntitle: \"Helm 3 Preview: Charting Our Future – Part 3: Chart Repositories\"\nslug: \"helm-3-preview-pt3\"\nauthors: [\"mattfisher\"]\ndate: \"2019-04-29\"\n---\n\nThis 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/).)\n\nAt 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.<!-- truncate -->\n\nWhile there are several benefits to the Chart Repository API meeting the most basic storage requirements, a few drawbacks have started to show:\n\n- 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.\n- 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.\n- 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.\n- 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.\n\nDocker’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.\n\nBut did you know that the Distribution project was designed to distribute any form of content, not just container images?\n\nThanks 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.\n\nI 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.\n\nYou 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.\n"
  },
  {
    "path": "blog/2019-05-02-helm-3-preview-pt4.md",
    "content": "---\ntitle: \"Helm 3 Preview: Charting Our Future – Part 4: Release Management\"\nslug: \"helm-3-preview-pt4\"\nauthors: [\"mattfisher\"]\ndate: \"2019-05-02\"\n---\n\nThis 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/.).\n\nIn Helm 3, an application's state is tracked in-cluster by a pair of objects:<!-- truncate -->\n\n- The release object: represents an instance of an application\n- The release version secret: represents an application's desired state at a particular instance of time (the release of a new version, for example)\n\nA `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.\n\nThe 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.\n\nThe release version secret ties a release to a series of revisions (install, upgrades, rollbacks, delete).\n\nIn 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.\n\nFor 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.\n\nWith 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\".\n\nSpeaking 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.\n"
  },
  {
    "path": "blog/2019-05-06-helm-3-preview-pt5.md",
    "content": "---\ntitle: \"Helm 3 Preview: Charting Our Future – Part 5: Changes to Chart Dependencies\"\nslug: \"helm-3-preview-pt5\"\nauthors: [\"mattfisher\"]\ndate: \"2019-05-06\"\n---\n\nThis 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/).)\n\nCharts 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.<!-- truncate -->\n\nThe 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.\n\nLet'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.\n\nIn Helm 2, this is how a requirements.yaml looked:\n\n```\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://kubernetes-charts.storage.googleapis.com/\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nIn Helm 3, the same dependency is expressed in your Chart.yaml:\n\n```\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://kubernetes-charts.storage.googleapis.com/\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nCharts are still downloaded and placed in the charts/ directory, so subcharts vendored into the charts/ directory will continue to work without modification.\n\nClick [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.\n"
  },
  {
    "path": "blog/2019-05-09-helm-3-preview-pt6.md",
    "content": "---\ntitle: \"Helm 3 Preview: Charting Our Future – Part 6: Introducing Library Charts\"\nslug: \"helm-3-preview-pt6\"\nauthors: [\"mattfisher\"]\ndate: \"2019-05-09\"\n---\n\nThis 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/).\n\nHelm 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).<!-- truncate -->\n\nLibrary charts are declared in the `dependencies` directive in Chart.yaml, and are installed and managed like any other chart.\n\n```\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nWe'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.\n\nClick [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.\n"
  },
  {
    "path": "blog/2019-05-13-helm-3-preview-pt7.md",
    "content": "---\ntitle: \"Helm 3 Preview: Charting Our Future – Part 7: What's Next?\"\nslug: \"helm-3-preview-pt7\"\nauthors: [\"mattfisher\"]\ndate: \"2019-05-13\"\n---\n\nThis 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/).\n\nHelm 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.<!-- truncate -->\n\nOnce 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.\n\nIn 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.\n\nIf you feel like a topic was missed, we'd love to hear your thoughts!\n\nFeel free to join the discussion in [our Slack channels](https://kubernetes.slack.com):\n\n - `#helm-users` for questions and just to hang out with the community\n - `#helm-dev` for discussing PRs, code, and bugs\n\nYou 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.\n\nTTFN, ta ta for now! \n"
  },
  {
    "path": "blog/2019-06-10-get-helm-sh.md",
    "content": "---\ntitle: \"Announcing get.helm.sh\"\nslug: \"get-helm-sh\"\nauthors: [\"mattfisher\"]\ndate: \"2019-06-10\"\n---\n\nThe Helm Client has long been available to download from Google Cloud Storage at the bucket <https://kubernetes-helm.storage.googleapis.com>. 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!\n\nGoogle 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.<!-- truncate -->\n\nThe 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.\n\n## Where are we now?\n\nThe Helm project now publishes client downloads to <https://get.helm.sh>. 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.\n\nFor backwards compatibility concerns, new releases of Helm 2 will continue to be published at the old URL, however we strongly encourage users to migrate.\n\nGoing 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.\n\n## What do I need to do?\n\nIf you're using the old URL in your CI pipeline, you can replace <https://kubernetes-helm.storage.googleapis.com/kubernetes-helm> with <https://get.helm.sh>.\n\nIf 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.\n\nAll the download URLs in our [GitHub releases](https://github.com/helm/helm/releases) have also been changed to use the new URL.\n\n## What's under the hood?\n\n`get.helm.sh` has three main components:\n\n1. [Azure Blob Storage](https://azure.microsoft.com/en-ca/services/storage/blobs/)\n1. [Azure CDN](https://azure.microsoft.com/en-ca/services/cdn/)\n1. The domain name `get.helm.sh`\n\nIn 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.\n\n## Why the new location?\n\nAs part of the move, we started considering some new features the community has been asking for:\n\n### An official helm.sh URL\n\nDuring 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.\n\n### Content delivery at the edge\n\n<https://get.helm.sh> 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.\n\nIt also provides availability in regions that were previously unavailable, such as...\n\n### Availability in China\n\nChina 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.\n\nThis 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.\n\nAzure 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...\n\n### Download metrics\n\nOne 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:\n\n- what versions of Helm are being used?\n- what regions of the world are using Helm today?\n- How long does it take for the community to migrate over to a new version of Helm?\n- How many users are downloading Helm 3 vs Helm 2?\n\nOur new CDN provides a rich set of metrics can provide answers to these questions.\n\nWhile 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 <https://devstats.cncf.io/>.\n\n## Caveat: Tiller and Chart downloads\n\nPlease 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.\n\n\nIf 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).\n"
  },
  {
    "path": "blog/2019-08-27-helm-v3-beta.md",
    "content": "---\ntitle: \"Helm v3 Beta 1 Released\"\nslug: \"helm-v3-beta\"\nauthors: [\"mattfarina\"]\ndate: \"2019-08-27\"\n---\n\nHelm 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.\n\nIf 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.<!-- truncate -->\n\n## Notable changes since Helm v2\n\n* 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.\n* 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.\n* 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.\n* 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.\n* 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).\n* The `helm search` command has been refactored to have sub-commands that can search the local repositories and the Helm Hub.\n* 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.\n* JSON schemas can now be imposed on chart values and bundled with the chart. The schemas can be used for validating chart values.\n* A new API version of charts are available. This new `apiVersion` is `v2` and contains several changes including:\n  * Requirements are now listed in the `Chart.yaml` file instead of the `requirements.yaml` file.\n  * 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.\n* 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.\n* 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.\n* 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.\n* `helm serve` has been removed.\n* 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.\n* `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.\n* Several CLI changes have happened for usability including:\n  * `helm inspect` is now `helm show`\n  * `helm fetch` is now `helm pull`\n  * `helm delete` is now `helm uninstall`\n  * Instead of using the `--purge` flag on `helm uninstall` the behavior is to use the `--keep-history` if you want to keep the history.\n\n## Helm v3 Next Steps\n\nThe 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.\n"
  },
  {
    "path": "blog/2019-09-11-migrate-from-helm-v2-to-helm-v3.md",
    "content": "---\ntitle: \"How to migrate from Helm v2 to Helm v3\"\nslug: \"migrate-from-helm-v2-to-helm-v3\"\nauthors: [\"rimasmocevicius\"]\ndate: \"2019-09-11\"\n---\n\n\n![Diagram how to migrate from Helm 2 to 3](images/helm-2to3.png)\n\nOne 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.\n<!-- truncate -->\n\nIt helps with this migration by supporting:\n\n- Migration of Helm v2 configuration.\n- Migration of Helm v2 releases.\n- Clean up Helm v2 configuration, release data and Tiller deployment.\n\n## Setting up Helm v3\n\nAs 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:\n\nDownload latest Helm v3 release from [here](https://github.com/helm/helm/releases), rename the binary to `helm3` and store it in your path.\n\nWe are ready to use `helm3`:\n\n```\n$ helm3 repo list\nError: no repositories to show\n```\n\nAs you see there are no repositories set as Helm v3 comes without `stable` repository setup by default, let's fix it up.\n\n## helm-2to3 plugin\n\n`helm-2to3` plugin will allow us to migrate and cleanup Helm v2 configuration and releases to Helm v3 in-place.\n\nInstalled Kubernetes objects will not be modified or removed.\n\n### Installing\n\nLet's install it:\n\n```\n$ helm3 plugin install https://github.com/helm/helm-2to3\nDownloading and installing helm-2to3 v0.2.0 ...\nhttps://github.com/helm/helm-2to3/releases/download/v0.2.0/helm-2to3_0.2.0_darwin_amd64.tar.gz\nInstalled plugin: 2to3\n```\n\n```\n$ helm3 plugin list\nNAME  \tVERSION\tDESCRIPTION\n2to3  \t0.2.0  \tmigrate and cleanup Helm v2 configuration and releases in-place to Helm v3\n```\n\n```\n$ helm3 2to3\nMigrate and Cleanup Helm v2 configuration and releases in-place to Helm v3\n\nUsage:\n  2to3 [command]\n\nAvailable Commands:\n  cleanup     cleanup Helm v2 configuration, release data and Tiller deployment\n  convert     migrate Helm v2 release in-place to Helm v3\n  help        Help about any command\n  move        migrate Helm v2 configuration in-place to Helm v3\n\nFlags:\n  -h, --help   help for 2to3\n\nUse \"2to3 [command] --help\" for more information about a command.\n```\n\nAwesome.\n\n### Plugin features\n\nCurrently plugin supports:\n\n- Migration of Helm v2 configuration\n- Migration of Helm v2 releases\n- Clean up Helm v2 configuration, release data and Tiller deployment\n\n## Migrate Helm v2 configuration\n\nFirst we need to migrate Helm v2 config and data folders:\n\n```\n$ helm3 2to3 move config -h\nmigrate Helm v2 configuration in-place to Helm v3\n\nUsage:\n  2to3 move config [flags]\n\nFlags:\n      --dry-run   simulate a command\n  -h, --help      help for move\n```\n\nIt will migrate:\n\n- Chart starters\n- Repositories\n- Plugins\n\nThe safest way is to start with --dry-run flag:\n\n```\n$ helm3 2to3 move config --dry-run\n2019/11/14 14:54:04 NOTE: This is in dry-run mode, the following actions will not be executed.\n2019/11/14 14:54:04 Run without --dry-run to take the actions described below:\n2019/11/14 14:54:04\n2019/11/14 14:54:04 WARNING: Helm v3 configuration maybe overwritten during this operation.\n2019/11/14 14:54:04\n[Move Config/confirm] Are you sure you want to move the v2 configuration? [y/N]: y\n2019/11/14 14:54:12\nHelm v2 configuration will be moved to Helm v3 configuration.\n2019/11/14 14:54:12 [Helm 2] Home directory: /Users/rimas/.helm\n2019/11/14 14:54:12 [Helm 3] Config directory: /Users/rimas/Library/Preferences/helm\n2019/11/14 14:54:12 [Helm 3] Data directory: /Users/rimas/Library/helm\n2019/11/14 14:54:12 [Helm 3] Create config folder \"/Users/rimas/Library/Preferences/helm\" .\n2019/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\" .\n2019/11/14 14:54:12 [Helm 3] Create data folder \"/Users/rimas/Library/helm\" .\n2019/11/14 14:54:12 [Helm 2] plugins \"/Users/rimas/.helm/plugins\" will copy to [Helm 3] data folder \"/Users/rimas/Library/helm/plugins\" .\n2019/11/14 14:54:12 [Helm 2] starters \"/Users/rimas/.helm/starters\" will copy to [Helm 3] data folder \"/Users/rimas/Library/helm/starters\" .\n```\n\nCool, now let's do the actual migration:\n\n```\n$ helm3 2to3 move config\nWARNING: Helm v3 configuration maybe overwritten during this operation.\n\n[Move Config/confirm] Are you sure you want to move the v2 configuration? [y/N]: y\n\n2019/11/14 14:55:00 Helm v2 configuration will be moved to Helm v3 configuration.\n2019/11/14 14:55:00 [Helm 2] Home directory: /Users/rimas/.helm\n2019/11/14 14:55:00 [Helm 3] Config directory: /Users/rimas/Library/Preferences/helm\n2019/11/14 14:55:00 [Helm 3] Data directory: /Users/rimas/Library/helm\n2019/11/14 14:55:00 [Helm 3] Create config folder \"/Users/rimas/Library/Preferences/helm\" .\n2019/11/14 14:55:00 [Helm 3] Config folder \"/Users/rimas/Library/Preferences/helm\" created.\n2019/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\" .\n2019/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\" .\n2019/11/14 14:55:00 [Helm 3] Create data folder \"/Users/rimas/Library/helm\" .\n2019/11/14 14:55:00 [Helm 3] data folder \"/Users/rimas/Library/helm\" created.\n2019/11/14 14:55:00 [Helm 2] plugins \"/Users/rimas/.helm/plugins\" will copy to [Helm 3] data folder \"/Users/rimas/Library/helm/plugins\" .\n2019/11/14 14:55:00 [Helm 2] plugins \"/Users/rimas/.helm/plugins\" copied successfully to [Helm 3] data folder \"/Users/rimas/Library/helm/plugins\" .\n2019/11/14 14:55:00 [Helm 2] starters \"/Users/rimas/.helm/starters\" will copy to [Helm 3] data folder \"/Users/rimas/Library/helm/starters\" .\n2019/11/14 14:55:00 [Helm 2] starters \"/Users/rimas/.helm/starters\" copied successfully to [Helm 3] data folder \"/Users/rimas/Library/helm/starters\" .\n2019/11/14 14:55:00 Helm v2 configuration was moved successfully to Helm v3 configuration.\n```\n\nNow let's run `helm3 repo list` again:\n\n```\n$ helm3 repo list\nNAME       \tURL\nstable     \thttps://kubernetes-charts.storage.googleapis.com\njfrog      \thttps://charts.jfrog.io\nrimusz     \thttps://charts.rimusz.net\nbuildkite  \thttps://buildkite.github.io/charts\njetstack   \thttps://charts.jetstack.io\nodavid     \thttps://odavid.github.io/k8s-helm-charts\nelastic    \thttps://helm.elastic.co\nappscode   \thttps://charts.appscode.com/stable\n\n$ helm3 plugin list\nNAME   \tVERSION\tDESCRIPTION\n2to3   \t0.1.0  \tmigrate Helm v2 configuration and releases in-place to Helm v3\nedit   \t0.3.0  \tEdit a release.\ngcs    \t0.2.0  \tProvides Google Cloud Storage protocol support.\n       \t       \thttps://github.com/vigles...\nlinter \t0.1.1  \tHelm plugin to find hardcoded passwords in values.yaml files\nmonitor\t0.3.0  \tQuery at a given interval a Prometheus, ElasticSearch or Sentry instance...\n```\n\nNice, now I can use the same Helm repositories and plugins which I have in Helm v2.\n\n**Note:** Please check that all Helm v2 plugins work fine with the Helm v3, and remove plugins that do not work.\n\nThe 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.\n\nThe plugin also supports non default Helm v2 `home` and Helm v3 `config` and `data` folders, an example of it's use:\n\n```\n$ export HELM_V2_HOME=$HOME/.helm2\n$ export HELM_V3_CONFIG=$HOME/.helm3\n$ export HELM_V3_DATA=$PWD/.helm3\n$ helm3 2to3 move config\n```\n\n## Migrate Helm v2 releases\n\nNow we are ready to start migrating releases.\n\nLet's check available options:\n\n```\n$ helm3 2to3 convert -h\nmigrate Helm v2 release in-place to Helm v3\n\nUsage:\n  2to3 convert [flags] RELEASE\n\nFlags:\n      --delete-v2-releases         v2 release versions are deleted after migration. By default, the v2 release versions are retained\n      --dry-run                    simulate a command\n  -h, --help                       help for convert\n  -l, --label string               label to select Tiller resources by (default \"OWNER=TILLER\")\n  -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\")\n      --release-versions-max int   limit the maximum number of versions converted per release. Use 0 for no limit (default 10)\n  -t, --tiller-ns string           namespace of Tiller (default \"kube-system\")\n      --tiller-out-cluster         when  Tiller is not running in the cluster e.g. Tillerless\n```\n\nNice, the plugin even supports the [Tillerless Helm v2](https://github.com/rimusz/helm-tiller).\n\nLet's check out for Helm v2 releases and pick one to test out the migration:\n\n```\n$ helm list\n\nNAME    \tREVISION\tUPDATED                 \tSTATUS  \tCHART           \tAPP VERSION\tNAMESPACE\npostgres\t1       \tThu Nov 14 15:01:00 2019\tDEPLOYED\tpostgresql-7.1.0\t11.5.0     \tpostgres\nredis   \t1       \tThu Nov 14 15:02:12 2019\tDEPLOYED\tredis-9.5.4     \t5.0.6      \tredis\n```\n\nThe safest way of course to start with `--dry-run` flag:\n\n```\n$ helm3 2to3 convert --dry-run postgres\n2019/11/14 15:03:17 NOTE: This is in dry-run mode, the following actions will not be executed.\n2019/11/14 15:03:17 Run without --dry-run to take the actions described below:\n2019/11/14 15:03:17\n2019/11/14 15:03:17 Release \"postgres\" will be converted from Helm v2 to Helm v3.\n2019/11/14 15:03:17 [Helm 3] Release \"postgres\" will be created.\n2019/11/14 15:03:17 [Helm 3] ReleaseVersion \"postgres.v1\" will be created.\n```\n\nNow, let's run the actual migration:\n\n```\n$ helm3 2to3 convert postgres\n2019/11/14 15:03:57 Release \"postgres\" will be converted from Helm v2 to Helm v3.\n2019/11/14 15:03:57 [Helm 3] Release \"postgres\" will be created.\n2019/11/14 15:03:57 [Helm 3] ReleaseVersion \"postgres.v1\" will be created.\n2019/11/14 15:03:57 [Helm 3] ReleaseVersion \"postgres.v1\" created.\n2019/11/14 15:03:57 [Helm 3] Release \"postgres\" created.\n2019/11/14 15:03:57 Release \"postgres\" was converted successfully from Helm v2 to Helm v3.\n2019/11/14 15:03:57 Note: The v2 release information still remains and should be removed to avoid conflicts with the migrated v3 release.\n2019/11/14 15:03:57 v2 release information should only be removed using `helm 2to3` cleanup and when all releases have been migrated over.\n```\n\nCheck out whether it was successful:\n\n```\n$ helm list\nNAME    \tREVISION\tUPDATED                 \tSTATUS  \tCHART           \tAPP VERSION\tNAMESPACE\npostgres\t1       \tThu Nov 14 15:01:00 2019\tDEPLOYED\tpostgresql-7.1.0\t11.5.0     \tpostgres\nredis   \t1       \tThu Nov 14 15:02:12 2019\tDEPLOYED\tredis-9.5.4     \t5.0.6      \tredis\n\n$ helm3 list -n postgres\nNAME    \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART           \tAPP VERSION\npostgres\tpostgres \t1       \t2019-11-14 13:01:00.188487 +0000 UTC\tdeployed\tpostgresql-7.1.0\t11.5.0\n```\n\n**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.\n\nWhen 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.\n\nIf you are using Tillerless Helm v2, just add `--tiller-out-cluster` to migrate the release:\n\n```\n$ helm3 2to3 convert postgres --tiller-out-cluster\n```\n\nVery cool and simple, right :-)\n\n## Clean up of Helm v2 data\n\nThe last step is cleaning up the old data. While this is not required, we strongly recommend it.\n\nLet's check available options:\n\n```\n$ helm3 2to3 cleanup -h\ncleanup Helm v2 configuration, release data and Tiller deployment\n\nUsage:\n  2to3 cleanup [flags]\n\nFlags:\n      --config-cleanup           if set, configuration cleanup performed\n      --dry-run                  simulate a command\n  -h, --help                     help for cleanup\n  -l, --label string             label to select Tiller resources by (default \"OWNER=TILLER\")\n      --release-cleanup          if set, release data cleanup performed\n  -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\")\n      --tiller-cleanup           if set, Tiller cleanup performed\n  -t, --tiller-ns string         namespace of Tiller (default \"kube-system\")\n      --tiller-out-cluster       when  Tiller is not running in the cluster e.g. Tillerless\n```\n\nIt will clean:\n- Configuration (Helm home directory)\n- v2 release data\n- Tiller deployment\n\nAnd of course the safest way is to start with `--dry-run` flag:\n\n```\n$ helm3 2to3 cleanup --dry-run\n2019/11/14 15:06:59 NOTE: This is in dry-run mode, the following actions will not be executed.\n2019/11/14 15:06:59 Run without --dry-run to take the actions described below:\n2019/11/14 15:06:59\nWARNING: \"Helm v2 Configuration\" \"Release Data\" \"Release Data\" will be removed.\nThis 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.\nHelm v2 may not be usable afterwards.\n\n[Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: y\n2019/11/14 15:07:01\nHelm v2 data will be cleaned up.\n2019/11/14 15:07:01 [Helm 2] Releases will be deleted.\n2019/11/14 15:07:01 [Helm 2] ReleaseVersion \"postgres.v1\" will be deleted.\n2019/11/14 15:07:01 [Helm 2] ReleaseVersion \"redis.v1\" will be deleted.\n2019/11/14 15:07:01 [Helm 2] Home folder \"/Users/rimasm/.helm\" will be deleted.\n```\n\nIt 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.\n\nWhen you are ready to clean up Hem v2 data, just run that command without `--dry-run` flag.\n\n**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.\n\nIf you are using Tillerless Helm v2, just add `--tiller-out-cluster` to clean up Helm v2 data.\n\nThe plugin also supports non default Helm v2 `home` data folder and Tiller releases `namespace`:\n\n```\n$ export HELM_V2_HOME=$PWD/.helm2\n$ helm 2to3 cleanup --tiller-ns some_namespace\n```\n\n**Happy Helm v3 sailing**\n"
  },
  {
    "path": "blog/2019-10-22-helm-2150-released.md",
    "content": "---\ntitle: \"Helm 2.15.0 Released\"\nauthors: [\"mattfisher\"]\ndate: \"2019-10-22\"\n---\n\n[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.\n\nIn 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.\n\nAs 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.<!-- truncate -->\n\n## Helm 2 support plan\n\nDuring 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.\n\nFor 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.\n\n6 months after Helm 3's public release, Helm 2 will stop accepting bug fixes. Only security issues will be accepted.\n\n12 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`.\n\n## The big branch switch\n\nEver 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.\n\nWith Helm 2 transitioning into maintenance mode, now was a good opportunity to switch branches over.\n\nEarlier 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.\n\n## Parting thoughts\n\nThe 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.\n\nOnwards and upwards!\n"
  },
  {
    "path": "blog/2019-10-30-helm-symlink-security-notice.md",
    "content": "---\ntitle: \"Helm Vulnerability: Client Loading and Packaging Chart Directory Containing Malicious Symlinked Content [CVE-2019-18658]\"\nauthors: [\"mattfarina\"]\ndate: \"2019-10-30\"\n---\n\nPart 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.\n\nThe 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.<!-- truncate -->\n\nNo version of Tiller is known to be impacted. This is a client-only issue.\n\nThe following Helm commands may unsafely handle malformed charts: `helm package`, `helm install`, `helm upgrade`, and `helm dependency build`.\n\nWe are unaware of any public exploits caused by this issue.\n\n## Details\n\nHelm 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.\n\n1. 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.\n2. 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.\n\nNo Tiller version is impacted. This vulnerability does not render clusters vulnerable to attack. Tiller does not load chart directories.\n\n## Workarounds\n\nA 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.\n\n## Fix\n\nUpdate to Helm >= 2.15.2.\n\nAs 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).\n"
  },
  {
    "path": "blog/2019-11-04-helm-security-audit-results.md",
    "content": "---\ntitle: \"Helm Security Audit Results\"\nauthors: [\"mattfarina\"]\ndate: \"2019-11-04\"\n---\n\nToday, 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.\n\nA 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:\n\n> 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.<!-- truncate -->\n\nDuring 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.\n\nA [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:\n\n* The programming language used along with patterns and the use of external libraries\n* Access control which is different in Helm v3 than in Helm v2 due to the removal of Tiller\n* How logging and monitoring are handled\n* Unit and regression testing\n* Documentation, including the security contacts and process\n* The process for fixing security issues\n* The software used for signing and verification of Helm charts\n* Manipulation of chart files\n* TLS handling for communications\n\nFrom 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.\n\nThe [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:\n\n> 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.\n\nSecurity 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.\n"
  },
  {
    "path": "blog/2019-11-11-community-management.md",
    "content": "---\ntitle: \"Helm Community Management\"\nauthors: [\"mattfarina\"]\ndate: \"2019-11-11\"\n---\n\n[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.\n\nKaren 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).<!-- truncate -->\n\nUntil 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.\n\nCommunity 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!\n\nIf 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).\n"
  },
  {
    "path": "blog/2019-11-13-helm-3-released.md",
    "content": "---\ntitle: \"Helm 3.0.0 has been released!\"\nslug: \"helm-3-released\"\nauthors: [\"mattfisher\"]\ndate: \"2019-11-13\"\n---\n\nThe Helm Team is proud to announce the first stable release of Helm 3.\n\nHelm 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.<!-- truncate -->\n\nThe 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.\n\nAdditionally, 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/).\n\nHere are some Helm 3 resources:\n\n- [Documentation](https://helm.sh/docs/)\n- [FAQ: Changes since Helm 2](https://helm.sh/docs/faq/#changes-since-helm-2)\n- [Installing Helm](https://helm.sh/docs/intro/install/)\n- [Documentation on Helm 2 to Helm 3 migration](https://helm.sh/docs/topics/v2_v3_migration/)\n- [Plugin to help migrate from Helm 2 to Helm 3](https://github.com/helm/helm-2to3)\n- Chat with developers and contributors in the [#helm-users Kubernetes Slack channel](https://slack.k8s.io/)\n- Please report bugs at <https://github.com/helm/helm/issues>\n\n## What is Helm?\n\nHelm gives teams the tools they need to collaborate when creating, installing, and managing applications inside of Kubernetes.\n\nWith Helm, you can...\n\n- Find prepackaged software (charts) to install and use\n- Easily create and host your own packages\n- Install packages into any Kubernetes cluster\n- Query the cluster to see what packages are installed and running\n- Update, delete, rollback, or view the history of installed packages\n\nHelm makes it easy to run applications inside Kubernetes.\n\n## Let's see it!\n\nAssuming you have a Kubernetes cluster running and a correctly configured `kubectl`, working with Helm is a piece of cake.\n\nHelm makes it easy to search for new charts by adding repositories hosted by the community.\n\n```bash\n$ helm repo add nginx https://helm.nginx.com/stable\n```\n\nOnce you've added a few repositories, you can search for charts:\n\n```bash\n$ helm search repo nginx-ingress\nNAME                    CHART VERSION   APP VERSION     DESCRIPTION\nnginx/nginx-ingress     0.3.7           1.5.7           NGINX Ingress Controller\n```\n\nHelm gives you a quick way to install that chart with `helm install`:\n\n```bash\n$ helm install my-ingress-controller nginx/nginx-ingress\n```\n\nIf we inspect the cluster with `kubectl`:\n\n```bash\n$ kubectl get deployments\n```\n\nWe have an ingress controller running! We can just as easily remove it with `helm uninstall my-ingress-controller`.\n\nOkay. 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.\n\n```bash\n$ helm create diy\nCreating diy\n```\n\nNow 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`.\n\nWant 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.\n\n## What changed in Helm 3?\n\nYou may be asking yourself at this point:\n\n> How did the workflow change from Helm 2? If I run those commands with Helm 2, will I see the same output?\n\nHelm 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.\n\nIf you're comfortable with Helm 2, you'll feel right at home with Helm 3.\n\nTo 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.\n\n## The Future of Helm\n\nThe 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:\n\n- Enhanced functionality for `helm test`\n- Improvements to Helm's OCI integration\n- Enhanced functionality for the Go client libraries\n\n### Helm 2 Support Plan\n\nIn 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/).\n\n## Relation of Helm 3 to Helm 1 and 2\n\nIn 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.\n\nA 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.\n\nIn 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.\n\n## Conclusion\n\nWe 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.\n\nOver 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.\n\nThank you all, and see you on GitHub!\n\n- The Helm Team :heart:"
  },
  {
    "path": "blog/2019-11-15-helm-at-cloudnativecon.md",
    "content": "---\ntitle: \"Helm at KubeCon + CloudNativeCon NA 2019\"\nauthors: [\"mattfarina\"]\ndate: \"2019-11-15\"\n---\n\nNext 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.<!-- truncate -->\n\nHelm 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!\n\nThis 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.\n\nThere 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/).\n\nGoing 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/)."
  },
  {
    "path": "blog/2020-04-02-covid-19-extending-helm-v2-bug-fixes.md",
    "content": "---\ntitle: \"COVID-19: Extending Helm v2 Bug Fixes\"\nslug: \"covid-19-extending-helm-v2-bug-fixes\"\ndate: \"2020-04-03\"\n---\n\nAs 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.<!-- truncate -->\n\nWhen 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.\n\nWe 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!\n"
  },
  {
    "path": "blog/2020-04-30-celebrating-helms-cncf-graduation.md",
    "content": "---\ntitle: \"Celebrating Helm's CNCF Graduation\"\nslug: \"celebrating-helms-cncf-graduation\"\nauthors: [\"mattbutcher\"]\ndate: \"2020-04-30\"\n---\n\n![images/helmgraduation.png](images/helmgraduation.png)\n\nToday 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.<!-- truncate -->\n\nGiven 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.\n\nSeveral 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.\n\nThese 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.\n\nBe 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.\n\nAt 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.\n\nThe 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.\n\nCNCF 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.\n\nAnd 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.\n\nSo 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.\n\nWe 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!\n\n\n"
  },
  {
    "path": "blog/2020-08-13-helm-v2-deprecation-timeline.md",
    "content": "---\ntitle: \"Helm v2 Deprecation Timeline\"\nslug: \"helm-v2-deprecation-timeline\"\nauthors: [\"bridgetkromhout\"]\ndate: \"2020-08-12\"\n---\n\n\n_[with a nod to Lewis Carroll...](https://www.jabberwocky.com/carroll/walrus.html)_\n\n    “The time has come,” the maintainers said,\n      “To talk of software fates:\n    Of upgrades -- and shipping Helm v3 --\n      Of bugfixes -- and k8s --”\n\n[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.\n<!-- truncate -->\n\nWe 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).\n\n## What does this mean for Helm users?\n\n_After August 13, 2020, you will see these changes:_\n- 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.\n- 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.\n- 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).\n\n\n_After November 13, 2020, you will see these changes:_\n- No further Helm v2 releases (even for security patches)\n- No further updates to [Helm v2 documentation](https://v2.helm.sh/docs), which will remain available for the present time but may be discontinued\n- Existing and new issues/PRs that are v2-specific will be closed\n- [Transitioning Helm release and chart hosting ownership to CNCF](https://github.com/helm/community/issues/114)\n\n| | |\n| - | - |\n| To Be Removed | Replacement |\n| Download links for the Helm v2 client through Google Cloud Storage | Client downloads through [get.helm.sh](/blog/get-helm-sh/)|\n| 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. |\n| Google Cloud buckets for the stable and incubator chart repositories | “Stable” and “incubator” repositories discontinued; https://github.com/helm/charts marked as obsolete |\n\nThe 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.\n\nWe 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!\n"
  },
  {
    "path": "blog/2020-10-07-helm-hub-moving-artifact-hub.md",
    "content": "---\ntitle: \"Helm Hub Moving To Artifact Hub\"\nslug: \"helm-hub-moving-to-artifact-hub\"\nauthors: [\"mattfarina\"]\ndate: \"2020-10-07\"\n---\n\nToday, 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.<!-- truncate -->\n\n## What This Means For You\n\nIf you search the Helm Hub or list your charts in the Helm Hub you might wonder, what does this mean for me?\n\nThe 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.\n\nThere 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.\n\nIf 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.\n\n## Why We Are Doing This\n\nThe 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.\n\nThe 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.\n\n## Questions, Concerns, or Issues\n\nIf you experience issues with the changeover please let us know. There are a few ways you can do this:\n\n1. 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).\n2. 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.\n3. 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.\n"
  },
  {
    "path": "blog/2020-10-19-helm-turns-five.md",
    "content": "---\ntitle: \" Helm Turns 5, and GitHub Gives the Gift of Charts\"\nslug: \"helm-turns-five\"\nauthors: [\"mattbutcher\", \"mattfarina\"]\ndate: \"2020-10-19\"\n---\n\n![Happy 5th Birthday Helm](images/happy-5th.png)\n\nFive years ago, in a hackathon at Deis (who has since been acquired by Microsoft) Helm was born.<!-- truncate -->\n\n```\ncommit ecad6e2ef9523a0218864ec552bbfc724f0b9d3d\nAuthor: Matt Butcher <mbutcher@engineyard.com>\nDate:   Mon Oct 19 17:43:26 2015 -0600\n\n    initial add\n```\n\n[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.\n\nSince 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.\n\nBut 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.\n\nRecently, 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.\n\n![Hello Github Octocat!](images/octocat.png)\n\nSo 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!\n\nWe 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.\n\nWhile 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.\n\nWe are deeply appreciative of GitHub’s tooling and their support for open source projects of all sizes.\n\nHappy Birthday, Helm!\n"
  },
  {
    "path": "blog/2020-10-26-new-location-stable-incubator-charts.md",
    "content": "---\ntitle: \"New Location For Stable and Incubator Charts\"\nslug: \"new-location-stable-incubator-charts\"\nauthors: [\"mattfarina\"]\ndate: \"2020-10-26\"\n---\n\n[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.\n\n_**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._<!-- truncate -->\n\nThe 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.\n\n| Name      | Old Location | New Location |\n| --------- | ------------ | ------------ |\n| stable    | https://kubernetes-charts.storage.googleapis.com | https://charts.helm.sh/stable |\n| incubator | https://kubernetes-charts-incubator.storage.googleapis.com | https://charts.helm.sh/incubator |\n\n\nAlong 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.\n\n## Helm v3.4.0\n\nHelm 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:\n\n```\nhelm repo add stable https://charts.helm.sh/stable --force-update\n```\n\nThis 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.\n\nIn 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.\n\n## Helm v2.17.0\n\nHelm 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.\n\nIf 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.\n\nIn 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.\n\nIf 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:\n\n```\nhelm repo rm stable\nhelm repo add stable https://charts.helm.sh/stable\n```\n\nThis command will work on Helm v2 versions prior to v2.17.0. You can use it without updating to the latest Helm v2 release.\n\n_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`._\n\n## Host Your Own Copy\n\nThere 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.\n\nScott 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.\n\nIn Helm v2, you can specify an alternative location for the stable repository when running `helm init` by using the `--stable-repo-url` flag.\n"
  },
  {
    "path": "blog/2020-10-30-charts-repo-deprecation.md",
    "content": "---\ntitle: \"Helm Chart Repository Deprecation Update\"\nslug: \"charts-repo-deprecation\"\nauthors: [\"viciglesias\"]\ndate: \"2020-10-30\"\n---\n\nBack 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.<!-- truncate -->\n\nWhen 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:\n\n- [Chart Testing](https://github.com/helm/chart-testing) provides linting and testing for PRs against your charts\n- [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\n- [Testing and Releasing Github Actions](https://github.com/helm?q=chart+action) to automate the tooling described above using GitHub Actions\n\nWith these tools available we've enabled many charts to [migrate to their own repositories](https://github.com/helm/charts/issues/21103) for active maintenance.\n\n## Key Dates and Recommended Actions\n\nThere 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:\n\n* Nov 2, 2020 - READMEs for all non-deprecated charts will get a note added, stating that they will no longer be updated\n    * **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.\n* Nov 6, 2020 the stable and incubator charts repos will be removed from the [Artifact Hub](https://artifacthub.io/)\n    * **RECOMMENDED ACTION** - None\n* 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.\n    * **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).\n* *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.\n    * **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.\n\n\n## References\n\n* [Charts Repo Deprecation Timeline](https://github.com/helm/charts/issues/23944)\n* [Relocation of package history](https://github.com/helm/charts/issues/23850)\n* [Request to transition Helm Chart hosting to CNCF](https://github.com/helm/community/issues/114)\n"
  },
  {
    "path": "blog/2020-11-11-helm-release-process.md",
    "content": "---\ntitle: \"Helm’s First Patch Wednesday\"\nslug: \"helm-release-process\"\nauthors: [\"mattfarina\"]\ndate: \"2020-11-11\"\n---\n\nHelm 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.<!-- truncate -->\n\nThe release schedule generally follows these rules:\n\n* 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.\n* 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.\n* 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.\n* Security releases do not need to follow any of these rules. They will be released as needed.\n\nA 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.\n\nMore details can be found in [Helm Improvement Proposal 2](https://github.com/helm/community/blob/main/hips/hip-0002.md).\n"
  },
  {
    "path": "blog/2020-11-13-helm-2-becomes-unsupported.md",
    "content": "---\ntitle: \"Helm 2 and the Charts Project Are Now Unsupported\"\nslug: \"helm-2-becomes-unsupported\"\nauthors: [\"mattbutcher\"]\ndate: \"2020-11-13\"\n---\n\nA 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.\n\nHere 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.<!-- truncate -->\n\nFrom this point forward, the Helm team will devote all of its energy to Helm 3 and our ecosystem tools.\n\nIn practice, this means the following:\n\n- **Helm 2** will receive no more updates (not even security patches).\n- The **Helm Charts** [GitHub project](https://github.com/helm/charts) will receive no more updates.\n- 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.\n- **Helm 3** will [continue](https://github.com/helm/helm/releases) to add new features, fix bugs, and address security issues.\n- [Other Helm projects](https://github.com/helm) like our **GitHub actions** will continue feature development as well.\n- **Artifact Hub** is now the official location for [finding Helm charts](https://artifacthub.io/).\n\nWe 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/).\n\nFinally, 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."
  },
  {
    "path": "blog/2021-03-05-second-security-audit/index.md",
    "content": "---\ntitle: \"Helm 2nd Security Audit\"\nslug: \"helm-2nd-security-audit\"\nauthors: [\"mattfarina\"]\ndate: \"2021-03-05\"\n---\n\nHelm 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.<!-- truncate -->\n\nThe 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.\n\n![Thread model diagram](arch.png)\n\nAs a result of the audit, the Helm security team worked on [a release](https://github.com/helm/helm/releases/tag/v3.3.2).\n\nWe 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.\n\nYou 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).\n"
  },
  {
    "path": "blog/2021-06-24-welcome-martin-hickey.md",
    "content": "---\ntitle: \"Martin Hickey Joins Helm Org Maintainers\"\nslug: \"welcome-martin-hickey\"\nauthors: [\"mattbutcher\"]\ndate: \"2021-06-24\"\n---\n\nMeet 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).<!-- truncate -->\n\nThis 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.\n\nCongratulations to Martin!\n"
  },
  {
    "path": "blog/2022-01-11-welcome-karen-chu.md",
    "content": "---\ntitle: \"Karen Chu Joins Helm Org Maintainers\"\nslug: \"welcome-karen-chu\"\nauthors: [\"mattbutcher\"]\ndate: \"2022-01-11\"\n---\n\nThe 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.<!-- truncate -->\n\nLast 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.\n\nCongratulations to Karen!"
  },
  {
    "path": "blog/2022-02-28-storing-charts-in-oci.md",
    "content": "---\ntitle: \"Storing Helm Charts in OCI Registries\"\nslug: \"storing-charts-in-oci\"\nauthors: [\"scottrigby\", \"joshdolitsky\", \"mattfarina\"]\ndate: \"2022-02-28\"\n---\n\nWith 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.\n\n<!-- truncate -->\n\nOver 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.\n\n<!-- ## What Does This Mean For Me? -->\n\n## Common Storage\n\nSince 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.\n\n## Working With Charts In Registries\n\nThe 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:\n\n```text\n$ helm create demo\nCreating demo\n\n$ helm package demo\nSuccessfully packaged chart and saved it to: /tmp/demo-0.1.0.tgz\n\n$ echo \"mypass\" | helm registry login r.example.com -u myuser --password-stdin\nLogin Succeeded\n\n$ helm push demo-0.1.0.tgz oci://r.example.com/myuser\nPushed: r.example.com/myuser/demo:0.1.0\nDigest: sha256:7ed393daf1ffc94803c08ffcbecb798fa58e786bebffbab02da5458f68d0ecb0\n```\n\nMore detail on [working with registries can be found in the Helm documentation](https://helm.sh/docs/topics/registries/).\n\n## The Helm SDK\n\nThe 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:\n\n```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"io/ioutil\"\n\n\t\"helm.sh/helm/v3/pkg/registry\"\n)\n\nfunc check(err error) {\n\tif err != nil {\n\t\tpanic(err)\n\t}\n}\n\nfunc main() {\n\tclient, err := registry.NewClient()\n\tcheck(err)\n\n\tb, err := ioutil.ReadFile(\"demo-0.1.0.tgz\")\n\tcheck(err)\n\n\tinfo, err := client.Push(b, \"r.example.com/myuser/demo:0.1.0\")\n\tcheck(err)\n\n\tfmt.Printf(\"Pushed: %s\\n\", info.Ref)\n\tfmt.Printf(\"Digest: %s\\n\", info.Manifest.Digest)\n}\n```\n\nMore detail can be found in the [documentation for the registry package](https://pkg.go.dev/helm.sh/helm/v3/pkg/registry).\n\n## Limitations\n\nThere are some limitations when using registries to store charts compared to Helm repositories or storing container images in registries.\n\nHelm 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.\n\nWhile 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.\n\n## Artifact Hub Support\n\n[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).\n\n## ORAS\n\nThe [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:\n\n> 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.\n\nIf you want to work with other artifacts in registries the ORAS project may provide some tools to help you.\n\n## Thanks and Help Us Keep Improving\n\nThanks 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.\n\nWe 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!\n"
  },
  {
    "path": "blog/2022-04-19-tools-to-manage-helm-declaratively.md",
    "content": "---\ntitle: \"Tools You Can Use To Manage Your Helm Releases Declaratively\"\nslug: \"tools-to-manage-helm-declaratively\"\nauthors: [\"scottrigby\", \"mattfarina\"]\ndate: \"2022-04-19\"\n---\n\nWe 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.\n\n<!-- truncate -->\n\n## Why Helm Doesn't Have Tools To Do This\n\nYou might wonder, why doesn't Helm provide tools to do this out of the box?\n\nHelm 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.\n\nManaging 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._\n\nThe 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.\n\n## Declarative and Imperative\n\nIn the Kubernetes space we talk about _declarative_ management. If you're not familiar with the concept, here is a brief explanation.\n\nWith 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.\n\nImperative 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.\n\nKubernetes 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.\n\n## Tools\n\nThe 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/).\n\n### CNCF Projects\n\nThe 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:\n\n* [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.\n* [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.\n\n### Other Projects\n\nThere 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.\n\n* [Helmfile](https://github.com/helmfile/helmfile) - A declarative spec for deploying Helm charts.\n* [Captain](https://github.com/alauda/captain) - A Helm controller.\n* [Terraform Helm provider](https://github.com/hashicorp/terraform-provider-helm) - Enables you to manage Helm charts through Terraform.\n* [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.\n* [Fleet](https://github.com/rancher/fleet) - A GitOps tool chain that works with Kubernetes manifests, Helm charts, and Kustomize.\n\n### High-Level Tool Comparison\n\nThere 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.\n\n| | Retains Helm release info | Supports Helm hooks | OCI support | Does not require Helm binary |\n| -- | -- | -- | -- | -- |\n| Flux Helm controller | ✅ | ✅ | 🚫[^1] | ✅ |\n| Argo CD | 🚫 | :warning:[^2] | ✅[^3] | 🚫 |\n| Helmfile | ✅ | :warning:[^4] | :warning:[^5] | 🚫[^6] |\n| Captain | ✅ | ✅ | :warning:[^7] | ✅ |\n| Terraform Helm provider | ✅ | :warning:[^8] | ✅ | ✅ |\n| Orkestra | ✅ | ✅ | 🚫[^9] | ✅ |\n| Fleet | ✅ | ✅ | 🚫[^10] | ✅ |\n\n_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._\n\n## Conclusion\n\nIf 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.\n\n[^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.\n[^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.\n[^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.\n[^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.\n[^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).\n[^6]: Helmfile parameterizes the Helm binary (default: `helm`).\n[^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.\n[^8]: Terraform Helm provider has [some issues](https://github.com/hashicorp/terraform-provider-helm/issues/683) with Helm hooks and wait configurations.\n[^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.\n[^10]: Fleet uses the Helm SDK. Once it uses a version of the Helm SDK that supports OCI registries, Fleet will inherit support.\n"
  },
  {
    "path": "blog/2022-10-14-helm-at-kubecon-na-22.md",
    "content": "---\ntitle: \"Helm @ KubeCon + CloudNativeCon NA '22\"\nslug: \"helm-at-kubecon-na-22\"\nauthors: [\"karenchu\"]\ndate: \"2022-10-14\"\n---\n\nThe 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!\n\n<!-- truncate -->\n\n## Helm Maintainer Track Talk: [Learn about Helm and Its Ecosystem](https://sched.co/182Ns)\n\nDATE: Thursday October 27\n\nTIME: 11:00am - 11:35am EDT\n\nLOCATION: Room 410 A\n\nMaintainers [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. \n\n## Helm Booth in Project Pavilion\n\nWED OCT 26: 15:30 – 20:00 ET\n\nTHUR OCT 27: 14:00 – 17:30 ET\n\nFRI Oct 28: 13:00 – 16:00 ET\n\nLOCATION: opposite side of the Fuzz booth, near the LitmusChaos/Flux/Cortex/Falco booths\n\nOur 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. \n\nNow 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!\n\nWith that, we'll see the Helm community soon in-person! \n"
  },
  {
    "path": "blog/2022-11-14-welcome-yxxhero.md",
    "content": "---\ntitle: \"Helm welcomes yxxhero as our newest helm-www repo maintainer\"\nslug: \"welcome-yxxhero\"\nauthors: [\"karenchu\"]\ndate: \"2022-11-14\"\n---\n\nThe Helm project is happy to welcome [yxxhero](https://github.com/yxxhero) as our newest maintainer for the helm-www repo! \n<!-- truncate --> 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.\n\nCheers to yxxhero! \n"
  },
  {
    "path": "blog/2023-03-31-helm-completes-fuzzing-security-audit.md",
    "content": "---\ntitle: \"Helm Completes Fuzzing Security Audit\"\nslug: \"helm-completes-fuzzing-security-audit\"\nauthors: [\"adamkorczynski\", \"davidkorczynski\", \"martinhickey\"]\ndate: \"2023-03-31 15:00:00\"\n---\n\nIn 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).<!-- truncate -->\n\n[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. \n\n## What is fuzzing?\n\n[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. \n\n## Helm fuzzing overview\n\nIn 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.\n\nHelm 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.\n\nAt 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.\n\n## Closing thoughts\n\nThe 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."
  },
  {
    "path": "blog/2023-05-15-helm-oci-mediatypes.md",
    "content": "---\ntitle: \"The Helm OCI MediaTypes\"\nslug: \"helm-oci-mediatypes\"\nauthors: [\"andrewblock\"]\ndate: \"2023-05-15\"\n---\n\nHelm 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.<!-- truncate -->\n\n## OCI Artifacts\n\nEven 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.\n\nHelm 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:\n\n* The packaged chart\n* An optional provenance file\n* A repository index file\n\nProducing 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:\n\n* An OCI Image Config containing the contents of the Chart.yaml file\n* The packaged chart within an Image Layer\n* The provenance file (when included) as an Image Layer\n\nThe 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:\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\nThis 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.\n\n* Size – Content size\n* Digest – Content addressable reference signifying the algorithm and hash used\n* Media Type – Media Type of the referenced content\n\nThe 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.\n\n## Media Types and Their Significance\n\nMedia 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.\n\nA 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.\n\nThe OCI Image Specification contains several Media Types that represent the various structural elements of an image. These include:\n\n* `application/vnd.oci.image.index.v1+json` - Index Image\n* `application/vnd.oci.image.manifest.v1+json` - Image Manifest\n* `application/vnd.oci.image.layer.v1.tar+gzip` - gzip compressed Layer\n\nThese 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:\n\n* `vnd` - The vendor tree which are associated with specific products\n* `oci` - The organization or company responsible\n* `image` - A short name for the type\n* `index/manifest/layer` - an optional subcomponent of the type\n* `v1` - enables the versioning of the schema\n* `json/tar+gzip` - Optional format signifier \n\nA 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).\n\n## Helm Media Types\n\nThe Helm community has worked with the IANA to register three new Media Types representing each of the components comprising an OCI based Helm Chart.\n\n* [application/vnd.cncf.helm.config.v1+json](https://www.iana.org/assignments/media-types/application/vnd.cncf.helm.config.v1+json)\n* [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)\n* [application/vnd.cncf.helm.chart.provenance.v1.prov](https://www.iana.org/assignments/media-types/application/vnd.cncf.helm.chart.provenance.v1.prov)\n\nSimilar 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.\n\nFor 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.\n\nHelm 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.\n\n## The Future for Helm’s OCI Media Types\n\nAs 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. \n"
  },
  {
    "path": "blog/2023-09-29-helm-3.13.md",
    "content": "---\ntitle: \"Helm 3.13\"\nslug: \"helm-3.13\"\nauthors: [\"mattfarina\"]\ndate: \"2023-09-29\"\n---\n\nHelm 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.<!-- truncate -->\n\n## Dry-run & Template Can Connect To Servers\n\nThe 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.\n\nWith 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.\n\nHelm SDK users will find a new property, named `DryRunOption`, that allows you to tell the SDK to communicate with the server.\n\n## Values Handling Improvements\n\nValues 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.\n\nThe order you can expect for a value to be used is:\n\n1. User specified values (e.g CLI)\n2. Imported values from dependencies\n3. Parent chart values\n4. Sub-chart values\n\n## JSON Indexes\n\nHelm 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.\n\nThose `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.\n\nTests were run on very large indexes to look at the perform difference. The results found that:\n\n- Helm 3 versions before 3.13:\n  - Parsed JSON in ~80% the time of parsing YAML\n  - Used ~93% the memory parsing JSON compared to YAML\n- Helm 3.13+, with special case handling to detect and handle JSON:\n  - Parsed JSON in ~13% the time of parsing YAML\n  - Used ~5% the memory parsing JSON compared to YAML\n\n## Get Metadata Command\n\n`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.\n\nTo illustrate this, I installed WordPress and retrieved the metadata:\n\n```shell\n$ helm get metadata wp\nNAME: wp\nCHART: wordpress\nVERSION: 17.1.13\nAPP_VERSION: 6.3.1\nNAMESPACE: default\nREVISION: 1\nSTATUS: deployed\nDEPLOYED_AT: 2023-09-28T16:28:30-04:00\n```\n\n## And More...\n\nThese 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).\n\n"
  },
  {
    "path": "blog/2024-03-14-cve-2019-25210.md",
    "content": "---\ntitle: \"Response To CVE-2019-25210\"\nslug: \"response-CVE-2019-25210\"\nauthors: [\"helmmaintainers\"]\ndate: \"2024-03-14\"\n---\n\n[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.<!-- truncate -->\n\n## Not A Vulnerability In Helm\n\nThe Helm project rejects this disclosure’s assertion of a vulnerability within Helm.\n\nThe [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.\n\nThe `--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.\n\nThis 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.\n\nConsider 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.\n\n## Helm Changes\n\nTo provide greater clarity, the Helm maintainers have made two changes.\n\n1. [Documentation has been updated to make the possible exposure of secret information explicit](https://github.com/helm/helm/pull/12859).\n2. [ 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.\n\n## Why A Delay In Response\n\nWhen the CVE listing was released and the Helm maintainers became aware, the team went to work evaluating the potential impacts.\n\nThe Helm project takes security seriously. Some examples of this include:\n\n* [A documented security policy that enables someone to contact the security team with encrypted communications](https://github.com/helm/community/tree/main/security-audit).\n* [Two 3rd party security audits (on versions of Helm that contained this functionality)](https://github.com/helm/community/tree/main/security-audit).\n* [A fuzzing audit and continuous fuzzing has been set up](https://github.com/helm/community/tree/main/security-audit).\n* [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.\n* Helm releases are signed by the maintainer who produced the release.\n\nNormally, 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.\n\n## Please Responsibly Contact The Helm Security Team\n\nThe 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.\n"
  },
  {
    "path": "blog/2024-06-26-the-road-to-helm-4.md",
    "content": "---\ntitle: \"The Road to Helm 4\"\nslug: \"the-road-to-helm-4\"\nauthors: [\"helmmaintainers\"]\ndate: \"2024-07-10\"\n---\n\nWe 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.<!-- truncate -->\n\nOne 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.\n\nHowever, 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).\n\nThe 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.\n\nBusinessman 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.\n\n## Helm 4 ContribFest at KubeCon EU 2024\n\nIt’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).\n\n## Getting Involved\n\nFor 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!\n\n1. 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. \n    1. [Zoom Meeting](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09).\n2. 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.\n3. Submit an [issue](https://github.com/helm/helm/issues) within the Helm [GitHub repository](https://github.com/helm/helm).\n4. Follow [@HelmPack](https://x.com/HelmPack) on Twitter/X for project updates.\n\nHelm 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.\n"
  },
  {
    "path": "blog/2024-07-16-helm2to3-becomes-unsupported.md",
    "content": "---\ntitle: \"Helm 2to3 is Now Unsupported\"\nslug: \"helm2to3-becomes-unsupported\"\nauthors: [\"martinhickey\"]\ndate: \"2024-07-16\"\n---\n\nOver 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.<!-- truncate -->\n\nOne year later, [Helm 2 became unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/).\n\nHere 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.\n\nIn practice, this means that **Helm 2to3** will receive no more updates (not even security patches).\n\nWe 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.\n"
  },
  {
    "path": "blog/2024-10-07-kubecon-na-24/index.md",
    "content": "---\ntitle: \"Helm at KubeCon/CloudNativeCon SLC\"\nslug: \"kubecon-slc\"\nauthors: [\"mattfarina\"]\ndate: \"2024-11-07\"\n---\n\n![KubeCon / CloudNativeCon Logo](kubecon.png)\n\nHelm 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:<!-- truncate -->\n\n* Wednesday: \n  * At a booth in the project pavilion from 3:15pm - 8pm.\n  * At 7pm MST we are planning to cut a release, live.\n* Thursday: \n  * At a project pavilion booth from 1:45pm - 5pm.\n  * Session: [Contribfest: Helm 4: The Next Generation of the Kubernetes Package Manager](https://kccncna2024.sched.com/event/1howt)\n  * Session: [The Path to Helm 4](https://kccncna2024.sched.com/event/1hoxU)\n* Friday:\n  * 12:30pm - 2:30pm at the project pavilion\n\nIf 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.\n\nIf you're going to be in Salt Lake City, we hope to see you there."
  },
  {
    "path": "blog/2024-11-08-experience-helm-release-kubecon-na-24.md",
    "content": "---\ntitle: \"Experience a Helm Release: Live at KubeCon + CloudNativeCon North America 2024!\"\nslug: \"experience-helm-release-kubecon-na-24\"\nauthors: [\"andrewblock\"]\ndate: \"2024-11-08\"\n---\n\nHave 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!<!-- truncate -->\n\nJoin 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.\n\nWhether 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!\n\nNot able to make it to KubeCon + CloudNativeCon North America? Don’t fret! The session will be recorded and made available at a later date.\n\nThis 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). \n"
  },
  {
    "path": "blog/2025-08-19-debian-helm-repository-move.md",
    "content": "---\ntitle: \"Debian/Ubuntu Helm Apt Repository Move\"\nslug: \"debian-helm-repository-move\"\nauthors: [\"terryhowe\"]\ndate: \"2025-08-19\"\n---\n\nIf you are installing helm with Apt, be aware that the Debian/Ubuntu Helm Apt repository is moving.<!-- truncate -->\nPreviously the repository was hosted at [Balto](https://helm.baltorepo.com/) and\nnow it will be hosted at [Buildkite](https://buildkite.com/).\n\nUpdate your APT key and references to the repository using the [new installation instructions](https://helm.sh/docs/intro/install/#from-apt-debianubuntu).\n"
  },
  {
    "path": "blog/2025-09-09-path-to-helm-v4.md",
    "content": "---\ntitle: \"Path To Releasing Helm v4\"\nslug: \"path-to-helm-v4\"\nauthors: [\"mattfarina\"]\ndate: \"2025-09-09\"\n---\n\nThe [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.<!-- truncate -->\n\n## Alpha Period\n\nWith 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.\n\nIf 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.\n\nFor 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.\n\nThe Alpha period runs through the month of September.\n\n## Beta Period\n\nThe 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.\n\nTesters should file bugs as they encounter any issues.\n\nPer [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.\n\n## Release Candidates\n\nAt 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.\n\n## 🎉 Release 🎉\n\nThe 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.\n"
  },
  {
    "path": "blog/2025-10-19-helm-turns-10/index.md",
    "content": "---\ntitle: \"Helm Turns 10\"\nslug: \"helm-turns-ten\"\nauthors: [\"mattfarina\"]\ndate: \"2025-10-19\"\n---\n\nTen years ago, in a hackathon shortly after the release of Kubernetes 1.1.0, Helm was born.\n\n```\ncommit ecad6e2ef9523a0218864ec552bbfc724f0b9d3d\nAuthor: Matt Butcher <mbutcher@engineyard.com>\nDate:   Mon Oct 19 17:43:26 2015 -0600\n\n    initial add\n```\n<!-- truncate -->\n\n[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.<!--more-->\n\nThis 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.\n\nHappy 10th Birthday, Helm!\n\n![Happy 10th Birthday Helm](happy-10th.png)\n"
  },
  {
    "path": "blog/2025-11-04-helm-at-kubecon-na-25.md",
    "content": "---\ntitle: \"Helm @ KubeCon + CloudNativeCon NA '25\"\nslug: \"helm-at-kubecon-na-25\"\nauthors: [\"karenchu\"]\ndate: \"2025-11-04\"\n---\n\nThe 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! \n\n<!-- truncate -->\n\n## Helm Booth in Project Pavilion\n\nDon'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!\n\n* TUES Nov 11 @ 03:30 PM - 07:45 PM ET \n\n* WED Nov 12 @ 02:00 PM - 05:00 PM ET\n\n* THUR Nov 13 @ 12:30 PM - 02:00 PM ET\n\nLOCATION: 8B, back side of Flux and across from Argo\n\n## Tuesday November 11, 2025\n\n### [Simplifying Advanced AI Model Serving on Kubernetes Using Helm Charts](https://sched.co/27FVb)\n\nTIME: 12:00 PM - 12:30 PM ET\n\nLOCATION: Building B | Level 4 | B401-402\n\nSPEAKERS: [Ajay Vohra](https://kccncna2025.sched.com/speaker/ajayvohr) & [Caron Zhang](https://kccncna2025.sched.com/speaker/caronzh03)\n\nThe 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.\n\nThis 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.\n\nWe'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.\n\n## Wednesday November 12, 2025\n\n### [Maintainer Track: Introducing Helm 4](https://sched.co/27Nme)\n\nTIME: 11:00 AM - 11:30 AM ET\n\nLOCATION: Building C | Level 3 | Georgia Ballroom 1\n\nSPEAKERS: [Matt Farina](https://kccncna2025.sched.com/speaker/matt812) & [Robert Sirchia](https://kccncna2025.sched.com/speaker/robert_sirchia.28kd1wis) (Helm Maintainers)\n\nThe 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?\n\n### [Contribfest: Hands-On With Helm 4: Wasm Plugins, OCI, and Resource Sequencing. Oh My!](https://sched.co/27Nl0)\n\nTIME: 02:15pm - 03:30 PM ET\n\nLOCATION: Building B | Level 2 | B207\n\nSPEAKERS: [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)\n\nJoin 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.\n\nThis session is geared toward anyone interested in Helm development including leveraging and building upon some of the latest features associated with Helm 4!\n\n### [Helm 4 Release Party](/helm-4-release-party/)\n\nTIME: 06:00 PM - 09:00 PM EST\n\nLOCATION: [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)\n\n[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).\n\n## Thursday November 13, 2025\n\n### [Mission Abort: Intercepting Dangerous Deletes Before Helm Hits Apply](https://sched.co/27FeJ)\n\nTIME: 01:45 PM - 02:15 PM ET\n\nLOCATION: Building B | Level 5 | Thomas Murphy Ballroom 4\n\nSPEAKERS: [Payal Godhani](https://kccncna2025.sched.com/speaker/godhanipayal)\n\nWhat 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.\n\n"
  },
  {
    "path": "blog/2025-11-17-helm-4-released/index.md",
    "content": "---\ntitle: \"Helm 4 Released\"\nslug: \"helm-4-released\"\nauthors: [\"mattfarina\"]\ndate: \"2025-11-17\"\n---\n\nOn 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. <!-- truncate -->\n\n## What's New\n\nHelm 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.\n\nSome of the new features include:\n\n- Redesigned plugin system that supports Web Assembly based plugins\n- Post-renderers are now plugins\n- Server side apply is now supported\n- Improved resource watching, to support waiting, based on kstatus\n- Local Content-based caching (e.g. for charts)\n- Logging via slog enabling SDK logging to integrate with modern loggers\n- Reproducible/Idempotent builds of chart archives\n- Updated SDK API including support for multiple chart API versions (new experimental v3 chart API version coming soon)\n\nYou can learn about more of the changes in the [Helm 4 Overview](/docs/overview).\n\n## Helm v3 Support\n\nWhen 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:\n\n* Bug fixes until July 8th 2026.\n* Security fixes until November 11th 2026.\n\nHelm 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.\n\n## Learn More\n\nYou 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.\n"
  },
  {
    "path": "blog/authors.yml",
    "content": "adamkorczynski:\n  name: Adam Korczynski\n  image_url: https://github.com/AdamKorcz.png\n  page: true\n  socials:\n    github: AdamKorcz\n    linkedin: adam-korczynski-731909119\nandrewblock:\n  name: Andrew Block\n  image_url: https://github.com/sabre1041.png\n  page: true\n  socials:\n    github: sabre1041\n    linkedin: andrewsblock\n    # keybase: sabre1041\n    website: https://t.co/utJRRBeHm1\nbridgetkromhout:\n  name: Bridget Kromhout\n  image_url: https://github.com/bridgetkromhout.png\n  page: true\n  socials:\n    github: bridgetkromhout\n    linkedin: bridgetkromhout\ndavidkorczynski:\n  name: David Korczynski\n  image_url: https://github.com/davidkorczynski.png\n  page: true\n  socials:\n    github: davidkorczynski\n    linkedin: david-korczynski-875a4957\nhelmmaintainers:\n  name: Helm Maintainers\n  image_url: https://raw.githubusercontent.com/helm/community/refs/heads/main/art/images/Logo-Tweak-Dark.png\n  page: true\n  socials:\n    github: helm\n    website: https://helm.sh\njoshdolitsky:\n  name: Josh Dolitsky\n  image_url: https://github.com/jdolitsky.png\n  page: true\n  socials:\n    github: jdolitsky\n    linkedin: jdolitsky\n    # keybase: jdolitsky\nkarenchu:\n  name: Karen Chu\n  image_url: https://github.com/karenhchu.png\n  page: true\n  socials:\n    github: karenhchu\n    linkedin: karenhchu\nmartinhickey:\n  name: Martin Hickey\n  image_url: https://github.com/hickeyma.png\n  page: true\n  socials:\n    github: hickeyma\n    linkedin: martin-hickey-b64a374\n    website: https://hickeyma.github.io/\nmattbutcher:\n  name: Matt Butcher\n  image_url: https://github.com/technosophos.png\n  page: true\n  socials:\n    github: technosophos\n    linkedin: mattbutcher\n    # keybase: technosophos\n    website: http://technosophos.com/\nmattfarina:\n  name: Matt Farina\n  image_url: https://github.com/mattfarina.png\n  page: true\n  socials:\n    github: mattfarina\n    linkedin: matthewfarina\n    # keybase: mattfarina\n    website: https://mattfarina.com/\nmattfisher:\n  name: Matt Fisher\n  image_url: https://github.com/bacongobbler.png\n  page: true\n  socials:\n    github: bacongobbler\n    linkedin: bacongobbler\n    website: https://blog.bacongobbler.com/\nrimasmocevicius:\n  name: Rimas Mocevicius\n  image_url: https://github.com/rimusz.png\n  page: true\n  socials:\n    github: rimusz\n    linkedin: rimantasmocevicius\n    website: https://rimusz.net/\nscottrigby:\n  name: Scott Rigby\n  image_url: https://github.com/scottrigby.png\n  page: true\n  socials:\n    github: scottrigby\n    linkedin: scottrigby\n    # keybase: r6by\n    website: http://basekamp.com/\nterryhowe:\n  name: Terry Howe\n  image_url: https://github.com/terryhowe.png\n  page: true\n  socials:\n    github: terryhowe\n    linkedin: terrylhowe\n    website: https://terryhowe.wordpress.com/\nviciglesias:\n  name: Vic Iglesias\n  image_url: https://github.com/viglesiasce.png\n  page: true\n  socials:\n    github: viglesiasce\n    linkedin: viglesias\n"
  },
  {
    "path": "blog/helm-at-kubecon-eu-25.md",
    "content": "---\ntitle: \"Helm @ KubeCon + CloudNativeCon EU '25\"\nslug: \"helm-at-kubecon-eu-25\"\nauthors: [\"karenchu\"]\ndate: \"2025-03-31\"\n---\n\nIt'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.\n\n<!-- truncate -->\n\n## Contribfest: [Expanding the Helm Ecosystem With Helm 4](https://sched.co/1tcyE)\n\nDATE: Wednesday April 2\n\nTIME: 16:15 - 17:30 BST\n\nLOCATION: Level 3 | ICC Capital Suite 17\n\nAre 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: \n* Exploring the Helm Ecosystem\n* Building a Triage Team\n* Diving into Helm 4\n\nDon'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. \n\n## Helm Maintainer Track Talk: [Helm 4 You](https://sched.co/1td0b)\n\nDATE: Thursday April 3\n\nTIME: 16:45 - 17:15 BST\n\nLOCATION: Level 3 | ICC Capital Suite 10-12\n\nJoin 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.\n\nFull details on the talk can be found on the [session page](https://sched.co/1td0b).\n\n## Helm Booth in Project Pavilion\n\nWED April 2 @ 15:30 – 19:45 BST\n\nTHUR April 3 @ 14:00 – 17:00 BST\n\nFRI April 4 @ 12:30 – 14:00 BST\n\nLOCATION: 2B, near the sticker wall + back side of Backstage\n\nOur 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! \n\n## Helm Sessions from the Community\n\nAside 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 ~\n\n* [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\n* [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\n* [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\n* [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\n* [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\n\nSee everyone this week!\n"
  },
  {
    "path": "code-of-conduct.md",
    "content": "# Community Code of Conduct\n\nHelm follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).\n"
  },
  {
    "path": "community/MAINTAINERS.md",
    "content": "---\ntitle: Helm Org Maintainers\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/MAINTAINERS.md\n-->\n\n* [Karen Chu](https://github.com/karenhchu)\n* [Matt Butcher](https://github.com/technosophos) (chair)\n* [Matt Farina](https://github.com/mattfarina)\n* [Reinhard Nägele](https://github.com/unguiculus)\n* [Scott Rigby](https://github.com/scottrigby)\n\n## Emeritus\n\n* [Adam Reese](https://github.com/adamreese)\n* [Adnan Abdulhussein](https://github.com/prydonius)\n* [Josh Dolitsky](https://github.com/jdolitsky)\n* [Martin Hickey](https://github.com/hickeyma)\n* [Matt Fisher](https://github.com/bacongobbler)\n* [Vic Iglesias](https://github.com/viglesiasce)\n"
  },
  {
    "path": "community/README.md",
    "content": "---\nsidebar_position: 1\ntitle: Helm Community\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/README.md\n-->\n\nWelcome to the Helm community!\n\nThis is the starting point for becoming a contributor to the Helm project - improving docs, improving code, giving talks etc.\n\n## Communicating\n\nThe [communication](communication.md) page lists communication channels like chat,\nissues, mailing lists, meetings, conferences, etc.\n\n## Assets\n\n- Helm logos are located at [cncf/artwork](https://github.com/cncf/artwork/blob/master/examples/graduated.md#helm-logos)\n- Helm website and docs are located at [helm/helm-www](https://github.com/helm/helm-www)\n- Helm brand examples and guidelines: [art](/community/art)\n- Helm themed presentation template: [slides](https://github.com/helm/community/tree/main/slides)\n\n## How Can I Help?\n\n#### First, you should join our communication forums:\n\n- Follow us on [Twitter](communication.md#social-media)\n- Join us on [Slack](communication.md#slack)\n- Subscribe to our [mailing lists](communication.md#mailing-lists)\n- Join the [weekly meeting](communication.md#meetings)\n\n#### Next, get set-up with the basics (if not already done so):\n\n- [Documentation](https://docs.helm.sh/)\n- [Issues](https://github.com/helm/helm/issues)\n- [PRs](https://github.com/helm/helm/pulls)\n- [Quickstart Guide](https://docs.helm.sh/using_helm/#quickstart)\n- [Developer Guide](https://docs.helm.sh/developers/)\n\nNow, you can get down to business!\n\nA good way to learn is:\n\n- Check out the code and look at code reviews. Documentation and test are part of the code base.\n- Try reproducing issues and get an overview of user problems.\n- Talk to people on Slack and ask questions.\n\nAreas you can start working on:\n\n- Documentation (like the text you are reading now) can always use improvement!\n- We can always do with more test coverage.\n- Review open PRs. Add comments, feedback or give a LGTM!\n- Try out some easy-to-fix bugs which may be marked with the [good first issue] tag\n- Just ask an [owner] for suggestions.\n\n#### Last but not least, we'd love to know what you want to see on the [Helm Blog](https://helm.sh/blog).\nFeel free to submit a blog post topic [here](blog-topics.md).\n\n## Your First Contribution\n\nWe recommend that you work on existing [issues] before attempting to develop a new feature.\n\nFind an existing issue (e.g. one marked [good first issue], or simply ask an [owner] for suggestions),\nand respond on the issue thread expressing interest in working on it.\n\nThis helps other people know that the issue is active, and hopefully prevents duplicated efforts.\n\nEach commit must be signed off in git, as described by\n[the article](https://www.helm.sh/blog/helm-dco/index.html)\ndescribing Helm's switch to DCO.\n\nIf you want to work on a new idea of relatively small scope:\n\n  1. Submit an issue describing your proposed change to the repo in question.\n  1. The repo owners will respond to your issue promptly.\n  1. If your proposed change is accepted, start work in your fork, signing off each commit as described above.\n  1. Submit a [pull request] containing a tested change.\n\n\n[good first issue]: https://github.com/helm/helm/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3A%22good+first+issue%22\n[issues]: https://github.com/helm/helm/issues\n[pull request]: https://github.com/helm/helm/blob/main/CONTRIBUTING.md#pull-requests\n[owner]: https://github.com/kubernetes/helm/blob/main/OWNERS\n"
  },
  {
    "path": "community/SECURITY.md",
    "content": "---\nsidebar_label: Helm Security\ntitle: Helm Security Process and Policy\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/SECURITY.md\n-->\n\nThis document provides the details on the Helm security policy and details the processes\nsurrounding security handling including a how to guide on reporting a security vulnerability\nfor anything within the Helm organization.\n\n## Report A Vulnerability\n\nWe’re extremely grateful for security researchers and users who report vulnerabilities\nto the Helm community. All reports are thoroughly investigated by a set of Helm maintainers.\n\nTo make a report please email the private security list at cncf-helm-security@lists.cncf.io\nwith the details.\n\nYou may, but are not required to, encrypt your email to this list using the PGP keys\nof security team members, listed below.\n\n| Name           | Key URL                                                                                         | Fingerprint                                        |\n|----------------|-------------------------------------------------------------------------------------------------|----------------------------------------------------|\n| Andrew Block   | [link](https://keybase.io/sabre1041/pgp_keys.asc)                                               | 2CE5 F1FB 9E8C 59B8 7BBD  5F2B 02DF E631 AEF3 5EBC |\n| George Jenkins | [link](https://keybase.io/gjenkins8/pgp_keys.asc)                                               | C048 04B5 F250 1D25 CA69  A415 2945 4FC9 6455 D41E |\n| Matt Butcher   | [link](https://keybase.io/technosophos/pgp_keys.asc)                                            | ABA2 5295 98F6 626C 420D 335B 62F4 9E74 7D91 1B60  |\n| Matt Farina    | [link](https://keybase.io/mattfarina/pgp_keys.asc)                                              | 672C 657B E06B 4B30 969C 4A57 4614 49C2 5E36 B98E  |\n| Robert Sirchia | [link](https://keys.openpgp.org/vks/v1/by-fingerprint/7FEC81FACC7FFB2A010ADD13C2D40F4D8196E874) | 7FEC81FACC7FFB2A010ADD13C2D40F4D8196E874           |\n\n### When To Send A Report\n\nYou 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).\n\n### When Not To Send A Report\n\n* If a vulnerability has been found in an application deployed by a Helm Chart. Instead, contact the application maintainers\n* 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)\n* You are looking for help applying security updates\n\n### Security Vulnerability Response\n\nEach report will be reviewed and receipt acknowledged within 3 business days. This will set off the security review process detailed below.\n\nAny 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.\n\nWe 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.\n\nAs 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.\n\n### Public Disclosure\n\nA 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.\n\nCVEs 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.\n\nIf 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.\n\n## Security Team Membership\n\nThe security team is made up of a subset of the Helm project maintainers who are willing and able to respond to vulnerability reports.\n\n### Responsibilities\n\n* Members MUST be active project maintainers on active (non-deprecated) Helm projects as defined in [the governance](governance/governance.md)\n* Members SHOULD engage in each reported vulnerability, at a minimum to make sure it is being handled\n* Members MUST keep the vulnerability details private and only share on a need to know basis\n\n### Membership\n\nNew 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.\n\nFrom 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.\n\n## Patch and Release Team\n\nWhen 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.\n\n## Disclosures\n\nVulnerability 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.\n\nDisclosures will be published on the same day as a release fixing the vulnerability after the release is published.\n"
  },
  {
    "path": "community/art/readme.md",
    "content": "---\ntitle: Styleguide\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/art/readme.md\n-->\n## Logo\n\nThe official Helm logo is found at the [CNCF/artwork](https://github.com/cncf/artwork/blob/master/examples/graduated.md#helm-logos) repo.\n\n![Logo-Tweak-Light](./images/Logo-Tweak-Light.png)\n\n![Logo-Tweak-Dark](./images/Logo-Tweak-Dark.png)\n\n\n# Brand Colors\n\n![Helm-3-Color-Palettes-Light](./images/Helm-3-Color-Palettes-Light.png)\n\n![Helm-3-Color-Palettes-Dark](./images/Helm-3-Color-Palettes-Dark.png)\n\n\n### Color Values\n\n```\n// primary\nnavy           #0F1689\n\n// secondary\nblue-dark      #090E6F\nblue-light     #1B53C2\n\n// shades\nshade-dark     #050843\nshade-mid      #B7C2E9\nshade-light    #DBE1F3\n\n// accents\naccent-blue    #3B82BF\naccent-green   #2F84A7\naccent-red     #95297C\naccent-yellow  #D1AA9B\n```\n\n# Typography\n\n![type-notes](./images/type-notes.png)\n\n* [Space Mono](https://fonts.google.com/specimen/Space+Mono) _(Google Fonts)_\n* [Public Sans](https://public-sans.digital.gov/) _(USWDS)_\n\n---\n\n## Examples:\n\nExample applications of the Helm brand to different assets.\n\n![Typography](./images/Typography.png)\n\nExample typography.\n\n![Example-Icon-Illustrations](./images/Example-Icon-Illustrations.png)\n\nIllustrations and icon examples.\n\n![Helm-Summit](./images/Helm-Summit.png)\n\n---\n\n![Website-Exmple](./images/Example-Icon-Illustrations.png)\n\nExample for a website layout.\n\n![Website-Exmple.png](./images/Website-Exmple.png)\n"
  },
  {
    "path": "community/blog-topics.md",
    "content": "---\ntitle: Submit a topic for the Helm Blog\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/blog-topics.md\n-->\n\n1. Helm 2 to 3 Migration (Blog Series)\n  * 5 Useful Tips for Migrating to Helm 3\n  * Helm 2 to Helm 3 Migration Checklist\n  * Rethinking Security for Helm 3\n2. Helm Maintainer Spotlight (Blog Series)\n3. Case Studies\n4. Solution Guides\n5. <insert topic here>\n"
  },
  {
    "path": "community/code-of-conduct.md",
    "content": "---\ntitle: Community Code of Conduct\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/code-of-conduct.md\n-->\n\nHelm follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).\n"
  },
  {
    "path": "community/communication.md",
    "content": "---\ntitle: Communication\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/communication.md\n-->\n\nThe Helm community abides by the [CNCF code of conduct].  Here is an excerpt:\n\n> _As contributors and maintainers of this project, and in the interest\n> of fostering an open and welcoming community, we pledge to respect\n> all people who contribute through reporting issues, posting feature\n> requests, updating documentation, submitting pull requests or patches,\n> and other activities._\n\n## Social Media\n\n* [Twitter]\n* Pose questions and help answer them on [Slack] or [Stack Overflow].\n\n## Slack\n\nYou can [request an invitation to the Kubernetes Slack](https://slack.kubernetes.io/).\n\nMost real time discussion happens at [#helm-users](https://kubernetes.slack.com/messages/C0NH30761) and [#charts](https://kubernetes.slack.com/messages/C6E3XH1ED).\n\nThere is also a [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG) channel for discussing development of Helm.\n\n## Issues\n\nIssues are used as the primary method for tracking anything to do with the Helm project.\n\nSee the [contributing guide](https://github.com/kubernetes/helm/blob/main/CONTRIBUTING.md#issues)\nfor information on how to [file an issue] if you think you have found a bug or have a feature request.\n\n## Mailing lists\n\nDevelopment announcements and discussions appear on the Helm mailing list\n[cncf-helm] (send mail to `cncf-helm@lists.cncf.io`).\n\n## Meetings\n\nThe Helm community holds regular public meetings, including those supporting Helm\nclient 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)\nand [subscribe via an ical](https://calendar.google.com/calendar/ical/s5anaqbm9kda435dnh5r8lj1l8%40group.calendar.google.com/public/basic.ics) feed.\n\nWe have a [weekly development meeting] every Thursday at 9:30am US Pacific Time and all are welcome.\n\nMap that to your local time with this [timezone table].\n\nWe 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.\n\nVideos are available on the [Helm Community Meetings playlist].\n\n## Conferences\n\nHelm 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.\n\nAlso, the Helm community organizes the Helm-focused event - [Helm Summit], first\nedition 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.\n\n[CNCF code of conduct]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md\n[cncf-helm]: https://lists.cncf.io/g/cncf-helm/topics\n[events]: https://www.cncf.io/events/\n[file an issue]: https://github.com/helm/helm/issues/new\n[kubernetes-sig-apps]: https://groups.google.com/forum/#!forum/kubernetes-sig-apps\n[Slack]: https://kubernetes.slack.com\n[Helm Summit]: https://helmsummitpdx-feb2018.splashthat.com/\n[Stack Overflow]: https://stackoverflow.com/questions/tagged/kubernetes-helm\n[timezone table]: https://www.google.com/search?q=0930+am+in+pst\n[Twitter]: https://twitter.com/helmpack\n[weekly development meeting]: https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09\n[Helm Community Meetings playlist]: https://www.youtube.com/playlist?list=PLVt9l4b66d5EY5Xs9OVJgvO5ss9WzrSY0\n[SIGs]: https://github.com/kubernetes/community/blob/master/sig-list.md\n[SIG-Apps]: https://github.com/kubernetes/community/tree/master/sig-apps\n"
  },
  {
    "path": "community/developers.md",
    "content": "---\ntitle: Developer Setup\ndescription: Instructions for setting up your environment for developing Helm.\nsidebar_position: 2\n---\n\nThis guide explains how to set up your environment for developing on Helm.\n\n## Prerequisites\n\n- The latest version of Go\n- A Kubernetes cluster w/ kubectl (optional)\n- Git\n\n## Building Helm\n\nWe use Make to build our programs. The simplest way to get started is:\n\n```console\n$ make\n```\n\nIf required, this will first install dependencies and validate configuration. It will then compile `helm` and place it in\n`bin/helm`.\n\nTo run Helm locally, you can run `bin/helm`.\n\n- Helm is known to run on macOS and most Linux distributions, including Alpine.\n\n## Running tests\n\nTo run all the tests, run `make test`.\nAs a pre-requisite, you would need to have\n[golangci-lint](https://golangci-lint.run)\ninstalled.\n\n## Running Locally\n\nYou can update your path and add the path of your local helm binary. In an editor\nopen your shell config file. Add the following line making sure you replace\n`<path to your binary folder>` with your local bin directory.\n\n``` bash\nexport PATH=\"<path to your binary folder>:$PATH\"\n```\n\nThis will allow you to run the locally built version of helm from your terminal.\n\n## Contribution Guidelines\n\nWe welcome contributions. This project has set up some guidelines in order to\nensure that (a) code quality remains high, (b) the project remains consistent,\nand (c) contributions follow the open source legal requirements. Our intent is\nnot to burden contributors, but to build elegant and high-quality open source\ncode so that our users will benefit.\n\nMake sure you have read and understood the main CONTRIBUTING guide:\n\n<https://github.com/helm/helm/blob/main/CONTRIBUTING.md>\n\n### Structure of the Code\n\nThe code for the Helm project is organized as follows:\n\n- The individual programs are located in `cmd/`. Code inside of `cmd/` is not\n  designed for library re-use.\n- Shared libraries are stored in `pkg/`.\n- The `scripts/` directory contains a number of utility scripts. Most of these\n  are used by the CI/CD pipeline.\n\nGo dependency management is in flux, and it is likely to change during the\ncourse of Helm's lifecycle. We encourage developers to _not_ try to manually\nmanage dependencies. Instead, we suggest relying upon the project's `Makefile`\nto do that for you. With Helm 3, it is recommended that you are on Go version\n1.13 or later.\n\n### Writing Documentation\n\nSince Helm 3, documentation has been moved to its own repository. When writing\nnew features, please write accompanying documentation and submit it to the\n[helm-www](https://github.com/helm/helm-www) repository.\n\nOne exception: [Helm CLI output (in English)](/docs/helm) is\ngenerated from the `helm` binary itself. See [Updating the Helm CLI Reference Docs](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs)\nfor instructions on how to generate this output. When translated, the CLI\noutput is not generated and can be found in `/content/<lang>/docs/helm`.\n\n### Git Conventions\n\nWe use Git for our version control system. The `main` branch is the home of\nthe current development candidate. Releases are tagged.\n\nWe accept changes to the code via GitHub Pull Requests (PRs). One workflow for\ndoing this is as follows:\n\n1. Fork the `github.com/helm/helm` repository into your GitHub account\n2. `git clone` the forked repository into your desired directory\n3. Create a new working branch (`git checkout -b feat/my-feature`) and do your\n   work on that branch.\n4. When you are ready for us to review, push your branch to GitHub, and then\n   open a new pull request with us.\n\nFor Git commit messages, we follow the [Semantic Commit\nMessages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html):\n\n```\nfix(helm): add --foo flag to 'helm install'\n\nWhen 'helm install --foo bar' is run, this will print \"foo\" in the\noutput regardless of the outcome of the installation.\n\nCloses #1234\n```\n\nCommon commit types:\n\n- fix: Fix a bug or error\n- feat: Add a new feature\n- docs: Change documentation\n- test: Improve testing\n- ref: refactor existing code\n\nCommon scopes:\n\n- helm: The Helm CLI\n- pkg/lint: The lint package. Follow a similar convention for any package\n- `*`: two or more scopes\n\nRead more:\n\n- The [Deis\n  Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)\n  were the inspiration for this section.\n- Karma Runner\n  [defines](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) the\n  semantic commit message idea.\n\n### Go Conventions\n\nWe follow the Go coding style standards very closely. Typically, running `go\nfmt` will make your code beautiful for you.\n\nWe also typically follow the conventions recommended by `go lint` and\n`gometalinter`. Run `make test-style` to test the style conformance.\n\nRead more:\n\n- Effective Go [introduces\n  formatting](https://golang.org/doc/effective_go.html#formatting).\n- The Go Wiki has a great article on\n  [formatting](https://github.com/golang/go/wiki/CodeReviewComments).\n\nIf you run the `make test` target, not only will unit tests be run, but so will\nstyle tests. If the `make test` target fails, even for stylistic reasons, your\nPR will not be considered ready for merging.\n\n## Troubleshooting\n\nTo 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.\n\nIf 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_."
  },
  {
    "path": "community/governance/README.md",
    "content": "---\nsidebar_label: Governance\ntitle: Governance Introduction\nid: helm-governance\nsidebar_position: 9\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/governance/README.md\n-->\n\nThe Helm governance details areas such as:\n\n* Maintainer responsibilities\n* Types of maintainers (Org and Project)\n* How elections occur\n* Decision making\n* Code of Conduct handling\n\nFor the full detail on the Helm governance see the document [governance.md](/community/governance/governance).\n\nThe Helm Org Maintainers are documented in [the community repo Maintainers file](/community/MAINTAINERS).\n\n## Projects\n\nThe Helm governance refers to projects for the Helm project. The following Helm\nprojects currently exist:\n\n* **Helm Core**: The Helm CLI and packages\n* **Charts**: Responsible for chart-related tooling (e.g., chart testing)\n* **ChartMuseum**: The chart repository server\n* **Web and Docs**: The Helm websites\n\nAll other repositories are either archived or owned by the org maintainers.\n"
  },
  {
    "path": "community/governance/_category_.json",
    "content": "{\n  \"link\": {\n    \"type\": \"doc\",\n    \"id\": \"helm-governance\"\n  }\n}\n"
  },
  {
    "path": "community/governance/governance.md",
    "content": "---\nsidebar_label: Rules\ntitle: Governance Rules\nslug: governance\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/governance/governance.md\n-->\n\nThe following document outlines how the Helm project governance operates.\n\n## The Helm Project\n\nThe 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:\n\n* Helm - the package manager\n* Charts - community curated charts\n* Chartmuseum - a chart repository with support for pushing charts, auth, and more\n* chart-testing - container based chart testing tools\n\nThe services provided include:\n\n* Documentation for those who want to create, distribute, depend on, and operate packages\n* Public chart collaboration\n\n## Maintainers Structure\n\nThere 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.\n\nChanges in maintainership have to be announced on the [Helm mailing list](https://lists.cncf.io/g/cncf-helm).\n\n### Helm Org Maintainers\n\nThe Helm Org maintainers are responsible for:\n\n* Maintaining the mission, vision, values, and scope of the project\n* Refining the governance and charter as needed\n* Making project level decisions\n* Resolving escalated project decisions when the subteam responsible is blocked\n* Managing the Helm brand\n* Controlling access to Helm assets such as source repositories, hosting, project calendars\n* Handling code of conduct violations\n* Deciding what sub-groups are part of the Helm project\n* Overseeing the resolution and disclosure of security issues\n* Managing financial decisions related to the project\n\nChanges to org maintainers use the following:\n\n* There will be between 3 and 9 people.\n* Any project maintainer of any active (non-archived) Helm organization project is eligible for a position as an org maintainer.\n* No one company or organization can employ a simple majority of the org maintainers\n* 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\n* 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\n* 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\n  * The nomination period will be three weeks starting the day after an org maintainer opening becomes available\n  * The nomination must be made via the [public Helm mailing list](https://lists.cncf.io/g/cncf-helm/)\n* When nominated individual(s) agrees to be a candidate for maintainership, the project maintainers may vote\n  * 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\n  * Only current project maintainers of active projects are eligible to vote\n  * 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\n  * 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)\n* When an org maintainer steps down, they become an emeritus maintainer\n\nOnce 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.\n\nThe Org Maintainers will select a chair to set agendas and call meetings of the Org Maintainers.\n\n### Project Maintainers\n\nProject 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.\n\nIn 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).\n\nTo 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.\n\nProject 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.\n\nChanges to maintainers use the following:\n\n* A maintainer may step down by emailing the [Helm mailing list](https://lists.cncf.io/g/cncf-helm)\n* 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\n* 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.\n* 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.\n* When a project has no maintainers the Helm org maintainers become responsible for it and may archive the project or find new maintainers\n* 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.\n\n## Decision Making at the Helm org level\n\nWhen maintainers need to make decisions there are two ways decisions are made, unless described elsewhere.\n\nThe 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.\n\nWhen a consensus cannot be found a maintainer can call for a [majority](https://en.wikipedia.org/wiki/Majority) vote on a decision.\n\nMany of the day-to-day project maintenance can be done by a lazy consensus model. But the following items must be called to vote:\n\n* Enforcing a CoC violation (super majority)\n* Removing a maintainer for any reason other than inactivity (super majority)\n* Changing the governance rules (this document) (super majority)\n* Licensing and intellectual property changes (including new logos, wordmarks) (simple majority)\n* Adding, archiving, or removing subprojects (simple majority)\n* Utilizing Helm/CNCF money for anything CNCF deems \"not cheap and easy\" (simple majority)\n\nOther 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.\n\n## Code of Conduct\n\nThe 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.\n\nIf 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.\n\n## DCO and Licenses\n\nThe following licenses and contributor agreements will be used for Helm projects:\n\n* [Apache 2.0](https://opensource.org/licenses/Apache-2.0) for code\n* [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/legalcode) for documentation\n* [Developer Certificate of Origin](https://developercertificate.org/) for new contributions\n"
  },
  {
    "path": "community/hips/README.md",
    "content": "---\ntitle: Helm Improvement Proposals (HIPs)\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/README.md\n-->\n\nTo learn more about the purpose of HIPs and how to go about writing a proposal,\nplease start reading [HIP 1](hip-0001.md).\n\n## Markdown for Proposals\n\nOriginal proposal source should be written in Markdown format, and the format is\ndescribed in HIP 1. Older proposals were often written in a more mildly\nrestricted markdown format and can be found in the\n[archives](archives/README.md).\n\n## Existing HIPs\n\n- [hip-0001: Writing a HIP](hip-0001.md)\n- [hip-0002: Pre-defined release dates for Helm](hip-0002.md)\n- [hip-0003: How Projects Join the Helm Organization](hip-0003.md)\n- [hip-0004: Document backwards-compatibility rules](hip-0004.md)\n- [hip-0005: Helm Org Maintainers and Deprecated Projects](hip-0005.md)\n- [hip-0006: OCI Support](hip-0006.md)\n- [hip-0007: Document and Track maintainer groups](hip-0007.md)\n- [hip-0008: Add descriptions to custom completions](hip-0008.md)\n- [hip-0009: Transitioning Security Team Members on Project Deprecation](hip-0009.md)\n- [hip-0010: Distributed responsibility for picking](hip-0010.md)\n- [hip-0011: CRD Handling in Helm 3](hip-0011.md)\n- [hip-0012: Helm 4 Development Process](hip-0012.md)\n- [hip-0014: Helm Triage Maintainers](hip-0014.md)\n- [hip-0015: Annotation for Images used by Helm Charts](hip-0015.md)\n- [hip-0017: Helm OCI MediaType Registration](hip-0017.md)\n- [hip-0018: Include repository URL and tarball digest in chart's release metadata](hip-0018.md)\n- [hip-0019: New annotations for displaying hook output](hip-0019.md)\n- [hip-0020: H4HIP: Charts v3 Enablement](hip-0020.md)\n- [hip-0021: Enhanced logging library for Helm](hip-0021.md)\n- [hip-0022: Wait With kstatus](hip-0022.md)\n- [hip-0023: Utilize Server Side Apply for installs/upgrades](hip-0023.md)\n- [hip-0024: Improve the Helm Documentation](hip-0024.md)\n- [hip-0025: Better Support for Resource Creation Sequencing](hip-0025.md)\n- [hip-0026: H4HIP: Wasm plugin system](hip-0026.md)\n"
  },
  {
    "path": "community/hips/archives/README.md",
    "content": "---\ntitle: Proposal Archives\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/README.md\n-->\n\nHere lies all of the proposals written prior to the new standard: proposal-0001.\nThey are retained here for historical purposes.\n"
  },
  {
    "path": "community/hips/archives/helm/distributed-search.md",
    "content": "---\ntitle: \"Proposal: Search of Distributed Repositories\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/distributed-search.md\n-->\n\nRepositories 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)).\n\nTo 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.\n\nThis proposal is about enabling distributed repositories by making them and their packages discoverable.\n\n## A Single Search Location\n\nThe 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.\n\nThe public repositories would need to provide:\n\n1. Valid repositories to the repository specification\n1. A security point of contact for the repository\n1. A general point of contact for issues\n1. 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.\n\nEnd users would then be able to query, via the web or API, for charts with an experience containing the following characteristics:\n\n* Can perform a general text search for packages that queries across all listed repositories\n* In the details of the response on a chart there will be directions on:\n\n    * Adding the repository to a local helm installation\n    * Installing the chart without adding the repository\n\n* Metadata on repositories, charts, and provider organizations.\n\nThe 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.\n\n_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._\n\n## Tools Provided For Repository Maintainers\n\nTo enable distributed repositories the Helm project will provide the following tools:\n\n### Repository Tools\n\nBasic 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.\n\n### Documentation\n\nIn addition to tooling there needs to be documentation that covers:\n\n* How to run a repository on GitHub, Gitlab, and other similar code hosting services\n* Details on signing charts and how to integrate that into workflows\n* Suggestions on leveraging CI as part of repository hosting\n* A clearly documented repository specification\n\n### Analysis Tools\n\nTo 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.\n\nNote, work on this step has already begun and [can be found on GitHub](https://github.com/kubernetes-helm/chart-testing).\n\n## Outstanding Actions\n\nThe following are outstanding actions that need to be worked out but can happen after the proposal is accepted:\n\n* [ ] Decide on and document the requirements for listed repositories\n\n## Organizational Management\n\nThe Charts Maintainers team will be the directly responsible party for this system and it will be hosted by the Helm project."
  },
  {
    "path": "community/hips/archives/helm/helm-v3/000-helm-v3.md",
    "content": "---\ntitle: Helm 3 Design Proposal\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/000-helm-v3.md\n-->\n\nThis document contains a proposal for Helm 3. It assumes deep familiarity with\nHelm 2, and assumes that much of Helm 2's architecture will simply carry over\nwithout major change.\n\n## Summary\n\n- Tiller is gone, and there is only one functional component (`helm`)\n- Charts are updated with libraries, schematized values, and the ext directory\n- Helm will use a \"lifecycle events\" emitter/handler model.\n- Helm has an embedded Lua engine for scripting some event handlers. Scripts are stored in charts.\n- State is maintained with two types of object: Release and a release version Secret\n- Resources created by hooks will now be managed\n- For pull-based DevOps workflow, a new Helm Controller project will be started\n- Cross platform plugins in Lua that only have a runtime dependency on Helm\n- A complementary command to `helm fetch` to push packages to a repository\n\n## Purpose\n\nThe design presented herein is intended to begin with the [user profiles](../../../../user-profiles.md)\nidentified for helm and match as many of the [user stories](./011-user_stories.md)\nas could be accommodated\n\n## The Basic Architecture\n\nHelm 3 is a single-service architecture. One executable is responsible for\nimplementing Helm. There is no client/server split, nor is the core processing\nlogic distributed among components.\n\nThe reference implementation of Helm 3 is a single command-line client with no\nin-cluster server or controller. This tool exposes command-line operations, and\nunilaterally handles the package management process.\n\nThe reference implementation has two distinct parts:\n\n1. The command line façade, which translates commands, subcommands, flags, and\n   arguments into a Helm operation\n2. The Helm library, which provides the logic for executing all Helm\n   operations.\n\nBy design, the Helm library _must_ be usable as a standalone library.\n\nIn Appendix A, we specify a second implementation of Helm 3 that provides a\ncontroller-oriented model with no client. The Helm Controller provides a\nCRD-based façade to receive commands, but executes them via the Helm library.\n\nWith this simplification, the following list comprises the components of Helm\nv3's core implementation:\n\n* Charts\n* Chart repositories\n* `helm`, the CLI\n* An extension mechanism (Lua scripts stored in the chart)\n* A new in-cluster CRD: Release\n\nIn this model, Tiller is removed and there are no operators or controllers that\nrun in-cluster.\n\n## Command/Flag Differences from Helm 2\n\nThere are a few major (breaking) changes to the Helm CLI planned:\n\n- The `-n` flag will be remapped across the board to `--namespace`, not `-name`.\n  This is for consistency with `kubectl`, which added `-n` after Helm 2 was released.\n- `helm install` will _require_ a name, unless `--generate-name` is specified. This\n  inverts the default behavior for Helm 2.\n- `helm serve` and `helm reset` will be removed\n- `helm delete` will be renamed to `helm remove`, though `helm delete` will remain an alias.\n- `helm inspect` will be renamed `helm show`, though `helm inspect` will remain as an alias.\n\nOther changes to commands are described in their relevant sections within this document.\n\n## Table of Contents\n\n1.  [Charts](./001-charts.md)\n2.  [Event System](./002-events.md)\n3.  [State Storage](./003-state.md)\n4.  [Hooks](./004-hooks.md)\n5.  [Plugins](./005-plugins.md)\n6.  [Repositories](./006-repositories.md)\n7.  [Security Considerations](./007-security.md)\n8.  [Appendix A: A Helm Controller](./008-controller.md)\n9.  [Appendix B: What Is A Package Manager](./009-package_manager.md)\n10. [Appendix C: Removed Sections](010-removed.md)\n11. [Appendix D: User Stories](011-user_stories.md)\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/001-charts.md",
    "content": "---\ntitle: Charts\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/001-charts.md\n-->\n\n\nThe chart architecture remains largely unchanged.\n\nThe following changes are proposed to the existing chart format:\n\n- The ext/ directory and supporting requirements\n- Library charts\n- Schemata for values files\n\n## The ext/ directory\n\nThe `ext/` directory is a reserved directory in v3 charts. It is reserved for\nplacing extension scripts.\n\nIn Helm 3, Lua scripts are placed into `ext/lua/`. Examples of Lua scripts can\nbe found below.\n\n### Sandboxing Model\n\nWhen a chart is loaded, the script `chart.lua` in `ext/lua` will also be loaded. All\nsubchart `ext/lua/chart.lua` scripts will be loaded into the same runtime, and then the\ntop-level (parent) chart's `init()` function will be executed.\n\nWith this construction, the parent chart will (a) have access to the objects\nin the child charts, and (b) be responsible for initializing child charts. Library\nsupport will be provided for simplifying this process:\n\n```lua\nfunction init(events) {\n  -- Initialize subcharts\n  subchart.init(events)\n\n  -- Do other stuff\n  event.on(\"pre-load\", 0.5, function () {\n    print(\"pre-load event\")\n  })\n}\n```\n\nThis design will make it possible for top-level charts to strategically overrride\nthe behavior of subcharts, or (as above) simply use them as-is.\n\nBy default, the chart sandbox will be prepared with a minimal set of built-in libraries.\nThese libraries will not include network, os, or filesystem access. The module\nsystem (e.g. `require()`) will only allow in-chart libraries to be loaded.\n\nAdditional core libraries, such as os, network, and filesystem access, can be\nloaded only of they are specified in the `ext/permissions.yaml` file.\n\n```yaml\nlua:\n    - network\n    - io\n```\n\nThe above permissions file asks that the Lua interpreter grant permission to\nthe `network` and `io` libraries. This request will require user\nconfirmation.\n\nWhen users install charts that ask for additional permissions, they will be\nprompted to allow:\n\n```console\n$ helm install stable/ishmael\nChart \"ishmael\" is requesting the following additional permissions:\n  - network: Access the network\n  - io: Access the local filesystem\nAllow? (y, yes, n, no) > \n```\n\nAn additional `-y`,`--yes` flag will allow global acceptance of permissions.\n\nFor fine-grained control, a `--accept-perms [strings]` may be provided to allow a\nuser to set a specific set of perms. If the chart asks for others, the install will\nfail:\n\n```\n$ helm install stable/ishmael --accept-perms network,io\n```\n\nThe above will succeed if:\n\n- The chart does not request any permissions\n- The chart requires one or both of `network` and `io`, but no other permissions\n\nThe above will fail if:\n\n- The chart asks for any permissions other than `network` or `io`\n\nWhen a chart contains subcharts, the presence of a `permissions.yaml` file will\nresult in a permissions prompt even if the subchart's Lua code is overridden.\nThis is because the overriding logic does not preclude the loading of the\nlibraries.\n\n## Library Charts\n\nHelm 3 supports a class of chart called a \"library chart\". This is a chart that\nis shared by other charts, but does not create any release artifacts of its\nown. A library chart's templates can only declare `define` elements. Globally\nscoped non-`define` content is simply ignored.\n\nLibrary charts may also contain scripts (`ext/`). However, overlays are\nignored.\n\nLibrary charts are stored in `library/` in a Helm chart. Helm may hoist the\nlibrary charts in subcharts into the parent chart.\n\nLibrary charts are noted in the `library:` directive in the\n`requirements.yaml`.\n\n```yaml\nrequirements:\n  - name: apache\n    version: 1.2.3\n    repository: http://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: http://another.example.com/charts\nlibraries:\n  - name: common\n    version: \"^2.1.0\"\n    repository: http://another.example.com/charts\n```\n\nLibraries are semver ranged. When versions are processed, the highest global\nmatch is used. An incompatibility results in a failed chart render or build.\n\n> [name=Matt Farina]\n> 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?\n> [name=Matt Butcher]\n> We could put a flag in the chart.yaml which would make such\n> a chart uninstallable. I'm not sure, though, whether that's \n> necessary. Installing a library would be a no-op on Helm's\n> side, so we could just have Helm output an error any time\n> there are no objects to install (as Helm v2 does now).\n> [name=Nikhil Manchanda]\n> 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? \n> \n> [name=Adnan Abdulhussein]\n> 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.\n> [name=Matt Butcher]\n> 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?\n> \n> [name=Adnan Abdulhussein]\n> 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.\n\n### Lua in Library Charts\n\nLua in library charts will be loaded as normal, and the `init()` functions will\nbe executed by `subcharts.init()` (if called). It is considered bad (but legal)\npractice to include event handlers in library charts.\n\n## Schematized Values Files\n\nIn Helm 2, there is no schema that is applied to a values file.\n\nFor Helm 3, a [JSON schema](http://json-schema.org/specification.html) can be\napplied to a values file to validate it. The JSON schema file can be generated\nfrom the source values file (e.g. by introspecting the YAML), or it can be\nhand-authored.\n\nFor the sake of consistency, the JSON schema file will be stored as YAML data.\nThe schema is stored in `values.schema.yaml`, parallel to `values.yaml`.\n\n> [name=Adnan Abdulhussein]\n> 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.\n> [name=Matt Fisher]\n> I don't think there's a better way to do this unless we made values.yaml strongly typed.\n> \n> 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.\n> \n> [name=Matt Butcher]\n> Schema could be optional, in addition to being autogenerated by default.\n\nFor example, consider a simple `values.yaml` file:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nThis can be schematized into something like this:\n\n```yaml\n    title: Values\n    type: object\n    properties:\n        name:\n            description: Service name\n            type: string\n        protocol:\n            type: string\n        port:\n            description: Port\n            type: integer\n            minimum: 0\n        image:\n            description: Container Image\n            type: object\n            properties:\n                repo: \n                    type: string\n                tag:\n                    type: string\n    required: \n        - protocol\n        - port\n```\n> [name=Adnan Abdulhussein]\n> 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).\n\nIn many cases, the base types in a YAML file can be used to derive a base\nschema. Thus it may be desirable to automatically derive schemata if they are\nnot supplied.\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/002-events.md",
    "content": "---\ntitle: Event-Driven Architecture\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/002-events.md\n-->\n\nThis document describes an architectural transition inside of Helm. The client-server\nmodel of Helm 2 will be replaced with a single event-driven model.\n\nHigh level logic will _emit events_, while event responders will _handle events_.\n\nSome event handlers will be internal-only. Other event handlers will be exposed\nto the new lifecycle events subsystem (with its Lua engine). Those events will\nbe open to extension.\n\n## The Lifecycle Events Architecture\n\nHelm 3 is internally reorganized around an event model. Some events are\ninternal only, while others are exposed to the Lua scripting engine. In this\nlatter case, chart authors may script certain behaviors.\n\nDuring various phases of an operation (like install), Helm will execute pre-defined\nevents. Charts will have an opportunity to respond to these events.\n\nFor example, during `helm install`, the process my look something like this:\n\n1. Load chart\n2. Merge values\n3. Emit `pre-render` event\n4. Render templates\n5. Parse resulting manifest into objects\n6. Emit `post-render` event\n7. Validate all objects\n8. Call `pre-install` event\n9. Install the manifests into Kubernetes\n10. Exit\n\n\n#### Scripting Event Handlers\n\nAn embedded Lua interpreter can load scripts at runtime, which makes it\npossible to write code which can be stored inside of a chart, but executed in\nanswer to a lifecycle event.\n\nIn Lua, executing a particular hook might look something like this:\n\n```lua\n  -- events is used to register event handlers.\n  events.on(\"pre-render\", 0.5, function (_)\n      -- Accessing an object\n      print(\"got chart \" + _.chart.name)\n      -- Mutating an object\n      _.values.myvalue = \"My Value\"\n  end)\n```\n\nThe event handler format is: `events.on(_)`, where `_` is a variable pointing to\na context object (see next section).\n\n### Script locations\n\nScripts are stored inside charts. They are stored in charts for the following\nreasons:\n\n- Charts remain self-contained. There is no need to negotiate on which plugins\n  a chart needs.\n- Dependency resolution is relegated to the chart scope\n- The ordering problem is clearly solved (see below) if the scripts are located\n  inside of the chart.\n\n\nLua scripts are stored in a chart's `ext/lua` folder. The `ext/lua/chart.lua` file\nis loaded automatically along with the chart, and it may `require()` in other\nLua scripts.\n\nThe order of loading goes like this:\n\n1. Chart is verified (if requested) against `.prov` file\n2. Chart is loaded into memory\n3. Chart.yaml is parsed, validated, and loaded\n4. `ext/lua/chart.lua` files are parsed and loaded into a runtime\n5. `chart-loaded` event is fired on chart that was loaded\n\n> Note: Values from `-f` and `--set` are coalesced prior to chart loading.\n\nCharts and subcharts may each have Lua. When events are triggered, the event\nhandler will do a depth-first execution of the `chart.lua` files, ending with the\ntopmost `chart.lua` file.\n\n## The Context Object for Events\n\nEvery event will receive a context, which will contain data about that event. In pseudo-code, the context stucture looks like this:\n\n```lua\ncontext = {\n  -- Loaded from chart.yaml\n  chart = {\n    version = function () return \"v2\" end,\n    name = function () return \"alpine\" end,\n    version = function () return \"1.1.0\" end,\n    description = function() return \"This is an example chart.\" end,\n    keywords = function() return { \"alpine\", \"utility\", \"debugging\" } end,\n    home = function() return \"https://docs.helm.sh\" end,\n    sources = function() return { \"https://github.com/helm/helm\" } end,\n    maintainers = function() return {\n      name = \"M Butcher\",\n      email = \"mbutcher@example.com\",\n      url = \"http://mbutcher.example.com\"\n    } end,\n    icon = function() return \"https://example.com/alpine.svg\" end,\n    appVersion = function() return \"3.8\" end,\n    kubernetesVersions = function() return \">1.9.0\" end,\n  },\n  -- All user-specified. None of these is hard-coded\n  values = {\n    rbac = { enabled = true },\n    image = { name = \"alpine\", tag = \"3.8\"}\n  },\n  -- These are supplied by the system and the user\n  release = {\n    name = function() return \"my-alpine\" end\n  },\n  -- Information about the cluster that Helm is currently\n  -- targeting\n  capabilities = {\n    helmVersion = function() return \"3.0.0-alpha.1\" end,\n    -- Kubernetes version, as reported by Kubernetes\n    kubernetesVersion = function() return \"1.10.0\" end,\n    apiVersions = function() return {\n      \"v1\",\n      \"batch/v1\",\n      \"batch/v2\",\n      \"batch/v2beta1\",\n      -- ...\n    } end\n  },\n  -- Files specified in the chart, exclusing templates and\n  -- the contents of ext/\n  files = {\n    { name = \"config.json\", data = \"{}\" }\n  },\n  -- Any gotopl files. Depending on the phase, modification of\n  -- these may have no impact.\n  templates = {\n    { name = \"pod.yaml\", data = \"apiVersion: v1\\nkind: Pod\\nname: {{.Release.Name }}\\n#...\" }\n  },\n  dependencies = {\n    {name = \"nginx\", version = \"1.2.0\", repository = \"https://example.com/charts\"}\n  },\n  -- Depending on phase, this may contain the list of already\n  -- rendered objects. It may be empty. Depending on the\n  -- phase, the contents of this may, on return, be preserved.\n  objects = {\n    {\n      apiVersion = \"v1\",\n      kind = \"Pod\",\n      name = \"my-alpine\"\n    }\n  }\n}\n\n```\n\nNote that some of the properties in the context are functions.\nThese are implemented as functions because their values are\nimmutable. (The implementation of the function is informational pseudo-code, and is not the real implementation.)\n\n> [name=Matt Butcher]\n> Options for subcharts: We can either collapse them into one top-level context or nest subcharts in a `charts = { context::new() }` way.\n> \n\n> [name=Stuart P. Bentley]\n> 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).\n\n## Events\n\nThis is meant to be an exhaustive list of the events that will be emitted in Helm 3.\n\nThe following are events by command. If a command is not present, then that command\nis not slated for inclusion in Helm 3.\n\nFor each command, the events are presented in the order that they occur.\n\n### Create\n\nEvents for `helm create`:\n\n- `pre-create`\n- `post-create`\n\nThe `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.\n\n### Dependency Build\n\n- `pre-dependency-build`\n- `post-dependency-build`\n\nThe `pre-` hook will have access to the base chart's context.\n\nThe `pre-` hook will be able to modify the `dependencies` object before dependencies are resolved or fetched.\n\nThe `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.\n\n### Dependency [List, Update]\nNo other `helm dependency *` commands have hooks\n\n### Delete\n\n- `pre-delete`\n\nThe `pre-delete` event will receive a minimal context. It will not receive the chart.\n\n### Fetch\n\nThere are no defined hooks for this command\n\n### Get [manifests, values]\n\nThere are no defined hooks for these commands\n\n### History\n\nThere are no defined hooks for this command\n\n### Home\n\nThere are no defined hooks for this command\n\n### Init\n\nThere are no defined hooks for this command\n\n### Inspect\n\nThere are no defined hooks for this command\n\n### Install\n\n- `pre-render`\n- `post-render`\n- `pre-install`\n\n#### pre-/post-render\n\nThe pre- and post-render events are common across several operations.\n\n`pre-render` occurs before the contents of the `context.templates` have been rendered. The `context.objects` array is thus empty prior to `pre-render`.\n\nThe `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.\n\n#### pre-install\n\nThe `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.\n\n### Lint\n\n- `pre-render`\n- `post-render`\n- `pre-lint`\n\nThe `pre-lint` event is fired after post-render, and is only fired for lint.\n\n### Package\n\n- `pre-package`\n\nThe `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.\n\n### Plugin [*]\n\nThere are no defined hooks for this command\n\n### Repo [*]\n\nThere are no defined hooks for this command\n\n### Rollback\n\n_This is dependent on a possible re-architecting of `helm rollback` that will no longer include a render phase._\n\n- `pre-render`\n- `post-render`\n- `pre-rollback`\n\nThe `pre-rollback` event fires after the post-render, and with the same context. This event only fires on rollback.\n\n### Search\n\nThere are no defined hooks for this command\n\n### Template\n\n- `pre-render`\n- `post-render`\n- `post-template` (name may change)\n\nThe `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.\n\n### Test\n\n- `pre-render`\n- `post-render`\n- `pre-test`\n- `post-test`\n- `failed-test`\n\n`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.\n\n### Upgrade\n\n- `pre-render`\n- `post-render`\n- `pre-upgrade`\n- `post-upgrade`\n\nThe `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.\n\n### Verify\n\nThere are no defined hooks for this command\n\n### Version\n\nThere are no defined hooks for this command\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/003-state.md",
    "content": "---\ntitle: State Management\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/003-state.md\n-->\n\nThis document explains how state management works in absense of Tiller. Largely,\nit is the same model with a few changes to eliminate conflicts during race conditions.\n\n## State Storage\n\nIn Helm v3, state is tracked in-cluster by a pair of objects:\n\n- The Release object (CRD): Represents an instance of an application\n- The release version Secret: Represents a version of an instance of an application\n\nA `helm install` creates an Application,\na Release, and a Secret. A `helm upgrade` requires an existing Application and\nRelease (which it may modify), and creates a new Secret that contains the new\nvalues and rendered manifest.\n\n### Namespacing Changes\n\nWith Tiller gone, there is no reason to default to storing data in\n`kube-system`. Instead, Helm 3 will store release data _in the same namespace\nas the release's destination_.\n\nRelease and release version Secrets are stored **in the same namespace as the\ninstalled release itself**. In other words, if we install `nginx` into\nnamespace `foo`, then both the Release and release version Secret will also be\ninstalled into namespace `foo`.\n\nFor example, if no namespace is specified:\n\n```console\n$ helm install -n foo bar\n# everything, including Release and Secret is installed into default namespace\n```\n\nThere is now only one releavant namespace, and the _tiller namespace_ goes away:\n\n```console\n$ helm install -n foo bar --namespace=dynamite\n# installs release, releaseVersion, and un-namespaced charts into dynamite namespace.\n```\n\nAs with Helm 2, if a resource explicitly declares its own namespace (e.g. with\nmetadata.namespace=something), then Helm will install it into that namespace.\nBut since the owner references do not hold over namespaces, any such resource\nwill basically become unmanaged.\n> [name=Taylor Thomas]\n> 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\n> \n> [name=Adnan Abdulhussein]\n> Should we add the concept of a un-namespaced ClusterRelease which is created for charts that are cross-namespace?\n> \n> [name=Matt Butcher]\n> Maybe we should confirm whether or not owner references hold across namespaces. Cuz maybe this isn't actually an issue.\n\n### The Release Object\n\nThe release object contains information about a release, where a release is _a\nparticular installation of a named chart and values._ This object describes the\ntop-level metadata about a release.\n\nAt minimum, there are two necessary pieces of data a Release must track:\n\n- The name of the release\n- The currently deployed version (release version Secret) of this release\n\nThe release object persists for the duration of an application lifecycle, and is\nthe owner of all release version Secrets, as well as of all objects that are\ndirectly created by the Helm chart. (These relationships may be represented by owner references.)\n\nWith this change, release names can now be scoped to namespace, instead of\nglobally scoped as they were with Helm 2.\n\n### The release version Secret\n\nThe release version Secret ties a release to a series of revisions (install,\nupgrades, rollbacks, delete). In Helm 2, revisions were merely incremental. Install\ncreated release v1, a subsequent upgrade went to v2, and so on. And in Helm 2, \nthe Release and release version Secret were collapsed into one.\n\nFor Helm 3, a Release has one or more release version Secrets associated with it.\nThe Release object always describes the current head release. Each release version\nSecret describes just one version of that release.\n\nAn upgrade operation, for example, will create a new release version Secret, and\nthen modify the Release object to point to this new version. Rollback operations\ncan use older release version Secrets to roll back a release to a previous state.\n\nA release version secret will have the following metadata and data fields:\n\n| field | description |\n| -------- | -------- |\n| type | Always `helm.sh/release-version` |\n| metadata.name | The release name plus the version ULID |\n| metadata.labels.version | The ULID of the release |\n| metadata.labels.release | The name of the release |\n| data.userValues| The user-specified values |\n| data.chartValues | The default values specified in the chart |\n| data.manifest | The rendered manifest from this release |\n| data.chartSource | The source of the original chart |\n| data.chartName | The name and version of the original chart |\n\nGiven the above, the following operations are redescribed:\n\n- `helm get manifest` gets `data.manifest`\n- `helm get values` gets `data.userValues`\n- `helm get values --all` gets `data.userValues` and `data.chartValues`\n- `helm upgrade --reuse-values` uses `data.userValues`and `data.chartValues`\n\nThe owner reference of the secret will be set to the Release object.\n\n### Versions are ULIDs, not incremented integers\nHelm 2 used incremented integers for version numbering. This is changing.\n\nVersion increments are ULIDs, not SemVer or integer counters. This is to\nprevent any race conditions when two revisions are pushed in near proximity.\nThe version incrementor need not be negotiated with ULID; each new ULID is\ntime-bound, but unique.\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/004-hooks.md",
    "content": "---\ntitle: Hook Annotations\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/004-hooks.md\n-->\n\nIn Helm 2, hook annotations could be placed on various manifests, and those\nannotations would result in special treatment.\n\nIn Helm 2, resources with hook annotations were unmanaged. In Helm 3, the owner\nreference is set on those, and they will be removed when the chart is deleted.\nThere will be a way to override the management policy by setting an annotation\nfor `helm.sh/hook-policy: unmanaged`\n\n> [name=Taylor Thomas] Would hooks be needed anymore with the new eventing\n> system? I think all we would need is something that can translate Helm v2\n> hooks into the new events behind the scenes\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/005-plugins.md",
    "content": "---\ntitle: Plugins\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/005-plugins.md\n-->\n\nThe plugin model will undergo a few changes in order to make it possible to\nsupport 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`.\n\n* [Plugin Format](#plugin-format)\n* [Installing Plugins](#installing-plugins)\n\n## Plugin Format\n\n### Standard Plugins\n\nThe existing plugin model (based on `exec` to local binaries) will continue to\nbe supported.\n\nThe current YAML format for `plugin.yaml` will be extended as follows:\n\n```\nname: \"last\"\nversion: \"0.1.0\"\nusage: \"get the last release name\"\ndescription: \"get the last release name\"\ncommand: \"$HELM_BIN --host $TILLER_HOST list --short --max 1 --date -r\"\n# New part:\nplatformCommand:\n  - os: linux\n    arch: i386\n    command: \"$HELM_BIN list --short --max 1 --date -r\"\n  - os: windows\n    arch: amd64\n    command: \"$HELM_BIN list --short --max 1 --date -r\"\n```\n\nThe `platformCommand` section defines OS/Architecture specific variations of a\ncommand.\n\nThe following rules will apply to processing commands:\n\n- If platformCommand is present, it will be searched first.\n- If both OS and Arch match the current platform, search will stop and the \n  command will be executed\n- If OS matches and there is no more specific match, the command will be executed\n- If no OS/Arch match is found, the default `command` will be executed\n- If no `command` is present and no matches are found in `platformCommand`, Helm\n  will exit with an error.\n\n### Lua Plugins\n\nThe existing Helm plugin mechanism has enabled numerous extensions to Helm\n(e.g., [here](https://docs.helm.sh/related/#helm-plugins) and\n[here](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)).\nWhile this has been useful there have been two shortcomings:\n\n1. Many plugins are written as shell scripts assuming a POSIX environment and\n   familiar linux-style userland. Helm, and Kubernetes as a whole, supports\n   windows where these plugins don't work natively.\n2. Other plugins are written in a compiled language (e.g., Go) or a general\n   scripting language (e.g., Python) that have system dependencies in order to\n   work. These can have version complications as well (e.g., a system Python of\n   3 and a plugin Python need of 2.7).\n\nAlong with Helm supporting Lua for scripting chart extensions, it will support\nplugins in Lua. These plugins will only have a dependency on Helm to run and\ncan be ported cross platform.\n\nLua plugins _are executed separately_ from chart-based Lua scripts. The pattern\nused for executing Lua plugins mirrors the pattern for writing command-line\napplications. A `main()` function will be executed with access to STDIN, STDOUT,\nSTDERR, and all command-line parameters and options.\n\n#### Lua Plugin Sandboxing\n\nLike charts, each plugin will be executed in an isolated Lua sandbox. Unlike\nchart scripts, plugins will be granted access to all core libraries, and will\nnot require security prompts to accept.\n\n## Installing Plugins\nA single plugin can be installed via `helm plugin install`.\n\nA set of plugins can also be defined in a yaml file and installed during the `helm init` process by using a flag called `--plugins <file.yaml>`\nwhere `file.yaml` looks like this:\n```\nplugins:\n- name: helm-template\n  url: https://github.com/technosophos/helm-template\n- name: helm-value-store\n  url: https://github.com/skuid/helm-value-store\n- name: helm-diff\n  url: https://github.com/databus23/helm-diff\n```\n\nThe `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.\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/006-repositories.md",
    "content": "---\ntitle: Repositories\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/006-repositories.md\n-->\n\nThe following changes will be made to the repository subsystem:\n\n- The `helm serve` command will be removed\n- A new `helm push` verb will be added for pushing charts to a repository\n- The index file will be JSON instead of YAML\n\n> This document is in-progress and needs input from Chart Museum.\n\n## Pushing Charts To A Repository\n\nSeveral registries have emerged with support for Helm charts including\nChartMuseum and Quay (via Application Registries) along with extras built on\ntop of other systems, such as object storage (e.g., see the [S3\nPlugin](https://github.com/hypnoglow/helm-s3)). These registries are asking for\nand could benefit from a capability to push packages from the Helm client.\n\nTo support registries there will be a `helm push` command that works in a\nsimilar manner to `helm fetch`. It will support different systems via the\nURI/URL scheme and provide a default implementation for HTTP(S). Other systems,\nsuch as S3, can implement an uploader via a plugin for schemes Helm does not\nprovide an implementation for.\n\n> [name=Matt Farina] There very well may be additional work here around\n> registry search and pluggable or otherwise extendable authenication\n> mechanisms.\n> \n> [name=Adnan Abdulhussein] What would the default HTTP(S) implementation be?\n> [name=Matt Fisher] Adnan, would you mind clarifying your comment a little?\n> \n> [name=Adnan Abdulhussein] Sorry, the proposal mentions there will be a\n> default implemention for `helm push` to a regular HTTP(S) chart repository.\n> It's unclear to me how this would actually work.\n> \n> [name=Adnan Abdulhussein] Sounds like this is something that will be fleshed\n> out more in Josh's proposal, so I'll wait for that :)\n\n## Repository v2 Specification\n\nHelm v3 will use a second version of the repository specification. For backwards\ncompatibility, v1 of the specification will be supported but deprecated.\n\nThe new version of the repository specification will make the following changes\nfrom version 1.\n\nFirst, the `apiVersion` field will be incremented to `v2`. This will signal a\nbreaking change.\n\nSecond, the file format will be changed from YAML to JSON. JSON is more memory\nefficient than YAML to parse. This is in part due to anchors and references in\nYAML.\n\nThird, there will be 2 types of files. The `index.json` file will hold the top\nlevel details about the repository. Alongside that there will be JSON files for\neach chart in the repository. These chart JSON files will contain the details\nabout the revisions of the chart.\n\nThe following two examples illustrate index and chart JSON files:\n\n```json\n{\n  \"apiVersion\": \"v2\",\n  \"entries\": {\n    \"artifactory\": {\n      \"ref\": \"https://kubernetes-charts-incubator.storage.googleapis.com/artifactory.json\",\n      \"stable\": {\n        \"created\": \"2017-07-06T01:33:50.952Z\",\n        \"description\": \"Universal Repository Manager supporting all major packaging formats,\\nbuild tools and CI servers.\",\n        \"digest\": \"249e27501dbfe1bd93d4039b04440f0ff19c707ba720540f391b5aefa3571455\",\n        \"home\": \"https://www.jfrog.com/artifactory/\",\n        \"icon\": \"https://raw.githubusercontent.com/JFrogDev/artifactory-dcos/master/images/jfrog_med.png\",\n        \"keywords\": [\n          \"artifactory\",\n          \"jfrog\"\n        ],\n        \"maintainers\": [\n          {\n            \"email\": \"[redacted]\",\n            \"name\": \"[redacted]\"\n          }\n        ],\n        \"name\": \"artifactory\",\n        \"sources\": [\n          \"https://bintray.com/jfrog/product/JFrog-Artifactory-Pro/view\",\n          \"https://github.com/JFrogDev\"\n        ],\n        \"urls\": [\n          \"https://kubernetes-charts-incubator.storage.googleapis.com/artifactory-5.2.0.tgz\"\n        ],\n        \"version\": \"5.2.0\"\n      }\n    }\n  }\n}\n```\n\nThe example above is of the `index.json` file. An entry here has two properties.\nThe `ref` property is the location of the chart JSON file. This can be either\na relative URL path relative to the `index.json` file or an absolute path to the\nfile. The `stable` property contains the details about the latest stable release\nof the chart.\n\nThe example below is the `artifactory.json` file referred to in the index. The\ninformation for each version of the is listed under versions. This is in a similar\nformat to the repository v1 `entries` for a single chart. The different in format\nis that an object with versions as keys is used instead of an array as seen in\nthe v1 specification.\n\n```json\n{\n  \"apiVersion\": \"v2\",\n  \"versions\": {\n    \"5.2.0\": {\n        \"created\": \"2017-07-06T01:33:50.952Z\",\n        \"description\": \"Universal Repository Manager supporting all major packaging formats,\\nbuild tools and CI servers.\",\n        \"digest\": \"249e27501dbfe1bd93d4039b04440f0ff19c707ba720540f391b5aefa3571455\",\n        \"home\": \"https://www.jfrog.com/artifactory/\",\n        \"icon\": \"https://raw.githubusercontent.com/JFrogDev/artifactory-dcos/master/images/jfrog_med.png\",\n        \"keywords\": [\n            \"artifactory\",\n            \"jfrog\"\n        ],\n        \"maintainers\": [\n            {\n            \"email\": \"[redacted\",\n            \"name\": \"[redacted\"\n            }\n        ],\n        \"name\": \"artifactory\",\n        \"sources\": [\n            \"https://bintray.com/jfrog/product/JFrog-Artifactory-Pro/view\",\n            \"https://github.com/JFrogDev\"\n        ],\n        \"urls\": [\n            \"https://kubernetes-charts-incubator.storage.googleapis.com/artifactory-5.2.0.tgz\"\n        ],\n        \"version\": \"5.2.0\"\n    },\n    \"5.1.0\": {\n        \"created\": \"2017-05-03T23:49:01.558Z\",\n        \"description\": \"Universal Repository Manager supporting all major packaging formats,\\nbuild tools and CI servers.\",\n        \"digest\": \"1ce86533fca59c77e52d32138c80c332c5102557fd79f9af4afbbd7e93b9f105\",\n        \"home\": \"https://www.jfrog.com/artifactory/\",\n        \"icon\": \"https://raw.githubusercontent.com/JFrogDev/artifactory-dcos/master/images/jfrog_med.png\",\n        \"keywords\": [\n            \"artifactory\",\n            \"jfrog\"\n        ],\n        \"maintainers\": [\n            {\n            \"email\": \"[redacted\",\n            \"name\": \"[redacted\"\n            }\n        ],\n        \"name\": \"artifactory\",\n        \"sources\": [\n            \"https://bintray.com/jfrog/product/JFrog-Artifactory-Pro/view\",\n            \"https://github.com/JFrogDev\"\n        ],\n        \"urls\": [\n            \"https://kubernetes-charts-incubator.storage.googleapis.com/artifactory-5.1.0.tgz\"\n        ],\n        \"version\": \"5.1.0\"\n    }\n    ...\n  }\n}\n```\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/007-security.md",
    "content": "---\ntitle: Security Considerations\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/007-security.md\n-->\n\nThis architecture for Helm is more secure than Helm 2 (and equally secure to\nHelm Classic). The following security goals are met by this proposal:\n\n- Helm now runs with the ID and permissions of the UserAccount or\n  ServiceAccount executing the commands.\n- RBAC can now be applied to each user\n- On-the-wire security is as secure as the cluster is configured to be (e.g. if\n  KUBECONFIG is set up for mTLS, that's what we use)\n- Auditability is now a feature of the cluster, as each chart is \"created by\"\n  the user who runs the request\n- In-cluster CRDs can be secured with RBAC, too, providing access controls for\n  releases.\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/008-controller.md",
    "content": "---\ntitle: \"Appendix A: A Helm Controller\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/008-controller.md\n-->\n\n> This section is a placeholder until a detailed proposal is written.\n\nThis section describes a second implementation of Helm. The goal of this\nimplementation is to provide a controller/CRD façade for the core Helm\nfeatures. _However, defining the specifics of this controller was deemed\noutside of the scope of this proposal, which focuses on the reference\nimplementation of the Helm CLI_.\n\nA client-only Helm follows a push-based model. To facilitate a pull-based\nmodel, we can also create a Helm controller that provides a CRD facade, but\nuses the Helm library.\n\nIt is suggested that this (a) be a core Helm project, but (b) is kept\nseparately from the main Helm codebase.\n\nThis controller accepts Chart and values configuration as a new `HelmRequest`\nCRD, and then provides the following operations:\n\n- Install\n- Upgrade\n- Delete\n- Get\n- List\n\nJust like the client, the controller will operate on Release and release\nversion Secret. For that reason, the Helm CLI and the Helm CRD can be used in\nconjunction, and RBACs can even be applied to lock down certain features for\none or the other. (For example, Helm CLI may be restricted to only read\nfunctions, while the controller can perform read and write operations)\n\n> [name=Adnan Abdulhussein] How will the controller apply a user's RBAC\n> permissions when installing a chart? Or is this not possible, and the\n> controller will need to be restricted using service accounts?  [name=Matt\n> Fisher] It is not possible to apply a user's RBAC permissions when installing\n> a chart via this model, which is why we decided to remove Tiller in Helm 3.\n\nThis implementation will necessarily have some limitations and restrictions\nthat the client Helm does not; namely, it will not be able to handle large\ncharts because there is a 1M limit to CRD size.\n\nIt is also assumed that the controller model may not choose to implement a\nnumber of the client features, such as dry runs, repository management, chart\ncreation, etc.\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/009-package_manager.md",
    "content": "---\ntitle: \"Appendix B: What Is a Package Manager?\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/009-package_manager.md\n-->\n\nIf Helm is \"the package manager for Kubernetes\", we need to have a common\nexplanation of what we mean by \"package manager\".\n\nHelm's notion of package management is informed by _operating system package\nmanagers_ such as:\n - [APT](https://www.debian.org/doc/manuals/debian-reference/ch02.en.html)\n - [RPM](http://rpm.org/documentation.html)\n - [Homebrew](https://docs.brew.sh/)\n - [APK](https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management)\n - [Portage](https://wiki.gentoo.org/wiki/Portage)\n - [Snap](https://docs.snapcraft.io/core/)\n\nIt is important to not overzealously compare Helm to programming language\nlibrary package managers, as such systems have a fundamentally different goal.\n\nPackage managers such as Apt, Homebrew, and RPM provide the following services:\n\n- They define a package format\n- They define a package repository architecture\n- They define a security model (signing, verification, etc)\n- They specify a programming langugage (or languages) to be used for management\n  logic (e.g. shell scripts, Ruby)\n- They manage the installation, upgrade, and deletion of a package\n- They provide dependency resolution features and version management\n- They expose configuration options that the user may override\n- They start services (e.g. when installing a database, the database is\n  started) and often provide tooling for administrators to manage those\n  services (e.g. systemd/upstart/sysV init scripts)\n- They provide tools to search, list, and discover packages\n- They implement (or make it easy to implement) environment-specific (os,\n  processor, distro) optimizations\n- They provide an opinion as to how to best construct and maintain packages\n- They surface documentation (typically via output during installation)\n\nPackage managers tend to involve all of these because it is important in\npackage management to keep external dependencies to a minimum.\n\nConsequently, if Helm is to fit into such a paradigm, it is natural that Helm\nwill provide at least most, if not all of these.\n\nHelm is not a configuration management tool (such as Chef or Puppet). Helm does\nprovide certain features of such systems, though. Helm's templating and\nconfiguration model is a common feature of configuration managers (and also of\npackage managers).\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/010-removed.md",
    "content": "---\ntitle: \"Appendx C: Removed Sections\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/010-removed.md\n-->\n\nThe following parts of the proposal have been removed.\n\n## Overlays\n\nAn earlier draft included a provision for overlaying templates within charts. This section\nwas removed once we realized that the same thing can be easily accomplished using\nthe `post-render` event and some trivial Lua.\n\nThis appendix will be removed before the final proposal.\n\n## Chart.yaml refactored as Kubernetes resource\n\nAn earlier draft proposed formatting Chart.yaml as a Kubernetes resource. However,\nit became evident that there was no intention of installing the Chart.yaml into\nthe cluster, at which point it did not make sense to retain that functionality.\n\n## Application CRD\n\nEarlier drafts contained information about implementing the Application CRD\nproposal as a feature of Helm.\n\nWhile there is a plan to support Application CRD in Helm, it will not be a\nrequired feature of Helm. For that reason, it has been removed from the proposal.\n\n## Alternatives to Lua extensions\n\nThe following alternatives were proposed:\n\n- Implement lifecycle event handlers as containers in-cluster\n- Reimplement Helm in Python|Ruby|TypeScript|JavaScript\n- Extend Plugins to be event handlers\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/011-user_stories.md",
    "content": "---\ntitle: Helm v3 User Stories\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/011-user_stories.md\n-->\n\nThis 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).\n\n## 1. Application Operator\n\n1. 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\n1. 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)\n1. In order to have a secure system as an application operator, I want Helm to install/upgrade/delete based on the user’s credentials\n1. 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\n1. In order to have a secure system as an application operator, I want out-of-the-box “easy security”\n1. In order to have a secure system as an application operator, I want RBACs done for me\n1. In order to have a secure system as an application operator, I want to audit what charts have been deployed\n1. 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\n1. 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\n1. In order to easily get started as an application operator, I want to easily install and use Helm\n\n## 2. Application Distributor\n\n1. As an application distributor, I want to develop charts using a template engine of my choice (e.g., Jinja, KSonnet, JSonnet)\n1. In order to have reusability as an application distributor, I want to use common libraries to build charts\n1. As an application distributor, I want to be able to override chart templates (e.g., those in dependency charts)\n1. As an application distributor, I want to intercept rendered YAML/JSON and do last-mile modifications (e.g. insert or remove)\n1. As an application distributor, I want lifecycle hooks for pre- and post-render operations\n1. As an application distributor, I want to be able to do simple variable substitution in values.yaml (and reference in --set)\n\n## 3. Application Developer\n\n1. As a application developer, I want to automatically pull charts so that my local env looks like production\n\n## 4. Supporting Tool Developer\n\n1. As a supporting tool developer, I want to interact with Helm without using gRPC.\n1. As a supporting tool developer, I want to write plugins that intercept hooks\n1. As a supporting tool developer, I want to be able to write alternate back-ends (for deploying)\n\n## 5. Helm Developer\n\n1. TBD\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/012-chart-dev-stories.md",
    "content": "---\ntitle: Chart v3 User Stories\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/012-chart-dev-stories.md\n-->\n\nThis document contains user stories for Helm3 Charts. User stories provide guidance,\nbut are not necessarily a list of requirements.\n\nAll stories in this document are implicitly prefaced with \"As a Chart Developer...\"\nand are of the form \"As a _ROLE_ I want _TASK_ so that _GOAL_.\n\n\n## General\n\n- I want to re-use Helm 2 charts so that I don't have to rebuild the same thing\n- I want to create charts the Helm 2 way so that I can continue developing\n  the way I have been\n- I do not want to have to understand all the details of every\n  subchart I use so that I can compose complex applications quickly\n\n## Extensions/Lua\n\nThese 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\n\n### Values\n\n- I want programmatic access to subchart values so that I can access defaults\n- I want access to modify subchart values so that I can explicitly set a value\n  for a subchart\n- I want late access to a subchart's values so that I can discover any values\n  that a subchart's scripts computed\n- I want to use Lua to validate values before templates are rendered so that I\n  can alert users to unexpected values before install fails\n- I want to use Lua to modify values in subcharts programmatically so that I can\n  expose a top-level set of values and computer subchart values\n- I want to use Lua to alter subchart values so that I can read the values of one\n  subchart and rewrite the values in another subchart (e.g. configuring a proxy\n  based on the settings for a database or web server)\n- I want to be able to intercept values in a top-level chart before _and_ after a\n  subchart's event handler executes so that I can pre-seed data, let the subchart\n  calculate results, and then retrieve and use those results. (e.g. SSL certificate\n  generation)\n\n### Templates\n- I want to define template functions in Lua so that I can easily write custom\n  template functions\n- I want to render templates using a different template engine so that I can\n  use my preferred template engine\n  * Option A: Template engine implemented in pure Lua\n  * Option B: Template engine invoked via `exec` call\n- I want to intercept a template before it is rendered and be able to alter it so\n  that I can dynamically replace parts of a template (example: regexp replace\n  one template function/include with another)\n- I want to replace a template in a subchart before it is rendred so that I can\n  rewrite part of a chart dynamically\n\n### Rendered Manifests\n\n- I want to modify a generated manifest so that I can insert additional\n  information (e.g. Istio sidecar)\n- I want to delete a generated manifest prior to it being loaded so that I can\n  prevent an object from being created (e.g. subchart creates a manifest I don't\n  want)\n- I want to add a new manifest post-render so that I can create an object based\n  on the results of a render process (e.g. RBAC generation, service generation,\n  storage class generation)\n\n### Feature Discovery\n\n- I want to query Kubernetes to see if a CRD exists so that I can decide whether\n  to include a CRD definition\n- I want to query whether a cluster supports RBAC so that I can decide whether\n  to add RBAC rules\n- I want to query for StorageClass so that I can pick an appropriate one for my\n  PVC\n- I want to look up DNS address (e.g. service discovery) so that I can find an\n  endpoint, IP, or URL before installing/upgrading\n\n### Events\n\n- I want to declare a function that responds to an event (e.g. \"render\") so that\n  I can modify a chart/values at a particular point in the lifecycle\n- I want to allow subcharts to run their event handlers by default so that I don't\n  have to read all of the subcharts to know what they do\n- I want to be able to turn off a subchart's lifecycle event by name so that I can\n  disable a particular event handler\n- I want to turn off all event handlers for a chart so that I can prevent it from\n  intercepting any events\n- I want to have an opportunity to initialize my chart's code every time it is loaded\n  so that my chart can be initialized into a known state consistently\n- I want to be able to perform installation-specific actions before an install so\n  that I can do custom install logic\n- I want to be able to perform post-installation actions so that I can set up an\n  application (or notify the user about an installation) after the app has been\n  submitted to Kubernetes\n- I want to be able to do upgrade-specific logic before the upgrade has been submitted\n  to Kubernetes\n- I want to be able to do post-upgrade logic so that I can set up an app or\n  notify a user\n- I want to do custom logic before an app is deleted so that I can prepare for\n  a deletion\n- I want to do custom logic after a deletion so that I can ensure that a teardown\n  is successful (e.g. if no other apps are using a namespace, delete teh namespace;\n  if no other apps are using a CRD, delete the CRD definition...)\n- I want to be able to declare custom logic that determines whether an installed\n  or upgrade application is considered _ready_.\n- I want to be able to perform specific logic when an application is considered\n  ready.\n\n### Lua Libraries and Access\n\n- I want to be able to break my Lua script into multiple files so that I can organize\n  my code\n- I want to be able to import code from subcharts so that I can re-use existing\n  code\n- I want to import existing pure Lua libraries that are stored in charts\n- I want to use standard Lua libraries that do not have access to network or\n  filesystem\n- I want to optionally use network and filesystem libraries if approved by the\n  user so that I can perform IO within a chart\n\n## Library Charts\n\n- I want to use charts as template definition libraries so that I can re-use\n  common template code\n- I want to use charts as containers for Lua libraries so that I can re-use\n  Lua code\n\n## Additional Considerations\n\n- There are charts like OpenStack that have dozens of subcharts (and sub-subcharts)\n"
  },
  {
    "path": "community/hips/archives/helm/helm-v3/research/package-manager-ux.md",
    "content": "---\ntitle: Package Manager UX\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/helm/helm-v3/research/package-manager-ux.md\n-->\n\nThis document is for usability research on the UX and interaction interface for other package managers.\n\n(This re-creates some of the work done during the Helm 1 and Helm 2 planning cycles.)\n\n## A Goal of Helm: Follow Existing Patterns\n\nTo reduce the cognitive overhead of Helm, one of Helm's UX goals is to follow the patterns set down by other package managers.\n\nMatching the UX of `kubectl` is of secondary importance.\n\nIn practice, this plays out as follows:\n\n- When considering Helm's package managemet operations, Helm _should_ follow the patterns and practices of other package management tools.\n- 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.\n- In more general circumstances, Helm _should_ follow the _de facto_ patterns found in contemporary Linux/UNIX tooling.\n\nHelm _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.\n\n## Package Managers and Their Characteristics\n\nThe 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.\n\n| Tool     | Type | Cmd    | Install | Upgrade        | Delete       | Create | Repo Update | Search           | About Pkg      |\n| ----     | ---- | ------ | ------- | -------        | ------       | ------ | ----------- | ------           | ---------      |\n| apt-get  | OS   | y      | install | upgrade        | remove       | -      | update      | apt-cache search | apt-cache show |\n| yum      | OS   | y      | install | update/upgrade | remove/erase | -      | -           | search           | info           |\n| brew     | OS   | y      | install | upgrade        | uninstall    | create | update      | search           | info           |\n| pacman   | OS   | n      | --sync  | --upgrade      | --remove     | -      | --refresh   | --query          | --query        |\n| emerge   | OS   | n      | -       | -              | --unmerge    | -      | --sync      | --search         | --search       |\n| choco    | OS   | y      | install | upgrade        | uninstall    | new    | ~update~    | search           | info           |\n| npm      | Lang | y      | install | update/upgrade | uninstall/rm | init/create | -      | search           | view/info/show |\n| pod      | Lang | y      | install | update         | -            | spec create | -      | search           | search         |\n| pip      | Lang | y      | install | install -U     | uninstall    | -      | -           | search           | show           |\n| composer | Lang | y      | install | update         | remove       | init   | -           | search           | show           |\n| kubectl  | -    | y      | create  | apply          | delete       | create | -           | -                | -              |\n| helm 2   | CN   | y      | install | upgrade        | delete       | create | update      | search           | inspect        |\n\nNote that `kubectl` is included for reference, though it is _not_ a package manager, and is not weighed into the results below.\n\nOther 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`).\n\n### Apt\n\n- Apt uses multiple tools. `apt-get` and `apt-cache` are the most frequently used.\n- Apt does not layer subcomments. There are only direct subcommands and flags\n- Create new packages with other tools\n\n### Yum\n\n- Yum layers subcommands, but without a consistent pattern:\n    - `yum clean headers` (NOUN VERB NOUN)\n    - `yum version groupinfo` (NOUN NOUN NOUN)\n    - `yum groups install` (NOUN NOUN VERB)\n- Yum syncs with remote repositories based on local configuration\n- Create new packages with RPM commands\n\n### Brew\n\nNo notes\n\n### Pacman\n\nArch 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).\n\nCommands 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`.)\n\n- `pacman` updates from remote repos as needed (when specified to do so by the user, usually as part of a `--sync` installation/upgrade operation).\n- Search is multi-modal, being able to describe packages as well as listing them\n\n### Emerge (Portage)\n\n- Create new packages with `ebuild`\n- `emerge PKG` handles install and upgrade. In other words, installation is the default action\n\n### choco (Chocolatey)\n\n- The `update` command is deprecated, and future version will sync differently\n\n### NPM\n\n- Fun fact: `npm isntall` is an alias for `npm install`, as is `npm add` and `npm i`.\n- Update, upgrade, and up are aliases\n- Uninstall, remove, rm, and un are aliases\n- view, info, and show are aliases\n\n### pod (cocoapods)\n\n- Supports subcommands, usually as NOUN NOUN VERB (`pod spec create`), but occasionally NOUN NOUN NOUN (`pod trunk info`)\n- I cannot find docs on how to remove a pod\n\n### pip\n\n- A few commands have subcommands in the form NOUN NOUN VERB (`pip config get`)\n\n### Composer\n\nComposer is the PHP package manager.\n\n- `composer` has only one level of commands, but uses flags for subcommands (`composer config --list`).\n- The exception to the above, though, is the `compoers global` command, which is NOUN NOUN VERB or NOUN NOUN NOUN.\n\n### kubectl\n\n`kubectl` is not a package manager, but has subcommands that are similar to package managers\n\n- `create` combines generation and installation\n- Upgrading can be done several different ways, each with a separate verb: `apply`, `edit`, `patch`, `convert`, and `replace`\n- There is no standard pattern to `kubectl`'s subcommands:\n    - `kubectl get` (NOUN VERB)\n    - `kubectl logs` (NOUN NOUN)\n    - `kubectl config view` (NOUN NOUN VERB)\n    - `kubectl config current-context` (NOUN NOUN NOUN)\n- 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.\n\n## Analysis of Results\n\nCommonalities between package managers:\n\n- 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).\n- 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.\n    - For subcommands, the `NOUN NOUN VERB` pattern was the most common, but definitely not the only option.\n    - The only discernable pattern used for seperating top level and multi-level commands is: \"popular operations are top level\"\n    - 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).\n- Aliases are supported in a few tools\n- `upgrade` is general preferred over `update` for describing the process of installing a newer version of an existing package\n- For package managers that support synchronizing a local cache with a remote auhtority, `update` is the preferred term, in spite of its ambiguity.\n- For the package managers that support scaffolding out new packages, `create` is the most widely used term.\n- `show` and `info` are about equal in representation for showing package information. `inspect`, which Helm uses, is not represented in any other package manager.\n- For deleting a package, `remove` is the most common term, followed closely by `uninstall`.\n- None of the examined systems had more than three layers of commands: `CMD SUBCMD SUBCMD`.\n\n## Recommendations for Helm 3\n\nThe following commands should be changed (with the old name aliased to the new name):\n\n- `helm delete` should be renamed `helm remove`\n- `helm inspect` should be renamed `helm show`\n\nWhile there is little to draw from, it might be prudent to rename `helm fetch` to `helm download`.\n\nAfter 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.\n\nNo other changes are necessary for Helm to fit in with the common idioms found in package managers.\n\n_Note:_ The Helm 2 `reset` command is no longer present in Helm 3. Earlier discussions about renaming it are no longer relevant.\n"
  },
  {
    "path": "community/hips/archives/monocular/1.0-improvements.md",
    "content": "---\ntitle: \"Proposal: Monocular 1.0 - improvements and redefining project focus\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/archives/monocular/1.0-improvements.md\n-->\n\nMonocular 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).\n\nAs 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.\n\nThe 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.\n\n## Replacing the Monocular API server\n\nThe 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.\n\nThe [Kubeapps project](https://github.com/kubeapps/kubeapps) includes components that will be contributed back to Monocular to achieve this.\n\n### Storing chart metadata in a database\n\nIn 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.\n\nThis 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.\n\n### Chartsvc\n\n[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.\n\n### Syncing chart repositories\n\nOne 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.\n\nThe [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.\n\n[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.\n\n\n## Removing in-cluster support\n\nMonocular 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.\n\nProviding 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/)).\n\nTo 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.\n"
  },
  {
    "path": "community/hips/hip-0001.md",
    "content": "---\ntitle: Writing a HIP\nsidebar_label: \"0001: Writing a HIP\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0001.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0001 | Writing a HIP | Matthew Fisher <matt.fisher@microsoft.com> | 2020-08-13 | process | accepted |\n\n\n## Abstract\n\nA HIP is a Helm Improvement Proposal. It is a design document providing\ninformation to the Helm community, or describing a new feature for a Helm\nproject or its processes or environment. The proposal should provide a concise\ntechnical specification of the feature and a rationale for the feature.\n\nWe intend HIPs to be the primary mechanisms for proposing major new features,\nfor collecting community input on an issue, and for documenting the design\ndecisions that have gone into the project. The proposal author is responsible\nfor building consensus within the community and documenting dissenting opinions.\n\nThe system is heavily influenced by Python's Enhancement Proposal (PEP) system,\nhence the name. Given that Helm is a much (MUCH) smaller project than Python,\nthere are a few changes in the HIP workflow to make it a looser format for\nproposals, most notably the lack of proposal \"editors\", a BDFL, and a much\nsmaller review & resolution cycle.\n\nBecause the proposals are maintained as markdown files in a versioned\nrepository, their revision history is the historical record of the proposal.\n\n## Audience\n\nThe typical primary audience for proposals are the project maintainers for each\nHelm project, as well as the Helm project's org maintainers.\n\nHowever, other parts of the Helm community may also choose to use the process\n(particularly for informational proposals) to document expected conventions and\nto manage complex design coordination problems that require collaboration across\nmultiple projects.\n\n## HIP types\n\nThere are three kinds of proposals:\n\n1. A **feature** proposal describes a new feature or implementation for the Helm\n   project. It may also describe an interoperability standard that will be\n   supported by the Helm project.\n1. An **informational** proposal describes a Helm design issue, or provides\n   general guidelines or information to the Helm community, but does not propose\n   a new feature. Informational proposals do not necessarily represent a Helm\n   community consensus or recommendation, so users and implementers are free to\n   ignore informational proposals or follow their advice.\n1. A **process** proposal describes a process surrounding the Helm project, or\n   proposes a change to (or an event in) a process. Process proposals are like\n   feature proposals, but apply to areas other than the Helm project itself.\n   They may propose an implementation, but not to Helm's codebase; they often\n   require community consensus. Unlike informational proposals, they are more\n   than recommendations, and users are typically not free to ignore them.\n   Examples include procedures, guidelines, changes to the decision-making\n   process, and changes to the tools or environment used in Helm development.\n\n## HIP workflow\n\n### Start with an idea\n\nThe proposal process begins with a new idea for the Helm project. It is highly\nrecommended that a single proposal contain a single key proposal or new idea.\nSmall enhancements or patches often don't need a proposal and can be injected\ninto a project's development workflow with a patch submission to the project's\nissue tracker. The more focused the proposal, the more successful it tends to\nbe. As per Helm's governance, the project maintainers reserve the right to\nreject proposals if they appear too unfocused, too broad, or incomplete. If in\ndoubt, split your proposal into several well-focused ones, or explain your\nproposal more clearly.\n\nEach proposal must have a champion -- someone who writes the proposal using the\nstyle and format described below, shepherds the discussions in the appropriate\ncommunication channels, and attempts to build community consensus around the\nidea. The proposal champion (a.k.a. author) should first attempt to ascertain\nwhether the idea is proposal-able. Posting to the [cncf-helm][] mailing list is\nthe best way to go about this.\n\nVetting an idea publicly before going as far as writing a proposal is meant to\nsave the potential author time. Many ideas have been brought forward for\nchanging Helm that have been rejected for various reasons. Asking the Helm\ncommunity first if an idea is original helps prevent wasting time on something\nthat is guaranteed to be rejected based on prior discussions (searching the\ninternet does not always do the trick). It also helps to make sure the idea is\n**applicable to the entire community and not just the author**. Just because an\nidea sounds good to the author does not mean it will work for most Helm users in\nmost areas where Helm is used.\n\nOnce the champion has asked the Helm community as to whether an idea has any\nchance of acceptance, a summary of the proposal should be presented to\n[cncf-helm][]. This gives the author a chance to flesh out the proposal as a\nhigh quality, well-formatted proposal, and to address initial concerns about the\nproposal.\n\n### Submitting a HIP\n\nFollowing a discussion on [cncf-helm][], the proposal should be submitted as a\nproposal via a [GitHub pull request][pr]. The proposal must be written in\nproposal style as described below, else it will fail review immediately\n(although minor errors may be corrected by the maintainers).\n\nThe standard HIP workflow is:\n\n- You, as the proposal author, fork the helm/community repository and create a\n  new proposal\n- Proposals are written in [Markdown][markdown]\n- Push your proposal to your GitHub fork and [submit a pull request][pr].\n\nOnce the review process is complete, the reviewers will approve the proposal by\ncommenting on the proposal with a \"Looks good to me\" (\"LGTM\" for short) and\nmerge the proposal. (note that this is not the same as accepting your proposal!)\n\nThe reviewers will not unreasonably deny a proposal. Reasons for denying\nproposal status include duplication of effort, being technically unsound, not\nproviding proper motivation, not addressing backwards compatibility, or not in\nkeeping with Helm's design. The core maintainers can be consulted during the\napproval phase.\n\nOnce approved, proposal authors are responsible for collecting community\nfeedback on a proposal before submitting a feature that satisfies the proposal\nfor review. However, wherever possible, long open-ended discussions on public\nmailing lists should be avoided. Strategies to keep the discussions efficient\ninclude: setting up a separate meetings for the topic, having the proposal\nauthor accept private comments in the early design phases, setting up a wiki\npage, etc. proposal authors should use their discretion here.\n\n## What belongs in a successful HIP\n\nEach HIP should include the following parts:\n\n1. Preamble - YAML style headers containing metadata about the proposal,\n   including the proposal number, a short descriptive title, the author names,\n   its current status, etc.\n1. Abstract - a short (~200 word) description of the technical issue being\n   addressed.\n1. Specification - The technical specification should describe the syntax and\n   semantics of any new feature. If the proposal describes a standard, the\n   specification should be detailed enough to describe how other community\n   members may re-implement the standard in their product.\n1. Motivation - The motivation is critical for proposals that want to change\n   Helm in a significant way. It should clearly explain why existing features\n   are inadequate to address the problem that the proposal solves, as well as\n   who and what profiles/roles are impacted by this proposal. Proposal\n   submissions without sufficient motivation may be rejected outright.\n1. Rationale - The rationale fleshes out the specification by describing what\n   motivated the design and why particular design decisions were made. It should\n   describe alternate designs that were considered and related work, e.g. how\n   the feature is supported in other projects.\n1. Backwards Compatibility - Helm projects follow [Semantic Versioning][semver].\n   Therefore, all proposals that introduce backwards incompatibilities must\n   include a section describing these incompatibilities and their severity. The\n   proposal must explain how the author proposes to deal with these\n   incompatibilities. Proposal submissions without a sufficient backwards\n   compatibility treatise may be rejected outright.\n1. Reference Implementation - The reference implementation must be completed\n   before any proposal is given status \"final\", but it need not be completed\n   before the proposal is accepted. While there is merit to the approach of\n   reaching consensus on the specification and rationale before writing code,\n   the principle of \"rough consensus and running code\" is still useful when it\n   comes to resolving many discussions of API details.\n\nThe final implementation must include test code and documentation appropriate\nfor the Helm project's reference or the community at large.\n\n### Preamble\n\nEach proposal must begin with a [YAML][yaml] style header preamble. The headers\nmust appear in the following order:\n\nHeaders marked with \"*\" are optional and are described below. All other headers\nare required.\n\n```yaml\n---\nhip: <HIP number>\ntitle: \"<HIP title>\"\nauthors: [ \"<list of authors' real names and optionally, email addresses>\" ]\ncreated: \"2020-08-13\"\ntype: \"<feature | informational | process>\"\nstatus: \"<draft | accepted | provisional | deferred | rejected | final | superseded>\"\n* helm-version: \"<version number>\"\n* requires: [ <HIP numbers> ]\n* replaces: <HIP number>\n* superseded-by: <HIP number>\n---\n```\n\nThe `authors` header lists the names, and optionally the email addresses of all\nthe authors/owners of the proposal. The format of the author header value must\nbe\n\n```yaml\nauthors: [ \"John Doe <john@example.com>\", \"Jane Doe <jane@example.com>\" ]\n```\n\nIf the email address is included, and\n\n```yaml\nauthors: [ \"John Doe\", \"Jane Doe\" ]\n```\n\nIf the address is not given.\n\nThe `created` header records the date that the proposal was published to the\nHelm project on Github. The header should be in [RFC 3339][rfc3339] format, e.g.\n2020-08-13.\n\nProposals will typically have a `helm-version` header which indicates the\nversion of Helm that the feature will be released with. Proposals without a\n`helm-version` header indicate interoperability standards that will initially be\nsupported through external libraries and tools, and then supplemented by a later\nproposal to add support to the project's client library or Command Line\nInterface. Informational and process proposals do not need a `helm-version`\nheader, and this header can be added after the implementation has been shipped\nand the proposal is marked as \"final\".\n\nProposals may have a `requires` header, indicating the proposal numbers that\nthis proposal ends on.\n\nThe `type` header specifies the type of proposal: feature, informational, or\nprocess.\n\nThe `status` header specifies which state the proposal is in. A proposal always\nbegins in \"draft\" status, and the other statuses are explained below.\n\nProposals with the `superseded` status may also have a `superseded-by` header\nindicating that a proposal has been rendered obsolete by a later document; the\nvalue is the number of the proposal that replaces the current document. The\nnewer proposal must have a `replaces` header containing the number of the\nproposal that it rendered obsolete.\n\n### Auxiliary files\n\nproposals may include auxiliary files such as diagrams. Such files must be named\nproposal-XXX-YY.ext, where \"XXX\" is the proposal number, \"YY\" is a serial number\n(starting at 01), and \"ext\" is replaced by the actual file extension (e.g.\n\"png\").\n\n## Sample template\n\nIf you intend to submit a HIP, it is highly recommended to use this template to\nensure that your HIP submission won't be automatically rejected because of form.\n\n### How to use this template\n\nTo use this template you must first decide whether your HIP is going to be an\ninformational, process, or feature HIP. Most HIPs are of type \"feature\" because\nthey propose a new feature for the Helm project or client library.\n\nOnce you've decided which type of HIP yours is going to be, make a copy of this\nfile and perform the following edits:\n\n- Do NOT change the `hip: 9999` header since you don't yet have a HIP number\n  assigned... Yet. This is to prevent merge conflicts with other HIPs.\n- Change the `title` header to the title of your HIP.\n- Change the `authors` header to include your name(s), and optionally your email\n  address(es). Be sure to follow the format carefully: your name must appear\n  first, and it must not be contained in parentheses. Your email address may\n  appear second (or it can be omitted) and if it appears, it must appear in\n  angle brackets. It is okay to obfuscate your email address.\n- Change the `created` header to the current date, following [RFC 3339][rfc3339]\n  format.\n- For feature HIPs, change the `type` header to \"feature\".\n- For informational HIPs, change the `type` header to \"informational\".\n- For process HIPs, change the `type` header to \"process\".\n- Do NOT change the `status` header from `draft`.\n- For feature HIPs, if your feature depends on the acceptance of some other\n  currently in-development HIP, add a `requires` header right after the `status`\n  header. The value should be the HIP number of the HIP yours depends on. Don't\n  add this header if your dependent feature is described in a \"final\" HIP.\n- Add a `replaces` header if your HIP obsoletes an earlier HIP. The value of\n  this header is the number of the HIP that your new HIP is replacing. Only add\n  this header if the older HIP is in \"final\" form, i.e. is either accepted,\n  final, or rejected. You aren't replacing an older open HIP if you're\n  submitting a competing idea.\n- Now write your abstract, rationale, and other content for your HIP, replacing\n  all this gobbledygook with your own text.\n- Update your references section.\n\n```markdown\n---\nhip: 9999\ntitle: \"\"\nauthors: [ \"\" ]\ncreated: \"2020-08-13\"\ntype: \"feature\"\nstatus: \"draft\"\n---\n\n## Abstract\n\nA short (~200 word) description of the technical issue being addressed.\n\n## Motivation\n\nClearly explain why the existing design is inadequate to address the problem\nthat the HIP solves.\n\n## Rationale\n\nDescribe why particular design decisions were made.\n\n## Specification\n\nDescribe the syntax and semantics of any new feature.\n\n## Backwards compatibility\n\nDescribe potential impact and severity on pre-existing code.\n\n## Security implications\n\nHow could a malicious user take advantage of this new feature?\n\n## How to teach this\n\nHow to teach users, new and experienced, how to apply the HIP to their work.\n\n## Reference implementation\n\nLink to any existing implementation and details about its state, e.g.\nproof-of-concept.\n\n## Rejected ideas\n\nWhy certain ideas that were brought while discussing this HIP were not\nultimately pursued.\n\n## Open issues\n\nAny points that are still being decided/discussed.\n\n## References\n\nA collection of URLs or materials used as references through the HIP.\n```\n\n## Proposal review & resolution\n\nOnce the authors have completed a proposal, they may request a review for style\nand consistency from the project maintainers.\n\nThe final authority for proposal approval is the project maintainers responsible\nfor the project the proposal is aimed at. However, whenever a new proposal is\nput forward, any project maintainer that believes they are suitably experienced\nto make the final decision on that proposal may offer to review the proposal,\nand they will have the authority to approve (or reject) that proposal.\nIndividuals taking on this responsibility are free to seek additional guidance\nfrom other project maintainers at any time, and are also expected to take the\nadvice and perspectives of other project maintainers into account.\n\nSuch self-nominations are accepted by default, but may be explicitly declined by\nthe project or org maintainers. Possible reasons for the maintainers declining\nanother maintainer's review include, but are not limited to, perceptions of a\npotential conflict of interest (e.g. working for the same organisation as the\nproposal submitter), or simply considering another potential maintainer to be\nmore appropriate. If project maintainers (or other community members) have\nconcerns regarding the suitability of a reviewer for any given proposal, they\nmay ask the org maintainers to review the case.\n\nTo allow gathering of additional design and interface feedback before committing\nto long term stability for a feature or client library API, a HIP may also be\nmarked as \"provisional\". This is short for \"provisionally accepted\", and\nindicates that the proposal has been accepted for inclusion in the reference\nimplementation, but additional user feedback is needed before the full design\ncan be considered \"final\". Unlike regular accepted proposals, provisionally\naccepted proposals may still be rejected **even after the related changes have\nbeen included in a project's release**.\n\nWherever possible, it is considered preferable to reduce the scope of a proposal\nto avoid the need to rely on the \"provisional\" status (e.g. by deferring some\nfeatures to later proposals), as this status can lead to version compatibility\nchallenges in the wider Helm ecosystem.\n\nA proposal can also be assigned the status \"deferred\". The proposal author or a\nmaintainer can assign the proposal this status when no progress is being made on\nthe proposal. Once a proposal is deferred, a maintainer can re-assign it to\ndraft status.\n\nA proposal can also be \"rejected\". Perhaps after all is said and done it was not\na good idea. It is still important to have a record of this fact.\n\nFeature and Informational proposals require at least 2 approvals from project\nmaintainers. Process proposals require at least 2 approvals from Helm org\nmaintainers.\n\nWhen a proposal is accepted or rejected, the proposal should be updated\naccordingly by updating the `status` field, and a link to any relevant\ninformation should be provided in the introduction.\n\n## What to do after a proposal has been approved\n\nOnce a proposal has been approved, the reference implementation must be\ncompleted. When the reference implementation is complete and incorporated into\nthe project's source code repository, the status will be marked as \"final\".\n\n## Transferring proposal ownership\n\nIt occasionally becomes necessary to transfer ownership of proposals to a new\nchampion. In general, it is preferable to retain the original author as a\nco-author of the transferred proposal, but that's really up to the original\nauthor. A good reason to transfer ownership is because the original author no\nlonger has the time or interest in updating it or following through with the\nproposal process, or has fallen off the face of the earth (i.e. is unreachable\nor not responding to email). A bad reason to transfer ownership is because the\nauthor doesn't agree with the direction of the proposal. One aim of the proposal\nprocess is to try to build consensus around a proposal, but if that's not\npossible, an author can always submit a competing proposal.\n\nIf you are interested in assuming ownership of a proposal, you can also do this\nvia pull request. Fork the helm/community repository, make your ownership\nmodification, and submit a pull request. You should also send a message asking\nto take over, addressed to both the original author and the org maintainers\n(`@helm/org-maintainers`). If the original author doesn't respond to email in a\ntimely manner, the org maintainers will make a unilateral decision (it's not\nlike these decisions can't be reversed).\n\n[cncf-helm]: mailto:cncf-helm@lists.cncf.io\n[markdown]: https://spec.commonmark.org/\n[pr]: https://github.com/helm/community/pulls\n[rfc3339]: https://tools.ietf.org/html/rfc3339\n[semver]: https://semver.org/spec/v2.0.0.html\n[yaml]: https://yaml.org/\n"
  },
  {
    "path": "community/hips/hip-0002.md",
    "content": "---\ntitle: Pre-defined release dates for Helm\nsidebar_label: \"0002: Pre-defined release dates for Helm\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0002.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0002 | Pre-defined release dates for Helm | Marc Khouzam <marc.khouzam@montreal.ca> | 2020-09-04 | process | accepted |\n\n\n## Abstract\n\nHave well-known cyclical release dates for Helm minor and patch releases.\nHave a published release date for a Helm major release, upon the availability of the first beta release.\n\n## Motivation\n\nContributors and users/organizations greatly appreciate knowing in advance when the next release will be available.\nIt 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.\n\n## Rationale\n\nMinor and patch releases for Helm normally occur a couple of times a year.  They therefore lend themselves well to cyclical, pre-defined release dates.\n\nAs 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\".\n\nHelm 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.\n\n## Specification\n### Patch releases\nPatch 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.\n\n#### Cancelling a patch release\n\nA patch release should be cancelled:\n- if it falls within one week before the first release candidate (RC1) of an upcoming minor release\n- if it falls within four weeks following a minor release\n\nAs 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.\n\n### Minor releases\nFor minor releases, it is not necessary to aim for dates that are the same every year.  Instead, the following is proposed:\n* Once a Helm minor release is made, the release date of the next minor release must be announced.\n* To align with Kubernetes releases, a 4-month minor release cadence should be adopted (so at least 3 minor releases of Helm per year)\n\nExtra minor releases can be added to the schedule when needed.  However:\n* 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.\n* 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.\n\n## Security implications\n\nSecurity releases do not follow any planned dates and should be done as soon as required.\n\n## How to teach this\n\n* When a Helm minor release is made, the next minor release number and date should be chosen and announced at the same time.\n* The Helm website should have a page mentioning each planned release and its date.  This page should be updated at each release.\n* The Helm website should have a page describing the process for release dates put forth in this HIP\n\n## Reference implementation\n\nA reference implementation for this proposal to be accepted would entail:\n* Proposing a date of the next minor release\n* Posting a PR to helm-www which:\n    * documents the next release date\n    * updates the release check-list as per the new process\n    * creates a page to document the details of this HIP for users\n* Creating a public online calendar so that maintainers can get release reminders and consumers can see the Helm release dates.  The calendar shall contain:\n    * monthly patch release dates\n    * the next minor release date (or major release date if applicable)\n    * dates when RCs must be created\n    * it may be interesting to include kubernetes release dates if available\n* A link to the release calendar shall be added to helm-www\n\n[kubernetes-dates]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#minor-version-scheme-and-timeline\n[helm-skew]: https://helm.sh/docs/topics/version_skew/#supported-version-skew\n\n"
  },
  {
    "path": "community/hips/hip-0003.md",
    "content": "---\ntitle: How Projects Join the Helm Organization\nsidebar_label: \"0003: How Projects Join the Helm Organization\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0003.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0003 | How Projects Join the Helm Organization | Matt Butcher <matt.butcher@microsoft.com> | 2020-09-30 | process | accepted |\n\n\n## Abstract\n\nHelm is an organization with multiple projects. This document describes how new projects may be added to the Helm organization.\n\n## Motivation\n\nFormalizing this process removes unspoken assumptions and makes it clear how to add a project to the Helm organization.\n\n## Rationale\n\nClarifying the process and the requirements will make it simpler, more consistent, and more transparent for projects to join the Helm organization.\n\n### Legal Requirements\n\nAny 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].\n\n### Governance Requirements\n\nAny 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].\n\nAdditionally, governance requirements from CNCF must be adhered to. For example, any candidate project must use the [CNCF Code of Conduct][CNCF Code of Conduct].\n\nWe 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.\n\n### Security Requirements\n\nAny 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.\n\n\n## Specification\n\nThis is the process to submit a project for addition to the Helm organization.\n\n### 1. Project opens issue\n\nThe candidate project must open an issue in the [Helm community repository][Helm community repository] requesting that it join.\n\nThis issue should provide:\n\n- A link back to the project\n- The GitHub user names of those in a governance role for that project\n- A short description (1-3 paragraphs) of why it makes sense to add to Helm\n- A short explanation of how the project is to be staffed going forward.\n\n### 2. Helm Org Review\n\nThe Helm organization owners will review the proposal. This process will likely involve some back-and-forth conversation with the owners of the project.\n\n### 3. Helm Org Voting\n\nAs 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.\n\nIf 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.\n\n### 4. CNCF Review\n\nCNCF 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.\n\nIf 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.\n\n### 5. Transition of Resources\n\nOnce 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.\n\n### 6. Completion\n\nAt 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].\n\n\n\n## Backwards compatibility\n\nThis change applies to all future project additions and implies no change to the status of existing projects.\n\n## Security implications\n\nNot applicable.\n\n## How to teach this\n\nThe steps in the Specification will be available in [the Helm governance documents][Helm governance documents].\n\n## Reference implementation\n\nNot applicable.\n\n## Rejected ideas\n\nNone currently.\n\n## Open issues\n\nNone currently.\n\n## References\n\n- [CNCF intellectual property commitments](https://github.com/cncf/foundation/blob/master/copyright-notices.md)\n- [DCO or CLA](https://www.cncf.io/services-for-projects/#legal-services)\n- [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)\n- [Helm security process](../SECURITY.md)\n- [Helm governance documents](../governance/governance.md)\n- [Helm community repository](http://github.com/helm/community)\n\n"
  },
  {
    "path": "community/hips/hip-0004.md",
    "content": "---\ntitle: Document backwards-compatibility rules\nsidebar_label: \"0004: Document backwards-compatibility rules\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0004.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0004 | Document backwards-compatibility rules | Marc Khouzam <marc.khouzam@montreal.ca>, Matt Butcher <matt.butcher@microsoft.com> | 2020-09-18 | process | accepted |\n\n\n## Abstract\n\nDefine and document the backwards-compatibility rules that apply to Helm minor and patch releases.\n\n## Motivation\n\nHelm aims to strictly respect [Semantic Versioning][semver], where minor and patch releases must be 100% backwards compatible.\nBackwards compatibility implies that when moving to a new backwards-compatible release:\n* tools (such as Continuous Integration tools) using the helm CLI will not require any changes\n* programs using the Helm Go API will continue to compile \n\nSome contributors to the Helm code base may not be comfortable with the details of what constitutes a compatibility-breaking change.\nFurthermore, in some cases, there can be a difference of opinion, even amongst the maintainers, on what constitutes such a change.\n\nHaving a well-defined, documented set of backwards-compatibility rules for the Helm code-base will allow to:\n* avoid compatibility-breaking changes being merged by mistake\n* guide contributors in understanding helm's backwards-compatibility requirements\n* remove any uncertainty when it comes to enforcing backwards compatibility\n* provide a basis for discussion and possible updates to how helm handles backwards compatibility\n\n## Rationale\n\nThe maintainers have agreed that a formal definition of Helm's backwards-compatibility rules would be beneficial.\n\n## Specification\n\nThe following compatibility rules will apply to helm minor and patch releases:\n* exported Go APIs will remain compatible as per this [article][go-module-comp]\n    * the exception to this rule is where Helm exposes Kubernetes APIs. Kubernetes APIs do not follow semantic versioning so Helm cannot enforce compatibility.\n* CLI commands and flags:\n    * commands and flags are case-sensitive\n    * commands and flags must not be removed\n    * commands and flags must not be renamed\n    * commands and flags must not be moved elsewhere in the command hierarchy\n    * commands and flags cannot be \"repurposed\" to provide a different behavior than the original (even if deprecated)\n    * 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)\n    * 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\n    \n* CLI output:\n    * the help text may change\n    * the format of structured output (tables, JSON, YAML) must not change\n    * errors can change if doing so increases their usability\n    * a message containing a \"bug\" (including spelling errors, misinformation, or egregious grammar errors), can be fixed\n    * return codes should not be changed unless they are incorrect\n\n* File formats (such as index.yaml, values.yaml, Chart.yaml):\n    * No fields may be removed, added, or modified on the Chart.yaml file\n    * No fields may be modified or removed in:\n        * index.yaml\n        * repositories.yaml\n    * Any added fields must be accompanied by backward compatibility checks\n    * No existing optional field can be made required (but a required field can be downgraded to optional)\n    * If a field is added to a structured piece of data, it must be optional. No \"new required\" fields\n    * 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)\n\n* Charts:\n    * The handling of templates/ must not be changed\n    * Reserved directory names (e.g. crds) must not be removed\n    * No files or file types that are allowed may be changed to be disallowed\n    * If an object or file type is added to a chart, it must also be optional (see requirements.yaml in Helm 2)\n    * 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)\n\n* Templates (commands, functions, syntax, and variables):\n    * Template functions cannot be removed\n    * Return types of functions cannot change\n    * 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.\n    * built-in directives, constants, and variables cannot be removed or changed in any way that would break an existing template\n    * 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\")\n    * 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.\n    * 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).\n    * occasionally, external template libraries or their dependencies have made breaking changes. We are now trying to avoid that.\n\n* Experimental Feature Flags:\n    * 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.\n    * 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.\n    * 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.\n\n## Security implications\n\nCompatibility 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.\n\nIn 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.\n\n## How to teach this\n\n* The list of compatibility rules should be published on helm.sh with a global explanation of the motivation behind to need to follow them\n* The list of compatibility rules should be used as a reference by maintainers when doing code reviews\n* During PR reviews, when appropriate, the reviewing maintainer should refer the contributor to the list of compatibility rules\n\n## Reference implementation\n\nThis HIP will serve as the document listing the backwards-compatibility rules.\n\n## Open issues\n\n* Should Go's experimental [apidiff][apidiff] tool be used?  The following [issue][apidiff-install] gives a couple of ways to install it.\n* 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]\n* 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]\n* 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]\n* Does breaking compatibility due to security require a major release?\n* Should the rules specifically mention the helm packages that must respect compatibility? (e.g., `pkg` for Go API, `cmd` for CLI)\n\n[semver]: https://semver.org/spec/v2.0.0.html\n[go-module-comp]: https://blog.golang.org/module-compatibility\n[apidiff]: https://pkg.go.dev/golang.org/x/exp/cmd/apidiff\n[apidiff-install]: https://github.com/golang/go/issues/34849\n"
  },
  {
    "path": "community/hips/hip-0005.md",
    "content": "---\ntitle: Helm Org Maintainers and Deprecated Projects\nsidebar_label: \"0005: Helm Org Maintainers and Deprecated Projects\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0005.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 5 | Helm Org Maintainers and Deprecated Projects | Matt Butcher <matt.butcher@microsoft.com> | 2020-09-24 | process | draft |\n\n\n## Abstract\n\nThis process proposal explains what happens to Helm organization maintainer slots when\na project is deprecated.\n\n## Motivation\n\nThe current governance documents state that org maintainers may be selected from any of\nthe official Helm projects. However, as the Helm organization matures, some projects are\nbeing deprecated. The governance docs are unclear what happens to org maintainers from\ndeprecated projects, and whether deprecated projects may hold org maintainer seats.\n\n## Rationale\n\nIn the interest of keeping the Helm project thriving and alive, this HIP proposes that\nonly non-deprecated projects are entitled to org maintainer seats.\n\n## Specification\nTo implement this, a new PR must be opened with the changes to the governance document.\nThe changes must be adopted by 2/3 supermajority of the _current org maintainers_ \n(including those maintainers who may be attached to deprecated projects).\n\nThe governance documentation for the Helm org will be updated as follows:\n\n- All references to org maintainer seats for projects will clarify that they apply only\n  to non-deprecated projects\n- Text will clarify that when a project is deprecated, its org maintainers will\n  be moved to Emeritus status _except_ where those maintainers may be able to keep their\n  role because of their status on another Helm project, including the `helm/helm` project.\n- The definition of an active maintainer will also be revised to specify that the\n  maintained project must not be deprecated\n\n## Backwards compatibility\n\nN/A\n\n## Security implications\n\nN/A\n\n## How to teach this\n\nThe [governance.md] document will be updated with precise language.\n\n## Reference implementation\n\nThe [governance.md] document will contain all associated changes.\n\n## Rejected ideas\n\n### 1. Allowing maintainers of deprecated projects to stay\n\nOne might argue that maintainers of deprecated projects should be allowed to stay on as\norg maintainers. This option was considered. But the design of the org maintainers board\nwas intended to give projects governing input into Helm. Essentially, allowing\nmaintainers of deprecated projects to take these slots means essentially that\nnon-owners will be given a say in Helm's direction. It would even be possible that non-owners\ncould have a majority voting stake in the Helm project. This did not seem right.\n\n### 2. Requiring maintainers of deprecated projects to go even if they represented other projects as well\n\nOne might argue that if a maintainer was elected because of their involvement in project\nX, their org maintainership should be inextricably tied to X. However, as written, this\nproposal allows such a maintainer to simply stay on as a maintainer due to their\naffiliation with another project, Y.\n\nOur intention in forming the organizational maintainers was to give interested parties\na voice in steering Helm. Because such a party would still be formally affiliated with a\nHelm project, we believe they fill the spirit of the original organizational motivations.\n\nOf course, this does not prevent a maintainer from voluntarily stepping down when their\nproject is deprecated.\n\n## Open issues\n\nN/A\n\n## References\n\n[governance.md](/community/governance/governance)"
  },
  {
    "path": "community/hips/hip-0006.md",
    "content": "---\ntitle: OCI Support\nsidebar_label: \"0006: OCI Support\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0006.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0006 | OCI Support | Josh Dolitsky | 2020-07-21 | feature | accepted |\n\n\n## Abstract\n\nThis 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.\n\n## Motivation\n\nUntil 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`.\n\nWhile 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.\n\nIn addition, there has not yet been a clear response to the following questions concerning Helm's OCI support:\n\n- What is the relationship between a chart version and registry tag?\n- Will this work with `helm install` / `helm upgrade` / `helm dependency`?\n- How will provenance files (`.prov`) be supported?\n- When will the experimental flag be removed?\n\n## Rationale\n\nThe 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.\n\nBy 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.\n\n## Specification\n\nThe specification for this HIP is broken into six (6) major sections:\n\n1. Implement `Getter` and introduce `Pusher`\n2. Support for provenance files\n3. Chart versions == OCI reference tags\n4. Chart names == OCI reference basenames\n5. Cache is removed\n6. `helm chart` is removed, integrated into rest of CLI\n7. Experimental until clear messaging from OCI\n\n### 1. Implement `Getter` and introduce `Pusher`\n\nAs 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)).\n\nThe 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.\n\nCurrently 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).\nThis 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)).\n\nThis 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.\n\nHere is an example of what the `helm push` UX will look like:\n\n```\n$ helm create mychart\nCreating mychart\n\n$ helm package mychart/\nSuccessfully packaged chart and saved it to: /home/user/mychart-0.1.0.tgz\n\n$ helm push mychart-0.1.0.tgz oci://example.com/some/root/namespace\nThe push refers to repository [oci://example.com/some/root/namespace/mychart]\nref:     oci://example.com/some/root/namespace/mychart:0.1.0\ndigest:  1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\nsize:    2.4 KiB\nname:    mychart\nversion: 0.1.0\n0.1.0: pushed to remote (1 layer, 2.4 KiB total)\n```\n\n### 2. Support for provenance files\n\nHelm 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.\n\nSupport 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`).\n\nAs 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.\nThe 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.\n\nHere is an example of what a manifest will look like with a provenance file attached:\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n\n```\n\n### 3. Chart versions == OCI reference tags\n\nTo 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.\n\nThis also means that tags are no longer necessary to be provided on the command-line in the form `<ref>:<tag>`. Instead, users can provide `--version <version>`.\n\n### 4. Chart names == OCI reference basenames\n\nAgain, to keep things simple, the basename (the last segment of the URL path) on a registry reference should be equivalent to the chart name. \n\nFor example, given a chart with the name `pepper` and the version `1.2.3`, users may run a command such as the following:\n\n```\n$ helm push pepper-1.2.3.tgz oci://r.myreg.io/mycharts\n```\n\nwhich would result in the following reference:\n\n```\noci://r.myreg.io/mycharts/pepper:1.2.3\n```\n\nBy placing such restrictions on registry URLs and tags, Helm users are less likely to do \"strange things\" with charts in registries.\n\n### 5. Cache is removed\n\nSince 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.\n\nBy 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.\n\n### 6. `helm chart` is removed, integrated into rest of CLI\n\nWherever possible, the subcommands provided by the new `helm chart` command should be integrated into existing Helm CLI commands.\n\n`helm chart pull` should be baked into `helm pull`, `helm chart push` should be `helm push` (new).\n\nCommands that work with the cache will be removed: `helm chart save`, `helm chart remove` and `helm chart export`.\n\n`helm registry` will be kept as is. This manages auth against OCI registries.\n\n\n### 7. Experimental until clear messaging from OCI\n\nConsidering 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.\n\nThe 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.\n\n## Backwards compatibility\n\nSince the existing feature set is currently experimental, there will be no promise of backwards compatibility with prior OCI support (sorry!)\n\n## Security implications\n\nRegistry authentication introduces a new attack vector. Upon running `helm registry login`, these credentials can possibly be stored in an unencrypted JSON file.\nHowever, 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.\n\nHere is an example of a registry config file using a credential helper:\n\n```\n{\n\t\"auths\": {\n\t\t\"example.com\": {}\n\t},\n\t\"credsStore\": \"osxkeychain\"\n}\n```\n\nHere is an example of a registry config file without a credential helper:\n\n```\n{\n\t\"auths\": {\n\t\t\"example.com\": {\n\t\t\t\"auth\": \"<password>\",\n\t\t\t\"email\": \"<username>\"\n\t\t}\n\t}\n}\n```\n\nSo, while a new attack vector has been introduced, it should not be considered any less safe than using `docker login`.\nIn fact, he underlying code is leveraging docker/cli, and existing logins created with `docker login` are leveraged if not found in Helm's config.\n\nNote: this is already implemented in the current OCI feature set.\n\n## How to teach this\n\nFollowing the implementation of all facets of this HIP, extensive documentation should be added to the Helm website on how to leverage OCI.\n\nAdditionally, 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.\n\nHelm and charts maintainers should be educated on how to make a transition from classic chart repositories to registries.\nIn short the workflow for uploading a chart goes from `helm package` (+ custom upload) to `helm package && helm registry login && helm push`.\n\n## Reference implementation\n\nThe features are currently under development. \n\nHere are the following outstanding tasks:\n\n- We need to implement helm push, which does not exist\n- 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)\n- Support for provenance files must be added\n- `helm chart save`, `helm chart export`, `helm chart list`, `helm chart remove`, `helm chart pull`, and `helm chart push` need to be removed\n- The Helm documentation for OCI support needs to be updated (https://helm.sh/docs/topics/registries/))\n\n## Rejected ideas\n\n### Will I be able to use custom tags such as \"latest\"?\n\nThe 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.\n\n### Will I be able to pull a chart using the `:<tag>` syntax?\n\nIt's unclear if users will be able to pull charts with a specific version using the `:<tag>` syntax (vs. `--version <version>`). This seems relatively harmless to allow both, but this may have implications on dependencies and other areas.\n\n## Open issues\n\nThe issues below are still unresolved.\n\n### What is the correct media type to use for the chart content layer?\n\nThe 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).\n\nDue to this, a unique media type will be used: `application/vnd.cncf.helm.chart.content.v1.tar+gzip`.\n\nThe 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.\n\n### What is the correct media type to use for the provenance file layer?\n\nAgain, there doesn't appear to be an IANA media type for this type of file. Additionally, this file format appears unique to Helm.\n\nIn this case, it seems the only option is to use a custom media type such as `application/vnd.cncf.helm.chart.provenance.v1.prov`.\n\n## References\n\nThe following links are used as references in this HIP:\n\n- [Open Container Initiative](https://opencontainers.org/)\n- [OCI Distribution Specification](https://github.com/opencontainers/distribution-spec)\n- [List of IANA media types](https://www.iana.org/assignments/media-types/media-types.xhtml)\n- [Helm Documentation - Registries](https://helm.sh/docs/topics/registries/)\n- [Artifact Hub](https://artifacthub.io/)\n- [Existing standalone code for OCI support](https://github.com/helm/helm/tree/master/internal/experimental/registry)"
  },
  {
    "path": "community/hips/hip-0007.md",
    "content": "---\ntitle: Document and Track maintainer groups\nsidebar_label: \"0007: Document and Track maintainer groups\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0007.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0007 | Document and Track maintainer groups | Matt Farina <matt@mattfarina.com>, Scott Rigby <scott@r6by.com> | 2025-10-07 | process | draft |\n\n\n## Abstract\n\nThere are numerous Helm maintainer groups where each can have zero or more Git\nrepositories associated with them. This process provides a centralized method\nto document and track the maintainer groups, maintainers, and associated repos.\n\n## Motivation\n\nThe current design uses a collection of documented and access controls to track\nthis information while there are several gaps in the information. The Teams.md\nfile attempted to track the different teams (i.e. maintainer groups, the org\nmaintainers, etc).\n\nThe repositories owned by a maintainer group, and the members of a group are\nnot documented but are instead tracked via GitHub teams. The owners are\nscattered in various locations that are not consistent. In some cases they\ncannot be consistent (e.g. community management which does not have a GitHub\nrepo). This has lead to confusion with the Org Maintainers and others.\n\n## Rationale\n\nThere is currently no consistent manner to document the codebases associated with\na maintainer group or the members of a maintainer group. There are two examples we can look\nat for this situation.\n\nFirst, there are maintainer groups responsible for multiple repositories. Charts and the\nOrg maintainers groups are two examples with multiple repositories.\nThere is no location to publicly document this situation.\n\nSecond, not all maintainer groups own a repository. Community management is an example\nof a maintainer group that does a significant amount of work without owning a source\nrepository.\n\nThis HIP aims to provide a single source of document to discover maintainer group\nrepositories and owners.\n\n## Specification\n\nThe source of truth will be a YAML file name [`maintainer-groups.yaml`](https://github.com/helm/community/blob/main/maintainer-groups.yaml)\nstored at the root of the Helm community repository. It will have the following\nstructure:\n\n```\nmaintainerGroups:\n- name: Helm Core\n  ownersLink: https://raw.githubusercontent.com/helm/helm/master/OWNERS\n  repos:\n  - https://github.com/helm/helm\n  mailingList: cncf-helm-core-maintainers@lists.cncf.io\n- name: Charts\n  owners:\n  - unguiculus\n  - ...\n  emeritus:\n  - foxish\n  - ...\n  repos:\n  - https://github.com/helm/chart-releaser-action\n  - https://github.com/helm/charts-repo-actions-demo\n  - ...\n```\n\nA maintainer group can only have either `ownersLink` (a URL to the location of the\nowners list) or `owners` (a list of owners). It cannot have both. This enables\nthose who do not have a Git repo (e.g., community managers) and those with\nmultiple repos and no primary one (e.g., charts) to have a documented list.\n\nWhen `owners` is used it can have an accompanying `emeritus`. When `ownersLink`\nis used the emeritus is expected to be listed in that file.\n\n## References\n\n* [Helm Governance](/community/governance/governance)\n  documents maintainer groups.\n* The [Teams.md file can be referenced in the community history](https://github.com/helm/community/blob/ecedb3ddea57749580bc4800cb1492fce9c9b332/Teams.md).\n"
  },
  {
    "path": "community/hips/hip-0008.md",
    "content": "---\ntitle: Add descriptions to custom completions\nsidebar_label: \"0008: Add descriptions to custom completions\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0008.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0008 | Add descriptions to custom completions | Marc Khouzam <marc.khouzam@montreal.ca> | 2020-11-14 | feature | accepted |\n\n\n## Abstract\n\nProvide (optional) descriptions for helm's custom completions.\n\nThe goal is to help users be more efficient by providing useful information\nwhen doing auto-completion.\n\n## Motivation\n\nHelm currently supports auto-completion for the following shells: `bash`, `zsh`,\n`fish`. Both the `zsh` and `fish` shells support descriptions for completions.\n\nFor example, in the case of `zsh`:\n```\n$ helm s<TAB>\nsearch  -- search for a keyword in charts\nshow    -- show information of a chart\nstatus  -- display the status of the named release\n```\n\n[The Cobra project][cobra project], which is used by Helm to define its\ncommands and flags, automatically provides completion descriptions when\ncompleting those commands and flags.  Those descriptions are based on the usage\ninformation specified by Helm.  However, custom completions that are provided\nby helm itself currently don't include any descriptions. For example, when\ncompleting `helm status` it is helm that provides the list of releases, but\nthis list does not include descriptions.\n```\n$ helm status n<TAB>\nnginx          nginx-ingress\n```\n\nAugmenting helm's custom completions with descriptions allows providing\nadditional information to help users make their selection from the list of\ncompletions.\n\n## Rationale\n\nThe completions for some helm arguments do not always provide sufficient\ninformation for a user to know which value to choose.  For instance, the\nname of a release is not always informative enough for the user to know\nwhich one to select.  For example:\n```\n$ helm upgrade ngin<TAB>\nnginx         nginx2\n```\nClearly, in this case, the user needs to know the details of each release\nin advance as the difference between completion choices is not very helpful.\n\n## Specification\n\nHere are proposed descriptions for the different types of custom completions:\n* chart names (for 'install', 'pull', 'show *', 'template', 'upgrade')\n    * \\<chart description>\n```\n$ helm install myrelease bitnami/c<TAB>\nbitnami/cassandra  -- Apache Cassandra is a free and open-source distributed database managemen\nbitnami/common     -- A Library Helm Chart for grouping common logic between bitnami charts. Th\nbitnami/consul     -- Highly available and distributed service discovery and key-value store de\nbitnami/contour    -- Contour Ingress controller for Kubernetes\n```\nAs the chart description will often be too long to fit on a single line, the shell will truncate\nthe description to fit the shell's window.  Note that each shell handles this case in its own way,\nwhere `zsh` truncates, while `fish` uses an ellipsis.\n\n* chart version (for '--version')\n    * App: \\<app version>, Created: \\<date>\n```\n$ helm pull bitnami/nginx --version 7.1.<TAB>\n7.1.0  -- App: 1.19.2, Created: September 24, 2020\n7.1.1  -- App: 1.19.3, Created: September 29, 2020\n7.1.2  -- App: 1.19.3, Created: October 2, 2020\n```\n* kubernetes context (for '--kube-context')\n    * \\<kube cluster name>\n```\n$ helm --kube-context d<TAB>\ndefault  -- k3d-k3s-default\ndev      -- development\n```\n* helm environment variables (for 'env')\n    * \\<value> (\\<description of variable>)\n```\n$ helm env HELM_RE<TAB>\nHELM_REGISTRY_CONFIG    -- /me/Library/Preferences/helm/registry.json (Path to the registry configuration file)\nHELM_REPOSITORY_CACHE   -- /me/Library/Caches/helm/repository (Path to the file containing cached repository indexes)\nHELM_REPOSITORY_CONFIG  -- /me/Library/Preferences/helm/repositories.yaml (Path to the file containing repository names and URLs)\n```\n* plugin names (for 'plugin uninstall', 'plugin update')\n    * \\<plugin description>\n```\n$ helm plugin uninstall <TAB>\n2to3        -- migrate and cleanup Helm v2 configuration and releases in-place to Helm v3\nfullstatus  -- provide status of resources part of the release\n```\n* release names (for 'get *', 'history', 'rollback', 'status', 'test', 'upgrade')\n    * \\<chart name>-\\<chart version> -> \\<release status>\n```\n$ helm status <TAB>\nmynginx        -- nginx-6.0.5 -> superseded\nnginx-ingress  -- nginx-ingress-controller-5.4.4 -> deployed\n```\n* release revisions (for 'rollback', '--revision')\n    * App: \\<app version>, Chart: \\<chart name>-\\<chart version>\n```\n$ helm rollback nginx-ingress <TAB>\n1  -- App: 0.34.1, Chart: nginx-ingress-controller-5.4.4\n2  -- App: 0.40.2, Chart: nginx-ingress-controller-5.6.10\n```\n* repo names (for 'repo remove' and completion of chart names)\n    * \\<repo URL>\n```\n$ helm repo remove <TAB>\nbitnami  -- https://charts.bitnami.com/bitnami\ncenter   -- https://repo.chartcenter.io\nstable   -- https://charts.helm.sh/stable\n```\n* output formats (for '--output', '-o')\n    * \\<format description>\n```\n$ helm status -o <TAB>\njson   -- Output result in JSON format\ntable  -- Output result in human-readable format\nyaml   -- Output result in YAML format\n```\n\nNote that descriptions can be turned off by the user when generating the shell\ncompletion script using the `--no-descriptions` flag.\n\n## Backwards compatibility\n\nNot applicable to shell auto-completion. In fact, this allows us to implement\nsome descriptions and still be able to modify them later if different ones are\nrequested.\n\n## Security implications\n\nNone\n\n## How to teach this\n\nThe new descriptions will automatically appear when using auto-completion, so no\nspecial effort needs to be made to teach this new feature.\n\n## Reference implementation\n\nA PR will be opened to implement the proposed specification for descriptions of\ncustom completions.\n\n## Open issues\n\nNone.  \n\nIt is worth clarifying that the bash shell does not support descriptions for\nauto-completion, so this feature will not apply to bash.  That being said, there\nis a [PR open on the Cobra project][cobra pr] that adds descriptions for bash\ncompletions.\n\n[cobra project]: https://github.com/spf13/cobra\n[cobra pr]: https://github.com/spf13/cobra/pull/1146\n"
  },
  {
    "path": "community/hips/hip-0009.md",
    "content": "---\ntitle: Transitioning Security Team Members on Project Deprecation\nsidebar_label: \"0009: Transitioning Security Team Members on Project Deprecation\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0009.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 9 | Transitioning Security Team Members on Project Deprecation | Matt Butcher <matt.butcher@microsoft.com> | 2020-09-24 | process | draft |\n\n\n## Abstract\n\nHelm maintains a security team composed of interested maintainers from Helm projects. This\nproposal clarifies that to be a member of the security team, one must be a maintainer of\nan active (non-deprecated) project.\n\n## Motivation\n\nThe existing security team documentation does not cover cases where a Helm project is\nmarked deprecated. However, because the security team discusses sensitive and potentially\ndamaging issues, the Helm project requires clarity on this point.\n\n## Rationale\n\nThis HIP suggests that security team members must be maintainers on _active_ Helm projects.\n\n## Specification\n\nAccording to the current documentation in [SECURITY.md][SECURITY.md], the only requirements for\nsecurity team members are as follows:\n\n* Members MUST be active project maintainers as defined in [the governance][governance]\n* Members SHOULD engage in each reported vulnerability, at a minimum to make sure it is being handled\n* Members MUST keep the vulnerability details private and only share on a need to know basis\n\nThis proposal suggests that the first requirement be amended to read:\n\n> Members MUST be active project maintainers for an active project as defined in [the governance]\n\nFurther, the [SECURITY.md][SECURITY.md] document should be updated to indicate that a security team\nmember will be automatically removed if they are no longer affiliated with any\nactive (non-deprecated) projects.\n\n## Backwards compatibility\n\nN/A\n\n## Security implications\n\nThe primary reason for this change is that we view it as a compromise of our security\nposture to have vulnerability disclosures sent to non-maintainers. Making this change\nimproves our security posture.\n\n## How to teach this\n\nThe change will be documented in [SECURITY.md][SECURITY.md]\n\n## Reference implementation\n\nThe change will be made in [SECURITY.md][SECURITY.md]\n\n## Rejected ideas\n\nOne might claim that security team members should be entitled to stay because of their\npast experience. While we do not want to downplay the role of experience, we do want to\npoint out that it is unwise to allow unaffiliated individuals to have access to\nvulnerability disclosures.\n\n## Open issues\n\nNone currently.\n\n[SECURITY.md]: ../SECURITY.md\n[governance]: ../governance/governance.md"
  },
  {
    "path": "community/hips/hip-0010.md",
    "content": "---\ntitle: Distributed responsibility for picking\nsidebar_label: \"0010: Distributed responsibility for picking\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0010.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0010 | Distributed responsibility for picking | Marc Khouzam <marc.khouzam@montreal.ca> | 2021-01-28 | process | draft |\n\n\n## Abstract\n\nThe picking of PRs into a release branch is currently the responsibility of the maintainer\ncutting the release.  It is usually the largest part of cutting a release.  Improving\nthe picking process would make cutting releases easier with a reduced risk of error.\n\n## Motivation\n\nIn the current picking process the maintainer that merges a PR is only required to tag that PR with a `needs-pick` \nlabel. The day of the patch release the maintainer cutting the release will go through each PR\nwith a `needs-pick` label and manually cherry-pick it into the release branch.  Once the\ncherry-pick is done, the `picked` label is added to the PR.\n\nThere are multiple issues with this process:\n1. Manual work for the maintainer doing the release to pick each relevant PR.\n1. Possible merge conflicts during the cherry-picks as the code on master may\nhave substantially diverged from the code in the release branch.  This is particularly concerning\nas the maintainer cutting the release may not be the one who reviewed the PR in question\nand may not be familiar with its details, thus making resolving the conflicts difficult\nand error prone.\n1. There is basically no soak time for the cherry-picks or merge conflict resolution code:\nsome quick manual testing and the unit tests are the only tests these changes go through. \n\n## Rationale\n\nBy cherry-picking PRs as soon as they are merged into the master branch will allow to\naddress the issues mentioned above.  It will reduce the manual work required\nat release time, will reduce the risk of errors during merge conflicts, and will provide\nmore time to soak the release branch content.\n\n## Specification\n\nThe pick process would be modified to the following:\n1. Once a PR is merged into the master branch the `needs-pick` label will still be applied.\nThis is to reduce the risk of forgetting to cherry-pick a PR.\n1. Once the PR is merged into the master branch, it becomes the responsibility of the merging maintainer to\ncherry-pick it into the release branch; this should be done as soon as possible.  The cherry-pick could\nalso be done by another maintainer if desired.\n1. Once the cherry-pick into the release branch is done, the cherry-picking maintainer should add the\n`picked` label in the original PR.\n1. On a regular basis, or at least one week before a patch release date, the list of `needs-pick`\nPRs without a `picked` label should be verified in case any was forgotten.\n\nWith this process, the release branch should always be in a state that is ready for release;\nthe maintainer cutting the release does not need to perform any cherry-picking.\n\nFor increased quality of patch releases, the release branch can be used by the community\nat any time, so as to verify no issues are present by the time the release day comes around.\n\nThe maintainer doing the cherry-pick could optionally choose to create a PR targeting the\nrelease branch instead of directly pushing the cherry-pick.  This option could be chosen to obtain\na review, for example if merge conflicts were substantial.  Such PRs would not need to follow the\nfull PR process but could be merged at the discretion of the maintainers.\n\n### Security releases\n\nSecurity releases are currently cut from the release branch and must only contain the\nsecurity fix itself.  However, with the proposed change to the pick-process, the release branch may\ncontain new commits that should not be part of the security release.  To address this, the\nsecurity release process will require to create a new branch off the\nlast release **tag**, apply the security fix to that new branch and then build the release\nfrom that branch.  The security fix must also be applied to the release branch in preparation\nfor a future patch release.\n\n## Backwards compatibility\n\nN/A\n\n## Security implications\n\nN/A\n\n## How to teach this\n\nEach Helm core maintainer should be told about this new process and asked to read the HIP.\n\n## Reference implementation\n\nA PR will be posted to update the release checklist to match the new process.\n"
  },
  {
    "path": "community/hips/hip-0011.md",
    "content": "---\ntitle: CRD Handling in Helm 3\nsidebar_label: \"0011: CRD Handling in Helm 3\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0011.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0011 | CRD Handling in Helm 3 | Matt Butcher <matt.butcher@microsoft.com> | 2021-03-26 | informational | final |\n\n\n## Abstract\n\nThis 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.\n\nThe 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.)\n\n## Rationale\n\nThis 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.\n\n### The Core Problem\n\nThe 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.\n\nFor that reason, installing, modifying, and deleting CRDs is a process that has ramifications for all users and systems of that cluster.\n\nIn 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.\n\n### Users First: A Core Principal\n\nOver 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.\n\nHelm distinguishes between at least two roles:\n\n- A chart author: A person filling this role _creates_ and _maintains_ Helm charts\n- A Helm user: This person installs and manages instances of charts\n\n#### The Chart Author Role\n\nWe assume that a _chart author_ has three specific areas of domain knowledge:\n\n1. How to model applications in Kubernetes\n2. How to create Helm charts, including author templates\n3. How the application they are packaging works\n\nIn this case, we assume the chart author role includes knowledge of Kubernetes kinds, Helm template commands, and so on.\n\nWe 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.)\n\n#### The Helm User Role\n\nOur 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.\n\n#### The Importance of This Distinction\n\nOver 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.\n\nSome 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.\n\nAs 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.\n\nAnd 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.\n\nWhen 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.\n\nThis 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.\n\nWe will not ignore it for CRDs.\n\n### CRDs and How They Are Used\n\nCRDs 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.\n\nOriginally, 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.\n\nA 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.\n\nWhile 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.\n\nYou 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.)\n\nFrom 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.\n\nIn Kubernetes, the following CRD patterns have emerged:\n\n- 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.\n- CRD and Singleton Controller: A specific application defines a specific CRD that only it uses. Only one controller uses that CRD.\n- 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)\n- 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.\n\nAs 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.\n\nThe following facts about CRDs should be kept in mind throughout this paper:\n\n- 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.\n- 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.\n    - 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.\n    - 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\n    - A retrieved object may not match the schema of the version that is in its apiVersion field because of the above.\n- 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.\n\nA 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.\n\n### How This Impacts Helm\n\nHelm 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.\n\nOriginally, 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.\n\nOur 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.\n\n#### Installing CRDs\n\nThere 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.\n\nAll 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.\"\n\nAfter 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.\n\nOf 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.\n\n> 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.\n\n### Deleting CRDs\n\nWe'll delay talking about upgrades for just a moment, and skip to the easiest one: Deleting CRDs.\n\nHelm currently does not delete CRDs. The reasoning behind this decision is the trivial confluence of two aspects of CRDs: global resources and cascading deletes.\n\nThe next two subsections explain these.\n\n#### Shared Global Resources\n\nEarlier, 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.\n\nIf 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.\n\nHowever, 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.)\n\nEven 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).\n\nTherefore, there is no way to determine when it is safe to remove a CRD short of determining that the cluster itself is being destroyed.\n\n\"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.\n\nEven more simply, there is no guarantee that Team A even knows that their chart installed a CRD. There are several cases to consider here:\n\n- 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\n- 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\n- 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).\n\nThe 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.\n\n#### Cascading Deletions\n\nAnother 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.\n\nNow consider this innocuous \"fix\": A chart is misbehaving. Something about the newest version is broken. The Helm user chooses one of the following actions:\n\n* rollback\n* force delete and recreation\n\nIf 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.\n\nNow 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.\n\nAgain, this is not a story friendly to our \"users first\" philosophy.\n\n### Upgrading and Modifying CRDs\n\nThis is perhaps the most vexed part of CRD handling. While the ramifications of deletion are straightforward, modifying CRDs is nuanced and complicated.\n\nIf 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.\n\nLikewise, 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.\n\nBecause 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.\n\nFinally, 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.\n\n#### Upgrading CRDs\n\nGiven 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.\n\nIt'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_.\n\nThe 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.)\n\nOne 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.\n\nIn 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.\n\nFinally, 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.\n\n#### Rollbacks\n\nRollbacks 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.\n\nIf a CRD is rolled back, then the old version will overwrite the new version.\n\nThere 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_.\n\n##### Rollback target does not have the CRD\n\nConsider 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.\n\nIn 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.\n\n##### Rollback target has an older version of the CRD\n\nIn 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.\n\nBut this is where Kubernetes' behavior gets interesting:\n\n- 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.\n- 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.\n- It is unclear how the schemata will be applied in this case\n- 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.\n\nThus, rollbacks have a few special cases where the uncertainty of Kubernetes' behavior could cause issues that are exceedingly hard to debug.\n\n## Rejected Ideas\n\nProposed Solutions for Helm CRD Management\n\nIn 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.\n\nAs we progress through potential solutions, keep in mind the roles and caveats elaborated before:\n\n- Chart authors create charts\n- Helm users install and manage instances of those charts\n- We cannot assume that those roles are filled by the same person\n- We cannot assume, specifically, that a Helm user understands the inner workings of a chart or even of Kubernetes\n- We cannot assume that a Helm user looks at the contents of a chart\n- We cannot assume that a chart author knows the target cluster environment\n- We cannot assume that a chart author knows what other things will be running concurrently in the same cluster as the chart\n- 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.\n\nThe following kinds of solutions have been suggested:\n\n1. Do not manage CRDs any differently than other resources\n2. Helm should let chart authors control how CRDs are managed\n3. Helm should let Helm users control how CRDs are managed\n4. Helm should have deep special-case logic for handling CRDs\n\nEach of these is discussed below.\n\n### No Special CRD Management\n\nIn this solution, a CRD is treated no differently than any other Kubernetes kind.\n\n_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.\n\nThis 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.\n\nBut 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:\n\n1. CRDs alter the behavior of the API server. Specifically, discovery and validation change when a CRD is added or modified.\n2. It is impossible to pre-verify a chart that has both a CRD and CRs for that CRD\n3. `helm delete` becomes a very, very dangerous command, as it can destabilize a cluster by deleting a CRD\n4. `helm upgrade` and `helm rollback` can have surprising consequences that are difficult to find and debug\n\nWe still haven't solved #2, but by adding some special treatment of CRDs in Helm 3, we eliminated #3-4 and fixed #1.\n\n> **IMPORTANT**: It is still possible to use Helm this way. For CRD/Operator-only charts, this is a perfectly legitimate way of packaging.\n\n### Chart Authors Have Control\n\nIn 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.\n\nThe problems that this approach must address are:\n\n- How can a chart author know when it is safe to install, upgrade, or delete a CRD without harming the broader cluster?\n- How can massive data loss be prevented when a CRD is deleted?\n- How can two versions of the same chart (with different CRD versions) be safely installed on the same cluster?\n- Can the user opt to override this behavior if they detect an issue? (And if so, how?)\n\nAs 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.\n\nWe 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.\n\n### Helm Users Have Control\n\nIn 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.\n\nOne could imagine, in this model, the following commands and flags:\n\n```console\n$ helm install --with-crds ...\n$ helm upgrade --allow-crd-modification ...\n$ helm delete --unsafe-delete-crds ...\n```\n\nBut with this model, there are also problems:\n\n- 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)\n- 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?\n- How does the user discover whether the CRD is in use in namespaces that the user does not have access to?\n- How does the user avoid catastrophic data loss on deletion?\n\nWe have not discovered satisfactory answers to these questions, which has led us away from implementing this approach.\n\n### Helm Itself Has Control\n\nThis 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_.\n\nAs things currently stand, there is no way for us to implement this.\n\nBasically 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.\n\n## How To Teach This\n\nA critical challenge for Helm 3 has been to educate the Helm community about why the maintainers have made the choices we have made.\n\nThee first step in teaching this has been to make the rationale generally accessible.\nWe hope the present HIP accomplishes this. But beyond that, we may need to head off some\ncommon misconceptions directly. The remainder of this section discusses those.\n\n### Nobody is \"Blocked\" on This\n\nIt has been claimed that this issue is a \"blocker\" to using Helm. While we hear this claim on occasion, it stems from a misunderstanding.\n\nFirst, 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.\n\nSecond, 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.\n\nThird, 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.\n\nFinally, 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.\n\nSo 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.\n\nYou are free to handle CRDs however you want. To get you started, here are some useful links:\n\n- Read the [CRD Best Practices](https://helm.sh/docs/chart_best_practices/custom_resource_definitions/) guide\n- Learn about [plugins](https://helm.sh/docs/topics/plugins/)\n- Use a [post-render](https://helm.sh/docs/topics/advanced/#post-rendering)\n- Export YAML with [helm template](https://helm.sh/docs/helm/helm_template/#helm-template)\n\nHelm 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.\n\n### Helm Is Still Working On Thus, But We Cannot Solve It Alone\n\nCRDs 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.\n\nWe 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.\n\nIf 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."
  },
  {
    "path": "community/hips/hip-0012.md",
    "content": "---\ntitle: Helm 4 Development Process\nsidebar_label: \"0012: Helm 4 Development Process\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0012.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0012 | Helm 4 Development Process | Matt Butcher <matt.butcher@fermyon.com>, George Jenkins <gvjenkins@gmail.com>, Matt Farina <matt.farina@suse.com> | 2021-04-02 | process | accepted |\n\n\n## Abstract\n\nHelm 4 is planned as the next major version release of Helm.\nContinuing to evolve Helm in its role as the Kubernetes package manager.\n\nThis HIP outlines the requirements and process for building Helm 4.\nIt describes the scope of Helm 4 changes, with a focus on maintaining continuity within the Helm ecosystem.\n\nThis HIP also aims for an open and productive process that enables Helm 4 to build upon the success of Helm 3.\nTo continue advancing Helm and its ecosystem for the benefit of the Helm community.\n\n## Motivation\n\nHelm 3 has been greatly successful, and Helm has built a significant ecosystem around the Helm client (CLI), charts, chart repositories, SDK, plugins, etc.\nAs 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.\n\nHowever, Helm has accumulated debt.\nOne 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.\nHelm 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.\n\nHowever, Helm 4 must maintain continuity in the Helm ecosystem.\nIt is crucial that Helm 4 be largely functionally/feature compatible with Helm 3.\nSignificant 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.\nAnd at worst, could splinter the Helm ecosystem.\n\nThe project also aims to timebox the Helm 4 release process.\nGiven 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.\n\n## Rationale\n\nDuring the Helm 3 development process, Helm core maintainers received criticism that the process was not transparent enough.\nThis proposal aims to outline a formal process for a successful Helm 4 release to address those criticisms.\n\nFurther 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.\n\nThis 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.\nIt 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.\n\nThe process is based on the following ideas:\n- Requiring changes to be documented, either as reduced \"Helm 4 proposals\" (H4HIP) or standard HIPs.\nAllowing both Helm community members and maintainers to review them.\nThis oversight ensures that changes are in line with this HIP, regarding their functional and architectural implementation.\nAdditionally, documented changes enable contributors to independently implement agreed-upon proposals in coordination with the release engineer.\n- 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.\nIt also aims to prevent an \"open-ended\" development cycle that might drag on or fizzle out.\nIdeally, the majority of changes will be proposed and agreed upon during the planning phase of the development cycle.\nHowever, amendments to the initial scope are permitted as long as they can fit within the agreed-upon timeframe.\nExplicitly allowing for scope amendments ensures that any changes are well thought out.\nFor 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).\nAnd for further changes, there will be a Helm 5 release of course!\n\n## Specification\n\n### The process / timelines\n\nHelm 4 development will consist of three main phases:\n1. Planning\n1. Feature development\n1. Release preparation\n\nThe timeline will be approximately:\n\n1. Marking this HIP as \"accepted\"\n1. Naming of a Release Engineer: Nov. 2024\n1. Kick-off: KubeCon/CloudNativeCon North America 2024 (Nov. 2024, Salt Lake City)\n1. Earliest that engineering can begin: Nov. 2024\n1. Feature freeze for release preparation: By Aug. 2025\n1. Expected release of Helm v4.0.0: By the week before KubeCon/CloudNativeCon North America 2025 (expected Nov. 2025)\n\nHelm 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.\n\nHelm 3 will reach end of life 6-8 months after Helm 4 release (July 2026 estimated)\n\n### Change suitability\n\nThe Helm ecosystem is large, including not just the Helm CLI but also the SDK, Charts, and Chart repositories, plugins.\nHelm also has several [roles or personas](/community/user-profiles) for different user categories, from \"Application Operators\" to \"Helm Developers.\"\nThe Helm project must be careful in how it delivers changes without causing significant adverse impact to Helm's users or the overall Helm ecosystem.\n\nTherefore, 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.\nClear migration options and paths should be documented and presented for Helm 3 users to update to Helm 4.\n\n### Change proposals\n\nTo ensure that Helm 4 changes align with this HIP, Helm core maintainers will review proposals.\nThese proposals can take the form of lighter-weight Helm 4-specific proposals \"H4HIP\"s, or standard HIPs suitable for Helm 4 implementation.\nStandard Helm HIPs that are marked suitable for Helm 4 will also be accepted.\n\n#### Helm 4 proposals (H4HIPs)\n\nA H4HIP is simply a reduced version of a standard Helm HIP.\nThey follow the same format as a HIP, but the author can choose to skip sections they do not feel applicable.\nIntended to minimize the friction required for implementing small, functional changes in Helm 4 that do not warrant a full HIP process.\nAnd to allow categorization of changes specific to the Helm 4 process and changes.\nAs well as to avoid feature development from Github issues.\n\n### Compatibility\n\nEven 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.\nDue to Helm's maturity and the extensive ecosystem built around its CLI, charts, SDK, etc.\n\nWhere non-compatible changes are introduced, they should have migration documentation for equivalent functionality.\nFunctionality removal should prefer deprecation over immediate removal.\nBehavioral changes that negatively impact a significant number of users without reasonable migration options cannot be allowed.\n\nSpecific requirements for compatibility include the following:\n\n#### Compatibility with existing charts and releases\n\nWhile the tooling can evolve, Helm must maintain compatibility with existing charts and releases.\nA Helm 4 that cannot operate on Helm 3 charts (and vice versa) effectively becomes a different tool, which likely would diverge the Helm ecosystem.\n\nSpecifically, charts deployable with Helm 3 should be deployable by Helm 4.\nSimilarly, any existing chart (release) managed by Helm 3 must be upgradable by Helm 4.\nHowever, Helm 3 may not be able to manage releases created using later Helm 4.x series (which may introduce incompatible changes).\n\nExceptions for already deprecated functionality, such as `requirements.yaml`, may be made.\n\n#### Compatibility with existing CLI workflows\n\nThe 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.\n\nA judgment call will be required by the release engineer and maintainers regarding how much a given change might impact user workflows.\nPossible mitigation strategies for those changes should also be considered.\n\nAs 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.\nChanges should be clearly documented in a migration guide.\n\nMore advanced users, such as \"Application Developers,\" might be subject to more significant changes at the discretion of the release engineer and maintainers.\n\n### The Release Engineer\n\nA single individual will oversee the planning and development phases of Helm 4.\nThis person will be the _Release Engineer_.\nFor Helm v4 the _Release Engineer_ will be Matt Farina.\nThe person will have the following responsibilities:\n\n- Lead the kick-off meeting\n- Define the process for including features\n- Determine the timelines for development\n- Make the determination of when the project has indeed reached a milestone\n- Name and oversee releases\n- 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)\n\n#### Determining Who Will Be Release Engineer\n\nTo become the release engineer for the Helm project, an individual must be a core maintainer on <https://github.com/helm/helm> project.\nThe engineer must be an active core maintainer.\nSelf-nominations are encouraged, and potential nominees must agree to their nomination.\nThe Helm project maintainers will then decide which nominated maintainer should serve as the release engineer.\n\nIf the release engineer is unable to fulfill their duties, the Helm project maintainers may select a replacement.\n\n#### Planning\n\nThis phase begins when the release engineer is appointed.\nThe goal of the planning phase is to have a specific period to prioritize writing and reviewing proposals.\nAnd enable time to focus on buidling, prioritizing and reviewing the major changes for Helm 4.\n\nThe release engineer shall schedule a kick-off meeting, inviting all Helm maintainers from any Helm org project to attend.\nThe release engineer may also decide who else to include and whether the meeting will be public.\nDuring the kick-off meeting, participants are encouraged to propose feature ideas and changes, with preference given to those already documented as HIPs.\n\nThis process continues until the release engineer deems it sufficient, but for a minimum of two months, to allow ample community input.\n\nAll proposed features and breaking changes must be described in a standard HIP or Helm 4 proposal (H4HIP).\nThis approach offers several advantages:\n- All changes are documented\n- Changes undergo scrutiny before PR creation\n- A clear record of alternative considerations exists\n\nMinor non-functional changes for \"bug fixes\" or cleanup, as determined by core maintainers, do not require formal proposals.\n\nThe outcome of the planning cycle is a well-documented list of approved HIPs detailing Helm 4's major changes.\nThis list will serve as the foundation for working on Helm 4.\n\nItems which are readily agreeable for Helm 4 (as determined by the release engineer and core maintainers) may begin implementation during the planning phase.\nCleanup and non-functional changes may proceed while in the planning phase.\n\n#### Feature Development\n\nDuring this phase, agreed-upon features and changes from the planning stage will be implemented.\nBreaking changes are permitted, as well as experimental features that may be removed before final release.\nThe 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.\n\nAdditional features can be propsed during the feature development phase, at the release engineers discretion.\n\nThis phase concludes with Alpha releases, where new features can still be incorporated and breaking changes may be implemented at the release engineer's discretion.\n\n#### Release Preparation\n\nDuring this final phase, no new features will be added except for those deemed critical by the release engineer.\nThe focus shifts towards bug fixes, documentation improvement, security audits and addresses, and preparation of the ecosystem, such as chart modifications.\nAll Beta and Release Candidates (RC) are produced during this stage.\n\nBefore the stable release, there will be a 4-6 week testing period for public feedback.\nThe duration is determined based on the testing progress and the trust in the code leading up to the release candidate window.\n\nThis 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.\n\n### Halting Helm 4 Development\n\nDuring the course of Helm 4 development, it may become clear that there is not enough justification for continuing development.\nReasons could include insufficient feature HIPs or lack of sponsorship and support from Helm project maintainers.\n\nIf this occurs, the Helm maintainers can hold a \"circuit breaker\" vote to temporarily halt Helm 4 development until a more suitable time arises.\n\nThe procedure for stopping Helm 4 development requires a simple majority vote among the Helm project maintainers.\n\n### Maintaining Helm 3\n\nThis section outlines how we will support Helm 3 throughout the Helm 4 development process.\nThe Release Engineer retains the freedom to modify this approach for the sake of providing the best experience to Helm users.\n\nDuring the \"Feature Development\" phase of Helm 4, Helm 3 will continue to receive security, bug, and minor feature patches.\n\nDuring 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.\n\nHelm 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.\n\n## Backwards compatibility\n\nNothing in this document contradicts our existing decision-making process.\nSpecifically, [HIP-0004](./hip-0004.md) pertains only to minor and patch releases, not major version releases.\nThis does not affect the PR review process or the HIP process, as both are expected to remain unchanged.\n\n## How to teach this\n\nThe plans for Helm 4 will to be announced during KubeCon/CloudNativeCon North America 2024 at both the Helm Maintainers talk and Helm 'contribfest'.\n\nThe content of this HIP will be discussed publicly in the regular Helm Dev meetings, which are recorded.\n\nThroughout 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\nmonth.\n\n## Rejected ideas\n\nHelm 3 was primarily developed using an informal version of the proposed process, but we were criticized for lacking documentation and transparency.\nThis proposal presents an alternative to an \"informal process,\" which might elicit similar criticism.\n\nMultiple release engineers were considered, but deemed inappropriate for two reasons:\n1. The need for a singular authority in charge of architectural integrity and resolution\n2. The lack of sufficient Helm core maintainers to justify a committee\n\nWe entertained the idea of allowing a non-core maintainer to serve as release engineer, but rejected it due to these concerns:\n1.  A release engineer requires comprehensive knowledge of Helm's design, intents, and implementation, which is best ensured through maintainer status\n2. A non-core maintainer is not bound by the core maintainer process, potentially introducing tension and exceptionalism\n\nWe 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.\nWe regard the release engineer position as more akin to an architect than a project manager.\n\nWe 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.\nRelease engineering is beyond their charter.\n\nWe 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.\nHowever, we also faced pushback from the community regarding major changes being implemented without proper discussion.\nFurthermore, there is a lack of documentation detailing past decisions made in Helm 2, with only a few draft documents available in Helm 3.\n\nTherefore, 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.\nWhile some may argue this adds unnecessary overhead, we believe the advantages far outweigh the burden.\n\nWe considered eliminating the mandatory minimum durations for planning and release preparation periods.\nHowever, careful consideration is required during a major version transition on a project as impactful as Helm's.\nIt is in the community's best interest for developers to proceed at a deliberate pace with clearly defined timeframes.\n"
  },
  {
    "path": "community/hips/hip-0014.md",
    "content": "---\ntitle: Helm Triage Maintainers\nsidebar_label: \"0014: Helm Triage Maintainers\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0014.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0014 | Helm Triage Maintainers | Matthew Fisher <matt.fisher@microsoft.com> | 2021-07-06 | process | accepted |\n\n\n## Abstract\n\nThe existing Helm Project Maintainers have identified the need for a new \"triage\" role. This document lists out the responsibilities of this new role.\n\n## Motivation\n\nHelm Project Maintainers are responsible for activities surrounding the development and release of code, the operation of any services they own (e.g. <https://get.helm.sh>), 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.\n\nThis new role provides three benefits:\n\n1. New Triage Maintainers can help maintain the project's day-to-day, such as responding to new tickets and review pull requests\n2. Helm project maintainers' burden is reduced, allowing them to carry out higher-level tasks like coordinating software releases, organizing events, and maintaining production services.\n3. Provides an easier on-ramp from community members, to Triage Maintainers, to project maintainers, to org maintainers.\n\n## Rationale\n\nProject 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.\n\n## Specification\n\nThe new Triage Maintainer role is allowed to perform certain day-to-day tasks as a maintainer of the project, including:\n\n- attach labels to issues\n- assign issues to milestones\n- review and approve pull requests\n- nominate new Triage Maintainers\n- nominate new Core Maintainers\n\nThe following roles and responsibilities are NOT allowed to be performed under this role:\n\n- merge pull requests\n- release new revisions of the Helm Client\n- operate any public-facing services, such as\n   - <https://get.helm.sh>\n   - Mailing lists\n   - Slack channels\n   - The helm/helm GitHub project\n- organize official LF events (Helm Summit)\n- vote on governance-related topics (including membership votes)\n- become a member of the security team\n- receive access to the helm_project Keybase team\n- receive access to the cncf-helm-core-maintainers mailing list\n\nThese 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.\n\nThe 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.\n\nThe 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.\n\nAfterwards, 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.\n\n## Backwards compatibility\n\nCommunity 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.\n\n## Security implications\n\nThe 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.\n\n## How to teach this\n\nThe contents of this HIP will be discussed in the public Helm Dev meeting, which is recorded.\n\n## Rejected ideas\n\nThe 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.\n\n## Open Questions\n\nAll 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.\n\nShould 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?\n\nA: 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.\n\n## References\n\n- The Helm organization's [governance structure](/community/governance/governance)\n- The Helm organization's [team structure](https://github.com/helm/community/blob/main/maintainer-groups.yaml)\n"
  },
  {
    "path": "community/hips/hip-0015.md",
    "content": "---\ntitle: Annotation for Images used by Helm Charts\nsidebar_label: \"0015: Annotation for Images used by Helm Charts\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0015.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0015 | Annotation for Images used by Helm Charts | Tom Runyon <tom@defenseunicorns.com>, Scott Rigby <scott@weave.works>, Andrew Block <ablock@redhat.com> | 2021-10-07 | feature | draft |\n\n\n## Abstract\n\nThe 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.\n\n## Motivation\n\nWithout 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.\n\n## Rationale\n\nThe `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_.\n\n## Specification\n\nA helm chart would be define the images in the `annotations` field:\n\n```yaml\napiVersion: v1\nversion: 6.0.0\nappVersion: 6.0.0\nname: podinfo\nengine: gotpl\ndescription: Podinfo Helm chart for Kubernetes\nhome: https://github.com/stefanprodan/podinfo\nmaintainers:\n  - email: stefanprodan@users.noreply.github.com\n    name: stefanprodan\nsources:\n  - https://github.com/stefanprodan/podinfo\nkubeVersion: \">=1.19.0-0\"\nannotations:\n  helm.sh/images: |\n    - name: podinfo\n      image: ghcr.io/stefanprodan/podinfo:6.0.0\n    - name: redis\n      image: dockerhub.io/_/redis:6.0.8\n      whitelisted: true\n```\n\nWhen 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:\n\n```yaml\nannotations:\n  category: Infrastructure\n  images: |\n    - name: kafka\n      image: docker.io/bitnami/kafka:2.8.1-debian-10-r0\n    - name: kubectl\n      image: docker.io/bitnami/kubectl:1.19.5-debian-10-r3\n    - name: shell\n      image: docker.io/bitnami/bitnami-shell:10-debian-10-r199\n    - name: kafka-exporter\n      image: docker.io/bitnami/kafka-exporter:1.4.2-debian-10-r5\n    - name: jmx-exporter\n      image: docker.io/bitnami/bitnami/jmx-exporter:0.16.1-debian-10-r66\n    - name: zookeeper\n      image: docker.io/bitnami/zookeeper:3.7.0-debian-10-r157\n      dependency: zookeeper\n    - name: shell\n      image: docker.io/bitnami/bitnami-shell:10-debian-10-r202\n      dependency: zookeeper\napiVersion: v2\nappVersion: 2.8.1\ndependencies:\n  - name: common\n    repository: https://charts.bitnami.com/bitnami\n    tags:\n      - bitnami-common\n    version: 1.x.x\n  - condition: zookeeper.enabled\n    name: zookeeper\n    repository: https://charts.bitnami.com/bitnami\n    version: 7.x.x\ndescription: Apache Kafka is a distributed streaming platform.\nengine: gotpl\nhome: https://github.com/bitnami/charts/tree/master/bitnami/kafka\nicon: https://bitnami.com/assets/stacks/kafka/img/kafka-stack-220x234.png\nkeywords:\n  - kafka\n  - zookeeper\n  - streaming\n  - producer\n  - consumer\nmaintainers:\n  - email: containers@bitnami.com\n    name: Bitnami\nname: kafka\nsources:\n  - https://github.com/bitnami/bitnami-docker-kafka\n  - https://kafka.apache.org/\nversion: 14.2.1\n```\n\nIt's worth noting that the `bitnami-shell` image is used in both zookeeper and kafka, but with different tags.\n\n## Backwards compatibility\n\nSince there is no existing specification, the annotation will be optional to support backwards compatibility.\n\n## Security implications\n\nHave to think about it, but don't see any.\n\n## How to teach this\n\nThe 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.\n\n## Rejected Ideas\n\n### Helm Templating Discovery\n\nThe 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.\n"
  },
  {
    "path": "community/hips/hip-0016.md",
    "content": "---\ntitle: Add export-values directive (similar to import-values)\nsidebar_label: \"0016: Add export-values directive (similar to import-values)\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0016.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0016 | Add export-values directive (similar to import-values) | Jan von Loewenstein <jan.von.loewenstein@sap.com>, Johannes Dillmann <j.dillmann@sap.com>, Pavel Busko <pavel.busko@sap.com>, Philipp Stehle <philipp.stehle@sap.com>, Ralf Pannemans <ralf.pannemans@sap.com>, Sumit Kulhadia <sumit.kulhadia@sap.com> | 2022-02-01 | feature | draft |\n\n\n## Abstract\n\nComposing 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.\n\nWith 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.\nThis 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.\nWith 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.\n\nThis change was discussed in [helm/#3242]. There were several attempts to implement this: [helm/#7477], [helm/#10059].\n\n## Specification\n\nWith 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**.\n\n```yaml\n# Chart.yaml:\ndependencies:\n  - name: client\n    version: 1.0.0\n    export-values:\n    - parent: \"port\"\n      child: \"serverPort\"\n  - name: server\n    version: 1.0.0\n    export-values:\n    - parent: \"port\"\n      child: \"exposePort\"\n    - \"server-config\"\n```\n\n```yaml\n# values.yaml\nport: 8080\nexports:\n  server-config:\n    debug: true\n```\n\n```yaml\n# charts/client/values.yaml\nserverPort: 9090\n```\n\n```yaml\n# charts/server/values.yaml\nexposePort: 80\ndebug: false\n```\n\n### Value Precedence\n\nBecause 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.\n\nSuggested precedence:\n\n1. Explicitly set for subchart value (`client.port`)\n1. Explicitly set for parent chart's value (`port`)\n1. default for parent chart's value (`values.yaml` in parent chart)\n1. default for subchart value (`values.yaml` in subchart)\n\nFor 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.\nIn contrast using e.g. `--set client.serverPort=42` would only overwrite the `.Values.client.serverPort` value.\n\n### Combination with `import-values`\n\nIt 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.\n\n## Motivation\n\nCurrently, it is not possible to compose charts using dependencies without leaking the structure of the values of the subcharts used.\nUsers 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.\n\nThis HIP would allow to freely structure the values the user interacts with.\n\nThe problem described above is less severe, if the subchart author, parent chart author and consumer are the same person or team.\nIt 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.\n\n## Rationale\n\nUsing 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.\n\n```yaml\n# values.yaml\nclient:\n  serverPort: 8080\n\nserver:\n  exposePort: 8080\n```\n\nThe proposed structure is not only cleaner for the user, but also less error prone since the port value is only maintained once.\n\n## Backwards Compatibility\n\nOn one hand this change won't break any existing Helm chart since it only adds new mechanisms.\nOn 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.\nThere is currently no way to specify a minimum Helm version.\nThe current workaround is to add this to a parent chart template, which will fix the otherwise silent failure:\n`{{- if semverCompare \">3.10.0\" .Capabilities.HelmVersion.Version }} {{- fail \"This chart requires helm version 3.10.0 or higher\" }} {{- end }}`.\nA built-in mechanism to specify a minimum Helm version for a chart could be introduced in a separate HIP.\nUntil 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.\n\n## Reference Implementation\n\nTBD\n\n[helm/#3242]: https://github.com/helm/helm/issues/3242\n[helm/#7477]: https://github.com/helm/helm/pull/7477\n[helm/#10059]: https://github.com/helm/helm/pull/10059\n[import-values]: https://helm.sh/docs/topics/charts/#importing-child-values-via-dependencies\n"
  },
  {
    "path": "community/hips/hip-0017.md",
    "content": "---\ntitle: Helm OCI MediaType Registration\nsidebar_label: \"0017: Helm OCI MediaType Registration\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0017.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0017 | Helm OCI MediaType Registration | Andrew Block <andy.block@gmail.com> | 2022-06-09 | informational | accepted |\n\n\n## Abstract\n\nThe 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.\n\n## Motivation\n\nSupport 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.\n\n## Rationale\n\nA 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.\n\n## Specification\n\nEach 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.\n\n### Helm Config\n\nThe [OCI config](https://github.com/opencontainers/image-spec/blob/main/config.md) containing a JSON formatted representation of the Helm `Chart.yaml` file.\n\n&nbsp; | &nbsp;\n------ | -----\n| Type Name | application |\n| Tree | Vendor Tree (vnd prefix) |\n| Subtype Name | `cncf.helm.config.v1+json` |\n| Required Parameters | Fields as required per the Chart.yaml definition |\n| Optional Parameters | Remaining fields which as defined within the Chart.yaml definition which are not noted as required |\n| Encoding Considerations | Encoding considerations are identical to those specified for the \"application/json\" media type.  See [RFC8259](https://datatracker.ietf.org/doc/html/rfc8259). |\n| 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. |\n| Interoperability Consideration | N/A |\n| Published specification | [https://helm.sh/docs/topics/charts/#the-chartyaml-file](https://helm.sh/docs/topics/charts/#the-chartyaml-file) |\n| Application Usage | Internally within the Helm package manager as well as various interfacing applications |\n| Fragment Identifier Considerations | N/A |\n| Restrictions on Usage | N/A |\n| Provisional Registrations | N/A |\n| Additional Information | <ol><li>Deprecated alias names for this type: None</li><li>Magic number(s): None</li><li>File extension(s): .json</li><li>Macintosh file type code: TEXT</li><li>Object Identifiers: None</li></ol>|\n| Intended Usage | Common |\n| Other Information and Comments | N/A |\n\n### Helm Content\n\nRepresents the packaged Helm chart.\n\n&nbsp; | &nbsp;\n------ | -----\n| Type Name | application |\n| Tree | Vendor Tree (vnd prefix) |\n| Subtype Name | `cncf.helm.chart.content.v1.tar+gzip` |\n| Required Parameters | N/A |\n| Optional Parameters | N/A |\n| Encoding Considerations | Binary |\n| 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. |\n| Interoperability Consideration | N/A |`\n| Published specification | None |\n| Application Usage | Internally within the Helm package manager as well as various interfacing applications |\n| Fragment Identifier Considerations | N/A |\n| Restrictions on Usage | N/A |\n| Provisional Registrations | N/A |\n| Additional Information | <ol><li>Deprecated alias names for this type: None</li><li>Magic number(s): None</li><li>File extension(s): None</li><li>Macintosh file type code: None</li><li>Object Identifiers: None</li></ol>\n| Intended Usage | Common |\n| Other Information and Comments | N/A |\n\n### Helm Provenance\n\nRepresents the Helm Provenance file associated with a signed chart.\n\n&nbsp; | &nbsp;\n------ | -----\n| Type Name | application |\n| Tree |Vendor Tree (vnd prefix) |\n| Subtype Name | `cncf.helm.chart.provenance.v1.prov` |\n| Required Parameters | Fields as specified within Helm provenance file definition |\n| Optional Parameters N/A |\n| Encoding Considerations | The utf-8 charset is always used for this type |\n| 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.\n| Interoperability Consideration | N/A |\n| Published specification | <https://helm.sh/docs/topics/provenance/#the-provenance-file> |\n| Application Usage | Internally within the Helm package manager as well as various interfacing applications |\n| Fragment Identifier Considerations | N/A |\n| Restrictions on Usage | N/A |\n| Provisional Registrations | N/A |\n| Additional Information | <ol><li>Deprecated alias names for this type: None</li><li>Magic number(s): None</li><li>File extension(s): None</li><li>Macintosh file type code: Text</li><li>Object Identifiers: None</li></ol> |\n| Intended Usage | Common |\n| Other Information and Comments | N/A |\n\n## Backwards Compatibility\n\nN/A\n\n## Security implications\n\nN/A\n\n## Reference implementation\n\nThe 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).\n\n## Rejected ideas\n\nNone\n\n## Open issues\n\nNone\n\n## References\n\nExisting 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:\n\n* [json](https://www.iana.org/assignments/media-types/application/json)\n* [gzip](https://www.iana.org/assignments/media-types/application/gzip)\n* [wasm](https://www.iana.org/assignments/media-types/application/wasm)\n"
  },
  {
    "path": "community/hips/hip-0018.md",
    "content": "---\ntitle: Add Repository URL and tarball digest to a chart's release metadata\nsidebar_label: \"0018: Add Repository URL and tarball digest to a chart's release metadata\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0018.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 18 | Add Repository URL and tarball digest to a chart's release metadata | Luke Reed <luke@lreed.net>, Andy Suderman <andy@suderman.dev> | 2021-11-24 | feature | draft |\n\n\n## Abstract\n\nCurrently 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.\n\nThe 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.\n\n## Motivation\n\nThe 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:\n- 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.\n- 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.\n- 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.\n\n## Rationale\n\nIn 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.\n\n## Specification\n\nNothing 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.\n\nThe 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.\n\nMore 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.\n\nWhen 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.\n\nThe chart metadata object would have new fields that looked like so:\n\n```\n\"repoURL\": \"https://charts.fairwinds.com/stable\"\n\"tarballDigest\": \"sha256:f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9\"\n```\n\nAnd an OCI compliant repository would look like this (example is using ECR):\n\n```\n\"repoURL\": \"oci://${ACCOUNT_NUMBER}.dkr.ecr.us-east-1.amazonaws.com/goldilocks\"\n\"tarballDigest\": \"sha256:f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9\"\n```\n\n## Backwards compatibility\n\nThere should be no impact to backwards compatibility.\n\n## Security implications\n\nA 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.\n\nAnother 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.\n\nA 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.\n\n## How to teach this\n\nThe 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.\n\n## Reference implementation\nA PR has been created to show a possible implementation: https://github.com/helm/helm/pull/10369\n\n## Rejected ideas\n\nN/A. I don't know of any other ideas proposed for this feature.\n\n## Open issues\n\nN/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\n\n## References\n\n- Github issue that would be fixed by this feature: https://github.com/helm/helm/issues/4256\n- Github PR that proposes a solution for this: https://github.com/helm/helm/pull/10369\n"
  },
  {
    "path": "community/hips/hip-0019.md",
    "content": "---\ntitle: New annotations for displaying hook output\nsidebar_label: \"0019: New annotations for displaying hook output\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0019.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 19 | New annotations for displaying hook output | Ian Zink <ian@replicated.com> | 2023-01-26 | feature | draft |\n\n\n## Abstract\n\nThis proposes a new annotation to indicate that the output from the hook should be displayed to the user.\n\n## Motivation\n\nThe 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.\n\nOften 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.\n\nAnother 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.\n\nIn 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.\n\n## Rationale\n\nThere 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.\n\nAnother 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. \n\n## Specification\n\nTemplates may include the following annotations on Jobs or Pods:\n    \n```yaml\n        \"helm.sh/hook\": pre-install, pre-upgrade\n        \"helm.sh/hook-output-log-policy\": hook-failed # or hook-succeeded or hook-failed,hook-succeeded\n```\n\n\n`helm.sh/hook-output-log-policy` would indicate that Helm should display the output of the Job to the user.\n\nAdditionally, a new user flag should be created `--no-log-output`  that would skip the output of logs.\n\nAdditionally, there will be a new item added to the action SDK configuration to allow SDK consumers to get the output. \nBy default this output will be discarded by writing to `io.Discard`, but an SDK consumer can overwrite the HookOutputFunc to provide a custom writer.\n\n\n```go\ntype Configuration struct {\n  ...\n\t// Called with container name and returns and expects writer that will receive the log output\n\tHookOutputFunc func(namespace, pod, container string) io.Writer\n}\n```\n\n## Backwards compatibility\n\nThe 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.\n\n## Security implications\n\nPotentially the preflight checks could check for security misconfigurations that could enhance the security of the chart deployment.\n\n## How to teach this\n\nIn the first instance, documentation plus the help text for `helm install` would explain the feature.\n\nAn example template could be provided in documentation showing how to use this feature with a generic command used in a hook.\n\nA 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.\n\n## Reference implementation\n\n[Pull Request for Documentation ](https://github.com/helm/helm-www/pull/1242)\n\n[Pull Request for Helm](https://github.com/helm/helm/pull/10309) - most upvoted open PR\n\n\n## Rejected ideas\nN/A\n\n## Open issues\nN/A\n\n## References\n\n[Troubleshoot.sh](https://troubleshoot.sh/) - the tool that is the motivation for this HIP. \n\n[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.\n\n## Reference - Examples Usage\n\n### Example using `false`\n\nTemplate:\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}-false-job\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    \"helm.sh/hook\": pre-install, pre-upgrade\n    \"helm.sh/hook-output-log-policy\": hook-failed, hook-suceeded\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded, hook-failed\n\nspec:\n  backoffLimit: 0\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.18\"\n        command: [\"sh\", \"-c\", \"echo foo ; false\"]\n```\n\nWhat it should loook when running:\n\n```text\n$ helm install ./ my-release\nLogs for pod: my-release-false-job-bgbz6, container: pre-install-job\nfoo\nError: INSTALLATION FAILED: failed pre-install: job failed: BackoffLimitExceeded\n```\n\n### Example using Troubleshoot Preflight Checks\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}-preflight-job\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    \"helm.sh/hook\": pre-install, pre-upgrade\n    \"helm.sh/hook-output-log-policy\": hook-failed\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded, hook-failed\n\nspec:\n  backoffLimit: 0\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      volumes:\n        - name: preflights\n          configMap:\n            name: \"{{ .Release.Name }}-preflight-config\"\n      containers:\n      - name: post-install-job\n        image: \"replicated/preflight:latest\"\n        command: [\"preflight\", \"--interactive=false\", \"/preflights/preflights.yaml\"]\n        volumeMounts:\n        - name: preflights\n          mountPath: /preflights\n\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  annotations:\n    \"helm.sh/hook\": pre-install, pre-upgrade\n    \"helm.sh/hook-weight\": \"-6\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded, hook-failed\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  name: \"{{ .Release.Name }}-preflight-config\"\ndata:\n  preflights.yaml: |\n    apiVersion: troubleshoot.sh/v1beta2\n    kind: Preflight\n    metadata:\n      name: preflight-tutorial\n    spec:\n      collectors:\n        {{ if eq .Values.mariadb.enabled false }}\n        - mysql:\n            collectorName: mysql\n            uri: '{{ .Values.externalDatabase.user }}:{{ .Values.externalDatabase.password }}@tcp({{ .Values.externalDatabase.host }}:{{ .Values.externalDatabase.port }})/{{ .Values.externalDatabase.database }}?tls=false'\n        {{ end }}\n      analyzers:\n        - clusterVersion:\n            outcomes:\n              - fail:\n                  when: \"< 1.16.0\"\n                  message: The application requires at least Kubernetes 1.16.0, and recommends 1.18.0.\n                  uri: https://kubernetes.io\n              - warn:\n                  when: \"< 1.18.0\"\n                  message: Your cluster meets the minimum version of Kubernetes, but we recommend you update to 1.18.0 or later.\n                  uri: https://kubernetes.io\n              - pass:\n                  message: Your cluster meets the recommended and required versions of Kubernetes.\n        {{ if eq .Values.mariadb.enabled false }}\n        - mysql:\n            checkName: Must be MySQL 8.x or later\n            collectorName: mysql\n            outcomes:\n              - fail:\n                  when: connected == false\n                  message: Cannot connect to MySQL server\n              - fail:\n                  when: version < 8.x\n                  message: The MySQL server must be at least version 8\n              - pass:\n                  message: The MySQL server is ready\n        {{ end }}\n```\n\nWhich should yield the following output to stdout:\n\n```text\n$ helm install ./ my-release\nLogs for pod: my-release-preflight-job-bgbz6, container: pre-install-job\n   --- FAIL: Required Kubernetes Version\n      --- The application requires at least Kubernetes 1.16.0, and recommends 1.18.0.\n   --- FAIL: Must be MySQL 8.x or later\n      --- Cannot connect to MySQL server\n--- FAIL   preflight-tutorial\nFAILED\nname: cluster-resources    status: completed       completed: 1    total: 3\nname: mysql/mysql          status: running         completed: 1    total: 3\nname: mysql/mysql          status: completed       completed: 2    total: 3\nname: cluster-info         status: running         completed: 2    total: 3\nname: cluster-info         status: completed       completed: 3    total: 3\n\nError: INSTALLATION FAILED: failed pre-install: job failed: BackoffLimitExceeded\n\n```\n"
  },
  {
    "path": "community/hips/hip-0020.md",
    "content": "---\ntitle: \"H4HIP: Charts v3 Enablement\"\nsidebar_label: \"0020: H4HIP: Charts v3 Enablement\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0020.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0020 | H4HIP: Charts v3 Enablement | Matt Farina <matt.farina@suse.com> | 2025-01-09 | feature | accepted |\n\n\n## Abstract\n\nThis HIP proposes the creation of charts v3, updating Helm to handle charts v2 and v3, and a\ntimeline for the general availability of charts v3 that can happen after the release of Helm v4.0.0.\n\n## Motivation\n\nMany of the proposed changes for Helm v4 affect charts. Layering these onto existing charts will\nsometimes cause chart installation and upgrade to happen differently in Helm v3 and Helm v4, as\nboth will need to live side by side for a time. It also means that testing of charts for v3 can produce\na different result when installed with Helm v4.\n\nIn addition to the affects of the changes, Helm v4 development has a fixed timeline and making\nchanges to Helm in addition to reworking charts is not likely to fit within that fixed window. Enabling\nthe development of charts v3 to happen as an experiment that becomes generally available after\nthe release of Helm v4 provides more time to continue the work and get feedback.\n\nThe goal is to provide adequate time to work on chart changes while doing it in a way that enables\ntrust in existing charts to run as they were tested.\n\n## Rationale\n\nCharts v2 were created for Helm v3 and introduced minor changes. The code that handles the chart\nversions is the same with some checking to handle the differences. This handling ended up having\nnumerous bugs that had to be worked out in patch releases.\n\nThe chart changes being proposed for Helm v4 are more significant. Mixing those in alongside the\ncurrent chart version handling will have trouble limiting bugs will enabling the changes and keeping\nexisting charts functioning properly.\n\nThe design specified here is meant to enable the current charts to work as expected while providing\nspace for more radical changes.\n\n## Specification\n\nHelm has numerous packages that do various things, from working with charts to storing release\ninformation. These packages all expect there to be one version of a particular thing. To support\nmultiple versions of charts, the `chart`, `chartutil`, `engine`, and `release` packages will be made\nmulti-version. (e.g., engine will have a v1 and v2 versions). In addition to enabling a new version of\ncharts, this will enable the gotpl engine to evolve as needed to support the new version of charts. \nThe `chartutil` may be combined with the `chart` package and the `releaseutil` package may be\ncombined with the `release` package for simplification of the package structure.\n\nThe versioning of the packages will follow the same structure that Kubernetes does with its APIs.\nThis means a thing will have a directory and within it will be sub-directories for the versions. The\nversion specific implementation will be in the version specific sub-directory. For example,\n\n```\nchart\n├── v2\n└── v3\n```\n\nThe version will not use a separate Git repository or Go modules. The reason for this is the added\ncomplexity of managing the repositories and modules is added work to manage changes which will\nslow down velocity, will make releases more complex, and make the Helm SDK more complicated\nto work with.\n\nThe existing versions of these packages will be externally facing while the new versions will be\ndeveloped in `internal` as experiments until they are complete enough for release. When ready for\nrelease, these packages will be moved to the public locations.\n\nTo illustrate this, while in development the `chart` package will have the following structure:\n\n```\ninternal/chart\n└── v3\npkg/chart\n└── v2\n```\n\nOnce the new chart packages have (a) a stable API and (b) are feature complete the structure will\nbe merged to look like:\n\n```\npkg/chart\n├── v2\n└── v3\n```\n\nWhile in development, as an experiment, the `pkg/gates` package will be used to create an opt-in\nenvironment variable to enable a new chart version. This is how the OCI experimental feature was\nhandled.\n\n## Backwards compatibility\n\nThis development and process is designed with backwards compatibility in mind. The package\nlocations will change, which is ok in a major version of Helm. The existing charts will be preserved\nso that their installation process continues to work as expected from Helm v3. New features and\nchanges to charts can be added in without impacting existing charts.\n\nWhile the new chart version is being developed and is going through breaking changes, the chart\nwill be an opt-in feature which will enable us to warn users about the state of it.\n\n## Security implications\n\nN/A\n\n## How to teach this\n\nThere are a few ways to teach this:\n\n1. **Documentation**: The chart documentation will be updated to teach both versions of charts.\n2. **Helm Create**: Helm create will be updated to use the new chart version and provide an example.\n3. **Blog and Webinars**: The marketing options open to Helm will be used to share details and teach about the new chart version.\n\n## Reference implementation\n\nN/A\n\n## Rejected ideas\n\nAn option to detect the chart version within existing code was seen as an option. This is how\ncharts `apiVersion` is handled for `v1` and `v2`. This is problematic as large changes in charts\nwill be difficult to work on and test to ensure nothing breaks across version.\n\n## Open issues\n\nN/A\n## References\n\nN/A"
  },
  {
    "path": "community/hips/hip-0021.md",
    "content": "---\ntitle: Enhanced logging library for Helm\nsidebar_label: \"0021: Enhanced logging library for Helm\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0021.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 21 | Enhanced logging library for Helm | Evans Mungai <mbuevans@gmail.com> | 2024-11-22 | feature | draft |\n\n\n## Abstract\n\nThis 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.\n\nThe 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.\n\n## Motivation\n\nThe current logging mechanism in Helm CLI and SDK lacks granularity and structure. Users and developers face difficulties when:\n\n- 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.\n- Instrumenting Helm code with clear and consistent logging conventions for contributors, as well as consumers of CLI and SDK logs.\n- 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\n\nThe 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.\n\n## Rationale\n\nThe following libraries were evaluated:\n\n1. **`slog`:**\n   - Provides log levels (`info`, `debug`, `error`, `warning`). More levels can be added\n   - Offers structured logging.\n   - Lightweight and straightforward to integrate.\n   - Is part of Go standard library\n   - Has `slog.Handler` interface that other logger implementations can implement to be `slog` compatible\n\nWhile 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.\n\n## Specification\n\n- Helm will instrument `debug`, `info`, `warning` and `error` log levels. These log levels will enable filtering of logs.\n- 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.\n- Ability to allow users to configure log levels and formatting through CLI flags or environment variables.\n- 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.\n- 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.\n- There will be structured logging with two options. Raw text for humans to view, and JSON formatting that machines can consume.\n- Ability for SDK users to override the default logger implementation. The SDK will expect at logger that implements `slog.Handler` interface.\n\n### Example:\n\nFor code where there is no context the implementation of `slog` will be static and we will directly call `slog`.\n\nFor example:\n\n``` go\nimport (\n\t\"log/slog\"\n)\n\nfunc MyFunc() {\n\t...\n\tslog.Debug(\"test debug\", \"test key\", \"test value\")\n\t...\n}\n```\n\n## Backwards Compatibility\n\nThe current logging system, Golang's `log` package will be replaced by `slog`.\n\n## Security Implications\n\nTBD\n\n## How to Teach This\n\n1. **Documentation Updates:**\n   - Provide examples of using the new logging features in the Helm documentation.\n   - Include a section on how to configure log levels and formats.\n   - 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.\n   - 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.\n   - Document how plugins and post-renderers can inherit log levels and formatting from helm CLI client.\n\n2. **CLI help text:**\n   - Use Helm CLI help messages (`helm --help`) to inform users about the new logging options.\n\n## Reference Implementation\n\n\n## Rejected Ideas\n\n1. **Sticking with the current logging system:**\n   - Rejected due to lack of flexibility and limited usefulness for debugging.\n2. 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.\n\n## Open Issues\n\n\n## References\n\n- [Go’s slog Documentation](https://pkg.go.dev/log/slog)\n"
  },
  {
    "path": "community/hips/hip-0022.md",
    "content": "---\ntitle: Wait With kstatus\nsidebar_label: \"0022: Wait With kstatus\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0022.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | **Helm Version** |\n|---|---|---|---|---|---|---|\n| 22 | Wait With kstatus | @austinabro321 | 2024-12-06 | feature | accepted | 4 |\n\n\n## Abstract\n\nCurrently 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.\n\n## Motivation\n\nBy introducing kstatus we will lower user friction with the `--wait` flag. \n\nCertain 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. \n\nCertain 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. \n\n## Rationale\n\nLeveraging 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`. \n\n## Specification\n\nThe 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.\n\nKstatus 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.\n\nAny 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. \n\nThe new client will look like: \n```go\ntype Client struct {\n\tFactory Factory\n\tLog     func(string, ...interface{})\n\tNamespace string\n\tkubeClient *kubernetes.Clientset\n\tWaiter\n}\ntype WaitStrategy int\nconst (\n\tStatusWaiter WaitStrategy = iota\n\tLegacyWaiter\n)\nfunc New(getter genericclioptions.RESTClientGetter, ws WaitStrategy) (*Client, error)\n```\n\nThe waiter interface will look like: \n```go\ntype Waiter interface {\n\tWait(resources ResourceList, timeout time.Duration) error\n\tWaitWithJobs(resources ResourceList, timeout time.Duration) error\n\tWaitForDelete(resources ResourceList, timeout time.Duration) error\n  WatchUntilReady(resources ResourceList, timeout time.Duration) error\n}\n```\n\n`Wait` will wait for all resources to be ready. This will include jobs, but this function not wait for jobs to be complete.\n\n`WaitWithJobs` will wait for all resources to be ready and all jobs to be complete.\n\n`WatchUntilReady` only waits for Pods and Jobs to complete. It is used for Helm hooks. This logic will stay the same.\n\nCalls 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).\n\nKstatus 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.\n\n## Backwards compatibility\n\nWaiting for custom resources and other previously not waited for resources could lead to charts timing out when using the new logic.\n\nThe 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.\n\nKstatus 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\n\nBelow 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.\n```yaml\nrules:\n  - apiGroups: [\"apps\"]\n    resources: [\"deployments\"]\n    verbs: [\"list\", \"watch\"] \n  - apiGroups: [\"apps\"]\n    resources: [\"replicasets\"]\n    verbs: [\"list\"]\n```\n\n\n## Security implications\n\nUsers 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. \n\n## How to teach this\n\nReplace 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.\n\n## Reference implementation\n\nseen here - https://github.com/helm/helm/pull/13604\n\n## Rejected ideas\n\n## Open issues\n\n[8661](https://github.com/helm/helm/issues/8661)\n\n## References\n\nexisting wait documentation - https://helm.sh/docs/intro/using_helm/\nkstatus documentation - https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/kstatus/README.md\nZarf kstatus implementation - https://github.com/zarf-dev/zarf/blob/main/src/internal/healthchecks/healthchecks.go"
  },
  {
    "path": "community/hips/hip-0023.md",
    "content": "---\ntitle: Utilize Server Side Apply for installs/upgrades\nsidebar_label: \"0023: Utilize Server Side Apply for installs/upgrades\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0023.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | **Helm Version** |\n|---|---|---|---|---|---|---|\n| 23 | Utilize Server Side Apply for installs/upgrades | George Jenkins <gvjenkins@gmail.com> | 2023-07-07 | feature | accepted | 4 |\n\n\n## Abstract\n\nThis 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.\n\n\n## Motivation\n\nHelm 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.\nKubernetes 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.\n\nKubernetes 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.\n\nThe following describes the advantages of SSA from Kubernetes perspective, where SSA generally is considered to be superior:\n\n<https://kubernetes.io/blog/2022/10/20/advanced-server-side-apply/>\n\n(See [KEP 555][kep555] and the Kubernetes [documentation][server-side-apply] for server-side apply's full motivation and detailed description)\n\nHelm supporting to SSA allows Helm users (chart operators) to realize the benefits of Kubernetes server-side field management for object updates.\nAnd 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.\n\nFinally, from a code maintenance benefit, SSA support may eventually allow Helm to eventually drop support for the strategic-merge patch CSA implementation/code.\n\n## Rationale\n\nKubernetes' 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.\n\nWith Helm 4, it was decided to opt into utilizing SSA by default.\nAllowing chart operators to gain the benefit of SSA without needing to know about the server-side vs. client-side mechanisms.\nIf 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.\n\nA CLI flag will allow users to override SSA opt-in and revert to utilizing CSA. Should a chart operator need for a particular circumstance.\n\nA chart release mechanism will allow Helm to track and follow SSA enablement for a given release.\nTracking 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).\n\nAdditionally it was desirable to mimic `kubectl`'s CLI interface/flags.\nAs a way for Helm to be consistent with an existing `kubectl` functionality that Kubernetes users may be familar with.\n\n## Specification\n\n### General\n\nHelm will add a new flag `--server-side=false|true|auto` to the install, upgrade and rollback commands (modeled after the like `kubectl apply` flag).\nAnd add a corresponding field to the respective install/upgrade/rollback SDK API objects.\n\nHelm will default to `true` for installs, enabling SSA.\nAnd `auto` for upgrade and rollbacks, where Helm will enable SSA based on the whether SSA was utilized for the prior release (see below).\nWhen enabled, Helm will submit object to the Kubernetes API server via SSA patches.\n\nIf SSA or CSA is utilized for a release, this will be stored as a field in the release's metadata.\nIf the field is unset when reading a prior release, this implies that the release was created with an old version of Helm utilizing CSA.\n\n```\ntype Release struct {\n   ApplyMethod *string  `json:\"apply_method,omitempty\"` // \"ssa\" | \"csa\"\n}\n```\n\nIf 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).\n\nIn 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).\n\n#### Custom resource objects\n\nHelm 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).\nThe API server will [merge custom resources][ssa-crds based on CRD metadata.\n\n#### Conflicts and forcing\n\nIt is possible that when Helm upgrades (or rollbacks) a chart, there will be a field conflict with another field manager.\nIn this case, Helm will report the error for the conflict field(s) to the user.\n\nHelm 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)\nAnd corresponding API objects field.\nWhen `true`, Helm will enabling overriding the field conflicts, setting field(s) to the charts values.\nAnd also make Helm the field manager for the conflicting field(s).\nThe `--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.\n\nFor more details, see SSA documentation [Overwrite value, become sole manager][ssa-conflicts]\n\n(To note, `helm upgrade|rollback` commands already includes a `--force` flag, which tells Helm to replace objects during upgrade.\nHowever, given this different semantics of `--force`, a new flag is required)\n\nAn 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.\nFor which the rollback will fail.\nSince 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).\nIf the user specified `--force-conflicts` to the upgrade, the corresponding rollback should similarly force conflicts (this is the behavior of `--force`).\nIf the rollback is to a release version which previously didn't have SSA enabled, the rollback install should also disable SSA.\n\n#### Special\n\n- `--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`.\n- 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\n- Client-side API object validation isn't applicable when SSA is enabled (`helm install|upgrade --disable-openapi-validation`)\n- Hooks could be deployed with SSA. But as hook objects are not updated (create/delete only), they are not really affected\n- Stored release manifests should not change (they store the object as Helm intends)\n\n### Implementation\n\nHelm will send object's manifests to the Kubernetes API server via SSA patches. Similar to `kubectl apply`.\nUtilizing the field manager name `\"helm\"`:\n\nhttps://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L248\nhttps://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L564-L602\n\n## Backwards compatibility\n\nSSA should be generally compatible functionality-wise with CSA.\nThe expectation is that SSA should generally produce equivalent Kubernetes objects as CSA.\n\nThere four main behavioural differences for Helm switching to SSA:\n\n1. The differences between object's manifests managed with SSA vs the existing three-way strategic merge process. SSA will enable:\n   - Arrays will be merged\n   - Removal of unset fields\n   - Default values\n2. 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\n3. SSA will apply to custom resources\n4. Field management ownership conflicts\n\nFor 1., chart-operators may opt-out out of SSA.\nFor 2., the user can control by ensuring SSA is consistently used within their environment.\nFor 3., it is generally considered a limitation of Helm not updating custom resource objects, for which SSA is expected to be an improvement.\nFor 4., the `--force-conflicts` flag exists.\n\nAdditionally as noted, SSA isn't compatible with very old Kubernetes versions (1.22 GA / 1.17 Beta)\n\n## Security implications\n\nThere should not be any additional security concerns.\nServer-side apply and client-side apply should be equivalent security-wise.\n\n## How to teach this\n\nDocumentation for how Helm does object upgrades, and the advantages of SSA.\nAlso documentation for the `--server-side=false|true|auto` and `--force-conflicts=false|true` flags, and the defaults for install/upgrades/rollbacks.\nAnd the corresponding documentation for the field(s) SDK API objects.\n\n## Reference implementation\n\nKubectl:\n- <https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L248>\n- <https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L564-L657>\n\nPrototype (hack) for Helm:\n- <https://github.com/helm/helm/compare/main...gjenkins8:helm:server_side_apply_proto>\n\n\n## Rejected ideas\n\n### Chart field manager support\n\nThis HIP defers including field manager support in charts.\nie. Helm could enable applying multiple manifests for the same object with distinct field manager names.\nEither from the same chart, or different charts/releases.\n\nIt 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.\nAnd `helm template` might somehow need to allow describing the object's field manager name in its output.\nAnd whether it would be needed to control per-manifest conflict forcing.\n\nOnce 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.\n\n### Field ownership transfer\n\nHelm won't support ownership transfer of fields.\nSimilar to the `kubectl` example: <https://kubernetes.io/docs/reference/using-api/server-side-apply/#transferring-ownership>.\n\nDissimilar to `kubectl`, Helm distinguishes between chart developers and chart operators.\nChart 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.\n\nOwnership transfer would likley first require charts have field manager support.\nAs well as additional support for per-object conflicts resolution.\n\n## Open issues\n\n## References\n\n- Kubernetes SSA documentation: [https://kubernetes.io/docs/reference/using-api/server-side-apply/][server-side-apply]\n- KEP-555: Server-side apply: [https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/555-server-side-apply/README.md][kep555]\n- Strategic Merge Patch: [https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md][strategic-merge-patch]\n- Kubectl SSA default: <https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3805-ssa-default#summary>\n- Structured Merge and Diff (`kubectl` client-side apply): <https://github.com/kubernetes-sigs/structured-merge-diff>\n- <https://pkg.go.dev/k8s.io/apimachinery/pkg/util/strategicpatch#CreateThreeWayMergePatch>\n\n[server-side-apply]: https://kubernetes.io/docs/reference/using-api/server-side-apply/\n[strategic-merge-patch]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md\n[kep555]: <https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/555-server-side-apply/README.md>\n[ssa-conflicts]: <https://kubernetes.io/docs/reference/using-api/server-side-apply/#conflicts>\n[ssa-crds]: <https://kubernetes.io/docs/reference/using-api/server-side-apply/#custom-resources>\n"
  },
  {
    "path": "community/hips/hip-0024.md",
    "content": "---\ntitle: Improve the Helm Documentation\nsidebar_label: \"0024: Improve the Helm Documentation\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0024.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0024 | Improve the Helm Documentation | Paige Calvert <eura.calvert@gmail.com> | 2025-05-07 | feature | draft |\n\n\n## Abstract\n\nThis 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.\n\nThis 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.\n\n## Motivation\n\nThis proposal identifies the following key areas for improvement in the Helm documentation:\n\n- 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.\n\n- There is no comprehensive introductory page explaining Helm’s purpose, personas, common use cases, and so on.\n\n-  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.\n\n## Rationale\n\nThe following describes the rationale behind improving each of the key areas listed under Motivation above:\n\n- 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.\n\n- 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.\n\n- 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.\n\n## Specification\n\nThis HIP proposes the following:\n\n1. **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.\n1. **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.\n1. **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.\n\nEach of these items would be presented for review by the Helm community.\n\nThese docs improvements could be published alongside the release of Helm 4. Implementations would include:\n- Migrate all the existing docs to the new site.\n   - Create the new sidebar to reorganize the docs.\n- Write the updated Helm overview content.\n- Docs for Helm 4:\n  1. Drafted in a branch initially\n  2. Helm 4 released, merge the Helm 4 docs, and publish the new docs site.\n\n## Backwards compatibility\n\nThis 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.\n\n## Security implications\n\nThere are no known security implications from this change, as it would affect only the public documentation and the docs toolchain.\n\n## How to teach this\n\n- Add clear contribution guides and README instructions in the docs repo, including templates and guidelines for docs contributors\n- Promote the new docs structure and toolchain through Helm community channels and other documentation update announcements.\n\n## Reference implementation\n\nNo 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.\n\n## Rejected ideas\n\nTo 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.\n\n## Open issues\n\nThe open issues for this HIP include the specific implementation strategy and timeline for each area for improvement, such as:\n\n- Creation of a roadmap/project plan to track progress  \n- Selection of the static site generator\n- Static site generator migration strategy and timeline\n- The specific information and/or visuals to add to a new overview page\n- Completion of content audit\n- The specific information architecture improvements that should be made, such as the different categories where content should be grouped\n- The strategy and timeline for making information architecture improvements\n\n## References\n\n- [Helm Documentation](https://helm.sh/docs)\n- [Docusaurus](https://docusaurus.io/)\n- [MkDocs](https://www.mkdocs.org/)\n"
  },
  {
    "path": "community/hips/hip-0025.md",
    "content": "---\ntitle: Better Support for Resource Creation Sequencing\nsidebar_label: \"0025: Better Support for Resource Creation Sequencing\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0025.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** |\n|---|---|---|---|---|---|\n| 0025 | Better Support for Resource Creation Sequencing | Joe Beck <joebeck5705@gmail.com>, Evans Mungai <mbuevans@gmail.com> | 2025-05-21 | feature | draft |\n\n\n## Abstract\n\nThis 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.\n\nAt a high level, this HIP proposes the following\n- Ability for chart authors to specify how to sequence deployment of **resources within a single chart**\n- Ability for chart authors to specify how to sequence **subcharts within a parent chart**\n- Ability for Helm operators and tool developers to enable sequencing behaviour using `--wait=ordered` CLI flag and `WaitStrategy=ordered` SDK parameter respectively\n\nThe 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.\n\n## Motivation\n\nThe 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.\n\nToday, 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.\n\nAdditionally, Helm currently doesn't provide a way to sequence when chart dependencies are deployed and this featureset would ideally address this.\n\n## Rationale\n\nThe 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.\n\n## Specification\n\nAt 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.\n\nFor 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.\n\nEach release will store information of whether sequencing was used or not. This information is used when performing uninstalls and rollbacks.\n\n### Sequencing Execution Flow\n\nWhen sequencing is enabled, Helm installs resources in a structured order across both subcharts and resource-groups:\n\n**1. Subchart Ordering**\n\nHelm builds a dependency graph from definitions in `Chart.yaml`:\n\n* `helm.sh/depends-on/subcharts` key in `annotations` field\n* `depends-on` key on `dependencies` list entries\n\nSubcharts are installed in dependency order. Each subchart must be fully deployed and ready before its dependents begin.\n\n**2. Resource-Group Sequencing (Per Chart)**\n\nWithin each chart (parent and subcharts), Helm builds a resource-group graph using:\n\n* `helm.sh/resource-group`\n* `helm.sh/depends-on/resource-groups`\n\nResources in each group are deployed together, and Helm waits for all to be ready before continuing to the next group.\n\n**3. Unsequenced Resources**\n\nResources that:\n\n* lack annotations,\n* depend on non-existent groups, or\n* belong to isolated groups\n\nwill be deployed after all properly sequenced groups have been processed.\n\nIf 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.\n\n*Additions to templates*\n\nThe following annotations would be added to enable this.\n- `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.\n- `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.\n\nThese annotations are only used for sequencing resources within the same chart. They do not influence or interact with resources across charts or subcharts.\n\n*Additions to Chart.yaml*\n* `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.\n- `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.\n\nThe 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.\n\n#### Template examples:\n```yaml\n# resource 1\nmetadata:\n  name: db-service\n  annotations:\n    helm.sh/resource-group: database\n---\n# resource 2\nmetadata:\n  name: my-app\n  annotations:\n    helm.sh/resource-group: app\n    helm.sh/depends-on/resource-groups: [\"database\", \"queue\"]\n---\n# resource 3\nmetadata:\n  name: queue-processor\n  annotations:\n    helm.sh/resource-group: queue\n    helm.sh/depends-on/resource-groups: [\"another-group\"]\n\n```\nIn 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:\n\n```\n\"database\" group:    [db-service]\n                          ||\n\"queue\" group:            || [queue-processor]\n                          ||       ||\n                          ||       ||\n                          \\/       \\/\n                           \\\\     //\n                            \\\\   //\n                             \\/ \\/\n\"app\" group:                 [my-app]\n```\n\n#### Chart dependencies example\n\nTo 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.\n\n```yaml\nname: foo\nannotations:\n  helm.sh/depends-on/subcharts: [\"bar\", \"rabbitmq\"]\ndependencies:\n  - name: nginx\n    version: \"18.3.1\"\n    repository: \"oci://registry-1.docker.io/bitnamicharts\"\n  - name: rabbitmq\n    version: \"9.3.1\"\n    repository: \"oci://registry-1.docker.io/bitnamicharts\"\n  - name: bar   # This is a subchart packaged with \"foo\" in charts dir. It's not pulled from a remote location\n    version: \"0.1.0\"\n    depends-on: [\"nginx\", \"rabbitmq\"]\n    condition: bar.enabled\n```\n\n```\n [nginx] [rabbitmq]\n    ||       ||\n    ||       ||\n    \\/       \\/\n     \\\\     //\n      \\/   \\/\n       [bar]\n        ||\n        ||\n        \\/\n       [foo]\n```\n\nIn 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.\n\nThis 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.\n\n### Readiness\n\nTo 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.\n\nChart authors can optionally override this behavior using the following annotations:\n\n* `helm.sh/readiness-success`: A list of custom success conditions. If any are true, the resource is marked **ready**.\n* `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.\n\nBoth `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.\n\n#### JsonPath syntax\n\nThe `readiness-success` and `readiness-failure` annotations accept lists of expressions with the format:\n\n```\n{<jsonpath_query>} <logical_operator> <value>\n```\n\nWhere:\n\n* `<jsonpath_query>` is a [Kubernetes JSONPath](https://kubernetes.io/docs/reference/kubectl/jsonpath/) query scoped to `.status`.\n* `<logical_operator>` supports: `==`, `!=`, `<`, `<=`, `>`, `>=`.\n* `<value>` is the expected literal for comparison. The value should be a scalor (string, number, boolean). Object comparisons will not be supported.\n\n##### Example\n\n```yaml\nkind: Job\nmetadata:\n  name: db-init\n  annotations:\n    helm.sh/readiness-success: [\"{.succeeded} == 1\", \"{.succeeded} == 2\"]\n    helm.sh/readiness-failure: [\"{.failed} >= 1\"]\nstatus:\n  succeeded: 1\n```\n\nIn 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.\n\nA resources readiness is checked if there is a resource that depends on it as per the sequencing DAG, otherwise the checks are ignored.\n\nHelm 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.\n\n### Sequencing order\n\nResources 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.\n\n- 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.\n- 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.\n- 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.\n- `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: <chart>/<subchart> <group-name>` comment indicating the beginning of each resource-group and `END resource-group: <chart>/<subchart> <group-name>`.\n\n```yaml\n## START resource-group: foo group1\n# resource 1\nmetadata:\n  name: foo\n  annotations:\n    helm.sh/resource-group: group1\n---\n# resource 2\nmetadata:\n  name: bar\n  annotations:\n    helm.sh/resource-group: group1\n## END resource-group: foo group1\n---\n## START resource-group: foo/bar group2\n# resource 3\nmetadata:\n  name: fizz\n  annotations:\n    helm.sh/resource-group: group2\n    helm.sh/depends-on/resource-groups: [\"group1\"]\n## END resource-group: foo/bar group2\n```\n\n## Backwards compatibility\n\nHelm will continue to install/upgrade/uninstall/rollback all resources and dependencies at one go for all charts using `Charts v2` and below.\n\n## Security implications\n\nNone.\n\n## How to teach this\n\n- 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.\n- Document how this feature works for SDK users.\n\n## Reference implementation\n\nN/A\n\n## Rejected ideas\n\n1. A weight based system, similar to Helm hooks\n    - Static numbering of the order is more challenging to develop and maintain\n    - Modifying the order can lead to cascading changes.\n    - Dynamically named system solves these problems for the application distributors.\n\n## Open issues\n\n## Prior raised issues\n\n- https://github.com/helm/helm/pull/12541\n- https://github.com/helm/helm/pull/9534\n- https://github.com/helm/helm/issues/8439\n- https://github.com/helm/community/pull/230\n"
  },
  {
    "path": "community/hips/hip-0026.md",
    "content": "---\ntitle: \"H4HIP: Wasm plugin system\"\nsidebar_label: \"0026: H4HIP: Wasm plugin system\"\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/hips/hip-0026.md\n-->\n\n| **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | **Helm Version** |\n|---|---|---|---|---|---|---|\n| 0026 | H4HIP: Wasm plugin system | Scott Rigby <scott@r6by.com>, George Jenkins <gvjenkins@gmail.com> | 2025-02-17 | feature | draft | 4 |\n\n\n## Abstract\n\nHelm 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.\n\nThis 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.\n\nThis 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.\n\n## Scope\n\nThis 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.\n\nThis HIP focuses primarily on CLI users.\nSDK 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.\nAdditionally, 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.\n\n## Motivation\n\nHelm 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.\n\nHelm 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.\n\n### Helm 3 plugins did not adequately address the problem this HIP solves\n\nHelm 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.\n\nThe [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:\n> 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)\n\nHowever, Helm 3 plugins had the following limitations:\n\n- 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.\n- 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.\n- 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.\n\n### Other Helm 3 customization options did not adequately address the problem this HIP solves either\n\nApart from plugins, Helm 3 attempts to allow user customization globally and per command:\n\n- 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).\n- 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.\n\nWhile 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.\n\n## Specification\n\nThis section outlines the Wasm based plugin system, and the plan to define a wider range of plugin types.\n\n### Terminology\n\n- #### Plugin System\n    The *entire* Helm 4 plugin architecture.\n- #### ApiVersion\n    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.\n- #### Plugin Type\n    Which Helm functionality the plugin can extend. Examples: `subcommand`, `downloader`, `postrender`\n- #### Plugins\n    The individual, optionally intallable, plugins themselves\n\n### Directory Structure and Go Packages\n\n```text\npkg\n└── plugin\n    ├── internal\n    │   ├── legacy\n    │   └── v1\n    └── *.go\n```\n\n### Plugin System specification\n\nThe [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.\n\n* `v1`: The new Wasm Plugin System\n* `legacy`: Legacy support for Helm 3 subprocess plugins; no new fields expected (deprecated in Helm 4, to be removed in Helm 5)\n* `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.\n\n### Plugin Types specification\n\nThese 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.\n\nInitial 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:\n\n- **Download**\n\n    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).\n- **Postrender**\n\n    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.\n- **CLI**\n\n    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.\n\n### Plugin specification\n\n`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.\n\n```yaml\napiVersion: v1\nname: my-custom-postrender-plugin\nversion: 0.1.0\ntype: postrender.plugins.helm.sh/v1\nsourceURL: https://github.com/example/my-plugin\nconfig: {}\n```\n\nNew fields:\n- `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.\n- `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`.\n- `sourceURL`: added to encourage best security practices. See [Security implications](#security-implications).\n- `config`: Per-plugin configuration allowable by it's [Plugin Type](#plugin-type) definition.\n\n### Helm plugin commands specification\n\n- `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:\n\n    ```console\n    NAME        VERSION     TYPE            SIGNED      SOURCE_URL\n    s3          1.2.3       download        862HB19B    https://gitlab.com/someone/s3-helm-plugin\n    kustomize   4.0.0       post-render     208DD36E    https://github.com/helm/helm\n    my-nodejs   0.1.0       post-render     N/A         N/A\n    ```\n- `helm plugin install` installs a plugin from a URL (see Distribution specification below)\n- `helm plugin update` will check for updates, then follow the same behavior of `plugin install`\n- `helm plugin sign` will use Helm 4's built-in provenance signing mechanisms as a convenience to sign a plugin\n- `helm plugin verify` will use Helm 4's built-in provenance mechanisms as a conveniencce to verify a signed plugin\n\n### Distribution specification\n\nHelm will need to install/download plugins Wasm binaries. When users run `helm plugin install`, and other future methods.\n\nHelm will initially support installing plugins from http URLs, from version control systems, and the local filesystem, just as in Helm 3.\n\nThe 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.\n\nEventually, it is recommended that Helm supports plugin distribution via OCI artifacts. And further distribtion schemes e.g. S3 could be supported via plugins themselves.\n\n#### Plugin distribution format\n\nA plugin comprises of the following filesystem structure (or a tar archive of):\n\n```\n.\n├── [LICENSE]        # Optional: plugin licence\n├── NAME.wasm        # Wasm binary\n└── plugin.yaml      # Plugin manifest\n```\n\n### Provenance specification\n\nHelm 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:\n\n- Installing from the local filesystem (for local development)\n- When the user provides an `--allow-insecure-plugins` flag (see [Security implications](#security-implications))\n\nHelm 4 will support the same provenance functionality for Plugins as Helm 3 supports for charts. See <https://helm.sh/docs/topics/provenance/>. 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).\n\n## Rationale\n\nThe following apply to the Plugin API v1 (see `apiVersion` under [Plugin specification](#plugin-specification)):\n\n### Technical reasoning for Wasm plugins\n\nFor 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\n\n```mermaid\nsequenceDiagram\n    participant h as Helm (Go) + Wasm runtime\n    participant P as Plugin (Go, Rust, etc as .wasm)\n    h->>P: Call exported function\n    P->> h: Call imported function\n```\n\nFor 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:\n\n1. Native WASI P1 (POSIX/C-life FFI)\n[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.\n2. Message serialization/RPC (GRPC/protobuf, JSON, etc)\nRather 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.\n\n### Technical reasoning using Extism for Wasm plugins\n\nFor Wasm Plugin Interfacing, Helm 4 will be leveraging the Extism project. See <https://extism.org/> and specifically the Extism [Go SDK](https://github.com/extism/go-sdk) and [Go PDK](https://github.com/extism/go-pdk).\n\nExtism 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.\n\nBy 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).\n\n## Backwards compatibility\n\nRequirements for the new plugin system and the initial default plugins:\n\n- Helm 4 MUST continue to be as easy to install as Helm 3\n- 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\n- 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.\n- The new plugin system MUST NOT prevent SDK users from using the default functionality\n- A security plan approved by Helm's security team MUST be adopted for developing and releasing this new architecture model\n\n## Security implications\n\n### Summary\n\nThe 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. \n\nAdditional steps are also taken to improve security:\n- Tools are added for signing and verifying plugins\n- 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\n- Helm will automaitcally attempt to verify the provenance signature of a plugin by default when it is first installed\n- [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\n\n### Details\n\nIn 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.\n\nIn Helm 4, users may still manually install plugins.\n\nHelm 4 will address this in the following ways:\n\n- Adds provenance signing and verifying options for plugins:\n\n    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).\n    \n- Security best practices encouraged and surfaced to end users:\n    \n    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.\n\n    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.\n    \n    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.\n\n    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.\n\n## Implementation Plan\n\nWork for the plugin system will follow the [H4HIP: Helm 4 Development Process](/community/hips/hip-0012) timelines.\n\n1. Marking this HIP as accepted (including security plan in this HIP approved by Helm's security team)\n1. May. 2025: Engineering on this feature begins\n1. Aug. 2025: Have inital work on all features included in the initial implementation, adhering to Feature freeze for Helm 4 release preparation\n1. Nov. 2025: Initial offering feature complete by Helm v4.0.0 release\n1. Post-release: Follow up HIPs for additional plugin types and features will match future Helm 4 Minor version release schedule\n\n### Initial release of the new plugin system\n\n- [ ] Create initial version of new plugin package to load Wasm Extism plugins\n- [ ] Create message schemas for new plugins types:\n    - [ ] `download.plugins.helm.sh/v1`\n    - [ ] `postrender.plugins.helm.sh/v1`\n    - [ ] `cli.plugins.helm.sh/v1`\n- [ ] Write host functions to invoke these initial defined Wasm plugin types\n\n### Roadmap items that may be added in further HIPs\n\n- Additional plugin types for moving other Helm functionality to the plugin system\n- Allow plugins to be stored as OCI artifacts (in addition to HTTP, VCS, and local filesystem)\n    - add Helm CLI command for plugins similar to `helm push`\n- Add new Helm plugin types to ArtifactHub.io\n    - Move current Helm plugin kind to legacy and add a new Helm plugin artifact kind.\n      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.\n\n## How to teach this\n\n- Create examples of each Plugin Type for the new plugin system that contributors can use as a model for their own plugins\n    - `download`: OCI, HTTP/S\n    - `postrender`: No default. We should write a very simple example to prove that the host function works\n    - `cli`: No default. Similarly we should write a simple example proving the host function works\n- Write concise and easy to follow documentation for the new plugin system\n- Write a blog post outlining how the community will benefit from the new plugin system, which can link to the documentation and these examples\n- Create a presentation to propose for conference talks as another communition channel to make the community aware of the new plugin system\n- 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)\n\n## Reference implementation\n\nTwo example Wasm plugins leveraging Extism have been prototyped. The first is an example downloader plugin, and the second is an example renderer plugin:\n- https://github.com/gjenkins8/helm-plugin-ocigetter\n- https://github.com/gjenkins8/helm-plugin-gotemplate-renderer/\n\nThe 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)).\n\n## Rejected ideas\n\n1. Using a subprocess plugin model. (The legacy Helm 3 subprocess system will be deprecated in Helm 4, and removed in Helm 5).\n\n    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.\n\n    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).\n\n1. Helm 4 will not create a central repository for plugins.\n\n    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).\n\n1. Helm 4 have ruled out the following technologies for plugin interfacing in Helm 4:\n    - [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)\n\n        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.\n\n        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.\n\n    - [Wazero](https://github.com/tetratelabs/wazero) directly\n    \n        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.\n\n    - [Wadge](https://wasmcloud.com/docs/developer/languages/go/components#wadge) in wasmCloud\n    \n        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.\n\n    - [Web Assembly for Proxies (Go SDK)](https://github.com/proxy-wasm/proxy-wasm-go-sdk)\n    \n        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.\n\n    - [Go native plugin system](https://pkg.go.dev/plugin)\n    \n        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.\n\n    - [Embedded go interpreter (yaegi)](https://github.com/traefik/yaegi)\n\n        Problem: Yaegi does not have full sandboxing like Wasm. See <https://github.com/traefik/yaegi/discussions/1463>\n\n        Note: Traefik uses this, so it seemed notable enough to mention.\n\n## Open issues\n\n1. 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?\n\n## References\n\nPrecedents:\n\nHelm [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.\n\nLater 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).\n"
  },
  {
    "path": "community/history.mdx",
    "content": "---\ntitle: The History of the Project\ndescription: Provides a high-level overview of the project's history.\nsidebar_position: 5\n---\n\nHelm is a [graduated](https://helm.sh/blog/celebrating-helms-cncf-graduation/)\n[CNCF project](https://www.cncf.io/projects/).\n\nHelm began as what is now known as [Helm\nClassic](https://github.com/helm/helm-classic), a Deis project begun in 2015 and\nintroduced at the inaugural KubeCon.\n\nIn January of 2016, the project merged with a GCS tool called Kubernetes\nDeployment Manager, and the project was moved under\n[Kubernetes](https://kubernetes.io). As a result of the merging of codebases,\nHelm 2.0 was released later that year. The key feature of Deployment Manager\nthat survived in Helm 2 was the server-side component, renamed from DM to Tiller\nfor the final Helm 2.0 release.\n\nHelm was promoted from a Kubernetes subproject to a full-fledged CNCF project in\nJune, 2018. Helm formed a top-level governing body and several projects were\nsubsumed under the Helm project, including Monocular, the Helm Chart Repo, Chart\nMuseum, and later the Helm Hub.\n\nWhen the Helm 3 development cycle began, Tiller was removed, bringing Helm\ncloser to its original vision of being a client tool. Helm 3 was released in\nNovember 2019.\n\nHelm [graduated as a CNCF project in April 2020](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/).\n\nThe CNCF [Artifact Hub](https://artifacthub.io) replaced the [Helm Hub](https://hub.helm.sh)\nin October 2020.\n\nIn 2025, the Helm project [celebrated its 10th anniversary](https://helm.sh/blog/helm-turns-ten/).\n\n[Helm v4.0.0](https://github.com/helm/helm/releases/tag/v4.0.0) was\n[released](https://helm.sh/blog/helm-4-released/) on November 12, 2025 at\nKubeCon + CloudNativeCon North America — the first new major version in six\nyears. The release was driven by the need for architectural changes that could\nnot be made without breaking the public SDK API.  Key additions include a\nredesigned plugin system with WebAssembly support, Server-Side Apply,\nkstatus-based resource watching, content-based caching, reproducible chart\nbuilds, and an updated SDK API with support for multiple chart API versions. \nExisting charts remained backwards compatible. See the\n[Helm 4 Overview](/docs/overview) for more details."
  },
  {
    "path": "community/incubator.md",
    "content": "---\ntitle: Kubernetes Helm Incubator Process\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/incubator.md\n-->\n\n**Authors:** Brandon Philips <brandon.philips@coreos.com>, Sarah Novotny <sarahnovotny@google.com>, Brian Grant <briangrant@google.com>\n\n## Kubernetes Helm Incubator\n\nThe [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.\n\n### Context\n\nNew 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).\n\n### Status\n\nThis 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.\n\n## Does my project need to Incubate?\n\n### Applications on top of Kubernetes Helm\n\nIf 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.\n\n## Entering Incubation\n\nTo 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.\n\nYour 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.\n\nOnce 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.\n\nThe 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.\n\nThe 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.\n\nAcceptance 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.\n\n## Creation of the Incubator Project\n\nOnce 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:\n\n- a README from the accepted proposal\n- an OWNERS from the accepted proposal\n- a CONTRIBUTING file based on kubernetes/kubernetes\n- a code-of-conduct.md based on kubernetes/code-of-conduct.md\n- a LICENSE file with the Apache 2.0 license\n- a RELEASE.md file that talks about the process for releases\n\nA template project to start your project with these files can be found here: https://github.com/kubernetes/kubernetes-template-project\n\n## Exiting Incubation\n\nAn Incubator Project must exit 12 months from the date of acceptance in one of these three ways:\n\n- Graduate as a new Kubernetes Project\n- Merge with another Kubernetes Project\n- Retirement\n\n### Graduation\n\nBoth 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:\n\n- **Documented users:** the project tracks evidence from downloads, mailing lists, Twitter, blogs, GitHub issues, etc that the project has gained a user base\n- **Regular releases:** the project is making releases at least once every 3 months; although release should happen more often\n- **Incubation time:** a minimum of 6 months has passed since\n- **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.\n- **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\n\nWhen 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.\n\nAn announcement of graduation must be sent to the kubernetes-dev@googlegroups.com mailing list by the Champion.\n\n### Merge\n\nAt 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:\n\n1. Incubator Project OWNERS notifying the project Champion and Sponsor\n2. Once the Champion and Sponsor have been informed then email kubernetes-dev@googlegroups.com about the intention to exit through a merge\n\n### Retirement\n\nIf 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.\n\n## FAQ\n\n**Q: What is the role of a Champion?**\n\n**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.\n\n**Q: What is the role of the Sponsor?**\n\n**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.\n\n## Existing Repos\n\nBased 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.\n\n**Projects to Move to Incubator**\n\n- github.com/helm/monocular\n- github.com/helm/rudder-appcontroller\n\n## Thank You\n\nLarge portions of this process and prose are inspired by the Apache Incubator process.\n\n## Original Discussion\nhttps://groups.google.com/d/msg/kubernetes-dev/o6E1u-orDK8/SAqal_CeCgAJ\n\n## Future Work\n\n- Expanding potential sources of champions outside of Kubernetes main repo"
  },
  {
    "path": "community/localization.md",
    "content": "---\ntitle: \"Localizing Helm Documentation\"\ndescription: \"Instructions for localizing the Helm documentation.\"\naliases: [\"/docs/localization/\"]\nsidebar_position: 6\n---\n\nThis guide explains how to localize the Helm documentation.\n\n## Getting Started\n\nContributions for translations use the same process as contributions for\ndocumentation. Translations are supplied through [pull\nrequests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)\nto the [helm-www](https://github.com/helm/helm-www) git repository and pull\nrequests are reviewed by the team that manages the website.\n\n### Two-letter Language Code\n\nDocumentation is organized by the [ISO 639-1\nstandard](https://www.loc.gov/standards/iso639-2/php/code_list.php) for the\nlanguage codes. For example, the two-letter code for Korean is `ko`.\n\nIn content and configuration you will find the language code in use. Here are 3\nexamples:\n\n- In the `i18n` directory, there are subdirectories for each language code. The\n  localized content for the language is in each subdirectory.\n- Localized content in each \n- For each language, there is a `code.json` file for each language with\n  phrases used on the website.   \n\nEnglish, with a language code of `en`, is the default language and source for\ntranslations.\n\n### Fork, Branch, Change, Pull Request\n\nTo contribute translations start by [creating a\nfork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo)\nof the [helm-www repository](https://github.com/helm/helm-www) on GitHub. You\nwill start by committing the changes to your fork.\n\nBy default your fork will be set to work on the default branch known as `main`.\nPlease use branches to develop your changes and create pull requests. If you are\nunfamiliar with branches you can [read about them in the GitHub\ndocumentation](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches).\n\nOnce you have a branch make changes to add translations and localize the content\nto a language.\n\nNote, Helm uses a [Developers Certificate of\nOrigin](https://developercertificate.org/). All commits need to have signoff.\nWhen making a commit you can use the `-s` or `--signoff` flag to use your Git\nconfigured name and email address to signoff on the commit. More details are\navailable in the\n[CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work)\nfile.\n\nWhen you are ready, create a [pull\nrequest](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)\nwith the translation back to the helm-www repository.\n\nOnce a pull request has been created one of the maintainers will review it.\nDetails on that process are in the\n[CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md)\nfile.\n\n## Translating Content\n\nLocalizing all of the Helm content is a large task. It is ok to start small. The\ntranslations can be expanded over time.\n\nThe following describes the files/directories that are used to translate the docs content, blog content, and site elements in the Helm documentation site:\n\n- `i18n/<language-code>` directory:\n  - `code.json` used for translating React code in the site (including the landing page)\n  - `i18n/<language-code>/docusaurus-plugin-content-blog` subdirectory with blog translations\n  - `i18n/<language-code>/docusaurus-plugin-content-docs` subdirectory with:\n     - Version subdirectories for docs content translations (eg `i18n/<language-code>/docusaurus-plugin-content-docs/version-3/`)\n     - JSON files for each version of the docs with translations for the categories in the sidebar (eg, `current.json`, `version-3.json`, etc)\n  - `i18n/docusaurus-theme-classic` subdirectory with `footer.json` and `navbar.json` files for translating the visible text in the site navbar and footer\n- 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\n\nFor more information, see [i18n - Introduction](https://docusaurus.io/docs/i18n/introduction) in the Docusaurus docs.\n\n### Starting A New Language\n\nFor a tutorial that walks you through how to translate site content, see [i18n - Tutorial](https://docusaurus.io/docs/i18n/tutorial) in the Docusaurus docs.\n\nTo start a new language:\n\n1. If you haven't already, install dependencies:\n\n   ```\n   yarn install --frozen-lockfile\n   ```\n\n1. 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.\n\n    ```\n    yarn write-translations --locale <language-code>\n    ```\n\n1. Do the minimum translations for the new language:\n   1. Translate the `code.json` file.\n   1. In the `i18n/docusaurus-theme-classic` subdirectory, translate the `footer.json` and `navbar.json` files.\n   1. In the `docusaurus-plugin-content-blog/options.json`, translate the blog elements in the `options.json` file.\n1. Add the language to the `i18n` key of the `docusaurus.config.js` file so that it appears in the dropdown in the navbar:\n    ```yaml\n    i18n: {\n      defaultLocale: 'en',\n      # add new language to this list of locales\n      locales: ['en', 'de', 'es', 'fr', 'gr', 'ja', 'ko', 'pt', 'ru', 'uk', 'zh'],\n      localeConfigs: {\n        en: {\n          htmlLang: 'en-us',\n          label: 'English',\n        },\n        de: {\n          label: 'Deutsch',\n        },\n      # new_lang {\n      #   label: 'Navbar label',\n      # }\n      },\n    },\n    ```\n1. (Optional) Translate docs or blog content. See _Translating_ below.\n1. Test your changes by starting the localized site in dev mode, specifying the locale:\n\n   ```\n   yarn start --locale fr\n   ```\n   :::note\n   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.\n   :::\n\n### Translating\n\nBefore you translate docs content, review the following best practices and guidelines:\n* Translation tools can help with the process. This includes machine\ngenerated translations. Machine generated translations should be edited or\notherwise reviewing for grammar and meaning by a native language speaker before\npublishing.\n* Do not add an untranslated copy of an English file to `i18n/[LANG]/plugin-content-docs` or `i18n/[LANG]/plugin-content-blog`.\nOnce a language exists on the site, any untranslated pages will redirect to\nEnglish automatically. Translation takes time, and you always want to be\ntranslating the most current version of the docs, not an outdated fork.\n* Make sure you remove any `aliases` lines from the header section. A line like\n`aliases: [\"/docs/using_helm/\"]` does not belong in the translations. Those\nare redirections for old links which don't exist for new pages.\n* 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`.\n\nTo translate docs and blog content:\n1. Make sure that target locale exists in the `i18n` directory. If it doesn't, see _Starting a New Language_ above.\n1. Copy one or more markdown files that you want to translate from `/docs` or `/versioned_docs` to the appropriate version folder in `i18n/<language-code>/docusaurus-plugin-content-docs`.\n     For example, to translate `versioned_docs/version-3/example.md` into Korean:\n     ```sh\n     cp versioned_docs/version-3/topics/example.md i18n/ko/docusaurus-plugin-content-docs/version-3/topics/example.md\n     ```\n1. Copy one or more markdown files that you want to translate from `/blog` to `i18n/<language-code>/docusaurus-plugin-content-blog`.\n    For example, to translate `blog/2025-09-09-path-to-helm-v4.md` into Korean:\n     ```sh\n     cp blog/2025-09-09-path-to-helm-v4.md i18n/ko/docusaurus-plugin-content-blog/2025-09-09-path-to-helm-v4.md\n     ```\n1. If you haven't already, install dependencies:\n\n   ```\n   yarn install --frozen-lockfile\n   ```\n\n1. Test your changes by starting the localized site in dev mode, specifying the locale:\n\n   ```\n   yarn start --locale ko\n   ```\n   :::note\n   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.\n   :::\n\n## Navigating Between Languages\n\nUsers navigate between languages in the locale dropdown in the site navbar.\nThe `i18n` key in the site global `docusaurus.config.js` file is where language navigation is configured.\nTo add a new language, add the locale using the [two-letter\nlanguage code](./localization/#two-letter-language-code) defined above. Example:\n\n```yaml\ni18n: {\n  defaultLocale: 'en',\n  # add new language to this list of locales\n  locales: ['en', 'de', 'es', 'fr', 'gr', 'ja', 'ko', 'pt', 'ru', 'uk', 'zh'],\n  localeConfigs: {\n    en: {\n        htmlLang: 'en-us',\n        label: 'English',\n    },\n    de: {\n        label: 'Deutsch',\n    },\n    # new_lang {\n    #   label: 'Navbar label',\n    # }\n  },\n},\n```"
  },
  {
    "path": "community/meeting-notes/2017.md",
    "content": "---\ntitle: Helm Minutes for 2017\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/meeting-notes/2017.txt\n-->\n\n```txt\nDecember 14, 2017\nAnnouncements\nHelm Summit CFP is open (are we extending deadline?)\nHelm 2.8 soon after Kubernetes 1.9 is released\nStandup:\nJustin:\nIssue triaging\nMichelle: KubeCon SIG-Apps meeting\nDeployments with injected values about the environment\nHelm summit planning and mailing list setup\nSteve:\nLot of discussions a KubeCon\nInternal discussions about Helm and security, maybe some afterward discussions\nLooking over issue list\nMatt Farina\nHelm Status YAML/JSON output done\nHow to pass in custom user agents? (For CI)\nOWNERS files for k/charts; instituting this as policy this week\nAll k8s org projects will now have stale issue closer\nCircleCI fixed\nMatt Butcher\nKubeCon updates about SK, Alibaba, etc.\nSuggest skipping meetings for rest of year\nMatt Fisher\nAlibaba: Using a forked Kubernetes with Helm\nSIG-Apps Update and Deep Dive meetings: Good discussions on Helm dev summit, esp. On whether we should use CRDs\nLooking at Adam’s PR for 1.9 support\nTaylor\nFocusing on Helm summit\nLots of sponsorship asks\nTriaging CFPs with Fisher, Adam, Michelle on Dec. 15\nSome PR triaging\nSome ideas about CRDs that might prototype\nAdam\nPR for k8s 1.9\nHeads up on remodeling of Kubernetes types\n[Fisher volunteered to pair]\nDiscussion items\nHelm Summit [Michelle]\nPlease submit CFPs https://helmsummitpdx-feb2018.splashthat.com/\nContact Taylor for CFP review\nWhen do we want the CFP deadline?\nFollow-up in the CFP discussion tomorrow\nHelm security mailing list and email [Michelle]\nCurrent: helm-security@deis.com\nWhat do we want the new address to be? Security mailing list?\nGoogle groups or mailman\nFisher: Mailman usage is common in open source communities\nKubeCon update\nKubernetes upgrades for 1.9, and how this breaks/changes Helm\n\nNovember 30, 2017\nAnnouncements\nHelm Summit venue is locked in: The Evergreen in Portland, OR.\n21-22 February 2017\nThere’s space enough for 200 people or less. It’s “super cute.”\nNike is co-sponsoring with Microsoft. There or may not be Nike swag available.\nStandup:\nTaylor\nWorking through backlog of PRs.\nCoordinating Nike side of sponsoring the summit.\nReviewing Michelle’s Tiller plugin.\nAdam\nKubeCon preparation.\nStarting in on working on Kubernetes 1.9-related changes.\nBrian\n\n\nSteven\nDiscussing Tiller security with internal teams considering using Helm.\nMichelle\nWorking 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.\nWorking on securing the venue for the Helm summit.\nMatt Fisher\nTriaging issues, including a few related to security.\ngRPC upgrade\nShould we wait until after KubeCon to release?\nHelm version 2.8 would bring parity with Kubernetes version 1.9.\nMatt Farina\nWorking on slides for presentation at KubeCon.\nSprig library interface oddities needed accommodation, for a pending release.\nMatt Butcher\nCleared out PRs in the queue on Thanksgiving.\nPublished the secure Tiller/TLS configuration blog post.\nThere are coming changes to the Helm documentation site.\nKubeCon and the Helm Team\nMichelle is planning meetings, and wants to know who wants to participate.\nLots of people new to Helm will be there. Keep that in mind when pitching Helm.\nMichelle is working on a “cheat sheet” to help explain what’s changing in Helm to keep pace with Kubernetes evolution.\nWe’d like to find people who are not maintainers to speak on their use of Helm.\nBe on the lookout for experience reports, and encourage people to attend the Helm summit a couple of months later.\nDiscussion\nStepping 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.\nThere 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.\nBe professional, level-headed, and set a good example. Confrontation isn’t helpful. Matt Farina is willing to intervene and mediate.\n\nAction Items:\nShare documentation that addresses these concerns.\n\nNovember 16, 2017\nAnnouncements\nHelm v2.7.2\nStandup:\nTaylor\nIssue sherpa’ing\nBug reported with tiller memory leaks\nWorking with michelle on the helm dev summit\nAdam\nReleased v2.7.1\nBrian\nTriage the TLS issue that was released in v2.7.2\nSteven\nAsked to place a discussion around pluggable tiller authentication backends\nMichelle\nWorking on the helm dev summit side as usual\nBeen going through the UX for setting up RBAC\nMatt Fisher\nTriaged issues for v2.7.1\nPeer reviewed the patch for v2.7.2\nMatt Farina\nStarting on work for helm status output as JSON\nDiscussion\nPluggable auth backends for tiller\nIBM wants to integrate their authentication/authorization backend to front tiller\nSome arch discussion around blocking direct access to tiller only to the authentication gateway\nIBM would like to open a ticket to discuss this proposal\nv2.7.3?\nThe patch looks good, but there are concerns around the grpc-go PR being backwards-incomaptible between Helm patch releases\nNovember 9, 2017\nAnnouncements\nNone for today\nStandup:\nTaylor\nLooking at what items need to make it to the next Helm release\nReviewed the \"symlink-walk\" piece that we needed to remove because it was part of the facebook-go dependencies. Looking pretty good.\nMatt Farina:\nMoving charts to a model where owners will be able to make PRs themselves.\nStill a little ways out to finalize this, since we need to move to Prow before this can happen\nJustin:\nWas Sherpa Tsar\nMerged an example for overrides\nNikhil:\nWorking on new chart for Portus Registry\nWill run it by folks once it's complete to get some feedback\nDiscussion Topics\nTurning on RBAC by default (kensey - Issue 3098 in GitHub)\nChart PR that was reviewed - reformat chart using RBAC (enable/disable + service account)\nMost of the other kubernetes teams have moved to use RBAC by default\nIdeally make a decision on this by next dev-meeting\nHelm Summit (Taylor)\nCurrent dates were oo close to KubeCon, so makes sense to reschedule\nMoved out to Feb 6th and 7th\nCFP deadline to moved out to a week after KubeCon\nThe venue is still being finalized, should be safe to book travel once venue is finalized\nAssignments for next week\nIssue Sherrif - Taylor\nNotes - Justin\nMeeting Lead - <TBD>\nNovember 2, 2017\nAnnouncements\nMicrosoft folks will be away all next week\nIf you are a core maintainer and not already on the kubernetes-helm-core google group, please request access here\nHelm Summit CFP is open. Submit a CFP to speak at the summit here\nIf you’re interested in helping with the schedule and sort CFP submissions, please contact Taylor Thomas\nPlans to release a v2.7.1 sometime in the near future\nStandups\nMatt Farina\nGot a few PRs merged on bringing out the app version and maintainer URL to Chart.yaml\nRaised a question about charts should be mutable or not; kubernetes/charts are currently mutable\nMatt Butcher\nGot ChartMuseum into helm’s incubator with Matt Farina\nChatted with Farina about helm templating ideas\nPlans this week are to continue with helm comunity stuff\nMichelle\nReached out to Sarah (Kubernetes) and Dan (CNCF) to advise on where we should post community meeting recordings\nFisher\nIssue queue triaging\nWorking on documentation\nNeed alias for security leaks\nTaylor\nIssue sherpa this week\nIssue 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\nFinalizing some venue stuff for the dev summit, looks like it’s going to be in downtown portland\nAdam\nWorked on trying to tamper down the PR queue along with Fisher\nFocusing on helping out Michelle on the helm dev summit\nMichelle\nTalking to lots of users last week on Helm\nPosted the presentation on helm from last week so others can learn\nHelm summit is on her list of TODOs: CFPs, venues, schedule etc.\nReached out to Sarah and Dan(?) on how we want to upload the helm dev summit videos\nJustin\nJumped into the context deadline exceeded issue\nFisher has commented on that issue to *hopefully* move the conversation/troubleshooting forward\nSteven\nHelping 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\nFound 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\nDiscussion topics\nWhat other mailing lists do we need other than Kubernetes-helm-core for core team communications?\nNeed alias for security leaks\nJustin: should we pre-seed discussion about what is on the table for breaking changes in Helm 3?\nWe 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.\nShould we discuss about the helm summit at KubeCon?\nYes\nAssignments for next week\nIssue Majaraja: Justin\nMeeeting notes: Steven\nMeeting lead: Taylor\n\nOctober 26th, 2017\nAnnouncements\nHelm v2.7.0 was released this Monday\nHelm v2.8.0 is planned to go out after Kubernetes 1.9 in December as agreed upon last meeting\nStandups\nAdam Reese\nReleased Helm v2.7\nBrigade launch has been taking up most of his time this week\nMatt Fisher\nAlso assisted with Helm v2.7 release\nSteven Harris\nConcerns around confusion with values.yaml -- there are a lot of different ways to configure values. --reuse-values, --set, changing values.yaml, `helm inspect values`\nTaylor Thomas\nJumping back this week\nWorking on the helm summit, hopefully more progress next week\nNeeds some more help on reviewing CFPs for the summit: Fisher and Reese raised hands\nMatt Farina\nHas 2 PRs in helm related to charts\nAdam said that he will get to reviewing them this week\nDiscussion topics\nFisher wants to propose a talk about how to propose and document new features in helm at the dev summit in Jan\nOne concern around Helm 3: chart compatibility. We should strive to be compatible with Helm 2 charts now that there are a lot of them\nSteven brought up the discussion from this week’s SIG-Apps meeting from Brian Grant\nFisher 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)\nAssignments for next week\nIssue sherpa: taylor\nMeeting notes: fisher\nMeeting lead: steven\nOctober 19th, 2017\nAnnouncements\nHelm Summit Interest Survey is out: https://goo.gl/forms/UBTTS7JaoZpSzoar1\nCut the release for 2.7.0-rc1 - Thanks Fisher, Adam and Taylor\nStandups\nMatt Fisher\nHelped out with the release\nTag was not being built on CircleCI, had to use API directly to cut the tag\nSame issue happening on Draft so it might be something related\nCurrently 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\nPlanning on doing the release notes and documenting how to do that\nLooking for any issues on the rc1 release but haven’t found any\nIf all looks well, we could release by next week\nMichelle Noorali\nIssue Maharani this week\nCreated a google group for the Helm core team\nSent out Helm Summit Survey to gauge people’s interest in attending\nLink: https://goo.gl/forms/UBTTS7JaoZpSzoar1\n44 responses so far\nSending out CFP form today for the Helm Dev Summit\nWill create a google group for the Helm community at large\nVenue is looking to have a max capacity of 200 at this time, looking at other options\nReach out to michelle if interested in setting schedule stuff for the summit\nDate might be changing to Jan 16th/17th\nAdam Reese\nIssue grooming, PR reviews\nHelped released 2.7-rc1\nJustin Scott\nThis week want to participate more in helm\nInterested in telepresence. Pretty cool, didn’t work\nTaylor\nMore helm dev summit organizing\nMatt Farina\nWorking with the charts team for loosening CI linter rules\nMatt Butcher\nTaylor had some impromptu helm things going\nAll the Helmettes went to the KubeCon after party together, from core maintainers to new users\nMet with SK Telecom using Helm to deploy all their Openstack mega clusters\nLots of discussions around what people like and don’t like about Helm\nOut on vacation next week\nBitnami announced their new Kubeapps product\nDiscussion topics\nKubernetes 1.9 planning\nWednesday December 13th\nThe rc1 is set for 12/6\nLook at releasing helm 2.8 at the end of the year\nKeep in mind KubeCon is Dec. 6-8\nHelm 2.7.0 release date\nLooking at Monday or Tuesday of next week if no issues arise before then\nVenue options and preferences\nFisher said that he’s interested in seeing the Nike campus :3\nAssignments for next week\nIssue sherpa: Taylor\nMeeting Notes: Matt Fisher\nMeeting Leader:\n\nOctober 12th, 2017\nAnnouncements\nStandups\nAdam\nK8s 1.8 support\nWorking with Matt Farina on some PRs, will be following up this week\nMatt Fisher\nSteven\nUsing helm around different environment-based values\nLooking into/reading about the CronJob issue\nMatt Butcher\nHad a meeting with App Registry and ChartMuseum\nFollowing up with ChartMuseum dev wants to put it into helm incubator\nOutcome of the meetings was there was strong ChartMuseum as the backend and Monocular as the front-end for a chart repository experience\nLaunching new OSS so being busy for the next 2 weeks or so\nJustin Scott\nPlaying around with telepresence (sorry Fisher) :P\nTaylor\nIssue sherpa this week\nTrying to lasso issues into the 2.7 release, continuing to assist in the RC\nNick\nGot helm/tiller merged into SUSE’s CaaS platform\nMatt Farina\nSubmitted a preemptive bug fix\nUpdates on the charts repo: They are linting and running various static tests with Circle to automate all the things\nDiscussion\nSecrets backend\nDocs\nConversion from ConfigMaps to Secrets\nDecision is to go ahead and merge and add documentation outside of PR\n2.7 Release\nAdam in charge of cutting release\nK8s support again….We need to support 1.7 and 1.8, which means supporting 2 API versions for this release\nThis PR should probably be pulled off of 2.7 and fixed upstream\nRC release date: Monday, Oct. 16th\nHelm Summit\nFiguring out final details about the venue, should have news in the next few weeks\nFakeClient PR\nSome input and help needed. We need to make sure we help quickly on this\nDashboard Authentication example\nSteve saw some code with using user roles to allow better access. Not the best option, but other apps are progressing with authentication\nSee https://github.com/kubernetes/helm/pull/3025\n\nAssignments for next week:\nIssue Sherpa: Michelle\nMeeting Lead: Fisher\nNote taker: Steve\nOctober 5th, 2017\nAnnouncements\nHelm v2.6.2\nStandups\nMatt Fisher\nCut v2.6.2 with help from Adam\nIssue sherpa’ing\nAdam Reese\nAssisting Fisher on the Helm v2.6.2 release\nWorking on porting k8s 1.8 support on top of Helm. There’s some nil errors occurring during testing\nAlso an issue to do with docker/distribution in glide\nFisher mentions that there is an open PR to switch over to dep which may fix that\nTaylor\nWorking on PR support for 2.7\nNeed to figure out the 2.7 release timeline\nWant to get back on Helm commandeer stuff\nMatt Butcher\nGetting back onto the swing of things, been at conferences all last week\nWorking/chatting with the creator of ChartMuseum\nWorking with the service catalog team on sprig PRs which should get incorporated into Helm\nMike Goodness\nFinished wrap-up on calico network policies at TicketMaster, so far so good\nShould be able to spend some time reviewing community PRs on charts\nSteven\nJail chart tiller?\nLooking at checking tiller’s capabilities to check kubernetes api versions for conditional logic in charts\nBrian\nJust listening in this week\nJustin\nWorking on different operators like prometheus\nMatt Farina\nAdded CI to every chart PR, which runs `helm lint` on CircleCI\nGet meetings for ChartMuseum, AppRegistry etc. to sort through all of this\nMichelle (Matt Butcher speaking on behalf of her)\nWorking with karen on helm dev summit\nTaylor is working with michelle on finding venues in portland\nWorking with Fisher on creating a Helm-dev google group for notes, voting etc.\nDiscussion\nHelm 2.7 timeline\nButcher asks if there’s anything other than k8s 1.8 that should get in before we cut 2.7\nTaylor 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\nMatt Farina relays community unrest around the release delay between a kubernetes release and a helm release supporting that kubernetes release\nWe 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\nAssignments for next week:\nIssue Sherpa: Taylor (next week: michelle)\nMeeting Lead: Adam\nNote taker: Taylor\nSeptember 28th, 2017\nAnnouncements\n\n\nStandups\nTaylor\nMerged PRs that should be part of the patch release\nFisher\nIssue sherping\nFacebook Go deps not compatible with Apache v2 or MIT license - need to pull these out\nMaciej\nGetting back to Helm-y stuff\nResuming work on proposal of existing releases as chart deps\nRamp up review counts\nAdam\nJust getting back up to speed after being ill :(\nSteven\nUsing Helm quite a bit, new clusters coming online\nScripts for installing and upgrading Helm\nJustin\nA couple issues\nWorking on galera cluster operator\nMike\nWorking with Calico network policies using a chart\nNeed to give the prometheus operator & alb ingress chart some love\nAdnan\nSomething about CI?\nDiscussion\nFacebook Go dependencies\nInclude in patch release 2.6.2?\nMatt Farina: remove sooner than later\nCutting patch release\nSome bug fixes still not merged\nTaylor to create 2.6.2 milestone\nNot sure we're in a position to release 2.7 next week\n2.6.2 scheduled for tuesday or wednesday next week\nAuthentication webhook\nTaylor to have chart to show for this\nMoving to offline discussion\nDeclarative app management doc\nDiscussed WG formation SIG-CLI meeting\nSIG-Apps and SIG-CLI effort, Helm should be involved\nAssignments for next week:\nIssue sherpa: Matt Fisher\nMeeting lead: Steven\nNote taker: Maciej\nSeptember 14, 2017\nAnnouncements\nStandups\nSteven\nTalked about application deployments using Helm and `kubectl rollout status`\nLypht\nAsked about how to deploy charts sharing common values.yaml\nTaylor mentions https://github.com/skuid/helm-value-store\nImproved documentation on common charts?\nAdnan talked about possibility of `helm create` pulling in the common chart\nMike\nWorking on maintaining Helm chart PRs\nWorking out the storageClass pattern for official charts\nWorking on high quality, solidly reproducible charts\nAdnan\nDid a webinar yesterday with Helm, went rather well\nMatt Farina\nTalked about chart repositories at the last SIG-Apps meeting\nDifferent implementations: kubeless, app registry, traditional helm way\nPrivate chart repositories: app registry vs. dockerhub style\nAdnan: Perhaps incubate app registry as a Helm 3 “official” registry\nAdnan: perhaps just remove the concept of `helm repo update` and a local index.yaml?\nSpun out a larger discussion on Helm 3 chart hosting, migration paths for kubernetes/charts etc.\nJustin\nIssue triaging over the week\nMatt Fisher\nIssue triaging, assisting first-time contributors with their PRs\nDiscussion\nHelm 3 chart hosting, as seen above\nShould we come up with a proposal template for proposals?\nJust want to push back-channel discussion over to the helm dev meetings, more lax proposals\nAssignments for next week:\nIssue sherpa: Justin\nMeeting lead: Taylor\nNote taker: Adnan\nSeptember 7, 2017 [Recording]\nAnnouncements\nIf you need edit access to this doc, let Michelle know\n2.6.1 was released!\nStandups\nMaciej\nWorked on Rudder Federation\nProposal for having existing releases be dependencies\nAdam\nIssue sherpa for the week\nGoing to be looking at deployments not rolling\nStarting work on k8s 1.8 for Helm\nButcher\nWorking on releasing new sprig version\nWorking with Openstack people on running Tiller as a DaemonSet\nDid something else small :)\nMichael\nLots of chart PRs\nMichelle\nReviewing PRs (specifically Amanda’s PR for indexing nested charts)\nFisher\nReviewing PRs, merged Helm template into core\nShould we add a kube version variable to template\nSteven\nCatching up on issues\nTrying out ksonnet\nJustin\nWorking on writing tests for recursive builds (taking over another PR)\nChart sorting\nTaylor\nPR reviews\nNeeds another review on https://github.com/kubernetes/helm/pull/2721\nDemos\nHelmet (Butcher)\nAn intellisense completion tool for Helm on the command line\nhttps://github.com/technosophos/helmet\nDiscussion\nHelm Summit\nPossible location\nPortland\nGeorgia\nHappening in early January\nKube version in Helm template\nRelated PR: https://github.com/kubernetes/helm/pull/2898\nWe can mock things out like we do in tests. We would mock against the current kubernetes version we build against\nTemplate 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\nOutput formatting for Helm\nThis is a complex issue that Adam already tried\nIt might be cool to have, but there will be some work\nThe main benefit would be viewing what the release looks like from a machine readable standpoint\nHelm dev meeting length\nMeeting will now start at 9:15 and go for 45 minutes\nTaylor to announce in channel\nAssignments for next week:\nIssue batman/butler: Butcher\nMeeting moderator: Adam\nNote taker: Fisher\nAugust 31, 2017 [Recording]\nAnnouncements\nOne PR merged for 2.6.1, need to discuss when we want to release\nStandups\nFisher\nIssue triaging, reviewing PRs. No significant feature work\nButcher\nAsked about the `helm template` PR\nJustin mentioned it’s ready for review but not merged yet\nWorking on chart stuff but not core Helm\nMichelle\nNo issue updates for this week\nUpdated the Deis youtube channel playlist\nSeeing if the channel playlist should live in CNCF or in the Kubernetes channel\nMaciej\nWorking on federation rudder\nAdam\nReviewed Maciej’s e2e PR, might want to hold off on merging until 2.6 is out to test tag release automation\nPossibly 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\nBrian\nNot present\nTaylor\nWas the issue maharaj this week, kudos to fisher and justin for triaging issues this week\nDoing PR reviews this week\nChatting about secrets backend for Tiller, due to the size needs he asked for another review from the core team\nRobots are taking over Helm’s issue labels\nButcher’s saying that we’ve been pushing back on moving over to the kubernetes-helm org for a while\nAny bots that are CNCF-related (like the CLA bot) could be pulled in once we move orgs\nGoing to move forward with seeing how we can configure the PR sizing bot and see how we deal with them moving forward\nLachie\nNot present\nSteven\nWorking on Helm adoption internally\nLooking at integrating with artifactory\nOver the weekend had some time to look at some of the issues and PRs\nAdnan\nIn the community repo, there’s a PR for meeting notes to reference the single google doc (this one)\nDiscussion in the charts repo about moving away from annotations over to fields in the spec\nLots of people are adding network policy stuff which is nice to see\nJustin\nGeneral issue triaging\nTaking on the work for recursive build feature\nDemos\nDiscussions\nHelm 2.5.1 issues to cherry pick?\nThe subcharts being deleted when not present in requirements.yaml\nPossibly adding in the regex case-sensitive issue on helm search? https://github.com/kubernetes/helm/pull/2876\nFixup with relative index.yaml https://github.com/kubernetes/helm/pull/2862\nPlanning for next week\nIssues: Adam Reese\nMeeting moderator: Maciej\nNote taker: Taylor Thomas\nAugust 24, 2017 [Recording]\nNo announcements\n1 ticket for a 2.6.1 release, moving forward with 2.7.0\nStandups\nFisher\nIssue queue\nTaylor\nWorking on scaffolding for helm commandeer\nIdentified bug on helm delete, community member took this on after\nPR is out\nWould warrant 2.6.1 release\nButcher\nPlanning related stuff\nBeginning helm 3.0 phase the beginning of January\nKubernetes Core has asked us if we would start releasing when kubernetes releases within a week or so of a Kubernetes release\nLachie\nIs there anything we do could do as chart maintainers to start testing against kubernetes 1.8\nMichelle\nStill waiting on initial cost projects for helm summit and helm core maintainer sessions. Will probably happen in January. Looking for sites.\nLooked into this PR: https://github.com/kubernetes/helm/pull/2824\nThink it’d be best to nest helm readme command under helm inspect\nHelm Q&A time during next SIG Apps meeting. Here is the form.\nAdnan\nThere is a discussion going on in charts around functions to be namespaced\nhttps://github.com/kubernetes/charts/issues/1785#issuecomment-323642628\nMaciej\nWorking on e2e tests https://github.com/kubernetes/helm/pull/2846\nCreated a framework, not about creating scenarios\nUsing gingko\nFor each test case, create new namespace\nWaiting on review and feedback\nStarted writing proposal on using existing helm releases for dependencies\nLooking for feedback\nDemos\nDiscussion Topics\nLook at Maciej’s proposal for re-using existing helm releases as dependencies\nPlanning\nIssue Maharaja: Taylor Thomas\nMeeting moderator: Michelle Noorali\nNote taker: Matt Fisher / Matt Butcher\n\nAug 17, 2017\n\nTopics:\n\nNote taking\nRecording\nHelm Commandeer\nCircleCI/testing\nAutomation of Homebrew, etc\nVolunteer for triage, note taking\n\n\n\nTaylor:\n• Helm comandeer\n\nMajiec:\n• e2e testing: basic framework for running and checking\n• Want to talk about CircleCI capacity for running these\n\nFisher:\n• Issue triager for last week\n  • Caught up on old untriaged issues\n\nJustin:\n• Closed a bunch of ancient issues\n• Little stuff like the manifest ordering patch\n\nSteve:\n• “Helm on Helm” to install Tiller via a chart\n• Issue queue managing\n\nAdnan:\n• 0.4.0 of Monocular released\n• New chart maintainer joined last week\n\nLachie:\n• Azure installing Tiller by default, working on some similar RBAC stuff to Steve\n\nMichelle:\n• Community meeting with Karen Chu (MS) on organizing Helm Summit\n• Onboarding with Majiec\n\nAdam:\n• Release of 2.6\n\nButcher:\n• 2.6 stuff\n• Getting ready for 2.7\n\nRonan:\n• Documentation update run soon\n\n\n\nNote Taking and Recording:\n\nWhere do we store notes? What do SIGs do?\n\nGoogle Doc for collaboration\nRotating meeting leads and note taking every week is fine?\nMinutes will go in https://github.com/kubernetes-helm/community\n\n\nNext week’s…\n\nMeeting leader: Fisher\nNote taker: Michelle\nIssue Sherpa: Justin\n\n\n\nRecording:\nOne of the SIG-Apps leads will record via Zoom\nSet up YouTube channel (Michelle)\nEach week, add link to the repo\n\n\n\nHelm Commandeer\n\nAdopt existing resources into a chart/release\nUse Case: Bootstrap cluster, install Tiller, then turn around and capture the bootstrapped resources as charts/resources\nButcher/Scott: Capturing existing resources for already-deployed Kubernetes clusters\nSteve: Trimming out state information is painful. Might be nice to have a “spec” that an object can be imported into\nMajiec: Two arguments for doing this as a plugin instead:\nIt can make use of Helm as libraries\nIt forces improvements of the API\nLachie: Concern is with starting to confuse what the “source of truth” is for features.\nTaylor: Okay, I do it as a plugin, with the goal of making it a “gold standard” plugin\n\n\n\nCircleCI/automation/etc\n\nMajiec: 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\nAdam: I actually reserved you a dedicated e2e resource\nScott: 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.\nFisher: Maybe you (Scott) and I can chat about that\nLachie: Chart maintainers are also talking about that today\n\nTemplate\nAnnouncements\n\n\nStandup\n\n\nDiscussion\n\n\nAssignments\nIssue Sherpa:\nNotes:\nModerator:\n```\n"
  },
  {
    "path": "community/meeting-notes/2018.md",
    "content": "---\ntitle: Helm Minutes for 2018\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/meeting-notes/2018.txt\n-->\n\n```txt\nDecember 20, 2018\nAnnouncements\nNo meeting next week!\nHelm 3 repos working group, Wednesdays 8:30-9:00 am PST [link]\nHelm Hub is live! https://hub.helm.sh\nHelm 2.12.1 is out (decaf edition)\nStandup (kubecon was last week)\nAdam\nGiving update on Kubecon/Helm v3\nThe v3 talk was highly attended and engaged\n\n\nMatt Fisher\nJosh\nMatt Farina\nMichelle\nScott\nAdnan\nHelm v3 Status\nhttps://github.com/helm/helm/projects/1\nTasks open for people to take on are tagged with “help wanted”\nIn the past week we organized to update the details on the tasks\nDiscussion\nProposal for CRD Support\nWe would like less intrusive changes to support CRDs\nWill CRDs become GA or overcome as TPRs were?\nWill look into patterns in current system that we could potentially use\nHelm 2 to 3 upgrade story\nA tool that can migrate from v2 config, as managed by tiller (configmaps/secrets), to the new v3 format\nDocument what we need to do (proposal in community repo)\nHelm 3 repos update (Josh)\nTLDR; Helm charts will be able to be stored in an image registry\nhttps://groups.google.com/a/opencontainers.org/forum/#!topic/dev/qYM84b0vays\nAssignments\nIssue Sherpa: Michelle\nNotes: Josh\nModerator: Matt Farina\nDecember 6, 2018\nAnnouncements\nHelm Deep Dive now 80 minutes (2 back to back time slots) at CloudNativeCon\nFirst half is the Helm 3 deep dive, second half is free-form discussion\nHelm 2.12.0-rc.2 has been released\nStandup\nMatt Fisher\nWorking 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.\nAttending to the helm repository discussion\nMatt Farina\nWorking on the hub to get launched\nTaking the charts in image repos to the OCI\nhttps://groups.google.com/a/opencontainers.org/forum/#!topic/dev/U49AZRFo3tk\nNikhil\nBack from paternity leave - just getting back into the swing of things.\nJosh\nWorking on chartmuseum 0.8 with bearer auth support\nContinuing to moderate the helm repository discussion\nNow discussing with people at docker on the distribution API\nBrian\nWorking on utilities on mapping Go values to Lua, deserializing back to YAML\nAdnan\nWorking on the hub\nPost-kubecon, looking to add some CI to deploy to the helm hub repo\nContinuing development on monocular\nJustin\nBusy, hoping to help out with the issue queue/PR queue\nTaylor\nHelping fisher on the 2.12 release\nWant to have a discussion on adding contributors to help out on Helm 3 (onboarding)\nMichelle\nPutting together some slides on Helm 3, hub.helm.sh and Helm 2 for the KubeCon keynote update from Liz\nHelm v3 Status\nAdam has no voice/internet today, therefore no update this week\nDiscussion:\nTaylor: on adding contributors to help out on Helm 3 (onboarding)\nTaylor: action item to talk to adam about discuss onboarding\nSome bugs that may need some love: 949, 990, 1098, 1168, 1193, 1237, 1354\nDiscussion: how do we want to handle long-standing issues that have gone stale?\nFarina: 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\nAction item: michelle will open a ticket for discussing the issue of closing long-standing feature requests\nHow do we get proposals in?\nThis process should be documented\nAction item: henry will open the issue to write up the docs\nShould we have another standup next week?\nYes, one standup next week then cancel until the new year\nAssignments (for week after Kubecon - 20th )\nIssue sherpa: matt, matt and michelle all working part-time\nNotes: (Nikhil can’t make this) Farina\nModerator: taylor\n\nNovember 29, 2018\nAnnouncements\nRecurring Helm 3 Repos discussion, Wednesdays 8am PST\nStandup\nJosh\nSetup weekly Helm 3 Repos discussion, Wednesdays 8am PST\nHad call #1, made some progress.\nRemoving --version flag\nKeeping “helm repo add”\nMatt Farina\nWorked on Helm Intro slides for seattle\nSigned up for the project maintainers booth in seattle\nMatt Fisher\nAdam\n\n\nHelm v3 Status\nHelm repo stuff, not ready for Kubecon\nRequirements handling, cleanup. Merging arbitrary data. Pre-req for adding Lua to execution engine\n\n\nDiscussion\nFisher: Helm 2.12 release status\n1 PR - feature flag to helm upgrade “--cleanup-on-fail”\nhttps://github.com/helm/helm/pull/4871\nNeeds few more reviews (Taylor + Fisher + ?)\nCan this make it in? https://github.com/helm/helm/pull/4709 (Jacob Legrone)\nButcher: looks great\nIs there a plan for a helm contributors/maintainers social get-together, drinks (I volunteer to buy the first round!) at kubecon? [henrynash]\nCNCF booth? Microsoft Booth?\nLook for peoples hair\nMS Reactor event: https://open.microsoft.com/2018/11/21/microsoft-pre-kubecon-community-workshops/\n\n\nFixing bugs in v2 & v3 [mattfarina]\nFor features - if they do not affect Helm 3, we consider merging\nIf it solves for Helm 2 and 3, asking contributors if they are willing to add these things for Helm 3\nBugs - will be merged\nSystem wide plugins [mattfarina]\nSUSE wants to add this for envs that are unable to install plugins\nCan be handled by https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html\nAdam: this is on Helm 3 project board , XDG configuration\nGiven 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]\nFisher: 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.\nStandup is good to give people chance to speak up, get people engaged\nStef: comes to meeting to keep up with what were up to, also to be involved\nTechnical-level discussions, fostering this type of community at SUSE\nHenry:\nMartin: just make standup shorter, main points in discussion\nAssignments\nModerator: Josh\nNotes: Matt Fisher\nIssue Triage: Martin\n^ may not have access to add labels etc\n\nNovember 22, 2018\nCancelled due to holidays\n\nNovember 15, 2018\n```yaml\nAnnouncements\nBrian is the bee’s knees: github.com/Azure/golua\nBecause of Thanksgiving, this meeting will be skipped on Nov 22.\nStandup\nJosh\nMeeting 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\nWill send out an email to the CNCF mailing list\nMatt Fisher\nBeen working on getting the helm 2.12 release out\nMichelle\nTrying 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)\nBrian\nBeen working on golua as well as some debug facilities into the VM execution for the lua engine\nSpending the next few weeks focusing on the debugging library as well as panic traces in the lua VM\nMatt Butcher\nOn the Helm 3 side, opening PRs on re-naming some of the commands\nWorking on the Helm 3 conference stuff for KubeCon Seattle\nAttempting to make progress on a Helm 3 alpha release for KubeCon Seattle (tentative)\n2 sessions for the core maintainers: intro and advanced sessions\nWorking on a Helm Summit EU for spring 2019\nAdnan\nFocusing on Monocular and kubeApps\n(butcher) are we planning on a KubeCon announcement for that one?\n(adnan) yeah, it’d be great to announce that in the intro\n(butcher) it might be getting a main stage annoucement\nMatt Farina\nWe might be getting the main stage for KubeCon\nWorking on a session for the Hub\nIssues triaging etc.\nAdam Reese\nLooking into integrating golua into Helm\nMostly focusing on helm 3\nHelm v3 Status\nDiscussion\nFixing bugs in v2 & v3 [mattfarina]\nWhat is the success criteria for going back to one issue triager? [bacongobbler]\nWill follow up in cncf-core-maintainers mailing list\nAt 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]\nSystem wide plugins [mattfarina]\nhttps://github.com/helm/helm/pull/4871 [mattfarina]\nCRD lifecycle - Helm and deleting CRDs (doesn’t today) and CRD lifecycle [mattfarina]\nThe crd-install hook only deals with the install lifecycle but there are open issues IRT CRDs with Helm. How should we approach this?\nAdam: 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\nJames: 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\nAdam: 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\nMortent: would it be valuable to add a proposal for the solution in Helm 3?\nJames 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\nAt 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]\n<heresy>Given the increasing agenda length, if we are going to stick to a 30min call, maybe we should skip the Standup section?</heresy> [henrynash]\nAdam: should we talk about this in 2 weeks at next standup?\nHenry - happy with that\nGiven 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)\nPR #4871? [farina & fisher]\nAdam: Let’s follow up offline\nAssignments\nModerator: Fisher\nNotes: Josh\nIssue: Michelle & Fisher\n\n\nNovember 8, 2018\nAnnouncements\nBecause of Thanksgiving, this meeting will be skipped on Nov 22.\nStandup\nMatt Farina\nSpecs repo, document how everything works\nIssue sherpa-ing this week, trying to bring down queue\nChanges to monocular to work w MongoDB over SSL, to support Helm Hub\nMatt Butcher\nSSL issue, CRLs not supported by GRPC/Go crypto libs (link?)\nGoing away in Helm 3, so if somebody else wants to take it, go for it\nFormal specification for Helm 3 charts - to track what is and isnt supported\nSome parts of charts in Helm 2 are unclear/not documented\nStarting on Helm 3 CLI stuff soon\nTaylor\nSlide decks for Kubecon shanghai\nAsk taylor for help looking at PRs\nMichelle\nReviewed old issues\nParallel flag on Helm test, did testing (link?)\nMore issue triage this week\nJosh\nLooking into a proposal that Steve put together involving repositories for v3 -> #55\nSubmitted another related proposal. Will talk about that in discussion. -> #57\nMatt Fisher\nIssue triaging this week\nPrimarily focused on PR queue\nSlating things for 2.12 RC release\nAdam\nHelm 3 CRDs\nSome PR reviews\nAdnan\nWorking on Monocular w Farina\nSubmitted PR to monocular to support\nMonocular chart still needs to allow Mongo params as secret vs. values\nBrian\nStabilizing Lua VM\nPrototyping events code\nHelm v3 Status\nProject board: https://github.com/helm/helm/projects/1\nCards are being added linked to topics from the proposal in helm/community\nWill be converted to issues when people are ready\nLua, charts format in progress\nKubernetes-core removed as a dependency\nDiscussion\nHelm v3 repository topics [jdolitsky]\nCommunity proposal #55 - merging helm repos and docker registries\nThe basis of this proposal is for helm repositories to mimic the docker registry API more closely\nLooking on what is the right way to build it out further\nJimmy: the problem I see is the backwards compatibility for the pre-existing repository system (referring to Helm 2 repositories)\nFisher: 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)\nThe quay implementation restricts repositories to a single mimetype to avoid this problem, but that has UX tradeoffs\nFollow-up: let’s set up a call to discuss this meeting (assigned to Josh Dolitsky)\nCommunity proposal #57 - Helm 3: push, login, capabilities api\nAssignments\nModerator: Adam\nNotes: ?\nIssue:\nMichelle\nNovember 1, 2018\nAnnouncements\nJosh and Scott are now Helm Org Maintainers [mattfarina]\nStandup\nJosh\nWorking on chartmuseum 0.8 with token bearer auth support\nWorked on proposal with Azure folks on merging docker and helm repos\nAdam\nLast week in a company team offsite\nMatt Fisher\nIn team offsite last week\nDoing triaging for v2.11.1 looking to see if we should patch release\nMichelle\nResponded to comments on helm test proposal (for v3)\nhttps://github.com/helm/community/pull/40\nIn team offsite last week\nMatt Butcher\nTeam meetings last week\nWorking on helm v3 command line argument changes\nRemoved moniker naming\nBrian\nAt team offsite\nFocused on Helm v3 lua integration\nMatt Farina\nDoing issue triaging last week\nWorking on nested repositories for the Helm 3 proposals\nTaylor\nWriting slides for China and Helm deep dive\nHelm v3 Status\nTalked through the board\nWhen something in the proposal goes to being built we can:\nConvert existing cards to issues in the project\nWhen implementation happens we should add a link to an implementation issue where further details can be found in the proposal\nDiscussion\nHow can we handle the 500+ open issues? [mattfarina]\nNot going to add a stale issue closer yet but discussed\nGoing to have multiple issue sherpas to bring the number down\nIssue #3943 - allow a fix for this in helm 2? [jdolitsky]\nThis fix can go in as long as it’s opt-in and no APIs are changed in backward incompatible ways (including tiller api)\nAssignments\nModerator: Matt Butcher\nNotes: Josh Dolitsky\nIssue:\nMatt Farina\nMatt Fisher\nOctober 25, 2018\nAnnouncements\nDistributed charts repo search update via mailing list email\nStandup\nJosh\nInvestigating helm login commands for different repository providers\nChartMuseum has a PR for oracle storage backend\nMatt Farina\nWorked on some charts tooling\nShowcased helm repo audit\nTaylor\nNot much coding this week\nPrepping to talk in China about v3\nDiscussion\nAdd weekly review of helm 3 github project to this meeting [Adam Reese]\nIssues needing some extra love:\nPotentially can try and close out: 4789, 4773\nNeed a response to: 4833, 4831, 4827, 4826, 4824, 4784, 4767, 4754, 4744, 4699, 4695, 4679, 4698, 4697, 4695, 4679\nAssignments\nModerator: Josh\nNotes: Matt Fisher\nIssue: Matt Farina\n\nOctober 18, 2018\nAnnouncements\nNo announcements for this week\nStandup\nMatt Farina\nWorking on bringing back the PR sizing stuff\nLooking back on the hub stuff with adnan in the future\nMatt Fisher\nNot much to report this week\nTaylor\nWorking on a talk for KubeCon Shanghai on an intro to Helm\nAlso looking at doing a talk on a Helm 3 deep dive, also at KubeCon Shanghai\nAdam\nStarted putting together a github project for Helm 3 work\nhttps://github.com/helm/helm/projects/1\nNon-core maintainer standup\nMartin Hickey\nDropped a few issues down in chat\nIssues potentially can try and close out: 4782, 4775, 4768, 4751, 4745, 4713, 4705, 4689\nIssues need a response to (potential quick response): 4796, 4793, 4790, 4767, 4744, 4737, 4729, 4712, 4699, 4698, 4697, 4695, 4679\nDiscussion\nedX course… anyone interested in doing it? CNCF has $$ [Matt Farina]\nUniversity-like material for education on Helm\nTaylor: I might be interested in it but not sure about the timeframe is on that\nFarina: let’s talk about this offline, but this opportunity just came up\nShould helm login support basic auth in addition to oauth? [Matt Farina]\nAdam: I’m not sure how difficult it’d be to add that in\nFarina: so we should probably support an oauth mechanism out of the box for now\nHelm container image? What base image (scratch, alpine, etc?) [Matt Farina]\nTiller uses alpine, so we should probably re-use that\nFollow-up question: should we also push tiller images to quay/dockerhub?\nI think we’re at an acceptable time to push to both gcr and quay using CircleCI\nLinkerd2 has a different way to inject sidecars. How can we do this with Helm today? [Matt Farina]\nAdam: yeah, I don’t think we could accommodate this today, essentially linkerd2 needs to stream-edit the chart as it’s being applied\nFarina: could the event changes in Helm 3 help accommodate this?\nAdam: theoretically, yes\nFarina: perhaps it would be good to sit down with the linkerd folks\nAssignments\nModerator: Taylor\nNotes: Farina\nIssue: Fisher\nOctober 11, 2018\nAnnouncements\nMatt Butcher is the new chair of the org maintainers\nStandup\nJosh\nLooking into v2 repo index\nChallenges are that it is partitioned into multiple files\nDesign work around things like nested chart directories needed\nFarina\nWorking on getting the Hub site rolling\nDco-labeler moved to charts AKS cluster\nIssues with AKS cluster\nAdnan\nHelm hub site\nMonocular 1.0\nCosmos DB\nFisher\nIssue queue stuff\nAdam\nHave some PRs to go through, small changes, docs changes\nOut for a bit\nFocusing on helm 3 stuff tomorrow\nKubernetes 1.12 merged\nMichelle\nWent through some PRs this morning\n3805 and 1193\nBrian\nWorking on lua for Helm 3, continuing through the tests\nNotes and talking points for the use of Lua in Helm\nJustin\nA little issue triage\nHoping to jump on some PRs soon\nButcher\nHelm trademark move from Deis/MS to CNCF\nKubeCon Helm stuff\nPlanning work on Helm Summit in the EU (spring next year)\nDiscussion\nHow can we better communicate around Helm v3 and let people help with it? [Matt Farina]\n[Henry Nash] Maybe at least add weekly item for an update on v3 development, calls for help, focus areas etc. ?\nImplementing index v2\n\nAssignments\nModerator: Adam\nNotes: Fisher\nIssue: Michelle\nOctober 4, 2018\nAnnouncements\nHelm Org Maintainers vote link [Matt Butcher and Matt Farina]\nStandup\nAdnan\nWorking on Monocular 1.0, migrating onto CircleCI because that’s what most teams are using it seems\nJosh\nIn talks with the Azure Container Registry team in regards to API design\nMatt Farina\nWorking on the hub site (hub.helm.sh)\nAll the infra is there and ready (cert-manager, letsencrypt, ingress etc.)\nHow do we store secret information? Want to chat about it today\nMatt Butcher\nTransferring the Helm trademark to the CNCF, working with the Microsoft lawyers for transferring the paperwork in time for KubeCon\nWorking on the Helm 3 stuff with Adam and Brian\nBrian: working his way through implementing the Lua stdlib\nVic\nI have been getting back into reviews on the charts repo.\nMatt Fisher\nLast week has been maintaining the issue queue, ensuring whether or not we need to do a v2.11.1 release\nAdam\nLast week has been focused on Helm 2 and Kubernetes 1.12 support\nNothing ready to show yet, waiting on upstream to fix some things which should be coming out later today\nNon-core maintainers\nMartin Hickey\nIs it true that the Helm 3 codebase has been locked down to core maintainers?\n(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?)\nIn terms of docs, what areas can we help?\n(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\nMarkdown docs are stale in dev-v3, so updating the README or jumping into existing project work (docs site, CI infra, repository API working group)\nDiscussion\nEncrypting secrets for sites and services [Matt Farina]\nOrg maintainers - congrats! You are now responsible for the following [Josh]:\nMaintaining the mission, vision, values, and scope of the project\nWhat is it that Helm trying to solve? (mission)\nWhere does Helm start and end? (scope)\nHow will we get there? (vision)\nWhat do we need to embrace in order to succeed? (values)\nRefining the governance and charter as needed\nWhat can we do to make this process ultra-efficient?\nHow do move fast and not break things?\nMaking project level decisions\nHow can we make sure people have necessary info in order to confidently vote?\nWhich type of decisions are made at the subproject level? (eg. choice of CI, language, etc.)\nResolving escalated project decisions when the subteam responsible is blocked\nWhat are the respective subteams?\nWho will be primary points of contact for each?\nManaging the Helm brand\nWebsites, logos\nDocumentation\nTutorials and evangelism\nTwitter, social media, etc.\n?\nControlling access to Helm assets such as source repositories, hosting, project calendars\nWhich tools will we use managing and sharing credentials?\nHandling code of conduct violations\nViolators will be publicly executed with a 2/3 vote\nDeciding what sub-groups are part of the Helm project\nShould this divide into more than just subprojects? (eg. testing committee)\nOverseeing the resolution and disclosure of security issues\nMajority of issues would related to Kubernetes in Helm 3\nDoes CNCF have a process in place for this?\nManaging financial decisions related to the project\nWhat types of things might cost money?\nHow does being a CNCF project relate to this?\nCan companies or individuals contribute?\nHow can we ensure that the direction of the project cannot be “bought”?\nAssignments\nModerator: Josh\nNotes: Adnan\nIssue: Adam\nSeptember 27, 2018\nAnnouncements\nHelm 2.11 with Kubernetes 1.11 support was released\nTomorrow is the last day for nominating Helm project maintainers\nStandup\nAdam\nOn vacation last week\nContinued work on Helm 3\nStarted on Kubernetes 1.12 support\nFarina\nWorking on getting the Hub cluster up and going\nPublished a blog post on how to use chart-testing yourself!\nMoving bots under the helm org\nButcher\nProvenance and crypto stuff\nBlog post for the Helm blog\nStaying on top of Helm 3 things\nBrian\nGet the lua implementation passing against the spec conformance test suite\nIssues around snapshotting values, ironed them out\nContinuing to wrap up lua implementation over the next few weeks\nJustin\nIssue triage, helped people close a few issues\nAdnan\nMonocular 1.0 close to cutting\nWorking on moving the chart-repo and chartsvc to the Helm org, moving images to quay\nFisher\nGoing through Helm 2.11 release\nEnsuring RCs have been going through smoothly\nStef\nSUSE working on a Helm mirror utility\nDiscussion\nKubeCon Seattle Helm Talk Coordination [Matt Butcher]\n3 talks: intro to Helm, draft, deep dive on Helm\nReddit is going to talk about their story for getting into k8s, includes Helm\nFind out what Helm related talks will happen and put together a list in hackmd or somewhere\nChart caching, using it, and content addressability https://github.com/helm/helm/issues/4618 [Matt Farina]\nCache as-is doesn't work because could have same chart and version\nUse digest instead as cache key for Helm 2\nHomebrew Helm problem\nFixed and merged!\nJustin: Docs site search experience improvement\nFarina: Outstanding issue to move Helm docs out of tree to another repo\nAssignments\nModerator: Adam\nNotes: Fisher\nIssue Sherpa: Justin\nSeptember 20, 2018\nAnnouncements\nHelm 2.11 RC4 released yesterday\n1.11 Kubernetes support\nhttps://github.com/helm/helm/tree/v2.11.0-rc.4\nStandup\nJustin\n\n\nMatt Butcher\nPutting together helm demos for ignite\nBrian\nWorking on lua implementation\nAdam\nValues files stuff\nCRD, replacing secrets\nTiller race conditions\nMichelle\n2.11 release\nMatt Fisher\n2.11 release\nAdnan\nMonocular 1.0\nCron jobs to sync chart repositories, more responsive\nMatt F\nWaiting for cluster, still being worked on\nPolicy, workflow and tooling stuff for the Hub\nDocs for how to stand up a helm repo\nChart-testing images now up on quay\nJosh\nHelm push and authentication\n\nDiscussion\nHelm -push multiple provider support\nSomething in index.yaml?\nGovernance\n1 week left for nominations, 9 people nominated and accepted\n7 initial selection, but can have up to 9\nhttps://gist.github.com/mattfarina/51056f5655dea3f0d60e20b37ccc79c2\nUsing Quay for chart testing\nhttps://quay.io/repository/helmpack/chart-testing\nProvides usage logs\n2.11 official release date\nBugs should be squashed\nTuesday Sep 25th (unless explosions, Wed)\nWhy Lua?\nNeed to explain to users the reason for this\nWhy not JS etc\nWrite a post/doc that dives into depth\nAssignments\nModerator: Matt Fisher\nNotes: Adnan\nIssue Sherpa: Justin\n\nSeptember 13, 2018\nAnnouncements\nHelm 2.11.0-rc.2 was released yesterday\nHelm Governance votes were complete last week\nStandup\nMichelle\nIssue triage\nWorking on proposal for auto rollback feature\nFisher\nWorking on the Helm 2.11 release making sure that’s going through\nAdam\nWorking on some of the Helm 3 design stuff with CRDs\nOut of town next week so will miss next week’s standup\nMatt Farina\nWorking on the charts repository stuff, DCO labeling\nThrowing the charts-testing image on quay.io\nWorking on putting a blog post on working with the charts-testing project\nWill be weighing in on the distributed search proposals\nBrian\nWorking on the Lua VM implementation for Helm 3\nJosh\nClosed a few ChartMuseum chart PRs\nLooking into authentication/authorization flow for Helm 3\nDiscussion\nChart packaging system improvements (@gintas) Please see https://hackmd.io/Q8dyCyztRmW4_Xz9UFwuMQ\nFarina: 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.\nThe question becomes “how do we do caching/forking with this model?”\nWe could run a hash on the chart and map it to that, perhaps\nJosh: hashing may be a problem with relative file path links in requirements.yaml (charts can change on disk)\nFarina: 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?\nAction item: reach out and follow up with @gintas on the core problem without trying to come up with a solution\nhttps://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?\nFisher: does the CNCF have any policies/thoughts on statistics for CNCF projects (e.g. any policies that came out of devstats.cncf.io)?\nFarina: good question. I’ll follow up with them\nAdam and Matt: probably good to just track general trendlines rather than deep personal data on users.\nJosh: can we move the ChartMuseum image over to the quay repository?\nFarina: yeah!\nTravis Foster: hey, I’ve been looking into JSON parsers for Helm 3\nhttps://github.com/helm/community/issues/49\nFarina: 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.\nAssignments\nModerator: Matt Farina\nNotes: Michelle\nIssue Sherpa: Matt Fisher\nSeptember 6, 2018\nAnnouncements\nGovernance has enough votes to pass! Acceptance window closes today at 5 pm Pacific\nStandup\nTaylor\nAt Open Source Summit last week\n2.11 PRs this week\nJosh\nExploring Helm login and authorization flows. Been talking to Matt Farina and some of the people on the Microsoft Containers team\nAdnan\nMerged the Monocular 1.0 proposal\nMatt Fisher\nAt Open Source Summit last week\nWorking on 2.11 PRs this week.\nMatt Farina\nWorking on Governance this week\nCharts 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\nMichelle\nWorking on proposal for auto-rollback when releases fail\nAdam (vicariously through Michelle)\nWorking on Helm 3\nDiscussion\nHelm 2.11 release\n3 PRs left in the queue before we can cut a release, all ready to go: https://github.com/helm/helm/milestone/55\nShould we pull https://github.com/helm/helm/pull/4468 off the milestone? (fisher)\nWe are ok with pushing this off to 2.12 so we can hammer out some design issues.\nRE: PR #4590, was there a technical reason we use cmd.PersistentFlags() in certain commands vs cmd.Flags()? (fisher)\nPersistentFlags used so all subcommands can inherit the flag. Fisher is going to go back and change this for some of the new code\n“maven-like dependency system” for charts (josh via gintas)\norg.apache:kafka:1.0.0 -> ~/.helm/repository/org/kafka/1.0.0/kafka-<classifier-id>-1.0.0.tar.gz\nPossibly adding dependency caching\nJosh is going to work with a few others to create an issue on this\n(Henry Nash): As a newbie, have some questions about how the overall community works etc.\nIBM is starting to use Helm a lot and wanted to get involved\nAssignments\nModerator: Josh\nNotes: Fisher\nIssue Sherpa: Michelle\nAugust 30, 2018\nAnnouncements\nSwitched to the DCO from the CLA\nBlog post here\nStandup\nAdnan\nPR’ed Monocular 1.0 proposal\nMatt Fisher\nAt Open Source Summit NA\nPaired with Taylor around 2.11 release, triaging issues\nBrian Hardock\nLua work for Helm 3.0\nMichelle\nWorking solution for Issues #3805 and #1193\nVic\nWorked with folks at Replicated Ship\nTheir business is to ship software to vendors\nDid presentation at SIG Apps\nWorked on how to do customization around helm charts for different environments. “Last-mile customizations”\nMatt Farina\nDCO change + prep work for DCO change\nFollow up issues on charts automation\nMade changes to governance doc\nMatt Butcher\nWorked on governance docs with Farina\nJosh\nGiving a short talk on helm 3 in SF\nAdam\nWorking on refactoring for Helm 3. Got a bunch of stuff merged.\nNew API for dealing with charts and releases\nSetting up for Lua stuff\nWorking on upgrade issue with Fisher and Michelle\nDiscussion\nEstimating the Airspeed Velocity of an Unladen Swallow\nBumped to next week\nShould we use something like https://github.com/ericchiang/k8s instead of client-go for helm v3? (Farina)\nClient-go has some well known pain points\nButcher: is it still being maintained?\nNot sure\nWould it be practical to use an alternative client to client-go in helm 3?\nButcher tried it. His findings:\nPervasive change\nEric made some really insightful changes but that create a somewhat cumbersome experience\nFor example, pointer to all the fields\nThis is the approach that apache thrift took\nTo use this library, some things are more cumbersome for the user\nSome parts of the library didn’t feel 100% done\nPros: dep ensure took like 5 seconds\nAdam: what is driving this?\nFarina: Making upgrades easier. This is the time to make breaking changes, so let’s entertain the idea.\nAdam: will take a look at it this week\nDocker Hub vs alternatives for public image distribution (Farina)\nOn 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.\nWent out on the email list\nButcher: DOCKERHUB\nQuay will tell us if there are vulnerabilities\nMichelle: security is nice. Cool.\nFisher: DockerHub seems to be ubiquitous\nDeis Workflow had a tough time trying to figure out metrics like image download count. Didn’t know if it was actually accurate.\nMetrics not a blocker if the discoverability is the primary driver for this.\nWhat is the best place to store images to get metrics?\nMetadata points in ACR but it’s not public so it’s not an option\nA wild Taylor appears in the meeting\nIs DCO required for a PR with a CLA that was submitted before the DCO took place?\nShould not be required. PRs are covered before\nAssignments\nModerator: Michelle\nNotes: Taylor\nSherpa: Fisher\n\nAugust 23, 2018\nAnnouncements\nStandup\nFisher\nMonitoring 2.10 release and making sure everything is going as planned\nMatt Butcher\nIssue sherpa for this week, nothing significant to report\nWorking with Matt Farina on the governance proposal\nTalking with Brian and Adam on some of the Helm 3/Lua stuff\nAdam\nContinuing work on refactoring Helm 3, looking into breaking things into smaller chunks to move things upstream\nMerged Kubernetes 1.11 support into master and the dev-v3 branch\nMichelle\nReviewing Helm PRs\nRe-named the helm-secure plugin to helm-rbac\nTaylor\nDoing some PR review work\nThere is an open PR for recursive build option, code looks good but there may some eyes on it\nAsked Matt Farina if he can help take a look at it\nAdnan\nWorking on a proposal for changes to Monocular\nFisher\nReleased helm v2.10.0\nScouring 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\nJosh\nTraveling etc last week\nWorking with helm repository authentication stuff\nPlanning to add “helm push” API spec to specs repo soon\nMeeting 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\nGiving 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/)\nChartmuseum website to launch possibly next week. Preview: https://codefresh-io.github.io/chartmuseum-www/\nMatt Farina\nWorking on the governance model as well as the switch to the DCO\nJustin\nWon’t be available for 3 days\nSomeone at istio was being blocked with https://github.com/helm/helm/issues/3805\nAdam: this would be a major breaking change to how Tiller works for Helm 2, but it could be a possibility for Helm 3\nThere are a ton of edge cases around the different merge strategies\nFarina: what about server-side apply?\nAdam: same problem, it would be a very large technical challenge to manage different upgrade strategies for Helm 2\nDiscussion\nQuestion: how does helm plan to address auto-generated configuration on `helm install`? E.g. autogenerated passwords in the postgres chart\nFarina: we should come up with a convention.\nButcher: I would guess doing a pre-install hook to install a Configmap to autogenerate a password and place it in there\nDCO?\nButcher: DCOs require all commits need to be signed?\nAdam and Farina: yes\nhttps://github.com/mattfarina/brigade-test-project/pull/1\nhttps://github.com/probot/dco\nFarina: asking michelle if they can pair on this on Monday?\nMichelle: yes\nHelm v3 or hub: enforce or notify if immutability changed?\nFarina: if the digest changes, should we notify if someone broke\nThis is referring to changing an existing chart in-place, not bumping the version\nMichelle in chat: then yes, we should put a warning in\nAdam: the one thing we may want to think about is when charts are in development.\nFarina: we could do a digest diff on a `helm repo update`?\nFarina: we should probably think this one through\n“helm login” - How do we envision this to work? Anybody interested in a call to address this in detail?\nJosh will put out an email to discuss this topic\nButcher: can we start on the next Helm release since k8s 1.11 support is done and we have a few minor features committed already?\nFisher: sure\nButcher: there’s a lot of people asking for it, so we should cut an RC\nTaylor: we should go through the PR queue before we cut an RC as there’s been a few requests\nAssignments\nModerator: adam\nNotes: michelle\nSherpa: justin\n\nAugust 16, 2018\nAnnouncements\nSlack is down, meeting link needs update.\nStandup\nTaylor\nPR work, with follow-ups today and tomorrow\nMatt Farina\nChart PR queue reduced. Now below 400\nDCO chart automation is a blocker to widespread DCO adoption.\nDistributed chart site is underway. Looking at hosting\nLink for this meeting is wrong in Helm repo README. Will fix.\nButcher\nMain focus right now is on Helm governance, CNCF deadline is September\nWorking with one of Microsoft’s engineers on a bug with `helm ls`\nNext week: continue to focus on governance and focus on next release for Helm\nHelm 3 related work (reporting for Adam): onto the Helm 3 loading and rendering logic\nIn-memory tree structure is structured rather than flat\nLua side (Brian): the core engine is about halfway there, working on Lua 5.3 support\nMatt Fisher\nMostly issue queue and release management\nShould the issue go in RC4 or are we good to go with 2.10.0?\nAdnan\nChanges to Monocular with the hub stuff\nNikhil\nOut last week. Getting back into things.\nMichelle\nMainly responding to GitHub issues\nWill respond to comments on test proposal in the helm/community repo this week\nJosh\nPR out for ChartMuseum bearer auth\nExploring approaches for values management\nShould we add ChartMuseum API for fetching/saving value sets?\nAllow for diff key-value backends (Consul, Vault)\n“helm config” plugin that works with API described above to fetch value sets and save the to .yaml file prior to helm install\nGoing to get involved in specs repo as it relates to helm push, helm login\nChartMuseum website coming soon - can we open source it under helm org?\nDemo\nCharthub (Paul Czarkowski)\nEasy way to host chart-repos using GitHub releases.\n[Adnan] may be interesting to use this as the base for the “github bot”\nDiscussion\nLonger meeting? Should we start 30 min earlier?\nAre we letting meetings run long because we don’t do well time-boxing items, or do we just have a lot of agenda items.\nThere seems to be more material to discuss. With Helm 3 and the hub, there is more “stuff” to discuss.\nShould https://github.com/helm/helm/pull/4473 be thrown into the release branch and cut rc.4, or cut v2.10.0 without it?\n[Taylor] would prefer to see a 2.10.1 with this fix in it\n[Fisher] would like to cut a 2.10.0 today\nAssignments\nModerator: Farina\nNotes: Fisher\nSherpa: Butcher\n\nAugust 9, 2018\nAnnouncements\nHelm v2.10.0-rc.3 was released yesterday\nStandup\nButcher\nStaying on top of issues\nResearch for Helm v3 command line UX, PR in helm/community repo\nSuggested a few edits\nSee doc for analysis\nTurning attention back to governance. There is a draft out there.\nLooking at Lua things\nBrian Hardock\nBuilding a Lua implementation for Helm v3\nFocused on the virtual machine / interpreter for Lua and writing the backend\nHad conversations on design with Butcher\nFisher\nMajority of work has been related to the release candidate\nHelm issue #1968 - meta issue on the build system and the infrastructure around it\nModerate discussion on building helm for different architectures\nContinuing work on release candidate and watching for regression and going forward with that process\nTaylor\nClearing out the PR queue as much as possible\nContinuing clearing out the PRs\nWe are not currently accepting PRs against the helm3-dev branch\nThere is a massive internal core refactor which is why we’re holding off on merging any PRs (Farina)\nFarina\nKubernetes came out with recommended labels similar to our own and did a PR to update our docs with that\nFollowing up on governance related items\nFollowing up on charts\n\nAdnan\nGetting next release of KubeApps.com out\nAdam\nHeads down on refactor work for v3. Close to having the public API part down for helm v3.\nWatching for feedback on the PR for supporting kubernetes 1.11 work\n(Taylor) Doing more testing against AKS right now\nVic\nPlugging back in\nWill work on Kubernetes 1.11 verification\nWorking on figuring out how to ease use cases observed and pain points from helm 3\nMichelle\nReviewed a bunch of PRs, especially patches for release candidate\nPR’ed helm test plan/proposal for helm v3\nReviewing long term governance plan\nJosh\nAdded Helm 3 proposal for helm push\nTrying to tackle repo authentication design w/ Farina and friends\nHelm-push plugin updates (Harbor project etc)\nCNCF Webinar w Stef! https://www.youtube.com/watch?v=u3VqswB-TJo&feature=youtu.be\nDiscussion\nHow are the changes/testing coming along for kubernetes 1.11 support? Where do we need more help? (michelle)\nComing along well. Adam already updated.\nPlease help if you can.\nSpecs repo, helm push/login\nClear specification for authentication and uploads by default\nChartMuseum will be responsible for implementing this spec, but others can BYO-API\nHow do we does the auths\nWill pull in JFrog and some other people for their experience\n(Matt Farina): Would like to get the specs repo moving. Being voted on now. Especially important for distributed search.\nHub update? Is there any movement on putting forth a monocular instance to start the hub\n(Farina): yes there is movement\nNeed to find location where it will be hosted\nCNCF has a bare metal as a service option\nFew other ways we can go between sponsored hosting from a company or through the CNCF\nFarina is chasing down funding\nGuidelines for inclusion\nWhat guidelines should be there to be included\nReinhard (chart maintainer) is working on this\nCNCF will look at this as well\nAdnan will also help because Bitnami has experience in managing chart repositories\nThere was an email sent out to the maintainers to figure out a name\nAdnan has been looking into resource requirements for hosting monocular\nVery little resources required\nGuides about creating your own repositories\nStarted with how to host your repo on GitHub\nKey focus on documentation\nThis is distributed search not proxying for repos\nFirst version will be a monocular instance and we will improve from there\nAssignments\nIssue Sherpa: Matt Fisher\nNotes: Josh Dolitsky\nModerator: Taylor\n\nAugust 2, 2018\nAnnouncements\nHelm RC2 was released earlier this week. RC\nStandup\nNikhil\nGetting back from an internal all-hands\nWill be testing out the release candidates\nAdam\nOpened 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\nOther Helm3 stuff\nBrian\nLUA stuff for Helm3\nFisher\nMaking sure helm2 RCs are going through, move along the 2.10 cycle\nPaired with Adam for the k8s 1.11 support.\nKeep moving through the RC2 => RC3, but has already been approved, just needs merge.\nJustin\nSome issue triage this week\nButcher\nOn vacation last week\nGetting close on the Helm Governance Proposal -- should have something on the next couple of weeks. (deadline in Sept)\nWorking with Ronan to get various helm accounts shifted over to CNCF\nItem 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\nAdnan\nWorking with Scott Rigby to figure out how to make standing up distributed chart repos as easy as possible.\nMore on this soon\nDiscussion\nUpdate strategy in helm v3. See issue #3805 (michelle)\nAdam’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.\n`--strict` flag on `helm repo update` to return non-zero exit code on failure PR #4348\n<Hard to figure context on this, so let’s discuss in helm-dev>\nRelease Helm 2.10.0 today after merging PR #4364? (fisher)\nAlready discussed cutting an RC3 before doing a 2.10.0\nRelease without Adam’s patch for k8s 1.11. Doing so would break semver, so we shouldn’t do this.\nProposal to port GoFish as a Helm 3 plugin manager (fisher)\nhttps://github.com/helm/community/blob/master/helm-v3/005-plugins.md\nIs the community repo the right place for this?\nYes!\nWhen 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?\nYes\nhttps://github.com/kubernetes/kubernetes/labels/priority%2Fawaiting-more-evidence\nHelm v3 update:\nOngoing work on the LUA engine\nProposals in helm/community are flowing, will spend some time next couple of weeks going through them.\nNo definitive ETA yet, but it would be nice to be able to show some of the newer features during KubeCon\n(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.\n\n\nJuly 26, 2018\nAnnouncements\nFinally finished move of all the helm repos to the Helm org\nDistributed search proposal passed with a majority of votes\nVoted Rimus (sp?) as an emeritus member\nStandup\nButcher\nIssue sherpa trying to stay on top of issue queue\nMerged PRs -- were a couple of features\nHelm 3 design LUA stuff with Brian\nAdam\nBeen working on getting the 1.11 kubernetes support ready\nJosh\nBeen trying to keep up with email list\nBeen a lot of activity around repo discussions:\nTaylor\nVacation\nWorking on PR stuff tomorrow\nJustin\nWas at vacation\nGetting back into the flow of things\nFarina:\nNeed to figure out logistics of moving from CLA to DCO\nWhen 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.\nWorking on update notifications -- how to tell folks that they have a helm update for them.\nDiscussion\nCan folks (non core-maintainers) add/remove labels on the helm/helm repo right now? (michelle)\nNon-core shouldn’t have access to do this.\nThere 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.\nHelm proposals\nInstalling custom plugin sets:\n(Taylor) Two thumbs up\nHow do we do version handling? How do we discover the version.\n(Butcher) It might be good to not even handle versions for a first pass\nHelm v2 repositories\nhttps://github.com/helm/community/pull/27\nTwo file approach -- idea is to do this to improve performance so that we’re able to do a lazy fetch\nIf you use a relative URL, don’t you lose context of the base URL?\nIf you have it in more than one URL the relative URL works across http / https.\nAre 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).\nWe might want to change it from “latest” to “stable” to address this\nImproved signing\nhttps://github.com/helm/community/pull/20\nGenerate 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.\nMain thing here is whether storing the public key is okay to store in the charts or not.\nWe don’t need to take an external dependency on GPG -- go already has libs that we use (already in the code).\nUpdate notifications\n<Punted to the next meeting in the interest of time>\nStale issue automation\n<Punted to the next meeting in the interest of time>\nAssignments\nIssue Sherpa: Justin\nNotes: Nikhil\nModerator: Butcher\n\nJuly 19, 2018\nAnnouncements\nNeed helm doing some research into possible bugs from the issue queue. If you have time today, please reach out to Michelle\nAccelerated move to Helm org (github.com/helm/helm)\nStill having some CLA/CicleCI issues\nSeems like it might be an issue with CLA-Bot\nStandup:\n<Skipping standup so that we can devote some talking about the Governance changes>\nDiscussion\nGovernance\nMatt Farina's proposal for a new governance structure\nhttps://hackmd.io/s/B1BksVYW7#\nBootstrapping process for project maintainer elections\nStill need to figure out how to do this fairly and equally\nProject maintainers need to be codebase maintainers\nA codebase maintainer may not want to/be suitable to be a project maintainer\nCodebase maintainers have skin in the game and care about the project direction\nCodebase 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\nExperience matters here, want ideas and psychology to bubble up to project maintainership\nDon't want to end up with top-down maintainership\nSub-projects have a lot of freedom in adding maintainers - simple majority vote\nAction: Make it more explicit that codebase maintainers don't need to be software engineers\nOkay to have an even number of project maintainers for a short amount of time, if someone steps down before replacement found\nMaintainers only removed if they become unresponsive\nBootstrapping project maintainers\nDifferent weights for different projects?\nGhost period for code maintainers should be shorter?\nSet an upper limit, but let codebases choose lower limits if desired\nCNCF CoC - email contact in the CoC doc\nBetter nomenclature for project & codebase maintainers - repo & org maintainers?\nChartmuseum\nUI\nOrgs and Authz\nAssignments\nIssue Sherpa: Butcher\nNotes: Nikhil\nModerator: Fisher\n\nJuly 12, 2018\nAnnouncements\n<None>\nStandup\nTaylor:\nGetting back into doing Helm stuff.\nDigging into PRs and notifications\nThen looking into Helm 3 stuff\nAdnan:\nDiscussions around charts - especially distributed repository proposal.\nThere were some ideas in the charts call this week which is recorded.\nMore conversations with Scott Rigby\nWork with Kube CRD and Tiller Proxy\nNikhil:\nNot much going on with Helm this last week\nJust touching base with issue comments and PRs\nMichelle:\nKnowledge transfer with Adam on the changes for k8s 1.11\nWorking 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\nBrian:\nFix the 1.10 RC for helm list,\nLooking into the TLS security support question. Turned out to be a documentation issue\nFarina:\nNotifications: Working on how we can notify people when new versions of Helm are out. Using mini-kube as a model for this.\nVerification work with the proxy (using kubeapps model). This is interesting especially with the multi-tiller approach that most people use.\nLots of emails around governance\nDiscussion\nMoving docs [Matt Farina]\nDocs repo?\nCurrently docs live in the helm repo itself.\nWould be nice to add translation, etc.\nKeeping this in mind does it make sense to move docs to their own repo?\nMarkdown vs Asciidoc:\nConversation with a few other folks about this:\nMarkdown is more popular, asciidoc is more technical?\nThere are tools that can switch between the two.\nExample of kube-builder http://book.kubebuilder.io\nNice to be able to do side-by-side code and docs.\nBuilt in i18n with gitbook\n[Taylor]: In support of moving the docs to own repo\n[Michelle] Helm v2 vs v3 docs -- will they live in the same repo in different directories?\nDocker compose does a good job of splitting out the docs for different versions.\nGitbook vs other tool? https://github.com/kubernetes/helm/issues/4100\nMulti-lingual\nK8s recommended labels. Do we switch? When? https://github.com/kubernetes/website/pull/8703 [Matt Farina]\nHelm has standard labels, almost one:one with the ones listed here, but having different names.\nWhat is the best way to proceed here?\nAdding annotations makes sense, but labels changes people’s deployments so the change is more intensive.\nGovernance esp w.r.t related projects:\nSeparation of concerns project maintainers vs. codebase maintainers\nCNCF 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.\nAssignments\nIssue sherpa: Michelle\nNotes: Adnan\nMeeting Moderator: Nikhil\nJuly 5, 2018\nAnnouncements\nDevoting time to discussion, skipping standups\nDiscussion\nDiscussion on k8s 1.11 support for Helm\nUpdate on current state of k8s 1.11 backwards incompatibilities\nGenerated Go code in k8s/k8s has been removed, making it unusable as a package: https://github.com/kubernetes/kubernetes/pull/62432\nRemoved the client-side reaper in favour of the server-side reaper. Because Helm prior releases, we need that for 1.10 support\nThe entire factory/builder packages in kubernetes/kubernetes were rewritten and are totally different between 1.10 and 1.11\nThe printer was rewritten and requires significant refactoring\nProposal (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\nAnother option: remove k8s/k8s as a dependency, and vendor the k8s 1.10 code directly into Helm 2 as a crutch\nApparently service catalog has already gone with this approach\nButcher: (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\nAdam: ok, I can go take a look at forking kubernetes/kubernetes so we have the packages for handling backwards compatibility\nFarina: I’m going to take these issues up to SIG Architecture and SIG Release\nMichelle (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?\nFarina: on the agenda for next SIG Apps\nFisher: Do we want to have a strategy for communication with the community for this? Farina: Better to over-communicate than under.\nAdam: Go/no-go by end of the week. Farina: based on this we can craft some messaging to the community next week.\nAssignments\nIssue sherpa: Justin\nNotes: Nikhil\nMeeting Moderator: Michelle\nJune 28, 2018\nAnnouncements\nv2.10.0-rc.1 released\nStandup\nJustin:\nIssue Sherpaing\nWorking on CRD issue\nAdam:\nReleased v2.10.0-rc1\nStill been working on some of the Helm 3 stuff\nPairing with Brian on some things to help through some of the design choices\nWorking 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\nBrian:\nPaired with Adam, and I loved it!\nJosh:\nNothing to report\nAdnan:\nNothing to report\nMatt Fisher:\nOn vacation last week\nTesting RC.1\nDiscussion\nKubernetes v1.11 support\nAssignments:\nIssue sherpa: Justin\nNotes: Matt Fisher\nMeeting Moderator: Adam\n\nJune 21, 2018\nAnnouncements\n<None this week>\nStandup\nNikhil:\nIssue sherpa last week - support related things\nTalk about cutting a new release?\nMatt Farina:\nMigration to Helm org\nMichelle opened up an issue moving from CLA to DCO that needs follow up.\nSome 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.\nAdam:\nOut sick last week.\nBeing pulled into other things since Butcher’s out.\nHelping with Helm 3 refactoring\nFisher:\nIssue queue + triage\nHad a good session with Nik helping with Issue Sherpa handoff, and process regarding labels while sherpa’ing\nJosh Dolitsky\nKeeping up with all the stuff Matt Farina’s been posting with distributed search\nWants a heads up on any CNCF stuff going on\nFarina mentioned about copyright headers\nQuestion: is there any hold-up on moving to the github org\nFarina: one hold-up is the Linux CLA bot hasn’t; once it’s fixed we can start moving over\nAdnan\nBeen looking over the distributed search proposal and the application CRD\nJustin Scott\nBeen heads down on internal projects, LGTM’d a few PRs\nDiscussion\nNext helm release?\nTalk about cutting a helm 2.10 with the changes present in master\nK8s 1.11 client APIs broke a lot of things from initial testing\nCome up with an announcement on the helm-users mailing list on if we’re adding 1.11 support\nHelm 3 tickets\nThere’s been a few tickets raised on Helm 3 topics; are we ready for these?\nAnswer: no, redirect users to #helm-dev or the helm/community proposals at this point\nThings are expected to break (and break often); we’re not ready feedback until the first alpha release\nZoom issues - people on hold?\nThe meeting moderator now needed to allow folks explicitly into the meeting, and folks are on hold until the moderator allows them in\nFarina: 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.\nIt 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.\nAssignments:\nIssue sherpa: Justin\nNotes: Adam\nMeeting Moderator: Fisher\n\nJune 14, 2018\nAnnouncements\n<None this week>\nStandup\nFisher:\nWas at offsite last week\nWorking mostly on Issue queue / PRs\nFix for: https://github.com/kubernetes/helm/pull/4146\nAdnan:\nNeed to check out Helm v3, and got feedback on Helm CNCF move\nAt DockerCon this week\nNikhil\nTaking a look at the helm 3 branch, looking at particular the lua stuff\nAdam\nOut for last couple of weeks\nLooking into some pieces of helm that weren’t touched before (requirements)\nNeed to look at treatment of Helm subcharts internally (needed for LUA)\nButcher\nPairing with Adam on the tech side for Helm v3 -- taking a deep pass through the lower code base before building the upper layers\nWill be out next couple of weeks (including at ContainerCon China)\nCNCF 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:\nHelm\nCharts\nChart testing tools\nChartMusuem\nEveryday conversation will stay in Kubernetes Slack.\nWill be running an article in https://sweetcode.io/ on Helm 3\nTaylor\nNot much on Helm, mostly working on AKS GA\nHope to jump back in after next couple of weeks\nDiscussion\nHow can we better manage issue triaging with the issue queue getting so large?\nSomething that came up last week. Currently ~400 issues, ~90 open PRs. What’s our level of priority for issues / PRs coming in.\n4 categories: Bugs, Support Tickets, Features, Whatever else?\n59 open bugs (most are fairly low pri), but there are a couple of high pri ones\nThought is: make handling bugs as P1 for issue sherpas since it’s hard to focus on everything.\n(Adam) Another idea: talk about high-pri bugs during meeting.\nCharts distributed repo proposal - please leave feedback https://github.com/kubernetes-helm/community/pull/24\n\nAssignments\nIssue sherpa: Nikhil\nNotes: Fisher\nMeeting moderator: Adnan\nJune 7, 2018\nAnnouncements\n<None this week>\nStandup\nTaylor:\nNot much this week\nDiscovered issue with --wait\nNikhil\nIssue sherpa, spent some time on some issues and looked into a few PRs\nAdnan\nPlan to take a look at the Helm v3 branch, and the canary\nNot much else apart from that\nDiscussion\nStef: Issue with “Connection Reset” caused by difference of versions between Helm and Tiller\nAssignments\nNotes: Taylor\nMeeting Moderator: Nikhil\nIssue Sherpa: Fisher\n\nMay 31, 2018\nAnnouncements\n<None this week>\nStandup\nMatt Fisher\nIssue triage + PR\nSome windows related stuff\nBrian\nNothing to report\nTaylor\nTrying to make time to fix the helm wait stuff\nJustin\nNothing to report\nNikhil\nStarted pulling down on the dev-v3 branch and making his way through the branch to see what’s changed\nAdnan\nInterested to see what’s going on in the dev-v3 branch, otherwise working on other work\nMatt Farina\nWorked on the helm proposal to the CNCF, fair amount of discussion going on in that PR. Discussion is still ongoing\nThe community charts sync broke due to a breaking change in the system\nFixed by using CircleCI rather than Jenkins thanks with help by Adnan\nDiscussion:\nFolks are in summer mode! Not much tabled to discuss this week.\nAssignments\nModerator: Taylor Thomas\nIssue Sherpa: Nikhil\nNote taking: Matt Fisher\nMay 24, 2018\nAnnouncements\nHelm and CNCF [Matt Farina]\nAfter 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.\nStandup\nTaylor:\nNot much, mostly working on the wait-flag stuff\nMight be busy over the next couple of weeks\nAdam\nWorking on Helm 3 stuff\nTrying to split up the tight coupling of templating and resources\nNext week on vacation\nNikhil\nMostly out last week, getting back into the swing of things this week\nButcher\nPR on the LUA stuff for Helm 3 (Core event handler)\nTalked with Adam about things like helm install which has grown organically -- so we need to do a little ‘topiary’.\nJdolitsky\nManaged Helm Repos\nWe also now have auth for ChartMuseum using a bearer-token in the header\nWorked on helm-push/helm-login/performance of index.yaml\nFarina\nHappy to take on the proposal of the index.yaml\nStarting to poke at i18n, filed a few issues against doc, i18n, etc. Looking into finding a framework to do the translation.\nFisher\nMostly on vacation last week - got back this week\nHoping to take a look at Helm3 discussions and get involved with that this week\nDiscussion\n(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.\nJosh Demo https://github.com/chartmuseum/helm-push\nAssignments\nIssue Maharaj\nButcher\nNotes\nFisher\nMeeting Moderator\nNikhil\nMay 17, 2018\nAnnouncements\nHelm and CNCF [Matt Farina]\nStandup\nTaylor\nDebug --wait flag\nOpened PR for release process\nNikhil\nIssue sherpa duty\nFisher\nVacation\nDefining first issues with Farina\nAdam\nHelm3 refactoring\nReview PR’s\nMichelle\nReview PR’s\nButcher:\nVacation\nPR reviews with Adam\nPR for CRD support in helm2\nFarina\nLooking into making chart repo more distributed\nLanguage support for helm\nDemo\nJosh with Chartmuseum\nDiscussion\nKubernetes Apps Survey Results for Helm [Matt Farina]\nIssues with the wait flag [Taylor]\nAssignments\nIssue/PR sherpa:\nMichelle\nNotes\nNikhil\nMeeting Moderator\nFisher\n\nMay 10, 2018\nAnnouncements\n3.0 dev branch is sorta open but in code cleanup phase\nCodefresh just announced managed Helm repos -- awesome!\nStandup\nNikhil\nHas not done much in the last week\nVolunteered to do issue/pr sherpa\nReviewed oauth work with Josh\nAdam\nHolding fort when folks were at KubeCon\nFocusing on Helm3 stuff with refactoring\nFarina\nDigging into the charts craziness\nAlmost 300 open PRs\nAdded a discussion topic to figure out how we can manage some of this craziness\nHope to chat with Josh and present a PR to help with this\nButcher\nPicked up some of the Issue Sherpa this week\nAt KubeCon -- spoke to a few Chart maintainers to talk about some of the alternatives to what we have  currently.\nPropose people interested in this problem, meet up during Chart Office Hours (next week on Tuesday?)\nOpen PRs for CRDs that needs reviews -- might need to pair with someone\nHas a POC for LUA scripting for Helm v3\nTaylor\nProposal idea for how we want to do releases\nLooking into PR templates / Issue Templates\nDiscussion\nProposal idea for how we want to do releases [JTT]\nThe dev call after the release is the next (bootstrap) call for the next release.\nEach 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.\nIs this adding unnecessary process which will be overhead for us?\nTaylor will write up the process and make a PR to Helm to kick off more discussion for next week.\nDistributed charts vs central hosting vs a combo [Matt Farina]\nCharts Office Hours are at 9am PST 10 am Mountain on Tuesdays\nWhole 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.\nPHP 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.\nMore discussion next week\nThat _is_ a different project, so technically they would make a decision on this, but we should weigh-in during Charts office hours\nAssignments\nIssue/PR sherpa:\nNikhil\nNotes:\nAdam\nMeeting Moderator:\nTaylor\n\nMay 4, 2018\nCanceled due to KubeCon\n\nApril 26, 2018 [recording]\nAnnouncements\nHelm 2.9.0-rc5 was released last afternoon\nHelm dev call canceled for next week\nStandup\nAdam\nBeen doing work on Helm 3 refactoring, pulling out gRPC and old commands we had\nPaired with Fisher on some bugs for the Helm 2 release and issues upon request\nTaylor\nHaven’t done much, switched over to Microsoft so have been onboarding onto his team over there\nMatt Farina\nBeen looking onto the community charts scalability problem\nLooking into chart repository scalability issues, like switching to JSON for index files\nMight have stronger opinions after KubeCon\nMatt Butcher\nBeen issue sherpa this week, triaging issues for Helm 2\nPairing with Adam on Helm 3 stuff\nAutomated helm.sh and docs.helm.sh this week\nHave a couple items to work on for the Helm 3 spec doc while in Copenhagen\nJustin Scott\nIssue triaging\nIdentified an issue around import-values, will look further into the ticket\nMichelle\nBeen travelling this week\nMatt Fisher\nBeen cutting release candidates as needed this week\nWant to cut a 2.9.0 by the end of this week, but we should probably discuss this\nDemo\nJosh with push to chartmuseum\nDiscussion\nHelm material from Kubernetes Apps Survey\nMore Helm Maintainers for the issue queue?\nShould we cut Helm 2.9.0 prior to KubeCon?\nTesting coverage (Adam)\nAssignments\nIssue Sherpa\nAdam Reese, party of 1\nPR Sherpas\nAdam Reese, party of 1\nNotes\nMatt Farina (for the week after KubeCon)\nModerator\nMatt Fisher (for the week after KubeCon)\nApril 19, 2018 [recording]\nAnnouncements\nApplication survey date extended until Monday - https://docs.google.com/forms/d/e/1FAIpQLSeetP_EnzMjAayR73sbpHDtfxnAzT6Y0wzCCvrP4C1uLa1u0Q/viewform\n\nStandup\nMichelle\nIssue sherpaing and fixing bugs\nMatt Fisher\nWorked on fixing bugs\nThere’s a PR to add flags to pkg that was merged and then reverted because it broke compatibility\nWorking on getting RC4 out and fixing bugs to do that\nNikhil\nDidn’t do much Helm related this week\nFarina\nNot much directly related with Helm\nIf 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.\nButcher\nReviewing PRs for Helm 2\nOne PR open on spec for Helm 3 around on security\nGoing to proposes changes to where releases are stored\nAdam\nA few patches in for the RCs\nWorking on Helm 3 looking to factor out gRPC and remove tiller binary\nLooking for feature parity with a single binary\nBrian\nPaired with Adam on helm 3 refactor\nJosh Dolitsky\nBuilt a plugin for chartmuseum push\nDiscussion\nIssue Sherpa’ing with a second person was really good -- maybe we should institute a buddy system\nWhen do we open up ‘the branch’ (referring to v3 branch)?\nFew things to consider - How to handle feature requests coming in.\nBugfixes, 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)\nHow / when do we define a freeze for Helm v2 features?\nLots of folks still using Helm 2\n(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?\n(Michelle) Some folks might want to continue with Helm v2 and not Helm v3.\nAdam is pointing out concern for the end user vs concern for contributors.\nMichelle 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\n“1. Window for getting in feature requests before the v3 requirement\n2. Labeling features in Helm 2 that we need to forward-port, so we can track those”\nIssue sherpas can respond to Helm 3 branch PR requests appropriately.\nLet’s schedule Josh’s demo for next week, for lack of time.\nAssignments\nIssue Sherpa:\nMatt Butcher\nPR Sherpas:\n\n\nNotes:\nFisher\nModerator:\nMichelle Noorali\n\nApril 12, 2018 [recording]\nAnnouncements\nApplication Survey https://docs.google.com/forms/d/e/1FAIpQLSeetP_EnzMjAayR73sbpHDtfxnAzT6Y0wzCCvrP4C1uLa1u0Q/viewform\nAll results will be publicly available\nStandup\nTaylor\nReviewing PRs\nStill need some help reviewing PRs\nJustin\nPut some labels on issues\nMatt Fisher\nWorking on release\nInflux of stuff coming in which is great because we’re getting feedback on release candidates\nIssue sherpa - aggressively closing issues\nCommon issues with bare metal clusters. Maybe there is something address in upstream Kubernetes documentation\nStill triaging issues for bugs related to RC\nMatt Butcher\nOperating Kubernetes clusters with aid from hat\nSome light reviewing on PRs\nAdded 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.\nAdam Reese\nSick.\nWorking on PoC work around Helm 3 proposal.\nLooking at how to refactor out some gRPC stuff to make easier transition to client only architecture\nMichelle\nFollowing up on issues\nSent request in for\nBrian Hardock\nNot too much\nMatt Farina\nComparing memory allocation of YAML/JSON parsers\nTLDR; we’re using the worst.\nWill post result\nMight be worthwhile looking at a better YAML parser\nTLDR from chat; Matt Farina is a nerd and everyone loves it\nJosh Dolitsky\nJWT validation in chart museum working\nHelm push plugin working on oauth flow\nDiscussion\nRC 4 from master? (Fisher)\nLots of activity has happened since the release of the first  2.9.0 RC\nThere’s a lot of features released in there\nShould we cut from master with changes included and features or should we continue to cherry-pick?\nAdam: let’s follow semver\nMatt Farina: we have lots of silent users so let’s now throw them off\nMichelle: Agree with Adam and cool with doing a quick 2.10 release with new features\nTaylor: If people want the latest, they can use canary\nIn agreement on how to go forward. Cherry-pick and no new features.\nAction Item: Let’s make that clearer in documentation either in FAQ or CONTRIBUTING.md\nAssignments\nIssue Sherpa:\nMichelle Noorali\nPR Sherpas:\nMatt Fisher\npart-time sherpas\nMatt Butcher\nTaylor Thomas\nAdam Reese\nNotes:\nMatt Farina\nModerator:\nAdam Reese\n\nApril 5, 2018\nAnnouncements\nThe AppDef WG has put out a survey at https://docs.google.com/forms/d/e/1FAIpQLSeetP_EnzMjAayR73sbpHDtfxnAzT6Y0wzCCvrP4C1uLa1u0Q/viewform\nHelm 2.9.0 rc1 and rc2 were released this week (thanks Farina and Fisher!). The notification\nStandup\nTaylor\nPRs this week -- trying to get stuff merged\nWe now have a release branch, so we don’t need to wait for the RC cycle to be done\nMichelle\nWas issue sherpa this week, mostly just triaging issues and fixing bugs\nHave several items for discussion at the end of this call\nNikhil\nCouple good convos with Josh on ChartMuseum auth stuff\nAdnan\nPass\nFisher\nTriaging issues, helping out with release\nCouple of bugs with the release checklist. Opened an issue yesterday to look into.\nIf there is an issue that needs to be picked into a release, please use the ‘needs-pick’ tag where x is the release.\nJosh\nNew chartmuseum release this week. 0.5.1 which lets you serve multiple chartmuseum repos\nPutting together notes on helm push as next steps\nDiscussion\nHow do we respond to semver issues like this (Michelle)\nIf you use the kubeversion field and you have a constraint like >=1.8.0 this becomes incompatible with GKE’s versioning.\nHow do we respond / have we responded to these kinds of issues in the past.\nOne 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)\nThere 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)\n(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.\n(Fisher) It would be nice to make the community a bit more self-sustainable. Fully agree with prioritizing PRs over issue queue.\n(Michelle) Do we want to have a dedicated person looking at PRs?\nTaylor volunteered, but was decided not to make it a formal role just yet.\nVote on combined maintainers mailing list here (Michelle)\nTwo options right now (suggestions welcome!):\ncharts-and-helm-maintainers@lists.cncf.io\nhelm-cartographers@lists.cncf.io\n(Adnan) Discussion on charts collecting analytics - https://github.com/kubernetes/charts/issues/4697\nHeads up that this discussion is happening - folks interested please join in at the next charts call where this will probably come up.\n(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.\n(Fisher) It would be nice to make it blatantly obvious that we were turning on analytics (eg. homebrew, etc.).\n(Kensey) CoreOS has one flag for all projects to turn off analytics -- would be good to standardize\nAssignments\nIssue Sherpa:\nMatt Fisher\nPR Sherpas:\nTaylor\nNikhil\nNotes:\nMichelle\nModerator:\nTaylor\n\nMarch 29, 2018\nAnnouncements\nBacongobbler: Adam, Michelle, Fisher tested Kubernetes 1.10, so it is merged. When should we cut the Helm 2.9 release?\nStandup\nAdam:\nI am going to miss standup, my 2 updates: merged kube 1.10 support and worked on a POC of the helm3 ext model.\nAs always, dont trust anything @mattfarina says about me\nMichelle:\nTesting of 1.10\nInvestigating another issue #3655\nNik:\nLooking at Docker Registry token format for registry planning for Chart Museum\nInvestigating how PIP/pypy do things (and launchpad)\nJustin:\nHelm issue queue triaging\nButcher\nHelm v3 work + prototyping with Adam\nEmbedding LUA, eliminating grpc -- get clear on some of the areas for the Helm v3 proposal\nTaylor\nWorking on a few PRs this week\nMatt Farina\nHelm Survey for end users\nAdnan\nCharts work on owners/maintainers\nCheck if any chart maintainers want to go emeritus\nBrian Hardock\nFix on Helm List due to gRPC threshold, working on tests now\nMatt Fisher\nTesting 1.10 and issue triaging\n Also a little Lua experimentation just to get comfortable with embedding Lua in Go\nDiscussion\nWhat do we want to name the mailing list for both charts maintainers and helm maintainers? Is it public or private? [Michelle]\nThink about this one, we can decide further next week.\nCNCF landscape [Matt Farina]\nUploaders for Plugins [Josh D]\nHow to implement ‘helm push’\nFarina: I was thinking of doing it over http/https downloaders, so that plugins can implement custom push uploaders.\nJosh: See #18 on the community repo, which could also provide indexers to tackle search scale issues, maybe others.\nFarina: 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.\nJosh: Maybe make chart museum method the default, and allow plugins to override\nFisher: jFrog is also interested, maybe in basic auth because that’s the only available kind\nFarina: Maybe we should ship with oauth support and token auth too\nJosh: What if we don’t have a default implementation?\nCall for next Monday after sig apps: https://calendar.google.com/event?action=TEMPLATE&tmeid=NDA3a2NsbzlxaWdpcnNuMm41NzNsdnFqaDggY29kZWZyZXNoLmlvX3BmbmlqajVrbjFmYzhqMnJtMXYwbWJoaTIwQGc&tmsrc=codefresh.io_pfnijj5kn1fc8j2rm1v0mbhi20%40group.calendar.google.com\nTODO: Schedule call -- Josh Dolitsky\nBranch naming for Helm 3 [Butcher]\nTentative plan is to have a place for Helm v3 code to land prior to KubeCon EU (beginning of May).\nWe 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.\nNormal weekday 150 - 180 unique cloners.\nPoints to not breaking master and leaving as is. => v3 code should live in a different branch.\n‘v3’ is as good a name as any for the branch name.\nFarina: We should think about how the branch name plays with dependency management tools like glide, dep, etc.\nButcher: Maybe we should do something like dev-v3.\nLots 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.\nAssignments\nIssue Sherpa: Michelle Noorali\nNotes: Nikhil\nModerator: Taylor\n\nMarch 22, 2018\nAnnouncements\nHelm v3 discussions are making progress.\nStandup\nAdam:\nBeen working on 1.10 support for Helm. This is now tested.\nWorked on vetting LUA models with Butcher.\nFisher:\nPushing through the JFrog remote authentication support for Helm -- that’s done.\nMostly issue triage in addition to that\nTaylor:\nWas a bit busy this week.\nWill take on some more PRs from the PR queue this week -- keep an eye out for reviews especially on mediums and larges.\nGoing to start trying to look at\nJustin\nBeen pretty busy, so mostly been some issue triaging.\nMaybe talk about some regressions that have been creeping up with Helm.\nButcher\nMostly focused on Helm 3\nBroke the document out into smaller proposals\nBacked 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\nAlso 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.\nAlso simplified the event model this week.\nWill keep working at that this week.\nFarina\nSome more of the Helm 3 stuff\nWorking on charts -- merged a couple of features upstream wrt better validation of files, linting, etc.\nNikhil\nMoved ChartMuseum to dep\nLooked at a few PRs and the issue queue.\nPlan to work on some of the repo auth pieces this next week.\nDiscussion\n(Josh) Helm repo proposal:\nhttps://github.com/kubernetes-helm/community/pull/18\nhttps://github.com/jdolitsky/community/blob/ebf12b58dec108f85c582369d937100d591f7cdc/helm-v3/006-repositories.md\nMethods for authentication -- suggestion to add a helm config for authentication\n(Fisher) Have we looked at different authentication models eg. pypi authentication for pip packages?\nAnother thing to think about is being able to auth against different repos.\nThis has ramifications on helm search -- you would not be able to search against multiple repos.\nDo 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.\nThis has similarities with search with pypi -- might be useful to take a look at them too.\nDuring 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.\n (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.\n(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.\n(Josh) Demo for ChartMuseum multi-tenancy\nAssignments\nIssue Sherpa: Justin\nNotes: Butcher\nModerator: Fisher\n\nMarch 15, 2018\nAnnouncements\nWe had a v2.8.2 release go out last week\n\n\nStandup\nMatt Fisher\nHelm issue queue stuff\nGot a repro for a Helm rollback issue that he’s helping to track down\nNikhil\nSpent time looking through the Helm 3 proposal\nHelm issue queue stuff\nMatt Farina\nWorking on the Helm 3 User Stories and User Profile docs\nAdnan\nReviewing the Helm 3 proposal, user stories\nTaylor\nIssue sherpa for this week\nQuestion about --reuse-values and its intended behaviour\nhttps://github.com/kubernetes/helm/issues/3685\nJustin\nOut for a week travelling\nTaking a look at the Helm 3 proposal\nMatt Butcher\nMerged stuff on emeritus core maintainers\nAddressing comments on the Helm 3 proposal, moving progress along\nPlan for the next week is to help move the Helm 3 stuff along\nKensey\nasked https://github.com/kubernetes/charts/issues/4067 for best practices on networking best practices\nDiscussion\nMatt 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\nHelm 3 Proposal\nhttps://hackmd.io/YvQCGazPRNanSugJV-rbSg\nProposing a client-only model, tiller is gone\nInternally, Helm will be restructured around events\nAdam mentions notes about Lua\nLua is the easiest to embed\nBrian Grant asks if they’ve looked at alternatives like Skylark\nHave 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\nOne appendix is to propose using the Lua engine for Helm plugins\nInclude a `helm push` verb to push helm charts to a repository\nTalking to Josh Dolitsky and the ChartMuseum team on defining the spec for `helm push`\nFarina 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\nNext steps: how to break this up into sizeable chunks/proposals\nThrow in a milestone?\nMove it to issues?\nDump into enhancement proposals/documentation?\nBrian asks whether development would happen in the main helm repo\nLazy consensus says yes, we should have a 2.x mainline branch and run Helm 3 development on master\nMatt Butcher will publish the Helm 3 proposal in the community repository\nJosh added multi-tenancy to ChartMuseum!\nNot ready for primetime, but available for preview\nAssignments\nIssue Sherpa: Matt Fisher\nNotes: Nikhil\nModerator: Matt Butcher\n\nMarch 8, 2018\nAnnouncements\nAdam 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.\nTaylor gave a brief des\nStandup\nTaylor:\nGoing over the Helm 3 proposal stuff\nBlog post about the Helm Summit\nWill have more time this week for PRs + issues.\nNikhil\nDoing some investigation on how OAuth works so he can propose ideas to chartmuseum and other chart repository work\nSpent some time responding to Issues\nMichelle\nWas at the OSLS for the last few days\nWorking on fetja bot\nNeed to revisit who should join which mailing list -- maybe create a different ML for the chart maintainers. Added Matt admins to the ML.\nFisher\nLast week worked hard on reviewing PRs\nMoving 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!)\nThis week, want to pair with Adam on some of the PRs already in the pipeline.\nRonan 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.\nFarina:\nWorking on getting documentation from the summit together\nThe user profiles have now been documented at https://github.com/kubernetes-helm/community/blob/master/user-profiles.md\nWorking on proposing other documentation from the summit.\nPoking at the Helm v3 proposal as well.\nAdam\nWas issue sherpa this week. Thanks to others who jumped in on that.\nAlso 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).\nWill be pairing to review a couple of hot PRs with Fisher.\nBrian\nPairing with Fisher on the Helm wait stuff with the ping using proto health check specification\n\n\nDiscussion\nTemplating in values.yaml file (see #1978, #2133, #2492, #3252, and https://image.ibb.co/k9Xo07/tpl.png)\nFolks 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?\nIs there a primary use-case for this? The use-cases are documented in the multiple open issues.\nAdam: Maybe comes across as an anti-pattern with\nOne 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?\nOther use case: Want to be able to set a value in values.yaml and use that over and over again, later on.\nTaylor: 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.\nFisher: 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?)\nAdam: 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.\nNext 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.\nReconnect to tiller on transport error (TODO: issue number -- Farina will follow up)\nThere are cases where the connection to tiller gets broken. Experiencing this on chart CI and is an outstanding issue.\nSuggestion: 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.\nAnother option could be to keep the tunnel open.\nDoes grpc have an auto-reconnect that we can use?\nWe see the error in less than a minute on the CI tests so it’s not very long.\nE2e tests (see #2846)\nAdam will take it over -- has already rebased it. A few more things to clean up. Initial rebase (#3636)\nIndex.yaml v2 proposal (#3557)\nFarina: Can we get more eyeballs on this?\nThis goes hand-in-hand with the scaling discussion for chart repositories. Has implications on the growing size of the community charts repositories.\nWe will try and cover this a bit more during the next meeting.\nChartMuseum OAuth discussion: https://github.com/kubernetes-helm/chartmuseum/issues/59\nAssignments\nIssue Sherpa: Taylor with Michelle as assistant to the regional sherpa! :)\nNotes: Fisher\nModerator: Adam\n\nMarch 1, 2018\nAnnouncements\nHelm Summit was awesome last week; nice job everyone!\nThanks to Fisher for closing a massive amount of PRs\nStandup\nFisher:\nPost summit stuff\nReviewing blog post with Taylor\nFollow up with Karen (Microsoft) on post-summit feedback email\nLooked at an merged a whole bunch of PRs (Thanks Fisher!)\nThis week: More PRs + Follow up on Helm 3 discussions, and next steps from notes from the Summit\nTaylor:\nDistilling requirements for Helm 3 from unconference discussions\nShould discuss these requirements in a follow-up meeting\nNikhil:\nIssue sherpa’ing this week\nPost Helm 3 discussions with josh Dolitsky on ChartMuseum multi-tenancy stuff, feedback\nWill have a follow-up discussion with Josh on auth in ChartMuseum\nAdam:\nDid a few PR reviews\nFixed a few bugs with Helm plugins\nUpdated all his plugins\nBucher and Adam got together, writing and sketching a proposal for Helm 3 with a few decision trees, which should be good for discussions\nButcher’s away in Texas this week, so it might not be finished until next week\nJustin:\nPopped in late, talking about triaging issues this week\nProposed an issue template on kubernetes-helm-core for Helm\nLargely positive feedback on the proposal, so Taylor asks about proposing a PR to it\nAsked about Brian Grant’s proposal, which\nDiscussion\nFisher: talk about https://github.com/kubernetes/helm/pull/3437\nAdam explained how upgrading as if it was a fresh install won’t work due to the install being in an unknown state\nFisher agreed\nTaylor proposed perhaps this would be a good feature flag instead? That way users can opt into destructive behaviour\nAdam and Fisher both agreed that would be a good proposal\nAdam will bring some context back into the PR so we can hopefully steer the conversation in that direction\nNikhil: When sherpa’ing, how can we determine which features should be frozen from fejta-bot?\nAdam and Taylor provided context and info on asking questions about older issues on helm-dev\nPairing sessions are great for this!\nNikhil agreed\nAssignments\nIssue Sherpa: Adam\nNotes: Nikhil\nModerator: Taylor?\nFebruary 15, 2018\nAnnouncements\nHelm summit next week! http://helmsummitpdx-feb2018.splashthat.com Get your tickets if you don’t already have them!\n\n\nStandup\nJustin\nMostly issues and PRs\nIs excited(?) to be the AV guy at the summit at 7:30. :) We appreciate the contributions. There will be coffee!\nMatt Butcher\nHelm summit things\nCollecting some feedback on what are currently the most requested features for Helm -- to try and steer the Helm 3 discussion that way.\nWhat is the long term structure / governance model for Helm? Is this something we want to discuss at the summit?\nOpen question: Is it better to lay down (discuss) suggested requirements, rather than dictate solutions for Helm 3?\nMatt Fisher\nMajority of the work was helping out with the Dev summit\nWorking with Ronan? To figure out logistics regarding the summit.\nMichelle\nWorked on reviewing PR (https://github.com/kubernetes/helm/pull/3206) -- is now up for review\nUpdated 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.\nhttps://lists.cncf.io/g/cncf-kubernetes-helm\nhttps://lists.cncf.io/g/cncf-kubernetes-helm-power-users\nhttps://lists.cncf.io/g/cncf-kubernetes-helm-security\nhttps://lists.cncf.io/g/cncf-kubernetes-helm-maintainers\n\n\nAlso working on speaker stuff for Helm summit\n\n\nTaylor\nWorking on Helm summit things -- big shout out to all the folks working on Helm summit items (Michelle, Adam, Fisher, everyone else)\nNikhil\nWorking on updating SUSE’s version of helm along with ChartMuseum\nWorking on his talk for the summit\n(Nikhil: Thanks Fisher for noting this down while I was speaking!)\nAdam\nMore summit stuff\nFocused on summit talks and speaker work items\nBrian Hardock\nJust listening in this week\nDiscussion\nThere are some bugs in 2.8\nHelm 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?\nTaylor / Butcher / Nikhil: Doesn’t seem like too many folks are affected by this - so probably prudent to wait until after summit.\nDon’t need a dev call next week since we’ll be at the summit.\nMichelle 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.\nTaylor: 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”)\nAssignments (NOTE - assignments are for March 1st -- the week _after_ the summit)\nIssue sherpa: Nikhil\nNotes: Michelle\nModerator: Adam\n\nFebruary 8, 2018\nAnnouncements\nHelm summit it comes soon. Tell your friends. http://helmsummitpdx-feb2018.splashthat.com\nStandup\nJustin\nIssue triaging\nTried to generate the docs site working on issues and it failed. We have an issue\nMatt Farina\nPrepping for Helm summit talks\nFixed charts CI woes (ran out of resources due to memory leak)\nPR to fix GRPC bug from update\nReviewing 2.8.1 issues/PRs\nBeing involved with KEP and CRD discussions for application type.\nMatt Butcher\nLooking into images to docker hub and other places for put binaries for better metrics that are public\nLooking to clear some schedule time for helm development\nMatt Fisher\nTriaged things for 2.8.1\nDove into bug of multiple releases being marked as deployed\nGoing to pair with Butcher on keynote which isn’t done yet\nGoing to work to get 2.8.1 out\nMichelle\nReviewed on auth PR (by jfrog)\nWill be around to review more things\nCNCF requested mailing lists are setup\nTaylor\nHelm summit- all the things!\nNikhil\nIssue triage\nWorked on issue with chartmuseum on helm and updates\nWorked on his helm summit talk\nAdam\nBehind on everything so not too much to report. Took time off\nDiscussion\nDiscussed https://github.com/kubernetes/helm/issues/3242\n2.8.1 burn down\nThere are two PRs left that need reviewing\nMailing lists\nDidn’t get many people biting on power users list but will announce at the summit\nHelm site\nCI is still deis and needs to move elsewhere as that is going away in March\nAssignments\nIssue sherpa: Matt Butcher\nNotes: Nikhil\nModerator: Matt Fisher\n\nFebruary 1, 2018\nAnnouncements\n<No announcements>\nStandup\nJustin\nMostly looking at issues\nLooking at reuse values bug\nTrying to help people having one-off issues.\nMatt Farina\nUpgrade 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\nOdd testing scenarios and poking at CI things.\nTaylor\nWas mostly doing Helm Summit stuff\nMight not have too much time for issue sherpa given the Summit tasks\nNikhil\nLooking at issues and PRs\nProgress towards Helm Summit talk\nDiscussion\nKubernetes 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.\nNeed a few more eyes on issue 3382 to figure out why upgrades are failing. Seems to be an issue with patch metadata.\nWe 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?\nWas specifically asked to be noted that we finished 10 minutes early without MS folks around ;)\nAssignments\nIssue sherpa: Justin\nNotes: Matt Farina\nModerator: Taylor\nJanuary 25, 2018\nAnnouncements\nHelm Summit registration is open <insert link>\nStandup\nMatt Fisher\nPaired with Farina on release cutting for 2.8.0 off RC1\nIssues are coming in related to Kubernetes 1.9.0 libraries\nIssue triaging this week, not around next week as much\nAggressively reviewing PRs\nAdnan\nInteresting things going on in the chart repo\nWorking on Kube Apps related things\nNew dashboard rewrite\nTaylor\nHelm Summit\nWorking on CRD talk for Helm Summit. Will ping asking for feedback\nMatt Farina\nFollowed along on the release process which is nicely documented\nIssue open about signing Helm releases. Looking at that more closely and how other projects to do this to respond.\nPoking at bug on helm 2.8.0 that has to do with Helm upgrades.\nOn the charts side, usual stuff\nAlso documenting more processes on the charts repo\nAlso documenting public chart best practices\nHelps give people clearer idea on expectations\nMatt Butcher\n\n\nBrian Hardock\nListening today\nNikhil\nIssue triaging this week\nIn Germany this week talking about Helm at SUSE\nPreparing for the Helm Summit\nMichelle Noorali\nHelm summit schedule is live, schedule is up\n44% of the available tickets have been sold\nDiscussion\nOnboarding documents\nPut in Kubernetes-Helm org in the community repo\nTransparent governance\nHelm Summit\nCore maintainers who will be there\nMatt Butcher, Matt Fisher, Matt Farina, Brian Hardock, Nikhil\nThere will be a Q&A with a core maintainer\nMatt Fisher volunteered for unconference organization\nMiguel and Scott Rigby\n(Taylor) How we publicize RCs that may have prevent bugs\nLet’s collect a group of Helm power users to test RCs\nProblem with testing charts in RCs\nCNCF is switching over to groups.io and may be able to set up some mailing lists for us\nMichelle to follow up\nCNCF has already switched (https://lists.cncf.io/g/main) - thnx for the link Farina\nAssignments\nIssue sherpa: Matt Fisher\nNotes: Nikhil\nModerator:\nJanuary 18, 2018\nAnnouncements\nHelm Dev Summit CFP acceptance letters have been sent out, just finalizing the details and schedule\nTickets are set at $75, anyone who RSVP’d will get an email with the link\nStandup\nTaylor\nWorking primarily on Helm Summit stuff\nFinalizing some of those details this coming week\nHas a lightning talk; would like to bug others for feedback\nMatt Farina\nFound out that .Capabilities.GitVersion is missing for testing purposes\nCurrentl workflow is string comparison so x.9 > x.10\nNikhil\nShadowed the issue queue w/ Matt Fisher\nReminded that he will be out next week, putting information together for SUSE folks\nWanted to follow up with Butcher on the onboarding documentation\nMatt Butcher\nWanted to announce that Matt Farina and Nikhil are both core maintainers\nBeen on the customer front talking about helm\nNailed down a bug with `helm list` in related to rolling back and recovering lost errors\nLooking to hire Helm developers @ Microsoft\nAdam\nMostly on vacation last week and the following week\nPairing with Matt Butcher on the `helm list` bug\nHelm 2.8 release stuff\nMatt Fisher\nCFP submission scheduling\nDiscussion\nCome to a final decision on how we are going to use test-infra and any concerns we have with it\nFarina gave a demo on https://prow.k8s.io/plugin-help.html\nButcher: can we version pin plugins/opt out of new features e.g. new labels introduced in the label plugin?\nFarina: policy on how we roll this out is discussing right now in SIG test infra\nFeedback: 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\nFarina is hoping more people to come to SIG contribex to provide this feedback\nBest option is to look at the plugin repo to see what we can opt in (and out) of\nBuilding for other architectures\nOpinions on releasing a separate docker image for Helm vs Tiller?\nGoing forward with splitting into separate docker images\nLooking forward to supporting alternate architectures\nPublish these images to Dockerhub? Conversations leaned towards “yes”\nHelm v2.8 release\nPlanning to cut the release next week, Fisher will take the lead. Farina and Taylor are interested in pairing to understand the release process\nAssignments\nIssue Sherpa: Nikhil\nMeeting Lead: Matt Butcher\nMeeting Notes: Michelle (voluntold)\n\nJanuary 11, 2018 [Recording]\nAnnouncements\nHelm 2.8.0-rc1 is released\nHelm 2.8.0 is being targeted for release next week\nStandup\nMatt Fisher\nHelm Summit CFP reviewing\nJustin\nReviewed some PRs\nTaylor\nReviewing CFPs, helm summit stuff\nNik\nPR reviews\nWorked with Matt Butcher to put together some material to talk about Helm at SUSE\nThis week wants to work on learning how to issue czar\nMichelle\nHelm Summit CFP review and planning\nSame thing for this week\nReminder: there is a core maintainer meeting the night before the Helm Summit\nMatt Farina\nHelped merge the feature for the supported Kubernetes versions for a chart\nAdam\nHelm Summit CFP reviewing\nThis week is more Helm Summit stuff\nGetting ready for 2.8 release\nDiscussion\nRBAC best practices changes\nDo we create a service account for each service by default (in Tiller)?\nA service account per service is a pretty good idea\nThere is a debate about whether or not we should have Tiller do this.\nThe resolution is that we go forward with adding service account creation in the charts themselves and not tiller\nFeedback requested: Common labels (mattfarina)\nCommon labels allow for some really good possibilities for visualization\nK8s tooling (/lgtm, /approve and owners file changes) (mattfarina)\nKubernetes is wanting everyone to use the test-infra tools. Do we want to use them?\nThere are some useful testing functions that the tools enable, like tests right before a merge\nIf we have issues with having these enforced, we need to let people know at https://github.com/kubernetes/test-infra\nCRD stuff (Justin)\nMoved to next week. This is about changing the validation piece so CRDs function properly\nWe are ok if someone wants to refactor the validation\nAssignments\nIssue Czar: Matt Fisher with Nik\nMeeting Notes: Michelle\nMeeting Lead: Taylor\nJanuary 4, 2018\nAnnouncements\nHelm Summit CFP is officially closed\nStandup\nTaylor\nMostly working on clearing out notifications on github\nReviewed adam’s PR for kube 1.9\nReviewing CFPs for the Helm Summit\nMatt Butcher\n2.8 release planning is priority\nMatt Fisher\nSee Taylor’s standup\nSlicknik\nWants to sync up with butcher to ramp up SUSE on Helm\nAdam\nSee Taylor’s standup\nDiscussion\nPaul (withnale) talked about https://github.com/kubernetes/helm/pull/3243\nButcher and Taylor mention it would be good to get Justin Scott to take a look at this\nHelm 2.8\nNothing else blocking except for 1.9 support\nWe should continue to cut an RC like the last few releases\nAssignments\nIssue sherpa: Matt Butcher\nNote Taker: Taylor\nMeeting Lead: Adam Reese\n```\n"
  },
  {
    "path": "community/meeting-notes/2019.md",
    "content": "---\ntitle: Helm Minutes for 2019\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/meeting-notes/2019.txt\n-->\n\n```txt\nDecember 26, 2019\nCancelled for the holidays\nDecember 19, 2019\nAnnouncements\nHelm 3.0.2 has been released: https://github.com/helm/helm/releases/tag/v3.0.2\nHelm dev calls resume 2nd week of January, the 9th\nChartMuseum v0.11.0 released, works w/ Helm 3\nStandup\nMatt Butcher\nCut the 3.0.2 bug fix release\n3.1.0 release set for end of January (tentatively)\nMatt Fisher\nConsultation on the issue queue\nJosh Dolitsky\nNew release of chartmuseum based on Helm 2.16.1 which broke backwards compatibility, so working with community members on that\nhelm-push now has Helm 3 support\nTaylor Thomas\nIssue triaging\nProposal for post-render hooks: https://github.com/helm/helm/issues/7260\nSupport for Kustomize\nPR: https://github.com/helm/helm/pull/7259\nDiscussion\nTaylor’s post-render proposal\nSpecify a binary with --post-renderer=<bin> on install\nThe binary must take stdin and return kubernetes yaml on stdout\nIf you opt-into a post-render, you’re stuck with it for the release’s lifetime\nWill remove checks on if a release used post-renderer for now, will add in later as feature if needed\nNeed review from other maintainers\nWhat’s for dinner for _______?\n?\nAssignments: [Determined Jan 9 - Fisher Moderator, Josh D notes]\n\nDecember 12, 2019\nAnnouncements\nHelm 3.0.1 has been released\nStandup\nMarc: Improvements to completion -- in Cobra itself. It will be a surprise!\nJosh: Introducing Peter, who will be working with Josh. Chart Museum 0.10 is incompatible with Helm 3, so working on upgrading it.\nFisher: ONE BAZILLION ISSUES TRIAGED. Pass through old support questions that were stale\nTaylor: Backlog on issues and PRs. Next week: Proposal for post-render hooks with Replicated. Example with Kustomize coming soon.\nFarina: 3.0.1 released, then at Kubernetes Forum in Seoul doing a Helm presentation.\nButcher: Discovery client bug, PR triaging\nMartin: Working through the PR queue, and triaging issues\nCommunity:\nAnukul: Issue #3276 (external files to chart deployments). Can we discuss here?  https://github.com/helm/helm/issues/3276\nSandip: Second time on the call, and interested in contributing as well.\nScott (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:\nDemo: 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)\n@helm/kind-action\n@helm/chart-testing-action\n@helm/chart-releaser-action\nDiscussion\n#3276: Proposed possible implementation. Pass in files from a commandline flag, then a template can access those particular files if they were passed in.\nFisher: 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\nAnukul: Yeah, we can talk about this offline\n“Lookup” function: https://github.com/helm/helm/pull/6752 [Taylor]\nAbility to look up data from inside the cluster during template rendering\nNeed to vet security of this\nJosh: How does this handle the (offline) ‘helm template’ case?\nTaylor: We should follow up on that in the issue\n“helm env and XDG_* vars” https://github.com/helm/helm/pull/6892 [Marc]\nMarc: Was hoping Adam would be here. Will continue on the issue queue.\nNext Cobra release will print the help text on stderr.  Any foreseen issue? [Marc]\nChange that causes all help text to go to stderr\nMarc: Could bring it up in Cobra as a breaking change?\nFisher (chat): Should look into whether this is configurable in Cobra itself\nAssignments\nNotes:\nModerator:\n\nDecember 5, 2019\nAnnouncements\nNew Helm Client Maintainer\nChartmuseum 0.10 is out\nStandup\nMartin\nGetting back into things after a long return from KubeCon\nTriaging and reviewing the things\nJosh\nReleased chartmuseum\nScrubbing issue queue for registry things\nFarina\nTriaging PRs for a 3.0.1 release\nMarc\nWorking on autocompletion for plugins\nButcher\nGiving team update. Many people are using their use it or lose it vacation time. Slow down in velocity\nFinished last conference of the year\nNot much done since KubeCon/CloudNativeCon\nKaruppiah\nWorking on pull plugin for chartmuseum\nDiscussion\nChartutil unmarshiling to json.Number issue - https://github.com/helm/helm/pull/6888 [mattfarina]\nReleasing 3.0.1 [mattfarina]\nMatt Farina will get a release out\nS390x releases? [mattfarina]\nMartin is going to chase this down\nWe are tentative to own and support releases we cannot test or debug\nhttps://github.com/helm/helm/pull/6988\nhttps://github.com/helm/helm/pull/7096\nDiscovery client errors [technosophos]\nGo modules/Oras lib update [jdolitsky]\nPeople having issues using Helm 3 as a lib due to docker/distribution replace\nMaybe this will fix: https://github.com/helm/helm/pull/6862\nAssignments\nNotes: Butcher\nModerator: Martin\n\nNovember 14, 2019\nAnnouncements\nNo meeting for the next 2 weeks\nHelm 3.0.0 has been released\nhttps://helm.sh/blog/helm-3-released/\nHelm 2.16.1 has been released\nhttps://github.com/helm/helm/releases/tag/v2.16.1\nKubeCon sessions for next week\nScott is doing a maintainer’s booth\nFarina and Josh: Helm intro session\nTaylor and Martin: Helm deep dive\nCERN is giving a Helm talk\nMichelle will be talking to analysts during the event\nMichelle will be hosting a few panels: TOC and end user\nSignup sheet: https://docs.google.com/document/d/1d-6xJEx0C78csIYSPKJzRPeWaHG_8W1Hjl72OJggwdc/edit#heading=h.y5ll0uc2osyi\nStandup\nJosh\nStarted using helm 3 and helmfile this week\nTaylor\nPolishing up kubecon talks, continuing to do so next week\nMartin\nBeen dealing with a bunch of miscellaneous issues at work. Broken laptop, server issues, etc.\nUpdated migration plugin for Helm ga\nPrepping for KubeCon\nMatt Fisher\nManaging the helm 3 release\nAdam Reese\nTaking a look at managed hook proposal\nMatt Butcher\nWorking through a whole bunch of the documentation for Helm 3\nAttending kubecon next week\nMatt Farina\nGot the blog post and governance changes out for the community management role\nTriaging hub.helm.sh requests\nScott\nWorking on a stable and incubator charts repo deprecation policy, aligning with the helm 2 deprecation policy\nMichelle\nPrepping for Kubecon\nDiscussion\nInterest in a “helm import” tool for existing resources? (to help migrate from helm template | kubectl apply -f type workflows) (jacob)\nJacob to follow up with taylor on the `helm commandeer` plugin\nQuestion about hooks for community charts v2 compatibility\nScott to follow up with adam\nOk time to update go modules? / Does anybody know how to update Go modules?\nFarina: yes\nAssignments (3 weeks from now)\nNotes: Farina\nModerator: Fisher\n\nNovember 7, 2019\nAnnouncements\n3.0.0-rc.3 has been released\n_should_ be the last one\n2.16.0 has been released\nDue to breaking changes, it needed to be a major version\nStandup\nFisher\nworking with Martin & Rimas - mini-consulting - found issues with some releases not being created/propagated over\nAdam\nPR reviews, and anything that comes up before the release\nButcher\ngave talks at Open Source Summit on Helm & community with Karen\nHelping Farina get ready for kubecon\nRunning through the docs with a new user’s eyes\nFarina\nSlides! Preparing for the conference\nHelm hub - reviews for v3\nReviews and other helping in prep for v3 release\nBridget\nOut earlier this week at VelocityConf Berlin\nING is doing interesting stuff with Helm\nHelping Lachie get ready for his QCon SF Helm talk\nMartin\nFocused on Helm 3 & bugs\nWorking on deep dive with Taylor for KubeCon\nCommenting on Fisher’s blog post for Helm 3\nMichelle\nShe’s back!\nVolunteering with a non-profit _using_ Helm - good perspective\nAvailable to help with PRs\nJacob\nPlanning to look over current docs on Helm test/hooks\nPlanning to open a PR to fix referencing images by digest in the default starter chart\nScott Rigby\nWorked on chart testing repo this week with Reinhard\nAligned branches with helm/helm’s current branching scheme\nWe are in the process of upgrading chart testing to Helm v3\nTaylor\nWorking with Martin on talk for KubeCon San Diego\nWorking on an advanced k8s talk for cloud native rejects\nbugs/PRs!\nDiscussion\n2.16.1 release [Taylor] - 2.16.1 milestone\nSchema issue in the issue queue - fix merged in, undergoing testing - breaking some of the major charts like Prometheus.\nLet’s cut release today [Taylor and Fisher will pair on issues and cut release]\nIs a `helm status` bug a regression? Or did something else break in the k8s client libraries?\nKubeCon/CloudNativeCon booth [Farina]\nSign up! We need people to pick time(s) to be there.\nHelm 3 Presser update [Farina]\nThe CNCF is waiting on what we plan to announce\nButcher: Microsoft will have an Open at Microsoft blog post about it. [Bridget is writing it]\nQuestion about Helm v3 compatibility with community helm/charts that I may have missed: are we still planning something like this:\n    > A “legacy” plugin will be released by the Helm project to support v1 charts with the crd-install hook\nFarina: 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.\nHelm template not rendering notes in 3: https://github.com/helm/helm/issues/6901\nMartin: this has been answered\nAssignments\nNotes: Fisher\nModerator: Scott\n\nOctober 31, 2019\nAnnouncements\n3.0.0-rc.1 has been released! rc.2 to follow\n2.15.2 released. See https://helm.sh/blog/2019-10-30-helm-symlink-security-notice/\n2.16.0-rc.2 has been released\nStandup\nTaylor\nWorking on PRs, working on issues, etc. Keeping an eye on the queue\nJosh (in costume)\nBeen spending time on the OCI mailing list to make sure our strategy is good for charts in OCI repos\nMartin\nDoing bits of this and that (spending time in issues and PR reviews)\nBridget\nIn Belgium with lots of delicious chocolate\nDoing a helm talk at a k8s meetup\nMatt Farina\nCutting releases and doing odds and ends to help get releases and prereleases out\nAdam\nTying up loose ends on v3 including dependency updates\nScott\nBeen out sick. PR reviews and online help since back\nMatt Fisher\nWorking on ins and outs of getting releases out and fixing things up\nWorking with 2-to-3 migration process\nTriaging bugs\nDiscussion\nDo 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]\nAdam suggest we use a time box when cutting RCs.\nNot doing this for the 3.0.0\nAssignments\nNotes\nBridget\nModerator\nTaylor\n\nOctober 24, 2019\nAnnouncements:\nHelm 3 beta.5 released 🎺\nHelm 2.15.0 released 🎺\nHelm 2.15.1 released 🎺\nGitHub branches changes: 🎺\n2.x: `master` → `dev-v2`\n3.x: `dev-v3` → `master`\nHelm 2.x now in maintenance mode - bug fixes only accepted\nHelm Security Audit current status [fisher]\nWe should see the full report within the next week\nStandup:\nMatt Farina\nWorking on PR reviews, triage\nUpgraded the kubernetes cluster for Helm Hub\nFixed a few issues related to CronJobs in the cluster\nTaylor\nReviewing PRs and shepherding things through to cut Helm releases\nWorking on documentation for Helm 3\nMatt Fisher\nWorking on triaging issues for the Helm release milestones (2.15, beta.5)\nMatt Butcher\nAway at OSS Lyon, France this week\nMartin\nBug triage\nPR reviews\nLooking to follow up with the other core maintainers to help out with the RC\nJacob\nWorking with a coworker on a particular PR in regards to `helm template` in Helm 3\nDiscussion:\nHelm 3 GA: [martin]\nNotification to CNCF\nRC1 release date\nGA release date\nFarina: 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.\nWe have to coordinate with partners\nFisher: On the site design, Ronan is free right now but may be pulled in other directions as KubeCon NA comes closer\n?????\nChange related to OCI mediatypes: [josh]\nhttps://github.com/helm/helm/pull/6779\nAssignments:\nNotes: Farina\nModerator: Fisher\n\n\nOctober 17, 2019\nAnnouncements\nStandup\nTaylor\nPR Reviews\nWorking on some PRs like around a “funky” situation with time: feat(*): Adds custom time package for better marshalling. Working on a lint PR\nMartin\nWorked on a few PRs and PR reviews\nDid some triaging\nMatt Farina\nWorked with folks on the Helm security audit which is ongoing\nTriagied issues with the Helm Hub\nMatt Fisher\nWorked on v3 including the 3 way merge\nGoing to continue on with v3 beta 5 work\nDiscussion:\nWill Helm v2 CRDs work in Helm v3? [martin]\nNo. The CRD install is different in each. This needs to be documented\nWe were/are planning to have a legacy plugin that will bring about compatibility but work has not happened on that, yet\nHow should `repo update` resolve v3 repository file: [martin]\nhttps://github.com/helm/helm/issues/6644\nRelease updates\nRelease.Time and Release.Revision discussion\nJacob asked to have it back because he uses it with backups and to pull the right backup\nAssignments\nNotes: Matt Fisher\nModerator: Martin\n\nOctober 10, 2019\nAnnouncements\nIf you are a project maintainer, you now have triage access everywhere in the Helm org\nHelm 3 security audit starts today\nThis is needed for graduation\nV3 beta.4 contains an important security fix\nStandup\nTaylor\nWorking on porting features over from Helm 2 to Helm 3\nThis next week spending more on ports and outstanding work for beta.5\nAdam\nMerged PRs on open API validations\nMaking sure there aren’t any other loose ends for v3\nMatt Fisher\nWorking on paring down the PR queue, closing old PRs and triaging ones needed in 2.15. One more outstanding PR for 2.15\nWorking on finishing up 2.15 and beta.5 this next week\nMatt Farina\nWorked on getting the security audit work rolling\nWorking through go modules issues and cleanup\nWorking on Helm Hub stuff as well\nThere are some scaling and storage issues\nJacob\nSaving time for discussion\nMartin\nWorking on v3 ports\nPR reviews!\nUpdating the migration plugin against beta.4, including updating go modules\nDiscussion\nWhat versions of Kubernetes is Helm supporting? [mattfarina]\nNote, Google Cloud, Azure, and AWS ship n-2 as their latest stable\nExample: https://github.com/helm/helm/pull/6590\nIf we stick with n-1 we’d be excluding all public cloud providers\nAll maintainers present in the call are ok with n-2. Farina is going to send out an email to Helm Maintainers for a vote\nHow should Helm v3 cache work? [martin]\nIn v3, repository file (repositories.yaml) seems to be empty for cache property for repo entries\nThe repositories.yaml file is missing the cache property.\nThis is different per system due to the XDG spec, which allows you to change which directory to look in. Caching should still work\nAdam is going to look it up to validate\nWhen 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\nHelm test and hooks roadmap for v3 release [jacob]\nSee presentation for full proposal\nThere is an open PR to remove the cleanup command\nHooks will be recreated (idempotent) by default and other resources will be updated as needed\nHelm 2.x and 3.x [martin]\nWhen going to release Beta 5?\nBeta.5 is following the same roadmap as beta.4 (which was released due to a needed security patch)\nWe are waiting for beta.5 until 2.15 is released\nDo we lock down merges until we have new branches available?\nBranch names post 2.15 release? For example, master → 2.x, dev-v3 → master & dev-v3 → 3.0 (3.0 GA)\nDates:\n2.15 RC today or tomorrow\n2.15 by next wednesday\nSwitch branches right after 2.15 (shoot for thursday)\nBeta.5 will be released before branch cut over (shoot for thursday)\nWe’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\nAssignments\nNotes: Matt Fisher\nModerator: Adam\nOctober 3, 2019\nAnnouncements\nA 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\nStandup\nAdam Reese\nWorking on a few Helm 3 PRs around flag parsing and environment variable processing\nMatt Fisher\nPairing with Bridget on Helm 2 PR queue - figuring out what is in there, what could go into 2.15, resolving old issues.\nNot too much to report on Helm 3 this week\nMartin Hickey\nPR review/triaging\nStarting to pour over som older PRs and see where they are in terms of merging status. One of them is the release checklist\nHelping out with the Helm 2 -> Helm 3 PR port process\nTaylor Thomas\nWorking on a major refactor in Helm 3 that standardizes how Helm displays information. We had 2 printers; now we have 1\nReviewing PRs as they come in\nMatt Butcher\nWorking on migrating some internal charts from Helm 2 -> Helm 3 for testing purposes\nWorking on updating the Helm 3 documentation around XDG\nBridget Kromhout\nPairing with Fisher on a bunch of Helm 2 PRs\n~20% of the old PRs were cleared up in the past few days\nAdded a few PRs to the discussion list for further questions\nMatt Farina\nWorking on migrating helm/helm over to Go Modules, which has been fun\nShould have a workable PR with an up-to-date modules in the next few days\nDiscussion\nIssue Triage/Discussion\nhelm template refactor and remove dependency on install. Ideas on how to go about it.\nAction item: open up a WIP PR so we can give some actionable feedback\nMoving 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.)\nAdam: I can give an update on this one\nFix 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.)\nOverall, I think we need to step in and respond, telling them that we need to\nfeat(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.)\nFisher will look at this.\nfix 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.)\nMatt Farina: I’ve already commented and they’re asking for me. I’ll look at it.\nadd 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?)\nMatt Farina: I’ll take a look at this one\nTaylor: I can port to v3 when done\nRelease Metadata https://github.com/helm/helm/issues/6464 [Taylor]\nAction item: Fisher will follow up in the issue with the discussion that occurred in the meeting (link to youtube)\nPossible 2.15 Release Date [Fisher/Taylor/Bridget]\nSuggestion:\nmid-october cut 2.15 branch (Oct 16?),\nswitch the dev-v3 over to master\ncut beta 4 first\nconsider a Helm 3 release candidate for Halloween (or right before KubeCon mid-Nov)\nCan we also discuss 3.x release date [Martin]\nWe need to cut beta 4 first\nCreate a 3.1 milestone\nAssignments\nNotes: Taylor\nModerator: Martin\n\nSeptember 26, 2019\nAnnouncements\nBeta 4 date? - coming out fairly soon (discuss at standup)\nStandup\nTaylor Thomas:\nporting features from v2 to v3 - small refactors - adding back in missing validations\nTying up 2.15 milestone & releasing that - which should be the last feature release of Helm2\nJosh Dolitsky\nDiving down OCI harbo(u?)r rabbit hole\nBridget Kromhout\nWorking on communications around Helm 3 ticket items\nMatt Farina\nHelm hub install/search issues (redirect needed; in progress)\nHoping to start go modules on Helm\nMatt Fisher\nTriaging, porting features\nWorking towards next beta milestone\nAdam Reese\nOpenAPI validation - adding back, finding small bugs\nMatt Butcher\nInfoQ will publish an article about Helm Summit tomorrow (after interviewing Butcher)\nMartin Hickey\nWorking on migration feature and docs (yay)\nReviews for ports\nLooking at k8s 1.16 breaking changes\nJacob\nHas a PR open for moving test run subcommands: https://github.com/helm/helm/pull/6363\nTriage -[moving to discussion this time]\nDiscussion\nv2.15 [Taylor]\nCurrent 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”.\nHelm channels: Slack, mailing list, etc - letting people know\nWe will probably have to stay on current client go libraries until k8s 1.17 comes out.\nv3 label, project board, etc (Bridget)\nWhat 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.\nFarina: “V3” as a label doesn’t imply any commitment\nFisher: 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.\nFarina + Adam: let’s flag everything v2 or v3\n timeboxed segment where we look at outstanding issues/PRs\nhttps://github.com/helm/helm/pull/6504 - technically a breaking change - but we said beta could have those! So it should be okay?\nFarina will add some labels for v2/v3\n\nMarckhouzam: auto-completion for the v2/v3 migration https://github.com/helm/helm/issues/6474\nWhat is the priority? Adam appreciates and will review.\nBut should v2 patches get added so autocomplete works properly on both sides?\nJosh D: if autocomplete is not working it’s a bug\nMatt Farina: Happy to review these.\nMarc & Martin discussing autocomplete speed (10ms vs 60ms)\nAssignments\nNotes: Fisher\nModerator: Farina\n\n\nSeptember 19, 2019\nAnnouncements\nHelm summit\nHelm 2to3 plugin moved to Helm Org: https://github.com/helm/helm-2to3\nStandup\nAdnan\nNot much to report\nMatt Butcher\nWas at Helm Summit last week\nStarting light planning for next Helm summit\nMatt Farina\nSemver v3 out and sprig v3 in works. Both using go modules\nWorking on monocular redirects to work with helm install for helm hub and removing chartsvc from search url\nTaylor\nLooking into bugs and features for Helm v3\nWas at the summit last week\nJacob\nUsing helm v3 for past 3 weeks!\nWorking on test subcommand\nMartin\nHelm summit last week\nCleanup capability in 2to3 plugin\nGoing to get back to migration docs\nTriaging in the queue\nDiscussion\nWhat about adding kubectl as dependency for zsh completions. See https://github.com/helm/helm/pull/6408 [mattfarina]\nWill check with Adam who has worked on this\nValidate that the absence of kubectl does not cause any issues so this is only additive\nEdge case issue https://github.com/helm/helm/issues/6435 [martin]:\nIf Helm 2 and Helm 3 manage the same cluster concurrently\nAnd Helm 2 release data is stored as secrets in the cluster\nAnd Helm 2 has release(s) stored in namespace of the release\nHelm 3 stores release as secret in the namespace of release\nHelm 3 will not list any such v2 releases as different labels used\nWith Helm 3 you can try to install with name already used in v2 and it errors out\nIssues also occurs for migrating data meaning that release cannot be migrated\nShould Helm 3 to use a different naming convention for release versions?\nAre we still integrating new functionality into v2 like https://github.com/helm/helm/pull/5704? [martin]\nLooking to 2.15 as last feature release for v2\nTaylor 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]\nDeprecating the --recreate-pods flag https://github.com/helm/helm/issues/1702 [Taylor]\nTaylor would document the replacement\nNo push back\nTriage role and the Helm org… https://help.github.com/en/articles/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level [mattfarina]\nAssignments\nNotes: Bridget\nModerator: Taylor\n\nSeptember 12, 2019\nNo meeting due to the Helm summit in Amsterdam\n\nSeptember 5, 2019\nAnnouncements\nMake sure to register for Helm Summit! -  https://events.linuxfoundation.org/events/helm-summit-2019/\nButcher: there is a 20% discount code “HELM19G20”\nNext week in Amsterdam, The Netherlands\nCommunity and core maintainers\nStandup\nTaylor:\nPreparing for Helm summit\nPR reviews\nPaired with Butcher on some CRD stuff\nMatt Fisher:\nBack from honeymoon! Congrats!\nPreparing for Helm summit\nPR reviews\nAdam:\nPR reviews\nDoing fixes\nMartin:\nMigration work\nPR reviews\nStarting to pull up some v2 work around scaffold charts\nMatt Farina:\nBug triage\nPR reviews\nHelm hub work\nJacob:\nHelm test proposal\nLooking to refactor Helm test\nJosh:\nPreparing for Helm summit\nMatt Butcher:\nWorking on CRDs with Taylor\nPreparing for Helm summit\nDiscussion\nWill we have a meeting during the summit?\nNext week dev meeting is cancelled due to Helm summit\nBeta 3 release [Taylor]:\nCut a release before going to summit to pickup work\nBeta 4 and RC release timelines [Taylor]:\nPull up any v2 work and get it stable for Beta 4 before rc1\nWork to make it stable for GA\nShould “helm-2to3” plugin be added to Helm org [Martin]: https://github.com/hickeyma/helm-2to3/issues/14:\nYes, pull it\nMartin to send mail to Helm Org Maintainers to vote to get it added\nIf/When added to Helm org, Helm core maintainer become owners\nTest subcommand beta status? [Jacob]\nRemove `run` from `helm test run` (Jacob before beta.4)\nRemove the cleanup flag (Jacob before beta.4)\nMake it useable by Helm 3\nAny breaking changes are feature gated\nhttps://github.com/helm/helm/issues/5654\n`helm template` Breaking change?\nNeed `validate` flag now to use\nMatt Butcher/Jacob to look at it\nJacob to file a new issue\nOne-minute summary of the CNCF review [butcher]:\nMatt Butcher and Farina delivered to CNCF\nVery successful meeting and CNCF very happy with progress\nSecurity audit in October\nLooking to  move from incubator project to Fully fledged project by EOY\nAssignments [for September 19th]\nNotes: Matt Farina\nModerator: Josh\n\nAugust 29, 2019\n- Moderator: Adam\n- Notes: Vibhav\n\nAnnouncements\n    - Helm v3.0.0-beta.{1,2} released: Thanks Taylor & Adam.\n- Standup\n    - Butcher\n        - Open Source Summit talk with Karen Chu about lessons from open source (focused on the Helm project)\n    - Josh:\n        - Working on ORAS\n    - Martin\n        - PR reviews\n        - Bug triaging\n- Getting ready for helm summit\n    - Matt Farina\n        - Getting ready for helm summit,\n- if you hit 501 jobs in the cluster in helm hub cron jobs stop working. Fix: reduce the number of jobs\n    - Bridget\n        - Talks in Open source summit\n        - Getting ready for helm summit\n- Discussion\n- [Josh] https://github.com/helm/acceptance-testing\n- Define goals\n- [Martin] Discuss goals for Helm 2 to Helm 3 Migration:\n    - Feature: https://github.com/helm/helm/issues/5892\n    - Doc: https://github.com/helm/helm/pull/5582\n    - Helm v2 releases in-place to Helm v3:\n        - Proposal: https://github.com/helm/helm/issues/6154\n- Plugin: https://github.com/hickeyma/helm-2to3\n\n- Assignments:\n- [Bridget] - figure out what’s more common - “dry run” or “template” - in the wider ecosystem (https://github.com/helm/helm/issues/6290)\n\n- Notes:\n- Moderator:\n\n\nAugust 22, 2019\nmoderator: matt farina\nnotes: scott\nAnnouncements\nMake sure to register for Helm Summit! -  https://events.linuxfoundation.org/events/helm-summit-2019/\nThere is a 20% discount code “HELM19G20”\nStandup\nJosh\nRegistry should be good for beta\nAdam\nWorking on removing helm init. Changing how config is passed around\nTrying to get all unit tests to pass\nScott\nChart PRs & slack help\nHelped with Azure image updating for Helm Hub\nIssue on Helmfile and Helm org: https://github.com/roboll/helmfile/issues/758\nMatt Farina\nupdated helm hub\ncert-manager (older version made excessive api calls, will be deprecated soon)\nupgraded helm version to v2.14.3, and docker image for that\nHelm issue triaging\nJacob\nhelm test for v3\ncan create configmaps and secrets at the same time\ndocumenting\nfollow-up work to document cleanup policy. Working on proposal for that\n\n\nDiscussion\nCaptain CRD+Controller for Helm 3 [Some folks from Alauda]\nhttps://github.com/alauda/captain\n\n\nhttps://github.com/helm/acceptance-testing\nMove to next week\nWants to define project goals\nAssignments\nNotes: Vibhav\nModerator: Adam\nAugust 15, 2019\nAnnouncements\nMake sure to register for Helm Summit! -  https://events.linuxfoundation.org/events/helm-summit-2019/\nButcher: there is a 20% discount code “HELM19G20”\nJosh now a Helm Core maintainer - congrats!\nStandup\nButcher: Fisher did a major issue-queue pruning\nTriage, clearnining, getting ready for Helm 3 beta 1 milestone\nFarina and Butcher worked on security audit\nuncovered problem with CRDs\n\n\nTaylor: Bugs and beta 1 release notes\nGo 1.12.8 was breaking… everything (so, rebase your open PRs against v3 - and check all your go projects)\nFinishing open PRs and cutting beta very soon\nFarina: getting search stuff completed - `helm search` in v3 shows what you can search (registries, hub, monocular instances if you pass the URL)\nBridget: getting ready for Open Source Summit talk about Helm 3\nAdam: code reviews, pairing, helm init feature (lazy-creating config files and system directories as needed)\nVibhav Bobde: question re: storage classes - is it a good idea to wait on provisioners in storage classes? (sent a PR recently)\nNick Huanca - asking about adding a flag to show all values or supplied values in template debug\nWrote “reckoner” - would like compatibility\nAdam: let’s make sure we have machine-parsable output\nDiscussion\nCRDs in Helm 3 [Taylor and Adam]\nTaylor: “Everybody’s favorite topic in k8s-land - CRDs!”\nAs we factor out how manifests are rendered, there isn’t a clear path/common use/install/manage pattern for CRDs\nFarina: 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?)\nFarina: Helm v3 likely can’t “solve” things that are still beta in k8s itself.\nAdam: 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?\nButcher: “There’s also that peculiar pattern where the controller installs its CRD. Then we can’t load CRD instances until the controller is running”\nTaylor: 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).\nAdam: projects wanting clean install steps are interested in answers on CRDs, but application operations is where the problems show up.\nFarina: a human way to make the experience of interacting with this better - better error messages, better docs\nBridget: 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.\nFarina: let’s help people understand how to use Helm in production\nVibhav: we don’t want people to use CRDs by mistake or without understanding them.\nAssignments\nNotes: ?? [a number of people are at Open Source Summit]\nModerator: Matt Farina\n\n\nAugust 8, 2019\nAnnouncements\nMake sure to register for Helm Summit! -  https://events.linuxfoundation.org/events/helm-summit-2019/\nStandup\nButcher\nWorking with Farina on the security audit for the Helm 3 codebase\nSecurity audit is slated for the beginning of October\nHelm administrivia\nFisher\nLooking at what is needed for the beta.1 milestone\nTaylor\nWorking on the same things as Fisher\nFixing bugs in Helm 3/Helm 2\nWorking on items to get the beta out the door\nAdam\nFocused on code reviews this week\nNext week working on removing “helm init”\nJosh\nWorking with Farina and Fisher on OCI work and how it is going to land in beta\nFarina\nUpdating our security list\nPR reviews!\nDiscussion\nBringing 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\nDoc changes\nMost code ones are taken care of\nDo we remove or add the label when complete?\nAdam: We should have a second label to indicate it is done\nTaylor will be adding “v3 port complete” label and going through the list of tagged changes\nHelm security audit update [Matt Farina / Matt Butcher]\nWhich code areas should we be checking?\nTlsutil\nChart provenance\nNew registry code\nTemplating (no break-outs)\nSecurity issues will be reported in real time to the security mailing list\nFor clarity: This audit is part of the requirements for CNCF graduation\nIntro to Helm talk at KubeCon SD [Taylor]\nFarina is going to join Josh for giving the Intro talk\nTaylor will start a thread with Nanci at the CNCF to get the talk transferred to them\nRegistry updates\nExperimental flag for inclusion\nWe are all ok with including the OCI work with a feature flag, which means we need to add in feature flag functionality to Helm\nStatus of remaining tasks\nExport errors bug: DONE\nIssue: https://github.com/helm/helm/issues/5757\nLayers finalization: almost done\nIssue: https://github.com/helm/helm/issues/6141\noci-layout: almost done\nIssue: https://github.com/helm/helm/issues/6068\nHelm Hub search [mattfarina]\nThe goal would be to have the default search tie into the helm hub search\nFisher: This would be a good UX for users\nAssignments\nNotes: Bridget\nModerator: Adam\nAugust 1, 2019\nAnnouncements\nHelm 2.14.3 is out [Matt Fisher]\nStandup\nMatt Fisher\nWorking with Taylor on some helm v3 issues. The design for 3-way merge patch (PR available). Still needs docs.\n\n\nAdnan\nNot much to report\nDiscussion 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\nJosh\nWorking on chartmuseum\nGetting OCI related tasks for beta\nMartin\nWorking on charts v2 api. First PR is up\nEnabled checking for the test styling\nWorking on migrations\nScott\nA github app for chart releases\nTaylor\nWorking on 2.14.3 (a CRD change). The helm v3 version of the change still needs to land\nKubeclient change\nWorking on 3 way merge changes\nMatt Farina\nRemoving the stable repository from Helm 3 has been merged\nBackground context:\nthe stable repository has been hosted by Google’s account, making it difficult to migrate\nThe chart repository has become unsustainable for the charts maintainers (ERR_FIREHOSE)\nWorking on a process for making the gpg keys public in a KEYS file\nJacob LeGrone\nWorking on proposed changes to testing for helm v3\nDiscussion\nHelm v2 support window once v3 is out [mattfarina]\nBridget noted the shopping and tax season issues\nSuggestion is 6 months of bug fixes, following 6 months of security releases\nAfter 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\nTODO(mattfarina): Create a support proposal and put out for review\nTODO(mattfarina): Email helm mailing list on this\nFinal pre-3.0-beta OCI tasks!\nOCI layout: helm/helm#6068\nLayers/meta decision: helm/helm#6141\nThis impacts signing charts which still needs to be worked out for OCI storage\nArgoCD demo/consultation [Alex Collins]\nHelm v3 3 way merge [Taylor]\nAssignments\nNotes: Taylor Thomas\nModerator: Matt Farina\n\nJuly 25, 2019\nAnnouncements\nHelm 3.0.0-alpha.2 was released earlier this week (Matt Fisher)\nStandup\nScott\ncharts PRs\nMartin\nLooking at release information between Helm 2 and Helm 3\nPutting together a proposal for migration\nTaylor\nRefactoring the internal kube client libraries in Helm 3\nAdding back --cleanup-on-fail\nAlso following up on the issue where resources sometimes don’t update. More information has been shared by the community\nMatt Farina\nHelm Hub work for the last week\nMichelle\nWorking through the helm test proposal Jacob worked on last week\nJosh\nOpened a new acceptance test suite repository: https://github.com/helm/acceptance-testing\nWorking with Fisher on a list of work items to complete for the beta\nMatt Fisher\nReleased alpha.2\nWorking on doing some release planning for beta.1\nDiscussion\nIan https://github.com/helm/helm/pull/6066\nAction item: Matt Fisher will take a closer look at this one this week (or early next week)\nA KEYS file for signed releases… https://github.com/helm/helm/issues/6015 [farina]\nYes, this sounds like a good thing to do\nIn the future we may move to notary, but we still need to implement this for Helm 2\nWork remaining for Helm 3 and how best to share the load? [martin]\nLinking “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?)\nA: maybe both, we could follow up on the PR to see how to link\nWe are also translating (localized) Helm v3 Doc in Chinese\nThe helm official docs want to move to have translations\nhttps://github.com/helm/helm/issues/5994 (helm controller and CRD) [Hang Yan]\nScott to follow up with Hang to set up a meeting, or as a demo for next week’s dev call\nAssignments\nNotes:\nModerator: Matt Fisher\nJuly 18, 2019\nAnnouncements\nHelm Summit Update (fisher)\nSchedule is available https://helmsummit2019.sched.com/\nSpeakers have been notified\nNext steps: review diversity scholarships, sponsorships\n2.14.2 released\nStandup\nMatt Fisher:\nHelm Summit planning\nRelease planning for 3.0-beta\nScott:\nReviewing chart tooling, also PR reviews/merges for helm/charts\nMatt Butcher:\nMeetings for CNCF Graduation\nBridget joined team to work on docs\nHelmfile looking to join the Helm Org\nWorking on getting our KubeCon SD sessions setup\nMatt Farina:\nPR reviews\nAdam:\nThis week: reviewing a few PRs\nTalking to taylor about some apply design stuff\nPulling out some features from his XDG PR (like the --namespace fix)\nMichelle:\nHelm Test:  reviewing proposal from Jacob\nTaylor:\nAtomic flag feature\nWorking with Adam and it was amazing\nMartin:\nv2 to v3 migration proposal\nCut 2.14.2 release\nGeneral PR, issue work\nDiscussion\nMaking Helm easier to use as a Go library and the work required (Taylor)\nHelm testing proposal https://github.com/helm/helm/issues/6020 (Jacob)\nMerging PRs procedure: PR has one LGTM (small, medium), two LGTMs (large+) OR 2 LGTMs? (Martin)\nAssignments\nNotes: Matt Fisher\nModerator: Scott\n\nJuly 11, 2019\nAnnouncements\n2.14.2 is coming (today? lol)\nHelm Summit CFP notifications will go out Monday\nHelm Summit schedule final touches happening, coming out soon\nWe will be bumping the chart API version to v2, because new charts made for helm v3 won't work with the v1 charts API\nStandup\nTaylor:\nalmost done moving atomic flag to help 3\nwill work on 3 way diff merge\nhelped a bit on 2.14.2\nScott:\nNothing to report for this week\nMartin:\nissue triage/pr review/ workspace answers\nmigration stuff on backburner, will try to get back to it\nneed some issue triage help\nMatt farina:\nnot much this week except merging stuff into helm hub and some triage help\nJosh (via Taylor):\nworking on kind acceptance test suite\nAdam:\nworking on helm init (can remove command)\ncatching up on code reviews\nBridget:\nOffer to help w kubecon NA CFPs, due Friday\nMatt Fisher (via Martin):\nworking on helm summit schedule planning\nVia 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.\"\nDiscussion\nHelm v3 charts, is it time to increment the chart apiVersion to v2?\nhttps://github.com/helm/helm/issues/5907\nExample changes:\nrequirements.lock now Chart.lock\nRequirements now in Chart.yaml\nMichelle has proposed a chart test breaking change\nRelease object in templates has changed (Time dropped but sprig function coming to templates to return exact same feature in use)\nSomeone is working on a Helm v3 controller - https://github.com/helm/helm/issues/5994\nhttps://github.com/fluxcd, too\nAre the changes to the test architecture documented somewhere (proposal? v3*.md?).\nAny updates on planning for Lua engine stuff? (curious about chart template post-render options. No rush 😅)\nAnswer: 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.\nAssignments\nNotes: Adam\nModerator: Martin\n\nJune 27, 2019\nAnnouncements\nNone for today\nStandup\nNikhil:\nNot much last week\nFollow up on PR reviews / Issues this week\nJosh:\nHelm.sh follow up\nNot too much else\nTaylor\nReady to jump to Helm 3 things\nPlan to cut 2.14.2 on Monday with Martin’s help\nIf there are some bug fixes that need to make it to this release please let Taylor / Martin know!\nScott\nCoalesce values fix added to 2.14.2\nMartin\nDigging in to a lot of PR reviews and issue triage\nFixed an issue with templating on the v3 branch. This was causing unit tests to fail\nAlso made some progress on the migration work\nJacob\nMichelle has an updated helm testing proposal. Would be good to get feedback from a wider audience around this.\nMichelle\nWorking on helm test -- this week was helm test cleanup\nGoing to get on a zoom with Jacob to go into detail on helm test. Will drop a link in the #helm-dev channel\nWould love some more feedback on the helm test PR\nDiscussion\nNeed a label or a way to assign community members to issues (michelle)\nWas 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.\nNeed to look into what administrative controls GitHub has for this?\nWill look into what k8s does here and should have an update soon\nCommunity member asking when alpha.2 is scheduled for (martin)\n(Find alpha.2 issue to add here)\nWe’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.\nHelm Testing Proposal:\n[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).\n[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.\n[Jacob] Re test cleanup: https://github.com/helm/community/pull/90#discussion_r297374923\nThe second test proposal is based on a lot of feedback and conversations. The first one should be closed shortly.\nLots of people are using this very often, and is very popular -- so thanks for driving this Michelle!\n[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.\nAssignments\nModerator: Taylor\nNotes: Josh\n\nJune 20, 2019\nAnnouncements\nHelm Summit update\nStandup\nTaylor\nHave been working on troubleshooting an issue where certain objects aren’t being updated on an upgrade (for Helm 2)\nSome of the folks over at Mattermost have a reproducible case, so working with them\nJosh\nThis week, been giving talks/evangelising Helm in the midwest\nHoping to connect with Matt Fisher on the registry work going on in Helm 3\nMartin\nConcentrating on the migration work from Helm 2 to Helm 3\nLooking on the release metadata differences between Helm 2 and Helm 3\nPR reviews\nMatt Fisher\nDiving into the downloader package for Helm 3\nLots of cruft in there, so cleaning up the code\nWorking on Helm summit\nMatt Farina\nReleasing a new version of sprig\nWorking on the capabilities object for Helm 3\nReviewing PRs\nDiscussion\nHelm 3 OCI: enforcement of tags (joshua)\nOCI does not have a ruleset on the tag pushed\nThe current context in Helm is to not push non-semver tags\nDo we want to allow semver-incompatible tags?\n(fisher and farina) if we do support those, then it makes the dependency resolution problem much harder\nIf there’s enough demand, perhaps we should come up with a proposal to the UX so we can capture that use case\nNew docs: https://v3.helm.sh/docs/developing_charts/#registries\nPR reviews (matt and adam)\nCurrent status: Helm 2 requires 2 LGTMs on PRs size/L or higher. Helm 3 requires 2 LGTMs on *all* PRs\nHow do we get more people to jump in on PR reviews?\nWhat can we do to incentivize folks to review PRs?\nTaylor: 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?\nAction item: farina to bring it back to the mailing list?\nShould we cut 2.14.2 when this PR lands? https://github.com/helm/helm/pull/5532 (Taylor)\nKubernetes 1.15 was just released yesterday. Should we wait on merging support for that before cutting a new release?\nThere may not be enough release maintainers around to cut a 2.15 any time soon\nAction item: taylor to follow up with Martin on a 2.14.2 release\nJosh: 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?\nFisher: 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\nAction item: Josh to follow up with Fisher\nAssignments\nModerator: Martin\nNotes: Matt Fisher\n\nJune 13, 2019\nAnnouncements\nHelm Summit\nCo-chair committee met up this week. Program Committee is currently reviewing proposals. After that, chairs will assemble the schedule.\nStandup\nMatt Fisher\nTaking a look at one of the helm 3 refactors: the OCI registry integration\nTaking a closer look at the getter package for fetching helm charts and refactoring\nGoing through helm 3 PRs\nMatt Butcher\nKeeping tabs on a few things in the helm issue queue\nAdam\nWorking on the XDG base directory specification + removal of `helm init`\nMichelle Noorali\nWorking on `helm test`, currently refactoring\nMartin Hickey\nUpdated the release checklist from 2.14.0\nTesting around the v2 to v3 migration, working on a migration doc\nSome issues around release metadata\nTaylor\nReviewing CFPs on the Helm Summit\nLooking at the coalescing tables refactor in Helm 2\nRamping up on Helm 3\nJosh\nGiving Helm talks next week with Bridget\nScott\nSame as taylor this week\nMatt Farina\nWorking on detecting objects in the capabilities object\nWorking on Helm Hub for Helm 3\nDiscussion\nProposal to drop the title “issue sherpa” (fisher)\nIs this a shared responsibility?\nMichelle: we should still have someone on-call to ensure someone is taking a look at security-related issues\nFarina: we do have a process in place about who is responsible for security issues (in helm/community, SECURITY.md)\nAction item: fisher to bring it to the core maintainers mailing list\nv2 release object from state not loading in v3 (martin)\nThis is in relation to the release object stored in the namespace, not the rendering engine itself\nPart 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\nIf 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.\nAction 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)\nCRDs - https://github.com/helm/helm/issues/5871 (farina)\nIdea from adnan. Farina threw something up to the mailing list for a call-to-action from community feedback\nIf you have comments/feedback, please chime in on that PR\nUnsetting values keys for Helm 3: https://github.com/helm/helm/issues/5834\nHow do we want to address this? Deprecation or remove it?\nFarina: how would you unset it in a values.yaml file?\nAdam: 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\nA simple example of this is probes. It’s becoming increasingly common to unset values for execute vs http probes\nIf time, check in about Lua chart post-render overrides (Scott)\nAssignments\nIssue Sherpa\nModerator\nScott\nNotes\nMichelle\n\nJune 6, 2019\nAnnouncements\nHelm has a new home for downloads: https://get.helm.sh\nThree main benefits to this move:\nNo more changes required for users if we have to switch storage providers in the future\nUsers in China can now download the Helm client using official download URLs. No mirrors required!\nGlobal content delivery via CDN. Downloads should be faster across the globe.\nHelm Summit\nCFPs are closed now\nProgram Committee is reviewing the CFPs. June 14/15 is when the reviews finish and the co-chairs will do the scheduling. More to come.\nStandup\nBrian\nMic not working\nMoving and Lua work\nMatt Butcher\nGone all week. Just been tracking issues\nMatt Farina\nWorking on being able to detect individual resources\nLooking into popping those up into the capabilities object for checking if resources exist\nThe Helm Hub is receiving about 5-6 new repos per week, so working on some of the growing pains over in monocular\nMichelle\nWorking on helm test refactor\nUpdated the helm test proposal based on feedback\nUpdated people interested in helping with helm test work\nMatt Fisher\nMigrated to get.helm.sh. No downtime or issues. Yay!\nWorking on community PRs for Helm. In particular Helm\nDiscussion\nAlibaba 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)\nSlides: https://speakerdeck.com/resouer/helm-hub-china-project-from-alibaba-cloud\nThings hosted in Google & S3, like charts and images in them, are not available in China\nLocalization! That includes content in charts?\nYes! 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\nBuilt on chartmuseum, free to use, storage in Alibaba\nPreview at developer.aliyun.com/hub\nStill in development\nWe would like to link to this when it launches\nUnsetting values keys for Helm 3: https://github.com/helm/helm/issues/5834 (Taylor)\n(fisher): Taylor is out today due to on-call work last night. He mentioned Scott may be able to talk about this\nAssignments\nIssue Sherpa:\nModerator: Matt Farina\nNotes: Matt Fisher\nMay 30, 2019\nAnnouncements\nEveryone survived KubeCon\nHelm Summit CFPs are due 5/31\nPlease submit CFPs, especially use cases for Helm!\nHelm Hub charts available over registry here to play with: bundle.bar\nStandup\nTaylor\nKubeCon\nWorking on CFP\nHelm 3 tasks\nButcher\nReviewing PRs this week\nWill be out next week, so not much\nJosh\nIssue sherpa last week,\nlooking into a few issues with Regis\nNikhil\nWatching KubeCon videos and responding to issues\nScott\nFixed Helm Hub automation. Thanks to Matt for reviewing\nWant to understand what we will be able to do with LUA for charts for Helmv3 (can discuss afterwards)\nBrian\nBeen moving, so a lot of packing\nHoping to get back to Lua development for Alpha2\nLooking into the go reflect layer\nFisher\nAt Kubecon, Deep dive with Adam + Intro with Michelle\nExpense reports, getting back into the swing of things\nMartin\nAt Kubecon last week as well\nIssue triage, PR reviews, and answering questions in Slack\nIs next week the review of CFPs?\n[Fisher] Hoping to get more information out on this from the Program committee ~Wednesday next week\nUpdates to the release checklist, and get back to migration\nFarina\nCharts and Helm hub\nHelm hub is now automated! Yay!\nDiscussion\nFeatures added to Helm 3 project board so community can help deliver Helm 3 release [martin]\nCreated this so folks can pick up features off the board and work on it.\nBoard is at: https://github.com/helm/helm/projects/1\nCore 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.\nSigning and container repos [matt farina]\nHow do we go about sticking charts in container repos\nProvenance file has hash of package, signed using gpg keys\nContainer repos don’t necessarily have the same hash in different container repos (e.g. docker-distribution, quay, etc.)\nInteresting 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).\nHow does this work with tuf and notary?\nWe have alternatives to GPG keys as well -- some folks want to use PKI instead.\nHelm 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.\nRegistry things undiscussed [josh]\nThis is a longer discussion, so probably a better idea to schedule a 30+ minute slot to hash this out.\nPlay with bundle.bar -- there are now ~600 charts\n2.14 + Azure issue? [josh]\nhttps://github.com/helm/helm/issues/5788\nIssue where helm keeps logging out when login is done with az-cli\nSince this is an ecosystem problem, this will be a problem with kubectl\nLooks like an issue with a backwards incompatible change with client-go\nCheck to see if there is a corresponding issue with\nAssignments\nModerator: Matt Fisher\nNotes: Matt Farina\nIssue Sherpa: Matt Fisher\n\nMay 16, 2019\nAnnouncements\nv3.0.0-alpha.1 released (Hooray!) 🎉\nv2.14.0 released ☘️\nKubeCon/Cloud Native Con EU Barcelona, Mon 20 - Thu 23 May (next week) - No dev meeting next week (23rd)\nCFPs due May 31st\nStandup\nButcher\nPR reviewing for v3\nFisher\nWorking on v3 Alpha.1\nv2.14.0 pairing with Martin\n Preparing for KubeCon Helm 101 and deep dive talks\nMichelle\nPreparing for KubeCon\nWIP: helm test framework\nAdam\nWorking on v3 Alpha.1\nPreparing for KubeCon\nTaylor\nPR review\nPreparing for Helm workshop on Monday at KubeCon\nMartin\nYay last library/charts functionality went in!\nAlso fixed the dry-run output for v3.\nShadowed v2.14.0 release to get that out the door.\nNikhil\nIssue sherpa\nPR reviews\nFarina\nCleanup of owner files\nIssues\nPRs (lint work etc.)\nDiscussion\nKaren 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)\nSeems like a good approach\nMichelle to chat again with Karen\nSome topic raised in community (Martin):\nMultiple environment best practices\nMicro-services best practices\nHistory/state stored details\nWe 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)\n(fisher) I believe this already exists, we just need to document it: cncf-helm-maintainers@lists.cncf.io\n(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.\ncncf-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\n[Action] Farina to document the different mailing lists\nPeople 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)\nAssignments (for the 30th (week after KubeCon))\nModerator: Adam\nNotes: Nikhil\nIssue Sherpa: Josh\n\nMay 09, 2019\nAnnouncements\nCFP May 31st\nStandup\nAdam\nMissed last week due to a team meeting\nWorking on some core reviews, prepping for the first alpha release\nPublished a proposal on the v3 release rollout\nJosh\nWorking on the oras project, getting things like `helm registry login` implemented for Helm 3\nMartin\nMostly working on PR reviews\nThinking of the v2 -> v3 migration document\nMatt Fisher\nMissed last week due to a team meeting\nFigured out things left for Alpha release\nWorked on proposal\nWorking on solution for moving out of Google Cloud Storage\nBrian\nMissed last week due to a team meeting\nWorking on conversion packages from Go to Lua\nWorking on prototype code for Alpha 2\nMatt Farina\nIssue sherpa\nPulling over v2 commits needed for v3\nMatt Butcher\nCNCF meetings for graduation\nSecurity audit after Beta 1 of Helm 3\nGood progress on graduation and good feedback\nNew branding for Helm 3 release inc. CNCF org look and feel\nKubeConEU sessions and workshops filling up\nOrg maintainers maturing\nSome PR reviews\nDiscussion\nProposal: Rollout of v3 release #5695 (adam)\nHigh level plan of deliverables\nCan add comments to the issue\nHelm 2: Anything else we should get in before we cut v2.14.0-rc.1? (fisher)\nWe should get in the postgres storage layer PR in (butcher to review): https://github.com/helm/helm/pull/5371\nDemo: https://get.helm.sh (fisher)\nNice demo :)\nOpinionated OCI namespacing/versioning + dropping search + repo subcommand as plugin (josh)\nAssignments\nModerator: Matt Farina\nNotes: Josh (Martin to deputize)\nIssue Sherpa: Nikhil\n\nMay 02, 2019\nAnnouncements\n\n\nStandup\nFarina\nWorking on search (starting with API on Monocular/helm hub)\nSprig and SemVer new major release planning with Dr. Butcher\nButcher\nHis team putting out a series of Helm 3 blog posts on the MS blog\nMost of his team at DockerCon and breakout to work on Helm 3\nLooking for Alpha v1 by KubeCon EU\nMartin\nTriaged issues\nIssues to v2 and v3 on scaffolding charts\nFrom the community\nMorten\nIssues with proto files and get the generation and tests working\nWorking on a fix\nDiscussion\nhttps://github.com/helm/helm/issues/5664\nCan’t switch default behavior because it would break scripts using helm in the wild\nA flag could be added for this feature to opt-in to it\nhttps://github.com/helm/helm/issues/5650\nWe don’t have a precedence for doing this.\nThe pattern we have is to link to external related docs\nHow is Helm going to handle CRDs?\nWe needs docs on CRDs\nAbility to detect if CRD is installed as part of crd-install hook and/or capabilities\nCRDs are HARD! [farina 2019]\nAssignments\nModerator: Butcher\nNotes: Martin\nIssue Sherpa: Farina\n\nApril 25, 2019\nAnnouncements\nHelm Summit update [Michelle]\nHelm summit CFPs are now open at: https://events.linuxfoundation.org/events/helm-summit-2019/program/call-for-proposals/\nPriyanka Sharma\nStandup\nTaylor Thomas\nWorking on PRs this week, reviewing feature PRs\nShould think about cutting 2.14 after KubeCon at least the rc for it\nFarina\nMonocular search API work to tie it into helm search for v3\nFoxish has become inactive on charts… moved to emeratus\nReviewed PRs, yo\nNikhil\nOut last week\nGetting back into the swing of things\nMartin\nOut last week\nGetting back into things\nDid some PR reviews and put in a few PRs\nMade it to the program committee! Woo\nWill go back to working on the helm v2 -> v3 migration docs\nMichelle\nHelm test PR is in - works now!\nTrying to finish up refactor, so others can jump in as well.\nAlso working on the Helm Summit stuff\nButcher\nOut last week\nTook a look at a bunch of code that Brian wrote on the lua repo\nWill meet with Adam later today\nBrian\nWorking on the lua runtime\nGetting all of the latest code out\nAdam\nReviewing PRs\nLonger reviews because PRs are touching similar parts of the codebase\nGetting those reviews finished up this week\nIan\nGetting new tests in before EOD for testing for subcharts on the schema validation PR\nDan Garfield\nChatted with Josh about migrating CICD to use codefresh\nStarted working on the migration\nHoping to get things in a place to review by next week\nScott Rigby\nLooking at the doc this afternoon\nThere 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.\nDiscussion\nHow detailed should our CONTRIBUTING guide be? https://github.com/helm/helm/pull/5346\nThis PR may target different audiences specifically people who are not familiar with GitHub. Is that what we want?\n[Martin]\n[michelle] Copy/paste command options are nice for even power users of GitHub\n[Taylor]\nMatt Farina will follow up and merge PR\n$schema in values for json schema? https://github.com/helm/helm/pull/5350#issuecomment-485852606\nMultiple editors support the top level $schema line but it’s not part of the official spec. Informal thing.\nIf someone copies/pastes a values file, they still want that validation but it’s again not part of the official spec\nMatt Farina will open a separate issue so we can have an async discussion on it and sit on it for a few days\nhttps://github.com/helm/helm/pull/5601 [Adam]\nThis is something that is used in the stable charts today. Do we want to break compatibility with v2 here?\nWe could potentially create tooling to convert charts\nV3, migration and users [Martin]\nAssignments\nModerator: Taylor Thomas\nNotes: Matt Farina\nIssue Sherpa: Martin Hickey\n\nApril 18, 2019\nAnnouncements\nHelm Summit update\nSeptember 11-12, 2018 in Amsterdam\nCFP form and conference website is live\nBe on the lookout for program committee notifications\nLink: https://events.linuxfoundation.org/events/helm-summit-2019/\nStandup\nFisher\nWorking 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\nLooking at how Jaeger has done it for their documentation\nWorking with Bridget as well on this stuff\nRe-integrating OCI work into top level commands. Helm package,etc.\nMichelle\nPretty deep into the internals of `helm test` for Helm 3\nUsing client-go for watching the test pods\nTrying to refactor the unit tests for the working test run commands\nJosh\nSubmitted the initial PR for registry login: https://github.com/helm/helm/pull/5597\nBrian\npushed 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\nAdam\nOut last week with Flu\nCatching up on PR reviews and getting back up to speed\nDan Garfield\nCodeFresh is interested in offering a grant to the Helm project to use for CI/CD and chart repository hosting\nMichelle: let’s follow up in the mailing list, and set up a meeting to determine what conversations we need to have RE: grants\nIan Howell\nMade progress on schema validation\nDiscussion\nRelease/ReleaseVersion CRDs status+questions (Josh)\nTillerless 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.\nConcern over RBAC and permission model\nNow, RBAC is mapped to user. RBAC will be identical to what kubectl does right now\nDefine what Helm creates for you and give an overview on what permissions a cluster admin should give a user\nJosh will create a follow up issue\nAlpha.1 release (michelle)\nLooking at the board, most things for alpha.1 are in the review phase now.\nShould take about a week and a half\nAssignments\nModerator: Adam\nNotes: Michelle\nIssue Sherpa: Fisher will follow up on mailing list for people\n\nApril 11, 2019\nAnnouncements\nHelm Summit EU updates [michelle]\nHelm Summit Program Committee form is now closed and will be announced soon.\nHelm venue and dates have been confirmed for September 11-12, 2019 in Amsterdam.\nlHelm Summit website will be launched next week along with the CFP form. Be thinking of topics for sessions, lightning talks, and tutorials/workshops.\nStandup\nTaylor\nWorking on issue triage/PR triage this week\nGoing to work on replicating a particular PR next week\nWOuld be great if someone with bash autocompletion could take a look at https://github.com/helm/helm/pull/5562\nJosh\nBack from holidays\nWorking on the oras project on the `helm login` stuff\nMatt Butcher\nWorking on things related to the timeline and the Lua stuff\nKubecon will be alpha.1\nAfter Kubecon, we’ll be transitioning to further alpha releases (possible 3?)\nThat should bring us to a beta around July\nThat should be the time when we get a CNCF security audit, which should bring us to CNCF graduation\nBrian 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\nMatt Fisher\nProgram committee stuff squared away for Helm Summit\nPaired with Josh on the oras project and getting up to speed on what needs to be done\nSpecifically interested in credential handling\nReview PR #5441 (not rendering templates inside of library chart) is on the list of things to review\nPairing with Ronan on getting alpha documentation for Helm v3\nMartin\nWorking on some PR/issue reviews and triaging this week\nJumped in on the v2 -> v3 migration doc this week\nMichelle\nWorking on Helm Summit stuff with Fisher, Karen, Ronan\nPicked up some of the helm test work\nFound a few rendering errors so diving a little deeper into the rendering/label selection code\nScott\nHelping Reinhard with the charts-testing project\nWorking to automate the Helm Hub\nDiscussion\nWhat’s the process for creating new slack channels now that we’re part of the CNCF? [fisher]\nFor context, Helm is now part of the CNCF. There exists a CNCF Slack, but Helm slack channels still exist in the Kubernetes slack.\nWe have not had to create a channel since the CNCF migration, but Scott Rigby wants to create a channel for helm/chart-releaser\nLachie mentioned last time he checked in January, the CNCF slack is only for CNCF related business and temporary channels on an ad-hoc basis\nCNCF projects like OPA and Kubernetes should manage and maintain their own Slack workspace\nFisher will ask Scott to ask the Kubernetes org if they’ll create a channel for him\nCredential helpers for `helm login`? [fisher]\nFisher and josh will pair together, but it looks like they work out of the box\nAssignments\nModerator: Taylor\nNotes: Michelle Noorali\nIssue Sherpa: Matt Fisher\n\nApril 4, 2019\nAnnouncements\nMartin has been voted in as a core maintainer\nStandup\nTaylor:\nPRs this week, around the atomic flag\nReview deleting resources\nContinue on with PR reviews\nMartin\nWorking on 2 PRs for the `make docs` target for Helm 3\nLib charts and app version are ready for review on Helm 3\nFisher: will definitely take a look at those, just have some things working on at the moment\nInvestigating a bug around removing a service account and how it isn’t removed from child dependencies (pods relying on the service account)\nLooking into another PR with `helm list`for Helm 3:\nMatt Fisher:\nRefactors in Helm 3\nLooking at OCI integrations (refactoring). Full integrations of repo with Helm CLI.\nBlog post with Bridget for KubeCon EU\nBrian:\nFinal integrations of the GO Lua projects\nUpdate soon in repo\nAdam:\nWorking with PRs ands issues in Helm 3\nFleshing out idea of removing helm init and lazy creating\nCharts rendering as atomic units in progress\n\nDiscussion\nUpdate on Helm 3 development progress [fisher]\nAssignments\nModerator: Martin\nNotes: Matt Fisher\nIssue Sherpa: Taylor\n\nMarch 28, 2019\nAnnouncements\nhttp://www.cloudnativeday.ca/en/program/ is looking for Helm speakers\nHelm program committee form still open for a day for Helm Summit… https://docs.google.com/forms/d/e/1FAIpQLSeMWnylHu1Yi6SmwKYvitrJxqNpBVAVXtMunjaiqkNAGkeG7g/viewform\nStandup\nMichelle\nWorking on `helm test run`.  Making it work.  Looking into using k8s Jobs\nThrew 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.\nBrian\nWorking on the path forward for Lua.  Finishing up stdlib for lua tables.  Defining api for getting values out of lua into go.\nFisher\nBooked travel for giving KubeCon deep dive talk with Adam\nJSONSchema research\nReviewed Ian’s PR\nReviewing plugin arch\nButcher\nOn Vaca all last week.  Missed everyone esp Adam\nTaylor\nMOVED HOUSES!\nWorking with go modules, having a blast.\nNikhil\nAway last week, this week reviewing issues and PR’s\nAdam\nBeen doing prep for KubeCon EU, thinking about the deep dive session\nDoing some PR reviews around some of the Helm 3 architecture changes\nLooking over the client architecture with a fine-toothed comb (event interrupts, for example)\nMatt Farina\nWorking on the Go modules stuff\nFound 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\nLet the community test it out and provide feedback\nTaylor: I have another PR with Go modules. Should we close this? https://github.com/helm/helm/pull/5520\nFarina: looks like that’s for master vs. Helm 3\nDiscussion\nIs ‘make docs’ target still relevant? Ref: https://github.com/helm/helm/pull/5458\nIntent was to keep the target around so that users can have the option of generating docs\nThere is an effort for helm v3 to take the docs under a different location\nMhickey will take it offline with folks to work out what the PR needs to evolve to.\nLua in Helm v3 and golua [mattfarina]\n\n\nThere are a few bug fixes that need another review for Helm 2.14 [fisher]:\nhttps://github.com/helm/helm/pull/4871\nhttps://github.com/helm/helm/pull/5112\nhttps://github.com/helm/helm/pull/5395\nAssignments\nIssue sherpa: Nikhil\nModerator: Matt Fisher\nNotes: Martin\n\n\nMarch 21, 2019\nAnnouncements\n2.13.1\nStandup\nJosh\nThere was a chartmuseum bug that affected Harbour, waiting on a response from them\nContinuing work on the Helm 3 repo docs\nMatt Farina\nPoking at Go modules a bit, as the next version of Go enables it by default\nBrian\nWorking on the Go Lua standard libraries based on some of the core changes over the past few months\nPairing with adam today on the lua implementation for Helm\nMatt Fisher\nWorking on the XDG base directory PR\nLightly reviewed Ian Howell’s schema values PR, need to manually review\nWorking on a Helm 3 high-level overview blog post\nMatt Butcher\nOn vacation for the next week\nDiscussion\nLua timeline/milestones [josh]\nWanted to clear up some of the story for Lua in far as Alpha is concerned\nBrian: so the current idea is to use it as an overlay as part of the rendering engine\nJosh: 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.\nFisher: can we propose to discuss this next week? We don’t have a physical integration of Helm and Lua at this point yet\nGeneral consensus is to table the discussion once we have a Helm/Lua integration\nHelm 2.13.1 release [fisher]\nMatt Fisher will go ahead and release 2.13.1\nAssignments\nIssue sherpa: Matt Fisher\nModerator: Matt Farina\nNotes: Adam Reese\n\nMarch 14, 2019\nAnnouncements\n\n\nStandup\nJosh\nMet with a few people this week about the Lua subsystem to discuss how that relates to Helm 3\nWorking on the Helm 3 repository documentation\nMatt Butcher\nHelm Summit planning (EU)\nSprig updates\nPR reviewing on community PRs\nMartin\nSherpa-ing\nPR reviews\nPR for standard application charts (library charts)\n#5441\nHelping on slack channels\nAdam\nMet with people about docs changes (v2->v3 changes)\nLabel for PRs that require a\nVanity import path\nScott\nFixed Helm Hub search\nLooking into Hub deployment automation\nLastPass setup\nCNCF prefers we use this\nFisher\nHelm 3!\nRefactoring “helm template” to action pkg\nMajor action pkg refactor (thx adam)\nCommunity PRs\nPR for storing Helm Home in XDG spec\nhttps://github.com/helm/helm/pull/5443\nThis coming week working on FAQ, planning etc\nJustin\nTriage, catching up starting tmrw\nDiscussion\nDeprecate “helm search” in Helm 3? [josh]\nSent a message to mailing list asking if anyone uses this and received no response\nHas no function in a CI/automation setting\n“Underpowered” since it only looks at local cache\nUsers can go to hub.helm.sh\nOnce remote search is rolled into OCI, we can add this feature back (in 3.1, 3.2 etc.)\nShould we cherry-pick https://github.com/helm/helm/pull/5423 into 2.13.1? [fisher]\nVanity import path #5440 [adam]\n“helm.sh/helm”\nSeparates Helm 2 and Helm 3 in go path\nOpen PRs will have to rebase\nThere is a sed script to do this\nWill enable other proj under the Helm org\nWhen should we cut a 2.13.1? [fisher]\nLua timeline [josh]\nAssignments\nIssue sherpa: Martin/Justin\nModerator: Josh\nNotes: Matt Fisher\n\nMarch 7, 2019\nAnnouncements\nProgram Committee Applications are now open. Please fill out this form if you’re interested. Deadline to apply is March 29th, 2019. [michelle]\nHelm Summit update [michelle]\nPlanning on Helm Summit 2nd week of September\nVenue in Amsterdam is on hold -- things are looking good.\nLook 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)\nStandup\nButcher\nOpened a PR on Helm 2 to update the version of sprig to one that should be used.\n Nikhil\nWorking with a customer engagement so nothing to report this week\nAdam\nPast week -- Helm 3 momentum picking up. More to come during the Helm 3 discussion.\nLot of refactoring of the engine package - diving in to the go-templates package.\nMichelle\nTook some time to work on helm-test. Helm test run is now a subcommand. Digging more into getting the test response back.\nRefactoring the initial proposal for helm test. Revising the proposal to continue using anotations and adding support for test suites\nFisher\nPairing with folks to figure out Helm 3 project planning.\nLate last week - bigger refactor for action package. Will return to that to figure out what can be pulled out to make it cleaner.\nAdnan\nNot much this week\nJosh\nNot a huge lot, still trying to mess with LUA and connect with Brian\nGet Helm repo docs out by end of the week.\nMartin\nLibchart -- should have a PR by tomorrow.\nLooking at a few issues on the Slack channel and answered a few questions\nTook 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.\nFarina\nA lot of chart stuff including reviews.\nHelped Fisher with some Windows stuff and was psyched!\nSecurity process for the Helm org document is up.\n\nA big shout-out to Fisher for getting the Helm 3 project plan organized!\n\nDiscussion\nMake crd-install hook idempotent [mattfarina]\nCharts repo is seeing issue from this\nError if the content is different on first pass\nIn the future we could discuss a flag that allows overwriting if different\nWas also proposed over on https://github.com/helm/community/pull/64\nDiscussion:\nMake 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.\n(Adnan) built a workaround\nHelm 3 status update [fisher] 👈\nhttps://github.com/helm/helm/projects/1\nThe goal is to understand what are the things we are quantifying for an alpha release of Helm 3.\nPaired 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.\nWhen we go through this backlog, we should be able to cut an alpha release.\nFeedback / Comments:\nThis is awesome! Thanks!\nChanges with Helm 3 fall into different buckets. E.g. LUA, repo, tillerless, etc. Does it make sense to make labels for these bigger “themes”.\nMight be difficult to do since lines are sometime blurred between components. E.g. refactoring of the engine piece.\nThis would help with filtering by theme -- especially as we add more items to the board. There might be a parallel with SIGs, perhaps?\nThis might be a good thing to add at some point later perhaps when we go from alpha => beta.\n(fisher / josh) Let’s table the discussion for now and revisit this once we are a bit further along.\n#helm slack channel moderators, we need them [mattfarina]\nhttps://github.com/kubernetes/community/blob/master/communication/moderation.md\nWe’re in k8s Slack and they are looking for moderators.\nEspecially in EMEA / APAC region time-zones.\nDon’t need to necessarily need be core maintainers. It would be good if anyone in the community can be Slack moderators.\nRequest for feedback on resource policy PR: https://github.com/helm/helm/pull/5092\nHas to do with deleting manifests.\nCall to folks who understand this space to comment.\nFirst commit is what’s changing in the application logic.\nThere 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.\nAssignments\nIssue sherpa: Martin\nModerator: Fisher (/ Adam, tag team)\nNotes: Josh\nFebruary 28, 2019\nAnnouncements\nHelm 2.13.0 was released yesterday\nThe first release that is PGP signed. Go try it out!\nStandup\nMichelle: Helm v3 test\nTaylor\nToday will be trying to get through a PR from a community member\nJosh\nDiving deep into GoLua\nGoing to experiment with embedding the Lua engine in Helm 3\nFisher\nPaired with Farina on the Helm 2.13 release\nWorking on the Helm 3 action package refactor\nButcher\nKubernetes meetup in Boulder with ReactiveOps\nMight be a good team to contact on the action package refactor\nBrian\nWorking on the GoLua compiler for parity with luac\nUsing the output from gluac against the lua runtime for testing\nMoving some code around but should hopefully be merged in the next few days\nPairing with Josh next week on Helm and Lua\nMartin\nWorking through some PRs to close them out\nIssue triaging\nMatt Farina\nWorking on CII best practices for CNCF graduation\nIan Howell\nWorking on the JSON schema\nQuestion: should we generate a JSON schema out of the gate?\nSolution: 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\nNikhil\nNothing to report this week\nDiscussion\nv3 contributor work (mhickey)\nFisher and Adam working on this to get some of the initial pieces out (client-package, v3-board) so that we can move forward.\nWould 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?\nHow can other contributors help with this, to get this unstuck / moving?\nFisher will come up with a workable list of helm v3 basic issues and float it to the rest of the team.\nGood first issues (mhickey)\nWe have about 9 of them, 6/7 of which are somewhat stale.\nMhickey will put in some comments and float it to other folks on the project.\nList of good first issues: https://github.com/helm/helm/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22\nOCI Update - not much to share.\nFolks were okay with using the manifest / index at the top layer (Steve / Jimmie’s proposal)\nNot 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.\nNotes from yesterday’s OCI call: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2019/opencontainers.2019-02-27-21.59.html\nLatest Proposal using manifest.config.mediaType but no solution at the index: https://github.com/SteveLasker/RegistryArtifactTypes/blob/master/mediaTypes.md\nFarina will try to jump in and get some clarity here.\nAssignments\nIssue sherpa: Matt Fisher\nModerator: Farina\nNotes: Nikhil\nFebruary 21, 2019\nAnnouncements\nHelm 2.13.0-rc.2 was released Tuesday\nHelm Summit Update:\nWaiting on CNCF to get back\nLooking at costs etc.\nMight know more by early next week\nStandup:\nJosh: Looking at the LUA language\nAdnan: Looked at library charts. Added comment to the issue.\nMichelle:\nCollecting feedback from CNCF projects for improvement\nContinue on Helm test\nNikhil:\nLooking into v3 work\nMatt Farina:\nReviews\nCrypto signing delivered with Matt Fisher\nTaylor:\nGoing to be reviewing this week\nBrian: Meta tables in lua to override operators\nAdam:\nWorking on builder to manipulate charts in lua\nPopulate issue\nMatt Fisher:\nPR reviews\nHelm v3 action package refactoring\nMartin: Library chart feature merged\nScott:\nLaser github app\nDiscussion\nLua plans?\nhttps://github.com/jdolitsky/goluamapper\nBrian working on an idiomatic go interface in lua\nNot going to be modelling charts at start with lua\nDesign shortly on the syntax of lua in charts\n1MB limit w/ no tiller?,\nIn Helm dev question about map being too big\netcd limit: 1M . Not a limitation of Helm. All Kubs objects have this issue.\nhttps://github.com/etcd-io/etcd/blob/master/Documentation/dev-guide/limit.md#request-size-limit\nSome discussions on using an alternative backend to etcd\nAssignments\nIssue sherpa: Martin\nModerator: Taylor (not Josh)\nNotes: Nikhil\nFebruary 14, 2019\nAnnouncements\nHelm 2.13.0-rc.1 was released yesterday\nHelm repo working group call cancelled. Now gone to the OCI space.\nJoin CNCF #artifact-registry\nHelm Summit Update\nWorking with CNCF on a venue for September\nMay need sponsors\nIf your company would be willing, please contact Michelle and I will get you in touch with the right people\nStandup\nMichelle\nMerged PRs\nWorking on POC for Helm test v3\nIterating on the initial helm test proposal for v3\nButcher\nWorking on grpc changes\nReviewed martins patch\nDiscussion\nScott: 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?\nAdam: 2 LGTM policy for dev-v3 branch\nFisher: will add this to the CONTRIBUTING.md in dev-v3\nAsking for status: What is the status for Helm Summit 2019?\nDiscussed in announcements\nFisher: bringing back up issue #2039. How do we want to cryptographically sign Helm releases?\nButcher: TUF/Notary looks like the right approach for v3\nFor v2 we probably want to cryptographically sign all the assets and upload the signatures via Circle\nSupport \"delete\" resource policy in Helm 2? (PR)\nFisher will have a look at it next week\nAssignments\nIssue sherpa: matt fisher\nModerator: adam\nNotes: martin\n\nFebruary 7, 2019\nAnnouncements\nGood First Issue App added\nTwitter account will tweet out our issues if we put a label on it\nStandup\nJosh\nHelm 3 initial registry stuff merged! See PR #5243\nWe’ll have to continue the discussion around how this will affect the rest of the Helm commands\nMatt Farina\nMerged some PRs, talked on some OCI stuff\nMichelle\nGoing to work on some new helm test stuff\nBrian\nIsolating difficult APIs in lua spec for manipulating tables\nHybrid array+hashtable\nRefactoring on call stack to support proper tail recursion\nMatt Fisher\nHelm 3 PR reviews, PR reviews\nLooking at some Helm 3 things this coming week\nGiving dev-v3 a try on Windows, found some bugs\nCFPs!\nTaylor\nWasn’t able to do much this week. Will be back to issue stuff and PRs this next week\nNikhil\nLooking into curating issues in issue queue\nAdam\nHelm 3 stuff, mostly code reviews\nOrganizing top-level stuff\nMartin\nMix btw v2 and v3\nTriaging a bunch of issues\nStarting on PR reviews\nV3: broke down PR for -\n\n\nDiscussion\nWhat’s the status on #5210? Are we ready to cut a v2.13.0? [fisher]\nUpgrading GRPC for better TLS connection handling\nNeed to check w Matt Butcher\nWhen the protos changes, people need to recompile their clients\nIs there a way for us to fix issues without updating grpc?\nSome 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]\nWhat’s the timeline for 2.13?\nFisher will check with Butcher offline on the prior discussion item to get an idea how far out we are from a 2.13\nIs this proposal are runner for v2/v3: https://github.com/helm/helm/issues/3279 ?[mhickey]\nDifferent than other tests, leaves pods around\nTake a look at v3 proposal (link me)\nHelm Summit update [michelle]\nStill confirming an Amsterdam venue\n2nd week of september\nWorking on program committee application\n\n\nGSoC ?? [josh]\nOoo missed the deadline (yesterday)\nAssignments\nIssue Sherpa\nFisher\nAdam (v3)\nMartin (v2)\nModerator: Adam+Michelle COMBO\nNotes: Martin\nJanuary 31, 2019\nAnnouncements\nStandups\nBrian\nWorking on refactoring\nMatt Farina\nAdnan Abdulhussein\nMichelle Noorali\nTaylor\nReviewed atomic flag PR\nWorking on issues/PR this week\nMartin\nv3 work: Lib chart feature\nHelm v3 status https://github.com/helm/helm/projects/1\nInitial registry support PR: https://github.com/helm/helm/pull/5243\nDiscussion\nConsider installing https://github.com/rajatjindal/goodfirstissue for helm org (Rajat)\nWhat is Helm support of CRDs? Can it handle large CRDs? Open issue: https://github.com/helm/helm/issues/4697\nThis will need to go to SIG Apps because of the wider scope of what this will affect.\nHelm Summit Update\nWorking on locking down the venue and getting the CFP things ready\nhttps://github.com/helm/helm/issues/3279 : Proposal for v2/v3?\nhttps://github.com/helm/helm/issues/5242 CNAB\nAssignments\nIssue Sherpa: Nik\nNotes: Josh\nModerator: Adam\nJanuary 24, 2019\nAnnouncements\nCVEs for Helm+ChartMuseum vulns\nHelm: (link me)\nChartMuseum: (link me)\nHelm Summit is being rescheduled from March to the second week of September\nNeed more time to lock down venue + give travel time to attendees\nStandups\nMichelle\nIssues and PRs triaging\nActive in #helm-dev\nScott\nMet w farina about Helm Hub deployment automation\nSetup on CNCF service\nMatt Butcher\nhttps://github.com/helm/helm/issues/3480 : connect btw helm+tiller having issues, unsure why. “write: broken pipe”\nMatt Fisher\nInvestigated #3480\nHelm 3 repo discussions\nTrying to offload some work from Adam\nOCI docs based on meeting yesterday\nJosh\nOCI/Helm repo convos\nNeed to look into search + auth\nWorking on dev-v3 fork for push/pull\nMatt Farina\nHelm Hub: how do we scale? # of charts, user experience, etc\nPotentially contractors from CNCF\nOCI fun, specs\nNikhil\nClosed out a couple issues, sherpa-ing some others\nAdnan\nMonocular issue/PRs\nMartin\nIssue sherpa-ing, passing things along\nClosed out some PRs\nLooking into v3 features\n\n\nHelm v3 status https://github.com/helm/helm/projects/1\nDiscussion\nCould 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)\nWe need a clear policy...which is that v3 IS accepting fixes.\nNew label: #needs-v3-fix\nPlace this info somewhere, contributing.md (henrynash to do)\nWhat is Helm support of CRDs? Can it handle large CRDs? Open issue: https://github.com/helm/helm/issues/4697\nNeed to punt to next week when Adam returns. He had some actions on this and we don’t know the state\nChartMuseum + Monocular in Helm 3?\nMonocular: need to change to own the Helm Hub experience\nChartMuseum: ???\nWhat do we invest in terms of Google Summer of Code\nGoogle Summer of Code: what projects should we propose?\nDeadline for org submission: Feb 6\nDeadline for students: April 9\nAssignments\nIssue Sherpa:\nNikhil\nMichelle\nNotes: Michelle\nModerator: Fisher\n\nJanuary 17, 2019\nAnnouncements\nHelm and ChartMuseum security releases out\nStandups\nNikhil (had to miss call due to a conflict)\nLast week, mostly worked on curating our issue queue. Hope to have some time to spend on it this week as well.\nFisher: had to miss due to an AKS all hands\nLast week: participating in the helm 3 repo discussions, getting ramped up with Helm Summit committee prep, triaging tickets\nThis week: wants to write a blog post on the current status of the Helm 3 repo discussions\nButcher: had to miss due to an AKS all hands\nFarina:\nChartMuseum and Helm security release work\nTook charts in container registries to the OCI for direction. Jimmy Z has a strawman that was generally accepted at the OCI meeting\nJosh\nChartMuseum security release v0.8.1\nChart-scanner to check for the vuln: https://github.com/chartmuseum/chart-scanner\nThings moving along w Helm 3 repos stuff, chats w OCI team\nLife status changes\nMartin\nDelivered a feature for v3\nDid issue queue triaging\n\n\nHelm v3 status https://github.com/helm/helm/projects/1\nDiscussion\nHelm 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]\nShould we support the --token and --insecure flags on helm v3? These are flags on kubectl. https://github.com/helm/helm/issues/5159\nDiscussion on Bazel  in helm… https://github.com/helm/helm/issues/5160\nLikely pushing to a plugin\nAssignments\nIssue Sherpa:\nMartin + Adam\nNotes: Josh\nModerator: Farina\n\nJanuary 10, 2019\nAnnouncements\nKubeCon+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.\nParallel flag PR got merged on helm test! Woot!\nStandup\nJosh\nBeen working on getting helm push/pull working. Has a working example! Should be ready to PR in a week\nFisher\nNot too much to report this week. Going in to the helm 3 repo discussion and continued issue triaging\nMichelle\nBeen issue triaging on issues for the past few weeks\nIf you aren’t working on Helm 3, we need your help to triage the large number of issues that still need it\nTriaging #5118\nScott\nHelping in the different repos as time permits\nWorking on a tool to help people get a helm repo from a git repo is on hold\nAdnan\nNot much for this week\nAdam\nPretty much just Helm 3 work\nMatt Farina\nWorking in the fun filled world of process. Need to get process things in place like a security reporting process before we can graduate\nHave been meeting with the OCI people\nNikhil\nJust got back from holidays, not too much to report from last week\nWill be issue triaging this week\nTaylor\nTry to spend a little time tomorrow to triage the issue queue\nButcher\nTrying to stay on top of the repo stuff\nDoing a bunch of Helm 3 work\nGetting close to having Helm Summit EU dates\nBrian\nGetting back into the swing of things after holidays\nHelm v3 status https://github.com/helm/helm/projects/1\nMerged a few PRs in to the v3 branch\nMatt Farina is working on an actions package so other projects can consume it if desired\nCode cleanup around build targets, makefile, infrastructure\nAdam is focusing on the chartutils package\nDiscussion\nHelm Summit 2019 - When? Where? How to help [carlos]\nMichelle and Adam volunteered to start getting things rolling with CFP and the like\nShould we cut a v2.12.2 with https://github.com/helm/helm/pull/5132? [fisher]\nWe should validate that this is the same validation that k8s uses\nIs this something that should be documented vs. a bug fix?\nThere was a new name restriction put in place for 2.12.0. This wasn’t quite up to spec to support subdomains\nAll hands on deck with issue triage and PR review [michelle]\nIf you’re a core maintainer and not working on helm v3, please help in the issue and PR queues this week.\nIf 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.\nHelm 3 repos working group update\nGo lib “oras”  for pushing any file to OCI-friendly registry: https://github.com/shizhMSFT/oras\nDemo:\n\nCleaning up hooks - https://github.com/helm/charts/pull/10400 [adnan]\nShould Helm CLI should have an option to delete hooks & other dependent things on delete\nAssignments\nIssue Sherpa:\nMichelle + Nikhil + everyone\nNotes: Scott\nModerator: Adam\n\nJanuary 3, 2019\nAnnouncements\nHelm 3 repos\nOras: POC pushing arbitrary data to a container registry\nhttps://github.com/shizhMSFT/oras\nStandup\nTaylor\nWorking on diff issues and PRs as needed\nMichelle\nTriaging issues\nWants to pair with people interested in issue triage\nBrian\nCoroutines for Lua VM, Lua compiler\nFisher\nKnows rust now\nJosh\nWorked on oras\n?\nHelm v3 status\nLikely same place as pre xmas\nDiscussion\nOrganize/sort release notes #5119\nBugs and features are not distinguished\nAlso see https://goreleaser.com\nFeedback https://github.com/helm/helm/pull/5110\nAdding things to “helm create”\nNeed to work w charts maintainers\nThey have been assigned to the issue\nHelm repo updates\nWorking w OCI on next steps\nWhitelisting mediatypes\nSearch spec, to support “helm search” against only charts (not images)\n#opencontainers IRC channel on freenode\nOCI mailing list: https://groups.google.com/a/opencontainers.org/forum/#!forum/dev\nAssignments\nIssue Sherpa (2):\n1: Matt Fisher\n2: Michelle\nNotes:\nTaylor\nModerator:\nJosh\n```\n"
  },
  {
    "path": "community/meeting-notes/2020.md",
    "content": "---\ntitle: Helm Minutes for 2020\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/meeting-notes/2020.txt\n-->\n\n```txt\nDecember 17, 2020\nAssignments for this meeting\nModerator: Marc\nNotes: Karena\nIssue Triage: Butcher\n\nAnnouncements\n3.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.\nHalf PRs still open\nOCI- found issues, Farina will work on it over the break\nWhatever gets in this year is what will land\nThis 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.\n\nDiscussion\n[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\nBridget: it’s in the 3.5.0 milestone - when do those get reviewed/merged?\nFarina: hopefully reviewed by end of the week\nDecember is a terrible time to get features into Helm\nFarina: with mature projects, esp this time of year, takes longer. Slower at merging since reviewing with other maintainers to consider implications\nJoe: concerned since using a fork for their linter now\nJoe: wondering as first time contributor what should have done differently\nFarina: thank you for the feedback\n[Shoubhik Bose] Engineering architect for GitOps\nWould like to have more disciplined approach to contributing\nBest way to understand from list of PRs for where to contribute?\nLooking at milestones\n[Bridget] yes, looking at milestones is great\n[Farina] one of best - look at PRs and walkthrough\nStart walking through and test\nGive feedback - not just when something is wrong, but when something is good\nFor people who want to be maintainers - get the title once you’re already doing it\n[Bridget] what if we run a new Helm maintainer workshop\nWalk through the process\nHave more senior maintainers act as mentors\nBridget to work with Butcher and CNCF\n\nAssignments for next meeting (Jan 7th!)\nModerator: Bridget    \nNotes: Karena \nIssue Triage:  [at least 3 needed] \nMatt Farina\nShoubhik for non-core maintainer issue triage\nJosh for 3.5 issues\n\nDecember 10, 2020\nAssignments for this meeting\nModerator:   Marc K   \nNotes: Bridget Kromhout\nIssue Triage:  Matt Farina  \n\n\nAnnouncements\nHelm 3.4.2 patch release yesterday\n3.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.\nThe 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.\nK8s.dev contributor celebration this friday -> sunday \nhttps://www.kubernetes.dev/events/kcc2020/\nKubecon CFP closes Sunday 13th 11:59p.\nhttps://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/cfp/#overview \nBridget volunteers to review your talk proposal!\n\n \nDiscussion\n[Tim St. Clair] - Helm 4, modularity, and pluggable templating.\nTim St Clair: Saw KubeCon NA 2020 talk about past/present/future\nTim St Clair: Is familiar with templating issues\nTim St Clair: Used to be Heptio/RH, and in vmware they’re seeing ytt - but the templating theme keeps repeating itself\nTim St Clair: Interested in an abstraction layer around charts itself\nFarina: in Helm 2 we had a mechanism for setting templating engine - “engineyard”\nFarina: and nobody ever extended it! Existed, and nobody used it\nTim: in this moment, the demand is now here\nButcher: the right step is probably a HIP - now is a good time\nFisher: possible opportunity of revving to API v3.\nFisher: in a HIP we could discuss backwards compat, use cases, post-rendering\nMarc: Tim, would you also be providing implementation?\nTim: I’d be working with a team to do so\nHelm v3.5.0 [Farina] - this is less than a month away - the core maintainers should please review over the next two weeks\nThis is a small release but we do want to get it ready\nHelm meeting calendar vs Helm release calendar [Marc]\nFisher: no objection to merging - we also use github milestones to communicate\nFarina: calendar is also for us\nIntroductions\n\tMark Fisher, Aaron Hurley, John Ryan - Tanzu team - https://github.com/helm/community/blob/master/hips/hip-0001.md \n\tKarena Angell - Red Hat \n\tJoe Julian - d2IQ - Helm needs for their customers\nStorage backend needs: https://github.com/helm/helm/issues/8977 [Joe Julian]\nJoe Julian - label selectors don’t work - either break up by namespaces or query the predictable-name releases by name\nButcher: there is a pluggable system for alternative data stores\nJohn Ryan: how about WASM, Lua, etc?\nButcher: web assembly is an idea on the table\n\n\nAssignments for next meeting \nModerator:    Marc\nNotes: Karena\nIssue Triage: Butcher\n\nDecember 3, 2020\nAssignments for this meeting\nModerator:    Josh Dolitsky\nNotes:       Dan Garfield\nIssue Triage:  Bridget, Fisher, Martin  \n\n\nAnnouncements\n Next patch release (3.4.2) will be Wednesday Dec 9 - add relevant issues/PRs to https://github.com/helm/helm/milestone/106 [Bridget]\n[Dan] Few things still need to happen in milestone. \nReview bugs in issue queue for 3.4.2 Tuesday is last day to put in\nInterested in being a Helm maintainer, reach out to Farina, shadow on Wednesday release available.\n\nDiscussion\nChart Examples in Docs [Bridget]\n[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)  \n[Bridget] Adam and I previously discussed a helm-org repo with illustrative example charts \n[Bridget] Not intended to be supported as production-ready, but meant to forestall the inevitable changes if we point to a third party\n[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?\n[Dan] How do we handle mentioning deprecated charts…\nFarina: Take something like ChartMuseum and point to it as example\nFarina: Or… Create examples repository and use it as example charts, use providence files etc all best practices. \n[Josh] Should we have examples of more than just charts? \nFarina: Let’s make sure we can use CI to test things, so, keep separate repos\nResolution: 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.\nRe: 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.\n\nPassing arguments to post-renderer [Marc]\n(https://github.com/helm/helm/pull/9047) \nIdea is to split on space:\n--post-renderer \"kubectl kustomize calico/kustomize\"\nBackwards-compatibility issue?\n--post-renderer \"./my binary.exe\"\nDo we need a flag e.g., --post-renderer-args\n[Farina] breaking on a space is potentially unreliable, use environment variables instead\n[Marc] \nFisher: https://github.com/helm/helm/blob/d3d1ceab4f30ef792195f6a2b0fbf36a3b300340/pkg/postrender/exec.go#L45-L67 \n[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\n[Marc] the goal here is to allow usage of “kubectl kustomize” as a post-renderer\nResolution: Marc will review and comment in the PR\n \nMoving size labels to GitHub action [Farina]\nCurrently a service hosted in helm hub cluster\n[Farina] Our size labels all come from a deprecated repo. Want to port into Github Actions instead\n[Fisher] Github Actions have been very reliable. Very in favor\nConclusion: Farina will start working on moving sizing labels to github actions\n[Fisher] LGTM\n\nTranslation PRs… when multiple people are committers and the lgtm comes from a committer? [Farina]\n[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?\n[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.\n[Bridget] Issues arise in particular if they forked some time ago and are translating an old version of the page.\n[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.\n[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. \nConclusion: Garfield will go do some investigation into what might work best and discuss with Bridget and come back.\n\n[Josh] Congrats to Bridget and Fisher for winning the CNCF chopping wood and carrying water award!\n\n[dlipovetsky] action.List client is unable to return a list of all releases (#9028)\n[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. \nOpen Discussion\n\nAssignments for next meeting \nModerator:   Marc K   \nNotes: Dan Garfield\nIssue Triage:  Matt Farina\n\n\n[no meetings Nov 19 2020 (KubeCon) or Nov 26 2020 (Thanksgiving)]\n\n\nNovember 12, 2020\nAssignments for this meeting\nModerator:    Martin Hickey\nNotes:      Josh Dolitsky\n\nAnnouncements\nArtifact Hub has experimental support for OCI charts [Farina]\nUsing oci:// you can add in the artifact hub your OCI repo\nSecurity scanning supported\nhttps://artifacthub.io/\nHelm 3.4.1 released - https://github.com/helm/helm/releases/tag/v3.4.1 \nFirst of release cycle\nHelm blog: https://helm.sh/blog/helm-release-process/ \n“First Patch Wednesday”\nHelm v2 EOL and stable/incubator repositories deprecated on this Friday 13th November\nBlog post by Butcher in progress\nThats tomorrow\ncharts.helm.sh new home for stable and incubator\nKudos Matt and Scott (and charts maintainers)\nPlease use Helm 3, no longer will receive fixes on Helm 2\ntomorrow, friday the 13th\nMartin is OK with Tiller\nKubeCon/CloudNativeCon next week (17th - 20th Nov)\nHelm sessions: (link me) https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/program/schedule/\nButcher+Farina+Bridget\nhttps://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\nWednesday, November 18 • 4:55pm - 5:30pm\nBooth duty - bring your questions!\nOffice hours\nSlot 1: Wednesday, November 18 • 3:00pm - 3:45pm\nSlot 2: Thursday, November 19 • 5:00pm - 5:45pm\nSlot 3: Friday, November 20 • 3:00pm - 3:45pm\n\nDiscussion\nRequest for Helm mapkubeapis plugin to join the Helm Org https://github.com/helm/community/issues/157  [Martin]\nFollowing the new HIP process, #?\nFarina to take a look and help drive it along\nUpcoming call schedule\nWill there be a dev weekly call next week (conf week)? [Martin]\n[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?\n[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?\n[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.\n[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.\nDo we have better/more stats on chart downloads now? [Bridget]\n Nope! Because GitHub Pages\nCharts that upgrade with an issue when the previous version used a deprecated API. Ref https://github.com/helm/helm/issues/9014 [Martin]\nSomething using deployment appbeta (old thing), when you upgrade the chart, the old thing is not deleted due to new API versions\n“Documenting is better than magic” (lets document this edge case)\nLink to release calendar on helm.sh? [Marc]\nMarc will make a PR\n\nAssignments for next meeting (Dec 3)\nModerator:    Josh Dolitsky\nNotes:       Dan Garfield\nIssue Triage:  Bridget, Fisher, Martin  \n\n\n\nNovember 5, 2020\nAssignments for this meeting\nModerator:  Marc K \nNotes:    Bridget Kromhout\nIssue Triage: TBD\n\nAnnouncements\nFarina: the stable and incubator repos are about to leave artifact hub\nFarina: we cut the 3.4.1 release on Wednesday\n\nDiscussion\nDeprecation(s) Status Check [Bridget]\n8 days to go\nDo we want a super-minimal blog post that just explains that if you do nothing else, you should do this:\nhelm repo rm stable\nhelm repo add stable https://charts.helm.sh/stable\nFarina: maybe a blog post to pull their stuff out of stable and incubator? Git history?\nJoe Julian: remind people to check requirements yaml\nBridget: reach out to Scott Rigby and Matt Farina; draft last-minute tactical “what you must do” blog post.\nHow do we communicate essential info about changes with people we’re missing via our usual channels? [Farina]\nBridget] AKS emailed customers; GKE can’t do that but will do outreach\n[Farina] Do we have any Digital Ocean contacts?\nFarina: Minikube builds in a pop-up\nMarc: in a deprecation you can mention it in the tool itself\nPaul C: corporate users aren’t big fans of MOTD from internet\nBridget: get their service providers to reach out, when possible?\nMartin: get people the message when they upgrade their tool\nMarc: perhaps optionally enable “helm announcement”?\nFarina: will consider and start a HIP\nFrom Paul Czarkowski to Everyone: (11:43 AM)\na 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.\nFrom Paul Czarkowski to Everyone: (11:44 AM)\nthen we could have an announcements repo that has an index.yaml but no charts so people can subscribe to announcements by adding the repo\n\n\n\nRelease histories not pruned. Since they are failures… should they be? https://github.com/helm/helm/pull/8881 [Farina]\nFarina: pruning only happens after a good installation - could end up with many failed\nJoe Julian: happens thousands of times in CI/CD\nMartin: technically a bug - but the logic from the last deployed release is valid\nMarc: let’s continue the discussion in the PR\n\nLint 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]\nShould 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?\nFarina: 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?\nFarina: we should merge both\nJoe Julian: I think the one you're thinking of talked about multiple empty documents in the file:\n---\n---\n---\n \nAre internal commands subject to backwards-compatibility (helm docs) [Marc]\nFarina: Let’s put it behind a flag\n\nWhat’s the best source of replacement examples for the docs? (assuming we may not want to point at stable anymore) [Bridget]\nFarina: sounds good - could document best practices\n\nBridget: who’s got questions or concerns around the changes?\nJoe Julian: we’ve been telling customers they have to upgrade\nMartin: you don’t have to change the version of Helm - but do have to point to the right places\nMarc: at a minimum, 2.17 would be important because of Tiller.\nFarina: we don’t have a solid date on when the GCR buckets will stop working\nJoe Thompson: question about the deprecation - what’s the emergency procedure in place?\nFarina: the current plan is every chart will point to an archive that gives an error\nDan Garfield: should we yank it early?\nBridget: let’s not make breaking changes during shopping holiday change freeze\nMartin: and remember, the archived charts will still exist.\nPaul: let’s not disrupt people for no reason\nFarina: charts.helm.sh is going nowhere. The google location is what we don’t control.\nMartin: so, change your URLs to charts.helm.sh!\n\n\nAssignments for next meeting\nModerator:    Martin Hickey\nNotes:      Josh\nIssue Triage:   Farina\n\nOctober 29, 2020\nAssignments for this meeting\nModerator:  Adam Reese \nNotes:    Bridget Kromhout\nIssue Triage: Matt Fisher & Bridget Kromhout\n\nAnnouncements\n 3.4 & 2.17 [Farina]\nupgrade!\n\nDiscussion\nDeprecation(s) Update [Farina]\nFarina: Friday November 13th, Helm v2 support ends and charts stable/incubator go into archive mode\nFarina: Blog post going out tomorrow\nFarina: CNCF will post things Friday and Monday - also, Kube Weekly\nFarina: Removing stable and incubator from artifact hub on Nov 6th\n[Scott] discoverability will increase as charts get relocated to new repos\nFarina: helm/helm CI won’t break with the Docker changes\nHelm Hub -> Artifact Hub move [Farina]\nCan we get this PR looked at for the 3.5 milestone or before? Replace Helm Hub with Artifact Hub · Issue #8626 · helm/helm [Bridget]\nFarina: it pays to add your items early!\nFarina: 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\nBridget: does this affect stats?\nFarina: we can get that now (though it’s not super useful data - unsure what some of these queries are)\nScott: of course we want to decrease our maintenance burden but we might want data\nButcher: we shouldn’t be in the critical path - let’s instead help Artifact Hub craft good stats/reporting\nFarina: reach out to artifact hub maintainers for stats/data\nFarina: let’s redirect to artifact hub (affirmed by the call)\n\nDependabot k8s patch updates and Helm patch releases [Farina]\nCheck on packages that have bugfixes, if we consume them\nFisher: sometimes these affect helm - a recent client release did\nAdam: let’s look at them and (usually) merge\n\nFocus on recruiting new maintainers [Butcher]\nButcher: let’s form a sub-team to strategize about solving this\nBridget: volunteers\nAdam: people may not want new commitments this time of year\nFisher: we could start doing up-front work on docs and testing\nKarena 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.)\nButcher: as a group we need to identify who would make good core maintainers\nButcher: we can mention it on calls\nFarina: have we documented being a maintainer?\nAdam: yes - it’s documented (https://github.com/helm/community/blob/master/helm-maintainers-onboarding-guide.md) \nBridget & Farina will follow up with docs\n\n\nGenerating docs for helm-www (not done for 3.4?) [Marc]\nhttps://helm.sh/docs/helm/\nv2? https://github.com/helm/helm/issues/8869 \n[Bridget] this is a manual process - https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs \nBridget and Marc will sync\n\nupdate chart repository dependency references https://github.com/helm/charts/issues/23971 [Marc]\nFarina and Scott will pair on this\n\n[joe] Can I get this merged? Reduce linting severity for users of out-of-date kubernetes · Issue #8608 · helm/helm \nDeprecated APIs were the reason originally - upstream has now started keeping this data, and this is useful\nFisher: this has one LGTM - Adam will look at it\nFarina: added to the 3.5 milestone\n\nAssignments for next meeting\nModerator:   Marc\nNotes:     Bridget Kromhout\nIssue Triage:  TBD\n\n\nOctober 22, 2020\nAssignments for this meeting\nModerator:  Fisher\nNotes:  Martin\nIssue Triage:   Farina\n\nAnnouncements\n (none this week)\n\nDiscussion\nHelm v3.4 and v2.17 [Farina]\nRC1s out\nPlan is to release on Monday & blog post Monday as well\nMain release features:\nDefault location for Tiller is GHCR (not to be confused with GCR!)\nNew helm repo location\nCriteria to accept dependabot PR [Marc]\nCobra 1.1.1 https://github.com/helm/helm/pull/8916\nWhat is the criteria for sub-dependencies brought in by dependabot? [Marc]\nIs test passing sufficient? Fisher thinks for the most part it is good to merge\nThere can be exceptions like k8s from time to time [Fisher]\nNeed to check if licenses are acceptable [Farina]\nHIP 0002: Announced release dates [Marc]\nOk to announce 3.5 for January 13th, 2021 once 3.4 released?\nOk to start monthly cycle for patch releases once v2 is done?\nhttps://github.com/helm/helm-www/pull/869\nOnce 3.4 is released, then we would like to start announcing major releases. Also patch release announcements. Is this ok to go? [Marc]\nAdded those milestones and added dates to them [Farina]\nWe should add a calendar to add the dates in place. Marc is going to add the calendar to the HIP.\nHelm Charts Repo Switchover timeline [Vic]\nMove charts storage over to GH Pages\nImplement URL switchover in Helm 2.17\nMove index.yaml in GCS to point to new GH pages URLs\nCreate specially crafted chart that presents users with a hard failure \nMark all charts as deprecated\nSwitch index.yaml to point all charts to the specially crafted chart\nReduce the size of the index.yaml\nDisable public access to buckets\nChart producers: Repos switching but need to move charts to new host [Farina]\nChart consumers: Switching stable/incubator but repo is going to become an archive [Farina]\nOngoing plan: Martin points out that some still haven’t changed - who then are (by default) archived\n“Band aid” needs to be ripped off wrt obsolescence of charts. So charts are messaged that the charts are deprecated. [Farina]\nMessage so that users know that charts are deprecated [Dan]\nLint 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]\nAnswer in the issue [Farina] [Fisher]\n\nAssignments for next meeting\nModerator:  Adam Reese \nNotes:    Bridget Kromhout\nIssue Triage: Matt Fisher & Bridget Kromhout\n\nOctober 15, 2020\nAssignments for this meeting\nModerator:  Marc\nNotes:  Bridget\nIssue Triage:   Martin & Farina\n\nAnnouncements\nHelm turns 5. Started Oct 19, 2015 (first committed). [Farina]\nButcher points out it’s like 80 in internet years\nDiscussion\nStable and Incubator repos [Farina]\nShould we consider extending the date to make helm/charts read-only, since it has taken longer than expected to relocate stable charts [Scott]\nScott: 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\nPaul: read only timeline is still good IMO\nMuch discussion on TOC list etc\nFarina: lesson learned: don’t use a bucket name - use custom domains/CDNs for flexibility\nFarina: Kubernetes credits for GCP only apply to k8s itself, not other CNCF projects, so it’s a funding issue to keep these from\nButcher: GitHub has raised bandwidth caps to allow for chart repos - we will make public announcement/thanks next week\nScott: about 45min to pull down the index file - in-flight\nFarina: should we update the URL in people’s configs?\nVic: 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.)\nMartin: option 2 good, because otherwise people will never update\nVic: this is a happy medium - but my main concern is not wanting to blow away their resources.\nFisher: are there any stable or incubator charts signed by chart authors, which might lead to a failure?\nFarina: no, nothing is signed.\nFisher: Can we swap out what they receive without telling them?\nBridget: If we’d had a custom domain in the first place they’d never know when we swap out back-ends, unless it breaks \nVic: a hard fail is safest and a message telling them the path forward\nFarina: we need some kind of direction in 2.17 that tells people what to do.\nButcher: what was the argument against automatic, other than proxies?\nJoe Julian: many customers are behind proxies with air-gapped clusters\nFarina: proxies sometimes limit domains/routing - we should print a message in logs\nFarina: we will add something to 2.17 and 3.4 for this. Also: how do we handle stable/incubator?\n1 - do nothing/404\n2 - redirect to new download locations (will err eventually)\n3 - we could craft a required with a variable that does not exist to throw an exception - but needs investigation/testing\nTimeline: we need a solution before Nov 13 \n2 weeks before, we could have all charts fail or could give a message\nFisher: client caches locally so without helm repo update, we won’t have them getting updates to their local\nLet’s bring this to chat/cartographers list\nFarina will look into whether this kind of chart action breaks a cluster.\nVic looking into how much the bill is the index file vs something else\nFarina: there is metadata not used - could save bandwidth there\nButcher: 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\n\nDeferred to next week:\nHelm v3.4 and v2.17 [Farina]\nImpacts of gopkg.in/yaml.v2 v2.3.0 [Marc]\nDependency of Cobra 1.1\nhttps://github.com/helm/helm/pull/8890\nHIP 0002: Announced release dates [Marc]\nWaiting for 3.4\nhttps://github.com/helm/helm-www/pull/869\nHelm Charts Repo Switchover timeline:\nMove charts storage over to GH Pages\nImplement URL switchover in Helm 2.17\nMove index.yaml in GCS to point to new GH pages URLs\nCreate specially crafted chart that presents users with a hard failure \nSwitch index.yaml to point all charts to the specially crafted chart\nReduce the size of the index.yaml\nDisable public access to buckets\n\nAssignments for next meeting\nModerator:   Fisher\nNotes:    Martin\nIssue Triage: Farina\n\nOctober 8, 2020\nAssignments for this meeting\nModerator:  Marc\nNotes:  Josh\nIssue Triage: Farina\n\nAnnouncements\nArtifact Hub takes over for Helm Hub [Bridget]: https://helm.sh/blog/helm-hub-moving-to-artifact-hub/ (some docs updates pending)\nThere was a CNCF blog post about \"Important Helm Repo Changes & v2 End of Support in November\": [Scott]\nhttps://www.cncf.io/blog/2020/10/07/important-reminder-for-all-helm-users-stable-incubator-repos-are-deprecated-and-all-images-are-changing-location/\nFrom Dan\nWent out in the newsletter\nDiscussion\nHelm Lightning Talk @ KubeCon [Karen]\nDeadline to fill out the form is Oct 11 \n15 minute format\nDoes anyone have ideas? Highlight something special?\nBridget: Karen talks w/ each maintainer about something specific\nWill be pre-recorded\nHelm Workshop: v2 to v3 - Oct 21 [Karen]\n112 attendees registered to participate, as of this morning!\nplease sign up on Google sheets so we know you'll be there to help!\nWe need to register too (it’s free and easy with your existing LF account): https://events.linuxfoundation.org/helm-v3-workshop/ \nStill need “runners” - \nCan expand to non-maintainers if needed\nSwag will be involved\n\n\nHelm Project Pavilion/Office Hours [Karen]Three 45-min office hours \nLast kubecon, was not effective. Numbers disappointing, 3 clickthroughs according to stats\nInstead of this we could do office hours (3 45min sessions)\nMartin: it worked in San Diego (in person)\n3.4 release planning [Farina]\n3.5 planned for january\nKube 1.19 support not in a release yet\n3.4 Milestone: https://github.com/helm/helm/milestone/94 \n7 open items\n“Test” -scott 😂\nFarina: Let’s set a date: next wednesday: 10/14/2020\nMartin: update modules in 2.x?\nShould the 3.4 release include https://github.com/helm/helm/pull/8626 (Artifact Hub update) [Scott]\nNo hub search in 2.x 👍 Updated note above\nFarina: let’s cut 2.17.0 before 3.4 so the most current is a 3.x\nJobs and --wait flag [Farina]\nhttps://github.com/helm/helm-www/pull/884#discussion_r501849243\nIf a job is part of a hook, it waits. But if part of a chart - relies on --wait flag\nPeople have diff views on what wait means\nSpecial case for jobs?\nScott: could break alot of charts\nMaybe new flag? --wait-jobs or --wait-for-jobs\n “How Projects Join the Helm Organization” proposal by Matt Butcher seeks your input and LGTMs: \nhttps://github.com/helm/community/pull/149 [Bridget]\nBridget has impersonated dr. butcher\n2 approvals from org maintainers needed\nSlack integration - let’s give this a yes (my recommendation - I don’t see a down side) or a no: [Bridget]\n https://github.com/helm/helm/issues/8610\nLow-hanging fruit to make people happy\nAllows people to view issues within slack\nOCI Pull PR: https://github.com/helm/helm/pull/8843 [Josh]\nSlight miscommunication but resolved\nCould base change atop original work so contributor gets points in the commit history\nhttps://stackoverflow.com/questions/7442112/how-to-attribute-a-single-commit-to-multiple-developers \nCould credit him in notes\nMartin: API deprecation notes - may need issue\n\nAssignments for next meeting\nModerator:    Marc\nNotes:    Butcher\nIssue Triage:   Martin & Farina\n\n\nOctober 1, 2020\nAssignments for this meeting\nModerator:  Adam\nNotes:  Scott\nIssue Triage: Farina\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n “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]\nPlease review!\nHelm maintainer session for KubeCon North America 2020: https://sched.co/ekHz [Bridget] Wednesday, November 18 • 4:55pm - 5:30pm Eastern \n- a good time to be in the CNCF Slack channel for the maintainer track so as to discuss/answer questions (during and after)\nRemoval of governance section on first org maintainers election [Farina] https://github.com/helm/community/pull/148 \nPR in - votes in - will be removing that section.\n\nDiscussion 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.)\nDeferred from last week: Announcing migration needs in CNCF blog/newsletter [Dan Garfield]\nCurrent draft here https://docs.google.com/document/d/1D_cbuxObeD6yjKUmfcRjF_i1gyKnGZxG3intv57xw1A/edit?usp=sharing \nDeadline October 5th\nReviewed already by some Helm team members (thanks Karen, Bridget, Josh)\nDan will work with Scott (and Matt Farina if he has time?) in Slack before the deadline\nDeferred from last week: Helm Hub -> Artifact Hub timeline [Farina]\nHoping to do next week. Defer again to next week\nDeferred from last week: Slack integration - do we want to allow this? [Bridget]\nhttps://github.com/helm/helm/issues/8610 \nIs there any good reason to say no to this? Please look if you can\n End User Story for KubeCon Keynote Project Highlight [Karen]\nDue Oct 5\nAny ideas?\nIf so, please pass along to Bridget and Karen\nHelm Workshop: v2 to v3 - Oct 21 [Karen]\nLiving Event doc\nStill need help with staffing presentations (2) and runners (10) for workshop\nFeature detection in Helm (lookup function) https://github.com/helm/helm/issues/8834 [Farina]\nLooking for a possible hack for older versions of Helm 3 before version was introduced\nAdam will think about it\n[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?\nFarina: could probably add a flag?\nAdam: should this be built into Helm, though?\nFarina: 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)\nScott: https://github.com/helm/helm/issues/7173#issuecomment-562648387 addresses some of this. Specifically linking to https://github.com/helm/helm/issues/7082\nTo be continued\n\nAssignments for next meeting\nModerator:   Marc Khouzam\nNotes:   Josh Dolitsky\nIssue Triage:  Matt Farina\n\n\n\nSeptember 24, 2020\nAssignments for this meeting\nModerator: Martin\nNotes: Bridget\nIssue Triage: Farina\n\nAnnouncements (items of general interest like releases, requiring no discussion)\nHelm v2.16.12 and Helm v3.3.4 have been released\nhttps://github.com/helm/helm/releases/tag/v2.16.12\nhttps://github.com/helm/helm/releases/tag/v3.3.4\nPatch releases; thanks to Farina and Fisher.\nFisher: 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\nZoom call password [Farina]\nZoom will require passwords or waiting rooms across all CNCF\n\nDiscussion 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.)\nStable and incubator repositories being removed in November. What is the plan for users? [Martin]\nMartin: 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?\nFarina: 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\nMartin: the message has gone out but we need a good migration path for people.\nFisher: Karen is the community manager around comms\nFarina: 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\nAdam: what about releases?\nFarina: get.helm.sh is in azure but if someone is using the old location then yes that will fail\nFisher: we have a clean migration path and blog post for that (over the last year and a half)\nFarina: the 8-meg helm init index.yaml for helm 2 is a big part of the bandwidth\nScott: happy to help with migration path for charts\nFarina: will work with Scott on that\nMarc: where to continue discussion?\nFarina: let’s continue discussion in the charts repo in an issue\nDeferred from last week: HIP 002 -- Fixed release dates: https://github.com/helm/community/pull/143 [Marc]\nMarc: Getting close to an agreement - we need to agree on a date and publish it\nFarina: may be related to k8s 1.20 then? Or something off 1.19?\nButcher: we should cut a 3.3.4 with 1.19 support\nFarina: let’s start with the approval of a HIP - we need to look at date possibilities in the coming weeks\nFisher: project and org maintainers can approve these HIPs - final approval details pending\nSecurity patches can lead to unexpected problems. How can we mitigate these with previewing upcoming changes? [Bridget] https://github.com/helm/community/issues/128 \nFarina will follow up with the CNCF to get the list set up\nFarina: We will need to handle the vetting process for list members - k8s uses a vouching system\nDan: can we use the k8s list?\nFarina: 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\nButcher: let’s exercise caution and due diligence here\nMartin: we will revisit over coming months\nEnd User Story for KubeCon Keynote Project Highlight [Karen]\nDue Oct 5\nFocus on graduated projects - to be highlighted during keynotes, focus on end user stories\nHelm v2-to-v3 Hands-on Workshop - Oct 21 [Karen]\nNeed to decide on content + confirm who can help\nWorking with CNCF - this will be an official CNCF event\nFormat: 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\nIf free, attendees might flake out?\nScott: “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”\nVolunteer/Staffing doc -- https://docs.google.com/spreadsheets/d/1IbZkM_eKiCeOc01lVxCXu1-aiBKNj-9SqP_Swn09rLs/edit?usp=sharing\n\nOut of time: Announcing migration needs in CNCF blog/newsletter [Dan Garfield]\nCurrent draft here https://docs.google.com/document/d/1D_cbuxObeD6yjKUmfcRjF_i1gyKnGZxG3intv57xw1A/edit?usp=sharing \nDeadline October 5th\nHelm Hub -> Artifact Hub timeline [Farina]\nSlack integration - do we want to allow this? [Bridget]\nhttps://github.com/helm/helm/issues/8610 \n\nSkip discussion - resolved - Various v2-deprecation-related issues [Bridget]\n[Skip discussion - resolved on GitHub] Helm v2 deprecation progress [Bridget]\nDo we want to think about https://github.com/helm/helm/issues/7239 - the ability to mark a chart as v3-incompat? [Bridget]\n[fisher] I closed the issue. There has not been any activity since it was opened last December.\n[Skip discussion - resolved on GitHub]  https://github.com/helm/helm/pull/8363 [Bridget] - \n“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”\nCan we review this and see if it should move forward?\n[fisher] I’ve added it to the next Helm 3 milestone for review.\n[Skip discussion - resolved on GitHub]  Can we get a review on Allow helm test to run a subset of tests #8484? [Bridget]\nIt could close an old issue\n[fisher] I’ve added it to the 3.4.0 milestone for review.\n[Skip discussion - resolved on GitHub] Is executing hooks in parallel useful? Should we solicit more help here? [Bridget]\nhttps://github.com/helm/helm/pull/7792 \n[fisher] I’ve closed the PR and pointed out how users can move this proposal forward.\n\nAssignments for next meeting\nModerator:  Adam\nNotes:  Scott\nIssue Triage: Farina\n\n\nSeptember 17, 2020\n\nAssignments for this meeting\nModerator: Marc\nNotes: Bridget\nIssue Triage: Farina, Josh, and Fisher\n\nAnnouncements (items of general interest like releases, requiring no discussion)\nCNCF CD Radar (Helm is on it) https://radar.cncf.io/2020-06-continuous-delivery [Farina]\nThough Helm isn’t a CD tool it was listed as “Adopt”\nContacted the end users to ask them for feedback on Helm [Farina]\nRadar was put out by “end users” so Farina reached out to that mailing list for feedback\nQCon Plus Helm Session https://plus.qconferences.com/ [Bridget]\nVoluntold Butcher & Farina\nDiscussed stable repo GCP hosting costs with Vic [Scott]\nCosts are not small - chart version package history will need a different solution as this is not going to be sustainable after Nov 13\nPerhaps we could revisit moving their past packages/index file to github hosting? \nButcher likes this idea & will help investigate\nTalked with ASF about the possibility of hosting charts that install Apache projects [Scott]\nThey 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\nLicensing/ownership considerations\n\n\nDiscussion 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.)\nConversation about Helm’s governance [Butcher]\nButcher: 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.\nScott 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)\nFisher 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\nhelm/helm call for vote open on 2 approvals for community PRs [Farina]\nFarina: we’ve had some commits merged that warranted further discussion - it would be better to catch some issues earlier on\nFisher: we changed this for Helm’s velocity - stability is more important now\nMartin: it’s a sticky wicket when you get into backwards-compat\nChanging vs extending error strings [Marc] - is this okay?\nFisher: 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)\nButcher: perhaps this needs more discussion (as go the language will routinely change error text)\nProcess HIP could be the path forward! Marc will star;t will need input from other maintainers\nDecision 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\nThis 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\nFisher: we can work on this in parallel\nDocs translations quirk [Bridget]\nAn 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?\nVetting language-specific contributors\nTranslation community\nHelm v2 deprecation tasks [Bridget]\nDefault tiller image location\nhttps://github.com/helm/helm/issues/7211 (heritage=Tiller issue)\nFarina: GitHub container registry will be the default, with mirrors on quay and dockerhub\nBlog post and announcement with CNCF [Dan Garfield]\nDan: Started drafting blog post to clarify what will help people who find that their tiller location is gone\nBridget: https://helm.sh/blog/helm-v2-deprecation-timeline/\nMarc: we need to clarify what the user experience change is\nScott: 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\nMartin: we have to talk about this again next week\nScott: Here’s the issue to follow: https://github.com/helm/charts/issues/21103💯\nDeferred to next week: HIP 002 -- Fixed release dates: https://github.com/helm/community/pull/143 [Marc]\n\nAssignments for next meeting\nModerator: Martin\nNotes: Scott\nIssue Triage: Farina\n\nSeptember 10, 2020\nAssignments for this meeting\nModerator:      Marc  \nNotes:    \tMartin  \nIssue Triage:   Farina and Fisher (shared triage; both are in and out this week)\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n \n\nDiscussion (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.)\nDe-listing stable and incubator from Helm Hub as planned? (followup from last week) [Farina]\nTwo current thoughts on migration plan for users:\n1) chartcenter is hosting a “mirror” of the stable and incubator repositories\n2) storing this ourselves in S3\nJosh: does this mean new URLs?\nFarina: yes. We cannot move google cloud storage buckets from one to another, preventing us from migrating the URL in a clean fashion\nFisher: has there been a discussion over with the chart maintainers on which path seems worth investigating?\nFarina: this is something we need to talk more about there\nMarc: the one thing that’s a bummer about all this is the guarantee that there is a “stable” repository I can depend on\nFarina: 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\nHIP for fixed release dates - https://github.com/helm/community/pull/143 [Marc]\nI tried to put the basic ideas in a HIP - \nButcher: 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)\nFarina: one of the risks was that updating client-go has been a major paint point. Some releases have certainly taken a month to update\nFisher 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\nHelm security audit [butcher]\nWe are in the last phases of our security audit. As a reminder, each year the CNCF sponsors a security audit\nThere will be two reports: an architectural report, and a code report\nTwo questions: do we want to disclose it to the security maintainers before releasing to the public?\nFarina: first opinion, we should release it to the other security maintainers to reduce that bus factor\nFisher: who is on the security maintainers list?\nFarina: myself, butcher, fisher, adnan, nikhil, and vic\nStoring Tiller after GCR [farina]\nTiller is now in Quay. We’re looking to move to Github Container Registry\n(farina had to leave at this point)\nDan 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\nQuestion about governance of Helm and deprecating chart repo [Butcher]\nPunted to next week to discuss governance\nRelated: Security group membership\n\nAssignments for next meeting\nModerator: Marc\nNotes: Bridget (unless someone else claims it!)   \nIssue Triage:  Farina, Fisher, and Josh\n\n\n\nSeptember 3, 2020\nAssignments for this meeting\nModerator:        Marc\nNotes:    \tBridget  \nIssue Triage:    Butcher\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n3.3.1 released: https://github.com/helm/helm/releases/tag/v3.3.1 \nFarina: we wanted to get the cert-manager issue fixed  \n\nDiscussion (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.)\n\nDe-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\nStated on 20 Aug that further discussion was needed\nAug 27: stable/incubator becoming unavailable? Blog? [Marc]\nAug 27: Blog post (Farina + Bridget), docs updates, artifact hub switch\nAug 27: Revisit next week\nSept 3: Bridget can participate in blog post writing and docs updating starting Sept 14 \nFarina: Many charts have not found new homes - do we want to remove it now? We’re running out of time here\nMartin: there were questions around the prometheus chart - large community - Scott working on moving that - we need a clear path forward\nFarina: reminder: Nov 13th the bucket will (likely) be garbage-collected - we have an issue on the community repo around moving that elsewhere\nFarina: maybe something useful would be a tool to grab the history for a chart and download it etc\nMarc: what do we do if important charts aren’t relocated yet?\nFarina: 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)\nMartin: charts are where the value of Helm is seen - we need to make sure people have options\nFarina: 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\nFisher: 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.\nBridget: so we’re moving away from centralized ownership\nFarina: Scott is working on a checklist to move to new owners \nFarina: will send out an email to the chart maintainer mailing list after this\nFarina: let’s talk about this again next week.\n\nWhat 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 \nDeferred from Aug 27\nFisher: proposal itself is ready - at this point, we need quorum from org maintainers. (PR review and approval)\nFisher: Let’s seek consensus and ensure it’s not too heavy-handed\nFarina: Fisher, can you send an email to cartographers?\nFisher: yes\n\nDependabot: https://github.com/helm/helm/pull/8574 [Marc]\nDeferred from Aug 27\nMarc: I think Fisher wanted feedback?\nFisher: I’ve seen cases where dependabot creates PRs for security issues and thus makes it public - sending an email can be safer\nFisher: in a couple cases I’ve seen lots of visibility around npm vulns.\nFarina: Docker packages where we don’t use the runtime part have CVEs that don’t impact us - but we would see said CVEs\nBridget: it doesn’t nag - just tells you on each version\nFarina: if it’s a problem we can turn it off\nFisher: I’m fine with a trial run - it doesn’t rewrite code, just submits PRs\nFisher: let’s give it a try and we can discuss further if it proves necessary\n\nApplication version as container tag? [Farina] https://github.com/helm/helm/pull/8562 \nFarina: version vs packaging are not the same\nFarina: 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?\nFarina: we may need to communicate more clearly on these matters\nMarc: so an empty version is better?\nFarina: no, it’s better to have no annotation at all\nBridget: point of order - will we need to revert that PR?\nMartin: I volunteer to do it as I merged it in first place - reverting it back may be the best action.\n\nMoving images from DockerHub to GitHub? [Bridget] https://github.blog/2020-09-01-introducing-github-container-registry\nBridget: should we move to this?\nFarina: do we have access to this beta feature?\nFisher: 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)\nFarina: I’ll test if we can migrate everything \nFisher: we should make sure we loop the CNCF in\nBridget: currently no limits on public\nFarina: we’d want to avoid hitting a limit but no limit is documented yet\n\nAllow templating in value files? Yes or no? [Martin] https://github.com/helm/helm/pull/6876\nMartin: 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?\nFisher: 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?\nFarina: 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.\nFarina: let’s pause on this until we can suggest they create a HIP\nFisher: I will take the action to explain this pause/conversation to them\n \nAssignments for next meeting\nModerator:       Marc  \nNotes:    \tMartin   \nIssue Triage:  Farina can help and The Canadian can also help (we have a Labour Day in Canada as well)   and Martin also\n\n\nAugust 27, 2020\nAssignments for this meeting\nModerator:       Matt Butcher\nNotes:    Bridget\t  \nIssue Triage:    Butcher, Bridget \n\nAnnouncements (items of general interest like releases, requiring no discussion)\nAnonymized 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]\nButcher: also if you have numbers from your Helm session, drop them in here - Intro to Helm got ~566\n\nDiscussion (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.)\nShould the “mapkubeapis” plugin be moved to Helm org (https://github.com/hickeyma/helm-mapkubeapis) ? [Martin] \n(deferred from 20 Aug, to when Martin is here)\nMartin: 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?)\nButcher: related - helmfile has also asked - we need documented guidelines\nFarina: helmfile is not apache2 licensed - that’s the big blocker\nButcher: if anyone can document the basics in a helm community PR, that would be a good start\nFarina: Martin’s is apache2 so that’s not an issue\nButcher: we could use Martin’s as a test run for the process\nFarina: who would like to write this up? I’ll take the followup action\nSlack app integration? https://github.com/helm/helm/issues/8610 [Farina]\n(skipped on 20 Aug)\nFarina: we can deal with it on GitHub\nBump to Kubernetes v1.18 in Helm v2 [Martin]\nThis 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\nThis would mean not being able to upgrade above Helm 3.1.x\nExample: https://github.com/hickeyma/helm-mapkubeapis\nMartin: in 3.2 we bumped Helm 3 to 1.18 - some APIs changed\nMartin: 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.\nFarina: 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? \nBridget: how do we know this doesn’t come with regressions?\nButcher: we need to decide if we’re changing our minds on adding k8s compat that isn’t security, and decide\nDan Garfield: do we have stats on how many people are still pulling those images?\nFarina: I can try to pull that as we discuss other things\nHighest item: v2.14.3 - the most widely-downloaded - some CI system\nThen. 3.x\nThree diff 2.x are still in the top ten\n\nDe-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\nStated on 20 Aug that further discussion was needed\nstable/incubator becoming unavailable? Blog? [Marc]\nBlog post (Farina + Bridget), docs updates, artifact hub switch\nRevisit next week\n\nOpen 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]\nupside: 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\ndownside: users will be redirected to an eventual different domain than they see in `helm search hub` output\nFarina: when we move forward we will have a redirect, but should we change the helm code? \nBridget: I don’t see a downside\nButcher: 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\nBridget: let’s keep control of the URL\nMartin: agreed\nButcher: so we wouldn’t change the domain name at least until it goes from sandbox to incubation\nFarina: we can do something in the messaging to make that more clear\nButcher: staying on same domain for now - someone can propose a transition plan for when artifact hub hits incubation\n\nTaking over a contribution inactive since July 7th 2020? [Marc] https://github.com/helm/helm/pull/8111        \nFarina: 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.\nMarc: needs a rebase\n                         \n3.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\nMatt Farina can do Monday - Josh D to shadow\n\nWhat 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 \ndefer\nDependabot: https://github.com/helm/helm/pull/8574 [Marc]\ndefer\n\n\nAssignments for next meeting\nModerator:        Marc\nNotes:    \tBridget  \nIssue Triage:    Butcher\n\n\nAugust 20, 2020\nAssignments for this meeting\nModerator:    Marc Khouzam     \nNotes:    Scott\t  \nIssue Triage:  Fisher      \n\n\nAnnouncements (items of general interest like releases, requiring no discussion)\nIntroducing the stale issue bot: https://github.com/helm/helm/pull/8521 (added to announcements by Bridget; credit to Fisher)\n\nDiscussion (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.)\nHelm Hub -> Artifact Hub [Farina]\nPaul, Scott, Farina met with AH maintainers on moving HelmHub to AH. \nThe plan is here and open for a vote: https://github.com/helm/hub/issues/439\nGoal is to make sure we don’t drop any repos\nAH will be compliant to Helm’s search API\nHH will be redirected to AH when things are stable. Then HH will be removed. And we will do a blog post announcing the change\nAH already has migration automated, things are moving quickly.\nProvisional PR: https://github.com/helm/helm/pull/8626\nShould the “mapkubeapis” plugin be moved to Helm org (https://github.com/hickeyma/helm-mapkubeapis) ? [Martin] \n(defer to when Martin is here)\nDependabot: https://github.com/helm/helm/pull/8574 [Marc]\n(defer to when Martin and Fisher are here)\nTiller in Docker Hub or GitHub container registry? [Farina]\nDan Garfield notes danger in moving locations, as experienced at Codefresh\nMatt 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\nMatt Butcher: in favor of GitHub registry, will do what we need\nPaul C: agree with github\nDan G: limits for open source projects?\nMatt Farina: GH says free for public repos\nMattt B: if anyone wants to list alternatives, please do\nSlack app integration? https://github.com/helm/helm/issues/8610 [Farina]\n(skip)\nPublishing the KubeConEU recordings/demos? [Marc]\nHelm youtube channel https://www.youtube.com/helmpack\nBridget, Paul in favor of hosting our own high res verisions\nAnnounced release dates https://github.com/helm/community/issues/141 [Marc]\nButcher: from CNCF meeting, 4 releases annually, with at least 2 of them being minor releases\nDe-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\nWill bring up again next week\nin the meantime continue discussion via Slack and mailing list\n\nAssignments for next meeting\nModerator:        Butcher \nNotes: Bridget    \t  \nIssue Triage:    Butcher, Bridget  \n\n\nAugust 13, 2020\nAssignments for this meeting\nModerator:        Martin\nNotes:    \t  Paul\nIssue Triage:     \n\nAnnouncements (items of general interest like releases, requiring no discussion)\nHelm 3.3.0 released \nHelm 2.16.10 released & Helm v2 deprecation timeline to inform people about: https://twitter.com/HelmPack/status/1293694958432481280  [Bridget]\n\t^ thanks to Matt Farina for cutting the releases & Bridget for the blog post\nFinal cut of helm 2 will be 2.17\nJoin CNCF Slack if you want to talk to Helm intro & deep dive session attendees!\nInvites: https:///slack.cncf.io , Slack https://cloud-native.slack.com, Channel #2-kubecon-maintainer\nJoin the slacks for a bit before and up to 15 mins later, help with chat and questions.  \nA 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]\nThe 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\n- Helm GitHub Actions have all released v1.0.0 [Scott]\nkind action ( start up a cluster that lives for the further tests such as `helm install` `helm test`\nChart-testing -  lint + install on just the changed charts ( monorepo )\nDoesn’t test upgrade by default, but functionality is in the testing tool.\nChart-releaser - creates chart package, adds binary to github release, updates index.yml in to gh-pages.\nScott is driving the rehome of prometheus charts, and is showing off how great the actions are.\n\n\n\nDiscussion (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.)\nNext 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]\nEnd of August after Farina and Butcher are back from vacation\nRoad-testing 3.3.0 may give us more \nEnd 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)\nMarc suggests we should do fixed dates for feature releases.\nQuarterly minor cadence? [Martin] - move this discussion to next week\nSecurity Mitigation spec/file proposal https://github.com/helm/community/pull/139 [Rimas]\nAlso see this discussion thread https://kubernetes.slack.com/archives/C0NH30761/p1596744481096000\nRimas shares reference example on screen (see recording)\nchartcenter UI lists CVEs that affect a chart\nIf mitigation file exists, will display notes/comments/etc from that file per CVE\n[Fisher] what’s the rationale, how do others use it?  Value prop is there. Do we make this an openstandard, need helm community agreement.\n\nProposed change to the Helm community proposals: https://github.com/helm/community/pull/140 [fisher]\nFisher talks to need for a proposal on how to create proposals, inspired by Rimas security Mitigation proposal.\nInspired by PEP, KEP, DEP … but lightened up.\n[martin] sounds great, but we’re out of time for further discussion this call.\n\n(out of time for this week)\nShould the “mapkubeapis” plugin be moved to Helm org (https://github.com/hickeyma/helm-mapkubeapis) ? [Martin]\nStale issue bot: https://github.com/helm/helm/pull/8521 [fisher]\nIt 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]\n\nAssignments for next meeting\nModerator:    Marc Khouzam     \nNotes:    Bridget\t  \nIssue Triage:  Fisher      \n\nAugust 6, 2020\nAssignments for this meeting\nModerator:        Adam\nNotes:    \t  Butcher\nIssue Triage:     Fisher  \n\nAnnouncements (items of general interest like releases, requiring no discussion)\nHelm 3.3.0 release plan?\n Possibly ready [Bridget will follow up with Fisher/Farina]\n2.16.10 on the 12th?\nFarina will release, Bridget will have blog post (with an unwitting Adam on the assist)\n\nDiscussion (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.)\nMaintainer signups wanted for virtual Helm project pavilion at KubeCon EU: https://docs.google.com/spreadsheets/d/1qQ067_AeU274sDiu1nwGBeBfwt1q5H3k5UojlOZFV9s/edit#gid=0 [Karen]\nBridget: Free passes if you sign up!\nButcher: 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\nThis is a casual question/answer session on the Intrado platform. Nothing fancy.\nUnanswered question: is it text-only or is there video? (Bridget to investigate) Answer: text-only; must be listed as “booth staff” to answer.\nHow best to implement `untar` capability for `dependency update` https://github.com/helm/helm/pull/8499 [Martin]\nWhen you do an update, you can --untar it.\nThe 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\nAdam will review. Adam listed a few issues that could come up with local v. remote dependencies\nV2 end-of-support progress: https://github.com/helm/helm/issues/8343 [Bridget]\nOngoing triage of v2 issues (7 open) and v2 PRs (three open)\nNeed quick review before it is too late\nQuick update on Security audit\nButcher: one team audits architecture, while another goes through the go code and runs a number of security scanners\nButcher: 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.\n\nAssignments for next meeting\nModerator:         Martin\nNotes:    \t   Paul.\nIssue Triage:        \n\n\nJuly 30, 2020\nAssignments for this meeting\nModerator:    Farina   \nNotes:   Fisher\nIssue Triage:    \n\nAnnouncements (items of general interest like releases, requiring no discussion)\n Helm 3.3.0 release status [Farina]\n3.3.0-rc.2 was released yesterday\nLooking for a volunteer to release 3.3.0\n   \nDiscussion (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.)\nTiming for next 2.16.x release? [Bridget]\nFisher: perhaps we should wait until August 13\nFarina: Do we want a 2.17.0? Farina points out we need to garbage-collect old docker location\nFisher: so we’ll have two releases then\nFarina: 2.17.0 likely to go the week of Aug 13\nPlease 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]\nIf you leave any comments in the google doc today, those will be added to the video as “pop-ups”\nPR https://github.com/helm/helm/pull/8529 [Martin]\nDoes this break backward compatibility?\n[fisher] in general, new output that does not break existing use cases should be fine (like adding new columns to `helm list`)\nThe trick here is that `helm status` is plain text - no formatting applied here\n[farina] there are a few bugs in `helm status` right now which can change the output, so this output can change\nI would ping Matt Butcher on this particular topic - he may have more historical context on whether this may be a breaking change\n[fisher] what output from helm status, if breaking, is to be considered here?\nTwo weeks to go! V2 end-of-support progress: https://github.com/helm/helm/issues/8343 [Bridget]\nOngoing triage of v2 issues (7 open) and v2 PRs (one open)\nBridget will start draft of v2 EOL/migration blog post this week\nFarina: 2.16.10 the last bugfix release mid-August, 2.17.0 thereafter.\nFisher: MSFT folks in virtual offsite Aug 11-12.\nFarina: can cut 2.16.10 on the 12th and Bridget can get blog post in.\n\nAssignments for next meeting\nModerator:        Adam\nNotes:    \t  Butcher\nIssue Triage:     Fisher  \n\n\nJuly 23, 2020\nAssignments for this meeting\nModerator:   Bridget   \nNotes:  Scott\nIssue Triage:    Josh\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n Helm 3.3.0 release status [fisher]\nRelease blocker: https://github.com/helm/helm/issues/8467#issuecomment-662502567\nStill in progress\n\nDiscussion (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.)\n OCI Support Updates [Josh]\nProposal doc: https://github.com/jdolitsky/community/blob/oci-support-updates/proposals/oci-support-updates.md\nCommunity repo PR: https://github.com/helm/community/pull/136\nSummary:\nImplement `Getter` and introduce `Pusher`\nSupport for provenance files\nChart versions == OCI reference tags\nChart names == OCI reference basenames\n`helm chart` is removed, integrated into rest of CLI\nExperimental until clear messaging from OCI\nThe 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\nCache may also be removed, since the tech debt cost may outweigh the benefits\nJacob: Q: do we plan to support digest references? We need this use case\nA: let's address that in the proposal. If not a breaking change, we could introduce post-stable\nGithub’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]\nhttps://github.com/helm/helm/issues/8502\nCould we solve the problem by retagging the 3.x release? https://stackoverflow.com/questions/22822586/swap-latest-release-on-github [Marc]\nA concern with re-creating tags is breaking other systems like homebrew etc\nAlso, it would be mis-leading to users to advertise a different date than the actual release date\nJacob LeGrone: have we looked at server-side apply? https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/ \n\nAssignments for next meeting\nModerator:    Farina   \nNotes:   Fisher\nIssue Triage:       \n\n\n\nJuly 16, 2020\nAssignments for this meeting \nModerator:    Adam\nNotes:      Bridget\nIssue Triage:  TBD\n\nAnnouncements (items of general interest like releases, requiring no discussion)\nKubeCon EU Intro session to be recorded by Marc & Bridget - comments requested: https://docs.google.com/document/d/1giuqSbesC00illJAAHSZF95hXuzXKVfr8UgfyqH5Hkk/edit?usp=sharing [Bridget]\nRelease checklist updates in progress; please review https://github.com/helm/helm-www/pull/749 [Bridget] \n\nDiscussion (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.)\nWhen shall we finalize the 3.3.0 release? How about 2.16.10 and/or 2.17.0? [Bridget] \nFarina: Possible issue with the release candidate - we need to chase this down: https://github.com/helm/helm/issues/8467\nFarina: We do need to add some features for 2.x - skip repos, provide tiller from elsewhere - those need to be completed for 2.17\nFarina: tiller available on dockerhub now\nFarina: 2.16.x could go out at any time\nSupport non conformant Kubernetes objects [Martin]:\nhttps://github.com/helm/helm/issues/8439\nMartin thinks there are interrelated issues - asks Ashok (community member) to introduce topic\nAshok clarifies the benefits of adding weighting/ordering\nAdam asks if this is for just custom resources\nAshok clarifies that it’s for all resources\nFarina 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\nAdam points out we don’t separate dependent chart objects from parent chart objects\nFarina’s proposed solution: top-level chart could specify order (with an advanced feature toggled on)\nAdam: if ordering is dependent, how do upgrades work?\nFarina: use the sort ordering in the chart\nAdam: need to consider how to deal with dependent objects if parents get upgraded\nFarina: solved with config maps - could expand to dependencies - put metadata in Chart.yaml\n[long discussion]\nConcept from Paul:\nMy 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\nWhy would we expose that in a CRD like object? Why not just as metadata in the _Chart.yaml_ file? [Farina]\nhttps://github.com/helm/helm/pull/8441\nDiscussion will continue in https://github.com/helm/helm/pull/8448 \n Recreate upgrade strategy [Martin]:\nhttps://github.com/helm/helm/pull/7431\ndelete/recreate is a sufficient solution (Butcher in https://github.com/helm/helm/pull/7431#issuecomment-658440433)\nShould it and any other similar issues/PRs be closed?\nV2 end-of-support progress: https://github.com/helm/helm/issues/8343 [Bridget]\nOngoing triage of v2 issues and v2 PRs\nThis doc’s ownership [Farina]\nBridget just had Michelle move it to Butcher - done\nResolver vs manager internal cache vs making user manually add repos for deps? [Farina] https://github.com/helm/helm/issues/8449 \nFarina: Possible fixes: internal cache, error out\nAdam: related was a backwards-compat issue\nFarina: whatever we do it will break some CI toolchains\nFollowup: look at the issue and see what you can add - we want to fix this but be as non-invasive as possible.\n[moving to next week] OCI Update after maintainer chat early this week [Josh]\nWe 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\nProvenance 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\nRegistry 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\nRegistry reference basenames will be 1-to-1 with chart name\nMost “helm chart” commands should be removed where possible. For example “helm chart save” -> “helm package --save-oci”\nAs 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\n\n\nAssignments for next meeting\nModerator:   Farina   \nNotes:  Scott\nIssue Triage:    Josh\n\n\n\nJuly 9, 2020\nAssignments for this meeting \nModerator:    Bridget\nNotes:      Martin\nIssue Triage:  Fisher, Martin, Bridget\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n3.3.0 rc.1 available for testing: https://github.com/helm/helm/releases/tag/v3.3.0-rc.1 [Fisher]\nPlease try it out\nOpen for week or so\nReminder 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]\nRonan pulled the top docs search terms over the last 90 days: https://github.com/helm/helm-www/issues/266#issuecomment-655756770 [Bridget]\n\n\nDiscussion (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.)\nSwitching `master` to `main|trunk` https://github.com/helm/helm/issues/8412 [Matt Fisher]\nAny possible issue about moving over?\nTest and research to avoid any downtime/issues\nFisher to investigate further\nSome background: https://github.com/chancancode/branch-rename/\nV2 end-of-support progress: https://github.com/helm/helm/issues/8343 [Bridget]\nOngoing triage of v2 issues and v2 PRs\nDoes 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.)  \nWhen 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?  \nThe “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”. \nOngoing docs updates\nTriage party … Jul 15 10am … based on 2 responses. Do we want to go forward with it ?\nBridget will do a triage of issues/prs to add labels for 2.x\nPaul will do triage of labelled 2.x and close or add to existing helm2 eol issue tasks.\nHelm Project Pavilion at KubeCon EU Virtual\nKaren thinks we should do it\nOffice hours on zoom\nNeed volunteers to sign up\nKaren to follow up on this\nOCI discussion https://github.com/helm/helm/issues/8387 [Josh]\nNeed discussion with Fisher and Farina at least to help progress\nNeed maintainers to make a call to get there\nJosh to set-up a meeting with maintainers, doodle to get a timeslot\nKnown issues with EINTR introduced in Go 1.14: https://golang.org/doc/go1.14#runtime [Martin]\nGo 1.14 changed how it wraps system calls for interrupts\nThis is an issue for k8s - is it an issue for Helm?\nFisher: yes, this is an issue for plugins\nMartin: if there is an interrupt/capture we are safe - are we doing any waits when creating k8s resource?\nFisher: I don’t think this affects us… “famous last words”\nMartin to track in an issue\nKubecon Helm deep dive (scott/paul) … any specific call outs ?\nHelm 2to3 plugin (demo)\nHelm postrender hook (demo)\nThanks/<3’s  for Michelle\nThoughts on growing core maintainership [Karen]\nKaren talking about making it a public announcement\nKaren to market this initiaitive\n\nAssignments for next meeting\nModerator:     Adam\nNotes:       Bridget\nIssue Triage:   TBD\n\n\n\nJuly 2, 2020\nAssignments for this meeting \nModerator:  Marc \nNotes:     Bridget\nIssue Triage: Fisher\n\nAnnouncements (items of general interest like releases, requiring no discussion)\nIntro to Helm KubeCon EU session input - will have script and draft video for review in mind-July - presenting session with Marc [Bridget]\n\nDiscussion (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.)\n3.3.0 date? Open PRs on the milestone: https://github.com/helm/helm/pulls?q=is%3Aopen+is%3Apr+milestone%3A3.3.0 [Bridget]\nFisher: RC1: not this week because of holidays - probably better to do Tuesday of next week - or slightly later\nFarina: we’ve got most things in that we wanted - let’s cut this Tuesday\nV2 EOL progress: https://github.com/helm/helm/issues/8343 [Bridget]\nCan we merge Add Apt (Deb/Ubuntu) installation instructions for Helm 2 #8136?\nFarina will fix the v2 version\nWho can review fix(tiller): Avoid corrupting storage via a lock #7360? (it also has a v3 fix: https://github.com/helm/helm/pull/7322)\nWho can review [v2] fix stack overflow error in helm template. #7185? (It has a v3 fix too: https://github.com/helm/helm/pull/7184)\nFisher says we need to determine if the v3 parts should be merged, then look at v2 as well\nV2-related issues: https://github.com/helm/helm/issues?q=is%3Aopen+is%3Aissue+label%3Av2.x\nDon'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 \nWith new 3-way merge, how about “helm restore” == “helm rollback <current>”? [Marc]\nFisher: rollback logic is intended to preserve any ad-hoc changes\nAdam: 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\nFisher: detect drifts in state\nAdam: let user decide on best remedy\nJoe Thompson: use cases to deal with drift - 1) keep changes 2) want easy undo\nFisher: find all the patches that helm does during an upgrade, take output, do selective logic?\nJoe T: no, I just want to reset to a known state - either a patch or a reset\nAdam: how does this differ from `helm delete && helm install`?\nJoe T: will create an issue to delineate differences from past request\nFisher: a rollback is an upgrade using internal chart metadata, patching release with an old version’s info - usually going back one release\nIntros for interns to learn about the roles Helm maintainers play\n\nAssignments for next meeting\nModerator:    Adam\nNotes:      Martin\nIssue Triage:  Fisher, Martin, Bridget\n\nJune 25, 2020\nAssignments for this meeting \nModerator: Marc    \nNotes:     Josh\nIssue Triage:    Matt Fisher\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n\n\n\nDiscussion (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.)\nHelm 2 Triage Party [Paul, who has a conflict today]\nPaul 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.\nLikely 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\nExpected timeline for 3.3? [Marc]\nCurrently for 3.4 but could be moved up:\nFish completion https://github.com/helm/helm/pull/8111 which requires:\nSubcommands for the completion command https://github.com/helm/helm/pull/8314\nMilestone: https://github.com/helm/helm/pulls?q=is%3Aopen+is%3Apr+milestone%3A3.3.0\nMatt Fisher: looking into this yesterday, some things waiting on reviews, others maybe need to be rethought. \nJosh: maybe do this on this call\nMatt Fisher will bring up on the mailing list the need for a hard date to cut 3.3\nDo we need a v2 release to merge v2 docs? [Bridget, who has a conflict today]\nThe PR in question: https://github.com/helm/helm/pull/8323\nTrying to understand what the next steps are here\n[fisher]: PRs just need to be merged to the dev-v2 branch and v2.helm.sh should rebuild itself from there\nMatt Fisher: this should be resolved, unusual situation\nAdding more labels to the release secret… https://github.com/helm/helm/pull/8272 [Farina]\nDiscussion 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\nJosh: Can this be configurable?\nFisher: It would take a rethinking of storage implementation\nFarina: maybe there is some other way to do this\nV2 EOL tracking issue https://github.com/helm/helm/issues/8343 [Farina]\nShould we make tiller undownloadable (the container image)?\nThis might create a large number of support questions\n\n\n\nAssignments for next meeting\nModerator:  Marc \nNotes:     Bridget\nIssue Triage: Fisher\n\n\nJune 18, 2020\nAssignments for this meeting \nModerator:    Martin Hickey\nNotes:    Matt Fisher /Bridget\nIssue Triage:   Josh Dolitsky\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n3.2.4 and 2.16.9 released\nPossible 3.3.0 RC1? \n\nDiscussion (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.)\nSome repos in https://github.com/helm/ haven’t been updated since 2018 - does someone want to mark them as archived? [Bridget]\nAdam: some maybe - for others we might want to accept issues - we need to review them to see\nBugfixes 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]  \nPaul C will organize a bug-bash cleanup party for 2.x\nSubcommands for the completion command https://github.com/helm/helm/pull/8314 [Marc] \nWho needs to be involved for this type of change?\nAdam thinks this shouldn’t be an issue - think of it like the API - if it’s refactoring but no CLI changes that’s fine\nBlocking contribution for Fish completion https://github.com/helm/helm/pull/8111\nToo late for 3.3?\nAdam: Time to season isn’t as critical - we can review for 3.3 if it’s in soon\nMarc: it’s also not super time-critical\n`tpl` function is non performant for Umbrella chart which contains large number of sub-charts (120 in this case)\nRef to: https://github.com/helm/helm/issues/8002\nConfirmed by Matt Butcher\nAdam: the bug report was around performance \nMartin: listed as bug/help-wanted\nNeed reviewer on https://github.com/helm/acceptance-testing/pull/84 and feedback on https://github.com/helm/acceptance-testing/pull/81#issuecomment-643952826 [Predrag]\nMarc looking at it in limited time\nHow to properly handle force-pushing in a review? [Marc]\nFisher: ends up being a full re-review - lacks context of what changed since last review\nAdam: github allows squashing for more useful history later\nMartin: multiple commits in a PR makes cutting the release challenging - squash at the end is helpful\nYouTube playlist\nMarked as private by default\nNeed to follow up [Bridget will check]\n\nAssignments for next meeting\nModerator: Marc    \nNotes:     Martin\nIssue Triage:    Matt Fisher\n\n\nJune 11, 2020\nAssignments for this meeting \nModerator:   Matt Fisher\nNotes:   Josh Dolitsky\nIssue Triage:  Matt Farina\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n Helm 2.16.8 was released yesterday [Fisher]\nSecurity issue that affect 32-bit arch on older version of Go, CVE for 1.13.6 and below\n Helm 3.2.3 was released [Farina]\n3.2.2 botched due to release hiccup, 3.2.3 has everything meant to be in 3.2.2 \nCNCF webinar tomorrow - join and heckle! https://www.cncf.io/webinars/cncf-project-webinar-charting-your-voyage-to-helm-3/ [Bridget]\nTell your friends!\n\nDiscussion (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.)\nThe 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]\n.File.Get scoping is in whichever chart you are operating on\nWill this break peoples current expectations\nWe should at least try to understand it and document current functionality\nAfterwards, maybe we can take action on Helm 3. Need to ensure backwards compatibility so as not to affect older charts\nLarge release objects, again… https://github.com/helm/helm/issues/8281 [Farina]\nWasn’t there an issue to remove manifests from release objects?\n(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.))\nManifests are each base64 encoded, then gzipped. Can we just not base64 encode it so gzip could work better? [farina]\nIf we change underlying storage, it would break migration from 2-to-3 [martin]\nPeople trying to use Helm as a higher-level tool (like Chef), we should document strategies [Farina]\nThis 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]\nAllow other storage backends? [Bridget]\n3.3.0 release? [Farina]\nPlease maintainers, review PRs in the milestone\nLink: https://github.com/helm/helm/milestone/89\nRelease candidate possibly next Thursday\nNew 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]\nProbably not slated for 3.3, will add to 3.4.0 [Fisher]\n\nAssignments for next meeting\nModerator:    Martin Hickey\nNotes:    Matt Fisher\nIssue Triage:   Josh\n\n\nJune 4, 2020\nAssignments for this meeting \nModerator:  Adam\nNotes: Bridget \nIssue Triage: TBD\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n \n\nDiscussion (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.)\nBLM support statement for Twitter and/or Helm website [Karen]\nIs this something we need to run past CNCF? [fisher]\nLinkerd and Prometheus already have tweets [Bridget]\nDiscussion - all agree: We should check with the CNCF and follow their guidance. Bridget to follow up.\nDiscussion of changes in unit tests for chart fixtures [Adam Reese]\nContinuing from last week\nAdam will open an issue to continue the discussion\nWants to change the practices around test fixtures\nHow do we want to document the methods of Linux installs for the various distros? https://github.com/helm/helm-www/pull/641 [Matt Farina] \nFarina: Do we want to point to a startup’s installation that is not a well-known source?\nAdam: we could use a link instead of copy-paste instructions.\nMartin: we shouldn’t include a link if we’re unsure about the source\nFarina: “reputation” is a squishy thing\nAdam: even with homebrew we don’t control what goes into the installation process\nFarina: is referencing a third party a recommendation of the third party? Helm is providing links to third parties, ymmv, not an endorsement.\nJosh: do we want to release our own fpm, deb, rpm, etc? https://github.com/jordansissel/fpm\nAdam: we had requests for snap, etc - hard to draw a line.\nFarina: will take action to update install docs to say the Helm community and link (not copypasta)\nFarina: Packaging matters but also working with every packaging system increases complexity.\nFarina and Butcher - please ack if all points are clear now in https://github.com/helm/helm/issues/8175 [Predrag]\nFarina: I’ll look through it and consider - will look at implications\n3.3.0: let’s set a date. [Bridget]\nFarina: will start reviewing\nAdam: add anything to milestone for next release\nOCI: let’s get “install chart from registry” in. [Bridget]\nhttps://github.com/helm/helm/pull/7613\n#7613 does not implement this, but it's a prerequisite [Josh]\nhttps://github.com/helm/helm/issues/6982\nWe 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]\nMisc. OCI-related PRs (* can we get these ones in for 3.3?) [Josh]\n* Unique digests (bug): https://github.com/helm/helm/pull/8216\n\n\n* Crashing “helm chart list” (bug): https://github.com/helm/helm/pull/8220\n* Tags that look like ports (bug): https://github.com/helm/helm/pull/8199\n* Improve repo parsing (bug): https://github.com/helm/helm/pull/8089\nAppears a duplicate of https://github.com/helm/helm/pull/7236 ?\n* Fix for --registry-config (bug): https://github.com/helm/helm/pull/7356\n* Display manifest digest instead: https://github.com/helm/helm/pull/8249\nBuilt on top of #8216, should be merged after\n* oci:// dependencies + Getter: https://github.com/helm/helm/pull/7613\nThis the same one from Bridget’s topic\nRelated: git dependencies: https://github.com/helm/helm/pull/6734\nExperimental Notary support: https://github.com/helm/helm/pull/7829\nCustom TLS config: https://github.com/helm/helm/pull/7844\n\nAssignments for next meeting\nModerator:   Marc\nNotes:   Josh\nIssue Triage:  Farina\n\n\nMay 28, 2020\nAssignments for this meeting \nModerator:  Adam\nNotes:  Martin\nIssue Triage:  Fisher and Bridget\n\nAnnouncements (items of general interest like releases, requiring no discussion)\nHelp with Q&A at today’s “Hands-on Helm” session at DockerCon! [Bridget]\nFree 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. \nNavigate 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)\nHang out with Bridget in the live chat and share your opinions/answer questions!\n\nDiscussion (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.)\nDiscussion of changes in unit tests for chart fixtures [Adam Reese]\nWill talk again next week and maybe have a pattern\nReferencing chart fixtures in other packages etc.\nSo Adam did a review and refactor\nSmaller text fixtures and keep in memory - \nMartin suggests documenting some patterns of how we suggest doing this \nGoal: to reduce code bloat of unit tests\n(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] \nFollowup from May 14th: There is a proposal around managing repository configuration in cluster; thoughts? https://github.com/helm/helm/issues/8175 [Predrag]\nPredrag to reach out again on GH to Farina and Butcher\nhttps://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]\nWhy specify the chart instead of the chart embedded in the release?\nTaylor says we don’t have metadata for that, but we do have a proposal\nAdam thinks this is possible, Martin not so sure\nJoe is going to take a stab at a proposal\nMaking 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]\nPatch gets rid of some overhead code and move to Cobra 1.0\nTo help get patch reviewed, Marc is willing to do a 101 session around completion\nOCI topics [josh]:\nRegression since 3.0.3, non-identical digests for identical charts:\nIssue: https://github.com/helm/helm/issues/8212\nPR: https://github.com/helm/helm/pull/8216\nLarger issue pointed out by Matt Fisher, “`helm package` should produce bitwise-deterministic tar files”: https://github.com/helm/helm/issues/3612\nAdam says this is probably a bug\nWhen you tar something order of files are not guaranteed\nMaybe sort files before performing tar\nCould it be because of packaging dependencies also?\noci:// chart dependencies\nPR: https://github.com/helm/helm/pull/7613\nJosh looking for maintainers to review and get merged\n“helm chart list” with large cache causes “too many open files” - issue+fix coming\nShow digest for chart, or manifest? Or both?\nDigest is being shown for the chart and not \n\nAssignments for next meeting\nModerator:  Adam\nNotes: Bridget \nIssue Triage: TBD\n\n\nMay 21, 2020\nAssignments for this meeting \nModerator:  Bridget\nNotes:  Farina\nIssue Triage:  Butcher\n\nAnnouncements (items of general interest like releases, requiring no discussion)\nHelm project journey going to be released next week [Farina]\nCNCF spotlight on Helm sometime in June [Farina]\nHelm webinar June 12 [Farina]\n\nDiscussion (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.)\nRequest for a role (moderator/notes) to upload recordings to youtube playlist [Jeff]\nFisher is working on this using automation around Splain\t\nThe videos are uploaded as private and someone needs to make them public\nTimeline of merging docs (helm-www) prior to a release? [Josh]\nThere was a case where docs were merged prior to a feature\nWe have a longer issue of versioning for docs we are looking for someone to help with\nSuggestion, when a new feature is documented we should document the version it’s available in.\nMartin suggested a GitHub milestone for docs.\nReturn ChartLoader Interface instead of the Chart Path when using LocateChart API. [Vibhav] https://github.com/helm/helm/pull/7601\nFisher: additional context is required\nAdam: will take a look\nFarina: we will not change function signatures or returns, but old deprecated functions will remain\nNew helm options and/or removing klog flags [Marc]:\nhttps://github.com/helm/helm/pull/8067\nhttps://github.com/helm/helm/pull/8095\nGrouping commands was reverted but Marc thinks the command grouping needs to be back in.\nNo urgency on making these changes\nNeeds to be reconciled with Adams other work.\nI 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]\nhttps://github.com/helm/helm/issues/8155\nhttps://github.com/helm/helm/issues/7908\nhttps://github.com/helm/helm/issues/7389\nhttps://github.com/helm/helm/issues/5780\nhttps://github.com/helm/helm/issues/8118\nhttps://github.com/helm/helm/issues/7993\n\n\n 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.\nButcher has done some auditing - broken in several places\nButcher has blocked off a sprint to take a look into this once the lint work is in\nA classic issue from Farina - Add Warning when installing or upgrading a deprecated chart #3724 [Bridget]\nhttps://github.com/helm/helm/issues/3724 \nfixed in v3 but the committer doesn’t seem to have come back to fix it in v2. \nDo 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?\nIf so, maybe we get a volunteer to backport the fix instead of waiting for that committer? (looks like Martin may have some context)\nWe agreed this should go into v2\n[we ran out of time at this point]\nLinux installs [Farina] https://github.com/helm/helm-www/pull/641 \nFollowup 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\n(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]\n\nAssignments for next meeting\nModerator:  Adam\nNotes:  Martin\nIssue Triage:  Fisher and Bridget\n\nMay 14, 2020\nAssignments for this meeting \nModerator:  Josh Dolitsky\nNotes:  Bridget Kromhout \nIssue Triage:  Matt Farina\n\nAnnouncements (items of general interest like releases, requiring no discussion)\nV 3.2.1 released\n\nDiscussion (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.)\nmake test-style seems to fail and be ignored on circle-ci https://circleci.com/gh/helm/helm/12123 [Marc]\nFisher will help; this is fixed on master for now according to Marc\nFisher says the warnings may need to be handled differently\nReview needed for plugin loading refactor https://github.com/helm/helm/pull/7906.  [Marc] Blocks:\nContribution https://github.com/helm/helm/pull/8111 from a new contrib - blocked by existing PR (we should avoid breaking plugin completion)\nFish completion\nDropping the internal package “completion”\nImproved custom completion (adding descriptions)\nUpcoming improved Zsh completion (with descriptions)\nDoes someone have time to look at this now or pair with Marc?\nFisher and Marc will look at this together (Scott R may join as well)\nManaging repository configuration in cluster (alternative to .config/helm/repositories.yaml), elevator pitch [Predrag]\nAt Red Hat they’ve been looking at options to store/read helm charts from a repo instead of a local file\nDoes this make sense for the community upstream?\nFisher: use case vs local fs?\nPredrag: centrally administered configs\nFisher: similar projects exist \nPredrag: 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\nFarina: is the use case a read-only env? Or to help a new dev get running more quickly? (Yes)\nButcher: Also this eases sharing between teams of devs\nFarina: helm fetch/install work with a URL without you needing to add the repository first, for CI use cases\nPredrag: this is more to share pre-defined configuration for developers\nMarc: 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?\nFarina: a typed secret could be better than a CRD, since some can’t use that. \nRigby: 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?\nRigby: 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)\nPred: Will follow up with an issue\nArtifact 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]\nJosh D: This was main part of OCI meeting discussion yesterday: https://www.youtube.com/watch?v=E9WNkklCmuc\nJosh: Farina was named - the OCI meeting said it needed a list from us of what it takes to remove the experimental flag\nBridget: yes - let’s figure out our plan/make sure it’s visible\nJosh D: OCI dependency PR? https://github.com/helm/helm/pull/7613\nFarina: is this a spec waiting for everyone to use it, or can it be depended on? (Is it “trusted” or “already there”?)\nFarina: Distribution spec is concerned with container images. Is the artifact spec something we can stably rely on?\nJosh: 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”\nFarina: we’ll be going off the documented beaten path if we stick things that aren’t images in \nFisher: Docker Distribution can be more compliant\nButcher: 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.\nFarina: 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\nJosh: will take action to try to explain more clearly.\n[This is as far as we got. Pushing other topics to next week. --Bridget]\nReturn ChartLoader Interface instead of the Chart Path when using LocateChart API. [Vibhav] https://github.com/helm/helm/pull/7601\nTimeline of merging docs (helm-www) prior to a release? [Josh]\nRequest for a role (moderator/notes) to upload recordings to youtube playlist [Jeff]\n\n\nAssignments for next meeting\nModerator:  Bridget\nNotes:  Farina\nIssue Triage:  Butcher\n\n\nMay 7, 2020\nAssignments for this meeting \nModerator: Martin Hickey\nNotes: Matt Farina\nIssue Triage: Matt Fisher\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n (Team Microsoft is on vacation today, so none of us are on this call)\n Cutting 3.2.1 release\n\nDiscussion (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.)\nInstall charts with HELM_REPOSITORY_CACHE=off (vibhav)\nhttps://github.com/helm/helm/issues/7545\nhttps://github.com/helm/helm/pull/7601\nThe 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).\nFor this use case a full url or path would need to be passed to Helm to install. This would bypass registries.\nHow would this be tested? Do we need a test run in a read-only environment?\nMight be useful for making chart-test github actions read only … and those would then help verify it works.\nOCI - what are the steps to get off of experimental (josh)\nIssues left before distribution-spec 1.0: https://github.com/opencontainers/distribution-spec/milestone/3\nOCI charts as dependencies: https://github.com/helm/helm/pull/7613\nCurrent registry support: https://helm.sh/docs/topics/registries/\n[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.\n[josh] is interested in a better configuration experience other than environment variables. Possibly something like the way git does it.\nThe hold up isn’t the UX (which we could work on). It’s OCI artifact stability\n\nAssignments for next meeting\nModerator:  Josh\nNotes:  Bridget Kromhout (unless someone present at the May 7th meeting really wants it!)\nIssue Triage:  Matt Farina\n\n\nApril 30, 2020\nAssignments for this meeting (Matt^3!)\nModerator: Matt Farina\nNotes: Matt Fisher\nIssue Triage: Matt Butcher\n\nAnnouncements (items of general interest like releases, requiring no discussion)\n Graduation!!!!!!!! https://twitter.com/HelmPack/status/1255892071002411009\nBridget: Mention @helmpack in your tweets if you want (if you write a blog post or something)\n\nDiscussion (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.)\n(moved from April 23) XDG_DATA_DIRS Support https://github.com/helm/helm/issues/7529 [Vibhav]\nFarina: should be in in the next month or so\nPaul C: encourages summary; Farina summarizes: tldr, we’re adding better support in Helm for multiple directories and/or overriding it\n(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]\nGood way to use https://github.com/roboll/helmfile\nCelebrating!\n\n\nAssignments for next meeting\nModerator: Martin\nNotes: Farina\nIssue Triage: Fisher\n\nApril 23, 2020\nAssignments for this meeting\nModerator: Adam\nNotes: Farina\nIssue Triage: Fisher, Adam\n\nAnnouncements\nTo ensure enough time for discussion items, we will not do a formal standup. Please add discussion items as desired. [Bridget]\nReleases this week: 3.2.0, 3.1.3 [Matt Farina]\nCVE button! Neat features!\nCNCF Graduation - ready your blog posts! [Bridget]\nProbably next week - we don’t have exact timing set by the CNCF yet\n\nDiscussion (include issue links and your name)\nMeans to override the XDG Base Directory Specification: https://github.com/helm/helm/issues/7919 [Martin]\nAction items remain\nSeems can set specific Helm env vars\nCan I add helm to the list of projects using Cobra? https://github.com/spf13/cobra/blob/master/projects_using_cobra.md [Marc]\nYes; everyone agrees this is a good thing\nContributor Beginner’s guide: Logging in different packages? [Marc]\nFarina mentioned a need for a beginner’s guide\nQuestions answered for new maintainers and users\nPR 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.\nDoc on k8s APIs (https://github.com/helm/helm-www/pull/559) [Martin]\nLooking for reviews on it\nAdam will look at it\nMystery Circle CI failure [Josh]\nSee https://github.com/helm/helm/pull/7613#issuecomment-617984152\nFailure: https://circleci.com/gh/helm/helm/11875\nAny reason not to upgrade Go version to 1.14+ ?\nJosh will try updating to 1.14\nPGP signature verification in install script [Josh]\nPR/discussion: https://github.com/helm/helm/pull/7944\nDisabled by default, enable with VERIFY_SIGNATURES=true\nCurrent plan:\nFetch KEYS files from GitHub, @master (all maintainers keys)\nCreate a temporary keyring, import KEYS file\nFetch .asc files for .tar.gz and .shasum on release\nVerify the .asc files against temporary keyring using gpg\nDelete temporary keyring\nGithub actions suggested; Josh will chase down\n`helm dep up` seems to traverse directories all over - file an issue? (Joe Thompson)\nMust dependencies be documented in charts.yaml? (in theory, yes)\nWill start a more general issue to describe this re: dependency resolvers\nMini-retro on no standup (started with 3 minutes to go) [Bridget]\nPro-standup: it’s a point of connection with each other\nAnti-standup: if lacking a specific accomplishment, one may feel like skipping the call\nResolution: for now, let’s see how many discussion items there are\n\nAssignments for next meeting\nModerator: Matt Farina\nNotes: Matt Fisher\nIssue Triage: Matt Butcher\n\n\nApril 16, 2020\nAssignments for this meeting:\nModerator: Matt Fisher\nNotes: Bridget\nIssue Triage: Butcher, Josh D\nAnnouncements\n  2.16.6 released: https://github.com/helm/helm/releases/tag/v2.16.6\nFixed one issue; there’s another issue in there [Farina]\nStandup\nMartin Hickey\nTriage, PR reviews\nimplementation in plugin for removing deprecated APIs for supported ones (for v2) - similar to how it’s done in v3\nJosh Dolitsky\nIssue triage\nMarc\nCobra 1.0 is out - custom go completion - but cannot move Helm to it because of breaking plugin completion (#7906)\nMatt Farina\nWorking on translations process - first file being translated into Korean landed in helm-www! Also release, and PR triaging, and docs.\nTOS having discussions about graduation - waiting for TOC to call a vote, which takes about 5 days and then PR\nMatt Butcher\nIssue queue - getting 3.2 ready\nBridget\nGraduation Blog Post and preparations - PR cycle is slow but we’re getting started\nPaul C\nPresentation on allthetalks - building a chart\nMatt Fisher\nProviding context on issues\nDiscussion\nTransition Helm release and chart hosting ownership to CNCF [mattfarina] https://github.com/helm/community/issues/114 \nAffects charts repository - looking for a process to handle moving this\nHosting this is financially non-trivial\nTechnical considerations around moving buckets\nThis affects helm downloads, chart downloads, and CI\nIhor and Chris A have eyes on this\nOrg, charts, and core maintainers are all impacted by this\nSo stable going away - what's a “stablish” repo to share? Bitnami? [josh]\nProbably good to use Bitnami [Farina]\nAction item: heads up! Keep an eye on the issue.\nBreaking change to upstream merge library (template function) [mattfarina]\nSprig uses merge-go which made a breaking change\nFarina mentions an issue: https://github.com/imdario/mergo/issues/139 \nDocumentation 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.)\nHelm 3.2 - Finalizing the Issue List [Butcher]\nhttps://github.com/helm/helm/milestone/83\nLet’s cut the RC late today/tomorrow\n\nMoving to next time:\nMeans to override the XDG Base Directory Specification: https://github.com/helm/helm/issues/7919 (martin)\nPaul’s helmfile-starter-kit demo (https://github.com/paulczar/helmfile-starter-kit)\nXDG_DATA_DIRS Support https://github.com/helm/helm/issues/7529 [added by Vibhav]\nCRDs not uninstalled upon uninstall. Is this by Design?[vibhav]\nFisher: yes, this is by design. https://helm.sh/docs/topics/charts/#limitations-on-crds\nCool thanks :) \nBeginner’s guide: Logging in different packages? [Marc]\n\nAssignments for next meeting\nModerator: Adam\nNotes: Farina\nIssue Triage: Fisher, Adam\n\nApril 9, 2020\nAssignments for this meeting:\nModerator: Martin\nNotes: Matt Fisher\nIssue triage: Matt Butcher\nAnnouncements\nZero 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)\nStandup\nMatt Farina\nTypical issue triage/PR review\nWorking through the PGP release signature process\nThere’s something going on with our GPG signing process that’s causing the verification process to fail\nJoe Thompson: has been looking into this as part of his course material\nLooking into korean translation for the helm docs\nMatt Fisher\nIssue triage\nMarc Khouzam\nCompletion PRs being merged\nJosh Dolitsky\nOCI work\nMatt Butcher\nBeen monitoring the CNCF graduation voting process\nPairing with Adam on some of the bigger PRs out there for Helm\nWorking with Adam on the Kubernetes 1.18 version bump PR\nBridget Kromhout\nGot blog post out with Farina about the bugfixes for another three months Starting to think about a blog post for the graduation announcement\nMartin Hickey\nConcentrated mostly on issue 7219, which is around deprecated workload apiVersions\nWorking on a plugin to help ease this issue\nThere’s a PR sitting out there that Martin’s looking to merge: #7024\nDiscussion\nIn-memory Cache PR\nVibhav: Looking to give a demo on the in-memory cache demo\nPredrag: 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\nMatt Farina: the pluggable proposal can be discussed offline - https://github.com/helm/helm/issues/7545\nAllow patching/updating CRD resources after first install (https://github.com/helm/helm/issues/7735) [Martin]\nJames Munnelly to pitch proposal (parking this - no word back from James)\nIs the SQL storage backend supported or beta?\nFisher: this is available in a pull request: https://github.com/helm/helm/pull/7635\nSome 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\nAt that time when originally added, only postgres was available \nButcher still doesn’t think this is out of beta\nNeed second reviewer on https://github.com/helm/helm/pull/7791 (multiple repo remove) [Marc]\nMaking 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]\nThis is in reference to `helm test`\nWe’re looking for help to review some of the use cases we have on our end\nMatt Butcher volunteered to help look into these use cases\nAssignments for next meeting\nModerator: Matt Fisher\nNotes: Bridget\nIssue Triage: Butcher, Josh D\n\nApril 2, 2020\nAssignments for this meeting:\nModerator:   Adam Reese\nNotes:    Josh Dolitsky\nIssue triage: Matt Farina\n\nAnnouncements\n2.16.5 - released with new fixes and bugs!\nChartMuseum 0.12 released Friday\nStandup\nJosh Dolitsky \nChartMuseum 0.12 released Friday\nMatt Fisher\nPR reviews and triage\nBridget\nNo update (just helped with blog post which is going out this week)\n Matt Butcher\nBlog on Helm+Operators\nPairing w/ Adam on some bugs\nVersion inconsistencies with k8s\nMatt Farina\nFix issue w/ Kubernetes 1.15\nWorking on - Give resource info in helm status back\nSOMETIMES things blow up\nLooking into support for translations (on docs)\nMarc K\nReview on cobra completions coming soon\nMartin\nTriage \nPR reviews\nAdam\nPairing, issues queue, PR reviews\nVersion breaking issues with Kubernetes, Very frustrated.\nDiscussion\nPlan for the Security Story, it is a good time as this can be taken alongside the design of Notary v2. [Vibhav]\nPushed to next week (vibhav gone)\nThoughts 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]\nThe 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)\nCan we measure the number of Helm 2 users remaining (downloads, other metrics)?\nButcher: maybe lets push back bug fixes by about 3 months\nAll: agree\nAction: blog post on helm.sh\nMatt Farina + Bridget to take\nAllow patching/updating CRD resources after first install (https://github.com/helm/helm/issues/7735) [martin]\nJames Munnelly to pitch proposal\nPush to next week (james gone)\nCache Drivers for Helm.\nPushed to next week (no link no vibhav)\n[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\nContext - doing backup using Velero, needs more granular backup\nVelero: https://velero.io/\nThe release driver for secrets plus configmaps is hardcoded\nNo ability, unilaterally, to get labels defined by user\nAdam: there has been discussion on this previously\n1. Policy on not wanting to touch resources, fully unopinionated\nHaven't found clean way to do this\nJacob: There is a PR using annotations vs labels\nLink: https://github.com/helm/helm/pull/7649\nMerged but unreleased, in 3.2 milestone\nKen: annotations might not cover it\nAdam: in favor of labels option being added, but was unable to find a clean way to do so previously\nMatt Farina: this may be doable with postrenderers\nAdam: labels - will make upgrade much easier\n\t\t\nAssignments for next meeting:\nModerator: Martin\nNotes: Matt Fisher\nIssue triage: Matt Butcher\n\n\nMarch 26, 2020\nAssignments for this meeting:\nModerator:  Josh Dolitsky\nNotes:   Matt Fisher\nIssue triage:  [help wanted]\n\nAnnouncements\nHelm v2.16.4 and v2.16.5 released [mattfarina]. 2.16.4 contained an issue when working with Kubernetes 1.15\nStandup\nMarc\nDisrupted with COVID-19\nContinuing to hope for fish completion PR review https://github.com/helm/helm/pull/7690\nMatt Butcher\nAway all last week\nAdam\nDisrupted by COVID-19, nothing to report this week\nBridget\nMostly focused on SMI things\nMatt Farina\nCut Helm 2.14.4 and 2.14.5\nIssue and PR triage\nMartin\nIssue and PR triage\nFix for the helm 2to3 plugin (some tests weren’t migrating over)\nMatt Fisher\nIssue triage; another open source project\nBug reviews\nScott Rigby\nWe have RC releases out for chart-releaser and updated the github actions around that\nMore work on the chart repositories (tracking issue)\nWorked on a PR to make downloading different Helm 3 binaries easier\nJacob LeGrone\nHave an internal change of `helm commandeer`, will open a PR eventually once that’s ready to go\nJosh Dolitsky\nFighting with Go 1.14 and tests\nAdvancing the OCI spec\nDiscussion\nNotary / TUF compatibility or support ( how do we go about it ? ) [Vibhav]\nPushed from last week\nDiscussed with Radu on some of the design discussions around Notary/TUF support\nQuestion raised to the call: are we looking to get the experimental OCI feature into a stable feature?\nJosh D and others have been working on ORAS - works for arbitrary artifacts: https://github.com/deislabs/oras \nJosh D: “There is also an ongoing “notary v2” discussion going on in OCI #notary-v2 channel in CNCF slack”\nButcher: definition of stable: a security story, finalized OCI, community momentum\nFarina: let’s not move-fast-break-things - real enterprises use Helm\nButcher: 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\nSome PRs needing just a bit of attention:\nInstall / Template Charts without downloading to filesystem https://github.com/helm/helm/pull/7601 needs small input @mattfarina [Marc]\nWill need a bigger discussion\nCan we get some maintainer eyes on this PR? https://github.com/helm/helm/pull/7743 - Joe Thompson \nFarina will look at it\nCut a release candidate for 3.2.0? - Jacob\nMartin: Can we get 7635 in?\nIt’s on the milestone so we can get that one in\nFirst class image referencing support proposal presentation https://github.com/helm/helm/issues/7754 - Konstantin Semenov\nPresentation (5 min): https://www.icloud.com/iclouddrive/0teMaUh1a8whndQ8vgEyzKVww#Helm_image_reference_proposal \nFarina: we’ll mull it over\nButcher: backward compat is important\n[this is all we got to]\nDiff in Helm History Command https://github.com/helm/helm/issues/7828 \nThoughts 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]\n\n\nAssignments for next meeting:\nModerator:   Adam Reese\nNotes:    Josh D\nIssue triage: Matt Farina\n\nMarch 19, 2020\nAssignments for this meeting:\nModerator:  Matt Fisher \nNotes:   Bridget\nIssue triage: Matt Butcher / Bridget  \n\nAnnouncements\n2.16.4 release is delayed by printers (not the paper kind), per Farina\nSome k8s environments cannot use 2.16 right now, so this is time-sensitive\nFisher and Farina will discuss\nStandup\nMatt Farina\nPrinters! Trying to get things to display correctly (affects Helm 2 and 3 both)\nHave submitted Helm for CNCF graduation\nProcess being revamped\nTOC member (non-Michelle, as she’s a maintainer) needs to pick up and evaluate our request - breaking news! It’s Justin Cormack of Docker!\nMartin Hickey\nCreated a doc around storage backends - hoping to get it in for 3.2\nLooking at plugin fixes to help with side-by-side (not entirely cleaning up)\nPR reviews and bug triaging\nBridget Kromhout\nNo Helm; all SMI stuff this week\nTaylor Thomas\nReviewing Farina’s printer PR\nCausing earthquakes in Utah, for maximum hilarity :)\nMarc Khouzam\nRefactoring completion tests to cover Fish completion\nJosh Dolitsky\nTriage - possibly breaking changes in chart dependencies from registries\nJacob LeGrone\nGot PR in for automatically adopting resources - hoping for Martin’s feedback - planning to add an import command to annotate existing resources\nMatt Fisher\nPR review - behavioral assumption changes, though not breaking per se (will sync with Josh D)\nDiscussion\nHelm v2 utility library (https://github.com/maorfr/helm-plugin-utils/) request move to Helm org [Martin] - carry over from last week\nFarina is working on an email Martin is waiting for.\nNotary / TUF compatibility or support ( how do we go about it ? ) [Vibhav]\nPush to next week\nSome PRs needing just a bit of attention:\nInstall / Template Charts without downloading to filesystem https://github.com/helm/helm/pull/7601 needs small input @mattfarina [Marc]\nWill need a bigger discussion\nUse repository-cache if specified https://github.com/helm/helm/pull/7166 @bacongobbler [Marc]\nMake side-by-side versions easier - https://github.com/helm/helm/pull/7752 [Bridget]\nPresent what Codefresh is doing for Helm 3 and collect feedback for the team [Dan Garfield]\nNumerous codefresh users particularly in Europe getting ready for Helm 3 - Jessica Deen did a recent presentation using codefresh & Helm 3\nDemo\nTime for feedback ran out - Bridget directed them to open an issue if desired for discussion\nAssignments for next meeting:\nModerator:  Josh Dolitsky\nNotes:   Matt Fisher\nIssue triage:  [help wanted]\n\n\nMarch 12, 2020\nAssignments for this meeting:\nModerator: Matt Butcher\nNotes:  Scott Rigby\nIssue triage: Matt Fisher, Bridget Kromhout\n\nAnnouncements\nEarly access to CNCF Hub is available: https://hub.cncf.io/\nStandup\nBridget: not much this week\nTaylor: Triage\nMatt Fisher: Triage, follow ups\nAdam: spent more time on deprecated k8s API versions\nMarc: Added completion to 2to3 plugin. Finished fish shell completion. Reviewing in-memory cache concept\nMartin: 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\nScott: not much this week, heads down. Yay about cncf hub!\nJacob: 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\nJosh: not much to add. Hoping to get eyes on a PR: sourcing dependency charts from OCI https://github.com/helm/helm/pull/7613\nMatt Butcher: Presenting to ToC on Tuesday\nDiscussion\nRelease 3.1.2? [Farina]\nWill cut later today [probably by Farina] unless someone else get there first\nVision for HelmHub: how to choose the right chart for a product? [Marc]\nThe 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\nThe 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\nOrgs 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\nThere 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)\nWe 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)\nHelm.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]\nhttps://www.youtube.com/playlist?list=PLVt9l4b66d5EY5Xs9OVJgvO5ss9WzrSY0\nFisher will migrate videos from Zoom to Youtube\nAdam points out there’s a doc in keybase with the necessary info\nHelm v2 utility library (https://github.com/maorfr/helm-plugin-utils/) request move to Helm org [Martin]\nDiscuss next week\nDocs:\nImprovement of library chart docs  https://github.com/helm/helm-www/pull/526  [Martin]\nOne review done by Matt Fisher. Can we get another core maintainer review?\nPlugin shell-completion (which is in 3.2) https://github.com/helm/helm-www/pull/506 [Marc]\nFisher just approved and merged\nFollow-up meeting on kube 1.16^ [Marc]\nAdam will talk to Farina\nPlease include Martin and Marc\nShould we split this file by decade? 😁 Slow on a phone in the subway. [Marc]\nButcher: we could migrate past years to a markdown doc in github - Marc to open issue in community repo\nPlease take a critical look at https://github.com/helm/helm/pull/7649 (resource adoption)! [Jacob]\n\nAssignments for next meeting:\nModerator:  Matt Fisher\nNotes:   Bridget\nIssue triage: Matt Butcher / Bridget\n\n\nMarch 5, 2020\nAssignments for this meeting:\nModerator: Adam\nNotes: Matt Farina\nIssue triage:\nJosh\nMatt Farina\n\nAnnouncements\nnone\nStandup\nMatt Fisher\nLooking at PRs for upcoming milestones to see where we’re at\nLooking at a PR that does `--force`\nJosh D\nIssue sherpa-ing\nDid not complete Chart Museum release\nMatt Butcher\nHelm graduation tasks - shoutout to Michelle Noorali for her help on that\nHelm Security Assurance case - to get CII Silver badge\nPossibly not here next week if traveling\nMatt Farina\nHas been working on Helm graduation (less pressure due to KubeCon delay)\nHelm 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.\nMartin\nLibrary charts docs work\nPR reviews\nScott\nChart testing/release work with Reinhard\nWorked to move charts out of charts repo (e.g., working with nginx project maintainers to host the chart)\nPaul\nBoth KubeApps and Helmfile now support Helm 3.\nPR in to script craft release notes: https://github.com/helm/helm/pull/7636\nJacob\nPR open around resource ownership. Make helm more intelligent on adopting resources. Needs work still.\nBridget\nKubeCon EU work (intro to Helm maintainer session with Reinhard) is now put off\nAdam\nWorked on upgrading Kubernetes and depreciated K8s resources\n\n\nDiscussion\nKubernetes broken versioning [Adam] https://github.com/helm/helm/issues/7219\nWe rely on the libraries kubectl uses - and that no longer supports some old versions\nFarina: this problem is going to keep happening/get worse (because the API server/kubectl won’t work with older versions)\nFarina: should we add Helm lint rules around this?\nFisher: yes; we should give a warning/message in these cases\nAdam: we could build a binary outside of helm for conversion\n[new meeting warranted]\n[ran out of time]\nRelease 3.1.2? [Farina]\nVision for HelmHub: how to choose the right chart for a product? [Marc]\nHelm.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]\nIssue triage: how’s it going? Trends? Thoughts? [Bridget]\n\n\n\nAssignments for next meeting:\nModerator: Matt Farina\nNotes:  Scott Rigby\nIssue triage: Matt Fisher, Bridget Kromhout\n\n\n\nFeb 27, 2020\nAssignments for this meeting:\nModerator: Josh\nNotes: Martin\nIssue triage: Farina\nAnnouncements\nFisher, Taylor, and Bridget are at an event today so won’t be on the call\nFarina did a webinar on Helm security: https://www.cncf.io/webinars/helm-security-a-look-below-deck/\nStandup\nMarc:\nCobra is very open to Go completion\nAdding support in Helm for Fish\nAdam:\nReviewed some PRs\nPushed a PR for fixing a lib\nJacob:\nResource ownership issues\nMatt Farina:\nIssue sherpa this week\nLots of support questions\nMartin:\nSome PR reviews\nSome bug triaging\nJosh\nTalking ChartMuseum bugs\nOne is: Storage cache issue\nNew release of CM on the way\nDiscussion\nContributing Guide? https://github.com/helm/helm/issues/7585 [discussion suggested by Bridget, based on issue opened by Matt Farina]\nHow do we handle things at project level? All the bits and pieces.\nThen handle things at code level? Maybe better code doc/GoDoc.\nHow do you dive in? How you get started?\nHow do you lower the barrier?\nFarina to maybe drive this outside of the weekly meeting?\nGpg signing [mattfarina] https://github.com/helm/helm/issues/7599\nBest practice for handling kube 1.16 removed APIs? Helm v2 or Helm v3? [Marc]\nBig issue we need to be able to handle\nVanilla `kubectl` can handle this, Helm needs to be able to diff against deprecated api to new api in cluster\nAdama to investigate\nCRDs not available during `dry-run`: https://github.com/helm/helm/issues/7449 [martin]\nDo we document that this is a limitation?\nShould this issue be marked as a feature?\nResource ownership refactor https://github.com/helm/helm/pull/7649\nResource ownership does not guarantee exclusivity https://github.com/helm/helm/issues/7699\nAssignments for next meeting:\nModerator: Adam\nNotes: Matt Farina\nIssue triage:\nJosh\nMatt Farina\n\nFeb 20, 2020\nAssignments for this meeting:\nModerator: Adam\nNotes: Bridget\nAnnouncements - none!\nStandup\nMartin\nMigration plugin:\nKube context/kubeconfig can be set on the fly now\nFun bug found about back-end storage (we weren’t catching setting that with args)\nPossibly need to release 3.1.1 - error not being propagated up correctly\nFisher\nPR reviews\nMarc\nCompletion coded in go - posted to cobra\nWorking on k8s 1.16 at work - so dealing with challenges that are showing up in Helm issues -\nBridget\nWorking on Intro to Helm for KubeCon EU with Reinhard\nFarina\nHelm Hub - linting - github actions\nWebinar on Helm security\nFinding issues - putting issues into backlog\nJacob\nWorking on a bug to update resources to new API versions that exist in the cluster\nMay suggest a new ownership heuristic soon (opt-in with label or env variable) (Fisher: maybe as a lookup)\nAdam\nPR reviews/merges\nXDG discussion with Farina\nDiscussion\nRestore issue triage position? [mattfarina]\nAssign specific person/persons to do triage for a specific week\nFisher: can we do assignments async on the maintainers list?\nBridget: we should document how to do the triaging\nFarina: maintainers who aren’t core maintainers could also sign up\nMartin: new core maintainers can learn how to triage by pairing\nFarina: let’s start by reinstating the role and writing docs\nAdd a “NEWS” file to help with release notes? https://github.com/helm/helm/issues/7581 [Marc]\nMerge conflicts mean a single file is a challenge\nAdam suggests an update to the github template\nFisher will link to another tool that helps.\nWhat versions of Helm should be in docs? https://github.com/helm/helm-www/issues/497 [mattfarina]\nFisher: Ronan added version dropdown list between individual versions - 2.14 does not have a specific need to be on there\nAdam: we’re constantly changing docs (not synced with specific versions)\nFarina: 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\nAdam - include a section for anything that’s changed in the docs\nFisher: bring it back to Ronan\nFarina: will continue convo with Ronan\nNote: topics after this point were not discussed on Feb 20 and are being suggested for Feb 27\nShould we cut 3.1.1? [martin]\nErrors not being propagated from template/install/list\nContributing Guide? https://github.com/helm/helm/issues/7585 [Bridget, based on issue opened by Matt Farina]\nGpg signing [mattfarina]\nPorting of sql storage driver https://github.com/helm/helm/pull/7635 [martin]\nNamespaces and user access\nBest practice for handling kube 1.16 removed APIs? Helm v2 or Helm v3? [Marc]\nAssignments for next meeting:\nModerator: Josh\nNotes: Martin\nIssue triage: Farina\n\nFeb 13, 2020\nAssignments for this meeting:\nModerator: Martin Hickey\nNotes: Matt Fisher\nAnnouncements\nHelm 3.1.0 released today: https://github.com/helm/helm/releases/tag/v3.1.0\nStandup\nMatt Farina\nCut the 3.1.0 release, issue triaging, bug fixes\nMatt Fisher\nTriaging PRs for the 3.1.0 release, issue triaging, PR reviews\nAdam Reese\nNothing to report this week\nTaylor Thomas\nPost-render work, giving a talk next week\nScott Rigby\nWorking on some demos with Helm 3 and the new github actions\nMight work on some demos for the new post-render feature\nGot around to pinging people in SIG-PM regarding the “kubernetes helm charts” repo naming suggestions\nMatt Butcher\nKubecon stuff: working on the project maintainer’s booth for AMS\nTaking a look at managed hooks a little bit to resurrect the architecture\nHelm CNCF graduation is moving through the process\nAction item: need to fill out the ADOPTERS.md file in helm/helm\nNeed to spend some time to fix the gpg signing key for past helm releases\nMarc Khouzam\nWorking on PRs: namespaced memory drivers and pre-populating the memory driver for test infra\nJacob LeGrone\nHoping to compile an experience doc for his org\nMartin Hickey\nLooking into some bugs regarding passing along the kube context for the migration plugin\nFacilitating discussion around contributing a new project to the helm org\nDiscussion\nScott Morgan: I’ve had a PR sitting around for a while. Looking to find a core maintainer to move this around (7060)\nMartin: how come the apiVersion had to be updated? `helm lint` should work with older chart APIs\nFisher: to resolve this, let’s add this to 3.2.0 so we can review it for the next release\nTravis raines: https://github.com/helm/chart-testing/issues/202\nTaylor: 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\nhttps://github.com/helm/helm/pull/6920 “helm upgrade --install” purposefully ignores installation errors. Why? [Marc]\nButcher: I’ll review this offline\nShould helm env show XDG paths? https://github.com/helm/helm/pull/6892 Result of offline discussion between Farina and Adam? [Marc]\nFarina: we shouldn’t be showing XDG-related environment variables. We should expose it as a Helm-specific variable in its place\nAction item: farina to push a PR\nShould Helm transform API versions? https://github.com/helm/helm/pull/7575 [Farina]\nFarina: 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.\nAssignments for next meeting:\nModerator: Adam\nNotes: Bridget\n\nFeb 6, 2020\nAnnouncements\nSessions scheduled for KubeCon EU (Bridget, credit to Karen Chu):\nIntro: https://sched.co/Zx1Z\nDeep Dive: https://sched.co/Zx4K\n\nStandup\nFarina\nTriaging issue queue & pull requests\nAdding items to 3.1.0 at this point\nLooking at translations for the website right now\nHelm hub growing\nMarc\nPosted a PR for memory driver to support namespaces - wants to preload releases in memory driver\nAutocompletion for plugins\nAdam\nCatching up - getting back into Helm\nMartin\nFix around lockfiles\nIn Ghent for config mgmt camp to speak about Helm with Taylor\nFisher\nHelm website changes around updating helm commands in the docs\nWorking with Ronan to have good fallbacks for deprecated commands\nHigh-level items & focus on 3.1\nTaylor\nConfig mgmt camp with Martin - worked up good advanced helm demos\nWorking on post-render\nWorking on devopsdays Guad. talk (in Spanish!) about Helm\nButcher\nWorking on TOC review docs for graduation - researching “security assurance” cases & markdown doc with list of companies using Helm\nTriaging issues/reviewing PRs - kudos to Martin on a tricky one!\nBridget\nKubeCon EU talks, yay!\n\nDiscussion\nWhen should we cut the 3.1.0 RC? (Farina, Bridget)\nRC 3.1 tomorrow (Feb 7) - Farina willing to cut the release\nRelease 3.1: tentatively, Feb 13\nRC 3.2 March 11, release March 18\nOne last sync up on post render [Taylor]\nFarina considered this to be for one-off scripts and trying to understand use case\nMartin: this capability has some inherent risks - perhaps we should document more than restrict\nFarina wants a good pattern for this; Taylor is going to comment/explain future enchancements.\nWhat should we do with https://github.com/helm/helm/issues/6794? [Taylor]\nNamespace mechanism is more declarative than before - but might be okay? [Taylor]\nFarina: you’re moving namespace choices from one role to another with this change\nFisher: The role conflicts aren’t fixed by this PR - the lookup functionality is the same.\nFarina suggesting an opt-in flag for auto-creation\nAdam: it was a much-desired feature to limit releases to a namespace\nShould helm-plugin-utils (https://github.com/maorfr/helm-plugin-utils) be moved to Helm org? [Maor/Martin]\nFisher: is this a Helm2-only plugin? If so we’d want that to be clear\nFarina: there is no license on this repo yet\nShould helm env show XDG paths? https://github.com/helm/helm/pull/6892 [Marc]\nMarc: XDG paths get default values when no set, which are hard to discern\nFarina: debugging is difficult for XDG - this workaround would make our lives easier\nAdam: XDG is unix/linux specific, so we probably want to call this “config root directory” or some such\nFarina: we have an issue about setting locations - the ability to use multiple path separators doesn’t currently work\nAdam & Farina will follow up offline\nUpdate on --name flag https://github.com/helm/helm/issues/7345 [Marc]\nMarc: Farina noted that many READMEs mention this\nFisher: core maintainers are making design decisions - we’ll listen but not change based on one community member’s opinion\n[note: meeting ran 45min so we could discuss items d, e, and f]\nAssignments for next meeting:\nModerator: Martin Hickey\nNotes: Matt Fisher\n\nJanuary 30, 2020\nAnnouncements\nJan 29 release of 3.0.3 by Matt Farina: https://github.com/helm/helm/releases/tag/v3.0.3\nStandup\nMarc\nSkip - internet connection flaky\nFarina\n3.0.3 release\nIssue and PR triaging and reviewing\nButcher\nIssue queue triaging\nMartin\nWorking on issue where hash was created in helm v2 and now trying to validate with helm v3. Working on a fix with tests\nWorking on setting kubectx or kubecfg as part of migration (plugin)\nTriaging and reviews\nTaylor\nWorking through his backlog\nWorking on post-render feature with a target on 3.1.0\nCreated a repo of advanced Helm demos for an upcoming talk\nFisher\nIssue triaging and PR queue. Trying to poke some PRs and make sure they have what they need to move on\nBridget\nLearning about release process\nDiscussion\nLet’s discuss a date for 3.1.0 (Farina)\nFarina: Can we do this in mid-Feb?\nTaylor: let’s make sure the k8s libraries are updated\nYes: Joe Langford did this\nFisher: let’s check a few regressions, but yes, this could work\nFarina: by the call next week, we’ll know when we can cut the RC\nFisher: will put some PRs for discussion in the helm dev channel\nPrettify Updated time in helm ls [Martin]: https://github.com/helm/helm/pull/7024\nBreaking change or not?\nHelmsman (a 3rd party tool) is consuming the table and the time\nPotential path forward:\nMove to local timezone and remove the fraction of a second. It’s same format with difference in accuracy\nSee what this means for helmsman and parsing the information\nWould be nice for ls and history to be consistent\nDependency digest differs between Helm 2 and 3: https://github.com/helm/helm/pull/7261 [Martin]\nNeed review and feedback if right approach\nFisher: consistent calculation?\nFarina: there is a complication around dependencies with v1 vs v3 of library\nMartin: some reverse engineering of hash\nFarina will review\nUpdate on --name flag https://github.com/helm/helm/issues/7345 [Farina]\nFarina: lots of charts use this - we can make it a hidden flag\nFisher: 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)\nFarina: we’re less worried about the SDK and more about copypasta\n3tutorials\nTaylor: let’s be careful of precedent\nFisher: let’s assert this is a case-by-case decision, and not a precedent\nFarina: a valid case exists here, and they get a deprecation message. This isn’t a “we support it forever” scenario.\nAssignments\nModerator:  Matt Fisher\nNotes:  Bridget (unless someone else wants to!)\n\nJanuary 23, 2020\nAnnouncements\nStandup\nJosh:\nShifting focus to make OCI distribution mature\nHelp get OCI out of experimental\nMarc:\nPR on bash completion in Go now merged\nPorting support to Cobra\nAdapting patch for helm plugins (bash completion)\nBridget:\nThinking about issues and PRs\nScott:\nConnected with Farina on ingress-nginx project\nJaeger and Kong using new Helm actions\nFarina asks: do we want a blog post about actions?\nScott thinks yes, now might be the time\nJacob:\nNew proposal for test:\nUpgrade and downgrade\nIssue on way\nMartin:\nBug triaging, PR review, issues on Slack\nPushed some PRs with fixes for release checklist - brought v2 fixes in to v3\nFixed a bug in helm plugin utils project\nPreparing talk with Taylor for config mgmt camp in Ghent\nFarina:\nReviewing in\nHelm Hub\nHelm core\nDiscussion\nQuestion 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]:\nCurious what practice why to create a SA everytime for deploy a chart\nFarina said he reviewed this and he thought this pattern was being used commonly in the chart repo\nNo chart maintainers chimed in when Farina asked\nScott will raise an issue if it needs a change\nUpgrade from failed releases: https://github.com/helm/helm/issues/5595 [Martin]\nSeveral issues - releases can get into a state that can’t move on; people can be using deprecated APIs\nWe’ll have this issue for open a while, for discussion\nJacob to add comment on how this can fail on first attempt to deploy\nReintroducing --name flag? https://github.com/helm/helm/issues/7345 [Farina]\nMartin: we need to be cautious about deprecation now that the (metaphorical) horse has bolted - the release is out.\nMarc agrees with Martin’s opinion\nFarina to add a comment to the PR that we have broken compatibility which is allowed. There is a way to work on this.\nCould set a precedence of adding back in deprecated items which is not a great idea\nCommunity member would like to add Deb and RPM packages for Helm: https://github.com/helm/helm/issues/7003#issuecomment-577527262  [Martin]\nMartin: Is this something we want? They’re talking about hosting somewhere - do we actively support this or remain neutral/they support+we link?\nFarina: Hosting elsewhere could cause a trust issue depending on who - we’d want to be clear that it’s a third party\nMartin: choice is between running it ourselves and pointing to a third party\nFarina: 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)\n3.0.3 and 3.1.0 releases? [Farina]\nBridget to shadow Farina to get 3.0.3 release out this coming week\nDiscuss next week a date for 3.1.0\nAssignments\nModerator: Bridget\nNotes: Farina (or Josh D)\nJanuary 16, 2020\nAnnouncements\nWe did a CNCF webinar: https://www.cncf.io/webinars/a-conversation-about-helm-3/\nStandup\nMatt Fisher\nCNCF webinar\nMarc\nBig patch (discussion topic to follow)\nDiscussing with Fisher about working with memory driver\nHoping to pre-load it with something (but doesn’t handle namespaces - worried about API compat)\nWe can add but cannot alter methods\nButcher thinks this is an oversight/bug\nMatt Butcher\nWebinar\nWorking on getting us closer to graduation\nMatt Farina\nMostly reviews & triaging - Helm & Helm Hub\nBridget\nFocused right now on content for the documentation\nWebinar\nMartin\nLinux on s390x\nDeprecated APIs (for discussion)\nFailed deployments - can we help? Make announcements?\n[something I missed which people love]\nPR review\nJacob\nAll good!\nTaylor Thomas\nWebinar\nPostrender\nFeedback to address from community members\nWorking on talks for configmgmt camp and devopsdays Guadalajara\nPing him if you need him on specific PRs\nDiscussion\nAuto-completion re-written in Go https://github.com/helm/helm/pull/7323 [Matt Farina]\nMoving it to Go lets us remove kubectl as a dependency\nRequest: please take a look/review this - it’s a big change\nFisher will be taking a look & put it on the 3.1 milestone\nWhat should be done about the version on master? \"unreleased\" is currently not being added [Marc]\nMarc was unsure how to post a version to show something would be off master - like “3.0 unreleased” like it used to.\nFisher explains he & Adam refactored the internal version packaging so the stable release would not have “unreleased” hardcoded\nFisher: In the makefile there’s a way to specify “unreleased” when not being built from a tag - we should add that (back).\nAction item for Fisher: open an issue explaining the problem and suggested solution\nHandle CRD ingress resources https://github.com/helm/helm/issues/5574 [Matt Farina provided feedback]\nFarina commented on this last May but uncertain why it’s on this list today\nMartin added it today, to see if we can give a more complete answer now\nFarina says we need more eyes on work that will affect CRDs - they’re still challenging\ncommunity 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]\nFisher: that is a pretty comprehensive issue list\nHook up Linux s390x as CI platform: https://github.com/helm/helm/pull/7096 [Martin]\nSubmitter was asking about hooking a particular test into our CI pipeline\nFarina mentions github actions and “self-hosted runners” as an option\nMartin wonders if we _want_ this to be automated\nFisher 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?\nMartin mentions that we aren’t automatically running other platforms’ tests either.\nFisher: the same argument can be made for PPC arch\nButcher: the problem with new architectures: we cannot guarantee reliability on archs that the core team can’t access\nFarina: so, we document to avoid confusion\nK8s 1.16 and deprecated APIs: https://github.com/helm/helm/issues/7219 [Martin]\nMartin: This is going to be a big issue for people in production\nA community member might work on a plugin for this (like the helm 2to3 plugin)\nThis is going to be messy - there’s no clean delineation\nFisher: 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\nFarina: other issues are coming - helm upgrade *should* allow All The Things to work (if we can find a way)\nBridget: can we recommend replace instead of upgrade?\nFisher: we should look at the k8s strategy for API version upgrades - this is going to happen with ingress and more\nMartin: we’ll keep an eye on this\nAssignments\nModerator: Farina\nNotes: Martin\n\nJanuary 9, 2020\nAnnouncements\nCNCF webinar on Helm 3 w/ maintainers next Tuesday (Jan. 14)\nhttps://www.cncf.io/webinars/a-conversation-about-helm-3/\nStandup\nMarc\nCobra help text on stderr has been reverted to stdout\nWhat is the “needs pick” process?\nFisher: release triaging for next patch release, tracking what’s been cherry-picked into patch branch\nTaylor:\nStep 1 -> Add to correct milestone.\nStep 2 -> Add the “needs pick” label to the PR\nWorking on shell completion\nTaylor\nPost-render PR tidying, getting feedback addressed\nJosh\nClosed a few chartmuseum bugs\nMatt Butcher\nPR - making sure we don't use old directories.\nDiscovery client: make sure last set of fixes work\nIf you had stale API endpoint declared, it failed to initialized, causing chart rendering to fail\nMartin\nPR reviews, looking at defects\nLooking at Taylor’s proposal\nScott\nIn a large room\nHelm actions work, working with orgs to move charts from community repo to use their own, using action when possible\nJacob\nHelm rollout logs, adding more watchers for readiness. Getting more logs to the end user without having to use kubectl\nBridget\nHelm 101 content for upcoming workshops, getting it into a repo for anybody to run\nMatt Fisher\nPanel next week Tuesday w/ other maintainers\nhttps://www.cncf.io/webinars/a-conversation-about-helm-3/\nPR reviewing\nFeedback on issue queue, making sure things are triaged\nFiguring out what's the story w/ 2.16.2 and 3.0.3, as well as 3.1.0 release\n\n\nDiscussion\nhttps://github.com/helm/helm/pull/6752 needs some reviews [Taylor]\nWe should discuss its behavior with `helm template`\nButcher: the right thing to do is to throw errors vs. default values\nTaylor: are we ok w/ this?\nFIsher: curious if this solves anyones issues\nTaylor: maybe post-render is the better option\nMartin: we may not want this capability\nTaylor: this feels like --wait - took 2 years to make it work properly, so we should be cautious\nBridget: lets not surprise people in unpleasant ways\nhttps://github.com/helm/helm/issues/7260 [Taylor]\nUpdates on this proposal\nNeed to decide on how long we should leave open for comment\nFisher: Is there a precedent in other orgs (python) for long features left open for discussion?\nPost-render hooks - the ability to add in extra resources after the fact\nBridget: “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?\nTaylor: will probably leave open for 2 weeks\nhttps://github.com/helm/helm/pull/7320 [Taylor]\nWhen migrating from 2 to 3, when moving CRDs to crd/ directory, their CRDs will be deleted.\nWe’ve always said (in docs etc.) we will not delete CRDs\nTaylor: rather user angry over not working, vs. things being deleted w/out their knowledge\nAuto-completion re-written in Go https://github.com/helm/helm/pull/7323\nKubernetes nginx-ingress chart [Scott]\nWhat should be done about the version on master? \"unreleased\" is currently not being added [Marc]\nAssignments\nModerator: taylor\nNotes: Bridget\n\nJanuary 2, 2020\nCancelled for the holidays\n```\n"
  },
  {
    "path": "community/meeting-notes/2021.md",
    "content": "---\ntitle: Helm Minutes for 2021\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/meeting-notes/2021.txt\n-->\n\n```txt\nDecember 16, 2021\nAssignments for this meeting\nModerator:    Butcher   \nNotes:   Karena   \t \nIssue Triage:     was unassigned for the week that ended today\n\nAnnouncements\nThis is the last meeting of 2021\nno Helm call on Dec 23 or Dec 30\nWe will resume this call on Thursday January 6, 2022.\nNext release: minor release 3.8 on Jan 19, 2022\nNot a patch release\nMilestone in progress (review PRs, ideally by Jan 10!): https://github.com/helm/helm/milestone/113  \nRelease candidate goes out Jan 10 (monday before)\n\nDiscussion\n[Karen] KubeCon CFP reminder, May 17-20, Valencia Spain - Hybrid Event\nDeadline is tomorrow, December 16 - https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/cfp/ \nMaintainers talk deadline is later in January\nIf two talks: Panel + Non-panel (in the past, could be two co-speaker talks)\nEarly bird pricing ends January 7\n[Karena] cfp topics?\n[Scott] helm 4, sdk improvements for extending to other tools\n[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\"\n[Farina] idea for Scott … flux, helm controller .. ‘how we built something using the helm sdk’\n[Scott] workarounds they might be able to highlight, improvements?\n[Andrew] oci level distributions … how client model might change, how package, etc.\n[Scott] OCI alignment\n[Farina] List of things: https://github.com/helm/helm/issues/10393\nWhen fall back don’t pass url, pass directory (think is a minor issue)\n[Butcher] correct fall back sequence\n[Farina] version range support.. Only one unsure about\nWork w ORAS team to satisfy version range support\n\nAssignments for next meeting - Jan 6, first meeting of 2022!\nModerator:   Karena     \nNotes:     Bridget  \t \nIssue Triage:     Dec 16-Dec 23 (Allen Bai), Dec 23-Dec 30 (Scott), Dec 30-Jan 6 (Butcher)\n\nDecember 9, 2021\nAssignments for this meeting\nModerator:    Marc    \nNotes:     Bridget\t  \nIssue Triage:     Farina\n\nAnnouncements\n3.7.2 was released yesterday\nButcher: mostly dependency updates but also some bugfixes\nMeeting next week, then a break until January\n\nDiscussion\n[Paul Vollmer] demo of helm-playground, a webapp to render helm charts in the browser.\nhttps://paulvollmer.net/helm-playground \nEarly stages - interested in feedback on https://github.com/paulvollmer/helm-playground \nTool for testing/quick iteration\nRenders automatically when changing values\nPerhaps we could set up play.helm.sh eventually - what’s the next step to bring this to the community?\nCurrently no data recorded/only local WASM\nNext step: HIP to incorporate this into helm docs\n[Butcher] compare to vscode plugin for helm, to see how to incorporate with IDE\nD Peraza - could incorporate helm test\nButcher: be interesting to be able to upload a chart or template\nPaul: goal is to allow people to see results immediately\nButcher: webassembly is an interesting way to package up templates\n\n\n[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 \nThey met and triaged the list in that issue; currently 6 items need to happen:\n Adopt Helm best practice for altering build affix in versions when pushing to OCI #10166\n Move internal/experimental/registry out of internal package #9188\n Documentation only: Helm v3.7.0 OCI Helm push to ecr gives 404 Not found #10169 (comment)\n Forthcoming issue: @jdolitsky re DOCKER_CONFIG\n OCI: no version range support for dependencies/helm install #9694\n helm registry login cannot use existing config file for authentication #10156\n\n[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?\nMentioned - we shall see \n\n\nAssignments for next meeting - Dec 16, last meeting of 2021!\nModerator:    Butcher   \nNotes:   Karena   \t \nIssue Triage:     TBD\n\n\n\nDecember 2, 2021\nAssignments for this meeting\nModerator: Farina     \nNotes:    Karena  \nIssue Triage: week 1 Scott, then week 2 Butcher    \n \nAnnouncements\n3.7.2 scheduled for Dec 8 - https://github.com/helm/helm/milestone/115 \nSecond wednesday of every month\n[Bridget] when to get in any last minute items?\n[Farina] end of this week is the best - has to be a bug (not feature)\n\nDiscussion\n\n[Bridget] Schedule for the rest of this year(!)\nThursday Dec 9 - meeting as normal\nThursday Dec 16 - meeting as normal\nThursday Dec 23 - cancelled\nThursday Dec 30 - cancelled\nThursday Jan 6 - back to normal\n\n[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\nJosh/Scott/Farina met to discuss getting OCI out of experimental\nConcerns: lack of dev resources / feature gaps\nhttps://github.com/helm/helm/issues/10393\nVersion ranges .. not finished\nBusiness logic to implement api’s ..?\nLessons learned: more proj mgmt\nWhat is the MVP?\n[Josh] need document to clearly outline the requirements and issues to work on\nAlias support: https://github.com/helm/helm/issues/10013\n[Farina] Need to go through the list to determine what still needs to be worked on, what needs to be added, etc.\n[Joe Julian] distinction between sufficient API and feature complete\nFarina/Josh/Butcher meeting this week to discuss further\nAdditional topics?\n[Luke] https://github.com/helm/community/pull/224 if there is time\nRelease objects stored wherever they are stored\n[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.\n[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\n[Farina] digest checking and reproducible digests would be great .. want to keep in scope\n\nDefer 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 \n\nAssignments for next meeting\nModerator:    Marc  (and Butcher on dec 16)   \nNotes:     Bridget\t  \nIssue Triage:     Farina\n\n\nNovember 25, 2021 - no meeting (US Thanksgiving)\n\nNovember 18, 2021\nAssignments for this meeting\nModerator:     Butcher\nNotes:    Bridget \nIssue Triage: Farina   \n\n Announcements\n[Bridget] no Helm call next week for US Thanksgiving Thursday Nov 25\n[Bridget] 3.7.2 scheduled for Dec 8 - https://github.com/helm/helm/milestone/115 \nAdd your bugfixes now!\nPatches have been added already!\nGet those k8s dependency fixes in, with a single PR to cover the content of those automated dependabot PRs - help wanted on that PR\n[Farina] Allen Bai as Triage Maintainer\nCongrats! Next step: PRing in himself to https://github.com/helm/helm/blob/main/OWNERS#L12 \nThanks to all for patience as voting can take time\n\nDiscussion\n[Scott] OCI update\nupgrade oras to 0.5.0, refactor client oci logic to use new oras.Copy() #10294\nORAS project meeting today\nPlan to cover ORAS project community maturity #9\nJosh: experimental features will wait for after 1.0\nFarina: we’re interested in the Go API\nalso semver contract\nDependency issues - older k8s packages being imported - keep eye on containerd versioning\nWIP to remove containerd dep https://github.com/oras-project/oras-go/issues/52\nThanks to Josh, Farina, and all working to get this over the finish line\nJosh: number 1 request for OCI is semver matching\nhttps://github.com/oras-project/oras-go/issues/47\n\n\n[Farina] An alternative template delimiter - https://github.com/helm/helm/pull/10299 \nOther systems like Prometheus have options like this\nHowever, affects execution\n[Butcher] Also might cause a breaking change - a silent failure if a chart couldn’t be rendered\nScott - new chart version?\nButcher: yes, this is a severe breaking change to templates - we’d have to do a version increment on charts.\nFarine will update issue\nButcher: likely we’d want a HIP for this as well\n\n\n[Farina] Reproducible builds (and further security things)\nhttps://reproducible-builds.org/ \nhttps://slsa.dev/ \nJoe J: https://twitter.com/puerco/status/1461176447742226440 SLSA in this month’s patch releases of k8s\nWe’ve had PRs in the past but would need tests etc\n[Scott] yes, as long as we feature-flag this\n[David P] does the tar spec claim it will create the same digest output?\n[Farina] Go sort order issues, and the timestamp, are why this varies\n[Scott] chart repo automation currently has to work around this\n\nDefer to Dec 2 [Bridget] Kent Rancourt asking about introducing new template file: https://github.com/helm/helm/issues/10074#issuecomment-973097624 \n\n\nAssignments for next meeting (no meeting Nov 25 - next meeting Dec 2) \nModerator: Farina     \nNotes:    Josh  \nIssue Triage: week 1 Scott, then week 2 Butcher      \n\nNovember 11, 2021\nAssignments for this meeting\nModerator:   Karena \nNotes:   Butcher \nIssue Triage: Scott shadowing Martin   \n\n\nAnnouncements\n[Marc] Welcome yxxhero as new triage maintainer!\nVote was a while back, but he is now officially in OWNERS file\nStill some open votes for the maintainers, so vote now!\n[Marc] Patch release cancelled for this month - No new commits since 3.7.1\nThere were no committed changes, so nothing to release.\nFarina: We will discuss getting some momentum\n[Bridget] no Helm call for US Thanksgiving Thursday Nov 25\nJust a reminder that since many maintainers are in US, we will cancel that meeting\nKarena: We had discussed canceling some other meetings during the holiday season\n\n\n\nDiscussion\n [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?\nJosh 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. \n\n [Bridget] Can someone check and perhaps merge the current dependabot PRs? (do we want this to be part of triage tasks for the week?)\nThere are several Dependabot PRs that should get some attention. And the longer we wait, the harder they are to merge.\nCould this be considered triage work?\n \n\n\n[Farina] How do we get more merged?\nCore 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\nWe have more maintainers, but not enough to make a big difference here\nSo what can we do to help with that?\nDpereza: Will more maintainers fix this?\nFarina: Maybe, but that does require more work\ndpereza: 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)\nFarina: I will help get this going. Feel free to come bug me to help you. I’m in ALL the Slacks.\nKarena: What about the dependabot PRs?\nBridget: Can these be triage tasks? Or are they more than that?\nFarina: 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.\nMarc: Someone from RedHat did this k8s merge in the past. Does anyone remember who? [Will look up]\nFarina will write the Help Wanted issue for tracking the k8s upgrade\nMarc: It was Shoubik who had done some in the past.\nDiscussion about asking Shoubik to do this again (David will follow up).\n\n[Bridget] What do we think of this Slack integration request? https://github.com/helm/helm/issues/10291 \nInstalling the slack app on the repo… do we want to do this?\nDo projects do this? Is this a good idea? Does anyone want to investigate?\nButcher: I will track this one\n\nAssignments for next meeting  \nModerator:     Butcher\nNotes:    Bridget \nIssue Triage: Farina      \n\n\nNovember 4, 2021\nAssignments for this meeting\nModerator:   Martin Hickey\nNotes:   Bridget Kromhout\nIssue Triage:   Scott Rigby - will reach out to other folks for backup\n\nAnnouncements\n[Bridget] Next scheduled release: 3.8.0 on January 12th, 2022 https://github.com/helm/helm/milestone/113 - review items in there!\nIs 3.7.2 still planned for Nov 10? https://github.com/helm/helm/milestone/115 has no items in it yet\n[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\n[bridget] okay. I wasn’t sure how late an item could be added.\n[Fisher] when we have nothing to release we extend the date\n\n\nDiscussion\n[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]\nBridget and Karena will be out for all three\nFisher: generally speaking most people won’t be at the calls these dates\nMartin: I will also be out\nResolution: We will cancel the Nov 25th call and ask about the December ones closer to the time.\n[Bridget] does anyone know offhand if the OCI support as of 3.7.1 fixes this bug? https://github.com/helm/helm/issues/8090 \n[fisher] that should be fixed as of Helm 3.7+. Added a comment\nWe can revisit this if it doesn’t work in 3.7+\n[Josh] clarity around :version versus --version: https://github.com/helm/helm/issues/8090#issuecomment-961222358 \n[Scott] update on ORAS/Helm OCI progress\nupgrade oras to 0.5.0, refactor client oci logic to use new oras.Copy()\nJosh D, can we connect on how to update the test?\nJosh: 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.\n[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”\nScott: PR in question: https://github.com/helm/helm/pull/10294 \n\nAssignments for next meeting  \nModerator:   Karena \nNotes:   Butcher \nIssue Triage: Scott shadowing Martin    \n\n\nOctober 28, 2021\nAssignments for this meeting\nModerator:    Marc\nNotes:  Karena\nIssue Triage:  Scott shadowing Farina\n\nAnnouncements\n[Marc] New triage maintainer: yxxhero\nWelcome!\n[Karena] KubeCon Maintainer Session - Combined views (in-person + virtual): 1223\n\nDiscussion\n[Marc] Should triage maintainers be added to the OWNERS file?\n[Farina] makes sense to have it\nAI: Marc to send email to maintainers\n[Josh (who cannot attend)] Merge me! https://github.com/helm/helm-www/pull/1228\nSeveral issues is the queue related to OCI may be prevented, since the current registry docs are misleading/contain old commands\nPeople have command line documentation\nold vs. new\n[Scott] I am reviewing\n[Adam] - PRs to bump\nhttps://github.com/helm/helm-www/pull/1228\nLabeling releases:\nhttps://github.com/helm/helm/pull/8099\nAlternatively https://github.com/helm/helm/pull/9560\n[Farina] Expectations: next minor release (January) for these PRs\n[David Peraza] question on pre-GA install\n[Farina] k8s versions look semantic but are not semantic\nHelm uses a semver check\nAccording to semver, use ascii character map so start w/ using zero\n[Farina] could have better help documentation\n[Scott] quick update from last week on Helm OCI & ORAS dependency. Moving forward!\nCommunicating closely w ORAS maintainers (Josh, Sajay, Avi etc)  and collabing with volunteers (David P, Andy Block, Josh Wolf, Tom Runyon)\n[Marc] Triage maintainers\nVoting on Allen too\nAnd Scott\n\nAssignments for next meeting  \nModerator:   Matt Farina\nNotes:   Bridget Kromhout\nIssue Triage:   Scott Rigby - will reach out to other folks for backup\n\nOctober 21, 2021\nAssignments for this meeting\nModerator:    Bridget\nNotes:  Scott\nIssue Triage:  Farina\n\nAnnouncements\n[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 \n\nDiscussion\n[Bridget] does someone want to check and approve/comment on the outstanding dependabot PRs? https://github.com/helm/helm/pulls/app%2Fdependabot \nDependabot will keep them up to date, so if they’re still open, we can review and merge them \n\n[Scott] feedback on OCI status\nIssue, SDK users can not import helm's OCI support, because it is EXPERIMENTAL (note this is by design for now for a good reason)\nquick note on earlier idea for helm/registry breakout proposal. Chat prior to HIP\nMet with Josh & Matt Farina before and during KubeCon\nNow: prefer to instead help push Helm OCI support over the finish line. Shoot for January\nScott: 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\nTarget: the January 3.8.0 release\nVolunteers:\nScott\nAndrew Block\nDavid Peraza\nJosh Wolf\n[Scott] will push this forward\nset up a simple collaborative process for the busy folks who want to help (scheduled meeting? just async? whatever is pragmatic & easiest)\nstart with checklist of required things to do\ncoordinate with Bridget\ncoordinate with other ppl who have volunteered to collaborate on this\ncoordinate with Josh for reviews\n\n\n[David] New member asked to bring this up in call: https://github.com/helm/helm/pulls/mmulholla \n Will follow up (we were KubeCon-ing last week)\n\n[Farina] summary of community online meeting during KubeCon\nOCI and CRD questions as usual\n\t\t\n[Bridget] HIP review: https://github.com/helm/community/pulls \nAnyone can comment\n\nAssignments for next meeting  \nModerator:   Marc\nNotes:  Karena  \nIssue Triage:   Scott shadowing Farina\n\n\nOctober 14, 2021\nCancelled due to KubeCon :-)\nJoin office hours on Bevy instead!\nTuesday, October 12 • 9:00am - 9:45am Pacific \nFriday, October 15 • 10:30am - 11:15am Pacific\n\n\nOctober 7, 2021\nAssignments for this meeting\nModerator:   Karena\nNotes:  Scott\nIssue Triage: Farina\n\nAnnouncements\n[Bridget] reminder: no Thursday Oct 14th Helm weekly dev call due to KubeCon\nJoin office hours on Bevy instead!\nTuesday, October 12 • 9:00am - 9:45am Pacific \nFriday, October 15 • 10:30am - 11:15am Pacific\n[Farina] 3.7.1 patch release next week (being cut by Farina)\nCutting this on Wednesday next week : https://github.com/helm/helm/milestone/114 \nhttps://helm.sh/docs/community/release_checklist/ \nMarc: new pick and push process\n\n\n\nDiscussion\n[Nick Jennings/Ramindar/Dhanashree] Surfacing container logs in Helm?\nhttps://github.com/helm/helm/pull/7728  and https://github.com/helm/helm/issues/5952 \nMatt Farina: check out the https://github.com/helm/chart-testing project\nJoe: 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).\nMatt Farina: Nick is looking to do something that's not custom\nJoe: agree, though it could start out custom prior to a HIP\nNick: agree that would be a good way to move ahead\nMarc: legit use case though right?\nMatt 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)\nKarena: ensuring there is a clear next step\nNick: 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\n\n\n [Tom Runyon] Standardize Annotations to identify images used by Helm Chart.\nArtifactHub 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. \nOther 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.\nProposed:  `helm.sh/images` as seen below:\n\nAndrew 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 \nScott Rigby: agrees there should be a standard - this doesn’t require much from Helm other than stating something is “supported”\nFarina: we’d need to agree and document\nTom R: happy to do that work\nFarina: this would definitely need to be a HIP and I would be supportive of it\n\n\n(move to Oct 21?) [Scott] If time, feedback on earlier idea for helm/registry breakout proposal. Chat prior to HIP\n\n\n\nAssignments for next meeting (Oct 21! No meeting Oct 14)\nModerator:  Bridget (or other!)  \nNotes:  Karena \nIssue Triage: Farina for week 1; someone needed for week 2  \n\nSeptember 30, 2021\nAssignments for this meeting\nModerator: Scott \nNotes:  Bridget\nIssue Triage: Butcher\n\n\nAnnouncements\n[Bridget] Hosts needed for KubeCon online office hours (held on Bevy):\nTuesday, October 12 • 9:00am - 9:45am Pacific (to be led by Matt Farina)\nFriday, October 15 • 10:30am - 11:15am Pacific (to be led by…?)\n[Bridget] 3.7.1 patch release would be during KubeCon - schedule adjustment?\nFarina: I can still cut this release that day\n[Bridget] reminder: no Thursday Oct 14th Helm weekly dev call due to KubeCon\n[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\n\n\nDiscussion\n[Farina] Artifact Hub storing validation in OCI registry for charts there…\n\t- “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.”\nArtifact Hub asking for input/feedback on this feature, and asking you to add the metadata files - similar to provenance files\nThis is different from “verified publisher” - see https://artifacthub.io/docs/topics/repositories/ - important for businesses etc\n\n[Bridget] Inactive repo cleanup - I’m proposing we archive three repos due to minimal content and no activity:\nhttps://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\nhttps://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\nhttps://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\n\n\n[Bridget] OCI/mediatype question - do we know what we want to do with https://github.com/helm/helm/pull/10182#issuecomment-927377309? \nFarina: this is an issue with user confusion around experimental features - plugins will be a more clear delineation in the future\n\n[Scott] who wants to make a PR against Helm Governance for using the private maintainers list for new maintainers voting.\n[Bridget] I already have a PR open against governance to update from last year’s HIP-005: https://github.com/helm/community/pull/210 \nBridget will request that clarification - according to farina, self-nominations should happen on public list, then vote on private list\n\n\nAssignments for next meeting\nModerator:   Karena\nNotes:  Scott\nIssue Triage: Farina\n\nSeptember 23, 2021\nAssignments for this meeting\nModerator:  Matt Farina\nNotes:  Bridget\nIssue Triage: TBD\n\nAnnouncements\n[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 \n\nDiscussion\n[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) \n [Bridget] The original plan mentioned possible kickoff activities at kubecon north america 2021, which is fast approaching.\nButcher: 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.\nButcher so perhaps we amend HIP-12 with a redefinition of the roles to two instead of one, and for a resumption post-holidays\nAction item: Butcher to carry out HIP replacement (lol)\n\n[Bridget] 3.7.1 for bugfixes?\nOCI: Allow any mediatype for layers on download #10176\n[Josh] old charts being rejected is not ideal, but this bugfix would allow less-strict checking.\n[Farina] debated in the original issue as to whether we should accept the old media type as well - what’s changed?\n[Josh] the community reaction has motivated this increase in flexibility\n[Farina] we should log deprecated media type - patch is in a couple weeks\n[Farina] instead of experiments, we should look at plugins in the future (because of how this has been treated)\n[Josh] helm-push plugin is broken due to “helm push”\nhttps://github.com/helm/helm/issues/10175  \nAction item: Josh will submit update for the patch release\n\n\n[Karen Chu] Helm at KubeCon\nWays to participate\nOnline office hours (RSVP - held on Bevy): Tuesday, October 12 • 9:00am - 9:45am Pacific and Friday, October 15 • 10:30am - 11:15am Pacific \nHosts 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.\nMaintainer session: Wednesday October 13, 2021 11:00am - 11:35am PDT Concourse Hall 150 ABC + Online  \nProject Pavilion booth\nOnline\nIn person  - possible to sign up for participation (we have it half the day - mornings each day)\n\n\n[Andrew Block] Helm + Sigstore: Presentation plus very short demo\nHelm Sigstore Plugin Demo: https://www.youtube.com/watch?v=cjY26RRHpo8 \nSigstore is not SIG Storage\ncosign, rekor, fulcio\nhttps://github.com/sigstore/helm-sigstore \nScott Rigby: please join the Helm chart talk at KubeCon\n\n\nAssignments for next meeting\nModerator: Scott \nNotes:  Karena\nIssue Triage: Butcher\n\nSeptember 16, 2021\nAssignments for this meeting\nModerator: Karena\nNotes: Bridget\nIssue Triage: Fisher\n\nAnnouncements\nHelm 3.7.0 has been released https://github.com/helm/helm/releases/tag/v3.7.0\nFisher: community identified code regressions, which are now fixed - RC3 was cut and now we’ve released 3.7.0\n[Marc] should we clarify the breaking change further (OCI charts only)?\nFisher: 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 \nCharts will need re-uploading\nFisher: documentation needs to be updated in accordance with this change\n[Marc] we may need to clarify the release notes\nFarina: Josh D did a gist on how to update: https://gist.github.com/jdolitsky/66e0768ceedb6eab7395422e86e16a53 \nAction item: Release notes update by Marc\n\n\n\nDiscussion\nHelm 3.8.0 release date\n[fisher] I looked at the calendar and tentatively scheduled it for January 12, 2022 (second Wednesday, four months from now). Lazy consensus vote?\nFisher: the HIP says quarterly - 4 months from now would land in January\nFarina: 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\nAction item: Fisher will send email & update the release calendar\nMarc will add Fisher to the calendar\n[Karena] Triage shadowing session\n[Karena] pairing is challenging - can we schedule a session for walking people through triage?\n[Fisher] perhaps we need to define what this is?\n[Bridget] Do we want a one-off triage onboarding/shadow session?\n[dperaza] Async would be valuable as well, but I would attend a one-off orientation\nStephane: also please record the session and document it\nKarena: resolution: \n[Bridget] KubeCon logistics\nShall we cancel the Thursday Oct 14th Helm weekly dev call? [yes]\nWho 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]\nWho’ll be onsite for KubeCon? (We have an in-person project pavilion spot.)\n[Karena] Please comment here if you’re going to be onsite in Los Angeles\nBridget: I’m planning to be there\nKarena: I’ll be there!\n\n\n[Marc]: Wondering if dynamic completion of plugins could have security implications? https://helm.sh/docs/topics/plugins/#dynamic-completion\nButcher: Helm can’t secure unknown 3rd-party code on behalf of the user\n\n[Karena] Helm youtube channel\nWho maintains/uploads community videos?\n[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)\n[Scott] progress on helm session technical focus on charts\n[Bridget] Skipped this so pulling it out to highlight it 💖\nBuilding, publishing, sharing charts!\n[David] Can we demo sig-store for the community call?\nFisher: 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 \nFarina: a recorded demo on youtube is far easier to share\n\nAssignments for next meeting\nModerator:  Matt Farina\nNotes:  Bridget\nIssue Triage: TBD\n\nSeptember 9, 2021\nAssignments for this meeting\nModerator: Matt Fisher\nNotes: Karena Angell\nIssue Triage: Matt Butcher\nAnnouncements\n[fisher] Helm 3.7.0 delayed due to a few code regressions\nCut 3.7.0-rc.3 and look to release 3.7.0 after that\nNext hour, release candidate is out\nNext Tuesday for 3.7.0 GA\nDiscussion\n[fisher] Helm 3.7.0-rc.2 update\n[fisher] there is a fix available now available for #10112: https://github.com/helm/helm/pull/10117\nReviewed and approved\n[Bridget] Helm at KubeCon NA 2021 - updates?\nProject talk: \nHelm: The Charts and the Curious - https://sched.co/lV7H\nHelm project booth\nOnline office hours\nFriday, https://sched.co/mtNO\nScott, 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\n[Bridget] Triage maintainer nominations - updates?\nOne is being onboarded\nIf anyone else - there’s a HIP: https://github.com/helm/community/blob/main/hips/hip-0014.md\n[Bridget] Self-nominate! It’s easy and fun!\nDon’t have to be proficient in Go or Helm - it’s a good way to learn\nJoe Julian & Scott Rigby interested\n[Andrew Block] Sigstore + Helm - https://www.sigstore.dev/\nSigstore for signing/verifying content\nHelm package signing\nhttps://medium.com/@sabre1041/setting-up-your-own-rekor-transparency-log-server-using-helm-fc7bbeafb59c\nhttps://medium.com/@sabre1041/integrating-helm-into-the-sigstore-project-d51564ea001f\nSign Helm charts - not rewriting how they are signed today - taking content and publishing to a transparency log\nInterested in feedback - future presentation will demo to the group\nFarina: would love to see Helm work published to transparency log\nPgp keys?\nFarina: pgp was when we created things - integration with gpg not as good anymore\nJosh: helm push - if sees  file, will upload over oci distribution … would be cool to detect sigstore plugin\n\nAssignments for next meeting\nModerator: Karena\nNotes: Butcher\nIssue Triage: Fisher\n\n\nSeptember 2, 2021\nAssignments for this meeting\nModerator:   Martin\nNotes:   Karena\nIssue Triage:  Farina \n\n\nAnnouncements\n3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 \nRevamped OCI integration\nBreaking change to previous OCI experiment\nUnder experimental flag\nJosh dolitsky\nUseability\nAny volunteers to test??\nAPI changes:\npush/pull from registry, certain manifests pull from there (breaking change)\nAction package - tried to move some of the api stuff out\n“should be” clearly documented\nCRDs out of the chart - helm show crds\nSIGTERMS on upgrade/install\n\nDiscussion\n [Itai Spiegel] Including external files in chart. https://github.com/helm/helm/pull/10077 \nBroke api compatibility - PR not ready for review yet\n [Butcher] Helm 4 Release Manager\n“It is time!”\nRelease manager - most of architectural decisions\nRoadmarkers\nPM’y but more architect role\n25-30 hours of work per week\nDecide by end of september - go/no-go then\nOr nominate Adam ;)\nNeeds to be existing maintainer of helm/helm code base\nRequires some coding and managing PRs with PR authors\nDavid: break up the role?\nAndy: cover multiple geos\nJulian: 30 hours per week for how long?\n6 months?\nButcher: We could also break it into PM-like tasks and coding tasks, and create two distinct roles\nOnce decide on person(s), can kick off the process\nWhat are the bounds for this release?\n[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)\nCommand that compares helm storage state with a live cluster state\nHelm controller from flux and Helm operator had to do a lot of workarounds to ascertain the info - should this be a HIP?\nFarina: Helm 3 - 3-way merge patch\nMutating web hooks\nE.g. Service mesh\nA tool like this might fail / raise those thing instantly in a case like this\nFarina: what’s the use case?\nButcher: And Kubernetes itself mutates things (in ways that change from k8s release to k8s release)\nButcher: a HIP sounds like a great way to discuss this\n[Karena] Blog post for this release\nLoves the mentions so far about what's landing in this release\nAny other notes over the next 3 mins?\nFarina: 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\n\nAssignments for next meeting\nModerator:   (Bridget if no other volunteers)\nNotes:   Karena\nIssue Triage: Matt Butcher \n\n\nAugust 26, 2021\nAssignments for this meeting\nModerator:  Adam\nNotes:  Bridget\nIssue Triage:  unassigned\n\nAnnouncements\n3.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 \nCall to action: review (and/or update) PRs for 3.7.0\n\nDiscussion\n[Farina] Download cache HIP and security… https://github.com/helm/community/pull/185 \n[Farina] Possible security issue if index.yaml file intercepted/changed, leading to a wrong version being installed\n[Farina] Perhaps checking which version is being requested would mitigate?\n[Butcher] that reduces the risk to local filesystem attacks\n[Farina] this cache also covers cache environment variables\n[Butcher] we have extraneous cache environment variables\n[Martin] for helm 4 - one cache to rule them all!\n[Karena] how does this tie back to the overall security story?\n[Farina] many factors for security - like signed indexes - but yes, a security-centered approach is wise\n[Farina] we should discuss https://github.com/sigstore/helm-charts \n[Karena] Andy would like to come on to discuss\n[David Peraza] let’s discuss/bring in more folks\n[Farina] We could look into more caching items before Helm v4\n\n[Martin] Would functionality to clean failed revisions be useful? Came up as a conversation in https://github.com/helm/helm/issues/10056. \n[Farina] In Helm 3 there is a limit of 10 by default\n[Martin] Failed revisions that people want the ability to clean up\n[Farina] We don’t garbage-collect if all the release objects are failures\n[Farina] perhaps we should start with a garbage-collection plugin?\n[Martin] that is better than telling people to edit the cluster directly\n[Farina] a plugin called `gc` would be a good place to start\n[Martin] will raise as a feature and see if someone has the bandwidth\n\n[Farina] Helm v4 - context, dependency injection container, or something else… \nnot being able to get to information we didn’t know we needed is making the SDK hard or unusable for non-Helm apps. \nSee https://github.com/helm/helm/pull/10008 as an example. \nLooking for way to solve this in v4.\n[Farina] plugin can have wrong directory due to tight coupling\n[Farina] dependency injection may be the way to do this\n[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.\n[Butcher] context object or directory perhaps, but building a dependency injection pattern may be useful\n[Farina] context or CLI will both work interactively vs in a CI pipeline\n[Butcher] possibilities chainable context tuple pattern\n[Karena] Do we want to have a working group at KubeCon?\n[Butcher] Karen did request space for a planning session\n[Martin] remote participation options?\n[Bridget] I can join a device from an in-person session as needed\n\n[Martin] Do changes to an interface break backwards compatibility according to Go conventions? \nWe have precedent in Helm 3 where an interface was changed in https://github.com/helm/helm/pull/8363. \nShould we therefore allow it to be changed in https://github.com/helm/helm/pull/9702? \nCan’t see it mentioned in the backwards compatibility HIP: https://github.com/helm/community/blob/main/hips/hip-0004.md \nhttps://go.dev/blog/module-compatibility\n[Martin] we can probably get this in for 3.7\n[Farina] this isn’t documented in the backward-compatibility rules\n[Butcher] but it is documented in go’s guidelines\n[Adam] modifying an interface is a breaking change\n[Martin] we did merge a PR that breaks the interface\n\n[Bridget] do we have any update on adding triage maintainers?\n[Farina] Need a few more votes from maintainers for the first candidate\n\nAssignments for next meeting\nModerator:   Martin\nNotes:   Karena\nIssue Triage:  Farina \n\n\nAugust 19, 2021\nAssignments for this meeting\nModerator: Bridget Kromhout\nNotes: Matt Fisher\nIssue Triage: TBD\n\nAnnouncements\n3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 \nCall to action: review PRs for 3.7.0\nNew FAQ entry for tiller download questions: https://helm.sh/docs/faq/troubleshooting/#tiller-installations-stopped-working-and-access-is-denied \n\nDiscussion\n[Itai Spiegel]  Add --include-file flag for external files: https://github.com/helm/helm/pull/8841 \nWriting a helm chart for deploying applications, using the first helm chart as a dependency\nLooking for a summary of Helm’s architecture to help move the feature forward\n[Fisher] recommended step - first, reach out to the original author of the PR - perhaps you can see if their timeline matches yours\nItai: yes, I sent him email with no response\n[Fisher] It’s fair to work on an alternative if you don’t hear back\nAdam - he can open a new PR with the existing commits (Butcher: as long as the DCO is in place from the original committer)\nAdam (on rollback): when you send up files on an install, these files are added as templates, not configuration in parts of the chart\nAdditionally, there is a security concern of including files\nItai: we’re fine with this. The security concerns is not important in our case.\nBridget: just because security concerns are not important in this use case doesn’t mean we shouldn’t be concerned about security leaks\nItai: okay. So I’ll go and test/document this with regards to `helm rollback`\n[Bridget] progress on OCI support - https://github.com/helm/helm/pull/9782 \n[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.\nAdam & Fisher to pair\n[Bridget] Call-to-action to contact Josh Dolitsky later [emailed]\n[Stephane] next steps for https://github.com/helm/helm/pull/9180\nHad some conversations with FIsher about how to get this into Helm 3.7.0\n[bridget] added to Helm 3.7.0 for visibility\n\nAssignments for next meeting\nModerator:  Adam\nNotes:  Karena\nIssue Triage:  TBD\n\n\nAugust 12, 2021\nAssignments for this meeting\nModerator:    Adam Reese\nNotes:  Bridget Kromhout\nIssue Triage:  Matt Farina\n\nAnnouncements\n3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 \npatch release (3.6.4) scheduled for Wed August 11 has not occurred: https://github.com/helm/helm/milestone/112 \nPRs were not in shape for merging\nCancel 3.6.4 and move those items to the 3.7.0 milestone?\nFarina will do this cleanup step\nCall to action: review PRs for 3.7.0\n\nDiscussion\n [Fisher] HIP 14 (Helm Triage Maintainers) update\nhttps://github.com/helm/community/blob/main/hips/hip-0014.md \nLet’s sign on new maintainers at a lower commitment level, to help with PR review and triage\nThis role does not handle release management or event coordination\nHIP is approved - Fisher has created github “Team”\nSome candidates in the pipeline\nNominate candidates using the same process as for core maintainers\nAction 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\n [Martin] Generate `values.schema.json` during  `helm create` https://github.com/helm/helm/issues/10009 \nShould this be added or do we keep the scaffold chart simple and the basics to better help users onboarding to Helm?\nAdam: “create” should be as simple as possible - let’s not add to the base “create” command\nFisher: https://github.com/karuppiah7890/helm-schema-gen - this plugin is not currently maintained, but this discussion happened before\nFarina: “create” is already too complex - Helm 4 could make that simpler - but starter templates could also be easier.\nFisher: compare https://github.com/cargo-generate/cargo-generate - values schemas can be quite opinionated\nMartin: next steps - I might create a proposal and perhaps a HIP for Helm 4\nScott: we’ve talked about a “wizard” before but that is too much complexity for helm itself (as opposed to being a plugin)\nFisher: yeoman is great for creating wizard-like templates. we've been using it in a few projects. https://yeoman.io/ \nScott: docs improvements ideas could be migrated over from the legacy charts repo\nMartin is going to carry this discussion forward (helm create, templates, best practices, wizards…)\nAdam: 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\nScott: Decoupling that could make backwards compatibility for v4 easier to maintain\n[Martin] `helm repo update` commands return exit code 0 regardless of errors or not https://github.com/helm/helm/issues/10016 \n[Martin] Code implemented to just output any errors but does not return an error back to cobra. Is this expected behaviour? \n[fisher] dropped a comment in the ticket providing some historical context\nFisher: “helm serve” was mostly a convenience but this behavior might be a workaround for that\nFisher: define “failure” - what if _some_ updates succeed and others (like helm serve) don’t and that is expected?\nFisher: we could consider this change for Helm 4 with a HIP - let’s not surprise people by changing 5-year-old behavior.\nMartin: agreed, this is how it works, but maybe we reconsider this for Helm 4\nFisher: _all_ failing definitely is exit code 1, but it’s ambiguous after that (as to if we need _any_ or _all_ to succeed).\nFarina: 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\n[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?\nAction item: Bridget to write updated FAQ entry\n\nAssignments for next meeting\nModerator: Bridget Kromhout\nNotes: Matt Fisher\nIssue Triage: TBD\n\nAugust 5, 2021\nAssignments for this meeting\nModerator: Marc K    \nNotes: Jasper \nIssue Triage: Matt Farina\n\nAnnouncements\nNext patch release (3.6.4) scheduled for Wed August 11: https://github.com/helm/helm/milestone/112 \n3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 \n\nDiscussion\n[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. \n[Farina] Unlikely going down this path. May go down sigstore path. \n[Shoubhik] https://github.com/sigstore/helm-sigstore \nDoc needs to be updated to reflect latest. [action item: Bridget]\n[Farina] Helm 4 (and the release engineer) Target Oct 2021\nHIP 12: https://github.com/helm/community/blob/main/hips/hip-0012.md\nNeed to identify Release Engineer for Helm 4 \nRequire to be Helm/helm maintainer to be release engineer\nRole and responsibilities: Person who oversees Helm 4 from technical coordination\n[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)\n[Martin] Do we have enough stories, features for Helm 4?\nDefined in HIP on how to short circuit progres to halt development\nKick off meeting to be scheduled\n[Shoubhik] When should we discuss what will go into Helm 4\n[Farina] Opportunity for breaking changes. Require HIP to describe request\nConsider topic of Helm Releases on cluster\n[Farina] Helm is a package manager and does not enforce a specific style. Need to understand how it works in a specific scenario.\n[David] Helm having multiple resources in templates but the user does not have permission to perform action\n[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). \nCan we improve the experience earlier during or before the installation \n[Paul C] Opportunity for a plugin to perform this check\nConsider split responsibilities to install different components of a chart\n[Farina] This is release management and beyond scope of a package manager \n[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\nThis may be fixed by https://github.com/helm/helm/pull/9180\n[Farina] Opportunities to improve Helm 4 CLI and SDK\nNeed to brainstorm for using SDK to flush out stories \nAction item for Scott to lead\nNeed to consider alternatives on how to capture this feedback.\n[Marc] PR to add some completion descriptions (HIP 8)\nFor 3.7?\nhttps://github.com/helm/helm/pull/9421\nhttps://github.com/helm/community/blob/main/hips/hip-0008.md\n[Bridget] Where to track Helm 4 ideas? Attached to a HIP or create separate HIPs?\n[Farina] use HIP to track all changes\n\nAssignments for next meeting\nModerator:    Scott Rigby\nNotes:  Bridget Kromhout\nIssue Triage:  Matt Farina\n\nJuly 29, 2021\nAssignments for this meeting\nModerator:   Marc Khouzam\nNotes:     Karena Angell\nIssue Triage:    Matt Fisher/Martin\n\nAnnouncements\nNext patch release (3.6.4) scheduled for Wed August 11: https://github.com/helm/helm/milestone/112 \n3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 \n\nDiscussion\n[Martin] Support for bearer token authentication https://github.com/helm/helm/pull/8447 \nFarina: it’s stale because it still needs work\nFarina: want to pass via stdin, need to be security conscious\nFarina: just need to think through the implementation details in the PR\nAI - Farina to follow-up\n[Martin] Go SDK installing Kubernetes resources to the wrong namespaces https://github.com/helm/helm/issues/8780 \nFarina: two namespaces - k8s resources diff than the records; can only set it once when you instantiate\nNeed to instantiate k8s client with new namespace\nFarina: no way to change this until Helm v4\nFarina: 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\nAI - Farina to share code (from https://github.com/rancher-sandbox/hypper) where it’s done\nFarina: initializing isn’t setting it right\n\nAssignments for next meeting\nModerator: Scott Rigby    \nNotes:    Jasper \nIssue Triage: Matt Farina\n\nJuly 22, 2021\nAssignments for this meeting\nModerator:    Martin Hickey\nNotes:     Karena Angell\nIssue Triage:    Martin Hickey/Matt Fisher\n\nAnnouncements\nNext patch release (3.6.4) scheduled for Wed August 11: https://github.com/helm/helm/milestone/112 \n3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 \n\nDiscussion\n[Martin] Install chart from remote repo should it get the latest dependencies https://github.com/helm/helm/issues/9962 \nIf helm repo add and then the person says helm install\nFisher: expectation, would fetch during build or helm dependency update\nAndrew: hard dependencies\nFisher: shouldn’t run a helm install and have it run and get any dependencies without you knowing\nFisher: further inspection needed\nAI: ill look into more\n\n [Martin] Helm create a namespace from template which it installs into https://github.com/helm/helm/issues/9965 \nNamespace plus custom labels\nFisher: tricky problem to solve\nFisher: Helm 1&2, original assumption, installed by Sys Admin\nPeople didn’t setup acl’s for their grpc endpoints\nMitigated in 1&2, things stored in release record vs release namespace\nChanged in Helm 3, user installs\nResource quotas in namespaces, etc\nHelm 3 - move to kubectl approach\nCreate namespace ahead of time\nSame as CRD problem\nFisher: Documentation? How to manage namespaces outside the chart\nFisher: namespace mgmt recommendation - one is to use helmfile\n\n [Martin] Adopt resources to a release https://github.com/helm/helm/issues/9958 :\nAny docs for this feature?\nPotential bug: https://github.com/helm/helm/issues/9958 \nIssue with migrated releases because labels/annotations didn’t exist prior to Helm 3.2.0\nFisher: If you can get hold of Jacob, best person to talk to\nFisher: Alternative, look through the code and create a HIP\nA little familiar with the code\nAI: Martin to reach out to Jacob\n\n[Karena] Helm 3.7 blog / release themes:\nAny themes popping up for next major release\nDo people think it is a good idea? Do anyone want to work with Karena to create a blog of it?\nFisher: happy to help\nOpen Initiative PR?\nAlso look at Helm 4 HIPs \nFall? Helm 4 discussions starting\n[Fisher] call for more reviews on Helm Triage Maintainers HIP https://github.com/helm/community/pull/199\nMartin: should look at it too\n\nAssignments for next meeting\nModerator: Marc Khouzam    \nNotes: Karena Angell     \nIssue Triage:   Matt Fisher\n  \n\n\nJuly 15, 2021\nAssignments for this meeting\nModerator:    Bridget Kromhout\nNotes:     Jasper Chui\nIssue Triage:    Matt Farina\n\nAnnouncements\n[Farina] Yesterday (Wed July 14) patch release (3.6.3): https://github.com/helm/helm/releases/tag/v3.6.3 \n[Farina] Next patch release (3.6.4) scheduled for Wed August 11: https://github.com/helm/helm/milestone/112 \n[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 \n\nDiscussion\n[Bridget] repo cleanup project\nWe merged https://github.com/helm/monocular/pull/691/ - should the repo be archived in the github UI?\n[Farina] We can click the clicky\nshould we archive https://github.com/helm/query-store-quay-logs ? \n[Farina] Need to check if its still in use\nUsed to store metrics for quay\nData kept for 2 months from public source. Source of data into this repo\n[Farina] 3-way merge patch and CRs https://github.com/helm/helm/issues/9937 (feature or bug)?\nNeed to clarify expected use case \nNot intended for CR\n[Adam] Written when kubernetes does not support 3 way merge\nBehaviour has changed and needs to be updated\nWhich release should include this\nDocumentation is too general\n[Martin] Inconsistency bug and documentation bug, could break backwards compatibility\n[Bridget] Open issues in repo to address the documentation bug\nTarget fix for Helm v4\n[Farina] Feature change needs to be included in major release\nbehaviour change needs to be behind a flag\n[Marc] Building in Kubernetes without Docker, any experiences?\nBuild container in a kubernetes cluster\n[Andrew Block] Use Shipwright and Buildah\n[Josh] use Kaniko\n[Farina] Docs bug or Helm bug with no repo dependencies… https://github.com/helm/helm/issues/9928 \nSub chart in a chart can only exist in a directory in a repository not a chart archive. Doc says that it could\n[Adam] Would work if it’s listed as a dependency\n[Farina] It is not a dependency\n[David] Doc bug and feature to support archive in future release\n[Martin] How did it work in 3.x?\n[Farina] Checked original source. It is not a regression\n[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 \nPR already submitted to fix\nIs this a doc defect for a file?\nSuggestion: Update doc to mark this as optional in the file scheme  \nNext step: Version is required and not optional\nIdentify as a bug to be addressed\n\nAssignments for next meeting (note: Farina, Bridget, and Adam will be gone - volunteers needed)\nModerator:     Martin Hickey\nNotes:      Karena Angell\nIssue Triage:   Martin Hickey\n\n\n\nJuly 8, 2021\nAssignments for this meeting\nModerator:   Adam\nNotes:  Karena  \nIssue Triage:   Farina\n\nAnnouncements\nNext patch release (3.6.3) scheduled for Wednesday July 14th: https://github.com/helm/helm/milestone/110 \nFarina: one more pass at PRs this week then gtg\n\nDiscussion\n[Farina] indexes in OCI registries\n(continued from last week)\nButcher: they’re storing the apt index in an image layer\nExperiment with a plug-in\n [Farina] --repo flag and username/password https://github.com/helm/helm/issues/9599 and https://github.com/helm/helm/pull/9760 \nNote, this same idea would apply to `helm install` and `helm upgrade`\nhttps://github.com/helm/helm/issues/9599\nDoesn’t do set when `helm repo add`\nIs it a bug but is anything else actually using it?\nBug or feature change?\nFisher: feature addition in helm 3, PR merge\nFarina: like it, when should it be released?\nAI: Farina to dig into it to look if is a regression or needs to be in 3.7\nAdam: should apply to any repo\n[Farina] Move to GH Actions… https://github.com/helm/helm/issues/9921 \nExample of CI issues… https://github.com/helm/helm/pull/9763 \nTakes 30 mins / timeouts on linting\nCircleCI performance issues\nFisher: this is going to get worse over time, GitHub Actions could help run tasks in parallel\nJosh: GH action for golang ci lint tool - maybe consider\nFarina: linter deprecated error?\nAdam: open PRs will have to rebase on it\nJosh: if use GH Actions, can keep running Circle in parallel\nFarina: start doing Windows testing in GH Actions\n[Fisher] HIP: Helm Triage Maintainers https://github.com/helm/community/pull/199\nIntermediary role? Help triage, shadow\n[Bridget] relevant to Adding HIP 7 to document subprojects https://github.com/helm/community/pull/156 as well? Roles for charts maintainers?\n[Marc] Is updating a single repo safe?\nhttps://github.com/helm/helm/pull/9845\nWhat happens if you update in one repo, will it update all?\nMarc: recipe does a helm repo add (which doesn’t do an update)\nHelm repo add; helm repo update\nAndrew: wants more control over when to update\nMarc: risk in inconsistency\nFarina: dependency mgmt handled, thinks it’s okay\nReduce bandwidth, and mem\n[Scott] Maintainers track talk for KubeCon NA\nTechnical 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\nCTA: any topics you think should be covered? Speak up!\n[Marc] Dependabot details?  Why hasn’t it picked up Cobra 1.2.1?\nToo many dependabot issues?\nPlease create a PR!\n\n\n\nAssignments for next meeting\nModerator:    Matt Fisher\nNotes:     Jasper Chui\nIssue Triage:    Matt Farina\n\n\nJuly 1, 2021\nAssignments for this meeting\nModerator:  Bridget\nNotes:   Butcher\nIssue Triage:  Fisher\n\nAnnouncements\nFarina: releases\nReleased 3.6.2 as fix for regression this week.\nFixes a bug that became more pronounced by security fix\nNext patch release (3.6.3) scheduled for Wednesday July 14th: https://github.com/helm/helm/milestone/110 \nAsk: Maintainers, please review PRs in that milestone\n\nDiscussion\n[Bridget] helm org cleanup continues\nCan we complete https://github.com/helm/hub/pull/484 so we can archive the helm/hub repo?\nBridget: Process was started but not complete. Anything blocking completion?\nCan we archive https://github.com/helm/repo-audit ? Seems to be an experiment that may be concluded.\nBridget: Any reason not to archive?\nFarina: 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\n\n[Farina] Automatically adding repos during build processes… https://github.com/helm/helm/issues/9840 and https://github.com/helm/helm/pull/9841 \nCertain commands will error out if a repo has not been added, forcing the user to add the repo manually\nThese 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)\nButcher: this can mask the source of untrusted packages - with the recent software supply chain attacks, this is particularly inadvisable\nJoe T: this is similar to distro package naming conflicts\n\n[Adam] annotations nested in List objects are not respected https://github.com/helm/helm/issues/9829 \n(continued from last week)\nAdam: 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.\nPaul: It seems fair to say that we only respect annotations on the top-level object, and ignore the items in the list\nFarina: A “keep” on a nested item in a list: How would we handle that?\nAdam: 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.\nFarina: 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. \n\n[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?\nBridget: We think this is ready to merge.\nFarina: I will do one final review and merge\n\n\n[Farina] indexes in OCI registries\n(continued from last week)\nQuick review of where we ended last week. \nFarina: 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\nJosh: 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…\nFarina: Would prefer not to need registry-side add-ons\nJosh: Could, for example, create a list object that would list all of the chart names for a given user…\nFarina: But… (I missed the objection)\nJosh: We could make a new media type for the existing index file and store/retrieve that, pointing to the full blob path\nFarina: If you have a namespace, can you list all the things in it?\nJosh: 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]\nFarina: 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\nJosh: Only thing in the Discovery API on OCI Dist is which tags for a given object. \n\n\nAssignments for next meeting\nModerator:   Adam\nNotes:  Karena  \nIssue Triage:   Farina\n\n\n\nJune 24, 2021\nAssignments for this meeting\nModerator: Scott \nNotes: Karena (Andy in for Karena)\nIssue Triage: Adam\n\nAnnouncements\nFarina: Next patch release (3.6.2) scheduled for Wednesday July 14th: https://github.com/helm/helm/milestone/110 \nLooking for reviewers\nButcher: 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 \n\nDiscussion\n[Bridget] What remains before we can archive the helm/hub repo? See question in https://github.com/helm/hub/issues/439#issuecomment-820598759 \nFinal steps have been complete and archive can be completed\nDeprecation notice needs to be added\nAction: Scott will PR in the “Obsolete” and click the “archive repo” in settings. PR: https://github.com/helm/hub/pull/484\n[Farina] managedFields and manager… https://github.com/helm/helm/issues/9859 \nNew field in metadata\nAdded in 1.18 and displayed in kubectl output. Hidden starting in 1.21\nNew field for Helm to be created to denote the tool that performed the action\n[Farina] indexes in OCI registries\nChallenge is that no metadata can be queried (no search API)\nhttps://hypper.io/ is talking about putting index files into OCI registries\nFisher: review of HIP 6 OCI PR is ongoing\nChallenge in a race condition and locking\nWhat is managing the creation of the index?\nHelm CLI? What about those not using the CLI\nJosh: Why are we trying to implement a search mechanism?\nFarina: Its important to be able to determine what is available and what specific versions\nScott: 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?\nTopic to be continued next week or in another forum\n\n[Adam] annotations nested in List objects are not respected https://github.com/helm/helm/issues/9829 \nOnly looks at top-level object\nMaybe: cascade down?\nWould be breaking change\nIf anyone has any thoughts, provide details in the issue and follow up next week.\n\n[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?\n\nAssignments for next meeting\nModerator:  Bridget\nNotes:   Scott\nIssue Triage:  Fisher\n\n\nJune 17, 2021\nAssignments for this meeting\nModerator: Matt Farina \nNotes: Bridget\nIssue Triage:  Adam\n\nAnnouncements\n[Farina] Helm 3.6.1 released. \nThis was a security release (affects usernames/passwords for repositories)\nAdded a new flag to preserve the old behavior when needed\nNext patch release scheduled for Wednesday July 14th\n\n\nDiscussion\n[Bridget] HIP 6 OCI changes in flight for 3.7.0 (End of August): https://github.com/helm/helm/pull/9782 - please review!\nJosh: thanks for comments\nButcher: yesterday we tri-paired (Adam: tri-pairitops!)\nToo large to review in one pass - we started with running everything, then looked at impacts on public API and actions\nJosh: will respond to the first round of comments\nJosh: tests: https://github.com/bloodorangeio/acceptance-testing/blob/hip-6-push/testsuites/registries.robot \nButcher: read the HIP before trying this out - the HIP dictates the UX\n\n[Bridget] HIP 4 - can we merge this in? Question for Marc/others https://github.com/helm/community/pull/145#issuecomment-848912289 \nNeeds a confirmation about not being able to change *.yaml at all\nNeeds another approval\nMarc: this is the backwards-compat HIP - one unaddressed concern about yaml compat\nFarina: 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\nButcher: the security audit is here: https://github.com/helm/community/tree/main/security-audit \nScott: we need to update the docs \nFisher: 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\nScott: I will update the docs\nMarc: I’ll reach out if I don’t see it there\nButcher: I’ll add the list to that comment thread on the issue\nFarina: once that’s in, I’ll review it.\n\n\n[Marc] Why was updating a single repo removed in helm v3? \n“helm repo update <repo>”\nMissing PR?\nhttps://github.com/helm/helm/pull/5182 \nWith many repos configured on my machine, a script would benefit from only updating the repo it cares about\nOr helm repo add could cause an automatic update when repo exists?\nFarina: This appears to have not been brought over to v3 - this would be an easy feature request to port over\nFisher: possible considerations around chart locking, but I don’t think we _chose_ to not port this.\n\n[Josh] mailing list votes - should we add reminders to this call?\nFarina: someone needs to track down all potential votes\nButcher: the project adoption one will be simple majority (4 org maintainers)\nMailing list vote this time for Martin\n\nAssignments for next meeting\nModerator: Scott\nNotes: Karena \nIssue Triage: Adam\n\nJune 10, 2021\nAssignments for this meeting\nModerator: Marc \nNotes: Jasper\nIssue Triage:  Matt Farina\n\nAnnouncements\nNo patch release yesterday, as it would have been within 4 weeks after a minor release\nNext patch release scheduled for Wednesday July 14th\nSummer vacations make things quiet at the helm! \n[Farina] Tend to see some slow down in the summer\n\nDiscussion\n[Bridget] HIP 6 OCI changes in flight for 3.7.0 (End of August): https://github.com/helm/helm/pull/9782 \n[Farina] Make OCI available as GA\nPlease review PR \n[Marc] What can be changed?\n[Farina/Adam] As long as it doesn’t have UI impact can be changed \n[Farina] Some experimental commands are available when experimental mode is enabled\nHIP (4?) in flight that defines what can change\nMaintainers to Review and determine next steps\n[Farina] Target end of July to ensure it doesn’t break anything. \n[Joe] A number of files are being modified and removed\nDoes impact public API\n[Martin M] PR backlog  (154 PRs open)\nWhat is the plan to bring this down to a manageable level?\n[Farina] Usually hovers around ~100\nHoping to start going through these PRs if someone else can take over triage\nSteps to maintainer is to provide constructive feedback on PR review\nAnyone can provide review \n[David] Should we wait until tests are passing?\nSecurity scan is gated but should not stop reviews\n[David] Testing and verifying fix will be useful\n[Farina] ensure test format is consistent with other tests\n[Bridget] Chartmuseum repos proposed for Helm org membership: https://github.com/helm/community/issues/191 \n[Marc] Martin will cherry pick for next release\nRelease branch will be ready by day of release\n7 PRs in 3.6.1 milestones that are not reviewed\n[Farina] Will try to review to get it in\nAny help is appreciated\n\nAssignments for next meeting\nModerator: Matt Farina\nNotes:  Bridget\nIssue Triage:   Adam\n\nJune 3, 2021\nAssignments for this meeting\nModerator: Scott Rigby\nNotes: Matt Fisher\nIssue Triage: Matt Butcher\n\nAnnouncements\n[none]\n\nDiscussion\n[Josh] Various HIP 6 questions\nExperimental flag, internal/ vs. pkg/, removal of “helm chart”\n“Pusher” interface - implement uploader plugins identical to downloader plugins?\nMultiple requests made to fetch .prov, even though both chart and prov can be fetched at once\n[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.\nIs there a way in memory to extract chart metadata from .tgz raw bytes?\n[fisher] I believe pkg/chart/loader has functions for this\n“read” function - reader interface\n[fisher] https://github.com/helm/helm/blob/bf486a25cdc12017c7dac74d1582a8a16acd37ea/pkg/chart/loader/archive.go#L188-L189\nOutput 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\n[fisher] would this be useful to append as a PR to HIP 6?\nAdd --digest=<digest> flag on “helm pull” to verify manifest digest? Later?\nThe 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?\n[josh] looking for feedback on these items\n[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\n[josh] the underlying client is being completely overhauled, so it would be easier to change it all underneath. Is this OK?\n[fisher] while it’s experimental, we can make whatever changes make sense - go ahead if needed to move the experiment forward\n[scott] are there any thoughts on pulling out the registry package into a separate library/repository?\n[josh/farina] I think the ORAS project handles this\nORAS: https://github.com/oras-project/oras\n[farina] when can that become available for other projects? What are the requirements for removing experimental flag?\n\n\n\n[Simon K] Anything else needed for https://github.com/helm/helm/pull/9713 (brought up by David last time)? Next steps?\n[fisher] will need two maintainers to review it (cdndoit18 is not a maintainer)\nAdding a reproducible test case is a great way to help people see more\n[Paul] Does anyone want to enter a Helm team for CNCFaceoff (https://twitter.com/mattstratton/status/1397565630975463432  )\n[bridget] If they do, how should they reach out?\nThere’s a form in the tweet thread. - https://twitter.com/mattstratton/status/1397567060012580864\n\n\n[Bridget] notification emails from ArtifactHub - do we need to do any followup?\n [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\n[farina] if you post something on Artifact Hub, you can subscribe to notifications to be informed of any security issues\n\n\n\nAssignments for next meeting\nModerator: [Bridget if nobody else volunteers] \nNotes: Jasper\nIssue Triage:  Matt Farina\n\n\nMay 27, 2021\nAssignments for this meeting\nModerator: Adam Reese\nNotes: Karena Angell\nIssue Triage: Matt Farina\n\nAnnouncements\n[Farina] 3.6.0 is released\n[Farina] the release date for 3.7 is set to Wednesday September 8, 2021\nKubernetes 1.22 is scheduled for August 4th; this gives us time to test.\nLooking ahead: there will be one more k8s release in 2021 (1.23)\n[Butcher] Emeritus maintainers\nThanks, Vic & Brian!\nMartin Hickey has been nominated as a new org maintainer\nDiscussion\n[Farina] Generating reproducible tarball fix - https://github.com/helm/helm/pull/9674 \nIs it a breaking change to drop the timestamp?\nFisher: need to address a couple of things in the PR before moving forward. Spend time writing a unit test would be helpful\nFarina: agree, need more testing - concerned removing the date could be a breaking change. Focus on whether stripping the date is a breaking change.\nButcher: Because some people use the hash to see when the tar has been rebuilt, even if its contents were the same\nButcher: And the Go implementation is different than BSD and Gnu tar, too\nScott: https://github.com/helm/helm/pull/9674#discussion_r640793402\nMaybe feature flag could solve it\nFollow-up: Farina going to go back and address some things in PR\n[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.\n[fisher] approved.\nFisher: more nuanced - bitcoin mining!\nMarc: trust github automation?\n[Adam] Global values https://github.com/helm/helm/pull/9333 \nNeeds another maintainer’s eyes on it\nFisher: wants to proceed with caution \n[Scott] If time, Farina do we want to discuss KubeCon NA session ideas on this call?\nFarina: tech focused talk on charts\nFisher: yes, if other CfP doesn’t get accepted\nAI: Farina will start a doc\n\nAssignments for next meeting\nModerator: Scott Rigby\nNotes: Matt Fisher\nIssue Triage: Matt Butcher\n\nMay 20, 2021\nAssignments for this meeting\nModerator: Marc Khouzam\nNotes: Jasper Chui\nIssue Triage: Matt Farina\n\nAnnouncements\n[Farina] Next release is 3.6.0, planned for next week: Wednesday May 26th\nRC available for your evaluation: https://github.com/helm/helm/releases/tag/v3.6.0-rc.1 \nPlease test it out and let us know if there are any issues\n[Bridget] Helm at KubeCon EU was a huge hit! Thanks to all who participated; start thinking about KubeCon North America! Numbers from Karen Chu: \nTuesday, May 4 Helm office hours attendees: 458\nWednesday, May 5 Helm office hours attendees: 312\nThursday, May 6 Helm office hours attendees: 233\nHelm project booth visitors: 1,233\n[Karena] KubeCon NA - CfP deadline is this Sunday 11:59 PM PDT\nBridget is happy to review any proposals\n[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.\nLooking for additional topics to document\n[Farina] Vic stepped down from Helm org maintainership\nCredit for the CI infrastructure for stable/incubator - thank you!\n\nDiscussion\n[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.\n[Marc] For Josh, regarding acceptance testing repo \n[Josh] Needing updates\nHELP WANTED\n[Farina] Pull sizer: designate size of issues \nShould not be deprecated as there are no alternatives\nHelp needed to determine if there are GitHub actions that could be used to achieve this function \n\n[Bridget] Have you commented on all HIPs of interest to you? https://github.com/helm/community/pulls has various HIPs to check out. \n\n[Butcher] Continuing discussion for HIP for Helm 4 planning and development process (HIP0012) \n[Bridget] Should we defer to next week?\n[Farina] Highlights approach for Helm 4, including roles and responsibilities\nFeedback is useful\n[Martin] May need additional updates to branching.  Waiting on feedback from Matt Fisher\n[Bridget] Should we say lazy consensus by next week?\n[Farina] Need approvals from 2 helm/helm maintainers\n[Josh] Is there a requirement to push for Helm 4\n[Farina] Opportunity for breaking changes, api changes, clean up.  Requests from the community. \n[Martin] Need a list of PRs before Helm 4 kicks off\n\n\n[S Bose] Support for the --hide-secrets flag, PR is good to go https://github.com/helm/helm/pull/9130 \nBridget: should this go in milestone 3.6.1? 3.7.0?\n[Farina] Requires approval from two maintainers\nSoonest is 3.7.0 as it is a feature addition\nPossibly 3.7.0 (September 8). Month after next k8s release\n\n[David P] Pipeline doesn’t run and need approval from maintainer to approve\n[Farina] This is a good forum to raise this \nNew requirement from Github within last few weeks\nBridget: https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/ \n\n[Bridget] Welcome Annie Wang, new intern on Bridget’s team\n\n\nAssignments for next meeting\nModerator: Adam Reese\nNotes: Karena Angell\nIssue Triage: Matt Farina\n\nMay 13, 2021\nAssignments for this meeting\nModerator: Adam Reese\nNotes: Karena Angell\nIssue Triage: (2 weeks) - Butcher, Fisher\n\n\nAnnouncements\n[Bridget & Farina] Next release will be 3.6.0\nRC planned to be cut Monday May 17th\nrelease planned for Wednesday May 26th\n[Bridget & Butcher] Butcher’s HIP for Helm 4 planning and development process (HIP0012) has one more week for discussion\n\nDiscussion\n[farina] HIP on caching https://github.com/helm/community/pull/185 \nCurrently - when pull or install, chart is stuck in cache with index files  - creates conflicts\nHIP - local cache w/ content addressability\nAlso helps w/ people who download the same charts over and over again\nNeeds two maintainers to look at\nMatt Fisher\n??\nAlso, look at to make sure there isn’t anything that can go horribly wrong\n[farina] Hypper Demo https://hypper.io/ \nBuilt on top of Helm\nFor cluster admins\nInstall charts into separate namespaces\nJoe J: shared dependencies but different values?\nFarina: still working through that\nFarina: currently, can alter namespace name and release\nBridget: use cases?\nFarina: used by tooling, structured like helm, future wrap the sdk\n[karena] new FAQs from office hour sessions\n\n\nAssignments for next meeting\nModerator: Marc Khouzam\nNotes: Jasper Chui\nIssue Triage: Matt Farina\n\nMay 6, 2021\nCancelled this week - KubeCon EU (various Helm sessions and office hours - https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/schedule/) \n\nApril 29, 2021\nAssignments for this meeting\nModerator: Marc Khouzam\nNotes: Matt Fisher\nIssue Triage: unassigned\n\nAnnouncements\n[Bridget] Next release will be 3.6.0\nRC planned to be cut Monday May 17th\nrelease planned for Wednesday May 26th\n[Bridget] Helm org repo audit continues\n[Bridget] Sign up to participate in KubeCon EU next week: https://docs.google.com/spreadsheets/d/1yJyvuzHoOoQk0yiGGUXPfDUCo_mO_UWyryFURc1HOX4/edit?usp=sharing \n“Meet the maintainer” means staffing the booth in the KubeCon EU event platform\n“Project office hours” are held on Bevy\n[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. \n\n\nDiscussion\n[Marc] Backwards-compatibility for yaml files (Hip 0004): https://github.com/helm/community/pull/145 \nFisher: security issue based on unexpected overwrites\nFisher: solved by strict field checking\nKarena: documentation of this limitation would be good\nMarc: why can’t we introduce optional fields?\nFisher: older versions of Helm would have no notion of this field. Introducing a new field would break strict parsing\nFisher: let’s be cautious about circumventing security - avoid footguns\nAdam: when strict checking is enabled, it doesn’t error out. It just ignore those fields. Right\nFisher: I believe strict checking does tell YAML to error out on those fields. By default those fields are ignored\n\n[Marc] Hip 0010 for distributed pick process: https://github.com/helm/community/pull/172\nMarc: This is ready for review. I left if there for when anyone has time to review\n\n[Josh] Registry support + OCI Distribution + ORAS updates\nHIP 006: https://github.com/helm/community/blob/main/hips/hip-0006.md\nThe Distribution spec was put up for a 1.0 vote this week\nThere is a movement to move the oras project as a CNCF sandbox project\nI will be working on the reference implementation for HIP 6. Expect that to be coming in the next month or so\nFisher: is the artifacts proposal part of the v1.0 vote or is that separate?\nJosh: 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.\nJosh: I would ask if you can join the OCI meeting and ask about that\nPaul: does harbor support Helm charts in the registry?\nJosh: short answer yes\n\n[Joe] I tried asking in slack, but can this get into 3.6? https://github.com/helm/helm/pull/9425 \nThere'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.\n[Bridget] let’s try to get it some reviews after KubeCon EU?\nAdded to the 3.6.0 milestone for review\n\nAssignments for next meeting (Thursday May 13th)\nModerator: Adam Reese\nNotes: Karena Angell\nIssue Triage: (2 weeks) - Butcher, Fisher\n\nApril 22, 2021\nAssignments for this meeting\nModerator: Matt Farina   \nNotes: Karena Angell   \nIssue Triage: Matt Fisher, Joe Julian (shadow)\n\nAnnouncements\n[Farina] Next release will be 3.6.0\nTarget for Wednesday, May 26th for Kubernetes 1.21\nMonday of the week before, RC will be cut - May 17th\n\nDiscussion\n[Butcher] HIP for Helm 4 planning and development process (HIP0012)\nWhat will be selected for development\nWhen will it be worked on\nHow to stop the process if necessary (lack of community resources/involvement)\nAcceptance: project maintainers\nMid to end of May - May 20th dev meeting, finalize comments/acceptance\nSomeone needs to make sure they’re looking at all the HIPs and they work well together\nShoubhik: High level themes for Helm 4?\nFarina: separate process from content, but sdk changes, feature changes, etc.\nFarina: define process first and pull those discussions into the bigger picture strategy for Helm 4\n\n[Bridget] Helm org repo audit progress\nCan we archive helm/hub and other inactive repos?\nLet’s finish the branch rename for active repos\nProgressing and will continue to progress\nFarina: will help after KubeCon/CNcon\n\n\n[jannfis/shoubhik] Helm integration with Argo CD\nWant to talk about https://github.com/helm/helm/pull/9040\nWe need --kube-version for “helm template” badly\nJann: Maintainer for Argo CD, in Argo community, some people are having difficulties installing charts\nFisher: validate flag - grabs kube version from live k8s cluster - possibility?\nJann: separate isolated process for processing manifests using a repo server, no live info from cluster - security requirement\nFarina: is there a conflict setting the kube version and validating? Maybe specify can only have one or the other\nFarina AI: will add to backlog for 3.6.0 [Bridget added to the milestone for review, as of April 29, 2021]\nShoubhik volunteering to dive deeper into use cases\nFisher: Helm 2 did not do openapi validation\n\n[shoubhik] Curiosity question :) What’s the due diligence needed when we do kubernetes version bumps? https://github.com/helm/helm/pull/9595 \n\n[Srishti] question : I had a question around the issue I recently raised https://github.com/helm/helm/issues/9620\nFarina: you can still put CRDs in the templates directory\nFarina: You can use a separate chart to template crds: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-2-separate-charts\nFarina: STRONGLY suggest reading the CRDs HIP: https://github.com/helm/community/blob/main/hips/hip-0011.md\nJoe Julian: important reason for CRD templating: conversion webhooks\nButcher: no changes to CRDs for the rest of Helm 3 lifecycle, Helm 4 HIPs would be a good place to discuss\n\n[dperaza] question: Recording for last contributor summit out?\n[Bridget] CNCF will release that; Helm maintainers don’t control the timing. We expect it around the end of the month.\n\n[Scott] I’ll be archiving some repos that I understand were already discussed, and will update the spreadsheet accordingly! :-) Thanks Bridget for the reminder\nAlso 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\n\nAssignments for next meeting\nModerator:   Marc Khouzam\nNotes:  Matt Fisher \nIssue Triage: \n \nApril 15, 2021\nAssignments for this meeting\nModerator:   Bridget  \nNotes:    Jasper\nIssue Triage:   Butcher\n\nAnnouncements\n[Bridget] Branch rename (to “main”)\nin progress for repos under https://github.com/helm\ncheck your repos and rename if need be!\nInstructions: https://github.com/github/renaming \nWorking checklist: https://docs.google.com/spreadsheets/d/13OjQnpzCRrdFtJ6nhzO7c7JmsKjnyJ48y63ry1GmP14/edit?usp=sharing \n[Farina] v3.5.4 released\nNext release 3.6.0 Target for May for Kubernetes 1.21\n\nDiscussion\n[Marc] Blog about DockerHub rate limits (see last week)\nShould we clarify to community if they may think it is caused by Helm?\nCould use a blog to inform community\n[Joe T] Starting to collect details, could put towards google docs\n[Fisher] Rate limit has been in place since last October\n[Farina] Are we seeing any complaints?\n[Bridget] Not directly, just hearing from community\n[Bridget] To review docs and update as appropriate \n[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  \n[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) \n[Farina] Has a list of repos to be archived\nMonocular: Ready to be archived. Need to inform community\nBridget to connect with Farina to create list of repos to be archived\n[Butcher] Only maintainers can / should archive repos\n[Marc K] What is the process to identify which PR to include in a release?\n[Farina] Only the PRs that were closed \n[Butcher] https://github.com/helm/community/pull/145 - backward-compat HIP\n[Fisher] Needs to be approved by core maintainer\n[Marc K] Are referenced implementations required?\n[Fisher] If HIP requires one then it should\nMarc to remove referenced implementation section\n[Marc] Should we have a master list of what cannot change?\n[Butcher] Agree that it should be in the www documentation. Not required before HIP is approved.\n[Fisher] Question deferred to future discussion\n[Marc] HIP will be used for backward compatibility criteria\n[Bridget] PRs to be reviewed \n\nAssignments for next meeting\nModerator: Matt Farina   \nNotes: Karena   \nIssue Triage: Matt Fisher, Joe Julian (shadow)  \n\n\nApril 8, 2021\nAssignments for this meeting\nModerator:    Marc K \nNotes: Karena A   \nIssue Triage:  Adam and Bridget\n\nAnnouncements\n[Bridget] Branch rename (to “main”)\n in progress for repos under https://github.com/helm\ncheck your repos and rename if need be!\nInstructions: https://github.com/github/renaming \n[Bridget] Helm Contributor Summit is a wrap!\nCNCF will publish videos.\nShout out to Karen Chu and Matt Butcher for all their work putting it together.\n[Bridget] get those bug fixes in!\n3.5.4 will contain only bug fixes and be released on April 14, 2021\nNew “pick” process should help with release\nMarc wants to help w/ release\nAI: Whoever is cutting the release, pull Marc in\n\nDiscussion\n[Bridget] Dockerhub rate limiting and defaults\nPotential 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)   \nPotential change: https://github.com/kubernetes/ingress-nginx/pull/7018/files (to decouple the registry and repository)\nAnything else to consider here?\n[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\nBridget: where should this be documented? ArtifactHub? Helm docs?\nKarena: blog post, Scott +1\nScott Rigby: we can communicate to users about how this might affect them - charts have images configurable for helm values\nJoe Julian: Helm users might not be k8s admins and might not know about dockerhub rate limits - pointing it out in documentation might be useful\nScott: even people who use k8s frequently, they might not know where in the supply chain it’s pulled from \nBridget: cya for Helm, not a prob created by Helm\nJoe J: be aware of your rate limits\nJoe 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.\nJoe: “Turns out they do!  https://docs.docker.com/docker-hub/download-rate-limit/#how-can-i-check-my-current-rate”\nAI: Blog post, start a draft next week, volunteers?\n\nAssignments for next meeting\nModerator:   Bridget  \nNotes:    Jasper\nIssue Triage:   Butcher\n\n\nApril 1 2021\nAssignments for this meeting\nModerator:    Adam Reese\nNotes:   Karena Angell\nIssue Triage:   Matt Farina\n\nAnnouncements\n[Martin] Rename of “main” branch\nMostly redirection\nLook at Helm slack channel for details\nGitHub will pop-up info too\nBridget: clean up for others?\nMartin: yes, maintainer by maintainer AI\nMaintainers AI: Update your repos\n[Farina] Archiving of Monocular\nBlog tbd saying ‘use ArtifactHub instead of Monocular’\n[Karena] Contributor Summit on Tuesday! April 6\n\nDiscussion\n[Farina] The --dependency-update flag, it’s docs, and it is not matching its functionality… https://github.com/helm/helm/issues/9545\nCreate documentation that says ‘only updates in this case’\nCreate another flag that updates everything\nClean up in Helm 4\nOnly returns if there are missing dependencies: https://github.com/helm/helm/blob/213a7df2dcd07e8d49fc6acf8a53a540c661ed53/cmd/helm/install.go#L216\nBug since Helm 2.9 or .. ?\nJoe T: deprecate the old flag, define 2 new flags\nFarina: no deprecation cycle, mark for removal in Helm v4\nFarina AI: Document the ticket to remove\n[Marc] HIP-0010: \"Cherry-pick a PR into the release branch right after it is merged into main\"\nMarc AI: add a section for the security patch\n[Farina] chart cache in helm https://github.com/helm/helm/issues/9561 \nIndex.yaml, use digest to go look at cache\nBridget: bandwidth discussion, what gets cached, what doesn’t\nFarina: that was about binaries, so prob no impact\nScott: careful with changes in index.yaml, sounds good\n[Karena] Investigate artifact signing? https://sigstore.dev/what_is_sigstore/\nFarina: provenance files are pgp signed\nFarina AI: Go learn about it\n\nAssignments for next meeting\nModerator:    Marc K \nNotes: Karena A   \nIssue Triage:  Adam and Bridget\n\n\nMarch 25, 2021\nAssignments for this meeting\nModerator:   Martin Hickey\nNotes:  Jasper Chui\nIssue Triage:  Matt Butcher\n\nAnnouncements\n [Bridget] get those bug fixes in!\n3.5.4 will contain only bug fixes and be released on April 14, 2021\nWhen would we like to cut an RC?\n[Farina] No RC for Patch \n3.6.0 is the next feature release and will be released on May 26, 2021\nDepending on k8s release schedule (on track)\nFollowup end of April on release status\nContributor Summit April 6, 2021\nHelm Contributor Summit - Tues Apr 6, 2021\nRegister: https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/  \n[Bridget] Reach out to Karen if you want to register as an organizer\n[Fisher] Need an LF account to register as an organizer\nDiscussion\n [Farina] Archiving Monocular https://github.com/helm/monocular (Web UI for Helm Chart repositories)\nMaintainers are in agreement to archive project\nTarget next week to archive\nReplaced by Artifacthub.io\nDocuments to be updated:\nhttps://helm.sh/docs/community/related/#additional-tools\n[Farina] Hackweek project: How to navigate source code - https://codeengineered.com/blog/2021/helm-vid-series/ \nAssignments for next meeting\nModerator:    Adam Reese\nNotes:   Karena Angell\nIssue Triage:   Matt Farina\n\nMarch 18, 2021\nAssignments for this meeting\nModerator:  Josh D\nNotes:  Bridget K\nIssue Triage: Josh Dolitsky\n\nAnnouncements\n \n \n\nDiscussion\n [Marc] Details of the “needs-pick” process? \nLabel goes on bugs that need to go into a patch release (not a minor)\nWhat if no patch release until minor release?\n[fisher] If there’s no need to cherry-pick, then we remove the “needs-pick” label.\nNot features (features don’t go into patch releases)\nDoes a milestone need to be added/created?\n[fisher] For a patch release, yes.\nWhat query to use? \nis:pr label:needs-pick -label:picked\n[fisher] it looks like a number of PRs need to be triaged in that query.\nButcher: ideally, add “picked” and remove “needs-pick”\nMarc: found some needs-pick and they ended up in a minor release\nButcher: 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\nResolution: Marc will change labels as desired to correct inconsistencies\n\n\n[Simon Croome] - Linter name validation rules: https://github.com/helm/helm/pull/9416  \nSimon: in 3.3.0, change to add name validation\nSimon: PRs in place to try to correct this (inferring from k8s API is challenging - match on object Kind?)\nSimon: hoping to get movement on this as it’s blocking us from doing releases\nButcher: Adam can look at PR\nJosh: can you pool the cases from k8s?\nButcher: API server in k8s does validation after determining if validation is well-formed\nBridget: 3.5.4 will contain only bug fixes and be released on April 14, 2021 - can we get this PR reviewed by then?\nButcher: yes, this goes in bugfix. Josh to look first, then Adam\n\n[Butcher] Helm Contributor Summit - Tues Apr 6, 2021\nRegister: https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/  \n\n[Farina] Dropping support for Go < 1.14 … https://github.com/helm/helm/pull/9355\nFarina: Cobra dropped below 1.14 support\nMarc: confirms that Cobra won’t confirm 1.14 soon but this hasn’t happened yet\nFarina: the only supported Go versions are 1.15 and 1.16\n\nButcher: GitHub had a security alert - we audited and are fine.\n\nJosh: I was doing triage this week - do we have rules around squashing vs merge commits\nFarina: no consistency\nButcher: we had a rule about squashing but haven’t enforced it in at least two years\nJosh: sounds like we don’t have an answer to this?\nDiscussion 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.\n\nAssignments for next meeting\nModerator:   Marc K\nNotes:  Jasper Chui\nIssue Triage:  Matt Butcher\n\n\nMarch 11, 2021\nAssignments for this meeting\nModerator: Josh\nNotes: Karena\nIssue Triage: Butcher\n\nAnnouncements\n[Farina] Helm 3.5.3 released\n3.5.4 will contain only bug fixes and be released on April 14, 2021\n3.6.0 is the next feature release and will be released on May 26, 2021. \n[Bridget] get.helm.sh funding renewed  \n[Butcher & Karen] Helm Contributor Summit - Tues Apr 6, 2021\nRegister: https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/  \n[Bridget] KubeCon EU 2021 Helm content:\nHelm Users! What Flux 2 Can Do For You - Scott Rigby & Kingdon Barrett, Weaveworks \nMainly for Helm-only users\nTaking the Helm: Becoming a Maintainer - Bridget Kromhout & Matt Butcher, Microsoft; Karena Angell, Red Hat; Matt Farina, Rancher Labs \nOffice hours (Karen arranging)\nHelm project pavilion booth (Karen arranging)\n[Farina] Helm 2nd security audit - https://helm.sh/blog/helm-2nd-security-audit/ \nAlso includes threat analysis\n\nDiscussion\n[Adam] Helm examples repo \nhttps://github.com/helm/examples\nCreated a straw man - looking for any help\nBridget: former stable/incubating repo is a good place to start for any docs help\nFarina: let’s use best practices\nScott: volunteering to help / charts team would be good volunteers too\nAI: Scott to start an issue in the repo for brainstorming\nScott: GH Discussions?\nBridget: 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.\n[Bridget] get.helm.sh download metrics: how should we surface them?\nFisher: using verizon cdn, unsure how to pull metrics, maybe could scrape the mgmt portal\nAI: no AI\n[Devdatta Kulkarni] highlighting KubePlus (https://github.com/cloud-ark/kubeplus)\nPresentation: https://github.com/cloud-ark/kubeplus/blob/master/KubePlus-presentation.pdf\nMulti-tenant application stacks\nWrap api around the Helm chart  \nButcher: resourcePolicy sounds like a good idea\nAble to collect consumption metrics now\nMight be interesting to folks from Orkestra (https://github.com/Azure/orkestra)\n[Joe] Issue w storage size for secrets\nFisher: opt in to configmaps, move from 2 to 3\nFisher: talking about alternate storage backends (like mysql)\nhttps://helm.sh/docs/topics/advoanced/#configmap-storage-backend\n\nPostponed to March 18 [Marc] Details of the “needs-pick” process? \nLabel goes on bugs that need to go into a patch release (not a minor)\nWhat if no patch release until minor release?\nNot features (features don’t go into patch releases)\nDoes a milestone need to be added/created?\nWhat query to use? \nis:pr label:needs-pick -label:picked\n\nAssignments for next meeting\nModerator:  Matt Farina\nNotes:  Scott Rigby\nIssue Triage: Josh Dolitsky\n\n\nMarch 4, 2021\nAssignments for this meeting\nModerator: Bridget\nNotes: Butcher\nIssue Triage: Fisher\n\nAnnouncements\n[Bridget] 3.5.3 milestone due March 10, 2021: https://github.com/helm/helm/milestone/107 \nCut-off for the Helm release is tomorrow, Mar 5\nOnly two issues in the milestone, and changes have not been made, so may be removed from release\n[Butcher & Karen] Helm Contributor Summit - Tues Apr 6, 2021\nRegister: https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/  \nWorkshop to help new contributors and those who may want to become maintainers\nTA-style maintainers needed for Q&A during chat \nKubeCon EU: Karen arranging booth and office hours; Bridget arranging recording of contributor-onboarding maintainer session: https://sched.co/iE6C \nOffice hours: Zoom calls at specific times where people can join and chat\nKaren will tell us when it is time to sign up\nKarena, Bridget, and “various Matts” will do a talk\n\nDiscussion\n[Bridget] followup on Brendan’s idea about a Helm label project?\nButcher’s action item was to send info to Farina who was going to talk to sig-apps\nNext SIG-Apps meeting is next Monday\n[Scott & Farina] progress on opening up the functions to the SDK?\nBlocked on OCI experimental flag\nJosh: 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).\n[Karena] Update on CI/CD?\nFarina: Issue is that GitHub actions are pulling Helm fresh each time\nCaching is not as airtight as it should be… no best practices. So we are stalled\nShoubhik will take a look at it. “Is there an issue to look at?”\nFarina: Maybe on www repo?\nBrief discussion on docs for release process https://helm.sh/docs/community/release_checklist/\n\n\nAssignments for next meeting\nModerator: Josh\nNotes: Karena\nIssue Triage: Butcher\n\nFebruary 25, 2021\nAssignments for this meeting\nModerator:  Marc K\nNotes: Scott\nIssue Triage: Matt Farina\n\nAnnouncements\n[Bridget] 3.5.3 milestone due March 10, 2021: https://github.com/helm/helm/milestone/107 \nReview issues/pr and add to milestone as appropriate \nTarget week before (March 3) due date\n\nDiscussion\n[Butcher & Karen] Helm Contributor’s Summit - Tues Apr 6, 2021\nWebsite is live! https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/ \nNeed volunteers to present\nRegistration on the website\nSingle track. See Agenda on website\nOne goal of this is to help those contributors who may eventually become maintainers\nPlan 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\"\nNo cost for attending the event\n[Farina] How much of this covers parts of the Helm project that aren't helm/helm (chartmuseum, chart-releaser, etc)\n[Butcher] mainly focused on Helm org, community repo, documentation, and helm/helm (the biggest process load)\nNeed more maintainers to help organize\n[Scott] happy to help with various things, including charts and tooling related repos\n\n\n[Butcher] Brendan’s idea about a Helm label project\nk8s in general is trying to come up with more labels, but no org happy to take that on\nBrendan thought, since Helm is how most people organize their manifests, could Helm help canonicalize this?\nButcher talked with a few people already, but this would be the forum\nFarina: if it's not documented somewhere, I think that would be great\nexample \"icon\" - no standard label for application icon yet\nFarina (re SIG Apps): would this be better to expand in k8s common labels there, or here?\n[Joe J] was thinking SIG Apps so that it can be used in other projects e.g. kudo \nFarina will take this to SIG Apps to see if that is the right place. If not will bring it back to here\n[Fisher] if it comes back to here, a HIP is a good way to go\n[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\n[Scott] What steps are needed to open up the functions to the SDK\ngetter is already open\none thing that would help open up is the registry client currently in internal package in helm \nScott: Yes we have semver contracts and don’t want to screw those up - but what do we need to get the OCI support finished?\nFarina in same boat. but 2 things would like to have before we make public\n1. APIs solidified. Not sure if done, must talk w Josh\n2. doesn't want to use logrus as a dependency because they're not in maintenance mode. Ideally would not like to pull this in\n3. Really like to see ORAS repo (https://github.com/deislabs/oras) moved out of deislabs and into its own org\nFisher OCI is still considered a draft.\nScott: can we keep the experimental flag but also make functions avail to SDK?\nFisher: some things (like catalog items) changing over time - if stable, we won’t break compatibility\nScott: hmmm.. Own package/repo for versioning?\nFarina: Scott, do you have time? Action item: Farina and Scott to connect and write a plan.\n\n\nAssignments for next meeting\nModerator: Bridget\nNotes: Butcher\nIssue Triage: Fisher\n\nFebruary 18, 2021\nAssignments for this meeting\nModerator:  Scott\nNotes: Jasper\nIssue Triage: Matt Farina\n\nAnnouncements\n[Bridget] 3.5.3 milestone due March 10, 2021: https://github.com/helm/helm/milestone/107 \nReview issues/pr and add to milestone as appropriate \nTarget week before (March 3) due date\n\nDiscussion\n[Marc] HIP for a distributed pick process https://github.com/helm/community/pull/172 \nProcess for Patch release identify needs-pick labelled items to include\nPerson approves into master also responsible for including in release branch\n[Farina] What would be the process to handle a security release?\nCreate a separate branch for Security Release based on previous release\nDoes this work for the two recent security releases?\nDiscuss proposal on how to handle releases and branches under different scenarios\nMerge back commits from hot fix branch back to master\nLooking for reviewers and feedback\n[Marc] HIP for descriptions for custom completions https://github.com/helm/community/pull/161 \nCobra has improved handling auto complete\nWhere does the description come from?\nPulls from various sources\nLooking for reviewers and feedback\nScott: I'll look closer from a charts end user POV \n[Bridget] good first issue label - can we revisit this one? https://github.com/helm/helm/labels/good%20first%20issue is very stale\nLooking for additional issues that could be labelled with “good first issue”\n\nAssignments for next meeting\nModerator: Marc K\nNotes: Scott\nIssue Triage: Matt Farina\n\nFebruary 11, 2021\nAssignments for this meeting\nModerator:  Bridget\nNotes: Karena\nIssue Triage: Matt Butcher\n\nAnnouncements\nArtifact Hub: Values Schema Reference  [Farina] https://blog.artifacthub.io/blog/helm-values-schema-reference/ \nDiscussion\nWhen a release fails to update (after the upgrade of Kubernetes manifests) should we display a message or return an error [Farina]\nInconsistent between Install and Upgrade/rollback\nOn Install we display a message to debug log\nComment in action install says…\n// This is a tricky case. The release has been created, but the result\n// cannot be recorded. The truest thing to tell the user is that the\n// release was created. However, the user will not be able to do anything\n// further with this release.\n//\n// One possible strategy would be to do a timed retry to see if we can get\n// this stored in the future.\nOn upgrade/rollback we return an error\nIt will upgrade all the k8s assets, doesn’t actually store the secret \n[M Butcher] Failure of etcd to store something \nIf recorded, will show installing\n[Farina] Just return a non 0 exit code\nhttps://github.com/helm/helm/pull/9131 is looking to add a case where another error could be returned on upgrade/rollback\n[Scott] should this be a bugfix?\nGitHub Discussions [Farina]\nDisabling github discussions: https://github.com/dotnet/aspnetcore/issues/29935\n[Bridget] What happens to existing discussions?\n[Scott] Will test \nDiscussions last longer than issues\nHomebrew is using discussions\n[M Butcher] Is GH Discussions basically “Stack Overflow by GitHub”\n[Bridget] yes, but don't have the management granularity, would it make it harder for ourselves?\n[Scott] has default categories, can change categories at any point\nThreaded answers, user or maintainer can select the correct answer\n[Josh/Bridget] more things to check / more work for the community/maintainers?\n[Farina] Will send to helm mailing list and other maintainers, revisit in a week or two.\nBetter CI practices [Farina & Butcher]\nCosts a lot for downloads every month\nExample: homebrew ~ $25k/mo\nDocument best practices\n[Scott] GH actions have artifacts, will look into also look into caching across jobs\n[Bridget] define how to be more prescriptive\nTO DO: “CI Best Practices” on helm docs\nQuestion about CRDs during helm upgrade [Scott]\nIf a CRD exists we don’t try to apply it - but what about updates?\nCould we have a similar functionality on “helm upgrade” to what we have on “helm install”?\nRead: https://github.com/helm/community/blob/f9e06c16d89ccea1bea77c01a6a96ae3b309f823/architecture/crds.md\nExplains pitfalls of handling crd’s\nFarina has opinions :)\n\nAssignments for next meeting\nModerator: Scott\nNotes: Jasper\nIssue Triage: Farina\n\nFebruary 4, 2021\nAssignments for this meeting\nModerator:  Adam Reese\nNotes: Jasper Chui\nIssue Triage: Matt Farina   \n\nAnnouncements\nChartMuseum v0.13.0 released today (currently in progress..)\nFollows Helm’s release process: same artifact store (get.helm.sh), installer script, release notes, signatures, etc.\nDocker image on GitHub Container Registry\n\nDiscussion\nCancelling patch release of Feb 10th? (4 weeks after 3.5.0) [Marc]\npolicy https://helm.sh/docs/topics/release_policy/#patch-releases \nShould this be cancelled per policy\n[Butcher] Security team scheduled release today so it makes sense to cancel patch release\nNext patch will be in March\nPatches in current release will be bumped to 3.5.3\nHIP for a distributed pick process https://github.com/helm/community/pull/172 [Marc]\nPlease review, if approved will impact all maintainers \nRecent intermittent CircleCI failures - perhaps we need to consider changes to the build pipeline? [Bridget]\n[Butcher] Security issue was found and should be fixed today\nChart releaser action docs update? https://github.com/helm/helm-www/pull/928 [Bridget]\nScott says circle back\n[Scott] Reviewed and will leave suggestions for owner to review\nCreating a 4.0 milestone? [Marc]\n4.0 should be delayed as long as possible but good to have community to start tracking\n[Butcher] Milestone 3.0 was opened a year before so good to do the same for 4.0\n[Bridget] Label already exists for 4.0 https://github.com/helm/helm/labels/v4.x \nLabel is sufficient to track 4.0 work\n--hide-secrets https://github.com/helm/helm/pull/9130 Discussion on the state of the PR [Shoubhik]\nDoes not work for template but works for Helm Install\n[Adam] Important for this to work with templates\nQuick update on planning the contributor summit [Butcher]\nTopics: How to contribute to project, How to become core maintainer \nCurriculum in progress (Butcher, Bridget, Karen)\nTalk to CNCF to determine timeframe for sessions\nTalk to this (Bridget, Karen, Butcher)  if you are interested in presenting, working on curriculum\n\nAssignments for next meeting\nModerator: Scott\nNotes:  Bridget\nIssue Triage:  Butcher\n\nJanuary 28, 2021\nAssignments for this meeting\nModerator: Bridget\nNotes:  Jasper\nIssue Triage: Josh Dolitsky\n\nAnnouncements\n3.5.1 milestone in progress\nRebuild of 3.5.0 with new version of Go (today) with security updates\nNo other patches\nPatches and updates will become 3.5.2\nLearning Helm [written by Matts and Josh]\nCovers introduction and how to use it\nCommands of Helm\nPosition within CNCF\nCharts\nRegistries and plugin\nAppendix on differences between v2 and v3\nTo be published soon\n\nDiscussion\nStorage improvement brainstorming [Joe Julian] https://github.com/stedolan/jq/issues/2257\nConfig and secrets can be very large\nHelm v3: limits to history of 10 items\nException if its failing: capture failure log\nHelm used to use Config maps, want Helm to be usable out of box\nUsed secrets as it is simple and just works\nAlternative (CRD) may require additional permissions \nAlternative postgres \nLooking for alternatives that could fit requirement to be used out of box\nEtcd pulls entire dataset\nSplit secrets into two parts\nSplit manifest into its own object (separate namespace)\nConfig: helm release, secret: metadata\nWhere would Values go?\nSecrets stored in secrets (can be referenced)\n[Igor] Confirm that we are trying to simplify how to store runtime data?\nAlternatives: postgres service, sqllite, aggregated api server\n[Matt] Enterprise wanted simpler format\n[Matt] different than programming locally\nHelm is a package manager (need to keep this space)\nNeed higher level tool to manage complexity (ansible, chef, flux helm operator)\nNeed to make sure when we scale up we handle the simpler case and need to reduce complexity for easy\nSimple case easy to use with Helm, don’t want to optimize for the complex case\n[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.\nJoe to open an issue to continue the conversation to determine next step (HIP or PR)\nTest 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]\nin https://app.circleci.com/pipelines/github/helm/helm/2106/workflows/fad17fdc-61dd-4558-9704-b6d930568cc6/jobs/13653 \n--- FAIL: TestSearchRepositoriesCmd/search_for_'maria',_expect_one_match_with_semver_begin_with_zero_development_version (0.00s) \nhelm_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\n[Fisher] just a test fluke - never seen it before. Likely just a rebase error. Re-running the test suite passed.\n\n\nHiding secrets - is this a blocker we should resolve quickly? [Bridget] https://github.com/helm/helm/pull/9130 \n[Farina] Should hide secrets in log\nShould this be in next release as low hanging fruit\n[Farina] Should look into this issue\n[Shoubhik] Can take a look into this issue : Done\n[Scott] fun question: what blockers would we have to revisit the idea of installing missing CRDs from the /crds dir at the version level\n[Farina] What do you mean by version level? CRD capture all version info in each CRD\nCreating a 4.0 milestone to track any feature needing a major release [Marc]\n(but we should avoid a 4.0 as long as possible in my opinion)\n[Shoubhik] Should not signify that its coming\n[Farina] There could be a mismatch\n[Bridget] Stick with milestone 4.0\n[Karena] Charts Chat - is that still active, I have a standing conflict and the notes doc was last updated in 2019\nIs this still happening?\n[Farina] Should be cancelled. Meeting has not been held since 2019.\n[Farina] Meeting has been cancelled.\n[Karena] If people still need help with Charts should they be directed to this meeting?\nDirect to charts channel in community slack\n[Farina] Topics has been covered in this meeting or directly in issues\n\nAssignments for next meeting\nModerator:  Adam Reese\nNotes: Karena\nIssue Triage: Matt Farina   \n\n\nJanuary 21, 2021\nAssignments for this meeting\nModerator: Matt Farina\nNotes:  Karena  \nIssue Triage: Matt Butcher\n\nAnnouncements\nNone this week\n\nDiscussion\n3.5.1- https://github.com/helm/helm/milestone/107 \nPatch fix milestone\nUpdating kube libraries for 1.20.2\nMaintainer doesn’t have to do the upgrades for the libraries\nUsually aren’t breaking\nVolunteer? Shoubhik will attempt\nIf need to release Go security patch, 3.5.1 will only the security patch and 3.5.2 will be the rest\nPerformance improvements [Farina]\nIndex.yaml updates\nPreviously, 8mb yaml file - slow to parse\nJson so much faster to parse, both in memory and operations\nIndex.json to cut down on processing time (vs index.yaml)\n[Matt Fisher] Redirect? (might be a breaking change)\nFarina: perhaps a start - look at what’s on artifact hub. Explore further.\nHelm repositories with Git [Igor]\nSuggestion: parse tar balls on the fly - grab directly from git\n[Igor] Example: https://github.com/otaviof/chart-streams\n[Bridget] GitHub pages example: https://helm.sh/docs/topics/chart_repository/#github-pages-example\n[Farina] Helm is meant to be simple and like seeing people using the API\n[Matt Fisher] there’s a section in documentation to point to projects\nNice that it demonstrates the chart repository api\n[Bridget] here is where you can PR in a link: https://github.com/helm/helm-www/blob/master/content/en/docs/community/related.md\n[Josh Dolitsky] Similar, but using plugin vs. http(s): https://github.com/aslafy-z/helm-git\nStorage improvement brainstorming [Joe Julian - deferring a week]\n\nAssignments for next meeting\nModerator: Bridget\nNotes:  Jasper\nIssue Triage: Josh Dolitsky\n\nJanuary 14, 2021\nAssignments for this meeting\nModerator:     Marc K\nNotes:  Bridget  \nIssue Triage:  Shoubhik, tbd\n\nAnnouncements\n3.5.0 released [Farina] - https://github.com/helm/helm/releases/tag/v3.5.0 \nBridget to coordinate a blog post; Farina to review\n3.5.1 milestone: https://github.com/helm/helm/milestone/107 (second Wed in Feb)\nDate for next minor release [Marc]\n3.6 RC1: Monday May 17th, 2021\n3.6 final release: Wednesday May 26th, 2021\nMarc to update calendar\n Helm plugins in Artifact Hub [Farina]\n(for example, https://artifacthub.io/packages/helm-plugin/helm-2to3/2to3) \nList and search - artifact hub is like a search engine\nTo do: add this to helm docs\n\n\nDiscussion\nDependabot recommendations (https://github.com/helm/helm/pulls/app%2Fdependabot) - what action do we want to take? [Bridget]\nbump k8s.io/[various] from 0.20.1 to 0.20.2\nhttps://github.com/stretchr/testify update\nOlder containerd issue\nFarina: we shouldn’t do the k8s ones through dependabot - we should do these - cherry-pick into 3.5.1\nBut the containerd one is a tough one - a transitive dependency we need to update - we ideally would prefer ORAS to update this\nThe testify one could probably be merged & marked as needs-pick - may work best for 3.6 not 3.5.x\nPicks for patches [Farina]\nMarking “needs pick” and then picking them - not a long period of sitting in the branch\nMore difficult if the main branch has diverged far from the release branch\nIdeally, whoever merges marks as needs pick and pushes to release branch - would make patch releases quicker\nMarc: we could move this towards a “make release” if this were made more consistent\nButcher: now that we do releases more consistently, we can pick onto the branch sooner rather than later\nMarc: how about a process HIP to document this? (willing to write it but others can help)\nPlugin discussion for artifact hub [Butcher]\nButcher: Might we want “helm plugin search”?\nFarina: artifact hub is API driven so external tools are entirely possible\nButcher: we could do this as a feature HIP\nBucket redirections [Butcher]\nFarina: no problem thus far\nKubeCon video [Bridget]\nShould be a sea shanty\nHelm 4 wishlist\nDate formatting [issues open already] [Bridget]\nStorage - too large of release storage objects bring kubernetes api to its knees [Joe Julian]\nFarina: we should iterate on this in an experimental fashion in v3\nCould do a tool to migrate from secrets to postgres\nContext-specific storage options instead of env variables\nJoe Julian: also we read all the secrets to get metadata but just need the metadata itself\nJoe Thompson: 1meg request limit also is an issue\nIgor Sutton Lopes: can we use something other than etcd?\nFarina: we can’t assume people can install anywhere other than their clusters\nIgor: alternative backends for storage - discussion for next week\nFarina: with secrets we have encryption, so we have to consider that and not just push secrets to git - could be opt-in\n\nAssignments for next meeting\nModerator:  Farina\nNotes:   Karena\nIssue Triage:  Butcher\n\n\nJanuary 7, 2021\nAssignments for this meeting\nModerator: Bridget   \nNotes: Karena \nIssue Triage: Farina/Josh/Shoubhik  \n\nAnnouncements\n3.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.\n\nDiscussion\nWe must select the date for the next minor release [Marc]\nMove discussion to the mailing list for consensus?\n[Farina] april 19-23 is release week, suggesting May 12, first week after KubeCon Europe (virtual)\nTentative date: \nBig risk - any changes from kube release\nWant to make sure follow a quarterly release cadence\n[marc, farina] suggesting follow new kube release schedule - 3 x’s a year\n[farina] suggesting May 26, rc1 would be May 17\n[marc] to send email to maintainer list\n[shoubhik] how to check api changes?\nCheck docs, not easy question\n[bridget] would you like to check api questions that may affect helm?\n[farina] any k8s go api changes could break anything for helm\nTracking changes may be more work than just fixing what’s breaking\nWhen should a patch release be cancelled? [Marc]\nhttps://github.com/helm/community/issues/160\nFinal point to finish HIP2 (Pre-defined release dates for Helm) https://github.com/helm/community/blob/master/hips/hip-0002.md\n[fisher] justification to cancel a patch release?\n[farina] canceled patch release because minor release (superseded)\n[fisher] patch release == low severity bugs that affect the smallest number of users\n[bridget] if within x days, judgement call\nIf within 7 days, wait for minor release to save time for release managers\nNeeds more discussion\nAsset 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]\n Asset Transparency project\n[butcher] if generally in favor, would like to get merged\nPlease look at and comment so decision can be made w/i the next week\nContributor Workshop\n[bridget] working w CNCF to schedule the workshop\n[Butcher] 2-block format\n1 - Non-maintainer\n2 - People who are interested in becoming a core maintainer\nKaren has already reached out to people who have done this before\nTimeline: Late first quarter, early second quarter\nWho wants to volunteer from core maintainers for Kube preso?\nMartin?\nBridget will coordinate \n\nAssignments for next meeting\nModerator: Marc\nNotes: Josh \nIssue Triage: Shoubhik (non-maintainer issues), tbd\n```\n"
  },
  {
    "path": "community/meeting-notes/index.mdx",
    "content": "---\ntitle: Archived Meeting Notes\n---\n\nHere are all of the archived Helm meeting notes prior to 2022. They are retained here for historical purposes.\n\nFor current Helm dev meeting agenda and notes, see [this Google Doc](https://docs.google.com/document/d/1d-6xJEx0C78csIYSPKJzRPeWaHG_8W1Hjl72OJggwdc/edit?usp=sharing).\n\nimport DocCardList from \"@theme/DocCardList\";\n\n<DocCardList />\n"
  },
  {
    "path": "community/related.md",
    "content": "---\ntitle: Related Projects and Documentation\ndescription: third-party tools, plugins and documentation provided by the community!\nsidebar_position: 4\n---\n\nThe Helm community has produced many extra tools, plugins, and documentation\nabout Helm. We love to hear about these projects.\n\nIf you have anything you'd like to add to this list, please open an\n[issue](https://github.com/helm/helm-www/issues) or [pull\nrequest](https://github.com/helm/helm-www/pulls).\n\n## Helm Plugins {#helm-plugins}\n\n- [helm-adopt](https://github.com/HamzaZo/helm-adopt) - A helm v3 plugin to adopt\n  existing k8s resources into a new generated helm chart.\n- [helm-cel](https://github.com/idsulik/helm-cel) - Plugin that uses Common Expression Language (CEL) to validate values.\n- [helm-chartsnap](https://github.com/jlandowner/helm-chartsnap) - Snapshot testing plugin for Helm charts.\n- [Helm Diff](https://github.com/databus23/helm-diff) - Preview `helm upgrade`\n  as a coloured diff\n- [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\n- [Helm Dashboard](https://github.com/komodorio/helm-dashboard) - GUI for Helm, visualize releases and repositories, manifest diffs\n- [helm-gcs](https://github.com/hayorov/helm-gcs) - Plugin to manage repositories\n  on Google Cloud Storage\n- [helm-git](https://github.com/aslafy-z/helm-git) - Install charts and retrieve\n  values files from your Git repositories\n- [helm-k8comp](https://github.com/cststack/k8comp) - Plugin to create Helm\n  Charts from hiera using k8comp\n- [helm-mapkubeapis](https://github.com/helm/helm-mapkubeapis) - Update helm release\n  metadata to replace deprecated or removed Kubernetes APIs\n- [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`\n- [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - Plugin to\n  monitor a release and rollback based on Prometheus/ElasticSearch query\n- [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.\n- [helm-s3](https://github.com/hypnoglow/helm-s3) - Helm plugin that allows to\n  use AWS S3 as a [private] chart repository\n- [helm-secrets](https://github.com/jkroepke/helm-secrets) - Plugin to manage\n  and store secrets safely (based on [sops](https://github.com/mozilla/sops))\n- [helm-sigstore](https://github.com/sigstore/helm-sigstore) -\n  Plugin for Helm to integrate the [sigstore](https://sigstore.dev/) ecosystem. Search, upload and verify signed Helm charts.\n- [helm-tanka](https://github.com/Duologic/helm-tanka) - A Helm plugin for\n  rendering Tanka/Jsonnet inside Helm charts.\n- [hc-unit](https://github.com/xchapter7x/hcunit) - Plugin for unit testing\n  charts locally using OPA (Open Policy Agent) & Rego\n- [helm-unittest](https://github.com/helm-unittest/helm-unittest) - Plugin for unit\n  testing chart locally with YAML\n- [helm-val](https://github.com/HamzaZo/helm-val) - A plugin to get\n  values from a previous release.\n- [helm-external-val](https://github.com/kuuji/helm-external-val) - A plugin that fetches helm values from external sources (configMaps, Secrets, etc.)\n- [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\n- [helm-drift](https://github.com/nikhilsbhat/helm-drift) - Helm plugin that identifies the configuration that has drifted from the Helm chart\n- [helm-tui](https://github.com/pidanou/helm-tui) - A light UI to manage your Helm assets without leaving the terminal\n\nWe also encourage GitHub authors to use the\n[helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)\ntag on their plugin repositories.\n\n## Additional Tools\n\nTools layered on top of Helm.\n\n- [Aptakube](https://aptakube.com) - Desktop UI for Kubernetes and Helm Releases\n- [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) - Manage\n  prefixed releases throughout various Kubernetes namespaces, and removes\n  completed jobs for complex deployments\n- [avionix](https://github.com/zbrookle/avionix) -\n  Python interface for generating Helm\n  charts and Kubernetes yaml, allowing for inheritance and less duplication of code\n- [Botkube](https://botkube.io) - Run Helm commands directly from Slack,\n  Discord, Microsoft Teams, and Mattermost.\n- [Captain](https://github.com/alauda/captain) - A Helm3 Controller using\n  HelmRequest and Release CRD\n- [Chartify](https://github.com/appscode/chartify) - Generate Helm charts from\n  existing Kubernetes resources.\n- [ChartMuseum](https://github.com/helm/chartmuseum) - Helm Chart Repository\n  with support for Amazon S3 and Google Cloud Storage\n- [chart-registry](https://github.com/hangyan/chart-registry) - Helm Charts\n  Hosts on OCI Registry\n- [Codefresh](https://codefresh.io) - Kubernetes native CI/CD and management\n  platform with UI dashboards for managing Helm charts and releases\n- ⁠[Cyclops](https://cyclops-ui.com) - Dynamic Kubernetes UI rendering based\n  on Helm charts\n- [Flux](https://fluxcd.io/docs/components/helm/) -\n  Continuous and progressive delivery from Git to Kubernetes.\n- [Helmfile](https://github.com/helmfile/helmfile) - Helmfile is a declarative\n  spec for deploying helm charts\n- [Helmper](https://github.com/ChristofferNissen/helmper) - Helmper helps you\n  import Helm Charts - including all OCI artifacts(images), to your own OCI\n  registries. Helmper also facilitates security scanning and patching of OCI\n  images. Helmper utilizes Helm, Oras, Trivy, Copacetic and Buildkitd.\n- [Helmsman](https://github.com/Praqma/helmsman) - Helmsman is a\n  helm-charts-as-code tool which enables\n  installing/upgrading/protecting/moving/deleting releases from version\n  controlled desired state files (described in a simple TOML format)\n- [HULL](https://github.com/vidispine/hull) - This library chart provides a\n  ready-to-use interface for specifying all Kubernetes objects directly in the `values.yaml`.\n  It removes the need to write any templates for your charts and comes with many\n  additional features to simplify Helm chart creation and usage.\n- [K8Studio](https://k8studio.io) -\n  Desktop UI for Managing Kubernetes Clusters with Integrated Helm Manager.\n- [Konveyor Move2Kube](https://konveyor.io/move2kube/) -\n  Generate Helm charts for your\n  existing projects.\n- [Landscaper](https://github.com/Eneco/landscaper/) - \"Landscaper takes a set\n  of Helm Chart references with values (a desired state), and realizes this in a\n  Kubernetes cluster.\"\n- [Monocular](https://github.com/helm/monocular) - Web UI for Helm Chart\n  repositories\n- [Monokle](https://monokle.io) - Desktop tool for creating, debugging and deploying Kubernetes resources and Helm Charts\n- [Orkestra](https://azure.github.io/orkestra/) - A cloud-native Release\n  Orchestration and Lifecycle Management (LCM) platform for a related group of\n  Helm releases and their subcharts\n- [Tanka](https://tanka.dev/helm) - Grafana Tanka configures Kubernetes\n  resources through Jsonnet with the ability to consume Helm Charts\n- [Terraform Helm\n  Provider](https://github.com/hashicorp/terraform-provider-helm) - The Helm\n  provider for HashiCorp Terraform enables lifecycle management of Helm Charts\n  with a declarative infrastructure-as-code syntax.  The Helm provider is often\n  paired the other Terraform providers, like the Kubernetes provider, to create\n  a common workflow across all infrastructure services.\n- [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - VIM plugin\n  for Kubernetes and Helm\n\n## Helm Included\n\nPlatforms, distributions, and services that include Helm support.\n\n- [Kubernetic](https://kubernetic.com/) - Kubernetes Desktop Client\n- [Jenkins X](https://jenkins-x.io/) - open source automated CI/CD for\n  Kubernetes which uses Helm for\n  [promoting](https://jenkins-x.io/docs/getting-started/promotion/) applications\n  through environments via GitOps\n\n## Misc\n\nGrab bag of useful things for Chart authors and Helm users.\n\n- [Await](https://github.com/saltside/await) - Docker image to \"await\" different\n  conditions--especially useful for init containers. [More\n  Info](https://blog.slashdeploy.com/2017/02/16/introducing-await/)\n"
  },
  {
    "path": "community/release_checklist.md",
    "content": "---\ntitle: Maintainer Release Checklist\ndescription: Checklist for maintainers when releasing the next version of Helm.\n---\n\n# A Maintainer's Guide to Releasing Helm\n\nTime for a new Helm release! As a Helm maintainer cutting a release, you are\nthe best person to update this\nrelease checklist\nshould your experiences vary from what's documented here.\n\nAll releases will be of the form vX.Y.Z where X is the major version number, Y\nis the minor version number and Z is the patch release number. This project\nstrictly follows [semantic versioning](https://semver.org/) so following this\nstep is critical.\n\nHelm announces in advance the date of its next minor release. Every effort\nshould be made to respect the announced date.  Furthermore, when starting\nthe release process, the date for the next release should have been selected\nas it will be used in the release process.\n\nThese directions will cover initial configuration followed by the release\nprocess for three different kinds of releases:\n\n* Major Releases - released less frequently - have breaking changes\n* Minor Releases - released every 3 to 4 months - no breaking changes\n* Patch Releases - released monthly - do not require all steps in this guide\n\n[Initial Configuration](#initial-configuration)\n\n1. [Create the Release Branch](#1-create-the-release-branch)\n2. [Major/Minor releases: Change the Version Number in Git](#2-majorminor-releases-change-the-version-number-in-git)\n3. [Major/Minor releases: Commit and Push the Release Branch](#3-majorminor-releases-commit-and-push-the-release-branch)\n4. [Major/Minor releases: Create a Release Candidate](#4-majorminor-releases-create-a-release-candidate)\n5. [Major/Minor releases: Iterate on Successive Release Candidates](#5-majorminor-releases-iterate-on-successive-release-candidates)\n6. [Finalize the Release](#6-finalize-the-release)\n7. [Write the Release Notes](#7-write-the-release-notes)\n8. [PGP Sign the downloads](#8-pgp-sign-the-downloads)\n9. [Publish Release](#9-publish-release)\n10. [Update Docs](#10-update-docs)\n11. [Tell the Community](#11-tell-the-community)\n\n## Initial Configuration\n\n### Set Up Git Remote\n\nIt is important to note that this document assumes that the git remote in your\nrepository that corresponds to <https://github.com/helm/helm> is named\n\"upstream\". If yours is not (for example, if you've chosen to name it \"origin\"\nor something similar instead), be sure to adjust the listed snippets for your\nlocal environment accordingly. If you are not sure what your upstream remote is\nnamed, use a command like `git remote -v` to find out.\n\nIf you don't have an [upstream\nremote](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork)\n, you can add one using something like:\n\n```shell\ngit remote add upstream git@github.com:helm/helm.git\n```\n\n### Set Up Environment Variables\n\nIn this doc, we are going to reference a few environment variables as well,\nwhich you may want to set for convenience. For major/minor releases, use the\nfollowing:\n\n```shell\nexport RELEASE_NAME=vX.Y.0\nexport RELEASE_BRANCH_NAME=\"release-X.Y\"\nexport RELEASE_CANDIDATE_NAME=\"$RELEASE_NAME-rc.1\"\n```\n\nIf you are creating a patch release, use the following instead:\n\n```shell\nexport PREVIOUS_PATCH_RELEASE=vX.Y.Z\nexport RELEASE_NAME=vX.Y.Z+1\nexport RELEASE_BRANCH_NAME=\"release-X.Y\"\n```\n\n### Set Up Signing Key\n\nWe are also going to be adding security and verification of the release process\nby hashing the binaries and providing signature files. We perform this using\n[GitHub and\nGPG](https://help.github.com/en/articles/about-commit-signature-verification).\nIf you do not have GPG already setup you can follow these steps:\n\n1. [Install GPG](https://gnupg.org/index.html)\n2. [Generate GPG\n   key](https://help.github.com/en/articles/generating-a-new-gpg-key)\n3. [Add key to GitHub\n   account](https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account)\n4. [Set signing key in\n   Git](https://help.github.com/en/articles/telling-git-about-your-signing-key)\n\nOnce you have a signing key you need to add it to the KEYS file at the root of\nthe repository. The instructions for adding it to the KEYS file are in the file.\nIf you have not done so already, you need to add your public key to the\nkeyserver network. If you use GnuPG you can follow the [instructions provided by\nDebian](https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver).\n\n## 1. Create the Release Branch\n\n### Major/Minor Releases\n\nMajor releases are for new feature additions and behavioral changes *that break\nbackwards compatibility*. Minor releases are for new feature additions that do\nnot break backwards compatibility. To create a major or minor release, start by\ncreating a `release-X.Y` branch from main.\n\n```shell\ngit fetch upstream\ngit checkout upstream/main\ngit checkout -b $RELEASE_BRANCH_NAME\n```\n\nThis new branch is going to be the base for the release, which we are going to\niterate upon later.\n\nVerify that a [helm/helm milestone](https://github.com/helm/helm/milestones)\nfor the release exists on GitHub (creating it if necessary). Make sure PRs and\nissues for this release are in this milestone.\n\nFor major & minor releases, move on to step 2: [Major/Minor releases: Change\nthe Version Number in Git](#2-majorminor-releases-change-the-version-number-in-git).\n\n### Patch releases\n\nPatch releases are a few critical cherry-picked fixes to existing releases.\nStart by creating a `release-X.Y` branch:\n\n```shell\ngit fetch upstream\ngit checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME\n```\n\nFrom here, we can cherry-pick the commits we want to bring into the patch\nrelease:\n\n```shell\n# get the commits ids we want to cherry-pick\ngit log --oneline\n# cherry-pick the commits starting from the oldest one, without including merge commits\ngit cherry-pick -x <commit-id>\n```\n\nAfter the commits have been cherry picked the release branch needs to be pushed.\n\n```shell\ngit push upstream $RELEASE_BRANCH_NAME\n```\n\nPushing the branch will cause the tests to run. Make sure they pass prior to\ncreating the tag. This new tag is going to be the base for the patch release.\n\nCreating a [helm/helm\nmilestone](https://github.com/helm/helm/milestones) is optional for patch\nreleases.\n\nMake sure to check [GitHub Actions](https://github.com/helm/helm/actions) to see\nthat the release passed CI before proceeding. Patch releases can skip steps 2-5\nand proceed to step 6 to [Finalize the Release](#6-finalize-the-release).\n\n## 2. Major/Minor releases: Change the Version Number in Git\n\nWhen doing a major or minor release, make sure to update\n`internal/version/version.go` with the new release version.\n\n```shell\n$ git diff internal/version/version.go\ndiff --git a/internal/version/version.go b/internal/version/version.go\nindex 712aae64..c1ed191e 100644\n--- a/internal/version/version.go\n+++ b/internal/version/version.go\n@@ -30,7 +30,7 @@ var (\n        // Increment major number for new feature additions and behavioral changes.\n        // Increment minor number for bug fixes and performance enhancements.\n        // Increment patch number for critical fixes to existing releases.\n-       version = \"v3.3\"\n+       version = \"v3.4\"\n\n        // metadata is extra build time data\n        metadata = \"\"\n```\n\nIn addition to updating the version within the `version.go` file, you will also\nneed to update corresponding tests that are using that version number.\n\n* `cmd/helm/testdata/output/version.txt`\n* `cmd/helm/testdata/output/version-client.txt`\n* `cmd/helm/testdata/output/version-client-shorthand.txt`\n* `cmd/helm/testdata/output/version-short.txt`\n* `cmd/helm/testdata/output/version-template.txt`\n* `pkg/chartutil/capabilities_test.go`\n\n```shell\ngit add .\ngit commit -m \"bump version to $RELEASE_NAME\"\n```\n\nThis will update it for the $RELEASE_BRANCH_NAME only. You will also need to\npull this change into the main branch for when the next release is being\ncreated, as in [this example of 3.2 to\n3.3](https://github.com/helm/helm/pull/8411/files), and add it to the milestone\nfor the next release.\n\n```shell\n# get the last commit id i.e. commit to bump the version\ngit log --format=\"%H\" -n 1\n\n# create new branch off main\ngit checkout main\ngit checkout -b bump-version-<release_version>\n\n# cherry pick the commit using id from first command\ngit cherry-pick -x <commit-id>\n\n# commit the change\ngit push origin bump-version-<release-version>\n```\n\n## 3. Major/Minor releases: Commit and Push the Release Branch\n\nIn order for others to start testing, we can now push the release branch\nupstream and start the test process.\n\n```shell\ngit push upstream $RELEASE_BRANCH_NAME\n```\n\nMake sure to check [GitHub Actions](https://github.com/helm/helm/actions) to see\nthat the release passed CI before proceeding.\n\nIf anyone is available, let others peer-review the branch before continuing to\nensure that all the proper changes have been made and all of the commits for the\nrelease are there.\n\n## 4. Major/Minor releases: Create a Release Candidate\n\nNow that the release branch is out and ready, it is time to start creating and\niterating on release candidates.\n\n```shell\ngit tag --sign --annotate \"${RELEASE_CANDIDATE_NAME}\" --message \"Helm release ${RELEASE_CANDIDATE_NAME}\"\ngit push upstream $RELEASE_CANDIDATE_NAME\n```\n\nGitHub Actions will automatically create a tagged release image and client binary to\ntest with.\n\nFor testers, the process to start testing after GitHub Actions finishes building the\nartifacts involves the following steps to grab the client:\n\nlinux/amd64, using /bin/bash:\n\n```shell\nwget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz\n```\n\ndarwin/amd64, using Terminal.app:\n\n```shell\nwget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz\n```\n\nwindows/amd64, using PowerShell:\n\n```shell\nPS C:\\> Invoke-WebRequest -Uri \"https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz\" -OutFile \"helm-$ReleaseCandidateName-windows-amd64.tar.gz\"\n```\n\nThen, unpack and move the binary to somewhere on your $PATH, or move it\nsomewhere and add it to your $PATH (e.g. /usr/local/bin/helm for linux/macOS,\nC:\\Program Files\\helm\\helm.exe for Windows).\n\n## 5. Major/Minor releases: Iterate on Successive Release Candidates\n\nSpend several days explicitly investing time and resources to try and break helm\nin every possible way, documenting any findings pertinent to the release. This\ntime should be spent testing and finding ways in which the release might have\ncaused various features or upgrade environments to have issues, not coding.\nDuring this time, the release is in code freeze, and any additional code changes\nwill be pushed out to the next release.\n\nDuring this phase, the $RELEASE_BRANCH_NAME branch will keep evolving as you\nwill produce new release candidates. The frequency of new candidates is up to\nthe release manager: use your best judgement taking into account the severity of\nreported issues, testers' availability, and the release deadline date. Generally\nspeaking, it is better to let a release roll over the deadline than to ship a\nbroken release.\n\nEach time you'll want to produce a new release candidate, you will start by\nadding commits to the branch by cherry-picking from main:\n\n```shell\ngit cherry-pick -x <commit_id>\n```\n\nYou will also want to push the branch to GitHub and ensure it passes CI.\n\nAfter that, tag it and notify users of the new release candidate:\n\n```shell\nexport RELEASE_CANDIDATE_NAME=\"$RELEASE_NAME-rc.2\"\ngit tag --sign --annotate \"${RELEASE_CANDIDATE_NAME}\" --message \"Helm release ${RELEASE_CANDIDATE_NAME}\"\ngit push upstream $RELEASE_CANDIDATE_NAME\n```\n\nOnce pushed to GitHub, check to ensure the branch with this tag builds in CI.\n\nFrom here on just repeat this process, continuously testing until you're happy\nwith the release candidate. For a release candidate, we don't write the full notes,\nbut you can scaffold out some [release notes](#7-write-the-release-notes).\n\n## 6. Finalize the Release\n\nWhen you're finally happy with the quality of a release candidate, you can move\non and create the real thing. Double-check one last time to make sure everything\nis in order, then finally push the release tag.\n\n```shell\ngit checkout $RELEASE_BRANCH_NAME\ngit tag --sign --annotate \"${RELEASE_NAME}\" --message \"Helm release ${RELEASE_NAME}\"\ngit push upstream $RELEASE_NAME\n```\n\nVerify that the release succeeded in\n[GitHub Actions](https://github.com/helm/helm/actions). If not, you will need to fix the\nrelease and push the release again.\n\nAs the CI job will take some time to run, you can move on to writing release\nnotes while you wait for it to complete.\n\n## 7. Write the Release Notes\n\nWe will auto-generate a changelog based on the commits that occurred during a\nrelease cycle, but it is usually more beneficial to the end-user if the release\nnotes are hand-written by a human being/marketing team/dog.\n\nIf you're releasing a major/minor release, listing notable user-facing features\nis usually sufficient. For patch releases, do the same, but make note of the\nsymptoms and who is affected.\n\nThe release notes should include the version and planned date of the next release.\n\nAn example release note for a minor release would look like this:\n\n```markdown\n## vX.Y.Z\n\nHelm vX.Y.Z is a feature release. This release, we focused on <insert focal point>. Users are encouraged to upgrade for the best experience.\n\nThe community keeps growing, and we'd love to see you there!\n\n- Join the discussion in [Kubernetes Slack](https://kubernetes.slack.com):\n  - `#helm-users` for questions and just to hang out\n  - `#helm-dev` for discussing PRs, code, and bugs\n- Hang out at the Public Developer Call: Thursday, 9:30 Pacific via [Zoom](https://zoom.us/j/696660622)\n- Test, debug, and contribute charts: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0)\n\n## Notable Changes\n\n- Kubernetes 1.16 is now supported including new manifest apiVersions\n- Sprig was upgraded to 2.22\n\n## Installation and Upgrading\n\nDownload Helm X.Y. The common platform binaries are here:\n\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n\nThe [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`.\n\n## What's Next\n\n- vX.Y.Z+1 will contain only bug fixes and is planned for <insert DATE>.\n- vX.Y+1.0 is the next feature release and is planned for <insert DATE>. This release will focus on ...\n\n## Changelog\n\n- chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese)\n- fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher)\n```\n\nA partially completed set of release notes including the changelog can be\ncreated by running the following command:\n\n```shell\nexport VERSION=\"$RELEASE_NAME\"\nexport PREVIOUS_RELEASE=vX.Y.Z\nmake clean\nmake fetch-dist\nmake release-notes\n```\n\nThis will create a good baseline set of release notes to which you should just\nneed to fill out the **Notable Changes** and **What's next** sections.\n\nFeel free to add your voice to the release notes; it's nice for people to think\nwe're not all robots.\n\nYou should also double check the URLs and checksums are correct in the\nauto-generated release notes.\n\nOnce finished, go into GitHub to [helm/helm\nreleases](https://github.com/helm/helm/releases) and edit the release notes for\nthe tagged release with the notes written here.\nFor target branch, set to $RELEASE_BRANCH_NAME.\n\nIt is now worth getting other people to take a look at the release notes before\nthe release is published. Send a request out to\n[#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG) for review. It is\nalways beneficial as it can be easy to miss something.\n\n## 8. PGP Sign the downloads\n\nWhile hashes provide a signature that the content of the downloads is what it\nwas generated, signed packages provide traceability of where the package came\nfrom.\n\nTo do this, run the following `make` commands:\n\n```shell\nexport VERSION=\"$RELEASE_NAME\"\nmake clean\t\t# if not already run\nmake fetch-dist\t# if not already run\nmake sign\n```\n\nThis will generate ascii armored signature files for each of the files pushed by\nCI.\n\nAll of the signature files (`*.asc`) need to be uploaded to the release on\nGitHub (attach binaries).\n\n## 9. Publish Release\n\nTime to make the release official!\n\nAfter the release notes are saved on GitHub, the CI build is completed, and\nyou've added the signature files to the release, you can hit \"Publish\" on\nthe release. This publishes the release, listing it as \"latest\", and shows this\nrelease on the front page of the [helm/helm](https://github.com/helm/helm) repo.\n\n## 10. Update Docs\n\nThe [Helm website docs section](https://helm.sh/docs) lists the Helm versions\nfor the docs. Major, minor, and patch versions need to be updated on the site.\nThe date for the next minor release is also published on the site and must be\nupdated.\nTo do that create a pull request against the [helm-www\nrepository](https://github.com/helm/helm-www). In the `config.toml` file find\nthe proper `params.versions` section and update the Helm version, like in this\nexample of [updating the current\nversion](https://github.com/helm/helm-www/pull/676/files).  In the same\n`config.toml` file, update the `params.nextversion` section.\n\nClose the [helm/helm milestone](https://github.com/helm/helm/milestones) for\nthe release, if applicable.\n\nUpdate the [version\nskew](https://github.com/helm/helm-www/blob/main/docs/topics/version_skew.mdx)\nfor major and minor releases.\n\nUpdate the release calendar [here](https://helm.sh/calendar/release):\n* create an entry for the next minor release with a reminder for that day at 5pm GMT\n* 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\n\n## 11. Tell the Community\n\nCongratulations! You're done. Go grab yourself a $DRINK_OF_CHOICE. You've earned\nit.\n\nAfter enjoying a nice $DRINK_OF_CHOICE, go forth and announce the new release\nin Slack and on Twitter with a link to the [release on\nGitHub](https://github.com/helm/helm/releases).\n\nOptionally, write a blog post about the new release and showcase some of the new\nfeatures on there!\n"
  },
  {
    "path": "community/release_policy.md",
    "content": "---\ntitle: \"Release schedule policy\"\ndescription: \"Describes Helm's release schedule policy.\"\n---\n\nFor the benefit of its users, Helm defines and announces release dates in\nadvance.  This document describes the policy governing Helm's release schedule.\n\n## Release calendar\n\nA public calendar showing the upcoming Helm releases can be found [here](https://helm.sh/calendar/release).\n## Semantic versioning\n\nHelm versions are expressed as `x.y.z`, where `x` is the major version, `y` is\nthe minor version, and `z` is the patch version, following [Semantic\nVersioning](https://semver.org/spec/v2.0.0.html) terminology.\n\n## Patch releases\n\nPatch releases provide users with bug fixes and security fixes.  They do not\ncontain new features.\n\nA new patch release relating to the latest minor/major release will normally be\ndone once a month on the second Wednesday of each month.\n\nA patch release to fix a high priority regression or security issue can be done\nwhenever needed.\n\nA scheduled patch release will be cancelled for any of the following reasons:\n- if there is no new content since the previous release\n- if the patch release date falls within one week before the first release candidate (RC1) of an upcoming minor release\n- if the patch release date falls within four weeks following a minor release\n- if a major or minor release is scheduled for the same month\n\n## Minor releases\n\nMinor releases contain security and bug fixes as well as new features.  They\nare backwards compatible with respect to the API and the CLI usage.\n\nTo align with Kubernetes releases, a minor helm release will be done every\n4 months (3 releases a year).\n\nExtra minor releases can be done if needed but will not affect the timeline of\nan announced future release, unless the announced release is less than 7 days\naway.\n\nAt the same time as a release is published, the date of the next minor release\nwill be announced and posted to Helm's main web page.\n\n## Major releases\n\nMajor releases contain breaking changes.  Such releases are rare but are\nsometimes necessary to allow helm to continue to evolve in important new\ndirections.\n\nMajor releases can be difficult to plan.  With that in mind, a final release\ndate will only be chosen and announced once the first beta version of such a\nrelease is available."
  },
  {
    "path": "community/stable-repo-charts-new-locations.md",
    "content": "---\ntitle: Stable chart repo new locations\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/stable-repo-charts-new-locations.md\n-->\n\n## First try Artifact Hub\n\nThe canonical source for Helm charts is the [Artifact Hub](https://artifacthub.io/), an aggregator for distributed chart repos.\n\n- [Chart end users](https://github.com/helm/community/blob/main/user-profiles.md#1-application-operator) looking for charts should look there.\n- [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.\n\n## Ongoing effort to relocate charts to new repos\n\nIf 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).\nIt continues to serve two needs:\n\n1. 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.\n2. 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! ✨\n\nWe will maintain this file until these needs are solved in another way, or are no longer necessary to solve, whichever comes first 🤝\n\n## Brief history to avoid confusion\n\nWhen `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).\n\nThose 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.\n\nThe table below was moved from the  now in GitHub to help the community contribute to tracking this migration through Pull Requests.\n\n## Status of relocated charts\n\n### Notes on updating lists below\n\n1. List all charts:\n\n    ```bash\n    find -d stable/ -mindepth 1 -maxdepth 1\n    ```\n\n2. List all charts marked `deprecated`:\n\n    ```bash\n    grep -l 'deprecated: true' stable/*/Chart.yaml | xargs -I {} dirname {}\n    ```\n\n3. 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)\n\n### Non-applicable (purposefully deprecated)\n\n- stable/acs-engine-autoscaler\n- stable/ark\n- stable/aws-cluster-autoscaler\n- stable/dask-distributed\n- stable/gcloud-endpoints\n- stable/kube-lego\n- stable/magic-namespace\n- stable/mongodb-replicaset (#23747)\n- stable/nginx-lego\n- stable/rabbitmq-ha (#23746)\n- stable/sematext-docker-agent\n\n### Applicable\n\n<!-- We use Inline HTML to make checkboxes in markdown tables for easier end user visual scanning. -->\n<!-- markdownlint-disable MD033 -->\n| Chart | Status | Issue/PR |\n| -- | -- | -- |\n| <ul><li>[ ] stable/aerospike</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/airflow</li></ul> | in progress: discussion started | https://github.com/apache/airflow/issues/10523 |\n| <ul><li>[x] stable/ambassador</li></ul> | done | https://github.com/datawire/ambassador-chart/issues/9 |\n| <ul><li>[x] stable/anchore-engine</li></ul> | done | https://github.com/helm/charts/pull/23509 |\n| <ul><li>[ ] stable/apm-server</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/artifactory</li></ul> | done | https://github.com/helm/charts/pull/7627 |\n| <ul><li>[x] stable/artifactory-ha</li></ul> | done | https://github.com/helm/charts/pull/7627 |\n| <ul><li>[ ] stable/atlantis</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/auditbeat</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/aws-iam-authenticator</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/bitcoind</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/bookstack</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/buildkite</li></ul> | done | https://github.com/helm/charts/pull/9200 |\n| <ul><li>[ ] stable/burrow</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/centrifugo</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/cerebro</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/cert-manager</li></ul> | done | https://github.com/helm/charts/pull/12970 |\n| <ul><li>[ ] stable/chaoskube</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/chartmuseum</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/chronograf</li></ul> | done | https://github.com/helm/charts/pull/21233 |\n| <ul><li>[ ] stable/clamav</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/cloudserver</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/cluster-autoscaler</li></ul> | done | https://github.com/kubernetes/autoscaler/pull/3341 |\n| <ul><li>[ ] stable/cluster-overprovisioner</li></ul> | in progress | https://github.com/helm/charts/pull/23586 |\n| <ul><li>[x] stable/cockroachdb</li></ul> | done | https://github.com/helm/charts/pull/23000 |\n| <ul><li>[ ] stable/collabora-code</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/concourse</li></ul> | done | https://github.com/helm/charts/pull/19128 |\n| <ul><li>[x] stable/consul</li></ul> | done | https://github.com/helm/charts/pull/22696 |\n| <ul><li>[ ] stable/contour</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/coredns</li></ul> | in progress | https://github.com/coredns/coredns/issues/3905 |\n| <ul><li>[ ] stable/cosbench</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/coscale</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/couchbase-operator</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/couchdb</li></ul> | done | https://github.com/helm/charts/pull/18079 |\n| <ul><li>[x] stable/dask</li></ul> | done | https://github.com/helm/charts/pull/18419 |\n| <ul><li>[X] stable/datadog</li></ul> | done | https://github.com/helm/charts/pull/23384 |\n| <ul><li>[ ] stable/dex</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/distributed-jmeter</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/distributed-tensorflow</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/distribution</li></ul> | done | https://github.com/helm/charts/pull/7627 |\n| <ul><li>[x] stable/dmarc2logstash</li></ul> | done | https://github.com/helm/charts/pull/22524 |\n| <ul><li>[ ] stable/docker-registry</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/dokuwiki</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/drone</li></ul> | done | https://github.com/helm/charts/pull/21151 |\n| <ul><li>[x] stable/drupal</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/efs-provisioner</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/elastabot</li></ul> | done | https://github.com/helm/charts/pull/22676 |\n| <ul><li>[x] stable/elastalert</li></ul> | done | https://github.com/helm/charts/pull/22689 |\n| <ul><li>[ ] stable/elastic-stack</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/elasticsearch</li></ul> | done | https://github.com/helm/charts/pull/21955 |\n| <ul><li>[ ] stable/elasticsearch-curator</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/elasticsearch-exporter</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/envoy</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/etcd-operator</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/ethereum</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/eventrouter</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/express-gateway</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/external-dns</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/factorio</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/filebeat</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/fluent-bit</li></ul> | migrated: need to deprecate chart with migration path | https://github.com/helm/charts/issues/21235 |\n| <ul><li>[ ] stable/fluentd</li></ul> | migrated: need to deprecate chart with migration path | https://github.com/helm/charts/issues/21235 |\n| <ul><li>[x] stable/fluentd-elasticsearch</li></ul> | done | https://github.com/helm/charts/pull/10354 |\n| <ul><li>[x] stable/g2</li></ul> | done | https://github.com/helm/charts/pull/4957 |\n| <ul><li>[ ] stable/gangway</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/gce-ingress</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/gcloud-sqlproxy</li></ul> | done | https://github.com/helm/charts/pull/9219 |\n| <ul><li>[ ] stable/gcp-night-king</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/ghost</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/gitlab-ce</li></ul> | done | https://github.com/helm/charts/pull/1876 |\n| <ul><li>[x] stable/gitlab-ee</li></ul> | done | https://github.com/helm/charts/pull/1876 |\n| <ul><li>[ ] stable/gocd</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/goldpinger</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/grafana</li></ul> | done | https://github.com/helm/charts/pull/23662 |\n| <ul><li>[x] stable/graphite</li></ul> | done | https://github.com/helm/charts/pull/10350 |\n| <ul><li>[x] stable/graylog</li></ul> | done | helm/charts#24011 |\n| <ul><li>[ ] stable/hackmd</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/hadoop</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/hazelcast</li></ul> | done | https://github.com/helm/charts/pull/22797 |\n| <ul><li>[x] stable/hazelcast-jet</li></ul> | done | https://github.com/helm/charts/pull/22798 |\n| <ul><li>[ ] stable/heapster</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/heartbeat</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/helm-exporter</li></ul> | migrated: need to update README | https://github.com/helm/charts/pull/20376 |\n| <ul><li>[ ] stable/hl-composer</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/hlf-ca</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/hlf-couchdb</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/hlf-ord</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/hlf-peer</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/hoard</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/home-assistant</li></ul> | done | https://github.com/helm/charts/pull/22745 |\n| <ul><li>[ ] stable/horovod</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/hubot</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/ignite</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/inbucket</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/influxdb</li></ul> | done | https://github.com/influxdata/helm-charts |\n| <ul><li>[ ] stable/ingressmonitorcontroller</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/instana-agent</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/ipfs</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/jaeger-operator</li></ul> | done | https://github.com/helm/charts/pull/19636 |\n| <ul><li>[ ] stable/janusgraph</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/jasperreports</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/jenkins</li></ul> | done | https://github.com/helm/charts/issues/23562 |\n| <ul><li>[x] stable/joomla</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/k8s-spot-rescheduler</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/k8s-spot-termination-handler</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/kafka-manager</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/kanister-operator</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/kapacitor</li></ul> | done | https://github.com/helm/charts/pull/21234 |\n| <ul><li>[ ] stable/karma</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/katafygio</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/keel</li></ul> | done | https://github.com/helm/charts/pull/9514 |\n| <ul><li>[x] stable/keycloak</li></ul> | done | https://github.com/helm/charts/pull/13316 |\n| <ul><li>[x] stable/kiam</li></ul> | done | https://github.com/helm/charts/pull/17959 |\n| <ul><li>[ ] stable/kibana</li></ul> | in progress | https://github.com/helm/charts/pull/23844 |\n| <ul><li>[x] stable/kong</li></ul> | done | https://github.com/helm/charts/pull/20149 |\n| <ul><li>[ ] stable/kube2iam</li></ul> | in progress: conversation started | https://github.com/jtblin/kube2iam/issues/277 |\n| <ul><li>[ ] stable/kube-hunter</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/kube-ops-view</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/kube-slack</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/kube-state-metrics</li></ul> | in progress | https://github.com/kubernetes/kube-state-metrics/issues/1153 |\n| <ul><li>[x] stable/kubed</li></ul> | done | https://github.com/helm/charts/pull/4957 |\n| <ul><li>[x] stable/kubedb</li></ul> | done | https://github.com/helm/charts/pull/4957 |\n| <ul><li>[x] stable/kuberhealthy</li></ul> | done | https://github.com/helm/charts/pull/23919 |\n| <ul><li>[x] stable/kubernetes-dashboard</li></ul> | done | https://github.com/helm/charts/pull/22627 |\n| <ul><li>[ ] stable/kuberos</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/kubewatch</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[X] stable/kured</li></ul> | done | https://github.com/weaveworks/kured/pull/150 |\n| <ul><li>[ ] stable/lamp</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/linkerd</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/locust</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/logdna-agent</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/logstash</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/luigi</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/magento</li></ul> | done | https://github.com/helm/charts/pull/14555 |\n| <ul><li>[ ] stable/magic-ip-address</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/mailhog</li></ul> | done | https://github.com/helm/charts/pull/13315 |\n| <ul><li>[x] stable/mariadb</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/mattermost-team-edition</li></ul> | done | https://github.com/helm/charts/pull/13540 |\n| <ul><li>[ ] stable/mcrouter</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/mediawiki</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/memcached</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/mercure</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/metabase</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/metallb</li></ul> | done | https://github.com/helm/charts/pull/23486 |\n| <ul><li>[ ] stable/metricbeat</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/metrics-server</li></ul> | in progress | https://github.com/kubernetes-sigs/metrics-server/issues/572 |\n| <ul><li>[ ] stable/minecraft</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/minio</li></ul> | done | https://charts.min.io |\n| <ul><li>[x] stable/mission-control</li></ul> | done | https://github.com/helm/charts/pull/7627 |\n| <ul><li>[x] stable/mongodb</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/moodle</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/msoms</li></ul> | in progress: discussion started | https://github.com/microsoft/charts/issues/19 |\n| <ul><li>[ ] stable/mssql-linux</li></ul> | in progress: discussion started | https://github.com/microsoft/charts/issues/19 |\n| <ul><li>[ ] stable/mysql</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/mysqldump</li></ul> | done | https://github.com/helm/charts/pull/23840 |\n| <ul><li>[ ] stable/namerd</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/nats</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/neo4j</li></ul> | done | https://github.com/helm/charts/pull/22437 |\n| <ul><li>[ ] stable/newrelic-infrastructure</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/nextcloud</li></ul> | done | https://github.com/helm/charts/pull/23627 |\n| <ul><li>[ ] stable/nfs-client-provisioner</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/nfs-server-provisioner</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/nginx-ingress</li></ul> | done | https://github.com/helm/charts/pull/22823 |\n| <ul><li>[ ] stable/nginx-ldapauth-proxy</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/node-problem-detector</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/node-red</li></ul> | done | https://github.com/helm/charts/pull/22739 |\n| <ul><li>[ ] stable/oauth2-proxy</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/odoo</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/opa</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/opencart</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[X] stable/openebs</li></ul> | done | https://github.com/helm/charts/pull/22860 |\n| <ul><li>[ ] stable/openiban</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/openldap</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/openvpn</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/orangehrm</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/osclass</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/owncloud</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/pachyderm</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/parse</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/percona</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/percona-xtradb-cluster</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/pgadmin</li></ul> | done | https://github.com/helm/charts/pull/21275 |\n| <ul><li>[x] stable/phabricator</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/phpbb</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/phpmyadmin</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/pomerium</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/postgresql</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/prestashop</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/presto</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/prisma</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/prometheus</li></ul> | done | https://github.com/helm/charts/pull/23692 |\n| <ul><li>[x] stable/prometheus-adapter</li></ul> | done | https://github.com/helm/charts/pull/23694 |\n| <ul><li>[x] stable/prometheus-blackbox-exporter</li></ul> | done | https://github.com/helm/charts/pull/23695 |\n| <ul><li>[x] stable/prometheus-cloudwatch-exporter</li></ul> | done | https://github.com/helm/charts/pull/23696 |\n| <ul><li>[x] stable/prometheus-consul-exporter</li></ul> | done | https://github.com/helm/charts/pull/23697 |\n| <ul><li>[x] stable/prometheus-couchdb-exporter</li></ul> | done | https://github.com/helm/charts/pull/23698 |\n| <ul><li>[x] stable/prometheus-mongodb-exporter</li></ul> | done | https://github.com/helm/charts/pull/23699 |\n| <ul><li>[x] stable/prometheus-mysql-exporter</li></ul> | done | https://github.com/helm/charts/pull/23700 |\n| <ul><li>[x] stable/prometheus-nats-exporter</li></ul> | done | https://github.com/helm/charts/pull/23701 |\n| <ul><li>[x] stable/prometheus-node-exporter</li></ul> | done | https://github.com/helm/charts/pull/23702 |\n| <ul><li>[x] stable/prometheus-operator</li></ul> | done | https://github.com/helm/charts/pull/23738 |\n| <ul><li>[x] stable/prometheus-postgres-exporter</li></ul> | done | https://github.com/helm/charts/pull/23703 |\n| <ul><li>[x] stable/prometheus-pushgateway</li></ul> | done | https://github.com/helm/charts/pull/23704 |\n| <ul><li>[x] stable/prometheus-rabbitmq-exporter</li></ul> | done | https://github.com/helm/charts/pull/23705 |\n| <ul><li>[x] stable/prometheus-redis-exporter</li></ul> | done | https://github.com/helm/charts/pull/23706 |\n| <ul><li>[x] stable/prometheus-snmp-exporter</li></ul> | done | https://github.com/helm/charts/pull/23708 |\n| <ul><li>[x] stable/prometheus-to-sd</li></ul> | done | https://github.com/helm/charts/pull/23707 |\n| <ul><li>[ ] stable/quassel</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/rabbitmq</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/redis</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/redis-ha</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/redmine</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/reloader</li></ul> | done | https://github.com/helm/charts/pull/23595 |\n| <ul><li>[ ] stable/rethinkdb</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/risk-advisor</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/rocketchat</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/rookout</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/sapho</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/satisfy</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/schema-registry-ui</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/sealed-secrets</li></ul> | Discussion ongoing - not settled | https://github.com/bitnami-labs/sealed-secrets/issues/389 |\n| <ul><li>[x] stable/searchlight</li></ul> | done | https://github.com/helm/charts/pull/4957 |\n| <ul><li>[ ] stable/selenium</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/sematext-agent</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/sensu</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/sentry</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/seq</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/signalfx-agent</li></ul> | done | https://github.com/helm/charts/pull/13586 |\n| <ul><li>[ ] stable/signalsciences</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/socat-tunneller</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/sonarqube</li></ul> | done | https://github.com/helm/charts/pull/21007 |\n| <ul><li>[x] stable/sonatype-nexus</li></ul> | done | https://github.com/helm/charts/pull/21255 |\n| <ul><li>[ ] stable/spark</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/spark-history-server</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/spartakus</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/spinnaker</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/spotify-docker-gc</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/spring-cloud-data-flow</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/stackdriver-exporter</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/stash</li></ul> | done | https://github.com/helm/charts/pull/4957 |\n| <ul><li>[ ] stable/stellar-core</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/stolon</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/suitecrm</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/sumokube</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/sumologic-fluentd</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/superset</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/swift</li></ul> | done | https://github.com/helm/charts/pull/4957 |\n| <ul><li>[ ] stable/sysdig</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/telegraf</li></ul> | done | https://github.com/helm/charts/pull/21232 |\n| <ul><li>[ ] stable/tensorflow-notebook</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/tensorflow-serving</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/terracotta</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/testlink</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[ ] stable/tomcat</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/traefik</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/uchiwa</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/unbound</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/unifi</li></ul> | done | https://github.com/helm/charts/pull/23714 |\n| <ul><li>[ ] stable/vault-operator</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/velero</li></ul> | done | https://github.com/helm/charts/pull/19719 |\n| <ul><li>[ ] stable/verdaccio</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/voyager</li></ul> | done | https://github.com/helm/charts/pull/4957 |\n| <ul><li>[ ] stable/vsphere-cpi</li></ul> | STATUS | URL |\n| <ul><li>[x] stable/wavefront</li></ul> | done | https://github.com/helm/charts/pull/20055 |\n| <ul><li>[ ] stable/weave-cloud</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/weave-scope</li></ul> | in progress: discussion underway | https://github.com/weaveworks/scope/issues/3807 |\n| <ul><li>[x] stable/wordpress</li></ul> | done | https://github.com/helm/charts/issues/20969 |\n| <ul><li>[x] stable/xray</li></ul> | done | https://github.com/helm/charts/pull/7627 |\n| <ul><li>[ ] stable/zeppelin</li></ul> | STATUS | URL |\n| <ul><li>[ ] stable/zetcd</li></ul> | STATUS | URL |\n"
  },
  {
    "path": "community/user-profiles.md",
    "content": "---\ntitle: User Profiles\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/user-profiles.md\n-->\n\nThe purpose of this document is to aid in the development of Helm features by evaluating Helm features against those who will be using them.\n\nWhen 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.\n\n## Preface\n\n* 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.\n* 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.\n\n## Profiles\n\nProfiles 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.\n\n### 1. Application Operator\n\nApplication 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).\n\n### 2. Application Distributor\n\nDistributors 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.\n\n### 3. Application Developer\n\nAn 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.\n\n### 4. Supporting Tool Developer\n\nSupporting 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.\n\n### 5. Helm Developer\n\nHelm developers are those who develop Helm itself. That includes core maintainers along with anyone else who fixes a bug or updates docs.\n\nGenerally speaking, the developers of Helm consider the end users above themselves when looking at requirements and implementation strategies.\n\n## Profiles Not In Scope\n\nSome 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.\n\n## Cluster Operator\n\nA 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."
  },
  {
    "path": "docs/_v4-in-progress.mdx",
    "content": ":::warning\nThis 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).\n:::"
  },
  {
    "path": "docs/changelog.md",
    "content": "---\nsidebar_position: 2\nsidebar_label: Full Changelog\n---\n\n# Helm 4 Full Changelog\n\n**Scope**: 290 PRs from (`v4.0.0-rc.1`) compared to `v3.19.0`\n**v4-only**: 257 PRs (33 backported to v3 excluded)\n\nSee the [Overview](/overview.md) for an actionable summary of these changes.\n\n## New Features\n\nNew features in Helm 4 that were not backported to v3\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31435 | 2025-11-03 | matheuscscp | Introduce a context for canceling wait operations |\n| #31389 | 2025-10-30 | TerryHowe | chore: fix pkg/registry warnings to reduce noise |\n| #31338 | 2025-10-21 | yzewei | Add loongarch64 support |\n| #31351 | 2025-10-21 | gjenkins8 | feat: `helm version` print Kubernetes (client-go) version |\n| #31376 | 2025-10-21 | benoittgt | Do not ignore *.yml file on linting while accepting *.yaml |\n| #31362 | 2025-10-21 | fabiocarneiro | Clarify the intent of the resource instructions |\n| #31392 | 2025-10-16 | TerryHowe | feature: create copilot structured context |\n| #31295 | 2025-10-13 | TerryHowe | Fix make helm list show all by default |\n| #31372 | 2025-10-10 | mattfarina | Enable Releases To Have Multiple Versions |\n| #31254 | 2025-09-23 | benoittgt | Warn when we fallback to a different version on `helm pull` |\n| #31275 | 2025-09-10 | benoittgt | Extend --skip-schema-validation for lint command |\n| #31116 | 2025-09-02 | banjoh | chore: check if go modules are tidy before build |\n| #31217 | 2025-09-01 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Move Postrenderer to a plugin type |\n| #31196 | 2025-08-31 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Remove unnecessary file i/o operations from signing and verifying |\n| #31176 | 2025-08-30 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin packaging, signing, and verification |\n| #31194 | 2025-08-28 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin extism/v1 runtime |\n| #30812 | 2025-08-27 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> HIP-0023: Helm support server-side apply |\n| #31174 | 2025-08-26 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin tarball support for HTTP and local installers |\n| #31172 | 2025-08-26 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin OCI installer |\n| #31146 | 2025-08-23 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin types and plugin apiVersion v1 |\n| #31145 | 2025-08-22 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin runtime interface |\n| #31142 | 2025-08-21 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Move pkg/plugin -> internal/plugin |\n| #31030 | 2025-08-14 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> HIP-0023: Kube client support server-side apply |\n| #12624 | 2025-08-13 | papdaniel | show crds command output separated by document separator |\n| #13111 | 2025-08-13 | rawtaz | style(pkg/chartutil): add missing dots and indentation to defaultValues |\n| #31076 | 2025-08-11 | matheuscscp | pkg/registry: Login option for passing TLS config in memory |\n| #31034 | 2025-08-05 | Mazafard | Feat: Add color output functionality and tests for release statuses |\n| #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 |\n| #31019 | 2025-07-17 | zachburg | Return early when linting if the `templates/` directory does not exist |\n| #31011 | 2025-07-17 | yalosev | feature: add labels to metadata |\n| #31015 | 2025-07-17 | zachburg | Add linter support for the `crds/` directory |\n| #13154 | 2025-07-10 | carloslima | Allow post-renderer to process hooks |\n| #13586 | 2025-06-04 | jessesimpson36 | feat: add formatting for errors to make multiline stacktraces in helm templates |\n| #30553 | 2025-05-07 | Zhanweelee | feat: Add mustToYaml and mustToJson template functions |\n| #30734 | 2025-04-21 | ipaqsa | feat(pkg/engine): add support for custom template funcs |\n| #13283 | 2025-04-14 | win-t | adding support for JSON Schema 2020 |\n| #30751 | 2025-04-13 | benoittgt | Add detailed debug logging for resource readiness states |\n| #30708 | 2025-04-11 | benoittgt | Migrate pkg to slog |\n| #13604 | 2025-04-05 | AustinAbro321 | Introduce kstatus watcher |\n| #13617 | 2025-02-27 | AustinAbro321 | <span class=\"breaking\">BREAKING CHANGE:</span>  Refactor cmd/helm to allow library usage |\n| #30571 | 2025-02-24 | yardenshoham | feat: error out when post-renderer produces no output |\n| #13655 | 2025-02-20 | LuBingtan | feat: support multi-document values files |\n| #13471 | 2025-02-19 | wangjingcun | Use a more direct and less error-prone return value |\n| #30294 | 2025-02-19 | Zhanweelee | Supports json arguments |\n| #13538 | 2025-01-17 | godhanipayal | Add Contextual Error Messages to RunWithContext |\n| #12588 | 2024-11-22 | rynowak | Make the authorizer and registry authorizer configurable |\n\n## Bug Fixes\n\nFixes in Helm 4 that were not backported to v3\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31323 | 2025-10-29 | mattfarina | Reproducible chart archive builds |\n| #31411 | 2025-10-29 | banjoh | fix: reinstate logger parameter to actions package |\n| #31204 | 2025-10-22 | benoittgt | Avoid panic in helm.sh/helm/v3/pkg/chartutil.ValidateAgainstSchema |\n| #31337 | 2025-10-22 | rachelvweber | Fixing rollback and uninstall client WaitStrategy |\n| #31393 | 2025-10-21 | benoittgt | Return errors during upgrade when the deletion of resources fails |\n| #31406 | 2025-10-21 | jessesimpson36 | fix: kube client should return empty results objects instead of nil |\n| #31375 | 2025-10-13 | TerryHowe | fix: release info time parsing |\n| #31349 | 2025-10-07 | TerryHowe | fix: flakey lint test on shuffle |\n| #31327 | 2025-10-07 | TerryHowe | fix: broken `--html` flag to coverage script |\n| #31354 | 2025-10-07 | TerryHowe | fix: flake upgrade test |\n| #31227 | 2025-10-03 | evankanderson | Use filepath.Path when handling directory names |\n| #31307 | 2025-10-02 | TerryHowe | fix: Ignore absolute path when RepoUrl is provided |\n| #31334 | 2025-09-30 | fleaz | Fix typo in bug-report  issue template |\n| #31330 | 2025-09-25 | mattfarina | Restore lint rule for excluding meaningless name |\n| #31320 | 2025-09-25 | kosiew | provenance: allow RSA signing when ed25519 keys are present (switch to ProtonMail/go-crypto) |\n| #31285 | 2025-09-12 | bennsimon | fix: remove leftover debugging line that outputs invalid YAML for helm template command |\n| #31277 | 2025-09-11 | benoittgt | Fix deprecation warning for spf13/pflag from 1.0.7 to 1.0.10 |\n| #31272 | 2025-09-09 | TerryHowe | fix: idea gitignore entry |\n| #31252 | 2025-09-05 | kamilswiec | fix:chartfile tests - semver2 error message |\n| #31199 | 2025-09-05 | TerryHowe | fix: flaky registry data race on mockdns close |\n| #31200 | 2025-09-05 | TerryHowe | fix: installer action goroutine count |\n| #31222 | 2025-09-03 | benoittgt | Prevent failing `helm push` on ghcr.io using standard GET auth token flow |\n| #31191 | 2025-08-26 | TerryHowe | fix: send logging to stderr |\n| #31138 | 2025-08-19 | islewis | fix(helm-lint): Add HTTP/HTTPS URL support for json schema references |\n| #31152 | 2025-08-18 | TerryHowe | fix: enable shuffle in Makefile for unit tests |\n| #12968 | 2025-08-13 | sjeandeaux | helm uninstall dry run support `--ignore-not-found` |\n| #31126 | 2025-08-12 | paologallinaharbur | fix(transport): leverage same tls config |\n| #31109 | 2025-08-06 | carlossg | fix: prevent panic when ChartDownloader.getOciURI |\n| #31074 | 2025-07-18 | joejulian | add missing template directory to badcrdfile testdata |\n| #31042 | 2025-07-10 | TerryHowe | fix: test teardown dns data race |\n| #30898 | 2025-07-06 | AshmitBhardwaj | Fix issue 13198 |\n| #31021 | 2025-07-05 | zachburg | Update tests in create_test.go and package_test.go to work in a temp directory |\n| #31024 | 2025-07-03 | gjenkins8 | fix: 'TestRunLinterRule' stateful test |\n| #30900 | 2025-06-23 | unguiculus | Add timeout flag to repo add and update commands |\n| #30981 | 2025-06-15 | TerryHowe | fix: lint test SetEnv errors |\n| #30973 | 2025-06-12 | manslaughter03 | fix: wrap run release test error in case GetPodLogs failed. |\n| #30972 | 2025-06-10 | TerryHowe | fix: kube client create mutex |\n| #30958 | 2025-06-06 | TerryHowe | fix: repo update cmd mutex |\n| #30955 | 2025-06-04 | carloslima | Fix tests deleting XDG_DATA_HOME |\n| #30939 | 2025-06-03 | TerryHowe | fix: action hooks delete policy mutex |\n| #12581 | 2025-06-03 | MichaelMorrisEst | Consider full GroupVersionKind when matching resources |\n| #30930 | 2025-05-28 | benoittgt | Fix flaky TestFindChartURL due to non-deterministic map iteration |\n| #30884 | 2025-05-21 | mattfarina | Reverting fix \"renders int as float\" |\n| #30862 | 2025-05-20 | OmriSteiner | fix: correctly concat absolute URIs in repo cache |\n| #30864 | 2025-05-16 | jessesimpson36 | fix: remove duplicate error message |\n| #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 |\n| #30800 | 2025-04-25 | mmorel-35 | fix: dep fs errors |\n| #30803 | 2025-04-25 | mattfarina | Fixing windows build |\n| #30783 | 2025-04-23 | rpolishchuk | fix: chart icon presence test |\n| #30777 | 2025-04-23 | ryanhockstad | fix: null merge |\n| #9175 | 2025-04-23 | dastrobu | fix: copy dependencies on aliasing to avoid sharing chart references on multiply aliased dependencies |\n| #12382 | 2025-04-20 | edbmiller | fix(pkg/lint): unmarshals Chart.yaml strictly |\n| #30766 | 2025-04-17 | benoittgt | Fix main branch by defining wait strategy parameter on hooks |\n| #30718 | 2025-04-16 | klihub | Allow signing multiple charts with a single passphrase from stdin. |\n| #30752 | 2025-04-16 | benoittgt | Bump golangci lint to last major version and fix static-check errors |\n| #30737 | 2025-04-11 | rpolishchuk | fix: order dependent test |\n| #9318 | 2025-04-07 | wahabmk | Fix issue with helm pull failing if pulling from a repository that redirects to another domain |\n| #13119 | 2025-04-05 | idsulik | fix(concurrency): Use channel for repoFailList errors in updateCharts |\n| #30618 | 2025-03-04 | AustinAbro321 | Fix namespace flag not registering |\n| #30590 | 2025-03-01 | SantalScript | fix:add proxy support when mTLS configured |\n| #30572 | 2025-02-25 | yardenshoham | fix: error when more than one post-renderer is specified |\n| #30576 | 2025-02-23 | felipecrs | Fix flaky TestDedupeRepos |\n| #30562 | 2025-02-20 | robertsirc | fixing error handling from a previous PR |\n| #13656 | 2025-02-03 | gjenkins8 | fix: Bind repotest server to `localhost` |\n| #13633 | 2025-01-17 | mattfarina | Ensuring the file paths are clean prior to passing to securejoin |\n| #13425 | 2024-11-15 | MathieuCesbron | Fix typo \"re-use\" to \"reuse\" |\n\n## Refactor/Cleanup\n\nCode quality improvements and modernization\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31440 | 2025-10-29 | mattfarina | Updating Go and golangci-lint versions |\n| #31408 | 2025-10-21 | AndiDog | Improve error message when plugin source cannot be determined or a non-directory is passed |\n| #31390 | 2025-10-21 | TerryHowe | fix: improve pkg/cmd/list test coverage |\n| #31365 | 2025-10-21 | reddaisyy | refactor: use reflect.TypeFor |\n| #31395 | 2025-10-21 | wyrapeseed | chore: fix some comment format |\n| #31401 | 2025-10-17 | TerryHowe | refactor: remove unused err from pkg/registry/client.go |\n| #31391 | 2025-10-15 | TerryHowe | chore: rename test registry |\n| #31302 | 2025-10-13 | TerryHowe | fix: helm verify Run signature |\n| #31270 | 2025-10-13 | TerryHowe | chore: registry utils clean up |\n| #31383 | 2025-10-13 | dirkmueller | Avoid accessing .Items on nil object |\n| #31379 | 2025-10-13 | TerryHowe | fix: clean up coverage script temp file |\n| #30980 | 2025-10-10 | gjenkins8 | cleanup: Remove/consolidate redundant kube client Interfaces |\n| #30712 | 2025-10-10 | gjenkins8 | cleanup: Remove extra lint/rules.Template functions |\n| #30833 | 2025-10-09 | gjenkins8 | refactor/cleanup: Replace action 'DryRun' string with DryRunStrategy type + deprecations |\n| #31326 | 2025-10-07 | TerryHowe | Update sign tests to use testify |\n| #31312 | 2025-10-01 | gjenkins8 | Remove unused 'Settings' from plugin schema |\n| #31143 | 2025-09-25 | TerryHowe | fix: remove redundant error check |\n| #31249 | 2025-09-25 | banjoh | chore: add additional logging to plugin installer |\n| #31321 | 2025-09-24 | juejinyuxitu | chore: fix some typos in comment |\n| #31297 | 2025-09-22 | TerryHowe | fix: hide notes in helm test command |\n| #31315 | 2025-09-22 | benoittgt | Remove unused golangci-lint rules that produce warning |\n| #31294 | 2025-09-19 | TerryHowe | Remove implicit support for helm lint current directory |\n| #31301 | 2025-09-19 | TerryHowe | chore: remove helm version `--client` option |\n| #31303 | 2025-09-18 | mattfarina | Update the action interfaces for chart apiversions |\n| #31198 | 2025-09-16 | TerryHowe | refactor: replace pkg/engine regular expressions with parser |\n| #31293 | 2025-09-16 | TerryHowe | chore: remove pkg/time which is no longer needed |\n| #31287 | 2025-09-16 | miledxz | improve fileutil test coverage |\n| #31292 | 2025-09-16 | reddaisyy | refactor: use strings.builder |\n| #31286 | 2025-09-12 | yajianggroup | refactor: use strings.CutPrefix |\n| #31258 | 2025-09-08 | StephanieHhnbrg | Refactor unreachableKubeClient for testing into failingKubeClient |\n| #31259 | 2025-09-07 | StephanieHhnbrg | Adapt test-coverage command to be able to run for a certain package |\n| #31225 | 2025-09-02 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move lint pkg to be part of each chart version |\n| #31220 | 2025-09-02 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> refactor: utilize `pluginTypesIndex` for config unmarshalling  |\n| #31219 | 2025-09-02 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove 'SetupPluginEnv' |\n| #31216 | 2025-09-02 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move to versioned packages |\n| #31224 | 2025-09-01 | gjenkins8 | fix: Adjust PostRenderer plugin output to value |\n| #31218 | 2025-09-01 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove legacy Command/Hooks from v1 Subprocess (#23) |\n| #31151 | 2025-08-30 | TerryHowe | fix: make file whitespace |\n| #31178 | 2025-08-28 | mattfarina | Add content cache to helm env |\n| #31165 | 2025-08-22 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Initial addition of content based cache |\n| #13629 | 2025-08-22 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Rename 'atomic' -> 'rollback-on-failure' |\n| #31175 | 2025-08-21 | cuiweixie | pkg/register: refactor to use atomic.Uint64 |\n| #31132 | 2025-08-19 | joemicky | refactor: replace []byte(fmt.Sprintf) with fmt.Appendf  |\n| #31133 | 2025-08-14 | joemicky | refactor: replace HasPrefix+TrimPrefix with CutPrefix |\n| #31134 | 2025-08-14 | joemicky | refactor: omit unnecessary reassignment |\n| #11700 | 2025-08-13 | suzaku | Refactor, use sort.Slice to reduce boilerplate code |\n| #31058 | 2025-08-07 | farazkhawaja | Add test coverage for get_values/metadata.go |\n| #31107 | 2025-08-06 | Pavanipogula | test(pkg/kube): Add unit tests to wait and roundtripper files. |\n| #31106 | 2025-08-05 | irikeish | test(pkg/kube): add test for Client.isReachable |\n| #30982 | 2025-08-05 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Rename 'force' to 'force-replace' |\n| #31094 | 2025-08-04 | mikelolasagasti | chore(deps): remove phayes/freeport module |\n| #31101 | 2025-07-30 | banjoh | feat: switch yaml library to go.yaml.in/yaml/v3 |\n| #31081 | 2025-07-25 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Initial addition of v3 charts |\n| #31079 | 2025-07-22 | gjenkins8 | cleanup: Remove plugin deprecated 'UseTunnelDeprecated' |\n| #31060 | 2025-07-18 | yumeiyin | refactor: replace Split in loops with more efficient SplitSeq |\n| #31065 | 2025-07-15 | TerryHowe | chore: improve OCI debug logging |\n| #31033 | 2025-07-14 | navinag1989 | test: increase test coverage for pkg/cli/options.go file |\n| #31029 | 2025-07-07 | gjenkins8 | chore(refactor): Privatize 'k8sYamlStruct' |\n| #31023 | 2025-07-03 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove deprecated '--create-pods' flag |\n| #31009 | 2025-07-02 | tpresa | test: increase test coverage for pkg/pusher |\n| #31018 | 2025-07-01 | mattfarina | Move logging setup to be configurable |\n| #30909 | 2025-06-03 | jinjiadu | refactor: replace HasPrefix+TrimPrefix with CutPrefix |\n| #30809 | 2025-06-03 | mmorel-35 | chore: enable usetesting linter |\n| #30865 | 2025-05-22 | mmorel-35 | refactor: update json-patch import path and add gomodguard settings |\n| #30871 | 2025-05-20 | gjenkins8 | Run test OCI registry localhost |\n| #30866 | 2025-05-20 | mmorel-35 | chore: enable thelper linter |\n| #30863 | 2025-05-16 | mattfarina | Adding test for list command |\n| #30850 | 2025-05-12 | yetyear | refactor: use maps.Copy for cleaner map handling |\n| #30829 | 2025-05-09 | TerryHowe | Increase pkg/time test coverage |\n| #30810 | 2025-05-08 | mmorel-35 | chore: enable usestdlibvars linter |\n| #30844 | 2025-05-08 | TerryHowe | fix: rename slave replica |\n| #30827 | 2025-05-06 | findnature | refactor: use slices.Contains to simplify code |\n| #13460 | 2025-04-23 | justenstall | fix: replace \"github.com/pkg/errors\" with stdlib \"errors\" package |\n| #30788 | 2025-04-23 | stephenpmurray | ref(helm): Export Chart Not Found error |\n| #30781 | 2025-04-22 | mmorel-35 | chore: remove `github.com/hashicorp/go-multierror` dependency |\n| #13578 | 2025-04-18 | gjenkins8 | refactor: Remove ChartRepository `[]ChartPaths` |\n| #30760 | 2025-04-16 | robertsirc | adding slog debug to a few points |\n| #30713 | 2025-04-11 | gjenkins8 | cleanup: Remove Helm v2 template lint rules |\n| #30749 | 2025-04-11 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Removing the alpine test chart |\n| #30686 | 2025-04-11 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Remove deprecated code |\n| #30736 | 2025-04-09 | robertsirc | manually updating go.mod file |\n| #13458 | 2025-04-05 | thudi | <span class=\"breaking\">BREAKING CHANGE:</span> #13449 Resolves: Replacing NewSimpleClientSet to NewClientSet due to deprecation |\n| #30684 | 2025-03-21 | twz123 | Remove ClientOptResolver from OCI Client |\n| #30603 | 2025-03-21 | robertsirc | converting inline log to slog |\n| #30699 | 2025-03-21 | mattfarina | Error when failed repo update. |\n| #30592 | 2025-02-28 | robertsirc | changing from log to slog |\n| #30589 | 2025-02-26 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move pkg/release to pkg/release/v1 to support v3 charts |\n| #30586 | 2025-02-25 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move pkg/chart to pkg/chart/v2 to prepare for v3 charts |\n| #30585 | 2025-02-25 | robertsirc | removing old apis |\n| #30580 | 2025-02-24 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move pkg/releaseutil to pkg/release/util |\n| #11112 | 2025-02-22 | felipecrs | perf(dep-up): do not update the same repo multiple times |\n| #30567 | 2025-02-21 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Moving chartutil to chart/util |\n| #30566 | 2025-02-21 | robertsirc | remove unused config.go |\n| #30470 | 2025-02-19 | gjenkins8 | Cleanup `repotest.Server` constructors |\n| #30550 | 2025-02-19 | mattfarina | Moving to SetOut and SetErr for Cobra |\n| #30546 | 2025-02-19 | hugehope | refactor: using slices.Contains to simplify the code |\n| #13535 | 2025-02-05 | gjenkins8 | refactor: tlsutil use options pattern |\n| #13665 | 2025-02-05 | gjenkins8 | chore: Remove unused `WaitAndGetCompletedPodPhase` |\n| #13579 | 2025-02-05 | gjenkins8 | refactor: Remove duplicate `FindChartIn*RepoURL` functions |\n| #13516 | 2025-01-24 | TerryHowe | chore: fix problems with latest lint |\n| #13494 | 2025-01-18 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove deprecated `repo add --no-update` flag |\n| #13602 | 2025-01-17 | crystalstall | refactor: using slices.Contains to simplify the code |\n| #13600 | 2025-01-14 | gjenkins8 | cleanup: `NewShowWithConfig` -> `NewShow` |\n| #13601 | 2025-01-09 | gjenkins8 | cleanup: Remove superseded 'lint/rules.Values' function |\n| #13611 | 2025-01-07 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Updating the internal version to v4 |\n| #13576 | 2025-01-07 | gjenkins8 | refactor: Consolidate lint package Run() functions |\n| #13577 | 2025-01-07 | gjenkins8 | refactor: Remove redundant `NewPullWithOpts` |\n| #13599 | 2025-01-07 | gjenkins8 | cleanup: `ProcessDependenciesWithMerge` -> `ProcessDependencies` |\n| #13573 | 2024-12-27 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Updating to helm.sh/helm/v4 |\n| #13444 | 2024-12-07 | justenstall | refactor(status): remove --show-desc and --show-resources flags |\n\n## Other\n\nInfrastructure and project management improvements\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31197 | 2025-09-03 | tzchenxixi | chore: fix function name |\n| #31150 | 2025-08-18 | TerryHowe | Feature add stale pr workflow |\n| #31149 | 2025-08-18 | TerryHowe | fix: stale issue workflow |\n| #31077 | 2025-07-21 | gaspergrom | fix: LFX health score badge link |\n| #31047 | 2025-07-10 | jingchanglu | chore: fix typo in pkg/repo/chartrepo.go |\n| #31004 | 2025-06-26 | andreped | fix(docs): Typofix in README |\n| #31002 | 2025-06-26 | curlwget | chore: fix function in comment |\n| #30912 | 2025-06-17 | Bhargavkonidena | Fix #30893 - issue templates |\n| #30957 | 2025-06-04 | acceptacross | chore: fix some function names in comment |\n| #30914 | 2025-05-27 | benoittgt | Fix dependabot upgrade of jsonschema to v6.0.2 |\n| #30904 | 2025-05-23 | benoittgt | [Doc] Help users avoid specifying URL scheme and path with `helm registry` |\n| #30882 | 2025-05-20 | caniszczyk | Add new LFX Insights Health Score Badge |\n| #30872 | 2025-05-20 | benoittgt | Bump golangci-lint version to match last golangci-lint-action |\n| #30824 | 2025-05-05 | adharsh277 | Fix bug in .golangci.yml configuration |\n| #30786 | 2025-04-25 | mmorel-35 | refactor: reorganize .golangci.yml for better clarity and structure |\n| #30785 | 2025-04-23 | mmorel-35 | fix: govulncheck workflow |\n| #30784 | 2025-04-22 | scottrigby | chore(OWNERS): Add TerryHowe as Triage Maintainer |\n| #30773 | 2025-04-18 | wangcundashang | chore: fix function name in comment |\n| #30754 | 2025-04-16 | mattfarina | Simplify the JSON Schema checking |\n| #30693 | 2025-03-20 | linghuying | chore: make function comment match function name |\n| #30665 | 2025-03-13 | mattfarina | Updating to 0.37.0 for x/net |\n| #30611 | 2025-03-04 | gjenkins8 | chore: Remove 'coveralls' |\n| #30612 | 2025-03-04 | gjenkins8 | fix: Fix go report card badge reference/link |\n| #30508 | 2025-02-19 | eimhin-rover | Update version option description with more accurate info |\n| #30497 | 2025-02-12 | robertsirc | adding-my-key |\n| #30295 | 2025-02-07 | edithturn | Add Percona to the list of organizations using Helm |\n| #13653 | 2025-01-23 | petercover | chore: fix some comments |\n| #13625 | 2025-01-13 | shahbazaamir | ading info to install helm , referring the documentation |\n| #13563 | 2024-12-21 | gjenkins8 | Run `build-test` action on `dev-v3` branch |\n| #13552 | 2024-12-20 | gjenkins8 | Fix `dependabot.yml` `target-branch` typo |\n| #13529 | 2024-12-15 | godhanipayal | Adding Oracle to the adopters list |\n| #13509 | 2024-12-06 | gjenkins8 | Dependabot update `dev-v3` branch go modules |\n| #13212 | 2024-12-01 | mbianchidev | Update ADOPTERS.md |\n| #13465 | 2024-11-20 | banjoh | Add precommit config to .gitignore |\n| #13443 | 2024-11-15 | mattfarina | Updating docs around v3 and v4 |\n\n## v4 Changes Also Backported to v3\n\nThese PRs were included in v4 but were also backported to v3 releases\n\n### New Features (Backported)\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #30696 | 2025-03-24 | benoittgt | Inform about time spent waiting resources to be ready in slog format |\n| #12912 | 2025-03-11 | hegerdes | feat: add httproute from gateway-api to create chart template |\n| #10309 | 2025-02-21 | Bez625 | Add hook annotation to output hook logs to client on error |\n| #13481 | 2025-02-18 | banjoh | feat: Enable CPU and memory profiling |\n| #12690 | 2025-01-01 | TerryHowe | feat: OCI install by digest |\n| #13232 | 2024-12-20 | dnskr | ref(create): don't render empty resource fields |\n| #12962 | 2024-12-04 | stevehipwell | feat: Added multi-platform plugin hook support |\n| #13343 | 2024-11-19 | niladrih | Add annotations and dependencies to get metadata output |\n\n### Bug Fixes (Backported)\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31064 | 2025-09-05 | kamilswiec | lint: throw warning when chart version is not semverv2 |\n| #31156 | 2025-08-22 | estroz | fix: set repo authorizer in registry.Client.Resolve() |\n| #30992 | 2025-08-18 | TerryHowe | fix: force bearer oauth for if registry requests bearer auth |\n| #31115 | 2025-08-18 | banjoh | fix: use username and password if provided |\n| #30891 | 2025-08-13 | gjenkins8 | fix: Port pluginCommand & command warning |\n| #31050 | 2025-08-08 | heyLu | Fix `helm pull` untar dir check with repo urls |\n| #31078 | 2025-07-24 | 8tomat8 | fix: k8s version parsing to match original |\n| #30979 | 2025-06-17 | TerryHowe | fix: OAuth username password login for v4 |\n| #30917 | 2025-06-01 | TerryHowe | fix: add debug logging to oci transport |\n| #30937 | 2025-05-30 | TerryHowe | fix: legacy docker support broken for login |\n| #30928 | 2025-05-28 | TerryHowe | fix: plugin installer test with no Internet |\n| #30905 | 2025-05-23 | robertsirc | forward porting 30902 |\n| #30894 | 2025-05-23 | benoittgt | Prevent push cmd failure in 3.18 by handling version tag resolution in ORAS memory store |\n| #30697 | 2025-04-17 | p-se | Fix --take-ownership for custom resources - closes #30622 |\n| #30673 | 2025-04-16 | nvanthao | fix: Process all hook deletions on failure |\n| #30701 | 2025-04-11 | zanuka | updates mutate and validate web hook configs |\n| #13583 | 2025-01-15 | jiashengz | fix: check group for resource info match |\n\n### Refactor/Cleanup (Backported)\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #30677 | 2025-04-18 | dongjiang1989 | chore: Update Golang to v1.24 |\n| #30741 | 2025-04-11 | benoittgt | Bumps github.com/distribution/distribution/v3 from 3.0.0-rc.3 to 3.0.0 |\n| #13382 | 2025-02-03 | TerryHowe | chore(oci): migrate to ORAS Golang library v2 |\n| #13546 | 2024-12-19 | mattfarina | Update to Go 1.23 |\n| #13499 | 2024-12-06 | gjenkins8 | Shadow ORAS remote.Client interface |\n\n### Other (Backported)\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #30775 | 2025-04-19 | benoittgt | Bump toml |\n| #13533 | 2025-01-24 | althmoha | fix: (toToml) renders int as float |\n| #13581 | 2024-12-31 | ldlb9527 | Upgrade golang.org/x/net to v0.33.0 to address CVE-2024-45338 |\n\n"
  },
  {
    "path": "docs/chart_best_practices/conventions.md",
    "content": "---\ntitle: General Conventions\ndescription: General conventions for charts.\nsidebar_position: 1\n---\n\nThis part of the Best Practices Guide explains general conventions.\n\n## Chart Names\n\nChart names must be lower case letters and numbers. Words _may_ be separated\nwith dashes (-):\n\nExamples:\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nNeither uppercase letters nor underscores can be used in chart names. Dots\nshould not be used in chart names.\n\n## Version Numbers\n\nWherever possible, Helm uses [SemVer 2](https://semver.org) to represent version\nnumbers. (Note that Docker image tags do not necessarily follow SemVer, and are\nthus considered an unfortunate exception to the rule.)\n\nWhen SemVer versions are stored in Kubernetes labels, we conventionally alter\nthe `+` character to an `_` character, as labels do not allow the `+` sign as a\nvalue.\n\n## Formatting YAML\n\nYAML files should be indented using _two spaces_ (and never tabs).\n\n## Usage of the Words Helm and Chart\n\nThere are a few conventions for using the words _Helm_ and _helm_.\n\n- _Helm_ refers to the project as a whole\n- `helm` refers to the client-side command\n- The term `chart` does not need to be capitalized, as it is not a proper noun\n- However, `Chart.yaml` does need to be capitalized because the file name is\n  case sensitive\n\nWhen in doubt, use _Helm_ (with an uppercase 'H').\n\n## Chart templates and namespaces\n\nAvoid defining the `namespace` property in the `metadata` section of your chart\ntemplates. The namespace to apply rendered templates to should be\nspecified in the call to a Kubernetes client via the flag like `--namespace`.\nHelm is rendering your templates as-is and sending them off to the\nKubernetes client, whether it be Helm itself or another\nprogram (kubectl, flux, spinnaker, etc).\n"
  },
  {
    "path": "docs/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Custom Resource Definitions\ndescription: How to handle creating and using CRDs.\nsidebar_position: 7\n---\n\nThis section of the Best Practices Guide deals with creating and using Custom\nResource Definition objects.\n\nWhen working with Custom Resource Definitions (CRDs), it is important to\ndistinguish two different pieces:\n\n- There is a declaration of a CRD. This is the YAML file that has the kind\n  `CustomResourceDefinition`\n- Then there are resources that _use_ the CRD. Say a CRD defines\n  `foo.example.com/v1`. Any resource that has `apiVersion: example.com/v1` and\n  kind `Foo` is a resource that uses the CRD.\n\n## Install a CRD Declaration Before Using the Resource\n\nHelm is optimized to load as many resources into Kubernetes as fast as possible.\nBy design, Kubernetes can take an entire set of manifests and bring them all\nonline (this is called the reconciliation loop).\n\nBut there's a difference with CRDs.\n\nFor a CRD, the declaration must be registered before any resources of that CRDs\nkind(s) can be used. And the registration process sometimes takes a few seconds.\n\n### Method 1: Let `helm` Do It For You\n\nWith the arrival of Helm 3, we removed the old `crd-install` hooks for a more\nsimple methodology. There is now a special directory called `crds` that you can\ncreate in your chart to hold your CRDs. These CRDs are not templated, but will\nbe installed by default when running a `helm install` for the chart. If the CRD\nalready exists, it will be skipped with a warning. If you wish to skip the CRD\ninstallation step, you can pass the `--skip-crds` flag.\n\n#### Some caveats (and explanations)\n\nThere is no support at this time for upgrading or deleting CRDs using Helm. This\nwas an explicit decision after much community discussion due to the danger for\nunintentional data loss. Furthermore, there is currently no community consensus\naround how to handle CRDs and their lifecycle. As this evolves, Helm will add\nsupport for those use cases.\n\nThe `--dry-run` flag of `helm install` and `helm upgrade` is not currently\nsupported for CRDs. The purpose of \"Dry Run\" is to validate that the output of\nthe chart will actually work if sent to the server. But CRDs are a modification\nof the server's behavior. Helm cannot install the CRD on a dry run, so the\ndiscovery client will not know about that Custom Resource (CR), and validation\nwill fail. You can alternatively move the CRDs to their own chart or use `helm\ntemplate` instead.\n\nAnother important point to consider in the discussion around CRD support is how\nthe rendering of templates is handled. One of the distinct disadvantages of the\n`crd-install` method used in Helm 2 was the inability to properly validate\ncharts due to changing API availability (a CRD is actually adding another\navailable API to your Kubernetes cluster). If a chart installed a CRD, `helm` no\nlonger had a valid set of API versions to work against. This is also the reason\nbehind removing templating support from CRDs. With the new `crds` method of CRD\ninstallation, we now ensure that `helm` has completely valid information about\nthe current state of the cluster.\n\n### Method 2: Separate Charts\n\nAnother way to do this is to put the CRD definition in one chart, and then put\nany resources that use that CRD in _another_ chart.\n\nIn this method, each chart must be installed separately. However, this workflow\nmay be more useful for cluster operators who have admin access to a cluster\n"
  },
  {
    "path": "docs/chart_best_practices/dependencies.mdx",
    "content": "---\ntitle: Dependencies\ndescription: Covers best practices for Chart dependencies.\nsidebar_position: 4\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nThis section of the guide covers best practices for `dependencies` declared in\n`Chart.yaml`.\n\n## Versions\n\nWhere possible, use version ranges instead of pinning to an exact version. The\nsuggested default is to use a patch-level version match:\n\n```yaml\nversion: ~1.2.3\n```\n\nThis will match version `1.2.3` and any patches to that release.  In other\nwords, `~1.2.3` is equivalent to `>= 1.2.3, < 1.3.0`\n\nFor the complete version matching syntax, please see the [semver\ndocumentation](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Prerelease versions\n\nThe above versioning constraints will not match on pre-release versions.\nFor example `version: ~1.2.3` will match `version: ~1.2.4` but not `version: ~1.2.3-1`.\nThe following provides a pre-release as well as patch-level matching:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### Repository URLs\n\nWhere possible, use `https://` repository URLs, followed by `http://` URLs.\n\nIf the repository has been added to the repository index file, the repository\nname can be used as an alias of URL. Use `alias:` or `@` followed by repository\nnames.\n\nFile URLs (`file://...`) are considered a \"special case\" for charts that are\nassembled by a fixed deployment pipeline.\n\nWhen using [downloader plugins](/topics/plugins.mdx#downloader-plugins)\nthe URL scheme will be specific to the plugin. Note, a user of the chart will\nneed to have a plugin supporting the scheme installed to update or build the\ndependency.\n\nHelm cannot perform dependency management operations on the dependency when the\n`repository` field is left blank. In that case Helm will assume the dependency\nis in a sub-directory of the `charts` folder with the name being the same as the\n`name` property for the dependency.\n\n## Conditions and Tags\n\nConditions or tags should be added to any dependencies that _are optional_. Note that by default a `condition` is `true`.\n\nThe preferred form of a condition is:\n\n```yaml\ncondition: somechart.enabled\n```\n\nWhere `somechart` is the chart name of the dependency.\n\nWhen multiple subcharts (dependencies) together provide an optional or swappable\nfeature, those charts should share the same tags.\n\nFor example, if both `nginx` and `memcached` together provide performance\noptimizations for the main app in the chart, and are required to both be present\nwhen that feature is enabled, then they should both have a tags section like\nthis:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nThis allows a user to turn that feature on and off with one tag.\n"
  },
  {
    "path": "docs/chart_best_practices/index.mdx",
    "content": "---\ntitle: Best Practices\nsidebar: true\nsidebar_position: 4\n---\n\n# The Chart Best Practices Guide\n\nThis guide covers the Helm Team's considered best practices for creating charts.\nIt focuses on how charts should be structured.\n\nWe focus primarily on best practices for charts that may be publicly deployed.\nWe know that many charts are for internal-use only, and authors of such charts\nmay find that their internal interests override our suggestions here.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "docs/chart_best_practices/labels.md",
    "content": "---\ntitle: Labels and Annotations\ndescription: Covers best practices for using labels and annotations in your Chart.\nsidebar_position: 5\n---\n\nThis part of the Best Practices Guide discusses the best practices for using\nlabels and annotations in your chart.\n\n## Is it a Label or an Annotation?\n\nAn item of metadata should be a label under the following conditions:\n\n- It is used by Kubernetes to identify this resource\n- It is useful to expose to operators for the purpose of querying the system.\n\nFor example, we suggest using `helm.sh/chart: NAME-VERSION` as a label so that\noperators can conveniently find all of the instances of a particular chart to\nuse.\n\nIf an item of metadata is not used for querying, it should be set as an\nannotation instead.\n\nHelm hooks are always annotations.\n\n## Standard Labels\n\nThe following table defines common labels that Helm charts use. Helm itself\nnever requires that a particular label be present. Labels that are marked REC\nare recommended, and _should_ be placed onto a chart for global consistency.\nThose marked OPT are optional. These are idiomatic or commonly in use, but are\nnot relied upon frequently for operational purposes.\n\nName|Status|Description\n-----|------|----------\n`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.\n`helm.sh/chart` | REC | This should be the chart name and version: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`.\n`app.kubernetes.io/managed-by` | REC | This should always be set to `{{ .Release.Service }}`. It is for finding all things managed by Helm.\n`app.kubernetes.io/instance` | REC | This should be the `{{ .Release.Name }}`. It aids in differentiating between different instances of the same application.\n`app.kubernetes.io/version` | OPT | The version of the app and can be set to `{{ .Chart.AppVersion }}`.\n`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`.\n`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.\n\nYou can find more information on the Kubernetes labels, prefixed with\n`app.kubernetes.io`, in the [Kubernetes\ndocumentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).\n"
  },
  {
    "path": "docs/chart_best_practices/pods.md",
    "content": "---\ntitle: Pods and PodTemplates\ndescription: Discusses formatting the Pod and PodTemplate portions in Chart manifests.\nsidebar_position: 6\n---\n\nThis part of the Best Practices Guide discusses formatting the Pod and\nPodTemplate portions in chart manifests.\n\nThe following (non-exhaustive) list of resources use PodTemplates:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Images\n\nA container image should use a fixed tag or the SHA of the image. It should not\nuse the tags `latest`, `head`, `canary`, or other tags that are designed to be\n\"floating\".\n\n\nImages _may_ be defined in the `values.yaml` file to make it easy to swap out\nimages.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nAn image and a tag _may_ be defined in `values.yaml` as two separate fields:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` sets the `imagePullPolicy` to `IfNotPresent` by default by doing\nthe following in your `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nAnd `values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nSimilarly, Kubernetes defaults the `imagePullPolicy` to `IfNotPresent` if it is\nnot defined at all. If you want a value other than `IfNotPresent`, simply update\nthe value in `values.yaml` to your desired value.\n\n\n## PodTemplates Should Declare Selectors\n\nAll PodTemplate sections should specify a selector. For example:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nThis is a good practice because it makes the relationship between the set and\nthe pod.\n\nBut this is even more important for sets like Deployment. Without this, the\n_entire_ set of labels is used to select matching pods, and this will break if\nyou use labels that change, like version or release date.\n"
  },
  {
    "path": "docs/chart_best_practices/rbac.md",
    "content": "---\ntitle: Role-Based Access Control\ndescription: Discusses the creation and formatting of RBAC resources in Chart manifests.\nsidebar_position: 8\n---\n\nThis part of the Best Practices Guide discusses the creation and formatting of\nRBAC resources in chart manifests.\n\nRBAC resources are:\n\n- ServiceAccount (namespaced)\n- Role (namespaced)\n- ClusterRole\n- RoleBinding (namespaced)\n- ClusterRoleBinding\n\n## YAML Configuration\n\nRBAC and ServiceAccount configuration should happen under separate keys. They\nare separate things. Splitting these two concepts out in the YAML disambiguates\nthem and makes this clearer.\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\nThis structure can be extended for more complex charts that require multiple\nServiceAccounts.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## RBAC Resources Should be Created by Default\n\n`rbac.create` should be a boolean value controlling whether RBAC resources are\ncreated.  The default should be `true`.  Users who wish to manage RBAC access\ncontrols themselves can set this value to `false` (in which case see below).\n\n## Using RBAC Resources\n\n`serviceAccount.name` should be set to the name of the ServiceAccount to be used\nby access-controlled resources created by the chart.  If `serviceAccount.create`\nis true, then a ServiceAccount with this name should be created.  If the name is\nnot set, then a name is generated using the `fullname` template, If\n`serviceAccount.create` is false, then it should not be created, but it should\nstill be associated with the same resources so that manually-created RBAC\nresources created later that reference it will function correctly.  If\n`serviceAccount.create` is false and the name is not specified, then the default\nServiceAccount is used.\n\nThe following helper template should be used for the ServiceAccount.\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "docs/chart_best_practices/templates.md",
    "content": "---\ntitle: Templates\ndescription: A closer look at best practices surrounding templates.\nsidebar_position: 3\n---\n\nThis part of the Best Practices Guide focuses on templates.\n\n## Structure of `templates/`\n\nThe `templates/` directory should be structured as follows:\n\n- Template files should have the extension `.yaml` if they produce YAML output.\n  The extension `.tpl` may be used for template files that produce no formatted\n  content.\n- Template file names should use dashed notation (`my-example-configmap.yaml`),\n  not camelcase.\n- Each resource definition should be in its own template file.\n- Template file names should reflect the resource kind in the name. e.g.\n  `foo-pod.yaml`, `bar-svc.yaml`\n\n## Names of Defined Templates\n\nDefined templates (templates created inside a `{{ define }} ` directive) are\nglobally accessible. That means that a chart and all of its subcharts will have\naccess to all of the templates created with `{{ define }}`.\n\nFor that reason, _all defined template names should be namespaced._\n\nCorrect:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nIncorrect:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\nIt is highly recommended that new charts are created via `helm create` command\nas the template names are automatically defined as per this best practice.\n\n## Formatting Templates\n\nTemplates should be indented using _two spaces_ (never tabs).\n\nTemplate directives should have whitespace after the opening  braces and before\nthe closing braces:\n\nCorrect:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nIncorrect:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nTemplates should chomp whitespace where possible:\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nBlocks (such as control structures) may be indented to indicate flow of the\ntemplate code.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nHowever, since YAML is a whitespace-oriented language, it is often not possible\nfor code indentation to follow that convention.\n\n## Whitespace in Generated Templates\n\nIt is preferable to keep the amount of whitespace in generated templates to a\nminimum. In particular, numerous blank lines should not appear adjacent to each\nother. But occasional empty lines (particularly between logical sections) is\nfine.\n\nThis is best:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nThis is okay:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nBut this should be avoided:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Comments (YAML Comments vs. Template Comments)\n\nBoth YAML and Helm Templates have comment markers.\n\nYAML comments:\n```yaml\n# This is a comment\ntype: sprocket\n```\n\nTemplate Comments:\n```yaml\n{{- /*\nThis is a comment.\n*/}}\ntype: frobnitz\n```\n\nTemplate comments should be used when documenting features of a template, such\nas explaining a defined template:\n\n```yaml\n{{- /*\nmychart.shortname provides a 6 char truncated version of the release name.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nInside of templates, YAML comments may be used when it is useful for Helm users\nto (possibly) see the comments during debugging.\n\n```yaml\n# This may cause problems if the value is more than 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nThe comment above is visible when the user runs `helm install --debug`, while\ncomments specified in `{{- /* */}}` sections are not.\n\nBeware of adding `#` YAML comments on template sections containing Helm values that may be required by certain template functions.\n\nFor example, if `required` function is introduced to the above example, and `maxMem` is unset, then a `#` YAML comment will introduce a rendering error.\n\nCorrect: `helm template` does not render this block\n```yaml\n{{- /*\n# This may cause problems if the value is more than 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nIncorrect: `helm template` returns `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n```yaml\n# This may cause problems if the value is more than 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nReview [Debugging Templates](/chart_template_guide/debugging.md) for another example of this behavior of how YAML comments are left intact.\n\n## Use of JSON in Templates and Template Output\n\nYAML is a superset of JSON. In some cases, using a JSON syntax can be more\nreadable than other YAML representations.\n\nFor example, this YAML is closer to the normal YAML method of expressing lists:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nBut it is easier to read when collapsed into a JSON list style:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nUsing JSON for increased legibility is good. However, JSON syntax should not be\nused for representing more complex constructs.\n\nWhen dealing with pure JSON embedded inside of YAML (such as init container\nconfiguration), it is of course appropriate to use the JSON format.\n"
  },
  {
    "path": "docs/chart_best_practices/values.md",
    "content": "---\ntitle: Values\ndescription: Focuses on how you should structure and use your values.\nsidebar_position: 2\n---\n\nThis part of the best practices guide covers using values. In this part of the\nguide, we provide recommendations on how you should structure and use your\nvalues, with focus on designing a chart's `values.yaml` file.\n\n## Naming Conventions\n\nVariable names should begin with a lowercase letter, and words should be\nseparated with camelcase:\n\nCorrect:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nIncorrect:\n\n```yaml\nChicken: true  # initial caps may conflict with built-ins\nchicken-noodle-soup: true # do not use hyphens in the name\n```\n\nNote that all of Helm's built-in variables begin with an uppercase letter to\neasily distinguish them from user-defined values: `.Release.Name`,\n`.Capabilities.KubeVersion`.\n\n## Flat or Nested Values\n\nYAML is a flexible format, and values may be nested deeply or flattened.\n\nNested:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nFlat:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nIn most cases, flat should be favored over nested. The reason for this is that\nit is simpler for template developers and users.\n\n\nFor optimal safety, a nested value must be checked at every level:\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nFor every layer of nesting, an existence check must be done. But for flat\nconfiguration, such checks can be skipped, making the template easier to read\nand use.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\nWhen there are a large number of related variables, and at least one of them is\nnon-optional, nested values may be used to improve readability.\n\n## Make Types Clear\n\nYAML's type coercion rules are sometimes counterintuitive. For example, `foo:\nfalse` is not the same as `foo: \"false\"`. Large integers like `foo: 12345678`\nwill get converted to scientific notation in some cases.\n\nThe easiest way to avoid type conversion errors is to be explicit about strings,\nand implicit about everything else. Or, in short, _quote all strings_.\n\nOften, to avoid the integer casting issues, it is advantageous to store your\nintegers as strings as well, and use `{{ int $value }}` in the template to\nconvert from a string back to an integer.\n\nIn most cases, explicit type tags are respected, so `foo: !!string 1234` should\ntreat `1234` as a string. _However_, the YAML parser consumes tags, so the type\ndata is lost after one parse.\n\n## Consider How Users Will Use Your Values\n\nThere are three potential sources of values:\n\n- A chart's `values.yaml` file\n- A values file supplied by `helm install -f` or `helm upgrade -f`\n- The values passed to a `--set` or `--set-string` flag on `helm install` or\n  `helm upgrade`\n\nWhen designing the structure of your values, keep in mind that users of your\nchart may want to override them via either the `-f` flag or with the `--set`\noption.\n\nSince `--set` is more limited in expressiveness, the first guidelines for\nwriting your `values.yaml` file is _make it easy to override from `--set`_.\n\nFor this reason, it's often better to structure your values file using maps.\n\nDifficult to use with `--set`:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nThe above cannot be expressed with `--set` in Helm `<=2.4`. In Helm 2.5,\naccessing the port on foo is `--set servers[0].port=80`. Not only is it harder\nfor the user to figure out, but it is prone to errors if at some later time the\norder of the `servers` is changed.\n\nEasy to use:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nAccessing foo's port is much more obvious: `--set servers.foo.port=80`.\n\n## Document `values.yaml`\n\nEvery defined property in `values.yaml` should be documented. The documentation\nstring should begin with the name of the property that it describes, and then\ngive at least a one-sentence description.\n\nIncorrect:\n\n```yaml\n# the host name for the webserver\nserverHost: example\nserverPort: 9191\n```\n\nCorrect:\n\n```yaml\n# serverHost is the host name for the webserver\nserverHost: example\n# serverPort is the HTTP listener port for the webserver\nserverPort: 9191\n```\n\nBeginning each comment with the name of the parameter it documents makes it easy\nto grep out documentation, and will enable documentation tools to reliably\ncorrelate doc strings with the parameters they describe.\n"
  },
  {
    "path": "docs/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Accessing Files Inside Templates\ndescription: How to access files from within a template.\nsidebar_position: 10\n---\n\nIn the previous section we looked at several ways to create and access named\ntemplates. This makes it easy to import one template from within another\ntemplate. But sometimes it is desirable to import a _file that is not a\ntemplate_ and inject its contents without sending the contents through the\ntemplate renderer.\n\nHelm provides access to files through the `.Files` object. Before we get going\nwith the template examples, though, there are a few things to note about how\nthis works:\n\n- It is okay to add extra files to your Helm chart. These files will be bundled.\n  Be careful, though. Charts must be smaller than 1M because of the storage\n  limitations of Kubernetes objects.\n- Some files cannot be accessed through the `.Files` object, usually for\n  security reasons.\n  - Files in `templates/` cannot be accessed.\n  - Files excluded using `.helmignore` cannot be accessed.\n  - Files outside of a Helm application [subchart](/chart_template_guide/subcharts_and_globals.md), including those of the parent, cannot be accessed\n- Charts do not preserve UNIX mode information, so file-level permissions will\n  have no impact on the availability of a file when it comes to the `.Files`\n  object.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Basic example](#basic-example)\n- [Path helpers](#path-helpers)\n- [Glob patterns](#glob-patterns)\n- [ConfigMap and Secrets utility functions](#configmap-and-secrets-utility-functions)\n- [Encoding](#encoding)\n- [Lines](#lines)\n\n<!-- tocstop -->\n\n## Basic example\n\nWith those caveats behind, let's write a template that reads three files into\nour ConfigMap. To get started, we will add three files to the chart, putting all\nthree directly inside of the `mychart/` directory.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nEach of these is a simple TOML file (think old-school Windows INI files). We\nknow the names of these files, so we can use a `range` function to loop through\nthem and inject their contents into our ConfigMap.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nThis ConfigMap uses several of the techniques discussed in previous sections.\nFor example, we create a `$files` variable to hold a reference to the `.Files`\nobject. We also use the `tuple` function to create a list of files that we loop\nthrough. Then we print each file name (`{{ . }}: |-`) followed by the contents\nof the file `{{ $files.Get . }}`.\n\nRunning this template will produce a single ConfigMap with the contents of all\nthree files:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Path helpers\n\nWhen working with files, it can be very useful to perform some standard\noperations on the file paths themselves. To help with this, Helm imports many of\nthe functions from Go's [path](https://golang.org/pkg/path/) package for your\nuse. They are all accessible with the same names as in the Go package, but with\na lowercase first letter. For example, `Base` becomes `base`, etc.\n\nThe imported functions are:\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Glob patterns\n\nAs your chart grows, you may find you have a greater need to organize your files\nmore, and so we provide a `Files.Glob(pattern string)` method to assist in\nextracting certain files with all the flexibility of [glob\npatterns](https://godoc.org/github.com/gobwas/glob).\n\n`.Glob` returns a `Files` type, so you may call any of the `Files` methods on\nthe returned object.\n\nFor example, imagine the directory structure:\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nYou have multiple options with Globs:\n\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nOr\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## ConfigMap and Secrets utility functions\n\n(Available Helm 2.0.2 and after)\n\nIt is very common to want to place file content into both ConfigMaps and\nSecrets, for mounting into your pods at run time. To help with this, we provide\na couple utility methods on the `Files` type.\n\nFor further organization, it is especially useful to use these methods in\nconjunction with the `Glob` method.\n\nGiven the directory structure from the [Glob](#glob-patterns) example above:\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Encoding\n\nYou can import a file and have the template base-64 encode it to ensure\nsuccessful transmission:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nThe above will take the same `config1.toml` file we used before and encode it:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Lines\n\nSometimes it is desirable to access each line of a file in your template. We\nprovide a convenient `Lines` method for this.\n\nYou can loop through `Lines` using a `range` function:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nThere is no way to pass files external to the chart during `helm install`. So if\nyou are asking users to supply data, it must be loaded using `helm install -f`\nor `helm install --set`.\n\nThis discussion wraps up our dive into the tools and techniques for writing Helm\ntemplates. In the next section we will see how you can use one special file,\n`templates/NOTES.txt`, to send post-installation instructions to the users of\nyour chart.\n"
  },
  {
    "path": "docs/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Built-in Objects\ndescription: Built-in objects available to templates.\nsidebar_position: 3\n---\n\nObjects are passed into a template from the template engine. And your code can\npass objects around (we'll see examples when we look at the `with` and `range`\nstatements). There are even a few ways to create new objects within your\ntemplates, like with the `tuple` function we'll see later.\n\nObjects can be simple, and have just one value. Or they can contain other\nobjects or functions. For example, the `Release` object contains several objects\n(like `Release.Name`) and the `Files` object has a few functions.\n\nIn the previous section, we use `{{ .Release.Name }}` to insert the name of a\nrelease into a template. `Release` is one of the top-level objects that you can\naccess in your templates.\n\n- `Release`: This object describes the release itself. It has several objects\n  inside of it:\n  - `Release.Name`: The release name\n  - `Release.Namespace`: The namespace to be released into (if the manifest\n    doesn’t override)\n  - `Release.IsUpgrade`: This is set to `true` if the current operation is an\n    upgrade or rollback.\n  - `Release.IsInstall`: This is set to `true` if the current operation is an\n    install.\n  - `Release.Revision`: The revision number for this release. On install, this\n    is 1, and it is incremented with each upgrade and rollback.\n  - `Release.Service`: The service that is rendering the present template. On\n    Helm, this is always `Helm`.\n- `Values`: Values passed into the template from the `values.yaml` file and from\n  user-supplied files. By default, `Values` is empty.\n- `Chart`: The contents of the `Chart.yaml` file. Any data in `Chart.yaml` will\n  be accessible here. For example `{{ .Chart.Name }}-{{ .Chart.Version }}` will\n  print out the `mychart-0.1.0`.\n  - The available fields are listed in the [Charts Guide](/topics/charts.mdx#the-chartyaml-file)\n- `Subcharts`: This provides access to the scope (.Values, .Charts, .Releases etc.)\n  of subcharts to the parent. For example `.Subcharts.mySubChart.myValue` to access\n  the `myValue` in the `mySubChart` chart.\n- `Files`: This provides access to all non-special files in a chart. While you\n  cannot use it to access templates, you can use it to access other files in the\n  chart. See the section [Accessing Files](/chart_template_guide/accessing_files.md) for more.\n  - `Files.Get` is a function for getting a file by name (`.Files.Get\n    config.ini`)\n  - `Files.GetBytes` is a function for getting the contents of a file as an\n    array of bytes instead of as a string. This is useful for things like\n    images.\n  - `Files.Glob` is a function that returns a list of files whose names match\n    the given shell glob pattern.\n  - `Files.Lines` is a function that reads a file line-by-line. This is useful\n    for iterating over each line in a file.\n  - `Files.AsSecrets` is a function that returns the file bodies as Base 64\n    encoded strings.\n  - `Files.AsConfig` is a function that returns file bodies as a YAML map.\n- `Capabilities`: This provides information about what capabilities the\n  Kubernetes cluster supports.\n  - `Capabilities.APIVersions` is a set of versions.\n  - `Capabilities.APIVersions.Has $version` indicates whether a version (e.g.,\n    `batch/v1`) or resource (e.g., `apps/v1/Deployment`) is available on the\n    cluster.\n  - `Capabilities.KubeVersion` and `Capabilities.KubeVersion.Version` is the\n    Kubernetes version.\n  - `Capabilities.KubeVersion.Major` is the Kubernetes major version.\n  - `Capabilities.KubeVersion.Minor` is the Kubernetes minor version.\n  - `Capabilities.HelmVersion` is the object containing the Helm Version details, it is the same output of `helm version`.\n  - `Capabilities.HelmVersion.Version` is the current Helm version in semver format.\n  - `Capabilities.HelmVersion.GitCommit` is the Helm git sha1.\n  - `Capabilities.HelmVersion.GitTreeState` is the state of the Helm git tree.\n  - `Capabilities.HelmVersion.GoVersion` is the version of the Go compiler used.\n- `Template`: Contains information about the current template that is being\n  executed\n  - `Template.Name`: A namespaced file path to the current template (e.g.\n    `mychart/templates/mytemplate.yaml`)\n  - `Template.BasePath`: The namespaced path to the templates directory of the current\n    chart (e.g. `mychart/templates`).\n\nThe built-in values always begin with a capital letter. This is in keeping with\nGo's naming convention. When you create your own names, you are free to use a\nconvention that suits your team. Some teams, like many whose charts you may see\non [Artifact Hub](https://artifacthub.io/packages/search?kind=0), choose to use\nonly initial lower case letters in order to distinguish local names from those\nbuilt-in. In this guide, we follow that convention.\n"
  },
  {
    "path": "docs/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Flow Control\ndescription: A quick overview on the flow structure within templates.\nsidebar_position: 7\n---\n\nControl structures (called \"actions\" in template parlance) provide you, the\ntemplate author, with the ability to control the flow of a template's\ngeneration. Helm's template language provides the following control structures:\n\n- `if`/`else` for creating conditional blocks\n- `with` to specify a scope\n- `range`, which provides a \"for each\"-style loop\n\nIn addition to these, it provides a few actions for declaring and using named\ntemplate segments:\n\n- `define` declares a new named template inside of your template\n- `template` imports a named template\n- `block` declares a special kind of fillable template area\n\nIn this section, we'll talk about `if`, `with`, and `range`. The others are\ncovered in the \"Named Templates\" section later in this guide.\n\n## If/Else\n\nThe first control structure we'll look at is for conditionally including blocks\nof text in a template. This is the `if`/`else` block.\n\nThe basic structure for a conditional looks like this:\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\nNotice that we're now talking about _pipelines_ instead of values. The reason\nfor this is to make it clear that control structures can execute an entire\npipeline, not just evaluate a value.\n\nA pipeline is evaluated as _false_ if the value is:\n\n- a boolean false\n- a numeric zero\n- an empty string\n- a `nil` (empty or null)\n- an empty collection (`map`, `slice`, `tuple`, `dict`, `array`)\n\nUnder all other conditions, the condition is true.\n\nLet's add a simple conditional to our ConfigMap. We'll add another setting if\nthe drink is set to coffee:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nSince we commented out `drink: coffee` in our last example, the output should\nnot include a `mug: \"true\"` flag. But if we add that line back into our\n`values.yaml` file, the output should look like this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Controlling Whitespace\n\nWhile we're looking at conditionals, we should take a quick look at the way\nwhitespace is controlled in templates. Let's take the previous example and\nformat it to be a little easier to read:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nInitially, this looks good. But if we run it through the template engine, we'll\nget an unfortunate result:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nWhat happened? We generated incorrect YAML because of the whitespacing above.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` is incorrectly indented. Let's simply out-dent that one line, and re-run:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nWhen we sent that, we'll get YAML that is valid, but still looks a little funny:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nNotice that we received a few empty lines in our YAML. Why? When the template\nengine runs, it _removes_ the contents inside of `{{` and `}}`, but it leaves\nthe remaining whitespace exactly as is.\n\nYAML ascribes meaning to whitespace, so managing the whitespace becomes pretty\nimportant. Fortunately, Helm templates have a few tools to help.\n\nFirst, the curly brace syntax of template declarations can be modified with\nspecial characters to tell the template engine to chomp whitespace. `{{- ` (with\nthe dash and space added) indicates that whitespace should be chomped left,\nwhile ` -}}` means whitespace to the right should be consumed. _Be careful!\nNewlines are whitespace!_\n\n> Make sure there is a space between the `-` and the rest of your directive.\n> `{{- 3 }}` means \"trim left whitespace and print 3\" while `{{-3 }}` means\n> \"print -3\".\n\nUsing this syntax, we can modify our template to get rid of those new lines:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nJust for the sake of making this point clear, let's adjust the above, and\nsubstitute an `*` for each whitespace that will be deleted following this rule.\nAn `*` at the end of the line indicates a newline character that would be\nremoved\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nKeeping that in mind, we can run our template through Helm and see the result:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nBe careful with the chomping modifiers. It is easy to accidentally do things\nlike this:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nThat will produce `food: \"PIZZA\"mug: \"true\"` because it consumed newlines on both\nsides.\n\n> For the details on whitespace control in templates, see the [Official Go\n> template documentation](https://godoc.org/text/template)\n\nFinally, sometimes it's easier to tell the template system how to indent for you\ninstead of trying to master the spacing of template directives. For that reason,\nyou may sometimes find it useful to use the `indent` function (`{{ indent 2\n\"mug:true\" }}`).\n\n## Modifying scope using `with`\n\nThe next control structure to look at is the `with` action. This controls\nvariable scoping. Recall that `.` is a reference to _the current scope_. So\n`.Values` tells the template to find the `Values` object in the current scope.\n\nThe syntax for `with` is similar to a simple `if` statement:\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\nScopes can be changed. `with` can allow you to set the current scope (`.`) to a\nparticular object. For example, we've been working with `.Values.favorite`.\nLet's rewrite our ConfigMap to alter the `.` scope to point to\n`.Values.favorite`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nNote that this example omits the `mug` output from the previous exercise\nto focus on `with` scoping. The `with` block only executes if\n`.Values.favorite` is not empty, so a separate outer `if` guard is not\nneeded.\n\nNotice that now we can reference `.drink` and `.food` without qualifying them.\nThat is because the `with` statement sets `.` to point to `.Values.favorite`.\nThe `.` is reset to its previous scope after `{{ end }}`.\n\nBut here's a note of caution! Inside of the restricted scope, you will not be\nable to access the other objects from the parent scope using `.`. This, for\nexample, will fail:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nIt will produce an error because `Release.Name` is not inside of the restricted\nscope for `.`. However, if we swap the last two lines, all will work as expected\nbecause the scope is reset after `{{ end }}`.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nOr, we can use `$` for accessing the object `Release.Name` from the parent\nscope. `$` is mapped to the root scope when template execution begins and it\ndoes not change during template execution. The following would work as well:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nAfter looking at `range`, we will take a look at template variables, which offer\none solution to the scoping issue above.\n\n## Looping with the `range` action\n\nMany programming languages have support for looping using `for` loops, `foreach`\nloops, or similar functional mechanisms. In Helm's template language, the way to\niterate through a collection is to use the `range` operator.\n\nTo start, let's add a list of pizza toppings to our `values.yaml` file:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nNow we have a list (called a `slice` in templates) of `pizzaToppings`. We can\nmodify our template to print this list into our ConfigMap:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nWe can use `$` for accessing the list `Values.pizzaToppings` from the parent\nscope. `$` is mapped to the root scope when template execution begins and it\ndoes not change during template execution. The following would work as well:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nLet's take a closer look at the `toppings:` list. The `range` function will\n\"range over\" (iterate through) the `pizzaToppings` list. But now something\ninteresting happens. Just like `with` sets the scope of `.`, so does a `range`\noperator. Each time through the loop, `.` is set to the current pizza topping.\nThat is, the first time, `.` is set to `mushrooms`. The second iteration it is\nset to `cheese`, and so on.\n\nWe can send the value of `.` directly down a pipeline, so when we do `{{ . |\ntitle | quote }}`, it sends `.` to `title` (title case function) and then to\n`quote`. If we run this template, the output will be:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nNow, in this example we've done something tricky. The `toppings: |-` line is\ndeclaring a multi-line string. So our list of toppings is actually not a YAML\nlist. It's a big string. Why would we do this? Because the data in ConfigMaps\n`data` is composed of key/value pairs, where both the key and the value are\nsimple strings. To understand why this is the case, take a look at the\n[Kubernetes ConfigMap docs](https://kubernetes.io/docs/concepts/configuration/configmap/).\nFor us, though, this detail doesn't matter much.\n\n> The `|-` marker in YAML takes a multi-line string. This can be a useful\n> technique for embedding big blocks of data inside of your manifests, as\n> exemplified here.\n\nSometimes it's useful to be able to quickly make a list inside of your template,\nand then iterate over that list. Helm templates have a function to make this\neasy: `tuple`. In computer science, a tuple is a list-like collection of fixed\nsize, but with arbitrary data types. This roughly conveys the way a `tuple` is\nused.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nThe above will produce this:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nIn addition to lists and tuples, `range` can be used to iterate over collections\nthat have a key and a value (like a `map` or `dict`). We'll see how to do that\nin the next section when we introduce template variables.\n"
  },
  {
    "path": "docs/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Appendix: Go Data Types and Templates\"\ndescription: A quick overview on variables in templates.\nsidebar_position: 16\n---\n\nThe Helm template language is implemented in the strongly typed Go programming\nlanguage. For that reason, variables in templates are _typed_. For the most\npart, variables will be exposed as one of the following types:\n\n- string: A string of text\n- bool: a `true` or `false`\n- int: An integer value (there are also 8, 16, 32, and 64 bit signed and\n  unsigned variants of this)\n- float64: a 64-bit floating point value (there are also 8, 16, and 32 bit\n  varieties of this)\n- a byte slice (`[]byte`), often used to hold (potentially) binary data\n- struct: an object with properties and methods\n- a slice (indexed list) of one of the previous types\n- a string-keyed map (`map[string]interface{}`) where the value is one of the\n  previous types\n\nThere are many other types in Go, and sometimes you will have to convert between\nthem in your templates. The easiest way to debug an object's type is to pass it\nthrough `printf \"%T\"` in a template, which will print the type. Also see the\n`typeOf` and `kindOf` functions.\n"
  },
  {
    "path": "docs/chart_template_guide/debugging.md",
    "content": "---\ntitle: Debugging Templates\ndescription: Troubleshooting charts that are failing to deploy.\nsidebar_position: 13\n---\n\nDebugging templates can be tricky because the rendered templates are sent to the\nKubernetes API server, which may reject the YAML files for reasons other than\nformatting.\n\nThere are a few commands that can help you debug.\n\n- `helm lint` is your go-to tool for verifying that your chart follows best\n  practices\n- `helm template --debug` will test rendering chart templates locally.  \n- `helm install --dry-run --debug` will also render your chart locally without\ninstalling it, but will also check if conflicting resources are already running\non the cluster. Setting `--dry-run=server` will additionally execute any\n`lookup` in your chart towards the server.\n- `helm get manifest`: This is a good way to see what templates are installed on\n  the server.\n\nWhen your YAML is failing to parse, but you want to see what is generated, one\neasy way to retrieve the YAML is to comment out the problem section in the\ntemplate, and then re-run `helm install --dry-run --debug`:\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\nThe above will be rendered and returned with the comments intact:\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\nThis provides a quick way of viewing the generated content without YAML parse\nerrors blocking.\n"
  },
  {
    "path": "docs/chart_template_guide/function_list.mdx",
    "content": "---\ntitle: Template Function List\ndescription: A list of template functions available in Helm\nsidebar_position: 6\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm includes many template functions you can take advantage of in templates.\nThey are listed here and broken down by the following categories:\n\n* [Cryptographic and Security](#cryptographic-and-security-functions)\n* [Date](#date-functions)\n* [Dictionaries](#dictionaries-and-dict-functions)\n* [Encoding](#encoding-functions)\n* [File Path](#file-path-functions)\n* [Kubernetes and Chart](#kubernetes-and-chart-functions)\n* [Logic and Flow Control](#logic-and-flow-control-functions)\n* [Lists](#lists-and-list-functions)\n* [Math](#math-functions)\n* [Float Math](#float-math-functions)\n* [Network](#network-functions)\n* [Reflection](#reflection-functions)\n* [Regular Expressions](#regular-expressions)\n* [Semantic Versions](#semantic-version-functions)\n* [String](#string-functions)\n* [Type Conversion](#type-conversion-functions)\n* [URL](#url-functions)\n* [UUID](#uuid-functions)\n\n## Logic and Flow Control Functions\n\nHelm includes numerous logic and control flow functions including [and](#and),\n[coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq),\n[fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne),\n[not](#not), [or](#or), and [required](#required).\n\n### and\n\nReturns the boolean AND of two or more arguments\n(the first empty argument, or the last argument).\n\n```\nand .Arg1 .Arg2\n```\n\n### or\n\nReturns the boolean OR of two or more arguments\n(the first non-empty argument, or the last argument).\n\n```\nor .Arg1 .Arg2\n```\n\n### not\n\nReturns the boolean negation of its argument.\n\n```\nnot .Arg\n```\n\n### eq\n\nReturns the boolean equality of the arguments (e.g., Arg1 == Arg2).\n\n```\neq .Arg1 .Arg2\n```\n\n### ne\n\nReturns the boolean inequality of the arguments (e.g., Arg1 != Arg2)\n\n```\nne .Arg1 .Arg2\n```\n\n### lt\n\nReturns a boolean true if the first argument is less than the second. False is\nreturned otherwise (e.g., Arg1 < Arg2).\n\n```\nlt .Arg1 .Arg2\n```\n\n### le\n\nReturns a boolean true if the first argument is less than or equal to the\nsecond. False is returned otherwise (e.g., Arg1 &lt;= Arg2).\n\n```\nle .Arg1 .Arg2\n```\n\n### gt\n\nReturns a boolean true if the first argument is greater than the second. False\nis returned otherwise (e.g., Arg1 > Arg2).\n\n```\ngt .Arg1 .Arg2\n```\n\n### ge\n\nReturns a boolean true if the first argument is greater than or equal to the\nsecond. False is returned otherwise (e.g., Arg1 >= Arg2).\n\n```\nge .Arg1 .Arg2\n```\n\n### default\n\nTo set a simple default value, use `default`:\n\n```\ndefault \"foo\" .Bar\n```\n\nIn the above, if `.Bar` evaluates to a non-empty value, it will be used. But if\nit is empty, `foo` will be returned instead.\n\nThe definition of \"empty\" depends on type:\n\n- Numeric: 0\n- String: \"\"\n- Lists: `[]`\n- Dicts: `{}`\n- Boolean: `false`\n- And always `nil` (aka null)\n\nFor structs, there is no definition of empty, so a struct will never return the\ndefault.\n\n### required\n\nSpecify values that must be set with `required`:\n\n```\nrequired \"A valid foo is required!\" .Bar\n```\n\nIf `.Bar` is empty or not defined (see [default](#default) on how this is \nevaluated), the template will not render and will return the error message \nsupplied instead.\n\n### empty\n\nThe `empty` function returns `true` if the given value is considered empty, and\n`false` otherwise. The empty values are listed in the `default` section.\n\n```\nempty .Foo\n```\n\nNote that in Go template conditionals, emptiness is calculated for you. Thus,\nyou rarely need `if not empty .Foo`. Instead, just use `if .Foo`.\n\n### fail\n\nUnconditionally returns an empty `string` and an `error` with the specified\ntext. This is useful in scenarios where other conditionals have determined that\ntemplate rendering should fail.\n\n```\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\nThe `coalesce` function takes a list of values and returns the first non-empty\none.\n\n```\ncoalesce 0 1 2\n```\n\nThe above returns `1`.\n\nThis function is useful for scanning through multiple variables or values:\n\n```\ncoalesce .name .parent.name \"Matt\"\n```\n\nThe above will first check to see if `.name` is empty. If it is not, it will\nreturn that value. If it _is_ empty, `coalesce` will evaluate `.parent.name` for\nemptiness. Finally, if both `.name` and `.parent.name` are empty, it will return\n`Matt`.\n\n### ternary\n\nThe `ternary` function takes two values, and a test value. If the test value is\ntrue, the first value will be returned. If the test value is empty, the second\nvalue will be returned. This is similar to the ternary operator in C and other programming languages.\n\n#### true test value\n\n```\nternary \"foo\" \"bar\" true\n```\n\nor\n\n```\ntrue | ternary \"foo\" \"bar\"\n```\n\nThe above returns `\"foo\"`.\n\n#### false test value\n\n```\nternary \"foo\" \"bar\" false\n```\n\nor\n\n```\nfalse | ternary \"foo\" \"bar\"\n```\n\nThe above returns `\"bar\"`.\n\n## String Functions\n\nHelm includes the following string functions: [abbrev](#abbrev),\n[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat),\n[contains](#contains), [hasPrefix](#hasprefix-and-hassuffix),\n[hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials),\n[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent),\n[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf),\n[println](#println), [quote](#quote-and-squote),\n[randAlpha](#randalphanum-randalpha-randnumeric-and-randascii),\n[randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii),\n[randAscii](#randalphanum-randalpha-randnumeric-and-randascii),\n[randNumeric](#randalphanum-randalpha-randnumeric-and-randascii),\n[repeat](#repeat), [replace](#replace), [shuffle](#shuffle),\n[snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr),\n[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall),\n[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc),\n[untitle](#untitle), [upper](#upper), [wrap](#wrap), and [wrapWith](#wrapwith).\n\n### print\n\nReturns a string from the combination of its parts.\n\n```\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\nTypes that are not strings are converted to strings where possible.\n\nNote, when two arguments next to each other are not strings a space is added\nbetween them.\n\n### println\n\nWorks the same way as [print](#print) but adds a new line at the end.\n\n### printf\n\nReturns a string based on a formatting string and the arguments to pass to it in\norder.\n\n```\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\nThe placeholder to use depends on the type for the argument being passed in.\nThis includes:\n\nGeneral purpose:\n\n* `%v` the value in a default format\n  * when printing dicts, the plus flag (%+v) adds field names\n* `%%` a literal percent sign; consumes no value\n\nBoolean:\n\n* `%t` the word true or false\n\nInteger:\n\n* `%b` base 2\n* `%c` the character represented by the corresponding Unicode code point\n* `%d` base 10\n* `%o` base 8\n* `%O` base 8 with 0o prefix\n* `%q` a single-quoted character literal safely escaped\n* `%x` base 16, with lower-case letters for a-f\n* `%X` base 16, with upper-case letters for A-F\n* `%U` Unicode format: U+1234; same as \"U+%04X\"\n\n Floating-point and complex constituents:\n\n* `%b` decimal less scientific notation with exponent a power of two, e.g.\n  -123456p-78\n* `%e` scientific notation, e.g. -1.234456e+78\n* `%E` scientific notation, e.g. -1.234456E+78\n* `%f` decimal point but no exponent, e.g. 123.456\n* `%F` synonym for %f\n* `%g` %e for large exponents, %f otherwise.\n* `%G` %E for large exponents, %F otherwise\n* `%x` hexadecimal notation (with decimal power of two exponent), e.g.\n  -0x1.23abcp+20\n* `%X` upper-case hexadecimal notation, e.g. -0X1.23ABCP+20\n\nString and slice of bytes (treated equivalently with these verbs):\n\n* `%s` the uninterpreted bytes of the string or slice\n* `%q` a double-quoted string safely escaped\n* `%x` base 16, lower-case, two characters per byte\n* `%X` base 16, upper-case, two characters per byte\n\nSlice:\n\n* `%p` address of 0th element in base 16 notation, with leading 0x\n\n### trim\n\nThe `trim` function removes white space from both sides of a string:\n\n```\ntrim \"   hello    \"\n```\n\nThe above produces `hello`\n\n### trimAll\n\nRemoves the given characters from the front and back of a string:\n\n```\ntrimAll \"$\" \"$5.00\"\n```\n\nThe above returns `5.00` (as a string).\n\n### trimPrefix\n\nTrim just the prefix from a string:\n\n```\ntrimPrefix \"-\" \"-hello\"\n```\n\nThe above returns `hello`\n\n### trimSuffix\n\nTrim just the suffix from a string:\n\n```\ntrimSuffix \"-\" \"hello-\"\n```\n\nThe above returns `hello`\n\n### lower\n\nConvert the entire string to lowercase:\n\n```\nlower \"HELLO\"\n```\n\nThe above returns `hello`\n\n### upper\n\nConvert the entire string to uppercase:\n\n```\nupper \"hello\"\n```\n\nThe above returns `HELLO`\n\n### title\n\nConvert to title case:\n\n```\ntitle \"hello world\"\n```\n\nThe above returns `Hello World`\n\n### untitle\n\nRemove title casing. `untitle \"Hello World\"` produces `hello world`.\n\n### repeat\n\nRepeat a string multiple times:\n\n```\nrepeat 3 \"hello\"\n```\n\nThe above returns `hellohellohello`\n\n### substr\n\nGet a substring from a string. It takes three parameters:\n\n- start (int)\n- end (int)\n- string (string)\n\n```\nsubstr 0 5 \"hello world\"\n```\n\nThe above returns `hello`\n\n### nospace\n\nRemove all whitespace from a string.\n\n```\nnospace \"hello w o r l d\"\n```\n\nThe above returns `helloworld`\n\n### trunc\n\nTruncate a string\n\n```\ntrunc 5 \"hello world\"\n```\n\nThe above produces `hello`.\n\n```\ntrunc -5 \"hello world\"\n```\n\nThe above produces `world`.\n\n### abbrev\n\nTruncate a string with ellipses (`...`)\n\nParameters:\n\n- max length\n- the string\n\n```\nabbrev 5 \"hello world\"\n```\n\nThe above returns `he...`, since it counts the width of the ellipses against the\nmaximum length.\n\n### abbrevboth\n\nAbbreviate both sides:\n\n```\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\nthe above produces `...5678...`\n\nIt takes:\n\n- left offset\n- max length\n- the string\n\n### initials\n\nGiven multiple words, take the first letter of each word and combine.\n\n```\ninitials \"First Try\"\n```\n\nThe above returns `FT`\n\n### randAlphaNum, randAlpha, randNumeric, and randAscii\n\nThese four functions generate cryptographically secure (uses ```crypto/rand```)\nrandom strings, but with different base character sets:\n\n- `randAlphaNum` uses `0-9a-zA-Z`\n- `randAlpha` uses `a-zA-Z`\n- `randNumeric` uses `0-9`\n- `randAscii` uses all printable ASCII characters\n\nEach of them takes one parameter: the integer length of the string.\n\n```\nrandNumeric 3\n```\n\nThe above will produce a random string with three digits.\n\n### wrap\n\nWrap text at a given column count:\n\n```\nwrap 80 $someText\n```\n\nThe above will wrap the string in `$someText` at 80 columns.\n\n### wrapWith\n\n`wrapWith` works as `wrap`, but lets you specify the string to wrap with.\n(`wrap` uses `\\n`)\n\n```\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\nThe above produces `Hello World` (where the whitespace is an ASCII tab\ncharacter)\n\n### contains\n\nTest to see if one string is contained inside of another:\n\n```\ncontains \"cat\" \"catch\"\n```\n\nThe above returns `true` because `catch` contains `cat`.\n\n### hasPrefix and hasSuffix\n\nThe `hasPrefix` and `hasSuffix` functions test whether a string has a given\nprefix or suffix:\n\n```\nhasPrefix \"cat\" \"catch\"\n```\n\nThe above returns `true` because `catch` has the prefix `cat`.\n\n### quote and squote\n\nThese functions wrap a string in double quotes (`quote`) or single quotes\n(`squote`).\n\n### cat\n\nThe `cat` function concatenates multiple strings together into one, separating\nthem with spaces:\n\n```\ncat \"hello\" \"beautiful\" \"world\"\n```\n\nThe above produces `hello beautiful world`\n\n### indent\n\nThe `indent` function indents every line in a given string to the specified\nindent width. This is useful when aligning multi-line strings:\n\n```\nindent 4 $lots_of_text\n```\n\nThe above will indent every line of text by 4 space characters.\n\n### nindent\n\nThe `nindent` function is the same as the indent function, but prepends a new\nline to the beginning of the string.\n\n```\nnindent 4 $lots_of_text\n```\n\nThe above will indent every line of text by 4 space characters and add a new\nline to the beginning.\n\n### replace\n\nPerform simple string replacement.\n\nIt takes three arguments:\n\n- string to replace\n- string to replace with\n- source string\n\n```\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\nThe above will produce `I-Am-Henry-VIII`\n\n### plural\n\nPluralize a string.\n\n```\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\nIn the above, if the length of the string is 1, the first argument will be\nprinted (`one anchovy`). Otherwise, the second argument will be printed (`many\nanchovies`).\n\nThe arguments are:\n\n- singular string\n- plural string\n- length integer\n\nNOTE: Helm does not currently support languages with more complex pluralization\nrules. And `0` is considered a plural because the English language treats it as\nsuch (`zero anchovies`).\n\n### snakecase\n\nConvert string from camelCase to snake_case.\n\n```\nsnakecase \"FirstName\"\n```\n\nThis above will produce `first_name`.\n\n### camelcase\n\nConvert string from snake_case to CamelCase\n\n```\ncamelcase \"http_server\"\n```\n\nThis above will produce `HttpServer`.\n\n### kebabcase\n\nConvert string from camelCase to kebab-case.\n\n```\nkebabcase \"FirstName\"\n```\n\nThis above will produce `first-name`.\n\n### swapcase\n\nSwap the case of a string using a word based algorithm.\n\nConversion algorithm:\n\n- Upper case character converts to Lower case\n- Title case character converts to Lower case\n- Lower case character after Whitespace or at start converts to Title case\n- Other Lower case character converts to Upper case\n- Whitespace is defined by unicode.IsSpace(char)\n\n```\nswapcase \"This Is A.Test\"\n```\n\nThis above will produce `tHIS iS a.tEST`.\n\n### shuffle\n\nShuffle a string.\n\n```\nshuffle \"hello\"\n```\n\nThe above will randomize the letters in `hello`, perhaps producing `oelhl`.\n\n## Type Conversion Functions\n\nThe following type conversion functions are provided by Helm:\n\n- `atoi`: Convert a string to an integer.\n- `float64`: Convert to a `float64`.\n- `int`: Convert to an `int` at the system's width.\n- `int64`: Convert to an `int64`.\n- `toDecimal`: Convert a unix octal to a `int64`.\n- `toString`: Convert to a string.\n- `toStrings`: Convert a list, slice, or array to a list of strings.\n- `toJson` (`mustToJson`): Convert list, slice, array, dict, or object to JSON.\n- `toPrettyJson` (`mustToPrettyJson`): Convert list, slice, array, dict, or\n  object to indented JSON.\n- `toRawJson` (`mustToRawJson`): Convert list, slice, array, dict, or object to\n  JSON with HTML characters unescaped.\n- `fromYaml`: Convert a YAML string to an object.\n- `fromJson`: Convert a JSON string to an object.\n- `fromJsonArray`: Convert a JSON array to a list.\n- `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\n- `toYamlPretty`: Convert list, slice, array, dict, or object to indented yaml. Equivalent to `toYaml` but will additionally indent lists by 2 spaces.\n- `toToml` (`mustToToml`): Convert list, slice, array, dict, or object to toml, can be used to copy chunks of toml from any source.\n- `fromYamlArray`: Convert a YAML array to a list.\n\nOnly `atoi` requires that the input be a specific type. The others will attempt\nto convert from any type to the destination type. For example, `int64` can\nconvert floats to ints, and it can also convert strings to ints.\n\n### toStrings\n\nGiven a list-like collection, produce a slice of strings.\n\n```\nlist 1 2 3 | toStrings\n```\n\nThe above converts `1` to `\"1\"`, `2` to `\"2\"`, and so on, and then returns them\nas a list.\n\n### toDecimal\n\nGiven a unix octal permission, produce a decimal.\n\n```\n\"0777\" | toDecimal\n```\n\nThe above converts `0777` to `511` and returns the value as an int64.\n\n### toJson, mustToJson\n\nThe `toJson` function encodes an item into a JSON string. If the item cannot be\nconverted to JSON the function will return an empty string. `mustToJson` will\nreturn an error in case the item cannot be encoded in JSON.\n\n```\ntoJson .Item\n```\n\nThe above returns JSON string representation of `.Item`.\n\n### toPrettyJson, mustToPrettyJson\n\nThe `toPrettyJson` function encodes an item into a pretty (indented) JSON\nstring.\n\n```\ntoPrettyJson .Item\n```\n\nThe above returns indented JSON string representation of `.Item`.\n\n### toRawJson, mustToRawJson\n\nThe `toRawJson` function encodes an item into JSON string with HTML characters\nunescaped.\n\n```\ntoRawJson .Item\n```\n\nThe above returns unescaped JSON string representation of `.Item`.\n\n### fromYaml\n\nThe `fromYaml` function takes a YAML string and returns an object that can be used in templates.\n\n`File at: yamls/person.yaml`\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n```yaml\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\nThe `fromJson` function takes a JSON string and returns an object that can be used in templates.\n\n`File at: jsons/person.json`\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n\n### fromJsonArray\n\nThe `fromJsonArray` function takes a JSON Array and returns a list that can be used in templates.\n\n`File at: jsons/people.json`\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml, toYamlPretty\n\nThe `toYaml` and `toYamlPretty` functions encode an object (list, slice, array, dict, or object) into an indented YAML string.\n\n> Note that `toYamlPretty` is functionally equivalent but will output YAML with additional indents for list elements\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\nThe `fromYamlArray` function takes a YAML Array and returns a list that can be used in templates.\n\n`File at: yamls/people.yml`\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toToml, mustToToml\n\nThe `toToml` function encodes an item into a TOML string. If the item cannot be\nconverted to TOML the function will return an empty string. `mustToToml` will\nreturn an error in case the item cannot be encoded in TOML.\n\n```\ntoToml .Item\n```\n\nThe above returns TOML string representation of `.Item`.\n\n\n## Regular Expressions\n\nHelm includes the following regular expression functions: [regexFind\n(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll\n(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch\n(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll\n(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall),\n[regexReplaceAllLiteral\n(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral),\n[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\nReturns true if the input string contains any match of the regular expression.\n\n```\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\nThe above produces `true`\n\n`regexMatch` panics if there is a problem and `mustRegexMatch` returns an error\nto the template engine if there is a problem.\n\n### regexFindAll, mustRegexFindAll\n\nReturns a slice of all matches of the regular expression in the input string.\nThe last parameter n determines the number of substrings to return, where -1\nmeans return all matches\n\n```\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\nThe above produces `[2 4 6 8]`\n\n`regexFindAll` panics if there is a problem and `mustRegexFindAll` returns an\nerror to the template engine if there is a problem.\n\n### regexFind, mustRegexFind\n\nReturn the first (left most) match of the regular expression in the input string\n\n```\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\nThe above produces `d1`\n\n`regexFind` panics if there is a problem and `mustRegexFind` returns an error to\nthe template engine if there is a problem.\n\n### regexReplaceAll, mustRegexReplaceAll\n\nReturns a copy of the input string, replacing matches of the Regexp with the\nreplacement string replacement. Inside string replacement, $ signs are\ninterpreted as in Expand, so for instance $1 represents the text of the first\nsubmatch. The first argument is `<pattern>`, second is `<input>`,\nand third is `<replacement>`.\n\n```\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\nThe above produces `-W-xxW-`\n\n`regexReplaceAll` panics if there is a problem and `mustRegexReplaceAll` returns\nan error to the template engine if there is a problem.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\nReturns a copy of the input string, replacing matches of the Regexp with the\nreplacement string replacement. The replacement string is substituted directly,\nwithout using Expand. The first argument is `<pattern>`, second is `<input>`,\nand third is `<replacement>`.\n\n```\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\nThe above produces `-${1}-${1}-`\n\n`regexReplaceAllLiteral` panics if there is a problem and\n`mustRegexReplaceAllLiteral` returns an error to the template engine if there is\na problem.\n\n### regexSplit, mustRegexSplit\n\nSlices the input string into substrings separated by the expression and returns\na slice of the substrings between those expression matches. The last parameter\n`n` determines the number of substrings to return, where `-1` means return all\nmatches\n\n```\nregexSplit \"z+\" \"pizza\" -1\n```\n\nThe above produces `[pi a]`\n\n`regexSplit` panics if there is a problem and `mustRegexSplit` returns an error\nto the template engine if there is a problem.\n\n## Cryptographic and Security Functions\n\nHelm provides some advanced cryptographic functions. They include\n[adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert),\n[decryptAES](#decryptaes), [derivePassword](#derivepassword),\n[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey),\n[genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert),\n[htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum), and\n[sha256sum](#sha256sum).\n\n### sha1sum\n\nThe `sha1sum` function receives a string, and computes it's SHA1 digest.\n\n```\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\nThe `sha256sum` function receives a string, and computes it's SHA256 digest.\n\n```\nsha256sum \"Hello world!\"\n```\n\nThe above will compute the SHA 256 sum in an \"ASCII armored\" format that is safe\nto print.\n\n### adler32sum\n\nThe `adler32sum` function receives a string, and computes its Adler-32 checksum.\n\n```\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\nThe `htpasswd` function takes a `username` and `password` and generates a\n`bcrypt` hash of the password. The result can be used for basic authentication\non an [Apache HTTP\nServer](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic).\n\n```\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nNote that it is insecure to store the password directly in the template.\n\n### randBytes\n\nThe randBytes function accepts a count N and generates a cryptographically\nsecure (uses crypto/rand) random sequence of N bytes. The sequence is returned\nas a base64 encoded string.\n\n```\nrandBytes 24\n```\n\n### derivePassword\n\nThe `derivePassword` function can be used to derive a specific password based on\nsome shared \"master password\" constraints. The algorithm for this is [well\nspecified](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf).\n\n```\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nNote that it is considered insecure to store the parts directly in the template.\n\n### genPrivateKey\n\nThe `genPrivateKey` function generates a new private key encoded into a PEM\nblock.\n\nIt takes one of the values for its first param:\n\n- `ecdsa`: Generate an elliptic curve DSA key (P256)\n- `dsa`: Generate a DSA key (L2048N256)\n- `rsa`: Generate an RSA 4096 key\n\n### buildCustomCert\n\nThe `buildCustomCert` function allows customizing the certificate.\n\nIt takes the following string parameters:\n\n- A base64 encoded PEM format certificate\n- A base64 encoded PEM format private key\n\nIt returns a certificate object with the following attributes:\n\n- `Cert`: A PEM-encoded certificate\n- `Key`: A PEM-encoded private key\n\nExample:\n\n```\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\nNote that the returned object can be passed to the `genSignedCert` function to\nsign a certificate using this CA.\n\n### genCA\n\nThe `genCA` function generates a new, self-signed x509 certificate authority.\n\nIt takes the following parameters:\n\n- Subject's common name (cn)\n- Cert validity duration in days\n\nIt returns an object with the following attributes:\n\n- `Cert`: A PEM-encoded certificate\n- `Key`: A PEM-encoded private key\n\nExample:\n\n```\n$ca := genCA \"foo-ca\" 365\n```\n\nNote that the returned object can be passed to the `genSignedCert` function to\nsign a certificate using this CA.\n\n### genSelfSignedCert\n\nThe `genSelfSignedCert` function generates a new, self-signed x509 certificate.\n\nIt takes the following parameters:\n\n- Subject's common name (cn)\n- Optional list of IPs; may be nil\n- Optional list of alternate DNS names; may be nil\n- Cert validity duration in days\n\nIt returns an object with the following attributes:\n\n- `Cert`: A PEM-encoded certificate\n- `Key`: A PEM-encoded private key\n\nExample:\n\n```\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\nThe `genSignedCert` function generates a new, x509 certificate signed by the\nspecified CA.\n\nIt takes the following parameters:\n\n- Subject's common name (cn)\n- Optional list of IPs; may be nil\n- Optional list of alternate DNS names; may be nil\n- Cert validity duration in days\n- CA (see `genCA`)\n\nExample:\n\n```\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\nThe `encryptAES` function encrypts text with AES-256 CBC and returns a base64\nencoded string.\n\n```\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\nThe `decryptAES` function receives a base64 string encoded by the AES-256 CBC\nalgorithm and returns the decoded text.\n\n```\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Date Functions\n\nHelm includes the following date functions you can use in templates:\n[ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify\n(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration),\n[durationRound](#durationround), [htmlDate](#htmldate),\n[htmlDateInZone](#htmldateinzone), [now](#now), [toDate\n(mustToDate)](#todate-musttodate), and [unixEpoch](#unixepoch).\n\n### now\n\nThe current date/time. Use this in conjunction with other date functions.\n\n### ago\n\nThe `ago` function returns duration from time. Now in seconds resolution.\n\n```\nago .CreatedAt\n```\n\nreturns in `time.Duration` String() format\n\n```\n2h34m7s\n```\n\n### date\n\nThe `date` function formats a date.\n\nFormat the date to YEAR-MONTH-DAY:\n\n```\nnow | date \"2006-01-02\"\n```\n\nDate formatting in Go is a [little bit\ndifferent](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\nIn short, take this as the base date:\n\n```\nMon Jan 2 15:04:05 MST 2006\n```\n\nWrite it in the format you want. Above, `2006-01-02` is the same date, but in\nthe format we want.\n\n### dateInZone\n\nSame as `date`, but with a timezone.\n\n```\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\nFormats a given amount of seconds as a `time.Duration`.\n\nThis returns 1m35s\n\n```\nduration \"95\"\n```\n\n### durationRound\n\nRounds a given duration to the most significant unit. Strings and\n`time.Duration` gets parsed as a duration, while a `time.Time` is calculated as\nthe duration since.\n\nThis return 2h\n\n```\ndurationRound \"2h10m5s\"\n```\n\nThis returns 3mo\n\n```\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\nReturns the seconds since the unix epoch for a `time.Time`.\n\n```\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\nThe `dateModify` takes a modification and a date and returns the timestamp.\n\nSubtract an hour and thirty minutes from the current time:\n\n```\nnow | dateModify \"-1.5h\"\n```\n\nIf the modification format is wrong `dateModify` will return the date\nunmodified. `mustDateModify` will return an error otherwise.\n\n### htmlDate\n\nThe `htmlDate` function formats a date for inserting into an HTML date picker\ninput field.\n\n```\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nSame as htmlDate, but with a timezone.\n\n```\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\n`toDate` converts a string to a date. The first argument is the date layout and\nthe second the date string. If the string can't be convert it returns the zero\nvalue. `mustToDate` will return an error in case the string cannot be converted.\n\nThis is useful when you want to convert a string date to another format (using\npipe). The example below converts \"2017-12-31\" to \"31/12/2017\".\n\n```\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Dictionaries and Dict Functions\n\nHelm provides a key/value storage type called a `dict` (short for \"dictionary\",\nas in Python). A `dict` is an _unordered_ type.\n\nThe key to a dictionary **must be a string**. However, the value can be any\ntype, even another `dict` or `list`.\n\nUnlike `list`s, `dict`s are not immutable. The `set` and `unset` functions will\nmodify the contents of a dictionary.\n\nHelm provides the following functions to support working with dicts: [deepCopy\n(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get),\n[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge),\n[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite),\n[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), and\n[values](#values).\n\n### dict\n\nCreating dictionaries is done by calling the `dict` function and passing it a\nlist of pairs.\n\nThe following creates a dictionary with three items:\n\n```\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nGiven a map and a key, get the value from the map.\n\n```\nget $myDict \"name1\"\n```\n\nThe above returns `\"value1\"`\n\nNote that if the key is not found, this operation will simply return `\"\"`. No\nerror will be generated.\n\n### set\n\nUse `set` to add a new key/value pair to a dictionary.\n\n```\n$_ := set $myDict \"name4\" \"value4\"\n```\n\nNote that `set` _returns the dictionary_ (a requirement of Go template\nfunctions), so you may need to trap the value as done above with the `$_`\nassignment.\n\n### unset\n\nGiven a map and a key, delete the key from the map.\n\n```\n$_ := unset $myDict \"name4\"\n```\n\nAs with `set`, this returns the dictionary.\n\nNote that if the key is not found, this operation will simply return. No error\nwill be generated.\n\n### hasKey\n\nThe `hasKey` function returns `true` if the given dict contains the given key.\n\n```\nhasKey $myDict \"name1\"\n```\n\nIf the key is not found, this returns `false`.\n\n### pluck\n\nThe `pluck` function makes it possible to give one key and multiple maps, and\nget a list of all of the matches:\n\n```\npluck \"name1\" $myDict $myOtherDict\n```\n\nThe above will return a `list` containing every found value (`[value1\notherValue1]`).\n\nIf the given key is _not found_ in a map, that map will not have an item in the\nlist (and the length of the returned list will be less than the number of dicts\nin the call to `pluck`).\n\nIf the key is _found_ but the value is an empty value, that value will be\ninserted.\n\nA common idiom in Helm templates is to use `pluck... | first` to get the first\nmatching key out of a collection of dictionaries.\n\n### dig\n\nThe `dig` function traverses a nested set of dicts, selecting keys from a list\nof values. It returns a default value if any of the keys are not found at the\nassociated dict.\n\n```\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\nGiven a dict structured like\n```\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\nthe above would return `\"curator\"`. If the dict lacked even a `user` field,\nthe result would be `\"guest\"`.\n\nDig can be very useful in cases where you'd like to avoid guard clauses,\nespecially since Go's template package's `and` doesn't shortcut. For instance\n`and a.maybeNil a.maybeNil.iNeedThis` will always evaluate\n`a.maybeNil.iNeedThis`, and panic if `a` lacks a `maybeNil` field.)\n\n`dig` accepts its dict argument last in order to support pipelining. For instance:\n```\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\nMerge two or more dictionaries into one, giving precedence to the dest\ndictionary:\n\nGiven:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nwill result in:\n\n```\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n```\n$newdict := merge $dest $source1 $source2\n```\n\nThis is a deep merge operation but not a deep copy operation. Nested objects\nthat are merged are the same instance on both dicts. If you want a deep copy\nalong with the merge, then use the `deepCopy` function along with merging. For\nexample,\n\n```\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` will return an error in case of unsuccessful merge.\n\n### mergeOverwrite, mustMergeOverwrite\n\nMerge two or more dictionaries into one, giving precedence from **right to\nleft**, effectively overwriting values in the dest dictionary:\n\nGiven:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nwill result in:\n\n```\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nThis is a deep merge operation but not a deep copy operation. Nested objects\nthat are merged are the same instance on both dicts. If you want a deep copy\nalong with the merge then use the `deepCopy` function along with merging. For\nexample,\n\n```\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` will return an error in case of unsuccessful merge.\n\n### keys\n\nThe `keys` function will return a `list` of all of the keys in one or more\n`dict` types. Since a dictionary is _unordered_, the keys will not be in a\npredictable order. They can be sorted with `sortAlpha`.\n\n```\nkeys $myDict | sortAlpha\n```\n\nWhen supplying multiple dictionaries, the keys will be concatenated. Use the\n`uniq` function along with `sortAlpha` to get a unique, sorted list of keys.\n\n```\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\nThe `pick` function selects just the given keys out of a dictionary, creating a\nnew `dict`.\n\n```\n$new := pick $myDict \"name1\" \"name2\"\n```\n\nThe above returns `{name1: value1, name2: value2}`\n\n### omit\n\nThe `omit` function is similar to `pick`, except it returns a new `dict` with\nall the keys that _do not_ match the given keys.\n\n```\n$new := omit $myDict \"name1\" \"name3\"\n```\n\nThe above returns `{name2: value2}`\n\n### values\n\nThe `values` function is similar to `keys`, except it returns a new `list` with\nall the values of the source `dict` (only one dictionary is supported).\n\n```\n$vals := values $myDict\n```\n\nThe above returns `list[\"value1\", \"value2\", \"value 3\"]`. Note that the `values`\nfunction gives no guarantees about the result ordering; if you care about this,\nthen use `sortAlpha`.\n\n### deepCopy, mustDeepCopy\n\nThe `deepCopy` and `mustDeepCopy` functions take a value and make a deep copy\nof the value. This includes dicts and other structures. `deepCopy` panics when\nthere is a problem, while `mustDeepCopy` returns an error to the template system\nwhen there is an error.\n\n```\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### A Note on Dict Internals\n\nA `dict` is implemented in Go as a `map[string]interface{}`. Go developers can\npass `map[string]interface{}` values into the context to make them available to\ntemplates as `dict`s.\n\n## Encoding Functions\n\nHelm has the following encoding and decoding functions:\n\n- `b64enc`/`b64dec`: Encode or decode with Base64\n- `b32enc`/`b32dec`: Encode or decode with Base32\n\n## Lists and List Functions\n\nHelm provides a simple `list` type that can contain arbitrary sequential lists\nof data. This is similar to arrays or slices, but lists are designed to be used\nas immutable data types.\n\nCreate a list of integers:\n\n```\n$myList := list 1 2 3 4 5\n```\n\nThe above creates a list of `[1 2 3 4 5]`.\n\nHelm provides the following list functions: [append\n(mustAppend)](#append-mustappend), [chunk](#chunk), [compact\n(mustCompact)](#compact-mustcompact), [concat](#concat), [first\n(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial\n(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast),\n[prepend (mustPrepend)](#prepend-mustprepend), [rest\n(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse),\n[seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq\n(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), and\n[without (mustWithout)](#without-mustwithout).\n\n### first, mustFirst\n\nTo get the head item on a list, use `first`.\n\n`first $myList` returns `1`\n\n`first` panics if there is a problem, while `mustFirst` returns an error to the\ntemplate engine if there is a problem.\n\n### rest, mustRest\n\nTo get the tail of the list (everything but the first item), use `rest`.\n\n`rest $myList` returns `[2 3 4 5]`\n\n`rest` panics if there is a problem, while `mustRest` returns an error to the\ntemplate engine if there is a problem.\n\n### last, mustLast\n\nTo get the last item on a list, use `last`:\n\n`last $myList` returns `5`. This is roughly analogous to reversing a list and\nthen calling `first`.\n\n### initial, mustInitial\n\nThis compliments `last` by returning all _but_ the last element. `initial\n$myList` returns `[1 2 3 4]`.\n\n`initial` panics if there is a problem, while `mustInitial` returns an error to\nthe template engine if there is a problem.\n\n### append, mustAppend\n\nAppend a new item to an existing list, creating a new list.\n\n```\n$new = append $myList 6\n```\n\nThe above would set `$new` to `[1 2 3 4 5 6]`. `$myList` would remain unaltered.\n\n`append` panics if there is a problem, while `mustAppend` returns an error to the\ntemplate engine if there is a problem.\n\n### prepend, mustPrepend\n\nPush an element onto the front of a list, creating a new list.\n\n```\nprepend $myList 0\n```\n\nThe above would produce `[0 1 2 3 4 5]`. `$myList` would remain unaltered.\n\n`prepend` panics if there is a problem, while `mustPrepend` returns an error to\nthe template engine if there is a problem.\n\n### concat\n\nConcatenate arbitrary number of lists into one.\n\n```\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\nThe above would produce `[1 2 3 4 5 6 7 8]`. `$myList` would remain unaltered.\n\n### reverse, mustReverse\n\nProduce a new list with the reversed elements of the given list.\n\n```\nreverse $myList\n```\n\nThe above would generate the list `[5 4 3 2 1]`.\n\n`reverse` panics if there is a problem, while `mustReverse` returns an error to\nthe template engine if there is a problem.\n\n### uniq, mustUniq\n\nGenerate a list with all of the duplicates removed.\n\n```\nlist 1 1 1 2 | uniq\n```\n\nThe above would produce `[1 2]`\n\n`uniq` panics if there is a problem, while `mustUniq` returns an error to the\ntemplate engine if there is a problem.\n\n### without, mustWithout\n\nThe `without` function filters items out of a list.\n\n```\nwithout $myList 3\n```\n\nThe above would produce `[1 2 4 5]`\n\n`without` can take more than one filter:\n\n```\nwithout $myList 1 3 5\n```\n\nThat would produce `[2 4]`\n\n`without` panics if there is a problem, while `mustWithout` returns an error to\nthe template engine if there is a problem.\n\n### has, mustHas\n\nTest to see if a list has a particular element.\n\n```\nhas 4 $myList\n```\n\nThe above would return `true`, while `has \"hello\" $myList` would return false.\n\n`has` panics if there is a problem, while `mustHas` returns an error to the\ntemplate engine if there is a problem.\n\n### compact, mustCompact\n\nAccepts a list and removes entries with empty values.\n\n```\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` will return a new list with the empty (i.e., \"\") item removed.\n\n`compact` panics if there is a problem and `mustCompact` returns an error to the\ntemplate engine if there is a problem.\n\n### index\n\nTo get the nth element of a list, use `index list [n]`. To index into \nmulti-dimensional lists, use `index list [n] [m] ...`\n- `index $myList 0` returns `1`. It is the same as `myList[0]`\n- `index $myList 0 1` would be the same as `myList[0][1]`\n\n### slice, mustSlice\n\nTo get partial elements of a list, use `slice list [n] [m]`. It is equivalent of\n`list[n:m]`.\n\n- `slice $myList` returns `[1 2 3 4 5]`. It is same as `myList[:]`.\n- `slice $myList 3` returns `[4 5]`. It is same as `myList[3:]`.\n- `slice $myList 1 3` returns `[2 3]`. It is same as `myList[1:3]`.\n- `slice $myList 0 3` returns `[1 2 3]`. It is same as `myList[:3]`.\n\n`slice` panics if there is a problem, while `mustSlice` returns an error to the\ntemplate engine if there is a problem.\n\n### until\n\nThe `until` function builds a range of integers.\n\n```\nuntil 5\n```\n\nThe above generates the list `[0, 1, 2, 3, 4]`.\n\nThis is useful for looping with `range $i, $e := until 5`.\n\n### untilStep\n\nLike `until`, `untilStep` generates a list of counting integers. But it allows\nyou to define a start, stop, and step:\n\n```\nuntilStep 3 6 2\n```\n\nThe above will produce `[3 5]` by starting with 3, and adding 2 until it is\nequal or greater than 6. This is similar to Python's `range` function.\n\n### seq\n\nWorks like the bash `seq` command.\n\n* 1 parameter  (end) - will generate all counting integers between 1 and `end`\n  inclusive.\n* 2 parameters (start, end) - will generate all counting integers between\n  `start` and `end` inclusive incrementing or decrementing by 1.\n* 3 parameters (start, step, end) - will generate all counting integers between\n  `start` and `end` inclusive incrementing or decrementing by `step`.\n\n```\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\nTo split a list into chunks of given size, use `chunk size list`. This is useful for pagination.\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\nThis produces list of lists `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`.\n\n## Math Functions\n\nAll math functions operate on `int64` values unless specified otherwise.\n\nThe following math functions are available: [add](#add), [add1](#add1),\n[ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max),\n[min](#min), [mod](#mod), [mul](#mul), [round](#round), and [sub](#sub).\n\n### add\n\nSum numbers with `add`. Accepts two or more inputs.\n\n```\nadd 1 2 3\n```\n\n### add1\n\nTo increment by 1, use `add1`.\n\n### sub\n\nTo subtract, use `sub`.\n\n### div\n\nPerform integer division with `div`.\n\n### mod\n\nModulo with `mod`.\n\n### mul\n\nMultiply with `mul`. Accepts two or more inputs.\n\n```\nmul 1 2 3\n```\n\n### max\n\nReturn the largest of a series of integers.\n\nThis will return `3`:\n\n```\nmax 1 2 3\n```\n\n### min\n\nReturn the smallest of a series of integers.\n\n`min 1 2 3` will return `1`.\n\n### len\n\nReturns the length of the argument as an integer.\n\n```\nlen .Arg\n```\n\n## Float Math Functions\n\nAll math functions operate on `float64` values.\n\n### addf\n\nSum numbers with `addf`\n\nThis will return `5.5`:\n\n```\naddf 1.5 2 2\n```\n\n### add1f\n\nTo increment by 1, use `add1f`\n\n### subf\n\nTo subtract, use `subf`\n\nThis is equivalent to `7.5 - 2 - 3` and will return `2.5`:\n\n```\nsubf 7.5 2 3\n```\n\n### divf\n\nPerform integer division with `divf`\n\nThis is equivalent to `10 / 2 / 4` and will return `1.25`:\n\n```\ndivf 10 2 4\n```\n\n### mulf\n\nMultiply with `mulf`\n\nThis will return `6`:\n\n```\nmulf 1.5 2 2\n```\n\n### maxf\n\nReturn the largest of a series of floats:\n\nThis will return `3`:\n\n```\nmaxf 1 2.5 3\n```\n\n### minf\n\nReturn the smallest of a series of floats.\n\nThis will return `1.5`:\n\n```\nminf 1.5 2 3\n```\n\n### floor\n\nReturns the greatest float value less than or equal to input value.\n\n`floor 123.9999` will return `123.0`.\n\n### ceil\n\nReturns the greatest float value greater than or equal to input value.\n\n`ceil 123.001` will return `124.0`.\n\n### round\n\nReturns a float value with the remainder rounded to the given number to digits\nafter the decimal point.\n\n`round 123.555555 3` will return `123.556`.\n\n## Network Functions\n\nHelm has a single network function, `getHostByName`.\n\nThe `getHostByName` receives a domain name and returns the ip address.\n\n`getHostByName \"www.google.com\"` would return the corresponding ip address of `www.google.com`.\n\nThis function requires the `--enable-dns` option to be passed on the helm command line.\n\n## File Path Functions\n\nWhile Helm template functions do not grant access to the filesystem, they do\nprovide functions for working with strings that follow file path conventions.\nThose include [base](#base), [clean](#clean), [dir](#dir), [ext](#ext), and\n[isAbs](#isabs).\n\n### base\n\nReturn the last element of a path.\n\n```\nbase \"foo/bar/baz\"\n```\n\nThe above prints \"baz\".\n\n### dir\n\nReturn the directory, stripping the last part of the path. So `dir\n\"foo/bar/baz\"` returns `foo/bar`.\n\n### clean\n\nClean up a path.\n\n```\nclean \"foo/bar/../baz\"\n```\n\nThe above resolves the `..` and returns `foo/baz`.\n\n### ext\n\nReturn the file extension.\n\n```\next \"foo.bar\"\n```\n\nThe above returns `.bar`.\n\n### isAbs\n\nTo check whether a file path is absolute, use `isAbs`.\n\n## Reflection Functions\n\nHelm provides rudimentary reflection tools. These help advanced template\ndevelopers understand the underlying Go type information for a particular value.\nHelm is written in Go and is strongly typed. The type system applies within\ntemplates.\n\nGo has several primitive _kinds_, like `string`, `slice`, `int64`, and `bool`.\n\nGo has an open _type_ system that allows developers to create their own types.\n\nHelm provides a set of functions for each via [kind functions](#kind-functions)\nand [type functions](#type-functions). A [deepEqual](#deepequal) function is\nalso provided to compare to values.\n\n### Kind Functions\n\nThere are two Kind functions: `kindOf` returns the kind of an object.\n\n```\nkindOf \"hello\"\n```\n\nThe above would return `string`. For simple tests (like in `if` blocks), the\n`kindIs` function will let you verify that a value is a particular kind:\n\n```\nkindIs \"int\" 123\n```\n\nThe above will return `true`.\n\n### Type Functions\n\nTypes are slightly harder to work with, so there are three different functions:\n\n- `typeOf` returns the underlying type of a value: `typeOf $foo`\n- `typeIs` is like `kindIs`, but for types: `typeIs \"*io.Buffer\" $myVal`\n- `typeIsLike` works as `typeIs`, except that it also dereferences pointers\n\n**Note:** None of these can test whether or not something implements a given\ninterface, since doing so would require compiling the interface in ahead of\ntime.\n\n### deepEqual\n\n`deepEqual` returns true if two values are [\"deeply\nequal\"](https://golang.org/pkg/reflect/#DeepEqual)\n\nWorks for non-primitive types as well (compared to the built-in `eq`).\n\n```\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\nThe above will return `true`.\n\n## Semantic Version Functions\n\nSome version schemes are easily parseable and comparable. Helm provides\nfunctions for working with [SemVer 2](http://semver.org) versions. These include\n[semver](#semver) and [semverCompare](#semvercompare). Below you will also find\ndetails on using ranges for comparisons.\n\n### semver\n\nThe `semver` function parses a string into a Semantic Version:\n\n```\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_If the parser fails, it will cause template execution to halt with an error._\n\nAt this point, `$version` is a pointer to a `Version` object with the following\nproperties:\n\n- `$version.Major`: The major number (`1` above)\n- `$version.Minor`: The minor number (`2` above)\n- `$version.Patch`: The patch number (`3` above)\n- `$version.Prerelease`: The prerelease (`alpha.1` above)\n- `$version.Metadata`: The build metadata (`123` above)\n- `$version.Original`: The original version as a string\n\nAdditionally, you can compare a `Version` to another `version` using the\n`Compare` function:\n\n```\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\nThe above will return `-1`.\n\nThe return values are:\n\n- `-1` if the given semver is greater than the semver whose `Compare` method was\n  called\n- `1` if the version who's `Compare` function was called is greater.\n- `0` if they are the same version\n\n(Note that in SemVer, the `Metadata` field is not compared during version\ncomparison operations.)\n\n### semverCompare\n\nA more robust comparison function is provided as `semverCompare`. This version\nsupports version ranges:\n\n- `semverCompare \"1.2.3\" \"1.2.3\"` checks for an exact match\n- `semverCompare \"~1.2.0\" \"1.2.3\"` checks that the major and minor versions\n  match, and that the patch number of the second version is _greater than or\n  equal to_ the first parameter.\n\nThe SemVer functions use the [Masterminds semver\nlibrary](https://github.com/Masterminds/semver), from the creators of Sprig.\n\n### Basic Comparisons\n\nThere are two elements to the comparisons. First, a comparison string is a list\nof space or comma separated AND comparisons. These are then separated by || (OR)\ncomparisons. For example, `\">= 1.2 < 3.0.0 || >= 4.2.3\"` is looking for a\ncomparison that's greater than or equal to 1.2 and less than 3.0.0 or is greater\nthan or equal to 4.2.3.\n\nThe basic comparisons are:\n\n- `=`: equal (aliased to no operator)\n- `!=`: not equal\n- `>`: greater than\n- `<`: less than\n- `>=`: greater than or equal to\n- `<=`: less than or equal to\n\n### Working With Prerelease Versions\n\nPre-releases, for those not familiar with them, are used for software releases\nprior to stable or generally available releases. Examples of prereleases include\ndevelopment, alpha, beta, and release candidate releases. A prerelease may be a\nversion such as `1.2.3-beta.1`, while the stable release would be `1.2.3`. In the\norder of precedence, prereleases come before their associated releases. In this\nexample `1.2.3-beta.1 < 1.2.3`.\n\nAccording to the Semantic Version specification prereleases may not be API\ncompliant with their release counterpart. It says,\n\n> A pre-release version indicates that the version is unstable and might not\n> satisfy the intended compatibility requirements as denoted by its associated\n> normal version.\n\nSemVer comparisons using constraints without a prerelease comparator will skip\nprerelease versions. For example, `>=1.2.3` will skip prereleases when looking\nat a list of releases, while `>=1.2.3-0` will evaluate and find prereleases.\n\nThe reason for the `0` as a pre-release version in the example comparison is\nbecause pre-releases can only contain ASCII alphanumerics and hyphens (along\nwith `.` separators), per the spec. Sorting happens in ASCII sort order, again\nper the spec. The lowest character is a `0` in ASCII sort order (see an [ASCII\nTable](http://www.asciitable.com/))\n\nUnderstanding ASCII sort ordering is important because A-Z comes before a-z.\nThat means `>=1.2.3-BETA` will return `1.2.3-alpha`. What you might expect from\ncase sensitivity doesn't apply here. This is due to ASCII sort ordering which is\nwhat the spec specifies.\n\n### Hyphen Range Comparisons\n\nThere are multiple methods to handle ranges and the first is hyphens ranges.\nThese look like:\n\n- `1.2 - 1.4.5` which is equivalent to `>= 1.2 <= 1.4.5`\n- `2.3.4 - 4.5` which is equivalent to `>= 2.3.4 <= 4.5`\n\n### Wildcards In Comparisons\n\nThe `x`, `X`, and `*` characters can be used as a wildcard character. This works\nfor all comparison operators. When used on the `=` operator it falls back to the\npatch level comparison (see tilde below). For example,\n\n- `1.2.x` is equivalent to `>= 1.2.0, < 1.3.0`\n- `>= 1.2.x` is equivalent to `>= 1.2.0`\n- `<= 2.x` is equivalent to `< 3`\n- `*` is equivalent to `>= 0.0.0`\n\n### Tilde Range Comparisons (Patch)\n\nThe tilde (`~`) comparison operator is for patch level ranges when a minor\nversion is specified and major level changes when the minor number is missing.\nFor example,\n\n- `~1.2.3` is equivalent to `>= 1.2.3, < 1.3.0`\n- `~1` is equivalent to `>= 1, < 2`\n- `~2.3` is equivalent to `>= 2.3, < 2.4`\n- `~1.2.x` is equivalent to `>= 1.2.0, < 1.3.0`\n- `~1.x` is equivalent to `>= 1, < 2`\n\n### Caret Range Comparisons (Major)\n\nThe caret (`^`) comparison operator is for major level changes once a stable\n(1.0.0) release has occurred. Prior to a 1.0.0 release the minor versions acts\nas the API stability level. This is useful when comparisons of API versions as a\nmajor change is API breaking. For example,\n\n- `^1.2.3` is equivalent to `>= 1.2.3, < 2.0.0`\n- `^1.2.x` is equivalent to `>= 1.2.0, < 2.0.0`\n- `^2.3` is equivalent to `>= 2.3, < 3`\n- `^2.x` is equivalent to `>= 2.0.0, < 3`\n- `^0.2.3` is equivalent to `>=0.2.3 <0.3.0`\n- `^0.2` is equivalent to `>=0.2.0 <0.3.0`\n- `^0.0.3` is equivalent to `>=0.0.3 <0.0.4`\n- `^0.0` is equivalent to `>=0.0.0 <0.1.0`\n- `^0` is equivalent to `>=0.0.0 <1.0.0`\n\n## URL Functions\n\nHelm includes the [urlParse](#urlparse), [urlJoin](#urljoin), and\n[urlquery](#urlquery) functions enabling you to work with URL parts.\n\n### urlParse\n\nParses string for URL and produces dict with URL parts\n\n```\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\nThe above returns a dict, containing URL object:\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nThis is implemented used the URL packages from the Go standard library. For more\ninfo, check https://golang.org/pkg/net/url/#URL\n\n### urlJoin\n\nJoins map (produced by `urlParse`) to produce URL string\n\n```\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\nThe above returns the following string:\n```\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nReturns the escaped version of the value passed in as an argument so that it is\nsuitable for embedding in the query portion of a URL.\n\n```\n$var := urlquery \"string for query\"\n```\n\n## UUID Functions\n\nHelm can generate UUID v4 universally unique IDs.\n\n```\nuuidv4\n```\n\nThe above returns a new UUID of the v4 (randomly generated) type.\n\n## Kubernetes and Chart Functions\n\nHelm includes functions for working with Kubernetes including\n[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas),\n[Files](#file-functions), and [lookup](#lookup).\n\n### lookup\n\n`lookup` is used to look up resource in a running cluster. When used with the\n`helm template` command it always returns an empty response.\n\nYou can find more detail in the [documentation on the lookup\nfunction](/chart_template_guide/functions_and_pipelines.mdx#using-the-lookup-function).\n\n### .Capabilities.APIVersions.Has\n\nReturns if an API version or resource is available in a cluster.\n\n```\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\nMore information is available on the [built-in object\ndocumentation](/chart_template_guide/builtin_objects.md).\n\n### File Functions\n\nThere are several functions that enable you to get to non-special files within a\nchart. For example, to access application configuration files. These are\ndocumented in [Accessing Files Inside Templates](/chart_template_guide/accessing_files.md).\n\n_Note, the documentation for many of these functions come from\n[Sprig](https://github.com/Masterminds/sprig). Sprig is a template function\nlibrary available to Go applications._\n"
  },
  {
    "path": "docs/chart_template_guide/functions_and_pipelines.mdx",
    "content": "---\ntitle: Template Functions and Pipelines\ndescription: Using functions in templates.\nsidebar_position: 5\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nSo far, we've seen how to place information into a template. But that\ninformation is placed into the template unmodified. Sometimes we want to\ntransform the supplied data in a way that makes it more usable to us.\n\nLet's start with a best practice: When injecting strings from the `.Values`\nobject into the template, we ought to quote these strings. We can do that by\ncalling the `quote` function in the template directive:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nTemplate functions follow the syntax `functionName arg1 arg2...`. In the snippet\nabove, `quote .Values.favorite.drink` calls the `quote` function and passes it a\nsingle argument.\n\nHelm has over 60 available functions. Some of them are defined by the [Go\ntemplate language](https://godoc.org/text/template) itself. Most of the others\nare part of the [Sprig template library](https://masterminds.github.io/sprig/).\nWe'll see many of them as we progress through the examples.\n\n> While we talk about the \"Helm template language\" as if it is Helm-specific, it\n> is actually a combination of the Go template language, some extra functions,\n> and a variety of wrappers to expose certain objects to the templates. Many\n> resources on Go templates may be helpful as you learn about templating.\n\n## Pipelines\n\nOne of the powerful features of the template language is its concept of\n_pipelines_. Drawing on a concept from UNIX, pipelines are a tool for chaining\ntogether a series of template commands to compactly express a series of\ntransformations. In other words, pipelines are an efficient way of getting\nseveral things done in sequence. Let's rewrite the above example using a\npipeline.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nIn this example, instead of calling `quote ARGUMENT`, we inverted the order. We\n\"sent\" the argument to the function using a pipeline (`|`):\n`.Values.favorite.drink | quote`. Using pipelines, we can chain several\nfunctions together:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Inverting the order is a common practice in templates. You will see `.val |\n> quote` more often than `quote .val`. Either practice is fine.\n\nWhen evaluated, that template will produce this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nNote that our original `pizza` has now been transformed to `\"PIZZA\"`.\n\nWhen pipelining arguments like this, the result of the first evaluation\n(`.Values.favorite.drink`) is sent as the _last argument to the function_. We\ncan modify the drink example above to illustrate with a function that takes two\narguments: `repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nThe `repeat` function will echo the given string the given number of times, so\nwe will get this for output:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Using the `default` function\n\nOne function frequently used in templates is the `default` function: `default\nDEFAULT_VALUE GIVEN_VALUE`. This function allows you to specify a default value\ninside of the template, in case the value is omitted. Let's use it to modify the\ndrink example above:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nIf we run this as normal, we'll get our `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nNow, we will remove the favorite drink setting from `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nNow re-running `helm install --dry-run --debug fair-worm ./mychart` will produce\nthis YAML:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nIn an actual chart, all static default values should live in the `values.yaml`,\nand should not be repeated using the `default` command (otherwise they would be\nredundant). However, the `default` command is perfect for computed values, which\ncannot be declared inside `values.yaml`. For example:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nIn some places, an `if` conditional guard may be better suited than `default`.\nWe'll see those in the next section.\n\nTemplate functions and pipelines are a powerful way to transform information and\nthen insert it into your YAML. But sometimes it's necessary to add some template\nlogic that is a little more sophisticated than just inserting a string. In the\nnext section we will look at the control structures provided by the template\nlanguage.\n\n## Using the `lookup` function\n\nThe `lookup` function can be used to _look up_ resources in a running cluster.\nThe synopsis of the lookup function is `lookup apiVersion, kind, namespace, name\n-> resource or resource list`.\n\n| parameter  | type   |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\nBoth `name` and `namespace` are optional and can be passed as an empty string\n(`\"\"`). However, if you're working with a namespace-scoped resource, both `name`\nand `namespace` must be specified.\n\nThe following combination of parameters are possible:\n\n| Behavior                               | Lookup function                            |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\nWhen `lookup` returns an object, it will return a dictionary. This dictionary\ncan be further navigated to extract specific values.\n\nThe following example will return the annotations present for the `mynamespace`\nobject:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nWhen `lookup` returns a list of objects, it is possible to access the object\nlist via the `items` field:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* do something with each service */}}\n{{ end }}\n```\n\nWhen no object is found, an empty value is returned. This can be used to check\nfor the existence of an object.\n\nThe `lookup` function uses Helm's existing Kubernetes connection configuration\nto query Kubernetes. If any error is returned when interacting with calling the\nAPI server (for example due to lack of permission to access a resource), Helm's\ntemplate processing will fail.\n\nKeep in mind that Helm is not supposed to contact the Kubernetes API Server during \na `helm template|install|upgrade|delete|rollback --dry-run` operation. To test `lookup` \nagainst a running cluster, `helm template|install|upgrade|delete|rollback --dry-run=server`\nshould be used instead to allow cluster connection.\n\n## Operators are functions\n\nFor templates, the operators (`eq`, `ne`, `lt`, `gt`, `and`, `or` and so on) are\nall implemented as functions. In pipelines, operations can be grouped with\nparentheses (`(`, and `)`).\n\nNow we can turn from functions and pipelines to flow control with conditions,\nloops, and scope modifiers.\n"
  },
  {
    "path": "docs/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Getting Started\ndescription: A quick guide on Chart templates.\nsidebar_position: 2\n---\n\nIn this section of the guide, we'll create a chart and then add a first\ntemplate. The chart we created here will be used throughout the rest of the\nguide.\n\nTo get going, let's take a brief look at a Helm chart.\n\n## Charts\n\nAs described in the [Charts Guide](/topics/charts.mdx), Helm charts are\nstructured like this:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nThe `templates/` directory is for template files. When Helm evaluates a chart,\nit will send all of the files in the `templates/` directory through the template\nrendering engine. It then collects the results of those templates and sends them\non to Kubernetes.\n\nThe `values.yaml` file is also important to templates. This file contains the\n_default values_ for a chart. These values may be overridden by users during\n`helm install` or `helm upgrade`.\n\nThe `Chart.yaml` file contains a description of the chart. You can access it\nfrom within a template.\n\nThe `charts/` directory _may_ contain other charts\n(which we call _subcharts_). Later in this guide we will see how those work when\nit comes to template rendering.\n\n## A Starter Chart\n\nFor this guide, we'll create a simple chart called `mychart`, and then we'll\ncreate some templates inside of the chart.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### A Quick Glimpse of `mychart/templates/`\n\nIf you take a look at the `mychart/templates/` directory, you'll notice a few\nfiles already there.\n\n- `NOTES.txt`: The \"help text\" for your chart. This will be displayed to your\n  users when they run `helm install`.\n- `deployment.yaml`: A basic manifest for creating a Kubernetes\n  [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n- `service.yaml`: A basic manifest for creating a [service\n  endpoint](https://kubernetes.io/docs/concepts/services-networking/service/) for your deployment\n- `_helpers.tpl`: A place to put template helpers that you can re-use throughout\n  the chart\n\nAnd what we're going to do is... _remove them all!_ That way we can work through\nour tutorial from scratch. We'll actually create our own `NOTES.txt` and\n`_helpers.tpl` as we go.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nWhen you're writing production grade charts, having basic versions of these\ncharts can be really useful. So in your day-to-day chart authoring, you probably\nwon't want to remove them.\n\n## A First Template\n\nThe first template we are going to create will be a `ConfigMap`. In Kubernetes,\na ConfigMap is simply an object for storing configuration data. Other things,\nlike pods, can access the data in a ConfigMap.\n\nBecause ConfigMaps are basic resources, they make a great starting point for us.\n\nLet's begin by creating a file called `mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**TIP:** Template names do not follow a rigid naming pattern. However, we\nrecommend using the extension `.yaml` for YAML files and `.tpl` for helpers.\n\nThe YAML file above is a bare-bones ConfigMap, having the minimal necessary\nfields. By virtue of the fact that this file is in the `mychart/templates/`\ndirectory, it will be sent through the template engine.\n\nIt is just fine to put a plain YAML file like this in the `mychart/templates/`\ndirectory. When Helm reads this template, it will simply send it to Kubernetes\nas-is.\n\nWith this simple template, we now have an installable chart. And we can install\nit like this:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nUsing Helm, we can retrieve the release and see the actual template that was\nloaded.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nThe `helm get manifest` command takes a release name (`full-coral`) and prints\nout all of the Kubernetes resources that were uploaded to the server. Each file\nbegins with `---` to indicate the start of a YAML document, and then is followed\nby an automatically generated comment line that tells us what template file\ngenerated this YAML document.\n\nFrom there on, we can see that the YAML data is exactly what we put in our\n`configmap.yaml` file.\n\nNow we can uninstall our release: `helm uninstall full-coral`.\n\n### Adding a Simple Template Call\n\nHard-coding the `name:` into a resource is usually considered to be bad\npractice. Names should be unique to a release. So we might want to generate a\nname field by inserting the release name.\n\n**TIP:** The `name:` field is limited to 63 characters because of limitations to\nthe DNS system. For that reason, release names are limited to 53 characters.\nKubernetes 1.3 and earlier limited to only 24 characters (thus 14 character\nnames).\n\nLet's alter `configmap.yaml` accordingly.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nThe big change comes in the value of the `name:` field, which is now\n`{{ .Release.Name }}-configmap`.\n\n> A template directive is enclosed in `{{` and `}}` blocks.\n\nThe template directive `{{ .Release.Name }}` injects the release name into the\ntemplate. The values that are passed into a template can be thought of as\n_namespaced objects_, where a dot (`.`) separates each namespaced element.\n\nThe leading dot before `Release` indicates that we start with the top-most\nnamespace for this scope (we'll talk about scope in a bit). So we could read\n`.Release.Name` as \"start at the top namespace, find the `Release` object, then\nlook inside of it for an object called `Name`\".\n\nThe `Release` object is one of the built-in objects for Helm, and we'll cover it\nin more depth later. But for now, it is sufficient to say that this will display\nthe release name that the library assigns to our release.\n\nNow when we install our resource, we'll immediately see the result of using this\ntemplate directive:\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nYou can run `helm get manifest clunky-serval` to see the entire generated YAML.\n\nNote that the ConfigMap inside Kubernetes name is `clunky-serval-configmap`\ninstead of `mychart-configmap` previously.\n\nAt this point, we've seen templates at their most basic: YAML files that have\ntemplate directives embedded in `{{` and `}}`. In the next part, we'll take a\ndeeper look into templates. But before moving on, there's one quick trick that\ncan make building templates faster: When you want to test the template\nrendering, but not actually install anything, you can use `helm install --debug\n--dry-run goodly-guppy ./mychart`. This will render the templates. But instead\nof installing the chart, it will return the rendered template to you so you can\nsee the output:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nUsing `--dry-run` will make it easier to test your code, but it won't ensure\nthat Kubernetes itself will accept the templates you generate. It's best not to\nassume that your chart will install just because `--dry-run` works.\n\nIn the [Chart Template Guide](/chart_template_guide/index.mdx), we take the basic chart we defined\nhere and explore the Helm template language in detail. And we'll get started\nwith built-in objects.\n"
  },
  {
    "path": "docs/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: The .helmignore file\ndescription: The `.helmignore` file is used to specify files you don't want to include in your helm chart.\nsidebar_position: 12\n---\n\nThe `.helmignore` file is used to specify files you don't want to include in\nyour helm chart.\n\nIf this file exists, the `helm package` command will ignore all the files that\nmatch the pattern specified in the `.helmignore` file while packaging your\napplication.\n\nThis can help in avoiding unnecessary or sensitive files or directories from\nbeing added in your helm chart.\n\nThe `.helmignore` file supports Unix shell glob matching, relative path\nmatching, and negation (prefixed with !). Only one pattern per line is\nconsidered.\n\nHere is an example `.helmignore` file:\n\n```\n# comment\n\n# Match any file or path named .helmignore\n.helmignore\n\n# Match any file or path named .git\n.git\n\n# Match any text file\n*.txt\n\n# Match only directories named mydir\nmydir/\n\n# Match only text files in the top-level directory\n/*.txt\n\n# Match only the file foo.txt in the top-level directory\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt\na[b-d].txt\n\n# Match any file under subdir matching temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nSome notable differences from .gitignore:\n- The '**' syntax is not supported.\n- The globbing library is Go's 'filepath.Match', not fnmatch(3)\n- Trailing spaces are always ignored (there is no supported escape sequence)\n- There is no support for '\\!' as a special leading sequence.\n- It does not exclude itself by default, you have to add an explicit entry for `.helmignore`\n\n\n**We'd love your help** making this document better. To add, correct, or remove\ninformation, [file an issue](https://github.com/helm/helm-www/issues) or send us a\npull request.\n"
  },
  {
    "path": "docs/chart_template_guide/index.mdx",
    "content": "---\ntitle: Chart Template Guide\nsidebar_position: 5\n---\n\n# The Chart Template Developer's Guide\n\nThis guide provides an introduction to Helm's chart templates, with emphasis on\nthe template language.\n\nTemplates generate manifest files, which are YAML-formatted resource\ndescriptions that Kubernetes can understand. We'll look at how templates are\nstructured, how they can be used, how to write Go templates, and how to debug\nyour work.\n\nThis guide focuses on the following concepts:\n\n- The Helm template language\n- Using values\n- Techniques for working with templates\n\nThis guide is oriented toward learning the ins and outs of the Helm template\nlanguage. Other guides provide introductory material, examples, and best\npractices.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "docs/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Named Templates\ndescription: How to define named templates.\nsidebar_position: 9\n---\n\nIt is time to move beyond one template, and begin to create others. In this\nsection, we will see how to define _named templates_ in one file, and then use\nthem elsewhere. A _named template_ (sometimes called a _partial_ or a\n_subtemplate_) is simply a template defined inside of a file, and given a name.\nWe'll see two ways to create them, and a few different ways to use them.\n\nIn the [Flow Control](/chart_template_guide/control_structures.md) section we introduced three actions\nfor declaring and managing templates: `define`, `template`, and `block`. In this\nsection, we'll cover those three actions, and also introduce a special-purpose\n`include` function that works similarly to the `template` action.\n\nAn important detail to keep in mind when naming templates: **template names are\nglobal**. If you declare two templates with the same name, whichever one is\nloaded last will be the one used. Because templates in subcharts are compiled\ntogether with top-level templates, you should be careful to name your templates\nwith _chart-specific names_.\n\nOne popular naming convention is to prefix each defined template with the name\nof the chart: `{{ define \"mychart.labels\" }}`. By using the specific chart name\nas a prefix we can avoid any conflicts that may arise due to two different\ncharts that implement templates of the same name.\n\nThis behavior also applies to different versions of a chart. If you have\n`mychart` version `1.0.0` that defines a template one way, and a `mychart`\nversion `2.0.0` that modifies the existing named template, it will use the one\nthat was loaded last. You can work around this issue by also adding a version\nin the name of the chart: `{{ define \"mychart.v1.labels\" }}` and\n`{{ define \"mychart.v2.labels\" }}`.\n\n## Partials and `_` files\n\nSo far, we've used one file, and that one file has contained a single template.\nBut Helm's template language allows you to create named embedded templates, that\ncan be accessed by name elsewhere.\n\nBefore we get to the nuts-and-bolts of writing those templates, there is file\nnaming convention that deserves mention:\n\n* Most files in `templates/` are treated as if they contain Kubernetes manifests\n* The `NOTES.txt` is one exception\n* But files whose name begins with an underscore (`_`) are assumed to _not_ have\n  a manifest inside. These files are not rendered to Kubernetes object\n  definitions, but are available everywhere within other chart templates for\n  use.\n\nThese files are used to store partials and helpers. In fact, when we first\ncreated `mychart`, we saw a file called `_helpers.tpl`. That file is the default\nlocation for template partials.\n\n## Declaring and using templates with `define` and `template`\n\nThe `define` action allows us to create a named template inside of a template\nfile. Its syntax goes like this:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # body of template here\n{{- end }}\n```\n\nFor example, we can define a template to encapsulate a Kubernetes block of\nlabels:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nNow we can embed this template inside of our existing ConfigMap, and then\ninclude it with the `template` action:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nWhen the template engine reads this file, it will store away the reference to\n`mychart.labels` until `template \"mychart.labels\"` is called. Then it will\nrender that template inline. So the result will look like this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nNote: a `define` does not produce output unless it is called with a template,\nas in this example.\n\nConventionally, Helm charts put these templates inside of a partials file,\nusually `_helpers.tpl`. Let's move this function there:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nBy convention, `define` functions should have a simple documentation block\n(`{{/* ... */}}`) describing what they do.\n\nEven though this definition is in `_helpers.tpl`, it can still be accessed in\n`configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nAs mentioned above, **template names are global**. As a result of this, if two\ntemplates are declared with the same name the last occurrence will be the one\nthat is used. Since templates in subcharts are compiled together with top-level\ntemplates, it is best to name your templates with _chart specific names_. A\npopular naming convention is to prefix each defined template with the name of\nthe chart: `{{ define \"mychart.labels\" }}`.\n\n## Setting the scope of a template\n\nIn the template we defined above, we did not use any objects. We just used\nfunctions. Let's modify our defined template to include the chart name and chart\nversion:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nIf we render this, we will get an error like this:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nTo see what rendered, re-run with `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`.\nThe result will not be what we expect:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\nWhat happened to the name and version? They weren't in the scope for our defined\ntemplate. When a named template (created with `define`) is rendered, it will\nreceive the scope passed in by the `template` call. In our example, we included\nthe template like this:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nNo scope was passed in, so within the template we cannot access anything in `.`.\nThis is easy enough to fix, though. We simply pass a scope to the template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nNote that we pass `.` at the end of the `template` call. We could just as easily\npass `.Values` or `.Values.favorite` or whatever scope we want. But what we want\nis the top-level scope. In the context of the named template, `$` will refer\nto the scope you passed in and not some global scope.\n\nNow when we execute this template with `helm install --dry-run --debug\nplinking-anaco ./mychart`, we get this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nNow `{{ .Chart.Name }}` resolves to `mychart`, and `{{ .Chart.Version }}`\nresolves to `0.1.0`.\n\n## The `include` function\n\nSay we've defined a simple template that looks like this:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nNow say I want to insert this both into the `labels:` section of my template,\nand also the `data:` section:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nIf we render this, we will get an error like this:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nTo see what rendered, re-run with `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`.\nThe output will not be what we expect:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nNote that the indentation on `app_version` is wrong in both places. Why? Because\nthe template that is substituted in has the text aligned to the left. Because\n`template` is an action, and not a function, there is no way to pass the output\nof a `template` call to other functions; the data is simply inserted inline.\n\nTo work around this case, Helm provides an alternative to `template` that will\nimport the contents of a template into the present pipeline where it can be\npassed along to other functions in the pipeline.\n\nHere's the example above, corrected to use `indent` to indent the `mychart.app`\ntemplate correctly:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nNow the produced YAML is correctly indented for each section:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> It is considered preferable to use `include` over `template` in Helm templates\n> simply so that the output formatting can be handled better for YAML documents.\n\nSometimes we want to import content, but not as templates. That is, we want to\nimport files verbatim. We can achieve this by accessing files through the\n`.Files` object described in the next section.\n"
  },
  {
    "path": "docs/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Creating a NOTES.txt File\ndescription: How to provide instructions to your Chart users.\nsidebar_position: 10\n---\n\nIn this section we are going to look at Helm's tool for providing instructions\nto your chart users. At the end of a `helm install` or `helm upgrade`, Helm can\nprint out a block of helpful information for users. This information is highly\ncustomizable using templates.\n\nTo add installation notes to your chart, simply create a `templates/NOTES.txt`\nfile. This file is plain text, but it is processed like a template, and has\nall the normal template functions and objects available.\n\nLet's create a simple `NOTES.txt` file:\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nNow if we run `helm install rude-cardinal ./mychart` we will see this message at\nthe bottom:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nUsing `NOTES.txt` this way is a great way to give your users detailed\ninformation about how to use their newly installed chart. Creating a `NOTES.txt`\nfile is strongly recommended, though it is not required.\n"
  },
  {
    "path": "docs/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Subcharts and Global Values\ndescription: Interacting with a subchart's and global values.\nsidebar_position: 11\n---\n\nTo this point we have been working only with one chart. But charts can have\ndependencies, called _subcharts_, that also have their own values and templates.\nIn this section we will create a subchart and see the different ways we can\naccess values from within templates.\n\nBefore we dive into the code, there are a few important details to learn about application subcharts.\n\n1. A subchart is considered \"stand-alone\", which means a subchart can never\n   explicitly depend on its parent chart.\n2. For that reason, a subchart cannot access the values of its parent.\n3. A parent chart can override values for subcharts.\n4. Helm has a concept of _global values_ that can be accessed by all charts.\n\n> These limitations do not all necessarily apply to [library charts](/topics/library_charts.md), which are designed to provide standardized helper functionality.\n\nAs we walk through the examples in this section, many of these concepts will\nbecome clearer.\n\n## Creating a Subchart\n\nFor these exercises, we'll start with the `mychart/` chart we created at the\nbeginning of this guide, and we'll add a new chart inside of it.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nNotice that just as before, we deleted all of the base templates so that we can\nstart from scratch. In this guide, we are focused on how templates work, not on\nmanaging dependencies. But the [Charts Guide](/topics/charts.mdx)\nhas more information on how subcharts work.\n\n## Adding Values and a Template to the Subchart\n\nNext, let's create a simple template and values file for our `mysubchart` chart.\nThere should already be a `values.yaml` in `mychart/charts/mysubchart`. We'll\nset it up like this:\n\n```yaml\ndessert: cake\n```\n\nNext, we'll create a new ConfigMap template in\n`mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nBecause every subchart is a _stand-alone chart_, we can test `mysubchart` on its\nown:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Overriding Values from a Parent Chart\n\nOur original chart, `mychart` is now the _parent_ chart of `mysubchart`. This\nrelationship is based entirely on the fact that `mysubchart` is within\n`mychart/charts`.\n\nBecause `mychart` is a parent, we can specify configuration in `mychart` and\nhave that configuration pushed into `mysubchart`. For example, we can modify\n`mychart/values.yaml` like this:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nNote the last two lines. Any directives inside of the `mysubchart` section will\nbe sent to the `mysubchart` chart. So if we run `helm install --generate-name --dry-run --debug\nmychart`, one of the things we will see is the `mysubchart` ConfigMap:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nThe value at the top level has now overridden the value of the subchart.\n\nThere's an important detail to notice here. We didn't change the template of\n`mychart/charts/mysubchart/templates/configmap.yaml` to point to\n`.Values.mysubchart.dessert`. From that template's perspective, the value is\nstill located at `.Values.dessert`. As the template engine passes values along,\nit sets the scope. So for the `mysubchart` templates, only values specifically\nfor `mysubchart` will be available in `.Values`.\n\nSometimes, though, you do want certain values to be available to all of the\ntemplates. This is accomplished using global chart values.\n\n## Global Chart Values\n\nGlobal values are values that can be accessed from any chart or subchart by\nexactly the same name. Globals require explicit declaration. You can't use an\nexisting non-global as if it were a global.\n\nThe Values data type has a reserved section called `Values.global` where global\nvalues can be set. Let's set one in our `mychart/values.yaml` file.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nBecause of the way globals work, both `mychart/templates/configmap.yaml` and\n`mysubchart/templates/configmap.yaml` should be able to access that value as\n`{{ .Values.global.salad }}`.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nNow if we run a dry run install, we'll see the same value in both outputs:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nGlobals are useful for passing information like this, though it does take some\nplanning to make sure the right templates are configured to use globals.\n\n## Sharing Templates with Subcharts\n\nParent charts and subcharts can share templates. Any defined block in any chart\nis available to other charts.\n\nFor example, we can define a simple template like this:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nRecall how the labels on templates are _globally shared_. Thus, the `labels`\nchart can be included from any other chart.\n\nWhile chart developers have a choice between `include` and `template`, one\nadvantage of using `include` is that `include` can dynamically reference\ntemplates:\n\n```yaml\n{{ include $mytemplate }}\n```\n\nThe above will dereference `$mytemplate`. The `template` function, in contrast,\nwill only accept a string literal.\n\n## Avoid Using Blocks\n\nThe Go template language provides a `block` keyword that allows developers to\nprovide a default implementation which is overridden later. In Helm charts,\nblocks are not the best tool for overriding because if multiple implementations\nof the same block are provided, the one selected is unpredictable.\n\nThe suggestion is to instead use `include`.\n"
  },
  {
    "path": "docs/chart_template_guide/values_files.mdx",
    "content": "---\ntitle: Values Files\ndescription: Instructions on how to use the --values flag.\nsidebar_position: 4\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nIn the previous section we looked at the built-in objects that Helm templates\noffer. One of the built-in objects is `Values`. This object provides access to\nvalues passed into the chart. Its contents come from multiple sources:\n\n- The `values.yaml` file in the chart\n- If this is a subchart, the `values.yaml` file of a parent chart\n- A values file is passed into `helm install` or `helm upgrade` with the `-f`\n  flag (`helm install -f myvals.yaml ./mychart`)\n- Individual parameters are passed with `--set` (such as `helm install --set foo=bar\n  ./mychart`)\n\nThe list above is in order of specificity: `values.yaml` is the default, which\ncan be overridden by a parent chart's `values.yaml`, which can in turn be\noverridden by a user-supplied values file, which can in turn be overridden by\n`--set` parameters.\n\nValues files are plain YAML files. Let's edit `mychart/values.yaml` and then\nedit our ConfigMap template.\n\nRemoving the defaults in `values.yaml`, we'll set just one parameter:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nNow we can use this inside of a template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nNotice on the last line we access `favoriteDrink` as an attribute of `Values`:\n`{{ .Values.favoriteDrink }}`.\n\nLet's see how this renders.\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run=client --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nBecause `favoriteDrink` is set in the default `values.yaml` file to `coffee`,\nthat's the value displayed in the template. We can easily override that by\nadding a `--set` flag in our call to `helm install`:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run=client --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nSince `--set` has a higher precedence than the default `values.yaml` file, our\ntemplate generates `drink: slurm`.\n\nValues files can contain more structured content, too. For example, we could\ncreate a `favorite` section in our `values.yaml` file, and then add several keys\nthere:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nNow we would have to modify the template slightly:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nWhile structuring data this way is possible, the recommendation is that you keep\nyour values trees shallow, favoring flatness. When we look at assigning values\nto subcharts, we'll see how values are named using a tree structure.\n\n## Deleting a default key\n\nIf you need to delete a key from the default values, you may override the value\nof the key to be `null`, in which case Helm will remove the key from the\noverridden values merge.\n\nFor example, the stable Drupal chart allows configuring the liveness probe, in\ncase you configure a custom image. Here are the default values:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nIf you try to override the livenessProbe handler to `exec` instead of `httpGet`\nusing `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm will\ncoalesce the default and overridden keys together, resulting in the following\nYAML:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nHowever, Kubernetes would then fail because you can not declare more than one\nlivenessProbe handler. To overcome this, you may instruct Helm to delete the\n`livenessProbe.httpGet` by setting it to null:\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nAt this point, we've seen several built-in objects, and used them to inject\ninformation into a template. Now we will take a look at another aspect of the\ntemplate engine: functions and pipelines.\n"
  },
  {
    "path": "docs/chart_template_guide/variables.md",
    "content": "---\ntitle: Variables\ndescription: Using variables in templates.\nsidebar_position: 8\n---\n\nWith functions, pipelines, objects, and control structures under our belts, we\ncan turn to one of the more basic ideas in many programming languages:\nvariables. In templates, they are less frequently used. But we will see how to\nuse them to simplify code, and to make better use of `with` and `range`.\n\nIn an earlier example, we saw that this code will fail:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` is not inside of the scope that's restricted in the `with` block.\nOne way to work around scoping issues is to assign objects to variables that can\nbe accessed without respect to the present scope.\n\nIn Helm templates, a variable is a named reference to another object. It follows\nthe form `$name`. Variables are assigned with a special assignment operator:\n`:=`. We can rewrite the above to use a variable for `Release.Name`.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nNotice that before we start the `with` block, we assign `$relname :=\n.Release.Name`. Now inside of the `with` block, the `$relname` variable still\npoints to the release name.\n\nRunning that will produce this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nVariables are particularly useful in `range` loops. They can be used on\nlist-like objects to capture both the index and the value:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nNote that `range` comes first, then the variables, then the assignment operator,\nthen the list. This will assign the integer index (starting from zero) to\n`$index` and the value to `$topping`. Running it will produce:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nFor data structures that have both a key and a value, we can use `range` to get\nboth. For example, we can loop through `.Values.favorite` like this:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nNow on the first iteration, `$key` will be `drink` and `$val` will be `coffee`,\nand on the second, `$key` will be `food` and `$val` will be `pizza`. Running the\nabove will generate this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nVariables are normally not \"global\". They are scoped to the block in which they\nare declared. Earlier, we assigned `$relname` in the top level of the template.\nThat variable will be in scope for the entire template. But in our last example,\n`$key` and `$val` will only be in scope inside of the `{{ range... }}{{ end }}`\nblock.\n\nHowever, there is one variable that will always point to the root context: - `$` -.\nThis can be very useful when you are looping\nin a range and you need to know the chart's release name.\n\nAn example illustrating this:\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Many helm templates would use `.` below, but that will not work,\n    # however `$` will work here\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # I cannot reference .Chart.Name, but I can do $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Value from appVersion in Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nSo far we have looked at just one template declared in just one file. But one of\nthe powerful features of the Helm template language is its ability to declare\nmultiple templates and use them together. We'll turn to that in the next\nsection.\n"
  },
  {
    "path": "docs/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Next Steps\ndescription: Wrapping up - some useful pointers to other documentation that will help you.\nsidebar_position: 14\n---\n\nThis guide is intended to give you, the chart developer, a strong understanding\nof how to use Helm's template language. The guide focuses on the technical\naspects of template development.\n\nBut there are many things this guide has not covered when it comes to the\npractical day-to-day development of charts. Here are some useful pointers to\nother documentation that will help you as you create new charts:\n\n- The CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) is an\n  indispensable source of charts.\n- The Kubernetes [Documentation](https://kubernetes.io/docs/home/) provides\n  detailed examples of the various resource kinds that you can use, from\n  ConfigMaps and Secrets to DaemonSets and Deployments.\n- The Helm [Charts Guide](/topics/charts.mdx) explains the workflow of using\n  charts.\n- The Helm [Chart Hooks Guide](/topics/charts_hooks.md) explains how to\n  create lifecycle hooks.\n- The Helm [Charts Tips and Tricks](/howto/charts_tips_and_tricks.md) article\n  provides some useful tips for writing charts.\n- The [Sprig documentation](https://github.com/Masterminds/sprig) documents more\n  than sixty of the template functions.\n- The [Go template docs](https://godoc.org/text/template) explain the template\n  syntax in detail.\n- The [Schelm tool](https://github.com/databus23/schelm) is a nice helper\n  utility for debugging charts.\n\nSometimes it's easier to ask a few questions and get answers from experienced\ndevelopers. The best place to do this is in the [Kubernetes\nSlack](https://kubernetes.slack.com) Helm channels:\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nFinally, if you find errors or omissions in this document, want to suggest some\nnew content, or would like to contribute, visit [The Helm\nProject](https://github.com/helm/helm-www).\n"
  },
  {
    "path": "docs/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Appendix: YAML Techniques\"\ndescription: A closer look at the YAML specification and how it applies to Helm.\nsidebar_position: 15\n---\n\nMost of this guide has been focused on writing the template language. Here,\nwe'll look at the YAML format. YAML has some useful features that we, as\ntemplate authors, can use to make our templates less error prone and easier to\nread.\n\n## Scalars and Collections\n\nAccording to the [YAML spec](https://yaml.org/spec/1.2/spec.html), there are two\ntypes of collections, and many scalar types.\n\nThe two types of collections are maps and sequences:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nScalar values are individual values (as opposed to collections)\n\n### Scalar Types in YAML\n\nIn Helm's dialect of YAML, the scalar data type of a value is determined by a\ncomplex set of rules, including the Kubernetes schema for resource definitions.\nBut when inferring types, the following rules tend to hold true.\n\nIf an integer or float is an unquoted bare word, it is typically treated as a\nnumeric type:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nBut if they are quoted, they are treated as strings:\n\n```yaml\ncount: \"1\" # <-- string, not int\nsize: '2.34' # <-- string, not float\n```\n\nThe same is true of booleans:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # string\n```\n\nThe word for an empty value is `null` (not `nil`).\n\nNote that `port: \"80\"` is valid YAML, and will pass through both the template\nengine and the YAML parser, but will fail if Kubernetes expects `port` to be an\ninteger.\n\nIn some cases, you can force a particular type inference using YAML node tags:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nIn the above, `!!str` tells the parser that `age` is a string, even if it looks\nlike an int. And `port` is treated as an int, even though it is quoted.\n\n\n## Strings in YAML\n\nMuch of the data that we place in YAML documents are strings. YAML has more than\none way to represent a string. This section explains the ways and demonstrates\nhow to use some of them.\n\nThere are three \"inline\" ways of declaring a string:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nAll inline styles must be on one line.\n\n- Bare words are unquoted, and are not escaped. For this reason, you have to be\n  careful what characters you use.\n- Double-quoted strings can have specific characters escaped with `\\`. For\n  example `\"\\\"Hello\\\", she said\"`. You can escape line breaks with `\\n`.\n- Single-quoted strings are \"literal\" strings, and do not use the `\\` to escape\n  characters. The only escape sequence is `''`, which is decoded as a single\n  `'`.\n\nIn addition to the one-line strings, you can declare multi-line strings:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nThe above will treat the value of `coffee` as a single string equivalent to\n`Latte\\nCappuccino\\nEspresso\\n`.\n\nNote that the first line after the `|` must be correctly indented. So we could\nbreak the example above by doing this:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nBecause `Latte` is incorrectly indented, we'd get an error like this:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nIn templates, it is sometimes safer to put a fake \"first line\" of content in a\nmulti-line document just for protection from the above error:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nNote that whatever that first line is, it will be preserved in the output of the\nstring. So if you are, for example, using this technique to inject a file's\ncontents into a ConfigMap, the comment should be of the type expected by\nwhatever is reading that entry.\n\n### Controlling Spaces in Multi-line Strings\n\nIn the example above, we used `|` to indicate a multi-line string. But notice\nthat the content of our string was followed with a trailing `\\n`. If we want the\nYAML processor to strip off the trailing newline, we can add a `-` after the\n`|`:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nNow the `coffee` value will be: `Latte\\nCappuccino\\nEspresso` (with no trailing\n`\\n`).\n\nOther times, we might want all trailing whitespace to be preserved. We can do\nthis with the `|+` notation:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nNow the value of `coffee` will be `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nIndentation inside of a text block is preserved, and results in the preservation\nof line breaks, too:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nIn the above case, `coffee` will be `Latte\\n  12 oz\\n  16\noz\\nCappuccino\\nEspresso`.\n\n### Indenting and Templates\n\nWhen writing templates, you may find yourself wanting to inject the contents of\na file into the template. As we saw in previous chapters, there are two ways of\ndoing this:\n\n- Use `{{ .Files.Get \"FILENAME\" }}` to get the contents of a file in the chart.\n- Use `{{ include \"TEMPLATE\" . }}` to render a template and then place its\n  contents into the chart.\n\nWhen inserting files into YAML, it's good to understand the multi-line rules\nabove. Often times, the easiest way to insert a static file is to do something\nlike this:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nNote how we do the indentation above: `indent 2` tells the template engine to\nindent every line in \"myfile.txt\" with two spaces. Note that we do not indent\nthat template line. That's because if we did, the file content of the first line\nwould be indented twice.\n\n### Folded Multi-line Strings\n\nSometimes you want to represent a string in your YAML with multiple lines, but\nwant it to be treated as one long line when it is interpreted. This is called\n\"folding\". To declare a folded block, use `>` instead of `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nThe value of `coffee` above will be `Latte Cappuccino Espresso\\n`. Note that all\nbut the last line feed will be converted to spaces. You can combine the\nwhitespace controls with the folded text marker, so `>-` will replace or trim\nall newlines.\n\nNote that in the folded syntax, indenting text will cause lines to be preserved.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nThe above will produce `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Note that\nboth the spacing and the newlines are still there.\n\n## Embedding Multiple Documents in One File\n\nIt is possible to place more than one YAML document into a single file. This is\ndone by prefixing a new document with `---` and ending the document with\n`...`\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nIn many cases, either the `---` or the `...` may be omitted.\n\nSome files in Helm cannot contain more than one doc. If, for example, more than\none document is provided inside of a `values.yaml` file, only the first will be\nused.\n\nTemplate files, however, may have more than one document. When this happens, the\nfile (and all of its documents) is treated as one object during template\nrendering. But then the resulting YAML is split into multiple documents before\nit is fed to Kubernetes.\n\nWe recommend only using multiple documents per file when it is absolutely\nnecessary. Having multiple documents in a file can be difficult to debug.\n\n## YAML is a Superset of JSON\n\nBecause YAML is a superset of JSON, any valid JSON document _should_ be valid\nYAML.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nThe above is another way of representing this:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nAnd the two can be mixed (with care):\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nAll three of these should parse into the same internal representation.\n\nWhile this means that files such as `values.yaml` may contain JSON data, Helm\ndoes not treat the file extension `.json` as a valid suffix.\n\n## YAML Anchors\n\nThe YAML spec provides a way to store a reference to a value, and later refer to\nthat value by reference. YAML refers to this as \"anchoring\":\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nIn the above, `&favoriteCoffee` sets a reference to `Cappuccino`. Later, that\nreference is used as `*favoriteCoffee`. So `coffees` becomes `Latte, Cappuccino,\nEspresso`.\n\nWhile there are a few cases where anchors are useful, there is one aspect of\nthem that can cause subtle bugs: The first time the YAML is consumed, the\nreference is expanded and then discarded.\n\nSo if we were to decode and then re-encode the example above, the resulting YAML\nwould be:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nBecause Helm and Kubernetes often read, modify, and then rewrite YAML files, the\nanchors will be lost.\n"
  },
  {
    "path": "docs/glossary/index.mdx",
    "content": "---\ntitle: Glossary\ndescription: Terms used to describe components of Helm's architecture.\nsidebar_position: 10\n---\n\n# Glossary\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\n## Chart\n\nA Helm package that contains information sufficient for installing a set of\nKubernetes resources into a Kubernetes cluster.\n\nCharts contain a `Chart.yaml` file as well as templates, default values\n(`values.yaml`), and dependencies.\n\nCharts are developed in a well-defined directory structure, and then packaged\ninto an archive format called a _chart archive_.\n\n## Chart Archive\n\nA _chart archive_ is a tarred and gzipped (and optionally signed) chart.\n\n## Chart Dependency (Subcharts)\n\nCharts may depend upon other charts. There are two ways a dependency may occur:\n\n- Soft dependency: A chart may simply not function without another chart being\n  installed in a cluster. Helm does not provide tooling for this case. In this\n  case, dependencies may be managed separately.\n- Hard dependency: A chart may contain (inside of its `charts/` directory)\n  another chart upon which it depends. In this case, installing the chart will\n  install all of its dependencies. In this case, a chart and its dependencies\n  are managed as a collection.\n\nWhen a chart is packaged (via `helm package`) all of its hard dependencies are\nbundled with it.\n\n## Chart Version\n\nCharts are versioned according to the [SemVer 2 spec](https://semver.org). A\nversion number is required on every chart.\n\n## Chart.yaml\n\nInformation about a chart is stored in a special file called `Chart.yaml`. Every\nchart must have this file.\n\n## Helm (and helm)\n\nHelm is the package manager for Kubernetes. As an operating system package\nmanager makes it easy to install tools on an OS, Helm makes it easy to install\napplications and resources into Kubernetes clusters.\n\nWhile _Helm_ is the name of the project, the command line client is also named\n`helm`. By convention, when speaking of the project, _Helm_ is capitalized. When\nspeaking of the client, _helm_ is in lowercase.\n\n## Helm Configuration Files (XDG)\n\nHelm stores its configuration files in XDG directories. These directories are\ncreated the first time `helm` is run.\n\n## Kube Config (KUBECONFIG)\n\nThe Helm client learns about Kubernetes clusters by using files in the _Kube\nconfig_ file format. By default, Helm attempts to find this file in the place\nwhere `kubectl` creates it (`$HOME/.kube/config`).\n\n## Lint (Linting)\n\nTo _lint_ a chart is to validate that it follows the conventions and\nrequirements of the Helm chart standard. Helm provides tools to do this, notably\nthe `helm lint` command.\n\n## Provenance (Provenance file)\n\nHelm charts may be accompanied by a _provenance file_ which provides information\nabout where the chart came from and what it contains.\n\nProvenance files are one part of the Helm security story. A provenance contains\na cryptographic hash of the chart archive file, the Chart.yaml data, and a\nsignature block (an OpenPGP \"clearsign\" block). When coupled with a keychain,\nthis provides chart users with the ability to:\n\n- Validate that a chart was signed by a trusted party\n- Validate that the chart file has not been tampered with\n- Validate the contents of a chart metadata (`Chart.yaml`)\n- Quickly match a chart to its provenance data\n\nProvenance files have the `.prov` extension, and can be served from a chart\nrepository server or any other HTTP server.\n\n## Release\n\nWhen a chart is installed, the Helm library creates a _release_ to track that\ninstallation.\n\nA single chart may be installed many times into the same cluster, and create\nmany different releases. For example, one can install three PostgreSQL databases\nby running `helm install` three times with a different release name.\n\n## Release Number (Release Version)\n\nA single release can be updated multiple times. A sequential counter is used to\ntrack releases as they change. After a first `helm install`, a release will have\n_release number_ 1. Each time a release is upgraded or rolled back, the release\nnumber will be incremented.\n\n## Rollback\n\nA release can be upgraded to a newer chart or configuration. But since release\nhistory is stored, a release can also be _rolled back_ to a previous release\nnumber. This is done with the `helm rollback` command.\n\nImportantly, a rolled back release will receive a new release number.\n\n| Operation  | Release Number                                       |\n|------------|------------------------------------------------------|\n| install    | release 1                                            |\n| upgrade    | release 2                                            |\n| upgrade    | release 3                                            |\n| rollback 1 | release 4 (but running the same config as release 1) |\n\nThe above table illustrates how release numbers increment across install,\nupgrade, and rollback.\n\n## Helm Library (or SDK)\n\nThe Helm Library (or SDK) refers to the Go code that interacts directly with the\nKubernetes API server to install, upgrade, query, and remove Kubernetes\nresources. It can be imported into a project to use Helm as a client library\ninstead of a CLI.\n\n## Repository (Repo, Chart Repository)\n\nHelm charts may be stored on dedicated HTTP servers called _chart repositories_\n(_repositories_, or just _repos_).\n\nA chart repository server is a simple HTTP server that can serve an `index.yaml`\nfile that describes a batch of charts, and provides information on where each\nchart can be downloaded from. (Many chart repositories serve the charts as well\nas the `index.yaml` file.)\n\nA Helm client can point to zero or more chart repositories. By default, Helm\nclients are not configured with any chart repositories. Chart repositories can\nbe added at any time using the `helm repo add` command.\n\n## Chart Registry (OCI-based Registry)\n\nA 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/).\n\n## Values (Values Files, values.yaml)\n\nValues provide a way to override template defaults with your own information.\n\nHelm Charts are \"parameterized\", which means the chart developer may expose\nconfiguration that can be overridden at installation time. For example, a chart\nmay expose a `username` field that allows setting a user name for a service.\n\nThese exposed variables are called _values_ in Helm parlance.\n\nValues can be set during `helm install` and `helm upgrade` operations, either by\npassing them in directly, or by using a `values.yaml` file.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "docs/helm/_category_.json",
    "content": "{\n  \"link\": {\n    \"type\": \"doc\",\n    \"id\": \"helm-category\"\n  }\n}\n"
  },
  {
    "path": "docs/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\nThe Helm package manager for Kubernetes.\n\n### Synopsis\n\nThe Kubernetes package manager\n\nCommon actions for Helm:\n\n- helm search:    search for charts\n- helm pull:      download a chart to your local directory to view\n- helm install:   upload the chart to Kubernetes\n- helm list:      list releases of charts\n\nEnvironment variables:\n\n| Name                               | Description                                                                                                |\n|------------------------------------|------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | set an alternative location for storing cached files.                                                      |\n| $HELM_CONFIG_HOME                  | set an alternative location for storing Helm configuration.                                                |\n| $HELM_DATA_HOME                    | set an alternative location for storing Helm data.                                                         |\n| $HELM_DEBUG                        | indicate whether or not Helm is running in Debug mode                                                      |\n| $HELM_DRIVER                       | set the backend storage driver. Values are: configmap, secret, memory, sql.                                |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | set the connection string the SQL storage driver should use.                                               |\n| $HELM_MAX_HISTORY                  | set the maximum number of helm release history.                                                            |\n| $HELM_NAMESPACE                    | set the namespace used for the helm operations.                                                            |\n| $HELM_NO_PLUGINS                   | disable plugins. Set HELM_NO_PLUGINS=1 to disable plugins.                                                 |\n| $HELM_PLUGINS                      | set the path to the plugins directory                                                                      |\n| $HELM_REGISTRY_CONFIG              | set the path to the registry config file.                                                                  |\n| $HELM_REPOSITORY_CACHE             | set the path to the repository cache directory                                                             |\n| $HELM_REPOSITORY_CONFIG            | set the path to the repositories file.                                                                     |\n| $KUBECONFIG                        | set an alternative Kubernetes configuration file (default \"~/.kube/config\")                                |\n| $HELM_KUBEAPISERVER                | set the Kubernetes API Server Endpoint for authentication                                                  |\n| $HELM_KUBECAFILE                   | set the Kubernetes certificate authority file.                                                             |\n| $HELM_KUBEASGROUPS                 | set the Groups to use for impersonation using a comma-separated list.                                      |\n| $HELM_KUBEASUSER                   | set the Username to impersonate for the operation.                                                         |\n| $HELM_KUBECONTEXT                  | set the name of the kubeconfig context.                                                                    |\n| $HELM_KUBETOKEN                    | set the Bearer KubeToken used for authentication.                                                          |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indicate if the Kubernetes API server's certificate validation should be skipped (insecure)                |\n| $HELM_KUBETLS_SERVER_NAME          | set the server name used to validate the Kubernetes API server certificate                                 |\n| $HELM_BURST_LIMIT                  | set the default burst limit in the case the server contains many CRDs (default 100, -1 to disable)         |\n| $HELM_QPS                          | set the Queries Per Second in cases where a high number of calls exceed the option for higher burst values |\n| $HELM_COLOR                        | set color output mode. Allowed values: never, always, auto (default: never)                                |\n| $NO_COLOR                          | set to any non-empty value to disable all colored output (overrides $HELM_COLOR)                           |\n\nHelm stores cache, configuration, and data based on the following configuration order:\n\n- If a HELM_*_HOME environment variable is set, it will be used\n- Otherwise, on systems supporting the XDG base directory specification, the XDG variables will be used\n- When no other location is set a default location will be used based on the operating system\n\nBy default, the default directories depend on the Operating System. The defaults are listed below:\n\n| Operating System | Cache Path                | Configuration Path             | Data Path               |\n|------------------|---------------------------|--------------------------------|-------------------------|\n| Linux            | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm |\n| macOS            | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm      |\n| Windows          | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm          |\n\n\n### Options\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n  -h, --help                            help for helm\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n* [helm create](/helm/helm_create.md)\t - create a new chart with the given name\n* [helm dependency](/helm/helm_dependency.md)\t - manage a chart's dependencies\n* [helm env](/helm/helm_env.md)\t - helm client environment information\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n* [helm history](/helm/helm_history.md)\t - fetch release history\n* [helm install](/helm/helm_install.md)\t - install a chart\n* [helm lint](/helm/helm_lint.md)\t - examine a chart for possible issues\n* [helm list](/helm/helm_list.md)\t - list releases\n* [helm package](/helm/helm_package.md)\t - package a chart directory into a chart archive\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n* [helm pull](/helm/helm_pull.md)\t - download a chart from a repository and (optionally) unpack it in local directory\n* [helm push](/helm/helm_push.md)\t - push a chart to remote\n* [helm registry](/helm/helm_registry.md)\t - login to or logout from a registry\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n* [helm rollback](/helm/helm_rollback.md)\t - roll back a release to a previous revision\n* [helm search](/helm/helm_search.md)\t - search for a keyword in charts\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n* [helm status](/helm/helm_status.md)\t - display the status of the named release\n* [helm template](/helm/helm_template.md)\t - locally render templates\n* [helm test](/helm/helm_test.md)\t - run tests for a release\n* [helm uninstall](/helm/helm_uninstall.md)\t - uninstall a release\n* [helm upgrade](/helm/helm_upgrade.md)\t - upgrade a release\n* [helm verify](/helm/helm_verify.md)\t - verify that a chart at the given path has been signed and is valid\n* [helm version](/helm/helm_version.md)\t - print the helm version information\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\ngenerate autocompletion scripts for the specified shell\n\n### Synopsis\n\n\nGenerate autocompletion scripts for Helm for the specified shell.\n\n\n### Options\n\n```\n  -h, --help   help for completion\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm completion bash](/helm/helm_completion_bash.md)\t - generate autocompletion script for bash\n* [helm completion fish](/helm/helm_completion_fish.md)\t - generate autocompletion script for fish\n* [helm completion powershell](/helm/helm_completion_powershell.md)\t - generate autocompletion script for powershell\n* [helm completion zsh](/helm/helm_completion_zsh.md)\t - generate autocompletion script for zsh\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\ngenerate autocompletion script for bash\n\n### Synopsis\n\n\nGenerate the autocompletion script for Helm for the bash shell.\n\nTo load completions in your current shell session:\n\n    source <(helm completion bash)\n\nTo load completions for every new session, execute once:\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n\n```\nhelm completion bash [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for bash\n      --no-descriptions   disable completion descriptions\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\ngenerate autocompletion script for fish\n\n### Synopsis\n\n\nGenerate the autocompletion script for Helm for the fish shell.\n\nTo load completions in your current shell session:\n\n    helm completion fish | source\n\nTo load completions for every new session, execute once:\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\nYou will need to start a new shell for this setup to take effect.\n\n\n```\nhelm completion fish [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for fish\n      --no-descriptions   disable completion descriptions\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\ngenerate autocompletion script for powershell\n\n### Synopsis\n\n\nGenerate the autocompletion script for powershell.\n\nTo load completions in your current shell session:\nPS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\nTo load completions for every new session, add the output of the above command\nto your powershell profile.\n\n\n```\nhelm completion powershell [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for powershell\n      --no-descriptions   disable completion descriptions\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\ngenerate autocompletion script for zsh\n\n### Synopsis\n\n\nGenerate the autocompletion script for Helm for the zsh shell.\n\nTo load completions in your current shell session:\n\n    source <(helm completion zsh)\n\nTo load completions for every new session, execute once:\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for zsh\n      --no-descriptions   disable completion descriptions\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n\ncreate a new chart with the given name\n\n### Synopsis\n\n\nThis command creates a chart directory along with the common files and\ndirectories used in a chart.\n\nFor example, 'helm create foo' will create a directory structure that looks\nsomething like this:\n\n    foo/\n    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.\n    ├── Chart.yaml    # Information about your chart\n    ├── values.yaml   # The default values for your templates\n    ├── charts/       # Charts that this chart depends on\n    └── templates/    # The template files\n        └── tests/    # The test files\n\n'helm create' takes a path for an argument. If directories in the given path\ndo not exist, Helm will attempt to create them as it goes. If the given\ndestination exists and there are files in that directory, conflicting files\nwill be overwritten, but other files will be left alone.\n\n\n```\nhelm create NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help             help for create\n  -p, --starter string   the name or absolute path to Helm starter scaffold\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\nmanage a chart's dependencies\n\n### Synopsis\n\n\nManage the dependencies of a chart.\n\nHelm charts store their dependencies in 'charts/'. For chart developers, it is\noften easier to manage dependencies in 'Chart.yaml' which declares all\ndependencies.\n\nThe dependency commands operate on that file, making it easy to synchronize\nbetween the desired dependencies and the actual dependencies stored in the\n'charts/' directory.\n\nFor example, this Chart.yaml declares two dependencies:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\nThe 'name' should be the name of a chart, where that name must match the name\nin that chart's 'Chart.yaml' file.\n\nThe 'version' field should contain a semantic version or version range.\n\nThe 'repository' URL should point to a Chart Repository. Helm expects that by\nappending '/index.yaml' to the URL, it should be able to retrieve the chart\nrepository's index. Note: 'repository' can be an alias. The alias must start\nwith 'alias:' or '@'.\n\nStarting from 2.2.0, repository can be defined as the path to the directory of\nthe dependency charts stored locally. The path should start with a prefix of\n\"file://\". For example,\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\nIf the dependency chart is retrieved locally, it is not required to have the\nrepository added to helm by \"helm add repo\". Version matching is also supported\nfor this case.\n\n\n### Options\n\n```\n  -h, --help   help for dependency\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm dependency build](/helm/helm_dependency_build.md)\t - rebuild the charts/ directory based on the Chart.lock file\n* [helm dependency list](/helm/helm_dependency_list.md)\t - list the dependencies for the given chart\n* [helm dependency update](/helm/helm_dependency_update.md)\t - update charts/ based on the contents of Chart.yaml\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\nrebuild the charts/ directory based on the Chart.lock file\n\n### Synopsis\n\n\nBuild out the charts/ directory from the Chart.lock file.\n\nBuild is used to reconstruct a chart's dependencies to the state specified in\nthe lock file. This will not re-negotiate dependencies, as 'helm dependency update'\ndoes.\n\nIf no lock file is found, 'helm dependency build' will mirror the behavior\nof 'helm dependency update'.\n\n\n```\nhelm dependency build CHART [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for build\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm dependency](/helm/helm_dependency.md)\t - manage a chart's dependencies\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\nlist the dependencies for the given chart\n\n### Synopsis\n\n\nList all of the dependencies declared in a chart.\n\nThis can take chart archives and chart directories as input. It will not alter\nthe contents of a chart.\n\nThis will produce an error if the chart cannot be loaded.\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### Options\n\n```\n  -h, --help                 help for list\n      --max-col-width uint   maximum column width for output table (default 80)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm dependency](/helm/helm_dependency.md)\t - manage a chart's dependencies\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\nupdate charts/ based on the contents of Chart.yaml\n\n### Synopsis\n\n\nUpdate the on-disk dependencies to mirror Chart.yaml.\n\nThis command verifies that the required charts, as expressed in 'Chart.yaml',\nare present in 'charts/' and are at an acceptable version. It will pull down\nthe latest charts that satisfy the dependencies, and clean up old dependencies.\n\nOn successful update, this will generate a lock file that can be used to\nrebuild the dependencies to an exact version.\n\nDependencies are not required to be represented in 'Chart.yaml'. For that\nreason, an update command will not remove charts unless they are (a) present\nin the Chart.yaml file, but (b) at the wrong version.\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for update\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm dependency](/helm/helm_dependency.md)\t - manage a chart's dependencies\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\nhelm client environment information\n\n### Synopsis\n\n\nEnv prints out all the environment information in use by Helm.\n\n\n```\nhelm env [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for env\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\ndownload extended information of a named release\n\n### Synopsis\n\n\nThis command consists of multiple subcommands which can be used to\nget extended information about the release, including:\n\n- The values used to generate the release\n- The generated manifest file\n- The notes provided by the chart of the release\n- The hooks associated with the release\n- The metadata of the release\n\n\n### Options\n\n```\n  -h, --help   help for get\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm get all](/helm/helm_get_all.md)\t - download all information for a named release\n* [helm get hooks](/helm/helm_get_hooks.md)\t - download all hooks for a named release\n* [helm get manifest](/helm/helm_get_manifest.md)\t - download the manifest for a named release\n* [helm get metadata](/helm/helm_get_metadata.md)\t - This command fetches metadata for a given release\n* [helm get notes](/helm/helm_get_notes.md)\t - download the notes for a named release\n* [helm get values](/helm/helm_get_values.md)\t - download the values file for a named release\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\ndownload all information for a named release\n\n### Synopsis\n\n\nThis command prints a human readable collection of information about the\nnotes, hooks, supplied values, and generated manifest file of the given release.\n\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for all\n      --revision int      get the named release with revision\n      --template string   go template for formatting the output, eg: {{.Release.Name}}\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\ndownload all hooks for a named release\n\n### Synopsis\n\n\nThis command downloads hooks for a given release.\n\nHooks are formatted in YAML and separated by the YAML '---\\n' separator.\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help           help for hooks\n      --revision int   get the named release with revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\ndownload the manifest for a named release\n\n### Synopsis\n\n\nThis command fetches the generated manifest for a given release.\n\nA manifest is a YAML-encoded representation of the Kubernetes resources that\nwere generated from this release's chart(s). If a chart is dependent on other\ncharts, those resources will also be included in the manifest.\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help           help for manifest\n      --revision int   get the named release with revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\nThis command fetches metadata for a given release\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help            help for metadata\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    specify release revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\ndownload the notes for a named release\n\n### Synopsis\n\n\nThis command shows notes provided by the chart of a named release.\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help           help for notes\n      --revision int   get the named release with revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\ndownload the values file for a named release\n\n### Synopsis\n\n\nThis command downloads a values file for a given release.\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -a, --all             dump all (computed) values\n  -h, --help            help for values\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    get the named release with revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\nfetch release history\n\n### Synopsis\n\n\nHistory prints historical revisions for a given release.\n\nA default maximum of 256 revisions will be returned. Setting '--max'\nconfigures the maximum length of the revision list returned.\n\nThe historical release set is printed as a formatted table, e.g:\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help            help for history\n      --max int         maximum number of revision to include in history (default 256)\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\ninstall a chart\n\n### Synopsis\n\n\nThis command installs a chart archive.\n\nThe install argument must be a chart reference, a path to a packaged chart,\na path to an unpacked chart directory or a URL.\n\nTo override values in a chart, use either the '--values' flag and pass in a file\nor use the '--set' flag and pass configuration from the command line, to force\na string value use '--set-string'. You can use '--set-file' to set individual\nvalues from a file when the value itself is too long for the command line\nor is dynamically generated. You can also use '--set-json' to set json values\n(scalars/objects/arrays) from the command line. Additionally, you can use '--set-json' and passing json object as a string.\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\nor\n\n    $ helm install --set name=prod myredis ./redis\n\nor\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\nor\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\nor\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\nor\n\n    $ helm install --set-json '{\"master\":{\"sidecars\":[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]}}' myredis ./redis\n\nYou can specify the '--values'/'-f' flag multiple times. The priority will be given to the\nlast (right-most) file specified. For example, if both myvalues.yaml and override.yaml\ncontained a key called 'Test', the value set in override.yaml would take precedence:\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\nYou can specify the '--set' flag multiple times. The priority will be given to the\nlast (right-most) set specified. For example, if both 'bar' and 'newbar' values are\nset for a key called 'foo', the 'newbar' value would take precedence:\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\nSimilarly, in the following example 'foo' is set to '[\"four\"]':\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\nAnd in the following example, 'foo' is set to '{\"key1\":\"value1\",\"key2\":\"bar\"}':\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\nTo check the generated manifests of a release without installing the chart,\nthe --debug and --dry-run flags can be combined.\n\nThe --dry-run flag will output all generated chart manifests, including Secrets\nwhich can contain sensitive values. To hide Kubernetes Secrets use the\n--hide-secret flag. Please carefully consider how and when these flags are used.\n\nIf --verify is set, the chart MUST have a provenance file, and the provenance\nfile MUST pass all verification steps.\n\nThere are six different ways you can express the chart you want to install:\n\n1. By chart reference: helm install mymaria example/mariadb\n2. By path to a packaged chart: helm install mynginx ./nginx-1.2.3.tgz\n3. By path to an unpacked chart directory: helm install mynginx ./nginx\n4. By absolute URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. By chart reference and repo url: helm install --repo https://example.com/charts/ mynginx nginx\n6. By OCI registries: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\nCHART REFERENCES\n\nA chart reference is a convenient way of referencing a chart in a chart repository.\n\nWhen you use a chart reference with a repo prefix ('example/mariadb'), Helm will look in the local\nconfiguration for a chart repository named 'example', and will then look for a\nchart in that repository whose name is 'mariadb'. It will install the latest stable version of that chart\nuntil you specify '--devel' flag to also include development version (alpha, beta, and release candidate releases), or\nsupply a version number with the '--version' flag.\n\nTo see the list of chart repositories, use 'helm repo list'. To search for\ncharts in a repository, use 'helm search'.\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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\")\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force-conflicts                            if set server-side apply will force changes against conflicts\n      --force-replace                              force resource updates by replacement\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for install\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --post-renderer postRendererString           the name of a postrenderer type plugin to be used for post rendering. If it exists, the plugin will be used\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    reuse the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --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\n      --server-side                                object updates run in the server instead of the client (default true)\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --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\"})\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --wait WaitStrategy[=watcher]                if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly)\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\nexamine a chart for possible issues\n\n### Synopsis\n\n\nThis command takes a path to a chart and runs a series of tests to verify that\nthe chart is well-formed.\n\nIf the linter encounters things that will cause the chart to fail installation,\nit will emit [ERROR] messages. If it encounters issues that break with convention\nor recommendation, it will emit [WARNING] messages.\n\n\n```\nhelm lint PATH [flags]\n```\n\n### Options\n\n```\n  -h, --help                      help for lint\n      --kube-version string       Kubernetes version used for capabilities and deprecation checks\n      --quiet                     print only warnings and errors\n      --set stringArray           set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --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\"})\n      --set-literal stringArray   set a literal STRING value on the command line\n      --set-string stringArray    set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-schema-validation    if set, disables JSON schema validation\n      --strict                    fail on lint warnings\n  -f, --values strings            specify values in a YAML file or a URL (can specify multiple)\n      --with-subcharts            lint dependent charts\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\nlist releases\n\n### Synopsis\n\n\nThis command lists all of the releases for a specified namespace (uses current namespace context if namespace not specified).\n\nBy default, it lists all releases in any status. Individual status filters like '--deployed', '--failed',\n'--pending', '--uninstalled', '--superseded', and '--uninstalling' can be used\nto show only releases in specific states. Such flags can be combined:\n'--deployed --failed'.\n\nBy default, items are sorted alphabetically. Use the '-d' flag to sort by\nrelease date.\n\nIf the --filter flag is provided, it will be treated as a filter. Filters are\nregular expressions (Perl compatible) that are applied to the list of releases.\nOnly items that match the filter will be returned.\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\nIf no results are found, 'helm list' will exit 0, but with no output (or in\nthe case of no '-q' flag, only headers).\n\nBy default, up to 256 items may be returned. To limit this, use the '--max' flag.\nSetting '--max' to 0 will not return all results. Rather, it will return the\nserver's default, which may be much higher than 256. Pairing the '--max'\nflag with the '--offset' flag allows you to page through results.\n\n\n```\nhelm list [flags]\n```\n\n### Options\n\n```\n  -A, --all-namespaces       list releases across all namespaces\n  -d, --date                 sort by release date\n      --deployed             show deployed releases\n      --failed               show failed releases\n  -f, --filter string        a regular expression (Perl compatible). Any releases that match the expression will be included in the results\n  -h, --help                 help for list\n  -m, --max int              maximum number of releases to fetch (default 256)\n      --no-headers           don't print headers when using the default output format\n      --offset int           next release index in the list, used to offset from start value\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pending              show pending releases\n  -r, --reverse              reverse the sort order\n  -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.\n  -q, --short                output short (quiet) listing format\n      --superseded           show superseded releases\n      --time-format string   format time using golang time formatter. Example: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          show uninstalled releases (if 'helm uninstall --keep-history' was used)\n      --uninstalling         show releases that are currently being uninstalled\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\npackage a chart directory into a chart archive\n\n### Synopsis\n\n\nThis command packages a chart into a versioned chart archive file. If a path\nis given, this will look at that path for a chart (which must contain a\nChart.yaml file) and then package that directory.\n\nVersioned chart archives are used by Helm package repositories.\n\nTo sign a chart, use the '--sign' flag. In most cases, you should also\nprovide '--keyring path/to/secret/keys' and '--key keyname'.\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\nIf '--keyring' is not specified, Helm usually defaults to the public keyring\nunless your environment is otherwise configured.\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Options\n\n```\n      --app-version string         set the appVersion on the chart to this version\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -u, --dependency-update          update dependencies from \"Chart.yaml\" to dir \"charts/\" before packaging\n  -d, --destination string         location to write the chart. (default \".\")\n  -h, --help                       help for package\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key string                 name of the key to use when signing. Used if --sign is true\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of a public keyring (default \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     location of a file which contains the passphrase for the signing key. Use \"-\" in order to read from stdin.\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --sign                       use a PGP private key to sign this package\n      --username string            chart repository username where to locate the requested chart\n      --version string             set the version on the chart to this semver version\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\ninstall, list, or uninstall Helm plugins\n\n### Synopsis\n\n\nManage client-side Helm plugins.\n\n\n### Options\n\n```\n  -h, --help   help for plugin\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm plugin install](/helm/helm_plugin_install.md)\t - install a Helm plugin\n* [helm plugin list](/helm/helm_plugin_list.md)\t - list installed Helm plugins\n* [helm plugin package](/helm/helm_plugin_package.md)\t - package a plugin directory into a plugin archive\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md)\t - uninstall one or more Helm plugins\n* [helm plugin update](/helm/helm_plugin_update.md)\t - update one or more Helm plugins\n* [helm plugin verify](/helm/helm_plugin_verify.md)\t - verify that a plugin at the given path has been signed and is valid\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\ninstall a Helm plugin\n\n### Synopsis\n\n\nThis command allows you to install a plugin from a url to a VCS repo or a local path.\n\nBy default, plugin signatures are verified before installation when installing from\ntarballs (.tgz or .tar.gz). This requires a corresponding .prov file to be available\nalongside the tarball.\nFor local development, plugins installed from local directories are automatically\ntreated as \"local dev\" and do not require signatures.\nUse --verify=false to skip signature verification for remote plugins.\n\n\n```\nhelm plugin install [options] <path|url> [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify registry client using this SSL certificate file\n  -h, --help                       help for install\n      --insecure-skip-tls-verify   skip tls certificate checks for the plugin download\n      --key-file string            identify registry client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --password string            registry password\n      --plain-http                 use insecure HTTP connections for the plugin download\n      --username string            registry username\n      --verify                     verify the plugin signature before installing (default true)\n      --version string             specify a version constraint. If this is not specified, the latest version is installed\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\nlist installed Helm plugins\n\n```\nhelm plugin list [flags]\n```\n\n### Options\n\n```\n  -h, --help          help for list\n      --type string   Plugin type\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_plugin_package.md",
    "content": "---\ntitle: helm plugin package\n---\n\npackage a plugin directory into a plugin archive\n\n### Synopsis\n\n\nThis command packages a Helm plugin directory into a tarball.\n\nBy default, the command will generate a provenance file signed with a PGP key.\nThis ensures the plugin can be verified after installation.\n\nUse --sign=false to skip signing (not recommended for distribution).\n\n\n```\nhelm plugin package [PATH] [flags]\n```\n\n### Options\n\n```\n  -d, --destination string       location to write the plugin tarball. (default \".\")\n  -h, --help                     help for package\n      --key string               name of the key to use when signing. Used if --sign is true\n      --keyring string           location of a public keyring (default \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string   location of a file which contains the passphrase for the signing key. Use \"-\" to read from stdin.\n      --sign                     use a PGP private key to sign this plugin (default true)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\nuninstall one or more Helm plugins\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for uninstall\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\nupdate one or more Helm plugins\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for update\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_plugin_verify.md",
    "content": "---\ntitle: helm plugin verify\n---\n\nverify that a plugin at the given path has been signed and is valid\n\n### Synopsis\n\n\nThis command verifies that a Helm plugin has a valid provenance file,\nand that the provenance file is signed by a trusted PGP key.\n\nIt supports both:\n- Plugin tarballs (.tgz or .tar.gz files)\n- Installed plugin directories\n\nFor installed plugins, use the path shown by 'helm env HELM_PLUGINS' followed\nby the plugin name. For example:\n  helm plugin verify ~/.local/share/helm/plugins/example-cli\n\nTo generate a signed plugin, use the 'helm plugin package --sign' command.\n\n\n```\nhelm plugin verify [PATH] [flags]\n```\n\n### Options\n\n```\n  -h, --help             help for verify\n      --keyring string   keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\ndownload a chart from a repository and (optionally) unpack it in local directory\n\n### Synopsis\n\n\nRetrieve a package from a package repository, and download it locally.\n\nThis is useful for fetching packages to inspect, modify, or repackage. It can\nalso be used to perform cryptographic verification of a chart without installing\nthe chart.\n\nThere are options for unpacking the chart after download. This will create a\ndirectory for the chart and uncompress into that directory.\n\nIf the --verify flag is specified, the requested chart MUST have a provenance\nfile, and MUST pass the verification process. Failure in any part of this will\nresult in an error, and the chart will not be saved locally.\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -d, --destination string         location to write the chart. If this and untardir are specified, untardir is appended to this (default \".\")\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help                       help for pull\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --prov                       fetch the provenance file, but don't perform verification\n      --repo string                chart repository url where to locate the requested chart\n      --untar                      if set to true, will untar the chart after downloading it\n      --untardir string            if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default \".\")\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\npush a chart to remote\n\n### Synopsis\n\n\nUpload a chart to a registry.\n\nIf the chart has an associated provenance file,\nit will also be uploaded.\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify registry client using this SSL certificate file\n  -h, --help                       help for push\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart upload\n      --key-file string            identify registry client using this SSL key file\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart upload\n      --username string            chart repository username where to locate the requested chart\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\nlogin to or logout from a registry\n\n### Synopsis\n\n\nThis command consists of multiple subcommands to interact with registries.\n\n\n### Options\n\n```\n  -h, --help   help for registry\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm registry login](/helm/helm_registry_login.md)\t - login to a registry\n* [helm registry logout](/helm/helm_registry_logout.md)\t - logout from a registry\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\nlogin to a registry\n\n### Synopsis\n\n\nAuthenticate to a remote registry.\n\nFor example for Github Container Registry:\n\n    echo \"$GITHUB_TOKEN\" | helm registry login ghcr.io -u $GITHUB_USER --password-stdin\n\n\n```\nhelm registry login [host] [flags]\n```\n\n### Options\n\n```\n      --ca-file string     verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string   identify registry client using this SSL certificate file\n  -h, --help               help for login\n      --insecure           allow connections to TLS registry without certs\n      --key-file string    identify registry client using this SSL key file\n  -p, --password string    registry password or identity token\n      --password-stdin     read password or identity token from stdin\n      --plain-http         use insecure HTTP connections for the chart upload\n  -u, --username string    registry username\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm registry](/helm/helm_registry.md)\t - login to or logout from a registry\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\nlogout from a registry\n\n### Synopsis\n\n\nRemove credentials stored for a remote registry.\n\n\n```\nhelm registry logout [host] [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for logout\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm registry](/helm/helm_registry.md)\t - login to or logout from a registry\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\nadd, list, remove, update, and index chart repositories\n\n### Synopsis\n\n\nThis command consists of multiple subcommands to interact with chart repositories.\n\nIt can be used to add, remove, list, and index chart repositories.\n\n\n### Options\n\n```\n  -h, --help   help for repo\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm repo add](/helm/helm_repo_add.md)\t - add a chart repository\n* [helm repo index](/helm/helm_repo_index.md)\t - generate an index file given a directory containing packaged charts\n* [helm repo list](/helm/helm_repo_list.md)\t - list chart repositories\n* [helm repo remove](/helm/helm_repo_remove.md)\t - remove one or more chart repositories\n* [helm repo update](/helm/helm_repo_update.md)\t - update information of available charts locally from chart repositories\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\nadd a chart repository\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Options\n\n```\n      --allow-deprecated-repos     by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --force-update               replace (overwrite) the repo if it already exists\n  -h, --help                       help for add\n      --insecure-skip-tls-verify   skip tls certificate checks for the repository\n      --key-file string            identify HTTPS client using this SSL key file\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password\n      --password-stdin             read chart repository password from stdin\n      --timeout duration           time to wait for the index file download to complete (default 2m0s)\n      --username string            chart repository username\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\ngenerate an index file given a directory containing packaged charts\n\n### Synopsis\n\n\nRead the current directory, generate an index file based on the charts found\nand write the result to 'index.yaml' in the current directory.\n\nThis tool is used for creating an 'index.yaml' file for a chart repository. To\nset an absolute URL to the charts, use '--url' flag.\n\nTo merge the generated index with an existing index file, use the '--merge'\nflag. In this case, the charts found in the current directory will be merged\ninto the index passed in with --merge, with local charts taking priority over\nexisting charts.\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### Options\n\n```\n  -h, --help           help for index\n      --json           output in JSON format\n      --merge string   merge the generated index into the given index\n      --url string     url of chart repository\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\nlist chart repositories\n\n```\nhelm repo list [flags]\n```\n\n### Options\n\n```\n  -h, --help            help for list\n      --no-headers      suppress headers in the output\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nremove one or more chart repositories\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for remove\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\nupdate information of available charts locally from chart repositories\n\n### Synopsis\n\n\nUpdate gets the latest information about charts from the respective chart repositories.\nInformation is cached locally, where it is used by commands like 'helm search'.\n\nYou can optionally specify a list of repositories you want to update.\n\t$ helm repo update <repo_name> ...\nTo update all the repositories, use 'helm repo update'.\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Options\n\n```\n  -h, --help               help for update\n      --timeout duration   time to wait for the index file download to complete (default 2m0s)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\nroll back a release to a previous revision\n\n### Synopsis\n\n\nThis command rolls back a release to a previous revision.\n\nThe first argument of the rollback command is the name of a release, and the\nsecond is a revision (version) number. If this argument is omitted or set to\n0, it will roll back to the previous release.\n\nTo see revision numbers, run 'helm history RELEASE'.\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Options\n\n```\n      --cleanup-on-fail               allow deletion of new resources created in this rollback when rollback fails\n      --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\")\n      --force-conflicts               if set server-side apply will force changes against conflicts\n      --force-replace                 force resource updates by replacement\n  -h, --help                          help for rollback\n      --history-max int               limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --no-hooks                      prevent hooks from running during rollback\n      --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\")\n      --timeout duration              time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --wait WaitStrategy[=watcher]   if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly)\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\nsearch for a keyword in charts\n\n### Synopsis\n\n\nSearch provides the ability to search for Helm charts in the various places\nthey can be stored including the Artifact Hub and repositories you have added.\nUse search subcommands to search different locations for charts.\n\n\n### Options\n\n```\n  -h, --help   help for search\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm search hub](/helm/helm_search_hub.md)\t - search for charts in the Artifact Hub or your own hub instance\n* [helm search repo](/helm/helm_search_repo.md)\t - search repositories for a keyword in charts\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\nsearch for charts in the Artifact Hub or your own hub instance\n\n### Synopsis\n\n\nSearch for Helm charts in the Artifact Hub or your own hub instance.\n\nArtifact Hub is a web-based application that enables finding, installing, and\npublishing packages and configurations for CNCF projects, including publicly\navailable distributed charts Helm charts. It is a Cloud Native Computing\nFoundation sandbox project. You can browse the hub at https://artifacthub.io/\n\nThe [KEYWORD] argument accepts either a keyword string, or quoted string of rich\nquery options. For rich query options documentation, see\nhttps://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n\nPrevious versions of Helm used an instance of Monocular as the default\n'endpoint', so for backwards compatibility Artifact Hub is compatible with the\nMonocular search API. Similarly, when setting the 'endpoint' flag, the specified\nendpoint must also be implement a Monocular compatible search API endpoint.\nNote that when specifying a Monocular instance as the 'endpoint', rich queries\nare not supported. For API details, see https://github.com/helm/monocular\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### Options\n\n```\n      --endpoint string      Hub instance to query for charts (default \"https://hub.helm.sh\")\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for hub\n      --list-repo-url        print charts repository URL\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm search](/helm/helm_search.md)\t - search for a keyword in charts\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\nsearch repositories for a keyword in charts\n\n### Synopsis\n\n\nSearch reads through all of the repositories configured on the system, and\nlooks for matches. Search of these repositories uses the metadata stored on\nthe system.\n\nIt will display the latest stable versions of the charts found. If you\nspecify the --devel flag, the output will include pre-release versions.\nIf you want to search using a version constraint, use --version.\n\nExamples:\n\n    # Search for stable release versions matching the keyword \"nginx\"\n    $ helm search repo nginx\n\n    # Search for release versions matching the keyword \"nginx\", including pre-release versions\n    $ helm search repo nginx --devel\n\n    # Search for the latest stable release for nginx-ingress with a major version of 1\n    $ helm search repo nginx-ingress --version ^1.0.0\n\nRepositories are managed with 'helm repo' commands.\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### Options\n\n```\n      --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\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for repo\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n  -r, --regexp               use regular expressions for searching repositories you have added\n      --version string       search using semantic versioning constraints on repositories you have added\n  -l, --versions             show the long listing, with each version of each chart on its own line, for repositories you have added\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm search](/helm/helm_search.md)\t - search for a keyword in charts\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\nshow information of a chart\n\n### Synopsis\n\n\nThis command consists of multiple subcommands to display information about a chart\n\n\n### Options\n\n```\n  -h, --help   help for show\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm show all](/helm/helm_show_all.md)\t - show all information of the chart\n* [helm show chart](/helm/helm_show_chart.md)\t - show the chart's definition\n* [helm show crds](/helm/helm_show_crds.md)\t - show the chart's CRDs\n* [helm show readme](/helm/helm_show_readme.md)\t - show the chart's README\n* [helm show values](/helm/helm_show_values.md)\t - show the chart's values\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\nshow all information of the chart\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays all its content\n(values.yaml, Chart.yaml, README)\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for all\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\nshow the chart's definition\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the Chart.yaml file\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for chart\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\nshow the chart's CRDs\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the CustomResourceDefinition files\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for crds\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nshow the chart's README\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the README file\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for readme\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\nshow the chart's values\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the values.yaml file\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for values\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --jsonpath string            supply a JSONPath expression to filter the output\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\ndisplay the status of the named release\n\n### Synopsis\n\n\nThis command shows the status of a named release.\nThe status consists of:\n- last deployment time\n- k8s namespace in which the release lives\n- state of the release (can be: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade or pending-rollback)\n- revision of the release\n- description of the release (can be completion message or error message)\n- list of resources that this release consists of\n- details on last test suite run, if applicable\n- additional notes provided by the chart\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help            help for status\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    if set, display the status of the named release with revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nlocally render templates\n\n### Synopsis\n\n\nRender chart templates locally and display the output.\n\nAny values that would normally be looked up or retrieved in-cluster will be\nfaked locally. Additionally, none of the server-side testing of chart validity\n(e.g. whether an API is supported) is done.\n\nTo specify the Kubernetes API versions used for Capabilities.APIVersions, use\nthe '--api-versions' flag. This flag can be specified multiple times or as a\ncomma-separated list:\n\n    $ helm template --api-versions networking.k8s.io/v1 --api-versions cert-manager.io/v1 mychart ./mychart\n\nor\n\n    $ helm template --api-versions networking.k8s.io/v1,cert-manager.io/v1 mychart ./mychart\n\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### Options\n\n```\n  -a, --api-versions strings                       Kubernetes api versions used for Capabilities.APIVersions (multiple can be specified)\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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\")\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force-conflicts                            if set server-side apply will force changes against conflicts\n      --force-replace                              force resource updates by replacement\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for template\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --include-crds                               include CRDs in the templated output\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --is-upgrade                                 set .Release.IsUpgrade instead of .Release.IsInstall\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        Kubernetes version used for Capabilities.KubeVersion\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n      --output-dir string                          writes the executed templates to files in output-dir instead of stdout\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --post-renderer postRendererString           the name of a postrenderer type plugin to be used for post rendering. If it exists, the plugin will be used\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --release-name                               use release name in the output-dir path.\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    reuse the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --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\n      --server-side                                object updates run in the server instead of the client (default true)\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --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\"})\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n  -s, --show-only stringArray                      only show manifests rendered from the given templates\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --skip-tests                                 skip tests from templated output\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --wait WaitStrategy[=watcher]                if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly)\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\nrun tests for a release\n\n### Synopsis\n\n\nThe test command runs the tests for a release.\n\nThe argument this command takes is the name of a deployed release.\nThe tests to be run are defined in the chart that was installed.\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### Options\n\n```\n      --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)\n  -h, --help               help for test\n      --logs               dump the logs from test pods (this runs after all tests are complete, but before any cleanup)\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\nuninstall a release\n\n### Synopsis\n\n\nThis command takes a release name and uninstalls the release.\n\nIt removes all of the resources associated with the last release of the chart\nas well as the release history, freeing it up for future use.\n\nUse the '--dry-run' flag to see which releases will be uninstalled without actually\nuninstalling them.\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Options\n\n```\n      --cascade string                Must be \"background\", \"orphan\", or \"foreground\". Selects the deletion cascading strategy for the dependents. Defaults to background. (default \"background\")\n      --description string            add a custom description\n      --dry-run                       simulate a uninstall\n  -h, --help                          help for uninstall\n      --ignore-not-found              Treat \"release not found\" as a successful uninstall\n      --keep-history                  remove all associated resources and mark the release as deleted, but retain the release history\n      --no-hooks                      prevent hooks from running during uninstallation\n      --timeout duration              time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --wait WaitStrategy[=watcher]   if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nupgrade a release\n\n### Synopsis\n\n\nThis command upgrades a release to a new version of a chart.\n\nThe upgrade arguments must be a release and chart. The chart\nargument can be either: a chart reference('example/mariadb'), a path to a chart directory,\na packaged chart, or a fully qualified URL. For chart references, the latest\nversion will be specified unless the '--version' flag is set.\n\nTo override values in a chart, use either the '--values' flag and pass in a file\nor use the '--set' flag and pass configuration from the command line, to force string\nvalues, use '--set-string'. You can use '--set-file' to set individual\nvalues from a file when the value itself is too long for the command line\nor is dynamically generated. You can also use '--set-json' to set json values\n(scalars/objects/arrays) from the command line. Additionally, you can use '--set-json' and passing json object as a string.\n\nYou can specify the '--values'/'-f' flag multiple times. The priority will be given to the\nlast (right-most) file specified. For example, if both myvalues.yaml and override.yaml\ncontained a key called 'Test', the value set in override.yaml would take precedence:\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\nYou can specify the '--set' flag multiple times. The priority will be given to the\nlast (right-most) set specified. For example, if both 'bar' and 'newbar' values are\nset for a key called 'foo', the 'newbar' value would take precedence:\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\nYou can update the values for an existing release with this command as well via the\n'--reuse-values' flag. The 'RELEASE' and 'CHART' arguments should be set to the original\nparameters, and existing values will be merged with any values set via '--values'/'-f'\nor '--set' flags. Priority is given to new values.\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\nThe --dry-run flag will output all generated chart manifests, including Secrets\nwhich can contain sensitive values. To hide Kubernetes Secrets use the\n--hide-secret flag. Please carefully consider how and when these flags are used.\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --cleanup-on-fail                            allow deletion of new resources created in this upgrade when upgrade fails\n      --create-namespace                           if --install is set, create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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\")\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force-conflicts                            if set server-side apply will force changes against conflicts\n      --force-replace                              force resource updates by replacement\n  -h, --help                                       help for upgrade\n      --hide-notes                                 if set, do not show notes in upgrade output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --history-max int                            limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n  -i, --install                                    if a release by this name doesn't already exist, run an install\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -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 [])\n      --no-hooks                                   disable pre/post upgrade hooks\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --post-renderer postRendererString           the name of a postrenderer type plugin to be used for post rendering. If it exists, the plugin will be used\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --repo string                                chart repository url where to locate the requested chart\n      --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\n      --reset-values                               when upgrading, reset the values to the ones built into the chart\n      --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\n      --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\n      --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\")\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --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\"})\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --wait WaitStrategy[=watcher]                if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly)\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\nverify that a chart at the given path has been signed and is valid\n\n### Synopsis\n\n\nVerify that the given chart has a valid provenance file.\n\nProvenance files provide cryptographic verification that a chart has not been\ntampered with, and was packaged by a trusted provider.\n\nThis command can be used to verify a local chart. Several other commands provide\n'--verify' flags that run the same validation. To generate a signed package, use\nthe 'helm package --sign' command.\n\n\n```\nhelm verify PATH [flags]\n```\n\n### Options\n\n```\n  -h, --help             help for verify\n      --keyring string   keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n\nprint the helm version information\n\n### Synopsis\n\n\nShow the version for Helm.\n\nThis will print a representation the version of Helm.\nThe output will look something like this:\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version is the semantic version of the release.\n- GitCommit is the SHA for the commit that this version was built from.\n- GitTreeState is \"clean\" if there are no local code changes when this binary was\n  built, and \"dirty\" if the binary was built from locally modified code.\n- GoVersion is the version of Go that was used to compile Helm.\n\nWhen using the --template flag the following properties are available to use in\nthe template:\n\n- .Version contains the semantic version of Helm\n- .GitCommit is the git commit\n- .GitTreeState is the state of the git tree when Helm was built\n- .GoVersion contains the version of Go that Helm was compiled with\n\nFor example, --template='Version: {{.Version}}' outputs 'Version: v3.2.1'.\n\n\n```\nhelm version [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for version\n      --short             print the version number\n      --template string   template for version string format\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --color string                    use colored output (never, auto, always) (default \"auto\")\n      --colour string                   use colored output (never, auto, always) (default \"auto\")\n      --content-cache string            path to the directory containing cached content (e.g. charts) (default \"~/.cache/helm/content\")\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 9-Feb-2026\n"
  },
  {
    "path": "docs/helm/index.mdx",
    "content": "---\ntitle: Helm Commands\ndescription: Documentation for the full list of helm CLI commands.\nsidebar_position: 6\nid: helm-category\n---\n\n# Helm Commands\n\nHere you'll find the list of CLI commands for Helm, with help info on their usage.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "docs/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action to Automate GitHub Page Charts\ndescription: Describe how to use Chart Releaser Action to automate releasing charts through GitHub pages.\nsidebar_position: 3\n---\n\nThis guide describes how to use [Chart Releaser\nAction](https://github.com/marketplace/actions/helm-chart-releaser) to automate\nreleasing charts through GitHub pages.  Chart Releaser Action is a GitHub Action\nworkflow to turn a GitHub project into a self-hosted Helm chart repo, using\n[helm/chart-releaser](https://github.com/helm/chart-releaser) CLI tool.\n\n## Repository Changes\n\nCreate a Git repository under your GitHub organization.  You could give the name\nof the repository as `helm-charts`, though other names are also acceptable.  The\nsources of all the charts can be placed under the `main` branch.  The charts\nshould be placed under `/charts` directory at the top-level of the directory\ntree.\n\nThere should be another branch named `gh-pages` to publish the charts.  The\nchanges to that branch will be automatically created by the Chart Releaser\nAction described here.  However, you can create that `gh-branch` and add\n`README.md` file, which is going to be visible to the users visiting the page.\n\nYou can add instruction in the `README.md` for charts installation like this\n(replace `<alias>`, `<orgname>`, and `<chart-name>`):\n\n```\n## Usage\n\n[Helm](https://helm.sh) must be installed to use the charts.  Please refer to\nHelm's [documentation](https://helm.sh/docs) to get started.\n\nOnce Helm has been set up correctly, add the repo as follows:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nIf you had already added this repo earlier, run `helm repo update` to retrieve\nthe latest versions of the packages.  You can then run `helm search repo\n<alias>` to see the charts.\n\nTo install the <chart-name> chart:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nTo uninstall the chart:\n\n    helm uninstall my-<chart-name>\n```\n\nThe charts will be published to a website with URL like this:\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions Workflow\n\nCreate GitHub Actions workflow file in the `main` branch at\n`.github/workflows/release.yml`\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nThe above configuration uses\n[@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) to\nturn your GitHub project into a self-hosted Helm chart repo.  It does this -\nduring every push to main - by checking each chart in your project, and whenever\nthere's a new chart version, creates a corresponding GitHub release named for\nthe chart version, adds Helm chart artifacts to the release, and creates or\nupdates an `index.yaml` file with metadata about those releases, which is then\nhosted on GitHub pages.\n\nThe Chart Releaser Action version number used in the above example is `v1.6.0`.\nYou can change it to the [latest available\nversion](https://github.com/helm/chart-releaser-action/releases).\n\nNote: The Chart Releaser Action is almost always used in tandem with the [Helm Testing\nAction](https://github.com/marketplace/actions/helm-chart-testing) and [Kind\nAction](https://github.com/marketplace/actions/kind-cluster).\n"
  },
  {
    "path": "docs/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: Syncing Your Chart Repository\ndescription: Describes how to synchronize your local and remote chart repositories.\nsidebar_position: 2\n---\n\n*Note: This example is specifically for a Google Cloud Storage (GCS) bucket\nwhich serves a chart repository.*\n\n## Prerequisites\n* Install the [gsutil](https://cloud.google.com/storage/docs/gsutil) tool. *We\n  rely heavily on the gsutil rsync functionality*\n* Be sure to have access to the Helm binary\n* _Optional: We recommend you set [object\n  versioning](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)\n  on your GCS bucket in case you accidentally delete something._\n\n## Set up a local chart repository directory\nCreate a local directory like we did in [the chart repository guide](/topics/chart_repository.md), and place your packaged charts in that\ndirectory.\n\nFor example:\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Generate an updated index.yaml\nUse Helm to generate an updated index.yaml file by passing in the directory path\nand the url of the remote repository to the `helm repo index` command like this:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\nThis will generate an updated index.yaml file and place it in the\n`fantastic-charts/` directory.\n\n## Sync your local and remote chart repositories\nUpload the contents of the directory to your GCS bucket by running\n`scripts/sync-repo.sh` and pass in the local directory name and the GCS bucket\nname.\n\nFor example:\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## Updating your chart repository\nYou'll want to keep a local copy of the contents of your chart repository or use\n`gsutil rsync` to copy the contents of your remote chart repository to a local\ndirectory.\n\nFor example:\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nHelpful Links:\n* Documentation on [gsutil\n  rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [The Chart Repository Guide](/topics/chart_repository.md)\n* Documentation on [object versioning and concurrency\n  control](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)\n  in Google Cloud Storage\n"
  },
  {
    "path": "docs/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Chart Development Tips and Tricks\ndescription: Covers some of the tips and tricks Helm chart developers have learned while building production-quality charts.\nsidebar_position: 1\n---\n\nThis guide covers some of the tips and tricks Helm chart developers have learned\nwhile building production-quality charts.\n\n## Know Your Template Functions\n\nHelm uses [Go templates](https://godoc.org/text/template) for templating your\nresource files. While Go ships several built-in functions, we have added many\nothers.\n\nFirst, we added all of the functions in the [Sprig\nlibrary](https://masterminds.github.io/sprig/), except `env` and `expandenv`, for security reasons.\n\nWe also added two special template functions: `include` and `required`. The\n`include` function allows you to bring in another template, and then pass the\nresults to other template functions. The `required` function allows you to declare\na particular values entry as required for template rendering. If the value is empty,\nthe template rendering will fail with a user submitted error message.\n\n### Using the 'include' Function\n\nGo provides a way of including one template in another using a built-in\n`template` directive. However, the built-in function cannot be used in Go\ntemplate pipelines.\n\nTo make it possible to include a template, and then perform an operation on that\ntemplate's output, Helm has a special `include` function:\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nThe above includes a template called `toYaml`, passes it `$value`, and then\npasses the output of that template to the `indent` function.\n\nBecause YAML ascribes significance to indentation levels and whitespace, this is\none great way to include snippets of code, but handle indentation in a relevant\ncontext.\n\nThis template snippet includes a template called `mytpl`, then\nlowercases the result, then wraps that in double quotes.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\n### Using the 'required' function\n\nGo provides a `missingkey` template option to control behavior when a map is indexed\nwith a key that's not present in the map. There may be situations where a chart\ndeveloper wants to enforce this behavior for select values in the `values.yaml` file.\n\nThe `required` function gives developers the ability to declare a value entry as\nrequired for template rendering. If the entry is empty in `values.yaml`, the\ntemplate will not render and will return an error message supplied by the\ndeveloper.\n\nFor example:\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nThe above will render the template when `.Values.foo` is defined, but will fail\nto render and exit when `.Values.foo` is undefined.\n\nThe following example of the `required` function declares an entry for\n`.Values.who` is required, and will print an error message when that entry is\nmissing:\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## Quote Strings, Don't Quote Integers\n\nWhen you are working with string data, you are always safer quoting the strings\nthan leaving them as bare words:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nBut when working with integers _do not quote the values._ That can, in many\ncases, cause parsing errors inside of Kubernetes.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nThis remark does not apply to env variables values which are expected to be\nstring, even if they represent integers:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Using the 'tpl' Function\n\nThe `tpl` function allows developers to evaluate strings as templates inside a\ntemplate. This is useful to pass a template string as a value to a chart or\nrender external configuration files. Syntax: `{{ tpl TEMPLATE_STRING VALUES }}`\n\nExamples:\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\nRendering an external configuration file:\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## Creating Image Pull Secrets\nImage pull secrets are essentially a combination of _registry_, _username_, and\n_password_.  You may need them in an application you are deploying, but to\ncreate them requires running `base64` a couple of times.  We can write a helper\ntemplate to compose the Docker configuration file for use as the Secret's\npayload.  Here is an example:\n\nFirst, assume that the credentials are defined in the `values.yaml` file like\nso:\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nWe then define our helper template as follows:\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nFinally, we use the helper template in a larger template to create the Secret\nmanifest:\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Automatically Roll Deployments\n\nOften times ConfigMaps or Secrets are injected as configuration files in\ncontainers or there are other external dependency changes that require rolling\npods. Depending on the application a restart may be required should those be\nupdated with a subsequent `helm upgrade`, but if the deployment spec itself\ndidn't change the application keeps running with the old configuration resulting\nin an inconsistent deployment.\n\nThe `sha256sum` function can be used to ensure a deployment's annotation section\nis updated if another file changes:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nNOTE: If you're adding this to a library chart you won't be able to access your\nfile in `$.Template.BasePath`. Instead you can reference your definition with\n`{{ include (\"mylibchart.configmap\") . | sha256sum }}`.\n\nIn the event you always want to roll your deployment, you can use a similar\nannotation step as above, instead replacing with a random string so it always\nchanges and causes the deployment to roll:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nEach invocation of the template function will generate a unique random string.\nThis means that if it's necessary to sync the random strings used by multiple\nresources, all relevant resources will need to be in the same template file.\n\nBoth of these methods allow your Deployment to leverage the built in update\nstrategy logic to avoid taking downtime.\n\nNOTE: In the past we recommended using the `--recreate-pods` flag as another\noption. This flag has been marked as deprecated in Helm 3 in favor of the more\ndeclarative method above.\n\n## Tell Helm Not To Uninstall a Resource\n\nSometimes there are resources that should not be uninstalled when Helm runs a\n`helm uninstall`. Chart developers can add an annotation to a resource to\nprevent it from being uninstalled.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nThe annotation `helm.sh/resource-policy: keep` instructs Helm to skip deleting\nthis resource when a helm operation (such as `helm uninstall`, `helm upgrade` or\n`helm rollback`) would result in its deletion. _However_, this resource becomes\norphaned. Helm will no longer manage it in any way. This can lead to problems if\nusing `helm install --replace` on a release that has already been uninstalled,\nbut has kept resources.\n\n## Using \"Partials\" and Template Includes\n\nSometimes you want to create some reusable parts in your chart, whether they're\nblocks or template partials. And often, it's cleaner to keep these in their own\nfiles.\n\nIn the `templates/` directory, any file that begins with an underscore(`_`) is\nnot expected to output a Kubernetes manifest file. So by convention, helper\ntemplates and partials are placed in a `_helpers.tpl` file.\n\n## Complex Charts with Many Dependencies\n\nMany of the charts in the CNCF [Artifact\nHub](https://artifacthub.io/packages/search?kind=0) are \"building blocks\" for\ncreating more advanced applications. But charts may be used to create instances\nof large-scale applications. In such cases, a single umbrella chart may have\nmultiple subcharts, each of which functions as a piece of the whole.\n\nThe current best practice for composing a complex application from discrete\nparts is to create a top-level umbrella chart that exposes the global\nconfigurations, and then use the `charts/` subdirectory to embed each of the\ncomponents.\n\n## YAML is a Superset of JSON\n\nAccording to the YAML specification, YAML is a superset of JSON. That means that\nany valid JSON structure ought to be valid in YAML.\n\nThis has an advantage: Sometimes template developers may find it easier to\nexpress a datastructure with a JSON-like syntax rather than deal with YAML's\nwhitespace sensitivity.\n\nAs a best practice, templates should follow a YAML-like syntax _unless_ the JSON\nsyntax substantially reduces the risk of a formatting issue.\n\n## Be Careful with Generating Random Values\n\nThere are functions in Helm that allow you to generate random data,\ncryptographic keys, and so on. These are fine to use. But be aware that during\nupgrades, templates are re-executed. When a template run generates data that\ndiffers from the last run, that will trigger an update of that resource.\n\n## Install or Upgrade a Release with One Command\n\nHelm provides a way to perform an install-or-upgrade as a single command. Use\n`helm upgrade` with the `--install` command. This will cause Helm to see if the\nrelease is already installed. If not, it will run an install. If it is, then the\nexisting release will be upgraded.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "docs/howto/index.mdx",
    "content": "---\ntitle: How-to\nsidebar_position: 3\n---\n\n# How-to Guides\n\nHere you’ll find short answers to “How do I….?” types of questions. These how-to\nguides don’t cover topics in depth – you’ll find that material in the [Topic\nGuides](/topics/index.mdx). However, these guides will help you quickly accomplish\ncommon tasks.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "docs/index.mdx",
    "content": "---\ntitle: Docs Home\ndescription: Everything you need to know about how the documentation is organized.\nsidebar_position: 1\n---\n\n# Welcome\n\nWelcome to the [Helm](https://helm.sh/) documentation. Helm is the package\nmanager for Kubernetes, and you can read detailed background information in the\n[CNCF Helm Project Journey\nreport](https://www.cncf.io/cncf-helm-project-journey/).\n\nimport DocCardList from \"@theme/DocCardList\";\n\n<DocCardList />\n"
  },
  {
    "path": "docs/intro/CheatSheet.mdx",
    "content": "---\ntitle: Cheat Sheet\ndescription: Helm cheatsheet\nsidebar_position: 4\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm cheatsheet featuring all the necessary commands required to manage an application through Helm.\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### Basic interpretations/context\n\nChart:\n- It is the name of your chart in case it has been pulled and untarred.\n- It is `<repo_name>/<chart_name>` in case the repository has been added but chart not pulled.\n- It is the URL/Absolute path to the chart.\n\nName:\n- It is the name you want to give to your current helm chart installation.\n\nRelease:\n- Is the name you assigned to an installation instance.\n\nRevision:\n- Is the value from the Helm history command\n\nRepo-name:\n- The name of a repository.\n\nDIR:\n- Directory name/path\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Chart Management\n\n```bash\nhelm create <name>                      # Creates a chart directory along with the common files and directories used in a chart.\nhelm package <chart-path>               # Packages a chart into a versioned chart archive file.\nhelm lint <chart>                       # Run tests to examine a chart and identify possible issues:\nhelm show all <chart>                   # Inspect a chart and list its contents:\nhelm show values <chart>                # Displays the contents of the values.yaml file\nhelm pull <chart>                       # Download/pull chart\nhelm pull <chart> --untar=true          # If set to true, will untar the chart after downloading it\nhelm pull <chart> --verify              # Verify the package before using it\nhelm pull <chart> --version <number>    # Default-latest is used, specify a version constraint for the chart version to use\nhelm dependency list <chart>            # Display a list of a chart’s dependencies:\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Install and Uninstall Apps\n\n```bash\nhelm install <name> <chart>                           # Install the chart with a name\nhelm install <name> <chart> --namespace <namespace>   # Install the chart in a specific namespace\nhelm install <name> <chart> --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas)\nhelm install <name> <chart> --values <yaml-file/url>  # Install the chart with your specified values\nhelm install <name> <chart> --dry-run --debug         # Run a test installation to validate chart (p)\nhelm install <name> <chart> --verify                  # Verify the package before using it\nhelm install <name> <chart> --dependency-update       # update dependencies if they are missing before installing the chart\nhelm uninstall <name>                                 # Uninstalls a release from the current (default) namespace\nhelm uninstall <release-name> --namespace <namespace> # Uninstalls a release from the specified namespace\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Perform App Upgrade and Rollback\n\n```bash\nhelm upgrade <release> <chart>                            # Upgrade a release\nhelm upgrade <release> <chart> --rollback-on-failure      # If set, upgrade process rolls back changes made in case of failed upgrade.\nhelm upgrade <release> <chart> --dependency-update        # update dependencies if they are missing before installing the chart\nhelm upgrade <release> <chart> --version <version_number> # specify a version constraint for the chart version to use\nhelm upgrade <release> <chart> --values                   # specify values in a YAML file or a URL (can specify multiple)\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Set values on the command line (can specify multiple or separate valuese)\nhelm upgrade <release> <chart> --force                    # Force resource updates through a replacement strategy\nhelm rollback <release> <revision>                        # Roll back a release to a specific revision\nhelm rollback <release> <revision>  --cleanup-on-fail     # Allow deletion of new resources created in this rollback when rollback fails\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### List, Add, Remove, and Update Repositories\n\n```bash\nhelm repo add <repo-name> <url>   # Add a repository from the internet:\nhelm repo list                    # List added chart repositories\nhelm repo update                  # Update information of available charts locally from chart repositories\nhelm repo remove <repo_name>      # Remove one or more chart repositories\nhelm repo index <DIR>             # Read the current directory and generate an index file based on the charts found.\nhelm repo index <DIR> --merge     # Merge the generated index with an existing index file\nhelm search repo <keyword>        # Search repositories for a keyword in charts\nhelm search hub <keyword>         # Search for charts in the Artifact Hub or your own hub instance\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Helm Release monitoring\n\n```bash\nhelm list                       # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified\nhelm list --all                 # Show all releases without any filter applied, can use -a\nhelm list --all-namespaces      # List releases across all namespaces, we can use -A\nhelm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!='\nhelm list --date                # Sort by release date\nhelm list --deployed            # Show deployed releases. If no other is specified, this will be automatically enabled\nhelm list --pending             # Show pending releases\nhelm list --failed              # Show failed releases\nhelm list --uninstalled         # Show uninstalled releases (if 'helm uninstall --keep-history' was used)\nhelm list --superseded          # Show superseded releases\nhelm list -o yaml               # Prints the output in the specified format. Allowed values: table, json, yaml (default table)\nhelm status <release>           # This command shows the status of a named release.\nhelm status <release> --revision <number>   # if set, display the status of the named release with revision\nhelm history <release>          # Historical revisions for a given release.\nhelm env                        # Env prints out all the environment information in use by Helm.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Download Release Information\n\n```bash\nhelm get all <release>      # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release.\nhelm get hooks <release>    # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\\n' separator.\nhelm get manifest <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.\nhelm get notes <release>    # Shows notes provided by the chart of a named release.\nhelm get values <release>   # Downloads a values file for a given release. use -o to format output\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Plugin Management\n\n```bash\nhelm plugin install <path/url>      # Install plugins\nhelm plugin list                    # View a list of all installed plugins\nhelm plugin update <plugin>         # Update plugins\nhelm plugin uninstall <plugin>      # Uninstall a plugin\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "docs/intro/index.mdx",
    "content": "---\ntitle: Introduction\nsidebar_position: 2\n---\n\n# Introduction to Helm\n\nAre you new to Helm? This is the place to start!\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "docs/intro/install.mdx",
    "content": "---\ntitle: Installing Helm\ndescription: Learn how to install and get running with Helm.\nsidebar_position: 2\n---\n\nThis guide shows how to install the Helm CLI. Helm can be installed either from\nsource, or from pre-built binary releases.\n\n## From The Helm Project\n\nThe Helm project provides two ways to fetch and install Helm. These are the\nofficial methods to get Helm releases. In addition to that, the Helm community\nprovides methods to install Helm through different package managers.\nInstallation through those methods can be found below the official methods.\n\n### From the Binary Releases\n\nEvery [release](https://github.com/helm/helm/releases) of Helm provides binary\nreleases for a variety of OSes. These binary versions can be manually downloaded\nand installed.\n\n1. Download your [desired version](https://github.com/helm/helm/releases)\n1. Verify the binary. See [Verifying Helm Binaries](#verifying-helm-binaries) on this page.\n1. Unpack it (`tar -zxvf helm-v4.0.0-linux-amd64.tar.gz`)\n1. Find the `helm` binary in the unpacked directory, and move it to its desired\n   destination (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nFrom there, you should be able to run the client and [add the stable\nchart repository](/intro/quickstart.md#initialize-a-helm-chart-repository):\n`helm help`.\n\n**Note:** Helm automated tests are performed for Linux AMD64 only during\nGitHub Actions builds and releases. Testing of other OSes are the responsibility of\nthe community requesting Helm for the OS in question.\n\n### From Script\n\nHelm now has an installer script that will automatically grab the latest version\nof Helm and [install it\nlocally](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4).\n\nYou can fetch that script, and then execute it locally. It's well documented so\nthat you can read through it and understand what it is doing before you run it.\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\nYes, you can `curl\nhttps://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 | bash` if\nyou want to live on the edge.\n\n## Through Package Managers\n\nThe Helm community provides the ability to install Helm through operating system\npackage managers. These are not supported by the Helm project and are not\nconsidered trusted 3rd parties.\n\n### From Homebrew (macOS)\n\nMembers of the Helm community have contributed a Helm formula build to Homebrew.\nThis formula is generally up to date.\n\n```console\nbrew install helm\n```\n\n(Note: There is also a formula for emacs-helm, which is a different project.)\n\n### From Chocolatey (Windows)\n\nMembers of the Helm community have contributed a [Helm\npackage](https://chocolatey.org/packages/kubernetes-helm) build to\n[Chocolatey](https://chocolatey.org/). This package is generally up to date.\n\n```console\nchoco install kubernetes-helm\n```\n\n### From Scoop (Windows)\n\nMembers of the Helm community have contributed a [Helm\npackage](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) build to [Scoop](https://scoop.sh). This package is generally up to date.\n\n```console\nscoop install helm\n```\n\n### From Winget (Windows)\n\nMembers of the Helm community have contributed a [Helm\npackage](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.\n\n```console\nwinget install Helm.Helm\n```\n\n### From Apt (Debian/Ubuntu)\n\nMembers of the Helm community have contributed an Apt package for Debian/Ubuntu. This package is\ngenerally up to date. Thanks to [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) for hosting the repo.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### From dnf/yum (fedora)\nSince Fedora 35, Helm is available on the official repository.\nYou can install Helm by invoking:\n\n```console\nsudo dnf install helm\n```\n\n### From Snap\n\nThe [Snapcrafters](https://github.com/snapcrafters) community maintains the Snap\nversion of the [Helm package](https://snapcraft.io/helm):\n\n```console\nsudo snap install helm --classic\n```\n\n### From pkg (FreeBSD)\n\nMembers of the FreeBSD community have contributed a [Helm\npackage](https://www.freshports.org/sysutils/helm) build to the\n[FreeBSD Ports Collection](https://man.freebsd.org/ports).\nThis package is generally up to date.\n\n```console\npkg install helm\n```\n\n### Development Builds\n\nIn addition to releases you can download or install development snapshots of\nHelm.\n\n### From Canary Builds\n\n\"Canary\" builds are versions of the Helm software that are built from the latest\n`main` branch. They are not official releases, and may not be stable. However,\nthey offer the opportunity to test the cutting edge features.\n\nCanary Helm binaries are stored at `get.helm.sh`. Here are\nlinks to the common builds:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows\n  AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### From Source (Linux, macOS)\n\nBuilding Helm from source is slightly more work, but is the best way to go if\nyou want to test the latest Helm version.\n\nYou must have a working Go environment.\n\n```console\ngit clone https://github.com/helm/helm.git\ncd helm\nmake\n```\n\nIf required, it will fetch the dependencies and cache them, and validate\nconfiguration. It will then compile `helm` and place it in `bin/helm`.\n\n## Verifying Helm Binaries\n\nEach Helm release includes cryptographic signatures that confirm the binary was built and signed by Helm maintainers.\nTo help protect against supply chain attacks, you should always verify the authenticity of Helm binaries before installing.\n\nPublished release assets on `get.helm.sh` (served through a CDN) generally cannot be altered after a GitHub release is published.\nHowever, the supply chain involves multiple components (CDN, hosting infrastructure, and so on),\nso signature verification is important even for older or pinned versions.\n\n### Requirements\n\nTo verify a Helm binary, you need the following:\n\n* The binary archive (for example, `helm-v4.0.0-linux-amd64.tar.gz`)\n* The corresponding signature file (for example, `helm-v4.0.0-linux-amd64.tar.gz.asc`)\n* The Helm maintainers' public PGP keys\n\n### Verification Steps\n\nTo verify a Helm binary:\n\n1. Verify the SHA256 checksum to confirm the download wasn't corrupted. For example:\n\n   ```console\n   $ sha256sum -c helm-v4.0.0-linux-amd64.tar.gz.sha256sum\n   helm-v4.0.0-linux-amd64.tar.gz: OK\n   ```\n\n1. Import the Helm maintainers' public keys:\n\n   ```console\n   $ curl https://raw.githubusercontent.com/helm/helm/main/KEYS | gpg --import\n   ```\n   :::note\n   Avoid fetching keys from the Helm repository each time you verify a Helm binary.\n   Instead, import the keys one time and then store them in a secure location you control.\n   This protects you if the repository is ever compromised and keys are swapped;\n   your local copy lets you detect the tampering.\n\n   You can also cross-check maintainer keys on [Keybase](https://keybase.io), where Helm maintainers have profiles linking their identities to their PGP keys.\n   :::\n\n1. Verify the binary's signature. For example:\n\n   ```console\n   $ gpg --verify helm-v4.0.0-linux-amd64.tar.gz.asc helm-v4.0.0-linux-amd64.tar.gz\n   gpg: Signature made [date] using RSA key ID [key-id]\n   gpg: Good signature from \"Helm Maintainer <maintainer@example.com>\"\n   ```\n\n   A \"Good signature\" message confirms the binary is authentic and hasn't been tampered with.\n\n   :::note\n   Signature files are safe to pull from upstream as long as you have trusted copies of the public keys.\n   An attacker cannot forge a valid signature without the private key, which only the legitimate maintainer has.\n   :::\n\n## FAQ\n\n### Why aren't there native packages of Helm for Fedora and other Linux distros?\n\nThe Helm project does not maintain packages for operating systems and\nenvironments. The Helm community may provide native packages and if the Helm\nproject is made aware of them they will be listed. This is how the Homebrew\nformula was started and listed. If you're interested in maintaining a package,\nwe'd love it.\n\n### Why do you provide a `curl ...|bash` script?\n\nThere is a script in our repository (`scripts/get-helm-4`) that can be executed\nas a `curl ..|bash` script. The transfers are all protected by HTTPS, and the\nscript does some auditing of the packages it fetches. However, the script has\nall the usual dangers of any shell script.\n\nWe provide it because it is useful, but we suggest that users carefully read the\nscript first. What we'd really like, though, are better packaged releases of\nHelm.\n\n### How do I put the Helm client files somewhere other than their defaults?\n\nHelm uses the XDG structure for storing files. There are environment variables\nyou can use to override these locations:\n\n- `$XDG_CACHE_HOME`: set an alternative location for storing cached files.\n- `$XDG_CONFIG_HOME`: set an alternative location for storing Helm\n  configuration.\n- `$XDG_DATA_HOME`: set an alternative location for storing Helm data.\n\nNote that if you have existing repositories, you will need to re-add them with\n`helm repo add...`.\n\n### I want to delete my local Helm. Where are all its files?\n\nAlong with the `helm` binary, Helm stores some files in the following locations:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nThe following table gives the default folder for each of these, by OS:\n\n| Operating System | Cache Path                  | Configuration Path               | Data Path                 |\n|------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux            | `$HOME/.cache/helm`         | `$HOME/.config/helm`             | `$HOME/.local/share/helm` |\n| macOS            | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm`      |\n| Windows          | `%TEMP%\\helm`               | `%APPDATA%\\helm`                 | `%APPDATA%\\helm`          |\n\n## Conclusion\n\nIn most cases, installation is as simple as getting a pre-built `helm` binary.\nThis document covers additional cases for those who want to do more\nsophisticated things with Helm.\n\nOnce you have the Helm Client successfully installed, you can move on to using\nHelm to manage charts and [add the stable\nchart repository](/intro/quickstart.md#initialize-a-helm-chart-repository).\n"
  },
  {
    "path": "docs/intro/quickstart.md",
    "content": "---\ntitle: Quickstart Guide\ndescription: How to install and get started with Helm including instructions for distros, FAQs, and plugins.\nsidebar_position: 1\n---\n\nThis guide covers how you can quickly get started using Helm.\n\n## Prerequisites\n\nThe following prerequisites are required for a successful and properly secured\nuse of Helm.\n\n1. A Kubernetes cluster\n2. Deciding what security configurations to apply to your installation, if any\n3. Installing and configuring Helm.\n\n### Install Kubernetes or have access to a cluster\n\n- You must have Kubernetes installed. For the latest release of Helm, we\n  recommend the latest stable release of Kubernetes, which in most cases is the\n  second-latest minor release.\n- You should also have a local configured copy of `kubectl`.\n\nSee the [Helm Version Support Policy](https://helm.sh/docs/topics/version_skew/) for the maximum version skew supported between Helm and Kubernetes.\n\n## Install Helm\n\nDownload a binary release of the Helm client. You can use tools like `homebrew`,\nor look at [the official releases page](https://github.com/helm/helm/releases).\n\nFor more details, or for other options, see [the installation guide](/intro/install.mdx).\n\n## Initialize a Helm Chart Repository\n\nOnce you have Helm ready, you can add a chart repository. Check [Artifact\nHub](https://artifacthub.io/packages/search?kind=0) for available Helm chart\nrepositories.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nOnce this is installed, you will be able to list the charts you can install:\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## Install an Example Chart\n\nTo install a chart, you can run the `helm install` command. Helm has several\nways to find and install a chart, but the easiest is to use the `bitnami`\ncharts.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nIn the example above, the `bitnami/mysql` chart was released, and the name of\nour new release is `mysql-1612624192`.\n\nYou get a simple idea of the features of this MySQL chart by running `helm show\nchart bitnami/mysql`. Or you could run `helm show all bitnami/mysql` to get all\ninformation about the chart.\n\nWhenever you install a chart, a new release is created. So one chart can be\ninstalled multiple times into the same cluster. And each can be independently\nmanaged and upgraded.\n\nThe `helm install` command is a very powerful command with many capabilities. To\nlearn more about it, check out the [Using Helm Guide](/intro/using_helm.mdx)\n\n## Learn About Releases\n\nIt's easy to see what has been released using Helm:\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nThe `helm list` (or `helm ls`) function will show you a list of all deployed releases.\n\n## Uninstall a Release\n\nTo uninstall a release, use the `helm uninstall` command:\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nThis will uninstall `mysql-1612624192` from Kubernetes, which will remove all\nresources associated with the release as well as the release history.\n\nIf the flag `--keep-history` is provided, release history will be kept. You will\nbe able to request information about that release:\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nBecause Helm tracks your releases even after you've uninstalled them, you can\naudit a cluster's history, and even undelete a release (with `helm rollback`).\n\n## Reading the Help Text\n\nTo learn more about the available Helm commands, use `helm help` or type a\ncommand followed by the `-h` flag:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "docs/intro/using_helm.mdx",
    "content": "---\ntitle: Using Helm\ndescription: Explains the basics of Helm.\nsidebar_position: 3\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nThis guide explains the basics of using Helm to manage packages on your\nKubernetes cluster. It assumes that you have already [installed](/intro/install.mdx) the Helm client.\n\nIf you are simply interested in running a few quick commands, you may wish to\nbegin with the [Quickstart Guide](/intro/quickstart.md). This chapter\ncovers the particulars of Helm commands, and explains how to use Helm.\n\n## Three Big Concepts\n\nA *Chart* is a Helm package. It contains all of the resource definitions\nnecessary to run an application, tool, or service inside of a Kubernetes\ncluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an\nApt dpkg, or a Yum RPM file.\n\nA *Repository* is the place where charts can be collected and shared. It's like\nPerl's [CPAN archive](https://www.cpan.org) or the [Fedora Package\nDatabase](https://src.fedoraproject.org/), but for Kubernetes packages.\n\nA *Release* is an instance of a chart running in a Kubernetes cluster. One chart\ncan often be installed many times into the same cluster. And each time it is\ninstalled, a new _release_ is created. Consider a MySQL chart. If you want two\ndatabases running in your cluster, you can install that chart twice. Each one\nwill have its own _release_, which will in turn have its own _release name_.\n\nWith these concepts in mind, we can now explain Helm like this:\n\nHelm installs _charts_ into Kubernetes, creating a new _release_ for each\ninstallation. And to find new charts, you can search Helm chart _repositories_.\n\n## 'helm search': Finding Charts\n\nHelm comes with a powerful search command. It can be used to search two\ndifferent types of source:\n\n- `helm search hub` searches [the Artifact Hub](https://artifacthub.io), which\n  lists helm charts from dozens of different repositories.\n- `helm search repo` searches the repositories that you have added to your local\n  helm client (with `helm repo add`). This search is done over local data, and\n  no public network connection is needed.\n\nYou can find publicly available charts by running `helm search hub`:\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\nThe above searches for all `wordpress` charts on Artifact Hub.\n\nWith no filter, `helm search hub` shows you all of the available charts.\n\n`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\nadd [NAME] [URL]`.\n\nUsing `helm search repo`, you can find the names of the charts in repositories\nyou have already added:\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nHelm search uses a fuzzy string matching algorithm, so you can type parts of\nwords or phrases:\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nSearch is a good way to find available packages. Once you have found a package\nyou want to install, you can use `helm install` to install it.\n\n## 'helm install': Installing a Package\n\nTo install a new package, use the `helm install` command. At its simplest, it\ntakes two arguments: A release name that you pick, and the name of the chart you\nwant to install.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nNow the `wordpress` chart is installed. Note that installing a chart creates a\nnew _release_ object. The release above is named `happy-panda`. (If you want\nHelm to generate a name for you, leave off the release name and use\n`--generate-name`.)\n\nDuring installation, the `helm` client will print useful information about which\nresources were created, what the state of the release is, and also whether there\nare additional configuration steps you can or should take.\n\nHelm installs resources in the following order:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nHelm does not wait until all of the resources are running before it exits. Many\ncharts require Docker images that are over 600MB in size, and may take a long\ntime to install into the cluster.\n\nTo keep track of a release's state, or to re-read configuration information, you\ncan use `helm status`:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nThe above shows the current state of your release.\n\n### Customizing the Chart Before Installing\n\nInstalling the way we have here will only use the default configuration options\nfor this chart. Many times, you will want to customize the chart to use your\npreferred configuration.\n\nTo see what options are configurable on a chart, use `helm show values`:\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nYou can then override any of these settings in a YAML formatted file, and then\npass that file during installation.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nThe above will create a default MariaDB user with the name `user0`, and grant\nthis user access to a newly created `user0db` database, but will accept all the\nrest of the defaults for that chart.\n\nThere are two ways to pass configuration data during install:\n\n- `--values` (or `-f`): Specify a YAML file with overrides. This can be\n  specified multiple times and the rightmost file will take precedence\n- `--set`: Specify overrides on the command line.\n\nIf both are used, `--set` values are merged into `--values` with higher\nprecedence. Overrides specified with `--set` are persisted in a Secret.\nValues that have been `--set` can be viewed for a given release with `helm get\nvalues <release-name>`. Values that have been `--set` can be cleared by running\n`helm upgrade` with `--reset-values` specified.\n\n#### The Format and Limitations of `--set`\n\nThe `--set` option takes zero or more name/value pairs. At its simplest, it is\nused like this: `--set name=value`. The YAML equivalent of that is:\n\n```yaml\nname: value\n```\n\nMultiple values are separated by `,` characters. So `--set a=b,c=d` becomes:\n\n```yaml\na: b\nc: d\n```\n\nMore complex expressions are supported. For example, `--set outer.inner=value`\nis translated into this:\n```yaml\nouter:\n  inner: value\n```\n\nLists can be expressed by enclosing values in `{` and `}`. For example, `--set\nname={a, b, c}` translates to:\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nCertain name/key can be set to be `null` or to be an empty array `[]`. For example, `--set name=[],a=null` translates\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\nto\n\n```yaml\nname: []\na: null\n```\n\nAs of Helm 2.5.0, it is possible to access list items using an array index\nsyntax. For example, `--set servers[0].port=80` becomes:\n\n```yaml\nservers:\n  - port: 80\n```\n\nMultiple values can be set this way. The line `--set\nservers[0].port=80,servers[0].host=example` becomes:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nSometimes you need to use special characters in your `--set` lines. You can use\na backslash to escape the characters; `--set name=value1\\,value2` will become:\n\n```yaml\nname: \"value1,value2\"\n```\n\nSimilarly, you can escape dot sequences as well, which may come in handy when\ncharts use the `toYaml` function to parse annotations, labels and node\nselectors. The syntax for `--set nodeSelector.\"kubernetes\\.io/role\"=master`\nbecomes:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nDeeply nested data structures can be difficult to express using `--set`. Chart\ndesigners are encouraged to consider the `--set` usage when designing the format\nof a `values.yaml` file  (read more about [Values Files](/chart_template_guide/values_files.mdx)).\n\n### More Installation Methods\n\nThe `helm install` command can install from several sources:\n\n- A chart repository (as we've seen above)\n- A local chart archive (`helm install foo foo-0.1.1.tgz`)\n- An unpacked chart directory (`helm install foo path/to/foo`)\n- A full URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' and 'helm rollback': Upgrading a Release, and Recovering on Failure\n\nWhen a new version of a chart is released, or when you want to change the\nconfiguration of your release, you can use the `helm upgrade` command.\n\nAn upgrade takes an existing release and upgrades it according to the\ninformation you provide. Because Kubernetes charts can be large and complex,\nHelm tries to perform the least invasive upgrade. It will only update things\nthat have changed since the last release.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nIn the above case, the `happy-panda` release is upgraded with the same chart,\nbut with a new YAML file:\n\n```yaml\nmariadb.auth.username: user1\n```\n\nWe can use `helm get values` to see whether that new setting took effect.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nThe `helm get` command is a useful tool for looking at a release in the cluster.\nAnd as we can see above, it shows that our new values from `panda.yaml` were\ndeployed to the cluster.\n\nNow, if something does not go as planned during a release, it is easy to roll\nback to a previous release using `helm rollback [RELEASE] [REVISION]`.\n\n```console\n$ helm rollback happy-panda 1\n```\n\nThe above rolls back our happy-panda to its very first release version. A\nrelease version is an incremental revision. Every time an install, upgrade, or\nrollback happens, the revision number is incremented by 1. The first revision\nnumber is always 1. And we can use `helm history [RELEASE]` to see revision\nnumbers for a certain release.\n\n## Helpful Options for Install/Upgrade/Rollback\n\nThere are several other helpful options you can specify for customizing the\nbehavior of Helm during an install/upgrade/rollback. Please note that this is\nnot a full list of cli flags. To see a description of all flags, just run `helm\n<command> --help`.\n\n- `--timeout`: A [Go duration](https://golang.org/pkg/time/#ParseDuration) value\n  to wait for Kubernetes commands to complete. This defaults to `5m0s`.\n- `--wait`: Waits until all Pods are in a ready state, PVCs are bound,\n  Deployments have minimum (`Desired` minus `maxUnavailable`) Pods in ready\n  state and Services have an IP address (and Ingress if a `LoadBalancer`) before\n  marking the release as successful. It will wait for as long as the `--timeout`\n  value. If timeout is reached, the release will be marked as `FAILED`. Note: In\n  scenarios where Deployment has `replicas` set to 1 and `maxUnavailable` is not\n  set to 0 as part of rolling update strategy, `--wait` will return as ready as\n  it has satisfied the minimum Pod in ready condition.\n- `--no-hooks`: This skips running hooks for the command\n- `--recreate-pods` (only available for `upgrade` and `rollback`): This flag\n  will cause all pods to be recreated (with the exception of pods belonging to\n  deployments). (DEPRECATED in Helm 3)\n\n## 'helm uninstall': Uninstalling a Release\n\nWhen it is time to uninstall a release from the cluster, use the `helm\nuninstall` command:\n\n```console\n$ helm uninstall happy-panda\n```\n\nThis will remove the release from the cluster. You can see all of your currently\ndeployed releases with the `helm list` command:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nFrom the output above, we can see that the `happy-panda` release was\nuninstalled.\n\nIn previous versions of Helm, when a release was deleted, a record of its\ndeletion would remain. In Helm 3, deletion removes the release record as well.\nIf you wish to keep a deletion release record, use `helm uninstall\n--keep-history`. Using `helm list --uninstalled` will only show releases that\nwere uninstalled with the `--keep-history` flag.\n\nThe `helm list --all` flag will show you all release records that Helm has\nretained, including records for failed or deleted items (if `--keep-history` was\nspecified):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nNote that because releases are now deleted by default, it is no longer possible\nto rollback an uninstalled resource.\n\n## 'helm repo': Working with Repositories\n\nHelm 3 no longer ships with a default chart repository. The `helm repo` command\ngroup provides commands to add, list, and remove repositories.\n\nYou can see which repositories are configured using `helm repo list`:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nAnd new repositories can be added with `helm repo\nadd [NAME] [URL]`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nBecause chart repositories change frequently, at any point you can make sure\nyour Helm client is up to date by running `helm repo update`.\n\nRepositories can be removed with `helm repo remove`.\n\n## Creating Your Own Charts\n\nThe [Chart Development Guide](/topics/charts.mdx) explains how\nto develop your own charts. But you can get started quickly by using the `helm\ncreate` command:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nNow there is a chart in `./deis-workflow`. You can edit it and create your own\ntemplates.\n\nAs you edit your chart, you can validate that it is well-formed by running `helm\nlint`.\n\nWhen it's time to package the chart up for distribution, you can run the `helm\npackage` command:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nAnd that chart can now easily be installed by `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nCharts that are packaged can be loaded into chart repositories. See the\ndocumentation for [Helm chart\nrepositories](/topics/chart_repository.md) for more details.\n\n## Conclusion\n\nThis chapter has covered the basic usage patterns of the `helm` client,\nincluding searching, installation, upgrading, and uninstalling. It has also\ncovered useful utility commands like `helm status`, `helm get`, and `helm repo`.\n\nFor more information on these commands, take a look at Helm's built-in help:\n`helm help`.\n\nIn the [next chapter](/howto/charts_tips_and_tricks.md), we look at the process of developing charts.\n"
  },
  {
    "path": "docs/overview.md",
    "content": "---\nsidebar_position: 1\nsidebar_label: Helm 4 Overview\n---\n\n# Helm 4 Overview\n\nHelm v4 represents a significant evolution from v3, introducing breaking changes, new architectural patterns, and enhanced functionality while maintaining backwards compatibility for charts.\n\nFor more information about the planned Helm 4 release phases, see [Path to Helm v4](https://helm.sh/blog/path-to-helm-v4/).\n\n## What's New\n\nThis 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).\n\n### Summary\n\n- **New features**: Wasm-based plugins, kstatus watcher, OCI digest support, multi-doc values, JSON arguments\n- **Architecture changes**: Plugin system completely redesigned, package restructuring, CLI flag renaming, move to versioned packages, chart v3 support, content-based caching\n- **Modernization**: slog migration, Go 1.24 update, dependency cleanup\n- **Security**: Enhanced OCI/registry support, TLS improvements\n\n### Breaking Changes\n\n#### Post-renderers implemented as plugins\nPost-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.\n\n#### Registry login does not accept full URLs\nThe `helm registry login` command must be done with the domain name only in v4.\nThis is so login can be scoped at different levels on a registry in the future.\n\n### New Features\n\n#### Plugin System Overhaul\nHelm 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).\n\n:::tip\nExisting plugins work as before. The new WebAssembly runtime is optional but recommended for enhanced security.\n:::\n\n#### Better resource monitoring\nNew kstatus integration shows detailed status of your deployments. Test with complex applications to see if it catches issues better.\n\n#### Enhanced OCI Support\nInstall 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.\n\n#### Multi-Document Values\nSplit complex values across multiple YAML files. Perfect for testing different environment configs.\n\n#### Server-Side Apply\nBetter conflict resolution when multiple tools manage the same resources. Test in environments with operators or other controllers.\n\nHelm 4 will default to server-side apply when installing a new Chart release.\n\nWhen upgrading (or rolling back), Helm will by default follow the previous apply method of the release.\nThis latching behavior is done to ensure continuity of operation for existing releases that used client-side apply.\nThe behavior can be overridden by setting the `--server-side` flag explicitly.\n\nAs such, all releases created by Helm 3 will default to using client-side apply after upgrading to Helm 4.\n\n#### Custom Template Functions\nExtend Helm's templating with your own functions through plugins. Great for organization-specific templating needs.\n\n#### Post-Renderers as Plugins\nPost-renderers are implemented as plugins, providing better integration and more capabilities.\n\n#### Stable SDK API\nAPI 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.\n\n#### Charts v3\n\nComing soon. v2 charts continue to work unchanged.\n\n### Improvements\n\n#### Performance\nFaster dependency resolution and new content-based chart caching.\n\n#### Error Messages\nClearer, more helpful error output.\n\n#### Registry Authentication\nBetter OAuth and token support for private registries.\n\n#### CLI Flags renamed\n\nSome common CLI flags are renamed to better clarify their operation.\nThe existing flags remain, but emit a deprecated warning:\n\n- `--atomic` → `--rollback-on-failure`\n- `--force` → `--force-replace`\n\nUpdate any automation that uses these renamed CLI flags.\n\n#### CLI Flags deprecated\n\nThe following flags for `helm template` are deprecated and will be removed in Helm 5:\n\n- `--hide-notes`\n- `--render-subchart-notes`\n\nThese flags have no effect because template output never includes notes. They remain in Helm 4 for backwards compatibility but are hidden from help output.\n\n## Upgrading to Helm 4\n\nWhile 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.\n\n### High Priority\n* Test your existing charts and releases to verify that they still work with v4.\n* Test all 3 plugin types (CLI, getter, post-renderer).\n* Try building WebAssembly plugins with the new runtime (see [example plugins](https://github.com/scottrigby/h4-example-plugins))\n* SDK users: test the now-stable API. Try to break it and share your feedback.\n* Test your CI/CD pipelines and fix any script errors from the renamed CLI flags.\n* Test your post-renderer integrations.\n* Test registry authentication and chart installation in your OCI workflows.\n\n### Other\n* Test other new features, including multi-document values, digest-based installs, and custom template functions.\n* Test the performance of Helm 4 with large, complex charts to see if it is noticeably faster for your workloads.\n* Try breaking things intentionally to see if the updated error messages are helpful.\n\n### Feedback\n* What other plugin types would you like to see added to customize Helm core functionality?\n* With the API supporting additional chart versions, what new features would you want in Charts v3?\n\n## How to Give Feedback\n\nFind issues? Have suggestions? We want to hear from you before the November release:\n\n### GitHub Issues\n\nReview 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.\n\n### Community Slack\n\nJoin [Kubernetes Slack](https://slack.kubernetes.io/) channels:\n- `#helm-dev` for development discussions\n- `#helm-users` for user support and testing feedback\n\n### Weekly Dev Meetings\n\nJoin live discussion with maintainers every Thursday 9:30am PT on [Zoom](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09).\n\nFor more options, see the Helm community [communication details](https://github.com/helm/community/blob/main/communication.md).\n"
  },
  {
    "path": "docs/plugins/developer/index.mdx",
    "content": "---\ntitle: Plugins Developer Guide\nsidebar_label: Developing Plugins\nsidebar_position: 3\n---\n\nimport DocCardList from \"@theme/DocCardList\";\n\nFor an overview of Helm Plugin concepts, and how to structure and configure plugins, read the [Plugins Overview](/plugins/overview.md).\n\nThis 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.\n\n:::info\nFor 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!\n:::\n\n## Tutorials\n\n<DocCardList />\n"
  },
  {
    "path": "docs/plugins/developer/tutorial-cli-plugin.mdx",
    "content": "---\ntitle: \"Tutorial: Build a CLI Plugin\"\nsidebar_label: Build a CLI Plugin\n---\n\nimport GetVersion from \"@site/src/components/GetVersion\";\nimport CodeBlock from \"@theme/CodeBlock\";\n\nBuild a `helm system-info` command that displays system information.\n\n## Subprocess Runtime\n\nLet's start by building a CLI Plugin with the Subprocess runtime.\n\n### Prerequisites\n\n1. Install the latest Helm 4 release: **<GetVersion majorVersion=\"4\" label={false} link={true} />**\n2. 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.\n\n### 1. Create Plugin Directory\n\nYou can create this anywhere on your filesystem. For example:\n\n```bash\nmkdir -p $HOME/code/helm/plugins/system-info\ncd $HOME/code/helm/plugins/system-info\n```\n\n### 2. Create plugin manifest\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: cli/v1\nname: \"system-info\"\nversion: \"0.1.0\"\nruntime: subprocess\nconfig:\n  usage: system-info\n  shortHelp: Display system and Helm information\n  longHelp: Shows OS info, Helm version, and environment details\nruntimeConfig:\n  platformCommand:\n    - command: ${HELM_PLUGIN_DIR}/system-info.sh\n```\n\n### 3. Create Script\n\n```bash title=\"system-info.sh\" showLineNumbers\n#!/bin/bash\n\necho \"=== System Information ===\"\necho \"OS: $(uname -s)\"\necho \"Architecture: $(uname -m)\"\n\necho \"\"\necho \"=== Helm Information ===\"\necho \"Plugin Dir: $HELM_PLUGIN_DIR\"\necho \"Arguments: $*\"\n\necho \"\"\necho \"System info complete!\"\n```\n\nMake it executable:\n\n```bash\nchmod +x system-info.sh\n```\n\n### 4. Install in Dev Mode and Test\n\nInstalling a plugin from your filesystem installs in local dev mode. This bypasses checking or verifying provenance:\n\n```bash\n% helm plugin install $HOME/code/helm/plugins/system-info\nInstalling plugin from local directory (development mode)\nInstalled plugin: system-info\n```\n\nLocal 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:\n\n```bash\n% ls -lah $(helm env HELM_PLUGINS)\ntotal 0\ndrwxr-xr-x@ 3 r6by  staff    96B Nov 10 02:18 .\ndrwxr-xr-x@ 3 r6by  staff    96B Jan 21  2025 ..\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info\n```\n\nYou can see your plugin details in the `helm plugin list` of installed plugins:\n\n```bash\n% helm plugin list\nNAME       \tVERSION\tTYPE  \tAPIVERSION\tPROVENANCE\tSOURCE\nsystem-info\t0.1.0  \tcli/v1\tv1        \tlocal dev \tunknown\n```\n\nYou 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`:\n\n```bash\n% helm help | grep system-info\n  system-info Display system and Helm information\n\n% helm help system-info\nShows OS info, Helm version, and environment details\n\nUsage:\n  helm system-info [flags]\n```\n\nLet's try running the CLI subcommand:\n\n```bash\n% helm system-info\n=== System Information ===\nOS: Darwin\nArchitecture: arm64\n\n=== Helm Information ===\nPlugin Dir: /Users/r6by/Library/helm/plugins/system-info\nArguments:\n\nSystem info complete!\n```\n\nWhat you built: A CLI plugin using the Subprocess runtime!\n\nNow let's do it again, this time using Wasm runtime…\n\n## Wasm Runtime\n\n### Prerequisites\n\n- Prerequisites from [Subprocess Runtime](#subprocess-runtime)\n- Go 1.25 installed\n\n:::warning\nTo-do: add this section\n:::\n"
  },
  {
    "path": "docs/plugins/developer/tutorial-getter-plugin.mdx",
    "content": "---\ntitle: \"Tutorial: Build a Getter Plugin\"\nsidebar_label: Build a Getter Plugin\n---\n\nimport GetVersion from \"@site/src/components/GetVersion\";\n\nBuild a `helm system-info` command that displays system information.\n\n## Subprocess Runtime\n\nLet's build a Getter Plugin using the Subprocess runtime.\n\n### Prerequisites\n\n1. Install the latest Helm 4 release: **<GetVersion majorVersion=\"4\" label={false} link={true} />**\n2. 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.\n\n### 1. Create Plugin Directory\n\nYou can create this anywhere on your filesystem. For example:\n\n```bash\nmkdir -p $HOME/code/helm/plugins/demo-getter\ncd $HOME/code/helm/plugins/demo-getter\n```\n\n### 2. Create plugin manifest\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: getter/v1\nname: demo-getter\nversion: 0.1.0\nruntime: subprocess\nconfig:\n  protocols: [\"demo\"]\nruntimeConfig:\n  protocolCommands:\n    - protocols:\n        - demo\n      platformCommand:\n        - command: get-demo.sh\n```\n\n### 3. Create Script\n\nGetter 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:\n\n```bash title=\"get-demo.sh\" showLineNumbers\n#!/usr/bin/env sh\nset -e\n\nURI=$@\nTMPDIR=\"$(mktemp -d)\"\n\n# make a fake chart for testing with the passed URL basename\nFILENAME=$(basename -- $URI)\nhelm create $TMPDIR/$FILENAME 1>/dev/null\nhelm package $TMPDIR/$FILENAME -d $TMPDIR 1>/dev/null\n# cat $FILENAME-0.1.0.tgz\n# just to not need to know the chart version\nrm -r $TMPDIR/$FILENAME 1>/dev/null\ncat $TMPDIR/$FILENAME-*\n```\n\nMake it executable:\n\n```bash\nchmod +x get-demo.sh\n```\n\n### 4. Install in Dev Mode and Test\n\nInstalling a plugin from your filesystem installs in local dev mode, which does not check the provenance:\n\n```bash\n% helm plugin install $HOME/code/helm/plugins/demo-getter\nInstalling plugin from local directory (development mode)\nInstalled plugin: demo-getter\n```\n\nAs 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:\n\n```bash\n% ls -lah $(helm env HELM_PLUGINS)\ntotal 0\ndrwxr-xr-x@ 4 r6by  staff   160B Nov 10 04:04 .\ndrwxr-xr-x@ 3 r6by  staff    96B Jan 21  2025 ..\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info\n```\n\nUnlike 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.\n\nBut like all plugin types, you can see your installed Postrenderer plugin details with `helm plugin list`:\n\n```bash\n% helm plugin list\nNAME          \tVERSION\tTYPE           \tAPIVERSION\tPROVENANCE\tSOURCE\ndemo-getter   \t0.1.0  \tgetter/v1      \tv1        \tlocal dev \tunknown\nsystem-info   \t0.1.0  \tcli/v1         \tv1        \tlocal dev \tunknown\n```\n\nLet's try it out. It should return templated YAML for a chart named \"example\":\n\n```bash\n% helm template example demo://does-not-matter/example\nLOTS OF YAML, INCLUDING:\n---\n# Source: example/templates/tests/test-connection.yaml\n```\n\nWhat you built: A demo Getter plugin using the Subprocess runtime!\n\nNext let's build a version in Wasm runtime…\n\n## Wasm Runtime\n\n### Prerequisites\n\n- Prerequisites from [Subprocess Runtime](#subprocess-runtime)\n- Go 1.25 installed\n\nBuild a custom protocol getter that converts `demo://` URLs to `https://`.\n\n### 1. Set up repository\n\nScaffold a new repository from the template (or just clone):\nhttps://github.com/gjenkins8/helm-extism-plugin-template\n\n### 2. Update plugin manifest\n\nSimilar to the same step for the Subprocess Getter, except you will do this in your own cloned Git repository.\n\nNote the `runtime` and `runtimeConfig` field values will change for Wasm:\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: getter/v1\nname: demo-getter\nversion: 0.1.0\nruntime: extism/v1\nconfig:\n  protocols: [\"demo\"]\nruntimeConfig:\n  memory:\n    maxPages: 16\n  timeout: 30000\n```\n\n### 3. Update `main.go`\n\nSpecify the plugins input/output messages:\n\n```go title=\"main.go\" showLineNumbers\npackage main\n\n...\n\ntype InputMessage struct {\n\tURL      string `json:\"url\"`\n\tProtocol string `json:\"protocol\"`\n}\n\ntype OutputMessage struct {\n\tData []byte `json:\"data\"`\n}\n```\n\nReplace the `replaceMeImplementationGoesHere` function with actual logic:\n\n```go\n...\n\n// Delete the `replaceMeImplementationGoesHere` function\n\nfunc demoDownloader(input InputMessage) (*OutputMessage, error) {\n\n\t// Convert demo:// to https://\n\tdownloadURL := strings.Replace(input.URL, \"demo://\", \"https://\", 1)\n\tpdk.Log(pdk.LogLevelInfo, fmt.Sprintf(\"Converted %s to %s\", input.URL, downloadURL))\n\n\t// Download content\n\tresp, err := http.Get(downloadURL)\n\tif err != nil {\n\t\treturn nil, fmt.Errorf(\"failed to download: %w\", err)\n\t}\n\tdefer resp.Body.Close()\n\n\t// Read and output content\n\tdata, _ := io.ReadAll(resp.Body)\n\toutput := OutputMessage{Data: data}\n\treturn &output, nil\n}\n\n```\n\nUpdate the runPlugin function to call `demoDownloader` instead:\n\n```go\nfunc runPlugin() error {\n\t...\n\t// Remove: output, err := replaceMeImplementationGoesHere(input)\n\toutput, err := demoDownloader(input)\n```\n\n### 4. Build WebAssembly\n\n```bash\n$ make build\n$ ls -la plugin.wasm\n```\n\n### 5. Install in Dev Mode and Test\n\nSame as the Subprocess CLI Plugin step.\n\nWhat you built: A WebAssembly plugin with sandboxed execution and structured communication via Extism PDK!\n\n"
  },
  {
    "path": "docs/plugins/developer/tutorial-postrenderer-plugin.mdx",
    "content": "---\ntitle: \"Tutorial: Build a Postrenderer Plugin\"\nsidebar_label: Build a Postrenderer Plugin\n---\n\nimport GetVersion from \"@site/src/components/GetVersion\";\nimport CodeBlock from \"@theme/CodeBlock\";\n\nBuild a plugin that adds custom labels to all Kubernetes resources.\n\n## Subprocess Runtime\n\nLet's start by building a Postrenderer Plugin with the Subprocess runtime.\n\n### Prerequisites\n\n1. Install the latest Helm 4 release: **<GetVersion majorVersion=\"4\" label={false} link={true} />**\n2. 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.\n3. Install `mikefarah/yq`: https://github.com/mikefarah/yq/#install\n\n### 1. Create Plugin Directory\n\nYou can create this anywhere on your filesystem. For example:\n\n```bash\nmkdir -p $HOME/code/helm/plugins/label-injector\ncd $HOME/code/helm/plugins/label-injector\n```\n\n### 2. Create plugin manifest\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: postrenderer/v1\nname: label-injector\nversion: 0.1.0\nruntime: subprocess\nruntimeConfig:\n  platformCommand:\n    - command: ${HELM_PLUGIN_DIR}/inject-labels.sh\n```\n\n### 3. Create Script\n\n```bash title=\"inject-labels.sh\" showLineNumbers\n#!/usr/bin/env sh\n# set -e\ncat <&0 | yq '.metadata.labels.postrendered-by = \"helm-label-injector-plugin\"'\n```\n\nMake it executable:\n\n```bash\nchmod +x inject-labels.sh\n```\n\n### 4. Install in Dev Mode and Test\n\nInstalling a plugin from your filesystem installs in local dev mode, which does not check the provenance:\n\n```bash\n% helm plugin install $HOME/code/helm/plugins/label-injector\nInstalling plugin from local directory (development mode)\nInstalled plugin: label-injector\n```\n\nAs 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:\n\n```bash\n% ls -lah $(helm env HELM_PLUGINS)\ntotal 0\ndrwxr-xr-x@ 5 r6by  staff   160B Nov 10 04:04 .\ndrwxr-xr-x@ 3 r6by  staff    96B Jan 21  2025 ..\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter\nlrwxr-xr-x  1 r6by  staff    44B Nov 10 03:02 label-injector -> /Users/r6by/code/helm/plugins/label-injector\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info\n```\n\nYou can now see your installed Postrenderer plugin details along with the installed CLI and Getter plugins, using `helm plugin list`:\n\n```bash\n% helm plugin list\nNAME          \tVERSION\tTYPE           \tAPIVERSION\tPROVENANCE\tSOURCE\ndemo-getter   \t0.1.0  \tgetter/v1      \tv1        \tlocal dev \tunknown\nlabel-injector\t0.1.0  \tpostrenderer/v1\tv1        \tlocal dev \tunknown\nsystem-info   \t0.1.0  \tcli/v1         \tv1        \tlocal dev \tunknown\n```\n\nLet's try it out:\n\n```bash\n% helm create ../mychart\n% helm template ../mychart --post-renderer label-injector\n```\n\nYou should see labels like this in the output:\n\n```yaml\nmetadata:\n  labels:\n    postrendered-by: helm-label-injector-plugin\n```\n\nWhat you built: A Postrenderer plugin using the Subprocess runtime!\n\nLet's do this one in Wasm runtime now too…\n\n## Wasm Runtime\n\n### Prerequisites\n\n- Prerequisites from [Subprocess Runtime](#subprocess-runtime)\n- Go 1.25 installed\n\n:::warning\nTo-do: add this section\n:::\n"
  },
  {
    "path": "docs/plugins/index.mdx",
    "content": "---\ntitle: Plugins Guide\nsidebar_label: Plugins\nsidebar_position: 5.5\n---\n\nThis guide explains what Helm plugins are, how to use them, and how to build them.\n\nimport DocCardList from \"@theme/DocCardList\";\n\n<DocCardList />\n"
  },
  {
    "path": "docs/plugins/overview.md",
    "content": "---\ntitle: Plugins Overview\nsidebar_label: Overview\nsidebar_position: 1\n---\n\nHelm 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.\n\nThey can be written in any programming language, and can be added and removed from a Helm installation without breaking Helm core functionality.\n\n## Plugin Types\n\nHelm currently has 3 types of Plugins:\n\n- [CLI plugins](#cli-plugins): allow users to add additional `helm` CLI sub-commands\n- [Getter plugins](#getter-plugins): allow users to use Charts and even other Plugins in locations Helm core doesn't have built-in support for\n- [Postrenderer plugins](#postrenderer-plugins): allow users to modify Chart rendered manifests before being sent to the Kubernetes API\n\nStarting 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.\n\n### CLI plugins\n\nWhat 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?\n\nThe 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.\n\n### Getter Plugins\n\nHelm 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.\n\nHelm 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.\n\n### PostRenderer plugins\n\nHelm 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.\n\nIf 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.\n\n## Plugin API Versions\n\nStarting with Helm 4, the `plugin.yaml` file included with every plugin now has an `apiVersion` field, currently at `v1`.\n\nLegacy 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.\n\nIf you are a plugin developer, read more about this in the [Plugins Developer Guide](/plugins/developer/index.mdx).\n\n## Plugin Runtimes\n\nHelm currently supports 2 plugin runtimes:\n\n- Subprocess runtime\n- Wasm runtime\n\nSee the relevant information about each runtime in either the [Plugins User Guide](/plugins/user/index.md) or [Plugins Developer Guide](/plugins/developer/index.mdx).\n\n## File structure\n\nAll of the files for a plugin live within a single directory, which is used for developing, packaging, and installing.\n\nInside the plugin's directory, Helm expects this structure:\n\n```\nexample-plugin\n├── plugin.yaml # REQUIRED\n├── plugin.sh   # OPTIONAL for Subprocess runtime\n└── plugin.wasm # REQUIRED for Wasm runtime\n```\n\n- The only required file is [plugin.yaml](#pluginyaml).\n- [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.\n- 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.\n\n## Plugin.yaml\n\nThe `plugin.yaml` file is required for a plugin. It is a YAML file containing metadata and configuration for the plugin.\n\n### Metadata Information\n\n```yaml\napiVersion: REQUIRED - The Plugin API version. Must be \"v1\"\ntype: REQUIRED - The versioned Plugin Type. Can be \"cli/v1\", \"getter/v1\", or \"postrenderer/v1\"\nname: REQUIRED - The name of the plugin\nversion: REQUIRED - The version of the plugin\nruntime: REQUIRED - The runtime for the plugin. Can be \"subprocess\" or \"extism/v1\" (Wasm)\nsourceURL: OPTIONAL - A URL pointing to the source code for your plugin\nconfig: DEPENDS ON PLUGIN TYPE\nruntimeConfig: DEPENDS ON RUNTIME\n```\n\n- 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.\n- The `runtimeConfig` field is for [Runtime Configuration](#runtime-configuration), with a structure that differs per [Runtime](#plugin-runtimes) as defined by the `runtime` field.\n- 💡 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.\n\n### Plugin Type Configuration\n\nThe `config` field of [plugin.yaml](#pluginyaml) has different options per [Plugin Type](#plugin-types). A plugin's type is defined by the `type` field.\n\n#### CLI Plugin Configuration\n\nIf `type` field is `cli/v1`, it is a [CLI Plugin type](#cli-plugins), and the following plugin type configurations are allowed:\n\n```yaml\nusage: OPTIONAL - The single-line usage text shown in help\nshortHelp: The short description shown in the 'helm help' output\nlongHelp: The long message shown in the 'helm help <this-command>' output\nignoreFlags: Ignores any flags passed in from Helm\n```\n\n- `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\n- `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.\n\n#### Getter Plugin Configuration\n\nIf `type` field is `getter/v1`, it is a [Getter Plugin type](#getter-plugins), and the following plugin type configurations are allowed:\n\n```yaml\nprotocols: The list of schemes from the charts URL that this plugin supports.\n```\n\n#### Postrenderer Plugin Configuration\n\nIf `type` field is `postrenderer/v1`, it is a [Postrenderer Plugin type](#cli-plugins), and does not have any configuration options.\n\n### Runtime Configuration\n\nThe `runtimeConfig` field of [plugin.yaml](#pluginyaml) has different options per [Plugin Runtime](#plugin-runtimes). A plugin's runtime is defined by the `runtime` field.\n\n#### Subprocess Runtime Configuration\n\nIf the `runtime` field is `subprocess`, it is a [Subprocess Runtime](#plugin-runtimes) plugin and the following runtime configurations are allowed:\n\n```yaml\nruntimeconfig:\n    platformCommand: # Configure command to run based on the platform\n        - os: OS match, can be empty or omitted to match any OS\n          arch: Architecture match, can be empty or omitted to match any architecture\n          command: Plugin command to execute\n          args: Plugin command arguments\n    platformHooks: # Configure plugin lifecycle hooks based on the platform\n        install: # Install lifecycle commands\n            - os: OS match, can be empty or omitted to match any OS\n              arch: Architecture match, can be empty or omitted to match any architecture\n              command: Plugin install command to execute\n              args: Plugin install command arguments\n        update: # Update lifecycle commands\n            - os: OS match, can be empty or omitted to match any OS\n              arch: Architecture match, can be empty or omitted to match any architecture\n              command: Plugin update command to execute\n              args: Plugin update command arguments\n        delete: # Delete lifecycle commands\n            - os: OS match, can be empty or omitted to match any OS\n              arch: Architecture match, can be empty or omitted to match any architecture\n              command: Plugin delete command to execute\n              args: Plugin delete command arguments\n    protocolCommands: # Obsolete/deprecated\n        - protocols: [] # Protocols are the list of schemes from the charts URL.\n          platformCommand: [] # Same structure as \"platformCommand\" above\n```\n\n- ⚠️ `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.\n\n#### Wasm Runtime Configuration\n\nIf the `runtime` field is `extism/v1`, it is a [Wasm Runtime](#plugin-runtimes) plugin and the following runtime configurations are allowed:\n\n```yaml\nruntimeconfig:\n    memory: # Describes the limits on the memory the plugin may be allocated\n        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).\n        maxHttpResponseBytes: The max size of an Extism HTTP response in bytes. Default is 4096 bytes (4KiB).\n        maxVarBytes: The max size of all Extism vars in bytes. Default is 4096 bytes (4KiB).\n    config: {} # A free-form map that can be passed to the plugin.\n    allowedHosts: [] # An optional set of hosts this plugin can communicate with. Defaults to no hosts allowed.\n    fileSystem:\n        createTempDir: Whether to create a temporary directory on the filesystem. Can be \"true\" or \"false\".\n    timeout: The timeout in milliseconds for the plugin to execute\n    hostFunctions: HostFunction names exposed in Helm the plugin may access. See https://extism.org/docs/concepts/host-functions/\n    entryFuncName: The name of entry function name to call in the plugin. Defaults to \"helm_plugin_main\".\n```\n\n- `allowedHosts` only has an effect if the plugin makes HTTP requests. If not specified, then no hosts are allowed.\n"
  },
  {
    "path": "docs/plugins/user/index.md",
    "content": "---\ntitle: Plugins User Guide\nsidebar_label: Using Plugins\nsidebar_position: 2\n---\n\nFor 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).\n\nThis section focuses on using Helm Plugins as an end-user.\n\n## Finding Plugins\n\nYou can already find [Helm Plugins on ArtifactHub](https://artifacthub.io/packages/search?kind=6).\n\nThe 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!\n\n## Plugin Security\n\nDepending on the plugin runtime, you should inspect any plugin from third parties before running on your system.\n\n- 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.\n- 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.\n\nIn 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.\n\nSee the `--verify` flag in `helm plugin install --help`.\n\nYou 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.\n\nThe `helm plugin list` command also includes high-level provenance information at a glance.\n\n## Installing Plugins\n\nHelm 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.\n\nSee `helm plugin install --help` for more information.\n\n## Listing Installed Plugins\n\nThe command to list plugins includes the plugin's name, version, type, API version, provenance, and source.\n\nSee `helm plugin list --help` for more information.\n\n## Uninstalling Plugins\n\nUninstalling 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.\n\nSee `helm plugin uninstall --help`.\n"
  },
  {
    "path": "docs/sdk/examples.mdx",
    "content": "---\ntitle: Examples\ndescription: Examples of various features of the Helm SDK\nsidebar_position: 2\n---\nimport CodeBlock from '@theme/CodeBlock';\n\nimport MainExampleGo from '!!raw-loader!/sdkexamples/main.go';\nimport InstallExampleGo from '!!raw-loader!/sdkexamples/install.go';\nimport ListExampleGo from '!!raw-loader!/sdkexamples/list.go';\nimport PullExampleGo from '!!raw-loader!/sdkexamples/pull.go';\nimport UninstallExampleGo from '!!raw-loader!/sdkexamples/uninstall.go';\nimport UpgradeExampleGo from '!!raw-loader!/sdkexamples/upgrade.go';\n\nThis document runs though a series of examples of using the Helm SDK.\nIntended to document various SDK functionalities.\n\nThe final example shows `main.go` driver ([link](#driver)). That runs the below actions and includes necessary helper functions.\n\nThe code for the examples lives in the [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples) directory.\nAnd is intended to be fully functional.\n\n## Actions\n\n### Install Action\n\nThis example installs the given chart/release, for the given version and values:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/install.go\" showLineNumbers>{InstallExampleGo}</CodeBlock>\n\n### Upgrade Action\n\nThis example upgrades the given release, with the given chart, version and values:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/upgrade.go\" showLineNumbers>{UpgradeExampleGo}</CodeBlock>\n\n### Uninstall Action\n\nThis example uninstalls the given release:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/uninstall.go\" showLineNumbers>{UninstallExampleGo}</CodeBlock>\n\n### List Action\n\nThis example lists all released charts (in the currently configured namespace):\n\n<CodeBlock language=\"go\" title=\"sdkexamples/list.go\" showLineNumbers>{ListExampleGo}</CodeBlock>\n\n### Pull Action\n\nThis example pulls a chart from an OCI repository:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/pull.go\" showLineNumbers>{PullExampleGo}</CodeBlock>\n\n## Driver\n\nThe 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:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/main.go\" showLineNumbers>{MainExampleGo}</CodeBlock>\n"
  },
  {
    "path": "docs/sdk/gosdk.mdx",
    "content": "---\ntitle: Introduction\ndescription: Introduces the Helm Go SDK\nsidebar_position: 1\n---\n\nHelm's Go SDK enables custom software to leverage Helm charts and Helm's functionality for managing Kubernetes software deployment\n(In fact, the Helm CLI is effectively just one such tool!).\n\nCurrently, the SDK has been functionally separated from the Helm CLI.\nAnd the SDK can (and is) used by standalone tooling.\nThe Helm project has committed to API stability for the SDK.\nAs 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.\n\nFull API documentation can be found at [https://pkg.go.dev/helm.sh/helm/v4](https://pkg.go.dev/helm.sh/helm/v4).\n\nA brief overview of some of the main types of packages and a simple example follows below.\nSee the [Examples](/sdk/examples.mdx) section for more examples and a more full featured 'driver'.\n\n## Main package overview\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v4/pkg/action):\n  Contains the main “client” for performing Helm actions.\n  This is the same package that the CLI is using underneath the hood.\n  If you just need to perform basic Helm commands from another Go program, this package is for you.\n- [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):\n  Methods and helpers used for loading and manipulating charts.\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v4/pkg/cli) and its subpackages:\n  Contains all the handlers for the standard Helm environment variables and its subpackages contain output and values file handling.\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v4/pkg/release):\n  Defines the `Release` object and statuses.\n\nThere are many more packages besides these, so go check out the documentation for more information!\n\n### Simple example\nThis is a simple example of doing a `helm list` using the Go SDK.\nSee the [Examples](/sdk/examples.mdx) section for more full featured examples.\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v4/pkg/action\"\n    \"helm.sh/helm/v4/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## Compatibility\n\nThe Helm SDK explicitly follows the Helm backwards compatibility guarantees:\n\nhttps://github.com/helm/community/blob/main/hips/hip-0004.md\n\nThat is, breaking changes will only be made with a major version release or to remediate a security issue.\n"
  },
  {
    "path": "docs/sdk/index.mdx",
    "content": "---\ntitle: Go SDK\nsidebar_position: 7\n---\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "docs/topics/advanced.mdx",
    "content": "---\ntitle: Advanced Helm Techniques\ndescription: Explains various advanced features for Helm power users\nsidebar_position: 9\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nThis section explains various advanced features and techniques for using Helm.\nThe information in this section is intended for \"power users\" of Helm that wish\nto do advanced customization and manipulation of their charts and releases. Each\nof these advanced features comes with their own tradeoffs and caveats, so each\none must be used carefully and with deep knowledge of Helm. Or in other words,\nremember the [Peter Parker\nprinciple](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)\n\n## Post Rendering\nPost rendering gives chart installers the ability to manually manipulate,\nconfigure, and/or validate rendered manifests before they are installed by Helm.\nThis allows users with advanced configuration needs to be able to use tools like\n[`kustomize`](https://kustomize.io) to apply configuration changes without the\nneed to fork a public chart or requiring chart maintainers to specify every last\nconfiguration option for a piece of software. There are also use cases for\ninjecting common tools and side cars in enterprise environments or analysis of\nthe manifests before deployment.\n\n### Prerequisites\n- Helm 3.1+\n\n### Usage\nA post-renderer can be any executable that accepts rendered Kubernetes manifests\non STDIN and returns valid Kubernetes manifests on STDOUT. It should return an\nnon-0 exit code in the event of a failure. This is the only \"API\" between the\ntwo components. It allows for great flexibility in what you can do with your\npost-render process.\n\nA post-renderer can be used with `install`, `upgrade`, and `template`. To use a\npost-renderer, use the `--post-renderer` flag with a path to the renderer\nexecutable you wish to use:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nIf the path does not contain any separators, it will search in $PATH, otherwise\nit will resolve any relative paths to a fully qualified path\n\nIf you wish to use multiple post-renderers, call all of them in a script or\ntogether in whatever binary tool you have built. In bash, this would be as\nsimple as `renderer1 | renderer2 | renderer3`.\n\nYou can see an example of using `kustomize` as a post-renderer\n[here](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n#### Filenames\nEach manifest passed to the post-renderer includes a temporary annotation:\n```yaml\nmetadata:\n  annotations:\n    postrenderer.helm.sh/postrender-filename: <original-template-filename>\n```\n\nHelm 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-<id>.yaml`. Finally, Helm removes the annotation before sending the manifests to Kubernetes.\n\n#### Hooks and Post-Render Strategy\n\nIn 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.\n\nYou can control this behavior via the Go SDK using the `PostRenderStrategy` option:\n\n| Strategy | Behavior |\n|----------|----------|\n| `combined` | Sends hooks and templates together as one stream. This is the default in Helm 4. |\n| `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. |\n| `nohooks` | Sends only templates to the post-renderer; hooks are left untouched. Matches Helm 3 behavior. |\n\n**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.\n\n### Caveats\nWhen using post renderers, there are several important things to keep in mind.\nThe most important of these is that when using a post-renderer, all people\nmodifying that release **MUST** use the same renderer in order to have\nrepeatable builds. This feature is purposefully built to allow any user to\nswitch out which renderer they are using or to stop using a renderer, but this\nshould be done deliberately to avoid accidental modification or data loss.\n\nOne other important note is around security. If you are using a post-renderer,\nyou should ensure it is coming from a reliable source (as is the case for any\nother arbitrary executable). Using non-trusted or non-verified renderers is NOT\nrecommended as they have full access to rendered templates, which often contain\nsecret data.\n\n### Custom Post Renderers\nThe post render step offers even more flexibility when used in the Go SDK. Any\npost renderer only needs to implement the following Go interface:\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nFor more information on using the Go SDK, See the [Go SDK section](#go-sdk)\n\n## Go SDK\nHelm 3 debuted a completely restructured Go SDK for a better experience when\nbuilding software and tools that leverage Helm. Full documentation can be found\nin the [Go SDK Section](/sdk/gosdk.mdx).\n\n## Storage backends\n\nBy default, release information is stored in Secrets in the\nnamespace of the release. The subsections which follow\nshow how to configure different backends. This configuration is based on the\n`HELM_DRIVER` environment variable. It can be set to one of the values:\n`[configmap, secret, sql]`.\n\n### ConfigMap storage backend\n\nTo enable the ConfigMap backend, you'll need to set the environmental variable\n`HELM_DRIVER` to `configmap`.\n\nYou can set it in a shell as follows:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nIf you want to switch from the default backend to the ConfigMap backend, you'll\nhave to do the migration for this on your own. You can retrieve release\ninformation with the following command:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**PRODUCTION NOTES**: The release information includes the contents of charts and\nvalues files, and therefore might contain sensitive data (like\npasswords, private keys, and other credentials) that needs to be protected from\nunauthorized access. When managing Kubernetes authorization, for instance with\n[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), it is\npossible to grant broader access to ConfigMap resources, while restricting\naccess to Secret resources. For instance, the default [user-facing\nrole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\n\"view\" grants access to most resources, but not to Secrets. Furthermore, secrets\ndata can be configured for [encrypted\nstorage](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).\nPlease keep that in mind if you decide to switch to the ConfigMap backend, as it\ncould expose your application's sensitive data.\n\n### SQL storage backend\n\nThere is a ***beta*** SQL storage backend that stores release information in an SQL\ndatabase.\n\nUsing such a storage backend is particularly useful if your release information\nweighs more than 1MB (in which case, it can't be stored in ConfigMaps/Secrets\nbecause of internal limits in Kubernetes' underlying etcd key-value store).\n\nTo enable the SQL backend, you'll need to deploy a SQL database and set the\nenvironmental variable `HELM_DRIVER` to `sql`. The DB details are set with the\nenvironmental variable `HELM_DRIVER_SQL_CONNECTION_STRING`.\n\nYou can set it in a shell as follows:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Note: Only PostgreSQL is supported at this moment.\n\n**PRODUCTION NOTES**: It is recommended to:\n- Make your database production ready. For PostgreSQL, refer to the [Server Administration](https://www.postgresql.org/docs/12/admin.html) docs for more details\n- Enable [permission management](/topics/permissions_sql_storage_backend.md) to\nmirror Kubernetes RBAC for release information\n\nIf you want to switch from the default backend to the SQL backend, you'll have\nto do the migration for this on your own. You can retrieve release information\nwith the following command:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "docs/topics/architecture.md",
    "content": "---\ntitle: Helm Architecture\ndescription: Describes the Helm architecture at a high level.\nsidebar_position: 8\n---\n\n# Helm Architecture\n\nThis document describes the Helm architecture at a high level.\n\n## The Purpose of Helm\n\nHelm is a tool for managing Kubernetes packages called _charts_. Helm can do the\nfollowing:\n\n- Create new charts from scratch\n- Package charts into chart archive (tgz) files\n- Interact with chart repositories where charts are stored\n- Install and uninstall charts into an existing Kubernetes cluster\n- Manage the release cycle of charts that have been installed with Helm\n\nFor Helm, there are three important concepts:\n\n1. The _chart_ is a bundle of information necessary to create an instance of a\n   Kubernetes application.\n2. The _config_ contains configuration information that can be merged into a\n   packaged chart to create a releasable object.\n3. A _release_ is a running instance of a _chart_, combined with a specific\n   _config_.\n\n## Components\n\nHelm is an executable which is implemented into two distinct parts:\n\n**The Helm Client** is a command-line client for end users. The client is\nresponsible for the following:\n\n- Local chart development\n- Managing repositories\n- Managing releases\n- Interfacing with the Helm library\n  - Sending charts to be installed\n  - Requesting upgrading or uninstalling of existing releases\n\n**The Helm Library** provides the logic for executing all Helm operations. It\ninterfaces with the Kubernetes API server and provides the following capability:\n\n- Combining a chart and configuration to build a release\n- Installing charts into Kubernetes, and providing the subsequent release object\n- Upgrading and uninstalling charts by interacting with Kubernetes\n\nThe standalone Helm library encapsulates the Helm logic so that it can be\nleveraged by different clients.\n\n## Implementation\n\nThe Helm client and library is written in the Go programming language.\n\nThe library uses the Kubernetes client library to communicate with Kubernetes.\nCurrently, that library uses REST+JSON. It stores information in Secrets located\ninside of Kubernetes. It does not need its own database.\n\nConfiguration files are, when possible, written in YAML.\n"
  },
  {
    "path": "docs/topics/chart_repository.md",
    "content": "---\ntitle: The Chart Repository Guide\ndescription: How to create and work with Helm chart repositories.\nsidebar_position: 6\n---\n\nThis section explains how to create and work with Helm chart repositories. At a\nhigh level, a chart repository is a location where packaged charts can be stored\nand shared.\n\nThe distributed community Helm chart repository is located at\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) and welcomes\nparticipation. But Helm also makes it possible to create and run your own chart\nrepository. This guide explains how to do so. If you are considering creating a\nchart repository, you may want to consider using an\n[OCI registry](/topics/registries.mdx) instead.\n\n## Prerequisites\n\n* Go through the [Quickstart](/intro/quickstart.md) Guide\n* Read through the [Charts](/topics/charts.mdx) document\n\n## Create a chart repository\n\nA _chart repository_ is an HTTP server that houses an `index.yaml` file and\noptionally some packaged charts.  When you're ready to share your charts, the\npreferred way to do so is by uploading them to a chart repository.\n\nAs of Helm 2.2.0, client-side SSL auth to a repository is supported. Other\nauthentication protocols may be available as plugins.\n\nBecause a chart repository can be any HTTP server that can serve YAML and tar\nfiles and can answer GET requests, you have a plethora of options when it comes\ndown to hosting your own chart repository. For example, you can use a Google\nCloud Storage (GCS) bucket, Amazon S3 bucket, GitHub Pages, or even create your\nown web server.\n\n### The chart repository structure\n\nA chart repository consists of packaged charts and a special file called\n`index.yaml` which contains an index of all of the charts in the repository.\nFrequently, the charts that `index.yaml` describes are also hosted on the same\nserver, as are the [provenance files](/topics/provenance.mdx).\n\nFor example, the layout of the repository `https://example.com/charts` might\nlook like this:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nIn this case, the index file would contain information about one chart, the\nAlpine chart, and provide the download URL\n`https://example.com/charts/alpine-0.1.2.tgz` for that chart.\n\nIt is not required that a chart package be located on the same server as the\n`index.yaml` file. However, doing so is often the easiest.\n\n### The index file\n\nThe index file is a yaml file called `index.yaml`. It contains some metadata\nabout the package, including the contents of a chart's `Chart.yaml` file. A\nvalid chart repository must have an index file. The index file contains\ninformation about each chart in the chart repository. The `helm repo index`\ncommand will generate an index file based on a given local directory that\ncontains packaged charts.\n\nThis is an example of an index file:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Hosting Chart Repositories\n\nThis part shows several ways to serve a chart repository.\n\n### Google Cloud Storage\n\nThe first step is to **create your GCS bucket**. We'll call ours\n`fantastic-charts`.\n\n![Create a GCS Bucket](/img/helm2/create-a-bucket.png)\n\nNext, make your bucket public by **editing the bucket permissions**.\n\n![Edit Permissions](/img/helm2/edit-permissions.png)\n\nInsert this line item to **make your bucket public**:\n\n![Make Bucket Public](/img/helm2/make-bucket-public.png)\n\nCongratulations, now you have an empty GCS bucket ready to serve charts!\n\nYou may upload your chart repository using the Google Cloud Storage command\nline tool, or using the GCS web UI. A public GCS bucket can be accessed via\nsimple HTTPS at this address: `https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith\n\nYou can also set up chart repositories using Cloudsmith. Read more about\nchart repositories with Cloudsmith\n[here](https://help.cloudsmith.io/docs/helm-chart-repository)\n\n### JFrog Artifactory\n\nSimilarly, you can also set up chart repositories using JFrog Artifactory. Read more about\nchart repositories with JFrog Artifactory\n[here](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)\n\n### GitHub Pages example\n\nIn a similar way you can create charts repository using GitHub Pages.\n\nGitHub allows you to serve static web pages in two different ways:\n\n- By configuring a project to serve the contents of its `docs/` directory\n- By configuring a project to serve a particular branch\n\nWe'll take the second approach, though the first is just as easy.\n\nThe first step will be to **create your gh-pages branch**.  You can do that\nlocally as.\n\n```console\n$ git checkout -b gh-pages\n```\n\nOr via web browser using **Branch** button on your GitHub repository:\n\n![Create GitHub Pages branch](/img/helm2/create-a-gh-page-button.png)\n\nNext, you'll want to make sure your **gh-pages branch** is set as GitHub Pages,\nclick on your repo **Settings** and scroll down to **GitHub pages** section and\nset as per below:\n\n![Create GitHub Pages branch](/img/helm2/set-a-gh-page.png)\n\nBy default **Source** usually gets set to **gh-pages branch**. If this is not\nset by default, then select it.\n\nYou can use a **custom domain** there if you wish so.\n\nAnd check that **Enforce HTTPS** is ticked, so the **HTTPS** will be used when\ncharts are served.\n\nIn such setup you can use your default branch to store your charts code, and\n**gh-pages branch** as charts repository, e.g.:\n`https://USERNAME.github.io/REPONAME`. The demonstration [TS\nCharts](https://github.com/technosophos/tscharts) repository is accessible at\n`https://technosophos.github.io/tscharts/`.\n\nIf you have decided to use GitHub pages to host the chart repository, check out\n[Chart Releaser Action](/howto/chart_releaser_action.md).\nChart Releaser Action is a GitHub Action workflow to turn a GitHub project into\na self-hosted Helm chart repo, using\n[helm/chart-releaser](https://github.com/helm/chart-releaser) CLI tool.\n\n### Ordinary web servers\n\nTo configure an ordinary web server to serve Helm charts, you merely need to do\nthe following:\n\n- Put your index and charts in a directory that the server can serve\n- Make sure the `index.yaml` file can be accessed with no authentication\n  requirement\n- Make sure `yaml` files are served with the correct content type (`text/yaml`\n  or `text/x-yaml`)\n\nFor example, if you want to serve your charts out of `$WEBROOT/charts`, make\nsure there is a `charts/` directory in your web root, and put the index file and\ncharts inside of that folder.\n\n### ChartMuseum Repository Server\n\nChartMuseum is an open-source Helm Chart Repository server written in Go\n(Golang), with support for cloud storage backends, including [Google Cloud\nStorage](https://cloud.google.com/storage/), [Amazon\nS3](https://aws.amazon.com/s3/), [Microsoft Azure Blob\nStorage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba\nCloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object\nStorage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud\nInfrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud\nBOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object\nStorage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean\nSpaces](https://www.digitalocean.com/products/spaces/),\n[Minio](https://min.io/), and [etcd](https://etcd.io/).\n\nYou can also use the\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\nserver to host a chart repository from a local file system.\n\n### GitLab Package Registry\n\nWith GitLab you can publish Helm charts in your project’s Package Registry.\nRead more about setting up a helm package repository with GitLab [here](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Managing Chart Repositories\n\nNow that you have a chart repository, the last part of this guide explains how\nto maintain charts in that repository.\n\n\n### Store charts in your chart repository\n\nNow that you have a chart repository, let's upload a chart and an index file to\nthe repository.  Charts in a chart repository must be packaged (`helm package\nchart-name/`) and versioned correctly (following [SemVer 2](https://semver.org/)\nguidelines).\n\nThese next steps compose an example workflow, but you are welcome to use\nwhatever workflow you fancy for storing and updating charts in your chart\nrepository.\n\nOnce you have a packaged chart ready, create a new directory, and move your\npackaged chart to that directory.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nThe last command takes the path of the local directory that you just created and\nthe URL of your remote chart repository and composes an `index.yaml` file inside\nthe given directory path.\n\nNow you can upload the chart and the index file to your chart repository using a\nsync tool or manually. If you're using Google Cloud Storage, check out this\n[example workflow](/howto/chart_repository_sync_example.md)\nusing the gsutil client. For GitHub, you can simply put the charts in the\nappropriate destination branch.\n\n### Add new charts to an existing repository\n\nEach time you want to add a new chart to your repository, you must regenerate\nthe index. The `helm repo index` command will completely rebuild the\n`index.yaml` file from scratch, including only the charts that it finds locally.\n\nHowever, you can use the `--merge` flag to incrementally add new charts to an\nexisting `index.yaml` file (a great option when working with a remote repository\nlike GCS). Run `helm repo index --help` to learn more,\n\nMake sure that you upload both the revised `index.yaml` file and the chart. And\nif you generated a provenance file, upload that too.\n\n### Share your charts with others\n\nWhen you're ready to share your charts, simply let someone know what the URL of\nyour repository is.\n\nFrom there, they will add the repository to their helm client via the `helm repo\nadd [NAME] [URL]` command with any name they would like to use to reference the\nrepository.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nIf the charts are backed by HTTP basic authentication, you can also supply the\nusername and password here:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Note:** A repository will not be added if it does not contain a valid\n`index.yaml`.\n\n**Note:** If your helm repository is e.g. using a self signed\ncertificate, you can use `helm repo add --insecure-skip-tls-verify ...` in order\nto skip the CA verification.\n\nAfter that, your users will be able to search through your charts. After you've\nupdated the repository, they can use the `helm repo update` command to get the\nlatest chart information.\n\n*Under the hood, the `helm repo add` and `helm repo update` commands are\nfetching the index.yaml file and storing them in the\n`$XDG_CACHE_HOME/helm/repository/cache/` directory. This is where the `helm\nsearch` function finds information about charts.*\n"
  },
  {
    "path": "docs/topics/chart_tests.md",
    "content": "---\ntitle: Chart Tests\ndescription: Describes how to run and test your charts.\nsidebar_position: 3\n---\n\nA chart contains a number of Kubernetes resources and components that work\ntogether. As a chart author, you may want to write some tests that validate that\nyour chart works as expected when it is installed. These tests also help the\nchart consumer understand what your chart is supposed to do.\n\nA **test** in a helm chart lives under the `templates/` directory and is a job\ndefinition that specifies a container with a given command to run. The container\nshould exit successfully (exit 0) for a test to be considered a success. The job\ndefinition must contain the helm test hook annotation: `helm.sh/hook: test`.\n\nNote that until Helm v3, the job definition needed to contain one of these helm\ntest hook annotations: `helm.sh/hook: test-success` or `helm.sh/hook: test-failure`.\n`helm.sh/hook: test-success` is still accepted as a backwards-compatible\nalternative to `helm.sh/hook: test`.\n\nExample tests:\n\n- Validate that your configuration from the values.yaml file was properly\n  injected.\n  - Make sure your username and password work correctly\n  - Make sure an incorrect username and password does not work\n- Assert that your services are up and correctly load balancing\n- etc.\n\nYou can run the pre-defined tests in Helm on a release using the command `helm\ntest <RELEASE_NAME>`. For a chart consumer, this is a great way to check that\ntheir release of a chart (or application) works as expected.\n\n## Example Test\n\nThe [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. \n\n```console\n$ helm create demo\n```\n\nYou will now be able to see the following structure in your demo helm chart.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nIn `demo/templates/tests/test-connection.yaml` you'll see a test you can try. You can see the helm test pod definition here:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Steps to Run a Test Suite on a Release\n\nFirst, install the chart on your cluster to create a release. You may have to\nwait for all pods to become active; if you test immediately after this install,\nit is likely to show a transitive failure, and you will want to re-test.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Notes\n\n- You can define as many tests as you would like in a single yaml file or spread\n  across several yaml files in the `templates/` directory.\n- You are welcome to nest your test suite under a `tests/` directory like\n  `<chart-name>/templates/tests/` for more isolation.\n- A test is a [Helm hook](/topics/charts_hooks.md), so annotations like\n  `helm.sh/hook-weight` and `helm.sh/hook-delete-policy` may be used with test\n  resources.\n"
  },
  {
    "path": "docs/topics/charts.mdx",
    "content": "---\ntitle: Charts\ndescription: Explains the chart format, and provides basic guidance for building charts with Helm.\nsidebar_position: 1\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm uses a packaging format called _charts_. A chart is a collection of files\nthat describe a related set of Kubernetes resources. A single chart might be\nused to deploy something simple, like a memcached pod, or something complex,\nlike a full web app stack with HTTP servers, databases, caches, and so on.\n\nCharts are created as files laid out in a particular directory tree. They can be\npackaged into versioned archives to be deployed.\n\nIf you want to download and look at the files for a published chart, without\ninstalling it, you can do so with `helm pull chartrepo/chartname`.\n\nThis document explains the chart format, and provides basic guidance for\nbuilding charts with Helm.\n\n## The Chart File Structure\n\nA chart is organized as a collection of files inside of a directory. The\ndirectory name is the name of the chart (without versioning information). Thus,\na chart describing WordPress would be stored in a `wordpress/` directory.\n\nInside of this directory, Helm will expect a structure that matches this:\n\n```text\nwordpress/\n  Chart.yaml          # A YAML file containing information about the chart\n  LICENSE             # OPTIONAL: A plain text file containing the license for the chart\n  README.md           # OPTIONAL: A human-readable README file\n  values.yaml         # The default configuration values for this chart\n  values.schema.json  # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file\n  charts/             # A directory containing any charts upon which this chart depends.\n  crds/               # Custom Resource Definitions\n  templates/          # A directory of templates that, when combined with values,\n                      # will generate valid Kubernetes manifest files.\n  templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes\n```\n\nHelm reserves use of the `charts/`, `crds/`, and `templates/` directories, and\nof the listed file names. Other files will be left as they are.\n\n## The Chart.yaml File\n\nThe `Chart.yaml` file is required for a chart. It contains the following fields:\n\n```yaml\napiVersion: The chart API version (required)\nname: The name of the chart (required)\nversion: The version of the chart (required)\nkubeVersion: A SemVer range of compatible Kubernetes versions (optional)\ndescription: A single-sentence description of this project (optional)\ntype: The type of the chart (optional)\nkeywords:\n  - A list of keywords about this project (optional)\nhome: The URL of this projects home page (optional)\nsources:\n  - A list of URLs to source code for this project (optional)\ndependencies: # A list of the chart requirements (optional)\n  - name: The name of the chart (nginx)\n    version: The version of the chart (\"1.2.3\")\n    repository: (optional) The repository URL (\"https://example.com/charts\") or alias (\"@repo-name\")\n    condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )\n    tags: # (optional)\n      - Tags can be used to group charts for enabling/disabling together\n    import-values: # (optional)\n      - 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.\n    alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times\nmaintainers: # (optional)\n  - name: The maintainers name (required for each maintainer)\n    email: The maintainers email (optional for each maintainer)\n    url: A URL for the maintainer (optional for each maintainer)\nicon: A URL to an SVG or PNG image to be used as an icon (optional).\nappVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.\ndeprecated: Whether this chart is deprecated (optional, boolean)\nannotations:\n  example: A list of annotations keyed by name (optional).\n```\n\nAs of [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), additional\nfields are not allowed.\nThe recommended approach is to add custom metadata in `annotations`.\n\n### Charts and Versioning\n\nEvery chart must have a version number. A version should follow the [SemVer\n2](https://semver.org/spec/v2.0.0.html) standard but it is not strictly enforced. Unlike Helm Classic, Helm v2\nand later uses version numbers as release markers. Packages in repositories are\nidentified by name plus version.\n\nFor example, an `nginx` chart whose version field is set to `version: 1.2.3`\nwill be named:\n\n```text\nnginx-1.2.3.tgz\n```\n\nMore complex SemVer 2 names are also supported, such as `version:\n1.2.3-alpha.1+ef365`. But non-SemVer names are explicitly disallowed by the\nsystem. Subject to exception are versions in format `x` or `x.y`.\nFor 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).\n\n**NOTE:** Whereas Helm Classic and Deployment Manager were both very GitHub\noriented when it came to charts, Helm v2 and later does not rely upon or require\nGitHub or even Git. Consequently, it does not use Git SHAs for versioning at\nall.\n\nThe `version` field inside of the `Chart.yaml` is used by many of the Helm\ntools, including the CLI. When generating a package, the `helm package` command\nwill use the version that it finds in the `Chart.yaml` as a token in the package\nname. The system assumes that the version number in the chart package name\nmatches the version number in the `Chart.yaml`. Failure to meet this assumption\nwill cause an error.\n\n### The `apiVersion` Field\n\nThe `apiVersion` field should be `v2` for Helm charts that require at least Helm\n3. Charts supporting previous Helm versions have an `apiVersion` set to `v1` and\nare still installable by Helm 3.\n\nChanges from `v1` to `v2`:\n\n- A `dependencies` field defining chart dependencies, which were located in a\n  separate `requirements.yaml` file for `v1` charts (see [Chart\n  Dependencies](#chart-dependencies)).\n- The `type` field, discriminating application and library charts (see [Chart\n  Types](#chart-types)).\n\n### The `appVersion` Field\n\nNote that the `appVersion` field is not related to the `version` field. It is a\nway of specifying the version of the application. For example, the `drupal`\nchart may have an `appVersion: \"8.2.1\"`, indicating that the version of Drupal\nincluded in the chart (by default) is `8.2.1`. This field is informational, and\nhas 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.\n\nAs of Helm v3.5.0, `helm create` wraps the default `appVersion` field in quotes.\n\n### The `kubeVersion` Field\n\nThe optional `kubeVersion` field can define semver constraints on supported\nKubernetes versions. Helm will validate the version constraints when installing\nthe chart and fail if the cluster runs an unsupported Kubernetes version.\n\nVersion constraints may comprise space separated AND comparisons such as\n```\n>= 1.13.0 < 1.15.0\n```\nwhich themselves can be combined with the OR `||` operator like in the following\nexample\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\nIn this example the version `1.14.0` is excluded, which can make sense if a bug\nin certain versions is known to prevent the chart from running properly.\n\nApart from version constrains employing operators `=` `!=` `>` `<` `>=` `<=` the\nfollowing shorthand notations are supported\n\n * hyphen ranges for closed intervals, where `1.1 - 2.3.4` is equivalent to `>=\n   1.1 <= 2.3.4`.\n * wildcards `x`, `X` and `*`, where `1.2.x` is equivalent to `>= 1.2.0 <\n   1.3.0`.\n * tilde ranges (patch version changes allowed), where `~1.2.3` is equivalent to\n   `>= 1.2.3 < 1.3.0`.\n * caret ranges (minor version changes allowed), where `^1.2.3` is equivalent to\n   `>= 1.2.3 < 2.0.0`.\n\nFor a detailed explanation of supported semver constraints see\n[Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Deprecating Charts\n\nWhen managing charts in a Chart Repository, it is sometimes necessary to\ndeprecate a chart. The optional `deprecated` field in `Chart.yaml` can be used\nto mark a chart as deprecated. If the **latest** version of a chart in the\nrepository is marked as deprecated, then the chart as a whole is considered to\nbe deprecated. The chart name can be later reused by publishing a newer version\nthat is not marked as deprecated. The workflow for deprecating charts is:\n\n1. Update chart's `Chart.yaml` to mark the chart as deprecated, bumping the\n   version\n2. Release the new chart version in the Chart Repository\n3. Remove the chart from the source repository (e.g. git)\n\n### Chart Types\n\nThe `type` field defines the type of chart. There are two types: `application`\nand `library`. Application is the default type and it is the standard chart\nwhich can be operated on fully. The [library chart](/topics/library_charts.md) provides utilities or functions for the\nchart builder. A library chart differs from an application chart because it is\nnot installable and usually doesn't contain any resource objects.\n\n**Note:** An application chart can be used as a library chart. This is enabled\nby setting the type to `library`. The chart will then be rendered as a library\nchart where all utilities and functions can be leveraged. All resource objects\nof the chart will not be rendered.\n\n## Chart LICENSE, README and NOTES\n\nCharts can also contain files that describe the installation, configuration,\nusage and license of a chart.\n\nA LICENSE is a plain text file containing the\n[license](https://en.wikipedia.org/wiki/Software_license) for the chart. The\nchart can contain a license as it may have programming logic in the templates\nand would therefore not be configuration only. There can also be separate\nlicense(s) for the application installed by the chart, if required.\n\nA README for a chart should be formatted in Markdown (README.md), and should\ngenerally contain:\n\n- A description of the application or service the chart provides\n- Any prerequisites or requirements to run the chart\n- Descriptions of options in `values.yaml` and default values\n- Any other information that may be relevant to the installation or\n  configuration of the chart\n\nWhen hubs and other user interfaces display details about a chart that detail is\npulled from the content in the `README.md` file.\n\nThe chart can also contain a short plain text `templates/NOTES.txt` file that\nwill be printed out after installation, and when viewing the status of a\nrelease. This file is evaluated as a [template](#templates-and-values), and can\nbe used to display usage notes, next steps, or any other information relevant to\na release of the chart. For example, instructions could be provided for\nconnecting to a database, or accessing a web UI. Since this file is printed to\nSTDOUT when running `helm install` or `helm status`, it is recommended to keep\nthe content brief and point to the README for greater detail.\n\n## Chart Dependencies\n\nIn Helm, one chart may depend on any number of other charts. These dependencies\ncan be dynamically linked using the `dependencies` field in `Chart.yaml` or\nbrought in to the `charts/` directory and managed manually.\n\n### Managing Dependencies with the `dependencies` field\n\nThe charts required by the current chart are defined as a list in the\n`dependencies` field.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- The `name` field is the name of the chart you want.\n- The `version` field is the version of the chart you want.\n- The `repository` field is the full URL to the chart repository. Note that you\n  must also use `helm repo add` to add that repo locally.\n- You might use the name of the repo instead of URL\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nOnce you have defined dependencies, you can run `helm dependency update` and it\nwill use your dependency file to download all the specified charts into your\n`charts/` directory for you.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nWhen `helm dependency update` retrieves charts, it will store them as chart\narchives in the `charts/` directory. So for the example above, one would expect\nto see the following files in the charts directory:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Alias field in dependencies\n\nIn addition to the other fields above, each requirements entry may contain the\noptional field `alias`.\n\nAdding an alias for a dependency chart would put a chart in dependencies using\nalias as name of new dependency.\n\nOne can use `alias` in cases where they need to access a chart with other\nname(s).\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nIn the above example we will get 3 dependencies in all for `parentchart`:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nThe manual way of achieving this is by copy/pasting the same chart in the\n`charts/` directory multiple times with different names.\n\n#### Tags and Condition fields in dependencies\n\nIn addition to the other fields above, each requirements entry may contain the\noptional fields `tags` and `condition`.\n\nAll charts are loaded by default. If `tags` or `condition` fields are present,\nthey will be evaluated and used to control loading for the chart(s) they are\napplied to.\n\nCondition - The condition field holds one or more YAML paths (delimited by\ncommas). If this path exists in the top parent's values and resolves to a\nboolean value, the chart will be enabled or disabled based on that boolean\nvalue.  Only the first valid path found in the list is evaluated and if no paths\nexist then the condition has no effect.\n\nTags - The tags field is a YAML list of labels to associate with this chart. In\nthe top parent's values, all charts with tags can be enabled or disabled by\nspecifying the tag and a boolean value.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nIn the above example all charts with the tag `front-end` would be disabled but\nsince the `subchart1.enabled` path evaluates to 'true' in the parent's values,\nthe condition will override the `front-end` tag and `subchart1` will be enabled.\n\nSince `subchart2` is tagged with `back-end` and that tag evaluates to `true`,\n`subchart2` will be enabled. Also note that although `subchart2` has a condition\nspecified, there is no corresponding path and value in the parent's values so\nthat condition has no effect.\n\n##### Using the CLI with Tags and Conditions\n\nThe `--set` parameter can be used as usual to alter tag and condition values.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Tags and Condition Resolution\n\n- **Conditions (when set in values) always override tags.** The first condition\n  path that exists wins and subsequent ones for that chart are ignored.\n- Tags are evaluated as 'if any of the chart's tags are true then enable the\n  chart'.\n- Tags and conditions values must be set in the top parent's values.\n- The `tags:` key in values must be a top level key. Globals and nested `tags:`\n  tables are not currently supported.\n\n#### Importing Child Values via dependencies\n\nIn some cases it is desirable to allow a child chart's values to propagate to\nthe parent chart and be shared as common defaults. An additional benefit of\nusing the `exports` format is that it will enable future tooling to introspect\nuser-settable values.\n\nThe keys containing the values to be imported can be specified in the parent\nchart's `dependencies` in the field `import-values` using a YAML list. Each item\nin the list is a key which is imported from the child chart's `exports` field.\n\nTo import values not contained in the `exports` key, use the\n[child-parent](#using-the-child-parent-format) format. Examples of both formats\nare described below.\n\n##### Using the exports format\n\nIf a child chart's `values.yaml` file contains an `exports` field at the root,\nits contents may be imported directly into the parent's values by specifying the\nkeys to import as in the example below:\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\nSince we are specifying the key `data` in our import list, Helm looks in the\n`exports` field of the child chart for `data` key and imports its contents.\n\nThe final parent values would contain our exported field:\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\nPlease note the parent key `data` is not contained in the parent's final values.\nIf you need to specify the parent key, use the 'child-parent' format.\n\n##### Using the child-parent format\n\nTo access values that are not contained in the `exports` key of the child\nchart's values, you will need to specify the source key of the values to be\nimported (`child`) and the destination path in the parent chart's values\n(`parent`).\n\nThe `import-values` in the example below instructs Helm to take any values found\nat `child:` path and copy them to the parent's values at the path specified in\n`parent:`\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nIn the above example, values found at `default.data` in the subchart1's values\nwill be imported to the `myimports` key in the parent chart's values as detailed\nbelow:\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nThe parent chart's resulting values would be:\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nThe parent's final values now contains the `myint` and `mybool` fields imported\nfrom subchart1.\n\n### Managing Dependencies manually via the `charts/` directory\n\nIf more control over dependencies is desired, these dependencies can be\nexpressed explicitly by copying the dependency charts into the `charts/`\ndirectory.\n\nA dependency should be an unpacked chart directory but its name cannot start \nwith `_` or `.`. Such files are ignored by the chart loader.\n\nFor example, if the WordPress chart depends on the Apache chart, the Apache\nchart (of the correct version) is supplied in the WordPress chart's `charts/`\ndirectory:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nThe example above shows how the WordPress chart expresses its dependency on\nApache and MySQL by including those charts inside of its `charts/` directory.\n\n**TIP:** _To drop a dependency into your `charts/` directory, use the `helm\npull` command_\n\n### Operational aspects of using dependencies\n\nThe above sections explain how to specify chart dependencies, but how does this\naffect chart installation using `helm install` and `helm upgrade`?\n\nSuppose that a chart named \"A\" creates the following Kubernetes objects\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nFurthermore, A is dependent on chart B that creates objects\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nAfter installation/upgrade of chart A a single Helm release is created/modified.\nThe release will create/update all of the above Kubernetes objects in the\nfollowing order:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nThis is because when Helm installs/upgrades charts, the Kubernetes objects from\nthe charts and all its dependencies are\n\n- aggregated into a single set; then\n- sorted by type followed by name; and then\n- created/updated in that order.\n\nHence a single release is created with all the objects for the chart and its\ndependencies.\n\nThe install order of Kubernetes types is given by the enumeration InstallOrder\nin kind_sorter.go (see [the Helm source\nfile](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n## Templates and Values\n\nHelm Chart templates are written in the [Go template\nlanguage](https://golang.org/pkg/text/template/), with the addition of 50 or so\nadd-on template functions [from the Sprig\nlibrary](https://github.com/Masterminds/sprig) and a few other [specialized\nfunctions](/howto/charts_tips_and_tricks.md).\n\nAll template files are stored in a chart's `templates/` folder. When Helm\nrenders the charts, it will pass every file in that directory through the\ntemplate engine.\n\nValues for the templates are supplied two ways:\n\n- Chart developers may supply a file called `values.yaml` inside of a chart.\n  This file can contain default values.\n- Chart users may supply a YAML file that contains values. This can be provided\n  on the command line with `helm install`.\n\nWhen a user supplies custom values, these values will override the values in the\nchart's `values.yaml` file.\n\n### Template Files\n\nTemplate files follow the standard conventions for writing Go templates (see\n[the text/template Go package\ndocumentation](https://golang.org/pkg/text/template/) for details). An example\ntemplate file might look something like this:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nThe above example, based loosely on\n[https://github.com/deis/charts](https://github.com/deis/charts), is a template\nfor a Kubernetes replication controller. It can use the following four template\nvalues (usually defined in a `values.yaml` file):\n\n- `imageRegistry`: The source registry for the Docker image.\n- `dockerTag`: The tag for the docker image.\n- `pullPolicy`: The Kubernetes pull policy.\n- `storage`: The storage backend, whose default is set to `\"minio\"`\n\nAll of these values are defined by the template author. Helm does not require or\ndictate parameters.\n\nTo see many working charts, check out the CNCF [Artifact\nHub](https://artifacthub.io/packages/search?kind=0).\n\n### Predefined Values\n\nValues that are supplied via a `values.yaml` file (or via the `--set` flag) are\naccessible from the `.Values` object in a template. But there are other\npre-defined pieces of data you can access in your templates.\n\nThe following values are pre-defined, are available to every template, and\ncannot be overridden. As with all values, the names are _case sensitive_.\n\n- `Release.Name`: The name of the release (not the chart)\n- `Release.Namespace`: The namespace the chart was released to.\n- `Release.Service`: The service that conducted the release.\n- `Release.IsUpgrade`: This is set to true if the current operation is an\n  upgrade or rollback.\n- `Release.IsInstall`: This is set to true if the current operation is an\n  install.\n- `Chart`: The contents of the `Chart.yaml`. Thus, the chart version is\n  obtainable as `Chart.Version` and the maintainers are in `Chart.Maintainers`.\n- `Files`: A map-like object containing all non-special files in the chart. This\n  will not give you access to templates, but will give you access to additional\n  files that are present (unless they are excluded using `.helmignore`). Files\n  can be accessed using `{{ index .Files \"file.name\" }}` or using the\n  `{{.Files.Get name }}` function. You can also access the contents of the file\n  as `[]byte` using `{{ .Files.GetBytes }}`\n- `Capabilities`: A map-like object that contains information about the versions\n  of Kubernetes (`{{ .Capabilities.KubeVersion }}`) and the supported Kubernetes\n  API versions (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n**NOTE:** Any unknown `Chart.yaml` fields will be dropped. They will not be\naccessible inside of the `Chart` object. Thus, `Chart.yaml` cannot be used to\npass arbitrarily structured data into the template. The values file can be used\nfor that, though.\n\n### Values files\n\nConsidering the template in the previous section, a `values.yaml` file that\nsupplies the necessary values would look like this:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nA values file is formatted in YAML. A chart may include a default `values.yaml`\nfile. The Helm install command allows a user to override values by supplying\nadditional YAML values:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nWhen values are passed in this way, they will be merged into the default values\nfile. For example, consider a `myvals.yaml` file that looks like this:\n\n```yaml\nstorage: \"gcs\"\n```\n\nWhen this is merged with the `values.yaml` in the chart, the resulting generated\ncontent will be:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nNote that only the last field was overridden.\n\n**NOTE:** The default values file included inside of a chart _must_ be named\n`values.yaml`. But files specified on the command line can be named anything.\n\n**NOTE:** If the `--set` flag is used on `helm install` or `helm upgrade`, those\nvalues are simply converted to YAML on the client side.\n\n**NOTE:** If any required entries in the values file exist, they can be declared\nas required in the chart template by using the ['required' function](/howto/charts_tips_and_tricks.md)\n\nAny of these values are then accessible inside of templates using the `.Values`\nobject:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Scope, Dependencies, and Values\n\nValues files can declare values for the top-level chart, as well as for any of\nthe charts that are included in that chart's `charts/` directory. Or, to phrase\nit differently, a values file can supply values to the chart as well as to any\nof its dependencies. For example, the demonstration WordPress chart above has\nboth `mysql` and `apache` as dependencies. The values file could supply values\nto all of these components:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nCharts at a higher level have access to all of the variables defined beneath. So\nthe WordPress chart can access the MySQL password as `.Values.mysql.password`.\nBut lower level charts cannot access things in parent charts, so MySQL will not\nbe able to access the `title` property. Nor, for that matter, can it access\n`apache.port`.\n\nValues are namespaced, but namespaces are pruned. So for the WordPress chart, it\ncan access the MySQL password field as `.Values.mysql.password`. But for the\nMySQL chart, the scope of the values has been reduced and the namespace prefix\nremoved, so it will see the password field simply as `.Values.password`.\n\n#### Global Values\n\nAs of 2.0.0-Alpha.2, Helm supports special \"global\" value. Consider this\nmodified version of the previous example:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nThe above adds a `global` section with the value `app: MyWordPress`. This value\nis available to _all_ charts as `.Values.global.app`.\n\nFor example, the `mysql` templates may access `app` as `{{\n.Values.global.app}}`, and so can the `apache` chart. Effectively, the values\nfile above is regenerated like this:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\nThis provides a way of sharing one top-level variable with all subcharts, which\nis useful for things like setting `metadata` properties like labels.\n\nIf a subchart declares a global variable, that global will be passed _downward_\n(to the subchart's subcharts), but not _upward_ to the parent chart. There is no\nway for a subchart to influence the values of the parent chart.\n\nAlso, global variables of parent charts take precedence over the global\nvariables from subcharts.\n\n### Schema Files\n\nSometimes, a chart maintainer might want to define a structure on their values.\nThis can be done by defining a schema in the `values.schema.json` file. A schema\nis represented as a [JSON Schema](https://json-schema.org/). It might look\nsomething like this:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nThis schema will be applied to the values to validate it. Validation occurs when\nany of the following commands are invoked:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nAn example of a `values.yaml` file that meets the requirements of this schema\nmight look something like this:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nNote that the schema is applied to the final `.Values` object, and not just to\nthe `values.yaml` file. This means that the following `yaml` file is valid,\ngiven that the chart is installed with the appropriate `--set` option shown\nbelow.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nFurthermore, the final `.Values` object is checked against *all* subchart\nschemas. This means that restrictions on a subchart can't be circumvented by a\nparent chart. This also works backwards - if a subchart has a requirement that\nis not met in the subchart's `values.yaml` file, the parent chart *must* satisfy\nthose restrictions in order to be valid.\n\nSchema validation can be disabled by setting the option shown below.\nThis is particularly useful in air-gapped environments when a chart's JSON Schema file contains remote references.\n```console\nhelm install --skip-schema-validation\n```\n\n### References\n\nWhen it comes to writing templates, values, and schema files, there are several\nstandard references that will help you out.\n\n- [Go templates](https://godoc.org/text/template)\n- [Extra template functions](https://godoc.org/github.com/Masterminds/sprig)\n- [The YAML format](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRDs)\n\nKubernetes provides a mechanism for declaring new types of Kubernetes objects.\nUsing CustomResourceDefinitions (CRDs), Kubernetes developers can declare custom\nresource types.\n\nIn Helm 3, CRDs are treated as a special kind of object. They are installed\nbefore the rest of the chart, and are subject to some limitations.\n\nCRD YAML files should be placed in the `crds/` directory inside of a chart.\nMultiple CRDs (separated by YAML start and end markers) may be placed in the\nsame file. Helm will attempt to load _all_ of the files in the CRD directory\ninto Kubernetes.\n\nCRD files _cannot be templated_. They must be plain YAML documents.\n\nWhen Helm installs a new chart, it will upload the CRDs, pause until the CRDs\nare made available by the API server, and then start the template engine, render\nthe rest of the chart, and upload it to Kubernetes. Because of this ordering,\nCRD information is available in the `.Capabilities` object in Helm templates,\nand Helm templates may create new instances of objects that were declared in\nCRDs.\n\nFor example, if your chart had a CRD for `CronTab` in the `crds/` directory, you\nmay create instances of the `CronTab` kind in the `templates/` directory:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nThe `crontab.yaml` file must contain the CRD with no template directives:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nThen the template `mycrontab.yaml` may create a new `CronTab` (using templates\nas usual):\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm will make sure that the `CronTab` kind has been installed and is available\nfrom the Kubernetes API server before it proceeds installing the things in\n`templates/`.\n\n### Limitations on CRDs\n\nUnlike most objects in Kubernetes, CRDs are installed globally. For that reason,\nHelm takes a very cautious approach in managing CRDs. CRDs are subject to the\nfollowing limitations:\n\n- CRDs are never reinstalled. If Helm determines that the CRDs in the `crds/`\n  directory are already present (regardless of version), Helm will not attempt\n  to install or upgrade.\n- CRDs are never installed on upgrade or rollback. Helm will only create CRDs on\n  installation operations.\n- CRDs are never deleted. Deleting a CRD automatically deletes all of the CRD's\n  contents across all namespaces in the cluster. Consequently, Helm will not\n  delete CRDs.\n\nOperators who want to upgrade or delete CRDs are encouraged to do this manually\nand with great care.\n\n## Using Helm to Manage Charts\n\nThe `helm` tool has several commands for working with charts.\n\nIt can create a new chart for you:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nOnce you have edited a chart, `helm` can package it into a chart archive for\nyou:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nYou can also use `helm` to help you find issues with your chart's formatting or\ninformation:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Chart Repositories\n\nA _chart repository_ is an HTTP server that houses one or more packaged charts.\nWhile `helm` can be used to manage local chart directories, when it comes to\nsharing charts, the preferred mechanism is a chart repository.\n\nAny HTTP server that can serve YAML files and tar files and can answer GET\nrequests can be used as a repository server. The Helm team has tested some\nservers, including Google Cloud Storage with website mode enabled, and S3 with\nwebsite mode enabled.\n\nA repository is characterized primarily by the presence of a special file called\n`index.yaml` that has a list of all of the packages supplied by the repository,\ntogether with metadata that allows retrieving and verifying those packages.\n\nOn the client side, repositories are managed with the `helm repo` commands.\nHowever, Helm does not provide tools for uploading charts to remote repository\nservers. This is because doing so would add substantial requirements to an\nimplementing server, and thus raise the barrier for setting up a repository.\n\n## Chart Starter Packs\n\nThe `helm create` command takes an optional `--starter` option that lets you\nspecify a \"starter chart\". Also, the starter option has a short alias `-p`.\n\nExamples of usage:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nStarters are just regular charts, but are located in\n`$XDG_DATA_HOME/helm/starters`. As a chart developer, you may author charts that\nare specifically designed to be used as starters. Such charts should be designed\nwith the following considerations in mind:\n\n- The `Chart.yaml` will be overwritten by the generator.\n- Users will expect to modify such a chart's contents, so documentation should\n  indicate how users can do so.\n- All occurrences of `<CHARTNAME>` 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, `<CHARTNAME>` will NOT override inside them. Additionally, the chart description is not inherited.\n\nCurrently the only way to add a chart to `$XDG_DATA_HOME/helm/starters` is to\nmanually copy it there. In your chart's documentation, you may want to explain\nthat process.\n"
  },
  {
    "path": "docs/topics/charts_hooks.md",
    "content": "---\ntitle: Chart Hooks\ndescription: Describes how to work with chart hooks.\nsidebar_position: 2\n---\n\nHelm provides a _hook_ mechanism to allow chart developers to intervene at\ncertain points in a release's life cycle. For example, you can use hooks to:\n\n- Load a ConfigMap or Secret during install before any other charts are loaded.\n- Execute a Job to back up a database before installing a new chart, and then\n  execute a second job after the upgrade in order to restore data.\n- Run a Job before deleting a release to gracefully take a service out of\n  rotation before removing it.\n\nHooks work like regular templates, but they have special annotations that cause\nHelm to utilize them differently. In this section, we cover the basic usage\npattern for hooks.\n\n## The Available Hooks\n\nThe following hooks are defined:\n\n| Annotation Value | Description                                                                                           |\n| ---------------- | ----------------------------------------------------------------------------------------------------- |\n| `pre-install`    | Executes after templates are rendered, but before any resources are created in Kubernetes             |\n| `post-install`   | Executes after all resources are loaded into Kubernetes                                               |\n| `pre-delete`     | Executes on a deletion request before any resources are deleted from Kubernetes                       |\n| `post-delete`    | Executes on a deletion request after all of the release's resources have been deleted                 |\n| `pre-upgrade`    | Executes on an upgrade request after templates are rendered, but before any resources are updated     |\n| `post-upgrade`   | Executes on an upgrade request after all resources have been upgraded                                 |\n| `pre-rollback`   | Executes on a rollback request after templates are rendered, but before any resources are rolled back |\n| `post-rollback`  | Executes on a rollback request after all resources have been modified                                 |\n| `test`           | Executes when the Helm test subcommand is invoked ([view test docs](/topics/chart_tests.md))              |\n\n_Note that the `crd-install` hook has been removed in favor of the `crds/`\ndirectory in Helm 3._\n\n## Hooks and the Release Lifecycle\n\nHooks allow you, the chart developer, an opportunity to perform operations at\nstrategic points in a release lifecycle. For example, consider the lifecycle for\na `helm install`. By default, the lifecycle looks like this:\n\n1. User runs `helm install foo`\n2. The Helm library install API is called\n3. After some verification, the library renders the `foo` templates\n4. The library loads the resulting resources into Kubernetes\n5. The library returns the release object (and other data) to the client\n6. The client exits\n\nHelm defines two hooks for the `install` lifecycle: `pre-install` and\n`post-install`. If the developer of the `foo` chart implements both hooks, the\nlifecycle is altered like this:\n\n1. User runs `helm install foo`\n2. The Helm library install API is called\n3. CRDs in the `crds/` directory are installed\n4. After some verification, the library renders the `foo` templates\n5. The library prepares to execute the `pre-install` hooks (loading hook\n   resources into Kubernetes)\n6. The library sorts hooks by weight (assigning a weight of 0 by default), \n   by resource kind and finally by name in ascending order.\n7. The library then loads the hook with the lowest weight first (negative to\n   positive)\n8. The library waits until the hook is \"Ready\" (except for CRDs)\n9. The library loads the resulting resources into Kubernetes. Note that if the\n   `--wait` flag is set, the library will wait until all resources are in a\n   ready state and will not run the `post-install` hook until they are ready.\n10. The library executes the `post-install` hook (loading hook resources)\n11. The library waits until the hook is \"Ready\"\n12. The library returns the release object (and other data) to the client\n13. The client exits\n\nWhat does it mean to wait until a hook is ready? This depends on the resource\ndeclared in the hook. If the resource is a `Job` or `Pod` kind, Helm will wait\nuntil it successfully runs to completion. And if the hook fails, the release\nwill fail. This is a _blocking operation_, so the Helm client will pause while\nthe Job is run.\n\nFor all other kinds, as soon as Kubernetes marks the resource as loaded (added\nor updated), the resource is considered \"Ready\". When many resources are\ndeclared in a hook, the resources are executed serially. If they have hook\nweights (see below), they are executed in weighted order. \nStarting from Helm 3.2.0 hook resources with same weight are installed in the same \norder as normal non-hook resources. Otherwise, ordering is\nnot guaranteed. (In Helm 2.3.0 and after, they are sorted alphabetically. That\nbehavior, though, is not considered binding and could change in the future.) It\nis considered good practice to add a hook weight, and set it to `0` if weight is\nnot important.\n\n### Hook resources are not managed with corresponding releases\n\nThe resources that a hook creates are currently not tracked or managed as part\nof the release. Once Helm verifies that the hook has reached its ready state, it\nwill leave the hook resource alone. Garbage collection of hook resources when\nthe corresponding release is deleted may be added to Helm 3 in the future, so\nany hook resources that must never be deleted should be annotated with\n`helm.sh/resource-policy: keep`.\n\nPractically speaking, this means that if you create resources in a hook, you\ncannot rely upon `helm uninstall` to remove the resources. To destroy such\nresources, you need to either [add a custom `helm.sh/hook-delete-policy`\nannotation](#hook-deletion-policies) to the hook template file, or [set the time\nto live (TTL) field of a Job\nresource](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Writing a Hook\n\nHooks are just Kubernetes manifest files with special annotations in the\n`metadata` section. Because they are template files, you can use all of the\nnormal template features, including reading `.Values`, `.Release`, and\n`.Template`.\n\nFor example, this template, stored in `templates/post-install-job.yaml`,\ndeclares a job to be run on `post-install`:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nWhat makes this template a hook is the annotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nOne resource can implement multiple hooks:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nSimilarly, there is no limit to the number of different resources that may\nimplement a given hook. For example, one could declare both a secret and a\nconfig map as a pre-install hook.\n\nWhen subcharts declare hooks, those are also evaluated. There is no way for a\ntop-level chart to disable the hooks declared by subcharts.\n\nIt is possible to define a weight for a hook which will help build a\ndeterministic executing order. Weights are defined using the following\nannotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nHook weights can be positive or negative numbers but must be represented as\nstrings. When Helm starts the execution cycle of hooks of a particular Kind it\nwill sort those hooks in ascending order.\n\n### Hook deletion policies\n\nIt is possible to define policies that determine when to delete corresponding\nhook resources. Hook deletion policies are defined using the following\nannotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nYou can choose one or more defined annotation values:\n\n| Annotation Value       | Description                                                          |\n| ---------------------- | -------------------------------------------------------------------- |\n| `before-hook-creation` | Delete the previous resource before a new hook is launched (default) |\n| `hook-succeeded`       | Delete the resource after the hook is successfully executed          |\n| `hook-failed`          | Delete the resource if the hook failed during execution              |\n\nIf no hook deletion policy annotation is specified, the `before-hook-creation`\nbehavior applies by default.\n"
  },
  {
    "path": "docs/topics/index.mdx",
    "content": "---\ntitle: Topics\nsidebar_position: 3\n---\n\n# Topic Guides\n\nHere you’ll find introductions to all the key parts of Helm you’ll need or want\nto know.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "docs/topics/kubernetes_apis.md",
    "content": "---\ntitle: Deprecated Kubernetes APIs\ndescription: Explains deprecated Kubernetes APIs in Helm\n---\n\nKubernetes is an API-driven system and the API evolves over time to reflect the\nevolving understanding of the problem space. This is common practice across\nsystems and their APIs. An important part of evolving APIs is a good deprecation\npolicy and process to inform users of how changes to APIs are implemented. In\nother words, consumers of your API need to know in advance and in what release\nan API will be removed or changed. This removes the element of surprise and\nbreaking changes to consumers.\n\nThe [Kubernetes deprecation\npolicy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\ndocuments how Kubernetes handles the changes to its API versions. The policy for\ndeprecation states the timeframe that API versions will be supported following a\ndeprecation announcement. It is therefore important to be aware of deprecation\nannouncements and know when API versions will be removed, to help minimize the\neffect.\n\nThis is an example of an announcement [for the removal of deprecated API\nversions in Kubernetes\n1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) and was\nadvertised a few months prior to the release. These API versions would have been\nannounced for deprecation prior to this again. This shows that there is a good\npolicy in place which informs consumers of API version support.\n\nHelm templates specify a [Kubernetes API\ngroup](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)\nwhen defining a Kubernetes object, similar to a Kubernetes manifest file. It is\nspecified in the `apiVersion` field of the template and it identifies the API\nversion of the Kubernetes object. This means that Helm users and chart\nmaintainers need to be aware when Kubernetes API versions have been deprecated\nand in what Kubernetes version they will be removed.\n\n## Chart Maintainers\n\nYou should audit your charts checking for Kubernetes API versions that are\ndeprecated or are removed in a Kubernetes version. The API versions found as due\nto be or that are now out of support, should be updated to the supported version\nand a new version of the chart released. The API version is defined by the\n`kind` and `apiVersion` fields. For example, here is a removed `Deployment`\nobject API version in Kubernetes 1.16:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Helm Users\n\nYou should audit the charts that you use (similar to [chart\nmaintainers](#chart-maintainers)) and identify any charts where API versions are\ndeprecated or removed in a Kubernetes version. For the charts identified, you\nneed to check for the latest version of the chart (which has supported API\nversions) or update the chart yourself.\n\nAdditionally, you also need to audit any charts deployed (i.e. Helm releases)\nchecking again for any deprecated or removed API versions. This can be done by\ngetting details of a release using the `helm get manifest` command.\n\nThe means for updating a Helm release to supported APIs depends on your findings\nas follows:\n\n1. If you find deprecated API versions only then:\n  - Perform a `helm upgrade` with a version of the chart with supported\n    Kubernetes API versions\n  - Add a description in the upgrade, something along the lines to not perform a\n    rollback to a Helm version prior to this current version\n2.  If you find any API version(s) that is/are removed in a Kubernetes version\n    then:\n  - If you are running a Kubernetes version where the API version(s) are still\n    available (for example, you are on Kubernetes 1.15 and found you use APIs\n    that will be removed in Kubernetes 1.16):\n    - Follow the step 1 procedure\n  - Otherwise (for example, you are already running a Kubernetes version where\n    some API versions reported by `helm get manifest` are no longer available):\n    - You need to edit the release manifest that is stored in the cluster to\n      update the API versions to supported APIs. See [Updating API Versions of a\n      Release Manifest](#updating-api-versions-of-a-release-manifest) for more\n      details\n\n> Note: In all cases of updating a Helm release with supported APIs, you should\nnever rollback the release to a version prior to the release version with the\nsupported APIs.\n\n> Recommendation: The best practice is to upgrade releases using deprecated API\nversions to supported API versions, prior to upgrading to a kubernetes cluster\nthat removes those API versions.\n\nIf you don't update a release as suggested previously, you will have an error\nsimilar to the following when trying to upgrade a release in a Kubernetes\nversion where its API version(s) is/are removed:\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm fails in this scenario because it attempts to create a diff patch between\nthe current deployed release (which contains the Kubernetes APIs that are\nremoved in this Kubernetes version) against the chart you are passing with the\nupdated/supported API versions. The underlying reason for failure is that when\nKubernetes removes an API version, the Kubernetes Go client library can no\nlonger parse the deprecated objects and Helm therefore fails when calling the\nlibrary. Helm unfortunately is unable to recover from this situation and is no\nlonger able to manage such a release. See [Updating API Versions of a Release\nManifest](#updating-api-versions-of-a-release-manifest) for more details on how\nto recover from this scenario.\n\n## Updating API Versions of a Release Manifest\n\nThe manifest is a property of the Helm release object which is stored in the\ndata field of a Secret (default) or ConfigMap in the cluster. The data field\ncontains a gzipped object which is base 64 encoded (there is an additional base\n64 encoding for a Secret). There is a Secret/ConfigMap per release\nversion/revision in the namespace of the release.\n\nYou can use the Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis)\nplugin to perform the update of a release to supported APIs. Check out the\nreadme for more details.\n\nAlternatively, you can follow these manual steps to perform an update of the API\nversions of a release manifest. Depending on your configuration you will follow\nthe steps for the Secret or ConfigMap backend.\n\n- Get the name of the Secret or Configmap associated with the latest deployed\n  release:\n  - Secrets backend: `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - ConfigMap backend: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- Get latest deployed release details:\n  - Secrets backend: `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - ConfigMap backend: `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- Backup the release in case you need to restore if something goes wrong:\n  - `cp release.yaml release.bak`\n  - In case of emergency, restore: `kubectl apply -f release.bak -n\n    <release_namespace>`\n- Decode the release object:\n  - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- Change API versions of the manifests. Can use any tool (e.g. editor) to make\n  the changes. This is in the `manifest` field of your decoded release object\n  (`release.data.decoded`)\n- Encode the release object:\n  - Secrets backend: `cat release.data.decoded | gzip | base64 | base64`\n  - ConfigMap backend: `cat release.data.decoded | gzip | base64`\n- Replace `data.release` property value in the deployed release file\n  (`release.yaml`) with the new encoded release object\n- Apply file to namespace: `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- Perform a `helm upgrade` with a version of the chart with supported Kubernetes\n  API versions\n- Add a description in the upgrade, something along the lines to not perform a\n  rollback to a Helm version prior to this current version\n"
  },
  {
    "path": "docs/topics/kubernetes_distros.md",
    "content": "---\ntitle: Kubernetes Distribution Guide\ndescription: Captures information about using Helm in specific Kubernetes environments.\nsidebar_position: 10\n---\n\nHelm should work with any [conformant version of\nKubernetes](https://github.com/cncf/k8s-conformance) (whether\n[certified](https://www.cncf.io/certification/software-conformance/) or not).\n\nThis document captures information about using Helm in specific Kubernetes\nenvironments. Please contribute more details about any distros (sorted\nalphabetically) if desired.\n\n\n## AKS\n\nHelm works with [Azure Kubernetes\nService](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nHelm has been tested and is working on Mesospheres DC/OS 1.11 Kubernetes\nplatform, and requires no additional configuration.\n\n## EKS\n\nHelm works with Amazon Elastic Kubernetes Service (Amazon EKS):\n[Using Helm with Amazon\nEKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nGoogle's GKE hosted Kubernetes platform is known to work with Helm, and requires\nno additional configuration.\n\n## `scripts/local-cluster` and Hyperkube\n\nHyperkube configured via `scripts/local-cluster.sh` is known to work. For raw\nHyperkube you may need to do some manual configuration.\n\n## IKS\n\nHelm works with [IBM Cloud Kubernetes\nService](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nHelm is regularly tested on [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne\n\nHelm works in clusters that are set up by KubeOne without caveats.\n\n## Kubermatic\n\nHelm works in user clusters that are created by Kubermatic without caveats.\nSince seed cluster can be set up in different ways Helm support depends on their\nconfiguration.\n\n## MicroK8s\n\nHelm can be enabled in [MicroK8s](https://microk8s.io) using the command:\n`microk8s.enable helm3`\n\n## Minikube\n\nHelm is tested and known to work with\n[Minikube](https://github.com/kubernetes/minikube). It requires no additional\nconfiguration.\n\n## Openshift\n\nHelm works straightforward on OpenShift Online, OpenShift Dedicated, OpenShift\nContainer Platform (version >= 3.6) or OpenShift Origin (version >= 3.6). To\nlearn more read [this\nblog](https://blog.openshift.com/getting-started-helm-openshift/) post.\n\n## Platform9\n\nHelm is pre-installed with [Platform9 Managed\nKubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes).\nPlatform9 provides access to all official Helm charts through the App Catalog UI\nand native Kubernetes CLI. Additional repositories can be manually added.\nFurther details are available in this [Platform9 App Catalog\narticle](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes).\n\n## Ubuntu with `kubeadm`\n\nKubernetes bootstrapped with `kubeadm` is known to work on the following Linux\ndistributions:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nSome versions of Helm (v2.0.0-beta2) require you to `export\nKUBECONFIG=/etc/kubernetes/admin.conf` or create a `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid\n\nHelm runs on VMware Tanzu Kubernetes Grid, TKG, without needing configuration changes.\nThe Tanzu CLI can manage installing packages for [helm-controller](https://fluxcd.io/flux/components/helm/) allowing for declaratively managing Helm chart releases.\nFurther 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).\n"
  },
  {
    "path": "docs/topics/library_charts.md",
    "content": "---\ntitle: Library Charts\ndescription: Explains library charts and examples of usage\nsidebar_position: 4\n---\n\nA library chart is a type of [Helm chart](/topics/charts.mdx)\nthat defines chart primitives or definitions which can be shared by Helm\ntemplates in other charts. This allows users to share snippets of code that can\nbe re-used across charts, avoiding repetition and keeping charts\n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nThe library chart was introduced in Helm 3 to formally recognize common or\nhelper charts that have been used by chart maintainers since Helm 2. By\nincluding it as a chart type, it provides:\n- A means to explicitly distinguish between common and application charts\n- Logic to prevent installation of a common chart\n- No rendering of templates in a common chart which may contain release\n  artifacts\n- Allow for dependent charts to use the importer's context\n\nA chart maintainer can define a common chart as a library chart and now be\nconfident that Helm will handle the chart in a standard consistent fashion. It\nalso means that definitions in an application chart can be shared by changing\nthe chart type.\n\n## Create a Simple Library Chart\n\nAs mentioned previously, a library chart is a type of [Helm chart](/topics/charts.mdx). This means that you can start off by creating a\nscaffold chart:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nYou will first remove all the files in `templates` directory as we will create\nour own templates definitions in this example.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nThe values file will not be required either.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nBefore we jump into creating common code, lets do a quick review of some\nrelevant Helm concepts. A [named template](/chart_template_guide/named_templates.md) (sometimes called a partial\nor a subtemplate) is simply a template defined inside of a file, and given a\nname.  In the `templates/` directory, any file that begins with an underscore(_)\nis not expected to output a Kubernetes manifest file. So by convention, helper\ntemplates and partials are placed in a `_*.tpl` or `_*.yaml` files.\n\nIn this example, we will code a common ConfigMap which creates an empty\nConfigMap resource. We will define the common ConfigMap in file\n`mylibchart/templates/_configmap.yaml` as follows:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nThe ConfigMap construct is defined in named template `mylibchart.configmap.tpl`.\nIt is a simple ConfigMap with an empty resource, `data`. Within this file there\nis another named template called `mylibchart.configmap`. This named template\nincludes another named template `mylibchart.util.merge` which will take 2 named\ntemplates as arguments, the template calling `mylibchart.configmap` and\n`mylibchart.configmap.tpl`.\n\nThe helper function `mylibchart.util.merge` is a named template in\n`mylibchart/templates/_util.yaml`. It is a handy util from [The Common Helm\nHelper Chart](#the-common-helm-helper-chart) because it merges the 2 templates\nand overrides any common parts in both:\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nThis is important when a chart wants to use common code that it needs to\ncustomize with its configuration.\n\nFinally, lets change the chart type to `library`. This requires editing\n`mylibchart/Chart.yaml` as follows:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\nThe library chart is now ready to be shared and its ConfigMap definition to be\nre-used.\n\nBefore moving on, it is worth checking if Helm recognizes the chart as a library\nchart:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Use the Simple Library Chart\n\nIt is time to use the library chart. This means creating a scaffold chart again:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nLets clean out the template files again as we want to create a ConfigMap only:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nWhen we want to create a simple ConfigMap in a Helm template, it could look\nsimilar to the following:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nWe are however going to re-use the common code already created in `mylibchart`.\nThe ConfigMap can be created in the file `mychart/templates/configmap.yaml` as\nfollows:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nYou can see that it simplifies the work we have to do by inheriting the common\nConfigMap definition which adds standard properties for ConfigMap. In our\ntemplate we add the configuration, in this case the data key `myvalue` and its\nvalue. The configuration override the empty resource of the common ConfigMap.\nThis is feasible because of the helper function `mylibchart.util.merge` we\nmentioned in the previous section.\n\nTo be able to use the common code, we need to add `mylibchart` as a dependency.\nAdd the following to the end of the file `mychart/Chart.yaml`:\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nThis includes the library chart as a dynamic dependency from the filesystem\nwhich is at the same parent path as our application chart. As we are including\nthe library chart as a dynamic dependency, we need to run `helm dependency\nupdate`. It will copy the library chart into your `charts/` directory.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nWe are now ready to deploy our chart. Before installing, it is worth checking\nthe rendered template first.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nThis looks like the ConfigMap we want with data override of `myvalue: Hello\nWorld`. Lets install it:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nWe can retrieve the release and see that the actual template was loaded.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## Library Chart Benefits\nBecause of their inability to act as standalone charts, library charts can leverage the following functionality:\n- The `.Files` object references the file paths on the parent chart, rather than the path local to the library chart\n- 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.\n\n\n## The Common Helm Helper Chart\n\n```markdown\nNote: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived.\n```\n\nThis [chart](https://github.com/helm/charts/tree/master/incubator/common) was\nthe original pattern for common charts. It provides utilities that reflect best\npractices of Kubernetes chart development. Best of all it can be used off the\nbat by you when developing your charts to give you handy shared code.\n\nHere is a quick way to use it. For more details, have a look at the\n[README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nCreate a scaffold chart again:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nLets use the common code from the helper chart. First, edit deployment\n`demo/templates/deployment.yaml` as follows:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nAnd now the service file, `demo/templates/service.yaml` as follows:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nThese templates show how inheriting the common code from the helper chart\nsimplifies your coding down to your configuration or customization of the\nresources.\n\nTo be able to use the common code, we need to add `common` as a dependency. Add\nthe following to the end of the file `demo/Chart.yaml`:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nNote: You will need to add the `incubator` repo to the Helm repository list\n(`helm repo add`).\n\nAs we are including the chart as a dynamic dependency, we need to run `helm\ndependency update`. It will copy the helper chart into your `charts/` directory.\n\nAs helper chart is using some Helm 2 constructs, you will need to add the\nfollowing to `demo/values.yaml` to enable the `nginx` image to be loaded as this\nwas updated in Helm 3 scaffold chart:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nYou can test that the chart templates are correct prior to deploying using the `helm lint` and `helm template` commands.\n\nIf it's good to go, deploy away using `helm install`!\n\n"
  },
  {
    "path": "docs/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Permissions management for SQL storage backend\ndescription: Get to know how to setup permissions when using SQL storage backend.\n---\n\nThis document aims to provide guidance to users for setting up and managing\npermissions when using the SQL storage backend.\n\n## Introduction\n\nTo handle permissions, Helm leverages the RBAC feature of Kubernetes. When using\nthe SQL storage backend, Kubernetes' roles can't be used to determine whether or\nnot an user can access a given resource. This document shows how to create and\nmanage these permissions.\n\n## Initialization\n\nThe first time the Helm CLI will make connect to your database, the client will\nmake sure that it was previously initialized. If it is not, it will take care of\nthe necessary setup automatically. This initialization requires admin privileges\non the public schema, or at least to be able to:\n\n* create a table\n* grant privileges on the public schema\n\nAfter the migration was run against your database, all the other roles can use\nthe client.\n\n## Grant privileges to a non admin user in PostgreSQL\n\nTo manage permissions, the SQL backend driver leverages the\n[RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)(Row Security\nLevel) feature of PostgreSQL. RLS allows all users to be able to read/write\nfrom/to the same table, without being able to manipulate the same rows if they\nare not explicitly allowed to. By default, any role that has not been\nexplicitly granted with the right privileges will always return an empty list\nwhen running `helm list` and will not be able to retrieve or modify any resource\nin the cluster.\n\nLet's see how to grant a given role access to specific namespaces:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nThis command will grant the permissions to read and write all resources that\nmeet the `namespace = 'default'` condition to the role `role`. After creating\nthis policy, the user being connected to the database on the behalf of the role\n`role` will therefore be able to see all the releases living in the `default`\nnamespace when running `helm list`, and to modify and delete them.\n\nPrivileges can be managed granularly with RLS, and one might be interested in\nrestraining access given the different columns of the table:\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "docs/topics/plugins.mdx",
    "content": "---\ntitle: The Helm Plugins Guide\ndescription: Introduces how to use and create plugins to extend Helm's functionality.\nsidebar_position: 12\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nA Helm plugin is a tool that can be accessed through the `helm` CLI, but which\nis not part of the built-in Helm codebase.\n\nExisting plugins can be found on [related](/community/related#helm-plugins) section or by searching\n[GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).\n\nThis guide explains how to use and create plugins.\n\n## An Overview\n\nHelm plugins are add-on tools that integrate seamlessly with Helm. They provide\na way to extend the core feature set of Helm, but without requiring every new\nfeature to be written in Go and added to the core tool.\n\nHelm plugins have the following features:\n\n- They can be added and removed from a Helm installation without impacting the\n  core Helm tool.\n- They can be written in any programming language.\n- They integrate with Helm, and will show up in `helm help` and other places.\n\nHelm plugins live in `$HELM_PLUGINS`. You can find the current value of this,\nincluding the default value when not set in the environment, using the\n`helm env` command.\n\nThe Helm plugin model is partially based on Git's plugin model. To that end,\nyou may sometimes hear `helm` referred to as the _porcelain_ layer, with plugins\nbeing the _plumbing_. This is a shorthand way of suggesting that Helm provides\nthe user experience and top level processing logic, while the plugins do the\n\"detail work\" of performing a desired action.\n\n## Installing a Plugin\n\nPlugins are installed using the `$ helm plugin install <path|url>` command. You\ncan pass in a path to a plugin on your local file system or a url of a remote\nVCS repo. The `helm plugin install` command clones or copies the plugin at the\npath/url given into `$HELM_PLUGINS`. If you are installing from a VCS you can specify\nthe version with the `--version` argument.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nIf you have a plugin tar distribution, simply untar the plugin into the\n`$HELM_PLUGINS` directory. You can also install tarball plugins\ndirectly from url by issuing `helm plugin install\nhttps://domain/path/to/plugin.tar.gz`\n\n## The Plugin File Structure\n\nIn many ways, a plugin is similar to a chart. Each plugin has a top-level\ndirectory containing a `plugin.yaml` file. Additional files may be present but\nonly the `plugin.yaml` file is required.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## The plugin.yaml File\n\nThe plugin.yaml file is required for a plugin. It contains the following fields:\n\n```yaml\nname: The name of the plugin (REQUIRED)\nversion: A SemVer 2 version (REQUIRED)\nusage: Single line usage text shown in help\ndescription: Long description shown in places like helm help\nignoreFlags: Ignore flags passed in from Helm\nplatformCommand: # Configure command to run based on the platform\n  - os: OS match, can be empty or omitted to match all OS'\n    arch: Architecture match, can be empty or omitted to match all architectures\n    command: Plugin command to execute\n    args: Plugin command arguments\ncommand: (DEPRECATED) Plugin command, use platformCommand instead\nplatformHooks: # Configure plugin lifecycle hooks based on the platform\n  install: # Install lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin install command to execute\n      args: Plugin install command arguments\n  update: # Update lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin update command to execute\n      args: Plugin update command arguments\n  delete: # Delete lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin delete command to execute\n      args: Plugin delete command arguments\nhooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead\n  install: Command to install plugin\n  update: Command to update plugin\n  delete: Command to delete plugin\ndownloaders: # Configure downloaders capability\n  - command: Command to invoke\n    protocols:\n      - Protocol schema supported\n```\n\n### The `name` Field\n\nThe `name` is the name of the plugin. When Helm executes this plugin, this is\nthe name it will use (e.g. `helm NAME` will invoke this plugin).\n\n_`name` should match the directory name._ In our example above, that means the\nplugin with `name: last` should be contained in a directory named `last`.\n\nRestrictions on `name`:\n\n- `name` cannot duplicate one of the existing `helm` top-level commands.\n- `name` must be restricted to the characters ASCII a-z, A-Z, 0-9, `_` and `-`.\n\n### The `version` Field\n\nThe `version` is the SemVer 2 version of the plugin. `usage` and `description` are\nboth used to generate the help text of a command.\n\n### The `ignoreFlags` Field\n\nThe `ignoreFlags` switch tells Helm to _not_ pass flags to the plugin. So if a\nplugin is called with `helm myplugin --foo` and `ignoreFlags: true`, then\n`--foo` is silently discarded.\n\n### The `platformCommand` Field\n\nThe `platformCommand` configures the command that the plugin will execute when\nit is called. You can't set both `platformCommand` & `command` as this will result\nin an error. The following rules will apply in deciding which command to use:\n\n- If `platformCommand` is present, it will be used.\n  - If both `os` and `arch` match the current platform, search will stop and the\n  command will be used.\n  - If `os` matches and `arch` is empty, the command will be used.\n  - If `os` and `arch` are both empty, the command will be used.\n  - If there is no match, Helm will exit with an error.\n- If `platformCommand` is not present and the deprecated `command` is present\nit will be used.\n  - If the command is empty, Helm will exit with an error.\n\n### The `platformHooks` Field\n\nThe `platformHooks` configures the commands that the plugin will execute for lifecycle\nevents. You can't set both `platformHooks` & `hooks` as this will result in an error.\nThe following rules will apply in deciding which hook command to use:\n\n- If `platformHooks` is present, it will be used and the commands for the lifecycle\nevent will be processed.\n  - If both `os` and `arch` match the current platform, search will stop and the\n  command will be used.\n  - If `os` matches and `arch` is empty, the command will be used.\n  - If `os` and `arch` are both empty, the command will be used.\n  - If there is no match, Helm will skip the event.\n- If `platformHooks` is not present and the deprecated `hooks` is present the command\nfor the lifecycle event will be used.\n  - If the command is empty, Helm will skip the event.\n\n## Building a Plugin\n\nHere is the plugin YAML for a simple plugin that helps get the last release name:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nPlugins may require additional scripts and executables.\nScripts can be included in the plugin directory and executables can be downloaded\nvia a hook. The following is an example plugin:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nEnvironment variables are interpolated before the plugin is executed. The\npattern above illustrates the preferred way to indicate where the plugin program\nlives.\n\n### Plugin Commands\n\nThere are some strategies for working with plugin commands:\n\n- If a plugin includes an executable, the executable for a `platformCommand:` or\n  should be packaged in the plugin directory or installed via a hook.\n- The `platformCommand:` or `command:` line will have any environment variables\n  expanded before execution. `$HELM_PLUGIN_DIR` will point to the plugin\n  directory.\n- The command itself is not executed in a shell. So you can't oneline a shell\n  script.\n- Helm injects lots of configuration into environment variables. Take a look at\n  the environment to see what information is available.\n- Helm makes no assumptions about the language of the plugin. You can write it\n  in whatever you prefer.\n- Commands are responsible for implementing specific help text for `-h` and\n  `--help`. Helm will use `usage` and `description` for `helm help` and `helm\n  help myplugin`, but will not handle `helm myplugin --help`.\n\n### Testing a Local Plugin\n\nFirst you need to find your `HELM_PLUGINS` path to do it run the following command:\n\n``` bash\nhelm env\n```\n\nChange your current directory to the director that `HELM_PLUGINS` is set to.\n\nNow you can add a symbolic link to your build output of your plugin in this example\nwe did it for `mapkubeapis`.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Downloader Plugins\n\nBy default, Helm is able to pull Charts using HTTP/S. As of Helm 2.4.0, plugins\ncan have a special capability to download Charts from arbitrary sources.\n\nPlugins shall declare this special capability in the `plugin.yaml` file (top\nlevel):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nIf such plugin is installed, Helm can interact with the repository using the\nspecified protocol scheme by invoking the `command`. The special repository\nshall be added similarly to the regular ones: `helm repo add favorite\nmyprotocol://example.com/` The rules for the special repos are the same to the\nregular ones: Helm must be able to download the `index.yaml` file in order to\ndiscover and cache the list of available Charts.\n\nThe defined command will be invoked with the following scheme: `command certFile\nkeyFile caFile full-URL`. The SSL credentials are coming from the repo\ndefinition, stored in `$HELM_REPOSITORY_CONFIG`\n(i.e., `$HELM_CONFIG_HOME/repositories.yaml`). A Downloader plugin\nis expected to dump the raw content to stdout and report errors on stderr.\n\nThe downloader command also supports sub-commands or arguments, allowing you to\nspecify for example `bin/mydownloader subcommand -d` in the `plugin.yaml`. This\nis useful if you want to use the same executable for the main plugin command and\nthe downloader command, but with a different sub-command for each.\n\n## Environment Variables\n\nWhen Helm executes a plugin, it passes the outer environment to the plugin, and\nalso injects some additional environment variables.\n\nVariables like `KUBECONFIG` are set for the plugin if they are set in the outer\nenvironment.\n\nThe following variables are guaranteed to be set:\n\n- `HELM_PLUGINS`: The path to the plugins directory.\n- `HELM_PLUGIN_NAME`: The name of the plugin, as invoked by `helm`. So `helm\n  myplug` will have the short name `myplug`.\n- `HELM_PLUGIN_DIR`: The directory that contains the plugin.\n- `HELM_BIN`: The path to the `helm` command (as executed by the user).\n- `HELM_DEBUG`: Indicates if the debug flag was set by helm.\n- `HELM_REGISTRY_CONFIG`: The location for the registry configuration (if\n  using). Note that the use of Helm with registries is an experimental feature.\n- `HELM_REPOSITORY_CACHE`: The path to the repository cache files.\n- `HELM_REPOSITORY_CONFIG`: The path to the repository configuration file.\n- `HELM_NAMESPACE`: The namespace given to the `helm` command (generally using\n  the `-n` flag).\n- `HELM_KUBECONTEXT`: The name of the Kubernetes config context given to the\n  `helm` command.\n\nAdditionally, if a Kubernetes configuration file was explicitly specified, it\nwill be set as the `KUBECONFIG` variable\n\n## A Note on Flag Parsing\n\nWhen executing a plugin, Helm will parse global flags for its own use. None of\nthese flags are passed on to the plugin.\n- `--burst-limit`: This is converted to `$HELM_BURST_LIMIT`\n- `--debug`: If this is specified, `$HELM_DEBUG` is set to `1`\n- `--kube-apiserver`: This is converted to `$HELM_KUBEAPISERVER`\n- `--kube-as-group`: These are converted to `$HELM_KUBEASGROUPS`\n- `--kube-as-user`: This is converted to `$HELM_KUBEASUSER`\n- `--kube-ca-file`: This is converted to `$HELM_KUBECAFILE`\n- `--kube-context`: This is converted to `$HELM_KUBECONTEXT`\n- `--kube-insecure-skip-tls-verify`: This is converted to `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`\n- `--kube-tls-server-name`: This is converted to `$HELM_KUBETLS_SERVER_NAME`\n- `--kube-token`: This is converted to `$HELM_KUBETOKEN`\n- `--kubeconfig`: This is converted to `$KUBECONFIG`\n- `--namespace` and `-n`: This is converted to `$HELM_NAMESPACE`\n- `--qps`: This is converted to `$HELM_QPS`\n- `--registry-config`: This is converted to `$HELM_REGISTRY_CONFIG`\n- `--repository-cache`: This is converted to `$HELM_REPOSITORY_CACHE`\n- `--repository-config`: This is converted to `$HELM_REPOSITORY_CONFIG`\n\nPlugins _should_ display help text and then exit for `-h` and `--help`. In all\nother cases, plugins may use flags as appropriate.\n\n## Providing shell auto-completion\n\nAs of Helm 3.2, a plugin can optionally provide support for shell\nauto-completion as part of Helm's existing auto-completion mechanism.\n\n### Static auto-completion\n\nIf a plugin provides its own flags and/or sub-commands, it can inform Helm of\nthem by having a `completion.yaml` file located in the plugin's root directory.\nThe `completion.yaml` file has the form:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nNotes:\n\n1. All sections are optional but should be provided if applicable.\n1. Flags should not include the `-` or `--` prefix.\n1. Both short and long flags can and should be specified. A short flag need not\n   be associated with its corresponding long form, but both forms should be\n   listed.\n1. Flags need not be ordered in any way, but need to be listed at the correct\n   point in the sub-command hierarchy of the file.\n1. Helm's existing global flags are already handled by Helm's auto-completion\n   mechanism, therefore plugins need not specify the following flags `--debug`,\n   `--namespace` or `-n`, `--kube-context`, and `--kubeconfig`, or any other\n   global flag.\n1. The `validArgs` list provides a static list of possible completions for the\n   first parameter following a sub-command.  It is not always possible to\n   provide such a list in advance (see the [Dynamic\n   Completion](#dynamic-completion) section below), in which case the\n   `validArgs` section can be omitted.\n\nThe `completion.yaml` file is entirely optional.  If it is not provided, Helm\nwill simply not provide shell auto-completion for the plugin (unless [Dynamic\nCompletion](#dynamic-completion) is supported by the plugin).  Also, adding a\n`completion.yaml` file is backwards-compatible and will not impact the behavior\nof the plugin when using older helm versions.\n\nAs an example, for the [`fullstatus\nplugin`](https://github.com/marckhouzam/helm-fullstatus) which has no\nsub-commands but accepts the same flags as the `helm status` command, the\n`completion.yaml` file is:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\n### Dynamic completion\n\nAlso starting with Helm 3.2, plugins can provide their own dynamic shell\nauto-completion. Dynamic shell auto-completion is the completion of parameter\nvalues or flag values that cannot be defined in advance.  For example,\ncompletion of the names of helm releases currently available on the cluster.\n\nFor the plugin to support dynamic auto-completion, it must provide an\n**executable** file called `plugin.complete` in its root directory. When the\nHelm completion script requires dynamic completions for the plugin, it will\nexecute the `plugin.complete` file, passing it the command-line that needs to be\ncompleted.  The `plugin.complete` executable will need to have the logic to\ndetermine what the proper completion choices are and output them to standard\noutput to be consumed by the Helm completion script.\n\nThe `plugin.complete` file is entirely optional.  If it is not provided, Helm\nwill simply not provide dynamic auto-completion for the plugin.  Also, adding a\n`plugin.complete` file is backwards-compatible and will not impact the behavior\nof the plugin when using older helm versions.\n\nThe output of the `plugin.complete` script should be a new-line separated list\nsuch as:\n\n```console\nrel1\nrel2\nrel3\n```\n\nWhen `plugin.complete` is called, the plugin environment is set just like when\nthe plugin's main script is called. Therefore, the variables `$HELM_NAMESPACE`,\n`$HELM_KUBECONTEXT`, and all other plugin variables will already be set, and\ntheir corresponding global flags will be removed.\n\nThe `plugin.complete` file can be in any executable form; it can be a shell\nscript, a Go program, or any other type of program that Helm can execute. The\n`plugin.complete` file ***must*** have executable permissions for the user. The\n`plugin.complete` file ***must*** exit with a success code (value 0).\n\nIn some cases, dynamic completion will require to obtain information from the\nKubernetes cluster.  For example, the `helm fullstatus` plugin requires a\nrelease name as input. In the `fullstatus` plugin, for its `plugin.complete`\nscript to provide completion for current release names, it can simply run `helm\nlist -q` and output the result.\n\nIf it is desired to use the same executable for plugin execution and for plugin\ncompletion, the `plugin.complete` script can be made to call the main plugin\nexecutable with some special parameter or flag; when the main plugin executable\ndetects the special parameter or flag, it will know to run the completion. In\nour example, `plugin.complete` could be implemented like this:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nThe `fullstatus` plugin's real script (`status.sh`) must then look for the\n`--complete` flag and if found, printout the proper completions.\n\n### Tips and tricks\n\n1. The shell will automatically filter out completion choices that don't match\n   user input. A plugin can therefore return all relevant completions without\n   removing the ones that don't match the user input.  For example, if the\n   command-line is `helm fullstatus ngin<TAB>`, the `plugin.complete` script can\n   print *all* release names (of the `default` namespace), not just the ones\n   starting with `ngin`; the shell will only retain the ones starting with\n   `ngin`.\n1. To simplify dynamic completion support, especially if you have a complex\n   plugin, you can have your  `plugin.complete` script call your main plugin\n   script and request completion choices.  See the [Dynamic\n   Completion](#dynamic-completion) section above for an example.\n1. To debug dynamic completion and the `plugin.complete` file, one can run the\n   following to see the completion results :\n    - `helm __complete <pluginName> <arguments to complete>`.  For example:\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "docs/topics/provenance.mdx",
    "content": "---\ntitle: Helm Provenance and Integrity\ndescription: Describes how to verify the integrity and origin of a Chart.\nsidebar_position: 5\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm has provenance tools which help chart users verify the integrity and origin\nof a package. Using industry-standard tools based on PKI, GnuPG, and\nwell-respected package managers, Helm can generate and verify signature files.\n\n## Overview\n\nIntegrity is established by comparing a chart to a provenance record. Provenance\nrecords are stored in _provenance files_, which are stored alongside a packaged\nchart. For example, if a chart is named `myapp-1.2.3.tgz`, its provenance file\nwill be `myapp-1.2.3.tgz.prov`.\n\nProvenance files are generated at packaging time (`helm package --sign ...`),\nand can be checked by multiple commands, notably `helm install --verify`.\n\n## The Workflow\n\nThis section describes a potential workflow for using provenance data\neffectively.\n\nPrerequisites:\n\n- A valid PGP keypair in a binary (not ASCII-armored) format\n- The `helm` command line tool\n- GnuPG command line tools (optional)\n- Keybase command line tools (optional)\n\n**NOTE:** If your PGP private key has a passphrase, you will be prompted to\nenter that passphrase for any commands that support the `--sign` option.\n\nCreating a new chart is the same as before:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nOnce ready to package, add the `--sign` flag to `helm package`. Also, specify\nthe name under which the signing key is known and the keyring containing the\ncorresponding private key:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**Note:** The value of the `--key` argument must be a substring of the desired\nkey's `uid` (in the output of `gpg --list-keys`), for example the name or email.\n**The fingerprint _cannot_ be used.**\n\n**TIP:** for GnuPG users, your secret keyring is in `~/.gnupg/secring.gpg`. You\ncan use `gpg --list-secret-keys` to list the keys you have.\n\n**Warning:**  the GnuPG v2 store your secret keyring using a new format `kbx` on\nthe default location  `~/.gnupg/pubring.kbx`. Please use the following command\nto convert your keyring to the legacy gpg format:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nAt this point, you should see both `mychart-0.1.0.tgz` and\n`mychart-0.1.0.tgz.prov`. Both files should eventually be uploaded to your\ndesired chart repository.\n\nYou can verify a chart using `helm verify`:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nA failed verification looks like this:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nTo verify during an install, use the `--verify` flag.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nIf the keyring containing the public key associated with the signed chart is not\nin the default location, you may need to point to the keyring with `--keyring\nPATH` as in the `helm package` example.\n\nIf verification fails, the install will be aborted before the chart is even\nrendered.\n\n### Using Keybase.io credentials\n\nThe [Keybase.io](https://keybase.io) service makes it easy to establish a chain\nof trust for a cryptographic identity. Keybase credentials can be used to sign\ncharts.\n\nPrerequisites:\n\n- A configured Keybase.io account\n- GnuPG installed locally\n- The `keybase` CLI installed locally\n\n#### Signing packages\n\nThe first step is to import your keybase keys into your local GnuPG keyring:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nThis will convert your Keybase key into the OpenPGP format, and then import it\nlocally into your `~/.gnupg/secring.gpg` file.\n\nYou can double check by running `gpg --list-secret-keys`.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nNote that your secret key will have an identifier string:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nThat is the full name of your key.\n\nNext, you can package and sign a chart with `helm package`. Make sure you use at\nleast part of that name string in `--key`.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nAs a result, the `package` command should produce both a `.tgz` file and a\n`.tgz.prov` file.\n\n#### Verifying packages\n\nYou can also use a similar technique to verify a chart signed by someone else's\nKeybase key. Say you want to verify a package signed by\n`keybase.io/technosophos`. To do this, use the `keybase` tool:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nThe first command above tracks the user `technosophos`. Next `keybase pgp pull`\ndownloads the OpenPGP keys of all of the accounts you follow, placing them in\nyour GnuPG keyring (`~/.gnupg/pubring.gpg`).\n\nAt this point, you can now use `helm verify` or any of the commands with a\n`--verify` flag:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Reasons a chart may not verify\n\nThese are common reasons for failure.\n\n- The `.prov` file is missing or corrupt. This indicates that something is\n  misconfigured or that the original maintainer did not create a provenance\n  file.\n- The key used to sign the file is not in your keyring. This indicate that the\n  entity who signed the chart is not someone you've already signaled that you\n  trust.\n- The verification of the `.prov` file failed. This indicates that something is\n  wrong with either the chart or the provenance data.\n- The file hashes in the provenance file do not match the hash of the archive\n  file. This indicates that the archive has been tampered with.\n\nIf a verification fails, there is reason to distrust the package.\n\n## The Provenance File\n\nThe provenance file contains a chart’s YAML file plus several pieces of\nverification information. Provenance files are designed to be automatically\ngenerated.\n\nThe following pieces of provenance data are added:\n\n* The chart file (`Chart.yaml`) is included to give both humans and tools an\n  easy view into the contents of the chart.\n* The signature (SHA256, just like Docker) of the chart package (the `.tgz`\n  file) is included, and may be used to verify the integrity of the chart\n  package.\n* The entire body is signed using the algorithm used by OpenPGP (see\n  [Keybase.io](https://keybase.io) for an emerging way of making crypto\n  signing and verification easy).\n\nThe combination of this gives users the following assurances:\n\n* The package itself has not been tampered with (checksum package `.tgz`).\n* The entity who released this package is known (via the GnuPG/PGP signature).\n\nThe format of the file looks something like this:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nNote that the YAML section contains two documents (separated by `...\\n`). The\nfirst file is the content of `Chart.yaml`. The second is the checksums, a map of\nfilenames to SHA-256 digests of that file's content at packaging time.\n\nThe signature block is a standard PGP signature, which provides [tamper\nresistance](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Chart Repositories\n\nChart repositories serve as a centralized collection of Helm charts.\n\nChart repositories must make it possible to serve provenance files over HTTP via\na specific request, and must make them available at the same URI path as the\nchart.\n\nFor example, if the base URL for a package is\n`https://example.com/charts/mychart-1.2.3.tgz`, the provenance file, if it\nexists, MUST be accessible at\n`https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nFrom the end user's perspective, `helm install --verify myrepo/mychart-1.2.3`\nshould result in the download of both the chart and the provenance file with no\nadditional user configuration or action.\n\n### Signatures in OCI-based registries\n\nWhen publishing charts to an [OCI-based registry](/topics/registries.mdx), the\n[`helm-sigstore` plugin](https://github.com/sigstore/helm-sigstore/) can be used \nto publish provenance to [sigstore](https://sigstore.dev/).  [As described in the\ndocumentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), the\nprocess of creating provenance and signing with a GPG key are common, but the\n`helm sigstore upload` command can be used to publish the provenance to an\nimmutable transparency log.\n\n## Establishing Authority and Authenticity\n\nWhen dealing with chain-of-trust systems, it is important to be able to\nestablish the authority of a signer. Or, to put this plainly, the system above\nhinges on the fact that you trust the person who signed the chart. That, in\nturn, means you need to trust the public key of the signer.\n\nOne of the design decisions with Helm has been that the Helm project would not\ninsert itself into the chain of trust as a necessary party. We don't want to be\n\"the certificate authority\" for all chart signers. Instead, we strongly favor a\ndecentralized model, which is part of the reason we chose OpenPGP as our\nfoundational technology. So when it comes to establishing authority, we have\nleft this step more-or-less undefined in Helm 2 (a decision carried forward in\nHelm 3).\n\nHowever, we have some pointers and recommendations for those interested in using\nthe provenance system:\n\n- The [Keybase](https://keybase.io) platform provides a public centralized\n  repository for trust information.\n  - You can use Keybase to store your keys or to get the public keys of others.\n  - Keybase also has fabulous documentation available\n  - While we haven't tested it, Keybase's \"secure website\" feature could be used\n    to serve Helm charts.\n  - The basic idea is that an official \"chart reviewer\" signs charts with her or\n    his key, and the resulting provenance file is then uploaded to the chart\n    repository.\n  - There has been some work on the idea that a list of valid signing keys may\n    be included in the `index.yaml` file of a repository.\n\n"
  },
  {
    "path": "docs/topics/rbac.md",
    "content": "---\ntitle: Role-based Access Control\ndescription: Explains how Helm interacts with Kubernetes' Role-Based Access Control.\nsidebar_position: 11\n---\n\nIn Kubernetes, granting roles to a user or an application-specific service\naccount is a best practice to ensure that your application is operating in the\nscope that you have specified. Read more about service account permissions [in\nthe official Kubernetes\ndocs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nFrom Kubernetes 1.6 onwards, Role-based Access Control is enabled by default.\nRBAC allows you to specify which types of actions are permitted depending on the\nuser and their role in your organization.\n\nWith RBAC, you can\n\n- grant privileged operations (creating cluster-wide resources, like new roles)\n  to administrators\n- limit a user's ability to create resources (pods, persistent volumes,\n  deployments) to specific namespaces, or in cluster-wide scopes (resource\n  quotas, roles, custom resource definitions)\n- limit a user's ability to view resources either in specific namespaces or at a\n  cluster-wide scope.\n\nThis guide is for administrators who want to restrict the scope of a user's\ninteraction with the Kubernetes API.\n\n## Managing user accounts\n\nAll Kubernetes clusters have two categories of users: service accounts managed\nby Kubernetes, and normal users.\n\nNormal users are assumed to be managed by an outside, independent service. An\nadministrator distributing private keys, a user store like Keystone or Google\nAccounts, even a file with a list of usernames and passwords. In this regard,\nKubernetes does not have objects which represent normal user accounts. Normal\nusers cannot be added to a cluster through an API call.\n\nIn contrast, service accounts are users managed by the Kubernetes API. They are\nbound to specific namespaces, and created automatically by the API server or\nmanually through API calls. Service accounts are tied to a set of credentials\nstored as Secrets, which are mounted into pods allowing in-cluster processes to\ntalk to the Kubernetes API.\n\nAPI requests are tied to either a normal user or a service account, or are\ntreated as anonymous requests. This means every process inside or outside the\ncluster, from a human user typing `kubectl` on a workstation, to kubelets on\nnodes, to members of the control plane, must authenticate when making requests\nto the API server, or be treated as an anonymous user.\n\n## Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings\n\nIn Kubernetes, user accounts and service accounts can only view and edit\nresources they have been granted access to. This access is granted through the\nuse of Roles and RoleBindings. Roles and RoleBindings are bound to a particular\nnamespace, which grant users the ability to view and/or edit resources within\nthat namespace the Role provides them access to.\n\nAt a cluster scope, these are called ClusterRoles and ClusterRoleBindings.\nGranting a user a ClusterRole grants them access to view and/or edit resources\nacross the entire cluster. It is also required to view and/or edit resources at\nthe cluster scope (namespaces, resource quotas, nodes).\n\nClusterRoles can be bound to a particular namespace through reference in a\nRoleBinding. The `admin`, `edit` and `view` default ClusterRoles are commonly\nused in this manner.\n\nThese are a few ClusterRoles available by default in Kubernetes. They are\nintended to be user-facing roles. They include super-user roles\n(`cluster-admin`), and roles with more granular access (`admin`, `edit`,\n`view`).\n\n| Default ClusterRole | Default ClusterRoleBinding | Description\n|---------------------|----------------------------|-------------\n| `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.\n| `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.\n| `edit`              | None                       | Allows read/write access to most objects in a namespace. It does not allow viewing or modifying roles or rolebindings.\n| `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.\n\n## Restricting a user account's access using RBAC\n\nNow that we understand the basics of Role-based Access Control, let's discuss\nhow an administrator can restrict a user's scope of access.\n\n### Example: Grant a user read/write access to a particular namespace\n\nTo restrict a user's access to a particular namespace, we can use either the\n`edit` or the `admin` role. If your charts create or interact with Roles and\nRolebindings, you'll want to use the `admin` ClusterRole.\n\nAdditionally, you may also create a RoleBinding with `cluster-admin` access.\nGranting a user `cluster-admin` access at the namespace scope provides full\ncontrol over every resource in the namespace, including the namespace itself.\n\nFor this example, we will create a user with the `edit` Role. First, create the\nnamespace:\n\n```console\n$ kubectl create namespace foo\n```\n\nNow, create a RoleBinding in that namespace, granting the user the `edit` role.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Example: Grant a user read/write access at the cluster scope\n\nIf a user wishes to install a chart that installs cluster-scope resources\n(namespaces, roles, custom resource definitions, etc.), they will require\ncluster-scope write access.\n\nTo do that, grant the user either `admin` or `cluster-admin` access.\n\nGranting a user `cluster-admin` access grants them access to absolutely every\nresource available in Kubernetes, including node access with `kubectl drain` and\nother administrative tasks. It is highly recommended to consider providing the\nuser `admin` access instead, or to create a custom ClusterRole tailored to their\nneeds.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Example: Grant a user read-only access to a particular namespace\n\nYou might've noticed that there is no ClusterRole available for viewing secrets.\nThe `view` ClusterRole does not grant a user read access to Secrets due to\nescalation concerns. Helm stores release metadata as Secrets by default.\n\nIn order for a user to run `helm list`, they need to be able to read these\nsecrets. For that, we will create a special `secret-reader` ClusterRole.\n\nCreate the file `cluster-role-secret-reader.yaml` and write the following\ncontent into the file:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nThen, create the ClusterRole using\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nOnce that's done, we can grant a user read access to most resources, and then\ngrant them read access to secrets:\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Example: Grant a user read-only access at the cluster scope\n\nIn certain scenarios, it may be beneficial to grant a user cluster-scope access.\nFor example, if a user wants to run the command `helm list --all-namespaces`,\nthe API requires the user has cluster-scope read access.\n\nTo do that, grant the user both `view` and `secret-reader` access as described\nabove, but with a ClusterRoleBinding.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Additional Thoughts\n\nThe examples shown above utilize the default ClusterRoles provided with\nKubernetes. For more fine-grained control over what resources users are granted\naccess to, have a look at [the Kubernetes\ndocumentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) on\ncreating your own custom Roles and ClusterRoles.\n"
  },
  {
    "path": "docs/topics/registries.mdx",
    "content": "---\ntitle: Use OCI-based registries\ndescription: Describes how to use OCI for Chart distribution.\nsidebar_position: 7\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nIt is recommended to use container registries with [OCI](https://www.opencontainers.org/) support to store and share chart packages.\n\n## Using an OCI-based registry\n\n### Helm repositories in OCI-based registries\n\nA [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.\n\n### Use hosted registries\n\nThere are several hosted container registries with OCI support that you can use for your Helm charts. For example:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\nFollow the hosted container registry provider's documentation to create and configure a registry with OCI support. \n\n**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.\n\n### Using sigstore to sign OCI-based charts\n\nThe [`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).\n\nFor more details on using the `helm sigstore` plugin, see [that project's documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md).\n\n## Commands for working with registries\n\n### The `registry` subcommand\n\n#### `login`\n\nlogin to a registry (with manual password entry)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\nThe host must be only the registry hostname, optionally with a port. Do not include a URL scheme or path:\n\n| Example | Valid |\n|---------|-------|\n| `ghcr.io` | Yes |\n| `localhost:5000` | Yes |\n| `https://ghcr.io` | No - scheme not allowed |\n| `ghcr.io/myrepo` | No - path not allowed |\n\n#### `logout`\n\nlogout from a registry\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### The `push` subcommand\n\nUpload a chart to an OCI-based registry:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nThe `push` subcommand can only be used against `.tgz` files\ncreated ahead of time using `helm package`.\n\nWhen using `helm push` to upload a chart an OCI registry, the reference\nmust be prefixed with `oci://` and must not contain the basename or tag.\n\nThe registry reference basename is inferred from the chart's name,\nand the tag is inferred from the chart's semantic version. This is\ncurrently a strict requirement.\n\nCertain registries require the repository and/or namespace (if specified)\nto be created beforehand. Otherwise, an error will be produced during the\n `helm push` operation.\n\nIf you have created a [provenance file](/topics/provenance.mdx) (`.prov`), and it is present next to the chart `.tgz` file, it will\nautomatically be uploaded to the registry upon `push`. This results in\nan extra layer on [the Helm chart manifest](#helm-chart-manifest).\n\nUsers of the [helm-push plugin](https://github.com/chartmuseum/helm-push) (for uploading charts to [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server))\nmay experience issues, since the plugin conflicts with the new, built-in `push`.\nAs of version v0.10.0, the plugin has been renamed to `cm-push`.\n\n### Other subcommands\n\nSupport for the `oci://` protocol is also available in various other subcommands.\nHere is a complete list:\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nThe basename (chart name) of the registry reference *is*\nincluded for any type of action involving chart download\n(vs. `helm push` where it is omitted).\n\nHere are a few examples of using the subcommands listed above against\nOCI-based charts:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Installing charts with digest\n\nInstalling a chart with a digest is more secure than a tag because digests are immutable.\nThe digest is specified in the chart URI:\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## Specifying dependencies\n\nDependencies of a chart can be pulled from a registry using the `dependency update` subcommand.\n\nThe `repository` for a given entry in `Chart.yaml` is specified as the registry reference without the basename:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\nThis will fetch `oci://localhost:5000/myrepo/mychart:2.7.0` when `dependency update` is executed.\n\n## Helm chart manifest\n\nExample Helm chart manifest as represented in a registry\n(note the `mediaType` fields):\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nThe following example contains a\n[provenance file](/topics/provenance.mdx)\n(note the extra layer):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Migrating from chart repos\n\nMigrating from classic [chart repositories](/topics/chart_repository.md)\n(index.yaml-based repos) is as simple using `helm pull`, then using `helm push` to upload the resulting `.tgz` files to a registry.\n\n"
  },
  {
    "path": "docs/topics/version_skew.mdx",
    "content": "---\ntitle: \"Helm Version Support Policy\"\ndescription: \"Describes Helm's patch release policy as well as the maximum version skew supported between Helm and Kubernetes.\"\n---\n\nThis document describes the maximum version skew supported between Helm 4 and\nKubernetes.\n\n## Supported Versions\n\nHelm versions are expressed as `x.y.z`, where `x` is the major version, `y` is\nthe minor version, and `z` is the patch version, following [Semantic\nVersioning](https://semver.org/spec/v2.0.0.html) terminology.\n\nThe Helm project maintains a release branch for the most recent minor release.\nApplicable fixes, including security fixes, are cherry-picked into the release\nbranch, depending on severity and feasibility. More details can be found in\n[Helm's release policy](/community/release_policy).\n\n## Supported Version Skew\n\nWhen a new version of Helm is released, it is compiled against a particular\nminor version of Kubernetes. For example, Helm v4.0.0 interacts with Kubernetes\nusing the Kubernetes 1.34.1 client, so it is compatible with Kubernetes 1.34.\n\nAs of Helm 4, Helm is assumed to be compatible with `n-3` versions of Kubernetes\nit was compiled against.\n\nFor example, if you are using a version of Helm 4 that was compiled against the\nKubernetes v1.35 client APIs, then it should be safe to use with Kubernetes v1.35,\nv1.34, v1.33, and v1.32.\n\nIt is not recommended to use Helm with a version of Kubernetes that is newer\nthan the version it was compiled against, as Helm does not make any forward\ncompatibility guarantees.\n\nIf you choose to use Helm with a version of Kubernetes that it does not support,\nyou are using it at your own risk.\n\nPlease refer to the table below to determine what version of Helm is compatible\nwith your cluster.\n\n| Helm Version | Supported Kubernetes Versions |\n|--------------|-------------------------------|\n| 4.1.x        | 1.35.x - 1.32.x               |\n| 4.0.x        | 1.34.x - 1.31.x               |\n"
  },
  {
    "path": "docusaurus.config.js",
    "content": "// @ts-check\n// `@type` JSDoc annotations allow editor autocompletion and type checking\n// (when paired with `@ts-check`).\n// There are various equivalent ways to declare your Docusaurus config.\n// See: https://docusaurus.io/docs/api/docusaurus-config\nimport { themes as prismThemes } from \"prism-react-renderer\";\n\n// This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)\nconst siteURL = process.env.SITE_URL || \"http://localhost:3000\";\nconst rawBaseUrl = process.env.BASE_URL;\nconst normalizedBaseUrl =\n  rawBaseUrl === undefined\n    ? \"/\"\n    : rawBaseUrl.endsWith(\"/\")\n    ? rawBaseUrl\n    : rawBaseUrl + \"/\";\n\n// Community documentation configuration\nconst communityConfig = require(\"./remote-content_community\");\nconst {\n  processConfig,\n  createEditUrlFunction,\n} = require(\"./src/utils/communityDocsHelpers\");\nconst {\n  transformImportedContent,\n} = require(\"./src/utils/communityDocsTransforms\");\n\n// Process the community docs configuration\nconst {\n  documents: remoteDocPaths,\n  metaByPath,\n  slugByPath,\n  linkExceptions,\n} = processConfig(communityConfig);\n\n/** @type {import('@docusaurus/types').Config} */\nconst config = {\n  title: \"Helm\",\n  tagline: \"The package manager for Kubernetes\",\n  favicon: \"img/favicon.ico\",\n\n  // Future flags, see https://docusaurus.io/docs/api/docusaurus-config#future\n  future: {\n    v4: true, // Improve compatibility with the upcoming Docusaurus v4\n  },\n\n  // Opt-in to less strict, standard CommonMark support with options\n  // Automatically detects .md and .mdx extensions\n  // See https://docusaurus.io/docs/markdown-features/react#markdown-and-jsx-interoperability\n  // See https://github.com/prettier/prettier/issues/17089\n  markdown: {\n    format: \"detect\",\n  },\n\n  // Set the production url of your site here\n  url: siteURL,\n  // Set the /<baseUrl>/ pathname under which your site is served\n  // For GitHub pages deployment, it is often '/<projectName>/'\n  baseUrl: normalizedBaseUrl,\n\n  // GitHub pages deployment config.\n  // If you aren't using GitHub pages, you don't need these.\n  organizationName: \"helm\", // Usually your GitHub org/user name.\n  projectName: \"helm-www\", // Usually your repo name.\n\n  onBrokenLinks: \"throw\",\n\n  i18n: {\n    defaultLocale: \"en\",\n    locales: [\"en\", \"de\", \"el\", \"es\", \"fr\", \"it\", \"ja\", \"ko\", \"pt\", \"ru\", \"uk\", \"zh\"],\n    localeConfigs: {\n      en: {\n        htmlLang: \"en-us\",\n        label: \"English\",\n      },\n      de: {\n        label: \"Deutsch (German)\",\n      },\n      es: {\n        label: \"Español (Spanish)\",\n      },\n      fr: {\n        label: \"Français (French)\",\n      },\n      it: {\n        label: \"Italiano (Italian)\",\n      },\n      el: {\n        label: \"Ελληνικά (Greek)\",\n      },\n      ja: {\n        label: \"日本語 (Japanese)\",\n      },\n      ko: {\n        label: \"한국어 (Korean)\",\n      },\n      pt: {\n        label: \"Português (Portuguese)\",\n      },\n      ru: {\n        label: \"Русский (Russian)\",\n      },\n      uk: {\n        label: \"Українська (Ukrainian)\",\n      },\n      zh: {\n        label: \"中文 (Chinese)\",\n      },\n    },\n  },\n\n  presets: [\n    [\n      \"classic\",\n      /** @type {import('@docusaurus/preset-classic').Options} */\n      ({\n        docs: {\n          sidebarPath: \"./sidebars.js\",\n          // Please change this to your repo.\n          // Remove this to remove the \"edit this page\" links.\n          editUrl: \"https://github.com/helm/helm-www/blob/main/\",\n          // Links \"edit this page\" on translated pages to i18n/[LOCALE]/... instead of English source file\n          editLocalizedFiles: true,\n          // \"lastVersion\" means the latest release\n          lastVersion: \"current\",\n          versions: {\n            // v4 is \"current\"\n            // v3 is in /versioned_docs/version-3\n            // v2 is in /versioned_docs/version-2\n            // TODO when we start work on Helm v5, we will copy /docs to /versioned_docs/version-4\n            // and v5 will then live in /docs\n            // Be sure to update each locale's docusaurus-plugin-content-docs/current.json to match the current label\n            // To-do: add this snippet to automation for bumping the version for each new release:\n            // `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`\n            current: { label: \"4.1.1\" },\n            3: { label: \"3.20.0\", path: \"v3\" },\n            2: { label: \"2.17.0\", path: \"v2\" },\n          },\n        },\n        blog: {\n          showReadingTime: true,\n          blogSidebarTitle: \"All posts\",\n          blogSidebarCount: \"ALL\",\n          feedOptions: {\n            type: [\"rss\", \"atom\"],\n            xslt: true,\n          },\n          // Please change this to your repo.\n          // Remove this to remove the \"edit this page\" links.\n          editUrl: \"https://github.com/helm/helm-www/blob/main/\",\n          // Useful options to enforce blogging best practices\n          onInlineTags: \"warn\",\n          onInlineAuthors: \"warn\",\n          onUntruncatedBlogPosts: \"throw\",\n        },\n        theme: {\n          customCss: \"./src/css/custom.css\",\n        },\n      }),\n    ],\n  ],\n\n  // Note @docusaurus/preset-classic already includes a docs plugin instance for us under \"presets\"\n  // See https://docusaurus.io/docs/docs-multi-instance#versioned-and-unversioned-doc\n  plugins: [\n    [\n      \"@docusaurus/plugin-content-docs\",\n      {\n        id: \"community\",\n        path: \"community\",\n        routeBasePath: \"community\",\n        sidebarPath: \"./sidebars_community.js\",\n        editLocalizedFiles: true,\n        editUrl: createEditUrlFunction(communityConfig.sourceRepo),\n        numberPrefixParser: false,\n      },\n    ],\n    [\n      \"docusaurus-plugin-remote-content\",\n      {\n        name: \"community\",\n        sourceBaseUrl: communityConfig.sourceBaseUrl,\n        outDir: \"community\",\n        documents: remoteDocPaths,\n        // Set to true since we commit files to Git and performCleanup: false prevents deletion\n        noRuntimeDownloads: true,\n        // Must be false to prevent files being deleted between i18n locale builds\n        // See: https://github.com/rdilweb/docusaurus-plugin-remote-content/issues/98\n        performCleanup: false,\n        /**\n         * @param {string} filename - The filename being processed\n         * @param {string} content - The file content\n         * @returns {{content: string, filename?: string}} Transformed content\n         */\n        modifyContent(filename, content) {\n          const transformed = transformImportedContent(\n            filename,\n            content,\n            metaByPath,\n            slugByPath,\n            linkExceptions\n          );\n\n          // transformImportedContent now returns an object with content and optionally filename\n          return transformed;\n        },\n      },\n    ],\n    [\n      \"docusaurus-plugin-remote-content\",\n      {\n        name: \"community-images\",\n        sourceBaseUrl: communityConfig.sourceBaseUrl,\n        outDir: \"community\",\n        documents: [\n          \"art/images/Backgrounds-Pattern-Dark.png\",\n          \"art/images/Backgrounds-Pattern.png\",\n          \"art/images/Example-Icon-Illustrations.png\",\n          \"art/images/Helm-3-Color-Palettes-Dark.png\",\n          \"art/images/Helm-3-Color-Palettes-Light.png\",\n          \"art/images/Helm-Summit.png\",\n          \"art/images/Logo-Tweak-Dark.png\",\n          \"art/images/Logo-Tweak-Light.png\",\n          \"art/images/Typography.png\",\n          \"art/images/Website-Exmple.png\",\n          \"art/images/Website-Sample.png\",\n          \"art/images/helm-3.png\",\n          \"art/images/type-notes.png\",\n        ],\n        requestConfig: { responseType: \"arraybuffer\" },\n        noRuntimeDownloads: true,\n        performCleanup: false,\n      },\n    ],\n  ],\n\n  themeConfig:\n    /** @type {import('@docusaurus/preset-classic').ThemeConfig} */\n    ({\n      algolia: {\n        appId: \"AYED2EXU9K\",\n        apiKey: \"ab452074863b15ae08d14d22d393f1e0\",\n        indexName: \"production\",\n      },\n      announcementBar: {\n        backgroundColor: \"#0f1689\",\n        textColor: \"#ffffff\",\n        // Note that closed state is stored in browser\n        // Change id to show again for users who have already closed it\n        id: \"helm4_ga\",\n        content:\n          '🎉 Helm v4.0.0 is out! See the <a href=\"/docs/overview\">Helm 4 Overview</a> for details!',\n        isCloseable: true,\n      },\n      // Replace with your project's social card\n      image: \"img/helm-social-card.png\",\n      colorMode: {\n        defaultMode: \"light\",\n        disableSwitch: true,\n      },\n      docs: {\n        sidebar: {\n          hideable: true,\n          autoCollapseCategories: true,\n        },\n      },\n      navbar: {\n        title: \"Helm\",\n        logo: {\n          alt: \"Helm Logo\",\n          src: \"img/helm.svg\",\n        },\n        items: [\n          { to: \"docs\", label: \"Docs\", position: \"left\" },\n          { to: \"community\", label: \"Community\", position: \"left\" },\n          { to: \"blog\", label: \"Blog\", position: \"left\" },\n          {\n            href: \"https://artifacthub.io/\",\n            label: \"Charts\",\n            position: \"left\",\n          },\n          {\n            type: \"docsVersionDropdown\",\n            position: \"right\",\n          },\n          {\n            type: \"localeDropdown\",\n            position: \"right\",\n          },\n        ],\n      },\n      footer: {\n        style: \"dark\",\n        links: [\n          {\n            title: \"Helm Project\",\n            items: [\n              {\n                label: \"Source code\",\n                href: \"https://github.com/helm/helm\",\n              },\n              {\n                label: \"Blog\",\n                to: \"blog\",\n              },\n              {\n                label: \"Events\",\n                href: \"https://www.cncf.io/community/kubecon-cloudnativecon-events/\",\n              },\n              {\n                label: \"Code of Conduct\",\n                href: \"https://github.com/cncf/foundation/blob/master/code-of-conduct.md\",\n              },\n            ],\n          },\n          {\n            title: \"Charts\",\n            items: [\n              {\n                label: \"Introduction\",\n                to: \"docs/intro\",\n              },\n              {\n                label: \"Chart tips & tricks\",\n                to: \"docs/howto/charts_tips_and_tricks\",\n              },\n              {\n                label: \"Developing Charts\",\n                to: \"docs/topics/charts\",\n              },\n              {\n                label: \"Search 800+ Charts\",\n                href: \"https://artifacthub.io/\",\n              },\n            ],\n          },\n          {\n            title: \"Development\",\n            items: [\n              {\n                label: \"Slack (#helm-dev)\",\n                href: \"https://kubernetes.slack.com/messages/C51E88VDG\",\n              },\n              {\n                label: \"Contribution Guide\",\n                href: \"https://github.com/helm/helm/blob/main/CONTRIBUTING.md\",\n              },\n              {\n                label: \"Maintainers\",\n                href: \"https://github.com/helm/helm/blob/main/OWNERS\",\n              },\n              {\n                label: \"Weekly Meetings\",\n                href: \"https://github.com/helm/community/blob/main/communication.md#meetings\",\n              },\n            ],\n          },\n          {\n            title: \"Community\",\n            items: [\n              {\n                label: \"GitHub Community\",\n                href: \"https://github.com/helm/community\",\n              },\n              {\n                label: \"Slack (#helm-users)\",\n                href: \"https://kubernetes.slack.com/\",\n              },\n              {\n                label: \"Stack Overflow\",\n                href: \"https://stackoverflow.com/questions/tagged/kubernetes-helm\",\n              },\n              {\n                label: \"X\",\n                href: \"https://x.com/helmpack\",\n              },\n            ],\n          },\n        ],\n        logo: {\n          alt: \"CNCF Logo\",\n          src: \"/img/cncf-white.png\",\n        },\n        copyright: `<p>We are a <a href=\"https://www.cncf.io/\">Cloud Native Computing Foundation</a> graduated project.</p><p>© Helm Authors ${new Date().getFullYear()}. Documentation distributed under <a href=\"https://creativecommons.org/licenses/by/4.0\">CC-BY-4.0.</a></p><p>© ${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 <a href=\"https://www.linuxfoundation.org/trademark-usage/\">Trademark Usage page</a>.</p>`,\n      },\n      prism: {\n        theme: prismThemes.github,\n        darkTheme: prismThemes.dracula,\n        additionalLanguages: [\"bash\"],\n      },\n    }),\n\n  clientModules: [\n    require.resolve(\"./src/client-modules/heroHeightCalculator.js\"),\n  ],\n};\n\nexport default config;\n"
  },
  {
    "path": "i18n/de/code.json",
    "content": "{\n  \"home.about.whatIsHelm\": {\n    \"message\": \"Helm hilft Ihnen, Kubernetes-Anwendungen zu verwalten — Helm Charts helfen Ihnen, selbst die komplexesten Kubernetes-Anwendungen zu definieren, zu installieren und zu aktualisieren.\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"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.\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Helm ist ein promoviertes Projekt in der {cncfLink} und wird von der {helmCommunityLink} gepflegt.\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"Helm Gemeinschaft\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"Mehr lernen:\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Helm-Architektur\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"Schnellstartanleitung\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"Video: Eine Einführung in Helm\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"Was ist Helm?\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"Nächste Version\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"Version:\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"Datum:\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"Veröffentlichungskalender\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"Kommende Veranstaltungen\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"Kommende Veranstaltungen\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"Vergangene Veranstaltungen\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"{meetLink}, um Tools und Projekte zu demonstrieren und zu diskutieren. Community-Treffen werden aufgezeichnet und {youtubeLink}.\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"Sie treffen sich jede Woche\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"auf YouTube geteilt\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"Entwickler-Standups\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"Donnerstags 9:30-10 Uhr (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"Diese Treffen sind für alle offen. Schauen Sie im {communityRepoLink} für Notizen und Details nach.\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"Community-Repository\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Diskussion über die Verwendung von Helm, die Arbeit mit Charts und das Lösen häufiger Fehler.\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Themen zur Helm-Entwicklung, laufende PRs, Releases usw.\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Diskussion für Benutzer und Mitwirkende von Helm Charts.\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"{slackLink}, um dem Kubernetes Slack-Team beizutreten.\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"Hier Zugang anfordern\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"Beitragen\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"Helm begrüßt immer neue Beiträge zum Projekt!\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"Wo anfangen?\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Helm ist ein großes Projekt mit vielen Benutzern und Mitwirkenden. Es kann viel zu verarbeiten sein!\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"Wir haben eine Liste von {goodFirstIssuesLink}, wenn Sie helfen möchten, aber nicht wissen, wo Sie anfangen sollen.\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"guten ersten Issues\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"Was soll ich tun?\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"Bevor Sie Code beisteuern, lesen Sie bitte unseren {contributionGuideLink}. Er behandelt die Prozesse rund um das Erstellen und Überprüfen von Pull Requests.\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"Beitragsleitfaden\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"Nachdem Sie Code geschrieben haben, {signYourCommitsLink} bitte, um sicherzustellen, dass Helm die von der {cncfLink} verwendete {dcoLink}-Vereinbarung einhält.\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"signieren Sie Ihre Commits\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"Der Gemeinschaft beitreten\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Weitere Informationen über das Helm-Projekt und wie Sie beitragen können.\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"Erste Schritte\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"Helm bekommen\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"Installieren Sie Helm mit einem Paketmanager oder {downloadLink}.\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"laden Sie eine Binärdatei herunter\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"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}.\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"Dokumentation\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"Installationsanweisungen\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"Nutzungsanweisungen\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"Charts beziehen\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"Besuchen Sie {artifactHubLink}, um {helmChartsLink} aus zahlreichen öffentlichen Repositories zu erkunden.\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"Helm Charts\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"Der Paket Manager für Kubernetes\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Helm ist der beste Weg, um Software zu finden, zu teilen und zu verwenden, die für\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"Komplexität verwalten\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"message\": \"Charts beschreiben selbst die komplexesten Apps, ermöglichen wiederholbare Anwendungsinstallationen und dienen als zentrale Autorität.\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"Einfache Aktualisierungen\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"Nehmen Sie den Schmerz aus Updates mit direkten Upgrades und benutzerdefinierten Hooks.\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"Einfaches Teilen\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"Charts sind einfach zu versionieren, zu teilen und auf öffentlichen oder privaten Servern zu hosten.\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"Zurückrollen\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"Verwenden Sie {helmRollback}, um einfach zu einer älteren Version eines Release zurückzukehren.\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"Funktionen\",\n    \"description\": \"Features section title\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"Die Seite ist abgestürzt.\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"Zurück nach oben scrollen\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"Archiv\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"Archiv\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"Navigation der Blog-Listenseite\",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"Neuere Einträge\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"Ältere Einträge\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"Blog Post Seiten Navigation\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"Neuer Post\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"Älterer Post\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"Alle Tags anzeigen\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"Systemmodus\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"heller Modus\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"dunkler Modus\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"Umschalten zwischen dunkler und heller Ansicht (momentan {mode})\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"Breadcrumbs\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"1 Eintrag|{count} Einträge\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"Dokumentation Seiten\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"Zurück\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"Weiter\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"Ein doc getaggt|{count} docs getaggt\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged} mit \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"Das ist die unveröffentlichte Dokumentation für {siteTitle} {versionLabel}.\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"Das ist die Dokumentation für {siteTitle} {versionLabel} und wird nicht weiter gewartet.\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"Für die aktuellste Dokumentation bitte auf {latestVersionLink} ({versionLabel}) gehen.\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"letzte Version\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"Version: {versionLabel}\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"Diese Seite bearbeiten\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"Direkter Link zur {heading}\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \" am {date}\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \" von {user}\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"Letztes Update{atDate}{byUser}\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"Versionen\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"Seite nicht gefunden\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"Tags:\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"Schließen\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"vorsicht\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"gefahr\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"info\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"hinweis\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"tipp\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"warnung\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"Navigation der letzten Beiträge im Blog\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"Seitenleisten-Kategorie '{label}' erweitern\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"Seitenleisten-Kategorie '{label}' einklappen\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(öffnet in neuem Tab)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"Haupt\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"Sprachen\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"Wir konnten nicht finden, wonach Sie gesucht haben.\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"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.\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"Auf dieser Seite\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"Mehr lesen\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"Mehr lesen über {title}\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"Eine Minute Lesezeit|{readingTime} Minuten Lesezeit\",\n    \"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)\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"Kopieren\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"Kopiert\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"In die Zwischenablage kopieren\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"Zeilenumbruch umschalten\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"Startseite\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"Seitenleiste einklappen\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"Seitenleiste einklappen\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"Dokumentationsseitenleiste\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"Navigationsleiste schließen\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← Zurück zum Hauptmenü\",\n    \"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)\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"Navigationsleiste umschalten\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"Dropdown erweitern\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"Dropdown einklappen\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"Seitenleiste ausklappen\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"Seitenleiste ausklappen\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"Ein Post|{count} Posts\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"{nPosts} getaggt mit \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"Autoren\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"Alle Autoren anzeigen\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"Dieser Autor hat noch keine Beiträge geschrieben.\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"Nicht gelistete Seite\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"message\": \"Diese Seite ist nicht gelistet. Suchmaschinen werden sie nicht indexieren, und nur Benutzer mit einem direkten Link können darauf zugreifen.\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"Entwurfsseite\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"Diese Seite ist ein Entwurf. Sie ist nur in der Entwicklung sichtbar und wird vom Produktions-Build ausgeschlossen.\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"Nochmal versuchen\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"Zum Hauptinhalt springen\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"Tags\",\n    \"description\": \"The title of the tag list page\"\n  }\n}\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Blog\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"Blog\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"Alle Beiträge\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Helm verwenden\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Helm-Befehle\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"Templates entwickeln\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Bewährte Praktiken\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: Allgemeine Konventionen\ndescription: Allgemeine Konventionen für Charts.\nsidebar_position: 1\n---\n\nDieser Teil des Best-Practices-Leitfadens erklärt allgemeine Konventionen.\n\n## Chart-Namen\n\nChart-Namen müssen aus Kleinbuchstaben und Zahlen bestehen. Wörter _können_ durch Bindestriche (-) getrennt werden:\n\nBeispiele:\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nWeder Großbuchstaben noch Unterstriche können in Chart-Namen verwendet werden. Punkte sollten in Chart-Namen nicht verwendet werden.\n\n## Versionsnummern\n\nWo 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.)\n\nWenn SemVer-Versionen in Kubernetes-Labels gespeichert werden, ersetzen wir üblicherweise das `+`-Zeichen durch ein `_`-Zeichen, da Labels das `+`-Zeichen als Wert nicht zulassen.\n\n## YAML-Formatierung\n\nYAML-Dateien sollten mit _zwei Leerzeichen_ eingerückt werden (und niemals mit Tabs).\n\n## Verwendung der Wörter Helm und Chart\n\nEs gibt einige Konventionen für die Verwendung der Wörter _Helm_ und _helm_.\n\n- _Helm_ bezieht sich auf das Projekt als Ganzes\n- `helm` bezieht sich auf den clientseitigen Befehl\n- Der Begriff `chart` muss nicht großgeschrieben werden, da es sich nicht um einen Eigennamen handelt\n- Allerdings muss `Chart.yaml` großgeschrieben werden, da der Dateiname Groß- und Kleinschreibung unterscheidet\n\nIm Zweifelsfall verwenden Sie _Helm_ (mit einem großen 'H').\n\n## Chart-Templates und Namespaces\n\nVermeiden 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.).\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Custom Resource Definitions\ndescription: Erstellen und Verwenden von CRDs.\nsidebar_position: 7\n---\n\nDieser Teil des Best-Practices-Leitfadens behandelt die Erstellung und Verwendung von Custom-Resource-Definition-Objekten.\n\nBei der Arbeit mit Custom Resource Definitions (CRDs) ist es wichtig, zwei Dinge zu unterscheiden:\n\n- Es gibt eine Deklaration einer CRD. Dies ist die YAML-Datei mit `kind: CustomResourceDefinition`\n- 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.\n\n## CRD-Deklaration vor Ressourcenverwendung installieren\n\nHelm 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).\n\nBei CRDs gibt es jedoch einen Unterschied.\n\nBei einer CRD muss die Deklaration registriert werden, bevor Ressourcen dieser CRD-Art(en) verwendet werden können. Der Registrierungsprozess dauert manchmal einige Sekunden.\n\n### Methode 1: Helm die Arbeit überlassen\n\nMit 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.\n\n#### Einige Vorbehalte (und Erklärungen)\n\nDerzeit 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.\n\nDas `--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.\n\nEin 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.\n\n### Methode 2: Separate Charts\n\nEine 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.\n\nBei 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.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: Abhängigkeiten\ndescription: Behandelt Best Practices für Chart-Abhängigkeiten.\nsidebar_position: 4\n---\n\nDieser Teil des Best-Practices-Leitfadens behandelt die in `Chart.yaml` deklarierten `dependencies`.\n\n## Versionen\n\nVerwenden Sie nach Möglichkeit Versionsbereiche anstelle einer exakten Version. Der empfohlene Standard ist ein Patch-Level-Versionsabgleich:\n\n```yaml\nversion: ~1.2.3\n```\n\nDies 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`\n\nDie vollständige Syntax für den Versionsabgleich finden Sie in der [semver-Dokumentation](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Prerelease-Versionen\n\nDie 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:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### Repository-URLs\n\nVerwenden Sie nach Möglichkeit `https://`-Repository-URLs, gefolgt von `http://`-URLs.\n\nWenn 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.\n\nDatei-URLs (`file://...`) gelten als „Sonderfall\" für Charts, die durch eine feste Deployment-Pipeline zusammengestellt werden.\n\nBei 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.\n\nHelm 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.\n\n## Conditions und Tags\n\nConditions oder Tags sollten zu allen Abhängigkeiten hinzugefügt werden, die _optional_ sind. Beachten Sie, dass eine `condition` standardmäßig den Wert `true` hat.\n\nDie bevorzugte Form einer Condition ist:\n\n```yaml\ncondition: somechart.enabled\n```\n\nWobei `somechart` der Chart-Name der Abhängigkeit ist.\n\nWenn mehrere Subcharts (Abhängigkeiten) zusammen eine optionale oder austauschbare Funktion bereitstellen, sollten diese Charts dieselben Tags teilen.\n\nWenn 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:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nDies ermöglicht es einem Benutzer, diese Funktion mit einem Tag ein- und auszuschalten.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: Labels und Annotationen\ndescription: Behandelt Best Practices für die Verwendung von Labels und Annotationen in Ihrem Chart.\nsidebar_position: 5\n---\n\nDieser Teil des Best-Practices-Leitfadens behandelt Best Practices für die Verwendung von Labels und Annotationen in Ihrem Chart.\n\n## Ist es ein Label oder eine Annotation?\n\nEin Metadateneintrag sollte unter folgenden Bedingungen ein Label sein:\n\n- Es wird von Kubernetes verwendet, um diese Ressource zu identifizieren\n- Es ist nützlich für Administratoren, um das System abzufragen.\n\nZum Beispiel empfehlen wir, `helm.sh/chart: NAME-VERSION` als Label zu verwenden, damit Administratoren bequem alle Instanzen eines bestimmten Charts finden können.\n\nWenn ein Metadateneintrag nicht für Abfragen verwendet wird, sollte er stattdessen als Annotation gesetzt werden.\n\nHelm Hooks sind immer Annotationen.\n\n## Standard-Labels\n\nDie 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.\n\n| Name | Status | Beschreibung |\n|------|--------|--------------|\n| `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. |\n| `helm.sh/chart` | REC | Der Chart-Name und die Version: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`. |\n| `app.kubernetes.io/managed-by` | REC | Sollte immer auf `{{ .Release.Service }}` gesetzt werden. Dient dazu, alle von Helm verwalteten Ressourcen zu finden. |\n| `app.kubernetes.io/instance` | REC | Sollte `{{ .Release.Name }}` sein. Hilft bei der Unterscheidung zwischen verschiedenen Instanzen derselben Anwendung. |\n| `app.kubernetes.io/version` | OPT | Die Version der App, kann auf `{{ .Chart.AppVersion }}` gesetzt werden. |\n| `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`. |\n| `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. |\n\nWeitere 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/).\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pods und PodTemplates\ndescription: Behandelt die Formatierung von Pod- und PodTemplate-Bereichen in Chart-Manifesten.\nsidebar_position: 6\n---\n\nDieser Teil des Best-Practices-Leitfadens behandelt die Formatierung von Pod- und PodTemplate-Bereichen in Chart-Manifesten.\n\nDie folgende (nicht vollständige) Liste von Ressourcen verwendet PodTemplates:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Images\n\nEin 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.\n\nImages _können_ in der `values.yaml`-Datei definiert werden, um Images einfach auszutauschen.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nEin Image und ein Tag _können_ in `values.yaml` als zwei separate Felder definiert werden:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` setzt die `imagePullPolicy` standardmäßig auf `IfNotPresent` durch folgenden Eintrag in Ihrer `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nUnd in `values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nEbenso 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.\n\n## PodTemplates sollten Selektoren deklarieren\n\nAlle PodTemplate-Bereiche sollten einen Selektor angeben. Zum Beispiel:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nDies ist eine gute Praxis, da sie die Beziehung zwischen Set und Pod deutlich macht.\n\nBei 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.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: Rollenbasierte Zugriffskontrolle\ndescription: Behandelt die Erstellung und Formatierung von RBAC-Ressourcen in Chart-Manifesten.\nsidebar_position: 8\n---\n\nDieser Teil des Best-Practices-Leitfadens behandelt die Erstellung und Formatierung von\nRBAC-Ressourcen in Chart-Manifesten.\n\nRBAC-Ressourcen sind:\n\n- ServiceAccount (Namespace-gebunden)\n- Role (Namespace-gebunden)\n- ClusterRole\n- RoleBinding (Namespace-gebunden)\n- ClusterRoleBinding\n\n## YAML-Konfiguration\n\nRBAC- und ServiceAccount-Konfiguration sollte unter separaten Schlüsseln erfolgen.\nEs handelt sich um unterschiedliche Konzepte. Die Trennung in der YAML-Datei\nverdeutlicht den Unterschied und macht die Konfiguration klarer.\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\nDiese Struktur kann für komplexere Charts erweitert werden, die mehrere\nServiceAccounts benötigen.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## RBAC-Ressourcen sollten standardmäßig erstellt werden\n\n`rbac.create` sollte ein boolescher Wert sein, der steuert, ob RBAC-Ressourcen\nerstellt werden. Der Standardwert sollte `true` sein. Benutzer, die ihre\nRBAC-Zugriffskontrollen selbst verwalten möchten, können diesen Wert auf `false`\nsetzen (siehe hierzu den Abschnitt unten).\n\n## Verwendung von RBAC-Ressourcen\n\n`serviceAccount.name` sollte auf den Namen des ServiceAccounts gesetzt werden,\nder von den zugriffskontrollierten Ressourcen des Charts verwendet wird.\n\n- Wenn `serviceAccount.create` auf `true` gesetzt ist, wird ein ServiceAccount mit\n  diesem Namen erstellt. Wenn kein Name angegeben ist, wird ein Name anhand des\n  `fullname`-Templates generiert.\n- Wenn `serviceAccount.create` auf `false` gesetzt ist, wird der ServiceAccount\n  nicht erstellt. Er sollte jedoch denselben Ressourcen zugeordnet werden, damit\n  manuell erstellte RBAC-Ressourcen, die später darauf verweisen, korrekt funktionieren.\n- Wenn `serviceAccount.create` auf `false` gesetzt ist und kein Name angegeben wurde,\n  wird der Standard-ServiceAccount verwendet.\n\nVerwenden Sie das folgende Helper-Template für den ServiceAccount:\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: Templates\ndescription: Ein genauerer Blick auf Best Practices rund um Templates.\nsidebar_position: 3\n---\n\nDieser Teil des Best-Practices-Leitfadens konzentriert sich auf Templates.\n\n## Struktur von `templates/`\n\nDas `templates/`-Verzeichnis sollte wie folgt strukturiert sein:\n\n- Template-Dateien sollten die Erweiterung `.yaml` haben, wenn sie YAML-Ausgabe erzeugen.\n  Die Erweiterung `.tpl` kann für Template-Dateien verwendet werden, die keinen\n  formatierten Inhalt erzeugen.\n- Template-Dateinamen sollten die Bindestrich-Schreibweise verwenden (`my-example-configmap.yaml`),\n  nicht camelCase.\n- Jede Ressourcendefinition sollte in einer eigenen Template-Datei sein.\n- Template-Dateinamen sollten die Ressourcen-Art im Namen widerspiegeln, z.B.\n  `foo-pod.yaml`, `bar-svc.yaml`\n\n## Namen von definierten Templates\n\nDefinierte Templates (Templates, die innerhalb einer `{{ define }}`-Direktive erstellt werden) sind\nglobal zugänglich. Das bedeutet, dass ein Chart und alle seine Subcharts Zugriff auf alle\nmit `{{ define }}` erstellten Templates haben.\n\nAus diesem Grund sollten _alle Namen definierter Templates einen Namespace haben._\n\nRichtig:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nFalsch:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\n\nEs wird dringend empfohlen, neue Charts mit dem Befehl `helm create` zu erstellen,\nda die Template-Namen automatisch gemäß dieser Best Practice definiert werden.\n\n## Formatierung von Templates\n\nTemplates sollten mit _zwei Leerzeichen_ eingerückt werden (niemals Tabs).\n\nTemplate-Direktiven sollten Leerzeichen nach den öffnenden geschweiften Klammern und vor\nden schließenden geschweiften Klammern haben:\n\nRichtig:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nFalsch:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nTemplates sollten Whitespace nach Möglichkeit trimmen:\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nBlöcke (wie Kontrollstrukturen) können eingerückt werden, um den Fluss des\nTemplate-Codes anzuzeigen.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nDa YAML jedoch eine Whitespace-orientierte Sprache ist, ist es oft nicht möglich,\ndass die Code-Einrückung dieser Konvention folgt.\n\n## Whitespace in generierten Templates\n\nDie Menge an Whitespace in generierten Templates sollte minimal gehalten werden.\nInsbesondere sollten nicht mehrere leere Zeilen nebeneinander erscheinen.\nGelegentliche leere Zeilen (besonders zwischen logischen Abschnitten) sind jedoch in Ordnung.\n\nDas ist am besten:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nDas ist akzeptabel:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nAber das sollte vermieden werden:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Kommentare (YAML-Kommentare vs. Template-Kommentare)\n\nSowohl YAML als auch Helm Templates haben Kommentarzeichen.\n\nYAML-Kommentare:\n```yaml\n# This is a comment\ntype: sprocket\n```\n\nTemplate-Kommentare:\n```yaml\n{{- /*\nThis is a comment.\n*/}}\ntype: frobnitz\n```\n\nTemplate-Kommentare sollten verwendet werden, wenn Funktionen eines Templates dokumentiert werden,\nzum Beispiel um ein definiertes Template zu erklären:\n\n```yaml\n{{- /*\nmychart.shortname provides a 6 char truncated version of the release name.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nInnerhalb von Templates können YAML-Kommentare verwendet werden, wenn es für Helm-Benutzer\nnützlich ist, die Kommentare (möglicherweise) beim Debugging zu sehen.\n\n```yaml\n# This may cause problems if the value is more than 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nDer obige Kommentar ist sichtbar, wenn der Benutzer `helm install --debug` ausführt, während\nKommentare in `{{- /* */}}`-Abschnitten nicht angezeigt werden.\n\nSeien 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.\n\nWenn zum Beispiel die Funktion `required` im obigen Beispiel verwendet wird und `maxMem` nicht gesetzt ist, führt ein `#` YAML-Kommentar zu einem Rendering-Fehler.\n\nRichtig: `helm template` rendert diesen Block nicht\n```yaml\n{{- /*\n# This may cause problems if the value is more than 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nFalsch: `helm template` gibt zurück `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n```yaml\n# This may cause problems if the value is more than 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nLesen Sie [Templates debuggen](../chart_template_guide/debugging.md) für ein weiteres Beispiel dieses Verhaltens, wie YAML-Kommentare intakt bleiben.\n\n## Verwendung von JSON in Templates und Template-Ausgabe\n\nYAML ist eine Obermenge von JSON. In manchen Fällen kann die Verwendung einer JSON-Syntax\nlesbarer sein als andere YAML-Darstellungen.\n\nZum Beispiel ist dieses YAML näher an der normalen YAML-Methode, Listen auszudrücken:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nAber es ist einfacher zu lesen, wenn es im JSON-Listen-Stil zusammengefasst wird:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nDie Verwendung von JSON für bessere Lesbarkeit ist gut. JSON-Syntax sollte jedoch nicht\nverwendet werden, um komplexere Strukturen darzustellen.\n\nBei reinem JSON, das in YAML eingebettet ist (wie bei der Init-Container-Konfiguration),\nist es natürlich angemessen, das JSON-Format zu verwenden.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: Values\ndescription: Beschreibt, wie Sie Ihre Values strukturieren und verwenden sollten.\nsidebar_position: 2\n---\n\nDieser 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.\n\n## Namenskonventionen\n\nVariablennamen sollten mit einem Kleinbuchstaben beginnen, und Wörter sollten in camelCase getrennt werden:\n\nRichtig:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nFalsch:\n\n```yaml\nChicken: true  # initial caps may conflict with built-ins\nchicken-noodle-soup: true # do not use hyphens in the name\n```\n\nAlle integrierten Helm-Variablen beginnen mit einem Großbuchstaben, um sie leicht von benutzerdefinierten Values zu unterscheiden: `.Release.Name`, `.Capabilities.KubeVersion`.\n\n## Flache oder verschachtelte Values\n\nYAML ist ein flexibles Format, und Values können tief verschachtelt oder flach strukturiert sein.\n\nVerschachtelt:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nFlach:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nIn den meisten Fällen ist eine flache Struktur vorzuziehen. Der Grund: Sie ist für Template-Entwickler und Benutzer einfacher.\n\nFür optimale Sicherheit muss ein verschachtelter Wert auf jeder Ebene überprüft werden:\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nFü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.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\nWenn es eine große Anzahl verwandter Variablen gibt und mindestens eine davon erforderlich ist, können verschachtelte Values zur Verbesserung der Lesbarkeit verwendet werden.\n\n## Typen explizit angeben\n\nDie 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.\n\nDer 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_.\n\nOft ist es vorteilhaft, Ganzzahlen ebenfalls als Strings zu speichern und im Template `{{ int $value }}` zu verwenden, um sie wieder in eine Ganzzahl umzuwandeln.\n\nIn 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.\n\n## Bedenken Sie die Nutzung durch Anwender\n\nEs gibt drei potenzielle Quellen für Values:\n\n- Die `values.yaml`-Datei eines Charts\n- Eine Values-Datei, die mit `helm install -f` oder `helm upgrade -f` übergeben wird\n- Die Werte, die über die Flags `--set` oder `--set-string` bei `helm install` oder `helm upgrade` übergeben werden\n\nBedenken Sie beim Entwurf der Struktur Ihrer Values, dass Benutzer diese möglicherweise über das `-f`-Flag oder mit der `--set`-Option überschreiben möchten.\n\nDa `--set` weniger flexibel ist, lautet die erste Richtlinie für das Schreiben Ihrer `values.yaml`-Datei: _Machen Sie das Überschreiben über `--set` einfach_.\n\nAus diesem Grund ist es oft besser, Ihre Values-Datei mit Maps zu strukturieren.\n\nSchwierig mit `--set` zu verwenden:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nDas 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.\n\nEinfach zu verwenden:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nDer Zugriff auf den Port von foo ist viel offensichtlicher: `--set servers.foo.port=80`.\n\n## Dokumentieren Sie `values.yaml`\n\nJede definierte Eigenschaft in `values.yaml` sollte dokumentiert werden. Der Dokumentationsstring sollte mit dem Namen der beschriebenen Eigenschaft beginnen und dann mindestens eine Satzbeschreibung enthalten.\n\nFalsch:\n\n```yaml\n# the host name for the webserver\nserverHost: example\nserverPort: 9191\n```\n\nRichtig:\n\n```yaml\n# serverHost is the host name for the webserver\nserverHost: example\n# serverPort is the HTTP listener port for the webserver\nserverPort: 9191\n```\n\nJeden 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.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Zugriff auf Dateien innerhalb von Templates\ndescription: Wie Sie auf Dateien innerhalb eines Templates zugreifen können.\nsidebar_position: 10\n---\n\nIm vorherigen Abschnitt haben wir mehrere Möglichkeiten kennengelernt, benannte\nTemplates zu erstellen und darauf zuzugreifen. Dies erleichtert das Importieren\neines Templates aus einem anderen Template. Manchmal ist es jedoch wünschenswert,\neine _Datei zu importieren, die kein Template ist_ und deren Inhalt einzufügen,\nohne ihn durch die Template-Rendering-Engine zu senden.\n\nHelm bietet Zugriff auf Dateien über das `.Files`-Objekt. Bevor wir mit den\nTemplate-Beispielen beginnen, gibt es einige wichtige Hinweise zur Funktionsweise:\n\n- Sie können zusätzliche Dateien zu Ihrem Helm Chart hinzufügen. Diese\n  Dateien werden mitgebündelt. Seien Sie jedoch vorsichtig: Charts müssen\n  aufgrund der Speicherbeschränkungen von Kubernetes-Objekten kleiner als 1 MB sein.\n- Einige Dateien können aus Sicherheitsgründen nicht über das `.Files`-Objekt\n  aufgerufen werden:\n  - Dateien in `templates/` sind nicht zugänglich.\n  - Dateien, die über `.helmignore` ausgeschlossen werden, sind nicht zugänglich.\n  - Dateien außerhalb eines Helm-Anwendungs-[Subcharts](./subcharts_and_globals.md), einschließlich derjenigen des übergeordneten Charts, sind nicht zugänglich.\n- Charts behalten keine UNIX-Modus-Informationen bei, sodass Datei-Berechtigungen\n  keinen Einfluss auf die Verfügbarkeit einer Datei über das `.Files`-Objekt haben.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Einfaches Beispiel](#einfaches-beispiel)\n- [Pfad-Hilfsfunktionen](#pfad-hilfsfunktionen)\n- [Glob-Muster](#glob-muster)\n- [ConfigMap- und Secrets-Hilfsfunktionen](#configmap--und-secrets-hilfsfunktionen)\n- [Kodierung](#kodierung)\n- [Zeilen](#zeilen)\n\n<!-- tocstop -->\n\n## Einfaches Beispiel\n\nMit diesen Hinweisen im Hinterkopf schreiben wir nun ein Template, das drei\nDateien in unsere ConfigMap einliest. Zunächst fügen wir drei Dateien zum\nChart hinzu und platzieren sie direkt im Verzeichnis `mychart/`.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nJede dieser Dateien ist eine einfache TOML-Datei (ähnlich den klassischen\nWindows-INI-Dateien). Da wir die Namen dieser Dateien kennen, können wir eine\n`range`-Funktion verwenden, um sie zu durchlaufen und ihren Inhalt in unsere\nConfigMap einzufügen.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nDiese ConfigMap verwendet mehrere Techniken, die in den vorherigen Abschnitten\nbesprochen wurden. Zum Beispiel erstellen wir eine Variable `$files`, um eine\nReferenz auf das `.Files`-Objekt zu speichern. Wir verwenden auch die\n`tuple`-Funktion, um eine Liste von Dateien zu erstellen, die wir durchlaufen.\nDann geben wir jeden Dateinamen aus (`{{ . }}: |-`), gefolgt vom Inhalt der\nDatei `{{ $files.Get . }}`.\n\nDas Ausführen dieses Templates erzeugt eine einzelne ConfigMap mit dem Inhalt\naller drei Dateien:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Pfad-Hilfsfunktionen\n\nBei der Arbeit mit Dateien kann es sehr nützlich sein, einige Standardoperationen\nauf den Dateipfaden selbst auszuführen. Um dabei zu helfen, importiert Helm viele\nFunktionen aus dem Go-Paket [path](https://golang.org/pkg/path/) für Ihre Nutzung.\nSie sind alle mit denselben Namen wie im Go-Paket zugänglich, jedoch mit einem\nKleinbuchstaben am Anfang. Zum Beispiel wird `Base` zu `base`, usw.\n\nDie importierten Funktionen sind:\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Glob-Muster\n\nWenn Ihr Chart wächst, werden Sie möglicherweise feststellen, dass Sie Ihre\nDateien besser organisieren müssen. Deshalb bieten wir eine Methode\n`Files.Glob(pattern string)` an, die beim Extrahieren bestimmter Dateien mit\nder vollen Flexibilität von [Glob-Mustern](https://godoc.org/github.com/gobwas/glob)\nhilft.\n\n`.Glob` gibt einen `Files`-Typ zurück, sodass Sie alle `Files`-Methoden auf dem\nzurückgegebenen Objekt aufrufen können.\n\nStellen Sie sich zum Beispiel folgende Verzeichnisstruktur vor:\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nSie haben mehrere Optionen mit Globs:\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nOder\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## ConfigMap- und Secrets-Hilfsfunktionen\n\n(Verfügbar ab Helm 2.0.2 und später)\n\nEs ist sehr üblich, Dateiinhalte sowohl in ConfigMaps als auch in Secrets zu\nplatzieren, um sie zur Laufzeit in Ihre Pods einzubinden. Um dabei zu helfen,\nbieten wir einige Hilfsmethoden auf dem `Files`-Typ an.\n\nFür eine bessere Organisation ist es besonders nützlich, diese Methoden in\nVerbindung mit der `Glob`-Methode zu verwenden.\n\nMit der Verzeichnisstruktur aus dem [Glob](#glob-muster)-Beispiel oben:\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Kodierung\n\nSie können eine Datei importieren und das Template sie base64-kodieren lassen,\num eine erfolgreiche Übertragung sicherzustellen:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nDas obige Beispiel nimmt dieselbe `config1.toml`-Datei, die wir zuvor verwendet\nhaben, und kodiert sie:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Zeilen\n\nManchmal ist es wünschenswert, auf jede Zeile einer Datei in Ihrem Template\nzuzugreifen. Wir bieten dafür eine praktische `Lines`-Methode.\n\nSie können `Lines` mit einer `range`-Funktion durchlaufen:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nEs gibt keine Möglichkeit, Dateien von außerhalb des Charts während\n`helm install` zu übergeben. Wenn Sie möchten, dass Benutzer Daten bereitstellen,\nmüssen diese über `helm install -f` oder `helm install --set` geladen werden.\n\nDamit schließen wir unseren Einblick in die Werkzeuge und Techniken zum\nSchreiben von Helm-Templates ab. Im nächsten Abschnitt werden wir sehen, wie Sie\neine spezielle Datei, `templates/NOTES.txt`, verwenden können, um den Benutzern\nIhres Charts Anweisungen nach der Installation zu senden.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Integrierte Objekte\ndescription: Integrierte Objekte, die in Templates verfügbar sind.\nsidebar_position: 3\n---\n\nObjekte werden von der Template-Engine an ein Template übergeben. Ihr Code kann\nObjekte weitergeben (wir werden Beispiele sehen, wenn wir uns die `with`- und\n`range`-Anweisungen ansehen). Es gibt sogar einige Möglichkeiten, neue Objekte\ninnerhalb Ihrer Templates zu erstellen, wie z.B. mit der `tuple`-Funktion, die\nwir später sehen werden.\n\nObjekte können einfach sein und nur einen Wert haben. Oder sie können andere\nObjekte oder Funktionen enthalten. Zum Beispiel enthält das `Release`-Objekt\nmehrere Objekte (wie `Release.Name`) und das `Files`-Objekt verfügt über einige\nFunktionen.\n\nIm vorherigen Abschnitt haben wir `{{ .Release.Name }}` verwendet, um den Namen\neines Release in ein Template einzufügen. `Release` ist eines der Top-Level-\nObjekte, auf die Sie in Ihren Templates zugreifen können.\n\n- `Release`: Dieses Objekt beschreibt das Release selbst. Es enthält mehrere\n  Objekte:\n  - `Release.Name`: Der Release-Name\n  - `Release.Namespace`: Der Namespace, in den bereitgestellt wird (sofern das\n    Manifest dies nicht überschreibt)\n  - `Release.IsUpgrade`: Wird auf `true` gesetzt, wenn die aktuelle Operation\n    ein Upgrade oder Rollback ist.\n  - `Release.IsInstall`: Wird auf `true` gesetzt, wenn die aktuelle Operation\n    eine Installation ist.\n  - `Release.Revision`: Die Revisionsnummer für dieses Release. Bei der\n    Installation ist dies 1, und sie wird mit jedem Upgrade und Rollback erhöht.\n  - `Release.Service`: Der Dienst, der das aktuelle Template rendert. In Helm\n    ist dies immer `Helm`.\n- `Values`: Werte, die aus der `values.yaml`-Datei und aus vom Benutzer\n  bereitgestellten Dateien an das Template übergeben werden. Standardmäßig ist\n  `Values` leer.\n- `Chart`: Der Inhalt der `Chart.yaml`-Datei. Alle Daten in `Chart.yaml` sind\n  hier zugänglich. Zum Beispiel gibt `{{ .Chart.Name }}-{{ .Chart.Version }}`\n  `mychart-0.1.0` aus.\n  - Die verfügbaren Felder sind in der [Charts-Anleitung](/topics/charts.md#the-chartyaml-file)\n    aufgelistet\n- `Subcharts`: Dies ermöglicht den Zugriff auf den Scope (.Values, .Charts,\n  .Releases usw.) von Subcharts für das übergeordnete Chart. Zum Beispiel greift\n  `.Subcharts.mySubChart.myValue` auf den `myValue` im `mySubChart`-Chart zu.\n- `Files`: Dies ermöglicht den Zugriff auf alle nicht-speziellen Dateien in\n  einem Chart. Sie können damit zwar nicht auf Templates zugreifen, aber auf\n  andere Dateien im Chart. Weitere Informationen finden Sie im Abschnitt\n  [Zugriff auf Dateien](/chart_template_guide/accessing_files.md).\n  - `Files.Get` ist eine Funktion zum Abrufen einer Datei nach Namen\n    (`.Files.Get config.ini`)\n  - `Files.GetBytes` ist eine Funktion zum Abrufen des Inhalts einer Datei als\n    Byte-Array anstatt als String. Dies ist nützlich für Dinge wie Bilder.\n  - `Files.Glob` ist eine Funktion, die eine Liste von Dateien zurückgibt, deren\n    Namen dem angegebenen Shell-Glob-Muster entsprechen.\n  - `Files.Lines` ist eine Funktion, die eine Datei Zeile für Zeile liest. Dies\n    ist nützlich für die Iteration über jede Zeile in einer Datei.\n  - `Files.AsSecrets` ist eine Funktion, die die Dateiinhalte als Base64-\n    codierte Strings zurückgibt.\n  - `Files.AsConfig` ist eine Funktion, die Dateiinhalte als YAML-Map zurückgibt.\n- `Capabilities`: Dies liefert Informationen darüber, welche Fähigkeiten der\n  Kubernetes-Cluster unterstützt.\n  - `Capabilities.APIVersions` ist eine Sammlung von Versionen.\n  - `Capabilities.APIVersions.Has $version` gibt an, ob eine Version (z.B.\n    `batch/v1`) oder Ressource (z.B. `apps/v1/Deployment`) im Cluster verfügbar\n    ist.\n  - `Capabilities.KubeVersion` und `Capabilities.KubeVersion.Version` ist die\n    Kubernetes-Version.\n  - `Capabilities.KubeVersion.Major` ist die Kubernetes-Hauptversion.\n  - `Capabilities.KubeVersion.Minor` ist die Kubernetes-Nebenversion.\n  - `Capabilities.HelmVersion` ist das Objekt, das die Helm-Versionsdetails\n    enthält; es entspricht der Ausgabe von `helm version`.\n  - `Capabilities.HelmVersion.Version` ist die aktuelle Helm-Version im\n    SemVer-Format.\n  - `Capabilities.HelmVersion.GitCommit` ist der Helm-Git-SHA1.\n  - `Capabilities.HelmVersion.GitTreeState` ist der Zustand des Helm-Git-Trees.\n  - `Capabilities.HelmVersion.GoVersion` ist die Version des verwendeten\n    Go-Compilers.\n- `Template`: Enthält Informationen über das aktuelle Template, das ausgeführt\n  wird\n  - `Template.Name`: Ein namespace-qualifizierter Dateipfad zum aktuellen\n    Template (z.B. `mychart/templates/mytemplate.yaml`)\n  - `Template.BasePath`: Der namespace-qualifizierte Pfad zum Templates-\n    Verzeichnis des aktuellen Charts (z.B. `mychart/templates`).\n\nDie integrierten Werte beginnen immer mit einem Großbuchstaben. Dies entspricht\nder Go-Namenskonvention. Wenn Sie Ihre eigenen Namen erstellen, können Sie eine\nKonvention verwenden, die zu Ihrem Team passt. Einige Teams, wie viele, deren\nCharts Sie auf [Artifact Hub](https://artifacthub.io/packages/search?kind=0)\nfinden können, verwenden nur Kleinbuchstaben am Anfang, um lokale Namen von\nden integrierten zu unterscheiden. In dieser Anleitung folgen wir dieser\nKonvention.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Ablaufsteuerung\ndescription: Ein kurzer Überblick über die Ablaufstrukturen in Templates.\nsidebar_position: 7\n---\n\nKontrollstrukturen (in der Template-Terminologie \"Aktionen\" genannt) bieten\nIhnen als Template-Autor die Möglichkeit, den Ablauf der Template-Generierung\nzu steuern. Die Template-Sprache von Helm bietet die folgenden\nKontrollstrukturen:\n\n- `if`/`else` zum Erstellen von bedingten Blöcken\n- `with` zum Festlegen eines Geltungsbereichs\n- `range`, das eine \"für jedes\"-Schleife bereitstellt\n\nZusätzlich zu diesen bietet sie einige Aktionen zum Deklarieren und Verwenden\nvon benannten Template-Segmenten:\n\n- `define` deklariert ein neues benanntes Template innerhalb Ihres Templates\n- `template` importiert ein benanntes Template\n- `block` deklariert einen speziellen, ausfüllbaren Template-Bereich\n\nIn diesem Abschnitt behandeln wir `if`, `with` und `range`. Die anderen werden\nim Abschnitt \"Benannte Templates\" später in dieser Anleitung behandelt.\n\n## If/Else\n\nDie erste Kontrollstruktur, die wir uns ansehen werden, dient zum bedingten\nEinbinden von Textblöcken in einem Template. Dies ist der `if`/`else`-Block.\n\nDie grundlegende Struktur für eine Bedingung sieht so aus:\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\nBeachten Sie: Hier geht es um _Pipelines_, nicht nur um einzelne Werte. Der\nGrund dafür ist, klarzumachen, dass Kontrollstrukturen eine ganze Pipeline\nausführen können – nicht nur einen Wert auswerten.\n\nEine Pipeline wird als _false_ ausgewertet, wenn der Wert:\n\n- ein boolesches false ist\n- eine numerische Null ist\n- ein leerer String ist\n- `nil` (leer oder null) ist\n- eine leere Sammlung (`map`, `slice`, `tuple`, `dict`, `array`) ist\n\nUnter allen anderen Bedingungen ist die Bedingung wahr.\n\nFügen wir eine einfache Bedingung zu unserer ConfigMap hinzu. Wir fügen eine\nweitere Einstellung hinzu, wenn das Getränk auf Kaffee gesetzt ist:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nDa wir `drink: coffee` in unserem letzten Beispiel auskommentiert haben, sollte\ndie Ausgabe kein `mug: \"true\"` Flag enthalten. Aber wenn wir diese Zeile in\nunsere `values.yaml`-Datei zurücksetzen, sollte die Ausgabe so aussehen:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Steuerung von Leerzeichen\n\nWährend wir uns mit Bedingungen beschäftigen, sollten wir einen kurzen Blick\ndarauf werfen, wie Leerzeichen in Templates gesteuert werden. Nehmen wir das\nvorherige Beispiel und formatieren es etwas leserlicher:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nZunächst sieht das gut aus. Aber wenn wir es durch die Template-Engine laufen\nlassen, erhalten wir ein unglückliches Ergebnis:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nWas ist passiert? Wir haben wegen der obigen Leerzeichen ungültiges YAML\ngeneriert.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` ist falsch eingerückt. Lassen Sie uns einfach diese eine Zeile nach links\nverschieben und erneut ausführen:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nWenn wir das ausführen, erhalten wir YAML, das gültig ist, aber immer noch\netwas seltsam aussieht:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nBeachten Sie, dass wir einige Leerzeilen in unserem YAML erhalten haben. Warum?\nWenn die Template-Engine läuft, _entfernt_ sie den Inhalt innerhalb von `{{`\nund `}}`, lässt aber die verbleibenden Leerzeichen genau so, wie sie sind.\n\nYAML misst Leerzeichen eine Bedeutung bei, daher wird die Verwaltung von\nLeerzeichen ziemlich wichtig. Glücklicherweise haben Helm-Templates einige\nWerkzeuge, um dabei zu helfen.\n\nErstens kann die geschweifte Klammer-Syntax von Template-Deklarationen mit\nspeziellen Zeichen modifiziert werden, um der Template-Engine mitzuteilen, dass\nsie Leerzeichen entfernen soll. `{{- ` (mit dem Bindestrich und Leerzeichen)\nzeigt an, dass Leerzeichen links entfernt werden sollen, während ` -}}`\nbedeutet, dass Leerzeichen rechts entfernt werden sollen. _Vorsicht! Zeilenumbrüche\nsind auch Leerzeichen!_\n\n> Stellen Sie sicher, dass zwischen dem `-` und dem Rest Ihrer Direktive ein\n> Leerzeichen steht. `{{- 3 }}` bedeutet \"entferne Leerzeichen links und gib 3 aus\",\n> während `{{-3 }}` \"gib -3 aus\" bedeutet.\n\nMit dieser Syntax können wir unser Template ändern, um diese Leerzeilen\nloszuwerden:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nZur Verdeutlichung passen wir das Obige an und ersetzen ein `*` für jedes\nLeerzeichen, das nach dieser Regel gelöscht wird. Ein `*` am Ende der Zeile\nzeigt ein Zeilenumbruchzeichen an, das entfernt würde:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nMit diesem Wissen können wir unser Template durch Helm ausführen und das\nErgebnis sehen:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nVorsicht bei den Entfernungsmodifikatoren. Es ist leicht, versehentlich so\netwas zu tun:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nDas erzeugt `food: \"PIZZA\"mug: \"true\"`, weil es die Zeilenumbrüche auf beiden\nSeiten entfernt hat.\n\n> Für Details zur Leerzeichen-Steuerung in Templates siehe die [offizielle Go\n> Template-Dokumentation](https://godoc.org/text/template)\n\nSchließlich ist es manchmal einfacher, dem Template-System zu sagen, wie es für\nSie einrücken soll, anstatt zu versuchen, die Abstände der Template-Direktiven\nzu meistern. Aus diesem Grund kann es manchmal nützlich sein, die `indent`-\nFunktion zu verwenden (`{{ indent 2 \"mug:true\" }}`).\n\n## Geltungsbereich ändern mit `with`\n\nDie nächste Kontrollstruktur, die wir uns ansehen werden, ist die `with`-Aktion.\nDiese steuert den Geltungsbereich von Variablen. Zur Erinnerung: `.` ist eine\nReferenz auf _den aktuellen Geltungsbereich_. So sagt `.Values` dem Template,\ndass es das `Values`-Objekt im aktuellen Geltungsbereich finden soll.\n\nDie Syntax für `with` ähnelt einer einfachen `if`-Anweisung:\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\nGeltungsbereiche können geändert werden. `with` kann es Ihnen ermöglichen, den\naktuellen Geltungsbereich (`.`) auf ein bestimmtes Objekt zu setzen. Zum\nBeispiel haben wir mit `.Values.favorite` gearbeitet. Lassen Sie uns unsere\nConfigMap umschreiben, um den `.`-Geltungsbereich so zu ändern, dass er auf\n`.Values.favorite` zeigt:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nBeachten Sie, dass wir die `if`-Bedingung aus der vorherigen Übung entfernt\nhaben, weil sie jetzt nicht mehr notwendig ist – der Block nach `with` wird\nnur ausgeführt, wenn der Wert der `PIPELINE` nicht leer ist.\n\nBeachten Sie, dass wir jetzt `.drink` und `.food` ohne Qualifizierung\nreferenzieren können. Das liegt daran, dass die `with`-Anweisung `.` so setzt,\ndass es auf `.Values.favorite` zeigt. Der `.` wird nach `{{ end }}` auf seinen\nvorherigen Geltungsbereich zurückgesetzt.\n\nAber Vorsicht! Innerhalb des eingeschränkten Geltungsbereichs können Sie nicht\nmit `.` auf die anderen Objekte aus dem übergeordneten Geltungsbereich\nzugreifen. Das folgende Beispiel wird fehlschlagen:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nEs wird einen Fehler erzeugen, weil `Release.Name` nicht innerhalb des\neingeschränkten Geltungsbereichs für `.` liegt. Wenn wir jedoch die letzten\nbeiden Zeilen vertauschen, funktioniert alles wie erwartet, weil der\nGeltungsbereich nach `{{ end }}` zurückgesetzt wird.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nOder wir können `$` verwenden, um auf das Objekt `Release.Name` aus dem\nübergeordneten Geltungsbereich zuzugreifen. `$` wird bei Beginn der\nTemplate-Ausführung auf den Root-Geltungsbereich gemappt und ändert sich\nwährend der Template-Ausführung nicht. Das Folgende würde ebenfalls\nfunktionieren:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nNachdem wir uns `range` angesehen haben, werden wir einen Blick auf\nTemplate-Variablen werfen, die eine Lösung für das obige Geltungsbereichsproblem\nbieten.\n\n## Schleifen mit der `range`-Aktion\n\nViele Programmiersprachen unterstützen Schleifen mit `for`-Schleifen, `foreach`-\nSchleifen oder ähnlichen funktionalen Mechanismen. In der Template-Sprache von\nHelm ist die Methode zum Iterieren durch eine Sammlung der `range`-Operator.\n\nZunächst fügen wir eine Liste von Pizza-Belägen zu unserer `values.yaml`-Datei\nhinzu:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nJetzt haben wir eine Liste (in Templates `slice` genannt) von `pizzaToppings`.\nWir können unser Template ändern, um diese Liste in unsere ConfigMap\nauszugeben:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nWir können `$` verwenden, um auf die Liste `Values.pizzaToppings` aus dem\nübergeordneten Geltungsbereich zuzugreifen. `$` wird bei Beginn der Template-\nAusführung auf den Root-Geltungsbereich gemappt und ändert sich während der\nTemplate-Ausführung nicht. Das Folgende würde ebenfalls funktionieren:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nSchauen wir uns die `toppings:`-Liste genauer an. Die `range`-Funktion wird\ndurch die `pizzaToppings`-Liste \"rangieren\" (iterieren). Aber jetzt passiert\netwas Interessantes. Genau wie `with` den Geltungsbereich von `.` setzt, tut\ndies auch ein `range`-Operator. Bei jedem Durchlauf durch die Schleife wird `.`\nauf den aktuellen Pizza-Belag gesetzt. Das heißt, beim ersten Mal wird `.` auf\n`mushrooms` gesetzt. In der zweiten Iteration wird es auf `cheese` gesetzt,\nund so weiter.\n\nWir können den Wert von `.` direkt durch eine Pipeline senden, sodass wenn wir\n`{{ . | title | quote }}` ausführen, es `.` an `title` (Großschreibungsfunktion)\nund dann an `quote` sendet. Wenn wir dieses Template ausführen, ist die\nAusgabe:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nIn diesem Beispiel haben wir etwas Trickreiches gemacht. Die Zeile\n`toppings: |-` deklariert einen mehrzeiligen String. Unsere Belagsliste ist\nalso eigentlich keine YAML-Liste. Sie ist ein großer String. Warum sollten wir\ndas tun? Weil die Daten in ConfigMaps aus Schlüssel/Wert-Paaren bestehen, bei\ndenen sowohl der Schlüssel als auch der Wert einfache Strings sind. Um zu\nverstehen, warum das so ist, schauen Sie sich die [Kubernetes ConfigMap-\nDokumentation](https://kubernetes.io/docs/concepts/configuration/configmap/)\nan. Für uns spielt dieses Detail jedoch keine große Rolle.\n\n> Die `|-`-Markierung in YAML nimmt einen mehrzeiligen String. Dies kann eine\n> nützliche Technik sein, um große Datenblöcke in Ihre Manifeste einzubetten,\n> wie hier gezeigt.\n\nManchmal ist es nützlich, schnell eine Liste innerhalb Ihres Templates zu\nerstellen und dann über diese Liste zu iterieren. Helm-Templates haben eine\nFunktion, die das einfach macht: `tuple`. In der Informatik ist ein Tupel eine\nlistenartige Sammlung fester Größe, aber mit beliebigen Datentypen. Dies\nvermittelt ungefähr, wie ein `tuple` verwendet wird.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nDas Obige erzeugt:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nZusätzlich zu Listen und Tupeln kann `range` verwendet werden, um über\nSammlungen zu iterieren, die einen Schlüssel und einen Wert haben (wie eine\n`map` oder `dict`). Wir werden sehen, wie das geht, im nächsten Abschnitt, wenn\nwir Template-Variablen einführen.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Anhang: Go-Datentypen und Templates\"\ndescription: Ein kurzer Überblick über Variablen in Templates.\nsidebar_position: 16\n---\n\nDie Helm-Template-Sprache ist in der stark typisierten Programmiersprache Go\nimplementiert. Aus diesem Grund sind Variablen in Templates _typisiert_. In den\nmeisten Fällen werden Variablen als einer der folgenden Typen bereitgestellt:\n\n- string: Eine Textzeichenkette\n- bool: Ein `true` oder `false`\n- int: Ein Integer-Wert (es gibt auch 8-, 16-, 32- und 64-Bit-Varianten, jeweils\n  mit und ohne Vorzeichen)\n- float64: Ein 64-Bit-Gleitkommawert (es gibt auch 8-, 16- und 32-Bit-Varianten\n  davon)\n- Ein Byte-Slice (`[]byte`), das häufig für (potenziell) binäre Daten verwendet\n  wird\n- struct: Ein Objekt mit Eigenschaften und Methoden\n- Ein Slice (indizierte Liste) eines der vorherigen Typen\n- Eine Map mit String-Schlüsseln (`map[string]interface{}`), wobei der Wert\n  einer der vorherigen Typen ist\n\nEs gibt viele andere Typen in Go, und manchmal müssen Sie in Ihren Templates\nzwischen ihnen konvertieren. Am einfachsten ermitteln Sie den Typ eines Objekts,\nindem Sie es in einem Template an `printf \"%T\"` übergeben – dies gibt den Typ\naus. Siehe hierfür auch die Funktionen `typeOf` und `kindOf`.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: Templates debuggen\ndescription: Fehlerbehebung bei Charts, die nicht bereitgestellt werden können.\nsidebar_position: 13\n---\n\nDas Debuggen von Templates kann schwierig sein, da die gerenderten Templates an\nden Kubernetes-API-Server gesendet werden, der die YAML-Dateien aus anderen\nGründen als der Formatierung ablehnen kann.\n\nEs gibt einige Befehle, die Ihnen beim Debuggen helfen können.\n\n- `helm lint` ist Ihr bevorzugtes Werkzeug, um zu überprüfen, ob Ihr Chart den\n  Best Practices entspricht\n- `helm template --debug` testet das Rendern von Chart-Templates lokal.\n- `helm install --dry-run --debug` rendert Ihr Chart ebenfalls lokal ohne es zu\ninstallieren, prüft aber auch, ob bereits konfliktbehaftete Ressourcen auf dem\nCluster laufen. Mit `--dry-run=server` werden zusätzlich alle `lookup`-Aufrufe\nin Ihrem Chart gegen den Server ausgeführt.\n- `helm get manifest`: Dies ist eine gute Möglichkeit zu sehen, welche Templates\n  auf dem Server installiert sind.\n\nWenn Ihr YAML nicht geparst werden kann, Sie aber sehen möchten, was generiert\nwird, ist eine einfache Möglichkeit, das YAML abzurufen, den problematischen\nAbschnitt im Template auszukommentieren und dann `helm install --dry-run --debug`\nerneut auszuführen:\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\nDer obige Code wird gerendert und mit den Kommentaren intakt zurückgegeben:\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\nDies bietet eine schnelle Möglichkeit, den generierten Inhalt anzuzeigen, ohne\nvon YAML-Parse-Fehlern aufgehalten zu werden.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: Liste der Template-Funktionen\ndescription: Eine Liste der in Helm verfügbaren Template-Funktionen\nsidebar_position: 6\n---\n\nHelm enthält viele Template-Funktionen, die Sie in Templates nutzen können.\nSie sind hier aufgelistet und in folgende Kategorien unterteilt:\n\n* [Kryptografie und Sicherheit](#kryptografie--und-sicherheitsfunktionen)\n* [Datum](#datumsfunktionen)\n* [Dictionaries](#dictionaries-und-dict-funktionen)\n* [Encoding](#encoding-funktionen)\n* [Dateipfade](#dateipfad-funktionen)\n* [Kubernetes und Chart](#kubernetes--und-chart-funktionen)\n* [Logik und Ablaufsteuerung](#logik--und-ablaufsteuerungsfunktionen)\n* [Listen](#listen-und-list-funktionen)\n* [Mathematik](#mathematische-funktionen)\n* [Float-Mathematik](#float-mathematik-funktionen)\n* [Netzwerk](#netzwerk-funktionen)\n* [Reflection](#reflection-funktionen)\n* [Reguläre Ausdrücke](#reguläre-ausdrücke)\n* [Semantische Versionen](#semantische-versionsfunktionen)\n* [Strings](#string-funktionen)\n* [Typkonvertierung](#typkonvertierungsfunktionen)\n* [URL](#url-funktionen)\n* [UUID](#uuid-funktionen)\n\n## Logik- und Ablaufsteuerungsfunktionen\n\nHelm enthält zahlreiche Logik- und Ablaufsteuerungsfunktionen, darunter [and](#and),\n[coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq),\n[fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne),\n[not](#not), [or](#or) und [required](#required).\n\n### and\n\nGibt das boolesche AND von zwei oder mehr Argumenten zurück\n(das erste leere Argument oder das letzte Argument).\n\n```\nand .Arg1 .Arg2\n```\n\n### or\n\nGibt das boolesche OR von zwei oder mehr Argumenten zurück\n(das erste nicht-leere Argument oder das letzte Argument).\n\n```\nor .Arg1 .Arg2\n```\n\n### not\n\nGibt die boolesche Negation des Arguments zurück.\n\n```\nnot .Arg\n```\n\n### eq\n\nGibt die boolesche Gleichheit der Argumente zurück (z.B. Arg1 == Arg2).\n\n```\neq .Arg1 .Arg2\n```\n\n### ne\n\nGibt die boolesche Ungleichheit der Argumente zurück (z.B. Arg1 != Arg2).\n\n```\nne .Arg1 .Arg2\n```\n\n### lt\n\nGibt `true` zurück, wenn das erste Argument kleiner als das zweite ist.\nAndernfalls wird `false` zurückgegeben (z.B. Arg1 < Arg2).\n\n```\nlt .Arg1 .Arg2\n```\n\n### le\n\nGibt `true` zurück, wenn das erste Argument kleiner oder gleich dem zweiten ist.\nAndernfalls wird `false` zurückgegeben (z.B. Arg1 <= Arg2).\n\n```\nle .Arg1 .Arg2\n```\n\n### gt\n\nGibt `true` zurück, wenn das erste Argument größer als das zweite ist.\nAndernfalls wird `false` zurückgegeben (z.B. Arg1 > Arg2).\n\n```\ngt .Arg1 .Arg2\n```\n\n### ge\n\nGibt `true` zurück, wenn das erste Argument größer oder gleich dem zweiten ist.\nAndernfalls wird `false` zurückgegeben (z.B. Arg1 >= Arg2).\n\n```\nge .Arg1 .Arg2\n```\n\n### default\n\nUm einen einfachen Standardwert zu setzen, verwenden Sie `default`:\n\n```\ndefault \"foo\" .Bar\n```\n\nWenn `.Bar` einen nicht-leeren Wert ergibt, wird dieser verwendet. Ist er\njedoch leer, wird stattdessen `foo` zurückgegeben.\n\nDie Definition von \"leer\" hängt vom Typ ab:\n\n- Numerisch: 0\n- String: \"\"\n- Listen: `[]`\n- Dicts: `{}`\n- Boolean: `false`\n- Und immer `nil` (auch bekannt als null)\n\nFür Structs gibt es keine Definition von leer, daher gibt ein Struct niemals\nden Standardwert zurück.\n\n### required\n\nGeben Sie Werte an, die mit `required` gesetzt werden müssen:\n\n```\nrequired \"A valid foo is required!\" .Bar\n```\n\nWenn `.Bar` leer oder nicht definiert ist (siehe [default](#default) für die\nAuswertung), wird das Template nicht gerendert und stattdessen die angegebene\nFehlermeldung zurückgegeben.\n\n### empty\n\nDie Funktion `empty` gibt `true` zurück, wenn der angegebene Wert als leer\ngilt, andernfalls `false`. Die leeren Werte sind im Abschnitt `default`\naufgelistet.\n\n```\nempty .Foo\n```\n\nBeachten Sie, dass in Go-Template-Bedingungen die Leerheit automatisch\nberechnet wird. Daher benötigen Sie selten `if not empty .Foo`. Verwenden Sie\nstattdessen einfach `if .Foo`.\n\n### fail\n\nGibt bedingungslos einen leeren `string` und einen `error` mit dem angegebenen\nText zurück. Dies ist nützlich in Szenarien, in denen andere Bedingungen\nfestgestellt haben, dass das Template-Rendering fehlschlagen sollte.\n\n```\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\nDie Funktion `coalesce` nimmt eine Liste von Werten und gibt den ersten\nnicht-leeren zurück.\n\n```\ncoalesce 0 1 2\n```\n\nDas obige gibt `1` zurück.\n\nDiese Funktion ist nützlich, um mehrere Variablen oder Werte zu durchsuchen:\n\n```\ncoalesce .name .parent.name \"Matt\"\n```\n\nDas obige prüft zunächst, ob `.name` leer ist. Falls nicht, wird dieser Wert\nzurückgegeben. Falls er _leer ist_, wertet `coalesce` `.parent.name` auf\nLeerheit aus. Wenn schließlich sowohl `.name` als auch `.parent.name` leer\nsind, wird `Matt` zurückgegeben.\n\n### ternary\n\nDie Funktion `ternary` nimmt zwei Werte und einen Testwert. Wenn der Testwert\n`true` ist, wird der erste Wert zurückgegeben. Wenn der Testwert leer ist, wird\nder zweite Wert zurückgegeben. Dies ähnelt dem ternären Operator in C und\nanderen Programmiersprachen.\n\n#### true-Testwert\n\n```\nternary \"foo\" \"bar\" true\n```\n\noder\n\n```\ntrue | ternary \"foo\" \"bar\"\n```\n\nDas obige gibt `\"foo\"` zurück.\n\n#### false-Testwert\n\n```\nternary \"foo\" \"bar\" false\n```\n\noder\n\n```\nfalse | ternary \"foo\" \"bar\"\n```\n\nDas obige gibt `\"bar\"` zurück.\n\n## String-Funktionen\n\nHelm enthält die folgenden String-Funktionen: [abbrev](#abbrev),\n[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat),\n[contains](#contains), [hasPrefix](#hasprefix-und-hassuffix),\n[hasSuffix](#hasprefix-und-hassuffix), [indent](#indent), [initials](#initials),\n[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent),\n[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf),\n[println](#println), [quote](#quote-und-squote),\n[randAlpha](#randalphanum-randalpha-randnumeric-und-randascii),\n[randAlphaNum](#randalphanum-randalpha-randnumeric-und-randascii),\n[randAscii](#randalphanum-randalpha-randnumeric-und-randascii),\n[randNumeric](#randalphanum-randalpha-randnumeric-und-randascii),\n[repeat](#repeat), [replace](#replace), [shuffle](#shuffle),\n[snakecase](#snakecase), [squote](#quote-und-squote), [substr](#substr),\n[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall),\n[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc),\n[untitle](#untitle), [upper](#upper), [wrap](#wrap) und [wrapWith](#wrapwith).\n\n### print\n\nGibt einen String aus der Kombination seiner Teile zurück.\n\n```\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\nTypen, die keine Strings sind, werden nach Möglichkeit in Strings konvertiert.\n\nBeachten Sie, dass zwischen zwei nebeneinanderstehenden Argumenten, die keine\nStrings sind, ein Leerzeichen eingefügt wird.\n\n### println\n\nFunktioniert wie [print](#print), fügt aber am Ende eine neue Zeile hinzu.\n\n### printf\n\nGibt einen String basierend auf einem Formatierungsstring und den übergebenen\nArgumenten zurück.\n\n```\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\nDer zu verwendende Platzhalter hängt vom Typ des übergebenen Arguments ab.\nDies umfasst:\n\nAllgemein:\n\n* `%v` der Wert im Standardformat\n  * beim Drucken von Dicts fügt das Plus-Flag (%+v) Feldnamen hinzu\n* `%%` ein literales Prozentzeichen; verbraucht keinen Wert\n\nBoolean:\n\n* `%t` das Wort true oder false\n\nInteger:\n\n* `%b` Basis 2\n* `%c` das Zeichen, das durch den entsprechenden Unicode-Codepunkt dargestellt wird\n* `%d` Basis 10\n* `%o` Basis 8\n* `%O` Basis 8 mit 0o-Präfix\n* `%q` ein einzeln zitiertes Zeichenliteral, sicher escaped\n* `%x` Basis 16, mit Kleinbuchstaben für a-f\n* `%X` Basis 16, mit Großbuchstaben für A-F\n* `%U` Unicode-Format: U+1234; entspricht \"U+%04X\"\n\nFließkomma- und komplexe Bestandteile:\n\n* `%b` dezimale wissenschaftliche Notation mit Exponent als Zweierpotenz, z.B.\n  -123456p-78\n* `%e` wissenschaftliche Notation, z.B. -1.234456e+78\n* `%E` wissenschaftliche Notation, z.B. -1.234456E+78\n* `%f` Dezimalpunkt ohne Exponent, z.B. 123.456\n* `%F` Synonym für %f\n* `%g` %e für große Exponenten, sonst %f\n* `%G` %E für große Exponenten, sonst %F\n* `%x` hexadezimale Notation (mit dezimaler Zweierpotenz als Exponent), z.B.\n  -0x1.23abcp+20\n* `%X` hexadezimale Notation in Großbuchstaben, z.B. -0X1.23ABCP+20\n\nString und Byte-Slice (werden gleichwertig behandelt mit diesen Verben):\n\n* `%s` die nicht interpretierten Bytes des Strings oder Slice\n* `%q` ein doppelt zitierter String, sicher escaped\n* `%x` Basis 16, Kleinbuchstaben, zwei Zeichen pro Byte\n* `%X` Basis 16, Großbuchstaben, zwei Zeichen pro Byte\n\nSlice:\n\n* `%p` Adresse des 0. Elements in Basis-16-Notation mit führendem 0x\n\n### trim\n\nDie Funktion `trim` entfernt Leerzeichen von beiden Seiten eines Strings:\n\n```\ntrim \"   hello    \"\n```\n\nDas obige erzeugt `hello`\n\n### trimAll\n\nEntfernt die angegebenen Zeichen vorne und hinten aus einem String:\n\n```\ntrimAll \"$\" \"$5.00\"\n```\n\nDas obige gibt `5.00` zurück (als String).\n\n### trimPrefix\n\nEntfernt nur das Präfix aus einem String:\n\n```\ntrimPrefix \"-\" \"-hello\"\n```\n\nDas obige gibt `hello` zurück\n\n### trimSuffix\n\nEntfernt nur das Suffix aus einem String:\n\n```\ntrimSuffix \"-\" \"hello-\"\n```\n\nDas obige gibt `hello` zurück\n\n### lower\n\nKonvertiert den gesamten String in Kleinbuchstaben:\n\n```\nlower \"HELLO\"\n```\n\nDas obige gibt `hello` zurück\n\n### upper\n\nKonvertiert den gesamten String in Großbuchstaben:\n\n```\nupper \"hello\"\n```\n\nDas obige gibt `HELLO` zurück\n\n### title\n\nKonvertiert in Titel-Schreibweise:\n\n```\ntitle \"hello world\"\n```\n\nDas obige gibt `Hello World` zurück\n\n### untitle\n\nEntfernt die Titel-Schreibweise. `untitle \"Hello World\"` erzeugt `hello world`.\n\n### repeat\n\nWiederholt einen String mehrfach:\n\n```\nrepeat 3 \"hello\"\n```\n\nDas obige gibt `hellohellohello` zurück\n\n### substr\n\nHolt einen Teilstring aus einem String. Es werden drei Parameter benötigt:\n\n- start (int)\n- end (int)\n- string (string)\n\n```\nsubstr 0 5 \"hello world\"\n```\n\nDas obige gibt `hello` zurück\n\n### nospace\n\nEntfernt alle Leerzeichen aus einem String.\n\n```\nnospace \"hello w o r l d\"\n```\n\nDas obige gibt `helloworld` zurück\n\n### trunc\n\nKürzt einen String\n\n```\ntrunc 5 \"hello world\"\n```\n\nDas obige erzeugt `hello`.\n\n```\ntrunc -5 \"hello world\"\n```\n\nDas obige erzeugt `world`.\n\n### abbrev\n\nKürzt einen String mit Auslassungspunkten (`...`)\n\nParameter:\n\n- maximale Länge\n- der String\n\n```\nabbrev 5 \"hello world\"\n```\n\nDas obige gibt `he...` zurück, da die Breite der Auslassungspunkte gegen die\nmaximale Länge gerechnet wird.\n\n### abbrevboth\n\nKürzt auf beiden Seiten:\n\n```\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\nDas obige erzeugt `...5678...`\n\nEs werden benötigt:\n\n- linker Offset\n- maximale Länge\n- der String\n\n### initials\n\nNimmt bei mehreren Wörtern den ersten Buchstaben jedes Wortes und kombiniert sie.\n\n```\ninitials \"First Try\"\n```\n\nDas obige gibt `FT` zurück\n\n### randAlphaNum, randAlpha, randNumeric und randAscii\n\nDiese vier Funktionen generieren kryptografisch sichere (verwendet\n```crypto/rand```) zufällige Strings, aber mit unterschiedlichen\nBasis-Zeichensätzen:\n\n- `randAlphaNum` verwendet `0-9a-zA-Z`\n- `randAlpha` verwendet `a-zA-Z`\n- `randNumeric` verwendet `0-9`\n- `randAscii` verwendet alle druckbaren ASCII-Zeichen\n\nJede nimmt einen Parameter: die ganzzahlige Länge des Strings.\n\n```\nrandNumeric 3\n```\n\nDas obige erzeugt einen zufälligen String mit drei Ziffern.\n\n### wrap\n\nUmbricht Text bei einer angegebenen Spaltenanzahl:\n\n```\nwrap 80 $someText\n```\n\nDas obige umbricht den String in `$someText` bei 80 Spalten.\n\n### wrapWith\n\n`wrapWith` funktioniert wie `wrap`, aber erlaubt die Angabe des\nUmbruch-Strings. (`wrap` verwendet `\\n`)\n\n```\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\nDas obige erzeugt `Hello World` (wobei das Leerzeichen ein ASCII-Tabulatorzeichen ist)\n\n### contains\n\nPrüft, ob ein String in einem anderen enthalten ist:\n\n```\ncontains \"cat\" \"catch\"\n```\n\nDas obige gibt `true` zurück, weil `catch` das Wort `cat` enthält.\n\n### hasPrefix und hasSuffix\n\nDie Funktionen `hasPrefix` und `hasSuffix` prüfen, ob ein String ein bestimmtes\nPräfix oder Suffix hat:\n\n```\nhasPrefix \"cat\" \"catch\"\n```\n\nDas obige gibt `true` zurück, weil `catch` das Präfix `cat` hat.\n\n### quote und squote\n\nDiese Funktionen umschließen einen String mit doppelten Anführungszeichen\n(`quote`) oder einfachen Anführungszeichen (`squote`).\n\n### cat\n\nDie Funktion `cat` verkettet mehrere Strings zu einem und trennt sie durch\nLeerzeichen:\n\n```\ncat \"hello\" \"beautiful\" \"world\"\n```\n\nDas obige erzeugt `hello beautiful world`\n\n### indent\n\nDie Funktion `indent` rückt jede Zeile in einem gegebenen String um die\nangegebene Einrückungsbreite ein. Dies ist nützlich beim Ausrichten von\nmehrzeiligen Strings:\n\n```\nindent 4 $lots_of_text\n```\n\nDas obige rückt jede Textzeile um 4 Leerzeichen ein.\n\n### nindent\n\nDie Funktion `nindent` ist identisch mit der Funktion indent, stellt aber eine\nneue Zeile an den Anfang des Strings.\n\n```\nnindent 4 $lots_of_text\n```\n\nDas obige rückt jede Textzeile um 4 Leerzeichen ein und fügt am Anfang eine\nneue Zeile hinzu.\n\n### replace\n\nFührt eine einfache String-Ersetzung durch.\n\nEs werden drei Argumente benötigt:\n\n- zu ersetzender String\n- Ersetzungs-String\n- Quell-String\n\n```\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\nDas obige erzeugt `I-Am-Henry-VIII`\n\n### plural\n\nPluralisiert einen String.\n\n```\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\nWenn die Länge des Strings 1 ist, wird das erste Argument ausgegeben (`one\nanchovy`). Andernfalls wird das zweite Argument ausgegeben (`many anchovies`).\n\nDie Argumente sind:\n\n- Singular-String\n- Plural-String\n- Länge als Integer\n\nHINWEIS: Helm unterstützt derzeit keine Sprachen mit komplexeren\nPluralbildungsregeln. Und `0` wird als Plural betrachtet, weil die englische\nSprache es so behandelt (`zero anchovies`).\n\n### snakecase\n\nKonvertiert einen String von camelCase in snake_case.\n\n```\nsnakecase \"FirstName\"\n```\n\nDas obige erzeugt `first_name`.\n\n### camelcase\n\nKonvertiert einen String von snake_case in CamelCase.\n\n```\ncamelcase \"http_server\"\n```\n\nDas obige erzeugt `HttpServer`.\n\n### kebabcase\n\nKonvertiert einen String von camelCase in kebab-case.\n\n```\nkebabcase \"FirstName\"\n```\n\nDas obige erzeugt `first-name`.\n\n### swapcase\n\nTauscht die Groß-/Kleinschreibung eines Strings mit einem wortbasierten\nAlgorithmus.\n\nKonvertierungsalgorithmus:\n\n- Großbuchstabe wird zu Kleinbuchstabe\n- Titelbuchstabe wird zu Kleinbuchstabe\n- Kleinbuchstabe nach Leerzeichen oder am Anfang wird zu Titelbuchstabe\n- Andere Kleinbuchstaben werden zu Großbuchstaben\n- Leerzeichen wird durch unicode.IsSpace(char) definiert\n\n```\nswapcase \"This Is A.Test\"\n```\n\nDas obige erzeugt `tHIS iS a.tEST`.\n\n### shuffle\n\nMischt einen String.\n\n```\nshuffle \"hello\"\n```\n\nDas obige randomisiert die Buchstaben in `hello` und erzeugt möglicherweise\n`oelhl`.\n\n## Typkonvertierungsfunktionen\n\nDie folgenden Typkonvertierungsfunktionen werden von Helm bereitgestellt:\n\n- `atoi`: Konvertiert einen String in einen Integer.\n- `float64`: Konvertiert in einen `float64`.\n- `int`: Konvertiert in einen `int` mit der Systembreite.\n- `int64`: Konvertiert in einen `int64`.\n- `toDecimal`: Konvertiert eine Unix-Oktalzahl in einen `int64`.\n- `toString`: Konvertiert in einen String.\n- `toStrings`: Konvertiert eine Liste, Slice oder Array in eine Liste von Strings.\n- `toJson` (`mustToJson`): Konvertiert Liste, Slice, Array, Dict oder Objekt in JSON.\n- `toPrettyJson` (`mustToPrettyJson`): Konvertiert Liste, Slice, Array, Dict\n  oder Objekt in eingerücktes JSON.\n- `toRawJson` (`mustToRawJson`): Konvertiert Liste, Slice, Array, Dict oder\n  Objekt in JSON mit nicht-escaped HTML-Zeichen.\n- `fromYaml`: Konvertiert einen YAML-String in ein Objekt.\n- `fromJson`: Konvertiert einen JSON-String in ein Objekt.\n- `fromJsonArray`: Konvertiert ein JSON-Array in eine Liste.\n- `toYaml`: Konvertiert Liste, Slice, Array, Dict oder Objekt in eingerücktes\n  YAML. Diese Funktion entspricht der GoLang yaml.Marshal-Funktion, siehe Dokumentation:\n  https://pkg.go.dev/gopkg.in/yaml.v2#Marshal\n- `toYamlPretty`: Konvertiert Liste, Slice, Array, Dict oder Objekt in\n  eingerücktes YAML. Entspricht `toYaml`, rückt aber Listen zusätzlich um 2\n  Leerzeichen ein.\n- `toToml`: Konvertiert Liste, Slice, Array, Dict oder Objekt in TOML.\n- `fromYamlArray`: Konvertiert ein YAML-Array in eine Liste.\n\nNur `atoi` erfordert, dass die Eingabe einen bestimmten Typ hat. Die anderen\nversuchen, von jedem Typ in den Zieltyp zu konvertieren. Zum Beispiel kann\n`int64` Floats in Ints und auch Strings in Ints konvertieren.\n\n### toStrings\n\nErzeugt bei einer listenähnlichen Sammlung eine Liste von Strings.\n\n```\nlist 1 2 3 | toStrings\n```\n\nDas obige konvertiert `1` in `\"1\"`, `2` in `\"2\"` usw. und gibt sie dann als\nListe zurück.\n\n### toDecimal\n\nErzeugt aus einer Unix-Oktal-Berechtigung eine Dezimalzahl.\n\n```\n\"0777\" | toDecimal\n```\n\nDas obige konvertiert `0777` in `511` und gibt den Wert als int64 zurück.\n\n### toJson, mustToJson\n\nDie Funktion `toJson` kodiert ein Element in einen JSON-String. Wenn das\nElement nicht in JSON konvertiert werden kann, gibt die Funktion einen leeren\nString zurück. `mustToJson` gibt einen Fehler zurück, falls das Element nicht\nin JSON kodiert werden kann.\n\n```\ntoJson .Item\n```\n\nDas obige gibt die JSON-String-Darstellung von `.Item` zurück.\n\n### toPrettyJson, mustToPrettyJson\n\nDie Funktion `toPrettyJson` kodiert ein Element in einen formatierten\n(eingerückten) JSON-String.\n\n```\ntoPrettyJson .Item\n```\n\nDas obige gibt die eingerückte JSON-String-Darstellung von `.Item` zurück.\n\n### toRawJson, mustToRawJson\n\nDie Funktion `toRawJson` kodiert ein Element in einen JSON-String mit\nnicht-escaped HTML-Zeichen.\n\n```\ntoRawJson .Item\n```\n\nDas obige gibt die nicht-escaped JSON-String-Darstellung von `.Item` zurück.\n\n### fromYaml\n\nDie Funktion `fromYaml` nimmt einen YAML-String und gibt ein Objekt zurück,\ndas in Templates verwendet werden kann.\n\n`Datei unter: yamls/person.yaml`\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n```yaml\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\nDie Funktion `fromJson` nimmt einen JSON-String und gibt ein Objekt zurück,\ndas in Templates verwendet werden kann.\n\n`Datei unter: jsons/person.json`\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n\n### fromJsonArray\n\nDie Funktion `fromJsonArray` nimmt ein JSON-Array und gibt eine Liste zurück,\ndie in Templates verwendet werden kann.\n\n`Datei unter: jsons/people.json`\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml, toYamlPretty\n\nDie Funktionen `toYaml` und `toYamlPretty` kodieren ein Objekt (Liste, Slice,\nArray, Dict oder Objekt) in einen eingerückten YAML-String.\n\n> Beachten Sie, dass `toYamlPretty` funktional äquivalent ist, aber YAML mit\n> zusätzlicher Einrückung für Listenelemente ausgibt\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\nDie Funktion `fromYamlArray` nimmt ein YAML-Array und gibt eine Liste zurück,\ndie in Templates verwendet werden kann.\n\n`Datei unter: yamls/people.yml`\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n\n## Reguläre Ausdrücke\n\nHelm enthält die folgenden Funktionen für reguläre Ausdrücke: [regexFind\n(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll\n(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch\n(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll\n(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall),\n[regexReplaceAllLiteral\n(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral),\n[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\nGibt `true` zurück, wenn der Eingabe-String eine Übereinstimmung mit dem\nregulären Ausdruck enthält.\n\n```\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\nDas obige erzeugt `true`\n\n`regexMatch` löst einen Panic aus, wenn ein Problem auftritt, und\n`mustRegexMatch` gibt einen Fehler an die Template-Engine zurück, wenn ein\nProblem auftritt.\n\n### regexFindAll, mustRegexFindAll\n\nGibt eine Liste aller Übereinstimmungen des regulären Ausdrucks im\nEingabe-String zurück. Der letzte Parameter n bestimmt die Anzahl der\nzurückzugebenden Teilstrings, wobei -1 bedeutet, dass alle Übereinstimmungen\nzurückgegeben werden.\n\n```\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\nDas obige erzeugt `[2 4 6 8]`\n\n`regexFindAll` löst einen Panic aus, wenn ein Problem auftritt, und\n`mustRegexFindAll` gibt einen Fehler an die Template-Engine zurück, wenn ein\nProblem auftritt.\n\n### regexFind, mustRegexFind\n\nGibt die erste (am weitesten links stehende) Übereinstimmung des regulären\nAusdrucks im Eingabe-String zurück.\n\n```\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\nDas obige erzeugt `d1`\n\n`regexFind` löst einen Panic aus, wenn ein Problem auftritt, und\n`mustRegexFind` gibt einen Fehler an die Template-Engine zurück, wenn ein\nProblem auftritt.\n\n### regexReplaceAll, mustRegexReplaceAll\n\nGibt eine Kopie des Eingabe-Strings zurück, wobei Übereinstimmungen des\nregulären Ausdrucks durch den Ersetzungs-String ersetzt werden. Innerhalb des\nErsetzungs-Strings werden $-Zeichen wie bei Expand interpretiert, sodass z.B.\n$1 den Text der ersten Unterübereinstimmung darstellt. Das erste Argument ist\n`<pattern>`, das zweite ist `<input>` und das dritte ist `<replacement>`.\n\n```\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\nDas obige erzeugt `-W-xxW-`\n\n`regexReplaceAll` löst einen Panic aus, wenn ein Problem auftritt, und\n`mustRegexReplaceAll` gibt einen Fehler an die Template-Engine zurück, wenn ein\nProblem auftritt.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\nGibt eine Kopie des Eingabe-Strings zurück, wobei Übereinstimmungen des\nregulären Ausdrucks durch den Ersetzungs-String ersetzt werden. Der\nErsetzungs-String wird direkt eingesetzt, ohne Expand zu verwenden. Das erste\nArgument ist `<pattern>`, das zweite ist `<input>` und das dritte ist\n`<replacement>`.\n\n```\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\nDas obige erzeugt `-${1}-${1}-`\n\n`regexReplaceAllLiteral` löst einen Panic aus, wenn ein Problem auftritt, und\n`mustRegexReplaceAllLiteral` gibt einen Fehler an die Template-Engine zurück,\nwenn ein Problem auftritt.\n\n### regexSplit, mustRegexSplit\n\nTeilt den Eingabe-String in Teilstrings auf, die durch den Ausdruck getrennt\nsind, und gibt eine Liste der Teilstrings zwischen diesen\nAusdrucksübereinstimmungen zurück. Der letzte Parameter `n` bestimmt die Anzahl\nder zurückzugebenden Teilstrings, wobei `-1` bedeutet, dass alle\nÜbereinstimmungen zurückgegeben werden.\n\n```\nregexSplit \"z+\" \"pizza\" -1\n```\n\nDas obige erzeugt `[pi a]`\n\n`regexSplit` löst einen Panic aus, wenn ein Problem auftritt, und\n`mustRegexSplit` gibt einen Fehler an die Template-Engine zurück, wenn ein\nProblem auftritt.\n\n## Kryptografie- und Sicherheitsfunktionen\n\nHelm bietet einige fortgeschrittene kryptografische Funktionen. Diese umfassen\n[adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert),\n[decryptAES](#decryptaes), [derivePassword](#derivepassword),\n[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey),\n[genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert),\n[htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum) und\n[sha256sum](#sha256sum).\n\n### sha1sum\n\nDie Funktion `sha1sum` empfängt einen String und berechnet dessen SHA1-Digest.\n\n```\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\nDie Funktion `sha256sum` empfängt einen String und berechnet dessen SHA256-Digest.\n\n```\nsha256sum \"Hello world!\"\n```\n\nDas obige berechnet die SHA-256-Summe in einem \"ASCII-armored\"-Format, das\nsicher gedruckt werden kann.\n\n### adler32sum\n\nDie Funktion `adler32sum` empfängt einen String und berechnet dessen\nAdler-32-Prüfsumme.\n\n```\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\nDie Funktion `htpasswd` nimmt einen `username` und ein `password` und erzeugt\neinen `bcrypt`-Hash des Passworts. Das Ergebnis kann für die\nBasis-Authentifizierung auf einem [Apache HTTP\nServer](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic)\nverwendet werden.\n\n```\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nBeachten Sie, dass es unsicher ist, das Passwort direkt im Template zu speichern.\n\n### randBytes\n\nDie Funktion randBytes akzeptiert eine Anzahl N und erzeugt eine\nkryptografisch sichere (verwendet crypto/rand) zufällige Sequenz von N Bytes.\nDie Sequenz wird als base64-kodierter String zurückgegeben.\n\n```\nrandBytes 24\n```\n\n### derivePassword\n\nDie Funktion `derivePassword` kann verwendet werden, um ein bestimmtes Passwort\nbasierend auf einigen gemeinsamen \"Master-Passwort\"-Beschränkungen abzuleiten.\nDer Algorithmus dafür ist [gut\nspezifiziert](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf).\n\n```\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nBeachten Sie, dass es als unsicher gilt, die Teile direkt im Template zu speichern.\n\n### genPrivateKey\n\nDie Funktion `genPrivateKey` erzeugt einen neuen privaten Schlüssel, der in\neinen PEM-Block kodiert ist.\n\nSie nimmt einen der folgenden Werte als ersten Parameter:\n\n- `ecdsa`: Erzeugt einen elliptischen Kurven-DSA-Schlüssel (P256)\n- `dsa`: Erzeugt einen DSA-Schlüssel (L2048N256)\n- `rsa`: Erzeugt einen RSA-4096-Schlüssel\n\n### buildCustomCert\n\nDie Funktion `buildCustomCert` ermöglicht die Anpassung des Zertifikats.\n\nSie nimmt die folgenden String-Parameter:\n\n- Ein base64-kodiertes Zertifikat im PEM-Format\n- Ein base64-kodierter privater Schlüssel im PEM-Format\n\nSie gibt ein Zertifikatsobjekt mit den folgenden Attributen zurück:\n\n- `Cert`: Ein PEM-kodiertes Zertifikat\n- `Key`: Ein PEM-kodierter privater Schlüssel\n\nBeispiel:\n\n```\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\nBeachten Sie, dass das zurückgegebene Objekt an die Funktion `genSignedCert`\nübergeben werden kann, um ein Zertifikat mit dieser CA zu signieren.\n\n### genCA\n\nDie Funktion `genCA` erzeugt ein neues, selbstsigniertes\nx509-Zertifizierungsstellenzertifikat.\n\nSie nimmt die folgenden Parameter:\n\n- Common Name (cn) des Subjekts\n- Gültigkeitsdauer des Zertifikats in Tagen\n\nSie gibt ein Objekt mit den folgenden Attributen zurück:\n\n- `Cert`: Ein PEM-kodiertes Zertifikat\n- `Key`: Ein PEM-kodierter privater Schlüssel\n\nBeispiel:\n\n```\n$ca := genCA \"foo-ca\" 365\n```\n\nBeachten Sie, dass das zurückgegebene Objekt an die Funktion `genSignedCert`\nübergeben werden kann, um ein Zertifikat mit dieser CA zu signieren.\n\n### genSelfSignedCert\n\nDie Funktion `genSelfSignedCert` erzeugt ein neues, selbstsigniertes\nx509-Zertifikat.\n\nSie nimmt die folgenden Parameter:\n\n- Common Name (cn) des Subjekts\n- Optionale Liste von IPs; kann nil sein\n- Optionale Liste alternativer DNS-Namen; kann nil sein\n- Gültigkeitsdauer des Zertifikats in Tagen\n\nSie gibt ein Objekt mit den folgenden Attributen zurück:\n\n- `Cert`: Ein PEM-kodiertes Zertifikat\n- `Key`: Ein PEM-kodierter privater Schlüssel\n\nBeispiel:\n\n```\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\nDie Funktion `genSignedCert` erzeugt ein neues x509-Zertifikat, das von der\nangegebenen CA signiert ist.\n\nSie nimmt die folgenden Parameter:\n\n- Common Name (cn) des Subjekts\n- Optionale Liste von IPs; kann nil sein\n- Optionale Liste alternativer DNS-Namen; kann nil sein\n- Gültigkeitsdauer des Zertifikats in Tagen\n- CA (siehe `genCA`)\n\nBeispiel:\n\n```\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\nDie Funktion `encryptAES` verschlüsselt Text mit AES-256 CBC und gibt einen\nbase64-kodierten String zurück.\n\n```\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\nDie Funktion `decryptAES` empfängt einen base64-String, der mit dem\nAES-256-CBC-Algorithmus kodiert wurde, und gibt den entschlüsselten Text zurück.\n\n```\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Datumsfunktionen\n\nHelm enthält die folgenden Datumsfunktionen, die Sie in Templates verwenden\nkönnen: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify\n(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration),\n[durationRound](#durationround), [htmlDate](#htmldate),\n[htmlDateInZone](#htmldateinzone), [now](#now), [toDate\n(mustToDate)](#todate-musttodate) und [unixEpoch](#unixepoch).\n\n### now\n\nDas aktuelle Datum/Uhrzeit. Verwenden Sie dies in Verbindung mit anderen\nDatumsfunktionen.\n\n### ago\n\nDie Funktion `ago` gibt die Dauer seit einer Zeit zurück. Jetzt in\nSekundenauflösung.\n\n```\nago .CreatedAt\n```\n\ngibt im `time.Duration` String()-Format zurück\n\n```\n2h34m7s\n```\n\n### date\n\nDie Funktion `date` formatiert ein Datum.\n\nFormatiert das Datum als JAHR-MONAT-TAG:\n\n```\nnow | date \"2006-01-02\"\n```\n\nDie Datumsformatierung in Go ist [etwas\nanders](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\nKurz gesagt, nehmen Sie dies als Basisdatum:\n\n```\nMon Jan 2 15:04:05 MST 2006\n```\n\nSchreiben Sie es in dem Format, das Sie möchten. Oben ist `2006-01-02` dasselbe\nDatum, aber in dem gewünschten Format.\n\n### dateInZone\n\nWie `date`, aber mit einer Zeitzone.\n\n```\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\nFormatiert eine gegebene Anzahl von Sekunden als `time.Duration`.\n\nDies gibt 1m35s zurück\n\n```\nduration \"95\"\n```\n\n### durationRound\n\nRundet eine gegebene Dauer auf die signifikanteste Einheit. Strings und\n`time.Duration` werden als Dauer geparst, während eine `time.Time` als die\nDauer seit diesem Zeitpunkt berechnet wird.\n\nDies gibt 2h zurück\n\n```\ndurationRound \"2h10m5s\"\n```\n\nDies gibt 3mo zurück\n\n```\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\nGibt die Sekunden seit der Unix-Epoche für eine `time.Time` zurück.\n\n```\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\nDie Funktion `dateModify` nimmt eine Modifikation und ein Datum und gibt den\nZeitstempel zurück.\n\nSubtrahiert eine Stunde und dreißig Minuten von der aktuellen Zeit:\n\n```\nnow | dateModify \"-1.5h\"\n```\n\nWenn das Modifikationsformat falsch ist, gibt `dateModify` das Datum unverändert\nzurück. `mustDateModify` gibt andernfalls einen Fehler zurück.\n\n### htmlDate\n\nDie Funktion `htmlDate` formatiert ein Datum zum Einfügen in ein\nHTML-Datumsauswahl-Eingabefeld.\n\n```\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nWie htmlDate, aber mit einer Zeitzone.\n\n```\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\n`toDate` konvertiert einen String in ein Datum. Das erste Argument ist das\nDatumslayout und das zweite der Datums-String. Wenn der String nicht\nkonvertiert werden kann, wird der Nullwert zurückgegeben. `mustToDate` gibt\neinen Fehler zurück, falls der String nicht konvertiert werden kann.\n\nDies ist nützlich, wenn Sie einen Datums-String in ein anderes Format\nkonvertieren möchten (mit Pipe). Das folgende Beispiel konvertiert \"2017-12-31\"\nin \"31/12/2017\".\n\n```\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Dictionaries und Dict-Funktionen\n\nHelm bietet einen Schlüssel/Wert-Speichertyp namens `dict` (kurz für\n\"Dictionary\", wie in Python). Ein `dict` ist ein _ungeordneter_ Typ.\n\nDer Schlüssel eines Dictionary **muss ein String sein**. Der Wert kann jedoch\njeden Typ haben, einschließlich eines anderen `dict` oder einer `list`.\n\nIm Gegensatz zu `list`s sind `dict`s nicht unveränderlich. Die Funktionen `set`\nund `unset` ändern den Inhalt eines Dictionary.\n\nHelm bietet die folgenden Funktionen zur Arbeit mit Dicts: [deepCopy\n(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get),\n[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge),\n[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite),\n[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) und\n[values](#values).\n\n### dict\n\nDas Erstellen von Dictionaries erfolgt durch Aufrufen der Funktion `dict` und\nÜbergeben einer Liste von Paaren.\n\nDas Folgende erstellt ein Dictionary mit drei Elementen:\n\n```\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nHolt bei gegebenem Map und Schlüssel den Wert aus dem Map.\n\n```\nget $myDict \"name1\"\n```\n\nDas obige gibt `\"value1\"` zurück\n\nBeachten Sie, dass diese Operation einfach `\"\"` zurückgibt, wenn der Schlüssel\nnicht gefunden wird. Es wird kein Fehler erzeugt.\n\n### set\n\nVerwenden Sie `set`, um ein neues Schlüssel/Wert-Paar zu einem Dictionary\nhinzuzufügen.\n\n```\n$_ := set $myDict \"name4\" \"value4\"\n```\n\nBeachten Sie, dass `set` _das Dictionary zurückgibt_ (eine Anforderung von\nGo-Template-Funktionen), daher müssen Sie den Wert möglicherweise wie oben mit\nder `$_`-Zuweisung auffangen.\n\n### unset\n\nLöscht bei gegebenem Map und Schlüssel den Schlüssel aus dem Map.\n\n```\n$_ := unset $myDict \"name4\"\n```\n\nWie bei `set` gibt dies das Dictionary zurück.\n\nBeachten Sie, dass diese Operation einfach zurückkehrt, wenn der Schlüssel\nnicht gefunden wird. Es wird kein Fehler erzeugt.\n\n### hasKey\n\nDie Funktion `hasKey` gibt `true` zurück, wenn das gegebene Dict den gegebenen\nSchlüssel enthält.\n\n```\nhasKey $myDict \"name1\"\n```\n\nWenn der Schlüssel nicht gefunden wird, gibt dies `false` zurück.\n\n### pluck\n\nDie Funktion `pluck` ermöglicht es, einen Schlüssel und mehrere Maps anzugeben\nund eine Liste aller Übereinstimmungen zu erhalten:\n\n```\npluck \"name1\" $myDict $myOtherDict\n```\n\nDas obige gibt eine `list` zurück, die jeden gefundenen Wert enthält (`[value1\notherValue1]`).\n\nWenn der gegebene Schlüssel _nicht gefunden_ wird in einem Map, hat dieses Map\nkein Element in der Liste (und die Länge der zurückgegebenen Liste ist kleiner\nals die Anzahl der Dicts im Aufruf von `pluck`).\n\nWenn der Schlüssel _gefunden_ wird, aber der Wert ein leerer Wert ist, wird\ndieser Wert eingefügt.\n\nEin gängiges Idiom in Helm-Templates ist die Verwendung von `pluck... | first`,\num den ersten passenden Schlüssel aus einer Sammlung von Dictionaries zu erhalten.\n\n### dig\n\nDie Funktion `dig` durchläuft eine verschachtelte Menge von Dicts und wählt\nSchlüssel aus einer Werteliste aus. Sie gibt einen Standardwert zurück, wenn\neiner der Schlüssel im zugehörigen Dict nicht gefunden wird.\n\n```\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\nBei einem Dict mit folgender Struktur\n```\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\nwürde das obige `\"curator\"` zurückgeben. Wenn das Dict nicht einmal ein\n`user`-Feld hätte, wäre das Ergebnis `\"guest\"`.\n\nDig kann sehr nützlich sein in Fällen, in denen Sie Schutzklauseln vermeiden\nmöchten, besonders da das `and` des Go-Template-Pakets nicht kurzschließt.\nZum Beispiel wird `and a.maybeNil a.maybeNil.iNeedThis` immer\n`a.maybeNil.iNeedThis` auswerten und einen Panic auslösen, wenn `a` kein\n`maybeNil`-Feld hat.)\n\n`dig` akzeptiert sein Dict-Argument zuletzt, um Pipelining zu unterstützen. Zum Beispiel:\n```\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\nFührt zwei oder mehr Dictionaries zu einem zusammen, wobei das\nZiel-Dictionary Vorrang hat:\n\nGegeben:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nergibt sich:\n\n```\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n```\n$newdict := merge $dest $source1 $source2\n```\n\nDies ist eine tiefe Merge-Operation, aber keine tiefe Kopier-Operation.\nVerschachtelte Objekte, die zusammengeführt werden, sind dieselbe Instanz in\nbeiden Dicts. Wenn Sie eine tiefe Kopie zusammen mit dem Merge möchten,\nverwenden Sie die Funktion `deepCopy` zusammen mit dem Merging. Zum Beispiel:\n\n```\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` gibt einen Fehler zurück, falls das Merge nicht erfolgreich ist.\n\n### mergeOverwrite, mustMergeOverwrite\n\nFührt zwei oder mehr Dictionaries zu einem zusammen, wobei der Vorrang von\n**rechts nach links** gilt, also Werte im Ziel-Dictionary überschrieben werden:\n\nGegeben:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nergibt sich:\n\n```\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nDies ist eine tiefe Merge-Operation, aber keine tiefe Kopier-Operation.\nVerschachtelte Objekte, die zusammengeführt werden, sind dieselbe Instanz in\nbeiden Dicts. Wenn Sie eine tiefe Kopie zusammen mit dem Merge möchten,\nverwenden Sie die Funktion `deepCopy` zusammen mit dem Merging. Zum Beispiel:\n\n```\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` gibt einen Fehler zurück, falls das Merge nicht\nerfolgreich ist.\n\n### keys\n\nDie Funktion `keys` gibt eine `list` aller Schlüssel in einem oder mehreren\n`dict`-Typen zurück. Da ein Dictionary _ungeordnet_ ist, sind die Schlüssel\nnicht in einer vorhersagbaren Reihenfolge. Sie können mit `sortAlpha` sortiert\nwerden.\n\n```\nkeys $myDict | sortAlpha\n```\n\nBei der Angabe mehrerer Dictionaries werden die Schlüssel verkettet. Verwenden\nSie die Funktion `uniq` zusammen mit `sortAlpha`, um eine eindeutige, sortierte\nListe von Schlüsseln zu erhalten.\n\n```\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\nDie Funktion `pick` wählt nur die angegebenen Schlüssel aus einem Dictionary\naus und erstellt ein neues `dict`.\n\n```\n$new := pick $myDict \"name1\" \"name2\"\n```\n\nDas obige gibt `{name1: value1, name2: value2}` zurück\n\n### omit\n\nDie Funktion `omit` ähnelt `pick`, gibt aber ein neues `dict` mit allen\nSchlüsseln zurück, die _nicht_ mit den angegebenen Schlüsseln übereinstimmen.\n\n```\n$new := omit $myDict \"name1\" \"name3\"\n```\n\nDas obige gibt `{name2: value2}` zurück\n\n### values\n\nDie Funktion `values` ähnelt `keys`, gibt aber eine neue `list` mit allen\nWerten des Quell-`dict` zurück (nur ein Dictionary wird unterstützt).\n\n```\n$vals := values $myDict\n```\n\nDas obige gibt `list[\"value1\", \"value2\", \"value 3\"]` zurück. Beachten Sie, dass\ndie Funktion `values` keine Garantien für die Reihenfolge des Ergebnisses gibt;\nwenn Ihnen das wichtig ist, verwenden Sie `sortAlpha`.\n\n### deepCopy, mustDeepCopy\n\nDie Funktionen `deepCopy` und `mustDeepCopy` nehmen einen Wert und erstellen\neine tiefe Kopie des Wertes. Dies umfasst Dicts und andere Strukturen.\n`deepCopy` löst einen Panic aus, wenn ein Problem auftritt, während\n`mustDeepCopy` einen Fehler an das Template-System zurückgibt, wenn ein Fehler\nauftritt.\n\n```\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### Eine Anmerkung zu Dict-Interna\n\nEin `dict` ist in Go als `map[string]interface{}` implementiert. Go-Entwickler\nkönnen `map[string]interface{}`-Werte in den Kontext übergeben, um sie für\nTemplates als `dict`s verfügbar zu machen.\n\n## Encoding-Funktionen\n\nHelm hat die folgenden Kodierungs- und Dekodierungsfunktionen:\n\n- `b64enc`/`b64dec`: Kodieren oder Dekodieren mit Base64\n- `b32enc`/`b32dec`: Kodieren oder Dekodieren mit Base32\n\n## Listen und List-Funktionen\n\nHelm bietet einen einfachen `list`-Typ, der beliebige sequentielle Datenlisten\nenthalten kann. Dies ähnelt Arrays oder Slices, aber Listen sind so konzipiert,\ndass sie als unveränderliche Datentypen verwendet werden.\n\nErstellen Sie eine Liste von Integers:\n\n```\n$myList := list 1 2 3 4 5\n```\n\nDas obige erstellt eine Liste von `[1 2 3 4 5]`.\n\nHelm bietet die folgenden List-Funktionen: [append\n(mustAppend)](#append-mustappend), [chunk](#chunk), [compact\n(mustCompact)](#compact-mustcompact), [concat](#concat), [first\n(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial\n(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast),\n[prepend (mustPrepend)](#prepend-mustprepend), [rest\n(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse),\n[seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq\n(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) und\n[without (mustWithout)](#without-mustwithout).\n\n### first, mustFirst\n\nUm das erste Element einer Liste zu erhalten, verwenden Sie `first`.\n\n`first $myList` gibt `1` zurück\n\n`first` löst einen Panic aus, wenn ein Problem auftritt, während `mustFirst`\neinen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt.\n\n### rest, mustRest\n\nUm den Rest der Liste zu erhalten (alles außer dem ersten Element), verwenden\nSie `rest`.\n\n`rest $myList` gibt `[2 3 4 5]` zurück\n\n`rest` löst einen Panic aus, wenn ein Problem auftritt, während `mustRest`\neinen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt.\n\n### last, mustLast\n\nUm das letzte Element einer Liste zu erhalten, verwenden Sie `last`:\n\n`last $myList` gibt `5` zurück. Dies entspricht ungefähr dem Umkehren einer\nListe und dem anschließenden Aufrufen von `first`.\n\n### initial, mustInitial\n\nDies ergänzt `last`, indem alle Elemente _außer_ dem letzten zurückgegeben\nwerden. `initial $myList` gibt `[1 2 3 4]` zurück.\n\n`initial` löst einen Panic aus, wenn ein Problem auftritt, während\n`mustInitial` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem\nauftritt.\n\n### append, mustAppend\n\nFügt ein neues Element zu einer bestehenden Liste hinzu und erstellt eine neue\nListe.\n\n```\n$new = append $myList 6\n```\n\nDas obige würde `$new` auf `[1 2 3 4 5 6]` setzen. `$myList` bleibt unverändert.\n\n`append` löst einen Panic aus, wenn ein Problem auftritt, während `mustAppend`\neinen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt.\n\n### prepend, mustPrepend\n\nFügt ein Element am Anfang einer Liste ein und erstellt eine neue Liste.\n\n```\nprepend $myList 0\n```\n\nDas obige würde `[0 1 2 3 4 5]` erzeugen. `$myList` bleibt unverändert.\n\n`prepend` löst einen Panic aus, wenn ein Problem auftritt, während `mustPrepend`\neinen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt.\n\n### concat\n\nVerkettet eine beliebige Anzahl von Listen zu einer.\n\n```\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\nDas obige würde `[1 2 3 4 5 6 7 8]` erzeugen. `$myList` bleibt unverändert.\n\n### reverse, mustReverse\n\nErzeugt eine neue Liste mit den umgekehrten Elementen der gegebenen Liste.\n\n```\nreverse $myList\n```\n\nDas obige würde die Liste `[5 4 3 2 1]` erzeugen.\n\n`reverse` löst einen Panic aus, wenn ein Problem auftritt, während\n`mustReverse` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem\nauftritt.\n\n### uniq, mustUniq\n\nErzeugt eine Liste, aus der alle Duplikate entfernt wurden.\n\n```\nlist 1 1 1 2 | uniq\n```\n\nDas obige würde `[1 2]` erzeugen\n\n`uniq` löst einen Panic aus, wenn ein Problem auftritt, während `mustUniq`\neinen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt.\n\n### without, mustWithout\n\nDie Funktion `without` filtert Elemente aus einer Liste heraus.\n\n```\nwithout $myList 3\n```\n\nDas obige würde `[1 2 4 5]` erzeugen\n\n`without` kann mehr als einen Filter haben:\n\n```\nwithout $myList 1 3 5\n```\n\nDas würde `[2 4]` erzeugen\n\n`without` löst einen Panic aus, wenn ein Problem auftritt, während\n`mustWithout` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem\nauftritt.\n\n### has, mustHas\n\nPrüft, ob eine Liste ein bestimmtes Element enthält.\n\n```\nhas 4 $myList\n```\n\nDas obige würde `true` zurückgeben, während `has \"hello\" $myList` `false`\nzurückgeben würde.\n\n`has` löst einen Panic aus, wenn ein Problem auftritt, während `mustHas` einen\nFehler an die Template-Engine zurückgibt, wenn ein Problem auftritt.\n\n### compact, mustCompact\n\nAkzeptiert eine Liste und entfernt Einträge mit leeren Werten.\n\n```\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` gibt eine neue Liste zurück, aus der das leere (d.h. \"\") Element\nentfernt wurde.\n\n`compact` löst einen Panic aus, wenn ein Problem auftritt, und `mustCompact`\ngibt einen Fehler an die Template-Engine zurück, wenn ein Problem auftritt.\n\n### index\n\nUm das n-te Element einer Liste zu erhalten, verwenden Sie `index list [n]`. Um\nin mehrdimensionale Listen zu indizieren, verwenden Sie `index list [n] [m] ...`\n- `index $myList 0` gibt `1` zurück. Es entspricht `myList[0]`\n- `index $myList 0 1` würde `myList[0][1]` entsprechen\n\n### slice, mustSlice\n\nUm Teilelemente einer Liste zu erhalten, verwenden Sie `slice list [n] [m]`. Es\nentspricht `list[n:m]`.\n\n- `slice $myList` gibt `[1 2 3 4 5]` zurück. Es entspricht `myList[:]`.\n- `slice $myList 3` gibt `[4 5]` zurück. Es entspricht `myList[3:]`.\n- `slice $myList 1 3` gibt `[2 3]` zurück. Es entspricht `myList[1:3]`.\n- `slice $myList 0 3` gibt `[1 2 3]` zurück. Es entspricht `myList[:3]`.\n\n`slice` löst einen Panic aus, wenn ein Problem auftritt, während `mustSlice`\neinen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt.\n\n### until\n\nDie Funktion `until` erstellt einen Bereich von Integers.\n\n```\nuntil 5\n```\n\nDas obige erzeugt die Liste `[0, 1, 2, 3, 4]`.\n\nDies ist nützlich für Schleifen mit `range $i, $e := until 5`.\n\n### untilStep\n\nWie `until` erzeugt `untilStep` eine Liste von Zähl-Integers. Aber es erlaubt\ndie Definition eines Starts, Stopps und Schritts:\n\n```\nuntilStep 3 6 2\n```\n\nDas obige erzeugt `[3 5]`, indem es bei 3 beginnt und 2 addiert, bis es gleich\noder größer als 6 ist. Dies ähnelt Pythons `range`-Funktion.\n\n### seq\n\nFunktioniert wie der Bash-Befehl `seq`.\n\n* 1 Parameter (end) - erzeugt alle Zähl-Integers zwischen 1 und `end`\n  einschließlich.\n* 2 Parameter (start, end) - erzeugt alle Zähl-Integers zwischen `start` und\n  `end` einschließlich, inkrementierend oder dekrementierend um 1.\n* 3 Parameter (start, step, end) - erzeugt alle Zähl-Integers zwischen `start`\n  und `end` einschließlich, inkrementierend oder dekrementierend um `step`.\n\n```\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\nUm eine Liste in Chunks einer gegebenen Größe zu teilen, verwenden Sie `chunk\nsize list`. Dies ist nützlich für Paginierung.\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\nDies erzeugt eine Liste von Listen `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`.\n\n## Mathematische Funktionen\n\nAlle mathematischen Funktionen arbeiten mit `int64`-Werten, sofern nicht anders\nangegeben.\n\nDie folgenden mathematischen Funktionen sind verfügbar: [add](#add),\n[add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len),\n[max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round) und\n[sub](#sub).\n\n### add\n\nSummiert Zahlen mit `add`. Akzeptiert zwei oder mehr Eingaben.\n\n```\nadd 1 2 3\n```\n\n### add1\n\nUm um 1 zu inkrementieren, verwenden Sie `add1`.\n\n### sub\n\nZum Subtrahieren verwenden Sie `sub`.\n\n### div\n\nFührt Integer-Division mit `div` durch.\n\n### mod\n\nModulo mit `mod`.\n\n### mul\n\nMultipliziert mit `mul`. Akzeptiert zwei oder mehr Eingaben.\n\n```\nmul 1 2 3\n```\n\n### max\n\nGibt den größten aus einer Reihe von Integers zurück.\n\nDies gibt `3` zurück:\n\n```\nmax 1 2 3\n```\n\n### min\n\nGibt den kleinsten aus einer Reihe von Integers zurück.\n\n`min 1 2 3` gibt `1` zurück.\n\n### len\n\nGibt die Länge des Arguments als Integer zurück.\n\n```\nlen .Arg\n```\n\n## Float-Mathematik-Funktionen\n\nAlle mathematischen Funktionen arbeiten mit `float64`-Werten.\n\n### addf\n\nSummiert Zahlen mit `addf`\n\nDies gibt `5.5` zurück:\n\n```\naddf 1.5 2 2\n```\n\n### add1f\n\nUm um 1 zu inkrementieren, verwenden Sie `add1f`\n\n### subf\n\nZum Subtrahieren verwenden Sie `subf`\n\nDies entspricht `7.5 - 2 - 3` und gibt `2.5` zurück:\n\n```\nsubf 7.5 2 3\n```\n\n### divf\n\nFührt Integer-Division mit `divf` durch\n\nDies entspricht `10 / 2 / 4` und gibt `1.25` zurück:\n\n```\ndivf 10 2 4\n```\n\n### mulf\n\nMultipliziert mit `mulf`\n\nDies gibt `6` zurück:\n\n```\nmulf 1.5 2 2\n```\n\n### maxf\n\nGibt den größten aus einer Reihe von Floats zurück:\n\nDies gibt `3` zurück:\n\n```\nmaxf 1 2.5 3\n```\n\n### minf\n\nGibt den kleinsten aus einer Reihe von Floats zurück.\n\nDies gibt `1.5` zurück:\n\n```\nminf 1.5 2 3\n```\n\n### floor\n\nGibt den größten Float-Wert zurück, der kleiner oder gleich dem Eingabewert ist.\n\n`floor 123.9999` gibt `123.0` zurück.\n\n### ceil\n\nGibt den größten Float-Wert zurück, der größer oder gleich dem Eingabewert ist.\n\n`ceil 123.001` gibt `124.0` zurück.\n\n### round\n\nGibt einen Float-Wert zurück, bei dem der Rest auf die angegebene Anzahl von\nNachkommastellen gerundet ist.\n\n`round 123.555555 3` gibt `123.556` zurück.\n\n## Netzwerk-Funktionen\n\nHelm hat eine einzige Netzwerk-Funktion, `getHostByName`.\n\nDie Funktion `getHostByName` empfängt einen Domainnamen und gibt die\nIP-Adresse zurück.\n\n`getHostByName \"www.google.com\"` würde die entsprechende IP-Adresse von\n`www.google.com` zurückgeben.\n\nDiese Funktion erfordert, dass die Option `--enable-dns` an der\nHelm-Kommandozeile übergeben wird.\n\n## Dateipfad-Funktionen\n\nObwohl Helm-Template-Funktionen keinen Zugriff auf das Dateisystem gewähren,\nbieten sie Funktionen für die Arbeit mit Strings, die Dateipfad-Konventionen\nfolgen. Diese umfassen [base](#base), [clean](#clean), [dir](#dir), [ext](#ext)\nund [isAbs](#isabs).\n\n### base\n\nGibt das letzte Element eines Pfades zurück.\n\n```\nbase \"foo/bar/baz\"\n```\n\nDas obige gibt \"baz\" aus.\n\n### dir\n\nGibt das Verzeichnis zurück und entfernt den letzten Teil des Pfades. Also gibt\n`dir \"foo/bar/baz\"` `foo/bar` zurück.\n\n### clean\n\nBereinigt einen Pfad.\n\n```\nclean \"foo/bar/../baz\"\n```\n\nDas obige löst das `..` auf und gibt `foo/baz` zurück.\n\n### ext\n\nGibt die Dateierweiterung zurück.\n\n```\next \"foo.bar\"\n```\n\nDas obige gibt `.bar` zurück.\n\n### isAbs\n\nUm zu prüfen, ob ein Dateipfad absolut ist, verwenden Sie `isAbs`.\n\n## Reflection-Funktionen\n\nHelm bietet grundlegende Reflection-Tools. Diese helfen fortgeschrittenen\nTemplate-Entwicklern, die zugrunde liegenden Go-Typinformationen für einen\nbestimmten Wert zu verstehen. Helm ist in Go geschrieben und streng typisiert.\nDas Typsystem gilt auch innerhalb von Templates.\n\nGo hat mehrere primitive _Arten_, wie `string`, `slice`, `int64` und `bool`.\n\nGo hat ein offenes _Typ_-System, das es Entwicklern ermöglicht, eigene Typen zu\nerstellen.\n\nHelm bietet eine Reihe von Funktionen für jede über [Kind-Funktionen](#kind-funktionen)\nund [Type-Funktionen](#type-funktionen). Eine [deepEqual](#deepequal)-Funktion\nwird ebenfalls bereitgestellt, um zwei Werte zu vergleichen.\n\n### Kind-Funktionen\n\nEs gibt zwei Kind-Funktionen: `kindOf` gibt die Art eines Objekts zurück.\n\n```\nkindOf \"hello\"\n```\n\nDas obige würde `string` zurückgeben. Für einfache Tests (wie in `if`-Blöcken)\nkönnen Sie mit der Funktion `kindIs` prüfen, ob ein Wert eine bestimmte Art hat:\n\n```\nkindIs \"int\" 123\n```\n\nDas obige gibt `true` zurück.\n\n### Type-Funktionen\n\nTypen sind etwas schwieriger zu handhaben, daher gibt es drei verschiedene\nFunktionen:\n\n- `typeOf` gibt den zugrunde liegenden Typ eines Wertes zurück: `typeOf $foo`\n- `typeIs` ist wie `kindIs`, aber für Typen: `typeIs \"*io.Buffer\" $myVal`\n- `typeIsLike` funktioniert wie `typeIs`, dereferenziert aber auch Pointer\n\n**Hinweis:** Keine dieser Funktionen kann testen, ob etwas ein bestimmtes\nInterface implementiert, da dies erfordern würde, das Interface vorab zu\nkompilieren.\n\n### deepEqual\n\n`deepEqual` gibt true zurück, wenn zwei Werte [\"tief\ngleich\"](https://golang.org/pkg/reflect/#DeepEqual) sind.\n\nFunktioniert auch für nicht-primitive Typen (im Gegensatz zum eingebauten `eq`).\n\n```\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\nDas obige gibt `true` zurück.\n\n## Semantische Versionsfunktionen\n\nEinige Versionsschemata sind leicht parsebar und vergleichbar. Helm bietet\nFunktionen für die Arbeit mit [SemVer 2](http://semver.org)-Versionen. Diese\numfassen [semver](#semver) und [semverCompare](#semvercompare). Im Folgenden\nfinden Sie auch Details zur Verwendung von Bereichen für Vergleiche.\n\n### semver\n\nDie Funktion `semver` parst einen String in eine Semantische Version:\n\n```\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_Wenn der Parser fehlschlägt, wird die Template-Ausführung mit einem Fehler\nangehalten._\n\nAn diesem Punkt ist `$version` ein Pointer auf ein `Version`-Objekt mit den\nfolgenden Eigenschaften:\n\n- `$version.Major`: Die Hauptversionsnummer (`1` oben)\n- `$version.Minor`: Die Nebenversionsnummer (`2` oben)\n- `$version.Patch`: Die Patch-Nummer (`3` oben)\n- `$version.Prerelease`: Das Prerelease (`alpha.1` oben)\n- `$version.Metadata`: Die Build-Metadaten (`123` oben)\n- `$version.Original`: Die Originalversion als String\n\nZusätzlich können Sie eine `Version` mit einer anderen `Version` mithilfe der\n`Compare`-Funktion vergleichen:\n\n```\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\nDas obige gibt `-1` zurück.\n\nDie Rückgabewerte sind:\n\n- `-1` wenn die gegebene Semver größer ist als die Semver, deren `Compare`-Methode\n  aufgerufen wurde\n- `1` wenn die Version, deren `Compare`-Funktion aufgerufen wurde, größer ist.\n- `0` wenn sie dieselbe Version sind\n\n(Beachten Sie, dass in SemVer das `Metadata`-Feld bei Versionsvergleichen nicht\nverglichen wird.)\n\n### semverCompare\n\nEine robustere Vergleichsfunktion wird als `semverCompare` bereitgestellt. Diese\nVersion unterstützt Versionsbereiche:\n\n- `semverCompare \"1.2.3\" \"1.2.3\"` prüft auf eine exakte Übereinstimmung\n- `semverCompare \"~1.2.0\" \"1.2.3\"` prüft, ob die Haupt- und Nebenversionen\n  übereinstimmen und ob die Patch-Nummer der zweiten Version _größer oder\n  gleich_ dem ersten Parameter ist.\n\nDie SemVer-Funktionen verwenden die [Masterminds\nsemver-Bibliothek](https://github.com/Masterminds/semver) von den Machern von\nSprig.\n\n### Einfache Vergleiche\n\nEs gibt zwei Elemente bei den Vergleichen. Erstens ist ein Vergleichs-String\neine Liste von durch Leerzeichen oder Kommas getrennten AND-Vergleichen. Diese\nwerden dann durch || (OR)-Vergleiche getrennt. Zum Beispiel sucht `\">= 1.2 <\n3.0.0 || >= 4.2.3\"` nach einem Vergleich, der größer oder gleich 1.2 und kleiner\nals 3.0.0 ist oder größer oder gleich 4.2.3 ist.\n\nDie grundlegenden Vergleiche sind:\n\n- `=`: gleich (Alias für keinen Operator)\n- `!=`: ungleich\n- `>`: größer als\n- `<`: kleiner als\n- `>=`: größer oder gleich\n- `<=`: kleiner oder gleich\n\n### Arbeiten mit Prerelease-Versionen\n\nPrereleases sind, für diejenigen, die damit nicht vertraut sind, für\nSoftware-Releases vor stabilen oder allgemein verfügbaren Releases gedacht.\nBeispiele für Prereleases sind Entwicklungs-, Alpha-, Beta- und\nRelease-Candidate-Releases. Ein Prerelease kann eine Version wie `1.2.3-beta.1`\nsein, während der stabile Release `1.2.3` wäre. In der Rangfolge kommen\nPrereleases vor ihren zugehörigen Releases. In diesem Beispiel `1.2.3-beta.1 <\n1.2.3`.\n\nGemäß der Semantic-Version-Spezifikation sind Prereleases möglicherweise nicht\nAPI-kompatibel mit ihrem Release-Gegenstück. Es heißt:\n\n> Eine Prerelease-Version zeigt an, dass die Version instabil ist und\n> möglicherweise nicht die beabsichtigten Kompatibilitätsanforderungen erfüllt,\n> wie sie durch ihre zugehörige normale Version gekennzeichnet sind.\n\nSemVer-Vergleiche mit Constraints ohne Prerelease-Vergleicher überspringen\nPrerelease-Versionen. Zum Beispiel überspringt `>=1.2.3` Prereleases beim\nDurchsuchen einer Liste von Releases, während `>=1.2.3-0` Prereleases\nauswertet und findet.\n\nDer Grund für die `0` als Prerelease-Version im Beispielvergleich ist, dass\nPrereleases nur ASCII-alphanumerische Zeichen und Bindestriche (zusammen mit\n`.`-Trennzeichen) enthalten können, gemäß Spezifikation. Die Sortierung erfolgt\nin ASCII-Sortierreihenfolge, ebenfalls gemäß Spezifikation. Das niedrigste\nZeichen ist eine `0` in der ASCII-Sortierreihenfolge (siehe eine\n[ASCII-Tabelle](http://www.asciitable.com/))\n\nDas Verständnis der ASCII-Sortierreihenfolge ist wichtig, da A-Z vor a-z kommt.\nDas bedeutet, `>=1.2.3-BETA` gibt `1.2.3-alpha` zurück. Was Sie von\nGroß-/Kleinschreibungsempfindlichkeit erwarten könnten, gilt hier nicht. Dies\nliegt an der ASCII-Sortierreihenfolge, die die Spezifikation vorgibt.\n\n### Bindestrich-Bereichsvergleiche\n\nEs gibt mehrere Methoden zur Handhabung von Bereichen, und die erste sind\nBindestrich-Bereiche. Diese sehen so aus:\n\n- `1.2 - 1.4.5` was äquivalent ist zu `>= 1.2 <= 1.4.5`\n- `2.3.4 - 4.5` was äquivalent ist zu `>= 2.3.4 <= 4.5`\n\n### Wildcards in Vergleichen\n\nDie Zeichen `x`, `X` und `*` können als Wildcard-Zeichen verwendet werden. Dies\nfunktioniert für alle Vergleichsoperatoren. Bei Verwendung mit dem `=`-Operator\nfällt es auf den Patch-Level-Vergleich zurück (siehe Tilde unten). Zum Beispiel:\n\n- `1.2.x` ist äquivalent zu `>= 1.2.0, < 1.3.0`\n- `>= 1.2.x` ist äquivalent zu `>= 1.2.0`\n- `<= 2.x` ist äquivalent zu `< 3`\n- `*` ist äquivalent zu `>= 0.0.0`\n\n### Tilde-Bereichsvergleiche (Patch)\n\nDer Tilde (`~`)-Vergleichsoperator ist für Patch-Level-Bereiche, wenn eine\nNebenversion angegeben ist, und für Major-Level-Änderungen, wenn die\nNebenversionsnummer fehlt. Zum Beispiel:\n\n- `~1.2.3` ist äquivalent zu `>= 1.2.3, < 1.3.0`\n- `~1` ist äquivalent zu `>= 1, < 2`\n- `~2.3` ist äquivalent zu `>= 2.3, < 2.4`\n- `~1.2.x` ist äquivalent zu `>= 1.2.0, < 1.3.0`\n- `~1.x` ist äquivalent zu `>= 1, < 2`\n\n### Caret-Bereichsvergleiche (Major)\n\nDer Caret (`^`)-Vergleichsoperator ist für Major-Level-Änderungen, sobald ein\nstabiles (1.0.0) Release erfolgt ist. Vor einem 1.0.0-Release fungiert die\nNebenversion als API-Stabilitätsstufe. Dies ist nützlich bei Vergleichen von\nAPI-Versionen, da eine Major-Änderung API-brechend ist. Zum Beispiel:\n\n- `^1.2.3` ist äquivalent zu `>= 1.2.3, < 2.0.0`\n- `^1.2.x` ist äquivalent zu `>= 1.2.0, < 2.0.0`\n- `^2.3` ist äquivalent zu `>= 2.3, < 3`\n- `^2.x` ist äquivalent zu `>= 2.0.0, < 3`\n- `^0.2.3` ist äquivalent zu `>=0.2.3 <0.3.0`\n- `^0.2` ist äquivalent zu `>=0.2.0 <0.3.0`\n- `^0.0.3` ist äquivalent zu `>=0.0.3 <0.0.4`\n- `^0.0` ist äquivalent zu `>=0.0.0 <0.1.0`\n- `^0` ist äquivalent zu `>=0.0.0 <1.0.0`\n\n## URL-Funktionen\n\nHelm enthält die Funktionen [urlParse](#urlparse), [urlJoin](#urljoin) und\n[urlquery](#urlquery), die Ihnen die Arbeit mit URL-Teilen ermöglichen.\n\n### urlParse\n\nParst einen String als URL und erzeugt ein Dict mit URL-Teilen\n\n```\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\nDas obige gibt ein Dict zurück, das das URL-Objekt enthält:\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nDies wird mit den URL-Paketen aus der Go-Standardbibliothek implementiert.\nFür weitere Informationen siehe https://golang.org/pkg/net/url/#URL\n\n### urlJoin\n\nVerbindet ein Map (erzeugt von `urlParse`) zu einem URL-String\n\n```\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\nDas obige gibt den folgenden String zurück:\n```\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nGibt die escaped Version des übergebenen Werts zurück, sodass er zum Einbetten\nin den Query-Teil einer URL geeignet ist.\n\n```\n$var := urlquery \"string for query\"\n```\n\n## UUID-Funktionen\n\nHelm kann UUID v4 universell eindeutige Identifikatoren generieren.\n\n```\nuuidv4\n```\n\nDas obige gibt eine neue UUID vom Typ v4 (zufällig generiert) zurück.\n\n## Kubernetes- und Chart-Funktionen\n\nHelm enthält Funktionen für die Arbeit mit Kubernetes, darunter\n[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas),\n[Files](#file-funktionen) und [lookup](#lookup).\n\n### lookup\n\n`lookup` wird verwendet, um Ressourcen in einem laufenden Cluster nachzuschlagen.\nBei Verwendung mit dem Befehl `helm template` gibt es immer eine leere Antwort\nzurück.\n\nWeitere Details finden Sie in der [Dokumentation zur lookup-Funktion](./functions_and_pipelines.md#verwendung-der-lookup-funktion).\n\n### .Capabilities.APIVersions.Has\n\nGibt zurück, ob eine API-Version oder Ressource in einem Cluster verfügbar ist.\n\n```\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\nWeitere Informationen finden Sie in der [Dokumentation der eingebauten\nObjekte](./builtin_objects.md).\n\n### File-Funktionen\n\nEs gibt mehrere Funktionen, die Ihnen den Zugriff auf nicht-spezielle Dateien\ninnerhalb eines Charts ermöglichen. Zum Beispiel zum Zugriff auf\nAnwendungskonfigurationsdateien. Diese sind dokumentiert unter [Zugriff auf\nDateien in Templates](./accessing_files.md).\n\n_Hinweis: Die Dokumentation für viele dieser Funktionen stammt von\n[Sprig](https://github.com/Masterminds/sprig). Sprig ist eine\nTemplate-Funktionsbibliothek, die für Go-Anwendungen verfügbar ist._\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: Template-Funktionen und Pipelines\ndescription: Verwendung von Funktionen in Templates.\nsidebar_position: 5\n---\n\nBisher haben wir gesehen, wie man Informationen in ein Template einfügt. Aber\ndiese Informationen werden unverändert in das Template eingefügt. Manchmal\nmöchten wir die übergebenen Daten so transformieren, dass sie für uns\nnützlicher werden.\n\nBeginnen wir mit einer Best Practice: Wenn wir Strings aus dem `.Values`-Objekt\nin das Template einfügen, sollten wir diese Strings in Anführungszeichen setzen.\nDazu rufen wir die `quote`-Funktion in der Template-Anweisung auf:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nTemplate-Funktionen folgen der Syntax `funktionsName arg1 arg2...`. Im obigen\nBeispiel ruft `quote .Values.favorite.drink` die `quote`-Funktion auf und\nübergibt ihr ein einzelnes Argument.\n\nHelm verfügt über mehr als 60 Funktionen. Einige davon sind durch die\n[Go-Template-Sprache](https://godoc.org/text/template) selbst definiert. Die\nmeisten anderen stammen aus der [Sprig Template-Bibliothek](https://masterminds.github.io/sprig/).\nWir werden viele davon kennenlernen, während wir die Beispiele durcharbeiten.\n\n> Obwohl wir von der \"Helm-Template-Sprache\" sprechen, als wäre sie\n> Helm-spezifisch, ist sie tatsächlich eine Kombination aus der\n> Go-Template-Sprache, einigen zusätzlichen Funktionen und verschiedenen\n> Wrappern, um bestimmte Objekte für die Templates verfügbar zu machen. Viele\n> Ressourcen über Go-Templates können beim Erlernen des Templating hilfreich\n> sein.\n\n## Pipelines\n\nEine der leistungsstarken Funktionen der Template-Sprache ist ihr Konzept der\n_Pipelines_. Basierend auf einem Konzept aus UNIX sind Pipelines ein Werkzeug,\num eine Reihe von Template-Befehlen zu verketten und so eine Folge von\nTransformationen kompakt auszudrücken. Mit anderen Worten: Pipelines sind eine\neffiziente Methode, um mehrere Dinge nacheinander zu erledigen. Schreiben wir\ndas obige Beispiel mit einer Pipeline um.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nIn diesem Beispiel haben wir, anstatt `quote ARGUMENT` aufzurufen, die\nReihenfolge umgekehrt. Wir haben das Argument mit einer Pipeline (`|`) an die\nFunktion \"gesendet\": `.Values.favorite.drink | quote`. Mit Pipelines können wir\nmehrere Funktionen verketten:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Die Umkehrung der Reihenfolge ist eine gängige Praxis in Templates. Sie werden\n> `.val | quote` häufiger sehen als `quote .val`. Beide Varianten sind in\n> Ordnung.\n\nWenn dieses Template ausgewertet wird, ergibt sich folgendes:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nBeachten Sie, dass unser ursprüngliches `pizza` jetzt zu `\"PIZZA\"` transformiert\nwurde.\n\nWenn Argumente auf diese Weise durch eine Pipeline geleitet werden, wird das\nErgebnis der ersten Auswertung (`.Values.favorite.drink`) als _letztes Argument\nan die Funktion_ übergeben. Wir können das Getränke-Beispiel oben anpassen, um\ndies mit einer Funktion zu veranschaulichen, die zwei Argumente akzeptiert:\n`repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nDie `repeat`-Funktion wiederholt den gegebenen String die angegebene Anzahl von\nMalen, sodass wir folgende Ausgabe erhalten:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Verwendung der `default`-Funktion\n\nEine häufig in Templates verwendete Funktion ist die `default`-Funktion:\n`default STANDARDWERT GEGEBENER_WERT`. Mit dieser Funktion können Sie einen\nStandardwert im Template festlegen, falls der Wert nicht angegeben wird.\nVerwenden wir sie, um das Getränke-Beispiel anzupassen:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nWenn wir dies normal ausführen, erhalten wir unseren `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nNun entfernen wir die Einstellung für das Lieblingsgetränk aus `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nWenn wir jetzt `helm install --dry-run --debug fair-worm ./mychart` erneut\nausführen, wird folgendes YAML erzeugt:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nIn einem echten Chart sollten alle statischen Standardwerte in der\n`values.yaml` definiert sein und nicht mit dem `default`-Befehl wiederholt\nwerden (da sie sonst redundant wären). Der `default`-Befehl ist jedoch ideal für\nberechnete Werte, die nicht in `values.yaml` deklariert werden können. Zum\nBeispiel:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nAn manchen Stellen ist eine `if`-Bedingung möglicherweise besser geeignet als\n`default`. Diese werden wir im nächsten Abschnitt kennenlernen.\n\nTemplate-Funktionen und Pipelines sind eine leistungsstarke Möglichkeit,\nInformationen zu transformieren und dann in Ihr YAML einzufügen. Aber manchmal\nist es notwendig, Template-Logik hinzuzufügen, die etwas anspruchsvoller ist als\nnur das Einfügen eines Strings. Im nächsten Abschnitt betrachten wir die\nKontrollstrukturen, die die Template-Sprache bietet.\n\n## Verwendung der `lookup`-Funktion\n\nDie `lookup`-Funktion kann verwendet werden, um Ressourcen in einem laufenden\nCluster _nachzuschlagen_. Die Syntax der lookup-Funktion ist\n`lookup apiVersion, kind, namespace, name -> resource or resource list`.\n\n| Parameter  | Typ    |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\nSowohl `name` als auch `namespace` sind optional und können als leerer String\n(`\"\"`) übergeben werden. Bei Namespace-spezifischen Ressourcen müssen jedoch\nbeide Parameter angegeben werden.\n\nFolgende Parameterkombinationen sind möglich:\n\n| Verhalten                              | Lookup-Funktion                            |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\nWenn `lookup` ein Objekt zurückgibt, wird es als Dictionary zurückgegeben.\nDieses Dictionary kann weiter navigiert werden, um spezifische Werte zu\nextrahieren.\n\nDas folgende Beispiel gibt die Annotationen zurück, die für das\n`mynamespace`-Objekt vorhanden sind:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nWenn `lookup` eine Liste von Objekten zurückgibt, kann über das Feld `items` auf\ndie Objektliste zugegriffen werden:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* do something with each service */}}\n{{ end }}\n```\n\nWenn kein Objekt gefunden wird, wird ein leerer Wert zurückgegeben. Dies kann\nverwendet werden, um die Existenz eines Objekts zu prüfen.\n\nDie `lookup`-Funktion verwendet Helms bestehende Kubernetes-Verbindungs-\nkonfiguration, um Kubernetes abzufragen. Wenn beim Aufruf des API-Servers ein\nFehler zurückgegeben wird (z.B. aufgrund fehlender Berechtigungen zum Zugriff\nauf eine Ressource), schlägt die Template-Verarbeitung von Helm fehl.\n\nBeachten Sie, dass Helm den Kubernetes API-Server nicht während einer\n`helm template|install|upgrade|delete|rollback --dry-run`-Operation kontaktieren\nsoll. Um `lookup` gegen einen laufenden Cluster zu testen, sollte stattdessen\n`helm template|install|upgrade|delete|rollback --dry-run=server` verwendet\nwerden, um die Cluster-Verbindung zu ermöglichen.\n\n## Operatoren sind Funktionen\n\nFür Templates sind die Operatoren (`eq`, `ne`, `lt`, `gt`, `and`, `or` usw.)\nalle als Funktionen implementiert. In Pipelines können Operationen mit Klammern\n(`(` und `)`) gruppiert werden.\n\nNun können wir von Funktionen und Pipelines zur Flusskontrolle mit Bedingungen,\nSchleifen und Scope-Modifikatoren übergehen.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Erste Schritte\ndescription: Eine Kurzanleitung zu Chart-Templates.\nsidebar_position: 2\n---\n\nIn diesem Abschnitt der Anleitung erstellen wir ein Chart und fügen dann ein\nerstes Template hinzu. Das hier erstellte Chart wird im Rest der Anleitung\nverwendet.\n\nUm loszulegen, werfen wir einen kurzen Blick auf ein Helm Chart.\n\n## Charts\n\nWie in der [Charts-Anleitung](/topics/charts.md) beschrieben, sind Helm Charts\nfolgendermaßen strukturiert:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nDas Verzeichnis `templates/` ist für Template-Dateien vorgesehen. Wenn Helm ein\nChart auswertet, sendet es alle Dateien im Verzeichnis `templates/` durch die\nTemplate-Rendering-Engine. Anschließend sammelt es die Ergebnisse dieser\nTemplates und sendet sie an Kubernetes.\n\nDie Datei `values.yaml` ist ebenfalls wichtig für Templates. Diese Datei enthält\ndie _Standardwerte_ für ein Chart. Diese Werte können von Benutzern während\n`helm install` oder `helm upgrade` überschrieben werden.\n\nDie Datei `Chart.yaml` enthält eine Beschreibung des Charts. Sie können aus\neinem Template heraus darauf zugreifen.\n\nDas Verzeichnis `charts/` _kann_ andere Charts enthalten (die wir _Subcharts_\nnennen). Später in dieser Anleitung werden wir sehen, wie diese beim\nTemplate-Rendering funktionieren.\n\n## Ein Starter-Chart\n\nFür diese Anleitung erstellen wir ein einfaches Chart namens `mychart` und dann\neinige Templates darin.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### Ein kurzer Blick auf `mychart/templates/`\n\nWenn Sie sich das Verzeichnis `mychart/templates/` ansehen, werden Sie einige\nDateien bemerken, die bereits vorhanden sind.\n\n- `NOTES.txt`: Der \"Hilfetext\" für Ihr Chart. Dieser wird Ihren Benutzern\n  angezeigt, wenn sie `helm install` ausführen.\n- `deployment.yaml`: Ein einfaches Manifest zum Erstellen eines Kubernetes\n  [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n- `service.yaml`: Ein einfaches Manifest zum Erstellen eines [Service-\n  Endpunkts](https://kubernetes.io/docs/concepts/services-networking/service/)\n  für Ihr Deployment\n- `_helpers.tpl`: Ein Ort für Template-Hilfsfunktionen, die Sie im gesamten\n  Chart wiederverwenden können\n\nUnd was wir jetzt tun werden, ist... _sie alle löschen!_ Auf diese Weise können\nwir unser Tutorial von Grund auf durcharbeiten. Wir werden tatsächlich unsere\neigene `NOTES.txt` und `_helpers.tpl` erstellen, während wir fortschreiten.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nWenn Sie produktionsreife Charts schreiben, kann es sehr nützlich sein,\nGrundversionen dieser Charts zu haben. In Ihrem täglichen Chart-Authoring werden\nSie diese wahrscheinlich nicht entfernen wollen.\n\n## Ein erstes Template\n\nDas erste Template, das wir erstellen werden, ist eine `ConfigMap`. In\nKubernetes ist eine ConfigMap einfach ein Objekt zum Speichern von\nKonfigurationsdaten. Andere Dinge, wie Pods, können auf die Daten in einer\nConfigMap zugreifen.\n\nDa ConfigMaps grundlegende Ressourcen sind, bieten sie uns einen guten\nAusgangspunkt.\n\nBeginnen wir mit der Erstellung einer Datei namens\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**TIPP:** Template-Namen folgen keinem strengen Benennungsmuster. Wir empfehlen\njedoch, die Erweiterung `.yaml` für YAML-Dateien und `.tpl` für Hilfsfunktionen\nzu verwenden.\n\nDie obige YAML-Datei ist eine einfache ConfigMap mit den minimal erforderlichen\nFeldern. Aufgrund der Tatsache, dass sich diese Datei im Verzeichnis\n`mychart/templates/` befindet, wird sie durch die Template-Engine gesendet.\n\nSie können problemlos eine einfache YAML-Datei wie diese im Verzeichnis\n`mychart/templates/` ablegen. Wenn Helm dieses Template liest, sendet es das\nTemplate unverändert an Kubernetes.\n\nMit diesem einfachen Template haben wir jetzt ein installierbares Chart. Wir\nkönnen es so installieren:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nMit Helm können wir das Release abrufen und das tatsächlich geladene Template\nsehen.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nDer Befehl `helm get manifest` nimmt einen Release-Namen (`full-coral`) und gibt\nalle Kubernetes-Ressourcen aus, die auf den Server hochgeladen wurden. Jede\nDatei beginnt mit `---`, um den Anfang eines YAML-Dokuments anzuzeigen, gefolgt\nvon einer automatisch generierten Kommentarzeile, die uns sagt, welche\nTemplate-Datei dieses YAML-Dokument generiert hat.\n\nVon dort an können wir sehen, dass die YAML-Daten genau das sind, was wir in\nunsere `configmap.yaml`-Datei eingefügt haben.\n\nJetzt können wir unser Release deinstallieren: `helm uninstall full-coral`.\n\n### Hinzufügen eines einfachen Template-Aufrufs\n\nDas Hardcodieren des `name:`-Felds in eine Ressource wird normalerweise als\nschlechte Praxis angesehen. Namen sollten für ein Release eindeutig sein.\nDeshalb möchten wir vielleicht ein Namensfeld generieren, indem wir den\nRelease-Namen einfügen.\n\n**TIPP:** Das `name:`-Feld ist aufgrund von Einschränkungen des DNS-Systems auf\n63 Zeichen begrenzt. Aus diesem Grund sind Release-Namen auf 53 Zeichen\nbegrenzt. Kubernetes 1.3 und früher war auf nur 24 Zeichen beschränkt (somit 14\nZeichen für Namen).\n\nÄndern wir `configmap.yaml` entsprechend.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nDie wesentliche Änderung betrifft den Wert des `name:`-Felds, das jetzt\n`{{ .Release.Name }}-configmap` ist.\n\n> Eine Template-Direktive ist in `{{` und `}}` Blöcken eingeschlossen.\n\nDie Template-Direktive `{{ .Release.Name }}` fügt den Release-Namen in das\nTemplate ein. Die Werte, die in ein Template übergeben werden, können als\n_Namespace-Objekte_ betrachtet werden, wobei ein Punkt (`.`) jedes\nNamespace-Element trennt.\n\nDer führende Punkt vor `Release` zeigt an, dass wir mit dem obersten Namespace\nfür diesen Geltungsbereich beginnen (wir werden den Geltungsbereich gleich\nbesprechen). Wir könnten `.Release.Name` also lesen als \"beginne im obersten\nNamespace, finde das `Release`-Objekt, dann suche darin nach einem Objekt\nnamens `Name`\".\n\nDas `Release`-Objekt ist eines der eingebauten Objekte von Helm, und wir werden\nes später ausführlicher behandeln. Für den Moment reicht es zu sagen, dass dies\nden Release-Namen anzeigt, den die Bibliothek unserem Release zuweist.\n\nWenn wir jetzt unsere Ressource installieren, sehen wir sofort das Ergebnis der\nVerwendung dieser Template-Direktive:\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nSie können `helm get manifest clunky-serval` ausführen, um das gesamte\ngenerierte YAML zu sehen.\n\nBeachten Sie, dass die ConfigMap innerhalb von Kubernetes nun\n`clunky-serval-configmap` heißt statt wie zuvor `mychart-configmap`.\n\nAn diesem Punkt haben wir Templates in ihrer einfachsten Form gesehen:\nYAML-Dateien mit Template-Direktiven, die in `{{` und `}}` eingebettet sind. Im\nnächsten Teil werden wir uns Templates genauer ansehen. Aber bevor wir\nweitergehen, gibt es einen schnellen Trick, der das Erstellen von Templates\nbeschleunigen kann: Wenn Sie das Template-Rendering testen möchten, ohne\ntatsächlich etwas zu installieren, können Sie `helm install --debug --dry-run\ngoodly-guppy ./mychart` verwenden. Dies rendert die Templates. Aber anstatt das\nChart zu installieren, wird das gerenderte Template an Sie zurückgegeben, damit\nSie die Ausgabe sehen können:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nDie Verwendung von `--dry-run` erleichtert das Testen Ihres Codes, garantiert\naber nicht, dass Kubernetes selbst die von Ihnen generierten Templates\nakzeptiert. Es ist am besten, nicht davon auszugehen, dass Ihr Chart\ninstalliert wird, nur weil `--dry-run` funktioniert.\n\nIn der [Chart-Template-Anleitung](/chart_template_guide/index.mdx) nehmen wir\ndas hier definierte grundlegende Chart und erkunden die Helm-Template-Sprache im\nDetail. Und wir werden mit den eingebauten Objekten beginnen.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: Die .helmignore-Datei\ndescription: Die `.helmignore`-Datei wird verwendet, um Dateien anzugeben, die Sie nicht in Ihr Helm Chart aufnehmen möchten.\nsidebar_position: 12\n---\n\nDie `.helmignore`-Datei wird verwendet, um Dateien anzugeben, die Sie nicht in\nIhr Helm Chart aufnehmen möchten.\n\nWenn diese Datei existiert, ignoriert der Befehl `helm package` beim Paketieren\nIhrer Anwendung alle Dateien, die den in der `.helmignore`-Datei angegebenen\nMustern entsprechen.\n\nSo können Sie verhindern, dass unnötige oder sensible Dateien und Verzeichnisse\nin Ihr Helm Chart aufgenommen werden.\n\nDie `.helmignore`-Datei unterstützt Unix-Shell-Glob-Matching, relatives\nPfad-Matching und Negation (mit ! vorangestellt). Pro Zeile wird nur ein Muster\nberücksichtigt.\n\nHier ist ein Beispiel für eine `.helmignore`-Datei:\n\n```\n# comment\n\n# Match any file or path named .helmignore\n.helmignore\n\n# Match any file or path named .git\n.git\n\n# Match any text file\n*.txt\n\n# Match only directories named mydir\nmydir/\n\n# Match only text files in the top-level directory\n/*.txt\n\n# Match only the file foo.txt in the top-level directory\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt\na[b-d].txt\n\n# Match any file under subdir matching temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nEinige bemerkenswerte Unterschiede zu .gitignore:\n- Die '**'-Syntax wird nicht unterstützt.\n- Die verwendete Globbing-Bibliothek ist Go's 'filepath.Match', nicht fnmatch(3)\n- Nachstehende Leerzeichen werden immer ignoriert (es gibt keine Escape-Sequenz, um sie zu erhalten)\n- Es gibt keine Unterstützung für '\\!' als spezielle führende Sequenz.\n- Die Datei schließt sich nicht standardmäßig selbst aus – Sie müssen einen expliziten Eintrag für `.helmignore` hinzufügen\n\n\n**Helfen Sie uns**, dieses Dokument zu verbessern. Um Informationen\nhinzuzufügen, zu korrigieren oder zu entfernen, [erstellen Sie ein\nIssue](https://github.com/helm/helm-www/issues) oder senden Sie uns einen Pull\nRequest.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Benannte Templates\ndescription: Wie man benannte Templates definiert.\nsidebar_position: 9\n---\n\nNun ist es an der Zeit, über ein einzelnes Template hinauszugehen und weitere zu\nerstellen. In diesem Abschnitt werden wir sehen, wie man _benannte Templates_ in\neiner Datei definiert und sie an anderer Stelle verwendet. Ein _benanntes\nTemplate_ (manchmal auch _Partial_ oder _Subtemplate_ genannt) ist einfach ein\nTemplate, das innerhalb einer Datei definiert und mit einem Namen versehen wird.\nWir werden zwei Möglichkeiten kennenlernen, sie zu erstellen, und verschiedene\nWege, sie zu verwenden.\n\nIm Abschnitt [Kontrollstrukturen](./control_structures.md) haben wir drei\nAktionen zur Deklaration und Verwaltung von Templates vorgestellt: `define`,\n`template` und `block`. In diesem Abschnitt werden wir diese drei Aktionen\nbehandeln und auch eine spezielle `include`-Funktion vorstellen, die ähnlich wie\ndie `template`-Aktion funktioniert.\n\nEin wichtiges Detail beim Benennen von Templates: **Template-Namen sind\nglobal**. Wenn Sie zwei Templates mit demselben Namen deklarieren, wird\ndasjenige verwendet, das zuletzt geladen wurde. Da Templates in Subcharts\nzusammen mit Top-Level-Templates kompiliert werden, sollten Sie Ihre Templates\nmit _chart-spezifischen Namen_ versehen.\n\nEine beliebte Namenskonvention besteht darin, jedem definierten Template den\nNamen des Charts voranzustellen: `{{ define \"mychart.labels\" }}`. Durch die\nVerwendung des spezifischen Chart-Namens als Präfix können Konflikte vermieden\nwerden, die entstehen könnten, wenn zwei verschiedene Charts Templates mit\ndemselben Namen implementieren.\n\nDieses Verhalten gilt auch für verschiedene Versionen eines Charts. Wenn Sie\n`mychart` Version `1.0.0` haben, die ein Template auf eine bestimmte Weise\ndefiniert, und eine `mychart` Version `2.0.0`, die das vorhandene benannte\nTemplate modifiziert, wird dasjenige verwendet, das zuletzt geladen wurde. Sie\nkönnen dieses Problem umgehen, indem Sie auch eine Version im Namen des Charts\nhinzufügen: `{{ define \"mychart.v1.labels\" }}` und\n`{{ define \"mychart.v2.labels\" }}`.\n\n## Partials und `_`-Dateien\n\nBisher haben wir eine Datei verwendet, und diese eine Datei enthielt ein\neinzelnes Template. Aber die Template-Sprache von Helm ermöglicht es Ihnen,\nbenannte eingebettete Templates zu erstellen, auf die an anderer Stelle per\nName zugegriffen werden kann.\n\nBevor wir uns mit den Details des Schreibens dieser Templates befassen, gibt es\neine Dateibenennungskonvention, die erwähnt werden sollte:\n\n* Die meisten Dateien in `templates/` werden so behandelt, als ob sie\n  Kubernetes-Manifeste enthalten\n* Die `NOTES.txt` ist eine Ausnahme\n* Aber Dateien, deren Name mit einem Unterstrich (`_`) beginnt, enthalten\n  annahmegemäß _kein_ Manifest. Diese Dateien werden nicht als\n  Kubernetes-Objektdefinitionen gerendert, sind aber überall in anderen\n  Chart-Templates zur Verwendung verfügbar.\n\nDiese Dateien werden verwendet, um Partials und Hilfsfunktionen zu speichern.\nTatsächlich haben wir bei der Erstellung von `mychart` eine Datei namens\n`_helpers.tpl` gesehen. Diese Datei ist der Standardspeicherort für\nTemplate-Partials.\n\n## Templates mit `define` und `template` deklarieren und verwenden\n\nDie `define`-Aktion ermöglicht es uns, ein benanntes Template innerhalb einer\nTemplate-Datei zu erstellen. Die Syntax sieht folgendermaßen aus:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # body of template here\n{{- end }}\n```\n\nZum Beispiel können wir ein Template definieren, um einen Block von\nKubernetes-Labels zu kapseln:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nJetzt können wir dieses Template in unsere vorhandene ConfigMap einbetten und es\ndann mit der `template`-Aktion einbinden:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nWenn die Template-Engine diese Datei liest, speichert sie die Referenz auf\n`mychart.labels`, bis `template \"mychart.labels\"` aufgerufen wird. Dann wird\ndieses Template inline gerendert. Das Ergebnis sieht so aus:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nHinweis: Ein `define` erzeugt keine Ausgabe, es sei denn, es wird mit template\naufgerufen, wie in diesem Beispiel.\n\nKonventionell legen Helm Charts diese Templates in einer Partials-Datei ab,\nüblicherweise `_helpers.tpl`. Verschieben wir diese Funktion dorthin:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nKonventionsgemäß sollten `define`-Funktionen einen einfachen Dokumentationsblock\n(`{{/* ... */}}`) haben, der beschreibt, was sie tun.\n\nObwohl diese Definition in `_helpers.tpl` steht, kann sie dennoch in\n`configmap.yaml` verwendet werden:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nWie oben erwähnt, **sind Template-Namen global**. Wenn daher zwei Templates mit\ndemselben Namen deklariert werden, wird das zuletzt vorkommende verwendet. Da\nTemplates in Subcharts zusammen mit Top-Level-Templates kompiliert werden, ist\nes am besten, Ihre Templates mit _chart-spezifischen Namen_ zu versehen. Eine\nbeliebte Namenskonvention besteht darin, jedem definierten Template den Namen\ndes Charts voranzustellen: `{{ define \"mychart.labels\" }}`.\n\n## Den Gültigkeitsbereich eines Templates festlegen\n\nIn dem oben definierten Template haben wir keine Objekte verwendet, sondern nur\nFunktionen. Ändern wir unser definiertes Template so, dass es den Chart-Namen\nund die Chart-Version enthält:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nWenn wir dies rendern, erhalten wir einen Fehler wie diesen:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nUm zu sehen, was gerendert wurde, führen Sie den Befehl mit\n`--disable-openapi-validation` erneut aus:\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`.\nDas Ergebnis wird nicht dem entsprechen, was wir erwarten:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\nWas ist mit dem Namen und der Version passiert? Sie waren nicht im\nGültigkeitsbereich unseres definierten Templates. Wenn ein benanntes Template\n(erstellt mit `define`) gerendert wird, erhält es den Gültigkeitsbereich, der\nvom `template`-Aufruf übergeben wird. In unserem Beispiel haben wir das Template\nso eingebunden:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nEs wurde kein Gültigkeitsbereich übergeben, daher können wir innerhalb des\nTemplates auf nichts in `.` zugreifen. Das lässt sich aber leicht beheben. Wir\nübergeben einfach einen Gültigkeitsbereich an das Template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nBeachten Sie, dass wir `.` am Ende des `template`-Aufrufs übergeben. Wir könnten\ngenauso gut `.Values` oder `.Values.favorite` oder einen beliebigen anderen\nGültigkeitsbereich übergeben. Aber wir möchten den Top-Level-Gültigkeitsbereich.\nIm Kontext des benannten Templates verweist `$` auf den Gültigkeitsbereich, den\nSie übergeben haben, und nicht auf einen globalen Gültigkeitsbereich.\n\nWenn wir dieses Template nun mit `helm install --dry-run --debug\nplinking-anaco ./mychart` ausführen, erhalten wir folgendes:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nJetzt wird `{{ .Chart.Name }}` zu `mychart` aufgelöst und `{{ .Chart.Version }}`\nzu `0.1.0`.\n\n## Die `include`-Funktion\n\nNehmen wir an, wir haben ein einfaches Template definiert, das so aussieht:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nNehmen wir nun an, ich möchte dies sowohl in den `labels:`-Abschnitt meines\nTemplates als auch in den `data:`-Abschnitt einfügen:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nWenn wir dies rendern, erhalten wir einen Fehler wie diesen:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nUm zu sehen, was gerendert wurde, führen Sie den Befehl mit\n`--disable-openapi-validation` erneut aus:\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`.\nDie Ausgabe wird nicht dem entsprechen, was wir erwarten:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nBeachten Sie, dass die Einrückung bei `app_version` an beiden Stellen falsch\nist. Warum? Weil das eingefügte Template den Text linksbündig ausgerichtet hat.\nDa `template` eine Aktion und keine Funktion ist, gibt es keine Möglichkeit, die\nAusgabe eines `template`-Aufrufs an andere Funktionen zu übergeben; die Daten\nwerden einfach inline eingefügt.\n\nUm diesen Fall zu umgehen, bietet Helm eine Alternative zu `template`, die den\nInhalt eines Templates in die aktuelle Pipeline importiert, wo er an andere\nFunktionen in der Pipeline weitergegeben werden kann.\n\nHier ist das obige Beispiel, korrigiert mit `indent`, um das `mychart.app`-\nTemplate korrekt einzurücken:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nJetzt ist das erzeugte YAML für jeden Abschnitt korrekt eingerückt:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> In Helm Templates wird die Verwendung von `include` gegenüber `template`\n> bevorzugt, einfach weil die Ausgabeformatierung für YAML-Dokumente besser\n> gehandhabt werden kann.\n\nManchmal möchten wir Inhalte importieren, aber nicht als Templates. Das heißt,\nwir möchten Dateien unverändert importieren. Dies können wir erreichen, indem\nwir über das `.Files`-Objekt auf Dateien zugreifen, das im nächsten Abschnitt\nbeschrieben wird.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Eine NOTES.txt-Datei erstellen\ndescription: Wie Sie Ihren Chart-Benutzern Anweisungen bereitstellen.\nsidebar_position: 10\n---\n\nIn diesem Abschnitt betrachten wir das Helm-Werkzeug zur Bereitstellung von\nAnweisungen für Ihre Chart-Benutzer. Am Ende eines `helm install` oder\n`helm upgrade` kann Helm einen Block mit hilfreichen Informationen für Benutzer\nausgeben. Diese Informationen sind mithilfe von Templates flexibel anpassbar.\n\nUm Installationshinweise zu Ihrem Chart hinzuzufügen, erstellen Sie einfach eine\n`templates/NOTES.txt`-Datei. Diese Datei enthält reinen Text, wird aber wie\nein Template verarbeitet und hat Zugriff auf alle normalen Template-Funktionen\nund -Objekte.\n\nErstellen wir eine einfache `NOTES.txt`-Datei:\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nWenn wir jetzt `helm install rude-cardinal ./mychart` ausführen, sehen wir diese\nNachricht am Ende:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nDie Verwendung von `NOTES.txt` auf diese Weise ist eine hervorragende\nMöglichkeit, Ihren Benutzern detaillierte Informationen zur Nutzung ihres neu\ninstallierten Charts zu geben. Wir empfehlen dringend, eine `NOTES.txt`-Datei\nzu erstellen, auch wenn diese nicht zwingend erforderlich ist.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Subcharts und globale Werte\ndescription: Arbeiten mit Subchart-Werten und globalen Werten.\nsidebar_position: 11\n---\n\nBis zu diesem Punkt haben wir nur mit einem einzelnen Chart gearbeitet. Aber\nCharts können Abhängigkeiten haben, sogenannte _Subcharts_, die ebenfalls eigene\nWerte und Templates besitzen. In diesem Abschnitt werden wir ein Subchart\nerstellen und die verschiedenen Möglichkeiten kennenlernen, wie wir innerhalb\nvon Templates auf Werte zugreifen können.\n\nBevor wir uns dem Code widmen, gibt es einige wichtige Details über Subcharts zu\nbeachten:\n\n1. Ein Subchart gilt als \"eigenständig\", was bedeutet, dass ein Subchart niemals\n   explizit von seinem übergeordneten Chart abhängig sein kann.\n2. Aus diesem Grund kann ein Subchart nicht auf die Werte seines übergeordneten\n   Charts zugreifen.\n3. Ein übergeordnetes Chart kann Werte für Subcharts überschreiben.\n4. Helm kennt das Konzept von _globalen Werten_, auf die alle Charts zugreifen\n   können.\n\n> Diese Einschränkungen gelten nicht unbedingt für [Library Charts](/topics/library_charts.md), die darauf ausgelegt sind, standardisierte Hilfsfunktionen bereitzustellen.\n\nBeim Durcharbeiten der Beispiele in diesem Abschnitt werden viele dieser\nKonzepte deutlicher.\n\n## Erstellen eines Subcharts\n\nFür diese Übungen beginnen wir mit dem `mychart/`-Chart, das wir am Anfang\ndieses Leitfadens erstellt haben, und fügen ein neues Chart darin hinzu.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nBeachten Sie, dass wir wie zuvor alle Basis-Templates gelöscht haben, damit wir\nvon Grund auf neu beginnen können. In diesem Leitfaden konzentrieren wir uns auf\ndie Funktionsweise von Templates, nicht auf die Verwaltung von Abhängigkeiten.\nDer [Charts-Leitfaden](/topics/charts.md) enthält weitere Informationen darüber,\nwie Subcharts funktionieren.\n\n## Hinzufügen von Werten und einem Template zum Subchart\n\nAls Nächstes erstellen wir ein einfaches Template und eine Values-Datei für\nunser `mysubchart`-Chart. Es sollte bereits eine `values.yaml` in\n`mychart/charts/mysubchart` vorhanden sein. Wir richten sie wie folgt ein:\n\n```yaml\ndessert: cake\n```\n\nAls Nächstes erstellen wir ein neues ConfigMap-Template in\n`mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nDa jedes Subchart ein _eigenständiges Chart_ ist, können wir `mysubchart`\neinzeln testen:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Überschreiben von Werten aus einem übergeordneten Chart\n\nUnser ursprüngliches Chart `mychart` ist nun das _übergeordnete Chart_ von\n`mysubchart`. Diese Beziehung ergibt sich ausschließlich daraus, dass sich\n`mysubchart` im Verzeichnis `mychart/charts` befindet.\n\nDa `mychart` ein übergeordnetes Chart ist, können wir Konfigurationen in\n`mychart` festlegen und diese an `mysubchart` weitergeben. Zum Beispiel können\nwir `mychart/values.yaml` wie folgt ändern:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nBeachten Sie die letzten beiden Zeilen. Alle Anweisungen innerhalb des\n`mysubchart`-Abschnitts werden an das `mysubchart`-Chart gesendet. Wenn wir also\n`helm install --generate-name --dry-run --debug mychart` ausführen, werden wir\nunter anderem die `mysubchart`-ConfigMap sehen:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nDer Wert auf der obersten Ebene hat nun den Wert des Subcharts überschrieben.\n\nHier gibt es ein wichtiges Detail zu beachten. Wir haben das Template von\n`mychart/charts/mysubchart/templates/configmap.yaml` nicht geändert, um auf\n`.Values.mysubchart.dessert` zu verweisen. Aus Sicht dieses Templates befindet\nsich der Wert weiterhin unter `.Values.dessert`. Da die Template-Engine Werte\nweiterreicht, legt sie den Gültigkeitsbereich fest. Für die `mysubchart`-Templates\nsind also nur Werte verfügbar, die speziell für `mysubchart` bestimmt sind.\n\nManchmal möchten Sie jedoch, dass bestimmte Werte für alle Templates verfügbar\nsind. Dies wird durch globale Chart-Werte erreicht.\n\n## Globale Chart-Werte\n\nGlobale Werte sind Werte, auf die von jedem Chart oder Subchart unter genau\ndemselben Namen zugegriffen werden kann. Globale Werte erfordern eine explizite\nDeklaration. Sie können einen vorhandenen nicht-globalen Wert nicht verwenden,\nals wäre er global.\n\nDer Values-Datentyp hat einen reservierten Abschnitt namens `Values.global`, in\ndem globale Werte gesetzt werden können. Fügen wir einen in unserer\n`mychart/values.yaml`-Datei hinzu.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nAufgrund der Funktionsweise von globalen Werten sollten sowohl\n`mychart/templates/configmap.yaml` als auch\n`mysubchart/templates/configmap.yaml` auf diesen Wert als\n`{{ .Values.global.salad }}` zugreifen können.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nWenn wir nun eine Testinstallation durchführen, sehen wir denselben Wert in\nbeiden Ausgaben:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nGlobale Werte sind nützlich, um solche Informationen weiterzugeben, erfordern\njedoch eine gewisse Planung, um sicherzustellen, dass die richtigen Templates\nfür die Verwendung globaler Werte konfiguriert sind.\n\n## Templates mit Subcharts teilen\n\nÜbergeordnete Charts und Subcharts können Templates gemeinsam nutzen. Jeder\ndefinierte Block in einem Chart ist auch für andere Charts verfügbar.\n\nZum Beispiel können wir ein einfaches Template wie dieses definieren:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nErinnern Sie sich daran, dass Labels in Templates _global geteilt_ werden.\nDaher kann das `labels`-Template von jedem anderen Chart eingebunden werden.\n\nObwohl Chart-Entwickler zwischen `include` und `template` wählen können, hat\n`include` den Vorteil, dass es Templates dynamisch referenzieren kann:\n\n```yaml\n{{ include $mytemplate }}\n```\n\nDas obige Beispiel dereferenziert `$mytemplate`. Die `template`-Funktion\nhingegen akzeptiert nur ein String-Literal.\n\n## Vermeiden von Blocks\n\nDie Go-Template-Sprache bietet ein `block`-Schlüsselwort, mit dem Entwickler\neine Standardimplementierung bereitstellen können, die später überschrieben\nwird. In Helm Charts sind Blocks nicht das beste Werkzeug zum Überschreiben,\nda bei mehreren Implementierungen desselben Blocks nicht vorhersehbar ist,\nwelche ausgewählt wird.\n\nDie Empfehlung ist, stattdessen `include` zu verwenden.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Values-Dateien\ndescription: Anleitung zur Verwendung des --values-Flags.\nsidebar_position: 4\n---\n\nIm vorherigen Abschnitt haben wir die eingebauten Objekte betrachtet, die Helm\nTemplates bieten. Eines dieser eingebauten Objekte ist `Values`. Dieses Objekt\nbietet Zugriff auf Werte, die in das Chart übergeben werden. Der Inhalt stammt\naus mehreren Quellen:\n\n- Die `values.yaml`-Datei im Chart\n- Falls es sich um ein Subchart handelt, die `values.yaml`-Datei des\n  übergeordneten Charts\n- Eine Values-Datei, die mit dem `-f`-Flag an `helm install` oder `helm upgrade`\n  übergeben wird (`helm install -f myvals.yaml ./mychart`)\n- Einzelne Parameter, die mit `--set` übergeben werden (z.B. `helm install --set foo=bar\n  ./mychart`)\n\nDie obige Liste ist nach Priorität geordnet: `values.yaml` ist die\nStandardeinstellung, die von der `values.yaml` eines übergeordneten Charts\nüberschrieben werden kann, welche wiederum von einer benutzerdefinierten\nValues-Datei überschrieben werden kann, die ihrerseits von `--set`-Parametern\nüberschrieben werden kann.\n\nValues-Dateien sind einfache YAML-Dateien. Bearbeiten wir `mychart/values.yaml`\nund anschließend unser ConfigMap-Template.\n\nNach dem Entfernen der Standardwerte in `values.yaml` setzen wir nur einen\nParameter:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nJetzt können wir diesen Wert in einem Template verwenden:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nBeachten Sie, dass wir in der letzten Zeile auf `favoriteDrink` als Attribut von\n`Values` zugreifen: `{{ .Values.favoriteDrink }}`.\n\nSehen wir uns das Ergebnis an:\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nDa `favoriteDrink` in der Standard-`values.yaml`-Datei auf `coffee` gesetzt ist,\nwird dieser Wert im Template angezeigt. Wir können dies einfach überschreiben,\nindem wir ein `--set`-Flag bei unserem `helm install`-Aufruf hinzufügen:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nDa `--set` eine höhere Priorität als die Standard-`values.yaml`-Datei hat,\nerzeugt unser Template `drink: slurm`.\n\nValues-Dateien können auch strukturiertere Inhalte enthalten. Zum Beispiel\nkönnten wir einen `favorite`-Abschnitt in unserer `values.yaml`-Datei erstellen\nund dort mehrere Schlüssel hinzufügen:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nNun müssten wir das Template leicht anpassen:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nObwohl diese Art der Datenstrukturierung möglich ist, empfehlen wir, Ihre\nValues-Bäume flach zu halten. Wenn wir uns mit der Zuweisung von Werten an\nSubcharts beschäftigen, werden wir sehen, wie Werte mit einer Baumstruktur\nbenannt werden.\n\n## Löschen eines Standardschlüssels\n\nFalls Sie einen Schlüssel aus den Standardwerten entfernen müssen, können Sie\nden Wert des Schlüssels auf `null` setzen. Helm entfernt dann den Schlüssel bei\nder Zusammenführung der überschriebenen Werte.\n\nBeispielsweise erlaubt das Stable Drupal Chart die Konfiguration der\nLiveness-Probe, falls Sie ein benutzerdefiniertes Image konfigurieren. Hier sind\ndie Standardwerte:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nWenn Sie versuchen, den livenessProbe-Handler mit\n`--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]` auf `exec` statt\n`httpGet` zu überschreiben, führt Helm die Standard- und überschriebenen\nSchlüssel zusammen, was zu folgendem YAML führt:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nKubernetes würde dann jedoch einen Fehler melden, da Sie nicht mehr als einen\nlivenessProbe-Handler deklarieren können. Um dies zu umgehen, können Sie Helm\nanweisen, `livenessProbe.httpGet` zu löschen, indem Sie es auf null setzen:\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nBisher haben wir mehrere eingebaute Objekte kennengelernt und verwendet, um\nInformationen in Templates einzufügen. Als Nächstes betrachten wir einen\nweiteren Aspekt der Template-Engine: Funktionen und Pipelines.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: Variablen\ndescription: Verwendung von Variablen in Templates.\nsidebar_position: 8\n---\n\nNachdem wir nun mit Funktionen, Pipelines, Objekten und Kontrollstrukturen\nvertraut sind, können wir uns einem der grundlegendsten Konzepte vieler\nProgrammiersprachen zuwenden: Variablen. In Templates werden sie weniger häufig\nverwendet. Wir werden jedoch sehen, wie man sie nutzt, um Code zu vereinfachen\nund `with` sowie `range` besser einzusetzen.\n\nIn einem früheren Beispiel haben wir gesehen, dass dieser Code fehlschlägt:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` befindet sich nicht innerhalb des Gültigkeitsbereichs, der im\n`with`-Block eingeschränkt ist. Um solche Gültigkeitsbereichsprobleme zu\numgehen, können Sie Objekte Variablen zuweisen, auf die unabhängig vom\naktuellen Gültigkeitsbereich zugegriffen werden kann.\n\nIn Helm Templates ist eine Variable eine benannte Referenz auf ein anderes\nObjekt. Sie folgt der Form `$name`. Variablen werden mit einem speziellen\nZuweisungsoperator zugewiesen: `:=`. Wir können das obige Beispiel umschreiben,\num eine Variable für `Release.Name` zu verwenden.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nBeachten Sie, dass wir vor dem Start des `with`-Blocks `$relname :=\n.Release.Name` zuweisen. Innerhalb des `with`-Blocks verweist die Variable\n`$relname` weiterhin auf den Release-Namen.\n\nDas erzeugt folgende Ausgabe:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nVariablen sind besonders nützlich in `range`-Schleifen. Sie können bei\nlistenartigen Objekten verwendet werden, um sowohl den Index als auch den Wert\nzu erfassen:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nBeachten Sie, dass zuerst `range` kommt, dann die Variablen, dann der\nZuweisungsoperator und schließlich die Liste. Dies weist den ganzzahligen Index\n(beginnend bei Null) `$index` zu und den Wert `$topping`. Das erzeugt:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nBei Datenstrukturen, die sowohl einen Schlüssel als auch einen Wert haben,\nkönnen wir `range` verwenden, um beides zu erhalten. Zum Beispiel können wir\n`.Values.favorite` so durchlaufen:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nBei der ersten Iteration wird `$key` den Wert `drink` haben und `$val` den Wert\n`coffee`, und bei der zweiten wird `$key` den Wert `food` haben und `$val` den\nWert `pizza`. Das erzeugt:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nVariablen sind normalerweise nicht \"global\". Sie sind auf den Block beschränkt,\nin dem sie deklariert werden. Früher haben wir `$relname` auf der obersten Ebene\ndes Templates zugewiesen. Diese Variable ist im gesamten Template gültig. Aber\nin unserem letzten Beispiel sind `$key` und `$val` nur innerhalb des\n`{{ range... }}{{ end }}`-Blocks gültig.\n\nEs gibt jedoch eine Variable, die immer auf den Root-Kontext verweist: `$`.\nDies kann sehr nützlich sein, wenn Sie in einer range-Schleife iterieren und\nden Release-Namen des Charts benötigen.\n\nEin Beispiel zur Veranschaulichung:\n\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Many helm templates would use `.` below, but that will not work,\n    # however `$` will work here\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # I cannot reference .Chart.Name, but I can do $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Value from appVersion in Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nBisher haben wir nur ein Template betrachtet, das in nur einer Datei deklariert\nist. Aber eine der mächtigen Funktionen der Helm Template-Sprache ist die\nMöglichkeit, mehrere Templates zu deklarieren und sie gemeinsam zu verwenden.\nDarauf werden wir im nächsten Abschnitt eingehen.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Nächste Schritte\ndescription: Abschluss - einige nützliche Hinweise auf weitere Dokumentation, die Ihnen helfen wird.\nsidebar_position: 14\n---\n\nDiese Anleitung soll Ihnen als Chart-Entwickler ein fundiertes Verständnis\nfür die Verwendung der Template-Sprache von Helm vermitteln. Die Anleitung\nkonzentriert sich auf die technischen Aspekte der Template-Entwicklung.\n\nEs gibt jedoch viele Themen, die diese Anleitung nicht behandelt hat, wenn\nes um die praktische tägliche Entwicklung von Charts geht. Hier sind einige\nnützliche Hinweise auf weitere Dokumentation, die Ihnen bei der Erstellung\nneuer Charts helfen wird:\n\n- Der CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) ist\n  eine unverzichtbare Quelle für Charts.\n- Die Kubernetes [Dokumentation](https://kubernetes.io/docs/home/) bietet\n  detaillierte Beispiele für die verschiedenen Ressourcentypen, die Sie\n  verwenden können, von ConfigMaps und Secrets bis hin zu DaemonSets und\n  Deployments.\n- Die Helm [Charts-Anleitung](/topics/charts.md) erklärt den Arbeitsablauf\n  bei der Verwendung von Charts.\n- Die Helm [Chart Hooks-Anleitung](/topics/charts_hooks.md) erklärt, wie\n  Sie Lifecycle Hooks erstellen.\n- Der Helm Artikel [Tipps und Tricks](/howto/charts_tips_and_tricks.md)\n  bietet nützliche Hinweise für das Schreiben von Charts.\n- Die [Sprig-Dokumentation](https://github.com/Masterminds/sprig) dokumentiert\n  mehr als sechzig Template-Funktionen.\n- Die [Go Template-Dokumentation](https://godoc.org/text/template) erklärt die\n  Template-Syntax im Detail.\n- Das [Schelm-Tool](https://github.com/databus23/schelm) ist ein praktisches\n  Hilfsprogramm zum Debuggen von Charts.\n\nManchmal ist es einfacher, ein paar Fragen zu stellen und Antworten von\nerfahrenen Entwicklern zu bekommen. Der beste Ort dafür sind die Helm-Kanäle\nim [Kubernetes Slack](https://kubernetes.slack.com):\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nWenn Sie Fehler oder Auslassungen in diesem Dokument finden, neue Inhalte\nvorschlagen oder einen Beitrag leisten möchten, besuchen Sie das\n[Helm-Projekt](https://github.com/helm/helm-www).\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Anhang: YAML-Techniken\"\ndescription: Ein genauerer Blick auf die YAML-Spezifikation und wie sie auf Helm angewendet wird.\nsidebar_position: 15\n---\n\nDer Großteil dieser Anleitung hat sich auf das Schreiben der Template-Sprache\nkonzentriert. Hier werden wir uns das YAML-Format ansehen. YAML hat einige\nnützliche Funktionen, die wir als Template-Autoren nutzen können, um unsere\nTemplates weniger fehleranfällig und leichter lesbar zu machen.\n\n## Skalare und Collections\n\nLaut der [YAML-Spezifikation](https://yaml.org/spec/1.2/spec.html) gibt es zwei\nArten von Collections und viele skalare Typen.\n\nDie zwei Arten von Collections sind Maps und Sequences:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nSkalare Werte sind einzelne Werte (im Gegensatz zu Collections).\n\n### Skalare Typen in YAML\n\nIn Helms YAML-Dialekt wird der skalare Datentyp eines Wertes durch einen\nkomplexen Satz von Regeln bestimmt, einschließlich des Kubernetes-Schemas für\nRessourcendefinitionen. Bei der Typinferenz gelten jedoch in der Regel die\nfolgenden Regeln.\n\nWenn eine Ganzzahl oder Fließkommazahl ein nicht in Anführungszeichen\ngesetztes Wort ist, wird sie typischerweise als numerischer Typ behandelt:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nWenn sie jedoch in Anführungszeichen gesetzt sind, werden sie als Strings behandelt:\n\n```yaml\ncount: \"1\" # <-- string, not int\nsize: '2.34' # <-- string, not float\n```\n\nDasselbe gilt für Booleans:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # string\n```\n\nDas Wort für einen leeren Wert ist `null` (nicht `nil`).\n\nBeachten Sie, dass `port: \"80\"` gültiges YAML ist und sowohl durch die\nTemplate-Engine als auch den YAML-Parser läuft, aber fehlschlägt, wenn\nKubernetes erwartet, dass `port` eine Ganzzahl ist.\n\nIn einigen Fällen können Sie eine bestimmte Typinferenz mit YAML-Node-Tags erzwingen:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nIm obigen Beispiel teilt `!!str` dem Parser mit, dass `age` ein String ist, auch\nwenn es wie ein Integer aussieht. Und `port` wird als Integer behandelt, obwohl\nes in Anführungszeichen steht.\n\n\n## Strings in YAML\n\nEin Großteil der Daten, die wir in YAML-Dokumenten platzieren, sind Strings.\nYAML hat mehr als eine Möglichkeit, einen String darzustellen. Dieser Abschnitt\nerklärt die verschiedenen Wege und zeigt, wie einige davon verwendet werden.\n\nEs gibt drei \"inline\" Möglichkeiten, einen String zu deklarieren:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nAlle Inline-Stile müssen in einer Zeile stehen.\n\n- Bare Words (unquotierte Wörter) sind nicht in Anführungszeichen gesetzt und\n  werden nicht escaped. Aus diesem Grund müssen Sie darauf achten, welche\n  Zeichen Sie verwenden.\n- Strings in doppelten Anführungszeichen können bestimmte Zeichen mit `\\`\n  escapen. Zum Beispiel `\"\\\"Hello\\\", she said\"`. Sie können Zeilenumbrüche mit\n  `\\n` escapen.\n- Strings in einfachen Anführungszeichen sind \"literale\" Strings und verwenden\n  nicht `\\` zum Escapen von Zeichen. Die einzige Escape-Sequenz ist `''`, die\n  als einzelnes `'` dekodiert wird.\n\nZusätzlich zu den einzeiligen Strings können Sie mehrzeilige Strings deklarieren:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nDas obige Beispiel behandelt den Wert von `coffee` als einen einzelnen String,\nder `Latte\\nCappuccino\\nEspresso\\n` entspricht.\n\nBeachten Sie, dass die erste Zeile nach dem `|` korrekt eingerückt sein muss.\nWir könnten das obige Beispiel also durch Folgendes ungültig machen:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nDa `Latte` falsch eingerückt ist, würden wir einen Fehler wie diesen erhalten:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nIn Templates ist es manchmal sicherer, eine \"erste Zeile\" als Platzhalter in\neinem mehrzeiligen Dokument zu setzen, um den obigen Fehler zu vermeiden:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nBeachten Sie, dass diese erste Zeile in der Ausgabe des Strings erhalten bleibt.\nWenn Sie diese Technik beispielsweise verwenden, um den Inhalt einer Datei in\neine ConfigMap einzufügen, sollte der Kommentar dem Typ entsprechen, der von\ndem erwartet wird, was diesen Eintrag liest.\n\n### Kontrolle von Leerzeichen in mehrzeiligen Strings\n\nIm obigen Beispiel haben wir `|` verwendet, um einen mehrzeiligen String\nanzuzeigen. Beachten Sie jedoch, dass dem Inhalt unseres Strings ein\nabschließendes `\\n` folgte. Wenn wir möchten, dass der YAML-Prozessor das\nabschließende Newline entfernt, können wir ein `-` nach dem `|` hinzufügen:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nJetzt wird der `coffee`-Wert sein: `Latte\\nCappuccino\\nEspresso` (ohne\nabschließendes `\\n`).\n\nIn anderen Fällen möchten wir vielleicht, dass alle abschließenden Leerzeichen\nerhalten bleiben. Wir können dies mit der `|+`-Notation tun:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nJetzt wird der Wert von `coffee` sein: `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nDie Einrückung innerhalb eines Textblocks wird beibehalten und führt auch zur\nBeibehaltung von Zeilenumbrüchen:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nIm obigen Fall wird `coffee` sein: `Latte\\n  12 oz\\n  16\noz\\nCappuccino\\nEspresso`.\n\n### Einrückung und Templates\n\nBeim Schreiben von Templates möchten Sie möglicherweise den Inhalt einer Datei\nin das Template einfügen. Wie wir in vorherigen Kapiteln gesehen haben, gibt es\nzwei Möglichkeiten, dies zu tun:\n\n- Verwenden Sie `{{ .Files.Get \"FILENAME\" }}`, um den Inhalt einer Datei im\n  Chart zu erhalten.\n- Verwenden Sie `{{ include \"TEMPLATE\" . }}`, um ein Template zu rendern und\n  dann dessen Inhalt in das Chart einzufügen.\n\nBeim Einfügen von Dateien in YAML ist es gut, die obigen mehrzeiligen Regeln zu\nverstehen. Oft ist der einfachste Weg, eine statische Datei einzufügen,\nfolgender:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nBeachten Sie, wie wir die Einrückung oben durchführen: `indent 2` weist die\nTemplate-Engine an, jede Zeile in \"myfile.txt\" mit zwei Leerzeichen\neinzurücken. Beachten Sie, dass wir diese Template-Zeile nicht einrücken. Das\nliegt daran, dass andernfalls der Dateiinhalt der ersten Zeile doppelt\neingerückt würde.\n\n### Gefaltete mehrzeilige Strings\n\nManchmal möchten Sie einen String in Ihrem YAML mit mehreren Zeilen darstellen,\naber möchten, dass er bei der Interpretation als eine lange Zeile behandelt\nwird. Dies wird \"Folding\" (Falten) genannt. Um einen gefalteten Block zu\ndeklarieren, verwenden Sie `>` anstelle von `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nDer Wert von `coffee` oben wird `Latte Cappuccino Espresso\\n` sein. Beachten\nSie, dass alle außer dem letzten Zeilenvorschub in Leerzeichen umgewandelt\nwerden. Sie können die Leerzeichen-Kontrollen mit dem Folded-Text-Marker\nkombinieren, sodass `>-` alle Newlines ersetzt oder entfernt.\n\nBeachten Sie, dass in der Folded-Syntax das Einrücken von Text dazu führt, dass\nZeilen erhalten bleiben.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nDas obige Beispiel ergibt `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`.\nBeachten Sie, dass sowohl die Leerzeichen als auch die Zeilenumbrüche noch\nvorhanden sind.\n\n## Einbetten mehrerer Dokumente in einer Datei\n\nEs ist möglich, mehr als ein YAML-Dokument in einer einzigen Datei zu\nplatzieren. Dies geschieht, indem ein neues Dokument mit `---` eingeleitet und\ndas Dokument mit `...` beendet wird.\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nIn vielen Fällen kann entweder `---` oder `...` weggelassen werden.\n\nEinige Dateien in Helm können nicht mehr als ein Dokument enthalten. Wenn\nbeispielsweise mehr als ein Dokument in einer `values.yaml`-Datei bereitgestellt\nwird, wird nur das erste verwendet.\n\nTemplate-Dateien können jedoch mehr als ein Dokument haben. In diesem Fall wird\ndie Datei (und alle ihre Dokumente) beim Template-Rendering als ein Objekt\nbehandelt. Aber dann wird das resultierende YAML in mehrere Dokumente\naufgeteilt, bevor es an Kubernetes übergeben wird.\n\nWir empfehlen, mehrere Dokumente pro Datei nur dann zu verwenden, wenn es\nunbedingt notwendig ist. Das Vorhandensein mehrerer Dokumente in einer Datei\nkann das Debugging erschweren.\n\n## YAML ist eine Obermenge von JSON\n\nDa YAML eine Obermenge von JSON ist, _sollte_ jedes gültige JSON-Dokument auch\ngültiges YAML sein.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nDas obige ist eine andere Art, dies darzustellen:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nUnd die beiden können (mit Vorsicht) gemischt werden:\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nAlle drei sollten zur gleichen internen Darstellung geparst werden.\n\nObwohl dies bedeutet, dass Dateien wie `values.yaml` JSON-Daten enthalten\nkönnen, behandelt Helm die Dateiendung `.json` nicht als gültiges Suffix.\n\n## YAML-Anker\n\nDie YAML-Spezifikation bietet eine Möglichkeit, eine Referenz auf einen Wert zu\nspeichern und später auf diesen Wert per Referenz zu verweisen. YAML nennt dies\n\"Anchoring\":\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nIm obigen Beispiel setzt `&favoriteCoffee` eine Referenz auf `Cappuccino`.\nSpäter wird diese Referenz als `*favoriteCoffee` verwendet. So wird `coffees` zu\n`Latte, Cappuccino, Espresso`.\n\nObwohl es einige Fälle gibt, in denen Anker nützlich sind, gibt es einen\nAspekt, der subtile Bugs verursachen kann: Wenn das YAML zum ersten Mal\neingelesen wird, wird die Referenz aufgelöst und dann verworfen.\n\nWenn wir also das obige Beispiel dekodieren und dann wieder kodieren würden,\nwäre das resultierende YAML:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nDa Helm und Kubernetes oft YAML-Dateien lesen, modifizieren und dann neu\nschreiben, gehen die Anker verloren.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: \"Änderungen seit Helm 2\"\nsidebar_position: 1\n---\n\n## Änderungen seit Helm 2\n\nHier ist eine Liste an grundlegenden Änderungen in Helm 3.\n\n### Löschung von Tiller\n\nWährend des Helm 2 Entwicklungszyklus haben wir Tiller vorgestellt. Tiller\nspielte eine wichtige Rolle für Teams in einem geteilten Cluster - es war\nfür mehrere unterschiedliche Operatoren möglich, mit demselben Set an Versionen\nzu interagieren.\n\nMit rollenbasierter Zugriffskontrolle (RBAC), standardmäßig aktiviert in Kubernetes 1.6,\nsperrte Tiller immer mehr in Produktionsumgebungen aus, da die Verwaltung schwieriger\nwurde. Durch die vielen möglichen Sicherheitsrichtlinien war es unser Fokus,\neine permissive Standardkonfiguration zu liefern. Das erlaubte es Neulingen in Helm\nund Kubernetes, schnell zu starten, ohne sich allzu viel über Sicherheitskontrollen den\nKopf zu zerbrechen. Unglücklicherweise konnte diese permissive Konfiguration ein\nbreites Spektrum an Berechtigungen öffnen, ohne dass der Nutzer dies erwartete.\nDevOps und SREs hatten zusätzliche Betriebsschritte zu lernen, um Tiller in einem\nMulti-Mandanten-Cluster zu betreiben.\n\nNachdem wir von Gemeinschaftsmitgliedern gehört haben, wie sie Helm benutzen, fanden\nwir, dass Tillers Versionsverwaltung nicht zum Clusterbetrieb oder als zentraler\nPlatz für Helm Versionsinformationen passte. Stattdessen können wir einfach die\nInformationen von der Kubernetes-API abrufen, die Charts auf lokaler Seite rendern und\neinen Eintrag der Installation in Kubernetes speichern.\n\nTillers primäre Ziel konnte ohne Tiller erreicht werden, so war es eine der ersten\nEntscheidungen, die für Helm 3 getroffen wurden, Tiller komplett zu entfernen.\n\nOhne Tiller hat sich das Sicherheitsmodell von Helm radikal vereinfacht. Helm 3\nunterstützt jetzt alle modernen Sicherheits-, Identitäts- und Autorisierungsfunktionen von Kubernetes.\nHelms Zugriffsrechte werden anhand Ihrer [kubeconfig-Datei](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) ausgewertet.\nCluster-Administratoren können Benutzerrechte so granular einschränken, wie sie es für nötig halten.\nVersionen werden weiter im Cluster gespeichert und die restliche Funktionalität\nvon Helm bleibt erhalten.\n\n### Verbesserte Aktualisierungsstrategie: 3-Wege Vereinigung\n\nHelm 2 hat eine 2-Wege Vereinigungsstrategie benutzt. Während der Aktualisierung\nverglich es das letzte Chart-Manifest gegen das vorgeschlagene Chart-Manifest\n(welches bei `helm upgrade` übergeben wurde). Es verglich die Unterschiede\nzwischen den zwei Charts, um herauszufinden, welche Änderungen an den Ressourcen\nim Kubernetes-Cluster notwendig sind.\nWenn Änderungen außerhalb von Helm gemacht wurden (etwa mit `kubectl edit`),\nwurden diese Änderungen nicht berücksichtigt. Das resultierte in Ressourcen, die nicht\nzurückgerollt werden konnten: Weil Helm nur das letzte angewandte Chart-Manifest als\naktuellen Status betrachtete, blieb der Live-Status unverändert, wenn es keine\nÄnderungen im Chart-Status gab.\n\nIn Helm 3 benutzen wir jetzt eine 3-Wege Vereinigungsstrategie. Helm beachtet das\nalte Manifest, den Livestatus und das neue Manifest, um einen Patch zu generieren.\n\n#### Beispiele\n\nLassen Sie uns durch ein paar übliche Beispiele gehen, um die Auswirkungen zu\nsehen.\n\n##### Zurückrollen wo sich der Livestatus geändert hat\n\nIhr Team hat gerade mit Helm ihre Applikation in die Produktion auf Kubernetes gebracht.\nDas Chart beinhaltet ein Deployment Objekt, in dem die Nummer der Replicas auf\ndrei gesetzt ist:\n\n```console\n$ helm install myapp ./myapp\n```\n\nEin neuer Entwickler tritt dem Team bei. An seinem ersten Arbeitstag tritt\nbeim Betrachten des Produktions-Clusters ein fürchterlicher Kaffee-auf-Tastatur-Unfall\nein und das Deployment wird von drei Replicas auf 0 skaliert.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nEin anderer Entwickler Ihres Teams stellt fest, dass die Produktionsseite aus ist und\nentscheidet ein Zurückrollen der Version zum vorherigen Status:\n\n```console\n$ helm rollback myapp\n```\n\nWas passiert?\n\nIn Helm 2 würde ein Patch generiert, der das alte gegen das neue\nManifest vergleicht. Weil es ein Zurückrollen ist, ist es dasselbe\nManifest. Helm würde feststellen, dass es nichts zu ändern gibt, weil es\nkeinen Unterschied zwischen dem alten und den neuen Manifest gibt. Der\nReplica Zähler würde weiter auf 0 stehenbleiben. Panik bricht aus.\n\nIn Helm 3 würde ein Patch generiert, der das alte Manifest, den Livestatus\nund das neue Manifest vergleicht. Helm stellt fest, dass der alte Status\ndrei, der Livestatus 0 und das neue Manifest den Wunsch der Änderung zurück\nzu drei hegt, sodass der Patch eine Änderung des Status zu drei generiert.\n\n##### Aktualisierungen wo sich der Livestatus geändert hat\n\nViele Dienstenetze und andere kontroll-basierte Applikationen injizieren\nDaten in Kubernetes Objekte. Das kann sowas sein wie ein Sidecar, Label oder\nandere Informationen. Vorher haben Sie ein Manifest von einem Chart so\ngerendert:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nUnd der Livestatus wurde von einer anderen Applikation geändert zu:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nJetzt möchten Sie den `nginx` Image Tag auf `2.1.0` aktualisieren. Dazu\naktualisieren Sie das Chart mit diesem Manifest:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nWas passiert?\n\nIn Helm 2 generiert Helm einen Patch für das `containers` Objekt zwischen dem\nalten und dem neuen Manifest. Der Cluster Livestatus wird bei der Patchgenerierung\nnicht beachtet.\n\nDer Cluster Livestatus wird in folgender Weise geändert:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nDer Sidecar-Pod ist aus dem Live-Status gelöscht. Mehr Panik bricht aus.\n\nIn Helm 3 generiert Helm einen Patch des `containers` Objekts zwischen dem\nalten Manifest, dem Live-Status und dem neuen Manifest. Es bemerkt, dass das\nneue Manifest den Image Tag auf `2.1.0` ändern möchte, aber der Live-Status\neinen Sidecar Container beinhaltet.\n\nDer Cluster Livestatus wird in folgender Weise geändert:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### Versionsnamen sind jetzt im Umfang des Namespace geändert\n\nNach der Löschung von Tiller müssen die Informationen über die Versionen\nirgendwohin. In Helm 2 wurde das im selben Namespace wie Tiller gespeichert.\nIn der Praxis bedeutete das, dass ein Name von einer Version verwendet wurde,\nkeine andere Version konnte denselben Namen benutzen, auch wenn es in\nunterschiedlichen Namespace installiert war.\n\nIn Helm 3 werden die Informationen über eine Version im selben Namespace\ngespeichert, in dem die Version selbst installiert ist. Das bedeutet, dass\nBenutzer jetzt `helm install wordpress stable/wordpress` in zwei separaten\nNamespaces ausführen können und jede Version mit `helm list` im Kontext des\njeweiligen Namespace angezeigt wird (z.B. `helm list --namespace foo`).\n\nMit dieser besseren Ausrichtung auf native Cluster-Namespaces listet das Kommando\n`helm list` nicht mehr standardmäßig alle Versionen auf. Stattdessen listet es\nes nur die Versionen im derzeitigen Kubernetes Kontext auf (z.B. den Namespace\nwenn Sie `kubectl config view --minify` eingeben). Das bedeutet also, dass Sie\ndie Option `--all-namespaces` zu `helm list` eingeben müssen, wie bei Helm 2.\n\n### Secrets als der Standardspeichertreiber\n\nIn Helm 3 werden jetzt Secrets als der [Standardspeichertreiber](/topics/advanced.md#storage-backends)\nbenutzt. Helm 2 benutzte ConfigMaps als Standard, um Versionsinformationen zu\nspeichern. In Helm 2.7.0 wurde ein neues Speicher-Backend implementiert, was\njetzt in Helm 3 der Standard ist.\n\nDie Änderung zu Secrets in Helm 3 als Standard erlaubt einen Schutz der Charts\nin derselben Weise wie die Version der Secret Verschlüsselung in Kubernetes.\n\n[Verschlüsseung von Secrets mit Rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)\nwurde Standard als Alpha-Funktion in Kubernetes 1.7 und wurde stabil in\nKubernetes 1.13. Dies erlaubt Benutzer Versions Metadaten zu verschlüsseln\nund es ist ein guter Startpunkt, um später sowas wie Vault zu benutzen.\n\n### Go Import Pfadänderungen\n\nIn Helm 3 schaltete Helm den Go Importpfad von `k8s.io/helm` zu\n`helm.sh/helm/v3`. Wenn Sie 3 Go client Bibliotheken verwenden, stellen\nSie die Änderung des Importpfads sicher.\n\n### Capabilities\n\nDie Verfügbarkeit des eingebauten `.Capabilities` Objekts wurde im Stadium\ndes Renderns vereinfacht.\n\n[Eingebaute Objekte](/chart_template_guide/builtin_objects.md)\n\n### Validierung der Chart Values mit JSONSchema\n\nEin JSON Schema kann jetzt den Chart Values auferlegt werden. Das stellt\nsicher, dass die Werte, die der Nutzer eingegeben hat, dem Schemalayout\ndes Charts entsprechen, bessere Fehlermeldungen werden zur Verfügung\ngestellt, wenn falsche Werte für das Chart eingegeben wurden.\n\nEine Validierung erfolgt bei folgenden Kommandos:\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\nSehen Sie die Dokumentation zu [Schema Dateien](/topics/charts.md#schema-files) für\nmehr Informationen.\n\n### Konsolidierung von `requirements.yaml` in `Chart.yaml`\n\nDas Chart-Abhängigkeitssystem wechselte von requirements.yaml und\nrequirements.lock zu Chart.yaml und Chart.lock. Wir empfehlen, dass neue\nCharts für Helm 3 das neue Format verwenden. Helm 3 versteht jedoch weiterhin\ndie Chart API Version 1 (`v1`) und lädt vorhandene `requirements.yaml` Dateien.\n\nIn Helm 2 sah eine `requirements.yaml` so aus:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nIn Helm 3 sehen die Abhängigkeiten genauso aus, stehen aber in\n`Chart.yaml`:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nCharts werden weiterhin in das `charts/` Verzeichnis heruntergeladen, Subcharts\ngeliefert nach `charts/` werden ohne Anpassungen weiter funktionieren.\n\n### Name (oder --generate-name) ist jetzt zur Installation erforderlich\n\nWenn in Helm 2 kein Name angeben wurde, wurde einer autogeneriert. In der\nProduktion war das eher störend als hilfreich. In Helm 3 gibt es eine Fehlermeldung,\nwenn bei `helm install` kein Name angegeben wird.\n\nWer weiter einen autogenerierten Namen verwenden will, kann die Option\n`--generate-name` für sich benutzen.\n\n### Charts in OCI Registries hochladen\n\nDies ist eine experimentelle Funktion in Helm 3. Um sie zu benutzen, setzen Sie\ndie Umgebungsvariable `HELM_EXPERIMENTAL_OCI=1`.\n\nAuf einem hohen Level, ein Chart Repository ist ein Ort, an dem Charts gespeichert\nund geteilt werden können. Ein Helm Programm packt und schickt Helm Charts zu\neinem Chart Repository. Einfach ausgedrückt ist das ein simpler HTTP Server, \nder eine index.yaml Datei hat und einige gepackte Charts.\n\nWährend es für die meisten einfachen Speicheranforderungen nur Vorteile bringt,\ngibt es aber auch ein paar Nachteile:\n\n- Chart Repositories fällt es sehr schwer, die Sicherheitsanforderungen an eine\n  Produktionsumgebung zu erfüllen. Es ist sehr wichtig, eine Authentifizierung\n  und Authorisierung für die Standard API zu haben.\n- Helm Chart Herkunftswerkzeuge zum Signieren und Verifizieren der Integrität\n  sind optional für den Veröffentlichungsprozess.\n- In einer Mehrbenutzerumgebung kann dasselbe Chart von unterschiedlichen Nutzern\n  hochgeladen werden, kostet doppelten Speicher für denselben Inhalt, aber\n  das ist nicht Teil der Spezifikation.\n- Die Benutzung einer einzigen Indexdatei zum Suchen, Metadataeninformationen und\n  Herunterladen der Charts hat es kompliziert gemacht oder ist in einer sicheren\n  Mehrbenutzerumgebung unmöglich.\n\nDas Docker Distribution Projekt (auch bekannt als Docker Registry v2) ist der\nErfolgsfaktor des Docker Registry Projekts. Viele Cloud Lieferanten bieten\nein Produkt des Distribution Projekts an und da dies so viele sind, hat das\nDistribution Projekt in vielen Jahren Vorteile bezüglich Hardening, empfohlene\nVorgehensweisen und Kampftests.\n\nBitte schauen Sie nach `helm help chart` und `helm help registry` für mehr\nwie ein Chart zu packen und in eine Docker Registry zu laden ist.\n\nFür mehr Informationen schauen Sie [diese Seite](/topics/registries.md).\n\n### Löschen von `helm serve`\n\n`helm serve` startete eine lokales Chart Repository auf Ihrem Computer für\nEntwicklerzwecke. Nun, es wurde nicht viel angenommen und hatte zahlreiche\nProbleme mit seinem Design. Am Ende entschieden wir uns es zu löschen und\nals Plugin auszulagern.\n\nFür ähnliche Erfahrungen zu `helm serve` schauen Sie in die lokale\nDateisystemoption im \n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\nund das [servecm plugin](https://github.com/jdolitsky/helm-servecm).\n\n### Unterstützung für Chart Bibliotheken\n\nHelm 3 unterstützt eine Klasse von Charts genannt \"Chart Bibliotheken\". Das ist\nein Chart, was von anderen Charts geteilt wird, aber keine eigenen Versionsartefakte\nerstellt.\nEine Chart Bibliothek Vorlage kann nur `define` Elemente deklarieren. Global\nnicht-`define` definierter Inhalt wird ignoriert. Das erlaubt Nutzern, Code oder\nCodeschnippsel quer zwischen vielen Charts wiederzuverwenden und doppelten Code\nzu vermeiden ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)).\n\nChart Bibliotheken sind in der Abhängigkeitsdirektive in der Chart.yaml deklariert\nund werden installiert und verwaltet wie andere Charts.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nWir sind sehr stolz darauf, um Anwendungsfälle für diese Funktion von\nChartentwicklern und auch beste Beispiele der Nutzung zu sehen.\n\n### Chart.yaml apiVersion erhöht\n\nMit der Vorstellung der Chartbibliotheken, der Konsilidierung der\nrequirements.yaml in Chart.yaml würden Programme in Helm 2 Format\nnicht mehr funktionieren. So erhöhten wir die apiVersion in\nChart.yaml von `v1` zu `v2`.\n\n`helm create` erstellt Charts jetzt in diesem neuen Format, so wurde\ndie Standard apiVersion ebenfalls erhöht.\n\nProgramme möchten beide Versionen unterstützen und sollten das Feld\n`apiVersion` in Chart.yaml untersuchen, um zu verstehen, wie sie das\nPaketformat parsen sollen.\n\n### XDG Basis Verzeichnissupport\n\n[Die Spezifikation zu XDG Basis Verzeichnissupport](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)\nist ein portabler Standard, der Konfigurationen, Daten und Zwischenspeicherdateien\ndefiniert und wie sie im Dateisystem gespeichert werden sollen.\n\nIn Helm 2 speicherte Helm all diese Informationen in `~/.helm` (auch bekannt als\n`helm home`), was mit der Umgebungsvariable `$HELM_HOME` geändert werden konnte\noder auch durch die globale Option `--home`.\n\nIn Helm 3 respektiert Helm jetzt die folgenden Umgebungsvariablen gemäß der\nXDG-Basisverzeichnis-Spezifikation:\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nHelm Plugins beachten weiterhin für Abwärtskompatibilität `$HELM_HOME` als Alias\nfür `$XDG_DATA_HOME`.\n\nVerschiedene neue Umgebungsvariablen werden ebenfalls als Variablen des Plugins\neingeführt:\n\n- `$HELM_PATH_CACHE` für den Pfad zum Zwischenspeicher\n- `$HELM_PATH_CONFIG` für den Pfad zur Konfiguration\n- `$HELM_PATH_DATA` für den Pfad zu den Daten\n\nHelm Plugins, die Helm 3 unterstützen, sollten diese neuen Umgebungsvariablen\nnutzen.\n\n### Umbenennung von CLI-Kommandos\n\nUm sich an die Terminologie anderer Paketmanager anzupassen, wurde\n`helm delete` in `helm uninstall` umbenannt. `helm delete` funktioniert\nweiterhin als Alias für `helm uninstall` und kann weiter verwendet werden.\n\nIn Helm 2 musste die Option `--purge` angegeben werden, um den Release-Verlauf\nzu bereinigen. Diese Funktion ist jetzt standardmäßig aktiviert. Um das vorherige\nVerhalten beizubehalten, verwenden Sie `helm uninstall --keep-history`.\n\nZusätzlich wurden verschiedene andere Kommandos in ähnlicher Konvention\numbenannt:\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\nDiese Kommandos haben ihre alte Bedeutung als Alias beibehalten, sodass\nsie die weiter benutzen können.\n\n### Automatisch erstellter Namespace\n\nWenn eine Version in einem Namespace erstellt wird, der nicht existiert,\nhat Helm2 diesen angelegt. Helm 3 folgt den Konventionen von anderen\nKubernetes Werkzeugen und gibt eine Fehlermeldung zurück, wenn der Namespace\nnicht existiert. Helm 3 wird den Namespace mit der expliziten Option\n`--create-namespace` anlegen.\n\n### Was ist mit .Chart.ApiVersion passiert?\n\nHelm folgt der üblichen Konvention für CamelCasing, bei der Akronyme\ngroßgeschrieben werden. Wir haben das bereits an anderen Stellen im Code\nso umgesetzt, wie z.B. bei `.Capabilities.APIVersions.Has`. In Helm v3\nhaben wir `.Chart.ApiVersion` korrigiert und in `.Chart.APIVersion`\numbenannt, um dieser Konvention zu folgen.\n\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/faq/index.mdx",
    "content": "---\ntitle: \"Fragen und Antworten\"\nsidebar_position: 8\n---\n\n# Fragen und Antworten\n\n> Was sind die Kernunterschiede zwischen Helm 2 und Helm 3?\n> Diese Seite bietet Antworten zu oft gestelten Fragen (FAQ)\n\n**Wir möchten Ihre Hilfe**, um dieses Dokument besser zu machen. Um Informationen\nhinzuzufügen, korrigieren oder zu löschen, [füllen Sie ein Issue aus](https://github.com/helm/helm-www/issues)\noder senden Sie einne Pull Request.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: \"Installieren\"\nsidebar_position: 2\n---\n\n## Installieren\n\n### Warum gibt es keine nativen Pakete von Helm für Fedora oder andere Linuxdistributionen?\n\nDas Helm Projekt verwaltet keine Pakete für Betriebssysteme oder Umgebungen.\nDie Helm Gemeinschaft stellt möglicherweise native Pakete zur Verfügung\nund wenn es genug Aufmerksamkeit in der Gemeinschaft für ein Paket gibt,\nwird es vielleicht gelistet. So war es als Homebrew Formular startete und gelistet\nwurde. Wenn Sie interessiert sind, ein Paket zu verwalten, würden wir das \nsehr begrüßen.\n\n### Warum stellen Sie ein `curl ...|bash` Script zur Verfügung?\n\nEs ist ein Script in unserem Verzeichnis (`scripts/get-helm-3`), was als\n`curl ..|bash` ausgeführt werden kann. Die Übertragung ist durch HTTPS gesichert\nund das Script macht einige Überprüfungen beim Abruf. Aber egal, dieses\nScript hat alle Gefahren eines Shellscripts.\n\nWir stellen es zur Verfügung, weil es nützlich ist, aber empfehlen den Nutzern,\nes vor der ersten Ausführung gründlich zu lesen. Was wir wirklich möchten,\nist eine besser gepackte Version von Helm.\n\n### Wie lege ich die Dateien vom Helm Programm woanders hin?\n\nHelm benutzt die XDG Struktur zum Abspeichern von Dateien. Es gibt\nUmgebungsvariablen, die diese Lokation überschreiben können:\n\n- `$XDG_CACHE_HOME`: Setzt eine alternative Lokation für Zwischenspeicherdateien.\n- `$XDG_CONFIG_HOME`: Setzt eine alternative Lokation für Helm Konfiguration.\n- `$XDG_DATA_HOME`: Setzt eine alternative Lokation für Helm Daten.\n\nBeachten Sie, dass Sie existierende Repositories mit dem Kommando\n`helm repo add...` neu hinzufügen müssen.\n\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: \"Fehlersuche\"\nsidebar_position: 4\n---\n\n## Fehlersuche\n\n### Ich bekomme eine Warnung \"Unable to get an update from the \"stable\" chart repository\"\n\nFü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.\n\nMit folgendem Befehl können Sie Ihr Repository reparieren:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nDasselbe 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:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Ich bekomme die Warnung 'WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.'\n\nDas alte Google Helm Chart Repository wurde durch ein neues Helm Chart Repository ersetzt.\n\nFühren Sie folgenden Befehl aus, um das dauerhaft zu beheben:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nWenn Sie einen ähnlichen Fehler für `incubator` bekommen, führen Sie diesen Befehl aus:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Wenn ich ein Helm Repo hinzufüge, bekomme ich den Fehler 'Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available'\n\nDie 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`.\n\n### Auf GKE (Google Container Engine) bekomme ich \"No SSH tunnels currently open\"\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nEine andere Variante dieser Fehlermeldung ist:\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nDas Problem ist, dass Ihre lokale Kubernetes Konfigurationsdatei die richtigen Anmeldeinformationen enthalten muss.\n\nWenn 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.\n\n### Nach der Migration von Helm 2 zeigt `helm list` nur wenige oder gar keine Releases an\n\nWahrscheinlich 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:\n\n* den aktuellen Namespace im aktiven Kubernetes-Kontext verwenden (wie vom Befehl `kubectl config view --minify` beschrieben),\n* den korrekten Namespace mit der Option `--namespace`/`-n` angeben, oder\n* beim `helm list` Befehl die Option `--all-namespaces`/`-A` verwenden\n\nDies gilt für `helm ls`, `helm uninstall` und alle anderen `helm` Befehle, die sich auf ein Release beziehen.\n\n### In macOS wird auf die Datei `/etc/.mdns_debug` zugegriffen. Warum?\n\nWir 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.\n\nDies 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.\n\nWenn 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.\n\nDieses Problem wurde ursprünglich als potenzielles Sicherheitsproblem gemeldet. Es wurde jedoch festgestellt, dass dieses Verhalten keine Schwachstelle oder Sicherheitslücke darstellt.\n\n### helm repo add schlägt fehl, obwohl es früher funktioniert hat\n\nIn Helm 3.3.1 und früher gab der Befehl `helm repo add <reponame> <url>` 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.\n\nIn Helm 3.3.2 und später führt der Versuch, ein existierendes Repository hinzuzufügen, zu einem Fehler:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nDas 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.\n\nDies 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.\n\n### Kubernetes-Client-Protokollierung aktivieren\n\nDie 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.\n\nZum Beispiel:\n\n```\nhelm list -v 6\n```\n\n### Tiller-Installationen funktionieren nicht mehr und der Zugriff wird verweigert\n\nHelm-Releases waren früher unter <https://storage.googleapis.com/kubernetes-helm/> 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.\n\nWenn 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:\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\nDer [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:\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\ndurch:\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nUm mit Helm v2.17.0 zu initialisieren:\n\n`helm init —upgrade`\n\nOder 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:\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**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).\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: \"Deinstallieren\"\nsidebar_position: 3\n---\n\n## Deinstallieren\n\n### Ich möchte mein lokales Helm deinstallieren. Wo sind alle Dateien?\n\nNeben dem eigentlichen `helm` Programm speichert Helm Dateien an folgenden\nOrten:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nDie folgende Tabelle gibt die Standardspeicherorte je Betriebssystem an:\n\n| Betriebssystem   | Zwischenspeicherpfad        | Konfigurationspfad               | Datenpfad                 |\n|------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux            | `$HOME/.cache/helm `        | `$HOME/.config/helm `            | `$HOME/.local/share/helm` |\n| macOS            | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm `     |\n| Windows          | `%TEMP%\\helm  `             | `%APPDATA%\\helm `                | `%APPDATA%\\helm`          |\n\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/glossary/index.mdx",
    "content": "---\ntitle: \"Glossar\" \ndescription: \"Benutzte Ausdrücke zur Beschreibung der Komponenten der Helm Architektur.\"\nsidebar_position: 9\n---\n\n# Glossar\n\n## Chart\n\nEin Helm Paket was Informationen zum Installieren eines Sets von Kubernetes Resourcen\nin einem Kubernetes Cluster beinhaltet.\n\nCharts enthalten eine `Chart.yaml` Datei als auch Vorlagen, Standardwerte\n(`values.yaml`) und Abhängigkeiten.\n\nCharts werden in einer gut definierten Verzeichnisstruktur entwickelt und dann in ein\nArchiv gepackt, was sich _Chart Archiv_ nennt.\n\n## Chart Archiv\n\nEin _Chart Archiv_ ist ein mit tar und gzip gepacktes (und optimalerweise signiertes) Chart.\n\n## Chart Abhängigkeit (Subcharts)\n\nCharts können voneinander abgängen. Es gibt zwei Wege, diese Abhängigkeit herzustellen:\n\n- Weiche Abhängigkeit: Ein Chart funktioniert möglicherweise nicht ohne ein anderes Chart.\n  Helm stellt für diesen Fall kein Werkzeug zur Verfügung. Abhängigkeiten müssen separat\n  verwaltet werden.\n- Harte Abhängigkeit: Ein Chart enthält (innerhalb des `charts/` Verzeichnis) ein\n  anderes Chart, von dem es abhängt. In diesem Fall wird die Installation des Charts\n  alle Abhängigkeiten mit installieren. Charts und seine Abhängigkeiten werden als\n  Kollektion verwaltet.\n\nWenn ein Chart gepackt wird (mit `helm package`), werden alle harten Abhängigkeiten mit\ngebündelt.\n\n## Chart Version\n\nCharts sind versioniert nach [SemVer 2 Spezifikation](https://semver.org). Eine Versionsnummer\nist für jedes Chart erforderlich.\n\n## Chart.yaml\n\nInformationen über ein Chart werden in einer speziellen Datei namens `Chart.yaml` gespeichert.\nJedes Chart muss diese Datei haben.\n\n## Helm (und helm)\n\nHelm ist der Paket Manager für Kubernetes. Wie ein Paket Manager für das\nBetriebssystem das Installieren einfacher macht, kann man mit Helm einfacher\nApplikationen und Resourcen in Kubernetes Cluster installieren.\n\nDa _Helm_ der Name des Projekts ist, trägt das Kommandozeilenprogramm denselben\nNamen. Wenn wir vom Projekt sprechen, wird _Helm_ gross geschrieben. Sprechen\nwir vom Kommandozeilenprogramm, schreiben wie _helm_ klein.\n\n## Helm Konfigurationsdateien (XDG)\n\nHelm speichert seine Konfigurationsdateien in XDG Verzeichnissen. Diese\nVerzeichnisse werden erstellt, wenn helm zum ersten mal läuft.\n\n## Kube Config (KUBECONFIG)\n\nDas Helm Programm lernt Kubernetes Clusters durch die Benutzung des _Kube\nconfig_ Dateiformats. Standardmässig erwartet Helm, diese Datei an einem Platz\nzu finden, wo kubectl es erstellt hat (`$HOME/.kube/config`).\n\n## Lint (Linting)\n\nEin Chart mit _lint_ zu validieren, ist die Überprüfung, ob es den Konventionen\nund Anforderungen des Helm Chart Standards genügt. Helm stellt Werkzeuge zur\nVerfügung, allen voran das `helm lint` Kommando.\n\n## Provenance (Provenance file)\n\nHelm charts können von einem _provenance file_ begleitet sein, welches\nInformationen bereitstellt, wo das Chart herkommt und was es beinhaltet.\n\nHerkunftsdateien (Provenance files) sind ein Teil der Helm Sicherheit. Eine\n_provenance_ beinhaltet einen kryptographischen Hash der Chart Archiv Datei,\nder Chart.yaml Datei und eines Signaturblockes (ein OpenPGP \"clearsign\" Block).\nWenn dies an eine Schlüsselkette gekoppelt ist, können Benutzer:\n\n- validieren, von welchem vertrauenswürdigen Partner das Chart signiert wurde\n- validieren, dass die Chart Datei nicht manipuliert wurde\n- den Inhalt der Chart Metadaten validieren (`Chart.yaml`)\n- schnell vergleichen, dass das Chart mit seinen Herkunftsdaten übereinstimmt\n\nHerkunftsdateien haben die Erweiterungen `.prov` und können von einem Chart\nVerzeichnis Server oder einem anderen HTTP Server ausgeliefert werden.\n\n## Release (Version)\n\nWenn ein Chart installiert ist, erstellt die Helmbibliothek ein Version (_release_),\num nachzuvollziehen, was installiert wurde.\n\nEin einzelnes Chart wird möglicherweise mehrmals in denselben Cluster installiert\nund erstellt unterschiedliche Versionen. Zum Beispiel, ein Chart kann drei\nPostgreSQL Datenbanken mit demselben Kommando  `helm install` dreimal mit\nunterschiedlchen Versionsnamen installieren.\n\n## Release Number (Release Version)\n\nEine eintelne Version kann mehrmals aktualisiert werden. Ein sequentieller Zähler\nwird benutzt, um die Versionen nachzuvollziehen. Nach einem ersten `helm install`\nhat eine Version die _release number_ 1. Nach jeder Aktualisierung oder jedem\nZurückrollen wird die Versionsnummer erhöht.\n\n## Rollback (Zurückrollen)\n\nEine Version kann zu einem neuen Chart oder einer neuen Konfiguration\naktualisiert werden. Wenn die Versionshistorie gespeichert ist,\nkann eine Version zu einer vorherigen auch zurückgerollt werden (_rolles back_).\nDas passiert mit dem `helm rollback` Kommando.\n\nWichtig zu wissen, dass eine zurückgerollte Version eine neue Versionsnummer\ngeneriert.\n\n| Operation  | Release Number                                       |\n|------------|------------------------------------------------------|\n| install    | release 1                                            |\n| upgrade    | release 2                                            |\n| upgrade    | release 3                                            |\n| rollback 1 | release 4 (but running the same config as release 1) |\n\nDie obige Tabelle zeigt, wie Versionsnummern bei jeder Aktion wie Installieren,\nAktualisieren und Zurückrollen erhöht werden.\n\n## Helm Library (Helm Bibltiothek oder SDK)\n\nDie Helm Bibliothek (Library oder SDK) referenziert zum Go Code, der direkt\nmit dem Kubernetes API Server zum Installieren, Aktualisieren, Abfragen und\nLöschen von Kubernetes Resourcen interagiert. Sie kann zum Import in ein\nProjekt benutzt werden, um Helm in einer Bibliothek anstatt des\nKommandozeilenwerkzeugs zu verwenden.\n\n## Repository (Verzeichnis, Repo, Chart Repository)\n\nHelm Charts sind gespeichert in dedizierten HTTP Servern namens\n_chart repositories_ (_Verzeichnis_, _Repositories_ oder einfach _repos_).\n\nEin Chart Repository Server ist ein einfacher HTTP Server, der eine index.yaml\nDatei ausliefern kann, die eine Anzahl Charts beschreibt und Informationen\nbereitstellt, wo das Chart herunterzuladen ist.\n(Viele Chart Repositories liefern die Charts zusammen mit der `index.yam` Datei\naus.)\n\nEin Helm Programm kann zu null oder mehreren Chart Verzeichnissen zeigen.\nStandardmässig sind keine Verzeichnisse konfiguriert. Chart Verzeichnisse\nkönnen mit dem Kommando `helm repo add`  hinzugefügt werden.\n\n## Values (Values/Werte Dateien, values.yaml)\n\nValues (Werte) stellen einen Weg zur Verfügung, um Standards aus den Vorlagen\nzu überschreiben.\n\nHelm Charts sind \"parametisiert\", was bedeutet, dass die Chart Entwickler\nKonfigurationen nach aussen führen, die zur Installationszeit überschrieben\nwerden können. Zum Beispiel, ein Chart führt ein `username` Feld nach aussen,\nwas das Setzen eines Benutzernamens für diesen Dienst erlaubt.\n\nDiese nach aussen geführten Variablen werden in Helm _values_ genannt.\n\nValues können während `helm install` und `helm upgrade` gesetzt werden, entweder\ndirekt beim Aufruf oder in einer `values.yaml` Datei.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\nDer Helm-Paketmanager für Kubernetes.\n\n### Zusammenfassung\n\nDer Kubernetes-Paketmanager\n\nHäufige Aktionen für Helm:\n\n- helm search:    Suche nach Charts\n- helm pull:      Ein Chart in Ihr lokales Verzeichnis herunterladen, um es anzuzeigen\n- helm install:   Das Chart nach Kubernetes hochladen\n- helm list:      Releases von Charts auflisten\n\nUmgebungsvariablen:\n\n| Name                               | Beschreibung                                                                                               |\n|------------------------------------|------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | Alternativen Speicherort für zwischengespeicherte Dateien festlegen.                                       |\n| $HELM_CONFIG_HOME                  | Alternativen Speicherort für die Helm-Konfiguration festlegen.                                             |\n| $HELM_DATA_HOME                    | Alternativen Speicherort für Helm-Daten festlegen.                                                         |\n| $HELM_DEBUG                        | Gibt an, ob Helm im Debug-Modus ausgeführt wird.                                                           |\n| $HELM_DRIVER                       | Backend-Speichertreiber festlegen. Mögliche Werte: configmap, secret, memory, sql.                         |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | Verbindungszeichenfolge für den SQL-Speichertreiber festlegen.                                             |\n| $HELM_MAX_HISTORY                  | Maximale Anzahl der Helm-Release-Historie festlegen.                                                       |\n| $HELM_NAMESPACE                    | Namespace für Helm-Operationen festlegen.                                                                  |\n| $HELM_NO_PLUGINS                   | Plugins deaktivieren. Setzen Sie HELM_NO_PLUGINS=1, um Plugins zu deaktivieren.                            |\n| $HELM_PLUGINS                      | Pfad zum Plugins-Verzeichnis festlegen.                                                                    |\n| $HELM_REGISTRY_CONFIG              | Pfad zur Registry-Konfigurationsdatei festlegen.                                                           |\n| $HELM_REPOSITORY_CACHE             | Pfad zum Repository-Cache-Verzeichnis festlegen.                                                           |\n| $HELM_REPOSITORY_CONFIG            | Pfad zur Repositories-Datei festlegen.                                                                     |\n| $KUBECONFIG                        | Alternative Kubernetes-Konfigurationsdatei festlegen (Standard: \"~/.kube/config\")                          |\n| $HELM_KUBEAPISERVER                | Kubernetes-API-Server-Endpunkt für die Authentifizierung festlegen.                                        |\n| $HELM_KUBECAFILE                   | Kubernetes-Zertifizierungsstellen-Datei festlegen.                                                         |\n| $HELM_KUBEASGROUPS                 | Gruppen für die Identitätsannahme festlegen (kommagetrennte Liste).                                        |\n| $HELM_KUBEASUSER                   | Benutzername für die Identitätsannahme bei der Operation festlegen.                                        |\n| $HELM_KUBECONTEXT                  | Name des kubeconfig-Kontexts festlegen.                                                                    |\n| $HELM_KUBETOKEN                    | Bearer-KubeToken für die Authentifizierung festlegen.                                                      |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | Gibt an, ob die Zertifikatsvalidierung des Kubernetes-API-Servers übersprungen werden soll (unsicher).     |\n| $HELM_KUBETLS_SERVER_NAME          | Servernamen zur Validierung des Kubernetes-API-Server-Zertifikats festlegen.                               |\n| $HELM_BURST_LIMIT                  | Standard-Burst-Limit festlegen, falls der Server viele CRDs enthält (Standard: 100, -1 zum Deaktivieren).  |\n| $HELM_QPS                          | Abfragen pro Sekunde festlegen, wenn eine hohe Anzahl von Aufrufen höhere Burst-Werte erfordert.           |\n\nHelm speichert Cache, Konfiguration und Daten in folgender Konfigurationsreihenfolge:\n\n- Falls eine HELM_*_HOME-Umgebungsvariable gesetzt ist, wird diese verwendet\n- Andernfalls werden auf Systemen, die die XDG-Base-Directory-Spezifikation unterstützen, die XDG-Variablen verwendet\n- Wenn kein anderer Speicherort festgelegt ist, wird ein Standardspeicherort basierend auf dem Betriebssystem verwendet\n\nStandardmäßig hängen die Standardverzeichnisse vom Betriebssystem ab. Die Standardwerte sind unten aufgeführt:\n\n| Betriebssystem   | Cache-Pfad                | Konfigurations-Pfad            | Daten-Pfad              |\n|------------------|---------------------------|--------------------------------|-------------------------|\n| Linux            | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm |\n| macOS            | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm      |\n| Windows          | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm          |\n\n\n### Optionen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n  -h, --help                            help for helm\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm completion](/helm/helm_completion.md)\t - Generiert Autovervollständigungsskripte für die angegebene Shell\n* [helm create](/helm/helm_create.md)\t - Erstellt ein neues Chart mit dem angegebenen Namen\n* [helm dependency](/helm/helm_dependency.md)\t - Verwaltet die Abhängigkeiten eines Charts\n* [helm env](/helm/helm_env.md)\t - Informationen zur Helm-Client-Umgebung\n* [helm get](/helm/helm_get.md)\t - Lädt erweiterte Informationen für ein benanntes Release herunter\n* [helm history](/helm/helm_history.md)\t - Ruft die Release-Historie ab\n* [helm install](/helm/helm_install.md)\t - Installiert ein Chart\n* [helm lint](/helm/helm_lint.md)\t - Untersucht ein Chart auf mögliche Probleme\n* [helm list](/helm/helm_list.md)\t - Listet Releases auf\n* [helm package](/helm/helm_package.md)\t - Packt ein Chart-Verzeichnis in ein Chart-Archiv\n* [helm plugin](/helm/helm_plugin.md)\t - Installiert, listet oder deinstalliert Helm-Plugins\n* [helm pull](/helm/helm_pull.md)\t - Lädt ein Chart aus einem Repository herunter und entpackt es optional im lokalen Verzeichnis\n* [helm push](/helm/helm_push.md)\t - Pusht ein Chart zu einem Remote-Repository\n* [helm registry](/helm/helm_registry.md)\t - An- oder Abmeldung bei einer Registry\n* [helm repo](/helm/helm_repo.md)\t - Hinzufügen, Auflisten, Entfernen, Aktualisieren und Indizieren von Chart-Repositories\n* [helm rollback](/helm/helm_rollback.md)\t - Setzt ein Release auf eine frühere Revision zurück\n* [helm search](/helm/helm_search.md)\t - Durchsucht Charts nach einem Suchbegriff\n* [helm show](/helm/helm_show.md)\t - Zeigt Informationen eines Charts an\n* [helm status](/helm/helm_status.md)\t - Zeigt den Status des benannten Releases an\n* [helm template](/helm/helm_template.md)\t - Rendert Templates lokal\n* [helm test](/helm/helm_test.md)\t - Führt Tests für ein Release aus\n* [helm uninstall](/helm/helm_uninstall.md)\t - Deinstalliert ein Release\n* [helm upgrade](/helm/helm_upgrade.md)\t - Aktualisiert ein Release\n* [helm verify](/helm/helm_verify.md)\t - Überprüft, ob ein Chart am angegebenen Pfad signiert und gültig ist\n* [helm version](/helm/helm_version.md)\t - Gibt die Client-Versionsinformationen aus\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\nGeneriert Autovervollständigungsskripte für die angegebene Shell\n\n### Zusammenfassung\n\n\nGeneriert Autovervollständigungsskripte für Helm für die angegebene Shell.\n\n\n### Optionen\n\n```\n  -h, --help   Hilfe für completion\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 Client-seitiges Standard-Throttling-Limit (Standard: 100)\n      --debug                           Ausführliche Ausgabe aktivieren\n      --kube-apiserver string           Adresse und Port des Kubernetes-API-Servers\n      --kube-as-group stringArray       Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben.\n      --kube-as-user string             Benutzername, der für die Operation imitiert werden soll\n      --kube-ca-file string             Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung\n      --kube-context string             Name des kubeconfig-Kontexts, der verwendet werden soll\n      --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.\n      --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.\n      --kube-token string               Bearer-Token für die Authentifizierung\n      --kubeconfig string               Pfad zur kubeconfig-Datei\n  -n, --namespace string                Namespace-Geltungsbereich für diese Anfrage\n      --qps float32                     Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting)\n      --registry-config string          Pfad zur Registry-Konfigurationsdatei (Standard: \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: \"~/.cache/helm/repository\")\n      --repository-config string        Pfad zur Datei mit Repository-Namen und URLs (Standard: \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n* [helm completion bash](/helm/helm_completion_bash.md)\t - Generiert das Autovervollständigungsskript für bash\n* [helm completion fish](/helm/helm_completion_fish.md)\t - Generiert das Autovervollständigungsskript für fish\n* [helm completion powershell](/helm/helm_completion_powershell.md)\t - Generiert das Autovervollständigungsskript für powershell\n* [helm completion zsh](/helm/helm_completion_zsh.md)\t - Generiert das Autovervollständigungsskript für zsh\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\nGeneriert das Autovervollständigungsskript für bash\n\n### Zusammenfassung\n\nGeneriert das Helm-Autovervollständigungsskript für die bash-Shell.\n\nUm die Vervollständigungen in Ihrer aktuellen Shell-Sitzung zu laden:\n\n    source <(helm completion bash)\n\nUm die Vervollständigungen für jede neue Sitzung zu laden, führen Sie einmalig aus:\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n\n```\nhelm completion bash [flags]\n```\n\n### Optionen\n\n```\n  -h, --help              Hilfe für bash\n      --no-descriptions   Vervollständigungsbeschreibungen deaktivieren\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 Client-seitiges Standard-Throttling-Limit (Standard: 100)\n      --debug                           Ausführliche Ausgabe aktivieren\n      --kube-apiserver string           Adresse und Port des Kubernetes-API-Servers\n      --kube-as-group stringArray       Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben.\n      --kube-as-user string             Benutzername, der für die Operation imitiert werden soll\n      --kube-ca-file string             Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung\n      --kube-context string             Name des kubeconfig-Kontexts, der verwendet werden soll\n      --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.\n      --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.\n      --kube-token string               Bearer-Token für die Authentifizierung\n      --kubeconfig string               Pfad zur kubeconfig-Datei\n  -n, --namespace string                Namespace-Geltungsbereich für diese Anfrage\n      --qps float32                     Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting)\n      --registry-config string          Pfad zur Registry-Konfigurationsdatei (Standard: \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: \"~/.cache/helm/repository\")\n      --repository-config string        Pfad zur Datei mit Repository-Namen und URLs (Standard: \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm completion](/helm/helm_completion.md)\t - Generiert Autovervollständigungsskripte für die angegebene Shell\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\nGeneriert das Autovervollständigungsskript für fish\n\n### Zusammenfassung\n\nGeneriert das Helm-Autovervollständigungsskript für die fish-Shell.\n\nUm die Vervollständigungen in Ihrer aktuellen Shell-Sitzung zu laden:\n\n    helm completion fish | source\n\nUm die Vervollständigungen für jede neue Sitzung zu laden, führen Sie einmalig aus:\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\nSie müssen eine neue Shell starten, damit diese Einrichtung wirksam wird.\n\n\n```\nhelm completion fish [flags]\n```\n\n### Optionen\n\n```\n  -h, --help              Hilfe für fish\n      --no-descriptions   Vervollständigungsbeschreibungen deaktivieren\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 Client-seitiges Standard-Throttling-Limit (Standard: 100)\n      --debug                           Ausführliche Ausgabe aktivieren\n      --kube-apiserver string           Adresse und Port des Kubernetes-API-Servers\n      --kube-as-group stringArray       Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben.\n      --kube-as-user string             Benutzername, der für die Operation imitiert werden soll\n      --kube-ca-file string             Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung\n      --kube-context string             Name des kubeconfig-Kontexts, der verwendet werden soll\n      --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.\n      --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.\n      --kube-token string               Bearer-Token für die Authentifizierung\n      --kubeconfig string               Pfad zur kubeconfig-Datei\n  -n, --namespace string                Namespace-Geltungsbereich für diese Anfrage\n      --qps float32                     Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting)\n      --registry-config string          Pfad zur Registry-Konfigurationsdatei (Standard: \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: \"~/.cache/helm/repository\")\n      --repository-config string        Pfad zur Datei mit Repository-Namen und URLs (Standard: \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm completion](/helm/helm_completion.md)\t - Generiert Autovervollständigungsskripte für die angegebene Shell\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\nGeneriert das Autovervollständigungsskript für PowerShell\n\n### Zusammenfassung\n\nGeneriert das Autovervollständigungsskript für PowerShell.\n\nUm die Vervollständigungen in Ihrer aktuellen Shell-Sitzung zu laden:\n\n    PS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\nUm die Vervollständigungen für jede neue Sitzung zu laden, fügen Sie die Ausgabe des obigen Befehls zu Ihrem PowerShell-Profil hinzu.\n\n\n```\nhelm completion powershell [flags]\n```\n\n### Optionen\n\n```\n  -h, --help              Hilfe für powershell\n      --no-descriptions   Vervollständigungsbeschreibungen deaktivieren\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 Client-seitiges Standard-Throttling-Limit (Standard: 100)\n      --debug                           Ausführliche Ausgabe aktivieren\n      --kube-apiserver string           Adresse und Port des Kubernetes-API-Servers\n      --kube-as-group stringArray       Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben.\n      --kube-as-user string             Benutzername, der für die Operation imitiert werden soll\n      --kube-ca-file string             Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung\n      --kube-context string             Name des kubeconfig-Kontexts, der verwendet werden soll\n      --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.\n      --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.\n      --kube-token string               Bearer-Token für die Authentifizierung\n      --kubeconfig string               Pfad zur kubeconfig-Datei\n  -n, --namespace string                Namespace-Geltungsbereich für diese Anfrage\n      --qps float32                     Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting)\n      --registry-config string          Pfad zur Registry-Konfigurationsdatei (Standard: \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: \"~/.cache/helm/repository\")\n      --repository-config string        Pfad zur Datei mit Repository-Namen und URLs (Standard: \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm completion](/helm/helm_completion.md)\t - Generiert Autovervollständigungsskripte für die angegebene Shell\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\nGeneriert das Autovervollständigungsskript für zsh\n\n### Zusammenfassung\n\nGeneriert das Helm-Autovervollständigungsskript für die zsh-Shell.\n\nUm die Vervollständigungen in Ihrer aktuellen Shell-Sitzung zu laden:\n\n    source <(helm completion zsh)\n\nUm die Vervollständigungen für jede neue Sitzung zu laden, führen Sie einmalig aus:\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### Optionen\n\n```\n  -h, --help              Hilfe für zsh\n      --no-descriptions   Vervollständigungsbeschreibungen deaktivieren\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 Client-seitiges Standard-Throttling-Limit (Standard: 100)\n      --debug                           Ausführliche Ausgabe aktivieren\n      --kube-apiserver string           Adresse und Port des Kubernetes-API-Servers\n      --kube-as-group stringArray       Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben.\n      --kube-as-user string             Benutzername, der für die Operation imitiert werden soll\n      --kube-ca-file string             Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung\n      --kube-context string             Name des kubeconfig-Kontexts, der verwendet werden soll\n      --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.\n      --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.\n      --kube-token string               Bearer-Token für die Authentifizierung\n      --kubeconfig string               Pfad zur kubeconfig-Datei\n  -n, --namespace string                Namespace-Geltungsbereich für diese Anfrage\n      --qps float32                     Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting)\n      --registry-config string          Pfad zur Registry-Konfigurationsdatei (Standard: \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: \"~/.cache/helm/repository\")\n      --repository-config string        Pfad zur Datei mit Repository-Namen und URLs (Standard: \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm completion](/helm/helm_completion.md)\t - Generiert Autovervollständigungsskripte für die angegebene Shell\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n\nErstellt ein neues Chart mit dem angegebenen Namen\n\n### Zusammenfassung\n\nDieser Befehl erstellt ein Chart-Verzeichnis mit den üblichen Dateien und Verzeichnissen, die in einem Chart verwendet werden.\n\nBeispielsweise erstellt 'helm create foo' eine Verzeichnisstruktur, die in etwa so aussieht:\n\n    foo/\n    ├── .helmignore   # Enthält Muster für Dateien, die beim Packen von Helm-Charts ignoriert werden sollen.\n    ├── Chart.yaml    # Informationen über Ihr Chart\n    ├── values.yaml   # Die Standardwerte für Ihre Templates\n    ├── charts/       # Charts, von denen dieses Chart abhängt\n    └── templates/    # Die Template-Dateien\n        └── tests/    # Die Testdateien\n\n'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.\n\n\n```\nhelm create NAME [flags]\n```\n\n### Optionen\n\n```\n  -h, --help             Hilfe für create\n  -p, --starter string   Name oder absoluter Pfad zu einer Helm-Starter-Vorlage\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 Client-seitiges Standard-Throttling-Limit (Standard: 100)\n      --debug                           Ausführliche Ausgabe aktivieren\n      --kube-apiserver string           Adresse und Port des Kubernetes-API-Servers\n      --kube-as-group stringArray       Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben.\n      --kube-as-user string             Benutzername, der für die Operation imitiert werden soll\n      --kube-ca-file string             Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung\n      --kube-context string             Name des kubeconfig-Kontexts, der verwendet werden soll\n      --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.\n      --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.\n      --kube-token string               Bearer-Token für die Authentifizierung\n      --kubeconfig string               Pfad zur kubeconfig-Datei\n  -n, --namespace string                Namespace-Geltungsbereich für diese Anfrage\n      --qps float32                     Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting)\n      --registry-config string          Pfad zur Registry-Konfigurationsdatei (Standard: \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: \"~/.cache/helm/repository\")\n      --repository-config string        Pfad zur Datei mit Repository-Namen und URLs (Standard: \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\nVerwaltet die Abhängigkeiten eines Charts\n\n### Zusammenfassung\n\nVerwaltet die Abhängigkeiten eines Charts.\n\nHelm Charts speichern ihre Abhängigkeiten im Verzeichnis 'charts/'. Für Chart-Entwickler\nist es oft einfacher, die Abhängigkeiten in der 'Chart.yaml' zu verwalten, die alle\nAbhängigkeiten deklariert.\n\nDie Dependency-Befehle arbeiten mit dieser Datei und erleichtern die Synchronisation\nzwischen den gewünschten Abhängigkeiten und den tatsächlich im Verzeichnis 'charts/'\ngespeicherten Abhängigkeiten.\n\nBeispielsweise deklariert diese Chart.yaml zwei Abhängigkeiten:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\nDas Feld 'name' sollte den Namen eines Charts enthalten. Dieser muss mit dem Eintrag\nin der 'Chart.yaml'-Datei des jeweiligen Charts übereinstimmen.\n\nDas Feld 'version' sollte eine semantische Version oder einen Versionsbereich enthalten.\n\nDie 'repository'-URL sollte auf ein Chart Repository verweisen. Helm erwartet, dass\ndurch Anhängen von '/index.yaml' an die URL der Index des Chart Repositorys abgerufen\nwerden kann. Hinweis: 'repository' kann ein Alias sein. Der Alias muss mit 'alias:'\noder '@' beginnen.\n\nAb Version 2.2.0 kann repository auch als Pfad zum Verzeichnis der lokal gespeicherten\nAbhängigkeits-Charts definiert werden. Der Pfad sollte mit dem Präfix \"file://\" beginnen.\nZum Beispiel:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\nWenn das Abhängigkeits-Chart lokal abgerufen wird, ist es nicht erforderlich, das\nRepository mit \"helm repo add\" zu Helm hinzuzufügen. Auch der Versionsabgleich wird\nin diesem Fall unterstützt.\n\n\n### Optionen\n\n```\n  -h, --help   help for dependency\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n* [helm dependency build](/helm/helm_dependency_build.md)\t - Erstellt das Verzeichnis charts/ basierend auf der Chart.lock-Datei neu\n* [helm dependency list](/helm/helm_dependency_list.md)\t - Listet die Abhängigkeiten für das angegebene Chart auf\n* [helm dependency update](/helm/helm_dependency_update.md)\t - Aktualisiert charts/ entsprechend dem Inhalt von Chart.yaml\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\nErstellt das Verzeichnis charts/ basierend auf der Chart.lock-Datei neu\n\n### Zusammenfassung\n\nBaut das Verzeichnis charts/ anhand der Chart.lock-Datei auf.\n\nDieser Befehl stellt die Abhängigkeiten eines Charts auf den Stand der Lock-Datei\nwieder her. Im Gegensatz zu 'helm dependency update' werden die Abhängigkeiten\ndabei nicht neu ausgehandelt.\n\nFalls keine Lock-Datei gefunden wird, verhält sich 'helm dependency build' wie\n'helm dependency update'.\n\n\n```\nhelm dependency build CHART [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for build\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm dependency](/helm/helm_dependency.md)\t - Verwaltet die Abhängigkeiten eines Charts\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\nListet die Abhängigkeiten für das angegebene Chart auf\n\n### Zusammenfassung\n\nListet alle in einem Chart deklarierten Abhängigkeiten auf.\n\nDieser Befehl akzeptiert Chart-Archive und Chart-Verzeichnisse als Eingabe.\nEr verändert den Inhalt des Charts nicht.\n\nFalls das Chart nicht geladen werden kann, wird ein Fehler ausgegeben.\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### Optionen\n\n```\n  -h, --help                 help for list\n      --max-col-width uint   maximum column width for output table (default 80)\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm dependency](/helm/helm_dependency.md)\t - Verwaltet die Abhängigkeiten eines Charts\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\nAktualisiert charts/ entsprechend dem Inhalt von Chart.yaml\n\n### Zusammenfassung\n\nAktualisiert die lokalen Abhängigkeiten entsprechend der Chart.yaml.\n\nDieser Befehl überprüft, ob die in 'Chart.yaml' angegebenen erforderlichen Charts\nim Verzeichnis 'charts/' vorhanden sind und eine passende Version haben. Er lädt\ndie neuesten Charts herunter, die die Abhängigkeiten erfüllen, und entfernt veraltete\nAbhängigkeiten.\n\nBei erfolgreicher Aktualisierung wird eine Lock-Datei erstellt, mit der die\nAbhängigkeiten auf eine exakte Version wiederhergestellt werden können.\n\nAbhängigkeiten müssen nicht zwingend in 'Chart.yaml' aufgeführt sein. Aus diesem\nGrund entfernt der update-Befehl Charts nur dann, wenn sie (a) in der Chart.yaml-Datei\nvorhanden sind, aber (b) die falsche Version haben.\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for update\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm dependency](/helm/helm_dependency.md)\t - Verwaltet die Abhängigkeiten eines Charts\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\nInformationen zur Helm-Client-Umgebung\n\n### Zusammenfassung\n\n\nEnv gibt alle von Helm verwendeten Umgebungsinformationen aus.\n\n\n```\nhelm env [flags]\n```\n\n### Optionen\n\n```\n  -h, --help   help for env\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\nLädt erweiterte Informationen für ein benanntes Release herunter\n\n### Zusammenfassung\n\nDieser Befehl besteht aus mehreren Unterbefehlen, um erweiterte\nInformationen über ein Release abzurufen, darunter:\n\n- Die zur Generierung des Releases verwendeten Values\n- Die generierte Manifest-Datei\n- Die vom Chart bereitgestellten Notizen zum Release\n- Die mit dem Release verbundenen Hooks\n- Die Metadaten des Releases\n\n\n### Optionen\n\n```\n  -h, --help   help for get\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n* [helm get all](/helm/helm_get_all.md)\t - Lädt alle Informationen für ein benanntes Release herunter\n* [helm get hooks](/helm/helm_get_hooks.md)\t - Lädt alle Hooks für ein benanntes Release herunter\n* [helm get manifest](/helm/helm_get_manifest.md)\t - Lädt das Manifest für ein benanntes Release herunter\n* [helm get metadata](/helm/helm_get_metadata.md)\t - Ruft Metadaten für ein bestimmtes Release ab\n* [helm get notes](/helm/helm_get_notes.md)\t - Lädt die Notizen für ein benanntes Release herunter\n* [helm get values](/helm/helm_get_values.md)\t - Lädt die Values-Datei für ein benanntes Release herunter\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\nLädt alle Informationen für ein benanntes Release herunter\n\n### Zusammenfassung\n\nDieser Befehl gibt eine lesbare Sammlung von Informationen über die\nNotizen, Hooks, übergebene Values und die generierte Manifest-Datei\ndes angegebenen Releases aus.\n\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### Optionen\n\n```\n  -h, --help              help for all\n      --revision int      get the named release with revision\n      --template string   go template for formatting the output, eg: {{.Release.Name}}\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm get](/helm/helm_get.md)\t - Lädt erweiterte Informationen zu einem benannten Release herunter\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\nLädt alle Hooks für ein benanntes Release herunter\n\n### Zusammenfassung\n\nDieser Befehl lädt die Hooks für ein bestimmtes Release herunter.\n\nDie Hooks werden im YAML-Format ausgegeben und durch den YAML-Trenner '---\\n' voneinander getrennt.\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Optionen\n\n```\n  -h, --help           help for hooks\n      --revision int   get the named release with revision\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm get](/helm/helm_get.md)\t - Lädt erweiterte Informationen zu einem benannten Release herunter\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\nLädt das Manifest für ein benanntes Release herunter\n\n### Zusammenfassung\n\nDieser Befehl ruft das generierte Manifest für ein bestimmtes Release ab.\n\nEin 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.\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### Optionen\n\n```\n  -h, --help           help for manifest\n      --revision int   get the named release with revision\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm get](/helm/helm_get.md)\t - Lädt erweiterte Informationen zu einem benannten Release herunter\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\nRuft die Metadaten für ein bestimmtes Release ab\n\n### Zusammenfassung\n\nDieser Befehl ruft die Metadaten für ein bestimmtes Release ab.\n\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### Optionen\n\n```\n  -h, --help            help for metadata\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    specify release revision\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm get](/helm/helm_get.md)\t - Lädt erweiterte Informationen zu einem benannten Release herunter\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\nLädt die Notizen für ein benanntes Release herunter\n\n### Zusammenfassung\n\nDieser Befehl zeigt die vom Chart bereitgestellten Notizen für ein benanntes Release an.\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### Optionen\n\n```\n  -h, --help           help for notes\n      --revision int   get the named release with revision\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm get](/helm/helm_get.md)\t - Lädt erweiterte Informationen zu einem benannten Release herunter\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\nLädt die Values-Datei für ein benanntes Release herunter\n\n### Zusammenfassung\n\nDieser Befehl lädt die Values-Datei für ein bestimmtes Release herunter.\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### Optionen\n\n```\n  -a, --all             dump all (computed) values\n  -h, --help            help for values\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    get the named release with revision\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm get](/helm/helm_get.md)\t - Lädt erweiterte Informationen zu einem benannten Release herunter\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\nZeigt die Release-Historie an\n\n### Zusammenfassung\n\nHistory gibt die historischen Revisionen für ein bestimmtes Release aus.\n\nStandardmäßig werden maximal 256 Revisionen zurückgegeben. Mit '--max' können Sie die maximale Länge der zurückgegebenen Revisionsliste konfigurieren.\n\nDie historischen Releases werden als formatierte Tabelle ausgegeben, z.B.:\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### Optionen\n\n```\n  -h, --help            help for history\n      --max int         maximum number of revision to include in history (default 256)\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\nInstalliert ein Chart\n\n### Zusammenfassung\n\nDieser Befehl installiert ein Chart-Archiv.\n\nAls 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.\n\nZum Ü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.\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\noder\n\n    $ helm install --set name=prod myredis ./redis\n\noder\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\noder\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\noder\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\nDas '--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:\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\nDas '--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:\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\nIm folgenden Beispiel wird 'foo' entsprechend auf '[\"four\"]' gesetzt:\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\nUnd im folgenden Beispiel wird 'foo' auf '{\"key1\":\"value1\",\"key2\":\"bar\"}' gesetzt:\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\nUm die generierten Manifeste eines Releases zu prüfen, ohne das Chart zu installieren, können die Flags --debug und --dry-run kombiniert werden.\n\nDas --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.\n\nWenn --verify gesetzt ist, MUSS das Chart eine Provenance-Datei haben, und die Provenance-Datei MUSS alle Verifizierungsschritte bestehen.\n\nEs gibt sechs verschiedene Möglichkeiten, das zu installierende Chart anzugeben:\n\n1. Per Chart-Referenz: helm install mymaria example/mariadb\n2. Per Pfad zu einem gepackten Chart: helm install mynginx ./nginx-1.2.3.tgz\n3. Per Pfad zu einem entpackten Chart-Verzeichnis: helm install mynginx ./nginx\n4. Per absolute URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. Per Chart-Referenz und Repository-URL: helm install --repo https://example.com/charts/ mynginx nginx\n6. Per OCI-Registry: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\nCHART-REFERENZEN\n\nEine Chart-Referenz ist eine praktische Methode, um auf ein Chart in einem Chart-Repository zu verweisen.\n\nWenn 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.\n\nUm die Liste der Chart-Repositories anzuzeigen, verwenden Sie 'helm repo list'. Um nach Charts in einem Repository zu suchen, verwenden Sie 'helm search'.\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### Optionen\n\n```\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for install\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\nUntersucht ein Chart auf mögliche Probleme\n\n### Zusammenfassung\n\nDieser 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.\n\nWenn 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.\n\n\n```\nhelm lint PATH [flags]\n```\n\n### Optionen\n\n```\n  -h, --help                      help for lint\n      --kube-version string       Kubernetes version used for capabilities and deprecation checks\n      --quiet                     print only warnings and errors\n      --set stringArray           set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray      set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray   set a literal STRING value on the command line\n      --set-string stringArray    set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-schema-validation    if set, disables JSON schema validation\n      --strict                    fail on lint warnings\n  -f, --values strings            specify values in a YAML file or a URL (can specify multiple)\n      --with-subcharts            lint dependent charts\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\nListet Releases auf\n\n### Zusammenfassung\n\nDieser Befehl listet alle Releases für einen angegebenen Namespace auf. Wird kein Namespace angegeben, wird der aktuelle Namespace-Kontext verwendet.\n\nStandardmäß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'.\n\nStandardmäßig werden Elemente alphabetisch sortiert. Verwenden Sie das Flag '-d', um nach Release-Datum zu sortieren.\n\nWenn 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.\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\nWenn 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).\n\nStandardmäß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.\n\n\n```\nhelm list [flags]\n```\n\n### Optionen\n\n```\n  -a, --all                  show all releases without any filter applied\n  -A, --all-namespaces       list releases across all namespaces\n  -d, --date                 sort by release date\n      --deployed             show deployed releases. If no other is specified, this will be automatically enabled\n      --failed               show failed releases\n  -f, --filter string        a regular expression (Perl compatible). Any releases that match the expression will be included in the results\n  -h, --help                 help for list\n  -m, --max int              maximum number of releases to fetch (default 256)\n      --no-headers           don't print headers when using the default output format\n      --offset int           next release index in the list, used to offset from start value\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pending              show pending releases\n  -r, --reverse              reverse the sort order\n  -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.\n  -q, --short                output short (quiet) listing format\n      --superseded           show superseded releases\n      --time-format string   format time using golang time formatter. Example: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          show uninstalled releases (if 'helm uninstall --keep-history' was used)\n      --uninstalling         show releases that are currently being uninstalled\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\nEin Chart-Verzeichnis in ein Chart-Archiv paketieren\n\n### Zusammenfassung\n\nDieser 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.\n\nVersionierte Chart-Archive werden von Helm-Repositorys verwendet.\n\nUm 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.\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\nWenn '--keyring' nicht angegeben wird, verwendet Helm standardmäßig den öffentlichen Schlüsselbund, es sei denn, Ihre Umgebung ist anders konfiguriert.\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Optionen\n\n```\n      --app-version string         set the appVersion on the chart to this version\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -u, --dependency-update          update dependencies from \"Chart.yaml\" to dir \"charts/\" before packaging\n  -d, --destination string         location to write the chart. (default \".\")\n      -h, --help                       help for package\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key string                 name of the key to use when signing. Used if --sign is true\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of a public keyring (default \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     location of a file which contains the passphrase for the signing key. Use \"-\" in order to read from stdin.\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --sign                       use a PGP private key to sign this package\n      --username string            chart repository username where to locate the requested chart\n      --version string             set the version on the chart to this semver version\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\nHelm Plugins installieren, auflisten oder deinstallieren\n\n### Übersicht\n\nVerwaltet clientseitige Helm Plugins.\n\n### Optionen\n\n```\n  -h, --help   help for plugin\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n* [helm plugin install](/helm/helm_plugin_install.md)\t - Installiert ein Helm-Plugin\n* [helm plugin list](/helm/helm_plugin_list.md)\t - Listet installierte Helm Plugins auf\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md)\t - Deinstalliert ein oder mehrere Helm Plugins\n* [helm plugin update](/helm/helm_plugin_update.md)\t - Aktualisiert ein oder mehrere Helm Plugins\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\nInstalliert ein Helm-Plugin\n\n### Übersicht\n\nMit diesem Befehl können Sie ein Plugin von der URL eines VCS-Repositorys oder von einem lokalen Pfad installieren.\n\n```\nhelm plugin install [options] <path|url> [flags]\n```\n\n### Optionen\n\n```\n  -h, --help             help for install\n      --version string   specify a version constraint. If this is not specified, the latest version is installed\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm plugin](/helm/helm_plugin.md)\t - Helm-Plugins installieren, auflisten oder deinstallieren\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\nListet installierte Helm Plugins auf\n\n```\nhelm plugin list [flags]\n```\n\n### Optionen\n\n```\n  -h, --help   help for list\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm plugin](/helm/helm_plugin.md)\t - Helm Plugins installieren, auflisten oder deinstallieren\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\nDeinstalliert ein oder mehrere Helm Plugins\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Optionen\n\n```\n  -h, --help   help for uninstall\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm plugin](/helm/helm_plugin.md)\t - Helm Plugins installieren, auflisten oder deinstallieren\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\nAktualisiert ein oder mehrere Helm Plugins\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### Optionen\n\n```\n  -h, --help   help for update\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm plugin](/helm/helm_plugin.md)\t - Helm Plugins installieren, auflisten oder deinstallieren\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\nEin Chart aus einem Repository herunterladen und (optional) lokal entpacken\n\n### Zusammenfassung\n\nLädt ein Paket aus einem Chart-Repository herunter und speichert es lokal.\n\nDamit 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.\n\nMit entsprechenden Optionen kann das Chart nach dem Herunterladen entpackt werden. Dabei wird ein Verzeichnis für das Chart erstellt und der Inhalt dorthin extrahiert.\n\nBei 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.\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -d, --destination string         location to write the chart. If this and untardir are specified, untardir is appended to this (default \".\")\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help                       help for pull\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --prov                       fetch the provenance file, but don't perform verification\n      --repo string                chart repository url where to locate the requested chart\n      --untar                      if set to true, will untar the chart after downloading it\n      --untardir string            if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default \".\")\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\nEin Chart in eine Registry hochladen\n\n### Zusammenfassung\n\n\nLädt ein Chart in eine Registry hoch.\n\nFalls das Chart eine zugehörige Provenance-Datei hat,\nwird diese ebenfalls hochgeladen.\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify registry client using this SSL certificate file\n  -h, --help                       help for push\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart upload\n      --key-file string            identify registry client using this SSL key file\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart upload\n      --username string            chart repository username where to locate the requested chart\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\nBei einer Registry an- oder abmelden\n\n### Zusammenfassung\n\n\nDieser Befehl besteht aus mehreren Unterbefehlen zur Interaktion mit Registries.\n\n\n### Optionen\n\n```\n  -h, --help   help for registry\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n* [helm registry login](/helm/helm_registry_login.md)\t - Bei einer Registry anmelden\n* [helm registry logout](/helm/helm_registry_logout.md)\t - Von einer Registry abmelden\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\nBei einer Registry anmelden\n\n### Zusammenfassung\n\n\nAuthentifiziert sich bei einer entfernten Registry.\n\n\n```\nhelm registry login [host] [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string     verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string   identify registry client using this SSL certificate file\n  -h, --help               help for login\n      --insecure           allow connections to TLS registry without certs\n      --key-file string    identify registry client using this SSL key file\n  -p, --password string    registry password or identity token\n      --password-stdin     read password or identity token from stdin\n      --plain-http         use insecure HTTP connections for the chart upload\n  -u, --username string    registry username\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm registry](/helm/helm_registry.md)\t - Bei einer Registry an- oder abmelden\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\nVon einer Registry abmelden\n\n### Zusammenfassung\n\n\nEntfernt die gespeicherten Anmeldeinformationen für eine entfernte Registry.\n\n\n```\nhelm registry logout [host] [flags]\n```\n\n### Optionen\n\n```\n  -h, --help   help for logout\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm registry](/helm/helm_registry.md)\t - Bei einer Registry an- oder abmelden\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\nChart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren\n\n### Zusammenfassung\n\n\nDieser Befehl besteht aus mehreren Unterbefehlen zur Interaktion mit Chart Repositories.\n\nMit diesem Befehl können Sie Chart Repositories hinzufügen, entfernen, auflisten und indizieren.\n\n\n### Optionen\n\n```\n  -h, --help   help for repo\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n* [helm repo add](/helm/helm_repo_add.md)\t - Fügt ein Chart Repository hinzu\n* [helm repo index](/helm/helm_repo_index.md)\t - Erstellt eine Indexdatei für ein Verzeichnis mit gepackten Charts\n* [helm repo list](/helm/helm_repo_list.md)\t - Listet Chart Repositories auf\n* [helm repo remove](/helm/helm_repo_remove.md)\t - Entfernt ein oder mehrere Chart Repositories\n* [helm repo update](/helm/helm_repo_update.md)\t - Aktualisiert lokal die Informationen über verfügbare Charts aus den Chart Repositories\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\nFügt ein Chart Repository hinzu\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Optionen\n\n```\n      --allow-deprecated-repos     by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --force-update               replace (overwrite) the repo if it already exists\n  -h, --help                       help for add\n      --insecure-skip-tls-verify   skip tls certificate checks for the repository\n      --key-file string            identify HTTPS client using this SSL key file\n      --no-update                  Ignored. Formerly, it would disabled forced updates. It is deprecated by force-update.\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password\n      --password-stdin             read chart repository password from stdin\n      --timeout duration           time to wait for the index file download to complete (default 2m0s)\n      --username string            chart repository username\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm repo](/helm/helm_repo.md)\t - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\nErstellt eine Indexdatei aus einem Verzeichnis mit gepackten Charts\n\n### Zusammenfassung\n\nLiest das aktuelle Verzeichnis und erstellt basierend auf den gefundenen Charts eine Indexdatei.\nDas Ergebnis wird in 'index.yaml' im aktuellen Verzeichnis geschrieben.\n\nDieses Werkzeug wird verwendet, um eine 'index.yaml'-Datei für ein Chart Repository zu erstellen.\nUm eine absolute URL für die Charts festzulegen, verwenden Sie das Flag '--url'.\n\nUm den generierten Index mit einer bestehenden Indexdatei zusammenzuführen, verwenden Sie das\nFlag '--merge'. In diesem Fall werden die Charts aus dem aktuellen Verzeichnis mit dem\nübergebenen Index zusammengeführt, wobei lokale Charts Vorrang vor bestehenden Charts haben.\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### Optionen\n\n```\n  -h, --help           help for index\n      --json           output in JSON format\n      --merge string   merge the generated index into the given index\n      --url string     url of chart repository\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm repo](/helm/helm_repo.md)\t - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\nListet Chart Repositories auf\n\n```\nhelm repo list [flags]\n```\n\n### Optionen\n\n```\n  -h, --help            help for list\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm repo](/helm/helm_repo.md)\t - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nEntfernt ein oder mehrere Chart Repositories\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Optionen\n\n```\n  -h, --help   help for remove\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm repo](/helm/helm_repo.md)\t - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\nAktualisiert lokal die Informationen über verfügbare Charts aus den Chart Repositories\n\n### Zusammenfassung\n\nDieser Befehl lädt die neuesten Informationen über Charts aus den jeweiligen Chart Repositories herunter.\nDie Informationen werden lokal zwischengespeichert und von Befehlen wie 'helm search' verwendet.\n\nSie können optional eine Liste von Repositories angeben, die Sie aktualisieren möchten.\n\t$ helm repo update <repo_name> ...\nUm alle Repositories zu aktualisieren, verwenden Sie 'helm repo update'.\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Optionen\n\n```\n      --fail-on-repo-update-fail   update fails if any of the repository updates fail\n  -h, --help                       help for update\n      --timeout duration           time to wait for the index file download to complete (default 2m0s)\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm repo](/helm/helm_repo.md)\t - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\nSetzt ein Release auf eine vorherige Revision zurück\n\n### Zusammenfassung\n\nDieser Befehl setzt ein Release auf eine vorherige Revision zurück.\n\nDas 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.\n\nUm Revisionsnummern anzuzeigen, führen Sie 'helm history RELEASE' aus.\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Optionen\n\n```\n      --cleanup-on-fail    allow deletion of new resources created in this rollback when rollback fails\n      --dry-run            simulate a rollback\n      --force              force resource update through delete/recreate if needed\n  -h, --help               help for rollback\n      --history-max int    limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --no-hooks           prevent hooks from running during rollback\n      --recreate-pods      performs pods restart for the resource if applicable\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --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\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\nDurchsucht Charts nach einem Suchbegriff\n\n### Zusammenfassung\n\n\nMit der Suchfunktion können Sie Helm Charts an verschiedenen Orten finden –\ndarunter der Artifact Hub sowie von Ihnen hinzugefügte Repositories. Nutzen\nSie die Unterbefehle, um an verschiedenen Orten nach Charts zu suchen.\n\n\n### Optionen\n\n```\n  -h, --help   help for search\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n* [helm search hub](/helm/helm_search_hub.md)\t - Durchsucht den Artifact Hub oder Ihre eigene Hub-Instanz nach Charts\n* [helm search repo](/helm/helm_search_repo.md)\t - Durchsucht Repositories nach Charts anhand eines Suchbegriffs\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\nDurchsucht den Artifact Hub oder Ihre eigene Hub-Instanz nach Charts\n\n### Zusammenfassung\n\n\nDieser Befehl sucht nach Helm Charts im Artifact Hub oder in Ihrer eigenen Hub-Instanz.\n\nArtifact Hub ist eine webbasierte Anwendung zum Finden, Installieren und\nVeröffentlichen von Paketen und Konfigurationen für CNCF-Projekte, einschließlich\nöffentlich verfügbarer Helm Charts. Es handelt sich um ein Sandbox-Projekt der\nCloud Native Computing Foundation. Sie können den Hub unter https://artifacthub.io/\ndurchsuchen.\n\nDas [KEYWORD]-Argument akzeptiert entweder einen Suchbegriff oder eine in\nAnführungszeichen gesetzte erweiterte Suchanfrage (Rich Query). Die Dokumentation\nzu erweiterten Suchoptionen finden Sie unter\nhttps://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n\nFrühere Versionen von Helm verwendeten eine Monocular-Instanz als Standard-\n'endpoint'. Zur Abwärtskompatibilität ist Artifact Hub mit der Monocular-Such-API\nkompatibel. Beim Setzen des 'endpoint'-Flags muss der angegebene Endpunkt\nebenfalls eine Monocular-kompatible Such-API bereitstellen. Beachten Sie, dass\nbei Verwendung einer Monocular-Instanz als 'endpoint' erweiterte Suchanfragen\nnicht unterstützt werden. API-Details finden Sie unter https://github.com/helm/monocular\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### Optionen\n\n```\n      --endpoint string      Hub instance to query for charts (default \"https://hub.helm.sh\")\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for hub\n      --list-repo-url        print charts repository URL\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm search](/helm/helm_search.md)\t - Durchsucht Charts nach einem Suchbegriff\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\nDurchsucht Repositories nach Charts anhand eines Suchbegriffs\n\n### Zusammenfassung\n\nDieser Befehl durchsucht alle auf dem System konfigurierten Repositories und sucht nach Übereinstimmungen. Die Suche verwendet die auf dem System gespeicherten Metadaten.\n\nStandardmäß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.\n\nBeispiele:\n\n    # Stabile Versionen mit Suchbegriff \"nginx\" suchen\n    $ helm search repo nginx\n\n    # Versionen mit Suchbegriff \"nginx\" suchen, einschließlich Vorabversionen\n    $ helm search repo nginx --devel\n\n    # Neuestes stabiles Release für nginx-ingress mit Hauptversion 1 suchen\n    $ helm search repo nginx-ingress --version ^1.0.0\n\nRepositories werden mit 'helm repo'-Befehlen verwaltet.\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### Optionen\n\n```\n      --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\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for repo\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n  -r, --regexp               use regular expressions for searching repositories you have added\n      --version string       search using semantic versioning constraints on repositories you have added\n  -l, --versions             show the long listing, with each version of each chart on its own line, for repositories you have added\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm search](/helm/helm_search.md)\t - Durchsucht Charts nach einem Suchbegriff\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\nZeigt Informationen zu einem Chart an\n\n### Zusammenfassung\n\nDieser Befehl besteht aus mehreren Unterbefehlen zur Anzeige von Informationen über ein Chart\n\n\n### Optionen\n\n```\n  -h, --help   help for show\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n* [helm show all](/helm/helm_show_all.md)\t - Zeigt alle Informationen eines Charts an\n* [helm show chart](/helm/helm_show_chart.md)\t - Zeigt die Definition des Charts an\n* [helm show crds](/helm/helm_show_crds.md)\t - Zeigt die CRDs des Charts an\n* [helm show readme](/helm/helm_show_readme.md)\t - Zeigt die README des Charts an\n* [helm show values](/helm/helm_show_values.md)\t - Zeigt die Values des Charts an\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\nZeigt alle Informationen eines Charts an\n\n### Zusammenfassung\n\nDieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt dessen gesamten Inhalt an (values.yaml, Chart.yaml, README).\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for all\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm show](/helm/helm_show.md)\t - Zeigt Informationen zu einem Chart an\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\nZeigt die Definition des Charts an\n\n### Zusammenfassung\n\nDieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt den Inhalt der Chart.yaml-Datei an.\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for chart\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm show](/helm/helm_show.md)\t - Zeigt Informationen zu einem Chart an\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\nZeigt die CRDs des Charts an\n\n### Zusammenfassung\n\nDieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt den Inhalt der CustomResourceDefinition-Dateien an.\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for crds\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm show](/helm/helm_show.md)\t - Zeigt Informationen zu einem Chart an\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nZeigt die README-Datei des Charts an\n\n### Zusammenfassung\n\nDieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt den Inhalt der README-Datei an.\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for readme\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm show](/helm/helm_show.md)\t - Zeigt Informationen zu einem Chart an\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\nZeigt die Werte des Charts an\n\n### Zusammenfassung\n\nDieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt den Inhalt der values.yaml-Datei an.\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### Optionen\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for values\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --jsonpath string            supply a JSONPath expression to filter the output\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm show](/helm/helm_show.md)\t - Zeigt Informationen zu einem Chart an\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\nZeigt den Status eines benannten Releases an\n\n### Zusammenfassung\n\nDieser Befehl zeigt den Status eines benannten Releases an.\nDer Status umfasst:\n- Zeitpunkt des letzten Deployments\n- Kubernetes-Namespace, in dem sich das Release befindet\n- Zustand des Releases (mögliche Werte: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade oder pending-rollback)\n- Revision des Releases\n- Beschreibung des Releases (kann eine Abschlussmeldung oder Fehlermeldung sein, erfordert --show-desc)\n- Liste der Ressourcen, aus denen dieses Release besteht (erfordert --show-resources)\n- Details zum letzten Testlauf, falls zutreffend\n- Zusätzliche Hinweise des Charts\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### Optionen\n\n```\n  -h, --help             help for status\n  -o, --output format    prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int     if set, display the status of the named release with revision\n      --show-desc        if set, display the description message of the named release\n      --show-resources   if set, display the resources of the named release\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nRendert Templates lokal\n\n### Zusammenfassung\n\nRendert Chart-Templates lokal und zeigt die Ausgabe an.\n\nAlle 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).\n\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### Optionen\n\n```\n  -a, --api-versions strings                       Kubernetes api versions used for Capabilities.APIVersions\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for template\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --include-crds                               include CRDs in the templated output\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --is-upgrade                                 set .Release.IsUpgrade instead of .Release.IsInstall\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        Kubernetes version used for Capabilities.KubeVersion\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n      --output-dir string                          writes the executed templates to files in output-dir instead of stdout\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --release-name                               use release name in the output-dir path.\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n  -s, --show-only stringArray                      only show manifests rendered from the given templates\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --skip-tests                                 skip tests from templated output\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n      --validate                                   validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\nFührt Tests für ein Release aus\n\n### Zusammenfassung\n\nDer test-Befehl führt die Tests für ein Release aus.\n\nDieser Befehl erwartet den Namen eines installierten Releases als Argument.\nDie auszuführenden Tests sind im installierten Chart definiert.\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### Optionen\n\n```\n      --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)\n  -h, --help               help for test\n      --hide-notes         if set, do not show notes in test output. Does not affect presence in chart metadata\n      --logs               dump the logs from test pods (this runs after all tests are complete, but before any cleanup)\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\nDeinstalliert ein Release\n\n### Zusammenfassung\n\nDieser Befehl nimmt einen Release-Namen entgegen und deinstalliert das Release.\n\nEr 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.\n\nVerwenden Sie das '--dry-run'-Flag, um zu sehen, welche Releases deinstalliert werden, ohne sie tatsächlich zu deinstallieren.\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Optionen\n\n```\n      --cascade string       Must be \"background\", \"orphan\", or \"foreground\". Selects the deletion cascading strategy for the dependents. Defaults to background. (default \"background\")\n      --description string   add a custom description\n      --dry-run              simulate a uninstall\n  -h, --help                 help for uninstall\n      --ignore-not-found     Treat \"release not found\" as a successful uninstall\n      --keep-history         remove all associated resources and mark the release as deleted, but retain the release history\n      --no-hooks             prevent hooks from running during uninstallation\n      --timeout duration     time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --wait                 if set, will wait until all the resources are deleted before returning. It will wait for as long as --timeout\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nAktualisiert ein Release auf eine neue Version eines Charts\n\n### Zusammenfassung\n\nDieser Befehl aktualisiert ein Release auf eine neue Version eines Charts.\n\nAls 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.\n\nZum Ü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.\n\nDas '--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:\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\nDas '--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:\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\nMit 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.\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\nDas --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.\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Optionen\n\n```\n      --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\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --cleanup-on-fail                            allow deletion of new resources created in this upgrade when upgrade fails\n      --create-namespace                           if --install is set, create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -h, --help                                       help for upgrade\n      --hide-notes                                 if set, do not show notes in upgrade output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --history-max int                            limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n  -i, --install                                    if a release by this name doesn't already exist, run an install\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -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 [])\n      --no-hooks                                   disable pre/post upgrade hooks\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --repo string                                chart repository url where to locate the requested chart\n      --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\n      --reset-values                               when upgrading, reset the values to the ones built into the chart\n      --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\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\nÜberprüft, ob ein Chart am angegebenen Pfad signiert wurde und gültig ist\n\n### Zusammenfassung\n\nÜberprüft, ob das angegebene Chart über eine gültige Provenance-Datei verfügt.\n\nProvenance-Dateien ermöglichen die kryptografische Verifizierung, dass ein Chart nicht manipuliert wurde und von einem vertrauenswürdigen Anbieter paketiert wurde.\n\nVerwenden 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'.\n\n\n```\nhelm verify PATH [flags]\n```\n\n### Optionen\n\n```\n  -h, --help             help for verify\n      --keyring string   keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n\nGibt die Client-Versionsinformationen aus\n\n### Zusammenfassung\n\nZeigt die Version von Helm an.\n\nDieser Befehl gibt die Helm-Versionsinformationen aus.\nDie Ausgabe sieht etwa so aus:\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version ist die semantische Version des Releases.\n- GitCommit ist der SHA des Commits, aus dem diese Version erstellt wurde.\n- 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.\n- GoVersion ist die Go-Version, mit der Helm kompiliert wurde.\n\nBei Verwendung des Flags --template stehen folgende Eigenschaften für das Template zur Verfügung:\n\n- .Version enthält die semantische Version von Helm\n- .GitCommit ist der Git-Commit\n- .GitTreeState ist der Zustand des Git-Baums beim Erstellen von Helm\n- .GoVersion enthält die Go-Version, mit der Helm kompiliert wurde\n\nBeispiel: --template='Version: {{.Version}}' gibt 'Version: v3.2.1' aus.\n\n\n```\nhelm version [flags]\n```\n\n### Optionen\n\n```\n  -h, --help              help for version\n      --short             print the version number\n      --template string   template for version string format\n```\n\n### Optionen von übergeordneten Befehlen\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SIEHE AUCH\n\n* [helm](/helm/helm.md)\t - Der Helm-Paketmanager für Kubernetes.\n\n###### Automatisch generiert von spf13/cobra am 14-Jan-2026\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action zur Automatisierung von GitHub Pages Charts\ndescription: Beschreibt, wie Sie die Chart Releaser Action verwenden, um die Veröffentlichung von Charts über GitHub Pages zu automatisieren.\nsidebar_position: 3\n---\n\nDiese Anleitung beschreibt, wie Sie die [Chart Releaser\nAction](https://github.com/marketplace/actions/helm-chart-releaser) verwenden,\num die Veröffentlichung von Charts über GitHub Pages zu automatisieren. Die Chart Releaser\nAction ist ein GitHub Action Workflow, der Ihr GitHub-Projekt in ein selbst-gehostetes\nHelm Chart Repository verwandelt, unter Verwendung des CLI-Werkzeugs\n[helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n## Repository-Änderungen\n\nErstellen Sie ein Git-Repository unter Ihrer GitHub-Organisation. Sie können das\nRepository beispielsweise `helm-charts` nennen, andere Namen sind aber auch möglich.\nDie Quelldateien aller Charts können im `main` Branch liegen. Die Charts sollten\nunter dem Verzeichnis `/charts` auf oberster Verzeichnisebene abgelegt werden.\n\nEs sollte einen weiteren Branch namens `gh-pages` geben, um die Charts zu veröffentlichen.\nDie Änderungen an diesem Branch werden automatisch von der hier beschriebenen Chart\nReleaser Action erstellt. Sie können jedoch den `gh-pages` Branch erstellen und eine\n`README.md` Datei hinzufügen, die für Besucher der Seite sichtbar sein wird.\n\nSie können in der `README.md` Installationsanweisungen für die Charts hinzufügen,\netwa so (ersetzen Sie `<alias>`, `<orgname>` und `<chart-name>`):\n\n```\n## Verwendung\n\n[Helm](https://helm.sh) muss installiert sein, um die Charts zu verwenden.\nBitte lesen Sie die Helm [Dokumentation](https://helm.sh/docs) für den Einstieg.\n\nSobald Helm eingerichtet ist, fügen Sie das Repository wie folgt hinzu:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nFalls Sie dieses Repository bereits früher hinzugefügt haben, führen Sie\n`helm repo update` aus, um die neuesten Versionen der Pakete abzurufen.\nMit `helm search repo <alias>` können Sie dann die Charts anzeigen.\n\nUm das <chart-name> Chart zu installieren:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nUm das Chart zu deinstallieren:\n\n    helm uninstall my-<chart-name>\n```\n\nDie Charts werden auf einer Website mit einer URL wie dieser veröffentlicht:\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions Workflow\n\nErstellen Sie eine GitHub Actions Workflow-Datei im `main` Branch unter\n`.github/workflows/release.yml`\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nDie obige Konfiguration verwendet\n[@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action),\num Ihr GitHub-Projekt in ein selbst-gehostetes Helm Chart Repository zu verwandeln.\nBei jedem Push auf main prüft die Action jedes Chart in Ihrem Projekt. Wenn eine\nneue Chart-Version vorliegt, wird ein entsprechendes GitHub Release erstellt, das\nnach der Chart-Version benannt ist. Die Helm Chart Artefakte werden dem Release\nhinzugefügt und eine `index.yaml` Datei mit Metadaten über diese Releases wird\nerstellt oder aktualisiert. Diese wird dann auf GitHub Pages gehostet.\n\nDie im obigen Beispiel verwendete Versionsnummer der Chart Releaser Action ist `v1.6.0`.\nSie können diese zur [neuesten verfügbaren Version](https://github.com/helm/chart-releaser-action/releases)\nändern.\n\nHinweis: Die Chart Releaser Action wird fast immer zusammen mit der [Helm Testing\nAction](https://github.com/marketplace/actions/helm-chart-testing) und der [Kind\nAction](https://github.com/marketplace/actions/kind-cluster) verwendet.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: \"Synchronisieren Ihres Chart Repository\"\ndescription: \"Beschreibt wie Sie lokale und entfernte Chart Repositories synchronisieren.\"\nsidebar_position: 2\n---\n\n*Hinweis: Dieses Beispiel richtet sich an einen Google Cloud Storage (GCS) Bucket,\nwelcher ein Chart Repository bereitstellt.*\n\n## Vorbedingungen\n* Installieren Sie das [gsutil](https://cloud.google.com/storage/docs/gsutil) Werkzeug.\n  *Wir lehnen uns stark an die gsutil rsync Funktionalität*\n* Stellen Sie sicher, dass Sie Zugriff auf das Helm Programm haben\n* _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._\n\n## Ein lokales Chart Repository Verzeichnis aufsetzen\nErstellen Sie ein lokales Verzeichnis wie wir es im [Chart Repository Handbuch](/topics/chart_repository.md) gemacht haben und legen Sie Ihr Chart Paket\nin das Verzeichnis.\n\nZum Beispiel:\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Generieren einer aktualisierten index.yaml\nBenutzen Sie Helm zum Generieren einer aktualisierten index.yaml Datei durch Aufruf des\nVerzeichnisses und der URL des entfernten Repository durch das `helm repo index` Kommando wie:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\nDies wird eine aktualisierte index.yaml Datei erstellen und in das Verzeichnis\n`fantastic-charts/` legen.\n\n## Synchronisieren Ihrer lokalen und entfernten Chart Repositories\nLaden Sie den Inhalt des Verzeichnisses in Ihren GCS Bucket, indem Sie das Programm\n`scripts/sync-repo.sh` aufrufen und im lokalen Verzeichnis den Verzeichnisnamen und den\nNamen des GCS Bucket angeben.\n\nZum Beispiel:\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## Aktualisieren Ihres Chart Repository\nSie möchten eine lokale Kopie des Inhalts Ihres Chart Repository behalten oder\n`gsutil rsync` zum Kopieren des Inhalts Ihres entfernten Chart Repository zu Ihrem lokalen\nVerzeichnis verwenden.\n\nZum Beispiel:\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nHilfreiche Links:\n* Dokumentation von [gsutil\n  rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [Das Chart Repository Handbuch](/topics/chart_repository.md)\n* Dokumentation von [Objektversionierung und parallele Zugriffe](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) in Google Cloud Storage\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: \"Chart-Entwicklung: Tipps und Tricks\"\ndescription: \"Beschreibt Tipps und Tricks, die Helm Chart-Entwickler bei der Erstellung von produktionsreifen Charts gelernt haben.\"\nsidebar_position: 1\n---\n\nDieses Handbuch beschreibt Tipps und Tricks, die Helm Chart-Entwickler bei der Erstellung von produktionsreifen Charts gelernt haben.\n\n## Kennen Sie Ihre Vorlagenfunktionen\n\nHelm 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.\n\nZunä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.\n\nWir 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.\n\nDas folgende Beispiel bindet eine Vorlage namens `mytpl` ein, wandelt das Ergebnis in Kleinbuchstaben um und setzt es in Anführungszeichen.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nDie `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.\n\nDas folgende Beispiel der `required`-Funktion deklariert einen Eintrag für `.Values.who` als erforderlich und gibt eine Fehlermeldung aus, wenn dieser fehlt:\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## Strings in Anführungszeichen setzen, Integers nicht\n\nWenn Sie mit Stringdaten arbeiten, sind Sie immer auf der sicheren Seite, wenn Sie Strings in Anführungszeichen setzen:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nBei Integers hingegen sollten Sie die Werte _nicht_ in Anführungszeichen setzen. Das kann in vielen Fällen zu Parsing-Fehlern in Kubernetes führen.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nDieser Hinweis gilt nicht für Umgebungsvariablen, die immer als String erwartet werden, auch wenn sie Integers repräsentieren:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Verwendung der 'include'-Funktion\n\nGo 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.\n\nUm es zu ermöglichen, eine Vorlage einzubinden und dann eine Operation auf der Ausgabe dieser Vorlage durchzuführen, bietet Helm eine spezielle `include`-Funktion:\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nDies bindet eine Vorlage namens `toYaml` ein, übergibt ihr `$value` und leitet dann die Ausgabe dieser Vorlage an die `indent`-Funktion weiter.\n\nDa 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.\n\n## Verwendung der 'required'-Funktion\n\nGo 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.\n\nDie `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.\n\nZum Beispiel:\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nDas obige Beispiel rendert die Vorlage, wenn `.Values.foo` definiert ist, schlägt aber fehl, wenn `.Values.foo` nicht definiert ist.\n\n## Verwendung der 'tpl'-Funktion\n\nDie `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 }}`\n\nBeispiele:\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\nRendern einer externen Konfigurationsdatei:\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## Erstellen von Image Pull Secrets\n\nImage 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:\n\nZunächst nehmen wir an, dass die Zugangsdaten in der `values.yaml`-Datei wie folgt definiert sind:\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nDann definieren wir unsere Hilfsvorlage wie folgt:\n\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nSchließlich verwenden wir die Hilfsvorlage in einer größeren Vorlage, um das Secret-Manifest zu erstellen:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Automatisches Rollout von Deployments\n\nHä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.\n\nDie `sha256sum`-Funktion kann verwendet werden, um sicherzustellen, dass der Annotation-Abschnitt eines Deployments aktualisiert wird, wenn sich eine andere Datei ändert:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nHINWEIS: 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.\n\nFalls 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:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nJeder 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.\n\nBeide Methoden ermöglichen es Ihrem Deployment, die eingebaute Update-Strategie-Logik zu nutzen, um Ausfallzeiten zu vermeiden.\n\nHINWEIS: 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.\n\n## Helm anweisen, eine Ressource nicht zu deinstallieren\n\nManchmal 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.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nDie 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.\n\n## Verwendung von \"Partials\" und Template-Includes\n\nManchmal 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.\n\nIm `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.\n\n## Komplexe Charts mit vielen Abhängigkeiten\n\nViele 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.\n\nDie 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.\n\n## YAML ist eine Obermenge von JSON\n\nLaut der YAML-Spezifikation ist YAML eine Obermenge von JSON. Das bedeutet, dass jede gültige JSON-Struktur auch in YAML gültig sein sollte.\n\nDies 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.\n\nAls Best Practice sollten Vorlagen einer YAML-ähnlichen Syntax folgen, _es sei denn_, die JSON-Syntax reduziert das Risiko eines Formatierungsproblems erheblich.\n\n## Vorsicht beim Generieren zufälliger Werte\n\nEs 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.\n\n## Installieren oder Aktualisieren eines Releases mit einem Befehl\n\nHelm 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.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/howto/index.mdx",
    "content": "---\ntitle: \"Lernprogramme\"\nsidebar_position: 2\n---\n\n# Wie-geht-Anleitungen (How-Tos)\n\nHier finden Sie eine schnelle Antwort auf die Fragen “Wie kann ich…?”. Diese Wie-geht-\nAnleitungen besprechen die Themen nicht in der Tiefe - dieses Material finden Sie\nin den [Themenhandbüchern](/topics/index.mdx). Diese Anleitungen helfen Ihnen zum schnellen\nErfüllen der üblichen Aufgaben.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"Dokumentation\"\ndescription: \"Alles Wissenswerte zur Organisation der Dokumentation.\"\n---\n\n# Willkommen\n\nWillkommen zur [Helm](https://helm.sh/) Dokumentation. Helm ist der Paket\nManager für Kubernetes. Genauere Hintergrundinformationen gibt es im \n[CNCF Helm Projekt Reisebericht](https://www.cncf.io/cncf-helm-project-journey/).\n\n# Wie die Dokumentation aufgebaut ist\n\nHelm hat eine Menge Dokumentation. Eine Hauptübersicht ist hilfreich, nach\nbestimmten Dingen zu suchen:\n\n- [Lernprogramme](/intro/index.mdx) sind eine gute Handhabe, um das erste Helm Chart zu\n  erstellen. Starten Sie hier, wenn Sie neu bei Helm sind.\n- [Themenhandbücher](/topics/index.mdx) diskutieren Hauptthemen und Konzepte auf einem\n  hohen Niveau und stellen nützliche Hintergrundinformationen und Erklärungen\n  zur Verfügung.\n- [Gemeinschaftshandbücher](/community) diskutieren Themen rund um die Helm Gemeinschaft.\n  Starten Sie hier, wenn Sie mehr über den Entwicklungsprozess von Helm lernen\n  möchten und wie Sie dazu beitragen können.\n- [Anleitungen](/howto/index.mdx) sind wie Rezepte. Sie werden durch die einzelnen Schritte\n  der Hauptprobleme und Anwendungsfälle geleitet. Anleitungen sind mehr\n  fortgeschritten als Themenhandbücher und setzen Wissen voraus, wie Helm\n  funktioniert.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: Spickzettel\ndescription: Helm Spickzettel\nsidebar_position: 4\n---\n\nDieser Helm Spickzettel enthält alle notwendigen Befehle, die Sie zur Verwaltung einer Anwendung mit Helm benötigen.\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### Grundlegende Begriffe und Kontext\n\nChart:\n- Der Name Ihres Charts, falls es heruntergeladen und entpackt wurde.\n- `<repo_name>/<chart_name>`, falls das Repository hinzugefügt, aber das Chart nicht heruntergeladen wurde.\n- Die URL oder der absolute Pfad zum Chart.\n\nName:\n- Der Name, den Sie Ihrer aktuellen Helm Chart Installation geben möchten.\n\nRelease:\n- Der Name, den Sie einer Installationsinstanz zugewiesen haben.\n\nRevision:\n- Der Wert aus dem `helm history` Befehl.\n\nRepo-name:\n- Der Name eines Repository.\n\nDIR:\n- Verzeichnisname oder Pfad.\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Chart Verwaltung\n\n```bash\nhelm create <name>                      # Creates a chart directory along with the common files and directories used in a chart.\nhelm package <chart-path>               # Packages a chart into a versioned chart archive file.\nhelm lint <chart>                       # Run tests to examine a chart and identify possible issues:\nhelm show all <chart>                   # Inspect a chart and list its contents:\nhelm show values <chart>                # Displays the contents of the values.yaml file\nhelm pull <chart>                       # Download/pull chart\nhelm pull <chart> --untar=true          # If set to true, will untar the chart after downloading it\nhelm pull <chart> --verify              # Verify the package before using it\nhelm pull <chart> --version <number>    # Default-latest is used, specify a version constraint for the chart version to use\nhelm dependency list <chart>            # Display a list of a chart's dependencies:\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Anwendungen installieren und deinstallieren\n\n```bash\nhelm install <name> <chart>                           # Install the chart with a name\nhelm install <name> <chart> --namespace <namespace>   # Install the chart in a specific namespace\nhelm install <name> <chart> --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas)\nhelm install <name> <chart> --values <yaml-file/url>  # Install the chart with your specified values\nhelm install <name> <chart> --dry-run --debug         # Run a test installation to validate chart (p)\nhelm install <name> <chart> --verify                  # Verify the package before using it\nhelm install <name> <chart> --dependency-update       # update dependencies if they are missing before installing the chart\nhelm uninstall <name>                                 # Uninstalls a release from the current (default) namespace\nhelm uninstall <release-name> --namespace <namespace> # Uninstalls a release from the specified namespace\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Anwendungs-Upgrade und Rollback durchführen\n\n```bash\nhelm upgrade <release> <chart>                            # Upgrade a release\nhelm upgrade <release> <chart> --rollback-on-failure      # If set, upgrade process rolls back changes made in case of failed upgrade.\nhelm upgrade <release> <chart> --dependency-update        # update dependencies if they are missing before installing the chart\nhelm upgrade <release> <chart> --version <version_number> # specify a version constraint for the chart version to use\nhelm upgrade <release> <chart> --values                   # specify values in a YAML file or a URL (can specify multiple)\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Set values on the command line (can specify multiple or separate valuese)\nhelm upgrade <release> <chart> --force                    # Force resource updates through a replacement strategy\nhelm rollback <release> <revision>                        # Roll back a release to a specific revision\nhelm rollback <release> <revision>  --cleanup-on-fail     # Allow deletion of new resources created in this rollback when rollback fails\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Repositories auflisten, hinzufügen, entfernen und aktualisieren\n\n```bash\nhelm repo add <repo-name> <url>   # Add a repository from the internet:\nhelm repo list                    # List added chart repositories\nhelm repo update                  # Update information of available charts locally from chart repositories\nhelm repo remove <repo_name>      # Remove one or more chart repositories\nhelm repo index <DIR>             # Read the current directory and generate an index file based on the charts found.\nhelm repo index <DIR> --merge     # Merge the generated index with an existing index file\nhelm search repo <keyword>        # Search repositories for a keyword in charts\nhelm search hub <keyword>         # Search for charts in the Artifact Hub or your own hub instance\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Helm Release Überwachung\n\n```bash\nhelm list                       # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified\nhelm list --all                 # Show all releases without any filter applied, can use -a\nhelm list --all-namespaces      # List releases across all namespaces, we can use -A\nhelm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!='\nhelm list --date                # Sort by release date\nhelm list --deployed            # Show deployed releases. If no other is specified, this will be automatically enabled\nhelm list --pending             # Show pending releases\nhelm list --failed              # Show failed releases\nhelm list --uninstalled         # Show uninstalled releases (if 'helm uninstall --keep-history' was used)\nhelm list --superseded          # Show superseded releases\nhelm list -o yaml               # Prints the output in the specified format. Allowed values: table, json, yaml (default table)\nhelm status <release>           # This command shows the status of a named release.\nhelm status <release> --revision <number>   # if set, display the status of the named release with revision\nhelm history <release>          # Historical revisions for a given release.\nhelm env                        # Env prints out all the environment information in use by Helm.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Release-Informationen herunterladen\n\n```bash\nhelm get all <release>      # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release.\nhelm get hooks <release>    # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\\n' separator.\nhelm get manifest <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.\nhelm get notes <release>    # Shows notes provided by the chart of a named release.\nhelm get values <release>   # Downloads a values file for a given release. use -o to format output\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Plugin Verwaltung\n\n```bash\nhelm plugin install <path/url>      # Install plugins\nhelm plugin list                    # View a list of all installed plugins\nhelm plugin update <plugin>         # Update plugins\nhelm plugin uninstall <plugin>      # Uninstall a plugin\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/intro/index.mdx",
    "content": "---\ntitle: \"Einführung\"\nsidebar_position: 1\n---\n\n# Einführung in Helm\n\nNeu in Helm? Hier ist der Weg zum Start!\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: \"Helm installieren\"\ndescription: \"Lernen Sie wie man Helm installiert und zum Laufen kriegt.\"\nsidebar_position: 2\n---\n\nDiese Anleitung zeigt, wie Helm CLI zu installieren ist. Helm kann sowohl\nvom Quellcode als auch vorkompilierten Binaries installiert werden.\n\n## Vom Helm Projekt\n\nDas Helm Projekt stellt zwei Wege zum Beziehen und Installieren von Helm zur\nVerfügung. Dies sind die offiziellen Methoden, um Helm Versionen zu bekommen.\nZusätzlich zu dem stellt die Helm Gemeinschaft Methoden zur Installation\nmit verschiedenen Paketmanagern zur Verfügung. Die Installation mit diesen\nMethoden können am Ende der Anleitung zu den offiziellen Methoden gelesen \nwerden.\n\n### Von Binary Versionen\n\nJede [Version](https://github.com/helm/helm/releases) von Helm stellt Binary\nVersionen für verschiedene Betriebssysteme zur Verfügung. Diese Binary Versionen\nkann man herunterladen und installieren.\n\n1. Laden Sie die [gewünschte Version](https://github.com/helm/helm/releases) herunter\n2. Entpacken Sie diese (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)\n3. Finden Sie das Helm Binary im entpackten Verzeichnis und verschieben es zum\n   gewünschten Ziel (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nVon dort aus sollten Sie in der Lage sein, das Programm aufzurufen und ein\n[erstes Repo hinzuzufügen](/intro/quickstart.md#initialize-a-helm-chart-repository):\n`helm help`.\n\n**Hinweis:** In den automatisierten Tests von Helm wird nur die Version von\nLinux AMD64 beim Bau durch GitHub Actions berücksichtigt. Das Testen von anderen\nBetriebssystemen liegt in der Zuständigkeit der Gemeinschaft.\n\n### Von einem Script\n\nHelm hat ein Installations-Script, mit der automatisch die neueste Version\nbezogen und [lokal installiert wird](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3).\n\nSie können dieses Script aufrufen und lokal ausführen. Es ist gut dokumentiert,\nso dass Sie es lesen und gut verstehen können, bevor Sie es ausführen.\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\nJa, Sie können auch `curl\nhttps://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`\naufrufen, wenn Sie am Rande des Abgrunds leben.\n\n## Durch einen Paket Manager\n\nDie Helm Gemeinschaft stellt auch die Möglichkeit der Installation durch\nPaketmanager des Betriebssystems zur Verfügung. Diese werden vom Helm Projekt\nnicht unterstützt und gelten nicht als vertrauenswürdige Drittanbieter.\n\n### Von Homebrew (macOS)\n\nMitglieder der Helm Gemeinschaft haben eine Form des Baus durch Homebrew zur\nVerfügung gestellt. Diese Form ist generell immer aktuell.\n\n```console\nbrew install helm\n```\n\n(Hinweis: Es gibt noch eine Form von emacs-helm, was ein anderes Projekt ist.)\n\n### Von Chocolatey (Windows)\n\nMitglieder der Helm Gemeinschaft haben ein [Helm\nPaket](https://chocolatey.org/packages/kubernetes-helm) für\n[Chocolatey](https://chocolatey.org/) beigetragen. Dieses Paket ist generell aktuell.\n\n```console\nchoco install kubernetes-helm\n```\n\n### Von Scoop (Windows)\n\nMitglieder der Helm Gemeinschaft haben ein [Helm\nPaket](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) für [Scoop](https://scoop.sh) beigetragen. Dieses Paket ist generell aktuell.\n\n```console\nscoop install helm\n```\n\n### Von Winget (Windows)\n\nMitglieder der Helm Gemeinschaft haben ein [Helm\nPaket](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.\n\n```console\nwinget install Helm.Helm\n```\n\n### Von Apt (Debian/Ubuntu)\n\nMitglieder 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.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### Von dnf/yum (Fedora)\n\nSeit Fedora 35 ist Helm im offiziellen Repository verfügbar.\nSie können Helm mit folgendem Befehl installieren:\n\n```console\nsudo dnf install helm\n```\n\n### Von Snap\n\nDie [Snapcrafters](https://github.com/snapcrafters) Gemeinschaft unterstützt die Snap\nVersion vom [Helm Paket](https://snapcraft.io/helm):\n\n```console\nsudo snap install helm --classic\n```\n\n### Von pkg (FreeBSD)\n\nMitglieder der FreeBSD-Gemeinschaft haben ein [Helm\nPaket](https://www.freshports.org/sysutils/helm) für die\n[FreeBSD Ports Collection](https://man.freebsd.org/ports) beigetragen.\nDieses Paket ist generell aktuell.\n\n```console\npkg install helm\n```\n\n### Entwickler Builds\n\nZusätzlich zu den Versionen können auch Entwicklerkopien von Helm installiert\nwerden.\n\n### Von Canary Builds\n\n\"Canary\" Builds sind Versionen der Helm Software, die aus dem aktuellen `main`-Branch gebaut werden.\nDas sind keine offiziellen Versionen und sind möglicherweise nicht stabil. Sie bieten\ndie Möglichkeit, die neuesten Funktionen zu testen.\n\nCanary Helm Binaries sind unter `get.helm.sh` verfügbar. Hier\nsind die Links zu den üblichen Builds:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows\n  AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### Vom Quellcode (Linux, macOS)\n\nDas Bauen von Helm vom Quellcode ist etwas aufwändiger, aber es ist\ndie beste Möglichkeit, die neueste (noch nicht veröffentlichte) Version von Helm\nzu testen.\n\nSie brauchen eine Go Arbeitsumgebung.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\nWenn erforderlich, werden die Abhängigkeiten heruntergeladen und zwischengespeichert.\nDie Konfiguration wird validiert und Helm nach `bin/helm` kompiliert.\n\n## Zusammenfassung\n\nIn den meisten Fällen ist die Installation einfach durch das Beziehen der vorkompilierten\nHelm Binaries. Dieses Dokument deckt zusätzliche Fälle ab für Leute, die anspruchsvolle\nDinge mit Helm bewerkstelligen wollen.\n\nWenn Sie das Helm Programm erfolgreich installiert haben, können Sie zur Verwaltung\nvon Charts und [Hinzufügen des stabilen Repos](/intro/quickstart.md#initialize-a-helm-chart-repository)\nwechseln.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: \"Schnellstartanleitung\"\ndescription: \"Wie mit Helm anfangen, incl. Anleitungen für Distributionen, FAQs und Plugins.\"\nsidebar_position: 1\n---\n\nMit dieser Anleitung können Sie schnell mit Helm starten.\n\n## Vorbedingungen\n\nDie folgenden Vorbedingungen sind erforderlich, um Helm erfolgreich und sicher\nzu nutzen.\n\n1. Ein Kubernetes Cluster\n2. Entscheiden, welche Sicherheitskonfigurationen zur Installation verwendet werden\n3. Installieren und konfigurieren von Helm.\n\n### Installieren von Kubernetes oder Zugriff auf einen Cluster haben\n\n- Sie müssen Kubernetes installiert haben. Für die letzte Version von Helm\n  empfehlen wir die letzte stabile Version von Kubernetes, was in den meisten\n  Fällen die zweitletzte Unterversion ist.\n- Sie sollten eine lokale Kopie eines konfigurierten kubectl haben.\n\nSehen Sie die [Helm Version Support Policy](https://helm.sh/docs/topics/version_skew/)\nfür die maximal unterstützte Version zwischen Helm und Kubernetes.\n\n## Installieren von Helm\n\nLaden Sie eine Binary Version von Helm herunter. Sie können Werkzeuge verwenden wie homebrew\noder schauen Sie auf [die offizielle Versionsseite](https://github.com/helm/helm/releases).\n\nFür mehr Details oder weitere Optionen schauen Sie in die [Installationsanleitung](/intro/install.md).\n\n## Initialisieren eines Helm Chart Repository {#initialize-a-helm-chart-repository}\n\nWenn Sie Helm installiert haben, können Sie ein Chart Repository hinzufügen. Schauen Sie nach\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) für verfügbare Helm Chart\nRepositories.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nEinmal installiert können Sie die installierbaren Charts auflisten:\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## Installieren eines Beispiel Chart\n\nUm ein Chart zu installieren, können Sie das `helm install` Kommando verwenden.\nHelm kennt verschieden Wege, um ein Chart zu finden und zu installieren, aber\nam einfachsten ist die Verwendung des `bitnami` Charts.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nIm Beispiel oben wurde das `bitnami/mysql` Chart versioniert und der Name\nder neuen Version ist `mysql-1612624192`.\n\nSie kriegen eine grobe Idee über die Funktionen dieses MySQL Charts mit dem\nKommando `helm show chart bitnami/mysql`. Oder dem Kommando `helm show all bitnami/mysql`,\num alle Informationen über das Chart zu bekommen.\n\nWennimmer Sie ein Chart installieren, wird eine neue Version erstellt. So kann\nein Chart beliebig oft im selben Cluster installiert und unabhängig verwaltet und\naktualisiert werden.\n\nDas `helm install` Kommando ist ein sehr mächtiges Kommando mit vielen Möglichkeiten.\nUm mehr darüber zu lernen, schauen Sie ins [Helm Benutzerhandbuch](/intro/using_helm.md)\n\n## Mehr über Versionen lernen\n\nEs ist einfach zu sehen, was durch Helm versioniert wurde:\n\n```console\n$ helm ls\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nDie `helm list` (oder `helm ls`) Funktion zeigt Ihnen eine Liste aller installierten Versionen.\n\n## Eine Version deinstallieren\n\nUm eine Version zu deinstallieren, benutzen Sie das `helm uninstall` Kommando:\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nDas wird `mysql-1612624192` von Kubernetes deinstallieren, was wiederum alle\nResourcen löscht, die mit dieser Version verbunden sind, genauso wie die Versionshistorie.\n\nWenn die Option `--keep-history` verwendet wird, bleibt die Versionshistorie erhalten.\nSo können Sie Informationen über diese Version erhalten:\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nWeil Helm Ihre Versionen nachverfolgt, auch nachdem Sie sie deinstalliert haben, können Sie\ndie Historie des Clusters auditieren und eine gelöschte Version wiederherstellen\n(mit `helm rollback`).\n\n## Die Hilfe lesen\n\nUm mehr über die verfügbaren Helm Kommandos zu lesen, benutzen Sie `helm help` oder\ntippen das Kommando gefolgt von einem `-h` ein:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: \"Helm benutzen\"\ndescription: \"Erklärt die Grundsätze zu Helm.\"\nsidebar_position: 3\n---\n\nDiese Anleitung erklärt die Grundlagen zur Benutzung von Helm, um Pakete in Ihrem Kubernetes\nCluster zu verwalten. Es wird vorausgesetzt, dass Sie den Helm Client bereits\n[installiert](/intro/install.md) haben.\n\nWenn Sie nur daran interessiert sind, ein paar einfache Kommandos schnell zu lernen,\nbeginnen Sie mit der [Schnellstartanleitung](/intro/quickstart.md). \nDieses Kapitel erklärt die speziellen Helm Kommandos und erklärt, wie \nHelm zu benutzen ist.\n\n## Drei große Konzepte\n\nEin *Chart* ist ein Helm Paket. Es beinhaltet alle Ressourcendefinitionen, die zur\nAusführung einer Applikation, eines Werkzeugs oder Dienstes im Kubernetes\nCluster erforderlich sind. Denken Sie an etwas wie ein Homebrew Formular für\nKubernetes, ein Apt dpkg oder eine Yum RPM Datei.\n\nEin *Repository* ist ein Platz, wo Charts gesammelt und gespeichert werden können.\nEs ist wie Perl's [CPAN Archiv](https://www.cpan.org) oder die [Fedora Package\nDatabase](https://src.fedoraproject.org/), aber für Kubernetes Pakete.\n\nEin(e) *Release/Version* ist eine Instanz von einem Chart, welches in einem\nKubernetes Cluster läuft. Ein Chart kann beliebig oft im selben Cluster\ninstalliert werden. Und immer wenn es neu installiert wird, wird ein neues\n_release_ erstellt. Denken Sie an ein MySQL Chart. Wenn Sie zwei laufende\nDatenbanken in Ihrem Cluster haben möchten, können Sie dieses Chart zweimal\ninstallieren. Jedes bekommt sein eigenes _release_, welches sich über seinen\neigenen _release_name_ identifiziert.\n\nMit diesem Konzept im Hinterkopf, können wir das Helm Konzept erklären wie:\n\nHelm installiert _charts_ in Kubernetes, erstellt ein neues _release_ für jede\nInstallation. Und zur Suche nach neuen Charts, können Sie Helm Chart _repositories_ durchsuchen.\n\n## 'helm search': Charts finden\n\nHelm kommt mit einem mächtigen Suchkommando. Es kann zwei verschiedene Quelltypen suchen:\n\n- `helm search hub` sucht [den Artifact Hub](https://artifacthub.io), welches\n  Helm Charts von dutzenden unterschiedlichen Repositories listet.\n- `helm search repo` sucht die Repositories, die Sie lokal in Ihrem Helm\n  Client hinzugefügt haben (mit `helm repo add`). Diese Suche wird über lokale Daten\n  durchgeführt, ohne dass eine öffentliche Netzwerkverbindung notwendig ist.\n\nSie können öffentlich verfügbare Charts finden mit dem Kommando `helm search hub`:\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\nDie obige Suche nach allen `wordpress` Charts auf Artifact Hub.\n\nOhne Filter zeigt `helm search hub` alle verfügbaren Charts.\n\n`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]`.\n\nWenn Sie `helm search repo` benutzen, können Sie alle Namen von Charts\nin Repositories finden, die Sie bereits hinzugefügt haben:\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nDie Helm Suche benutzt ein Fuzzy String Matching Algorithmus, wodurch\nSie Teile von Wortphrasen eingeben können:\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nDie Suche ist ein guter Weg, um verfügbare Pakete zu finden. Sobald\nSie ein Paket gefunden haben, können Sie es mit `helm install` installieren.\n\n## 'helm install': Ein Paket installieren\n\nBenutzen Sie das `helm install` Kommando, um ein neues Helm Paket zu installieren.\nAm einfachsten hat das Kommando zwei Argumente: Einen Versionsnamen, den Sie gewählt\nhaben und den Namen des Charts, dass Sie installieren möchten.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nJetzt ist das `wordpress` Chart installiert. Beachten Sie dass das Installieren\neines Charts ein neues _release_ Objekt erstellt. Die Version oben hat den Namen\n`happy-panda`. (Wenn Sie möchten, dass Helm einen Namen für Sie generiert, lassen\nSie den Versionsnamen offen und geben den Parameter `--generate-name` an.)\n\nWährend der Installation gibt das `helm` Programm nützliche Informationen aus wie\ndie erstellten Ressourcen, den Status des Release und falls vorhanden zusätzliche\nKonfigurationsschritte, die Sie durchführen können.\n\nHelm installiert Ressourcen in der folgenden Reihenfolge:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nHelm wartet nicht, bis alle Ressourcen laufen. Viele Charts benötigen Docker Images\nmit einer Grösse von 600 MB und brauchen länger, um im Cluster installiert zu\nwerden.\n\nUm auf dem Laufenden zu bleiben oder um Konfigurationsinformationen nochmal zu lesen,\nkönnen Sie `helm status` benutzen:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nDie Informationen oben zeigen den Status der letzten Version.\n\n### Anpassen des Charts vor der Installation\n\nBisher nutzen wir nur die Standardoptionen der Konfiguration eines Charts.\nÖfters will man aber das Chart anpassen.\n\nUm zu sehen, welche Konfigurationsoptionen ein Chart bietet, nutzen Sie `helm show values`:\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nSie können alle Einstellungen in einer YAML formatierten Datei überschreiben und\ndann bei der Installation angeben.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nDas oben wird eine Standard MariaDB mit dem Benutzer `user0` erstellen, ihm\nRechte auf der neu erstellten Datenbank `user0db` einrichten, aber alle anderen\nWerte auf dem Standard des Charts belassen.\n\nEs gibt zwei Wege, um Konfigurationsdaten während der Installation anzupassen:\n\n- `--values` (or `-f`): Gibt eine YAML Datei mit Werten zum Überschreiben an. Das\n  kann beliebig oft gemacht werden, die am weitesten rechts benutzte Datei wird\n  den Wert bestimmen.\n- `--set`: Gibt Überschreibungen auf der Kommandozeile an.\n\nWenn beide verwendet werden, `--set` Werte werden in `--values` mit einer höheren\nGewichtung verschmolzen. Überschreibungen mit `--set` sind in einer ConfigMap persistiert.\nWerte die mit `--set` angegeben wurden, können in einer Version mit `helm get\nvalues <release-name>` ausgegeben werden. Werte, die mit `--set` angegeben wurden,\nkönnen mit dem Kommando `helm upgrade` mit `--reset-values` gelöscht werden.\n\n#### Format und Limitierungen von `--set`\n\nDie `--set` Option hat null oder mehrere Name/Wert Paare. Am einfachsten ist es zu\nbenutzen wie: `--set name=value`. Die YAML Syntax ist:\n\n```yaml\nname: value\n```\n\nMehere Werte werden separiert mit `,` Zeichen. Aus `--set a=b,c=d` wird:\n\n```yaml\na: b\nc: d\n```\n\nMehr komplextere Beschreibungen werden auch unterstützt. Zum Beispiel `--set outer.inner=value`\nwird übersetzt in:\n\n```yaml\nouter:\n  inner: value\n```\n\nListen können mit geschweiften Klammern `{` und `}` angegeben werden. Zum Beispiel `--set\nname={a, b, c}` wird übersetzt in:\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nBestimmte Namen/Schlüssel können auf `null` oder ein leeres Array `[]` gesetzt werden. Zum Beispiel übersetzt `--set name=[],a=null`\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\nin\n\n```yaml\nname: []\na: null\n```\n\nMit Helm 2.5.0 ist es möglich, Listenwerte in einer Arrayindex-Syntax\nanzugeben, Zum Beispiel `--set servers[0].port=80` wird:\n\n```yaml\nservers:\n  - port: 80\n```\n\nMehrere Werte können auf diesem Weg angebenen werden. Die Zeile `--set\nservers[0].port=80,servers[0].host=example` wird:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nManchmal brauchen Sie spezielle Zeichen in Ihrer `--set` Zeile. Sie können\nBackslash zum Verstecken des Zeichens benutzen: `--set name=value1\\,value2` wird:\n\n```yaml\nname: \"value1,value2\"\n```\n\nGenauso können Sie Punktsequenzen maskieren, die möglicherweise beim Parsen von Charts\nin Annotations, Labels und Node Selectors mit der `toYaml` Funktion problematisch\nwerden könnten. Die Syntax für `--set nodeSelector.\"kubernetes\\.io/role\"=master`\nwird:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nTief verzweigte Datenstrukturen können schwierig darzustellen sein mit `--set`. Chart Designer\nsind angewiesen, die Benutzung von `--set` durch die Benutzung des Formats\nder `values.yaml` Datei zu minimieren.\n(Lesen Sie mehr dazu in [Values Files](/chart_template_guide/values_files.md)).\n\n### Mehr Installationsmethoden\n\nDas `helm install` Kommando kann von verschiedenen Quellen installieren:\n\n- Ein Chart Repository (wie wir es oben gesehen haben)\n- Ein lokales Chart Archiv (`helm install foo foo-0.1.1.tgz`)\n- Ein ungepacktes Chart Verzeichnis (`helm install foo path/to/foo`)\n- Eine URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' und 'helm rollback': Eine Version aktualisieren und die Wiederherstellung nach einem Fehler\n\nWenn eine neue Version von einem Chart installiert ist oder wenn Sie Änderungen\nan der Konfiguration durchführen möchten, können Sie das\n`helm upgrade` Kommando verwenden.\n\nEine Aktualisierung nimmt eine bestehende Version und aktualisiert sie nach\nden gegebenen Informationen, die Sie bereitstellen. Da Kubernetes Charts\nsehr gross und komplex sein können, probiert Helm die wenigst invasive\nAktualisierung. Es wird nur Dinge aktualisieren, die sich seit der letzten\nVersion wirklich geändert haben.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nIn dem Fall oben wird die `happy-panda` Version mit dem selben Chart aber mit einer\nneuen YAML Datei aktualisiert:\n\n```yaml\nmariadb.auth.username: user1\n```\n\nWir können `helm get values` benutzen, um zu sehen, ob die Änderungen durchgeführt wurden.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nDas `helm get` Kommando ist ein nützliches Werkzeug, um nach der Version in Ihrem\nCluster zu schauen. Wie wir oben sehen können, sieht es so aus, als wenn unsere\nneuen Werte von `panda.yaml` im Cluster installiert wurden sind.\n\nJetzt, wenn etwas ungeplantes in dieser Version passiert ist, ist es einfach zu\neiner vorherigen Version mit dem Kommando `helm rollback [RELEASE] [REVISION]`\nzu wechseln.\n\n\n```console\n$ helm rollback happy-panda 1\n```\n\nDies rollt unsere happy-panda Installation zur allerersten Version zurück. Bei jeder\nInstallation, Aktualisierung oder Zurückrollen wird die Revisionsnummer um 1 erhöht.\nDie erste Revisionsnummer ist immer die 1. Und mit dem Kommando `helm history [RELEASE]`\nsehen wir die Historie zu jeder Version.\n\n## Hilfreiche Optionen für Installation/Aktualisierung/Zurückrollen\n\nEs gibt sehr viele hilfreiche Optionen, um das Verhalten von Helm bei der Installation,\nder Aktualisierung oder dem Zurückrollen zu ändern. Bitte beachten Sie, dass das keine\nvollständige Liste der Optionen ist. Zur vollen Beschreibung rufen Sie einfach\n`helm <command> --help` auf.\n\n- `--timeout`: Ein Wert der [Go Wartezeit](https://golang.org/pkg/time/#ParseDuration),\n  um auf den Abschluss eines Kubernetes Kommandos zu warten. Der Standardwert ist `5m0s`.\n- `--wait`: Wartet bis alle Pods im Status Running sind, PVCs gebunden sind und\n  Deployments eine minimale Verfügbarkeit besitzen (`Desired` minus `maxUnavailable`),\n  Services eine IP-Adresse haben (Ingress wenn es ein `LoadBalancer` ist), bevor\n  die ganze Version als erfolgreich installiert markiert wird. Wenn das Timeout `--timeout`\n  erreicht wird, wird die Version als `FAILED` markiert. Hinweis: In Deployments in denen\n  `replicas` auf 1 und `maxUnavailable` als Teil der Aktualisierungsstrategie gesetzt ist,\n  wird `--wait` den Status fertig melden, wenn es den minimalen Pod als fertig gesehen hat.\n- `--no-hooks`: Dies übergeht Hooks für dieses Kommando\n- `--recreate-pods` (nur verfügbar bei `upgrade` und `rollback`): Diese Option wird\n  alle Pods neu erstellen (ausser den Pods in diesem Deployment). (VERALTET in Helm 3)\n\n## 'helm uninstall': Eine Version deinstallieren\n\nBenutzen Sie das Kommando `helm uninstall`, wenn es an der Zeit ist, eine Version vom\nCluster zu deinstallieren: \n\n```console\n$ helm uninstall happy-panda\n```\n\nDas wird die Version vom Cluster löschen. Sie können die derzeit im Cluster installierte\nVersion mit dem Kommando `helm list` sehen:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nVon der Ausgaben oben sehen wir, dass die Version `happy-panda` deinstalliert\nwurde.\n\nIn einer vorherigen Version von Helm wurde sich immer das Löschen einer Version\ngemerkt. In Helm 3 wird dieser Eintrag auch gelöscht.\nWenn Sie diese Löscheinträge behalten wollen, benutzen Sie beim Deinstallieren\n--keep-history`. Die Benutzung von `helm list --uninstalled` wird nur die Versionen\nzeigen, die mit der Option `--keep-history` gelöscht wurden.\n\nDie Option `helm list --all` zeigt alle Versionseinträge, die Helm aufgehoben hat,\ninkl. fehlerhafte und gelöschte Einträge (wenn `--keep-history` verwendet wurde):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nBeachten Sie, dass es durch die standardmässig gelöschten Versionen es nicht mehr\nmöglich ist, eine nicht installierte Resource zurückzurollen.\n\n## 'helm repo': Arbeiten mit Repositories\n\nHelm 3 wird nicht mehr mit einem Standard Chart Verzeichnis ausgeliefert. Das\n`helm repo` Gruppenkommando stellt Kommandos zum Hinzufügen, Auflisten und Löschen\nvon Verzeichnissen zur Verfügung.\n\nMit dem Kommando `helm repo list` können Sie sehen, welche Verzeichnisse konfiguriert sind:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nUnd neue Verzeichnisse können hinzugefügt werden mit `helm repo add`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nWeil Sich Chart Repositories ständig ändern, sollten Sie an dieser Stelle\nsicherstellen, dass Ihr Helm Programm mit dem Kommando `helm repo update`\naktuell ist.\n\nRepositories können mit `helm repo remove` gelöscht werden.\n\n## Ihr eigenes Chart erstellen\n\nDas [Chart Entwicklungshandbuch](/topics/charts.md) erklärt,\nwie Sie Ihr eigenes Chart entwickeln können. Aber Sie können auch schnell starten\nmit dem Kommando `helm create`:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nNun gibt es ein Chart in `./deis-workflow`. Sie können es editieren und Ihre \neigene Vorlage erstellen.\n\nNach dem Editieren können Sie das Format mit dem Kommando `helm lint` validieren.\n\nWenn es Zeit ist, ein Paket von diesem Chart für eine Distribution zu erstellen, können Sie das\nKommando `helm package` verwenden:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nJetzt kann das Chart einfach installiert werden mit `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nChart Pakete können einfach in ein Repository geladen werden. Schauen Sie\ndie Dokumentation für [Helm Chart Repositories](/topics/chart_repository.md) für mehr Details.\n\n## Zusammenfassung\n\nDieses Kapitel behandelte die grundlegende Verwendung des `helm` Clients,\ninkl. Suchen, Installieren, Aktualisieren und Deinstallieren. Es wurden auch\nhilfreiche Zusatzkommandos besprochen wie `helm status`, `helm get` und `helm repo`.\n\nFür mehr Informationen zu diesen Kommandos, schauen Sie in die eingebaute Hilfe:\n`helm help`.\n\nIm [nächsten Kapitel](/howto/charts_tips_and_tricks.md) werden wir\neinen Blick in die Entwicklung von Charts.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: Einführung\ndescription: Stellt das Helm Go SDK vor\nsidebar_position: 1\n---\nDas 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.\n(Die Helm CLI ist im Grunde selbst nur ein solches Werkzeug!)\n\nDerzeit wurde das SDK funktional von der Helm CLI getrennt.\nDas SDK kann (und wird) von eigenständigen Tools verwendet.\nDas Helm-Projekt hat sich zur API-Stabilität für das SDK verpflichtet.\nAls 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.\n\nDie vollständige API-Dokumentation finden Sie unter [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3).\n\nIm Folgenden finden Sie einen kurzen Überblick über einige der wichtigsten Paketarten und ein einfaches Beispiel.\nWeitere Beispiele und einen umfangreicheren 'Treiber' finden Sie im Abschnitt [Beispiele](/sdk/examples.mdx).\n\n## Überblick über die wichtigsten Pakete\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action):\n  Enthält den Haupt-\"Client\" zur Durchführung von Helm-Aktionen.\n  Dies ist dasselbe Paket, das die CLI im Hintergrund verwendet.\n  Wenn Sie nur grundlegende Helm-Befehle aus einem anderen Go-Programm ausführen möchten, ist dieses Paket genau das Richtige.\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil):\n  Methoden und Hilfsfunktionen zum Laden und Bearbeiten von Charts\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) und seine Unterpakete:\n  Enthält alle Handler für die Standard-Helm-Umgebungsvariablen. Die Unterpakete enthalten die Verarbeitung von Ausgabe- und Values-Dateien.\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release):\n  Definiert das `Release`-Objekt und Status\n\nEs gibt noch viele weitere Pakete – weitere Informationen finden Sie in der Dokumentation.\n\n### Einfaches Beispiel\nDies ist ein einfaches Beispiel für ein `helm list` mit dem Go SDK.\nWeitere umfangreichere Beispiele finden Sie im Abschnitt [Beispiele](/sdk/examples.mdx).\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## Kompatibilität\n\nDas Helm SDK folgt ausdrücklich den Rückwärtskompatibilitätsgarantien von Helm:\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\nDas bedeutet, dass inkompatible Änderungen nur bei Hauptversionen vorgenommen werden.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: Fortgeschrittene Helm-Techniken\ndescription: Erläutert verschiedene fortgeschrittene Funktionen für erfahrene Helm-Benutzer\nsidebar_position: 9\n---\n\nDieser Abschnitt erläutert verschiedene fortgeschrittene Funktionen und Techniken für die Verwendung von Helm.\nDie Informationen in diesem Abschnitt richten sich an „fortgeschrittene Benutzer\" von Helm, die\nerweiterte Anpassungen und Manipulationen ihrer Charts und Releases durchführen möchten. Jede\ndieser fortgeschrittenen Funktionen bringt eigene Kompromisse und Einschränkungen mit sich, daher muss jede\nmit Sorgfalt und fundiertem Wissen über Helm eingesetzt werden. Oder anders ausgedrückt:\nDenken Sie an das [Peter-Parker-Prinzip](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility).\n\n## Post Rendering\nPost Rendering gibt Chart-Installierern die Möglichkeit, gerenderte Manifeste manuell zu manipulieren,\nzu konfigurieren und/oder zu validieren, bevor sie von Helm installiert werden.\nDies ermöglicht es Benutzern mit erweiterten Konfigurationsanforderungen, Tools wie\n[`kustomize`](https://kustomize.io) zu verwenden, um Konfigurationsänderungen anzuwenden, ohne\nein öffentliches Chart forken zu müssen oder von Chart-Maintainern zu verlangen, jede einzelne\nKonfigurationsoption für eine Software bereitzustellen. Es gibt auch Anwendungsfälle für\ndas Einbinden gemeinsamer Tools und Sidecars in Unternehmensumgebungen oder die Analyse\nder Manifeste vor der Bereitstellung.\n\n### Voraussetzungen\n- Helm 3.1+\n\n### Verwendung\nEin Post-Renderer kann jede ausführbare Datei sein, die gerenderte Kubernetes-Manifeste\nüber STDIN akzeptiert und gültige Kubernetes-Manifeste über STDOUT zurückgibt. Bei einem\nFehler sollte ein Exit-Code ungleich 0 zurückgegeben werden. Dies ist die einzige „API\" zwischen den\nbeiden Komponenten. Sie ermöglicht große Flexibilität bei dem, was Sie mit Ihrem\nPost-Render-Prozess tun können.\n\nEin Post-Renderer kann mit `install`, `upgrade` und `template` verwendet werden. Um einen\nPost-Renderer zu verwenden, nutzen Sie das Flag `--post-renderer` mit einem Pfad zur\nausführbaren Renderer-Datei:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nWenn der Pfad keine Trennzeichen enthält, wird in $PATH gesucht, andernfalls\nwerden relative Pfade zu einem vollqualifizierten Pfad aufgelöst.\n\nWenn Sie mehrere Post-Renderer verwenden möchten, rufen Sie alle in einem Skript auf oder\nkombinieren Sie sie in einem beliebigen Binary-Tool, das Sie erstellt haben. In Bash wäre dies so\neinfach wie `renderer1 | renderer2 | renderer3`.\n\nSie können ein Beispiel für die Verwendung von `kustomize` als Post-Renderer\n[hier](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render) sehen.\n\n### Einschränkungen\nBei der Verwendung von Post-Renderern gibt es mehrere wichtige Punkte zu beachten.\nDer wichtigste davon ist, dass bei Verwendung eines Post-Renderers alle Personen,\ndie dieses Release modifizieren, **denselben Renderer verwenden müssen**, um\nreproduzierbare Builds zu gewährleisten. Diese Funktion wurde absichtlich so entwickelt, dass jeder Benutzer\nden verwendeten Renderer wechseln oder die Verwendung eines Renderers beenden kann, aber dies\nsollte bewusst geschehen, um versehentliche Änderungen oder Datenverlust zu vermeiden.\n\nEin weiterer wichtiger Hinweis betrifft die Sicherheit. Wenn Sie einen Post-Renderer verwenden,\nsollten Sie sicherstellen, dass er aus einer zuverlässigen Quelle stammt (wie bei jeder\nanderen beliebigen ausführbaren Datei). Die Verwendung von nicht vertrauenswürdigen oder nicht verifizierten Renderern wird NICHT\nempfohlen, da sie vollen Zugriff auf gerenderte Templates haben, die oft\nsensible Daten enthalten.\n\n### Benutzerdefinierte Post-Renderer\nDer Post-Render-Schritt bietet noch mehr Flexibilität bei Verwendung des Go SDK. Jeder\nPost-Renderer muss nur das folgende Go-Interface implementieren:\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nWeitere Informationen zur Verwendung des Go SDK finden Sie im [Go SDK-Abschnitt](#go-sdk).\n\n## Go SDK\nHelm 3 führte ein komplett umstrukturiertes Go SDK ein, das eine bessere Erfahrung beim\nErstellen von Software und Tools bietet, die Helm nutzen. Die vollständige Dokumentation finden Sie\nim [Go SDK-Abschnitt](/sdk/gosdk.md).\n\n## Speicher-Backends\n\nHelm 3 hat den Standard-Speicherort für Release-Informationen auf Secrets im\nNamespace des Releases geändert. Helm 2 speicherte Release-Informationen standardmäßig als\nConfigMaps im Namespace der Tiller-Instanz. Die folgenden Unterabschnitte\nzeigen, wie verschiedene Backends konfiguriert werden. Diese Konfiguration basiert auf der\nUmgebungsvariablen `HELM_DRIVER`. Sie kann auf einen der folgenden Werte gesetzt werden:\n`[configmap, secret, sql]`.\n\n### ConfigMap-Speicher-Backend\n\nUm das ConfigMap-Backend zu aktivieren, müssen Sie die Umgebungsvariable\n`HELM_DRIVER` auf `configmap` setzen.\n\nSie können sie in einer Shell wie folgt setzen:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nWenn Sie vom Standard-Backend zum ConfigMap-Backend wechseln möchten, müssen Sie\ndie Migration selbst durchführen. Sie können Release-Informationen mit folgendem\nBefehl abrufen:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**PRODUKTIONSHINWEISE**: Die Release-Informationen enthalten den Inhalt von Charts und\nValues-Dateien und können daher sensible Daten (wie\nPasswörter, private Schlüssel und andere Anmeldedaten) enthalten, die vor\nunbefugtem Zugriff geschützt werden müssen. Bei der Verwaltung von Kubernetes-Berechtigungen, beispielsweise mit\n[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), ist es\nmöglich, breiteren Zugriff auf ConfigMap-Ressourcen zu gewähren, während der\nZugriff auf Secret-Ressourcen eingeschränkt bleibt. Zum Beispiel gewährt die standardmäßige [benutzerorientierte\nRolle](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\n„view\" Zugriff auf die meisten Ressourcen, aber nicht auf Secrets. Darüber hinaus können Secrets-Daten für\n[verschlüsselte Speicherung](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)\nkonfiguriert werden. Bitte beachten Sie dies, wenn Sie zum ConfigMap-Backend wechseln möchten, da\ndies die sensiblen Daten Ihrer Anwendung offenlegen könnte.\n\n### SQL-Speicher-Backend\n\nEs gibt ein ***Beta***-SQL-Speicher-Backend, das Release-Informationen in einer SQL-Datenbank\nspeichert.\n\nDie Verwendung eines solchen Speicher-Backends ist besonders nützlich, wenn Ihre Release-Informationen\nmehr als 1 MB wiegen (in diesem Fall können sie aufgrund interner Beschränkungen im\nzugrundeliegenden etcd-Schlüssel-Wert-Speicher von Kubernetes nicht in ConfigMaps/Secrets gespeichert werden).\n\nUm das SQL-Backend zu aktivieren, müssen Sie eine SQL-Datenbank bereitstellen und die\nUmgebungsvariable `HELM_DRIVER` auf `sql` setzen. Die Datenbankdetails werden mit der\nUmgebungsvariablen `HELM_DRIVER_SQL_CONNECTION_STRING` festgelegt.\n\nSie können sie in einer Shell wie folgt setzen:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Hinweis: Derzeit wird nur PostgreSQL unterstützt.\n\n**PRODUKTIONSHINWEISE**: Es wird empfohlen:\n- 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)\n- [Berechtigungsverwaltung](/topics/permissions_sql_storage_backend.md) zu aktivieren, um\nKubernetes RBAC für Release-Informationen zu spiegeln\n\nWenn Sie vom Standard-Backend zum SQL-Backend wechseln möchten, müssen Sie\ndie Migration selbst durchführen. Sie können Release-Informationen mit folgendem\nBefehl abrufen:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Helm Architektur\ndescription: Beschreibt die Architektur von Helm auf hoher Ebene.\nsidebar_position: 8\n---\n\n# Helm Architektur\n\nDieses Dokument beschreibt die Architektur von Helm auf hoher Ebene.\n\n## Der Zweck von Helm\n\nHelm ist ein Werkzeug zur Verwaltung von Kubernetes-Paketen, die _Charts_ genannt werden. Helm kann Folgendes:\n\n- Neue Charts von Grund auf erstellen\n- Charts in Chart-Archive (tgz-Dateien) paketieren\n- Mit Chart-Repositories interagieren, in denen Charts gespeichert sind\n- Charts in einem bestehenden Kubernetes-Cluster installieren und deinstallieren\n- Den Release-Zyklus von Charts verwalten, die mit Helm installiert wurden\n\nFür Helm gibt es drei wichtige Konzepte:\n\n1. Das _Chart_ ist ein Bündel von Informationen, die zur Erstellung einer Instanz einer Kubernetes-Anwendung erforderlich sind.\n2. Die _Config_ enthält Konfigurationsinformationen, die mit einem paketierten Chart zusammengeführt werden können, um ein installierbares Objekt zu erstellen.\n3. Ein _Release_ ist eine laufende Instanz eines _Charts_, kombiniert mit einer bestimmten _Config_.\n\n## Komponenten\n\nHelm ist eine ausführbare Anwendung, die aus zwei verschiedenen Teilen besteht:\n\n**Der Helm Client** ist ein Kommandozeilen-Client für Endbenutzer. Der Client ist für Folgendes verantwortlich:\n\n- Lokale Chart-Entwicklung\n- Verwaltung von Repositories\n- Verwaltung von Releases\n- Schnittstelle zur Helm-Bibliothek\n  - Senden von Charts zur Installation\n  - Anfordern von Upgrades oder Deinstallationen bestehender Releases\n\n**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:\n\n- Kombination eines Charts und einer Config zu einem Release\n- Installation von Charts in Kubernetes und Bereitstellung des resultierenden Release-Objekts\n- Aktualisierung und Deinstallation von Charts durch Interaktion mit Kubernetes\n\nDie eigenständige Helm-Bibliothek kapselt die Helm-Logik, sodass sie von verschiedenen Clients genutzt werden kann.\n\n## Implementierung\n\nDer Helm Client und die Bibliothek sind in der Programmiersprache Go geschrieben.\n\nDie 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.\n\nKonfigurationsdateien werden, wenn möglich, in YAML geschrieben.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: Leitfaden für Chart Repositories\ndescription: So erstellen und arbeiten Sie mit Helm Chart Repositories.\nsidebar_position: 6\n---\n\nDieser Abschnitt erklärt, wie Sie Chart Repositories erstellen und damit arbeiten.\nGrundsätzlich ist ein Chart Repository ein Ort, an dem gepackte Charts gespeichert\nund geteilt werden können.\n\nDas verteilte Community-Repository für Helm Charts befindet sich bei\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) und begrüßt\nTeilnahme. Aber Helm ermöglicht es auch, eigene Chart Repositories zu erstellen und zu\nbetreiben. Dieser Leitfaden erklärt, wie das geht. Falls Sie erwägen, ein Chart\nRepository zu erstellen, sollten Sie stattdessen die Verwendung einer\n[OCI-Registry](/topics/registries.md) in Betracht ziehen.\n\n## Voraussetzungen\n\n* Arbeiten Sie den [Schnellstart](/intro/quickstart.md)-Leitfaden durch\n* Lesen Sie das [Charts](/topics/charts.md)-Dokument\n\n## Ein Chart Repository erstellen\n\nEin _Chart Repository_ ist ein HTTP-Server, der eine `index.yaml`-Datei und optional\neinige gepackte Charts hostet. Wenn Sie bereit sind, Ihre Charts zu teilen, ist der\nbevorzugte Weg, sie in ein Chart Repository hochzuladen.\n\nSeit Helm 2.2.0 wird clientseitige SSL-Authentifizierung für Repositories unterstützt.\nAndere Authentifizierungsprotokolle können als Plugins verfügbar sein.\n\nDa ein Chart Repository jeder HTTP-Server sein kann, der YAML- und tar-Dateien\nbereitstellen und GET-Anfragen beantworten kann, haben Sie zahlreiche Optionen beim\nHosten Ihres eigenen Chart Repositories. Zum Beispiel können Sie einen Google Cloud\nStorage (GCS) Bucket, einen Amazon S3 Bucket, GitHub Pages verwenden oder sogar Ihren\neigenen Webserver erstellen.\n\n### Die Struktur eines Chart Repositories\n\nEin Chart Repository besteht aus gepackten Charts und einer speziellen Datei namens\n`index.yaml`, die einen Index aller Charts im Repository enthält. Häufig werden die\nCharts, die `index.yaml` beschreibt, auch auf demselben Server gehostet, ebenso wie\ndie [Provenienz-Dateien](/topics/provenance.md).\n\nDas Layout des Repositories `https://example.com/charts` könnte beispielsweise so\naussehen:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nIn diesem Fall würde die Index-Datei Informationen über ein Chart enthalten, das\nAlpine-Chart, und die Download-URL `https://example.com/charts/alpine-0.1.2.tgz`\nfür dieses Chart bereitstellen.\n\nEs ist nicht erforderlich, dass ein Chart-Paket auf demselben Server wie die\n`index.yaml`-Datei liegt. Allerdings ist dies oft am einfachsten.\n\n### Die Index-Datei\n\nDie Index-Datei ist eine YAML-Datei namens `index.yaml`. Sie enthält einige Metadaten\nüber das Paket, einschließlich des Inhalts der `Chart.yaml`-Datei eines Charts. Ein\ngültiges Chart Repository muss eine Index-Datei haben. Die Index-Datei enthält\nInformationen über jedes Chart im Chart Repository. Der Befehl `helm repo index`\ngeneriert eine Index-Datei basierend auf einem gegebenen lokalen Verzeichnis, das\ngepackte Charts enthält.\n\nDies ist ein Beispiel einer Index-Datei:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Hosten von Chart Repositories\n\nDieser Teil zeigt verschiedene Möglichkeiten, ein Chart Repository bereitzustellen.\n\n### Google Cloud Storage\n\nDer erste Schritt ist das **Erstellen Ihres GCS-Buckets**. Wir nennen unseren\n`fantastic-charts`.\n\n![Create a GCS Bucket](/img/helm2/create-a-bucket.png)\n\nAls Nächstes machen Sie Ihren Bucket öffentlich, indem Sie die **Bucket-Berechtigungen\nbearbeiten**.\n\n![Edit Permissions](/img/helm2/edit-permissions.png)\n\nFügen Sie diese Zeile hinzu, um **Ihren Bucket öffentlich zu machen**:\n\n![Make Bucket Public](/img/helm2/make-bucket-public.png)\n\nHerzlichen Glückwunsch! Jetzt haben Sie einen leeren GCS-Bucket, der bereit ist, Charts\nbereitzustellen.\n\nSie können Ihr Chart Repository mit dem Google Cloud Storage-Kommandozeilentool oder\nüber die GCS-Weboberfläche hochladen. Ein öffentlicher GCS-Bucket kann über einfaches\nHTTPS unter dieser Adresse erreicht werden: `https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith\n\nSie können auch Chart Repositories mit Cloudsmith einrichten. Lesen Sie mehr über\nChart Repositories mit Cloudsmith\n[hier](https://help.cloudsmith.io/docs/helm-chart-repository)\n\n### JFrog Artifactory\n\nEbenso können Sie Chart Repositories mit JFrog Artifactory einrichten. Lesen Sie mehr\nüber Chart Repositories mit JFrog Artifactory\n[hier](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)\n\n### GitHub Pages-Beispiel\n\nAuf ähnliche Weise können Sie ein Chart Repository mit GitHub Pages erstellen.\n\nGitHub ermöglicht es Ihnen, statische Webseiten auf zwei verschiedene Arten\nbereitzustellen:\n\n- Indem Sie ein Projekt so konfigurieren, dass es den Inhalt seines `docs/`-Verzeichnisses bereitstellt\n- Indem Sie ein Projekt so konfigurieren, dass es einen bestimmten Branch bereitstellt\n\nWir nehmen den zweiten Ansatz, obwohl der erste genauso einfach ist.\n\nDer erste Schritt ist das **Erstellen Ihres gh-pages-Branches**. Sie können dies\nlokal wie folgt tun:\n\n```console\n$ git checkout -b gh-pages\n```\n\nOder über den Webbrowser mit dem **Branch**-Button in Ihrem GitHub-Repository:\n\n![Create GitHub Pages branch](/img/helm2/create-a-gh-page-button.png)\n\nAls Nächstes sollten Sie sicherstellen, dass Ihr **gh-pages-Branch** als GitHub Pages\neingestellt ist. Klicken Sie auf die **Settings** Ihres Repositories und scrollen Sie\nzum Abschnitt **GitHub Pages** und stellen Sie es wie unten gezeigt ein:\n\n![Create GitHub Pages branch](/img/helm2/set-a-gh-page.png)\n\nStandardmäßig wird die **Source** normalerweise auf **gh-pages branch** gesetzt. Falls\ndies nicht standardmäßig eingestellt ist, wählen Sie es aus.\n\nSie können dort bei Bedarf eine **benutzerdefinierte Domain** verwenden.\n\nStellen Sie außerdem sicher, dass **Enforce HTTPS** aktiviert ist, damit **HTTPS**\nverwendet wird, wenn Charts bereitgestellt werden.\n\nMit dieser Einrichtung können Sie Ihren Standard-Branch zum Speichern Ihres\nChart-Codes verwenden und den **gh-pages-Branch** als Chart Repository, z.B.:\n`https://USERNAME.github.io/REPONAME`. Das Demonstrations-Repository [TS\nCharts](https://github.com/technosophos/tscharts) ist erreichbar unter\n`https://technosophos.github.io/tscharts/`.\n\nWenn Sie sich entschieden haben, GitHub Pages zum Hosten des Chart Repositories zu\nverwenden, schauen Sie sich die [Chart Releaser Action](/howto/chart_releaser_action.md)\nan. Die Chart Releaser Action ist ein GitHub Action-Workflow, der ein GitHub-Projekt\nin ein selbst gehostetes Helm Chart Repository verwandelt, unter Verwendung des\n[helm/chart-releaser](https://github.com/helm/chart-releaser) CLI-Tools.\n\n### Gewöhnliche Webserver\n\nUm einen gewöhnlichen Webserver für Helm Charts zu konfigurieren, müssen Sie lediglich\nFolgendes tun:\n\n- Legen Sie Ihren Index und Ihre Charts in ein Verzeichnis, das der Server bereitstellen kann\n- Stellen Sie sicher, dass die `index.yaml`-Datei ohne Authentifizierungsanforderung zugänglich ist\n- Stellen Sie sicher, dass `yaml`-Dateien mit dem korrekten Content-Type bereitgestellt werden (`text/yaml` oder `text/x-yaml`)\n\nWenn Sie beispielsweise Ihre Charts aus `$WEBROOT/charts` bereitstellen möchten,\nstellen Sie sicher, dass ein `charts/`-Verzeichnis in Ihrem Web-Root existiert, und\nlegen Sie die Index-Datei und die Charts in diesen Ordner.\n\n### ChartMuseum Repository-Server\n\nChartMuseum ist ein Open-Source Helm Chart Repository-Server, der in Go (Golang)\ngeschrieben ist, mit Unterstützung für Cloud-Storage-Backends, einschließlich\n[Google Cloud Storage](https://cloud.google.com/storage/),\n[Amazon S3](https://aws.amazon.com/s3/),\n[Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/),\n[Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss),\n[Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/),\n[Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage),\n[Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html),\n[Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos),\n[DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/),\n[Minio](https://min.io/) und [etcd](https://etcd.io/).\n\nSie können auch den\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)-Server\nverwenden, um ein Chart Repository aus einem lokalen Dateisystem zu hosten.\n\n### GitLab Package Registry\n\nMit GitLab können Sie Helm Charts in der Package Registry Ihres Projekts\nveröffentlichen. Lesen Sie mehr über das Einrichten eines Helm Package Repositories\nmit GitLab [hier](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Verwalten von Chart Repositories\n\nDa Sie nun ein Chart Repository haben, erklärt der letzte Teil dieses Leitfadens, wie\nSie Charts in diesem Repository pflegen.\n\n### Charts in Ihrem Chart Repository speichern\n\nLaden wir nun ein Chart und eine Index-Datei in das Repository hoch. Charts in einem\nChart Repository müssen gepackt (`helm package chart-name/`) und korrekt versioniert\nsein (gemäß den [SemVer 2](https://semver.org/)-Richtlinien).\n\nDie folgenden Schritte bilden einen Beispiel-Workflow, aber Sie können jeden beliebigen\nWorkflow verwenden, den Sie zum Speichern und Aktualisieren von Charts in Ihrem Chart\nRepository bevorzugen.\n\nSobald Sie ein gepacktes Chart bereit haben, erstellen Sie ein neues Verzeichnis und\nverschieben Sie Ihr gepacktes Chart in dieses Verzeichnis.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nDer letzte Befehl nimmt den Pfad des lokalen Verzeichnisses, das Sie gerade erstellt\nhaben, und die URL Ihres Remote-Chart-Repositories und erstellt eine `index.yaml`-Datei\nim angegebenen Verzeichnispfad.\n\nJetzt können Sie das Chart und die Index-Datei mit einem Synchronisierungstool oder\nmanuell in Ihr Chart Repository hochladen. Wenn Sie Google Cloud Storage verwenden,\nschauen Sie sich diesen\n[Beispiel-Workflow](/howto/chart_repository_sync_example.md) mit dem gsutil-Client an.\nFür GitHub können Sie die Charts einfach in den entsprechenden Ziel-Branch legen.\n\n### Neue Charts zu einem bestehenden Repository hinzufügen\n\nJedes Mal, wenn Sie ein neues Chart zu Ihrem Repository hinzufügen möchten, müssen Sie\nden Index neu generieren. Der Befehl `helm repo index` baut die `index.yaml`-Datei\nvollständig von Grund auf neu auf und nimmt nur die Charts auf, die er lokal findet.\n\nSie können jedoch das Flag `--merge` verwenden, um neue Charts inkrementell zu einer\nbestehenden `index.yaml`-Datei hinzuzufügen (eine großartige Option bei der Arbeit mit\neinem Remote-Repository wie GCS). Führen Sie `helm repo index --help` aus, um mehr zu\nerfahren.\n\nStellen Sie sicher, dass Sie sowohl die überarbeitete `index.yaml`-Datei als auch das\nChart hochladen. Und falls Sie eine Provenienz-Datei generiert haben, laden Sie diese\nebenfalls hoch.\n\n### Ihre Charts mit anderen teilen\n\nWenn Sie bereit sind, Ihre Charts zu teilen, teilen Sie einfach jemandem die URL Ihres\nRepositories mit.\n\nVon dort aus können sie das Repository mit dem Befehl `helm repo add [NAME] [URL]` zu\nihrem Helm-Client hinzufügen, mit einem beliebigen Namen, den sie für die Referenzierung\ndes Repositories verwenden möchten.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nWenn die Charts durch HTTP-Basic-Authentifizierung geschützt sind, können Sie hier\nauch Benutzername und Passwort angeben:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Hinweis:** Ein Repository wird nicht hinzugefügt, wenn es keine gültige\n`index.yaml` enthält.\n\n**Hinweis:** Wenn Ihr Helm-Repository z.B. ein selbstsigniertes Zertifikat verwendet,\nkönnen Sie `helm repo add --insecure-skip-tls-verify ...` verwenden, um die\nCA-Verifizierung zu überspringen.\n\nDanach können Ihre Benutzer Ihre Charts durchsuchen. Nachdem Sie das Repository\naktualisiert haben, können sie den Befehl `helm repo update` verwenden, um die\nneuesten Chart-Informationen zu erhalten.\n\n*Unter der Haube rufen die Befehle `helm repo add` und `helm repo update` die\nindex.yaml-Datei ab und speichern sie im Verzeichnis\n`$XDG_CACHE_HOME/helm/repository/cache/`. Hier findet die Funktion `helm search`\nInformationen über Charts.*\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: Chart Tests\ndescription: Beschreibt, wie Sie Ihre Charts ausführen und testen können.\nsidebar_position: 3\n---\n\nEin 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.\n\nEin **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`.\n\nHinweis: 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.\n\nBeispiele für Tests:\n\n- Validieren Sie, dass Ihre Konfiguration aus der values.yaml-Datei korrekt übernommen wurde.\n  - Stellen Sie sicher, dass Ihr Benutzername und Passwort korrekt funktionieren\n  - Stellen Sie sicher, dass ein falscher Benutzername und falsches Passwort nicht funktionieren\n- Überprüfen Sie, dass Ihre Services aktiv sind und die Lastverteilung korrekt funktioniert\n- usw.\n\nSie können die vordefinierten Tests in Helm für ein Release mit dem Befehl `helm test <RELEASE_NAME>` 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.\n\n## Beispieltest\n\nDer 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.\n\n```console\n$ helm create demo\n```\n\nSie sehen nun die folgende Struktur in Ihrem Demo-Helm-Chart.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nIn `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:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Schritte zum Ausführen einer Testsuite für ein Release\n\nInstallieren 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.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Hinweise\n\n- Sie können beliebig viele Tests in einer einzelnen YAML-Datei definieren oder auf mehrere YAML-Dateien im Verzeichnis `templates/` verteilen.\n- Sie können Ihre Testsuite in einem Unterverzeichnis `tests/` wie `<chart-name>/templates/tests/` unterbringen, um eine bessere Übersichtlichkeit zu erreichen.\n- 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.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: Charts\ndescription: Erklärt das Chart-Format und bietet grundlegende Anleitungen zum Erstellen von Charts mit Helm.\nsidebar_position: 1\n---\n\nHelm 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.\n\nCharts werden als Dateien in einer bestimmten Verzeichnisstruktur angelegt und können in versionierte Archive verpackt werden.\n\nWenn 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.\n\nDieses Dokument erklärt das Chart-Format und bietet grundlegende Anleitungen zum Erstellen von Charts mit Helm.\n\n## Die Chart-Dateistruktur\n\nEin 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.\n\nInnerhalb dieses Verzeichnisses erwartet Helm eine Struktur wie diese:\n\n```text\nwordpress/\n  Chart.yaml          # A YAML file containing information about the chart\n  LICENSE             # OPTIONAL: A plain text file containing the license for the chart\n  README.md           # OPTIONAL: A human-readable README file\n  values.yaml         # The default configuration values for this chart\n  values.schema.json  # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file\n  charts/             # A directory containing any charts upon which this chart depends.\n  crds/               # Custom Resource Definitions\n  templates/          # A directory of templates that, when combined with values,\n                      # will generate valid Kubernetes manifest files.\n  templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes\n```\n\nHelm reserviert die Verwendung der Verzeichnisse `charts/`, `crds/` und `templates/` sowie der aufgelisteten Dateinamen. Andere Dateien bleiben unverändert.\n\n## Die Chart.yaml-Datei\n\nDie `Chart.yaml`-Datei ist für ein Chart erforderlich. Sie enthält die folgenden Felder:\n\n```yaml\napiVersion: The chart API version (required)\nname: The name of the chart (required)\nversion: The version of the chart (required)\nkubeVersion: A SemVer range of compatible Kubernetes versions (optional)\ndescription: A single-sentence description of this project (optional)\ntype: The type of the chart (optional)\nkeywords:\n  - A list of keywords about this project (optional)\nhome: The URL of this projects home page (optional)\nsources:\n  - A list of URLs to source code for this project (optional)\ndependencies: # A list of the chart requirements (optional)\n  - name: The name of the chart (nginx)\n    version: The version of the chart (\"1.2.3\")\n    repository: (optional) The repository URL (\"https://example.com/charts\") or alias (\"@repo-name\")\n    condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )\n    tags: # (optional)\n      - Tags can be used to group charts for enabling/disabling together\n    import-values: # (optional)\n      - 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.\n    alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times\nmaintainers: # (optional)\n  - name: The maintainers name (required for each maintainer)\n    email: The maintainers email (optional for each maintainer)\n    url: A URL for the maintainer (optional for each maintainer)\nicon: A URL to an SVG or PNG image to be used as an icon (optional).\nappVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.\ndeprecated: Whether this chart is deprecated (optional, boolean)\nannotations:\n  example: A list of annotations keyed by name (optional).\n```\n\nAb [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.\n\n### Charts und Versionierung\n\nJedes 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.\n\nBeispielsweise wird ein `nginx`-Chart, dessen Versionsfeld auf `version: 1.2.3` gesetzt ist, wie folgt benannt:\n\n```text\nnginx-1.2.3.tgz\n```\n\nKomplexere 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).\n\n**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.\n\nDas `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.\n\n### Das `apiVersion`-Feld\n\nDas `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.\n\nÄnderungen von `v1` zu `v2`:\n\n- 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)).\n- Das `type`-Feld, das zwischen Application- und Library-Charts unterscheidet (siehe [Chart-Typen](#chart-typen)).\n\n### Das `appVersion`-Feld\n\nBeachten 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.\n\nAb Helm v3.5.0 setzt `helm create` das standardmäßige `appVersion`-Feld in Anführungszeichen.\n\n### Das `kubeVersion`-Feld\n\nDas 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.\n\nVersionseinschränkungen können aus durch Leerzeichen getrennten UND-Vergleichen bestehen, wie z.B.:\n```\n>= 1.13.0 < 1.15.0\n```\nDiese können wiederum mit dem ODER-Operator `||` kombiniert werden, wie im folgenden Beispiel:\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\nIn 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.\n\nNeben Versionseinschränkungen mit den Operatoren `=` `!=` `>` `<` `>=` `<=` werden folgende Kurzschreibweisen unterstützt:\n\n * Bindestrich-Bereiche für geschlossene Intervalle, wobei `1.1 - 2.3.4` äquivalent zu `>= 1.1 <= 2.3.4` ist.\n * Wildcards `x`, `X` und `*`, wobei `1.2.x` äquivalent zu `>= 1.2.0 < 1.3.0` ist.\n * Tilde-Bereiche (Patch-Versionsänderungen erlaubt), wobei `~1.2.3` äquivalent zu `>= 1.2.3 < 1.3.0` ist.\n * Caret-Bereiche (Minor-Versionsänderungen erlaubt), wobei `^1.2.3` äquivalent zu `>= 1.2.3 < 2.0.0` ist.\n\nFür eine detaillierte Erklärung der unterstützten SemVer-Einschränkungen siehe [Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Charts als veraltet markieren\n\nBei 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:\n\n1. Aktualisieren Sie die `Chart.yaml` des Charts, um es als veraltet zu markieren, und erhöhen Sie die Version\n2. Veröffentlichen Sie die neue Chart-Version im Chart Repository\n3. Entfernen Sie das Chart aus dem Quell-Repository (z.B. git)\n\n### Chart-Typen\n\nDas `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.\n\n**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.\n\n## Chart LICENSE, README und NOTES\n\nCharts können auch Dateien enthalten, die die Installation, Konfiguration, Verwendung und Lizenz eines Charts beschreiben.\n\nEine 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.\n\nEine README für ein Chart sollte in Markdown formatiert sein (README.md) und sollte im Allgemeinen enthalten:\n\n- Eine Beschreibung der Anwendung oder des Dienstes, den das Chart bereitstellt\n- Alle Voraussetzungen oder Anforderungen zum Ausführen des Charts\n- Beschreibungen der Optionen in `values.yaml` und Standardwerte\n- Alle anderen Informationen, die für die Installation oder Konfiguration des Charts relevant sein könnten\n\nWenn Hubs und andere Benutzeroberflächen Details über ein Chart anzeigen, werden diese Informationen aus dem Inhalt der `README.md`-Datei gezogen.\n\nDas 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.\n\n## Chart-Abhängigkeiten\n\nIn 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.\n\n### Abhängigkeiten mit dem `dependencies`-Feld verwalten\n\nDie vom aktuellen Chart benötigten Charts werden als Liste im `dependencies`-Feld definiert.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- Das `name`-Feld ist der Name des gewünschten Charts.\n- Das `version`-Feld ist die Version des gewünschten Charts.\n- 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.\n- Sie können auch den Namen des Repos anstelle der URL verwenden\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nSobald 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.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nWenn `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:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Das Alias-Feld in Abhängigkeiten\n\nZusätzlich zu den anderen oben genannten Feldern kann jeder Abhängigkeitseintrag das optionale Feld `alias` enthalten.\n\nDas 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.\n\nSie können `alias` in Fällen verwenden, in denen Sie auf ein Chart mit anderen Namen zugreifen müssen.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nIm obigen Beispiel erhalten wir insgesamt 3 Abhängigkeiten für `parentchart`:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nDer manuelle Weg, dies zu erreichen, wäre das Kopieren und Einfügen desselben Charts im `charts/`-Verzeichnis mehrfach mit verschiedenen Namen.\n\n#### Tags- und Condition-Felder in Abhängigkeiten\n\nZusätzlich zu den anderen oben genannten Feldern kann jeder Abhängigkeitseintrag die optionalen Felder `tags` und `condition` enthalten.\n\nAlle 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.\n\nCondition - 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.\n\nTags - 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.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nIm 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.\n\nDa `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.\n\n##### Verwendung der CLI mit Tags und Conditions\n\nDer `--set`-Parameter kann wie gewohnt verwendet werden, um Tag- und Condition-Werte zu ändern.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Auflösung von Tags und Conditions\n\n- **Conditions (wenn in Values gesetzt) überschreiben immer Tags.** Der erste existierende Condition-Pfad gewinnt, und nachfolgende für dieses Chart werden ignoriert.\n- Tags werden als 'wenn eines der Tags des Charts true ist, dann aktiviere das Chart' ausgewertet.\n- Tag- und Condition-Werte müssen in den Values des obersten übergeordneten Charts gesetzt werden.\n- Der `tags:`-Schlüssel in Values muss ein Schlüssel auf oberster Ebene sein. Globale und verschachtelte `tags:`-Tabellen werden derzeit nicht unterstützt.\n\n#### Importieren von Child-Values über Abhängigkeiten\n\nIn 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.\n\nDie 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.\n\nUm 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.\n\n##### Verwendung des exports-Formats\n\nWenn 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:\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\nDa 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.\n\nDie endgültigen Values des übergeordneten Charts würden unser exportiertes Feld enthalten:\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\nBitte 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.\n\n##### Verwendung des child-parent-Formats\n\nUm 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.\n\nDas `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.\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nIm 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:\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nDie resultierenden Values des übergeordneten Charts wären:\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nDie endgültigen Values des übergeordneten Charts enthalten jetzt die aus subchart1 importierten Felder `myint` und `mybool`.\n\n### Abhängigkeiten manuell über das `charts/`-Verzeichnis verwalten\n\nWenn 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.\n\nEine Abhängigkeit sollte ein entpacktes Chart-Verzeichnis sein, aber sein Name darf nicht mit `_` oder `.` beginnen. Solche Dateien werden vom Chart-Loader ignoriert.\n\nWenn beispielsweise das WordPress-Chart vom Apache-Chart abhängt, wird das Apache-Chart (in der korrekten Version) im `charts/`-Verzeichnis des WordPress-Charts bereitgestellt:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nDas 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.\n\n**TIPP:** _Um eine Abhängigkeit in Ihr `charts/`-Verzeichnis zu laden, verwenden Sie den Befehl `helm pull`._\n\n### Betriebsaspekte bei der Verwendung von Abhängigkeiten\n\nDie 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?\n\nAngenommen, ein Chart namens \"A\" erstellt die folgenden Kubernetes-Objekte:\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nDarüber hinaus ist A von Chart B abhängig, das folgende Objekte erstellt:\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nNach 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:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nDer Grund dafür ist, dass Helm bei der Installation/dem Upgrade von Charts die Kubernetes-Objekte aus den Charts und allen ihren Abhängigkeiten:\n\n- in einer einzigen Menge zusammenfasst,\n- nach Typ und dann nach Name sortiert,\n- in dieser Reihenfolge erstellt/aktualisiert.\n\nDaher wird ein einzelnes Release mit allen Objekten für das Chart und seine Abhängigkeiten erstellt.\n\nDie 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)).\n\n## Templates und Values\n\nHelm-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).\n\nAlle 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.\n\nValues für die Templates werden auf zwei Arten bereitgestellt:\n\n- Chart-Entwickler können eine Datei namens `values.yaml` innerhalb eines Charts bereitstellen. Diese Datei kann Standardwerte enthalten.\n- Chart-Benutzer können eine YAML-Datei bereitstellen, die Values enthält. Diese kann bei der Befehlszeile mit `helm install` angegeben werden.\n\nWenn ein Benutzer benutzerdefinierte Values bereitstellt, überschreiben diese Values die Werte in der `values.yaml`-Datei des Charts.\n\n### Template-Dateien\n\nTemplate-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:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nDas 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):\n\n- `imageRegistry`: Die Quell-Registry für das Docker-Image.\n- `dockerTag`: Das Tag für das Docker-Image.\n- `pullPolicy`: Die Kubernetes-Pull-Policy.\n- `storage`: Das Storage-Backend, dessen Standard auf `\"minio\"` gesetzt ist.\n\nAlle diese Werte werden vom Template-Autor definiert. Helm schreibt keine Parameter vor oder erfordert sie.\n\nUm viele funktionierende Charts zu sehen, schauen Sie sich den CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) an.\n\n### Vordefinierte Values\n\nValues, 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.\n\nDie folgenden Values sind vordefiniert, in jedem Template verfügbar und können nicht überschrieben werden. Wie bei allen Values sind die Namen _case-sensitive_.\n\n- `Release.Name`: Der Name des Release (nicht des Charts)\n- `Release.Namespace`: Der Namespace, in dem das Chart released wurde.\n- `Release.Service`: Der Dienst, der das Release durchgeführt hat.\n- `Release.IsUpgrade`: Dies ist auf true gesetzt, wenn die aktuelle Operation ein Upgrade oder Rollback ist.\n- `Release.IsInstall`: Dies ist auf true gesetzt, wenn die aktuelle Operation eine Installation ist.\n- `Chart`: Der Inhalt der `Chart.yaml`. So ist die Chart-Version als `Chart.Version` und die Maintainer als `Chart.Maintainers` erhältlich.\n- `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.\n- `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.\n\n**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.\n\n### Values-Dateien\n\nUnter Berücksichtigung des Templates im vorherigen Abschnitt würde eine `values.yaml`-Datei, die die notwendigen Werte bereitstellt, so aussehen:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nEine 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:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nWenn Werte auf diese Weise übergeben werden, werden sie in die Standard-Values-Datei gemergt. Betrachten Sie beispielsweise eine `myvals.yaml`-Datei, die so aussieht:\n\n```yaml\nstorage: \"gcs\"\n```\n\nWenn dies mit der `values.yaml` im Chart gemergt wird, ist der resultierende generierte Inhalt:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nBeachten Sie, dass nur das letzte Feld überschrieben wurde.\n\n**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.\n\n**HINWEIS:** Wenn das `--set`-Flag bei `helm install` oder `helm upgrade` verwendet wird, werden diese Werte einfach clientseitig in YAML konvertiert.\n\n**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.\n\nAlle diese Werte sind dann innerhalb von Templates über das `.Values`-Objekt zugänglich:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Scope, Abhängigkeiten und Values\n\nValues-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:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nCharts 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.\n\nValues 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.\n\n#### Globale Values\n\nAb Version 2.0.0-Alpha.2 unterstützt Helm spezielle \"globale\" Values. Betrachten Sie diese modifizierte Version des vorherigen Beispiels:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nDas 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.\n\nBeispielsweise können die `mysql`-Templates auf `app` als `{{ .Values.global.app }}` zugreifen, ebenso das `apache`-Chart. Effektiv wird die Values-Datei oben so regeneriert:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\nSo 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.\n\nWenn 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.\n\nGlobale Variablen von übergeordneten Charts haben Vorrang vor den globalen Variablen von Subcharts.\n\n### Schema-Dateien\n\nManchmal 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:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nDieses Schema wird auf die Values angewendet, um sie zu validieren. Die Validierung erfolgt, wenn einer der folgenden Befehle aufgerufen wird:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nEin Beispiel für eine `values.yaml`-Datei, die die Anforderungen dieses Schemas erfüllt, könnte so aussehen:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nBeachten 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.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nAuß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.\n\nDie 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.\n```console\nhelm install --skip-schema-validation\n```\n\n### Referenzen\n\nBeim Schreiben von Templates, Values und Schema-Dateien gibt es mehrere Standardreferenzen, die Ihnen helfen werden.\n\n- [Go-Templates](https://godoc.org/text/template)\n- [Zusätzliche Template-Funktionen](https://godoc.org/github.com/Masterminds/sprig)\n- [Das YAML-Format](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRDs)\n\nKubernetes bietet einen Mechanismus zum Deklarieren neuer Arten von Kubernetes-Objekten. Mit CustomResourceDefinitions (CRDs) können Kubernetes-Entwickler benutzerdefinierte Ressourcentypen deklarieren.\n\nIn Helm 3 werden CRDs als eine spezielle Art von Objekt behandelt. Sie werden vor dem Rest des Charts installiert und unterliegen einigen Einschränkungen.\n\nCRD-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.\n\nCRD-Dateien _können nicht als Template verwendet werden_. Sie müssen einfache YAML-Dokumente sein.\n\nWenn 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.\n\nWenn Ihr Chart beispielsweise eine CRD für `CronTab` im `crds/`-Verzeichnis hat, können Sie Instanzen der `CronTab`-Art im `templates/`-Verzeichnis erstellen:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nDie `crontab.yaml`-Datei muss die CRD ohne Template-Direktiven enthalten:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nDann kann das Template `mycrontab.yaml` eine neue `CronTab` erstellen (unter Verwendung von Templates wie üblich):\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm 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.\n\n### Einschränkungen bei CRDs\n\nIm 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:\n\n- 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.\n- CRDs werden bei Upgrades oder Rollbacks niemals installiert. Helm erstellt CRDs nur bei Installationsoperationen.\n- 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.\n\nOperatoren, die CRDs aktualisieren oder löschen möchten, werden ermutigt, dies manuell und mit großer Vorsicht zu tun.\n\n## Verwendung von Helm zur Verwaltung von Charts\n\nDas `helm`-Tool verfügt über mehrere Befehle für die Arbeit mit Charts.\n\nEs kann ein neues Chart für Sie erstellen:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nSobald Sie ein Chart bearbeitet haben, kann `helm` es für Sie in ein Chart-Archiv verpacken:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nSie können `helm` auch verwenden, um Probleme mit der Formatierung oder den Informationen Ihres Charts zu finden:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Chart Repositories\n\nEin _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.\n\nJeder 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.\n\nEin 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.\n\nAuf 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.\n\n## Chart Starter Packs\n\nDer `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`.\n\nBeispiele für die Verwendung:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nStarter 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:\n\n- Die `Chart.yaml` wird vom Generator überschrieben.\n- Benutzer werden erwarten, den Inhalt eines solchen Charts zu modifizieren, daher sollte die Dokumentation angeben, wie Benutzer dies tun können.\n- Alle Vorkommen von `<CHARTNAME>` 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 `<CHARTNAME>` darin NICHT ersetzt. Zusätzlich wird die Chart-Beschreibung nicht vererbt.\n\nDerzeit 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.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: Chart Hooks\ndescription: Beschreibt die Arbeit mit Chart Hooks.\nsidebar_position: 2\n---\n\nHelm bietet einen _Hook_-Mechanismus, der es Chart-Entwicklern ermöglicht, an\nbestimmten Punkten im Lebenszyklus eines Release einzugreifen. Sie können Hooks\nbeispielsweise nutzen, um:\n\n- Eine ConfigMap oder ein Secret während der Installation zu laden, bevor andere Charts geladen werden.\n- 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.\n- Einen Job vor dem Löschen eines Release auszuführen, um einen Dienst ordnungsgemäß aus der Rotation zu nehmen, bevor er entfernt wird.\n\nHooks 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.\n\n## Die verfügbaren Hooks\n\nFolgende Hooks sind definiert:\n\n| Annotationswert  | Beschreibung                                                                                           |\n| ---------------- | ------------------------------------------------------------------------------------------------------ |\n| `pre-install`    | Wird ausgeführt, nachdem Templates gerendert wurden, aber bevor Ressourcen in Kubernetes erstellt werden |\n| `post-install`   | Wird ausgeführt, nachdem alle Ressourcen in Kubernetes geladen wurden                                   |\n| `pre-delete`     | Wird bei einer Löschanfrage ausgeführt, bevor Ressourcen aus Kubernetes gelöscht werden                 |\n| `post-delete`    | Wird bei einer Löschanfrage ausgeführt, nachdem alle Ressourcen des Release gelöscht wurden             |\n| `pre-upgrade`    | Wird bei einer Upgrade-Anfrage ausgeführt, nachdem Templates gerendert wurden, aber bevor Ressourcen aktualisiert werden |\n| `post-upgrade`   | Wird bei einer Upgrade-Anfrage ausgeführt, nachdem alle Ressourcen aktualisiert wurden                  |\n| `pre-rollback`   | Wird bei einer Rollback-Anfrage ausgeführt, nachdem Templates gerendert wurden, aber bevor Ressourcen zurückgerollt werden |\n| `post-rollback`  | Wird bei einer Rollback-Anfrage ausgeführt, nachdem alle Ressourcen geändert wurden                     |\n| `test`           | Wird ausgeführt, wenn der Helm-Unterbefehl test aufgerufen wird ([siehe Testdokumentation](/topics/chart_tests.md)) |\n\n_Hinweis: Der `crd-install` Hook wurde in Helm 3 zugunsten des `crds/`-Verzeichnisses entfernt._\n\n## Hooks und der Release-Lebenszyklus\n\nHooks 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:\n\n1. Der Benutzer führt `helm install foo` aus\n2. Die Install-API der Helm-Bibliothek wird aufgerufen\n3. Nach einigen Validierungen rendert die Bibliothek die `foo`-Templates\n4. Die Bibliothek lädt die resultierenden Ressourcen in Kubernetes\n5. Die Bibliothek gibt das Release-Objekt (und andere Daten) an den Client zurück\n6. Der Client wird beendet\n\nHelm definiert zwei Hooks für den `install`-Lebenszyklus: `pre-install` und\n`post-install`. Wenn der Entwickler des `foo`-Charts beide Hooks implementiert, ändert sich der Lebenszyklus wie folgt:\n\n1. Der Benutzer führt `helm install foo` aus\n2. Die Install-API der Helm-Bibliothek wird aufgerufen\n3. CRDs im `crds/`-Verzeichnis werden installiert\n4. Nach einigen Validierungen rendert die Bibliothek die `foo`-Templates\n5. Die Bibliothek bereitet die Ausführung der `pre-install` Hooks vor (lädt Hook-Ressourcen in Kubernetes)\n6. 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.\n7. Die Bibliothek lädt dann den Hook mit der niedrigsten Gewichtung zuerst (negativ bis positiv)\n8. Die Bibliothek wartet, bis der Hook \"Ready\" ist (außer bei CRDs)\n9. 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.\n10. Die Bibliothek führt den `post-install` Hook aus (lädt Hook-Ressourcen)\n11. Die Bibliothek wartet, bis der Hook \"Ready\" ist\n12. Die Bibliothek gibt das Release-Objekt (und andere Daten) an den Client zurück\n13. Der Client wird beendet\n\nWas 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.\n\nBei 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.\nAb 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.\n\n### Hook-Ressourcen werden nicht mit den zugehörigen Releases verwaltet\n\nDie 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.\n\nPraktisch 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/).\n\n## Einen Hook schreiben\n\nHooks 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`.\n\nDas folgende Template, gespeichert unter `templates/post-install-job.yaml`, deklariert beispielsweise einen Job, der bei `post-install` ausgeführt wird:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nWas dieses Template zu einem Hook macht, ist die Annotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nEine Ressource kann mehrere Hooks implementieren:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nEbenso 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.\n\nWenn Subcharts Hooks deklarieren, werden diese ebenfalls ausgewertet. Es gibt keine Möglichkeit für ein übergeordnetes Chart, die von Subcharts deklarierten Hooks zu deaktivieren.\n\nEs 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:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nHook-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.\n\n### Hook-Löschrichtlinien\n\nEs 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:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nSie können einen oder mehrere der definierten Annotationswerte wählen:\n\n| Annotationswert        | Beschreibung                                                           |\n| ---------------------- | ---------------------------------------------------------------------- |\n| `before-hook-creation` | Die vorherige Ressource löschen, bevor ein neuer Hook gestartet wird (Standard) |\n| `hook-succeeded`       | Die Ressource löschen, nachdem der Hook erfolgreich ausgeführt wurde   |\n| `hook-failed`          | Die Ressource löschen, wenn der Hook während der Ausführung fehlgeschlagen ist |\n\nWenn keine Hook-Löschrichtlinien-Annotation angegeben ist, gilt standardmäßig das `before-hook-creation`-Verhalten.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: Veraltete Kubernetes-APIs\ndescription: Erläutert veraltete Kubernetes-APIs im Kontext von Helm\n---\n\nKubernetes ist ein API-gesteuertes System. Die API entwickelt sich im Laufe der\nZeit weiter, um das wachsende Verständnis des Problembereichs widerzuspiegeln.\nDies ist gängige Praxis bei Systemen und ihren APIs. Ein wichtiger Teil der\nAPI-Weiterentwicklung ist eine gute Deprecation-Richtlinie und ein entsprechender\nProzess, um Benutzer über Änderungen zu informieren. Die Nutzer Ihrer API müssen\nim Voraus wissen, in welchem Release eine API entfernt oder geändert wird. So\nwerden Überraschungen und unerwartete Änderungen vermieden.\n\nDie [Kubernetes-Deprecation-Richtlinie](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\ndokumentiert, wie Kubernetes Änderungen an seinen API-Versionen handhabt. Die\nRichtlinie legt fest, wie lange API-Versionen nach einer Deprecation-Ankündigung\nunterstützt werden. Achten Sie daher auf Deprecation-Ankündigungen und informieren\nSie sich, wann API-Versionen entfernt werden, um die Auswirkungen zu minimieren.\n\nEin Beispiel für eine solche Ankündigung ist [die Entfernung veralteter\nAPI-Versionen in Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/).\nDiese wurde einige Monate vor dem Release veröffentlicht. Die betroffenen\nAPI-Versionen waren zuvor bereits als veraltet angekündigt worden. Dies zeigt,\ndass eine gute Richtlinie existiert, die Nutzer über die Unterstützung von\nAPI-Versionen informiert.\n\nHelm-Templates geben eine [Kubernetes-API-Gruppe](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)\nan, wenn ein Kubernetes-Objekt definiert wird – ähnlich wie eine\nKubernetes-Manifest-Datei. Die API-Gruppe wird im Feld `apiVersion` des Templates\nangegeben und identifiziert die API-Version des Kubernetes-Objekts. Helm-Benutzer\nund Chart-Maintainer müssen daher wissen, wann Kubernetes-API-Versionen als\nveraltet markiert wurden und in welcher Kubernetes-Version sie entfernt werden.\n\n## Chart-Maintainer\n\nÜberprüfen Sie Ihre Charts auf Kubernetes-API-Versionen, die veraltet sind oder\nin einer Kubernetes-Version entfernt wurden. Aktualisieren Sie API-Versionen,\ndie veraltet oder nicht mehr unterstützt werden, auf die aktuelle Version und\nveröffentlichen Sie eine neue Chart-Version. Die API-Version wird durch die\nFelder `kind` und `apiVersion` definiert. Hier ein Beispiel für eine in\nKubernetes 1.16 entfernte `Deployment`-API-Version:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Helm-Benutzer\n\nÜberprüfen Sie die von Ihnen verwendeten Charts (ähnlich wie\n[Chart-Maintainer](#chart-maintainer)) und identifizieren Sie alle Charts mit\nveralteten oder entfernten API-Versionen. Prüfen Sie für die identifizierten\nCharts, ob eine neuere Chart-Version mit unterstützten API-Versionen verfügbar\nist, oder aktualisieren Sie das Chart selbst.\n\nÜberprüfen Sie zusätzlich alle bereitgestellten Charts (d. h. Helm-Releases)\nauf veraltete oder entfernte API-Versionen. Verwenden Sie dazu den Befehl\n`helm get manifest`, um die Details eines Releases abzurufen.\n\nDie Vorgehensweise zur Aktualisierung eines Helm-Releases auf unterstützte APIs\nhängt von Ihren Ergebnissen ab:\n\n1. Wenn Sie nur veraltete API-Versionen finden:\n   - Führen Sie ein `helm upgrade` mit einer Chart-Version durch, die\n     unterstützte Kubernetes-API-Versionen verwendet\n   - Fügen Sie eine Beschreibung hinzu, die darauf hinweist, kein Rollback auf\n     eine frühere Helm-Version durchzuführen\n2. Wenn Sie API-Versionen finden, die in einer Kubernetes-Version entfernt wurden:\n   - Falls Sie eine Kubernetes-Version verwenden, in der die API-Versionen noch\n     verfügbar sind (z. B. Sie nutzen Kubernetes 1.15 und haben APIs gefunden,\n     die in Kubernetes 1.16 entfernt werden):\n     - Befolgen Sie die Schritte aus Punkt 1\n   - Andernfalls (z. B. Sie nutzen bereits eine Kubernetes-Version, in der einige\n     von `helm get manifest` gemeldete API-Versionen nicht mehr verfügbar sind):\n     - Bearbeiten Sie das im Cluster gespeicherte Release-Manifest, um die\n       API-Versionen zu aktualisieren. Weitere Details finden Sie unter\n       [API-Versionen eines Release-Manifests aktualisieren](#api-versionen-eines-release-manifests-aktualisieren)\n\n> Hinweis: Führen Sie in keinem Fall ein Rollback auf eine Version vor der\nRelease-Version mit den unterstützten APIs durch.\n\n> Empfehlung: Aktualisieren Sie Releases mit veralteten API-Versionen auf\nunterstützte API-Versionen, bevor Sie auf einen Kubernetes-Cluster upgraden,\nder diese API-Versionen entfernt.\n\nWenn Sie ein Release nicht wie empfohlen aktualisieren, erhalten Sie beim\nUpgrade-Versuch in einer Kubernetes-Version, in der die API-Versionen entfernt\nwurden, einen Fehler wie diesen:\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm schlägt in diesem Szenario fehl, weil es versucht, einen Diff-Patch zwischen\ndem aktuell bereitgestellten Release (mit den entfernten Kubernetes-APIs) und dem\nChart mit den aktualisierten API-Versionen zu erstellen. Der eigentliche Grund:\nWenn Kubernetes eine API-Version entfernt, kann die Kubernetes-Go-Client-Bibliothek\ndie veralteten Objekte nicht mehr parsen. Helm schlägt daher beim Aufruf der\nBibliothek fehl und kann sich von dieser Situation nicht erholen. Weitere Details\nzur Behebung finden Sie unter [API-Versionen eines Release-Manifests aktualisieren](#api-versionen-eines-release-manifests-aktualisieren).\n\n## API-Versionen eines Release-Manifests aktualisieren\n\nDas Manifest ist eine Eigenschaft des Helm-Release-Objekts und wird im Datenfeld\neines Secrets (Standard) oder einer ConfigMap im Cluster gespeichert. Das Datenfeld\nenthält ein gzipptes Objekt, das Base64-kodiert ist (bei einem Secret gibt es eine\nzusätzliche Base64-Kodierung). Pro Release-Version/Revision existiert ein Secret\nbzw. eine ConfigMap im Namespace des Releases.\n\nVerwenden Sie das Helm-Plugin [mapkubeapis](https://github.com/helm/helm-mapkubeapis),\num ein Release auf unterstützte APIs zu aktualisieren. Weitere Details finden Sie\nin der Readme-Datei.\n\nAlternativ können Sie die folgenden manuellen Schritte durchführen, um die\nAPI-Versionen eines Release-Manifests zu aktualisieren. Je nach Konfiguration\nfolgen Sie den Schritten für das Secret- oder ConfigMap-Backend.\n\n- Namen des Secrets oder der ConfigMap abrufen, das/die mit dem zuletzt\n  bereitgestellten Release verknüpft ist:\n  - Secrets-Backend: `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - ConfigMap-Backend: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- Details des zuletzt bereitgestellten Releases abrufen:\n  - Secrets-Backend: `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - ConfigMap-Backend: `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- Release sichern:\n  - `cp release.yaml release.bak`\n  - Im Notfall wiederherstellen: `kubectl apply -f release.bak -n\n    <release_namespace>`\n- Release-Objekt dekodieren:\n  - Secrets-Backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - ConfigMap-Backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- API-Versionen der Manifeste ändern. Verwenden Sie ein beliebiges Werkzeug\n  (z. B. einen Editor) für die Änderungen. Die Manifeste befinden sich im Feld\n  `manifest` Ihres dekodierten Release-Objekts (`release.data.decoded`)\n- Release-Objekt kodieren:\n  - Secrets-Backend: `cat release.data.decoded | gzip | base64 | base64`\n  - ConfigMap-Backend: `cat release.data.decoded | gzip | base64`\n- Den Wert der Eigenschaft `data.release` in der Release-Datei (`release.yaml`)\n  durch das neue kodierte Release-Objekt ersetzen\n- Datei auf den Namespace anwenden: `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- Ein `helm upgrade` mit einer Chart-Version durchführen, die unterstützte\n  Kubernetes-API-Versionen verwendet\n- Eine Beschreibung hinzufügen, die darauf hinweist, kein Rollback auf eine\n  frühere Helm-Version durchzuführen\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: Leitfaden für Kubernetes-Distributionen\ndescription: Enthält Informationen zur Verwendung von Helm in bestimmten Kubernetes-Umgebungen.\nsidebar_position: 10\n---\n\nHelm sollte mit jeder [konformen Version von\nKubernetes](https://github.com/cncf/k8s-conformance) funktionieren (ob\n[zertifiziert](https://www.cncf.io/certification/software-conformance/) oder nicht).\n\nDieses Dokument enthält Informationen zur Verwendung von Helm in bestimmten\nKubernetes-Umgebungen. Bitte tragen Sie weitere Details zu beliebigen Distributionen\n(alphabetisch sortiert) bei, falls gewünscht.\n\n\n## AKS\n\nHelm funktioniert mit [Azure Kubernetes\nService](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nHelm wurde auf der Mesosphere DC/OS 1.11 Kubernetes-Plattform getestet und\nfunktioniert ohne zusätzliche Konfiguration.\n\n## EKS\n\nHelm funktioniert mit Amazon Elastic Kubernetes Service (Amazon EKS):\n[Verwendung von Helm mit Amazon\nEKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nGoogles gehostete Kubernetes-Plattform GKE funktioniert nachweislich mit Helm\nund erfordert keine zusätzliche Konfiguration.\n\n## `scripts/local-cluster` und Hyperkube\n\nHyperkube, konfiguriert über `scripts/local-cluster.sh`, funktioniert nachweislich.\nBei reinem Hyperkube ist möglicherweise eine manuelle Konfiguration erforderlich.\n\n## IKS\n\nHelm funktioniert mit [IBM Cloud Kubernetes\nService](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nHelm wird regelmäßig auf [KIND](https://github.com/kubernetes-sigs/kind) getestet.\n\n## KubeOne\n\nHelm funktioniert in Clustern, die mit KubeOne eingerichtet wurden, ohne\nEinschränkungen.\n\n## Kubermatic\n\nHelm funktioniert in Benutzer-Clustern, die von Kubermatic erstellt wurden, ohne\nEinschränkungen. Da Seed-Cluster auf verschiedene Arten eingerichtet werden können,\nhängt die Helm-Unterstützung von deren Konfiguration ab.\n\n## MicroK8s\n\nHelm kann in [MicroK8s](https://microk8s.io) mit dem folgenden Befehl aktiviert werden:\n`microk8s.enable helm3`\n\n## Minikube\n\nHelm wurde mit [Minikube](https://github.com/kubernetes/minikube) getestet und\nfunktioniert nachweislich. Es ist keine zusätzliche Konfiguration erforderlich.\n\n## Openshift\n\nHelm funktioniert problemlos auf OpenShift Online, OpenShift Dedicated,\nOpenShift Container Platform (Version >= 3.6) oder OpenShift Origin (Version >= 3.6).\nWeitere Informationen finden Sie in diesem\n[Blogbeitrag](https://blog.openshift.com/getting-started-helm-openshift/).\n\n## Platform9\n\nHelm ist bei [Platform9 Managed\nKubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes)\nvorinstalliert. Platform9 bietet Zugang zu allen offiziellen Helm-Charts über die\nApp-Katalog-Benutzeroberfläche und die native Kubernetes-CLI. Zusätzliche Repositories\nkönnen manuell hinzugefügt werden. Weitere Details finden Sie in diesem [Platform9\nApp-Katalog-Artikel](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes).\n\n## Ubuntu mit `kubeadm`\n\nKubernetes, das mittels `kubeadm` eingerichtet wurde, funktioniert nachweislich auf\nfolgenden Linux-Distributionen:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nBei einigen Helm-Versionen (v2.0.0-beta2) müssen Sie `export\nKUBECONFIG=/etc/kubernetes/admin.conf` ausführen oder eine `~/.kube/config` erstellen.\n\n## VMware Tanzu Kubernetes Grid\n\nHelm läuft auf VMware Tanzu Kubernetes Grid (TKG) ohne Konfigurationsänderungen.\nDie Tanzu CLI kann die Installation von Paketen für [helm-controller](https://fluxcd.io/flux/components/helm/)\nverwalten und ermöglicht so die deklarative Verwaltung von Helm-Chart-Releases.\nWeitere Details finden Sie in der TKG-Dokumentation für [CLI-verwaltete\nPakete](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).\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: Library Charts\ndescription: Erläutert Library Charts und zeigt Anwendungsbeispiele\nsidebar_position: 4\n---\n\nEin Library Chart ist ein spezieller Typ von [Helm Chart](/topics/charts.md),\nder Chart-Primitive oder -Definitionen bereitstellt, die von Helm-Templates\nin anderen Charts verwendet werden können. So lassen sich Code-Snippets\nüber mehrere Charts hinweg gemeinsam nutzen, wodurch Wiederholungen vermieden\nund Charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) gehalten werden.\n\nDas Library Chart wurde in Helm 3 eingeführt, um offiziell gemeinsam genutzte Charts\noder Helper Charts anzuerkennen, die von Chart-Maintainern bereits seit Helm 2\nverwendet werden. Durch die Definition als eigener Chart-Typ bietet es:\n- Eine Möglichkeit zur expliziten Unterscheidung zwischen gemeinsam genutzten Charts\n  und Anwendungs-Charts\n- Logik zur Verhinderung der Installation eines gemeinsam genutzten Charts\n- Kein Rendering von Templates in einem gemeinsam genutzten Chart, die Release-Artefakte\n  enthalten könnten\n- Die Möglichkeit für abhängige Charts, den Kontext des importierenden Charts zu nutzen\n\nEin Chart-Maintainer kann ein gemeinsam genutztes Chart als Library Chart definieren\nund sicher sein, dass Helm das Chart auf eine standardisierte und konsistente Weise\nbehandelt. Darüber hinaus können Definitionen aus einem Anwendungs-Chart geteilt werden,\nindem einfach der Chart-Typ geändert wird.\n\n## Ein einfaches Library Chart erstellen\n\nWie bereits erwähnt, ist ein Library Chart ein spezieller Typ von\n[Helm Chart](/topics/charts.md). Das bedeutet, dass Sie mit der Erstellung\neines Grundgerüst-Charts beginnen können:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nZunächst entfernen Sie alle Dateien im Verzeichnis `templates`, da wir in diesem\nBeispiel eigene Template-Definitionen erstellen werden.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nDie Values-Datei wird ebenfalls nicht benötigt.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nBevor wir mit dem Erstellen von gemeinsam genutztem Code beginnen, gehen wir kurz\neinige relevante Helm-Konzepte durch. Ein\n[benanntes Template](/chart_template_guide/named_templates.md)\n(manchmal auch Partial oder Subtemplate genannt) ist einfach ein Template, das in\neiner Datei definiert und mit einem Namen versehen wird. Im Verzeichnis `templates/`\nwird jede Datei, die mit einem Unterstrich (_) beginnt, nicht als Kubernetes-Manifest\nausgegeben. Daher werden Hilfs-Templates und Partials üblicherweise in\n`_*.tpl`- oder `_*.yaml`-Dateien abgelegt.\n\nIn diesem Beispiel erstellen wir eine gemeinsam nutzbare ConfigMap, die eine leere\nConfigMap-Ressource definiert. Wir definieren die gemeinsame ConfigMap in der Datei\n`mylibchart/templates/_configmap.yaml` wie folgt:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nDas ConfigMap-Konstrukt wird im benannten Template `mylibchart.configmap.tpl` definiert.\nEs handelt sich um eine einfache ConfigMap mit einer leeren Ressource, `data`. In\ndieser Datei gibt es ein weiteres benanntes Template namens `mylibchart.configmap`.\nDieses benannte Template bindet ein anderes benanntes Template `mylibchart.util.merge`\nein, das 2 benannte Templates als Argumente entgegennimmt: das Template, das\n`mylibchart.configmap` aufruft, und `mylibchart.configmap.tpl`.\n\nDie Hilfsfunktion `mylibchart.util.merge` ist ein benanntes Template in\n`mylibchart/templates/_util.yaml`. Es handelt sich um ein praktisches Hilfsmittel\naus [The Common Helm Helper Chart](#the-common-helm-helper-chart), da es die\n2 Templates zusammenführt und gemeinsame Teile in beiden überschreibt:\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nDies ist wichtig, wenn ein Chart gemeinsamen Code verwenden möchte, den es mit\nseiner eigenen Konfiguration anpassen muss.\n\nZum Schluss ändern wir den Chart-Typ zu `library`. Dazu muss\n`mylibchart/Chart.yaml` wie folgt bearbeitet werden:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\nDas Library Chart ist nun bereit zum Teilen und seine ConfigMap-Definition kann\nwiederverwendet werden.\n\nBevor Sie fortfahren, lohnt es sich zu überprüfen, ob Helm das Chart als Library\nChart erkennt:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Das einfache Library Chart verwenden\n\nEs ist nun Zeit, das Library Chart zu verwenden. Das bedeutet, wieder ein\nGrundgerüst-Chart zu erstellen:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nEntfernen wir wieder die Template-Dateien, da wir nur eine ConfigMap erstellen möchten:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nWenn wir eine einfache ConfigMap in einem Helm-Template erstellen möchten, könnte\nsie etwa so aussehen:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nWir werden jedoch den bereits in `mylibchart` erstellten gemeinsamen Code\nwiederverwenden. Die ConfigMap kann in der Datei `mychart/templates/configmap.yaml`\nwie folgt erstellt werden:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nSie sehen, dass sich die Arbeit vereinfacht, indem die gemeinsame ConfigMap-Definition\ngeerbt wird, die Standardeigenschaften für ConfigMaps hinzufügt. In unserem Template\nfügen wir die Konfiguration hinzu, in diesem Fall den Datenschlüssel `myvalue` und\nseinen Wert. Die Konfiguration überschreibt die leere Ressource der gemeinsamen\nConfigMap. Dies ist möglich dank der Hilfsfunktion `mylibchart.util.merge`, die\nwir im vorherigen Abschnitt erwähnt haben.\n\nUm den gemeinsamen Code verwenden zu können, müssen wir `mylibchart` als Abhängigkeit\nhinzufügen. Fügen Sie Folgendes am Ende der Datei `mychart/Chart.yaml` hinzu:\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nDies bindet das Library Chart als dynamische Abhängigkeit aus dem Dateisystem ein,\ndas sich auf derselben übergeordneten Pfadebene wie unser Anwendungs-Chart befindet.\nDa wir das Library Chart als dynamische Abhängigkeit einbinden, müssen wir\n`helm dependency update` ausführen. Dieser Befehl kopiert das Library Chart in Ihr\nVerzeichnis `charts/`.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nWir sind nun bereit, unser Chart zu deployen. Vor der Installation lohnt es sich,\nzunächst das gerenderte Template zu überprüfen.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nDas sieht nach der ConfigMap aus, die wir wollen, mit dem überschriebenen Datenwert\n`myvalue: Hello World`. Lassen Sie uns das Chart installieren:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nWir können das Release abrufen und sehen, dass das eigentliche Template geladen wurde.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## Vorteile von Library Charts\n\nDa Library Charts nicht als eigenständige Charts fungieren können, bieten sie\nfolgende Funktionalität:\n- Das `.Files`-Objekt verweist auf die Dateipfade des übergeordneten Charts,\n  nicht auf den lokalen Pfad des Library Charts\n- Das `.Values`-Objekt ist identisch mit dem des übergeordneten Charts, im\n  Gegensatz zu Anwendungs-[Subcharts](/chart_template_guide/subcharts_and_globals.md),\n  die den Abschnitt der Values erhalten, der unter ihrem Header im übergeordneten\n  Chart konfiguriert ist\n\n\n## The Common Helm Helper Chart\n\n```markdown\nNote: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived.\n```\n\nDieses [Chart](https://github.com/helm/charts/tree/master/incubator/common) war\ndas ursprüngliche Muster für Library Charts. Es bietet Hilfsmittel, die Best\nPractices der Kubernetes-Chart-Entwicklung widerspiegeln. Der besondere Vorteil:\nSie können es bei der Entwicklung Ihrer Charts sofort verwenden, um praktischen\ngemeinsamen Code zu nutzen.\n\nHier ist eine schnelle Möglichkeit, es zu verwenden. Weitere Details finden Sie\nin der [README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nErstellen Sie wieder ein Grundgerüst-Chart:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nVerwenden wir den gemeinsamen Code aus dem Helper Chart. Bearbeiten Sie zunächst\ndas Deployment `demo/templates/deployment.yaml` wie folgt:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nUnd nun die Service-Datei `demo/templates/service.yaml` wie folgt:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nDiese Templates zeigen, wie das Erben von gemeinsam genutztem Code aus dem Helper\nChart Ihre Arbeit auf die Konfiguration oder Anpassung der Ressourcen reduziert.\n\nUm den gemeinsamen Code verwenden zu können, müssen wir `common` als Abhängigkeit\nhinzufügen. Fügen Sie Folgendes am Ende der Datei `demo/Chart.yaml` hinzu:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nHinweis: Sie müssen das `incubator`-Repository zur Helm-Repository-Liste hinzufügen\n(`helm repo add`).\n\nDa wir das Chart als dynamische Abhängigkeit einbinden, müssen wir\n`helm dependency update` ausführen. Dieser Befehl kopiert das Helper Chart in\nIhr Verzeichnis `charts/`.\n\nDa das Helper Chart einige Helm 2-Konstrukte verwendet, müssen Sie Folgendes zu\n`demo/values.yaml` hinzufügen, um das `nginx`-Image zu laden, da dies im\nHelm 3-Grundgerüst-Chart aktualisiert wurde:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nSie können mit den Befehlen `helm lint` und `helm template` testen, ob die\nChart-Templates korrekt sind, bevor Sie sie deployen.\n\nWenn alles in Ordnung ist, deployen Sie mit `helm install`!\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Berechtigungsverwaltung für das SQL-Speicher-Backend\ndescription: Erfahren Sie, wie Sie Berechtigungen bei Verwendung des SQL-Speicher-Backends einrichten.\n---\n\nDieses Dokument bietet eine Anleitung zur Einrichtung und Verwaltung von\nBerechtigungen bei Verwendung des SQL-Speicher-Backends.\n\n## Einführung\n\nHelm nutzt für die Berechtigungsverwaltung die RBAC-Funktion von Kubernetes. Bei\nVerwendung des SQL-Speicher-Backends können Kubernetes-Roles jedoch nicht verwendet\nwerden, um zu bestimmen, ob ein Benutzer auf eine bestimmte Ressource zugreifen darf.\nDieses Dokument zeigt, wie Sie diese Berechtigungen erstellen und verwalten.\n\n## Initialisierung\n\nBeim ersten Verbindungsaufbau der Helm CLI mit Ihrer Datenbank prüft der Client,\nob diese bereits initialisiert wurde. Falls nicht, führt er die notwendige\nEinrichtung automatisch durch. Diese Initialisierung erfordert Administratorrechte\nauf dem public-Schema oder mindestens folgende Berechtigungen:\n\n* eine Tabelle erstellen\n* Berechtigungen auf dem public-Schema vergeben\n\nNachdem die Migration auf Ihrer Datenbank ausgeführt wurde, können alle anderen\nRollen den Client nutzen.\n\n## Berechtigungen für einen Nicht-Administrator in PostgreSQL vergeben\n\nZur Verwaltung von Berechtigungen nutzt der SQL-Backend-Treiber die\n[RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)-Funktion\n(Row-Level Security, Sicherheit auf Zeilenebene) von PostgreSQL. RLS ermöglicht\nes allen Benutzern, aus derselben Tabelle zu lesen und in diese zu schreiben,\nohne dabei auf dieselben Zeilen zugreifen zu können, sofern ihnen dies nicht\nexplizit erlaubt wurde. Standardmäßig erhält jede Rolle, der nicht explizit die\nentsprechenden Rechte gewährt wurden, eine leere Liste bei Ausführung von\n`helm list` und kann keine Ressourcen im Cluster abrufen oder ändern.\n\nSo gewähren Sie einer bestimmten Rolle Zugriff auf spezifische Namespaces:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nDieser Befehl gewährt der Rolle `role` die Berechtigung, alle Ressourcen zu lesen\nund zu schreiben, die die Bedingung `namespace = 'default'` erfüllen. Nach dem\nErstellen dieser Policy kann der Benutzer, der im Namen der Rolle `role` mit der\nDatenbank verbunden ist, alle Releases im Namespace `default` bei Ausführung von\n`helm list` sehen sowie diese bearbeiten und löschen.\n\nBerechtigungen lassen sich mit RLS granular verwalten. So können Sie den Zugriff\nanhand der verschiedenen Tabellenspalten einschränken:\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Der Helm Plugins Leitfaden\ndescription: Erklärt, wie Sie Plugins verwenden und erstellen können, um die Funktionalität von Helm zu erweitern.\nsidebar_position: 12\n---\n\nEin Helm Plugin ist ein Werkzeug, das über die `helm` CLI aufgerufen werden kann,\naber nicht Teil des integrierten Helm-Quellcodes ist.\n\nBestehende Plugins finden Sie im Bereich [Verwandte Projekte](/community/related#helm-plugins)\noder durch eine Suche auf [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).\n\nDieser Leitfaden erklärt, wie Sie Plugins verwenden und erstellen.\n\n## Überblick\n\nHelm Plugins sind Erweiterungswerkzeuge, die sich nahtlos in Helm integrieren. Sie\nbieten eine Möglichkeit, die Kernfunktionalität von Helm zu erweitern, ohne dass\njede neue Funktion in Go geschrieben und dem Kern-Tool hinzugefügt werden muss.\n\nHelm Plugins haben folgende Eigenschaften:\n\n- Sie können einer Helm-Installation hinzugefügt und daraus entfernt werden, ohne\n  das Kern-Tool zu beeinflussen.\n- Sie können in jeder Programmiersprache geschrieben werden.\n- Sie integrieren sich in Helm und erscheinen in `helm help` und an anderen Stellen.\n\nHelm Plugins befinden sich in `$HELM_PLUGINS`. Den aktuellen Wert dieses Pfads,\neinschließlich des Standardwerts wenn er nicht in der Umgebung gesetzt ist, können\nSie mit dem Befehl `helm env` ermitteln.\n\nDas Helm Plugin-Modell basiert teilweise auf dem Plugin-Modell von Git. Daher\nwird `helm` manchmal als _Porcelain_-Schicht (Benutzeroberfläche) bezeichnet,\nwährend Plugins die _Plumbing_-Schicht (Basiswerkzeuge) darstellen. Das bedeutet:\nHelm stellt die Benutzererfahrung und die übergeordnete Verarbeitungslogik bereit,\nwährend die Plugins die \"Detailarbeit\" zur Ausführung einer gewünschten Aktion\nübernehmen.\n\n## Ein Plugin installieren\n\nPlugins werden mit dem Befehl `$ helm plugin install <pfad|url>` installiert. Sie\nkönnen einen Pfad zu einem Plugin auf Ihrem lokalen Dateisystem oder eine URL\neines entfernten VCS-Repositories angeben. Der Befehl `helm plugin install` klont\noder kopiert das Plugin vom angegebenen Pfad/URL nach `$HELM_PLUGINS`. Wenn Sie\nvon einem VCS installieren, können Sie die Version mit dem Argument `--version`\nangeben.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nWenn Sie eine Plugin-Tar-Distribution haben, entpacken Sie das Plugin einfach in\ndas Verzeichnis `$HELM_PLUGINS`. Sie können Tarball-Plugins auch direkt von einer\nURL installieren mit `helm plugin install https://domain/path/to/plugin.tar.gz`\n\n## Die Plugin-Dateistruktur\n\nEin Plugin ähnelt in vieler Hinsicht einem Chart. Jedes Plugin hat ein\nübergeordnetes Verzeichnis mit einer `plugin.yaml`-Datei. Weitere Dateien können\nvorhanden sein, aber nur die `plugin.yaml`-Datei ist erforderlich.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## Die plugin.yaml-Datei\n\nDie plugin.yaml-Datei ist für ein Plugin erforderlich. Sie enthält folgende Felder:\n\n```yaml\nname: The name of the plugin (REQUIRED)\nversion: A SemVer 2 version (REQUIRED)\nusage: Single line usage text shown in help\ndescription: Long description shown in places like helm help\nignoreFlags: Ignore flags passed in from Helm\nplatformCommand: # Configure command to run based on the platform\n  - os: OS match, can be empty or omitted to match all OS'\n    arch: Architecture match, can be empty or omitted to match all architectures\n    command: Plugin command to execute\n    args: Plugin command arguments\ncommand: (DEPRECATED) Plugin command, use platformCommand instead\nplatformHooks: # Configure plugin lifecycle hooks based on the platform\n  install: # Install lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin install command to execute\n      args: Plugin install command arguments\n  update: # Update lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin update command to execute\n      args: Plugin update command arguments\n  delete: # Delete lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin delete command to execute\n      args: Plugin delete command arguments\nhooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead\n  install: Command to install plugin\n  update: Command to update plugin\n  delete: Command to delete plugin\ndownloaders: # Configure downloaders capability\n  - command: Command to invoke\n    protocols:\n      - Protocol schema supported\n```\n\n### Das Feld `name`\n\nDas `name` ist der Name des Plugins. Wenn Helm dieses Plugin ausführt, verwendet\nes diesen Namen (z. B. wird `helm NAME` dieses Plugin aufrufen).\n\n_`name` sollte mit dem Verzeichnisnamen übereinstimmen._ In unserem Beispiel oben\nbedeutet das, dass das Plugin mit `name: last` in einem Verzeichnis namens `last`\nenthalten sein sollte.\n\nEinschränkungen für `name`:\n\n- `name` darf keinen der bestehenden `helm` Top-Level-Befehle duplizieren.\n- `name` muss auf die ASCII-Zeichen a-z, A-Z, 0-9, `_` und `-` beschränkt sein.\n\n### Das Feld `version`\n\nDas `version` ist die SemVer 2-Version des Plugins. `usage` und `description`\nwerden beide zur Generierung des Hilfetextes eines Befehls verwendet.\n\n### Das Feld `ignoreFlags`\n\nDer Schalter `ignoreFlags` weist Helm an, _keine_ Flags an das Plugin zu übergeben.\nWenn also ein Plugin mit `helm myplugin --foo` aufgerufen wird und `ignoreFlags:\ntrue` gesetzt ist, wird `--foo` stillschweigend verworfen.\n\n### Das Feld `platformCommand`\n\nDas `platformCommand` konfiguriert den Befehl, den das Plugin bei Aufruf ausführt.\nSie können nicht sowohl `platformCommand` als auch `command` setzen, da dies zu\neinem Fehler führt. Die folgenden Regeln gelten für die Auswahl des auszuführenden\nBefehls:\n\n- Wenn `platformCommand` vorhanden ist, wird es verwendet.\n  - Wenn sowohl `os` als auch `arch` mit der aktuellen Plattform übereinstimmen,\n  wird die Suche beendet und der Befehl verwendet.\n  - Wenn `os` übereinstimmt und `arch` leer ist, wird der Befehl verwendet.\n  - Wenn sowohl `os` als auch `arch` leer sind, wird der Befehl verwendet.\n  - Wenn keine Übereinstimmung vorliegt, beendet sich Helm mit einem Fehler.\n- Wenn `platformCommand` nicht vorhanden ist und das veraltete `command` vorhanden\nist, wird es verwendet.\n  - Wenn der Befehl leer ist, beendet sich Helm mit einem Fehler.\n\n### Das Feld `platformHooks`\n\nDas `platformHooks` konfiguriert die Befehle, die das Plugin für Lifecycle-Events\nausführt. Sie können nicht sowohl `platformHooks` als auch `hooks` setzen, da dies\nzu einem Fehler führt. Die folgenden Regeln gelten für die Auswahl des Hook-Befehls:\n\n- Wenn `platformHooks` vorhanden ist, wird es verwendet und die Befehle für das\nLifecycle-Event werden verarbeitet.\n  - Wenn sowohl `os` als auch `arch` mit der aktuellen Plattform übereinstimmen,\n  wird die Suche beendet und der Befehl verwendet.\n  - Wenn `os` übereinstimmt und `arch` leer ist, wird der Befehl verwendet.\n  - Wenn sowohl `os` als auch `arch` leer sind, wird der Befehl verwendet.\n  - Wenn keine Übereinstimmung vorliegt, überspringt Helm das Event.\n- Wenn `platformHooks` nicht vorhanden ist und das veraltete `hooks` vorhanden ist,\nwird der Befehl für das Lifecycle-Event verwendet.\n  - Wenn der Befehl leer ist, überspringt Helm das Event.\n\n## Ein Plugin erstellen\n\nHier ist das Plugin-YAML für ein einfaches Plugin, das den letzten Release-Namen\nabruft:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nPlugins können zusätzliche Skripte und ausführbare Dateien benötigen.\nSkripte können im Plugin-Verzeichnis enthalten sein und ausführbare Dateien können\nüber einen Hook heruntergeladen werden. Das folgende Beispiel zeigt ein Plugin:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nUmgebungsvariablen werden interpoliert, bevor das Plugin ausgeführt wird. Das\nobige Muster zeigt die bevorzugte Methode, um anzugeben, wo sich das Plugin-Programm\nbefindet.\n\n### Plugin-Befehle\n\nEs gibt einige Strategien für die Arbeit mit Plugin-Befehlen:\n\n- Wenn ein Plugin eine ausführbare Datei enthält, sollte die ausführbare Datei für\n  einen `platformCommand:` im Plugin-Verzeichnis verpackt oder über einen Hook\n  installiert werden.\n- Die Zeile `platformCommand:` oder `command:` wird vor der Ausführung alle\n  Umgebungsvariablen expandieren. `$HELM_PLUGIN_DIR` zeigt auf das Plugin-Verzeichnis.\n- Der Befehl selbst wird nicht in einer Shell ausgeführt. Sie können also kein\n  Shell-Skript in einer Zeile schreiben.\n- Helm injiziert viele Konfigurationen in Umgebungsvariablen. Schauen Sie in die\n  Umgebung, um zu sehen, welche Informationen verfügbar sind.\n- Helm macht keine Annahmen über die Sprache des Plugins. Sie können es in der\n  Sprache Ihrer Wahl schreiben.\n- Befehle sind dafür verantwortlich, spezifische Hilfetexte für `-h` und\n  `--help` zu implementieren. Helm verwendet `usage` und `description` für\n  `helm help` und `helm help myplugin`, behandelt aber nicht `helm myplugin --help`.\n\n### Ein lokales Plugin testen\n\nZuerst müssen Sie Ihren `HELM_PLUGINS`-Pfad finden. Führen Sie dazu den folgenden\nBefehl aus:\n\n``` bash\nhelm env\n```\n\nWechseln Sie in das Verzeichnis, auf das `HELM_PLUGINS` gesetzt ist.\n\nJetzt können Sie einen symbolischen Link zu Ihrer Build-Ausgabe Ihres Plugins\nhinzufügen – in diesem Beispiel haben wir es für `mapkubeapis` gemacht.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Downloader Plugins\n\nStandardmäßig kann Helm Charts über HTTP/S herunterladen. Seit Helm 2.4.0 können\nPlugins eine spezielle Fähigkeit haben, Charts aus beliebigen Quellen\nherunterzuladen.\n\nPlugins deklarieren diese spezielle Fähigkeit in der `plugin.yaml`-Datei (auf\noberster Ebene):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nWenn ein solches Plugin installiert ist, kann Helm mit dem Repository über das\nangegebene Protokollschema interagieren, indem es den `command` aufruft. Das\nspezielle Repository wird ähnlich wie reguläre Repositories hinzugefügt:\n`helm repo add favorite myprotocol://example.com/` Die Regeln für spezielle\nRepositories sind die gleichen wie für reguläre: Helm muss in der Lage sein,\ndie `index.yaml`-Datei herunterzuladen, um die Liste der verfügbaren Charts zu\nermitteln und zwischenzuspeichern.\n\nDer definierte Befehl wird mit folgendem Schema aufgerufen: `command certFile\nkeyFile caFile full-URL`. Die SSL-Anmeldeinformationen stammen aus der\nRepository-Definition, die in `$HELM_REPOSITORY_CONFIG` gespeichert ist\n(d. h. `$HELM_CONFIG_HOME/repositories.yaml`). Ein Downloader-Plugin soll den\nRohinhalt auf stdout ausgeben und Fehler auf stderr melden.\n\nDer Downloader-Befehl unterstützt auch Unterbefehle oder Argumente, sodass Sie\nbeispielsweise `bin/mydownloader subcommand -d` in der `plugin.yaml` angeben\nkönnen. Dies ist nützlich, wenn Sie dieselbe ausführbare Datei für den\nHaupt-Plugin-Befehl und den Downloader-Befehl verwenden möchten, aber mit einem\nunterschiedlichen Unterbefehl für jeden.\n\n## Umgebungsvariablen\n\nWenn Helm ein Plugin ausführt, übergibt es die äußere Umgebung an das Plugin\nund injiziert auch einige zusätzliche Umgebungsvariablen.\n\nVariablen wie `KUBECONFIG` werden für das Plugin gesetzt, wenn sie in der\näußeren Umgebung gesetzt sind.\n\nDie folgenden Variablen sind garantiert gesetzt:\n\n- `HELM_PLUGINS`: Der Pfad zum Plugins-Verzeichnis.\n- `HELM_PLUGIN_NAME`: Der Name des Plugins, wie von `helm` aufgerufen. So hat\n  `helm myplug` den Kurznamen `myplug`.\n- `HELM_PLUGIN_DIR`: Das Verzeichnis, das das Plugin enthält.\n- `HELM_BIN`: Der Pfad zum `helm`-Befehl (wie vom Benutzer ausgeführt).\n- `HELM_DEBUG`: Zeigt an, ob das Debug-Flag von Helm gesetzt wurde.\n- `HELM_REGISTRY_CONFIG`: Der Speicherort für die Registry-Konfiguration (falls\n  verwendet). Beachten Sie, dass die Verwendung von Helm mit Registries eine\n  experimentelle Funktion ist.\n- `HELM_REPOSITORY_CACHE`: Der Pfad zu den Repository-Cache-Dateien.\n- `HELM_REPOSITORY_CONFIG`: Der Pfad zur Repository-Konfigurationsdatei.\n- `HELM_NAMESPACE`: Der Namespace, der dem `helm`-Befehl übergeben wurde\n  (üblicherweise mit dem Flag `-n`).\n- `HELM_KUBECONTEXT`: Der Name des Kubernetes-Konfigurationskontexts, der dem\n  `helm`-Befehl übergeben wurde.\n\nZusätzlich wird, wenn eine Kubernetes-Konfigurationsdatei explizit angegeben wurde,\ndiese als Variable `KUBECONFIG` gesetzt.\n\n## Hinweis zur Flag-Verarbeitung\n\nBei der Ausführung eines Plugins analysiert Helm globale Flags für den eigenen\nGebrauch. Keines dieser Flags wird an das Plugin weitergegeben.\n- `--burst-limit`: Dies wird zu `$HELM_BURST_LIMIT` konvertiert\n- `--debug`: Wenn dies angegeben ist, wird `$HELM_DEBUG` auf `1` gesetzt\n- `--kube-apiserver`: Dies wird zu `$HELM_KUBEAPISERVER` konvertiert\n- `--kube-as-group`: Diese werden zu `$HELM_KUBEASGROUPS` konvertiert\n- `--kube-as-user`: Dies wird zu `$HELM_KUBEASUSER` konvertiert\n- `--kube-ca-file`: Dies wird zu `$HELM_KUBECAFILE` konvertiert\n- `--kube-context`: Dies wird zu `$HELM_KUBECONTEXT` konvertiert\n- `--kube-insecure-skip-tls-verify`: Dies wird zu `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` konvertiert\n- `--kube-tls-server-name`: Dies wird zu `$HELM_KUBETLS_SERVER_NAME` konvertiert\n- `--kube-token`: Dies wird zu `$HELM_KUBETOKEN` konvertiert\n- `--kubeconfig`: Dies wird zu `$KUBECONFIG` konvertiert\n- `--namespace` und `-n`: Dies wird zu `$HELM_NAMESPACE` konvertiert\n- `--qps`: Dies wird zu `$HELM_QPS` konvertiert\n- `--registry-config`: Dies wird zu `$HELM_REGISTRY_CONFIG` konvertiert\n- `--repository-cache`: Dies wird zu `$HELM_REPOSITORY_CACHE` konvertiert\n- `--repository-config`: Dies wird zu `$HELM_REPOSITORY_CONFIG` konvertiert\n\nPlugins _sollten_ Hilfetext anzeigen und dann beenden für `-h` und `--help`. In\nallen anderen Fällen können Plugins Flags nach Bedarf verwenden.\n\n## Shell-Autovervollständigung bereitstellen\n\nSeit Helm 3.2 kann ein Plugin optional Unterstützung für die Shell-Autovervollständigung\nals Teil des bestehenden Autovervollständigungsmechanismus von Helm bereitstellen.\n\n### Statische Autovervollständigung\n\nWenn ein Plugin eigene Flags und/oder Unterbefehle bereitstellt, kann es Helm\ndarüber informieren, indem eine `completion.yaml`-Datei im Stammverzeichnis des\nPlugins vorhanden ist. Die `completion.yaml`-Datei hat folgende Form:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nHinweise:\n\n1. Alle Abschnitte sind optional, sollten aber angegeben werden, wenn zutreffend.\n1. Flags sollten nicht das Präfix `-` oder `--` enthalten.\n1. Sowohl kurze als auch lange Flags können und sollten angegeben werden. Ein\n   kurzes Flag muss nicht mit seiner entsprechenden Langform verknüpft sein,\n   aber beide Formen sollten aufgelistet werden.\n1. Flags müssen nicht in einer bestimmten Reihenfolge sein, müssen aber an der\n   richtigen Stelle in der Unterbefehl-Hierarchie der Datei aufgelistet werden.\n1. Die bestehenden globalen Flags von Helm werden bereits vom Autovervollständigungsmechanismus\n   von Helm behandelt, daher müssen Plugins die folgenden Flags nicht angeben:\n   `--debug`, `--namespace` oder `-n`, `--kube-context` und `--kubeconfig`,\n   oder andere globale Flags.\n1. Die `validArgs`-Liste bietet eine statische Liste möglicher Vervollständigungen\n   für den ersten Parameter nach einem Unterbefehl. Es ist nicht immer möglich,\n   eine solche Liste im Voraus bereitzustellen (siehe Abschnitt [Dynamische\n   Vervollständigung](#dynamische-vervollständigung) unten), in diesem Fall kann\n   der `validArgs`-Abschnitt weggelassen werden.\n\nDie `completion.yaml`-Datei ist vollständig optional. Wenn sie nicht bereitgestellt\nwird, bietet Helm einfach keine Shell-Autovervollständigung für das Plugin (es sei\ndenn, das Plugin unterstützt [Dynamische Vervollständigung](#dynamische-vervollständigung)).\nDas Hinzufügen einer `completion.yaml`-Datei ist abwärtskompatibel und beeinflusst\ndas Verhalten des Plugins bei Verwendung älterer Helm-Versionen nicht.\n\nAls Beispiel hat das [`fullstatus\nPlugin`](https://github.com/marckhouzam/helm-fullstatus), das keine Unterbefehle\nhat, aber dieselben Flags wie der Befehl `helm status` akzeptiert, folgende\n`completion.yaml`-Datei:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nEin komplexeres Beispiel für das [`2to3\nPlugin`](https://github.com/helm/helm-2to3) hat folgende `completion.yaml`-Datei:\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### Dynamische Vervollständigung\n\nEbenfalls seit Helm 3.2 können Plugins ihre eigene dynamische Shell-Autovervollständigung\nbereitstellen. Dynamische Shell-Autovervollständigung ist die Vervollständigung von\nParameter- oder Flag-Werten, die nicht im Voraus definiert werden können. Zum\nBeispiel die Vervollständigung der Namen von Helm Releases, die derzeit im Cluster\nverfügbar sind.\n\nDamit das Plugin dynamische Autovervollständigung unterstützt, muss es eine\n**ausführbare** Datei namens `plugin.complete` in seinem Stammverzeichnis\nbereitstellen. Wenn das Helm-Vervollständigungsskript dynamische Vervollständigungen\nfür das Plugin benötigt, führt es die Datei `plugin.complete` aus und übergibt ihr\ndie Befehlszeile, die vervollständigt werden muss. Die ausführbare Datei\n`plugin.complete` muss die Logik enthalten, um zu bestimmen, welche die korrekten\nVervollständigungsoptionen sind, und diese auf die Standardausgabe ausgeben, damit\nsie vom Helm-Vervollständigungsskript verwendet werden können.\n\nDie Datei `plugin.complete` ist vollständig optional. Wenn sie nicht bereitgestellt\nwird, bietet Helm einfach keine dynamische Autovervollständigung für das Plugin.\nDas Hinzufügen einer `plugin.complete`-Datei ist abwärtskompatibel und beeinflusst\ndas Verhalten des Plugins bei Verwendung älterer Helm-Versionen nicht.\n\nDie Ausgabe des `plugin.complete`-Skripts sollte eine durch Zeilenumbrüche getrennte\nListe sein, wie:\n\n```console\nrel1\nrel2\nrel3\n```\n\nWenn `plugin.complete` aufgerufen wird, wird die Plugin-Umgebung genauso gesetzt\nwie beim Aufruf des Haupt-Skripts des Plugins. Daher sind die Variablen\n`$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` und alle anderen Plugin-Variablen bereits\ngesetzt, und ihre entsprechenden globalen Flags wurden entfernt.\n\nDie Datei `plugin.complete` kann in jeder ausführbaren Form vorliegen; es kann ein\nShell-Skript, ein Go-Programm oder jede andere Art von Programm sein, das Helm\nausführen kann. Die Datei `plugin.complete` ***muss*** ausführbare Berechtigungen\nfür den Benutzer haben. Die Datei `plugin.complete` ***muss*** mit einem Erfolgscode\n(Wert 0) beenden.\n\nIn einigen Fällen erfordert die dynamische Vervollständigung das Abrufen von\nInformationen aus dem Kubernetes-Cluster. Zum Beispiel erfordert das Plugin\n`helm fullstatus` einen Release-Namen als Eingabe. Im `fullstatus`-Plugin kann\nsein `plugin.complete`-Skript, um Vervollständigungen für aktuelle Release-Namen\nbereitzustellen, einfach `helm list -q` ausführen und das Ergebnis ausgeben.\n\nWenn es gewünscht ist, dieselbe ausführbare Datei für die Plugin-Ausführung und\nfür die Plugin-Vervollständigung zu verwenden, kann das `plugin.complete`-Skript\nso gestaltet werden, dass es die ausführbare Hauptdatei des Plugins mit einem\nspeziellen Parameter oder Flag aufruft. Wenn die ausführbare Hauptdatei des Plugins\nden speziellen Parameter oder das Flag erkennt, weiß sie, dass sie die Vervollständigung\nausführen soll. In unserem Beispiel könnte `plugin.complete` wie folgt implementiert\nwerden:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nDas eigentliche Skript des `fullstatus`-Plugins (`status.sh`) muss dann nach dem\nFlag `--complete` suchen und, wenn gefunden, die entsprechenden Vervollständigungen\nausgeben.\n\n### Tipps und Tricks\n\n1. Die Shell filtert automatisch Vervollständigungsoptionen heraus, die nicht mit\n   der Benutzereingabe übereinstimmen. Ein Plugin kann daher alle relevanten\n   Vervollständigungen zurückgeben, ohne diejenigen zu entfernen, die nicht mit\n   der Benutzereingabe übereinstimmen. Wenn die Befehlszeile beispielsweise\n   `helm fullstatus ngin<TAB>` ist, kann das `plugin.complete`-Skript *alle*\n   Release-Namen (des `default`-Namespace) ausgeben, nicht nur die, die mit `ngin`\n   beginnen; die Shell behält nur diejenigen, die mit `ngin` beginnen.\n1. Um die Unterstützung für dynamische Vervollständigung zu vereinfachen,\n   insbesondere bei einem komplexen Plugin, können Sie Ihr `plugin.complete`-Skript\n   Ihr Haupt-Plugin-Skript aufrufen lassen und Vervollständigungsoptionen anfordern.\n   Siehe den Abschnitt [Dynamische Vervollständigung](#dynamische-vervollständigung)\n   oben für ein Beispiel.\n1. Um die dynamische Vervollständigung und die `plugin.complete`-Datei zu debuggen,\n   können Sie Folgendes ausführen, um die Vervollständigungsergebnisse zu sehen:\n    - `helm __complete <pluginName> <arguments to complete>`. Zum Beispiel:\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: Helm-Provenienz und -Integrität\ndescription: Beschreibt, wie Sie die Integrität und Herkunft eines Charts überprüfen können.\nsidebar_position: 5\n---\n\nHelm verfügt über Provenienz-Werkzeuge, die Chart-Benutzern helfen, die Integrität und\nHerkunft eines Pakets zu überprüfen. Mithilfe von branchenüblichen Werkzeugen, die auf\nPKI, GnuPG und anerkannten Paketmanagern basieren, kann Helm Signaturdateien erstellen\nund verifizieren.\n\n## Überblick\n\nDie Integrität wird durch den Vergleich eines Charts mit einem Provenienz-Datensatz\nfestgestellt. Provenienz-Datensätze werden in _Provenienz-Dateien_ gespeichert, die\nzusammen mit einem gepackten Chart abgelegt werden. Wenn beispielsweise ein Chart\n`myapp-1.2.3.tgz` heißt, lautet seine Provenienz-Datei `myapp-1.2.3.tgz.prov`.\n\nProvenienz-Dateien werden beim Paketieren erstellt (`helm package --sign ...`) und\nkönnen von mehreren Befehlen geprüft werden, insbesondere `helm install --verify`.\n\n## Der Workflow\n\nDieser Abschnitt beschreibt einen möglichen Workflow für die effektive Nutzung von\nProvenienz-Daten.\n\nVoraussetzungen:\n\n- Ein gültiges PGP-Schlüsselpaar im Binärformat (nicht ASCII-armored)\n- Das Kommandozeilenwerkzeug `helm`\n- GnuPG-Kommandozeilenwerkzeuge (optional)\n- Keybase-Kommandozeilenwerkzeuge (optional)\n\n**Hinweis:** Falls Ihr privater PGP-Schlüssel ein Passwort hat, werden Sie bei allen\nBefehlen, die die Option `--sign` unterstützen, zur Eingabe dieses Passworts\naufgefordert.\n\nDas Erstellen eines neuen Charts funktioniert wie gewohnt:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nWenn Sie bereit zum Paketieren sind, fügen Sie das Flag `--sign` zu `helm package`\nhinzu. Geben Sie außerdem den Namen an, unter dem der Signaturschlüssel bekannt ist,\nsowie den Schlüsselring, der den entsprechenden privaten Schlüssel enthält:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**Hinweis:** Der Wert des Arguments `--key` muss ein Teilstring der `uid` des\ngewünschten Schlüssels sein (in der Ausgabe von `gpg --list-keys`), zum Beispiel\nder Name oder die E-Mail-Adresse.\n**Der Fingerprint _kann nicht_ verwendet werden.**\n\n**Tipp:** Für GnuPG-Benutzer befindet sich der geheime Schlüsselring in\n`~/.gnupg/secring.gpg`. Mit `gpg --list-secret-keys` können Sie Ihre verfügbaren\nSchlüssel auflisten.\n\n**Warnung:** GnuPG v2 speichert Ihren geheimen Schlüsselring in einem neuen Format\n`kbx` am Standardspeicherort `~/.gnupg/pubring.kbx`. Verwenden Sie bitte den\nfolgenden Befehl, um Ihren Schlüsselring in das alte gpg-Format zu konvertieren:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nAn diesem Punkt sollten Sie sowohl `mychart-0.1.0.tgz` als auch\n`mychart-0.1.0.tgz.prov` sehen. Beide Dateien sollten letztendlich in Ihr gewünschtes\nChart Repository hochgeladen werden.\n\nSie können ein Chart mit `helm verify` verifizieren:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nEine fehlgeschlagene Verifizierung sieht so aus:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nUm während der Installation zu verifizieren, verwenden Sie das Flag `--verify`.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nFalls sich der Schlüsselring mit dem öffentlichen Schlüssel, der zum signierten Chart\ngehört, nicht am Standardspeicherort befindet, müssen Sie möglicherweise mit\n`--keyring PATH` auf den Schlüsselring verweisen, wie im Beispiel `helm package`.\n\nWenn die Verifizierung fehlschlägt, wird die Installation abgebrochen, bevor das\nChart überhaupt gerendert wird.\n\n### Keybase.io-Anmeldedaten verwenden\n\nDer Dienst [Keybase.io](https://keybase.io) erleichtert das Aufbauen einer\nVertrauenskette für eine kryptografische Identität. Keybase-Anmeldedaten können zum\nSignieren von Charts verwendet werden.\n\nVoraussetzungen:\n\n- Ein konfiguriertes Keybase.io-Konto\n- GnuPG lokal installiert\n- Die `keybase`-CLI lokal installiert\n\n#### Pakete signieren\n\nDer erste Schritt besteht darin, Ihre Keybase-Schlüssel in Ihren lokalen\nGnuPG-Schlüsselring zu importieren:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nDies konvertiert Ihren Keybase-Schlüssel in das OpenPGP-Format und importiert ihn\ndann lokal in Ihre `~/.gnupg/secring.gpg`-Datei.\n\nSie können dies mit `gpg --list-secret-keys` überprüfen.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nBeachten Sie, dass Ihr geheimer Schlüssel eine Identifikationszeichenkette hat:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nDies ist der vollständige Name Ihres Schlüssels.\n\nAls Nächstes können Sie ein Chart mit `helm package` paketieren und signieren. Stellen\nSie sicher, dass Sie mindestens einen Teil dieser Namenszeichenkette in `--key`\nverwenden.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nAls Ergebnis sollte der `package`-Befehl sowohl eine `.tgz`-Datei als auch eine\n`.tgz.prov`-Datei erzeugen.\n\n#### Pakete verifizieren\n\nSie können eine ähnliche Technik verwenden, um ein Chart zu verifizieren, das mit dem\nKeybase-Schlüssel einer anderen Person signiert wurde. Angenommen, Sie möchten ein\nPaket verifizieren, das von `keybase.io/technosophos` signiert wurde. Verwenden Sie\ndazu das `keybase`-Werkzeug:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nDer erste Befehl oben folgt dem Benutzer `technosophos`. Dann lädt `keybase pgp pull`\ndie OpenPGP-Schlüssel aller Konten herunter, denen Sie folgen, und platziert sie in\nIhrem GnuPG-Schlüsselring (`~/.gnupg/pubring.gpg`).\n\nAn diesem Punkt können Sie nun `helm verify` oder jeden Befehl mit dem Flag `--verify`\nverwenden:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Gründe, warum ein Chart nicht verifiziert werden kann\n\nDies sind häufige Gründe für ein Fehlschlagen.\n\n- Die `.prov`-Datei fehlt oder ist beschädigt. Dies deutet darauf hin, dass etwas\n  falsch konfiguriert ist oder dass der ursprüngliche Maintainer keine Provenienz-Datei\n  erstellt hat.\n- Der Schlüssel, der zum Signieren der Datei verwendet wurde, befindet sich nicht in\n  Ihrem Schlüsselring. Dies deutet darauf hin, dass die Entität, die das Chart\n  signiert hat, keine Person ist, der Sie bereits Ihr Vertrauen signalisiert haben.\n- Die Verifizierung der `.prov`-Datei ist fehlgeschlagen. Dies deutet darauf hin, dass\n  entweder mit dem Chart oder den Provenienz-Daten etwas nicht stimmt.\n- Die Datei-Hashes in der Provenienz-Datei stimmen nicht mit dem Hash der Archivdatei\n  überein. Dies deutet darauf hin, dass das Archiv manipuliert wurde.\n\nWenn eine Verifizierung fehlschlägt, gibt es Grund, dem Paket zu misstrauen.\n\n## Die Provenienz-Datei\n\nDie Provenienz-Datei enthält die YAML-Datei eines Charts sowie mehrere\nVerifizierungsinformationen. Provenienz-Dateien sind so konzipiert, dass sie\nautomatisch generiert werden.\n\nDie folgenden Provenienz-Daten werden hinzugefügt:\n\n* Die Chart-Datei (`Chart.yaml`) wird einbezogen, um sowohl Menschen als auch\n  Werkzeugen einen einfachen Einblick in den Inhalt des Charts zu geben.\n* Die Signatur (SHA256, wie bei Docker) des Chart-Pakets (die `.tgz`-Datei) wird\n  einbezogen und kann zur Überprüfung der Integrität des Chart-Pakets verwendet werden.\n* Der gesamte Inhalt wird mit dem von OpenPGP verwendeten Algorithmus signiert (siehe\n  [Keybase.io](https://keybase.io) für einen aufkommenden Weg, kryptografisches\n  Signieren und Verifizieren zu vereinfachen).\n\nDiese Kombination gibt Benutzern die folgenden Zusicherungen:\n\n* Das Paket selbst wurde nicht manipuliert (Prüfsumme des `.tgz`-Pakets).\n* Die Entität, die dieses Paket veröffentlicht hat, ist bekannt (durch die\n  GnuPG/PGP-Signatur).\n\nDas Format der Datei sieht ungefähr so aus:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nBeachten Sie, dass der YAML-Abschnitt zwei Dokumente enthält (getrennt durch\n`...\\n`). Die erste Datei ist der Inhalt von `Chart.yaml`. Die zweite enthält\ndie Prüfsummen, eine Zuordnung von Dateinamen zu SHA-256-Digests des Dateiinhalts\nzum Zeitpunkt des Paketierens.\n\nDer Signaturblock ist eine standardmäßige PGP-Signatur, die\n[Manipulationsschutz](https://www.rossde.com/PGP/pgp_signatures.html) bietet.\n\n## Chart Repositories\n\nChart Repositories dienen als zentrale Sammlung von Helm-Charts.\n\nChart Repositories müssen es ermöglichen, Provenienz-Dateien über HTTP über eine\nbestimmte Anfrage bereitzustellen, und müssen sie unter demselben URI-Pfad wie das\nChart verfügbar machen.\n\nWenn beispielsweise die Basis-URL für ein Paket\n`https://example.com/charts/mychart-1.2.3.tgz` ist, MUSS die Provenienz-Datei,\nfalls vorhanden, unter\n`https://example.com/charts/mychart-1.2.3.tgz.prov` erreichbar sein.\n\nAus Sicht des Endbenutzers sollte `helm install --verify myrepo/mychart-1.2.3`\nzum Download sowohl des Charts als auch der Provenienz-Datei führen, ohne\nzusätzliche Benutzerkonfiguration oder -aktion.\n\n### Signaturen in OCI-basierten Registries\n\nBeim Veröffentlichen von Charts in einer [OCI-basierten Registry](/topics/registries.md)\nkann das [`helm-sigstore`-Plugin](https://github.com/sigstore/helm-sigstore/) verwendet\nwerden, um Provenienz in [sigstore](https://sigstore.dev/) zu veröffentlichen.\n[Wie in der Dokumentation beschrieben](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md),\nsind das Erstellen von Provenienz und das Signieren mit einem GPG-Schlüssel üblich,\naber der Befehl `helm sigstore upload` kann verwendet werden, um die Provenienz in\neinem unveränderlichen Transparenz-Log zu veröffentlichen.\n\n## Autorität und Authentizität etablieren\n\nBeim Umgang mit Vertrauensketten-Systemen ist es wichtig, die Autorität eines\nSignierenden feststellen zu können. Anders ausgedrückt: Das oben beschriebene\nSystem basiert darauf, dass Sie der Person vertrauen, die das Chart signiert hat.\nDas wiederum bedeutet, dass Sie dem öffentlichen Schlüssel des Signierenden\nvertrauen müssen.\n\nEine der Design-Entscheidungen bei Helm war, dass sich das Helm-Projekt nicht als\nnotwendige Partei in die Vertrauenskette einschalten würde. Wir wollen nicht die\n\"Zertifizierungsstelle\" für alle Chart-Signierer sein. Stattdessen bevorzugen wir\nstark ein dezentrales Modell, weshalb wir OpenPGP als unsere grundlegende\nTechnologie gewählt haben. Wenn es also darum geht, Autorität zu etablieren, haben\nwir diesen Schritt in Helm 2 mehr oder weniger undefiniert gelassen (eine\nEntscheidung, die in Helm 3 beibehalten wurde).\n\nDennoch haben wir einige Hinweise und Empfehlungen für diejenigen, die das\nProvenienz-System nutzen möchten:\n\n- Die [Keybase](https://keybase.io)-Plattform bietet ein öffentliches,\n  zentralisiertes Repository für Vertrauensinformationen.\n  - Sie können Keybase verwenden, um Ihre Schlüssel zu speichern oder die\n    öffentlichen Schlüssel anderer zu erhalten.\n  - Keybase bietet auch hervorragende Dokumentation.\n  - Obwohl wir es nicht getestet haben, könnte die \"sichere Website\"-Funktion\n    von Keybase verwendet werden, um Helm-Charts bereitzustellen.\n  - Die Grundidee ist, dass ein offizieller \"Chart-Reviewer\" Charts mit seinem\n    Schlüssel signiert und die resultierende Provenienz-Datei dann in das Chart\n    Repository hochgeladen wird.\n  - Es wurde an der Idee gearbeitet, dass eine Liste gültiger Signaturschlüssel\n    in der `index.yaml`-Datei eines Repositorys enthalten sein könnte.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: Rollenbasierte Zugriffskontrolle\ndescription: Erläutert, wie Helm mit der rollenbasierten Zugriffskontrolle (RBAC) von Kubernetes interagiert.\nsidebar_position: 11\n---\n\nIn Kubernetes ist es eine Best Practice, Benutzern oder anwendungsspezifischen\nServiceAccounts Rollen zuzuweisen, um sicherzustellen, dass Ihre Anwendung nur\ninnerhalb des vorgesehenen Geltungsbereichs agiert. Weitere Informationen zu\nServiceAccount-Berechtigungen finden Sie in der [offiziellen Kubernetes-Dokumentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nSeit Kubernetes 1.6 ist die rollenbasierte Zugriffskontrolle (RBAC) standardmäßig\naktiviert. Mit RBAC können Sie festlegen, welche Aktionstypen je nach Benutzer und\ndessen Rolle in Ihrer Organisation erlaubt sind.\n\nMit RBAC können Sie:\n\n- Administratoren privilegierte Operationen gewähren (z. B. das Erstellen\n  clusterweiter Ressourcen wie neue Roles)\n- die Fähigkeit eines Benutzers einschränken, Ressourcen (Pods, Persistent Volumes,\n  Deployments) entweder in bestimmten Namespaces oder clusterweit zu erstellen\n  (Resource Quotas, Roles, Custom Resource Definitions)\n- die Fähigkeit eines Benutzers einschränken, Ressourcen entweder in bestimmten\n  Namespaces oder clusterweit einzusehen.\n\nDieser Leitfaden richtet sich an Administratoren, die den Zugriff eines Benutzers\nauf die Kubernetes-API einschränken möchten.\n\n## Benutzerkonten verwalten\n\nAlle Kubernetes-Cluster haben zwei Kategorien von Benutzern: von Kubernetes\nverwaltete ServiceAccounts und normale Benutzer.\n\nNormale Benutzer werden von einem externen, unabhängigen Dienst verwaltet. Ein\nAdministrator kann private Schlüssel verteilen, einen Benutzerspeicher wie Keystone\noder Google Accounts verwenden, oder sogar eine Datei mit Benutzernamen und\nPasswörtern nutzen. Kubernetes verfügt nicht über Objekte, die normale\nBenutzerkonten repräsentieren. Normale Benutzer können nicht über einen API-Aufruf\nzum Cluster hinzugefügt werden.\n\nIm Gegensatz dazu werden ServiceAccounts von der Kubernetes-API verwaltet. Sie sind\nan bestimmte Namespaces gebunden und werden entweder automatisch vom API-Server oder\nmanuell durch API-Aufrufe erstellt. ServiceAccounts sind mit Anmeldeinformationen\nverknüpft, die als Secrets gespeichert und in Pods gemountet werden. Dadurch können\nProzesse innerhalb des Clusters mit der Kubernetes-API kommunizieren.\n\nAPI-Anfragen werden entweder einem normalen Benutzer oder einem ServiceAccount\nzugeordnet, oder sie werden als anonyme Anfragen behandelt. Das bedeutet, dass\njeder Prozess innerhalb oder außerhalb des Clusters – ob ein Benutzer, der `kubectl`\nauf einer Workstation eingibt, Kubelets auf Nodes oder Mitglieder der Control Plane –\nsich beim API-Server authentifizieren muss oder als anonymer Benutzer behandelt wird.\n\n## Roles, ClusterRoles, RoleBindings und ClusterRoleBindings\n\nIn Kubernetes können Benutzerkonten und ServiceAccounts nur Ressourcen einsehen und\nbearbeiten, für die ihnen Zugriff gewährt wurde. Dieser Zugriff wird durch Roles und\nRoleBindings gewährt. Roles und RoleBindings sind an einen bestimmten Namespace\ngebunden und gewähren Benutzern die Fähigkeit, Ressourcen innerhalb dieses Namespace\neinzusehen und/oder zu bearbeiten.\n\nAuf Clusterebene heißen diese ClusterRoles und ClusterRoleBindings. Wenn Sie einem\nBenutzer eine ClusterRole zuweisen, gewähren Sie ihm Zugriff auf das Einsehen\nund/oder Bearbeiten von Ressourcen im gesamten Cluster. Dies ist auch erforderlich,\num Ressourcen auf Clusterebene (Namespaces, Resource Quotas, Nodes) einzusehen\nund/oder zu bearbeiten.\n\nClusterRoles können über eine Referenz in einem RoleBinding an einen bestimmten\nNamespace gebunden werden. Die Standard-ClusterRoles `admin`, `edit` und `view`\nwerden häufig auf diese Weise verwendet.\n\nEs gibt einige ClusterRoles, die standardmäßig in Kubernetes verfügbar sind. Sie\nsind für Endbenutzer gedacht und umfassen Super-User-Rollen (`cluster-admin`) sowie\nRollen mit granularerem Zugriff (`admin`, `edit`, `view`).\n\n| Standard-ClusterRole | Standard-ClusterRoleBinding | Beschreibung\n|----------------------|-----------------------------|--------------\n| `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.\n| `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.\n| `edit`               | Keine                       | Erlaubt Lese-/Schreibzugriff auf die meisten Objekte in einem Namespace. Sie erlaubt nicht das Einsehen oder Bearbeiten von Roles oder RoleBindings.\n| `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.\n\n## Den Zugriff eines Benutzerkontos mit RBAC einschränken\n\nNachdem wir die Grundlagen der rollenbasierten Zugriffskontrolle verstanden haben,\nbesprechen wir nun, wie ein Administrator den Zugriffsbereich eines Benutzers\neinschränken kann.\n\n### Beispiel: Einem Benutzer Lese-/Schreibzugriff auf einen bestimmten Namespace gewähren\n\nUm den Zugriff eines Benutzers auf einen bestimmten Namespace einzuschränken, können\nSie entweder die Role `edit` oder `admin` verwenden. Wenn Ihre Charts Roles und\nRoleBindings erstellen oder damit interagieren, sollten Sie die ClusterRole `admin`\nverwenden.\n\nZusätzlich können Sie auch ein RoleBinding mit `cluster-admin`-Zugriff erstellen.\nDie Gewährung von `cluster-admin`-Zugriff auf Namespace-Ebene gibt dem Benutzer\nvolle Kontrolle über jede Ressource im Namespace, einschließlich des Namespace\nselbst.\n\nFür dieses Beispiel erstellen wir einen Benutzer mit der Role `edit`. Erstellen\nSie zunächst den Namespace:\n\n```console\n$ kubectl create namespace foo\n```\n\nErstellen Sie nun ein RoleBinding in diesem Namespace, das dem Benutzer die Role\n`edit` zuweist.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Beispiel: Einem Benutzer Lese-/Schreibzugriff auf Clusterebene gewähren\n\nWenn ein Benutzer ein Chart installieren möchte, das clusterweite Ressourcen\ninstalliert (Namespaces, Roles, Custom Resource Definitions usw.), benötigt er\nclusterweiten Schreibzugriff.\n\nGewähren Sie dem Benutzer dafür entweder `admin`- oder `cluster-admin`-Zugriff.\n\nDie Gewährung von `cluster-admin`-Zugriff gibt dem Benutzer Zugriff auf absolut\njede in Kubernetes verfügbare Ressource, einschließlich Node-Zugriff mit `kubectl\ndrain` und anderen administrativen Aufgaben. Es wird dringend empfohlen, dem\nBenutzer stattdessen `admin`-Zugriff zu gewähren oder eine benutzerdefinierte\nClusterRole zu erstellen, die auf seine Bedürfnisse zugeschnitten ist.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Beispiel: Einem Benutzer schreibgeschützten Zugriff auf einen bestimmten Namespace gewähren\n\nSie haben vielleicht bemerkt, dass es keine ClusterRole zum Einsehen von Secrets\ngibt. Die ClusterRole `view` gewährt Benutzern aufgrund von Bedenken bezüglich\nRechteausweitung keinen Lesezugriff auf Secrets. Helm speichert Release-Metadaten\nstandardmäßig als Secrets.\n\nDamit ein Benutzer `helm list` ausführen kann, muss er diese Secrets lesen können.\nDafür erstellen wir eine spezielle ClusterRole `secret-reader`.\n\nErstellen Sie die Datei `cluster-role-secret-reader.yaml` mit folgendem Inhalt:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nErstellen Sie dann die ClusterRole mit:\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nSobald dies erledigt ist, können wir einem Benutzer Lesezugriff auf die meisten\nRessourcen gewähren und ihm dann Lesezugriff auf Secrets geben:\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Beispiel: Einem Benutzer schreibgeschützten Zugriff auf Clusterebene gewähren\n\nIn bestimmten Szenarien kann es vorteilhaft sein, einem Benutzer clusterweiten\nZugriff zu gewähren. Beispielsweise erfordert die API, dass der Benutzer\nclusterweiten Lesezugriff hat, wenn er den Befehl `helm list --all-namespaces`\nausführen möchte.\n\nGewähren Sie dem Benutzer dafür sowohl `view`- als auch `secret-reader`-Zugriff\nwie oben beschrieben, aber mit einem ClusterRoleBinding.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Weitere Überlegungen\n\nDie oben gezeigten Beispiele verwenden die Standard-ClusterRoles, die mit\nKubernetes bereitgestellt werden. Für eine feinere Kontrolle darüber, auf welche\nRessourcen Benutzer Zugriff erhalten, lesen Sie die [Kubernetes-Dokumentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) zum Erstellen\neigener benutzerdefinierter Roles und ClusterRoles.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: OCI-basierte Registries verwenden\ndescription: Beschreibt die Verwendung von OCI für die Chart-Verteilung.\nsidebar_position: 7\n---\n\nSeit 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.\n\n\n## OCI-Unterstützung vor v3.8.0\n\nDie 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.\n\n### Aktivierung der OCI-Unterstützung vor v3.8.0\n\nVor Helm v3.8.0 ist die OCI-Unterstützung *experimentell* und muss aktiviert werden.\n\nUm 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:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### Veraltete OCI-Funktionen und Verhaltensänderungen mit v3.8.0\n\nMit 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:\n\n- Wenn ein Chart in den Abhängigkeiten als OCI gesetzt wird, kann die Version wie bei anderen Abhängigkeiten als Bereich angegeben werden.\n- 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 `_`.\n- 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.\n\n### Veraltete OCI-Funktionen und Verhaltensänderungen mit v3.7.0\n\nMit 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:\n\n- Der Unterbefehl `helm chart` wurde entfernt.\n- Der Chart-Cache wurde entfernt (kein `helm chart list` usw.).\n- OCI-Registry-Referenzen werden jetzt immer mit `oci://` präfixiert.\n- Der Basisname der Registry-Referenz muss *immer* mit dem Namen des Charts übereinstimmen.\n- Das Tag der Registry-Referenz muss *immer* mit der semantischen Version des Charts übereinstimmen (d.h. keine `latest`-Tags).\n- Der Medientyp der Chart-Schicht wurde von `application/tar+gzip` auf `application/vnd.cncf.helm.chart.content.v1.tar+gzip` geändert.\n\n\n## Verwendung einer OCI-basierten Registry\n\n### Helm-Repositories in OCI-basierten Registries\n\nEin [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.\n\n### Gehostete Registries verwenden\n\nEs 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:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\nFolgen Sie der Dokumentation Ihres Container-Registry-Anbieters, um eine Registry mit OCI-Unterstützung zu erstellen und zu konfigurieren.\n\n**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.\n\n### Sigstore zum Signieren von OCI-basierten Charts verwenden\n\nDas [`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.\n\nWeitere Informationen zur Verwendung des `helm sigstore`-Plugins finden Sie in der [Dokumentation dieses Projekts](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md).\n\n## Befehle für die Arbeit mit Registries\n\n### Der Unterbefehl `registry`\n\n#### `login`\n\nBei einer Registry anmelden (mit manueller Passworteingabe)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nVon einer Registry abmelden\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### Der Unterbefehl `push`\n\nEin Chart in eine OCI-basierte Registry hochladen:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nDer Unterbefehl `push` kann nur für `.tgz`-Dateien verwendet werden, die zuvor mit `helm package` erstellt wurden.\n\nWenn 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.\n\nDer 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.\n\nBestimmte 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.\n\nWenn 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).\n\nBenutzer 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.\n\n### Weitere Unterbefehle\n\nDie Unterstützung für das `oci://`-Protokoll ist auch in verschiedenen anderen Unterbefehlen verfügbar. Hier ist eine vollständige Liste:\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nDer 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).\n\nHier sind einige Beispiele für die Verwendung der oben aufgeführten Unterbefehle mit OCI-basierten Charts:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Charts mit Digest installieren\n\nDas 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:\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## Abhängigkeiten angeben\n\nAbhängigkeiten eines Charts können mit dem Unterbefehl `dependency update` aus einer Registry geholt werden.\n\nDas `repository` für einen Eintrag in `Chart.yaml` wird als Registry-Referenz ohne den Basisnamen angegeben:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\nDies ruft `oci://localhost:5000/myrepo/mychart:2.7.0` ab, wenn `dependency update` ausgeführt wird.\n\n## Helm-Chart-Manifest\n\nBeispiel eines Helm-Chart-Manifests, wie es in einer Registry dargestellt wird (beachten Sie die `mediaType`-Felder):\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nDas folgende Beispiel enthält eine [Provenance-Datei](/topics/provenance.md) (beachten Sie die zusätzliche Schicht):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Migration von Chart-Repos\n\nDie 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.\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: Migration von Helm v2 auf v3\ndescription: Erfahren Sie, wie Sie Helm v2 auf v3 migrieren.\nsidebar_position: 13\n---\n\nDiese Anleitung zeigt, wie Sie Helm v2 auf v3 migrieren. Helm v2 muss installiert sein\nund Releases in einem oder mehreren Clustern verwalten.\n\n## Übersicht der Änderungen in Helm 3\n\nDie vollständige Liste der Änderungen von Helm 2 auf 3 ist im Abschnitt\n[FAQ](/faq/changes_since_helm2.md) dokumentiert. Im Folgenden finden Sie eine\nZusammenfassung einiger Änderungen, die ein Benutzer vor und während der Migration\nbeachten sollte:\n\n1. Entfernung von Tiller:\n   - Die Client/Server-Architektur wird durch eine Client/Library-Architektur ersetzt\n     (nur noch das `helm`-Binary)\n   - Sicherheit basiert nun auf Benutzerbasis (delegiert an die Kubernetes-\n     Cluster-Sicherheit)\n   - Releases werden jetzt als In-Cluster-Secrets gespeichert und die Metadaten des\n     Release-Objekts haben sich geändert\n   - Releases werden pro Release-Namespace persistiert und nicht mehr im\n     Tiller-Namespace\n2. Aktualisiertes Chart-Repository:\n   - `helm search` unterstützt jetzt sowohl lokale Repository-Suchen als auch\n     Suchanfragen an Artifact Hub\n3. Chart apiVersion auf \"v2\" angehoben für folgende Spezifikationsänderungen:\n   - Dynamisch verknüpfte Chart-Abhängigkeiten wurden nach `Chart.yaml` verschoben\n     (`requirements.yaml` entfernt und requirements --> dependencies)\n   - Library-Charts (Hilfs-/Common-Charts) können jetzt als dynamisch verknüpfte\n     Chart-Abhängigkeiten hinzugefügt werden\n   - Charts haben ein `type`-Metadatenfeld, das definiert, ob das Chart ein\n     `application`- oder `library`-Chart ist. Standardmäßig ist es application,\n     was bedeutet, dass es renderbar und installierbar ist\n   - Helm 2-Charts (apiVersion=v1) sind weiterhin installierbar\n4. XDG-Verzeichnisspezifikation hinzugefügt:\n   - Helm home wurde entfernt und durch die XDG-Verzeichnisspezifikation zum Speichern\n     von Konfigurationsdateien ersetzt\n   - Helm muss nicht mehr initialisiert werden\n   - `helm init` und `helm home` wurden entfernt\n5. Weitere Änderungen:\n   - Die Installation/Einrichtung von Helm wurde vereinfacht:\n     - Nur noch Helm-Client (helm-Binary) (kein Tiller)\n     - Sofort einsatzbereit\n   - `local`- oder `stable`-Repositories werden standardmäßig nicht eingerichtet\n   - Der `crd-install`-Hook wurde entfernt und durch das `crds`-Verzeichnis im Chart\n     ersetzt, in dem alle CRDs definiert werden, die vor dem Rendern des Charts\n     installiert werden\n   - Der Hook-Annotationswert `test-failure` wurde entfernt, und `test-success` ist\n     veraltet. Verwenden Sie stattdessen `test`\n   - Entfernte/ersetzte/hinzugefügte Befehle:\n       - delete --> uninstall: Entfernt standardmäßig die gesamte Release-Historie\n         (früher war `--purge` erforderlich)\n       - fetch --> pull\n       - home (entfernt)\n       - init (entfernt)\n       - install: Erfordert einen Release-Namen oder das Argument `--generate-name`\n       - inspect --> show\n       - reset (entfernt)\n       - serve (entfernt)\n       - template: Das Argument `-x`/`--execute` wurde in `-s`/`--show-only` umbenannt\n       - upgrade: Das Argument `--history-max` wurde hinzugefügt, das die maximale\n         Anzahl der gespeicherten Revisionen pro Release begrenzt (0 für kein Limit)\n   - Die Helm 3-Go-Bibliothek hat viele Änderungen durchlaufen und ist nicht mit der\n     Helm 2-Bibliothek kompatibel\n   - Release-Binaries werden jetzt auf `get.helm.sh` gehostet\n\n## Anwendungsfälle für die Migration\n\nEs gibt folgende Anwendungsfälle:\n\n1. Helm v2 und v3 verwalten denselben Cluster:\n   - Dieser Anwendungsfall wird nur empfohlen, wenn Sie beabsichtigen, Helm v2\n     schrittweise auslaufen zu lassen und v3 keine von v2 bereitgestellten Releases\n     verwalten soll. Alle neuen Releases sollten von v3 bereitgestellt werden, und\n     bestehende, von v2 bereitgestellte Releases sollten nur von v2 aktualisiert/\n     entfernt werden\n   - Helm v2 und v3 können problemlos denselben Cluster verwalten. Die Helm-Versionen\n     können auf demselben oder auf separaten Systemen installiert werden\n   - Wenn Sie Helm v3 auf demselben System installieren, müssen Sie einen zusätzlichen\n     Schritt durchführen, um sicherzustellen, dass beide Client-Versionen koexistieren\n     können, bis Sie bereit sind, den Helm v2-Client zu entfernen. Benennen Sie das\n     Helm v3-Binary um oder legen Sie es in einem anderen Ordner ab, um Konflikte zu\n     vermeiden\n   - Andernfalls gibt es keine Konflikte zwischen beiden Versionen aufgrund der\n     folgenden Unterschiede:\n     - Die Release-(Historie-)Speicherung von v2 und v3 ist voneinander unabhängig.\n       Die Änderungen umfassen die Kubernetes-Ressource für die Speicherung und die\n       Release-Objekt-Metadaten in der Ressource. Releases werden auch pro\n       Benutzer-Namespace gespeichert und nicht mehr im Tiller-Namespace (z.B. war der\n       Standard-Tiller-Namespace in v2 kube-system). v2 verwendet \"ConfigMaps\" oder\n       \"Secrets\" im Tiller-Namespace mit `TILLER`-Ownership. v3 verwendet \"Secrets\"\n       im Benutzer-Namespace mit `helm`-Ownership. Releases sind sowohl in v2 als auch\n       in v3 inkrementell\n     - Das einzige Problem könnte auftreten, wenn clusterweite Kubernetes-Ressourcen\n       (z.B. `clusterroles.rbac`) in einem Chart definiert sind. Das v3-Deployment\n       würde dann fehlschlagen, selbst wenn es im Namespace eindeutig ist, da die\n       Ressourcen kollidieren würden\n     - Die v3-Konfiguration verwendet nicht mehr `$HELM_HOME` und nutzt stattdessen\n       die XDG-Verzeichnisspezifikation. Sie wird auch bei Bedarf automatisch erstellt.\n       Sie ist daher unabhängig von der v2-Konfiguration. Dies gilt nur, wenn beide\n       Versionen auf demselben System installiert sind\n\n2. Migration von Helm v2 auf Helm v3:\n   - Dieser Anwendungsfall gilt, wenn Sie möchten, dass Helm v3 bestehende Helm v2-\n     Releases verwaltet\n   - Beachten Sie, dass ein Helm v2-Client:\n     - 1 bis viele Kubernetes-Cluster verwalten kann\n     - sich mit 1 bis vielen Tiller-Instanzen pro Cluster verbinden kann\n   - Das bedeutet, dass Sie dies bei der Migration berücksichtigen müssen, da Releases\n     von Tiller und dessen Namespace in Cluster bereitgestellt werden. Sie müssen daher\n     die Migration für jeden Cluster und jede Tiller-Instanz berücksichtigen, die von\n     der Helm v2-Client-Instanz verwaltet wird\n   - Der empfohlene Migrationspfad für Daten ist wie folgt:\n     1. v2-Daten sichern\n     2. Helm v2-Konfiguration migrieren\n     3. Helm v2-Releases migrieren\n     4. Wenn Sie sicher sind, dass Helm v3 alle Helm v2-Daten (für alle Cluster und\n        Tiller-Instanzen der Helm v2-Client-Instanz) wie erwartet verwaltet, können Sie\n        die Helm v2-Daten bereinigen\n   - Der Migrationsprozess wird durch das Helm v3-Plugin\n     [2to3](https://github.com/helm/helm-2to3) automatisiert\n\n## Referenzen\n\n- Helm v3 [2to3](https://github.com/helm/helm-2to3) Plugin\n- [Blogbeitrag](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/), der die\n  Verwendung des `2to3`-Plugins mit Beispielen erklärt\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Helm Versionsunterstützung\"\ndescription: \"Beschreibt die Patch-Release-Richtlinie von Helm sowie die maximal unterstützte Versionsabweichung zwischen Helm und Kubernetes.\"\n---\n\nDieses Dokument beschreibt die maximal unterstützte Versionsabweichung zwischen Helm und\nKubernetes.\n\n## Unterstützte Versionen\n\nHelm-Versionen werden als `x.y.z` ausgedrückt, wobei `x` die Hauptversion, `y` die\nNebenversion und `z` die Patch-Version ist. Dies entspricht der [Semantischen\nVersionierung](https://semver.org/spec/v2.0.0.html).\n\nDas Helm-Projekt pflegt einen Release-Branch für die jeweils aktuellste Nebenversion.\nRelevante Korrekturen, einschließlich Sicherheitskorrekturen, werden je nach Schweregrad\nund Machbarkeit in den Release-Branch übernommen. Weitere Details finden Sie in\n[Helms Release-Richtlinie](/community/release_policy).\n\n## Unterstützte Versionsabweichung\n\nJede neue Helm-Version wird gegen eine bestimmte Nebenversion von Kubernetes kompiliert.\nHelm 3.0.0 verwendet beispielsweise den Kubernetes 1.16.2 Client und ist daher mit\nKubernetes 1.16 kompatibel.\n\nAb Helm 3 gilt die Kompatibilität mit `n-3` Versionen von Kubernetes, gegen die Helm\nkompiliert wurde. Bei Helm 2 ist die Unterstützungsrichtlinie aufgrund der Änderungen\nzwischen Kubernetes-Nebenversionen strenger: hier gilt die Kompatibilität mit `n-1`\nVersionen.\n\nWenn Sie beispielsweise eine Version von Helm 3 verwenden, die gegen die Kubernetes 1.17\nClient-APIs kompiliert wurde, können Sie diese sicher mit Kubernetes 1.17, 1.16, 1.15\nund 1.14 verwenden. Bei einer Version von Helm 2, die gegen die Kubernetes 1.16\nClient-APIs kompiliert wurde, ist die Verwendung mit Kubernetes 1.16 und 1.15 sicher.\n\nEs wird nicht empfohlen, Helm mit einer neueren Kubernetes-Version zu verwenden als der,\ngegen die es kompiliert wurde. Helm gibt keine Vorwärtskompatibilitätsgarantien.\n\nWenn Sie Helm mit einer nicht unterstützten Kubernetes-Version verwenden, tun Sie dies\nauf eigenes Risiko.\n\nIn der folgenden Tabelle sehen Sie, welche Helm-Version mit Ihrem Cluster kompatibel ist.\n\n| Helm-Version | Unterstützte Kubernetes-Versionen |\n|--------------|-----------------------------------|\n| 3.20.x       | 1.35.x - 1.32.x                   |\n| 3.19.x       | 1.34.x - 1.31.x                   |\n| 3.18.x       | 1.33.x - 1.30.x                   |\n| 3.17.x       | 1.32.x - 1.29.x                   |\n| 3.16.x       | 1.31.x - 1.28.x                   |\n| 3.15.x       | 1.30.x - 1.27.x                   |\n| 3.14.x       | 1.29.x - 1.26.x                   |\n| 3.13.x       | 1.28.x - 1.25.x                   |\n| 3.12.x       | 1.27.x - 1.24.x                   |\n| 3.11.x       | 1.26.x - 1.23.x                   |\n| 3.10.x       | 1.25.x - 1.22.x                   |\n| 3.9.x        | 1.24.x - 1.21.x                   |\n| 3.8.x        | 1.23.x - 1.20.x                   |\n| 3.7.x        | 1.22.x - 1.19.x                   |\n| 3.6.x        | 1.21.x - 1.18.x                   |\n| 3.5.x        | 1.20.x - 1.17.x                   |\n| 3.4.x        | 1.19.x - 1.16.x                   |\n| 3.3.x        | 1.18.x - 1.15.x                   |\n| 3.2.x        | 1.18.x - 1.15.x                   |\n| 3.1.x        | 1.17.x - 1.14.x                   |\n| 3.0.x        | 1.16.x - 1.13.x                   |\n| 2.16.x       | 1.16.x - 1.15.x                   |\n| 2.15.x       | 1.15.x - 1.14.x                   |\n| 2.14.x       | 1.14.x - 1.13.x                   |\n| 2.13.x       | 1.13.x - 1.12.x                   |\n| 2.12.x       | 1.12.x - 1.11.x                   |\n| 2.11.x       | 1.11.x - 1.10.x                   |\n| 2.10.x       | 1.10.x - 1.9.x                    |\n| 2.9.x        | 1.10.x - 1.9.x                    |\n| 2.8.x        | 1.9.x - 1.8.x                     |\n| 2.7.x        | 1.8.x - 1.7.x                     |\n| 2.6.x        | 1.7.x - 1.6.x                     |\n| 2.5.x        | 1.6.x - 1.5.x                     |\n| 2.4.x        | 1.6.x - 1.5.x                     |\n| 2.3.x        | 1.5.x - 1.4.x                     |\n| 2.2.x        | 1.5.x - 1.4.x                     |\n| 2.1.x        | 1.5.x - 1.4.x                     |\n| 2.0.x        | 1.4.x - 1.3.x                     |\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"Einführung\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"Anleitungen\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"Themen\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Bewährte Praktiken\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"Chart Template Guide\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Helm-Befehle\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"Gemeinschaft\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"Häufig gestellte Fragen\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/de/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: \"Release-Zeitplan-Richtlinie\"\ndescription: \"Beschreibt Helms Release-Zeitplan-Richtlinie.\"\n---\n\nHelm gibt Veröffentlichungstermine im Voraus bekannt, damit Anwender besser planen\nkönnen. Dieses Dokument beschreibt die Richtlinie für Helms Release-Zeitplan.\n\n## Release-Kalender\n\nEin öffentlicher Kalender mit den anstehenden Helm-Releases ist [hier](https://helm.sh/calendar/release) verfügbar.\n\n## Semantische Versionierung\n\nHelm-Versionen werden als `x.y.z` ausgedrückt, wobei `x` die Hauptversion, `y` die\nNebenversion und `z` die Patch-Version ist. Dies entspricht der Terminologie der\n[Semantischen Versionierung](https://semver.org/spec/v2.0.0.html).\n\n## Patch-Releases\n\nPatch-Releases bieten Benutzern Fehlerbehebungen und Sicherheitskorrekturen. Sie\nenthalten keine neuen Funktionen.\n\nEin neues Patch-Release für die aktuelle Neben-/Hauptversion wird normalerweise\neinmal im Monat am zweiten Mittwoch jedes Monats veröffentlicht.\n\nEin Patch-Release zur Behebung einer kritischen Regression oder eines\nSicherheitsproblems kann jederzeit bei Bedarf erfolgen.\n\nEin Patch-Release wird aus einem der folgenden Gründe abgesagt:\n- wenn seit dem letzten Release kein neuer Inhalt hinzugekommen ist\n- wenn das Patch-Release-Datum innerhalb einer Woche vor dem ersten Release Candidate (RC1) einer anstehenden Nebenversion liegt\n- wenn das Patch-Release-Datum innerhalb von vier Wochen nach einer Nebenversion liegt\n\n## Nebenversionen\n\nNebenversionen enthalten Sicherheits- und Fehlerbehebungen sowie neue Funktionen.\nSie sind rückwärtskompatibel in Bezug auf die API und die CLI-Nutzung.\n\nUm sich mit Kubernetes-Releases abzustimmen, wird eine Helm-Nebenversion alle\n4 Monate veröffentlicht (3 Releases pro Jahr).\n\nZusätzliche Nebenversionen können bei Bedarf veröffentlicht werden, beeinflussen\naber nicht den Zeitplan eines angekündigten zukünftigen Releases, es sei denn,\ndas angekündigte Release liegt weniger als 7 Tage entfernt.\n\nGleichzeitig mit der Veröffentlichung eines Releases wird das Datum der nächsten\nNebenversion angekündigt und auf Helms Hauptwebseite veröffentlicht.\n\n## Hauptversionen\n\nHauptversionen enthalten Breaking Changes. Solche Releases sind selten, aber\nmanchmal notwendig, damit sich Helm in wichtigen neuen Richtungen weiterentwickeln\nkann.\n\nHauptversionen können schwierig zu planen sein. Daher wird ein finales\nVeröffentlichungsdatum erst gewählt und angekündigt, wenn die erste Beta-Version\neines solchen Releases verfügbar ist.\n"
  },
  {
    "path": "i18n/de/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Helm-Projekt\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"Entwicklung\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"Gemeinschaft\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"Quellcode\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"Veranstaltungen\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"Verhaltenskodex\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"Einführung\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Chart-Tipps und -Tricks\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"Charts entwickeln\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"800+ Charts durchsuchen\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"Beitragsleitfaden\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"Betreuer\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"Wöchentliche Treffen\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"GitHub-Gemeinschaft\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<a href=\\\"https://www.cncf.io/\\\">Wir sind ein promoviertes Projekt der Cloud Native Computing Foundation.</a><br/>© Helm-Autoren 2025. Dokumentation verteilt unter <a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0.</a><br/>© 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 <a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">Seite zur Markennutzung</a>.\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"CNCF-Logo\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/de/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Helm-Logo\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"Dokumentation\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"Gemeinschaft\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/el/code.json",
    "content": "{\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"Επόμενο Feature Release\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"Έκδοση:\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"Ημερομηνία:\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"Ημερολόγιο Εκδόσεων\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"Επερχόμενα Events\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"Επερχόμενα Events\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"Παλιά Events\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"{meetLink} για επίδειξη και συζήτηση εργαλείων και έργων. Οι συναντήσεις της κοινότητας καταγράφονται και {youtubeLink}.\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"Συναντιούνται κάθε εβδομάδα\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"κοινοποιούνται στο YouTube\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"Συναντήσεις Προγραμματιστών\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"Πέμπτες 9:30-10πμ (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"Αυτές οι συναντήσεις είναι ανοιχτές σε όλους. Ελέγξτε το {communityRepoLink} για σημειώσεις και λεπτομέρειες.\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"αποθετήριο της κοινότητας\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Συζήτηση σχετικά με τη χρήση του Helm, την εργασία με charts και την επίλυση συνηθισμένων σφαλμάτων.\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Θέματα σχετικά με την ανάπτυξη του Helm, τρέχοντα PRs, εκδόσεις κ.λπ.\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Συζήτηση για χρήστες και συνεισφέροντες στα Helm Charts.\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"{slackLink} για να συμμετάσχετε στην ομάδα Slack του Kubernetes.\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"Ζητήστε πρόσβαση εδώ\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"Συνεισφορά\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"Το Helm καλωσορίζει πάντα νέες συνεισφορές στο έργο!\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"Από πού να ξεκινήσω;\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Το Helm είναι ένα μεγάλο project με πολλούς χρήστες και contributors. Έχεις πολλά να μάθεις!\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"Έχουμε μια λίστα με {goodFirstIssuesLink} αν θέλετε να βοηθήσετε αλλά δεν ξέρετε από πού να ξεκινήσετε.\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"καλά πρώτα ζητήματα\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"Τι πρέπει να κάνω;\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"Πριν συνεισφέρετε κώδικα, παρακαλούμε διαβάστε τον {contributionGuideLink}. Περιγράφει τις διαδικασίες γύρω από τη δημιουργία και την αναθεώρηση pull requests.\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"Οδηγό Συνεισφοράς\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"Αφού γράψετε κώδικα, παρακαλούμε {signYourCommitsLink} για να διασφαλίσετε ότι το Helm συμμορφώνεται με τη συμφωνία {dcoLink} που χρησιμοποιείται από το {cncfLink}.\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"υπογράψτε τα commits σας\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"Μπες στην κοινότητα\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Περισσότερες πληροφορίες για το Helm project, και πως να συνεισφέρεις.\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.about.whatIsHelm\": {\n    \"message\": \"Το Helm σας βοηθά να διαχειρίζεστε εφαρμογές Kubernetes — Τα Helm Charts σας βοηθούν να ορίζετε, να εγκαθιστάτε και να αναβαθμίζετε ακόμα και τις πιο σύνθετες εφαρμογές Kubernetes.\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"message\": \"Τα Charts είναι εύκολο να δημιουργηθούν, να εκδοθούν σε νέες εκδόσεις, να μοιραστούν και να δημοσιευτούν — ξεκινήστε λοιπόν να χρησιμοποιείτε το Helm και σταματήστε το αντιγραφή-επικόλληση.\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Το Helm είναι ένα graduated project στο {cncfLink} και διατηρείται από την {helmCommunityLink}.\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"κοινότητα Helm\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"Μάθε περισσότερα:\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Αρχιτεκτονική Helm\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"Οδηγός Γρήγορης Εκκίνησης\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"Βίντεο: Μια Εισαγωγή στο Helm\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"Τι είναι το Helm;\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"Διαχείριση Πολυπλοκότητας\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"message\": \"Τα Charts περιγράφουν ακόμα και τις πιο σύνθετες εφαρμογές, παρέχουν επαναλήψιμη εγκατάσταση εφαρμογών και λειτουργούν ως ενιαίο σημείο αναφοράς.\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"Εύκολες Ενημερώσεις\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"Αφαιρέστε τον πόνο από τις ενημερώσεις με αναβαθμίσεις επί τόπου και προσαρμοσμένα hooks.\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"Απλή Κοινοποίηση\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"Τα Charts είναι εύκολο να εκδοθούν σε νέες εκδόσεις, να μοιραστούν και να φιλοξενηθούν σε δημόσιους ή ιδιωτικούς διακομιστές.\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"Επαναφορές\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"Χρησιμοποιήστε το {helmRollback} για να επαναφέρετε εύκολα σε παλαιότερη έκδοση μιας κυκλοφορίας.\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"Χαρακτηριστικά\",\n    \"description\": \"Features section title\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"Ξεκίνα\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"Κατέβασε το Helm!\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"Εγκαταστήστε το Helm με έναν διαχειριστή πακέτων ή {downloadLink}.\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"κατεβάστε ένα δυαδικό αρχείο\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"message\": \"Μόλις εγκατασταθεί, αποσυμπιέστε το δυαδικό αρχείο helm και προσθέστε το στο PATH σας και είστε έτοιμοι! Ελέγξτε τα {docsLink} για περαιτέρω {installationLink} και {usageLink}.\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"έγγραφα\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"οδηγίες εγκατάστασης\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"οδηγίες χρήσης\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"Κατέβασε Charts\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"Επισκεφτείτε το {artifactHubLink} για να εξερευνήσετε {helmChartsLink} από πολλά δημόσια αποθετήρια.\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"Helm charts\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"Ο διαχειριστής πακέτων για το Kubernetes\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Το Helm είναι ο καλύτερος τρόπος για να βρείτε, να μοιραστείτε και να χρησιμοποιήσετε λογισμικό που έχει κατασκευαστεί για\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"This page crashed.\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"Scroll back to top\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"Archive\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"Archive\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"Blog list page navigation\",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"Newer entries\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"Older entries\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"Blog post page navigation\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"Newer post\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"Older post\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"View all tags\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"λειτουργία συστήματος\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"φωτεινή λειτουργία\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"σκοτεινή λειτουργία\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"Switch between dark and light mode (currently {mode})\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"Breadcrumbs\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"1 item|{count} items\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"Docs pages\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"Previous\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"Next\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"One doc tagged|{count} docs tagged\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged} with \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"This is unreleased documentation for {siteTitle} {versionLabel} version.\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"latest version\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"Version: {versionLabel}\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"Edit this page\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"Direct link to {heading}\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \" on {date}\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \" by {user}\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"Last updated{atDate}{byUser}\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"Page Not Found\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"Versions\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"Tags:\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"caution\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"danger\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"info\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"note\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"tip\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"warning\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"Close\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"Blog recent posts navigation\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"Expand sidebar category '{label}'\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"Collapse sidebar category '{label}'\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(ανοίγει σε νέα καρτέλα)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"Main\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"We could not find what you were looking for.\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"message\": \"Please contact the owner of the site that linked you to the original URL and let them know their link is broken.\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"Languages\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"On this page\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"One min read|{readingTime} min read\",\n    \"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)\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"Read more\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"Read more about {title}\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"Copy\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"Copied\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"Copy code to clipboard\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"Home page\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"Toggle word wrap\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"Docs sidebar\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"Collapse sidebar\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"Collapse sidebar\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"Close navigation bar\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← Back to main menu\",\n    \"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)\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"Toggle navigation bar\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"Ανάπτυξη του αναπτυσσόμενου μενού\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"Σύμπτυξη του αναπτυσσόμενου μενού\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"Expand sidebar\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"Expand sidebar\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"One post|{count} posts\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"{nPosts} tagged with \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"Συγγραφείς\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"View all authors\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"This author has not written any posts yet.\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"Unlisted page\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"message\": \"This page is unlisted. Search engines will not index it, and only users having a direct link can access it.\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"Draft page\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"This page is a draft. It will only be visible in dev and be excluded from the production build.\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"Try again\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"Skip to main content\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"Tags\",\n    \"description\": \"The title of the tag list page\"\n  },\n  \"theme.blog.list.pageTitle\": {\n    \"message\": \"Ιστολόγιο\",\n    \"description\": \"The word 'Blog' in breadcrumbs\"\n  }\n}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Ιστολόγιο\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"Ιστολόγιο\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"Όλες οι δημοσιεύσεις\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Χρήση του Helm\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Εντολές Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"Ανάπτυξη Προτύπων\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Καλές Πρακτικές\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: Γενικές Συμβάσεις\ndescription: Γενικές Συμβάσεις για τα charts.\nsidebar_position: 1\n---\n\nΑυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών εξηγεί τις γενικές συμβάσεις.\n\n## Ονόματα των Charts {#chart-names}\n\nΤα ονόματα των charts πρέπει να είναι γραμμένα με μικρά λατινικά γράμματα και αριθμούς. Οι λέξεις _μπορούν_ να διαχωρίζονται με παύλες (-):\n\nΠαραδείγματα:\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nΟύτε κεφαλαία γράμματα ούτε κάτω παύλες μπορούν να χρησιμοποιούνται στα ονόματα των charts. Οι τελείες δεν θα πρέπει να χρησιμοποιούνται στα ονόματα των charts.\n\n## Αριθμοί Εκδόσεων {#version-numbers}\n\nΌπου είναι δυνατό, το Helm χρησιμοποιεί το [SemVer 2](https://semver.org) για να αναπαραστήσει τους αριθμούς των εκδόσεων. (Σημειώστε ότι τα tags ενός Docker image δεν ακολουθούν απαραίτητα το SemVer, και ως εκ τούτου θεωρούνται μια ατυχής εξαίρεση στον κανόνα.)\n\nΌταν οι εκδόσεις τύπου SemVer αποθηκεύονται στα labels του Kubernetes, ως σύμβαση αλλάζουμε τον χαρακτήρα `+` σε `_`, καθώς τα labels δεν επιτρέπουν το σήμα `+` ως τιμή.\n\n## Μορφοποίηση του YAML {#formatting-yaml}\n\nΤα αρχεία YAML θα πρέπει να στοιχίζονται χρησιμοποιώντας _δύο κενά_ (και ποτέ tabs).\n\n## Χρήση των λέξεων Helm και Chart {#usage-of-the-words-helm-and-chart}\n\nΥπάρχουν μερικές συμβάσεις για τη χρήση των λέξεων _Helm_ και _helm_.\n\n- Το _Helm_ αναφέρεται σε ολόκληρο το project\n- Το `helm` αναφέρεται στην εντολή που εκτελείται από τον χρήστη\n- Ο όρος `chart` δεν χρειάζεται να γραφτεί με κεφαλαίο, αφού δεν αποτελεί κύριο όνομα\n- Παρ' ολ' αυτά, το `Chart.yaml` χρειάζεται να γραφτεί με κεφαλαίο γιατί τα ονόματα αρχείων κάνουν διάκριση πεζών-κεφαλαίων (case sensitive).\n\nΌταν δεν είστε σίγουροι, χρησιμοποιήστε το _Helm_ (με κεφαλαίο 'H').\n\n## Chart templates και namespaces {#chart-templates-and-namespaces}\n\nΑποφύγετε τον ορισμό της ιδιότητας `namespace` στην ενότητα `metadata` των templates του chart σας. Το namespace στο οποίο θα εφαρμοστούν τα rendered templates πρέπει να καθορίζεται κατά την κλήση του Kubernetes client μέσω flag όπως `--namespace`. Το Helm κάνει render τα templates σας ως έχουν και τα στέλνει στον Kubernetes client, είτε αυτός είναι το ίδιο το Helm είτε κάποιο άλλο πρόγραμμα (kubectl, flux, spinnaker, κ.λπ.).\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Custom Resource Definitions\ndescription: Πώς να χειρίζεστε τη δημιουργία και χρήση των CRDs.\nsidebar_position: 7\n---\n\nΑυτός ο τομέας του οδηγού καλύπτει τη δημιουργία και χρήση αντικειμένων\nCustom Resource Definition.\n\nΌταν εργάζεστε με Custom Resource Definitions (CRDs), είναι σημαντικό να\nδιακρίνετε δύο διαφορετικά στοιχεία:\n\n- Υπάρχει η δήλωση ενός CRD. Αυτό είναι το αρχείο YAML που έχει kind\n  `CustomResourceDefinition`\n- Στη συνέχεια υπάρχουν πόροι που _χρησιμοποιούν_ το CRD. Ας πούμε ότι ένα CRD ορίζει\n  `foo.example.com/v1`. Οποιοσδήποτε πόρος έχει `apiVersion: example.com/v1` και\n  kind `Foo` είναι ένας πόρος που χρησιμοποιεί το CRD.\n\n## Εγκαταστήστε μια Δήλωση CRD Πριν Χρησιμοποιήσετε τον Πόρο {#install-a-crd-declaration-before-using-the-resource}\n\nΤο Helm είναι βελτιστοποιημένο για να φορτώνει όσο το δυνατόν περισσότερους πόρους στο Kubernetes\nτο συντομότερο δυνατό. Από σχεδιασμό, το Kubernetes μπορεί να λάβει ένα ολόκληρο σύνολο manifests\nκαι να τα φέρει όλα online (αυτό ονομάζεται reconciliation loop).\n\nΑλλά υπάρχει μια διαφορά με τα CRDs.\n\nΓια ένα CRD, η δήλωση πρέπει να καταχωρηθεί πριν μπορέσουν να χρησιμοποιηθούν\nοποιοιδήποτε πόροι του τύπου (ή των τύπων) αυτού του CRD. Και η διαδικασία\nκαταχώρησης μερικές φορές διαρκεί μερικά δευτερόλεπτα.\n\n### Μέθοδος 1: Αφήστε το `helm` να το Κάνει {#method-1-let-helm-do-it-for-you}\n\nΜε την άφιξη του Helm 3, αφαιρέσαμε τα παλιά `crd-install` hooks για μια πιο\nαπλή μεθοδολογία. Υπάρχει τώρα ένας ειδικός φάκελος με το όνομα `crds` που μπορείτε\nνα δημιουργήσετε στο chart σας για να περιέχει τα CRDs σας. Αυτά τα CRDs δεν υποστηρίζουν\ntemplating, αλλά θα εγκατασταθούν από προεπιλογή όταν εκτελείτε `helm install` για το chart.\nΑν το CRD υπάρχει ήδη, θα παραλειφθεί με μια προειδοποίηση. Αν θέλετε να παραλείψετε\nτο βήμα εγκατάστασης CRD, μπορείτε να περάσετε τη σημαία `--skip-crds`.\n\n#### Μερικές επιφυλάξεις (και εξηγήσεις) {#some-caveats-and-explanations}\n\nΔεν υπάρχει υποστήριξη αυτή τη στιγμή για αναβάθμιση ή διαγραφή CRDs χρησιμοποιώντας το Helm.\nΑυτή ήταν μια ρητή απόφαση μετά από πολλή συζήτηση στην κοινότητα λόγω του κινδύνου για\nακούσια απώλεια δεδομένων. Επιπλέον, αυτή τη στιγμή δεν υπάρχει συναίνεση στην κοινότητα\nσχετικά με τον τρόπο χειρισμού των CRDs και του κύκλου ζωής τους. Καθώς αυτό εξελίσσεται,\nτο Helm θα προσθέσει υποστήριξη για αυτές τις περιπτώσεις χρήσης.\n\nΗ σημαία `--dry-run` των `helm install` και `helm upgrade` δεν υποστηρίζεται αυτή τη στιγμή\nγια CRDs. Ο σκοπός του \"Dry Run\" είναι να επικυρώσει ότι η έξοδος του chart θα λειτουργήσει\nπραγματικά αν σταλεί στον server. Αλλά τα CRDs αποτελούν τροποποίηση της συμπεριφοράς του\nserver. Το Helm δεν μπορεί να εγκαταστήσει το CRD σε dry run, επομένως ο discovery client\nδεν θα γνωρίζει για αυτό το Custom Resource (CR), και η επικύρωση θα αποτύχει. Εναλλακτικά\nμπορείτε να μεταφέρετε τα CRDs στο δικό τους chart ή να χρησιμοποιήσετε το `helm template`\nαντί αυτού.\n\nΈνα άλλο σημαντικό σημείο που πρέπει να ληφθεί υπόψη στη συζήτηση γύρω από την υποστήριξη\nCRD είναι ο τρόπος με τον οποίο γίνεται το rendering των templates. Ένα από τα ξεχωριστά\nμειονεκτήματα της μεθόδου `crd-install` που χρησιμοποιούνταν στο Helm 2 ήταν η αδυναμία\nσωστής επικύρωσης charts λόγω της μεταβαλλόμενης διαθεσιμότητας API (ένα CRD στην πραγματικότητα\nπροσθέτει ένα ακόμη διαθέσιμο API στο Kubernetes cluster σας). Αν ένα chart εγκαθιστούσε\nένα CRD, το `helm` δεν είχε πλέον ένα έγκυρο σύνολο εκδόσεων API με το οποίο να εργαστεί.\nΑυτός είναι επίσης ο λόγος πίσω από την αφαίρεση της υποστήριξης templating από τα CRDs.\nΜε τη νέα μέθοδο `crds` για την εγκατάσταση CRD, διασφαλίζουμε τώρα ότι το `helm` έχει\nπλήρως έγκυρες πληροφορίες για την τρέχουσα κατάσταση του cluster.\n\n### Μέθοδος 2: Ξεχωριστά Charts {#method-2-separate-charts}\n\nΈνας άλλος τρόπος για να το κάνετε αυτό είναι να βάλετε τον ορισμό του CRD σε ένα chart,\nκαι στη συνέχεια να βάλετε οποιουσδήποτε πόρους που χρησιμοποιούν αυτό το CRD σε\n_ένα άλλο_ chart.\n\nΜε αυτή τη μέθοδο, κάθε chart πρέπει να εγκατασταθεί ξεχωριστά. Ωστόσο, αυτή η ροή\nεργασίας μπορεί να είναι πιο χρήσιμη για διαχειριστές cluster που διαθέτουν\nδικαιώματα διαχειριστή σε ένα cluster.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: Εξαρτήσεις\ndescription: Καλύπτει τις βέλτιστες πρακτικές για τις εξαρτήσεις ενός Chart.\nsidebar_position: 4\n---\n\nΑυτός ο τομέας του οδηγού καλύπτει τις βέλτιστες πρακτικές για τις `dependencies` που δηλώνονται στο `Chart.yaml`.\n\n## Εκδόσεις {#versions}\n\nΌπου είναι δυνατό, χρησιμοποιήστε ένα εύρος εκδόσεων αντί να καρφώνετε σε κάποια συγκεκριμένη έκδοση. Η συνιστώμενη προεπιλογή είναι να χρησιμοποιείτε ταίριασμα σε επίπεδο patch:\n\n```yaml\nversion: ~1.2.3\n```\n\nΑυτό θα ταιριάξει με την έκδοση `1.2.3` και όλα τα patches αυτής της έκδοσης. Με άλλα λόγια, το `~1.2.3` είναι ισοδύναμο με `>= 1.2.3, < 1.3.0`\n\nΓια την πλήρη σύνταξη του ταιριάσματος εκδόσεων, παρακαλούμε δείτε την [τεκμηρίωση του semver](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Prerelease εκδόσεις {#prerelease-versions}\n\nΟι παραπάνω περιορισμοί έκδοσης δεν θα ταιριάξουν με prerelease εκδόσεις. Για παράδειγμα, το `version: ~1.2.3` θα ταιριάξει με το `version: ~1.2.4` αλλά όχι με το `version: ~1.2.3-1`. Το παρακάτω παρέχει ταίριασμα τόσο για prerelease όσο και σε επίπεδο patch:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### URLs των Repositories {#repository-urls}\n\nΌπου είναι δυνατό, χρησιμοποιήστε `https://` URLs για τα repositories, και στη συνέχεια `http://` URLs.\n\nΑν το repository έχει προστεθεί στο αρχείο index του repository, το όνομα του repository μπορεί να χρησιμοποιηθεί ως alias του URL. Χρησιμοποιήστε `alias:` ή `@` ακολουθούμενο από το όνομα του repository.\n\nΤα file URLs (`file://...`) θεωρούνται ως «ειδική περίπτωση» για charts τα οποία συναρμολογούνται από ένα σταθερό deployment pipeline.\n\nΌταν χρησιμοποιείτε [downloader plugins](/topics/plugins.md#plugins-λήψης), το URL scheme θα είναι συγκεκριμένο για το plugin. Σημειώστε ότι ένας χρήστης του chart θα πρέπει να έχει εγκατεστημένο ένα plugin που υποστηρίζει το scheme για να ενημερώσει ή να δημιουργήσει την εξάρτηση.\n\nΤο Helm δεν μπορεί να εκτελέσει λειτουργίες διαχείρισης εξαρτήσεων στην εξάρτηση όταν το πεδίο `repository` παραμένει κενό. Σε αυτήν την περίπτωση, το Helm θα υποθέσει ότι η εξάρτηση βρίσκεται σε έναν υποφάκελο του φακέλου `charts` με το ίδιο όνομα με την ιδιότητα `name` της εξάρτησης.\n\n## Συνθήκες και Tags {#conditions-and-tags}\n\nΟι συνθήκες ή τα tags θα πρέπει να προστίθενται σε εξαρτήσεις που είναι _προαιρετικές_. Σημειώστε ότι από προεπιλογή ένα `condition` είναι `true`.\n\nΗ προτιμώμενη μορφή μίας συνθήκης (condition) είναι η ακόλουθη:\n\n```yaml\ncondition: somechart.enabled\n```\n\nΌπου το `somechart` είναι το όνομα του chart της εξάρτησης.\n\nΌταν πολλαπλά subcharts (εξαρτήσεις) παρέχουν μαζί ένα προαιρετικό ή ανταλλάξιμο feature, αυτά τα charts θα πρέπει να μοιράζονται τα ίδια tags.\n\nΓια παράδειγμα, αν τόσο το `nginx` όσο και το `memcached` παρέχουν βελτιστοποιήσεις απόδοσης για την κύρια εφαρμογή του chart, και απαιτούνται και τα δύο όταν αυτό το feature είναι ενεργοποιημένο, τότε θα πρέπει να έχουν και τα δύο έναν τομέα με tags κάπως έτσι:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nΑυτό επιτρέπει στον χρήστη να ενεργοποιεί και να απενεργοποιεί αυτό το feature με ένα tag.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx",
    "content": "---\ntitle: Βέλτιστες Πρακτικές\nsidebar: true\nsidebar_position: 4\n---\n\n# Ο Οδηγός Βέλτιστων Πρακτικών για τα Charts\n\nΑυτός ο οδηγός καλύπτει αυτά που η Ομάδα του Helm θεωρεί ως βέλτιστες πρακτικές για την δημιουργία charts.\nΕπικεντρώνεται στο πως θα έπρεπε να δομούνται τα charts.\n\nΚυρίως επικεντρωνόμαστε στις βέλτιστες πρακτικές για τα charts τα οποία θα μπορούσαν να γίνουν deploy από ευρύτερο κοινό.\nΞέρουμε ότι πολλά charts προορίζονται μόνο για εσωτερική χρήση, και οι συγγραφείς τέτοιων charts ότι τα εσωτερικά συμφέροντα παρακάμπτουν τις προτάσεις μας εδώ.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: Ετικέτες και Annotations\ndescription: Καλύπτει τις βέλτιστες πρακτικές για τη χρήση ετικετών και annotations στο chart σας.\nsidebar_position: 5\n---\n\nΑυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών καλύπτει τις βέλτιστες πρακτικές για τη χρήση ετικετών και annotations στο chart σας.\n\n## Είναι Ετικέτα ή Annotation; {#is-it-a-label-or-an-annotation}\n\nΈνα στοιχείο μεταδεδομένων θα πρέπει να είναι ετικέτα υπό τις ακόλουθες συνθήκες:\n\n- Χρησιμοποιείται από το Kubernetes για την αναγνώριση αυτού του πόρου\n- Είναι χρήσιμο να εκτίθεται στους διαχειριστές για σκοπούς αναζήτησης στο σύστημα.\n\nΓια παράδειγμα, προτείνουμε τη χρήση του `helm.sh/chart: NAME-VERSION` ως ετικέτα, ώστε οι διαχειριστές να μπορούν να βρίσκουν εύκολα όλες τις εκδοχές ενός συγκεκριμένου chart.\n\nΑν ένα στοιχείο μεταδεδομένων δεν χρησιμοποιείται για αναζήτηση, θα πρέπει να οριστεί ως annotation.\n\nΤα Helm hooks είναι πάντα annotations.\n\n## Τυπικές Ετικέτες {#standard-labels}\n\nΟ παρακάτω πίνακας ορίζει τις συνήθεις ετικέτες που χρησιμοποιούν τα Helm charts. Το ίδιο το Helm δεν απαιτεί ποτέ την παρουσία μιας συγκεκριμένης ετικέτας. Οι ετικέτες που σημειώνονται με REC συνιστώνται και **θα πρέπει** να τοποθετούνται σε ένα chart για γενική συνέπεια. Αυτές που σημειώνονται με OPT είναι προαιρετικές. Είναι συνηθισμένες στην πράξη, αλλά δεν είναι απαραίτητες για λειτουργικούς σκοπούς.\n\n| Όνομα | Κατάσταση | Περιγραφή |\n|-------|-----------|-----------|\n| `app.kubernetes.io/name` | REC | Θα πρέπει να είναι το όνομα της εφαρμογής, που αντιπροσωπεύει ολόκληρη την εφαρμογή. Συνήθως χρησιμοποιείται το `{{ template \"name\" . }}`. Χρησιμοποιείται από πολλά Kubernetes manifests και δεν είναι συγκεκριμένο για το Helm. |\n| `helm.sh/chart` | REC | Θα πρέπει να είναι το όνομα και η έκδοση του chart: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`. |\n| `app.kubernetes.io/managed-by` | REC | Θα πρέπει να είναι πάντα `{{ .Release.Service }}`. Χρησιμοποιείται για την εύρεση όλων των πόρων που διαχειρίζεται το Helm. |\n| `app.kubernetes.io/instance` | REC | Θα πρέπει να είναι το `{{ .Release.Name }}`. Βοηθά στη διάκριση μεταξύ διαφορετικών εκδοχών της ίδιας εφαρμογής. |\n| `app.kubernetes.io/version` | OPT | Η έκδοση της εφαρμογής και μπορεί να οριστεί ως `{{ .Chart.AppVersion }}`. |\n| `app.kubernetes.io/component` | OPT | Μια συνήθης ετικέτα για τη σήμανση των διαφορετικών ρόλων που μπορεί να έχουν τα διάφορα στοιχεία μιας εφαρμογής. Για παράδειγμα, `app.kubernetes.io/component: frontend`. |\n| `app.kubernetes.io/part-of` | OPT | Όταν χρησιμοποιούνται πολλαπλά charts ή στοιχεία λογισμικού μαζί για τη δημιουργία μιας εφαρμογής. Για παράδειγμα, λογισμικό εφαρμογής και μια βάση δεδομένων για την παραγωγή ενός ιστότοπου. Μπορεί να οριστεί στην εφαρμογή ανώτερου επιπέδου που υποστηρίζεται. |\n\nΜπορείτε να βρείτε περισσότερες πληροφορίες για τις ετικέτες του Kubernetes, με πρόθεμα `app.kubernetes.io`, στην [τεκμηρίωση του Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pod και PodTemplate\ndescription: Συζητά τη μορφοποίηση των τμημάτων Pod και PodTemplate στα manifests των chart.\nsidebar_position: 6\n---\n\nΑυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών καλύπτει τη μορφοποίηση των τμημάτων Pod και PodTemplate στα manifests των chart.\n\nΗ παρακάτω (μη εξαντλητική) λίστα πόρων χρησιμοποιεί PodTemplates:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Images {#images}\n\nΈνα container image θα πρέπει να χρησιμοποιεί ένα σταθερό tag ή το SHA του image. Δεν θα πρέπει να χρησιμοποιεί τα tags `latest`, `head`, `canary`, ή άλλα tags που είναι σχεδιασμένα να είναι \"floating\" (μεταβαλλόμενα).\n\nΤα images _μπορούν_ να οριστούν στο αρχείο `values.yaml` για να διευκολύνεται η αλλαγή τους.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nΈνα image και ένα tag _μπορούν_ να οριστούν στο `values.yaml` ως δύο ξεχωριστά πεδία:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy {#imagepullpolicy}\n\nΗ εντολή `helm create` ορίζει το `imagePullPolicy` σε `IfNotPresent` από προεπιλογή με τις ακόλουθες ρυθμίσεις στο `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nΚαι στο `values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nΟμοίως, το Kubernetes ορίζει το `imagePullPolicy` σε `IfNotPresent` από προεπιλογή, αν δεν έχει οριστεί καθόλου. Αν θέλετε μια διαφορετική τιμή από το `IfNotPresent`, απλά ενημερώστε την τιμή στο `values.yaml` με την επιθυμητή τιμή.\n\n## Τα PodTemplates Θα Πρέπει να Δηλώνουν Selectors {#podtemplates-should-declare-selectors}\n\nΌλα τα τμήματα PodTemplate θα πρέπει να καθορίζουν έναν selector. Για παράδειγμα:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nΑυτή είναι μια καλή πρακτική επειδή καθιστά σαφή τη σχέση μεταξύ του set και του Pod.\n\nΑυτό είναι ακόμα πιο σημαντικό για πόρους όπως το Deployment. Χωρίς selector, χρησιμοποιείται _ολόκληρο_ το σύνολο των labels για την επιλογή των αντίστοιχων Pods, πράγμα που θα προκαλέσει προβλήματα αν χρησιμοποιείτε labels που αλλάζουν, όπως η έκδοση ή η ημερομηνία release.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: Έλεγχος Πρόσβασης Βασισμένος σε Ρόλους (RBAC)\ndescription: Συζητά τη δημιουργία και τη μορφοποίηση πόρων RBAC στα manifests των Charts.\nsidebar_position: 8\n---\n\nΑυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών ασχολείται με τη δημιουργία και τη\nμορφοποίηση πόρων RBAC στα manifests των charts.\n\nΟι πόροι RBAC είναι:\n\n- ServiceAccount (namespaced)\n- Role (namespaced)\n- ClusterRole\n- RoleBinding (namespaced)\n- ClusterRoleBinding\n\n## Διαμόρφωση YAML {#yaml-configuration}\n\nΗ διαμόρφωση RBAC και ServiceAccount θα πρέπει να γίνεται σε ξεχωριστά κλειδιά.\nΕίναι διαφορετικά πράγματα. Ο διαχωρισμός τους στο YAML αποσαφηνίζει τις έννοιες\nκαι τις κάνει πιο κατανοητές.\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\nΑυτή η δομή μπορεί να επεκταθεί για πιο σύνθετα charts που απαιτούν πολλαπλά\nServiceAccounts.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## Οι Πόροι RBAC Θα Πρέπει να Δημιουργούνται από Προεπιλογή {#rbac-resources-should-be-created-by-default}\n\nΤο `rbac.create` θα πρέπει να είναι μια boolean τιμή που ελέγχει αν θα δημιουργηθούν\nπόροι RBAC. Η προεπιλεγμένη τιμή θα πρέπει να είναι `true`. Οι χρήστες που επιθυμούν\nνα διαχειριστούν οι ίδιοι τους ελέγχους πρόσβασης RBAC μπορούν να ορίσουν αυτή την\nτιμή σε `false` (δείτε παρακάτω).\n\n## Χρήση Πόρων RBAC {#using-rbac-resources}\n\nΤο `serviceAccount.name` θα πρέπει να οριστεί στο όνομα του ServiceAccount που θα\nχρησιμοποιηθεί από τους πόρους με έλεγχο πρόσβασης που δημιουργεί το chart. Αν το\n`serviceAccount.create` είναι true, τότε θα πρέπει να δημιουργηθεί ένα ServiceAccount\nμε αυτό το όνομα. Αν το όνομα δεν έχει οριστεί, τότε δημιουργείται ένα όνομα\nχρησιμοποιώντας το template `fullname`. Αν το `serviceAccount.create` είναι false,\nτότε δεν θα πρέπει να δημιουργηθεί, αλλά θα πρέπει να συσχετίζεται με τους ίδιους\nπόρους ώστε οι πόροι RBAC που δημιουργούνται χειροκίνητα αργότερα και αναφέρονται\nσε αυτό να λειτουργούν σωστά. Αν το `serviceAccount.create` είναι false και το όνομα\nδεν έχει καθοριστεί, τότε χρησιμοποιείται το προεπιλεγμένο ServiceAccount.\n\nΧρησιμοποιήστε το παρακάτω βοηθητικό template για το ServiceAccount.\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: Templates\ndescription: Μια πιο προσεκτική ματιά στις βέλτιστες πρακτικές που αφορούν τα templates.\nsidebar_position: 3\n---\n\nΑυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών εστιάζει στα templates.\n\n## Δομή του `templates/` {#structure-of-templates}\n\nΟ φάκελος `templates/` θα πρέπει να είναι δομημένος ως εξής:\n\n- Τα αρχεία template θα πρέπει να έχουν την επέκταση `.yaml` αν παράγουν έξοδο YAML.\n  Η επέκταση `.tpl` μπορεί να χρησιμοποιηθεί για αρχεία template που δεν παράγουν\n  μορφοποιημένο περιεχόμενο.\n- Τα ονόματα των αρχείων template θα πρέπει να χρησιμοποιούν παύλες (`my-example-configmap.yaml`),\n  όχι camelcase.\n- Κάθε ορισμός πόρου θα πρέπει να βρίσκεται στο δικό του αρχείο template.\n- Τα ονόματα των αρχείων template θα πρέπει να αντικατοπτρίζουν τον τύπο του πόρου, π.χ.\n  `foo-pod.yaml`, `bar-svc.yaml`\n\n## Ονόματα Καθορισμένων Templates {#names-of-defined-templates}\n\nΤα καθορισμένα templates (templates που δημιουργούνται μέσα σε μια οδηγία `{{ define }}`) είναι\nπροσβάσιμα από οπουδήποτε. Αυτό σημαίνει ότι ένα chart και όλα τα subcharts του θα έχουν\nπρόσβαση σε όλα τα templates που δημιουργήθηκαν με `{{ define }}`.\n\nΓια αυτόν τον λόγο, _όλα τα ονόματα καθορισμένων templates θα πρέπει να έχουν namespace._\n\nΣωστό:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nΛάθος:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\nΣυνιστάται ιδιαίτερα να δημιουργούνται νέα charts μέσω της εντολής `helm create`,\nκαθώς τα ονόματα των templates ορίζονται αυτόματα σύμφωνα με αυτή τη βέλτιστη πρακτική.\n\n## Μορφοποίηση Templates {#formatting-templates}\n\nΤα templates θα πρέπει να έχουν εσοχή με _δύο κενά_ (ποτέ tabs).\n\nΟι οδηγίες template θα πρέπει να έχουν κενό μετά τα αρχικά άγκιστρα και πριν τα\nτελικά άγκιστρα:\n\nΣωστό:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nΛάθος:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nΤα templates θα πρέπει να περικόπτουν τα κενά όπου είναι δυνατόν:\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nΤα blocks (όπως οι δομές ελέγχου) μπορούν να έχουν εσοχή για να υποδεικνύουν τη ροή του\nκώδικα του template.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nΩστόσο, δεδομένου ότι το YAML είναι μια γλώσσα που βασίζεται στα κενά, συχνά δεν είναι δυνατό\nη εσοχή του κώδικα να ακολουθεί αυτή τη σύμβαση.\n\n## Κενά στα Παραγόμενα Templates {#whitespace-in-generated-templates}\n\nΕίναι προτιμότερο να κρατάτε τον αριθμό των κενών στα παραγόμενα templates στο\nελάχιστο. Ειδικότερα, δεν θα πρέπει να εμφανίζονται πολλές κενές γραμμές διαδοχικά.\nΑλλά περιστασιακά κενές γραμμές (ιδιαίτερα μεταξύ λογικών ενοτήτων) είναι αποδεκτές.\n\nΑυτό είναι το καλύτερο:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nΑυτό είναι αποδεκτό:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nΑλλά αυτό θα πρέπει να αποφεύγεται:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Σχόλια (Σχόλια YAML έναντι Σχολίων Template) {#comments-yaml-comments-vs-template-comments}\n\nΤόσο το YAML όσο και τα Helm Templates έχουν δείκτες σχολίων.\n\nΣχόλια YAML:\n```yaml\n# This is a comment {#this-is-a-comment}\ntype: sprocket\n```\n\nΣχόλια Template:\n```yaml\n{{- /*\nThis is a comment.\n*/}}\ntype: frobnitz\n```\n\nΤα σχόλια template θα πρέπει να χρησιμοποιούνται όταν τεκμηριώνετε χαρακτηριστικά ενός template,\nόπως για να εξηγήσετε ένα καθορισμένο template:\n\n```yaml\n{{- /*\nmychart.shortname provides a 6 char truncated version of the release name.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nΜέσα στα templates, τα σχόλια YAML μπορούν να χρησιμοποιηθούν όταν είναι χρήσιμο για τους\nχρήστες του Helm να (πιθανώς) δουν τα σχόλια κατά την αποσφαλμάτωση.\n\n```yaml\n# 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}\nmemory: {{ .Values.maxMem | quote }}\n```\n\nΤο παραπάνω σχόλιο είναι ορατό όταν ο χρήστης εκτελεί `helm install --debug`, ενώ\nτα σχόλια που καθορίζονται σε ενότητες `{{- /* */}}` δεν είναι.\n\nΝα είστε προσεκτικοί όταν προσθέτετε σχόλια YAML με `#` σε ενότητες template που περιέχουν τιμές Helm που μπορεί να απαιτούνται από ορισμένες συναρτήσεις template.\n\nΓια παράδειγμα, αν η συνάρτηση `required` χρησιμοποιηθεί στο παραπάνω παράδειγμα και το `maxMem` δεν έχει οριστεί, τότε ένα σχόλιο YAML με `#` θα προκαλέσει σφάλμα rendering.\n\nΣωστό: το `helm template` δεν κάνει render αυτό το block\n```yaml\n{{- /*\n# This may cause problems if the value is more than 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nΛάθος: το `helm template` επιστρέφει `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n```yaml\n# This may cause problems if the value is more than 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }} {#memory-required-valuesmaxmem-maxmem-must-be-set-quote}\n```\n\nΔείτε το [Αποσφαλμάτωση Templates](../chart_template_guide/debugging.md) για ένα ακόμη παράδειγμα αυτής της συμπεριφοράς όπου τα σχόλια YAML παραμένουν άθικτα.\n\n## Χρήση JSON σε Templates και Έξοδο Template {#use-of-json-in-templates-and-template-output}\n\nΤο YAML είναι ένα υπερσύνολο του JSON. Σε ορισμένες περιπτώσεις, η χρήση σύνταξης JSON μπορεί να είναι\nπιο ευανάγνωστη από άλλες αναπαραστάσεις YAML.\n\nΓια παράδειγμα, αυτό το YAML είναι πιο κοντά στον κανονικό τρόπο YAML για την έκφραση λιστών:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nΑλλά είναι ευκολότερο να διαβαστεί όταν συμπτύσσεται σε στυλ λίστας JSON:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nΗ χρήση JSON για βελτιωμένη αναγνωσιμότητα είναι καλή. Ωστόσο, η σύνταξη JSON δεν θα πρέπει να\nχρησιμοποιείται για την αναπαράσταση πιο σύνθετων δομών.\n\nΌταν αντιμετωπίζετε καθαρό JSON ενσωματωμένο μέσα σε YAML (όπως διαμόρφωση init container),\nείναι φυσικά κατάλληλο να χρησιμοποιείτε τη μορφή JSON.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: Values\ndescription: Εστιάζει στον τρόπο με τον οποίο πρέπει να δομείτε και να χρησιμοποιείτε τα values.\nsidebar_position: 2\n---\n\nΑυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών καλύπτει τη χρήση των values. Σε αυτόν τον τομέα του οδηγού, παρέχουμε συστάσεις σχετικά με τον τρόπο που θα πρέπει να δομείτε και να χρησιμοποιείτε τα values, με έμφαση στο σχεδιασμό του αρχείου `values.yaml` ενός chart.\n\n## Συμβάσεις Ονομασίας {#naming-conventions}\n\nΤα ονόματα των μεταβλητών θα πρέπει να ξεκινούν με πεζό γράμμα, και οι λέξεις θα πρέπει να διαχωρίζονται με camelcase:\n\nΣωστό:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nΛάθος:\n\n```yaml\nChicken: true  # initial caps may conflict with built-ins\nchicken-noodle-soup: true # do not use hyphens in the name\n```\n\nΣημειώστε ότι όλες οι ενσωματωμένες μεταβλητές του Helm ξεκινούν με κεφαλαίο γράμμα για να διακρίνονται εύκολα από τα values που ορίζει ο χρήστης: `.Release.Name`, `.Capabilities.KubeVersion`.\n\n## Επίπεδα ή Ένθετα Values {#flat-or-nested-values}\n\nΤο YAML είναι μια ευέλικτη μορφή, και τα values μπορούν να είναι βαθιά ένθετα ή επίπεδα.\n\nΈνθετα:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nΕπίπεδα:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nΣτις περισσότερες περιπτώσεις, τα επίπεδα values είναι προτιμότερα από τα ένθετα. Ο λόγος είναι ότι είναι απλούστερα τόσο για τους developers των templates όσο και για τους χρήστες.\n\nΓια βέλτιστη ασφάλεια, ένα ένθετο value πρέπει να ελέγχεται σε κάθε επίπεδο:\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nΓια κάθε επίπεδο ένθεσης, πρέπει να γίνεται έλεγχος ύπαρξης. Αλλά για επίπεδη διαμόρφωση, τέτοιοι έλεγχοι μπορούν να παραλειφθούν, καθιστώντας το template ευκολότερο στην ανάγνωση και τη χρήση.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\nΌταν υπάρχει μεγάλος αριθμός σχετικών μεταβλητών, και τουλάχιστον μία από αυτές είναι υποχρεωτική, μπορούν να χρησιμοποιηθούν ένθετα values για βελτίωση της αναγνωσιμότητας.\n\n## Διευκρινίστε τους Τύπους {#make-types-clear}\n\nΟι κανόνες μετατροπής τύπων του YAML είναι μερικές φορές απροσδόκητοι. Για παράδειγμα, το `foo: false` δεν είναι το ίδιο με το `foo: \"false\"`. Μεγάλοι ακέραιοι αριθμοί όπως το `foo: 12345678` μπορεί να μετατραπούν σε επιστημονική σημειογραφία σε ορισμένες περιπτώσεις.\n\nΟ ευκολότερος τρόπος να αποφύγετε σφάλματα μετατροπής τύπων είναι να είστε σαφείς με τα strings και να αφήνετε τα υπόλοιπα ως έχουν. Ή, με λίγα λόγια, _βάζετε όλα τα strings σε εισαγωγικά_.\n\nΣυχνά, για να αποφευχθούν προβλήματα με τη μετατροπή ακεραίων, είναι προτιμότερο να αποθηκεύετε τους ακέραιους ως strings, και να χρησιμοποιείτε το `{{ int $value }}` στο template για μετατροπή από string σε ακέραιο.\n\nΣτις περισσότερες περιπτώσεις, οι ρητές ετικέτες τύπων αναγνωρίζονται σωστά, οπότε το `foo: !!string 1234` θα αντιμετωπίσει το `1234` ως string. _Ωστόσο_, ο YAML parser καταναλώνει τις ετικέτες, οπότε οι πληροφορίες τύπου χάνονται μετά από μία ανάλυση.\n\n## Σκεφτείτε πώς θα Χρησιμοποιήσουν οι Χρήστες τα Values {#consider-how-users-will-use-your-values}\n\nΥπάρχουν τρεις πιθανές πηγές για τα values:\n\n- Το αρχείο `values.yaml` του chart\n- Ένα αρχείο values που παρέχεται με τις εντολές `helm install -f` ή `helm upgrade -f`\n- Τα values που περνούν μέσω του flag `--set` ή `--set-string` στις εντολές `helm install` ή `helm upgrade`\n\nΚατά το σχεδιασμό της δομής των values σας, έχετε υπόψη ότι οι χρήστες του chart μπορεί να θέλουν να τα παρακάμψουν είτε μέσω του flag `-f` είτε με την επιλογή `--set`.\n\nΔεδομένου ότι το `--set` έχει περιορισμένη εκφραστικότητα, η πρώτη κατευθυντήρια γραμμή για τη συγγραφή του αρχείου `values.yaml` είναι _να το κάνετε εύκολο να παρακαμφθεί από το `--set`_.\n\nΓια αυτόν τον λόγο, είναι συχνά καλύτερο να δομείτε το αρχείο values χρησιμοποιώντας maps.\n\nΔύσκολο στη χρήση με `--set`:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nΤο παραπάνω δεν μπορεί να εκφραστεί με `--set` στο Helm `<=2.4`. Στο Helm 2.5, η πρόσβαση στο port του foo είναι `--set servers[0].port=80`. Όχι μόνο είναι δυσκολότερο για τον χρήστη να το βρει, αλλά είναι επιρρεπές σε σφάλματα αν αργότερα αλλάξει η σειρά των `servers`.\n\nΕύκολο στη χρήση:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nΗ πρόσβαση στο port του foo είναι πολύ πιο προφανής: `--set servers.foo.port=80`.\n\n## Τεκμηρίωση του `values.yaml` {#document-valuesyaml}\n\nΚάθε ορισμένη ιδιότητα στο `values.yaml` θα πρέπει να τεκμηριώνεται. Το σχόλιο τεκμηρίωσης θα πρέπει να ξεκινά με το όνομα της ιδιότητας που περιγράφει και στη συνέχεια να δίνει τουλάχιστον μια πρόταση περιγραφής.\n\nΛάθος:\n\n```yaml\n# the host name for the webserver {#the-host-name-for-the-webserver}\nserverHost: example\nserverPort: 9191\n```\n\nΣωστό:\n\n```yaml\n# serverHost is the host name for the webserver {#serverhost-is-the-host-name-for-the-webserver}\nserverHost: example\n# serverPort is the HTTP listener port for the webserver {#serverport-is-the-http-listener-port-for-the-webserver}\nserverPort: 9191\n```\n\nΤο να ξεκινάτε κάθε σχόλιο με το όνομα της παραμέτρου που τεκμηριώνει διευκολύνει την εξαγωγή τεκμηρίωσης μέσω grep, και θα επιτρέψει στα εργαλεία τεκμηρίωσης να συσχετίζουν αξιόπιστα τα σχόλια με τις παραμέτρους που περιγράφουν.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Πρόσβαση σε Αρχεία μέσα σε Templates\ndescription: Πώς να προσπελάσετε αρχεία μέσα από ένα template.\nsidebar_position: 10\n---\n\nΣτην προηγούμενη ενότητα εξετάσαμε διάφορους τρόπους δημιουργίας και πρόσβασης\nσε ονομασμένα templates. Αυτό διευκολύνει την εισαγωγή ενός template μέσα από\nένα άλλο template. Ωστόσο, μερικές φορές είναι επιθυμητό να εισάγετε ένα _αρχείο\nπου δεν είναι template_ και να ενσωματώσετε τα περιεχόμενά του χωρίς να τα\nπεράσετε μέσα από τον template renderer.\n\nΤο Helm παρέχει πρόσβαση σε αρχεία μέσω του αντικειμένου `.Files`. Πριν\nπροχωρήσουμε με τα παραδείγματα template, υπάρχουν μερικά πράγματα που πρέπει\nνα σημειώσουμε σχετικά με το πώς λειτουργεί αυτό:\n\n- Είναι δυνατό να προσθέσετε επιπλέον αρχεία στο Helm chart σας. Αυτά τα αρχεία\n  θα συμπεριληφθούν στο πακέτο. Να είστε όμως προσεκτικοί. Τα charts πρέπει να\n  είναι μικρότερα από 1M λόγω των περιορισμών αποθήκευσης των αντικειμένων\n  Kubernetes.\n- Ορισμένα αρχεία δεν είναι προσπελάσιμα μέσω του αντικειμένου `.Files`, συνήθως\n  για λόγους ασφαλείας.\n  - Τα αρχεία στο `templates/` δεν είναι προσπελάσιμα.\n  - Τα αρχεία που εξαιρούνται μέσω του `.helmignore` δεν είναι προσπελάσιμα.\n  - Τα αρχεία εκτός του [subchart](./subcharts_and_globals.md) μιας εφαρμογής Helm, συμπεριλαμβανομένων αυτών του γονικού chart, δεν είναι προσπελάσιμα\n- Τα charts δεν διατηρούν πληροφορίες λειτουργίας UNIX mode, επομένως τα\n  δικαιώματα σε επίπεδο αρχείου δεν επηρεάζουν τη διαθεσιμότητα ενός αρχείου\n  όσον αφορά το αντικείμενο `.Files`.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Βασικό παράδειγμα](#basic-example)\n- [Βοηθητικές συναρτήσεις διαδρομής](#path-helpers)\n- [Μοτίβα glob](#glob-patterns)\n- [Βοηθητικές συναρτήσεις ConfigMap και Secrets](#configmap-and-secrets-utility-functions)\n- [Κωδικοποίηση](#encoding)\n- [Γραμμές](#lines)\n\n<!-- tocstop -->\n\n## Βασικό παράδειγμα {#basic-example}\n\nΜε αυτά υπόψη, ας γράψουμε ένα template που διαβάζει τρία\nαρχεία στο ConfigMap μας. Για να ξεκινήσουμε, θα προσθέσουμε τρία αρχεία στο\nchart, τοποθετώντας και τα τρία απευθείας μέσα στον κατάλογο `mychart/`.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nΚαθένα από αυτά είναι ένα απλό αρχείο TOML (σκεφτείτε τα παλιά αρχεία Windows\nINI). Γνωρίζουμε τα ονόματα αυτών των αρχείων, οπότε μπορούμε να χρησιμοποιήσουμε\nμια συνάρτηση `range` για να επαναλάβουμε σε αυτά και να εισάγουμε τα\nπεριεχόμενά τους στο ConfigMap μας.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nΑυτό το ConfigMap χρησιμοποιεί αρκετές από τις τεχνικές που συζητήθηκαν σε\nπροηγούμενες ενότητες. Για παράδειγμα, δημιουργούμε μια μεταβλητή `$files` για\nνα κρατήσουμε μια αναφορά στο αντικείμενο `.Files`. Χρησιμοποιούμε επίσης τη\nσυνάρτηση `tuple` για να δημιουργήσουμε μια λίστα αρχείων που επαναλαμβάνουμε.\nΣτη συνέχεια εκτυπώνουμε κάθε όνομα αρχείου (`{{ . }}: |-`) ακολουθούμενο από\nτα περιεχόμενα του αρχείου `{{ $files.Get . }}`.\n\nΗ εκτέλεση αυτού του template θα παράγει ένα μόνο ConfigMap με τα περιεχόμενα\nκαι των τριών αρχείων:\n\n```yaml\n# Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Βοηθητικές συναρτήσεις διαδρομής {#path-helpers}\n\nΌταν εργάζεστε με αρχεία, μπορεί να είναι πολύ χρήσιμο να εκτελείτε ορισμένες\nτυπικές λειτουργίες στις ίδιες τις διαδρομές των αρχείων. Για να βοηθήσει σε\nαυτό, το Helm εισάγει πολλές από τις συναρτήσεις του πακέτου\n[path](https://golang.org/pkg/path/) της Go για χρήση. Είναι όλες προσβάσιμες\nμε τα ίδια ονόματα όπως στο πακέτο της Go, αλλά με πεζό πρώτο γράμμα.\nΓια παράδειγμα, η `Base` γίνεται `base`, κ.λπ.\n\nΟι εισαγόμενες συναρτήσεις είναι:\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Μοτίβα glob {#glob-patterns}\n\nΚαθώς το chart σας μεγαλώνει, μπορεί να διαπιστώσετε ότι χρειάζεστε καλύτερη\nοργάνωση των αρχείων σας, και γι' αυτό παρέχουμε μια μέθοδο\n`Files.Glob(pattern string)` για να βοηθήσουμε στην εξαγωγή συγκεκριμένων\nαρχείων με όλη την ευελιξία των [μοτίβων glob](https://godoc.org/github.com/gobwas/glob).\n\nΗ `.Glob` επιστρέφει έναν τύπο `Files`, οπότε μπορείτε να καλέσετε οποιαδήποτε\nαπό τις μεθόδους `Files` στο επιστρεφόμενο αντικείμενο.\n\nΓια παράδειγμα, φανταστείτε τη δομή καταλόγου:\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nΈχετε πολλές επιλογές με τα Globs:\n\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nΉ\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## Βοηθητικές συναρτήσεις ConfigMap και Secrets {#configmap-and-secrets-utility-functions}\n\n(Διαθέσιμο από Helm 2.0.2 και μετά)\n\nΕίναι πολύ συνηθισμένο να θέλετε να τοποθετήσετε περιεχόμενα αρχείων τόσο σε\nConfigMaps όσο και σε Secrets, για προσάρτηση στα pods σας κατά το χρόνο\nεκτέλεσης. Για να βοηθήσουμε σε αυτό, παρέχουμε μερικές βοηθητικές μεθόδους\nστον τύπο `Files`.\n\nΓια καλύτερη οργάνωση, είναι ιδιαίτερα χρήσιμο να χρησιμοποιείτε αυτές τις\nμεθόδους σε συνδυασμό με τη μέθοδο `Glob`.\n\nΔεδομένης της δομής καταλόγου από το παράδειγμα [Glob](#glob-patterns) παραπάνω:\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Κωδικοποίηση {#encoding}\n\nΜπορείτε να εισάγετε ένα αρχείο και να το κωδικοποιήσετε σε base-64 από το\ntemplate για να εξασφαλίσετε τη σωστή μεταφορά:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nΤο παραπάνω θα πάρει το ίδιο αρχείο `config1.toml` που χρησιμοποιήσαμε πριν\nκαι θα το κωδικοποιήσει:\n\n```yaml\n# Source: mychart/templates/secret.yaml {#source-mycharttemplatessecretyaml}\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Γραμμές {#lines}\n\nΜερικές φορές είναι επιθυμητό να προσπελάσετε κάθε γραμμή ενός αρχείου στο\ntemplate σας. Παρέχουμε μια βολική μέθοδο `Lines` για αυτό.\n\nΜπορείτε να επαναλάβετε μέσω του `Lines` χρησιμοποιώντας μια συνάρτηση `range`:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nΔεν υπάρχει τρόπος να περάσετε αρχεία εξωτερικά του chart κατά τη διάρκεια του\n`helm install`. Επομένως, αν ζητάτε από τους χρήστες να παρέχουν δεδομένα,\nπρέπει να φορτωθούν χρησιμοποιώντας `helm install -f` ή `helm install --set`.\n\nΑυτή η συζήτηση ολοκληρώνει την εμβάθυνσή μας στα εργαλεία και τις τεχνικές για\nτη συγγραφή Helm templates. Στην επόμενη ενότητα θα δούμε πώς μπορείτε να\nχρησιμοποιήσετε ένα ειδικό αρχείο, το `templates/NOTES.txt`, για να στείλετε\nοδηγίες μετά την εγκατάσταση στους χρήστες του chart σας.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Ενσωματωμένα Αντικείμενα\ndescription: Τα ενσωματωμένα αντικείμενα που είναι διαθέσιμα στα templates.\nsidebar_position: 3\n---\n\nΤα αντικείμενα μεταβιβάζονται σε ένα template από τη μηχανή template. Ο κώδικάς\nσας μπορεί να μεταβιβάζει αντικείμενα (θα δούμε παραδείγματα όταν εξετάσουμε τις\nδηλώσεις `with` και `range`). Υπάρχουν ακόμη και μερικοί τρόποι για να\nδημιουργήσετε νέα αντικείμενα μέσα στα templates σας, όπως με τη συνάρτηση\n`tuple` που θα δούμε αργότερα.\n\nΤα αντικείμενα μπορεί να είναι απλά, με μία μόνο τιμή. Ή μπορεί να περιέχουν\nάλλα αντικείμενα ή συναρτήσεις. Για παράδειγμα, το αντικείμενο `Release`\nπεριέχει πολλά αντικείμενα (όπως το `Release.Name`) και το αντικείμενο `Files`\nέχει μερικές συναρτήσεις.\n\nΣτην προηγούμενη ενότητα, χρησιμοποιήσαμε το `{{ .Release.Name }}` για να\nεισάγουμε το όνομα ενός release σε ένα template. Το `Release` είναι ένα από τα\nαντικείμενα ανώτατου επιπέδου στα οποία μπορείτε να έχετε πρόσβαση στα templates\nσας.\n\n- `Release`: Αυτό το αντικείμενο περιγράφει το ίδιο το release. Περιέχει πολλά\n  αντικείμενα:\n  - `Release.Name`: Το όνομα του release\n  - `Release.Namespace`: Το namespace στο οποίο θα γίνει η εγκατάσταση (αν το\n    manifest δεν το παρακάμπτει)\n  - `Release.IsUpgrade`: Ορίζεται σε `true` αν η τρέχουσα λειτουργία είναι\n    upgrade ή rollback.\n  - `Release.IsInstall`: Ορίζεται σε `true` αν η τρέχουσα λειτουργία είναι\n    εγκατάσταση.\n  - `Release.Revision`: Ο αριθμός αναθεώρησης για αυτό το release. Κατά την\n    εγκατάσταση είναι 1 και αυξάνεται με κάθε upgrade και rollback.\n  - `Release.Service`: Η υπηρεσία που αποδίδει το τρέχον template. Στο Helm,\n    αυτό είναι πάντα `Helm`.\n- `Values`: Οι τιμές που μεταβιβάζονται στο template από το αρχείο `values.yaml`\n  και από αρχεία που παρέχει ο χρήστης. Από προεπιλογή, το `Values` είναι κενό.\n- `Chart`: Τα περιεχόμενα του αρχείου `Chart.yaml`. Οποιαδήποτε δεδομένα στο\n  `Chart.yaml` είναι προσβάσιμα εδώ. Για παράδειγμα, το\n  `{{ .Chart.Name }}-{{ .Chart.Version }}` θα εκτυπώσει `mychart-0.1.0`.\n  - Τα διαθέσιμα πεδία παρατίθενται στον [Οδηγό Charts](/topics/charts.md#the-chartyaml-file)\n- `Subcharts`: Παρέχει πρόσβαση στο εύρος (.Values, .Charts, .Releases κλπ.)\n  των subcharts από το γονικό chart. Για παράδειγμα, το\n  `.Subcharts.mySubChart.myValue` για πρόσβαση στο `myValue` του chart\n  `mySubChart`.\n- `Files`: Παρέχει πρόσβαση σε όλα τα μη ειδικά αρχεία σε ένα chart. Δεν\n  μπορείτε να το χρησιμοποιήσετε για πρόσβαση σε templates, αλλά μπορείτε να το\n  χρησιμοποιήσετε για πρόσβαση σε άλλα αρχεία του chart. Δείτε την ενότητα\n  [Πρόσβαση σε Αρχεία](/chart_template_guide/accessing_files.md) για\n  περισσότερα.\n  - `Files.Get` είναι μια συνάρτηση για λήψη ενός αρχείου με βάση το όνομά του\n    (`.Files.Get config.ini`)\n  - `Files.GetBytes` είναι μια συνάρτηση για λήψη των περιεχομένων ενός αρχείου\n    ως πίνακα bytes αντί για string. Αυτό είναι χρήσιμο για πράγματα όπως\n    εικόνες.\n  - `Files.Glob` είναι μια συνάρτηση που επιστρέφει μια λίστα αρχείων των οποίων\n    τα ονόματα ταιριάζουν με το δοσμένο μοτίβο shell glob.\n  - `Files.Lines` είναι μια συνάρτηση που διαβάζει ένα αρχείο γραμμή προς\n    γραμμή. Αυτό είναι χρήσιμο για επανάληψη σε κάθε γραμμή ενός αρχείου.\n  - `Files.AsSecrets` είναι μια συνάρτηση που επιστρέφει τα περιεχόμενα των\n    αρχείων ως strings κωδικοποιημένα σε Base 64.\n  - `Files.AsConfig` είναι μια συνάρτηση που επιστρέφει τα περιεχόμενα των\n    αρχείων ως YAML map.\n- `Capabilities`: Παρέχει πληροφορίες σχετικά με τις δυνατότητες που υποστηρίζει\n  το Kubernetes cluster.\n  - `Capabilities.APIVersions` είναι ένα σύνολο εκδόσεων.\n  - `Capabilities.APIVersions.Has $version` υποδεικνύει αν μια έκδοση (π.χ.\n    `batch/v1`) ή ένας πόρος (π.χ. `apps/v1/Deployment`) είναι διαθέσιμος στο\n    cluster.\n  - `Capabilities.KubeVersion` και `Capabilities.KubeVersion.Version` είναι η\n    έκδοση του Kubernetes.\n  - `Capabilities.KubeVersion.Major` είναι η κύρια έκδοση του Kubernetes.\n  - `Capabilities.KubeVersion.Minor` είναι η δευτερεύουσα έκδοση του Kubernetes.\n  - `Capabilities.HelmVersion` είναι το αντικείμενο που περιέχει τις\n    λεπτομέρειες της έκδοσης Helm, ίδια έξοδος με την εντολή `helm version`.\n  - `Capabilities.HelmVersion.Version` είναι η τρέχουσα έκδοση Helm σε μορφή\n    semver.\n  - `Capabilities.HelmVersion.GitCommit` είναι το Helm git sha1.\n  - `Capabilities.HelmVersion.GitTreeState` είναι η κατάσταση του git tree του\n    Helm.\n  - `Capabilities.HelmVersion.GoVersion` είναι η έκδοση του μεταγλωττιστή Go που\n    χρησιμοποιήθηκε.\n- `Template`: Περιέχει πληροφορίες σχετικά με το τρέχον template που εκτελείται\n  - `Template.Name`: Η διαδρομή αρχείου με namespace προς το τρέχον template\n    (π.χ. `mychart/templates/mytemplate.yaml`)\n  - `Template.BasePath`: Η διαδρομή με namespace προς τον κατάλογο templates του\n    τρέχοντος chart (π.χ. `mychart/templates`).\n\nΤα ενσωματωμένα αντικείμενα ξεκινούν πάντα με κεφαλαίο γράμμα. Αυτό ακολουθεί\nτη σύμβαση ονομασίας της Go. Όταν δημιουργείτε τα δικά σας ονόματα, είστε\nελεύθεροι να χρησιμοποιήσετε μια σύμβαση που ταιριάζει στην ομάδα σας. Ορισμένες\nομάδες, όπως πολλές από αυτές των οποίων τα charts μπορείτε να δείτε στο\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0), επιλέγουν να\nχρησιμοποιούν μόνο αρχικά πεζά γράμματα για να διακρίνουν τα τοπικά ονόματα από\nτα ενσωματωμένα. Σε αυτόν τον οδηγό, ακολουθούμε αυτή τη σύμβαση.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Έλεγχος Ροής\ndescription: Μια γρήγορη επισκόπηση της δομής ροής στα templates.\nsidebar_position: 7\n---\n\nΟι δομές ελέγχου (που ονομάζονται «actions» στην ορολογία των templates) σας\nδίνουν τη δυνατότητα να ελέγχετε τη ροή παραγωγής ενός template. Η γλώσσα\ntemplate του Helm παρέχει τις ακόλουθες δομές ελέγχου:\n\n- `if`/`else` για τη δημιουργία blocks υπό συνθήκη\n- `with` για τον καθορισμό εύρους (scope)\n- `range`, που παρέχει έναν βρόχο τύπου «for each»\n\nΕπιπλέον, παρέχει μερικές ενέργειες για τη δήλωση και χρήση ονομασμένων\nτμημάτων template:\n\n- `define` δηλώνει ένα νέο ονομασμένο template μέσα στο template σας\n- `template` εισάγει ένα ονομασμένο template\n- `block` δηλώνει έναν ειδικό τύπο περιοχής template που μπορεί να συμπληρωθεί\n\nΣε αυτήν την ενότητα, θα μιλήσουμε για τα `if`, `with` και `range`. Τα υπόλοιπα\nκαλύπτονται στην ενότητα «Ονομασμένα Templates» αργότερα σε αυτόν τον οδηγό.\n\n## If/Else {#ifelse}\n\nΗ πρώτη δομή ελέγχου που θα εξετάσουμε είναι για τη συμπερίληψη blocks κειμένου\nυπό συνθήκη σε ένα template. Πρόκειται για το block `if`/`else`.\n\nΗ βασική δομή για μια συνθήκη έχει την εξής μορφή:\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\nΠαρατηρήστε ότι τώρα μιλάμε για _pipelines_ αντί για τιμές. Ο λόγος είναι\nνα γίνει σαφές ότι οι δομές ελέγχου μπορούν να εκτελέσουν ένα ολόκληρο\npipeline, όχι απλά να αξιολογήσουν μια τιμή.\n\nΈνα pipeline αξιολογείται ως _false_ αν η τιμή είναι:\n\n- boolean false\n- αριθμητικό μηδέν\n- κενό string\n- `nil` (κενό ή null)\n- κενή συλλογή (`map`, `slice`, `tuple`, `dict`, `array`)\n\nΣε όλες τις άλλες περιπτώσεις, η συνθήκη είναι true.\n\nΑς προσθέσουμε μια απλή συνθήκη στο ConfigMap μας. Θα προσθέσουμε μια ακόμη\nρύθμιση αν το drink έχει οριστεί σε coffee:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nΕπειδή σχολιάσαμε το `drink: coffee` στο προηγούμενο παράδειγμά μας, η έξοδος\nδεν θα πρέπει να περιλαμβάνει τη σημαία `mug: \"true\"`. Αλλά αν προσθέσουμε\nξανά αυτή τη γραμμή στο αρχείο `values.yaml`, η έξοδος θα πρέπει να μοιάζει\nμε αυτό:\n\n```yaml\n# Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Έλεγχος Κενών Χαρακτήρων {#controlling-whitespace}\n\nΕνώ εξετάζουμε τις συνθήκες, ας δούμε γρήγορα πώς ελέγχονται οι κενοί\nχαρακτήρες (whitespace) στα templates. Ας πάρουμε το προηγούμενο παράδειγμα\nκαι ας το μορφοποιήσουμε για να είναι πιο ευανάγνωστο:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nΑρχικά, αυτό φαίνεται καλό. Αλλά αν το περάσουμε από τη μηχανή template, θα\nπάρουμε ένα ατυχές αποτέλεσμα:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nΤι συνέβη; Δημιουργήσαμε λανθασμένο YAML λόγω των κενών χαρακτήρων παραπάνω.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\nΤο `mug` έχει λανθασμένη εσοχή. Ας αφαιρέσουμε απλά την εσοχή από αυτή τη\nγραμμή και ας ξανατρέξουμε:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nΌταν το στείλουμε, θα πάρουμε YAML που είναι έγκυρο, αλλά εξακολουθεί να\nφαίνεται λίγο περίεργο:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nΠαρατηρήστε ότι πήραμε μερικές κενές γραμμές στο YAML μας. Γιατί; Όταν η μηχανή\ntemplate εκτελείται, _αφαιρεί_ τα περιεχόμενα μέσα από τα `{{` και `}}`, αλλά\nαφήνει τους υπόλοιπους κενούς χαρακτήρες ακριβώς όπως είναι.\n\nΤο YAML αποδίδει νόημα στους κενούς χαρακτήρες, οπότε η διαχείρισή τους\nγίνεται αρκετά σημαντική. Ευτυχώς, τα Helm templates έχουν μερικά εργαλεία\nγια να βοηθήσουν.\n\nΠρώτον, η σύνταξη με άγκιστρα των δηλώσεων template μπορεί να τροποποιηθεί\nμε ειδικούς χαρακτήρες για να ενημερώσει τη μηχανή template να «κόψει»\n(chomp) τους κενούς χαρακτήρες. Το `{{- ` (με παύλα και κενό) υποδεικνύει\nότι οι κενοί χαρακτήρες αριστερά πρέπει να αφαιρεθούν, ενώ το ` -}}`\nσημαίνει ότι οι κενοί χαρακτήρες δεξιά πρέπει να καταναλωθούν. _Προσοχή!\nΟι αλλαγές γραμμής (newlines) είναι κενοί χαρακτήρες!_\n\n> Βεβαιωθείτε ότι υπάρχει ένα κενό ανάμεσα στην `-` και το υπόλοιπο της\n> οδηγίας σας. Το `{{- 3 }}` σημαίνει «κόψε τους κενούς χαρακτήρες αριστερά\n> και τύπωσε 3», ενώ το `{{-3 }}` σημαίνει «τύπωσε -3».\n\nΧρησιμοποιώντας αυτή τη σύνταξη, μπορούμε να τροποποιήσουμε το template μας\nγια να απαλλαγούμε από αυτές τις νέες γραμμές:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nΓια να γίνει αυτό το σημείο ξεκάθαρο, ας προσαρμόσουμε τα παραπάνω και\nας αντικαταστήσουμε με ένα `*` κάθε κενό χαρακτήρα που θα διαγραφεί\nακολουθώντας αυτόν τον κανόνα. Ένα `*` στο τέλος της γραμμής υποδεικνύει\nέναν χαρακτήρα αλλαγής γραμμής που θα αφαιρεθεί\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nΈχοντας αυτό υπόψη, μπορούμε να περάσουμε το template μας μέσω του Helm και\nνα δούμε το αποτέλεσμα:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nΝα είστε προσεκτικοί με τους τροποποιητές κοπής (chomping modifiers). Είναι\nεύκολο να κάνετε κατά λάθος πράγματα όπως αυτό:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nΑυτό θα παράγει `food: \"PIZZA\"mug: \"true\"` επειδή κατανάλωσε τις αλλαγές\nγραμμής και στις δύο πλευρές.\n\n> Για λεπτομέρειες σχετικά με τον έλεγχο κενών χαρακτήρων στα templates, δείτε\n> την [Επίσημη τεκμηρίωση των Go templates](https://godoc.org/text/template)\n\nΤέλος, μερικές φορές είναι ευκολότερο να πείτε στο σύστημα template πώς να\nκάνει εσοχή για εσάς αντί να προσπαθείτε να κατακτήσετε τη διαστημάτωση των\nοδηγιών template. Για αυτόν τον λόγο, μπορεί να βρείτε χρήσιμο να\nχρησιμοποιήσετε τη συνάρτηση `indent` (`{{ indent 2 \"mug:true\" }}`).\n\n## Τροποποίηση εύρους με το `with` {#modifying-scope-using-with}\n\nΗ επόμενη δομή ελέγχου που θα εξετάσουμε είναι η ενέργεια `with`. Αυτή\nελέγχει το εύρος (scoping) των μεταβλητών. Θυμηθείτε ότι η `.` είναι μια\nαναφορά στο _τρέχον εύρος_. Έτσι, το `.Values` λέει στο template να βρει\nτο αντικείμενο `Values` στο τρέχον εύρος.\n\nΗ σύνταξη για το `with` είναι παρόμοια με μια απλή δήλωση `if`:\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\nΤα εύρη μπορούν να αλλάξουν. Το `with` μπορεί να σας επιτρέψει να ορίσετε\nτο τρέχον εύρος (`.`) σε ένα συγκεκριμένο αντικείμενο. Για παράδειγμα, έχουμε\nδουλέψει με το `.Values.favorite`. Ας ξαναγράψουμε το ConfigMap μας για να\nαλλάξουμε το εύρος της `.` ώστε να δείχνει στο `.Values.favorite`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nΣημειώστε ότι αφαιρέσαμε τη συνθήκη `if` από την προηγούμενη άσκηση επειδή\nδεν είναι πλέον απαραίτητη - το block μετά το `with` εκτελείται μόνο αν η\nτιμή του `PIPELINE` δεν είναι κενή.\n\nΠαρατηρήστε ότι τώρα μπορούμε να αναφερθούμε στα `.drink` και `.food` χωρίς\nνα τα προσδιορίσουμε πλήρως. Αυτό συμβαίνει επειδή η δήλωση `with` ορίζει\nτη `.` να δείχνει στο `.Values.favorite`. Η `.` επαναφέρεται στο προηγούμενο\nεύρος της μετά το `{{ end }}`.\n\nΑλλά εδώ υπάρχει μια προειδοποίηση! Μέσα στο περιορισμένο εύρος, δεν θα\nμπορείτε να έχετε πρόσβαση στα άλλα αντικείμενα από το γονικό εύρος\nχρησιμοποιώντας τη `.`. Αυτό, για παράδειγμα, θα αποτύχει:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nΘα παράγει σφάλμα επειδή το `Release.Name` δεν βρίσκεται μέσα στο περιορισμένο\nεύρος της `.`. Ωστόσο, αν εναλλάξουμε τις δύο τελευταίες γραμμές, όλα θα\nλειτουργήσουν όπως αναμένεται επειδή το εύρος επαναφέρεται μετά το `{{ end }}`.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nΉ, μπορούμε να χρησιμοποιήσουμε το `$` για πρόσβαση στο αντικείμενο\n`Release.Name` από το γονικό εύρος. Το `$` αντιστοιχίζεται στο αρχικό (root)\nεύρος όταν ξεκινά η εκτέλεση του template και δεν αλλάζει κατά την εκτέλεση.\nΤο παρακάτω θα λειτουργούσε επίσης:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nΑφού δούμε το `range`, θα ρίξουμε μια ματιά στις μεταβλητές template, που\nπροσφέρουν μια λύση στο πρόβλημα εύρους παραπάνω.\n\n## Βρόχοι με την ενέργεια `range` {#looping-with-the-range-action}\n\nΠολλές γλώσσες προγραμματισμού υποστηρίζουν βρόχους με `for` loops, `foreach`\nloops ή παρόμοιους μηχανισμούς. Στη γλώσσα template του Helm, ο τρόπος για να\nεπαναλάβετε μια συλλογή είναι να χρησιμοποιήσετε τον τελεστή `range`.\n\nΓια να ξεκινήσουμε, ας προσθέσουμε μια λίστα με υλικά πίτσας στο αρχείο\n`values.yaml`:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nΤώρα έχουμε μια λίστα (που ονομάζεται `slice` στα templates) με `pizzaToppings`.\nΜπορούμε να τροποποιήσουμε το template μας για να εκτυπώσει αυτή τη λίστα\nστο ConfigMap μας:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nΜπορούμε να χρησιμοποιήσουμε το `$` για πρόσβαση στη λίστα `Values.pizzaToppings`\nαπό το γονικό εύρος. Το `$` αντιστοιχίζεται στο αρχικό (root) εύρος όταν ξεκινά\nη εκτέλεση του template και δεν αλλάζει κατά την εκτέλεση. Το παρακάτω θα\nλειτουργούσε επίσης:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nΑς δούμε πιο προσεκτικά τη λίστα `toppings:`. Η συνάρτηση `range` θα «διατρέξει»\n(επαναλάβει) τη λίστα `pizzaToppings`. Αλλά τώρα συμβαίνει κάτι ενδιαφέρον.\nΌπως ακριβώς το `with` ορίζει το εύρος της `.`, έτσι και ο τελεστής `range`.\nΚάθε φορά που περνάμε τον βρόχο, η `.` ορίζεται στο τρέχον υλικό πίτσας.\nΔηλαδή, την πρώτη φορά, η `.` ορίζεται σε `mushrooms`. Στη δεύτερη επανάληψη\nορίζεται σε `cheese`, και ούτω καθεξής.\n\nΜπορούμε να στείλουμε την τιμή της `.` απευθείας σε ένα pipeline, οπότε\nόταν κάνουμε `{{ . | title | quote }}`, στέλνει τη `.` στην `title` (συνάρτηση\nκεφαλαιοποίησης τίτλου) και στη συνέχεια στην `quote`. Αν εκτελέσουμε αυτό\nτο template, η έξοδος θα είναι:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nΣε αυτό το παράδειγμα κάναμε κάτι δύσκολο. Η γραμμή `toppings: |-` δηλώνει\nένα string πολλαπλών γραμμών. Επομένως, η λίστα υλικών μας δεν είναι στην\nπραγματικότητα μια λίστα YAML. Είναι ένα μεγάλο string. Γιατί να το κάνουμε\nαυτό; Επειδή τα δεδομένα στο `data` των ConfigMaps αποτελούνται από ζεύγη\nκλειδιού/τιμής, όπου τόσο το κλειδί όσο και η τιμή είναι απλά strings. Για\nνα καταλάβετε γιατί συμβαίνει αυτό, δείτε την\n[τεκμηρίωση Kubernetes ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/).\nΓια εμάς, όμως, αυτή η λεπτομέρεια δεν έχει μεγάλη σημασία.\n\n> Ο δείκτης `|-` στο YAML λαμβάνει ένα string πολλαπλών γραμμών. Αυτό μπορεί\n> να είναι μια χρήσιμη τεχνική για την ενσωμάτωση μεγάλων blocks δεδομένων\n> μέσα στα manifests σας, όπως φαίνεται εδώ.\n\nΜερικές φορές είναι χρήσιμο να μπορείτε να δημιουργήσετε γρήγορα μια λίστα\nμέσα στο template σας, και στη συνέχεια να επαναλάβετε αυτή τη λίστα. Τα\nHelm templates έχουν μια συνάρτηση για να το κάνουν εύκολο: την `tuple`. Στην\nεπιστήμη των υπολογιστών, μια tuple είναι μια συλλογή τύπου λίστας με\nσταθερό μέγεθος, αλλά με αυθαίρετους τύπους δεδομένων. Αυτό αποδίδει κατά\nπροσέγγιση τον τρόπο χρήσης της `tuple`.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nΤο παραπάνω θα παράγει:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nΕκτός από λίστες και tuples, το `range` μπορεί να χρησιμοποιηθεί για\nεπανάληψη πάνω σε συλλογές που έχουν κλειδί και τιμή (όπως ένα `map` ή\n`dict`). Θα δούμε πώς να το κάνουμε αυτό στην επόμενη ενότητα όταν\nεισαγάγουμε τις μεταβλητές template.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Παράρτημα: Τύποι Δεδομένων της Go και Templates\"\ndescription: Μια σύντομη επισκόπηση των μεταβλητών στα templates.\nsidebar_position: 16\n---\n\nΗ γλώσσα template του Helm υλοποιείται στην αυστηρά τυποποιημένη γλώσσα\nπρογραμματισμού Go. Για αυτόν τον λόγο, οι μεταβλητές στα templates είναι\n_τυποποιημένες_. Συνήθως, οι μεταβλητές θα εκτίθενται ως ένας από τους\nπαρακάτω τύπους:\n\n- string: Συμβολοσειρά κειμένου\n- bool: Τιμή `true` ή `false`\n- int: Ακέραια τιμή (υπάρχουν επίσης παραλλαγές 8, 16, 32 και 64 bit,\n  προσημασμένες και μη)\n- float64: Τιμή κινητής υποδιαστολής 64 bit (υπάρχουν επίσης παραλλαγές\n  8, 16 και 32 bit)\n- byte slice (`[]byte`): Χρησιμοποιείται συχνά για (ενδεχομένως) δυαδικά\n  δεδομένα\n- struct: Αντικείμενο με ιδιότητες και μεθόδους\n- slice (ευρετηριασμένη λίστα) ενός από τους προηγούμενους τύπους\n- map με κλειδιά τύπου string (`map[string]interface{}`) όπου η τιμή είναι\n  ένας από τους προηγούμενους τύπους\n\nΥπάρχουν πολλοί άλλοι τύποι στη Go, και μερικές φορές θα χρειαστεί να τους\nμετατρέπετε στα templates σας. Ο ευκολότερος τρόπος για να κάνετε debug τον\nτύπο ενός αντικειμένου είναι να το περάσετε μέσω του `printf \"%T\"` σε ένα\ntemplate, το οποίο θα εκτυπώσει τον τύπο. Δείτε επίσης τις συναρτήσεις\n`typeOf` και `kindOf`.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: Αποσφαλμάτωση Templates\ndescription: Αντιμετώπιση προβλημάτων σε charts που αποτυγχάνουν να εγκατασταθούν.\nsidebar_position: 13\n---\n\nΗ αποσφαλμάτωση των templates μπορεί να αποδειχθεί δύσκολη, καθώς τα\nαποδομημένα templates αποστέλλονται στον Kubernetes API server, ο οποίος\nμπορεί να απορρίψει τα αρχεία YAML για λόγους που δεν σχετίζονται με τη\nμορφοποίηση.\n\nΥπάρχουν μερικές εντολές που μπορούν να σας βοηθήσουν στην αποσφαλμάτωση.\n\n- Η `helm lint` είναι το κύριο εργαλείο σας για να επαληθεύσετε ότι το chart\n  σας ακολουθεί βέλτιστες πρακτικές\n- Η `helm template --debug` θα δοκιμάσει την απόδοση των chart templates τοπικά.\n- Η `helm install --dry-run --debug` θα αποδώσει επίσης το chart σας τοπικά\n  χωρίς να το εγκαταστήσει, αλλά θα ελέγξει επίσης αν υπάρχουν συγκρουόμενοι\n  πόροι ήδη εκτελούμενοι στο cluster. Με τη ρύθμιση `--dry-run=server` θα\n  εκτελεστεί επιπλέον οποιοδήποτε `lookup` στο chart σας προς τον server.\n- `helm get manifest`: Αυτός είναι ένας καλός τρόπος για να δείτε ποια\n  templates είναι εγκατεστημένα στον server.\n\nΌταν το YAML σας αποτυγχάνει να αναλυθεί (parse), αλλά θέλετε να δείτε τι\nπαράγεται, ένας εύκολος τρόπος να ανακτήσετε το YAML είναι να σχολιάσετε\nτην προβληματική ενότητα στο template και στη συνέχεια να εκτελέσετε ξανά\nτην `helm install --dry-run --debug`:\n\n```yaml\napiVersion: v2\n# some: problem section {#some-problem-section} {#some-problem-section} {#some-problem-section}\n# {{ .Values.foo | quote }} {#valuesfoo-quote}\n```\n\nΤο παραπάνω θα αποδοθεί και θα επιστραφεί με τα σχόλια ανέπαφα:\n\n```yaml\napiVersion: v2\n# some: problem section\n# \"bar\" {#bar}\n```\n\nΑυτό παρέχει έναν γρήγορο τρόπο προβολής του παραγόμενου περιεχομένου, χωρίς\nτα σφάλματα ανάλυσης YAML να εμποδίζουν τη διαδικασία.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: Συναρτήσεις Template και Pipelines\ndescription: Χρήση συναρτήσεων στα templates.\nsidebar_position: 5\n---\n\nΜέχρι τώρα, έχουμε δει πώς να τοποθετούμε πληροφορίες σε ένα template. Αλλά\nαυτές οι πληροφορίες τοποθετούνται στο template χωρίς τροποποίηση. Μερικές\nφορές θέλουμε να μετασχηματίσουμε τα παρεχόμενα δεδομένα με τρόπο που να μας\nείναι πιο χρήσιμα.\n\nΑς ξεκινήσουμε με μια καλή πρακτική: Όταν εισάγουμε strings από το αντικείμενο\n`.Values` στο template, θα πρέπει να τα περικλείουμε σε εισαγωγικά. Μπορούμε να\nτο κάνουμε αυτό καλώντας τη συνάρτηση `quote` στην οδηγία του template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nΟι συναρτήσεις template ακολουθούν τη σύνταξη `functionName arg1 arg2...`. Στο\nπαραπάνω απόσπασμα, η `quote .Values.favorite.drink` καλεί τη συνάρτηση `quote`\nκαι της περνάει ένα μόνο όρισμα.\n\nΤο Helm διαθέτει περισσότερες από 60 συναρτήσεις. Μερικές από αυτές ορίζονται\nαπό την ίδια τη [γλώσσα template της Go](https://godoc.org/text/template). Οι\nπερισσότερες από τις υπόλοιπες είναι μέρος της [βιβλιοθήκης Sprig\ntemplate](https://masterminds.github.io/sprig/). Θα δούμε πολλές από αυτές\nκαθώς προχωράμε στα παραδείγματα.\n\n> Ενώ μιλάμε για τη «γλώσσα template του Helm» σαν να είναι συγκεκριμένη για το\n> Helm, στην πραγματικότητα είναι ένας συνδυασμός της γλώσσας template της Go,\n> μερικών επιπλέον συναρτήσεων και διάφορων wrappers για την έκθεση\n> συγκεκριμένων αντικειμένων στα templates. Πολλοί πόροι για τα Go templates\n> μπορεί να είναι χρήσιμοι καθώς μαθαίνετε για τη δημιουργία templates.\n\n## Pipelines {#pipelines}\n\nΈνα από τα ισχυρά χαρακτηριστικά της γλώσσας template είναι η έννοια των\n_pipelines_. Βασιζόμενοι σε μια ιδέα από το UNIX, τα pipelines είναι ένα\nεργαλείο για την αλυσίδωση μιας σειράς εντολών template ώστε να εκφράσουμε\nσυνοπτικά μια σειρά μετασχηματισμών. Με άλλα λόγια, τα pipelines είναι ένας\nαποδοτικός τρόπος για να κάνουμε πολλά πράγματα διαδοχικά. Ας ξαναγράψουμε το\nπαραπάνω παράδειγμα χρησιμοποιώντας ένα pipeline.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nΣε αυτό το παράδειγμα, αντί να καλέσουμε `quote ARGUMENT`, αντιστρέψαμε τη\nσειρά. «Στείλαμε» το όρισμα στη συνάρτηση χρησιμοποιώντας ένα pipeline (`|`):\n`.Values.favorite.drink | quote`. Χρησιμοποιώντας pipelines, μπορούμε να\nαλυσιδώσουμε πολλές συναρτήσεις μαζί:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Η αντιστροφή της σειράς είναι μια συνήθης πρακτική στα templates. Θα δείτε\n> πιο συχνά `.val | quote` παρά `quote .val`. Και οι δύο τρόποι είναι αποδεκτοί.\n\nΌταν αξιολογηθεί, αυτό το template θα παράγει:\n\n```yaml\n# Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nΠαρατηρήστε ότι το αρχικό μας `pizza` έχει μετατραπεί τώρα σε `\"PIZZA\"`.\n\nΌταν περνάμε ορίσματα με pipeline, το αποτέλεσμα της πρώτης αξιολόγησης\n(`.Values.favorite.drink`) στέλνεται ως _τελευταίο όρισμα στη συνάρτηση_.\nΜπορούμε να τροποποιήσουμε το παράδειγμα με το ποτό παραπάνω για να δείξουμε\nμια συνάρτηση που δέχεται δύο ορίσματα: `repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nΗ συνάρτηση `repeat` θα επαναλάβει το δοσμένο string τον καθορισμένο αριθμό\nφορών, οπότε θα λάβουμε αυτό ως έξοδο:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Χρήση της συνάρτησης `default` {#using-the-default-function}\n\nΜια συνάρτηση που χρησιμοποιείται συχνά στα templates είναι η `default`:\n`default DEFAULT_VALUE GIVEN_VALUE`. Αυτή η συνάρτηση σας επιτρέπει να ορίσετε\nμια προεπιλεγμένη τιμή μέσα στο template, σε περίπτωση που η τιμή παραλείπεται.\nΑς τη χρησιμοποιήσουμε για να τροποποιήσουμε το παράδειγμα με το ποτό παραπάνω:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nΑν το εκτελέσουμε κανονικά, θα πάρουμε τον `coffee` μας:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nΤώρα, θα αφαιρέσουμε τη ρύθμιση για το αγαπημένο ποτό από το `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nΤώρα η εκ νέου εκτέλεση της `helm install --dry-run --debug fair-worm ./mychart`\nθα παράγει αυτό το YAML:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nΣε ένα πραγματικό chart, όλες οι στατικές προεπιλεγμένες τιμές πρέπει να\nβρίσκονται στο `values.yaml` και δεν πρέπει να επαναλαμβάνονται με την εντολή\n`default` (διαφορετικά θα ήταν περιττές). Ωστόσο, η εντολή `default` είναι\nιδανική για υπολογιζόμενες τιμές, οι οποίες δεν μπορούν να δηλωθούν μέσα στο\n`values.yaml`. Για παράδειγμα:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nΣε κάποια σημεία, μια συνθήκη `if` μπορεί να είναι πιο κατάλληλη από τη\n`default`. Θα δούμε αυτές στην επόμενη ενότητα.\n\nΟι συναρτήσεις και τα pipelines των templates είναι ένας ισχυρός τρόπος για να\nμετασχηματίσετε πληροφορίες και στη συνέχεια να τις εισάγετε στο YAML σας. Αλλά\nμερικές φορές είναι απαραίτητο να προσθέσουμε κάποια λογική template που είναι\nλίγο πιο εξελιγμένη από την απλή εισαγωγή ενός string. Στην επόμενη ενότητα θα\nεξετάσουμε τις δομές ελέγχου που παρέχει η γλώσσα template.\n\n## Χρήση της συνάρτησης `lookup` {#using-the-lookup-function}\n\nΗ συνάρτηση `lookup` μπορεί να χρησιμοποιηθεί για να _αναζητήσει_ resources σε\nένα cluster που εκτελείται. Η σύνοψη της συνάρτησης lookup είναι\n`lookup apiVersion, kind, namespace, name -> resource or resource list`.\n\n| παράμετρος | τύπος  |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\nΤόσο το `name` όσο και το `namespace` είναι προαιρετικά και μπορούν να περαστούν\nως κενό string (`\"\"`). Ωστόσο, αν εργάζεστε με ένα resource που ανήκει σε\nnamespace, πρέπει να καθοριστούν και τα δύο, το `name` και το `namespace`.\n\nΟι ακόλουθοι συνδυασμοί παραμέτρων είναι δυνατοί:\n\n| Συμπεριφορά                            | Συνάρτηση lookup                           |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\nΌταν η `lookup` επιστρέφει ένα αντικείμενο, θα επιστρέψει ένα dictionary. Αυτό\nτο dictionary μπορεί να πλοηγηθεί περαιτέρω για να εξαχθούν συγκεκριμένες τιμές.\n\nΤο ακόλουθο παράδειγμα θα επιστρέψει τα annotations που υπάρχουν για το\nαντικείμενο `mynamespace`:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nΌταν η `lookup` επιστρέφει μια λίστα αντικειμένων, είναι δυνατή η πρόσβαση στη\nλίστα αντικειμένων μέσω του πεδίου `items`:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* do something with each service */}}\n{{ end }}\n```\n\nΌταν δεν βρεθεί κανένα αντικείμενο, επιστρέφεται μια κενή τιμή. Αυτό μπορεί να\nχρησιμοποιηθεί για τον έλεγχο ύπαρξης ενός αντικειμένου.\n\nΗ συνάρτηση `lookup` χρησιμοποιεί την υπάρχουσα ρύθμιση σύνδεσης Kubernetes του\nHelm για να κάνει ερωτήματα στο Kubernetes. Αν επιστραφεί οποιοδήποτε σφάλμα\nκατά την αλληλεπίδραση με τον API server (για παράδειγμα λόγω έλλειψης\nδικαιωμάτων πρόσβασης σε ένα resource), η επεξεργασία template του Helm θα\nαποτύχει.\n\nΝα έχετε υπόψη ότι το Helm δεν πρέπει να επικοινωνεί με τον Kubernetes API\nServer κατά τη διάρκεια μιας λειτουργίας\n`helm template|install|upgrade|delete|rollback --dry-run`. Για να δοκιμάσετε\nτη `lookup` σε ένα cluster που εκτελείται, θα πρέπει να χρησιμοποιήσετε\n`helm template|install|upgrade|delete|rollback --dry-run=server` για να\nεπιτρέψετε τη σύνδεση με το cluster.\n\n## Οι τελεστές είναι συναρτήσεις {#operators-are-functions}\n\nΓια τα templates, οι τελεστές (`eq`, `ne`, `lt`, `gt`, `and`, `or` κ.λπ.)\nυλοποιούνται όλοι ως συναρτήσεις. Στα pipelines, οι πράξεις μπορούν να\nομαδοποιηθούν με παρενθέσεις (`(` και `)`).\n\nΤώρα μπορούμε να προχωρήσουμε από τις συναρτήσεις και τα pipelines στον έλεγχο\nροής με συνθήκες, βρόχους και τροποποιητές εύρους.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Ξεκινώντας\ndescription: Ένας γρήγορος οδηγός για τα Chart templates.\nsidebar_position: 2\n---\n\nΣε αυτήν την ενότητα του οδηγού, θα δημιουργήσουμε ένα chart και στη συνέχεια\nθα προσθέσουμε ένα πρώτο template. Το chart που θα δημιουργήσουμε εδώ θα\nχρησιμοποιηθεί σε όλο τον υπόλοιπο οδηγό.\n\nΓια να ξεκινήσουμε, ας ρίξουμε μια σύντομη ματιά σε ένα Helm chart.\n\n## Charts {#charts}\n\nΌπως περιγράφεται στον [Οδηγό Charts](/topics/charts.md), τα Helm charts έχουν\nτην εξής δομή:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nΟ κατάλογος `templates/` προορίζεται για αρχεία template. Όταν το Helm\nαξιολογεί ένα chart, στέλνει όλα τα αρχεία του καταλόγου `templates/` μέσω της\nμηχανής απόδοσης template. Στη συνέχεια συλλέγει τα αποτελέσματα αυτών των\ntemplates και τα στέλνει στο Kubernetes.\n\nΤο αρχείο `values.yaml` είναι επίσης σημαντικό για τα templates. Αυτό το αρχείο\nπεριέχει τις _προεπιλεγμένες τιμές_ για ένα chart. Αυτές οι τιμές μπορούν να\nπαρακαμφθούν από τους χρήστες κατά τη διάρκεια του `helm install` ή του\n`helm upgrade`.\n\nΤο αρχείο `Chart.yaml` περιέχει μια περιγραφή του chart. Μπορείτε να έχετε\nπρόσβαση σε αυτό μέσα από ένα template.\n\nΟ κατάλογος `charts/` _μπορεί_ να περιέχει άλλα charts (τα οποία ονομάζουμε\n_subcharts_). Αργότερα σε αυτόν τον οδηγό θα δούμε πώς λειτουργούν αυτά κατά\nτην απόδοση των templates.\n\n## Ένα Αρχικό Chart {#a-starter-chart}\n\nΓια αυτόν τον οδηγό, θα δημιουργήσουμε ένα απλό chart με το όνομα `mychart`,\nκαι στη συνέχεια θα δημιουργήσουμε μερικά templates μέσα σε αυτό.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### Μια Γρήγορη Ματιά στο `mychart/templates/` {#a-quick-glimpse-of-mycharttemplates}\n\nΑν ρίξετε μια ματιά στον κατάλογο `mychart/templates/`, θα παρατηρήσετε ότι\nυπάρχουν ήδη μερικά αρχεία.\n\n- `NOTES.txt`: Το «κείμενο βοήθειας» για το chart σας. Θα εμφανίζεται στους\n  χρήστες όταν εκτελούν την εντολή `helm install`.\n- `deployment.yaml`: Ένα βασικό manifest για τη δημιουργία ενός Kubernetes\n  [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n- `service.yaml`: Ένα βασικό manifest για τη δημιουργία ενός [service\n  endpoint](https://kubernetes.io/docs/concepts/services-networking/service/) για το deployment σας\n- `_helpers.tpl`: Ένα μέρος για να τοποθετήσετε template helpers που μπορείτε\n  να επαναχρησιμοποιήσετε σε όλο το chart\n\nΚαι αυτό που θα κάνουμε είναι... _να τα διαγράψουμε όλα!_ Με αυτόν τον τρόπο\nμπορούμε να δουλέψουμε τον οδηγό από την αρχή. Θα δημιουργήσουμε στην\nπραγματικότητα τα δικά μας `NOTES.txt` και `_helpers.tpl` καθώς προχωράμε.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nΌταν γράφετε charts για παραγωγή, η ύπαρξη βασικών εκδόσεων αυτών των αρχείων\nμπορεί να είναι πραγματικά χρήσιμη. Επομένως, στην καθημερινή δημιουργία charts,\nπιθανότατα δεν θα θέλετε να τα διαγράψετε.\n\n## Ένα Πρώτο Template {#a-first-template}\n\nΤο πρώτο template που θα δημιουργήσουμε θα είναι ένα `ConfigMap`. Στο\nKubernetes, ένα ConfigMap είναι απλά ένα αντικείμενο για την αποθήκευση\nδεδομένων ρύθμισης. Άλλα στοιχεία, όπως τα pods, μπορούν να έχουν πρόσβαση\nστα δεδομένα ενός ConfigMap.\n\nΕπειδή τα ConfigMaps είναι βασικοί πόροι, αποτελούν ένα εξαιρετικό σημείο\nεκκίνησης για εμάς.\n\nΑς ξεκινήσουμε δημιουργώντας ένα αρχείο με το όνομα\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**ΣΥΜΒΟΥΛΗ:** Τα ονόματα των templates δεν ακολουθούν ένα αυστηρό πρότυπο\nονοματολογίας. Ωστόσο, συνιστούμε τη χρήση της επέκτασης `.yaml` για αρχεία\nYAML και `.tpl` για helpers.\n\nΤο παραπάνω αρχείο YAML είναι ένα ConfigMap με τα ελάχιστα απαραίτητα πεδία.\nΛόγω του ότι αυτό το αρχείο βρίσκεται στον κατάλογο `mychart/templates/`, θα\nπεράσει από τη μηχανή template.\n\nΕίναι απολύτως αποδεκτό να τοποθετήσετε ένα απλό αρχείο YAML όπως αυτό στον\nκατάλογο `mychart/templates/`. Όταν το Helm διαβάζει αυτό το template, απλά\nτο στέλνει στο Kubernetes ως έχει.\n\nΜε αυτό το απλό template, έχουμε τώρα ένα chart που μπορεί να εγκατασταθεί.\nΚαι μπορούμε να το εγκαταστήσουμε ως εξής:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nΧρησιμοποιώντας το Helm, μπορούμε να ανακτήσουμε το release και να δούμε το\nπραγματικό template που φορτώθηκε.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nΗ εντολή `helm get manifest` παίρνει ένα όνομα release (`full-coral`) και\nεκτυπώνει όλους τους πόρους Kubernetes που ανέβηκαν στον server. Κάθε αρχείο\nξεκινά με `---` για να υποδείξει την αρχή ενός εγγράφου YAML, και ακολουθεί\nμια αυτόματα παραγόμενη γραμμή σχολίου που μας λέει ποιο αρχείο template\nδημιούργησε αυτό το έγγραφο YAML.\n\nΑπό εκεί και πέρα, μπορούμε να δούμε ότι τα δεδομένα YAML είναι ακριβώς αυτά\nπου βάλαμε στο αρχείο `configmap.yaml`.\n\nΤώρα μπορούμε να απεγκαταστήσουμε το release: `helm uninstall full-coral`.\n\n### Προσθήκη μιας Απλής Κλήσης Template {#adding-a-simple-template-call}\n\nΗ σκληρή κωδικοποίηση του `name:` σε έναν πόρο θεωρείται γενικά κακή πρακτική.\nΤα ονόματα πρέπει να είναι μοναδικά για κάθε release. Επομένως, μπορεί να\nθέλουμε να δημιουργήσουμε ένα πεδίο name εισάγοντας το όνομα του release.\n\n**ΣΥΜΒΟΥΛΗ:** Το πεδίο `name:` περιορίζεται σε 63 χαρακτήρες λόγω περιορισμών\nτου συστήματος DNS. Για αυτόν τον λόγο, τα ονόματα release περιορίζονται σε\n53 χαρακτήρες. Το Kubernetes 1.3 και παλαιότερες εκδόσεις περιορίζονταν σε\nμόνο 24 χαρακτήρες (άρα 14 χαρακτήρες για τα ονόματα).\n\nΑς τροποποιήσουμε το `configmap.yaml` ανάλογα.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nΗ μεγάλη αλλαγή έρχεται στην τιμή του πεδίου `name:`, η οποία είναι τώρα\n`{{ .Release.Name }}-configmap`.\n\n> Μια οδηγία template περικλείεται σε blocks `{{` και `}}`.\n\nΗ οδηγία template `{{ .Release.Name }}` εισάγει το όνομα του release στο\ntemplate. Οι τιμές που περνούν σε ένα template μπορούν να θεωρηθούν ως\n_αντικείμενα οργανωμένα σε namespaces_, όπου μια τελεία (`.`) διαχωρίζει κάθε\nnamespace.\n\nΗ αρχική τελεία πριν από το `Release` υποδεικνύει ότι ξεκινάμε από το ανώτατο\nnamespace για αυτό το εύρος (scope) (θα μιλήσουμε για το εύρος αργότερα).\nΕπομένως, μπορούμε να διαβάσουμε το `.Release.Name` ως «ξεκίνα από\nτο ανώτατο namespace, βρες το αντικείμενο `Release`, και μετά ψάξε μέσα του\nγια ένα αντικείμενο με το όνομα `Name`».\n\nΤο αντικείμενο `Release` είναι ένα από τα ενσωματωμένα αντικείμενα του Helm,\nκαι θα το καλύψουμε πιο αναλυτικά αργότερα. Αλλά προς το παρόν, αρκεί να\nπούμε ότι αυτό θα εμφανίσει το όνομα release που η βιβλιοθήκη αναθέτει στο\nrelease μας.\n\nΤώρα, όταν εγκαταστήσουμε τον πόρο μας, θα δούμε αμέσως το αποτέλεσμα της\nχρήσης αυτής της οδηγίας template:\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nΜπορείτε να εκτελέσετε `helm get manifest clunky-serval` για να δείτε ολόκληρο\nτο παραγόμενο YAML.\n\nΠαρατηρήστε ότι το ConfigMap μέσα στο Kubernetes έχει όνομα\n`clunky-serval-configmap` αντί για `mychart-configmap` που είχε προηγουμένως.\n\nΣε αυτό το σημείο, έχουμε δει τα templates στην πιο βασική τους μορφή: αρχεία\nYAML που έχουν οδηγίες template ενσωματωμένες σε `{{` και `}}`. Στο επόμενο\nμέρος, θα ρίξουμε μια πιο βαθιά ματιά στα templates. Αλλά πριν προχωρήσουμε,\nυπάρχει ένα γρήγορο κόλπο που μπορεί να κάνει τη δημιουργία templates πιο\nγρήγορη: Όταν θέλετε να δοκιμάσετε την απόδοση του template, αλλά όχι να\nεγκαταστήσετε πραγματικά κάτι, μπορείτε να χρησιμοποιήσετε `helm install --debug\n--dry-run goodly-guppy ./mychart`. Αυτό θα αποδώσει τα templates. Αλλά αντί να\nεγκαταστήσει το chart, θα επιστρέψει το αποδοθέν template σε εσάς ώστε να\nδείτε την έξοδο:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nΗ χρήση του `--dry-run` θα διευκολύνει τον έλεγχο του κώδικά σας, αλλά δεν θα\nεξασφαλίσει ότι το ίδιο το Kubernetes θα αποδεχτεί τα templates που παράγετε.\nΕίναι καλύτερο να μην υποθέτετε ότι το chart σας θα εγκατασταθεί μόνο και\nμόνο επειδή το `--dry-run` λειτουργεί.\n\nΣτον [Οδηγό Chart Template](/chart_template_guide/index.mdx), παίρνουμε το\nβασικό chart που ορίσαμε εδώ και εξερευνούμε τη γλώσσα template του Helm\nαναλυτικά. Και θα ξεκινήσουμε με τα ενσωματωμένα αντικείμενα.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: Το αρχείο .helmignore\ndescription: Το αρχείο `.helmignore` χρησιμοποιείται για τον καθορισμό αρχείων που δεν θέλετε να συμπεριλάβετε στο helm chart σας.\nsidebar_position: 12\n---\n\nΜε το αρχείο `.helmignore` καθορίζετε τα αρχεία που δεν θέλετε να\nσυμπεριλάβετε στο helm chart σας.\n\nΕάν υπάρχει αυτό το αρχείο, η εντολή `helm package` θα αγνοήσει όλα τα αρχεία\nπου ταιριάζουν με τα μοτίβα που καθορίζονται στο `.helmignore` κατά τη\nδημιουργία του πακέτου της εφαρμογής σας.\n\nΑυτό βοηθά στην αποφυγή προσθήκης περιττών ή ευαίσθητων αρχείων και καταλόγων\nστο helm chart σας.\n\nΤο αρχείο `.helmignore` υποστηρίζει αντιστοίχιση μοτίβων Unix shell glob,\nαντιστοίχιση σχετικών διαδρομών και άρνηση (με πρόθεμα !). Λαμβάνεται υπόψη\nμόνο ένα μοτίβο ανά γραμμή.\n\nΑκολουθεί ένα παράδειγμα αρχείου `.helmignore`:\n\n```\n# comment {#comment}\n\n# Match any file or path named .helmignore {#match-any-file-or-path-named-helmignore}\n.helmignore\n\n# Match any file or path named .git {#match-any-file-or-path-named-git}\n.git\n\n# Match any text file {#match-any-text-file}\n*.txt\n\n# Match only directories named mydir {#match-only-directories-named-mydir}\nmydir/\n\n# Match only text files in the top-level directory {#match-only-text-files-in-the-top-level-directory}\n/*.txt\n\n# Match only the file foo.txt in the top-level directory {#match-only-the-file-footxt-in-the-top-level-directory}\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt {#match-any-file-named-abtxt-actxt-or-adtxt}\na[b-d].txt\n\n# Match any file under subdir matching temp* {#match-any-file-under-subdir-matching-temp}\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nΟρισμένες αξιοσημείωτες διαφορές από το .gitignore:\n- Η σύνταξη '**' δεν υποστηρίζεται.\n- Η βιβλιοθήκη globbing είναι η `filepath.Match` της Go, όχι η fnmatch(3)\n- Τα τελικά κενά αγνοούνται πάντα (δεν υπάρχει υποστηριζόμενη ακολουθία διαφυγής)\n- Δεν υπάρχει υποστήριξη για το '\\!' ως ειδική αρχική ακολουθία.\n- Το αρχείο δεν εξαιρεί τον εαυτό του από προεπιλογή· πρέπει να προσθέσετε ρητά μια καταχώρηση για το `.helmignore`\n\n\n**Θα εκτιμούσαμε τη βοήθειά σας** για τη βελτίωση αυτού του εγγράφου. Για να\nπροσθέσετε, διορθώσετε ή αφαιρέσετε πληροφορίες,\n[υποβάλετε ένα issue](https://github.com/helm/helm-www/issues) ή στείλτε μας ένα\npull request.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx",
    "content": "---\ntitle: Οδηγός Chart Template\nsidebar_position: 5\n---\n\n# Ο Οδηγός Ανάπτυξης Chart Template {#the-chart-template-developers-guide}\n\nΑυτός ο οδηγός παρέχει μια εισαγωγή στα templates των charts του Helm, με έμφαση\nστη γλώσσα template.\n\nΤα templates παράγουν αρχεία manifest, τα οποία είναι περιγραφές πόρων σε μορφή YAML\nπου μπορεί να κατανοήσει το Kubernetes. Θα δούμε πώς είναι δομημένα τα templates,\nπώς μπορούν να χρησιμοποιηθούν, πώς να γράφετε Go templates και πώς να κάνετε\nαποσφαλμάτωση της δουλειάς σας.\n\nΑυτός ο οδηγός επικεντρώνεται στις ακόλουθες έννοιες:\n\n- Η γλώσσα template του Helm\n- Χρήση values\n- Τεχνικές για εργασία με templates\n\nΑυτός ο οδηγός είναι προσανατολισμένος στην εκμάθηση των λεπτομερειών της γλώσσας\ntemplate του Helm. Άλλοι οδηγοί παρέχουν εισαγωγικό υλικό, παραδείγματα και βέλτιστες\nπρακτικές.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Ονομασμένα Templates\ndescription: Πώς να ορίζετε ονομασμένα templates.\nsidebar_position: 9\n---\n\nΉρθε η ώρα να ξεπεράσουμε τη χρήση ενός μόνο template και να αρχίσουμε να\nδημιουργούμε και άλλα. Σε αυτή την ενότητα θα δούμε πώς να ορίζουμε _ονομασμένα\ntemplates_ σε ένα αρχείο και πώς να τα χρησιμοποιούμε αλλού. Ένα _ονομασμένο\ntemplate_ (μερικές φορές αποκαλείται _partial_ ή _subtemplate_) είναι απλά ένα\ntemplate που ορίζεται μέσα σε ένα αρχείο και έχει ένα όνομα. Θα δούμε δύο\nτρόπους δημιουργίας τους και αρκετούς διαφορετικούς τρόπους χρήσης τους.\n\nΣτην ενότητα [Δομές Ελέγχου Ροής](./control_structures.md) παρουσιάσαμε τρεις\nενέργειες για τη δήλωση και διαχείριση templates: `define`, `template` και\n`block`. Σε αυτή την ενότητα θα καλύψουμε αυτές τις τρεις ενέργειες και επίσης\nθα παρουσιάσουμε μια ειδική συνάρτηση `include` που λειτουργεί παρόμοια με την\nενέργεια `template`.\n\nΜια σημαντική λεπτομέρεια που πρέπει να έχετε υπόψη όταν ονομάζετε templates:\n**τα ονόματα των templates είναι global**. Αν δηλώσετε δύο templates με το ίδιο\nόνομα, θα χρησιμοποιηθεί αυτό που φορτώθηκε τελευταίο. Επειδή τα templates στα\nsubcharts μεταγλωττίζονται μαζί με τα templates του ανώτερου επιπέδου, θα πρέπει\nνα είστε προσεκτικοί να ονομάζετε τα templates σας με _ονόματα ειδικά για το\nchart_.\n\nΜια δημοφιλής σύμβαση ονομασίας είναι να προσθέτετε ως πρόθεμα σε κάθε ορισμένο\ntemplate το όνομα του chart: `{{ define \"mychart.labels\" }}`. Χρησιμοποιώντας το\nσυγκεκριμένο όνομα του chart ως πρόθεμα, μπορούμε να αποφύγουμε τυχόν διενέξεις\nπου μπορεί να προκύψουν από δύο διαφορετικά charts που υλοποιούν templates με το\nίδιο όνομα.\n\nΑυτή η συμπεριφορά ισχύει επίσης για διαφορετικές εκδόσεις ενός chart. Αν έχετε\nτο `mychart` έκδοση `1.0.0` που ορίζει ένα template με έναν τρόπο, και ένα\n`mychart` έκδοση `2.0.0` που τροποποιεί το υπάρχον ονομασμένο template, θα\nχρησιμοποιηθεί αυτό που φορτώθηκε τελευταίο. Μπορείτε να αντιμετωπίσετε αυτό το\nπρόβλημα προσθέτοντας επίσης μια έκδοση στο όνομα του chart:\n`{{ define \"mychart.v1.labels\" }}` και `{{ define \"mychart.v2.labels\" }}`.\n\n## Partials και αρχεία `_` {#partials-and-_-files}\n\nΜέχρι στιγμής έχουμε χρησιμοποιήσει ένα αρχείο, και αυτό το αρχείο περιέχει ένα\nμόνο template. Όμως η γλώσσα template του Helm σας επιτρέπει να δημιουργείτε\nονομασμένα ενσωματωμένα templates, τα οποία μπορούν να προσπελαστούν με το όνομά\nτους οπουδήποτε αλλού.\n\nΠριν ασχοληθούμε με τις λεπτομέρειες της σύνταξης αυτών των templates, υπάρχει\nμια σύμβαση ονομασίας αρχείων που αξίζει να αναφερθεί:\n\n* Τα περισσότερα αρχεία στο `templates/` αντιμετωπίζονται σαν να περιέχουν\n  Kubernetes manifests\n* Το `NOTES.txt` αποτελεί εξαίρεση\n* Όμως τα αρχεία των οποίων το όνομα ξεκινά με κάτω παύλα (`_`) θεωρείται ότι\n  _δεν_ περιέχουν manifest. Αυτά τα αρχεία δεν αποδίδονται ως ορισμοί\n  αντικειμένων Kubernetes, αλλά είναι διαθέσιμα παντού μέσα σε άλλα chart\n  templates για χρήση.\n\nΑυτά τα αρχεία χρησιμοποιούνται για την αποθήκευση partials και helpers. Στην\nπραγματικότητα, όταν δημιουργήσαμε για πρώτη φορά το `mychart`, είδαμε ένα\nαρχείο με το όνομα `_helpers.tpl`. Αυτό το αρχείο είναι η προεπιλεγμένη\nτοποθεσία για τα template partials.\n\n## Δήλωση και χρήση templates με `define` και `template` {#declaring-and-using-templates-with-define-and-template}\n\nΗ ενέργεια `define` μας επιτρέπει να δημιουργούμε ένα ονομασμένο template μέσα\nσε ένα αρχείο template. Η σύνταξή της είναι η εξής:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # body of template here\n{{- end }}\n```\n\nΓια παράδειγμα, μπορούμε να ορίσουμε ένα template που ενθυλακώνει ένα block\nlabels του Kubernetes:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nΤώρα μπορούμε να ενσωματώσουμε αυτό το template μέσα στο υπάρχον ConfigMap και\nστη συνέχεια να το συμπεριλάβουμε με την ενέργεια `template`:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nΌταν ο μηχανισμός template διαβάσει αυτό το αρχείο, θα αποθηκεύσει την αναφορά\nστο `mychart.labels` μέχρι να κληθεί το `template \"mychart.labels\"`. Τότε θα\nαποδώσει αυτό το template στη θέση του. Επομένως το αποτέλεσμα θα είναι:\n\n```yaml\n# Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nΣημείωση: ένα `define` δεν παράγει έξοδο εκτός αν κληθεί με ένα template, όπως\nσε αυτό το παράδειγμα.\n\nΣυνήθως, τα Helm charts τοποθετούν αυτά τα templates μέσα σε ένα αρχείο\npartials, συνήθως το `_helpers.tpl`. Ας μεταφέρουμε αυτή τη συνάρτηση εκεί:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nΚατά σύμβαση, οι συναρτήσεις `define` θα πρέπει να έχουν ένα απλό block\nτεκμηρίωσης (`{{/* ... */}}`) που περιγράφει τι κάνουν.\n\nΠαρόλο που αυτός ο ορισμός βρίσκεται στο `_helpers.tpl`, μπορεί ακόμα να\nπροσπελαστεί από το `configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nΌπως αναφέρθηκε παραπάνω, **τα ονόματα των templates είναι global**. Ως\nαποτέλεσμα, αν δύο templates δηλωθούν με το ίδιο όνομα, θα χρησιμοποιηθεί η\nτελευταία εμφάνιση. Δεδομένου ότι τα templates στα subcharts μεταγλωττίζονται\nμαζί με τα templates του ανώτερου επιπέδου, είναι καλύτερο να ονομάζετε τα\ntemplates σας με _ονόματα ειδικά για το chart_. Μια δημοφιλής σύμβαση ονομασίας\nείναι να προσθέτετε ως πρόθεμα σε κάθε ορισμένο template το όνομα του chart:\n`{{ define \"mychart.labels\" }}`.\n\n## Ορισμός του εύρους (scope) ενός template {#setting-the-scope-of-a-template}\n\nΣτο template που ορίσαμε παραπάνω, δεν χρησιμοποιήσαμε κανένα αντικείμενο.\nΧρησιμοποιήσαμε μόνο συναρτήσεις. Ας τροποποιήσουμε το ορισμένο template ώστε\nνα συμπεριλάβει το όνομα και την έκδοση του chart:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nΑν αποδώσουμε αυτό, θα λάβουμε ένα σφάλμα όπως αυτό:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nΓια να δείτε τι αποδόθηκε, εκτελέστε ξανά με `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`.\nΤο αποτέλεσμα δεν θα είναι αυτό που περιμέναμε:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\nΤι συνέβη με το όνομα και την έκδοση; Δεν βρίσκονταν μέσα στο εύρος (scope) του\nορισμένου template. Όταν ένα ονομασμένο template (που δημιουργήθηκε με `define`)\nαποδίδεται, θα λάβει το εύρος που μεταβιβάστηκε από την κλήση `template`. Στο\nπαράδειγμά μας, συμπεριλάβαμε το template ως εξής:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nΔεν μεταβιβάστηκε κανένα εύρος, οπότε μέσα στο template δεν μπορούμε να έχουμε\nπρόσβαση σε τίποτα στο `.`. Αυτό διορθώνεται εύκολα. Απλά μεταβιβάζουμε ένα\nεύρος στο template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nΠαρατηρήστε ότι μεταβιβάζουμε το `.` στο τέλος της κλήσης `template`. Θα\nμπορούσαμε εξίσου εύκολα να μεταβιβάσουμε `.Values` ή `.Values.favorite` ή\nόποιο εύρος θέλουμε. Αλλά αυτό που θέλουμε είναι το εύρος ανώτερου επιπέδου.\nΣτο πλαίσιο του ονομασμένου template, η `$` θα αναφέρεται στο εύρος που\nμεταβιβάσατε και όχι σε κάποιο global εύρος.\n\nΤώρα όταν εκτελέσουμε αυτό το template με `helm install --dry-run --debug\nplinking-anaco ./mychart`, θα λάβουμε:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nΤώρα το `{{ .Chart.Name }}` επιλύεται σε `mychart` και το `{{ .Chart.Version }}`\nεπιλύεται σε `0.1.0`.\n\n## Η συνάρτηση `include` {#the-include-function}\n\nΑς πούμε ότι έχουμε ορίσει ένα απλό template που μοιάζει με αυτό:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nΤώρα ας πούμε ότι θέλω να εισάγω αυτό τόσο στην ενότητα `labels:` του template\nμου όσο και στην ενότητα `data:`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nΑν αποδώσουμε αυτό, θα λάβουμε ένα σφάλμα όπως αυτό:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nΓια να δείτε τι αποδόθηκε, εκτελέστε ξανά με `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`.\nΗ έξοδος δεν θα είναι αυτή που περιμέναμε:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nΠαρατηρήστε ότι η εσοχή στο `app_version` είναι λάθος και στις δύο θέσεις.\nΓιατί; Επειδή το template που αντικαθίσταται έχει το κείμενο στοιχισμένο στα\nαριστερά. Επειδή το `template` είναι μια ενέργεια και όχι μια συνάρτηση, δεν\nυπάρχει τρόπος να μεταβιβάσουμε την έξοδο μιας κλήσης `template` σε άλλες\nσυναρτήσεις· τα δεδομένα απλά εισάγονται στη θέση τους.\n\nΓια να αντιμετωπίσουμε αυτή την περίπτωση, το Helm παρέχει μια εναλλακτική στο\n`template` που θα εισάγει τα περιεχόμενα ενός template στο τρέχον pipeline όπου\nμπορούν να μεταβιβαστούν σε άλλες συναρτήσεις στο pipeline.\n\nΑκολουθεί το παράδειγμα παραπάνω, διορθωμένο ώστε να χρησιμοποιεί το `indent`\nγια να εσοχοποιεί το template `mychart.app` σωστά:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nΤώρα το παραγόμενο YAML είναι σωστά εσοχοποιημένο για κάθε ενότητα:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> Θεωρείται προτιμότερο να χρησιμοποιείτε το `include` αντί για το `template`\n> στα Helm templates, απλά επειδή η μορφοποίηση της εξόδου μπορεί να\n> αντιμετωπιστεί καλύτερα για έγγραφα YAML.\n\nΜερικές φορές θέλουμε να εισάγουμε περιεχόμενο, αλλά όχι ως templates. Δηλαδή,\nθέλουμε να εισάγουμε αρχεία αυτούσια. Μπορούμε να το επιτύχουμε προσπελαύνοντας\nαρχεία μέσω του αντικειμένου `.Files` που περιγράφεται στην επόμενη ενότητα.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Δημιουργία αρχείου NOTES.txt\ndescription: Πώς να παρέχετε οδηγίες στους χρήστες του Chart σας.\nsidebar_position: 10\n---\n\nΣε αυτή την ενότητα θα εξετάσουμε το εργαλείο του Helm για την παροχή οδηγιών\nστους χρήστες του chart σας. Στο τέλος μιας εντολής `helm install` ή `helm\nupgrade`, το Helm μπορεί να εμφανίσει ένα μπλοκ χρήσιμων πληροφοριών για τους\nχρήστες. Αυτές οι πληροφορίες είναι πλήρως προσαρμόσιμες μέσω templates.\n\nΓια να προσθέσετε σημειώσεις εγκατάστασης στο chart σας, απλά δημιουργήστε ένα\nαρχείο `templates/NOTES.txt`. Αυτό το αρχείο είναι απλό κείμενο, αλλά\nεπεξεργάζεται σαν template και έχει πρόσβαση σε όλες τις συνήθεις συναρτήσεις\nκαι αντικείμενα template.\n\nΑς δημιουργήσουμε ένα απλό αρχείο `NOTES.txt`:\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nΑν εκτελέσουμε τώρα `helm install rude-cardinal ./mychart`, θα δούμε αυτό το\nμήνυμα στο τέλος:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nΗ χρήση του `NOTES.txt` με αυτόν τον τρόπο είναι εξαιρετική για να παρέχετε στους\nχρήστες σας λεπτομερείς πληροφορίες σχετικά με τη χρήση του chart που μόλις\nεγκατέστησαν. Η δημιουργία ενός αρχείου `NOTES.txt` συνιστάται ιδιαίτερα, αν και\nδεν είναι υποχρεωτική.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Subcharts και Global Values\ndescription: Αλληλεπίδραση με τα values ενός subchart και τα global values.\nsidebar_position: 11\n---\n\nΜέχρι τώρα δουλεύαμε μόνο με ένα chart. Όμως τα charts μπορούν να έχουν\nεξαρτήσεις, που ονομάζονται _subcharts_, τα οποία επίσης έχουν τα δικά τους\nvalues και templates. Σε αυτή την ενότητα θα δημιουργήσουμε ένα subchart και θα\nδούμε τους διαφορετικούς τρόπους πρόσβασης στα values μέσα από τα templates.\n\nΠριν εμβαθύνουμε στον κώδικα, υπάρχουν μερικές σημαντικές λεπτομέρειες που\nπρέπει να γνωρίζετε σχετικά με τα subcharts εφαρμογών.\n\n1. Ένα subchart θεωρείται \"αυτόνομο\", που σημαίνει ότι ένα subchart δεν μπορεί\n   ποτέ να εξαρτάται ρητά από το γονικό chart.\n2. Για αυτόν τον λόγο, ένα subchart δεν μπορεί να έχει πρόσβαση στα values του\n   γονικού chart.\n3. Ένα γονικό chart μπορεί να παρακάμψει τα values των subcharts.\n4. Το Helm έχει την έννοια των _global values_ που είναι προσβάσιμα από όλα τα\n   charts.\n\n> Αυτοί οι περιορισμοί δεν ισχύουν απαραίτητα για τα [library charts](/topics/library_charts.md), τα οποία έχουν σχεδιαστεί για να παρέχουν τυποποιημένη βοηθητική λειτουργικότητα.\n\nΚαθώς προχωράμε στα παραδείγματα αυτής της ενότητας, πολλές από αυτές τις\nέννοιες θα γίνουν πιο ξεκάθαρες.\n\n## Δημιουργία Subchart {#creating-a-subchart}\n\nΓια αυτές τις ασκήσεις, θα ξεκινήσουμε με το chart `mychart/` που δημιουργήσαμε\nστην αρχή αυτού του οδηγού και θα προσθέσουμε ένα νέο chart μέσα σε αυτό.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nΠαρατηρήστε ότι όπως και πριν, διαγράψαμε όλα τα βασικά templates ώστε να\nμπορέσουμε να ξεκινήσουμε από την αρχή. Σε αυτόν τον οδηγό επικεντρωνόμαστε\nστον τρόπο λειτουργίας των templates, όχι στη διαχείριση εξαρτήσεων. Ο\n[Οδηγός Charts](/topics/charts.md) περιέχει περισσότερες πληροφορίες σχετικά με\nτον τρόπο λειτουργίας των subcharts.\n\n## Προσθήκη Values και Template στο Subchart {#adding-values-and-a-template-to-the-subchart}\n\nΣτη συνέχεια, ας δημιουργήσουμε ένα απλό template και αρχείο values για το\nchart `mysubchart`. Θα πρέπει να υπάρχει ήδη ένα `values.yaml` στο\n`mychart/charts/mysubchart`. Θα το ρυθμίσουμε ως εξής:\n\n```yaml\ndessert: cake\n```\n\nΣτη συνέχεια, θα δημιουργήσουμε ένα νέο ConfigMap template στο\n`mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nΕπειδή κάθε subchart είναι ένα _αυτόνομο chart_, μπορούμε να δοκιμάσουμε το\n`mysubchart` μόνο του:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml {#source-mysubcharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Παράκαμψη Values από Γονικό Chart {#overriding-values-from-a-parent-chart}\n\nΤο αρχικό μας chart, `mychart`, είναι τώρα το _γονικό chart_ του `mysubchart`.\nΑυτή η σχέση βασίζεται αποκλειστικά στο γεγονός ότι το `mysubchart` βρίσκεται\nμέσα στο `mychart/charts`.\n\nΕπειδή το `mychart` είναι γονικό, μπορούμε να καθορίσουμε ρυθμίσεις στο\n`mychart` και να τις περάσουμε στο `mysubchart`. Για παράδειγμα, μπορούμε να\nτροποποιήσουμε το `mychart/values.yaml` ως εξής:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nΠροσέξτε τις δύο τελευταίες γραμμές. Οποιαδήποτε οδηγία μέσα στην ενότητα\n`mysubchart` θα σταλεί στο chart `mysubchart`. Έτσι, αν εκτελέσουμε\n`helm install --generate-name --dry-run --debug mychart`, ένα από τα πράγματα\nπου θα δούμε είναι το ConfigMap του `mysubchart`:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml {#source-mychartchartsmysubcharttemplatesconfigmapyaml} {#source-mychartchartsmysubcharttemplatesconfigmapyaml} {#source-mychartchartsmysubcharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nΗ τιμή στο ανώτερο επίπεδο έχει τώρα παρακάμψει την τιμή του subchart.\n\nΥπάρχει μια σημαντική λεπτομέρεια που πρέπει να παρατηρήσουμε εδώ. Δεν\nαλλάξαμε το template του `mychart/charts/mysubchart/templates/configmap.yaml`\nώστε να δείχνει στο `.Values.mysubchart.dessert`. Από την οπτική γωνία αυτού\nτου template, η τιμή εξακολουθεί να βρίσκεται στο `.Values.dessert`. Καθώς η\nμηχανή template περνά τα values, ορίζει το εύρος (scope). Έτσι, για τα\ntemplates του `mysubchart`, μόνο τα values που προορίζονται συγκεκριμένα για\nτο `mysubchart` θα είναι διαθέσιμα στο `.Values`.\n\nΜερικές φορές, όμως, θέλετε ορισμένα values να είναι διαθέσιμα σε όλα τα\ntemplates. Αυτό επιτυγχάνεται με τα global chart values.\n\n## Global Chart Values {#global-chart-values}\n\nΤα global values είναι τιμές που είναι προσβάσιμες από οποιοδήποτε chart ή\nsubchart με ακριβώς το ίδιο όνομα. Τα globals απαιτούν ρητή δήλωση. Δεν μπορείτε\nνα χρησιμοποιήσετε ένα υπάρχον μη-global value σαν να ήταν global.\n\nΟ τύπος δεδομένων Values έχει μια δεσμευμένη ενότητα που ονομάζεται\n`Values.global` όπου μπορούν να οριστούν global values. Ας ορίσουμε ένα στο\nαρχείο `mychart/values.yaml`.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nΛόγω του τρόπου λειτουργίας των globals, τόσο το\n`mychart/templates/configmap.yaml` όσο και το\n`mysubchart/templates/configmap.yaml` θα πρέπει να μπορούν να έχουν πρόσβαση σε\nαυτή την τιμή ως `{{ .Values.global.salad }}`.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nΤώρα αν εκτελέσουμε μια dry run εγκατάσταση, θα δούμε την ίδια τιμή και στις δύο\nεξόδους:\n\n```yaml\n# Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nΤα globals είναι χρήσιμα για τη μετάδοση τέτοιων πληροφοριών, αν και απαιτείται\nκάποιος σχεδιασμός για να βεβαιωθείτε ότι τα σωστά templates είναι ρυθμισμένα\nνα χρησιμοποιούν globals.\n\n## Κοινή Χρήση Templates με Subcharts {#sharing-templates-with-subcharts}\n\nΤα γονικά charts και τα subcharts μπορούν να μοιράζονται templates. Οποιοδήποτε\nblock ορίζεται σε οποιοδήποτε chart είναι διαθέσιμο σε άλλα charts.\n\nΓια παράδειγμα, μπορούμε να ορίσουμε ένα απλό template ως εξής:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nΘυμηθείτε ότι τα labels στα templates είναι _παγκοσμίως κοινόχρηστα_. Επομένως,\nτο chart `labels` μπορεί να συμπεριληφθεί από οποιοδήποτε άλλο chart.\n\nΕνώ οι developers charts έχουν την επιλογή μεταξύ `include` και `template`, ένα\nπλεονέκτημα της χρήσης του `include` είναι ότι μπορεί να αναφέρεται δυναμικά σε\ntemplates:\n\n```yaml\n{{ include $mytemplate }}\n```\n\nΤο παραπάνω θα αποαναφέρει (dereference) τη μεταβλητή `$mytemplate`. Η συνάρτηση\n`template`, αντίθετα, δέχεται μόνο string literal.\n\n## Αποφύγετε τη Χρήση Blocks {#avoid-using-blocks}\n\nΗ γλώσσα Go template παρέχει τη λέξη-κλειδί `block` που επιτρέπει στους\ndevelopers να παρέχουν μια προεπιλεγμένη υλοποίηση η οποία μπορεί να\nπαρακαμφθεί αργότερα. Στα Helm charts, τα blocks δεν είναι το καλύτερο εργαλείο\nγια παράκαμψη, επειδή αν παρέχονται πολλαπλές υλοποιήσεις του ίδιου block, η\nεπιλογή είναι απρόβλεπτη.\n\nΗ σύσταση είναι να χρησιμοποιείτε αντ' αυτού το `include`.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Αρχεία Values\ndescription: Οδηγίες για τη χρήση της επιλογής --values.\nsidebar_position: 4\n---\n\nΣτην προηγούμενη ενότητα εξετάσαμε τα ενσωματωμένα αντικείμενα που προσφέρουν\nτα Helm templates. Ένα από αυτά είναι το `Values`. Αυτό το αντικείμενο παρέχει\nπρόσβαση σε τιμές που μεταβιβάζονται στο chart. Τα περιεχόμενά του προέρχονται\nαπό πολλαπλές πηγές:\n\n- Το αρχείο `values.yaml` μέσα στο chart\n- Εάν πρόκειται για subchart, το αρχείο `values.yaml` του γονικού chart\n- Ένα αρχείο values που μεταβιβάζεται στο `helm install` ή `helm upgrade` με την\n  επιλογή `-f` (`helm install -f myvals.yaml ./mychart`)\n- Μεμονωμένες παράμετροι που μεταβιβάζονται με το `--set` (όπως `helm install --set foo=bar\n  ./mychart`)\n\nΗ παραπάνω λίστα είναι σε σειρά προτεραιότητας: το `values.yaml` είναι η\nπροεπιλογή, η οποία μπορεί να παρακαμφθεί από το `values.yaml` ενός γονικού\nchart. Αυτό μπορεί να παρακαμφθεί από ένα αρχείο values που παρέχει ο χρήστης,\nτο οποίο τέλος μπορεί να παρακαμφθεί από παραμέτρους `--set`.\n\nΤα αρχεία values είναι απλά αρχεία YAML. Ας τροποποιήσουμε το\n`mychart/values.yaml` και στη συνέχεια το template του ConfigMap.\n\nΑφαιρώντας τις προεπιλεγμένες τιμές από το `values.yaml`, θα ορίσουμε μόνο μία\nπαράμετρο:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nΤώρα μπορούμε να τη χρησιμοποιήσουμε μέσα σε ένα template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nΠαρατηρήστε ότι στην τελευταία γραμμή έχουμε πρόσβαση στο `favoriteDrink` ως\nιδιότητα του `Values`: `{{ .Values.favoriteDrink }}`.\n\nΑς δούμε πώς αποδίδεται αυτό.\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nΕπειδή το `favoriteDrink` έχει οριστεί στο προεπιλεγμένο αρχείο `values.yaml` ως\n`coffee`, αυτή είναι η τιμή που εμφανίζεται στο template. Μπορούμε εύκολα να την\nπαρακάμψουμε προσθέτοντας την επιλογή `--set` στην κλήση του `helm install`:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nΔεδομένου ότι το `--set` έχει μεγαλύτερη προτεραιότητα από το προεπιλεγμένο\nαρχείο `values.yaml`, το template μας παράγει `drink: slurm`.\n\nΤα αρχεία values μπορούν να περιέχουν και πιο δομημένο περιεχόμενο. Για\nπαράδειγμα, θα μπορούσαμε να δημιουργήσουμε μια ενότητα `favorite` στο αρχείο\n`values.yaml` και να προσθέσουμε εκεί αρκετά κλειδιά:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nΤώρα θα πρέπει να τροποποιήσουμε ελαφρώς το template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nΑν και η δόμηση δεδομένων με αυτόν τον τρόπο είναι δυνατή, η σύσταση είναι να\nδιατηρείτε τα δέντρα τιμών σας ρηχά, προτιμώντας την επίπεδη δομή. Όταν\nεξετάσουμε την ανάθεση τιμών σε subcharts, θα δούμε πώς οι τιμές\nονομάζονται χρησιμοποιώντας μια ιεραρχική δομή.\n\n## Διαγραφή ενός προεπιλεγμένου κλειδιού {#deleting-a-default-key}\n\nΕάν χρειάζεται να διαγράψετε ένα κλειδί από τις προεπιλεγμένες τιμές, μπορείτε\nνα θέσετε την τιμή του κλειδιού σε `null`, οπότε το Helm θα αφαιρέσει το κλειδί\nκατά τη συγχώνευση των παρακαμφθεισών τιμών.\n\nΓια παράδειγμα, το stable Drupal chart επιτρέπει τη ρύθμιση του liveness probe,\nσε περίπτωση που διαμορφώνετε μια προσαρμοσμένη εικόνα. Οι προεπιλεγμένες τιμές\nείναι:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nΕάν προσπαθήσετε να αλλάξετε τον handler του livenessProbe σε `exec` αντί για\n`httpGet` χρησιμοποιώντας\n`--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, το Helm θα\nσυγχωνεύσει τα προεπιλεγμένα και τα παρακαμφθέντα κλειδιά, με αποτέλεσμα το\nακόλουθο YAML:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nΩστόσο, το Kubernetes θα αποτύχει επειδή δεν μπορείτε να δηλώσετε περισσότερους\nαπό έναν handlers για το livenessProbe. Για να το αντιμετωπίσετε, μπορείτε να\nδώσετε εντολή στο Helm να διαγράψει το `livenessProbe.httpGet` θέτοντάς το σε\nnull:\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nΣε αυτό το σημείο, έχουμε δει αρκετά ενσωματωμένα αντικείμενα και τα\nχρησιμοποιήσαμε για να εισάγουμε πληροφορίες σε ένα template. Τώρα θα εξετάσουμε\nμια άλλη πτυχή της μηχανής template: τις συναρτήσεις και τα pipelines.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: Μεταβλητές\ndescription: Χρήση μεταβλητών στα templates.\nsidebar_position: 8\n---\n\nΑφού έχουμε δει τις συναρτήσεις, τα pipelines, τα αντικείμενα και τις δομές\nελέγχου, μπορούμε να περάσουμε σε μια από τις πιο βασικές έννοιες σε πολλές\nγλώσσες προγραμματισμού: τις μεταβλητές. Στα templates, χρησιμοποιούνται λιγότερο\nσυχνά. Θα δούμε όμως πώς μπορούν να απλοποιήσουν τον κώδικα και να αξιοποιήσουν\nκαλύτερα τα `with` και `range`.\n\nΣε ένα προηγούμενο παράδειγμα, είδαμε ότι αυτός ο κώδικας θα αποτύχει:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nΤο `Release.Name` δεν βρίσκεται μέσα στο εύρος (scope) που περιορίζεται από το\nblock `with`. Ένας τρόπος για να αντιμετωπίσουμε προβλήματα εύρους είναι να\nαναθέτουμε αντικείμενα σε μεταβλητές, στις οποίες μπορούμε να έχουμε πρόσβαση\nανεξάρτητα από το τρέχον εύρος.\n\nΣτα Helm templates, μια μεταβλητή είναι μια ονομασμένη αναφορά σε ένα άλλο\nαντικείμενο. Ακολουθεί τη μορφή `$name`. Οι μεταβλητές αναθέτονται με έναν\nειδικό τελεστή ανάθεσης: `:=`. Μπορούμε να ξαναγράψουμε τα παραπάνω\nχρησιμοποιώντας μια μεταβλητή για το `Release.Name`.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nΠαρατηρήστε ότι πριν ξεκινήσουμε το block `with`, αναθέτουμε `$relname :=\n.Release.Name`. Τώρα μέσα στο block `with`, η μεταβλητή `$relname` εξακολουθεί\nνα δείχνει στο όνομα του release.\n\nΗ εκτέλεση αυτού θα παράγει:\n\n```yaml\n# Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nΟι μεταβλητές είναι ιδιαίτερα χρήσιμες στους βρόχους `range`. Μπορούν να\nχρησιμοποιηθούν σε λίστες για να πάρουν τόσο τον δείκτη (index) όσο και\nτην τιμή:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nΠαρατηρήστε ότι το `range` έρχεται πρώτο, μετά οι μεταβλητές, στη συνέχεια ο\nτελεστής ανάθεσης και τέλος η λίστα. Αυτό θα αναθέσει τον ακέραιο δείκτη\n(ξεκινώντας από το μηδέν) στην `$index` και την τιμή στην `$topping`. Η\nεκτέλεση θα παράγει:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nΓια δομές δεδομένων που έχουν τόσο κλειδί όσο και τιμή, μπορούμε να\nχρησιμοποιήσουμε το `range` για να λάβουμε και τα δύο. Για παράδειγμα,\nμπορούμε να κάνουμε βρόχο στο `.Values.favorite` ως εξής:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nΣτην πρώτη επανάληψη, το `$key` θα είναι `drink` και το `$val` θα είναι `coffee`,\nκαι στη δεύτερη, το `$key` θα είναι `food` και το `$val` θα είναι `pizza`. Η\nεκτέλεση των παραπάνω θα δημιουργήσει:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nΟι μεταβλητές κανονικά δεν είναι \"καθολικές\" (global). Έχουν εύρος μόνο στο\nblock στο οποίο δηλώνονται. Προηγουμένως, αναθέσαμε την `$relname` στο\nανώτατο επίπεδο του template. Αυτή η μεταβλητή θα είναι διαθέσιμη σε όλο\nτο template. Όμως στο τελευταίο παράδειγμα, οι `$key` και `$val` θα είναι\nδιαθέσιμες μόνο μέσα στο block `{{ range... }}{{ end }}`.\n\nΩστόσο, υπάρχει μια μεταβλητή που δείχνει πάντα στο αρχικό context: `$`.\nΑυτό μπορεί να είναι πολύ χρήσιμο όταν κάνουμε βρόχο με `range` και\nχρειαζόμαστε το όνομα του release του chart.\n\nΈνα παράδειγμα:\n\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Many helm templates would use `.` below, but that will not work,\n    # however `$` will work here\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # I cannot reference .Chart.Name, but I can do $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Value from appVersion in Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nΜέχρι τώρα έχουμε δει μόνο ένα template που δηλώνεται σε ένα μόνο αρχείο. Αλλά\nμια από τις ισχυρές δυνατότητες της γλώσσας template του Helm είναι η\nικανότητά της να δηλώνει πολλαπλά templates και να τα χρησιμοποιεί μαζί.\nΘα περάσουμε σε αυτό στην επόμενη ενότητα.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Επόμενα Βήματα\ndescription: Ολοκλήρωση - κάποιες χρήσιμες αναφορές σε άλλη τεκμηρίωση που θα σας βοηθήσουν.\nsidebar_position: 14\n---\n\nΑυτός ο οδηγός σκοπεύει να σας δώσει, ως προγραμματιστή chart, μια ισχυρή κατανόηση\nτου πώς να χρησιμοποιείτε τη γλώσσα template του Helm. Ο οδηγός επικεντρώνεται στις\nτεχνικές πτυχές της ανάπτυξης templates.\n\nΩστόσο, υπάρχουν πολλά πράγματα που αυτός ο οδηγός δεν κάλυψε όσον αφορά την\nπρακτική καθημερινή ανάπτυξη charts. Ακολουθούν κάποιες χρήσιμες αναφορές σε\nάλλη τεκμηρίωση που θα σας βοηθήσουν καθώς δημιουργείτε νέα charts:\n\n- Το [Artifact Hub](https://artifacthub.io/packages/search?kind=0) του CNCF είναι\n  μια ανεκτίμητη πηγή charts.\n- Η [τεκμηρίωση](https://kubernetes.io/docs/home/) του Kubernetes παρέχει\n  λεπτομερή παραδείγματα για τα διάφορα είδη πόρων που μπορείτε να χρησιμοποιήσετε,\n  από ConfigMaps και Secrets έως DaemonSets και Deployments.\n- Ο [Οδηγός Charts](/topics/charts.md) του Helm εξηγεί τη ροή εργασίας της\n  χρήσης charts.\n- Ο [Οδηγός Chart Hooks](/topics/charts_hooks.md) του Helm εξηγεί πώς να\n  δημιουργείτε lifecycle hooks.\n- Το άρθρο [Συμβουλές και Κόλπα για Charts](/howto/charts_tips_and_tricks.md)\n  του Helm παρέχει χρήσιμες συμβουλές για τη συγγραφή charts.\n- Η [τεκμηρίωση του Sprig](https://github.com/Masterminds/sprig) περιγράφει\n  περισσότερες από εξήντα συναρτήσεις template.\n- Η [τεκμηρίωση των Go templates](https://godoc.org/text/template) εξηγεί\n  λεπτομερώς τη σύνταξη template.\n- Το [εργαλείο Schelm](https://github.com/databus23/schelm) είναι ένα εύχρηστο\n  βοηθητικό εργαλείο για τον εντοπισμό σφαλμάτων σε charts.\n\nΜερικές φορές είναι πιο εύκολο να κάνετε μερικές ερωτήσεις και να λάβετε απαντήσεις\nαπό έμπειρους προγραμματιστές. Το καλύτερο μέρος για αυτό είναι τα κανάλια Helm\nστο [Kubernetes Slack](https://kubernetes.slack.com):\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nΤέλος, αν βρείτε λάθη ή παραλείψεις σε αυτό το έγγραφο, θέλετε να προτείνετε\nνέο περιεχόμενο ή θα θέλατε να συνεισφέρετε, επισκεφτείτε το [Helm\nProject](https://github.com/helm/helm-www).\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Παράρτημα: Τεχνικές YAML\"\ndescription: Μια πιο προσεκτική ματιά στην προδιαγραφή YAML και πώς εφαρμόζεται στο Helm.\nsidebar_position: 15\n---\n\nΤο μεγαλύτερο μέρος αυτού του οδηγού επικεντρώθηκε στη συγγραφή της γλώσσας\ntemplate. Εδώ, θα εξετάσουμε τη μορφή YAML. Η YAML έχει κάποια χρήσιμα\nχαρακτηριστικά που εμείς, ως συγγραφείς template, μπορούμε να χρησιμοποιήσουμε\nγια να κάνουμε τα templates μας λιγότερο επιρρεπή σε σφάλματα και ευκολότερα\nστην ανάγνωση.\n\n## Βαθμωτά και Συλλογές {#scalars-and-collections}\n\nΣύμφωνα με την [προδιαγραφή YAML](https://yaml.org/spec/1.2/spec.html), υπάρχουν\nδύο τύποι συλλογών και πολλοί βαθμωτοί τύποι.\n\nΟι δύο τύποι συλλογών είναι maps και sequences:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nΟι βαθμωτές τιμές είναι μεμονωμένες τιμές (σε αντίθεση με τις συλλογές)\n\n### Βαθμωτοί Τύποι στην YAML {#scalar-types-in-yaml}\n\nΣτη διάλεκτο YAML του Helm, ο βαθμωτός τύπος δεδομένων μιας τιμής καθορίζεται\nαπό ένα πολύπλοκο σύνολο κανόνων, συμπεριλαμβανομένου του Kubernetes schema\nγια ορισμούς πόρων. Αλλά κατά τη συναγωγή τύπων, οι παρακάτω κανόνες τείνουν\nνα ισχύουν.\n\nΕάν ένας ακέραιος ή αριθμός κινητής υποδιαστολής είναι bare word (χωρίς\nεισαγωγικά), τυπικά αντιμετωπίζεται ως αριθμητικός τύπος:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nΑλλά αν βρίσκονται σε εισαγωγικά, αντιμετωπίζονται ως strings:\n\n```yaml\ncount: \"1\" # <-- string, not int\nsize: '2.34' # <-- string, not float\n```\n\nΤο ίδιο ισχύει για τα booleans:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # string\n```\n\nΗ λέξη για μια κενή τιμή είναι `null` (όχι `nil`).\n\nΣημειώστε ότι το `port: \"80\"` είναι έγκυρη YAML, και θα περάσει τόσο από τη\nμηχανή template όσο και από τον parser της YAML, αλλά θα αποτύχει αν το\nKubernetes αναμένει το `port` να είναι ακέραιος.\n\nΣε ορισμένες περιπτώσεις, μπορείτε να επιβάλετε μια συγκεκριμένη συναγωγή\nτύπου χρησιμοποιώντας YAML node tags:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nΣτο παραπάνω, το `!!str` λέει στον parser ότι το `age` είναι string, ακόμα κι\nαν μοιάζει με int. Και το `port` αντιμετωπίζεται ως int, παρόλο που βρίσκεται\nσε εισαγωγικά.\n\n\n## Strings στην YAML {#strings-in-yaml}\n\nΠολλά από τα δεδομένα που τοποθετούμε σε έγγραφα YAML είναι strings. Η YAML έχει\nπερισσότερους από έναν τρόπους για να αναπαραστήσει ένα string. Αυτή η ενότητα\nεξηγεί τους τρόπους και επιδεικνύει πώς να χρησιμοποιήσετε κάποιους από αυτούς.\n\nΥπάρχουν τρεις \"inline\" τρόποι για να δηλώσετε ένα string:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nΌλα τα inline styles πρέπει να είναι σε μία γραμμή.\n\n- Τα bare words είναι χωρίς εισαγωγικά και δεν γίνεται escape. Για αυτόν τον\n  λόγο, πρέπει να προσέχετε ποιους χαρακτήρες χρησιμοποιείτε.\n- Τα double-quoted strings μπορούν να έχουν συγκεκριμένους χαρακτήρες με escape\n  χρησιμοποιώντας `\\`. Για παράδειγμα `\"\\\"Hello\\\", she said\"`. Μπορείτε να κάνετε\n  escape τις αλλαγές γραμμής με `\\n`.\n- Τα single-quoted strings είναι \"literal\" strings, και δεν χρησιμοποιούν το\n  `\\` για escape χαρακτήρων. Η μόνη escape sequence είναι `''`, που\n  αποκωδικοποιείται ως ένα μόνο `'`.\n\nΕκτός από τα strings μιας γραμμής, μπορείτε να δηλώσετε strings πολλών γραμμών:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nΤο παραπάνω θα αντιμετωπίσει την τιμή του `coffee` ως ένα μόνο string ισοδύναμο\nμε `Latte\\nCappuccino\\nEspresso\\n`.\n\nΣημειώστε ότι η πρώτη γραμμή μετά το `|` πρέπει να έχει σωστή εσοχή. Έτσι\nμπορούμε να σπάσουμε το παραπάνω παράδειγμα κάνοντας αυτό:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nΕπειδή το `Latte` έχει λανθασμένη εσοχή, θα λάβουμε ένα σφάλμα όπως αυτό:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nΣτα templates, είναι μερικές φορές πιο ασφαλές να βάλετε μια ψεύτικη \"πρώτη\nγραμμή\" περιεχομένου σε ένα έγγραφο πολλών γραμμών για προστασία από το\nπαραπάνω σφάλμα:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nΣημειώστε ότι οτιδήποτε είναι αυτή η πρώτη γραμμή, θα διατηρηθεί στην έξοδο του\nstring. Έτσι αν, για παράδειγμα, χρησιμοποιείτε αυτή την τεχνική για να εισάγετε\nτα περιεχόμενα ενός αρχείου σε ένα ConfigMap, το σχόλιο πρέπει να είναι του τύπου\nπου αναμένεται από ό,τι διαβάζει αυτή την καταχώρηση.\n\n### Έλεγχος Κενών σε Strings Πολλών Γραμμών {#controlling-spaces-in-multi-line-strings}\n\nΣτο παραπάνω παράδειγμα, χρησιμοποιήσαμε το `|` για να υποδείξουμε ένα string\nπολλών γραμμών. Αλλά παρατηρήστε ότι το περιεχόμενο του string μας ακολουθούνταν\nαπό ένα τελικό `\\n`. Αν θέλουμε ο επεξεργαστής YAML να αφαιρέσει αυτή την τελική\nαλλαγή γραμμής, μπορούμε να προσθέσουμε ένα `-` μετά το `|`:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nΤώρα η τιμή του `coffee` θα είναι: `Latte\\nCappuccino\\nEspresso` (χωρίς τελικό\n`\\n`).\n\nΆλλες φορές, μπορεί να θέλουμε να διατηρηθούν όλα τα κενά στο τέλος.\nΜπορούμε να το κάνουμε αυτό με τη σημειογραφία `|+`:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nΤώρα η τιμή του `coffee` θα είναι `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nΗ εσοχή μέσα σε ένα text block διατηρείται, και έχει ως αποτέλεσμα τη διατήρηση\nτων αλλαγών γραμμής επίσης:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nΣτην παραπάνω περίπτωση, το `coffee` θα είναι `Latte\\n  12 oz\\n  16\noz\\nCappuccino\\nEspresso`.\n\n### Εσοχή και Templates {#indenting-and-templates}\n\nΌταν γράφετε templates, μπορεί να θέλετε να εισάγετε τα περιεχόμενα ενός αρχείου\nστο template. Όπως είδαμε σε προηγούμενα κεφάλαια, υπάρχουν δύο τρόποι για να\nτο κάνετε αυτό:\n\n- Χρησιμοποιήστε `{{ .Files.Get \"FILENAME\" }}` για να λάβετε τα περιεχόμενα ενός\n  αρχείου στο chart.\n- Χρησιμοποιήστε `{{ include \"TEMPLATE\" . }}` για να κάνετε render ένα template\n  και στη συνέχεια να τοποθετήσετε τα περιεχόμενά του στο chart.\n\nΌταν εισάγετε αρχεία στην YAML, είναι καλό να κατανοήσετε τους κανόνες πολλών\nγραμμών παραπάνω. Συχνά, ο ευκολότερος τρόπος για να εισάγετε ένα στατικό αρχείο\nείναι να κάνετε κάτι σαν αυτό:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nΣημειώστε πώς κάνουμε την εσοχή παραπάνω: το `indent 2` λέει στη μηχανή template\nνα προσθέσει εσοχή δύο κενών σε κάθε γραμμή του \"myfile.txt\". Σημειώστε ότι δεν\nβάζουμε εσοχή σε εκείνη τη γραμμή του template. Αυτό γιατί αν το κάναμε, το\nπεριεχόμενο του αρχείου της πρώτης γραμμής θα είχε διπλή εσοχή.\n\n### Αναδιπλούμενα Strings Πολλών Γραμμών {#folded-multi-line-strings}\n\nΜερικές φορές θέλετε να αναπαραστήσετε ένα string στην YAML σας με πολλές\nγραμμές, αλλά θέλετε να αντιμετωπιστεί ως μία μακριά γραμμή όταν ερμηνεύεται.\nΑυτό ονομάζεται \"folding\". Για να δηλώσετε ένα folded block, χρησιμοποιήστε `>`\nαντί για `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nΗ τιμή του `coffee` παραπάνω θα είναι `Latte Cappuccino Espresso\\n`. Σημειώστε\nότι όλες εκτός από την τελευταία αλλαγή γραμμής θα μετατραπούν σε κενά. Μπορείτε\nνα συνδυάσετε τους ελέγχους whitespace με τον δείκτη folded text, οπότε το `>-`\nθα αντικαταστήσει ή θα αφαιρέσει όλες τις αλλαγές γραμμής.\n\nΣημειώστε ότι στη σύνταξη folding, η εσοχή κειμένου θα προκαλέσει τη διατήρηση\nτων γραμμών.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nΤο παραπάνω θα παράγει `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Σημειώστε\nότι τόσο τα κενά όσο και οι αλλαγές γραμμής εξακολουθούν να υπάρχουν.\n\n## Ενσωμάτωση Πολλαπλών Εγγράφων σε Ένα Αρχείο {#embedding-multiple-documents-in-one-file}\n\nΕίναι δυνατό να τοποθετήσετε περισσότερα από ένα έγγραφα YAML σε ένα μόνο αρχείο.\nΑυτό γίνεται προτάσσοντας ένα νέο έγγραφο με `---` και τερματίζοντας το έγγραφο\nμε `...`\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nΣε πολλές περιπτώσεις, είτε το `---` είτε το `...` μπορεί να παραλειφθεί.\n\nΟρισμένα αρχεία στο Helm δεν μπορούν να περιέχουν περισσότερα από ένα έγγραφα.\nΑν, για παράδειγμα, παρέχεται περισσότερο από ένα έγγραφο μέσα σε ένα αρχείο\n`values.yaml`, μόνο το πρώτο θα χρησιμοποιηθεί.\n\nΤα αρχεία template, ωστόσο, μπορεί να έχουν περισσότερα από ένα έγγραφα. Όταν\nσυμβαίνει αυτό, το αρχείο (και όλα τα έγγραφά του) αντιμετωπίζεται ως ένα\nαντικείμενο κατά το rendering του template. Αλλά στη συνέχεια η προκύπτουσα\nYAML διαχωρίζεται σε πολλαπλά έγγραφα πριν τροφοδοτηθεί στο Kubernetes.\n\nΣυνιστούμε να χρησιμοποιείτε πολλαπλά έγγραφα ανά αρχείο μόνο όταν είναι\nαπολύτως απαραίτητο. Η ύπαρξη πολλαπλών εγγράφων σε ένα αρχείο μπορεί να είναι\nδύσκολη στην αποσφαλμάτωση.\n\n## Η YAML είναι Υπερσύνολο της JSON {#yaml-is-a-superset-of-json}\n\nΕπειδή η YAML είναι υπερσύνολο της JSON, κάθε έγκυρο έγγραφο JSON _θα πρέπει_\nνα είναι έγκυρη YAML.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nΤο παραπάνω είναι ένας άλλος τρόπος αναπαράστασης αυτού:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nΚαι τα δύο μπορούν να αναμειχθούν (με προσοχή):\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nΚαι τα τρία πρέπει να αναλυθούν στην ίδια εσωτερική αναπαράσταση.\n\nΕνώ αυτό σημαίνει ότι αρχεία όπως το `values.yaml` μπορούν να περιέχουν\nδεδομένα JSON, το Helm δεν αντιμετωπίζει την επέκταση αρχείου `.json` ως\nέγκυρο επίθημα.\n\n## YAML Anchors {#yaml-anchors}\n\nΗ προδιαγραφή YAML παρέχει έναν τρόπο για να αποθηκεύσετε μια αναφορά σε μια\nτιμή, και αργότερα να αναφερθείτε σε αυτή την τιμή μέσω αναφοράς. Η YAML\nαναφέρεται σε αυτό ως \"anchoring\":\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nΣτο παραπάνω, το `&favoriteCoffee` ορίζει μια αναφορά στο `Cappuccino`. Αργότερα,\nαυτή η αναφορά χρησιμοποιείται ως `*favoriteCoffee`. Έτσι το `coffees` γίνεται\n`Latte, Cappuccino, Espresso`.\n\nΕνώ υπάρχουν μερικές περιπτώσεις όπου τα anchors είναι χρήσιμα, υπάρχει μια\nπτυχή τους που μπορεί να προκαλέσει ανεπαίσθητα σφάλματα: Την πρώτη φορά που\nη YAML καταναλώνεται, η αναφορά επεκτείνεται και στη συνέχεια απορρίπτεται.\n\nΈτσι αν αποκωδικοποιούσαμε και στη συνέχεια επανακωδικοποιούσαμε το παραπάνω\nπαράδειγμα, η προκύπτουσα YAML θα ήταν:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nΕπειδή το Helm και το Kubernetes συχνά διαβάζουν, τροποποιούν και στη συνέχεια\nξαναγράφουν αρχεία YAML, τα anchors θα χαθούν.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: Αλλαγές από το Helm 2\nsidebar_position: 1\n---\n\n## Αλλαγές από το Helm 2 {#changes-since-helm-2}\n\nΑκολουθεί μια ολοκληρωμένη λίστα με όλες τις σημαντικές αλλαγές που εισήχθησαν στο Helm 3.\n\n### Κατάργηση του Tiller {#removal-of-tiller}\n\nΚατά τη διάρκεια του κύκλου ανάπτυξης του Helm 2, εισαγάγαμε τον Tiller. Ο Tiller\nδιαδραμάτισε σημαντικό ρόλο για ομάδες που εργάζονται σε ένα κοινόχρηστο cluster —\nreleases.\n\nΜε τον έλεγχο πρόσβασης βάσει ρόλων (RBAC) ενεργοποιημένο από προεπιλογή στο\nKubernetes 1.6, η ασφάλιση του Tiller για χρήση σε παραγωγικό περιβάλλον έγινε πιο\nδύσκολη στη διαχείριση. Λόγω του μεγάλου αριθμού πιθανών πολιτικών ασφαλείας, η\nπροσέγγισή μας ήταν να παρέχουμε μια επιτρεπτική προεπιλεγμένη ρύθμιση. Αυτό\nεπέτρεπε στους νέους χρήστες να ξεκινήσουν να πειραματίζονται με το Helm και το\nKubernetes χωρίς να χρειάζεται να εμβαθύνουν αμέσως στους ελέγχους ασφαλείας.\nΔυστυχώς, αυτή η επιτρεπτική ρύθμιση μπορούσε να δώσει σε έναν χρήστη ένα ευρύ\nφάσμα δικαιωμάτων που δεν προοριζόταν να έχει. Οι DevOps και SREs έπρεπε να μάθουν\nεπιπλέον διαδικασίες κατά την εγκατάσταση του Tiller σε ένα multi-tenant cluster.\n\nΑφού ακούσαμε πώς τα μέλη της κοινότητας χρησιμοποιούσαν το Helm σε διάφορα\nσενάρια, διαπιστώσαμε ότι το σύστημα διαχείρισης releases του Tiller δεν χρειαζόταν\nνα βασίζεται σε έναν in-cluster operator για να διατηρεί την κατάσταση ή να λειτουργεί\nως κεντρικός κόμβος για τις πληροφορίες release του Helm. Αντ' αυτού, μπορούσαμε\nαπλά να ανακτούμε πληροφορίες από τον Kubernetes API server, να κάνουμε render τα\nCharts στην πλευρά του client και να αποθηκεύουμε μια εγγραφή της εγκατάστασης στο\nKubernetes.\n\nΟ πρωταρχικός στόχος του Tiller μπορούσε να επιτευχθεί χωρίς τον Tiller, οπότε μία\nαπό τις πρώτες αποφάσεις που πήραμε για το Helm 3 ήταν η πλήρης κατάργησή του.\n\nΜε την κατάργηση του Tiller, το μοντέλο ασφαλείας του Helm απλοποιείται ριζικά. Το\nHelm 3 υποστηρίζει πλέον όλες τις σύγχρονες δυνατότητες ασφάλειας, ταυτότητας και\nεξουσιοδότησης του σύγχρονου Kubernetes. Τα δικαιώματα του Helm αξιολογούνται\nχρησιμοποιώντας το [αρχείο kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)\nσας. Οι διαχειριστές του cluster μπορούν να περιορίσουν τα δικαιώματα των χρηστών\nμε όποια λεπτομέρεια επιθυμούν. Τα releases εξακολουθούν να καταγράφονται εντός\nτου cluster και η υπόλοιπη λειτουργικότητα του Helm παραμένει αμετάβλητη.\n\n### Βελτιωμένη Στρατηγική Αναβάθμισης: 3-way Strategic Merge Patches {#improved-upgrade-strategy-3-way-strategic-merge-patches}\n\nΤο Helm 2 χρησιμοποιούσε ένα two-way strategic merge patch. Κατά τη διάρκεια μιας\nαναβάθμισης, συνέκρινε το manifest του πιο πρόσφατου chart με το προτεινόμενο\nmanifest του chart (αυτό που παρέχεται κατά το `helm upgrade`). Συνέκρινε τις\nδιαφορές μεταξύ αυτών των δύο charts για να προσδιορίσει ποιες αλλαγές έπρεπε να\nεφαρμοστούν στους πόρους του Kubernetes. Αν εφαρμόζονταν αλλαγές στο cluster\nεκτός του Helm (όπως κατά τη διάρκεια ενός `kubectl edit`), αυτές οι αλλαγές δεν\nλαμβάνονταν υπόψη. Αυτό είχε ως αποτέλεσμα οι πόροι να μην μπορούν να επαναφερθούν\nστην προηγούμενη κατάστασή τους: επειδή το Helm θεωρούσε μόνο το τελευταίο\nεφαρμοσμένο manifest του chart ως την τρέχουσα κατάσταση, αν δεν υπήρχαν αλλαγές\nστην κατάσταση του chart, η live κατάσταση παρέμενε αμετάβλητη.\n\nΣτο Helm 3, χρησιμοποιούμε πλέον ένα three-way strategic merge patch. Το Helm\nλαμβάνει υπόψη το παλιό manifest, τη live κατάστασή του και το νέο manifest κατά\nτη δημιουργία ενός patch.\n\n#### Παραδείγματα {#examples}\n\nΑς δούμε μερικά συνηθισμένα παραδείγματα για το πώς επηρεάζει αυτή η αλλαγή.\n\n##### Επαναφορά όταν η live κατάσταση έχει αλλάξει {#rolling-back-where-live-state-has-changed}\n\nΗ ομάδα σας μόλις έκανε deploy την εφαρμογή της στο production στο Kubernetes\nχρησιμοποιώντας το Helm. Το chart περιέχει ένα αντικείμενο Deployment όπου ο\nαριθμός των replicas έχει οριστεί σε τρία:\n\n```console\n$ helm install myapp ./myapp\n```\n\nΈνας νέος developer εντάσσεται στην ομάδα. Την πρώτη του ημέρα, ενώ παρατηρεί το\nproduction cluster, συμβαίνει ένα φρικτό ατύχημα με καφέ που χύνεται στο\nπληκτρολόγιο και κάνει `kubectl scale` το production deployment από τρία replicas\nσε μηδέν.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nΈνας άλλος developer της ομάδας σας παρατηρεί ότι το production site είναι εκτός\nλειτουργίας και αποφασίζει να κάνει rollback το release στην προηγούμενη κατάστασή\nτου:\n\n```console\n$ helm rollback myapp\n```\n\nΤι συμβαίνει;\n\nΣτο Helm 2, θα δημιουργούσε ένα patch συγκρίνοντας το παλιό manifest με το νέο\nmanifest. Επειδή πρόκειται για rollback, είναι το ίδιο manifest. Το Helm θα\nκαθόριζε ότι δεν υπάρχει τίποτα να αλλάξει επειδή δεν υπάρχει διαφορά μεταξύ του\nπαλιού και του νέου manifest. Ο αριθμός των replicas συνεχίζει να παραμένει στο\nμηδέν. Ακολουθεί πανικός.\n\nΣτο Helm 3, το patch δημιουργείται χρησιμοποιώντας το παλιό manifest, τη live\nκατάσταση και το νέο manifest. Το Helm αναγνωρίζει ότι η παλιά κατάσταση ήταν\nτρία, η live κατάσταση είναι μηδέν και το νέο manifest επιθυμεί να το αλλάξει\nπίσω σε τρία, οπότε δημιουργεί ένα patch για να επαναφέρει την κατάσταση σε τρία.\n\n##### Αναβαθμίσεις όταν η live κατάσταση έχει αλλάξει {#upgrades-where-live-state-has-changed}\n\nΠολλά service meshes και άλλες εφαρμογές που βασίζονται σε controllers εισάγουν\nδεδομένα σε αντικείμενα Kubernetes. Αυτό μπορεί να είναι κάτι σαν sidecar, labels\nή άλλες πληροφορίες. Προηγουμένως, αν είχατε το παρακάτω manifest που προέκυψε\nαπό ένα Chart:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nΚαι η live κατάσταση τροποποιήθηκε από μια άλλη εφαρμογή σε:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nΤώρα, θέλετε να αναβαθμίσετε το image tag του `nginx` σε `2.1.0`. Οπότε,\nαναβαθμίζετε σε ένα chart με το παρακάτω manifest:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nΤι συμβαίνει;\n\nΣτο Helm 2, το Helm δημιουργεί ένα patch του αντικειμένου `containers` μεταξύ του\nπαλιού manifest και του νέου manifest. Η live κατάσταση του cluster δεν λαμβάνεται\nυπόψη κατά τη δημιουργία του patch.\n\nΗ live κατάσταση του cluster τροποποιείται ώστε να μοιάζει με το εξής:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nΤο sidecar pod αφαιρείται από τη live κατάσταση. Ακολουθεί περισσότερος πανικός.\n\nΣτο Helm 3, το Helm δημιουργεί ένα patch του αντικειμένου `containers` μεταξύ του\nπαλιού manifest, της live κατάστασης και του νέου manifest. Παρατηρεί ότι το νέο\nmanifest αλλάζει το image tag σε `2.1.0`, αλλά η live κατάσταση περιέχει ένα\nsidecar container.\n\nΗ live κατάσταση του cluster τροποποιείται ώστε να μοιάζει με το εξής:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### Τα ονόματα Release περιορίζονται πλέον στο Namespace {#release-names-are-now-scoped-to-the-namespace}\n\nΜε την κατάργηση του Tiller, οι πληροφορίες για κάθε release έπρεπε να αποθηκευτούν\nκάπου. Στο Helm 2, αυτές αποθηκεύονταν στο ίδιο namespace με τον Tiller. Στην\nπράξη, αυτό σήμαινε ότι μόλις χρησιμοποιούνταν ένα όνομα από ένα release, κανένα\nάλλο release δεν μπορούσε να χρησιμοποιήσει το ίδιο όνομα, ακόμα κι αν γινόταν\ndeploy σε διαφορετικό namespace.\n\nΣτο Helm 3, οι πληροφορίες για ένα συγκεκριμένο release αποθηκεύονται πλέον στο\nίδιο namespace με το release. Αυτό σημαίνει ότι οι χρήστες μπορούν πλέον να\nεκτελέσουν `helm install wordpress stable/wordpress` σε δύο ξεχωριστά namespaces\nκαι σε καθένα μπορεί να γίνει αναφορά με `helm list` αλλάζοντας το τρέχον context\nτου namespace (π.χ. `helm list --namespace foo`).\n\nΜε αυτή τη μεγαλύτερη ευθυγράμμιση με τα native cluster namespaces, η εντολή\n`helm list` δεν εμφανίζει πλέον όλα τα releases από προεπιλογή. Αντ' αυτού, θα\nεμφανίσει μόνο τα releases στο namespace του τρέχοντος kubernetes context σας\n(δηλαδή το namespace που εμφανίζεται όταν εκτελείτε `kubectl config view --minify`).\nΑυτό σημαίνει επίσης ότι πρέπει να παρέχετε τη σημαία `--all-namespaces` στην\nεντολή `helm list` για να έχετε συμπεριφορά παρόμοια με το Helm 2.\n\n### Τα Secrets ως προεπιλεγμένος storage driver {#secrets-as-the-default-storage-driver}\n\nΣτο Helm 3, τα Secrets χρησιμοποιούνται πλέον ως [προεπιλεγμένος storage\ndriver](/topics/advanced.md#storage-backends). Το Helm 2 χρησιμοποιούσε ConfigMaps\nαπό προεπιλογή για την αποθήκευση πληροφοριών release. Στο Helm 2.7.0,\nυλοποιήθηκε ένα νέο storage backend που χρησιμοποιεί Secrets για την αποθήκευση\nπληροφοριών release, και είναι πλέον η προεπιλογή από το Helm 3.\n\nΗ αλλαγή σε Secrets ως προεπιλογή του Helm 3 επιτρέπει πρόσθετη ασφάλεια στην\nπροστασία των charts σε συνδυασμό με την κυκλοφορία της κρυπτογράφησης Secret στο\nKubernetes.\n\nΗ [Κρυπτογράφηση secrets σε κατάσταση ηρεμίας](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)\nέγινε διαθέσιμη ως alpha δυνατότητα στο Kubernetes 1.7 και σταθεροποιήθηκε στο\nKubernetes 1.13. Αυτό επιτρέπει στους χρήστες να κρυπτογραφούν τα μεταδεδομένα\nrelease του Helm σε κατάσταση ηρεμίας, και αποτελεί ένα καλό σημείο εκκίνησης\nπου μπορεί να επεκταθεί αργότερα για χρήση κάποιου εργαλείου όπως το Vault.\n\n### Αλλαγές στο Go import path {#go-import-path-changes}\n\nΣτο Helm 3, το Helm άλλαξε το Go import path από `k8s.io/helm` σε\n`helm.sh/helm/v3`. Αν σκοπεύετε να αναβαθμίσετε στις Go client libraries του\nHelm 3, φροντίστε να αλλάξετε τα import paths σας.\n\n### Capabilities {#capabilities}\n\nΤο ενσωματωμένο αντικείμενο `.Capabilities` που είναι διαθέσιμο κατά τη φάση του\nrendering έχει απλοποιηθεί.\n\n[Ενσωματωμένα Αντικείμενα](/chart_template_guide/builtin_objects.md)\n\n### Επικύρωση Chart Values με JSONSchema {#validating-chart-values-with-jsonschema}\n\nΈνα JSON Schema μπορεί πλέον να επιβληθεί στα values ενός chart. Αυτό διασφαλίζει\nότι τα values που παρέχει ο χρήστης ακολουθούν το schema που έχει ορίσει ο\nσυντηρητής του chart, παρέχοντας καλύτερη αναφορά σφαλμάτων όταν ο χρήστης παρέχει\nλανθασμένα values για ένα chart.\n\nΗ επικύρωση πραγματοποιείται όταν εκτελείται οποιαδήποτε από τις παρακάτω εντολές:\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\nΔείτε την τεκμηρίωση για τα [Schema files](/topics/charts.md#schema-files) για\nπερισσότερες πληροφορίες.\n\n### Ενοποίηση του `requirements.yaml` στο `Chart.yaml` {#consolidation-of-requirementsyaml-into-chartyaml}\n\nΤο σύστημα διαχείρισης εξαρτήσεων Chart μεταφέρθηκε από τα requirements.yaml και\nrequirements.lock στα Chart.yaml και Chart.lock. Συνιστούμε τα νέα charts που\nπροορίζονται για το Helm 3 να χρησιμοποιούν τη νέα μορφή. Ωστόσο, το Helm 3\nεξακολουθεί να κατανοεί την έκδοση Chart API 1 (`v1`) και θα φορτώνει υπάρχοντα\nαρχεία `requirements.yaml`.\n\nΣτο Helm 2, έτσι έμοιαζε ένα `requirements.yaml`:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nΣτο Helm 3, η εξάρτηση εκφράζεται με τον ίδιο τρόπο, αλλά πλέον μέσα στο\n`Chart.yaml`:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nΤα charts εξακολουθούν να κατεβαίνουν και να τοποθετούνται στον κατάλογο `charts/`,\nοπότε τα subcharts που έχουν ενσωματωθεί στον κατάλογο `charts/` θα συνεχίσουν να\nλειτουργούν χωρίς τροποποίηση.\n\n### Το Name (ή --generate-name) απαιτείται πλέον κατά την εγκατάσταση {#name-or-generate-name-is-now-required-on-install}\n\nΣτο Helm 2, αν δεν παρεχόταν όνομα, θα δινόταν ένα αυτόματα παραγόμενο όνομα.\nΣτην παραγωγή, αυτό αποδείχτηκε περισσότερο ενόχληση παρά χρήσιμη δυνατότητα.\nΣτο Helm 3, το Helm θα εμφανίσει σφάλμα αν δεν παρέχεται όνομα με το `helm install`.\n\nΓια όσους εξακολουθούν να θέλουν να δημιουργείται αυτόματα ένα όνομα, μπορείτε να\nχρησιμοποιήσετε τη σημαία `--generate-name` για να δημιουργηθεί ένα.\n\n### Αποστολή Charts σε OCI Registries {#pushing-charts-to-oci-registries}\n\nΑυτή είναι μια πειραματική δυνατότητα που εισήχθη στο Helm 3. Για να τη\nχρησιμοποιήσετε, ορίστε τη μεταβλητή περιβάλλοντος `HELM_EXPERIMENTAL_OCI=1`.\n\nΣε υψηλό επίπεδο, ένα Chart Repository είναι μια τοποθεσία όπου μπορούν να\nαποθηκευτούν και να διαμοιραστούν Charts. Ο Helm client συσκευάζει και αποστέλλει\nHelm Charts σε ένα Chart Repository. Με απλά λόγια, ένα Chart Repository είναι\nένας βασικός HTTP server που φιλοξενεί ένα αρχείο index.yaml και μερικά\nσυσκευασμένα charts.\n\nΕνώ υπάρχουν αρκετά οφέλη στο ότι το Chart Repository API καλύπτει τις πιο βασικές\nαπαιτήσεις αποθήκευσης, έχουν αρχίσει να εμφανίζονται μερικά μειονεκτήματα:\n\n- Τα Chart Repositories δυσκολεύονται πολύ να αφαιρέσουν τις περισσότερες από τις\n  υλοποιήσεις ασφαλείας που απαιτούνται σε ένα παραγωγικό περιβάλλον. Η ύπαρξη\n  ενός τυπικού API για authentication και authorization είναι πολύ σημαντική σε\n  παραγωγικά σενάρια.\n- Τα εργαλεία provenance του Helm που χρησιμοποιούνται για την υπογραφή και\n  επαλήθευση της ακεραιότητας και προέλευσης ενός chart αποτελούν προαιρετικό\n  μέρος της διαδικασίας δημοσίευσης Chart.\n- Σε σενάρια multi-tenant, το ίδιο Chart μπορεί να ανεβεί από έναν άλλο tenant,\n  κοστίζοντας διπλάσιο χώρο αποθήκευσης για το ίδιο περιεχόμενο. Έχουν σχεδιαστεί\n  πιο έξυπνα chart repositories για να το αντιμετωπίσουν αυτό, αλλά δεν αποτελεί\n  μέρος της επίσημης προδιαγραφής.\n- Η χρήση ενός μόνο αρχείου index για αναζήτηση, πληροφορίες μεταδεδομένων και\n  ανάκτηση Charts έχει κάνει δύσκολο ή αδέξιο τον σχεδιασμό σε ασφαλείς\n  υλοποιήσεις multi-tenant.\n\nΤο project Distribution του Docker (γνωστό και ως Docker Registry v2) είναι ο\nδιάδοχος του project Docker Registry. Πολλοί μεγάλοι cloud vendors προσφέρουν\nπροϊόν βασισμένο στο project Distribution, και με τόσους vendors να προσφέρουν το\nίδιο προϊόν, το project Distribution έχει επωφεληθεί από πολλά χρόνια\nσκληραγώγησης, βέλτιστων πρακτικών ασφαλείας και δοκιμών στην πράξη.\n\nΠαρακαλούμε δείτε τα `helm help chart` και `helm help registry` για περισσότερες\nπληροφορίες σχετικά με το πώς να συσκευάσετε ένα chart και να το αποστείλετε σε\nένα Docker registry.\n\nΓια περισσότερες πληροφορίες, δείτε [αυτή τη σελίδα](/topics/registries.md).\n\n### Κατάργηση του `helm serve` {#removal-of-helm-serve}\n\nΗ εντολή `helm serve` εκτελούσε ένα τοπικό Chart Repository στον υπολογιστή σας\nγια σκοπούς ανάπτυξης. Ωστόσο, δεν είχε μεγάλη υιοθέτηση ως εργαλείο ανάπτυξης\nκαι είχε πολλά προβλήματα με τον σχεδιασμό της. Τελικά, αποφασίσαμε να την\nαφαιρέσουμε και να τη διαχωρίσουμε ως plugin.\n\nΓια μια παρόμοια εμπειρία με το `helm serve`, δείτε την επιλογή αποθήκευσης σε\nτοπικό filesystem στο [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\nκαι το [plugin servecm](https://github.com/jdolitsky/helm-servecm).\n\n\n### Υποστήριξη library chart {#library-chart-support}\n\nΤο Helm 3 υποστηρίζει μια κατηγορία chart που ονομάζεται \"library chart\". Αυτό\nείναι ένα chart που διαμοιράζεται από άλλα charts, αλλά δεν δημιουργεί δικά του\nrelease artifacts. Τα templates ενός library chart μπορούν να δηλώνουν μόνο\nστοιχεία `define`. Περιεχόμενο με global scope που δεν είναι `define` απλά\nαγνοείται. Αυτό επιτρέπει στους χρήστες να επαναχρησιμοποιούν και να μοιράζονται\nαποσπάσματα κώδικα που μπορούν να χρησιμοποιηθούν σε πολλά charts, αποφεύγοντας\nτην επανάληψη και διατηρώντας τα charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nΤα library charts δηλώνονται στην οδηγία dependencies στο Chart.yaml, και\nεγκαθίστανται και διαχειρίζονται όπως οποιοδήποτε άλλο chart.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nΕίμαστε πολύ ενθουσιασμένοι να δούμε τις περιπτώσεις χρήσης που αυτή η δυνατότητα\nανοίγει για τους developers chart, καθώς και τις βέλτιστες πρακτικές που\nπροκύπτουν από τη χρήση library charts.\n\n### Αναβάθμιση του apiVersion στο Chart.yaml {#chartyaml-apiversion-bump}\n\nΜε την εισαγωγή της υποστήριξης library chart και την ενοποίηση του\nrequirements.yaml στο Chart.yaml, τα clients που κατανοούσαν τη μορφή πακέτου\nτου Helm 2 δεν θα κατανοούν αυτές τις νέες δυνατότητες. Έτσι, αυξήσαμε το\napiVersion στο Chart.yaml από `v1` σε `v2`.\n\nΗ εντολή `helm create` δημιουργεί πλέον charts χρησιμοποιώντας αυτή τη νέα μορφή,\nοπότε το προεπιλεγμένο apiVersion αυξήθηκε και εκεί.\n\nΤα clients που επιθυμούν να υποστηρίζουν και τις δύο εκδόσεις Helm charts θα\nπρέπει να ελέγχουν το πεδίο `apiVersion` στο Chart.yaml για να κατανοήσουν πώς\nνα αναλύσουν τη μορφή του πακέτου.\n\n### Υποστήριξη XDG Base Directory {#xdg-base-directory-support}\n\nΗ [Προδιαγραφή XDG Base Directory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)\nείναι ένα φορητό πρότυπο που ορίζει πού θα πρέπει να αποθηκεύονται τα αρχεία\nρύθμισης, δεδομένων και cache στο filesystem.\n\nΣτο Helm 2, το Helm αποθήκευε όλες αυτές τις πληροφορίες στο `~/.helm`\n(στοργικά γνωστό ως `helm home`), το οποίο μπορούσε να αλλάξει ορίζοντας τη\nμεταβλητή περιβάλλοντος `$HELM_HOME` ή χρησιμοποιώντας τη global σημαία `--home`.\n\nΣτο Helm 3, το Helm σέβεται πλέον τις ακόλουθες μεταβλητές περιβάλλοντος σύμφωνα\nμε την Προδιαγραφή XDG Base Directory:\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nΣτα Helm plugins εξακολουθεί να περνιέται το `$HELM_HOME` ως alias για το\n`$XDG_DATA_HOME` για συμβατότητα προς τα πίσω με plugins που αναζητούν το\n`$HELM_HOME` ως scratchpad περιβάλλον.\n\nΑρκετές νέες μεταβλητές περιβάλλοντος περνιούνται επίσης στο περιβάλλον του\nplugin για να υποστηρίξουν αυτή την αλλαγή:\n\n- `$HELM_PATH_CACHE` για τη διαδρομή cache\n- `$HELM_PATH_CONFIG` για τη διαδρομή config\n- `$HELM_PATH_DATA` για τη διαδρομή data\n\nΤα Helm plugins που επιθυμούν να υποστηρίξουν το Helm 3 θα πρέπει να εξετάσουν\nτη χρήση αυτών των νέων μεταβλητών περιβάλλοντος αντί αυτών.\n\n### Μετονομασίες εντολών CLI {#cli-command-renames}\n\nΓια καλύτερη ευθυγράμμιση της ορολογίας με άλλους package managers, η εντολή\n`helm delete` μετονομάστηκε σε `helm uninstall`. Η `helm delete` διατηρείται\nακόμα ως alias για την `helm uninstall`, οπότε μπορεί να χρησιμοποιηθεί\nοποιαδήποτε από τις δύο μορφές.\n\nΣτο Helm 2, για να διαγραφεί το ledger του release, έπρεπε να παρέχεται η σημαία\n`--purge`. Αυτή η λειτουργικότητα είναι πλέον ενεργοποιημένη από προεπιλογή.\nΓια να διατηρήσετε την προηγούμενη συμπεριφορά, χρησιμοποιήστε\n`helm uninstall --keep-history`.\n\nΕπιπλέον, αρκετές άλλες εντολές μετονομάστηκαν για να συμβαδίζουν με τις ίδιες\nσυμβάσεις:\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\nΑυτές οι εντολές έχουν επίσης διατηρήσει τα παλαιότερα ρήματα ως aliases, οπότε\nμπορείτε να συνεχίσετε να τις χρησιμοποιείτε σε οποιαδήποτε μορφή.\n\n### Αυτόματη δημιουργία namespaces {#automatically-creating-namespaces}\n\nΚατά τη δημιουργία ενός release σε ένα namespace που δεν υπάρχει, το Helm 2\nδημιουργούσε το namespace. Το Helm 3 ακολουθεί τη συμπεριφορά άλλων εργαλείων\nKubernetes και επιστρέφει σφάλμα αν το namespace δεν υπάρχει. Το Helm 3 θα\nδημιουργήσει το namespace αν ορίσετε ρητά τη σημαία `--create-namespace`.\n\n### Τι συνέβη με το .Chart.ApiVersion; {#what-happened-to-chartapiversion}\n\nΤο Helm ακολουθεί τη συνηθισμένη σύμβαση CamelCasing που είναι να γράφονται τα\nαρκτικόλεξα με κεφαλαία. Το έχουμε κάνει αυτό αλλού στον κώδικα, όπως με το\n`.Capabilities.APIVersions.Has`. Στο Helm v3, διορθώσαμε το `.Chart.ApiVersion`\nώστε να ακολουθεί αυτό το μοτίβο, μετονομάζοντάς το σε `.Chart.APIVersion`.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: Εγκατάσταση\nsidebar_position: 2\n---\n\n## Εγκατάσταση {#installing}\n\n### Γιατί δεν υπάρχουν native packages του Helm για Fedora και άλλες διανομές Linux; {#why-arent-there-native-packages-of-helm-for-fedora-and-other-linux-distros}\n\nΤο project Helm δεν διατηρεί packages για λειτουργικά συστήματα και περιβάλλοντα. Η κοινότητα του Helm μπορεί να παρέχει native packages και αν το project Helm ενημερωθεί γι' αυτά, θα καταχωρηθούν. Με αυτόν τον τρόπο ξεκίνησε και προστέθηκε το Homebrew formula. Αν ενδιαφέρεστε να διατηρήσετε ένα package, θα χαρούμε πολύ.\n\n### Γιατί παρέχετε ένα script `curl ...|bash`; {#why-do-you-provide-a-curl-bash-script}\n\nΥπάρχει ένα script στο αποθετήριό μας (`scripts/get-helm-3`) που μπορεί να εκτελεστεί ως script `curl ..|bash`. Όλες οι μεταφορές προστατεύονται μέσω HTTPS και το script πραγματοποιεί κάποιους ελέγχους στα packages που κατεβάζει. Ωστόσο, το script έχει όλους τους συνήθεις κινδύνους οποιουδήποτε shell script.\n\nΤο παρέχουμε επειδή είναι χρήσιμο, αλλά προτείνουμε στους χρήστες να διαβάσουν προσεκτικά το script πρώτα. Αυτό που πραγματικά θα θέλαμε, ωστόσο, είναι πιο ολοκληρωμένες εκδόσεις του Helm.\n\n### Πώς μπορώ να τοποθετήσω τα αρχεία του Helm client σε διαφορετική θέση από τις προεπιλογές; {#how-do-i-put-the-helm-client-files-somewhere-other-than-their-defaults}\n\nΤο Helm χρησιμοποιεί τη δομή XDG για την αποθήκευση αρχείων. Υπάρχουν μεταβλητές περιβάλλοντος που μπορείτε να χρησιμοποιήσετε για να παρακάμψετε αυτές τις τοποθεσίες:\n\n- `$XDG_CACHE_HOME`: ορίστε μια εναλλακτική τοποθεσία για την αποθήκευση αρχείων cache.\n- `$XDG_CONFIG_HOME`: ορίστε μια εναλλακτική τοποθεσία για την αποθήκευση της διαμόρφωσης του Helm.\n- `$XDG_DATA_HOME`: ορίστε μια εναλλακτική τοποθεσία για την αποθήκευση δεδομένων του Helm.\n\nΣημειώστε ότι αν έχετε υπάρχοντα αποθετήρια, θα πρέπει να τα προσθέσετε ξανά με την εντολή `helm repo add...`.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: Αντιμετώπιση Προβλημάτων\nsidebar_position: 4\n---\n\n## Αντιμετώπιση Προβλημάτων {#troubleshooting}\n\n### Λαμβάνω μια προειδοποίηση σχετικά με \"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}\n\nΕκτελέστε `helm repo list`. Αν το αποθετήριο `stable` χρησιμοποιεί URL από το `storage.googleapis.com`, θα πρέπει να το ενημερώσετε. Στις 13 Νοεμβρίου 2020, το αποθετήριο Helm Charts [έπαψε να υποστηρίζεται](https://github.com/helm/charts#deprecation-timeline) μετά από μια περίοδο κατάργησης ενός έτους. Ένα αρχείο είναι διαθέσιμο στο `https://charts.helm.sh/stable` αλλά δεν θα λαμβάνει πλέον ενημερώσεις.\n\nΜπορείτε να εκτελέσετε την ακόλουθη εντολή για να διορθώσετε το αποθετήριο σας:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nΤο ίδιο ισχύει για το αποθετήριο `incubator`, το οποίο έχει ένα αρχείο διαθέσιμο στο https://charts.helm.sh/incubator. Μπορείτε να εκτελέσετε την ακόλουθη εντολή για να το επιδιορθώσετε:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Λαμβάνω την προειδοποίηση '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}\n\nΤο παλιό αποθετήριο chart της Google έχει αντικατασταθεί από ένα νέο αποθετήριο Helm chart.\n\nΕκτελέστε την ακόλουθη εντολή για να διορθώσετε αυτό μόνιμα:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nΑν λάβετε παρόμοιο σφάλμα για το `incubator`, εκτελέστε αυτή την εντολή:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Όταν προσθέτω ένα 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}\n\nΤα αποθετήρια 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`.\n\n### Στο GKE (Google Container Engine) λαμβάνω \"No SSH tunnels currently open\" {#on-gke-google-container-engine-i-get-no-ssh-tunnels-currently-open}\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nΜια άλλη παραλλαγή του μηνύματος σφάλματος είναι:\n\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nΤο πρόβλημα είναι ότι το τοπικό σας αρχείο ρυθμίσεων Kubernetes πρέπει να έχει τα σωστά credentials.\n\nΌταν δημιουργείτε ένα cluster στο GKE, θα λάβετε credentials, συμπεριλαμβανομένων πιστοποιητικών SSL και αρχών πιστοποίησης. Αυτά πρέπει να αποθηκευτούν σε ένα αρχείο ρυθμίσεων Kubernetes (Προεπιλογή: `~/.kube/config`) ώστε οι `kubectl` και `helm` να έχουν πρόσβαση σε αυτά.\n\n### Μετά τη μετάβαση από το Helm 2, το `helm list` εμφανίζει μόνο μερικά (ή κανένα) από τα releases μου {#after-migration-from-helm-2-helm-list-shows-only-some-or-none-of-my-releases}\n\nΠιθανώς δεν έχετε λάβει υπόψη ότι το Helm 3 χρησιμοποιεί πλέον τα namespaces του cluster για τον περιορισμό των releases. Αυτό σημαίνει ότι για όλες τις εντολές που αναφέρονται σε ένα release πρέπει είτε:\n\n* να βασίζεστε στο τρέχον namespace στο ενεργό kubernetes context (όπως περιγράφεται από την εντολή `kubectl config view --minify`),\n* να καθορίσετε το σωστό namespace χρησιμοποιώντας το flag `--namespace`/`-n`, ή\n* για την εντολή `helm list`, να καθορίσετε το flag `--all-namespaces`/`-A`\n\nΑυτό ισχύει για τα `helm ls`, `helm uninstall`, και όλες τις άλλες εντολές `helm` που αναφέρονται σε ένα release.\n\n\n### Σε macOS, γίνεται πρόσβαση στο αρχείο `/etc/.mdns_debug`. Γιατί; {#on-macos-the-file-etcmdns_debug-is-accessed-why}\n\nΓνωρίζουμε μια περίπτωση σε macOS όπου το Helm προσπαθεί να αποκτήσει πρόσβαση σε ένα αρχείο με όνομα `/etc/.mdns_debug`. Αν το αρχείο υπάρχει, το Helm κρατά το file handle ανοιχτό κατά την εκτέλεση.\n\nΑυτό προκαλείται από τη βιβλιοθήκη MDNS του macOS. Προσπαθεί να φορτώσει αυτό το αρχείο για να διαβάσει ρυθμίσεις debugging (αν είναι ενεργοποιημένες). Το file handle πιθανώς δεν θα έπρεπε να παραμένει ανοιχτό, και αυτό το ζήτημα έχει αναφερθεί στην Apple. Ωστόσο, είναι το macOS, όχι το Helm, που προκαλεί αυτή τη συμπεριφορά.\n\nΑν δεν θέλετε το Helm να φορτώνει αυτό το αρχείο, μπορείτε ίσως να μεταγλωττίσετε το Helm ως static library που δεν χρησιμοποιεί τη στοίβα δικτύου του host. Αυτό θα αυξήσει το μέγεθος του binary του Helm, αλλά θα αποτρέψει το άνοιγμα του αρχείου.\n\nΑυτό το ζήτημα αρχικά επισημάνθηκε ως πιθανό πρόβλημα ασφάλειας. Ωστόσο, έχει διαπιστωθεί ότι δεν υπάρχει κανένα ελάττωμα ή ευπάθεια που προκαλείται από αυτή τη συμπεριφορά.\n\n### Το helm repo add αποτυγχάνει ενώ λειτουργούσε παλιότερα {#helm-repo-add-fails-when-it-used-to-work}\n\nΣτο helm 3.3.1 και παλαιότερα, η εντολή `helm repo add <reponame> <url>` δεν έδινε καμία έξοδο αν προσπαθούσατε να προσθέσετε ένα αποθετήριο που υπήρχε ήδη. Το flag `--no-update` θα προκαλούσε σφάλμα αν το αποθετήριο ήταν ήδη καταχωρημένο.\n\nΣτο helm 3.3.2 και μεταγενέστερα, μια προσπάθεια προσθήκης υπάρχοντος αποθετηρίου θα προκαλέσει σφάλμα:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nΗ προεπιλεγμένη συμπεριφορά έχει πλέον αντιστραφεί. Το `--no-update` αγνοείται πλέον, ενώ αν θέλετε να αντικαταστήσετε ένα υπάρχον αποθετήριο, μπορείτε να χρησιμοποιήσετε το `--force-update`.\n\nΑυτό οφείλεται σε μια breaking change για διόρθωση ασφαλείας, όπως εξηγείται στις [σημειώσεις έκδοσης του Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2).\n\n### Ενεργοποίηση της καταγραφής του Kubernetes client {#enabling-kubernetes-client-logging}\n\nΗ εκτύπωση μηνυμάτων καταγραφής για τον εντοπισμό σφαλμάτων του Kubernetes client μπορεί να ενεργοποιηθεί χρησιμοποιώντας τα flags του [klog](https://pkg.go.dev/k8s.io/klog). Η χρήση του flag `-v` για να ορίσετε το επίπεδο λεπτομέρειας θα είναι αρκετή για τις περισσότερες περιπτώσεις.\n\nΓια παράδειγμα:\n\n```\nhelm list -v 6\n```\n\n### Οι εγκαταστάσεις Tiller σταμάτησαν να λειτουργούν και η πρόσβαση απορρίπτεται {#tiller-installations-stopped-working-and-access-is-denied}\n\nΤα releases του Helm ήταν διαθέσιμα από το <https://storage.googleapis.com/kubernetes-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.\n\n\nΑν προσπαθείτε να κατεβάσετε παλαιότερες εκδόσεις του Helm από το storage bucket που χρησιμοποιούσατε στο παρελθόν, μπορεί να διαπιστώσετε ότι λείπουν:\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\nΗ [παλιά τοποθεσία 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, αντικαταστήστε:\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\nμε:\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nΓια να αρχικοποιήσετε με το Helm v2.17.0:\n\n`helm init —upgrade`\n\nΉ αν χρειάζεται διαφορετική έκδοση, χρησιμοποιήστε το flag --tiller-image για να αντικαταστήσετε την προεπιλεγμένη τοποθεσία και να εγκαταστήσετε μια συγκεκριμένη έκδοση Helm v2:\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**Σημείωση:** Οι συντηρητές του 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) σήμερα.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: Απεγκατάσταση\nsidebar_position: 3\n---\n\n## Απεγκατάσταση {#uninstalling}\n\n### Θέλω να διαγράψω το τοπικό μου Helm. Πού βρίσκονται όλα τα αρχεία του; {#i-want-to-delete-my-local-helm-where-are-all-its-files}\n\nΠέρα από το binary `helm`, το Helm αποθηκεύει ορισμένα αρχεία στις ακόλουθες τοποθεσίες:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nΟ παρακάτω πίνακας δείχνει τον προεπιλεγμένο φάκελο για καθεμία από αυτές, ανά λειτουργικό σύστημα:\n\n| Λειτουργικό Σύστημα | Διαδρομή Cache              | Διαδρομή Ρυθμίσεων               | Διαδρομή Δεδομένων          |\n|---------------------|-----------------------------|----------------------------------|-----------------------------|\n| Linux               | `$HOME/.cache/helm `        | `$HOME/.config/helm `            | `$HOME/.local/share/helm`   |\n| macOS               | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm `       |\n| Windows             | `%TEMP%\\helm  `             | `%APPDATA%\\helm `                | `%APPDATA%\\helm`            |\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\nΟ διαχειριστής πακέτων Helm για το Kubernetes.\n\n### Σύνοψη {#synopsis}\n\nΟ διαχειριστής πακέτων του Kubernetes\n\nΣυνήθεις ενέργειες για το Helm:\n\n- helm search:    αναζήτηση για charts\n- helm pull:      λήψη ενός chart στον τοπικό σας κατάλογο για προβολή\n- helm install:   μεταφόρτωση του chart στο Kubernetes\n- helm list:      λίστα με τα releases των charts\n\nΜεταβλητές περιβάλλοντος:\n\n| Όνομα                              | Περιγραφή                                                                                                         |\n|------------------------------------|-------------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | ορίζει μια εναλλακτική τοποθεσία για την αποθήκευση cached αρχείων.                                                |\n| $HELM_CONFIG_HOME                  | ορίζει μια εναλλακτική τοποθεσία για την αποθήκευση της διαμόρφωσης του Helm.                                      |\n| $HELM_DATA_HOME                    | ορίζει μια εναλλακτική τοποθεσία για την αποθήκευση δεδομένων του Helm.                                            |\n| $HELM_DEBUG                        | υποδεικνύει αν το Helm εκτελείται σε λειτουργία Debug                                                              |\n| $HELM_DRIVER                       | ορίζει το backend storage driver. Τιμές: configmap, secret, memory, sql.                                          |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | ορίζει το connection string που θα χρησιμοποιήσει το SQL storage driver.                                          |\n| $HELM_MAX_HISTORY                  | ορίζει τον μέγιστο αριθμό του ιστορικού εκδόσεων του helm.                                                         |\n| $HELM_NAMESPACE                    | ορίζει το namespace που χρησιμοποιείται για τις λειτουργίες του helm.                                              |\n| $HELM_NO_PLUGINS                   | απενεργοποιεί τα plugins. Ορίστε HELM_NO_PLUGINS=1 για απενεργοποίηση.                                             |\n| $HELM_PLUGINS                      | ορίζει τη διαδρομή προς τον κατάλογο των plugins                                                                   |\n| $HELM_REGISTRY_CONFIG              | ορίζει τη διαδρομή προς το αρχείο διαμόρφωσης του registry.                                                        |\n| $HELM_REPOSITORY_CACHE             | ορίζει τη διαδρομή προς τον κατάλογο cache του repository                                                          |\n| $HELM_REPOSITORY_CONFIG            | ορίζει τη διαδρομή προς το αρχείο repositories.                                                                    |\n| $KUBECONFIG                        | ορίζει ένα εναλλακτικό αρχείο διαμόρφωσης Kubernetes (προεπιλογή \"~/.kube/config\")                                 |\n| $HELM_KUBEAPISERVER                | ορίζει το Kubernetes API Server Endpoint για πιστοποίηση                                                           |\n| $HELM_KUBECAFILE                   | ορίζει το αρχείο certificate authority του Kubernetes.                                                             |\n| $HELM_KUBEASGROUPS                 | ορίζει τα Groups για προσωποποίηση χρησιμοποιώντας μια λίστα διαχωρισμένη με κόμμα.                                 |\n| $HELM_KUBEASUSER                   | ορίζει το Username για προσωποποίηση για τη λειτουργία.                                                            |\n| $HELM_KUBECONTEXT                  | ορίζει το όνομα του kubeconfig context.                                                                            |\n| $HELM_KUBETOKEN                    | ορίζει το Bearer KubeToken που χρησιμοποιείται για πιστοποίηση.                                                    |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | υποδεικνύει αν η επαλήθευση του πιστοποιητικού του Kubernetes API server θα πρέπει να παραλειφθεί (μη ασφαλές)     |\n| $HELM_KUBETLS_SERVER_NAME          | ορίζει το όνομα διακομιστή που χρησιμοποιείται για την επαλήθευση του πιστοποιητικού του Kubernetes API server     |\n| $HELM_BURST_LIMIT                  | ορίζει το προεπιλεγμένο όριο burst σε περίπτωση που ο server περιέχει πολλά CRDs (προεπιλογή 100, -1 για απενεργοποίηση) |\n| $HELM_QPS                          | ορίζει τα Queries Per Second σε περιπτώσεις όπου ένας υψηλός αριθμός κλήσεων υπερβαίνει την επιλογή για υψηλότερες τιμές burst |\n\nΤο Helm αποθηκεύει cache, διαμόρφωση και δεδομένα με βάση την ακόλουθη σειρά διαμόρφωσης:\n\n- Αν έχει οριστεί μια μεταβλητή περιβάλλοντος HELM_*_HOME, θα χρησιμοποιηθεί αυτή\n- Διαφορετικά, σε συστήματα που υποστηρίζουν την προδιαγραφή XDG base directory, θα χρησιμοποιηθούν οι μεταβλητές XDG\n- Όταν δεν έχει οριστεί άλλη τοποθεσία, θα χρησιμοποιηθεί μια προεπιλεγμένη τοποθεσία με βάση το λειτουργικό σύστημα\n\nΑπό προεπιλογή, οι προεπιλεγμένοι κατάλογοι εξαρτώνται από το λειτουργικό σύστημα. Οι προεπιλογές παρατίθενται παρακάτω:\n\n| Λειτουργικό Σύστημα | Διαδρομή Cache            | Διαδρομή Διαμόρφωσης           | Διαδρομή Δεδομένων        |\n|---------------------|---------------------------|--------------------------------|---------------------------|\n| Linux               | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm   |\n| macOS               | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm        |\n| Windows             | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm            |\n\n\n### Επιλογές {#options}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n  -h, --help                            help for helm\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm completion](./helm_completion.md)\t - δημιουργία scripts αυτόματης συμπλήρωσης για το καθορισμένο shell\n* [helm create](./helm_create.md)\t - δημιουργία νέου chart με το δοσμένο όνομα\n* [helm dependency](./helm_dependency.md)\t - διαχείριση των εξαρτήσεων ενός chart\n* [helm env](./helm_env.md)\t - πληροφορίες περιβάλλοντος του Helm client\n* [helm get](./helm_get.md)\t - λήψη εκτεταμένων πληροφοριών για ένα συγκεκριμένο release\n* [helm history](./helm_history.md)\t - ανάκτηση ιστορικού release\n* [helm install](./helm_install.md)\t - εγκατάσταση ενός chart\n* [helm lint](./helm_lint.md)\t - εξέταση ενός chart για πιθανά προβλήματα\n* [helm list](./helm_list.md)\t - λίστα releases\n* [helm package](./helm_package.md)\t - πακετάρισμα ενός καταλόγου chart σε αρχείο chart\n* [helm plugin](./helm_plugin.md)\t - εγκατάσταση, λίστα ή απεγκατάσταση Helm plugins\n* [helm pull](./helm_pull.md)\t - λήψη ενός chart από ένα repository και (προαιρετικά) αποσυμπίεσή του σε τοπικό κατάλογο\n* [helm push](./helm_push.md)\t - αποστολή ενός chart σε απομακρυσμένο server\n* [helm registry](./helm_registry.md)\t - σύνδεση ή αποσύνδεση από ένα registry\n* [helm repo](./helm_repo.md)\t - προσθήκη, λίστα, αφαίρεση, ενημέρωση και ευρετηρίαση chart repositories\n* [helm rollback](./helm_rollback.md)\t - επαναφορά ενός release σε προηγούμενη αναθεώρηση\n* [helm search](./helm_search.md)\t - αναζήτηση λέξης-κλειδιού σε charts\n* [helm show](./helm_show.md)\t - εμφάνιση πληροφοριών ενός chart\n* [helm status](./helm_status.md)\t - εμφάνιση της κατάστασης του συγκεκριμένου release\n* [helm template](./helm_template.md)\t - τοπική απόδοση templates\n* [helm test](./helm_test.md)\t - εκτέλεση δοκιμών για ένα release\n* [helm uninstall](./helm_uninstall.md)\t - απεγκατάσταση ενός release\n* [helm upgrade](./helm_upgrade.md)\t - αναβάθμιση ενός release\n* [helm verify](./helm_verify.md)\t - επαλήθευση ότι ένα chart στη δοσμένη διαδρομή έχει υπογραφεί και είναι έγκυρο\n* [helm version](./helm_version.md)\t - εκτύπωση πληροφοριών έκδοσης του client\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\nδημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος\n\n### Σύνοψη {#synopsis}\n\n\nΔημιουργεί σενάρια αυτόματης συμπλήρωσης για το Helm για το καθορισμένο κέλυφος.\n\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for completion\n```\n\n### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](./helm.md)\t - Ο διαχειριστής πακέτων Helm για το Kubernetes.\n* [helm completion bash](./helm_completion_bash.md)\t - δημιουργεί σενάριο αυτόματης συμπλήρωσης για το bash\n* [helm completion fish](./helm_completion_fish.md)\t - δημιουργεί σενάριο αυτόματης συμπλήρωσης για το fish\n* [helm completion powershell](./helm_completion_powershell.md)\t - δημιουργεί σενάριο αυτόματης συμπλήρωσης για το powershell\n* [helm completion zsh](./helm_completion_zsh.md)\t - δημιουργεί σενάριο αυτόματης συμπλήρωσης για το zsh\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\nδημιουργεί σενάριο αυτόματης συμπλήρωσης για το bash\n\n### Σύνοψη {#synopsis}\n\n\nΔημιουργεί το σενάριο αυτόματης συμπλήρωσης για το Helm για το κέλυφος bash.\n\nΓια να φορτώσετε την αυτόματη συμπλήρωση στην τρέχουσα συνεδρία του κελύφους σας:\n\n    source <(helm completion bash)\n\nΓια να φορτώσετε την αυτόματη συμπλήρωση για κάθε νέα συνεδρία, εκτελέστε μία φορά:\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n\n```\nhelm completion bash [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help              help for bash\n      --no-descriptions   disable completion descriptions\n```\n\n### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm completion](./helm_completion.md)\t - δημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\nδημιουργεί σενάριο αυτόματης συμπλήρωσης για το fish\n\n### Σύνοψη {#synopsis}\n\n\nΔημιουργεί το σενάριο αυτόματης συμπλήρωσης για το Helm για το κέλυφος fish.\n\nΓια να φορτώσετε την αυτόματη συμπλήρωση στην τρέχουσα συνεδρία του κελύφους σας:\n\n    helm completion fish | source\n\nΓια να φορτώσετε την αυτόματη συμπλήρωση για κάθε νέα συνεδρία, εκτελέστε μία φορά:\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\nΘα χρειαστεί να ξεκινήσετε ένα νέο κέλυφος για να τεθεί σε ισχύ αυτή η ρύθμιση.\n\n\n```\nhelm completion fish [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help              help for fish\n      --no-descriptions   disable completion descriptions\n```\n\n### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm completion](./helm_completion.md)\t - δημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\nδημιουργεί σενάριο αυτόματης συμπλήρωσης για το powershell\n\n### Σύνοψη {#synopsis}\n\n\nΔημιουργεί το σενάριο αυτόματης συμπλήρωσης για το powershell.\n\nΓια να φορτώσετε την αυτόματη συμπλήρωση στην τρέχουσα συνεδρία του κελύφους σας:\n\n    PS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\nΓια να φορτώσετε την αυτόματη συμπλήρωση για κάθε νέα συνεδρία, προσθέστε την έξοδο της παραπάνω εντολής\nστο powershell profile σας.\n\n\n```\nhelm completion powershell [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help              help for powershell\n      --no-descriptions   disable completion descriptions\n```\n\n### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm completion](./helm_completion.md)\t - δημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\nδημιουργεί σενάριο αυτόματης συμπλήρωσης για το zsh\n\n### Σύνοψη {#synopsis}\n\n\nΔημιουργεί το σενάριο αυτόματης συμπλήρωσης για το Helm για το κέλυφος zsh.\n\nΓια να φορτώσετε την αυτόματη συμπλήρωση στην τρέχουσα συνεδρία του κελύφους σας:\n\n    source <(helm completion zsh)\n\nΓια να φορτώσετε την αυτόματη συμπλήρωση για κάθε νέα συνεδρία, εκτελέστε μία φορά:\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help              help for zsh\n      --no-descriptions   disable completion descriptions\n```\n\n### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm completion](./helm_completion.md)\t - δημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n\nδημιουργεί ένα νέο chart με το δοθέν όνομα\n\n### Σύνοψη {#synopsis}\n\n\nΑυτή η εντολή δημιουργεί έναν κατάλογο chart μαζί με τα κοινά αρχεία και\nτους καταλόγους που χρησιμοποιούνται σε ένα chart.\n\nΓια παράδειγμα, η εντολή 'helm create foo' θα δημιουργήσει μια δομή καταλόγου\nπου μοιάζει κάπως έτσι:\n\n    foo/\n    ├── .helmignore   # Περιέχει μοτίβα που αγνοούνται κατά το πακετάρισμα των Helm charts.\n    ├── Chart.yaml    # Πληροφορίες σχετικά με το chart σας\n    ├── values.yaml   # Οι προεπιλεγμένες τιμές για τα templates σας\n    ├── charts/       # Charts από τα οποία εξαρτάται αυτό το chart\n    └── templates/    # Τα αρχεία templates\n        └── tests/    # Τα αρχεία δοκιμών\n\nΗ εντολή 'helm create' δέχεται μια διαδρομή ως όρισμα. Αν οι κατάλογοι στη\nδοθείσα διαδρομή δεν υπάρχουν, το Helm θα προσπαθήσει να τους δημιουργήσει\nκαθώς προχωρά. Αν ο δοθείς προορισμός υπάρχει και υπάρχουν αρχεία σε αυτόν\nτον κατάλογο, τα αρχεία που έρχονται σε σύγκρουση θα αντικατασταθούν, αλλά\nτα υπόλοιπα αρχεία θα παραμείνουν ανέπαφα.\n\n\n```\nhelm create NAME [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help             help for create\n  -p, --starter string   the name or absolute path to Helm starter scaffold\n```\n\n### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](./helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\nδιαχείριση εξαρτήσεων ενός chart\n\n### Σύνοψη {#synopsis}\n\n\nΔιαχείριση των εξαρτήσεων ενός chart.\n\nΤα Helm charts αποθηκεύουν τις εξαρτήσεις τους στον κατάλογο 'charts/'. Για τους\nπρογραμματιστές charts, είναι συχνά πιο εύκολο να διαχειρίζονται τις εξαρτήσεις\nμέσω του 'Chart.yaml', το οποίο δηλώνει όλες τις εξαρτήσεις.\n\nΟι εντολές dependency λειτουργούν με αυτό το αρχείο, διευκολύνοντας τον\nσυγχρονισμό μεταξύ των επιθυμητών εξαρτήσεων και των πραγματικών εξαρτήσεων\nπου αποθηκεύονται στον κατάλογο 'charts/'.\n\nΓια παράδειγμα, το παρακάτω Chart.yaml δηλώνει δύο εξαρτήσεις:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\nΤο πεδίο 'name' πρέπει να είναι το όνομα ενός chart, και αυτό το όνομα πρέπει\nνα ταιριάζει με αυτό στο αρχείο 'Chart.yaml' του εν λόγω chart.\n\nΤο πεδίο 'version' πρέπει να περιέχει μια σημασιολογική έκδοση (SemVer) ή\nεύρος εκδόσεων.\n\nΤο URL του 'repository' πρέπει να δείχνει σε ένα Chart Repository. Το Helm\nαναμένει ότι προσθέτοντας '/index.yaml' στο URL, θα μπορεί να ανακτήσει το\nευρετήριο του αποθετηρίου. Σημείωση: το 'repository' μπορεί να είναι ψευδώνυμο.\nΤο ψευδώνυμο πρέπει να ξεκινά με 'alias:' ή '@'.\n\nΑπό την έκδοση 2.2.0 και μετά, το repository μπορεί να οριστεί ως διαδρομή\nπρος τον κατάλογο των εξαρτημένων charts που είναι αποθηκευμένα τοπικά. Η\nδιαδρομή πρέπει να ξεκινά με το πρόθεμα \"file://\". Για παράδειγμα,\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\nΑν το εξαρτημένο chart ανακτάται τοπικά, δεν απαιτείται να έχει προστεθεί το\nαποθετήριο στο Helm μέσω της εντολής \"helm repo add\". Η αντιστοίχιση εκδόσεων\nυποστηρίζεται και σε αυτήν την περίπτωση.\n\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for dependency\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](./helm.md)\t - Ο διαχειριστής πακέτων Helm για το Kubernetes.\n* [helm dependency build](./helm_dependency_build.md)\t - ανακατασκευή του καταλόγου charts/ με βάση το αρχείο Chart.lock\n* [helm dependency list](./helm_dependency_list.md)\t - εμφάνιση των εξαρτήσεων για ένα συγκεκριμένο chart\n* [helm dependency update](./helm_dependency_update.md)\t - ενημέρωση του καταλόγου charts/ με βάση τα περιεχόμενα του Chart.yaml\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\nανακατασκευή του καταλόγου charts/ με βάση το αρχείο Chart.lock\n\n### Σύνοψη {#synopsis}\n\n\nΚατασκευάζει τον κατάλογο charts/ από το αρχείο Chart.lock.\n\nΗ εντολή build χρησιμοποιείται για την ανακατασκευή των εξαρτήσεων ενός chart\nστην κατάσταση που καθορίζεται στο αρχείο lock. Δεν θα επαναδιαπραγματευτεί\nτις εξαρτήσεις, όπως κάνει η εντολή 'helm dependency update'.\n\nΑν δεν βρεθεί αρχείο lock, η 'helm dependency build' θα συμπεριφερθεί όπως\nη 'helm dependency update'.\n\n\n```\nhelm dependency build CHART [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for build\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm dependency](./helm_dependency.md)\t - διαχείριση εξαρτήσεων ενός chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\nεμφάνιση των εξαρτήσεων για ένα δεδομένο chart\n\n### Σύνοψη {#synopsis}\n\n\nΕμφανίζει όλες τις εξαρτήσεις που έχουν δηλωθεί σε ένα chart.\n\nΜπορεί να δεχθεί αρχεία chart και καταλόγους chart ως είσοδο. Δεν θα\nτροποποιήσει τα περιεχόμενα ενός chart.\n\nΘα εμφανίσει σφάλμα αν το chart δεν μπορεί να φορτωθεί.\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help                 help for list\n      --max-col-width uint   maximum column width for output table (default 80)\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm dependency](./helm_dependency.md)\t - διαχείριση εξαρτήσεων ενός chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\nενημέρωση του καταλόγου charts/ με βάση τα περιεχόμενα του Chart.yaml\n\n### Σύνοψη {#synopsis}\n\n\nΕνημερώνει τις εξαρτήσεις στον τοπικό δίσκο σύμφωνα με το Chart.yaml.\n\nΑυτή η εντολή επαληθεύει ότι τα απαιτούμενα charts, όπως ορίζονται στο 'Chart.yaml',\nυπάρχουν στον κατάλογο 'charts/' και είναι σε αποδεκτή έκδοση. Θα κατεβάσει τα\nπιο πρόσφατα charts που ικανοποιούν τις εξαρτήσεις και θα καθαρίσει τις παλιές\nεξαρτήσεις.\n\nΜετά από επιτυχή ενημέρωση, θα δημιουργηθεί ένα αρχείο lock που μπορεί να\nχρησιμοποιηθεί για την ανακατασκευή των εξαρτήσεων σε μια ακριβή έκδοση.\n\nΟι εξαρτήσεις δεν απαιτείται να αναπαρίστανται στο 'Chart.yaml'. Για αυτόν\nτον λόγο, μια εντολή ενημέρωσης δεν θα αφαιρέσει charts εκτός αν αυτά (α)\nυπάρχουν στο αρχείο Chart.yaml, αλλά (β) είναι σε λάθος έκδοση.\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for update\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm dependency](/helm/helm_dependency.md)\t - διαχείριση εξαρτήσεων ενός chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\nεμφανίζει τις πληροφορίες περιβάλλοντος του Helm client\n\n### Σύνοψη {#synopsis}\n\nΕκτυπώνει όλες τις πληροφορίες περιβάλλοντος που χρησιμοποιεί το Helm.\n\n\n```\nhelm env [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for env\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](./helm.md)\t - Ο διαχειριστής πακέτων Helm για το Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\nανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή αποτελείται από πολλαπλές υποεντολές που μπορούν να χρησιμοποιηθούν\nγια την ανάκτηση εκτεταμένων πληροφοριών σχετικά με ένα release, όπως:\n\n- Οι τιμές που χρησιμοποιήθηκαν για τη δημιουργία του release\n- Το παραγόμενο αρχείο manifest\n- Τα notes που παρέχονται από το chart του release\n- Τα hooks που σχετίζονται με το release\n- Τα μεταδεδομένα του release\n\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for get\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](./helm.md)\t - Ο διαχειριστής πακέτων Helm για το Kubernetes.\n* [helm get all](./helm_get_all.md)\t - κατεβάζει όλες τις πληροφορίες για ένα δεδομένο release\n* [helm get hooks](./helm_get_hooks.md)\t - κατεβάζει όλα τα hooks για ένα δεδομένο release\n* [helm get manifest](./helm_get_manifest.md)\t - κατεβάζει το manifest για ένα δεδομένο release\n* [helm get metadata](./helm_get_metadata.md)\t - ανακτά τα μεταδεδομένα για ένα δεδομένο release\n* [helm get notes](./helm_get_notes.md)\t - κατεβάζει τα notes για ένα δεδομένο release\n* [helm get values](./helm_get_values.md)\t - κατεβάζει το αρχείο values για ένα δεδομένο release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\nκατεβάζει όλες τις πληροφορίες για ένα δεδομένο release\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή εκτυπώνει μια αναγνώσιμη συλλογή πληροφοριών σχετικά με τα notes,\nτα hooks, τις παρεχόμενες τιμές (values) και το παραγόμενο αρχείο manifest του\nδεδομένου release.\n\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help              help for all\n      --revision int      get the named release with revision\n      --template string   go template for formatting the output, eg: {{.Release.Name}}\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm get](./helm_get.md)\t - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\nκατεβάζει όλα τα hooks για ένα δεδομένο release\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή κατεβάζει hooks για ένα δεδομένο release.\n\nΤα hooks παρέχονται σε μορφή YAML και διαχωρίζονται με το διαχωριστικό YAML '---\\n'.\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help           help for hooks\n      --revision int   get the named release with revision\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm get](./helm_get.md)\t - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\nκατεβάζει το manifest για ένα δεδομένο release\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή ανακτά το παραγόμενο manifest για ένα δεδομένο release.\n\nΈνα manifest είναι μια αναπαράσταση σε μορφή YAML των πόρων Kubernetes που\nδημιουργήθηκαν από το chart (ή τα charts) αυτού του release. Αν ένα chart εξαρτάται από άλλα\ncharts, αυτοί οι πόροι θα συμπεριληφθούν επίσης στο manifest.\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help           help for manifest\n      --revision int   get the named release with revision\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm get](./helm_get.md)\t - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\nΑυτή η εντολή ανακτά τα metadata για ένα δεδομένο release\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help            help for metadata\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    specify release revision\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm get](./helm_get.md)\t - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\nκατεβάζει τις σημειώσεις για ένα δεδομένο release\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή εμφανίζει τις σημειώσεις που παρέχονται από το chart ενός δεδομένου release.\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help           help for notes\n      --revision int   get the named release with revision\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm get](./helm_get.md)\t - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\nκατεβάζει το αρχείο values για ένα δεδομένο release\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή κατεβάζει το αρχείο values για ένα δεδομένο release.\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -a, --all             dump all (computed) values\n  -h, --help            help for values\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    get the named release with revision\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm get](./helm_get.md)\t - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\nανακτά το ιστορικό ενός release\n\n### Σύνοψη {#synopsis}\n\nΗ εντολή history εμφανίζει τις ιστορικές αναθεωρήσεις για ένα δεδομένο release.\n\nΑπό προεπιλογή, επιστρέφονται έως 256 αναθεωρήσεις. Χρησιμοποιήστε το flag\n'--max' για να ορίσετε το μέγιστο μήκος της λίστας αναθεωρήσεων που επιστρέφεται.\n\nΤο σύνολο των ιστορικών releases εμφανίζεται ως μορφοποιημένος πίνακας, π.χ.:\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help            help for history\n      --max int         maximum number of revision to include in history (default 256)\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](./helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\nεγκαθιστά ένα chart\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή εγκαθιστά ένα αρχείο chart.\n\nΤο όρισμα εγκατάστασης πρέπει να είναι μια αναφορά chart, μια διαδρομή προς\nένα πακεταρισμένο chart, μια διαδρομή προς έναν αποσυμπιεσμένο κατάλογο chart\nή ένα URL.\n\nΓια να παρακάμψετε τιμές σε ένα chart, χρησιμοποιήστε είτε το flag '--values' και\nπεράστε ένα αρχείο, είτε το flag '--set' και περάστε ρυθμίσεις από τη γραμμή\nεντολών. Για να ορίσετε μια τιμή ως string χρησιμοποιήστε '--set-string'.\nΜπορείτε να χρησιμοποιήσετε '--set-file' για να ορίσετε μεμονωμένες τιμές από\nαρχείο όταν η τιμή είναι πολύ μεγάλη για τη γραμμή εντολών ή δημιουργείται\nδυναμικά. Μπορείτε επίσης να χρησιμοποιήσετε '--set-json' για να ορίσετε τιμές\nJSON (scalars/objects/arrays) από τη γραμμή εντολών.\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\nή\n\n    $ helm install --set name=prod myredis ./redis\n\nή\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\nή\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\nή\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\nΜπορείτε να καθορίσετε το flag '--values'/'-f' πολλές φορές. Προτεραιότητα θα\nδοθεί στο τελευταίο (δεξιότερο) αρχείο που καθορίζεται. Για παράδειγμα, αν και\nτα δύο αρχεία myvalues.yaml και override.yaml περιέχουν ένα κλειδί με όνομα\n'Test', η τιμή που ορίζεται στο override.yaml θα υπερισχύσει:\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\nΜπορείτε να καθορίσετε το flag '--set' πολλές φορές. Προτεραιότητα θα δοθεί στην\nτελευταία (δεξιότερη) τιμή. Για παράδειγμα, αν και οι δύο τιμές 'bar' και 'newbar'\nοριστούν για ένα κλειδί με όνομα 'foo', η τιμή 'newbar' θα υπερισχύσει:\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\nΠαρόμοια, στο παρακάτω παράδειγμα το 'foo' ορίζεται ως '[\"four\"]':\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\nΚαι στο παρακάτω παράδειγμα, το 'foo' ορίζεται ως '{\"key1\":\"value1\",\"key2\":\"bar\"}':\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\nΓια να ελέγξετε τα δημιουργημένα manifests ενός release χωρίς να εγκαταστήσετε το\nchart, μπορείτε να συνδυάσετε τα flags --debug και --dry-run.\n\nΤο flag --dry-run θα εξάγει όλα τα δημιουργημένα manifests του chart, συμπεριλαμβανομένων\nτων Secrets που μπορεί να περιέχουν ευαίσθητες τιμές. Για να αποκρύψετε τα\nKubernetes Secrets χρησιμοποιήστε το flag --hide-secret. Παρακαλούμε σκεφτείτε\nπροσεκτικά πώς και πότε χρησιμοποιούνται αυτά τα flags.\n\nΑν οριστεί το --verify, το chart ΠΡΕΠΕΙ να έχει αρχείο provenance, και το αρχείο\nprovenance ΠΡΕΠΕΙ να περάσει όλα τα βήματα επαλήθευσης.\n\nΥπάρχουν έξι διαφορετικοί τρόποι να καθορίσετε το chart που θέλετε να εγκαταστήσετε:\n\n1. Μέσω αναφοράς chart: helm install mymaria example/mariadb\n2. Μέσω διαδρομής προς πακεταρισμένο chart: helm install mynginx ./nginx-1.2.3.tgz\n3. Μέσω διαδρομής προς αποσυμπιεσμένο κατάλογο chart: helm install mynginx ./nginx\n4. Μέσω απόλυτου URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. Μέσω αναφοράς chart και URL αποθετηρίου: helm install --repo https://example.com/charts/ mynginx nginx\n6. Μέσω OCI registries: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\nΑΝΑΦΟΡΕΣ CHART\n\nΜια αναφορά chart είναι ένας βολικός τρόπος να αναφερθείτε σε ένα chart μέσα σε\nένα αποθετήριο chart.\n\nΌταν χρησιμοποιείτε μια αναφορά chart με πρόθεμα αποθετηρίου ('example/mariadb'),\nτο Helm θα αναζητήσει στην τοπική ρύθμιση για ένα αποθετήριο chart με όνομα\n'example', και στη συνέχεια θα αναζητήσει ένα chart σε αυτό το αποθετήριο με\nόνομα 'mariadb'. Θα εγκαταστήσει την τελευταία σταθερή έκδοση αυτού του chart\nεκτός αν καθορίσετε το flag '--devel' για να συμπεριλάβετε και εκδόσεις ανάπτυξης\n(alpha, beta και release candidate), ή προσδιορίσετε έναν αριθμό έκδοσης με το\nflag '--version'.\n\nΓια να δείτε τη λίστα των αποθετηρίων chart, χρησιμοποιήστε 'helm repo list'. Για\nνα αναζητήσετε charts σε ένα αποθετήριο, χρησιμοποιήστε 'helm search'.\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for install\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](./helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\nεξέταση ενός chart για πιθανά προβλήματα\n\n### Σύνοψη {#synopsis}\n\n\nΑυτή η εντολή δέχεται μια διαδρομή προς ένα chart και εκτελεί μια σειρά δοκιμών για να\nεπαληθεύσει ότι το chart είναι σωστά διαμορφωμένο.\n\nΑν ο linter συναντήσει πράγματα που θα προκαλέσουν αποτυχία της εγκατάστασης του chart,\nθα εμφανίσει μηνύματα [ERROR]. Αν συναντήσει ζητήματα που αποκλίνουν από τις συμβάσεις\nή τις συστάσεις, θα εμφανίσει μηνύματα [WARNING].\n\n\n```\nhelm lint PATH [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help                      help for lint\n      --kube-version string       Kubernetes version used for capabilities and deprecation checks\n      --quiet                     print only warnings and errors\n      --set stringArray           set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray      set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray   set a literal STRING value on the command line\n      --set-string stringArray    set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-schema-validation    if set, disables JSON schema validation\n      --strict                    fail on lint warnings\n  -f, --values strings            specify values in a YAML file or a URL (can specify multiple)\n      --with-subcharts            lint dependent charts\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\nλίστα release\n\n### Σύνοψη {#synopsis}\n\n\nΑυτή η εντολή εμφανίζει όλα τα release για ένα συγκεκριμένο namespace (χρησιμοποιεί\nτο τρέχον namespace context αν δεν καθοριστεί namespace).\n\nΑπό προεπιλογή, εμφανίζει μόνο release με κατάσταση deployed ή failed. Σημαίες όπως\n'--uninstalled' και '--all' θα αλλάξουν αυτή τη συμπεριφορά. Αυτές οι σημαίες μπορούν\nνα συνδυαστούν: '--uninstalled --failed'.\n\nΑπό προεπιλογή, τα στοιχεία ταξινομούνται αλφαβητικά. Χρησιμοποιήστε τη σημαία '-d'\nγια ταξινόμηση κατά ημερομηνία release.\n\nΑν δοθεί η σημαία --filter, θα χρησιμοποιηθεί ως φίλτρο. Τα φίλτρα είναι\nκανονικές εκφράσεις (συμβατές με Perl) που εφαρμόζονται στη λίστα των release.\nΜόνο τα στοιχεία που ταιριάζουν με το φίλτρο θα επιστραφούν.\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\nΑν δεν βρεθούν αποτελέσματα, το 'helm list' θα επιστρέψει κωδικό 0, αλλά χωρίς\nέξοδο (ή στην περίπτωση χωρίς σημαία '-q', μόνο επικεφαλίδες).\n\nΑπό προεπιλογή, μπορούν να επιστραφούν έως 256 στοιχεία. Για να περιορίσετε αυτό,\nχρησιμοποιήστε τη σημαία '--max'. Η ρύθμιση '--max' σε 0 δεν θα επιστρέψει όλα τα\nαποτελέσματα. Αντίθετα, θα επιστρέψει την προεπιλεγμένη τιμή του server, η οποία\nμπορεί να είναι πολύ μεγαλύτερη από 256. Ο συνδυασμός της σημαίας '--max' με τη\nσημαία '--offset' σας επιτρέπει να περιηγηθείτε στα αποτελέσματα ανά σελίδα.\n\n\n```\nhelm list [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -a, --all                  show all releases without any filter applied\n  -A, --all-namespaces       list releases across all namespaces\n  -d, --date                 sort by release date\n      --deployed             show deployed releases. If no other is specified, this will be automatically enabled\n      --failed               show failed releases\n  -f, --filter string        a regular expression (Perl compatible). Any releases that match the expression will be included in the results\n  -h, --help                 help for list\n  -m, --max int              maximum number of releases to fetch (default 256)\n      --no-headers           don't print headers when using the default output format\n      --offset int           next release index in the list, used to offset from start value\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pending              show pending releases\n  -r, --reverse              reverse the sort order\n  -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.\n  -q, --short                output short (quiet) listing format\n      --superseded           show superseded releases\n      --time-format string   format time using golang time formatter. Example: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          show uninstalled releases (if 'helm uninstall --keep-history' was used)\n      --uninstalling         show releases that are currently being uninstalled\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\nπακετάρισμα καταλόγου chart σε αρχείο chart\n\n### Σύνοψη {#synopsis}\n\n\nΑυτή η εντολή πακετάρει ένα chart σε αρχείο chart με έκδοση. Αν δοθεί μια\nδιαδρομή, θα αναζητηθεί σε αυτή τη διαδρομή ένα chart (το οποίο πρέπει να περιέχει\nαρχείο Chart.yaml) και στη συνέχεια θα πακεταριστεί αυτός ο κατάλογος.\n\nΤα αρχεία chart με έκδοση χρησιμοποιούνται από τα αποθετήρια πακέτων Helm.\n\nΓια να υπογράψετε ένα chart, χρησιμοποιήστε την επιλογή '--sign'. Στις περισσότερες\nπεριπτώσεις, θα πρέπει επίσης να δώσετε '--keyring path/to/secret/keys' και '--key keyname'.\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\nΑν δεν καθοριστεί η επιλογή '--keyring', το Helm συνήθως χρησιμοποιεί το δημόσιο\nkeyring εκτός αν το περιβάλλον σας έχει ρυθμιστεί διαφορετικά.\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --app-version string         set the appVersion on the chart to this version\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -u, --dependency-update          update dependencies from \"Chart.yaml\" to dir \"charts/\" before packaging\n  -d, --destination string         location to write the chart. (default \".\")\n  -h, --help                       help for package\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key string                 name of the key to use when signing. Used if --sign is true\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of a public keyring (default \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     location of a file which contains the passphrase for the signing key. Use \"-\" in order to read from stdin.\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --sign                       use a PGP private key to sign this package\n      --username string            chart repository username where to locate the requested chart\n      --version string             set the version on the chart to this semver version\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\nεγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins\n\n### Σύνοψη {#synopsis}\n\nΔιαχειρίζεται τα client-side Helm plugins.\n\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for plugin\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n* [helm plugin install](/helm/helm_plugin_install.md)\t - εγκαθιστά ένα Helm plugin\n* [helm plugin list](/helm/helm_plugin_list.md)\t - εμφανίζει τα εγκατεστημένα Helm plugins\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md)\t - απεγκαθιστά ένα ή περισσότερα Helm plugins\n* [helm plugin update](/helm/helm_plugin_update.md)\t - ενημερώνει ένα ή περισσότερα Helm plugins\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\nεγκαθιστά ένα Helm plugin\n\n### Σύνοψη {#synopsis}\n\nΜε αυτή την εντολή μπορείτε να εγκαταστήσετε ένα plugin από ένα URL προς αποθετήριο VCS ή από τοπική διαδρομή.\n\n\n```\nhelm plugin install [options] <path|url> [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help             help for install\n      --version string   specify a version constraint. If this is not specified, the latest version is installed\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md)\t - εγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\nεμφανίζει τα εγκατεστημένα Helm plugins\n\n```\nhelm plugin list [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for list\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md)\t - εγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\nαπεγκαθιστά ένα ή περισσότερα Helm plugins\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for uninstall\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md)\t - εγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\nενημερώνει ένα ή περισσότερα Helm plugins\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for update\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md)\t - εγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\nλήψη chart από αποθετήριο με προαιρετική τοπική αποσυμπίεση\n\n### Σύνοψη {#synopsis}\n\n\nΑνακτά ένα πακέτο από αποθετήριο πακέτων και το κατεβάζει τοπικά.\n\nΑυτό είναι χρήσιμο για λήψη πακέτων ώστε να τα επιθεωρήσετε, τροποποιήσετε ή επανασυσκευάσετε. Μπορεί\nεπίσης να χρησιμοποιηθεί για κρυπτογραφική επαλήθευση ενός chart χωρίς να το εγκαταστήσετε.\n\nΥπάρχουν επιλογές για αποσυμπίεση του chart μετά τη λήψη. Αυτό θα δημιουργήσει\nέναν κατάλογο για το chart και θα αποσυμπιέσει τα περιεχόμενα σε αυτόν.\n\nΑν καθοριστεί η επιλογή --verify, το ζητούμενο chart ΠΡΕΠΕΙ να έχει αρχείο\nprovenance και ΠΡΕΠΕΙ να περάσει τη διαδικασία επαλήθευσης. Σε περίπτωση αποτυχίας,\nτο chart δεν θα αποθηκευτεί τοπικά.\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -d, --destination string         location to write the chart. If this and untardir are specified, untardir is appended to this (default \".\")\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help                       help for pull\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --prov                       fetch the provenance file, but don't perform verification\n      --repo string                chart repository url where to locate the requested chart\n      --untar                      if set to true, will untar the chart after downloading it\n      --untardir string            if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default \".\")\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\nαποστολή chart σε απομακρυσμένο registry\n\n### Σύνοψη {#synopsis}\n\n\nΑνεβάζει ένα chart σε registry.\n\nΑν υπάρχει συσχετισμένο αρχείο provenance,\nθα ανεβεί επίσης.\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify registry client using this SSL certificate file\n  -h, --help                       help for push\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart upload\n      --key-file string            identify registry client using this SSL key file\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart upload\n      --username string            chart repository username where to locate the requested chart\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\nσύνδεση ή αποσύνδεση από ένα registry\n\n### Σύνοψη {#synopsis}\n\n\nΑυτή η εντολή αποτελείται από πολλές υποεντολές για αλληλεπίδραση με registries.\n\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for registry\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n* [helm registry login](/helm/helm_registry_login.md)\t - σύνδεση σε ένα registry\n* [helm registry logout](/helm/helm_registry_logout.md)\t - αποσύνδεση από ένα registry\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\nσύνδεση σε ένα registry\n\n### Σύνοψη {#synopsis}\n\n\nΠραγματοποιεί πιστοποίηση σε ένα απομακρυσμένο registry.\n\n\n```\nhelm registry login [host] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string     verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string   identify registry client using this SSL certificate file\n  -h, --help               help for login\n      --insecure           allow connections to TLS registry without certs\n      --key-file string    identify registry client using this SSL key file\n  -p, --password string    registry password or identity token\n      --password-stdin     read password or identity token from stdin\n      --plain-http         use insecure HTTP connections for the chart upload\n  -u, --username string    registry username\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm registry](/helm/helm_registry.md)\t - σύνδεση ή αποσύνδεση από ένα registry\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\nαποσύνδεση από ένα registry\n\n### Σύνοψη {#synopsis}\n\nΑφαιρεί τα διαπιστευτήρια που είναι αποθηκευμένα για ένα απομακρυσμένο registry.\n\n\n```\nhelm registry logout [host] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for logout\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm registry](/helm/helm_registry.md)\t - σύνδεση ή αποσύνδεση από ένα registry\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\nπροσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart\n\n### Σύνοψη {#synopsis}\n\nΗ εντολή αποτελείται από πολλές υποεντολές για διαχείριση αποθετηρίων chart.\n\nΧρησιμοποιήστε την για να προσθέσετε, αφαιρέσετε, εμφανίσετε και δημιουργήσετε ευρετήριο αποθετηρίων chart.\n\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for repo\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n* [helm repo add](/helm/helm_repo_add.md)\t - προσθέτει ένα αποθετήριο chart\n* [helm repo index](/helm/helm_repo_index.md)\t - δημιουργεί ένα αρχείο ευρετηρίου για έναν κατάλογο που περιέχει πακεταρισμένα charts\n* [helm repo list](/helm/helm_repo_list.md)\t - εμφανίζει τα αποθετήρια chart\n* [helm repo remove](/helm/helm_repo_remove.md)\t - αφαιρεί ένα ή περισσότερα αποθετήρια chart\n* [helm repo update](/helm/helm_repo_update.md)\t - ενημερώνει τοπικά τις πληροφορίες για διαθέσιμα charts από τα αποθετήρια chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\nπροσθέτει ένα αποθετήριο chart\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --allow-deprecated-repos     by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --force-update               replace (overwrite) the repo if it already exists\n  -h, --help                       help for add\n      --insecure-skip-tls-verify   skip tls certificate checks for the repository\n      --key-file string            identify HTTPS client using this SSL key file\n      --no-update                  Ignored. Formerly, it would disabled forced updates. It is deprecated by force-update.\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password\n      --password-stdin             read chart repository password from stdin\n      --timeout duration           time to wait for the index file download to complete (default 2m0s)\n      --username string            chart repository username\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm repo](/helm/helm_repo.md)\t - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\nδημιουργεί ένα αρχείο ευρετηρίου για έναν κατάλογο που περιέχει πακεταρισμένα charts\n\n### Σύνοψη {#synopsis}\n\nΔιαβάζει τον τρέχοντα κατάλογο, δημιουργεί ένα αρχείο ευρετηρίου βασισμένο στα charts\nπου βρέθηκαν και γράφει το αποτέλεσμα στο 'index.yaml' στον τρέχοντα κατάλογο.\n\nΑυτό το εργαλείο χρησιμοποιείται για τη δημιουργία ενός αρχείου 'index.yaml' για\nένα αποθετήριο chart. Για να ορίσετε απόλυτο URL για τα charts, χρησιμοποιήστε\nτη σημαία '--url'.\n\nΓια να συγχωνεύσετε το παραγόμενο ευρετήριο με ένα υπάρχον αρχείο ευρετηρίου,\nχρησιμοποιήστε τη σημαία '--merge'. Σε αυτή την περίπτωση, τα charts που βρέθηκαν\nστον τρέχοντα κατάλογο θα συγχωνευθούν με το ευρετήριο που δόθηκε μέσω της --merge,\nδίνοντας προτεραιότητα στα τοπικά charts.\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help           help for index\n      --json           output in JSON format\n      --merge string   merge the generated index into the given index\n      --url string     url of chart repository\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm repo](/helm/helm_repo.md)\t - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\nεμφανίζει τα αποθετήρια chart\n\n```\nhelm repo list [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help            help for list\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm repo](/helm/helm_repo.md)\t - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nαφαιρεί ένα ή περισσότερα αποθετήρια chart\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for remove\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm repo](/helm/helm_repo.md)\t - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\nενημερώνει τοπικά τις πληροφορίες για διαθέσιμα charts από τα αποθετήρια chart\n\n### Σύνοψη {#synopsis}\n\nΗ εντολή update ανακτά τις πιο πρόσφατες πληροφορίες για charts από τα αντίστοιχα\nαποθετήρια chart. Οι πληροφορίες αποθηκεύονται τοπικά στην προσωρινή μνήμη (cache),\nόπου χρησιμοποιούνται από εντολές όπως η 'helm search'.\n\nΜπορείτε προαιρετικά να καθορίσετε μια λίστα αποθετηρίων που θέλετε να ενημερώσετε.\n\t$ helm repo update <repo_name> ...\nΓια να ενημερώσετε όλα τα αποθετήρια, χρησιμοποιήστε 'helm repo update'.\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --fail-on-repo-update-fail   update fails if any of the repository updates fail\n  -h, --help                       help for update\n      --timeout duration           time to wait for the index file download to complete (default 2m0s)\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm repo](/helm/helm_repo.md)\t - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\nεπαναφέρει ένα release σε προηγούμενη αναθεώρηση\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή επαναφέρει ένα release σε μια προηγούμενη αναθεώρηση.\n\nΤο πρώτο όρισμα της εντολής rollback είναι το όνομα ενός release, και το\nδεύτερο είναι ένας αριθμός αναθεώρησης (έκδοσης). Αν αυτό το όρισμα παραλειφθεί\nή οριστεί σε 0, θα γίνει επαναφορά στο προηγούμενο release.\n\nΓια να δείτε τους αριθμούς αναθεωρήσεων, εκτελέστε 'helm history RELEASE'.\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --cleanup-on-fail    allow deletion of new resources created in this rollback when rollback fails\n      --dry-run            simulate a rollback\n      --force              force resource update through delete/recreate if needed\n  -h, --help               help for rollback\n      --history-max int    limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --no-hooks           prevent hooks from running during rollback\n      --recreate-pods      performs pods restart for the resource if applicable\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --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\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\nαναζητά μια λέξη-κλειδί σε charts\n\n### Σύνοψη {#synopsis}\n\nΗ εντολή search παρέχει τη δυνατότητα αναζήτησης Helm charts στα διάφορα μέρη\nόπου μπορούν να αποθηκευτούν, συμπεριλαμβανομένου του Artifact Hub και των\nαποθετηρίων που έχετε προσθέσει. Χρησιμοποιήστε τις υποεντολές search για\nαναζήτηση σε διαφορετικές τοποθεσίες.\n\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for search\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για το Kubernetes.\n* [helm search hub](/helm/helm_search_hub.md)\t - αναζητά charts στο Artifact Hub ή στη δική σας hub instance\n* [helm search repo](/helm/helm_search_repo.md)\t - αναζητά charts στα αποθετήρια με βάση μια λέξη-κλειδί\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\nαναζητά charts στο Artifact Hub ή στη δική σας hub instance\n\n### Σύνοψη {#synopsis}\n\nΑναζητά Helm charts στο Artifact Hub ή στη δική σας hub instance.\n\nΤο Artifact Hub είναι μια διαδικτυακή εφαρμογή που επιτρέπει την εύρεση, εγκατάσταση\nκαι δημοσίευση πακέτων και ρυθμίσεων για έργα του CNCF, συμπεριλαμβανομένων\nδημόσια διαθέσιμων Helm charts. Είναι ένα sandbox project του Cloud Native Computing\nFoundation. Μπορείτε να περιηγηθείτε στο hub στη διεύθυνση https://artifacthub.io/\n\nΤο όρισμα [KEYWORD] δέχεται είτε μια λέξη-κλειδί, είτε ένα string σε εισαγωγικά με\nεπιλογές προηγμένης αναζήτησης. Για τεκμηρίωση των επιλογών προηγμένης αναζήτησης,\nδείτε\nhttps://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n\nΠροηγούμενες εκδόσεις του Helm χρησιμοποιούσαν μια instance του Monocular ως\nπροεπιλεγμένο 'endpoint', οπότε για συμβατότητα προς τα πίσω το Artifact Hub είναι\nσυμβατό με το Monocular search API. Ομοίως, όταν ορίζετε τη σημαία 'endpoint',\nτο καθορισμένο endpoint πρέπει επίσης να υλοποιεί ένα συμβατό Monocular search\nAPI endpoint. Όταν καθορίζετε μια Monocular instance ως 'endpoint', η προηγμένη\nαναζήτηση δεν υποστηρίζεται. Για λεπτομέρειες του API, δείτε https://github.com/helm/monocular\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --endpoint string      Hub instance to query for charts (default \"https://hub.helm.sh\")\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for hub\n      --list-repo-url        print charts repository URL\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm search](/helm/helm_search.md)\t - αναζητά μια λέξη-κλειδί σε charts\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\nαναζητά charts στα αποθετήρια με βάση μια λέξη-κλειδί\n\n### Σύνοψη {#synopsis}\n\nΗ εντολή search διαβάζει όλα τα αποθετήρια που έχουν ρυθμιστεί στο σύστημα και\nαναζητά αντιστοιχίες. Η αναζήτηση σε αυτά τα αποθετήρια χρησιμοποιεί τα μεταδεδομένα\nπου είναι αποθηκευμένα στο σύστημα.\n\nΕμφανίζει τις τελευταίες σταθερές εκδόσεις των charts που βρέθηκαν. Με τη σημαία\n--devel, τα αποτελέσματα περιλαμβάνουν και εκδόσεις προ-κυκλοφορίας. Για αναζήτηση\nμε περιορισμό έκδοσης, χρησιμοποιήστε --version.\n\nΠαραδείγματα:\n\n    # Αναζήτηση σταθερών εκδόσεων με λέξη-κλειδί \"nginx\"\n    $ helm search repo nginx\n\n    # Αναζήτηση εκδόσεων με λέξη-κλειδί \"nginx\", συμπεριλαμβανομένων εκδόσεων προ-κυκλοφορίας\n    $ helm search repo nginx --devel\n\n    # Αναζήτηση της τελευταίας σταθερής έκδοσης nginx-ingress με κύρια έκδοση 1\n    $ helm search repo nginx-ingress --version ^1.0.0\n\nΗ διαχείριση αποθετηρίων γίνεται με τις εντολές 'helm repo'.\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --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\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for repo\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n  -r, --regexp               use regular expressions for searching repositories you have added\n      --version string       search using semantic versioning constraints on repositories you have added\n  -l, --versions             show the long listing, with each version of each chart on its own line, for repositories you have added\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm search](/helm/helm_search.md)\t - αναζητά μια λέξη-κλειδί σε charts\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\nεμφανίζει πληροφορίες για ένα chart\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή αποτελείται από πολλαπλές υποεντολές για την εμφάνιση πληροφοριών σχετικά με ένα chart\n\n\n### Επιλογές {#options}\n\n```\n  -h, --help   help for show\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για το Kubernetes.\n* [helm show all](/helm/helm_show_all.md)\t - εμφανίζει όλες τις πληροφορίες του chart\n* [helm show chart](/helm/helm_show_chart.md)\t - εμφανίζει τον ορισμό του chart\n* [helm show crds](/helm/helm_show_crds.md)\t - εμφανίζει τα CRDs του chart\n* [helm show readme](/helm/helm_show_readme.md)\t - εμφανίζει το README του chart\n* [helm show values](/helm/helm_show_values.md)\t - εμφανίζει τα values του chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\nεμφανίζει όλες τις πληροφορίες του chart\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει όλα τα περιεχόμενά του\n(values.yaml, Chart.yaml, README)\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for all\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm show](/helm/helm_show.md)\t - εμφανίζει πληροφορίες για ένα chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\nεμφανίζει τον ορισμό του chart\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει τα περιεχόμενα\nτου αρχείου Chart.yaml\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for chart\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm show](/helm/helm_show.md)\t - εμφανίζει πληροφορίες για ένα chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\nεμφανίζει τα CRDs του chart\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει τα περιεχόμενα\nτων αρχείων CustomResourceDefinition\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for crds\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm show](/helm/helm_show.md)\t - εμφανίζει πληροφορίες για ένα chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nεμφανίζει το README του chart\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει τα περιεχόμενα\nτου αρχείου README\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for readme\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm show](/helm/helm_show.md)\t - εμφανίζει πληροφορίες για ένα chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\nεμφανίζει τις τιμές (values) του chart\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει τα περιεχόμενα\nτου αρχείου values.yaml\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for values\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --jsonpath string            supply a JSONPath expression to filter the output\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm show](/helm/helm_show.md)\t - εμφανίζει πληροφορίες για ένα chart\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\nεμφανίζει την κατάσταση ενός συγκεκριμένου release\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή εμφανίζει πληροφορίες κατάστασης για ένα release με βάση το όνομά του.\nΗ κατάσταση περιλαμβάνει:\n- τον χρόνο της τελευταίας εγκατάστασης\n- το namespace του Kubernetes όπου βρίσκεται το release\n- την τρέχουσα κατάσταση του release (δυνατές τιμές: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade ή pending-rollback)\n- την αναθεώρηση (revision) του release\n- την περιγραφή του release (μήνυμα ολοκλήρωσης ή σφάλματος, με το --show-desc)\n- τη λίστα πόρων που αποτελούν το release (με το --show-resources)\n- λεπτομέρειες για την τελευταία εκτέλεση test suite, αν υπάρχει\n- πρόσθετες σημειώσεις από το chart\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help             help for status\n  -o, --output format    prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int     if set, display the status of the named release with revision\n      --show-desc        if set, display the description message of the named release\n      --show-resources   if set, display the resources of the named release\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nτοπική απόδοση templates\n\n### Σύνοψη {#synopsis}\n\nΑποδίδει τα templates ενός chart τοπικά και εμφανίζει το αποτέλεσμα.\n\nΟι τιμές που κανονικά θα αναζητούνταν ή θα ανακτούνταν από το cluster\nπροσομοιώνονται τοπικά. Επιπλέον, δεν εκτελείται επικύρωση από την πλευρά\nτου server για την εγκυρότητα του chart (π.χ. αν υποστηρίζεται κάποιο API).\n\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -a, --api-versions strings                       Kubernetes api versions used for Capabilities.APIVersions\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for template\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --include-crds                               include CRDs in the templated output\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --is-upgrade                                 set .Release.IsUpgrade instead of .Release.IsInstall\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        Kubernetes version used for Capabilities.KubeVersion\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n      --output-dir string                          writes the executed templates to files in output-dir instead of stdout\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --release-name                               use release name in the output-dir path.\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n  -s, --show-only stringArray                      only show manifests rendered from the given templates\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --skip-tests                                 skip tests from templated output\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n      --validate                                   validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\nεκτελεί τα tests για ένα release\n\n### Σύνοψη {#synopsis}\n\nΗ εντολή test εκτελεί τα tests για ένα release.\n\nΤο όρισμα που δέχεται αυτή η εντολή είναι το όνομα ενός εγκατεστημένου release.\nΤα tests που θα εκτελεστούν ορίζονται στο chart που εγκαταστάθηκε.\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --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)\n  -h, --help               help for test\n      --hide-notes         if set, do not show notes in test output. Does not affect presence in chart metadata\n      --logs               dump the logs from test pods (this runs after all tests are complete, but before any cleanup)\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\nαπεγκαθιστά ένα release\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή δέχεται το όνομα ενός release και το απεγκαθιστά.\n\nΑφαιρεί όλους τους πόρους που σχετίζονται με την τελευταία έκδοση του chart,\nκαθώς και το ιστορικό του release, ελευθερώνοντάς το για μελλοντική χρήση.\n\nΧρησιμοποιήστε το flag '--dry-run' για να δείτε ποια releases θα απεγκατασταθούν\nχωρίς να τα απεγκαταστήσετε πραγματικά.\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --cascade string       Must be \"background\", \"orphan\", or \"foreground\". Selects the deletion cascading strategy for the dependents. Defaults to background. (default \"background\")\n      --description string   add a custom description\n      --dry-run              simulate a uninstall\n  -h, --help                 help for uninstall\n      --ignore-not-found     Treat \"release not found\" as a successful uninstall\n      --keep-history         remove all associated resources and mark the release as deleted, but retain the release history\n      --no-hooks             prevent hooks from running during uninstallation\n      --timeout duration     time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --wait                 if set, will wait until all the resources are deleted before returning. It will wait for as long as --timeout\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nαναβαθμίζει ένα release\n\n### Σύνοψη {#synopsis}\n\nΑυτή η εντολή αναβαθμίζει ένα release σε μια νέα έκδοση ενός chart.\n\nΤα ορίσματα της αναβάθμισης πρέπει να είναι ένα release και ένα chart. Το όρισμα\nchart μπορεί να είναι είτε: μια αναφορά chart ('example/mariadb'), μια διαδρομή\nπρος έναν κατάλογο chart, ένα πακεταρισμένο chart, ή ένα πλήρως προσδιορισμένο URL.\nΓια αναφορές chart, θα χρησιμοποιηθεί η τελευταία έκδοση εκτός αν οριστεί το\nflag '--version'.\n\nΓια να παρακάμψετε τιμές σε ένα chart, χρησιμοποιήστε είτε το flag '--values'\nκαι περάστε ένα αρχείο, είτε το flag '--set' και περάστε ρυθμίσεις από τη γραμμή\nεντολών. Για να αναγκάσετε τιμές string, χρησιμοποιήστε '--set-string'. Μπορείτε\nνα χρησιμοποιήσετε '--set-file' για να ορίσετε μεμονωμένες τιμές από αρχείο όταν\nη τιμή είναι πολύ μεγάλη για τη γραμμή εντολών ή δημιουργείται δυναμικά. Μπορείτε\nεπίσης να χρησιμοποιήσετε '--set-json' για να ορίσετε τιμές JSON\n(scalars/objects/arrays) από τη γραμμή εντολών.\n\nΜπορείτε να καθορίσετε το flag '--values'/'-f' πολλές φορές. Προτεραιότητα θα\nδοθεί στο τελευταίο (δεξιότερο) αρχείο που καθορίζεται. Για παράδειγμα, αν και\nτα δύο αρχεία myvalues.yaml και override.yaml περιέχουν ένα κλειδί με όνομα\n'Test', η τιμή που ορίζεται στο override.yaml θα υπερισχύσει:\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\nΜπορείτε να καθορίσετε το flag '--set' πολλές φορές. Προτεραιότητα θα δοθεί στην\nτελευταία (δεξιότερη) τιμή. Για παράδειγμα, αν και οι δύο τιμές 'bar' και 'newbar'\nοριστούν για ένα κλειδί με όνομα 'foo', η τιμή 'newbar' θα υπερισχύσει:\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\nΜπορείτε επίσης να ενημερώσετε τις τιμές για ένα υπάρχον release με αυτή την εντολή\nμέσω του flag '--reuse-values'. Τα ορίσματα 'RELEASE' και 'CHART' πρέπει να\nοριστούν στις αρχικές παραμέτρους, και οι υπάρχουσες τιμές θα συγχωνευτούν με\nόποιες τιμές οριστούν μέσω των flags '--values'/'-f' ή '--set'. Προτεραιότητα\nδίνεται στις νέες τιμές.\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\nΤο flag --dry-run θα εξάγει όλα τα δημιουργημένα manifests του chart, συμπεριλαμβανομένων\nτων Secrets που μπορεί να περιέχουν ευαίσθητες τιμές. Για να αποκρύψετε τα\nKubernetes Secrets χρησιμοποιήστε το flag --hide-secret. Παρακαλούμε σκεφτείτε\nπροσεκτικά πώς και πότε χρησιμοποιούνται αυτά τα flags.\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Επιλογές {#options}\n\n```\n      --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\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --cleanup-on-fail                            allow deletion of new resources created in this upgrade when upgrade fails\n      --create-namespace                           if --install is set, create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -h, --help                                       help for upgrade\n      --hide-notes                                 if set, do not show notes in upgrade output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --history-max int                            limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n  -i, --install                                    if a release by this name doesn't already exist, run an install\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -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 [])\n      --no-hooks                                   disable pre/post upgrade hooks\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --repo string                                chart repository url where to locate the requested chart\n      --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\n      --reset-values                               when upgrading, reset the values to the ones built into the chart\n      --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\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\nεπαληθεύει ότι ένα chart στη δεδομένη διαδρομή έχει υπογραφεί και είναι έγκυρο\n\n### Σύνοψη {#synopsis}\n\nΕπαληθεύει ότι το δεδομένο chart έχει έγκυρο αρχείο provenance.\n\nΤα αρχεία provenance παρέχουν κρυπτογραφική επαλήθευση ότι ένα chart δεν έχει\nπαραποιηθεί και δημιουργήθηκε από έναν αξιόπιστο πάροχο.\n\nΑυτή η εντολή μπορεί να χρησιμοποιηθεί για την επαλήθευση ενός τοπικού chart.\nΠολλές άλλες εντολές παρέχουν flags '--verify' που εκτελούν την ίδια επικύρωση.\nΓια να δημιουργήσετε ένα υπογεγραμμένο πακέτο, χρησιμοποιήστε την εντολή\n'helm package --sign'.\n\n\n```\nhelm verify PATH [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help             help for verify\n      --keyring string   keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n\nεμφανίζει την έκδοση του client\n\n### Σύνοψη {#synopsis}\n\nΕμφανίζει την έκδοση του Helm.\n\nΑυτή η εντολή εκτυπώνει μια αναπαράσταση της έκδοσης του Helm.\nΗ έξοδος θα μοιάζει κάπως έτσι:\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version είναι η semantic version του release.\n- GitCommit είναι το SHA για το commit από το οποίο δημιουργήθηκε αυτή η έκδοση.\n- GitTreeState είναι \"clean\" αν δεν υπάρχουν τοπικές αλλαγές κώδικα κατά τη δημιουργία\n  αυτού του binary, και \"dirty\" αν το binary δημιουργήθηκε από τοπικά τροποποιημένο κώδικα.\n- GoVersion είναι η έκδοση της Go που χρησιμοποιήθηκε για τη μεταγλώττιση του Helm.\n\nΌταν χρησιμοποιείτε την επιλογή --template, οι παρακάτω ιδιότητες είναι διαθέσιμες\nγια χρήση στο template:\n\n- .Version περιέχει τη semantic version του Helm\n- .GitCommit είναι το git commit\n- .GitTreeState είναι η κατάσταση του git tree κατά τη δημιουργία του Helm\n- .GoVersion περιέχει την έκδοση της Go με την οποία μεταγλωττίστηκε το Helm\n\nΓια παράδειγμα, η επιλογή --template='Version: {{.Version}}' εμφανίζει 'Version: v3.2.1'.\n\n\n```\nhelm version [flags]\n```\n\n### Επιλογές {#options}\n\n```\n  -h, --help              help for version\n      --short             print the version number\n      --template string   template for version string format\n```\n\n### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also}\n\n* [helm](/helm/helm.md)\t - Ο διαχειριστής πακέτων Helm για Kubernetes.\n\n###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action για Αυτοματοποίηση Charts σε GitHub Pages\ndescription: Περιγράφει πώς να χρησιμοποιήσετε το Chart Releaser Action για την αυτοματοποίηση δημοσίευσης charts μέσω GitHub pages.\nsidebar_position: 3\n---\n\nΑυτός ο οδηγός περιγράφει πώς να χρησιμοποιήσετε το [Chart Releaser\nAction](https://github.com/marketplace/actions/helm-chart-releaser) για την\nαυτοματοποίηση δημοσίευσης charts μέσω GitHub pages. Το Chart Releaser Action\nείναι ένα GitHub Action workflow που μετατρέπει ένα project στο GitHub σε\nαυτοφιλοξενούμενο αποθετήριο Helm chart, χρησιμοποιώντας το εργαλείο CLI\n[helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n## Αλλαγές στο Αποθετήριο {#repository-changes}\n\nΔημιουργήστε ένα Git αποθετήριο στον οργανισμό σας στο GitHub. Μπορείτε να\nονομάσετε το αποθετήριο `helm-charts`, αν και άλλα ονόματα είναι επίσης\nαποδεκτά. Ο πηγαίος κώδικας όλων των charts μπορεί να τοποθετηθεί στον κλάδο\n`main`. Τα charts θα πρέπει να τοποθετηθούν στον κατάλογο `/charts` στο\nανώτατο επίπεδο της δομής καταλόγων.\n\nΘα πρέπει να υπάρχει ένας άλλος κλάδος με όνομα `gh-pages` για τη δημοσίευση\nτων charts. Οι αλλαγές σε αυτόν τον κλάδο θα δημιουργούνται αυτόματα από το\nChart Releaser Action που περιγράφεται εδώ. Ωστόσο, μπορείτε να δημιουργήσετε\nτον κλάδο `gh-pages` και να προσθέσετε ένα αρχείο `README.md`, το οποίο θα\nείναι ορατό στους χρήστες που επισκέπτονται τη σελίδα.\n\nΜπορείτε να προσθέσετε οδηγίες στο `README.md` για την εγκατάσταση charts ως\nεξής (αντικαταστήστε τα `<alias>`, `<orgname>` και `<chart-name>`):\n\n```\n## Usage {#usage}\n\n[Helm](https://helm.sh) must be installed to use the charts.  Please refer to\nHelm's [documentation](https://helm.sh/docs) to get started.\n\nOnce Helm has been set up correctly, add the repo as follows:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nIf you had already added this repo earlier, run `helm repo update` to retrieve\nthe latest versions of the packages.  You can then run `helm search repo\n<alias>` to see the charts.\n\nTo install the <chart-name> chart:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nTo uninstall the chart:\n\n    helm uninstall my-<chart-name>\n```\n\nΤα charts θα δημοσιεύονται σε μια ιστοσελίδα με URL όπως αυτό:\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions Workflow {#github-actions-workflow}\n\nΔημιουργήστε ένα αρχείο GitHub Actions workflow στον κλάδο `main` στη διαδρομή\n`.github/workflows/release.yml`\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nΗ παραπάνω διαμόρφωση χρησιμοποιεί το\n[@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action)\nγια να μετατρέψει το project σας στο GitHub σε αυτοφιλοξενούμενο αποθετήριο\nHelm chart. Σε κάθε push στο main, το action ελέγχει κάθε chart στο project\nσας. Όταν εντοπίσει νέα έκδοση chart, δημιουργεί μια αντίστοιχη release στο\nGitHub με όνομα που αντιστοιχεί στην έκδοση του chart, προσθέτει τα αρχεία\nHelm chart στη release, και δημιουργεί ή ενημερώνει ένα αρχείο `index.yaml` με\nμεταδεδομένα για αυτές τις releases. Το αρχείο αυτό φιλοξενείται στη συνέχεια\nστο GitHub pages.\n\nΟ αριθμός έκδοσης του Chart Releaser Action που χρησιμοποιείται στο παραπάνω\nπαράδειγμα είναι `v1.6.0`. Μπορείτε να τον αλλάξετε στην [τελευταία διαθέσιμη\nέκδοση](https://github.com/helm/chart-releaser-action/releases).\n\nΣημείωση: Το Chart Releaser Action χρησιμοποιείται σχεδόν πάντα σε συνδυασμό με\nτο [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing)\nκαι το [Kind Action](https://github.com/marketplace/actions/kind-cluster).\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: Συγχρονισμός Αποθετηρίου Chart\ndescription: Περιγράφει πώς να συγχρονίσετε τα τοπικά και απομακρυσμένα αποθετήρια chart.\nsidebar_position: 2\n---\n\n*Σημείωση: Αυτό το παράδειγμα αφορά συγκεκριμένα ένα bucket Google Cloud Storage (GCS)\nπου εξυπηρετεί ένα αποθετήριο chart.*\n\n## Προαπαιτούμενα {#prerequisites}\n* Εγκαταστήστε το εργαλείο [gsutil](https://cloud.google.com/storage/docs/gsutil). *Βασιζόμαστε\n  σε μεγάλο βαθμό στη λειτουργικότητα rsync του gsutil*\n* Βεβαιωθείτε ότι έχετε πρόσβαση στο εκτελέσιμο του Helm\n* _Προαιρετικό: Συνιστούμε να ενεργοποιήσετε την [εκδοσιοποίηση αντικειμένων](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)\n  στο GCS bucket σας, σε περίπτωση που διαγράψετε κατά λάθος κάτι._\n\n## Δημιουργία τοπικού καταλόγου αποθετηρίου chart {#set-up-a-local-chart-repository-directory}\nΔημιουργήστε έναν τοπικό κατάλογο όπως κάναμε στον [οδηγό αποθετηρίου chart](/topics/chart_repository.md), και τοποθετήστε τα πακεταρισμένα charts σας σε αυτόν τον κατάλογο.\n\nΓια παράδειγμα:\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Δημιουργία ενημερωμένου index.yaml {#generate-an-updated-indexyaml}\nΧρησιμοποιήστε το Helm για να δημιουργήσετε ένα ενημερωμένο αρχείο index.yaml, περνώντας τη διαδρομή\nτου καταλόγου και το URL του απομακρυσμένου αποθετηρίου στην εντολή `helm repo index`, ως εξής:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\nΑυτό θα δημιουργήσει ένα ενημερωμένο αρχείο index.yaml και θα το τοποθετήσει στον\nκατάλογο `fantastic-charts/`.\n\n## Συγχρονισμός τοπικού και απομακρυσμένου αποθετηρίου chart {#sync-your-local-and-remote-chart-repositories}\nΑνεβάστε τα περιεχόμενα του καταλόγου στο GCS bucket σας εκτελώντας\n`scripts/sync-repo.sh` και περνώντας το όνομα του τοπικού καταλόγου και το όνομα του GCS bucket.\n\nΓια παράδειγμα:\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## Ενημέρωση του αποθετηρίου chart {#updating-your-chart-repository}\nΚαλό είναι να διατηρείτε ένα τοπικό αντίγραφο των περιεχομένων του αποθετηρίου chart σας ή να\nχρησιμοποιείτε το `gsutil rsync` για να αντιγράψετε τα περιεχόμενα του απομακρυσμένου αποθετηρίου\nchart σε έναν τοπικό κατάλογο.\n\nΓια παράδειγμα:\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nΧρήσιμοι σύνδεσμοι:\n* Τεκμηρίωση για το [gsutil\n  rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [Ο οδηγός αποθετηρίου chart](/topics/chart_repository.md)\n* Τεκμηρίωση για την [εκδοσιοποίηση αντικειμένων και τον έλεγχο ταυτοχρονισμού](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)\n  στο Google Cloud Storage\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Συμβουλές και Κόλπα για την Ανάπτυξη Charts\ndescription: Καλύπτει μερικές από τις συμβουλές και τα κόλπα που έχουν μάθει οι προγραμματιστές charts του Helm κατά τη δημιουργία charts παραγωγής.\nsidebar_position: 1\n---\n\nΑυτός ο οδηγός καλύπτει μερικές από τις συμβουλές και τα κόλπα που έχουν μάθει\nοι προγραμματιστές charts του Helm κατά τη δημιουργία charts για παραγωγικά\nπεριβάλλοντα.\n\n## Γνωρίστε τις Συναρτήσεις Template {#know-your-template-functions}\n\nΤο Helm χρησιμοποιεί [Go templates](https://godoc.org/text/template) για τη\nδημιουργία templates στα αρχεία πόρων σας. Αν και η Go παρέχει αρκετές ενσωματωμένες\nσυναρτήσεις, έχουμε προσθέσει πολλές επιπλέον.\n\nΠρώτον, προσθέσαμε όλες τις συναρτήσεις της [βιβλιοθήκης Sprig](https://masterminds.github.io/sprig/),\nεκτός από τις `env` και `expandenv`, για λόγους ασφαλείας.\n\nΠροσθέσαμε επίσης δύο ειδικές συναρτήσεις template: `include` και `required`. Η\nσυνάρτηση `include` σας επιτρέπει να συμπεριλάβετε ένα άλλο template και στη\nσυνέχεια να περάσετε τα αποτελέσματα σε άλλες συναρτήσεις template.\n\nΓια παράδειγμα, αυτό το απόσπασμα template συμπεριλαμβάνει ένα template με όνομα\n`mytpl`, στη συνέχεια μετατρέπει το αποτέλεσμα σε πεζά και το περικλείει σε\nδιπλά εισαγωγικά.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nΗ συνάρτηση `required` σας επιτρέπει να δηλώσετε μια συγκεκριμένη καταχώρηση\nvalues ως υποχρεωτική για την απόδοση του template. Αν η τιμή είναι κενή, η\nαπόδοση του template θα αποτύχει με ένα μήνυμα σφάλματος που ορίζει ο χρήστης.\n\nΤο ακόλουθο παράδειγμα της συνάρτησης `required` δηλώνει ότι η καταχώρηση\n`.Values.who` είναι υποχρεωτική και θα εκτυπώσει ένα μήνυμα σφάλματος όταν\nαυτή η καταχώρηση λείπει:\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## Χρησιμοποιήστε Εισαγωγικά για Strings, Όχι για Ακέραιους {#quote-strings-dont-quote-integers}\n\nΌταν εργάζεστε με δεδομένα τύπου string, είναι πάντα ασφαλέστερο να χρησιμοποιείτε\nεισαγωγικά αντί να τα αφήνετε χωρίς:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nΑλλά όταν εργάζεστε με ακέραιους αριθμούς, _μην χρησιμοποιείτε εισαγωγικά_. Αυτό\nμπορεί, σε πολλές περιπτώσεις, να προκαλέσει σφάλματα ανάλυσης μέσα στο Kubernetes.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nΑυτή η παρατήρηση δεν ισχύει για τιμές μεταβλητών περιβάλλοντος που αναμένονται\nως string, ακόμα κι αν αντιπροσωπεύουν ακέραιους:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Χρήση της Συνάρτησης 'include' {#using-the-include-function}\n\nΗ Go παρέχει έναν τρόπο να συμπεριλάβετε ένα template μέσα σε ένα άλλο\nχρησιμοποιώντας την ενσωματωμένη οδηγία `template`. Ωστόσο, η ενσωματωμένη\nσυνάρτηση δεν μπορεί να χρησιμοποιηθεί σε pipelines του Go template.\n\nΓια να είναι δυνατή η συμπερίληψη ενός template και στη συνέχεια η εκτέλεση μιας\nλειτουργίας στην έξοδο αυτού του template, το Helm έχει μια ειδική συνάρτηση `include`:\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nΤο παραπάνω συμπεριλαμβάνει ένα template με όνομα `toYaml`, του περνάει το `$value`\nκαι στη συνέχεια περνάει την έξοδο αυτού του template στη συνάρτηση `indent`.\n\nΕπειδή το YAML δίνει σημασία στα επίπεδα εσοχής και στα κενά, αυτός είναι ένας\nεξαιρετικός τρόπος για να συμπεριλαμβάνετε αποσπάσματα κώδικα, χειριζόμενοι\nτην εσοχή στο κατάλληλο πλαίσιο.\n\n## Χρήση της Συνάρτησης 'required' {#using-the-required-function}\n\nΗ Go παρέχει έναν τρόπο για να ορίσετε επιλογές template που ελέγχουν τη\nσυμπεριφορά όταν γίνεται αναζήτηση σε ένα map με κλειδί που δεν υπάρχει.\nΑυτό συνήθως ορίζεται με `template.Options(\"missingkey=option\")`, όπου η\n`option` μπορεί να είναι `default`, `zero` ή `error`. Αν και η ρύθμιση αυτής\nτης επιλογής σε error θα σταματήσει την εκτέλεση με σφάλμα, αυτό θα ισχύει\nγια κάθε κλειδί που λείπει στο map. Μπορεί να υπάρχουν περιπτώσεις όπου ο\nπρογραμματιστής του chart θέλει να επιβάλει αυτή τη συμπεριφορά για\nεπιλεγμένες τιμές στο αρχείο `values.yaml`.\n\nΗ συνάρτηση `required` δίνει στους προγραμματιστές τη δυνατότητα να δηλώσουν\nμια καταχώρηση τιμής ως υποχρεωτική για την απόδοση του template. Αν η\nκαταχώρηση είναι κενή στο `values.yaml`, το template δεν θα αποδοθεί και\nθα επιστρέψει ένα μήνυμα σφάλματος που παρέχει ο προγραμματιστής.\n\nΓια παράδειγμα:\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nΤο παραπάνω θα αποδώσει το template όταν το `.Values.foo` είναι ορισμένο,\nαλλά θα αποτύχει να το αποδώσει και θα τερματίσει όταν το `.Values.foo`\nδεν είναι ορισμένο.\n\n## Χρήση της Συνάρτησης 'tpl' {#using-the-tpl-function}\n\nΗ συνάρτηση `tpl` επιτρέπει στους προγραμματιστές να αξιολογούν strings\nως templates μέσα σε ένα template. Αυτό είναι χρήσιμο για τη μετάδοση ενός\ntemplate string ως τιμή σε ένα chart ή για την απόδοση εξωτερικών αρχείων\nρυθμίσεων. Σύνταξη: `{{ tpl TEMPLATE_STRING VALUES }}`\n\nΠαραδείγματα:\n\n```yaml\n# values {#values} {#values}\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template {#template} {#template}\n{{ tpl .Values.template . }}\n\n# output {#output} {#output}\nTom\n```\n\nΑπόδοση εξωτερικού αρχείου ρυθμίσεων:\n\n```yaml\n# external configuration file conf/app.conf {#external-configuration-file-confappconf}\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## Δημιουργία Image Pull Secrets {#creating-image-pull-secrets}\n\nΤα image pull secrets είναι ουσιαστικά ένας συνδυασμός _registry_, _username_\nκαι _password_. Μπορεί να τα χρειαστείτε σε μια εφαρμογή που αναπτύσσετε,\nαλλά για να τα δημιουργήσετε απαιτείται η εκτέλεση του `base64` μερικές φορές.\nΜπορούμε να γράψουμε ένα βοηθητικό template για τη σύνθεση του αρχείου ρυθμίσεων\nDocker προς χρήση ως payload του Secret. Ακολουθεί ένα παράδειγμα:\n\nΠρώτα, υποθέστε ότι τα credentials ορίζονται στο αρχείο `values.yaml` ως εξής:\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nΣτη συνέχεια ορίζουμε το βοηθητικό template ως εξής:\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nΤέλος, χρησιμοποιούμε το βοηθητικό template σε ένα μεγαλύτερο template για να\nδημιουργήσουμε το manifest του Secret:\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Αυτόματη Επανεκκίνηση Deployments {#automatically-roll-deployments}\n\nΣυχνά τα ConfigMaps ή τα Secrets εισάγονται ως αρχεία ρυθμίσεων σε containers\nή υπάρχουν άλλες αλλαγές εξωτερικών εξαρτήσεων που απαιτούν επανεκκίνηση των\npods. Ανάλογα με την εφαρμογή, μπορεί να απαιτείται επανεκκίνηση αν αυτά\nενημερωθούν με ένα επόμενο `helm upgrade`, αλλά αν το ίδιο το deployment spec\nδεν άλλαξε, η εφαρμογή συνεχίζει να εκτελείται με την παλιά ρύθμιση, με\nαποτέλεσμα ένα ασυνεπές deployment.\n\nΗ συνάρτηση `sha256sum` μπορεί να χρησιμοποιηθεί για να διασφαλίσει ότι η\nενότητα annotations ενός deployment ενημερώνεται αν αλλάξει ένα άλλο αρχείο:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nΣΗΜΕΙΩΣΗ: Αν προσθέτετε αυτό σε ένα library chart, δεν θα μπορέσετε να αποκτήσετε\nπρόσβαση στο αρχείο σας μέσω του `$.Template.BasePath`. Αντίθετα, μπορείτε να\nαναφερθείτε στον ορισμό σας με `{{ include (\"mylibchart.configmap\") . | sha256sum }}`.\n\nΣτην περίπτωση που θέλετε πάντα να κάνετε επανεκκίνηση το deployment σας, μπορείτε\nνα χρησιμοποιήσετε ένα παρόμοιο βήμα annotation όπως παραπάνω, αλλά αντικαθιστώντας\nμε ένα τυχαίο string ώστε να αλλάζει πάντα και να προκαλεί επανεκκίνηση του deployment:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nΚάθε κλήση της συνάρτησης template θα δημιουργήσει ένα μοναδικό τυχαίο string.\nΑυτό σημαίνει ότι αν είναι απαραίτητο να συγχρονιστούν τα τυχαία strings που\nχρησιμοποιούνται από πολλαπλούς πόρους, όλοι οι σχετικοί πόροι θα πρέπει να\nβρίσκονται στο ίδιο αρχείο template.\n\nΚαι οι δύο αυτές μέθοδοι επιτρέπουν στο Deployment σας να αξιοποιήσει την\nενσωματωμένη λογική στρατηγικής ενημέρωσης για να αποφύγει το downtime.\n\nΣΗΜΕΙΩΣΗ: Στο παρελθόν προτείναμε τη χρήση της επιλογής `--recreate-pods` ως\nεναλλακτική. Αυτή η επιλογή έχει επισημανθεί ως deprecated στο Helm 3 υπέρ\nτης πιο δηλωτικής μεθόδου που περιγράφεται παραπάνω.\n\n## Αποτροπή Απεγκατάστασης Πόρου από το Helm {#tell-helm-not-to-uninstall-a-resource}\n\nΜερικές φορές υπάρχουν πόροι που δεν πρέπει να απεγκατασταθούν όταν το Helm\nεκτελεί `helm uninstall`. Οι προγραμματιστές charts μπορούν να προσθέσουν\nένα annotation σε έναν πόρο για να αποτρέψουν την απεγκατάστασή του.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nΤο annotation `helm.sh/resource-policy: keep` δίνει εντολή στο Helm να\nπαραλείψει τη διαγραφή αυτού του πόρου όταν μια λειτουργία helm (όπως\n`helm uninstall`, `helm upgrade` ή `helm rollback`) θα είχε ως αποτέλεσμα\nτη διαγραφή του. _Ωστόσο_, αυτός ο πόρος γίνεται ορφανός. Το Helm δεν θα\nτον διαχειρίζεται πλέον με κανέναν τρόπο. Αυτό μπορεί να οδηγήσει σε\nπροβλήματα αν χρησιμοποιείτε `helm install --replace` σε ένα release που\nέχει ήδη απεγκατασταθεί, αλλά έχει διατηρήσει πόρους.\n\n## Χρήση \"Partials\" και Συμπερίληψη Templates {#using-partials-and-template-includes}\n\nΜερικές φορές θέλετε να δημιουργήσετε ορισμένα επαναχρησιμοποιήσιμα μέρη\nστο chart σας, είτε είναι blocks είτε template partials. Και συχνά, είναι\nπιο καθαρό να τα κρατάτε στα δικά τους αρχεία.\n\nΣτον κατάλογο `templates/`, οποιοδήποτε αρχείο ξεκινά με underscore (`_`)\nδεν αναμένεται να παράγει ένα αρχείο manifest Kubernetes. Έτσι, κατά σύμβαση,\nτα βοηθητικά templates και τα partials τοποθετούνται σε ένα αρχείο `_helpers.tpl`.\n\n## Σύνθετα Charts με Πολλές Εξαρτήσεις {#complex-charts-with-many-dependencies}\n\nΠολλά από τα charts στο CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0)\nείναι \"δομικά στοιχεία\" για τη δημιουργία πιο προηγμένων εφαρμογών. Αλλά τα\ncharts μπορούν επίσης να χρησιμοποιηθούν για τη δημιουργία instances\nμεγάλης κλίμακας εφαρμογών. Σε τέτοιες περιπτώσεις, ένα κεντρικό umbrella\nchart μπορεί να έχει πολλαπλά subcharts, καθένα από τα οποία λειτουργεί\nως μέρος του συνόλου.\n\nΗ τρέχουσα βέλτιστη πρακτική για τη σύνθεση μιας σύνθετης εφαρμογής από\nδιακριτά μέρη είναι να δημιουργήσετε ένα κορυφαίο umbrella chart που\nεκθέτει τις καθολικές ρυθμίσεις και στη συνέχεια να χρησιμοποιήσετε τον\nυποκατάλογο `charts/` για να ενσωματώσετε κάθε ένα από τα components.\n\n## Το YAML είναι Υπερσύνολο του JSON {#yaml-is-a-superset-of-json}\n\nΣύμφωνα με την προδιαγραφή YAML, το YAML είναι υπερσύνολο του JSON. Αυτό\nσημαίνει ότι οποιαδήποτε έγκυρη δομή JSON θα πρέπει να είναι έγκυρη και\nσε YAML.\n\nΑυτό έχει ένα πλεονέκτημα: Μερικές φορές οι προγραμματιστές templates\nμπορεί να βρουν πιο εύκολο να εκφράσουν μια δομή δεδομένων με σύνταξη\nπαρόμοια με JSON αντί να ασχοληθούν με την ευαισθησία του YAML στα κενά.\n\nΩς βέλτιστη πρακτική, τα templates θα πρέπει να ακολουθούν σύνταξη τύπου\nYAML _εκτός αν_ η σύνταξη JSON μειώνει σημαντικά τον κίνδυνο προβλήματος\nμορφοποίησης.\n\n## Προσοχή κατά τη Δημιουργία Τυχαίων Τιμών {#be-careful-with-generating-random-values}\n\nΥπάρχουν συναρτήσεις στο Helm που σας επιτρέπουν να δημιουργείτε τυχαία\nδεδομένα, κρυπτογραφικά κλειδιά και ούτω καθεξής. Αυτές είναι καλές για\nχρήση. Αλλά να έχετε υπόψη ότι κατά τις αναβαθμίσεις, τα templates\nεκτελούνται ξανά. Όταν μια εκτέλεση template δημιουργεί δεδομένα που\nδιαφέρουν από την τελευταία εκτέλεση, αυτό θα ενεργοποιήσει μια\nενημέρωση αυτού του πόρου.\n\n## Εγκατάσταση ή Αναβάθμιση Release με Μία Εντολή {#install-or-upgrade-a-release-with-one-command}\n\nΤο Helm παρέχει έναν τρόπο να εκτελέσετε εγκατάσταση ή αναβάθμιση ως μία\nεντολή. Χρησιμοποιήστε `helm upgrade` με την επιλογή `--install`. Αυτό θα\nκάνει το Helm να ελέγξει αν το release είναι ήδη εγκατεστημένο. Αν όχι,\nθα εκτελέσει εγκατάσταση. Αν είναι, τότε το υπάρχον release θα αναβαθμιστεί.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"Αρχική Εγγράφων\"\ndescription: \"Όλα όσα χρειάζεσαι να μάθεις για το πως είναι οργανωμένη η τεκμηρίωση.\"\n---\n\n# Καλωσήρθες\n\nΚαλωσήρθες στην τεκμηρίωση του [Helm](https://helm.sh/). Το Helm είναι ο package manager \nτου Kubernetes, και μπορείς να διαβάσεις τις λεπτομερείς πληροφορίες για το πλαίσιο στο\n[CNCF Helm Project Journey\nreport](https://www.cncf.io/cncf-helm-project-journey/).\n\n# Πως οργανώνεται η τεκμηρίωση\n\nΤο Helm έχει πολύ καλή τεκμηρίωση. Μια γενική ματιά στο πως είναι οργανωμένη \nθα σε βοηθήσει να ξέρεις που να ψάξεις για συγκεκριμένα πράγματα:\n\n- Τα Tutorials σε παίρνουν από το χέρι και σε καθοδηγούν σε μια σειρά από βήματα\n  ώστε να δημιουργήσεις το πρώτο σου Helm chart. Ξεκίνα από εδώ αν είσαι νέος/νέα στο Helm.\n- Οι Θεματικοί Οδηγοί συζητούν για θέματα κλειδιά και έννοιες σε ένα αρκετά γενικό επίπεδο\n  και παρέχουν χρήσιμες πληροφορίες για το πλαίσιο και επεξηγήσεις.\n- Οι Οδηγοί της Κοινότητας συζητούν για θέματα που έχουν κέντρο την κοινότητα του Helm.\n  Ξεκίνα από εδώ αν θες να μάθεις περισσότερα για την διαδικασία ανάπτυξης του ίδιου του Helm\n  και πως μπορείς να συνεισφέρεις.\n- Οι Οδηγοί How-to είναι συνταγές. Σε καθοδηγούν μέσα από τα βήματα που απαιτούνται\n  ώστε να διευθετήσεις προβλήματα κλειδιά και περιπτώσεις χρήσης. Είναι πιο προχωρημένοι από τα tutorials\n  και έχουν ως προϋπόθεση βασικές γνώσεις για το Helm.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: Φύλλο Αναφοράς\ndescription: Φύλλο γρήγορης αναφοράς για εντολές Helm\nsidebar_position: 4\n---\n\nΦύλλο αναφοράς Helm με όλες τις απαραίτητες εντολές για τη διαχείριση μιας εφαρμογής μέσω του Helm.\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### Βασικές έννοιες {#basic-interpretationscontext}\n\nChart:\n- Είναι το όνομα του chart σας σε περίπτωση που έχει γίνει pull και αποσυμπίεση.\n- Είναι <repo_name>/<chart_name> σε περίπτωση που το repository έχει προστεθεί αλλά το chart δεν έχει γίνει pull.\n- Είναι το URL ή η απόλυτη διαδρομή προς το chart.\n\nName:\n- Είναι το όνομα που θέλετε να δώσετε στην τρέχουσα εγκατάσταση του Helm chart.\n\nRelease:\n- Είναι το όνομα που δώσατε σε μια συγκεκριμένη εγκατάσταση.\n\nRevision:\n- Είναι η τιμή που επιστρέφει η εντολή `helm history`.\n\nRepo-name:\n- Το όνομα ενός repository.\n\nDIR:\n- Όνομα ή διαδρομή φακέλου.\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Διαχείριση Chart {#chart-management}\n\n```bash\nhelm create <name>                      # Creates a chart directory along with the common files and directories used in a chart.\nhelm package <chart-path>               # Packages a chart into a versioned chart archive file.\nhelm lint <chart>                       # Run tests to examine a chart and identify possible issues:\nhelm show all <chart>                   # Inspect a chart and list its contents:\nhelm show values <chart>                # Displays the contents of the values.yaml file\nhelm pull <chart>                       # Download/pull chart\nhelm pull <chart> --untar=true          # If set to true, will untar the chart after downloading it\nhelm pull <chart> --verify              # Verify the package before using it\nhelm pull <chart> --version <number>    # Default-latest is used, specify a version constraint for the chart version to use\nhelm dependency list <chart>            # Display a list of a chart's dependencies:\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Εγκατάσταση και Απεγκατάσταση Εφαρμογών {#install-and-uninstall-apps}\n\n```bash\nhelm install <name> <chart>                           # Install the chart with a name\nhelm install <name> <chart> --namespace <namespace>   # Install the chart in a specific namespace\nhelm install <name> <chart> --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas)\nhelm install <name> <chart> --values <yaml-file/url>  # Install the chart with your specified values\nhelm install <name> <chart> --dry-run --debug         # Run a test installation to validate chart (p)\nhelm install <name> <chart> --verify                  # Verify the package before using it\nhelm install <name> <chart> --dependency-update       # update dependencies if they are missing before installing the chart\nhelm uninstall <name>                                 # Uninstalls a release from the current (default) namespace\nhelm uninstall <release-name> --namespace <namespace> # Uninstalls a release from the specified namespace\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Αναβάθμιση και Επαναφορά Εφαρμογών {#perform-app-upgrade-and-rollback}\n\n```bash\nhelm upgrade <release> <chart>                            # Upgrade a release\nhelm upgrade <release> <chart> --rollback-on-failure      # If set, upgrade process rolls back changes made in case of failed upgrade.\nhelm upgrade <release> <chart> --dependency-update        # update dependencies if they are missing before installing the chart\nhelm upgrade <release> <chart> --version <version_number> # specify a version constraint for the chart version to use\nhelm upgrade <release> <chart> --values                   # specify values in a YAML file or a URL (can specify multiple)\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Set values on the command line (can specify multiple or separate valuese)\nhelm upgrade <release> <chart> --force                    # Force resource updates through a replacement strategy\nhelm rollback <release> <revision>                        # Roll back a release to a specific revision\nhelm rollback <release> <revision>  --cleanup-on-fail     # Allow deletion of new resources created in this rollback when rollback fails\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Λίστα, Προσθήκη, Αφαίρεση και Ενημέρωση Repositories {#list-add-remove-and-update-repositories}\n\n```bash\nhelm repo add <repo-name> <url>   # Add a repository from the internet:\nhelm repo list                    # List added chart repositories\nhelm repo update                  # Update information of available charts locally from chart repositories\nhelm repo remove <repo_name>      # Remove one or more chart repositories\nhelm repo index <DIR>             # Read the current directory and generate an index file based on the charts found.\nhelm repo index <DIR> --merge     # Merge the generated index with an existing index file\nhelm search repo <keyword>        # Search repositories for a keyword in charts\nhelm search hub <keyword>         # Search for charts in the Artifact Hub or your own hub instance\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Παρακολούθηση Helm Release {#helm-release-monitoring}\n\n```bash\nhelm list                       # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified\nhelm list --all                 # Show all releases without any filter applied, can use -a\nhelm list --all-namespaces      # List releases across all namespaces, we can use -A\nhelm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!='\nhelm list --date                # Sort by release date\nhelm list --deployed            # Show deployed releases. If no other is specified, this will be automatically enabled\nhelm list --pending             # Show pending releases\nhelm list --failed              # Show failed releases\nhelm list --uninstalled         # Show uninstalled releases (if 'helm uninstall --keep-history' was used)\nhelm list --superseded          # Show superseded releases\nhelm list -o yaml               # Prints the output in the specified format. Allowed values: table, json, yaml (default table)\nhelm status <release>           # This command shows the status of a named release.\nhelm status <release> --revision <number>   # if set, display the status of the named release with revision\nhelm history <release>          # Historical revisions for a given release.\nhelm env                        # Env prints out all the environment information in use by Helm.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Λήψη Πληροφοριών Release {#download-release-information}\n\n```bash\nhelm get all <release>      # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release.\nhelm get hooks <release>    # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\\n' separator.\nhelm get manifest <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.\nhelm get notes <release>    # Shows notes provided by the chart of a named release.\nhelm get values <release>   # Downloads a values file for a given release. use -o to format output\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Διαχείριση Plugin {#plugin-management}\n\n```bash\nhelm plugin install <path/url>      # Install plugins\nhelm plugin list                    # View a list of all installed plugins\nhelm plugin update <plugin>         # Update plugins\nhelm plugin uninstall <plugin>      # Uninstall a plugin\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: Εγκατάσταση του Helm\ndescription: Μάθετε πώς να εγκαταστήσετε και να ξεκινήσετε με το Helm.\nsidebar_position: 2\n---\n\nΑυτός ο οδηγός δείχνει πώς να εγκαταστήσετε το Helm CLI. Το Helm μπορεί να\nεγκατασταθεί είτε από τον πηγαίο κώδικα είτε από έτοιμα binary releases.\n\n## Από το Helm Project {#from-the-helm-project}\n\nΤο Helm project παρέχει δύο τρόπους για λήψη και εγκατάσταση του Helm. Αυτές\nείναι οι επίσημες μέθοδοι για απόκτηση εκδόσεων του Helm. Επιπλέον, η κοινότητα\nτου Helm παρέχει μεθόδους εγκατάστασης μέσω διαφορετικών διαχειριστών πακέτων.\nΗ εγκατάσταση μέσω αυτών των μεθόδων περιγράφεται παρακάτω, μετά τις επίσημες\nμεθόδους.\n\n### Από τα Binary Releases {#from-the-binary-releases}\n\nΚάθε [release](https://github.com/helm/helm/releases) του Helm παρέχει binary\nreleases για διάφορα λειτουργικά συστήματα. Αυτές οι binary εκδόσεις μπορούν\nνα ληφθούν και να εγκατασταθούν χειροκίνητα.\n\n1. Κατεβάστε την [επιθυμητή έκδοση](https://github.com/helm/helm/releases)\n2. Αποσυμπιέστε την (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)\n3. Βρείτε το `helm` binary στον αποσυμπιεσμένο φάκελο και μετακινήστε το στην\n   επιθυμητή τοποθεσία (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nΑπό εκεί, θα πρέπει να μπορείτε να εκτελέσετε τον client και να [προσθέσετε το\nstable chart repository](/intro/quickstart.md#initialize-a-helm-chart-repository):\n`helm help`.\n\n**Σημείωση:** Τα αυτοματοποιημένα tests του Helm εκτελούνται μόνο για Linux AMD64\nκατά τη διάρκεια των builds και releases στο GitHub Actions. Η δοκιμή άλλων\nλειτουργικών συστημάτων είναι ευθύνη της κοινότητας που ζητά το Helm για το\nσυγκεκριμένο λειτουργικό σύστημα.\n\n### Από Script {#from-script}\n\nΤο Helm έχει πλέον ένα script εγκατάστασης που κατεβάζει αυτόματα την τελευταία\nέκδοση του Helm και την [εγκαθιστά\nτοπικά](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3).\n\nΜπορείτε να κατεβάσετε αυτό το script και μετά να το εκτελέσετε τοπικά. Είναι\nκαλά τεκμηριωμένο ώστε να μπορείτε να το διαβάσετε και να καταλάβετε τι κάνει\nπριν το εκτελέσετε.\n\n```console\n$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\n$ chmod 700 get_helm.sh\n$ ./get_helm.sh\n```\n\nΝαι, μπορείτε να εκτελέσετε `curl\nhttps://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` αν\nθέλετε να χρησιμοποιήσετε την πιο πρόσφατη (ενδεχομένως ασταθή) έκδοση.\n\n## Μέσω Διαχειριστών Πακέτων {#through-package-managers}\n\nΗ κοινότητα του Helm παρέχει τη δυνατότητα εγκατάστασης του Helm μέσω\nδιαχειριστών πακέτων λειτουργικών συστημάτων. Αυτές οι μέθοδοι δεν υποστηρίζονται\nαπό το Helm project και δεν θεωρούνται αξιόπιστα τρίτα μέρη.\n\n### Από το Homebrew (macOS) {#from-homebrew-macos}\n\nΜέλη της κοινότητας του Helm έχουν συνεισφέρει ένα Helm formula στο Homebrew.\nΑυτό το formula είναι γενικά ενημερωμένο.\n\n```console\nbrew install helm\n```\n\n(Σημείωση: Υπάρχει επίσης ένα formula για το emacs-helm, που είναι διαφορετικό project.)\n\n### Από το Chocolatey (Windows) {#from-chocolatey-windows}\n\nΜέλη της κοινότητας του Helm έχουν συνεισφέρει ένα [Helm\npackage](https://chocolatey.org/packages/kubernetes-helm) στο\n[Chocolatey](https://chocolatey.org/). Αυτό το package είναι γενικά ενημερωμένο.\n\n```console\nchoco install kubernetes-helm\n```\n\n### Από το Scoop (Windows) {#from-scoop-windows}\n\nΜέλη της κοινότητας του Helm έχουν συνεισφέρει ένα [Helm\npackage](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) στο [Scoop](https://scoop.sh). Αυτό το package είναι γενικά ενημερωμένο.\n\n```console\nscoop install helm\n```\n\n### Από το Winget (Windows) {#from-winget-windows}\n\nΜέλη της κοινότητας του Helm έχουν συνεισφέρει ένα [Helm\npackage](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) στο [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Αυτό το package είναι γενικά ενημερωμένο.\n\n```console\nwinget install Helm.Helm\n```\n\n### Από το Apt (Debian/Ubuntu) {#from-apt-debianubuntu}\n\nΜέλη της κοινότητας του Helm έχουν συνεισφέρει ένα Apt package για Debian/Ubuntu.\nΑυτό το package είναι γενικά ενημερωμένο. Ευχαριστούμε το [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) για τη φιλοξενία του repository.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### Από το dnf/yum (Fedora) {#from-dnfyum-fedora}\n\nΑπό το Fedora 35, το Helm είναι διαθέσιμο στο επίσημο repository.\nΜπορείτε να εγκαταστήσετε το Helm εκτελώντας:\n\n```console\nsudo dnf install helm\n```\n\n### Από το Snap {#from-snap}\n\nΗ κοινότητα [Snapcrafters](https://github.com/snapcrafters) συντηρεί την Snap\nέκδοση του [Helm package](https://snapcraft.io/helm):\n\n```console\nsudo snap install helm --classic\n```\n\n### Από το pkg (FreeBSD) {#from-pkg-freebsd}\n\nΜέλη της κοινότητας FreeBSD έχουν συνεισφέρει ένα [Helm\npackage](https://www.freshports.org/sysutils/helm) στη\n[FreeBSD Ports Collection](https://man.freebsd.org/ports).\nΑυτό το package είναι γενικά ενημερωμένο.\n\n```console\npkg install helm\n```\n\n### Development Builds {#development-builds}\n\nΕκτός από τα releases, μπορείτε να κατεβάσετε ή να εγκαταστήσετε development\nsnapshots του Helm.\n\n### Από Canary Builds {#from-canary-builds}\n\nΤα \"Canary\" builds είναι εκδόσεις του λογισμικού Helm που δημιουργούνται από τον\nτελευταίο `main` branch. Δεν είναι επίσημα releases και μπορεί να μην είναι\nσταθερά. Ωστόσο, προσφέρουν τη δυνατότητα να δοκιμάσετε τα πιο πρόσφατα\nχαρακτηριστικά.\n\nΤα Canary Helm binaries αποθηκεύονται στο `get.helm.sh`. Ακολουθούν σύνδεσμοι\nγια τα συνηθισμένα builds:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows\n  AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### Από τον Πηγαίο Κώδικα (Linux, macOS) {#from-source-linux-macos}\n\nΗ μεταγλώττιση του Helm από τον πηγαίο κώδικα απαιτεί λίγο περισσότερη δουλειά,\nαλλά είναι ο καλύτερος τρόπος αν θέλετε να δοκιμάσετε την τελευταία (pre-release)\nέκδοση του Helm.\n\nΠρέπει να έχετε ένα λειτουργικό περιβάλλον Go.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\nΑν απαιτείται, θα κατεβάσει τις εξαρτήσεις, θα τις αποθηκεύσει στην cache και\nθα επικυρώσει τη ρύθμιση. Στη συνέχεια θα μεταγλωττίσει το `helm` και θα το\nτοποθετήσει στο `bin/helm`.\n\n## Συμπέρασμα {#conclusion}\n\nΣτις περισσότερες περιπτώσεις, η εγκατάσταση είναι τόσο απλή όσο η λήψη ενός\nέτοιμου `helm` binary. Αυτό το έγγραφο καλύπτει πρόσθετες περιπτώσεις για\nόσους θέλουν να κάνουν πιο εξελιγμένα πράγματα με το Helm.\n\nΜόλις εγκαταστήσετε επιτυχώς τον Helm Client, μπορείτε να προχωρήσετε στη\nχρήση του Helm για τη διαχείριση charts και να [προσθέσετε το stable\nchart repository](/intro/quickstart.md#initialize-a-helm-chart-repository).\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: Οδηγός Γρήγορης Εκκίνησης\ndescription: Πώς να εγκαταστήσετε και να ξεκινήσετε με το Helm, συμπεριλαμβανομένων οδηγιών για διανομές, συχνές ερωτήσεις και plugins.\nsidebar_position: 1\n---\n\nΑυτός ο οδηγός καλύπτει πώς μπορείτε να ξεκινήσετε γρήγορα με το Helm.\n\n## Προαπαιτούμενα {#prerequisites}\n\nΤα ακόλουθα προαπαιτούμενα είναι απαραίτητα για μια επιτυχημένη και ασφαλή\nχρήση του Helm:\n\n1. Ένα Kubernetes cluster\n2. Επιλογή ρυθμίσεων ασφαλείας για την εγκατάσταση, αν απαιτούνται\n3. Εγκατάσταση και ρύθμιση του Helm\n\n### Εγκαταστήστε το Kubernetes ή αποκτήστε πρόσβαση σε cluster {#install-kubernetes-or-have-access-to-a-cluster}\n\n- Πρέπει να έχετε εγκατεστημένο το Kubernetes. Για την τελευταία έκδοση του Helm,\n  προτείνουμε την πιο πρόσφατη σταθερή έκδοση του Kubernetes, η οποία στις\n  περισσότερες περιπτώσεις είναι η προτελευταία minor έκδοση.\n- Θα πρέπει επίσης να έχετε ένα τοπικά ρυθμισμένο αντίγραφο του `kubectl`.\n\nΔείτε την [Πολιτική Υποστήριξης Εκδόσεων του Helm](https://helm.sh/docs/topics/version_skew/) για τη μέγιστη υποστηριζόμενη απόκλιση εκδόσεων μεταξύ Helm και Kubernetes.\n\n## Εγκατάσταση του Helm {#install-helm}\n\nΚατεβάστε μια binary έκδοση του Helm client. Μπορείτε να χρησιμοποιήσετε εργαλεία\nόπως το `homebrew`, ή να δείτε [την επίσημη σελίδα εκδόσεων](https://github.com/helm/helm/releases).\n\nΓια περισσότερες λεπτομέρειες, ή για άλλες επιλογές, δείτε [τον οδηγό εγκατάστασης](/intro/install.md).\n\n## Αρχικοποίηση ενός Helm Chart Repository {#initialize-a-helm-chart-repository}\n\nΜόλις έχετε έτοιμο το Helm, μπορείτε να προσθέσετε ένα chart repository. Ελέγξτε\nτο [Artifact Hub](https://artifacthub.io/packages/search?kind=0) για διαθέσιμα\nHelm chart repositories.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nΜόλις προστεθεί, θα μπορείτε να δείτε τη λίστα με τα charts που μπορείτε να εγκαταστήσετε:\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... και πολλά άλλα {#and-many-more}\n```\n\n## Εγκατάσταση ενός Παραδείγματος Chart {#install-an-example-chart}\n\nΓια να εγκαταστήσετε ένα chart, μπορείτε να εκτελέσετε την εντολή `helm install`.\nΤο Helm προσφέρει διάφορους τρόπους για να βρείτε και να εγκαταστήσετε ένα chart,\nαλλά ο ευκολότερος είναι να χρησιμοποιήσετε τα `bitnami` charts.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nΣτο παραπάνω παράδειγμα, εγκαταστάθηκε το chart `bitnami/mysql` και το όνομα\nτου νέου release είναι `mysql-1612624192`.\n\nΜπορείτε να δείτε μια απλή περιγραφή των χαρακτηριστικών αυτού του MySQL chart\nεκτελώντας `helm show chart bitnami/mysql`. Ή μπορείτε να εκτελέσετε\n`helm show all bitnami/mysql` για να δείτε όλες τις πληροφορίες για το chart.\n\nΚάθε φορά που εγκαθιστάτε ένα chart, δημιουργείται ένα νέο release. Έτσι, ένα\nchart μπορεί να εγκατασταθεί πολλές φορές στο ίδιο cluster. Και κάθε release\nμπορεί να διαχειρίζεται και να αναβαθμίζεται ανεξάρτητα.\n\nΗ εντολή `helm install` είναι μια πολύ ισχυρή εντολή με πολλές δυνατότητες. Για\nνα μάθετε περισσότερα, δείτε τον [Οδηγό Χρήσης του Helm](/intro/using_helm.md).\n\n## Μάθετε για τα Releases {#learn-about-releases}\n\nΕίναι εύκολο να δείτε τι έχει εγκατασταθεί με το Helm:\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nΗ εντολή `helm list` (ή `helm ls`) θα σας δείξει τη λίστα με όλα τα deployed releases.\n\n## Απεγκατάσταση ενός Release {#uninstall-a-release}\n\nΓια να απεγκαταστήσετε ένα release, χρησιμοποιήστε την εντολή `helm uninstall`:\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nΑυτό θα απεγκαταστήσει το `mysql-1612624192` από το Kubernetes, αφαιρώντας όλους\nτους πόρους που σχετίζονται με το release καθώς και το ιστορικό του release.\n\nΑν χρησιμοποιηθεί η flag `--keep-history`, το ιστορικό του release θα διατηρηθεί.\nΘα μπορείτε να ζητήσετε πληροφορίες για αυτό το release:\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nΕπειδή το Helm παρακολουθεί τα releases σας ακόμα και μετά την απεγκατάστασή\nτους, μπορείτε να ελέγξετε το ιστορικό ενός cluster και ακόμα να επαναφέρετε\nένα release (με την εντολή `helm rollback`).\n\n## Ανάγνωση του Κειμένου Βοήθειας {#reading-the-help-text}\n\nΓια να μάθετε περισσότερα για τις διαθέσιμες εντολές του Helm, χρησιμοποιήστε\n`helm help` ή πληκτρολογήστε μια εντολή ακολουθούμενη από τη flag `-h`:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: Χρήση του Helm\ndescription: Εξηγεί τα βασικά του Helm.\nsidebar_position: 3\n---\n\nΑυτός ο οδηγός εξηγεί τα βασικά της χρήσης του Helm για τη διαχείριση πακέτων\nστο Kubernetes cluster σας. Προϋποθέτει ότι έχετε ήδη [εγκαταστήσει](/intro/install.md) τον Helm client.\n\nΑν απλά θέλετε να εκτελέσετε μερικές γρήγορες εντολές, μπορείτε να ξεκινήσετε\nμε τον [Οδηγό Γρήγορης Εκκίνησης](/intro/quickstart.md). Αυτό το κεφάλαιο\nκαλύπτει τις λεπτομέρειες των εντολών του Helm και εξηγεί πώς να το χρησιμοποιείτε.\n\n## Τρεις Βασικές Έννοιες {#three-big-concepts}\n\nΈνα *Chart* είναι ένα πακέτο Helm. Περιέχει όλους τους ορισμούς πόρων\nπου απαιτούνται για την εκτέλεση μιας εφαρμογής, εργαλείου ή υπηρεσίας μέσα σε\nένα Kubernetes cluster. Σκεφτείτε το σαν το αντίστοιχο του Kubernetes για ένα\nHomebrew formula, ένα Apt dpkg ή ένα Yum RPM αρχείο.\n\nΈνα *Repository* είναι ο χώρος όπου τα charts μπορούν να συγκεντρωθούν και να\nμοιραστούν. Είναι σαν το [αρχείο CPAN](https://www.cpan.org) της Perl ή τη\n[Βάση Δεδομένων Πακέτων Fedora](https://src.fedoraproject.org/), αλλά για\nπακέτα Kubernetes.\n\nΈνα *Release* είναι μια υπόσταση ενός chart που εκτελείται σε ένα Kubernetes\ncluster. Ένα chart μπορεί συχνά να εγκατασταθεί πολλές φορές στο ίδιο cluster.\nΚαι κάθε φορά που εγκαθίσταται, δημιουργείται ένα νέο _release_. Σκεφτείτε ένα\nMySQL chart. Αν θέλετε δύο βάσεις δεδομένων στο cluster σας, μπορείτε να\nεγκαταστήσετε αυτό το chart δύο φορές. Κάθε μία θα έχει το δικό της _release_,\nτο οποίο με τη σειρά του θα έχει το δικό του _release name_.\n\nΜε αυτά υπόψη, μπορούμε τώρα να εξηγήσουμε το Helm ως εξής:\n\nΤο Helm εγκαθιστά _charts_ στο Kubernetes, δημιουργώντας ένα νέο _release_ για\nκάθε εγκατάσταση. Και για να βρείτε νέα charts, μπορείτε να αναζητήσετε σε\n_repositories_ charts του Helm.\n\n## 'helm search': Εύρεση Charts {#helm-search-finding-charts}\n\nΤο Helm διαθέτει μια ισχυρή εντολή αναζήτησης. Μπορεί να χρησιμοποιηθεί για\nαναζήτηση σε δύο διαφορετικούς τύπους πηγών:\n\n- Η `helm search hub` αναζητά στο [Artifact Hub](https://artifacthub.io), το\n  οποίο παραθέτει helm charts από δεκάδες διαφορετικά repositories.\n- Η `helm search repo` αναζητά στα repositories που έχετε προσθέσει στον τοπικό\n  σας helm client (με την εντολή `helm repo add`). Αυτή η αναζήτηση γίνεται σε\n  τοπικά δεδομένα και δεν απαιτείται σύνδεση δημόσιου δικτύου.\n\nΜπορείτε να βρείτε δημόσια διαθέσιμα charts εκτελώντας `helm search hub`:\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\nΗ παραπάνω εντολή αναζητά όλα τα charts `wordpress` στο Artifact Hub.\n\nΧωρίς φίλτρο, η `helm search hub` σας δείχνει όλα τα διαθέσιμα charts.\n\nΗ `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]`.\n\nΧρησιμοποιώντας την `helm search repo`, μπορείτε να βρείτε τα ονόματα των charts\nστα repositories που έχετε ήδη προσθέσει:\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nΗ αναζήτηση Helm χρησιμοποιεί έναν αλγόριθμο ασαφούς αντιστοίχισης συμβολοσειρών,\nοπότε μπορείτε να πληκτρολογήσετε μέρη λέξεων ή φράσεων:\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nΗ αναζήτηση είναι ένας καλός τρόπος για να βρείτε διαθέσιμα πακέτα. Μόλις βρείτε\nένα πακέτο που θέλετε να εγκαταστήσετε, μπορείτε να χρησιμοποιήσετε την\n`helm install` για να το εγκαταστήσετε.\n\n## 'helm install': Εγκατάσταση Πακέτου {#helm-install-installing-a-package}\n\nΓια να εγκαταστήσετε ένα νέο πακέτο, χρησιμοποιήστε την εντολή `helm install`.\nΣτην απλούστερη μορφή της, δέχεται δύο ορίσματα: Ένα release name της επιλογής\nσας και το όνομα του chart που θέλετε να εγκαταστήσετε.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nΤώρα το chart `wordpress` έχει εγκατασταθεί. Σημειώστε ότι η εγκατάσταση ενός\nchart δημιουργεί ένα νέο αντικείμενο _release_. Το παραπάνω release ονομάζεται\n`happy-panda`. (Αν θέλετε το Helm να δημιουργήσει ένα όνομα για εσάς, παραλείψτε\nτο release name και χρησιμοποιήστε `--generate-name`.)\n\nΚατά την εγκατάσταση, ο `helm` client θα εκτυπώσει χρήσιμες πληροφορίες σχετικά\nμε τους πόρους που δημιουργήθηκαν, την κατάσταση του release, καθώς και αν\nυπάρχουν επιπλέον βήματα ρύθμισης παραμέτρων που μπορείτε ή πρέπει να κάνετε.\n\nΤο Helm εγκαθιστά πόρους με την ακόλουθη σειρά:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nΤο Helm δεν περιμένει μέχρι να εκτελούνται όλοι οι πόροι πριν τερματίσει. Πολλά\ncharts απαιτούν Docker images που είναι πάνω από 600MB σε μέγεθος και μπορεί να\nχρειαστεί πολύς χρόνος για να εγκατασταθούν στο cluster.\n\nΓια να παρακολουθήσετε την κατάσταση ενός release ή για να ξαναδιαβάσετε\nπληροφορίες ρύθμισης παραμέτρων, μπορείτε να χρησιμοποιήσετε την `helm status`:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nΤα παραπάνω δείχνουν την τρέχουσα κατάσταση του release σας.\n\n### Προσαρμογή του Chart Πριν την Εγκατάσταση {#customizing-the-chart-before-installing}\n\nΗ εγκατάσταση με τον τρόπο που δείξαμε θα χρησιμοποιήσει μόνο τις προεπιλεγμένες\nεπιλογές ρύθμισης παραμέτρων για αυτό το chart. Πολλές φορές θα θέλετε να\nπροσαρμόσετε το chart ώστε να χρησιμοποιεί τη ρύθμιση παραμέτρων της προτίμησής σας.\n\nΓια να δείτε ποιες επιλογές είναι παραμετροποιήσιμες σε ένα chart, χρησιμοποιήστε\nτην `helm show values`:\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters {#global-docker-image-parameters}\n## 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}\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets {#current-available-global-docker-image-parameters-imageregistry-and-imagepullsecrets}\n## # global: {#global}\n# imageRegistry: myRegistryName {#imageregistry-myregistryname}\n# imagePullSecrets: {#imagepullsecrets}\n# - myRegistryKeySecretName {#myregistrykeysecretname}\n# storageClass: myStorageClass {#storageclass-mystorageclass}\n\n## Bitnami WordPress image version {#bitnami-wordpress-image-version}\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ {#ref-httpshubdockercomrbitnamiwordpresstags}\n## image: {#image}\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nΣτη συνέχεια μπορείτε να παρακάμψετε οποιαδήποτε από αυτές τις ρυθμίσεις σε ένα\nαρχείο μορφής YAML και να περάσετε αυτό το αρχείο κατά την εγκατάσταση.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nΤα παραπάνω θα δημιουργήσουν έναν προεπιλεγμένο χρήστη MariaDB με το όνομα\n`user0`, και θα παραχωρήσουν σε αυτόν τον χρήστη πρόσβαση σε μια νέα βάση\nδεδομένων `user0db`, αλλά θα αποδεχτεί όλες τις υπόλοιπες προεπιλογές για\nαυτό το chart.\n\nΥπάρχουν δύο τρόποι για να περάσετε δεδομένα ρύθμισης παραμέτρων κατά την\nεγκατάσταση:\n\n- `--values` (ή `-f`): Καθορίστε ένα αρχείο YAML με παρακάμψεις. Αυτό μπορεί\n  να καθοριστεί πολλές φορές και το δεξιότερο αρχείο θα έχει προτεραιότητα\n- `--set`: Καθορίστε παρακάμψεις στη γραμμή εντολών.\n\nΑν χρησιμοποιηθούν και τα δύο, οι τιμές `--set` συγχωνεύονται στις τιμές\n`--values` με υψηλότερη προτεραιότητα. Οι παρακάμψεις που καθορίζονται με\n`--set` αποθηκεύονται σε ένα Secret. Οι τιμές που έχουν οριστεί με `--set`\nμπορούν να προβληθούν για ένα συγκεκριμένο release με την `helm get values <release-name>`.\nΟι τιμές που έχουν οριστεί με `--set` μπορούν να διαγραφούν εκτελώντας\n`helm upgrade` με την επιλογή `--reset-values`.\n\n#### Η Μορφή και οι Περιορισμοί του `--set` {#the-format-and-limitations-of-set}\n\nΗ επιλογή `--set` δέχεται μηδέν ή περισσότερα ζεύγη ονόματος/τιμής. Στην\nαπλούστερη μορφή της, χρησιμοποιείται ως εξής: `--set name=value`. Το\nαντίστοιχο σε YAML είναι:\n\n```yaml\nname: value\n```\n\nΠολλαπλές τιμές διαχωρίζονται με χαρακτήρες `,`. Έτσι το `--set a=b,c=d` γίνεται:\n\n```yaml\na: b\nc: d\n```\n\nΥποστηρίζονται πιο σύνθετες εκφράσεις. Για παράδειγμα, το `--set outer.inner=value`\nμεταφράζεται σε αυτό:\n```yaml\nouter:\n  inner: value\n```\n\nΟι λίστες μπορούν να εκφραστούν περικλείοντας τιμές με `{` και `}`. Για\nπαράδειγμα, το `--set name={a, b, c}` μεταφράζεται σε:\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nΟρισμένα ονόματα/κλειδιά μπορούν να οριστούν σε `null` ή σε κενό πίνακα `[]`.\nΓια παράδειγμα, το `--set name=[],a=null` μεταφράζει\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\nσε\n\n```yaml\nname: []\na: null\n```\n\nΑπό το Helm 2.5.0, είναι δυνατή η πρόσβαση σε στοιχεία λίστας χρησιμοποιώντας\nσύνταξη δείκτη πίνακα. Για παράδειγμα, το `--set servers[0].port=80` γίνεται:\n\n```yaml\nservers:\n  - port: 80\n```\n\nΠολλαπλές τιμές μπορούν να οριστούν με αυτόν τον τρόπο. Η γραμμή `--set\nservers[0].port=80,servers[0].host=example` γίνεται:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nΜερικές φορές χρειάζεται να χρησιμοποιήσετε ειδικούς χαρακτήρες στις γραμμές\n`--set`. Μπορείτε να χρησιμοποιήσετε backslash για να διαφύγετε τους χαρακτήρες·\nτο `--set name=value1\\,value2` θα γίνει:\n\n```yaml\nname: \"value1,value2\"\n```\n\nΟμοίως, μπορείτε να διαφύγετε ακολουθίες τελειών, κάτι που μπορεί να είναι\nχρήσιμο όταν τα charts χρησιμοποιούν τη συνάρτηση `toYaml` για ανάλυση\nannotations, labels και node selectors. Η σύνταξη για το\n`--set nodeSelector.\"kubernetes\\.io/role\"=master` γίνεται:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nΒαθιά ένθετες δομές δεδομένων μπορεί να είναι δύσκολο να εκφραστούν με το\n`--set`. Οι σχεδιαστές charts ενθαρρύνονται να λαμβάνουν υπόψη τη χρήση του\n`--set` κατά τον σχεδιασμό της μορφής ενός αρχείου `values.yaml` (διαβάστε\nπερισσότερα για τα [Αρχεία Values](/chart_template_guide/values_files.md)).\n\n### Περισσότεροι Τρόποι Εγκατάστασης {#more-installation-methods}\n\nΗ εντολή `helm install` μπορεί να εγκαταστήσει από διάφορες πηγές:\n\n- Ένα chart repository (όπως είδαμε παραπάνω)\n- Ένα τοπικό αρχείο chart (`helm install foo foo-0.1.1.tgz`)\n- Έναν αποσυμπιεσμένο φάκελο chart (`helm install foo path/to/foo`)\n- Μια πλήρη διεύθυνση URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' και 'helm rollback': Αναβάθμιση Release και Ανάκτηση από Αποτυχία {#helm-upgrade-and-helm-rollback-upgrading-a-release-and-recovering-on-failure}\n\nΌταν κυκλοφορεί μια νέα έκδοση ενός chart, ή όταν θέλετε να αλλάξετε τη ρύθμιση\nπαραμέτρων του release σας, μπορείτε να χρησιμοποιήσετε την εντολή `helm upgrade`.\n\nΜια αναβάθμιση παίρνει ένα υπάρχον release και το αναβαθμίζει σύμφωνα με τις\nπληροφορίες που παρέχετε. Επειδή τα Kubernetes charts μπορεί να είναι μεγάλα\nκαι σύνθετα, το Helm προσπαθεί να εκτελέσει την ελάχιστα παρεμβατική αναβάθμιση.\nΘα ενημερώσει μόνο πράγματα που έχουν αλλάξει από το τελευταίο release.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nΣτην παραπάνω περίπτωση, το release `happy-panda` αναβαθμίζεται με το ίδιο\nchart, αλλά με ένα νέο αρχείο YAML:\n\n```yaml\nmariadb.auth.username: user1\n```\n\nΜπορούμε να χρησιμοποιήσουμε την `helm get values` για να δούμε αν αυτή η νέα\nρύθμιση εφαρμόστηκε.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nΗ εντολή `helm get` είναι ένα χρήσιμο εργαλείο για την εξέταση ενός release στο\ncluster. Και όπως βλέπουμε παραπάνω, δείχνει ότι οι νέες τιμές μας από το\n`panda.yaml` εγκαταστάθηκαν στο cluster.\n\nΤώρα, αν κάτι δεν πάει σύμφωνα με το σχέδιο κατά τη διάρκεια ενός release, είναι\nεύκολο να επιστρέψετε σε ένα προηγούμενο release χρησιμοποιώντας\n`helm rollback [RELEASE] [REVISION]`.\n\n```console\n$ helm rollback happy-panda 1\n```\n\nΤα παραπάνω επαναφέρουν το happy-panda στην πρώτη του έκδοση release. Μια\nέκδοση release είναι μια αυξητική αναθεώρηση. Κάθε φορά που γίνεται εγκατάσταση,\nαναβάθμιση ή rollback, ο αριθμός αναθεώρησης αυξάνεται κατά 1. Ο πρώτος αριθμός\nαναθεώρησης είναι πάντα 1. Και μπορούμε να χρησιμοποιήσουμε την `helm history [RELEASE]`\nγια να δούμε τους αριθμούς αναθεώρησης για ένα συγκεκριμένο release.\n\n## Χρήσιμες Επιλογές για Install/Upgrade/Rollback {#helpful-options-for-installupgraderollback}\n\nΥπάρχουν αρκετές άλλες χρήσιμες επιλογές που μπορείτε να καθορίσετε για την\nπροσαρμογή της συμπεριφοράς του Helm κατά τη διάρκεια μιας εγκατάστασης/αναβάθμισης/rollback.\nΠαρακαλούμε σημειώστε ότι αυτή δεν είναι μια πλήρης λίστα flags του cli. Για να\nδείτε μια περιγραφή όλων των flags, απλά εκτελέστε `helm <command> --help`.\n\n- `--timeout`: Μια τιμή [Go duration](https://golang.org/pkg/time/#ParseDuration)\n  για να περιμένετε την ολοκλήρωση των εντολών Kubernetes. Η προεπιλογή είναι `5m0s`.\n- `--wait`: Περιμένει μέχρι όλα τα Pods να είναι σε κατάσταση ready, τα PVCs\n  να είναι bound, τα Deployments να έχουν τον ελάχιστο αριθμό (`Desired` μείον\n  `maxUnavailable`) Pods σε κατάσταση ready και τα Services να έχουν μια\n  διεύθυνση IP (και Ingress αν είναι `LoadBalancer`) πριν σημειώσει το release\n  ως επιτυχημένο. Θα περιμένει για όσο χρόνο ορίζει η τιμή `--timeout`. Αν\n  φτάσει το timeout, το release θα σημειωθεί ως `FAILED`. Σημείωση: Σε σενάρια\n  όπου το Deployment έχει `replicas` ορισμένο σε 1 και το `maxUnavailable` δεν\n  είναι ορισμένο σε 0 ως μέρος της στρατηγικής rolling update, το `--wait` θα\n  επιστρέψει ως ready καθώς έχει ικανοποιηθεί η ελάχιστη συνθήκη Pod σε ready.\n- `--no-hooks`: Παρακάμπτει την εκτέλεση hooks για την εντολή\n- `--recreate-pods` (διαθέσιμο μόνο για `upgrade` και `rollback`): Αυτό το flag\n  θα προκαλέσει την αναδημιουργία όλων των pods (με εξαίρεση τα pods που ανήκουν\n  σε deployments). (ΚΑΤΑΡΓΗΜΕΝΟ στο Helm 3)\n\n## 'helm uninstall': Απεγκατάσταση ενός Release {#helm-uninstall-uninstalling-a-release}\n\nΌταν έρθει η ώρα να απεγκαταστήσετε ένα release από το cluster, χρησιμοποιήστε\nτην εντολή `helm uninstall`:\n\n```console\n$ helm uninstall happy-panda\n```\n\nΑυτό θα αφαιρέσει το release από το cluster. Μπορείτε να δείτε όλα τα τρέχοντα\nεγκατεστημένα releases σας με την εντολή `helm list`:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nΑπό την παραπάνω έξοδο, μπορούμε να δούμε ότι το release `happy-panda`\nαπεγκαταστάθηκε.\n\nΣε προηγούμενες εκδόσεις του Helm, όταν διαγραφόταν ένα release, παρέμενε\nμια εγγραφή της διαγραφής του. Στο Helm 3, η διαγραφή αφαιρεί και την εγγραφή\nτου release. Αν θέλετε να διατηρήσετε μια εγγραφή διαγραφής του release,\nχρησιμοποιήστε `helm uninstall --keep-history`. Η χρήση της `helm list --uninstalled`\nθα εμφανίσει μόνο releases που απεγκαταστάθηκαν με το flag `--keep-history`.\n\nΤο flag `helm list --all` θα σας δείξει όλες τις εγγραφές release που έχει\nδιατηρήσει το Helm, συμπεριλαμβανομένων εγγραφών για αποτυχημένα ή διαγραμμένα\nστοιχεία (αν είχε καθοριστεί το `--keep-history`):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nΣημειώστε ότι επειδή τα releases πλέον διαγράφονται από προεπιλογή, δεν είναι\nπλέον δυνατό να κάνετε rollback σε έναν απεγκατεστημένο πόρο.\n\n## 'helm repo': Εργασία με Repositories {#helm-repo-working-with-repositories}\n\nΤο Helm 3 δεν αποστέλλεται πλέον με ένα προεπιλεγμένο chart repository. Η ομάδα\nεντολών `helm repo` παρέχει εντολές για προσθήκη, εμφάνιση λίστας και αφαίρεση\nrepositories.\n\nΜπορείτε να δείτε ποια repositories είναι ρυθμισμένα χρησιμοποιώντας `helm repo list`:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nΚαι νέα repositories μπορούν να προστεθούν με `helm repo add [NAME] [URL]`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nΕπειδή τα chart repositories αλλάζουν συχνά, ανά πάσα στιγμή μπορείτε να\nβεβαιωθείτε ότι ο Helm client σας είναι ενημερωμένος εκτελώντας `helm repo update`.\n\nΤα repositories μπορούν να αφαιρεθούν με την `helm repo remove`.\n\n## Δημιουργία των Δικών σας Charts {#creating-your-own-charts}\n\nΟ [Οδηγός Ανάπτυξης Chart](/topics/charts.md) εξηγεί πώς\nνα αναπτύξετε τα δικά σας charts. Αλλά μπορείτε να ξεκινήσετε γρήγορα\nχρησιμοποιώντας την εντολή `helm create`:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nΤώρα υπάρχει ένα chart στο `./deis-workflow`. Μπορείτε να το επεξεργαστείτε\nκαι να δημιουργήσετε τα δικά σας templates.\n\nΚαθώς επεξεργάζεστε το chart σας, μπορείτε να επικυρώσετε ότι είναι σωστά\nδιαμορφωμένο εκτελώντας `helm lint`.\n\nΌταν έρθει η ώρα να πακετάρετε το chart για διανομή, μπορείτε να εκτελέσετε\nτην εντολή `helm package`:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nΚαι αυτό το chart μπορεί πλέον εύκολα να εγκατασταθεί με `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nΤα πακεταρισμένα charts μπορούν να φορτωθούν σε chart repositories. Δείτε την\nτεκμηρίωση για τα [chart repositories του Helm](/topics/chart_repository.md)\nγια περισσότερες λεπτομέρειες.\n\n## Συμπέρασμα {#conclusion}\n\nΑυτό το κεφάλαιο κάλυψε τα βασικά μοτίβα χρήσης του `helm` client,\nσυμπεριλαμβανομένης της αναζήτησης, εγκατάστασης, αναβάθμισης και απεγκατάστασης.\nΚάλυψε επίσης χρήσιμες βοηθητικές εντολές όπως `helm status`, `helm get` και\n`helm repo`.\n\nΓια περισσότερες πληροφορίες σχετικά με αυτές τις εντολές, ρίξτε μια ματιά στη\nενσωματωμένη βοήθεια του Helm: `helm help`.\n\nΣτο [επόμενο κεφάλαιο](/howto/charts_tips_and_tricks.md), εξετάζουμε τη\nδιαδικασία ανάπτυξης charts.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx",
    "content": "---\ntitle: Παραδείγματα\ndescription: Παραδείγματα διαφόρων λειτουργιών του Helm SDK\nsidebar_position: 2\n---\nimport CodeBlock from '@theme/CodeBlock';\n\nimport MainExampleGo from '!!raw-loader!/sdkexamples/main.go';\nimport InstallExampleGo from '!!raw-loader!/sdkexamples/install.go';\nimport ListExampleGo from '!!raw-loader!/sdkexamples/list.go';\nimport PullExampleGo from '!!raw-loader!/sdkexamples/pull.go';\nimport UninstallExampleGo from '!!raw-loader!/sdkexamples/uninstall.go';\nimport UpgradeExampleGo from '!!raw-loader!/sdkexamples/upgrade.go';\n\nΑυτό το έγγραφο παρουσιάζει μια σειρά παραδειγμάτων χρήσης του Helm SDK.\nΣκοπός του είναι να τεκμηριώσει διάφορες λειτουργίες του SDK.\n\nΤο τελικό παράδειγμα δείχνει τον `main.go` driver ([σύνδεσμος](#driver)). Αυτός εκτελεί τις παρακάτω ενέργειες και περιλαμβάνει τις απαραίτητες βοηθητικές συναρτήσεις.\n\nΟ κώδικας για τα παραδείγματα βρίσκεται στον κατάλογο [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples).\nΚαι είναι σχεδιασμένος να είναι πλήρως λειτουργικός.\n\n## Ενέργειες {#actions}\n\n### Ενέργεια Install {#install-action}\n\nΑυτό το παράδειγμα εγκαθιστά το δοσμένο chart/release, για τη δοσμένη έκδοση και values:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/install.go\" showLineNumbers>{InstallExampleGo}</CodeBlock>\n\n### Ενέργεια Upgrade {#upgrade-action}\n\nΑυτό το παράδειγμα αναβαθμίζει το δοσμένο release, με το δοσμένο chart, έκδοση και values:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/upgrade.go\" showLineNumbers>{UpgradeExampleGo}</CodeBlock>\n\n### Ενέργεια Uninstall {#uninstall-action}\n\nΑυτό το παράδειγμα απεγκαθιστά το δοσμένο release:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/uninstall.go\" showLineNumbers>{UninstallExampleGo}</CodeBlock>\n\n### Ενέργεια List {#list-action}\n\nΑυτό το παράδειγμα παραθέτει όλα τα εγκατεστημένα charts (στο τρέχον διαμορφωμένο namespace):\n\n<CodeBlock language=\"go\" title=\"sdkexamples/list.go\" showLineNumbers>{ListExampleGo}</CodeBlock>\n\n### Ενέργεια Pull {#pull-action}\n\nΑυτό το παράδειγμα κατεβάζει ένα chart από ένα OCI repository:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/pull.go\" showLineNumbers>{PullExampleGo}</CodeBlock>\n\n## Driver {#driver}\n\nΟ driver εδώ δείχνει τις απαραίτητες βοηθητικές συναρτήσεις που χρειάζονται για να λειτουργήσουν οι ενέργειες του Helm SDK. Και δείχνει τα παραπάνω παραδείγματα σε δράση, για να κατεβάσει, εγκαταστήσει, αναβαθμίσει και απεγκαταστήσει το 'podinfo' chart από ένα OCI repository:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/main.go\" showLineNumbers>{MainExampleGo}</CodeBlock>\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: Εισαγωγή\ndescription: Εισαγωγή στο Helm Go SDK\nsidebar_position: 1\n---\nΤο Go SDK του Helm επιτρέπει σε προσαρμοσμένο λογισμικό να αξιοποιεί τα Helm charts και\nτη λειτουργικότητα του Helm για τη διαχείριση εγκατάστασης λογισμικού στο Kubernetes\n(το Helm CLI είναι στην πραγματικότητα ένα τέτοιο εργαλείο!).\n\nΕπί του παρόντος, το SDK έχει διαχωριστεί λειτουργικά από το Helm CLI.\nΤο SDK μπορεί να χρησιμοποιηθεί (και χρησιμοποιείται) από αυτόνομα εργαλεία.\nΤο Helm project έχει δεσμευτεί για τη σταθερότητα του API του SDK.\nΩς προειδοποίηση, το SDK διατηρεί ακόμη κάποιες ατέλειες από την αρχική εργασία\nδιαχωρισμού CLI και SDK, τις οποίες το Helm project στοχεύει να βελτιώσει σταδιακά.\n\nΠλήρης τεκμηρίωση του API μπορεί να βρεθεί στη διεύθυνση [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3).\n\nΜια σύντομη επισκόπηση ορισμένων από τους κύριους τύπους πακέτων και ένα απλό παράδειγμα\nακολουθούν παρακάτω.\nΔείτε την ενότητα [Παραδείγματα](/sdk/examples.mdx) για περισσότερα παραδείγματα και έναν\nπιο ολοκληρωμένο 'driver'.\n\n## Επισκόπηση των κύριων πακέτων {#main-package-overview}\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action):\n  Περιέχει τον κύριο \"client\" για την εκτέλεση ενεργειών Helm.\n  Αυτό είναι το ίδιο πακέτο που χρησιμοποιεί το CLI εσωτερικά.\n  Αν χρειάζεστε απλώς να εκτελέσετε βασικές εντολές Helm από άλλο πρόγραμμα Go, αυτό\n  είναι το πακέτο για εσάς\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil):\n  Μέθοδοι και βοηθητικά εργαλεία για τη φόρτωση και χειρισμό charts\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) και τα υποπακέτα του:\n  Περιέχει όλους τους handlers για τις τυπικές μεταβλητές περιβάλλοντος του Helm.\n  Τα υποπακέτα περιέχουν χειρισμό εξόδου και αρχείων values\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release):\n  Ορίζει το αντικείμενο `Release` και τις καταστάσεις του\n\nΥπάρχουν πολλά περισσότερα πακέτα εκτός από αυτά, οπότε δείτε την τεκμηρίωση για\nπερισσότερες πληροφορίες!\n\n### Απλό παράδειγμα {#simple-example}\nΑυτό είναι ένα απλό παράδειγμα εκτέλεσης `helm list` χρησιμοποιώντας το Go SDK.\nΔείτε την ενότητα [Παραδείγματα](/sdk/examples.mdx) για πιο ολοκληρωμένα παραδείγματα.\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## Συμβατότητα {#compatibility}\n\nΤο Helm SDK ακολουθεί ρητά τις εγγυήσεις συμβατότητας προς τα πίσω του Helm:\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\nΑυτό σημαίνει ότι αλλαγές που διακόπτουν τη συμβατότητα θα γίνονται μόνο μεταξύ major versions.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: Προηγμένες Τεχνικές Helm\ndescription: Εξηγεί διάφορες προηγμένες δυνατότητες για προχωρημένους χρήστες του Helm\nsidebar_position: 9\n---\n\nΑυτή η ενότητα εξηγεί διάφορες προηγμένες δυνατότητες και τεχνικές για τη χρήση του Helm.\nΟι πληροφορίες σε αυτή την ενότητα προορίζονται για \"προχωρημένους χρήστες\" του Helm που\nεπιθυμούν να κάνουν προηγμένη προσαρμογή και χειρισμό των charts και releases τους. Κάθε\nμία από αυτές τις προηγμένες δυνατότητες έρχεται με τους δικούς της συμβιβασμούς και\nπροειδοποιήσεις, επομένως καθεμία πρέπει να χρησιμοποιείται προσεκτικά και με βαθιά\nγνώση του Helm. Ή με άλλα λόγια, να θυμάστε την [αρχή του Peter Parker](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)\n\n## Post Rendering {#post-rendering}\n\nΤο Post rendering δίνει στους χρήστες που εγκαθιστούν charts τη δυνατότητα να χειριστούν\nχειροκίνητα, να ρυθμίσουν ή/και να επαληθεύσουν τα παραγόμενα manifests πριν εγκατασταθούν\nαπό το Helm. Έτσι, χρήστες με προηγμένες ανάγκες ρύθμισης μπορούν να χρησιμοποιήσουν\nεργαλεία όπως το [`kustomize`](https://kustomize.io) για να εφαρμόσουν αλλαγές διαμόρφωσης\nχωρίς να χρειάζεται να κάνουν fork ένα δημόσιο chart ή να απαιτούν από τους συντηρητές\nτου chart να καθορίσουν κάθε δυνατή επιλογή διαμόρφωσης. Υπάρχουν επίσης περιπτώσεις\nχρήσης για την ένεση κοινών εργαλείων και sidecars σε εταιρικά περιβάλλοντα ή για την\nανάλυση των manifests πριν από το deployment.\n\n### Προαπαιτούμενα {#prerequisites}\n- Helm 3.1+\n\n### Χρήση {#usage}\nΈνας post-renderer μπορεί να είναι οποιοδήποτε εκτελέσιμο αρχείο που δέχεται παραγόμενα\nKubernetes manifests στο STDIN και επιστρέφει έγκυρα Kubernetes manifests στο STDOUT.\nΘα πρέπει να επιστρέφει έναν μη-μηδενικό κωδικό εξόδου σε περίπτωση αποτυχίας. Αυτό είναι\nτο μόνο \"API\" μεταξύ των δύο στοιχείων. Επιτρέπει μεγάλη ευελιξία σε αυτό που μπορείτε\nνα κάνετε με τη διαδικασία post-render.\n\nΈνας post-renderer μπορεί να χρησιμοποιηθεί με τις εντολές `install`, `upgrade` και\n`template`. Για να χρησιμοποιήσετε έναν post-renderer, χρησιμοποιήστε την επιλογή\n`--post-renderer` με μια διαδρομή προς το εκτελέσιμο renderer που επιθυμείτε να χρησιμοποιήσετε:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nΑν η διαδρομή δεν περιέχει διαχωριστικά, θα αναζητήσει στο $PATH, διαφορετικά θα\nεπιλύσει τυχόν σχετικές διαδρομές σε πλήρως προσδιορισμένες διαδρομές.\n\nΑν επιθυμείτε να χρησιμοποιήσετε πολλαπλούς post-renderers, καλέστε τους όλους σε ένα\nscript ή μαζί σε οποιοδήποτε binary εργαλείο έχετε δημιουργήσει. Στο bash, αυτό θα ήταν\nτόσο απλό όσο `renderer1 | renderer2 | renderer3`.\n\nΜπορείτε να δείτε ένα παράδειγμα χρήσης του `kustomize` ως post renderer\n[εδώ](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n### Προειδοποιήσεις {#caveats}\nΌταν χρησιμοποιείτε post renderers, υπάρχουν αρκετά σημαντικά πράγματα που πρέπει να\nέχετε υπόψη σας. Το πιο σημαντικό από αυτά είναι ότι όταν χρησιμοποιείτε έναν\npost-renderer, όλα τα άτομα που τροποποιούν αυτό το release **ΠΡΕΠΕΙ** να\nχρησιμοποιούν τον ίδιο renderer για να έχουν επαναλήψιμες κατασκευές. Αυτή η\nδυνατότητα είναι σκόπιμα σχεδιασμένη ώστε να επιτρέπει σε οποιονδήποτε χρήστη να\nαλλάξει τον renderer που χρησιμοποιεί ή να σταματήσει να χρησιμοποιεί renderer, αλλά\nαυτό θα πρέπει να γίνεται σκόπιμα για να αποφευχθεί τυχαία τροποποίηση ή απώλεια\nδεδομένων.\n\nΜια άλλη σημαντική σημείωση αφορά την ασφάλεια. Αν χρησιμοποιείτε έναν post-renderer,\nθα πρέπει να διασφαλίσετε ότι προέρχεται από αξιόπιστη πηγή (όπως ισχύει για\nοποιοδήποτε άλλο αυθαίρετο εκτελέσιμο). Η χρήση μη αξιόπιστων ή μη επαληθευμένων\nrenderers ΔΕΝ συνιστάται καθώς έχουν πλήρη πρόσβαση στα παραγόμενα templates, τα\nοποία συχνά περιέχουν ευαίσθητα δεδομένα.\n\n### Προσαρμοσμένοι Post Renderers {#custom-post-renderers}\nΤο βήμα post render προσφέρει ακόμη περισσότερη ευελιξία όταν χρησιμοποιείται με\nτο Go SDK. Οποιοσδήποτε post renderer χρειάζεται μόνο να υλοποιήσει το ακόλουθο\nGo interface:\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nΓια περισσότερες πληροφορίες σχετικά με τη χρήση του Go SDK, δείτε την [ενότητα Go SDK](#go-sdk)\n\n## Go SDK {#go-sdk}\nΤο Helm 3 παρουσίασε ένα πλήρως αναδιαρθρωμένο Go SDK για καλύτερη εμπειρία κατά τη\nδημιουργία λογισμικού και εργαλείων που αξιοποιούν το Helm. Η πλήρης τεκμηρίωση\nβρίσκεται στην [Ενότητα Go SDK](/sdk/gosdk.md).\n\n## Backends αποθήκευσης {#storage-backends}\n\nΤο Helm 3 άλλαξε την προεπιλεγμένη αποθήκευση πληροφοριών release σε Secrets μέσα\nστο namespace του release. Το Helm 2 εξ ορισμού αποθηκεύει πληροφορίες release ως\nConfigMaps στο namespace της instance του Tiller. Οι ακόλουθες υποενότητες δείχνουν\nπώς να ρυθμίσετε διαφορετικά backends. Αυτή η ρύθμιση βασίζεται στη μεταβλητή\nπεριβάλλοντος `HELM_DRIVER`. Μπορεί να οριστεί σε μία από τις τιμές:\n`[configmap, secret, sql]`.\n\n### Backend αποθήκευσης ConfigMap {#configmap-storage-backend}\n\nΓια να ενεργοποιήσετε το ConfigMap backend, θα πρέπει να ορίσετε τη μεταβλητή\nπεριβάλλοντος `HELM_DRIVER` σε `configmap`.\n\nΜπορείτε να το ορίσετε σε ένα shell ως εξής:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nΑν θέλετε να αλλάξετε από το προεπιλεγμένο backend στο ConfigMap backend, θα\nπρέπει να κάνετε τη μετάβαση μόνοι σας. Μπορείτε να ανακτήσετε τις πληροφορίες\nrelease με την ακόλουθη εντολή:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**ΣΗΜΕΙΩΣΕΙΣ ΠΑΡΑΓΩΓΗΣ**: Οι πληροφορίες release περιλαμβάνουν τα περιεχόμενα των\ncharts και των αρχείων values, και επομένως μπορεί να περιέχουν ευαίσθητα δεδομένα\n(όπως κωδικούς πρόσβασης, ιδιωτικά κλειδιά και άλλα διαπιστευτήρια) που πρέπει να\nπροστατευθούν από μη εξουσιοδοτημένη πρόσβαση. Κατά τη διαχείριση της εξουσιοδότησης\nKubernetes, για παράδειγμα με το\n[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), είναι\nδυνατόν να παραχωρηθεί ευρύτερη πρόσβαση σε πόρους ConfigMap, ενώ περιορίζεται η\nπρόσβαση σε πόρους Secret. Για παράδειγμα, ο προεπιλεγμένος [ρόλος χρήστη](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\n\"view\" παρέχει πρόσβαση στους περισσότερους πόρους, αλλά όχι στα Secrets. Επιπλέον,\nτα δεδομένα secrets μπορούν να ρυθμιστούν για [κρυπτογραφημένη αποθήκευση](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).\nΠαρακαλούμε να το έχετε αυτό υπόψη σας αν αποφασίσετε να αλλάξετε στο ConfigMap\nbackend, καθώς θα μπορούσε να εκθέσει τα ευαίσθητα δεδομένα της εφαρμογής σας.\n\n### Backend αποθήκευσης SQL {#sql-storage-backend}\n\nΥπάρχει ένα ***beta*** SQL backend αποθήκευσης που αποθηκεύει πληροφορίες release\nσε μια βάση δεδομένων SQL.\n\nΗ χρήση ενός τέτοιου backend αποθήκευσης είναι ιδιαίτερα χρήσιμη αν οι πληροφορίες\nrelease σας ζυγίζουν περισσότερο από 1MB (σε αυτή την περίπτωση, δεν μπορούν να\nαποθηκευτούν σε ConfigMaps/Secrets λόγω εσωτερικών ορίων στο υποκείμενο etcd\nkey-value store του Kubernetes).\n\nΓια να ενεργοποιήσετε το SQL backend, θα πρέπει να αναπτύξετε μια βάση δεδομένων\nSQL και να ορίσετε τη μεταβλητή περιβάλλοντος `HELM_DRIVER` σε `sql`. Οι\nλεπτομέρειες της βάσης δεδομένων ορίζονται με τη μεταβλητή περιβάλλοντος\n`HELM_DRIVER_SQL_CONNECTION_STRING`.\n\nΜπορείτε να τα ορίσετε σε ένα shell ως εξής:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Σημείωση: Αυτή τη στιγμή υποστηρίζεται μόνο η PostgreSQL.\n\n**ΣΗΜΕΙΩΣΕΙΣ ΠΑΡΑΓΩΓΗΣ**: Συνιστάται να:\n- Κάνετε τη βάση δεδομένων σας έτοιμη για παραγωγή. Για PostgreSQL, ανατρέξτε στην τεκμηρίωση [Server Administration](https://www.postgresql.org/docs/12/admin.html) για περισσότερες λεπτομέρειες\n- Ενεργοποιήσετε τη [διαχείριση δικαιωμάτων](/topics/permissions_sql_storage_backend.md) για να αντικατοπτρίζει το Kubernetes RBAC για τις πληροφορίες release\n\nΑν θέλετε να αλλάξετε από το προεπιλεγμένο backend στο SQL backend, θα πρέπει να\nκάνετε τη μετάβαση μόνοι σας. Μπορείτε να ανακτήσετε τις πληροφορίες release με\nτην ακόλουθη εντολή:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Αρχιτεκτονική του Helm\ndescription: Περιγράφει την αρχιτεκτονική του Helm σε υψηλό επίπεδο.\nsidebar_position: 8\n---\n\n# Αρχιτεκτονική του Helm {#helm-architecture}\n\nΑυτό το έγγραφο περιγράφει την αρχιτεκτονική του Helm σε υψηλό επίπεδο.\n\n## Ο Σκοπός του Helm {#the-purpose-of-helm}\n\nΤο Helm είναι ένα εργαλείο για τη διαχείριση πακέτων Kubernetes που ονομάζονται\n_charts_. Το Helm μπορεί να κάνει τα εξής:\n\n- Δημιουργία νέων charts από την αρχή\n- Πακετάρισμα charts σε αρχεία αρχειοθέτησης chart (tgz)\n- Αλληλεπίδραση με αποθετήρια charts όπου αποθηκεύονται τα charts\n- Εγκατάσταση και απεγκατάσταση charts σε ένα υπάρχον cluster Kubernetes\n- Διαχείριση του κύκλου release των charts που έχουν εγκατασταθεί με το Helm\n\nΣτο Helm, υπάρχουν τρεις σημαντικές έννοιες:\n\n1. Το _chart_ είναι ένα σύνολο πληροφοριών που απαιτούνται για τη δημιουργία\n   μιας instance μιας εφαρμογής Kubernetes.\n2. Το _config_ περιέχει πληροφορίες ρύθμισης παραμέτρων που μπορούν να συγχωνευθούν\n   με ένα πακεταρισμένο chart για τη δημιουργία ενός αντικειμένου έτοιμου προς\n   κυκλοφορία.\n3. Ένα _release_ είναι μια εκτελούμενη instance ενός _chart_, συνδυασμένη με\n   συγκεκριμένη _config_.\n\n## Στοιχεία {#components}\n\nΤο Helm είναι ένα εκτελέσιμο αρχείο που αποτελείται από δύο διακριτά μέρη:\n\n**Ο Helm Client** είναι ένας client γραμμής εντολών για τους τελικούς χρήστες.\nΟ client είναι υπεύθυνος για τα εξής:\n\n- Τοπική ανάπτυξη charts\n- Διαχείριση αποθετηρίων\n- Διαχείριση releases\n- Διασύνδεση με τη βιβλιοθήκη Helm\n  - Αποστολή charts για εγκατάσταση\n  - Αίτηση αναβάθμισης ή απεγκατάστασης υπαρχόντων releases\n\n**Η Βιβλιοθήκη Helm** παρέχει τη λογική για την εκτέλεση όλων των λειτουργιών\nτου Helm. Διασυνδέεται με τον Kubernetes API server και παρέχει τις ακόλουθες\nδυνατότητες:\n\n- Συνδυασμός ενός chart και μιας ρύθμισης παραμέτρων για τη δημιουργία ενός release\n- Εγκατάσταση charts στο Kubernetes και παροχή του αντίστοιχου αντικειμένου release\n- Αναβάθμιση και απεγκατάσταση charts μέσω αλληλεπίδρασης με το Kubernetes\n\nΗ αυτόνομη βιβλιοθήκη Helm ενθυλακώνει τη λογική του Helm ώστε να μπορεί να\nαξιοποιηθεί από διαφορετικούς clients.\n\n## Υλοποίηση {#implementation}\n\nΟ Helm client και η βιβλιοθήκη είναι γραμμένοι στη γλώσσα προγραμματισμού Go.\n\nΗ βιβλιοθήκη χρησιμοποιεί τη client library του Kubernetes για την επικοινωνία\nμε το Kubernetes. Επί του παρόντος, αυτή η βιβλιοθήκη χρησιμοποιεί REST+JSON.\nΑποθηκεύει πληροφορίες σε Secrets μέσα στο Kubernetes. Δεν χρειάζεται τη δική\nτης βάση δεδομένων.\n\nΤα αρχεία ρύθμισης παραμέτρων, όπου είναι δυνατόν, γράφονται σε YAML.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: Οδηγός Αποθετηρίου Chart\ndescription: Πώς να δημιουργήσετε και να εργαστείτε με αποθετήρια Helm chart.\nsidebar_position: 6\n---\n\nΑυτή η ενότητα εξηγεί πώς να δημιουργήσετε και να εργαστείτε με αποθετήρια Helm chart.\nΟυσιαστικά, ένα αποθετήριο chart είναι μια τοποθεσία όπου μπορούν να αποθηκεύονται\nκαι να διαμοιράζονται πακεταρισμένα charts.\n\nΤο κατανεμημένο κοινοτικό αποθετήριο Helm chart βρίσκεται στο\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) και δέχεται\nσυνεισφορές. Ωστόσο, το Helm επιτρέπει επίσης τη δημιουργία και λειτουργία του δικού σας\nαποθετηρίου chart. Αυτός ο οδηγός εξηγεί πώς να το κάνετε. Αν σκέφτεστε να δημιουργήσετε ένα\nαποθετήριο chart, ίσως θέλετε να εξετάσετε τη χρήση ενός\n[μητρώου OCI](/topics/registries.md) ως εναλλακτική.\n\n## Προαπαιτούμενα {#prerequisites}\n\n* Ολοκληρώστε τον οδηγό [Γρήγορης Εκκίνησης](/intro/quickstart.md)\n* Διαβάστε το έγγραφο [Charts](/topics/charts.md)\n\n## Δημιουργία αποθετηρίου chart {#create-a-chart-repository}\n\nΈνα _αποθετήριο chart_ είναι ένας διακομιστής HTTP που φιλοξενεί ένα αρχείο `index.yaml`\nκαι προαιρετικά κάποια πακεταρισμένα charts. Όταν είστε έτοιμοι να διαμοιραστείτε τα\ncharts σας, ο προτιμώμενος τρόπος είναι να τα ανεβάσετε σε ένα αποθετήριο chart.\n\nΑπό το Helm 2.2.0, υποστηρίζεται η αυθεντικοποίηση SSL πελάτη προς ένα αποθετήριο.\nΆλλα πρωτόκολλα αυθεντικοποίησης μπορεί να είναι διαθέσιμα ως plugins.\n\nΕπειδή ένα αποθετήριο chart μπορεί να είναι οποιοσδήποτε διακομιστής HTTP που μπορεί\nνα εξυπηρετεί αρχεία YAML και tar και να απαντά σε αιτήματα GET, έχετε πολλές επιλογές\nόταν πρόκειται να φιλοξενήσετε το δικό σας αποθετήριο chart. Για παράδειγμα, μπορείτε\nνα χρησιμοποιήσετε ένα Google Cloud Storage (GCS) bucket, Amazon S3 bucket,\nGitHub Pages, ή ακόμα να δημιουργήσετε τον δικό σας διακομιστή ιστού.\n\n### Η δομή του αποθετηρίου chart {#the-chart-repository-structure}\n\nΈνα αποθετήριο chart αποτελείται από πακεταρισμένα charts και ένα ειδικό αρχείο που\nονομάζεται `index.yaml`, το οποίο περιέχει ένα ευρετήριο όλων των charts στο αποθετήριο.\nΣυχνά, τα charts που περιγράφει το `index.yaml` φιλοξενούνται επίσης στον ίδιο\nδιακομιστή, όπως και τα [αρχεία προέλευσης](/topics/provenance.md).\n\nΓια παράδειγμα, η διάρθρωση του αποθετηρίου `https://example.com/charts` μπορεί\nνα μοιάζει ως εξής:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nΣε αυτή την περίπτωση, το αρχείο ευρετηρίου θα περιέχει πληροφορίες για ένα chart,\nτο Alpine chart, και θα παρέχει τη διεύθυνση λήψης\n`https://example.com/charts/alpine-0.1.2.tgz` για αυτό το chart.\n\nΔεν είναι απαραίτητο το πακέτο chart να βρίσκεται στον ίδιο διακομιστή με το αρχείο\n`index.yaml`. Ωστόσο, αυτό είναι συνήθως η ευκολότερη λύση.\n\n### Το αρχείο ευρετηρίου {#the-index-file}\n\nΤο αρχείο ευρετηρίου είναι ένα αρχείο yaml που ονομάζεται `index.yaml`. Περιέχει κάποια\nμεταδεδομένα για το πακέτο, συμπεριλαμβανομένων των περιεχομένων του αρχείου\n`Chart.yaml` ενός chart. Ένα έγκυρο αποθετήριο chart πρέπει να έχει ένα αρχείο ευρετηρίου.\nΤο αρχείο ευρετηρίου περιέχει πληροφορίες για κάθε chart στο αποθετήριο chart.\nΗ εντολή `helm repo index` θα δημιουργήσει ένα αρχείο ευρετηρίου βασισμένο σε έναν\nτοπικό κατάλογο που περιέχει πακεταρισμένα charts.\n\nΑυτό είναι ένα παράδειγμα αρχείου ευρετηρίου:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Φιλοξενία Αποθετηρίων Chart {#hosting-chart-repositories}\n\nΑυτό το μέρος παρουσιάζει διάφορους τρόπους εξυπηρέτησης ενός αποθετηρίου chart.\n\n### Google Cloud Storage {#google-cloud-storage}\n\nΤο πρώτο βήμα είναι να **δημιουργήσετε το GCS bucket σας**. Θα ονομάσουμε το δικό μας\n`fantastic-charts`.\n\n![Δημιουργία GCS Bucket](/img/helm2/create-a-bucket.png)\n\nΣτη συνέχεια, κάντε το bucket σας δημόσιο **επεξεργαζόμενοι τα δικαιώματα του bucket**.\n\n![Επεξεργασία Δικαιωμάτων](/img/helm2/edit-permissions.png)\n\nΕισάγετε αυτή τη γραμμή για να **κάνετε το bucket σας δημόσιο**:\n\n![Κάντε το Bucket Δημόσιο](/img/helm2/make-bucket-public.png)\n\nΣυγχαρητήρια, τώρα έχετε ένα κενό GCS bucket έτοιμο να εξυπηρετήσει charts!\n\nΜπορείτε να ανεβάσετε το αποθετήριο chart σας χρησιμοποιώντας το εργαλείο γραμμής\nεντολών Google Cloud Storage ή τη διεπαφή ιστού GCS. Ένα δημόσιο GCS bucket μπορεί\nνα προσπελαστεί μέσω απλού HTTPS στη διεύθυνση: `https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith {#cloudsmith}\n\nΜπορείτε επίσης να δημιουργήσετε αποθετήρια chart χρησιμοποιώντας το Cloudsmith.\nΔιαβάστε περισσότερα για τα αποθετήρια chart με Cloudsmith\n[εδώ](https://help.cloudsmith.io/docs/helm-chart-repository).\n\n### JFrog Artifactory {#jfrog-artifactory}\n\nΠαρομοίως, μπορείτε να δημιουργήσετε αποθετήρια chart χρησιμοποιώντας το JFrog Artifactory.\nΔιαβάστε περισσότερα για τα αποθετήρια chart με JFrog Artifactory\n[εδώ](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories).\n\n### Παράδειγμα με GitHub Pages {#github-pages-example}\n\nΜε παρόμοιο τρόπο μπορείτε να δημιουργήσετε αποθετήριο charts χρησιμοποιώντας GitHub Pages.\n\nΤο GitHub σάς επιτρέπει να εξυπηρετείτε στατικές ιστοσελίδες με δύο διαφορετικούς τρόπους:\n\n- Διαμορφώνοντας ένα έργο να εξυπηρετεί τα περιεχόμενα του καταλόγου `docs/`\n- Διαμορφώνοντας ένα έργο να εξυπηρετεί ένα συγκεκριμένο branch\n\nΘα ακολουθήσουμε τη δεύτερη προσέγγιση, αν και η πρώτη είναι εξίσου εύκολη.\n\nΤο πρώτο βήμα θα είναι να **δημιουργήσετε το gh-pages branch σας**. Μπορείτε να το\nκάνετε τοπικά ως εξής:\n\n```console\n$ git checkout -b gh-pages\n```\n\nΉ μέσω browser χρησιμοποιώντας το κουμπί **Branch** στο GitHub repository σας:\n\n![Δημιουργία GitHub Pages branch](/img/helm2/create-a-gh-page-button.png)\n\nΣτη συνέχεια, θέλετε να βεβαιωθείτε ότι το **gh-pages branch** σας έχει οριστεί ως\nGitHub Pages. Κάντε κλικ στις **Settings** του repository σας και μετακινηθείτε\nστην ενότητα **GitHub pages** και ρυθμίστε ως εξής:\n\n![Δημιουργία GitHub Pages branch](/img/helm2/set-a-gh-page.png)\n\nΑπό προεπιλογή, το **Source** συνήθως ορίζεται στο **gh-pages branch**. Αν αυτό\nδεν είναι ρυθμισμένο από προεπιλογή, τότε επιλέξτε το.\n\nΜπορείτε να χρησιμοποιήσετε ένα **custom domain** αν θέλετε.\n\nΚαι βεβαιωθείτε ότι το **Enforce HTTPS** είναι επιλεγμένο, έτσι ώστε το **HTTPS**\nνα χρησιμοποιείται κατά την εξυπηρέτηση των charts.\n\nΜε αυτή τη ρύθμιση μπορείτε να χρησιμοποιήσετε το default branch σας για να\nαποθηκεύσετε τον κώδικα των charts σας, και το **gh-pages branch** ως αποθετήριο\ncharts, π.χ.: `https://USERNAME.github.io/REPONAME`. Το επιδεικτικό αποθετήριο\n[TS Charts](https://github.com/technosophos/tscharts) είναι προσβάσιμο στη διεύθυνση\n`https://technosophos.github.io/tscharts/`.\n\nΑν έχετε αποφασίσει να χρησιμοποιήσετε GitHub pages για να φιλοξενήσετε το αποθετήριο\nchart, δείτε το [Chart Releaser Action](/howto/chart_releaser_action.md).\nΤο Chart Releaser Action είναι μια ροή εργασίας GitHub Action για τη μετατροπή ενός\nGitHub project σε αυτο-φιλοξενούμενο αποθετήριο Helm chart, χρησιμοποιώντας το\nεργαλείο CLI [helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n### Απλοί διακομιστές ιστού {#ordinary-web-servers}\n\nΓια να διαμορφώσετε έναν απλό διακομιστή ιστού να εξυπηρετεί Helm charts, χρειάζεται\nαπλώς να κάνετε τα εξής:\n\n- Τοποθετήστε το ευρετήριο και τα charts σας σε έναν κατάλογο που μπορεί να εξυπηρετήσει\n  ο διακομιστής\n- Βεβαιωθείτε ότι το αρχείο `index.yaml` είναι προσβάσιμο χωρίς απαίτηση\n  αυθεντικοποίησης\n- Βεβαιωθείτε ότι τα αρχεία `yaml` εξυπηρετούνται με τον σωστό τύπο περιεχομένου\n  (`text/yaml` ή `text/x-yaml`)\n\nΓια παράδειγμα, αν θέλετε να εξυπηρετήσετε τα charts σας από το `$WEBROOT/charts`,\nβεβαιωθείτε ότι υπάρχει ένας κατάλογος `charts/` στο web root σας, και τοποθετήστε\nτο αρχείο ευρετηρίου και τα charts μέσα σε αυτόν τον φάκελο.\n\n### Διακομιστής Αποθετηρίου ChartMuseum {#chartmuseum-repository-server}\n\nΤο ChartMuseum είναι ένας ανοιχτού κώδικα διακομιστής αποθετηρίου Helm Chart\nγραμμένος σε Go (Golang), με υποστήριξη για backends αποθήκευσης cloud,\nσυμπεριλαμβανομένων [Google Cloud Storage](https://cloud.google.com/storage/),\n[Amazon S3](https://aws.amazon.com/s3/),\n[Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/),\n[Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss),\n[Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/),\n[Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage),\n[Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html),\n[Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos),\n[DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/),\n[Minio](https://min.io/), και [etcd](https://etcd.io/).\n\nΜπορείτε επίσης να χρησιμοποιήσετε τον διακομιστή\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\nγια να φιλοξενήσετε ένα αποθετήριο chart από ένα τοπικό σύστημα αρχείων.\n\n### Μητρώο Πακέτων GitLab {#gitlab-package-registry}\n\nΜε το GitLab μπορείτε να δημοσιεύσετε Helm charts στο Package Registry του\nproject σας. Διαβάστε περισσότερα για τη ρύθμιση ενός αποθετηρίου Helm πακέτων\nμε GitLab [εδώ](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Διαχείριση Αποθετηρίων Chart {#managing-chart-repositories}\n\nΤώρα που έχετε ένα αποθετήριο chart, το τελευταίο μέρος αυτού του οδηγού εξηγεί\nπώς να διατηρείτε τα charts σε αυτό το αποθετήριο.\n\n### Αποθήκευση charts στο αποθετήριο chart σας {#store-charts-in-your-chart-repository}\n\nΤώρα που έχετε ένα αποθετήριο chart, ας ανεβάσουμε ένα chart και ένα αρχείο\nευρετηρίου στο αποθετήριο. Τα charts σε ένα αποθετήριο chart πρέπει να είναι\nπακεταρισμένα (`helm package chart-name/`) και σωστά εκδοθέντα (ακολουθώντας τις\nοδηγίες [SemVer 2](https://semver.org/)).\n\nΤα επόμενα βήματα αποτελούν ένα παράδειγμα ροής εργασίας, αλλά μπορείτε να\nχρησιμοποιήσετε όποια ροή εργασίας προτιμάτε για την αποθήκευση και ενημέρωση\ncharts στο αποθετήριο chart σας.\n\nΑφού έχετε ένα πακεταρισμένο chart έτοιμο, δημιουργήστε έναν νέο κατάλογο και\nμετακινήστε το πακεταρισμένο chart σας σε αυτόν τον κατάλογο.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nΗ τελευταία εντολή παίρνει τη διαδρομή του τοπικού καταλόγου που μόλις δημιουργήσατε\nκαι τη διεύθυνση URL του απομακρυσμένου αποθετηρίου chart σας και συνθέτει ένα αρχείο\n`index.yaml` μέσα στη δεδομένη διαδρομή καταλόγου.\n\nΤώρα μπορείτε να ανεβάσετε το chart και το αρχείο ευρετηρίου στο αποθετήριο chart σας\nχρησιμοποιώντας ένα εργαλείο συγχρονισμού ή χειροκίνητα. Αν χρησιμοποιείτε Google\nCloud Storage, δείτε αυτό το\n[παράδειγμα ροής εργασίας](/howto/chart_repository_sync_example.md)\nχρησιμοποιώντας τον gsutil client. Για GitHub, μπορείτε απλά να τοποθετήσετε τα\ncharts στο κατάλληλο branch προορισμού.\n\n### Προσθήκη νέων charts σε υπάρχον αποθετήριο {#add-new-charts-to-an-existing-repository}\n\nΚάθε φορά που θέλετε να προσθέσετε ένα νέο chart στο αποθετήριό σας, πρέπει να\nαναδημιουργήσετε το ευρετήριο. Η εντολή `helm repo index` θα ξαναχτίσει πλήρως\nτο αρχείο `index.yaml` από την αρχή, συμπεριλαμβάνοντας μόνο τα charts που βρίσκει\nτοπικά.\n\nΩστόσο, μπορείτε να χρησιμοποιήσετε τη σημαία `--merge` για να προσθέσετε\nσταδιακά νέα charts σε ένα υπάρχον αρχείο `index.yaml` (μια εξαιρετική επιλογή\nόταν εργάζεστε με απομακρυσμένο αποθετήριο όπως το GCS). Εκτελέστε\n`helm repo index --help` για να μάθετε περισσότερα.\n\nΒεβαιωθείτε ότι ανεβάζετε τόσο το αναθεωρημένο αρχείο `index.yaml` όσο και το\nchart. Και αν δημιουργήσατε αρχείο προέλευσης, ανεβάστε και αυτό.\n\n### Διαμοιρασμός των charts σας με άλλους {#share-your-charts-with-others}\n\nΌταν είστε έτοιμοι να διαμοιραστείτε τα charts σας, απλά ενημερώστε κάποιον ποια\nείναι η διεύθυνση URL του αποθετηρίου σας.\n\nΑπό εκεί, θα προσθέσουν το αποθετήριο στον Helm client τους μέσω της εντολής\n`helm repo add [ΟΝΟΜΑ] [URL]` με οποιοδήποτε όνομα θέλουν να χρησιμοποιήσουν για\nνα αναφέρονται στο αποθετήριο.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nΑν τα charts υποστηρίζονται από βασική αυθεντικοποίηση HTTP, μπορείτε επίσης να\nπαρέχετε το όνομα χρήστη και τον κωδικό πρόσβασης εδώ:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Σημείωση:** Ένα αποθετήριο δεν θα προστεθεί αν δεν περιέχει ένα έγκυρο\n`index.yaml`.\n\n**Σημείωση:** Αν το αποθετήριο Helm σας χρησιμοποιεί π.χ. αυτο-υπογεγραμμένο\nπιστοποιητικό, μπορείτε να χρησιμοποιήσετε `helm repo add --insecure-skip-tls-verify ...`\nγια να παραλείψετε την επαλήθευση CA.\n\nΜετά από αυτό, οι χρήστες σας θα μπορούν να αναζητούν στα charts σας. Αφού\nενημερώσετε το αποθετήριο, μπορούν να χρησιμοποιήσουν την εντολή `helm repo update`\nγια να λάβουν τις τελευταίες πληροφορίες charts.\n\n*Εσωτερικά, οι εντολές `helm repo add` και `helm repo update` ανακτούν το αρχείο\nindex.yaml και το αποθηκεύουν στον κατάλογο `$XDG_CACHE_HOME/helm/repository/cache/`.\nΕκεί βρίσκει η συνάρτηση `helm search` πληροφορίες για τα charts.*\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: Δοκιμές Charts\ndescription: Περιγράφει τον τρόπο εκτέλεσης και δοκιμής των charts σας.\nsidebar_position: 3\n---\n\nΈνα chart περιέχει πολλούς πόρους Kubernetes και components που λειτουργούν\nμαζί. Ως δημιουργός chart, μπορεί να θέλετε να γράψετε κάποιες δοκιμές που\nεπαληθεύουν ότι το chart σας λειτουργεί όπως αναμένεται κατά την εγκατάσταση.\nΑυτές οι δοκιμές βοηθούν επίσης τους χρήστες του chart να κατανοήσουν τι\nυποτίθεται ότι κάνει το chart σας.\n\nΜια **δοκιμή** σε ένα Helm chart βρίσκεται στον φάκελο `templates/` και είναι\nένας ορισμός Job που καθορίζει ένα container με μια συγκεκριμένη εντολή προς\nεκτέλεση. Το container πρέπει να τερματίσει επιτυχώς (exit 0) για να θεωρηθεί\nη δοκιμή επιτυχής. Ο ορισμός του Job πρέπει να περιέχει το annotation hook\nδοκιμής του Helm: `helm.sh/hook: test`.\n\nΣημειώστε ότι μέχρι το Helm v3, ο ορισμός του Job έπρεπε να περιέχει ένα από τα\nπαρακάτω annotations hook δοκιμής του Helm: `helm.sh/hook: test-success` ή\n`helm.sh/hook: test-failure`. Το `helm.sh/hook: test-success` εξακολουθεί να\nγίνεται αποδεκτό ως εναλλακτική επιλογή συμβατή προς τα πίσω αντί του\n`helm.sh/hook: test`.\n\nΠαραδείγματα δοκιμών:\n\n- Επαλήθευση ότι η ρύθμιση παραμέτρων από το αρχείο values.yaml εισήχθη σωστά.\n  - Βεβαιωθείτε ότι το όνομα χρήστη και ο κωδικός πρόσβασης λειτουργούν σωστά\n  - Βεβαιωθείτε ότι ένα εσφαλμένο όνομα χρήστη και κωδικός πρόσβασης δεν\n    λειτουργεί\n- Επιβεβαίωση ότι οι υπηρεσίες σας είναι ενεργές και κατανέμουν σωστά το φορτίο\n- κ.λπ.\n\nΜπορείτε να εκτελέσετε τις προκαθορισμένες δοκιμές του Helm σε ένα release\nχρησιμοποιώντας την εντολή `helm test <RELEASE_NAME>`. Για τους χρήστες ενός\nchart, αυτός είναι ένας εξαιρετικός τρόπος να ελέγξουν ότι το release του chart\n(ή της εφαρμογής) λειτουργεί όπως αναμένεται.\n\n## Παράδειγμα Δοκιμής {#example-test}\n\nΗ εντολή [helm create](/helm/helm_create.md) δημιουργεί αυτόματα έναν αριθμό\nφακέλων και αρχείων. Για να δοκιμάσετε τη λειτουργικότητα του helm test,\nδημιουργήστε πρώτα ένα demo Helm chart.\n\n```console\n$ helm create demo\n```\n\nΘα μπορείτε πλέον να δείτε την ακόλουθη δομή στο demo Helm chart σας.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nΣτο `demo/templates/tests/test-connection.yaml` θα βρείτε μια δοκιμή που μπορείτε\nνα δοκιμάσετε. Παρακάτω μπορείτε να δείτε τον ορισμό του pod δοκιμής του Helm:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Βήματα για την Εκτέλεση μιας Σουίτας Δοκιμών σε ένα Release {#steps-to-run-a-test-suite-on-a-release}\n\nΠρώτα, εγκαταστήστε το chart στο cluster σας για να δημιουργήσετε ένα release.\nΜπορεί να χρειαστεί να περιμένετε μέχρι όλα τα pods να γίνουν ενεργά· αν\nεκτελέσετε τη δοκιμή αμέσως μετά την εγκατάσταση, μπορεί να εμφανιστεί παροδικό\nσφάλμα και θα θέλετε να επαναλάβετε τη δοκιμή.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Σημειώσεις {#notes}\n\n- Μπορείτε να ορίσετε όσες δοκιμές θέλετε σε ένα μόνο αρχείο yaml ή να τις\n  κατανείμετε σε πολλά αρχεία yaml στον φάκελο `templates/`.\n- Μπορείτε να τοποθετήσετε τη σουίτα δοκιμών σας σε έναν υποφάκελο `tests/`\n  όπως `<chart-name>/templates/tests/` για καλύτερη απομόνωση.\n- Μια δοκιμή είναι ένα [Helm hook](/topics/charts_hooks.md), επομένως annotations\n  όπως `helm.sh/hook-weight` και `helm.sh/hook-delete-policy` μπορούν να\n  χρησιμοποιηθούν με τους πόρους δοκιμών.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: Charts\ndescription: Εξηγεί τη μορφή των charts και παρέχει βασικές οδηγίες για τη δημιουργία charts με το Helm.\nsidebar_position: 1\n---\n\nΤο Helm χρησιμοποιεί μια μορφή πακεταρίσματος που ονομάζεται _charts_. Ένα chart είναι μια\nσυλλογή αρχείων που περιγράφουν ένα σύνολο σχετικών πόρων του Kubernetes. Ένα\nchart μπορεί να χρησιμοποιηθεί για να αναπτύξει κάτι απλό, όπως ένα memcached pod, ή\nκάτι πολύπλοκο, όπως μια πλήρη στοίβα web εφαρμογής με HTTP servers, βάσεις δεδομένων,\ncaches κ.λπ.\n\nΤα charts δημιουργούνται ως αρχεία διατεταγμένα σε μια συγκεκριμένη δομή καταλόγων.\nΜπορούν να πακεταριστούν σε versioned αρχεία για ανάπτυξη.\n\nΑν θέλετε να κατεβάσετε και να δείτε τα αρχεία ενός δημοσιευμένου chart, χωρίς να\nτο εγκαταστήσετε, μπορείτε να το κάνετε με την εντολή `helm pull chartrepo/chartname`.\n\nΑυτό το έγγραφο εξηγεί τη μορφή των charts και παρέχει βασικές οδηγίες για\nτη δημιουργία charts με το Helm.\n\n## Η Δομή Αρχείων του Chart {#the-chart-file-structure}\n\nΈνα chart είναι οργανωμένο ως μια συλλογή αρχείων μέσα σε έναν κατάλογο. Το\nόνομα του καταλόγου είναι το όνομα του chart (χωρίς πληροφορίες έκδοσης). Έτσι,\nένα chart που περιγράφει το WordPress θα αποθηκευόταν σε έναν κατάλογο `wordpress/`.\n\nΜέσα σε αυτόν τον κατάλογο, το Helm αναμένει μια δομή που ταιριάζει με αυτή:\n\n```text\nwordpress/\n  Chart.yaml          # A YAML file containing information about the chart\n  LICENSE             # OPTIONAL: A plain text file containing the license for the chart\n  README.md           # OPTIONAL: A human-readable README file\n  values.yaml         # The default configuration values for this chart\n  values.schema.json  # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file\n  charts/             # A directory containing any charts upon which this chart depends.\n  crds/               # Custom Resource Definitions\n  templates/          # A directory of templates that, when combined with values,\n                      # will generate valid Kubernetes manifest files.\n  templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes\n```\n\nΤο Helm δεσμεύει τη χρήση των καταλόγων `charts/`, `crds/` και `templates/`, καθώς\nκαι των αρχείων με τα παραπάνω ονόματα. Τα υπόλοιπα αρχεία θα παραμείνουν ως έχουν.\n\n## Το Αρχείο Chart.yaml {#the-chartyaml-file}\n\nΤο αρχείο `Chart.yaml` είναι απαραίτητο για ένα chart. Περιέχει τα εξής πεδία:\n\n```yaml\napiVersion: The chart API version (required)\nname: The name of the chart (required)\nversion: The version of the chart (required)\nkubeVersion: A SemVer range of compatible Kubernetes versions (optional)\ndescription: A single-sentence description of this project (optional)\ntype: The type of the chart (optional)\nkeywords:\n  - A list of keywords about this project (optional)\nhome: The URL of this projects home page (optional)\nsources:\n  - A list of URLs to source code for this project (optional)\ndependencies: # A list of the chart requirements (optional)\n  - name: The name of the chart (nginx)\n    version: The version of the chart (\"1.2.3\")\n    repository: (optional) The repository URL (\"https://example.com/charts\") or alias (\"@repo-name\")\n    condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )\n    tags: # (optional)\n      - Tags can be used to group charts for enabling/disabling together\n    import-values: # (optional)\n      - 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.\n    alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times\nmaintainers: # (optional)\n  - name: The maintainers name (required for each maintainer)\n    email: The maintainers email (optional for each maintainer)\n    url: A URL for the maintainer (optional for each maintainer)\nicon: A URL to an SVG or PNG image to be used as an icon (optional).\nappVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.\ndeprecated: Whether this chart is deprecated (optional, boolean)\nannotations:\n  example: A list of annotations keyed by name (optional).\n```\n\nΑπό την έκδοση [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), δεν\nεπιτρέπονται επιπλέον πεδία. Η προτεινόμενη προσέγγιση είναι να προσθέσετε\nπροσαρμοσμένα metadata στο πεδίο `annotations`.\n\n### Charts και Εκδοσιοποίηση {#charts-and-versioning}\n\nΚάθε chart πρέπει να έχει έναν αριθμό έκδοσης. Μια έκδοση πρέπει να ακολουθεί\nτο πρότυπο [SemVer 2](https://semver.org/spec/v2.0.0.html), αλλά δεν επιβάλλεται\nαυστηρά. Σε αντίθεση με το Helm Classic, το Helm v2 και μεταγενέστερα χρησιμοποιεί\nτους αριθμούς έκδοσης ως δείκτες release. Τα πακέτα στα repositories\nαναγνωρίζονται από το όνομα συν την έκδοση.\n\nΓια παράδειγμα, ένα `nginx` chart του οποίου το πεδίο version έχει οριστεί σε\n`version: 1.2.3` θα ονομάζεται:\n\n```text\nnginx-1.2.3.tgz\n```\n\nΥποστηρίζονται επίσης πιο σύνθετα ονόματα SemVer 2, όπως\n`version: 1.2.3-alpha.1+ef365`. Ωστόσο, τα μη-SemVer ονόματα απορρίπτονται ρητά\nαπό το σύστημα. Εξαίρεση αποτελούν εκδόσεις στη μορφή `x` ή `x.y`.\nΓια παράδειγμα, αν υπάρχει ένα πρόθεμα v ή μια έκδοση χωρίς και τα 3 μέρη\n(π.χ. v1.2), το σύστημα θα προσπαθήσει να τη μετατρέψει σε έγκυρη σημασιολογική\nέκδοση (π.χ. v1.2.0).\n\n**ΣΗΜΕΙΩΣΗ:** Ενώ το Helm Classic και το Deployment Manager ήταν πολύ\nπροσανατολισμένα στο GitHub όσον αφορά τα charts, το Helm v2 και μεταγενέστερα\nδεν βασίζεται ούτε απαιτεί GitHub ή ακόμα και Git. Κατά συνέπεια, δεν χρησιμοποιεί\nκαθόλου Git SHAs για εκδοσιοποίηση.\n\nΤο πεδίο `version` μέσα στο `Chart.yaml` χρησιμοποιείται από πολλά εργαλεία του Helm,\nσυμπεριλαμβανομένου του CLI. Κατά τη δημιουργία πακέτου, η εντολή `helm package`\nχρησιμοποιεί την έκδοση που βρίσκει στο `Chart.yaml` ως τμήμα του ονόματος του\nπακέτου. Το σύστημα υποθέτει ότι ο αριθμός έκδοσης στο όνομα του πακέτου chart\nταιριάζει με τον αριθμό έκδοσης στο `Chart.yaml`. Η αποτυχία ικανοποίησης αυτής\nτης υπόθεσης θα προκαλέσει σφάλμα.\n\n### Το Πεδίο `apiVersion` {#the-apiversion-field}\n\nΤο πεδίο `apiVersion` πρέπει να είναι `v2` για Helm charts που απαιτούν\nτουλάχιστον Helm 3. Τα charts που υποστηρίζουν προηγούμενες εκδόσεις του Helm\nέχουν `apiVersion` ορισμένο σε `v1` και εξακολουθούν να είναι εγκαταστάσιμα\nαπό το Helm 3.\n\nΑλλαγές από `v1` σε `v2`:\n\n- Ένα πεδίο `dependencies` που ορίζει τις εξαρτήσεις του chart, οι οποίες\n  βρίσκονταν σε ξεχωριστό αρχείο `requirements.yaml` για τα `v1` charts\n  (δείτε [Εξαρτήσεις Chart](#chart-dependencies)).\n- Το πεδίο `type`, που διακρίνει τα application και library charts (δείτε\n  [Τύποι Chart](#chart-types)).\n\n### Το Πεδίο `appVersion` {#the-appversion-field}\n\nΣημειώστε ότι το πεδίο `appVersion` δεν σχετίζεται με το πεδίο `version`. Είναι\nένας τρόπος να προσδιορίσετε την έκδοση της εφαρμογής. Για παράδειγμα, το chart\n`drupal` μπορεί να έχει `appVersion: \"8.2.1\"`, υποδεικνύοντας ότι η έκδοση\nτου Drupal που περιλαμβάνεται στο chart (από προεπιλογή) είναι `8.2.1`. Αυτό\nτο πεδίο είναι πληροφοριακό και δεν επηρεάζει τους υπολογισμούς έκδοσης του chart.\nΣυνιστάται ιδιαίτερα να περικλείετε την έκδοση σε εισαγωγικά. Αναγκάζει τον YAML\nparser να αντιμετωπίσει τον αριθμό έκδοσης ως string. Αν το αφήσετε χωρίς\nεισαγωγικά, μπορεί να προκληθούν προβλήματα parsing σε ορισμένες περιπτώσεις.\nΓια παράδειγμα, το YAML ερμηνεύει το `1.0` ως floating point τιμή, και ένα\ngit commit SHA όπως `1234e10` ως επιστημονική σημειογραφία.\n\nΑπό το Helm v3.5.0, η εντολή `helm create` περικλείει το προεπιλεγμένο πεδίο\n`appVersion` σε εισαγωγικά.\n\n### Το Πεδίο `kubeVersion` {#the-kubeversion-field}\n\nΤο προαιρετικό πεδίο `kubeVersion` μπορεί να ορίσει semver περιορισμούς για τις\nυποστηριζόμενες εκδόσεις Kubernetes. Το Helm θα επικυρώσει τους περιορισμούς\nέκδοσης κατά την εγκατάσταση του chart και θα αποτύχει αν το cluster τρέχει μη\nυποστηριζόμενη έκδοση Kubernetes.\n\nΟι περιορισμοί έκδοσης μπορεί να αποτελούνται από AND συγκρίσεις διαχωρισμένες\nμε κενά, όπως\n```\n>= 1.13.0 < 1.15.0\n```\nοι οποίες μπορούν να συνδυαστούν με τον OR τελεστή `||` όπως στο παρακάτω\nπαράδειγμα\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\nΣε αυτό το παράδειγμα η έκδοση `1.14.0` εξαιρείται, κάτι που μπορεί να έχει\nνόημα αν ένα bug σε συγκεκριμένες εκδόσεις είναι γνωστό ότι εμποδίζει τη\nσωστή λειτουργία του chart.\n\nΕκτός από περιορισμούς έκδοσης με τελεστές `=` `!=` `>` `<` `>=` `<=`,\nυποστηρίζονται και οι εξής συντομεύσεις:\n\n * hyphen ranges για κλειστά διαστήματα, όπου `1.1 - 2.3.4` ισοδυναμεί με\n   `>= 1.1 <= 2.3.4`.\n * wildcards `x`, `X` και `*`, όπου `1.2.x` ισοδυναμεί με `>= 1.2.0 < 1.3.0`.\n * tilde ranges (επιτρέπονται αλλαγές patch version), όπου `~1.2.3` ισοδυναμεί\n   με `>= 1.2.3 < 1.3.0`.\n * caret ranges (επιτρέπονται αλλαγές minor version), όπου `^1.2.3` ισοδυναμεί\n   με `>= 1.2.3 < 2.0.0`.\n\nΓια λεπτομερή εξήγηση των υποστηριζόμενων semver περιορισμών, δείτε το\n[Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Απόσυρση Charts {#deprecating-charts}\n\nΚατά τη διαχείριση charts σε ένα Chart Repository, μερικές φορές είναι απαραίτητο\nνα αποσύρετε ένα chart. Το προαιρετικό πεδίο `deprecated` στο `Chart.yaml`\nμπορεί να χρησιμοποιηθεί για να επισημάνει ένα chart ως απoσυρμένο. Αν η\n**τελευταία** έκδοση ενός chart στο repository είναι επισημασμένη ως αποσυρμένη,\nτότε το chart στο σύνολό του θεωρείται αποσυρμένο. Το όνομα του chart μπορεί\nνα επαναχρησιμοποιηθεί αργότερα δημοσιεύοντας μια νεότερη έκδοση που δεν είναι\nεπισημασμένη ως αποσυρμένη. Η ροή εργασίας για την απόσυρση charts είναι:\n\n1. Ενημερώστε το `Chart.yaml` του chart για να επισημάνετε το chart ως\n   αποσυρμένο, αυξάνοντας την έκδοση\n2. Δημοσιεύστε τη νέα έκδοση chart στο Chart Repository\n3. Αφαιρέστε το chart από το source repository (π.χ. git)\n\n### Τύποι Chart {#chart-types}\n\nΤο πεδίο `type` ορίζει τον τύπο του chart. Υπάρχουν δύο τύποι: `application`\nκαι `library`. Ο application είναι ο προεπιλεγμένος τύπος και είναι το τυπικό\nchart που μπορεί να λειτουργήσει πλήρως. Το [library chart](/topics/library_charts.md)\nπαρέχει εργαλεία ή συναρτήσεις για τον κατασκευαστή chart. Ένα library chart\nδιαφέρει από ένα application chart επειδή δεν είναι εγκαταστάσιμο και συνήθως\nδεν περιέχει αντικείμενα πόρων.\n\n**Σημείωση:** Ένα application chart μπορεί να χρησιμοποιηθεί ως library chart.\nΑυτό ενεργοποιείται ορίζοντας τον τύπο σε `library`. Το chart θα αποδοθεί τότε\nως library chart όπου όλα τα εργαλεία και οι συναρτήσεις μπορούν να αξιοποιηθούν.\nΌλα τα αντικείμενα πόρων του chart δεν θα αποδοθούν.\n\n## Chart LICENSE, README και NOTES {#chart-license-readme-and-notes}\n\nΤα charts μπορούν επίσης να περιέχουν αρχεία που περιγράφουν την εγκατάσταση,\nτη διαμόρφωση, τη χρήση και την άδεια ενός chart.\n\nΈνα LICENSE είναι ένα απλό αρχείο κειμένου που περιέχει την\n[άδεια χρήσης](https://en.wikipedia.org/wiki/Software_license) για το chart.\nΤο chart μπορεί να περιέχει άδεια καθώς μπορεί να έχει προγραμματιστική λογική\nστα templates και επομένως να μην είναι μόνο διαμόρφωση. Μπορεί επίσης να\nυπάρχουν ξεχωριστές άδειες για την εφαρμογή που εγκαθίσταται από το chart,\nαν απαιτείται.\n\nΈνα README για ένα chart πρέπει να είναι μορφοποιημένο σε Markdown (README.md)\nκαι γενικά να περιέχει:\n\n- Μια περιγραφή της εφαρμογής ή υπηρεσίας που παρέχει το chart\n- Τυχόν προαπαιτούμενα ή απαιτήσεις για την εκτέλεση του chart\n- Περιγραφές των επιλογών στο `values.yaml` και τις προεπιλεγμένες τιμές\n- Οποιαδήποτε άλλη πληροφορία που μπορεί να είναι σχετική με την εγκατάσταση\n  ή τη διαμόρφωση του chart\n\nΌταν τα hubs και άλλα περιβάλλοντα χρήστη εμφανίζουν λεπτομέρειες για ένα chart,\nαυτές οι λεπτομέρειες λαμβάνονται από το περιεχόμενο του αρχείου `README.md`.\n\nΤο chart μπορεί επίσης να περιέχει ένα σύντομο αρχείο κειμένου\n`templates/NOTES.txt` που θα εκτυπώνεται μετά την εγκατάσταση και κατά την\nπροβολή της κατάστασης ενός release. Αυτό το αρχείο αξιολογείται ως\n[template](#templates-and-values) και μπορεί να χρησιμοποιηθεί για να εμφανίσει\nσημειώσεις χρήσης, επόμενα βήματα, ή οποιαδήποτε άλλη πληροφορία σχετική με\nένα release του chart. Για παράδειγμα, θα μπορούσαν να παρασχεθούν οδηγίες\nγια σύνδεση σε μια βάση δεδομένων ή πρόσβαση σε ένα web UI. Δεδομένου ότι αυτό\nτο αρχείο εκτυπώνεται στο STDOUT κατά την εκτέλεση `helm install` ή `helm status`,\nσυνιστάται να διατηρείτε το περιεχόμενο σύντομο και να παραπέμπετε στο README\nγια περισσότερες λεπτομέρειες.\n\n## Εξαρτήσεις Chart {#chart-dependencies}\n\nΣτο Helm, ένα chart μπορεί να εξαρτάται από οποιονδήποτε αριθμό άλλων charts.\nΑυτές οι εξαρτήσεις μπορούν να συνδεθούν δυναμικά χρησιμοποιώντας το πεδίο\n`dependencies` στο `Chart.yaml` ή να εισαχθούν στον κατάλογο `charts/` και\nνα διαχειριστούν χειροκίνητα.\n\n### Διαχείριση Εξαρτήσεων με το Πεδίο `dependencies` {#managing-dependencies-with-the-dependencies-field}\n\nΤα charts που απαιτούνται από το τρέχον chart ορίζονται ως λίστα στο πεδίο\n`dependencies`.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- Το πεδίο `name` είναι το όνομα του chart που θέλετε.\n- Το πεδίο `version` είναι η έκδοση του chart που θέλετε.\n- Το πεδίο `repository` είναι το πλήρες URL του chart repository. Σημειώστε\n  ότι πρέπει επίσης να χρησιμοποιήσετε `helm repo add` για να προσθέσετε αυτό\n  το repo τοπικά.\n- Μπορείτε να χρησιμοποιήσετε το όνομα του repo αντί για URL\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nΑφού ορίσετε τις εξαρτήσεις, μπορείτε να εκτελέσετε `helm dependency update`\nκαι θα χρησιμοποιήσει το αρχείο εξαρτήσεων για να κατεβάσει όλα τα καθορισμένα\ncharts στον κατάλογο `charts/` για εσάς.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nΌταν η `helm dependency update` ανακτά charts, θα τα αποθηκεύσει ως chart\narchives στον κατάλογο `charts/`. Για το παραπάνω παράδειγμα, θα περιμένατε\nνα δείτε τα εξής αρχεία στον κατάλογο charts:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Πεδίο Alias στις Εξαρτήσεις {#alias-field-in-dependencies}\n\nΕπιπλέον των άλλων πεδίων παραπάνω, κάθε εγγραφή εξαρτήσεων μπορεί να περιέχει\nτο προαιρετικό πεδίο `alias`.\n\nΗ προσθήκη ενός alias για ένα chart εξάρτησης θα τοποθετήσει ένα chart στις\nεξαρτήσεις χρησιμοποιώντας το alias ως όνομα της νέας εξάρτησης.\n\nΜπορείτε να χρησιμοποιήσετε το `alias` σε περιπτώσεις όπου χρειάζεται να\nπροσπελάσετε ένα chart με άλλο όνομα(τα).\n\n```yaml\n# parentchart/Chart.yaml {#parentchartchartyaml} {#parentchartchartyaml}\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nΣτο παραπάνω παράδειγμα θα πάρουμε συνολικά 3 εξαρτήσεις για το `parentchart`:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nΟ χειροκίνητος τρόπος για να επιτευχθεί αυτό είναι με copy/paste του ίδιου\nchart στον κατάλογο `charts/` πολλές φορές με διαφορετικά ονόματα.\n\n#### Πεδία Tags και Condition στις Εξαρτήσεις {#tags-and-condition-fields-in-dependencies}\n\nΕπιπλέον των άλλων πεδίων παραπάνω, κάθε εγγραφή εξαρτήσεων μπορεί να περιέχει\nτα προαιρετικά πεδία `tags` και `condition`.\n\nΌλα τα charts φορτώνονται από προεπιλογή. Αν υπάρχουν πεδία `tags` ή `condition`,\nθα αξιολογηθούν και θα χρησιμοποιηθούν για τον έλεγχο φόρτωσης του/των chart(s)\nστα οποία εφαρμόζονται.\n\nCondition - Το πεδίο condition περιέχει μία ή περισσότερες διαδρομές YAML\n(διαχωρισμένες με κόμμα). Αν αυτή η διαδρομή υπάρχει στα values του ανώτερου\nγονικού και επιλύεται σε boolean τιμή, το chart θα ενεργοποιηθεί ή\nαπενεργοποιηθεί βάσει αυτής της boolean τιμής. Μόνο η πρώτη έγκυρη διαδρομή\nπου βρέθηκε στη λίστα αξιολογείται και αν δεν υπάρχουν διαδρομές, τότε η\ncondition δεν έχει αποτέλεσμα.\n\nTags - Το πεδίο tags είναι μια YAML λίστα ετικετών που σχετίζονται με αυτό\nτο chart. Στα values του ανώτερου γονικού, όλα τα charts με tags μπορούν να\nενεργοποιηθούν ή να απενεργοποιηθούν καθορίζοντας το tag και μια boolean τιμή.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml {#parentchartvaluesyaml}\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nΣτο παραπάνω παράδειγμα, όλα τα charts με το tag `front-end` θα απενεργοποιηθούν,\nαλλά επειδή η διαδρομή `subchart1.enabled` αξιολογείται ως 'true' στα values\nτου γονικού, η condition θα υπερισχύσει του tag `front-end` και το `subchart1`\nθα ενεργοποιηθεί.\n\nΔεδομένου ότι το `subchart2` έχει tag `back-end` και αυτό το tag αξιολογείται\nσε `true`, το `subchart2` θα ενεργοποιηθεί. Επίσης σημειώστε ότι παρόλο που\nτο `subchart2` έχει καθορισμένη condition, δεν υπάρχει αντίστοιχη διαδρομή\nκαι τιμή στα values του γονικού, οπότε αυτή η condition δεν έχει αποτέλεσμα.\n\n##### Χρήση του CLI με Tags και Conditions {#using-the-cli-with-tags-and-conditions}\n\nΗ παράμετρος `--set` μπορεί να χρησιμοποιηθεί όπως συνήθως για να αλλάξει\nτις τιμές tag και condition.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Επίλυση Tags και Conditions {#tags-and-condition-resolution}\n\n- **Οι conditions (όταν ορίζονται στα values) υπερισχύουν πάντα των tags.**\n  Η πρώτη διαδρομή condition που υπάρχει κερδίζει και οι επόμενες για αυτό\n  το chart αγνοούνται.\n- Τα tags αξιολογούνται ως 'αν οποιοδήποτε από τα tags του chart είναι true,\n  τότε ενεργοποίησε το chart'.\n- Οι τιμές tags και conditions πρέπει να οριστούν στα values του ανώτερου\n  γονικού.\n- Το κλειδί `tags:` στα values πρέπει να είναι κλειδί ανώτατου επιπέδου.\n  Τα globals και εμφωλευμένοι πίνακες `tags:` δεν υποστηρίζονται προς το παρόν.\n\n#### Εισαγωγή Τιμών Θυγατρικών μέσω Εξαρτήσεων {#importing-child-values-via-dependencies}\n\nΣε ορισμένες περιπτώσεις είναι επιθυμητό να επιτρέπεται στις τιμές ενός\nθυγατρικού chart να διαδοθούν στο γονικό chart και να μοιραστούν ως κοινές\nπροεπιλογές. Ένα επιπλέον πλεονέκτημα της χρήσης της μορφής `exports` είναι\nότι θα επιτρέψει σε μελλοντικά εργαλεία να εξετάζουν τις ρυθμιζόμενες τιμές\nχρήστη.\n\nΤα κλειδιά που περιέχουν τις τιμές προς εισαγωγή μπορούν να καθοριστούν στο\n`dependencies` του γονικού chart στο πεδίο `import-values` χρησιμοποιώντας\nμια λίστα YAML. Κάθε στοιχείο στη λίστα είναι ένα κλειδί που εισάγεται από\nτο πεδίο `exports` του θυγατρικού chart.\n\nΓια να εισάγετε τιμές που δεν περιέχονται στο κλειδί `exports`, χρησιμοποιήστε\nτη μορφή [child-parent](#using-the-child-parent-format). Παραδείγματα και\nτων δύο μορφών περιγράφονται παρακάτω.\n\n##### Χρήση της Μορφής Exports {#using-the-exports-format}\n\nΑν το αρχείο `values.yaml` ενός θυγατρικού chart περιέχει ένα πεδίο `exports`\nστη ρίζα, τα περιεχόμενά του μπορούν να εισαχθούν απευθείας στα values του\nγονικού καθορίζοντας τα κλειδιά προς εισαγωγή όπως στο παρακάτω παράδειγμα:\n\n```yaml\n# parent's Chart.yaml file {#parents-chartyaml-file} {#parents-chartyaml-file}\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file {#childs-valuesyaml-file}\n\nexports:\n  data:\n    myint: 99\n```\n\nΔεδομένου ότι καθορίζουμε το κλειδί `data` στη λίστα εισαγωγών, το Helm ψάχνει\nστο πεδίο `exports` του θυγατρικού chart για το κλειδί `data` και εισάγει\nτα περιεχόμενά του.\n\nΤα τελικά values του γονικού θα περιέχουν το εξαγόμενο πεδίο:\n\n```yaml\n# parent's values {#parents-values}\n\nmyint: 99\n```\n\nΣημειώστε ότι το γονικό κλειδί `data` δεν περιέχεται στα τελικά values του\nγονικού. Αν χρειάζεστε να καθορίσετε το γονικό κλειδί, χρησιμοποιήστε τη\nμορφή 'child-parent'.\n\n##### Χρήση της Μορφής Child-Parent {#using-the-child-parent-format}\n\nΓια να προσπελάσετε τιμές που δεν περιέχονται στο κλειδί `exports` των values\nτου θυγατρικού chart, θα πρέπει να καθορίσετε το κλειδί πηγή των τιμών\nπρος εισαγωγή (`child`) και τη διαδρομή προορισμού στα values του γονικού\nchart (`parent`).\n\nΤο `import-values` στο παρακάτω παράδειγμα δίνει εντολή στο Helm να πάρει\nοποιεσδήποτε τιμές βρεθούν στη διαδρομή `child:` και να τις αντιγράψει\nστα values του γονικού στη διαδρομή που καθορίζεται στο `parent:`\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nΣτο παραπάνω παράδειγμα, οι τιμές που βρίσκονται στο `default.data` στα values\nτου subchart1 θα εισαχθούν στο κλειδί `myimports` στα values του γονικού\nchart όπως περιγράφεται παρακάτω:\n\n```yaml\n# parent's values.yaml file {#parents-valuesyaml-file}\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file {#subchart1s-valuesyaml-file}\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nΤα τελικά values του γονικού chart θα είναι:\n\n```yaml\n# parent's final values {#parents-final-values}\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nΤα τελικά values του γονικού περιέχουν τώρα τα πεδία `myint` και `mybool`\nπου εισήχθησαν από το subchart1.\n\n### Χειροκίνητη Διαχείριση Εξαρτήσεων μέσω του Καταλόγου `charts/` {#managing-dependencies-manually-via-the-charts-directory}\n\nΑν επιθυμείται περισσότερος έλεγχος στις εξαρτήσεις, αυτές οι εξαρτήσεις\nμπορούν να εκφραστούν ρητά αντιγράφοντας τα charts εξαρτήσεων στον κατάλογο\n`charts/`.\n\nΜια εξάρτηση πρέπει να είναι ένας μη συμπιεσμένος κατάλογος chart, αλλά το\nόνομά του δεν μπορεί να ξεκινά με `_` ή `.`. Τέτοια αρχεία αγνοούνται από\nτον φορτωτή chart.\n\nΓια παράδειγμα, αν το WordPress chart εξαρτάται από το Apache chart, το Apache\nchart (της σωστής έκδοσης) παρέχεται στον κατάλογο `charts/` του WordPress\nchart:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nΤο παραπάνω παράδειγμα δείχνει πώς το WordPress chart εκφράζει την εξάρτησή\nτου από το Apache και το MySQL συμπεριλαμβάνοντας αυτά τα charts μέσα στον\nκατάλογο `charts/` του.\n\n**ΣΥΜΒΟΥΛΗ:** _Για να τοποθετήσετε μια εξάρτηση στον κατάλογο `charts/`,\nχρησιμοποιήστε την εντολή `helm pull`_\n\n### Λειτουργικές Πτυχές της Χρήσης Εξαρτήσεων {#operational-aspects-of-using-dependencies}\n\nΟι παραπάνω ενότητες εξηγούν πώς να καθορίσετε εξαρτήσεις chart, αλλά πώς\nεπηρεάζει αυτό την εγκατάσταση chart χρησιμοποιώντας `helm install` και\n`helm upgrade`;\n\nΥποθέστε ότι ένα chart με όνομα \"A\" δημιουργεί τα εξής αντικείμενα Kubernetes:\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nΕπιπλέον, το A εξαρτάται από το chart B που δημιουργεί αντικείμενα:\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nΜετά την εγκατάσταση/αναβάθμιση του chart A, δημιουργείται/τροποποιείται ένα\nμόνο Helm release. Το release θα δημιουργήσει/ενημερώσει όλα τα παραπάνω\nαντικείμενα Kubernetes με την εξής σειρά:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nΑυτό συμβαίνει επειδή όταν το Helm εγκαθιστά/αναβαθμίζει charts, τα αντικείμενα\nKubernetes από τα charts και όλες τις εξαρτήσεις τους:\n\n- συγκεντρώνονται σε ένα ενιαίο σύνολο· στη συνέχεια\n- ταξινομούνται κατά τύπο και έπειτα κατά όνομα· και τέλος\n- δημιουργούνται/ενημερώνονται με αυτή τη σειρά.\n\nΕπομένως, δημιουργείται ένα μόνο release με όλα τα αντικείμενα για το chart\nκαι τις εξαρτήσεις του.\n\nΗ σειρά εγκατάστασης των τύπων Kubernetes δίνεται από την απαρίθμηση InstallOrder\nστο kind_sorter.go (δείτε [τον πηγαίο κώδικα του Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n## Templates και Values {#templates-and-values}\n\nΤα Helm Chart templates γράφονται στη [γλώσσα template της Go](https://golang.org/pkg/text/template/), με την προσθήκη 50 και πλέον\nσυναρτήσεων template [από τη βιβλιοθήκη Sprig](https://github.com/Masterminds/sprig) και μερικές άλλες [εξειδικευμένες συναρτήσεις](/howto/charts_tips_and_tricks.md).\n\nΌλα τα αρχεία template αποθηκεύονται στον φάκελο `templates/` ενός chart.\nΌταν το Helm αποδίδει τα charts, θα περάσει κάθε αρχείο σε αυτόν τον κατάλογο\nμέσω της μηχανής template.\n\nΟι τιμές για τα templates παρέχονται με δύο τρόπους:\n\n- Οι προγραμματιστές chart μπορούν να παρέχουν ένα αρχείο με όνομα `values.yaml`\n  μέσα σε ένα chart. Αυτό το αρχείο μπορεί να περιέχει προεπιλεγμένες τιμές.\n- Οι χρήστες chart μπορούν να παρέχουν ένα αρχείο YAML που περιέχει τιμές.\n  Αυτό μπορεί να παρασχεθεί στη γραμμή εντολών με `helm install`.\n\nΌταν ένας χρήστης παρέχει προσαρμοσμένες τιμές, αυτές οι τιμές θα υπερισχύσουν\nτων τιμών στο αρχείο `values.yaml` του chart.\n\n### Αρχεία Template {#template-files}\n\nΤα αρχεία template ακολουθούν τις τυπικές συμβάσεις για τη σύνταξη Go templates\n(δείτε την [τεκμηρίωση του πακέτου text/template της Go](https://golang.org/pkg/text/template/)\nγια λεπτομέρειες). Ένα παράδειγμα αρχείου template μπορεί να μοιάζει κάπως έτσι:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nΤο παραπάνω παράδειγμα, βασισμένο χαλαρά στο\n[https://github.com/deis/charts](https://github.com/deis/charts), είναι ένα\ntemplate για έναν Kubernetes replication controller. Μπορεί να χρησιμοποιήσει\nτις εξής τέσσερις τιμές template (συνήθως ορίζονται σε ένα αρχείο `values.yaml`):\n\n- `imageRegistry`: Το source registry για το Docker image.\n- `dockerTag`: Το tag για το docker image.\n- `pullPolicy`: Η Kubernetes pull policy.\n- `storage`: Το storage backend, του οποίου η προεπιλογή ορίζεται σε `\"minio\"`\n\nΌλες αυτές οι τιμές ορίζονται από τον συγγραφέα template. Το Helm δεν απαιτεί\nούτε επιβάλλει παραμέτρους.\n\nΓια να δείτε πολλά λειτουργικά charts, δείτε το [Artifact Hub](https://artifacthub.io/packages/search?kind=0) του CNCF.\n\n### Προκαθορισμένες Τιμές {#predefined-values}\n\nΟι τιμές που παρέχονται μέσω ενός αρχείου `values.yaml` (ή μέσω της σημαίας\n`--set`) είναι προσβάσιμες από το αντικείμενο `.Values` σε ένα template.\nΑλλά υπάρχουν και άλλα προκαθορισμένα δεδομένα που μπορείτε να προσπελάσετε\nστα templates σας.\n\nΟι ακόλουθες τιμές είναι προκαθορισμένες, είναι διαθέσιμες σε κάθε template\nκαι δεν μπορούν να παρακαμφθούν. Όπως με όλες τις τιμές, τα ονόματα είναι\n_case sensitive_.\n\n- `Release.Name`: Το όνομα του release (όχι του chart)\n- `Release.Namespace`: Το namespace στο οποίο εκδόθηκε το chart.\n- `Release.Service`: Η υπηρεσία που διεξήγαγε το release.\n- `Release.IsUpgrade`: Ορίζεται σε true αν η τρέχουσα λειτουργία είναι\n  αναβάθμιση ή rollback.\n- `Release.IsInstall`: Ορίζεται σε true αν η τρέχουσα λειτουργία είναι\n  εγκατάσταση.\n- `Chart`: Τα περιεχόμενα του `Chart.yaml`. Έτσι, η έκδοση chart είναι\n  διαθέσιμη ως `Chart.Version` και οι maintainers στο `Chart.Maintainers`.\n- `Files`: Ένα map-like αντικείμενο που περιέχει όλα τα μη ειδικά αρχεία\n  στο chart. Αυτό δεν θα σας δώσει πρόσβαση στα templates, αλλά θα σας δώσει\n  πρόσβαση σε επιπλέον αρχεία που υπάρχουν (εκτός αν εξαιρούνται χρησιμοποιώντας\n  `.helmignore`). Τα αρχεία μπορούν να προσπελαστούν χρησιμοποιώντας\n  `{{ index .Files \"file.name\" }}` ή χρησιμοποιώντας τη συνάρτηση\n  `{{.Files.Get name }}`. Μπορείτε επίσης να προσπελάσετε τα περιεχόμενα\n  του αρχείου ως `[]byte` χρησιμοποιώντας `{{ .Files.GetBytes }}`\n- `Capabilities`: Ένα map-like αντικείμενο που περιέχει πληροφορίες για τις\n  εκδόσεις του Kubernetes (`{{ .Capabilities.KubeVersion }}`) και τις\n  υποστηριζόμενες εκδόσεις Kubernetes API\n  (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n**ΣΗΜΕΙΩΣΗ:** Οποιαδήποτε άγνωστα πεδία του `Chart.yaml` θα απορριφθούν.\nΔεν θα είναι προσβάσιμα μέσα στο αντικείμενο `Chart`. Επομένως, το `Chart.yaml`\nδεν μπορεί να χρησιμοποιηθεί για να περάσετε αυθαίρετα δομημένα δεδομένα\nστο template. Το αρχείο values όμως μπορεί να χρησιμοποιηθεί για αυτό.\n\n### Αρχεία Values {#values-files}\n\nΛαμβάνοντας υπόψη το template στην προηγούμενη ενότητα, ένα αρχείο `values.yaml`\nπου παρέχει τις απαραίτητες τιμές θα έμοιαζε έτσι:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nΈνα αρχείο values είναι μορφοποιημένο σε YAML. Ένα chart μπορεί να περιλαμβάνει\nένα προεπιλεγμένο αρχείο `values.yaml`. Η εντολή helm install επιτρέπει στον\nχρήστη να παρακάμψει τιμές παρέχοντας επιπλέον τιμές YAML:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nΌταν οι τιμές περνιούνται με αυτόν τον τρόπο, θα συγχωνευτούν με το προεπιλεγμένο\nαρχείο values. Για παράδειγμα, θεωρήστε ένα αρχείο `myvals.yaml` που μοιάζει\nέτσι:\n\n```yaml\nstorage: \"gcs\"\n```\n\nΌταν αυτό συγχωνευτεί με το `values.yaml` στο chart, το τελικό περιεχόμενο\nθα είναι:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nΣημειώστε ότι μόνο το τελευταίο πεδίο παρακάμφθηκε.\n\n**ΣΗΜΕΙΩΣΗ:** Το προεπιλεγμένο αρχείο values που περιλαμβάνεται μέσα σε ένα\nchart _πρέπει_ να ονομάζεται `values.yaml`. Αλλά τα αρχεία που καθορίζονται\nστη γραμμή εντολών μπορούν να έχουν οποιοδήποτε όνομα.\n\n**ΣΗΜΕΙΩΣΗ:** Αν χρησιμοποιηθεί η σημαία `--set` στο `helm install` ή\n`helm upgrade`, αυτές οι τιμές απλά μετατρέπονται σε YAML στην πλευρά\nτου client.\n\n**ΣΗΜΕΙΩΣΗ:** Αν υπάρχουν απαιτούμενες εγγραφές στο αρχείο values, μπορούν\nνα δηλωθούν ως υποχρεωτικές στο template του chart χρησιμοποιώντας τη\n[συνάρτηση 'required'](/howto/charts_tips_and_tricks.md)\n\nΟποιαδήποτε από αυτές τις τιμές είναι στη συνέχεια προσβάσιμες μέσα σε templates\nχρησιμοποιώντας το αντικείμενο `.Values`:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Εμβέλεια, Εξαρτήσεις και Values {#scope-dependencies-and-values}\n\nΤα αρχεία values μπορούν να δηλώσουν τιμές για το chart ανώτατου επιπέδου,\nκαθώς και για οποιοδήποτε από τα charts που περιλαμβάνονται στον κατάλογο\n`charts/` αυτού του chart. Ή, για να το θέσουμε διαφορετικά, ένα αρχείο values\nμπορεί να παρέχει τιμές στο chart καθώς και σε οποιαδήποτε από τις εξαρτήσεις\nτου. Για παράδειγμα, το επιδεικτικό WordPress chart παραπάνω έχει τόσο\n`mysql` όσο και `apache` ως εξαρτήσεις. Το αρχείο values θα μπορούσε να παρέχει\nτιμές σε όλα αυτά τα στοιχεία:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nΤα charts σε ανώτερο επίπεδο έχουν πρόσβαση σε όλες τις μεταβλητές που ορίζονται\nαπό κάτω. Έτσι το WordPress chart μπορεί να προσπελάσει τον κωδικό MySQL ως\n`.Values.mysql.password`. Αλλά τα charts χαμηλότερου επιπέδου δεν μπορούν να\nπροσπελάσουν πράγματα στα γονικά charts, οπότε το MySQL δεν θα μπορεί να\nπροσπελάσει την ιδιότητα `title`. Ούτε, εξάλλου, μπορεί να προσπελάσει το\n`apache.port`.\n\nΟι τιμές έχουν namespaces, αλλά τα namespaces περικόπτονται. Έτσι για το\nWordPress chart, μπορεί να προσπελάσει το πεδίο κωδικού MySQL ως\n`.Values.mysql.password`. Αλλά για το MySQL chart, η εμβέλεια των τιμών\nέχει μειωθεί και το πρόθεμα namespace έχει αφαιρεθεί, οπότε θα δει το πεδίο\nκωδικού απλά ως `.Values.password`.\n\n#### Global Values {#global-values}\n\nΑπό την έκδοση 2.0.0-Alpha.2, το Helm υποστηρίζει ειδικές \"global\" τιμές.\nΘεωρήστε αυτή την τροποποιημένη έκδοση του προηγούμενου παραδείγματος:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nΤα παραπάνω προσθέτουν μια ενότητα `global` με την τιμή `app: MyWordPress`.\nΑυτή η τιμή είναι διαθέσιμη σε _όλα_ τα charts ως `.Values.global.app`.\n\nΓια παράδειγμα, τα templates του `mysql` μπορούν να προσπελάσουν το `app` ως\n`{{ .Values.global.app}}`, και το ίδιο μπορεί να κάνει και το chart `apache`.\nΟυσιαστικά, το αρχείο values παραπάνω αναπαράγεται έτσι:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\nΑυτό παρέχει έναν τρόπο κοινής χρήσης μιας μεταβλητής ανώτατου επιπέδου με\nόλα τα subcharts, κάτι που είναι χρήσιμο για ρύθμιση ιδιοτήτων `metadata`\nόπως labels.\n\nΑν ένα subchart δηλώνει μια global μεταβλητή, αυτή η global θα περάσει\n_προς τα κάτω_ (στα subcharts του subchart), αλλά όχι _προς τα πάνω_ στο\nγονικό chart. Δεν υπάρχει τρόπος για ένα subchart να επηρεάσει τις τιμές\nτου γονικού chart.\n\nΕπίσης, οι global μεταβλητές των γονικών charts υπερισχύουν των global\nμεταβλητών από τα subcharts.\n\n### Αρχεία Schema {#schema-files}\n\nΜερικές φορές, ένας συντηρητής chart μπορεί να θέλει να ορίσει μια δομή\nγια τα values του. Αυτό μπορεί να γίνει ορίζοντας ένα schema στο αρχείο\n`values.schema.json`. Ένα schema αναπαρίσταται ως\n[JSON Schema](https://json-schema.org/). Μπορεί να μοιάζει κάπως έτσι:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nΑυτό το schema θα εφαρμοστεί στα values για να τα επικυρώσει. Η επικύρωση\nπραγματοποιείται όταν καλούνται οποιεσδήποτε από τις εξής εντολές:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nΈνα παράδειγμα αρχείου `values.yaml` που πληροί τις απαιτήσεις αυτού του\nschema μπορεί να μοιάζει κάπως έτσι:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nΣημειώστε ότι το schema εφαρμόζεται στο τελικό αντικείμενο `.Values` και\nόχι μόνο στο αρχείο `values.yaml`. Αυτό σημαίνει ότι το ακόλουθο αρχείο\nyaml είναι έγκυρο, δεδομένου ότι το chart εγκαθίσταται με την κατάλληλη\nεπιλογή `--set` που φαίνεται παρακάτω.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nΕπιπλέον, το τελικό αντικείμενο `.Values` ελέγχεται έναντι *όλων* των schemas\nτων subcharts. Αυτό σημαίνει ότι οι περιορισμοί σε ένα subchart δεν μπορούν\nνα παρακαμφθούν από ένα γονικό chart. Αυτό λειτουργεί και αντίστροφα - αν\nένα subchart έχει μια απαίτηση που δεν ικανοποιείται στο αρχείο `values.yaml`\nτου subchart, το γονικό chart *πρέπει* να ικανοποιήσει αυτούς τους περιορισμούς\nγια να είναι έγκυρο.\n\nΗ επικύρωση schema μπορεί να απενεργοποιηθεί ορίζοντας την παρακάτω επιλογή.\nΑυτό είναι ιδιαίτερα χρήσιμο σε περιβάλλοντα air-gapped όταν το αρχείο\nJSON Schema ενός chart περιέχει απομακρυσμένες αναφορές.\n```console\nhelm install --skip-schema-validation\n```\n\n### Αναφορές {#references}\n\nΌσον αφορά τη σύνταξη templates, values και αρχείων schema, υπάρχουν αρκετές\nτυπικές αναφορές που θα σας βοηθήσουν.\n\n- [Go templates](https://godoc.org/text/template)\n- [Επιπλέον συναρτήσεις template](https://godoc.org/github.com/Masterminds/sprig)\n- [Η μορφή YAML](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRDs) {#custom-resource-definitions-crds}\n\nΤο Kubernetes παρέχει έναν μηχανισμό για τη δήλωση νέων τύπων αντικειμένων\nKubernetes. Χρησιμοποιώντας CustomResourceDefinitions (CRDs), οι προγραμματιστές\nKubernetes μπορούν να δηλώσουν προσαρμοσμένους τύπους πόρων.\n\nΣτο Helm 3, τα CRDs αντιμετωπίζονται ως ειδικός τύπος αντικειμένου.\nΕγκαθίστανται πριν από το υπόλοιπο chart και υπόκεινται σε ορισμένους\nπεριορισμούς.\n\nΤα αρχεία YAML CRD πρέπει να τοποθετούνται στον κατάλογο `crds/` μέσα\nσε ένα chart. Πολλά CRDs (διαχωρισμένα με δείκτες αρχής και τέλους YAML)\nμπορούν να τοποθετηθούν στο ίδιο αρχείο. Το Helm θα προσπαθήσει να φορτώσει\n_όλα_ τα αρχεία στον κατάλογο CRD στο Kubernetes.\n\nΤα αρχεία CRD _δεν μπορούν να είναι templated_. Πρέπει να είναι απλά\nέγγραφα YAML.\n\nΌταν το Helm εγκαθιστά ένα νέο chart, θα ανεβάσει τα CRDs, θα περιμένει\nμέχρι τα CRDs να γίνουν διαθέσιμα από τον API server, και μετά θα ξεκινήσει\nτη μηχανή template, θα αποδώσει το υπόλοιπο chart και θα το ανεβάσει στο\nKubernetes. Λόγω αυτής της σειράς, οι πληροφορίες CRD είναι διαθέσιμες\nστο αντικείμενο `.Capabilities` στα Helm templates, και τα Helm templates\nμπορούν να δημιουργήσουν νέα instances αντικειμένων που δηλώθηκαν σε CRDs.\n\nΓια παράδειγμα, αν το chart σας είχε ένα CRD για `CronTab` στον κατάλογο\n`crds/`, μπορείτε να δημιουργήσετε instances του είδους `CronTab` στον\nκατάλογο `templates/`:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nΤο αρχείο `crontab.yaml` πρέπει να περιέχει το CRD χωρίς οδηγίες template:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nΣτη συνέχεια, το template `mycrontab.yaml` μπορεί να δημιουργήσει ένα νέο\n`CronTab` (χρησιμοποιώντας templates ως συνήθως):\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nΤο Helm θα διασφαλίσει ότι το είδος `CronTab` έχει εγκατασταθεί και είναι\nδιαθέσιμο από τον Kubernetes API server πριν προχωρήσει στην εγκατάσταση\nτων πραγμάτων στο `templates/`.\n\n### Περιορισμοί στα CRDs {#limitations-on-crds}\n\nΣε αντίθεση με τα περισσότερα αντικείμενα στο Kubernetes, τα CRDs εγκαθίστανται\nglobally. Για αυτό τον λόγο, το Helm ακολουθεί μια πολύ προσεκτική προσέγγιση\nστη διαχείριση CRDs. Τα CRDs υπόκεινται στους εξής περιορισμούς:\n\n- Τα CRDs δεν επανεγκαθίστανται ποτέ. Αν το Helm διαπιστώσει ότι τα CRDs\n  στον κατάλογο `crds/` υπάρχουν ήδη (ανεξαρτήτως έκδοσης), το Helm δεν\n  θα προσπαθήσει να τα εγκαταστήσει ή να τα αναβαθμίσει.\n- Τα CRDs δεν εγκαθίστανται ποτέ κατά την αναβάθμιση ή το rollback.\n  Το Helm θα δημιουργήσει CRDs μόνο κατά τις λειτουργίες εγκατάστασης.\n- Τα CRDs δεν διαγράφονται ποτέ. Η διαγραφή ενός CRD διαγράφει αυτόματα\n  όλα τα περιεχόμενα του CRD σε όλα τα namespaces στο cluster.\n  Κατά συνέπεια, το Helm δεν θα διαγράψει CRDs.\n\nΟι διαχειριστές που θέλουν να αναβαθμίσουν ή να διαγράψουν CRDs ενθαρρύνονται\nνα το κάνουν χειροκίνητα και με μεγάλη προσοχή.\n\n## Χρήση του Helm για Διαχείριση Charts {#using-helm-to-manage-charts}\n\nΤο εργαλείο `helm` έχει αρκετές εντολές για εργασία με charts.\n\nΜπορεί να δημιουργήσει ένα νέο chart για εσάς:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nΑφού επεξεργαστείτε ένα chart, το `helm` μπορεί να το πακετάρει σε ένα\nchart archive για εσάς:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nΜπορείτε επίσης να χρησιμοποιήσετε το `helm` για να σας βοηθήσει να βρείτε\nπροβλήματα με τη μορφοποίηση ή τις πληροφορίες του chart σας:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Chart Repositories {#chart-repositories}\n\nΈνα _chart repository_ είναι ένας HTTP server που φιλοξενεί ένα ή περισσότερα\nπακεταρισμένα charts. Ενώ το `helm` μπορεί να χρησιμοποιηθεί για τη διαχείριση\nτοπικών καταλόγων chart, όταν πρόκειται για κοινή χρήση charts, ο προτιμώμενος\nμηχανισμός είναι ένα chart repository.\n\nΟποιοσδήποτε HTTP server που μπορεί να εξυπηρετεί αρχεία YAML και tar και\nμπορεί να απαντά σε αιτήματα GET μπορεί να χρησιμοποιηθεί ως server\nrepository. Η ομάδα του Helm έχει δοκιμάσει ορισμένους servers, συμπεριλαμβανομένου\nτου Google Cloud Storage με ενεργοποιημένη τη λειτουργία website και του\nS3 με ενεργοποιημένη τη λειτουργία website.\n\nΈνα repository χαρακτηρίζεται κυρίως από την παρουσία ενός ειδικού αρχείου\nπου ονομάζεται `index.yaml` που έχει μια λίστα με όλα τα πακέτα που παρέχονται\nαπό το repository, μαζί με metadata που επιτρέπουν την ανάκτηση και επαλήθευση\nαυτών των πακέτων.\n\nΣτην πλευρά του client, τα repositories διαχειρίζονται με τις εντολές\n`helm repo`. Ωστόσο, το Helm δεν παρέχει εργαλεία για την αποστολή charts\nσε απομακρυσμένους servers repository. Αυτό συμβαίνει επειδή κάτι τέτοιο\nθα πρόσθετε σημαντικές απαιτήσεις σε έναν server υλοποίησης, και επομένως\nθα αύξανε το εμπόδιο για τη δημιουργία ενός repository.\n\n## Chart Starter Packs {#chart-starter-packs}\n\nΗ εντολή `helm create` δέχεται μια προαιρετική επιλογή `--starter` που σας\nεπιτρέπει να καθορίσετε ένα \"starter chart\". Επίσης, η επιλογή starter έχει\nένα σύντομο alias `-p`.\n\nΠαραδείγματα χρήσης:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nΤα starters είναι απλά κανονικά charts, αλλά βρίσκονται στο\n`$XDG_DATA_HOME/helm/starters`. Ως προγραμματιστής chart, μπορείτε να\nδημιουργήσετε charts που είναι ειδικά σχεδιασμένα για χρήση ως starters.\nΤέτοια charts πρέπει να σχεδιάζονται με τις εξής σκέψεις στο μυαλό:\n\n- Το `Chart.yaml` θα αντικατασταθεί από τον generator.\n- Οι χρήστες θα αναμένουν να τροποποιήσουν τα περιεχόμενα ενός τέτοιου chart,\n  οπότε η τεκμηρίωση πρέπει να υποδεικνύει πώς μπορούν οι χρήστες να το κάνουν.\n- Όλες οι εμφανίσεις του `<CHARTNAME>` θα αντικατασταθούν με το καθορισμένο\n  όνομα chart, ώστε τα starter charts να μπορούν να χρησιμοποιηθούν ως templates,\n  εκτός από ορισμένα αρχεία μεταβλητών. Για παράδειγμα, αν χρησιμοποιείτε\n  προσαρμοσμένα αρχεία στον κατάλογο `vars` ή ορισμένα αρχεία `README.md`,\n  το `<CHARTNAME>` ΔΕΝ θα αντικατασταθεί μέσα σε αυτά. Επιπλέον, η περιγραφή\n  chart δεν κληρονομείται.\n\nΠρος το παρόν, ο μόνος τρόπος να προσθέσετε ένα chart στο\n`$XDG_DATA_HOME/helm/starters` είναι να το αντιγράψετε χειροκίνητα εκεί.\nΣτην τεκμηρίωση του chart σας, μπορεί να θέλετε να εξηγήσετε αυτή τη διαδικασία.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: Hooks σε Charts\ndescription: Περιγράφει τον τρόπο εργασίας με hooks σε charts.\nsidebar_position: 2\n---\n\nΤο Helm παρέχει έναν μηχανισμό _hook_ που επιτρέπει στους δημιουργούς charts να\nπαρεμβαίνουν σε συγκεκριμένα σημεία του κύκλου ζωής ενός release. Για παράδειγμα,\nμπορείτε να χρησιμοποιήσετε hooks για να:\n\n- Φορτώσετε ένα ConfigMap ή Secret κατά την εγκατάσταση πριν φορτωθούν τυχόν άλλα\n  charts.\n- Εκτελέσετε ένα Job για δημιουργία αντιγράφου ασφαλείας μιας βάσης δεδομένων πριν\n  από την εγκατάσταση ενός νέου chart, και στη συνέχεια εκτελέσετε ένα δεύτερο job\n  μετά την αναβάθμιση για να επαναφέρετε τα δεδομένα.\n- Εκτελέσετε ένα Job πριν από τη διαγραφή ενός release για να αφαιρέσετε ομαλά\n  μια υπηρεσία από την εναλλαγή πριν την αφαιρέσετε.\n\nΤα hooks λειτουργούν όπως τα κανονικά templates, αλλά έχουν ειδικά annotations που\nαναγκάζουν το Helm να τα χειρίζεται διαφορετικά. Σε αυτήν την ενότητα καλύπτουμε\nτο βασικό μοτίβο χρήσης για τα hooks.\n\n## Τα Διαθέσιμα Hooks {#the-available-hooks}\n\nΟρίζονται τα ακόλουθα hooks:\n\n| Τιμή Annotation    | Περιγραφή                                                                                                       |\n| ------------------ | --------------------------------------------------------------------------------------------------------------- |\n| `pre-install`      | Εκτελείται μετά την απόδοση των templates, αλλά πριν τη δημιουργία οποιουδήποτε πόρου στο Kubernetes            |\n| `post-install`     | Εκτελείται μετά τη φόρτωση όλων των πόρων στο Kubernetes                                                        |\n| `pre-delete`       | Εκτελείται σε αίτημα διαγραφής πριν τη διαγραφή οποιουδήποτε πόρου από το Kubernetes                            |\n| `post-delete`      | Εκτελείται σε αίτημα διαγραφής αφού διαγραφούν όλοι οι πόροι του release                                        |\n| `pre-upgrade`      | Εκτελείται σε αίτημα αναβάθμισης μετά την απόδοση των templates, αλλά πριν ενημερωθεί οποιοσδήποτε πόρος        |\n| `post-upgrade`     | Εκτελείται σε αίτημα αναβάθμισης μετά την αναβάθμιση όλων των πόρων                                             |\n| `pre-rollback`     | Εκτελείται σε αίτημα rollback μετά την απόδοση των templates, αλλά πριν γίνει rollback οποιουδήποτε πόρου       |\n| `post-rollback`    | Εκτελείται σε αίτημα rollback αφού τροποποιηθούν όλοι οι πόροι                                                  |\n| `test`             | Εκτελείται όταν καλείται η υποεντολή test του Helm ([δείτε την τεκμηρίωση test](/topics/chart_tests.md))        |\n\n_Σημείωση: το hook `crd-install` έχει καταργηθεί υπέρ του φακέλου `crds/`\nστο Helm 3._\n\n## Hooks και ο Κύκλος Ζωής του Release {#hooks-and-the-release-lifecycle}\n\nΤα hooks σας επιτρέπουν, ως δημιουργό chart, να εκτελείτε λειτουργίες σε\nστρατηγικά σημεία του κύκλου ζωής ενός release. Για παράδειγμα, σκεφτείτε τον\nκύκλο ζωής για ένα `helm install`. Από προεπιλογή, ο κύκλος ζωής είναι ο εξής:\n\n1. Ο χρήστης εκτελεί `helm install foo`\n2. Καλείται το API εγκατάστασης της βιβλιοθήκης Helm\n3. Μετά από ορισμένες επαληθεύσεις, η βιβλιοθήκη αποδίδει τα templates του `foo`\n4. Η βιβλιοθήκη φορτώνει τους προκύπτοντες πόρους στο Kubernetes\n5. Η βιβλιοθήκη επιστρέφει το αντικείμενο release (και άλλα δεδομένα) στον client\n6. Ο client τερματίζει\n\nΤο Helm ορίζει δύο hooks για τον κύκλο ζωής `install`: `pre-install` και\n`post-install`. Αν ο δημιουργός του chart `foo` υλοποιήσει και τα δύο hooks,\nο κύκλος ζωής τροποποιείται ως εξής:\n\n1. Ο χρήστης εκτελεί `helm install foo`\n2. Καλείται το API εγκατάστασης της βιβλιοθήκης Helm\n3. Εγκαθίστανται τα CRDs στον φάκελο `crds/`\n4. Μετά από ορισμένες επαληθεύσεις, η βιβλιοθήκη αποδίδει τα templates του `foo`\n5. Η βιβλιοθήκη προετοιμάζεται να εκτελέσει τα hooks `pre-install` (φορτώνοντας\n   τους πόρους hook στο Kubernetes)\n6. Η βιβλιοθήκη ταξινομεί τα hooks κατά βάρος (αναθέτοντας βάρος 0 από προεπιλογή),\n   κατά τύπο πόρου και τέλος κατά όνομα σε αύξουσα σειρά.\n7. Η βιβλιοθήκη φορτώνει πρώτα το hook με το μικρότερο βάρος (αρνητικό προς\n   θετικό)\n8. Η βιβλιοθήκη περιμένει μέχρι το hook να είναι \"Ready\" (εκτός από τα CRDs)\n9. Η βιβλιοθήκη φορτώνει τους προκύπτοντες πόρους στο Kubernetes. Σημειώστε ότι\n   αν έχει οριστεί η σημαία `--wait`, η βιβλιοθήκη θα περιμένει μέχρι όλοι οι\n   πόροι να βρίσκονται σε κατάσταση ready και δεν θα εκτελέσει το hook\n   `post-install` μέχρι να είναι έτοιμοι.\n10. Η βιβλιοθήκη εκτελεί το hook `post-install` (φορτώνοντας τους πόρους hook)\n11. Η βιβλιοθήκη περιμένει μέχρι το hook να είναι \"Ready\"\n12. Η βιβλιοθήκη επιστρέφει το αντικείμενο release (και άλλα δεδομένα) στον client\n13. Ο client τερματίζει\n\nΤι σημαίνει να περιμένουμε μέχρι ένα hook να είναι ready; Αυτό εξαρτάται από τον\nπόρο που δηλώνεται στο hook. Αν ο πόρος είναι τύπου `Job` ή `Pod`, το Helm θα\nπεριμένει μέχρι να ολοκληρωθεί επιτυχώς. Και αν το hook αποτύχει, το release θα\nαποτύχει. Αυτή είναι μια _blocking λειτουργία_, επομένως ο client του Helm θα\nπαραμείνει σε αναμονή κατά την εκτέλεση του Job.\n\nΓια όλους τους άλλους τύπους, μόλις το Kubernetes σημειώσει τον πόρο ως\nφορτωμένο (προστέθηκε ή ενημερώθηκε), ο πόρος θεωρείται \"Ready\". Όταν πολλοί\nπόροι δηλώνονται σε ένα hook, οι πόροι εκτελούνται διαδοχικά. Αν έχουν βάρη hook\n(δείτε παρακάτω), εκτελούνται με σειρά βάρους.\nΑπό το Helm 3.2.0, οι πόροι hook με το ίδιο βάρος εγκαθίστανται με την ίδια\nσειρά όπως οι κανονικοί πόροι που δεν είναι hook. Διαφορετικά, η σειρά\nδεν είναι εγγυημένη. (Στο Helm 2.3.0 και μετά, ταξινομούνται αλφαβητικά. Αυτή\nη συμπεριφορά, ωστόσο, δεν θεωρείται δεσμευτική και μπορεί να αλλάξει στο\nμέλλον.) Θεωρείται καλή πρακτική να προσθέτετε ένα βάρος hook και να το ορίζετε\nσε `0` αν το βάρος δεν είναι σημαντικό.\n\n### Οι πόροι hook δεν διαχειρίζονται μαζί με τα αντίστοιχα releases {#hook-resources-are-not-managed-with-corresponding-releases}\n\nΟι πόροι που δημιουργεί ένα hook δεν παρακολουθούνται ούτε διαχειρίζονται ως\nμέρος του release προς το παρόν. Μόλις το Helm επαληθεύσει ότι το hook έχει\nφτάσει στην κατάσταση ready, θα αφήσει τον πόρο hook ως έχει. Η συλλογή\nαπορριμμάτων των πόρων hook όταν διαγράφεται το αντίστοιχο release μπορεί να\nπροστεθεί στο Helm 3 στο μέλλον, επομένως οποιοιδήποτε πόροι hook που δεν\nπρέπει ποτέ να διαγραφούν θα πρέπει να φέρουν το annotation\n`helm.sh/resource-policy: keep`.\n\nΠρακτικά, αυτό σημαίνει ότι αν δημιουργήσετε πόρους σε ένα hook, δεν μπορείτε\nνα βασιστείτε στο `helm uninstall` για να αφαιρέσει τους πόρους. Για να\nκαταστρέψετε τέτοιους πόρους, πρέπει είτε να [προσθέσετε ένα προσαρμοσμένο\nannotation `helm.sh/hook-delete-policy`](#hook-deletion-policies) στο αρχείο\ntemplate του hook, είτε να [ορίσετε το πεδίο time to live (TTL - χρόνος ζωής)\nJob](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Συγγραφή ενός Hook {#writing-a-hook}\n\nΤα hooks είναι απλά αρχεία manifest του Kubernetes με ειδικά annotations στην\nενότητα `metadata`. Επειδή είναι αρχεία template, μπορείτε να χρησιμοποιήσετε\nόλες τις κανονικές δυνατότητες template, συμπεριλαμβανομένης της ανάγνωσης\n`.Values`, `.Release` και `.Template`.\n\nΓια παράδειγμα, αυτό το template, αποθηκευμένο στο\n`templates/post-install-job.yaml`, δηλώνει ένα job που θα εκτελεστεί στο\n`post-install`:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nΑυτό που κάνει αυτό το template να είναι hook είναι το annotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nΈνας πόρος μπορεί να υλοποιήσει πολλαπλά hooks:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nΟμοίως, δεν υπάρχει όριο στον αριθμό των διαφορετικών πόρων που μπορούν να\nυλοποιήσουν ένα συγκεκριμένο hook. Για παράδειγμα, μπορείτε να δηλώσετε τόσο\nένα secret όσο και ένα config map ως hook `pre-install`.\n\nΌταν τα subcharts δηλώνουν hooks, αυτά αξιολογούνται επίσης. Δεν υπάρχει τρόπος\nγια ένα chart ανώτερου επιπέδου να απενεργοποιήσει τα hooks που δηλώνονται από\nτα subcharts.\n\nΕίναι δυνατός ο ορισμός ενός βάρους για ένα hook που θα βοηθήσει στη δημιουργία\nμιας καθορισμένης σειράς εκτέλεσης. Τα βάρη ορίζονται χρησιμοποιώντας το\nακόλουθο annotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nΤα βάρη hook μπορούν να είναι θετικοί ή αρνητικοί αριθμοί αλλά πρέπει να\nαναπαρίστανται ως strings. Όταν το Helm ξεκινά τον κύκλο εκτέλεσης των hooks\nενός συγκεκριμένου τύπου, θα ταξινομήσει αυτά τα hooks σε αύξουσα σειρά.\n\n### Πολιτικές διαγραφής hook {#hook-deletion-policies}\n\nΕίναι δυνατός ο ορισμός πολιτικών που καθορίζουν πότε θα διαγραφούν οι\nαντίστοιχοι πόροι hook. Οι πολιτικές διαγραφής hook ορίζονται χρησιμοποιώντας\nτο ακόλουθο annotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nΜπορείτε να επιλέξετε μία ή περισσότερες καθορισμένες τιμές annotation:\n\n| Τιμή Annotation          | Περιγραφή                                                                    |\n| ------------------------ | ---------------------------------------------------------------------------- |\n| `before-hook-creation`   | Διαγράφει τον προηγούμενο πόρο πριν εκκινηθεί ένα νέο hook (προεπιλογή)      |\n| `hook-succeeded`         | Διαγράφει τον πόρο μετά την επιτυχή εκτέλεση του hook                        |\n| `hook-failed`            | Διαγράφει τον πόρο αν το hook απέτυχε κατά την εκτέλεση                      |\n\nΑν δεν καθοριστεί annotation πολιτικής διαγραφής hook, εφαρμόζεται η συμπεριφορά\n`before-hook-creation` από προεπιλογή.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: Αποσυρμένα API του Kubernetes\ndescription: Επεξηγεί τα αποσυρμένα API του Kubernetes στο Helm\n---\n\nΤο Kubernetes είναι ένα σύστημα βασισμένο σε API και το API εξελίσσεται με την\nπάροδο του χρόνου, αντικατοπτρίζοντας την εξελισσόμενη κατανόηση του πεδίου\nπροβλημάτων. Αυτό είναι κοινή πρακτική σε συστήματα και τα API τους. Ένα\nσημαντικό μέρος της εξέλιξης των API είναι μια καλή πολιτική απόσυρσης και\nδιαδικασία για να ενημερώνονται οι χρήστες για τις αλλαγές στα API. Δηλαδή, οι\nκαταναλωτές του API σας πρέπει να γνωρίζουν εκ των προτέρων σε ποια έκδοση θα\nέκδοση θα αφαιρεθεί ή θα αλλάξει ένα API. Αυτό αποτρέπει το στοιχείο της\nέκπληξης και τις breaking changes για τους καταναλωτές.\n\nΗ [πολιτική απόσυρσης του\nKubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\nτεκμηριώνει τον τρόπο με τον οποίο το Kubernetes χειρίζεται τις αλλαγές στις\nεκδόσεις του API. Η πολιτική απόσυρσης καθορίζει το χρονικό πλαίσιο υποστήριξης\nτων εκδόσεων API μετά από μια ανακοίνωση απόσυρσης. Επομένως, είναι σημαντικό να\nπαρακολουθείτε τις ανακοινώσεις απόσυρσης και να γνωρίζετε πότε θα αφαιρεθούν οι\nεκδόσεις API, ώστε να ελαχιστοποιήσετε τις επιπτώσεις.\n\nΑυτό είναι ένα παράδειγμα ανακοίνωσης [για την αφαίρεση αποσυρμένων εκδόσεων API\nστο Kubernetes\n1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) που\nδημοσιεύτηκε μερικούς μήνες πριν την κυκλοφορία. Αυτές οι εκδόσεις API θα είχαν\nανακοινωθεί ως αποσυρμένες ακόμα νωρίτερα. Αυτό δείχνει ότι υπάρχει μια καλή\nπολιτική που ενημερώνει τους καταναλωτές για την υποστήριξη εκδόσεων API.\n\nΤα templates του Helm καθορίζουν ένα [Kubernetes API\ngroup](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)\nκατά τον ορισμό ενός αντικειμένου Kubernetes, παρόμοια με ένα αρχείο manifest του\nKubernetes. Καθορίζεται στο πεδίο `apiVersion` του template και προσδιορίζει την\nέκδοση API του αντικειμένου Kubernetes. Αυτό σημαίνει ότι οι χρήστες του Helm και\nοι συντηρητές chart πρέπει να γνωρίζουν πότε οι εκδόσεις API του Kubernetes έχουν\nαποσυρθεί και σε ποια έκδοση Kubernetes θα αφαιρεθούν.\n\n## Συντηρητές Chart {#chart-maintainers}\n\nΘα πρέπει να ελέγξετε τα chart σας για εκδόσεις API του Kubernetes που έχουν\nαποσυρθεί ή αφαιρεθεί σε κάποια έκδοση Kubernetes. Οι εκδόσεις API που\nπροβλέπεται να αποσυρθούν ή δεν υποστηρίζονται πλέον, θα πρέπει να ενημερωθούν\nστην υποστηριζόμενη έκδοση και να κυκλοφορήσει μια νέα έκδοση του chart. Η\nέκδοση API ορίζεται από τα πεδία `kind` και `apiVersion`. Για παράδειγμα, εδώ\nείναι μια αφαιρεμένη έκδοση API αντικειμένου `Deployment` στο Kubernetes 1.16:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Χρήστες του Helm {#helm-users}\n\nΘα πρέπει να ελέγξετε τα chart που χρησιμοποιείτε (παρόμοια με τους [συντηρητές\nchart](#chart-maintainers)) και να εντοπίσετε τυχόν chart με εκδόσεις API που\nέχουν αποσυρθεί ή αφαιρεθεί σε κάποια έκδοση Kubernetes. Για τα chart που\nεντοπίζετε, πρέπει να ελέγξετε για την τελευταία έκδοση του chart (που έχει\nυποστηριζόμενες εκδόσεις API) ή να ενημερώσετε το chart μόνοι σας.\n\nΕπιπλέον, πρέπει επίσης να ελέγξετε τα chart που έχετε εγκαταστήσει (δηλαδή τα\nHelm releases) για τυχόν αποσυρμένες ή αφαιρεμένες εκδόσεις API. Αυτό μπορεί να\nγίνει με τη λήψη λεπτομερειών ενός release χρησιμοποιώντας την εντολή `helm get\nmanifest`.\n\nΟ τρόπος ενημέρωσης ενός Helm release σε υποστηριζόμενα API εξαρτάται από τα\nευρήματά σας ως εξής:\n\n1. Αν βρείτε μόνο αποσυρμένες εκδόσεις API τότε:\n  - Εκτελέστε `helm upgrade` με μια έκδοση του chart που έχει υποστηριζόμενες\n    εκδόσεις API του Kubernetes\n  - Προσθέστε μια περιγραφή στην αναβάθμιση, που να αναφέρει να μην γίνει\n    rollback σε έκδοση Helm πριν από αυτή την τρέχουσα έκδοση\n2. Αν βρείτε κάποια έκδοση(εις) API που έχει(ουν) αφαιρεθεί σε κάποια έκδοση\n   Kubernetes τότε:\n  - Αν εκτελείτε μια έκδοση Kubernetes όπου η(οι) έκδοση(εις) API είναι ακόμα\n    διαθέσιμη(ες) (για παράδειγμα, είστε στο Kubernetes 1.15 και βρήκατε ότι\n    χρησιμοποιείτε API που θα αφαιρεθούν στο Kubernetes 1.16):\n    - Ακολουθήστε τη διαδικασία του βήματος 1\n  - Διαφορετικά (για παράδειγμα, εκτελείτε ήδη μια έκδοση Kubernetes όπου\n    κάποιες εκδόσεις API που αναφέρονται από το `helm get manifest` δεν είναι\n    πλέον διαθέσιμες):\n    - Πρέπει να επεξεργαστείτε το manifest του release που είναι αποθηκευμένο\n      στο cluster για να ενημερώσετε τις εκδόσεις API σε υποστηριζόμενα API.\n      Δείτε [Ενημέρωση Εκδόσεων API ενός Release\n      Manifest](#updating-api-versions-of-a-release-manifest) για\n      περισσότερες λεπτομέρειες\n\n> Σημείωση: Σε όλες τις περιπτώσεις ενημέρωσης ενός Helm release με\nυποστηριζόμενα API, δεν πρέπει ποτέ να κάνετε rollback του release σε έκδοση\nπριν από την έκδοση release με τα υποστηριζόμενα API.\n\n> Σύσταση: Η βέλτιστη πρακτική είναι να αναβαθμίζετε τα releases που\nχρησιμοποιούν αποσυρμένες εκδόσεις API σε υποστηριζόμενες εκδόσεις API, πριν\nαναβαθμίσετε σε ένα Kubernetes cluster που αφαιρεί αυτές τις εκδόσεις API.\n\nΑν δεν ενημερώσετε ένα release όπως προτείνεται παραπάνω, θα λάβετε ένα σφάλμα\nπαρόμοιο με το ακόλουθο όταν προσπαθήσετε να αναβαθμίσετε ένα release σε μια\nέκδοση Kubernetes όπου η(οι) έκδοση(εις) API του έχει(ουν) αφαιρεθεί:\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nΤο Helm αποτυγχάνει σε αυτό το σενάριο επειδή προσπαθεί να δημιουργήσει ένα diff\npatch μεταξύ του τρέχοντος εγκατεστημένου release (που περιέχει τα API του\nKubernetes που έχουν αφαιρεθεί σε αυτή την έκδοση Kubernetes) και του chart που\nπερνάτε με τις ενημερωμένες/υποστηριζόμενες εκδόσεις API. Ο υποκείμενος λόγος\nτης αποτυχίας είναι ότι όταν το Kubernetes αφαιρεί μια έκδοση API, η βιβλιοθήκη\nGo client του Kubernetes δεν μπορεί πλέον να αναλύσει τα αποσυρμένα αντικείμενα\nκαι επομένως το Helm αποτυγχάνει κατά την κλήση της βιβλιοθήκης. Δυστυχώς, το\nHelm δεν μπορεί να ανακτήσει από αυτή την κατάσταση και δεν είναι πλέον σε θέση\nνα διαχειριστεί ένα τέτοιο release. Δείτε [Ενημέρωση Εκδόσεων API ενός Release\nManifest](#updating-api-versions-of-a-release-manifest) για περισσότερες\nλεπτομέρειες σχετικά με τον τρόπο ανάκτησης από αυτό το σενάριο.\n\n## Ενημέρωση Εκδόσεων API ενός Release Manifest {#updating-api-versions-of-a-release-manifest}\n\nΤο manifest είναι μια ιδιότητα του αντικειμένου Helm release που αποθηκεύεται\nστο πεδίο data ενός Secret (προεπιλογή) ή ConfigMap στο cluster. Το πεδίο data\nπεριέχει ένα συμπιεσμένο (gzip) αντικείμενο που είναι κωδικοποιημένο σε base 64\n(υπάρχει μια επιπλέον κωδικοποίηση base 64 για τα Secret). Υπάρχει ένα\nSecret/ConfigMap ανά έκδοση/αναθεώρηση release στο namespace του release.\n\nΜπορείτε να χρησιμοποιήσετε το plugin\n[mapkubeapis](https://github.com/helm/helm-mapkubeapis) του Helm για να\nεκτελέσετε την ενημέρωση ενός release σε υποστηριζόμενα API. Ελέγξτε το readme\nγια περισσότερες λεπτομέρειες.\n\nΕναλλακτικά, μπορείτε να ακολουθήσετε αυτά τα χειροκίνητα βήματα για να\nεκτελέσετε μια ενημέρωση των εκδόσεων API ενός release manifest. Ανάλογα με τις\nρυθμίσεις σας, θα ακολουθήσετε τα βήματα για το Secret ή το ConfigMap backend.\n\n- Λήψη του ονόματος του Secret ή ConfigMap που σχετίζεται με το τελευταίο\n  εγκατεστημένο release:\n  - Secret backend: `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - ConfigMap backend: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- Λήψη λεπτομερειών του τελευταίου εγκατεστημένου release:\n  - Secret backend: `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - ConfigMap backend: `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- Δημιουργία αντιγράφου ασφαλείας του release σε περίπτωση που χρειαστεί\n  επαναφορά αν κάτι πάει στραβά:\n  - `cp release.yaml release.bak`\n  - Σε περίπτωση έκτακτης ανάγκης, επαναφορά: `kubectl apply -f release.bak -n\n    <release_namespace>`\n- Αποκωδικοποίηση του αντικειμένου release:\n  - Secret backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- Αλλαγή των εκδόσεων API των manifests. Μπορείτε να χρησιμοποιήσετε οποιοδήποτε\n  εργαλείο (π.χ. editor) για να κάνετε τις αλλαγές. Αυτό βρίσκεται στο πεδίο\n  `manifest` του αποκωδικοποιημένου αντικειμένου release σας\n  (`release.data.decoded`)\n- Κωδικοποίηση του αντικειμένου release:\n  - Secret backend: `cat release.data.decoded | gzip | base64 | base64`\n  - ConfigMap backend: `cat release.data.decoded | gzip | base64`\n- Αντικατάσταση της τιμής της ιδιότητας `data.release` στο αρχείο του\n  εγκατεστημένου release (`release.yaml`) με το νέο κωδικοποιημένο αντικείμενο\n  release\n- Εφαρμογή του αρχείου στο namespace: `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- Εκτέλεση `helm upgrade` με μια έκδοση του chart που έχει υποστηριζόμενες\n  εκδόσεις API του Kubernetes\n- Προσθήκη μιας περιγραφής στην αναβάθμιση, που να αναφέρει να μην γίνει\n  rollback σε έκδοση Helm πριν από αυτή την τρέχουσα έκδοση\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: Οδηγός Διανομών Kubernetes\ndescription: Πληροφορίες σχετικά με τη χρήση του Helm σε συγκεκριμένα περιβάλλοντα Kubernetes.\nsidebar_position: 10\n---\n\nΤο Helm λειτουργεί με οποιαδήποτε [συμβατή έκδοση του\nKubernetes](https://github.com/cncf/k8s-conformance) (είτε είναι\n[πιστοποιημένη](https://www.cncf.io/certification/software-conformance/) είτε όχι).\n\nΑυτό το έγγραφο περιέχει πληροφορίες σχετικά με τη χρήση του Helm σε συγκεκριμένα\nπεριβάλλοντα Kubernetes. Μπορείτε να συνεισφέρετε περισσότερες λεπτομέρειες για\nοποιαδήποτε διανομή (ταξινομημένες αλφαβητικά) αν θέλετε.\n\n\n## AKS {#aks}\n\nΤο Helm λειτουργεί με το [Azure Kubernetes\nService](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS {#dcos}\n\nΤο Helm έχει δοκιμαστεί και λειτουργεί στην πλατφόρμα Kubernetes του Mesosphere\nDC/OS 1.11, και δεν απαιτεί πρόσθετη διαμόρφωση.\n\n## EKS {#eks}\n\nΤο Helm λειτουργεί με το Amazon Elastic Kubernetes Service (Amazon EKS):\n[Χρήση του Helm με το Amazon\nEKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE {#gke}\n\nΗ πλατφόρμα GKE της Google λειτουργεί με το Helm και δεν απαιτεί πρόσθετη\nδιαμόρφωση.\n\n## `scripts/local-cluster` και Hyperkube {#scriptslocal-cluster-and-hyperkube}\n\nΤο Hyperkube ρυθμισμένο μέσω του `scripts/local-cluster.sh` λειτουργεί κανονικά.\nΓια το Hyperkube χωρίς script μπορεί να χρειαστεί χειροκίνητη διαμόρφωση.\n\n## IKS {#iks}\n\nΤο Helm λειτουργεί με το [IBM Cloud Kubernetes\nService](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker) {#kind-kubernetes-in-docker}\n\nΤο Helm δοκιμάζεται τακτικά στο [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne {#kubeone}\n\nΤο Helm λειτουργεί σε cluster που δημιουργούνται με το KubeOne χωρίς ιδιαίτερες\nπροϋποθέσεις.\n\n## Kubermatic {#kubermatic}\n\nΤο Helm λειτουργεί σε user cluster που δημιουργούνται από το Kubermatic χωρίς\nιδιαίτερες προϋποθέσεις. Καθώς τα seed cluster μπορούν να ρυθμιστούν με\nδιαφορετικούς τρόπους, η υποστήριξη του Helm εξαρτάται από τη διαμόρφωσή τους.\n\n## MicroK8s {#microk8s}\n\nΤο Helm μπορεί να ενεργοποιηθεί στο [MicroK8s](https://microk8s.io) με την εντολή:\n`microk8s.enable helm3`\n\n## Minikube {#minikube}\n\nΤο Helm έχει δοκιμαστεί και λειτουργεί με το\n[Minikube](https://github.com/kubernetes/minikube). Δεν απαιτεί πρόσθετη\nδιαμόρφωση.\n\n## Openshift {#openshift}\n\nΤο Helm λειτουργεί απευθείας στο OpenShift Online, OpenShift Dedicated,\nOpenShift Container Platform (έκδοση >= 3.6) ή OpenShift Origin (έκδοση >= 3.6).\nΓια περισσότερες πληροφορίες διαβάστε [αυτό το\nάρθρο](https://blog.openshift.com/getting-started-helm-openshift/).\n\n## Platform9 {#platform9}\n\nΤο Helm είναι προεγκατεστημένο στο [Platform9 Managed\nKubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes).\nΗ Platform9 παρέχει πρόσβαση σε όλα τα επίσημα Helm chart μέσω του App Catalog\nUI και του native Kubernetes CLI. Μπορείτε επίσης να προσθέσετε χειροκίνητα\nπρόσθετα repository. Περισσότερες λεπτομέρειες είναι διαθέσιμες σε αυτό το\n[άρθρο για το Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes).\n\n## Ubuntu με `kubeadm` {#ubuntu-with-kubeadm}\n\nΤο Kubernetes που έχει ρυθμιστεί με το `kubeadm` λειτουργεί στις ακόλουθες\nδιανομές Linux:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nΟρισμένες εκδόσεις του Helm (v2.0.0-beta2) απαιτούν να εκτελέσετε `export\nKUBECONFIG=/etc/kubernetes/admin.conf` ή να δημιουργήσετε ένα `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid {#vmware-tanzu-kubernetes-grid}\n\nΤο Helm λειτουργεί στο VMware Tanzu Kubernetes Grid, TKG, χωρίς να χρειάζονται\nαλλαγές στη διαμόρφωση. Το Tanzu CLI μπορεί να διαχειριστεί την εγκατάσταση\nπακέτων για το [helm-controller](https://fluxcd.io/flux/components/helm/),\nεπιτρέποντας τη δηλωτική διαχείριση των Helm chart release. Περισσότερες\nλεπτομέρειες είναι διαθέσιμες στην τεκμηρίωση του TKG για τα\n[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).\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: Library Charts\ndescription: Εξηγεί τα library charts και παραδείγματα χρήσης τους\nsidebar_position: 4\n---\n\nΤα library charts είναι ένας τύπος [Helm chart](/topics/charts.md)\nπου ορίζει βασικά στοιχεία ή ορισμούς chart, τα οποία μπορούν να χρησιμοποιηθούν από Helm\ntemplates σε άλλα charts. Αυτό επιτρέπει τον διαμοιρασμό αποσπασμάτων κώδικα\nπου επαναχρησιμοποιούνται σε διαφορετικά charts, αποφεύγοντας την επανάληψη και διατηρώντας τα charts\n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nΤο library chart εισήχθη στο Helm 3 για να αναγνωρίσει επίσημα τα κοινά ή\nβοηθητικά charts που χρησιμοποιούνταν από συντηρητές charts από το Helm 2. \nΩς τύπος chart, παρέχει:\n- Σαφή διάκριση μεταξύ κοινών και application charts\n- Λογική που αποτρέπει την εγκατάσταση ενός κοινού chart\n- Καμία απόδοση templates σε ένα κοινό chart που μπορεί να περιέχει release\n  artifacts\n- Δυνατότητα στα εξαρτώμενα charts να χρησιμοποιούν το context του chart που τα εισάγει\n\nΈνας συντηρητής chart μπορεί να ορίσει ένα κοινό chart ως library chart και να είναι\nβέβαιος ότι το Helm θα το χειριστεί με τυπικό και συνεπή τρόπο. Επιπλέον,\nοι ορισμοί σε ένα application chart μπορούν να διαμοιραστούν αλλάζοντας\nτον τύπο του chart.\n\n## Δημιουργία Απλού Library Chart {#create-a-simple-library-chart}\n\nΌπως αναφέρθηκε προηγουμένως, ένα library chart είναι ένας τύπος [Helm chart](/topics/charts.md). Μπορείτε λοιπόν να ξεκινήσετε δημιουργώντας ένα\nαρχικό chart:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nΑφαιρέστε πρώτα όλα τα αρχεία στον κατάλογο `templates`, καθώς θα δημιουργήσουμε\nτους δικούς μας ορισμούς templates σε αυτό το παράδειγμα.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nΤο αρχείο values δεν θα χρειαστεί επίσης.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nΠριν δημιουργήσουμε κοινό κώδικα, ας κάνουμε μια γρήγορη ανασκόπηση ορισμένων\nσχετικών εννοιών του Helm. Ένα [named template](/chart_template_guide/named_templates.md) (μερικές φορές ονομάζεται partial\nή subtemplate) είναι απλά ένα template που ορίζεται μέσα σε ένα αρχείο με συγκεκριμένο\nόνομα. Στον κατάλογο `templates/`, οποιοδήποτε αρχείο ξεκινά με κάτω παύλα (_)\nδεν αναμένεται να παράγει αρχείο manifest του Kubernetes. Κατά σύμβαση λοιπόν, τα βοηθητικά\ntemplates και τα partials τοποθετούνται σε αρχεία `_*.tpl` ή `_*.yaml`.\n\nΣε αυτό το παράδειγμα, θα δημιουργήσουμε ένα κοινό ConfigMap με κενό\nπόρο ConfigMap. Ο ορισμός του κοινού ConfigMap γίνεται στο αρχείο\n`mylibchart/templates/_configmap.yaml` ως εξής:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nΗ δομή του ConfigMap ορίζεται στο named template `mylibchart.configmap.tpl`.\nΠρόκειται για ένα απλό ConfigMap με κενό πόρο `data`. Στο ίδιο αρχείο υπάρχει\nένα άλλο named template με όνομα `mylibchart.configmap`. Αυτό το named template\nπεριλαμβάνει το `mylibchart.util.merge` που δέχεται 2 named\ntemplates ως ορίσματα: το template που καλεί το `mylibchart.configmap` και\nτο `mylibchart.configmap.tpl`.\n\nΗ βοηθητική συνάρτηση `mylibchart.util.merge` είναι ένα named template στο\n`mylibchart/templates/_util.yaml`. Πρόκειται για ένα χρήσιμο εργαλείο από το [The Common Helm\nHelper Chart](#the-common-helm-helper-chart), καθώς συγχωνεύει τα 2 templates\nκαι παρακάμπτει τα κοινά μέρη τους:\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nΑυτό είναι σημαντικό όταν ένα chart χρειάζεται να χρησιμοποιήσει κοινό κώδικα και να τον\nπροσαρμόσει στη δική του διαμόρφωση.\n\nΤέλος, αλλάξτε τον τύπο του chart σε `library`. Αυτό απαιτεί επεξεργασία\nτου `mylibchart/Chart.yaml` ως εξής:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart. {#a-chart-can-be-either-an-application-or-a-library-chart}\n# # 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}\n# to be deployed. {#to-be-deployed}\n# # 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}\n# 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}\n# 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}\n# type: application {#type-application}\ntype: library\n\n# 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}\n# to the chart and its templates, including the app version. {#to-the-chart-and-its-templates-including-the-app-version}\nversion: 0.1.0\n\n# 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}\n# 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}\nappVersion: \"1.16.0\"\n```\n\nΤο library chart είναι τώρα έτοιμο για διαμοιρασμό και ο ορισμός του ConfigMap μπορεί να\nεπαναχρησιμοποιηθεί.\n\nΠριν προχωρήσετε, ελέγξτε αν το Helm αναγνωρίζει το chart ως library\nchart:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Χρήση του Απλού Library Chart {#use-the-simple-library-chart}\n\nΤώρα μπορούμε να χρησιμοποιήσουμε το library chart. Δημιουργήστε ξανά ένα αρχικό chart:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nΚαθαρίστε τα αρχεία template ξανά, καθώς θέλουμε να δημιουργήσουμε μόνο ένα ConfigMap:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nΑν θέλαμε να δημιουργήσουμε ένα απλό ConfigMap σε ένα Helm template, θα μπορούσε να μοιάζει\nμε το ακόλουθο:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nΩστόσο, θα επαναχρησιμοποιήσουμε τον κοινό κώδικα που έχει ήδη δημιουργηθεί στο `mylibchart`.\nΤο ConfigMap μπορεί να δημιουργηθεί στο αρχείο `mychart/templates/configmap.yaml` ως\nεξής:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nΜε αυτόν τον τρόπο απλοποιείται η δουλειά, κληρονομώντας τον κοινό\nορισμό ConfigMap που προσθέτει τυπικές ιδιότητες για το ConfigMap. Στο\ntemplate προσθέτουμε τη διαμόρφωση, σε αυτή την περίπτωση το κλειδί δεδομένων `myvalue` και την\nτιμή του. Η διαμόρφωση παρακάμπτει τον κενό πόρο του κοινού ConfigMap.\nΑυτό είναι εφικτό χάρη στη βοηθητική συνάρτηση `mylibchart.util.merge` που\nαναφέραμε στην προηγούμενη ενότητα.\n\nΓια να χρησιμοποιήσουμε τον κοινό κώδικα, πρέπει να προσθέσουμε το `mylibchart` ως εξάρτηση.\nΠροσθέστε τα ακόλουθα στο τέλος του αρχείου `mychart/Chart.yaml`:\n\n```yaml\n# My common code in my library chart {#my-common-code-in-my-library-chart}\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nΜε αυτόν τον τρόπο το library chart συμπεριλαμβάνεται ως δυναμική εξάρτηση από το σύστημα αρχείων,\nστην ίδια γονική διαδρομή με το application chart. Επειδή συμπεριλαμβάνουμε\nτο library chart ως δυναμική εξάρτηση, πρέπει να εκτελέσουμε `helm dependency\nupdate`. Αυτό θα αντιγράψει το library chart στον κατάλογο `charts/`.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nΕίμαστε τώρα έτοιμοι να κάνουμε deploy το chart. Πριν την εγκατάσταση, ελέγξτε\nπρώτα το rendered template.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml}\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nΑυτό μοιάζει με το ConfigMap που θέλουμε, με παράκαμψη δεδομένων `myvalue: Hello\nWorld`. Εγκαταστήστε το:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nΜπορούμε να ανακτήσουμε το release και να δούμε ότι το πραγματικό template φορτώθηκε.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## Πλεονεκτήματα Library Chart {#library-chart-benefits}\n\nΕπειδή τα library charts δεν μπορούν να λειτουργήσουν ως αυτόνομα charts, μπορούν να αξιοποιήσουν την ακόλουθη λειτουργικότητα:\n- Το αντικείμενο `.Files` αναφέρεται στις διαδρομές αρχείων του γονικού chart, αντί της τοπικής διαδρομής του library chart\n- Το αντικείμενο `.Values` είναι το ίδιο με αυτό του γονικού chart, σε αντίθεση με τα application [subcharts](/chart_template_guide/subcharts_and_globals.md) που λαμβάνουν την ενότητα values που έχει διαμορφωθεί κάτω από την επικεφαλίδα τους στο γονικό\n\n\n## The Common Helm Helper Chart {#the-common-helm-helper-chart}\n\n```markdown\nNote: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived.\n```\n\nΑυτό το [chart](https://github.com/helm/charts/tree/master/incubator/common) ήταν\nτο αρχικό μοτίβο για τα common charts. Παρέχει εργαλεία που αντικατοπτρίζουν τις βέλτιστες\nπρακτικές ανάπτυξης Kubernetes chart. Το καλύτερο απ' όλα είναι ότι μπορείτε να το χρησιμοποιήσετε αμέσως\nκατά την ανάπτυξη των δικών σας charts, αποκτώντας έτοιμο κοινόχρηστο κώδικα.\n\nΑκολουθεί ένας γρήγορος τρόπος χρήσης. Για περισσότερες λεπτομέρειες, δείτε το\n[README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nΔημιουργήστε ένα αρχικό chart ξανά:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nΑς χρησιμοποιήσουμε τον κοινό κώδικα από το helper chart. Πρώτα, επεξεργαστείτε το deployment\n`demo/templates/deployment.yaml` ως εξής:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g. {#define-overrides-for-your-deployment-resource-here-eg}\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nΣτη συνέχεια το αρχείο service, `demo/templates/service.yaml` ως εξής:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g. {#define-overrides-for-your-service-resource-here-eg}\n# metadata: {#metadata}\n# labels: {#labels}\n# custom: label {#custom-label}\n# spec: {#spec}\n# ports: {#ports}\n# - port: 8080 {#port-8080}\n{{- end -}}\n```\n\nΑυτά τα templates δείχνουν πώς η κληρονομικότητα του κοινού κώδικα από το helper chart\nαπλοποιεί τον κώδικα στη διαμόρφωση ή την προσαρμογή των\nπόρων.\n\nΓια να χρησιμοποιήσουμε τον κοινό κώδικα, πρέπει να προσθέσουμε το `common` ως εξάρτηση. Προσθέστε\nτα ακόλουθα στο τέλος του αρχείου `demo/Chart.yaml`:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nΣημείωση: Θα πρέπει να προσθέσετε το `incubator` repo στη λίστα αποθετηρίων Helm\n(`helm repo add`).\n\nΕπειδή συμπεριλαμβάνουμε το chart ως δυναμική εξάρτηση, πρέπει να εκτελέσουμε `helm\ndependency update`. Αυτό θα αντιγράψει το helper chart στον κατάλογο `charts/`.\n\nΕπειδή το helper chart χρησιμοποιεί ορισμένες δομές του Helm 2, θα πρέπει να προσθέσετε τα\nακόλουθα στο `demo/values.yaml` για να ενεργοποιηθεί η φόρτωση του `nginx` image, καθώς αυτό\nενημερώθηκε στο αρχικό chart του Helm 3:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nΜπορείτε να ελέγξετε ότι τα chart templates είναι σωστά πριν το deploy χρησιμοποιώντας τις εντολές `helm lint` και `helm template`.\n\nΑν όλα είναι εντάξει, προχωρήστε στο deploy με `helm install`!\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Διαχείριση Δικαιωμάτων για SQL Storage Backend\ndescription: Μάθετε πώς να ρυθμίζετε δικαιώματα όταν χρησιμοποιείτε SQL storage backend.\n---\n\nΑυτός ο οδηγός παρέχει καθοδήγηση για τη ρύθμιση και διαχείριση δικαιωμάτων\nόταν χρησιμοποιείτε το SQL storage backend.\n\n## Εισαγωγή {#introduction}\n\nΓια τη διαχείριση δικαιωμάτων, το Helm αξιοποιεί τη λειτουργία RBAC του Kubernetes.\nΌταν χρησιμοποιείτε το SQL storage backend, οι ρόλοι του Kubernetes δεν μπορούν να\nκαθορίσουν αν ένας χρήστης έχει πρόσβαση σε έναν συγκεκριμένο πόρο. Αυτός ο\nοδηγός εξηγεί πώς να δημιουργήσετε και να διαχειριστείτε αυτά τα δικαιώματα.\n\n## Αρχικοποίηση {#initialization}\n\nΤην πρώτη φορά που το Helm CLI θα συνδεθεί στη βάση δεδομένων σας, ο client θα\nελέγξει αν έχει γίνει προηγούμενη αρχικοποίηση. Αν όχι, θα πραγματοποιήσει\nαυτόματα τις απαραίτητες ρυθμίσεις. Αυτή η αρχικοποίηση απαιτεί δικαιώματα\nδιαχειριστή στο public schema, ή τουλάχιστον τη δυνατότητα να:\n\n* δημιουργήσετε έναν πίνακα\n* εκχωρήσετε δικαιώματα στο public schema\n\nΜετά την εκτέλεση της μετάβασης στη βάση δεδομένων σας, όλοι οι άλλοι ρόλοι\nμπορούν να χρησιμοποιήσουν τον client.\n\n## Εκχώρηση δικαιωμάτων σε μη διαχειριστή στην PostgreSQL {#grant-privileges-to-a-non-admin-user-in-postgresql}\n\nΓια τη διαχείριση δικαιωμάτων, ο driver του SQL backend αξιοποιεί τη λειτουργία\n[RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security\nLevel) της PostgreSQL. Το RLS επιτρέπει σε όλους τους χρήστες να διαβάζουν και\nνα γράφουν στον ίδιο πίνακα, χωρίς να μπορούν να τροποποιούν τις ίδιες γραμμές\nεάν δεν τους έχει δοθεί ρητά η άδεια. Από προεπιλογή, κάθε ρόλος στον οποίο δεν\nέχουν εκχωρηθεί ρητά τα κατάλληλα δικαιώματα θα λαμβάνει πάντα κενή λίστα όταν\nεκτελεί `helm list` και δεν θα μπορεί να ανακτήσει ή να τροποποιήσει κανέναν\nπόρο στο cluster.\n\nΑς δούμε πώς να εκχωρήσετε πρόσβαση σε έναν ρόλο για συγκεκριμένα namespaces:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nΑυτή η εντολή εκχωρεί δικαιώματα ανάγνωσης και εγγραφής όλων των πόρων που\nπληρούν τη συνθήκη `namespace = 'default'` στον ρόλο `role`. Μετά τη δημιουργία\nαυτής της πολιτικής, ο χρήστης που συνδέεται στη βάση δεδομένων για τον ρόλο\n`role` θα μπορεί να βλέπει όλα τα releases στο namespace `default` όταν εκτελεί\n`helm list`, καθώς και να τα τροποποιεί και να τα διαγράφει.\n\nΤα δικαιώματα μπορούν να διαχειριστούν με λεπτομέρεια χρησιμοποιώντας το RLS.\nΜπορεί να σας ενδιαφέρει να περιορίσετε την πρόσβαση βάσει των διαφορετικών\nστηλών του πίνακα:\n\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Ο Οδηγός Plugins του Helm\ndescription: Εισάγει τον τρόπο χρήσης και δημιουργίας plugins για την επέκταση της λειτουργικότητας του Helm.\nsidebar_position: 12\n---\n\nΈνα plugin του Helm είναι ένα εργαλείο που είναι προσβάσιμο μέσω του CLI του `helm`, αλλά δεν αποτελεί μέρος του ενσωματωμένου κώδικα του Helm.\n\nΥπάρχοντα plugins μπορείτε να βρείτε στην ενότητα [σχετικά](/community/related#helm-plugins) ή αναζητώντας στο [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).\n\nΑυτός ο οδηγός εξηγεί πώς να χρησιμοποιήσετε και να δημιουργήσετε plugins.\n\n## Επισκόπηση {#an-overview}\n\nΤα plugins του Helm είναι πρόσθετα εργαλεία που ενσωματώνονται απρόσκοπτα με το Helm. Παρέχουν έναν τρόπο επέκτασης του βασικού συνόλου λειτουργιών του Helm, χωρίς να απαιτείται κάθε νέα λειτουργία να είναι γραμμένη σε Go και να προστεθεί στο βασικό εργαλείο.\n\nΤα plugins του Helm έχουν τα ακόλουθα χαρακτηριστικά:\n\n- Μπορούν να προστεθούν και να αφαιρεθούν από μια εγκατάσταση Helm χωρίς να επηρεάζεται το βασικό εργαλείο Helm.\n- Μπορούν να γραφτούν σε οποιαδήποτε γλώσσα προγραμματισμού.\n- Ενσωματώνονται με το Helm και εμφανίζονται στο `helm help` και σε άλλα σημεία.\n\nΤα plugins του Helm βρίσκονται στο `$HELM_PLUGINS`. Μπορείτε να βρείτε την τρέχουσα τιμή αυτού, συμπεριλαμβανομένης της προεπιλεγμένης τιμής όταν δεν έχει οριστεί στο περιβάλλον, χρησιμοποιώντας την εντολή `helm env`.\n\nΤο μοντέλο plugins του Helm βασίζεται εν μέρει στο μοντέλο plugins του Git. Για αυτό τον λόγο, μπορεί μερικές φορές να ακούσετε το `helm` να αναφέρεται ως το επίπεδο _porcelain_, με τα plugins να είναι το _plumbing_. Αυτός είναι ένας συντομευμένος τρόπος για να υποδηλωθεί ότι το Helm παρέχει την εμπειρία χρήστη και τη λογική επεξεργασίας υψηλού επιπέδου, ενώ τα plugins εκτελούν τη \"λεπτομερή εργασία\" για την πραγματοποίηση μιας επιθυμητής ενέργειας.\n\n## Εγκατάσταση ενός Plugin {#installing-a-plugin}\n\nΤα plugins εγκαθίστανται χρησιμοποιώντας την εντολή `$ helm plugin install <path|url>`. Μπορείτε να περάσετε μια διαδρομή προς ένα plugin στο τοπικό σας σύστημα αρχείων ή ένα url ενός απομακρυσμένου VCS αποθετηρίου. Η εντολή `helm plugin install` κλωνοποιεί ή αντιγράφει το plugin από τη διαδρομή/url που δίνεται στο `$HELM_PLUGINS`. Αν εγκαθιστάτε από VCS, μπορείτε να καθορίσετε την έκδοση με το όρισμα `--version`.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nΑν έχετε μια διανομή plugin σε μορφή tar, απλώς αποσυμπιέστε το plugin στον κατάλογο `$HELM_PLUGINS`. Μπορείτε επίσης να εγκαταστήσετε plugins σε μορφή tarball απευθείας από url εκτελώντας `helm plugin install https://domain/path/to/plugin.tar.gz`\n\n## Η Δομή Αρχείων του Plugin {#the-plugin-file-structure}\n\nΑπό πολλές απόψεις, ένα plugin είναι παρόμοιο με ένα chart. Κάθε plugin έχει έναν κατάλογο ανώτατου επιπέδου που περιέχει ένα αρχείο `plugin.yaml`. Μπορεί να υπάρχουν πρόσθετα αρχεία, αλλά μόνο το αρχείο `plugin.yaml` είναι απαραίτητο.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## Το Αρχείο plugin.yaml {#the-pluginyaml-file}\n\nΤο αρχείο plugin.yaml είναι απαραίτητο για ένα plugin. Περιέχει τα ακόλουθα πεδία:\n\n```yaml\nname: The name of the plugin (REQUIRED)\nversion: A SemVer 2 version (REQUIRED)\nusage: Single line usage text shown in help\ndescription: Long description shown in places like helm help\nignoreFlags: Ignore flags passed in from Helm\nplatformCommand: # Configure command to run based on the platform\n  - os: OS match, can be empty or omitted to match all OS'\n    arch: Architecture match, can be empty or omitted to match all architectures\n    command: Plugin command to execute\n    args: Plugin command arguments\ncommand: (DEPRECATED) Plugin command, use platformCommand instead\nplatformHooks: # Configure plugin lifecycle hooks based on the platform\n  install: # Install lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin install command to execute\n      args: Plugin install command arguments\n  update: # Update lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin update command to execute\n      args: Plugin update command arguments\n  delete: # Delete lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin delete command to execute\n      args: Plugin delete command arguments\nhooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead\n  install: Command to install plugin\n  update: Command to update plugin\n  delete: Command to delete plugin\ndownloaders: # Configure downloaders capability\n  - command: Command to invoke\n    protocols:\n      - Protocol schema supported\n```\n\n### Το Πεδίο `name` {#the-name-field}\n\nΤο `name` είναι το όνομα του plugin. Όταν το Helm εκτελεί αυτό το plugin, αυτό είναι το όνομα που θα χρησιμοποιήσει (π.χ. η εντολή `helm NAME` θα καλέσει αυτό το plugin).\n\n_Το `name` πρέπει να ταιριάζει με το όνομα του καταλόγου._ Στο παράδειγμά μας παραπάνω, αυτό σημαίνει ότι το plugin με `name: last` πρέπει να περιέχεται σε έναν κατάλογο με όνομα `last`.\n\nΠεριορισμοί στο `name`:\n\n- Το `name` δεν μπορεί να αντιγράφει μία από τις υπάρχουσες εντολές ανώτατου επιπέδου του `helm`.\n- Το `name` πρέπει να περιορίζεται στους χαρακτήρες ASCII a-z, A-Z, 0-9, `_` και `-`.\n\n### Το Πεδίο `version` {#the-version-field}\n\nΤο `version` είναι η έκδοση SemVer 2 του plugin. Τα πεδία `usage` και `description` χρησιμοποιούνται και τα δύο για τη δημιουργία του κειμένου βοήθειας μιας εντολής.\n\n### Το Πεδίο `ignoreFlags` {#the-ignoreflags-field}\n\nΟ διακόπτης `ignoreFlags` λέει στο Helm να _μην_ περάσει τις σημαίες στο plugin. Επομένως, αν ένα plugin κληθεί με `helm myplugin --foo` και `ignoreFlags: true`, τότε η σημαία `--foo` απορρίπτεται σιωπηλά.\n\n### Το Πεδίο `platformCommand` {#the-platformcommand-field}\n\nΤο `platformCommand` ρυθμίζει την εντολή που θα εκτελέσει το plugin όταν κληθεί. Δεν μπορείτε να ορίσετε ταυτόχρονα και `platformCommand` και `command` καθώς αυτό θα οδηγήσει σε σφάλμα. Οι ακόλουθοι κανόνες ισχύουν για τον καθορισμό της εντολής που θα χρησιμοποιηθεί:\n\n- Αν υπάρχει το `platformCommand`, θα χρησιμοποιηθεί.\n  - Αν τόσο το `os` όσο και το `arch` ταιριάζουν με την τρέχουσα πλατφόρμα, η αναζήτηση θα σταματήσει και η εντολή θα χρησιμοποιηθεί.\n  - Αν το `os` ταιριάζει και το `arch` είναι κενό, η εντολή θα χρησιμοποιηθεί.\n  - Αν και το `os` και το `arch` είναι κενά, η εντολή θα χρησιμοποιηθεί.\n  - Αν δεν υπάρχει αντιστοιχία, το Helm θα τερματίσει με σφάλμα.\n- Αν το `platformCommand` δεν υπάρχει και υπάρχει η καταργημένη εντολή `command`, θα χρησιμοποιηθεί αυτή.\n  - Αν η εντολή είναι κενή, το Helm θα τερματίσει με σφάλμα.\n\n### Το Πεδίο `platformHooks` {#the-platformhooks-field}\n\nΤο `platformHooks` ρυθμίζει τις εντολές που θα εκτελέσει το plugin για συμβάντα κύκλου ζωής. Δεν μπορείτε να ορίσετε ταυτόχρονα και `platformHooks` και `hooks` καθώς αυτό θα οδηγήσει σε σφάλμα. Οι ακόλουθοι κανόνες ισχύουν για τον καθορισμό της εντολής hook που θα χρησιμοποιηθεί:\n\n- Αν υπάρχει το `platformHooks`, θα χρησιμοποιηθεί και οι εντολές για το συμβάν κύκλου ζωής θα επεξεργαστούν.\n  - Αν τόσο το `os` όσο και το `arch` ταιριάζουν με την τρέχουσα πλατφόρμα, η αναζήτηση θα σταματήσει και η εντολή θα χρησιμοποιηθεί.\n  - Αν το `os` ταιριάζει και το `arch` είναι κενό, η εντολή θα χρησιμοποιηθεί.\n  - Αν και το `os` και το `arch` είναι κενά, η εντολή θα χρησιμοποιηθεί.\n  - Αν δεν υπάρχει αντιστοιχία, το Helm θα παραλείψει το συμβάν.\n- Αν το `platformHooks` δεν υπάρχει και υπάρχει το καταργημένο `hooks`, θα χρησιμοποιηθεί η εντολή για το συμβάν κύκλου ζωής.\n  - Αν η εντολή είναι κενή, το Helm θα παραλείψει το συμβάν.\n\n## Δημιουργία Plugin {#building-a-plugin}\n\nΑκολουθεί το αρχείο YAML του plugin για ένα απλό plugin που βοηθά να ληφθεί το όνομα της τελευταίας έκδοσης:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nΤα plugins μπορεί να απαιτούν πρόσθετα scripts και εκτελέσιμα. Τα scripts μπορούν να συμπεριληφθούν στον κατάλογο του plugin και τα εκτελέσιμα μπορούν να ληφθούν μέσω ενός hook. Ακολουθεί ένα παράδειγμα plugin:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nΟι μεταβλητές περιβάλλοντος αντικαθίστανται πριν από την εκτέλεση του plugin. Το παραπάνω μοτίβο δείχνει τον προτιμώμενο τρόπο για να υποδειχθεί πού βρίσκεται το πρόγραμμα του plugin.\n\n### Εντολές Plugin {#plugin-commands}\n\nΥπάρχουν ορισμένες στρατηγικές για την εργασία με εντολές plugin:\n\n- Αν ένα plugin περιλαμβάνει ένα εκτελέσιμο, το εκτελέσιμο για το `platformCommand:` πρέπει να είναι πακεταρισμένο στον κατάλογο του plugin ή να εγκαθίσταται μέσω ενός hook.\n- Η γραμμή `platformCommand:` ή `command:` θα έχει όλες τις μεταβλητές περιβάλλοντος επεκταμένες πριν από την εκτέλεση. Η μεταβλητή `$HELM_PLUGIN_DIR` θα δείχνει στον κατάλογο του plugin.\n- Η ίδια η εντολή δεν εκτελείται σε shell. Επομένως, δεν μπορείτε να γράψετε ένα shell script σε μία γραμμή.\n- Το Helm εισάγει πολλές ρυθμίσεις σε μεταβλητές περιβάλλοντος. Εξετάστε το περιβάλλον για να δείτε ποιες πληροφορίες είναι διαθέσιμες.\n- Το Helm δεν κάνει υποθέσεις για τη γλώσσα του plugin. Μπορείτε να το γράψετε σε ό,τι προτιμάτε.\n- Οι εντολές είναι υπεύθυνες για την υλοποίηση συγκεκριμένου κειμένου βοήθειας για τις σημαίες `-h` και `--help`. Το Helm θα χρησιμοποιήσει τα πεδία `usage` και `description` για τις εντολές `helm help` και `helm help myplugin`, αλλά δεν θα χειριστεί την εντολή `helm myplugin --help`.\n\n### Δοκιμή ενός Τοπικού Plugin {#testing-a-local-plugin}\n\nΑρχικά πρέπει να βρείτε τη διαδρομή `HELM_PLUGINS`. Για να το κάνετε αυτό, εκτελέστε την ακόλουθη εντολή:\n\n``` bash\nhelm env\n```\n\nΑλλάξτε τον τρέχοντα κατάλογο στον κατάλογο που έχει οριστεί στο `HELM_PLUGINS`.\n\nΤώρα μπορείτε να προσθέσετε έναν συμβολικό σύνδεσμο προς την έξοδο build του plugin σας. Σε αυτό το παράδειγμα το κάνουμε για το `mapkubeapis`.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Plugins Λήψης {#downloader-plugins}\n\nΑπό προεπιλογή, το Helm μπορεί να κατεβάσει Charts χρησιμοποιώντας HTTP/S. Από το Helm 2.4.0, τα plugins μπορούν να έχουν μια ειδική δυνατότητα λήψης Charts από αυθαίρετες πηγές.\n\nΤα plugins πρέπει να δηλώσουν αυτή την ειδική δυνατότητα στο αρχείο `plugin.yaml` (στο ανώτατο επίπεδο):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nΑν ένα τέτοιο plugin είναι εγκατεστημένο, το Helm μπορεί να αλληλεπιδράσει με το αποθετήριο χρησιμοποιώντας το καθορισμένο σχήμα πρωτοκόλλου καλώντας την εντολή `command`. Το ειδικό αποθετήριο πρέπει να προστεθεί παρόμοια με τα κανονικά: `helm repo add favorite myprotocol://example.com/` Οι κανόνες για τα ειδικά αποθετήρια είναι ίδιοι με τα κανονικά: Το Helm πρέπει να μπορεί να κατεβάσει το αρχείο `index.yaml` για να ανακαλύψει και να αποθηκεύσει προσωρινά τη λίστα των διαθέσιμων Charts.\n\nΗ καθορισμένη εντολή θα κληθεί με το ακόλουθο σχήμα: `command certFile keyFile caFile full-URL`. Τα διαπιστευτήρια SSL προέρχονται από τον ορισμό του αποθετηρίου, που αποθηκεύεται στο `$HELM_REPOSITORY_CONFIG` (δηλαδή `$HELM_CONFIG_HOME/repositories.yaml`). Ένα plugin λήψης αναμένεται να εκτυπώσει το ακατέργαστο περιεχόμενο στο stdout και να αναφέρει σφάλματα στο stderr.\n\nΗ εντολή λήψης υποστηρίζει επίσης υποεντολές ή ορίσματα, επιτρέποντάς σας να καθορίσετε για παράδειγμα `bin/mydownloader subcommand -d` στο `plugin.yaml`. Αυτό είναι χρήσιμο αν θέλετε να χρησιμοποιήσετε το ίδιο εκτελέσιμο τόσο για την κύρια εντολή του plugin όσο και για την εντολή λήψης, αλλά με διαφορετική υποεντολή για κάθε μία.\n\n## Μεταβλητές Περιβάλλοντος {#environment-variables}\n\nΌταν το Helm εκτελεί ένα plugin, περνάει το εξωτερικό περιβάλλον στο plugin, και επίσης εισάγει ορισμένες πρόσθετες μεταβλητές περιβάλλοντος.\n\nΜεταβλητές όπως η `KUBECONFIG` ορίζονται για το plugin αν έχουν οριστεί στο εξωτερικό περιβάλλον.\n\nΟι ακόλουθες μεταβλητές είναι εγγυημένο ότι θα οριστούν:\n\n- `HELM_PLUGINS`: Η διαδρομή προς τον κατάλογο plugins.\n- `HELM_PLUGIN_NAME`: Το όνομα του plugin, όπως κλήθηκε από το `helm`. Έτσι η εντολή `helm myplug` θα έχει το σύντομο όνομα `myplug`.\n- `HELM_PLUGIN_DIR`: Ο κατάλογος που περιέχει το plugin.\n- `HELM_BIN`: Η διαδρομή προς την εντολή `helm` (όπως εκτελέστηκε από τον χρήστη).\n- `HELM_DEBUG`: Υποδεικνύει αν η σημαία debug ήταν ενεργοποιημένη από το helm.\n- `HELM_REGISTRY_CONFIG`: Η τοποθεσία για τη ρύθμιση του registry (αν χρησιμοποιείται). Σημειώστε ότι η χρήση του Helm με registries είναι μια πειραματική λειτουργία.\n- `HELM_REPOSITORY_CACHE`: Η διαδρομή προς τα αρχεία προσωρινής μνήμης του αποθετηρίου.\n- `HELM_REPOSITORY_CONFIG`: Η διαδρομή προς το αρχείο ρύθμισης του αποθετηρίου.\n- `HELM_NAMESPACE`: Το namespace που δόθηκε στην εντολή `helm` (συνήθως χρησιμοποιώντας τη σημαία `-n`).\n- `HELM_KUBECONTEXT`: Το όνομα του Kubernetes config context που δόθηκε στην εντολή `helm`.\n\nΕπιπλέον, αν ένα αρχείο ρύθμισης Kubernetes καθορίστηκε ρητά, θα οριστεί ως μεταβλητή `KUBECONFIG`.\n\n## Σημείωση για την Ανάλυση Σημαιών {#a-note-on-flag-parsing}\n\nΌταν εκτελείται ένα plugin, το Helm αναλύει τις καθολικές σημαίες για δική του χρήση. Καμία από αυτές τις σημαίες δεν περνάει στο plugin.\n- `--burst-limit`: Μετατρέπεται σε `$HELM_BURST_LIMIT`\n- `--debug`: Αν καθοριστεί, η `$HELM_DEBUG` ορίζεται σε `1`\n- `--kube-apiserver`: Μετατρέπεται σε `$HELM_KUBEAPISERVER`\n- `--kube-as-group`: Μετατρέπονται σε `$HELM_KUBEASGROUPS`\n- `--kube-as-user`: Μετατρέπεται σε `$HELM_KUBEASUSER`\n- `--kube-ca-file`: Μετατρέπεται σε `$HELM_KUBECAFILE`\n- `--kube-context`: Μετατρέπεται σε `$HELM_KUBECONTEXT`\n- `--kube-insecure-skip-tls-verify`: Μετατρέπεται σε `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`\n- `--kube-tls-server-name`: Μετατρέπεται σε `$HELM_KUBETLS_SERVER_NAME`\n- `--kube-token`: Μετατρέπεται σε `$HELM_KUBETOKEN`\n- `--kubeconfig`: Μετατρέπεται σε `$KUBECONFIG`\n- `--namespace` και `-n`: Μετατρέπεται σε `$HELM_NAMESPACE`\n- `--qps`: Μετατρέπεται σε `$HELM_QPS`\n- `--registry-config`: Μετατρέπεται σε `$HELM_REGISTRY_CONFIG`\n- `--repository-cache`: Μετατρέπεται σε `$HELM_REPOSITORY_CACHE`\n- `--repository-config`: Μετατρέπεται σε `$HELM_REPOSITORY_CONFIG`\n\nΤα plugins _πρέπει_ να εμφανίζουν κείμενο βοήθειας και στη συνέχεια να τερματίζουν για τις σημαίες `-h` και `--help`. Σε όλες τις άλλες περιπτώσεις, τα plugins μπορούν να χρησιμοποιούν σημαίες όπως κρίνουν κατάλληλο.\n\n## Παροχή Αυτόματης Συμπλήρωσης Shell {#providing-shell-auto-completion}\n\nΑπό το Helm 3.2, ένα plugin μπορεί προαιρετικά να παρέχει υποστήριξη για αυτόματη συμπλήρωση shell ως μέρος του υπάρχοντος μηχανισμού αυτόματης συμπλήρωσης του Helm.\n\n### Στατική Αυτόματη Συμπλήρωση {#static-auto-completion}\n\nΑν ένα plugin παρέχει τις δικές του σημαίες ή/και υποεντολές, μπορεί να ενημερώσει το Helm γι' αυτές έχοντας ένα αρχείο `completion.yaml` στον ριζικό κατάλογο του plugin. Το αρχείο `completion.yaml` έχει την ακόλουθη μορφή:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nΣημειώσεις:\n\n1. Όλες οι ενότητες είναι προαιρετικές αλλά πρέπει να παρέχονται αν ισχύουν.\n1. Οι σημαίες δεν πρέπει να περιλαμβάνουν το πρόθεμα `-` ή `--`.\n1. Τόσο οι σύντομες όσο και οι μακριές σημαίες μπορούν και πρέπει να καθοριστούν. Μια σύντομη σημαία δεν χρειάζεται να συσχετιστεί με την αντίστοιχη μακριά μορφή της, αλλά και οι δύο μορφές πρέπει να αναφέρονται.\n1. Οι σημαίες δεν χρειάζεται να είναι ταξινομημένες με συγκεκριμένο τρόπο, αλλά πρέπει να αναφέρονται στο σωστό σημείο στην ιεραρχία υποεντολών του αρχείου.\n1. Οι υπάρχουσες καθολικές σημαίες του Helm διαχειρίζονται ήδη από τον μηχανισμό αυτόματης συμπλήρωσης του Helm, επομένως τα plugins δεν χρειάζεται να καθορίσουν τις ακόλουθες σημαίες: `--debug`, `--namespace` ή `-n`, `--kube-context` και `--kubeconfig`, ή οποιαδήποτε άλλη καθολική σημαία.\n1. Η λίστα `validArgs` παρέχει μια στατική λίστα πιθανών συμπληρώσεων για την πρώτη παράμετρο μετά από μια υποεντολή. Δεν είναι πάντα δυνατό να παρασχεθεί μια τέτοια λίστα εκ των προτέρων (δείτε την ενότητα [Δυναμική Συμπλήρωση](#dynamic-completion) παρακάτω), οπότε η ενότητα `validArgs` μπορεί να παραλειφθεί.\n\nΤο αρχείο `completion.yaml` είναι εντελώς προαιρετικό. Αν δεν παρέχεται, το Helm απλώς δεν θα παρέχει αυτόματη συμπλήρωση shell για το plugin (εκτός αν υποστηρίζεται [Δυναμική Συμπλήρωση](#dynamic-completion) από το plugin). Επίσης, η προσθήκη ενός αρχείου `completion.yaml` είναι συμβατή προς τα πίσω και δεν θα επηρεάσει τη συμπεριφορά του plugin σε παλαιότερες εκδόσεις του Helm.\n\nΩς παράδειγμα, για το [`fullstatus plugin`](https://github.com/marckhouzam/helm-fullstatus) που δεν έχει υποεντολές αλλά δέχεται τις ίδιες σημαίες με την εντολή `helm status`, το αρχείο `completion.yaml` είναι:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nΈνα πιο περίπλοκο παράδειγμα για το [`2to3 plugin`](https://github.com/helm/helm-2to3), έχει ένα αρχείο `completion.yaml`:\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### Δυναμική Συμπλήρωση {#dynamic-completion}\n\nΕπίσης από το Helm 3.2, τα plugins μπορούν να παρέχουν τη δική τους δυναμική αυτόματη συμπλήρωση shell. Η δυναμική αυτόματη συμπλήρωση shell είναι η συμπλήρωση τιμών παραμέτρων ή σημαιών που δεν μπορούν να οριστούν εκ των προτέρων. Για παράδειγμα, η συμπλήρωση ονομάτων helm releases που είναι διαθέσιμα αυτή τη στιγμή στο cluster.\n\nΓια να υποστηρίξει το plugin τη δυναμική αυτόματη συμπλήρωση, πρέπει να παρέχει ένα **εκτελέσιμο** αρχείο με όνομα `plugin.complete` στον ριζικό του κατάλογο. Όταν το script συμπλήρωσης του Helm απαιτεί δυναμικές συμπληρώσεις για το plugin, θα εκτελέσει το αρχείο `plugin.complete`, περνώντας του τη γραμμή εντολών που χρειάζεται συμπλήρωση. Το εκτελέσιμο `plugin.complete` θα πρέπει να έχει τη λογική για να καθορίσει ποιες είναι οι κατάλληλες επιλογές συμπλήρωσης και να τις εξάγει στην τυπική έξοδο για να καταναλωθούν από το script συμπλήρωσης του Helm.\n\nΤο αρχείο `plugin.complete` είναι εντελώς προαιρετικό. Αν δεν παρέχεται, το Helm απλώς δεν θα παρέχει δυναμική αυτόματη συμπλήρωση για το plugin. Επίσης, η προσθήκη ενός αρχείου `plugin.complete` είναι συμβατή προς τα πίσω και δεν θα επηρεάσει τη συμπεριφορά του plugin σε παλαιότερες εκδόσεις του Helm.\n\nΗ έξοδος του script `plugin.complete` πρέπει να είναι μια λίστα διαχωρισμένη με νέες γραμμές, όπως:\n\n```console\nrel1\nrel2\nrel3\n```\n\nΌταν καλείται το `plugin.complete`, το περιβάλλον του plugin ορίζεται όπως όταν καλείται το κύριο script του plugin. Επομένως, οι μεταβλητές `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` και όλες οι άλλες μεταβλητές plugin θα έχουν ήδη οριστεί, και οι αντίστοιχες καθολικές σημαίες τους θα έχουν αφαιρεθεί.\n\nΤο αρχείο `plugin.complete` μπορεί να είναι σε οποιαδήποτε εκτελέσιμη μορφή· μπορεί να είναι ένα shell script, ένα πρόγραμμα Go ή οποιοδήποτε άλλο είδος προγράμματος που μπορεί να εκτελέσει το Helm. Το αρχείο `plugin.complete` ***πρέπει*** να έχει δικαιώματα εκτέλεσης για τον χρήστη. Το αρχείο `plugin.complete` ***πρέπει*** να τερματίζει με κωδικό επιτυχίας (τιμή 0).\n\nΣε ορισμένες περιπτώσεις, η δυναμική συμπλήρωση θα απαιτεί τη λήψη πληροφοριών από το Kubernetes cluster. Για παράδειγμα, το plugin `helm fullstatus` απαιτεί ένα όνομα release ως είσοδο. Στο plugin `fullstatus`, για να παρέχει το script `plugin.complete` συμπληρώσεις για τρέχοντα ονόματα release, μπορεί απλώς να εκτελέσει `helm list -q` και να εξάγει το αποτέλεσμα.\n\nΑν επιθυμείτε να χρησιμοποιήσετε το ίδιο εκτελέσιμο τόσο για την εκτέλεση του plugin όσο και για τη συμπλήρωση του plugin, το script `plugin.complete` μπορεί να κάνει κλήση στο κύριο εκτελέσιμο του plugin με κάποια ειδική παράμετρο ή σημαία· όταν το κύριο εκτελέσιμο του plugin ανιχνεύσει την ειδική παράμετρο ή σημαία, θα γνωρίζει ότι πρέπει να εκτελέσει τη συμπλήρωση. Στο παράδειγμά μας, το `plugin.complete` θα μπορούσε να υλοποιηθεί ως εξής:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion. {#is-the-entire-command-line-that-requires-completion}\n# 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}\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nΤο πραγματικό script του plugin `fullstatus` (`status.sh`) πρέπει τότε να αναζητήσει τη σημαία `--complete` και αν βρεθεί, να εκτυπώσει τις κατάλληλες συμπληρώσεις.\n\n### Συμβουλές και Κόλπα {#tips-and-tricks}\n\n1. Το shell θα φιλτράρει αυτόματα τις επιλογές συμπλήρωσης που δεν ταιριάζουν με την είσοδο του χρήστη. Ένα plugin μπορεί επομένως να επιστρέφει όλες τις σχετικές συμπληρώσεις χωρίς να αφαιρεί αυτές που δεν ταιριάζουν με την είσοδο του χρήστη. Για παράδειγμα, αν η γραμμή εντολών είναι `helm fullstatus ngin<TAB>`, το script `plugin.complete` μπορεί να εκτυπώσει *όλα* τα ονόματα release (του namespace `default`), όχι μόνο αυτά που αρχίζουν με `ngin`· το shell θα διατηρήσει μόνο αυτά που αρχίζουν με `ngin`.\n1. Για να απλοποιήσετε την υποστήριξη δυναμικής συμπλήρωσης, ειδικά αν έχετε ένα πολύπλοκο plugin, μπορείτε να κάνετε το script `plugin.complete` να καλέσει το κύριο script του plugin σας και να ζητήσει επιλογές συμπλήρωσης. Δείτε την ενότητα [Δυναμική Συμπλήρωση](#dynamic-completion) παραπάνω για ένα παράδειγμα.\n1. Για να αποσφαλματώσετε τη δυναμική συμπλήρωση και το αρχείο `plugin.complete`, μπορείτε να εκτελέσετε τα ακόλουθα για να δείτε τα αποτελέσματα συμπλήρωσης:\n    - `helm __complete <pluginName> <arguments to complete>`. Για παράδειγμα:\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: Προέλευση και Ακεραιότητα Helm\ndescription: Περιγράφει πώς να επαληθεύσετε την ακεραιότητα και την προέλευση ενός Chart.\nsidebar_position: 5\n---\n\nΤο Helm διαθέτει εργαλεία προέλευσης που βοηθούν τους χρήστες chart να\nεπαληθεύσουν την ακεραιότητα και την προέλευση ενός πακέτου. Χρησιμοποιώντας\nεργαλεία βασισμένα σε βιομηχανικά πρότυπα, σε PKI, GnuPG και σεβαστούς διαχειριστές\nπακέτων, το Helm μπορεί να δημιουργήσει και να επαληθεύσει αρχεία υπογραφής.\n\n## Επισκόπηση {#overview}\n\nΗ ακεραιότητα καθορίζεται συγκρίνοντας ένα chart με μια εγγραφή προέλευσης. Οι\nεγγραφές προέλευσης αποθηκεύονται σε _αρχεία προέλευσης_, τα οποία αποθηκεύονται\nμαζί με το πακεταρισμένο chart. Για παράδειγμα, αν ένα chart ονομάζεται\n`myapp-1.2.3.tgz`, το αρχείο προέλευσής του θα είναι `myapp-1.2.3.tgz.prov`.\n\nΤα αρχεία προέλευσης δημιουργούνται κατά τη διαδικασία πακεταρίσματος\n(`helm package --sign ...`) και μπορούν να ελεγχθούν από πολλές εντολές,\nκυρίως την `helm install --verify`.\n\n## Η Ροή Εργασίας {#the-workflow}\n\nΑυτή η ενότητα περιγράφει μια πιθανή ροή εργασίας για την αποτελεσματική χρήση\nδεδομένων προέλευσης.\n\nΠροαπαιτούμενα:\n\n- Ένα έγκυρο ζεύγος κλειδιών PGP σε δυαδική μορφή (όχι ASCII-armored)\n- Το εργαλείο γραμμής εντολών `helm`\n- Εργαλεία γραμμής εντολών GnuPG (προαιρετικά)\n- Εργαλεία γραμμής εντολών Keybase (προαιρετικά)\n\n**ΣΗΜΕΙΩΣΗ:** Αν το ιδιωτικό κλειδί PGP σας έχει κωδικό πρόσβασης, θα σας\nζητηθεί να τον εισάγετε για οποιαδήποτε εντολή υποστηρίζει την επιλογή `--sign`.\n\nΗ δημιουργία ενός νέου chart είναι ίδια με πριν:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nΌταν είστε έτοιμοι για πακετάρισμα, προσθέστε τη σημαία `--sign` στην εντολή\n`helm package`. Επίσης, καθορίστε το όνομα με το οποίο είναι γνωστό το κλειδί\nυπογραφής και το keyring που περιέχει το αντίστοιχο ιδιωτικό κλειδί:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**Σημείωση:** Η τιμή του ορίσματος `--key` πρέπει να είναι ένα υποσύνολο του\n`uid` του επιθυμητού κλειδιού (στην έξοδο της `gpg --list-keys`), για παράδειγμα\nτο όνομα ή το email. **Το αποτύπωμα _δεν_ μπορεί να χρησιμοποιηθεί.**\n\n**ΣΥΜΒΟΥΛΗ:** Για χρήστες GnuPG, το μυστικό keyring σας βρίσκεται στο\n`~/.gnupg/secring.gpg`. Μπορείτε να χρησιμοποιήσετε την εντολή\n`gpg --list-secret-keys` για να δείτε τα κλειδιά που διαθέτετε.\n\n**Προειδοποίηση:** Το GnuPG v2 αποθηκεύει το μυστικό keyring σας χρησιμοποιώντας\nτη νέα μορφή `kbx` στην προεπιλεγμένη τοποθεσία `~/.gnupg/pubring.kbx`.\nΧρησιμοποιήστε την ακόλουθη εντολή για να μετατρέψετε το keyring σας στην\nπαλαιότερη μορφή gpg:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nΤώρα θα πρέπει να βλέπετε και τα δύο αρχεία `mychart-0.1.0.tgz`\nκαι `mychart-0.1.0.tgz.prov`. Και τα δύο αρχεία θα πρέπει τελικά να μεταφορτωθούν\nστο επιθυμητό αποθετήριο chart.\n\nΜπορείτε να επαληθεύσετε ένα chart χρησιμοποιώντας `helm verify`:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nΜια αποτυχημένη επαλήθευση έχει την εξής μορφή:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nΓια να επαληθεύσετε κατά την εγκατάσταση, χρησιμοποιήστε τη σημαία `--verify`.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nΑν το keyring που περιέχει το δημόσιο κλειδί σχετιζόμενο με το υπογεγραμμένο\nchart δεν βρίσκεται στην προεπιλεγμένη τοποθεσία, ίσως χρειαστεί να υποδείξετε\nτο keyring με `--keyring PATH` όπως στο παράδειγμα της `helm package`.\n\nΑν η επαλήθευση αποτύχει, η εγκατάσταση θα ακυρωθεί πριν καν αποδοθεί το chart.\n\n### Χρήση διαπιστευτηρίων Keybase.io {#using-keybaseio-credentials}\n\nΗ υπηρεσία [Keybase.io](https://keybase.io) διευκολύνει τη δημιουργία μιας\nαλυσίδας εμπιστοσύνης για μια κρυπτογραφική ταυτότητα. Τα διαπιστευτήρια Keybase\nμπορούν να χρησιμοποιηθούν για την υπογραφή charts.\n\nΠροαπαιτούμενα:\n\n- Ένας διαμορφωμένος λογαριασμός Keybase.io\n- Εγκατεστημένο τοπικά το GnuPG\n- Εγκατεστημένο τοπικά το `keybase` CLI\n\n#### Υπογραφή πακέτων {#signing-packages}\n\nΤο πρώτο βήμα είναι να εισάγετε τα κλειδιά Keybase στο τοπικό σας GnuPG keyring:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nΑυτό θα μετατρέψει το κλειδί Keybase σας σε μορφή OpenPGP και στη συνέχεια θα\nτο εισάγει τοπικά στο αρχείο `~/.gnupg/secring.gpg`.\n\nΜπορείτε να επαληθεύσετε εκτελώντας `gpg --list-secret-keys`.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nΣημειώστε ότι το μυστικό κλειδί σας θα έχει μια συμβολοσειρά αναγνώρισης:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nΑυτό είναι το πλήρες όνομα του κλειδιού σας.\n\nΣτη συνέχεια, μπορείτε να πακετάρετε και να υπογράψετε ένα chart με\n`helm package`. Βεβαιωθείτε ότι χρησιμοποιείτε τουλάχιστον μέρος αυτής της\nσυμβολοσειράς ονόματος στο `--key`.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nΩς αποτέλεσμα, η εντολή `package` θα παράγει και ένα αρχείο `.tgz` και ένα\nαρχείο `.tgz.prov`.\n\n#### Επαλήθευση πακέτων {#verifying-packages}\n\nΜπορείτε επίσης να χρησιμοποιήσετε παρόμοια τεχνική για να επαληθεύσετε ένα\nchart που έχει υπογραφεί από το κλειδί Keybase κάποιου άλλου. Ας πούμε ότι\nθέλετε να επαληθεύσετε ένα πακέτο υπογεγραμμένο από τον `keybase.io/technosophos`.\nΓια να το κάνετε αυτό, χρησιμοποιήστε το εργαλείο `keybase`:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nΗ πρώτη εντολή παραπάνω ακολουθεί τον χρήστη `technosophos`. Στη συνέχεια, η\n`keybase pgp pull` κατεβάζει τα κλειδιά OpenPGP όλων των λογαριασμών που\nακολουθείτε, τοποθετώντας τα στο GnuPG keyring σας (`~/.gnupg/pubring.gpg`).\n\nΤώρα μπορείτε να χρησιμοποιήσετε `helm verify` ή οποιαδήποτε εντολή με τη\nσημαία `--verify`:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Λόγοι που ένα chart μπορεί να μην επαληθευτεί {#reasons-a-chart-may-not-verify}\n\nΑυτοί είναι συνήθεις λόγοι αποτυχίας.\n\n- Το αρχείο `.prov` λείπει ή είναι κατεστραμμένο. Αυτό υποδηλώνει ότι κάτι\n  έχει ρυθμιστεί λανθασμένα ή ότι ο αρχικός συντηρητής δεν δημιούργησε αρχείο\n  προέλευσης.\n- Το κλειδί που χρησιμοποιήθηκε για την υπογραφή του αρχείου δεν βρίσκεται στο\n  keyring σας. Αυτό υποδηλώνει ότι η οντότητα που υπέγραψε το chart δεν είναι\n  κάποιος που έχετε ήδη υποδείξει ότι εμπιστεύεστε.\n- Η επαλήθευση του αρχείου `.prov` απέτυχε. Αυτό υποδηλώνει ότι κάτι δεν πάει\n  καλά είτε με το chart είτε με τα δεδομένα προέλευσης.\n- Τα hash αρχείων στο αρχείο προέλευσης δεν ταιριάζουν με το hash του αρχείου\n  αρχειοθήκης. Αυτό υποδηλώνει ότι η αρχειοθήκη έχει παραποιηθεί.\n\nΑν μια επαλήθευση αποτύχει, υπάρχει λόγος να μην εμπιστεύεστε το πακέτο.\n\n## Το Αρχείο Προέλευσης {#the-provenance-file}\n\nΤο αρχείο προέλευσης περιέχει το αρχείο YAML του chart μαζί με αρκετές\nπληροφορίες επαλήθευσης. Τα αρχεία προέλευσης είναι σχεδιασμένα να δημιουργούνται\nαυτόματα.\n\nΠροστίθενται τα ακόλουθα δεδομένα προέλευσης:\n\n* Το αρχείο chart (`Chart.yaml`) περιλαμβάνεται για να δώσει τόσο στους\n  ανθρώπους όσο και στα εργαλεία μια εύκολη προβολή στα περιεχόμενα του chart.\n* Η υπογραφή (SHA256, όπως στο Docker) του πακέτου chart (το αρχείο `.tgz`)\n  περιλαμβάνεται και μπορεί να χρησιμοποιηθεί για την επαλήθευση της\n  ακεραιότητας του πακέτου chart.\n* Ολόκληρο το σώμα υπογράφεται χρησιμοποιώντας τον αλγόριθμο που χρησιμοποιεί\n  το OpenPGP (δείτε το [Keybase.io](https://keybase.io) για έναν αναδυόμενο\n  τρόπο που κάνει την κρυπτογραφική υπογραφή και επαλήθευση εύκολη).\n\nΟ συνδυασμός αυτών δίνει στους χρήστες τις ακόλουθες εγγυήσεις:\n\n* Το ίδιο το πακέτο δεν έχει παραποιηθεί (checksum πακέτου `.tgz`).\n* Η οντότητα που κυκλοφόρησε αυτό το πακέτο είναι γνωστή (μέσω της υπογραφής\n  GnuPG/PGP).\n\nΗ μορφή του αρχείου είναι η ακόλουθη:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nΣημειώστε ότι η ενότητα YAML περιέχει δύο έγγραφα (χωρισμένα με `...\\n`). Το\nπρώτο αρχείο είναι το περιεχόμενο του `Chart.yaml`. Το δεύτερο είναι τα\nchecksums, μια αντιστοίχιση ονομάτων αρχείων σε SHA-256 digests του περιεχομένου\nκάθε αρχείου κατά τη στιγμή του πακεταρίσματος.\n\nΤο μπλοκ υπογραφής είναι μια τυπική υπογραφή PGP, η οποία παρέχει [αντίσταση\nσε παραποίηση](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Αποθετήρια Chart {#chart-repositories}\n\nΤα αποθετήρια chart λειτουργούν ως κεντρική συλλογή Helm charts.\n\nΤα αποθετήρια chart πρέπει να μπορούν να εξυπηρετούν αρχεία προέλευσης μέσω\nHTTP με συγκεκριμένο αίτημα, και πρέπει να τα καθιστούν διαθέσιμα στην ίδια\nδιαδρομή URI με το chart.\n\nΓια παράδειγμα, αν η βασική διεύθυνση URL για ένα πακέτο είναι\n`https://example.com/charts/mychart-1.2.3.tgz`, το αρχείο προέλευσης, αν\nυπάρχει, ΠΡΕΠΕΙ να είναι προσβάσιμο στη διεύθυνση\n`https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nΑπό την πλευρά του τελικού χρήστη, η εντολή\n`helm install --verify myrepo/mychart-1.2.3` θα πρέπει να κατεβάζει τόσο το\nchart όσο και το αρχείο προέλευσης χωρίς επιπλέον διαμόρφωση ή ενέργεια από\nτον χρήστη.\n\n### Υπογραφές σε αποθετήρια βασισμένα σε OCI {#signatures-in-oci-based-registries}\n\nΚατά τη δημοσίευση charts σε ένα [αποθετήριο βασισμένο σε OCI](/topics/registries.md),\nτο plugin [`helm-sigstore`](https://github.com/sigstore/helm-sigstore/) μπορεί\nνα χρησιμοποιηθεί για τη δημοσίευση προέλευσης στο [sigstore](https://sigstore.dev/).\n[Όπως περιγράφεται στην τεκμηρίωση](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md),\nη διαδικασία δημιουργίας προέλευσης και υπογραφής με κλειδί GPG είναι κοινές,\nαλλά η εντολή `helm sigstore upload` μπορεί να χρησιμοποιηθεί για τη δημοσίευση\nτης προέλευσης σε ένα αμετάβλητο αρχείο καταγραφής διαφάνειας.\n\n## Καθιέρωση Αρχής και Αυθεντικότητας {#establishing-authority-and-authenticity}\n\nΌταν ασχολούμαστε με συστήματα αλυσίδας εμπιστοσύνης, είναι σημαντικό να μπορούμε\nνα καθιερώσουμε την αρχή ενός υπογράφοντα. Ή, για να το θέσουμε απλά, το παραπάνω\nσύστημα βασίζεται στο γεγονός ότι εμπιστεύεστε το άτομο που υπέγραψε το chart.\nΑυτό, με τη σειρά του, σημαίνει ότι πρέπει να εμπιστεύεστε το δημόσιο κλειδί\nτου υπογράφοντα.\n\nΜία από τις σχεδιαστικές αποφάσεις του Helm ήταν να μην εισαχθεί το ίδιο το\nHelm project στην αλυσίδα εμπιστοσύνης ως απαραίτητο μέρος. Δεν θέλουμε να\nείμαστε \"η αρχή πιστοποίησης\" για όλους τους υπογράφοντες chart. Αντίθετα,\nπροτιμούμε έντονα ένα αποκεντρωμένο μοντέλο, που είναι μέρος του λόγου που\nεπιλέξαμε το OpenPGP ως θεμελιώδη τεχνολογία μας. Έτσι, όσον αφορά την\nκαθιέρωση αρχής, αφήσαμε αυτό το βήμα ως ανοικτό ζήτημα στο Helm 2 (μια\nαπόφαση που συνεχίστηκε στο Helm 3).\n\nΩστόσο, έχουμε μερικές υποδείξεις και συστάσεις για όσους ενδιαφέρονται να\nχρησιμοποιήσουν το σύστημα προέλευσης:\n\n- Η πλατφόρμα [Keybase](https://keybase.io) παρέχει ένα δημόσιο κεντρικό\n  αποθετήριο για πληροφορίες εμπιστοσύνης.\n  - Μπορείτε να χρησιμοποιήσετε το Keybase για να αποθηκεύσετε τα κλειδιά σας\n    ή να λάβετε τα δημόσια κλειδιά άλλων.\n  - Το Keybase διαθέτει επίσης εξαιρετική τεκμηρίωση\n  - Αν και δεν το έχουμε δοκιμάσει, η λειτουργία \"secure website\" του Keybase\n    θα μπορούσε να χρησιμοποιηθεί για την εξυπηρέτηση Helm charts.\n  - Η βασική ιδέα είναι ότι ένας επίσημος \"αξιολογητής chart\" υπογράφει charts\n    με το κλειδί του/της, και το αρχείο προέλευσης που προκύπτει μεταφορτώνεται\n    στη συνέχεια στο αποθετήριο chart.\n  - Έχει γίνει κάποια δουλειά στην ιδέα ότι μια λίστα έγκυρων κλειδιών υπογραφής\n    μπορεί να συμπεριληφθεί στο αρχείο `index.yaml` ενός αποθετηρίου.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: Έλεγχος Πρόσβασης Βασισμένος σε Ρόλους\ndescription: Εξηγεί πώς το Helm αλληλεπιδρά με τον Έλεγχο Πρόσβασης Βασισμένο σε Ρόλους (RBAC) του Kubernetes.\nsidebar_position: 11\n---\n\nΣτο Kubernetes, η εκχώρηση ρόλων σε έναν χρήστη ή σε ένα service account της\nεφαρμογής σας αποτελεί βέλτιστη πρακτική για να διασφαλίσετε ότι η εφαρμογή σας\nλειτουργεί εντός του πεδίου που έχετε ορίσει. Διαβάστε περισσότερα σχετικά με\nτα δικαιώματα service account [στην επίσημη τεκμηρίωση του\nKubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nΑπό το Kubernetes 1.6 και μετά, ο Έλεγχος Πρόσβασης Βασισμένος σε Ρόλους είναι\nενεργοποιημένος από προεπιλογή. Το RBAC σας επιτρέπει να καθορίσετε ποιοι τύποι\nενεργειών επιτρέπονται ανάλογα με τον χρήστη και τον ρόλο του στον οργανισμό σας.\n\nΜε το RBAC, μπορείτε να:\n\n- εκχωρήσετε προνομιούχες λειτουργίες (δημιουργία πόρων σε επίπεδο cluster, όπως\n  νέοι ρόλοι) σε διαχειριστές\n- περιορίσετε τη δυνατότητα ενός χρήστη να δημιουργεί πόρους (pods, persistent\n  volumes, deployments) σε συγκεκριμένα namespaces ή σε επίπεδο cluster (resource\n  quotas, roles, custom resource definitions)\n- περιορίσετε τη δυνατότητα ενός χρήστη να βλέπει πόρους είτε σε συγκεκριμένα\n  namespaces είτε σε επίπεδο cluster.\n\nΑυτός ο οδηγός είναι για διαχειριστές που θέλουν να περιορίσουν το πεδίο\nαλληλεπίδρασης ενός χρήστη με το Kubernetes API.\n\n## Διαχείριση λογαριασμών χρηστών {#managing-user-accounts}\n\nΌλα τα clusters του Kubernetes έχουν δύο κατηγορίες χρηστών: service accounts που\nδιαχειρίζεται το Kubernetes και κανονικούς χρήστες.\n\nΟι κανονικοί χρήστες θεωρείται ότι διαχειρίζονται από μια εξωτερική, ανεξάρτητη\nυπηρεσία. Μπορεί να είναι ένας διαχειριστής που διανέμει ιδιωτικά κλειδιά, ένα\nσύστημα αποθήκευσης χρηστών όπως το Keystone ή τα Google Accounts, ακόμα και ένα\nαρχείο με λίστα ονομάτων χρηστών και κωδικών πρόσβασης. Σε αυτό το πλαίσιο, το\nKubernetes δεν διαθέτει αντικείμενα που αντιπροσωπεύουν λογαριασμούς κανονικών\nχρηστών. Οι κανονικοί χρήστες δεν μπορούν να προστεθούν σε ένα cluster μέσω\nκλήσης API.\n\nΑντίθετα, τα service accounts είναι χρήστες που διαχειρίζεται το Kubernetes API.\nΕίναι δεσμευμένα σε συγκεκριμένα namespaces και δημιουργούνται αυτόματα από τον\nAPI server ή χειροκίνητα μέσω κλήσεων API. Τα service accounts συνδέονται με ένα\nσύνολο διαπιστευτηρίων που αποθηκεύονται ως Secrets, τα οποία προσαρτώνται σε\npods επιτρέποντας στις διεργασίες εντός του cluster να επικοινωνούν με το\nKubernetes API.\n\nΤα αιτήματα API συνδέονται είτε με έναν κανονικό χρήστη είτε με ένα service\naccount, ή αντιμετωπίζονται ως ανώνυμα αιτήματα. Αυτό σημαίνει ότι κάθε διεργασία\nεντός ή εκτός του cluster, από έναν χρήστη που πληκτρολογεί `kubectl` σε έναν\nσταθμό εργασίας, μέχρι τα kubelets στους κόμβους, μέχρι τα μέλη του control\nplane, πρέπει να πιστοποιηθεί όταν κάνει αιτήματα στον API server, ή θα\nαντιμετωπιστεί ως ανώνυμος χρήστης.\n\n## Roles, ClusterRoles, RoleBindings και ClusterRoleBindings {#roles-clusterroles-rolebindings-and-clusterrolebindings}\n\nΣτο Kubernetes, οι λογαριασμοί χρηστών και τα service accounts μπορούν να βλέπουν\nκαι να επεξεργάζονται μόνο πόρους στους οποίους τους έχει εκχωρηθεί πρόσβαση.\nΑυτή η πρόσβαση εκχωρείται μέσω της χρήσης Roles και RoleBindings. Τα Roles και\nτα RoleBindings είναι δεσμευμένα σε ένα συγκεκριμένο namespace, το οποίο παρέχει\nστους χρήστες τη δυνατότητα να βλέπουν ή/και να επεξεργάζονται πόρους εντός αυτού\nτου namespace στο οποίο το Role τους παρέχει πρόσβαση.\n\nΣε επίπεδο cluster, αυτά ονομάζονται ClusterRoles και ClusterRoleBindings.\nΗ εκχώρηση ενός ClusterRole σε έναν χρήστη του παρέχει πρόσβαση για προβολή ή/και\nεπεξεργασία πόρων σε ολόκληρο το cluster. Απαιτείται επίσης για την προβολή ή/και\nεπεξεργασία πόρων σε επίπεδο cluster (namespaces, resource quotas, nodes).\n\nΤα ClusterRoles μπορούν να δεσμευτούν σε ένα συγκεκριμένο namespace μέσω αναφοράς\nσε ένα RoleBinding. Τα προεπιλεγμένα ClusterRoles `admin`, `edit` και `view`\nχρησιμοποιούνται συχνά με αυτόν τον τρόπο.\n\nΥπάρχουν μερικά ClusterRoles διαθέσιμα από προεπιλογή στο Kubernetes.\nΠροορίζονται ως ρόλοι για τους χρήστες. Περιλαμβάνουν ρόλους υπερχρήστη\n(`cluster-admin`) και ρόλους με πιο λεπτομερή πρόσβαση (`admin`, `edit`, `view`).\n\n| Προεπιλεγμένο ClusterRole | Προεπιλεγμένο ClusterRoleBinding | Περιγραφή\n|---------------------------|----------------------------------|------------\n| `cluster-admin`           | ομάδα `system:masters`           | Επιτρέπει πρόσβαση υπερχρήστη για εκτέλεση οποιασδήποτε ενέργειας σε οποιονδήποτε πόρο. Όταν χρησιμοποιείται σε ένα ClusterRoleBinding, παρέχει πλήρη έλεγχο σε κάθε πόρο του cluster και σε όλα τα namespaces. Όταν χρησιμοποιείται σε ένα RoleBinding, παρέχει πλήρη έλεγχο σε κάθε πόρο του namespace του rolebinding, συμπεριλαμβανομένου του ίδιου του namespace.\n| `admin`                   | Κανένα                           | Επιτρέπει πρόσβαση διαχειριστή, προορίζεται να εκχωρηθεί εντός ενός namespace χρησιμοποιώντας ένα RoleBinding. Αν χρησιμοποιηθεί σε ένα RoleBinding, επιτρέπει πρόσβαση ανάγνωσης/εγγραφής στους περισσότερους πόρους ενός namespace, συμπεριλαμβανομένης της δυνατότητας δημιουργίας roles και rolebindings εντός του namespace. Δεν επιτρέπει πρόσβαση εγγραφής στα resource quotas ή στο ίδιο το namespace.\n| `edit`                    | Κανένα                           | Επιτρέπει πρόσβαση ανάγνωσης/εγγραφής στους περισσότερους πόρους ενός namespace. Δεν επιτρέπει την προβολή ή τροποποίηση roles ή rolebindings.\n| `view`                    | Κανένα                           | Επιτρέπει πρόσβαση μόνο για ανάγνωση στους περισσότερους πόρους ενός namespace. Δεν επιτρέπει την προβολή roles ή rolebindings. Δεν επιτρέπει την προβολή secrets, καθώς αυτό θα αποτελούσε κλιμάκωση δικαιωμάτων.\n\n## Περιορισμός πρόσβασης λογαριασμού χρήστη με χρήση RBAC {#restricting-a-user-accounts-access-using-rbac}\n\nΤώρα που κατανοούμε τα βασικά του Ελέγχου Πρόσβασης Βασισμένου σε Ρόλους, ας\nδούμε πώς ένας διαχειριστής μπορεί να περιορίσει το πεδίο πρόσβασης ενός χρήστη.\n\n### Παράδειγμα: Εκχώρηση πρόσβασης ανάγνωσης/εγγραφής σε ένα συγκεκριμένο namespace {#example-grant-a-user-readwrite-access-to-a-particular-namespace}\n\nΓια να περιορίσετε την πρόσβαση ενός χρήστη σε ένα συγκεκριμένο namespace,\nμπορείτε να χρησιμοποιήσετε είτε τον ρόλο `edit` είτε τον ρόλο `admin`. Αν τα\ncharts σας δημιουργούν ή αλληλεπιδρούν με Roles και Rolebindings, θα θέλετε να\nχρησιμοποιήσετε το ClusterRole `admin`.\n\nΕπιπλέον, μπορείτε επίσης να δημιουργήσετε ένα RoleBinding με πρόσβαση\n`cluster-admin`. Η εκχώρηση πρόσβασης `cluster-admin` σε έναν χρήστη σε επίπεδο\nnamespace παρέχει πλήρη έλεγχο σε κάθε πόρο του namespace, συμπεριλαμβανομένου\nτου ίδιου του namespace.\n\nΓια αυτό το παράδειγμα, θα δημιουργήσουμε έναν χρήστη με τον ρόλο `edit`. Πρώτα,\nδημιουργήστε το namespace:\n\n```console\n$ kubectl create namespace foo\n```\n\nΤώρα, δημιουργήστε ένα RoleBinding σε αυτό το namespace, εκχωρώντας στον χρήστη\nτον ρόλο `edit`.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Παράδειγμα: Εκχώρηση πρόσβασης ανάγνωσης/εγγραφής σε επίπεδο cluster {#example-grant-a-user-readwrite-access-at-the-cluster-scope}\n\nΑν ένας χρήστης επιθυμεί να εγκαταστήσει ένα chart που εγκαθιστά πόρους σε\nεπίπεδο cluster (namespaces, roles, custom resource definitions, κ.λπ.), θα\nχρειαστεί πρόσβαση εγγραφής σε επίπεδο cluster.\n\nΓια να το κάνετε αυτό, εκχωρήστε στον χρήστη πρόσβαση `admin` ή `cluster-admin`.\n\nΗ εκχώρηση πρόσβασης `cluster-admin` σε έναν χρήστη του παρέχει πρόσβαση σε\nαπολύτως κάθε διαθέσιμο πόρο στο Kubernetes, συμπεριλαμβανομένης της πρόσβασης σε\nκόμβους με `kubectl drain` και άλλες διαχειριστικές εργασίες. Συνιστάται ιδιαίτερα\nνα εξετάσετε το ενδεχόμενο να παρέχετε στον χρήστη πρόσβαση `admin` αντί αυτού,\nή να δημιουργήσετε ένα προσαρμοσμένο ClusterRole προσαρμοσμένο στις ανάγκες του.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Παράδειγμα: Εκχώρηση πρόσβασης μόνο για ανάγνωση σε ένα συγκεκριμένο namespace {#example-grant-a-user-read-only-access-to-a-particular-namespace}\n\nΜπορεί να έχετε παρατηρήσει ότι δεν υπάρχει διαθέσιμο ClusterRole για την προβολή\nsecrets. Το ClusterRole `view` δεν παρέχει στον χρήστη πρόσβαση ανάγνωσης στα\nSecrets λόγω ανησυχιών για κλιμάκωση δικαιωμάτων. Το Helm αποθηκεύει τα\nμεταδεδομένα των releases ως Secrets από προεπιλογή.\n\nΓια να μπορέσει ένας χρήστης να εκτελέσει `helm list`, πρέπει να μπορεί να\nδιαβάσει αυτά τα secrets. Για αυτό, θα δημιουργήσουμε ένα ειδικό ClusterRole\n`secret-reader`.\n\nΔημιουργήστε το αρχείο `cluster-role-secret-reader.yaml` και γράψτε το ακόλουθο\nπεριεχόμενο σε αυτό:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nΣτη συνέχεια, δημιουργήστε το ClusterRole χρησιμοποιώντας:\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nΜόλις ολοκληρωθεί αυτό, μπορούμε να εκχωρήσουμε σε έναν χρήστη πρόσβαση ανάγνωσης\nστους περισσότερους πόρους, και στη συνέχεια να του εκχωρήσουμε πρόσβαση ανάγνωσης\nστα secrets:\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Παράδειγμα: Εκχώρηση πρόσβασης μόνο για ανάγνωση σε επίπεδο cluster {#example-grant-a-user-read-only-access-at-the-cluster-scope}\n\nΣε ορισμένα σενάρια, μπορεί να είναι ωφέλιμο να εκχωρηθεί σε έναν χρήστη πρόσβαση\nσε επίπεδο cluster. Για παράδειγμα, αν ένας χρήστης θέλει να εκτελέσει την εντολή\n`helm list --all-namespaces`, το API απαιτεί ο χρήστης να έχει πρόσβαση ανάγνωσης\nσε επίπεδο cluster.\n\nΓια να το κάνετε αυτό, εκχωρήστε στον χρήστη πρόσβαση τόσο `view` όσο και\n`secret-reader` όπως περιγράφηκε παραπάνω, αλλά με ένα ClusterRoleBinding.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Επιπλέον Σκέψεις {#additional-thoughts}\n\nΤα παραπάνω παραδείγματα χρησιμοποιούν τα προεπιλεγμένα ClusterRoles που παρέχει\nτο Kubernetes. Για πιο λεπτομερή έλεγχο των πόρων στους οποίους οι χρήστες έχουν\nπρόσβαση, ανατρέξτε στην [τεκμηρίωση του\nKubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) για τη\nδημιουργία προσαρμοσμένων Roles και ClusterRoles.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: Χρήση Μητρώων OCI\ndescription: Περιγράφει τη χρήση του OCI για τη διανομή Charts.\nsidebar_position: 7\n---\n\nΑπό το Helm 3, μπορείτε να χρησιμοποιείτε container registries με υποστήριξη [OCI](https://www.opencontainers.org/) για την αποθήκευση και διαμοιρασμό πακέτων chart. Από το Helm v3.8.0, η υποστήριξη OCI είναι ενεργοποιημένη από προεπιλογή.\n\n\n## Υποστήριξη OCI πριν από την v3.8.0 {#oci-support-prior-to-v380}\n\nΗ υποστήριξη OCI πέρασε από πειραματικό σε γενικά διαθέσιμο στάδιο με το Helm v3.8.0. Σε προηγούμενες εκδόσεις του Helm, η υποστήριξη OCI λειτουργούσε διαφορετικά. Αν χρησιμοποιούσατε υποστήριξη OCI πριν από το Helm v3.8.0, είναι σημαντικό να κατανοήσετε τι έχει αλλάξει στις διάφορες εκδόσεις του Helm.\n\n### Ενεργοποίηση υποστήριξης OCI πριν από την v3.8.0 {#enabling-oci-support-prior-to-v380}\n\nΠριν από το Helm v3.8.0, η υποστήριξη OCI είναι *πειραματική* και πρέπει να ενεργοποιηθεί χειροκίνητα.\n\nΓια να ενεργοποιήσετε την πειραματική υποστήριξη OCI σε εκδόσεις Helm πριν από την v3.8.0, ορίστε τη μεταβλητή `HELM_EXPERIMENTAL_OCI` στο περιβάλλον σας. Για παράδειγμα:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### Απόσυρση λειτουργιών και αλλαγές συμπεριφοράς στην v3.8.0 {#oci-feature-deprecation-and-behavior-changes-with-v380}\n\nΜε την κυκλοφορία του [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0), οι ακόλουθες λειτουργίες και συμπεριφορές διαφέρουν από προηγούμενες εκδόσεις του Helm:\n\n- Όταν ορίζετε ένα chart στις εξαρτήσεις ως OCI, η έκδοση μπορεί να οριστεί ως εύρος, όπως και στις υπόλοιπες εξαρτήσεις.\n- Μπορείτε πλέον να αποστέλλετε και να χρησιμοποιείτε SemVer tags που περιλαμβάνουν πληροφορίες build. Τα OCI registries δεν υποστηρίζουν τον χαρακτήρα `+` στα tags. Το Helm μετατρέπει το `+` σε `_` κατά την αποθήκευση ως tag.\n- Η εντολή `helm registry login` ακολουθεί πλέον την ίδια δομή με το Docker CLI για την αποθήκευση διαπιστευτηρίων. Μπορείτε να χρησιμοποιήσετε την ίδια τοποθεσία διαμόρφωσης registry τόσο για το Helm όσο και για το Docker CLI.\n\n### Απόσυρση λειτουργιών και αλλαγές συμπεριφοράς στην v3.7.0 {#oci-feature-deprecation-and-behavior-changes-with-v370}\n\nΜε την κυκλοφορία του [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:\n\n- Η υποεντολή `helm chart` αφαιρέθηκε.\n- Η προσωρινή μνήμη (cache) των charts αφαιρέθηκε (δεν υπάρχει πλέον `helm chart list` κτλ.).\n- Οι αναφορές σε OCI registry ξεκινούν πλέον πάντα με το πρόθεμα `oci://`.\n- Το basename της αναφοράς στο registry πρέπει *πάντα* να ταιριάζει με το όνομα του chart.\n- Το tag της αναφοράς στο registry πρέπει *πάντα* να ταιριάζει με τη σημασιολογική έκδοση του chart (δηλαδή δεν επιτρέπονται `latest` tags).\n- Ο media type του επιπέδου chart άλλαξε από `application/tar+gzip` σε `application/vnd.cncf.helm.chart.content.v1.tar+gzip`.\n\n\n## Χρήση Μητρώου OCI {#using-an-oci-based-registry}\n\n### Αποθετήρια Helm σε Μητρώα OCI {#helm-repositories-in-oci-based-registries}\n\nΈνα [αποθετήριο Helm](/topics/chart_repository.md) είναι ένας τρόπος φιλοξενίας και διανομής πακέτων Helm charts. Ένα μητρώο OCI μπορεί να περιέχει μηδέν ή περισσότερα αποθετήρια Helm, και κάθε αποθετήριο μπορεί να περιέχει μηδέν ή περισσότερα πακέτα Helm charts.\n\n### Χρήση Φιλοξενούμενων Μητρώων {#use-hosted-registries}\n\nΥπάρχουν αρκετά φιλοξενούμενα container registries με υποστήριξη OCI που μπορείτε να χρησιμοποιήσετε για τα Helm charts σας. Για παράδειγμα:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\nΑκολουθήστε την τεκμηρίωση του παρόχου για να δημιουργήσετε και να διαμορφώσετε ένα registry με υποστήριξη OCI.\n\n**Σημείωση:** Μπορείτε να εκτελέσετε τοπικά το [Docker Registry](https://docs.docker.com/registry/deploying/) ή το [`zot`](https://github.com/project-zot/zot), που είναι μητρώα OCI, στον υπολογιστή ανάπτυξής σας. Η τοπική εκτέλεση μητρώου OCI πρέπει να χρησιμοποιείται μόνο για δοκιμές.\n\n### Χρήση sigstore για Υπογραφή Charts OCI {#using-sigstore-to-sign-oci-based-charts}\n\nΤο 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).\n\nΓια περισσότερες λεπτομέρειες σχετικά με τη χρήση του plugin `helm sigstore`, ανατρέξτε στην [τεκμηρίωση του έργου](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md).\n\n## Εντολές για Εργασία με Μητρώα {#commands-for-working-with-registries}\n\n### Η Υποεντολή `registry` {#the-registry-subcommand}\n\n#### `login` {#login}\n\nΣύνδεση σε registry (με χειροκίνητη εισαγωγή κωδικού):\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout` {#logout}\n\nΑποσύνδεση από registry:\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### Η Υποεντολή `push` {#the-push-subcommand}\n\nΑποστολή chart σε μητρώο OCI:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nΗ υποεντολή `push` μπορεί να χρησιμοποιηθεί μόνο με αρχεία `.tgz` που έχουν δημιουργηθεί προηγουμένως με το `helm package`.\n\nΚατά τη χρήση του `helm push` για αποστολή chart σε OCI registry, η αναφορά πρέπει να ξεκινά με `oci://` και δεν πρέπει να περιέχει το basename ή το tag.\n\nΤο basename της αναφοράς στο registry εξάγεται από το όνομα του chart, και το tag εξάγεται από τη σημασιολογική έκδοση του chart. Αυτή είναι προς το παρόν αυστηρή απαίτηση.\n\nΟρισμένα registries απαιτούν το repository ή/και το namespace (αν υπάρχει) να δημιουργηθεί εκ των προτέρων. Διαφορετικά, θα εμφανιστεί σφάλμα κατά την εκτέλεση του `helm push`.\n\nΑν έχετε δημιουργήσει [αρχείο προέλευσης](/topics/provenance.md) (`.prov`) και βρίσκεται δίπλα στο αρχείο `.tgz` του chart, θα αποσταλεί αυτόματα στο registry κατά το `push`. Αυτό προσθέτει ένα επιπλέον επίπεδο στο [manifest του Helm chart](#helm-chart-manifest).\n\nΟι χρήστες του [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`.\n\n### Άλλες Υποεντολές {#other-subcommands}\n\nΗ υποστήριξη για το πρωτόκολλο `oci://` είναι διαθέσιμη και σε άλλες υποεντολές. Ακολουθεί η πλήρης λίστα:\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nΤο basename (όνομα chart) της αναφοράς στο registry *συμπεριλαμβάνεται* σε κάθε ενέργεια που περιλαμβάνει λήψη chart (σε αντίθεση με το `helm push` όπου παραλείπεται).\n\nΑκολουθούν μερικά παραδείγματα χρήσης των παραπάνω υποεντολών με charts OCI:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml {#source-mycharttemplatesserviceaccountyaml}\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Εγκατάσταση Charts με Digest {#installing-charts-with-digest}\n\nΗ εγκατάσταση chart με digest είναι πιο ασφαλής από τη χρήση tag, επειδή τα digests είναι αμετάβλητα. Το digest καθορίζεται στο URI του chart:\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## Καθορισμός Εξαρτήσεων {#specifying-dependencies}\n\nΜπορείτε να λάβετε εξαρτήσεις ενός chart από registry χρησιμοποιώντας την υποεντολή `dependency update`.\n\nΤο `repository` για μια καταχώρηση στο `Chart.yaml` καθορίζεται ως η αναφορά στο registry χωρίς το basename:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\nΑυτό θα ανακτήσει το `oci://localhost:5000/myrepo/mychart:2.7.0` κατά την εκτέλεση του `dependency update`.\n\n## Manifest Helm Chart {#helm-chart-manifest}\n\nΠαράδειγμα manifest Helm chart όπως αναπαρίσταται σε registry\n(σημειώστε τα πεδία `mediaType`):\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nΤο ακόλουθο παράδειγμα περιέχει [αρχείο προέλευσης](/topics/provenance.md)\n(σημειώστε το επιπλέον επίπεδο):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Μετάβαση από Αποθετήρια Chart {#migrating-from-chart-repos}\n\nΗ μετάβαση από κλασικά [αποθετήρια chart](/topics/chart_repository.md)\n(αποθετήρια με index.yaml) είναι απλή: χρησιμοποιήστε το `helm pull` για λήψη και στη συνέχεια το `helm push` για αποστολή των αρχείων `.tgz` σε ένα registry.\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: Μετάβαση από Helm v2 σε v3\ndescription: Μάθετε πώς να μεταβείτε από το Helm v2 στο v3.\nsidebar_position: 13\n---\n\nΑυτός ο οδηγός δείχνει πώς να μεταβείτε από το Helm v2 στο v3. Το Helm v2 πρέπει να\nείναι εγκατεστημένο και να διαχειρίζεται releases σε ένα ή περισσότερα clusters.\n\n## Επισκόπηση Αλλαγών στο Helm 3 {#overview-of-helm-3-changes}\n\nΗ πλήρης λίστα αλλαγών από το Helm 2 στο 3 είναι τεκμηριωμένη στην ενότητα\n[FAQ](/faq/changes_since_helm2.md). Ακολουθεί μια σύνοψη κάποιων\nαπό αυτές τις αλλαγές που ο χρήστης πρέπει να γνωρίζει πριν και κατά τη μετάβαση:\n\n1. Κατάργηση του Tiller:\n   - Αντικατάσταση της αρχιτεκτονικής client/server με αρχιτεκτονική client/library\n     (μόνο το `helm` binary)\n   - Η ασφάλεια βασίζεται πλέον σε κάθε χρήστη ξεχωριστά (ανατίθεται στην ασφάλεια\n     του Kubernetes cluster ανά χρήστη)\n   - Τα releases αποθηκεύονται πλέον ως secrets εντός του cluster και τα\n     μεταδεδομένα του release object έχουν αλλάξει\n   - Τα releases παραμένουν με βάση το namespace του release και όχι πλέον στο\n     namespace του Tiller\n2. Ενημέρωση του chart repository:\n   - Η εντολή `helm search` υποστηρίζει πλέον αναζητήσεις τόσο σε τοπικά repositories\n     όσο και ερωτήματα αναζήτησης στο Artifact Hub\n3. Αναβάθμιση του chart apiVersion σε \"v2\" για τις ακόλουθες αλλαγές προδιαγραφών:\n   - Οι δυναμικά συνδεδεμένες εξαρτήσεις chart μεταφέρθηκαν στο `Chart.yaml`\n     (το `requirements.yaml` καταργήθηκε και requirements --> dependencies)\n   - Τα library charts (helper/common charts) μπορούν πλέον να προστεθούν ως\n     δυναμικά συνδεδεμένες εξαρτήσεις chart\n   - Τα charts έχουν ένα πεδίο μεταδεδομένων `type` για να ορίσουν αν το chart είναι\n     τύπου `application` ή `library`. Η προεπιλογή είναι application, που σημαίνει\n     ότι είναι δυνατή η απεικόνιση (render) και η εγκατάστασή του\n   - Τα Helm 2 charts (apiVersion=v1) εξακολουθούν να είναι εγκαταστάσιμα\n4. Προσθήκη προδιαγραφής καταλόγων XDG:\n   - Το Helm home καταργήθηκε και αντικαταστάθηκε με την προδιαγραφή καταλόγων XDG\n     για την αποθήκευση αρχείων ρυθμίσεων\n   - Δεν χρειάζεται πλέον αρχικοποίηση του Helm\n   - Οι εντολές `helm init` και `helm home` καταργήθηκαν\n5. Επιπλέον αλλαγές:\n   - Η εγκατάσταση/ρύθμιση του Helm απλοποιήθηκε:\n     - Μόνο το Helm client (helm binary) (χωρίς Tiller)\n     - Λειτουργεί αυτόνομα χωρίς ρύθμιση\n   - Τα `local` ή `stable` repositories δεν ρυθμίζονται πλέον από προεπιλογή\n   - Το hook `crd-install` καταργήθηκε και αντικαταστάθηκε με τον κατάλογο `crds`\n     στο chart, όπου όλα τα CRDs που ορίζονται σε αυτόν θα εγκαθίστανται πριν από\n     οποιαδήποτε απεικόνιση του chart\n   - Η τιμή annotation `test-failure` του hook καταργήθηκε, και η `test-success`\n     έχει καταργηθεί. Χρησιμοποιήστε το `test` αντί αυτού\n   - Εντολές που καταργήθηκαν/αντικαταστάθηκαν/προστέθηκαν:\n       - delete --> uninstall : αφαιρεί όλο το ιστορικό release από προεπιλογή\n         (προηγουμένως απαιτούσε `--purge`)\n       - fetch --> pull\n       - home (καταργήθηκε)\n       - init (καταργήθηκε)\n       - install: απαιτεί όνομα release ή το όρισμα `--generate-name`\n       - inspect --> show\n       - reset (καταργήθηκε)\n       - serve (καταργήθηκε)\n       - template: το όρισμα `-x`/`--execute` μετονομάστηκε σε `-s`/`--show-only`\n       - upgrade: Προστέθηκε το όρισμα `--history-max` που περιορίζει τον μέγιστο\n         αριθμό αναθεωρήσεων που αποθηκεύονται ανά release (0 για χωρίς όριο)\n   - Η βιβλιοθήκη Go του Helm 3 έχει υποστεί πολλές αλλαγές και είναι ασύμβατη με\n     τη βιβλιοθήκη του Helm 2\n   - Τα release binaries φιλοξενούνται πλέον στο `get.helm.sh`\n\n## Περιπτώσεις Χρήσης Μετάβασης {#migration-use-cases}\n\nΟι περιπτώσεις χρήσης για τη μετάβαση είναι οι εξής:\n\n1. Το Helm v2 και v3 διαχειρίζονται το ίδιο cluster:\n   - Αυτή η περίπτωση χρήσης συνιστάται μόνο αν σκοπεύετε να αποσύρετε σταδιακά το\n     Helm v2 και δεν απαιτείτε το v3 να διαχειρίζεται releases που έχουν εγκατασταθεί\n     με το v2. Όλα τα νέα releases πρέπει να εγκαθίστανται με το v3 και τα υπάρχοντα\n     releases που εγκαταστάθηκαν με το v2 πρέπει να ενημερώνονται/αφαιρούνται μόνο\n     με το v2\n   - Το Helm v2 και v3 μπορούν να διαχειριστούν το ίδιο cluster χωρίς προβλήματα.\n     Οι εκδόσεις του Helm μπορούν να εγκατασταθούν στο ίδιο ή σε διαφορετικά συστήματα\n   - Αν εγκαθιστάτε το Helm v3 στο ίδιο σύστημα, πρέπει να εκτελέσετε ένα επιπλέον\n     βήμα για να διασφαλίσετε ότι και οι δύο εκδόσεις client μπορούν να συνυπάρχουν\n     μέχρι να είστε έτοιμοι να αφαιρέσετε τον Helm v2 client. Μετονομάστε ή τοποθετήστε\n     το Helm v3 binary σε διαφορετικό φάκελο για να αποφύγετε συγκρούσεις\n   - Κατά τα άλλα δεν υπάρχουν συγκρούσεις μεταξύ των δύο εκδόσεων λόγω των\n     ακόλουθων διακρίσεων:\n     - Η αποθήκευση των release (ιστορικού) για τα v2 και v3 είναι ανεξάρτητη.\n       Οι αλλαγές περιλαμβάνουν τον πόρο Kubernetes για την αποθήκευση και τα\n       μεταδεδομένα του release object που περιέχονται στον πόρο. Τα releases θα\n       βρίσκονται επίσης σε namespace ανά χρήστη αντί να χρησιμοποιούν το namespace\n       του Tiller (για παράδειγμα, το προεπιλεγμένο namespace του Tiller στο v2 είναι\n       το kube-system). Το v2 χρησιμοποιεί \"ConfigMaps\" ή \"Secrets\" στο namespace\n       του Tiller και ιδιοκτησία `TILLER`. Το v3 χρησιμοποιεί \"Secrets\" στο namespace\n       του χρήστη και ιδιοκτησία `helm`. Τα releases είναι αυξητικά (incremental)\n       τόσο στο v2 όσο και στο v3\n     - Το μόνο πιθανό πρόβλημα θα ήταν αν ορίζονται πόροι Kubernetes εμβέλειας\n       cluster (π.χ. `clusterroles.rbac`) σε ένα chart. Η εγκατάσταση με το v3\n       θα αποτύγχανε ακόμα κι αν είναι μοναδικό στο namespace, καθώς οι πόροι θα\n       συγκρούονταν\n     - Η ρύθμιση του v3 δεν χρησιμοποιεί πλέον το `$HELM_HOME` και χρησιμοποιεί αντ'\n       αυτού την προδιαγραφή καταλόγων XDG. Δημιουργείται επίσης δυναμικά όταν\n       χρειάζεται. Επομένως είναι ανεξάρτητη από τη ρύθμιση του v2. Αυτό ισχύει\n       μόνο όταν και οι δύο εκδόσεις είναι εγκατεστημένες στο ίδιο σύστημα\n\n2. Μετάβαση από Helm v2 σε Helm v3:\n   - Αυτή η περίπτωση χρήσης ισχύει όταν θέλετε το Helm v3 να διαχειρίζεται\n     υπάρχοντα releases του Helm v2\n   - Πρέπει να σημειωθεί ότι ένας Helm v2 client:\n     - μπορεί να διαχειριστεί 1 έως πολλά Kubernetes clusters\n     - μπορεί να συνδεθεί σε 1 έως πολλές instances του Tiller για ένα cluster\n   - Αυτό σημαίνει ότι πρέπει να το λάβετε υπόψη κατά τη μετάβαση, καθώς τα releases\n     εγκαθίστανται σε clusters από τον Tiller και το namespace του. Επομένως πρέπει\n     να γνωρίζετε ότι η μετάβαση γίνεται για κάθε cluster και κάθε instance του Tiller\n     που διαχειρίζεται η instance του Helm v2 client\n   - Η συνιστώμενη διαδρομή μετάβασης δεδομένων είναι η ακόλουθη:\n     1. Δημιουργία αντιγράφου ασφαλείας των δεδομένων v2\n     2. Μετάβαση της ρύθμισης του Helm v2\n     3. Μετάβαση των releases του Helm v2\n     4. Όταν είστε βέβαιοι ότι το Helm v3 διαχειρίζεται όλα τα δεδομένα του Helm v2\n        (για όλα τα clusters και τις instances του Tiller της instance του Helm v2\n        client) όπως αναμένεται, τότε καθαρίστε τα δεδομένα του Helm v2\n   - Η διαδικασία μετάβασης είναι αυτοματοποιημένη από το plugin\n     [2to3](https://github.com/helm/helm-2to3) του Helm v3\n\n## Αναφορές {#reference}\n\n   - Plugin [2to3](https://github.com/helm/helm-2to3) του Helm v3\n   - [Άρθρο](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) στο blog\n     που εξηγεί τη χρήση του plugin `2to3` με παραδείγματα\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Πολιτική Υποστήριξης Εκδόσεων Helm\"\ndescription: \"Περιγράφει την πολιτική για τις εκδόσεις patch του Helm καθώς και τη μέγιστη διαφορά εκδόσεων που υποστηρίζεται μεταξύ Helm και Kubernetes.\"\n---\n\nΑυτό το έγγραφο περιγράφει τη μέγιστη διαφορά εκδόσεων που υποστηρίζεται μεταξύ\nHelm και Kubernetes.\n\n## Υποστηριζόμενες Εκδόσεις {#supported-versions}\n\nΟι εκδόσεις του Helm εκφράζονται ως `x.y.z`, όπου `x` είναι η κύρια έκδοση (major), `y` είναι\nη δευτερεύουσα έκδοση (minor) και `z` είναι η έκδοση patch, ακολουθώντας την ορολογία του\n[Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\nΗ ομάδα του Helm διατηρεί ένα release branch για την πιο πρόσφατη δευτερεύουσα έκδοση.\nΟι σχετικές διορθώσεις, συμπεριλαμβανομένων των διορθώσεων ασφαλείας, μεταφέρονται\n(cherry-pick) στο release branch, ανάλογα με τη σοβαρότητα και την εφικτότητα.\nΠερισσότερες λεπτομέρειες μπορείτε να βρείτε στην\n[πολιτική εκδόσεων του Helm](/community/release_policy).\n\n## Υποστηριζόμενη Διαφορά Εκδόσεων {#supported-version-skew}\n\nΌταν κυκλοφορεί μια νέα έκδοση του Helm, μεταγλωττίζεται με μια συγκεκριμένη\nδευτερεύουσα έκδοση του Kubernetes. Για παράδειγμα, το Helm 3.0.0 αλληλεπιδρά με το\nKubernetes χρησιμοποιώντας τον client του Kubernetes 1.16.2, επομένως είναι συμβατό\nμε το Kubernetes 1.16.\n\nΑπό το Helm 3 και μετά, θεωρείται ότι το Helm είναι συμβατό με εκδόσεις `n-3` του\nKubernetes έναντι του οποίου μεταγλωττίστηκε. Λόγω των αλλαγών του Kubernetes μεταξύ\nδευτερευουσών εκδόσεων, η πολιτική υποστήριξης του Helm 2 είναι ελαφρώς αυστηρότερη,\nυποθέτοντας συμβατότητα με εκδόσεις `n-1` του Kubernetes.\n\nΓια παράδειγμα, αν χρησιμοποιείτε μια έκδοση του Helm 3 που μεταγλωττίστηκε έναντι\nτων client APIs του Kubernetes 1.17, τότε θα πρέπει να είναι ασφαλής η χρήση με\nKubernetes 1.17, 1.16, 1.15 και 1.14. Αν χρησιμοποιείτε μια έκδοση του Helm 2 που\nμεταγλωττίστηκε έναντι των client APIs του Kubernetes 1.16, τότε θα πρέπει να είναι\nασφαλής η χρήση με Kubernetes 1.16 και 1.15.\n\nΔεν συνιστάται η χρήση του Helm με έκδοση Kubernetes νεότερη από αυτήν έναντι της\nοποίας μεταγλωττίστηκε, καθώς το Helm δεν παρέχει εγγυήσεις συμβατότητας προς τα εμπρός.\n\nΑν επιλέξετε να χρησιμοποιήσετε το Helm με μια έκδοση Kubernetes που το Helm δεν υποστηρίζει,\nτο κάνετε με δική σας ευθύνη.\n\nΑνατρέξτε στον παρακάτω πίνακα για να διαπιστώσετε ποια έκδοση του Helm είναι\nσυμβατή με το cluster σας.\n\n| Έκδοση Helm | Υποστηριζόμενες Εκδόσεις Kubernetes |\n|-------------|-------------------------------------|\n| 3.20.x      | 1.35.x - 1.32.x                     |\n| 3.19.x      | 1.34.x - 1.31.x                     |\n| 3.18.x      | 1.33.x - 1.30.x                     |\n| 3.17.x      | 1.32.x - 1.29.x                     |\n| 3.16.x      | 1.31.x - 1.28.x                     |\n| 3.15.x      | 1.30.x - 1.27.x                     |\n| 3.14.x      | 1.29.x - 1.26.x                     |\n| 3.13.x      | 1.28.x - 1.25.x                     |\n| 3.12.x      | 1.27.x - 1.24.x                     |\n| 3.11.x      | 1.26.x - 1.23.x                     |\n| 3.10.x      | 1.25.x - 1.22.x                     |\n| 3.9.x       | 1.24.x - 1.21.x                     |\n| 3.8.x       | 1.23.x - 1.20.x                     |\n| 3.7.x       | 1.22.x - 1.19.x                     |\n| 3.6.x       | 1.21.x - 1.18.x                     |\n| 3.5.x       | 1.20.x - 1.17.x                     |\n| 3.4.x       | 1.19.x - 1.16.x                     |\n| 3.3.x       | 1.18.x - 1.15.x                     |\n| 3.2.x       | 1.18.x - 1.15.x                     |\n| 3.1.x       | 1.17.x - 1.14.x                     |\n| 3.0.x       | 1.16.x - 1.13.x                     |\n| 2.16.x      | 1.16.x - 1.15.x                     |\n| 2.15.x      | 1.15.x - 1.14.x                     |\n| 2.14.x      | 1.14.x - 1.13.x                     |\n| 2.13.x      | 1.13.x - 1.12.x                     |\n| 2.12.x      | 1.12.x - 1.11.x                     |\n| 2.11.x      | 1.11.x - 1.10.x                     |\n| 2.10.x      | 1.10.x - 1.9.x                      |\n| 2.9.x       | 1.10.x - 1.9.x                      |\n| 2.8.x       | 1.9.x - 1.8.x                       |\n| 2.7.x       | 1.8.x - 1.7.x                       |\n| 2.6.x       | 1.7.x - 1.6.x                       |\n| 2.5.x       | 1.6.x - 1.5.x                       |\n| 2.4.x       | 1.6.x - 1.5.x                       |\n| 2.3.x       | 1.5.x - 1.4.x                       |\n| 2.2.x       | 1.5.x - 1.4.x                       |\n| 2.1.x       | 1.5.x - 1.4.x                       |\n| 2.0.x       | 1.4.x - 1.3.x                       |\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"Εισαγωγή\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"Πώς να\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"Θέματα\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Καλές Πρακτικές\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"Οδηγός Προτύπων Chart\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Εντολές Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"Κοινότητα\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"Συχνές Ερωτήσεις\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/el/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: \"Πολιτική Χρονοδιαγράμματος Εκδόσεων\"\ndescription: \"Περιγράφει την πολιτική χρονοδιαγράμματος εκδόσεων του Helm.\"\n---\n\nΠρος όφελος των χρηστών, το Helm καθορίζει και ανακοινώνει ημερομηνίες εκδόσεων\nεκ των προτέρων. Αυτό το έγγραφο περιγράφει την πολιτική που διέπει το\nχρονοδιάγραμμα εκδόσεων του Helm.\n\n## Ημερολόγιο Εκδόσεων {#release-calendar}\n\nΈνα δημόσιο ημερολόγιο που δείχνει τις επερχόμενες εκδόσεις του Helm μπορείτε\nνα βρείτε [εδώ](https://helm.sh/calendar/release).\n\n## Σημασιολογική Αρίθμηση Εκδόσεων {#semantic-versioning}\n\nΟι εκδόσεις του Helm εκφράζονται ως `x.y.z`, όπου `x` είναι η κύρια έκδοση (major),\n`y` είναι η δευτερεύουσα έκδοση (minor) και `z` είναι η έκδοση patch, ακολουθώντας\nτην ορολογία του [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## Εκδόσεις Patch {#patch-releases}\n\nΟι εκδόσεις patch παρέχουν στους χρήστες διορθώσεις σφαλμάτων και διορθώσεις\nασφαλείας. Δεν περιέχουν νέες λειτουργίες.\n\nΜια νέα έκδοση patch για την πιο πρόσφατη δευτερεύουσα/κύρια έκδοση κυκλοφορεί\nσυνήθως μία φορά το μήνα, τη δεύτερη Τετάρτη κάθε μήνα.\n\nΜια έκδοση patch για τη διόρθωση ενός κρίσιμου regression ή ζητήματος ασφαλείας\nμπορεί να κυκλοφορήσει όποτε χρειαστεί.\n\nΜια έκδοση patch ακυρώνεται για οποιονδήποτε από τους ακόλουθους λόγους:\n- δεν υπάρχει νέο περιεχόμενο από την προηγούμενη έκδοση\n- η ημερομηνία της έκδοσης patch εμπίπτει εντός μίας εβδομάδας πριν από το\n  πρώτο release candidate (RC1) μιας επερχόμενης δευτερεύουσας έκδοσης\n- η ημερομηνία της έκδοσης patch εμπίπτει εντός τεσσάρων εβδομάδων μετά από\n  μια δευτερεύουσα έκδοση\n\n## Δευτερεύουσες Εκδόσεις {#minor-releases}\n\nΟι δευτερεύουσες εκδόσεις περιέχουν διορθώσεις ασφαλείας και σφαλμάτων καθώς και\nνέες λειτουργίες. Είναι συμβατές προς τα πίσω όσον αφορά το API και τη χρήση CLI.\n\nΓια ευθυγράμμιση με τις εκδόσεις του Kubernetes, μια δευτερεύουσα έκδοση του Helm\nκυκλοφορεί κάθε 4 μήνες (3 εκδόσεις ετησίως).\n\nΠρόσθετες δευτερεύουσες εκδόσεις μπορούν να κυκλοφορήσουν αν χρειαστεί, αλλά δεν\nεπηρεάζουν το χρονοδιάγραμμα μιας ανακοινωμένης μελλοντικής έκδοσης, εκτός αν η\nανακοινωμένη έκδοση απέχει λιγότερο από 7 ημέρες.\n\nΤαυτόχρονα με τη δημοσίευση μιας έκδοσης, ανακοινώνεται η ημερομηνία της επόμενης\nδευτερεύουσας έκδοσης και αναρτάται στην κύρια ιστοσελίδα του Helm.\n\n## Κύριες Εκδόσεις {#major-releases}\n\nΟι κύριες εκδόσεις περιέχουν breaking changes. Τέτοιες εκδόσεις είναι σπάνιες,\nαλλά μερικές φορές απαραίτητες ώστε το Helm να συνεχίσει να εξελίσσεται προς\nσημαντικές νέες κατευθύνσεις.\n\nΟι κύριες εκδόσεις μπορεί να είναι δύσκολο να προγραμματιστούν. Με αυτό υπόψη,\nμια τελική ημερομηνία έκδοσης επιλέγεται και ανακοινώνεται μόνο αφού γίνει\nδιαθέσιμη η πρώτη beta έκδοση.\n"
  },
  {
    "path": "i18n/el/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Έργο Helm\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"Ανάπτυξη\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"Κοινότητα\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"Πηγαίος κώδικας\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"Ιστολόγιο\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"Εκδηλώσεις\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"Κώδικας Δεοντολογίας\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"Εισαγωγή\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Συμβουλές & κόλπα για Charts\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"Ανάπτυξη Charts\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"Αναζήτηση 800+ Charts\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"Οδηγός Συνεισφοράς\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"Συντηρητές\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"Εβδομαδιαίες Συναντήσεις\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"Κοινότητα GitHub\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<a href=\\\"https://www.cncf.io/\\\">Είμαστε ένα graduated project του Cloud Native Computing Foundation.</a><br/>© Συγγραφείς Helm 2025. Η τεκμηρίωση διανέμεται υπό <a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0.</a><br/>© 2025 The Linux Foundation. Με επιφύλαξη παντός δικαιώματος. Το Linux Foundation διαθέτει εγγεγραμμένα εμπορικά σήματα και χρησιμοποιεί εμπορικά σήματα. Για λίστα των εμπορικών σημάτων του Linux Foundation, παρακαλούμε δείτε τη <a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">σελίδα Χρήσης Εμπορικών Σημάτων</a>.\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Λογότυπο CNCF\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/el/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Λογότυπο Helm\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"Τεκμηρίωση\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"Ιστολόγιο\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"Κοινότητα\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/es/code.json",
    "content": "{\n  \"home.about.whatIsHelm\": {\n    \"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.\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"message\": \"Los Charts son fáciles de crear, versionar, compartir y publicar — así que empieza a usar Helm y deja de copiar y pegar.\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Helm es un proyecto graduado en la {cncfLink} y es mantenido por la {helmCommunityLink}.\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"comunidad de Helm\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"Aprende más:\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Arquitectura de Helm\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"Guía de Inicio Rápido\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"Video: Una Introducción a Helm\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"¿Qué es Helm?\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"Próxima Liberación de Características\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"Versión:\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"Fecha:\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"Calendario de Lanzamientos\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"Próximos Eventos\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"Próximos Eventos\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"Eventos Pasados\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"{meetLink} para demostrar y discutir herramientas y proyectos. Las reuniones de la comunidad son grabadas y {youtubeLink}.\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"Se reúnen cada semana\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"compartidas en YouTube\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"Standups para desarrolladores\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"Jueves 9:30-10am (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"Estas reuniones están abiertas a todos. Consulta el {communityRepoLink} para notas y detalles.\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"repositorio de la comunidad\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Discusión sobre el uso de Helm, trabajar con charts y resolver errores comunes.\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Temas relacionados con el desarrollo de Helm, PRs en curso, lanzamientos, etc.\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Discusión para usuarios y colaboradores de Helm Charts.\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"{slackLink} para unirse al equipo de Slack de Kubernetes.\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"Solicita acceso aquí\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"Contribuir\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"¡Helm siempre da la bienvenida a nuevas contribuciones al proyecto!\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"¿Por dónde empezar?\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Helm es un gran proyecto con muchos usuarios y colaboradores. ¡Puede ser mucho para asimilar!\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"Tenemos una lista de {goodFirstIssuesLink} si quieres ayudar pero no sabes por dónde empezar.\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"buenos primeros tickets\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"¿Qué debo hacer?\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"Antes de contribuir con código, por favor lee nuestra {contributionGuideLink}. Cubre los procesos para crear y revisar pull requests.\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"Guía de Contribución\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"Después de escribir código, por favor {signYourCommitsLink} para asegurar que Helm cumpla con el acuerdo {dcoLink} utilizado por la {cncfLink}.\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"firma tus commits\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"Únete a la Comunidad\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Más información sobre el proyecto Helm y cómo contribuir.\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"Administra la Complejidad\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"message\": \"Los Charts describen incluso las aplicaciones más complejas, proporcionan instalación de aplicaciones repetible y sirven como un único punto de autoridad.\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"Actualizaciones Fáciles\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"Elimina el dolor de las actualizaciones con upgrades en el lugar y hooks personalizados.\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"Uso Compartido Simple\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"Los Charts son fáciles de versionar, compartir y alojar en servidores públicos o privados.\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"Retrocesos\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"Usa {helmRollback} para revertir a una versión anterior de un lanzamiento con facilidad.\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"Características\",\n    \"description\": \"Features section title\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"Comenzar\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"Obtener Helm!\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"Instala Helm con un gestor de paquetes, o {downloadLink}.\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"descarga un binario\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"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}.\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"documentación\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"instalación\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"instrucciones de uso\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"Obtener Charts\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"Visita {artifactHubLink} para explorar {helmChartsLink} de numerosos repositorios públicos.\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"Helm charts\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"El gestor de paquetes para Kubernetes\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Helm es la mejor manera de encontrar, compartir y usar software construido para\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"Esta página ha fallado.\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"Volver al principio\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"Archivo\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"Archivo\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"Navegación por la página de la lista de blogs \",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"Entradas más recientes\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"Entradas más antiguas\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"Barra de paginación de publicaciones del blog\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"Publicación más reciente\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"Publicación más antigua\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"Ver Todas las Etiquetas\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"modo sistema\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"modo claro\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"modo oscuro\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"Cambiar entre modo oscuro y claro (actualmente {mode})\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"Rastro de navegación\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"1 artículo|{count} artículos\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"Página del documento\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"Anterior\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"Siguiente\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"Esta es la documentación sin publicar para {siteTitle}, versión {versionLabel}.\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"Esta es la documentación para {siteTitle} {versionLabel}, que ya no se mantiene activamente.\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"Para la documentación actualizada, vea {latestVersionLink} ({versionLabel}).\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"última versión\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"Un documento etiquetado|{count} documentos etiquetados\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged} con \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"Version: {versionLabel}\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"Enlace directo al {heading}\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"Editar esta página\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \" en {date}\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \" por {user}\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"Última actualización{atDate}{byUser}\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"Página No Encontrada\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"Versiones\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"Etiquetas:\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"Cerrar\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"precaución\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"peligro\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"info\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"nota\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"tip\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"aviso\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"Navegación de publicaciones recientes\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"Ampliar la categoría '{label}' de la barra lateral\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"Colapsar categoría '{label}' de la barra lateral\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(se abre en una nueva pestaña)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"Principal\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"No pudimos encontrar lo que buscaba.\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"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.\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"Idiomas\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"En esta página\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"Lectura de un minuto|{readingTime} min de lectura\",\n    \"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)\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"Leer Más\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"Leer más acerca de {title}\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"Copiar\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"Copiado\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"Copiar código\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"Alternar ajuste de palabras\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"Página de Inicio\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"Barra lateral de Documentos\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"Colapsar barra lateral\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"Colapsar barra lateral\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"Cerrar barra de lateral\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← Volver al menú principal\",\n    \"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)\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"Alternar barra lateral\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"Expandir el menú desplegable\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"Colapsar el menú desplegable\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"Expandir barra lateral\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"Expandir barra lateral\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"Una publicación|{count} publicaciones\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"{nPosts} etiquetados con \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"Autores\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"Ver Todos los Autores\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"Este autor aún no ha escrito ninguna publicación.\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"Página sin clasificar\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"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.\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"Página borrador\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"Esta página es un borrador. Solo será visible en desarrollo y se excluirá de la compilación de producción.\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"Intente de nuevo\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"Saltar al contenido principal\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"Etiquetas\",\n    \"description\": \"The title of the tag list page\"\n  },\n  \"theme.blog.list.pageTitle\": {\n    \"message\": \"Blog\",\n    \"description\": \"The word 'Blog' in breadcrumbs\"\n  }\n}\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Blog\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"Blog\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"Todas las publicaciones\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Usando Helm\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Comandos de Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"Desarrollando Plantillas\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Mejores Prácticas\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: Convenciones Generales\ndescription: Convenciones generales para charts.\nsidebar_position: 1\n---\n\nEsta parte de la Guía de Mejores Prácticas explica las convenciones generales.\n\n## Nombres de Charts\n\nLos nombres de los charts deben ser letras minúsculas y números. Las palabras\n_pueden_ separarse con guiones (-):\n\nEjemplos:\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nNo se pueden usar letras mayúsculas ni guiones bajos en los nombres de charts.\nLos puntos no deben usarse en los nombres de charts.\n\n## Números de Versión\n\nSiempre que sea posible, Helm usa [SemVer 2](https://semver.org) para representar\nnúmeros de versión. (Tenga en cuenta que las etiquetas de imágenes de Docker no\nnecesariamente siguen SemVer, y por lo tanto se consideran una desafortunada\nexcepción a la regla.)\n\nCuando las versiones SemVer se almacenan en etiquetas de Kubernetes, convencionalmente\nse cambia el carácter `+` por un carácter `_`, ya que las etiquetas no permiten el\nsigno `+` como valor.\n\n## Formato de YAML\n\nLos archivos YAML deben indentarse usando _dos espacios_ (y nunca tabulaciones).\n\n## Uso de las Palabras Helm y Chart\n\nExisten algunas convenciones para el uso de las palabras _Helm_ y _helm_.\n\n- _Helm_ se refiere al proyecto en su totalidad\n- `helm` se refiere al comando del lado del cliente\n- El término `chart` no necesita ser capitalizado, ya que no es un nombre propio\n- Sin embargo, `Chart.yaml` sí necesita ser capitalizado porque el nombre del\n  archivo distingue entre mayúsculas y minúsculas\n\nCuando tenga dudas, use _Helm_ (con 'H' mayúscula).\n\n## Plantillas de Chart y Namespace\n\nEvite definir la propiedad `namespace` en la sección `metadata` de sus plantillas\nde chart. El namespace para aplicar las plantillas renderizadas debe especificarse\nen la llamada a un cliente de Kubernetes mediante un flag como `--namespace`.\nHelm renderiza sus plantillas tal cual y las envía al cliente de Kubernetes, ya\nsea Helm mismo u otro programa (kubectl, flux, spinnaker, etc).\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Custom Resource Definitions\ndescription: Cómo manejar la creación y uso de CRDs.\nsidebar_position: 7\n---\n\nEsta sección de la Guía de Mejores Prácticas trata sobre la creación y uso de\nobjetos Custom Resource Definition.\n\nAl trabajar con Custom Resource Definitions (CRDs), es importante distinguir\ndos partes diferentes:\n\n- Existe una declaración de un CRD. Este es el archivo YAML que tiene el kind\n  `CustomResourceDefinition`\n- Luego existen recursos que _usan_ el CRD. Por ejemplo, un CRD define\n  `foo.example.com/v1`. Cualquier recurso que tenga `apiVersion: example.com/v1`\n  y kind `Foo` es un recurso que usa el CRD.\n\n## Instalar una Declaración de CRD Antes de Usar el Recurso\n\nHelm está optimizado para cargar tantos recursos en Kubernetes tan rápido como\nsea posible. Por diseño, Kubernetes puede tomar un conjunto completo de\nmanifiestos y ponerlos todos en línea (esto se llama el ciclo de reconciliación).\n\nPero hay una diferencia con los CRDs.\n\nPara un CRD, la declaración debe registrarse antes de que se puedan usar\nrecursos de ese tipo de CRD. Y el proceso de registro a veces tarda unos\nsegundos.\n\n### Método 1: Deje que `helm` lo Haga por Usted\n\nCon la llegada de Helm 3, eliminamos los antiguos hooks `crd-install` por una\nmetodología más simple. Ahora hay un directorio especial llamado `crds` que\npuede crear en su chart para contener sus CRDs. Estos CRDs no son plantillas,\npero se instalarán por defecto al ejecutar `helm install` para el chart. Si el\nCRD ya existe, se omitirá con una advertencia. Si desea omitir el paso de\ninstalación de CRD, puede pasar el flag `--skip-crds`.\n\n#### Algunas advertencias (y explicaciones)\n\nActualmente no hay soporte para actualizar o eliminar CRDs usando Helm. Esta\nfue una decisión explícita después de mucha discusión en la comunidad debido\nal peligro de pérdida de datos no intencional. Además, actualmente no hay\nconsenso en la comunidad sobre cómo manejar los CRDs y su ciclo de vida. A\nmedida que esto evolucione, Helm añadirá soporte para esos casos de uso.\n\nEl flag `--dry-run` de `helm install` y `helm upgrade` actualmente no es\ncompatible con CRDs. El propósito de \"Dry Run\" es validar que la salida del\nchart realmente funcionará si se envía al servidor. Pero los CRDs son una\nmodificación del comportamiento del servidor. Helm no puede instalar el CRD en\nun dry run, por lo que el cliente de descubrimiento no conocerá ese Custom\nResource (CR), y la validación fallará. Alternativamente, puede mover los CRDs\na su propio chart o usar `helm template` en su lugar.\n\nOtro punto importante a considerar en la discusión sobre el soporte de CRDs es\ncómo se maneja el renderizado de plantillas. Una de las desventajas claras del\nmétodo `crd-install` usado en Helm 2 era la incapacidad de validar\ncorrectamente los charts debido a la disponibilidad cambiante de la API (un CRD\nen realidad está añadiendo otra API disponible a su clúster de Kubernetes). Si\nun chart instalaba un CRD, `helm` ya no tenía un conjunto válido de versiones\nde API con el cual trabajar. Esta es también la razón detrás de eliminar el\nsoporte de plantillas de los CRDs. Con el nuevo método `crds` de instalación de\nCRDs, ahora aseguramos que `helm` tenga información completamente válida sobre\nel estado actual del clúster.\n\n### Método 2: Charts Separados\n\nOtra forma de hacer esto es poner la definición del CRD en un chart, y luego\nponer cualquier recurso que use ese CRD en _otro_ chart.\n\nEn este método, cada chart debe instalarse por separado. Sin embargo, este\nflujo de trabajo puede ser más útil para operadores de clúster con acceso de\nadministrador.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: Dependencias\ndescription: Cubre las mejores prácticas para las dependencias de un Chart.\nsidebar_position: 4\n---\n\nEsta sección de la guía cubre las mejores prácticas para las `dependencies` declaradas\nen `Chart.yaml`.\n\n## Versiones\n\nCuando sea posible, use rangos de versión en lugar de fijar una versión exacta. El\nvalor predeterminado sugerido es usar una coincidencia a nivel de parche:\n\n```yaml\nversion: ~1.2.3\n```\n\nEsto coincidirá con la versión `1.2.3` y cualquier parche de esa release. En otras\npalabras, `~1.2.3` es equivalente a `>= 1.2.3, < 1.3.0`\n\nPara la sintaxis completa de coincidencia de versiones, consulte la [documentación\nde semver](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Versiones preliminares (Prerelease)\n\nLas restricciones de versión anteriores no coincidirán con versiones preliminares.\nPor ejemplo, `version: ~1.2.3` coincidirá con `version: ~1.2.4` pero no con\n`version: ~1.2.3-1`. La siguiente configuración permite coincidir tanto con versiones\npreliminares como a nivel de parche:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### URLs de Repositorio\n\nCuando sea posible, use URLs de repositorio `https://`. Como segunda opción, use `http://`.\n\nSi el repositorio se ha añadido al archivo de índice de repositorios, el nombre del\nrepositorio puede usarse como un alias de la URL. Use `alias:` o `@` seguido del\nnombre del repositorio.\n\nLas URLs de archivo (`file://...`) se consideran un \"caso especial\" para charts que\nse ensamblan mediante un pipeline de despliegue fijo.\n\nAl usar [plugins de descarga](/topics/plugins.md#downloader-plugins), el esquema de URL\nserá específico del plugin. Tenga en cuenta que un usuario del chart necesitará\ntener instalado un plugin que soporte el esquema para actualizar o construir la\ndependencia.\n\nHelm no puede realizar operaciones de gestión de dependencias cuando el campo\n`repository` se deja en blanco. En ese caso, Helm asumirá que la dependencia está\nen un subdirectorio de la carpeta `charts` con el mismo nombre que la propiedad\n`name` de la dependencia.\n\n## Condiciones y Etiquetas\n\nSe deben añadir condiciones o etiquetas a cualquier dependencia que _sea opcional_.\nTenga en cuenta que, por defecto, una `condition` es `true`.\n\nLa forma preferida de una condición es:\n\n```yaml\ncondition: somechart.enabled\n```\n\nDonde `somechart` es el nombre del chart de la dependencia.\n\nCuando múltiples subcharts (dependencias) juntos proporcionan una característica\nopcional o intercambiable, esos charts deben compartir las mismas etiquetas.\n\nPor ejemplo, si tanto `nginx` como `memcached` juntos proporcionan optimizaciones\nde rendimiento para la aplicación principal del chart, y se requiere que ambos\nestén presentes cuando esa característica está habilitada, entonces ambos deben\ntener una sección de etiquetas como esta:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nEsto permite a un usuario activar o desactivar esa característica con una sola etiqueta.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: Etiquetas y Anotaciones\ndescription: Cubre las mejores prácticas para usar etiquetas y anotaciones en su Chart.\nsidebar_position: 5\n---\n\nEsta parte de la Guía de Mejores Prácticas cubre las mejores prácticas para usar\netiquetas y anotaciones en su chart.\n\n## ¿Es una Etiqueta o una Anotación?\n\nUn elemento de metadatos debe ser una etiqueta bajo las siguientes condiciones:\n\n- Es utilizado por Kubernetes para identificar este recurso\n- Es útil exponerlo a los operadores con el propósito de consultar el sistema.\n\nPor ejemplo, sugerimos usar `helm.sh/chart: NAME-VERSION` como etiqueta para que\nlos operadores puedan encontrar convenientemente todas las instancias de un chart\nen particular.\n\nSi un elemento de metadatos no se usa para consultas, debe establecerse como una\nanotación en su lugar.\n\nLos hooks de Helm siempre son anotaciones.\n\n## Etiquetas Estándar\n\nLa siguiente tabla define etiquetas comunes que usan los charts de Helm. Helm\nen sí nunca requiere que una etiqueta particular esté presente. Las etiquetas\nmarcadas como REC son recomendadas, y _deberían_ colocarse en un chart para\nmantener consistencia global. Las marcadas como OPT son opcionales. Son idiomáticas\no de uso común, pero no se depende de ellas frecuentemente para propósitos\noperacionales.\n\n| Nombre | Estado | Descripción |\n|--------|--------|-------------|\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. |\n| `helm.sh/chart` | REC | Debe ser el nombre del chart y la versión: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`. |\n| `app.kubernetes.io/managed-by` | REC | Siempre debe establecerse como `{{ .Release.Service }}`. Sirve para encontrar todo lo gestionado por Helm. |\n| `app.kubernetes.io/instance` | REC | Debe ser `{{ .Release.Name }}`. Ayuda a diferenciar entre diferentes instancias de la misma aplicación. |\n| `app.kubernetes.io/version` | OPT | La versión de la aplicación, puede establecerse como `{{ .Chart.AppVersion }}`. |\n| `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`. |\n| `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. |\n\nPuede encontrar más información sobre las etiquetas de Kubernetes, con el prefijo\n`app.kubernetes.io`, en la [documentación de Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pods y PodTemplates\ndescription: Discute el formato de las secciones Pod y PodTemplate en los manifiestos de Chart.\nsidebar_position: 6\n---\n\nEsta parte de la Guía de Mejores Prácticas discute el formato de las secciones\nPod y PodTemplate en los manifiestos de chart.\n\nLa siguiente lista (no exhaustiva) de recursos utilizan PodTemplates:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Imágenes\n\nUna imagen de contenedor debe usar un tag fijo o el SHA de la imagen. No debe\nusar los tags `latest`, `head`, `canary`, u otros tags diseñados para ser\n_flotantes_.\n\nLas imágenes _pueden_ definirse en el archivo `values.yaml` para facilitar el\ncambio de imágenes.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nUna imagen y un tag _pueden_ definirse en `values.yaml` como dos campos separados:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` establece el `imagePullPolicy` en `IfNotPresent` por defecto\nhaciendo lo siguiente en su `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nY en `values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nDe manera similar, Kubernetes establece por defecto el `imagePullPolicy` en\n`IfNotPresent` si no está definido. Si desea un valor diferente a `IfNotPresent`,\nsimplemente actualice el valor en `values.yaml` a su valor deseado.\n\n## Los PodTemplates Deben Declarar Selectores\n\nTodas las secciones de PodTemplate deben especificar un selector. Por ejemplo:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nEsta es una buena práctica porque establece claramente la relación entre el\nrecurso y el pod.\n\nPero esto es aún más importante para recursos como Deployment. Sin esto, se\nutiliza el conjunto _completo_ de etiquetas para seleccionar los pods\ncoincidentes, y esto causará problemas si usa etiquetas que cambian, como\nversión o fecha de lanzamiento.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: Control de Acceso Basado en Roles\ndescription: Discute la creación y formato de recursos RBAC en manifiestos de Charts.\nsidebar_position: 8\n---\n\nEsta parte de la Guía de Mejores Prácticas cubre la creación y formato de\nrecursos RBAC en manifiestos de charts.\n\nLos recursos RBAC son:\n\n- ServiceAccount (con namespace)\n- Role (con namespace)\n- ClusterRole\n- RoleBinding (con namespace)\n- ClusterRoleBinding\n\n## Configuración YAML\n\nLa configuración de RBAC y ServiceAccount debe realizarse bajo claves separadas.\nSon conceptos distintos. Separar estos dos conceptos en el YAML los desambigua\ny lo hace más claro.\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\nEsta estructura puede extenderse para charts más complejos que requieren\nmúltiples ServiceAccounts.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## Los Recursos RBAC Deben Crearse por Defecto\n\n`rbac.create` debe ser un valor booleano que controle si se crean los recursos\nRBAC. El valor por defecto debe ser `true`. Los usuarios que deseen gestionar\nlos controles de acceso RBAC por sí mismos pueden establecer este valor a `false`\n(en cuyo caso, consulte la sección siguiente).\n\n## Uso de Recursos RBAC\n\n`serviceAccount.name` debe establecerse con el nombre del ServiceAccount que\nusarán los recursos creados por el chart.\n\n- Si `serviceAccount.create` es true, se debe crear un ServiceAccount con este\n  nombre. Si el nombre no está establecido, se genera uno usando la plantilla\n  `fullname`.\n- Si `serviceAccount.create` es false, no se debe crear el ServiceAccount, pero\n  aún debe asociarse con los mismos recursos para que los recursos RBAC creados\n  manualmente posteriormente funcionen correctamente.\n- Si `serviceAccount.create` es false y el nombre no está especificado, se usa\n  el ServiceAccount por defecto.\n\nLa siguiente plantilla auxiliar puede usarse para el ServiceAccount.\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: Plantillas\ndescription: Mejores prácticas para trabajar con plantillas.\nsidebar_position: 3\n---\n\nEsta parte de la Guía de Mejores Prácticas se enfoca en plantillas.\n\n## Estructura de `templates/`\n\nEl directorio `templates/` debe estructurarse de la siguiente manera:\n\n- Los archivos de plantilla deben tener la extensión `.yaml` si producen salida\n  YAML. La extensión `.tpl` puede usarse para archivos de plantilla que no\n  producen contenido con formato.\n- Los nombres de archivos de plantilla deben usar notación con guiones\n  (`my-example-configmap.yaml`), no camelCase.\n- Cada definición de recurso debe estar en su propio archivo de plantilla.\n- Los nombres de archivos de plantilla deben reflejar el tipo de recurso en el\n  nombre, por ejemplo: `foo-pod.yaml`, `bar-svc.yaml`\n\n## Nombres de Plantillas Definidas\n\nLas plantillas definidas (plantillas creadas dentro de una directiva `{{ define }}`)\nson accesibles globalmente. Esto significa que un chart y todos sus subcharts\ntendrán acceso a todas las plantillas creadas con `{{ define }}`.\n\nPor esa razón, _todos los nombres de plantillas definidas deben incluir un prefijo\nde espacio de nombres (namespace)._\n\nCorrecto:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nIncorrecto:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\nSe recomienda encarecidamente que los nuevos charts se creen mediante el comando\n`helm create`, ya que los nombres de las plantillas se definen automáticamente\nsegún esta mejor práctica.\n\n## Formato de Plantillas\n\nLas plantillas deben indentarse usando _dos espacios_ (nunca tabulaciones).\n\nLas directivas de plantilla deben tener espacio en blanco después de las llaves\nde apertura y antes de las llaves de cierre:\n\nCorrecto:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nIncorrecto:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nLas plantillas deben recortar espacios en blanco donde sea posible:\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nLos bloques (como las estructuras de control) pueden indentarse para indicar el\nflujo del código de la plantilla.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nSin embargo, dado que YAML es un lenguaje orientado a espacios en blanco, a\nmenudo no es posible que la indentación del código siga esa convención.\n\n## Espacios en Blanco en Plantillas Generadas\n\nEs preferible mantener la cantidad de espacios en blanco en las plantillas\ngeneradas al mínimo. En particular, no deben aparecer numerosas líneas en blanco\nadyacentes entre sí. Pero líneas vacías ocasionales (particularmente entre\nsecciones lógicas) están bien.\n\nEsto es lo mejor:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nEsto está bien:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nPero esto debe evitarse:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Comentarios (Comentarios YAML vs. Comentarios de Plantilla)\n\nTanto YAML como las plantillas de Helm tienen marcadores de comentarios.\n\nComentarios YAML:\n```yaml\n# Esto es un comentario\ntype: sprocket\n```\n\nComentarios de Plantilla:\n```yaml\n{{- /*\nEsto es un comentario.\n*/}}\ntype: frobnitz\n```\n\nLos comentarios de plantilla deben usarse para documentar características de una\nplantilla, como explicar una plantilla definida:\n\n```yaml\n{{- /*\nmychart.shortname proporciona una versión truncada de 6 caracteres del nombre del release.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nDentro de las plantillas, los comentarios YAML pueden usarse cuando es útil que\nlos usuarios de Helm (posiblemente) vean los comentarios durante la depuración.\n\n```yaml\n# Esto puede causar problemas si el valor es mayor que 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nEl comentario anterior es visible cuando el usuario ejecuta `helm install --debug`,\nmientras que los comentarios especificados en secciones `{{- /* */}}` no lo son.\n\nTenga cuidado al agregar comentarios YAML `#` en secciones de plantilla que\ncontengan values de Helm que pueden ser requeridos por ciertas funciones de\nplantilla.\n\nPor ejemplo, si la función `required` se introduce en el ejemplo anterior y\n`maxMem` no está establecido, entonces un comentario YAML `#` introducirá un\nerror de renderizado.\n\nCorrecto: `helm template` no renderiza este bloque\n```yaml\n{{- /*\n# Esto puede causar problemas si el valor es mayor que 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nIncorrecto: `helm template` devuelve `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n```yaml\n# Esto puede causar problemas si el valor es mayor que 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nRevise [Depuración de Plantillas](../chart_template_guide/debugging.md) para\notro ejemplo de este comportamiento de cómo los comentarios YAML permanecen\nintactos.\n\n## Uso de JSON en Plantillas y Salida de Plantillas\n\nYAML es un superconjunto de JSON. En algunos casos, usar sintaxis JSON puede ser\nmás legible que otras representaciones YAML.\n\nPor ejemplo, este YAML está más cerca del método normal de YAML para expresar\nlistas:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nPero es más fácil de leer cuando se colapsa en un estilo de lista JSON:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nUsar JSON para mejorar la legibilidad es bueno. Sin embargo, la sintaxis JSON\nno debe usarse para representar estructuras más complejas.\n\nAl trabajar con JSON puro incrustado dentro de YAML (como la configuración de\ncontenedores init), es apropiado usar el formato JSON.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: Valores\ndescription: Se enfoca en cómo debe estructurar y usar sus values.\nsidebar_position: 2\n---\n\nEsta parte de la guía de mejores prácticas cubre el uso de values. En esta sección,\nofrecemos recomendaciones sobre cómo estructurar y usar sus values, con énfasis\nen el diseño del archivo `values.yaml` de un chart.\n\n## Convenciones de Nomenclatura\n\nLos nombres de variables deben comenzar con una letra minúscula y las palabras\ndeben separarse con camelCase:\n\nCorrecto:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nIncorrecto:\n\n```yaml\nChicken: true  # las mayúsculas iniciales pueden entrar en conflicto con las variables integradas\nchicken-noodle-soup: true # no use guiones en el nombre\n```\n\nTenga en cuenta que todas las variables integradas de Helm comienzan con una\nletra mayúscula para distinguirlas fácilmente de los values definidos por el\nusuario: `.Release.Name`, `.Capabilities.KubeVersion`.\n\n## Values Planos o Anidados\n\nYAML es un formato flexible, y los values pueden estar profundamente anidados\no ser planos.\n\nAnidado:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nPlano:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nEn la mayoría de los casos, se prefiere el formato plano sobre el anidado. Esto\nse debe a que es más simple para los desarrolladores de plantillas y los usuarios.\n\nPara una seguridad óptima, un value anidado debe verificarse en cada nivel:\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nPor cada nivel de anidamiento, se debe realizar una verificación de existencia.\nPero para la configuración plana, estas verificaciones pueden omitirse, haciendo\nla plantilla más fácil de leer y usar.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\nCuando hay una gran cantidad de variables relacionadas, y al menos una de ellas\nes requerida, los values anidados pueden usarse para mejorar la legibilidad.\n\n## Haga los Tipos Explícitos\n\nLas reglas de conversión de tipos de YAML a veces son poco intuitivas. Por ejemplo,\n`foo: false` no es lo mismo que `foo: \"false\"`. Los enteros grandes como\n`foo: 12345678` se convertirán a notación científica en algunos casos.\n\nLa forma más fácil de evitar errores de conversión de tipos es ser explícito con\nlas cadenas e implícito con todo lo demás. O, en resumen, _entrecomille todas\nlas cadenas_.\n\nA menudo, para evitar problemas de conversión de enteros, es ventajoso almacenar\nsus enteros como cadenas también, y usar `{{ int $value }}` en la plantilla para\nconvertir de cadena a entero.\n\nEn la mayoría de los casos, las etiquetas de tipo explícitas son respetadas, por\nlo que `foo: !!string 1234` tratará `1234` como una cadena. _Sin embargo_, el\nanalizador de YAML consume las etiquetas, por lo que la información de tipo se\npierde después de un análisis.\n\n## Considere Cómo los Usuarios Usarán sus Values\n\nHay tres fuentes potenciales de values:\n\n- El archivo `values.yaml` del chart\n- Un archivo values proporcionado por `helm install -f` o `helm upgrade -f`\n- Los values pasados con la opción `--set` o `--set-string` en `helm install` o\n  `helm upgrade`\n\nAl diseñar la estructura de sus values, tenga en cuenta que los usuarios de su\nchart pueden querer sobrescribirlos mediante la opción `-f` o con la opción `--set`.\n\nDado que `--set` es menos expresivo, la primera recomendación para escribir su\narchivo `values.yaml` es _facilitar la sobrescritura desde `--set`_.\n\nPor esta razón, a menudo es mejor estructurar su archivo values usando mapas.\n\nDifícil de usar con `--set`:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nLo anterior no puede expresarse con `--set` en Helm `<=2.4`. En Helm 2.5, acceder\nal puerto de foo es `--set servers[0].port=80`. No solo es más difícil para el\nusuario descubrirlo, sino que es propenso a errores si en algún momento posterior\nse cambia el orden de `servers`.\n\nFácil de usar:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nAcceder al puerto de foo es mucho más obvio: `--set servers.foo.port=80`.\n\n## Documente `values.yaml`\n\nCada propiedad definida en `values.yaml` debe documentarse. La cadena de\ndocumentación debe comenzar con el nombre de la propiedad que describe y luego\nproporcionar al menos una descripción de una oración.\n\nIncorrecto:\n\n```yaml\n# el nombre del host para el servidor web\nserverHost: example\nserverPort: 9191\n```\n\nCorrecto:\n\n```yaml\n# serverHost es el nombre del host para el servidor web\nserverHost: example\n# serverPort es el puerto de escucha HTTP para el servidor web\nserverPort: 9191\n```\n\nComenzar cada comentario con el nombre del parámetro que documenta facilita la\nbúsqueda de documentación con grep y permitirá que las herramientas de\ndocumentación correlacionen de manera confiable las cadenas de documentación\ncon los parámetros que describen.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Acceso a Archivos en las Plantillas\ndescription: Cómo acceder a archivos desde dentro de una plantilla.\nsidebar_position: 10\n---\n\nEn la sección anterior vimos varias formas de crear y acceder a plantillas con\nnombre. Esto facilita importar una plantilla desde dentro de otra plantilla.\nPero a veces es deseable importar un _archivo que no es una plantilla_ e\ninyectar su contenido sin enviarlo a través del renderizador de plantillas.\n\nHelm proporciona acceso a archivos a través del objeto `.Files`. Antes de\ncontinuar con los ejemplos de plantillas, hay algunas cosas que tener en cuenta\nsobre cómo funciona esto:\n\n- Puede agregar archivos adicionales a su chart de Helm. Estos archivos se\n  empaquetarán junto con el chart. Sin embargo, tenga cuidado: los charts deben\n  ser menores de 1M debido a las limitaciones de almacenamiento de los objetos\n  de Kubernetes.\n- No se puede acceder a algunos archivos a través del objeto `.Files`,\n  generalmente por razones de seguridad.\n  - No se puede acceder a los archivos en `templates/`.\n  - No se puede acceder a los archivos excluidos usando `.helmignore`.\n  - No se puede acceder a archivos fuera de un [subchart](./subcharts_and_globals.md) de una aplicación Helm, incluyendo los del padre.\n- Los charts no preservan la información del modo UNIX, por lo que los permisos\n  a nivel de archivo no tendrán impacto en la disponibilidad de un archivo\n  cuando se trata del objeto `.Files`.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Ejemplo básico](#ejemplo-básico)\n- [Helpers de ruta](#helpers-de-ruta)\n- [Patrones glob](#patrones-glob)\n- [Funciones de utilidad para ConfigMap y Secrets](#funciones-de-utilidad-para-configmap-y-secrets)\n- [Codificación](#codificación)\n- [Líneas](#líneas)\n\n<!-- tocstop -->\n\n## Ejemplo básico\n\nCon estas consideraciones en mente, escribamos una plantilla que lea tres\narchivos en nuestro ConfigMap. Para empezar, agregaremos tres archivos al chart,\ncolocando los tres directamente dentro del directorio `mychart/`.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nCada uno de estos es un archivo TOML simple (piense en los archivos INI de\nWindows antiguos). Conocemos los nombres de estos archivos, así que podemos usar\nuna función `range` para recorrerlos e inyectar su contenido en nuestro\nConfigMap.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nEste ConfigMap utiliza varias de las técnicas discutidas en secciones\nanteriores. Por ejemplo, creamos una variable `$files` para mantener una\nreferencia al objeto `.Files`. También usamos la función `tuple` para crear una\nlista de archivos que recorremos. Luego imprimimos cada nombre de archivo\n(`{{ . }}: |-`) seguido del contenido del archivo `{{ $files.Get . }}`.\n\nEjecutar esta plantilla producirá un único ConfigMap con el contenido de los\ntres archivos:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Helpers de ruta\n\nAl trabajar con archivos, puede ser muy útil realizar algunas operaciones\nestándar sobre las rutas de archivos. Para ayudar con esto, Helm importa muchas\nde las funciones del paquete [path](https://golang.org/pkg/path/) de Go para su\nuso. Todas son accesibles con los mismos nombres que en el paquete de Go, pero\ncon la primera letra en minúscula. Por ejemplo, `Base` se convierte en `base`,\netc.\n\nLas funciones importadas son:\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Patrones glob\n\nA medida que su chart crece, puede encontrar que tiene una mayor necesidad de\norganizar sus archivos, por lo que proporcionamos un método\n`Files.Glob(pattern string)` para ayudar a extraer ciertos archivos con toda la\nflexibilidad de los [patrones glob](https://godoc.org/github.com/gobwas/glob).\n\n`.Glob` devuelve un tipo `Files`, por lo que puede llamar a cualquiera de los\nmétodos de `Files` en el objeto devuelto.\n\nPor ejemplo, imagine la siguiente estructura de directorios:\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nTiene múltiples opciones con Globs:\n\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nO\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## Funciones de utilidad para ConfigMap y Secrets\n\n(Disponible en Helm 2.0.2 y posterior)\n\nEs muy común querer colocar el contenido de archivos tanto en ConfigMaps como en\nSecrets, para montarlos en sus pods en tiempo de ejecución. Para ayudar con\nesto, proporcionamos un par de métodos de utilidad en el tipo `Files`.\n\nPara una mayor organización, es especialmente útil usar estos métodos en\nconjunto con el método `Glob`.\n\nDada la estructura de directorios del ejemplo de [Glob](#patrones-glob)\nanterior:\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Codificación\n\nPuede importar un archivo y hacer que la plantilla lo codifique en base-64 para\nasegurar una transmisión exitosa:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nEl ejemplo anterior tomará el mismo archivo `config1.toml` que usamos antes y lo\ncodificará:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Líneas\n\nA veces es deseable acceder a cada línea de un archivo en su plantilla.\nProporcionamos un método conveniente `Lines` para esto.\n\nPuede recorrer `Lines` usando una función `range`:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nNo hay forma de pasar archivos externos al chart durante `helm install`. Por lo\ntanto, si está pidiendo a los usuarios que proporcionen datos, estos deben\ncargarse usando `helm install -f` o `helm install --set`.\n\nEsta discusión concluye nuestra inmersión en las herramientas y técnicas para\nescribir plantillas de Helm. En la siguiente sección veremos cómo puede usar un\narchivo especial, `templates/NOTES.txt`, para enviar instrucciones\npost-instalación a los usuarios de su chart.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Objetos Integrados\ndescription: Objetos integrados disponibles para las plantillas.\nsidebar_position: 3\n---\n\nEl motor de plantillas pasa los objetos a la plantilla. Su código también puede\npasar objetos (veremos ejemplos al usar las sentencias `with` y `range`).\nIncluso hay algunas formas de crear nuevos objetos dentro de sus plantillas,\ncomo con la función `tuple` que veremos más adelante.\n\nLos objetos pueden ser simples y contener un único valor. O pueden contener\notros objetos o funciones. Por ejemplo, el objeto `Release` contiene varios\nobjetos (como `Release.Name`) y el objeto `Files` tiene algunas funciones.\n\nEn la sección anterior, usamos `{{ .Release.Name }}` para insertar el nombre de\nun release en una plantilla. `Release` es uno de los objetos de nivel superior\na los que puede acceder en sus plantillas.\n\n- `Release`: Este objeto describe el release en sí. Tiene varios objetos dentro:\n  - `Release.Name`: El nombre del release\n  - `Release.Namespace`: El namespace donde se desplegará (si el manifiesto no\n    lo sobrescribe)\n  - `Release.IsUpgrade`: Se establece en `true` si la operación actual es una\n    actualización o rollback.\n  - `Release.IsInstall`: Se establece en `true` si la operación actual es una\n    instalación.\n  - `Release.Revision`: El número de revisión para este release. En la\n    instalación, es 1, y se incrementa con cada actualización y rollback.\n  - `Release.Service`: El servicio que está renderizando la plantilla actual.\n    En Helm, siempre es `Helm`.\n- `Values`: Valores pasados a la plantilla desde el archivo `values.yaml` y\n  desde archivos proporcionados por el usuario. Por defecto, `Values` está vacío.\n- `Chart`: El contenido del archivo `Chart.yaml`. Cualquier dato en `Chart.yaml`\n  será accesible aquí. Por ejemplo, `{{ .Chart.Name }}-{{ .Chart.Version }}`\n  imprimirá `mychart-0.1.0`.\n  - Los campos disponibles están listados en la [Guía de Charts](/topics/charts.md#the-chartyaml-file)\n- `Subcharts`: Proporciona acceso al scope (.Values, .Charts, .Releases, etc.)\n  de los subcharts desde el chart padre. Por ejemplo,\n  `.Subcharts.mySubChart.myValue` para acceder a `myValue` en el chart\n  `mySubChart`.\n- `Files`: Proporciona acceso a todos los archivos no especiales en un chart.\n  Aunque no puede usarlo para acceder a plantillas, puede usarlo para acceder a\n  otros archivos en el chart. Consulte la sección\n  [Acceso a Archivos](/chart_template_guide/accessing_files.md) para más\n  información.\n  - `Files.Get` es una función para obtener un archivo por nombre\n    (`.Files.Get config.ini`)\n  - `Files.GetBytes` es una función para obtener el contenido de un archivo\n    como un array de bytes en lugar de una cadena. Esto es útil para cosas como\n    imágenes.\n  - `Files.Glob` es una función que devuelve una lista de archivos cuyos\n    nombres coinciden con el patrón glob de shell dado.\n  - `Files.Lines` es una función que lee un archivo línea por línea. Esto es\n    útil para iterar sobre cada línea de un archivo.\n  - `Files.AsSecrets` es una función que devuelve los contenidos de los\n    archivos como cadenas codificadas en Base 64.\n  - `Files.AsConfig` es una función que devuelve los contenidos de los archivos\n    como un mapa YAML.\n- `Capabilities`: Proporciona información sobre las capacidades que soporta el\n  clúster de Kubernetes.\n  - `Capabilities.APIVersions` es un conjunto de versiones.\n  - `Capabilities.APIVersions.Has $version` indica si una versión (por ejemplo,\n    `batch/v1`) o recurso (por ejemplo, `apps/v1/Deployment`) está disponible\n    en el clúster.\n  - `Capabilities.KubeVersion` y `Capabilities.KubeVersion.Version` es la\n    versión de Kubernetes.\n  - `Capabilities.KubeVersion.Major` es la versión mayor de Kubernetes.\n  - `Capabilities.KubeVersion.Minor` es la versión menor de Kubernetes.\n  - `Capabilities.HelmVersion` es el objeto que contiene los detalles de la\n    versión de Helm, es la misma salida de `helm version`.\n  - `Capabilities.HelmVersion.Version` es la versión actual de Helm en formato\n    semver.\n  - `Capabilities.HelmVersion.GitCommit` es el sha1 de git de Helm.\n  - `Capabilities.HelmVersion.GitTreeState` es el estado del árbol git de Helm.\n  - `Capabilities.HelmVersion.GoVersion` es la versión del compilador Go\n    utilizado.\n- `Template`: Contiene información sobre la plantilla actual que se está\n  ejecutando\n  - `Template.Name`: Una ruta de archivo con namespace a la plantilla actual\n    (por ejemplo, `mychart/templates/mytemplate.yaml`)\n  - `Template.BasePath`: La ruta con namespace al directorio de plantillas del\n    chart actual (por ejemplo, `mychart/templates`).\n\nLos valores integrados siempre comienzan con una letra mayúscula. Esto sigue la\nconvención de nomenclatura de Go. Cuando cree sus propios nombres, puede usar la\nconvención que prefiera su equipo. Algunos equipos, como muchos cuyos charts\npuede ver en [Artifact Hub](https://artifacthub.io/packages/search?kind=0),\neligen usar solo letras minúsculas iniciales para distinguir los nombres locales\nde los integrados. En esta guía, seguimos esa convención.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Control de Flujo\ndescription: Una descripción rápida de la estructura de flujo dentro de las plantillas.\nsidebar_position: 7\n---\n\nLas estructuras de control (llamadas \"acciones\" en la terminología de plantillas)\nle permiten, como autor de plantillas, controlar el flujo de generación de una\nplantilla. El lenguaje de plantillas de Helm proporciona las siguientes\nestructuras de control:\n\n- `if`/`else` para crear bloques condicionales\n- `with` para especificar un ámbito\n- `range`, que proporciona un bucle de estilo \"for each\"\n\nAdemás de estas, proporciona algunas acciones para declarar y usar segmentos de\nplantilla con nombre:\n\n- `define` declara una nueva plantilla con nombre dentro de su plantilla\n- `template` importa una plantilla con nombre\n- `block` declara un tipo especial de área de plantilla rellenable\n\nEn esta sección, hablaremos sobre `if`, `with` y `range`. Los otros se cubren en\nla sección \"Plantillas con Nombre\" más adelante en esta guía.\n\n## If/Else\n\nLa primera estructura de control que veremos es para incluir condicionalmente\nbloques de texto en una plantilla. Este es el bloque `if`/`else`.\n\nLa estructura básica de un condicional se ve así:\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\nObserve que ahora estamos hablando de _pipelines_ en lugar de valores. Esto es\npara aclarar que las estructuras de control pueden ejecutar un pipeline\ncompleto, no solo evaluar un valor.\n\nUn pipeline se evalúa como _falso_ si el valor es:\n\n- un booleano falso\n- un cero numérico\n- una cadena vacía\n- un `nil` (vacío o nulo)\n- una colección vacía (`map`, `slice`, `tuple`, `dict`, `array`)\n\nEn todas las demás condiciones, la condición es verdadera.\n\nAgreguemos un condicional simple a nuestro ConfigMap. Añadiremos otra\nconfiguración si la bebida está establecida como coffee:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nComo comentamos `drink: coffee` en nuestro último ejemplo, la salida no debería\nincluir una bandera `mug: \"true\"`. Pero si agregamos esa línea de nuevo a\nnuestro archivo `values.yaml`, la salida debería verse así:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Control de Espacios en Blanco\n\nMientras observamos los condicionales, deberíamos echar un vistazo rápido a\ncómo se controlan los espacios en blanco en las plantillas. Tomemos el ejemplo\nanterior y formatémoslo para que sea un poco más fácil de leer:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nInicialmente, esto se ve bien. Pero si lo ejecutamos a través del motor de\nplantillas, obtendremos un resultado desafortunado:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\n¿Qué pasó? Generamos YAML incorrecto debido a los espacios en blanco anteriores.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` tiene una sangría incorrecta. Simplemente quitemos la sangría de esa línea\ny volvamos a ejecutar:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nCuando enviemos eso, obtendremos YAML válido, pero que todavía se ve un poco\nextraño:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nObserve que recibimos algunas líneas vacías en nuestro YAML. ¿Por qué? Cuando el\nmotor de plantillas se ejecuta, _elimina_ el contenido dentro de `{{` y `}}`,\npero deja el resto de los espacios en blanco exactamente como está.\n\nYAML asigna significado a los espacios en blanco, por lo que gestionar los\nespacios en blanco se vuelve bastante importante. Afortunadamente, las\nplantillas de Helm tienen algunas herramientas para ayudar.\n\nPrimero, la sintaxis de llaves de las declaraciones de plantilla se puede\nmodificar con caracteres especiales para indicar al motor de plantillas que\nrecorte los espacios en blanco. `{{- ` (con el guion y el espacio agregados)\nindica que se deben recortar los espacios en blanco a la izquierda, mientras que\n` -}}` significa que se deben consumir los espacios en blanco a la derecha.\n_¡Tenga cuidado! ¡Los saltos de línea también son espacios en blanco!_\n\n> Asegúrese de que haya un espacio entre el `-` y el resto de su directiva.\n> `{{- 3 }}` significa \"recortar espacios en blanco a la izquierda e imprimir 3\"\n> mientras que `{{-3 }}` significa \"imprimir -3\".\n\nUsando esta sintaxis, podemos modificar nuestra plantilla para eliminar esas\nnuevas líneas:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nPara ilustrar este punto, ajustemos lo anterior y sustituyamos un `*` por cada\nespacio en blanco que se eliminará siguiendo esta regla. Un `*` al final de la\nlínea indica un carácter de nueva línea que se eliminaría\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nTeniendo eso en cuenta, podemos ejecutar nuestra plantilla a través de Helm y\nver el resultado:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nTenga cuidado con los modificadores de recorte. Es fácil hacer accidentalmente\ncosas como esta:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nEso producirá `food: \"PIZZA\"mug: \"true\"` porque consume las nuevas líneas en\nambos lados.\n\n> Para obtener detalles sobre el control de espacios en blanco en plantillas,\n> consulte la [documentación oficial de plantillas de\n> Go](https://godoc.org/text/template)\n\nFinalmente, a veces es más fácil indicarle al sistema de plantillas cómo debe\naplicar la sangría en lugar de intentar dominar el espaciado de las directivas\nde plantilla. Por esa razón, puede que a veces le resulte útil usar la función\n`indent` (`{{ indent 2 \"mug:true\" }}`).\n\n## Modificar el ámbito usando `with`\n\nLa siguiente estructura de control a analizar es la acción `with`. Esta controla\nel ámbito de las variables. Recuerde que `.` es una referencia al _ámbito\nactual_. Por lo tanto, `.Values` le indica a la plantilla que busque el objeto\n`Values` en el ámbito actual.\n\nLa sintaxis de `with` es similar a una declaración `if` simple:\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\nLos ámbitos se pueden cambiar. `with` le permite establecer el ámbito actual\n(`.`) a un objeto particular. Por ejemplo, hemos estado trabajando con\n`.Values.favorite`. Reescribamos nuestro ConfigMap para alterar el ámbito `.`\npara que apunte a `.Values.favorite`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nTenga en cuenta que eliminamos el condicional `if` del ejercicio anterior porque\nahora es innecesario - el bloque después de `with` solo se ejecuta si el valor\nde `PIPELINE` no está vacío.\n\nObserve que ahora podemos hacer referencia a `.drink` y `.food` sin calificarlos.\nEsto se debe a que la declaración `with` establece `.` para que apunte a\n`.Values.favorite`. El `.` se restablece a su ámbito anterior después de\n`{{ end }}`.\n\nPero aquí hay una nota de precaución: Dentro del ámbito restringido, no podrá\nacceder a los otros objetos del ámbito padre usando `.`. Por ejemplo, esto\nfallará:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nProducirá un error porque `Release.Name` no está dentro del ámbito restringido\npara `.`. Sin embargo, si intercambiamos las dos últimas líneas, todo funcionará\ncomo se espera porque el ámbito se restablece después de `{{ end }}`.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nO bien, podemos usar `$` para acceder al objeto `Release.Name` desde el ámbito\npadre. `$` se asigna al ámbito raíz cuando comienza la ejecución de la plantilla\ny no cambia durante la ejecución de la misma. Lo siguiente también funcionaría:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nDespués de ver `range`, examinaremos las variables de plantilla, que ofrecen una\nsolución al problema de ámbito anterior.\n\n## Iterando con la acción `range`\n\nMuchos lenguajes de programación tienen soporte para iterar usando bucles `for`,\nbucles `foreach` o mecanismos funcionales similares. En el lenguaje de\nplantillas de Helm, la forma de iterar a través de una colección es usar el\noperador `range`.\n\nPara comenzar, agreguemos una lista de ingredientes de pizza a nuestro archivo\n`values.yaml`:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nAhora tenemos una lista (llamada `slice` en plantillas) de `pizzaToppings`.\nPodemos modificar nuestra plantilla para imprimir esta lista en nuestro\nConfigMap:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nPodemos usar `$` para acceder a la lista `Values.pizzaToppings` desde el ámbito\npadre. `$` se asigna al ámbito raíz cuando comienza la ejecución de la plantilla\ny no cambia durante la ejecución de la misma. Lo siguiente también funcionaría:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nExaminemos más de cerca la lista `toppings:`. La función `range` \"recorrerá\"\n(iterará a través de) la lista `pizzaToppings`. Pero ahora sucede algo\ninteresante. Al igual que `with` establece el ámbito de `.`, también lo hace un\noperador `range`. Cada vez que pasa por el bucle, `.` se establece en el\ningrediente de pizza actual. Es decir, la primera vez, `.` se establece en\n`mushrooms`. En la segunda iteración se establece en `cheese`, y así\nsucesivamente.\n\nPodemos enviar el valor de `.` directamente a través de un pipeline, así que\ncuando hacemos `{{ . | title | quote }}`, enviamos `.` a `title` (función de\ncapitalización de título) y luego a `quote`. Si ejecutamos esta plantilla, la\nsalida será:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nAhora, en este ejemplo hemos hecho algo ingenioso. La línea `toppings: |-`\ndeclara una cadena multilínea. Así que nuestra lista de ingredientes en realidad\nno es una lista YAML. Es una gran cadena. ¿Por qué haríamos esto? Porque los\ndatos en el campo `data` de ConfigMaps están compuestos por pares clave/valor,\ndonde tanto la clave como el valor son cadenas simples. Para entender por qué\neste es el caso, consulte la [documentación de ConfigMap de\nKubernetes](https://kubernetes.io/docs/concepts/configuration/configmap/).\nSin embargo, para nosotros, este detalle no importa mucho.\n\n> El marcador `|-` en YAML toma una cadena multilínea. Esta puede ser una técnica\n> útil para incrustar grandes bloques de datos dentro de sus manifiestos, como\n> se ejemplifica aquí.\n\nA veces es útil poder crear rápidamente una lista dentro de su plantilla y luego\niterar sobre esa lista. Las plantillas de Helm tienen una función para facilitar\nesto: `tuple`. En ciencias de la computación, una tupla es una colección similar\na una lista de tamaño fijo, pero con tipos de datos arbitrarios. Esto transmite\naproximadamente la forma en que se usa un `tuple`.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nLo anterior producirá esto:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nAdemás de listas y tuplas, `range` se puede usar para iterar sobre colecciones\nque tienen una clave y un valor (como un `map` o `dict`). Veremos cómo hacer\nesto en la siguiente sección cuando introduzcamos las variables de plantilla.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Apéndice: Tipos de datos de Go y plantillas\"\ndescription: Un resumen rápido sobre las variables en las plantillas.\nsidebar_position: 16\n---\n\nEl lenguaje de plantillas de Helm está implementado en Go, un lenguaje de\nprogramación fuertemente tipado. Por esta razón, las variables en las plantillas\ntienen _tipos_. En la mayoría de los casos, las variables se expondrán como uno\nde los siguientes tipos:\n\n- string: Una cadena de texto\n- bool: un valor `true` o `false`\n- int: Un valor entero (también existen variantes de 8, 16, 32 y 64 bits con y\n  sin signo)\n- float64: un valor de punto flotante de 64 bits (también existen variantes de\n  8, 16 y 32 bits)\n- un slice de bytes (`[]byte`), que se usa frecuentemente para almacenar datos\n  (potencialmente) binarios\n- struct: un objeto con propiedades y métodos\n- un slice (lista indexada) de cualquiera de los tipos anteriores\n- un map con claves de tipo string (`map[string]interface{}`) donde el valor es\n  cualquiera de los tipos anteriores\n\nExisten muchos otros tipos en Go, y a veces será necesario convertir entre ellos\nen las plantillas. La forma más fácil de depurar el tipo de un objeto es pasarlo\na través de `printf \"%T\"` en una plantilla, lo que imprimirá el tipo. También\npuede consultar las funciones `typeOf` y `kindOf`.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: Depuración de Plantillas\ndescription: Solución de problemas de charts que no se despliegan correctamente.\nsidebar_position: 13\n---\n\nLa depuración de plantillas puede ser complicada porque las plantillas renderizadas\nse envían al servidor de API de Kubernetes, que puede rechazar los archivos YAML\npor razones distintas al formato.\n\nHay algunos comandos que pueden ayudarle a depurar.\n\n- `helm lint` es su herramienta principal para verificar que su chart sigue las\n  mejores prácticas\n- `helm template --debug` permite probar el renderizado de las plantillas del chart\n  localmente.\n- `helm install --dry-run --debug` también renderizará su chart localmente sin\n  instalarlo, pero además verificará si hay recursos en conflicto que ya están\n  ejecutándose en el clúster. Usar `--dry-run=server` también ejecutará cualquier\n  `lookup` en su chart contra el servidor.\n- `helm get manifest`: Esta es una buena manera de ver qué plantillas están\n  instaladas en el servidor.\n\nCuando su YAML no se puede analizar, pero desea ver qué se genera, una forma\nfácil de recuperar el YAML es comentar la sección problemática en la plantilla,\ny luego volver a ejecutar `helm install --dry-run --debug`:\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\nLo anterior se renderizará y devolverá con los comentarios intactos:\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\nEsto proporciona una forma rápida de ver el contenido generado sin que los\nerrores de análisis de YAML interfieran.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: Lista de Funciones de Plantilla\ndescription: Una lista de funciones de plantilla disponibles en Helm\nsidebar_position: 6\n---\n\nHelm incluye muchas funciones de plantilla que puede aprovechar en sus plantillas.\nSe enumeran aquí y se desglosan en las siguientes categorías:\n\n* [Criptografía y Seguridad](#funciones-de-criptografía-y-seguridad)\n* [Fecha](#funciones-de-fecha)\n* [Diccionarios](#funciones-de-diccionarios-y-dict)\n* [Codificación](#funciones-de-codificación)\n* [Rutas de Archivos](#funciones-de-rutas-de-archivos)\n* [Kubernetes y Chart](#funciones-de-kubernetes-y-chart)\n* [Lógica y Control de Flujo](#funciones-de-lógica-y-control-de-flujo)\n* [Listas](#funciones-de-listas-y-list)\n* [Matemáticas](#funciones-matemáticas)\n* [Matemáticas de Punto Flotante](#funciones-matemáticas-de-punto-flotante)\n* [Red](#funciones-de-red)\n* [Reflexión](#funciones-de-reflexión)\n* [Expresiones Regulares](#expresiones-regulares)\n* [Versiones Semánticas](#funciones-de-versiones-semánticas)\n* [Cadenas](#funciones-de-cadenas)\n* [Conversión de Tipos](#funciones-de-conversión-de-tipos)\n* [URL](#funciones-de-url)\n* [UUID](#funciones-de-uuid)\n\n## Funciones de Lógica y Control de Flujo\n\nHelm incluye numerosas funciones de lógica y control de flujo incluyendo [and](#and),\n[coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq),\n[fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne),\n[not](#not), [or](#or), y [required](#required).\n\n### and\n\nDevuelve el AND booleano de dos o más argumentos\n(el primer argumento vacío, o el último argumento).\n\n```\nand .Arg1 .Arg2\n```\n\n### or\n\nDevuelve el OR booleano de dos o más argumentos\n(el primer argumento no vacío, o el último argumento).\n\n```\nor .Arg1 .Arg2\n```\n\n### not\n\nDevuelve la negación booleana de su argumento.\n\n```\nnot .Arg\n```\n\n### eq\n\nDevuelve la igualdad booleana de los argumentos (ej., Arg1 == Arg2).\n\n```\neq .Arg1 .Arg2\n```\n\n### ne\n\nDevuelve la desigualdad booleana de los argumentos (ej., Arg1 != Arg2)\n\n```\nne .Arg1 .Arg2\n```\n\n### lt\n\nDevuelve un booleano verdadero si el primer argumento es menor que el segundo. De lo contrario\ndevuelve falso (ej., Arg1 < Arg2).\n\n```\nlt .Arg1 .Arg2\n```\n\n### le\n\nDevuelve un booleano verdadero si el primer argumento es menor o igual que el\nsegundo. De lo contrario devuelve falso (ej., Arg1 <= Arg2).\n\n```\nle .Arg1 .Arg2\n```\n\n### gt\n\nDevuelve un booleano verdadero si el primer argumento es mayor que el segundo. De lo contrario\ndevuelve falso (ej., Arg1 > Arg2).\n\n```\ngt .Arg1 .Arg2\n```\n\n### ge\n\nDevuelve un booleano verdadero si el primer argumento es mayor o igual que el\nsegundo. De lo contrario devuelve falso (ej., Arg1 >= Arg2).\n\n```\nge .Arg1 .Arg2\n```\n\n### default\n\nPara establecer un valor por defecto simple, use `default`:\n\n```\ndefault \"foo\" .Bar\n```\n\nEn el ejemplo anterior, si `.Bar` evalúa a un valor no vacío, se usará ese valor. Pero si\nestá vacío, se devolverá `foo` en su lugar.\n\nLa definición de \"vacío\" depende del tipo:\n\n- Numérico: 0\n- Cadena: \"\"\n- Listas: `[]`\n- Diccionarios: `{}`\n- Booleano: `false`\n- Y siempre `nil` (también conocido como null)\n\nPara estructuras, no hay definición de vacío, por lo que una estructura nunca devolverá el\nvalor por defecto.\n\n### required\n\nEspecifique valores que deben establecerse con `required`:\n\n```\nrequired \"A valid foo is required!\" .Bar\n```\n\nSi `.Bar` está vacío o no está definido (consulte [default](#default) para saber cómo se\nevalúa), la plantilla no se renderizará y devolverá el mensaje de error\nproporcionado en su lugar.\n\n### empty\n\nLa función `empty` devuelve `true` si el valor dado se considera vacío, y\n`false` en caso contrario. Los valores vacíos se enumeran en la sección `default`.\n\n```\nempty .Foo\n```\n\nNote que en los condicionales de plantillas de Go, el vacío se calcula automáticamente. Por lo tanto,\nraramente necesitará `if not empty .Foo`. En su lugar, simplemente use `if .Foo`.\n\n### fail\n\nDevuelve incondicionalmente un `string` vacío y un `error` con el texto\nespecificado. Esto es útil en escenarios donde otras condiciones han determinado que\nel renderizado de la plantilla debe fallar.\n\n```\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\nLa función `coalesce` toma una lista de valores y devuelve el primer valor no vacío.\n\n```\ncoalesce 0 1 2\n```\n\nLo anterior devuelve `1`.\n\nEsta función es útil para recorrer múltiples variables o valores:\n\n```\ncoalesce .name .parent.name \"Matt\"\n```\n\nLo anterior primero verificará si `.name` está vacío. Si no lo está, devolverá\nese valor. Si _está_ vacío, `coalesce` evaluará `.parent.name` para verificar\nsi está vacío. Finalmente, si tanto `.name` como `.parent.name` están vacíos, devolverá\n`Matt`.\n\n### ternary\n\nLa función `ternary` toma dos valores y un valor de prueba. Si el valor de prueba es\nverdadero, se devolverá el primer valor. Si el valor de prueba está vacío, se devolverá\nel segundo valor. Esto es similar al operador ternario en C y otros lenguajes de programación.\n\n#### valor de prueba verdadero\n\n```\nternary \"foo\" \"bar\" true\n```\n\no\n\n```\ntrue | ternary \"foo\" \"bar\"\n```\n\nLo anterior devuelve `\"foo\"`.\n\n#### valor de prueba falso\n\n```\nternary \"foo\" \"bar\" false\n```\n\no\n\n```\nfalse | ternary \"foo\" \"bar\"\n```\n\nLo anterior devuelve `\"bar\"`.\n\n## Funciones de Cadenas\n\nHelm incluye las siguientes funciones de cadenas: [abbrev](#abbrev),\n[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat),\n[contains](#contains), [hasPrefix](#hasprefix-y-hassuffix),\n[hasSuffix](#hasprefix-y-hassuffix), [indent](#indent), [initials](#initials),\n[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent),\n[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf),\n[println](#println), [quote](#quote-y-squote),\n[randAlpha](#randalphanum-randalpha-randnumeric-y-randascii),\n[randAlphaNum](#randalphanum-randalpha-randnumeric-y-randascii),\n[randAscii](#randalphanum-randalpha-randnumeric-y-randascii),\n[randNumeric](#randalphanum-randalpha-randnumeric-y-randascii),\n[repeat](#repeat), [replace](#replace), [shuffle](#shuffle),\n[snakecase](#snakecase), [squote](#quote-y-squote), [substr](#substr),\n[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall),\n[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc),\n[untitle](#untitle), [upper](#upper), [wrap](#wrap), y [wrapWith](#wrapwith).\n\n### print\n\nDevuelve una cadena a partir de la combinación de sus partes.\n\n```\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\nLos tipos que no son cadenas se convierten a cadenas cuando es posible.\n\nNote que cuando dos argumentos adyacentes no son cadenas, se agrega un espacio\nentre ellos.\n\n### println\n\nFunciona de la misma manera que [print](#print) pero agrega una nueva línea al final.\n\n### printf\n\nDevuelve una cadena basada en una cadena de formato y los argumentos a pasar en\norden.\n\n```\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\nEl marcador de posición a usar depende del tipo del argumento que se pasa.\nEsto incluye:\n\nPropósito general:\n\n* `%v` el valor en formato por defecto\n  * al imprimir diccionarios, el flag plus (%+v) agrega nombres de campo\n* `%%` un signo de porcentaje literal; no consume ningún valor\n\nBooleano:\n\n* `%t` la palabra true o false\n\nEntero:\n\n* `%b` base 2\n* `%c` el carácter representado por el punto de código Unicode correspondiente\n* `%d` base 10\n* `%o` base 8\n* `%O` base 8 con prefijo 0o\n* `%q` un literal de carácter entre comillas simples escapado de forma segura\n* `%x` base 16, con letras minúsculas para a-f\n* `%X` base 16, con letras mayúsculas para A-F\n* `%U` formato Unicode: U+1234; igual que \"U+%04X\"\n\n Punto flotante y componentes complejos:\n\n* `%b` notación científica decimal con exponente potencia de dos, ej.\n  -123456p-78\n* `%e` notación científica, ej. -1.234456e+78\n* `%E` notación científica, ej. -1.234456E+78\n* `%f` punto decimal pero sin exponente, ej. 123.456\n* `%F` sinónimo de %f\n* `%g` %e para exponentes grandes, %f en caso contrario.\n* `%G` %E para exponentes grandes, %F en caso contrario\n* `%x` notación hexadecimal (con exponente potencia de dos decimal), ej.\n  -0x1.23abcp+20\n* `%X` notación hexadecimal mayúsculas, ej. -0X1.23ABCP+20\n\nCadena y slice de bytes (tratados de manera equivalente con estos verbos):\n\n* `%s` los bytes sin interpretar de la cadena o slice\n* `%q` una cadena entre comillas dobles escapada de forma segura\n* `%x` base 16, minúsculas, dos caracteres por byte\n* `%X` base 16, mayúsculas, dos caracteres por byte\n\nSlice:\n\n* `%p` dirección del elemento 0 en notación base 16, con 0x inicial\n\n### trim\n\nLa función `trim` elimina los espacios en blanco de ambos lados de una cadena:\n\n```\ntrim \"   hello    \"\n```\n\nLo anterior produce `hello`\n\n### trimAll\n\nElimina los caracteres dados del principio y final de una cadena:\n\n```\ntrimAll \"$\" \"$5.00\"\n```\n\nEsto devuelve `5.00` (como cadena).\n\n### trimPrefix\n\nElimina solo el prefijo de una cadena:\n\n```\ntrimPrefix \"-\" \"-hello\"\n```\n\nLo anterior devuelve `hello`\n\n### trimSuffix\n\nElimina solo el sufijo de una cadena:\n\n```\ntrimSuffix \"-\" \"hello-\"\n```\n\nLo anterior devuelve `hello`\n\n### lower\n\nConvierte toda la cadena a minúsculas:\n\n```\nlower \"HELLO\"\n```\n\nEsto devuelve `hello`\n\n### upper\n\nConvierte toda la cadena a mayúsculas:\n\n```\nupper \"hello\"\n```\n\nLo anterior devuelve `HELLO`\n\n### title\n\nConvierte a formato de título:\n\n```\ntitle \"hello world\"\n```\n\nLo anterior devuelve `Hello World`\n\n### untitle\n\nElimina el formato de título. `untitle \"Hello World\"` produce `hello world`.\n\n### repeat\n\nRepite una cadena múltiples veces:\n\n```\nrepeat 3 \"hello\"\n```\n\nLo anterior devuelve `hellohellohello`\n\n### substr\n\nObtiene una subcadena de una cadena. Toma tres parámetros:\n\n- inicio (int)\n- fin (int)\n- cadena (string)\n\n```\nsubstr 0 5 \"hello world\"\n```\n\nEl resultado es `hello`\n\n### nospace\n\nElimina todos los espacios en blanco de una cadena.\n\n```\nnospace \"hello w o r l d\"\n```\n\nEl resultado es `helloworld`\n\n### trunc\n\nTrunca una cadena\n\n```\ntrunc 5 \"hello world\"\n```\n\nLo anterior produce `hello`.\n\n```\ntrunc -5 \"hello world\"\n```\n\nLo anterior produce `world`.\n\n### abbrev\n\nTrunca una cadena con puntos suspensivos (`...`)\n\nParámetros:\n\n- longitud máxima\n- la cadena\n\n```\nabbrev 5 \"hello world\"\n```\n\nLo anterior devuelve `he...`, ya que cuenta el ancho de los puntos suspensivos contra la\nlongitud máxima.\n\n### abbrevboth\n\nAbrevia en ambos lados:\n\n```\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\nLo anterior produce `...5678...`\n\nToma:\n\n- desplazamiento izquierdo\n- longitud máxima\n- la cadena\n\n### initials\n\nDadas múltiples palabras, toma la primera letra de cada palabra y las combina.\n\n```\ninitials \"First Try\"\n```\n\nEsto devuelve `FT`\n\n### randAlphaNum, randAlpha, randNumeric, y randAscii\n\nEstas cuatro funciones generan cadenas aleatorias criptográficamente seguras (usan ```crypto/rand```),\npero con diferentes conjuntos de caracteres base:\n\n- `randAlphaNum` usa `0-9a-zA-Z`\n- `randAlpha` usa `a-zA-Z`\n- `randNumeric` usa `0-9`\n- `randAscii` usa todos los caracteres ASCII imprimibles\n\nCada una toma un parámetro: la longitud entera de la cadena.\n\n```\nrandNumeric 3\n```\n\nLo anterior producirá una cadena aleatoria con tres dígitos.\n\n### wrap\n\nAjusta el texto a un número de columnas dado:\n\n```\nwrap 80 $someText\n```\n\nLo anterior ajustará la cadena en `$someText` a 80 columnas.\n\n### wrapWith\n\n`wrapWith` funciona como `wrap`, pero le permite especificar la cadena con la que ajustar.\n(`wrap` usa `\\n`)\n\n```\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\nLo anterior produce `Hello World` (donde el espacio en blanco es un carácter de tabulación ASCII)\n\n### contains\n\nPrueba si una cadena está contenida dentro de otra:\n\n```\ncontains \"cat\" \"catch\"\n```\n\nEsto devuelve `true` porque `catch` contiene `cat`.\n\n### hasPrefix y hasSuffix\n\nLas funciones `hasPrefix` y `hasSuffix` prueban si una cadena tiene un\nprefijo o sufijo dado:\n\n```\nhasPrefix \"cat\" \"catch\"\n```\n\nLo anterior devuelve `true` porque `catch` tiene el prefijo `cat`.\n\n### quote y squote\n\nEstas funciones envuelven una cadena en comillas dobles (`quote`) o comillas simples\n(`squote`).\n\n### cat\n\nLa función `cat` concatena múltiples cadenas en una, separándolas\ncon espacios:\n\n```\ncat \"hello\" \"beautiful\" \"world\"\n```\n\nLo anterior produce `hello beautiful world`\n\n### indent\n\nLa función `indent` indenta cada línea en una cadena dada al ancho de\nindentación especificado. Esto es útil cuando se alinean cadenas multilínea:\n\n```\nindent 4 $lots_of_text\n```\n\nLo anterior indentará cada línea de texto con 4 caracteres de espacio.\n\n### nindent\n\nLa función `nindent` es igual que la función indent, pero antepone una nueva\nlínea al principio de la cadena.\n\n```\nnindent 4 $lots_of_text\n```\n\nLo anterior indentará cada línea de texto con 4 caracteres de espacio y agregará una nueva\nlínea al principio.\n\n### replace\n\nRealiza un reemplazo simple de cadenas.\n\nToma tres argumentos:\n\n- cadena a reemplazar\n- cadena con la que reemplazar\n- cadena fuente\n\n```\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\nLo anterior producirá `I-Am-Henry-VIII`\n\n### plural\n\nPluraliza una cadena.\n\n```\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\nEn el ejemplo anterior, si la longitud de la cadena es 1, se imprimirá el primer argumento\n(`one anchovy`). De lo contrario, se imprimirá el segundo argumento (`many\nanchovies`).\n\nLos argumentos son:\n\n- cadena singular\n- cadena plural\n- entero de longitud\n\nNOTA: Helm actualmente no soporta idiomas con reglas de pluralización más complejas.\nY `0` se considera plural porque el idioma inglés lo trata así\n(`zero anchovies`).\n\n### snakecase\n\nConvierte una cadena de camelCase a snake_case.\n\n```\nsnakecase \"FirstName\"\n```\n\nEsto producirá `first_name`.\n\n### camelcase\n\nConvierte una cadena de snake_case a CamelCase\n\n```\ncamelcase \"http_server\"\n```\n\nEsto producirá `HttpServer`.\n\n### kebabcase\n\nConvierte una cadena de camelCase a kebab-case.\n\n```\nkebabcase \"FirstName\"\n```\n\nLo anterior producirá `first-name`.\n\n### swapcase\n\nIntercambia las mayúsculas/minúsculas de una cadena usando un algoritmo basado en palabras.\n\nAlgoritmo de conversión:\n\n- Carácter mayúscula se convierte a minúscula\n- Carácter de título se convierte a minúscula\n- Carácter minúscula después de espacio en blanco o al inicio se convierte a título\n- Otros caracteres minúsculas se convierten a mayúsculas\n- El espacio en blanco se define por unicode.IsSpace(char)\n\n```\nswapcase \"This Is A.Test\"\n```\n\nLo anterior producirá `tHIS iS a.tEST`.\n\n### shuffle\n\nMezcla aleatoriamente una cadena.\n\n```\nshuffle \"hello\"\n```\n\nLo anterior reordenará aleatoriamente las letras en `hello`, produciendo quizás `oelhl`.\n\n## Funciones de Conversión de Tipos\n\nHelm proporciona las siguientes funciones de conversión de tipos:\n\n- `atoi`: Convierte una cadena a un entero.\n- `float64`: Convierte a `float64`.\n- `int`: Convierte a `int` en el ancho del sistema.\n- `int64`: Convierte a `int64`.\n- `toDecimal`: Convierte un octal unix a `int64`.\n- `toString`: Convierte a una cadena.\n- `toStrings`: Convierte una lista, slice o arreglo a una lista de cadenas.\n- `toJson` (`mustToJson`): Convierte lista, slice, arreglo, dict u objeto a JSON.\n- `toPrettyJson` (`mustToPrettyJson`): Convierte lista, slice, arreglo, dict u\n  objeto a JSON indentado.\n- `toRawJson` (`mustToRawJson`): Convierte lista, slice, arreglo, dict u objeto a\n  JSON con caracteres HTML sin escapar.\n- `fromYaml`: Convierte una cadena YAML a un objeto.\n- `fromJson`: Convierte una cadena JSON a un objeto.\n- `fromJsonArray`: Convierte un arreglo JSON a una lista.\n- `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\n- `toYamlPretty`: Convierte lista, slice, arreglo, dict u objeto a yaml indentado. Equivalente a `toYaml` pero adicionalmente indentará listas por 2 espacios.\n- `toToml`: Convierte lista, slice, arreglo, dict u objeto a toml, puede usarse para copiar fragmentos de toml de cualquier fuente.\n- `fromYamlArray`: Convierte un arreglo YAML a una lista.\n\nSolo `atoi` requiere que la entrada sea de un tipo específico. Las demás intentarán\nconvertir de cualquier tipo al tipo de destino. Por ejemplo, `int64` puede\nconvertir flotantes a enteros, y también puede convertir cadenas a enteros.\n\n### toStrings\n\nDada una colección tipo lista, produce un slice de cadenas.\n\n```\nlist 1 2 3 | toStrings\n```\n\nLo anterior convierte `1` a `\"1\"`, `2` a `\"2\"`, y así sucesivamente, y luego los devuelve\ncomo una lista.\n\n### toDecimal\n\nDado un permiso octal unix, produce un decimal.\n\n```\n\"0777\" | toDecimal\n```\n\nLo anterior convierte `0777` a `511` y devuelve el valor como int64.\n\n### toJson, mustToJson\n\nLa función `toJson` codifica un elemento en una cadena JSON. Si el elemento no puede ser\nconvertido a JSON, la función devolverá una cadena vacía. `mustToJson` devolverá\nun error en caso de que el elemento no pueda ser codificado en JSON.\n\n```\ntoJson .Item\n```\n\nLo anterior devuelve la representación en cadena JSON de `.Item`.\n\n### toPrettyJson, mustToPrettyJson\n\nLa función `toPrettyJson` codifica un elemento en una cadena JSON formateada (indentada).\n\n```\ntoPrettyJson .Item\n```\n\nLo anterior devuelve la representación en cadena JSON indentada de `.Item`.\n\n### toRawJson, mustToRawJson\n\nLa función `toRawJson` codifica un elemento en una cadena JSON con caracteres HTML\nsin escapar.\n\n```\ntoRawJson .Item\n```\n\nLo anterior devuelve la representación en cadena JSON sin escapar de `.Item`.\n\n### fromYaml\n\nLa función `fromYaml` toma una cadena YAML y devuelve un objeto que puede usarse en plantillas.\n\n`Archivo en: yamls/person.yaml`\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n```yaml\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\nLa función `fromJson` toma una cadena JSON y devuelve un objeto que puede usarse en plantillas.\n\n`Archivo en: jsons/person.json`\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n\n### fromJsonArray\n\nLa función `fromJsonArray` toma un arreglo JSON y devuelve una lista que puede usarse en plantillas.\n\n`Archivo en: jsons/people.json`\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml, toYamlPretty\n\nLas funciones `toYaml` y `toYamlPretty` codifican un objeto (lista, slice, arreglo, dict u objeto) en una cadena YAML indentada.\n\n> Note que `toYamlPretty` es funcionalmente equivalente pero mostrará YAML con indentación adicional para elementos de lista\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\nLa función `fromYamlArray` toma un arreglo YAML y devuelve una lista que puede usarse en plantillas.\n\n`Archivo en: yamls/people.yml`\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n\n## Expresiones Regulares\n\nHelm incluye las siguientes funciones de expresiones regulares: [regexFind\n(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll\n(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch\n(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll\n(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall),\n[regexReplaceAllLiteral\n(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral),\n[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\nDevuelve true si la cadena de entrada contiene alguna coincidencia de la expresión regular.\n\n```\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\nLo anterior produce `true`\n\n`regexMatch` entra en pánico si hay un problema y `mustRegexMatch` devuelve un error\nal motor de plantillas si hay un problema.\n\n### regexFindAll, mustRegexFindAll\n\nDevuelve un slice de todas las coincidencias de la expresión regular en la cadena de entrada.\nEl último parámetro n determina el número de subcadenas a devolver, donde -1\nsignifica devolver todas las coincidencias\n\n```\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\nLo anterior produce `[2 4 6 8]`\n\n`regexFindAll` entra en pánico si hay un problema y `mustRegexFindAll` devuelve un\nerror al motor de plantillas si hay un problema.\n\n### regexFind, mustRegexFind\n\nDevuelve la primera coincidencia (la más a la izquierda) de la expresión regular en la cadena de entrada\n\n```\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\nLo anterior produce `d1`\n\n`regexFind` entra en pánico si hay un problema y `mustRegexFind` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### regexReplaceAll, mustRegexReplaceAll\n\nDevuelve una copia de la cadena de entrada, reemplazando las coincidencias de la Regexp con la\ncadena de reemplazo. Dentro de la cadena de reemplazo, los signos $ se\ninterpretan como en Expand, por lo que por ejemplo $1 representa el texto de la primera\nsubcoincidencia. El primer argumento es `<pattern>`, el segundo es `<input>`,\ny el tercero es `<replacement>`.\n\n```\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\nLo anterior produce `-W-xxW-`\n\n`regexReplaceAll` entra en pánico si hay un problema y `mustRegexReplaceAll` devuelve\nun error al motor de plantillas si hay un problema.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\nDevuelve una copia de la cadena de entrada, reemplazando las coincidencias de la Regexp con la\ncadena de reemplazo. La cadena de reemplazo se sustituye directamente,\nsin usar Expand. El primer argumento es `<pattern>`, el segundo es `<input>`,\ny el tercero es `<replacement>`.\n\n```\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\nLo anterior produce `-${1}-${1}-`\n\n`regexReplaceAllLiteral` entra en pánico si hay un problema y\n`mustRegexReplaceAllLiteral` devuelve un error al motor de plantillas si hay un\nproblema.\n\n### regexSplit, mustRegexSplit\n\nDivide la cadena de entrada en subcadenas separadas por la expresión y devuelve\nun slice de las subcadenas entre esas coincidencias de expresión. El último parámetro\n`n` determina el número de subcadenas a devolver, donde `-1` significa devolver todas\nlas coincidencias\n\n```\nregexSplit \"z+\" \"pizza\" -1\n```\n\nLo anterior produce `[pi a]`\n\n`regexSplit` entra en pánico si hay un problema y `mustRegexSplit` devuelve un error\nal motor de plantillas si hay un problema.\n\n## Funciones de Criptografía y Seguridad\n\nHelm proporciona algunas funciones criptográficas avanzadas. Incluyen\n[adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert),\n[decryptAES](#decryptaes), [derivePassword](#derivepassword),\n[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey),\n[genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert),\n[htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum), y\n[sha256sum](#sha256sum).\n\n### sha1sum\n\nLa función `sha1sum` recibe una cadena y calcula su resumen SHA1.\n\n```\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\nLa función `sha256sum` recibe una cadena y calcula su resumen SHA256.\n\n```\nsha256sum \"Hello world!\"\n```\n\nLo anterior calculará la suma SHA 256 en un formato \"blindado ASCII\" que es seguro\npara imprimir.\n\n### adler32sum\n\nLa función `adler32sum` recibe una cadena y calcula su suma de verificación Adler-32.\n\n```\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\nLa función `htpasswd` toma un `username` y `password` y genera un\nhash `bcrypt` de la contraseña. El resultado puede usarse para autenticación básica\nen un [Servidor HTTP Apache](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic).\n\n```\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nNote que es inseguro almacenar la contraseña directamente en la plantilla.\n\n### randBytes\n\nLa función randBytes acepta un conteo N y genera una secuencia aleatoria\ncriptográficamente segura (usa crypto/rand) de N bytes. La secuencia se devuelve\ncomo una cadena codificada en base64.\n\n```\nrandBytes 24\n```\n\n### derivePassword\n\nLa función `derivePassword` puede usarse para derivar una contraseña específica basada en\nalgunas restricciones de \"contraseña maestra\" compartidas. El algoritmo para esto está [bien\nespecificado](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf).\n\n```\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nNote que se considera inseguro almacenar las partes directamente en la plantilla.\n\n### genPrivateKey\n\nLa función `genPrivateKey` genera una nueva clave privada codificada en un bloque PEM.\n\nToma uno de los valores para su primer parámetro:\n\n- `ecdsa`: Genera una clave DSA de curva elíptica (P256)\n- `dsa`: Genera una clave DSA (L2048N256)\n- `rsa`: Genera una clave RSA 4096\n\n### buildCustomCert\n\nLa función `buildCustomCert` permite personalizar el certificado.\n\nToma los siguientes parámetros de cadena:\n\n- Un certificado en formato PEM codificado en base64\n- Una clave privada en formato PEM codificada en base64\n\nDevuelve un objeto de certificado con los siguientes atributos:\n\n- `Cert`: Un certificado codificado en PEM\n- `Key`: Una clave privada codificada en PEM\n\nEjemplo:\n\n```\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\nNote que el objeto devuelto puede pasarse a la función `genSignedCert` para\nfirmar un certificado usando esta CA.\n\n### genCA\n\nLa función `genCA` genera una nueva autoridad de certificación x509 autofirmada.\n\nToma los siguientes parámetros:\n\n- Nombre común del sujeto (cn)\n- Duración de validez del certificado en días\n\nDevuelve un objeto con los siguientes atributos:\n\n- `Cert`: Un certificado codificado en PEM\n- `Key`: Una clave privada codificada en PEM\n\nEjemplo:\n\n```\n$ca := genCA \"foo-ca\" 365\n```\n\nNote que el objeto devuelto puede pasarse a la función `genSignedCert` para\nfirmar un certificado usando esta CA.\n\n### genSelfSignedCert\n\nLa función `genSelfSignedCert` genera un nuevo certificado x509 autofirmado.\n\nToma los siguientes parámetros:\n\n- Nombre común del sujeto (cn)\n- Lista opcional de IPs; puede ser nil\n- Lista opcional de nombres DNS alternativos; puede ser nil\n- Duración de validez del certificado en días\n\nDevuelve un objeto con los siguientes atributos:\n\n- `Cert`: Un certificado codificado en PEM\n- `Key`: Una clave privada codificada en PEM\n\nEjemplo:\n\n```\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\nLa función `genSignedCert` genera un nuevo certificado x509 firmado por la\nCA especificada.\n\nToma los siguientes parámetros:\n\n- Nombre común del sujeto (cn)\n- Lista opcional de IPs; puede ser nil\n- Lista opcional de nombres DNS alternativos; puede ser nil\n- Duración de validez del certificado en días\n- CA (ver `genCA`)\n\nEjemplo:\n\n```\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\nLa función `encryptAES` cifra texto con AES-256 CBC y devuelve una cadena\ncodificada en base64.\n\n```\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\nLa función `decryptAES` recibe una cadena base64 codificada por el algoritmo AES-256 CBC\ny devuelve el texto descifrado.\n\n```\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Funciones de Fecha\n\nHelm incluye las siguientes funciones de fecha que puede usar en plantillas:\n[ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify\n(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration),\n[durationRound](#durationround), [htmlDate](#htmldate),\n[htmlDateInZone](#htmldateinzone), [now](#now), [toDate\n(mustToDate)](#todate-musttodate), y [unixEpoch](#unixepoch).\n\n### now\n\nLa fecha/hora actual. Use esto en conjunto con otras funciones de fecha.\n\n### ago\n\nLa función `ago` devuelve la duración desde un momento en el tiempo. Ahora en resolución de segundos.\n\n```\nago .CreatedAt\n```\n\ndevuelve en formato String() de `time.Duration`\n\n```\n2h34m7s\n```\n\n### date\n\nLa función `date` formatea una fecha.\n\nFormatear la fecha a AÑO-MES-DÍA:\n\n```\nnow | date \"2006-01-02\"\n```\n\nEl formateo de fechas en Go es [un poco\ndiferente](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\nEn resumen, tome esto como la fecha base:\n\n```\nMon Jan 2 15:04:05 MST 2006\n```\n\nEscríbala en el formato que desee. Arriba, `2006-01-02` es la misma fecha, pero en\nel formato que queremos.\n\n### dateInZone\n\nIgual que `date`, pero con una zona horaria.\n\n```\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\nFormatea una cantidad dada de segundos como `time.Duration`.\n\nEsto devuelve 1m35s\n\n```\nduration \"95\"\n```\n\n### durationRound\n\nRedondea una duración dada a la unidad más significativa. Las cadenas y\n`time.Duration` se parsean como duración, mientras que un `time.Time` se calcula como\nla duración desde entonces.\n\nEsto devuelve 2h\n\n```\ndurationRound \"2h10m5s\"\n```\n\nEsto devuelve 3mo\n\n```\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\nDevuelve los segundos desde el epoch unix para un `time.Time`.\n\n```\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\n`dateModify` toma una modificación y una fecha y devuelve la marca de tiempo.\n\nRestar una hora y treinta minutos del tiempo actual:\n\n```\nnow | dateModify \"-1.5h\"\n```\n\nSi el formato de modificación es incorrecto, `dateModify` devolverá la fecha\nsin modificar. `mustDateModify` devolverá un error en su lugar.\n\n### htmlDate\n\nLa función `htmlDate` formatea una fecha para insertarla en un campo de entrada\nde selector de fecha HTML.\n\n```\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nIgual que htmlDate, pero con una zona horaria.\n\n```\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\n`toDate` convierte una cadena a una fecha. El primer argumento es el layout de fecha y\nel segundo la cadena de fecha. Si la cadena no puede convertirse, devuelve el valor\ncero. `mustToDate` devolverá un error en caso de que la cadena no pueda convertirse.\n\nEsto es útil cuando desea convertir una cadena de fecha a otro formato (usando\npipe). El ejemplo siguiente convierte \"2017-12-31\" a \"31/12/2017\".\n\n```\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Funciones de Diccionarios y Dict\n\nHelm proporciona un tipo de almacenamiento clave/valor llamado `dict` (abreviatura de \"dictionary\",\ncomo en Python). Un `dict` es un tipo _no ordenado_.\n\nLa clave de un diccionario **debe ser una cadena**. Sin embargo, el valor puede ser de cualquier\ntipo, incluso otro `dict` o `list`.\n\nA diferencia de las `list`s, los `dict`s no son inmutables. Las funciones `set` y `unset`\nmodificarán el contenido de un diccionario.\n\nHelm proporciona las siguientes funciones para trabajar con dicts: [deepCopy\n(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get),\n[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge),\n[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite),\n[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), y\n[values](#values).\n\n### dict\n\nLa creación de diccionarios se hace llamando a la función `dict` y pasándole una\nlista de pares.\n\nLo siguiente crea un diccionario con tres elementos:\n\n```\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nDado un mapa y una clave, obtiene el valor del mapa.\n\n```\nget $myDict \"name1\"\n```\n\nLo anterior devuelve `\"value1\"`\n\nNote que si la clave no se encuentra, esta operación simplemente devolverá `\"\"`. No se\ngenerará ningún error.\n\n### set\n\nUse `set` para agregar un nuevo par clave/valor a un diccionario.\n\n```\n$_ := set $myDict \"name4\" \"value4\"\n```\n\nNote que `set` _devuelve el diccionario_ (un requisito de las funciones de plantilla de Go),\npor lo que puede necesitar capturar el valor como se hizo arriba con la asignación `$_`.\n\n### unset\n\nDado un mapa y una clave, elimina la clave del mapa.\n\n```\n$_ := unset $myDict \"name4\"\n```\n\nAl igual que con `set`, esto devuelve el diccionario.\n\nNote que si la clave no se encuentra, esta operación simplemente retornará. No se\ngenerará ningún error.\n\n### hasKey\n\nLa función `hasKey` devuelve `true` si el dict dado contiene la clave dada.\n\n```\nhasKey $myDict \"name1\"\n```\n\nSi la clave no se encuentra, devuelve `false`.\n\n### pluck\n\nLa función `pluck` hace posible dar una clave y múltiples mapas, y\nobtener una lista de todas las coincidencias:\n\n```\npluck \"name1\" $myDict $myOtherDict\n```\n\nLo anterior devolverá una `list` que contiene cada valor encontrado (`[value1\notherValue1]`).\n\nSi la clave dada _no se encuentra_ en un mapa, ese mapa no tendrá un elemento en la\nlista (y la longitud de la lista devuelta será menor que el número de dicts\nen la llamada a `pluck`).\n\nSi la clave _se encuentra_ pero el valor es un valor vacío, ese valor se\ninsertará.\n\nUn patrón común en las plantillas de Helm es usar `pluck... | first` para obtener la primera\nclave coincidente de una colección de diccionarios.\n\n### dig\n\nLa función `dig` recorre un conjunto anidado de dicts, seleccionando claves de una lista\nde valores. Devuelve un valor por defecto si alguna de las claves no se encuentra en el\ndict asociado.\n\n```\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\nDado un dict estructurado como\n```\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\nlo anterior devolvería `\"curator\"`. Si el dict careciera incluso de un campo `user`,\nel resultado sería `\"guest\"`.\n\nDig puede ser muy útil en casos donde le gustaría evitar cláusulas de guardia,\nespecialmente ya que el `and` del paquete de plantillas de Go no hace cortocircuito. Por ejemplo\n`and a.maybeNil a.maybeNil.iNeedThis` siempre evaluará\n`a.maybeNil.iNeedThis`, y entrará en pánico si `a` carece de un campo `maybeNil`.)\n\n`dig` acepta su argumento dict al final para soportar pipelining. Por ejemplo:\n```\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\nCombina dos o más diccionarios en uno, dando precedencia al diccionario\nde destino:\n\nDado:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nresultará en:\n\n```\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n```\n$newdict := merge $dest $source1 $source2\n```\n\nEsta es una operación de combinación profunda pero no una operación de copia profunda. Los objetos\nanidados que se combinan son la misma instancia en ambos dicts. Si desea una copia profunda\njunto con la combinación, entonces use la función `deepCopy` junto con la combinación. Por\nejemplo,\n\n```\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` devolverá un error en caso de una combinación fallida.\n\n### mergeOverwrite, mustMergeOverwrite\n\nCombina dos o más diccionarios en uno, dando precedencia de **derecha a\nizquierda**, sobrescribiendo efectivamente valores en el diccionario de destino:\n\nDado:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nresultará en:\n\n```\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nEsta es una operación de combinación profunda pero no una operación de copia profunda. Los objetos\nanidados que se combinan son la misma instancia en ambos dicts. Si desea una copia profunda\njunto con la combinación, entonces use la función `deepCopy` junto con la combinación. Por\nejemplo,\n\n```\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` devolverá un error en caso de una combinación fallida.\n\n### keys\n\nLa función `keys` devolverá una `list` de todas las claves en uno o más\ntipos `dict`. Dado que un diccionario está _desordenado_, las claves no estarán en un\norden predecible. Pueden ordenarse con `sortAlpha`.\n\n```\nkeys $myDict | sortAlpha\n```\n\nAl proporcionar múltiples diccionarios, las claves se concatenarán. Use la\nfunción `uniq` junto con `sortAlpha` para obtener una lista única y ordenada de claves.\n\n```\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\nLa función `pick` selecciona solo las claves dadas de un diccionario, creando un\nnuevo `dict`.\n\n```\n$new := pick $myDict \"name1\" \"name2\"\n```\n\nLo anterior devuelve `{name1: value1, name2: value2}`\n\n### omit\n\nLa función `omit` es similar a `pick`, excepto que devuelve un nuevo `dict` con\ntodas las claves que _no coinciden_ con las claves dadas.\n\n```\n$new := omit $myDict \"name1\" \"name3\"\n```\n\nLo anterior devuelve `{name2: value2}`\n\n### values\n\nLa función `values` es similar a `keys`, excepto que devuelve una nueva `list` con\ntodos los valores del `dict` fuente (solo se soporta un diccionario).\n\n```\n$vals := values $myDict\n```\n\nLo anterior devuelve `list[\"value1\", \"value2\", \"value 3\"]`. Note que la función `values`\nno da garantías sobre el orden del resultado; si le importa esto,\nentonces use `sortAlpha`.\n\n### deepCopy, mustDeepCopy\n\nLas funciones `deepCopy` y `mustDeepCopy` toman un valor y hacen una copia profunda\ndel valor. Esto incluye dicts y otras estructuras. `deepCopy` entra en pánico cuando\nhay un problema, mientras que `mustDeepCopy` devuelve un error al sistema de plantillas\ncuando hay un error.\n\n```\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### Una Nota sobre los Internos de Dict\n\nUn `dict` se implementa en Go como un `map[string]interface{}`. Los desarrolladores de Go pueden\npasar valores `map[string]interface{}` al contexto para hacerlos disponibles a\nlas plantillas como `dict`s.\n\n## Funciones de Codificación\n\nHelm tiene las siguientes funciones de codificación y decodificación:\n\n- `b64enc`/`b64dec`: Codificar o decodificar con Base64\n- `b32enc`/`b32dec`: Codificar o decodificar con Base32\n\n## Funciones de Listas y List\n\nHelm proporciona un tipo `list` simple que puede contener listas secuenciales arbitrarias\nde datos. Esto es similar a arreglos o slices, pero las listas están diseñadas para ser usadas\ncomo tipos de datos inmutables.\n\nCrear una lista de enteros:\n\n```\n$myList := list 1 2 3 4 5\n```\n\nLo anterior crea una lista de `[1 2 3 4 5]`.\n\nHelm proporciona las siguientes funciones de lista: [append\n(mustAppend)](#append-mustappend), [chunk](#chunk), [compact\n(mustCompact)](#compact-mustcompact), [concat](#concat), [first\n(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial\n(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast),\n[prepend (mustPrepend)](#prepend-mustprepend), [rest\n(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse),\n[seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq\n(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), y\n[without (mustWithout)](#without-mustwithout).\n\n### first, mustFirst\n\nPara obtener el primer elemento de una lista, use `first`.\n\n`first $myList` devuelve `1`\n\n`first` entra en pánico si hay un problema, mientras que `mustFirst` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### rest, mustRest\n\nPara obtener la cola de la lista (todo excepto el primer elemento), use `rest`.\n\n`rest $myList` devuelve `[2 3 4 5]`\n\n`rest` entra en pánico si hay un problema, mientras que `mustRest` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### last, mustLast\n\nPara obtener el último elemento de una lista, use `last`:\n\n`last $myList` devuelve `5`. Esto es aproximadamente análogo a invertir una lista y\nluego llamar a `first`.\n\n### initial, mustInitial\n\nEsto complementa a `last` devolviendo todo _excepto_ el último elemento. `initial\n$myList` devuelve `[1 2 3 4]`.\n\n`initial` entra en pánico si hay un problema, mientras que `mustInitial` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### append, mustAppend\n\nAgrega un nuevo elemento a una lista existente, creando una nueva lista.\n\n```\n$new = append $myList 6\n```\n\nLo anterior establecería `$new` a `[1 2 3 4 5 6]`. `$myList` permanecería sin cambios.\n\n`append` entra en pánico si hay un problema, mientras que `mustAppend` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### prepend, mustPrepend\n\nInserta un elemento al principio de una lista, creando una nueva lista.\n\n```\nprepend $myList 0\n```\n\nLo anterior produciría `[0 1 2 3 4 5]`. `$myList` permanecería sin cambios.\n\n`prepend` entra en pánico si hay un problema, mientras que `mustPrepend` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### concat\n\nConcatena un número arbitrario de listas en una.\n\n```\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\nLo anterior produciría `[1 2 3 4 5 6 7 8]`. `$myList` permanecería sin cambios.\n\n### reverse, mustReverse\n\nProduce una nueva lista con los elementos invertidos de la lista dada.\n\n```\nreverse $myList\n```\n\nLo anterior generaría la lista `[5 4 3 2 1]`.\n\n`reverse` entra en pánico si hay un problema, mientras que `mustReverse` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### uniq, mustUniq\n\nGenera una lista con todos los duplicados eliminados.\n\n```\nlist 1 1 1 2 | uniq\n```\n\nLo anterior produciría `[1 2]`\n\n`uniq` entra en pánico si hay un problema, mientras que `mustUniq` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### without, mustWithout\n\nLa función `without` filtra elementos de una lista.\n\n```\nwithout $myList 3\n```\n\nLo anterior produciría `[1 2 4 5]`\n\n`without` puede tomar más de un filtro:\n\n```\nwithout $myList 1 3 5\n```\n\nEso produciría `[2 4]`\n\n`without` entra en pánico si hay un problema, mientras que `mustWithout` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### has, mustHas\n\nPrueba si una lista tiene un elemento particular.\n\n```\nhas 4 $myList\n```\n\nLo anterior devolvería `true`, mientras que `has \"hello\" $myList` devolvería false.\n\n`has` entra en pánico si hay un problema, mientras que `mustHas` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### compact, mustCompact\n\nAcepta una lista y elimina entradas con valores vacíos.\n\n```\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` devolverá una nueva lista con el elemento vacío (es decir, \"\") eliminado.\n\n`compact` entra en pánico si hay un problema y `mustCompact` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### index\n\nPara obtener el elemento n-ésimo de una lista, use `index list [n]`. Para indexar en\nlistas multidimensionales, use `index list [n] [m] ...`\n- `index $myList 0` devuelve `1`. Es lo mismo que `myList[0]`\n- `index $myList 0 1` sería lo mismo que `myList[0][1]`\n\n### slice, mustSlice\n\nPara obtener elementos parciales de una lista, use `slice list [n] [m]`. Es equivalente a\n`list[n:m]`.\n\n- `slice $myList` devuelve `[1 2 3 4 5]`. Es lo mismo que `myList[:]`.\n- `slice $myList 3` devuelve `[4 5]`. Es lo mismo que `myList[3:]`.\n- `slice $myList 1 3` devuelve `[2 3]`. Es lo mismo que `myList[1:3]`.\n- `slice $myList 0 3` devuelve `[1 2 3]`. Es lo mismo que `myList[:3]`.\n\n`slice` entra en pánico si hay un problema, mientras que `mustSlice` devuelve un error al\nmotor de plantillas si hay un problema.\n\n### until\n\nLa función `until` construye un rango de enteros.\n\n```\nuntil 5\n```\n\nLo anterior genera la lista `[0, 1, 2, 3, 4]`.\n\nEsto es útil para iterar con `range $i, $e := until 5`.\n\n### untilStep\n\nComo `until`, `untilStep` genera una lista de enteros contando. Pero le permite\ndefinir un inicio, fin y paso:\n\n```\nuntilStep 3 6 2\n```\n\nLo anterior producirá `[3 5]` comenzando con 3 y sumando 2 hasta que sea\nigual o mayor que 6. Esto es similar a la función `range` de Python.\n\n### seq\n\nFunciona como el comando `seq` de bash.\n\n* 1 parámetro (fin) - generará todos los enteros contando entre 1 y `fin`\n  inclusive.\n* 2 parámetros (inicio, fin) - generará todos los enteros contando entre\n  `inicio` y `fin` inclusive incrementando o decrementando en 1.\n* 3 parámetros (inicio, paso, fin) - generará todos los enteros contando entre\n  `inicio` y `fin` inclusive incrementando o decrementando en `paso`.\n\n```\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\nPara dividir una lista en fragmentos de un tamaño dado, use `chunk size list`. Esto es útil para paginación.\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\nEsto produce una lista de listas `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`.\n\n## Funciones Matemáticas\n\nTodas las funciones matemáticas operan con valores `int64` a menos que se especifique lo contrario.\n\nLas siguientes funciones matemáticas están disponibles: [add](#add), [add1](#add1),\n[ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max),\n[min](#min), [mod](#mod), [mul](#mul), [round](#round), y [sub](#sub).\n\n### add\n\nSuma números con `add`. Acepta dos o más entradas.\n\n```\nadd 1 2 3\n```\n\n### add1\n\nPara incrementar en 1, use `add1`.\n\n### sub\n\nPara restar, use `sub`.\n\n### div\n\nRealiza división entera con `div`.\n\n### mod\n\nMódulo con `mod`.\n\n### mul\n\nMultiplica con `mul`. Acepta dos o más entradas.\n\n```\nmul 1 2 3\n```\n\n### max\n\nDevuelve el mayor de una serie de enteros.\n\nEsto devolverá `3`:\n\n```\nmax 1 2 3\n```\n\n### min\n\nDevuelve el menor de una serie de enteros.\n\n`min 1 2 3` devolverá `1`.\n\n### len\n\nDevuelve la longitud del argumento como un entero.\n\n```\nlen .Arg\n```\n\n## Funciones Matemáticas de Punto Flotante\n\nTodas las funciones matemáticas operan con valores `float64`.\n\n### addf\n\nSuma números con `addf`\n\nEsto devolverá `5.5`:\n\n```\naddf 1.5 2 2\n```\n\n### add1f\n\nPara incrementar en 1, use `add1f`\n\n### subf\n\nPara restar, use `subf`\n\nEsto es equivalente a `7.5 - 2 - 3` y devolverá `2.5`:\n\n```\nsubf 7.5 2 3\n```\n\n### divf\n\nRealiza división con `divf`\n\nEsto es equivalente a `10 / 2 / 4` y devolverá `1.25`:\n\n```\ndivf 10 2 4\n```\n\n### mulf\n\nMultiplica con `mulf`\n\nEsto devolverá `6`:\n\n```\nmulf 1.5 2 2\n```\n\n### maxf\n\nDevuelve el mayor de una serie de flotantes:\n\nEsto devolverá `3`:\n\n```\nmaxf 1 2.5 3\n```\n\n### minf\n\nDevuelve el menor de una serie de flotantes.\n\nEsto devolverá `1.5`:\n\n```\nminf 1.5 2 3\n```\n\n### floor\n\nDevuelve el mayor valor flotante menor o igual al valor de entrada.\n\n`floor 123.9999` devolverá `123.0`.\n\n### ceil\n\nDevuelve el mayor valor flotante mayor o igual al valor de entrada.\n\n`ceil 123.001` devolverá `124.0`.\n\n### round\n\nDevuelve un valor flotante con el resto redondeado al número dado de dígitos\ndespués del punto decimal.\n\n`round 123.555555 3` devolverá `123.556`.\n\n## Funciones de Red\n\nHelm tiene una única función de red, `getHostByName`.\n\n`getHostByName` recibe un nombre de dominio y devuelve la dirección ip.\n\n`getHostByName \"www.google.com\"` devolvería la dirección ip correspondiente de `www.google.com`.\n\nEsta función requiere que se pase la opción `--enable-dns` en la línea de comandos de helm.\n\n## Funciones de Rutas de Archivos\n\nAunque las funciones de plantilla de Helm no otorgan acceso al sistema de archivos, sí\nproporcionan funciones para trabajar con cadenas que siguen convenciones de rutas de archivos.\nEstas incluyen [base](#base), [clean](#clean), [dir](#dir), [ext](#ext), e\n[isAbs](#isabs).\n\n### base\n\nDevuelve el último elemento de una ruta.\n\n```\nbase \"foo/bar/baz\"\n```\n\nLo anterior imprime \"baz\".\n\n### dir\n\nDevuelve el directorio, eliminando la última parte de la ruta. Así que `dir\n\"foo/bar/baz\"` devuelve `foo/bar`.\n\n### clean\n\nLimpia una ruta.\n\n```\nclean \"foo/bar/../baz\"\n```\n\nLo anterior resuelve el `..` y devuelve `foo/baz`.\n\n### ext\n\nDevuelve la extensión del archivo.\n\n```\next \"foo.bar\"\n```\n\nLo anterior devuelve `.bar`.\n\n### isAbs\n\nPara verificar si una ruta de archivo es absoluta, use `isAbs`.\n\n## Funciones de Reflexión\n\nHelm proporciona herramientas de reflexión rudimentarias. Estas ayudan a los desarrolladores avanzados\nde plantillas a entender la información de tipo de Go subyacente para un valor particular.\nHelm está escrito en Go y tiene tipado fuerte. El sistema de tipos aplica dentro\nde las plantillas.\n\nGo tiene varios _kinds_ primitivos, como `string`, `slice`, `int64`, y `bool`.\n\nGo tiene un sistema de _tipos_ abierto que permite a los desarrolladores crear sus propios tipos.\n\nHelm proporciona un conjunto de funciones para cada uno a través de [funciones kind](#funciones-kind)\ny [funciones type](#funciones-type). También se proporciona una función [deepEqual](#deepequal)\npara comparar dos valores.\n\n### Funciones Kind\n\nHay dos funciones Kind: `kindOf` devuelve el kind de un objeto.\n\n```\nkindOf \"hello\"\n```\n\nLo anterior devolvería `string`. Para pruebas simples (como en bloques `if`), la\nfunción `kindIs` le permitirá verificar que un valor es de un kind particular:\n\n```\nkindIs \"int\" 123\n```\n\nLo anterior devolverá `true`.\n\n### Funciones Type\n\nLos tipos son ligeramente más difíciles de trabajar, por lo que hay tres funciones diferentes:\n\n- `typeOf` devuelve el tipo subyacente de un valor: `typeOf $foo`\n- `typeIs` es como `kindIs`, pero para tipos: `typeIs \"*io.Buffer\" $myVal`\n- `typeIsLike` funciona como `typeIs`, excepto que también desreferencia punteros\n\n**Nota:** Ninguna de estas puede probar si algo implementa una\ninterfaz dada, ya que hacerlo requeriría compilar la interfaz por adelantado.\n\n### deepEqual\n\n`deepEqual` devuelve true si dos valores son [\"profundamente\niguales\"](https://golang.org/pkg/reflect/#DeepEqual)\n\nFunciona también para tipos no primitivos (comparado con el `eq` incorporado).\n\n```\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\nLo anterior devolverá `true`.\n\n## Funciones de Versiones Semánticas\n\nAlgunos esquemas de versiones son fácilmente parseables y comparables. Helm proporciona\nfunciones para trabajar con versiones [SemVer 2](http://semver.org). Estas incluyen\n[semver](#semver) y [semverCompare](#semvercompare). A continuación también encontrará\ndetalles sobre el uso de rangos para comparaciones.\n\n### semver\n\nLa función `semver` parsea una cadena en una Versión Semántica:\n\n```\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_Si el parser falla, causará que la ejecución de la plantilla se detenga con un error._\n\nEn este punto, `$version` es un puntero a un objeto `Version` con las siguientes\npropiedades:\n\n- `$version.Major`: El número mayor (`1` arriba)\n- `$version.Minor`: El número menor (`2` arriba)\n- `$version.Patch`: El número de parche (`3` arriba)\n- `$version.Prerelease`: El prerelease (`alpha.1` arriba)\n- `$version.Metadata`: Los metadatos de compilación (`123` arriba)\n- `$version.Original`: La versión original como cadena\n\nAdemás, puede comparar una `Version` con otra `version` usando la\nfunción `Compare`:\n\n```\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\nLo anterior devolverá `-1`.\n\nLos valores de retorno son:\n\n- `-1` si la semver dada es mayor que la semver cuyo método `Compare` fue\n  llamado\n- `1` si la versión cuya función `Compare` fue llamada es mayor.\n- `0` si son la misma versión\n\n(Note que en SemVer, el campo `Metadata` no se compara durante las operaciones de\ncomparación de versiones.)\n\n### semverCompare\n\nSe proporciona una función de comparación más robusta como `semverCompare`. Esta versión\nsoporta rangos de versiones:\n\n- `semverCompare \"1.2.3\" \"1.2.3\"` comprueba una coincidencia exacta\n- `semverCompare \"~1.2.0\" \"1.2.3\"` comprueba que las versiones mayor y menor\n  coincidan, y que el número de parche de la segunda versión sea _mayor o\n  igual al_ primer parámetro.\n\nLas funciones SemVer usan la [biblioteca semver de\nMasterminds](https://github.com/Masterminds/semver), de los creadores de Sprig.\n\n### Comparaciones Básicas\n\nHay dos elementos en las comparaciones. Primero, una cadena de comparación es una lista\nde comparaciones AND separadas por espacios o comas. Estas luego se separan por || (OR)\ncomparaciones. Por ejemplo, `\">= 1.2 < 3.0.0 || >= 4.2.3\"` busca una\ncomparación que sea mayor o igual a 1.2 y menor que 3.0.0 o sea mayor\no igual a 4.2.3.\n\nLas comparaciones básicas son:\n\n- `=`: igual (alias de ningún operador)\n- `!=`: no igual\n- `>`: mayor que\n- `<`: menor que\n- `>=`: mayor o igual que\n- `<=`: menor o igual que\n\n### Trabajando con Versiones Prerelease\n\nLos prereleases, para aquellos no familiarizados con ellos, se usan para lanzamientos de software\nantes de lanzamientos estables o disponibles de forma general. Ejemplos de prereleases incluyen\nlanzamientos de desarrollo, alpha, beta y release candidate. Un prerelease puede ser una\nversión como `1.2.3-beta.1`, mientras que el lanzamiento estable sería `1.2.3`. En el\norden de precedencia, los prereleases vienen antes de sus lanzamientos asociados. En este\nejemplo `1.2.3-beta.1 < 1.2.3`.\n\nSegún la especificación de Versiones Semánticas, los prereleases pueden no ser compatibles\ncon la API de su contraparte de lanzamiento. Dice,\n\n> Una versión prerelease indica que la versión es inestable y podría no\n> satisfacer los requisitos de compatibilidad previstos como lo denota su\n> versión normal asociada.\n\nLas comparaciones de SemVer usando restricciones sin un comparador de prerelease omitirán\nlas versiones prerelease. Por ejemplo, `>=1.2.3` omitirá prereleases al buscar\nen una lista de lanzamientos, mientras que `>=1.2.3-0` evaluará y encontrará prereleases.\n\nLa razón del `0` como versión prerelease en la comparación de ejemplo es\nporque los prereleases solo pueden contener alfanuméricos ASCII y guiones (junto\ncon separadores `.`), según la especificación. El ordenamiento ocurre en orden ASCII,\nnuevamente según la especificación. El carácter más bajo es un `0` en el orden ASCII (vea una [Tabla\nASCII](http://www.asciitable.com/))\n\nEntender el ordenamiento ASCII es importante porque A-Z viene antes de a-z.\nEso significa que `>=1.2.3-BETA` devolverá `1.2.3-alpha`. Lo que podría esperar de la\nsensibilidad a mayúsculas no aplica aquí. Esto se debe al ordenamiento ASCII que es lo que\nla especificación indica.\n\n### Comparaciones de Rango con Guion\n\nHay múltiples métodos para manejar rangos y el primero son los rangos con guion.\nEstos se ven así:\n\n- `1.2 - 1.4.5` que es equivalente a `>= 1.2 <= 1.4.5`\n- `2.3.4 - 4.5` que es equivalente a `>= 2.3.4 <= 4.5`\n\n### Comodines en Comparaciones\n\nLos caracteres `x`, `X`, y `*` pueden usarse como comodines. Esto funciona\npara todos los operadores de comparación. Cuando se usa en el operador `=` se retrocede al\nnivel de comparación de parche (ver tilde abajo). Por ejemplo,\n\n- `1.2.x` es equivalente a `>= 1.2.0, < 1.3.0`\n- `>= 1.2.x` es equivalente a `>= 1.2.0`\n- `<= 2.x` es equivalente a `< 3`\n- `*` es equivalente a `>= 0.0.0`\n\n### Comparaciones de Rango Tilde (Parche)\n\nEl operador de comparación tilde (`~`) es para rangos a nivel de parche cuando se especifica una versión\nmenor y cambios a nivel mayor cuando falta el número menor.\nPor ejemplo,\n\n- `~1.2.3` es equivalente a `>= 1.2.3, < 1.3.0`\n- `~1` es equivalente a `>= 1, < 2`\n- `~2.3` es equivalente a `>= 2.3, < 2.4`\n- `~1.2.x` es equivalente a `>= 1.2.0, < 1.3.0`\n- `~1.x` es equivalente a `>= 1, < 2`\n\n### Comparaciones de Rango Circunflejo (Mayor)\n\nEl operador de comparación circunflejo (`^`) es para cambios a nivel mayor una vez que ha ocurrido un\nlanzamiento estable (1.0.0). Antes de un lanzamiento 1.0.0, las versiones menores actúan\ncomo el nivel de estabilidad de la API. Esto es útil cuando las comparaciones de versiones de API como un\ncambio mayor es un cambio que rompe la API. Por ejemplo,\n\n- `^1.2.3` es equivalente a `>= 1.2.3, < 2.0.0`\n- `^1.2.x` es equivalente a `>= 1.2.0, < 2.0.0`\n- `^2.3` es equivalente a `>= 2.3, < 3`\n- `^2.x` es equivalente a `>= 2.0.0, < 3`\n- `^0.2.3` es equivalente a `>=0.2.3 <0.3.0`\n- `^0.2` es equivalente a `>=0.2.0 <0.3.0`\n- `^0.0.3` es equivalente a `>=0.0.3 <0.0.4`\n- `^0.0` es equivalente a `>=0.0.0 <0.1.0`\n- `^0` es equivalente a `>=0.0.0 <1.0.0`\n\n## Funciones de URL\n\nHelm incluye las funciones [urlParse](#urlparse), [urlJoin](#urljoin), y\n[urlquery](#urlquery) que le permiten trabajar con partes de URL.\n\n### urlParse\n\nParsea una cadena para URL y produce un dict con las partes de la URL\n\n```\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\nLo anterior devuelve un dict, conteniendo un objeto URL:\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nEsto se implementa usando los paquetes URL de la biblioteca estándar de Go. Para más\ninformación, consulte https://golang.org/pkg/net/url/#URL\n\n### urlJoin\n\nUne un mapa (producido por `urlParse`) para producir una cadena URL\n\n```\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\nLo anterior devuelve la siguiente cadena:\n```\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nDevuelve la versión escapada del valor pasado como argumento para que sea\nadecuado para incrustar en la parte de query de una URL.\n\n```\n$var := urlquery \"string for query\"\n```\n\n## Funciones de UUID\n\nHelm puede generar IDs universalmente únicos UUID v4.\n\n```\nuuidv4\n```\n\nLo anterior devuelve un nuevo UUID del tipo v4 (generado aleatoriamente).\n\n## Funciones de Kubernetes y Chart\n\nHelm incluye funciones para trabajar con Kubernetes incluyendo\n[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas),\n[Files](#funciones-de-archivos), y [lookup](#lookup).\n\n### lookup\n\n`lookup` se usa para buscar recursos en un clúster en ejecución. Cuando se usa con el\ncomando `helm template` siempre devuelve una respuesta vacía.\n\nPuede encontrar más detalles en la [documentación sobre la función\nlookup](./functions_and_pipelines.md#uso-de-la-función-lookup).\n\n### .Capabilities.APIVersions.Has\n\nDevuelve si una versión de API o recurso está disponible en un clúster.\n\n```\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\nMás información está disponible en la [documentación de objetos\nincorporados](./builtin_objects.md).\n\n### Funciones de Archivos\n\nHay varias funciones que le permiten acceder a archivos no especiales dentro de un\nchart. Por ejemplo, para acceder a archivos de configuración de aplicaciones. Estas están\ndocumentadas en [Acceder a Archivos Dentro de Plantillas](./accessing_files.md).\n\n_Nota, la documentación para muchas de estas funciones proviene de\n[Sprig](https://github.com/Masterminds/sprig). Sprig es una biblioteca de funciones de plantilla\ndisponible para aplicaciones Go._\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: Funciones de Plantilla y Pipelines\ndescription: Uso de funciones en plantillas.\nsidebar_position: 5\n---\n\nHasta ahora, hemos visto cómo colocar información en una plantilla. Pero esa\ninformación se coloca en la plantilla sin modificar. A veces queremos\ntransformar los datos suministrados de una manera que nos sea más útil.\n\nComencemos con una mejor práctica: Al inyectar cadenas del objeto `.Values` en\nla plantilla, debemos ponerlas entre comillas. Podemos hacer esto llamando a la\nfunción `quote` en la directiva de plantilla:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nLas funciones de plantilla siguen la sintaxis `functionName arg1 arg2...`. En el\nfragmento anterior, `quote .Values.favorite.drink` llama a la función `quote` y\nle pasa un solo argumento.\n\nHelm tiene más de 60 funciones disponibles. Algunas de ellas están definidas por\nel propio [lenguaje de plantillas de Go](https://godoc.org/text/template). La\nmayoría de las demás son parte de la [biblioteca de plantillas\nSprig](https://masterminds.github.io/sprig/). Veremos muchas de ellas a medida\nque avancemos a través de los ejemplos.\n\n> Aunque hablamos del \"lenguaje de plantillas de Helm\" como si fuera específico\n> de Helm, en realidad es una combinación del lenguaje de plantillas de Go,\n> algunas funciones adicionales y una variedad de wrappers para exponer ciertos\n> objetos a las plantillas. Muchos recursos sobre plantillas de Go pueden ser\n> útiles mientras aprende sobre plantillas.\n\n## Pipelines\n\nUna de las características más poderosas del lenguaje de plantillas es su\nconcepto de _pipelines_. Inspirándose en un concepto de UNIX, los pipelines son\nuna herramienta para encadenar una serie de comandos de plantilla y expresar de\nmanera compacta una serie de transformaciones. En otras palabras, los pipelines\nson una forma eficiente de realizar varias operaciones en secuencia. Reescribamos el\nejemplo anterior usando un pipeline.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nEn este ejemplo, en lugar de llamar a `quote ARGUMENT`, invertimos el orden.\n\"Enviamos\" el argumento a la función usando un pipeline (`|`):\n`.Values.favorite.drink | quote`. Usando pipelines, podemos encadenar varias\nfunciones juntas:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Invertir el orden es una práctica común en plantillas. Verá `.val | quote` más\n> a menudo que `quote .val`. Cualquiera de las dos prácticas está bien.\n\nCuando se evalúa, esa plantilla producirá esto:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nNote que nuestra `pizza` original ahora se ha transformado a `\"PIZZA\"`.\n\nCuando se encadenan argumentos de esta manera, el resultado de la primera\nevaluación (`.Values.favorite.drink`) se envía como el _último argumento de la\nfunción_. Podemos modificar el ejemplo de bebida anterior para ilustrar con una\nfunción que toma dos argumentos: `repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nLa función `repeat` repetirá la cadena dada el número de veces indicado, por lo\nque obtendremos esta salida:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Uso de la función `default`\n\nUna función que se usa con frecuencia en plantillas es la función `default`:\n`default DEFAULT_VALUE GIVEN_VALUE`. Esta función le permite especificar un\nvalor por defecto dentro de la plantilla, en caso de que el valor sea omitido.\nUsémosla para modificar el ejemplo de bebida anterior:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nSi ejecutamos esto de manera normal, obtendremos nuestro `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nAhora, eliminaremos la configuración de bebida favorita de `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nAhora volver a ejecutar `helm install --dry-run --debug fair-worm ./mychart`\nproducirá este YAML:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nEn un chart real, todos los valores por defecto estáticos deben estar en el\n`values.yaml`, y no deben repetirse usando el comando `default` (de lo contrario\nserían redundantes). Sin embargo, el comando `default` es perfecto para valores\ncalculados, que no pueden declararse dentro de `values.yaml`. Por ejemplo:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nEn algunos lugares, una condición `if` puede ser más adecuada que `default`.\nVeremos eso en la siguiente sección.\n\nLas funciones y pipelines de plantilla son una forma poderosa de transformar\ninformación y luego insertarla en su YAML. Pero a veces es necesario agregar\nalgo de lógica de plantilla que sea un poco más sofisticada que simplemente\ninsertar una cadena. En la siguiente sección veremos las estructuras de control\nproporcionadas por el lenguaje de plantillas.\n\n## Uso de la función `lookup`\n\nLa función `lookup` se puede usar para _buscar_ recursos en un clúster en\nejecución. La sinopsis de la función lookup es `lookup apiVersion, kind,\nnamespace, name -> resource or resource list`.\n\n| parámetro  | tipo   |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\nTanto `name` como `namespace` son opcionales y pueden pasarse como una cadena\nvacía (`\"\"`). Sin embargo, si está trabajando con un recurso con ámbito de\nnamespace, tanto `name` como `namespace` deben especificarse.\n\nLas siguientes combinaciones de parámetros son posibles:\n\n| Comportamiento                         | Función lookup                             |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\nCuando `lookup` devuelve un objeto, devolverá un diccionario. Este diccionario\nse puede navegar posteriormente para extraer valores específicos.\n\nEl siguiente ejemplo devolverá las anotaciones presentes para el objeto\n`mynamespace`:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nCuando `lookup` devuelve una lista de objetos, es posible acceder a la lista de\nobjetos a través del campo `items`:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* do something with each service */}}\n{{ end }}\n```\n\nCuando no se encuentra ningún objeto, se devuelve un valor vacío. Esto se puede\nusar para verificar la existencia de un objeto.\n\nLa función `lookup` usa la configuración de conexión de Kubernetes existente de\nHelm para consultar Kubernetes. Si se devuelve algún error al interactuar con\nel servidor de API (por ejemplo, debido a falta de permiso para acceder a un\nrecurso), el procesamiento de plantillas de Helm fallará.\n\nTenga en cuenta que Helm no está diseñado para contactar al servidor de API de\nKubernetes durante una operación `helm template|install|upgrade|delete|rollback --dry-run`.\nPara probar `lookup` contra un clúster en ejecución, debe usar\n`helm template|install|upgrade|delete|rollback --dry-run=server` en su lugar,\nlo que permite la conexión al clúster.\n\n## Los operadores son funciones\n\nPara las plantillas, los operadores (`eq`, `ne`, `lt`, `gt`, `and`, `or` y\ndemás) están todos implementados como funciones. En pipelines, las operaciones\nse pueden agrupar con paréntesis (`(` y `)`).\n\nAhora podemos pasar de funciones y pipelines al control de flujo con\ncondiciones, bucles y modificadores de alcance.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Primeros Pasos\ndescription: Una guía rápida sobre plantillas de Chart.\nsidebar_position: 2\n---\n\nEn esta sección de la guía, crearemos un chart y luego agregaremos una primera\nplantilla. El chart que creamos aquí se usará durante el resto de la guía.\n\nPara comenzar, echemos un vistazo rápido a un chart de Helm.\n\n## Charts\n\nComo se describe en la [Guía de Charts](/topics/charts.md), los charts de Helm\nestán estructurados así:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nEl directorio `templates/` es para archivos de plantilla. Cuando Helm evalúa un\nchart, envía todos los archivos del directorio `templates/` a través del motor\nde renderizado de plantillas. Luego recopila los resultados de esas plantillas\ny los envía a Kubernetes.\n\nEl archivo `values.yaml` también es importante para las plantillas. Este archivo\ncontiene los _valores por defecto_ de un chart. Estos valores pueden ser\nsobrescritos por los usuarios durante `helm install` o `helm upgrade`.\n\nEl archivo `Chart.yaml` contiene una descripción del chart. Puede acceder a él\ndesde dentro de una plantilla.\n\nEl directorio `charts/` _puede_ contener otros charts (que llamamos _subcharts_).\nMás adelante en esta guía veremos cómo funcionan cuando se trata de renderizado\nde plantillas.\n\n## Un Chart Inicial\n\nPara esta guía, crearemos un chart simple llamado `mychart`, y luego crearemos\nalgunas plantillas dentro del chart.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### Un Vistazo Rápido a `mychart/templates/`\n\nSi observa el directorio `mychart/templates/`, notará que ya hay algunos archivos\nallí.\n\n- `NOTES.txt`: El \"texto de ayuda\" para su chart. Se mostrará a los usuarios\n  cuando ejecuten `helm install`.\n- `deployment.yaml`: Un manifiesto básico para crear un\n  [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n  de Kubernetes\n- `service.yaml`: Un manifiesto básico para crear un [endpoint de\n  servicio](https://kubernetes.io/docs/concepts/services-networking/service/)\n  para su deployment\n- `_helpers.tpl`: Un lugar para colocar helpers de plantilla que puede reutilizar\n  en todo el chart\n\nY lo que vamos a hacer es... _¡eliminarlos todos!_ De esta manera podemos\ntrabajar en nuestro tutorial desde cero. En realidad, crearemos nuestros propios\n`NOTES.txt` y `_helpers.tpl` a medida que avancemos.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nCuando esté escribiendo charts de nivel de producción, tener versiones básicas\nde estos archivos puede ser muy útil. Así que en su trabajo diario de creación\nde charts, probablemente no querrá eliminarlos.\n\n## Una Primera Plantilla\n\nLa primera plantilla que vamos a crear será un `ConfigMap`. En Kubernetes, un\nConfigMap es simplemente un objeto para almacenar datos de configuración. Otras\ncosas, como los pods, pueden acceder a los datos en un ConfigMap.\n\nDebido a que los ConfigMaps son recursos básicos, son un excelente punto de\npartida para nosotros.\n\nComencemos creando un archivo llamado `mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**TIP:** Los nombres de plantilla no siguen un patrón de nomenclatura rígido.\nSin embargo, recomendamos usar la extensión `.yaml` para archivos YAML y `.tpl`\npara helpers.\n\nEl archivo YAML anterior es un ConfigMap básico, con los campos mínimos\nnecesarios. Por el hecho de que este archivo está en el directorio\n`mychart/templates/`, será enviado a través del motor de plantillas.\n\nEstá perfectamente bien colocar un archivo YAML simple como este en el\ndirectorio `mychart/templates/`. Cuando Helm lea esta plantilla, simplemente la\nenviará a Kubernetes tal cual.\n\nCon esta plantilla simple, ahora tenemos un chart instalable. Y podemos\ninstalarlo así:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nUsando Helm, podemos recuperar el release y ver la plantilla real que fue\ncargada.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nEl comando `helm get manifest` toma un nombre de release (`full-coral`) e\nimprime todos los recursos de Kubernetes que fueron subidos al servidor. Cada\narchivo comienza con `---` para indicar el inicio de un documento YAML, y luego\nes seguido por una línea de comentario generada automáticamente que nos dice\nqué archivo de plantilla generó este documento YAML.\n\nA partir de ahí, podemos ver que los datos YAML son exactamente lo que pusimos\nen nuestro archivo `configmap.yaml`.\n\nAhora podemos desinstalar nuestro release: `helm uninstall full-coral`.\n\n### Agregando una Llamada de Plantilla Simple\n\nCodificar el `name:` directamente en un recurso generalmente se considera una\nmala práctica. Los nombres deben ser únicos para un release. Por lo tanto,\npodríamos querer generar un campo de nombre insertando el nombre del release.\n\n**TIP:** El campo `name:` está limitado a 63 caracteres debido a limitaciones\ndel sistema DNS. Por esa razón, los nombres de release están limitados a 53\ncaracteres. Kubernetes 1.3 y versiones anteriores estaban limitados a solo 24\ncaracteres (por lo tanto, nombres de 14 caracteres).\n\nModifiquemos `configmap.yaml` en consecuencia.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nEl gran cambio viene en el valor del campo `name:`, que ahora es\n`{{ .Release.Name }}-configmap`.\n\n> Una directiva de plantilla está encerrada en bloques `{{` y `}}`.\n\nLa directiva de plantilla `{{ .Release.Name }}` inyecta el nombre del release en\nla plantilla. Los valores que se pasan a una plantilla pueden pensarse como\n_objetos con namespace_, donde un punto (`.`) separa cada elemento del namespace.\n\nEl punto inicial antes de `Release` indica que comenzamos con el namespace de\nnivel superior para este alcance (hablaremos sobre el alcance en un momento).\nAsí que podríamos leer `.Release.Name` como \"comenzar en el namespace superior,\nencontrar el objeto `Release`, luego buscar dentro de él un objeto llamado\n`Name`\".\n\nEl objeto `Release` es uno de los objetos integrados de Helm, y lo cubriremos\ncon más profundidad más adelante. Pero por ahora, es suficiente decir que esto\nmostrará el nombre del release que la biblioteca asigna a nuestro release.\n\nAhora cuando instalemos nuestro recurso, veremos inmediatamente el resultado de\nusar esta directiva de plantilla:\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nPuede ejecutar `helm get manifest clunky-serval` para ver todo el YAML generado.\n\nNote que el nombre del ConfigMap dentro de Kubernetes es\n`clunky-serval-configmap` en lugar de `mychart-configmap` como antes.\n\nEn este punto, hemos visto las plantillas en su forma más básica: archivos YAML\nque tienen directivas de plantilla incrustadas en `{{` y `}}`. En la siguiente\nparte, veremos más a fondo las plantillas. Pero antes de continuar, hay un\ntruco rápido que puede hacer que la construcción de plantillas sea más rápida:\nCuando quiera probar el renderizado de plantillas, pero no instalar nada\nrealmente, puede usar `helm install --debug --dry-run goodly-guppy ./mychart`.\nEsto renderizará las plantillas. Pero en lugar de instalar el chart, le\ndevolverá la plantilla renderizada para que pueda ver la salida:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nUsar `--dry-run` hará más fácil probar su código, pero no garantizará que\nKubernetes acepte las plantillas que genere. Es mejor no asumir que su chart se\ninstalará solo porque `--dry-run` funciona.\n\nEn la [Guía de Plantillas de Chart](/chart_template_guide/index.mdx), tomamos el\nchart básico que definimos aquí y exploramos el lenguaje de plantillas de Helm\nen detalle. Y comenzaremos con los objetos integrados.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: El archivo .helmignore\ndescription: El archivo `.helmignore` se usa para especificar archivos que no desea incluir en su chart de Helm.\nsidebar_position: 12\n---\n\nEl archivo `.helmignore` se usa para especificar archivos que no desea incluir\nen su chart de Helm.\n\nSi este archivo existe, el comando `helm package` ignorará todos los archivos\nque coincidan con el patrón especificado en el archivo `.helmignore` al\nempaquetar su chart.\n\nEsto puede ayudar a evitar que se agreguen archivos o directorios innecesarios\no sensibles en su chart de Helm.\n\nEl archivo `.helmignore` soporta coincidencia de patrones glob de shell Unix,\ncoincidencia de rutas relativas y negación (con prefijo !). Solo se considera\nun patrón por línea.\n\nAquí hay un ejemplo de un archivo `.helmignore`:\n\n```\n# comment\n\n# Match any file or path named .helmignore\n.helmignore\n\n# Match any file or path named .git\n.git\n\n# Match any text file\n*.txt\n\n# Match only directories named mydir\nmydir/\n\n# Match only text files in the top-level directory\n/*.txt\n\n# Match only the file foo.txt in the top-level directory\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt\na[b-d].txt\n\n# Match any file under subdir matching temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nAlgunas diferencias notables con respecto a .gitignore:\n- La sintaxis '**' no está soportada.\n- La biblioteca de coincidencia de patrones es 'filepath.Match' de Go, no fnmatch(3)\n- Los espacios finales siempre se ignoran (no hay secuencia de escape soportada)\n- No hay soporte para '\\!' como secuencia inicial especial.\n- No se excluye a sí mismo de forma predeterminada, debe agregar una entrada explícita para `.helmignore`\n\n\n**Nos encantaría su ayuda** para mejorar este documento. Para agregar, corregir\no eliminar información, [abra un issue](https://github.com/helm/helm-www/issues)\no envíenos un pull request.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Plantillas con Nombre\ndescription: Cómo definir plantillas con nombre.\nsidebar_position: 9\n---\n\nHa llegado el momento de ir más allá de una sola plantilla y comenzar a crear\notras. En esta sección, veremos cómo definir _plantillas con nombre_ en un\narchivo y luego usarlas en otros lugares. Una _plantilla con nombre_ (a veces\nllamada _parcial_ o _subplantilla_) es simplemente una plantilla definida dentro\nde un archivo a la que se le asigna un nombre. Veremos dos formas de crearlas y\nvarias formas diferentes de usarlas.\n\nEn la sección de [Estructuras de Control](./control_structures.md) presentamos\ntres acciones para declarar y gestionar plantillas: `define`, `template` y\n`block`. En esta sección, cubriremos esas tres acciones y también presentaremos\nuna función especial `include` que funciona de manera similar a la acción\n`template`.\n\nEs importante recordar al nombrar plantillas: **los nombres de las plantillas\nson globales**. Si declara dos plantillas con el mismo nombre, la que se cargue\nen último lugar será la que se use. Como las plantillas en subcharts se compilan\njunto con las plantillas de nivel superior, debe tener cuidado de nombrar sus\nplantillas con _nombres específicos del chart_.\n\nUna convención de nomenclatura popular es prefijar cada plantilla definida con\nel nombre del chart: `{{ define \"mychart.labels\" }}`. Al usar el nombre\nespecífico del chart como prefijo, podemos evitar cualquier conflicto que pueda\nsurgir debido a dos charts diferentes que implementan plantillas con el mismo\nnombre.\n\nEste comportamiento también se aplica a diferentes versiones de un chart. Si\ntiene `mychart` versión `1.0.0` que define una plantilla de cierta manera, y\n`mychart` versión `2.0.0` que modifica la plantilla con nombre existente, se\nusará la que se cargó en último lugar. Puede solucionar este problema agregando\ntambién una versión en el nombre del chart: `{{ define \"mychart.v1.labels\" }}` y\n`{{ define \"mychart.v2.labels\" }}`.\n\n## Parciales y archivos `_`\n\nHasta ahora, hemos usado un solo archivo, y ese archivo contenía una sola\nplantilla. Pero el lenguaje de plantillas de Helm le permite crear plantillas\ncon nombre incrustadas, a las que se puede acceder por nombre desde cualquier\notro lugar.\n\nAntes de entrar en los detalles de cómo escribir esas plantillas, hay una\nconvención de nomenclatura de archivos que merece mención:\n\n* La mayoría de los archivos en `templates/` se tratan como si contuvieran\n  manifiestos de Kubernetes\n* `NOTES.txt` es una excepción\n* Pero los archivos cuyo nombre comienza con un guion bajo (`_`) se asumen como\n  que _no_ contienen un manifiesto. Estos archivos no se renderizan como\n  definiciones de objetos de Kubernetes, pero están disponibles en todas las\n  demás plantillas del chart para su uso.\n\nEstos archivos se usan para almacenar parciales y helpers. De hecho, cuando\ncreamos `mychart` por primera vez, vimos un archivo llamado `_helpers.tpl`. Ese\narchivo es la ubicación predeterminada para parciales de plantillas.\n\n## Declarar y usar plantillas con `define` y `template`\n\nLa acción `define` nos permite crear una plantilla con nombre dentro de un\narchivo de plantilla. Su sintaxis es la siguiente:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # body of template here\n{{- end }}\n```\n\nPor ejemplo, podemos definir una plantilla para encapsular un bloque de\netiquetas de Kubernetes:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nAhora podemos incrustar esta plantilla dentro de nuestro ConfigMap existente, y\nluego incluirla con la acción `template`:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nCuando el motor de plantillas lee este archivo, almacenará la referencia a\n`mychart.labels` hasta que se llame a `template \"mychart.labels\"`. Luego\nrenderizará esa plantilla en línea. Así que el resultado se verá así:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nNota: un `define` no produce salida a menos que se llame con template, como en\neste ejemplo.\n\nPor convención, los charts de Helm colocan estas plantillas dentro de un archivo\nde parciales, generalmente `_helpers.tpl`. Movamos esta función allí:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nPor convención, las funciones `define` deben tener un bloque de documentación\nsimple (`{{/* ... */}}`) que describa lo que hacen.\n\nAunque esta definición está en `_helpers.tpl`, todavía se puede acceder a ella\ndesde `configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nComo se mencionó anteriormente, **los nombres de las plantillas son globales**.\nComo resultado, si dos plantillas se declaran con el mismo nombre, la última que\naparezca será la que se use. Dado que las plantillas en subcharts se compilan\njunto con las plantillas de nivel superior, es mejor nombrar sus plantillas con\n_nombres específicos del chart_. Una convención de nomenclatura popular es\nprefijar cada plantilla definida con el nombre del chart:\n`{{ define \"mychart.labels\" }}`.\n\n## Establecer el ámbito de una plantilla\n\nEn la plantilla que definimos anteriormente, no usamos ningún objeto. Solo\nusamos funciones. Modifiquemos nuestra plantilla definida para incluir el nombre\ndel chart y la versión del chart:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nSi renderizamos esto, obtendremos un error como este:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nPara ver qué se renderizó, vuelva a ejecutar con `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`.\nEl resultado no será el que esperamos:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\n¿Qué pasó con el nombre y la versión? No estaban en el ámbito de nuestra\nplantilla definida. Cuando se renderiza una plantilla con nombre (creada con\n`define`), recibirá el ámbito pasado por la llamada `template`. En nuestro\nejemplo, incluimos la plantilla así:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nNo se pasó ningún ámbito, por lo que dentro de la plantilla no podemos acceder a\nnada en `.`. Esto es fácil de arreglar. Basta con pasar un ámbito a la plantilla:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nObserve que pasamos `.` al final de la llamada `template`. También podríamos\npasar `.Values` o `.Values.favorite` o cualquier ámbito que deseemos. Pero lo\nque queremos es el ámbito de nivel superior. En el contexto de la plantilla con\nnombre, `$` se referirá al ámbito que pasó y no a algún ámbito global.\n\nAhora, cuando ejecutamos esta plantilla con `helm install --dry-run --debug\nplinking-anaco ./mychart`, obtenemos esto:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nAhora `{{ .Chart.Name }}` se resuelve a `mychart`, y `{{ .Chart.Version }}` se\nresuelve a `0.1.0`.\n\n## La función `include`\n\nDigamos que hemos definido una plantilla simple que se ve así:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nAhora supongamos que quiero insertar esto tanto en la sección `labels:` de mi\nplantilla como en la sección `data:`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nSi renderizamos esto, obtendremos un error como este:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nPara ver qué se renderizó, vuelva a ejecutar con `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`.\nLa salida no será la que esperamos:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nObserve que la indentación de `app_version` es incorrecta en ambos lugares.\n¿Por qué? Porque la plantilla que se sustituye tiene el texto alineado a la\nizquierda. Como `template` es una acción, y no una función, no hay forma de\npasar la salida de una llamada `template` a otras funciones; los datos\nsimplemente se insertan en línea.\n\nPara solucionar este caso, Helm proporciona una alternativa a `template` que\nimportará el contenido de una plantilla al pipeline actual donde puede pasarse\na otras funciones en el pipeline.\n\nAquí está el ejemplo anterior, corregido para usar `indent` para indentar la\nplantilla `mychart.app` correctamente:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nAhora el YAML producido está correctamente indentado para cada sección:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> Es preferible usar `include` en lugar de `template` en las plantillas de Helm\n> simplemente para que el formato de salida pueda manejarse mejor en documentos\n> YAML.\n\nA veces queremos importar contenido, pero no como plantillas. Es decir, queremos\nimportar archivos literalmente. Podemos lograr esto accediendo a los archivos a\ntravés del objeto `.Files` descrito en la siguiente sección.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Creación de un Archivo NOTES.txt\ndescription: Cómo proporcionar instrucciones a los usuarios de su Chart.\nsidebar_position: 10\n---\n\nEn esta sección vamos a ver la herramienta de Helm para proporcionar\ninstrucciones a los usuarios de su chart. Al finalizar un `helm install` o\n`helm upgrade`, Helm puede mostrar un bloque de información útil para los\nusuarios. Esta información es altamente personalizable mediante plantillas.\n\nPara agregar notas de instalación a su chart, simplemente cree un archivo\n`templates/NOTES.txt`. Este archivo es texto plano, pero se procesa como una\nplantilla, y tiene todas las funciones y objetos de plantilla normales\ndisponibles.\n\nCreemos un archivo `NOTES.txt` simple:\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nAhora, si ejecutamos `helm install rude-cardinal ./mychart`, veremos este mensaje\nal final:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nUsar `NOTES.txt` de esta manera es una excelente forma de proporcionar a sus\nusuarios información detallada sobre cómo usar su chart recién instalado. Se\nrecomienda encarecidamente crear un archivo `NOTES.txt`, aunque no es obligatorio.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Subcharts y Valores Globales\ndescription: Interacción con subcharts y valores globales.\nsidebar_position: 11\n---\n\nHasta este punto hemos trabajado solo con un chart. Pero los charts pueden tener\ndependencias, llamadas _subcharts_, que también tienen sus propios values y\nplantillas. En esta sección crearemos un subchart y veremos las diferentes\nformas en que podemos acceder a los values desde las plantillas.\n\nAntes de profundizar en el código, hay algunos detalles importantes que aprender\nsobre los subcharts de aplicaciones.\n\n1. Un subchart se considera \"independiente\", lo que significa que un subchart\n   nunca puede depender explícitamente de su chart padre.\n2. Por esa razón, un subchart no puede acceder a los values de su padre.\n3. Un chart padre puede sobrescribir values para los subcharts.\n4. Helm tiene un concepto de _valores globales_ que pueden ser accedidos por\n   todos los charts.\n\n> Estas limitaciones no necesariamente aplican a los [charts de biblioteca](/topics/library_charts.md), que están diseñados para proporcionar funcionalidad auxiliar estandarizada.\n\nA medida que recorramos los ejemplos en esta sección, muchos de estos conceptos\nquedarán más claros.\n\n## Creación de un Subchart\n\nPara estos ejercicios, comenzaremos con el chart `mychart/` que creamos al\ninicio de esta guía, y agregaremos un nuevo chart dentro de él.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nObserve que, al igual que antes, eliminamos todas las plantillas base para poder\ncomenzar desde cero. En esta guía, nos enfocamos en cómo funcionan las plantillas,\nno en gestionar dependencias. Sin embargo, la [Guía de Charts](/topics/charts.md)\ntiene más información sobre cómo funcionan los subcharts.\n\n## Agregar Values y una Plantilla al Subchart\n\nA continuación, crearemos una plantilla simple y un archivo values para nuestro\nchart `mysubchart`. Ya debería existir un `values.yaml` en\n`mychart/charts/mysubchart`. Lo configuraremos así:\n\n```yaml\ndessert: cake\n```\n\nLuego, crearemos una nueva plantilla de ConfigMap en\n`mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nComo cada subchart es un _chart independiente_, podemos probar `mysubchart` por\nsí solo:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Sobrescribir Values desde un Chart Padre\n\nNuestro chart original, `mychart`, ahora es el _chart padre_ de `mysubchart`.\nEsta relación se basa completamente en el hecho de que `mysubchart` está dentro\nde `mychart/charts`.\n\nComo `mychart` es el padre, podemos especificar configuración en `mychart` y\nhacer que esa configuración se pase a `mysubchart`. Por ejemplo, podemos\nmodificar `mychart/values.yaml` de esta forma:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nObserve las últimas dos líneas. Cualquier directiva dentro de la sección\n`mysubchart` se pasará al chart `mysubchart`. Entonces, si ejecutamos\n`helm install --generate-name --dry-run --debug mychart`, una de las cosas que\nveremos es el ConfigMap de `mysubchart`:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nEl valor en el nivel superior ahora ha sobrescrito el valor del subchart.\n\nHay un detalle importante que notar aquí. No cambiamos la plantilla de\n`mychart/charts/mysubchart/templates/configmap.yaml` para que apunte a\n`.Values.mysubchart.dessert`. Desde la perspectiva de esa plantilla, el valor\ntodavía está ubicado en `.Values.dessert`. A medida que el motor de plantillas\npasa los values, establece el ámbito. Así que para las plantillas de `mysubchart`,\nsolo los values específicamente para `mysubchart` estarán disponibles en `.Values`.\n\nSin embargo, a veces querrá que ciertos valores estén disponibles para todas las\nplantillas. Esto se logra usando valores globales de chart.\n\n## Valores Globales de Chart\n\nLos valores globales son valores a los que se puede acceder desde cualquier chart\no subchart con exactamente el mismo nombre. Los globales requieren declaración\nexplícita. No se puede usar un valor no global existente como si fuera global.\n\nEl tipo de datos Values tiene una sección reservada llamada `Values.global` donde\nse pueden establecer valores globales. Establezcamos uno en nuestro archivo\n`mychart/values.yaml`.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nDebido a cómo funcionan los globales, tanto `mychart/templates/configmap.yaml`\ncomo `mysubchart/templates/configmap.yaml` deberían poder acceder a ese valor\ncomo `{{ .Values.global.salad }}`.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nAhora, si ejecutamos una instalación en modo dry run, veremos el mismo valor en\nambas salidas:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nLos globales son útiles para pasar información como esta, aunque requiere cierta\nplanificación para asegurarse de que las plantillas correctas estén configuradas\npara usar globales.\n\n## Compartir Plantillas con Subcharts\n\nLos charts padres y los subcharts pueden compartir plantillas. Cualquier bloque\ndefinido en cualquier chart está disponible para otros charts.\n\nPor ejemplo, podemos definir una plantilla simple como esta:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nRecuerde que las etiquetas en las plantillas se _comparten globalmente_. Por lo\ntanto, el chart `labels` puede incluirse desde cualquier otro chart.\n\nMientras que los desarrolladores de charts pueden elegir entre `include` y\n`template`, una ventaja de usar `include` es que puede referenciar plantillas\ndinámicamente:\n\n```yaml\n{{ include $mytemplate }}\n```\n\nLo anterior desreferenciará `$mytemplate`. La función `template`, en contraste,\nsolo acepta un literal de cadena.\n\n## Evitar el Uso de Blocks\n\nEl lenguaje de plantillas de Go proporciona una palabra clave `block` que permite\na los desarrolladores proporcionar una implementación por defecto que se\nsobrescribe después. En los charts de Helm, los blocks no son la mejor herramienta\npara sobrescribir porque si se proporcionan múltiples implementaciones del mismo\nblock, la seleccionada es impredecible.\n\nSe recomienda usar `include` en su lugar.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Archivos Values\ndescription: Instrucciones sobre cómo usar la opción --values.\nsidebar_position: 4\n---\n\nEn la sección anterior vimos los objetos integrados que ofrecen las plantillas\nde Helm. Uno de los objetos integrados es `Values`. Este objeto permite acceder\na los valores que se pasan al chart. Su contenido proviene de múltiples fuentes:\n\n- El archivo `values.yaml` en el chart\n- Si es un subchart, el archivo `values.yaml` de un chart padre\n- Un archivo values pasado a `helm install` o `helm upgrade` con la opción `-f`\n  (`helm install -f myvals.yaml ./mychart`)\n- Parámetros individuales pasados con `--set` (como `helm install --set foo=bar\n  ./mychart`)\n\nLa lista anterior está en orden de prioridad: `values.yaml` es el valor por\ndefecto, que puede ser sobrescrito por el `values.yaml` de un chart padre, que\na su vez puede ser sobrescrito por un archivo values proporcionado por el usuario,\nque a su vez puede ser sobrescrito por los parámetros `--set`.\n\nLos archivos values son archivos YAML simples. Editemos `mychart/values.yaml` y\nluego editemos nuestra plantilla de ConfigMap.\n\nEliminando los valores por defecto en `values.yaml`, estableceremos solo un\nparámetro:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nAhora podemos usar esto dentro de una plantilla:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nObserve en la última línea que accedemos a `favoriteDrink` como un atributo de\n`Values`: `{{ .Values.favoriteDrink }}`.\n\nVeamos cómo se renderiza.\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nDado que `favoriteDrink` está configurado en el archivo `values.yaml` por\ndefecto como `coffee`, ese es el valor que se muestra en la plantilla. Podemos\nsobrescribirlo fácilmente agregando una opción `--set` en nuestra llamada a\n`helm install`:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nDado que `--set` tiene mayor prioridad que el archivo `values.yaml` por defecto,\nnuestra plantilla genera `drink: slurm`.\n\nLos archivos values también pueden contener contenido más estructurado. Por\nejemplo, podríamos crear una sección `favorite` en nuestro archivo `values.yaml`\ny agregar varias claves allí:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nAhora tendríamos que modificar ligeramente la plantilla:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nAunque es posible estructurar los datos de esta manera, la recomendación es\nmantener los árboles de values poco profundos, favoreciendo una estructura plana.\nCuando veamos cómo asignar valores a subcharts, veremos cómo los values se\nnombran usando una estructura de árbol.\n\n## Eliminar una clave por defecto\n\nSi necesita eliminar una clave de los values por defecto, puede sobrescribir el\nvalor de la clave como `null`, en cuyo caso Helm eliminará la clave de la fusión\nde valores sobrescritos.\n\nPor ejemplo, el chart estable de Drupal permite configurar el liveness probe,\nen caso de que configure una imagen personalizada. Estos son los valores por\ndefecto:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nSi intenta sobrescribir el handler del livenessProbe a `exec` en lugar de\n`httpGet` usando `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`,\nHelm fusionará las claves por defecto y las sobrescritas, resultando en el\nsiguiente YAML:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nSin embargo, Kubernetes fallaría porque no se puede declarar más de un handler\nde livenessProbe. Para resolver esto, puede indicar a Helm que elimine\n`livenessProbe.httpGet` estableciéndolo como null:\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nEn este punto, hemos visto varios objetos integrados y los hemos usado para\ninyectar información en una plantilla. Ahora veremos otro aspecto del motor de\nplantillas: funciones y pipelines.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: Variables\ndescription: Uso de variables en plantillas.\nsidebar_position: 8\n---\n\nCon funciones, pipelines, objetos y estructuras de control ya dominados, podemos\nabordar una de las ideas más básicas en muchos lenguajes de programación: las\nvariables. En las plantillas, se usan con menos frecuencia. Pero veremos cómo\nusarlas para simplificar el código y aprovechar mejor `with` y `range`.\n\nEn un ejemplo anterior, vimos que este código fallará:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` no está dentro del ámbito restringido en el bloque `with`.\nUna forma de solucionar los problemas de ámbito es asignar objetos a variables\na las que se puede acceder independientemente del ámbito actual.\n\nEn las plantillas de Helm, una variable es una referencia con nombre a otro\nobjeto. Sigue la forma `$nombre`. Las variables se asignan con un operador de\nasignación especial: `:=`. Podemos reescribir lo anterior para usar una variable\npara `Release.Name`.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nObserve que antes de comenzar el bloque `with`, asignamos `$relname :=\n.Release.Name`. Ahora, dentro del bloque `with`, la variable `$relname` todavía\napunta al nombre del release.\n\nEjecutar eso producirá lo siguiente:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nLas variables son particularmente útiles en los bucles `range`. Se pueden usar\nen objetos tipo lista para capturar tanto el índice como el valor:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nTenga en cuenta que `range` va primero, luego las variables, luego el operador\nde asignación y finalmente la lista. Esto asignará el índice entero (comenzando\ndesde cero) a `$index` y el valor a `$topping`. Ejecutarlo producirá:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nPara estructuras de datos que tienen tanto una clave como un valor, podemos usar\n`range` para obtener ambos. Por ejemplo, podemos recorrer `.Values.favorite`\nde esta manera:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nAhora, en la primera iteración, `$key` será `drink` y `$val` será `coffee`,\ny en la segunda, `$key` será `food` y `$val` será `pizza`. Ejecutar lo anterior\ngenerará esto:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nLas variables normalmente no son \"globales\". Tienen un ámbito limitado al bloque\nen el que se declaran. Anteriormente, asignamos `$relname` en el nivel superior\nde la plantilla. Esa variable estará en el ámbito de toda la plantilla. Pero en\nnuestro último ejemplo, `$key` y `$val` solo estarán en el ámbito dentro del\nbloque `{{ range... }}{{ end }}`.\n\nSin embargo, hay una variable que siempre apuntará al contexto raíz: `$`.\nEsto puede ser muy útil cuando está iterando en un range y necesita conocer\nel nombre del release del chart.\n\nUn ejemplo que ilustra esto:\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Muchas plantillas de helm usarían `.` a continuación, pero eso no funcionará,\n    # sin embargo `$` funcionará aquí\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # No puedo referenciar .Chart.Name, pero puedo hacer $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Valor de appVersion en Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nHasta ahora hemos visto solo una plantilla declarada en un solo archivo. Pero una\nde las características más poderosas del lenguaje de plantillas de Helm es su\ncapacidad para declarar múltiples plantillas y usarlas juntas. Lo veremos en la\nsiguiente sección.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Próximos Pasos\ndescription: Conclusión - algunos enlaces útiles a otra documentación que le será de ayuda.\nsidebar_position: 14\n---\n\nEsta guía está diseñada para darle a usted, el desarrollador de charts, una\ncomprensión sólida de cómo usar el lenguaje de plantillas de Helm. La guía se\ncentra en los aspectos técnicos del desarrollo de plantillas.\n\nPero hay muchas cosas que esta guía no ha cubierto en lo que respecta al\ndesarrollo práctico de charts en el día a día. Aquí hay algunos enlaces útiles\na otra documentación que le ayudará a medida que cree nuevos charts:\n\n- El [Artifact Hub](https://artifacthub.io/packages/search?kind=0) de CNCF es una\n  fuente indispensable de charts.\n- La [Documentación](https://kubernetes.io/docs/home/) de Kubernetes proporciona\n  ejemplos detallados de los diversos tipos de recursos que puede usar, desde\n  ConfigMaps y Secrets hasta DaemonSets y Deployments.\n- La [Guía de Charts](/topics/charts.md) de Helm explica el flujo de trabajo del\n  uso de charts.\n- La [Guía de Hooks de Charts](/topics/charts_hooks.md) de Helm explica cómo\n  crear hooks de ciclo de vida.\n- El artículo [Consejos y Trucos de Charts](/howto/charts_tips_and_tricks.md) de\n  Helm proporciona algunos consejos útiles para escribir charts.\n- La [documentación de Sprig](https://github.com/Masterminds/sprig) documenta más\n  de sesenta funciones de plantilla.\n- La [documentación de plantillas de Go](https://godoc.org/text/template) explica\n  la sintaxis de plantillas en detalle.\n- La [herramienta Schelm](https://github.com/databus23/schelm) es una utilidad\n  auxiliar muy útil para depurar charts.\n\nA veces es más fácil hacer algunas preguntas y obtener respuestas de\ndesarrolladores experimentados. El mejor lugar para hacerlo es en los canales de\nHelm en [Kubernetes Slack](https://kubernetes.slack.com):\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nFinalmente, si encuentra errores u omisiones en este documento, desea sugerir\ncontenido nuevo o le gustaría contribuir, visite [The Helm\nProject](https://github.com/helm/helm-www).\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Apéndice: Técnicas de YAML\"\ndescription: Una mirada más detallada a la especificación YAML y cómo se aplica a Helm.\nsidebar_position: 15\n---\n\nLa mayor parte de esta guía se ha centrado en escribir el lenguaje de plantillas.\nAquí veremos el formato YAML. YAML tiene algunas características útiles que\nnosotros, como autores de plantillas, podemos usar para hacer nuestras plantillas\nmenos propensas a errores y más fáciles de leer.\n\n## Escalares y Colecciones\n\nSegún la [especificación YAML](https://yaml.org/spec/1.2/spec.html), hay dos\ntipos de colecciones y muchos tipos escalares.\n\nLos dos tipos de colecciones son mapas y secuencias:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nLos valores escalares son valores individuales (a diferencia de las colecciones)\n\n### Tipos Escalares en YAML\n\nEn el dialecto de YAML de Helm, el tipo de dato escalar de un valor se determina\npor un conjunto complejo de reglas, incluyendo el esquema de Kubernetes para las\ndefiniciones de recursos. Pero al inferir tipos, las siguientes reglas tienden\na aplicarse.\n\nSi un entero o flotante es una palabra sin comillas, normalmente se trata como\nun tipo numérico:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nPero si están entre comillas, se tratan como cadenas:\n\n```yaml\ncount: \"1\" # <-- cadena, no int\nsize: '2.34' # <-- cadena, no float\n```\n\nLo mismo aplica para los booleanos:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # cadena\n```\n\nEl valor nulo se representa como `null` (no `nil`).\n\nTenga en cuenta que `port: \"80\"` es YAML válido y pasará tanto por el motor de\nplantillas como por el analizador YAML, pero fallará si Kubernetes espera que\n`port` sea un entero.\n\nEn algunos casos, puede forzar una inferencia de tipo particular usando etiquetas\nde nodo YAML:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nEn el ejemplo anterior, `!!str` le dice al analizador que `age` es una cadena,\naunque parezca un int. Y `port` se trata como un int, aunque esté entre comillas.\n\n\n## Cadenas en YAML\n\nGran parte de los datos que colocamos en documentos YAML son cadenas. YAML tiene\nmás de una forma de representar una cadena. Esta sección explica las formas y\ndemuestra cómo usar algunas de ellas.\n\nHay tres formas \"en línea\" de declarar una cadena:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nTodos los estilos en línea deben estar en una sola línea.\n\n- Las palabras sin comillas no están entre comillas y no se escapan. Por esta\n  razón, debe tener cuidado con los caracteres que usa.\n- Las cadenas entre comillas dobles pueden tener caracteres específicos escapados\n  con `\\`. Por ejemplo `\"\\\"Hello\\\", she said\"`. Puede escapar saltos de línea con `\\n`.\n- Las cadenas entre comillas simples son cadenas \"literales\" y no usan `\\` para\n  escapar caracteres. La única secuencia de escape es `''`, que se decodifica\n  como una sola `'`.\n\nAdemás de las cadenas de una línea, puede declarar cadenas multilínea:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nEl ejemplo anterior trata el valor de `coffee` como una sola cadena equivalente\na `Latte\\nCappuccino\\nEspresso\\n`.\n\nTenga en cuenta que la primera línea después de `|` debe tener la indentación\ncorrecta. Podríamos causar un error en el ejemplo anterior haciendo esto:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nComo `Latte` tiene una indentación incorrecta, obtendríamos un error como este:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nEn las plantillas, a veces es más seguro poner una \"primera línea\" falsa de\ncontenido en un documento multilínea solo para protegerse del error anterior:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nTenga en cuenta que cualquiera que sea esa primera línea, se conservará en la\nsalida de la cadena. Entonces, si está usando esta técnica para inyectar el\ncontenido de un archivo en un ConfigMap, el comentario debe ser del tipo\nesperado por lo que esté leyendo esa entrada.\n\n### Control de Espacios en Cadenas Multilínea\n\nEn el ejemplo anterior, usamos `|` para indicar una cadena multilínea. Pero\nobserve que el contenido de nuestra cadena fue seguido por un `\\n` final. Si\nqueremos que el procesador YAML elimine el salto de línea final, podemos agregar\nun `-` después del `|`:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nAhora el valor de `coffee` será: `Latte\\nCappuccino\\nEspresso` (sin `\\n` final).\n\nOtras veces, podríamos querer que se conserven todos los espacios en blanco\nfinales. Podemos hacer esto con la notación `|+`:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nAhora el valor de `coffee` será `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nLa indentación dentro de un bloque de texto se conserva, y también resulta en\nla conservación de los saltos de línea:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nEn el caso anterior, `coffee` será `Latte\\n  12 oz\\n  16\noz\\nCappuccino\\nEspresso`.\n\n### Indentación y Plantillas\n\nAl escribir plantillas, es posible que desee inyectar el contenido de un archivo\nen la plantilla. Como vimos en capítulos anteriores, hay dos formas de hacer esto:\n\n- Use `{{ .Files.Get \"FILENAME\" }}` para obtener el contenido de un archivo en\n  el chart.\n- Use `{{ include \"TEMPLATE\" . }}` para renderizar una plantilla y luego colocar\n  su contenido en el chart.\n\nAl insertar archivos en YAML, es bueno entender las reglas de multilínea\nanteriores. A menudo, la forma más fácil de insertar un archivo estático es\nhacer algo como esto:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nObserve cómo hacemos la indentación anterior: `indent 2` le dice al motor de\nplantillas que indente cada línea en \"myfile.txt\" con dos espacios. Tenga en\ncuenta que no indentamos esa línea de plantilla. Eso es porque si lo hiciéramos,\nel contenido del archivo de la primera línea estaría indentado dos veces.\n\n### Cadenas Multilínea Plegadas (Folded)\n\nA veces quiere representar una cadena en su YAML con múltiples líneas, pero\nquiere que se trate como una sola línea larga cuando se interprete. A esto se\nle llama \"folding\" (plegado). Para declarar un bloque plegado, use `>` en lugar de `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nEl valor de `coffee` anterior será `Latte Cappuccino Espresso\\n`. Tenga en\ncuenta que todos los saltos de línea excepto el último se convertirán en\nespacios. Puede combinar los controles de espacios en blanco con el marcador\nde texto plegado, así que `>-` reemplazará o recortará todos los saltos de línea.\n\nTenga en cuenta que en la sintaxis plegada, indentar texto hará que las líneas\nse conserven.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nLo anterior producirá `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Observe\nque tanto los espacios como los saltos de línea siguen ahí.\n\n## Incrustando Múltiples Documentos en Un Archivo\n\nEs posible colocar más de un documento YAML en un solo archivo. Esto se hace\nprefijando un nuevo documento con `---` y terminando el documento con `...`\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nEn muchos casos, se puede omitir ya sea `---` o `...`.\n\nAlgunos archivos en Helm no pueden contener más de un documento. Si, por ejemplo,\nse proporciona más de un documento dentro de un archivo `values.yaml`, solo se\nusará el primero.\n\nSin embargo, los archivos de plantilla pueden tener más de un documento. Cuando\nesto sucede, el archivo (y todos sus documentos) se trata como un objeto durante\nel renderizado de la plantilla. Pero luego el YAML resultante se divide en\nmúltiples documentos antes de enviarse a Kubernetes.\n\nRecomendamos usar múltiples documentos por archivo solo cuando sea absolutamente\nnecesario. Tener múltiples documentos en un archivo puede ser difícil de depurar.\n\n## YAML es un Superconjunto de JSON\n\nDebido a que YAML es un superconjunto de JSON, cualquier documento JSON válido\n_debería_ ser YAML válido.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nLo anterior es otra forma de representar esto:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nY los dos se pueden mezclar (con cuidado):\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nLos tres deberían analizarse en la misma representación interna.\n\nSi bien esto significa que archivos como `values.yaml` pueden contener datos\nJSON, Helm no trata la extensión de archivo `.json` como un sufijo válido.\n\n## Anclas YAML\n\nLa especificación YAML proporciona una forma de almacenar una referencia a un\nvalor y luego referirse a ese valor por referencia. YAML llama a esto \"anclaje\":\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nEn lo anterior, `&favoriteCoffee` establece una referencia a `Cappuccino`. Más\ntarde, esa referencia se usa como `*favoriteCoffee`. Entonces `coffees` se\nconvierte en `Latte, Cappuccino, Espresso`.\n\nSi bien hay algunos casos donde las anclas son útiles, hay un aspecto de ellas\nque puede causar errores sutiles: La primera vez que se consume el YAML, la\nreferencia se expande y luego se descarta.\n\nEntonces, si decodificáramos y luego recodificáramos el ejemplo anterior, el\nYAML resultante sería:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nDebido a que Helm y Kubernetes a menudo leen, modifican y luego reescriben\narchivos YAML, las anclas se perderán.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: Cambios desde Helm 2\nsidebar_position: 1\n---\n\n## Cambios desde Helm 2\n\nEsta es una lista exhaustiva de todos los cambios principales introducidos en Helm 3.\n\n### Eliminación de Tiller\n\nDurante 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.\n\nCon 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.\n\nDespué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.\n\nEl 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.\n\nSin 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.\n\n### Estrategia de actualización mejorada: parches de fusión estratégica de tres vías\n\nHelm 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.\n\nEn 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.\n\n#### Ejemplos\n\nVeamos algunos ejemplos comunes de cómo este cambio impacta.\n\n##### Reversión cuando el estado en vivo ha cambiado\n\nSu 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:\n\n```console\n$ helm install myapp ./myapp\n```\n\nUn 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.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nOtro desarrollador de su equipo nota que el sitio de producción está caído y decide revertir el release a su estado anterior:\n\n```console\n$ helm rollback myapp\n```\n\n¿Qué sucede?\n\nEn 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.\n\nEn 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.\n\n##### Actualizaciones cuando el estado en vivo ha cambiado\n\nMuchas 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:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nY el estado en vivo fue modificado por otra aplicación a:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nAhora, desea actualizar la etiqueta de imagen de `nginx` a `2.1.0`. Entonces, actualiza a un chart con el siguiente manifiesto:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\n¿Qué sucede?\n\nEn 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.\n\nEl estado en vivo del clúster se modifica para verse así:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nEl pod sidecar se elimina del estado en vivo. Cunde más pánico.\n\nEn 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.\n\nEl estado en vivo del clúster se modifica para verse así:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### Los nombres de releases ahora tienen alcance de namespace\n\nCon 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.\n\nEn 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`).\n\nCon 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.\n\n### Secrets como driver de almacenamiento predeterminado\n\nEn 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.\n\nCambiar a Secrets como predeterminado en Helm 3 permite seguridad adicional para proteger los charts junto con el lanzamiento del cifrado de Secrets en Kubernetes.\n\n[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.\n\n### Cambios en la ruta de importación de Go\n\nEn 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.\n\n### Capabilities\n\nEl objeto incorporado `.Capabilities` disponible durante la etapa de renderizado ha sido simplificado.\n\n[Objetos incorporados](/chart_template_guide/builtin_objects.md)\n\n### Validación de valores de Chart con JSONSchema\n\nAhora 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.\n\nLa validación ocurre cuando se invocan cualquiera de los siguientes comandos:\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\nConsulte la documentación sobre [archivos de esquema](/topics/charts.md#schema-files) para más información.\n\n### Consolidación de `requirements.yaml` en `Chart.yaml`\n\nEl 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.\n\nEn Helm 2, así se veía un `requirements.yaml`:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nEn Helm 3, la dependencia se expresa de la misma manera, pero ahora desde su `Chart.yaml`:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nLos 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.\n\n### El nombre (o --generate-name) ahora es requerido en install\n\nEn 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`.\n\nPara aquellos que aún deseen que se les genere un nombre automáticamente, pueden usar la flag `--generate-name` para crear uno.\n\n### Publicación de Charts en registros OCI\n\nEsta es una característica experimental introducida en Helm 3. Para usarla, configure la variable de entorno `HELM_EXPERIMENTAL_OCI=1`.\n\nA 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.\n\nAunque 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:\n\n- 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.\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.\n- 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.\n- 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.\n\nEl 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.\n\nPor 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.\n\nPara más información, consulte [esta página](/topics/registries.md).\n\n### Eliminación de `helm serve`\n\n`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.\n\nPara 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).\n\n### Soporte para charts de biblioteca\n\nHelm 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).\n\nLos charts de biblioteca se declaran en la directiva dependencies en Chart.yaml, y se instalan y gestionan como cualquier otro chart.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nEstamos 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.\n\n### Incremento del apiVersion de Chart.yaml\n\nCon 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`.\n\n`helm create` ahora crea charts usando este nuevo formato, por lo que el apiVersion predeterminado también se incrementó ahí.\n\nLos 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.\n\n### Soporte para XDG Base Directory\n\n[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.\n\nEn 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`.\n\nEn Helm 3, Helm ahora respeta las siguientes variables de entorno según la especificación XDG Base Directory:\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nLos 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.\n\nVarias variables de entorno nuevas también se pasan al entorno del plugin para acomodar este cambio:\n\n- `$HELM_PATH_CACHE` para la ruta de caché\n- `$HELM_PATH_CONFIG` para la ruta de configuración\n- `$HELM_PATH_DATA` para la ruta de datos\n\nLos plugins de Helm que busquen soportar Helm 3 deberían considerar usar estas nuevas variables de entorno en su lugar.\n\n### Renombrado de comandos CLI\n\nPara 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.\n\nEn 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`.\n\nAdicionalmente, varios otros comandos fueron renombrados para acomodar las mismas convenciones:\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\nEstos comandos también han conservado sus verbos anteriores como aliases, por lo que puede continuar usándolos en cualquiera de las dos formas.\n\n### Creación automática de namespaces\n\nAl 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`.\n\n### ¿Qué pasó con .Chart.ApiVersion?\n\nHelm 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`.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: Instalación\nsidebar_position: 2\n---\n\n## Instalación\n\n### ¿Por qué no hay paquetes nativos de Helm para Fedora y otras distribuciones de Linux?\n\nEl 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.\n\n### ¿Por qué proporcionan un script `curl ...|bash`?\n\nHay 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.\n\nLo 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.\n\n### ¿Cómo puedo colocar los archivos del cliente de Helm en un lugar diferente a sus ubicaciones predeterminadas?\n\nHelm utiliza la estructura XDG para almacenar archivos. Hay variables de entorno que puede usar para anular estas ubicaciones:\n\n- `$XDG_CACHE_HOME`: establece una ubicación alternativa para almacenar archivos en caché.\n- `$XDG_CONFIG_HOME`: establece una ubicación alternativa para almacenar la configuración de Helm.\n- `$XDG_DATA_HOME`: establece una ubicación alternativa para almacenar los datos de Helm.\n\nTenga en cuenta que si tiene repositorios existentes, deberá volver a agregarlos con `helm repo add...`.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: Solución de Problemas\nsidebar_position: 4\n---\n\n## Solución de Problemas\n\n### Recibo una advertencia sobre \"Unable to get an update from the \"stable\" chart repository\"\n\nEjecute `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.\n\nPuede ejecutar el siguiente comando para corregir su repositorio:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nLo mismo aplica para el repositorio `incubator`, que tiene un archivo disponible en https://charts.helm.sh/incubator. Puede ejecutar el siguiente comando para repararlo:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Recibo la advertencia 'WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.'\n\nEl antiguo repositorio de charts de Google Helm ha sido reemplazado por un nuevo repositorio de charts de Helm.\n\nEjecute el siguiente comando para solucionar esto de forma permanente:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nSi recibe un error similar para `incubator`, ejecute este comando:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Al agregar un repositorio de Helm, recibo el error 'Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available'\n\nLos 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`.\n\n### En GKE (Google Container Engine) recibo \"No SSH tunnels currently open\"\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nOtra variación del mensaje de error es:\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nEl problema es que su archivo de configuración local de Kubernetes debe tener las credenciales correctas.\n\nCuando 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.\n\n### Después de migrar desde Helm 2, `helm list` muestra solo algunas (o ninguna) de mis releases\n\nEs 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:\n\n* confiar en el namespace actual en el contexto activo de Kubernetes (como lo describe el comando `kubectl config view --minify`),\n* especificar el namespace correcto usando el flag `--namespace`/`-n`, o\n* para el comando `helm list`, especificar el flag `--all-namespaces`/`-A`\n\nEsto aplica a `helm ls`, `helm uninstall` y todos los demás comandos de `helm` que hacen referencia a una release.\n\n\n### En macOS, se accede al archivo `/etc/.mdns_debug`. ¿Por qué?\n\nExiste 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.\n\nEsto 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.\n\nSi 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.\n\nEste 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.\n\n### helm repo add falla cuando antes funcionaba\n\nEn Helm 3.3.1 y versiones anteriores, el comando `helm repo add <reponame> <url>` 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.\n\nEn Helm 3.3.2 y versiones posteriores, intentar agregar un repositorio existente producirá un error:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nEl comportamiento predeterminado ahora está invertido. `--no-update` ahora se ignora, mientras que si desea reemplazar (sobrescribir) un repositorio existente, puede usar `--force-update`.\n\nEsto 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).\n\n### Habilitar el registro del cliente de Kubernetes\n\nPuede 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.\n\nPor ejemplo:\n\n```\nhelm list -v 6\n```\n\n### Las instalaciones de Tiller dejaron de funcionar y se deniega el acceso\n\nLas versiones de Helm solían estar disponibles en <https://storage.googleapis.com/kubernetes-helm/>. 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.\n\n\nSi está intentando descargar versiones antiguas de Helm del bucket de almacenamiento que usaba en el pasado, puede encontrar que faltan:\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\nLa [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:\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\ncon:\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nPara inicializar con Helm v2.17.0:\n\n`helm init —upgrade`\n\nO 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:\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**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.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: Desinstalación\nsidebar_position: 3\n---\n\n## Desinstalación\n\n### Quiero eliminar mi Helm local. ¿Dónde están todos sus archivos?\n\nAdemás del binario `helm`, Helm almacena algunos archivos en las siguientes ubicaciones:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nLa siguiente tabla muestra la carpeta predeterminada para cada una de estas, según el sistema operativo:\n\n| Sistema Operativo | Ruta de Caché               | Ruta de Configuración            | Ruta de Datos             |\n|-------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux             | `$HOME/.cache/helm`        | `$HOME/.config/helm`            | `$HOME/.local/share/helm` |\n| macOS             | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm`     |\n| Windows           | `%TEMP%\\helm`             | `%APPDATA%\\helm`                | `%APPDATA%\\helm`          |\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\nEl gestor de paquetes Helm para Kubernetes.\n\n### Sinopsis\n\nEl gestor de paquetes de Kubernetes\n\nAcciones comunes de Helm:\n\n- helm search:    buscar charts\n- helm pull:      descargar un chart a su directorio local para visualizarlo\n- helm install:   subir el chart a Kubernetes\n- helm list:      listar releases de charts\n\nVariables de entorno:\n\n| Nombre                             | Descripción                                                                                                       |\n|------------------------------------|-------------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | establece una ubicación alternativa para almacenar archivos en caché.                                             |\n| $HELM_CONFIG_HOME                  | establece una ubicación alternativa para almacenar la configuración de Helm.                                      |\n| $HELM_DATA_HOME                    | establece una ubicación alternativa para almacenar datos de Helm.                                                 |\n| $HELM_DEBUG                        | indica si Helm se está ejecutando en modo Debug o no                                                              |\n| $HELM_DRIVER                       | establece el controlador de almacenamiento del backend. Los valores son: configmap, secret, memory, sql.          |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | establece la cadena de conexión que debe usar el controlador de almacenamiento SQL.                               |\n| $HELM_MAX_HISTORY                  | establece el número máximo de historial de releases de Helm.                                                      |\n| $HELM_NAMESPACE                    | establece el namespace usado para las operaciones de Helm.                                                        |\n| $HELM_NO_PLUGINS                   | deshabilita plugins. Establezca HELM_NO_PLUGINS=1 para deshabilitar plugins.                                      |\n| $HELM_PLUGINS                      | establece la ruta al directorio de plugins                                                                        |\n| $HELM_REGISTRY_CONFIG              | establece la ruta al archivo de configuración del registro.                                                       |\n| $HELM_REPOSITORY_CACHE             | establece la ruta al directorio de caché del repositorio                                                          |\n| $HELM_REPOSITORY_CONFIG            | establece la ruta al archivo de repositorios.                                                                     |\n| $KUBECONFIG                        | establece un archivo de configuración de Kubernetes alternativo (por defecto \"~/.kube/config\")                    |\n| $HELM_KUBEAPISERVER                | establece el Endpoint del servidor API de Kubernetes para autenticación                                           |\n| $HELM_KUBECAFILE                   | establece el archivo de autoridad certificadora de Kubernetes.                                                    |\n| $HELM_KUBEASGROUPS                 | establece los grupos a usar para suplantación usando una lista separada por comas.                                |\n| $HELM_KUBEASUSER                   | establece el nombre de usuario a suplantar para la operación.                                                     |\n| $HELM_KUBECONTEXT                  | establece el nombre del contexto de kubeconfig.                                                                   |\n| $HELM_KUBETOKEN                    | establece el Bearer KubeToken usado para autenticación.                                                           |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indica si se debe omitir la validación del certificado del servidor API de Kubernetes (inseguro)                  |\n| $HELM_KUBETLS_SERVER_NAME          | establece el nombre del servidor usado para validar el certificado del servidor API de Kubernetes                 |\n| $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) |\n| $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 |\n\nHelm almacena caché, configuración y datos basándose en el siguiente orden de configuración:\n\n- Si una variable de entorno HELM_*_HOME está establecida, se usará\n- De lo contrario, en sistemas que soportan la especificación de directorios base XDG, se usarán las variables XDG\n- Cuando no se establece ninguna otra ubicación, se usará una ubicación por defecto basada en el sistema operativo\n\nPor defecto, los directorios predeterminados dependen del sistema operativo. Los valores por defecto se listan a continuación:\n\n| Sistema Operativo | Ruta de Caché             | Ruta de Configuración          | Ruta de Datos             |\n|-------------------|---------------------------|--------------------------------|---------------------------|\n| Linux             | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm   |\n| macOS             | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm        |\n| Windows           | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm            |\n\n\n### Opciones\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente por defecto (por defecto 100)\n      --debug                           habilita salida detallada\n  -h, --help                            ayuda para helm\n      --kube-apiserver string           la dirección y el puerto del servidor API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad certificadora para la conexión del servidor API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito de namespace para esta solicitud\n      --qps float32                     consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorio en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm completion](/helm/helm_completion.md)\t - genera scripts de autocompletado para el shell especificado\n* [helm create](/helm/helm_create.md)\t - crea un nuevo chart con el nombre dado\n* [helm dependency](/helm/helm_dependency.md)\t - gestiona las dependencias de un chart\n* [helm env](/helm/helm_env.md)\t - información del entorno del cliente Helm\n* [helm get](/helm/helm_get.md)\t - descarga información extendida de un release nombrado\n* [helm history](/helm/helm_history.md)\t - obtiene el historial de releases\n* [helm install](/helm/helm_install.md)\t - instala un chart\n* [helm lint](/helm/helm_lint.md)\t - examina un chart en busca de posibles problemas\n* [helm list](/helm/helm_list.md)\t - lista releases\n* [helm package](/helm/helm_package.md)\t - empaqueta un directorio de chart en un archivo de chart\n* [helm plugin](/helm/helm_plugin.md)\t - instala, lista o desinstala plugins de Helm\n* [helm pull](/helm/helm_pull.md)\t - descarga un chart de un repositorio y (opcionalmente) lo desempaqueta en el directorio local\n* [helm push](/helm/helm_push.md)\t - sube un chart a un servidor remoto\n* [helm registry](/helm/helm_registry.md)\t - inicia o cierra sesión en un registro\n* [helm repo](/helm/helm_repo.md)\t - añade, lista, elimina, actualiza e indexa repositorios de charts\n* [helm rollback](/helm/helm_rollback.md)\t - revierte un release a una revisión anterior\n* [helm search](/helm/helm_search.md)\t - busca una palabra clave en charts\n* [helm show](/helm/helm_show.md)\t - muestra información de un chart\n* [helm status](/helm/helm_status.md)\t - muestra el estado del release nombrado\n* [helm template](/helm/helm_template.md)\t - renderiza plantillas localmente\n* [helm test](/helm/helm_test.md)\t - ejecuta pruebas para un release\n* [helm uninstall](/helm/helm_uninstall.md)\t - desinstala un release\n* [helm upgrade](/helm/helm_upgrade.md)\t - actualiza un release\n* [helm verify](/helm/helm_verify.md)\t - verifica que un chart en la ruta dada ha sido firmado y es válido\n* [helm version](/helm/helm_version.md)\t - imprime la información de versión del cliente\n\n###### Generado automáticamente por spf13/cobra el 14-Ene-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\ngenera scripts de autocompletado para el shell especificado\n\n### Sinopsis\n\n\nGenera scripts de autocompletado de Helm para el shell especificado.\n\n\n### Opciones\n\n```\n  -h, --help   ayuda para completion\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de limitación predeterminado del lado del cliente (predeterminado 100)\n      --debug                           habilitar salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (predeterminado \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (predeterminado \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](/helm/helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n* [helm completion bash](/helm/helm_completion_bash.md)\t - genera el script de autocompletado para bash\n* [helm completion fish](/helm/helm_completion_fish.md)\t - genera el script de autocompletado para fish\n* [helm completion powershell](/helm/helm_completion_powershell.md)\t - genera el script de autocompletado para powershell\n* [helm completion zsh](/helm/helm_completion_zsh.md)\t - genera el script de autocompletado para zsh\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\ngenera el script de autocompletado para bash\n\n### Sinopsis\n\nGenera el script de autocompletado de Helm para el shell bash.\n\nPara cargar los autocompletados en su sesión de shell actual:\n\n    source <(helm completion bash)\n\nPara cargar los autocompletados en cada nueva sesión, ejecute una vez:\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n\n```\nhelm completion bash [flags]\n```\n\n### Opciones\n\n```\n  -h, --help              ayuda para bash\n      --no-descriptions   deshabilitar descripciones de autocompletado\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de limitación predeterminado del lado del cliente (predeterminado 100)\n      --debug                           habilitar salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (predeterminado \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (predeterminado \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm completion](/helm/helm_completion.md)\t - genera scripts de autocompletado para el shell especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\ngenera el script de autocompletado para fish\n\n### Sinopsis\n\nGenera el script de autocompletado de Helm para el shell fish.\n\nPara cargar los autocompletados en su sesión de shell actual:\n\n    helm completion fish | source\n\nPara cargar los autocompletados en cada nueva sesión, ejecute una vez:\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\nDeberá iniciar un nuevo shell para que esta configuración surta efecto.\n\n\n```\nhelm completion fish [flags]\n```\n\n### Opciones\n\n```\n  -h, --help              ayuda para fish\n      --no-descriptions   deshabilitar descripciones de autocompletado\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de limitación predeterminado del lado del cliente (predeterminado 100)\n      --debug                           habilitar salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (predeterminado \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (predeterminado \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm completion](/helm/helm_completion.md)\t - genera scripts de autocompletado para el shell especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\ngenera el script de autocompletado para powershell\n\n### Sinopsis\n\nGenera el script de autocompletado para powershell.\n\nPara cargar los autocompletados en su sesión de shell actual:\n\n    PS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\nPara cargar los autocompletados en cada nueva sesión, agregue la salida del comando anterior a su perfil de powershell.\n\n\n```\nhelm completion powershell [flags]\n```\n\n### Opciones\n\n```\n  -h, --help              ayuda para powershell\n      --no-descriptions   deshabilitar descripciones de autocompletado\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de limitación predeterminado del lado del cliente (predeterminado 100)\n      --debug                           habilitar salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (predeterminado \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (predeterminado \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm completion](/helm/helm_completion.md)\t - genera scripts de autocompletado para el shell especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\ngenera el script de autocompletado para zsh\n\n### Sinopsis\n\nGenera el script de autocompletado de Helm para el shell zsh.\n\nPara cargar los autocompletados en su sesión de shell actual:\n\n    source <(helm completion zsh)\n\nPara cargar los autocompletados en cada nueva sesión, ejecute una vez:\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### Opciones\n\n```\n  -h, --help              ayuda para zsh\n      --no-descriptions   deshabilitar descripciones de autocompletado\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de limitación predeterminado del lado del cliente (predeterminado 100)\n      --debug                           habilitar salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (predeterminado \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (predeterminado \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm completion](/helm/helm_completion.md)\t - genera scripts de autocompletado para el shell especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n\ncrea un nuevo chart con el nombre proporcionado\n\n### Sinopsis\n\nEste comando crea un directorio de chart junto con los archivos y directorios comunes utilizados en un chart.\n\nPor ejemplo, 'helm create foo' creará una estructura de directorios similar a esta:\n\n    foo/\n    ├── .helmignore   # Contiene patrones a ignorar al empaquetar charts de Helm.\n    ├── Chart.yaml    # Información sobre su chart\n    ├── values.yaml   # Los valores predeterminados para sus plantillas\n    ├── charts/       # Charts de los que depende este chart\n    └── templates/    # Los archivos de plantillas\n        └── tests/    # Los archivos de pruebas\n\n'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.\n\n\n```\nhelm create NAME [flags]\n```\n\n### Opciones\n\n```\n  -h, --help             ayuda para create\n  -p, --starter string   el nombre o ruta absoluta al scaffold de inicio de Helm\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de limitación predeterminado del lado del cliente (predeterminado 100)\n      --debug                           habilitar salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (predeterminado \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (predeterminado \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](/helm/helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\ngestiona las dependencias de un chart\n\n### Sinopsis\n\n\nGestiona las dependencias de un chart.\n\nLos charts de Helm almacenan sus dependencias en 'charts/'. Para los desarrolladores\nde charts, a menudo es más fácil gestionar las dependencias en 'Chart.yaml', que\ndeclara todas las dependencias.\n\nLos comandos de dependencia operan sobre ese archivo, facilitando la sincronización\nentre las dependencias deseadas y las dependencias reales almacenadas en el\ndirectorio 'charts/'.\n\nPor ejemplo, este Chart.yaml declara dos dependencias:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\nEl 'name' debe ser el nombre de un chart, donde ese nombre debe coincidir con el\nnombre en el archivo 'Chart.yaml' de ese chart.\n\nEl campo 'version' debe contener una versión semántica o un rango de versiones.\n\nLa URL del 'repository' debe apuntar a un repositorio de charts. Helm espera que,\nal añadir '/index.yaml' a la URL, pueda obtener el índice del repositorio de charts.\nNota: 'repository' puede ser un alias. El alias debe comenzar con 'alias:' o '@'.\n\nA partir de la versión 2.2.0, el repository puede definirse como la ruta al directorio\nde los charts de dependencia almacenados localmente. La ruta debe comenzar con el\nprefijo \"file://\". Por ejemplo,\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\nSi el chart de dependencia se obtiene localmente, no es necesario añadir el\nrepositorio a helm mediante \"helm add repo\". También se admite la coincidencia\nde versiones en este caso.\n\n\n### Opciones\n\n```\n  -h, --help   ayuda para dependency\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](/helm/helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n* [helm dependency build](/helm/helm_dependency_build.md)\t - reconstruye el directorio charts/ basándose en el archivo Chart.lock\n* [helm dependency list](/helm/helm_dependency_list.md)\t - lista las dependencias del chart dado\n* [helm dependency update](/helm/helm_dependency_update.md)\t - actualiza charts/ basándose en el contenido de Chart.yaml\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\nreconstruye el directorio charts/ basándose en el archivo Chart.lock\n\n### Sinopsis\n\n\nReconstruye el directorio charts/ a partir del archivo Chart.lock.\n\nEste comando se utiliza para reconstruir las dependencias de un chart al estado especificado en\nel archivo de bloqueo. Esto no volverá a resolver las dependencias, como lo hace 'helm dependency update'.\n\nSi no se encuentra ningún archivo de bloqueo, 'helm dependency build' replicará el comportamiento\nde 'helm dependency update'.\n\n\n```\nhelm dependency build CHART [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string             verifica certificados de servidores habilitados para HTTPS usando este paquete de CA\n      --cert-file string           identifica al cliente HTTPS usando este archivo de certificado SSL\n  -h, --help                       ayuda para build\n      --insecure-skip-tls-verify   omite las verificaciones de certificado tls para la descarga del chart\n      --key-file string            identifica al cliente HTTPS usando este archivo de clave SSL\n      --keyring string             llavero que contiene claves públicas (por defecto \"~/.gnupg/pubring.gpg\")\n      --password string            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la descarga del chart\n      --skip-refresh               no actualiza la caché local del repositorio\n      --username string            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n      --verify                     verifica los paquetes contra las firmas\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm dependency](/helm/helm_dependency.md)\t - gestiona las dependencias de un chart\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\nlista las dependencias del chart dado\n\n### Sinopsis\n\n\nLista todas las dependencias declaradas en un chart.\n\nEste comando puede recibir archivos de chart y directorios de chart como entrada.\nNo alterará el contenido de un chart.\n\nSe producirá un error si no se puede cargar el chart.\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### Opciones\n\n```\n  -h, --help                 ayuda para list\n      --max-col-width uint   ancho máximo de columna para la tabla de salida (por defecto 80)\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm dependency](/helm/helm_dependency.md)\t - gestiona las dependencias de un chart\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\nactualiza charts/ basándose en el contenido de Chart.yaml\n\n### Sinopsis\n\n\nActualiza las dependencias en disco para reflejar Chart.yaml.\n\nEste comando verifica que los charts requeridos, tal como se expresan en 'Chart.yaml',\nestén presentes en 'charts/' y tengan una versión aceptable. Descargará\nlos charts más recientes que satisfagan las dependencias y eliminará las dependencias antiguas.\n\nTras una actualización exitosa, se generará un archivo de bloqueo que puede usarse para\nreconstruir las dependencias con una versión exacta.\n\nNo es obligatorio que las dependencias estén representadas en 'Chart.yaml'. Por esa\nrazón, un comando de actualización no eliminará charts a menos que estén (a) presentes\nen el archivo Chart.yaml, pero (b) con una versión incorrecta.\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string             verifica certificados de servidores habilitados para HTTPS usando este paquete de CA\n      --cert-file string           identifica al cliente HTTPS usando este archivo de certificado SSL\n  -h, --help                       ayuda para update\n      --insecure-skip-tls-verify   omite las verificaciones de certificado tls para la descarga del chart\n      --key-file string            identifica al cliente HTTPS usando este archivo de clave SSL\n      --keyring string             llavero que contiene claves públicas (por defecto \"~/.gnupg/pubring.gpg\")\n      --password string            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la descarga del chart\n      --skip-refresh               no actualiza la caché local del repositorio\n      --username string            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n      --verify                     verifica los paquetes contra las firmas\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm dependency](/helm/helm_dependency.md)\t - gestiona las dependencias de un chart\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\ninformación del entorno del cliente Helm\n\n### Sinopsis\n\n\nEnv imprime toda la información del entorno en uso por Helm.\n\n\n```\nhelm env [flags]\n```\n\n### Opciones\n\n```\n  -h, --help   ayuda para env\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](/helm/helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\ndescarga información extendida de un release especificado\n\n### Sinopsis\n\n\nEste comando consta de múltiples subcomandos que pueden usarse para\nobtener información extendida sobre el release, incluyendo:\n\n- Los valores utilizados para generar el release\n- El archivo de manifiesto generado\n- Las notas proporcionadas por el chart del release\n- Los hooks asociados con el release\n- Los metadatos del release\n\n\n### Opciones\n\n```\n  -h, --help   ayuda para get\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](/helm/helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n* [helm get all](/helm/helm_get_all.md)\t - descarga toda la información de un release especificado\n* [helm get hooks](/helm/helm_get_hooks.md)\t - descarga todos los hooks de un release especificado\n* [helm get manifest](/helm/helm_get_manifest.md)\t - descarga el manifiesto de un release especificado\n* [helm get metadata](/helm/helm_get_metadata.md)\t - obtiene los metadatos de un release dado\n* [helm get notes](/helm/helm_get_notes.md)\t - descarga las notas de un release especificado\n* [helm get values](/helm/helm_get_values.md)\t - descarga el archivo de valores de un release especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\ndescarga toda la información de un release especificado\n\n### Sinopsis\n\n\nEste comando muestra información legible sobre las notas, hooks, valores\nsuministrados y el archivo de manifiesto generado de un release dado.\n\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### Opciones\n\n```\n  -h, --help              ayuda para all\n      --revision int      obtiene el release especificado con la revisión indicada\n      --template string   plantilla de Go para formatear la salida, ej: {{.Release.Name}}\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm get](/helm/helm_get.md)\t - descarga información extendida de un release especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\ndescarga todos los hooks de un release especificado\n\n### Sinopsis\n\n\nEste comando descarga los hooks de un release dado.\n\nLos hooks están en formato YAML y se separan mediante '---\\n'.\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Opciones\n\n```\n  -h, --help           ayuda para hooks\n      --revision int   obtiene el release especificado con la revisión indicada\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm get](/helm/helm_get.md)\t - descarga información extendida de un release especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\ndescarga el manifest de un release especificado\n\n### Sinopsis\n\n\nEste comando obtiene el manifest generado para un release dado.\n\nUn manifest es una representación en formato YAML de los recursos de Kubernetes\nque fueron generados a partir del chart (o charts) de este release. Si un chart\ndepende de otros charts, esos recursos también serán incluidos en el manifest.\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### Opciones\n\n```\n  -h, --help           ayuda para manifest\n      --revision int   obtiene el release especificado con la revisión indicada\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm get](/helm/helm_get.md)\t - descarga información extendida de un release especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\nEste comando obtiene los metadatos de un release especificado\n\n### Sinopsis\n\nEste comando obtiene los metadatos de un release especificado.\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### Opciones\n\n```\n  -h, --help            ayuda para metadata\n  -o, --output format   imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n      --revision int    especifica la revisión del release\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm get](/helm/helm_get.md)\t - descarga información extendida de un release especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\ndescarga las notas de un release especificado\n\n### Sinopsis\n\n\nEste comando muestra las notas proporcionadas por el chart de un release especificado.\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### Opciones\n\n```\n  -h, --help           ayuda para notes\n      --revision int   obtiene el release especificado con la revisión indicada\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm get](/helm/helm_get.md)\t - descarga información extendida de un release especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\ndescarga el archivo de valores de un release especificado\n\n### Sinopsis\n\n\nEste comando descarga un archivo de valores para un release dado.\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### Opciones\n\n```\n  -a, --all             muestra todos los valores (calculados)\n  -h, --help            ayuda para values\n  -o, --output format   imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n      --revision int    obtiene el release especificado con la revisión indicada\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm get](/helm/helm_get.md)\t - descarga información extendida de un release especificado\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\nobtiene el historial del release\n\n### Sinopsis\n\n\nHistory imprime las revisiones de un release especificado.\n\nPor defecto se devuelven hasta 256 revisiones. Use '--max' para configurar\nla longitud máxima de la lista de revisiones devuelta.\n\nEl historial del release se muestra como una tabla formateada, por ejemplo:\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### Opciones\n\n```\n  -h, --help            ayuda para history\n      --max int         número máximo de revisiones a incluir en el historial (por defecto 256)\n  -o, --output format   imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\ninstala un chart\n\n### Sinopsis\n\nEste comando instala un archivo de chart.\n\nEl 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.\n\nPara 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.\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\no\n\n    $ helm install --set name=prod myredis ./redis\n\no\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\no\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\no\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\nPuede 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:\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\nPuede 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:\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\nDe manera similar, en el siguiente ejemplo 'foo' se establece como '[\"four\"]':\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\nY en el siguiente ejemplo, 'foo' se establece como '{\"key1\":\"value1\",\"key2\":\"bar\"}':\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\nPara verificar los manifiestos generados de un release sin instalar el chart, se pueden combinar las opciones --debug y --dry-run.\n\nLa 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.\n\nSi --verify está establecido, el chart DEBE tener un archivo de procedencia, y el archivo de procedencia DEBE pasar todos los pasos de verificación.\n\nExisten seis formas diferentes de expresar el chart que desea instalar:\n\n1. Por referencia de chart: helm install mymaria example/mariadb\n2. Por ruta a un chart empaquetado: helm install mynginx ./nginx-1.2.3.tgz\n3. Por ruta a un directorio de chart desempaquetado: helm install mynginx ./nginx\n4. Por URL absoluta: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. Por referencia de chart y URL de repositorio: helm install --repo https://example.com/charts/ mynginx nginx\n6. Por registros OCI: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\nREFERENCIAS DE CHART\n\nUna referencia de chart es una forma conveniente de referenciar un chart en un repositorio de charts.\n\nCuando 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'.\n\nPara ver la lista de repositorios de charts, use 'helm repo list'. Para buscar charts en un repositorio, use 'helm search'.\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### Opciones\n\n```\n      --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\n      --ca-file string                             verifica certificados de servidores habilitados con HTTPS usando este paquete de CA\n      --cert-file string                           identifica el cliente HTTPS usando este archivo de certificado SSL\n      --create-namespace                           crea el namespace del release si no está presente\n      --dependency-update                          actualiza las dependencias si faltan antes de instalar el chart\n      --description string                         añade una descripción personalizada\n      --devel                                      usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si --version está establecido, esto se ignora\n      --disable-openapi-validation                 si se establece, el proceso de instalación no validará las plantillas renderizadas contra el esquema OpenAPI de Kubernetes\n      --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.\n      --enable-dns                                 habilita búsquedas DNS al renderizar plantillas\n      --force                                      fuerza actualizaciones de recursos mediante una estrategia de reemplazo\n  -g, --generate-name                              genera el nombre (y omite el parámetro NAME)\n  -h, --help                                       ayuda para install\n      --hide-notes                                 si se establece, no muestra las notas en la salida de instalación. No afecta su presencia en los metadatos del chart\n      --hide-secret                                oculta los Secrets de Kubernetes cuando también se usa la opción --dry-run\n      --insecure-skip-tls-verify                   omite verificaciones de certificado TLS para la descarga del chart\n      --key-file string                            identifica el cliente HTTPS usando este archivo de clave SSL\n      --keyring string                             ubicación de las claves públicas usadas para verificación (por defecto \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      etiquetas que se añadirán a los metadatos del release. Deben separarse por coma. (por defecto [])\n      --name-template string                       especifica la plantilla usada para nombrar el release\n      --no-hooks                                   evita que se ejecuten los hooks durante la instalación\n  -o, --output format                              imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n      --pass-credentials                           pasa credenciales a todos los dominios\n      --password string                            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                                 usa conexiones HTTP inseguras para la descarga del chart\n      --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\n      --post-renderer-args postRendererArgsSlice   un argumento para el post-renderer (puede especificar múltiples) (por defecto [])\n      --render-subchart-notes                      si se establece, renderiza las notas del subchart junto con el padre\n      --replace                                    reutiliza el nombre dado, solo si ese nombre es un release eliminado que permanece en el historial. Esto es inseguro en producción\n      --repo string                                URL del repositorio de charts donde localizar el chart solicitado\n      --set stringArray                            establece valores en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2)\n      --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)\n      --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)\n      --set-literal stringArray                    establece un valor STRING literal en la línea de comandos\n      --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)\n      --skip-crds                                  si se establece, no se instalarán CRDs. Por defecto, los CRDs se instalan si no están presentes\n      --skip-schema-validation                     si se establece, deshabilita la validación de esquema JSON\n      --take-ownership                             si se establece, la instalación ignorará la verificación de anotaciones de helm y tomará posesión de los recursos existentes\n      --timeout duration                           tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s)\n      --username string                            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n  -f, --values strings                             especifica valores en un archivo YAML o una URL (puede especificar múltiples)\n      --verify                                     verifica el paquete antes de usarlo\n      --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\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\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita la salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a utilizar\n      --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\n      --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\n      --kube-token string               token bearer utilizado para la autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\nexamina un chart en busca de posibles problemas\n\n### Sinopsis\n\nEste comando toma una ruta a un chart y ejecuta una serie de pruebas para verificar que\nel chart esté bien formado.\n\nSi el linter encuentra problemas que harán fallar la instalación del chart,\nemitirá mensajes [ERROR]. Si encuentra problemas que rompen con la convención\no las recomendaciones, emitirá mensajes [WARNING].\n\n\n```\nhelm lint PATH [flags]\n```\n\n### Opciones\n\n```\n  -h, --help                      ayuda para lint\n      --kube-version string       versión de Kubernetes usada para verificaciones de capacidades y deprecación\n      --quiet                     imprime solo advertencias y errores\n      --set stringArray           establece valores en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2)\n      --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)\n      --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)\n      --set-literal stringArray   establece un valor STRING literal en la línea de comandos\n      --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)\n      --skip-schema-validation    si está activado, deshabilita la validación de esquema JSON\n      --strict                    falla si hay advertencias en el lint\n  -f, --values strings            especifica valores en un archivo YAML o una URL (puede especificar múltiples)\n      --with-subcharts            analiza también los charts dependientes\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\nlista los releases\n\n### Sinopsis\n\nEste comando lista todos los releases para un namespace especificado (usa el contexto del namespace actual si no se especifica ninguno).\n\nPor defecto, solo lista los releases que están desplegados o fallidos. Opciones como\n'--uninstalled' y '--all' alterarán este comportamiento. Estas opciones se pueden combinar:\n'--uninstalled --failed'.\n\nPor defecto, los elementos se ordenan alfabéticamente. Use la opción '-d' para ordenar por\nfecha de release.\n\nSi se proporciona la opción --filter, se tratará como un filtro. Los filtros son\nexpresiones regulares (compatibles con Perl) que se aplican a la lista de releases.\nSolo se devolverán los elementos que coincidan con el filtro.\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\nSi no se encuentran resultados, 'helm list' finalizará con código 0, pero sin salida (o en\ncaso de no usar la opción '-q', solo mostrará los encabezados).\n\nPor defecto, se pueden devolver hasta 256 elementos. Para limitar esto, use la opción '--max'.\nEstablecer '--max' en 0 no devolverá todos los resultados. En su lugar, devolverá el\nvalor predeterminado del servidor, que puede ser mucho mayor que 256. Combinar la opción '--max'\ncon la opción '--offset' permite paginar los resultados.\n\n\n```\nhelm list [flags]\n```\n\n### Opciones\n\n```\n  -a, --all                  muestra todos los releases sin ningún filtro aplicado\n  -A, --all-namespaces       lista releases en todos los namespaces\n  -d, --date                 ordena por fecha de release\n      --deployed             muestra releases desplegados. Si no se especifica otro, se habilitará automáticamente\n      --failed               muestra releases fallidos\n  -f, --filter string        una expresión regular (compatible con Perl). Cualquier release que coincida con la expresión se incluirá en los resultados\n  -h, --help                 ayuda para list\n  -m, --max int              número máximo de releases a obtener (por defecto 256)\n      --no-headers           no imprime encabezados cuando se usa el formato de salida predeterminado\n      --offset int           siguiente índice de release en la lista, usado para desplazarse desde el valor inicial\n  -o, --output format        imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n      --pending              muestra releases pendientes\n  -r, --reverse              invierte el orden de clasificación\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.\n  -q, --short                formato de listado corto (silencioso)\n      --superseded           muestra releases reemplazados\n      --time-format string   formatea la hora usando el formateador de tiempo de golang. Ejemplo: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          muestra releases desinstalados (si se usó 'helm uninstall --keep-history')\n      --uninstalling         muestra releases que están siendo desinstalados actualmente\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\nempaqueta un directorio de chart en un archivo de chart\n\n### Sinopsis\n\nEste 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.\n\nLos repositorios de paquetes de Helm utilizan archivos de chart versionados.\n\nPara 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'.\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\nSi no se especifica '--keyring', Helm normalmente usa el llavero público por defecto, a menos que su entorno esté configurado de otra manera.\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Opciones\n\n```\n      --app-version string         establece el appVersion en el chart a esta versión\n      --ca-file string             verifica certificados de servidores habilitados con HTTPS usando este paquete de CA\n      --cert-file string           identifica el cliente HTTPS usando este archivo de certificado SSL\n  -u, --dependency-update          actualiza las dependencias desde \"Chart.yaml\" al directorio \"charts/\" antes de empaquetar\n  -d, --destination string         ubicación donde escribir el chart (por defecto \".\")\n  -h, --help                       ayuda para package\n      --insecure-skip-tls-verify   omite las verificaciones del certificado TLS para la descarga del chart\n      --key string                 nombre de la clave a usar al firmar. Se usa si --sign es true\n      --key-file string            identifica el cliente HTTPS usando este archivo de clave SSL\n      --keyring string             ubicación del llavero público (por defecto \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     ubicación del archivo que contiene la frase de contraseña para la clave de firma. Use \"-\" para leer desde stdin.\n      --password string            contraseña del repositorio de charts donde ubicar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la descarga del chart\n      --sign                       usa una clave privada PGP para firmar este paquete\n      --username string            nombre de usuario del repositorio de charts donde ubicar el chart solicitado\n      --version string             establece la versión del chart a esta versión semver\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\ninstala, lista o desinstala plugins de Helm\n\n### Sinopsis\n\n\nAdministra plugins de Helm del lado del cliente.\n\n\n### Opciones\n\n```\n  -h, --help   ayuda para plugin\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n* [helm plugin install](./helm_plugin_install.md)\t - instala un plugin de Helm\n* [helm plugin list](./helm_plugin_list.md)\t - lista los plugins de Helm instalados\n* [helm plugin uninstall](./helm_plugin_uninstall.md)\t - desinstala uno o más plugins de Helm\n* [helm plugin update](./helm_plugin_update.md)\t - actualiza uno o más plugins de Helm\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\ninstala un plugin de Helm\n\n### Sinopsis\n\nEste comando permite instalar un plugin desde una URL de un repositorio VCS o una ruta local.\n\n\n```\nhelm plugin install [options] <path|url> [flags]\n```\n\n### Opciones\n\n```\n  -h, --help             ayuda para install\n      --version string   especifica una restricción de versión. Si no se especifica, se instala la última versión\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm plugin](./helm_plugin.md)\t - instala, lista o desinstala plugins de Helm\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\nlista los plugins de Helm instalados\n\n```\nhelm plugin list [flags]\n```\n\n### Opciones\n\n```\n  -h, --help   ayuda para list\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm plugin](./helm_plugin.md)\t - instala, lista o desinstala plugins de Helm\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\ndesinstala uno o más plugins de Helm\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Opciones\n\n```\n  -h, --help   ayuda para uninstall\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm plugin](/helm/helm_plugin.md)\t - instala, lista o desinstala plugins de Helm\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\nactualiza uno o más plugins de Helm\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### Opciones\n\n```\n  -h, --help   ayuda para update\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm plugin](./helm_plugin.md)\t - instala, lista o desinstala plugins de Helm\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\ndescarga un chart de un repositorio y (opcionalmente) lo desempaqueta en un directorio local\n\n### Sinopsis\n\nRecupera un paquete de un repositorio de paquetes y lo descarga localmente.\n\nEs ú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.\n\nHay opciones para desempaquetar el chart después de la descarga. Esto creará un directorio para el chart y lo descomprimirá en ese directorio.\n\nSi 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.\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string             verifica certificados de servidores habilitados con HTTPS usando este paquete de CA\n      --cert-file string           identifica el cliente HTTPS usando este archivo de certificado SSL\n  -d, --destination string         ubicación donde escribir el chart. Si se especifica junto con untardir, untardir se agrega a esta ruta (por defecto \".\")\n      --devel                      incluye versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esta opción se ignora.\n  -h, --help                       ayuda para pull\n      --insecure-skip-tls-verify   omite las verificaciones del certificado TLS para la descarga del chart\n      --key-file string            identifica el cliente HTTPS usando este archivo de clave SSL\n      --keyring string             ubicación de las claves públicas usadas para verificación (por defecto \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pasa credenciales a todos los dominios\n      --password string            contraseña del repositorio de charts donde ubicar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la descarga del chart\n      --prov                       descarga el archivo de procedencia, pero no realiza verificación\n      --repo string                URL del repositorio de charts donde ubicar el chart solicitado\n      --untar                      si se establece a true, desempaquetará el chart después de descargarlo\n      --untardir string            si se especifica untar, esta opción indica el nombre del directorio donde se expandirá el chart (por defecto \".\")\n      --username string            nombre de usuario del repositorio de charts donde ubicar el chart solicitado\n      --verify                     verifica el paquete antes de usarlo\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\nsube un chart a un registro remoto\n\n### Sinopsis\n\nSube un chart a un registro.\n\nSi el chart tiene un archivo de procedencia asociado,\neste también será subido.\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string             verifica certificados de servidores habilitados con HTTPS usando este paquete de CA\n      --cert-file string           identifica el cliente del registro usando este archivo de certificado SSL\n  -h, --help                       ayuda para push\n      --insecure-skip-tls-verify   omite las verificaciones del certificado TLS para la subida del chart\n      --key-file string            identifica el cliente del registro usando este archivo de clave SSL\n      --password string            contraseña del repositorio de charts donde ubicar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la subida del chart\n      --username string            nombre de usuario del repositorio de charts donde ubicar el chart solicitado\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\niniciar o cerrar sesión en un registro\n\n### Sinopsis\n\nEste comando consiste en múltiples subcomandos para interactuar con registros.\n\n### Opciones\n\n```\n  -h, --help   ayuda para registry\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes de Helm para Kubernetes.\n* [helm registry login](./helm_registry_login.md)\t - iniciar sesión en un registro\n* [helm registry logout](./helm_registry_logout.md)\t - cerrar sesión de un registro\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\niniciar sesión en un registro\n\n### Sinopsis\n\nAutenticarse en un registro remoto.\n\n```\nhelm registry login [host] [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string     verificar certificados de servidores habilitados con HTTPS usando este paquete de CA\n      --cert-file string   identificar al cliente del registro usando este archivo de certificado SSL\n  -h, --help               ayuda para login\n      --insecure           permitir conexiones a un registro TLS sin certificados\n      --key-file string    identificar al cliente del registro usando este archivo de clave SSL\n  -p, --password string    contraseña del registro o token de identidad\n      --password-stdin     leer contraseña o token de identidad desde stdin\n      --plain-http         usar conexiones HTTP inseguras para la carga del chart\n  -u, --username string    nombre de usuario del registro\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm registry](./helm_registry.md)\t - iniciar o cerrar sesión en un registro\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\ncerrar sesión de un registro\n\n### Sinopsis\n\nElimina las credenciales almacenadas para un registro remoto.\n\n```\nhelm registry logout [host] [flags]\n```\n\n### Opciones\n\n```\n  -h, --help   ayuda para logout\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm registry](./helm_registry.md)\t - iniciar o cerrar sesión en un registro\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\nañade, lista, elimina, actualiza e indexa repositorios de charts\n\n### Sinopsis\n\nEste comando consiste en múltiples subcomandos para interactuar con repositorios de charts.\n\nPuede usarse para añadir, eliminar, listar e indexar repositorios de charts.\n\n### Opciones\n\n```\n  -h, --help   ayuda para repo\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes de Helm para Kubernetes.\n* [helm repo add](./helm_repo_add.md)\t - añade un repositorio de charts\n* [helm repo index](./helm_repo_index.md)\t - genera un archivo de índice dado un directorio que contiene charts empaquetados\n* [helm repo list](./helm_repo_list.md)\t - lista repositorios de charts\n* [helm repo remove](./helm_repo_remove.md)\t - elimina uno o más repositorios de charts\n* [helm repo update](./helm_repo_update.md)\t - actualiza la información de charts disponibles localmente desde repositorios de charts\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\nañade un repositorio de charts\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Opciones\n\n```\n      --allow-deprecated-repos     por defecto, este comando no permite añadir repositorios oficiales que han sido eliminados permanentemente. Esta opción deshabilita ese comportamiento\n      --ca-file string             verifica certificados de servidores HTTPS usando este paquete de CA\n      --cert-file string           identifica el cliente HTTPS usando este archivo de certificado SSL\n      --force-update               reemplaza (sobrescribe) el repositorio si ya existe\n  -h, --help                       ayuda para add\n      --insecure-skip-tls-verify   omite las verificaciones de certificado TLS para el repositorio\n      --key-file string            identifica el cliente HTTPS usando este archivo de clave SSL\n      --no-update                  Ignorado. Anteriormente, deshabilitaba las actualizaciones forzadas. Está obsoleto por force-update.\n      --pass-credentials           pasa las credenciales a todos los dominios\n      --password string            contraseña del repositorio de charts\n      --password-stdin             lee la contraseña del repositorio de charts desde stdin\n      --timeout duration           tiempo de espera para que se complete la descarga del archivo de índice (por defecto 2m0s)\n      --username string            nombre de usuario del repositorio de charts\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm repo](./helm_repo.md)\t - añade, lista, elimina, actualiza e indexa repositorios de charts\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\ngenera un archivo de índice a partir de un directorio con charts empaquetados\n\n### Sinopsis\n\nLee el directorio actual, genera un archivo de índice basado en los charts encontrados\ny escribe el resultado en 'index.yaml' en el directorio actual.\n\nEsta herramienta se utiliza para crear un archivo 'index.yaml' para un repositorio de charts. Para\nestablecer una URL absoluta para los charts, use la opción '--url'.\n\nPara fusionar el índice generado con un archivo de índice existente, use la opción\n'--merge'. En este caso, los charts encontrados en el directorio actual se fusionarán\ncon el índice proporcionado en --merge, donde los charts locales tienen prioridad sobre\nlos charts existentes.\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### Opciones\n\n```\n  -h, --help           ayuda para index\n      --json           salida en formato JSON\n      --merge string   fusiona el índice generado con el índice proporcionado\n      --url string     url del repositorio de charts\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm repo](./helm_repo.md)\t - añade, lista, elimina, actualiza e indexa repositorios de charts\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\nlista repositorios de charts\n\n```\nhelm repo list [flags]\n```\n\n### Opciones\n\n```\n  -h, --help            ayuda para list\n  -o, --output format   imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm repo](./helm_repo.md)\t - añade, lista, elimina, actualiza e indexa repositorios de charts\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nelimina uno o más repositorios de charts\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Opciones\n\n```\n  -h, --help   ayuda para remove\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm repo](./helm_repo.md)\t - añade, lista, elimina, actualiza e indexa repositorios de charts\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\nactualiza la información local de los charts disponibles en los repositorios\n\n### Sinopsis\n\nEste comando obtiene la información más reciente sobre charts desde los repositorios de charts correspondientes.\nLa información se almacena en caché localmente, donde es utilizada por comandos como 'helm search'.\n\nOpcionalmente puede especificar una lista de repositorios que desea actualizar.\n\t$ helm repo update <repo_name> ...\nPara actualizar todos los repositorios, use 'helm repo update'.\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Opciones\n\n```\n      --fail-on-repo-update-fail   la actualización falla si alguna de las actualizaciones de repositorio falla\n  -h, --help                       ayuda para update\n      --timeout duration           tiempo de espera para que se complete la descarga del archivo de índice (por defecto 2m0s)\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm repo](./helm_repo.md)\t - añade, lista, elimina, actualiza e indexa repositorios de charts\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\nrevierte un release a una revisión anterior\n\n### Sinopsis\n\nEste comando revierte un release a una revisión anterior.\n\nEl 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.\n\nPara ver los números de revisión, ejecute 'helm history RELEASE'.\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Opciones\n\n```\n      --cleanup-on-fail    permite eliminar nuevos recursos creados en este rollback cuando el rollback falla\n      --dry-run            simula un rollback\n      --force              fuerza la actualización de recursos mediante eliminación/recreación si es necesario\n  -h, --help               ayuda para rollback\n      --history-max int    limita el número máximo de revisiones guardadas por release. Use 0 para sin límite (por defecto 10)\n      --no-hooks           evita que los hooks se ejecuten durante el rollback\n      --recreate-pods      realiza el reinicio de pods para el recurso si es aplicable\n      --timeout duration   tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s)\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\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\nbusca una palabra clave en charts\n\n### Sinopsis\n\nPermite 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.\n\n### Opciones\n\n```\n  -h, --help   ayuda para search\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes de Helm para Kubernetes.\n* [helm search hub](./helm_search_hub.md)\t - busca charts en Artifact Hub o en su propia instancia de hub\n* [helm search repo](./helm_search_repo.md)\t - busca charts por palabra clave en los repositorios\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\nbusca charts en Artifact Hub o en su propia instancia de hub\n\n### Sinopsis\n\nBusca charts de Helm en Artifact Hub o en su propia instancia de hub.\n\nArtifact 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/\n\nEl 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\n\nLas 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\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### Opciones\n\n```\n      --endpoint string      instancia de Hub a consultar para charts (por defecto \"https://hub.helm.sh\")\n      --fail-on-no-result    la búsqueda falla si no se encuentran resultados\n  -h, --help                 ayuda para hub\n      --list-repo-url        imprime la URL del repositorio de charts\n      --max-col-width uint   ancho máximo de columna para la tabla de salida (por defecto 50)\n  -o, --output format        imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm search](./helm_search.md)\t - busca una palabra clave en charts\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\nbusca charts por palabra clave en los repositorios\n\n### Sinopsis\n\nLee todos los repositorios configurados en el sistema y busca coincidencias. La búsqueda en estos repositorios utiliza los metadatos almacenados en el sistema.\n\nMostrará 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.\n\nEjemplos:\n\n    # Buscar versiones de release estables que coincidan con la palabra clave \"nginx\"\n    $ helm search repo nginx\n\n    # Buscar versiones de release que coincidan con la palabra clave \"nginx\", incluyendo versiones preliminares\n    $ helm search repo nginx --devel\n\n    # Buscar la última versión estable de nginx-ingress con una versión mayor de 1\n    $ helm search repo nginx-ingress --version ^1.0.0\n\nLos repositorios se gestionan con los comandos 'helm repo'.\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### Opciones\n\n```\n      --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\n      --fail-on-no-result    la búsqueda falla si no se encuentran resultados\n  -h, --help                 ayuda para repo\n      --max-col-width uint   ancho máximo de columna para la tabla de salida (por defecto 50)\n  -o, --output format        imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n  -r, --regexp               usar expresiones regulares para buscar en los repositorios que ha añadido\n      --version string       buscar usando restricciones de versionado semántico en los repositorios que ha añadido\n  -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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm search](./helm_search.md)\t - busca una palabra clave en charts\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\nmuestra información de un chart\n\n### Sinopsis\n\nEste comando consiste en múltiples subcomandos para mostrar información sobre un chart\n\n\n### Opciones\n\n```\n  -h, --help   ayuda para show\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n* [helm show all](./helm_show_all.md)\t - muestra toda la información del chart\n* [helm show chart](./helm_show_chart.md)\t - muestra la definición del chart\n* [helm show crds](./helm_show_crds.md)\t - muestra los CRDs del chart\n* [helm show readme](./helm_show_readme.md)\t - muestra el README del chart\n* [helm show values](./helm_show_values.md)\t - muestra los values del chart\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\nmuestra toda la información del chart\n\n### Sinopsis\n\nEste comando inspecciona un chart (directorio, archivo o URL) y muestra todo su contenido\n(values.yaml, Chart.yaml, README)\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS usando este paquete de CA\n      --cert-file string           identifica al cliente HTTPS usando este archivo de certificado SSL\n      --devel                      usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora\n  -h, --help                       ayuda para all\n      --insecure-skip-tls-verify   omite las verificaciones de certificado TLS para la descarga del chart\n      --key-file string            identifica al cliente HTTPS usando este archivo de clave SSL\n      --keyring string             ubicación de las claves públicas usadas para verificación (por defecto \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pasa credenciales a todos los dominios\n      --password string            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la descarga del chart\n      --repo string                URL del repositorio de charts donde localizar el chart solicitado\n      --username string            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n      --verify                     verifica el paquete antes de usarlo\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm show](./helm_show.md)\t - muestra información de un chart\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\nmuestra la definición del chart\n\n### Sinopsis\n\nEste comando inspecciona un chart (directorio, archivo o URL) y muestra el contenido\ndel archivo Chart.yaml\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS usando este paquete de CA\n      --cert-file string           identifica al cliente HTTPS usando este archivo de certificado SSL\n      --devel                      usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora\n  -h, --help                       ayuda para chart\n      --insecure-skip-tls-verify   omite las verificaciones de certificado TLS para la descarga del chart\n      --key-file string            identifica al cliente HTTPS usando este archivo de clave SSL\n      --keyring string             ubicación de las claves públicas usadas para verificación (por defecto \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pasa credenciales a todos los dominios\n      --password string            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la descarga del chart\n      --repo string                URL del repositorio de charts donde localizar el chart solicitado\n      --username string            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n      --verify                     verifica el paquete antes de usarlo\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm show](./helm_show.md)\t - muestra información de un chart\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\nmuestra los CRDs del chart\n\n### Sinopsis\n\nEste comando inspecciona un chart (directorio, archivo o URL) y muestra el contenido\nde los archivos CustomResourceDefinition\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS usando este paquete de CA\n      --cert-file string           identifica al cliente HTTPS usando este archivo de certificado SSL\n      --devel                      usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora\n  -h, --help                       ayuda para crds\n      --insecure-skip-tls-verify   omite las verificaciones de certificado TLS para la descarga del chart\n      --key-file string            identifica al cliente HTTPS usando este archivo de clave SSL\n      --keyring string             ubicación de las claves públicas usadas para verificación (por defecto \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pasa credenciales a todos los dominios\n      --password string            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la descarga del chart\n      --repo string                URL del repositorio de charts donde localizar el chart solicitado\n      --username string            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n      --verify                     verifica el paquete antes de usarlo\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm show](./helm_show.md)\t - muestra información de un chart\n\n###### Generado automáticamente por spf13/cobra el 14-Ene-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nmuestra el README del chart\n\n### Sinopsis\n\nEste comando inspecciona un chart (directorio, archivo o URL) y muestra el contenido\ndel archivo README\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS usando este paquete de CA\n      --cert-file string           identifica al cliente HTTPS usando este archivo de certificado SSL\n      --devel                      usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora\n  -h, --help                       ayuda para readme\n      --insecure-skip-tls-verify   omite las verificaciones de certificado TLS para la descarga del chart\n      --key-file string            identifica al cliente HTTPS usando este archivo de clave SSL\n      --keyring string             ubicación de las claves públicas usadas para verificación (por defecto \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pasa credenciales a todos los dominios\n      --password string            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la descarga del chart\n      --repo string                URL del repositorio de charts donde localizar el chart solicitado\n      --username string            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n      --verify                     verifica el paquete antes de usarlo\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm show](./helm_show.md)\t - muestra información de un chart\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\nmuestra los valores del chart\n\n### Sinopsis\n\nEste comando inspecciona un chart (directorio, archivo o URL) y muestra el contenido\ndel archivo values.yaml\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### Opciones\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS usando este paquete de CA\n      --cert-file string           identifica al cliente HTTPS usando este archivo de certificado SSL\n      --devel                      usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora\n  -h, --help                       ayuda para values\n      --insecure-skip-tls-verify   omite las verificaciones de certificado TLS para la descarga del chart\n      --jsonpath string            proporciona una expresión JSONPath para filtrar la salida\n      --key-file string            identifica al cliente HTTPS usando este archivo de clave SSL\n      --keyring string             ubicación de las claves públicas usadas para verificación (por defecto \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pasa credenciales a todos los dominios\n      --password string            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                 usa conexiones HTTP inseguras para la descarga del chart\n      --repo string                URL del repositorio de charts donde localizar el chart solicitado\n      --username string            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n      --verify                     verifica el paquete antes de usarlo\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm show](./helm_show.md)\t - muestra información de un chart\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\nmuestra el estado del release especificado\n\n### Sinopsis\n\nEste comando muestra el estado de un release especificado.\nEl estado consiste en:\n- fecha y hora del último despliegue\n- namespace de Kubernetes en el que reside el release\n- estado del release (puede ser: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade o pending-rollback)\n- revisión del release\n- descripción del release (puede ser un mensaje de finalización o un mensaje de error, requiere habilitar --show-desc)\n- lista de recursos que componen este release (requiere habilitar --show-resources)\n- detalles de la última ejecución del conjunto de pruebas, si aplica\n- notas adicionales proporcionadas por el chart\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### Opciones\n\n```\n  -h, --help             ayuda para status\n  -o, --output format    imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n      --revision int     si se establece, muestra el estado del release especificado con esa revisión\n      --show-desc        si se establece, muestra el mensaje de descripción del release especificado\n      --show-resources   si se establece, muestra los recursos del release especificado\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nrenderiza plantillas localmente\n\n### Sinopsis\n\nRenderiza las plantillas del chart localmente y muestra la salida.\n\nCualquier valor que normalmente se buscaría o recuperaría en el clúster será\nsimulado localmente. Además, no se realiza ninguna validación del chart\ndel lado del servidor (por ejemplo, si una API es compatible).\n\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### Opciones\n\n```\n  -a, --api-versions strings                       versiones de la API de Kubernetes utilizadas para Capabilities.APIVersions\n      --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\n      --ca-file string                             verifica certificados de servidores con HTTPS habilitado usando este bundle de CA\n      --cert-file string                           identifica el cliente HTTPS usando este archivo de certificado SSL\n      --create-namespace                           crea el namespace del release si no está presente\n      --dependency-update                          actualiza las dependencias si faltan antes de instalar el chart\n      --description string                         añade una descripción personalizada\n      --devel                                      usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora\n      --disable-openapi-validation                 si se establece, el proceso de instalación no validará las plantillas renderizadas contra el esquema OpenAPI de Kubernetes\n      --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.\n      --enable-dns                                 habilita búsquedas DNS al renderizar plantillas\n      --force                                      fuerza actualizaciones de recursos a través de una estrategia de reemplazo\n  -g, --generate-name                              genera el nombre (y omite el parámetro NAME)\n  -h, --help                                       ayuda para template\n      --hide-notes                                 si se establece, no muestra las notas en la salida. No afecta su presencia en los metadatos del chart\n      --include-crds                               incluye CRDs en la salida renderizada\n      --insecure-skip-tls-verify                   omite verificaciones de certificado TLS para la descarga del chart\n      --is-upgrade                                 establece .Release.IsUpgrade en lugar de .Release.IsInstall\n      --key-file string                            identifica el cliente HTTPS usando este archivo de clave SSL\n      --keyring string                             ubicación de las claves públicas usadas para verificación (por defecto \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        versión de Kubernetes usada para Capabilities.KubeVersion\n  -l, --labels stringToString                      etiquetas que se añadirían a los metadatos del release. Deben separarse con comas. (por defecto [])\n      --name-template string                       especifica la plantilla usada para nombrar el release\n      --no-hooks                                   evita que los hooks se ejecuten durante la instalación\n      --output-dir string                          escribe las plantillas ejecutadas en archivos en output-dir en lugar de stdout\n      --pass-credentials                           pasa credenciales a todos los dominios\n      --password string                            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                                 usa conexiones HTTP inseguras para la descarga del chart\n      --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\n      --post-renderer-args postRendererArgsSlice   un argumento para el post-renderer (puede especificar múltiples) (por defecto [])\n      --release-name                               usa el nombre del release en la ruta de output-dir.\n      --render-subchart-notes                      si se establece, renderiza las notas del subchart junto con el padre\n      --replace                                    reutiliza el nombre dado, solo si ese nombre es un release eliminado que permanece en el historial. Esto es inseguro en producción\n      --repo string                                URL del repositorio de charts donde localizar el chart solicitado\n      --set stringArray                            establece valores en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2)\n      --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)\n      --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)\n      --set-literal stringArray                    establece un valor STRING literal en la línea de comandos\n      --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)\n  -s, --show-only stringArray                      solo muestra manifiestos renderizados desde las plantillas especificadas\n      --skip-crds                                  si se establece, no se instalarán CRDs. Por defecto, los CRDs se instalan si no están presentes\n      --skip-schema-validation                     si se establece, deshabilita la validación del esquema JSON\n      --skip-tests                                 omite las pruebas en la salida renderizada\n      --take-ownership                             si se establece, install ignorará la verificación de anotaciones de helm y tomará posesión de los recursos existentes\n      --timeout duration                           tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s)\n      --username string                            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n      --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\n  -f, --values strings                             especifica valores en un archivo YAML o una URL (puede especificar múltiples)\n      --verify                                     verifica el paquete antes de usarlo\n      --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\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\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita la salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a utilizar\n      --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\n      --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\n      --kube-token string               token bearer utilizado para la autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\nejecuta las pruebas de un release\n\n### Sinopsis\n\nEl comando test ejecuta las pruebas de un release.\n\nEste comando recibe como argumento el nombre de un release desplegado.\nLas pruebas que se ejecutarán están definidas en el chart instalado.\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### Opciones\n\n```\n      --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)\n  -h, --help               ayuda para test\n      --hide-notes         si se establece, no muestra las notas en la salida de test. No afecta su presencia en los metadatos del chart\n      --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)\n      --timeout duration   tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s)\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita la salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a utilizar\n      --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\n      --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\n      --kube-token string               token bearer utilizado para la autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\ndesinstala un release\n\n### Sinopsis\n\nEste comando recibe un nombre de release y lo desinstala.\n\nElimina todos los recursos asociados con la última versión del chart, así como el historial del release, liberándolo para uso futuro.\n\nUse la opción '--dry-run' para ver qué releases serán desinstalados sin desinstalarlos realmente.\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Opciones\n\n```\n      --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\")\n      --description string   añade una descripción personalizada\n      --dry-run              simula una desinstalación\n  -h, --help                 ayuda para uninstall\n      --ignore-not-found     Trata \"release no encontrado\" como una desinstalación exitosa\n      --keep-history         elimina todos los recursos asociados y marca el release como eliminado, pero retiene el historial del release\n      --no-hooks             evita que los hooks se ejecuten durante la desinstalación\n      --timeout duration     tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s)\n      --wait                 si se establece, esperará hasta que todos los recursos sean eliminados antes de finalizar. Esperará tanto tiempo como se especifique en --timeout\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a usar\n      --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\n      --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\n      --kube-token string               token bearer usado para autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](/helm/helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nactualiza un release a una nueva versión de un chart\n\n### Sinopsis\n\nEste comando actualiza un release a una nueva versión de un chart.\n\nLos 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'.\n\nPara 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.\n\nPuede 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:\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\nPuede 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:\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\nTambié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.\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\nLa 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.\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Opciones\n\n```\n      --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\n      --ca-file string                             verifica certificados de servidores habilitados con HTTPS usando este paquete de CA\n      --cert-file string                           identifica el cliente HTTPS usando este archivo de certificado SSL\n      --cleanup-on-fail                            permite eliminar nuevos recursos creados en este upgrade cuando el upgrade falla\n      --create-namespace                           si --install está establecido, crea el namespace del release si no está presente\n      --dependency-update                          actualiza las dependencias si faltan antes de instalar el chart\n      --description string                         añade una descripción personalizada\n      --devel                                      usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si --version está establecido, esto se ignora\n      --disable-openapi-validation                 si se establece, el proceso de upgrade no validará las plantillas renderizadas contra el esquema OpenAPI de Kubernetes\n      --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.\n      --enable-dns                                 habilita búsquedas DNS al renderizar plantillas\n      --force                                      fuerza actualizaciones de recursos mediante una estrategia de reemplazo\n  -h, --help                                       ayuda para upgrade\n      --hide-notes                                 si se establece, no muestra las notas en la salida del upgrade. No afecta su presencia en los metadatos del chart\n      --hide-secret                                oculta los Secrets de Kubernetes cuando también se usa la opción --dry-run\n      --history-max int                            limita el número máximo de revisiones guardadas por release. Use 0 para sin límite (por defecto 10)\n      --insecure-skip-tls-verify                   omite verificaciones de certificado TLS para la descarga del chart\n  -i, --install                                    si un release con este nombre no existe, ejecuta una instalación\n      --key-file string                            identifica el cliente HTTPS usando este archivo de clave SSL\n      --keyring string                             ubicación de las claves públicas usadas para verificación (por defecto \"~/.gnupg/pubring.gpg\")\n  -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 [])\n      --no-hooks                                   deshabilita los hooks pre/post upgrade\n  -o, --output format                              imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table)\n      --pass-credentials                           pasa credenciales a todos los dominios\n      --password string                            contraseña del repositorio de charts donde localizar el chart solicitado\n      --plain-http                                 usa conexiones HTTP inseguras para la descarga del chart\n      --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\n      --post-renderer-args postRendererArgsSlice   un argumento para el post-renderer (puede especificar múltiples) (por defecto [])\n      --render-subchart-notes                      si se establece, renderiza las notas del subchart junto con el padre\n      --repo string                                URL del repositorio de charts donde localizar el chart solicitado\n      --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\n      --reset-values                               al actualizar, restablece los valores a los incorporados en el chart\n      --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\n      --set stringArray                            establece valores en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2)\n      --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)\n      --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)\n      --set-literal stringArray                    establece un valor STRING literal en la línea de comandos\n      --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)\n      --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\n      --skip-schema-validation                     si se establece, deshabilita la validación de esquema JSON\n      --take-ownership                             si se establece, el upgrade ignorará la verificación de anotaciones de helm y tomará posesión de los recursos existentes\n      --timeout duration                           tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s)\n      --username string                            nombre de usuario del repositorio de charts donde localizar el chart solicitado\n  -f, --values strings                             especifica valores en un archivo YAML o una URL (puede especificar múltiples)\n      --verify                                     verifica el paquete antes de usarlo\n      --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\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\n      --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\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita la salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a utilizar\n      --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\n      --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\n      --kube-token string               token bearer utilizado para la autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\nverifica que un chart en la ruta dada ha sido firmado y es válido\n\n### Sinopsis\n\nVerifica que el chart especificado tenga un archivo de procedencia válido.\n\nLos archivos de procedencia proporcionan verificación criptográfica de que un chart no ha sido manipulado y fue empaquetado por un proveedor de confianza.\n\nEste 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'.\n\n\n```\nhelm verify PATH [flags]\n```\n\n### Opciones\n\n```\n  -h, --help             ayuda para verify\n      --keyring string   llavero que contiene las claves públicas (por defecto \"~/.gnupg/pubring.gpg\")\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita la salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a utilizar\n      --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\n      --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\n      --kube-token string               token bearer utilizado para la autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n\nmuestra la información de versión del cliente\n\n### Sinopsis\n\nMuestra la versión de Helm.\n\nEste comando imprimirá una representación de la versión de Helm.\nLa salida tendrá un aspecto similar a este:\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version es la versión semántica de la release.\n- GitCommit es el SHA del commit a partir del cual se construyó esta versión.\n- GitTreeState es \"clean\" si no hay cambios locales en el código cuando se\n  construyó este binario, y \"dirty\" si el binario fue construido a partir\n  de código modificado localmente.\n- GoVersion es la versión de Go que se utilizó para compilar Helm.\n\nCuando utilice la opción --template, las siguientes propiedades están disponibles\npara usar en la plantilla:\n\n- .Version contiene la versión semántica de Helm\n- .GitCommit es el commit de git\n- .GitTreeState es el estado del árbol de git cuando se construyó Helm\n- .GoVersion contiene la versión de Go con la que se compiló Helm\n\nPor ejemplo, --template='Version: {{.Version}}' produce 'Version: v3.2.1'.\n\n\n```\nhelm version [flags]\n```\n\n### Opciones\n\n```\n  -h, --help              ayuda para version\n      --short             muestra solo el número de versión\n      --template string   plantilla para el formato de la cadena de versión\n```\n\n### Opciones heredadas de comandos padre\n\n```\n      --burst-limit int                 límite de throttling del lado del cliente (por defecto 100)\n      --debug                           habilita la salida detallada\n      --kube-apiserver string           la dirección y el puerto del servidor de API de Kubernetes\n      --kube-as-group stringArray       grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos.\n      --kube-as-user string             nombre de usuario a suplantar para la operación\n      --kube-ca-file string             el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes\n      --kube-context string             nombre del contexto de kubeconfig a utilizar\n      --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\n      --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\n      --kube-token string               token bearer utilizado para la autenticación\n      --kubeconfig string               ruta al archivo kubeconfig\n  -n, --namespace string                ámbito del namespace para esta solicitud\n      --qps float32                     consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas\n      --registry-config string          ruta al archivo de configuración del registro (por defecto \"~/.config/helm/registry/config.json\")\n      --repository-cache string         ruta al directorio que contiene los índices de repositorios en caché (por defecto \"~/.cache/helm/repository\")\n      --repository-config string        ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto \"~/.config/helm/repositories.yaml\")\n```\n\n### VEA TAMBIÉN\n\n* [helm](./helm.md)\t - El gestor de paquetes Helm para Kubernetes.\n\n###### Generado automáticamente por spf13/cobra el 14-Jan-2026\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: \"Chart Releaser Action para automatizar la publicación de Charts en GitHub Pages\"\ndescription: \"Describe cómo utilizar Chart Releaser Action para automatizar la publicación de charts a través de GitHub Pages.\"\nsidebar_position: 3\n---\n\nEsta guía describe cómo utilizar [Chart Releaser\nAction](https://github.com/marketplace/actions/helm-chart-releaser) para automatizar\nla publicación de charts a través de GitHub Pages. Chart Releaser Action es un workflow\nde GitHub Action para convertir un proyecto de GitHub en un repositorio de Helm charts\nautoalojado, utilizando la herramienta CLI\n[helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n## Cambios en el Repositorio\n\nCree un repositorio Git en su organización de GitHub. Puede nombrar el repositorio\ncomo `helm-charts`, aunque otros nombres también son aceptables. El código fuente\nde todos los charts puede colocarse en la rama `main`. Los charts deben ubicarse\nen el directorio `/charts` en el nivel superior del árbol de directorios.\n\nDebe existir otra rama llamada `gh-pages` para publicar los charts. Los cambios en\nesa rama serán creados automáticamente por Chart Releaser Action como se describe\naquí. Sin embargo, puede crear esa rama `gh-pages` y añadir un archivo `README.md`,\nque será visible para los usuarios que visiten la página.\n\nPuede añadir instrucciones en el `README.md` para la instalación de charts de la\nsiguiente manera (reemplace `<alias>`, `<orgname>` y `<chart-name>`):\n\n```\n## Uso\n\n[Helm](https://helm.sh) debe estar instalado para usar los charts. Consulte la\n[documentación](https://helm.sh/docs) de Helm para comenzar.\n\nUna vez que Helm esté configurado correctamente, añada el repositorio de la siguiente manera:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nSi ya añadió este repositorio anteriormente, ejecute `helm repo update` para obtener\nlas últimas versiones de los paquetes. Luego puede ejecutar `helm search repo\n<alias>` para ver los charts.\n\nPara instalar el chart <chart-name>:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nPara desinstalar el chart:\n\n    helm uninstall my-<chart-name>\n```\n\nLos charts se publicarán en un sitio web con una URL como esta:\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions Workflow\n\nCree un archivo de workflow de GitHub Actions en la rama `main` en\n`.github/workflows/release.yml`\n\n```yaml\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nLa configuración anterior utiliza\n[@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) para\nconvertir su proyecto de GitHub en un repositorio de Helm charts autoalojado. Esto\nfunciona de la siguiente manera: durante cada push a main, verifica cada chart en\nsu proyecto y, cuando hay una nueva versión de chart, crea un release de GitHub\ncorrespondiente con el nombre de la versión del chart, añade los artefactos del\nHelm chart al release, y crea o actualiza un archivo `index.yaml` con metadatos\nsobre esos releases, que luego se alojan en GitHub Pages.\n\nLa versión de Chart Releaser Action utilizada en el ejemplo anterior es `v1.6.0`.\nPuede cambiarla por la [última versión\ndisponible](https://github.com/helm/chart-releaser-action/releases).\n\nNota: Chart Releaser Action se utiliza casi siempre junto con [Helm Testing\nAction](https://github.com/marketplace/actions/helm-chart-testing) y [Kind\nAction](https://github.com/marketplace/actions/kind-cluster).\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: \"Sincronizar su Repositorio de Charts\"\ndescription: \"Describe cómo sincronizar sus repositorios de charts locales y remotos.\"\nsidebar_position: 2\n---\n\n*Nota: Este ejemplo es específico para un bucket de Google Cloud Storage (GCS)\nque sirve como repositorio de charts.*\n\n## Requisitos Previos\n\n* Instalar la herramienta [gsutil](https://cloud.google.com/storage/docs/gsutil).\n  *Dependemos en gran medida de la funcionalidad de gsutil rsync*\n* Asegúrese de tener acceso al binario de Helm\n* _Opcional: Le recomendamos que establezca [control de versiones del\n  objeto](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)\n  en su bucket de GCS en caso de que elimine algo accidentalmente._\n\n## Configurar un directorio de repositorio de charts local\n\nCree un directorio local como lo hicimos en [la guía del repositorio de charts](/topics/chart_repository.md)\n, y coloque sus charts empaquetados en ese directorio.\n\nPor ejemplo:\n\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Genere un index.yaml actualizado\n\nUtilice Helm para generar un archivo index.yaml actualizado pasando la ruta del\ndirectorio y la URL del repositorio remoto al comando `helm repo index` de esta\nmanera:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\n\nEsto generará un archivo index.yaml actualizado y lo colocará en el directorio\n`fantastic-charts/`.\n\n## Sincronice sus repositorios de charts locales y remotos\n\nSuba el contenido del directorio a su bucket de GCS ejecutando `scripts/sync-repo.sh`\ny pase el nombre del directorio local y el nombre del bucket de GCS.\n\nPor ejemplo:\n\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n\n## Actualizar su repositorio de charts\n\nQuerrá mantener una copia local del contenido de su repositorio de charts o usar\n`gsutil rsync` para copiar el contenido de su repositorio de charts remoto a un\ndirectorio local.\n\nPor ejemplo:\n\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # la bandera -n hace un ensayo\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # realiza las acciones de copia\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nEnlaces Útiles:\n\n* Documentación sobre [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [La Guía del Repositorio de Charts](/topics/chart_repository.md)\n* Documentación sobre [Control de versiones de objetos y control de \n  simultaneidad](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)\n  en Google Cloud Storage\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: \"Consejos y Trucos para el Desarrollo de Charts\"\ndescription: \"Cubre algunos de los consejos y trucos que los desarrolladores de charts de Helm han aprendido al crear charts con calidad de producción.\"\nsidebar_position: 1\n---\n\nEsta guía cubre algunos de los consejos y trucos que los desarrolladores de charts\nde Helm han aprendido al crear charts con calidad de producción.\n\n## Conozca las Funciones de Plantilla\n\nHelm usa [plantillas Go](https://godoc.org/text/template) para crear plantillas\npara sus archivos de recursos. Si bien Go incluye varias funciones integradas,\nhemos agregado muchas otras.\n\nPrimero, agregamos todas las funciones en la [biblioteca\nSprig](https://masterminds.github.io/sprig/), excepto `env` y `expandenv`, por\nrazones de seguridad.\n\nTambién agregamos dos funciones de plantilla especiales: `include` y\n`required`. La función `include` le permite traer otra plantilla y luego pasar\nlos resultados a otras funciones de la plantilla.\n\nPor ejemplo, este fragmento de plantilla incluye una plantilla llamada `mytpl`,\nluego pone el resultado en minúsculas y luego lo envuelve entre comillas dobles.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nLa función `required` le permite declarar una entrada de valores particulares según\nsea necesario para la representación de la plantilla. Si el valor está vacío,\nla representación de la plantilla fallará con un mensaje de error enviado al\nusuario.\n\nEl siguiente ejemplo de la función `required` declara que una entrada para\n`.Values.who` es obligatoria e imprimirá un mensaje de error cuando falte esa entrada:\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## Envuelva en Comillas las Cadenas, no los Enteros\n\nCuando trabaja con cadenas de caracteres, siempre es más seguro envolverlas entre\ncomillas dobles que dejarlas como palabras sueltas:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nPero cuando trabaje con números enteros, _no envuelva entre comillas dobles los\nvalores._ Eso puede, en muchos casos, causar errores de análisis dentro de Kubernetes.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nEsta observación no se aplica a los valores de las variables de entorno que se espera\nque sean cadenas, incluso si representan números enteros:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Utilizar la Función 'include'\n\nGo proporciona una forma de incluir una plantilla en otra utilizando la directiva\nincorporada `template`. Sin embargo, la directiva incorporada no se puede utilizar\nen las canalizaciones de plantilla de Go.\n\nPara que sea posible incluir una plantilla y luego realizar una operación en la\nsalida de esa plantilla, Helm tiene una función `include` especial:\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nLo anterior incluye una plantilla llamada `toYaml`, le pasa `$value` y luego pasa\nla salida de esa plantilla a la función `indent`.\n\nDebido a que YAML atribuye importancia a los niveles de sangría y los espacios\nen blanco, esta es una excelente manera de incluir fragmentos de código, pero\nmanejar la sangría en un contexto relevante.\n\n## Utilizar la Función 'required'\n\nGo proporciona una forma de configurar opciones de plantilla para controlar el\ncomportamiento cuando un mapa se indexa con una clave que no está presente en el\nmapa. Por lo general, esto se establece con `template.Options(\"missingkey=option\")`,\ndonde `option` puede ser `default`, `zero` o `error`. Si bien establecer esta opción\nen error detendrá la ejecución con un error, esto se aplicaría a todas las claves\nque faltan en el mapa. Puede haber situaciones en las que un desarrollador de charts\nquiera aplicar este comportamiento para valores seleccionados en el archivo `values.yaml`.\n\nLa función `required` brinda a los desarrolladores la capacidad de declarar una\nentrada de valor según sea necesario para la renderización de la plantilla. Si\nla entrada está vacía en `values.yaml`, la plantilla no se procesará y devolverá\nun mensaje de error proporcionado por el desarrollador.\n\nPor ejemplo:\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nLo anterior renderizará la plantilla cuando se defina `.Values.foo`, pero fallará\nen renderizar y se cerrará cuando `.Values.foo` no esté definido.\n\n## Utilizar la Función 'tpl'\n\nLa función `tpl` permite a los desarrolladores evaluar cadenas como plantillas\ndentro de una plantilla. Esto es útil para pasar una cadena de plantilla como\nvalor a un chart o representar archivos de configuración externos. Sintaxis:\n`{{ tpl TEMPLATE_STRING VALUES }}`\n\nEjemplos:\n\n```yaml\n# valores\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# plantilla\n{{ tpl .Values.template . }}\n\n# salida\nTom\n```\n\nRenderizar un archivo de configuración externo:\n\n```yaml\n# archivo de configuración externo conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# valores\nfirstName: Peter\nlastName: Parker\n\n# plantilla\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# salida\nfirstName=Peter\nlastName=Parker\n```\n\n## Creando Image Pull Secrets\n\nLos Image Pull Secrets son esencialmente una combinación de _registro_,\n_username_ y _password_. Es posible que los necesite en una aplicación que está\nimplementando, pero para crearlos es necesario ejecutar `base64` un par de veces.\nPodemos escribir una plantilla auxiliar para componer el archivo de configuración\nde Docker y usarlo como carga útil del Secret. Aquí hay un ejemplo:\n\nPrimero, suponga que las credenciales están definidas en el archivo `values.yaml`\nasí:\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nLuego definimos nuestra plantilla auxiliar de la siguiente manera:\n\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nFinalmente, usamos la plantilla auxiliar en una plantilla más grande para crear\nel manifiesto del Secret:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Despliegue Automático de Deployments\n\nA menudo, los ConfigMaps o Secrets se inyectan como archivos de configuración en\ncontenedores o hay otros cambios de dependencia externa que requieren recrear pods.\nDependiendo de la aplicación, es posible que sea necesario reiniciar si se actualizan\ncon un `helm upgrade` posterior, pero si el Deployment spec en sí no cambia, la\naplicación sigue ejecutándose con la configuración anterior, lo que da como resultado\nun despliegue inconsistente.\n\nLa función `sha256sum` se puede utilizar para garantizar que la sección de\nanotaciones de un Deployment se actualice si cambia otro archivo:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nNOTA: Si está agregando esto a un library chart, no podrá acceder a su archivo\nen `$.Template.BasePath`. En su lugar, puede hacer referencia a su definición con\n`{{ include (\"mylibchart.configmap\") . | sha256sum }}`.\n\nEn el caso de que siempre desee reiniciar su Deployment, puede usar un paso de anotación\nsimilar al anterior, en lugar de reemplazarlo con una cadena aleatoria para que siempre\ncambie y haga que el Deployment se reinicie:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nCada invocación de la función de plantilla generará una cadena aleatoria única.\nEsto significa que si es necesario sincronizar las cadenas aleatorias utilizadas\npor varios recursos, todos los recursos relevantes deberán estar en el mismo\narchivo de plantilla.\n\nAmbos métodos permiten que su Deployment aproveche la lógica de la estrategia\nde actualización incorporada para evitar tener tiempo de inactividad.\n\nNOTA: En el pasado, recomendamos usar la marca `--recreate-pods` como otra opción.\nEsta marca se ha marcado como obsoleta en Helm 3 a favor del método más\ndeclarativo anterior.\n\n## Dígale a Helm que No Desinstale un Recurso\n\nA veces hay recursos que no deben desinstalarse cuando Helm ejecuta un\n`helm uninstall`. Los desarrolladores de charts pueden agregar una anotación\na un recurso para evitar que se desinstale.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nLa anotación `helm.sh/resource-policy: keep` indica a Helm que omita la\neliminación de este recurso cuando una operación de helm (como `helm uninstall`,\n`helm upgrade` o `helm rollback`) resulte en su eliminación. _Sin embargo_, este\nrecurso queda huérfano. Helm ya no lo administrará de ninguna manera. Esto puede\nocasionar problemas si se usa `helm install --replace` en un release que ya se\nha desinstalado, pero que ha conservado los recursos.\n\n## Utilizar \"Parciales\" (Partials) e Incluir Plantillas\n\nA veces, desea crear algunas partes reutilizables en sus charts, ya sean bloques\no parciales de plantilla. Y, a menudo, es más limpio mantenerlos en sus propios archivos.\n\nEn el directorio `templates/`, no se espera que ningún archivo que comience con\nun guión bajo (`_`) genere un archivo de manifiesto de Kubernetes. Entonces, por\nconvención, las plantillas auxiliares y los parciales se colocan en un archivo\n`_helpers.tpl`.\n\n## Charts Complejos con Muchas Dependencias\n\nMuchos de los charts de [Artifact Hub](https://artifacthub.io/packages/search?kind=0)\nde la CNCF son \"bloques de construcción\" para crear aplicaciones más avanzadas.\nPero los charts pueden usarse para crear instancias de aplicaciones a gran escala.\nEn tales casos, un solo chart general puede tener múltiples sub-charts, cada uno\nde los cuales funciona como una parte del todo.\n\nLa mejor práctica actual para componer una aplicación compleja a partir de partes\ndiscretas es crear un chart general de nivel superior que exponga las configuraciones\nglobales, y luego usar el subdirectorio `charts/` para incrustar cada uno de los\ncomponentes.\n\n## YAML es un Superconjunto de JSON\n\nSegún la especificación YAML, YAML es un superconjunto de JSON. Eso significa que\ncualquier estructura JSON válida debería ser válida en YAML.\n\nEsto tiene una ventaja: a veces, a los desarrolladores de plantillas les puede\nresultar más fácil expresar una estructura de datos con una sintaxis similar a\nJSON en lugar de lidiar con la sensibilidad de los espacios en blanco de YAML.\n\nComo práctica recomendada, las plantillas deben seguir una sintaxis similar a YAML,\n_a menos que_ la sintaxis JSON reduzca sustancialmente el riesgo de problemas de\nformato.\n\n## Tenga Cuidado con la Generación de Valores Aleatorios\n\nHay funciones en Helm que le permiten generar datos aleatorios,\nclaves criptográficas, etc. Está bien usarlos. Pero tenga en cuenta que durante\nlas actualizaciones, las plantillas se vuelven a ejecutar. Cuando la ejecución de\nuna plantilla genera datos que difieren de la última ejecución, se activará una\nactualización de ese recurso.\n\n## Instalar o Actualizar un Release con un Comando\n\nHelm proporciona una forma de realizar una instalación o actualización como un solo\ncomando. Utilice `helm upgrade` con el comando `--install`. Esto hará que Helm vea\nsi el release ya está instalado. De lo contrario, ejecutará una instalación. Si es\nasí, se actualizará el release existente.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/howto/index.mdx",
    "content": "---\ntitle: \"Cómo Hacer\"\nsidebar_position: 2\n---\n\n# Guías de Cómo Hacer\n\nAquí encontrará respuestas breves a preguntas del tipo “¿Cómo hago para ...?”.\nEstas guías prácticas no cubren temas en profundidad; encontrará ese material en\nlas [Guías de Temas](/topics/index.mdx). Sin embargo,\nestas guías lo ayudarán a realizar rápidamente tareas comunes.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"Docs Inicio\"\ndescription: \"Todo lo que necesita saber sobre cómo está organizada la documentación.\"\nsidebar_position: 1\nhide_table_of_contents: true\n---\n\n# Bienvenidos\n\nBienvenidos a la documentación de [Helm](https://helm.sh/). Helm es el administrador\nde paquetes de Kubernetes, y puedes leer información de antecedentes detallados en\nel [CNCF Informe de Viaje del Proyecto de Helm](https://www.cncf.io/cncf-helm-project-journey/).\n\n# Cómo está organizada la documentación\n\nHelm tiene mucha documentación. Una descripción general de alto nivel de cómo está\norganizado lo ayudará a saber dónde buscar ciertas cosas:\n\n- [Tutoriales](/intro/index.mdx) te llevan de la mano a través de una serie de pasos para crear\n  tu primer Helm chart. Empieza aquí si eres nuevo en Helm.\n- [Guías de temas](/topics/index.mdx) discute temas y\n  conceptos clave a un nivel bastante alto y proporcionar información de antecedentes\n  y explicaciones útiles.\n- [Guías de la comunidad](/community) discute\n  temas centrados en la comunidad de Helm. Comience aquí si desea obtener más información\n  sobre el proceso de desarrollo de Helm y cómo puede contribuir.\n- [Guías prácticas](/howto/index.mdx) son recetas. Le\n  guían a través de los pasos necesarios para abordar problemas clave y casos de uso.\n  Son más avanzados que los tutoriales y asumen cierto conocimiento de cómo funciona\n  Helm.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />  "
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: Guía Rápida\ndescription: Guía rápida de comandos de Helm\nsidebar_position: 4\n---\n\nGuía rápida de Helm con todos los comandos necesarios para gestionar una aplicación a través de Helm.\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### Interpretaciones básicas/contexto\n\nChart:\n- Es el nombre de su chart en caso de que haya sido descargada y descomprimida.\n- Es <nombre_repo>/<nombre_chart> en caso de que el repositorio se haya añadido pero la chart no se haya descargado.\n- Es la URL/ruta absoluta a la chart.\n\nName:\n- Es el nombre que desea dar a su instalación actual de Helm chart.\n\nRelease:\n- Es el nombre que asignó a una instancia de instalación.\n\nRevision:\n- Es el valor del comando Helm history.\n\nRepo-name:\n- El nombre de un repositorio.\n\nDIR:\n- Nombre del directorio/ruta.\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Gestión de Charts\n\n```bash\nhelm create <name>                      # Crea un directorio de chart junto con los archivos y directorios comunes usados en una chart.\nhelm package <chart-path>               # Empaqueta una chart en un archivo chart versionado.\nhelm lint <chart>                       # Ejecuta pruebas para examinar una chart e identificar posibles problemas.\nhelm show all <chart>                   # Inspecciona una chart y lista su contenido.\nhelm show values <chart>                # Muestra el contenido del archivo values.yaml.\nhelm pull <chart>                       # Descarga una chart.\nhelm pull <chart> --untar=true          # Si se establece en true, descomprime la chart después de descargarla.\nhelm pull <chart> --verify              # Verifica el paquete antes de usarlo.\nhelm pull <chart> --version <number>    # Por defecto se usa la última versión; especifica una restricción de versión para la chart.\nhelm dependency list <chart>            # Muestra una lista de las dependencias de una chart.\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Instalar y desinstalar aplicaciones\n\n```bash\nhelm install <name> <chart>                           # Instala la chart con un nombre.\nhelm install <name> <chart> --namespace <namespace>   # Instala la chart en un namespace específico.\nhelm install <name> <chart> --set key1=val1,key2=val2 # Establece valores en la línea de comandos (puede especificar varios o separarlos con comas).\nhelm install <name> <chart> --values <yaml-file/url>  # Instala la chart con los valores especificados.\nhelm install <name> <chart> --dry-run --debug         # Ejecuta una instalación de prueba para validar la chart (p).\nhelm install <name> <chart> --verify                  # Verifica el paquete antes de usarlo.\nhelm install <name> <chart> --dependency-update       # Actualiza dependencias si faltan antes de instalar la chart.\nhelm uninstall <name>                                 # Desinstala una release del namespace actual (por defecto).\nhelm uninstall <release-name> --namespace <namespace> # Desinstala una release del namespace especificado.\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Actualizar y revertir la aplicación (Rollback)\n\n```bash\nhelm upgrade <release> <chart>                            # Actualiza una release.\nhelm upgrade <release> <chart> --rollback-on-failure      # Si se establece, el proceso de actualización revierte los cambios en caso de fallo.\nhelm upgrade <release> <chart> --dependency-update        # Actualiza las dependencias si faltan antes de instalar la chart.\nhelm upgrade <release> <chart> --version <version_number> # Especifica una restricción de versión para la chart a usar.\nhelm upgrade <release> <chart> --values                   # Especifica valores en un archivo YAML o una URL (puede especificar múltiples).\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Establece valores en la línea de comandos (puede especificar múltiples o separados).\nhelm upgrade <release> <chart> --force                    # Fuerza la actualización de recursos mediante una estrategia de reemplazo.\nhelm rollback <release> <revision>                        # Revierte una release a una revisión específica.\nhelm rollback <release> <revision>  --cleanup-on-fail     # Permite eliminar nuevos recursos creados en este rollback si el rollback falla.\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Listar, añadir, eliminar y actualizar repositorios\n\n```bash\nhelm repo add <repo-name> <url>   # Añade un repositorio desde internet.\nhelm repo list                    # Lista los repositorios de charts añadidos.\nhelm repo update                  # Actualiza la información local de charts disponibles desde los repositorios.\nhelm repo remove <repo_name>      # Elimina uno o más repositorios de charts.\nhelm repo index <DIR>             # Lee el directorio actual y genera un archivo de índice basado en las charts encontradas.\nhelm repo index <DIR> --merge     # Fusiona el índice generado con un archivo de índice existente.\nhelm search repo <keyword>        # Busca una palabra clave en los charts de los repositorios.\nhelm search hub <keyword>         # Busca charts en Artifact Hub o en su propia instancia de hub.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Monitorización de Helm Release\n\n```bash\nhelm list                       # Lista todas las releases del namespace especificado; usa el namespace actual si no se especifica.\nhelm list --all                 # Muestra todas las releases sin aplicar ningún filtro, puede usar -a.\nhelm list --all-namespaces      # Lista releases en todos los namespaces, puede usar -A.\nhelm list -l key1=value1,key2=value2 # Selector (label query) para filtrar, soporta '=', '==', y '!='.\nhelm list --date                # Ordena por fecha de release.\nhelm list --deployed            # Muestra las releases desplegadas. Si no se especifica otra opción, se activa automáticamente.\nhelm list --pending             # Muestra las releases pendientes.\nhelm list --failed              # Muestra las releases fallidas.\nhelm list --uninstalled         # Muestra las releases desinstaladas (si se usó 'helm uninstall --keep-history').\nhelm list --superseded          # Muestra las releases sustituidas.\nhelm list -o yaml               # Imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table).\nhelm status <release>           # Muestra el estado de una release con nombre.\nhelm status <release> --revision <number>   # Si se establece, muestra el estado de la release nombrada con la revisión.\nhelm history <release>          # Historial de revisiones para una release dada.\nhelm env                        # Imprime toda la información de entorno usada por Helm.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Descargar información de Release\n\n```bash\nhelm get all <release>      # Una colección legible de información sobre las notas, hooks, valores suministrados y archivo de manifiesto generado de la release dada.\nhelm get hooks <release>    # Descarga los hooks para una release dada. Los hooks están formateados en YAML y separados por el separador YAML '---\\n'.\nhelm get manifest <release> # 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.\nhelm get notes <release>    # Muestra las notas proporcionadas por la chart de una release con nombre.\nhelm get values <release>   # Descarga un archivo de valores para una release dada. Use -o para formatear la salida.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Gestión de plugins\n\n```bash\nhelm plugin install <path/url>      # Instala plugins.\nhelm plugin list                    # Muestra una lista de todos los plugins instalados.\nhelm plugin update <plugin>         # Actualiza plugins.\nhelm plugin uninstall <plugin>      # Desinstala un plugin.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/intro/index.mdx",
    "content": "---\ntitle: \"Introducción\"\nsidebar_position: 1\n---\n\n# Introducción a Helm\n\n¿Eres nuevo en Helm? ¡Este es el lugar para comenzar!\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: Instalar Helm\ndescription: Aprenda a instalar y poner Helm en funcionamiento.\nsidebar_position: 2\n---\n\nEsta guía muestra cómo instalar Helm CLI. Helm se puede instalar desde la fuente\no desde versiones binarias preconstruidas.\n\n## Desde el Proyecto Helm\n\nEl proyecto Helm proporciona dos formas de obtener e instalar Helm. Estos son los\nmétodos oficiales para obtener lanzamientos de Helm. Además de eso, la comunidad\nde Helm proporciona métodos para instalar Helm a través de diferentes administradores\nde paquetes. La instalación a través de esos métodos se puede encontrar debajo\nde los métodos oficiales.\n\n### De los Lanzamientos Binarios\n\nCada [lanzamiento](https://github.com/helm/helm/releases) de Helm proporciona\nbinarios de lanzamiento para una variedad de sistemas operativos. Estas versiones\nbinarias se pueden descargar e instalar manualmente.\n\n1. Descarga tu [versión deseada](https://github.com/helm/helm/releases)\n2. Desempaquétala (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)\n3. Encuentra el binario `helm` en el directorio desempaquetado, y muévelo a su\ndestino deseado (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nDe ahí, debe poder ejecutar el cliente y\n[agregar el repositorio de charts estable](/intro/quickstart.md#initialize-a-helm-chart-repository):\n`helm help`.\n\n**Nota:** Las pruebas automatizadas de Helm se realizan para Linux AMD64 solo durante\nlas compilaciones y lanzamientos de GitHub Actions. Las pruebas de otros sistemas operativos\nson responsabilidad de la comunidad que solicita Helm para el sistema operativo\nen cuestión.\n\n### Desde Script\n\nHelm ahora tiene un script de instalación que automáticamente tomará la última versión\nde Helm y [la instalará localmente](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3).\n\nPuede recuperar ese script y luego ejecutarlo localmente. Está bien documentado para\nque puedas leerlo y comprender lo que está haciendo antes de ejecutarlo.\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\nSí, puedes `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`si\nquieres vivir al límite.\n\n## A Través de Administradores de Paquetes\n\nLa comunidad de Helm ofrece la posibilidad de instalar Helm a través de administradores\nde paquetes del sistema operativo. Estos no son soportados por el proyecto Helm y\nno se consideran terceros de confianza.\n\n### Desde Homebrew (macOS)\n\nLos miembros de la comunidad de Helm han contribuido con una fórmula de Helm a Homebrew.\nEsta fórmula generalmente está actualizada.\n\n```console\nbrew install helm\n```\n\n(Nota: también hay una fórmula para emacs-helm, que es un proyecto diferente).\n\n### Desde Chocolatey (Windows)\n\nLos miembros de la comunidad Helm han contribuido con un\n[paquete Helm](https://chocolatey.org/packages/kubernetes-helm) construido para\n[Chocolatey](https://chocolatey.org/). Este paquete generalmente está actualizado.\n\n```console\nchoco install kubernetes-helm\n```\n\n### Desde Scoop (Windows)\n\nLos miembros de la comunidad Helm han contribuido con un\n[paquete Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) construido para [Scoop](https://scoop.sh). Este paquete generalmente está actualizado.\n\n```console\nscoop install helm\n```\n\n### Desde Winget (Windows)\n\nLos miembros de la comunidad Helm han contribuido con un\n[paquete Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) construido para\n[Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Este paquete generalmente está actualizado.\n\n```console\nwinget install Helm.Helm\n```\n\n### Desde Apt (Debian/Ubuntu)\n\nLos miembros de la comunidad Helm han contribuido con un paquete Apt para Debian/Ubuntu.\nEste paquete generalmente está actualizado. Gracias a [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) por alojar el repositorio.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### Desde dnf/yum (fedora)\n\nDesde Fedora 35, Helm está disponible en el repositorio oficial.\nPuede instalar Helm ejecutando:\n\n```console\nsudo dnf install helm\n```\n\n### Desde Snap\n\nLa comunidad [Snapcrafters](https://github.com/snapcrafters) mantiene la\nversión Snap del [paquete Helm](https://snapcraft.io/helm):\n\n```console\nsudo snap install helm --classic\n```\n\n### Desde pkg (FreeBSD)\n\nLos miembros de la comunidad FreeBSD han contribuido con una compilación de\n[paquete Helm](https://www.freshports.org/sysutils/helm) a la\n[Colección de Ports de FreeBSD](https://man.freebsd.org/ports).\nEste paquete generalmente está actualizado.\n\n```console\npkg install helm\n```\n\n### Builds de Desarrollo\n\nAdemás de los lanzamientos, puede descargar o instalar versiones de desarrollo de\nHelm.\n\n### Desde Canary Builds\n\nLos \"Canary\" builds son versiones del software Helm que se crean a partir de lo último\nde la rama main. No son lanzamientos oficiales y pueden no ser estables. Sin embargo,\nofrecen la oportunidad de probar las funciones de vanguardia.\n\nLos binarios Canary builds se guardan en [get.helm.sh](https://get.helm.sh). Aquí\nhay enlaces a las compilaciones comunes:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Windows Experimental AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### Desde los Fuentes (Linux, macOS)\n\nConstruir Helm desde los fuentes es un poco más complicado, pero es la mejor\nmanera de hacerlo si desea probar la última versión (prelanzamiento) de Helm.\n\nDebe tener un entorno de trabajo de Go.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\nSi es necesario, buscará las dependencias, las almacenará en caché y validará\nla configuración. Luego compilará `helm` y lo colocará en `bin/helm`.\n\n## Conclusión\n\nEn la mayoría de los casos, la instalación es tan simple como obtener un binario\n`helm` preconstruido. Este documento cubre casos adicionales para aquellos que\ndesean hacer cosas más sofisticadas con Helm.\n\nUna vez que tenga el cliente de Helm instalado correctamente, puede continuar con\nel uso de Helm para administrar charts y [agregar el repositorio de charts\nestable](/intro/quickstart.md#initialize-a-helm-chart-repository).\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: Guía de inicio rápido\ndescription: Cómo instalar y comenzar con Helm, incluidas instrucciones para distribuciones, preguntas frecuentes y plugins.\nsidebar_position: 1\n---\n\nEsta guía explica cómo empezar a utilizar Helm rápidamente.\n\n## Prerrequisitos\n\nPara usar Helm de forma exitosa y segura, necesita lo siguiente:\n\n1. Un clúster de Kubernetes\n2. Decidir qué configuraciones de seguridad aplicar a su instalación, si corresponde\n3. Instalar y configurar Helm.\n\n### Instalar Kubernetes o tener acceso a un clúster\n\n- Debe tener Kubernetes instalado. Para la última versión de Helm, recomendamos\n  la última versión estable de Kubernetes, que en la mayoría de los casos es la\n  segunda versión menor más reciente.\n- También debe tener una copia de `kubectl` configurada localmente.\n\nConsulte la [Política de Soporte de Versiones de Helm](https://helm.sh/docs/topics/version_skew/)\npara conocer la máxima diferencia de versiones soportada entre Helm y Kubernetes.\n\n## Instalar Helm\n\nDescargue una versión binaria del cliente Helm. Puede usar herramientas como\n`homebrew`, o consultar [la página de releases oficiales](https://github.com/helm/helm/releases).\n\nPara más detalles u otras opciones, consulte [la guía de instalación](/intro/install.md).\n\n## Inicializar un Repositorio de Charts de Helm {#initialize-a-helm-chart-repository}\n\nUna vez que tenga Helm listo, puede agregar un repositorio de charts. Consulte\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) para ver los\nrepositorios de charts de Helm disponibles.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nUna vez instalado, podrá listar los charts disponibles para instalar:\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... y muchos más\n```\n\n## Instalar un Chart de Ejemplo\n\nPara instalar un chart, puede ejecutar el comando `helm install`. Helm tiene\nvarias formas de buscar e instalar un chart, pero la más fácil es utilizar los\ncharts de `bitnami`.\n\n```console\n$ helm repo update              # Asegúrese de obtener la última lista de charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nEn el ejemplo anterior, se desplegó el chart `bitnami/mysql` y el nombre de\nnuestro nuevo release es `mysql-1612624192`.\n\nPuede ver las características básicas de este chart de MySQL ejecutando\n`helm show chart bitnami/mysql`. O puede ejecutar `helm show all bitnami/mysql`\npara obtener toda la información sobre el chart.\n\nSiempre que instale un chart, se crea un nuevo release. Por lo tanto, un chart\nse puede instalar varias veces en el mismo clúster. Y cada uno se puede\nadministrar y actualizar de forma independiente.\n\nEl comando `helm install` es muy potente y tiene muchas capacidades. Para más\ninformación, consulte la [Guía de Uso de Helm](/intro/using_helm.md).\n\n## Más Información sobre Releases\n\nCon Helm puede ver fácilmente lo que se ha desplegado:\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nEl comando `helm list` (o `helm ls`) le mostrará una lista de todos los releases desplegados.\n\n## Desinstalar un Release\n\nPara desinstalar un release, utilice el comando `helm uninstall`:\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nEsto desinstalará `mysql-1612624192` de Kubernetes, eliminando todos los\nrecursos asociados con el release, así como el historial del release.\n\nSi proporciona la bandera `--keep-history`, se conservará el historial del\nrelease. Podrá solicitar información sobre ese release:\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nDado que Helm realiza un seguimiento de sus releases incluso después de\nhaberlos desinstalado, puede auditar el historial de un clúster e incluso\nrecuperar un release (con `helm rollback`).\n\n## Leer el Texto de Ayuda\n\nPara más información sobre los comandos disponibles de Helm, utilice\n`helm help` o escriba un comando seguido de la bandera `-h`:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: Uso de Helm\ndescription: Explica los conceptos básicos de Helm.\nsidebar_position: 3\n---\n\nEsta guía explica los conceptos básicos del uso de Helm para administrar paquetes\nen su clúster de Kubernetes. Asume que ya has [instalado](/intro/install.md) el cliente de Helm.\n\nSi simplemente está interesado en ejecutar algunos comandos rápidos, es posible\nque desee comenzar con la [Guía de inicio rápido](/intro/quickstart.md).\nEste capítulo cubre los detalles de los comandos de Helm y explica cómo usar Helm.\n\n## Tres Grandes Conceptos\n\nUn *Chart* es un paquete de Helm. Contiene todas las definiciones de recursos\nnecesarias para ejecutar una aplicación, herramienta o servicio dentro de un\nclúster de Kubernetes. Piense en él como el equivalente de Kubernetes de una\nfórmula Homebrew, un Apt de dpkg o un archivo Yum de RPM.\n\nUn *Repositorio* es el lugar donde se pueden recopilar y compartir Charts.\nEs como el [archivo CPAN](https://www.cpan.org) de Perl o la [Base de Datos de\nPaquetes de Fedora](https://src.fedoraproject.org/), pero para los paquetes\nde Kubernetes.\n\nUn *Release* es una instancia de un Chart que se ejecuta en un clúster de\nKubernetes. A menudo, un Chart se puede instalar muchas veces en el mismo clúster.\nY cada vez que se instala, se crea un nuevo _release_. Considere un Chart MySQL.\nSi desea que se ejecuten dos bases de datos en su clúster, puede instalar ese\nChart dos veces. Cada uno tendrá su propio _release_, que a su vez tendrá su propio\n_nombre de release_.\n\nCon estos conceptos en mente, ahora podemos explicar Helm así:\n\nHelm instala _charts_ en Kubernetes, creando nuevos _release_ para cada\ninstalacion. Y para encontrar nuevos charts, puedes buscar en los _repositorios_ \nde charts de Helm.\n\n## 'helm search': Buscando Charts\n\nHelm viene con un poderoso comando de búsqueda. Se puede utilizar para buscar\ndos tipos diferentes de fuentes:\n\n- `helm search hub` buscar en [Artifact Hub](https://artifacthub.io), que\n  enumera charts de Helm de docenas de repositorios diferentes.\n- `helm search repo` busca en los repositorios que ha agregado a su cliente\n  de helm local (con `helm repo add`). Esta búsqueda se realiza a través de\n  datos locales y no se necesita una conexión de red pública.\n\nPuede encontrar charts disponibles públicamente ejecutando `helm search hub`:\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\nLo anterior busca todos los charts de `wordpress` en Artifact Hub.\n\nSin filtro, `helm search hub` muestra todos los charts disponibles.\n\n`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]`.\n\nUsando `helm search repo`, puede encontrar los nombres de los charts en los\nrepositorios que ya has agregado:\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nHelm search utiliza un algoritmo de coincidencia de cadenas difusas, por lo\nque puede escribir partes de palabras o frases:\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nEl comando search es una buena forma de encontrar paquetes disponibles. Una vez que\nhaya encontrado el paquete que desea instalar, puede usar `helm install` para instalarlo.\n\n## 'helm install': Instalando un Package\n\nPara instalar un nuevo paquete, use el comando `helm install`. En su forma más simple,\nse necesitan dos argumentos: un nombre de release que elijas y el nombre del chart\nque deseas instalar.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nAhora el chart `wordpress` está instalado. Tenga en cuenta que la instalación de\nun chart crea un nuevo objeto _release_. El release anterior se llama `happy-panda`.\n(Si desea que Helm genere un nombre por usted, omita el nombre del release y\nuse `--generate-name`).\n\nDurante la instalación, el cliente `helm` imprimirá información útil sobre qué\nrecursos se crearon, cuál es el estado del release y también si hay pasos de\nconfiguración adicionales que puede o debe tomar.\n\nHelm instala los recursos en el siguiente orden:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nHelm no espera hasta que todos los recursos se estén ejecutando antes de salir.\nMuchos charts requieren imágenes de Docker que tienen un tamaño superior a 600M\ny pueden tardar mucho en instalarse en el clúster.\n\nPara realizar un seguimiento del estado de un release o para volver a leer la\ninformación de configuración, puede utilizar `helm status`:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nLo anterior muestra el estado actual de su release.\n\n### Personalización del Charts antes de la instalación\n\nLa instalación de la forma que tenemos aquí solo usará las opciones de\nconfiguración predeterminadas para este chart. Muchas veces, querrás\npersonalizar el chart para usar tu configuración preferida.\n\nPara ver qué opciones se pueden configurar en un chart, use `helm show values`:\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nLuego, puedes sobreescribir cualquiera de estas configuraciones en un archivo\ncon formato YAML y luego pasar ese archivo durante la instalación.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nLo anterior creará un usuario MariaDB predeterminado con el nombre `user0`,\ny otorgará a este usuario acceso a una base de datos `user0db` recién creada,\npero aceptará el resto de los valores predeterminados para ese chart.\n\nHay dos formas de pasar los datos de configuración durante la instalación:\n\n- `--values` (o `-f`): Especifique un archivo YAML con sobreescrituras. Esto se\n  puede especificar varias veces y el archivo más a la derecha tendrá prioridad\n- `--set`: Especifique sobreescrituras en la línea de comando.\n\nSi se utilizan ambos, los valores pasados en `--set` se fusionan con los pasados\nen `--values` con mayor precedencia. Las sobreescrituras especificadas con `--set`\nse guardan en un Secret. Los valores que han sido pasados con `--set` se pueden\nver para un release determinado con `helm get values <release-name>`. Los valores\nque han sido pasados con `--set` se pueden borrar ejecutando `helm upgrade`\nespecificando `--reset-values`.\n\n#### El Formato y Limitaciones de `--set`\n\nLa opción `--set` toma cero o más pares de nombre/valor. En su forma más simple,\nse usa así: `--set name=value`. El equivalente YAML de eso es:\n\n```yaml\nname: value\n```\n\nMúltiples valores son separados por el caracteres `,`. Entonces, `--set a=b,c=d`\nse convierte en:\n\n```yaml\na: b\nc: d\n```\n\nExpresiones más complejas son soportadas. Por ejemplo, `--set outer.inner=value`\nes traducida a esto:\n\n```yaml\nouter:\n  inner: value\n```\n\nLas listas se pueden expresar encerrando valores en `{` y `}`. Por ejemplo,\n`--set name={a, b, c}` se traduce a:\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nCiertos nombres/claves se pueden establecer como `null` o como un array vacío `[]`.\nPor ejemplo, `--set name=[],a=null` traduce\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\na\n\n```yaml\nname: []\na: null\n```\n\nA partir de Helm 2.5.0, es posible acceder a los elementos de la lista utilizando\nuna sintaxis de índice de arreglo. Por ejemplo, `--set servers[0].port=80` se\nconvierte en:\n\n```yaml\nservers:\n  - port: 80\n```\n\nDe esta forma se pueden configurar varios valores. La línea `--set\nservers[0].port=80,servers[0].host=example` se vuelve:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nA veces es necesario utilizar caracteres especiales en sus líneas `--set`. Puede\nusar una barra invertida para escapar de los caracteres; `--set name=value1\\,value2`\nse convertirá en:\n\n```yaml\nname: \"value1,value2\"\n```\n\nDe manera similar, también puede escapar de las secuencias de puntos, lo que\npuede resultar útil cuando los charts usan la función `toYaml` para analizar\nanotaciones, etiquetas y selectores de nodos. La sintaxis para\n`--set nodeSelector.\"kubernetes\\.io/role\"=master` se convertirá en:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nLas estructuras de datos profundamente anidadas pueden ser difíciles de expresar\nusando `--set`. Se alienta a los diseñadores de charts a considerar el uso de\n`--set` al diseñar el formato de un archivo `values.yaml`\n(lea más sobre [Archivos Values](/chart_template_guide/values_files.md)).\n\n### Más Métodos de Instalación\n\nEl comando `helm install` puede instalar desde varias fuentes:\n\n- Un repositorio de charts (como hemos visto anteriormente)\n- Un archivo de chart local (`helm install foo foo-0.1.1.tgz`)\n- Un directorio de chart descomprimido (`helm install foo path/to/foo`)\n- Una URL completa (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' y 'helm rollback': Actualizar un Release y Revertir un Fallo\n\nCuando se lanza una nueva versión de un chart, o cuando desea cambiar la configuración\nde su release, puede usar el comando `helm upgrade`.\n\nUna actualización toma un release existente y lo actualiza de acuerdo con la\ninformación que proporcione. Dado que los charts de Kubernetes pueden ser grandes\ny complejos, Helm intenta realizar la actualización menos invasiva. Solo actualizará\nlas cosas que hayan cambiado desde el último release.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nEn el caso anterior, la versión `happy-panda` se actualiza con el mismo chart,\npero con un nuevo archivo YAML:\n\n```yaml\nmariadb.auth.username: user1\n```\n\nPodemos usar `helm get values` para ver si esa nueva configuración entró en vigencia.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nEl comando `helm get` es una herramienta útil para ver un release en el clúster.\nY como podemos ver arriba, muestra que nuestros nuevos valores de `panda.yaml`\nse desplegaron en el clúster.\n\nAhora, si algo no sale según lo planeado durante un release, es fácil retroceder\na un release anterior usando `helm rollback [RELEASE] [REVISION]`.\n\n```console\n$ helm rollback happy-panda 1\n```\n\nLo anterior hace retroceder a nuestro release happy-panda a su primera versión de\nrelease. La versión de release es una revisión incremental. Cada vez que ocurre\nuna instalación, actualización o reversión, el número de revisión se incrementa\nen 1. El primer número de revisión es siempre 1. Y podemos usar\n`helm history [RELEASE]` para ver los números de revisión de un determinado release.\n\n## Opciones Útiles para Instalar/Actualizar/Revertir\n\nHay varias otras opciones útiles que puede especificar para personalizar el\ncomportamiento de Helm durante una instalación/actualización/reversión. Tenga en\ncuenta que esta no es una lista completa de banderas del cliente. Para ver una\ndescripción de todos las banderas, simplemente ejecute `helm <comando> --help`.\n\n- `--timeout`: Un valor de [duración de Go](https://golang.org/pkg/time/#ParseDuration)\n  para esperar a que se completen los comandos de Kubernetes. El valor por\n  defecto es `5m0s`.\n- `--wait`: Espera hasta que todos los pods estén listos, los PVC están vinculados,\n  los Depolyments tengan el mínimo (`Desired` menos `maxUnavailable`) Pods en estado\n  listo y los Services tengan una dirección IP (e Ingress si es un `LoadBalancer`)\n  antes de marcar el release como exitoso. Esperará tanto tiempo como el valor\n  `--timeout`. Si se alcanza el tiempo de espera, el release se marcará como\n  `FAILED` (Fallida). Nota: En escenarios donde el Deployment tiene `replicas`\n  configuradas en 1 y `maxUnavailable` no está configurado en 0 como parte de la\n  estrategia de actualización continua, `--wait` regresará tan pronto como haya\n  satisfecho la condición de mínimo de Pods listos.\n- `--no-hooks`: Esto omite la ejecución de ganchos para el comando\n- `--recreate-pods` (sólo disponible para `upgrade` y `rollback`): Esta bandera\n  hará que se vuelvan a crear todos los Pods (con la excepción de los Pods que\n  pertenecen a Deployments). (DEPRECADO en Helm 3)\n\n## 'helm uninstall': Desinstalar un Release\n\nCuando sea el momento de desinstalar un release del clúster, use el comando\n`helm uninstall`:\n\n```console\n$ helm uninstall happy-panda\n```\n\nEsto eliminará el release del clúster. Puedes ver todas tus releases implementados\nactualmente con el comando `helm list`:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nEn el resultado anterior, podemos ver que se desinstaló el release `happy-panda`.\n\nEn versiones anteriores de Helm, cuando se eliminaba un release, quedaba un registro\nde su eliminación. En Helm 3, la eliminación también elimina el registro del release.\nSi desea mantener un registro de eliminación del release, use\n`helm uninstall --keep-history`. El uso de `helm list --uninstalled` solo mostrará\nlos releases que se desinstalaron con la bandera `--keep-history`.\n\nLa bandera `helm list --all` le mostrará todos los registros de releases que Helm\nha retenido, incluidos los registros de elementos fallidos o eliminados (si se\nespecificó `--keep-history`):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nTenga en cuenta que debido a que los releases ahora se eliminan de forma\npredeterminada, ya no es posible revertir un recurso desinstalado.\n\n## 'helm repo': Trabajar con Repositorios\n\nHelm 3 ya no viene con un repositorio de charts predeterminado. El grupo de\ncomandos `helm repo` proporciona comandos para agregar, enumerar y eliminar repositorios.\n\nPuede ver qué repositorios están configurados usando `helm repo list`:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nY se pueden agregar nuevos repositorios con `helm repo add`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nDebido a que los repositorios de charts cambian con frecuencia, en cualquier\nmomento puede asegurarse de que su cliente Helm esté actualizado ejecutando\n`helm repo update`.\n\nLos repositorios se pueden eliminar con `helm repo remove`.\n\n## Creación de sus Propios Charts\n\nLa [Guía de Desarrollo de Chart](/topics/charts.md)\nexplica cómo desarrollar sus propios charts. Pero puede comenzar rápidamente usando\nel comando `helm create`:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nAhora hay un chart en `./deis-workflow`. Puede editarlo y crear sus propias plantillas.\n\nA medida que editas tu chart, puede validar que está bien formado ejecutando\n`helm lint`.\n\nCuando llegue el momento de empaquetar el chart para su distribución, puedes\nejecutar el comando `helm package`:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nY este chart ahora se puede instalar fácilmente con `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nLos Charts empaquetados se pueden cargar en repositorios de charts. Consulte la\ndocumentación de los [Repositorios de Charts de Helm](/topics/chart_repository.md)\npara obtener más detalles.\n\n## Conclusión\n\nEste capítulo ha cubierto los patrones de uso básicos del cliente `helm`, incluida\nla búsqueda, instalación, actualización y desinstalación. También ha cubierto comandos\nútiles de utilidad como `helm status`, `helm get` y `helm repo`.\n\nPara obtener más información sobre estos comandos, consulte la ayuda incorporada\nde Helm: `helm help`.\n\nEn el [capítulo siguiente](/howto/charts_tips_and_tricks.md),\nanalizamos el proceso de desarrollo de charts.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: Introducción\ndescription: Presenta el SDK de Go para Helm\nsidebar_position: 1\n---\nEl 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.\n¡De hecho, la CLI de Helm es efectivamente una herramienta de este tipo!\n\nActualmente, el SDK ha sido funcionalmente separado de la CLI de Helm.\nY el SDK puede ser (y es) utilizado por herramientas independientes.\nEl proyecto Helm se ha comprometido con la estabilidad de la API del SDK.\nComo 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.\n\nLa 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).\n\nA continuación se presenta una breve descripción de algunos de los principales tipos de paquetes y un ejemplo sencillo.\nConsulte la sección de [Ejemplos](/sdk/examples.mdx) para más ejemplos y un 'driver' (controlador) más completo.\n\n## Descripción general de los paquetes principales\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action):\n  Contiene el \"cliente\" principal para realizar acciones de Helm.\n  Este es el mismo paquete que la CLI utiliza internamente.\n  Si solo necesita ejecutar comandos básicos de Helm desde otro programa Go, este es el paquete indicado\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil):\n  Métodos y helpers utilizados para cargar y manipular charts\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) y sus subpaquetes:\n  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\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release):\n  Define el objeto `Release` y sus estados\n\n¡Hay muchos más paquetes además de estos, así que consulte la documentación para más información!\n\n### Ejemplo sencillo\nEste es un ejemplo sencillo de cómo hacer un `helm list` usando el SDK de Go.\nConsulte la sección de [Ejemplos](/sdk/examples.mdx) para ejemplos más completos.\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## Compatibilidad\n\nEl SDK de Helm sigue explícitamente las garantías de compatibilidad hacia atrás de Helm:\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\nEs decir, los cambios que rompen la compatibilidad solo se realizarán en versiones mayores.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: Técnicas avanzadas de Helm\ndescription: Explica varias características avanzadas para usuarios avanzados de Helm\nsidebar_position: 9\n---\n\nEsta sección explica varias características avanzadas y técnicas para usar Helm.\nLa 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).\n\n## Post Renderizado\nEl 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.\n\n### Prerrequisitos\n- Helm 3.1+\n\n### Uso\nUn 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.\n\nUn 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:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nSi la ruta no contiene ningún separador, buscará en $PATH, de lo contrario resolverá cualquier ruta relativa a una ruta absoluta.\n\nSi 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`.\n\nPuede ver un ejemplo de uso de `kustomize` como post renderer [aquí](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n### Advertencias\nCuando 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.\n\nOtra 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.\n\n### Post-renderizadores personalizados\nEl 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:\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nPara más información sobre el uso del Go SDK, consulte la siguiente [sección Go SDK](#go-sdk).\n\n## Go SDK\nHelm 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.\n\n### Resumen de paquetes\nEsta es una lista de los paquetes más utilizados con una explicación sencilla sobre cada uno de ellos:\n\n- `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.\n- `pkg/{chart,chartutil}`:  Métodos y ayudantes usados para cargar y manipular charts.\n- `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.\n- `pkg/release`: Define el objeto `Release` y sus estados.\n\nObviamente hay muchos más paquetes además de estos, ¡así que revise la documentación para más información!\n\n### Ejemplo simple\nEste es un ejemplo simple para hacer un `helm list` usando el Go SDK:\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n```\n\n## Backends de almacenamiento {#storage-backends}\nHelm 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:\n`[configmap, secret, sql]`.\n\n### Backend de almacenamiento ConfigMap\nPara habilitar el backend ConfigMap, necesitará establecer la variable de entorno `HELM_DRIVER` a `configmap`.\n\nPuede establecerla en un shell de la siguiente manera:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nSi 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:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**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\nrole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\n\"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.\n\n### Backend de almacenamiento SQL\nExiste un backend de almacenamiento SQL ***beta*** que almacena la información de liberación en una base de datos SQL.\n\nEl 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).\n\nPara 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`.\n\nPuede configurarlo en un shell de la siguiente manera:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Nota: En este momento solo se soporta PostgreSQL.\n\n**NOTAS DE PRODUCCIÓN**: Se recomienda:\n- 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\n- Habilitar [gestión de permisos](/topics/permissions_sql_storage_backend.md) para reflejar Kubernetes RBAC y obtener información sobre la versión\n\nSi 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:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Arquitectura Helm\ndescription: Describe la arquitectura de Helm a alto nivel.\nsidebar_position: 8\n---\n\n# Arquitectura de Helm\n\nEste documento describe la arquitectura de Helm a alto nivel.\n\n## El propósito de Helm\n\nHelm es una herramienta para gestionar paquetes Kubernetes llamados _charts_. Helm puede hacer lo siguiente:\n\n- Crear nuevos charts desde cero\n- Empaquetar charts en archivos de charts (tgz)\n- Interactuar con repositorios de charts donde se almacenan charts\n- Instalar y desinstalar charts en un clúster Kubernetes existente\n- Gestionar el ciclo de lanzamiento de los charts instalados con Helm\n\nPara Helm, hay tres conceptos importantes:\n\n1. El _chart_ es un conjunto de información necesaria para crear una instancia de una aplicación de Kubernetes.\n2. El _config_ contiene información de configuración que puede fusionarse en un chart empaquetado para crear un objeto desplegable.\n3. Un _release_ es una instancia en ejecución de un _chart_, combinado con un _config_ específico.\n\n## Componentes\n\nHelm es un ejecutable que se implementa en dos partes distintas:\n\n**El cliente Helm** es un cliente de línea de comandos para usuarios finales. El cliente es responsable de lo siguiente:\n\n- Desarrollo de charts locales\n- Gestión de repositorios\n- Gestión de releases\n- Interfaz con la biblioteca Helm\n  - Envío de charts para su instalación\n  - Solicitud de actualización o desinstalación de releases existentes\n\n**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:\n\n- Combinar un chart y una configuración para construir un release\n- Instalar charts en Kubernetes y proporcionar el objeto release subsiguiente\n- Actualizar y desinstalar charts interactuando con Kubernetes\n\nLa biblioteca standalone de Helm encapsula la lógica de Helm para que pueda ser aprovechada por diferentes clientes.\n\n## Implementación\n\nEl cliente y la biblioteca Helm están escritos en el lenguaje de programación Go.\n\nLa 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.\n\nLos archivos de configuración se escriben, cuando es posible, en YAML.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: Guía del Repositorio de Charts\ndescription: Cómo crear y trabajar con repositorios de charts de Helm.\nsidebar_position: 6\n---\n\nEsta sección explica cómo crear y trabajar con repositorios de charts de Helm.\nEn términos generales, un repositorio de charts es un lugar donde se pueden\nalmacenar y compartir charts empaquetados.\n\nEl repositorio comunitario distribuido de charts de Helm está ubicado en\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) y acepta\nparticipación. Pero Helm también permite crear y ejecutar su propio repositorio\nde charts. Esta guía explica cómo hacerlo. Si está considerando crear un\nrepositorio de charts, puede considerar usar un\n[registro OCI](/topics/registries.md) en su lugar.\n\n## Prerrequisitos\n\n* Completar la guía de [Inicio Rápido](/intro/quickstart.md)\n* Leer el documento de [Charts](/topics/charts.md)\n\n## Crear un repositorio de charts\n\nUn _repositorio de charts_ es un servidor HTTP que aloja un archivo `index.yaml`\ny opcionalmente algunos charts empaquetados. Cuando esté listo para compartir\nsus charts, la forma preferida es subirlos a un repositorio de charts.\n\nA partir de Helm 2.2.0, se admite la autenticación SSL del lado del cliente para\nun repositorio. Otros protocolos de autenticación pueden estar disponibles como\nplugins.\n\nDebido a que un repositorio de charts puede ser cualquier servidor HTTP que\npueda servir archivos YAML y tar y pueda responder a solicitudes GET, dispone de\nmuchas opciones para alojar su propio repositorio de charts. Por ejemplo, puede\nusar un bucket de Google Cloud Storage (GCS), un bucket de Amazon S3, GitHub\nPages, o incluso crear su propio servidor web.\n\n### La estructura del repositorio de charts\n\nUn repositorio de charts consiste en charts empaquetados y un archivo especial\nllamado `index.yaml` que contiene un índice de todos los charts en el\nrepositorio. Frecuentemente, los charts que `index.yaml` describe también están\nalojados en el mismo servidor, al igual que los\n[archivos de procedencia](/topics/provenance.md).\n\nPor ejemplo, el diseño del repositorio `https://example.com/charts` podría verse\nasí:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nEn este caso, el archivo de índice contendría información sobre un chart, el\nchart Alpine, y proporcionaría la URL de descarga\n`https://example.com/charts/alpine-0.1.2.tgz` para ese chart.\n\nNo es necesario que un paquete de chart esté ubicado en el mismo servidor que el\narchivo `index.yaml`. Sin embargo, hacerlo suele ser lo más fácil.\n\n### El archivo de índice\n\nEl archivo de índice es un archivo yaml llamado `index.yaml`. Contiene algunos\nmetadatos sobre el paquete, incluyendo el contenido del archivo `Chart.yaml` de\nun chart. Un repositorio de charts válido debe tener un archivo de índice. El\narchivo de índice contiene información sobre cada chart en el repositorio de\ncharts. El comando `helm repo index` generará un archivo de índice basándose en\nun directorio local dado que contiene charts empaquetados.\n\nEste es un ejemplo de un archivo de índice:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Alojamiento de Repositorios de Charts\n\nEsta parte muestra varias formas de servir un repositorio de charts.\n\n### Google Cloud Storage\n\nEl primer paso es **crear su bucket de GCS**. Llamaremos al nuestro\n`fantastic-charts`.\n\n![Crear un Bucket de GCS](/img/helm2/create-a-bucket.png)\n\nA continuación, haga público su bucket **editando los permisos del bucket**.\n\n![Editar Permisos](/img/helm2/edit-permissions.png)\n\nInserte esta línea para **hacer público su bucket**:\n\n![Hacer Público el Bucket](/img/helm2/make-bucket-public.png)\n\n¡Felicitaciones, ahora tiene un bucket de GCS vacío listo para servir charts!\n\nPuede subir su repositorio de charts usando la herramienta de línea de comandos\nde Google Cloud Storage, o usando la interfaz web de GCS. Un bucket público de\nGCS puede ser accedido vía HTTPS simple en esta dirección:\n`https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith\n\nTambién puede configurar repositorios de charts usando Cloudsmith. Lea más sobre\nrepositorios de charts con Cloudsmith\n[aquí](https://help.cloudsmith.io/docs/helm-chart-repository)\n\n### JFrog Artifactory\n\nDe manera similar, también puede configurar repositorios de charts usando JFrog\nArtifactory. Lea más sobre repositorios de charts con JFrog Artifactory\n[aquí](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)\n\n### Ejemplo de GitHub Pages\n\nDe manera similar, puede crear un repositorio de charts usando GitHub Pages.\n\nGitHub le permite servir páginas web estáticas de dos formas diferentes:\n\n- Configurando un proyecto para servir el contenido de su directorio `docs/`\n- Configurando un proyecto para servir una rama específica\n\nTomaremos el segundo enfoque, aunque el primero es igual de fácil.\n\nEl primer paso será **crear su rama gh-pages**. Puede hacerlo localmente así:\n\n```console\n$ git checkout -b gh-pages\n```\n\nO vía navegador web usando el botón **Branch** en su repositorio de GitHub:\n\n![Crear rama de GitHub Pages](/img/helm2/create-a-gh-page-button.png)\n\nA continuación, querrá asegurarse de que su **rama gh-pages** esté configurada\ncomo GitHub Pages, haga clic en **Settings** de su repositorio y desplácese\nhacia abajo a la sección **GitHub pages** y configure como se muestra a\ncontinuación:\n\n![Crear rama de GitHub Pages](/img/helm2/set-a-gh-page.png)\n\nPor defecto, **Source** generalmente se configura a **gh-pages branch**. Si esto\nno está configurado por defecto, selecciónelo.\n\nPuede usar un **dominio personalizado** si lo desea.\n\nY verifique que **Enforce HTTPS** esté marcado, para que se use **HTTPS** cuando\nse sirvan los charts.\n\nCon esta configuración puede usar su rama principal para almacenar el código de\nsus charts, y la **rama gh-pages** como repositorio de charts, por ejemplo:\n`https://USERNAME.github.io/REPONAME`. El repositorio de demostración [TS\nCharts](https://github.com/technosophos/tscharts) está accesible en\n`https://technosophos.github.io/tscharts/`.\n\nSi ha decidido usar GitHub Pages para alojar el repositorio de charts, consulte\n[Chart Releaser Action](/howto/chart_releaser_action.md). Chart Releaser\nAction es un flujo de trabajo de GitHub Action para convertir un proyecto de\nGitHub en un repositorio de charts de Helm autoalojado, usando la herramienta\nCLI [helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n### Servidores web ordinarios\n\nPara configurar un servidor web ordinario para servir charts de Helm, simplemente\nnecesita hacer lo siguiente:\n\n- Poner su índice y charts en un directorio que el servidor pueda servir\n- Asegurarse de que el archivo `index.yaml` sea accesible sin requisitos de\n  autenticación\n- Asegurarse de que los archivos `yaml` se sirvan con el tipo de contenido\n  correcto (`text/yaml` o `text/x-yaml`)\n\nPor ejemplo, si desea servir sus charts desde `$WEBROOT/charts`, asegúrese de\nque haya un directorio `charts/` en su raíz web, y coloque el archivo de índice\ny los charts dentro de esa carpeta.\n\n### Servidor de Repositorio ChartMuseum\n\nChartMuseum es un servidor de repositorio de charts de Helm de código abierto\nescrito en Go (Golang), con soporte para backends de almacenamiento en la nube,\nincluyendo [Google Cloud Storage](https://cloud.google.com/storage/),\n[Amazon S3](https://aws.amazon.com/s3/),\n[Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/),\n[Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss),\n[Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/),\n[Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage),\n[Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html),\n[Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos),\n[DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/),\n[Minio](https://min.io/), y [etcd](https://etcd.io/).\n\nTambién puede usar el servidor\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\npara alojar un repositorio de charts desde un sistema de archivos local.\n\n### Registro de Paquetes de GitLab\n\nCon GitLab puede publicar charts de Helm en el Registro de Paquetes de su\nproyecto. Lea más sobre cómo configurar un repositorio de paquetes helm con\nGitLab [aquí](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Gestión de Repositorios de Charts\n\nAhora que tiene un repositorio de charts, la última parte de esta guía explica\ncómo mantener charts en ese repositorio.\n\n### Almacenar charts en su repositorio de charts\n\nAhora que tiene un repositorio de charts, subamos un chart y un archivo de\níndice al repositorio. Los charts en un repositorio de charts deben estar\nempaquetados (`helm package chart-name/`) y versionados correctamente (siguiendo\nlas directrices de [SemVer 2](https://semver.org/)).\n\nEstos siguientes pasos componen un flujo de trabajo de ejemplo, pero puede usar\ncualquier flujo de trabajo que prefiera para almacenar y actualizar charts en su\nrepositorio de charts.\n\nUna vez que tenga un chart empaquetado listo, cree un nuevo directorio y mueva\nsu chart empaquetado a ese directorio.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nEl último comando toma la ruta del directorio local que acaba de crear y la URL\nde su repositorio de charts remoto y compone un archivo `index.yaml` dentro de\nla ruta del directorio dado.\n\nAhora puede subir el chart y el archivo de índice a su repositorio de charts\nusando una herramienta de sincronización o manualmente. Si está usando Google\nCloud Storage, consulte este\n[flujo de trabajo de ejemplo](/howto/chart_repository_sync_example.md) usando\nel cliente gsutil. Para GitHub, simplemente puede poner los charts en la rama de\ndestino apropiada.\n\n### Agregar nuevos charts a un repositorio existente\n\nCada vez que desee agregar un nuevo chart a su repositorio, debe regenerar el\níndice. El comando `helm repo index` reconstruirá completamente el archivo\n`index.yaml` desde cero, incluyendo solo los charts que encuentre localmente.\n\nSin embargo, puede usar la bandera `--merge` para agregar incrementalmente\nnuevos charts a un archivo `index.yaml` existente (una gran opción cuando\ntrabaja con un repositorio remoto como GCS). Ejecute `helm repo index --help`\npara obtener más información.\n\nAsegúrese de subir tanto el archivo `index.yaml` revisado como el chart. Y si\ngeneró un archivo de procedencia, súbalo también.\n\n### Compartir sus charts con otros\n\nCuando esté listo para compartir sus charts, simplemente comparta la URL de su\nrepositorio.\n\nDesde allí, agregarán el repositorio a su cliente helm mediante el comando\n`helm repo add [NAME] [URL]` con cualquier nombre que deseen usar para\nreferenciar el repositorio.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nSi los charts están respaldados por autenticación básica HTTP, también puede\nproporcionar el nombre de usuario y la contraseña aquí:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Nota:** No se agregará un repositorio si no contiene un `index.yaml` válido.\n\n**Nota:** Si su repositorio de helm utiliza, por ejemplo, un certificado\nautofirmado, puede usar\n`helm repo add --insecure-skip-tls-verify ...` para omitir la verificación de CA.\n\nDespués de eso, sus usuarios podrán buscar en sus charts. Después de que haya\nactualizado el repositorio, pueden usar el comando `helm repo update` para\nobtener la información más reciente de los charts.\n\n*Bajo el capó, los comandos `helm repo add` y `helm repo update` obtienen el\narchivo index.yaml y lo almacenan en el directorio\n`$XDG_CACHE_HOME/helm/repository/cache/`. Aquí es donde la función `helm search`\nencuentra información sobre los charts.*\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: Pruebas de Chart\ndescription: Describe cómo ejecutar y probar sus charts.\nsidebar_position: 3\n---\n\nUn chart contiene varios recursos y componentes de Kubernetes que funcionan\njuntos. Como autor de charts, es posible que desee escribir algunas pruebas\nque validen que su chart funciona como se esperaba cuando se instala. Estas\npruebas también ayudan al consumidor de charts a comprender lo que se supone\nque debe hacer su chart.\n\nUna **prueba** en un chart de Helm vive en el directorio `templates/` y es una\ndefinición de Job que especifica un contenedor con un comando dado para ejecutar.\nEl contenedor debe salir correctamente (exit 0) para que una prueba se considere\nexitosa. La definición del Job debe contener la anotación del hook de\nprueba de Helm: `helm.sh/hook: test`.\n\nTenga en cuenta que hasta Helm v3, la definición de trabajo debía contener una\nde estas anotaciones de hook de prueba de Helm: `helm.sh/hook: test-success` o\n`helm.sh/hook: test-failure`. `helm.sh/hook: test-success` todavía se acepta como\nuna alternativa compatible con versiones anteriores de `helm.sh/hook: test`.\n\nEjemplos de pruebas:\n\n- Validar que su configuración del archivo values.yaml se haya inyectado correctamente.\n  - Asegurarse de que su nombre de usuario y contraseña funcionen correctamente\n  - Asegurarse de que un nombre de usuario y una contraseña incorrectos no funcionen\n- Verificar que sus servicios están activos y con el balanceo de carga correcto\n- etc.\n\nPuede ejecutar las pruebas predefinidas en Helm sobre un release usando el comando\n`helm test <RELEASE_NAME>`. Para un consumidor de charts, esta es una excelente\nmanera de verificar que su release de un chart (o aplicación) funcione como se esperaba.\n\n## Ejemplo de Prueba\n\nEl 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.\n\n```console\n$ helm create demo\n```\n\nAhora podrá ver la siguiente estructura en su chart de demostración.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nEn `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:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Pasos para Ejecutar un Conjunto de Pruebas sobre un Release\n\nPrimero, instale el chart en su clúster para crear un release. Puede que tenga\nque esperar a que todos los pods se activen; si prueba inmediatamente después de\nesta instalación, es probable que muestre una falla transitoria y querrá volver\na probar.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Notas\n\n- Puede definir tantas pruebas como desee en un solo archivo yaml o distribuirlas\n  en varios archivos yaml en el directorio `templates/`.\n- Le invitamos a anidar su suite de pruebas en un directorio `tests/` como\n  `<chart-name>/templates/tests/` para mayor aislamiento.\n- Una prueba es un [hook de Helm](/topics/charts_hooks.md), por lo que anotaciones\n  como `helm.sh/hook-weight` y `helm.sh/hook-delete-policy` pueden usarse con\n  recursos de prueba.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: \"Charts\"\ndescription: \"Explica el formato del chart y proporciona una guía básica para crear charts con Helm.\"\nsidebar_position: 1\n---\n\nHelm usa un formato de empaquetado llamado _charts_. Un chart es una colección\nde archivos que describen un conjunto relacionado de recursos de Kubernetes. Se\npuede usar un solo chart para implementar algo simple, como un pod de Memcached,\no algo complejo, como una pila de aplicaciones web completa con servidores HTTP,\nbases de datos, cachés, etc.\n\nLos charts se crean como archivos dispuestos en un árbol de directorios en\nparticular. Se pueden empaquetar en archivos versionados para ser desplegados.\n\nSi desea descargar y ver los archivos de un chart publicado, sin instalarlo,\npuede hacerlo con `helm pull chartrepo/chartname`.\n\nEste documento explica el formato del chart y proporciona una guía básica para\ncrear charts con Helm.\n\n## La Estructura de Archivos del Chart\n\nUn chart se organiza como una colección de archivos dentro de un directorio. El\nnombre del directorio es el nombre del chart (sin información de versiones). Por\nlo tanto, un chart que describa WordPress se almacenaría en un directorio `wordpress/`.\n\nDentro de este directorio, Helm esperará una estructura que coincida con esto:\n\n```text\nwordpress/\n  Chart.yaml          # Un archivo YAML que contiene información sobre el chart.\n  LICENSE             # OPCIONAL: Un archivo de texto sin formato que contiene la licencia del chart.\n  README.md           # OPCIONAL: Un archivo README legible por humanos\n  values.yaml         # Los valores de configuración predeterminados para este chart\n  values.schema.json  # OPCIONAL: Un esquema JSON para imponer una estructura en el archivo values.yaml\n  charts/             # Un directorio que contiene los charts de los que depende este chart.\n  crds/               # Custom Resource Definitions\n  templates/          # Un directorio de plantillas que, cuando se combinan con valores, \n                      # generarán archivos de manifiesto de Kubernetes válidos.\n  templates/NOTES.txt # OPCIONAL: Un archivo de texto sin formato que contiene breves notas de uso.\n```\n\nHelm se reserva el uso de los directorios `charts/`, `crds/` y `templates/`, y\nde los nombres de archivo listados. Los demás archivos se dejarán como están.\n\n## El Archivo Chart.yaml {#the-chartyaml-file}\n\nEl archivo `Chart.yaml` es requerido para un chart. Contiene los siguientes campos:\n\n```yaml\napiVersion: La versión de la API de chart (requerido)\nname: El nombre del chart (requerido)\nversion: An versión SemVer 2 (requerido)\nkubeVersion: Un rango SemVer de versiones compatibles de Kubernetes (opcional)\ndescription: Una descripción de una sola frase de este proyecto (opcional)\ntype: El tipo de chart (opcional)\nkeywords:\n  - Una lista de palabras clave sobre este proyecto (opcional)\nhome: La URL de la página de inicio de este proyecto (opcional)\nsources:\n  - Una lista de URL al código fuente de este proyecto (opcional)\ndependencies: # Una lista de los requisitos del chart. (opcional)\n  - name: El nombre del chart (nginx)\n    version: La versión del chart (\"1.2.3\")\n    repository: (opcional) La URL del repositorio (\"https://example.com/charts\") o el alias (\"@repo-name\")\n    condition: (opcional) Una ruta yaml que se resuelve en un booleano, que se usa para habilitar/deshabilitar charts (e.g. subchart1.enabled)\n    tags: # (opcional)\n      - Las etiquetas se pueden usar para agrupar charts para habilitar/deshabilitar en for conjunta\n    import-values: # (opcional)\n      - 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.\n    alias: (opcional) Alias que se utilizará para el chart. Útil cuando tiene que agregar el mismo chart varias veces\nmaintainers: # (opcional)\n  - name: El nombre de los mantenedores (requerido para cada mantenedor)\n    email: El correo electrónico de los mantenedores (opcional para cada mantenedor)\n    url: Una URL para el mantenedor (opcional para cada mantenedor)\nicon: Una URL a una imagen SVG o PNG que se utilizará como icono (opcional).\nappVersion: La versión de la aplicación que contiene. (opcional). No es necesario que sea SemVer. Se recomienda encerrar en comillas.\ndeprecated: Si este chart está obsoleto (optional, boolean)\nannotations:\n  example: Una lista de anotaciones codificadas por nombre (opcional).\n```\n\nA partir de [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), no se\npermiten campos adicionales. El enfoque recomendado es agregar metadatos\npersonalizados en `annotations`.\n\n### Charts y Versionado\n\nCada chart debe tener un número de versión. Una versión debe seguir el estándar\n[SemVer 2](https://semver.org/spec/v2.0.0.html). A diferencia de Helm Classic,\nHelm v2 y versiones posteriores utilizan números de versión como marcadores de\nversión. Los paquetes en repositorios son identificado por el nombre más la versión.\n\nPor ejemplo, un chart `nginx` cuyo campo de versión se establece en\n`versión: 1.2.3` se denominará:\n\n```text\nnginx-1.2.3.tgz\n```\n\nTambién se admiten nombres SemVer 2 más complejos, como `versión: 1.2.3-alpha.1+ef365`.\nPero el sistema rechaza explícitamente los nombres que no son SemVer. Se exceptúan\nlas versiones en formato `x` o `x.y`. Por ejemplo, si hay una v al principio o una\nversión sin las 3 partes (por ejemplo, v1.2), se intentará convertirla en una\nversión semántica válida (por ejemplo, v1.2.0).\n\n**NOTA:** Mientras que Helm Classic y Deployment Manager estaban muy orientados\na GitHub cuando se trataba de charts, Helm v2 y versiones posteriores no dependen\nni requieren GitHub o incluso Git. En consecuencia, no utiliza Git SHA para el\ncontrol de versiones.\n\nEl campo `version` dentro de `Chart.yaml` es utilizado por muchas de las\nherramientas de Helm, incluida el CLI. Al generar un paquete, el comando\n`helm package` usará la versión que encuentre en el archivo `Chart.yaml`\ncomo un token en el nombre del paquete. El sistema asume que el número de versión\nen el nombre del paquete del chart coincide con el número de versión en\n`Chart.yaml`. El incumplimiento de esta suposición provocará un error.\n\n### El Campo `apiVersion`\n\nEl campo `apiVersion` debe ser `v2` para los charts de Helm que requieren al menos\nHelm 3. Los charts que admiten versiones anteriores de Helm tienen el campo `apiVersion`\nestablecido en `v1` y aún se pueden instalar en Helm 3.\n\nCambios de `v1` a `v2`:\n\n- Un campo `dependencies` que define las dependencias del chart, que se encontraba\n  en el archivo `requirements.yaml` para los charts `v1` (consulte [Dependencias\n  del chart](#dependencias-del-chart)).\n- El campo `type`, discriminando charts de aplicaciones y bibliotecas (consulte\n  [Tipos de Charts](#tipos-de-chart)).\n\n### El Campo `appVersion`\n\nTenga en cuenta que el campo `appVersion` no está relacionado con el campo `version`.\nEs una forma de especificar la versión de la aplicación. Por ejemplo, el chart\n`drupal` puede tener una `appVersion: \"8.2.1\"`, lo que indica que la versión de\nDrupal incluida en el chart (por defecto) es `8.2.1`. Este campo es informativo\ny no tiene ningún impacto en los cálculos de la versión del chart. Se recomienda\nencarecidamente envolver la versión entre comillas. Esto obliga al analizador YAML\na tratar el número de versión como una cadena. Dejarlo sin comillas puede provocar\nproblemas de análisis en algunos casos. Por ejemplo, YAML interpreta `1.0` como un\nvalor de punto flotante y un SHA de confirmación de git como `1234e10` como\nnotación científica.\n\nA partir de Helm v3.5.0, `helm create` envuelve el campo predeterminado\n`appVersion` entre comillas.\n\n### El Campo `kubeVersion`\n\nEl campo opcional `kubeVersion` puede definir restricciones de SemVer en las\nversiones compatibles de Kubernetes. Helm validará las restricciones de versión\nal instalar el chart y fallará si el clúster ejecuta una versión de Kubernetes\nno compatible.\n\nLas restricciones de versión pueden comprender comparaciones AND separadas por\nespacios, como\n\n```text\n>= 1.13.0 < 1.15.0\n```\n\nque pueden combinarse con el operador OR `||` como en el siguiente ejemplo\n\n```text\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\n\nEn este ejemplo, se excluye la versión `1.14.0`, lo que puede tener sentido si\nse sabe que un error en ciertas versiones impide que el chart se ejecute correctamente.\n\nAparte de las restricciones de versión que emplean operadores `=` `! =` `>` `<`\n`> =` `<=`, se admiten las siguientes notaciones abreviadas\n\n * rangos de guiones para intervalos cerrados, donde `1.1 - 2.3.4` es equivalente\n  a `>= 1.1 <= 2.3.4`.\n * comodines `x`, `X` y `*`, donde `1.2.x` es equivalente a `> = 1.2.0 <1.3.0`.\n * rangos de tilde (se permiten cambios en la versión del parche), donde `~1.2.3`\n   es equivalente a `>= 1.2.3 < 1.3.0`.\n * intervalos de intercalación (se permiten cambios menores en la versión), donde\n   `^1.2.3` es equivalente a `>= 1.2.3 < 2.0.0`.\n\nPara obtener una explicación detallada de las restricciones semver admitidas, consulte\n[Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Deprecando Charts\n\nAl administrar charts en un repositorio de charts, a veces es necesario deprecar\nun chart. El campo opcional `deprecated` en `Chart.yaml` se puede utilizar para\nmarcar un chart como deprecado. Si la **última** versión de un chart en el\nrepositorio está marcada como deprecado, entonces el chart en su conjunto se\nconsidera deprecado. El nombre del chart se puede reutilizar más tarde publicando\nuna versión más reciente que no esté marcada como deprecado. El flujo de trabajo\npara charts obsoletos es:\n\n1. Actualizar el archivo `Chart.yaml` del chart para marcar el chart como deprecado,\n   subiendo la versión\n2. Publicar la nueva versión del chart en el repositorio de charts.\n3. Eliminar el chart del repositorio de origen (p. Ej., git)\n\n### Tipos de Chart\n\nEl campo `type` define el tipo de chart. Hay dos tipos: `application` (aplicación)\ny `library` (biblioteca). Aplicación es el tipo predeterminado y es el chart estándar\ncon el que se puede operar completamente. El [chart de biblioteca](/topics/library_charts.md)\nproporciona utilidades o funciones para el generador de charts. Un chart de biblioteca\nse diferencia de un chart de aplicación porque no se puede instalar y, por lo\ngeneral, no contiene ningún objeto de recurso.\n\n**Nota:** Se puede utilizar un chart de aplicación como chart de biblioteca. Esto\nse habilita estableciendo el tipo en `library`. Luego, el chart se renderizará\ncomo un chart de biblioteca en el que se pueden aprovechar todas las utilidades\ny funciones. Todos los objetos de recursos del chart no se renderizarán.\n\n## Archivos LICENSE, README y NOTES del Chart\n\nLos Charts también pueden contener archivos que describen la instalación,\nconfiguración, uso y licencia de un chart.\n\nUn archivo LICENSE es un archivo de texto sin formato que contiene la\n[licencia](https://en.wikipedia.org/wiki/Software_license) para el chart. El\nchart puede contener una licencia, ya que puede tener lógica de programación en\nlas plantillas y, por lo tanto, no sería solo configuración. También puede haber\nlicencias separadas para la aplicación instalada por el chart, si es necesario.\n\nUn archivo README para un chart debe tener el formato Markdown (README.md) y\ngeneralmente debe contener:\n\n- Una descripción de la aplicación o servicio que proporciona el chart.\n- Cualquier requisito previo o requisito para ejecutar el chart.\n- Descripciones de opciones en `values.yaml` y valores predeterminados\n- Cualquier otra información que pueda ser relevante para la instalación o\n   configuración del chart\n\nCuando los concentradores y otras interfaces de usuario muestran detalles sobre\nun chart, ese detalle se extrae del contenido del archivo `README.md`.\n\nEl chart también puede contener un archivo corto de texto sin formato `templates/NOTES.txt`\nque se imprimirá después de la instalación y al ver el estado de un release. Este\narchivo se evalúa como una [plantilla](#plantillas-y-valores) y se puede utilizar\npara mostrar notas de uso, próximos pasos o cualquier otra información relevante\npara una publicación del chart. Por ejemplo, se pueden proporcionar instrucciones\npara conectarse a una base de datos o acceder a una interfaz de usuario web. Dado\nque este archivo se imprime en STDOUT cuando se ejecuta `helm install` o `helm status`,\nse recomienda mantener breve el contenido y señalar el archivo README para obtener\nmás detalles.\n\n## Dependencias del Chart\n\nEn Helm, un chart puede depender de cualquier número de otros charts. Estas\ndependencias se pueden vincular dinámicamente usando el campo `dependencies` en\n`Chart.yaml` o se pueden traer al directorio `charts/` y administrar manualmente.\n\n### Administrar Dependencias con el Campo `dependencies`\n\nLos chart requeridos por el chart actual se definen como una lista en el campo\n`dependencias`.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- El campo `name` es el nombre del chart que desea.\n- El campo `version` es la versión del chart que desea.\n- El campo `repository` es la URL completa del repositorio de charts. Tenga en\n  cuenta que usted también debe usar `helm repo add` para agregar ese repositorio\n  localmente.\n- Puede usar el nombre del repositorio en lugar de la URL\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nUna vez que haya definido las dependencias, puede ejecutar `helm dependency update`\ny usará su archivo de dependencia para descargar todos los chart especificados\nen su directorio `charts/` por usted.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nCuando `helm dependency update` recupera charts, los almacenará como archivos\nde chart en el directorio `charts/`. Entonces, para el ejemplo anterior, uno\nesperaría ver los siguientes archivos en el directorio de charts:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### El Campo Alias en dependencies\n\nAdemás de los otros campos anteriores, cada entrada de requisitos puede contener\nel campo opcional `alias`.\n\nAgregar un alias para un chart de dependencia colocaría un chart en dependencias\nusando alias como nombre de la nueva dependencia.\n\nSe puede usar un `alias` en los casos en que necesiten acceder a un chart con otro\nnombre(s).\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nEn el ejemplo anterior obtendremos 3 dependencias en total para `parentchart`:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nLa forma manual de lograr esto es copiando y pegando el mismo chart en el directorio\n`charts/` varias veces con diferentes nombres.\n\n#### Campos de Tags and Condition en dependencies\n\nAdemás de los otros campos anteriores, cada entrada de requisitos puede contener\nlos campos opcionales `tags` y `condition`.\n\nTodos los charts se cargan de forma predeterminada. Si los campos `tags` o `condition`\nestán presentes, se evaluarán y usarán para controlar la carga de los charts a\nlos que se aplican.\n\nCondition: el campo condition contiene una o más rutas YAML (delimitadas por\ncomas). Si esta ruta existe en los valores del padre superior y se resuelve en\nun valor booleano, el chart se habilitará o deshabilitará en función de ese\nvalor booleano. Solo se evalúa la primera ruta válida que se encuentra en la\nlista y, si no existen rutas, la condición no tiene ningún efecto.\n\nTags: el campo tag es una lista YAML de etiquetas para asociar con este chart. En\nlos valores padres superiores, todos los charts con etiquetas se pueden habilitar\no deshabilitar especificando la etiqueta y un valor booleano.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled, global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nEn el ejemplo anterior, todos los chart con la etiqueta `front-end` estarían deshabilitados,\npero dado que la ruta `subchart1.enabled` se evalúa como 'true' en los valores del\npadre, la condición anulará la etiqueta `front-end` y `subchart1` estará habilitado.\n\nDado que `subchart2` está etiquetado con `back-end` y esa etiqueta se evalúa como\n`true`, se habilitará `subchart2`. También tenga en cuenta que aunque `subchart2`\ntiene una condición especificada, no hay una ruta y un valor correspondientes en\nlos valores de los padres, por lo que la condición no tiene ningún efecto.\n\n##### Utilizar el CLI con Etiquetas y Condiciones\n\nEl parámetro `--set` se puede utilizar como de costumbre para alterar los valores\nde tags (etiquetas) y conditions (condiciones).\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Resolución de Etiquetas y Condiciones\n\n- **Las condiciones (cuando se establecen en values) siempre sobreescriben a\n  las etiquetas.** La primera ruta de condición que existe gana y las siguientes\n  para ese chart se ignoran.\n- Las etiquetas se evalúan como 'si alguna de las etiquetas del chart es\n  verdadera, habilite el chart'.\n- Los valores de etiquetas y condiciones deben establecerse en los values\n  del chart padre superior.\n- The `tags:` key in values must be a top level key. Globals and nested `tags:`\n  tables are not currently supported.\n- La clave `tags:` en values debe ser una clave de nivel superior. Los `tags:`\n  globales y anidados no son soportados actualmente.\n\n#### Importar values hijos via dependencias\n\nEn algunos casos, es deseable permitir que los valores de un chart secundario\nse propaguen al chart principal y se compartan como valores predeterminados\ncomunes. Un beneficio adicional de usar el formato de `exports` es que permitirá\nque las herramientas futuras introspecten los valores configurables por el usuario.\n\nLas claves que contienen los valores que se van a importar se pueden especificar\nen la sección `dependencies` del chart principal en el campo `import-values`\nmediante una lista YAML. Cada elemento de la lista es una clave que se importa\ndel campo `exports` del chart secundario.\n\nPara importar valores que no están contenidos en la clave `exports`, use el\nformato [hijo-padre](#usando-el-formato-padre-hijo). A continuación se describen\nejemplos de ambos formatos.\n\n##### Usando el formato de exportación\n\nIf a child chart's `values.yaml` file contains an `exports` field at the root,\nits contents may be imported directly into the parent's values by specifying the\nkeys to import as in the example below:\n\nSi el archivo `values.yaml` de un chart secundario contiene un campo de `exports`\nen la raíz, su contenido se puede importar directamente a los values del padre\nespecificando las claves para importar como en el siguiente ejemplo:\n\n```yaml\n# archivo Chart.yaml del padre\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# archivo value.yaml del hijo\n\nexports:\n  data:\n    myint: 99\n```\n\nDado que estamos especificando la clave `data` en nuestra lista de importación,\nHelm busca en el campo `exports` del chart secundario la clave `data` e importa\nsu contenido.\n\nEl values final del padres contendrían nuestro campo exportado:\n\n```yaml\n# values del padre\n\nmyint: 99\n```\n\nTenga en cuenta que la clave principal `data` no está contenida en el values\nfinal del padre. Si necesita especificar la clave principal, utilice el formato 'hijo-padre'.\n\n##### Usando el formato padre-hijo\n\nPara acceder a los valores que no están contenidos en la clave `exports` del values\ndel chart hijo, deberá especificar la clave de origen del values que se\nimportarán (`child`) y la ruta de destino en el values del chart padre (`parent`).\n\nThe `import-values` in the example below instructs Helm to take any values found\nat `child:` path and copy them to the parent's values at the path specified in\n`parent:`\n\nLos `import-values` en el siguiente ejemplo le indican a Helm que tome los valores\nencontrados en la ruta `child:` y los copie a los valores del padre en la ruta\nespecificada en `parent:`\n\n```yaml\n# archivo Chart.yaml del padre\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nEn el ejemplo anterior, los valores que se encuentran en `default.data` en los\nvalores del subchart1 se importarán a la clave `myimports` en los values del chart\npadre como se detalla a continuación:\n\n```yaml\n# archivo values.yaml del padre\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# archivo values.yaml subchart1\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nEl values del chart padre resultantes sería:\n\n```yaml\n# vales final del padre\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nEl values final del padre ahora contienen los campos `myint` y `mybool`\nimportados de subchart1.\n\n### Administrar Dependencias manualmente a través del directorio `charts/`\n\nSi se desea más control sobre las dependencias, estas dependencias se pueden\nexpresar explícitamente copiando los charts de dependencias en el directorio\n`charts/`.\n\nUna dependencia debe ser un directorio de chart desempaquetado, pero su nombre no\npuede comenzar con `_` o `.`. El cargador de charts ignora esos archivos.\n\nPor ejemplo, si el chart de WordPress depende del chart de Apache, el chart de Apache\n(de la versión correcta) se proporciona en el directorio `charts/` del chart de WordPress:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nEl ejemplo anterior muestra cómo el chart de WordPress expresa su dependencia\nde Apache y MySQL al incluir esos charts dentro de su directorio `charts /`.\n\n**CONSEJO:** _Para colocar una dependencia en su directorio `charts/`, use el\ncomando `helm pull`_\n\n### Aspectos operativos del uso de dependencias\n\nLas secciones anteriores explican cómo especificar las dependencias del chart,\npero ¿cómo afecta esto a la instalación del chart usando `helm install` y\n`helm upgrade`?\n\nSupongamos que un chart llamado \"A\" crea los siguientes objetos de Kubernetes\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nAdemás, A depende del chart B que crea los objetos\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nDespués de la instalación/actualización del chart A, se crea/modifica un único\nrelease de Helm. El release creará/actualizará todos los objetos de Kubernetes\nanteriores en el siguiente orden:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nEsto se debe a que cuando Helm instala/actualiza charts, los objetos de Kubernetes\nde los charts y todas sus dependencias son\n\n- agregado en un solo conjunto; luego\n- ordenados por tipo seguido de nombre; y entonces\n- creado/actualizado en ese orden.\n\nPor lo tanto, se crea un único release con todos los objetos del charts y sus dependencias.\n\nEl orden de instalación de los tipos de Kubernetes viene dado por la enumeración\nInstallOrder en kind_sorter.go (ver [el archivo fuente de Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n## Plantillas y Valores\n\nLas plantillas de Charts de Helm están escritas en el [lenguaje Go\ntemplate](https://golang.org/pkg/text/template/), con la adición de unas 50\nfunciones de plantilla complementarias [de la biblioteca Sprig](https://github.com/Masterminds/sprig)\ny algunas otras [funciones especializadas](/howto/charts_tips_and_tricks.md).\n\nTodos los archivos de plantilla se almacenan en la carpeta `templates/` de un chart.\nCuando Helm renderiza los charts, pasará todos los archivos de ese directorio a\ntravés del motor de plantillas.\n\nLos valores de las plantillas se proporcionan de dos formas:\n\n- Los desarrolladores de charts pueden proporcionar un archivo llamado `values.yaml`\n  dentro de un chart. Este archivo puede contener valores predeterminados.\n- Los usuarios de charts pueden proporcionar un archivo YAML que contenga valores.\n  Esto se puede proporcionar en la línea de comandos con `helm install`.\n\nCuando un usuario proporciona valores personalizados, estos valores sobreescribirán\nlos valores del archivo `values.yaml` del chart.\n\n### Archivos de Plantillas\n\nLos archivos de plantilla siguen las convenciones estándar para escribir plantillas\nde Go (consulte [la documentación del paquete de text/template de Go](https://golang.org/pkg/text/template/)\npara obtener más detalles). Un archivo de plantilla de ejemplo podría verse así:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nEl ejemplo anterior, basado ligeramente en\n[https://github.com/deis/charts](https://github.com/deis/charts), es una plantilla\npara un controlador de replicación de Kubernetes. Puede utilizar los siguientes\ncuatro valores de plantilla (normalmente definidos en un archivo `values.yaml`):\n\n- `imageRegistry`: El registro de origen de la imagen de Docker.\n- `dockerTag`: La etiqueta para image de Docker.\n- `pullPolicy`: La política de pull de The Kubernetes.\n- `storage`: El backend de almacenamiento, cuyo valor predeterminado es `\"minio\"`\n\nTodos estos valores los define el autor de la plantilla. Helm no requiere ni\ndicta parámetros.\n\nPara ver muchos charts operativos, consulte [Artifact\nHub](https://artifacthub.io/packages/search?kind=0) de la CNCF.\n\n### Valores Predefinidos\n\nLos valores que se proporcionan a través de un archivo `values.yaml` (o mediante\nla bandera `--set`) son accesibles desde el objeto `.Values` en una plantilla.\nPero hay otros datos predefinidos a los que puede acceder en tus plantillas.\n\nLos siguientes valores están predefinidos, están disponibles para todas las\nplantillas y no se pueden sobreescribir. Como ocurre con todos los valores,\nlos nombres son _sensibles a mayúsculas y minúsculas_.\n\n- `Release.Name`: El nombre del release (no del chart)\n- `Release.Namespace`: El namespace donde el chart fue deplegado.\n- `Release.Service`: El servicio que realizó el lanzamiento.\n- `Release.IsUpgrade`: Se establece en true (verdadero) si la operación actual\n  es una actualización o una reversión.\n- `Release.IsInstall`: Se establece en true (verdadero) si la operación actual\n  es una instalación.\n- `Chart`: El contenido de `Chart.yaml`. Por lo tanto, la versión del chart se\n  puede obtener como `Chart.Version` y los mantenedores están en `Chart.Maintainers`.\n- `Files`: Un objeto similar a un mapa que contiene todos los archivos no especiales\n  del chart. Esto no le dará acceso a las plantillas, pero le dará acceso a archivos\n  adicionales que están presentes (a menos que estén excluidos usando `.helmignore`).\n  Se puede acceder al archivo usando `{{ index .Files \"file.name\" }}` o usando la\n  función `{{ .Files.Get name }}`. También puede acceder al contenido del archivo\n  como `[]byte` usando `{{ .Files.GetBytes }}`\n- `Capabilities`: Un objeto similar a un mapa que contiene información sobre las\n  versiones de Kubernetes (`{{ .Capabilities.KubeVersion }}`) y las versiones\n  compatibles de la API de Kubernetes (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n**NOTA:** Se eliminarán todos los campos desconocidos de `Chart.yaml`. No serán\naccesibles dentro del objeto `Chart`. Por lo tanto, `Chart.yaml` no se puede usar\npara pasar datos estructurados arbitrariamente a la plantilla. Sin embargo, el\narchivo de values se puede usar para eso.\n\n### Archivos values\n\nTeniendo en cuenta la plantilla de la sección anterior, un archivo `values.yaml`\nque proporciona los valores necesarios se vería así:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nUn archivo values tiene el formato YAML. Un chart puede incluir un archivo\n`values.yaml` predeterminado. El comando de instalación de Helm permite al usuario\nsobreescribir valores al proporcionar valores YAML adicionales:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nCuando los valores se pasan de esta manera, se fusionarán en el archivo de values\npredeterminado. Por ejemplo, considere un archivo `myvals.yaml` que se ve así:\n\n```yaml\nstorage: \"gcs\"\n```\n\nCuando se fusiona con `values.yaml` del chart, el contenido generado resultante será:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nTenga en cuenta que solo se sobreescribó el último campo.\n\n**NOTA:** El archivo de valores predeterminados incluido dentro de un chart\n_debe_ llamarse `values.yaml`. Pero los archivos especificados en la línea de\ncomandos pueden tener cualquier nombre.\n\n**NOTA:** Si la marca `--set` se usa en `helm install` o `helm upgrade`, esos valores\nsimplemente se convierten a YAML en el lado del cliente.\n\n**NOTA:** Si existen entradas obligatorias en el archivo values, se pueden declarar\nsegún sea necesario en la plantilla del chart mediante la [función\n'required'](/howto/charts_tips_and_tricks.md)\n\nCualquiera de estos valores es accesible dentro de las plantillas usando el objeto\n`.Values`:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Alcance, Dependencias y Valores\n\nLos archivos de valores pueden declarar valores para el chart de nivel superior,\nasí como para cualquiera de los charts que se incluyen en el directorio `charts/`\nde ese chart. O, para expresarlo de otra manera, un archivo de valores puede\nproporcionar valores al chart, así como a cualquiera de sus dependencias. Por ejemplo,\nel chart de demostración de WordPress anterior tiene tanto `mysql` como `apache`\ncomo dependencias. El archivo de valores podría proporcionar valores a todos estos\ncomponentes:\n\n```yaml\ntitle: \"My WordPress Site\" # Enviado a la plantilla de WordPress\n\nmysql:\n  max_connections: 100 # Enviado a MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Enviado a Apache\n```\n\nLos charts de un nivel superior tienen acceso a todas las variables definidas a\nnivel inferior. Entonces, el chart de WordPress puede acceder a la contraseña de\nMySQL como `.Values.mysql.password`. Pero los charts de nivel inferior no pueden\nacceder a elementos de los charts padres, por lo que MySQL no podrá acceder a la\npropiedad `title`. Tampoco, en ese caso, puede acceder a `apache.port`.\n\nLos valores son dependientes del espacio de nombres, pero los espacios de nombres\nse podan. Entonces, para el chart de WordPress, puede acceder al campo de contraseña\nde MySQL como `.Values.mysql.password`. Pero para el chart MySQL, el alcance de\nlos valores se ha reducido y el prefijo del espacio de nombres eliminado, por lo\nque verá el campo de contraseña simplemente como `.Values.password`.\n\n#### Valores Globales\n\nA partir de 2.0.0-Alpha.2, Helm admite un valor \"global\" especial. Considere esta\nversión modificada del ejemplo anterior:\n\n```yaml\ntitle: \"My WordPress Site\" # Enviado a la plantilla de WordPress\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Enviado a MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Enviado a Apache\n```\n\nLo anterior agrega una sección `global` con el valor `app: MyWordPress`. Este\nvalor está disponible para _todos_ los charts como `.Values.global.app`.\n\nPor ejemplo, las plantillas `mysql` pueden acceder a `app` como\n`{{ .Values.global.app }}`, y también el chart `apache`. Efectivamente, el\narchivo de valores anterior se regenera así:\n\n```yaml\ntitle: \"My WordPress Site\" # Enviado a la plantilla de WordPress\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Enviado a MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Enviado a Apache\n```\n\nEsto proporciona una forma de compartir una variable de nivel superior con todos\nlos sub-charts, lo cual es útil para cosas como establecer propiedades de `metadatos`\ncomo etiquetas.\n\nSi un sub-chart declara una variable global, ese global se pasará _hacia abajo_\n(a los sub-charts del sub-chart), pero no _hacia arriba_ al chart padre. No hay\nforma de que un sub-chart influya en los valores del chart padre.\n\nAdemás, las variables globales de los charts padres tienen prioridad sobre las\nvariables globales de los subcharts.\n\n### Archivos de Esquema {#schema-files}\n\nA veces, un mantenedor de charts puede querer definir una estructura sobre sus\nvalores. Esto se puede hacer definiendo un esquema en el archivo\n`values.schema.json`. Un esquema se representa como un\n[JSON Schema](https://json-schema.org/). Podría verse algo como esto:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nEste esquema se aplicará a los valores para validarlo. La validación se produce\ncuando se invoca cualquiera de los siguientes comandos:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nUn ejemplo de un archivo `values.yaml` que cumpla con los requisitos de este\nesquema podría verse así:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nTenga en cuenta que el esquema se aplica al objeto final `.Values`, y no solo al\narchivo `values.yaml`. Esto significa que el siguiente archivo `yaml` es válido,\ndado que el chart se instala con la opción `--set` apropiada que se muestra a continuación.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nAdemás, el objeto `.Values` final se verifica con *todos* los esquemas de los sub-charts.\nEsto significa que un chart padre no puede eludir las restricciones de un sub-chart.\nEsto también funciona al revés: si un subchart tiene un requisito que no se cumple\nen el archivo `values.yaml` del subchart, el chart padre *debe* satisfacer esas\nrestricciones para ser válido.\n\nLa validación del esquema se puede deshabilitar con la siguiente opción.\nEsto es particularmente útil en entornos aislados (air-gapped) cuando el archivo\nJSON Schema de un chart contiene referencias remotas.\n```console\nhelm install --skip-schema-validation\n```\n\n### Referencias\n\nCuando se trata de escribir plantillas, valores y archivos de esquema, existen\nvarias referencias estándar que le ayudarán.\n\n- [Plantillas de Go](https://godoc.org/text/template)\n- [Funciones extras de plantillas](https://godoc.org/github.com/Masterminds/sprig)\n- [El formato YAML](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRDs)\n\nKubernetes proporciona un mecanismo para declarar nuevos tipos de objetos de Kubernetes.\nCon CustomResourceDefinitions (CRD), los desarrolladores de Kubernetes pueden declarar\ntipos de recursos personalizados.\n\nEn Helm 3, los CRD se tratan como un tipo especial de objeto. Se instalan antes\nque el resto de la tabla y están sujetos a algunas limitaciones.\n\nLos archivos CRD YAML deben colocarse en el directorio `crds/` dentro de un chart.\nSe pueden colocar varios CRD (separados por marcadores de inicio y finalización YAML)\nen el mismo archivo. Helm intentará cargar _todos_ los archivos del directorio\nCRD en Kubernetes.\n\nLos archivos CRD _no pueden tener plantilla_. Deben ser documentos YAML simples.\n\nCuando Helm instala un nuevo chart, cargará los CRD, se detendrá hasta que el\nservidor de API los ponga a disposición, y luego iniciará el motor de plantillas,\nrenderizará el resto del chart y lo cargará en Kubernetes. Debido a este orden,\nla información de CRD está disponible en el objeto `.Capabilities` en las\nplantillas de Helm, y las plantillas de Helm pueden crear nuevas instancias de\nobjetos que fueron declarados en los CRD.\n\nFor example, if your chart had a CRD for `CronTab` in the `crds/` directory, you\nmay create instances of the `CronTab` kind in the `templates/` directory:\n\nPor ejemplo, si su chart tenía un CRD para `CronTab` en el directorio `crds/`,\npuede crear instancias del tipo `CronTab` en el directorio `templates/`:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nEl archivo `crontab.yaml` debe contener el CRD sin directivas de plantilla:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nLuego, la plantilla `mycrontab.yaml` puede crear un nuevo `CronTab` (usando\nplantillas como de costumbre):\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm se asegurará de que el tipo `CronTab` se haya instalado y esté disponible\nen el servidor API de Kubernetes antes de continuar con la instalación de las cosas \nen `templates/`.\n\n### Limitaciones de los CRDs\n\nA diferencia de la mayoría de los objetos de Kubernetes, los CRD se instalan\nglobalmente. Por esa razón, Helm adopta un enfoque muy cauteloso en la gestión\nde CRD. Los CRD están sujetos a las siguientes limitaciones:\n\n- Los CRD nunca se reinstalan. Si Helm determina que los CRD en el directorio `crds/`\n  ya están presentes (independientemente de la versión), Helm no intentará\n  instalarlos ni actualizarlos.\n- Los CRD nunca se instalan en la actualización o reversión. Helm solo creará\n  CRD en las operaciones de instalación.\n- Los CRD nunca se eliminan. La eliminación de un CRD elimina automáticamente\n  todo el contenido del CRD en todos los espacios de nombres del clúster.\n  En consecuencia, Helm no eliminará los CRD.\n\nSe recomienda a los operadores que deseen actualizar o eliminar CRD que lo hagan\nmanualmente y con mucho cuidado.\n\n## Uso de Helm para Administrar Charts\n\nLa herramienta `helm` tiene varios comandos para trabajar con charts.\n\nPuede crear un nuevo chart para usted:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nUna vez que haya editado un chart, `helm` puede empaquetarlo en un archivo de\ncharts para usted:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nTambién puede usar `helm` para ayudarlo a encontrar problemas con el formato o\nla información de su chart:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Repositorios de Chart\n\nUn _repositorio de charts_ es un servidor HTTP que alberga uno o más charts\nempaquetados. Si bien `helm` se puede usar para administrar directorios de\ncharts locales, cuando se trata de compartir charts, el mecanismo preferido es\nun repositorio de charts.\n\nCualquier servidor HTTP que pueda servir archivos YAML y tar y que pueda responder\nsolicitudes GET se puede utilizar como servidor de repositorio. El equipo de Helm\nha probado algunos servidores, incluido Google Cloud Storage con el modo de sitio\nweb habilitado y S3 con el modo de sitio web habilitado.\n\nUn repositorio se caracteriza principalmente por la presencia de un archivo\nespecial llamado `index.yaml` que tiene una lista de todos los paquetes\nproporcionados por el repositorio, junto con metadatos que permiten recuperar y\nverificar esos paquetes.\n\nEn el lado del cliente, los repositorios se administran con los comandos `helm repo`.\nSin embargo, Helm no proporciona herramientas para cargar charts en servidores\nde repositorios remotos. Esto se debe a que hacerlo agregaría requisitos\nsustanciales a un servidor de implementación y, por lo tanto, elevaría la barrera\npara configurar un repositorio.\n\n## Paquetes de Inicio de Charts\n\nEl comando `helm create` toma una opción opcional `--starter` que le permite\nespecificar un \"chart de inicio\". Además, la opción starter tiene un alias corto `-p`.\n\nEjemplos de uso:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nLos paquetes de inicio son charts regulares, pero se encuentran en\n`$XDG_DATA_HOME/helm/starters`. Como desarrollador de charts, puede crear charts\nque estén diseñados específicamente para usarse como iniciadores. Dichos charts\ndeben diseñarse teniendo en cuenta las siguientes consideraciones:\n\n- El generador sobrescribirá el archivo `Chart.yaml`.\n- Los usuarios esperarán modificar el contenido de dicho chart, por lo que la\n  documentación debe indicar cómo pueden hacerlo los usuarios.\n- Todas las apariciones de `<CHARTNAME>` serán reemplazadas con el nombre de chart\n  especificado para que los charts de inicio se puedan usar como plantillas, excepto\n  para algunos archivos variables. Por ejemplo, si usa archivos personalizados en el\n  directorio `vars` o ciertos archivos `README.md`, `<CHARTNAME>` NO se reemplazará\n  dentro de ellos. Además, la descripción del chart no se hereda.\n\nActualmente, la única forma de agregar un chart a `$XDG_DATA_HOME/helm/starters`\nes copiarlo manualmente allí. En la documentación de su chart, es posible que\ndesee explicar ese proceso.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: \"Ganchos de Chart\"\ndescription: \"Describe como trabajar con ganchos de chart.\"\nsidebar_position: 2\n---\n\nHelm proporciona un mecanismo de _gancho_ (hook) que permite a los desarrolladores\nde charts intervenir en determinados puntos del ciclo de vida de un release. Por\nejemplo, puede utilizar ganchos para:\n\n- Cargue un ConfigMap o un Secret durante la instalación antes de que se carguen\n  otros charts.\n- Ejecute un trabajo para hacer una copia de seguridad de una base de datos antes\n  de instalar un nuevo chart y luego ejecute un segundo trabajo después de la\n  actualización para restaurar los datos.\n- Ejecute un trabajo antes de eliminar un release para retirar un servicio de\n  rotación antes de eliminarlo.\n\nLos ganchos funcionan como plantillas normales, pero tienen anotaciones especiales\nque hacen que Helm los utilice de manera diferente. En esta sección, cubrimos el\npatrón de uso básico de los ganchos.\n\n## Los Ganchos Disponibles\n\nSe definen los siguientes ganchos:\n\n| Valor de Anotación | Descripción                                                                                                                          |\n| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |\n| `pre-install`      | Se ejecuta después de que se procesan las plantillas, pero antes de que se creen recursos en Kubernetes                              |\n| `post-install`     | Se ejecuta después de que todos los recursos se cargan en Kubernetes                                                                 |\n| `pre-delete`       | Ejecuta en una solicitud de eliminación antes de que se eliminen los recursos de Kubernetes                                          |\n| `post-delete`      | Se ejecuta en una solicitud de eliminación después de que se hayan eliminado todos los recursos del release                          |\n| `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 |\n| `post-upgrade`     | Se ejecuta en una solicitud de actualización después de que se hayan actualizado todos los recursos.                                 |\n| `pre-rollback`     | Se ejecuta en una solicitud de reversión después de renderizar las plantillas, pero antes de revertir los recursos                   |\n| `post-rollback`    | Se ejecuta en una solicitud de reversión después de que se hayan modificado todos los recursos.                                      |\n| `test`             | Se ejecuta cuando se invoca el subcomando Helm test ([ver documentos de prueba](/topics/chart_tests.md))                                 |\n\n_Note que el gancho `crd-install` se ha eliminado a favor del directorio `crds/`\nen Helm 3._\n\n## Ganchos y el Ciclo de Vida del Release\n\nLos ganchos le brindan a usted, el desarrollador de charts, la oportunidad de\nrealizar operaciones en puntos estratégicos del ciclo de vida de un release. Por\nejemplo, considere el ciclo de vida de un `helm install`. De forma predeterminada,\nel ciclo de vida se ve así:\n\n1. El usuario ejecuta `helm install foo`\n2. La API de instalación de la biblioteca Helm se llama\n3. Después de cierta verificación, la biblioteca renderiza las plantillas de `foo`\n4. La biblioteca carga los recursos resultantes en Kubernetes.\n5. La biblioteca devuelve el objeto de release (y otros datos) al cliente.\n6. El cliente sale\n\nHelm define dos ganchos para el ciclo de vida de `install`: `pre-install` y\n`post-install`. Si el desarrollador del chart `foo` implementa ambos ganchos, el\nciclo de vida se modifica así:\n\n1. El usuario ejecuta `helm install foo`\n2. La API de instalación de la biblioteca Helm se llama\n3. Se instalan los CRD del directorio `crds/`\n4. Después de cierta verificación, la biblioteca renderiza las plantillas de `foo`\n5. La biblioteca se prepara para ejecutar los ganchos de `pre-install` (cargando\n   los recursos del gancho en Kubernetes)\n6. La biblioteca ordena los ganchos por peso (asignando un peso de 0 de forma predeterminada),\n   por tipo de recurso y finalmente por nombre en orden ascendente.\n7. Luego, la biblioteca carga primero el gancho con el peso más bajo (negativo a\n   positivo)\n8. La biblioteca espera hasta que el gancho esté \"Listo\" (excepto para los CRD).\n9. La biblioteca carga los recursos resultantes en Kubernetes. Tenga en cuenta\n   que si la bandera `--wait` está configurada, la biblioteca esperará hasta que\n   todos los recursos estén en un estado \"Listo\" y no ejecutará el gancho `post-install`\n   hasta que estén listos.\n10. La biblioteca ejecuta el gancho `post-install` (cargando recursos del gancho)\n11. La biblioteca espera hasta que el gancho esté \"Listo\".\n12. La biblioteca devuelve el objeto de release (y otros datos) al cliente.\n13. El cliente sale\n\n¿Qué significa esperar hasta que un gancho esté listo? Esto depende del recurso\ndeclarado en el gancho. Si el recurso es del tipo `Job` o `Pod`, Helm esperará\nhasta que se complete correctamente. Y si el gancho falla, el release fallará.\nEsta es una _operación de bloqueo_, por lo que el cliente de Helm se detendrá\nmientras se ejecuta el Job.\n\nPara todos los demás tipos, tan pronto como Kubernetes marca el recurso como\ncargado (agregado o actualizado), el recurso se considera \"Listo\". Cuando se\ndeclaran muchos recursos en un gancho, los recursos se ejecutan en serie. Si\ntienen pesos de gancho (ver más abajo), se ejecutan en orden ponderado. A partir\nde Helm 3.2.0, los recursos de ganchos con el mismo peso se instalan en el mismo\norden que los recursos normales que no son de gancho. De lo contrario, el ordenamiento\nno está garantizado. (En Helm 2.3.0 y posteriores, se ordenan alfabéticamente.\nSin embargo, ese comportamiento no se considera vinculante y podría cambiar en\nel futuro). Se considera una buena práctica agregar un peso de gancho y establecerlo\nen `0` si el peso no es importante.\n\n### Los recursos del gancho no se administran con los releases correspondientes\n\nLos recursos que crea un gancho no se rastrean ni administran actualmente como parte\ndel release. Una vez que Helm verifica que el gancho ha alcanzado su estado listo,\ndejará solo el recurso de gancho. La recolección de basura de los recursos del\ngancho cuando se elimina el release correspondiente se puede agregar a Helm 3 en\nel futuro, por lo que cualquier recurso del gancho que nunca deba eliminarse debe\nanotarse con `helm.sh/resource-policy: keep`.\n\nEn términos prácticos, esto significa que si crea recursos en un gancho, no puede\nconfiar en `helm uninstall` para eliminar los recursos. Para destruir dichos\nrecursos, debe [agregar una anotación personalizada `helm.sh/hook-delete-policy`](#políticas-de-eliminación-de-ganchos)\nal archivo de plantilla de gancho, o [establecer el campo de tiempo de vida (TTL)\nde un recurso Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Escribir un Gancho\n\nLos ganchos son solo archivos de manifiesto de Kubernetes con anotaciones\nespeciales en la sección `metadata`. Debido a que son archivos de plantilla,\npuede utilizar todas las funciones normales de la plantilla, incluida la lectura\nde `.Values`, `.Release` y `.Template`.\n\nPor ejemplo, esta plantilla, almacenada en `templates/post-install-job.yaml`,\ndeclara que un Job se ejecutará en `post-install`:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # Esto es lo que define este recurso como un gancho. Sin esta línea, \n    # el trabajo se considera parte del release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nLo que hace que esta plantilla sea un gancho es la anotación:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nUn recurso puede implementar varios ganchos:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nDe manera similar, no hay límite para la cantidad de recursos diferentes que\npueden implementar un gancho determinado. Por ejemplo, uno podría declarar tanto\nun ConfigMap y un Secret como un gancho de pre-install.\n\nCuando los sub-charts declaran ganchos, también se evalúan. No hay forma de que\nun chart de nivel superior deshabilite los ganchos declarados por los sub-charts.\n\nEs posible definir un peso para un gancho que ayudará a construir un orden de\nejecución determinista. Los pesos se definen mediante la siguiente anotación:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nLos pesos de los ganchos pueden ser números positivos o negativos, pero deben\nrepresentarse como cadenas. Cuando Helm inicia el ciclo de ejecución de ganchos\nde un tipo particular, los ordenará en orden ascendente.\n\n### Políticas de eliminación de ganchos\n\nEs posible definir políticas que determinen cuándo eliminar los recursos de\ngancho correspondientes. Las políticas de eliminación de ganchos se definen\nmediante la siguiente anotación:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nPuede elegir uno o más valores de anotación definidos:\n\n| Valor de Anotación     | Descripción                                                                        |\n| ---------------------- | ---------------------------------------------------------------------------------- |\n| `before-hook-creation` | Elimina el recurso anterior antes de que se lance un nuevo gancho (predeterminado) |\n| `hook-succeeded`       | Eliminar el recurso después de que el gancho se ejecute correctamente              |\n| `hook-failed`          | Eliminar el recurso si el gancho falló durante la ejecución                        |\n\nSi no se especifica ninguna anotación de política de eliminación de ganchos, el\ncomportamiento `before-hook-creation` se aplica de forma predeterminada.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/index.mdx",
    "content": "---\ntitle: \"Temas\"\nsidebar_position: 3\n---\n\n# Guías de Temas\n\nAquí encontrará una introducción a todas las partes clave de Helm que necesitará\no querrá saber.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: APIs de Kubernetes Obsoletas\ndescription: Explica las APIs de Kubernetes obsoletas en Helm\n---\n\nKubernetes es un sistema basado en APIs y estas evolucionan con el tiempo para\nadaptarse a una mejor comprensión del problema que resuelven. Esta es una\npráctica común en sistemas y sus APIs. Una parte importante de esta evolución es\ntener una buena política y proceso de deprecación para informar a los usuarios\nsobre cómo se implementan los cambios. En otras palabras, los consumidores de su\nAPI necesitan saber con anticipación en qué release se eliminará o cambiará una\nAPI. Esto evita sorpresas y cambios incompatibles para los consumidores.\n\nLa [política de deprecación de\nKubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\ndocumenta cómo Kubernetes maneja los cambios en sus versiones de API. La política\nestablece el plazo durante el cual las versiones de API serán soportadas después\nde un anuncio de deprecación. Por lo tanto, es importante conocer los anuncios\nde deprecación y saber cuándo se eliminarán las versiones de API para minimizar\nel impacto.\n\nEste es un ejemplo de un anuncio [para la eliminación de versiones de API\nobsoletas en Kubernetes\n1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) que fue\npublicado unos meses antes del release. Estas versiones de API ya habrían sido\nanunciadas como obsoletas previamente. Esto demuestra que existe una buena\npolítica que informa a los consumidores sobre el soporte de versiones de API.\n\nLas plantillas de Helm especifican un [grupo de API de\nKubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)\nal definir un objeto de Kubernetes, similar a un archivo de manifiesto de\nKubernetes. Se especifica en el campo `apiVersion` de la plantilla e identifica\nla versión de API del objeto de Kubernetes. Esto significa que los usuarios de\nHelm y los mantenedores de charts deben conocer cuándo las versiones de API de\nKubernetes han sido declaradas obsoletas y en qué versión de Kubernetes serán\neliminadas.\n\n## Mantenedores de Charts\n\nDebe auditar sus charts verificando las versiones de API de Kubernetes que están\nobsoletas o han sido eliminadas en alguna versión de Kubernetes. Las versiones\nde API que están por dejar de ser soportadas o que ya no lo son deben\nactualizarse a la versión soportada y publicar una nueva versión del chart. La\nversión de API se define mediante los campos `kind` y `apiVersion`. Por ejemplo,\naquí hay una versión de API de objeto `Deployment` eliminada en Kubernetes 1.16:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Usuarios de Helm\n\nDebe auditar los charts que utiliza (similar a los [mantenedores de\ncharts](#mantenedores-de-charts)) e identificar cualquier chart donde las\nversiones de API estén obsoletas o hayan sido eliminadas en alguna versión de\nKubernetes. Para los charts identificados, verifique si existe una versión más\nreciente del chart (con versiones de API soportadas) o actualice el chart usted\nmismo.\n\nAdemás, debe auditar los charts desplegados (es decir, los releases de Helm)\nverificando nuevamente si hay versiones de API obsoletas o eliminadas. Puede\nhacerlo obteniendo los detalles de un release con el comando `helm get manifest`.\n\nLos pasos para actualizar un release de Helm a APIs soportadas dependen de lo\nque encuentre:\n\n1. Si encuentra solo versiones de API obsoletas:\n  - Realice un `helm upgrade` con una versión del chart que tenga versiones de\n    API de Kubernetes soportadas\n  - Agregue una descripción en la actualización indicando que no debe revertirse\n    a una versión de Helm anterior a esta\n2.  Si encuentra alguna versión de API que haya sido eliminada en una versión de\n    Kubernetes:\n  - Si está ejecutando una versión de Kubernetes donde las versiones de API aún\n    están disponibles (por ejemplo, está en Kubernetes 1.15 y encontró que usa\n    APIs que serán eliminadas en Kubernetes 1.16):\n    - Siga el procedimiento del paso 1\n  - De lo contrario (por ejemplo, ya está ejecutando una versión de Kubernetes\n    donde algunas versiones de API reportadas por `helm get manifest` ya no\n    están disponibles):\n    - Necesita editar el manifiesto del release almacenado en el clúster para\n      actualizar las versiones de API. Consulte [Actualización de Versiones de\n      API de un Manifiesto de\n      Release](#actualización-de-versiones-de-api-de-un-manifiesto-de-release)\n      para más detalles\n\n> Nota: En todos los casos de actualización de un release de Helm con APIs\nsoportadas, nunca debe revertir el release a una versión anterior a la versión\ncon las APIs soportadas.\n\n> Recomendación: La mejor práctica es actualizar los releases que usan versiones\nde API obsoletas a versiones soportadas antes de actualizar a un clúster de\nKubernetes que elimine esas versiones de API.\n\nSi no actualiza un release como se sugirió anteriormente, obtendrá un error\nsimilar al siguiente al intentar actualizar un release en una versión de\nKubernetes donde sus versiones de API han sido eliminadas:\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm falla en este escenario porque intenta crear un parche diff entre el\nrelease desplegado actualmente (que contiene las APIs de Kubernetes eliminadas\nen esta versión) y el chart que está pasando con las versiones de API\nactualizadas/soportadas. La razón subyacente es que cuando Kubernetes elimina\nuna versión de API, la biblioteca cliente de Go de Kubernetes ya no puede\nanalizar los objetos obsoletos, por lo que Helm falla al llamar a la biblioteca.\nDesafortunadamente, Helm no puede recuperarse de esta situación y ya no puede\ngestionar dicho release. Consulte [Actualización de Versiones de API de un\nManifiesto de\nRelease](#actualización-de-versiones-de-api-de-un-manifiesto-de-release) para\nmás detalles sobre cómo recuperarse de este escenario.\n\n## Actualización de Versiones de API de un Manifiesto de Release\n\nEl manifiesto es una propiedad del objeto release de Helm que se almacena en el\ncampo de datos de un Secret (por defecto) o ConfigMap en el clúster. El campo de\ndatos contiene un objeto comprimido con gzip codificado en base 64 (hay una\ncodificación base 64 adicional para un Secret). Existe un Secret/ConfigMap por\ncada versión/revisión del release en el namespace del release.\n\nPuede usar el plugin [mapkubeapis](https://github.com/helm/helm-mapkubeapis) de\nHelm para actualizar un release a APIs soportadas. Consulte el readme para más\ndetalles.\n\nAlternativamente, puede seguir estos pasos manuales para actualizar las\nversiones de API de un manifiesto de release. Dependiendo de su configuración,\nseguirá los pasos para el backend de Secret o ConfigMap.\n\n- Obtenga el nombre del Secret o ConfigMap asociado con el último release\n  desplegado:\n  - Backend de Secrets: `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - Backend de ConfigMap: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- Obtenga los detalles del último release desplegado:\n  - Backend de Secrets: `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - Backend de ConfigMap: `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- Haga una copia de seguridad del release en caso de que necesite restaurarlo si\n  algo sale mal:\n  - `cp release.yaml release.bak`\n  - En caso de emergencia, restaure: `kubectl apply -f release.bak -n\n    <release_namespace>`\n- Decodifique el objeto release:\n  - Backend de Secrets:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - Backend de ConfigMap: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- Cambie las versiones de API de los manifiestos. Puede usar cualquier\n  herramienta (por ejemplo, un editor) para hacer los cambios. Esto está en el\n  campo `manifest` de su objeto release decodificado (`release.data.decoded`)\n- Codifique el objeto release:\n  - Backend de Secrets: `cat release.data.decoded | gzip | base64 | base64`\n  - Backend de ConfigMap: `cat release.data.decoded | gzip | base64`\n- Reemplace el valor de la propiedad `data.release` en el archivo del release\n  desplegado (`release.yaml`) con el nuevo objeto release codificado\n- Aplique el archivo al namespace: `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- Realice un `helm upgrade` con una versión del chart que tenga versiones de API\n  de Kubernetes soportadas\n- Agregue una descripción en la actualización indicando que no debe revertirse a\n  una versión de Helm anterior a esta\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: \"Guía de distribución de Kubernetes\"\ndescription: \"Captura información sobre el uso de Helm en entornos específicos de Kubernetes\"\nsidebar_position: 10\n---\n\nHelm 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).\n\nEste 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).\n\n\n## AKS\n\nHelm funciona con [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nHelm ha sido probado y funciona en la plataforma Mesospheres DC/OS 1.11 Kubernetes, y no requiere ninguna configuración adicional.\n\n## EKS\n\nHelm funciona con Amazon Elastic Kubernetes Service (Amazon EKS): [Uso de Helm con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nSe sabe que la plataforma Kubernetes alojada en GKE de Google funciona con Helm, y no requiere ninguna configuración adicional.\n\n## `scripts/local-cluster` e Hyperkube\n\nSe 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.\n\n## IKS\n\nHelm funciona con [IBM Cloud Kubernetes\nService](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nHelm se prueba regularmente en [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne\n\nHelm funciona en clusters configurados por KubeOne sin advertencias.\n\n## Kubermatic\n\nHelm 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.\n\n## MicroK8s\n\nHelm puede ser habilitado en [MicroK8s](https://microk8s.io) usando el comando: `microk8s.enable helm3`\n\n## Minikube\n\nHelm está probado y se sabe que funciona con [Minikube](https://github.com/kubernetes/minikube). No requiere configuración adicional.\n\n## Openshift\n\nHelm 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/).\n\n## Platform9\n\nHelm 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).\n\n## Ubuntu con `kubeadm`\n\nSe sabe que Kubernetes arrancado con `kubeadm` funciona en las siguientes distribuciones de Linux:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nAlgunas versiones de Helm (v2.0.0-beta2) requieren que el comando `export KUBECONFIG=/etc/kubernetes/admin.conf` o crear el fichero `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid\n\nHelm 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).\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: \"Charts de Biblioteca\"\ndescription: \"Explica los charts de biblioteca y ejemplos de uso.\"\nsidebar_position: 4\n---\n\nUn chart de biblioteca es un tipo de [chart de Helm](/topics/charts.md)\nque define las primitivas o definiciones del chart que pueden ser compartidas por\nlas plantillas de Helm en otros charts. Esto permite a los usuarios compartir\nfragmentos de código que se pueden reutilizar en los charts, evitando la repetición\ny manteniendo los charts [DRY](https://es.wikipedia.org/wiki/No_te_repitas).\n\nEl chart de biblioteca se introdujo en Helm 3 para reconocer formalmente\nlos charts comunes o auxiliares que han sido utilizados por los mantenedores\nde charts desde Helm 2. Al incluirlo como un tipo de chart, proporciona:\n\n- Un medio para distinguir explícitamente entre charts comunes y de aplicación\n- Lógica para evitar la instalación de un chart común\n- No se renderizan las plantillas en un chart común que puede contener artefactos\n  de un release\n- Permite que los charts dependientes utilicen el contexto del chart que los importa\n\nUn mantenedor de charts puede definir un chart común como un chart de biblioteca\ny ahora estar seguro de que Helm manejará el chart de una manera estándar y\nconsistente. También significa que las definiciones en un chart de aplicación\nse pueden compartir cambiando el tipo de chart.\n\n## Crear un Chart de Biblioteca Simple\n\nComo se mencionó anteriormente, un chart de biblioteca es un tipo de [chart de\nHelm](/topics/charts.md). Esto significa que puede comenzar\ncreando un chart base:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nPrimero eliminará todos los archivos en el directorio `templates` ya que crearemos\nnuestras propias definiciones de plantillas en este ejemplo.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nEl archivo values tampoco será necesario.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nAntes de pasar a la creación de código común, hagamos una revisión rápida de algunos\nconceptos relevantes de Helm. Una [plantilla con nombre](/chart_template_guide/named_templates.md)\n(a veces llamada parcial o subplantilla) es simplemente una plantilla definida\ndentro de un archivo, y se le da un nombre. En el directorio `templates/`, no se\nespera que ningún archivo que comience con un guión bajo (_) genere un archivo de\nmanifiesto de Kubernetes. Entonces, por convención, las plantillas auxiliares y\nlos parciales se colocan en archivos `_*.tpl` o `_*.yaml`.\n\nEn este ejemplo, codificaremos un ConfigMap común que crea un recurso ConfigMap\nvacío. Definiremos el ConfigMap común en el archivo `mylibchart/templates/_configmap.yaml`\nde la siguiente manera:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nLa construcción ConfigMap se define en la plantilla denominada `mylibchart.configmap.tpl`.\nEs un ConfigMap simple con un recurso vacío, `data`. Dentro de este archivo hay\notra plantilla con nombre llamada `mylibchart.configmap`. Esta plantilla con\nnombre incluye otra plantilla con nombre `mylibchart.util.merge` que tomará 2\nplantillas con nombre como argumentos, la plantilla que llama a `mylibchart.configmap`\ny `mylibchart.configmap.tpl`.\n\nLa función auxiliar `mylibchart.util.merge` es una plantilla con nombre en\n`mylibchart/templates/_util.yaml`. Es una utilidad útil de [El Chart de Utilidad\nComún de Helm](#el-chart-de-utilidad-común-de-helm) porque combina las 2 plantillas\ny sobrescribe cualquier parte común en ambas:\n\n```yaml\n{{- /*\nmylibchart.util.merge fusionará dos plantillas YAML y generará el resultado.\nEsto toma un array de tres valores:\n- el contexto superior\n- el nombre de la plantilla de las anulaciones (destino)\n- el nombre de la plantilla base (fuente)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nEsto es importante cuando un chart desea utilizar un código común que necesita\npersonalizar con su configuración.\n\nFinalmente, cambiemos el tipo de chart a `library`. Esto requiere editar\n`mylibchart/Chart.yaml` de la siguiente manera:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\nEl chart de biblioteca ahora está listo para ser compartido y su definición de\nConfigMap para ser reutilizada.\n\nAntes de continuar, vale la pena verificar si Helm reconoce el chart como un chart\nde biblioteca:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Utilice el Chart de Biblioteca Simple\n\nEs hora de usar el chart de biblioteca. Esto significa volver a crear un chart\nbase:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nLimpiemos los archivos de plantilla nuevamente, ya que solo queremos crear un ConfigMap:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nCuando queremos crear un ConfigMap simple en una plantilla de Helm, podría tener\nun aspecto similar al siguiente:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nSin embargo, vamos a reutilizar el código común ya creado en `mylibchart`. El\nConfigMap se puede crear en el archivo `mychart/templates/configmap.yaml` de\nla siguiente manera:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nPuede ver que simplifica el trabajo que tenemos que hacer al heredar la definición\ncomún de ConfigMap que agrega propiedades estándar para ConfigMap. En nuestra\nplantilla agregamos la configuración, en este caso la clave de datos `myvalue`\ny su valor. La configuración sobrescribe el recurso vacío del ConfigMap común.\nEsto es factible debido a la función auxiliar `mylibchart.util.merge` que\nmencionamos en la sección anterior.\n\nPara poder usar el código común, necesitamos agregar `mylibchart` como dependencia.\nAgregue lo siguiente al final del archivo `mychart/Chart.yaml`:\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nEsto incluye el chart de biblioteca como una dependencia dinámica del\nsistema de archivos que se encuentra en la misma ruta principal que nuestro\nchart de aplicación. Como estamos incluyendo el chart de biblioteca como\nuna dependencia dinámica, necesitamos ejecutar `helm dependency update`.\nHelm copiará el chart de biblioteca en su directorio `charts/`.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nAhora estamos listos para implementar nuestro chart. Antes de instalar, vale la\npena verificar primero la plantilla renderizada.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nEsto se parece al ConfigMap que queremos con la sobrescritura de datos de\n`myvalue: Hello World`. Vamos a instalarlo:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nPodemos recuperar el release y ver que se cargó la plantilla real.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\n## Beneficios del Chart de Biblioteca\n\nDebido a su incapacidad para actuar como charts independientes, los charts de\nbiblioteca pueden aprovechar la siguiente funcionalidad:\n\n- El objeto `.Files` hace referencia a las rutas de archivo del chart padre,\n  en lugar de la ruta local del chart de biblioteca\n- El objeto `.Values` es el mismo que el del chart padre, a diferencia de los\n  [subcharts](/chart_template_guide/subcharts_and_globals.md) de aplicación\n  que reciben la sección de valores configurada bajo su encabezado en el padre\n\n## El Chart de Utilidad Común de Helm\n\n```markdown\nNota: 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.\n```\n\nEste [chart](https://github.com/helm/charts/tree/master/incubator/common) fue\nel patrón original para los charts comunes. Proporciona utilidades que reflejan\nlas mejores prácticas del desarrollo de charts de Kubernetes. Lo mejor de todo\nes que puede usarlo de inmediato cuando desarrolle sus charts para brindarle un\ncódigo compartido útil.\n\nAquí hay una forma rápida de usarlo. Para más detalles, consulte el\n[README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nVuelva a crear un chart base:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nUsemos el código común del chart auxiliar. Primero, edite el deployment\n`demo/templates/deployment.yaml` de la siguiente manera:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Defina anulaciones para su recurso Deployment aquí, por ejemplo\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nY ahora el archivo de servicio, `demo/templates/service.yaml` como sigue:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Defina anulaciones para su recurso Service aquí, por ejemplo\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nEstas plantillas muestran cómo heredar el código común del chart auxiliar\nsimplifica su codificación hasta su configuración o personalización de los recursos.\n\nPara poder usar el código común, necesitamos agregar `common` como dependencia.\nAgregue lo siguiente al final del archivo `demo/Chart.yaml`:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nNota: Deberá agregar el repositorio `incubator` a la lista de repositorios\nde Helm (`helm repo add`).\n\nComo estamos incluyendo el chart como una dependencia dinámica, necesitamos\nejecutar `helm dependency update`. Helm copiará el chart auxiliar en su directorio\n`charts/`.\n\nComo el chart auxiliar usa algunas construcciones de Helm 2, deberá agregar\nlo siguiente a `demo/values.yaml` para permitir que se cargue la imagen `nginx`\nya que se actualizó en el chart base de Helm 3:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nPuede verificar que las plantillas del chart son correctas antes de desplegarlo\nusando los comandos `helm lint` y `helm template`.\n\n¡Si todo está bien, proceda a desplegarlo con `helm install`!\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Gestión de permisos para el backend de almacenamiento SQL\ndescription: Aprenda a configurar permisos cuando utilice el backend de almacenamiento SQL.\n---\n\nEste documento proporciona orientación para configurar y gestionar permisos al\nutilizar el backend de almacenamiento SQL.\n\n## Introducción\n\nPara manejar permisos, Helm aprovecha la funcionalidad RBAC de Kubernetes. Al\nutilizar el backend de almacenamiento SQL, los roles de Kubernetes no pueden\nusarse para determinar si un usuario puede acceder a un recurso dado. Este\ndocumento muestra cómo crear y gestionar estos permisos.\n\n## Inicialización\n\nCuando el CLI de Helm se conecte por primera vez a su base de datos, el cliente\nverificará que haya sido inicializada previamente. Si no lo está, realizará la\nconfiguración necesaria automáticamente. Esta inicialización requiere\nprivilegios de administrador en el esquema público, o al menos poder:\n\n* crear una tabla\n* otorgar privilegios en el esquema público\n\nUna vez ejecutada la migración en su base de datos, todos los demás roles pueden\nutilizar el cliente.\n\n## Otorgar privilegios a un usuario no administrador en PostgreSQL\n\nPara gestionar permisos, el controlador del backend SQL aprovecha la\nfuncionalidad [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)\n(Row Security Level) de PostgreSQL. RLS permite que todos los usuarios lean y\nescriban en la misma tabla, pero solo puedan manipular las filas para las que\ntienen permiso explícito. Por defecto, cualquier rol al que no se le hayan\notorgado explícitamente los privilegios correctos siempre devolverá una lista\nvacía al ejecutar `helm list` y no podrá recuperar ni modificar ningún recurso\nen el clúster.\n\nVeamos cómo otorgar a un rol dado acceso a namespaces específicos:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nEste comando otorgará permisos para leer y escribir todos los recursos que\ncumplan la condición `namespace = 'default'` al rol `role`. Después de crear esta\npolítica, el usuario conectado a la base de datos en representación del rol\n`role` podrá ver todos los releases en el namespace `default` al ejecutar\n`helm list`, y podrá modificarlos y eliminarlos.\n\nLos privilegios pueden gestionarse de manera granular con RLS, y puede resultar\nútil restringir el acceso según las diferentes columnas de la tabla:\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Guía de Plugins de Helm\ndescription: Introduce cómo usar y crear plugins para extender la funcionalidad de Helm.\nsidebar_position: 12\n---\n\nUn plugin de Helm es una herramienta a la que se puede acceder a través del CLI\nde `helm`, pero que no forma parte del código base incorporado de Helm.\n\nLos plugins existentes se pueden encontrar en la sección [relacionados](/community/related#helm-plugins)\no buscando en [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).\n\nEsta guía explica cómo usar y crear plugins.\n\n## Descripción General\n\nLos plugins de Helm son herramientas complementarias que se integran perfectamente\ncon Helm. Proporcionan una forma de extender el conjunto de características principales\nde Helm, sin requerir que cada nueva característica sea escrita en Go y añadida\na la herramienta principal.\n\nLos plugins de Helm tienen las siguientes características:\n\n- Se pueden agregar y eliminar de una instalación de Helm sin afectar la\n  herramienta principal de Helm.\n- Pueden ser escritos en cualquier lenguaje de programación.\n- Se integran con Helm y aparecerán en `helm help` y otros lugares.\n\nLos plugins de Helm residen en `$HELM_PLUGINS`. Puede encontrar el valor actual\nde esta variable, incluyendo el valor predeterminado cuando no está configurada\nen el entorno, usando el comando `helm env`.\n\nEl modelo de plugins de Helm está parcialmente basado en el modelo de plugins de\nGit. Por esa razón, a veces puede escuchar que `helm` se denomina la capa de\n_porcelana_, mientras que los plugins son la _fontanería_. Esta es una forma\nabreviada de sugerir que Helm proporciona la experiencia del usuario y la lógica\nde procesamiento de alto nivel, mientras que los plugins hacen el \"trabajo de\ndetalle\" de realizar una acción deseada.\n\n## Instalar un Plugin\n\nLos plugins se instalan usando el comando `$ helm plugin install <path|url>`. Puede\npasar una ruta a un plugin en su sistema de archivos local o una URL de un\nrepositorio VCS remoto. El comando `helm plugin install` clona o copia el plugin\nen la ruta/URL proporcionada en `$HELM_PLUGINS`. Si está instalando desde un VCS,\npuede especificar la versión con el argumento `--version`.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nSi tiene una distribución tar de un plugin, simplemente descomprima el plugin en\nel directorio `$HELM_PLUGINS`. También puede instalar plugins tarball\ndirectamente desde una URL usando `helm plugin install\nhttps://domain/path/to/plugin.tar.gz`\n\n## Estructura de Archivos del Plugin\n\nEn muchos aspectos, un plugin es similar a un chart. Cada plugin tiene un directorio\nde nivel superior que contiene un archivo `plugin.yaml`. Pueden estar presentes\narchivos adicionales, pero solo el archivo `plugin.yaml` es requerido.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## El Archivo plugin.yaml\n\nEl archivo plugin.yaml es requerido para un plugin. Contiene los siguientes campos:\n\n```yaml\nname: The name of the plugin (REQUIRED)\nversion: A SemVer 2 version (REQUIRED)\nusage: Single line usage text shown in help\ndescription: Long description shown in places like helm help\nignoreFlags: Ignore flags passed in from Helm\nplatformCommand: # Configure command to run based on the platform\n  - os: OS match, can be empty or omitted to match all OS'\n    arch: Architecture match, can be empty or omitted to match all architectures\n    command: Plugin command to execute\n    args: Plugin command arguments\ncommand: (DEPRECATED) Plugin command, use platformCommand instead\nplatformHooks: # Configure plugin lifecycle hooks based on the platform\n  install: # Install lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin install command to execute\n      args: Plugin install command arguments\n  update: # Update lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin update command to execute\n      args: Plugin update command arguments\n  delete: # Delete lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin delete command to execute\n      args: Plugin delete command arguments\nhooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead\n  install: Command to install plugin\n  update: Command to update plugin\n  delete: Command to delete plugin\ndownloaders: # Configure downloaders capability\n  - command: Command to invoke\n    protocols:\n      - Protocol schema supported\n```\n\n### El Campo `name`\n\nEl `name` es el nombre del plugin. Cuando Helm ejecuta este plugin, este es el\nnombre que usará (por ejemplo, `helm NAME` invocará este plugin).\n\n_`name` debe coincidir con el nombre del directorio._ En nuestro ejemplo anterior,\neso significa que el plugin con `name: last` debe estar contenido en un directorio\nllamado `last`.\n\nRestricciones sobre `name`:\n\n- `name` no puede duplicar uno de los comandos de nivel superior existentes de `helm`.\n- `name` debe estar restringido a los caracteres ASCII a-z, A-Z, 0-9, `_` y `-`.\n\n### El Campo `version`\n\nEl `version` es la versión SemVer 2 del plugin. `usage` y `description` se\nutilizan para generar el texto de ayuda de un comando.\n\n### El Campo `ignoreFlags`\n\nEl interruptor `ignoreFlags` le indica a Helm que _no_ pase banderas al plugin.\nPor lo tanto, si un plugin se llama con `helm myplugin --foo` e `ignoreFlags: true`,\nentonces `--foo` se descarta silenciosamente.\n\n### El Campo `platformCommand`\n\nEl campo `platformCommand` configura el comando que el plugin ejecutará cuando\nsea invocado. No puede establecer tanto `platformCommand` como `command`, ya que\nesto resultará en un error. Se aplicarán las siguientes reglas para decidir qué\ncomando usar:\n\n- Si `platformCommand` está presente, se usará.\n  - Si tanto `os` como `arch` coinciden con la plataforma actual, la búsqueda se\n  detendrá y se usará el comando.\n  - Si `os` coincide y `arch` está vacío, se usará el comando.\n  - Si tanto `os` como `arch` están vacíos, se usará el comando.\n  - Si no hay coincidencia, Helm saldrá con un error.\n- Si `platformCommand` no está presente y el obsoleto `command` está presente,\nse usará.\n  - Si el comando está vacío, Helm saldrá con un error.\n\n### El Campo `platformHooks`\n\nEl campo `platformHooks` configura los comandos que el plugin ejecutará para\neventos del ciclo de vida. No puede establecer tanto `platformHooks` como `hooks`,\nya que esto resultará en un error. Se aplicarán las siguientes reglas para decidir\nqué comando de hook usar:\n\n- Si `platformHooks` está presente, se usará y se procesarán los comandos para\nel evento del ciclo de vida.\n  - Si tanto `os` como `arch` coinciden con la plataforma actual, la búsqueda se\n  detendrá y se usará el comando.\n  - Si `os` coincide y `arch` está vacío, se usará el comando.\n  - Si tanto `os` como `arch` están vacíos, se usará el comando.\n  - Si no hay coincidencia, Helm omitirá el evento.\n- Si `platformHooks` no está presente y el obsoleto `hooks` está presente, se\nusará el comando para el evento del ciclo de vida.\n  - Si el comando está vacío, Helm omitirá el evento.\n\n## Construir un Plugin\n\nAquí está el YAML del plugin para un plugin simple que ayuda a obtener el nombre\ndel último release:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nLos plugins pueden requerir scripts y ejecutables adicionales.\nLos scripts pueden incluirse en el directorio del plugin y los ejecutables pueden\ndescargarse mediante un hook. El siguiente es un ejemplo de plugin:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nLas variables de entorno se interpolan antes de que el plugin se ejecute. El\npatrón anterior ilustra la forma preferida de indicar dónde reside el programa\ndel plugin.\n\n### Comandos del Plugin\n\nHay algunas estrategias para trabajar con comandos de plugins:\n\n- Si un plugin incluye un ejecutable, el ejecutable para un `platformCommand:` o\n  debe estar empaquetado en el directorio del plugin o instalado mediante un hook.\n- La línea `platformCommand:` o `command:` tendrá todas las variables de entorno\n  expandidas antes de la ejecución. `$HELM_PLUGIN_DIR` apuntará al directorio\n  del plugin.\n- El comando en sí no se ejecuta en un shell. Por lo tanto, no puede escribir\n  un script de shell en una sola línea.\n- Helm inyecta mucha configuración en variables de entorno. Examine el entorno\n  para ver qué información está disponible.\n- Helm no hace suposiciones sobre el lenguaje del plugin. Puede escribirlo en el\n  lenguaje que prefiera.\n- Los comandos son responsables de implementar texto de ayuda específico para `-h`\n  y `--help`. Helm usará `usage` y `description` para `helm help` y `helm\n  help myplugin`, pero no manejará `helm myplugin --help`.\n\n### Probar un Plugin Local\n\nPrimero necesita encontrar la ruta de su `HELM_PLUGINS`. Para hacerlo, ejecute el\nsiguiente comando:\n\n``` bash\nhelm env\n```\n\nCambie su directorio actual al directorio donde está configurado `HELM_PLUGINS`.\n\nAhora puede agregar un enlace simbólico a la salida de compilación de su plugin.\nEn este ejemplo lo hicimos para `mapkubeapis`.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Plugins de Descarga\n\nPor defecto, Helm puede descargar Charts usando HTTP/S. A partir de Helm 2.4.0,\nlos plugins pueden tener una capacidad especial para descargar Charts desde\nfuentes arbitrarias.\n\nLos plugins deben declarar esta capacidad especial en el archivo `plugin.yaml`\n(nivel superior):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nSi dicho plugin está instalado, Helm puede interactuar con el repositorio usando\nel esquema de protocolo especificado invocando el `command`. El repositorio\nespecial debe agregarse de manera similar a los regulares: `helm repo add favorite\nmyprotocol://example.com/`. Las reglas para los repositorios especiales son las\nmismas que para los regulares: Helm debe poder descargar el archivo `index.yaml`\npara descubrir y almacenar en caché la lista de Charts disponibles.\n\nEl comando definido se invocará con el siguiente esquema: `command certFile\nkeyFile caFile full-URL`. Las credenciales SSL provienen de la definición del\nrepositorio, almacenada en `$HELM_REPOSITORY_CONFIG`\n(es decir, `$HELM_CONFIG_HOME/repositories.yaml`). Se espera que un plugin de\ndescarga envíe el contenido sin procesar a stdout e informe errores en stderr.\n\nEl comando de descarga también admite subcomandos o argumentos, lo que le permite\nespecificar, por ejemplo, `bin/mydownloader subcommand -d` en el `plugin.yaml`.\nEsto es útil si desea usar el mismo ejecutable para el comando principal del\nplugin y el comando de descarga, pero con un subcomando diferente para cada uno.\n\n## Variables de Entorno\n\nCuando Helm ejecuta un plugin, pasa el entorno externo al plugin y también\ninyecta algunas variables de entorno adicionales.\n\nVariables como `KUBECONFIG` se configuran para el plugin si están configuradas\nen el entorno externo.\n\nSe garantiza que las siguientes variables estarán configuradas:\n\n- `HELM_PLUGINS`: La ruta al directorio de plugins.\n- `HELM_PLUGIN_NAME`: El nombre del plugin, como fue invocado por `helm`. Así que\n  `helm myplug` tendrá el nombre corto `myplug`.\n- `HELM_PLUGIN_DIR`: El directorio que contiene el plugin.\n- `HELM_BIN`: La ruta al comando `helm` (como fue ejecutado por el usuario).\n- `HELM_DEBUG`: Indica si la bandera de depuración fue establecida por helm.\n- `HELM_REGISTRY_CONFIG`: La ubicación de la configuración del registro (si se\n  usa). Tenga en cuenta que el uso de Helm con registros es una característica\n  experimental.\n- `HELM_REPOSITORY_CACHE`: La ruta a los archivos de caché del repositorio.\n- `HELM_REPOSITORY_CONFIG`: La ruta al archivo de configuración del repositorio.\n- `HELM_NAMESPACE`: El namespace dado al comando `helm` (generalmente usando\n  la bandera `-n`).\n- `HELM_KUBECONTEXT`: El nombre del contexto de configuración de Kubernetes dado\n  al comando `helm`.\n\nAdicionalmente, si se especificó explícitamente un archivo de configuración de\nKubernetes, se establecerá como la variable `KUBECONFIG`.\n\n## Una Nota sobre el Análisis de Banderas\n\nAl ejecutar un plugin, Helm analizará las banderas globales para su propio uso.\nNinguna de estas banderas se pasa al plugin.\n- `--burst-limit`: Esto se convierte a `$HELM_BURST_LIMIT`\n- `--debug`: Si se especifica, `$HELM_DEBUG` se establece en `1`\n- `--kube-apiserver`: Esto se convierte a `$HELM_KUBEAPISERVER`\n- `--kube-as-group`: Estas se convierten a `$HELM_KUBEASGROUPS`\n- `--kube-as-user`: Esto se convierte a `$HELM_KUBEASUSER`\n- `--kube-ca-file`: Esto se convierte a `$HELM_KUBECAFILE`\n- `--kube-context`: Esto se convierte a `$HELM_KUBECONTEXT`\n- `--kube-insecure-skip-tls-verify`: Esto se convierte a `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`\n- `--kube-tls-server-name`: Esto se convierte a `$HELM_KUBETLS_SERVER_NAME`\n- `--kube-token`: Esto se convierte a `$HELM_KUBETOKEN`\n- `--kubeconfig`: Esto se convierte a `$KUBECONFIG`\n- `--namespace` y `-n`: Esto se convierte a `$HELM_NAMESPACE`\n- `--qps`: Esto se convierte a `$HELM_QPS`\n- `--registry-config`: Esto se convierte a `$HELM_REGISTRY_CONFIG`\n- `--repository-cache`: Esto se convierte a `$HELM_REPOSITORY_CACHE`\n- `--repository-config`: Esto se convierte a `$HELM_REPOSITORY_CONFIG`\n\nLos plugins _deberían_ mostrar texto de ayuda y luego salir para `-h` y `--help`.\nEn todos los demás casos, los plugins pueden usar banderas según sea apropiado.\n\n## Proporcionar Auto-completado de Shell\n\nA partir de Helm 3.2, un plugin puede opcionalmente proporcionar soporte para\nauto-completado de shell como parte del mecanismo de auto-completado existente\nde Helm.\n\n### Auto-completado Estático\n\nSi un plugin proporciona sus propias banderas y/o subcomandos, puede informar a\nHelm de ellos teniendo un archivo `completion.yaml` ubicado en el directorio raíz\ndel plugin. El archivo `completion.yaml` tiene la siguiente forma:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nNotas:\n\n1. Todas las secciones son opcionales pero deben proporcionarse si son aplicables.\n1. Las banderas no deben incluir el prefijo `-` o `--`.\n1. Se pueden y deben especificar tanto banderas cortas como largas. Una bandera\n   corta no necesita estar asociada con su forma larga correspondiente, pero ambas\n   formas deben listarse.\n1. Las banderas no necesitan estar ordenadas de ninguna manera, pero deben listarse\n   en el punto correcto de la jerarquía de subcomandos del archivo.\n1. Las banderas globales existentes de Helm ya son manejadas por el mecanismo de\n   auto-completado de Helm, por lo tanto los plugins no necesitan especificar las\n   siguientes banderas `--debug`, `--namespace` o `-n`, `--kube-context`, y\n   `--kubeconfig`, ni ninguna otra bandera global.\n1. La lista `validArgs` proporciona una lista estática de posibles completados\n   para el primer parámetro después de un subcomando. No siempre es posible\n   proporcionar dicha lista por adelantado (consulte la sección [Completado\n   Dinámico](#completado-dinámico) a continuación), en cuyo caso la sección\n   `validArgs` puede omitirse.\n\nEl archivo `completion.yaml` es completamente opcional. Si no se proporciona,\nHelm simplemente no proporcionará auto-completado de shell para el plugin (a\nmenos que el plugin soporte [Completado Dinámico](#completado-dinámico)).\nAdemás, agregar un archivo `completion.yaml` es compatible con versiones anteriores\ny no afectará el comportamiento del plugin cuando se usen versiones anteriores\nde helm.\n\nComo ejemplo, para el plugin [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus)\nque no tiene subcomandos pero acepta las mismas banderas que el comando\n`helm status`, el archivo `completion.yaml` es:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nUn ejemplo más complejo para el plugin [`2to3`](https://github.com/helm/helm-2to3),\ntiene un archivo `completion.yaml` de:\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### Completado Dinámico\n\nTambién a partir de Helm 3.2, los plugins pueden proporcionar su propio\nauto-completado dinámico de shell. El auto-completado dinámico de shell es el\ncompletado de valores de parámetros o valores de banderas que no pueden definirse\npor adelantado. Por ejemplo, el completado de los nombres de releases de helm\nactualmente disponibles en el clúster.\n\nPara que el plugin soporte el completado dinámico, debe proporcionar un archivo\n**ejecutable** llamado `plugin.complete` en su directorio raíz. Cuando el script\nde completado de Helm requiere completados dinámicos para el plugin, ejecutará\nel archivo `plugin.complete`, pasándole la línea de comandos que necesita ser\ncompletada. El ejecutable `plugin.complete` deberá tener la lógica para determinar\ncuáles son las opciones de completado apropiadas y enviarlas a la salida estándar\npara ser consumidas por el script de completado de Helm.\n\nEl archivo `plugin.complete` es completamente opcional. Si no se proporciona,\nHelm simplemente no proporcionará auto-completado dinámico para el plugin.\nAdemás, agregar un archivo `plugin.complete` es compatible con versiones anteriores\ny no afectará el comportamiento del plugin cuando se usen versiones anteriores\nde helm.\n\nLa salida del script `plugin.complete` debe ser una lista separada por nuevas\nlíneas como:\n\n```console\nrel1\nrel2\nrel3\n```\n\nCuando se llama a `plugin.complete`, el entorno del plugin se configura igual que\ncuando se llama al script principal del plugin. Por lo tanto, las variables\n`$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` y todas las demás variables del plugin ya\nestarán configuradas, y sus banderas globales correspondientes habrán sido\neliminadas.\n\nEl archivo `plugin.complete` puede estar en cualquier forma ejecutable; puede ser\nun script de shell, un programa Go o cualquier otro tipo de programa que Helm\npueda ejecutar. El archivo `plugin.complete` ***debe*** tener permisos de\nejecución para el usuario. El archivo `plugin.complete` ***debe*** salir con un\ncódigo de éxito (valor 0).\n\nEn algunos casos, el completado dinámico requerirá obtener información del clúster\nde Kubernetes. Por ejemplo, el plugin `helm fullstatus` requiere un nombre de\nrelease como entrada. En el plugin `fullstatus`, para que su script\n`plugin.complete` proporcione completado para los nombres de releases actuales,\nsimplemente puede ejecutar `helm list -q` y mostrar el resultado.\n\nSi se desea usar el mismo ejecutable para la ejecución del plugin y para el\ncompletado del plugin, el script `plugin.complete` puede configurarse para llamar\nal ejecutable principal del plugin con algún parámetro o bandera especial; cuando\nel ejecutable principal del plugin detecte el parámetro o bandera especial, sabrá\nque debe ejecutar el completado. En nuestro ejemplo, `plugin.complete` podría\nimplementarse así:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nEl script real del plugin `fullstatus` (`status.sh`) debe entonces buscar la\nbandera `--complete` y, si la encuentra, mostrar los completados apropiados.\n\n### Consejos y Trucos\n\n1. El shell filtrará automáticamente las opciones de completado que no coincidan\n   con la entrada del usuario. Por lo tanto, un plugin puede devolver todos los\n   completados relevantes sin eliminar los que no coinciden con la entrada del\n   usuario. Por ejemplo, si la línea de comandos es `helm fullstatus ngin<TAB>`,\n   el script `plugin.complete` puede mostrar *todos* los nombres de releases (del\n   namespace `default`), no solo los que comienzan con `ngin`; el shell solo\n   mantendrá los que comienzan con `ngin`.\n1. Para simplificar el soporte de completado dinámico, especialmente si tiene un\n   plugin complejo, puede hacer que su script `plugin.complete` llame a su script\n   principal del plugin y solicite opciones de completado. Consulte la sección\n   [Completado Dinámico](#completado-dinámico) anterior para ver un ejemplo.\n1. Para depurar el completado dinámico y el archivo `plugin.complete`, puede\n   ejecutar lo siguiente para ver los resultados de completado:\n    - `helm __complete <pluginName> <arguments to complete>`. Por ejemplo:\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: \"Procedencia e Integridad de Helm\"\ndescription: \"Describe cómo verificar la integridad y el origen de un Chart.\"\nsidebar_position: 5\n---\n\nHelm tiene herramientas de procedencia que ayudan a los usuarios de charts a\nverificar la integridad y el origen de un paquete. Utilizando herramientas estándar\nde la industria basadas en PKI, GnuPG y administradores de paquetes muy respetados,\nHelm puede generar y verificar archivos de firmas.\n\n## Descripción General\n\nLa integridad se establece comparando un chart con un registro de procedencia.\nLos registros de procedencia se almacenan en _archivos de procedencia_, que se\nalmacenan junto con un chart empaquetado. Por ejemplo, si un chart se llama\n`myapp-1.2.3.tgz`, su archivo de procedencia será `myapp-1.2.3.tgz.prov`.\n\nLos archivos de procedencia se generan en el momento del empaquetado\n(`helm package --sign ...`) y se pueden verificar mediante varios comandos,\nen particular `helm install --verify`.\n\n## El Flujo de Trabajo\n\nEsta sección describe un flujo de trabajo potencial para utilizar los datos de\nprocedencia de manera eficaz.\n\nRequisitos previos:\n\n- Un par de claves PGP válido en formato binario (no blindado ASCII)\n- La herramienta de línea de comandos `helm`\n- Herramientas de línea de comandos de GnuPG (opcional)\n- Herramientas de línea de comandos de Keybase (opcional)\n\n**NOTA:** Si su clave privada PGP tiene una frase de contraseña, se le pedirá que\ningrese esa frase de contraseña para cualquier comando que admita la opción `--sign`.\n\nCrear un nuevo chart es el mismo que antes:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nUna vez que esté listo para empaquetar, agregue la marca `--sign` a `helm package`.\nAdemás, especifique el nombre con el que se conoce la clave de firma y el anillo\nde claves que contiene la clave privada correspondiente:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**Nota:** El valor del argumento `--key` debe ser una subcadena del `uid` de la\nclave deseada (en la salida de `gpg --list-keys`), por ejemplo, el nombre o el\ncorreo electrónico. **La huella _no_ se puede utilizar.**\n\n**SUGERENCIA:** para los usuarios de GnuPG, su anillo de claves secreto está en\n`~/.gnupg/secring.gpg`. Puede usar `gpg --list-secret-keys` para enumerar las\nclaves que tiene.\n\n**Advertencia:** GnuPG v2 almacena su llavero secreto usando un nuevo formato\n`kbx` en la ubicación predeterminada `~/.gnupg/pubring.kbx`. Utilice el siguiente\ncomando para convertir su llavero al formato gpg heredado:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nEn este punto, debería ver tanto `mychart-0.1.0.tgz` como `mychart-0.1.0.tgz.prov`.\nFinalmente, ambos archivos deberían cargarse en el repositorio de charts que desee.\n\nPuede verificar un chart usando `helm verify`:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nUna verificación fallida se ve así:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nPara verificar durante una instalación, use la bandera `--verify`.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nSi el llavero que contiene la clave pública asociada con el chart firmado no se\nencuentra en la ubicación predeterminada, es posible que deba señalar el llavero\ncon `--keyring PATH` como en el ejemplo de `helm package`.\n\nSi la verificación falla, la instalación se cancelará antes de que el chart sea renderizado.\n\n### Usando las credenciales de Keybase.io\n\nEl servicio [Keybase.io](https://keybase.io) facilita el establecimiento de una\ncadena de confianza para una identidad criptográfica. Las credenciales de la base\nde claves se pueden utilizar para firmar charts.\n\nRequisitos previos:\n\n- Una cuenta Keybase.io configurada\n- GnuPG instalado localmente\n- La CLI `keybase` instalada localmente\n\n#### Firma de paquetes\n\nEl primer paso es importar sus claves de Keybase a su anillo de claves\nGnuPG local:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nEsto convertirá su clave de Keybase al formato OpenPGP, y luego la importará\nlocalmente en su archivo `~/.gnupg/secring.gpg`.\n\nPuede comprobarlo ejecutando `gpg --list-secret-keys`.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nTenga en cuenta que su clave secreta tendrá una cadena de identificación:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nEse es el nombre completo de su clave.\n\nA continuación, puede empaquetar y firmar un chart con `helm package`. Asegúrese\nde utilizar al menos parte de esa cadena de nombre en `--key`.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nComo resultado, el comando `package` debería producir tanto un archivo\n`.tgz` como un archivo `.tgz.prov`.\n\n#### Verificación de paquetes\n\nTambién puede utilizar una técnica similar para verificar un chart firmado por\nla clave de Keybase de otra persona. Supongamos que desea verificar un paquete\nfirmado por `keybase.io/technosophos`. Para hacer esto, use la herramienta `keybase`:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nEl primer comando de arriba rastrea al usuario `technosophos`. A continuación,\n`keybase pgp pull` descarga las claves OpenPGP de todas las cuentas que sigue,\ncolocándolas en su anillo de claves GnuPG (`~/.gnupg/pubring.gpg`).\n\nEn este punto, ahora puede usar `helm verify` o cualquiera de los comandos con\nuna marca `--verify`:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Razones por las que un chart no puede verificar\n\nÉstas son razones comunes de falla.\n\n- Falta el archivo `.prov` o está dañado. Esto indica que algo está mal configurado\n  o que el responsable de mantenimiento original no creó un archivo de procedencia.\n- La clave utilizada para firmar el archivo no está en su llavero. Esto indica que\n  la entidad que firmó el chart no es alguien a quien ya haya señalado que confía.\n- Falló la verificación del archivo `.prov`. Esto indica que algo anda mal con\n  el chart o con los datos de procedencia.\n- Los hash de archivo en el archivo de procedencia no coinciden con el hash del\n  archivo de almacenamiento. Esto indica que el archivo ha sido manipulado.\n\nSi una verificación falla, hay motivos para desconfiar del paquete.\n\n## El Archivo de Procedencia\n\nEl archivo de procedencia contiene un archivo YAML de un chart más varios datos\nde verificación. Los archivos de procedencia están diseñados para generarse automáticamente.\n\nSe agregan los siguientes datos de procedencia:\n\n- El archivo de chart (`Chart.yaml`) se incluye para que tanto los humanos como\n  las herramientas puedan ver fácilmente el contenido del chart.\n- La firma (SHA256, al igual que Docker) del paquete de charts (el archivo `.tgz`)\n  está incluida y puede usarse para verificar la integridad del paquete de charts.\n- Todo el cuerpo está firmado utilizando el algoritmo utilizado por OpenPGP\n  (consulte [Keybase.io](https://keybase.io) para conocer una forma emergente de\n  facilitar la firma y verificación de cifrado).\n\nLa combinación de esto brinda a los usuarios las siguientes garantías:\n\n- El paquete en sí no ha sido manipulado (suma de comprobación del paquete `.tgz`).\n- Se conoce la entidad que liberó este paquete (a través de la firma GnuPG/PGP).\n\nEl formato del archivo se parece a esto:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nTenga en cuenta que la sección YAML contiene dos documentos (separados por `...\\n`).\nEl primer archivo es el contenido de `Chart.yaml`. El segundo son las sumas de\ncomprobación, un mapa de nombres de archivo a resúmenes SHA-256 del contenido de\nese archivo en el momento del empaquetado.\n\nEl bloque de firma es una firma PGP estándar, que proporciona [resistencia a la\nmanipulación](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Repositorios de Charts\n\nLos repositorios de charts sirven como una colección centralizada de charts de Helm.\n\nLos repositorios de charts deben permitir la entrega de archivos de procedencia\na través de HTTP a través de una solicitud específica, y deben hacerlos disponibles\nen la misma ruta de URI que el chart.\n\nPor ejemplo, si la URL base de un paquete es\n`https://example.com/charts/mychart-1.2.3.tgz`, el archivo de procedencia,\nsi existe, DEBE ser accesible en `https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nDesde la perspectiva del usuario final, `helm install --verify myrepo/mychart-1.2.3`\ndebería resultar en la descarga tanto del chart como del archivo de procedencia\nsin configuración o acción adicional del usuario.\n\n### Firmas en registros basados en OCI\n\nAl publicar charts en un [registro basado en OCI](/topics/registries.md), se puede\nutilizar el [plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) para\npublicar la procedencia en [sigstore](https://sigstore.dev/). [Como se describe en la\ndocumentación](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), el\nproceso de crear la procedencia y firmar con una clave GPG es común, pero el comando\n`helm sigstore upload` se puede utilizar para publicar la procedencia en un registro\nde transparencia inmutable.\n\n## Establecimiento de Autoridad y Autenticidad\n\nCuando se trata de sistemas de cadena de confianza, es importante poder establecer\nla autoridad de un firmante. O, para decirlo claramente, el sistema anterior depende\ndel hecho de que usted confía en la persona que firmó el chart. Eso, a su vez,\nsignifica que debe confiar en la clave pública del firmante.\n\nUna de las decisiones de diseño de Helm ha sido que el proyecto Helm no se\ninsertará en la cadena de confianza como parte necesaria. No queremos ser\n\"la autoridad de certificación\" para todos los firmantes de charts. En cambio,\nestamos a favor de un modelo descentralizado, que es parte de la razón por la\nque elegimos OpenPGP como nuestra tecnología fundamental. Entonces, cuando se\ntrata de establecer la autoridad, hemos dejado este paso más o menos indefinido\nen Helm 2 (una decisión llevada a cabo en Helm 3).\n\nSin embargo, tenemos algunos consejos y recomendaciones para aquellos interesados\nen utilizar el sistema de procedencia:\n\n- La plataforma [Keybase](https://keybase.io) proporciona un repositorio público\n  centralizado para información de confianza.\n  - Puede utilizar Keybase para almacenar sus claves o para obtener las claves\n    públicas de otros.\n  - Keybase también tiene documentación fabulosa disponible\n  - Si bien no lo hemos probado, la función de \"sitio web seguro\" de Keybase\n    podría usarse para servir charts de Helm.\n  - La idea básica es que un \"revisor de charts\" oficial firme los charts con\n    su clave, y el archivo de procedencia resultante se carga en el repositorio\n    de charts.\n  - Se ha trabajado en la idea de que se pueda incluir una lista de claves de\n    firmas válidas en el archivo `index.yaml` de un repositorio.\n\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: Control de Acceso Basado en Roles\ndescription: Explica cómo Helm interactúa con el Control de Acceso Basado en Roles (RBAC) de Kubernetes.\nsidebar_position: 11\n---\n\nEn Kubernetes, otorgar roles a un usuario o a una cuenta de servicio específica\nde la aplicación es una buena práctica para asegurar que su aplicación esté\noperando dentro del alcance que usted ha especificado. Lea más sobre los permisos\nde cuentas de servicio [en la documentación oficial de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nA partir de Kubernetes 1.6, el Control de Acceso Basado en Roles está habilitado\npor defecto. RBAC le permite especificar qué tipos de acciones están permitidas\ndependiendo del usuario y su rol en su organización.\n\nCon RBAC, puede:\n\n- otorgar operaciones privilegiadas (crear recursos a nivel de clúster, como\n  nuevos roles) a administradores\n- limitar la capacidad de un usuario para crear recursos (pods, volúmenes\n  persistentes, deployments) a namespaces específicos, o a nivel de todo el\n  clúster (cuotas de recursos, roles, definiciones de recursos personalizados)\n- limitar la capacidad de un usuario para ver recursos ya sea en namespaces\n  específicos o a nivel de todo el clúster.\n\nEsta guía es para administradores que desean restringir el alcance de la\ninteracción de un usuario con la API de Kubernetes.\n\n## Administración de cuentas de usuario\n\nTodos los clústeres de Kubernetes tienen dos categorías de usuarios: cuentas de\nservicio administradas por Kubernetes, y usuarios normales.\n\nSe asume que los usuarios normales son administrados por un servicio externo e\nindependiente. Un administrador que distribuye claves privadas, un almacén de\nusuarios como Keystone o Google Accounts, incluso un archivo con una lista de\nnombres de usuario y contraseñas. En este sentido, Kubernetes no tiene objetos\nque representen cuentas de usuarios normales. Los usuarios normales no pueden\nagregarse a un clúster mediante una llamada a la API.\n\nEn contraste, las cuentas de servicio son usuarios administrados por la API de\nKubernetes. Están vinculadas a namespaces específicos y son creadas\nautomáticamente por el servidor de API o manualmente mediante llamadas a la API.\nLas cuentas de servicio están ligadas a un conjunto de credenciales almacenadas\ncomo Secrets, que se montan en los pods permitiendo que los procesos dentro del\nclúster se comuniquen con la API de Kubernetes.\n\nLas solicitudes a la API están vinculadas ya sea a un usuario normal o a una\ncuenta de servicio, o se tratan como solicitudes anónimas. Esto significa que\ncada proceso dentro o fuera del clúster, desde un usuario humano escribiendo\n`kubectl` en una estación de trabajo, hasta kubelets en los nodos, hasta miembros\ndel plano de control, debe autenticarse al hacer solicitudes al servidor de API,\no ser tratado como un usuario anónimo.\n\n## Roles, ClusterRoles, RoleBindings y ClusterRoleBindings\n\nEn Kubernetes, las cuentas de usuario y las cuentas de servicio solo pueden ver y\neditar los recursos a los que se les ha otorgado acceso. Este acceso se otorga\nmediante el uso de Roles y RoleBindings. Los Roles y RoleBindings están vinculados\na un namespace particular, lo que otorga a los usuarios la capacidad de ver y/o\neditar recursos dentro de ese namespace al que el Role les proporciona acceso.\n\nA nivel de clúster, estos se denominan ClusterRoles y ClusterRoleBindings.\nOtorgar a un usuario un ClusterRole le da acceso para ver y/o editar recursos en\ntodo el clúster. También es necesario para ver y/o editar recursos a nivel de\nclúster (namespaces, cuotas de recursos, nodos).\n\nLos ClusterRoles pueden vincularse a un namespace particular mediante referencia\nen un RoleBinding. Los ClusterRoles predeterminados `admin`, `edit` y `view` se\nutilizan comúnmente de esta manera.\n\nEstos son algunos ClusterRoles disponibles por defecto en Kubernetes. Están\npensados para ser roles orientados al usuario. Incluyen roles de superusuario\n(`cluster-admin`) y roles con acceso más granular (`admin`, `edit`, `view`).\n\n| ClusterRole predeterminado | ClusterRoleBinding predeterminado | Descripción\n|----------------------------|-----------------------------------|-------------\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í.\n| `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í.\n| `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.\n| `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.\n\n## Restringir el acceso de una cuenta de usuario usando RBAC\n\nAhora que entendemos los conceptos básicos del Control de Acceso Basado en Roles,\nanalicemos cómo un administrador puede restringir el alcance del acceso de un\nusuario.\n\n### Ejemplo: Otorgar a un usuario acceso de lectura/escritura a un namespace particular\n\nPara restringir el acceso de un usuario a un namespace particular, podemos usar\nel role `edit` o el role `admin`. Si sus charts crean o interactúan con Roles y\nRoleBindings, querrá usar el ClusterRole `admin`.\n\nAdicionalmente, también puede crear un RoleBinding con acceso `cluster-admin`.\nOtorgar a un usuario acceso `cluster-admin` a nivel de namespace proporciona\ncontrol total sobre todos los recursos en el namespace, incluyendo el namespace\nen sí.\n\nPara este ejemplo, crearemos un usuario con el Role `edit`. Primero, cree el\nnamespace:\n\n```console\n$ kubectl create namespace foo\n```\n\nAhora, cree un RoleBinding en ese namespace, otorgando al usuario el role `edit`.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Ejemplo: Otorgar a un usuario acceso de lectura/escritura a nivel de clúster\n\nSi un usuario desea instalar un chart que instala recursos a nivel de clúster\n(namespaces, roles, definiciones de recursos personalizados, etc.), necesitará\nacceso de escritura a nivel de clúster.\n\nPara hacer esto, otorgue al usuario acceso `admin` o `cluster-admin`.\n\nOtorgar a un usuario acceso `cluster-admin` le da acceso a absolutamente todos\nlos recursos disponibles en Kubernetes, incluyendo acceso a nodos con\n`kubectl drain` y otras tareas administrativas. Es altamente recomendable\nconsiderar proporcionar al usuario acceso `admin` en su lugar, o crear un\nClusterRole personalizado adaptado a sus necesidades.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Ejemplo: Otorgar a un usuario acceso de solo lectura a un namespace particular\n\nHabrá notado que no hay un ClusterRole disponible para ver secrets. El ClusterRole\n`view` no otorga a un usuario acceso de lectura a Secrets debido a preocupaciones\nde escalada de privilegios. Helm almacena los metadatos de releases como Secrets por defecto.\n\nPara que un usuario pueda ejecutar `helm list`, necesita poder leer estos secrets.\nPara esto, crearemos un ClusterRole especial `secret-reader`.\n\nCree el archivo `cluster-role-secret-reader.yaml` y escriba el siguiente\ncontenido en el archivo:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nLuego, cree el ClusterRole usando\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nUna vez hecho esto, podemos otorgar a un usuario acceso de lectura a la mayoría\nde los recursos, y luego otorgarle acceso de lectura a los secrets:\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Ejemplo: Otorgar a un usuario acceso de solo lectura a nivel de clúster\n\nEn ciertos escenarios, puede ser beneficioso otorgar a un usuario acceso a nivel\nde clúster. Por ejemplo, si un usuario quiere ejecutar el comando\n`helm list --all-namespaces`, la API requiere que el usuario tenga acceso de\nlectura a nivel de clúster.\n\nPara hacer esto, otorgue al usuario acceso tanto a `view` como a `secret-reader`\ncomo se describió anteriormente, pero con un ClusterRoleBinding.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Consideraciones adicionales\n\nLos ejemplos mostrados anteriormente utilizan los ClusterRoles predeterminados\nproporcionados con Kubernetes. Para un control más detallado sobre a qué recursos\nse les otorga acceso a los usuarios, consulte [la documentación de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)\nsobre cómo crear sus propios Roles y ClusterRoles personalizados.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: Uso de registros basados en OCI\ndescription: Describe cómo usar OCI para la distribución de Charts.\nsidebar_position: 7\n---\n\nA 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.\n\n\n## Soporte OCI antes de v3.8.0\n\nEl 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.\n\n### Habilitar el soporte OCI antes de v3.8.0\n\nAntes de Helm v3.8.0, el soporte OCI es *experimental* y debe ser habilitado.\n\nPara habilitar el soporte experimental de OCI en versiones de Helm anteriores a v3.8.0, configure `HELM_EXPERIMENTAL_OCI` en su entorno. Por ejemplo:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### Deprecación de características y cambios de comportamiento de OCI con v3.8.0\n\nCon 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:\n\n- Al establecer un chart en las dependencias como OCI, la versión se puede establecer como un rango al igual que otras dependencias.\n- 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.\n- 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.\n\n### Deprecación de características y cambios de comportamiento de OCI con v3.7.0\n\nCon 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:\n\n- El subcomando `helm chart` ha sido eliminado.\n- El caché de charts ha sido eliminado (no más `helm chart list`, etc.).\n- Las referencias a registros OCI ahora siempre llevan el prefijo `oci://`.\n- El nombre base de la referencia del registro *siempre* debe coincidir con el nombre del chart.\n- La etiqueta de la referencia del registro *siempre* debe coincidir con la versión semántica del chart (es decir, no hay etiquetas `latest`).\n- El tipo de medio de la capa del chart cambió de `application/tar+gzip` a `application/vnd.cncf.helm.chart.content.v1.tar+gzip`.\n\n\n## Uso de un registro basado en OCI\n\n### Repositorios Helm en registros basados en OCI\n\nUn [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.\n\n### Usar registros alojados\n\nExisten varios registros de contenedores alojados con soporte OCI que puede usar para sus charts de Helm. Por ejemplo:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\nSiga la documentación del proveedor de su registro de contenedores alojado para crear y configurar un registro con soporte OCI.\n\n**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.\n\n### Uso de sigstore para firmar charts basados en OCI\n\nEl 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.\n\nPara 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).\n\n## Comandos para trabajar con registros\n\n### El subcomando `registry`\n\n#### `login`\n\nIniciar sesión en un registro (con entrada manual de contraseña)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nCerrar sesión de un registro\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### El subcomando `push`\n\nSubir un chart a un registro basado en OCI:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nEl subcomando `push` solo puede usarse con archivos `.tgz` creados previamente usando `helm package`.\n\nAl 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.\n\nEl 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.\n\nCiertos 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`.\n\nSi 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).\n\nLos 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`.\n\n### Otros subcomandos\n\nEl soporte para el protocolo `oci://` también está disponible en varios otros subcomandos. Aquí está la lista completa:\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nEl 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).\n\nAquí hay algunos ejemplos del uso de los subcomandos listados anteriormente con charts basados en OCI:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Instalar charts con digest\n\nInstalar 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:\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## Especificar dependencias\n\nLas dependencias de un chart se pueden descargar de un registro usando el subcomando `dependency update`.\n\nEl `repository` para una entrada dada en `Chart.yaml` se especifica como la referencia del registro sin el nombre base:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\nEsto descargará `oci://localhost:5000/myrepo/mychart:2.7.0` cuando se ejecute `dependency update`.\n\n## Manifiesto de chart de Helm\n\nEjemplo de manifiesto de chart de Helm tal como se representa en un registro (note los campos `mediaType`):\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nEl siguiente ejemplo contiene un [archivo de procedencia](/topics/provenance.md) (note la capa adicional):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Migrar desde repositorios de charts\n\nMigrar 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.\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: Migración de Helm v2 a v3\ndescription: Aprenda cómo migrar de Helm v2 a v3.\nsidebar_position: 13\n---\n\nEsta guía muestra cómo migrar de Helm v2 a v3. Helm v2 debe estar instalado\ny gestionando releases en uno o más clústeres.\n\n## Resumen de Cambios en Helm 3\n\nLa lista completa de cambios de Helm 2 a 3 está documentada en la [sección de\npreguntas frecuentes](/faq/changes_since_helm2.md). A continuación se presenta un\nresumen de algunos de esos cambios que el usuario debe conocer antes y durante\nla migración:\n\n1. Eliminación de Tiller:\n   - Reemplaza la arquitectura cliente/servidor por una arquitectura\n     cliente/biblioteca (solo el binario `helm`)\n   - La seguridad ahora se gestiona por usuario (delegada a la seguridad del\n     clúster de Kubernetes del usuario)\n   - Los releases ahora se almacenan como secrets dentro del clúster y los\n     metadatos del objeto release han cambiado\n   - Los releases se persisten por namespace del release y ya no en el namespace\n     de Tiller\n2. Repositorio de charts actualizado:\n   - `helm search` ahora soporta tanto búsquedas en repositorios locales como\n     consultas de búsqueda en Artifact Hub\n3. Chart apiVersion actualizado a \"v2\" para los siguientes cambios de especificación:\n   - Las dependencias de charts enlazadas dinámicamente se movieron a `Chart.yaml`\n     (`requirements.yaml` eliminado y requirements --> dependencies)\n   - Los library charts (charts auxiliares/comunes) ahora pueden añadirse como\n     dependencias de charts enlazadas dinámicamente\n   - Los charts tienen un campo de metadatos `type` para definir si el chart es\n     de tipo `application` o `library`. Por defecto es application, lo que\n     significa que es renderizable e instalable\n   - Los charts de Helm 2 (apiVersion=v1) siguen siendo instalables\n4. Especificación de directorios XDG añadida:\n   - El directorio home de Helm eliminado y reemplazado por la especificación de\n     directorios XDG para almacenar archivos de configuración\n   - Ya no es necesario inicializar Helm\n   - `helm init` y `helm home` eliminados\n5. Cambios adicionales:\n   - La instalación/configuración de Helm se simplifica:\n     - Solo cliente Helm (binario helm) (sin Tiller)\n     - Se ejecuta tal cual\n   - Los repositorios `local` o `stable` no se configuran por defecto\n   - El hook `crd-install` eliminado y reemplazado por el directorio `crds` en\n     el chart donde todos los CRDs definidos se instalarán antes de cualquier\n     renderizado del chart\n   - El valor de anotación de hook `test-failure` eliminado, y `test-success`\n     obsoleto. Use `test` en su lugar\n   - Comandos eliminados/reemplazados/añadidos:\n       - delete --> uninstall: elimina todo el historial del release por defecto\n         (anteriormente necesitaba `--purge`)\n       - fetch --> pull\n       - home (eliminado)\n       - init (eliminado)\n       - install: requiere nombre del release o argumento `--generate-name`\n       - inspect --> show\n       - reset (eliminado)\n       - serve (eliminado)\n       - template: argumento `-x`/`--execute` renombrado a `-s`/`--show-only`\n       - upgrade: Añadido argumento `--history-max` que limita el número máximo\n         de revisiones guardadas por release (0 para sin límite)\n   - La biblioteca Go de Helm 3 ha sufrido muchos cambios y es incompatible con\n     la biblioteca de Helm 2\n   - Los binarios de release ahora se alojan en `get.helm.sh`\n\n## Casos de Uso de Migración\n\nLos casos de uso de migración son los siguientes:\n\n1. Helm v2 y v3 gestionando el mismo clúster:\n   - Este caso de uso solo se recomienda si tiene la intención de eliminar\n     gradualmente Helm v2 y no necesita que v3 gestione ningún release\n     desplegado por v2. Todos los nuevos releases deben desplegarse con v3 y\n     los releases existentes desplegados con v2 solo deben actualizarse/eliminarse\n     con v2\n   - Helm v2 y v3 pueden gestionar el mismo clúster sin problemas. Las versiones\n     de Helm pueden instalarse en el mismo sistema o en sistemas separados\n   - Si instala Helm v3 en el mismo sistema, necesita realizar un paso adicional\n     para asegurar que ambas versiones del cliente puedan coexistir hasta que\n     esté listo para eliminar el cliente de Helm v2. Renombre o coloque el\n     binario de Helm v3 en una carpeta diferente para evitar conflictos\n   - De lo contrario, no hay conflictos entre ambas versiones debido a las\n     siguientes distinciones:\n     - El almacenamiento de releases (historial) de v2 y v3 son independientes\n       entre sí. Los cambios incluyen el recurso de Kubernetes para almacenamiento\n       y los metadatos del objeto release contenidos en el recurso. Los releases\n       también estarán en un namespace por usuario en lugar de usar el namespace\n       de Tiller (por ejemplo, el namespace por defecto de Tiller en v2 es\n       kube-system). v2 usa \"ConfigMaps\" o \"Secrets\" bajo el namespace de Tiller\n       con propiedad `TILLER`. v3 usa \"Secrets\" en el namespace del usuario con\n       propiedad `helm`. Los releases son incrementales tanto en v2 como en v3\n     - El único problema podría ser si se definen recursos de Kubernetes con\n       alcance de clúster (por ejemplo, `clusterroles.rbac`) en un chart. El\n       despliegue de v3 fallaría aunque sea único en el namespace porque los\n       recursos colisionarían\n     - La configuración de v3 ya no usa `$HELM_HOME` y usa la especificación de\n       directorios XDG en su lugar. También se crea sobre la marcha según sea\n       necesario. Por lo tanto, es independiente de la configuración de v2. Esto\n       aplica solo cuando ambas versiones están instaladas en el mismo sistema\n\n2. Migrar Helm v2 a Helm v3:\n   - Este caso de uso aplica cuando desea que Helm v3 gestione los releases\n     existentes de Helm v2\n   - Debe tenerse en cuenta que un cliente de Helm v2:\n     - puede gestionar de 1 a muchos clústeres de Kubernetes\n     - puede conectarse a de 1 a muchas instancias de Tiller para un clúster\n   - Esto significa que debe tener esto en cuenta al migrar, ya que los releases\n     se despliegan en los clústeres por Tiller y su namespace. Por lo tanto, debe\n     ser consciente de la migración para cada clúster y cada instancia de Tiller\n     que gestiona la instancia del cliente de Helm v2\n   - La ruta de migración de datos recomendada es la siguiente:\n     1. Hacer backup de los datos de v2\n     2. Migrar la configuración de Helm v2\n     3. Migrar los releases de Helm v2\n     4. Cuando esté seguro de que Helm v3 está gestionando todos los datos de\n        Helm v2 (para todos los clústeres e instancias de Tiller de la instancia\n        del cliente de Helm v2) según lo esperado, limpie los datos de Helm v2\n   - El proceso de migración está automatizado por el plugin\n     [2to3](https://github.com/helm/helm-2to3) de Helm v3\n\n## Referencia\n\n   - Plugin [2to3](https://github.com/helm/helm-2to3) de Helm v3\n   - [Artículo de blog](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)\n     que explica el uso del plugin `2to3` con ejemplos\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Política de Soporte de Versiones de Helm\"\ndescription: \"Describe la política de lanzamiento de parches de Helm, así como la diferencia máxima de versiones soportada entre Helm y Kubernetes.\"\n---\n\nEste documento describe la diferencia máxima de versiones soportada entre Helm y\nKubernetes.\n\n## Versiones Soportadas\n\nLas versiones de Helm se expresan como `x.y.z`, donde `x` es la versión mayor,\n`y` es la versión menor y `z` es la versión de parche, siguiendo la terminología\nde [Versionado Semántico](https://semver.org/spec/v2.0.0.html).\n\nEl proyecto Helm mantiene una rama de release para la versión menor más reciente.\nLas correcciones aplicables, incluyendo correcciones de seguridad, se incorporan\na la rama de release, dependiendo de la severidad y la viabilidad. Para más\ndetalles, consulte la [política de releases de Helm](/community/release_policy).\n\n## Diferencia de Versiones Soportada\n\nCuando se lanza una nueva versión de Helm, se compila contra una versión menor\nparticular de Kubernetes. Por ejemplo, Helm 3.0.0 interactúa con Kubernetes\nutilizando el cliente de Kubernetes 1.16.2, por lo que es compatible con\nKubernetes 1.16.\n\nA partir de Helm 3, se asume que Helm es compatible con versiones `n-3` de\nKubernetes contra las que fue compilado. Debido a los cambios de Kubernetes\nentre versiones menores, la política de soporte de Helm 2 es ligeramente más\nestricta, asumiendo compatibilidad con versiones `n-1` de Kubernetes.\n\nPor ejemplo, si está utilizando una versión de Helm 3 que fue compilada contra\nlas APIs del cliente de Kubernetes 1.17, entonces debería ser seguro usarla con\nKubernetes 1.17, 1.16, 1.15 y 1.14. Si está utilizando una versión de Helm 2 que\nfue compilada contra las APIs del cliente de Kubernetes 1.16, entonces debería\nser seguro usarla con Kubernetes 1.16 y 1.15.\n\nNo se recomienda usar Helm con una versión de Kubernetes más nueva que la versión\ncontra la que fue compilado, ya que Helm no ofrece garantías de compatibilidad\nhacia adelante.\n\nSi elige usar Helm con una versión de Kubernetes que no soporta, lo hace bajo\nsu propia responsabilidad.\n\nConsulte la siguiente tabla para determinar qué versión de Helm es compatible\ncon su clúster.\n\n| Versión de Helm | Versiones de Kubernetes Soportadas |\n|-----------------|------------------------------------|\n| 3.20.x          | 1.35.x - 1.32.x                    |\n| 3.19.x          | 1.34.x - 1.31.x                    |\n| 3.18.x          | 1.33.x - 1.30.x                    |\n| 3.17.x          | 1.32.x - 1.29.x                    |\n| 3.16.x          | 1.31.x - 1.28.x                    |\n| 3.15.x          | 1.30.x - 1.27.x                    |\n| 3.14.x          | 1.29.x - 1.26.x                    |\n| 3.13.x          | 1.28.x - 1.25.x                    |\n| 3.12.x          | 1.27.x - 1.24.x                    |\n| 3.11.x          | 1.26.x - 1.23.x                    |\n| 3.10.x          | 1.25.x - 1.22.x                    |\n| 3.9.x           | 1.24.x - 1.21.x                    |\n| 3.8.x           | 1.23.x - 1.20.x                    |\n| 3.7.x           | 1.22.x - 1.19.x                    |\n| 3.6.x           | 1.21.x - 1.18.x                    |\n| 3.5.x           | 1.20.x - 1.17.x                    |\n| 3.4.x           | 1.19.x - 1.16.x                    |\n| 3.3.x           | 1.18.x - 1.15.x                    |\n| 3.2.x           | 1.18.x - 1.15.x                    |\n| 3.1.x           | 1.17.x - 1.14.x                    |\n| 3.0.x           | 1.16.x - 1.13.x                    |\n| 2.16.x          | 1.16.x - 1.15.x                    |\n| 2.15.x          | 1.15.x - 1.14.x                    |\n| 2.14.x          | 1.14.x - 1.13.x                    |\n| 2.13.x          | 1.13.x - 1.12.x                    |\n| 2.12.x          | 1.12.x - 1.11.x                    |\n| 2.11.x          | 1.11.x - 1.10.x                    |\n| 2.10.x          | 1.10.x - 1.9.x                     |\n| 2.9.x           | 1.10.x - 1.9.x                     |\n| 2.8.x           | 1.9.x - 1.8.x                      |\n| 2.7.x           | 1.8.x - 1.7.x                      |\n| 2.6.x           | 1.7.x - 1.6.x                      |\n| 2.5.x           | 1.6.x - 1.5.x                      |\n| 2.4.x           | 1.6.x - 1.5.x                      |\n| 2.3.x           | 1.5.x - 1.4.x                      |\n| 2.2.x           | 1.5.x - 1.4.x                      |\n| 2.1.x           | 1.5.x - 1.4.x                      |\n| 2.0.x           | 1.4.x - 1.3.x                      |\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"Introducción\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"Cómo hacer\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"Temas\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Mejores Prácticas\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"Guía de Plantillas de Charts\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Comandos de Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"Comunidad\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"Preguntas Frecuentes\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/es/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: \"Política de Calendario de Releases\"\ndescription: \"Describe la política de calendario de releases de Helm.\"\n---\n\nPara beneficio de sus usuarios, Helm define y anuncia las fechas de release con\nanticipación. Este documento describe la política que rige el calendario de\nreleases de Helm.\n\n## Calendario de Releases\n\nPuede consultar un calendario público con los próximos releases de Helm\n[aquí](https://helm.sh/calendar/release).\n\n## Versionado Semántico\n\nLas versiones de Helm se expresan como `x.y.z`, donde `x` es la versión mayor,\n`y` es la versión menor y `z` es la versión de parche, siguiendo la terminología\nde [Versionado Semántico](https://semver.org/spec/v2.0.0.html).\n\n## Releases de Parche\n\nLos releases de parche proporcionan a los usuarios correcciones de errores y\ncorrecciones de seguridad. No contienen nuevas funcionalidades.\n\nNormalmente, se realizará un nuevo release de parche relacionado con el último\nrelease menor/mayor una vez al mes, el segundo miércoles de cada mes.\n\nSe puede realizar un release de parche para corregir una regresión de alta\nprioridad o un problema de seguridad en cualquier momento que sea necesario.\n\nUn release de parche se cancelará por cualquiera de las siguientes razones:\n- si no hay contenido nuevo desde el release anterior\n- si la fecha del release de parche cae dentro de la semana anterior al primer release candidate (RC1) de un próximo release menor\n- si la fecha del release de parche cae dentro de las cuatro semanas siguientes a un release menor\n\n## Releases Menores\n\nLos releases menores contienen correcciones de seguridad y errores, así como\nnuevas funcionalidades. Son compatibles con versiones anteriores en cuanto a la\nAPI y el uso del CLI.\n\nPara alinearse con los releases de Kubernetes, se realizará un release menor de\nHelm cada 4 meses (3 releases al año).\n\nSe pueden realizar releases menores adicionales si es necesario, pero esto no\nafectará el cronograma de un release futuro anunciado, a menos que falten menos\nde 7 días para el release anunciado.\n\nAl mismo tiempo que se publica un release, se anunciará la fecha del próximo\nrelease menor y se publicará en la página web principal de Helm.\n\n## Releases Mayores\n\nLos releases mayores contienen cambios incompatibles. Estos releases son poco\nfrecuentes, pero a veces son necesarios para permitir que Helm continúe\nevolucionando en nuevas direcciones importantes.\n\nLos releases mayores pueden ser difíciles de planificar. Con esto en mente, solo\nse elegirá y anunciará una fecha de release final una vez que esté disponible la\nprimera versión beta de dicho release.\n"
  },
  {
    "path": "i18n/es/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Proyecto Helm\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"Desarrollo\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"Comunidad\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"Código fuente\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"Eventos\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"Código de Conducta\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"Introducción\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Consejos y trucos de Charts\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"Desarrollando Charts\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"Buscar 800+ Charts\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"Guía de Contribución\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"Mantenedores\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"Reuniones Semanales\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"Comunidad de GitHub\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<a href=\\\"https://www.cncf.io/\\\">Somos un proyecto graduado de Cloud Native Computing Foundation.</a><br/>© Autores de Helm 2025. Documentación distribuida bajo <a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0.</a><br/>© 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 <a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">página de Uso de Marcas</a>.\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Logo de CNCF\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/es/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Logo de Helm\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"Documentación\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"Comunidad\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/fr/code.json",
    "content": "{\n  \"home.about.whatIsHelm\": {\n    \"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.\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"message\": \"Les Charts sont faciles à créer, versionner, partager et publier — alors commencez à utiliser Helm et arrêtez le copier-coller.\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Helm est un projet diplômé de la {cncfLink} et est maintenu par la {helmCommunityLink}.\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"communauté Helm\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"En savoir plus :\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Architecture de Helm\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"Guide de Démarrage Rapide\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"Vidéo : Une Introduction à Helm\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"Qu'est-ce que Helm ?\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"Prochaine Feature Release\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"Version :\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"Date :\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"Calendrier des Versions\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"Événements à Venir\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"Événements à Venir\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"Événements Passés\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"{meetLink} pour faire des démos et discuter des outils et projets. Les réunions de la communauté sont enregistrées et {youtubeLink}.\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"Ils se réunissent chaque semaine\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"partagées sur YouTube\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"Rencontres Développeur\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"Jeudis 9:30-10h (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"Ces réunions sont ouvertes à tous. Consultez le {communityRepoLink} pour les notes et détails.\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"dépôt de la communauté\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Discussion sur l'utilisation de Helm, le travail avec les charts et la résolution des erreurs courantes.\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Sujets concernant le développement de Helm, les PRs en cours, les versions, etc.\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Discussion pour les utilisateurs et contributeurs de Helm Charts.\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"{slackLink} pour rejoindre l'équipe Kubernetes Slack.\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"Demander l'accès ici\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"Contribuer\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"Helm accueille toujours les contributeurs avec plaisir !\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"Par où commencer ?\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Helm est un grand projet avec beaucoup d'utilisateurs et de contributeurs. Cela peut être beaucoup à assimiler !\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"Nous avons une liste de {goodFirstIssuesLink} si vous voulez aider mais ne savez pas par où commencer.\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"bonnes premières issues\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"Que dois-je faire ?\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"Avant de contribuer du code, veuillez lire notre {contributionGuideLink}. Il couvre les processus de création et de révision des pull requests.\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"Guide de Contribution\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"Après avoir écrit du code, veuillez {signYourCommitsLink} pour garantir que Helm respecte l'accord {dcoLink} utilisé par la {cncfLink}.\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"signer vos commits\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"Rejoignez la communauté !\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Plus d'informations sur le projet Helm et comment contribuer.\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"Le gestionnaire de paquets pour Kubernetes\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Helm est le meilleur moyen de trouver, partager et utiliser des logiciels conçus pour\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"Commencer\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"Télécharger Helm !\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"Installez Helm avec un gestionnaire de paquets, ou {downloadLink}.\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"téléchargez un binaire\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"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}.\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"documentation\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"l'installation\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"les instructions d'utilisation\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"Télécharger des Charts\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"Visitez {artifactHubLink} pour explorer des {helmChartsLink} de nombreux dépôts publics.\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"Helm charts\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"Gérer la Complexité\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"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.\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"Mises à Jour Faciles\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"Éliminez la douleur des mises à jour avec des upgrades sur place et des hooks personnalisés.\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"Partage Simple\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"Les Charts sont faciles à versionner, partager et héberger sur des serveurs publics ou privés.\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"Retours en Arrière\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"Utilisez {helmRollback} pour revenir facilement à une version antérieure d'une version.\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"Fonctionnalités\",\n    \"description\": \"Features section title\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"Cette page a planté.\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"Retour au début de la page\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"Archive\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"Archive\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"Pagination de la liste des articles du blog\",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"Nouvelles entrées\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"Anciennes entrées\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"Pagination des articles du blog\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"Article plus récent\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"Article plus ancien\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"Voir tous les tags\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"mode système\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"mode clair\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"mode sombre\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"Basculer entre le mode sombre et clair (actuellement {mode})\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"Fil d'Ariane\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"1 élément|{count} éléments\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"Pages de documentation\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"Précédent\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"Suivant\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"Un document tagué|{count} documents tagués\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged} avec \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"Ceci est la documentation de la prochaine version {versionLabel} de {siteTitle}.\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"Ceci est la documentation de {siteTitle} {versionLabel}, qui n'est plus activement maintenue.\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"Pour une documentation à jour, consultez la {latestVersionLink} ({versionLabel}).\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"dernière version\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"Version: {versionLabel}\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"Éditer cette page\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"Lien direct vers {heading}\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \" le {date}\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \" par {user}\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"Dernière mise à jour{atDate}{byUser}\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"Page introuvable\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"Versions\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"Tags :\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"attention\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"danger\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"info\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"remarque\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"astuce\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"attention\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"Fermer\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"Navigation article de blog récent\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"Développer la catégorie '{label}' de la barre latérale\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"Réduire la catégorie '{label}' de la barre latérale\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(s'ouvre dans un nouvel onglet)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"Principal\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"Nous n'avons pas trouvé ce que vous recherchez.\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"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é.\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"Langues\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"Sur cette page\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"Lire plus\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"En savoir plus sur {title}\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"Une minute de lecture|{readingTime} minutes de lecture\",\n    \"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)\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"Copier\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"Copié\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"Copier le code\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"Activer/désactiver le retour à la ligne\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"Page d'accueil\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"Barre latérale de documentation\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"Réduire le menu latéral\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"Réduire le menu latéral\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"Fermer la barre de navigation\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← Retour au menu principal\",\n    \"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)\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"Ouvrir/fermer la barre de navigation\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"Développer le menu déroulant\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"Réduire le menu déroulant\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"Déplier le menu latéral\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"Déplier le menu latéral\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"Un article|{count} articles\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"{nPosts} tagués avec « {tagName} »\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"Auteurs\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"Voir Tous les Auteurs\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"Cet auteur n'a pas encore écrit d'articles.\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"Page non répertoriée\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"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.\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"Page brouillon\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"Cette page est un brouillon. Elle ne sera visible qu'en développement et sera exclue de la version de production.\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"Réessayer\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"Aller au contenu principal\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"Tags\",\n    \"description\": \"The title of the tag list page\"\n  }\n}\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Blog\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"Blog\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"Tous les articles\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Utiliser Helm\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Commandes Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"Développer des Templates\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Meilleures Pratiques\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: Conventions générales\ndescription: Conventions générales pour les charts.\nsidebar_position: 1\n---\n\nCette partie du guide des bonnes pratiques explique les conventions générales.\n\n## Noms des charts\n\nLes noms de charts doivent être composés uniquement de lettres minuscules et de chiffres.\nLes mots _peuvent_ être séparés par des tirets (-) :\n\nExemples :\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nLes majuscules et les tirets bas (underscores) ne peuvent pas être utilisés dans les noms de charts.\nLes points ne devraient pas être utilisés dans les noms de charts.\n\n## Numéros de version\n\nDans la mesure du possible, Helm utilise [SemVer 2](https://semver.org) pour représenter\nles numéros de version. (Notez que les tags d'images Docker ne suivent pas nécessairement\nSemVer et sont donc considérés comme une exception regrettable à cette règle.)\n\nLorsque les versions SemVer sont stockées dans des labels Kubernetes, nous remplaçons\nconventionnellement le caractère `+` par un caractère `_`, car les labels n'autorisent pas\nle signe `+` comme valeur.\n\n## Formatage YAML\n\nLes fichiers YAML doivent être indentés avec _deux espaces_ (et jamais des tabulations).\n\n## Utilisation des mots Helm et Chart\n\nIl existe quelques conventions pour l'utilisation des mots _Helm_ et _helm_.\n\n- _Helm_ fait référence au projet dans son ensemble\n- `helm` fait référence à la commande côté client\n- Le terme `chart` n'a pas besoin d'être mis en majuscule, car ce n'est pas un nom propre\n- Cependant, `Chart.yaml` doit être mis en majuscule car le nom du fichier est sensible\n  à la casse\n\nEn cas de doute, utilisez _Helm_ (avec un 'H' majuscule).\n\n## Templates de chart et namespaces\n\nÉvitez de définir la propriété `namespace` dans la section `metadata` de vos templates\nde chart. Le namespace à appliquer aux templates rendus doit être spécifié lors de l'appel\nà un client Kubernetes via un flag comme `--namespace`. Helm rend vos templates tels quels\net les envoie au client Kubernetes, que ce soit Helm lui-même ou un autre programme\n(kubectl, flux, spinnaker, etc.).\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Définitions de ressources personnalisées\ndescription: Comment créer et utiliser des CRDs.\nsidebar_position: 7\n---\n\nCette partie du guide des bonnes pratiques traite de la création et de l'utilisation\ndes objets Custom Resource Definition.\n\nLorsque vous travaillez avec des Custom Resource Definitions (CRDs), il est important\nde distinguer deux éléments différents :\n\n- Il y a une déclaration de CRD. C'est le fichier YAML qui a le kind\n  `CustomResourceDefinition`\n- Ensuite, il y a les ressources qui _utilisent_ la CRD. Par exemple, si une CRD définit\n  `foo.example.com/v1`, toute ressource ayant `apiVersion: example.com/v1` et\n  le kind `Foo` est une ressource qui utilise cette CRD.\n\n## Installer une déclaration de CRD avant d'utiliser la ressource\n\nHelm est optimisé pour charger autant de ressources que possible dans Kubernetes le plus rapidement possible.\nPar conception, Kubernetes peut prendre un ensemble complet de manifestes et les mettre tous\nen ligne (c'est ce qu'on appelle la boucle de réconciliation).\n\nMais il y a une différence avec les CRDs.\n\nPour une CRD, la déclaration doit être enregistrée avant que les ressources de ce type\nde CRD puissent être utilisées. L'enregistrement peut prendre quelques secondes.\n\n### Méthode 1 : Laissez Helm s'en charger\n\nAvec l'arrivée de Helm 3, nous avons supprimé les anciens hooks `crd-install` au profit d'une\nméthodologie plus simple. Il existe maintenant un répertoire spécial appelé `crds` que vous pouvez\ncréer dans votre chart pour contenir vos CRDs. Ces CRDs ne sont pas traitées comme des templates, mais seront\ninstallées par défaut lors de l'exécution de `helm install` pour le chart. Si la CRD\nexiste déjà, elle sera ignorée avec un avertissement. Si vous souhaitez ignorer l'étape\nd'installation des CRDs, vous pouvez passer le flag `--skip-crds`.\n\n#### Quelques mises en garde (et explications)\n\nIl n'y a actuellement pas de support pour la mise à niveau ou la suppression des CRDs via Helm. Cette\ndécision a été prise explicitement après de nombreuses discussions avec la communauté en raison du danger\nde perte accidentelle de données. De plus, il n'existe actuellement pas de consensus communautaire\nsur la manière de gérer les CRDs et leur cycle de vie. À mesure que cela évoluera, Helm ajoutera\nun support pour ces cas d'utilisation.\n\nLe flag `--dry-run` de `helm install` et `helm upgrade` n'est actuellement pas\nsupporté pour les CRDs. L'objectif du \"Dry Run\" est de valider que la sortie du\nchart fonctionnera réellement si elle est envoyée au serveur. Mais les CRDs sont une modification\ndu comportement du serveur. Helm ne peut pas installer la CRD lors d'un dry run, donc le\nclient de découverte ne connaîtra pas cette Custom Resource (CR), et la validation\néchouera. Vous pouvez alternativement déplacer les CRDs dans leur propre chart ou utiliser `helm\ntemplate` à la place.\n\nUn autre point important à considérer dans la discussion sur le support des CRDs est la façon dont\nle rendu des templates est géré. L'un des inconvénients distincts de la\nméthode `crd-install` utilisée dans Helm 2 était l'impossibilité de valider correctement\nles charts en raison du changement de disponibilité des APIs (une CRD ajoute en fait une autre\nAPI disponible à votre cluster Kubernetes). Si un chart installait une CRD, `helm` n'avait\nplus un ensemble valide de versions d'API contre lesquelles travailler. C'est aussi la raison\nde la suppression du support du templating pour les CRDs. Avec la nouvelle méthode `crds` d'installation\ndes CRDs, nous nous assurons maintenant que `helm` dispose d'informations complètement valides sur\nl'état actuel du cluster.\n\n### Méthode 2 : Charts séparés\n\nUne autre façon de procéder est de mettre la définition de la CRD dans un chart, puis de mettre\ntoutes les ressources qui utilisent cette CRD dans _un autre_ chart.\n\nAvec cette méthode, chaque chart doit être installé séparément. Cependant, ce workflow\npeut être plus utile pour les opérateurs de cluster qui ont un accès administrateur au cluster.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: Dépendances\ndescription: Couvre les bonnes pratiques pour les dépendances de chart.\nsidebar_position: 4\n---\n\nCette partie du guide des bonnes pratiques couvre les `dependencies` déclarées dans\n`Chart.yaml`.\n\n## Versions\n\nLorsque 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 :\n\n```yaml\nversion: ~1.2.3\n```\n\nCela 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`\n\nPour la syntaxe complète de correspondance des versions, veuillez consulter la [documentation semver](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Versions préliminaires\n\nLes contraintes de version ci-dessus ne correspondent pas aux versions préliminaires (pre-release).\nPar exemple, `version: ~1.2.3` correspondra à `version: ~1.2.4` mais pas à `version: ~1.2.3-1`.\nLa syntaxe suivante permet une correspondance pour les pre-release ainsi qu'au niveau du patch :\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### URLs de dépôt\n\nLorsque c'est possible, utilisez des URLs de dépôt en `https://`, puis en `http://` comme alternative.\n\nSi 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.\n\nLes 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.\n\nLors 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.\n\nSi 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.\n\n## Conditions et Tags\n\nDes 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`.\n\nLa forme préférée d'une condition est :\n\n```yaml\ncondition: somechart.enabled\n```\n\nOù `somechart` est le nom du chart de la dépendance.\n\nLorsque plusieurs sous-charts (dépendances) fournissent ensemble une fonctionnalité optionnelle ou interchangeable, ces charts doivent partager les mêmes tags.\n\nPar 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 :\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nCela permet à l'utilisateur d'activer ou de désactiver cette fonctionnalité avec un seul tag.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: Labels et annotations\ndescription: Couvre les bonnes pratiques pour l'utilisation des labels et annotations dans votre chart.\nsidebar_position: 5\n---\n\nCette partie du guide des bonnes pratiques traite de l'utilisation des labels et\nannotations dans votre chart.\n\n## Est-ce un label ou une annotation ?\n\nUn élément de métadonnées doit être un label dans les conditions suivantes :\n\n- Il est utilisé par Kubernetes pour identifier cette ressource\n- Il est utile de l'exposer aux opérateurs pour permettre l'interrogation du système.\n\nPar exemple, nous suggérons d'utiliser `helm.sh/chart: NAME-VERSION` comme label afin\nque les opérateurs puissent facilement trouver toutes les instances d'un chart particulier.\n\nSi un élément de métadonnées n'est pas utilisé pour l'interrogation, il devrait être\ndéfini comme une annotation.\n\nLes hooks Helm sont toujours des annotations.\n\n## Labels standards\n\nLe tableau suivant définit les labels courants utilisés par les charts Helm. Helm lui-même\nn'exige jamais qu'un label particulier soit présent. Les labels marqués REC sont\nrecommandés et **devraient** être placés sur un chart pour une cohérence globale.\nCeux marqués OPT sont optionnels. Ils sont idiomatiques ou couramment utilisés, mais\nne sont pas fréquemment utilisés à des fins opérationnelles.\n\nNom|Statut|Description\n-----|------|----------\n`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.\n`helm.sh/chart` | REC | Doit être le nom et la version du chart : `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`.\n`app.kubernetes.io/managed-by` | REC | Doit toujours être défini à `{{ .Release.Service }}`. Permet de trouver tout ce qui est géré par Helm.\n`app.kubernetes.io/instance` | REC | Doit être `{{ .Release.Name }}`. Aide à différencier les différentes instances de la même application.\n`app.kubernetes.io/version` | OPT | La version de l'application, peut être défini à `{{ .Chart.AppVersion }}`.\n`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`.\n`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.\n\nPour plus d'informations sur les labels Kubernetes préfixés par `app.kubernetes.io`,\nconsultez la [documentation Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pods et PodTemplates\ndescription: Bonnes pratiques pour le formatage des sections Pod et PodTemplate dans les manifestes de chart.\nsidebar_position: 6\n---\n\nCette partie du guide des bonnes pratiques aborde le formatage des sections Pod et\nPodTemplate dans les manifestes de chart.\n\nLa liste suivante (non exhaustive) de ressources utilise des PodTemplates :\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Images\n\nUne image de conteneur doit utiliser un tag fixe ou le SHA de l'image. Elle ne doit pas\nutiliser les tags `latest`, `head`, `canary`, ou d'autres tags conçus pour être\n« flottants ».\n\nLes images _peuvent_ être définies dans le fichier `values.yaml` pour faciliter le\nremplacement des images.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nUne image et un tag _peuvent_ être définis dans `values.yaml` comme deux champs séparés :\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` définit `imagePullPolicy` sur `IfNotPresent` par défaut en ajoutant\nce qui suit dans votre `deployment.yaml` :\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nEt dans `values.yaml` :\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nDe la même façon, Kubernetes définit par défaut `imagePullPolicy` sur `IfNotPresent` s'il\nn'est pas défini du tout. Si vous souhaitez une valeur autre que `IfNotPresent`, modifiez\nsimplement la valeur dans `values.yaml` pour la valeur souhaitée.\n\n## Les PodTemplates doivent déclarer des sélecteurs\n\nToutes les sections PodTemplate doivent spécifier un sélecteur. Par exemple :\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nC'est une bonne pratique car elle établit clairement la relation entre l'ensemble et\nle pod.\n\nMais cela est encore plus important pour les ressources comme Deployment. Sans cela,\n_l'ensemble complet_ des labels est utilisé pour sélectionner les pods correspondants,\nce qui peut poser problème si vous utilisez des labels qui changent, comme la version\nou la date de release.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: Contrôle d'accès basé sur les rôles\ndescription: Traite de la création et du formatage des ressources RBAC dans les manifestes de chart.\nsidebar_position: 8\n---\n\nCette partie du guide des bonnes pratiques traite de la création et du formatage des\nressources RBAC dans les manifestes de chart.\n\nLes ressources RBAC sont :\n\n- ServiceAccount (namespaced)\n- Role (namespaced)\n- ClusterRole\n- RoleBinding (namespaced)\n- ClusterRoleBinding\n\n## Configuration YAML\n\nLa configuration de RBAC et de ServiceAccount doit se faire sous des clés séparées. Ce sont\ndes concepts distincts. Les séparer dans le YAML permet de les distinguer clairement.\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\nCette structure peut être étendue pour des charts plus complexes nécessitant plusieurs\nServiceAccounts.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## Les ressources RBAC doivent être créées par défaut\n\n`rbac.create` doit être une valeur booléenne contrôlant si les ressources RBAC sont\ncréées. La valeur par défaut doit être `true`. Les utilisateurs qui souhaitent gérer eux-mêmes\nles contrôles d'accès RBAC peuvent définir cette valeur à `false` (dans ce cas, voir ci-dessous).\n\n## Utilisation des ressources RBAC\n\n`serviceAccount.name` doit être défini avec le nom du ServiceAccount à utiliser\npar les ressources soumises au contrôle d'accès créées par le chart.\n\n- Si `serviceAccount.create` est true, un ServiceAccount avec ce nom doit être créé.\n- Si le nom n'est pas défini, un nom est généré en utilisant le template `fullname`.\n- Si `serviceAccount.create` est false, le ServiceAccount ne doit pas être créé, mais il doit\n  tout de même être associé aux mêmes ressources afin que les ressources RBAC créées\n  manuellement ultérieurement fonctionnent correctement.\n- Si `serviceAccount.create` est false et que le nom n'est pas spécifié, le\n  ServiceAccount par défaut est utilisé.\n\nLe helper template suivant doit être utilisé pour le ServiceAccount.\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: Templates\ndescription: Un examen approfondi des bonnes pratiques concernant les templates.\nsidebar_position: 3\n---\n\nCette partie du guide des bonnes pratiques se concentre sur les templates.\n\n## Structure de `templates/`\n\nLe répertoire `templates/` doit être structuré comme suit :\n\n- Les fichiers template doivent avoir l'extension `.yaml` s'ils produisent une sortie YAML.\n  L'extension `.tpl` peut être utilisée pour les fichiers template qui ne produisent pas\n  de contenu formaté.\n- Les noms de fichiers template doivent utiliser la notation avec tirets (`my-example-configmap.yaml`),\n  et non le camelCase.\n- Chaque définition de ressource doit être dans son propre fichier template.\n- Les noms de fichiers template doivent refléter le type de ressource dans le nom. Par exemple :\n  `foo-pod.yaml`, `bar-svc.yaml`\n\n## Noms des templates définis\n\nLes templates définis (templates créés à l'intérieur d'une directive `{{ define }}`) sont\nglobalement accessibles. Cela signifie qu'un chart et tous ses sous-charts auront\naccès à tous les templates créés avec `{{ define }}`.\n\nPour cette raison, _tous les noms de templates définis doivent être préfixés par un espace de noms._\n\nCorrect :\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nIncorrect :\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\n\nIl est fortement recommandé de créer de nouveaux charts via la commande `helm create`\ncar les noms de templates sont automatiquement définis selon cette bonne pratique.\n\n## Formatage des templates\n\nLes templates doivent être indentés avec _deux espaces_ (jamais des tabulations).\n\nLes directives de template doivent avoir un espace après les accolades ouvrantes et avant\nles accolades fermantes :\n\nCorrect :\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nIncorrect :\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nLes templates doivent supprimer les espaces blancs lorsque c'est possible :\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nLes blocs (tels que les structures de contrôle) peuvent être indentés pour indiquer le flux\ndu code template.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nCependant, comme YAML est un langage orienté espaces blancs, il n'est souvent pas possible\npour l'indentation du code de suivre cette convention.\n\n## Espaces blancs dans les templates générés\n\nIl est préférable de limiter la quantité d'espaces blancs dans les templates générés\nau minimum. En particulier, de nombreuses lignes vides ne doivent pas apparaître les unes\nà côté des autres. Cependant, des lignes vides occasionnelles (en particulier entre les sections logiques)\nsont acceptables.\n\nCeci est idéal :\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nCeci est acceptable :\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nMais ceci doit être évité :\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Commentaires (Commentaires YAML vs. Commentaires de template)\n\nYAML et les templates Helm disposent tous deux de marqueurs de commentaires.\n\nCommentaires YAML :\n```yaml\n# Ceci est un commentaire\ntype: sprocket\n```\n\nCommentaires de template :\n```yaml\n{{- /*\nCeci est un commentaire.\n*/}}\ntype: frobnitz\n```\n\nLes commentaires de template doivent être utilisés pour documenter les fonctionnalités d'un template,\ncomme expliquer un template défini :\n\n```yaml\n{{- /*\nmychart.shortname provides a 6 char truncated version of the release name.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nÀ l'intérieur des templates, les commentaires YAML peuvent être utilisés lorsqu'il est utile\nque les utilisateurs Helm puissent (éventuellement) voir les commentaires lors du débogage.\n\n```yaml\n# This may cause problems if the value is more than 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nLe commentaire ci-dessus est visible lorsque l'utilisateur exécute `helm install --debug`, tandis que\nles commentaires spécifiés dans les sections `{{- /* */}}` ne le sont pas.\n\nFaites 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.\n\nPar 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.\n\nCorrect : `helm template` ne rend pas ce bloc\n```yaml\n{{- /*\n# This may cause problems if the value is more than 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nIncorrect : `helm template` retourne `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n```yaml\n# This may cause problems if the value is more than 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nConsultez [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.\n\n## Utilisation de JSON dans les templates et la sortie des templates\n\nYAML est un sur-ensemble de JSON. Dans certains cas, utiliser une syntaxe JSON peut être\nplus lisible que d'autres représentations YAML.\n\nPar exemple, ce YAML est plus proche de la méthode YAML normale pour exprimer des listes :\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nMais il est plus facile à lire lorsqu'il est condensé dans un style de liste JSON :\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nUtiliser JSON pour améliorer la lisibilité est une bonne pratique. Cependant, la syntaxe JSON ne doit pas\nêtre utilisée pour représenter des constructions plus complexes.\n\nLorsque vous travaillez avec du JSON pur intégré dans du YAML (comme la configuration\nde conteneur init), il est bien sûr approprié d'utiliser le format JSON.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: Values\ndescription: Se concentre sur la façon de structurer et d'utiliser vos values.\nsidebar_position: 2\n---\n\nCette 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.\n\n## Conventions de nommage\n\nLes noms de variables doivent commencer par une lettre minuscule, et les mots doivent être séparés en camelCase :\n\nCorrect :\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nIncorrect :\n\n```yaml\nChicken: true  # les majuscules initiales peuvent entrer en conflit avec les variables intégrées\nchicken-noodle-soup: true # n'utilisez pas de tirets dans le nom\n```\n\nNotez 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`.\n\n## Values plates ou imbriquées\n\nYAML est un format flexible, et les values peuvent être profondément imbriquées ou aplaties.\n\nImbriquées :\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nPlates :\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nDans 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.\n\nPour une sécurité optimale, une value imbriquée doit être vérifiée à chaque niveau :\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nPour 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.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\nLorsqu'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é.\n\n## Rendre les types explicites\n\nLes 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.\n\nLa 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_.\n\nSouvent, 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.\n\nDans 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.\n\n## Considérez comment les utilisateurs utiliseront vos values\n\nIl existe trois sources potentielles de values :\n\n- Le fichier `values.yaml` d'un chart\n- Un fichier de values fourni par `helm install -f` ou `helm upgrade -f`\n- Les values passées via les options `--set` ou `--set-string` de `helm install` ou `helm upgrade`\n\nLors 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`.\n\nÉ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`_.\n\nPour cette raison, il est souvent préférable de structurer votre fichier de values en utilisant des maps.\n\nDifficile à utiliser avec `--set` :\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nL'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.\n\nFacile à utiliser :\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nAccéder au port de foo est beaucoup plus évident : `--set servers.foo.port=80`.\n\n## Documenter `values.yaml`\n\nChaque 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.\n\nIncorrect :\n\n```yaml\n# le nom d'hôte du serveur web\nserverHost: example\nserverPort: 9191\n```\n\nCorrect :\n\n```yaml\n# serverHost est le nom d'hôte du serveur web\nserverHost: example\n# serverPort est le port d'écoute HTTP du serveur web\nserverPort: 9191\n```\n\nCommencer 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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Accéder aux fichiers dans les templates\ndescription: Comment accéder aux fichiers depuis un template.\nsidebar_position: 10\n---\n\nDans 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.\n\nHelm 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 :\n\n- Vous pouvez ajouter des fichiers supplémentaires à votre chart Helm. Ces fichiers seront inclus dans le package.\n  Attention toutefois : les charts doivent faire moins de 1 Mo en raison des limitations de stockage des objets Kubernetes.\n- Certains fichiers ne sont pas accessibles via l'objet `.Files`, généralement pour des raisons de sécurité.\n  - Les fichiers dans `templates/` ne sont pas accessibles.\n  - Les fichiers exclus via `.helmignore` ne sont pas accessibles.\n  - 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.\n- 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`.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Exemple de base](#exemple-de-base)\n- [Fonctions d'aide pour les chemins](#fonctions-daide-pour-les-chemins)\n- [Motifs glob](#motifs-glob)\n- [Fonctions utilitaires pour ConfigMap et Secrets](#fonctions-utilitaires-pour-configmap-et-secrets)\n- [Encodage](#encodage)\n- [Lignes](#lignes)\n\n<!-- tocstop -->\n\n## Exemple de base\n\nCes 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/`.\n\n`config1.toml` :\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml` :\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml` :\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nChacun 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.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nCe 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 . }}`.\n\nL'exécution de ce template produira un seul ConfigMap contenant le contenu des trois fichiers :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Fonctions d'aide pour les chemins\n\nLorsque 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.\n\nLes fonctions importées sont :\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Motifs glob\n\nÀ 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).\n\n`.Glob` retourne un type `Files`, vous pouvez donc appeler n'importe quelle méthode de `Files` sur l'objet retourné.\n\nPar exemple, imaginez la structure de répertoires suivante :\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nVous avez plusieurs options avec les Globs :\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nOu\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## Fonctions utilitaires pour ConfigMap et Secrets\n\n(Disponible depuis Helm 2.0.2)\n\nIl 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`.\n\nPour une meilleure organisation, il est particulièrement utile d'utiliser ces méthodes en conjonction avec la méthode `Glob`.\n\nAvec la structure de répertoires de l'exemple [Glob](#motifs-glob) ci-dessus :\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Encodage\n\nVous pouvez importer un fichier et demander au template de l'encoder en base64 pour garantir une transmission réussie :\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nLe code ci-dessus prendra le même fichier `config1.toml` utilisé précédemment et l'encodera :\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Lignes\n\nParfois, il est souhaitable d'accéder à chaque ligne d'un fichier dans votre template. Nous fournissons une méthode `Lines` pratique pour cela.\n\nVous pouvez parcourir `Lines` en utilisant une fonction `range` :\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nIl 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`.\n\nCette 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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Objets intégrés\ndescription: Les objets intégrés disponibles dans les templates.\nsidebar_position: 3\n---\n\nLes 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.\n\nLes 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.\n\nDans 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.\n\n- `Release` : Cet objet décrit la release elle-même. Il contient plusieurs objets :\n  - `Release.Name` : Le nom de la release\n  - `Release.Namespace` : Le namespace dans lequel la release sera déployée (si le manifeste ne le remplace pas)\n  - `Release.IsUpgrade` : Cette valeur est définie à `true` si l'opération en cours est une mise à niveau ou un rollback.\n  - `Release.IsInstall` : Cette valeur est définie à `true` si l'opération en cours est une installation.\n  - `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.\n  - `Release.Service` : Le service qui effectue le rendu du template actuel. Dans Helm, c'est toujours `Helm`.\n- `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.\n- `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`.\n  - Les champs disponibles sont listés dans le [Guide des Charts](/topics/charts.md#the-chartyaml-file)\n- `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`.\n- `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.\n  - `Files.Get` est une fonction pour obtenir un fichier par son nom (`.Files.Get config.ini`)\n  - `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.\n  - `Files.Glob` est une fonction qui retourne une liste de fichiers dont les noms correspondent au motif glob donné.\n  - `Files.Lines` est une fonction qui lit un fichier ligne par ligne. Utile pour itérer sur chaque ligne d'un fichier.\n  - `Files.AsSecrets` est une fonction qui retourne le contenu des fichiers encodé en Base 64.\n  - `Files.AsConfig` est une fonction qui retourne le contenu des fichiers sous forme de map YAML.\n- `Capabilities` : Cet objet fournit des informations sur les fonctionnalités prises en charge par le cluster Kubernetes.\n  - `Capabilities.APIVersions` est un ensemble de versions.\n  - `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.\n  - `Capabilities.KubeVersion` et `Capabilities.KubeVersion.Version` représentent la version de Kubernetes.\n  - `Capabilities.KubeVersion.Major` est la version majeure de Kubernetes.\n  - `Capabilities.KubeVersion.Minor` est la version mineure de Kubernetes.\n  - `Capabilities.HelmVersion` est l'objet contenant les détails de la version de Helm, c'est la même sortie que `helm version`.\n  - `Capabilities.HelmVersion.Version` est la version actuelle de Helm au format semver.\n  - `Capabilities.HelmVersion.GitCommit` est le sha1 git de Helm.\n  - `Capabilities.HelmVersion.GitTreeState` est l'état de l'arborescence git de Helm.\n  - `Capabilities.HelmVersion.GoVersion` est la version du compilateur Go utilisé.\n- `Template` : Contient des informations sur le template en cours d'exécution\n  - `Template.Name` : Le chemin qualifié vers le template actuel (par exemple, `mychart/templates/mytemplate.yaml`)\n  - `Template.BasePath` : Le chemin qualifié vers le répertoire templates du chart actuel (par exemple, `mychart/templates`).\n\nLes 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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Structures de contrôle\ndescription: Un aperçu rapide des structures de contrôle dans les templates.\nsidebar_position: 7\n---\n\nLes 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 :\n\n- `if`/`else` pour créer des blocs conditionnels\n- `with` pour spécifier une portée\n- `range`, qui fournit une boucle de type « for each »\n\nEn plus de celles-ci, il fournit quelques actions pour déclarer et utiliser des segments de templates nommés :\n\n- `define` déclare un nouveau template nommé à l'intérieur de votre template\n- `template` importe un template nommé\n- `block` déclare un type spécial de zone de template remplissable\n\nDans cette section, nous parlerons de `if`, `with` et `range`. Les autres sont couverts dans la section « Templates nommés » plus loin dans ce guide.\n\n## If/Else\n\nLa 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`.\n\nLa structure de base d'une condition ressemble à ceci :\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\nRemarquez 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.\n\nUn pipeline est évalué comme _false_ si la valeur est :\n\n- un booléen false\n- un zéro numérique\n- une chaîne vide\n- un `nil` (vide ou null)\n- une collection vide (`map`, `slice`, `tuple`, `dict`, `array`)\n\nDans toutes les autres conditions, la condition est vraie.\n\nAjoutons une condition simple à notre ConfigMap. Nous ajouterons un autre paramètre si la boisson est définie sur coffee :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nPuisque 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 :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Contrôle des espaces blancs\n\nEn 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 :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nInitialement, cela semble correct. Mais si nous l'exécutons via le moteur de template, nous obtiendrons un résultat malheureux :\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nQue s'est-il passé ? Nous avons généré du YAML incorrect à cause des espaces blancs ci-dessus.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` est mal indenté. Réduisons l'indentation de cette ligne et relançons :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nLorsque nous envoyons cela, nous obtiendrons du YAML valide, mais qui a toujours l'air un peu étrange :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nRemarquez 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.\n\nYAML attribue une signification aux espaces blancs, donc la gestion des espaces blancs devient assez importante. Heureusement, les templates Helm ont quelques outils pour aider.\n\nPremiè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 !_\n\n> Assurez-vous qu'il y a un espace entre le `-` et le reste de votre directive.\n> `{{- 3 }}` signifie « supprimer les espaces blancs à gauche et afficher 3 » tandis que `{{-3 }}` signifie « afficher -3 ».\n\nEn utilisant cette syntaxe, nous pouvons modifier notre template pour nous débarrasser de ces nouvelles lignes :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nJuste 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é\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nEn gardant cela à l'esprit, nous pouvons exécuter notre template via Helm et voir le résultat :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nSoyez prudent avec les modificateurs de suppression. Il est facile de faire accidentellement des choses comme ceci :\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nCela produira `food: \"PIZZA\"mug: \"true\"` car cela a consommé les nouvelles lignes des deux côtés.\n\n> 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)\n\nEnfin, 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\" }}`).\n\n## Modification de la portée avec `with`\n\nLa 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.\n\nLa syntaxe de `with` est similaire à une simple instruction `if` :\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\nLes 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` :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nNotez 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.\n\nRemarquez 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 }}`.\n\nMais 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 :\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nCela 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 }}`.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nOu, 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 :\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nAprès avoir examiné `range`, nous examinerons les variables de template, qui offrent une solution au problème de portée ci-dessus.\n\n## Boucle avec l'action `range`\n\nDe 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`.\n\nPour commencer, ajoutons une liste de garnitures de pizza à notre fichier `values.yaml` :\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nMaintenant, nous avons une liste (appelée `slice` dans les templates) de `pizzaToppings`. Nous pouvons modifier notre template pour imprimer cette liste dans notre ConfigMap :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nNous 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 :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nExaminons 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.\n\nNous 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 :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nMaintenant, 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.\n\n> 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.\n\nParfois, 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é.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nCe qui précède produira ceci :\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nEn 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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Annexe : Types de données Go et Templates\"\ndescription: Un bref aperçu des variables dans les templates.\nsidebar_position: 16\n---\n\nLe 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 :\n\n- string : une chaîne de texte\n- bool : un `true` ou `false`\n- int : une valeur entière (il existe également des variantes signées et non signées sur 8, 16, 32 et 64 bits)\n- float64 : une valeur à virgule flottante sur 64 bits (il existe également des variantes sur 8, 16 et 32 bits)\n- un slice d'octets (`[]byte`), souvent utilisé pour stocker des données (potentiellement) binaires\n- struct : un objet avec des propriétés et des méthodes\n- un slice (liste indexée) de l'un des types précédents\n- une map indexée par des chaînes (`map[string]interface{}`) où la valeur est l'un des types précédents\n\nIl 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`.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: Débogage des templates\ndescription: Dépannage des charts dont le déploiement échoue.\nsidebar_position: 13\n---\n\nLe 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.\n\nVoici quelques commandes utiles pour le débogage.\n\n- `helm lint` est votre outil de référence pour vérifier que votre chart respecte les bonnes pratiques\n- `helm template --debug` permet de tester le rendu des templates de chart localement.\n- `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.\n- `helm get manifest` : C'est un bon moyen de voir quels templates sont installés sur le serveur.\n\nLorsque 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` :\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\nLe code ci-dessus sera rendu et retourné avec les commentaires intacts :\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\nCela permet de visualiser rapidement le contenu généré sans être bloqué par des erreurs d'analyse YAML.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: Liste des fonctions de template\ndescription: Une liste des fonctions de template disponibles dans Helm\nsidebar_position: 6\n---\n\nHelm inclut de nombreuses fonctions de template que vous pouvez utiliser dans vos templates.\nElles sont répertoriées ici et classées dans les catégories suivantes :\n\n* [Fonctions cryptographiques et de sécurité](#fonctions-cryptographiques-et-de-sécurité)\n* [Date](#fonctions-de-date)\n* [Dictionnaires](#dictionnaires-et-fonctions-dict)\n* [Encodage](#fonctions-dencodage)\n* [Chemins de fichiers](#fonctions-de-chemin-de-fichier)\n* [Kubernetes et Chart](#fonctions-kubernetes-et-chart)\n* [Logique et contrôle de flux](#fonctions-de-logique-et-de-contrôle-de-flux)\n* [Listes](#listes-et-fonctions-de-liste)\n* [Mathématiques](#fonctions-mathématiques)\n* [Mathématiques à virgule flottante](#fonctions-mathématiques-à-virgule-flottante)\n* [Réseau](#fonctions-réseau)\n* [Réflexion](#fonctions-de-réflexion)\n* [Expressions régulières](#expressions-régulières)\n* [Versions sémantiques](#fonctions-de-version-sémantique)\n* [Chaînes de caractères](#fonctions-de-chaînes-de-caractères)\n* [Conversion de types](#fonctions-de-conversion-de-types)\n* [URL](#fonctions-url)\n* [UUID](#fonctions-uuid)\n\n## Fonctions de logique et de contrôle de flux\n\nHelm inclut de nombreuses fonctions de logique et de contrôle de flux, notamment [and](#and),\n[coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq),\n[fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne),\n[not](#not), [or](#or), et [required](#required).\n\n### and\n\nRetourne le ET logique de deux arguments ou plus\n(le premier argument vide, ou le dernier argument).\n\n```\nand .Arg1 .Arg2\n```\n\n### or\n\nRetourne le OU logique de deux arguments ou plus\n(le premier argument non vide, ou le dernier argument).\n\n```\nor .Arg1 .Arg2\n```\n\n### not\n\nRetourne la négation logique de son argument.\n\n```\nnot .Arg\n```\n\n### eq\n\nRetourne l'égalité booléenne des arguments (par exemple, Arg1 == Arg2).\n\n```\neq .Arg1 .Arg2\n```\n\n### ne\n\nRetourne l'inégalité booléenne des arguments (par exemple, Arg1 != Arg2)\n\n```\nne .Arg1 .Arg2\n```\n\n### lt\n\nRetourne vrai si le premier argument est inférieur au second. Retourne faux\nsinon (par exemple, Arg1 < Arg2).\n\n```\nlt .Arg1 .Arg2\n```\n\n### le\n\nRetourne vrai si le premier argument est inférieur ou égal au\nsecond. Retourne faux sinon (par exemple, Arg1 <= Arg2).\n\n```\nle .Arg1 .Arg2\n```\n\n### gt\n\nRetourne vrai si le premier argument est supérieur au second. Retourne faux\nsinon (par exemple, Arg1 > Arg2).\n\n```\ngt .Arg1 .Arg2\n```\n\n### ge\n\nRetourne vrai si le premier argument est supérieur ou égal au\nsecond. Retourne faux sinon (par exemple, Arg1 >= Arg2).\n\n```\nge .Arg1 .Arg2\n```\n\n### default\n\nPour définir une valeur par défaut simple, utilisez `default` :\n\n```\ndefault \"foo\" .Bar\n```\n\nDans l'exemple ci-dessus, si `.Bar` s'évalue à une valeur non vide, elle sera utilisée. Sinon,\n`foo` sera retourné à la place.\n\nLa définition de « vide » dépend du type :\n\n- Numérique : 0\n- Chaîne : \"\"\n- Listes : `[]`\n- Dicts : `{}`\n- Booléen : `false`\n- Et toujours `nil` (aka null)\n\nPour les structures, il n'y a pas de définition de vide, donc une structure ne retournera jamais\nla valeur par défaut.\n\n### required\n\nSpécifiez les valeurs qui doivent être définies avec `required` :\n\n```\nrequired \"A valid foo is required!\" .Bar\n```\n\nSi `.Bar` est vide ou non défini (voir [default](#default) pour savoir comment cela est \névalué), le template ne sera pas rendu et retournera le message d'erreur \nfourni à la place.\n\n### empty\n\nLa fonction `empty` retourne `true` si la valeur donnée est considérée comme vide, et\n`false` sinon. Les valeurs vides sont listées dans la section `default`.\n\n```\nempty .Foo\n```\n\nNotez que dans les conditionnels des templates Go, le vide est calculé pour vous. Ainsi,\nvous avez rarement besoin de `if not empty .Foo`. Utilisez simplement `if .Foo`.\n\n### fail\n\nRetourne inconditionnellement une chaîne vide (`string`) et une erreur (`error`) avec le texte\nspécifié. Ceci est utile dans les scénarios où d'autres conditionnels ont déterminé que\nle rendu du template doit échouer.\n\n```\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\nLa fonction `coalesce` prend une liste de valeurs et retourne la première valeur non vide.\n\n```\ncoalesce 0 1 2\n```\n\nL'exemple ci-dessus retourne `1`.\n\nCette fonction est utile pour parcourir plusieurs variables ou valeurs :\n\n```\ncoalesce .name .parent.name \"Matt\"\n```\n\nL'exemple ci-dessus vérifiera d'abord si `.name` est vide. Si ce n'est pas le cas, il\nretournera cette valeur. Si c'est vide, `coalesce` évaluera `.parent.name` pour\nvérifier s'il est vide. Enfin, si `.name` et `.parent.name` sont tous deux vides, il retournera\n`Matt`.\n\n### ternary\n\nLa fonction `ternary` prend deux valeurs et une valeur de test. Si la valeur de test est\nvraie, la première valeur sera retournée. Si la valeur de test est vide, la seconde\nvaleur sera retournée. Ceci est similaire à l'opérateur ternaire en C et autres langages de programmation.\n\n#### Valeur de test vraie\n\n```\nternary \"foo\" \"bar\" true\n```\n\nou\n\n```\ntrue | ternary \"foo\" \"bar\"\n```\n\nL'exemple ci-dessus retourne `\"foo\"`.\n\n#### Valeur de test fausse\n\n```\nternary \"foo\" \"bar\" false\n```\n\nou\n\n```\nfalse | ternary \"foo\" \"bar\"\n```\n\nL'exemple ci-dessus retourne `\"bar\"`.\n\n## Fonctions de chaînes de caractères\n\nHelm inclut les fonctions de chaînes suivantes : [abbrev](#abbrev),\n[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat),\n[contains](#contains), [hasPrefix](#hasprefix-et-hassuffix),\n[hasSuffix](#hasprefix-et-hassuffix), [indent](#indent), [initials](#initials),\n[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent),\n[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf),\n[println](#println), [quote](#quote-et-squote),\n[randAlpha](#randalphanum-randalpha-randnumeric-et-randascii),\n[randAlphaNum](#randalphanum-randalpha-randnumeric-et-randascii),\n[randAscii](#randalphanum-randalpha-randnumeric-et-randascii),\n[randNumeric](#randalphanum-randalpha-randnumeric-et-randascii),\n[repeat](#repeat), [replace](#replace), [shuffle](#shuffle),\n[snakecase](#snakecase), [squote](#quote-et-squote), [substr](#substr),\n[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall),\n[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc),\n[untitle](#untitle), [upper](#upper), [wrap](#wrap), et [wrapWith](#wrapwith).\n\n### print\n\nRetourne une chaîne à partir de la combinaison de ses parties.\n\n```\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\nLes types qui ne sont pas des chaînes sont convertis en chaînes lorsque c'est possible.\n\nNotez que lorsque deux arguments côte à côte ne sont pas des chaînes, un espace est ajouté\nentre eux.\n\n### println\n\nFonctionne de la même manière que [print](#print) mais ajoute une nouvelle ligne à la fin.\n\n### printf\n\nRetourne une chaîne basée sur une chaîne de formatage et les arguments à lui passer dans\nl'ordre.\n\n```\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\nLe caractère de substitution à utiliser dépend du type de l'argument passé.\nCela inclut :\n\nUsage général :\n\n* `%v` la valeur dans un format par défaut\n  * lors de l'impression de dicts, le flag plus (%+v) ajoute les noms de champs\n* `%%` un signe pourcentage littéral ; ne consomme aucune valeur\n\nBooléen :\n\n* `%t` le mot true ou false\n\nEntier :\n\n* `%b` base 2\n* `%c` le caractère représenté par le point de code Unicode correspondant\n* `%d` base 10\n* `%o` base 8\n* `%O` base 8 avec le préfixe 0o\n* `%q` un caractère littéral entre guillemets simples, échappé de manière sûre\n* `%x` base 16, avec des lettres minuscules pour a-f\n* `%X` base 16, avec des lettres majuscules pour A-F\n* `%U` format Unicode : U+1234 ; identique à \"U+%04X\"\n\n Virgule flottante et constituants complexes :\n\n* `%b` notation scientifique décimale avec exposant puissance de deux, par exemple\n  -123456p-78\n* `%e` notation scientifique, par exemple -1.234456e+78\n* `%E` notation scientifique, par exemple -1.234456E+78\n* `%f` virgule décimale sans exposant, par exemple 123.456\n* `%F` synonyme de %f\n* `%g` %e pour les grands exposants, %f sinon.\n* `%G` %E pour les grands exposants, %F sinon\n* `%x` notation hexadécimale (avec exposant puissance de deux décimale), par exemple\n  -0x1.23abcp+20\n* `%X` notation hexadécimale majuscule, par exemple -0X1.23ABCP+20\n\nChaîne et slice d'octets (traités de manière équivalente avec ces verbes) :\n\n* `%s` les octets non interprétés de la chaîne ou du slice\n* `%q` une chaîne entre guillemets doubles, échappée de manière sûre\n* `%x` base 16, minuscules, deux caractères par octet\n* `%X` base 16, majuscules, deux caractères par octet\n\nSlice :\n\n* `%p` adresse du 0ème élément en notation base 16, avec 0x en préfixe\n\n### trim\n\nLa fonction `trim` supprime les espaces blancs des deux côtés d'une chaîne :\n\n```\ntrim \"   hello    \"\n```\n\nL'exemple ci-dessus produit `hello`\n\n### trimAll\n\nSupprime les caractères donnés de l'avant et de l'arrière d'une chaîne :\n\n```\ntrimAll \"$\" \"$5.00\"\n```\n\nL'exemple ci-dessus retourne `5.00` (en tant que chaîne).\n\n### trimPrefix\n\nSupprime uniquement le préfixe d'une chaîne :\n\n```\ntrimPrefix \"-\" \"-hello\"\n```\n\nL'exemple ci-dessus retourne `hello`\n\n### trimSuffix\n\nSupprime uniquement le suffixe d'une chaîne :\n\n```\ntrimSuffix \"-\" \"hello-\"\n```\n\nL'exemple ci-dessus retourne `hello`\n\n### lower\n\nConvertit toute la chaîne en minuscules :\n\n```\nlower \"HELLO\"\n```\n\nL'exemple ci-dessus retourne `hello`\n\n### upper\n\nConvertit toute la chaîne en majuscules :\n\n```\nupper \"hello\"\n```\n\nL'exemple ci-dessus retourne `HELLO`\n\n### title\n\nConvertit en casse titre :\n\n```\ntitle \"hello world\"\n```\n\nL'exemple ci-dessus retourne `Hello World`\n\n### untitle\n\nSupprime la casse titre. `untitle \"Hello World\"` produit `hello world`.\n\n### repeat\n\nRépète une chaîne plusieurs fois :\n\n```\nrepeat 3 \"hello\"\n```\n\nL'exemple ci-dessus retourne `hellohellohello`\n\n### substr\n\nObtient une sous-chaîne d'une chaîne. Cette fonction prend trois paramètres :\n\n- start (int)\n- end (int)\n- string (string)\n\n```\nsubstr 0 5 \"hello world\"\n```\n\nL'exemple ci-dessus retourne `hello`\n\n### nospace\n\nSupprime tous les espaces blancs d'une chaîne.\n\n```\nnospace \"hello w o r l d\"\n```\n\nL'exemple ci-dessus retourne `helloworld`\n\n### trunc\n\nTronque une chaîne\n\n```\ntrunc 5 \"hello world\"\n```\n\nL'exemple ci-dessus produit `hello`.\n\n```\ntrunc -5 \"hello world\"\n```\n\nL'exemple ci-dessus produit `world`.\n\n### abbrev\n\nTronque une chaîne avec des points de suspension (`...`)\n\nParamètres :\n\n- longueur maximale\n- la chaîne\n\n```\nabbrev 5 \"hello world\"\n```\n\nL'exemple ci-dessus retourne `he...`, car la largeur des points de suspension est comptée dans la\nlongueur maximale.\n\n### abbrevboth\n\nAbrège des deux côtés :\n\n```\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\nL'exemple ci-dessus produit `...5678...`\n\nCette fonction prend :\n\n- décalage gauche\n- longueur maximale\n- la chaîne\n\n### initials\n\nÉtant donné plusieurs mots, prend la première lettre de chaque mot et les combine.\n\n```\ninitials \"First Try\"\n```\n\nL'exemple ci-dessus retourne `FT`\n\n### randAlphaNum, randAlpha, randNumeric et randAscii\n\nCes quatre fonctions génèrent des chaînes aléatoires cryptographiquement sécurisées (utilisant ```crypto/rand```),\nmais avec différents jeux de caractères de base :\n\n- `randAlphaNum` utilise `0-9a-zA-Z`\n- `randAlpha` utilise `a-zA-Z`\n- `randNumeric` utilise `0-9`\n- `randAscii` utilise tous les caractères ASCII imprimables\n\nChacune d'elles prend un paramètre : la longueur entière de la chaîne.\n\n```\nrandNumeric 3\n```\n\nL'exemple ci-dessus produira une chaîne aléatoire avec trois chiffres.\n\n### wrap\n\nEnveloppe le texte à un nombre de colonnes donné :\n\n```\nwrap 80 $someText\n```\n\nL'exemple ci-dessus enveloppera la chaîne dans `$someText` à 80 colonnes.\n\n### wrapWith\n\n`wrapWith` fonctionne comme `wrap`, mais vous permet de spécifier la chaîne avec laquelle envelopper.\n(`wrap` utilise `\\n`)\n\n```\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\nL'exemple ci-dessus produit `Hello\tWorld` (où l'espace blanc est un caractère de tabulation ASCII)\n\n### contains\n\nTeste si une chaîne est contenue dans une autre :\n\n```\ncontains \"cat\" \"catch\"\n```\n\nL'exemple ci-dessus retourne `true` car `catch` contient `cat`.\n\n### hasPrefix et hasSuffix\n\nLes fonctions `hasPrefix` et `hasSuffix` testent si une chaîne a un\npréfixe ou suffixe donné :\n\n```\nhasPrefix \"cat\" \"catch\"\n```\n\nL'exemple ci-dessus retourne `true` car `catch` a le préfixe `cat`.\n\n### quote et squote\n\nCes fonctions entourent une chaîne de guillemets doubles (`quote`) ou de guillemets simples\n(`squote`).\n\n### cat\n\nLa fonction `cat` concatène plusieurs chaînes en une seule, en les séparant\npar des espaces :\n\n```\ncat \"hello\" \"beautiful\" \"world\"\n```\n\nL'exemple ci-dessus produit `hello beautiful world`\n\n### indent\n\nLa fonction `indent` indente chaque ligne d'une chaîne donnée à la largeur d'indentation\nspécifiée. Ceci est utile lors de l'alignement de chaînes multilignes :\n\n```\nindent 4 $lots_of_text\n```\n\nL'exemple ci-dessus indentera chaque ligne de texte de 4 caractères d'espace.\n\n### nindent\n\nLa fonction `nindent` est identique à la fonction indent, mais ajoute une nouvelle\nligne au début de la chaîne.\n\n```\nnindent 4 $lots_of_text\n```\n\nL'exemple ci-dessus indentera chaque ligne de texte de 4 caractères d'espace et ajoutera une nouvelle\nligne au début.\n\n### replace\n\nEffectue un simple remplacement de chaîne.\n\nCette fonction prend trois arguments :\n\n- chaîne à remplacer\n- chaîne de remplacement\n- chaîne source\n\n```\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\nL'exemple ci-dessus produira `I-Am-Henry-VIII`\n\n### plural\n\nPluralise une chaîne.\n\n```\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\nDans l'exemple ci-dessus, si la longueur de la chaîne est 1, le premier argument sera\naffiché (`one anchovy`). Sinon, le second argument sera affiché (`many\nanchovies`).\n\nLes arguments sont :\n\n- chaîne au singulier\n- chaîne au pluriel\n- entier de longueur\n\nNOTE : Helm ne prend actuellement pas en charge les langues avec des règles de pluralisation\nplus complexes. Et `0` est considéré comme un pluriel car la langue anglaise le traite ainsi\n(`zero anchovies`).\n\n### snakecase\n\nConvertit une chaîne de camelCase en snake_case.\n\n```\nsnakecase \"FirstName\"\n```\n\nL'exemple ci-dessus produira `first_name`.\n\n### camelcase\n\nConvertit une chaîne de snake_case en CamelCase\n\n```\ncamelcase \"http_server\"\n```\n\nL'exemple ci-dessus produira `HttpServer`.\n\n### kebabcase\n\nConvertit une chaîne de camelCase en kebab-case.\n\n```\nkebabcase \"FirstName\"\n```\n\nL'exemple ci-dessus produira `first-name`.\n\n### swapcase\n\nInverse la casse d'une chaîne en utilisant un algorithme basé sur les mots.\n\nAlgorithme de conversion :\n\n- Les caractères majuscules sont convertis en minuscules\n- Les caractères en casse titre sont convertis en minuscules\n- Les caractères minuscules après un espace ou au début sont convertis en casse titre\n- Les autres caractères minuscules sont convertis en majuscules\n- Les espaces sont définis par unicode.IsSpace(char)\n\n```\nswapcase \"This Is A.Test\"\n```\n\nL'exemple ci-dessus produira `tHIS iS a.tEST`.\n\n### shuffle\n\nMélange une chaîne.\n\n```\nshuffle \"hello\"\n```\n\nL'exemple ci-dessus mélangera les lettres dans `hello`, produisant peut-être `oelhl`.\n\n## Fonctions de conversion de types\n\nLes fonctions de conversion de types suivantes sont fournies par Helm :\n\n- `atoi` : Convertit une chaîne en entier.\n- `float64` : Convertit en `float64`.\n- `int` : Convertit en `int` à la largeur du système.\n- `int64` : Convertit en `int64`.\n- `toDecimal` : Convertit un octal unix en `int64`.\n- `toString` : Convertit en chaîne.\n- `toStrings` : Convertit une liste, un slice ou un tableau en une liste de chaînes.\n- `toJson` (`mustToJson`) : Convertit une liste, un slice, un tableau, un dict ou un objet en JSON.\n- `toPrettyJson` (`mustToPrettyJson`) : Convertit une liste, un slice, un tableau, un dict ou un\n  objet en JSON indenté.\n- `toRawJson` (`mustToRawJson`) : Convertit une liste, un slice, un tableau, un dict ou un objet en\n  JSON avec les caractères HTML non échappés.\n- `fromYaml` : Convertit une chaîne YAML en objet.\n- `fromJson` : Convertit une chaîne JSON en objet.\n- `fromJsonArray` : Convertit un tableau JSON en liste.\n- `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\n- `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.\n- `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.\n- `fromYamlArray` : Convertit un tableau YAML en liste.\n\nSeule `atoi` nécessite que l'entrée soit d'un type spécifique. Les autres tenteront\nde convertir depuis n'importe quel type vers le type de destination. Par exemple, `int64` peut\nconvertir des flottants en entiers, et peut également convertir des chaînes en entiers.\n\n### toStrings\n\nÉtant donné une collection de type liste, produit un slice de chaînes.\n\n```\nlist 1 2 3 | toStrings\n```\n\nL'exemple ci-dessus convertit `1` en `\"1\"`, `2` en `\"2\"`, et ainsi de suite, puis les retourne\nsous forme de liste.\n\n### toDecimal\n\nÉtant donné une permission octal unix, produit un décimal.\n\n```\n\"0777\" | toDecimal\n```\n\nL'exemple ci-dessus convertit `0777` en `511` et retourne la valeur en tant qu'int64.\n\n### toJson, mustToJson\n\nLa fonction `toJson` encode un élément en chaîne JSON. Si l'élément ne peut pas être\nconverti en JSON, la fonction retournera une chaîne vide. `mustToJson`\nretournera une erreur si l'élément ne peut pas être encodé en JSON.\n\n```\ntoJson .Item\n```\n\nL'exemple ci-dessus retourne la représentation en chaîne JSON de `.Item`.\n\n### toPrettyJson, mustToPrettyJson\n\nLa fonction `toPrettyJson` encode un élément en chaîne JSON formatée (indentée).\n\n```\ntoPrettyJson .Item\n```\n\nL'exemple ci-dessus retourne la représentation en chaîne JSON indentée de `.Item`.\n\n### toRawJson, mustToRawJson\n\nLa fonction `toRawJson` encode un élément en chaîne JSON avec les caractères HTML\nnon échappés.\n\n```\ntoRawJson .Item\n```\n\nL'exemple ci-dessus retourne la représentation en chaîne JSON non échappée de `.Item`.\n\n### fromYaml\n\nLa fonction `fromYaml` prend une chaîne YAML et retourne un objet qui peut être utilisé dans les templates.\n\n`Fichier à : yamls/person.yaml`\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n```yaml\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\nLa fonction `fromJson` prend une chaîne JSON et retourne un objet qui peut être utilisé dans les templates.\n\n`Fichier à : jsons/person.json`\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n\n### fromJsonArray\n\nLa fonction `fromJsonArray` prend un tableau JSON et retourne une liste qui peut être utilisée dans les templates.\n\n`Fichier à : jsons/people.json`\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml, toYamlPretty\n\nLes fonctions `toYaml` et `toYamlPretty` encodent un objet (liste, slice, tableau, dict ou objet) en une chaîne YAML indentée.\n\n> Notez que `toYamlPretty` est fonctionnellement équivalent mais produira du YAML avec une indentation supplémentaire pour les éléments de liste\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\nLa fonction `fromYamlArray` prend un tableau YAML et retourne une liste qui peut être utilisée dans les templates.\n\n`Fichier à : yamls/people.yml`\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n\n## Expressions régulières\n\nHelm inclut les fonctions d'expressions régulières suivantes : [regexFind\n(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll\n(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch\n(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll\n(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall),\n[regexReplaceAllLiteral\n(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral),\n[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\nRetourne vrai si la chaîne d'entrée contient une correspondance de l'expression régulière.\n\n```\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\nL'exemple ci-dessus produit `true`\n\n`regexMatch` provoque un panic en cas de problème et `mustRegexMatch` retourne une erreur\nau moteur de template en cas de problème.\n\n### regexFindAll, mustRegexFindAll\n\nRetourne un slice de toutes les correspondances de l'expression régulière dans la chaîne d'entrée.\nLe dernier paramètre n détermine le nombre de sous-chaînes à retourner, où -1\nsignifie retourner toutes les correspondances\n\n```\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\nL'exemple ci-dessus produit `[2 4 6 8]`\n\n`regexFindAll` provoque un panic en cas de problème et `mustRegexFindAll` retourne une\nerreur au moteur de template en cas de problème.\n\n### regexFind, mustRegexFind\n\nRetourne la première (la plus à gauche) correspondance de l'expression régulière dans la chaîne d'entrée\n\n```\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\nL'exemple ci-dessus produit `d1`\n\n`regexFind` provoque un panic en cas de problème et `mustRegexFind` retourne une erreur au\nmoteur de template en cas de problème.\n\n### regexReplaceAll, mustRegexReplaceAll\n\nRetourne une copie de la chaîne d'entrée, en remplaçant les correspondances de l'expression régulière par\nla chaîne de remplacement. Dans la chaîne de remplacement, les signes $ sont\ninterprétés comme dans Expand, donc par exemple $1 représente le texte de la première\nsous-correspondance. Le premier argument est `<pattern>`, le second est `<input>`,\net le troisième est `<replacement>`.\n\n```\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\nL'exemple ci-dessus produit `-W-xxW-`\n\n`regexReplaceAll` provoque un panic en cas de problème et `mustRegexReplaceAll` retourne\nune erreur au moteur de template en cas de problème.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\nRetourne une copie de la chaîne d'entrée, en remplaçant les correspondances de l'expression régulière par\nla chaîne de remplacement. La chaîne de remplacement est substituée directement,\nsans utiliser Expand. Le premier argument est `<pattern>`, le second est `<input>`,\net le troisième est `<replacement>`.\n\n```\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\nL'exemple ci-dessus produit `-${1}-${1}-`\n\n`regexReplaceAllLiteral` provoque un panic en cas de problème et\n`mustRegexReplaceAllLiteral` retourne une erreur au moteur de template en cas de\nproblème.\n\n### regexSplit, mustRegexSplit\n\nDécoupe la chaîne d'entrée en sous-chaînes séparées par l'expression et retourne\nun slice des sous-chaînes entre ces correspondances d'expression. Le dernier paramètre\n`n` détermine le nombre de sous-chaînes à retourner, où `-1` signifie retourner toutes\nles correspondances\n\n```\nregexSplit \"z+\" \"pizza\" -1\n```\n\nL'exemple ci-dessus produit `[pi a]`\n\n`regexSplit` provoque un panic en cas de problème et `mustRegexSplit` retourne une erreur\nau moteur de template en cas de problème.\n\n## Fonctions cryptographiques et de sécurité\n\nHelm fournit des fonctions cryptographiques avancées. Elles incluent\n[adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert),\n[decryptAES](#decryptaes), [derivePassword](#derivepassword),\n[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey),\n[genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert),\n[htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum), et\n[sha256sum](#sha256sum).\n\n### sha1sum\n\nLa fonction `sha1sum` reçoit une chaîne et calcule son condensé SHA1.\n\n```\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\nLa fonction `sha256sum` reçoit une chaîne et calcule son condensé SHA256.\n\n```\nsha256sum \"Hello world!\"\n```\n\nL'exemple ci-dessus calculera la somme SHA 256 dans un format « ASCII armored » qui est sûr\nà afficher.\n\n### adler32sum\n\nLa fonction `adler32sum` reçoit une chaîne et calcule sa somme de contrôle Adler-32.\n\n```\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\nLa fonction `htpasswd` prend un `username` et un `password` et génère un\nhachage `bcrypt` du mot de passe. Le résultat peut être utilisé pour l'authentification de base\nsur un [serveur HTTP Apache](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic).\n\n```\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nNotez qu'il n'est pas sécurisé de stocker le mot de passe directement dans le template.\n\n### randBytes\n\nLa fonction randBytes accepte un compteur N et génère une séquence aléatoire\ncryptographiquement sécurisée (utilise crypto/rand) de N octets. La séquence est retournée\nsous forme de chaîne encodée en base64.\n\n```\nrandBytes 24\n```\n\n### derivePassword\n\nLa fonction `derivePassword` peut être utilisée pour dériver un mot de passe spécifique basé sur\ncertaines contraintes d'un « mot de passe maître » partagé. L'algorithme pour cela est [bien\nspécifié](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf).\n\n```\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nNotez qu'il est considéré comme non sécurisé de stocker les parties directement dans le template.\n\n### genPrivateKey\n\nLa fonction `genPrivateKey` génère une nouvelle clé privée encodée dans un bloc PEM.\n\nElle prend l'une des valeurs suivantes pour son premier paramètre :\n\n- `ecdsa` : Génère une clé DSA à courbe elliptique (P256)\n- `dsa` : Génère une clé DSA (L2048N256)\n- `rsa` : Génère une clé RSA 4096\n\n### buildCustomCert\n\nLa fonction `buildCustomCert` permet de personnaliser le certificat.\n\nElle prend les paramètres de chaîne suivants :\n\n- Un certificat au format PEM encodé en base64\n- Une clé privée au format PEM encodée en base64\n\nElle retourne un objet certificat avec les attributs suivants :\n\n- `Cert` : Un certificat encodé en PEM\n- `Key` : Une clé privée encodée en PEM\n\nExemple :\n\n```\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\nNotez que l'objet retourné peut être passé à la fonction `genSignedCert` pour\nsigner un certificat en utilisant cette CA.\n\n### genCA\n\nLa fonction `genCA` génère une nouvelle autorité de certification x509 auto-signée.\n\nElle prend les paramètres suivants :\n\n- Nom commun du sujet (cn)\n- Durée de validité du certificat en jours\n\nElle retourne un objet avec les attributs suivants :\n\n- `Cert` : Un certificat encodé en PEM\n- `Key` : Une clé privée encodée en PEM\n\nExemple :\n\n```\n$ca := genCA \"foo-ca\" 365\n```\n\nNotez que l'objet retourné peut être passé à la fonction `genSignedCert` pour\nsigner un certificat en utilisant cette CA.\n\n### genSelfSignedCert\n\nLa fonction `genSelfSignedCert` génère un nouveau certificat x509 auto-signé.\n\nElle prend les paramètres suivants :\n\n- Nom commun du sujet (cn)\n- Liste optionnelle d'IPs ; peut être nil\n- Liste optionnelle de noms DNS alternatifs ; peut être nil\n- Durée de validité du certificat en jours\n\nElle retourne un objet avec les attributs suivants :\n\n- `Cert` : Un certificat encodé en PEM\n- `Key` : Une clé privée encodée en PEM\n\nExemple :\n\n```\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\nLa fonction `genSignedCert` génère un nouveau certificat x509 signé par la\nCA spécifiée.\n\nElle prend les paramètres suivants :\n\n- Nom commun du sujet (cn)\n- Liste optionnelle d'IPs ; peut être nil\n- Liste optionnelle de noms DNS alternatifs ; peut être nil\n- Durée de validité du certificat en jours\n- CA (voir `genCA`)\n\nExemple :\n\n```\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\nLa fonction `encryptAES` chiffre du texte avec AES-256 CBC et retourne une chaîne\nencodée en base64.\n\n```\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\nLa fonction `decryptAES` reçoit une chaîne base64 encodée par l'algorithme AES-256 CBC\net retourne le texte déchiffré.\n\n```\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Fonctions de date\n\nHelm inclut les fonctions de date suivantes que vous pouvez utiliser dans les templates :\n[ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify\n(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration),\n[durationRound](#durationround), [htmlDate](#htmldate),\n[htmlDateInZone](#htmldateinzone), [now](#now), [toDate\n(mustToDate)](#todate-musttodate), et [unixEpoch](#unixepoch).\n\n### now\n\nLa date/heure actuelle. Utilisez ceci en conjonction avec d'autres fonctions de date.\n\n### ago\n\nLa fonction `ago` retourne la durée depuis un temps. Résolution en secondes.\n\n```\nago .CreatedAt\n```\n\nretourne au format String() de `time.Duration`\n\n```\n2h34m7s\n```\n\n### date\n\nLa fonction `date` formate une date.\n\nFormatez la date en ANNÉE-MOIS-JOUR :\n\n```\nnow | date \"2006-01-02\"\n```\n\nLe formatage de date en Go est [un peu\ndifférent](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\nEn bref, prenez ceci comme date de référence :\n\n```\nMon Jan 2 15:04:05 MST 2006\n```\n\nÉcrivez-la dans le format souhaité. Ci-dessus, `2006-01-02` est la même date, mais dans\nle format que nous voulons.\n\n### dateInZone\n\nIdentique à `date`, mais avec un fuseau horaire.\n\n```\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\nFormate un nombre de secondes donné en `time.Duration`.\n\nCeci retourne 1m35s\n\n```\nduration \"95\"\n```\n\n### durationRound\n\nArrondit une durée donnée à l'unité la plus significative. Les chaînes et\n`time.Duration` sont analysés comme une durée, tandis qu'un `time.Time` est calculé comme\nla durée depuis.\n\nCeci retourne 2h\n\n```\ndurationRound \"2h10m5s\"\n```\n\nCeci retourne 3mo\n\n```\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\nRetourne les secondes depuis l'époque unix pour un `time.Time`.\n\n```\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\nLa fonction `dateModify` prend une modification et une date et retourne l'horodatage.\n\nSoustraire une heure et trente minutes de l'heure actuelle :\n\n```\nnow | dateModify \"-1.5h\"\n```\n\nSi le format de modification est incorrect, `dateModify` retournera la date\nnon modifiée. `mustDateModify` retournera une erreur dans ce cas.\n\n### htmlDate\n\nLa fonction `htmlDate` formate une date pour l'insertion dans un champ de sélection\nde date HTML.\n\n```\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nIdentique à htmlDate, mais avec un fuseau horaire.\n\n```\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\n`toDate` convertit une chaîne en date. Le premier argument est le format de date et\nle second est la chaîne de date. Si la chaîne ne peut pas être convertie, elle retourne la valeur zéro.\n`mustToDate` retournera une erreur si la chaîne ne peut pas être convertie.\n\nCeci est utile lorsque vous voulez convertir une date en chaîne vers un autre format (en utilisant\nun pipe). L'exemple ci-dessous convertit \"2017-12-31\" en \"31/12/2017\".\n\n```\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Dictionnaires et fonctions Dict\n\nHelm fournit un type de stockage clé/valeur appelé `dict` (abréviation de « dictionary »,\ncomme en Python). Un `dict` est un type _non ordonné_.\n\nLa clé d'un dictionnaire **doit être une chaîne**. Cependant, la valeur peut être de n'importe quel\ntype, même un autre `dict` ou une `list`.\n\nContrairement aux `list`s, les `dict`s ne sont pas immuables. Les fonctions `set` et `unset`\nmodifieront le contenu d'un dictionnaire.\n\nHelm fournit les fonctions suivantes pour travailler avec les dicts : [deepCopy\n(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get),\n[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge),\n[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite),\n[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), et\n[values](#values).\n\n### dict\n\nLa création de dictionnaires se fait en appelant la fonction `dict` et en lui passant une\nliste de paires.\n\nL'exemple suivant crée un dictionnaire avec trois éléments :\n\n```\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nÉtant donné un map et une clé, obtient la valeur du map.\n\n```\nget $myDict \"name1\"\n```\n\nL'exemple ci-dessus retourne `\"value1\"`\n\nNotez que si la clé n'est pas trouvée, cette opération retournera simplement `\"\"`. Aucune\nerreur ne sera générée.\n\n### set\n\nUtilisez `set` pour ajouter une nouvelle paire clé/valeur à un dictionnaire.\n\n```\n$_ := set $myDict \"name4\" \"value4\"\n```\n\nNotez que `set` _retourne le dictionnaire_ (une exigence des fonctions de template Go),\nvous devrez donc peut-être capturer la valeur comme fait ci-dessus avec l'assignation `$_`.\n\n### unset\n\nÉtant donné un map et une clé, supprime la clé du map.\n\n```\n$_ := unset $myDict \"name4\"\n```\n\nComme avec `set`, ceci retourne le dictionnaire.\n\nNotez que si la clé n'est pas trouvée, cette opération retournera simplement. Aucune erreur\nne sera générée.\n\n### hasKey\n\nLa fonction `hasKey` retourne `true` si le dict donné contient la clé donnée.\n\n```\nhasKey $myDict \"name1\"\n```\n\nSi la clé n'est pas trouvée, ceci retourne `false`.\n\n### pluck\n\nLa fonction `pluck` permet de donner une clé et plusieurs maps, et\nd'obtenir une liste de toutes les correspondances :\n\n```\npluck \"name1\" $myDict $myOtherDict\n```\n\nL'exemple ci-dessus retournera une `list` contenant chaque valeur trouvée (`[value1\notherValue1]`).\n\nSi la clé donnée _n'est pas trouvée_ dans un map, ce map n'aura pas d'élément dans la\nliste (et la longueur de la liste retournée sera inférieure au nombre de dicts\ndans l'appel à `pluck`).\n\nSi la clé _est trouvée_ mais que la valeur est une valeur vide, cette valeur sera\ninsérée.\n\nUn idiome courant dans les templates Helm est d'utiliser `pluck... | first` pour obtenir la première\nclé correspondante d'une collection de dictionnaires.\n\n### dig\n\nLa fonction `dig` parcourt un ensemble imbriqué de dicts, en sélectionnant les clés d'une liste\nde valeurs. Elle retourne une valeur par défaut si l'une des clés n'est pas trouvée dans le\ndict associé.\n\n```\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\nÉtant donné un dict structuré comme\n```\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\nl'exemple ci-dessus retournerait `\"curator\"`. Si le dict n'avait même pas de champ `user`,\nle résultat serait `\"guest\"`.\n\nDig peut être très utile dans les cas où vous souhaitez éviter les clauses de garde,\nd'autant plus que le `and` du package template de Go ne fait pas de court-circuit. Par exemple\n`and a.maybeNil a.maybeNil.iNeedThis` évaluera toujours\n`a.maybeNil.iNeedThis`, et provoquera une panique si `a` n'a pas de champ `maybeNil`.)\n\n`dig` accepte son argument dict en dernier afin de prendre en charge le pipelining. Par exemple :\n```\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\nFusionne deux dictionnaires ou plus en un seul, en donnant la priorité au dictionnaire\nde destination :\n\nÉtant donné :\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nle résultat sera :\n\n```\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n```\n$newdict := merge $dest $source1 $source2\n```\n\nC'est une opération de fusion profonde mais pas une opération de copie profonde. Les objets imbriqués\nqui sont fusionnés sont la même instance dans les deux dicts. Si vous voulez une copie profonde\nen même temps que la fusion, utilisez la fonction `deepCopy` avec la fusion. Par\nexemple,\n\n```\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` retournera une erreur en cas de fusion non réussie.\n\n### mergeOverwrite, mustMergeOverwrite\n\nFusionne deux dictionnaires ou plus en un seul, en donnant la priorité **de droite à\ngauche**, écrasant ainsi les valeurs dans le dictionnaire de destination :\n\nÉtant donné :\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nle résultat sera :\n\n```\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nC'est une opération de fusion profonde mais pas une opération de copie profonde. Les objets imbriqués\nqui sont fusionnés sont la même instance dans les deux dicts. Si vous voulez une copie profonde\nen même temps que la fusion, utilisez la fonction `deepCopy` avec la fusion. Par\nexemple,\n\n```\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` retournera une erreur en cas de fusion non réussie.\n\n### keys\n\nLa fonction `keys` retournera une `list` de toutes les clés dans un ou plusieurs\ntypes `dict`. Puisqu'un dictionnaire est _non ordonné_, les clés ne seront pas dans un\nordre prévisible. Elles peuvent être triées avec `sortAlpha`.\n\n```\nkeys $myDict | sortAlpha\n```\n\nLors de la fourniture de plusieurs dictionnaires, les clés seront concaténées. Utilisez la\nfonction `uniq` avec `sortAlpha` pour obtenir une liste unique et triée de clés.\n\n```\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\nLa fonction `pick` sélectionne uniquement les clés données d'un dictionnaire, créant un\nnouveau `dict`.\n\n```\n$new := pick $myDict \"name1\" \"name2\"\n```\n\nL'exemple ci-dessus retourne `{name1: value1, name2: value2}`\n\n### omit\n\nLa fonction `omit` est similaire à `pick`, sauf qu'elle retourne un nouveau `dict` avec\ntoutes les clés qui _ne correspondent pas_ aux clés données.\n\n```\n$new := omit $myDict \"name1\" \"name3\"\n```\n\nL'exemple ci-dessus retourne `{name2: value2}`\n\n### values\n\nLa fonction `values` est similaire à `keys`, sauf qu'elle retourne une nouvelle `list` avec\ntoutes les valeurs du `dict` source (un seul dictionnaire est pris en charge).\n\n```\n$vals := values $myDict\n```\n\nL'exemple ci-dessus retourne `list[\"value1\", \"value2\", \"value 3\"]`. Notez que la fonction `values`\nne donne aucune garantie sur l'ordre des résultats ; si cela vous importe,\nutilisez `sortAlpha`.\n\n### deepCopy, mustDeepCopy\n\nLes fonctions `deepCopy` et `mustDeepCopy` prennent une valeur et en font une copie profonde.\nCela inclut les dicts et autres structures. `deepCopy` provoque un panic lorsqu'il\ny a un problème, tandis que `mustDeepCopy` retourne une erreur au système de template\nlorsqu'il y a une erreur.\n\n```\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### Note sur les internes des Dict\n\nUn `dict` est implémenté en Go comme un `map[string]interface{}`. Les développeurs Go peuvent\npasser des valeurs `map[string]interface{}` dans le contexte pour les rendre disponibles aux\ntemplates en tant que `dict`s.\n\n## Fonctions d'encodage\n\nHelm dispose des fonctions d'encodage et de décodage suivantes :\n\n- `b64enc`/`b64dec` : Encoder ou décoder avec Base64\n- `b32enc`/`b32dec` : Encoder ou décoder avec Base32\n\n## Listes et fonctions de liste\n\nHelm fournit un type `list` simple qui peut contenir des listes séquentielles arbitraires\nde données. C'est similaire aux tableaux ou aux slices, mais les listes sont conçues pour être utilisées\ncomme types de données immuables.\n\nCréer une liste d'entiers :\n\n```\n$myList := list 1 2 3 4 5\n```\n\nL'exemple ci-dessus crée une liste de `[1 2 3 4 5]`.\n\nHelm fournit les fonctions de liste suivantes : [append\n(mustAppend)](#append-mustappend), [chunk](#chunk), [compact\n(mustCompact)](#compact-mustcompact), [concat](#concat), [first\n(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial\n(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast),\n[prepend (mustPrepend)](#prepend-mustprepend), [rest\n(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse),\n[seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq\n(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), et\n[without (mustWithout)](#without-mustwithout).\n\n### first, mustFirst\n\nPour obtenir le premier élément d'une liste, utilisez `first`.\n\n`first $myList` retourne `1`\n\n`first` provoque un panic en cas de problème, tandis que `mustFirst` retourne une erreur au\nmoteur de template en cas de problème.\n\n### rest, mustRest\n\nPour obtenir la queue de la liste (tout sauf le premier élément), utilisez `rest`.\n\n`rest $myList` retourne `[2 3 4 5]`\n\n`rest` provoque un panic en cas de problème, tandis que `mustRest` retourne une erreur au\nmoteur de template en cas de problème.\n\n### last, mustLast\n\nPour obtenir le dernier élément d'une liste, utilisez `last` :\n\n`last $myList` retourne `5`. C'est approximativement équivalent à inverser une liste et\nensuite appeler `first`.\n\n### initial, mustInitial\n\nCeci complète `last` en retournant tous les éléments _sauf_ le dernier. `initial\n$myList` retourne `[1 2 3 4]`.\n\n`initial` provoque un panic en cas de problème, tandis que `mustInitial` retourne une erreur au\nmoteur de template en cas de problème.\n\n### append, mustAppend\n\nAjoute un nouvel élément à une liste existante, créant une nouvelle liste.\n\n```\n$new = append $myList 6\n```\n\nL'exemple ci-dessus définirait `$new` à `[1 2 3 4 5 6]`. `$myList` resterait inchangé.\n\n`append` provoque un panic en cas de problème, tandis que `mustAppend` retourne une erreur au\nmoteur de template en cas de problème.\n\n### prepend, mustPrepend\n\nPousse un élément au début d'une liste, créant une nouvelle liste.\n\n```\nprepend $myList 0\n```\n\nL'exemple ci-dessus produirait `[0 1 2 3 4 5]`. `$myList` resterait inchangé.\n\n`prepend` provoque un panic en cas de problème, tandis que `mustPrepend` retourne une erreur au\nmoteur de template en cas de problème.\n\n### concat\n\nConcatène un nombre arbitraire de listes en une seule.\n\n```\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\nL'exemple ci-dessus produirait `[1 2 3 4 5 6 7 8]`. `$myList` resterait inchangé.\n\n### reverse, mustReverse\n\nProduit une nouvelle liste avec les éléments inversés de la liste donnée.\n\n```\nreverse $myList\n```\n\nL'exemple ci-dessus générerait la liste `[5 4 3 2 1]`.\n\n`reverse` provoque un panic en cas de problème, tandis que `mustReverse` retourne une erreur au\nmoteur de template en cas de problème.\n\n### uniq, mustUniq\n\nGénère une liste avec tous les doublons supprimés.\n\n```\nlist 1 1 1 2 | uniq\n```\n\nL'exemple ci-dessus produirait `[1 2]`\n\n`uniq` provoque un panic en cas de problème, tandis que `mustUniq` retourne une erreur au\nmoteur de template en cas de problème.\n\n### without, mustWithout\n\nLa fonction `without` filtre les éléments d'une liste.\n\n```\nwithout $myList 3\n```\n\nL'exemple ci-dessus produirait `[1 2 4 5]`\n\n`without` peut prendre plus d'un filtre :\n\n```\nwithout $myList 1 3 5\n```\n\nCela produirait `[2 4]`\n\n`without` provoque un panic en cas de problème, tandis que `mustWithout` retourne une erreur au\nmoteur de template en cas de problème.\n\n### has, mustHas\n\nTeste si une liste contient un élément particulier.\n\n```\nhas 4 $myList\n```\n\nL'exemple ci-dessus retournerait `true`, tandis que `has \"hello\" $myList` retournerait false.\n\n`has` provoque un panic en cas de problème, tandis que `mustHas` retourne une erreur au\nmoteur de template en cas de problème.\n\n### compact, mustCompact\n\nAccepte une liste et supprime les entrées avec des valeurs vides.\n\n```\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` retournera une nouvelle liste avec l'élément vide (c'est-à-dire \"\") supprimé.\n\n`compact` provoque un panic en cas de problème et `mustCompact` retourne une erreur au\nmoteur de template en cas de problème.\n\n### index\n\nPour obtenir le nième élément d'une liste, utilisez `index list [n]`. Pour indexer dans\ndes listes multidimensionnelles, utilisez `index list [n] [m] ...`\n- `index $myList 0` retourne `1`. C'est la même chose que `myList[0]`\n- `index $myList 0 1` serait la même chose que `myList[0][1]`\n\n### slice, mustSlice\n\nPour obtenir des éléments partiels d'une liste, utilisez `slice list [n] [m]`. C'est équivalent à\n`list[n:m]`.\n\n- `slice $myList` retourne `[1 2 3 4 5]`. C'est la même chose que `myList[:]`.\n- `slice $myList 3` retourne `[4 5]`. C'est la même chose que `myList[3:]`.\n- `slice $myList 1 3` retourne `[2 3]`. C'est la même chose que `myList[1:3]`.\n- `slice $myList 0 3` retourne `[1 2 3]`. C'est la même chose que `myList[:3]`.\n\n`slice` provoque un panic en cas de problème, tandis que `mustSlice` retourne une erreur au\nmoteur de template en cas de problème.\n\n### until\n\nLa fonction `until` construit une plage d'entiers.\n\n```\nuntil 5\n```\n\nL'exemple ci-dessus génère la liste `[0, 1, 2, 3, 4]`.\n\nC'est utile pour boucler avec `range $i, $e := until 5`.\n\n### untilStep\n\nComme `until`, `untilStep` génère une liste d'entiers à compter. Mais elle vous permet\nde définir un début, une fin et un pas :\n\n```\nuntilStep 3 6 2\n```\n\nL'exemple ci-dessus produira `[3 5]` en commençant par 3, et en ajoutant 2 jusqu'à ce que ce soit\négal ou supérieur à 6. C'est similaire à la fonction `range` de Python.\n\n### seq\n\nFonctionne comme la commande bash `seq`.\n\n* 1 paramètre  (end) - générera tous les entiers entre 1 et `end`\n  inclus.\n* 2 paramètres (start, end) - générera tous les entiers entre\n  `start` et `end` inclus en incrémentant ou décrémentant de 1.\n* 3 paramètres (start, step, end) - générera tous les entiers entre\n  `start` et `end` inclus en incrémentant ou décrémentant de `step`.\n\n```\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\nPour diviser une liste en morceaux d'une taille donnée, utilisez `chunk size list`. C'est utile pour la pagination.\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\nCeci produit une liste de listes `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`.\n\n## Fonctions mathématiques\n\nToutes les fonctions mathématiques opèrent sur des valeurs `int64` sauf indication contraire.\n\nLes fonctions mathématiques suivantes sont disponibles : [add](#add), [add1](#add1),\n[ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max),\n[min](#min), [mod](#mod), [mul](#mul), [round](#round), et [sub](#sub).\n\n### add\n\nAdditionne des nombres avec `add`. Accepte deux entrées ou plus.\n\n```\nadd 1 2 3\n```\n\n### add1\n\nPour incrémenter de 1, utilisez `add1`.\n\n### sub\n\nPour soustraire, utilisez `sub`.\n\n### div\n\nEffectue une division entière avec `div`.\n\n### mod\n\nModulo avec `mod`.\n\n### mul\n\nMultiplie avec `mul`. Accepte deux entrées ou plus.\n\n```\nmul 1 2 3\n```\n\n### max\n\nRetourne le plus grand d'une série d'entiers.\n\nCeci retournera `3` :\n\n```\nmax 1 2 3\n```\n\n### min\n\nRetourne le plus petit d'une série d'entiers.\n\n`min 1 2 3` retournera `1`.\n\n### len\n\nRetourne la longueur de l'argument en tant qu'entier.\n\n```\nlen .Arg\n```\n\n## Fonctions mathématiques à virgule flottante\n\nToutes les fonctions mathématiques opèrent sur des valeurs `float64`.\n\n### addf\n\nAdditionne des nombres avec `addf`\n\nCeci retournera `5.5` :\n\n```\naddf 1.5 2 2\n```\n\n### add1f\n\nPour incrémenter de 1, utilisez `add1f`\n\n### subf\n\nPour soustraire, utilisez `subf`\n\nCeci est équivalent à `7.5 - 2 - 3` et retournera `2.5` :\n\n```\nsubf 7.5 2 3\n```\n\n### divf\n\nEffectue une division à virgule flottante avec `divf`\n\nCeci est équivalent à `10 / 2 / 4` et retournera `1.25` :\n\n```\ndivf 10 2 4\n```\n\n### mulf\n\nMultiplie avec `mulf`\n\nCeci retournera `6` :\n\n```\nmulf 1.5 2 2\n```\n\n### maxf\n\nRetourne le plus grand d'une série de nombres à virgule flottante :\n\nCeci retournera `3` :\n\n```\nmaxf 1 2.5 3\n```\n\n### minf\n\nRetourne le plus petit d'une série de nombres à virgule flottante.\n\nCeci retournera `1.5` :\n\n```\nminf 1.5 2 3\n```\n\n### floor\n\nRetourne la plus grande valeur flottante inférieure ou égale à la valeur d'entrée.\n\n`floor 123.9999` retournera `123.0`.\n\n### ceil\n\nRetourne la plus grande valeur flottante supérieure ou égale à la valeur d'entrée.\n\n`ceil 123.001` retournera `124.0`.\n\n### round\n\nRetourne une valeur flottante avec le reste arrondi au nombre donné de chiffres\naprès la virgule décimale.\n\n`round 123.555555 3` retournera `123.556`.\n\n## Fonctions réseau\n\nHelm a une seule fonction réseau, `getHostByName`.\n\nLa fonction `getHostByName` reçoit un nom de domaine et retourne l'adresse IP.\n\n`getHostByName \"www.google.com\"` retournerait l'adresse IP correspondante de `www.google.com`.\n\nCette fonction nécessite l'option `--enable-dns` à passer sur la ligne de commande helm.\n\n## Fonctions de chemin de fichier\n\nBien que les fonctions de template Helm ne donnent pas accès au système de fichiers, elles fournissent\ndes fonctions pour travailler avec des chaînes qui suivent les conventions de chemins de fichiers.\nCelles-ci incluent [base](#base), [clean](#clean), [dir](#dir), [ext](#ext), et\n[isAbs](#isabs).\n\n### base\n\nRetourne le dernier élément d'un chemin.\n\n```\nbase \"foo/bar/baz\"\n```\n\nL'exemple ci-dessus affiche \"baz\".\n\n### dir\n\nRetourne le répertoire, en supprimant la dernière partie du chemin. Donc `dir\n\"foo/bar/baz\"` retourne `foo/bar`.\n\n### clean\n\nNettoie un chemin.\n\n```\nclean \"foo/bar/../baz\"\n```\n\nL'exemple ci-dessus résout le `..` et retourne `foo/baz`.\n\n### ext\n\nRetourne l'extension du fichier.\n\n```\next \"foo.bar\"\n```\n\nL'exemple ci-dessus retourne `.bar`.\n\n### isAbs\n\nPour vérifier si un chemin de fichier est absolu, utilisez `isAbs`.\n\n## Fonctions de réflexion\n\nHelm fournit des outils de réflexion rudimentaires. Ceux-ci aident les développeurs de templates avancés\nà comprendre les informations de type Go sous-jacentes pour une valeur particulière.\nHelm est écrit en Go et est fortement typé. Le système de types s'applique dans les\ntemplates.\n\nGo a plusieurs _kinds_ primitifs, comme `string`, `slice`, `int64`, et `bool`.\n\nGo a un système de _types_ ouvert qui permet aux développeurs de créer leurs propres types.\n\nHelm fournit un ensemble de fonctions pour chacun via les [fonctions kind](#fonctions-kind)\net les [fonctions type](#fonctions-type). Une fonction [deepEqual](#deepequal) est\négalement fournie pour comparer deux valeurs.\n\n### Fonctions Kind\n\nIl y a deux fonctions Kind : `kindOf` retourne le kind d'un objet.\n\n```\nkindOf \"hello\"\n```\n\nL'exemple ci-dessus retournerait `string`. Pour des tests simples (comme dans les blocs `if`), la\nfonction `kindIs` vous permettra de vérifier qu'une valeur est d'un kind particulier :\n\n```\nkindIs \"int\" 123\n```\n\nL'exemple ci-dessus retournera `true`.\n\n### Fonctions Type\n\nLes types sont légèrement plus difficiles à manipuler, il y a donc trois fonctions différentes :\n\n- `typeOf` retourne le type sous-jacent d'une valeur : `typeOf $foo`\n- `typeIs` est comme `kindIs`, mais pour les types : `typeIs \"*io.Buffer\" $myVal`\n- `typeIsLike` fonctionne comme `typeIs`, sauf qu'il déréférence également les pointeurs\n\n**Note :** Aucune de ces fonctions ne peut tester si quelque chose implémente une\ninterface donnée, car cela nécessiterait de compiler l'interface à l'avance.\n\n### deepEqual\n\n`deepEqual` retourne vrai si deux valeurs sont [« profondément\négales »](https://golang.org/pkg/reflect/#DeepEqual)\n\nFonctionne également pour les types non primitifs (contrairement au `eq` intégré).\n\n```\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\nL'exemple ci-dessus retournera `true`.\n\n## Fonctions de version sémantique\n\nCertains schémas de version sont facilement analysables et comparables. Helm fournit des\nfonctions pour travailler avec les versions [SemVer 2](http://semver.org). Celles-ci incluent\n[semver](#semver) et [semverCompare](#semvercompare). Vous trouverez ci-dessous également des\ndétails sur l'utilisation des plages pour les comparaisons.\n\n### semver\n\nLa fonction `semver` analyse une chaîne en une Version Sémantique :\n\n```\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_Si l'analyseur échoue, il provoquera l'arrêt de l'exécution du template avec une erreur._\n\nÀ ce stade, `$version` est un pointeur vers un objet `Version` avec les\npropriétés suivantes :\n\n- `$version.Major` : Le numéro majeur (`1` ci-dessus)\n- `$version.Minor` : Le numéro mineur (`2` ci-dessus)\n- `$version.Patch` : Le numéro de patch (`3` ci-dessus)\n- `$version.Prerelease` : La préversion (`alpha.1` ci-dessus)\n- `$version.Metadata` : Les métadonnées de build (`123` ci-dessus)\n- `$version.Original` : La version originale sous forme de chaîne\n\nDe plus, vous pouvez comparer une `Version` à une autre `version` en utilisant la\nfonction `Compare` :\n\n```\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\nL'exemple ci-dessus retournera `-1`.\n\nLes valeurs de retour sont :\n\n- `-1` si le semver donné est supérieur au semver dont la méthode `Compare` a été\n  appelée\n- `1` si la version dont la fonction `Compare` a été appelée est supérieure.\n- `0` s'ils sont de la même version\n\n(Notez que dans SemVer, le champ `Metadata` n'est pas comparé lors des opérations\nde comparaison de version.)\n\n### semverCompare\n\nUne fonction de comparaison plus robuste est fournie par `semverCompare`. Cette version\nprend en charge les plages de versions :\n\n- `semverCompare \"1.2.3\" \"1.2.3\"` vérifie une correspondance exacte\n- `semverCompare \"~1.2.0\" \"1.2.3\"` vérifie que les versions majeure et mineure\n  correspondent, et que le numéro de patch du second paramètre est _supérieur ou\n  égal au_ premier paramètre.\n\nLes fonctions SemVer utilisent la [bibliothèque semver\nMasterminds](https://github.com/Masterminds/semver), des créateurs de Sprig.\n\n### Comparaisons de base\n\nIl y a deux éléments dans les comparaisons. Premièrement, une chaîne de comparaison est une liste\nde comparaisons ET séparées par des espaces ou des virgules. Celles-ci sont ensuite séparées par || (OU)\ncomparaisons. Par exemple, `\">= 1.2 < 3.0.0 || >= 4.2.3\"` recherche une\ncomparaison qui est supérieure ou égale à 1.2 et inférieure à 3.0.0 ou est supérieure\nou égale à 4.2.3.\n\nLes comparaisons de base sont :\n\n- `=` : égal (alias vers pas d'opérateur)\n- `!=` : différent\n- `>` : supérieur à\n- `<` : inférieur à\n- `>=` : supérieur ou égal à\n- `<=` : inférieur ou égal à\n\n### Travailler avec les versions préliminaires\n\nLes préversions, pour ceux qui ne les connaissent pas, sont utilisées pour les versions de logiciels\navant les versions stables ou généralement disponibles. Des exemples de préversions incluent\nles versions de développement, alpha, bêta et release candidate. Une préversion peut être une\nversion comme `1.2.3-beta.1`, tandis que la version stable serait `1.2.3`. Dans l'\nordre de préséance, les préversions viennent avant leurs versions associées. Dans cet\nexemple `1.2.3-beta.1 < 1.2.3`.\n\nSelon la spécification de Version Sémantique, les préversions peuvent ne pas être conformes à l'API\navec leur version correspondante. Elle dit :\n\n> Une version préliminaire indique que la version est instable et pourrait ne pas\n> satisfaire les exigences de compatibilité prévues comme indiqué par sa\n> version normale associée.\n\nLes comparaisons SemVer utilisant des contraintes sans comparateur de préversion sauteront\nles versions préliminaires. Par exemple, `>=1.2.3` sautera les préversions lors de la recherche\ndans une liste de versions, tandis que `>=1.2.3-0` évaluera et trouvera les préversions.\n\nLa raison du `0` comme version préliminaire dans l'exemple de comparaison est que\nles préversions ne peuvent contenir que des alphanumériques ASCII et des tirets (avec\ndes séparateurs `.`), selon la spécification. Le tri se fait dans l'ordre de tri ASCII, encore\nselon la spécification. Le caractère le plus bas est un `0` dans l'ordre de tri ASCII (voir une [Table\nASCII](http://www.asciitable.com/))\n\nComprendre l'ordre de tri ASCII est important car A-Z vient avant a-z.\nCela signifie que `>=1.2.3-BETA` retournera `1.2.3-alpha`. Ce à quoi vous pourriez vous attendre\nde la sensibilité à la casse ne s'applique pas ici. C'est dû à l'ordre de tri ASCII qui est\nce que la spécification définit.\n\n### Comparaisons de plage avec tiret\n\nIl existe plusieurs méthodes pour gérer les plages et la première est les plages avec tirets.\nCelles-ci ressemblent à :\n\n- `1.2 - 1.4.5` qui est équivalent à `>= 1.2 <= 1.4.5`\n- `2.3.4 - 4.5` qui est équivalent à `>= 2.3.4 <= 4.5`\n\n### Caractères génériques dans les comparaisons\n\nLes caractères `x`, `X` et `*` peuvent être utilisés comme caractère générique. Cela fonctionne\npour tous les opérateurs de comparaison. Lorsqu'il est utilisé avec l'opérateur `=`, il revient à la\ncomparaison au niveau du patch (voir tilde ci-dessous). Par exemple,\n\n- `1.2.x` est équivalent à `>= 1.2.0, < 1.3.0`\n- `>= 1.2.x` est équivalent à `>= 1.2.0`\n- `<= 2.x` est équivalent à `< 3`\n- `*` est équivalent à `>= 0.0.0`\n\n### Comparaisons de plage avec tilde (Patch)\n\nL'opérateur de comparaison tilde (`~`) est pour les plages au niveau du patch lorsqu'une version\nmineure est spécifiée et les changements au niveau majeur lorsque le numéro mineur est manquant.\nPar exemple,\n\n- `~1.2.3` est équivalent à `>= 1.2.3, < 1.3.0`\n- `~1` est équivalent à `>= 1, < 2`\n- `~2.3` est équivalent à `>= 2.3, < 2.4`\n- `~1.2.x` est équivalent à `>= 1.2.0, < 1.3.0`\n- `~1.x` est équivalent à `>= 1, < 2`\n\n### Comparaisons de plage avec accent circonflexe (Majeur)\n\nL'opérateur de comparaison accent circonflexe (`^`) est pour les changements au niveau majeur une fois qu'une version\nstable (1.0.0) a été publiée. Avant une version 1.0.0, les versions mineures agissent\ncomme le niveau de stabilité de l'API. C'est utile lors des comparaisons de versions d'API car un\nchangement majeur casse l'API. Par exemple,\n\n- `^1.2.3` est équivalent à `>= 1.2.3, < 2.0.0`\n- `^1.2.x` est équivalent à `>= 1.2.0, < 2.0.0`\n- `^2.3` est équivalent à `>= 2.3, < 3`\n- `^2.x` est équivalent à `>= 2.0.0, < 3`\n- `^0.2.3` est équivalent à `>=0.2.3 <0.3.0`\n- `^0.2` est équivalent à `>=0.2.0 <0.3.0`\n- `^0.0.3` est équivalent à `>=0.0.3 <0.0.4`\n- `^0.0` est équivalent à `>=0.0.0 <0.1.0`\n- `^0` est équivalent à `>=0.0.0 <1.0.0`\n\n## Fonctions URL\n\nHelm inclut les fonctions [urlParse](#urlparse), [urlJoin](#urljoin), et\n[urlquery](#urlquery) vous permettant de travailler avec les parties d'URL.\n\n### urlParse\n\nAnalyse une chaîne pour une URL et produit un dict avec les parties de l'URL\n\n```\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\nL'exemple ci-dessus retourne un dict, contenant l'objet URL :\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nCeci est implémenté en utilisant les packages URL de la bibliothèque standard Go. Pour plus\nd'informations, consultez https://golang.org/pkg/net/url/#URL\n\n### urlJoin\n\nJoint un map (produit par `urlParse`) pour produire une chaîne URL\n\n```\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\nL'exemple ci-dessus retourne la chaîne suivante :\n```\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nRetourne la version échappée de la valeur passée en argument de sorte qu'elle soit\nadaptée à l'intégration dans la partie requête d'une URL.\n\n```\n$var := urlquery \"string for query\"\n```\n\n## Fonctions UUID\n\nHelm peut générer des UUID v4 universellement uniques.\n\n```\nuuidv4\n```\n\nL'exemple ci-dessus retourne un nouvel UUID de type v4 (généré aléatoirement).\n\n## Fonctions Kubernetes et Chart\n\nHelm inclut des fonctions pour travailler avec Kubernetes, notamment\n[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas),\n[Files](#fonctions-de-fichier), et [lookup](#lookup).\n\n### lookup\n\n`lookup` est utilisé pour rechercher une ressource dans un cluster en cours d'exécution. Lorsqu'il est utilisé avec la\ncommande `helm template`, il retourne toujours une réponse vide.\n\nVous pouvez trouver plus de détails dans la [documentation sur la fonction\nlookup](./functions_and_pipelines.md#utilisation-de-la-fonction-lookup).\n\n### .Capabilities.APIVersions.Has\n\nRetourne si une version d'API ou une ressource est disponible dans un cluster.\n\n```\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\nPlus d'informations sont disponibles dans la [documentation sur les objets\nintégrés](./builtin_objects.md).\n\n### Fonctions de fichier\n\nIl existe plusieurs fonctions qui vous permettent d'accéder aux fichiers non spéciaux dans un\nchart. Par exemple, pour accéder aux fichiers de configuration d'application. Celles-ci sont\ndocumentées dans [Accéder aux fichiers dans les templates](./accessing_files.md).\n\n_Note, la documentation de beaucoup de ces fonctions provient de\n[Sprig](https://github.com/Masterminds/sprig). Sprig est une bibliothèque de fonctions de template\ndisponible pour les applications Go._\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: Fonctions de template et pipelines\ndescription: Utilisation des fonctions dans les templates.\nsidebar_position: 5\n---\n\nJusqu'à 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.\n\nCommenç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 :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nLes 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.\n\nHelm 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.\n\n> 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.\n\n## Pipelines\n\nL'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.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nDans 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 :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Inverser l'ordre est une pratique courante dans les templates. Vous verrez `.val | quote` plus souvent que `quote .val`. Les deux pratiques sont valables.\n\nLorsque ce template est évalué, il produira le résultat suivant :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nNotez que notre `pizza` d'origine a été transformée en `\"PIZZA\"`.\n\nLorsque 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` :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nLa fonction `repeat` répétera la chaîne donnée le nombre de fois spécifié, nous obtiendrons donc ce résultat :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Utilisation de la fonction `default`\n\nUne 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 :\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nSi nous exécutons ceci normalement, nous obtiendrons notre `coffee` :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nMaintenant, supprimons le paramètre de boisson favorite dans `values.yaml` :\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nEn réexécutant `helm install --dry-run --debug fair-worm ./mychart`, nous obtiendrons ce YAML :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nDans 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 :\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nDans certains cas, une condition `if` peut être mieux adaptée que `default`. Nous les verrons dans la section suivante.\n\nLes 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.\n\n## Utilisation de la fonction `lookup`\n\nLa 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`.\n\n| paramètre  | type   |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\n`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.\n\nLes combinaisons de paramètres suivantes sont possibles :\n\n| Comportement                           | Fonction lookup                            |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\nLorsque `lookup` retourne un objet, il renvoie un dictionnaire. Ce dictionnaire peut être parcouru pour extraire des valeurs spécifiques.\n\nL'exemple suivant renverra les annotations présentes pour l'objet `mynamespace` :\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nLorsque `lookup` retourne une liste d'objets, il est possible d'accéder à la liste d'objets via le champ `items` :\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* faire quelque chose avec chaque service */}}\n{{ end }}\n```\n\nLorsqu'aucun objet n'est trouvé, une valeur vide est retournée. Cela peut être utilisé pour vérifier l'existence d'un objet.\n\nLa 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.\n\nNotez 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.\n\n## Les opérateurs sont des fonctions\n\nPour 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 `)`).\n\nPassons maintenant aux structures de contrôle : conditions, boucles et modificateurs de portée.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Premiers pas\ndescription: Un guide rapide sur les templates de chart.\nsidebar_position: 2\n---\n\nDans 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.\n\nPour commencer, examinons brièvement la structure d'un chart Helm.\n\n## Charts\n\nComme décrit dans le [Guide des charts](/topics/charts.md), les charts Helm sont structurés de la manière suivante :\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nLe 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.\n\nLe 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`.\n\nLe fichier `Chart.yaml` contient une description du chart. Vous pouvez y accéder depuis un template.\n\nLe 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.\n\n## Un premier chart\n\nPour ce guide, nous allons créer un chart simple appelé `mychart`, puis nous créerons quelques templates à l'intérieur de ce chart.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### Un aperçu rapide de `mychart/templates/`\n\nSi vous examinez le répertoire `mychart/templates/`, vous remarquerez que quelques fichiers sont déjà présents :\n\n- `NOTES.txt` : Le « texte d'aide » de votre chart. Il sera affiché aux utilisateurs lorsqu'ils exécuteront `helm install`.\n- `deployment.yaml` : Un manifeste de base pour créer un [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) Kubernetes\n- `service.yaml` : Un manifeste de base pour créer un [endpoint de service](https://kubernetes.io/docs/concepts/services-networking/service/) pour votre deployment\n- `_helpers.tpl` : Un emplacement pour les fonctions de template réutilisables dans tout le chart\n\nEt 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.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nLorsque 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.\n\n## Un premier template\n\nLe 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.\n\nComme les ConfigMaps sont des ressources de base, ils constituent un excellent point de départ pour nous.\n\nCommençons par créer un fichier appelé `mychart/templates/configmap.yaml` :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**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.\n\nLe 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.\n\nIl 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.\n\nAvec ce template simple, nous avons maintenant un chart installable. Et nous pouvons l'installer de cette façon :\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nEn utilisant Helm, nous pouvons récupérer la release et voir le template réellement chargé.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nLa 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.\n\nÀ partir de là, nous pouvons voir que les données YAML sont exactement ce que nous avons mis dans notre fichier `configmap.yaml`.\n\nMaintenant, nous pouvons désinstaller notre release : `helm uninstall full-coral`.\n\n### Ajouter un appel de template simple\n\nCoder 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.\n\n**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).\n\nModifions `configmap.yaml` en conséquence.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nLe changement majeur se trouve dans la valeur du champ `name:`, qui est maintenant `{{ .Release.Name }}-configmap`.\n\n> Une directive de template est encadrée par les blocs `{{` et `}}`.\n\nLa 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.\n\nLe 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` ».\n\nL'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.\n\nMaintenant, lorsque nous installons notre ressource, nous verrons immédiatement le résultat de l'utilisation de cette directive de template :\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nVous pouvez exécuter `helm get manifest clunky-serval` pour voir l'ensemble du YAML généré.\n\nNotez que le nom du ConfigMap dans Kubernetes est `clunky-serval-configmap` au lieu de `mychart-configmap` précédemment.\n\nÀ 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 :\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nL'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.\n\nDans 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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: Le fichier .helmignore\ndescription: Le fichier `.helmignore` permet de spécifier les fichiers que vous ne souhaitez pas inclure dans votre chart Helm.\nsidebar_position: 12\n---\n\nLe fichier `.helmignore` permet de spécifier les fichiers que vous ne souhaitez\npas inclure dans votre chart Helm.\n\nSi ce fichier existe, la commande `helm package` ignorera tous les fichiers qui\ncorrespondent aux motifs spécifiés dans le fichier `.helmignore` lors de\nl'empaquetage de votre application.\n\nCela permet d'éviter l'ajout de fichiers ou répertoires inutiles ou sensibles\ndans votre chart Helm.\n\nLe fichier `.helmignore` prend en charge les motifs de type glob Unix,\nla correspondance de chemins relatifs, et la négation (préfixée par !). Chaque\nligne ne doit contenir qu'un seul motif.\n\nVoici un exemple de fichier `.helmignore` :\n\n```\n# comment\n\n# Match any file or path named .helmignore\n.helmignore\n\n# Match any file or path named .git\n.git\n\n# Match any text file\n*.txt\n\n# Match only directories named mydir\nmydir/\n\n# Match only text files in the top-level directory\n/*.txt\n\n# Match only the file foo.txt in the top-level directory\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt\na[b-d].txt\n\n# Match any file under subdir matching temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nQuelques différences notables par rapport à .gitignore :\n- La syntaxe '**' n'est pas prise en charge.\n- La bibliothèque de correspondance utilisée est 'filepath.Match' de Go, et non fnmatch(3).\n- Les espaces en fin de ligne sont toujours ignorés (aucune séquence d'échappement n'est prise en charge).\n- Il n'y a pas de prise en charge de '\\!' comme séquence spéciale de début de ligne.\n- Le fichier ne s'exclut pas lui-même par défaut ; vous devez ajouter une entrée explicite pour `.helmignore`.\n\n\n**Vous pouvez nous aider** à améliorer ce document. Pour ajouter, corriger ou supprimer\ndes informations, [créez un ticket](https://github.com/helm/helm-www/issues) ou envoyez-nous une\npull request.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Templates Nommés\ndescription: Comment définir des templates nommés.\nsidebar_position: 9\n---\n\nIl 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.\n\nDans 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`.\n\nUn 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_.\n\nUne 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.\n\nCe 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\" }}`.\n\n## Partials et fichiers `_`\n\nJusqu'à 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.\n\nAvant 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 :\n\n* La plupart des fichiers dans `templates/` sont traités comme s'ils contenaient des manifestes Kubernetes\n* Le fichier `NOTES.txt` est une exception\n* 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.\n\nCes 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.\n\n## Déclarer et utiliser des templates avec `define` et `template`\n\nL'action `define` nous permet de créer un template nommé à l'intérieur d'un fichier template. Sa syntaxe est la suivante :\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # corps du template ici\n{{- end }}\n```\n\nPar exemple, nous pouvons définir un template pour encapsuler un bloc de labels Kubernetes :\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nNous pouvons maintenant intégrer ce template dans notre ConfigMap existant, puis l'inclure avec l'action `template` :\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nLorsque 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 :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nRemarque : un `define` ne produit pas de sortie à moins d'être appelé avec un template, comme dans cet exemple.\n\nPar convention, les charts Helm placent ces templates dans un fichier de partials, généralement `_helpers.tpl`. Déplaçons cette fonction là-bas :\n\n```yaml\n{{/* Génère les labels de base */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nPar convention, les fonctions `define` devraient avoir un simple bloc de documentation (`{{/* ... */}}`) décrivant ce qu'elles font.\n\nMême si cette définition est dans `_helpers.tpl`, elle peut toujours être accédée dans `configmap.yaml` :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nComme 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\" }}`.\n\n## Définir la portée d'un template\n\nDans 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 :\n\n```yaml\n{{/* Génère les labels de base */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nSi nous rendons ceci, nous obtiendrons une erreur comme celle-ci :\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nPour voir ce qui a été rendu, relancez avec `--disable-openapi-validation` :\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`.\nLe résultat ne sera pas celui attendu :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\nQue 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 :\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nAucune 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 :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nNotez 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.\n\nMaintenant, lorsque nous exécutons ce template avec `helm install --dry-run --debug plinking-anaco ./mychart`, nous obtenons ceci :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nMaintenant `{{ .Chart.Name }}` se résout en `mychart`, et `{{ .Chart.Version }}` se résout en `0.1.0`.\n\n## La fonction `include`\n\nSupposons que nous ayons défini un template simple qui ressemble à ceci :\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nMaintenant, supposons que je veuille insérer ceci à la fois dans la section `labels:` de mon template et aussi dans la section `data:` :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nSi nous rendons ceci, nous obtiendrons une erreur comme celle-ci :\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nPour voir ce qui a été rendu, relancez avec `--disable-openapi-validation` :\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`.\nLa sortie ne sera pas celle attendue :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nNotez 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.\n\nPour 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.\n\nVoici l'exemple ci-dessus, corrigé pour utiliser `indent` afin d'indenter correctement le template `mychart.app` :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nMaintenant le YAML produit est correctement indenté pour chaque section :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> 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.\n\nParfois, 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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Créer un fichier NOTES.txt\ndescription: Comment fournir des instructions aux utilisateurs de votre Chart.\nsidebar_position: 10\n---\n\nDans 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.\n\nPour 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.\n\nCréons un simple fichier `NOTES.txt` :\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nMaintenant, si nous exécutons `helm install rude-cardinal ./mychart`, nous verrons ce message en bas :\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nUtiliser `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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Sous-charts et Valeurs Globales\ndescription: Interaction avec les valeurs d'un sous-chart et les valeurs globales.\nsidebar_position: 11\n---\n\nJusqu'à 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.\n\nAvant de plonger dans le code, voici quelques détails importants à connaître sur les sous-charts d'application.\n\n1. Un sous-chart est considéré comme « autonome », ce qui signifie qu'il ne peut jamais dépendre explicitement de son chart parent.\n2. Pour cette raison, un sous-chart ne peut pas accéder aux valeurs de son chart parent.\n3. Un chart parent peut remplacer les valeurs des sous-charts.\n4. Helm dispose d'un concept de _valeurs globales_ accessibles par tous les charts.\n\n> 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.\n\nAu fil des exemples de cette section, ces concepts deviendront plus clairs.\n\n## Création d'un Sous-chart\n\nPour 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.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nRemarquez 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.\n\n## Ajout de Valeurs et d'un Template au Sous-chart\n\nEnsuite, 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 :\n\n```yaml\ndessert: cake\n```\n\nEnsuite, nous allons créer un nouveau template ConfigMap dans `mychart/charts/mysubchart/templates/configmap.yaml` :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nComme chaque sous-chart est un _chart autonome_, nous pouvons tester `mysubchart` indépendamment :\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Remplacement des Valeurs depuis un Chart Parent\n\nNotre 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`.\n\nPuisque `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 :\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nNotez 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` :\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nLa valeur au niveau supérieur a maintenant remplacé la valeur du sous-chart.\n\nIl 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`.\n\nParfois, cependant, vous souhaitez que certaines valeurs soient disponibles pour tous les templates. Cela s'accomplit en utilisant les valeurs globales de chart.\n\n## Valeurs Globales de Chart\n\nLes 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.\n\nLe 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`.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nGrâ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 }}`.\n\n`mychart/templates/configmap.yaml` :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml` :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nMaintenant, si nous effectuons une installation dry-run, nous verrons la même valeur dans les deux sorties :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nLes 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.\n\n## Partage de Templates avec les Sous-charts\n\nLes 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.\n\nPar exemple, nous pouvons définir un simple template comme ceci :\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nRappelez-vous que les labels sur les templates sont _partagés globalement_. Ainsi, le chart `labels` peut être inclus depuis n'importe quel autre chart.\n\nBien 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 :\n\n```yaml\n{{ include $mytemplate }}\n```\n\nL'exemple ci-dessus déréférencera `$mytemplate`. La fonction `template`, en revanche, n'accepte qu'une chaîne littérale.\n\n## Éviter l'Utilisation des Blocs\n\nLe 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.\n\nNous recommandons d'utiliser `include` à la place.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Fichiers Values\ndescription: Instructions sur l'utilisation du flag --values.\nsidebar_position: 4\n---\n\nDans 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 :\n\n- Le fichier `values.yaml` du chart\n- Si c'est un sous-chart, le fichier `values.yaml` du chart parent\n- Un fichier values passé à `helm install` ou `helm upgrade` avec le flag `-f` (`helm install -f myvals.yaml ./mychart`)\n- Des paramètres individuels passés avec `--set` (par exemple `helm install --set foo=bar ./mychart`)\n\nLa 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`.\n\nLes fichiers values sont de simples fichiers YAML. Modifions `mychart/values.yaml`, puis éditons notre template ConfigMap.\n\nEn supprimant les valeurs par défaut dans `values.yaml`, nous définirons un seul paramètre :\n\n```yaml\nfavoriteDrink: coffee\n```\n\nNous pouvons maintenant l'utiliser dans un template :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nRemarquez qu'à la dernière ligne, nous accédons à `favoriteDrink` comme attribut de `Values` : `{{ .Values.favoriteDrink }}`.\n\nVoyons comment cela est rendu.\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nPuisque `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` :\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nPuisque `--set` a une priorité plus élevée que le fichier `values.yaml` par défaut, notre template génère `drink: slurm`.\n\nLes 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 :\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nIl faudrait alors modifier légèrement le template :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nBien 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.\n\n## Supprimer une clé par défaut\n\nSi 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.\n\nPar 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 :\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nSi 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 :\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nCependant, 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 :\n\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nÀ 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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: Variables\ndescription: Utilisation des variables dans les templates.\nsidebar_position: 8\n---\n\nAprè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`.\n\nDans un exemple précédent, nous avons vu que ce code échouera :\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`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.\n\nDans 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`.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nNotez 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.\n\nL'exécution de ce code produira :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nLes 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 :\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nNotez 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 :\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nPour 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 :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nLors 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 :\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nLes 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 }}`.\n\nCependant, 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.\n\nVoici un exemple illustrant cela :\n\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # De nombreux templates Helm utiliseraient `.` ci-dessous, mais cela ne fonctionnera pas,\n    # cependant `$` fonctionnera ici\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # Je ne peux pas référencer .Chart.Name, mais je peux faire $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Valeur de appVersion dans Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nJusqu'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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Prochaines étapes\ndescription: Conclusion - quelques liens utiles vers d'autres documentations qui vous aideront.\nsidebar_position: 14\n---\n\nCe 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.\n\nCependant, 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 :\n\n- [Artifact Hub](https://artifacthub.io/packages/search?kind=0) de la CNCF est une source incontournable de charts.\n- 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.\n- Le [guide des charts](/topics/charts.md) Helm explique le flux de travail pour l'utilisation des charts.\n- Le [guide des hooks de charts](/topics/charts_hooks.md) Helm explique comment créer des hooks de cycle de vie.\n- 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.\n- La [documentation Sprig](https://github.com/Masterminds/sprig) documente plus de soixante fonctions de template.\n- La [documentation des templates Go](https://godoc.org/text/template) explique la syntaxe des templates en détail.\n- L'outil [Schelm](https://github.com/databus23/schelm) est un utilitaire pratique pour le débogage des charts.\n\nParfois, 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) :\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nEnfin, 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).\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Annexe : Techniques YAML\"\ndescription: Un examen approfondi de la spécification YAML et de son application dans Helm.\nsidebar_position: 15\n---\n\nCe guide s'est principalement concentré sur l'écriture du langage de template. Ici,\nnous allons examiner le format YAML. YAML possède des fonctionnalités utiles que nous,\nen tant qu'auteurs de templates, pouvons utiliser pour rendre nos templates moins sujets aux erreurs\net plus faciles à lire.\n\n## Scalaires et collections\n\nSelon la [spécification YAML](https://yaml.org/spec/1.2/spec.html), il existe deux\ntypes de collections et de nombreux types scalaires.\n\nLes deux types de collections sont les maps et les séquences :\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nLes valeurs scalaires sont des valeurs individuelles (par opposition aux collections).\n\n### Types scalaires en YAML\n\nDans le dialecte YAML de Helm, le type de données scalaire d'une valeur est déterminé par un\nensemble de règles complexes, incluant le schéma Kubernetes pour les définitions de ressources.\nMais lors de l'inférence des types, les règles suivantes tendent à s'appliquer.\n\nSi un entier ou un flottant est un mot non quoté, il est généralement traité comme\nun type numérique :\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nMais s'ils sont entre guillemets, ils sont traités comme des chaînes :\n\n```yaml\ncount: \"1\" # <-- chaîne, pas int\nsize: '2.34' # <-- chaîne, pas float\n```\n\nIl en va de même pour les booléens :\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # chaîne\n```\n\nLe mot pour une valeur vide est `null` (pas `nil`).\n\nNotez que `port: \"80\"` est du YAML valide, et passera à travers le moteur de template\net l'analyseur YAML, mais échouera si Kubernetes attend que `port` soit un\nentier.\n\nDans certains cas, vous pouvez forcer une inférence de type particulière en utilisant les balises de nœud YAML :\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nDans l'exemple ci-dessus, `!!str` indique à l'analyseur que `age` est une chaîne, même s'il ressemble\nà un entier. Et `port` est traité comme un entier, même s'il est entre guillemets.\n\n\n## Les chaînes de caractères en YAML\n\nUne 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\nfaçon de représenter une chaîne. Cette section explique les différentes méthodes et montre\ncomment en utiliser certaines.\n\nIl existe trois façons « en ligne » de déclarer une chaîne :\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nTous les styles en ligne doivent tenir sur une seule ligne.\n\n- Les mots non quotés (*bare words*) ne sont pas échappés. Pour cette raison, vous devez\n  faire attention aux caractères que vous utilisez.\n- Les chaînes entre guillemets doubles peuvent avoir des caractères spécifiques échappés avec `\\`. Par\n  exemple `\"\\\"Hello\\\", she said\"`. Vous pouvez échapper les sauts de ligne avec `\\n`.\n- Les chaînes entre guillemets simples sont des chaînes « littérales » et n'utilisent pas le `\\` pour échapper\n  les caractères. La seule séquence d'échappement est `''`, qui est décodée comme un seul\n  `'`.\n\nEn plus des chaînes sur une seule ligne, vous pouvez déclarer des chaînes multi-lignes :\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nL'exemple ci-dessus traitera la valeur de `coffee` comme une chaîne unique équivalente à\n`Latte\\nCappuccino\\nEspresso\\n`.\n\nNotez que la première ligne après le `|` doit être correctement indentée. Nous pourrions\ndonc casser l'exemple ci-dessus en faisant ceci :\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nComme `Latte` est incorrectement indenté, nous obtiendrions une erreur comme celle-ci :\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nDans les templates, il est parfois plus sûr de mettre une fausse « première ligne » de contenu dans un\ndocument multi-lignes juste pour se protéger de l'erreur ci-dessus :\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nNotez que quelle que soit cette première ligne, elle sera conservée dans la sortie de la\nchaîne. Donc si vous utilisez, par exemple, cette technique pour injecter le contenu d'un fichier\ndans un ConfigMap, le commentaire doit être du type attendu par\nce qui lit cette entrée.\n\n### Contrôler les espaces dans les chaînes multi-lignes\n\nDans l'exemple ci-dessus, nous avons utilisé `|` pour indiquer une chaîne multi-lignes. Mais remarquez\nque le contenu de notre chaîne était suivi d'un `\\n` final. Si nous voulons que\nle processeur YAML supprime le saut de ligne final, nous pouvons ajouter un `-` après le\n`|` :\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nMaintenant la valeur de `coffee` sera : `Latte\\nCappuccino\\nEspresso` (sans `\\n`\nfinal).\n\nD'autres fois, nous pourrions vouloir préserver tous les espaces blancs finaux. Nous pouvons le faire\navec la notation `|+` :\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nMaintenant la valeur de `coffee` sera `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nL'indentation à l'intérieur d'un bloc de texte est préservée, et entraîne également la préservation\ndes sauts de ligne :\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nDans le cas ci-dessus, `coffee` sera `Latte\\n  12 oz\\n  16\noz\\nCappuccino\\nEspresso`.\n\n### Indentation et templates\n\nLors de l'écriture de templates, vous pourriez vouloir injecter le contenu d'un\nfichier dans le template. Comme nous l'avons vu dans les chapitres précédents, il existe deux façons\nde le faire :\n\n- Utilisez `{{ .Files.Get \"FILENAME\" }}` pour obtenir le contenu d'un fichier dans le chart.\n- Utilisez `{{ include \"TEMPLATE\" . }}` pour rendre un template et ensuite placer son\n  contenu dans le chart.\n\nLors de l'insertion de fichiers dans du YAML, il est bon de comprendre les règles multi-lignes\nci-dessus. Souvent, la façon la plus simple d'insérer un fichier statique est de faire quelque chose\ncomme ceci :\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nNotez comment nous faisons l'indentation ci-dessus : `indent 2` indique au moteur de template d'indenter\nchaque ligne de « myfile.txt » avec deux espaces. Notez que nous n'indentons pas\ncette ligne de template. C'est parce que si nous le faisions, le contenu du fichier de la première ligne\nserait indenté deux fois.\n\n### Chaînes multi-lignes repliées\n\nParfois vous voulez représenter une chaîne dans votre YAML avec plusieurs lignes, mais\nvous voulez qu'elle soit traitée comme une longue ligne lors de l'interprétation. Cela s'appelle\nle « repliement ». Pour déclarer un bloc replié, utilisez `>` au lieu de `|` :\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nLa valeur de `coffee` ci-dessus sera `Latte Cappuccino Espresso\\n`. Notez que tous\nles sauts de ligne sauf le dernier seront convertis en espaces. Vous pouvez combiner les\ncontrôles d'espaces blancs avec le marqueur de texte replié, donc `>-` remplacera ou supprimera\ntous les sauts de ligne.\n\nNotez que dans la syntaxe repliée, l'indentation du texte entraînera la préservation des lignes.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nL'exemple ci-dessus produira `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Notez que\nles espaces et les sauts de ligne sont toujours présents.\n\n## Intégrer plusieurs documents dans un seul fichier\n\nIl est possible de placer plus d'un document YAML dans un seul fichier. Cela se fait\nen préfixant un nouveau document avec `---` et en terminant le document avec\n`...`\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nDans de nombreux cas, le `---` ou le `...` peuvent être omis.\n\nCertains fichiers dans Helm ne peuvent pas contenir plus d'un document. Si, par exemple, plus d'un\ndocument est fourni à l'intérieur d'un fichier `values.yaml`, seul le premier sera\nutilisé.\n\nLes fichiers de template, cependant, peuvent avoir plus d'un document. Lorsque c'est le cas, le\nfichier (et tous ses documents) est traité comme un seul objet pendant le rendu du\ntemplate. Mais ensuite le YAML résultant est divisé en plusieurs documents avant\nd'être envoyé à Kubernetes.\n\nNous recommandons de n'utiliser plusieurs documents par fichier que lorsque c'est absolument\nnécessaire. Avoir plusieurs documents dans un fichier peut être difficile à déboguer.\n\n## YAML est un sur-ensemble de JSON\n\nParce que YAML est un sur-ensemble de JSON, tout document JSON valide _devrait_ être du YAML valide.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nL'exemple ci-dessus est une autre façon de représenter ceci :\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nEt les deux peuvent être mélangés (avec précaution) :\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nCes trois exemples devraient être analysés vers la même représentation interne.\n\nBien que cela signifie que des fichiers comme `values.yaml` peuvent contenir des données JSON, Helm\nne traite pas l'extension de fichier `.json` comme un suffixe valide.\n\n## Ancres YAML\n\nLa spécification YAML fournit un moyen de stocker une référence à une valeur, et plus tard de se référer\nà cette valeur par référence. YAML appelle cela l'« ancrage » :\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nDans l'exemple ci-dessus, `&favoriteCoffee` définit une référence à `Cappuccino`. Plus tard, cette\nréférence est utilisée comme `*favoriteCoffee`. Donc `coffees` devient `Latte, Cappuccino,\nEspresso`.\n\nBien qu'il existe quelques cas où les ancres sont utiles, il y a un aspect qui\npeut causer des bugs subtils : la première fois que le YAML est consommé, la\nréférence est développée puis supprimée.\n\nDonc si nous devions décoder puis ré-encoder l'exemple ci-dessus, le YAML résultant\nserait :\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nParce que Helm et Kubernetes lisent, modifient et réécrivent souvent les fichiers YAML, les\nancres seront perdues.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: Changements depuis Helm 2\nsidebar_position: 1\n---\n\n## Changements depuis Helm 2\n\nVoici une liste exhaustive de tous les changements majeurs introduits dans Helm 3.\n\n### Suppression de Tiller\n\nDurant 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.\n\nAvec 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.\n\nAprè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.\n\nL'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.\n\nAvec 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é.\n\n### Stratégie de mise à niveau améliorée : correctifs de fusion stratégique à 3 voies\n\nHelm 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é.\n\nDans 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.\n\n#### Exemples\n\nPassons en revue quelques exemples courants pour illustrer l'impact de ce changement.\n\n##### Retour en arrière lorsque l'état actif a changé\n\nVotre é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 :\n\n```console\n$ helm install myapp ./myapp\n```\n\nUn 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.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nUn 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 :\n\n```console\n$ helm rollback myapp\n```\n\nQue se passe-t-il ?\n\nDans 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.\n\nDans 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.\n\n##### Mises à niveau lorsque l'état actif a changé\n\nDe 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 :\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nEt que l'état actif avait été modifié par une autre application pour devenir :\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nMaintenant, 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 :\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nQue se passe-t-il ?\n\nDans 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.\n\nL'état actif du cluster est modifié pour ressembler à ceci :\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nLe pod sidecar est supprimé de l'état actif. Encore plus de panique.\n\nDans 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.\n\nL'état actif du cluster est modifié pour ressembler à ceci :\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### Les noms de releases sont maintenant limités au namespace\n\nAvec 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.\n\nDans 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`).\n\nAvec 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.\n\n### Les Secrets comme backend de stockage par défaut\n\nDans 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.\n\nLe 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.\n\n[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.\n\n### Changements du chemin d'import Go\n\nDans 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.\n\n### Capabilities\n\nL'objet intégré `.Capabilities` disponible pendant la phase de rendu a été simplifié.\n\n[Objets intégrés](/chart_template_guide/builtin_objects.md)\n\n### Validation des valeurs de chart avec JSONSchema\n\nUn 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.\n\nLa validation se produit lorsque l'une des commandes suivantes est invoquée :\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\nConsultez la documentation sur les [fichiers de schéma](/topics/charts.md#schema-files) pour plus d'informations.\n\n### Consolidation de `requirements.yaml` dans `Chart.yaml`\n\nLe 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.\n\nDans Helm 2, voici à quoi ressemblait un `requirements.yaml` :\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nDans Helm 3, la dépendance est exprimée de la même manière, mais maintenant depuis votre `Chart.yaml` :\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nLes 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.\n\n### Le nom (ou --generate-name) est maintenant requis lors de l'installation\n\nDans 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`.\n\nPour ceux qui souhaitent toujours avoir un nom auto-généré, vous pouvez utiliser le flag `--generate-name` pour en créer un.\n\n### Publication de charts vers des registres OCI\n\nIl s'agit d'une fonctionnalité expérimentale introduite dans Helm 3. Pour l'utiliser, définissez la variable d'environnement `HELM_EXPERIMENTAL_OCI=1`.\n\nÀ 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.\n\nBien 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 :\n\n- 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.\n- 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.\n- 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.\n- 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.\n\nLe 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.\n\nConsultez `helm help chart` et `helm help registry` pour plus d'informations sur comment empaqueter un chart et le publier vers un registre Docker.\n\nPour plus d'informations, consultez [cette page](/topics/registries.md).\n\n### Suppression de `helm serve`\n\n`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.\n\nPour 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).\n\n### Support des charts de type bibliothèque\n\nHelm 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).\n\nLes 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.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nNous 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.\n\n### Mise à jour de l'apiVersion de Chart.yaml\n\nAvec 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`.\n\n`helm create` crée maintenant des charts en utilisant ce nouveau format, donc l'apiVersion par défaut a également été mise à jour.\n\nLes 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.\n\n### Support de la spécification des répertoires de base XDG\n\n[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.\n\nDans 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`.\n\nDans Helm 3, Helm respecte maintenant les variables d'environnement suivantes conformément à la spécification des répertoires de base XDG :\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nLes 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.\n\nPlusieurs nouvelles variables d'environnement sont également transmises à l'environnement du plugin pour s'adapter à ce changement :\n\n- `$HELM_PATH_CACHE` pour le chemin du cache\n- `$HELM_PATH_CONFIG` pour le chemin de la configuration\n- `$HELM_PATH_DATA` pour le chemin des données\n\nLes plugins Helm souhaitant prendre en charge Helm 3 devraient envisager d'utiliser ces nouvelles variables d'environnement à la place.\n\n### Renommage des commandes CLI\n\nAfin 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.\n\nDans 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`.\n\nDe plus, plusieurs autres commandes ont été renommées pour suivre les mêmes conventions :\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\nCes commandes ont également conservé leurs anciens verbes comme alias, vous pouvez donc continuer à les utiliser sous l'une ou l'autre forme.\n\n### Création automatique des namespaces\n\nLors 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`.\n\n### Qu'est-il arrivé à .Chart.ApiVersion ?\n\nHelm 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`.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: Installation\nsidebar_position: 2\n---\n\n## Installation\n\n### Pourquoi n'y a-t-il pas de paquets natifs de Helm pour Fedora et d'autres distributions Linux ?\n\nLe 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.\n\n### Pourquoi fournissez-vous un script `curl ...|bash` ?\n\nIl 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.\n\nNous 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.\n\n### Comment puis-je placer les fichiers du client Helm ailleurs que dans leurs emplacements par défaut ?\n\nHelm utilise la structure XDG pour le stockage des fichiers. Il existe des variables d'environnement que vous pouvez utiliser pour remplacer ces emplacements :\n\n- `$XDG_CACHE_HOME` : définit un emplacement alternatif pour le stockage des fichiers mis en cache.\n- `$XDG_CONFIG_HOME` : définit un emplacement alternatif pour le stockage de la configuration Helm.\n- `$XDG_DATA_HOME` : définit un emplacement alternatif pour le stockage des données Helm.\n\nNotez que si vous avez des dépôts existants, vous devrez les ajouter à nouveau avec `helm repo add...`.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: Dépannage\nsidebar_position: 4\n---\n\n## Dépannage\n\n### J'obtiens un avertissement « Unable to get an update from the \"stable\" chart repository »\n\nExé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.\n\nVous pouvez exécuter la commande suivante pour corriger votre dépôt :\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nIl 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 :\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### J'obtiens l'avertissement 'WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.'\n\nL'ancien dépôt de charts Helm de Google a été remplacé par un nouveau dépôt de charts Helm.\n\nExécutez la commande suivante pour corriger définitivement ce problème :\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nSi vous obtenez une erreur similaire pour `incubator`, exécutez cette commande :\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Quand j'ajoute un dépôt Helm, j'obtiens l'erreur 'Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available'\n\nLes 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`.\n\n### Sur GKE (Google Container Engine) j'obtiens « No SSH tunnels currently open »\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nUne autre variante de ce message d'erreur est :\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nLe problème vient du fait que votre fichier de configuration Kubernetes local doit contenir les identifiants corrects.\n\nLorsque 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.\n\n### Après la migration depuis Helm 2, `helm list` n'affiche qu'une partie (ou aucune) de mes releases\n\nIl 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 :\n\n* vous fier au namespace actuel dans le contexte kubernetes actif (comme décrit par la commande `kubectl config view --minify`),\n* spécifier le namespace correct en utilisant le flag `--namespace`/`-n`, ou\n* pour la commande `helm list`, spécifier le flag `--all-namespaces`/`-A`\n\nCela s'applique à `helm ls`, `helm uninstall` et toutes les autres commandes `helm` faisant référence à une release.\n\n### Sur macOS, le fichier `/etc/.mdns_debug` est accédé. Pourquoi ?\n\nNous 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.\n\nCela 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.\n\nSi 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.\n\nCe 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.\n\n### helm repo add échoue alors qu'il fonctionnait auparavant\n\nDans Helm 3.3.1 et versions antérieures, la commande `helm repo add <reponame> <url>` 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é.\n\nDans Helm 3.3.2 et versions ultérieures, une tentative d'ajout d'un dépôt existant produit une erreur :\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nLe 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`.\n\nCela 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).\n\n### Activer la journalisation du client Kubernetes\n\nL'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.\n\nPar exemple :\n\n```\nhelm list -v 6\n```\n\n### Les installations de Tiller ne fonctionnent plus et l'accès est refusé\n\nLes releases Helm étaient auparavant disponibles sur <https://storage.googleapis.com/kubernetes-helm/>. 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.\n\nSi 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 :\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\nL'[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 :\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\npar :\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nPour initialiser avec Helm v2.17.0 :\n\n`helm init —upgrade`\n\nOu 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 :\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: Désinstallation\nsidebar_position: 3\n---\n\n## Désinstallation\n\n### Je veux supprimer Helm de mon ordinateur. Où se trouvent tous ses fichiers ?\n\nEn plus du binaire `helm`, Helm stocke certains fichiers aux emplacements suivants :\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nLe tableau suivant indique le dossier par défaut pour chacun de ces emplacements, selon le système d'exploitation :\n\n| Système d'exploitation | Chemin du cache             | Chemin de configuration          | Chemin des données        |\n|------------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux                  | `$HOME/.cache/helm `        | `$HOME/.config/helm `            | `$HOME/.local/share/helm` |\n| macOS                  | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm `     |\n| Windows                | `%TEMP%\\helm  `             | `%APPDATA%\\helm `                | `%APPDATA%\\helm`          |\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/_category_.json",
    "content": "{\n  \"link\": { \"type\": \"doc\", \"id\": \"helm-category\" }\n}\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\nHelm, Le gestionnaire de paquets pour Kubernetes\n\n### Synopsis\n\nLe gestionnaire de paquets pour Kubernetes\n\nActions courantes de Helm :\n\n- `helm search` :    cherche des charts installées dans Kubernetes\n- `helm pull` :      télécharge l'archive chart dans le répertoire courant\n- `helm install` :   installe le chart dans le namespace du cluster Kubernetes\n- `helm list` :      liste les versions de charts installées dans le namespace du cluster Kubernetes\n\nVariables d'environnement :\n\n| Nom                                | Description                                                                                        |\n|------------------------------------|----------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | définit un répertoire alternatif pour stocker les fichiers du cache.                               |\n| $HELM_CONFIG_HOME                  | définit un répertoire alternatif pour stocker les fichiers de configuration.                       |\n| $HELM_DATA_HOME                    | définit un répertoire alternatif pour stocker les fichiers de données.                             |\n| $HELM_DEBUG                        | indique si Helm tourne en mode Debug                                                               |\n| $HELM_DRIVER                       | définit le driver du stockage du backend. Il peut être: configmap, secret, memory, sql.            |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | définit la chaîne de caractères que le driver de stockage SQL doit utiliser.                       |\n| $HELM_MAX_HISTORY                  | définit le nombre maximum de versions helm conservées.                                             |\n| $HELM_NAMESPACE                    | définit le namespace des operations helm.                                                          |\n| $HELM_NO_PLUGINS                   | désactive les plugins. Mettre HELM_NO_PLUGINS=1 pour désactiver les plugins.                       |\n| $HELM_PLUGINS                      | définit le chemin du répertoire de plugins.                                                        |\n| $HELM_REGISTRY_CONFIG              | définit le chemin de la configuration du registre.                                                 |\n| $HELM_REPOSITORY_CACHE             | définit le chemin du repertoire cache.                                                             |\n| $HELM_REPOSITORY_CONFIG            | définit le chemin de la configuration du répertoire.                                               |\n| $KUBECONFIG                        | définit un chemin alternatif de configuration de kubernetes (par défaut \"~/.kube/config\")          |\n| $HELM_KUBEAPISERVER                | définit le point d'entrée API du serveur Kubernetes pour l'authentification                        |\n| $HELM_KUBECAFILE                   | définit le fichier de l'autorité de certification de Kubernetes.                                   |\n| $HELM_KUBEASGROUPS                 | définit le groupe à utiliser pour anonymisation en utilisant une liste csv.                        |\n| $HELM_KUBEASUSER                   | définit le nom à utiliser pour anonymiser l'operation.                                             |\n| $HELM_KUBECONTEXT                  | définit le nom du contexte kubeconfig.                                                             |\n| $HELM_KUBETOKEN                    | définit le canal KubeToken utilisé pour l'authentification.                                        |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indique si la vérification du certificat de l'API ne doit pas être faite. (peu sûr)                |\n| $HELM_KUBETLS_SERVER_NAME          | définit le nom du serveur utilisé pour valider le certificat de l'API Kubernetes.                  |\n| $HELM_BURST_LIMIT                  | définit la limite burst au cas où le serveur contient plusieurs CRDs (par défaut 100, -1 désactive)|\n| $HELM_QPS                          | définit le nombre de requêtes par seconde lorsqu'un grand nombre d'appels dépasse les valeurs de burst |\n\nHelm stocke le cache, la configuration, et les données suivant les configurations serveur suivantes :\n\n- Si la variable d'environnement `HELM_*_HOME` est positionnée, elle sera utilisée\n- Sinon, sur les systèmes supportant les spécifications XDG base directory, les variables XDG seront utilisées\n- Lorsqu'aucun autre chemin n'est positionné, le chemin par défaut sera celui définit par le système d'exploitation OS\n\nPar défaut, les répertoires par défaut dépendent du système d'exploitation OS:\n\n| OS               | Chemin Cache              | Chemin Configuration           | Chemin Données          |\n|------------------|---------------------------|--------------------------------|-------------------------|\n| Linux            | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm |\n| macOS            | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm      |\n| Windows          | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm          |\n\n\n### Options\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n  -h, --help                            Aide pour Helm\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, hors burst\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n### VOIR AUSSI\n\n* [helm completion](./helm_completion.md)\t - génère des scripts d'autocomplétion pour le shell spécifié\n* [helm create](./helm_create.md)\t - crée un nouveau chart avec le nom donné\n* [helm dependency](./helm_dependency.md)\t - gère les dépendances d'un chart\n* [helm env](./helm_env.md)\t - informations sur l'environnement client Helm\n* [helm get](./helm_get.md)\t - télécharge des informations étendues d'une release nommée\n* [helm history](./helm_history.md)\t - récupère l'historique d'une release\n* [helm install](./helm_install.md)\t - installe un chart\n* [helm lint](./helm_lint.md)\t - examine un chart pour détecter d'éventuels problèmes\n* [helm list](./helm_list.md)\t - liste les releases\n* [helm package](./helm_package.md)\t - empaquète un répertoire chart dans une archive chart\n* [helm plugin](./helm_plugin.md)\t - installe, liste ou désinstalle des plugins Helm\n* [helm pull](./helm_pull.md)\t - télécharge un chart depuis un dépôt et (optionnellement) le décompresse localement\n* [helm push](./helm_push.md)\t - pousse un chart vers un dépôt distant\n* [helm registry](./helm_registry.md)\t - connexion ou déconnexion d'un registre\n* [helm repo](./helm_repo.md)\t - ajoute, liste, supprime, met à jour et indexe des dépôts de charts\n* [helm rollback](./helm_rollback.md)\t - restaure une release à une révision précédente\n* [helm search](./helm_search.md)\t - recherche un mot-clé dans les charts\n* [helm show](./helm_show.md)\t - affiche les informations d'un chart\n* [helm status](./helm_status.md)\t - affiche le statut de la release nommée\n* [helm template](./helm_template.md)\t - effectue le rendu local des templates\n* [helm test](./helm_test.md)\t - exécute les tests d'une release\n* [helm uninstall](./helm_uninstall.md)\t - désinstalle une release\n* [helm upgrade](./helm_upgrade.md)\t - met à niveau une release\n* [helm verify](./helm_verify.md)\t - vérifie qu'un chart à un chemin donné a été signé et est valide\n* [helm version](./helm_version.md)\t - affiche les informations de version du client\n\n###### Généré automatiquement par spf13/cobra le 14-Jan-2026"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\ngénérer des scripts d'auto-complétion pour le shell spécifié\n\n### Synopsis\n\nGénérer des scripts d'auto-complétion pour Helm pour le shell spécifié.\n\n\n### Options\n\n```\n  -h, --help   Aide pour la complétion\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de paquets Helm pour Kubernetes\n* [helm completion bash](/helm/helm_completion_bash.md) - Générer des scripts d'auto-complétion pour bash\n* [helm completion fish](/helm/helm_completion_fish.md)\t- Générer des scripts d'auto-complétion pour fish\n* [helm completion powershell](/helm/helm_completion_powershell.md) - Générer des scripts d'auto-complétion pour powershell\n* [helm completion zsh](/helm/helm_completion_zsh.md) - Générer des scripts d'auto-complétion pour zsh\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\ngénérer des scripts d'auto-complétion pour bash\n\n### Synopsis\n\nGénérer des scripts d'auto-complétion pour Helm pour le shell bash.\n\nPour charger les complétions dans votre session shell courante :\n\n    source <(helm completion bash)\n\nPour charger les complétions pour chaque nouvelles sessions, exécutez une fois :\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\nVous devez relancer un nouveau shell pour que cette configuration prenne effet.\n\n\n```\nhelm completion bash [flags]\n```\n\n### Options\n\n```\n  -h, --help              Aide pour bash\n      --no-descriptions   Désactiver les descriptions des complétions\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm completion](./helm_completion.md) - Générer des scripts d'auto-complétion pour le shell spécifié\n\n###### Auto généré par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\ngénérer des scripts d'auto-complétion pour fish\n\n### Synopsis\n\nGénérer des scripts d'auto-complétion pour Helm pour le shell fish.\n\nPour charger les complétions dans votre session shell courante :\n\n    helm completion fish | source\n\nPour charger les complétions pour chaque nouvelle session, exécutez une fois :\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\nVous devez relancer un nouveau shell pour que cette configuration prenne effet.\n\n\n```\nhelm completion fish [flags]\n```\n\n### Options\n\n```\n  -h, --help              Aide pour fish\n      --no-descriptions   Désactiver les descriptions des complétions\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm completion](/helm/helm_completion.md) - Générer des scripts d'auto-complétion pour le shell spécifié\n\n###### Généré automatiquement par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\ngénérer des scripts d'auto-complétion pour powershell\n\n### Synopsis\n\nGénérer des scripts d'auto-complétion Helm pour PowerShell.\n\nPour charger les complétions dans votre session shell actuelle :\n`PS C:\\> helm completion powershell | Out-String | Invoke-Expression`\n\nPour charger les complétions pour chaque nouvelle session, ajoutez la sortie de la commande ci-dessus à votre profil PowerShell.\n\n\n```\nhelm completion powershell [flags]\n```\n\n### Options\n\n```\n  -h, --help              Aide pour powershell\n      --no-descriptions   Désactiver les descriptions pour les complétions\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n* [helm completion](/helm/helm_completion.md) - Générer des scripts d'auto-complétion pour un shell spécifique\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\ngénérer des scripts d'auto-complétion pour Zsh\n\n### Synopsis\n\nGénérer des scripts d'auto-complétion pour Helm pour Zsh\n\nPour charger les complétions dans votre session courante shell :\n\n    source <(helm completion zsh)\n\nPour charger les complétions pour chaque nouvelle session shell, exécutez une fois :\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### Options\n\n```\n  -h, --help              Aide pour zsh\n      --no-descriptions   Désactiver les descriptions des complétions\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm completion](/helm/helm_completion.md) - Générer des scripts d'auto-complétion pour un shell spécifique\n\n###### Généré automatiquement par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\ncréer un nouveau chart avec le nom donné\n\n### Synopsis\n\nCette commande crée un dossier chart ainsi que les fichiers et répertoires courants utilisés dans un chart.\n\nPar exemple, `helm create foo` va créer une structure de répertoires qui ressemble à ceci :\n\n    foo/\n    ├── .helmignore   # Contient des modèles à ignorer lors de l’empaquetage des charts Helm\n    ├── Chart.yaml    # Informations à propos de votre chart\n    ├── values.yaml   # Valeurs par défaut pour vos templates\n    ├── charts/       # Charts dont dépend votre chart\n    └── templates/    # Fichiers de template\n        └── tests/    # Fichiers de test\n\n`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.\nSi 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.\n\n\n```\nhelm create NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help             Aide pour la commande create\n  -p, --starter string   Le nom ou le chemin absolu vers le dossier de démarrage Helm\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\ngestion des dépendances d'un chart\n\n### Synopsis\n\nGère les dépendances d'un chart.\n\nLes 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.\n\nLes 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/`.\n\nPar exemple, ce fichier Chart.yaml déclare deux dépendances :\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\nLe champ `name` doit correspondre au nom du chart tel qu'indiqué dans le fichier `Chart.yaml` de ce chart.\n\nLe champ `version` doit contenir une version sémantique ou une plage de versions.\n\nL'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 `@`.\n\nÀ 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 :\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\nSi 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.\n\n### Options\n\n```\n  -h, --help   Aide pour la commande dependency\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes.\n* [helm dependency build](/helm/helm_dependency_build.md) - Reconstruire le répertoire charts/ en fonction du fichier Chart.lock\n* [helm dependency list](/helm/helm_dependency_list.md) - Lister les dépendances pour un chart donné\n* [helm dependency update](/helm/helm_dependency_update.md) - Met à jour le répertoire charts/ basé sur le contenu du fichier Chart.yaml\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\nreconstruire le répertoire charts/ à partir du fichier Chart.lock\n\n### Synopsis\n\nReconstruire le répertoire charts/ à partir du fichier Chart.lock.\n\nCette 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`.\n\nSi aucun fichier lock n'est trouvé, la commande `helm dependency build` aura le même comportement que la commande `helm dependency update`.\n\n```\nhelm dependency build CHART [flags]\n```\n\n### Options\n\n```\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n  -h, --help                       Aide pour la commande build\n      --insecure-skip-tls-verify   Ignore les vérifications du certificat TLS pour le téléchargement du chart\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --keyring string             Porte-clés contenant des clés publiques (par défaut \"~/.gnupg/pubring.gpg\")\n      --password string            Mot de passe du dépôt de charts où se trouve le chart demandé\n      --plain-http                 Utilise une connexion HTTP non sécurisée pour le téléchargement du chart\n      --skip-refresh               Ne pas actualiser le cache du dépôt local\n      --username string            Nom d'utilisateur du dépôt de charts où se trouve le chart demandé\n      --verify                     Vérifier les paquets par rapport aux signatures\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du dépôt mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm dependency](/helm/helm_dependency.md) - Gérer les dépendances d'un chart\n\n###### Généré automatiquement par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\nliste les dépendances pour un chart donné\n\n### Synopsis\n\nListe toutes les dépendances déclarées dans un chart.\n\nCela prend en entrée les archives de chart et le répertoire des charts. Cela ne modifiera pas le contenu d'un chart.\n\nCela produira une erreur si le chart ne peut pas être chargé.\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### Options\n\n```\n  -h, --help                 Aide pour la commande list\n      --max-col-width uint   Largeur maximal de colonne pour le tableau de sortie (par defaut 80)\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utilisé pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm dependency](/helm/helm_dependency.md) - Gérer les dépendances d'un chart\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\nmet à jour le dossier charts/ basé sur le contenu du fichier Chart.yaml\n\n### Synopsis\n\nMet à jour les dépendances sur le disque pour correspondre au fichier `Chart.yaml`.\n\nCette 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.\n\nEn 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.\n\nIl 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.\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### Options\n\n```\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n  -h, --help                       Aide pour la commande update\n      --insecure-skip-tls-verify   Ignore les vérifications du certificat TLS pour le téléchargement du chart\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --keyring string             Porte-clés contenant des clés publiques (par défaut \"~/.gnupg/pubring.gpg\")\n      --password string            Mot de passe du dépôt de charts où se trouve le chart demandé\n      --plain-http                 Utilise une connexion HTTP non-sécurisée pour le téléchargement du chart\n      --skip-refresh               Ne pas actualiser le cache du dépôt local\n      --username string            Nom d'utilisateur du dépôt de charts où se trouve le chart demandé\n      --verify                     Vérifier les paquets par rapport aux signatures\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du dépôt mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm dependency](/helm/helm_dependency.md) - Gérer les dépendances d'un chart\n\n###### Généré automatiquement par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\ninformations sur l'environnement du client Helm\n\n### Synopsis\n\n\nLa commande `env`, affiche toutes les informations sur l'environnement utilisé par Helm.\n\n\n```\nhelm env [flags]\n```\n\n### Options\n\n```\n  -h, --help   Aide pour la commande env\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire officiel de paquets Helm pour Kubernetes\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\ntélécharger les informations détaillées d'une version donnée\n\n### Synopsis\n\nCette commande se compose de plusieurs sous-commandes qui peuvent être utilisées pour obtenir des informations détaillées sur la version, cela inclut :\n\n- Les valeurs utilisées pour générer la version\n- Le fichier manifeste généré\n- Les notes fournies par le chart d'une version\n- Les hooks associés avec la version\n- Les métadonnées de la version\n\n\n### Options\n\n```\n  -h, --help   Aide pour la commande get\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n* [helm get all](/helm/helm_get_all.md) - Télécharge toutes les informations d'une version donnée\n* [helm get hooks](/helm/helm_get_hooks.md) - Télécharge tous les hooks pour une version donnée\n* [helm get manifest](/helm/helm_get_manifest.md) - Télécharge le manifeste d'une version donnée\n* [helm get metadata](/helm/helm_get_metadata.md) - Cette commande récupère les métadonnées d'une version donnée\n* [helm get notes](/helm/helm_get_notes.md) - Télécharge les notes d'une version donnée\n* [helm get values](/helm/helm_get_values.md) - Télécharge le fichier valeurs d'une version donnée\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\ntélécharge toutes les informations pour une version donnée\n\n### Synopsis\n\nCette 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. \n\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help              Aide pour la commande get all\n      --revision int      Récupère la version donnée avec sa révision\n      --template string   Template en Go pour formatter la sortie, ex : {{.Release.Name}}\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\ntélécharge tous les hooks pour une version donnée\n\n### Synopsis\n\nCette commande télécharge les hooks pour une version donnée.\n\nLes hooks sont formatés en YAML et séparés par le séparateur YAML `---\\n`. \n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help           Aide pour la commande get hooks\n      --revision int   Récupère la version donnée avec sa révision\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\ntélécharge le manifeste pour une version donnée\n\n### Synopsis\n\nCette commande récupère le manifeste généré pour une version donnée.\n\nUn 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.\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help           Aide pour la commande get manifest\n      --revision int   Récupère la version donnée avec sa révision\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\nCette commande récupère les métadonnées pour une version donnée\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help            Aide pour la commande get metadata\n  -o, --output format   Affiche la sortie sous différents formats. Valeurs possibles : table, json, yaml (par défaut table)\n      --revision int    Spécifie la révision\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\ntélécharge les notes pour une version donnée\n\n### Synopsis\n\n\nCette commande affiche les notes fournies pour une version de chart donnée.\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help           Aide pour la commande get notes\n      --revision int   Récupère la version donnée avec sa révision\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utilisé pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\ntélécharge le fichier de valeurs d'une version donnée\n\n### Synopsis\n\nCette commande télécharge un fichier de valeurs d'une version donnée\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -a, --all             Récupère toutes les valeurs (calculées)\n  -h, --help            Aide pour la commande get values\n  -o, --output format   Affiche la sortie sous différents formats. Valeurs possibles : table, json, yaml (par défaut table)\n      --revision int    Récupère la version donnée avec sa révision\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\nrécupère l'historique des versions\n\n### Synopsis\n\nCette commande affiche l'historique des revisions pour une version donnée.\n\nUn 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.\n\nL'historique de la version est affiché sous la forme d'un tableau, ex :\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help            Aide pour la commande history\n      --max int         Nombre maximum de révisions à inclure dans l'historique (par défaut 256)\n  -o, --output format   Affiche la sortie dans un format spécifique. Valeurs possibles : table, json, yaml (par défaut table)\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\ninstalle un chart\n\n### Synopsis\n\nCette commande installe une archive de chart.\n\nL'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.\n\nPour 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.\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\nou\n\n    $ helm install --set name=prod myredis ./redis\n\nou\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\nou\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\nou\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\nVous 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é :\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\nVous 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 :\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\nDe même, dans l'exemple suivant, 'foo' est défini sur '[\"four\"]' :\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\nEt dans l'exemple suivant, 'foo' est défini sur '{\"key1\":\"value1\",\"key2\":\"bar\"}' :\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\nPour 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.\n\nL'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.\n\nSi 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.\n\nIl y a six manières différentes d'exprimer le chart que vous souhaitez installer :\n\n1. Par référence du chart : `helm install mymaria example/mariadb`\n2. Par le chemin d'accès vers un chart compressé : `helm install mynginx ./nginx-1.2.3.tgz`\n3. Par le chemin d'accès vers un chart décompressé : `helm install mynginx ./nginx`\n4. Par l'URL absolue : `helm install mynginx https://example.com/charts/nginx-1.2.3.tgz`\n5. Par référence du chart et l'URL du dépôt : `helm install --repo https://example.com/charts/ mynginx nginx`\n6. Par les registres OCI : `helm install mynginx --version 1.2.3 oci://example.com/charts/nginx`\n\nRÉFÉRENCES DES CHARTS\n\nUne référence de chart est un moyen pratique de référencer un chart dans un référentiel de charts.\n\nLorsque 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`.\n\nPour 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`.\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### Options\n\n```\n      --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é\n      --ca-file string                             Vérifie les certificats des serveurs ayant activé HTTPS en utilisant ce fichier de certificat racine (CA bundle)\n      --cert-file string                           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n      --create-namespace                           Créer le namespace de la version s'il n'est pas présent\n      --dependency-update                          Met à jour les dépendances si elles sont manquantes avant l'installation du chart\n      --description string                         Ajoute une description personnalisée\n      --devel                                      Utiliser également les versions de développement. Équivalent à version '>0.0.0-0'. Si --versions est fixé, ceci est ignoré\n      --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\n      --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\n      --enable-dns                                 Active les recherches DNS lors du rendu des modèles\n      --force                                      Force les mise à jour des ressources en utilisant une stratègie de remplacement\n  -g, --generate-name                              Génère le nom (et omet le paramètre NAME)\n  -h, --help                                       Aide pour la commande install\n      --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\n      --hide-secret                                Masque les Secrets Kubernetes lors de l'utilisation de l'argument --dry-run\n      --insecure-skip-tls-verify                   Ignore les vérifications de certificat TLS lors du téléchargement du chart\n      --key-file string                            Identifie le client HTTPS en utilisant ce fichier de clé SSL\n      --keyring string                             Emplacement des clés publiques utilisées pour la vérification (par defaut \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Étiquettes qui seront ajoutées aux métadonnées de la publication. Doit être séparé par des virgules. (par defaut [])\n      --name-template string                       Spécifie un modèle à utiliser pour le nom de la publication\n      --no-hooks                                   Empêche les hooks de fonctionner pendant l'installation\n  -o, --output format                              Affiche la sortie dans un format spécifique. Valeurs possibles : table, json, yaml (par defaut table)\n      --pass-credentials                           Transmet les informations d'identification à tous les domaines\n      --password string                            Mot de passe du dépôt de chart où est localisé le chart demandé\n      --plain-http                                 Utiliser des connexion HTTP non sécurisées pour le téléchargement du chart\n      --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é.\n      --post-renderer-args postRendererArgsSlice   Un argument pour le post-rendu (peut être spécifié plusieurs fois) (par défaut [])\n      --render-subchart-notes                      Si défini, génère les notes du sous-chart avec le chart parent\n      --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\n      --repo string                                Url du dépôt de chart où est localisé le chart demandé\n      --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)\n      --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)\n      --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)\n      --set-literal stringArray                    Défini une valeur littérale de type STRING en ligne de commande\n      --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)\n      --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\n      --skip-schema-validation                     Si défini, désactive la validation du schéma JSON\n      --take-ownership                             Si défini, l'installation ignorera la vérification des annotations Helm et prendra possession des ressources existantes\n      --timeout duration                           Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s)\n      --username string                            Nom d'utilisateur du dépôt de chart où est localisé le chart demandé\n  -f, --values strings                             Spécifie les valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs)\n      --verify                                     Vérifie le paquet avant de l'utiliser\n      --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\n      --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'\n      --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'\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utilisé pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\nexamine un chart pour détecter d'éventuels problèmes\n\n### Synopsis\n\nCette commande prend un chemin vers un chart et lance une série de tests pour vérifier que le chart est correctement formé.\n\nSi 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].\n\n\n```\nhelm lint PATH [flags]\n```\n\n### Options\n\n```\n  -h, --help                      Aide pour la commande lint\n      --kube-version string       Version de Kubernetes utilisée pour les vérifications des capacités et des dépréciations\n      --quiet                     Affiche uniquement les avertissements et les erreurs\n      --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)\n      --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)\n      --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)\n      --set-literal stringArray   Défini une valeur littérale de type STRING en ligne de commande\n      --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)\n      --skip-schema-validation    Si défini, désactive la validation du schéma JSON\n      --strict                    Échoue en cas d'avertissements\n  -f, --values strings            Spécifie les valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs)\n      --with-subcharts            Vérifie les sous-charts dépendants\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\nliste les publications\n\n### Synopsis\n\nCette commande liste toutes les publications pour un namespace donné (utilise le namespace du contexte si le namespace n'est pas spécifié).\n\nPar 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'.\n\nPar défaut, les éléments sont triés par ordre alphabétique. Vous pouvez utiliser l'option '-d' pour trier par date de publication.\n\nSi 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.\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\nSi 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).\n\nPar défaut, jusqu'à 256 éléments peuvent être renvoyés. Pour limiter cela, utilisez l'option '--max'.\nDé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.\nL'utilisation de l'option '--max' avec l'option '--offset' vous permet de parcourir les résultats pages par pages.\n\n```\nhelm list [flags]\n```\n\n### Options\n\n```\n  -a, --all                  Affiche toutes les publications sans aucun filtre appliqué\n  -A, --all-namespaces       Liste les publications à travers tous les namespaces\n  -d, --date                 Trie par date de publication\n      --deployed             Affiche les publications déployées. Si aucune autre option n'est spécifiée, celle-ci sera automatiquement activée\n      --failed               Affiche les publications échouées\n  -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\n  -h, --help                 Aide pour la commande list\n  -m, --max int              Nombre maximum de publications à récupérer (par défaut 256)\n      --no-headers           Ne pas afficher les en-têtes lors de l'utilisation de sortie par défaut\n      --offset int           Index de la prochaine publication dans la liste, utilisé pour décaler à partir de la valeur de départ\n  -o, --output format        Affiche la sortie dans un format spécifique. Valeurs possible : table, json, yaml (par défaut table)\n      --pending              Affiche les publications en attente\n  -r, --reverse              Inverse l'ordre de tri\n  -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\n  -q, --short                Format de la liste de sortie courte (silencieux)\n      --superseded           Affiche les publications remplacées\n      --time-format string   Format du temps en utilisant le formateur de temps de GoLang. Exemple : --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          Affiche les publications désinstallées (Si 'helm uninstall --keep-history' a été utilisé)\n      --uninstalling         Affiche les publications en cours de désinstallation\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\nemballe un dossier de chart dans une archive de chart \n\n### Synopsis\n\nCette commande, emballe un chart dans un fichier archive versionné.\nSi 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.\n\nLes archives de chart versionnés sont utilisées par les dépôts de paquets Helm.\n\nPour signer un chart, utilisez l'argument '--sign'. Dans la plupart des cas, vous devez également fournir  '--keyring path/to/secret/keys' et '--key keyname'.\n\n  `$ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg`\n\nSi 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.\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Options\n\n```\n      --app-version string       Définit l'appVersion du chart pour cette version\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n  -u, --dependency-update        Met à jour les dépendances depuis le fichier \"Chart.yaml\" vers le dossier \"charts/\" avant de l'emballer\n  -d, --destination string       Emplacement pour écrire le chart. (par défaut \".\")\n  -h, --help                     Aide pour la commande package\n      --insecure-skip-tls-verify   Ignore les vérifications du certificat TLS pour le téléchargement du chart\n      --key string               Nom de la clé à utiliser lors de la signature. Utilisé si '--sign' est vrai\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --keyring string             Emplacement du trousseau de clés public (par défaut \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     Emplacement du fichier qui contient la passphrase pour la clé de signature. Utilisez \"-\" pour lire depuis stdin.\n      --password string            Mot de passe du dépôt de charts où se trouve le chart demandé\n      --plain-http                 Utilise une connexion HTTP non sécurisée pour le téléchargement du chart\n      --sign                     Utilise une clé privée PGP pour signer ce paquet\n      --username string            Nom d'utilisateur du dépôt de charts où se trouve le chart demandé\n      --version string             Définit la version de ce chart (version semver)\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utilisé pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](./helm.md) - Le gestionnaire de package Helm pour Kubernetes.\n\n###### Auto généré par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\ninstaller, lister ou désinstaller des plugins Helm.\n\n### Synopsis\n\nGère les plugins Helm côté client.\n\n\n### Options\n\n```\n  -h, --help   Aide pour la commande plugin\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n* [helm plugin install](/helm/helm_plugin_install.md) - Installe un ou plusieurs plugins Helm\n* [helm plugin list](/helm/helm_plugin_list.md) - Liste les plugins Helm installés\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - Désinstalle un ou plusieurs plugins Helm\n* [helm plugin update](/helm/helm_plugin_update.md) - Met à jour un ou plusieurs plugins Helm"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\ninstalle un ou plusieurs plugins Helm\n\n### Synopsis\n\nCette commande vous permet d'installer un plugin depuis une URL vers un dépôt VCS ou un chemin local.\n\n\n```\nhelm plugin install [options] <path|url>... [flags]\n```\n\n### Options\n\n```\n  -h, --help             Aide pour la commande install\n      --version string   Spécifie une contrainte de version. Si cela n'est pas spécifié, la dernière version sera installée\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm plugin](/helm/helm_plugin.md) - Installer, lister ou désinstaller des plugins Helm\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\nliste les plugins Helm installés\n\n\n```\nhelm plugin list [flags]\n```\n\n### Options\n\n```\n  -h, --help   Aide pour la commande list\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm plugin](/helm/helm_plugin.md) - Installer, lister ou désinstaller des plugins Helm\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\ndésinstalle un ou plusieurs plugins Helm\n\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Options\n\n```\n  -h, --help   Aide pour la commande uninstall\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utilisé pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm plugin](/helm/helm_plugin.md) - Installer, lister ou désinstaller des plugins Helm\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\nmet à jour un ou plusieurs plugins Helm\n\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### Options\n\n```\n  -h, --help   Aide pour la commande update\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm plugin](/helm/helm_plugin.md) - Installer, lister ou désinstaller des plugins Helm\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\nTélécharge un chart depuis un dépôt et (optionnellement) le décompresse dans un répertoire local.\n\n### Synopsis\n\nRécupère un package depuis un dépôt de packages et le télécharge localement.\n\nCela 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.\n\nDes 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.\n\nSi 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.\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n  -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 \".\")\n      --devel                      Utilise les versions de développement également. Équivalent à version '>0.0.0-0'. Si --version est fixé, cela sera ignoré\n  -h, --help                       Aide pour la commande pull\n      --insecure-skip-tls-verify   Ignore les vérifications du certificat TLS pour le téléchargement du chart\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --keyring string             Emplacement des clés publiques utilisées pour la vérification (par défaut \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           Transmettre les informations d'identification à tous les domaines\n      --password string            Mot de passe du répertoire de chart\n      --plain-http                 Utilise une connexion HTTP non-sécurisée pour le téléchargement du chart\n      --prov                       Récupérer le fichier de provenance, mais n'effectue pas de vérification\n      --repo string                URL du répertoire de chart\n      --untar                      Si fixé à true, décompresse le chart après l'avoir téléchargé\n      --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 \".\")\n      --username string            Nom d'utilisateur du répertoire de chart\n      --verify                     Vérifie le package avant de l'utiliser\n      --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\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes.\n\n###### Généré automatiquement par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\nPousse un chart à distance\n\n### Synopsis\n\nTransfert un chart vers un registre.\n\nSi le chart est associé à un fichier de provenance, il sera également transféré avec.\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### Options\n\n```\n      --ca-file string              Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n  -h, --help                       Aide pour la commande push\n      --insecure-skip-tls-verify   Passe les vérifications du certificat TLS pour le transfert du chart\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --password string            Mot de passe du dépôt de chart où est localisé le chart demandé\n      --plain-http                 Utilise une connexion HTTP non-sécurisée pour le transfert du chart\n      --username string            Nom d'utilisateur du dépôt de chart où est localisé le chart demandé\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](./helm.md) - Le gestionnaire de package Helm pour Kubernetes\n\n###### Auto généré par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\nSe connecter ou se déconnecter d'un registre\n\n### Synopsis\n\nCette commande se compose de plusieurs sous-commandes pour interagir avec des registres.\n\n\n### Options\n\n```\n  -h, --help   Aide pour la commande registry\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n* [helm registry login](/helm/helm_registry_login.md) - Se connecter à un registre\n* [helm registry logout](/helm/helm_registry_logout.md) - Se déconnecter d'un registre\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\nSe connecter à un registre\n\n### Synopsis\n\n\nAuthentification sur un registre distant\n\n\n```\nhelm registry login [host] [flags]\n```\n\n### Options\n\n```\n      --ca-file string     Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string   Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n  -h, --help               Aide pour la commande login\n      --insecure           Autorise la connexion TLS au registre sans certificat\n      --key-file string    identifie le client de registre à l'aide de ce fichier de clé SSL\n  -p, --password string    Mot de passe du registre ou jeton d'identification\n      --password-stdin     Lire le mot de passe ou le token d'identification depuis stdin\n      --plain-http         Utilise des connexions HTTP non sécurisées pour le téléversement du chart\n  -u, --username string    Nom d'utilisateur du registre\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm registry](/helm/helm_registry.md) - Se connecter et se déconnecter d'un registre\n\n###### Généré automatiquement par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\nSe déconnecter d'un registre\n\n### Synopsis\n\nSupprime les informations d'identification stockées pour un registre distant.\n\n\n```\nhelm registry logout [host] [flags]\n```\n\n### Options\n\n```\n  -h, --help   Aide pour la commande logout\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm registry](/helm/helm_registry.md) - Se connecter ou se déconnecter d'un registre\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\nAjoute, supprime, liste, met à jour et index les référentiels de charts\n\n### Synopsis\n\nCette commande se compose de plusieurs sous-commandes pour interagir avec des référentiels de charts.\n\nElle peut être utilisée pour ajouter, supprimer, lister et indexer des référentiels de charts.\n\n\n### Options\n\n```\n  -h, --help   Aide pour la commande repo\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de packages Helm pour Kubernetes\n* [helm repo add](/helm/helm_repo_add.md) - Ajoute un référentiel de charts\n* [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\n* [helm repo list](/helm/helm_repo_list.md) - Liste les référentiels\n* [helm repo remove](/helm/helm_repo_remove.md) - Supprime un ou plusieurs référentiels\n* [helm repo update](/helm/helm_repo_update.md) - Met à jour les informations des charts disponible localement à partir des référentiels\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\nAjouter un répertoire de chart\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Options\n\n```\n      --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\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n      --force-update               Remplace (réécrit) le repo s'il existe déjà\n  -h, --help                       Aide pour la commande add\n      --insecure-skip-tls-verify   Passe les vérifications du certificat TLS pour le transfert du chart\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --no-update                  Ignoré. Auparavant, cela désactivait les mises à jour forcées. Il est obsolète et remplacé par --force-update.\n      --pass-credentials           Transmettre les informations d'identification à tous les domaines\n      --password string            Mot de passe du répertoire\n      --password-stdin             Lis le mot de passe depuis la sortie standard\n      --timeout duration           Temps d'attente pour le téléchargement du fichier index (par défaut 2m0s)\n      --username string            Nom d'utilisateur du répertoire\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\nGénère un fichier index à partir d'un répertoire contenant des charts packagés\n\n### Synopsis\n\nAnalyse 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.\n\nCet 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`.\n\nPour 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.\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### Options\n\n```\n  -h, --help           Aide pour la commande index\n      --json           Sortie au format JSON\n      --merge string   Fusionne l'index généré avec l'index donné\n      --url string     URL du répertoire de charts\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\nListe les répertoires de charts\n\n```\nhelm repo list [flags]\n```\n\n### Options\n\n```\n  -h, --help            Aide pour la commande list\n  -o, --output format   Affiche la sortie dans le format spécifié. Valeurs autorisées: table, json, yaml (par défaut table)\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nSupprime un ou plusieurs répertoires de charts\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Options\n\n```\n  -h, --help   Aide pour la commande remove\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\nMet à jour les informations sur les charts disponibles localement à partir des répertoires de charts\n\n### Synopsis\n\nLa 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`.\n\nVous pouvez optionnellement spécifier une liste de répertoires que vous voulez mettre à jour.\n`$ helm repo update <repo_name> ...`\nPour mettre à jour tous les répertoires, utilisez `helm repo update`.\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Options\n\n```\n      --fail-on-repo-update-fail   La mise à jour échoue si l'une des mise à jour du répertoire échoue\n  -h, --help                       Aide pour la commande update\n      --timeout duration           Temps d'attente pour le téléchargement du fichier d'index (par défaut 2m0s)\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\nRestaurer une release vers une révision précédente\n\n### Synopsis\n\nCette commande restaure une release vers une révision précédente.\n\nLe 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.\n\nPour voir les numéros de révision, lancez la commande `helm history <RELEASE>`.\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Options\n\n```\n      --cleanup-on-fail    Suppression des nouvelles ressources créées lors de cette restauration en cas d'échec de la restauration\n      --dry-run            Simule une restauration\n      --force              Force la mise à jour des ressources en les supprimant/recréant si nécessaire\n  -h, --help               Aide pour la commande rollback\n      --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)\n      --no-hooks           Empêche les hooks de fonctionner pendant la restauration\n      --recreate-pods      Effectue le redémarrage des pods pour la ressource, le cas échéant\n      --timeout duration   Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s)\n      --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\n      --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\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\nRecherche un mot clé dans les charts\n\n### Synopsis\n\nLa 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.\nUtilisez les sous-commandes de search pour rechercher des charts dans différents endroits.\n\n\n### Options\n\n```\n  -h, --help   Aide pour la commande search\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n* [helm search hub](/helm/helm_search_hub.md)\t - Rechercher des charts dans Artifact Hub ou dans votre propre instance de hub\n* [helm search repo](/helm/helm_search_repo.md) - Rechercher dans les répertoires un mot-clé dans les charts\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\nRecherche de charts dans l'Artifact Hub ou dans votre propre instance du hub\n\n### Synopsis\nRechercher des charts Helm dans l'Artifact Hub ou dans votre propre instance du hub.\n\nL'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/\n\nL'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\n\nLes 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. \nDe 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\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### Options\n\n```\n      --endpoint string      instance du Hub pour rechercher les charts (par défaut \"https://hub.helm.sh\")\n      --fail-on-no-result    La recherche échoue si pas de résultat trouvé\n  -h, --help                 Aide pour la commande hub\n      --list-repo-url        Affiche les URLs des répertoires de charts\n      --max-col-width uint   Largeur maximum de colonne pour la table de sortie (par défaut 50)\n  -o, --output format        Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table)\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm search](/helm/helm_search.md) - Recherche par mot clé dans les charts\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\nRechercher par mot clé dans les répertoires de charts\n\n### Synopsis\n\nLa 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.\n\nIl affichera les dernières versions stables des charts trouvés. Si vous spécifiez l'argument `--devel`, cela inclura des versions préliminaires.\nSi vous voulez faire une recherche en utilisant une contrainte de version, utilisez l'argument `--version`.\n\nExamples :\n\n    # Recherchez les versions stables correspondant au mot-clé \"nginx\"\n    $ helm search repo nginx\n\n    # Recherchez les versions correspondant au mot-clé \"nginx\", incluant les versions préliminaires\n    $ helm search repo nginx --devel\n\n    # Recherchez les dernières versions stables pour nginx-ingress avec une version majeure de 1\n    $ helm search repo nginx-ingress --version ^1.0.0\n\nLes répertoires sont gérés avec la commande `helm repo`.\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### Options\n\n```\n      --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é\n      --fail-on-no-result    La recherche échoue si pas de résultat trouvé\n  -h, --help                 Aide pour la commande repo\n      --max-col-width uint   Largeur maximum de colonne pour la table de sortie (par défaut 50)\n  -o, --output format        Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table)\n  -r, --regexp               Utiliser des expressions régulières pour rechercher dans les répertoires que vous avez ajoutés\n      --version string       Utiliser une contrainte de version sémantique sur les répertoires que vous avez ajoutés\n  -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\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm search](/helm/helm_search.md) - Recherche par mot clé dans les charts\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\nAffiche les informations sur le chart\n\n### Synopsis\n\nCette commande se compose de plusieurs sous-commandes pour afficher des informations sur les charts.\n\n\n### Options\n\n```\n  -h, --help   Aide pour la commande show\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n* [helm show all](/helm/helm_show_all.md) - Affiche toutes les informations sur le chart\n* [helm show chart](/helm/helm_show_chart.md) - Affiche la définition du chart\n* [helm show crds](/helm/helm_show_crds.md) - Affiche les CRDs du chart\n* [helm show readme](/helm/helm_show_readme.md) - Affiche le README du chart\n* [helm show values](/helm/helm_show_values.md) - Affiche les Values du chart\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\nAffiche toutes les informations sur un chart\n\n### Synopsis\n\nCette commande inspecte un chart (dossier, fichier ou URL) et affiche tout son contenu (values.yaml, Chart.yaml, README).\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n      --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é\n  -h, --help                       Aide pour la commande all\n      --insecure-skip-tls-verify   Passe les vérifications du certificat TLS pour le transfert du chart\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --keyring string             Emplacement des clés publiques utilisé pour la vérification (par défaut \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           Transmet les informations d'identification à tous les domaines\n      --password string            Mot de passe pour le répertoire de chart où est le chart demandé\n      --plain-http                 Utilise une connexion HTTP non-sécurisée pour le transfert du chart\n      --repo string                URL du répertoire du chart demandé\n      --username string            Nom d'utilisateur pour le répertoire du chart demandé\n      --verify                     Vérifie le package avant de l'utiliser\n      --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\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm show](/helm/helm_show.md) - Affiche les informations sur un chart\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\nAffiche la définition du chart\n\n### Synopsis\n\nCette commande inspecte un chart (dossier, fichier ou URL) et affiche le contenu du fichier Chart.yaml.\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n      --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é\n  -h, --help                       Aide pour la commande chart\n      --insecure-skip-tls-verify   Passe les vérifications du certificat TLS pour le transfert du chart\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --keyring string             Emplacement des clés publiques utilisé pour la vérification (par défaut \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           Transmet les informations d'identification à tous les domaines\n      --password string            Mot de passe pour le répertoire de chart où est le chart demandé\n      --plain-http                 Utilise une connexion HTTP non-sécurisée pour le transfert du chart\n      --repo string                URL du répertoire du chart demandé\n      --username string            Nom d'utilisateur pour le répertoire du chart demandé\n      --verify                     Vérifie le package avant de l'utiliser\n      --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\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm show](/helm/helm_show.md) - Affiche les informations sur un chart\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\nAffiche les CRDs du chart\n\n### Synopsis\n\nCette commande inspecte un chart (dossier, fichier ou URL) et affiche le contenu des fichiers des CustomResourceDefinition.\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n      --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é\n  -h, --help                       Aide pour la commande crds\n      --insecure-skip-tls-verify   Passe les vérification du certificat TLS pour le transfer du chart\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --keyring string             Emplacement des clés publiques utilisé pour la vérification (par défaut \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           Transmet les informations d'identification à tous les domaines\n      --password string            Mot de passe pour le répertoire de chart où est le chart demandé\n      --plain-http                 Utilise une connexion HTTP non-sécurisée pour le transfert du chart\n      --repo string                URL du répertoire du chart demandé\n      --username string            Nom d'utilisateur pour le répertoire du chart demandé\n      --verify                     Vérifie le package avant de l'utiliser\n      --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\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utilisé pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm show](/helm/helm_show.md) - Affiche les informations du chart\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nAffiche le README du chart\n\n### Synopsis\n\nCette commande inspecte un chart (dossier, fichier ou URL) et affiche le contenu du fichier README.\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n      --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é\n  -h, --help                       Aide pour la commande readme\n      --insecure-skip-tls-verify   Passe les vérifications du certificat TLS pour le transfert du chart\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --keyring string             Emplacement des clés publiques utilisé pour la vérification (par défaut \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           Transmet les informations d'identification à tous les domaines\n      --password string            Mot de passe pour le répertoire de chart où est le chart demandé\n      --plain-http                 Utilise une connexion HTTP non-sécurisée pour le transfert du chart\n      --repo string                URL du répertoire du chart demandé\n      --username string            Nom d'utilisateur pour le répertoire du chart demandé\n      --verify                     Vérifie le package avant de l'utiliser\n      --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\n```\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm show](/helm/helm_show.md) - Affiche les informations du chart\n\n###### Auto généré par spf13/cobra le 14-Jan-2026\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\nAffiche les values du chart\n\n### Synopsis\n\nCette commande inspecte un chart (dossier, fichier ou URL) et affiche le contenu du fichier values.yaml.\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n      --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é\n  -h, --help                       Aide pour la commande values\n      --insecure-skip-tls-verify   Passe les vérifications du certificat TLS pour le transfert du chart\n      --jsonpath string            fournir une expression JSONPath pour filtrer la sortie\n      --key-file string            Identifie le client HTTPS à l'aide de ce fichier de clé SSL\n      --keyring string             Emplacement des clés publiques utilisé pour la vérification (par défaut \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           Transmet les informations d'identification à tous les domaines\n      --password string            Mot de passe pour le répertoire de chart où est le chart demandé\n      --plain-http                 Utilise une connexion HTTP non-sécurisée pour le transfert du chart\n      --repo string                URL du répertoire du chart demandé\n      --username string            Nom d'utilisateur pour le répertoire du chart demandé\n      --verify                     Vérifie le package avant de l'utiliser\n      --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\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n* [helm show](/helm/helm_show.md) - Affiche les informations du chart\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\nAffiche le statut de la release nommée\n\n### Synopsis\n\nCette commande affiche l'état d'une release nommée. \nLe statut est composé de :\n- heure du dernier déploiement\n- namespace k8s dans lequel se trouve la release\n- l'état de la release  (peut être : unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade or pending-rollback)\n- révision de la release\n- description de la release (peut être un message de complément ou un message d'erreur, besoin d'activer `--show-desc`)\n- liste des ressources dont se compose cette release (besoin d'activer `--show-resources`)\n- détails sur la dernière exécution de la suite de tests, si disponible\n- notes supplémentaires fournies par le chart\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help             Aide pour la commande status\n  -o, --output format    Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table)\n      --revision int     Si fixé, affiche le statut de la release nommée avec la révision\n      --show-desc        Si fixé, affiche la description de la release nommée\n      --show-resources   Si fixé, affiche les ressources de la release nommée\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le répertoire contenant les index de dépôts mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nRendu local de modèles\n\n### Synopsis\n\n\nRendu local de modèle de chart et affiche le résultat.\n\nToutes 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).\n\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### Options\n\n```\n  -a, --api-versions strings                       Versions de l'API Kubernetes utilisées pour Capabilities.APIVersions\n      --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é\n      --ca-file string                             Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA\n      --cert-file string                           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n      --create-namespace                           Créer le namespace de release s'il n'est pas présent\n      --dependency-update                          Met à jour les dépendances si elles sont manquantes avant l'installation du chart\n      --description string                         Ajoute une description personnalisée\n      --devel                                      Utiliser également les versions de développement. Équivalent à version '>0.0.0-0'. Si --version est défini, ceci est ignoré\n      --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\n      --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\n      --enable-dns                                 Active les recherches DNS lors du rendu des modèles\n      --force                                      Force les mises à jour des ressources en utilisant une stratégie de remplacement\n  -g, --generate-name                              Génère le nom (et omet le paramètre NAME)\n  -h, --help                                       Aide pour la commande template\n      --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\n      --include-crds                               Inclure les CRDs dans la sortie du modèle\n      --insecure-skip-tls-verify                   Ignore les vérifications de certificat TLS lors du téléchargement du chart\n      --is-upgrade                                 Définit .Release.IsUpgrade à la place de .Release.IsInstall\n      --key-file string                            Identifie le client HTTPS en utilisant ce fichier de clé SSL\n      --keyring string                             Emplacement des clés publiques utilisé pour la vérification (par défaut \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        Version de Kubernetes utilisée pour Capabilities.KubeVersion\n  -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 [])\n      --name-template string                       Spécifie un modèle à utiliser pour le nom de la release\n      --no-hooks                                   Empêche les hooks de fonctionner pendant l'installation\n      --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)\n      --pass-credentials                           Transmet les informations d'identification à tous les domaines\n      --password string                            Mot de passe pour le dépôt de chart où se trouve le chart demandé\n      --plain-http                                 Utilise une connexion HTTP non sécurisée pour le téléchargement du chart\n      --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é\n      --post-renderer-args postRendererArgsSlice   Un argument pour le post-rendu (peut être spécifié plusieurs fois) (par défaut [])\n      --release-name                               Utilise le nom de la release dans le chemin du dossier de sortie\n      --render-subchart-notes                      Si défini, génère les notes du sous-chart avec le chart parent\n      --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\n      --repo string                                URL du dépôt du chart demandé\n      --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)\n      --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)\n      --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)\n      --set-literal stringArray                    Définit une valeur littérale de type STRING en ligne de commande\n      --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)\n  -s, --show-only stringArray                      Affiche uniquement les manifestes rendus à partir des modèles donnés\n      --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\n      --skip-schema-validation                     Si défini, désactive la validation du schéma JSON\n      --skip-tests                                 Exclut les tests de la sortie du modèle\n      --take-ownership                             Si défini, l'installation ignorera la vérification des annotations Helm et prendra possession des ressources existantes\n      --timeout duration                           Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s)\n      --username string                            Nom d'utilisateur pour le dépôt du chart demandé\n      --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\n  -f, --values strings                             Spécifie les valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs)\n      --verify                                     Vérifie le package avant de l'utiliser\n      --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\n      --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'\n      --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'\n```\n\n### Options héritées des commandes parentes\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port du serveur API Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion au serveur API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le répertoire contenant les index du dépôt mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](./helm.md)\t - Le gestionnaire de packages Helm pour Kubernetes.\n\n###### Auto généré par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\nLance des tests sur une release\n\n### Synopsis\n\nLa commande test, lance des tests sur une release.\n\nCette 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.\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### Options\n\n```\n      --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)\n  -h, --help               Aide pour la commande test\n      --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\n      --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)\n      --timeout duration   Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s)\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite coté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'operation\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utilisé pour la requête\n\t  --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\nDésinstalle une release\n\n### Synopsis\n\nCette commande prend le nom d'une release et la désinstalle.\n\nCela 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.\n\nUtilisez l'argument `--dry-run` pour voir quelles releases seront désinstallées sans vraiment les désinstaller.\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Options\n\n```\n      --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\")\n      --description string   Ajoute une description personnalisée\n      --dry-run              Simule une désinstallation\n  -h, --help                 Aide pour la commande uninstall\n      --ignore-not-found     Considère l'erreur \"release not found\" comme une désinstallation réussie\n      --keep-history         Supprime toutes les ressources associées et marque la release comme supprimée, mais conserve l'historique des versions\n      --no-hooks             Empêche les hooks de s'exécuter pendant la désinstallation\n      --timeout duration     Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s)\n      --wait                 Si défini, attendra que toutes les ressources soient supprimées avant de retourner. Attendra aussi longtemps que la valeur de --timeout\n```\n\n### Options héritées des commandes parentes\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton bearer utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le répertoire contenant les index de dépôts mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](./helm.md) - Le gestionnaire de paquets Helm pour Kubernetes\n\n###### Généré automatiquement par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nMet à niveau une release\n\n### Synopsis\n\nCette commande met à niveau une release vers une nouvelle version du chart.\n\nLes 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.\n\nPour 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.\n\nVous 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 :\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\nVous 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 :\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\nVous 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.\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\nL'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.\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Options\n\n```\n      --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é\n      --ca-file string                             Vérifie les certificats des serveurs HTTPS en utilisant ce fichier de certificat racine (CA bundle)\n      --cert-file string                           Identifie le client HTTPS à l'aide de ce fichier de certificat SSL\n      --cleanup-on-fail                            Autorise la suppression des nouvelles ressources créées lors de cette mise à niveau en cas d'échec\n      --create-namespace                           Si --install est défini, crée le namespace de la release s'il n'est pas présent\n      --dependency-update                          Met à jour les dépendances si elles sont manquantes avant l'installation du chart\n      --description string                         Ajoute une description personnalisée\n      --devel                                      Utilise également les versions de développement. Équivalent à version '>0.0.0-0'. Si --version est défini, ceci est ignoré\n      --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\n      --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\n      --enable-dns                                 Active les recherches DNS lors du rendu des templates\n      --force                                      Force les mises à jour des ressources en utilisant une stratégie de remplacement\n  -h, --help                                       Aide pour upgrade\n      --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\n      --hide-secret                                Masque les Secrets Kubernetes lors de l'utilisation de l'argument --dry-run\n      --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)\n      --insecure-skip-tls-verify                   Ignore les vérifications de certificat TLS lors du téléchargement du chart\n  -i, --install                                    Si une release avec ce nom n'existe pas, lance une installation\n      --key-file string                            Identifie le client HTTPS en utilisant ce fichier de clé SSL\n      --keyring string                             Emplacement des clés publiques utilisées pour la vérification (par défaut \"~/.gnupg/pubring.gpg\")\n  -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 [])\n      --no-hooks                                   Désactive les hooks pre/post mise à niveau\n  -o, --output format                              Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table)\n      --pass-credentials                           Transmet les identifiants à tous les domaines\n      --password string                            Mot de passe du dépôt de charts où se trouve le chart demandé\n      --plain-http                                 Utilise des connexions HTTP non sécurisées pour le téléchargement du chart\n      --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é\n      --post-renderer-args postRendererArgsSlice   Un argument pour le post-renderer (peut être spécifié plusieurs fois) (par défaut [])\n      --render-subchart-notes                      Si défini, génère les notes des sous-charts avec le chart parent\n      --repo string                                URL du dépôt de charts où se trouve le chart demandé\n      --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é\n      --reset-values                               Lors de la mise à niveau, réinitialise les valeurs à celles intégrées au chart\n      --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é\n      --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)\n      --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)\n      --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)\n      --set-literal stringArray                    Définit une valeur littérale de type STRING en ligne de commande\n      --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)\n      --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\n      --skip-schema-validation                     Si défini, désactive la validation du schéma JSON\n      --take-ownership                             Si défini, la mise à niveau ignorera la vérification des annotations helm et prendra possession des ressources existantes\n      --timeout duration                           Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s)\n      --username string                            Nom d'utilisateur du dépôt de charts où se trouve le chart demandé\n  -f, --values strings                             Spécifie les valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs)\n      --verify                                     Vérifie le paquet avant de l'utiliser\n      --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\n      --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'\n      --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'\n```\n\n### Options héritées des commandes parentes\n\n```\n      --burst-limit int                 Limite de régulation côté client (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           Adresse et port du serveur API Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Fichier de l'autorité de certification pour la connexion au serveur API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton bearer utilisé pour l'authentification\n      --kubeconfig string               Chemin vers le fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le répertoire contenant les index de dépôts mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](./helm.md)\t - Le gestionnaire de paquets Helm pour Kubernetes.\n\n###### Auto généré par spf13/cobra le 14-Jan-2026\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\nVérifie que le chart à l'emplacement donné a été signé et est valide\n\n### Synopsis\n\nVérifie que le chart donné possède un fichier de provenance valide.\n\nLes 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.\n\nCette 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`.\n\n\n```\nhelm verify PATH [flags]\n```\n\n### Options\n\n```\n  -h, --help             Aide pour la commande verify\n      --keyring string   Emplacement des clés publiques utilisé pour la vérification (par défaut \"~/.gnupg/pubring.gpg\")\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du dépôt mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\nAffiche les informations sur la version du client\n\n### Synopsis\n\nAffiche la version de Helm.\n\nCela affiche une représentation de la version de Helm.\nLe résultat ressemblera à ceci :\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version : est la version sémantique de la release.\n- GitCommit est le hash SHA pour le commit à partir duquel cette version a été construite.\n- 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.\n- GoVersion est la version de Go qui a été utilisée pour compiler Helm.\n\nLorsque vous utilisez l'indicateur `--template`, les propriétés suivantes peuvent être utilisées dans le modèle :\n\n- .Version contient la version sémantique de Helm.\n- .GitCommit est le commit git.\n- .GitTreeState est l'état du git tree quand Helm a été construit.\n- .GoVersion contient la version de Go qui a été utilisée pour compiler Helm.\n\nPar exemple : `--template='Version: {{.Version}}'` retournera : 'Version: v3.2.1'.\n\n\n```\nhelm version [flags]\n```\n\n### Options\n\n```\n  -h, --help              Aide pour la commande version\n      --short             Affiche le numéro de version\n      --template string   Modèle pour le format de version\n```\n\n### Options héritées des commandes parents\n\n```\n      --burst-limit int                 Limite côté client de la bande passante (par défaut 100)\n      --debug                           Active la sortie détaillée\n      --kube-apiserver string           L'adresse et le port API du serveur Kubernetes\n      --kube-as-group stringArray       Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes\n      --kube-as-user string             Nom d'utilisateur à utiliser pour l'opération\n      --kube-ca-file string             Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes\n      --kube-context string             Nom du contexte kubeconfig à utiliser\n      --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\n      --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é\n      --kube-token string               Jeton utilisé pour l'authentification\n      --kubeconfig string               Chemin du fichier de configuration kubeconfig\n  -n, --namespace string                Namespace à utiliser pour la requête\n      --qps float32                     Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting\n      --registry-config string          Chemin vers le fichier de configuration du registre (par défaut \"~/.config/helm/registry/config.json\")\n      --repository-cache string         Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut \"~/.cache/helm/repository\")\n      --repository-config string        Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut \"~/.config/helm/repositories.yaml\")\n```\n\n### Voir également\n\n* [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes\n\n###### Auto généré par spf13/cobra le 14-Jan-2026\n\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/helm/index.mdx",
    "content": "---\ntitle: Commandes Helm\ndescription: Documentation de toute la liste des commandes CLI helm.\nsidebar_position: 6\nid: helm-category\n---\n\n# Commandes Helm\n\nVous trouverez ici la liste des commandes CLI helm, avec l'aide sur leur utilisation\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: Action Chart Releaser pour automatiser les charts via GitHub Pages\ndescription: Décrit comment utiliser l'action Chart Releaser pour automatiser la publication de charts via GitHub Pages.\nsidebar_position: 3\n---\n\nCe guide décrit comment utiliser [Chart Releaser\nAction](https://github.com/marketplace/actions/helm-chart-releaser) pour\nautomatiser la publication de charts via GitHub Pages. Chart Releaser Action est\nun workflow GitHub Action qui transforme un projet GitHub en dépôt Helm chart\nauto-hébergé, en utilisant l'outil CLI\n[helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n## Configuration du dépôt\n\nCréez un dépôt Git sous votre organisation GitHub. Vous pouvez nommer le dépôt\n`helm-charts`, bien que d'autres noms soient également acceptables. Les sources\nde tous les charts peuvent être placées dans la branche `main`. Les charts\ndoivent être placés dans le répertoire `/charts` à la racine de l'arborescence.\n\nUne autre branche nommée `gh-pages` est nécessaire pour publier les charts. Les\nmodifications apportées à cette branche seront automatiquement créées par\nl'action Chart Releaser décrite ici. Vous pouvez cependant créer cette branche\n`gh-pages` et y ajouter un fichier `README.md`, qui sera visible aux\nutilisateurs qui visitent la page.\n\nVous pouvez ajouter des instructions dans le `README.md` pour l'installation des\ncharts comme ceci (remplacez `<alias>`, `<orgname>` et `<chart-name>`) :\n\n```\n## Utilisation\n\n[Helm](https://helm.sh) doit être installé pour utiliser les charts. Veuillez\nconsulter la [documentation](https://helm.sh/docs) de Helm pour commencer.\n\nUne fois Helm correctement configuré, ajoutez le dépôt comme suit :\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nSi vous avez déjà ajouté ce dépôt précédemment, exécutez `helm repo update` pour\nrécupérer les dernières versions des packages. Vous pouvez ensuite exécuter\n`helm search repo <alias>` pour voir les charts disponibles.\n\nPour installer le chart <chart-name> :\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nPour désinstaller le chart :\n\n    helm uninstall my-<chart-name>\n```\n\nLes charts seront publiés sur un site web avec une URL comme celle-ci :\n\n    https://<orgname>.github.io/helm-charts\n\n## Workflow GitHub Actions\n\nCréez un fichier de workflow GitHub Actions dans la branche `main` à l'emplacement\n`.github/workflows/release.yml`\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nLa configuration ci-dessus utilise\n[@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action)\npour transformer votre projet GitHub en dépôt Helm chart auto-hébergé. À chaque\npush sur main, l'action vérifie chaque chart de votre projet. Lorsqu'une\nnouvelle version est détectée, elle crée une release GitHub correspondante\nnommée d'après la version du chart, y ajoute les artefacts Helm chart, puis crée\nou met à jour un fichier `index.yaml` contenant les métadonnées de ces releases.\nCe fichier est ensuite hébergé sur GitHub Pages.\n\nLe numéro de version de Chart Releaser Action utilisé dans l'exemple ci-dessus\nest `v1.6.0`. Vous pouvez le remplacer par la [dernière version\ndisponible](https://github.com/helm/chart-releaser-action/releases).\n\nRemarque : Chart Releaser Action est presque toujours utilisée conjointement avec\n[Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing)\net [Kind Action](https://github.com/marketplace/actions/kind-cluster).\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: Synchroniser votre dépôt de charts\ndescription: Explique comment synchroniser vos dépôts de charts locaux et distants.\nsidebar_position: 2\n---\n\n*Remarque : cet exemple est spécifiquement conçu pour un bucket Google Cloud Storage (GCS) qui héberge un dépôt de charts.*\n\n## Prérequis\n* Installez l'outil [gsutil](https://cloud.google.com/storage/docs/gsutil). *Nous nous appuyons fortement sur la fonctionnalité rsync de gsutil*\n* Assurez-vous d'avoir accès au binaire Helm\n* _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._\n\n## Configurer un répertoire local pour le dépôt de charts\nCré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.\n\nPar exemple :\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Générer un fichier index.yaml mis à jour\nUtilisez 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 :\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\nCela générera un fichier index.yaml mis à jour et le placera dans le répertoire `fantastic-charts/`.\n\n## Synchroniser vos dépôts de charts local et distant\nTé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.\n\nPar exemple :\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## Mettre à jour votre dépôt de charts\nVous 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.\n\nPar exemple :\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nLiens utiles :\n* Documentation sur [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [Le guide des dépôts de charts](/topics/chart_repository.md)\n* 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\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Trucs et astuces pour le développement de charts\ndescription: 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.\nsidebar_position: 1\n---\n\nCe 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.\n\n## Connaître vos fonctions de template\n\nHelm 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.\n\nTout 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é.\n\nNous 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.\n\nPar exemple, ce fragment de template inclut un template appelé `mytpl`, puis convertit le résultat en minuscules, puis l'entoure de guillemets doubles.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nLa 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.\n\nL'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 :\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## Mettre les chaînes entre guillemets, pas les entiers\n\nLorsque 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 :\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nMais 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.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nCette 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 :\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Utiliser la fonction 'include'\n\nGo 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.\n\nPour 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` :\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nCe qui précède inclut un template appelé `toYaml`, lui passe `$value`, puis passe la sortie de ce template à la fonction `indent`.\n\nParce 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é.\n\n## Utiliser la fonction 'required'\n\nGo 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`.\n\nLa 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.\n\nPar exemple :\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nCe 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.\n\n## Utiliser la fonction 'tpl'\n\nLa 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 }}`\n\nExemples :\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\nRendu d'un fichier de configuration externe :\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## Créer des Image Pull Secrets\n\nLes 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 :\n\nTout d'abord, supposons que les identifiants sont définis dans le fichier `values.yaml` comme suit :\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nNous définissons ensuite notre template helper comme suit :\n\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nEnfin, nous utilisons le template helper dans un template plus large pour créer le manifeste Secret :\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Déclencher automatiquement le redéploiement des Deployments\n\nSouvent, 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.\n\nLa 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 :\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nNOTE : 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 }}`.\n\nDans 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 :\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nChaque 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.\n\nCes 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.\n\nNOTE : 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.\n\n## Indiquer à Helm de ne pas désinstaller une ressource\n\nParfois, 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.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nL'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.\n\n## Utiliser les « Partials » et les includes de templates\n\nParfois, 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.\n\nDans 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`.\n\n## Charts complexes avec de nombreuses dépendances\n\nDe 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.\n\nLa 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.\n\n## YAML est un sur-ensemble de JSON\n\nSelon la spécification YAML, YAML est un sur-ensemble de JSON. Cela signifie que toute structure JSON valide devrait être valide en YAML.\n\nCela 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.\n\nEn 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.\n\n## Attention à la génération de valeurs aléatoires\n\nIl 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.\n\n## Installer ou mettre à niveau une release avec une seule commande\n\nHelm 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.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/howto/index.mdx",
    "content": "---\ntitle: Comment faire\nsidebar_position: 2\n---\n\n# Comment faire\n\nDans cette section vous trouverez un ensemble de courtes réponses aux questions\n\"**Comment faire ...?**\". Ces guides ne vont pas traiter de sujets en profondeur \n*(La documentation dans les guides par [Thèmes](/topics/index.mdx))*, cependant ils vous\naideront à réussir rapidement des tâches simples.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"Accueil Documentations\"\ndescription: \"Tout ce que vous devez savoir sur l'organisation de la documentation.\"\n---\n\n# Bienvenue\n\nBienvenue 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/).\n\n# Comment la documentation est organisée\n\nHelm a beaucoup de documentation. Voici un aperçu de son organisation\npour vous aider à chercher:\n\n- [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.\n- [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.\n- [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.\n- [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.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: Cheat Sheet\ndescription: Helm cheatsheet\nsidebar_position: 4\n---\n\nLa cheatsheet d'Helm contient toutes les commandes nécessaires pour gérer une application avec Helm.\n\n---\n\n### Base\n\nChart:\n\n- Il s'agit du nom de votre chart dans le cas où il aurait été téléchargé ou décompressé.\n- Il s'agit du <repo_name>/<chart_name> dans le cas où le répertoire a été ajouté mais que le chart n'a pas été téléchargé.\n- Il s'agit de l'URL/chemin absolu vers le chart.\n\nName:\n\n- C'est le nom que vous souhaitez donner à votre installation du Chart Helm.\n\nRelease:\n\n- C'est le nom que vous donnez à une instance d'installation.\n\nRevision:\n\n- C'est le numéro de l'historique de déploiement.\n\nRepo-name:\n\n- Le nom d'un dépôt.\n\nDIR:\n\n- Nom/chemin du dossier\n\n---\n\n### Gestion des Chart\n\n```bash\nhelm create <name>                      # Créer un dossier chart avec les fichiers et dossiers utilisés dans un chart.\nhelm package <chart-path>               # Emballe un chart dans une archive compressée et versionnée.\nhelm lint <chart>                       # Lance des tests pour examiner un chart et identifier des problèmes.\nhelm show all <chart>                   # Inspecte et liste le contenu d'un chart.\nhelm show values <chart>                # Affiche le contenu du fichier values.yaml\nhelm pull <chart>                       # Télécharge/pull un chart\nhelm pull <chart> --untar=true          # Si spécifié à true, décompresse le chart une fois téléchargé.\nhelm pull <chart> --verify              # Vérifie le package avant de l'utiliser\nhelm pull <chart> --version <number>    # Par défaut, c'est la dernière version (latest) qui est utilisée, vous pouvez spécifier une version à utiliser.\nhelm dependency list <chart>            # Affiche la liste des dépendances du chart.\n```\n\n---\n\n### Installer et Désinstaller des Applications\n\n```bash\nhelm install <name> <chart>                           # Installe le chart avec son nom.\nhelm install <name> <chart> --namespace <namespace>   # Installe le chart dans un namespace spécifié.\nhelm install <name> <chart> --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).\nhelm install <name> <chart> --values <yaml-file/url>  # Installe le chart avec vos valeurs spécifiques.\nhelm install <name> <chart> --dry-run --debug         # Lance un test d'installation pour valider le chart.\nhelm install <name> <chart> --verify                  # Vérifie le package avant de l'utiliser.\nhelm install <name> <chart> --dependency-update       # Met à jour les dépendances si elles sont manquantes avant d'installer le chart.\nhelm uninstall <name>                                 # Désinstalle une release du namespace courant (par défaut).\nhelm uninstall <release-name> --namespace <namespace> # Désinstalle une release du namespace spécifié.\n```\n\n---\n\n### Mise à jour et Restauration de l'Application\n\n```bash\nhelm upgrade <release> <chart>                            # Met à niveau une version\nhelm upgrade <release> <chart> --rollback-on-failure      # Si fixé, le processus de mise à niveau restaure en cas d'erreur\nhelm upgrade <release> <chart> --dependency-update        # Met à jour les dépendances si elles sont manquantes avant d'installer le chart\nhelm upgrade <release> <chart> --version <version_number> # Spécifie une version à installer\nhelm upgrade <release> <chart> --values                   # Spécifier des valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs)\nhelm upgrade <release> <chart> --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)\nhelm upgrade <release> <chart> --force                    # Force la mise à jour des ressources via une stratégie de remplacement\nhelm rollback <release> <revision>                        # Restaure une release vers une révision spécifique\nhelm rollback <release> <revision>  --cleanup-on-fail     # Autorise la suppression des nouvelles ressources créées si le rollback échoue\n```\n\n---\n\n### Lister, Ajouter, Supprimer et Mettre à jour des dépôts\n\n```bash\nhelm repo add <repo-name> <url>   # Ajoute un dépôt depuis Internet.\nhelm repo list                    # Liste les dépôts de charts ajoutés.\nhelm repo update                  # Met à jour les informations des charts disponibles localement à partir des dépôts.\nhelm repo remove <repo_name>      # Supprime un ou plusieurs dépôts.\nhelm repo index <DIR>             # Lit le dossier courant et génère un fichier d'index sur les charts trouvés.\nhelm repo index <DIR> --merge     # Fusionne l'index généré avec un fichier d'index existant.\nhelm search repo <keyword>        # Recherche des dépôts pour un mot clé dans les charts.\nhelm search hub <keyword>         # Recherche des charts sur l'Artifact Hub ou sur votre propre instance hub.\n```\n\n---\n\n### Surveillance des Version Helm\n\n```bash\nhelm list                       # Liste toutes les versions pour un namespace spécifique, utilise le namespace du contexte courant si le namespace n'est pas spécifié.\nhelm list --all                 # Liste toutes les versions sans filtre appliqué, vous pouvez utiliser '-a'.\nhelm list --all-namespaces      # Liste toutes les versions dans tous les namespaces, vous pouvez utiliser '-A'.\nhelm list -l key1=value1,key2=value2 # Sélecteur (requête sur les étiquettes) sur lequel filtrer, prend en charge '=', '==', et '!='.\nhelm list --date                # Tri par date de sortie.\nhelm list --deployed            # Liste les releases déployées. Si aucune n'est spécifiée, cela sera automatiquement activé.\nhelm list --pending             # Liste les releases en attente.\nhelm list --failed              # Liste les releases ayant échoué.\nhelm list --uninstalled         # Liste les releases désinstallées (si 'helm uninstall --keep-history' a été utilisé).\nhelm list --superseded          # Liste les releases remplacées.\nhelm list -o yaml               # Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table).\nhelm status <release>           # Cette commande affiche l'état de la release nommée.\nhelm status <release> --revision <number>   # Si fixé, affiche l'état d'une release nommée avec sa révision.\nhelm history <release>          # Historique des révisions pour une release donnée.\nhelm env                        # Affiche toutes les informations sur l'environnement utilisées par Helm.\n```\n\n---\n\n### Télécharger les Informations des Versions\n\n```bash\nhelm get all <release>      # 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.\nhelm get hooks <release>    # 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'.\nhelm get manifest <release> # 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.\nhelm get notes <release>    # Affiche les notes fournies par le chart d'une release donnée.\nhelm get values <release>   # Télécharge un fichier de valeurs pour une release donnée. Utilisez l'argument '-o' pour formater la sortie.\n```\n\n---\n\n### Gestion des Plugins\n\n```bash\nhelm plugin install <path/url>      # Installe des plugins\nhelm plugin list                    # Affiche la liste des plugins installés\nhelm plugin update <plugin>         # Met à jour des plugins\nhelm plugin uninstall <plugin>      # Désinstalle un plugin\n```\n\n---\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/intro/index.mdx",
    "content": "---\ntitle: Introduction\nsidebar_position: 1\n---\n\n# Introduction à Helm\n\nVous êtes nouveau sur Helm ? C'est ici que ça commence !\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: Installation de Helm\ndescription: Apprenez à installer Helm et à le prendre en main.\nsidebar_position: 2\n---\n\nCe 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.\n\n## Depuis le projet Helm\n\nLe 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.\n\n### À partir des releases binaires\n\nChaque [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.\n\n1. Téléchargez la [version souhaitée](https://github.com/helm/helm/releases)\n2. Décompressez l'archive (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)\n3. 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`)\n\nÀ 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`.\n\n**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.\n\n### À partir du script\n\nHelm 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).\n\nVous 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.\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\nOui, vous pouvez également exécuter `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` si vous aimez vivre dangereusement.\n\n## Via les gestionnaires de packages\n\nLa 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.\n\n### Depuis Homebrew (macOS)\n\nLes membres de la communauté Helm ont contribué à la création d'une formule Helm pour Homebrew. Cette formule est généralement à jour.\n\n```console\nbrew install helm\n```\n\n(Note : il existe un projet différent possédant une formule pour emacs-helm.)\n\n### Depuis Chocolatey (Windows)\n\nLes 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.\n\n```console\nchoco install kubernetes-helm\n```\n\n### Depuis Scoop (Windows)\n\nLes 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.\n\n```console\nscoop install helm\n```\n\n### Depuis Winget (Windows)\n\nLes 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.\n\n```console\nwinget install Helm.Helm\n```\n\n### Depuis Apt (Debian/Ubuntu)\n\nLes 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.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### Depuis dnf/yum (Fedora)\n\nDepuis Fedora 35, Helm est disponible dans le dépôt officiel. Vous pouvez installer Helm en exécutant :\n\n```console\nsudo dnf install helm\n```\n\n### Depuis Snap\n\nLa communauté des [Snapcrafters](https://github.com/snapcrafters) maintient la version Snap du [package Helm](https://snapcraft.io/helm) :\n\n```console\nsudo snap install helm --classic\n```\n\n### Depuis pkg (FreeBSD)\n\nLes 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.\n\n```console\npkg install helm\n```\n\n### Builds de développement\n\nEn plus des releases, vous pouvez également télécharger et installer les snapshots de développement de Helm.\n\n### Depuis les builds Canary\n\nLes 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.\n\nLes binaires Canary de Helm sont disponibles sur `get.helm.sh`. Voici les liens vers les builds les plus courants :\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### Depuis les sources (Linux, macOS)\n\nConstruire 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.\n\nVous devez disposer d'un environnement Go fonctionnel.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\nSi 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`.\n\n## Conclusion\n\nDans 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.\n\nUne 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).\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: Guide de démarrage rapide\ndescription: Comment installer et débuter avec Helm, y compris les instructions pour les distributions, FAQ et plugins.\nsidebar_position: 1\n---\n\nCe guide explique comment commencer rapidement à utiliser Helm.\n\n## Conditions préalables\n\nLes conditions préalables suivantes sont requises pour une utilisation correcte et sécurisée de Helm :\n\n1. Un cluster Kubernetes\n2. Décider des configurations de sécurité à appliquer à votre installation, si nécessaire\n3. Installation et configuration de Helm\n\n### Installer Kubernetes ou avoir accès à un cluster\n\n- 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.\n- Vous devriez également avoir une copie locale configurée de `kubectl`.\n\nConsultez 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.\n\n## Installer Helm\n\nTé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).\n\nPour plus de détails ou d'autres options, consultez [le guide d'installation](/intro/install.md).\n\n## Initialiser un dépôt de charts Helm\n\nUne 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.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nUne fois le dépôt ajouté, vous pourrez lister les charts disponibles :\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## Installer un chart d'exemple\n\nPour 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`.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nDans l'exemple ci-dessus, le chart `bitnami/mysql` a été déployé, et le nom de notre nouvelle release est `mysql-1612624192`.\n\nVous 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.\n\nChaque 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.\n\nLa 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).\n\n## Découvrir les releases\n\nPour voir ce qui a été déployé avec Helm :\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nLa fonction `helm list` (ou `helm ls`) vous montrera une liste de toutes les releases déployées.\n\n## Désinstaller une release\n\nPour désinstaller une release, utilisez la commande `helm uninstall` :\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nCela désinstallera `mysql-1612624192` de Kubernetes, supprimant toutes les ressources associées à la release ainsi que l'historique de la release.\n\nSi l'option `--keep-history` est fournie, l'historique de la release sera conservé. Vous pourrez alors demander des informations sur cette release :\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nÉ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`).\n\n## Consulter l'aide\n\nPour en savoir plus sur les commandes Helm disponibles, utilisez `helm help` ou tapez une commande suivie de l'option `-h` :\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: Utilisation de Helm\ndescription: Explique la base de Helm.\nsidebar_position: 3\n---\n\nCe 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.\n\nSi 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.\n\n## Trois grands concepts\n\nUn *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.\n\nUn *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.\n\nUne *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_.\n\nMaintenant que vous maîtrisez ces concepts, nous pouvons aborder Helm de la manière suivante :\n\nHelm 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.\n\n## 'helm search': La recherche de charts\n\nHelm est livré avec une puissante commande de recherche. Elle peut être utilisée pour rechercher deux différents types de ressources :\n\n- `helm search hub` recherche sur [Artifact Hub](https://artifacthub.io), qui liste les charts Helm provenant de dizaines de dépôts différents.\n- `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.\n\nVous pouvez trouver des charts publiquement disponibles avec la commande `helm search hub` :\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\nLa commande ci-dessus recherche toutes les charts `wordpress` sur Artifact Hub.\n\nSans filtre, `helm search hub` affiche tous les charts disponibles.\n\n`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]`.\n\nEn utilisant `helm search repo`, vous pouvez trouver les noms des charts dans les dépôts que vous avez ajoutés manuellement :\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nLa 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 :\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nLa 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.\n\n## 'helm install': Installation d'un package\n\nPour 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\nvoulez installer. \n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nLe 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`.)\n\nLors 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.\n\nHelm installe les ressources dans l'ordre suivant :\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nHelm 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.\n\nPour suivre l'état d'une release ou pour relire les informations de configuration, vous pouvez utiliser `helm status`:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nLa commande ci-dessus montre l'état actuel de votre release.\n\n### Personnalisation d'un chart avant son installation\n\nL'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.\n\nPour voir quelles options sont configurables sur un chart, utilisez `helm show values`:\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nVous pouvez ensuite ecraser la configuration par défaut grâce à un fichier YAML que vous passerez en paramètre lors de l'installation.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nLa 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.\n\nIl existe deux façons de transmettre les données de configuration lors de l'installation:\n\n- `--values` (ou `-f`): Spécifie un fichier YAML personnalisé. Vous pouvez spécifier plusieurs fichiers, celui le plus à droite prévaudra.\n- `--set`: Spécifie une valeur personnalisée en ligne de commande.\n\nSi 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.\nLes valeurs définies avec `--set` peuvent être visualisées pour une release donnée avec `helm get values <nom-de-release>`.\nLes valeurs définies avec `--set` peuvent être effacées en exécutant `helm upgrade` avec `--reset-values` spécifié.\n\n#### Le format et les limites de `--set`\n\nL'option `--set` prend zéro ou plusieurs paires de nom/valeur. La manière la plus simple d'utilisation est :  \n`--set name = value`. L'équivalent YAML serait :\n\n```yaml\nname: value\n```\n\nVous pouvez entrer plusieurs valeurs en les séparant par une virgule `,` . Ainsi `--set a=b,c=d` devient l'équivalent YAML de :\n\n```yaml\na: b\nc: d\n```\n\nDes expressions plus complexes sont acceptés. Par exemple l'équivalent de `--set outer.inner=value` en YAML est :\n\n```yaml\nouter:\n  inner: value\n```\n\nVous pouvez définir des listes grâce à des accolades `{` et `}`. Exemple: `--set name={a, b, c}` devient :\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nCertaines clés peuvent être définies à `null` ou à un tableau vide `[]`. Par exemple, `--set name=[],a=null` transforme :\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\nen :\n\n```yaml\nname: []\na: null\n```\n\nDepuis Helm 2.5.0, il est possible d'accéder aux éléments d'une liste en utilisant l'index du tableau.  \nExemple : `--set servers[0].port=80` correspond à :\n\n```yaml\nservers:\n  - port: 80\n```\n\nPlusieurs valeurs peuvent être définies de cette manière.\nLa ligne suivante `--set servers[0].port=80,servers[0].host=example` devient:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nIl peut arriver que vous ayez besoin d'utiliser un charactère spécial avec `--set`. Pour ce faire vous pouvez utiliser un backslash `\\`.  \nExemple : `--set name=value1\\,value2` devient :\n\n```yaml\nname: \"value1,value2\"\n```\n\nDe 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.  \nLa syntaxe de `--set nodeSelector.\" Kubernetes \\ .io / role \"= master` devient:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nLes 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)).\n\n### Autres méthodes d'installation\n\nLa commande `helm install` peut installer un package depuis différentes sources:\n\n- Un dépôt de charts (comme vu précédemment)\n- Une archive locale d'un chart (`helm install foo foo-0.1.1.tgz`)\n- Un dossier contenant un chart décompressé (`helm install foo path/to/foo`)\n- Une URL pointant vers un chart (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' et 'helm rollback': Mettre à jour une Release, et récupération d'un Echec\n\nLorsqu'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`.\n\nUne 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.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nDans 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 :\n\n```yaml\nmariadb.auth.username: user1\n```\n\nVous pouvez utiliser `helm get values` pour voir si votre nouvelle configuration à pris effet ou non :\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nLa 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.\n\nMaintenant 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]`.\n\n```console\n$ helm rollback happy-panda 1\n```\n\nla 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.\n\n## Options utiles pour l'installation / la mise à jour / la restauration\n\nIl 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 <commande> --help`.\n\n- `--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`.\n- `--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.\n- `--no-hooks`: Permet d'ignorer l'exécution des hooks pour la commande\n- `--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)\n\n## 'helm uninstall': Désinstallation d'une Release\n\nQuand sera venu le jour ou vous devrez désinstaller une release de votre cluster, utilisez la commande `helm uninstall` :\n\n```console\n$ helm uninstall happy-panda\n```\n\nCela supprimera la release du cluster. Vous pouvez voir toutes vos releases actuellement déployées avec la commande `helm list`:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nÀ partir du résultat ci-dessus, nous pouvons voir que la version `happy-panda` a bien été désinstallé.\n\nDans 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.\nSi vous souhaitez tout de même conserver un enregistrement de l'historique, utilisez `helm uninstall --keep-history`.  \nL'utilisation de `helm list --uninstalled` affichera uniquement les release qui ont été désinstallés avec l'indicateur `--keep-history`.\n\nL'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é):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nNotez 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.\n\n## 'helm repo': Travailler avec des Dépôts\n\nHelm 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.\n\nVous pouvez voir quels dépôts sont configurés en utilisant `helm repo list`:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nVous pouvez bien entendu ajouter de nouveaux dépôts avec `helm repo add`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nÉ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`.\n\nLes dépôts peuvent être supprimés avec `helm repo remove`.\n\n## Création de vos propres charts\n\nLe [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`:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nIl y a maintenant un chart dans `./deis-workflow`. Vous pouvez le modifier et créer vos propres templates.\n\nLorsque vous modifiez votre chart, vous pouvez valider sa syntaxe en exécutant `helm lint`.\n\nQuand vous aurez besoin de packager le chart pour la distribution, vous pourrez exécuter `helm package`:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nLe chart est maintenant prêt à l'installation `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nLes charts packagés peuvent être uploadés dans des dépôts. Jetez un oeil à la\n[documentation des dépôts](/topics/chart_repository.md) de charts Helm pour plus de détails.\n\n## Conclusion\n\nCe 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`.\n\nPour plus d'informations sur ces commandes, consultez l'aide intégrée de Helm: `helm help`.\n\nDans le [chapitre suivant](/howto/charts_tips_and_tricks.md), nous verrons le processus de développement des charts.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: Introduction\ndescription: Présente le SDK Go de Helm\nsidebar_position: 1\n---\nLe 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.\n(En fait, la CLI Helm n'est qu'un exemple d'un tel outil !)\n\nActuellement, le SDK a été séparé fonctionnellement de la CLI Helm.\nLe SDK peut être (et est) utilisé par des outils autonomes.\nLe projet Helm s'est engagé à assurer la stabilité de l'API du SDK.\nAttention : 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.\n\nLa 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).\n\nUn bref aperçu des principaux types de packages ainsi qu'un exemple simple sont présentés ci-dessous.\nConsultez la section [Exemples](/sdk/examples.mdx) pour plus d'exemples et un exemple plus complet.\n\n## Aperçu des packages principaux\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action) :\n  Contient le \"client\" principal pour exécuter les actions Helm.\n  C'est le même package que la CLI utilise en interne.\n  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.\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil) :\n  Méthodes et utilitaires pour charger et manipuler les charts.\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) et ses sous-packages :\n  Contient tous les handlers pour les variables d'environnement Helm standard. Ses sous-packages gèrent la sortie et le traitement des fichiers values.\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release) :\n  Définit l'objet `Release` et ses statuts.\n\nIl existe de nombreux autres packages. Consultez la documentation pour plus d'informations !\n\n### Exemple simple\nVoici un exemple simple d'exécution d'un `helm list` avec le SDK Go.\nConsultez la section [Exemples](/sdk/examples.mdx) pour des exemples plus complets.\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## Compatibilité\n\nLe SDK Helm suit explicitement les garanties de rétrocompatibilité de Helm :\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\nLes ruptures de compatibilité ne sont introduites qu'entre versions majeures.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: Techniques Helm avancées\ndescription: Explique diverses fonctionnalités avancées pour les utilisateurs expérimentés de Helm\nsidebar_position: 9\n---\n\nCette section présente diverses fonctionnalités et techniques avancées pour utiliser Helm.\nCes 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.\n\nChacune 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).\n\n## Post Rendering\n\nLe post rendering permet de manipuler, configurer et/ou valider manuellement les manifestes rendus avant leur installation par Helm.\nCette fonctionnalité permet aux utilisateurs ayant des besoins de configuration avancés d'utiliser des outils comme\n[`kustomize`](https://kustomize.io) pour appliquer des modifications de configuration sans\navoir à forker un chart public ou exiger des mainteneurs qu'ils spécifient chaque\noption de configuration possible pour un logiciel. Il existe également des cas d'utilisation pour\nl'injection d'outils communs et de sidecars dans les environnements d'entreprise, ou l'analyse\ndes manifestes avant le déploiement.\n\n### Prérequis\n- Helm 3.1+\n\n### Utilisation\nUn post-renderer peut être n'importe quel exécutable qui accepte les manifestes Kubernetes rendus\nsur STDIN et retourne des manifestes Kubernetes valides sur STDOUT. Il doit retourner un\ncode de sortie non nul en cas d'échec. C'est la seule « API » entre les\ndeux composants. Cela offre une grande flexibilité dans ce que vous pouvez faire avec votre\nprocessus de post-render.\n\nUn post renderer peut être utilisé avec `install`, `upgrade` et `template`. Pour utiliser un\npost-renderer, utilisez le flag `--post-renderer` avec le chemin vers l'exécutable\ndu renderer que vous souhaitez utiliser :\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nSi le chemin ne contient aucun séparateur, il sera recherché dans $PATH, sinon\nles chemins relatifs seront résolus en chemins absolus.\n\nSi vous souhaitez utiliser plusieurs post-renderers, appelez-les tous dans un script ou\nensemble dans l'outil binaire que vous avez construit. En bash, cela serait aussi\nsimple que `renderer1 | renderer2 | renderer3`.\n\nVous pouvez voir un exemple d'utilisation de `kustomize` comme post renderer\n[ici](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n### Mises en garde\n\nLors de l'utilisation de post renderers, plusieurs points importants sont à garder à l'esprit.\n\nLe 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.\n\nPoint 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.\n\n### Post Renderers personnalisés\nL'étape de post render offre encore plus de flexibilité lorsqu'elle est utilisée avec le SDK Go. Tout\npost renderer n'a qu'à implémenter l'interface Go suivante :\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nPour plus d'informations sur l'utilisation du SDK Go, consultez la [section SDK Go](#sdk-go)\n\n## SDK Go\nHelm 3 a introduit un SDK Go entièrement restructuré pour une meilleure expérience lors\nde la création de logiciels et d'outils exploitant Helm. La documentation complète se trouve\ndans la [section SDK Go](/sdk/gosdk.md).\n\n## Backends de stockage\n\nHelm 3 a changé le stockage par défaut des informations de release vers les Secrets dans le\nnamespace de la release. Helm 2 stockait par défaut les informations de release sous forme de\nConfigMaps dans le namespace de l'instance Tiller. Les sous-sections suivantes\nexpliquent comment configurer différents backends. Cette configuration est basée sur la\nvariable d'environnement `HELM_DRIVER`. Elle peut être définie sur l'une des valeurs suivantes :\n`[configmap, secret, sql]`.\n\n### Backend de stockage ConfigMap\n\nPour activer le backend ConfigMap, vous devez définir la variable d'environnement\n`HELM_DRIVER` sur `configmap`.\n\nVous pouvez la définir dans un shell comme suit :\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nSi vous souhaitez passer du backend par défaut au backend ConfigMap, vous devrez\neffectuer la migration vous-même. Vous pouvez récupérer les informations de release\navec la commande suivante :\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**NOTES DE PRODUCTION** : Les informations de release incluent le contenu des charts et\ndes fichiers values, et peuvent donc contenir des données sensibles (comme\ndes mots de passe, des clés privées et d'autres identifiants) qui doivent être protégées contre\nles accès non autorisés. Lors de la gestion des autorisations Kubernetes, par exemple avec\n[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), il est\npossible d'accorder un accès plus large aux ressources ConfigMap, tout en restreignant\nl'accès aux ressources Secret. Par exemple, le [rôle orienté utilisateur](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\npar défaut « view » accorde l'accès à la plupart des ressources, mais pas aux Secrets. De plus, les\ndonnées des secrets peuvent être configurées pour un [stockage chiffré](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).\nGardez cela à l'esprit si vous décidez de passer au backend ConfigMap, car cela\npourrait exposer les données sensibles de votre application.\n\n### Backend de stockage SQL\n\nIl existe un backend de stockage SQL en ***beta*** qui stocke les informations de release dans une base\nde données SQL.\n\nL'utilisation d'un tel backend de stockage est particulièrement utile si vos informations de release\npèsent plus de 1 Mo (auquel cas, elles ne peuvent pas être stockées dans ConfigMaps/Secrets\nen raison des limites internes du magasin clé-valeur etcd sous-jacent de Kubernetes).\n\nPour activer le backend SQL, vous devez déployer une base de données SQL et définir la\nvariable d'environnement `HELM_DRIVER` sur `sql`. Les détails de la base de données sont définis avec la\nvariable d'environnement `HELM_DRIVER_SQL_CONNECTION_STRING`.\n\nVous pouvez les définir dans un shell comme suit :\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Note : Seul PostgreSQL est pris en charge pour le moment.\n\n**NOTES DE PRODUCTION** : Il est recommandé de :\n- 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\n- Activer la [gestion des permissions](/topics/permissions_sql_storage_backend.md) pour\nrefléter le RBAC Kubernetes pour les informations de release\n\nSi vous souhaitez passer du backend par défaut au backend SQL, vous devrez\neffectuer la migration vous-même. Vous pouvez récupérer les informations de release\navec la commande suivante :\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Architecture de Helm\ndescription: Décrit l'architecture de Helm à un niveau général.\nsidebar_position: 8\n---\n\n# Architecture de Helm\n\nCe document décrit l'architecture de Helm à un niveau général.\n\n## L'objectif de Helm\n\nHelm est un outil de gestion des paquets Kubernetes appelés _charts_. Helm peut effectuer les opérations suivantes :\n\n- Créer de nouveaux charts à partir de zéro\n- Empaqueter des charts dans des fichiers d'archive (tgz)\n- Interagir avec des dépôts de charts où les charts sont stockés\n- Installer et désinstaller des charts dans un cluster Kubernetes existant\n- Gérer le cycle de release des charts installés avec Helm\n\nPour Helm, il existe trois concepts importants :\n\n1. Le _chart_ est un ensemble d'informations nécessaires à la création d'une instance d'une application Kubernetes.\n2. La _config_ contient les informations de configuration qui peuvent être fusionnées avec un chart empaqueté pour créer un objet déployable.\n3. Une _release_ est une instance en cours d'exécution d'un _chart_, combinée avec une _config_ spécifique.\n\n## Composants\n\nHelm est un exécutable implémenté en deux parties distinctes :\n\n**Le client Helm** est un client en ligne de commande destiné aux utilisateurs finaux. Le client est responsable des opérations suivantes :\n\n- Développement local de charts\n- Gestion des dépôts\n- Gestion des releases\n- Interface avec la bibliothèque Helm\n  - Envoi de charts à installer\n  - Demande de mise à niveau ou de désinstallation de releases existantes\n\n**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 :\n\n- Combiner un chart et une configuration pour créer une release\n- Installer des charts dans Kubernetes et fournir l'objet release résultant\n- Mettre à niveau et désinstaller des charts en interagissant avec Kubernetes\n\nLa bibliothèque Helm autonome encapsule la logique Helm afin qu'elle puisse être utilisée par différents clients.\n\n## Implémentation\n\nLe client et la bibliothèque Helm sont écrits dans le langage de programmation Go.\n\nLa 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.\n\nLes fichiers de configuration sont, dans la mesure du possible, écrits en YAML.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: Guide des dépôts de charts\ndescription: Comment créer et travailler avec les dépôts de charts Helm.\nsidebar_position: 6\n---\n\nCette section explique comment créer et travailler avec les dépôts de charts Helm.\nUn dépôt de charts est un emplacement où les charts empaquetés peuvent être stockés\net partagés.\n\nLe dépôt communautaire distribué de charts Helm se trouve sur\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) et accueille les\ncontributions. Cependant, Helm permet également de créer et d'héberger votre propre\ndépôt de charts. Ce guide explique comment procéder. Si vous envisagez de créer un\ndépôt de charts, vous pourriez considérer l'utilisation d'un\n[registre OCI](./registries.md) à la place.\n\n## Prérequis\n\n* Parcourir le guide de [Démarrage rapide](../intro/quickstart.md)\n* Lire le document sur les [Charts](./charts.md)\n\n## Créer un dépôt de charts\n\nUn _dépôt de charts_ est un serveur HTTP qui héberge un fichier `index.yaml` ainsi\nque des charts empaquetés. Lorsque vous êtes prêt à partager vos charts, la méthode\nrecommandée est de les téléverser vers un dépôt de charts.\n\nDepuis Helm 2.2.0, l'authentification SSL côté client est supportée pour les dépôts.\nD'autres protocoles d'authentification peuvent être disponibles via des plugins.\n\nPuisqu'un dépôt de charts peut être n'importe quel serveur HTTP capable de servir\ndes fichiers YAML et tar et de répondre aux requêtes GET, vous avez de nombreuses\noptions pour héberger votre propre dépôt de charts. Par exemple, vous pouvez\nutiliser un bucket Google Cloud Storage (GCS), un bucket Amazon S3, GitHub Pages,\nou même créer votre propre serveur web.\n\n### Structure du dépôt de charts\n\nUn dépôt de charts se compose de charts empaquetés et d'un fichier spécial appelé\n`index.yaml` qui contient un index de tous les charts du dépôt. Souvent, les charts\ndécrits par `index.yaml` sont également hébergés sur le même serveur, tout comme\nles [fichiers de provenance](./provenance.md).\n\nPar exemple, la structure du dépôt `https://example.com/charts` pourrait ressembler\nà ceci :\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nDans ce cas, le fichier index contiendrait des informations sur un seul chart, le\nchart Alpine, et fournirait l'URL de téléchargement\n`https://example.com/charts/alpine-0.1.2.tgz` pour ce chart.\n\nIl n'est pas obligatoire que le package du chart soit situé sur le même serveur que\nle fichier `index.yaml`. Cependant, c'est souvent la solution la plus simple.\n\n### Le fichier index\n\nLe fichier index est un fichier yaml appelé `index.yaml`. Il contient des métadonnées\nsur le package, y compris le contenu du fichier `Chart.yaml` du chart. Un dépôt de\ncharts valide doit avoir un fichier index. Le fichier index contient des informations\nsur chaque chart dans le dépôt. La commande `helm repo index` génère un fichier index\nà partir d'un répertoire local donné contenant des charts empaquetés.\n\nVoici un exemple de fichier index :\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Héberger des dépôts de charts\n\nCette partie présente plusieurs façons de servir un dépôt de charts.\n\n### Google Cloud Storage\n\nLa première étape est de **créer votre bucket GCS**. Nous appellerons le nôtre\n`fantastic-charts`.\n\n![Créer un bucket GCS](/img/helm2/create-a-bucket.png)\n\nEnsuite, rendez votre bucket public en **modifiant les permissions du bucket**.\n\n![Modifier les permissions](/img/helm2/edit-permissions.png)\n\nAjoutez cette ligne pour **rendre votre bucket public** :\n\n![Rendre le bucket public](/img/helm2/make-bucket-public.png)\n\nFélicitations, vous avez maintenant un bucket GCS vide prêt à servir des charts !\n\nVous pouvez téléverser votre dépôt de charts en utilisant l'outil en ligne de\ncommande Google Cloud Storage ou via l'interface web GCS. Un bucket GCS public\nest accessible via HTTPS simple à cette adresse : `https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith\n\nVous pouvez également configurer des dépôts de charts en utilisant Cloudsmith.\nPour en savoir plus sur les dépôts de charts avec Cloudsmith, consultez\n[cette documentation](https://help.cloudsmith.io/docs/helm-chart-repository).\n\n### JFrog Artifactory\n\nDe même, vous pouvez configurer des dépôts de charts en utilisant JFrog Artifactory.\nPour en savoir plus sur les dépôts de charts avec JFrog Artifactory, consultez\n[cette documentation](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories).\n\n### Exemple avec GitHub Pages\n\nDe manière similaire, vous pouvez créer un dépôt de charts en utilisant GitHub Pages.\n\nGitHub vous permet de servir des pages web statiques de deux manières différentes :\n\n- En configurant un projet pour servir le contenu de son répertoire `docs/`\n- En configurant un projet pour servir une branche particulière\n\nNous allons utiliser la seconde approche, bien que la première soit tout aussi simple.\n\nLa première étape sera de **créer votre branche gh-pages**. Vous pouvez le faire\nlocalement ainsi :\n\n```console\n$ git checkout -b gh-pages\n```\n\nOu via le navigateur web en utilisant le bouton **Branch** dans votre dépôt GitHub :\n\n![Créer une branche GitHub Pages](/img/helm2/create-a-gh-page-button.png)\n\nEnsuite, assurez-vous que votre **branche gh-pages** est définie comme source pour\nGitHub Pages. Cliquez sur **Settings** de votre dépôt et descendez jusqu'à la section\n**GitHub pages** puis configurez comme suit :\n\n![Configurer GitHub Pages](/img/helm2/set-a-gh-page.png)\n\nPar défaut, **Source** est généralement défini sur **gh-pages branch**. Si ce n'est\npas le cas par défaut, sélectionnez-le.\n\nVous pouvez utiliser un **domaine personnalisé** si vous le souhaitez.\n\nEt vérifiez que **Enforce HTTPS** est coché, afin que **HTTPS** soit utilisé lors\ndu service des charts.\n\nAvec cette configuration, vous pouvez utiliser votre branche par défaut pour stocker\nle code de vos charts et la **branche gh-pages** comme dépôt de charts, par exemple :\n`https://USERNAME.github.io/REPONAME`. Le dépôt de démonstration\n[TS Charts](https://github.com/technosophos/tscharts) est accessible à\n`https://technosophos.github.io/tscharts/`.\n\nSi vous avez décidé d'utiliser GitHub Pages pour héberger le dépôt de charts,\nconsultez [Chart Releaser Action](../howto/chart_releaser_action.md).\nChart Releaser Action est un workflow GitHub Action pour transformer un projet\nGitHub en dépôt de charts Helm auto-hébergé, en utilisant l'outil CLI\n[helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n### Serveurs web ordinaires\n\nPour configurer un serveur web ordinaire pour servir des charts Helm, vous devez\nsimplement faire ce qui suit :\n\n- Placer votre fichier index et vos charts dans un répertoire que le serveur peut\n  servir\n- S'assurer que le fichier `index.yaml` est accessible sans exigence d'authentification\n- S'assurer que les fichiers `yaml` sont servis avec le bon type de contenu\n  (`text/yaml` ou `text/x-yaml`)\n\nPar exemple, si vous voulez servir vos charts depuis `$WEBROOT/charts`, assurez-vous\nqu'il y a un répertoire `charts/` dans votre racine web, et placez le fichier index\net les charts dans ce dossier.\n\n### Serveur de dépôt ChartMuseum\n\nChartMuseum est un serveur de dépôt de charts Helm open-source écrit en Go (Golang),\navec support pour les backends de stockage cloud, notamment [Google Cloud\nStorage](https://cloud.google.com/storage/), [Amazon\nS3](https://aws.amazon.com/s3/), [Microsoft Azure Blob\nStorage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba\nCloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object\nStorage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud\nInfrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud\nBOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object\nStorage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean\nSpaces](https://www.digitalocean.com/products/spaces/),\n[Minio](https://min.io/), et [etcd](https://etcd.io/).\n\nVous pouvez également utiliser le serveur\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\npour héberger un dépôt de charts depuis un système de fichiers local.\n\n### GitLab Package Registry\n\nAvec GitLab, vous pouvez publier des charts Helm dans le Package Registry de votre\nprojet. Pour en savoir plus sur la configuration d'un dépôt de packages Helm avec\nGitLab, consultez [cette documentation](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Gérer les dépôts de charts\n\nMaintenant que vous avez un dépôt de charts, la dernière partie de ce guide explique\ncomment maintenir les charts dans ce dépôt.\n\n### Stocker des charts dans votre dépôt de charts\n\nMaintenant que vous avez un dépôt de charts, téléversons un chart et un fichier index\nvers le dépôt. Les charts dans un dépôt de charts doivent être empaquetés\n(`helm package chart-name/`) et versionnés correctement (en suivant les directives\n[SemVer 2](https://semver.org/)).\n\nLes étapes suivantes composent un exemple de workflow, mais vous êtes libre d'utiliser\nle workflow de votre choix pour stocker et mettre à jour les charts dans votre dépôt.\n\nUne fois que vous avez un chart empaqueté prêt, créez un nouveau répertoire et\ndéplacez-y votre chart empaqueté.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nLa dernière commande prend le chemin du répertoire local que vous venez de créer et\nl'URL de votre dépôt de charts distant pour composer un fichier `index.yaml` dans\nle répertoire donné.\n\nVous pouvez maintenant téléverser le chart et le fichier index vers votre dépôt de\ncharts en utilisant un outil de synchronisation ou manuellement. Si vous utilisez\nGoogle Cloud Storage, consultez cet\n[exemple de workflow](../howto/chart_repository_sync_example.md)\nutilisant le client gsutil. Pour GitHub, vous pouvez simplement placer les charts\ndans la branche de destination appropriée.\n\n### Ajouter de nouveaux charts à un dépôt existant\n\nChaque fois que vous souhaitez ajouter un nouveau chart à votre dépôt, vous devez\nrégénérer l'index. La commande `helm repo index` reconstruira complètement le fichier\n`index.yaml` à partir de zéro, en incluant uniquement les charts qu'elle trouve\nlocalement.\n\nCependant, vous pouvez utiliser le flag `--merge` pour ajouter de nouveaux charts\nde manière incrémentale à un fichier `index.yaml` existant (une excellente option\nlorsque vous travaillez avec un dépôt distant comme GCS). Exécutez\n`helm repo index --help` pour en savoir plus.\n\nAssurez-vous de téléverser à la fois le fichier `index.yaml` révisé et le chart.\nEt si vous avez généré un fichier de provenance, téléversez-le également.\n\n### Partager vos charts avec d'autres\n\nLorsque vous êtes prêt à partager vos charts, communiquez simplement l'URL de\nvotre dépôt.\n\nÀ partir de là, ils pourront ajouter le dépôt à leur client Helm via la commande\n`helm repo add [NOM] [URL]` avec le nom de leur choix pour référencer le dépôt.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nSi les charts sont protégés par une authentification HTTP basique, vous pouvez\négalement fournir le nom d'utilisateur et le mot de passe ici :\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Note :** Un dépôt ne sera pas ajouté s'il ne contient pas un fichier `index.yaml`\nvalide.\n\n**Note :** Si votre dépôt Helm utilise par exemple un certificat auto-signé, vous\npouvez utiliser `helm repo add --insecure-skip-tls-verify ...` pour ignorer la\nvérification du CA.\n\nAprès cela, vos utilisateurs pourront rechercher dans vos charts. Après avoir mis\nà jour le dépôt, ils peuvent utiliser la commande `helm repo update` pour obtenir\nles dernières informations sur les charts.\n\n*En coulisses, les commandes `helm repo add` et `helm repo update` récupèrent le\nfichier index.yaml et le stockent dans le répertoire\n`$XDG_CACHE_HOME/helm/repository/cache/`. C'est là que la fonction `helm search`\ntrouve les informations sur les charts.*\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: Tests de chart\ndescription: Décrit comment exécuter et tester vos charts.\nsidebar_position: 3\n---\n\nUn chart contient de nombreuses ressources et composants Kubernetes qui\nfonctionnent ensemble. En tant qu'auteur de chart, vous souhaiterez peut-être\nécrire des tests pour valider que votre chart fonctionne comme prévu lors de\nson installation. Ces tests aident également les utilisateurs du chart à\ncomprendre ce que celui-ci est censé faire.\n\nUn **test** dans un chart Helm se trouve dans le répertoire `templates/` et\nconsiste en une définition de Job spécifiant un conteneur avec une commande\ndonnée à exécuter. Le conteneur doit se terminer avec succès (exit 0) pour que\nle test soit considéré comme réussi. La définition du Job doit contenir\nl'annotation de hook de test Helm : `helm.sh/hook: test`.\n\nNotez que jusqu'à Helm v3, la définition du Job devait contenir l'une de ces\nannotations de hook de test Helm : `helm.sh/hook: test-success` ou\n`helm.sh/hook: test-failure`. L'annotation `helm.sh/hook: test-success` est\ntoujours acceptée comme alternative rétrocompatible à `helm.sh/hook: test`.\n\nExemples de tests :\n\n- Valider que votre configuration provenant du fichier values.yaml a été\n  correctement injectée.\n  - Vérifier que votre nom d'utilisateur et votre mot de passe fonctionnent\n    correctement\n  - Vérifier qu'un nom d'utilisateur et un mot de passe incorrects ne\n    fonctionnent pas\n- Vérifier que vos services sont opérationnels et répartissent correctement\n  la charge\n- etc.\n\nVous pouvez exécuter les tests prédéfinis dans Helm sur une release à l'aide de\nla commande `helm test <RELEASE_NAME>`. C'est un excellent moyen pour les\nutilisateurs de vérifier que leur release d'un chart (ou application)\nfonctionne comme prévu.\n\n## Exemple de test\n\nLa commande [helm create](/helm/helm_create.md) crée automatiquement un certain\nnombre de dossiers et fichiers. Pour essayer la fonctionnalité de test Helm,\ncréez d'abord un chart de démonstration.\n\n```console\n$ helm create demo\n```\n\nVous verrez maintenant la structure suivante dans votre chart de démonstration.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nDans `demo/templates/tests/test-connection.yaml`, vous trouverez un test que\nvous pouvez essayer. Voici la définition du pod de test Helm :\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Étapes pour exécuter une suite de tests sur une release\n\nTout d'abord, installez le chart sur votre cluster pour créer une release. Vous\ndevrez peut-être attendre que tous les pods deviennent actifs ; si vous lancez\nle test immédiatement après l'installation, un échec transitoire est probable,\net vous voudrez relancer le test.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Notes\n\n- Vous pouvez définir autant de tests que vous le souhaitez dans un seul fichier\n  yaml ou les répartir dans plusieurs fichiers yaml dans le répertoire\n  `templates/`.\n- Vous pouvez placer votre suite de tests dans un sous-répertoire `tests/` comme\n  `<nom-du-chart>/templates/tests/` pour plus d'isolation.\n- Un test est un [hook Helm](/topics/charts_hooks.md), donc les annotations telles\n  que `helm.sh/hook-weight` et `helm.sh/hook-delete-policy` peuvent être utilisées\n  avec les ressources de test.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: Charts\ndescription: Explique le format des charts et fournit des conseils de base pour créer des charts avec Helm.\nsidebar_position: 1\n---\n\nHelm utilise un format de packaging appelé _charts_. Un chart est une collection\nde fichiers décrivant un ensemble cohérent de ressources Kubernetes. Un seul\nchart peut être utilisé pour déployer quelque chose de simple, comme un pod\nmemcached, ou quelque chose de complexe, comme une pile applicative web complète\navec serveurs HTTP, bases de données, caches, etc.\n\nLes charts sont créés sous forme de fichiers organisés dans une arborescence de\nrépertoires particulière. Ils peuvent être empaquetés dans des archives versionnées\npour être déployés.\n\nSi vous souhaitez télécharger et examiner les fichiers d'un chart publié sans\nl'installer, vous pouvez le faire avec `helm pull chartrepo/chartname`.\n\nCe document explique le format des charts et fournit des conseils de base pour\ncréer des charts avec Helm.\n\n## Structure des fichiers d'un chart\n\nUn chart est organisé comme une collection de fichiers dans un répertoire. Le nom\ndu répertoire est le nom du chart (sans information de version). Ainsi, un chart\ndécrivant WordPress serait stocké dans un répertoire `wordpress/`.\n\nÀ l'intérieur de ce répertoire, Helm s'attend à une structure correspondant à ceci :\n\n```text\nwordpress/\n  Chart.yaml          # Un fichier YAML contenant des informations sur le chart\n  LICENSE             # OPTIONNEL : Un fichier texte contenant la licence du chart\n  README.md           # OPTIONNEL : Un fichier README lisible par les humains\n  values.yaml         # Les valeurs de configuration par défaut pour ce chart\n  values.schema.json  # OPTIONNEL : Un JSON Schema pour imposer une structure au fichier values.yaml\n  charts/             # Un répertoire contenant les charts dont ce chart dépend\n  crds/               # Custom Resource Definitions\n  templates/          # Un répertoire de templates qui, combinés aux values,\n                      # génèreront des fichiers manifestes Kubernetes valides\n  templates/NOTES.txt # OPTIONNEL : Un fichier texte contenant des notes d'utilisation courtes\n```\n\nHelm réserve l'utilisation des répertoires `charts/`, `crds/` et `templates/`,\nainsi que des noms de fichiers listés ci-dessus. Les autres fichiers sont laissés\ntels quels.\n\n## Le fichier Chart.yaml\n\nLe fichier `Chart.yaml` est obligatoire pour un chart. Il contient les champs\nsuivants :\n\n```yaml\napiVersion: The chart API version (required)\nname: The name of the chart (required)\nversion: The version of the chart (required)\nkubeVersion: A SemVer range of compatible Kubernetes versions (optional)\ndescription: A single-sentence description of this project (optional)\ntype: The type of the chart (optional)\nkeywords:\n  - A list of keywords about this project (optional)\nhome: The URL of this projects home page (optional)\nsources:\n  - A list of URLs to source code for this project (optional)\ndependencies: # A list of the chart requirements (optional)\n  - name: The name of the chart (nginx)\n    version: The version of the chart (\"1.2.3\")\n    repository: (optional) The repository URL (\"https://example.com/charts\") or alias (\"@repo-name\")\n    condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )\n    tags: # (optional)\n      - Tags can be used to group charts for enabling/disabling together\n    import-values: # (optional)\n      - 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.\n    alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times\nmaintainers: # (optional)\n  - name: The maintainers name (required for each maintainer)\n    email: The maintainers email (optional for each maintainer)\n    url: A URL for the maintainer (optional for each maintainer)\nicon: A URL to an SVG or PNG image to be used as an icon (optional).\nappVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.\ndeprecated: Whether this chart is deprecated (optional, boolean)\nannotations:\n  example: A list of annotations keyed by name (optional).\n```\n\nÀ partir de [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), les champs\nsupplémentaires ne sont plus autorisés. L'approche recommandée est d'ajouter des\nmétadonnées personnalisées dans `annotations`.\n\n### Charts et versioning\n\nChaque chart doit avoir un numéro de version. Une version doit suivre le standard\n[SemVer 2](https://semver.org/spec/v2.0.0.html), mais ce n'est pas strictement\nimposé. Contrairement à Helm Classic, Helm v2 et les versions ultérieures utilisent\nles numéros de version comme marqueurs de release. Les paquets dans les dépôts sont\nidentifiés par leur nom plus leur version.\n\nPar exemple, un chart `nginx` dont le champ version est défini à `version: 1.2.3`\nsera nommé :\n\n```text\nnginx-1.2.3.tgz\n```\n\nDes noms SemVer 2 plus complexes sont également supportés, comme `version:\n1.2.3-alpha.1+ef365`. Cependant, les noms non-SemVer sont explicitement interdits\npar le système. Sont toutefois acceptés les formats de version `x` ou `x.y`.\nPar exemple, s'il y a un `v` initial ou une version listée sans les 3 parties\n(par ex. `v1.2`), Helm tentera de la convertir en une version sémantique valide\n(par ex. `v1.2.0`).\n\n**NOTE :** Alors que Helm Classic et Deployment Manager étaient très orientés\nGitHub en ce qui concerne les charts, Helm v2 et les versions ultérieures ne\ndépendent pas de GitHub ni ne requièrent Git. Par conséquent, les SHA Git ne\nsont pas du tout utilisés pour le versioning.\n\nLe champ `version` dans le fichier `Chart.yaml` est utilisé par de nombreux\noutils Helm, y compris la CLI. Lors de la génération d'un paquet, la commande\n`helm package` utilisera la version trouvée dans le `Chart.yaml` comme jeton\ndans le nom du paquet. Le système suppose que le numéro de version dans le nom\ndu paquet de chart correspond au numéro de version dans le `Chart.yaml`. Le\nnon-respect de cette hypothèse provoquera une erreur.\n\n### Le champ `apiVersion`\n\nLe champ `apiVersion` doit être `v2` pour les charts Helm nécessitant au moins\nHelm 3. Les charts supportant les versions précédentes de Helm ont un `apiVersion`\ndéfini à `v1` et restent installables par Helm 3.\n\nChangements de `v1` à `v2` :\n\n- Un champ `dependencies` définissant les dépendances du chart, qui étaient\n  situées dans un fichier séparé `requirements.yaml` pour les charts `v1`\n  (voir [Dépendances des charts](#dependances-des-charts)).\n- Le champ `type`, distinguant les charts d'application et les charts de type\n  library (voir [Types de charts](#types-de-charts)).\n\n### Le champ `appVersion`\n\nNotez que le champ `appVersion` n'est pas lié au champ `version`. C'est un moyen\nde spécifier la version de l'application. Par exemple, le chart `drupal` peut\navoir un `appVersion: \"8.2.1\"`, indiquant que la version de Drupal incluse dans\nle chart (par défaut) est `8.2.1`. Ce champ est informatif et n'a aucun impact\nsur les calculs de version du chart. Il est fortement recommandé d'entourer la\nversion de guillemets. Cela force l'analyseur YAML à traiter le numéro de version\ncomme une chaîne. Ne pas utiliser de guillemets peut entraîner des problèmes\nd'analyse dans certains cas. Par exemple, YAML interprète `1.0` comme une valeur\nà virgule flottante, et un SHA de commit git comme `1234e10` comme une notation\nscientifique.\n\nÀ partir de Helm v3.5.0, `helm create` entoure le champ `appVersion` par défaut\nde guillemets.\n\n### Le champ `kubeVersion`\n\nLe champ optionnel `kubeVersion` peut définir des contraintes semver sur les\nversions de Kubernetes supportées. Helm validera les contraintes de version lors\nde l'installation du chart et échouera si le cluster exécute une version de\nKubernetes non supportée.\n\nLes contraintes de version peuvent comprendre des comparaisons AND séparées par\ndes espaces comme :\n```\n>= 1.13.0 < 1.15.0\n```\nqui peuvent elles-mêmes être combinées avec l'opérateur OR `||` comme dans\nl'exemple suivant :\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\nDans cet exemple, la version `1.14.0` est exclue, ce qui peut être utile si un\nbug dans certaines versions est connu pour empêcher le chart de fonctionner\ncorrectement.\n\nEn plus des contraintes de version utilisant les opérateurs `=` `!=` `>` `<`\n`>=` `<=`, les notations raccourcies suivantes sont supportées :\n\n * plages avec tiret pour les intervalles fermés, où `1.1 - 2.3.4` est équivalent\n   à `>= 1.1 <= 2.3.4`.\n * jokers `x`, `X` et `*`, où `1.2.x` est équivalent à `>= 1.2.0 < 1.3.0`.\n * plages tilde (changements de version patch autorisés), où `~1.2.3` est\n   équivalent à `>= 1.2.3 < 1.3.0`.\n * plages caret (changements de version mineure autorisés), où `^1.2.3` est\n   équivalent à `>= 1.2.3 < 2.0.0`.\n\nPour une explication détaillée des contraintes semver supportées, consultez\n[Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Déprécier des charts\n\nLors de la gestion de charts dans un dépôt de charts, il est parfois nécessaire\nde déprécier un chart. Le champ optionnel `deprecated` dans `Chart.yaml` peut\nêtre utilisé pour marquer un chart comme déprécié. Si la **dernière** version\nd'un chart dans le dépôt est marquée comme dépréciée, alors le chart dans son\nensemble est considéré comme déprécié. Le nom du chart peut être réutilisé\nultérieurement en publiant une nouvelle version qui n'est pas marquée comme\ndépréciée. Le workflow pour déprécier des charts est :\n\n1. Mettre à jour le `Chart.yaml` du chart pour le marquer comme déprécié, en\n   incrémentant la version\n2. Publier la nouvelle version du chart dans le dépôt de charts\n3. Supprimer le chart du dépôt source (par ex. git)\n\n### Types de charts\n\nLe champ `type` définit le type de chart. Il existe deux types : `application`\net `library`. Application est le type par défaut et c'est le chart standard sur\nlequel on peut effectuer toutes les opérations. Le [chart de type library](/topics/library_charts.md)\nfournit des utilitaires ou des fonctions pour le créateur du chart. Un chart de\ntype library diffère d'un chart d'application car il n'est pas installable et\nne contient généralement pas d'objets ressources.\n\n**Note :** Un chart d'application peut être utilisé comme chart de type library.\nCela s'active en définissant le type à `library`. Le chart sera alors rendu\ncomme un chart de type library où tous les utilitaires et fonctions peuvent être\nexploités. Tous les objets ressources du chart ne seront pas rendus.\n\n## LICENSE, README et NOTES d'un chart\n\nLes charts peuvent également contenir des fichiers décrivant l'installation, la\nconfiguration, l'utilisation et la licence d'un chart.\n\nUne LICENSE est un fichier texte brut contenant la\n[licence](https://fr.wikipedia.org/wiki/Licence_de_logiciel) du chart. Le chart\npeut contenir une licence car il peut avoir une logique de programmation dans\nles templates et ne serait donc pas uniquement de la configuration. Il peut\négalement y avoir des licences séparées pour l'application installée par le\nchart, si nécessaire.\n\nUn README pour un chart doit être formaté en Markdown (README.md), et devrait\ngénéralement contenir :\n\n- Une description de l'application ou du service fourni par le chart\n- Tout prérequis ou exigence pour exécuter le chart\n- Des descriptions des options dans `values.yaml` et des valeurs par défaut\n- Toute autre information pertinente pour l'installation ou la configuration\n  du chart\n\nLorsque les hubs et autres interfaces utilisateur affichent les détails d'un\nchart, ces informations sont extraites du contenu du fichier `README.md`.\n\nLe chart peut également contenir un court fichier texte `templates/NOTES.txt`\nqui sera affiché après l'installation et lors de l'affichage du statut d'une\nrelease. Ce fichier est évalué comme un [template](#templates-et-values), et\npeut être utilisé pour afficher des notes d'utilisation, les prochaines étapes,\nou toute autre information pertinente pour une release du chart. Par exemple,\ndes instructions pourraient être fournies pour se connecter à une base de\ndonnées ou accéder à une interface web. Comme ce fichier est affiché sur STDOUT\nlors de l'exécution de `helm install` ou `helm status`, il est recommandé de\ngarder le contenu bref et de pointer vers le README pour plus de détails.\n\n## Dépendances des charts\n\nDans Helm, un chart peut dépendre de n'importe quel nombre d'autres charts. Ces\ndépendances peuvent être liées dynamiquement en utilisant le champ `dependencies`\ndans `Chart.yaml` ou importées dans le répertoire `charts/` et gérées manuellement.\n\n### Gérer les dépendances avec le champ `dependencies`\n\nLes charts requis par le chart actuel sont définis comme une liste dans le champ\n`dependencies`.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- Le champ `name` est le nom du chart souhaité.\n- Le champ `version` est la version du chart souhaitée.\n- Le champ `repository` est l'URL complète du dépôt de charts. Notez que vous\n  devez également utiliser `helm repo add` pour ajouter ce dépôt localement.\n- Vous pouvez utiliser le nom du dépôt au lieu de l'URL\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nUne fois les dépendances définies, vous pouvez exécuter `helm dependency update`\nqui utilisera votre fichier de dépendances pour télécharger tous les charts\nspécifiés dans votre répertoire `charts/`.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nLorsque `helm dependency update` récupère les charts, il les stocke sous forme\nd'archives de charts dans le répertoire `charts/`. Ainsi, pour l'exemple\nci-dessus, on s'attendrait à voir les fichiers suivants dans le répertoire charts :\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Champ alias dans les dépendances\n\nEn plus des autres champs ci-dessus, chaque entrée de dépendance peut contenir\nle champ optionnel `alias`.\n\nAjouter un alias pour un chart de dépendance place ce chart dans les dépendances\nen utilisant l'alias comme nom de la nouvelle dépendance.\n\nOn peut utiliser `alias` lorsqu'on a besoin d'accéder à un chart avec un ou\nplusieurs autres noms.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nDans l'exemple ci-dessus, nous obtiendrons 3 dépendances au total pour `parentchart` :\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nLa méthode manuelle pour accomplir cela serait de copier/coller le même chart\ndans le répertoire `charts/` plusieurs fois avec des noms différents.\n\n#### Champs tags et condition dans les dépendances\n\nEn plus des autres champs ci-dessus, chaque entrée de dépendance peut contenir\nles champs optionnels `tags` et `condition`.\n\nTous les charts sont chargés par défaut. Si les champs `tags` ou `condition`\nsont présents, ils seront évalués et utilisés pour contrôler le chargement des\ncharts auxquels ils s'appliquent.\n\nCondition - Le champ condition contient un ou plusieurs chemins YAML (délimités\npar des virgules). Si ce chemin existe dans les values du parent de niveau\nsupérieur et se résout en une valeur booléenne, le chart sera activé ou\ndésactivé en fonction de cette valeur booléenne. Seul le premier chemin valide\ntrouvé dans la liste est évalué et si aucun chemin n'existe, la condition n'a\naucun effet.\n\nTags - Le champ tags est une liste YAML de labels à associer à ce chart. Dans\nles values du parent de niveau supérieur, tous les charts avec des tags peuvent\nêtre activés ou désactivés en spécifiant le tag et une valeur booléenne.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nDans l'exemple ci-dessus, tous les charts avec le tag `front-end` seraient\ndésactivés, mais comme le chemin `subchart1.enabled` s'évalue à 'true' dans les\nvalues du parent, la condition prendra le dessus sur le tag `front-end` et\n`subchart1` sera activé.\n\nPuisque `subchart2` a le tag `back-end` et que ce tag s'évalue à `true`,\n`subchart2` sera activé. Notez également que bien que `subchart2` ait une\ncondition spécifiée, il n'y a pas de chemin et de valeur correspondants dans\nles values du parent, donc cette condition n'a aucun effet.\n\n##### Utiliser la CLI avec les tags et conditions\n\nLe paramètre `--set` peut être utilisé comme d'habitude pour modifier les\nvaleurs des tags et conditions.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Résolution des tags et conditions\n\n- **Les conditions (quand elles sont définies dans les values) prennent toujours\n  le dessus sur les tags.** Le premier chemin de condition qui existe l'emporte\n  et les suivants pour ce chart sont ignorés.\n- Les tags sont évalués comme \"si l'un des tags du chart est vrai, alors activer\n  le chart\".\n- Les valeurs des tags et conditions doivent être définies dans les values du\n  parent de niveau supérieur.\n- La clé `tags:` dans les values doit être une clé de niveau supérieur. Les\n  globaux et les tables `tags:` imbriquées ne sont actuellement pas supportés.\n\n#### Importer les values des charts enfants via les dépendances\n\nDans certains cas, il est souhaitable de permettre aux values d'un chart enfant\nde se propager au chart parent et d'être partagées comme valeurs par défaut\ncommunes. Un avantage supplémentaire de l'utilisation du format `exports` est\nqu'il permettra aux outils futurs d'introspecter les valeurs configurables par\nl'utilisateur.\n\nLes clés contenant les values à importer peuvent être spécifiées dans les\n`dependencies` du chart parent dans le champ `import-values` en utilisant une\nliste YAML. Chaque élément de la liste est une clé qui est importée depuis le\nchamp `exports` du chart enfant.\n\nPour importer des values non contenues dans la clé `exports`, utilisez le format\n[child-parent](#utiliser-le-format-child-parent). Des exemples des deux formats\nsont décrits ci-dessous.\n\n##### Utiliser le format exports\n\nSi le fichier `values.yaml` d'un chart enfant contient un champ `exports` à la\nracine, son contenu peut être importé directement dans les values du parent en\nspécifiant les clés à importer comme dans l'exemple ci-dessous :\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\nPuisque nous spécifions la clé `data` dans notre liste d'import, Helm cherche\ndans le champ `exports` du chart enfant la clé `data` et importe son contenu.\n\nLes values finales du parent contiendront notre champ exporté :\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\nVeuillez noter que la clé parente `data` n'est pas contenue dans les values\nfinales du parent. Si vous avez besoin de spécifier la clé parente, utilisez le\nformat 'child-parent'.\n\n##### Utiliser le format child-parent\n\nPour accéder aux values qui ne sont pas contenues dans la clé `exports` des\nvalues du chart enfant, vous devrez spécifier la clé source des values à\nimporter (`child`) et le chemin de destination dans les values du chart parent\n(`parent`).\n\nLe `import-values` dans l'exemple ci-dessous indique à Helm de prendre toutes\nles values trouvées au chemin `child:` et de les copier vers les values du\nparent au chemin spécifié dans `parent:`\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nDans l'exemple ci-dessus, les values trouvées à `default.data` dans les values\nde subchart1 seront importées à la clé `myimports` dans les values du chart\nparent comme détaillé ci-dessous :\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nLes values résultantes du chart parent seraient :\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nLes values finales du parent contiennent maintenant les champs `myint` et\n`mybool` importés de subchart1.\n\n### Gérer les dépendances manuellement via le répertoire `charts/`\n\nSi plus de contrôle sur les dépendances est souhaité, ces dépendances peuvent\nêtre exprimées explicitement en copiant les charts de dépendance dans le\nrépertoire `charts/`.\n\nUne dépendance doit être un répertoire de chart non compressé mais son nom ne\npeut pas commencer par `_` ou `.`. De tels fichiers sont ignorés par le chargeur\nde chart.\n\nPar exemple, si le chart WordPress dépend du chart Apache, le chart Apache (de\nla bonne version) est fourni dans le répertoire `charts/` du chart WordPress :\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nL'exemple ci-dessus montre comment le chart WordPress exprime sa dépendance\nenvers Apache et MySQL en incluant ces charts dans son répertoire `charts/`.\n\n**CONSEIL :** _Pour placer une dépendance dans votre répertoire `charts/`,\nutilisez la commande `helm pull`_\n\n### Aspects opérationnels de l'utilisation des dépendances\n\nLes sections ci-dessus expliquent comment spécifier les dépendances de charts,\nmais comment cela affecte-t-il l'installation de charts avec `helm install` et\n`helm upgrade` ?\n\nSupposons qu'un chart nommé \"A\" crée les objets Kubernetes suivants :\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nDe plus, A dépend du chart B qui crée les objets :\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nAprès l'installation/mise à niveau du chart A, une seule release Helm est\ncréée/modifiée. La release créera/mettra à jour tous les objets Kubernetes\nci-dessus dans l'ordre suivant :\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nC'est parce que lorsque Helm installe/met à niveau des charts, les objets\nKubernetes provenant des charts et de toutes leurs dépendances sont :\n\n- agrégés en un seul ensemble ; puis\n- triés par type suivi du nom ; et ensuite\n- créés/mis à jour dans cet ordre.\n\nPar conséquent, une seule release est créée avec tous les objets du chart et de\nses dépendances.\n\nL'ordre d'installation des types Kubernetes est donné par l'énumération\nInstallOrder dans kind_sorter.go (voir [le fichier source Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n## Templates et Values\n\nLes templates de charts Helm sont écrits dans le [langage de template\nGo](https://golang.org/pkg/text/template/), avec l'ajout d'une cinquantaine de\nfonctions de template supplémentaires [de la bibliothèque Sprig](https://github.com/Masterminds/sprig)\net quelques autres [fonctions spécialisées](/howto/charts_tips_and_tricks.md).\n\nTous les fichiers de template sont stockés dans le dossier `templates/` d'un\nchart. Lorsque Helm effectue le rendu des charts, il passe chaque fichier de ce\nrépertoire à travers le moteur de template.\n\nLes values pour les templates sont fournies de deux manières :\n\n- Les développeurs de charts peuvent fournir un fichier appelé `values.yaml` dans\n  un chart. Ce fichier peut contenir des valeurs par défaut.\n- Les utilisateurs de charts peuvent fournir un fichier YAML contenant des values.\n  Celui-ci peut être fourni en ligne de commande avec `helm install`.\n\nLorsqu'un utilisateur fournit des values personnalisées, ces values remplaceront\nles values du fichier `values.yaml` du chart.\n\n### Fichiers de template\n\nLes fichiers de template suivent les conventions standard pour écrire des\ntemplates Go (voir la [documentation du package Go text/template](https://golang.org/pkg/text/template/)\npour les détails). Un exemple de fichier de template pourrait ressembler à ceci :\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nL'exemple ci-dessus, inspiré de\n[https://github.com/deis/charts](https://github.com/deis/charts), est un template\npour un contrôleur de réplication Kubernetes. Il peut utiliser les quatre values\nde template suivantes (généralement définies dans un fichier `values.yaml`) :\n\n- `imageRegistry` : Le registre source pour l'image Docker.\n- `dockerTag` : Le tag pour l'image Docker.\n- `pullPolicy` : La politique de pull Kubernetes.\n- `storage` : Le backend de stockage, dont la valeur par défaut est `\"minio\"`\n\nToutes ces values sont définies par l'auteur du template. Helm n'exige ni ne\ndicte de paramètres.\n\nPour voir de nombreux charts fonctionnels, consultez le [Artifact Hub](https://artifacthub.io/packages/search?kind=0)\nde la CNCF.\n\n### Values prédéfinies\n\nLes values fournies via un fichier `values.yaml` (ou via le flag `--set`) sont\naccessibles depuis l'objet `.Values` dans un template. Mais il existe d'autres\néléments de données prédéfinis auxquels vous pouvez accéder dans vos templates.\n\nLes values suivantes sont prédéfinies, disponibles pour chaque template, et ne\npeuvent pas être remplacées. Comme pour toutes les values, les noms sont\n_sensibles à la casse_.\n\n- `Release.Name` : Le nom de la release (pas du chart)\n- `Release.Namespace` : Le namespace dans lequel le chart a été déployé.\n- `Release.Service` : Le service qui a effectué la release.\n- `Release.IsUpgrade` : Défini à true si l'opération actuelle est une mise à\n  niveau ou un rollback.\n- `Release.IsInstall` : Défini à true si l'opération actuelle est une installation.\n- `Chart` : Le contenu du `Chart.yaml`. Ainsi, la version du chart est accessible\n  via `Chart.Version` et les mainteneurs sont dans `Chart.Maintainers`.\n- `Files` : Un objet de type map contenant tous les fichiers non spéciaux du\n  chart. Cela ne vous donne pas accès aux templates, mais vous permet d'accéder\n  aux fichiers additionnels présents (sauf s'ils sont exclus via `.helmignore`).\n  Les fichiers sont accessibles via `{{ index .Files \"file.name\" }}` ou via la\n  fonction `{{.Files.Get name }}`. Vous pouvez également accéder au contenu du\n  fichier sous forme de `[]byte` avec `{{ .Files.GetBytes }}`\n- `Capabilities` : Un objet de type map contenant des informations sur les\n  versions de Kubernetes (`{{ .Capabilities.KubeVersion }}`) et les versions\n  d'API Kubernetes supportées\n  (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n**NOTE :** Tout champ inconnu du `Chart.yaml` sera supprimé. Il ne sera pas\naccessible dans l'objet `Chart`. Ainsi, `Chart.yaml` ne peut pas être utilisé\npour passer des données structurées arbitraires dans le template. Le fichier\nvalues peut être utilisé à cette fin.\n\n### Fichiers values\n\nEn considérant le template de la section précédente, un fichier `values.yaml`\nfournissant les values nécessaires ressemblerait à ceci :\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nUn fichier values est formaté en YAML. Un chart peut inclure un fichier\n`values.yaml` par défaut. La commande helm install permet à un utilisateur de\nremplacer les values en fournissant des values YAML supplémentaires :\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nLorsque les values sont passées de cette manière, elles seront fusionnées avec\nle fichier values par défaut. Par exemple, considérons un fichier `myvals.yaml`\nqui ressemble à ceci :\n\n```yaml\nstorage: \"gcs\"\n```\n\nLorsque ceci est fusionné avec le `values.yaml` du chart, le contenu généré\nrésultant sera :\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nNotez que seul le dernier champ a été remplacé.\n\n**NOTE :** Le fichier values par défaut inclus dans un chart _doit_ être nommé\n`values.yaml`. Mais les fichiers spécifiés en ligne de commande peuvent avoir\nn'importe quel nom.\n\n**NOTE :** Si le flag `--set` est utilisé avec `helm install` ou `helm upgrade`,\nces values sont simplement converties en YAML côté client.\n\n**NOTE :** Si des entrées obligatoires existent dans le fichier values, elles\npeuvent être déclarées comme requises dans le template du chart en utilisant la\n[fonction 'required'](/howto/charts_tips_and_tricks.md).\n\nToutes ces values sont ensuite accessibles dans les templates via l'objet\n`.Values` :\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Portée, dépendances et values\n\nLes fichiers values peuvent déclarer des values pour le chart de niveau\nsupérieur, ainsi que pour tous les charts inclus dans le répertoire `charts/`\nde ce chart. Ou, formulé différemment, un fichier values peut fournir des values\nau chart ainsi qu'à toutes ses dépendances. Par exemple, le chart WordPress de\ndémonstration ci-dessus a `mysql` et `apache` comme dépendances. Le fichier\nvalues pourrait fournir des values à tous ces composants :\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nLes charts de niveau supérieur ont accès à toutes les variables définies en\ndessous. Ainsi, le chart WordPress peut accéder au mot de passe MySQL via\n`.Values.mysql.password`. Mais les charts de niveau inférieur ne peuvent pas\naccéder aux éléments des charts parents, donc MySQL ne pourra pas accéder à la\npropriété `title`. De même, il ne peut pas accéder à `apache.port`.\n\nLes values sont séparées par namespace, mais les préfixes de namespace sont\nsupprimés. Ainsi, pour le chart WordPress, il peut accéder au champ du mot de\npasse MySQL via `.Values.mysql.password`. Mais pour le chart MySQL, la portée\ndes values a été réduite et le préfixe de namespace supprimé, donc il verra le\nchamp password simplement comme `.Values.password`.\n\n#### Values globales\n\nÀ partir de la version 2.0.0-Alpha.2, Helm supporte des values \"globales\"\nspéciales. Considérons cette version modifiée de l'exemple précédent :\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nCeci ajoute une section `global` avec la valeur `app: MyWordPress`. Cette valeur\nest disponible pour _tous_ les charts via `.Values.global.app`.\n\nPar exemple, les templates `mysql` peuvent accéder à `app` via\n`{{ .Values.global.app }}`, tout comme le chart `apache`. En fait, le fichier\nvalues ci-dessus est régénéré comme ceci :\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\nCela fournit un moyen de partager une variable de niveau supérieur avec tous les\nsous-charts, ce qui est utile pour des choses comme définir des propriétés\n`metadata` comme les labels.\n\nSi un sous-chart déclare une variable globale, cette globale sera passée _vers\nle bas_ (aux sous-charts du sous-chart), mais pas _vers le haut_ au chart parent.\nIl n'y a aucun moyen pour un sous-chart d'influencer les values du chart parent.\n\nDe plus, les variables globales des charts parents ont la priorité sur les\nvariables globales des sous-charts.\n\n### Fichiers de schéma\n\nParfois, un mainteneur de chart peut vouloir définir une structure pour ses\nvalues. Cela peut être fait en définissant un schéma dans le fichier\n`values.schema.json`. Un schéma est représenté sous forme de [JSON Schema](https://json-schema.org/).\nIl pourrait ressembler à ceci :\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nCe schéma sera appliqué aux values pour les valider. La validation se produit\nlorsque l'une des commandes suivantes est invoquée :\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nUn exemple de fichier `values.yaml` qui répond aux exigences de ce schéma\npourrait ressembler à ceci :\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nNotez que le schéma est appliqué à l'objet `.Values` final, et pas seulement au\nfichier `values.yaml`. Cela signifie que le fichier `yaml` suivant est valide,\nà condition que le chart soit installé avec l'option `--set` appropriée montrée\nci-dessous.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nDe plus, l'objet `.Values` final est vérifié par rapport aux schémas de *tous*\nles sous-charts. Cela signifie que les restrictions d'un sous-chart ne peuvent\npas être contournées par un chart parent. Cela fonctionne également dans l'autre\nsens - si un sous-chart a une exigence qui n'est pas satisfaite dans le fichier\n`values.yaml` du sous-chart, le chart parent *doit* satisfaire ces restrictions\npour être valide.\n\nLa validation de schéma peut être désactivée avec l'option montrée ci-dessous.\nC'est particulièrement utile dans les environnements isolés lorsque le fichier\nJSON Schema d'un chart contient des références distantes.\n```console\nhelm install --skip-schema-validation\n```\n\n### Références\n\nEn ce qui concerne l'écriture de templates, values et fichiers de schéma, il\nexiste plusieurs références standard qui vous aideront.\n\n- [Templates Go](https://godoc.org/text/template)\n- [Fonctions de template supplémentaires](https://godoc.org/github.com/Masterminds/sprig)\n- [Le format YAML](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRDs)\n\nKubernetes fournit un mécanisme pour déclarer de nouveaux types d'objets\nKubernetes. En utilisant les CustomResourceDefinitions (CRDs), les développeurs\nKubernetes peuvent déclarer des types de ressources personnalisées.\n\nDans Helm 3, les CRDs sont traitées comme un type spécial d'objet. Elles sont\ninstallées avant le reste du chart et sont soumises à certaines limitations.\n\nLes fichiers YAML CRD doivent être placés dans le répertoire `crds/` à\nl'intérieur d'un chart. Plusieurs CRDs (séparées par des marqueurs de début et\nde fin YAML) peuvent être placées dans le même fichier. Helm tentera de charger\n_tous_ les fichiers du répertoire CRD dans Kubernetes.\n\nLes fichiers CRD _ne peuvent pas être templatisés_. Ils doivent être des\ndocuments YAML bruts.\n\nLorsque Helm installe un nouveau chart, il télécharge les CRDs, attend jusqu'à\nce que les CRDs soient rendues disponibles par le serveur API, puis démarre le\nmoteur de template, effectue le rendu du reste du chart, et le télécharge vers\nKubernetes. En raison de cet ordre, les informations CRD sont disponibles dans\nl'objet `.Capabilities` des templates Helm, et les templates Helm peuvent créer\nde nouvelles instances d'objets qui ont été déclarés dans les CRDs.\n\nPar exemple, si votre chart avait une CRD pour `CronTab` dans le répertoire\n`crds/`, vous pouvez créer des instances du type `CronTab` dans le répertoire\n`templates/` :\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nLe fichier `crontab.yaml` doit contenir la CRD sans directives de template :\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nEnsuite, le template `mycrontab.yaml` peut créer un nouveau `CronTab` (en\nutilisant les templates comme d'habitude) :\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm s'assurera que le type `CronTab` a été installé et est disponible depuis\nle serveur API Kubernetes avant de procéder à l'installation des éléments dans\n`templates/`.\n\n### Limitations des CRDs\n\nContrairement à la plupart des objets dans Kubernetes, les CRDs sont installées\nglobalement. Pour cette raison, Helm adopte une approche très prudente dans la\ngestion des CRDs. Les CRDs sont soumises aux limitations suivantes :\n\n- Les CRDs ne sont jamais réinstallées. Si Helm détermine que les CRDs dans le\n  répertoire `crds/` sont déjà présentes (quelle que soit la version), Helm ne\n  tentera pas de les installer ou de les mettre à niveau.\n- Les CRDs ne sont jamais installées lors d'une mise à niveau ou d'un rollback.\n  Helm créera uniquement les CRDs lors des opérations d'installation.\n- Les CRDs ne sont jamais supprimées. La suppression d'une CRD supprime\n  automatiquement tout le contenu de la CRD dans tous les namespaces du cluster.\n  Par conséquent, Helm ne supprimera pas les CRDs.\n\nLes opérateurs qui souhaitent mettre à niveau ou supprimer des CRDs sont\nencouragés à le faire manuellement et avec beaucoup de précaution.\n\n## Utiliser Helm pour gérer les charts\n\nL'outil `helm` dispose de plusieurs commandes pour travailler avec les charts.\n\nIl peut créer un nouveau chart pour vous :\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nUne fois que vous avez modifié un chart, `helm` peut l'empaqueter dans une\narchive de chart pour vous :\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nVous pouvez également utiliser `helm` pour vous aider à trouver des problèmes\nde formatage ou d'information dans votre chart :\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Dépôts de charts\n\nUn _dépôt de charts_ est un serveur HTTP qui héberge un ou plusieurs charts\nempaquetés. Bien que `helm` puisse être utilisé pour gérer des répertoires de\ncharts locaux, quand il s'agit de partager des charts, le mécanisme préféré est\nun dépôt de charts.\n\nTout serveur HTTP capable de servir des fichiers YAML et tar et de répondre aux\nrequêtes GET peut être utilisé comme serveur de dépôt. L'équipe Helm a testé\ncertains serveurs, notamment Google Cloud Storage avec le mode site web activé,\net S3 avec le mode site web activé.\n\nUn dépôt est caractérisé principalement par la présence d'un fichier spécial\nappelé `index.yaml` qui contient une liste de tous les paquets fournis par le\ndépôt, ainsi que des métadonnées permettant de récupérer et vérifier ces paquets.\n\nCôté client, les dépôts sont gérés avec les commandes `helm repo`. Cependant,\nHelm ne fournit pas d'outils pour télécharger des charts vers des serveurs de\ndépôt distants. En effet, cela ajouterait des exigences substantielles à un\nserveur implémentant cette fonctionnalité, et augmenterait donc la barrière\npour mettre en place un dépôt.\n\n## Packs de démarrage de charts\n\nLa commande `helm create` prend une option optionnelle `--starter` qui vous\npermet de spécifier un \"chart de démarrage\". De plus, l'option starter a un\nalias court `-p`.\n\nExemples d'utilisation :\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nLes starters sont simplement des charts ordinaires, mais situés dans\n`$XDG_DATA_HOME/helm/starters`. En tant que développeur de chart, vous pouvez\ncréer des charts spécifiquement conçus pour être utilisés comme starters. Ces\ncharts doivent être conçus avec les considérations suivantes en tête :\n\n- Le `Chart.yaml` sera écrasé par le générateur.\n- Les utilisateurs s'attendront à modifier le contenu d'un tel chart, donc la\n  documentation devrait indiquer comment les utilisateurs peuvent le faire.\n- Toutes les occurrences de `<CHARTNAME>` seront remplacées par le nom de chart\n  spécifié afin que les charts de démarrage puissent être utilisés comme\n  templates, sauf pour certains fichiers de variables. Par exemple, si vous\n  utilisez des fichiers personnalisés dans le répertoire `vars` ou certains\n  fichiers `README.md`, `<CHARTNAME>` ne sera PAS remplacé à l'intérieur de\n  ceux-ci. De plus, la description du chart n'est pas héritée.\n\nActuellement, la seule façon d'ajouter un chart à `$XDG_DATA_HOME/helm/starters`\nest de le copier manuellement. Dans la documentation de votre chart, vous\nvoudrez peut-être expliquer ce processus.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: Hooks de chart\ndescription: Décrit comment utiliser les hooks de chart.\nsidebar_position: 2\n---\n\nHelm fournit un mécanisme de _hook_ permettant aux développeurs de charts\nd'intervenir à certains moments du cycle de vie d'une release. Par exemple,\nvous pouvez utiliser les hooks pour :\n\n- Charger un ConfigMap ou un Secret pendant l'installation avant le chargement\n  des autres charts.\n- Exécuter un Job pour sauvegarder une base de données avant l'installation d'un\n  nouveau chart, puis exécuter un second job après la mise à niveau pour restaurer\n  les données.\n- Exécuter un Job avant la suppression d'une release pour retirer proprement un\n  service de la rotation avant de le supprimer.\n\nLes hooks fonctionnent comme des templates classiques, mais possèdent des\nannotations spéciales qui amènent Helm à les utiliser différemment. Cette section\ncouvre les principes de base de l'utilisation des hooks.\n\n## Les hooks disponibles\n\nLes hooks suivants sont définis :\n\n| Valeur de l'annotation | Description                                                                                                  |\n| ---------------------- | ------------------------------------------------------------------------------------------------------------ |\n| `pre-install`          | S'exécute après le rendu des templates, mais avant la création des ressources dans Kubernetes                |\n| `post-install`         | S'exécute après le chargement de toutes les ressources dans Kubernetes                                       |\n| `pre-delete`           | S'exécute lors d'une demande de suppression, avant la suppression des ressources de Kubernetes               |\n| `post-delete`          | S'exécute lors d'une demande de suppression, après la suppression de toutes les ressources de la release     |\n| `pre-upgrade`          | S'exécute lors d'une mise à niveau, après le rendu des templates, mais avant la mise à jour des ressources   |\n| `post-upgrade`         | S'exécute lors d'une mise à niveau, après la mise à jour de toutes les ressources                            |\n| `pre-rollback`         | S'exécute lors d'un rollback, après le rendu des templates, mais avant le rollback des ressources            |\n| `post-rollback`        | S'exécute lors d'un rollback, après la modification de toutes les ressources                                 |\n| `test`                 | S'exécute lorsque la sous-commande test de Helm est invoquée ([voir la documentation des tests](/topics/chart_tests.md)) |\n\n_Note : le hook `crd-install` a été supprimé au profit du répertoire `crds/`\ndans Helm 3._\n\n## Les hooks et le cycle de vie d'une release\n\nLes hooks vous permettent, en tant que développeur de charts, d'effectuer des\nopérations à des moments stratégiques du cycle de vie d'une release. Par exemple,\nconsidérons le cycle de vie d'un `helm install`. Par défaut, celui-ci se déroule\nainsi :\n\n1. L'utilisateur exécute `helm install foo`\n2. L'API d'installation de la bibliothèque Helm est appelée\n3. Après quelques vérifications, la bibliothèque effectue le rendu des templates de `foo`\n4. La bibliothèque charge les ressources résultantes dans Kubernetes\n5. La bibliothèque renvoie l'objet release (et d'autres données) au client\n6. Le client se termine\n\nHelm définit deux hooks pour le cycle de vie de l'installation : `pre-install` et\n`post-install`. Si le développeur du chart `foo` implémente ces deux hooks, le\ncycle de vie est modifié ainsi :\n\n1. L'utilisateur exécute `helm install foo`\n2. L'API d'installation de la bibliothèque Helm est appelée\n3. Les CRDs du répertoire `crds/` sont installés\n4. Après quelques vérifications, la bibliothèque effectue le rendu des templates de `foo`\n5. La bibliothèque prépare l'exécution des hooks `pre-install` (chargement des\n   ressources du hook dans Kubernetes)\n6. La bibliothèque trie les hooks par poids (attribuant un poids de 0 par défaut),\n   puis par type de ressource et enfin par nom dans l'ordre croissant\n7. La bibliothèque charge ensuite le hook ayant le poids le plus faible en premier\n   (du négatif vers le positif)\n8. La bibliothèque attend que le hook soit « Ready » (sauf pour les CRDs)\n9. La bibliothèque charge les ressources résultantes dans Kubernetes. Notez que si\n   le drapeau `--wait` est défini, la bibliothèque attendra que toutes les ressources\n   soient dans un état prêt et n'exécutera pas le hook `post-install` tant qu'elles\n   ne le seront pas.\n10. La bibliothèque exécute le hook `post-install` (chargement des ressources du hook)\n11. La bibliothèque attend que le hook soit « Ready »\n12. La bibliothèque renvoie l'objet release (et d'autres données) au client\n13. Le client se termine\n\nQue signifie attendre qu'un hook soit prêt ? Cela dépend de la ressource déclarée\ndans le hook. Si la ressource est de type `Job` ou `Pod`, Helm attendra qu'elle\ns'exécute avec succès jusqu'à son terme. Et si le hook échoue, la release échouera.\nIl s'agit d'une _opération bloquante_, le client Helm se mettra donc en pause\npendant l'exécution du Job.\n\nPour tous les autres types, dès que Kubernetes marque la ressource comme chargée\n(ajoutée ou mise à jour), la ressource est considérée comme « Ready ». Lorsque\nplusieurs ressources sont déclarées dans un hook, elles sont exécutées en série.\nSi elles possèdent des poids de hook (voir ci-dessous), elles sont exécutées dans\nl'ordre de leurs poids.\nÀ partir de Helm 3.2.0, les ressources de hook ayant le même poids sont installées\ndans le même ordre que les ressources normales (non-hook). Sinon, l'ordre n'est pas\ngaranti. (Dans Helm 2.3.0 et versions ultérieures, elles étaient triées par ordre\nalphabétique. Ce comportement n'est toutefois pas considéré comme contraignant et\npourrait changer à l'avenir.) Une bonne pratique consiste à ajouter un poids de hook\net à le définir à `0` si le poids n'est pas important.\n\n### Les ressources de hook ne sont pas gérées avec les releases correspondantes\n\nLes ressources créées par un hook ne sont actuellement pas suivies ni gérées dans\nle cadre de la release. Une fois que Helm a vérifié que le hook a atteint son état\nprêt, il ne touche plus à la ressource du hook. Le nettoyage des ressources de hook\nlors de la suppression de la release correspondante pourrait être ajouté à Helm 3\ndans le futur, donc toute ressource de hook qui ne doit jamais être supprimée doit\nêtre annotée avec `helm.sh/resource-policy: keep`.\n\nEn pratique, cela signifie que si vous créez des ressources dans un hook, vous ne\npouvez pas compter sur `helm uninstall` pour les supprimer. Pour détruire ces\nressources, vous devez soit [ajouter une annotation personnalisée\n`helm.sh/hook-delete-policy`](#politiques-de-suppression-de-hook) au fichier\ntemplate du hook, soit [définir le champ TTL (time to live) d'une ressource\nJob](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Écrire un hook\n\nLes hooks sont simplement des fichiers manifeste Kubernetes avec des annotations\nspéciales dans la section `metadata`. Comme ce sont des fichiers template, vous\npouvez utiliser toutes les fonctionnalités habituelles des templates, y compris\nla lecture de `.Values`, `.Release` et `.Template`.\n\nPar exemple, ce template, stocké dans `templates/post-install-job.yaml`, déclare\nun job à exécuter lors du `post-install` :\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # C'est ce qui définit cette ressource comme un hook. Sans cette ligne,\n    # le job est considéré comme faisant partie de la release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nCe qui fait de ce template un hook, c'est l'annotation :\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nUne ressource peut implémenter plusieurs hooks :\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nDe même, il n'y a pas de limite au nombre de ressources différentes pouvant\nimplémenter un hook donné. Par exemple, on pourrait déclarer à la fois un secret\net un config map comme hook de pre-install.\n\nLorsque des sous-charts déclarent des hooks, ceux-ci sont également évalués. Il\nn'y a aucun moyen pour un chart parent de désactiver les hooks déclarés par les\nsous-charts.\n\nIl est possible de définir un poids pour un hook afin de construire un ordre\nd'exécution déterministe. Les poids sont définis à l'aide de l'annotation suivante :\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nLes poids de hook peuvent être des nombres positifs ou négatifs, mais doivent être\nreprésentés sous forme de chaînes de caractères. Lorsque Helm commence le cycle\nd'exécution des hooks d'un type particulier, il trie ces hooks par ordre croissant.\n\n### Politiques de suppression de hook\n\nIl est possible de définir des politiques qui déterminent quand supprimer les\nressources de hook correspondantes. Les politiques de suppression de hook sont\ndéfinies à l'aide de l'annotation suivante :\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nVous pouvez choisir une ou plusieurs valeurs d'annotation parmi celles définies :\n\n| Valeur de l'annotation | Description                                                                  |\n| ---------------------- | ---------------------------------------------------------------------------- |\n| `before-hook-creation` | Supprime la ressource précédente avant le lancement d'un nouveau hook (défaut) |\n| `hook-succeeded`       | Supprime la ressource après l'exécution réussie du hook                        |\n| `hook-failed`          | Supprime la ressource si le hook a échoué pendant l'exécution                  |\n\nSi aucune annotation de politique de suppression de hook n'est spécifiée, le\ncomportement `before-hook-creation` s'applique par défaut.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/index.mdx",
    "content": "---\ntitle: Thèmes\nsidebar_position: 3\n---\n\n# Guides par thème\n\nDans cette section vous trouverez une introduction pour chacune des parties clés\nde Helm dont vous pourrez avoir besoin.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: APIs Kubernetes dépréciées\ndescription: Explique les APIs Kubernetes dépréciées dans Helm\n---\n\nKubernetes est un système basé sur les APIs, et l'API évolue au fil du temps\npour refléter une meilleure compréhension des problématiques. C'est une pratique\ncourante pour les systèmes et leurs APIs. Une partie importante de l'évolution\ndes APIs est d'avoir une bonne politique et un bon processus de dépréciation\npour informer les utilisateurs de la manière dont les changements d'API sont\nimplémentés. En d'autres termes, les consommateurs de votre API doivent savoir à\nl'avance et dans quelle version une API sera supprimée ou modifiée. Cela évite\nles surprises et les changements incompatibles pour les consommateurs.\n\nLa [politique de dépréciation de\nKubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\ndocumente comment Kubernetes gère les changements de ses versions d'API. Cette\npolitique précise la durée pendant laquelle les versions d'API seront supportées\naprès l'annonce de leur dépréciation. Il est donc important d'être attentif aux\nannonces de dépréciation et de savoir quand les versions d'API seront\nsupprimées, afin de minimiser l'impact.\n\nVoici un exemple d'annonce [concernant la suppression des versions d'API\ndépréciées dans Kubernetes\n1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), publiée\nquelques mois avant la release. Ces versions d'API auraient également été\nannoncées comme dépréciées auparavant. Cela montre qu'une bonne politique est en\nplace pour informer les consommateurs du support des versions d'API.\n\nLes templates Helm spécifient un [groupe d'API\nKubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)\nlors de la définition d'un objet Kubernetes, de manière similaire à un fichier\nmanifeste Kubernetes. Ce groupe est spécifié dans le champ `apiVersion` du\ntemplate et identifie la version d'API de l'objet Kubernetes. Cela signifie que\nles utilisateurs de Helm et les mainteneurs de charts doivent être attentifs aux\nversions d'API Kubernetes qui ont été dépréciées et dans quelle version de\nKubernetes elles seront supprimées.\n\n## Mainteneurs de charts\n\nVous devez auditer vos charts pour vérifier les versions d'API Kubernetes qui\nsont dépréciées ou supprimées dans une version de Kubernetes. Les versions d'API\nidentifiées comme devant être ou étant désormais hors support doivent être mises\nà jour vers la version supportée et une nouvelle version du chart doit être\npubliée. La version d'API est définie par les champs `kind` et `apiVersion`. Par\nexemple, voici une version d'API de l'objet `Deployment` supprimée dans\nKubernetes 1.16 :\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Utilisateurs de Helm\n\nVous devez auditer les charts que vous utilisez (de la même manière que les\n[mainteneurs de charts](#mainteneurs-de-charts)) et identifier ceux dont les\nversions d'API sont dépréciées ou supprimées dans une version de Kubernetes.\nPour les charts identifiés, vous devez vérifier si une version plus récente du\nchart (avec des versions d'API supportées) existe ou mettre à jour le chart\nvous-même.\n\nDe plus, vous devez également auditer les charts déployés (c'est-à-dire les\nreleases Helm) en vérifiant à nouveau les versions d'API dépréciées ou\nsupprimées. Cela peut être fait en obtenant les détails d'une release à l'aide\nde la commande `helm get manifest`.\n\nLa méthode pour mettre à jour une release Helm vers des APIs supportées dépend\nde vos constatations :\n\n1. Si vous ne trouvez que des versions d'API dépréciées :\n  - Effectuez un `helm upgrade` avec une version du chart utilisant des versions\n    d'API Kubernetes supportées\n  - Ajoutez une description lors de la mise à niveau, indiquant de ne pas\n    effectuer de rollback vers une version de Helm antérieure à cette version\n    actuelle\n2. Si vous trouvez des version(s) d'API supprimée(s) dans une version de\n   Kubernetes :\n  - Si vous utilisez une version de Kubernetes où la ou les version(s) d'API\n    sont encore disponibles (par exemple, vous êtes sur Kubernetes 1.15 et vous\n    utilisez des APIs qui seront supprimées dans Kubernetes 1.16) :\n    - Suivez la procédure de l'étape 1\n  - Sinon (par exemple, vous utilisez déjà une version de Kubernetes où\n    certaines versions d'API rapportées par `helm get manifest` ne sont plus\n    disponibles) :\n    - Vous devez modifier le manifeste de release stocké dans le cluster pour\n      mettre à jour les versions d'API vers des APIs supportées. Consultez\n      [Mise à jour des versions d'API d'un manifeste de\n      release](#mise-à-jour-des-versions-dapi-dun-manifeste-de-release) pour\n      plus de détails\n\n> Remarque : Dans tous les cas de mise à jour d'une release Helm avec des APIs\nsupportées, vous ne devez jamais effectuer de rollback de la release vers une\nversion antérieure à la version de release avec les APIs supportées.\n\n> Recommandation : La bonne pratique consiste à mettre à niveau les releases\nutilisant des versions d'API dépréciées vers des versions d'API supportées,\navant de mettre à niveau vers un cluster Kubernetes qui supprime ces versions\nd'API.\n\nSi vous ne mettez pas à jour une release comme suggéré précédemment, vous\nobtiendrez une erreur similaire à la suivante lors de la tentative de mise à\nniveau d'une release dans une version de Kubernetes où sa ou ses version(s)\nd'API est/sont supprimée(s) :\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm échoue dans ce scénario car il tente de créer un patch de différences entre\nla release actuellement déployée (qui contient les APIs Kubernetes supprimées\ndans cette version de Kubernetes) et le chart que vous passez avec les versions\nd'API mises à jour/supportées. La raison sous-jacente de l'échec est que lorsque\nKubernetes supprime une version d'API, la bibliothèque client Go de Kubernetes\nne peut plus parser les objets dépréciés, et Helm échoue donc lors de l'appel à\nla bibliothèque. Helm ne peut malheureusement pas récupérer de cette situation\net n'est plus en mesure de gérer une telle release. Consultez [Mise à jour des\nversions d'API d'un manifeste de release](#mise-à-jour-des-versions-dapi-dun-manifeste-de-release)\npour savoir comment récupérer de ce scénario.\n\n## Mise à jour des versions d'API d'un manifeste de release\n\nLe manifeste est une propriété de l'objet release Helm qui est stockée dans le\nchamp data d'un Secret (par défaut) ou d'un ConfigMap dans le cluster. Le champ\ndata contient un objet compressé en gzip et encodé en base 64 (il y a un\nencodage base 64 supplémentaire pour un Secret). Il y a un Secret/ConfigMap par\nversion/révision de release dans le namespace de la release.\n\nVous pouvez utiliser le plugin Helm\n[mapkubeapis](https://github.com/helm/helm-mapkubeapis) pour effectuer la mise à\njour d'une release vers des APIs supportées. Consultez le readme pour plus de\ndétails.\n\nAlternativement, vous pouvez suivre ces étapes manuelles pour effectuer une mise\nà jour des versions d'API d'un manifeste de release. Selon votre configuration,\nvous suivrez les étapes pour le backend Secret ou ConfigMap.\n\n- Obtenez le nom du Secret ou ConfigMap associé à la dernière release déployée :\n  - Backend Secrets : `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - Backend ConfigMap : `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- Obtenez les détails de la dernière release déployée :\n  - Backend Secrets : `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - Backend ConfigMap : `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- Sauvegardez la release au cas où vous auriez besoin de la restaurer si quelque\n  chose tourne mal :\n  - `cp release.yaml release.bak`\n  - En cas d'urgence, restaurez : `kubectl apply -f release.bak -n\n    <release_namespace>`\n- Décodez l'objet release :\n  - Backend Secrets : `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - Backend ConfigMap : `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- Modifiez les versions d'API des manifestes. Vous pouvez utiliser n'importe\n  quel outil (par exemple, un éditeur) pour effectuer les modifications. Cela se\n  trouve dans le champ `manifest` de votre objet release décodé\n  (`release.data.decoded`)\n- Encodez l'objet release :\n  - Backend Secrets : `cat release.data.decoded | gzip | base64 | base64`\n  - Backend ConfigMap : `cat release.data.decoded | gzip | base64`\n- Remplacez la valeur de la propriété `data.release` dans le fichier de release\n  déployée (`release.yaml`) par le nouvel objet release encodé\n- Appliquez le fichier au namespace : `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- Effectuez un `helm upgrade` avec une version du chart utilisant des versions\n  d'API Kubernetes supportées\n- Ajoutez une description lors de la mise à niveau, indiquant de ne pas\n  effectuer de rollback vers une version de Helm antérieure à cette version\n  actuelle\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: Guide des Distributions Kubernetes\ndescription: Fournit des informations sur l'utilisation de Helm dans des environnements Kubernetes spécifiques.\nsidebar_position: 10\n---\n\nHelm devrait fonctionner avec toute [version conforme de\nKubernetes](https://github.com/cncf/k8s-conformance) (qu'elle soit\n[certifiée](https://www.cncf.io/certification/software-conformance/) ou non).\n\nCe document fournit des informations sur l'utilisation de Helm dans des\nenvironnements Kubernetes spécifiques. Vous pouvez contribuer des informations\nsupplémentaires sur d'autres distributions (triées par ordre alphabétique) si\nvous le souhaitez.\n\n\n## AKS\n\nHelm fonctionne avec [Azure Kubernetes\nService](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nHelm a été testé et fonctionne sur la plateforme Kubernetes de Mesosphere DC/OS\n1.11, sans configuration supplémentaire.\n\n## EKS\n\nHelm fonctionne avec Amazon Elastic Kubernetes Service (Amazon EKS) :\n[Utilisation de Helm avec Amazon\nEKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nLa plateforme Kubernetes hébergée de Google, GKE, fonctionne avec Helm et ne\nnécessite aucune configuration supplémentaire.\n\n## `scripts/local-cluster` et Hyperkube\n\nHyperkube configuré via `scripts/local-cluster.sh` fonctionne correctement. Pour\nHyperkube en mode natif, une configuration manuelle peut être nécessaire.\n\n## IKS\n\nHelm fonctionne avec [IBM Cloud Kubernetes\nService](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nHelm est régulièrement testé avec [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne\n\nHelm fonctionne dans les clusters configurés par KubeOne sans difficulté.\n\n## Kubermatic\n\nHelm fonctionne dans les clusters utilisateurs créés par Kubermatic sans\ndifficulté. Étant donné que les seed clusters peuvent être configurés de\ndifférentes manières, la prise en charge de Helm dépend de leur configuration.\n\n## MicroK8s\n\nHelm peut être activé dans [MicroK8s](https://microk8s.io) avec la commande :\n`microk8s.enable helm3`\n\n## Minikube\n\nHelm est testé et fonctionne avec\n[Minikube](https://github.com/kubernetes/minikube). Aucune configuration\nsupplémentaire n'est requise.\n\n## Openshift\n\nHelm fonctionne directement sur OpenShift Online, OpenShift Dedicated, OpenShift\nContainer Platform (version >= 3.6) ou OpenShift Origin (version >= 3.6). Pour\nen savoir plus, consultez [cet article de\nblog](https://blog.openshift.com/getting-started-helm-openshift/).\n\n## Platform9\n\nHelm est préinstallé avec [Platform9 Managed\nKubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes).\nPlatform9 donne accès à tous les charts Helm officiels via l'interface App\nCatalog et la CLI Kubernetes native. Des dépôts supplémentaires peuvent être\najoutés manuellement. Plus de détails sont disponibles dans cet [article sur\nPlatform9 App\nCatalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes).\n\n## Ubuntu avec `kubeadm`\n\nKubernetes déployé avec `kubeadm` fonctionne sur les distributions Linux\nsuivantes :\n\n- Ubuntu 16.04\n- Fedora release 25\n\nCertaines versions de Helm (v2.0.0-beta2) nécessitent d'exécuter `export\nKUBECONFIG=/etc/kubernetes/admin.conf` ou de créer un fichier `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid\n\nHelm fonctionne sur VMware Tanzu Kubernetes Grid, TKG, sans modification de\nconfiguration. La CLI Tanzu permet de gérer l'installation de packages pour\n[helm-controller](https://fluxcd.io/flux/components/helm/), permettant une\ngestion déclarative des releases de charts Helm. Plus de détails sont\ndisponibles dans la documentation TKG concernant les [packages gérés via\nCLI](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).\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: Charts de type Library\ndescription: Explique les charts de type library et fournit des exemples d'utilisation\nsidebar_position: 4\n---\n\nUn chart de type library est un type de [chart Helm](/topics/charts.md)\nqui définit des primitives ou des définitions pouvant être partagées par les\ntemplates Helm d'autres charts. Cela permet aux utilisateurs de partager des\nextraits de code réutilisables entre plusieurs charts, évitant ainsi la\nrépétition et respectant le principe\n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) (Don't Repeat Yourself).\n\nLe chart de type library a été introduit dans Helm 3 pour reconnaître\nofficiellement les charts communs ou utilitaires utilisés par les mainteneurs\nde charts depuis Helm 2. En l'incluant comme type de chart, il offre :\n- Un moyen de distinguer explicitement les charts communs des charts d'application\n- Une logique empêchant l'installation d'un chart commun\n- Pas de rendu des templates dans un chart commun qui pourraient contenir des\n  artefacts de release\n- La possibilité pour les charts dépendants d'utiliser le contexte de l'importateur\n\nUn mainteneur de chart peut définir un chart commun comme chart de type library\net être ainsi certain que Helm gérera le chart de manière standard et cohérente.\nCela signifie également que les définitions d'un chart d'application peuvent\nêtre partagées simplement en changeant le type de chart.\n\n## Créer un chart de type library simple\n\nComme mentionné précédemment, un chart de type library est un type de\n[chart Helm](/topics/charts.md). Cela signifie que vous pouvez\ncommencer par créer un chart de base :\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nVous allez d'abord supprimer tous les fichiers du répertoire `templates` car\nnous allons créer nos propres définitions de templates dans cet exemple.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nLe fichier values ne sera pas non plus nécessaire.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nAvant de passer à la création du code commun, revenons sur quelques\nconcepts Helm pertinents. Un [template nommé](/chart_template_guide/named_templates.md)\n(parfois appelé partial ou sous-template) est simplement un template défini dans\nun fichier et auquel on donne un nom. Dans le répertoire `templates/`, tout fichier\ncommençant par un underscore (_) n'est pas censé générer un fichier manifeste\nKubernetes. Par convention, les templates utilitaires et les partials sont donc\nplacés dans des fichiers `_*.tpl` ou `_*.yaml`.\n\nDans cet exemple, nous allons coder un ConfigMap commun qui crée une ressource\nConfigMap vide. Nous définirons ce ConfigMap commun dans le fichier\n`mylibchart/templates/_configmap.yaml` comme suit :\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nLa structure ConfigMap est définie dans le template nommé `mylibchart.configmap.tpl`.\nC'est un simple ConfigMap avec une ressource vide, `data`. Dans ce fichier, il y a\nun autre template nommé appelé `mylibchart.configmap`. Ce template nommé inclut un\nautre template nommé `mylibchart.util.merge` qui prend 2 templates nommés comme\narguments : le template appelant `mylibchart.configmap` et `mylibchart.configmap.tpl`.\n\nLa fonction utilitaire `mylibchart.util.merge` est un template nommé dans\n`mylibchart/templates/_util.yaml`. C'est un utilitaire pratique tiré de\n[The Common Helm Helper Chart](#the-common-helm-helper-chart) car il fusionne\nles 2 templates et remplace les parties communes aux deux :\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nCeci est important lorsqu'un chart souhaite utiliser du code commun qu'il doit\npersonnaliser avec sa propre configuration.\n\nEnfin, changeons le type de chart en `library`. Cela nécessite de modifier le\nfichier `mylibchart/Chart.yaml` comme suit :\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\nLe chart de type library est maintenant prêt à être partagé et sa définition de\nConfigMap peut être réutilisée.\n\nAvant de continuer, il est utile de vérifier si Helm reconnaît le chart comme un\nchart de type library :\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Utiliser le chart de type library simple\n\nIl est temps d'utiliser le chart de type library. Cela signifie créer à nouveau\nun chart de base :\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nSupprimons à nouveau les fichiers de templates car nous voulons créer uniquement\nun ConfigMap :\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nLorsque nous voulons créer un simple ConfigMap dans un template Helm, cela\npourrait ressembler à ceci :\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nCependant, nous allons réutiliser le code commun déjà créé dans `mylibchart`.\nLe ConfigMap peut être créé dans le fichier `mychart/templates/configmap.yaml`\ncomme suit :\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nVous pouvez voir que cela simplifie le travail en héritant de la définition\ncommune du ConfigMap qui ajoute les propriétés standard. Dans notre template,\nnous ajoutons la configuration, dans ce cas la clé de données `myvalue` et sa\nvaleur. La configuration remplace la ressource vide du ConfigMap commun. Ceci\nest possible grâce à la fonction utilitaire `mylibchart.util.merge` mentionnée\ndans la section précédente.\n\nPour pouvoir utiliser le code commun, nous devons ajouter `mylibchart` comme\ndépendance. Ajoutez ce qui suit à la fin du fichier `mychart/Chart.yaml` :\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nCela inclut le chart de type library comme dépendance dynamique depuis le\nsystème de fichiers, au même niveau que notre chart d'application. Comme nous\nincluons le chart de type library en tant que dépendance dynamique, nous devons\nexécuter `helm dependency update`. Cette commande copiera le chart de type\nlibrary dans votre répertoire `charts/`.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nNous sommes maintenant prêts à déployer notre chart. Avant l'installation, il\nest utile de vérifier d'abord le template rendu.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nCela ressemble au ConfigMap que nous voulions avec la surcharge de données\n`myvalue: Hello World`. Installons-le :\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nNous pouvons récupérer la release et voir que le template réel a été chargé.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## Avantages des charts de type library\n\nParce qu'ils ne peuvent pas fonctionner comme des charts autonomes, les charts de\ntype library peuvent tirer parti des fonctionnalités suivantes :\n- L'objet `.Files` référence les chemins de fichiers du chart parent, plutôt que\n  le chemin local du chart de type library\n- L'objet `.Values` est le même que celui du chart parent, contrairement aux\n  [sous-charts](/chart_template_guide/subcharts_and_globals.md) d'application\n  qui reçoivent la section de values configurée sous leur en-tête dans le parent.\n\n## The Common Helm Helper Chart\n\n```markdown\nNote: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived.\n```\n\nCe [chart](https://github.com/helm/charts/tree/master/incubator/common) était le\nmodèle original pour les charts communs. Il fournit des utilitaires qui reflètent\nles meilleures pratiques de développement de charts Kubernetes. Et surtout, il\npeut être utilisé immédiatement lors du développement de vos charts pour vous\nfournir du code partagé pratique.\n\nVoici une façon rapide de l'utiliser. Pour plus de détails, consultez le\n[README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nCréez à nouveau un chart de base :\n\n```console\n$ helm create demo\nCreating demo\n```\n\nUtilisons le code commun du chart utilitaire. Tout d'abord, modifiez le déploiement\n`demo/templates/deployment.yaml` comme suit :\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nEt maintenant le fichier service, `demo/templates/service.yaml` comme suit :\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nCes templates montrent comment hériter du code commun du chart utilitaire\nsimplifie votre codage à la seule configuration ou personnalisation des\nressources.\n\nPour pouvoir utiliser le code commun, nous devons ajouter `common` comme\ndépendance. Ajoutez ce qui suit à la fin du fichier `demo/Chart.yaml` :\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nNote : Vous devrez ajouter le dépôt `incubator` à la liste des dépôts Helm\n(`helm repo add`).\n\nComme nous incluons le chart en tant que dépendance dynamique, nous devons\nexécuter `helm dependency update`. Cette commande copiera le chart utilitaire\ndans votre répertoire `charts/`.\n\nComme le chart utilitaire utilise certaines constructions de Helm 2, vous devrez\najouter ce qui suit à `demo/values.yaml` pour permettre le chargement de l'image\n`nginx`, car cela a été mis à jour dans le chart de base de Helm 3 :\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nVous pouvez tester que les templates du chart sont corrects avant de déployer en\nutilisant les commandes `helm lint` et `helm template`.\n\nSi tout est en ordre, déployez avec `helm install` !\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Gestion des permissions pour le backend de stockage SQL\ndescription: Découvrez comment configurer les permissions lors de l'utilisation du backend de stockage SQL.\n---\n\nCe document explique comment configurer et gérer les permissions lors de\nl'utilisation du backend de stockage SQL.\n\n## Introduction\n\nPour gérer les permissions, Helm s'appuie sur la fonctionnalité RBAC de\nKubernetes. Lorsque vous utilisez le backend de stockage SQL, les rôles\nKubernetes ne peuvent pas être utilisés pour déterminer si un utilisateur peut\naccéder à une ressource donnée ou non. Ce document explique comment créer et\ngérer ces permissions.\n\n## Initialisation\n\nLa première fois que le CLI Helm se connectera à votre base de données, le\nclient s'assurera qu'elle a été préalablement initialisée. Si ce n'est pas le\ncas, il effectuera automatiquement la configuration nécessaire. Cette\ninitialisation nécessite des privilèges d'administrateur sur le schéma public,\nou au minimum la capacité de :\n\n* créer une table\n* accorder des privilèges sur le schéma public\n\nUne fois la migration exécutée sur votre base de données, tous les autres rôles\npeuvent utiliser le client.\n\n## Accorder des privilèges à un utilisateur non administrateur dans PostgreSQL\n\nPour gérer les permissions, le pilote du backend SQL utilise la fonctionnalité\n[RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security\nLevel) de PostgreSQL. RLS permet à tous les utilisateurs de lire et écrire dans\nla même table, sans pouvoir manipuler les mêmes lignes s'ils n'y sont pas\nexplicitement autorisés. Par défaut, tout rôle qui n'a pas reçu explicitement\nles privilèges appropriés obtiendra toujours une liste vide lors de l'exécution\nde `helm list` et ne pourra ni récupérer ni modifier aucune ressource dans le\ncluster.\n\nVoyons comment accorder à un rôle donné l'accès à des namespaces spécifiques :\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nCette commande accordera au rôle `role` les permissions de lecture et d'écriture\nsur toutes les ressources qui respectent la condition `namespace = 'default'`.\nAprès la création de cette politique, l'utilisateur connecté à la base de\ndonnées pour le compte du rôle `role` pourra voir toutes les releases présentes\ndans le namespace `default` lors de l'exécution de `helm list`, ainsi que les\nmodifier et les supprimer.\n\nLes privilèges peuvent être gérés de manière granulaire avec RLS, et vous\npouvez restreindre l'accès en fonction des différentes colonnes de la table :\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Guide des plugins Helm\ndescription: Présente comment utiliser et créer des plugins pour étendre les fonctionnalités de Helm.\nsidebar_position: 12\n---\n\nUn plugin Helm est un outil accessible via la CLI `helm`, mais qui ne fait pas partie du code source intégré de Helm.\n\nLes 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).\n\nCe guide explique comment utiliser et créer des plugins.\n\n## Vue d'ensemble\n\nLes 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.\n\nLes plugins Helm possèdent les caractéristiques suivantes :\n\n- Ils peuvent être ajoutés et supprimés d'une installation Helm sans impacter l'outil Helm principal.\n- Ils peuvent être écrits dans n'importe quel langage de programmation.\n- Ils s'intègrent à Helm et apparaissent dans `helm help` et ailleurs.\n\nLes 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`.\n\nLe 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.\n\n## Installer un plugin\n\nLes plugins sont installés à l'aide de la commande `$ helm plugin install <path|url>`. 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`.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nSi 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`\n\n## Structure de fichiers d'un plugin\n\nÀ 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.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## Le fichier plugin.yaml\n\nLe fichier plugin.yaml est requis pour un plugin. Il contient les champs suivants :\n\n```yaml\nname: The name of the plugin (REQUIRED)\nversion: A SemVer 2 version (REQUIRED)\nusage: Single line usage text shown in help\ndescription: Long description shown in places like helm help\nignoreFlags: Ignore flags passed in from Helm\nplatformCommand: # Configure command to run based on the platform\n  - os: OS match, can be empty or omitted to match all OS'\n    arch: Architecture match, can be empty or omitted to match all architectures\n    command: Plugin command to execute\n    args: Plugin command arguments\ncommand: (DEPRECATED) Plugin command, use platformCommand instead\nplatformHooks: # Configure plugin lifecycle hooks based on the platform\n  install: # Install lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin install command to execute\n      args: Plugin install command arguments\n  update: # Update lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin update command to execute\n      args: Plugin update command arguments\n  delete: # Delete lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin delete command to execute\n      args: Plugin delete command arguments\nhooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead\n  install: Command to install plugin\n  update: Command to update plugin\n  delete: Command to delete plugin\ndownloaders: # Configure downloaders capability\n  - command: Command to invoke\n    protocols:\n      - Protocol schema supported\n```\n\n### Le champ `name`\n\nLe 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).\n\n_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`.\n\nRestrictions sur `name` :\n\n- `name` ne peut pas dupliquer l'une des commandes de premier niveau existantes de `helm`.\n- `name` doit être limité aux caractères ASCII a-z, A-Z, 0-9, `_` et `-`.\n\n### Le champ `version`\n\nLe 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.\n\n### Le champ `ignoreFlags`\n\nLe 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.\n\n### Le champ `platformCommand`\n\nLe 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 :\n\n- Si `platformCommand` est présent, il sera utilisé.\n  - Si `os` et `arch` correspondent à la plateforme actuelle, la recherche s'arrête et la commande sera utilisée.\n  - Si `os` correspond et `arch` est vide, la commande sera utilisée.\n  - Si `os` et `arch` sont tous deux vides, la commande sera utilisée.\n  - S'il n'y a pas de correspondance, Helm se terminera avec une erreur.\n- Si `platformCommand` n'est pas présent et que la commande dépréciée `command` est présente, elle sera utilisée.\n  - Si la commande est vide, Helm se terminera avec une erreur.\n\n### Le champ `platformHooks`\n\nLe 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 :\n\n- Si `platformHooks` est présent, il sera utilisé et les commandes pour l'événement du cycle de vie seront traitées.\n  - Si `os` et `arch` correspondent à la plateforme actuelle, la recherche s'arrête et la commande sera utilisée.\n  - Si `os` correspond et `arch` est vide, la commande sera utilisée.\n  - Si `os` et `arch` sont tous deux vides, la commande sera utilisée.\n  - S'il n'y a pas de correspondance, Helm ignorera l'événement.\n- 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.\n  - Si la commande est vide, Helm ignorera l'événement.\n\n## Créer un plugin\n\nVoici le YAML de plugin pour un plugin simple qui aide à obtenir le nom de la dernière release :\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nLes 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 :\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nLes 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.\n\n### Commandes de plugin\n\nIl existe quelques stratégies pour travailler avec les commandes de plugin :\n\n- 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.\n- 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.\n- 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.\n- Helm injecte beaucoup de configuration dans les variables d'environnement. Consultez l'environnement pour voir quelles informations sont disponibles.\n- Helm ne fait aucune supposition sur le langage du plugin. Vous pouvez l'écrire dans le langage de votre choix.\n- 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`.\n\n### Tester un plugin local\n\nVous devez d'abord trouver votre chemin `HELM_PLUGINS`. Pour ce faire, exécutez la commande suivante :\n\n``` bash\nhelm env\n```\n\nChangez votre répertoire actuel vers le répertoire défini par `HELM_PLUGINS`.\n\nMaintenant vous pouvez ajouter un lien symbolique vers la sortie de build de votre plugin. Dans cet exemple, nous l'avons fait pour `mapkubeapis`.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Plugins téléchargeurs\n\nPar 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.\n\nLes plugins doivent déclarer cette capacité spéciale dans le fichier `plugin.yaml` (au niveau supérieur) :\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nSi 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.\n\nLa 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.\n\nLa 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.\n\n## Variables d'environnement\n\nLorsque Helm exécute un plugin, il transmet l'environnement externe au plugin et injecte également quelques variables d'environnement supplémentaires.\n\nLes variables comme `KUBECONFIG` sont définies pour le plugin si elles sont définies dans l'environnement externe.\n\nLes variables suivantes sont garanties d'être définies :\n\n- `HELM_PLUGINS` : Le chemin vers le répertoire des plugins.\n- `HELM_PLUGIN_NAME` : Le nom du plugin, tel qu'invoqué par `helm`. Ainsi `helm myplug` aura le nom court `myplug`.\n- `HELM_PLUGIN_DIR` : Le répertoire qui contient le plugin.\n- `HELM_BIN` : Le chemin vers la commande `helm` (telle qu'exécutée par l'utilisateur).\n- `HELM_DEBUG` : Indique si le flag debug a été défini par helm.\n- `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.\n- `HELM_REPOSITORY_CACHE` : Le chemin vers les fichiers de cache du dépôt.\n- `HELM_REPOSITORY_CONFIG` : Le chemin vers le fichier de configuration du dépôt.\n- `HELM_NAMESPACE` : Le namespace donné à la commande `helm` (généralement via le flag `-n`).\n- `HELM_KUBECONTEXT` : Le nom du contexte de configuration Kubernetes donné à la commande `helm`.\n\nDe plus, si un fichier de configuration Kubernetes a été explicitement spécifié, il sera défini comme variable `KUBECONFIG`.\n\n## Note sur l'analyse des flags\n\nLors 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.\n- `--burst-limit` : Converti en `$HELM_BURST_LIMIT`\n- `--debug` : Si spécifié, `$HELM_DEBUG` est défini à `1`\n- `--kube-apiserver` : Converti en `$HELM_KUBEAPISERVER`\n- `--kube-as-group` : Converti en `$HELM_KUBEASGROUPS`\n- `--kube-as-user` : Converti en `$HELM_KUBEASUSER`\n- `--kube-ca-file` : Converti en `$HELM_KUBECAFILE`\n- `--kube-context` : Converti en `$HELM_KUBECONTEXT`\n- `--kube-insecure-skip-tls-verify` : Converti en `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`\n- `--kube-tls-server-name` : Converti en `$HELM_KUBETLS_SERVER_NAME`\n- `--kube-token` : Converti en `$HELM_KUBETOKEN`\n- `--kubeconfig` : Converti en `$KUBECONFIG`\n- `--namespace` et `-n` : Converti en `$HELM_NAMESPACE`\n- `--qps` : Converti en `$HELM_QPS`\n- `--registry-config` : Converti en `$HELM_REGISTRY_CONFIG`\n- `--repository-cache` : Converti en `$HELM_REPOSITORY_CACHE`\n- `--repository-config` : Converti en `$HELM_REPOSITORY_CONFIG`\n\nLes 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é.\n\n## Fournir l'auto-complétion shell\n\nÀ 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.\n\n### Auto-complétion statique\n\nSi 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 :\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nNotes :\n\n1. Toutes les sections sont optionnelles mais doivent être fournies si applicables.\n1. Les flags ne doivent pas inclure le préfixe `-` ou `--`.\n1. 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.\n1. 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.\n1. 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.\n1. 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.\n\nLe 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.\n\nPar 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 :\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nUn exemple plus élaboré pour le plugin [`2to3`](https://github.com/helm/helm-2to3), a un fichier `completion.yaml` de :\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### Complétion dynamique\n\nÉ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.\n\nPour 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.\n\nLe 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.\n\nLa sortie du script `plugin.complete` doit être une liste séparée par des sauts de ligne telle que :\n\n```console\nrel1\nrel2\nrel3\n```\n\nLorsque `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.\n\nLe 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).\n\nDans 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.\n\nSi 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 :\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nLe vrai script du plugin `fullstatus` (`status.sh`) doit alors rechercher le flag `--complete` et si trouvé, afficher les complétions appropriées.\n\n### Astuces et conseils\n\n1. 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<TAB>`, 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`.\n1. 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.\n1. 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 :\n    - `helm __complete <pluginName> <arguments to complete>`. Par exemple :\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: Provenance et intégrité dans Helm\ndescription: Décrit comment vérifier l'intégrité et l'origine d'un Chart.\nsidebar_position: 5\n---\n\nHelm dispose d'outils de provenance qui aident les utilisateurs de charts à\nvérifier l'intégrité et l'origine d'un package. Basé sur des outils standard de\nl'industrie comme PKI, GnuPG et des gestionnaires de paquets reconnus, Helm peut\ngénérer et vérifier des fichiers de signature.\n\n## Vue d'ensemble\n\nL'intégrité est établie en comparant un chart à un enregistrement de provenance.\nCes enregistrements sont stockés dans des _fichiers de provenance_, conservés aux\ncôtés du chart packageé. Par exemple, si un chart est nommé `myapp-1.2.3.tgz`,\nson fichier de provenance sera `myapp-1.2.3.tgz.prov`.\n\nLes fichiers de provenance sont générés lors du packaging (`helm package --sign ...`)\net peuvent être vérifiés par plusieurs commandes, notamment `helm install --verify`.\n\n## Le flux de travail\n\nCette section décrit un flux de travail possible pour utiliser efficacement les\ndonnées de provenance.\n\nPrérequis :\n\n- Une paire de clés PGP valide au format binaire (pas au format ASCII-armored)\n- L'outil en ligne de commande `helm`\n- Les outils en ligne de commande GnuPG (optionnel)\n- Les outils en ligne de commande Keybase (optionnel)\n\n**NOTE :** Si votre clé privée PGP possède une phrase de passe, vous serez invité\nà la saisir pour toute commande prenant en charge l'option `--sign`.\n\nLa création d'un nouveau chart se fait comme d'habitude :\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nLorsque vous êtes prêt à packager, ajoutez le drapeau `--sign` à `helm package`.\nSpécifiez également le nom sous lequel la clé de signature est connue ainsi que\nle trousseau de clés contenant la clé privée correspondante :\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**Note :** La valeur de l'argument `--key` doit être une sous-chaîne de l'`uid`\nde la clé souhaitée (tel qu'affiché par `gpg --list-keys`), par exemple le nom ou\nl'email. **L'empreinte _ne peut pas_ être utilisée.**\n\n**ASTUCE :** Pour les utilisateurs de GnuPG, votre trousseau de clés secrètes se\ntrouve dans `~/.gnupg/secring.gpg`. Utilisez `gpg --list-secret-keys` pour lister\nvos clés disponibles.\n\n**Attention :** GnuPG v2 stocke votre trousseau de clés secrètes dans un nouveau\nformat `kbx` à l'emplacement par défaut `~/.gnupg/pubring.kbx`. Utilisez la\ncommande suivante pour convertir votre trousseau au format gpg historique :\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nÀ ce stade, vous devriez voir à la fois `mychart-0.1.0.tgz` et\n`mychart-0.1.0.tgz.prov`. Ces deux fichiers doivent ensuite être téléversés vers\nvotre dépôt de charts.\n\nVous pouvez vérifier un chart avec `helm verify` :\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nUne vérification échouée ressemble à ceci :\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nPour vérifier lors d'une installation, utilisez le drapeau `--verify`.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nSi le trousseau de clés contenant la clé publique associée au chart signé n'est\npas à l'emplacement par défaut, vous devrez peut-être indiquer le trousseau avec\n`--keyring PATH` comme dans l'exemple `helm package`.\n\nSi la vérification échoue, l'installation sera annulée avant même que le chart\nne soit rendu.\n\n### Utiliser les identifiants Keybase.io\n\nLe service [Keybase.io](https://keybase.io) facilite l'établissement d'une chaîne\nde confiance pour une identité cryptographique. Les identifiants Keybase peuvent\nêtre utilisés pour signer des charts.\n\nPrérequis :\n\n- Un compte Keybase.io configuré\n- GnuPG installé localement\n- La CLI `keybase` installée localement\n\n#### Signer des packages\n\nLa première étape consiste à importer vos clés Keybase dans votre trousseau\nGnuPG local :\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nCela convertira votre clé Keybase au format OpenPGP, puis l'importera localement\ndans votre fichier `~/.gnupg/secring.gpg`.\n\nVous pouvez vérifier en exécutant `gpg --list-secret-keys`.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nNotez que votre clé secrète possède une chaîne d'identification :\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nC'est le nom complet de votre clé.\n\nEnsuite, vous pouvez packager et signer un chart avec `helm package`. Assurez-vous\nd'utiliser au moins une partie de cette chaîne de nom dans `--key`.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nEn résultat, la commande `package` produira à la fois un fichier `.tgz` et un\nfichier `.tgz.prov`.\n\n#### Vérifier des packages\n\nVous pouvez également utiliser une technique similaire pour vérifier un chart\nsigné avec la clé Keybase d'une autre personne. Supposons que vous souhaitiez\nvérifier un package signé par `keybase.io/technosophos`. Utilisez l'outil\n`keybase` :\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nLa première commande suit l'utilisateur `technosophos`. Ensuite, `keybase pgp pull`\ntélécharge les clés OpenPGP de tous les comptes que vous suivez et les place dans\nvotre trousseau GnuPG (`~/.gnupg/pubring.gpg`).\n\nÀ ce stade, vous pouvez utiliser `helm verify` ou n'importe quelle commande avec\nle drapeau `--verify` :\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Raisons pour lesquelles un chart peut ne pas être vérifié\n\nVoici les raisons courantes d'échec.\n\n- Le fichier `.prov` est manquant ou corrompu. Cela indique que quelque chose est\n  mal configuré ou que le mainteneur original n'a pas créé de fichier de\n  provenance.\n- La clé utilisée pour signer le fichier n'est pas dans votre trousseau. Cela\n  indique que l'entité qui a signé le chart n'est pas quelqu'un en qui vous avez\n  déjà indiqué avoir confiance.\n- La vérification du fichier `.prov` a échoué. Cela indique un problème avec le\n  chart ou les données de provenance.\n- Les hachages de fichiers dans le fichier de provenance ne correspondent pas au\n  hachage du fichier d'archive. Cela indique que l'archive a été altérée.\n\nSi une vérification échoue, il convient de se méfier du package.\n\n## Le fichier de provenance\n\nLe fichier de provenance contient le fichier YAML du chart ainsi que plusieurs\ninformations de vérification. Les fichiers de provenance sont conçus pour être\ngénérés automatiquement.\n\nLes données de provenance suivantes sont ajoutées :\n\n* Le fichier du chart (`Chart.yaml`) est inclus pour donner aux humains et aux\n  outils une vue claire du contenu du chart.\n* La signature (SHA256, comme Docker) du package du chart (le fichier `.tgz`)\n  est incluse et peut être utilisée pour vérifier l'intégrité du package.\n* L'ensemble du corps est signé avec l'algorithme utilisé par OpenPGP (voir\n  [Keybase.io](https://keybase.io) pour une méthode émergente de signature et de\n  vérification cryptographiques simplifiées).\n\nCette combinaison donne aux utilisateurs les assurances suivantes :\n\n* Le package lui-même n'a pas été altéré (somme de contrôle du package `.tgz`).\n* L'entité qui a publié ce package est connue (via la signature GnuPG/PGP).\n\nLe format du fichier ressemble à ceci :\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nNotez que la section YAML contient deux documents (séparés par `...\\n`). Le\npremier est le contenu de `Chart.yaml`. Le second contient les sommes de\ncontrôle : une correspondance entre les noms de fichiers et les condensés SHA-256\ndu contenu de chaque fichier au moment du packaging.\n\nLe bloc de signature est une signature PGP standard, qui fournit une [résistance\nà l'altération](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Dépôts de charts\n\nLes dépôts de charts constituent une collection centralisée de charts Helm.\n\nLes dépôts de charts doivent permettre de servir les fichiers de provenance via\nHTTP par une requête spécifique, et doivent les rendre disponibles au même chemin\nURI que le chart.\n\nPar exemple, si l'URL de base d'un package est\n`https://example.com/charts/mychart-1.2.3.tgz`, le fichier de provenance, s'il\nexiste, DOIT être accessible à\n`https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nDu point de vue de l'utilisateur final, `helm install --verify myrepo/mychart-1.2.3`\ndoit entraîner le téléchargement du chart et du fichier de provenance sans\nconfiguration ni action supplémentaire de l'utilisateur.\n\n### Signatures dans les registres basés sur OCI\n\nLors de la publication de charts vers un [registre basé sur OCI](/topics/registries.md),\nle [plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) peut être\nutilisé pour publier la provenance sur [sigstore](https://sigstore.dev/). [Comme\ndécrit dans la documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md),\nle processus de création de provenance et de signature avec une clé GPG est\ncommun, mais la commande `helm sigstore upload` peut être utilisée pour publier\nla provenance vers un journal de transparence immuable.\n\n## Établir l'autorité et l'authenticité\n\nDans les systèmes basés sur une chaîne de confiance, il est important de pouvoir\nétablir l'autorité d'un signataire. Autrement dit, le système ci-dessus repose\nsur le fait que vous faites confiance à la personne qui a signé le chart. Ce qui\nimplique que vous devez faire confiance à la clé publique du signataire.\n\nL'une des décisions de conception de Helm a été de ne pas s'insérer dans la\nchaîne de confiance en tant que partie nécessaire. Nous ne voulons pas être\n« l'autorité de certification » pour tous les signataires de charts. Nous\nprivilégions un modèle décentralisé, ce qui explique notre choix d'OpenPGP comme\ntechnologie de base. Concernant l'établissement de l'autorité, nous avons laissé\ncette étape relativement indéfinie dans Helm 2 (décision reprise dans Helm 3).\n\nCependant, voici quelques conseils et recommandations pour ceux qui souhaitent\nutiliser le système de provenance :\n\n- La plateforme [Keybase](https://keybase.io) fournit un dépôt public centralisé\n  pour les informations de confiance.\n  - Vous pouvez utiliser Keybase pour stocker vos clés ou obtenir les clés\n    publiques d'autres personnes.\n  - Keybase dispose également d'une excellente documentation.\n  - Bien que nous ne l'ayons pas testé, la fonctionnalité « site web sécurisé »\n    de Keybase pourrait être utilisée pour servir des charts Helm.\n  - L'idée de base est qu'un « réviseur de charts » officiel signe les charts\n    avec sa clé, et le fichier de provenance résultant est ensuite téléversé\n    vers le dépôt de charts.\n  - Des travaux ont été menés sur l'idée qu'une liste de clés de signature\n    valides pourrait être incluse dans le fichier `index.yaml` d'un dépôt.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: Contrôle d'accès basé sur les rôles\ndescription: Explique comment Helm interagit avec le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes.\nsidebar_position: 11\n---\n\nDans Kubernetes, attribuer des rôles à un utilisateur ou à un compte de service\nspécifique à une application est une bonne pratique pour garantir que votre\napplication fonctionne dans le périmètre que vous avez défini. Pour en savoir\nplus sur les permissions des comptes de service, consultez [la documentation\nofficielle de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nDepuis Kubernetes 1.6, le contrôle d'accès basé sur les rôles est activé par\ndéfaut. RBAC vous permet de spécifier quels types d'actions sont autorisées en\nfonction de l'utilisateur et de son rôle dans votre organisation.\n\nAvec RBAC, vous pouvez :\n\n- accorder des opérations privilégiées (création de ressources à l'échelle du\n  cluster, comme de nouveaux rôles) aux administrateurs\n- limiter la capacité d'un utilisateur à créer des ressources (Pods, volumes\n  persistants, Deployments) à des namespaces spécifiques, ou à l'échelle du\n  cluster (quotas de ressources, rôles, Custom Resource Definitions)\n- limiter la capacité d'un utilisateur à visualiser des ressources dans des\n  namespaces spécifiques ou à l'échelle du cluster.\n\nCe guide s'adresse aux administrateurs qui souhaitent restreindre le périmètre\nd'interaction d'un utilisateur avec l'API Kubernetes.\n\n## Gestion des comptes utilisateurs\n\nTous les clusters Kubernetes disposent de deux catégories d'utilisateurs : les\ncomptes de service gérés par Kubernetes, et les utilisateurs normaux.\n\nLes utilisateurs normaux sont supposés être gérés par un service externe\nindépendant. Il peut s'agir d'un administrateur distribuant des clés privées,\nd'un annuaire d'utilisateurs comme Keystone ou Google Accounts, voire d'un\nfichier contenant une liste de noms d'utilisateurs et de mots de passe. À cet\négard, Kubernetes ne possède pas d'objets représentant les comptes utilisateurs\nnormaux. Les utilisateurs normaux ne peuvent pas être ajoutés à un cluster via\nun appel API.\n\nEn revanche, les comptes de service sont des utilisateurs gérés par l'API\nKubernetes. Ils sont liés à des namespaces spécifiques et créés automatiquement\npar le serveur API ou manuellement via des appels API. Les comptes de service\nsont associés à un ensemble d'identifiants stockés en tant que Secrets, qui sont\nmontés dans les Pods permettant aux processus du cluster de communiquer avec\nl'API Kubernetes.\n\nLes requêtes API sont liées soit à un utilisateur normal, soit à un compte de\nservice, soit traitées comme des requêtes anonymes. Cela signifie que chaque\nprocessus à l'intérieur ou à l'extérieur du cluster, qu'il s'agisse d'un\nutilisateur humain exécutant `kubectl` sur un poste de travail, des kubelets sur\nles nœuds, ou des membres du plan de contrôle, doit s'authentifier lors des\nrequêtes au serveur API, sinon il sera traité comme un utilisateur anonyme.\n\n## Roles, ClusterRoles, RoleBindings et ClusterRoleBindings\n\nDans Kubernetes, les comptes utilisateurs et les comptes de service ne peuvent\nvisualiser et modifier que les ressources auxquelles ils ont été autorisés à\naccéder. Cet accès est accordé via l'utilisation de Roles et de RoleBindings.\nLes Roles et RoleBindings sont liés à un namespace particulier, ce qui permet\naux utilisateurs de visualiser et/ou de modifier les ressources au sein de ce\nnamespace auxquelles le Role leur donne accès.\n\nÀ l'échelle du cluster, on parle de ClusterRoles et de ClusterRoleBindings.\nAccorder un ClusterRole à un utilisateur lui donne accès à la visualisation\net/ou à la modification des ressources sur l'ensemble du cluster. C'est\négalement nécessaire pour visualiser et/ou modifier des ressources à l'échelle\ndu cluster (namespaces, quotas de ressources, nœuds).\n\nLes ClusterRoles peuvent être liés à un namespace particulier via une référence\ndans un RoleBinding. Les ClusterRoles par défaut `admin`, `edit` et `view` sont\ncouramment utilisés de cette manière.\n\nVoici quelques ClusterRoles disponibles par défaut dans Kubernetes. Ils sont\ndestinés aux utilisateurs finaux. Ils comprennent des rôles de super-utilisateur\n(`cluster-admin`), et des rôles avec des accès plus granulaires (`admin`,\n`edit`, `view`).\n\n| ClusterRole par défaut | ClusterRoleBinding par défaut | Description\n|------------------------|-------------------------------|-------------\n| `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.\n| `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.\n| `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.\n| `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.\n\n## Restreindre l'accès d'un compte utilisateur avec RBAC\n\nMaintenant que nous comprenons les bases du contrôle d'accès basé sur les rôles,\nvoyons comment un administrateur peut restreindre le périmètre d'accès d'un\nutilisateur.\n\n### Exemple : Accorder à un utilisateur un accès en lecture/écriture à un namespace particulier\n\nPour restreindre l'accès d'un utilisateur à un namespace particulier, nous\npouvons utiliser soit le rôle `edit`, soit le rôle `admin`. Si vos charts créent\nou interagissent avec des Roles et des RoleBindings, vous devrez utiliser le\nClusterRole `admin`.\n\nDe plus, vous pouvez également créer un RoleBinding avec un accès\n`cluster-admin`. Accorder à un utilisateur l'accès `cluster-admin` au niveau\nd'un namespace lui donne un contrôle total sur chaque ressource du namespace, y\ncompris le namespace lui-même.\n\nPour cet exemple, nous allons créer un utilisateur avec le Role `edit`. Tout\nd'abord, créez le namespace :\n\n```console\n$ kubectl create namespace foo\n```\n\nEnsuite, créez un RoleBinding dans ce namespace, accordant à l'utilisateur le\nrôle `edit`.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Exemple : Accorder à un utilisateur un accès en lecture/écriture à l'échelle du cluster\n\nSi un utilisateur souhaite installer un chart qui installe des ressources à\nl'échelle du cluster (namespaces, rôles, Custom Resource Definitions, etc.), il\naura besoin d'un accès en écriture à l'échelle du cluster.\n\nPour cela, accordez à l'utilisateur l'accès `admin` ou `cluster-admin`.\n\nAccorder à un utilisateur l'accès `cluster-admin` lui donne accès à absolument\ntoutes les ressources disponibles dans Kubernetes, y compris l'accès aux nœuds\navec `kubectl drain` et d'autres tâches administratives. Il est fortement\nrecommandé d'envisager de fournir à l'utilisateur l'accès `admin` à la place, ou\nde créer un ClusterRole personnalisé adapté à ses besoins.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Exemple : Accorder à un utilisateur un accès en lecture seule à un namespace particulier\n\nVous avez peut-être remarqué qu'il n'existe pas de ClusterRole permettant de\nvisualiser les Secrets. Le ClusterRole `view` n'accorde pas l'accès en lecture\naux Secrets car cela permettrait une élévation de privilèges. Helm stocke les\nmétadonnées des releases en tant que Secrets par défaut.\n\nPour qu'un utilisateur puisse exécuter `helm list`, il doit pouvoir lire ces\nSecrets. Pour cela, nous allons créer un ClusterRole spécial `secret-reader`.\n\nCréez le fichier `cluster-role-secret-reader.yaml` et écrivez le contenu suivant\ndans le fichier :\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nEnsuite, créez le ClusterRole avec la commande :\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nUne fois cela fait, nous pouvons accorder à un utilisateur un accès en lecture à\nla plupart des ressources, puis lui accorder un accès en lecture aux Secrets :\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Exemple : Accorder à un utilisateur un accès en lecture seule à l'échelle du cluster\n\nDans certains scénarios, il peut être utile d'accorder à un utilisateur un accès\nà l'échelle du cluster. Par exemple, si un utilisateur souhaite exécuter la\ncommande `helm list --all-namespaces`, l'API exige que l'utilisateur dispose\nd'un accès en lecture à l'échelle du cluster.\n\nPour cela, accordez à l'utilisateur les accès `view` et `secret-reader` comme\ndécrit ci-dessus, mais avec un ClusterRoleBinding.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Réflexions supplémentaires\n\nLes exemples présentés ci-dessus utilisent les ClusterRoles par défaut fournis\navec Kubernetes. Pour un contrôle plus fin sur les ressources auxquelles les\nutilisateurs ont accès, consultez [la documentation\nKubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) sur\nla création de vos propres Roles et ClusterRoles personnalisés.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: Utiliser des registres basés sur OCI\ndescription: Décrit comment utiliser OCI pour la distribution de charts.\nsidebar_position: 7\n---\n\nÀ 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.\n\n\n## Support OCI avant la version v3.8.0\n\nLe 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.\n\n### Activer le support OCI avant la version v3.8.0\n\nAvant Helm v3.8.0, le support OCI est *expérimental* et doit être activé manuellement.\n\nPour 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 :\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### Dépréciation de fonctionnalités OCI et changements de comportement avec la v3.8.0\n\nAvec 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 :\n\n- 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.\n- 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.\n- 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.\n\n### Dépréciation de fonctionnalités OCI et changements de comportement avec la v3.7.0\n\nAvec 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 :\n\n- La sous-commande `helm chart` a été supprimée.\n- Le cache de charts a été supprimé (plus de `helm chart list`, etc.).\n- Les références aux registres OCI sont désormais toujours préfixées par `oci://`.\n- Le nom de base de la référence au registre doit *toujours* correspondre au nom du chart.\n- 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`).\n- 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`.\n\n\n## Utiliser un registre basé sur OCI\n\n### Dépôts Helm dans des registres basés sur OCI\n\nUn [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.\n\n### Utiliser des registres hébergés\n\nIl existe plusieurs registres de conteneurs hébergés avec support OCI que vous pouvez utiliser pour vos charts Helm. Par exemple :\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\nConsultez la documentation de votre fournisseur de registre de conteneurs hébergé pour créer et configurer un registre compatible OCI.\n\n**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.\n\n### Utiliser Sigstore pour signer des charts basés sur OCI\n\nLe 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.\n\nPour 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).\n\n## Commandes pour travailler avec les registres\n\n### La sous-commande `registry`\n\n#### `login`\n\nSe connecter à un registre (avec saisie manuelle du mot de passe)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nSe déconnecter d'un registre\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### La sous-commande `push`\n\nTéléverser un chart vers un registre basé sur OCI :\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nLa sous-commande `push` s'utilise uniquement avec des fichiers `.tgz` créés au préalable avec `helm package`.\n\nLors 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.\n\nLe 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.\n\nCertains 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`.\n\nSi 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).\n\nLes 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`.\n\n### Autres sous-commandes\n\nLe support du protocole `oci://` est également disponible dans plusieurs autres sous-commandes. Voici la liste complète :\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nLe 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).\n\nVoici quelques exemples d'utilisation des sous-commandes listées ci-dessus avec des charts basés sur OCI :\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Installer des charts avec un digest\n\nInstaller 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 :\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## Spécifier les dépendances\n\nLes dépendances d'un chart peuvent être récupérées depuis un registre en utilisant la sous-commande `dependency update`.\n\nLe `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 :\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\nCela récupérera `oci://localhost:5000/myrepo/mychart:2.7.0` lors de l'exécution de `dependency update`.\n\n## Manifeste du chart Helm\n\nExemple de manifeste de chart Helm tel que représenté dans un registre (remarquez les champs `mediaType`) :\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nL'exemple suivant contient un [fichier de provenance](/topics/provenance.md) (notez la couche supplémentaire) :\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Migration depuis des dépôts de charts\n\nLa 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.\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: Migration de Helm v2 vers v3\ndescription: Apprenez comment migrer Helm v2 vers v3.\nsidebar_position: 13\n---\n\nCe guide explique comment migrer de Helm v2 vers v3. Helm v2 doit être installé\net gérer des releases dans un ou plusieurs clusters.\n\n## Aperçu des changements dans Helm 3\n\nLa liste complète des changements entre Helm 2 et 3 est documentée dans la\n[section FAQ](/faq/changes_since_helm2.md). Voici un résumé des changements\nqu'un utilisateur devrait connaître avant et pendant la migration :\n\n1. Suppression de Tiller :\n   - Remplacement de l'architecture client/serveur par une architecture\n     client/bibliothèque (binaire `helm` uniquement)\n   - La sécurité est désormais gérée par utilisateur (déléguée à la sécurité du\n     cluster Kubernetes)\n   - Les releases sont maintenant stockées en tant que secrets dans le cluster\n     et les métadonnées de l'objet release ont changé\n   - Les releases sont persistées par namespace et non plus dans le namespace\n     Tiller\n2. Mise à jour du dépôt de charts :\n   - `helm search` prend désormais en charge les recherches dans les dépôts\n     locaux ainsi que les requêtes de recherche sur Artifact Hub\n3. Passage de l'apiVersion des charts à \"v2\" pour les changements de\n   spécification suivants :\n   - Les dépendances de charts liées dynamiquement ont été déplacées vers\n     `Chart.yaml` (`requirements.yaml` supprimé et requirements --> dependencies)\n   - Les charts de type bibliothèque (helper/common charts) peuvent maintenant\n     être ajoutés comme dépendances de charts liées dynamiquement\n   - Les charts ont un champ de métadonnées `type` pour définir le chart comme\n     étant de type `application` ou `library`. Par défaut, il est de type\n     application, ce qui signifie qu'il est rendu et installable\n   - Les charts Helm 2 (apiVersion=v1) sont toujours installables\n4. Ajout de la spécification des répertoires XDG :\n   - Helm home supprimé et remplacé par la spécification des répertoires XDG\n     pour le stockage des fichiers de configuration\n   - Plus besoin d'initialiser Helm\n   - `helm init` et `helm home` supprimés\n5. Changements supplémentaires :\n   - L'installation/configuration de Helm est simplifiée :\n     - Client Helm (binaire helm) uniquement (pas de Tiller)\n     - Fonctionne immédiatement\n   - Les dépôts `local` ou `stable` ne sont plus configurés par défaut\n   - Le hook `crd-install` est supprimé et remplacé par le répertoire `crds`\n     dans le chart où tous les CRDs définis seront installés avant le rendu du\n     chart\n   - La valeur d'annotation de hook `test-failure` est supprimée, et\n     `test-success` est dépréciée. Utilisez `test` à la place\n   - Commandes supprimées/remplacées/ajoutées :\n       - delete --> uninstall : supprime tout l'historique des releases par\n         défaut (auparavant nécessitait `--purge`)\n       - fetch --> pull\n       - home (supprimé)\n       - init (supprimé)\n       - install : nécessite un nom de release ou l'argument `--generate-name`\n       - inspect --> show\n       - reset (supprimé)\n       - serve (supprimé)\n       - template : l'argument `-x`/`--execute` renommé en `-s`/`--show-only`\n       - upgrade : ajout de l'argument `--history-max` qui limite le nombre\n         maximum de révisions sauvegardées par release (0 pour aucune limite)\n   - La bibliothèque Go de Helm 3 a subi de nombreux changements et est\n     incompatible avec la bibliothèque Helm 2\n   - Les binaires de release sont maintenant hébergés sur `get.helm.sh`\n\n## Cas d'utilisation de la migration\n\nLes cas d'utilisation de la migration sont les suivants :\n\n1. Helm v2 et v3 gérant le même cluster :\n   - Ce cas d'utilisation est recommandé uniquement si vous avez l'intention de\n     supprimer progressivement Helm v2 et que vous n'avez pas besoin que v3 gère\n     les releases déployées par v2. Toutes les nouvelles releases doivent être\n     déployées par v3 et les releases existantes déployées par v2 sont mises à\n     jour/supprimées uniquement par v2\n   - Helm v2 et v3 peuvent parfaitement gérer le même cluster. Les versions de\n     Helm peuvent être installées sur le même système ou sur des systèmes\n     séparés\n   - Si vous installez Helm v3 sur le même système, vous devez effectuer une\n     étape supplémentaire pour vous assurer que les deux versions du client\n     peuvent coexister jusqu'à ce que vous soyez prêt à supprimer le client\n     Helm v2. Renommez ou placez le binaire Helm v3 dans un dossier différent\n     pour éviter tout conflit\n   - Sinon, il n'y a pas de conflits entre les deux versions grâce aux\n     distinctions suivantes :\n     - Le stockage des releases (historique) de v2 et v3 est indépendant. Les\n       changements incluent la ressource Kubernetes pour le stockage et les\n       métadonnées de l'objet release contenues dans la ressource. Les releases\n       seront également sur une base de namespace par utilisateur au lieu\n       d'utiliser le namespace Tiller (par exemple, le namespace Tiller par\n       défaut de v2 est kube-system). v2 utilise \"ConfigMaps\" ou \"Secrets\" sous\n       le namespace Tiller et la propriété `TILLER`. v3 utilise \"Secrets\" dans\n       le namespace utilisateur et la propriété `helm`. Les releases sont\n       incrémentales dans v2 et v3\n     - Le seul problème pourrait survenir si des ressources Kubernetes à portée\n       de cluster (par exemple `clusterroles.rbac`) sont définies dans un chart.\n       Le déploiement v3 échouerait alors même si le namespace est unique car\n       les ressources entreraient en conflit\n     - La configuration v3 n'utilise plus `$HELM_HOME` et utilise à la place la\n       spécification des répertoires XDG. Elle est également créée à la volée\n       selon les besoins. Elle est donc indépendante de la configuration v2.\n       Ceci s'applique uniquement lorsque les deux versions sont installées sur\n       le même système\n\n2. Migration de Helm v2 vers Helm v3 :\n   - Ce cas d'utilisation s'applique lorsque vous souhaitez que Helm v3 gère les\n     releases Helm v2 existantes\n   - Il faut noter qu'un client Helm v2 :\n     - peut gérer 1 à plusieurs clusters Kubernetes\n     - peut se connecter à 1 à plusieurs instances Tiller pour un cluster\n   - Ceci implique que vous devez en tenir compte lors de la migration car les\n     releases sont déployées dans les clusters par Tiller et son namespace. Vous\n     devez donc prendre en compte la migration pour chaque cluster et chaque\n     instance Tiller gérée par l'instance du client Helm v2\n   - Le chemin de migration de données recommandé est le suivant :\n     1. Sauvegarder les données v2\n     2. Migrer la configuration Helm v2\n     3. Migrer les releases Helm v2\n     4. Lorsque vous êtes confiant que Helm v3 gère toutes les données Helm v2\n        (pour tous les clusters et instances Tiller de l'instance du client\n        Helm v2) comme prévu, procédez au nettoyage des données Helm v2\n   - Le processus de migration est automatisé par le plugin Helm v3\n     [2to3](https://github.com/helm/helm-2to3)\n\n## Références\n\n   - Plugin Helm v3 [2to3](https://github.com/helm/helm-2to3)\n   - [Article de blog](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)\n     expliquant l'utilisation du plugin `2to3` avec des exemples\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Politique de Prise en Charge des Versions Helm\"\ndescription: \"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.\"\n---\n\nCe document décrit le décalage de version maximal pris en charge entre Helm et\nKubernetes.\n\n## Versions Prises en Charge\n\nLes versions de Helm sont exprimées sous la forme `x.y.z`, où `x` est la version\nmajeure, `y` est la version mineure et `z` est la version de correctif, suivant\nla terminologie du [Versionnement Sémantique](https://semver.org/spec/v2.0.0.html).\n\nLe projet Helm maintient une branche de release pour la version mineure la plus\nrécente. Les correctifs applicables, y compris les correctifs de sécurité, sont\nintégrés à la branche de release, en fonction de la gravité et de la faisabilité.\nPlus de détails sont disponibles dans la [politique de publication de Helm](/community/release_policy).\n\n## Décalage de Version Pris en Charge\n\nLorsqu'une nouvelle version de Helm est publiée, elle est compilée pour une\nversion mineure particulière de Kubernetes. Par exemple, Helm 3.0.0 interagit\navec Kubernetes en utilisant le client Kubernetes 1.16.2, et est donc compatible\navec Kubernetes 1.16.\n\nÀ partir de Helm 3, Helm est considéré comme compatible avec les versions `n-3`\nde Kubernetes pour lesquelles il a été compilé. En raison des changements\napportés par Kubernetes entre les versions mineures, la politique de prise en\ncharge de Helm 2 est légèrement plus stricte, prenant en charge les versions\n`n-1` de Kubernetes.\n\nPar exemple, si vous utilisez une version de Helm 3 compilée avec les API du\nclient Kubernetes 1.17, vous pouvez l'utiliser en toute sécurité avec Kubernetes\n1.17, 1.16, 1.15 et 1.14. Si vous utilisez une version de Helm 2 compilée avec\nles API du client Kubernetes 1.16, vous pouvez l'utiliser en toute sécurité avec\nKubernetes 1.16 et 1.15.\n\nIl n'est pas recommandé d'utiliser Helm avec une version de Kubernetes plus\nrécente que celle pour laquelle il a été compilé, car Helm ne garantit pas la\ncompatibilité ascendante.\n\nSi vous choisissez d'utiliser Helm avec une version de Kubernetes non prise en\ncharge, vous le faites à vos propres risques.\n\nVeuillez consulter le tableau ci-dessous pour déterminer quelle version de Helm\nest compatible avec votre cluster.\n\n| Version Helm | Versions Kubernetes Prises en Charge |\n|--------------|--------------------------------------|\n| 3.20.x       | 1.35.x - 1.32.x                      |\n| 3.19.x       | 1.34.x - 1.31.x                      |\n| 3.18.x       | 1.33.x - 1.30.x                      |\n| 3.17.x       | 1.32.x - 1.29.x                      |\n| 3.16.x       | 1.31.x - 1.28.x                      |\n| 3.15.x       | 1.30.x - 1.27.x                      |\n| 3.14.x       | 1.29.x - 1.26.x                      |\n| 3.13.x       | 1.28.x - 1.25.x                      |\n| 3.12.x       | 1.27.x - 1.24.x                      |\n| 3.11.x       | 1.26.x - 1.23.x                      |\n| 3.10.x       | 1.25.x - 1.22.x                      |\n| 3.9.x        | 1.24.x - 1.21.x                      |\n| 3.8.x        | 1.23.x - 1.20.x                      |\n| 3.7.x        | 1.22.x - 1.19.x                      |\n| 3.6.x        | 1.21.x - 1.18.x                      |\n| 3.5.x        | 1.20.x - 1.17.x                      |\n| 3.4.x        | 1.19.x - 1.16.x                      |\n| 3.3.x        | 1.18.x - 1.15.x                      |\n| 3.2.x        | 1.18.x - 1.15.x                      |\n| 3.1.x        | 1.17.x - 1.14.x                      |\n| 3.0.x        | 1.16.x - 1.13.x                      |\n| 2.16.x       | 1.16.x - 1.15.x                      |\n| 2.15.x       | 1.15.x - 1.14.x                      |\n| 2.14.x       | 1.14.x - 1.13.x                      |\n| 2.13.x       | 1.13.x - 1.12.x                      |\n| 2.12.x       | 1.12.x - 1.11.x                      |\n| 2.11.x       | 1.11.x - 1.10.x                      |\n| 2.10.x       | 1.10.x - 1.9.x                       |\n| 2.9.x        | 1.10.x - 1.9.x                       |\n| 2.8.x        | 1.9.x - 1.8.x                        |\n| 2.7.x        | 1.8.x - 1.7.x                        |\n| 2.6.x        | 1.7.x - 1.6.x                        |\n| 2.5.x        | 1.6.x - 1.5.x                        |\n| 2.4.x        | 1.6.x - 1.5.x                        |\n| 2.3.x        | 1.5.x - 1.4.x                        |\n| 2.2.x        | 1.5.x - 1.4.x                        |\n| 2.1.x        | 1.5.x - 1.4.x                        |\n| 2.0.x        | 1.4.x - 1.3.x                        |\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"Introduction\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"Comment faire\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"Sujets\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Meilleures Pratiques\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"Guide des Templates de Chart\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Commandes Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"Communauté\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"Questions Fréquemment Posées\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/fr/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: \"Politique de planification des releases\"\ndescription: \"Décrit la politique de planification des releases de Helm.\"\n---\n\nDans l'intérêt de ses utilisateurs, Helm définit et annonce les dates de release\nà l'avance. Ce document décrit la politique régissant la planification des\nreleases de Helm.\n\n## Calendrier des releases\n\nUn calendrier public indiquant les prochaines releases de Helm est disponible\n[ici](https://helm.sh/calendar/release).\n\n## Versionnement sémantique\n\nLes versions de Helm sont exprimées sous la forme `x.y.z`, où `x` est la version\nmajeure, `y` est la version mineure et `z` est la version de correctif, suivant\nla terminologie du [Versionnement Sémantique](https://semver.org/spec/v2.0.0.html).\n\n## Releases de correctifs\n\nLes releases de correctifs fournissent aux utilisateurs des corrections de bugs\net des correctifs de sécurité. Elles ne contiennent pas de nouvelles\nfonctionnalités.\n\nUne nouvelle release de correctif relative à la dernière version mineure/majeure\nest normalement effectuée une fois par mois, le deuxième mercredi de chaque mois.\n\nUne release de correctif pour résoudre une régression de haute priorité ou un\nproblème de sécurité peut être effectuée à tout moment si nécessaire.\n\nUne release de correctif sera annulée pour l'une des raisons suivantes :\n- s'il n'y a pas de nouveau contenu depuis la release précédente\n- si la date de la release de correctif tombe dans la semaine précédant la\n  première release candidate (RC1) d'une prochaine version mineure\n- si la date de la release de correctif tombe dans les quatre semaines suivant\n  une release mineure\n\n## Releases mineures\n\nLes releases mineures contiennent des correctifs de sécurité, des corrections de\nbugs ainsi que de nouvelles fonctionnalités. Elles sont rétrocompatibles en ce\nqui concerne l'API et l'utilisation de la CLI.\n\nPour s'aligner sur les releases de Kubernetes, une release mineure de Helm est\neffectuée tous les 4 mois (3 releases par an).\n\nDes releases mineures supplémentaires peuvent être effectuées si nécessaire,\nmais n'affecteront pas le calendrier d'une release future annoncée, sauf si\ncelle-ci est prévue dans moins de 7 jours.\n\nAu moment de la publication d'une release, la date de la prochaine release\nmineure sera annoncée et publiée sur la page principale du site web de Helm.\n\n## Releases majeures\n\nLes releases majeures contiennent des changements non rétrocompatibles. Ces\nreleases sont rares mais parfois nécessaires pour permettre à Helm de continuer\nà évoluer dans de nouvelles directions importantes.\n\nLes releases majeures peuvent être difficiles à planifier. Dans cet esprit, une\ndate de release finale ne sera choisie et annoncée qu'une fois la première\nversion bêta d'une telle release disponible.\n"
  },
  {
    "path": "i18n/fr/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Projet Helm\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"Développement\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"Communauté\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"Code source\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"Événements\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"Code de Conduite\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"Introduction\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Conseils et astuces pour Charts\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"Développer des Charts\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"Rechercher 800+ Charts\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"Guide de Contribution\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"Mainteneurs\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"Réunions Hebdomadaires\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"Communauté GitHub\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<a href=\\\"https://www.cncf.io/\\\">Nous sommes un projet diplômé de la Cloud Native Computing Foundation.</a><br/>© Auteurs de Helm 2025. Documentation distribuée sous <a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0.</a><br/>© 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 <a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">page d'utilisation des marques</a>.\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Logo CNCF\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/fr/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Logo Helm\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"Documentation\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"Communauté\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/it/code.json",
    "content": "{\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"Prossima versione\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"v4.0.0\",\n    \"description\": \"Next Feature Release version\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"Calendario Rilasci\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.events\": {\n    \"message\": \"Eventi\",\n    \"description\": \"Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"Prossimi eventi\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"Eventi Passati\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"Ci si {meetLink} per mostrare e discutere strumenti e progetti. Gli incontri della comunità vengono registrati e {youtubeLink}.\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"incontra ogni settimana\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"condivisi su YouTube\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"Developer Standups\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"Giovedì dalle 9:30 alle 10:00 (ora del Pacifico)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"Questi incontri sono aperti a tutti. Controlla {communityRepoLink} per note e dettagli.\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"community repo\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"{slackLink} per entrare nel team Kubernetes Slack.\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"Richiedi accesso qui\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Discussione sull'uso di Helm, sul lavoro con i charts e sulla risoluzione degli errori più comuni.\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Argomenti relativi allo sviluppo di Helm, PR in corso, rilasci, ecc.\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Discussione per utenti e collaboratori di Helm Charts.\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"Contribuire\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"Helm accoglie sempre con favore nuovi contributi al progetto!\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"Da dove iniziare?\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Helm è un progetto di grandi dimensioni con molti utenti e collaboratori. Può essere difficile da comprendere appieno!\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"Abbiamo un elenco di {goodFirstIssuesLink} se desideri dare una mano ma non sai da dove iniziare.\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"good first issues\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"Cosa devo fare?\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"Prima di contribuire con del codice, leggi la nostra {contributionGuideLink}. Descrive le procedure relative alla creazione e alla revisione delle richieste pull.\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"Guida al contributo\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"Dopo aver scritto del codice, ti preghiamo di {signYourCommitsLink} per garantire che Helm rispetti l'accordo {dcoLink} utilizzato da {cncfLink}.\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"firmare il tuo commit\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"Entra nella Community\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Maggiori informazioni sul progetto Helm e su come contribuire.\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"Gestire la complessità\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"message\": \"I chart descrivono anche le app più complesse, consentono un'installazione ripetibile delle applicazioni e fungono da unico punto di riferimento autorevole.\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"Aggiornamenti facili\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"Elimina il fastidio degli aggiornamenti con aggiornamenti in loco e hook personalizzati.\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"Condivisione semplice\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"I chart sono facili da versionare, condividere e ospitare su server pubblici o privati.\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"Rollbacks\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"Utilizza {helmRollback} per ripristinare facilmente una versione precedente di una release.\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"Features\",\n    \"description\": \"Features section title\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"Per iniziare\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"Ottieni Helm\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"Installa Helm con un gestore di pacchetti o {downloadLink}.\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"scarica un binario\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"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}.\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"docs\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"installazione\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"istruzioni d'utilizzo\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"Ottieni Charts\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"Visita {artifactHubLink} per esplorare {helmChartsLink} da numerosi repository pubblici.\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"Helm charts\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.about.whatIsHelm\": {\n    \"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.\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"message\": \"I chart sono facili da creare, aggiornare, condividere e pubblicare: inizia a usare Helm e smetti di copiare e incollare.\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Helm è un graduated project del {cncfLink} ed è mantenuto dalla {helmCommunityLink}.\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"community Helm\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"Per saperne di più:\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Architettura di Helm\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"Guida rapida\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"Video: Introduzione a Helm\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"Che cos'è Helm?\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"Il package manager per Kubernetes\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Helm è il modo migliore per trovare, condividere e utilizzare software creato per\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"home.support.title\": {\n    \"message\": \"Supporters\",\n    \"description\": \"Community support section title\"\n  },\n  \"home.support.subtitle\": {\n    \"message\": \"Helm è supportato e sviluppato da una comunità di oltre 400 sviluppatori.\",\n    \"description\": \"Community support section subtitle\"\n  },\n  \"home.support.maintainers\": {\n    \"message\": \"...e {maintainersLink}.\",\n    \"description\": \"Link to core maintainers\"\n  },\n  \"home.support.maintainersLink\": {\n    \"message\": \"molti altri meravigliosi manutentori del core di Helm\",\n    \"description\": \"Core maintainers link text\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"Pagina principale\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.blog.list.pageTitle\": {\n    \"message\": \"Blog\",\n    \"description\": \"The word \\\"Blog\\\" in breadcrumbs\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"Breadcrumbs\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"Navigazione dei post recenti del blog\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"Su questa pagina\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"Questa pagina è andata in crash.\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"Torna indietro all'inizio\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"Archivio\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"Archivio\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"Navigazione nella pagina dei post del blog \",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"Post più recenti\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"Post più vecchi\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"Navigazione nella pagina dei post del blog \",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"Post più recente\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"Post più vecchio\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"Guarda tutte le etichette\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"system mode\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"Modalità chiara\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"Modalità scura\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"Passa dalla modalità scura a quella chiara (currently {mode})\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"1 elemento|{count} elementi\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"Pagina del documento\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"Precedente\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"Successivo\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"Un documento etichettato|{count} documenti etichettati\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged} con \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"Versione: {versionLabel}\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"Questa è documentazione inedita per {siteTitle} versione {versionLabel}.\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"Questa è la documentazione per {siteTitle} {versionLabel}, che non è più attivamente mantenuta.\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"Per la documentazione aggiornata, guarda la {latestVersionLink} ({versionLabel}).\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"ultima versione\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"Modifica questa pagina\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"Link diretto a {heading}\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \" il {date}\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \" da {user}\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"Ultimo aggiornamento{atDate}{byUser}\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"Versioni\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"Pagina non trovata\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"Etichette:\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"Chiudi\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"attenzione\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"pericolo\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"informazioni\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"note\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"suggerimento\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"warning\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"Expand sidebar category '{label}'\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"Collapse sidebar category '{label}'\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(apri in un nuovo tab)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"Principale\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"Non siamo riusciti a trovare quello che stavi cercando.\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"message\": \"Contatta il proprietario del sito che ti ha collegato all'URL originale e fagli sapere che il loro collegamento è interrotto.\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"Linguaggio\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"Lettura di 1 minuto|{readingTime} minuti di lettura\",\n    \"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)\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"Leggi di più\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"Leggi di più su {title}\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"Attiva/disattiva a capo automatico\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"Copia\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"Copiato\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"Copia il codice negli appunti\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"Collassa la barra laterale\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"Collassa la barra laterale\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"Barra laterale dei documenti\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"Chiudi la barra di navigazione\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"Attiva/disattiva la barra di navigazione\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← Indietro al menu principale\",\n    \"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)\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"Apri il menù a tendina\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"Chiudi il menù a tendina\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"Espandi la barra laterale\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"Espandi la barra laterale\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"Un post|{count} post\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"{nPosts} etichettati con \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"Authori\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"Vedi Tutti gli Authori\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"Questo autore non ha ancora scritto alcun post.\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"Pagina non in elenco\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"message\": \"Questa pagina non è in elenco. I motori di ricerca non lo indicheranno e solo gli utenti con collegamento diretto possono accedervi.\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"Pagina in bozza\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"Questa pagina è una bozza. Sarà visibile solo in dev e sarà esclusa dalla build di produzione.\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"Prova di nuovo\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"Passa al contenuto principale\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"Etichette\",\n    \"description\": \"The title of the tag list page\"\n  }\n}\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Blog\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"Blog\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"Tutti i post\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  }\n}\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Usa Helm\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Comandi Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"Sviluppa Templates\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Best Practices\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"Inizio della documentazione\"\ndescription: “Tutto quello che c'è da sapere su come è organizzata questa documentazione.”\nsidebar_position: 1\n---\n\n# Benvenuto\n\nBenvenuto nella documentazione di [Helm](https://helm.sh/). Helm è un gestore di\npacchetti per Kubernetes. Per ulteriori informazioni sul contesto dettagliato, consulta il\n[rapporto sul percorso del progetto Helm\nalla CNCF](https://www.cncf.io/cncf-helm-project-journey/).\n\n# Come è organizzata questa documentazione?\n\nHelm ha una vasta documentazione. Una panoramica di alto livello su come è organizzata\nti aiuterà a capire dove cercare determinate informazioni:\n\n- I [tutorial](/intro/index.mdx) ti guidano passo dopo passo nella creazione del\n  tuo primo Chart in Helm. Inizia da qui se sei nuovo in Helm.\n- [Guide tematiche](/topics/index.mdx) trattano gli argomenti e i concetti principali ad alto livello,\n  oltre a fornire contesto e spiegazioni utili su Helm.\n- [Guide pratiche](/howto/index.mdx) sono ricette pronte all'uso. Ti guidano attraverso i passaggi\n  necessari per risolvere i principali problemi e casi d'uso. Sono più avanzate\n  dei tutorial e richiedono una conoscenza preliminare del funzionamento di Helm.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: \"Tecniche Avanzate di Helm\"\ndescription: \"Spiega varie funzioni avanzate per i power user di Helm\"\nweight: 9\n---\n\nQuesta sezione illustra varie funzioni e tecniche avanzate di utilizzo di Helm.\nLe informazioni contenute in questa sezione sono destinate ai \"power user\" di Helm che desiderano\npersonalizzare e manipolare in modo avanzato i charts e le release. Ognuna di queste funzioni avanzate comporta dei compromessi e degli avvertimenti, per cui\nognuna di esse deve essere utilizzata con attenzione e con una conoscenza approfondita di Helm. O in altre parole,\nricordate il [principio di Peter Parker](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)\n\n## Post Rendering\nIl post rendering offre agli installatori di Charts la possibilità di manipolare manualmente,\nconfigurare e/o convalidare i manifesti renderizzati prima che vengano installati da Helm.\nQuesto 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\nper 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.\n\n### Prerequisiti\n- Helm 3.1+\n\n### Utilizzo\nUn post-renderer può essere un qualsiasi eseguibile che accetta manifest Kubernetes renderizzati\nsu STDIN e restituisce manifest Kubernetes validi su STDOUT. Dovrebbe restituire\nun codice di uscita non-0 in caso di fallimento. Questa è l'unica \"API\" tra i\ndue componenti. Permette una grande flessibilità in ciò che si può fare con il processo di\npost-rendering.\n\nUn post renderer può essere usato con `install`, `upgrade` e `template`. Per usare un\npost-renderer, usare il flag `--post-renderer` con il percorso del renderer\nche si desidera utilizzare:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nSe il percorso non contiene separatori, la ricerca verrà effettuata in $PATH, altrimenti\nrisolverà qualsiasi percorso relativo in un percorso completamente qualificato.\n\nSe si desidera utilizzare più post-renderizzatori, richiamateli tutti in uno script o\ninsieme in un qualsiasi strumento binario con cui è stato implementato. In bash, questo potrebbe essere\nsemplice come `renderer1 | renderer2 | renderer3`.\n\nSi può vedere un esempio di utilizzo di `kustomize` come renderizzatore di post\n[qui](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n### Avvertenze\nQuando si usano i postrenderer, ci sono diverse cose importanti da tenere a mente.\nLa più importante è che quando si usa un post renderer, tutte le persone che modificano quella release **DOVREBBERO** usare lo stesso renderizzatore per poter essere\nripetibili. Questa caratteristica è stata costruita appositamente per consentire a qualsiasi utente di\ncambiare il renderer che sta utilizzando o di smettere di usare un renderer, ma questo\ndovrebbe essere fatto deliberatamente per evitare modifiche accidentali o perdite di dati.\n\nUn'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\n). L'uso di renderizzatori non affidabili o non verificati NON è raccomandato, in quanto hanno pieno accesso ai modelli renderizzati, che spesso contengono dati\ndati segreti.\n\n### Post renderer personalizzati\nLa 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:\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nPer ulteriori informazioni sull'uso di Go SDK, vedere la sezione [Go SDK](#go-sdk).\n\n## Go SDK\nHelm 3 ha presentato un SDK per Go completamente ristrutturato per una migliore esperienza nella\ndi creazione di software e strumenti che sfruttano Helm. La documentazione completa è disponibile\nall'indirizzo [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3), ma\nuna breve panoramica di alcuni dei pacchetti più comuni e di un semplice esempio qui di seguito.\n\n## Storage backends\n\nHelm 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\nConfigMaps nel namespace dell'istanza di Tiller. Le sottosezioni che seguono\nmostrano come configurare i diversi backend. Questa configurazione si basa sulla \nvariabile d'ambiente `HELM_DRIVER`. Può essere impostata su uno dei valori:\n`[configmap, secret, sql]`.\n\n###  Storage backend ConfigMap\n\nPer abilitare il backend ConfigMap, è necessario impostare la variabile d'ambiente\n`HELM_DRIVER` a `configmap`.\n\nSi può impostare in una shell come segue:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nSe si vuole passare dal backend predefinito a quello ConfigMap, si \ndovrà fare la migrazione autonomamente. È possibile recuperare le informazioni sulla release\ncon il seguente comando:\n\n```shell\nkubectl get secret --all-namespaces -l “owner=helm”\n```\n\n**NOTE DI PRODUZIONE**: Le informazioni sulla release includono il contenuto dei chart e dei values file, e quindi potrebbero contenere dati sensibili (come\npassword, chiavi private e altre credenziali) che devono essere protetti dall'accesso non autorizzato. Quando si gestisce l'autorizzazione di Kubernetes, ad esempio con\n[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), è possibile\nconcedere un accesso più ampio alle risorse ConfigMap, mentre si limita l'accesso alle risorse Secret. \nAd esempio, il ruolo predefinito [user-facing\nutente](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\n“view” garantisce l'accesso alla maggior parte delle risorse, ma non ai Secret. Inoltre, i dati dei Secret\npossono essere configurati per [archiviazione criptata](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).\nSi tenga presente questo aspetto se si decide di passare al backend ConfigMap, perché potrebbe esporre i dati sensibili dell'applicazione.\n\n### Storage backend SQL\n\nEsiste uno storage backend SQL ***beta*** che memorizza le informazioni di rilascio in un database SQL.\n\nL'uso di uno storage backend di questo tipo è particolarmente utile se le informazioni sulla release\npesano più di 1 MB (nel qual caso non possono essere memorizzate in ConfigMaps/Secrets).\na causa dei limiti nello storage key-values di etcd in Kubernetes).\n\nPer 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`.\n\nÈ possibile impostarla in una shell come segue:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Nota: al momento è supportato solo PostgreSQL.\n\n**NOTE DI PRODUZIONE**: Si raccomanda di:\n- Preparare il database alla produzione. Per PostgreSQL, consultare i documenti di [Server Administration](https://www.postgresql.org/docs/12/admin.html) per maggiori dettagli.\n- Abilitare la [gestione dei permessi](/topics/permissions_sql_storage_backend.md) per\nrispecchiare le RBAC di Kubernetes per le informazioni della release\n\nSe si vuole passare dal backend predefinito al backend SQL, si dovrà\nfare la migrazione in autonomia. È possibile recuperare le informazioni sulla release\ncon il seguente comando:\n\n```shell\nkubectl get secret --all-namespaces -l “owner=helm”\n```"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: \"Architettura di Helm\"\ndescription: \"Descrive l'architettura di Helm ad alto livello.\"\nweight: 8\n---\n\n# Architettura di Helm\n\nQuesto documento descrive l'architettura di Helm ad alto livello.\n\n## Lo scopo di Helm\n\nHelm è uno strumento per la gestione dei pacchetti Kubernetes chiamati _charts_. Helm può fare quanto segue:\n\n- Creare nuovi chart da zero\n- Pacchettizzare i chart in file archivi (tgz)\n- Interagire con i repository dei chart, dove questi sono memorizzati\n- installare e disinstallare chart in un cluster Kubernetes esistente\n- Gestire il ciclo di rilascio dei chart installati con Helm.\n\nPer Helm, ci sono tre concetti importanti:\n\n1. Il _chart_ è un insieme di informazioni necessarie per creare un'istanza di un'applicazione Kubernetes.\n2. Il _config_ contiene informazioni di configurazione che possono essere unite in un chart impacchettato per creare un oggetto rilasciabile.\n3. Una _release_ è un'istanza in esecuzione di un _chart_, combinato con una specifica\n   _config_.\n\n## Componenti\n\nHelm è un eseguibile implementato in due parti distinte:\n\nIl **Client Helm** è un client a riga di comando per gli utenti finali. Il client è\nresponsabile di quanto segue:\n\n- Sviluppo del chart locale\n- Gestione dei repository\n- Gestione dei rilasci\n- Interfacciamento con la libreria Helm\n  - Invio di chart da installare\n  - Richiedere l'aggiornamento o la disinstallazione di release esistenti.\n\nLa **Libreria Helm** fornisce la logica per l'esecuzione di tutte le operazioni di Helm. Si\nsi interfaccia con il server API di Kubernetes e fornisce le seguenti funzionalità:\n\n- Combinazione di un chart e di una configurazione per costruire un rilascio.\n- Installazione dei chart in Kubernetes e fornitura del successivo oggetto di rilascio.\n- Aggiornamento e disinstallazione dei chart interagendo con Kubernetes.\n\nLa libreria Helm standalone incapsula la logica Helm in modo che possa essere sfruttata da diversi client.\n\n## Implementazione\n\nIl client e la libreria Helm sono scritti nel linguaggio di programmazione Go.\n\nLa libreria utilizza il client Kubernetes per comunicare con Kubernetes.\nAttualmente, questa libreria utilizza REST+JSON. Memorizza le informazioni in Secrets situati all'interno di Kubernetes. Non ha bisogno di un proprio database.\n\nI file di configurazione sono, quando possibile, scritti in YAML."
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: \"Guida ai Chart Repository\"\ndescription: \"Come creare e lavorare coi repository per Helm chart.\"\nweight: 6\n---\n\nQuesta sezione spiega come creare e lavorare con i repository dei chart Helm. Ad alto livello\nun repository di chart è una posizione in cui i chart confezionati possono essere archiviati e condivisi.\n\nIl repository distribuito della comunità di Helm si trova all'indirizzo\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) e accoglie con favore la\npartecipazione. Ma Helm permette anche di creare e gestire un proprio repository di chart. Questa guida spiega come farlo.\n\n## Prerequisiti\n\n* Leggere la guida [Quickstart](/intro/quickstart.md)\n* Leggere il documento [Charts](/topics/charts.md)\n\n## Creare un chart repository\n\nUn _chart repository_ è un server HTTP che ospita un file `index.yaml` e\nopzionalmente alcuni chart confezionati.  Quando si è pronti a condividere i propri chart, il modo\n modo preferibile è caricarli in un archivio di grafici.\n\nA partire da Helm 2.2.0, è supportata l'autenticazione SSL lato client a un repository. Altri\nprotocolli di autenticazione possono essere disponibili come plugin.\n\nPoiché un chart repository può essere un qualsiasi server HTTP in grado di servire file YAML e tar\ne può rispondere a richieste GET, si ha una pletora di opzioni quando si tratta di ospitare il proprio chart repository.\nAd esempio, è possibile utilizzare un bucket di Google\nCloud Storage (GCS), Amazon S3, GitHub Pages o addirittura creare il proprio server web.\n\n### La struttura del chart repository\n\nUn 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.\nSpesso, 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ì:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nIn 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.\n\nNon è necessario che un pacchetto di chart si trovi sullo stesso server del file`index.yaml`. Tuttavia, spesso è la soluzione più semplice.\n\n### Il file indice\n\nIl file indice è un file yaml chiamato `index.yaml`. Contiene alcuni metadati\ndel pacchetto, compreso il contenuto del file `Chart.yaml` di un chart. A\nchart repository valido deve avere un file di indice. Il file indice contiene\ninformazioni su ogni chart presente nel repository. Il comando `helm repo index`\ngenera un file di indice basato su una determinata directory locale che\ncontenente i chart pacchettizzati.\n\nQuesto è un esempio di file di indice:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Ospitare i Chart Repositories\n\nQuesta parte mostra diversi modi per servire un chart repository..\n\n### Google Cloud Storage\n\nIl primo passo è quello di **creare il proprio bucket GCS**. Chiameremo il nostro\n`fantastic-charts`.\n\n![Creare un bucket GCS](https://helm.sh/img/create-a-bucket.png)\n\nQuindi, rendete il vostro bucket pubblico **modificando i permessi del bucket**.\n\n![Modifica permessi](https://helm.sh/img/edit-permissions.png)\n\nInserire questa voce per **rendere pubblico il bucket**:\n\n![Rendi pubblico il bucket](https://helm.sh/img/make-bucket-public.png)\n\nCongratulazioni, ora avete un bucket GCS vuoto pronto per servire i chart!\n\nÈ possibile caricare il chart repository utilizzando lo strumento a riga di comando Google Cloud Storage\no utilizzando l'interfaccia web di GCS. È possibile accedere a un bucket GCS pubblico tramite\nsemplice HTTPS a questo indirizzo: `https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith\n\nÈ anche possibile impostare chart repositories utilizzando Cloudsmith. Per saperne di più\nchart repositories con Cloudsmith\n[qui](https://help.cloudsmith.io/docs/helm-chart-repository)\n\n### JFrog Artifactory\n\nAllo stesso modo, è possibile impostare chart repositories utilizzando JFrog Artifactory. Per saperne di più\nsu chart repositories con JFrog Artifactory\n[qui](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repository)\n\n### Esempio con GitHub Pages\n\nIn modo simile è possibile creare charts repository utilizzando GitHub Pages.\n\nGitHub consente di servire pagine web statiche in due modi diversi:\n\n- Configurando un progetto per servire il contenuto della sua cartella `docs/`.\n- Configurando un progetto per servire un particolare branch.\n\nNoi adotteremo il secondo approccio, anche se il primo è altrettanto semplice.\n\nIl primo passo sarà quello di **creare il branch gh-pages**.  È possibile farlo\nlocalmente come.\n\n```console\n$ git checkout -b gh-pages\n```\n\nOppure tramite browser web usando il pulsante **Branch** sul repository GitHub:\n\n![Crea branch GitHub Pages](https://helm.sh/img/create-a-gh-page-button.png)\n\nSuccessivamente, ci si deve assicurare che il branch **gh-pages** sia impostato come GitHub Pages,\ncliccare sulle **Impostazioni** del proprio repository e scorrere fino alla sezione **Pagine GitHub** e\ne impostare come indicato di seguito:\n\n![Crea branch GitHub Pages](https://helm.sh/img/set-a-gh-page.png)\n\nPer impostazione predefinita, **Source** viene solitamente impostato su **gh-pages branch**. Se questo non è\nimpostato per impostazione predefinita, selezionarlo.\n\nÈ possibile utilizzare un **dominio personalizzato** se lo si desidera.\n\nVerificare che **Enforce HTTPS** sia spuntato, in modo che **HTTPS** venga utilizzato quando vengono serviti i chart.\n\nIn 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:\n`https://USERNAME.github.io/REPONAME`. La dimostrazione [TS\nCharts](https://github.com/technosophos/tscharts) è accessibile all'indirizzo\n`https://technosophos.github.io/tscharts/`.\n\nSe hai deciso di utilizzare le GitHub pages per ospitare il repository dei chart, consulta\n[Chart Releaser Action](/howto/chart_releaser_action.md).\nChart Releaser Action è un flusso di lavoro GitHub Action che consente di trasformare un progetto GitHub in\nun repository Helm chart self-hosted, utilizzando lo strumento CLI\n[helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n### Ordinary web servers\n\nTo configure an ordinary web server to serve Helm charts, you merely need to do\nthe following:\n\n- Put your index and charts in a directory that the server can serve\n- Make sure the `index.yaml` file can be accessed with no authentication\n  requirement\n- Make sure `yaml` files are served with the correct content type (`text/yaml`\n  or `text/x-yaml`)\n\nPer 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\nall'interno di quella cartella.\n\n### ChartMuseum Repository Server\n\nChartMuseum è un server di repository Helm Chart open-source scritto in Go\n(Golang), con supporto per backend di cloud storage, tra cui [Google Cloud\nStorage](https://cloud.google.com/storage/), [Amazon\nS3](https://aws.amazon.com/s3/), [Microsoft Azure Blob\nMicrosoft Azure](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba\nCloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object\nStorage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud\nOracle Cloud](https://cloud.oracle.com/storage), [Baidu Cloud\nBOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object\nTencent](https://intl.cloud.tencent.com/product/cos), [DigitalOcean\nSpaces](https://www.digitalocean.com/products/spaces/),\n[Minio](https://min.io/) e [etcd](https://etcd.io/).\n\nÈ inoltre possibile utilizzare il servizio\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\nper ospitare un archivio di chart da un file system locale.\n\n### Registro dei pacchetti GitLab\n\nCon GitLab è possibile pubblicare i chart Helm nel Package Registry del progetto.\nPer saperne di più sull'impostazione di un helm package repository con GitLab [qui](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Gestione dei repository dei grafici\n\nOra che si dispone di un chart repository, l'ultima parte di questa guida spiega come\ncome gestire i chart in quel repository.\n\n\n### Memorizzare i chart nel chart repository\n\nOra che si dispone di un chart repository, carichiamo un chart e un file di indice nel repository.\nI chart in un chart repository devono essere impacchettati (`helm package\nnome-della-cartella/`) e correttamente versionati (seguendo le linee guida di [SemVer 2](https://semver.org/)).\n\nI passi successivi compongono un flusso di lavoro di esempio, ma si può usare\nqualsiasi flusso di lavoro per memorizzare e aggiornare i chart nel proprio repository.\n\nUna volta pronto un chart pacchettizzato, creare una nuova directory e spostare il chart pacchettizzato in quella directory.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nL'ultimo comando prende il percorso della cartella locale appena creata e l'URL del repository grafico remoto.\nl'URL del chart repository remoto e compone un file `index.yaml` all'interno della cartella indicata.\n\nOra è possibile caricare il chart e il file di indice nel chart repository, utilizzando uno strumento di sincronizzazione o manualmente.\nSe 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.\n\n### Aggiungere nuovi chart a un repository esistente\n\nOgni volta che si desidera aggiungere un nuovo chart al repository, è necessario rigenerare l'indice.\n\nIl comando `helm repo index` ricostruisce completamente il file\n`index.yaml` da zero, includendo solo i chart trovati localmente.\n\nTuttavia, è possibile utilizzare il flag `--merge` per aggiungere in modo incrementale nuovi chart a un file `index.yaml\n esistente (un'ottima opzione quando si lavora con un repository remoto come GCS).\n Eseguire `helm repo index --help` per saperne di più,\n\nAssicurarsi di caricare sia il file `index.yaml` rivisto che il chart. E\nse si è generato un file di provenienza, caricare anche quello.\n\n### Condividere i chart con altri\n\nQuando si è pronti a condividere i chart, è sufficiente comunicare a qualcuno l'URL del vostro repository.\n\nDa lì, aggiungeranno il repository al loro client helm tramite il comando `helm repo\nadd [NAME] [URL]` con il nome che si desidera utilizzare per fare riferimento al repository.\n\n ``console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts https://fantastic-charts.storage.googleapis.com\n```\n\nSe i chart sono supportati dall'autenticazione di base HTTP, si possono fornire anche il nome utente e la password:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts https://fantastic-charts.storage.googleapis.com\n```\n\n**Nota:** Un repository non verrà aggiunto se non contiene un valido file\n`index.yaml`.\n\n**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.\n\nDopodiché, i vostri utenti saranno in grado di cercare nei vostri chart. Dopo aver\naggiornato il repository, possono usare il comando `helm repo update` per ottenere le ultime\ninformazioni più recenti sui chart.\n\n*Sotto il cofano, i comandi `helm repo add` e `helm repo update` \nrecuperano il file index.yaml e lo memorizzano nella cartella\n`$XDG_CACHE_HOME/helm/repository/cache/`. È qui che la funzione `helm\nsearch` trova le informazioni sui chart.\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: \"Testare i Chart\"\ndescription: \"Descrive come eseguire e testare i chart.\"\nweight: 3\n---\n\nUn 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.\n\nUn **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\ndeve 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`.\n\nSi 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`.\n`helm.sh/hook: test-success` è ancora accettato come alternativa retro-compatibile a `helm.sh/hook: test`.\n\nTest di esempio:\n\n- Validare che la configurazione del file values.yaml sia stata iniettata correttamente.\n  - Verificare che il nome utente e la password funzionino correttamente\n  - Assicurarsi che un nome utente e una password non corretti non funzionino.\n- Verificare che i servizi siano attivi e che il bilanciamento del carico sia corretto\n- ecc.\n\nÈ possibile eseguire i test predefiniti in Helm su una release utilizzando il comando `helm\ntest <NOME_RELEASE>`. 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.\n\n## Esempio di test\n\nIl 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. \n\n```console\n$ helm create demo\n```\n\nOra sarà possibile vedere la seguente struttura nel chart demo.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nIn `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:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Passi per eseguire una suite di test su una release\n\nPer prima cosa, installare il chart sul cluster per creare una release. Potrebbe essere necessario\nattendere 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.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Note\n\n- È possibile definire tutti i test che si desidera in un singolo file yaml o distribuirli in diversi file yaml nella cartella `templates/`.\n- È possibile annidare la propria suite di test sotto una cartella `tests/`, come ad esempio   `<nome-cartella>/templates/tests/` per un maggiore isolamento.\n- 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.\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: \"Charts\"\ndescription: \"Spiega il formato dei chart e fornisce indicazioni di base per la creazione di chart con Helm.\"\nweight: 1\n---\n\nHelm utilizza un formato di packaging chiamato _charts_. Un chart è un insieme di file\nche 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,\ncome uno stack completo di app web con server HTTP, database, cache e così via.\n\nI chart vengono creati come file disposti in un particolare albero di directory. Possono essere\nin archivi versionati per essere distribuiti.\n\nSe si desidera scaricare e consultare i file di un chart pubblicato, senza installarlo, è possibile farlo con `helm pull chartrepo/nome del chart`.\n\nQuesto documento spiega il formato del chart e fornisce una guida di base per\ncostruire chart con Helm.\n\n## La struttura dei file del chart\n\nUn chart è organizzato come una raccolta di file all'interno di una directory. Il nome della directory\nè il nome del chart (senza informazioni sulla versione). Quindi,\nun chart che descrive WordPress verrebbe memorizzato in una directory `wordpress/`.\n\nAll'interno di questa directory, Helm si aspetta una struttura che corrisponde a questa:\n\n```text\nwordpress/\n  Chart.yaml          # Un file YAML contenente informazioni sul chart\n  LICENSE             # OPZIONALE: un file di testo semplice contenente la licenza per il chart.\n  README.md           # OPZIONALE: un file README human-readable\n  values.yaml         # I valori di configurazione predefiniti per questo chart\n  values.schema.json  # OPZIONALE: Uno schema JSON per imporre una struttura al file values.yaml\n  charts/             # Una directory contenente i chart da cui dipende questo chart.\n  crds/               # Custom Resource Definitions\n  templates/          # Una directory di template che, se combinati con i values,\n                      # genereranno file manifest Kubernetes validi.\n  templates/NOTES.txt # OPZIONALE: un file di testo semplice contenente brevi note d'uso.\n```\n\nHelm si riserva l'uso delle directory `charts/`, `crds/` e `templates/` e dei nomi dei file elencati.\nGli altri file saranno lasciati così come sono.\n\n## Il file Chart.yaml\n\nIl file `Chart.yaml` è necessario per un chart. Contiene i seguenti campi:\n\n```yaml\napiVersion: La versione dell'API del chart (obbligatorio)\nname: il nome del chart (obbligatorio)\nversion: Una versione di SemVer 2 (obbligatorio)\nkubeVersion: Un intervallo SemVer di versioni Kubernetes compatibili (opzionale)\ndescription: Una descrizione di una sola frase di questo progetto (opzionale)\ntype: Il tipo di chart (opzionale)\nkeywords:\n  - Un elenco di parole chiave relative a questo progetto (opzionale)\nhome: L'URL della pagina iniziale di questo progetto (facoltativo)\nsources:\n  - Un elenco di URL al codice sorgente di questo progetto (facoltativo)\ndependencies: # Un elenco dei requisiti del chart (opzionale)\n  - name: il nome del chart (nginx)\n    version: La versione del chart (\"1.2.3\")\n    repository: (opzionale) L'URL del repository (\"https://example.com/charts\") o l'alias (\"@repo-name\")\n    condition: (facoltativo) Un percorso yaml che si risolve in un booleano, usato per abilitare/disabilitare i chart (ad esempio, subchart1.enabled).\n    tag: # (opzionale)\n      - I tag possono essere usati per raggruppare i chart da abilitare/disabilitare insieme\n    import-values: # (opzionale)\n      - 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.\n    alias: (opzionale) Alias da usare per il chart. Utile quando si deve aggiungere lo stesso chart più volte.\nmaintainer: # (opzionale)\n  - name: il nome del maintainer (obbligatorio per ogni maintainer)\n    email: L'email del maintainer (opzionale per ogni maintainer)\n    url: Un URL per il maintainer ( opzionale per ogni maintainer)\nicon: Un URL a un'immagine SVG o PNG da usare come icona (opzionale).\nappVersion: La versione dell'applicazione che contiene (opzionale). Non è necessario che sia SemVer. Si consigliano le citazioni.\ndeprecated: Se questo chart è deprecato (opzionale, booleano).\nannotations:\n  example: Un elenco di annotazioni con chiave per nome (opzionale).\n```\n\nA partire da [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), non sono consentiti campi aggiuntivi.\nL'approccio consigliato è quello di aggiungere metadati personalizzati in `annotations`.\n\n### Chart e versioni\n\nOgni 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\ne successivi utilizza i numeri di versione come marcatori di release. I pacchetti nei repository sono\nidentificati dal nome più versione.\n\nPer esempio, un chart `nginx` il cui campo versione è impostato a `version: 1.2.3`\nsi chiamerà:\n\n```testo\nnginx-1.2.3.tgz\n```\n\nSono supportati anche nomi SemVer 2 più complessi, come `version:\n1.2.3-alpha.1+ef365`. Ma i nomi non SemVer sono esplicitamente rifiutati dal sistema.\n\n**NOTA:** Mentre Helm Classic e Deployment Manager erano entrambi molto orientati a GitHub\nquando si trattava di chart, Helm v2 e successivi non si basano su GitHub e nemmeno su Git.\nDi conseguenza, non utilizza gli SHA di Git per il versioning.\n\nIl 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`\nutilizzerà la versione trovata in `Chart.yaml` come token nel nome del pacchetto.\nIl sistema presume che il numero di versione nel nome del pacchetto del chart\ncorrisponda al numero di versione presente in `Chart.yaml`. Il mancato rispetto di questa ipotesi\ncauserà un errore.\n\n### Il campo `apiVersion`\n\nIl campo `apiVersion` dovrebbe essere `v2` per i chart Helm che richiedono almeno Helm\n3. I chart che supportano versioni precedenti di Helm hanno una `apiVersion` impostata a `v1` e sono ancora installabili con Helm 3.\n\nCambiamenti dalla `v1` alla `v2`:\n\n- 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)).\n- Il campo `type`, che discrimina i chart di applicazione da quelli di libreria (vedere [Tipi di chart](#tipi-di-chart)).\n\n### Il campo `appVersion`\n\nSi noti che il campo `appVersion` non è correlato al campo `version`. È un\nmodo di specificare la versione dell'applicazione. Per esempio, la tabella `drupal`\npuò 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.\n\nA partire da Helm v3.5.0, `helm create` avvolge il campo predefinito `appVersion` tra virgolette.\n\n### Il campo `kubeVersion` \n\nIl 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.\n\nI vincoli di versione possono comprendere confronti AND separati da spazi, come ad esempio\n\n```\n>= 1.13.0 < 1.15.0\n```\nche possono essere combinati con l'operatore OR `||` come nel seguente esempio\n\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\n\nIn questo esempio la versione `1.14.0` viene esclusa, il che può avere senso se è noto un bug\nin certe versioni che impediscono il corretto funzionamento del chart.\n\nOltre ai vincoli di versione che impiegano gli operatori `=` `!=` `>` `<` `>=` `<=`, sono supportate le seguenti notazioni stenografiche\n\n * intervalli di trattini per intervalli chiusi, dove `1.1 - 2.3.4` è equivalente a `>=\n   1.1 <= 2.3.4`.\n * caratteri jolly `x`, `X` e `*`, dove `1.2.x` equivale a `>= 1.2.0 <= 1.3.0`.\n   1.3.0`.\n * intervalli di tilde (sono consentite modifiche alla versione della patch), dove `~1.2.3` equivale a\n   `>= 1.2.3 < 1.3.0`.\n * intervalli di caret (sono ammessi cambiamenti di versione minori), dove `^1.2.3` equivale a\n   `>= 1.2.3 < 2.0.0`.\n\nPer una spiegazione dettagliata dei vincoli di semver supportati, vedere\n[Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Deprecazione dei chart\n\nQuando si gestiscono i chart in un Chart Repository, a volte è necessario deprecare un chart.\nIl campo opzionale `deprecated` in `Chart.yaml` può essere utilizzato\nper contrassegnare un chart come deprecato. Se la versione **più recente** di un chart nel repository\nè contrassegnata come deprecata, allora il chart nel suo insieme è considerato\ndeprecato. Il nome del chart può essere riutilizzato in seguito pubblicando una versione più recente\nche non sia contrassegnata come deprecata. Il flusso di lavoro per la deprecazione dei chart è il seguente:\n\n1. Aggiornare il file `Chart.yaml` del grafico per contrassegnarlo come deprecato, eliminando la versione\n2. Rilasciare la nuova versione del chart nel Chart Repository.\n3. Rimuovere il chart dal repository dei sorgenti (p.e. git)\n\n### Tipi di chart\n\nIl campo `type` definisce il tipo di chart. Esistono due tipi:`application`\ne `library`. Application è il tipo predefinito e rappresenta il chart standard\nche può essere utilizzato completamente. Il [Chart di tipo Library]({{< ref\n\"/docs/topics/library_charts.md\" >}}) fornisce utilità o funzioni per il costruttore di chart.\nUn chart library si differenzia da un chart applicativo perché non è\ninstallabile e di solito non contiene oggetti risorsa.\n\n**Nota:** Un chart di tipo application può essere usato come chart di tipo library. Questo viene abilitato impostando il tipo a `library`. \nIl chart sarà quindi reso come un chart di libreria\ndove si possono sfruttare tutte le utilità e le funzioni. Tutti gli oggetti risorsa\ndel chart non saranno renderizzati.\n\n## LICENZA, README e NOTE\n\nI chart possono contenere anche file che descrivono l'installazione, la configurazione,\ne la licenza d'uso di un chart.\n\nLa 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.\n\nUn README per un chart dovrebbe essere formattato in Markdown (README.md) e dovrebbe contenere generalmente:\n- una descrizione dell'applicazione o del servizio che il chart fornisce\n- Eventuali prerequisiti o requisiti per eseguire il chart\n- Descrizioni delle opzioni in `values.yaml` e dei valori predefiniti\n- Qualsiasi altra informazione che possa essere rilevante per l'installazione o la configurazione del chart.\n\nQuando gli hub e le altre interfacce utente visualizzano i dettagli di un chart, tali dettagli vengono\ndal contenuto del file `README.md`.\n\nIl 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.\nQuesto file viene valutato come un [template](#templates-e-values) e può essere\nusato per visualizzare le note d'uso, i passi successivi o qualsiasi altra informazione relativa a una\nun 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.\n\n## Dipendenze dei chart\n\nIn Helm, un chart può dipendere da un numero qualsiasi di altri chart. Queste dipendenze\npossono essere collegate dinamicamente utilizzando il campo `dependencies` in `Chart.yaml` o\nnella cartella `charts/` e gestite manualmente.\n\n### Gestione delle dipendenze con il campo `dipendenze\n\nI chart richiesti dal chart corrente sono definiti come un elenco nel campo\n`dipendenze`.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- Il campo `name` è il nome del chart desiderato.\n- Il campo `version` è la versione del chart desiderata.\n- Il campo `repository` è l'URL completo del repository del chart. Si noti che\n  deve essere usato anche `helm repo add` per aggiungere quel repo localmente.\n- Si può usare il nome del repo invece dell'URL\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\nUna 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\n`charts/`.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nQuando `helm dependency update` recupera i chart, li memorizza come archivi di chart nella directory `charts/`. Quindi, per l'esempio precedente, ci si aspetterebbe\ndi vedere i seguenti file nella cartella charts:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Campo Alias nelle dipendenze\n\nOltre agli altri campi sopra citati, ogni voce relativa alle dipendenze può contenere il campo opzionale`alias`.\n\nL'aggiunta di un alias per un dependency chart inserisce un chart nelle dipendenze usando\nalias come nome della nuova dipendenza.\n\nSi può usare `alias` nel caso in cui si debba accedere a un chart con altri nomi.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nNell'esempio precedente, avremo 3 dipendenze in tutto per `parentchart`:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nIl modo manuale per ottenere questo risultato è copiare/incollare lo stesso chart nella directory\n`charts/` più volte con nomi diversi.\n\n#### Tag e Condition fields nelle dipendenze\n\nOltre agli altri campi sopra citati, ogni voce di requisiti può contenere i campi opzionali\n`tags` e `condition`.\n\nTutti i campi sono caricati per impostazione predefinita. Se i campi `tags` o `condition` sono presenti,\nvengono valutati e utilizzati per controllare il caricamento dei chart a cui sono applicati.\n\nCondition - Il campo condition contiene uno o più percorsi YAML (delimitati da virgole). \nSe questo percorso esiste nei valori del genitore superiore e si risolve in un valore\nvalore booleano, il grafico verrà attivato o disattivato in base a quel valore booleano.\nViene valutato solo il primo percorso valido trovato nell'elenco; se non esistono percorsi, la condizione non ha effetto.\n\nTags - Il campo tags è un elenco YAML di etichette da associare a questo chart. In\nvalori del parent superiore, tutti i chart con tag possono essere attivati o disattivati\nspecificando il tag e un valore booleano.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nNell'esempio precedente, tutti i chart con il tag `front-end` sarebbero disabilitati ma\npoiché il percorso `subchart1.enabled` valuta 'true' nei valori del parent,\nla condizione sovrascrive il tag `front-end` e `subchart1` viene abilitato.\n\nPoiché `subchart2` è etichettato con `back-end` e tale tag valuta a `true`,\n`subchart2` sarà abilitato. Si noti anche che, sebbene `subchart2` abbia una condizione\n\nspecificata, non c'è alcun percorso e valore corrispondente nei valori del parent, per cui questa\ncondizione non ha alcun effetto.\n\n##### Uso della CLI con tag e condizioni\n\nIl parametro `--set' può essere usato come di consueto per modificare i valori dei tag e delle condizioni.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Risoluzione di tag e condizioni\n\n- **Le conditions (se impostate in valori) sovrascrivono sempre i tag.** La prima condition path\n  che esiste vince e le successive per quel chart vengono ignorate.\n- I tag vengono valutati come \"se uno qualsiasi dei tag del chart è vero, allora abilita il chart\".\n- I valori dei tag e delle condition devono essere impostati nei value del chart superiore.\n- La chiave `tags:` nei value deve essere una chiave di livello superiore. I globals e le tabelle `tags:` annidate non sono attualmente supportati.\n\n#### Importare i Values dei figli tramite le dipendenze\n\nIn alcuni casi è auspicabile che i valori di un chart figlio si propaghino al chart padre e siano condivisi come values predefiniti comuni. \nUn ulteriore vantaggio di\nutilizzare il formato `exports` è che consentirà ai futuri strumenti di introspezione dei values impostabili dall'utente.\n\nLe chiavi che contengono i valori da importare possono essere specificate nel chart\npadre, nel campo `import-values`, utilizzando un elenco YAML. Ogni elemento\ndell'elenco è una chiave che viene importata dal campo `exports` del chart figlio.\n\nPer importare valori non contenuti nella chiave `exports`, utilizzare il metodo\n[child-parent](#usare-il-formato-child-parent). Esempi di entrambi i formati\nsono descritti di seguito.\n\n##### Usare il formato exports\n\nSe il file `values.yaml` di un chart figlio contiene un campo `exports` nella root, \nil suo contenuto può essere importato direttamente nei valori del parent, specificando le chiavi da importare, come nell'esempio seguente:\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\nDal 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.\n\nI valori finali del parent conterranno il nostro campo esportato:\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\nSi noti che la chiave del parent `data' non è contenuta nei values finali del parent.\n\nSe è necessario specificare la chiave del parent, utilizzare il formato 'child-parent'.\n\n##### Usare il formato child-parent\n\nPer 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\nda importare (`child`) e il percorso di destinazione nei valori del chart padre\n(`parent`).\n\nL'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\n`parent:`\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nNell'esempio precedente, i valori trovati in `default.data` nei valori del subchart1\nsaranno importati nella chiave `myimports` nei valori del chart padre, come descritto di seguito:\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nI valori risultanti del chart padre saranno:\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nI valori finali del parent contengono ora i campi `myint` e `mybool` importati da subchart1.\n\n### Gestione manuale delle dipendenze tramite la directory `charts/`\n\nSe si desidera un maggiore controllo sulle dipendenze, queste possono essere\nesplicitate copiando i chart delle dipendenze nella cartella `charts/`.\n\nUna dipendenza deve essere una cartella di chart scompattati, ma il suo nome non può iniziare con \ncon `_` o `.`. Tali file vengono ignorati dal caricatore del chart.\n\nPer esempio, se il chart di WordPress dipende dal grafico di Apache, il chart di Apache\n(della versione corretta) viene fornito nella cartella `charts/` del chart WordPress:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nL'esempio precedente mostra come il chart di WordPress esprima la sua dipendenza da\nApache e MySQL includendo questi chart all'interno della cartella `charts/`.\n\n**TIP:** _Per inserire una dipendenza nella cartella `charts/`, usare il comando `helm pull\".\n\n### Aspetti operativi dell'uso delle dipendenze\n\nLe sezioni precedenti spiegano come specificare le dipendenze dei chart, ma come influiscono sull'installazione dei chart con `helm install` e `helm upgrade`?\n\nSupponiamo che un chart chiamato \"A\" crei i seguenti oggetti Kubernetes\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nInoltre, A dipende dal chart B, che crea gli oggetti\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nDopo l'installazione/aggiornamento del chart A viene creata/modificata una singola release di Helm.\nIl rilascio creerà/aggiornerà tutti gli oggetti Kubernetes di cui sopra nel seguente ordine:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nQuesto perché quando Helm installa/aggiorna i chart, gli oggetti Kubernetes del\nchart e tutte le sue dipendenze sono\n\n- aggregati in un unico insieme; quindi\n- ordinati per tipo seguito dal nome; e poi\n- creati/aggiornati in questo ordine.\n\nQuindi viene creata una singola release con tutti gli oggetti per il chart e le sue dipendenze.\n\nL'ordine di installazione dei tipi di Kubernetes è dato dall'enumerazione InstallOrder\nin kind_sorter.go (si veda [il file sorgente di Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n## Templates e Values\n\nI template di Helm Chart sono scritti nel linguaggio [Go template](https://golang.org/pkg/text/template/), con l'aggiunta di una cinquantina di\nfunzioni template [dalla libreria Sprig](https://github.com/Masterminds/sprig) e alcune altre [funzioni specializzate](/howto/charts_tips_and_tricks.md).\n\nTutti i file dei template sono memorizzati nella cartella `templates/` di un chart. Quando Helm\nesegue il rendering dei chart, passerà ogni file in quella cartella attraverso il motore dei\n template.\n\nI values dei template possono essere forniti in due modi:\n- Gli sviluppatori dei chart possono fornire un file chiamato `values.yaml` all'interno di di un chart. Questo file può contenere valori predefiniti.\n- Gli utenti dei chart possono fornire un file YAML contenente i valori. Questo può essere fornito a riga di comando con helm install.\n\nQuando un utente fornisce valori personalizzati, questi valori sovrascrivono quelli del file values.yaml del chart.\n\n### File Template\n\nI file template seguono le convenzioni standard per la scrittura dei template di Go (vedi\n[il pacchetto Go text/templatedocumentazione](https://golang.org/pkg/text/template/) per i dettagli). \nUn esempio dipotrebbe essere simile a questo:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nL'esempio precedente, basato vagamente su\n[https://github.com/deis/charts](https://github.com/deis/charts), è un template\nper un replica controller Kubernetes. Può utilizzare i seguenti quattro valori\n(solitamente definiti in un file `values.yaml`):\n\n- `imageRegistry`: Il registry di origine dell'immagine Docker.\n- `dockerTag`: Il tag per l'immagine Docker.\n- `pullPolicy`: La politica di pull di Kubernetes.\n- `storage`: Il backend dello storage, il cui valore predefinito è impostato su `\"minio\"`.\n\nTutti questi valori sono definiti dall'autore del template. Helm non richiede o deficita di\nparametri.\n\nPer vedere chart funzionanti, consultare il CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0).\n\n### Valori predefiniti\n\nI valori forniti tramite un file `values.yaml` (o tramite il flag `--set`) sono\naccessibili dall'oggetto `.Values` di un template. Ma ci sono altri\ndati predefiniti a cui si può accedere nei template.\n\nI 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_.\n\n- `Release.Name`: Il nome della release (non il chart).\n- `Release.Namespace`: il namespace in cui è stato rilasciato il chart\n- `Release.Service`: Il servizio che ha effettuato il rilascio.\n- `Release.IsUpgrade`: Viene impostato a true se l'operazione corrente è un\n  aggiornamento o rollback.\n- `Release.IsInstall`: È impostato su true se l'operazione corrente è un'installazione.\n- `Chart`: Il contenuto di `Chart.yaml`. Pertanto, la versione del chart è\n  ottenibile come `Chart.Version` e i manutentori sono in `Chart.Maintainers`.\n- `Files`: Un oggetto simile a una mappa che contiene tutti i file non speciali del chart. Questo oggetto\n  non darà accesso ai template, ma darà accesso ai file aggiuntivi presenti (a meno che non siano esclusi usando `.helmignore`). Ai file\n  si può accedere utilizzando `{{ index .Files \"file.name\" }}` o utilizzando il comando\n  `{{.Files.Get name }}` Si può anche accedere al contenuto del file\n  come `[]byte` usando `{{ .Files.GetBytes }}`.\n- `Capabilities`: Un oggetto simile a una mappa che contiene informazioni sulle versioni\n  di Kubernetes (`{{ .Capabilities.KubeVersion }}`) e le versioni di Kubernetes\n  API supportate (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`).\n\n**NOTA:** Qualsiasi campo `Chart.yaml` sconosciuto verrà eliminato.Non saranno\naccessibili all'interno dell'oggetto `Chart`. Pertanto, `Chart.yaml` non può essere usato per\npassare dati strutturati in modo arbitrario nel template. Il file values può essere usato\nper questo, però.\n\n### Values Files\n\nConsiderando il modello della sezione precedente, un file `values.yaml` che fornisce i valori necessari\navrebbe il seguente aspetto:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nUn 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\nvalues YAML aggiuntivi:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nQuando i valori vengono passati in questo modo, verranno uniti nel file dei valori\ndi default. Per esempio, si consideri un file `myvals.yaml` che assomiglia a questo:\n\n```yaml\nstorage: \"gcs\"\n```\n\nQuando questo viene unito con il file `values.yaml` nel chart, il contenuto generato risultante sarà: \n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nSi noti che solo l'ultimo campo è stato sovrascritto.\n\n**NOTA:** Il file dei valori predefiniti incluso in un chart _deve_ essere chiamato\n`values.yaml`. Ma i file specificati sulla riga di comando possono avere qualsiasi nome.\n\n**NOTA:** Se il flag `--set` è usato in `helm install` o `helm upgrade`, quei valori sono semplicemente convertiti in YAML.\n\n**NOTA:** Se esistono voci richieste nel file dei valori, queste possono essere dichiarate\ncome richieste nel template del chart, utilizzando la funzione ['required'](/howto/charts_tips_and_tricks.md)\n\nTutti questi valori sono poi accessibili all'interno dei template utilizzando l'oggetto `.Values`:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Ambito, dipendenze e valori\n\nI 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 \nin modo diverso, un file di values può fornire valori al chart così come a qualsiasi\ndelle 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\na tutti questi componenti:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nI 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`.\nMa 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\n`apache.port`.\n\nI valori sono inseriti in namespace, ma i namespace vengono eliminati. Quindi, per il chart di WordPress,\npuò accedere al campo della password di MySQL come `.Values.mysql.password`. Ma per il chart\nMySQL, l'ambito dei valori è stato ridotto e il prefisso dello spazio dei nomi è stato\nrimosso, per cui il campo password viene visualizzato semplicemente come `.Values.password`.\n\n#### Valori globali\n\nA partire dalla versione 2.0.0-Alpha.2, Helm supporta valori speciali \"globali\". Si consideri questa\nversione modificata dell'esempio precedente:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nQuanto sopra aggiunge una sezione `global` con il valore `app: MyWordPress`. Questo valore\nè disponibile per _tutti_ i chart come `.Values.global.app`.\n\nPer esempio, i template `mysql` possono accedere a `app` come `{{.Values.global.app}}`, così come il chart `apache`. In effetti, il file values\ndi cui sopra viene rigenerato in questo modo:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\nQuesto permette di condividere una variabile di primo livello con tutti i chart secondari che\nè utile per impostare proprietà di `metadati` come le etichette.\n\nSe 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'è\nmodo che un subchart possa influenzare i valori del chart padre.\n\nInoltre, le variabili globali del chart padre hanno la precedenza sulle variabili globali dei subchart.\n\n### Schema Files\n\nA volte, il maintainer di un chart potrebbe voler definire una struttura per i suoi values.\nQuesto può essere fatto definendo uno schema nel file `values.schema.json`. Uno schema\nè rappresentato come un [JSON Schema] (https://json-schema.org/). Potrebbe assomigliare a \nqualcosa del genere:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nQuesto schema verrà applicato ai valori per convalidarli. La convalida avviene quando\nuno dei seguenti comandi:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nUn esempio di file `values.yaml` che soddisfa i requisiti di questo schema\npotrebbe assomigliare a questo:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nSi 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,\ndato che lo schema è stato installato con l'appropriata opzione `--set` mostrata\nsotto.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nInoltre, 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\nnon è soddisfatto nel file `values.yaml` del subchart, il chart padre *deve* soddisfare \ntali restrizioni per essere valido.\n\n### Riferimenti\n\nQuando si tratta di scrivere template, values e schema, esistono diversi\nriferimenti standard che vi aiuteranno.\n\n- [Go templates](https://godoc.org/text/template)\n- [Extra template functions](https://godoc.org/github.com/Masterminds/sprig)\n- [The YAML format](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n## Definizioni di risorse personalizzate (CRD)\n\nKubernetes fornisce un meccanismo per dichiarare nuovi tipi di oggetti Kubernetes.\nUtilizzando le CustomResourceDefinitions (CRDs), gli sviluppatori Kubernetes possono dichiarare tipi di risorse personalizzate.\n\nIn Helm 3, i CRD sono trattati come un tipo speciale di oggetto. Vengono installati\nprima del resto del chart e sono soggetti ad alcune limitazioni.\n\nI file YAML dei CRD devono essere collocati nella cartella `crds/` all'interno di un chart.\nPiù CRD (separati da marcatori YAML di inizio e fine) possono essere inseriti nello stesso file. \nHelm tenterà di caricare _tutti_ i file nella directory CRD\nin Kubernetes.\n\nI file CRD _non possono essere \"templetizzati\"_. Devono essere semplici documenti YAML.\n\nQuando Helm installa un nuovo chart, caricherà i CRD, si fermerà fino a quando i CRD\nsono 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,\nle informazioni sui CRD sono disponibili nell'oggetto `.Capabilities` nei template Helm,\ne i template di Helm possono creare nuove istanze di oggetti che sono stati dichiarati in\nCRD.\n\nAd esempio, se il chart ha una CRD per `CronTab` nella cartella `crds/`,\nsi possono creare istanze del tipo `CronTab` nella cartella `templates/`:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nIl file `crontab.yaml` deve contenere la CRD senza direttive di template:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nQuindi il template `mycrontab.yaml` può creare una nuova `CronTab` (usando i template\ncome di consueto):\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm si assicurerà che il tipo `CronTab` sia stato installato e che sia disponibile\ndal server API di Kubernetes prima di procedere all'installazione degli elementi in\n`templates/`.\n\n### Limitazioni dei CRD\n\nA differenza della maggior parte degli oggetti in Kubernetes, i CRD sono installati globalmente. Per questo motivo,\nHelm adotta un approccio molto cauto nella gestione dei CRD. I CRD sono soggetti alle\nseguenti limitazioni:\n\n- I CRD non vengono mai reinstallati. Se Helm determina che i CRD presenti nella directory `crds/`\n  sono già presenti (indipendentemente dalla versione), Helm non tenterà di installarli o aggiornarli.\n- I CRD non vengono mai installati in caso di aggiornamento o rollback. Helm creerà i CRD solo durante le\n  operazioni di installazione.\n- I CRD non vengono mai eliminati. L'eliminazione di un CRD cancella automaticamente tutti i contenuti del CRD in tutti i namespace del cluster.\n \nDi conseguenza, Helm non\n  eliminerà i CRD.\n\nGli operatori che desiderano aggiornare o eliminare i CRD sono invitati a farlo manualmente e con molta attenzione.\n\n## Usare Helm per gestire i chart\n\nLo strumento `helm` ha diversi comandi per lavorare con i chart.\n\nPuò creare un nuovo chart:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nUna volta modificato un chart, `helm` può impacchettarlo in un archivio di chart\nper l'utente:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nSi può anche usare `helm` per trovare problemi con la formattazione o le informazioni del chart.\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Chart Repositories\n\nUn _chart repository_  è un server HTTP che ospita uno o più chart confezionati.\nMentre `helm` può essere utilizzato per gestire le directory locali di chart, quando si tratta di\ncondividere i chart, il meccanismo preferito è un chart repository.\n\nQualsiasi server HTTP in grado di servire file YAML e file tar e di rispondere alle richieste GET\npuò essere utilizzato come server di repository. Il team di Helm ha testato alcuni\nserver, tra cui Google Cloud Storage con modalità website abilitata e S3 con modalità website  abilitata.\n\nUn repository è caratterizzato principalmente dalla presenza di un file speciale chiamato\n`index.yaml` che contiene un elenco di tutti i pacchetti forniti dal repository,\ninsieme ai metadati che permettono di recuperare e verificare tali pacchetti.\n\nSul lato client, i repository sono gestiti con i comandi `helm repo`.\nTuttavia, Helm non fornisce strumenti per il caricamento di grafici su server di repository remoti.\n Questo perché ciò comporterebbe l'aggiunta di requisiti sostanziali per un server\nserver e quindi aumenterebbe la barriera per la creazione di un repository.\n\n## Chart Starter Packs\n\nIl comando `helm create` accetta un'opzione `--starter` che permette di\nspecificare un \"chart iniziale\". Inoltre, l'opzione starter ha un alias breve `-p`.\n\nEsempi di utilizzo:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nGli starter sono dei normali chart, ma si trovano in\n`$XDG_DATA_HOME/helm/starters`. Come sviluppatore di chart, si possono creare chart \nche sono specificamente progettati per essere usati come starter. Tali chart devono essere progettati\ncon le seguenti considerazioni:\n\n- Il file `Chart.yaml` sarà sovrascritto dal generatore.\n- Gli utenti si aspetteranno di poter modificare i contenuti di un chart di questo tipo, quindi la documentazione dovrebbe\n  indicare come gli utenti possono farlo.\n- Tutte le occorrenze di `<nome del chart>` 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`, `<CHARTNAME>` NON verrà sovrascritto al loro interno. Inoltre, la descrizione del chart non viene ereditata.\n\nAttualmente l'unico modo per aggiungere un chart a `$XDG_DATA_HOME/helm/starters` è copiarlo manualmente. Nella documentazione del chart, si potrebbe spiegare\nquesto processo.\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: \"Chart Hooks\"\ndescription: \"Descrive come lavorare con i chart hooks.\"\naliases: [\"/docs/charts_hooks/\"]\nweight: 2\n---\n\nHelm 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:\n\n- Caricare una ConfigMap o un Segreto durante l'installazione prima che vengano caricati altri chart.\n- 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.\n- Eseguire un Job prima di eliminare una release per togliere in modo gracefully un service dalla rotation prima di rimuoverlo.\n\nGli hook funzionano come i normali templates, ma hanno annotazioni speciali che fanno sì che Helm li utilizzi in modo diverso.\nIn questa sezione si illustra il modello d'uso di base degli hook.\n\n## Gli Hook disponibili\n\nSono definiti i seguenti hook:\n\n| Valore Annotation | Descrizione |\n| ---------------- | ----------------------------------------------------------------------------------------------------- |\n| `pre-install` | Viene eseguito dopo il rendering dei modelli, ma prima che vengano create le risorse in Kubernetes |\n| `post-install` | Viene eseguita dopo che tutte le risorse sono state caricate in Kubernetes |\n| `pre-delete` | Viene eseguito su una richiesta di cancellazione prima che qualsiasi risorsa venga eliminata da Kubernetes |\n| `post-delete` | Viene eseguita su una richiesta di cancellazione dopo che tutte le risorse della release sono state cancellate |\n| `pre-upgrade` | Viene eseguita una richiesta di aggiornamento dopo che i template sono stati renderizzati, ma prima che le risorse siano aggiornate   |\n|`post-upgrade` | Viene eseguita una richiesta di aggiornamento dopo che tutte le risorse sono state aggiornate |\n| `pre-rollback` | Viene eseguita una richiesta di rollback dopo che i template sono stati renderizzati, ma prima che le risorse siano state rollbackate |\n| `post-rollback` | Viene eseguita una richiesta di rollback dopo che tutte le risorse sono state modificate |\n| `test` | Viene eseguita quando viene invocato il sottocomando Helm test ([view test docs](/topics/chart_tests.md))              |\n\nSi noti che l'hook `crd-install` è stato rimosso a favore della directory `crds/`.\nin Helm 3._\n\n## Hooks e Release Lifecycle\n\nGli hook consentono allo sviluppatore del chart di eseguire operazioni in punti strategici del ciclo di vita della release. \nAd esempio, si consideri il ciclo di vita di\nun'installazione di `helm`. Per impostazione predefinita, il ciclo di vita appare come segue:\n\n1. L'utente esegue `helm install foo`\n2. Viene richiamata l'API di installazione della libreria Helm3. \n3. Dopo alcune verifiche, la libreria restituisce i manifest `foo`.\n4. La libreria carica le risorse risultanti in Kubernetes\n5. La libreria restituisce l'oggetto di rilascio (e altri dati) al client.\n6. Il client esce\n\nHelm definisce due hook per il ciclo di vita di `install`: `pre-install` e `post-install`.\n Se lo sviluppatore della chart `foo` implementa entrambi gli hook, il ciclo di vita\nviene modificato in questo modo:\n\n1. L'utente esegue `helm install foo`\n2. Viene richiamata l'API di installazione della libreria Helm\n3. Vengono installati i CRD nella directory `crds/`.\n4. Dopo alcune verifiche, la libreria esegue il rendering dei template `foo`.\n5. La libreria si prepara a eseguire gli hook `pre-install` (caricamento delle risorse hook\n   in Kubernetes)\n6. La libreria ordina gli hook per peso (assegnando un peso pari a 0 per impostazione predefinita), \n   per tipo di risorsa e infine per nome in ordine crescente.\n7. La libreria carica quindi per primo hook con il peso più basso (da negativo a positivo).\n8. La libreria attende finché l'hook non è \"pronto\" (tranne che per i CRD).\n\n9. La libreria carica le risorse risultanti in Kubernetes. Si noti che se il flag\n   `--wait` è impostato, la libreria aspetterà che tutte le risorse siano in uno stato di\n   ready e non eseguirà l'hook `post-install` finché non saranno pronte.\n10. La libreria esegue l'hook `post-install` (caricando le risorse dell'hook).\n11. La libreria attende finché l'hook non è \"pronto\".\n12. La libreria restituisce l'oggetto release (e altri dati) al client.\n13. Il client esce\n\nCosa significa aspettare che un hook sia pronto? Dipende dalla risorsa\ndichiarata nell'hook. Se la risorsa è del tipo `Job` o `Pod`, Helm attenderà\nfinché non viene eseguita con successo fino al completamento. Se l'hook fallisce, il rilascio\nfallirà. Si tratta di un'operazione _bloccante_, quindi il client Helm si metterà in pausa durante l'esecuzione del Job.\n\nPer tutti gli altri tipi, non appena Kubernetes contrassegna la risorsa come caricata (aggiunta o aggiornata), la risorsa è considerata come caricata.\no aggiornata), la risorsa è considerata \"pronta\". Quando molte risorse sono\ndichiarate in un hook, le risorse vengono eseguite in serie. Se hanno un peso\n(vedere sotto), vengono eseguite in ordine ponderato. \nA 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 è\ngarantito. (In Helm 2.3.0 e successivi, sono ordinate alfabeticamente. Questo\ncomportamento, 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.\n\n### Le risorse degli hook non sono gestite con i rilasci corrispondenti\n\nLe risorse create da un hook non sono attualmente tracciate o gestite come parte del rilascio.\nUna 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\nil rilascio corrispondente viene cancellato, potrebbe essere aggiunto a Helm 3 in futuro, per cui\nle risorse hook che non devono mai essere cancellate dovrebbero essere annotate con\n`helm.sh/resource-policy: keep`.\n\nIn 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\nrisorse, è necessario o [aggiungere un'annotazione personalizzata `helm.sh/hook-delete-policy\npersonalizzata](#politiche-di-cancellazione-degli-hook) al file template dell'hook, oppure [impostare il campo time\nto live (TTL) di una risorsa Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Scrivere un hook\n\nGli hook sono semplicemente file manifest di Kubernetes con annotazioni speciali nella sezione\n`metadati`.Essendo file di template, si possono usare tutte le normali funzionalità dei template, tra cui la lettura di `.Values`, `.Release` e\n`.Template`.\n\nPer esempio, questo modello, memorizzato in `templates/post-install-job.yaml`,\ndichiara un job da eseguire su `post-install`:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nCiò che rende questo template un hook è l'annotazione:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nUna risorsa può implementare più hook:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nAllo stesso modo, non c'è limite al numero di risorse diverse che possono\nimplementare un determinato hook. Per esempio, si potrebbero dichiarare sia un segreto che una config map\ncome pre-install hook.\n\nQuando sottochart dichiarano degli hook, anche questi vengono valutati. Non c'è modo per un chart di\ndi livello superiore di disabilitare gli hook dichiarati dai sottochart.\n\nÈ possibile definire un peso per un hook, che aiuterà a costruire un ordine di esecuzione deterministico. I pesi si definiscono utilizzando la seguente\nannotazione:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nI pesi degli hook possono essere numeri positivi o negativi, ma devono essere rappresentati come\nstringhe. Quando Helm avvia il ciclo di esecuzione degli hook di un particolare tipo, li ordina modo crescente.\n\n### Politiche di cancellazione degli hook\n\nÈ possibile definire delle politiche che determinano quando eliminare le\nrisorse degli hook corrispondenti. Le politiche di cancellazione degli hook sono definite usando la seguente\nannotazione:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nÈ possibile scegliere uno o più valori di annotazione definiti:\n\n| Annotation Value       | Description                                                          |\n| ---------------------- | -------------------------------------------------------------------- |\n| `before-hook-creation` | Elimina la risorsa precedente prima che venga lanciato un nuovo hook (impostazione predefinita) |\n| `hook-succeeded`       | Eliminare la risorsa dopo che l' hook è stato eseguito con successo          |\n| `hook-failed`          | Elimina la risorsa se l'hook fallisce durante l'esecuzione              |\n\nSe non è specificata alcuna annotazione relativa alla politica di cancellazione degli hook, si applica il comportamento `before-hook-creation` per impostazione predefinita.\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/index.mdx",
    "content": "---\ntitle: Guide tematiche\nsidebar_position: 3\n---\n\n# Guide tematiche\n\nQui troverai un'introduzione a tutti i concetti principali di Helm che\ndovrai conoscere.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: \"API Kubernetes Deprecate\"\ndescription: \"Spiega le API Kubernetes deprecate in Helm\"\naliases: [\"docs/k8s_apis/\"]\n---\n\nKubernetes è un sistema basato su API e l'API si evolve nel tempo per riflettere l'evoluzione della \ncomprensione dello spazio problematico. Questa è una pratica comune a tutti i\nsistemi e le loro API. Una parte importante dell'evoluzione delle API è una buona politica e un processo di deprecazione\ne 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\nun'API sarà rimossa o modificata. \nIn questo modo si elimina l'elemento sorpresa e\ndi cambiamenti che possono causare interruzioni per i consumatori.\n\nIl [Kubernetes deprecation\npolicy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\ndocumenta come Kubernetes gestisce le modifiche alle versioni delle sue API. La politica di\ndeprecazione indica l'arco di tempo in cui le versioni delle API saranno supportate in seguito a un\nannuncio di deprecazione. È quindi importante essere a conoscenza degli annunci di deprecazione e sapere quando le versioni delle API\ne verranno rimosse, per ridurre al minimo l'effetto.\n\nQuesto è un esempio di annuncio [per la rimozione di versioni API deprecate\ndeprecate in Kubernetes\n1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) ed è stato\npubblicizzato alcuni mesi prima del rilascio. Queste API sarebbero state\nannunciate per la deprecazione prima di questo rilascio. Questo dimostra che esiste una buona\npolitica che informa i consumatori sul supporto delle versioni delle API.\n\nI template di Helm specificano un [Kubernetes API \ngroup](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)\nquando si definisce un oggetto Kubernetes, simile a un file manifest Kubernetes. Viene\nspecificato nel campo `apiVersion` del template e identifica la versione dell'API\ndell'oggetto Kubernetes. Questo significa che gli utenti di Helm e i manteiner dei chart \nHelm devono sapere quando le versioni delle API di Kubernetes sono state deprecate e in quale versione di Kubernetes saranno rimosse.\n\n## Maintainers dei chart\n\nÈ necessario controllare i chart per verificare la presenza di versioni dell'API Kubernetes che siano\ndeprecate o rimosse in una versione di Kubernetes. Le versioni dell'API trovate come deprecate\no 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 \n`kind` e `apiVersion`. Ad esempio, un oggetto `Deployment` rimosso\nnella versione API di Kubernetes 1.16:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Utenti Helm\n\nÈ necessario verificare i chart che si utilizzano (in modo simile a [chart\nmaintainers](#maintainers-dei-chart)) e identificare tutti i chart in cui le versioni delle API sono\ndeprecate 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.\n\nInoltre, è necessario verificare tutti i chart distribuiti (ad esempio, i rilasci di Helm).\nverificando nuovamente la presenza di versioni API deprecate o rimosse. Questo può essere fatto\nottenendo i dettagli di una release con il comando `helm get manifest`.\n\nI mezzi per aggiornare una release di Helm alle API supportate dipendono dalle vostre scoperte\ncome segue:\n\n1. Se si trovano versioni API deprecate solo allora:\n  - Eseguire un `aggiornamento` con una versione del chart con versioni API di Kubernetes supportate.\n  \n- Aggiungere una descrizione nell'aggiornamento, qualcosa del tipo di non eseguire un     rollback a una versione di Helm precedente a quella attuale.\n\n2.  Se si trova una o più versioni di API che sono state rimosse in una versione di Kubernetes\n    allora:\n  - Se si sta eseguendo una versione di Kubernetes in cui la versione o le versioni API sono ancora\n    disponibili (ad esempio, si è su Kubernetes 1.15 e si è scoperto di utilizzare API\n    che saranno rimosse in Kubernetes 1.16):\n    - Seguire la procedura del passo 1\n  - In caso contrario (ad esempio, si sta già utilizzando una versione di Kubernetes dove\n    alcune versioni di API segnalate da `helm get manifest` non sono più disponibili):\n    - È necessario modificare il manifest di rilascio memorizzato nel cluster per\n      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.\n\n> Nota: in tutti i casi di aggiornamento di una release di Helm con API supportate, non si dovrebbe\nmai eseguire il rollback della release a una versione precedente a quella con le API supportate.\n\n> 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.\n\nSe non si aggiorna una release come suggerito in precedenza, si verificherà un errore\nsimile al seguente quando si tenta di aggiornare una release in una versione Kubernetes\nin cui la versione o le versioni API sono state rimosse:\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm fallisce in questo scenario perché tenta di creare una patch diff tra la release correntemente distribuita (che contiene le API di Kubernetes che vengono\n\nrimosse in questa versione di Kubernetes) rispetto al chart che si sta passando con le \nversioni 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.\n Helm purtroppo non è in grado di riprendersi da questa situazione e non è più in grado di gestire un simile rilascio. \n 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.\n\n## Aggiornamento delle versioni API di un Release Manifest\n\nIl 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 \ncontiene un oggetto gzipped codificato in base 64 (c'è un'ulteriore codifica in base 64 per un Secret). \nEsiste un Secret/ConfigMap per release nel namespace della release.\n\nÈ possibile utilizzare il plugin Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis)\nper eseguire l'aggiornamento di una release alle API supportate. Consultare il readme\nper maggiori dettagli.\n\nIn alternativa, si possono seguire i seguenti passaggi manuali per eseguire l'aggiornamento delle versioni APIdi un manifest di rilascio. \nA seconda della configurazione, si seguiranno i passi per il backend Secret o la ConfigMap.\n\n- Ottenere il nome del Secret o della Configmap associata all'ultima release distribuita :\n  - backend Secrets: `kubectl get secret -l \n    owner=helm,status=deployed,name=<nome_release> --namespace\n    <namespace_di_rilascio> | awk '{print $1}' | grep -v NAME`   \n- backend ConfigMap: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<nome_rilasciato> --namespace\n    <namespace_di_rilascio> | awk '{print $1}' | grep -v NAME`\n- Ottenere i dettagli dell'ultimo rilascio distribuito:\n  - Secrets backend: `kubectl get secret <nome_segreto_di_rilascio> -n\n    <release_namespace> -o yaml > release.yaml`\n  - ConfigMap Backend: `kubectl get configmap <release_configmap_name> -n\n    <namespace_di_rilascio> -o yaml > release.yaml`\n- Eseguire il backup del rilascio, nel caso sia necessario ripristinarlo se qualcosa va storto:\n  - `cp release.yaml release.bak`\n  - In caso di emergenza, ripristinare: `kubectl apply -f release.bak -n\n    <namespace_di_rilascio>`\n- Decodificare l'oggetto release:\n  - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- Cambia le versioni API dei manifest. Si può usare qualsiasi strumento (per esempio un editor) per apportare le modifiche. \nQuesto si trova nel campo `manifest` dell'oggetto release decodificato (`release.data.decoded`)\n- Codifica l'oggetto release: \n  - Secrets backend: `cat release.data.decoded | gzip | base64 | base64`\n  - ConfigMap backend: `cat release.data.decoded | gzip | base64`\n- Sostituire il valore della proprietà `data.release` nel file di rilascio distribuito   \n(`release.yaml`) con il nuovo oggetto di rilascio codificato\n- Applicare il file allo nel namespace: `kubectl apply -f release.yaml -n\n  <namespace_di_rilascio>`\n- Eseguire un `helm upgrade` con una versione del chart con le versioni supportate di API Kubernetes\n- Aggiungere una descrizione nell'aggiornamento, qualcosa del tipo di non eseguire un\n  rollback a una versione di Helm precedente a questa versione attuale\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: \"Guida alle distribuzioni di Kubernetes\"\ndescription: \"Raccoglie informazioni sull'utilizzo di Helm in ambienti Kubernetes specifici.\"\naliases: [\"/docs/kubernetes_distros/\"]\nweight: 10\n---\n\nHelm dovrebbe funzionare con qualsiasi [versione conforme di\nKubernetes](https://github.com/cncf/k8s-conformance) (che sia\n[certificato](https://www.cncf.io/certification/software-conformance/) o meno).\n\nQuesto documento raccoglie informazioni sull'uso di Helm in specifici ambienti Kubernetes. \nSi prega di contribuire con ulteriori dettagli su qualsiasi distro (ordinata\nin ordine alfabetico) se lo si desidera.\n\n## AKS\n\nHelm funziona con [Azure Kubernetes\nService](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nHelm è stato testato e funziona sulla piattaforma Mesospheres DC/OS 1.11 Kubernetes,\ne non richiede alcuna configurazione aggiuntiva.\n\n## EKS\n\nHelm funziona con Amazon Elastic Kubernetes Service (Amazon EKS):\n[Utilizzo di Helm con Amazon\nEKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nLa piattaforma Kubernetes in hosting GKE di Google è nota per funzionare con Helm e non richiede \nnessuna configurazione aggiuntiva.\n\n## `scripts/local-cluster` e Hyperkube\n\nÈ noto che Hyperkube configurato tramite `scripts/local-cluster.sh` funziona. Per \nHyperkube raw potrebbe essere necessario eseguire una configurazione manuale.\n\n## IKS\n\nHelm funziona con [IBM Cloud Kubernetes\nService](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nHelm è regolarmente testato su [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne\n\nHelm funziona senza problemi nei cluster impostati da KubeOne.\n\n## Kubermatic\n\nHelm funziona senza problemi nei cluster utente creati da Kubermatic.\nPoiché i seed cluster possono essere impostati in modi diversi, il supporto di Helm dipende dalla loro configurazione.\n\n## MicroK8s\n\nHelm può essere abilitato in [MicroK8s](https://microk8s.io) usando il comando:\n`microk8s.enable helm3`\n\n## Minikube\n\nHelm è testato e noto per funzionare con\n[Minikube](https://github.com/kubernetes/minikube). Non richiede alcuna\nconfigurazione aggiuntiva.\n\n## Openshift\n\nHelm funziona direttamente su OpenShift Online, OpenShift Dedicated, OpenShift \nContainer Platform (versione >= 3.6) o OpenShift Origin (versione >= 3.6). Per\nsaperne di più leggete [questo\nblog](https://blog.openshift.com/getting-started-helm-openshift/) post.\n\n## Platform9\n\nHelm è preinstallato con [Platform9 Managed\nKubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes).\nPlatform9 fornisce l'accesso a tutti i chart ufficiali di Helm attraverso l'interfaccia utente dell'App Catalog\ne la CLI nativa di Kubernetes. È possibile aggiungere manualmente altri repository. \nUlteriori dettagli sono disponibili in questo [articolo Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes).\n\n## Ubuntu con `kubeadm`\n\nKubernetes avviato con `kubeadm` è noto per funzionare sulle seguenti distribuzioni Linux:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nAlcune versioni di Helm (v2.0.0-beta2) richiedono di `esportare\nKUBECONFIG=/etc/kubernetes/admin.conf` o creare un `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid\n\nHelm funziona su VMware Tanzu Kubernetes Grid, TKG, senza bisogno di modifiche alla configurazione. \nLa 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. \nUlteriori 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).\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: \"Library Charts\"\ndescription: \"Spiega i library charts e gli esempi di utilizzo\"\naliases: [\"docs/library_charts/\"]\nweight: 4\n---\n\nUn library chart è un tipo di [[Helm chart]] ({{< ref \"/docs/topics/charts.md\" >}})\nche definisce primitive o definizioni di chart che possono essere condivise dai template di Helm in altri chart. \nQuesto permette agli utenti di condividere frammenti di codice che possono essere\nriutilizzabili tra i vari chart, evitando ripetizioni e mantenendo i chart\n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nIl library chart è stato introdotto in Helm 3 per riconoscere formalmente i chart comuni o\n di aiuto che sono stati utilizzati dai manutentori dei chart a partire da Helm 2. Includendolo come\n tipo di chart, fornisce:\n- un mezzo per distinguere esplicitamente tra chart comuni e chart applicativi\n- Una logica per impedire l'installazione di un chart comune\n- Nessun rendering di template in un chart comune, che potrebbe contenere artefatti di rilascio.\n- Permettere ai chart dipendenti di utilizzare il contesto dell'importatore.\n\nUn 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\n che le definizioni in un chart applicativo possono essere condivise cambiando\nil tipo di chart.\n\n## Creare un Simple Library Chart\n\n Come accennato in precedenza, un library chart è un tipo di [Helm chart]({{< ref \"/docs/topics/charts.md\" >}}).  \nCiò significa che si può iniziare creando un chart:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nSi rimuoveranno prima tutti i file nella cartella `templates`, poiché in questo esempio si creeranno le\n le nostre definizioni di template.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nAnche il file values non sarà necessario.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nPrima 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\no un subtemplate) è semplicemente un template definito all'interno di un file e a cui viene dato un nome.\nNella cartella `templates/`, qualsiasi file che inizia con un trattino basso(_)\nnon è previsto come output di un file manifest di Kubernetes. Quindi, per convenzione, i template\ne partials sono inseriti in un file `_*.tpl` o `_*.yaml`.\n\nIn questo esempio, si codificherà un ConfigMap comune che crea una risorsa\nConfigMap vuota. Si definirà il ConfigMap comune nel file\n`mylibchart/templates/_configmap.yaml` come segue:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nIl 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'è\nun altro modello denominato `mylibchart.configmap`. Questo named template\ninclude un altro template chiamato `mylibchart.util.merge` che prenderà come argomenti due named template\n il template che chiama `mylibchart.configmap` e\n`mylibchart.configmap.tpl`.\n\nLa helper function `mylibchart.util.merge` è un named template in\n`mylibchart/templates/_util.yaml`. Si tratta di un pratico utility di [The Common Helm\nHelper Chart](#the-common-helm-helper-chart) perché fonde i due template\ne sovrascrive qualsiasi parte comune in entrambi:\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nQuesto è importante quando un chart vuole utilizzare codice comune che deve essere personalizzato con la sua configurazione.\n\nInfine, cambiamo il tipo di chart in `library`. Questo richiede la modifica di\n`mylibchart/Chart.yaml` come segue:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\nIl library chart è ora pronto per essere condiviso e la sua definizione di ConfigMap può essere riutilizzata.\n\nPrima di andare avanti, vale la pena di verificare se Helm riconosce il chart come un library chart:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Utilizzare il Simple Library Chart\n\nÈ il momento di utilizzare il library chart. Ciò significa creare nuovamente un chart:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nRipuliamo di nuovo i file dei template, perché vogliamo creare solo una ConfigMap:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nQuando si vuole creare una semplice ConfigMap in un template di Helm, si potrebbe avere un aspetto\nsimile al seguente:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nTuttavia, riutilizzeremo il codice comune già creato in `mylibchart`.\nLa ConfigMap può essere creata nel file `mychart/templates/configmap.yaml`\ncome segue:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nSi può notare che si semplifica il lavoro da fare, ereditando la definizione comune di\nConfigMap, che aggiunge proprietà standard per ConfigMap. Nel nostro modello\naggiungiamo la configurazione, in questo caso la chiave dati `myvalue` e il suo valore.\nvalore. La configurazione sovrascrive la risorsa vuota del ConfigMap comune.\nQuesto è possibile grazie alla funzione helper `mylibchart.util.merge` di cui abbiamo parlato nella sezione precedente.\n\nPer poter utilizzare il codice comune, è necessario aggiungere `mylibchart` come dipendenza.\nAggiungere quanto segue alla fine del file `mychart/Chart.yaml`:\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nQuesto include il library chart come dipendenza dinamica dal filesystem\nche si trova nello stesso percorso padre del nostro chart dell'applicazione. Poiché stiamo includendo\nil library chart come dipendenza dinamica, è necessario eseguire `helm dependency update`. \nQuesto copierà il library chart nella cartella `charts/`.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nOra siamo pronti a distribuire il nostro chart. Prima dell'installazione, vale la pena di controllare\nil template renderizzato.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nQuesta sembra la ConfigMap che vogliamo, con la sovrascrittura dei dati di `myvalue: Hello\nWorld`. Installiamolo:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nPossiamo recuperare il rilascio e vedere che il template effettivo è stato caricato.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## Vantaggi dei Library Chart\n\nA causa della loro incapacità di agire come chart autonomi, i library charts possono sfruttare le seguenti funzionalità:\n- L'oggetto `.Files` fa riferimento ai percorsi dei file del chart padre, anziché al percorso locale del library charts.\n- L'oggetto `.Values` è lo stesso del chart padre, a differenza dei \n[subcharts](/chart_template_guide/subcharts_and_globals.md) dell'applicazione che ricevono la sezione di valori configurata sotto la loro intestazione nel chart padre.\n\n\n## The Common Helm Helper Chart\n\n```markdown\nNote: Il repo Common Helm Helper Chart su Github non è più mantenuto attivamente e il repo è stato deprecato e archiviato.\n```\n\nQuesto [chart] (https://github.com/helm/charts/tree/master/incubator/common) era\nil pattern originale per i chart comuni. Fornisce utilità che riflettono le best practice\n di sviluppo dei chart Kubernetes. Soprattutto, può essere utilizzato\nquando si sviluppano i chart, in modo da avere a disposizione un pratico codice condiviso.\n\nEcco un modo rapido per usarlo. Per maggiori dettagli, consultare il file\n[README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nCreare di nuovo un chart:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nUtilizziamo il codice comune della tabella degli helper. Per prima cosa, modificare il file di deployment\n`demo/templates/deployment.yaml` come segue:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nE ora il file del service, `demo/templates/service.yaml`, come segue:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nQuesti template mostrano come l'ereditarietà del codice comune dal helper chart\nsemplifica la codifica fino alla configurazione o alla personalizzazione delle risorse.\n\nPer poter utilizzare il codice comune, occorre aggiungere `common` come dipendenza. Aggiungere\nquanto segue alla fine del file `demo/Chart.yaml`:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nNota: è necessario aggiungere il repo `incubator` all'elenco dei repository Helm\n(`helm repo add`).\n\nPoiché stiamo includendo il chart come dipendenza dinamica, dobbiamo eseguire \n`helm dependency update`. Questo copierà il chart helper nella cartella `charts/`.\n\nPoiché l'helper chart utilizza alcuni costrutti di Helm 2, è necessario aggiungere il file\na `demo/values.yaml` per consentire il caricamento dell'immagine `nginx`, che \nè stata aggiornata nello scaffold chart di Helm 3:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nSi può verificare che i chart template siano corretti prima di distribuirli usando i comandi `helm lint` e `helm template`.\n\nSe è tutto a posto, si può procedere al deploy con `helm install`!\n\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: \"Gestione delle autorizzazioni per SQL storage backend\"\ndescription: \"Scoprite come impostare le autorizzazioni quando si utilizza SQL storage backend.\"\n---\n\nQuesto documento ha lo scopo di fornire agli utenti una guida per l'impostazione e la gestione dei permessi nell'utilizzo del SQL storage backend.\n\n## Introduzione\n\nPer gestire i permessi, Helm sfrutta la funzione RBAC di Kubernetes. Quando si utilizza\nSQL storage backend, i ruoli di Kubernetes non possono essere utilizzati per determinare se un utente può accedere o meno a una determinata risorsa. \nQuesto documento mostra come creare e\ngestire questi permessi.\n\n## Inizializzazione\n\nLa prima volta che la CLI di Helm si connetterà al database, il client si accerterà che sia stato\nprecedentemente inizializzato. Se così non fosse, si occuperà automaticamente dell'impostazione necessaria.\nQuesta inizializzazione richiede i privilegi di amministratore\nsullo schema pubblico, o almeno per essere in grado di:\n\n* creare una tabella\n* concedere i privilegi sullo schema pubblico\n\nDopo l'esecuzione della migrazione sul database, tutti gli altri ruoli possono utilizzare il client.\n\n## Concedere i privilegi a un utente non amministratore in PostgreSQL\n\nPer gestire i permessi, il driver del backend SQL sfrutta l'opzione\n[RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security\nSecurity Level) di PostgreSQL. RLS consente a tutti gli utenti di poter leggere/scrivere\ndalla/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\nconcesso esplicitamente con i giusti privilegi restituirà sempre un elenco vuoto\nquando si esegue `helm list` e non sarà in grado di recuperare o modificare alcuna risorsa nel cluster.\n\nVediamo come concedere a un determinato ruolo l'accesso a specifici spazi dei nomi:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nQuesto comando concederà i permessi di lettura e scrittura a tutte le risorse che\nsoddisfano la condizione `namespace = 'default'' al ruolo `role'. Dopo aver creato\nquesta politica, l'utente che si connette al database per conto del ruolo\n`role` sarà quindi in grado di vedere tutti i rilasci che risiedono nel namespace`default`.\nquando si esegue `helm list`, e di modificarle e cancellarle.\n\nI privilegi possono essere gestiti in modo granulare con RLS, e si potrebbe essere interessati a\nlimitare l'accesso alle diverse colonne della tabella:\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: \"Guida ai plugin di Helm\"\ndescription: \"Introduce all'uso e alla creazione di plugin per estendere le funzionalità di Helm.\"\nweight: 12\n---\n\nUn plugin di Helm è uno strumento a cui si può accedere tramite la CLI `helm`, ma che \nnon fa parte della base di codice di Helm.\n\nQuesta guida spiega come usare e creare i plugin.\n\n## Una panoramica\n\nI plugin di Helm sono strumenti aggiuntivi che si integrano perfettamente con Helm. Forniscono\nun modo per estendere il set di funzionalità principali di Helm, senza però richiedere che ogni nuova\nfunzionalità sia scritta in in Go e di aggiungerle al core dello strumento.\n\nI plugin di Helm hanno le seguenti caratteristiche:\n\n- Possono essere aggiunti e rimossi da un'installazione di Helm senza impattare lo\n  strumento principale.\n- Possono essere scritti in qualsiasi linguaggio di programmazione.\n- Si integrano con Helm e vengono visualizzati in `helm help` e in altri luoghi.\n\nI plugin di Helm si trovano in `$HELM_PLUGINS`. È possibile trovarne il valore corrente,\ncompreso il valore predefinito quando non è impostato nell'ambiente, usando il comando\n`helm env`.\n\nIl modello a plugin di Helm è parzialmente basato sul modello a plugin di Git. A tal fine,\na 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\nl'esperienza dell'utente e la logica di elaborazione di primo livello, mentre i plugin svolgono il\n\"lavoro di dettaglio\" per eseguire un'azione desiderata.\n\n## Installazione di un plugin\n\nI plugin vengono installati con il comando `$ helm plugin install <path|url>`. È possibile\n inserire il percorso di un plugin sul file system locale o l'url di un repo VCS remoto.\nIl comando `helm plugin install` clona o copia il plugin nel \npercorso/url indicato in `$HELM_PLUGINS`\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nSe si dispone di una distribuzione tar del plugin, è sufficiente decomprimere il plugin nella cartella\n`$HELM_PLUGINS`. È anche possibile installare i plugin in formato tar\n direttamente da url, lanciando `helm plugin install\nhttps://domain/path/to/plugin.tar.gz`\n\n## La struttura del file Plugin\n\nPer molti versi, un plugin è simile a un chart. Ogni plugin ha una cartella di primo livello\n e un file `plugin.yaml`. Possono essere presenti altri file, ma è necessario solo il file plugin.yaml.\n\n```\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n## Il file plugin.yaml\n\nIl file plugin.yaml è necessario per un plugin. Contiene i seguenti campi:\n\n```yaml\nname: il nome del plugin (OBBLIGATORIO)\nversion: Una versione in formato SemVer 2 (OBBLIGATORIA)\nusage: Testo d'uso a riga singola mostrato nella guida\ndescrizione: Lunga descrizione mostrata in luoghi come l'help di Helm\nignoreFlags: Ignora i flag passati in Helm\nplatformCommand: # Configura il comando da eseguire in base alla piattaforma\n  - os: OS match, può essere vuoto o omesso per corrispondere a tutti i sistemi operativi.\n    arch: Architecture match, può essere vuoto o omesso per corrispondere a tutte le architetture\n    command: Comando del plugin da eseguire\n    args: Argomenti del comando del plugin\ncommand: (DEPRECATO) Comando del plugin, utilizzare invece platformCommand\nplatformHooks: # Configura gli hook del ciclo di vita del plugin in base alla piattaforma\n  install: # Comando di install\n    - os: OS match, può essere vuoto o omesso per corrispondere a tutti i sistemi operativi.\n      arch: Architecture match, può essere vuoto o omesso per corrispondere a tutte le architetture\n      comando: Comando di installazione del plugin da eseguire\n      args: Argomenti del comando di installazione del plugin\n  update: # Comando di update\n    - os: OS match, può essere vuoto o omesso per corrispondere a tutti i sistemi operativi.\n      arch: Architecture match, può essere vuoto o omesso per corrispondere a tutte le architetture\n      comando: Comando di aggiornamento del plugin da eseguire\n      args: Argomenti del comando di aggiornamento del plugin\n  delete: # Comando di delete plugin\n    - os: OS match, può essere vuoto o omesso per corrispondere a tutti i sistemi operativi.\n      arch: Architecture match, può essere vuoto o omesso per corrispondere a tutte le architetture\n      comando: Comando di cancellazione del plugin da eseguire\n      args: Argomenti del comando di cancellazione del plugin\nhooks: # (Deprecato) Hook del plugin, usare invece platformHooks\n  install: Comando per installare il plugin\n  update: Comando per aggiornare il plugin\n  delete: Comando per cancellare il plugin\ndownloader: # Configura la capacità dei downloader\n  - command: Comando da invocare\n    protocolli:\n      - Schema di protocollo supportato\n```\n\n### Il campo `name`\n\nIl campo `name` è il nome del plugin. Quando Helm esegue questo plugin, questo\nè il nome che utilizzerà (ad esempio, `helm NAME` invocherà questo plugin).\n\n_`name` deve corrispondere al nome della cartella._ Nell'esempio precedente, ciò significa che il plugin\ncon `name: last` deve essere contenuto in una cartella chiamata `last`.\n\nRestrizioni su `name`:\n\n- `name` non può duplicare uno dei comandi di primo livello esistenti `helm`.\n- `name` deve essere limitato ai caratteri ASCII a-z, A-Z, 0-9, `_` e `-`.\n\n### Il campo `version`\n\nLa `version` è la versione in formato SemVer 2 del plugin. I campi `usage` e `description` sono\nentrambi utilizzati per generare il testo di aiuto di un comando.\n\n### Il campo `ignoreFlags`\n\nL'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\n`--foo` viene silenziosamente scartato.\n\n### Il campo `platformCommand`\n\nIl 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:\n\n- Se `platformCommand` è presente, verrà utilizzato.\n  - Se sia `os` che `arch` corrispondono alla piattaforma corrente, la ricerca si interrompe e viene utilizzato il comando\n  - Se `os` corrisponde e `arch` è vuoto, verrà utilizzato il comando.\n  - Se `os` e `arch` sono entrambi vuoti, verrà utilizzato il comando.\n  - Se non c'è corrispondenza, Helm uscirà con un errore.\n- Se `platformCommand` non è presente e il deprecato `command` è presente\nverrà utilizzato.\n  - Se il comando è vuoto, Helm uscirà con un errore.\n\n### Il campo `platformHooks`\n\nIl 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.\nPer decidere quale comando di hook utilizzare, si applicano le seguenti regole:\n\n- Se `platformHooks` è presente, verrà utilizzato e i comandi per l'evento del ciclo di vita saranno processati.\n  - Se sia `os` che `arch` corrispondono alla piattaforma corrente, la ricerca si interrompe e il comando sarà utilizzato\n  - Se `os` corrisponde e `arch` è vuoto, il comando verrà utilizzato.\n  - Se `os` e `arch` sono entrambi vuoti, verrà utilizzato il comando.\n  - Se non c'è corrispondenza, Helm salterà l'evento.\n- Se `platformHooks` non è presente e il deprecato `hooks` è presente il comando\nper l'evento del ciclo di vita sarà usato.\n  - Se il comando è vuoto, Helm salterà l'evento.\n\n\n## Building a Plugin\n\nEcco un plugin YAML per un semplice plugin che aiuta a recuperare il nome dell'ultima release:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nI plugin possono richiedere script ed eseguibili aggiuntivi.\nGli script possono essere inclusi nella cartella dei plugin e gli eseguibili possono essere scaricati\ntramite un hook. Il seguente è un esempio di plugin:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nLe 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.\n\n### Comandi dei plugin\n\nEsistono alcune strategie per lavorare con i comandi dei plugin:\n\n- Se un plugin include un eseguibile, l'eseguibile per un `platformCommand:`\n  dovrebbe essere impacchettato nella cartella del plugin o installato tramite un hook.\n- La linea `platformCommand:` o `command:` avrà le variabili d'ambiente espanse prima dell'esecuzione. \n`$HELM_PLUGIN_DIR` punterà alla cartella dei plugin.\n- Il comando stesso non viene eseguito in una shell. Quindi non è possibile eseguire uno script.\n- Helm inietta molte configurazioni nelle variabili d'ambiente. Si può dare un'occhiata all'ambiente per vedere quali informazioni sono disponibili.\n- Helm non fa alcuna ipotesi sulla linguaggio del plugin. È possibile scriverlo\n  in qualsiasi linguaggio si preferisca.\n- I comandi sono responsabili dell'implementazione di testi di aiuto specifici per `-h` e\n  `--help`. Helm userà `usage` e `description` per `helm help` e `helm\n  help myplugin`, ma non gestirà `helm myplugin --help`.\n\n### Testare un plugin locale\n\nPer prima cosa è necessario trovare il percorso `HELM_PLUGINS` e per farlo eseguire il seguente comando:\n\n``` bash\nhelm env\n```\n\nCambiare la propria directory corrente nella directory in cui è impostato `HELM_PLUGINS`.\n\nOra si può aggiungere un collegamento simbolico all'output di compilazione del plugin, in questo esempio\nlo abbiamo fatto per `mapkubeapis`.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Downloader Plugins\nPer impostazione predefinita, Helm è in grado di estrarre i chart tramite HTTP/S. A partire da Helm 2.4.0, i plugin \npossono avere una capacità speciale di scaricare chart da fonti arbitrarie.\n\nI plugin devono dichiarare questa capacità speciale nel file `plugin.yaml` (livello superiore):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nSe tale plugin è installato, Helm può interagire con il repository usando lo schema di protocollo specificato invocando il `comand`.\n Il repository speciale \ndeve 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\nscoprire e memorizzare nella cache l'elenco dei chart disponibili.\n\nIl comando definito sarà invocato con il seguente schema: `command certFile\nkeyFile caFile full-URL`. Le credenziali SSL provengono dalla definizione del repo\nmemorizzate in `$HELM_REPOSITORY_CONFIG`.\n(cioè, `$HELM_CONFIG_HOME/repositories.yaml`). Un downloader plugin \ndovrebbe scaricare il contenuto grezzo su stdout e segnalare gli errori su stderr.\n\nIl comando downloader supporta anche subcommands o argomenti, consentendo di\nspecificare ad esempio il subcommand `bin/mydownloader -d` nel file `plugin.yaml`. Questo\nè utile se si vuole usare lo stesso eseguibile per il comando principale del plugin e per\nil comando downloader, ma con un subcommand diverso per ciascuno.\n\n## Variabili d'ambiente\n\nQuando Helm esegue un plugin, passa l'environment esterno al plugin e inietta alcune variabili d'ambiente aggiuntive.\n\nVariabili come `KUBECONFIG` sono impostate per il plugin se sono impostate nell'ambiente esterno.\n\nViene garantito che le seguenti variabili siano impostate:\n\n- `HELM_PLUGINS`:Il percorso della cartella dei plugin.\n- `HELM_PLUGIN_NAME`: Il nome del plugin, come invocato da `helm`. Quindi `helm\n  myplug` avrà il nome breve `myplug`.\n- `HELM_PLUGIN_DIR`: La directory che contiene il plugin.\n- `HELM_BIN`: Il percorso del comando `helm` (come eseguito dall'utente).\n- `HELM_DEBUG`: Indica se il flag di debug è stato impostato da helm.\n- `HELM_REGISTRY_CONFIG`: Il percorso della configurazione del registry (se\n  se si usa). Si noti che l'uso di Helm con i registry è una funzione sperimentale.\n- `HELM_REPOSITORY_CACHE`: Il percorso dei file della cache del repository.\n- `HELM_REPOSITORY_CONFIG`: Il percorso del file di configurazione del repository.\n- `HELM_NAMESPACE`: Il namespace dato al comando `helm` (generalmente usando il flag\n  il flag `-n`).\n- `HELM_KUBECONTEXT`: Il nome del contesto di configurazione di Kubernetes dato al comando\n  `helm`.\n\nInoltre, se è stato specificato esplicitamente un file di configurazione di Kubernetes, esso verrà\nsarà impostato come variabile `KUBECONFIG`.\n\n## Una nota sul flag parsing\n\nQuando si esegue un plugin, Helm analizza i flag globali per il proprio uso. Nessuno di questi\n flag viene passato al plugin.\n\n- `--debug`: Se viene specificato, `$HELM_DEBUG` viene impostato a `1`.\n- `--registry-config`: Viene convertito in `$HELM_REGISTRY_CONFIG`.\n- `--repository-cache`: Viene convertito in `$HELM_REPOSITORY_CACHE`.\n- `--repository-config`: Viene convertito in `$HELM_REPOSITORY_CONFIG`.\n- `--namespace` e `-n`: Viene convertito in `$HELM_NAMESPACE`.\n- `--kube-context`: Viene convertito in `$HELM_KUBECONTEXT`.\n- `--kubeconfig`: Viene convertito in `$KUBECONFIG`.\n\nI plugin dovrebbero mostrare un testo di aiuto e poi uscire per `-h` e `--help`. In tutti gli\naltri casi, i plugin possono usare i flag come meglio credono.\n\n## Supporto per l'autocompletamento della shell\n\nA 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.\n \n### Autocompletamento statico\n\nSe 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.\nIl file `completion.yaml` ha la forma:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nNote:\n1. Tutte le sezioni sono facoltative ma devono essere fornite se applicabili.\n2. I flag non devono includere il prefisso `-` o `--`.\n3. Possono e devono essere specificati flag sia brevi che lunghi. Un flag breve non deve necessariamente\n essere associato alla corrispondente forma lunga, ma entrambe le forme devono essere\n   elencate.\n4. I flag non devono essere ordinati in alcun modo, ma devono essere elencati nel punto corretto della gerarchia dei sottocomandi del file.\n5. 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`,\n`--namespace` o `-n`, `--kube-context` e `--kubeconfig`, o qualsiasi altro flag globale.\n\n6. L'elenco `validArgs` fornisce un elenco statico di possibili completamenti del\n   primo parametro di un sottocomando.  Non è sempre possibile\n   fornire tale elenco in anticipo (vedere la sezione [Completamento dinamico](#completamento-dinamico)), nel qual caso la sezione\n`validArgs` può essere omessa.\n\nIl file `completion.yaml` è del tutto opzionale.  Se non viene fornito, Helm\nnon 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\n`completion.yaml` è compatibile con le versioni precedenti e non avrà alcun impatto sul comportamento del plugin quando si utilizzano versioni precedenti di helm.\n\nA titolo di esempio, per il [`fullstatus\n](https://github.com/marckhouzam/helm-fullstatus) che non ha sottocomandi, ma accetta gli stessi flag del comando `helm status`, il file\nfile `completion.yaml` è:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nUn esempio più complesso per il \n[`2to3`](https://github.com/helm/helm-2to3), ha un file `completion.yaml` del tipo:\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### Completamento dinamico\n\nSempre a partire da Helm 3.2, i plugin possono fornire il proprio completamento automatico della shell. \nL'autocompletamento dinamico della shell è il completamento dei valori dei parametri o dei flag che non possono essere\ndefiniti in anticipo.  Ad esempio,\nil completamento dei nomi delle release di helm attualmente disponibili sul cluster.\n\nAffinché il plugin supporti l'autocompletamento dinamico, deve fornire un file\n **eseguibile** chiamato `plugin.complete` nella sua directory principale. Quando lo script di completamento di\nHelm 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\ndeterminare quali siano le scelte corrette per il completamento e inviarle allo standard\nper essere utilizzato dallo script di completamento di Helm.\n\nIl file `plugin.complete` è del tutto opzionale.  Se non viene fornito, Helm\nnon 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\ncon versioni precedenti di Helm.\n\nL'output dello script `plugin.complete` dovrebbe essere un elenco separato da new-line char\ncome ad esempio:\n\n```\nrel1\nrel2\nrel3\n```\n\nQuando viene richiamato `plugin.complete`, l'ambiente del plugin viene impostato come quando viene richiamato lo script principale del plugin.\nPertanto, le variabili `$HELM_NAMESPACE`,\n`$HELM_KUBECONTEXT` e tutte le altre variabili del plugin saranno già impostate e i corrispondenti flag globali saranno rimossi.\n\nIl 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\n `plugin.complete` ***deve*** avere i permessi di esecuzione per l'utente. Il file\n `plugin.complete` ***deve*** terminare con codice di successo (valore 0).\n\nIn 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.\nNel plugin `fullstatus`, per il suo script `plugin.complete`\nfornisce il completamento per i nomi dei rilasci correnti, può semplicemente eseguire `helm list -q` e produrre il risultato.\n\nSe si vuole usare lo stesso eseguibile per l'esecuzione del plugin e per il suo completamento, lo script\n`plugin.complete` deve richiamare l'eseguibile del plugin principale  con qualche parametro o flag speciale; quando l'eseguibile principale del plugin\nrileva il parametro o il flag speciale, saprà di dover eseguire il completamento. Nel nostro\n esempio, `plugin.complete` potrebbe essere implementato in questo modo:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nIl vero script del plugin `fullstatus` (`status.sh`) deve quindi cercare il flag `--complete`\ne, se lo trova, stampare il completamento corretto.\n\n### Suggerimenti e trucchi\n\n1. 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\n   rimuovere quelli che non corrispondono all'input dell'utente.  Ad esempio, se la riga di comando è `helm fullstatus ngin<TAB>`, lo script `plugin.complete` può\n   stampare *tutti* i nomi dei rilasci (dello spazio dei nomi `default`), non solo quelli che iniziano con `ngin`.\n; la shell manterrà solo quelli che iniziano con\n   `ngin`.\n2. Per semplificare il supporto al completamento dinamico, specialmente se si ha un plugin complesso, \n   si può fare in modo che lo script `plugin.complete` chiami lo script principale del plugin e richieda le scelte di completamento.\n Si veda la sezione [Completamento dinamico](#completamento-dinamico) per un esempio.\n3. Per eseguire il debug del completamento dinamico e del file `plugin.complete`, si può eseguire il comando\n   seguente per vedere i risultati del completamento:\n    - `helm __complete <nomeplugin> <argomenti da completare>`.  Per esempio:\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`.\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: \"Provenienza e integrità di Helm\"\ndescription: \"Descrive come verificare l'integrità e l'origine di un chart.\"\nweight: 5\n---\n\nHelm dispone di strumenti di provenienza che aiutano gli utenti dei chart a verificare l'integrità e l'origine di un pacchetto. \nUtilizzando 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.\n\n## Panoramica\n\nL'integrità viene stabilita confrontando un chart con un record di provenienza. I record di provenienza\nsono 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\nsarà `myapp-1.2.3.tgz.prov`.\n\nI file di provenienza sono generati al momento dell'impacchettamento (`helm package --sign ...`),\ne possono essere controllati da più comandi, in particolare `helm install --verify`.\n\n## Il flusso di lavoro\n\nQuesta sezione descrive un potenziale flusso di lavoro per utilizzare i dati di provenienza in modo efficace.\n\nPrerequisiti:\n\n- Una coppia di chiavi PGP valida in un formato binario (non in formato ASCII)\n- Lo strumento a riga di comando `helm`\n- Strumenti a riga di comando GnuPG (opzionale)\n- Strumenti a riga di comando Keybase (opzionale)\n\n**NOTA:** Se la vostra chiave privata PGP ha una passphrase, vi sarà richiesto di\n inserire tale passphrase per tutti i comandi che supportano l'opzione `--sign'.\n\nLa creazione di un nuovo chart è identica a quella precedente:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nUna 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\ncorrispondente chiave privata:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**Nota:** Il valore dell'argomento `--key` deve essere una sottostringa del `uid` \ndella chiave desiderata (nell'output di `gpg --list-keys`), ad esempio il nome o l'email. **L'impronta digitale non può essere usata.**\n\n**TIP:** per gli utenti di GnuPG, il portachiavi segreto si trova in `~/.gnupg/secring.gpg`. È possibile\nusare `gpg --list-secret-keys` per elencare le chiavi in proprio possesso.\n\n**Attenzione:** GnuPG v2 memorizza il portachiavi segreto usando un nuovo formato `kbx`nel percorso predefinito `~/.gnupg/pubring.kbx`. Utilizzare il seguente comando\nper convertire il portachiavi nel formato gpg tradizionale:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nA questo punto, si dovrebbero vedere sia `mychart-0.1.0.tgz` che \n`mychart-0.1.0.tgz.prov`. Entrambi i file dovrebbero essere caricati nel repository desiderato.\n\nÈ possibile verificare un chart usando `helm verify`:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nUna verifica fallita si presenta così:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nPer verificare durante un'installazione, usare il flag `--verify`.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nSe 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`.\n\nSe la verifica fallisce, l'installazione verrà interrotta prima che il chart venga\nrenderizzato.\n\n### Utilizzo delle credenziali di Keybase.io\n\nIl 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\nchart.\n\nPrerequisiti:\n\n- Un account Keybase.io configurato\n- GnuPG installato localmente\n- La CLI `keybase` installata localmente\n\n#### Firmare i pacchetti\n\nIl primo passo è importare le chiavi del keybase nel portachiavi GnuPG locale:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nQuesto convertirà la vostra chiave Keybase nel formato OpenPGP, e poi la importerà\nlocalmente nel file `~/.gnupg/secring.gpg`.\n\nSi può verificare eseguendo `gpg --list-secret-keys`.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nSi noti che la chiave segreta avrà una stringa identificativa:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nQuesto è il nome completo della chiave.\n\nSuccessivamente, si può impacchettare e firmare un chart con `helm package`. Assicuratevi di usare almeno\n una parte di questi nomi in `--key`.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nDi conseguenza, il comando `package` dovrebbe produrre sia un file `.tgz` che un file `.tgz.prov`.\n\n#### Verifica dei pacchetti\n\nÈ possibile utilizzare una tecnica simile anche per verificare un chart firmato con la chiave\nKeybase di qualcun altro. Supponiamo di voler verificare un pacchetto firmato da\n`keybase.io/technosophos`. Per farlo, utilizzate lo strumento `keybase`:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nIl primo comando qui sopra traccia l'utente `technosophos`. Successivamente `keybase pgp pull`\nscarica le chiavi OpenPGP di tutti gli account che si seguono, inserendole nel proprio portachiavi GnuPG (`~/.gnupg/pubring.gpg`).\n\nA questo punto, è possibile utilizzare `helm verify` o uno qualsiasi dei comandi con il flag\n`--verify`:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Motivi per cui un chart non può essere verificato\n\nQueste sono le ragioni più comuni del fallimento.\n\n- Il file `.prov' è mancante o corrotto. Questo indica che qualcosa è\n  configurato male o che il manteiner originale non ha creato un file di provenienza.\n- 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.\n- La verifica del file `.prov` non è riuscita. Questo indica che c'è qualcosa di\n  sbagliato nel chart o nei dati di provenienza.\n- Gli hash dei file nel file di provenienza non corrispondono all'hash del file \n  dell'archivio. Ciò indica che l'archivio è stato manomesso.\n\nSe la verifica fallisce, c'è motivo di diffidare del pacchetto.\n\n## Il file di provenienza\n\nIl file di provenienza contiene il file YAML di un chart e diverse informazioni di verifica. I file di provenienza sono progettati per essere\ngenerati automaticamente.\n\nVengono aggiunti i seguenti dati di provenienza:\n\n* Il file del chart (`Chart.yaml`) è incluso per dare sia all'uomo che agli strumenti una facile visione del contenuto del chart.\n* 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.  \n* L'intero corpo del file è firmato con l'algoritmo usato da OpenPGP (vedi\n  [Keybase.io](https://keybase.io) per un modo emergente di rendere semplice la firma crittografica e la verifica).\n\nLa combinazione di questi elementi fornisce agli utenti le seguenti garanzie:\n\n* Il pacchetto stesso non è stato manomesso (checksum del pacchetto `.tgz`).\n* L'entità che ha rilasciato il pacchetto è nota (tramite la firma GnuPG/PGP).\n\nIl formato del file è simile a questo:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nSi 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\nnomi di file e digest SHA-256 del contenuto di quel file al momento del packaging.\n\nIl blocco della firma è una firma PGP standard, che fornisce [resistenza alla manomissione](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Chart Repositories\n\nI chart repository servono come raccolta centralizzata dei chart Helm.\n\nI chart repository devono consentire di fornire i file di provenienza via HTTP tramite una\nuna richiesta specifica e devono renderli disponibili nello stesso percorso URI del chart.\n\nAd 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\n`https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nDal punto di vista dell'utente finale, `helm install --verify myrepo/mychart-1.2.3`\ndovrebbe portare al download sia del chart che del file di provenienza, senza alcuna\nconfigurazione o azione aggiuntiva da parte dell'utente.\n\n### Firme nei registri basati su OCI\n\nSe si pubblicano charts in un [registro basato su OCI]({{< ref \"registries.md\" >}}), si può usare il\n[plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/)  \nper pubblicare la provenienza su [sigstore](https://sigstore.dev/).\n[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.\n\n## Stabilire autorità e autenticità\n\nQuando si ha a che fare con i sistemi a catena di fiducia, è importante essere in grado di\nstabilire l'autorità di un firmatario. O, per dirla in parole povere, il sistema di cui sopra\nsi 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.\n\nUna delle decisioni progettuali di Helm è stata quella di non inserirsi nella catena di fiducia come una parte necessaria. \nNon vogliamo essere\n\"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\ntecnologia di base. Quindi, quando si tratta di stabilire l'autorità, abbiamo\n lasciato questo passo più o meno indefinito in Helm 2 (una decisione portata avanti in\nHelm 3).\n\nTuttavia, abbiamo alcune indicazioni e raccomandazioni per coloro che sono interessati a utilizzare\nil sistema di provenienza:\n\n- La piattaforma [Keybase](https://keybase.io) fornisce un archivio pubblico centralizzato per le informazioni sulla fiducia.\n  \n- È possibile utilizzare Keybase per memorizzare le proprie chiavi o per ottenere le chiavi pubbliche di altri.\n- Keybase ha anche una favolosa documentazione disponibile\n- Anche se non l'abbiamo testata, la funzione \"sito web sicuro\" di Keybase potrebbe essere usata\n    per fornire i chart di Helm.\n- 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.\n- Si è lavorato sull'idea che un elenco di chiavi di firma valide possa essere incluso nel file `index.yaml` di un repository."
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: \"Role-based Access Control\"\ndescription: \"Spiega come Helm interagisce con il Role-Based Access Control di Kubernetes.\"\nweight: 11\n---\n\nIn Kubernetes, l'assegnazione di ruoli a un utente o a un account di servizio specifico per un'applicazione\nè una pratica ottimale per garantire che l'applicazione operi nell'ambito\n specificato. Per saperne di più sui permessi dei service account  leggere la [\ndocumentazione ufficiale di Kubernetes] (https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nA partire da Kubernetes 1.6, il Role-based Access Control è abilitato per impostazione predefinita.\nRBAC consente di specificare quali tipi di azioni sono consentite a seconda dell'utente e del suo ruolo nell'organizzazione.\n\nCon RBAC, è possibile\n\n- concedere operazioni privilegiate (creazione di risorse a livello di cluster, come nuovi ruoli)\n  agli amministratori\n- limitare la capacità di un utente di creare risorse (pod, volumi persistenti,\n  deployment) a specifici namespace o in ambiti a livello di cluster (quote di risorse, ruoli, definizioni di risorse personalizzate).\n- limitare la capacità di un utente di visualizzare le risorse in namespace specifici o a livello di cluster.\n\nQuesta guida è destinata agli amministratori che desiderano limitare l'ambito di interazione di un utente con l'API Kubernetes.\n\n## Gestione degli account utente\n\nTutti i cluster Kubernetes hanno due categorie di utenti: i service accounts gestiti da Kubernetes e gli utenti normali.\n\nSi 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\nAccounts, 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. \nGli utenti normali non possono essere aggiunti a un cluster tramite una chiamata API.\n\nAl contrario, i service account sono utenti gestiti dall'API di Kubernetes. Sono\n vincolati a specifici namespace e creati automaticamente dal server API o\nmanualmente 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\ninteragire con l'API di Kubernetes.\n\nLe richieste API sono legate a un utente normale o a un service account, oppure sono trattate come richieste anonime.\n Questo significa che ogni processo all'interno o all'esterno del\ncluster, dall'utente umano che digita `kubectl` su una workstation, alle kubelets sui nodi, ai membri del sistema di controllo devono autenticarsi quando effettuano richieste\nal server API, o essere trattato come un utente anonimo.\n\n## Ruoli, ClusterRoles, RoleBindings e ClusterRoleBindings\n\nIn 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\nnamespace, 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.\n\nA livello di cluster, questi sono chiamati ClusterRoles e ClusterRoleBindings.\nLa 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).\n\n I ClusterRole possono essere vincolati a un particolare namespace attraverso un riferimento in un\nRoleBinding. I ClusterRoles predefiniti `admin`, `edit` e `view` sono comunemente utilizzati in questo modo.\n\nQuesti sono alcuni ClusterRoles disponibili di default in Kubernetes. Sono\n intesi come ruoli rivolti all'utente. Includono i ruoli di super-utente\n(`cluster-admin`) e ruoli con accesso più granulare (`admin`, `edit`,\n`view`).\n\n| Default ClusterRole | Default ClusterRoleBinding | Description\n|---------------------|----------------------------|-------------\n| `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.\n| `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.\n| `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.\n| `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.\n\n## Limitare l'accesso di un account utente utilizzando RBAC\n\nOra che abbiamo compreso le basi del controllo degli accessi basato sui ruoli, discutiamo di come un amministratore può limitare l'accesso di un utente.\n\n### Esempio: Concedere a un utente l'accesso in lettura/scrittura a un particolare namespace\n\nPer limitare l'accesso di un utente a un particolare namespace, si può usare il ruolo\n`edit` o il ruolo `admin`. Se i vostri chart creano o interagiscono con i Ruoli e i\nRolebindings, si vorrà utilizzare il ClusterRole `admin`.\n\nInoltre, è possibile creare un RoleBinding con accesso `cluster-admin`.\nConcedere 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.\n\nIn questo esempio, creeremo un utente con il ruolo `edit`. Per prima cosa, creare il namespace:\n\n```console\n$ kubectl create namespace foo\n```\n\nOra, creare un RoleBinding in questo namespace, assegnando all'utente il ruolo `edit`.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Esempio: Concedere a un utente l'accesso in lettura/scrittura all'ambito del cluster\n\nSe un utente desidera installare un chart che installa risorse di ambito cluster (namespace, ruoli, definizioni di risorse personalizzate, ecc.) necessita di \naccesso in scrittura all'ambito del cluster.\n\nPer farlo, si deve concedere all'utente l'accesso `admin` o `cluster-admin`.\n\nConcedere a un utente l'accesso `cluster-admin` garantisce l'accesso a tutte le \nrisorse 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.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Esempio: Concedere a un utente l'accesso in sola lettura a un particolare spazio dei nomi\n\nSi 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.\n\nPer poter eseguire `helm list`, un utente deve essere in grado di leggere i secret. Per questo, si creerà uno speciale ClusterRole `secret-reader`.\n\nCreare il file `cluster-role-secret-reader.yaml` e scrivervi il seguente contenuto nel file:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nQuindi, creare il ClusterRole usando\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nUna 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:\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Esempio: Concedere a un utente l'accesso in sola lettura all'ambito del cluster\n\nIn alcuni scenari, può essere utile concedere a un utente l'accesso all'ambito del cluster.\nAd esempio, se un utente vuole eseguire il comando `helm list --all-namespaces`,\nl'API richiede che l'utente abbia accesso in lettura all'ambito del cluster.\n\nPer farlo, si deve concedere all'utente l'accesso `view` e `secret-reader` come descritto sopra, ma con un ClusterRoleBinding.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Riflessioni aggiuntive\n\nGli esempi mostrati sopra utilizzano i ClusterRoles predefiniti forniti con\nKubernetes. Per un controllo più dettagliato sulle risorse a cui gli utenti hanno accesso, si può consultare [la documentazione di Kubernetes\nhttps://kubernetes.io/docs/reference/access-authn-authz/rbac/) sulla creazione di Roles e ClusterRoles personalizzati.\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: \"Utilizzare registry OCI-based\"\ndescription: \"Descrive come utilizzare OCI per la distribuzione dei chart.\"\nweight: 7\n---\n\nA 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. \n\n## Supporto OCI prima della v3.8.0\n\nCon 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.\n\n### Abilitazione del supporto OCI prima della v3.8.0\n\nPrima di Helm v3.8.0, il supporto OCI è *sperimentale* e deve essere abilitato.\n\nPer 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:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### Deprecazione di funzioni OCI e cambiamenti di comportamento con la versione 3.8.0\n\nCon 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:\n\n- Quando si imposta un chart nelle dipendenze come OCI, la versione può essere impostata su un intervallo come le altre dipendenze.\n- 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.\n- 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.\n\n### Deprecazione di funzioni OCI e cambiamenti di comportamento con la v3.7.0\n\nIl 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:\n\n- Il sottocomando `helm chart` è stato rimosso.\n- La cache dei chart è stata rimossa (niente `helm chart list` ecc.).\n- I riferimenti al registry OCI sono ora sempre preceduti da `oci://`.\n- Il nome di base del riferimento al registry deve *sempre* corrispondere al nome del chart.\n- Il tag del riferimento al registry deve *sempre* corrispondere alla versione semantica del chart (quindi nessun tag `latest`).\n- Il tipo di supporto del chart è stato cambiato da `application/tar+gzip` a `application/vnd.cncf.helm.chart.content.v1.tar+gzip`.\n\n\n## Utilizzo di un registry OCI-based\n\n### Helm repositories in registry OCI-based\n\nUn [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.\n\n### Use hosted registries\n\nEsistono diversi registri di container ospitati con supporto OCI che si possono usare per i chart di Helm. Ad esempio:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n  \n\nSeguire la documentazione del fornitore del container registry ospitati per creare e configurare un registry con supporto OCI. \n\n**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.\n\n### Usare sigstore per firmare i chart basati su OCI\n\nIl 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\" >}}).\n\nPer maggiori dettagli sull'uso del plugin `helm sigstore`, vedere [la documentazione del progetto](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md).\n\n## Comandi per lavorare con i registries\n\n### il sottocomando `registry`\n\n#### `login`\n\naccesso a un registry (con inserimento manuale della password)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nlogout da un registry\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### Il sottocomando `push`\n\nCarica un chart in un registry basato su OCI:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nIl sottocomando `push` può essere utilizzato solo per i file `.tgz\ncreati in anticipo con `helm package`.\n\nQuando si usa `helm push` per caricare un chart in un registro OCI, il riferimento\ndeve essere preceduto da `oci://` e non deve contenere il nome di base o il tag.\n\nIl nome di base del registry viene dedotto dal nome del chart,\ne il tag viene dedotto dalla versione semantica del chart. Questo è\nattualmente un requisito rigoroso.\n\nAlcuni registry richiedono che il repository e/o lo spazio dei nomi (se specificato).\nsiano stati creati in precedenza. In caso contrario, verrà prodotto un errore durante l'operazione `helm push`.\n\nSe è stato creato un [file di provenienza] ({{< ref \"provenance.md\" >}}) (`.prov`), ed è presente accanto al file `.tgz` del chart, esso sarà\n automaticamente caricato nel registry al momento del `push`. Questo comporta\nun livello in più nel [Helm chart manifest] (#helm-chart-manifest).\n\nGli utenti del plugin [helm-push](https://github.com/chartmuseum/helm-push) (per caricare i chart su [ChartMuseum]({{< ref \"chart_repository.md\" >}}#chartmuseum-repository-server))\npotrebbe avere dei problemi, poiché il plugin va in conflitto con il nuovo `push` integrato.\nA partire dalla versione v0.10.0, il plugin è stato rinominato in `cm-push`.\n\n### Altri sottocomandi\n\nIl supporto per il protocollo `oci://` è disponibile anche in vari altri sottocomandi.\nEcco un elenco completo:\n\n- `helm pull`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nIl nome di base (nome del chart) del riferimento al registry *è* incluso in ogni tipo di azione che comporta il download di un chart\n(rispetto a `helm push` dove viene omesso).\n\nEcco alcuni esempi di utilizzo dei sottocomandi sopra elencati contro\ngrafici basati su OCI:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Specificare le dipendenze\n\nLe dipendenze di un chart possono essere recuperate da un registry usando il sottocomando `dependency update`.\n\nIl `repository` per una data voce in `Chart.yaml` è specificato come riferimento al registry senza il nome di base:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\nQuesto recupererà `oci://localhost:5000/myrepo/mychart:2.7.0` quando viene eseguito `dependency update`.\n\n## Helm chart manifest\n\nEsempio di manifest del chart Helm rappresentato in un registry\n(notare i campi `mediaType`):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nIl seguente esempio contiene un \n[provenance file]({{< ref \"provenance.md\" >}})\n(notare il layer extra):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Migrazione da un chart repo\n\nLa migrazione dai classici [chart repository]({{< ref \"chart_repository.md\" >}})\n(repository basati su index.yaml) è semplice usando `helm pull`, poi `helm push` per caricare i file `.tgz` in un registry.\n\n\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/release_policy.md",
    "content": "---\ntitle: \"Politica sui rilasci pianificati\"\ndescription: \"Descrive la politica dei programmi di rilascio di Helm.\"\n---\n\nA beneficio dei suoi utenti, Helm definisce e annuncia in anticipo le date di rilascio.\nQuesto documento descrive la politica che regola il programma di rilascio di Helm.\n\n## Calendario dei rilasci\n\nIl calendario pubblico dei prossimi rilasci di Helm è disponibile [qui] (https://helm.sh/calendar/release).\n\n## Versioni semantiche\n\nLe 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\nVersioning](https://semver.org/spec/v2.0.0.html).\n\n## Rilasci di patch\n\nLe patch release forniscono agli utenti correzioni di bug e di sicurezza.  Non\ncontengono nuove funzionalità.\n\nIl rilascio di una nuova patch relativa all'ultima minor/major release avverrà di norma una volta al mese, il secondo mercoledì di ogni mese.\n\nUn rilascio di patch per correggere una regressione ad alta priorità o un problema di sicurezza può essere effettuato ogni volta che è necessario.\n\nIl rilascio di una patch sarà annullato per uno dei seguenti motivi:\n- se non ci sono nuovi contenuti dal rilascio precedente\n- se la data di rilascio della patch cade una settimana prima della release candidate (RC1) di una prossima release minore\n- se la data di rilascio della patch cade entro le quattro settimane successive a una release minore\n\n## Rilasci minori\n\nI rilasci minori contengono correzioni di sicurezza e bug, oltre a nuove funzionalità.  Sono retrocompatibili per quanto riguarda l'API e l'uso della CLI.\n\nPer 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.\n\nIn concomitanza con la pubblicazione di una release, la data della prossima release minore\nsarà annunciata e pubblicata sulla pagina web principale di Helm.\n\n## Rilasci maggiori\n\nLe 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.\n\nLe 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."
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: \"Migrazione Helm da v2 a v3\"\ndescription: \"Scoprite come migrare Helm da v2 a v3.\"\nweight: 13\n---\n\nQuesta guida mostra come migrare Helm da v2 a v3. Helm v2 deve essere installato e gestire le release in uno o più cluster.\n\n## Panoramica dei cambiamenti di Helm 3\n\nL'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\ndi alcuni di questi cambiamenti che l'utente dovrebbe conoscere prima e durante la migrazione:\n\n1. Rimozione di Tiller:\n   - Sostituisce l'architettura client/server con quella client/library (solo binary `helm`).\n   - La sicurezza è ora basata sull'utente (delegata al cluster di utenti Kubernetes). \n   - I rilasci sono ora memorizzati come secrets all'interno del cluster e i metadati dell'oggetto release sono cambiati.\n   - I rilasci sono persistiti in base al namespace della release e non più nel Tiller namespace.\n2. Aggiornamento del repository dei chart:\n   - `helm search` ora supporta sia la ricerca nel repository locale che l'esecuzione di query di ricerca\n nell'Hub degli artefatti\n3. Chart apiVersion spostato a \"v2\" per le modifiche alle specifiche:\n   - Dipendenze del chart collegate dinamicamente spostate in `Chart.yaml`.\n     (`requirements.yaml` rimosso e requisiti --> dipendenze)\n   - I library chart (chart helper/comuni) possono ora essere aggiunti come dipendenze di chart collegati dinamicamente\n   - I chart hanno un campo di metadati `type` per definire che il chart è di tipo\n     \"applicazione\" o \"libreria\". È un'applicazione per impostazione predefinita, il che significa che\n     è renderizzabile e installabile\n   - I chart di Helm 2 (apiVersion=v1) sono ancora installabili.\n4. Aggiunta della specifica di directory XDG:\n   - La home di Helm è stata rimossa e sostituita con una specifica di directory XDG per la memorizzazione dei file di configurazione.\n   - Non è più necessario inizializzare Helm\n   - Rimossi `helm init` e `helm home`.\n5. Ulteriori modifiche:\n   - L'installazione/set-up di Helm è semplificata:\n     - Solo client Helm (helm binary) (senza Tiller).        \n     - Paradigma Run-as-is\n   - i repository `local` o `stable` non sono impostati di default\n   - L'hook `crd-install` è stato rimosso e sostituito con la directory `crds` in chart\ndove tutti i CRD in essa definiti saranno installati prima di qualsiasi rendering del chart.\n   - il valore dell'annotazione del hook `test-failure` è stato rimosso e `test-success` è stato deprecato.\n     Usare invece `test`\n   - Comandi rimossi/sostituiti/aggiunti:\n       - delete --> uninstall : rimuove tutta la cronologia dei rilasci per impostazione predefinita\n         (in precedenza era necessario `--purge`)\n       - fetch --> pull\n       - home (rimosso)\n       - init (rimosso)\n       - install: richiede il nome della release o l'argomento `--generate-name`.\n       - inspect --> show\n       - reset (rimosso)\n       - serve (rimosso)\n       - template: l'argomento `-x`/`--execute` è stato rinominato in `-s`/`--show-only`.\n       - upgrade: Aggiunto l'argomento `--history-max` che limita il numero massimo di revisioni salvate per rilascio (0 per nessun limite)\n   - La libreria Go di Helm 3 ha subito molte modifiche ed è incompatibile con\n     la libreria Helm 2\n   - I binari di rilascio sono ora ospitati su `get.helm.sh`.\n\n## Casi d'uso per migrazione\n\nI casi d'uso della migrazione sono i seguenti:\n\n1. Helm v2 e v3 gestiscono lo stesso cluster:\n   - 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\n     esistenti sono aggiornate/rimosse solo dalla v2.\n   - Helm v2 e v3 possono tranquillamente gestire lo stesso cluster. Le versioni di Helm\n     possono essere installate sullo stesso sistema o su sistemi separati\n   - Se si installa Helm v3 sullo stesso sistema, è necessario eseguire un passaggio aggiuntivo \n     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.\n   \n   - Altrimenti non ci sono conflitti tra le due versioni grazie alle\n     seguenti distinzioni:\n     - I file di archiviazione delle release (cronologia) v2 e v3 sono indipendenti l'uno dall'altro. Le\n       modifiche includono la risorsa Kubernetes per la memorizzazione e i metadati dell'oggetto\n       contenuti nella risorsa. I rilasci saranno anche su un namespace per\n       utente invece di utilizzare namespace di Tiller (ad esempio, v2\n       namespace predefinito di Tiller kube-system). v2 utilizza \"ConfigMaps\" o \"Secrets\"\n       sotto namespace Tiller e la ownership `TILLER`. v3 usa \"Secrets\" nel namespace utente e ownership `helm`. I rilasci sono incrementali sia in\n       v2 e v3\n     - L'unico problema potrebbe esserci se le risorse Kubernetes con scope di cluster (ad es.\n       `clusterroles.rbac`) sono definite in un chart. La distribuzione v3 fallirebbe \n       anche se unico nel namespace, perché le risorse si scontrerebbero.\n     - La configurazione della v3 non usa più `$HELM_HOME` e utilizza invece le specifiche delle directory XDG Viene anche creata al volo, se necessario. È\n       quindi indipendente dalla configurazione v2. Questo è applicabile solo quando\n       entrambe le versioni sono installate sullo stesso sistema\n\n2. Migrazione di Helm v2 a Helm v3:\n   - Questo caso d'uso si applica quando si desidera che Helm v3 gestisca le release Helm v2 esistenti.    \n   - Va notato che un client Helm v2:     \n     - può gestire da 1 a molti cluster Kubernetes\n     - può connettersi a 1 o più istanze di Tiller per un cluster.\n   - Questo significa che bisogna essere consapevoli di questo quando si esegue la migrazione, in quanto le release\n     vengono distribuite nei cluster da Tiller e dal suo namespace. È necessario\n     quindi essere consapevoli della migrazione per ogni cluster e ogni istanza Tiller\n     gestita dall'istanza del client Helm v2.\n   - Il percorso di migrazione dei dati consigliato è il seguente:\n     1. Backup dei dati v2\n     2. Migrare la configurazione di Helm v2\n     3. Migrare le release di Helm v2\n     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\n ci si aspetta, si procede alla pulizia dei dati di Helm v2.\n   - Il processo di migrazione è automatizzato da Helm v3\n     [2to3](https://github.com/helm/helm-2to3).\n\n## Riferimenti\n\n   - Plugin Helm v3 [2to3](https://github.com/helm/helm-2to3)\n   - Blog [post](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)    \nche spiega l'uso del plugin `2to3` con degli esempi\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Helm Version Support Policy\"\ndescription: \"Descrive la politica di rilascio delle patch di Helm e lo scostamento massimo di versione supportato tra Helm e Kubernetes.\"\n---\n\nQuesto documento descrive il massimo scarto di versione supportato tra Helm e\nKubernetes.\n\n## Versioni supportate\n\nLe 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\nVersioning](https://semver.org/spec/v2.0.0.html).\n\nIl progetto Helm mantiene un branch di rilascio per la versione minore più recente.\nLe correzioni applicabili, comprese quelle per la sicurezza, vengono raccolte nel ramo di rilascio, \na seconda della gravità e della fattibilità.\n\n## Sfasamento della versione supportata\n\nQuando viene rilasciata una nuova versione di Helm, questa viene compilata per una particolare\nversione minore di Kubernetes. Ad esempio, Helm 3.0.0 interagisce con Kubernetes\nutilizzando il client Kubernetes 1.16.2, quindi è compatibile con Kubernetes 1.16.\n\nA 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\n2 è leggermente più restrittiva, in quanto si presume che sia compatibile con `n-1` versioni di Kubernetes.\n\nAd esempio, se si utilizza una versione di Helm 3 compilata con la versione client di\nAPI Kubernetes 1.17, allora dovrebbe essere sicuro l'utilizzo con Kubernetes 1.17,\n1.16, 1.15 e 1.14. Se si sta utilizzando una versione di Helm 2 compilata\ncon le API client di Kubernetes 1.16, dovrebbe essere sicuro l'uso con \nKubernetes 1.16 e 1.15.\n\nNon è 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à.\n\nSe si sceglie di utilizzare Helm con una versione di Kubernetes non supportata,\nl'utilizzo avviene a proprio rischio e pericolo.\n\nPer determinare quale versione di Helm è compatibile con il vostro cluster, consultate la tabella seguente.\n\n| Helm Version | Supported Kubernetes Versions |\n|--------------|-------------------------------|\n| 3.16.x       | 1.31.x - 1.28.x               |\n| 3.15.x       | 1.30.x - 1.27.x               |\n| 3.14.x       | 1.29.x - 1.26.x               |\n| 3.13.x       | 1.28.x - 1.25.x               |\n| 3.12.x       | 1.27.x - 1.24.x               |\n| 3.11.x       | 1.26.x - 1.23.x               |\n| 3.10.x       | 1.25.x - 1.22.x               |\n| 3.9.x        | 1.24.x - 1.21.x               |\n| 3.8.x        | 1.23.x - 1.20.x               |\n| 3.7.x        | 1.22.x - 1.19.x               |\n| 3.6.x        | 1.21.x - 1.18.x               |\n| 3.5.x        | 1.20.x - 1.17.x               |\n| 3.4.x        | 1.19.x - 1.16.x               |\n| 3.3.x        | 1.18.x - 1.15.x               |\n| 3.2.x        | 1.18.x - 1.15.x               |\n| 3.1.x        | 1.17.x - 1.14.x               |\n| 3.0.x        | 1.16.x - 1.13.x               |\n| 2.16.x       | 1.16.x - 1.15.x               |\n| 2.15.x       | 1.15.x - 1.14.x               |\n| 2.14.x       | 1.14.x - 1.13.x               |\n| 2.13.x       | 1.13.x - 1.12.x               |\n| 2.12.x       | 1.12.x - 1.11.x               |\n| 2.11.x       | 1.11.x - 1.10.x               |\n| 2.10.x       | 1.10.x - 1.9.x                |\n| 2.9.x        | 1.10.x - 1.9.x                |\n| 2.8.x        | 1.9.x - 1.8.x                 |\n| 2.7.x        | 1.8.x - 1.7.x                 |\n| 2.6.x        | 1.7.x - 1.6.x                 |\n| 2.5.x        | 1.6.x - 1.5.x                 |\n| 2.4.x        | 1.6.x - 1.5.x                 |\n| 2.3.x        | 1.5.x - 1.4.x                 |\n| 2.2.x        | 1.5.x - 1.4.x                 |\n| 2.1.x        | 1.5.x - 1.4.x                 |\n| 2.0.x        | 1.4.x - 1.3.x                 |\n"
  },
  {
    "path": "i18n/it/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"Introduzione\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"How-to\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"Topics\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Best Practices\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"Guida ai Chart Template\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Comandi Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"Community\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"Frequently Asked Questions\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/it/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Helm Project\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"Sviluppo\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"Community\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"Codice sorgente\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"Eventi\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"Codice di condotta\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"Introduzione\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Chart tips & tricks\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"Sviluppo Charts\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"Cerca 800+ Charts\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"Guida alla contribuzione\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"Maintainers\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"Riunioni settimanali\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"GitHub Community\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<p>Siamo un progetto graduated della <a href=\\\"https://www.cncf.io/\\\">Cloud Native Computing Foundation</a>.</p><p>© Helm Authors 2025. Documentazione distribuita sotto licenza <a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0.</a></p><p>© 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  <a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">pagina Uso Marchi Commerciali</a>.</p>\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"CNCF Logo\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/it/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Helm Logo\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"Docs\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"Community\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/ja/code.json",
    "content": "{\n  \"home.about.whatIsHelm\": {\n    \"message\": \"Helmは、Kubernetesアプリケーションの管理を支援します。Helm Chartsは、最も複雑なKubernetesアプリケーションでも定義、インストール、アップグレードができます。\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"message\": \"Chartsは簡単に作成、バージョン管理、共有、公開ができます。Helmを使い始めて、コピー&ペーストをやめましょう。\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Helmは{cncfLink}の卒業プロジェクトで、{helmCommunityLink}によって維持されています。\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"Helmコミュニティ\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"詳細はこちら:\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Helmアーキテクチャ\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"クイックスタートガイド\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"ビデオ: Helmの紹介\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"Helmとは？\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"複雑性の管理\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"message\": \"Chartsは最も複雑なアプリケーションでも記述し、再現可能なアプリケーションのインストールを提供し、単一の権威ポイントとして機能します。\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"簡単なアップデート\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"インプレースアップグレードとカスタムフックで、アップデートの苦痛を取り除きます。\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"シンプルな共有\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"Chartsは簡単にバージョン管理、共有でき、パブリックまたはプライベートサーバーでホストできます。\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"ロールバック\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"{helmRollback}を使用して、リリースの古いバージョンに簡単にロールバックできます。\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"機能\",\n    \"description\": \"Features section title\"\n  },\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"次回の機能リリース\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"バージョン:\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"日付:\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"リリースカレンダー\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"今後のイベント\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"今後のイベント\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"過去のイベント\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"彼らは{meetLink}ツールやプロジェクトのデモと議論を行います。コミュニティミーティングは記録され{youtubeLink}。\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"毎週集まって\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"YouTubeで共有されます\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"開発者スタンドアップ\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"木曜日 9:30-10am (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"これらのミーティングはすべての人に公開されています。メモや詳細については{communityRepoLink}を確認してください。\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"コミュニティリポジトリ\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Helmの使用、Chartsの作業、一般的なエラーの解決に関するディスカッション。\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Helm開発、進行中のPR、リリースなどに関するトピック。\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Helm Chartsのユーザーとコントリビューターのためのディスカッション。\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"Kubernetes Slackチームに参加するには{slackLink}。\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"こちらからアクセスをリクエスト\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"貢献する\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"Helmはプロジェクトへの新しい貢献をいつでも歓迎します！\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"どこから始めればいいですか？\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Helmは多くのユーザーとコントリビューターを持つ大きなプロジェクトです。理解するのは大変かもしれません！\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"助けたいけれどどこから始めればいいかわからない場合は、{goodFirstIssuesLink}のリストがあります。\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"初心者向けのissue\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"何をすればいいですか？\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"コードを貢献する前に、{contributionGuideLink}をお読みください。プルリクエストの作成とレビューのプロセスについて説明しています。\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"貢献ガイド\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"コードを書いた後、Helmが{cncfLink}で使用される{dcoLink}契約に準拠していることを確認するために、{signYourCommitsLink}してください。\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"コミットに署名\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"コミュニティに参加\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Helmプロジェクトと貢献方法に関する詳細情報。\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"はじめに\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"ヘルムを入手！\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"パッケージマネージャーでHelmをインストールするか、{downloadLink}してください。\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"バイナリをダウンロード\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"message\": \"インストールしたら、helmバイナリを解凍してPATHに追加すれば準備完了です！詳細な{installationLink}と{usageLink}については{docsLink}を確認してください。\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"ドキュメント\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"インストール手順\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"使用手順\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"Chartsを入手\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"{artifactHubLink}にアクセスして、多数のパブリックリポジトリから{helmChartsLink}を探索してください。\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"Helm charts\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"Kubernetes用パッケージマネージャー\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Helmは、Kubernetes向けに構築されたソフトウェアを検索、共有、使用するための最良の方法です\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"エラーが発生しました\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"先頭へ戻る\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"アーカイブ\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"アーカイブ\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"ブログ記事一覧のナビゲーション\",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"新しい記事\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"過去の記事\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"ブログ記事のナビゲーション\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"新しい記事\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"過去の記事\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"全てのタグを見る\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"システムモード\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"ライトモード\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"ダークモード\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"ダークモードを切り替える(現在は{mode})\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"パンくずリストのナビゲーション\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"{count}項目\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"ドキュメントページ\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"前へ\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"次へ\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"{count}記事\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"「{tagName}」タグのついた{nDocsTagged}\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"バージョン: {versionLabel}\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"これはリリース前のバージョン{versionLabel}の{siteTitle}のドキュメントです。\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"これはバージョン{versionLabel}の{siteTitle}のドキュメントで現在はメンテナンスされていません\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"最新のドキュメントは{latestVersionLink} ({versionLabel}) を見てください\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"最新バージョン\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"このページを編集\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"{heading} への直接リンク\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \"{date}に\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \"{user}が\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"{atDate}{byUser}最終更新\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"他のバージョン\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"ページが見つかりません\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"タグ:\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"閉じる\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"注意\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"危険\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"備考\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"注記\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"ヒント\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"警告\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"最近のブログ記事のナビゲーション\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"'{label}'の目次を開く\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"'{label}'の目次を隠す\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(新しいタブで開きます)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"ナビゲーション\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"他の言語\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"お探しのページが見つかりませんでした\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"message\": \"このページにリンクしているサイトの所有者にリンクが壊れていることを伝えてください\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"このページの見出し\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"もっと見る\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"{title}についてもっと見る\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"約{readingTime}分\",\n    \"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)\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"コピー\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"コピーしました\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"クリップボードにコードをコピー\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"折り返し\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"ホームページ\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"ドキュメントのサイドバー\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"サイドバーを隠す\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"サイドバーを隠す\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"ナビゲーションバーを閉じる\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← メインメニューに戻る\",\n    \"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)\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"ナビゲーションバーを開く\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"ドロップダウンを開く\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"ドロップダウンを閉じる\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"サイドバーを開く\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"サイドバーを開く\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"{count}件\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"「{tagName}」タグの記事が{nPosts}件あります\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"著者一覧\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"すべての著者を見る\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"この著者による投稿はまだありません。\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"非公開のページ\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"message\": \"このページは非公開です。 検索対象外となり、このページのリンクに直接アクセスできるユーザーのみに公開されます。\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"下書きのページ\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"このページは下書きです。開発環境でのみ表示され、本番環境のビルドには含まれません。\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"もう一度試してください\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"メインコンテンツまでスキップ\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"タグ\",\n    \"description\": \"The title of the tag list page\"\n  }\n}\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"ブログ\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"ブログ\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"すべての投稿\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Helmの使用\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Helmコマンド\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"チャート\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"テンプレートの開発\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"ベストプラクティス\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: 一般的な規約\ndescription: chart の一般的な規約について説明します。\nsidebar_position: 1\n---\n\nベストプラクティスガイドのこの部分では、一般的な規約について説明します。\n\n## chart 名\n\nchart 名は英小文字と数字で構成する必要があります。単語はダッシュ（-）で区切ることが _できます_ 。\n\n例:\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\n英大文字やアンダースコアは chart 名に使用できません。ドットも chart 名には使用しないでください。\n\n## バージョン番号\n\nHelm は可能な限り [SemVer 2](https://semver.org) を使用してバージョン番号を表現します。（Docker イメージタグは必ずしも SemVer に従わないため、この規則の例外と見なされています。）\n\nSemVer バージョンを Kubernetes ラベルに保存する場合、`+` 文字を `_` に置き換える慣習があります。ラベルの値として `+` 記号が許可されていないためです。\n\n## YAML のフォーマット\n\nYAML ファイルは _スペース 2 つ_ でインデントしてください（タブは使用しないでください）。\n\n## Helm と chart という用語の使い方\n\n_Helm_ および _helm_ という用語の使い方にはいくつかの規約があります。\n\n- _Helm_ はプロジェクト全体を指します\n- `helm` はクライアントサイドのコマンドを指します\n- `chart` という用語は固有名詞ではないため、大文字にする必要はありません\n- ただし、ファイル名は大文字小文字を区別するため、`Chart.yaml` は正確に記述する必要があります\n\n迷った場合は、_Helm_（大文字の「H」）を使用してください。\n\n## chart テンプレートと namespace\n\nchart テンプレートの `metadata` セクションで `namespace` プロパティを定義することは避けてください。レンダリングされたテンプレートを適用する namespace は、`--namespace` などのフラグを通じて Kubernetes クライアントへの呼び出し時に指定してください。Helm はテンプレートをそのままレンダリングして、Kubernetes クライアント（Helm 自身、kubectl、flux、spinnaker など）に送信します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: カスタムリソース定義\ndescription: CRDの作成と使用方法について解説します。\nsidebar_position: 7\n---\n\nベストプラクティスガイドのこのセクションでは、カスタムリソース定義オブジェクトの作成と使用方法について説明します。\n\nカスタムリソース定義（CRD）を扱う場合、2つの異なる要素を区別することが重要です。\n\n- CRDの宣言。kind が `CustomResourceDefinition` である YAML ファイルです。\n- CRDを _使用する_ リソース。例えば、CRD が `foo.example.com/v1` を定義するとします。`apiVersion: example.com/v1` かつ kind `Foo` を持つリソースは、その CRD を使用するリソースです。\n\n## リソースを使用する前に CRD 宣言をインストールする\n\nHelm は Kubernetes にできるだけ多くのリソースを高速にロードできるよう最適化されています。Kubernetes は設計上、マニフェストのセット全体を受け取り、それらをすべてオンラインにできます（これは reconciliation loop と呼ばれます）。\n\nしかし CRD には違いがあります。\n\nCRD を使用するには、その CRD の kind を持つリソースを使用する前に、まず CRD の宣言を登録する必要があります。この登録処理には数秒かかることがあります。\n\n### 方法1: `helm` に任せる\n\nHelm 3 の登場により、古い `crd-install` フックは削除され、よりシンプルな方法が採用されました。chart 内に `crds` という特別なディレクトリを作成し、CRD を配置できます。これらの CRD はテンプレート化されませんが、`helm install` を実行するとデフォルトでインストールされます。CRD がすでに存在する場合は、警告とともにスキップされます。CRD のインストール手順をスキップしたい場合は、`--skip-crds` フラグを指定してください。\n\n#### 注意事項（および説明）\n\n現時点では、Helm を使用して CRD をアップグレードまたは削除することはサポートされていません。これは、意図しないデータ損失の危険性があるため、コミュニティで多くの議論が行われた結果、明示的に決定されたものです。さらに、CRD とそのライフサイクルの処理方法については、コミュニティ内でコンセンサスが得られていません。この状況が進展すれば、Helm はこれらのユースケースのサポートを追加する予定です。\n\n`helm install` および `helm upgrade` の `--dry-run` フラグは、CRD ではサポートされていません。ドライランの目的は、chart の出力をサーバーに送信した場合に実際に機能するかを検証することです。しかし、CRD はサーバーの動作を変更するものです。Helm はドライランで CRD をインストールできないため、ディスカバリークライアントはそのカスタムリソース（CR）を認識できず、検証は失敗します。代わりに、CRD を別の chart に分離するか、`helm template` を使用してください。\n\nCRD サポートに関する議論で考慮すべきもう1つの重要な点は、テンプレートのレンダリング処理です。Helm 2 で使用されていた `crd-install` メソッドの明確な欠点の1つは、API の利用可能性が変化するため chart を適切に検証できないことでした（CRD は実際に Kubernetes クラスターに新しい API を追加します）。chart が CRD をインストールすると、`helm` は有効な API バージョンのセットを把握できなくなります。これが CRD のテンプレート化サポートを削除した理由でもあります。新しい `crds` メソッドにより、`helm` がクラスターの現在の状態について完全に有効な情報を持つことが保証されます。\n\n### 方法2: chart を分離する\n\nもう1つの方法は、CRD 定義を1つの chart に配置し、その CRD を使用するリソースを _別の_ chart に配置することです。\n\nこの方法では、各 chart を個別にインストールする必要があります。しかし、このワークフローはクラスターへの管理者アクセス権を持つクラスターオペレーターにとってはより有用な場合があります。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: 依存関係\ndescription: Chart の依存関係に関するベストプラクティスを解説します。\nsidebar_position: 4\n---\n\nベストプラクティスガイドのこの部分では、`Chart.yaml` で宣言する `dependencies` について解説します。\n\n## バージョン\n\n可能な限り、特定のバージョンを固定するのではなく、バージョン範囲を使用してください。\n推奨されるデフォルトの方法は、パッチレベルでのバージョンマッチです:\n\n```yaml\nversion: ~1.2.3\n```\n\nこれはバージョン `1.2.3` およびそのパッチリリースにマッチします。\nつまり、`~1.2.3` は `>= 1.2.3, < 1.3.0` と同等です。\n\nバージョンマッチの完全な構文については、[semver documentation](https://github.com/Masterminds/semver#checking-version-constraints) を参照してください。\n\n### プレリリースバージョン\n\n上記のバージョン制約は、プレリリースバージョンにはマッチしません。\n例えば、`version: ~1.2.3` は `version: ~1.2.4` にマッチしますが、`version: ~1.2.3-1` にはマッチしません。\n以下の書き方で、パッチレベルだけでなくプレリリースにもマッチさせることができます:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### リポジトリ URL\n\n可能な限り `https://` の URL を優先し、次に `http://` の URL を使用してください。\n\nリポジトリがリポジトリインデックスファイルに追加されている場合、リポジトリ名を URL のエイリアスとして使用できます。`alias:` または `@` の後にリポジトリ名を指定してください。\n\nファイル URL（`file://...`）は、固定のデプロイパイプラインで組み立てられた chart 向けの「特殊なケース」と見なされます。\n\n[ダウンローダープラグイン](/topics/plugins.md#downloader-plugins)を使用する場合、URL スキームはプラグイン固有になります。chart を利用するユーザーは、依存関係を更新またはビルドするために、そのスキームに対応したプラグインをインストールする必要があります。\n\n`repository` フィールドが空の場合、Helm は依存関係の管理操作を実行できません。この場合、Helm は依存関係が `charts` フォルダ内のサブディレクトリにあり、そのディレクトリ名が依存関係の `name` プロパティと同じであると見なします。\n\n## condition と tag\n\n**オプションの**依存関係には、condition または tag を追加してください。`condition` はデフォルトで `true` になることに注意してください。\n\ncondition の推奨される書き方:\n\n```yaml\ncondition: somechart.enabled\n```\n\nここで `somechart` は依存関係の chart 名です。\n\n複数のサブチャート（依存関係）が連携してオプションまたは交換可能な機能を提供する場合、これらの chart には同じ tag を設定してください。\n\n例えば、`nginx` と `memcached` の両方が chart 内のメインアプリケーションに対してパフォーマンス最適化を提供し、その機能を有効にするには両方が必要な場合、両方に次のような tags セクションを含めます:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nこれにより、ユーザーは 1 つの tag でその機能のオン・オフを切り替えることができます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx",
    "content": "---\ntitle: ベストプラクティス\nsidebar: true\nsidebar_position: 4\n---\n\n# チャートのベストプラクティスガイド\n\nこのガイドでは、チャートを作成するために Helm チームが検討したベストプラクティスについて説明します。\nチャートの構造に焦点を当てています。\n\n主に、公に展開される可能性のあるチャートのベストプラクティスに焦点を当てています。\n多くのチャートは内部使用のみであることを認識しており、\nそのようなチャートの作成者は、内部の関心がここでの提案をオーバーライドすることに気付く場合があります。\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: ラベルとアノテーション\ndescription: chart でラベルとアノテーションを使用するためのベストプラクティスを解説します。\nsidebar_position: 5\n---\n\nベストプラクティスガイドのこの部分では、chart でのラベルとアノテーションの使い方を説明します。\n\n## ラベルかアノテーションか？\n\nメタデータの項目は、以下の条件に該当する場合はラベルにしてください:\n\n- Kubernetes がリソースを識別するために使用する\n- システムへのクエリ目的でオペレータに公開すると便利である\n\n例えば、オペレータが特定の chart のすべてのインスタンスを簡単に検索できるように、`helm.sh/chart: NAME-VERSION` をラベルとして使用することを推奨します。\n\nメタデータの項目がクエリ目的で使用されない場合は、代わりにアノテーションを使用してください。\n\nHelm hook は常にアノテーションです。\n\n## 標準ラベル\n\n以下の表は、Helm chart が使用する一般的なラベルを定義しています。Helm 自体は特定のラベルの存在を必須としていません。REC とマークされたラベルは推奨であり、一貫性のために chart に含める**べき**です。OPT とマークされたラベルは任意です。これらは慣用的に使用されていますが、運用上必須ではありません。\n\n| 名前 | ステータス | 説明 |\n|------|---------|------|\n| `app.kubernetes.io/name` | REC | アプリ全体を反映する名前です。通常は `{{ template \"name\" . }}` を使用します。多くの Kubernetes マニフェストで使用されており、Helm 固有ではありません。 |\n| `helm.sh/chart` | REC | chart 名とバージョンを設定します: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}` |\n| `app.kubernetes.io/managed-by` | REC | 常に `{{ .Release.Service }}` に設定します。Helm が管理するリソースの検索に使用されます。 |\n| `app.kubernetes.io/instance` | REC | `{{ .Release.Name }}` を設定します。同じアプリケーションの異なるインスタンスを区別するのに役立ちます。 |\n| `app.kubernetes.io/version` | OPT | アプリのバージョンです。`{{ .Chart.AppVersion }}` を設定できます。 |\n| `app.kubernetes.io/component` | OPT | アプリケーション内の役割を示す一般的なラベルです。例: `app.kubernetes.io/component: frontend` |\n| `app.kubernetes.io/part-of` | OPT | 複数の chart やソフトウェアが連携して 1 つのアプリケーションを構成する場合に使用します。例: Web サイトを構成するアプリケーションとデータベース。サポートするトップレベルのアプリケーションを設定できます。 |\n\n`app.kubernetes.io` プレフィックスが付いた Kubernetes ラベルの詳細については、[Kubernetes のドキュメント](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)を参照してください。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pod と PodTemplate\ndescription: chart マニフェストにおける Pod と PodTemplate 部分のフォーマットについて説明します。\nsidebar_position: 6\n---\n\nベストプラクティスガイドのこの部分では、chart マニフェストにおける Pod と PodTemplate 部分のフォーマットについて説明します。\n\n以下のリソース（網羅的ではありません）が PodTemplate を使用します:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## イメージ\n\nコンテナイメージには固定されたタグ、またはイメージの SHA を使用してください。`latest`、`head`、`canary` など、常に最新を指すフローティングタグは使用しないでください。\n\nイメージを `values.yaml` ファイルに定義しておくと、簡単に差し替えられます。\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nイメージとタグを `values.yaml` で別々のフィールドとして定義することもできます:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` は、`deployment.yaml` で以下のように記述することで、`imagePullPolicy` をデフォルトで `IfNotPresent` に設定します:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\n`values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\n同様に、Kubernetes も `imagePullPolicy` が定義されていない場合、デフォルトで `IfNotPresent` を使用します。`IfNotPresent` 以外の値が必要な場合は、`values.yaml` の値を希望する値に更新してください。\n\n## PodTemplate には selector を宣言する\n\nすべての PodTemplate セクションで selector を指定してください。例:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nselector を指定することで、ワークロードリソースと Pod の関係が明確になり、推奨されるプラクティスです。\n\nDeployment などのワークロードリソースでは、これは特に重要です。selector を指定しないと、**すべての**ラベルが一致する Pod の選択に使用されます。バージョンやリリース日など変化するラベルを使用している場合、意図しない動作を引き起こす可能性があります。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: ロールベースアクセス制御\ndescription: Chart マニフェストにおける RBAC リソースの作成とフォーマットについて解説します。\nsidebar_position: 8\n---\n\nベストプラクティスガイドのこの部分では、chart マニフェストにおける RBAC リソースの作成とフォーマットについて解説します。\n\nRBAC リソースには以下が含まれます:\n\n- ServiceAccount（namespace スコープ）\n- Role（namespace スコープ）\n- ClusterRole\n- RoleBinding（namespace スコープ）\n- ClusterRoleBinding\n\n## YAML の設定\n\nRBAC と ServiceAccount の設定は、別々のキーで管理してください。\nこれらは異なる概念であり、YAML 内で分離することで明確になります。\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\nこの構造は、複数の ServiceAccount を必要とするより複雑な chart にも拡張できます。\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## RBAC リソースはデフォルトで作成する\n\n`rbac.create` は RBAC リソースを作成するかどうかを制御するブール値です。\nデフォルト値は `true` にしてください。\nRBAC のアクセス制御を自分で管理したいユーザーは、この値を `false` に設定できます（その場合は以下を参照）。\n\n## RBAC リソースの使用\n\n`serviceAccount.name` には、chart が作成するアクセス制御対象リソースで使用する ServiceAccount の名前を設定します。\n\n- `serviceAccount.create` が true の場合: この名前で ServiceAccount が作成されます。名前が設定されていない場合は、`fullname` テンプレートを使用して名前が生成されます。\n- `serviceAccount.create` が false の場合: ServiceAccount は作成されませんが、同じリソースに関連付けられたままにしておく必要があります。これにより、後で手動で作成した RBAC リソースがこの ServiceAccount を参照しても正しく機能します。名前が指定されていない場合は、デフォルトの ServiceAccount が使用されます。\n\nServiceAccount には以下のヘルパーテンプレートを使用してください。\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: テンプレート\ndescription: テンプレートに関するベストプラクティスを詳しく解説します。\nsidebar_position: 3\n---\n\nベストプラクティスガイドのこの部分では、テンプレートについて焦点を当てます。\n\n## `templates/` の構造\n\n`templates/` ディレクトリは次のように構造化してください:\n\n- YAML を出力するテンプレートファイルには `.yaml` 拡張子を使用します。\n  フォーマットされた内容を出力しないテンプレートファイルには `.tpl` 拡張子を使用できます。\n- テンプレートファイル名はキャメルケースではなく、ダッシュ記法（`my-example-configmap.yaml`）\n  を使用します。\n- 各リソース定義は個別のテンプレートファイルに配置します。\n- テンプレートファイル名にはリソースの種類を含めます。\n  例: `foo-pod.yaml`、`bar-svc.yaml`\n\n## 定義済みテンプレートの名前\n\n定義済みテンプレート（`{{ define }}` ディレクティブ内で作成されたテンプレート）は\nグローバルにアクセス可能です。つまり、chart とそのすべてのサブチャートから、\n`{{ define }}` で作成されたすべてのテンプレートにアクセスできます。\n\nそのため、_すべての定義済みテンプレート名には namespace を含めてください。_\n\n正しい書き方:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\n正しくない書き方:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\n\n新しい chart は `helm create` コマンドで作成することを強く推奨します。\nこのコマンドを使用すると、テンプレート名がこのベストプラクティスに従って自動的に定義されます。\n\n## テンプレートのフォーマット\n\nテンプレートは _2 つのスペース_ でインデントします（タブは使用しません）。\n\nテンプレートディレクティブでは、開き中括弧の後と閉じ中括弧の前にスペースを入れます:\n\n正しい書き方:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\n正しくない書き方:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\n可能な場合、テンプレートでは空白を削除します:\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nブロック（制御構造など）は、テンプレートコードのフローを示すために\nインデントできます。\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nただし、YAML は空白に依存する言語であるため、コードのインデントが\nこの規則に従えない場合もあります。\n\n## 生成されるテンプレートの空白\n\n生成されるテンプレートに含まれる空白の量は最小限に抑えるのが望ましいです。\n特に、複数の空行が連続して並ぶべきではありません。\nただし、論理的なセクション間などで時折空行を入れることは問題ありません。\n\nベストな書き方:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\n問題のない書き方:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\n避けるべき書き方:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## コメント（YAML コメント vs. テンプレートコメント）\n\nYAML と Helm テンプレートの両方にコメント記法があります。\n\nYAML コメント:\n```yaml\n# This is a comment\ntype: sprocket\n```\n\nテンプレートコメント:\n```yaml\n{{- /*\nThis is a comment.\n*/}}\ntype: frobnitz\n```\n\nテンプレートコメントは、テンプレートの機能を文書化する際に使用します。\nたとえば、定義済みテンプレートを説明する場合:\n\n```yaml\n{{- /*\nmychart.shortname provides a 6 char truncated version of the release name.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nテンプレート内で YAML コメントを使用するのは、Helm ユーザーがデバッグ中に\nそのコメントを見ると便利な場合です。\n\n```yaml\n# This may cause problems if the value is more than 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\n上記のコメントは、ユーザーが `helm install --debug` を実行したときに表示されます。\n一方、`{{- /* */}}` セクションで指定されたコメントは表示されません。\n\n特定のテンプレート関数で必要になる可能性のある Helm 値を含むテンプレートセクションに\n`#` YAML コメントを追加する際は注意してください。\n\nたとえば、上記の例に `required` 関数を導入し、`maxMem` が設定されていない場合、\n`#` YAML コメントはレンダリングエラーを引き起こします。\n\n正しい書き方: `helm template` はこのブロックをレンダリングしません\n```yaml\n{{- /*\n# This may cause problems if the value is more than 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\n正しくない書き方: `helm template` は `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` を返します\n```yaml\n# This may cause problems if the value is more than 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nYAML コメントがそのまま残される動作の別の例については、\n[テンプレートのデバッグ](/chart_template_guide/debugging.md)を参照してください。\n\n## テンプレートとテンプレート出力での JSON の使用\n\nYAML は JSON のスーパーセットです。場合によっては、JSON 構文の方が\n他の YAML 表現よりも読みやすいことがあります。\n\nたとえば、この YAML は通常の YAML のリスト表現方法に近いです:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nしかし、JSON リストスタイルに折りたたむと読みやすくなります:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\n可読性を高めるために JSON を使用することは良い方法です。ただし、JSON 構文は\nより複雑な構造を表現するために使用すべきではありません。\n\nYAML 内に純粋な JSON を埋め込む場合（init コンテナの設定など）は、\nもちろん JSON フォーマットを使用するのが適切です。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: 値\ndescription: どのように値を設定するかを解説します。\nsidebar_position: 2\n---\n\nベストプラクティスガイドのこの部分では、値の設定方法を解説します。\nチャートの`values.yaml`の書き方に重点を置いて、値を構造化して利用するおすすめの方法を解説します。\n\n## 命名規則\n\n変数名は小文字で始める必要があります。また、単語はキャメルケースで区切ってください。\n\n正しい書き方:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\n正しくない書き方:\n\n```yaml\nChicken: true  # 最初を大文字にすると組み込み変数と衝突することがあります\nchicken-noodle-soup: true # ハイフンは使わないでください\n```\n\nユーザー定義のパラメータと区別しやすくするため、Helmの全ての組み込み変数は大文字で始まります。\n例: `.Release.Name`、`.Capabilities.KubeVersion`\n\n## フラット・ネスト構造の値\n\nYAMLは柔軟な形式なので、値を深くネストすることも、フラットにすることもできます。\n\nネスト:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nフラット:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nほとんどの場合、ネストよりフラットな方が好まれます。フラットな方がテンプレートの開発者・ユーザーがよりシンプルに理解できるからです。\n\nネストされた値を安全に扱うためには、全ての階層で値をチェックする必要があります。\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nネストされた全ての階層では値が存在するかをチェックする必要があります。\nその一方でフラット構成の場合、このようなチェックをせずにテンプレートを読みやすく、使いやすくすることができます。\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\n関連する変数が多数あり、そのうちの少なくとも1つが必須の変数である場合は、\n読みやすさを向上させるためにネストされた値を使うことがあります。\n\n## 型の明確化\n\nYAMLの型強制ルールは直感に反することがあります。例えば `foo: false`と \n`foo: \"false\"`は同じではありません。`foo: 12345678` のように大きな整数は、\n科学的表記に変換される場合があります。\n\n型変換エラーを回避する最も簡単な方法は、文字列は明示的に扱い、その他全ては暗黙的に扱うことです。\n簡潔に言えば、_すべての文字列をクォートする_ ということです。\n\n多くの場合、整数キャストの問題を回避するには整数を文字列として格納し、\nテンプレートで`{{ int $value }}`のように使用して文字列から整数に戻すと便利です。\n\nほとんどの場合、明示的な型のタグが優先されるため、`foo: !!string 1234`は文字列の`1234`として扱われます。\n_ただし_、YAMLパーサーはタグを消費してしまうので、パースされた後は型情報が失われます。\n\n## ユーザーがどのように値を扱うかについて考える\n\n値は3つの方法で設定することができます。\n\n- チャートの`values.yaml`ファイル\n- `helm install -f`、`helm upgrade -f`で渡されるファイル\n- `helm install`、`helm upgrade`の`--set`、`--set-string` フラグで渡される値\n\n値の構造を設計するときは、ユーザーが`-f`フラグや`--set`オプションで\n値を上書きしたい場合があることに注意してください。\n\n`--set`が一番表現力が制限されているので、`values.yaml`を書くにあたって最初に考えるべきことは、\n`--set`で簡単に上書きできるようにすることです。\n\nそのような理由から、大抵の場合はマップを使用して値を構造化するほうがよいです。\n\n`--set`の利用が難しい例:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\n上の例は、Helm `<=2.4` では `--set` で表現できません。Helm 2.5では fooのportを\n`--set servers[0].port=80`と書くことができます。ユーザーが理解しにくいだけでなく、\n後に`servers`の順番が変更されたときにエラーが発生しやすくなります。\n\n使いやすい例:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nfooのportへのアクセスは非常に明確です: `--set servers.foo.port=80`\n\n## `values.yaml`のドキュメント\n\n`values.yaml`で定義された全てのプロパティは文書化されているべきです。\n説明文は説明するプロパティ名で始めて、少なくとも1文以上書いてください。\n\n正しくない例:\n\n```yaml\n# the host name for the webserver\nserverHost: example\nserverPort: 9191\n```\n\n正しい例:\n\n```yaml\n# serverHost is the host name for the webserver\nserverHost: example\n# serverPort is the HTTP listener port for the webserver\nserverPort: 9191\n```\n\n各コメントをパラメータ名で始めるとドキュメントをgrepするのが簡単になるのに加え、\n文書化ツールが説明文をパラメータと確実に紐付けることができるようになります。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: テンプレート内からファイルにアクセスする\ndescription: テンプレート内からファイルにアクセスする方法について説明します。\nsidebar_position: 10\n---\n\n前のセクションでは、名前付きテンプレートを作成してアクセスするいくつかの方法を説明しました。これにより、あるテンプレートから別のテンプレートを簡単にインポートできます。しかし、_テンプレートではないファイル_ をインポートして、テンプレートレンダリングエンジンを通さずにその内容を挿入したい場合もあります。\n\nHelm では、`.Files` オブジェクトを通じてファイルにアクセスできます。テンプレートの例に入る前に、この機能の仕組みについていくつか注意事項があります:\n\n- Helm chart に追加のファイルを含めることができます。これらのファイルは chart にバンドルされます。ただし、Kubernetes オブジェクトのストレージ制限があるため、chart は 1M 未満でなければなりません。\n- セキュリティ上の理由から、一部のファイルは `.Files` オブジェクトからアクセスできません。\n  - `templates/` ディレクトリ内のファイルにはアクセスできません。\n  - `.helmignore` で除外されたファイルにはアクセスできません。\n  - Helm アプリケーションの[サブチャート](/chart_template_guide/subcharts_and_globals.md)外のファイル（親 chart のファイルを含む）にはアクセスできません。\n- chart は UNIX モード情報を保持しません。そのため、ファイルレベルのパーミッションは `.Files` オブジェクトを通じたファイルの利用可否に影響しません。\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [基本的な例](#basic-example)\n- [パスヘルパー](#path-helpers)\n- [Glob パターン](#glob-patterns)\n- [ConfigMap と Secret のユーティリティ関数](#configmap-and-secrets-utility-functions)\n- [エンコーディング](#encoding)\n- [行ごとの処理](#lines)\n\n<!-- tocstop -->\n\n## 基本的な例 {#basic-example}\n\n以上の注意事項を踏まえ、3 つのファイルを読み込んで ConfigMap に格納するテンプレートを作成します。まず、chart に 3 つのファイルを追加し、すべて `mychart/` ディレクトリ直下に配置します。\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nこれらは簡単な TOML ファイルです（昔の Windows INI ファイルのようなものです）。ファイル名がわかっているので、`range` 関数を使ってループし、内容を ConfigMap に挿入できます。\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nこの ConfigMap は、前のセクションで説明したいくつかのテクニックを使用しています。たとえば、`.Files` オブジェクトへの参照を保持する `$files` 変数を作成しています。また、`tuple` 関数を使用してループ対象のファイルリストを作成しています。そして、各ファイル名（`{{ . }}: |-`）とその内容（`{{ $files.Get . }}`）を出力しています。\n\nこのテンプレートを実行すると、3 つすべてのファイル内容を含む単一の ConfigMap が生成されます:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## パスヘルパー {#path-helpers}\n\nファイルを扱う際、ファイルパス自体に対して標準的な操作を行うと便利なことがあります。Helm は Go の [path](https://golang.org/pkg/path/) パッケージの関数を多数インポートしており、これらを利用できます。Go パッケージと同じ名前で、先頭の文字が小文字になっています。たとえば、`Base` は `base` になります。\n\nインポートされている関数は以下の通りです:\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Glob パターン {#glob-patterns}\n\nchart が大きくなるにつれて、ファイルをより整理する必要が出てくることがあります。そのため、[glob パターン](https://godoc.org/github.com/gobwas/glob)の柔軟性を活かして特定のファイルを抽出できる `Files.Glob(pattern string)` メソッドを提供しています。\n\n`.Glob` は `Files` 型を返すため、返されたオブジェクトに対して `Files` のメソッドを呼び出せます。\n\nたとえば、次のようなディレクトリ構造があるとします:\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nGlob ではいくつかのオプションがあります:\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nまたは\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## ConfigMap と Secret のユーティリティ関数 {#configmap-and-secrets-utility-functions}\n\n（Helm 2.0.2 以降で利用可能）\n\nファイルの内容を ConfigMap と Secret の両方に配置し、実行時に Pod にマウントしたいことがよくあります。これを支援するため、`Files` 型にいくつかのユーティリティメソッドを提供しています。\n\nさらに整理するために、これらのメソッドを `Glob` メソッドと組み合わせて使用すると特に便利です。\n\n[Glob パターン](#glob-patterns)の例で示したディレクトリ構造を使用すると:\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## エンコーディング {#encoding}\n\nファイルをインポートして、転送の成功を確実にするために Base64 エンコードすることができます:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\n上記は、前に使用した同じ `config1.toml` ファイルをエンコードします:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## 行ごとの処理 {#lines}\n\nテンプレート内でファイルの各行にアクセスしたい場合があります。このために便利な `Lines` メソッドを提供しています。\n\n`range` 関数を使用して `Lines` をループ処理できます:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\n`helm install` 時に chart 外部からファイルを渡す方法はありません。そのため、ユーザーにデータを提供してもらう場合は、`helm install -f` または `helm install --set` を使用して読み込む必要があります。\n\nこの説明で、Helm テンプレートを作成するためのツールとテクニックの解説は終わりです。次のセクションでは、特別なファイル `templates/NOTES.txt` を使用して、chart のユーザーにインストール後の手順を送信する方法を説明します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: 組み込みオブジェクト\ndescription: テンプレートで利用可能な組み込みオブジェクトについて説明します。\nsidebar_position: 3\n---\n\nオブジェクトはテンプレートエンジンからテンプレートに渡されます。コード内でオブジェクトを受け渡すこともできます（`with` 文や `range` 文で例を見ていきます）。また、`tuple` 関数など、テンプレート内で新しいオブジェクトを作成する方法もいくつかあります。\n\nオブジェクトは単純なもので、単一の値だけを持つこともあります。あるいは、他のオブジェクトや関数を含むこともできます。たとえば、`Release` オブジェクトは複数のオブジェクト（`Release.Name` など）を含み、`Files` オブジェクトはいくつかの関数を持っています。\n\n前のセクションでは、`{{ .Release.Name }}` を使用して release 名をテンプレートに挿入しました。`Release` は、テンプレート内でアクセスできるトップレベルオブジェクトの一つです。\n\n- `Release`: release 自体を表すオブジェクトです。内部にいくつかのオブジェクトを持っています:\n  - `Release.Name`: release 名\n  - `Release.Namespace`: release 先の namespace（マニフェストで上書きされない場合）\n  - `Release.IsUpgrade`: 現在の操作がアップグレードまたはロールバックの場合、`true` に設定されます。\n  - `Release.IsInstall`: 現在の操作がインストールの場合、`true` に設定されます。\n  - `Release.Revision`: この release のリビジョン番号。インストール時は 1 で、アップグレードやロールバックごとに増加します。\n  - `Release.Service`: 現在のテンプレートをレンダリングしているサービス。Helm では常に `Helm` です。\n- `Values`: `values.yaml` ファイルおよびユーザー指定のファイルからテンプレートに渡される値。デフォルトでは `Values` は空です。\n- `Chart`: `Chart.yaml` ファイルの内容。`Chart.yaml` 内のすべてのデータにアクセスできます。たとえば、`{{ .Chart.Name }}-{{ .Chart.Version }}` は `mychart-0.1.0` のように出力されます。\n  - 利用可能なフィールドの一覧は [Chart ガイド](/topics/charts.md#the-chartyaml-file) を参照してください。\n- `Subcharts`: サブチャートのスコープ（.Values、.Charts、.Releases など）に親 chart からアクセスできます。たとえば、`.Subcharts.mySubChart.myValue` で `mySubChart` chart 内の `myValue` にアクセスできます。\n- `Files`: chart 内の特殊ファイル以外のすべてのファイルにアクセスできます。テンプレートへのアクセスには使用できませんが、chart 内の他のファイルにアクセスするために使用できます。詳細は[ファイルへのアクセス](/chart_template_guide/accessing_files.md)のセクションを参照してください。\n  - `Files.Get` は名前でファイルを取得する関数です（`.Files.Get config.ini`）。\n  - `Files.GetBytes` はファイルの内容を文字列ではなくバイト配列として取得する関数です。画像などに便利です。\n  - `Files.Glob` は指定したシェルの glob パターンに一致する名前のファイルリストを返す関数です。\n  - `Files.Lines` はファイルを1行ずつ読み込む関数です。ファイル内の各行を反復処理するのに便利です。\n  - `Files.AsSecrets` はファイルの内容を Base 64 エンコードされた文字列として返す関数です。\n  - `Files.AsConfig` はファイルの内容を YAML マップとして返す関数です。\n- `Capabilities`: Kubernetes クラスターがサポートする機能に関する情報を提供します。\n  - `Capabilities.APIVersions` はバージョンのセットです。\n  - `Capabilities.APIVersions.Has $version` は、バージョン（例: `batch/v1`）またはリソース（例: `apps/v1/Deployment`）がクラスターで利用可能かどうかを示します。\n  - `Capabilities.KubeVersion` と `Capabilities.KubeVersion.Version` は Kubernetes のバージョンです。\n  - `Capabilities.KubeVersion.Major` は Kubernetes のメジャーバージョンです。\n  - `Capabilities.KubeVersion.Minor` は Kubernetes のマイナーバージョンです。\n  - `Capabilities.HelmVersion` は Helm のバージョン詳細を含むオブジェクトで、`helm version` の出力と同じです。\n  - `Capabilities.HelmVersion.Version` は semver 形式の現在の Helm バージョンです。\n  - `Capabilities.HelmVersion.GitCommit` は Helm の git sha1 です。\n  - `Capabilities.HelmVersion.GitTreeState` は Helm の git ツリーの状態です。\n  - `Capabilities.HelmVersion.GoVersion` は使用されている Go コンパイラのバージョンです。\n- `Template`: 現在実行中のテンプレートに関する情報を含みます。\n  - `Template.Name`: 現在のテンプレートへの namespace を含むファイルパス（例: `mychart/templates/mytemplate.yaml`）\n  - `Template.BasePath`: 現在の chart の templates ディレクトリへの namespace を含むパス（例: `mychart/templates`）。\n\n組み込み値は常に大文字で始まります。これは Go の命名規則に従っています。独自の名前を作成する場合は、チームに合った規則を自由に使用できます。[Artifact Hub](https://artifacthub.io/packages/search?kind=0) で見られる多くの chart を作成しているチームのように、一部のチームでは、組み込みの名前とローカルの名前を区別するために、小文字で始めることを選択しています。このガイドでは、その規則に従います。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: フロー制御\ndescription: テンプレート内のフロー構造について概説します。\nsidebar_position: 7\n---\n\n制御構造（テンプレート用語では「アクション」と呼ばれます）を使うと、テンプレートの生成フローを制御できます。Helm のテンプレート言語では、以下の制御構造を提供しています:\n\n- `if`/`else`: 条件分岐ブロックの作成\n- `with`: スコープの指定\n- `range`: 「for each」スタイルのループ\n\nこれらに加えて、名前付きテンプレートセグメントを宣言・使用するためのアクションもあります:\n\n- `define`: テンプレート内で新しい名前付きテンプレートを宣言\n- `template`: 名前付きテンプレートをインポート\n- `block`: 埋め込み可能な特殊なテンプレート領域を宣言\n\nこのセクションでは、`if`、`with`、`range` について解説します。その他のアクションについては、本ガイドの後半にある「名前付きテンプレート」セクションで説明します。\n\n## If/Else\n\n最初に紹介する制御構造は、テンプレート内で条件付きのテキストブロックを含めるためのものです。これが `if`/`else` ブロックです。\n\n条件分岐の基本構文は次のとおりです:\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\nここでは値ではなく _パイプライン_ について説明しています。これは、制御構造が単に値を評価するだけでなく、パイプライン全体を実行できることを明示するためです。\n\nパイプラインは以下の場合に _false_ として評価されます:\n\n- boolean の false\n- 数値のゼロ\n- 空文字列\n- `nil`（空または null）\n- 空のコレクション（`map`、`slice`、`tuple`、`dict`、`array`）\n\nこれら以外の条件では、すべて true として評価されます。\n\nConfigMap に簡単な条件分岐を追加してみましょう。drink が coffee に設定されている場合に、別の設定を追加します:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\n前の例で `drink: coffee` をコメントアウトしていたため、出力には `mug: \"true\"` フラグは含まれません。しかし、`values.yaml` ファイルにその行を戻すと、出力は次のようになります:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## ホワイトスペースの制御\n\n条件分岐を見ているうちに、テンプレート内でホワイトスペースがどのように制御されるかを簡単に確認しておきましょう。前の例を読みやすいように整形してみます:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\n一見よさそうに見えます。しかし、テンプレートエンジンを通すと、残念な結果になります:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\n何が起きたのでしょうか? 上記のホワイトスペースが原因で、不正な YAML が生成されました。\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` のインデントが正しくありません。この行のインデントを減らして、再実行してみましょう:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nこれを実行すると、有効な YAML が得られますが、まだ少し見た目がおかしいです:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nYAML に空行がいくつか含まれています。なぜでしょうか? テンプレートエンジンは `{{` と `}}` の間の内容を _削除_ しますが、残りのホワイトスペースはそのまま残します。\n\nYAML ではホワイトスペースに意味があるため、その管理は非常に重要です。幸い、Helm テンプレートにはこれを支援するツールがいくつかあります。\n\nまず、テンプレート宣言の波括弧構文を特殊文字で修飾して、テンプレートエンジンにホワイトスペースを削除するよう指示できます。`{{- `（ダッシュとスペースを追加）は左側のホワイトスペースを削除することを示し、` -}}` は右側のホワイトスペースを削除することを意味します。_注意: 改行もホワイトスペースです!_\n\n> `-` とディレクティブの残りの部分の間には必ずスペースを入れてください。`{{- 3 }}` は「左側のホワイトスペースを削除して 3 を出力する」ことを意味しますが、`{{-3 }}` は「-3 を出力する」ことを意味します。\n\nこの構文を使って、テンプレートを修正して空行を削除しましょう:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nこのポイントを明確にするために、上記を調整して、このルールに従って削除されるホワイトスペースを `*` で置き換えてみましょう。行末の `*` は削除される改行文字を表します。\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nこれを念頭に置いて、テンプレートを Helm で実行すると、結果は次のようになります:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nホワイトスペース削除修飾子には注意が必要です。次のような間違いをしやすいです:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nこれは `food: \"PIZZA\"mug: \"true\"` を出力します。両側の改行が削除されたためです。\n\n> テンプレートでのホワイトスペース制御の詳細については、[Go テンプレートの公式ドキュメント](https://godoc.org/text/template)を参照してください。\n\n最後に、テンプレートディレクティブのスペースを調整するよりも、テンプレートシステムにインデントを指示する方が簡単な場合があります。そのような場合は、`indent` 関数（`{{ indent 2 \"mug:true\" }}`）が便利です。\n\n## `with` によるスコープの変更\n\n次に紹介する制御構造は `with` アクションです。これは変数のスコープを制御します。`.` は _現在のスコープ_ への参照であることを思い出してください。したがって `.Values` は、現在のスコープで `Values` オブジェクトを探すようにテンプレートに指示します。\n\n`with` の構文は単純な `if` 文に似ています:\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\nスコープは変更できます。`with` を使うと、現在のスコープ（`.`）を特定のオブジェクトに設定できます。たとえば、これまで `.Values.favorite` を使って作業してきました。`.` スコープが `.Values.favorite` を指すように ConfigMap を書き換えてみましょう:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\n前の演習から `if` 条件を削除しました。`PIPELINE` の値が空でない場合にのみ `with` の後のブロックが実行されるため、もう不要です。\n\n`.drink` と `.food` を修飾なしで参照できるようになったことに注目してください。これは `with` 文が `.` を `.Values.favorite` を指すように設定したためです。`.` は `{{ end }}` の後に元のスコープにリセットされます。\n\nただし注意が必要です! 制限されたスコープ内では、`.` を使って親スコープの他のオブジェクトにアクセスできません。たとえば、以下のコードは失敗します:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` が `.` の制限されたスコープ内にないため、エラーが発生します。しかし、最後の 2 行を入れ替えると、`{{ end }}` の後にスコープがリセットされるため、すべて期待どおりに動作します:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nまたは、`$` を使って親スコープから `Release.Name` オブジェクトにアクセスできます。`$` はテンプレート実行開始時にルートスコープにマップされ、テンプレート実行中に変更されません。以下のコードも動作します:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\n`range` を見た後、上記のスコープ問題に対する解決策の 1 つであるテンプレート変数について説明します。\n\n## `range` アクションによるループ\n\n多くのプログラミング言語では、`for` ループ、`foreach` ループ、または同様の仕組みを使ったループをサポートしています。Helm のテンプレート言語では、`range` 演算子を使ってコレクションを反復処理します。\n\nまず、`values.yaml` ファイルにピザのトッピングリストを追加しましょう:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nこれで `pizzaToppings` のリスト（テンプレートでは `slice` と呼ばれます）ができました。このリストを ConfigMap に出力するようにテンプレートを変更しましょう:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\n`$` を使って親スコープから `Values.pizzaToppings` リストにアクセスすることもできます。`$` はテンプレート実行開始時にルートスコープにマップされ、テンプレート実行中に変更されません。以下のコードも動作します:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\n`toppings:` リストを詳しく見てみましょう。`range` 関数は `pizzaToppings` リストを反復処理します。ここで興味深いことが起こります。`with` が `.` のスコープを変更するのと同様に、`range` 演算子もスコープを変更します。ループの各イテレーションで、`.` は現在のピザトッピングに設定されます。最初のイテレーションでは `.` は `mushrooms` になります。2 回目は `cheese`、以降同様に続きます。\n\n`.` の値を直接パイプラインに送ることができるので、`{{ . | title | quote }}` と書くと、`.` を `title`（タイトルケース関数）に送り、次に `quote` に送ります。このテンプレートを実行すると、出力は次のようになります:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nこの例では少しトリッキーなことをしています。`toppings: |-` 行は複数行の文字列を宣言しています。したがって、トッピングのリストは実際には YAML のリストではなく、大きな文字列です。なぜこうするのでしょうか? ConfigMap の `data` はキー/値のペアで構成され、キーと値はどちらも単純な文字列だからです。この詳細については [Kubernetes ConfigMap ドキュメント](https://kubernetes.io/docs/concepts/configuration/configmap/)を参照してください。ただし、ここではそれほど重要ではありません。\n\n> YAML の `|-` マーカーは複数行の文字列を取ります。これは、この例のようにマニフェスト内に大きなデータブロックを埋め込むのに便利なテクニックです。\n\nテンプレート内で素早くリストを作成し、そのリストを反復処理したい場合があります。Helm テンプレートにはこれを簡単にする関数 `tuple` があります。コンピュータサイエンスでは、タプルは固定サイズのリスト形式のコレクションですが、任意のデータ型を持つことができます。これは `tuple` の使い方を大まかに表しています。\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\n上記は次のように出力されます:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nリストやタプルに加えて、`range` はキーと値を持つコレクション（`map` や `dict` など）を反復処理するためにも使用できます。次のセクションでテンプレート変数を紹介する際に、その方法を説明します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"付録: Go データ型とテンプレート\"\ndescription: テンプレート内の変数についての簡単な解説です。\nsidebar_position: 16\n---\n\nHelm テンプレート言語は、強い型付けを持つ Go プログラミング言語で実装されています。そのため、テンプレート内の変数には _型_ があります。ほとんどの場合、変数は以下のいずれかの型として扱われます:\n\n- string: テキスト文字列\n- bool: `true` または `false`\n- int: 整数値（8、16、32、64 ビットの符号付きおよび符号なしのバリエーションもあります）\n- float64: 64 ビット浮動小数点値（8、16、32 ビットのバリエーションもあります）\n- バイトスライス（`[]byte`）: （潜在的に）バイナリデータを格納する際によく使用されます\n- struct: プロパティとメソッドを持つオブジェクト\n- スライス（インデックス付きリスト）: 上記のいずれかの型を要素として持ちます\n- 文字列キーのマップ（`map[string]interface{}`）: 値は上記の型のいずれかになります\n\nGo には他にも多くの型があり、テンプレート内でそれらを変換する必要がある場合もあります。オブジェクトの型を調べる最も簡単な方法は、テンプレート内で `printf \"%T\"` に渡すことです。これにより型名が出力されます。`typeOf` 関数や `kindOf` 関数も併せて参照してください。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: テンプレートのデバッグ\ndescription: デプロイに失敗する chart のトラブルシューティング方法。\nsidebar_position: 13\n---\n\nテンプレートのデバッグは難しいことがあります。レンダリングされたテンプレートは Kubernetes API サーバーに送信され、フォーマット以外の理由で YAML ファイルが拒否される可能性があるためです。\n\nデバッグに役立つコマンドをいくつか紹介します。\n\n- `helm lint`: chart がベストプラクティスに従っているかを検証する基本ツールです。\n- `helm template --debug`: chart テンプレートをローカルでレンダリングしてテストします。\n- `helm install --dry-run --debug`: chart をローカルでレンダリングし、インストールは行いません。また、競合するリソースがクラスター上で既に実行されていないかもチェックします。`--dry-run=server` を指定すると、chart 内の `lookup` もサーバーに対して実行されます。\n- `helm get manifest`: サーバーにインストールされているテンプレートを確認できます。\n\nYAML のパースに失敗したが、生成された内容を確認したい場合は、テンプレート内の問題箇所をコメントアウトしてから `helm install --dry-run --debug` を再実行する方法があります:\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\n上記はコメントを含んだままレンダリングされます:\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\nこの方法により、YAML パースエラーに妨げられずに生成内容を素早く確認できます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: テンプレート関数リスト\ndescription: Helm で利用可能なテンプレート関数の一覧です\nsidebar_position: 6\n---\n\nHelm にはテンプレートで活用できる多くのテンプレート関数が用意されています。\n以下のカテゴリごとに一覧を掲載します:\n\n* [暗号化とセキュリティ](#cryptographic-and-security-functions)\n* [日付](#date-functions)\n* [辞書](#dictionaries-and-dict-functions)\n* [エンコーディング](#encoding-functions)\n* [ファイルパス](#file-path-functions)\n* [Kubernetes と Chart](#kubernetes-and-chart-functions)\n* [論理とフロー制御](#logic-and-flow-control-functions)\n* [リスト](#lists-and-list-functions)\n* [算術](#math-functions)\n* [浮動小数点算術](#float-math-functions)\n* [ネットワーク](#network-functions)\n* [リフレクション](#reflection-functions)\n* [正規表現](#regular-expressions)\n* [セマンティックバージョン](#semantic-version-functions)\n* [文字列](#string-functions)\n* [型変換](#type-conversion-functions)\n* [URL](#url-functions)\n* [UUID](#uuid-functions)\n\n## 論理とフロー制御関数\n\nHelm には多くの論理・制御フロー関数が含まれています: [and](#and)、\n[coalesce](#coalesce)、[default](#default)、[empty](#empty)、[eq](#eq)、\n[fail](#fail)、[ge](#ge)、[gt](#gt)、[le](#le)、[lt](#lt)、[ne](#ne)、\n[not](#not)、[or](#or)、[required](#required)。\n\n### and\n\n2つ以上の引数のブール論理積（AND）を返します\n（最初の空の引数、または最後の引数を返します）。\n\n```\nand .Arg1 .Arg2\n```\n\n### or\n\n2つ以上の引数のブール論理和（OR）を返します\n（最初の空でない引数、または最後の引数を返します）。\n\n```\nor .Arg1 .Arg2\n```\n\n### not\n\n引数のブール否定を返します。\n\n```\nnot .Arg\n```\n\n### eq\n\n引数のブール等価性を返します（例: Arg1 == Arg2）。\n\n```\neq .Arg1 .Arg2\n```\n\n### ne\n\n引数のブール不等価性を返します（例: Arg1 != Arg2）。\n\n```\nne .Arg1 .Arg2\n```\n\n### lt\n\n第1引数が第2引数より小さい場合に true を返します。\nそれ以外は false を返します（例: Arg1 < Arg2）。\n\n```\nlt .Arg1 .Arg2\n```\n\n### le\n\n第1引数が第2引数以下の場合に true を返します。\nそれ以外は false を返します（例: Arg1 <= Arg2）。\n\n```\nle .Arg1 .Arg2\n```\n\n### gt\n\n第1引数が第2引数より大きい場合に true を返します。\nそれ以外は false を返します（例: Arg1 > Arg2）。\n\n```\ngt .Arg1 .Arg2\n```\n\n### ge\n\n第1引数が第2引数以上の場合に true を返します。\nそれ以外は false を返します（例: Arg1 >= Arg2）。\n\n```\nge .Arg1 .Arg2\n```\n\n### default\n\nシンプルなデフォルト値を設定するには `default` を使用します:\n\n```\ndefault \"foo\" .Bar\n```\n\n上記の場合、`.Bar` が空でない値に評価されればその値が使用されます。\n空の場合は代わりに `foo` が返されます。\n\n「空」の定義は型によって異なります:\n\n- 数値: 0\n- 文字列: \"\"\n- リスト: `[]`\n- 辞書: `{}`\n- ブール: `false`\n- および常に `nil`（null）\n\n構造体には空の定義がないため、構造体がデフォルト値を返すことはありません。\n\n### required\n\n`required` を使用して必須の値を指定します:\n\n```\nrequired \"A valid foo is required!\" .Bar\n```\n\n`.Bar` が空または未定義の場合（評価方法については [default](#default) を参照）、\nテンプレートはレンダリングされず、指定されたエラーメッセージが返されます。\n\n### empty\n\n`empty` 関数は、指定された値が空と見なされる場合に `true` を返し、\nそれ以外は `false` を返します。空の値は `default` セクションに記載されています。\n\n```\nempty .Foo\n```\n\nGo テンプレートの条件文では、空かどうかは自動的に計算されます。\nそのため、`if not empty .Foo` はほとんど必要ありません。代わりに `if .Foo` を使用してください。\n\n### fail\n\n無条件に空の `string` と指定されたテキストを含む `error` を返します。\nこれは、他の条件によってテンプレートのレンダリングが失敗すべきと判断された\nシナリオで役立ちます。\n\n```\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\n`coalesce` 関数は値のリストを受け取り、最初の空でない値を返します。\n\n```\ncoalesce 0 1 2\n```\n\n上記は `1` を返します。\n\nこの関数は複数の変数や値をスキャンする際に便利です:\n\n```\ncoalesce .name .parent.name \"Matt\"\n```\n\n上記はまず `.name` が空かどうかを確認します。空でなければその値を返します。\n空の場合、`coalesce` は `.parent.name` の空をチェックします。\n最終的に `.name` と `.parent.name` の両方が空の場合、`Matt` を返します。\n\n### ternary\n\n`ternary` 関数は2つの値とテスト値を受け取ります。テスト値が true の場合は\n第1の値を返します。テスト値が空の場合は第2の値を返します。\nこれは C や他のプログラミング言語の三項演算子に似ています。\n\n#### true テスト値\n\n```\nternary \"foo\" \"bar\" true\n```\n\nまたは\n\n```\ntrue | ternary \"foo\" \"bar\"\n```\n\n上記は `\"foo\"` を返します。\n\n#### false テスト値\n\n```\nternary \"foo\" \"bar\" false\n```\n\nまたは\n\n```\nfalse | ternary \"foo\" \"bar\"\n```\n\n上記は `\"bar\"` を返します。\n\n## 文字列関数\n\nHelm には以下の文字列関数が含まれています: [abbrev](#abbrev)、\n[abbrevboth](#abbrevboth)、[camelcase](#camelcase)、[cat](#cat)、\n[contains](#contains)、[hasPrefix](#hasprefix-and-hassuffix)、\n[hasSuffix](#hasprefix-and-hassuffix)、[indent](#indent)、[initials](#initials)、\n[kebabcase](#kebabcase)、[lower](#lower)、[nindent](#nindent)、\n[nospace](#nospace)、[plural](#plural)、[print](#print)、[printf](#printf)、\n[println](#println)、[quote](#quote-and-squote)、\n[randAlpha](#randalphanum-randalpha-randnumeric-and-randascii)、\n[randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii)、\n[randAscii](#randalphanum-randalpha-randnumeric-and-randascii)、\n[randNumeric](#randalphanum-randalpha-randnumeric-and-randascii)、\n[repeat](#repeat)、[replace](#replace)、[shuffle](#shuffle)、\n[snakecase](#snakecase)、[squote](#quote-and-squote)、[substr](#substr)、\n[swapcase](#swapcase)、[title](#title)、[trim](#trim)、[trimAll](#trimall)、\n[trimPrefix](#trimprefix)、[trimSuffix](#trimsuffix)、[trunc](#trunc)、\n[untitle](#untitle)、[upper](#upper)、[wrap](#wrap)、[wrapWith](#wrapwith)。\n\n### print\n\nパーツを組み合わせて文字列を返します。\n\n```\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\n文字列でない型は可能な限り文字列に変換されます。\n\n隣り合う2つの引数が文字列でない場合、間にスペースが追加されます。\n\n### println\n\n[print](#print) と同様に動作しますが、末尾に改行を追加します。\n\n### printf\n\nフォーマット文字列と順番に渡す引数に基づいて文字列を返します。\n\n```\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\n使用するプレースホルダーは渡す引数の型によって異なります。\n以下が含まれます:\n\n汎用:\n\n* `%v` デフォルトフォーマットでの値\n  * 辞書を出力する場合、プラスフラグ（%+v）でフィールド名を追加\n* `%%` リテラルのパーセント記号、値を消費しない\n\nブール:\n\n* `%t` true または false という単語\n\n整数:\n\n* `%b` 2進数\n* `%c` 対応する Unicode コードポイントで表される文字\n* `%d` 10進数\n* `%o` 8進数\n* `%O` 0o プレフィックス付き8進数\n* `%q` 安全にエスケープされたシングルクォート文字リテラル\n* `%x` 16進数（a-f は小文字）\n* `%X` 16進数（A-F は大文字）\n* `%U` Unicode フォーマット: U+1234、\"U+%04X\" と同等\n\n浮動小数点と複素数の構成要素:\n\n* `%b` 指数が2のべき乗の10進なし科学的記数法（例: -123456p-78）\n* `%e` 科学的記数法（例: -1.234456e+78）\n* `%E` 科学的記数法（例: -1.234456E+78）\n* `%f` 小数点あり、指数なし（例: 123.456）\n* `%F` %f と同義\n* `%g` 大きな指数には %e、それ以外は %f\n* `%G` 大きな指数には %E、それ以外は %F\n* `%x` 16進表記（2のべき乗の10進指数付き、例: -0x1.23abcp+20）\n* `%X` 大文字16進表記（例: -0X1.23ABCP+20）\n\n文字列とバイトスライス（これらの動詞で同等に扱われます）:\n\n* `%s` 文字列またはスライスの解釈されないバイト\n* `%q` 安全にエスケープされたダブルクォート文字列\n* `%x` 16進（小文字、バイトあたり2文字）\n* `%X` 16進（大文字、バイトあたり2文字）\n\nスライス:\n\n* `%p` 先頭 0x 付き16進表記での第0要素のアドレス\n\n### trim\n\n`trim` 関数は文字列の両側から空白を削除します:\n\n```\ntrim \"   hello    \"\n```\n\n上記は `hello` を生成します。\n\n### trimAll\n\n文字列の前後から指定した文字を削除します:\n\n```\ntrimAll \"$\" \"$5.00\"\n```\n\n上記は `5.00`（文字列として）を返します。\n\n### trimPrefix\n\n文字列からプレフィックスのみを削除します:\n\n```\ntrimPrefix \"-\" \"-hello\"\n```\n\n上記は `hello` を返します。\n\n### trimSuffix\n\n文字列からサフィックスのみを削除します:\n\n```\ntrimSuffix \"-\" \"hello-\"\n```\n\n上記は `hello` を返します。\n\n### lower\n\n文字列全体を小文字に変換します:\n\n```\nlower \"HELLO\"\n```\n\n上記は `hello` を返します。\n\n### upper\n\n文字列全体を大文字に変換します:\n\n```\nupper \"hello\"\n```\n\n上記は `HELLO` を返します。\n\n### title\n\nタイトルケースに変換します:\n\n```\ntitle \"hello world\"\n```\n\n上記は `Hello World` を返します。\n\n### untitle\n\nタイトルケースを解除します。`untitle \"Hello World\"` は `hello world` を生成します。\n\n### repeat\n\n文字列を複数回繰り返します:\n\n```\nrepeat 3 \"hello\"\n```\n\n上記は `hellohellohello` を返します。\n\n### substr\n\n文字列から部分文字列を取得します。3つのパラメータを取ります:\n\n- start（int）\n- end（int）\n- string（string）\n\n```\nsubstr 0 5 \"hello world\"\n```\n\n上記は `hello` を返します。\n\n### nospace\n\n文字列からすべての空白を削除します。\n\n```\nnospace \"hello w o r l d\"\n```\n\n上記は `helloworld` を返します。\n\n### trunc\n\n文字列を切り詰めます。\n\n```\ntrunc 5 \"hello world\"\n```\n\n上記は `hello` を生成します。\n\n```\ntrunc -5 \"hello world\"\n```\n\n上記は `world` を生成します。\n\n### abbrev\n\n文字列を省略記号（`...`）付きで切り詰めます。\n\nパラメータ:\n\n- 最大長\n- 文字列\n\n```\nabbrev 5 \"hello world\"\n```\n\n上記は `he...` を返します。省略記号の幅も最大長に含まれます。\n\n### abbrevboth\n\n両側を省略します:\n\n```\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\n上記は `...5678...` を生成します。\n\nパラメータ:\n\n- 左オフセット\n- 最大長\n- 文字列\n\n### initials\n\n複数の単語から各単語の最初の文字を取得して組み合わせます。\n\n```\ninitials \"First Try\"\n```\n\n上記は `FT` を返します。\n\n### randAlphaNum、randAlpha、randNumeric、randAscii\n\nこれら4つの関数は暗号学的に安全な（```crypto/rand``` を使用）\nランダム文字列を生成しますが、基本文字セットが異なります:\n\n- `randAlphaNum` は `0-9a-zA-Z` を使用\n- `randAlpha` は `a-zA-Z` を使用\n- `randNumeric` は `0-9` を使用\n- `randAscii` はすべての印刷可能 ASCII 文字を使用\n\nそれぞれ1つのパラメータ（文字列の整数長）を取ります。\n\n```\nrandNumeric 3\n```\n\n上記は3桁のランダム文字列を生成します。\n\n### wrap\n\n指定した列数でテキストを折り返します:\n\n```\nwrap 80 $someText\n```\n\n上記は `$someText` 内の文字列を80列で折り返します。\n\n### wrapWith\n\n`wrapWith` は `wrap` と同様に動作しますが、折り返しに使用する文字列を指定できます\n（`wrap` は `\\n` を使用）。\n\n```\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\n上記は `Hello World` を生成します（空白は ASCII タブ文字）。\n\n### contains\n\nある文字列が別の文字列に含まれているかテストします:\n\n```\ncontains \"cat\" \"catch\"\n```\n\n上記は `true` を返します。`catch` には `cat` が含まれているためです。\n\n### hasPrefix と hasSuffix\n\n`hasPrefix` と `hasSuffix` 関数は、文字列が指定したプレフィックスまたは\nサフィックスを持っているかテストします:\n\n```\nhasPrefix \"cat\" \"catch\"\n```\n\n上記は `true` を返します。`catch` にはプレフィックス `cat` があるためです。\n\n### quote と squote\n\nこれらの関数は文字列をダブルクォート（`quote`）または\nシングルクォート（`squote`）で囲みます。\n\n### cat\n\n`cat` 関数は複数の文字列をスペースで区切りながら1つに連結します:\n\n```\ncat \"hello\" \"beautiful\" \"world\"\n```\n\n上記は `hello beautiful world` を生成します。\n\n### indent\n\n`indent` 関数は指定した文字列のすべての行を指定したインデント幅で\nインデントします。複数行の文字列を揃える際に便利です:\n\n```\nindent 4 $lots_of_text\n```\n\n上記はテキストのすべての行を4つのスペース文字でインデントします。\n\n### nindent\n\n`nindent` 関数は indent 関数と同じですが、文字列の先頭に改行を追加します。\n\n```\nnindent 4 $lots_of_text\n```\n\n上記はテキストのすべての行を4つのスペース文字でインデントし、\n先頭に改行を追加します。\n\n### replace\n\n単純な文字列置換を行います。\n\n3つの引数を取ります:\n\n- 置換する文字列\n- 置換後の文字列\n- ソース文字列\n\n```\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\n上記は `I-Am-Henry-VIII` を生成します。\n\n### plural\n\n文字列を複数形にします。\n\n```\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\n上記で、文字列の長さが1の場合は第1引数が出力されます（`one anchovy`）。\nそれ以外の場合は第2引数が出力されます（`many anchovies`）。\n\n引数:\n\n- 単数形文字列\n- 複数形文字列\n- 長さ整数\n\nNOTE: 現在 Helm はより複雑な複数形ルールを持つ言語をサポートしていません。\nまた、`0` は複数形として扱われます。英語ではそのように扱われるためです\n（`zero anchovies`）。\n\n### snakecase\n\n文字列を camelCase から snake_case に変換します。\n\n```\nsnakecase \"FirstName\"\n```\n\n上記は `first_name` を生成します。\n\n### camelcase\n\n文字列を snake_case から CamelCase に変換します。\n\n```\ncamelcase \"http_server\"\n```\n\n上記は `HttpServer` を生成します。\n\n### kebabcase\n\n文字列を camelCase から kebab-case に変換します。\n\n```\nkebabcase \"FirstName\"\n```\n\n上記は `first-name` を生成します。\n\n### swapcase\n\n単語ベースのアルゴリズムを使用して文字列の大文字小文字を入れ替えます。\n\n変換アルゴリズム:\n\n- 大文字は小文字に変換\n- タイトルケース文字は小文字に変換\n- 空白の後または先頭の小文字はタイトルケースに変換\n- その他の小文字は大文字に変換\n- 空白は unicode.IsSpace(char) で定義\n\n```\nswapcase \"This Is A.Test\"\n```\n\n上記は `tHIS iS a.tEST` を生成します。\n\n### shuffle\n\n文字列をシャッフルします。\n\n```\nshuffle \"hello\"\n```\n\n上記は `hello` の文字をランダムに並べ替えます。`oelhl` のような結果になる可能性があります。\n\n## 型変換関数\n\nHelm は以下の型変換関数を提供しています:\n\n- `atoi`: 文字列を整数に変換\n- `float64`: `float64` に変換\n- `int`: システムのビット幅で `int` に変換\n- `int64`: `int64` に変換\n- `toDecimal`: Unix 8進数を `int64` に変換\n- `toString`: 文字列に変換\n- `toStrings`: リスト、スライス、または配列を文字列のリストに変換\n- `toJson`（`mustToJson`）: リスト、スライス、配列、辞書、またはオブジェクトを JSON に変換\n- `toPrettyJson`（`mustToPrettyJson`）: リスト、スライス、配列、辞書、またはオブジェクトをインデント付き JSON に変換\n- `toRawJson`（`mustToRawJson`）: リスト、スライス、配列、辞書、またはオブジェクトを HTML 文字がエスケープされていない JSON に変換\n- `fromYaml`: YAML 文字列をオブジェクトに変換\n- `fromJson`: JSON 文字列をオブジェクトに変換\n- `fromJsonArray`: JSON 配列をリストに変換\n- `toYaml`: リスト、スライス、配列、辞書、またはオブジェクトをインデント付き yaml に変換。任意のソースから yaml のチャンクをコピーするのに使用できます。この関数は GoLang の yaml.Marshal 関数と同等です。詳細はこちらを参照: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal\n- `toYamlPretty`: リスト、スライス、配列、辞書、またはオブジェクトをインデント付き yaml に変換。`toYaml` と同等ですが、リストを2スペースでさらにインデントします。\n- `toToml`: リスト、スライス、配列、辞書、またはオブジェクトを toml に変換。任意のソースから toml のチャンクをコピーするのに使用できます。\n- `fromYamlArray`: YAML 配列をリストに変換\n\n`atoi` のみ入力が特定の型である必要があります。その他は任意の型から\n目的の型への変換を試みます。例えば、`int64` は浮動小数点を整数に変換でき、\n文字列を整数に変換することもできます。\n\n### toStrings\n\nリスト型のコレクションを与えると、文字列のスライスを生成します。\n\n```\nlist 1 2 3 | toStrings\n```\n\n上記は `1` を `\"1\"` に、`2` を `\"2\"` に変換し、リストとして返します。\n\n### toDecimal\n\nUnix 8進数パーミッションを与えると、10進数を生成します。\n\n```\n\"0777\" | toDecimal\n```\n\n上記は `0777` を `511` に変換し、int64 として値を返します。\n\n### toJson、mustToJson\n\n`toJson` 関数は項目を JSON 文字列にエンコードします。項目を JSON に変換できない場合、\n関数は空の文字列を返します。`mustToJson` は項目を JSON にエンコードできない場合に\nエラーを返します。\n\n```\ntoJson .Item\n```\n\n上記は `.Item` の JSON 文字列表現を返します。\n\n### toPrettyJson、mustToPrettyJson\n\n`toPrettyJson` 関数は項目をインデント付きの整形された JSON 文字列にエンコードします。\n\n```\ntoPrettyJson .Item\n```\n\n上記は `.Item` のインデント付き JSON 文字列表現を返します。\n\n### toRawJson、mustToRawJson\n\n`toRawJson` 関数は項目を HTML 文字がエスケープされていない JSON 文字列にエンコードします。\n\n```\ntoRawJson .Item\n```\n\n上記は `.Item` のエスケープされていない JSON 文字列表現を返します。\n\n### fromYaml\n\n`fromYaml` 関数は YAML 文字列を受け取り、テンプレートで使用できるオブジェクトを返します。\n\n`File at: yamls/person.yaml`\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n```yaml\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\n`fromJson` 関数は JSON 文字列を受け取り、テンプレートで使用できるオブジェクトを返します。\n\n`File at: jsons/person.json`\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n\n### fromJsonArray\n\n`fromJsonArray` 関数は JSON 配列を受け取り、テンプレートで使用できるリストを返します。\n\n`File at: jsons/people.json`\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml、toYamlPretty\n\n`toYaml` と `toYamlPretty` 関数はオブジェクト（リスト、スライス、配列、辞書、またはオブジェクト）をインデント付き YAML 文字列にエンコードします。\n\n> `toYamlPretty` は機能的に同等ですが、リスト要素を追加でインデントした YAML を出力します。\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\n`fromYamlArray` 関数は YAML 配列を受け取り、テンプレートで使用できるリストを返します。\n\n`File at: yamls/people.yml`\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n\n## 正規表現\n\nHelm には以下の正規表現関数が含まれています: [regexFind\n（mustRegexFind）](#regexfindall-mustregexfindall)、[regexFindAll\n（mustRegexFindAll）](#regexfind-mustregexfind)、[regexMatch\n（mustRegexMatch）](#regexmatch-mustregexmatch)、[regexReplaceAll\n（mustRegexReplaceAll）](#regexreplaceall-mustregexreplaceall)、\n[regexReplaceAllLiteral\n（mustRegexReplaceAllLiteral）](#regexreplaceallliteral-mustregexreplaceallliteral)、\n[regexSplit（mustRegexSplit）](#regexsplit-mustregexsplit)。\n\n### regexMatch、mustRegexMatch\n\n入力文字列が正規表現にマッチするものを含む場合に true を返します。\n\n```\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\n上記は `true` を生成します。\n\n`regexMatch` は問題があるとパニックし、`mustRegexMatch` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### regexFindAll、mustRegexFindAll\n\n入力文字列内の正規表現のすべてのマッチのスライスを返します。\n最後のパラメータ n は返す部分文字列の数を決定し、-1 はすべてのマッチを返すことを意味します。\n\n```\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\n上記は `[2 4 6 8]` を生成します。\n\n`regexFindAll` は問題があるとパニックし、`mustRegexFindAll` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### regexFind、mustRegexFind\n\n入力文字列内の正規表現の最初の（最も左の）マッチを返します。\n\n```\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\n上記は `d1` を生成します。\n\n`regexFind` は問題があるとパニックし、`mustRegexFind` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### regexReplaceAll、mustRegexReplaceAll\n\n入力文字列のコピーを返し、正規表現のマッチを置換文字列で置換します。\n置換文字列内では、$ 記号は Expand と同様に解釈されます。\n例えば、$1 は最初のサブマッチのテキストを表します。\n第1引数は `<pattern>`、第2引数は `<input>`、第3引数は `<replacement>` です。\n\n```\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\n上記は `-W-xxW-` を生成します。\n\n`regexReplaceAll` は問題があるとパニックし、`mustRegexReplaceAll` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### regexReplaceAllLiteral、mustRegexReplaceAllLiteral\n\n入力文字列のコピーを返し、正規表現のマッチを置換文字列で置換します。\n置換文字列は Expand を使用せずに直接代入されます。\n第1引数は `<pattern>`、第2引数は `<input>`、第3引数は `<replacement>` です。\n\n```\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\n上記は `-${1}-${1}-` を生成します。\n\n`regexReplaceAllLiteral` は問題があるとパニックし、\n`mustRegexReplaceAllLiteral` は問題があるとテンプレートエンジンにエラーを返します。\n\n### regexSplit、mustRegexSplit\n\n入力文字列を正規表現で区切られた部分文字列にスライスし、\nそれらの正規表現マッチ間の部分文字列のスライスを返します。\n最後のパラメータ `n` は返す部分文字列の数を決定し、\n`-1` はすべてのマッチを返すことを意味します。\n\n```\nregexSplit \"z+\" \"pizza\" -1\n```\n\n上記は `[pi a]` を生成します。\n\n`regexSplit` は問題があるとパニックし、`mustRegexSplit` は問題があると\nテンプレートエンジンにエラーを返します。\n\n## 暗号化とセキュリティ関数\n\nHelm はいくつかの高度な暗号化関数を提供しています:\n[adler32sum](#adler32sum)、[buildCustomCert](#buildcustomcert)、\n[decryptAES](#decryptaes)、[derivePassword](#derivepassword)、\n[encryptAES](#encryptaes)、[genCA](#genca)、[genPrivateKey](#genprivatekey)、\n[genSelfSignedCert](#genselfsignedcert)、[genSignedCert](#gensignedcert)、\n[htpasswd](#htpasswd)、[randBytes](#randbytes)、[sha1sum](#sha1sum)、\n[sha256sum](#sha256sum)。\n\n### sha1sum\n\n`sha1sum` 関数は文字列を受け取り、その SHA1 ダイジェストを計算します。\n\n```\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\n`sha256sum` 関数は文字列を受け取り、その SHA256 ダイジェストを計算します。\n\n```\nsha256sum \"Hello world!\"\n```\n\n上記は印刷しても安全な「ASCII アーマー」形式で SHA 256 サムを計算します。\n\n### adler32sum\n\n`adler32sum` 関数は文字列を受け取り、その Adler-32 チェックサムを計算します。\n\n```\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\n`htpasswd` 関数は `username` と `password` を受け取り、パスワードの\n`bcrypt` ハッシュを生成します。結果は [Apache HTTP\nServer](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic) での\n基本認証に使用できます。\n\n```\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nパスワードをテンプレートに直接保存することは安全ではありません。\n\n### randBytes\n\nrandBytes 関数はカウント N を受け取り、暗号学的に安全な\n（crypto/rand を使用）N バイトのランダムシーケンスを生成します。\nシーケンスは base64 エンコードされた文字列として返されます。\n\n```\nrandBytes 24\n```\n\n### derivePassword\n\n`derivePassword` 関数は、共有「マスターパスワード」の制約に基づいて\n特定のパスワードを導出するために使用できます。\nこのアルゴリズムは[明確に仕様化されています](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf)。\n\n```\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nパーツをテンプレートに直接保存することは安全でないと見なされます。\n\n### genPrivateKey\n\n`genPrivateKey` 関数は PEM ブロックにエンコードされた新しい秘密鍵を生成します。\n\n最初のパラメータとして以下のいずれかの値を取ります:\n\n- `ecdsa`: 楕円曲線 DSA 鍵を生成（P256）\n- `dsa`: DSA 鍵を生成（L2048N256）\n- `rsa`: RSA 4096 鍵を生成\n\n### buildCustomCert\n\n`buildCustomCert` 関数は証明書のカスタマイズを可能にします。\n\n以下の文字列パラメータを取ります:\n\n- base64 エンコードされた PEM 形式の証明書\n- base64 エンコードされた PEM 形式の秘密鍵\n\n以下の属性を持つ証明書オブジェクトを返します:\n\n- `Cert`: PEM エンコードされた証明書\n- `Key`: PEM エンコードされた秘密鍵\n\n例:\n\n```\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\n返されたオブジェクトは `genSignedCert` 関数に渡して、この CA を使用して\n証明書に署名できます。\n\n### genCA\n\n`genCA` 関数は新しい自己署名 x509 認証局を生成します。\n\n以下のパラメータを取ります:\n\n- サブジェクトのコモンネーム（cn）\n- 証明書の有効期間（日数）\n\n以下の属性を持つオブジェクトを返します:\n\n- `Cert`: PEM エンコードされた証明書\n- `Key`: PEM エンコードされた秘密鍵\n\n例:\n\n```\n$ca := genCA \"foo-ca\" 365\n```\n\n返されたオブジェクトは `genSignedCert` 関数に渡して、この CA を使用して\n証明書に署名できます。\n\n### genSelfSignedCert\n\n`genSelfSignedCert` 関数は新しい自己署名 x509 証明書を生成します。\n\n以下のパラメータを取ります:\n\n- サブジェクトのコモンネーム（cn）\n- IP のオプションリスト（nil 可）\n- 代替 DNS 名のオプションリスト（nil 可）\n- 証明書の有効期間（日数）\n\n以下の属性を持つオブジェクトを返します:\n\n- `Cert`: PEM エンコードされた証明書\n- `Key`: PEM エンコードされた秘密鍵\n\n例:\n\n```\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\n`genSignedCert` 関数は指定した CA によって署名された新しい x509 証明書を生成します。\n\n以下のパラメータを取ります:\n\n- サブジェクトのコモンネーム（cn）\n- IP のオプションリスト（nil 可）\n- 代替 DNS 名のオプションリスト（nil 可）\n- 証明書の有効期間（日数）\n- CA（`genCA` を参照）\n\n例:\n\n```\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\n`encryptAES` 関数は AES-256 CBC でテキストを暗号化し、\nbase64 エンコードされた文字列を返します。\n\n```\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\n`decryptAES` 関数は AES-256 CBC アルゴリズムでエンコードされた\nbase64 文字列を受け取り、復号されたテキストを返します。\n\n```\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## 日付関数\n\nHelm にはテンプレートで使用できる以下の日付関数が含まれています:\n[ago](#ago)、[date](#date)、[dateInZone](#dateinzone)、[dateModify\n（mustDateModify）](#datemodify-mustdatemodify)、[duration](#duration)、\n[durationRound](#durationround)、[htmlDate](#htmldate)、\n[htmlDateInZone](#htmldateinzone)、[now](#now)、[toDate\n（mustToDate）](#todate-musttodate)、[unixEpoch](#unixepoch)。\n\n### now\n\n現在の日時を返します。他の日付関数と組み合わせて使用します。\n\n### ago\n\n`ago` 関数は現在からの経過時間を秒単位の解像度で返します。\n\n```\nago .CreatedAt\n```\n\n`time.Duration` の String() 形式で返します。\n\n```\n2h34m7s\n```\n\n### date\n\n`date` 関数は日付をフォーマットします。\n\n日付を YEAR-MONTH-DAY 形式でフォーマット:\n\n```\nnow | date \"2006-01-02\"\n```\n\nGo での日付フォーマットは[少し異なります](https://pauladamsmith.com/blog/2011/05/go_time.html)。\n\n簡単に言うと、以下を基準日として使用します:\n\n```\nMon Jan 2 15:04:05 MST 2006\n```\n\nこれを希望する形式で記述します。上記の `2006-01-02` は同じ日付ですが、\n希望する形式になっています。\n\n### dateInZone\n\n`date` と同じですが、タイムゾーン付きです。\n\n```\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\n指定した秒数を `time.Duration` としてフォーマットします。\n\n以下は 1m35s を返します。\n\n```\nduration \"95\"\n```\n\n### durationRound\n\n指定した期間を最も重要な単位に丸めます。文字列と `time.Duration` は\n期間として解析され、`time.Time` はそこからの経過時間として計算されます。\n\n以下は 2h を返します。\n\n```\ndurationRound \"2h10m5s\"\n```\n\n以下は 3mo を返します。\n\n```\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\n`time.Time` に対する Unix エポックからの秒数を返します。\n\n```\nnow | unixEpoch\n```\n\n### dateModify、mustDateModify\n\n`dateModify` は修正と日付を受け取り、タイムスタンプを返します。\n\n現在時刻から1時間30分を引く:\n\n```\nnow | dateModify \"-1.5h\"\n```\n\n修正形式が間違っている場合、`dateModify` は日付を変更せずに返します。\n`mustDateModify` はそれ以外の場合にエラーを返します。\n\n### htmlDate\n\n`htmlDate` 関数は HTML の日付ピッカー入力フィールドに挿入するために\n日付をフォーマットします。\n\n```\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nhtmlDate と同じですが、タイムゾーン付きです。\n\n```\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate、mustToDate\n\n`toDate` は文字列を日付に変換します。第1引数は日付レイアウト、\n第2引数は日付文字列です。文字列を変換できない場合はゼロ値を返します。\n`mustToDate` は文字列を変換できない場合にエラーを返します。\n\nこれは文字列の日付を別の形式に変換したい場合に便利です（パイプを使用）。\n以下の例は \"2017-12-31\" を \"31/12/2017\" に変換します。\n\n```\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## 辞書と Dict 関数\n\nHelm は `dict`（Python の「dictionary」の略）と呼ばれるキー/値ストレージ型を\n提供しています。`dict` は _順序なし_ の型です。\n\n辞書のキーは **文字列でなければなりません**。ただし、値は任意の型にでき、\n別の `dict` や `list` でも構いません。\n\n`list` とは異なり、`dict` は不変ではありません。`set` と `unset` 関数は\n辞書の内容を変更します。\n\nHelm は辞書を扱うために以下の関数を提供しています: [deepCopy\n（mustDeepCopy）](#deepcopy-mustdeepcopy)、[dict](#dict)、[dig](#dig)、[get](#get)、\n[hasKey](#haskey)、[keys](#keys)、[merge（mustMerge）](#merge-mustmerge)、\n[mergeOverwrite（mustMergeOverwrite）](#mergeoverwrite-mustmergeoverwrite)、\n[omit](#omit)、[pick](#pick)、[pluck](#pluck)、[set](#set)、[unset](#unset)、\n[values](#values)。\n\n### dict\n\n辞書の作成は `dict` 関数を呼び出してペアのリストを渡すことで行います。\n\n以下は3つの項目を持つ辞書を作成します:\n\n```\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nマップとキーを与えると、マップから値を取得します。\n\n```\nget $myDict \"name1\"\n```\n\n上記は `\"value1\"` を返します。\n\nキーが見つからない場合、この操作は単に `\"\"` を返します。\nエラーは生成されません。\n\n### set\n\n`set` を使用して辞書に新しいキー/値ペアを追加します。\n\n```\n$_ := set $myDict \"name4\" \"value4\"\n```\n\n`set` は _辞書を返す_（Go テンプレート関数の要件）ため、\n上記の `$_` 代入のように値をトラップする必要がある場合があります。\n\n### unset\n\nマップとキーを与えると、マップからキーを削除します。\n\n```\n$_ := unset $myDict \"name4\"\n```\n\n`set` と同様に、辞書を返します。\n\nキーが見つからない場合、この操作は単に戻ります。エラーは生成されません。\n\n### hasKey\n\n`hasKey` 関数は、指定した辞書に指定したキーが含まれている場合に `true` を返します。\n\n```\nhasKey $myDict \"name1\"\n```\n\nキーが見つからない場合は `false` を返します。\n\n### pluck\n\n`pluck` 関数は1つのキーと複数のマップを与えて、\nすべてのマッチのリストを取得することを可能にします:\n\n```\npluck \"name1\" $myDict $myOtherDict\n```\n\n上記は見つかったすべての値を含む `list` を返します（`[value1\notherValue1]`）。\n\n指定したキーがマップに _見つからない_ 場合、そのマップはリストに項目を持ちません\n（返されるリストの長さは `pluck` 呼び出しの辞書の数より少なくなります）。\n\nキーが _見つかった_ が値が空の値の場合、その値は挿入されます。\n\nHelm テンプレートでの一般的なイディオムは、`pluck... | first` を使用して\n辞書のコレクションから最初にマッチするキーを取得することです。\n\n### dig\n\n`dig` 関数はネストした辞書のセットを走査し、値のリストからキーを選択します。\n関連する辞書でキーが見つからない場合はデフォルト値を返します。\n\n```\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\n以下のような構造の辞書が与えられた場合\n```\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\n上記は `\"curator\"` を返します。辞書に `user` フィールドさえない場合、\n結果は `\"guest\"` になります。\n\nDig はガード句を避けたい場合に非常に便利です。特に Go のテンプレートパッケージの\n`and` はショートサーキットしないためです。例えば `and a.maybeNil a.maybeNil.iNeedThis` は\n常に `a.maybeNil.iNeedThis` を評価し、`a` に `maybeNil` フィールドがない場合は\nパニックします。\n\n`dig` はパイプラインをサポートするために辞書引数を最後に受け取ります。例えば:\n```\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge、mustMerge\n\n2つ以上の辞書を1つにマージし、dest 辞書を優先します:\n\n与えられた場合:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\n結果は:\n\n```\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n```\n$newdict := merge $dest $source1 $source2\n```\n\nこれはディープマージ操作ですが、ディープコピー操作ではありません。\nマージされるネストしたオブジェクトは両方の辞書で同じインスタンスです。\nマージと一緒にディープコピーが必要な場合は、マージと一緒に `deepCopy` 関数を\n使用してください。例えば、\n\n```\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` はマージが失敗した場合にエラーを返します。\n\n### mergeOverwrite、mustMergeOverwrite\n\n2つ以上の辞書を1つにマージし、**右から左**への優先順位で、\ndest 辞書の値を上書きします:\n\n与えられた場合:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\n結果は:\n\n```\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nこれはディープマージ操作ですが、ディープコピー操作ではありません。\nマージされるネストしたオブジェクトは両方の辞書で同じインスタンスです。\nマージと一緒にディープコピーが必要な場合は、マージと一緒に `deepCopy` 関数を\n使用してください。例えば、\n\n```\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` はマージが失敗した場合にエラーを返します。\n\n### keys\n\n`keys` 関数は1つ以上の `dict` 型のすべてのキーの `list` を返します。\n辞書は _順序なし_ なので、キーは予測可能な順序にはなりません。\n`sortAlpha` でソートできます。\n\n```\nkeys $myDict | sortAlpha\n```\n\n複数の辞書を指定すると、キーは連結されます。`uniq` 関数と `sortAlpha` を\n使用して、一意でソートされたキーのリストを取得できます。\n\n```\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\n`pick` 関数は辞書から指定したキーのみを選択し、新しい `dict` を作成します。\n\n```\n$new := pick $myDict \"name1\" \"name2\"\n```\n\n上記は `{name1: value1, name2: value2}` を返します。\n\n### omit\n\n`omit` 関数は `pick` に似ていますが、指定したキーに _マッチしない_\nすべてのキーを持つ新しい `dict` を返します。\n\n```\n$new := omit $myDict \"name1\" \"name3\"\n```\n\n上記は `{name2: value2}` を返します。\n\n### values\n\n`values` 関数は `keys` に似ていますが、ソース `dict` のすべての値を持つ\n新しい `list` を返します（辞書は1つのみサポート）。\n\n```\n$vals := values $myDict\n```\n\n上記は `list[\"value1\", \"value2\", \"value 3\"]` を返します。`values` 関数は\n結果の順序を保証しません。順序が重要な場合は `sortAlpha` を使用してください。\n\n### deepCopy、mustDeepCopy\n\n`deepCopy` と `mustDeepCopy` 関数は値を受け取り、その値のディープコピーを作成します。\nこれには辞書やその他の構造も含まれます。`deepCopy` は問題があるとパニックし、\n`mustDeepCopy` はエラーがあるとテンプレートシステムにエラーを返します。\n\n```\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### Dict 内部に関する注記\n\n`dict` は Go では `map[string]interface{}` として実装されています。\nGo 開発者は `map[string]interface{}` 値をコンテキストに渡して、\nテンプレートで `dict` として利用可能にすることができます。\n\n## エンコーディング関数\n\nHelm には以下のエンコードおよびデコード関数があります:\n\n- `b64enc`/`b64dec`: Base64 でエンコード/デコード\n- `b32enc`/`b32dec`: Base32 でエンコード/デコード\n\n## リストと List 関数\n\nHelm は任意のデータの連続リストを含むことができるシンプルな `list` 型を提供しています。\nこれは配列やスライスに似ていますが、リストは不変のデータ型として使用されるように\n設計されています。\n\n整数のリストを作成:\n\n```\n$myList := list 1 2 3 4 5\n```\n\n上記は `[1 2 3 4 5]` のリストを作成します。\n\nHelm は以下のリスト関数を提供しています: [append\n（mustAppend）](#append-mustappend)、[chunk](#chunk)、[compact\n（mustCompact）](#compact-mustcompact)、[concat](#concat)、[first\n（mustFirst）](#first-mustfirst)、[has（mustHas）](#has-musthas)、[initial\n（mustInitial）](#initial-mustinitial)、[last（mustLast）](#last-mustlast)、\n[prepend（mustPrepend）](#prepend-mustprepend)、[rest\n（mustRest）](#rest-mustrest)、[reverse（mustReverse）](#reverse-mustreverse)、\n[seq](#seq)、[index](#index)、[slice（mustSlice）](#slice-mustslice)、[uniq\n（mustUniq）](#uniq-mustuniq)、[until](#until)、[untilStep](#untilstep)、\n[without（mustWithout）](#without-mustwithout)。\n\n### first、mustFirst\n\nリストの先頭項目を取得するには `first` を使用します。\n\n`first $myList` は `1` を返します。\n\n`first` は問題があるとパニックし、`mustFirst` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### rest、mustRest\n\nリストの末尾（先頭項目以外のすべて）を取得するには `rest` を使用します。\n\n`rest $myList` は `[2 3 4 5]` を返します。\n\n`rest` は問題があるとパニックし、`mustRest` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### last、mustLast\n\nリストの最後の項目を取得するには `last` を使用します:\n\n`last $myList` は `5` を返します。これはリストを逆にしてから\n`first` を呼び出すのとほぼ同じです。\n\n### initial、mustInitial\n\nこれは `last` を補完し、最後の要素 _以外_ のすべてを返します。\n`initial $myList` は `[1 2 3 4]` を返します。\n\n`initial` は問題があるとパニックし、`mustInitial` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### append、mustAppend\n\n既存のリストに新しい項目を追加し、新しいリストを作成します。\n\n```\n$new = append $myList 6\n```\n\n上記は `$new` を `[1 2 3 4 5 6]` に設定します。`$myList` は変更されません。\n\n`append` は問題があるとパニックし、`mustAppend` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### prepend、mustPrepend\n\nリストの先頭に要素をプッシュし、新しいリストを作成します。\n\n```\nprepend $myList 0\n```\n\n上記は `[0 1 2 3 4 5]` を生成します。`$myList` は変更されません。\n\n`prepend` は問題があるとパニックし、`mustPrepend` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### concat\n\n任意の数のリストを1つに連結します。\n\n```\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\n上記は `[1 2 3 4 5 6 7 8]` を生成します。`$myList` は変更されません。\n\n### reverse、mustReverse\n\n与えられたリストの要素を逆にした新しいリストを生成します。\n\n```\nreverse $myList\n```\n\n上記はリスト `[5 4 3 2 1]` を生成します。\n\n`reverse` は問題があるとパニックし、`mustReverse` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### uniq、mustUniq\n\nすべての重複を削除したリストを生成します。\n\n```\nlist 1 1 1 2 | uniq\n```\n\n上記は `[1 2]` を生成します。\n\n`uniq` は問題があるとパニックし、`mustUniq` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### without、mustWithout\n\n`without` 関数はリストから項目をフィルタリングします。\n\n```\nwithout $myList 3\n```\n\n上記は `[1 2 4 5]` を生成します。\n\n`without` は複数のフィルターを取ることができます:\n\n```\nwithout $myList 1 3 5\n```\n\nこれは `[2 4]` を生成します。\n\n`without` は問題があるとパニックし、`mustWithout` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### has、mustHas\n\nリストに特定の要素があるかテストします。\n\n```\nhas 4 $myList\n```\n\n上記は `true` を返しますが、`has \"hello\" $myList` は false を返します。\n\n`has` は問題があるとパニックし、`mustHas` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### compact、mustCompact\n\nリストを受け取り、空の値を持つエントリを削除します。\n\n```\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` は空（つまり \"\"）の項目を削除した新しいリストを返します。\n\n`compact` は問題があるとパニックし、`mustCompact` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### index\n\nリストの n 番目の要素を取得するには `index list [n]` を使用します。\n多次元リストにインデックスするには `index list [n] [m] ...` を使用します。\n- `index $myList 0` は `1` を返します。`myList[0]` と同じです。\n- `index $myList 0 1` は `myList[0][1]` と同じです。\n\n### slice、mustSlice\n\nリストの部分要素を取得するには `slice list [n] [m]` を使用します。\nこれは `list[n:m]` と同等です。\n\n- `slice $myList` は `[1 2 3 4 5]` を返します。`myList[:]` と同じです。\n- `slice $myList 3` は `[4 5]` を返します。`myList[3:]` と同じです。\n- `slice $myList 1 3` は `[2 3]` を返します。`myList[1:3]` と同じです。\n- `slice $myList 0 3` は `[1 2 3]` を返します。`myList[:3]` と同じです。\n\n`slice` は問題があるとパニックし、`mustSlice` は問題があると\nテンプレートエンジンにエラーを返します。\n\n### until\n\n`until` 関数は整数の範囲を構築します。\n\n```\nuntil 5\n```\n\n上記はリスト `[0, 1, 2, 3, 4]` を生成します。\n\nこれは `range $i, $e := until 5` でループする際に便利です。\n\n### untilStep\n\n`until` と同様に、`untilStep` はカウント整数のリストを生成します。\nただし、開始、終了、ステップを定義できます:\n\n```\nuntilStep 3 6 2\n```\n\n上記は 3 から開始し、6 以上になるまで 2 を加算して `[3 5]` を生成します。\nこれは Python の `range` 関数に似ています。\n\n### seq\n\nbash の `seq` コマンドのように動作します。\n\n* 1 パラメータ（end）- 1 から `end` までのすべてのカウント整数を生成します（両端含む）。\n* 2 パラメータ（start, end）- `start` から `end` までのすべてのカウント整数を\n  1 ずつ増減して生成します（両端含む）。\n* 3 パラメータ（start, step, end）- `start` から `end` までのすべてのカウント整数を\n  `step` ずつ増減して生成します（両端含む）。\n\n```\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\nリストを指定したサイズのチャンクに分割するには `chunk size list` を使用します。\nこれはページネーションに便利です。\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\nこれはリストのリスト `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]` を生成します。\n\n## 算術関数\n\nすべての算術関数は、特に指定がない限り `int64` 値で動作します。\n\n以下の算術関数が利用可能です: [add](#add)、[add1](#add1)、\n[ceil](#ceil)、[div](#div)、[floor](#floor)、[len](#len)、[max](#max)、\n[min](#min)、[mod](#mod)、[mul](#mul)、[round](#round)、[sub](#sub)。\n\n### add\n\n`add` で数値を合計します。2つ以上の入力を受け付けます。\n\n```\nadd 1 2 3\n```\n\n### add1\n\n1 を加算するには `add1` を使用します。\n\n### sub\n\n減算するには `sub` を使用します。\n\n### div\n\n`div` で整数除算を行います。\n\n### mod\n\n`mod` で剰余を求めます。\n\n### mul\n\n`mul` で乗算します。2つ以上の入力を受け付けます。\n\n```\nmul 1 2 3\n```\n\n### max\n\n一連の整数の最大値を返します。\n\n以下は `3` を返します:\n\n```\nmax 1 2 3\n```\n\n### min\n\n一連の整数の最小値を返します。\n\n`min 1 2 3` は `1` を返します。\n\n### len\n\n引数の長さを整数として返します。\n\n```\nlen .Arg\n```\n\n## 浮動小数点算術関数\n\nすべての算術関数は `float64` 値で動作します。\n\n### addf\n\n`addf` で数値を合計します。\n\n以下は `5.5` を返します:\n\n```\naddf 1.5 2 2\n```\n\n### add1f\n\n1 を加算するには `add1f` を使用します。\n\n### subf\n\n減算するには `subf` を使用します。\n\n以下は `7.5 - 2 - 3` と同等で、`2.5` を返します:\n\n```\nsubf 7.5 2 3\n```\n\n### divf\n\n`divf` で整数除算を行います。\n\n以下は `10 / 2 / 4` と同等で、`1.25` を返します:\n\n```\ndivf 10 2 4\n```\n\n### mulf\n\n`mulf` で乗算します。\n\n以下は `6` を返します:\n\n```\nmulf 1.5 2 2\n```\n\n### maxf\n\n一連の浮動小数点の最大値を返します:\n\n以下は `3` を返します:\n\n```\nmaxf 1 2.5 3\n```\n\n### minf\n\n一連の浮動小数点の最小値を返します。\n\n以下は `1.5` を返します:\n\n```\nminf 1.5 2 3\n```\n\n### floor\n\n入力値以下の最大の浮動小数点値を返します。\n\n`floor 123.9999` は `123.0` を返します。\n\n### ceil\n\n入力値以上の最小の浮動小数点値を返します。\n\n`ceil 123.001` は `124.0` を返します。\n\n### round\n\n小数点以下の指定した桁数に余りを丸めた浮動小数点値を返します。\n\n`round 123.555555 3` は `123.556` を返します。\n\n## ネットワーク関数\n\nHelm には1つのネットワーク関数 `getHostByName` があります。\n\n`getHostByName` はドメイン名を受け取り、IP アドレスを返します。\n\n`getHostByName \"www.google.com\"` は `www.google.com` に対応する IP アドレスを返します。\n\nこの関数を使用するには、helm コマンドラインで `--enable-dns` オプションを渡す必要があります。\n\n## ファイルパス関数\n\nHelm テンプレート関数はファイルシステムへのアクセスを許可しませんが、\nファイルパスの規則に従う文字列を扱う関数を提供しています。\n[base](#base)、[clean](#clean)、[dir](#dir)、[ext](#ext)、[isAbs](#isabs) があります。\n\n### base\n\nパスの最後の要素を返します。\n\n```\nbase \"foo/bar/baz\"\n```\n\n上記は \"baz\" を出力します。\n\n### dir\n\n最後の部分を除いたディレクトリを返します。つまり `dir\n\"foo/bar/baz\"` は `foo/bar` を返します。\n\n### clean\n\nパスをクリーンアップします。\n\n```\nclean \"foo/bar/../baz\"\n```\n\n上記は `..` を解決し、`foo/baz` を返します。\n\n### ext\n\nファイル拡張子を返します。\n\n```\next \"foo.bar\"\n```\n\n上記は `.bar` を返します。\n\n### isAbs\n\nファイルパスが絶対パスかどうかを確認するには `isAbs` を使用します。\n\n## リフレクション関数\n\nHelm は初歩的なリフレクションツールを提供しています。\nこれらは上級テンプレート開発者が特定の値の基盤となる Go の型情報を\n理解するのに役立ちます。Helm は Go で書かれており、厳密に型付けされています。\n型システムはテンプレート内でも適用されます。\n\nGo には `string`、`slice`、`int64`、`bool` などのいくつかのプリミティブ _kind_ があります。\n\nGo にはオープンな _type_ システムがあり、開発者は独自の型を作成できます。\n\nHelm は [kind 関数](#kind-functions) と [type 関数](#type-functions) を通じて\nそれぞれに対する関数セットを提供しています。2つの値を比較するための\n[deepEqual](#deepequal) 関数も提供されています。\n\n### Kind 関数\n\nKind 関数は2つあります: `kindOf` はオブジェクトの kind を返します。\n\n```\nkindOf \"hello\"\n```\n\n上記は `string` を返します。単純なテスト（`if` ブロックなど）では、\n`kindIs` 関数で値が特定の kind かどうかを確認できます:\n\n```\nkindIs \"int\" 123\n```\n\n上記は `true` を返します。\n\n### Type 関数\n\n型は扱いが少し難しいため、3つの異なる関数があります:\n\n- `typeOf` は値の基盤となる型を返します: `typeOf $foo`\n- `typeIs` は `kindIs` のようなものですが、型用です: `typeIs \"*io.Buffer\" $myVal`\n- `typeIsLike` は `typeIs` のように動作しますが、ポインタの参照解除も行います\n\n**注意:** これらはいずれも、何かが特定のインターフェースを実装しているかどうかを\nテストできません。そのためには、インターフェースを事前にコンパイルする必要があるためです。\n\n### deepEqual\n\n`deepEqual` は2つの値が[\"深く等しい\"](https://golang.org/pkg/reflect/#DeepEqual)\n場合に true を返します。\n\n非プリミティブ型でも動作します（組み込みの `eq` と比較して）。\n\n```\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\n上記は `true` を返します。\n\n## セマンティックバージョン関数\n\n一部のバージョンスキームは簡単に解析・比較できます。Helm は [SemVer 2](http://semver.org)\nバージョンを扱うための関数を提供しています。これには [semver](#semver) と\n[semverCompare](#semvercompare) が含まれます。以下では、比較のための\n範囲の使用方法についても詳しく説明します。\n\n### semver\n\n`semver` 関数は文字列をセマンティックバージョンに解析します:\n\n```\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_パーサーが失敗した場合、テンプレートの実行はエラーで停止します。_\n\nこの時点で、`$version` は以下のプロパティを持つ `Version` オブジェクトへのポインタです:\n\n- `$version.Major`: メジャー番号（上記では `1`）\n- `$version.Minor`: マイナー番号（上記では `2`）\n- `$version.Patch`: パッチ番号（上記では `3`）\n- `$version.Prerelease`: プレリリース（上記では `alpha.1`）\n- `$version.Metadata`: ビルドメタデータ（上記では `123`）\n- `$version.Original`: 元のバージョン文字列\n\nさらに、`Compare` 関数を使用して `Version` を別の `version` と比較できます:\n\n```\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\n上記は `-1` を返します。\n\n戻り値は:\n\n- `-1`: 指定した semver が `Compare` メソッドを呼び出した semver より大きい場合\n- `1`: `Compare` 関数を呼び出したバージョンの方が大きい場合\n- `0`: 同じバージョンの場合\n\n（SemVer では、バージョン比較操作中に `Metadata` フィールドは比較されません。）\n\n### semverCompare\n\nより堅牢な比較関数として `semverCompare` が提供されています。\nこのバージョンはバージョン範囲をサポートします:\n\n- `semverCompare \"1.2.3\" \"1.2.3\"` は完全一致をチェックします\n- `semverCompare \"~1.2.0\" \"1.2.3\"` はメジャーとマイナーバージョンが一致し、\n  第2パラメータのパッチ番号が第1パラメータ _以上_ であることをチェックします。\n\nSemVer 関数は Sprig の作成者による [Masterminds semver\nライブラリ](https://github.com/Masterminds/semver) を使用しています。\n\n### 基本的な比較\n\n比較には2つの要素があります。まず、比較文字列はスペースまたはカンマで区切られた\nAND 比較のリストです。これらは ||（OR）比較で区切られます。\n例えば、`\">= 1.2 < 3.0.0 || >= 4.2.3\"` は、1.2 以上かつ 3.0.0 未満、\nまたは 4.2.3 以上の比較を探しています。\n\n基本的な比較は:\n\n- `=`: 等しい（演算子なしと同義）\n- `!=`: 等しくない\n- `>`: より大きい\n- `<`: より小さい\n- `>=`: 以上\n- `<=`: 以下\n\n### プレリリースバージョンの扱い\n\nプレリリースは、安定版または一般公開リリースの前のソフトウェアリリースに\n使用されます。プレリリースの例には、開発版、アルファ版、ベータ版、\nリリース候補版などがあります。プレリリースは `1.2.3-beta.1` のようなバージョンで、\n安定版リリースは `1.2.3` です。優先順位では、プレリリースは関連するリリースの\n前に来ます。この例では `1.2.3-beta.1 < 1.2.3` です。\n\nセマンティックバージョン仕様によると、プレリリースは\nそのリリース版と API 互換でない場合があります。以下のように述べられています:\n\n> プレリリースバージョンは、バージョンが不安定であり、\n> 関連する通常バージョンで示される意図された互換性要件を\n> 満たさない可能性があることを示します。\n\nプレリリース比較子なしの制約を使用した SemVer 比較は、\nリリースのリストを見るときにプレリリースバージョンをスキップします。\n例えば、`>=1.2.3` はプレリリースをスキップしますが、\n`>=1.2.3-0` はプレリリースを評価して見つけます。\n\n比較例でプレリリースバージョンとして `0` を使用する理由は、\nプレリリースには仕様に従って ASCII 英数字とハイフン（および `.` 区切り）のみを\n含めることができるためです。ソートは仕様に従って ASCII ソート順で行われます。\nASCII ソート順で最も低い文字は `0` です（[ASCII\nテーブル](http://www.asciitable.com/)を参照）。\n\nASCII ソート順を理解することは重要です。なぜなら、A-Z は a-z の前に来るからです。\nつまり、`>=1.2.3-BETA` は `1.2.3-alpha` を返します。\n大文字小文字の区別から期待することはここでは適用されません。\nこれは仕様で指定されている ASCII ソート順によるものです。\n\n### ハイフン範囲比較\n\n範囲を扱う方法は複数あり、最初はハイフン範囲です。\n以下のような形式になります:\n\n- `1.2 - 1.4.5` は `>= 1.2 <= 1.4.5` と同等\n- `2.3.4 - 4.5` は `>= 2.3.4 <= 4.5` と同等\n\n### 比較でのワイルドカード\n\n`x`、`X`、`*` 文字はワイルドカード文字として使用できます。\nこれはすべての比較演算子で動作します。`=` 演算子で使用すると、\nパッチレベルの比較にフォールバックします（下記のチルダを参照）。例えば、\n\n- `1.2.x` は `>= 1.2.0, < 1.3.0` と同等\n- `>= 1.2.x` は `>= 1.2.0` と同等\n- `<= 2.x` は `< 3` と同等\n- `*` は `>= 0.0.0` と同等\n\n### チルダ範囲比較（パッチ）\n\nチルダ（`~`）比較演算子は、マイナーバージョンが指定されている場合は\nパッチレベルの範囲、マイナー番号がない場合はメジャーレベルの変更用です。\n例えば、\n\n- `~1.2.3` は `>= 1.2.3, < 1.3.0` と同等\n- `~1` は `>= 1, < 2` と同等\n- `~2.3` は `>= 2.3, < 2.4` と同等\n- `~1.2.x` は `>= 1.2.0, < 1.3.0` と同等\n- `~1.x` は `>= 1, < 2` と同等\n\n### キャレット範囲比較（メジャー）\n\nキャレット（`^`）比較演算子は、安定版（1.0.0）リリース後の\nメジャーレベルの変更用です。1.0.0 リリース前は、マイナーバージョンが\nAPI 安定性レベルとして機能します。これは API バージョンの比較に便利です。\nメジャーな変更は API を壊すためです。例えば、\n\n- `^1.2.3` は `>= 1.2.3, < 2.0.0` と同等\n- `^1.2.x` は `>= 1.2.0, < 2.0.0` と同等\n- `^2.3` は `>= 2.3, < 3` と同等\n- `^2.x` は `>= 2.0.0, < 3` と同等\n- `^0.2.3` は `>=0.2.3 <0.3.0` と同等\n- `^0.2` は `>=0.2.0 <0.3.0` と同等\n- `^0.0.3` は `>=0.0.3 <0.0.4` と同等\n- `^0.0` は `>=0.0.0 <0.1.0` と同等\n- `^0` は `>=0.0.0 <1.0.0` と同等\n\n## URL 関数\n\nHelm には [urlParse](#urlparse)、[urlJoin](#urljoin)、\n[urlquery](#urlquery) 関数が含まれており、URL の部分を扱えます。\n\n### urlParse\n\n文字列を URL として解析し、URL 部分を含む辞書を生成します。\n\n```\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\n上記は URL オブジェクトを含む辞書を返します:\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nこれは Go 標準ライブラリの URL パッケージを使用して実装されています。\n詳細は https://golang.org/pkg/net/url/#URL を参照してください。\n\n### urlJoin\n\nマップ（`urlParse` で生成）を結合して URL 文字列を生成します。\n\n```\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\n上記は以下の文字列を返します:\n```\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\n引数として渡された値のエスケープ版を返します。\nURL のクエリ部分に埋め込むのに適しています。\n\n```\n$var := urlquery \"string for query\"\n```\n\n## UUID 関数\n\nHelm は UUID v4 ユニバーサル一意識別子を生成できます。\n\n```\nuuidv4\n```\n\n上記は v4（ランダム生成）タイプの新しい UUID を返します。\n\n## Kubernetes と Chart 関数\n\nHelm には Kubernetes を扱うための関数が含まれています:\n[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas)、\n[Files](#file-functions)、[lookup](#lookup)。\n\n### lookup\n\n`lookup` は実行中のクラスターでリソースを検索するために使用されます。\n`helm template` コマンドで使用すると、常に空のレスポンスを返します。\n\n詳細は [lookup 関数のドキュメント](/chart_template_guide/functions_and_pipelines.md#using-the-lookup-function)を\n参照してください。\n\n### .Capabilities.APIVersions.Has\n\nAPI バージョンまたはリソースがクラスターで利用可能かどうかを返します。\n\n```\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\n詳細は[組み込みオブジェクトのドキュメント](/chart_template_guide/builtin_objects.md)を\n参照してください。\n\n### File 関数\n\nchart 内の特別でないファイルにアクセスできる関数がいくつかあります。\n例えば、アプリケーション設定ファイルにアクセスする場合などです。\nこれらは[テンプレート内でのファイルへのアクセス](/chart_template_guide/accessing_files.md)で\nドキュメント化されています。\n\n_注意: これらの関数の多くのドキュメントは\n[Sprig](https://github.com/Masterminds/sprig) から来ています。\nSprig は Go アプリケーションで利用可能なテンプレート関数ライブラリです。_\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: テンプレート関数とパイプライン\ndescription: テンプレートでの関数の使い方を解説します。\nsidebar_position: 5\n---\n\nこれまでに、テンプレートに情報を配置する方法を見てきました。しかし、その情報はそのまま配置されます。時には、データをより使いやすい形に変換したい場合があります。\n\nまずベストプラクティスから始めましょう: `.Values` オブジェクトからの文字列をテンプレートに挿入する際は、その文字列をクォートで囲むべきです。テンプレートディレクティブ内で `quote` 関数を呼び出すことで実現できます:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nテンプレート関数は `functionName arg1 arg2...` という構文に従います。上記のスニペットでは、`quote .Values.favorite.drink` が `quote` 関数を呼び出し、1 つの引数を渡しています。\n\nHelm には 60 以上の関数が用意されています。そのうちのいくつかは [Go テンプレート言語](https://godoc.org/text/template)自体で定義されています。その他のほとんどは [Sprig テンプレートライブラリ](https://masterminds.github.io/sprig/)の一部です。これらの関数については、以降の例を進めながら解説していきます。\n\n> 「Helm テンプレート言語」という表現は Helm 固有のものと思われがちですが、実際には Go テンプレート言語、追加の関数、そしてテンプレートに特定のオブジェクトを公開するためのさまざまなラッパーの組み合わせです。Go テンプレートに関する多くのリソースが、テンプレートを学ぶ際に役立ちます。\n\n## パイプライン\n\nテンプレート言語の強力な機能の 1 つに _パイプライン_ の概念があります。UNIX のコンセプトに基づき、パイプラインは一連のテンプレートコマンドを連結して、一連の変換をコンパクトに表現するためのツールです。つまり、複数の処理を順番に効率よく実行できます。上記の例をパイプラインを使って書き直してみましょう。\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nこの例では、`quote ARGUMENT` と呼び出す代わりに、順序を逆にしています。パイプライン（`|`）を使って引数を関数に「送って」います: `.Values.favorite.drink | quote`。パイプラインを使用すると、複数の関数を連結できます:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> 順序を逆にする書き方はテンプレートでよく使われます。`quote .val` よりも `.val | quote` の形式をよく目にするでしょう。どちらでも構いません。\n\n評価されると、このテンプレートは以下のような出力を生成します:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\n元の `pizza` が `\"PIZZA\"` に変換されていることに注目してください。\n\nこのようにパイプラインで引数を渡す場合、最初の評価結果（`.Values.favorite.drink`）は _関数の最後の引数_ として送られます。上記の drink の例を、2 つの引数を取る関数 `repeat COUNT STRING` を使って説明してみましょう:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n`repeat` 関数は与えられた文字列を指定された回数だけ繰り返すので、出力は以下のようになります:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## `default` 関数の使用\n\nテンプレートで頻繁に使用される関数の 1 つに `default` 関数があります: `default DEFAULT_VALUE GIVEN_VALUE`。この関数を使用すると、値が省略された場合にテンプレート内でデフォルト値を指定できます。上記の drink の例を修正してみましょう:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\n通常どおり実行すると、`coffee` が表示されます:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\n次に、`values.yaml` から favorite drink の設定を削除します:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\n`helm install --dry-run --debug fair-worm ./mychart` を再実行すると、以下の YAML が生成されます:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\n実際の chart では、すべての静的なデフォルト値は `values.yaml` に定義し、`default` コマンドで重複させるべきではありません（冗長になるため）。ただし、`default` コマンドは `values.yaml` 内で宣言できない計算値に最適です。例:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\n状況によっては、`default` よりも `if` 条件ガードを使用する方が適している場合があります。次のセクションで説明します。\n\nテンプレート関数とパイプラインは、情報を変換して YAML に挿入する強力な方法です。しかし、単に文字列を挿入するだけでなく、より高度なテンプレートロジックが必要な場合もあります。次のセクションでは、テンプレート言語が提供する制御構造について説明します。\n\n## `lookup` 関数の使用\n\n`lookup` 関数を使用すると、実行中のクラスター内のリソースを _ルックアップ_ できます。lookup 関数の構文は `lookup apiVersion, kind, namespace, name -> resource or resource list` です。\n\n| パラメータ  | 型     |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\n`name` と `namespace` はどちらもオプションで、空文字列（`\"\"`）として渡すことができます。ただし、namespace スコープのリソースを扱う場合は、`name` と `namespace` の両方を指定する必要があります。\n\n以下のパラメータの組み合わせが可能です:\n\n| 動作                                   | lookup 関数                                |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\n`lookup` がオブジェクトを返す場合、辞書が返されます。この辞書をさらにナビゲートして特定の値を抽出できます。\n\n以下の例は `mynamespace` オブジェクトに存在するアノテーションを返します:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\n`lookup` がオブジェクトのリストを返す場合、`items` フィールドを通じてオブジェクトリストにアクセスできます:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* do something with each service */}}\n{{ end }}\n```\n\nオブジェクトが見つからない場合、空の値が返されます。これを使用してオブジェクトの存在を確認できます。\n\n`lookup` 関数は Helm の既存の Kubernetes 接続設定を使用して Kubernetes に問い合わせを行います。API サーバーとのやり取り中にエラーが返された場合（たとえば、リソースへのアクセス権限がない場合など）、Helm のテンプレート処理は失敗します。\n\nHelm は `helm template|install|upgrade|delete|rollback --dry-run` 操作中に Kubernetes API サーバーに接続しない点に注意してください。実行中のクラスターに対して `lookup` をテストするには、`helm template|install|upgrade|delete|rollback --dry-run=server` を使用してクラスター接続を許可する必要があります。\n\n## 演算子は関数である\n\nテンプレートでは、演算子（`eq`、`ne`、`lt`、`gt`、`and`、`or` など）はすべて関数として実装されています。パイプラインでは、括弧（`(`、`)`）を使用して演算をグループ化できます。\n\n次は関数とパイプラインから離れて、条件、ループ、スコープ修飾子を使用したフロー制御について説明します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: はじめに\ndescription: chart テンプレートのクイックガイドです。\nsidebar_position: 2\n---\n\nこのガイドのセクションでは、chart を作成し、最初のテンプレートを追加します。ここで作成する chart は、ガイドの残りの部分を通して使用します。\n\nまず、Helm chart について簡単に見ていきましょう。\n\n## Chart の構造\n\n[Chart ガイド](/topics/charts.md)で説明されているように、Helm chart は次のような構造になっています:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\n`templates/` ディレクトリはテンプレートファイル用です。Helm が chart を評価すると、`templates/` ディレクトリ内のすべてのファイルをテンプレートレンダリングエンジンに通して処理します。その後、テンプレートの処理結果を収集し、Kubernetes に送信します。\n\n`values.yaml` ファイルもテンプレートにとって重要です。このファイルには chart の _デフォルト値_ が含まれています。これらの値は、`helm install` や `helm upgrade` の実行時にユーザーが上書きできます。\n\n`Chart.yaml` ファイルには chart の説明が含まれています。テンプレート内からこの情報にアクセスできます。\n\n`charts/` ディレクトリには他の chart（_サブチャート_ と呼びます）を含めることが _できます_。このガイドの後半で、テンプレートレンダリング時にサブチャートがどのように動作するかを説明します。\n\n## スターター Chart の作成\n\nこのガイドでは、`mychart` というシンプルな chart を作成し、その中にいくつかのテンプレートを作成します。\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### `mychart/templates/` の概要\n\n`mychart/templates/` ディレクトリを見ると、すでにいくつかのファイルがあることに気づきます。\n\n- `NOTES.txt`: chart の「ヘルプテキスト」です。ユーザーが `helm install` を実行したときに表示されます。\n- `deployment.yaml`: Kubernetes の [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) を作成するための基本的なマニフェストです。\n- `service.yaml`: Deployment のための [Service エンドポイント](https://kubernetes.io/docs/concepts/services-networking/service/)を作成する基本的なマニフェストです。\n- `_helpers.tpl`: chart 全体で再利用できるテンプレートヘルパーを記述する場所です。\n\nこれから行うことは... _これらをすべて削除することです！_ そうすることで、チュートリアルを最初から進められます。実際には、ガイドを進めながら独自の `NOTES.txt` と `_helpers.tpl` を作成していきます。\n\n```console\n$ rm -rf mychart/templates/*\n```\n\n本番環境用の chart を作成する場合、これらの基本バージョンがあると非常に便利です。そのため、日常的な chart 作成では削除したくないでしょう。\n\n## 最初のテンプレート\n\n最初に作成するテンプレートは ConfigMap です。Kubernetes では、ConfigMap は設定データを格納するためのオブジェクトです。Pod などの他のリソースから ConfigMap 内のデータにアクセスできます。\n\nConfigMap は基本的なリソースなので、最初のテンプレートとして最適です。\n\nまず、`mychart/templates/configmap.yaml` というファイルを作成します:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**TIP:** テンプレート名には厳密な命名パターンはありません。ただし、YAML ファイルには `.yaml` 拡張子を、ヘルパーには `.tpl` を使用することを推奨します。\n\n上記の YAML ファイルは、最小限の必須フィールドだけを持つ基本的な ConfigMap です。このファイルは `mychart/templates/` ディレクトリにあるため、テンプレートエンジンを通して処理されます。\n\n`mychart/templates/` ディレクトリにこのようなプレーンな YAML ファイルを配置しても問題ありません。Helm がこのテンプレートを読み込むと、そのまま Kubernetes に送信します。\n\nこのシンプルなテンプレートで、インストール可能な chart ができました。次のようにインストールできます:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nHelm を使用して release を取得し、実際に読み込まれたテンプレートを確認できます。\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n`helm get manifest` コマンドは release 名（`full-coral`）を受け取り、サーバーにアップロードされたすべての Kubernetes リソースを出力します。各ファイルは YAML ドキュメントの開始を示す `---` で始まり、その後にどのテンプレートファイルがこの YAML ドキュメントを生成したかを示す自動生成されたコメント行が続きます。\n\nそこから先を見ると、YAML データは `configmap.yaml` ファイルに記述したものとまったく同じであることがわかります。\n\nでは、release をアンインストールしましょう: `helm uninstall full-coral`\n\n### シンプルなテンプレート呼び出しの追加\n\nリソースに `name:` をハードコーディングするのは、一般的に良くないプラクティスと考えられています。名前は release ごとに一意であるべきです。そのため、release 名を挿入して name フィールドを生成したいと思うかもしれません。\n\n**TIP:** `name:` フィールドは DNS システムの制限により 63 文字に制限されています。そのため、release 名は 53 文字に制限されています。Kubernetes 1.3 以前では 24 文字（つまり名前は 14 文字）に制限されていました。\n\n`configmap.yaml` を次のように変更します。\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n大きな変更は `name:` フィールドの値です。現在は `{{ .Release.Name }}-configmap` となっています。\n\n> テンプレートディレクティブは `{{` と `}}` ブロックで囲まれています。\n\nテンプレートディレクティブ `{{ .Release.Name }}` は release 名をテンプレートに挿入します。テンプレートに渡される値は _名前空間付きオブジェクト_ と考えることができ、ドット（`.`）が各名前空間要素を区切ります。\n\n`Release` の前の先頭のドットは、このスコープの最上位の名前空間から開始することを示します（スコープについては後で説明します）。つまり、`.Release.Name` は「最上位の名前空間から開始し、`Release` オブジェクトを見つけ、その中の `Name` というオブジェクトを探す」と読むことができます。\n\n`Release` オブジェクトは Helm の組み込みオブジェクトの 1 つで、後で詳しく説明します。今のところは、これが Helm ライブラリが release に割り当てる release 名を表示するということだけ理解しておいてください。\n\nこのテンプレートディレクティブを使用してリソースをインストールすると、すぐに結果が確認できます:\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\n`helm get manifest clunky-serval` を実行すると、生成された YAML 全体を確認できます。\n\nKubernetes 内の ConfigMap の名前が、以前の `mychart-configmap` ではなく `clunky-serval-configmap` になっていることに注目してください。\n\nこれで、テンプレートの最も基本的な形を見てきました: `{{` と `}}` にテンプレートディレクティブが埋め込まれた YAML ファイルです。次のパートでは、テンプレートについてさらに深く見ていきます。しかし先に進む前に、テンプレートの構築を速くする 1 つのテクニックがあります: テンプレートのレンダリングをテストしたいが、実際には何もインストールしたくない場合は、`helm install --debug --dry-run goodly-guppy ./mychart` を使用できます。これによりテンプレートがレンダリングされます。しかし、chart をインストールする代わりに、レンダリングされたテンプレートを返すので、出力を確認できます:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\n`--dry-run` を使用するとコードのテストが簡単になりますが、Kubernetes 自体が生成されたテンプレートを受け入れることは保証されません。`--dry-run` が動作するからといって、chart がインストールされると想定しないでください。\n\n[Chart テンプレートガイド](/chart_template_guide/index.mdx)では、ここで定義した基本的な chart を使用して、Helm テンプレート言語を詳しく探っていきます。そして、組み込みオブジェクトから始めます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: .helmignore ファイル\ndescription: \"`.helmignore` ファイルは、Helm chart に含めたくないファイルを指定するために使用します。\"\nsidebar_position: 12\n---\n\n`.helmignore` ファイルは、Helm chart に含めたくないファイルを指定するために使用します。\n\nこのファイルが存在する場合、`helm package` コマンドはアプリケーションをパッケージ化する際に `.helmignore` ファイルで指定されたパターンに一致するすべてのファイルを無視します。\n\nこれにより、不要なファイルや機密性の高いファイル、ディレクトリが Helm chart に含まれることを防ぐことができます。\n\n`.helmignore` ファイルは、Unix シェルの glob マッチング、相対パスマッチング、および否定（先頭に ! を付ける）をサポートしています。1 行につき 1 つのパターンのみ認識されます。\n\n以下は `.helmignore` ファイルの例です:\n\n```\n# comment\n\n# Match any file or path named .helmignore\n.helmignore\n\n# Match any file or path named .git\n.git\n\n# Match any text file\n*.txt\n\n# Match only directories named mydir\nmydir/\n\n# Match only text files in the top-level directory\n/*.txt\n\n# Match only the file foo.txt in the top-level directory\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt\na[b-d].txt\n\n# Match any file under subdir matching temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\n.gitignore との主な違いは以下のとおりです:\n- `**` 構文はサポートされていません。\n- glob ライブラリは fnmatch(3) ではなく、Go の `filepath.Match` を使用しています。\n- 末尾のスペースは常に無視されます（エスケープシーケンスはサポートされていません）。\n- `\\!` を特別な先頭シーケンスとして使用することはできません。\n- `.helmignore` ファイルはデフォルトでは自身を除外しないため、明示的にエントリを追加する必要があります。\n\n\n**このドキュメントの改善にご協力ください。** 情報の追加、修正、削除については、[issue を作成する](https://github.com/helm/helm-www/issues)か、プルリクエストを送信してください。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx",
    "content": "---\ntitle: チャートテンプレートガイド\nsidebar_position: 5\n---\n\n# チャートテンプレート開発者ガイド\n\nこのガイドでは、テンプレート言語に重点を置いて、\nHelm のチャートテンプレートの概要を説明します。\n\nテンプレートは、Kubernetes が理解できる \nYAML 形式のリソース記述であるマニフェストファイルを生成します。\nテンプレートの構造、テンプレートの使用方法、\nGo テンプレートの作成方法、作業のデバッグ方法について説明します。\n\nこのガイドでは、次の概念に焦点を当てています。\n\n- Helm テンプレート言語\n- 値の使用\n- テンプレートを操作するためのテクニック\n\nこのガイドは、Helm テンプレート言語の詳細を学ぶことを目的としています。\n他のガイドは、紹介資料、例、\nおよびベストプラクティスを提供します。\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: 名前付きテンプレート\ndescription: 名前付きテンプレートの定義方法を解説します。\nsidebar_position: 9\n---\n\nここからは 1 つのテンプレートを超えて、複数のテンプレートを作成していきます。このセクションでは、1 つのファイル内で _名前付きテンプレート_ を定義し、それを他の場所で使用する方法を説明します。_名前付きテンプレート_（_partial_ や _subtemplate_ とも呼ばれます）は、ファイル内で定義され、名前が付けられたテンプレートです。作成方法を 2 つ、使用方法をいくつか紹介します。\n\n[フロー制御](/chart_template_guide/control_structures.md)のセクションでは、テンプレートの宣言と管理のための 3 つのアクションを紹介しました: `define`、`template`、`block` です。このセクションでは、これら 3 つのアクションに加えて、`template` アクションと同様に機能する特別な `include` 関数も取り上げます。\n\nテンプレートに名前を付ける際に覚えておくべき重要な点があります: **テンプレート名はグローバルです**。同じ名前のテンプレートを 2 つ宣言した場合、最後に読み込まれたものが使用されます。サブチャートのテンプレートはトップレベルのテンプレートと一緒にコンパイルされるため、_chart 固有の名前_ でテンプレートに名前を付けるように注意してください。\n\n一般的な命名規則として、定義した各テンプレートに chart 名をプレフィックスとして付ける方法があります: `{{ define \"mychart.labels\" }}`。chart 固有の名前をプレフィックスとして使用することで、同じ名前のテンプレートを実装している異なる chart 間での衝突を回避できます。\n\nこの動作は、chart の異なるバージョン間でも同様に適用されます。`mychart` のバージョン `1.0.0` で特定の方法でテンプレートを定義し、`mychart` のバージョン `2.0.0` で既存の名前付きテンプレートを変更した場合、最後に読み込まれたものが使用されます。この問題を回避するには、chart 名にバージョンを含めるという方法もあります: `{{ define \"mychart.v1.labels\" }}` や `{{ define \"mychart.v2.labels\" }}` のようにします。\n\n## Partial と `_` ファイル\n\nここまでは 1 つのファイルを使用し、そのファイルには単一のテンプレートが含まれていました。しかし、Helm のテンプレート言語では、名前付きの埋め込みテンプレートを作成し、他の場所から名前でアクセスすることができます。\n\nこれらのテンプレートの書き方の詳細に入る前に、ファイルの命名規則について説明します:\n\n* `templates/` 内のほとんどのファイルは、Kubernetes マニフェストを含むものとして扱われます\n* `NOTES.txt` は例外です\n* ファイル名がアンダースコア（`_`）で始まるファイルは、マニフェストを含んでいないと見なされます。これらのファイルは Kubernetes オブジェクト定義としてはレンダリングされませんが、他の chart テンプレート内のどこからでも使用できます\n\nこれらのファイルは、partial やヘルパーを格納するために使用されます。実際、最初に `mychart` を作成したときに、`_helpers.tpl` というファイルがあったことを思い出してください。このファイルがテンプレート partial のデフォルトの保存場所です。\n\n## `define` と `template` によるテンプレートの宣言と使用\n\n`define` アクションを使用すると、テンプレートファイル内で名前付きテンプレートを作成できます。構文は以下のとおりです:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # body of template here\n{{- end }}\n```\n\nたとえば、Kubernetes のラベルブロックをカプセル化するテンプレートを定義できます:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nこのテンプレートを既存の ConfigMap に埋め込み、`template` アクションで呼び出すことができます:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nテンプレートエンジンがこのファイルを読み込むと、`mychart.labels` への参照を保存し、`template \"mychart.labels\"` が呼び出されるまで待機します。そして、そのテンプレートをインラインでレンダリングします。結果は以下のようになります:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\n注意: この例のように template で呼び出されない限り、`define` は出力を生成しません。\n\n慣例として、Helm chart ではこれらのテンプレートを partial ファイル（通常は `_helpers.tpl`）に配置します。この関数をそこに移動してみましょう:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\n慣例として、`define` 関数には何をするかを説明する簡単なドキュメントブロック（`{{/* ... */}}`）を付けるべきです。\n\nこの定義は `_helpers.tpl` にありますが、`configmap.yaml` からも引き続きアクセスできます:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\n前述のとおり、**テンプレート名はグローバルです**。そのため、同じ名前で 2 つのテンプレートが宣言された場合、最後に読み込まれたものが使用されます。サブチャートのテンプレートはトップレベルのテンプレートと一緒にコンパイルされるため、_chart 固有の名前_ でテンプレートに名前を付けるのがベストプラクティスです。一般的な命名規則として、定義した各テンプレートに chart 名をプレフィックスとして付ける方法があります: `{{ define \"mychart.labels\" }}`。\n\n## テンプレートのスコープ設定\n\n上記で定義したテンプレートでは、オブジェクトを一切使用せず、関数のみを使用しました。定義したテンプレートを修正して、chart 名と chart バージョンを含めてみましょう:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nこれをレンダリングすると、以下のようなエラーが発生します:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nレンダリング結果を確認するには、`--disable-openapi-validation` を付けて再実行します:\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`。\n結果は期待どおりではありません:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\n名前とバージョンはどうなったのでしょうか？定義したテンプレートのスコープ内になかったのです。名前付きテンプレート（`define` で作成されたもの）がレンダリングされると、`template` 呼び出しで渡されたスコープを受け取ります。この例では、テンプレートを以下のように呼び出していました:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nスコープが渡されていないため、テンプレート内では `.` の中の何にもアクセスできません。これは簡単に修正できます。テンプレートにスコープを渡すだけです:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\n`template` 呼び出しの最後に `.` を渡していることに注目してください。`.Values` や `.Values.favorite` など、任意のスコープを渡すこともできますが、ここではトップレベルのスコープが必要です。名前付きテンプレートのコンテキスト内では、`$` は渡されたスコープを参照し、グローバルスコープを参照するわけではありません。\n\nこのテンプレートを `helm install --dry-run --debug plinking-anaco ./mychart` で実行すると、以下の結果が得られます:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nこれで `{{ .Chart.Name }}` は `mychart` に、`{{ .Chart.Version }}` は `0.1.0` に解決されます。\n\n## `include` 関数\n\n以下のような単純なテンプレートを定義したとします:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nこのテンプレートをテンプレートの `labels:` セクションと `data:` セクションの両方に挿入したいとします:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nこれをレンダリングすると、以下のようなエラーが発生します:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nレンダリング結果を確認するには、`--disable-openapi-validation` を付けて再実行します:\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`。\n出力は期待どおりではありません:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\n両方の場所で `app_version` のインデントがおかしいことに注目してください。なぜでしょうか？置換されたテンプレートのテキストが左揃えになっているからです。`template` はアクションであり関数ではないため、`template` 呼び出しの出力を他の関数に渡す方法がありません。データは単にインラインで挿入されるだけです。\n\nこの問題を回避するため、Helm には `template` の代わりとなる方法が用意されています。テンプレートの内容を現在のパイプラインにインポートし、パイプライン内の他の関数に渡すことができます。\n\n以下は、`indent` を使用して `mychart.app` テンプレートを正しくインデントするように修正した例です:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nこれで生成される YAML は各セクションで正しくインデントされます:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> Helm テンプレートでは、`template` よりも `include` を使用することが推奨されます。これにより、YAML ドキュメントの出力フォーマットをより適切に処理できるためです。\n\n場合によっては、テンプレートとしてではなく、コンテンツをそのままインポートしたいことがあります。つまり、ファイルをそのまま取り込みたい場合です。これは、次のセクションで説明する `.Files` オブジェクトを通じてファイルにアクセスすることで実現できます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: NOTES.txt ファイルの作成\ndescription: chart のユーザーに使い方を伝える方法を解説します。\nsidebar_position: 10\n---\n\nこのセクションでは、chart のユーザーに使い方を伝えるための Helm の機能を紹介します。`helm install` や `helm upgrade` の実行後、Helm はユーザーに役立つ情報を出力できます。この情報はテンプレートを使って自由にカスタマイズできます。\n\nchart にインストール時のメモを追加するには、`templates/NOTES.txt` ファイルを作成します。このファイルはプレーンテキストですが、テンプレートとして処理されるため、通常のテンプレート関数やオブジェクトをすべて利用できます。\n\nそれでは、簡単な `NOTES.txt` ファイルを作成してみましょう:\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\n`helm install rude-cardinal ./mychart` を実行すると、以下のようなメッセージが末尾に表示されます:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\n`NOTES.txt` を活用すれば、新しくインストールした chart の使い方をユーザーに詳しく伝えられます。`NOTES.txt` ファイルの作成は必須ではありませんが、強く推奨します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: サブ chart とグローバル値\ndescription: サブ chart およびグローバル値との連携について解説します。\nsidebar_position: 11\n---\n\nこれまで 1 つの chart のみを扱ってきました。しかし chart には依存関係を持たせることができ、依存先の chart は _サブ chart_ と呼ばれます。サブ chart も独自の values とテンプレートを持ちます。このセクションでは、サブ chart を作成し、テンプレート内から values にアクセスするさまざまな方法を説明します。\n\n実際のコードに入る前に、アプリケーションのサブ chart に関する重要な点をいくつか説明します。\n\n1. サブ chart は「スタンドアロン」とみなされ、親 chart に明示的に依存することはできません。\n2. そのため、サブ chart は親の values にアクセスできません。\n3. 親 chart はサブ chart の values を上書きできます。\n4. Helm には、すべての chart からアクセスできる _グローバル値_ という概念があります。\n\n> これらの制限は、標準化されたヘルパー機能を提供するために設計された [library chart](/topics/library_charts.md) にはすべて当てはまるわけではありません。\n\nこのセクションの例を進めていくうちに、これらの概念がより明確になります。\n\n## サブ chart の作成\n\nこの演習では、ガイドの冒頭で作成した `mychart/` chart を使用し、その中に新しい chart を追加します。\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\n以前と同様に、ゼロから始めるためベーステンプレートをすべて削除しました。このガイドでは、依存関係の管理ではなく、テンプレートの仕組みに焦点を当てています。サブ chart の詳細については、[Charts ガイド](/topics/charts.md)を参照してください。\n\n## サブ chart への Values とテンプレートの追加\n\n次に、`mysubchart` chart 用のシンプルなテンプレートと values ファイルを作成します。`mychart/charts/mysubchart` にはすでに `values.yaml` があるはずです。以下のように設定します:\n\n```yaml\ndessert: cake\n```\n\n次に、`mychart/charts/mysubchart/templates/configmap.yaml` に新しい ConfigMap テンプレートを作成します:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nサブ chart は _スタンドアロン_ であるため、`mysubchart` を単独でテストできます:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## 親 chart からの Values の上書き\n\n元の chart である `mychart` は、`mysubchart` の _親 chart_ になりました。この関係は、`mysubchart` が `mychart/charts` 内にあるという事実のみに基づいています。\n\n`mychart` が親であるため、`mychart` で設定を指定し、その設定を `mysubchart` にプッシュできます。たとえば、`mychart/values.yaml` を以下のように変更できます:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\n最後の 2 行に注目してください。`mysubchart` セクション内のディレクティブはすべて `mysubchart` chart に送信されます。`helm install --generate-name --dry-run --debug mychart` を実行すると、`mysubchart` の ConfigMap が出力に含まれます:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nトップレベルの値がサブ chart の値を上書きしています。\n\nここで重要な点に注目してください。`mychart/charts/mysubchart/templates/configmap.yaml` のテンプレートを `.Values.mysubchart.dessert` を参照するように変更していません。そのテンプレートの視点からは、値は依然として `.Values.dessert` に配置されています。テンプレートエンジンが values を渡す際にスコープを設定するため、`mysubchart` テンプレートでは `mysubchart` に固有の値のみが `.Values` で利用可能になります。\n\nしかし、特定の値をすべてのテンプレートで利用可能にしたい場合もあります。これはグローバル chart 値で実現できます。\n\n## グローバル chart 値\n\nグローバル値は、すべての chart またはサブ chart から同じ名前でアクセスできる値です。グローバル値は明示的な宣言が必要です。既存の非グローバル値をグローバルであるかのように使用することはできません。\n\nValues データ型には `Values.global` という予約されたセクションがあり、ここでグローバル値を設定できます。`mychart/values.yaml` ファイルで設定してみましょう。\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nグローバル値の仕組みにより、`mychart/templates/configmap.yaml` と `mysubchart/templates/configmap.yaml` の両方から `{{ .Values.global.salad }}` としてこの値にアクセスできます。\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\ndry-run インストールを実行すると、両方の出力で同じ値が確認できます:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nグローバル値はこのような情報を共有するのに便利ですが、使用するテンプレートを適切に設計する必要があります。\n\n## サブ chart とのテンプレートの共有\n\n親 chart とサブ chart はテンプレートを共有できます。任意の chart で定義されたブロックは、他の chart から利用可能です。\n\nたとえば、以下のようなシンプルなテンプレートを定義できます:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nテンプレートのラベルは _グローバルに共有される_ ことを思い出してください。したがって、`labels` chart は他の任意の chart からインクルードできます。\n\nchart 開発者は `include` と `template` のどちらかを選択できますが、`include` を使用する利点の 1 つは、テンプレートを動的に参照できることです:\n\n```yaml\n{{ include $mytemplate }}\n```\n\n上記は `$mytemplate` を参照解決します。一方、`template` 関数は文字列リテラルのみを受け付けます。\n\n## Blocks の使用を避ける\n\nGo テンプレート言語には、開発者がデフォルトの実装を提供し、後でオーバーライドできるようにする `block` キーワードがあります。Helm chart では、同じ block の複数の実装が提供された場合に選択されるものが予測できないため、blocks はオーバーライドに最適なツールではありません。\n\n代わりに `include` の使用を推奨します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Values ファイル\ndescription: --values フラグの使い方について解説します。\nsidebar_position: 4\n---\n\n前のセクションで、Helm テンプレートが提供する組み込みオブジェクトについて説明しました。組み込みオブジェクトの 1 つに `Values` があります。このオブジェクトは、chart に渡された値へのアクセスを提供します。`Values` の内容は複数のソースから取得されます:\n\n- chart 内の `values.yaml` ファイル\n- サブ chart の場合は、親 chart の `values.yaml` ファイル\n- `helm install` または `helm upgrade` で `-f` フラグを使用して渡された values ファイル（`helm install -f myvals.yaml ./mychart`）\n- `--set` で渡された個別のパラメータ（`helm install --set foo=bar ./mychart` など）\n\n上記のリストは具体性の高い順に並んでいます。`values.yaml` がデフォルト値となり、親 chart の `values.yaml` で上書きできます。さらにユーザー指定の values ファイルで上書きでき、最終的に `--set` パラメータで上書きできます。\n\nvalues ファイルは単純な YAML ファイルです。`mychart/values.yaml` を編集し、続いて ConfigMap テンプレートを編集してみましょう。\n\n`values.yaml` のデフォルト値を削除し、1 つのパラメータだけを設定します:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nこれをテンプレート内で使用できます:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\n最後の行で `favoriteDrink` を `Values` の属性としてアクセスしていることに注目してください: `{{ .Values.favoriteDrink }}`。\n\nレンダリング結果を確認します。\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nデフォルトの `values.yaml` ファイルで `favoriteDrink` が `coffee` に設定されているため、テンプレートにはその値が表示されています。`helm install` の呼び出しに `--set` フラグを追加することで、簡単に上書きできます:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\n`--set` はデフォルトの `values.yaml` ファイルよりも優先順位が高いため、テンプレートは `drink: slurm` を生成します。\n\nvalues ファイルにはより構造化されたコンテンツを含めることもできます。たとえば、`values.yaml` ファイルに `favorite` セクションを作成し、その中に複数のキーを追加できます:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nテンプレートを少し修正する必要があります:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nこのようにデータを構造化することは可能ですが、values ツリーは浅く保ち、フラットな構造を優先することを推奨します。サブ chart への値の割り当てについて説明するときに、ツリー構造を使用した値の命名方法を確認します。\n\n## デフォルトキーの削除\n\nデフォルト値からキーを削除する必要がある場合は、キーの値を `null` に上書きできます。これにより、Helm はマージされた値からそのキーを削除します。\n\nたとえば、stable Drupal chart ではカスタムイメージを使用する場合に liveness probe を設定できるようになっています。デフォルト値は以下のとおりです:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\n`--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]` を使用して livenessProbe ハンドラを `httpGet` から `exec` に上書きしようとすると、Helm はデフォルト値と上書き値のキーをマージし、以下の YAML が生成されます:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nしかし、Kubernetes では複数の livenessProbe ハンドラを宣言できないため、これは失敗します。この問題を解決するには、`livenessProbe.httpGet` を null に設定して Helm に削除を指示します:\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nここまでで、いくつかの組み込みオブジェクトを確認し、それらを使用してテンプレートに情報を注入する方法を解説しました。次は、テンプレートエンジンのもう 1 つの側面である関数とパイプラインについて説明します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: 変数\ndescription: テンプレートでの変数の使い方を解説します。\nsidebar_position: 8\n---\n\nこれまでに関数、パイプライン、オブジェクト、制御構造について解説してきました。ここでは、多くのプログラミング言語で基本的な概念である変数について説明します。テンプレートでの使用頻度は高くありませんが、コードを簡潔にしたり、`with` や `range` をより効果的に使ったりするのに役立ちます。\n\n前の例で、以下のコードが失敗することを確認しました:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` は `with` ブロックで制限されたスコープの外にあります。スコープの問題を回避する方法の 1 つは、現在のスコープに関係なくアクセスできる変数にオブジェクトを代入することです。\n\nHelm テンプレートにおける変数は、別のオブジェクトへの名前付き参照です。変数は `$name` という形式で記述します。変数への代入には、特別な代入演算子 `:=` を使用します。上記を変数を使って書き直してみましょう。`Release.Name` を変数に格納できます:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\n`with` ブロックの開始前に `$relname := .Release.Name` で代入していることに注目してください。これにより、`with` ブロック内でも `$relname` 変数は引き続き release 名を参照できます。\n\n上記を実行すると、以下の出力が得られます:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\n変数は `range` ループで特に便利です。リスト型のオブジェクトに対して、インデックスと値の両方を取得できます:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\n`range` が最初に来て、次に変数、代入演算子、リストの順になることに注意してください。これにより、整数のインデックス（0 から開始）が `$index` に、値が `$topping` に代入されます。実行結果は次のとおりです:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nキーと値の両方を持つデータ構造に対しても、`range` で両方を取得できます。たとえば、`.Values.favorite` を以下のようにループできます:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\n最初のイテレーションでは `$key` が `drink`、`$val` が `coffee` になり、2 回目のイテレーションでは `$key` が `food`、`$val` が `pizza` になります。上記を実行すると、以下の出力が生成されます:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\n変数は通常「グローバル」ではありません。宣言されたブロック内でのみ有効です。先ほどの例では、`$relname` をテンプレートのトップレベルで代入しました。この変数はテンプレート全体で有効です。しかし、最後の例の `$key` と `$val` は `{{ range... }}{{ end }}` ブロック内でのみ有効です。\n\nただし、常にルートコンテキストを参照する変数が 1 つあります: `$` です。これは、range でループしているときに chart の release 名を取得したい場合などに非常に便利です。\n\n以下に使用例を示します:\n\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # 多くの Helm テンプレートでは下記で `.` を使いますが、それでは動作しません。\n    # しかし、`$` を使えば動作します\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # .Chart.Name は参照できませんが、$.Chart.Name は参照できます\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Chart.yaml の appVersion から取得した値\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nここまでは、1 つのファイルで宣言された 1 つのテンプレートのみを扱ってきました。しかし、Helm テンプレート言語の強力な機能の 1 つは、複数のテンプレートを宣言し、それらを組み合わせて使用できることです。次のセクションでその方法を説明します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: 次のステップ\ndescription: まとめ - 今後の学習に役立つ参考ドキュメントを紹介します。\nsidebar_position: 14\n---\n\nこのガイドでは、chart 開発者向けに Helm テンプレート言語の使い方を詳しく解説しています。テンプレート開発の技術的な側面に焦点を当てています。\n\nただし、chart の日常的な開発に関して、このガイドでカバーしていない内容も多くあります。新しい chart を作成する際に参考になるドキュメントを以下に紹介します:\n\n- CNCF の [Artifact Hub](https://artifacthub.io/packages/search?kind=0) は、chart を探す上で欠かせない情報源です。\n- Kubernetes の[ドキュメント](https://kubernetes.io/docs/home/)では、ConfigMap や Secret から DaemonSet、Deployment まで、さまざまなリソースの種類について詳しい例を確認できます。\n- Helm の [Charts ガイド](/topics/charts.md)では、chart を使用するワークフローについて説明しています。\n- Helm の [Chart Hooks ガイド](/topics/charts_hooks.md)では、ライフサイクルフックの作成方法について説明しています。\n- Helm の [Charts Tips and Tricks](/howto/charts_tips_and_tricks.md) の記事では、chart を作成する際に役立つヒントを紹介しています。\n- [Sprig ドキュメント](https://github.com/Masterminds/sprig)では、60以上のテンプレート関数について説明しています。\n- [Go テンプレートのドキュメント](https://godoc.org/text/template)では、テンプレート構文の詳細が説明されています。\n- [Schelm ツール](https://github.com/databus23/schelm)は、chart のデバッグに便利なヘルパーユーティリティです。\n\n経験豊富な開発者に直接質問する方が手っ取り早い場合もあります。そのためには、[Kubernetes Slack](https://kubernetes.slack.com) の Helm チャンネルが最適です:\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\n最後に、このドキュメントに誤りや記載漏れがある場合、新しいコンテンツを提案したい場合、または貢献したい場合は、[The Helm Project](https://github.com/helm/helm-www) をご覧ください。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"付録: YAML テクニック\"\ndescription: YAML 仕様と Helm での活用方法について詳しく解説します。\nsidebar_position: 15\n---\n\nこのガイドでは主にテンプレート言語について説明してきました。ここでは、YAML フォーマットについて見ていきます。YAML には、テンプレート作成者として活用できる便利な機能があり、テンプレートでのエラーを減らし、読みやすくすることができます。\n\n## スカラーとコレクション\n\n[YAML 仕様](https://yaml.org/spec/1.2/spec.html)によると、コレクションには 2 種類あり、スカラー型は多数あります。\n\nコレクションの 2 種類は、マップとシーケンスです:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nスカラー値は（コレクションとは対照的に）個々の値です。\n\n### YAML のスカラー型\n\nHelm の YAML 方言では、値のスカラーデータ型は、リソース定義の Kubernetes スキーマを含む複雑なルールセットによって決定されます。ただし、型を推論する際には、以下のルールが一般的に当てはまります。\n\n整数または浮動小数点数が引用符なしの単語の場合、通常は数値型として扱われます:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nただし、引用符で囲むと、文字列として扱われます:\n\n```yaml\ncount: \"1\" # <-- string, not int\nsize: '2.34' # <-- string, not float\n```\n\nブール値も同様です:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # string\n```\n\n空の値を表す単語は `null` です（`nil` ではありません）。\n\n`port: \"80\"` は有効な YAML であり、テンプレートエンジンと YAML パーサーの両方を通過しますが、Kubernetes が `port` を整数として期待している場合は失敗することに注意してください。\n\n場合によっては、YAML ノードタグを使用して特定の型推論を強制できます:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\n上記では、`!!str` は `age` が整数のように見えても文字列であることをパーサーに伝えます。また、`port` は引用符で囲まれていても整数として扱われます。\n\n\n## YAML の文字列\n\nYAML ドキュメントに配置するデータの多くは文字列です。YAML には文字列を表現する方法が複数あります。このセクションでは、その方法を説明し、いくつかの使用方法を示します。\n\n文字列を宣言する「インライン」の方法は 3 つあります:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nすべてのインラインスタイルは 1 行で記述する必要があります。\n\n- ベアワード（引用符なしの語）はエスケープされません。そのため、使用する文字に注意が必要です。\n- ダブルクォート文字列では、`\\` で特定の文字をエスケープできます。例: `\"\\\"Hello\\\", she said\"`。`\\n` で改行をエスケープできます。\n- シングルクォート文字列は「リテラル」文字列であり、`\\` を使用して文字をエスケープしません。唯一のエスケープシーケンスは `''` で、これは単一の `'` にデコードされます。\n\n1 行の文字列に加えて、複数行の文字列を宣言できます:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\n上記では、`coffee` の値は `Latte\\nCappuccino\\nEspresso\\n` と同等の単一の文字列として扱われます。\n\n`|` の後の最初の行は正しくインデントされている必要があることに注意してください。次のようにすると上記の例は壊れます:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\n`Latte` のインデントが正しくないため、次のようなエラーが発生します:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nテンプレートでは、上記のエラーを防ぐために、保護用のダミー行を最初に配置しておくと安全な場合があります:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\n最初の行が何であれ、文字列の出力に保持されることに注意してください。たとえば、この技法を使用してファイルの内容を ConfigMap に挿入する場合、コメントはそのエントリを読み取るものが期待する形式である必要があります。\n\n### 複数行文字列の空白制御\n\n上記の例では、`|` を使用して複数行文字列を示しました。しかし、文字列の内容の末尾に `\\n` が付いていることに注意してください。YAML プロセッサに末尾の改行を削除させたい場合は、`|` の後に `-` を追加できます:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nこれで `coffee` の値は `Latte\\nCappuccino\\nEspresso` になります（末尾の `\\n` なし）。\n\n逆に、すべての末尾の空白を保持したい場合もあります。これは `|+` 記法で実現できます:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nこれで `coffee` の値は `Latte\\nCappuccino\\nEspresso\\n\\n\\n` になります。\n\nテキストブロック内のインデントは保持され、改行も保持されます:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\n上記の場合、`coffee` は `Latte\\n  12 oz\\n  16 oz\\nCappuccino\\nEspresso` になります。\n\n### インデントとテンプレート\n\nテンプレートを記述するとき、ファイルの内容をテンプレートに挿入したい場合があります。前の章で見たように、これを行う方法は 2 つあります:\n\n- `{{ .Files.Get \"FILENAME\" }}` を使用して chart 内のファイルの内容を取得する。\n- `{{ include \"TEMPLATE\" . }}` を使用してテンプレートをレンダリングし、その内容を chart に配置する。\n\nファイルを YAML に挿入する場合、上記の複数行ルールを理解することが重要です。多くの場合、静的ファイルを挿入する最も簡単な方法は次のようなものです:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\n上記のインデントの方法に注意してください: `indent 2` はテンプレートエンジンに「myfile.txt」のすべての行を 2 つのスペースでインデントするよう指示します。テンプレート行自体はインデントしないことに注意してください。インデントすると、最初の行のファイル内容が 2 回インデントされてしまいます。\n\n### 折りたたみ複数行文字列\n\nYAML で文字列を複数行で表現したいが、解釈時には 1 つの長い行として扱いたい場合があります。これは「折りたたみ」と呼ばれます。折りたたみブロックを宣言するには、`|` の代わりに `>` を使用します:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\n上記の `coffee` の値は `Latte Cappuccino Espresso\\n` になります。最後の改行を除くすべてがスペースに変換されることに注意してください。空白制御を折りたたみテキストマーカーと組み合わせることができるため、`>-` はすべての改行を置き換えるか削除します。\n\n折りたたみ構文では、テキストをインデントすると行が保持されることに注意してください。\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\n上記は `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso` を生成します。スペースと改行の両方がまだ残っていることに注意してください。\n\n## 1 つのファイルに複数のドキュメントを埋め込む\n\n1 つのファイルに複数の YAML ドキュメントを配置することができます。これは、新しいドキュメントの前に `---` を付け、ドキュメントの終わりに `...` を付けることで行います。\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\n多くの場合、`---` または `...` のいずれかを省略できます。\n\nHelm の一部のファイルには複数のドキュメントを含めることができません。たとえば、`values.yaml` ファイル内に複数のドキュメントが提供されている場合、最初のドキュメントのみが使用されます。\n\nただし、テンプレートファイルには複数のドキュメントを含めることができます。この場合、ファイル（およびそのすべてのドキュメント）はテンプレートレンダリング中に 1 つのオブジェクトとして扱われます。ただし、結果の YAML は Kubernetes に渡される前に複数のドキュメントに分割されます。\n\n複数ドキュメントの使用は、本当に必要な場合に限ることを推奨します。ファイルに複数のドキュメントがあると、デバッグが困難になる可能性があります。\n\n## YAML は JSON のスーパーセット\n\nYAML は JSON のスーパーセットであるため、有効な JSON ドキュメントは_有効な_ YAML でもあるはずです。\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\n上記は、以下を表現する別の方法です:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nそして、2 つを（注意して）混合することもできます:\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nこれら 3 つはすべて同じ内部表現にパースされるはずです。\n\nつまり、`values.yaml` などのファイルには JSON データを含めることができますが、Helm はファイル拡張子 `.json` を有効なサフィックスとして扱いません。\n\n## YAML アンカー\n\nYAML 仕様では、値への参照を保存し、後でその値を参照によって参照する方法が提供されています。YAML ではこれを「アンカー」と呼びます:\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\n上記では、`&favoriteCoffee` が `Cappuccino` への参照を設定します。後で、その参照は `*favoriteCoffee` として使用されます。したがって、`coffees` は `Latte, Cappuccino, Espresso` になります。\n\nアンカーが役立つケースはいくつかありますが、気づきにくいバグを引き起こす可能性がある点が 1 つあります: YAML が最初に読み込まれるとき、参照は展開されてから破棄されます。\n\nしたがって、上記の例をデコードしてから再エンコードすると、結果の YAML は次のようになります:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nHelm と Kubernetes は YAML ファイルを読み取り、変更し、再書き込みすることが多いため、アンカーは失われます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: Helm 2 からの変更点\nsidebar_position: 1\n---\n\n## Helm 2 からの変更点\n\nHelm 3 で導入された主要な変更点を網羅的に紹介します。\n\n### Tiller の削除\n\nHelm 2 の開発サイクル中に Tiller を導入しました。Tiller は共有クラスターで作業するチームにとって重要な役割を果たし、複数のオペレーターが同じ release セットを操作できるようにしました。\n\nしかし、Kubernetes 1.6 でロールベースアクセス制御（RBAC）がデフォルトで有効化されたことにより、本番環境で Tiller を安全に運用することが難しくなりました。セキュリティポリシーは多岐にわたるため、Helm チームとしては寛容なデフォルト設定を提供する方針をとりました。これにより、初めてのユーザーはセキュリティ制御を深く学ばなくても Helm と Kubernetes を試すことができました。しかし、この寛容な設定により、ユーザーに意図しない広範な権限が付与される可能性がありました。DevOps エンジニアや SRE は、マルチテナントクラスターに Tiller をインストールする際に追加の運用手順を学ぶ必要がありました。\n\nコミュニティメンバーがさまざまなシナリオでどのように Helm を使用しているかを聞いた結果、Tiller の release 管理システムには、クラスター内オペレーターに状態を維持させたり、Helm release 情報の中央ハブとして機能させたりする必要がないことがわかりました。代わりに、Kubernetes API サーバーから情報を取得し、クライアント側で chart をレンダリングし、インストール記録を Kubernetes に保存するだけで十分です。\n\nTiller の主な目的は Tiller なしでも達成できるため、Helm 3 に関する最初の決定の 1 つとして、Tiller を完全に削除しました。\n\nTiller がなくなったことで、Helm のセキュリティモデルは大幅に簡素化されました。Helm 3 は、最新の Kubernetes のセキュリティ、ID、認可機能をすべてサポートしています。Helm の権限は [kubeconfig ファイル](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)を使用して評価されます。クラスター管理者は、必要な粒度でユーザー権限を制限できます。release は引き続きクラスター内に記録され、Helm のその他の機能はそのまま維持されています。\n\n### アップグレード戦略の改善: 3-way Strategic Merge Patch\n\nHelm 2 では、2-way strategic merge patch を使用していました。アップグレード時には、最新の chart のマニフェストと提案された chart のマニフェスト（`helm upgrade` で指定されたもの）を比較し、この 2 つの差分から Kubernetes リソースに適用すべき変更を決定しました。`kubectl edit` などによる手動での変更は考慮されませんでした。そのため、リソースを以前の状態にロールバックできない場合がありました。Helm は最後に適用された chart のマニフェストのみを現在の状態として認識するため、chart の状態に変更がなければ、ライブ状態は変更されませんでした。\n\nHelm 3 では、3-way strategic merge patch を使用しています。パッチを生成する際に、古いマニフェスト、ライブ状態、新しいマニフェストの 3 つを考慮します。\n\n#### 例\n\nこの変更が及ぼす影響について、一般的な例をいくつか見ていきます。\n\n##### ライブ状態が変更された場合のロールバック\n\nチームが Helm を使用して Kubernetes の本番環境にアプリケーションをデプロイしたとします。chart には Deployment オブジェクトが含まれており、レプリカ数は 3 に設定されています:\n\n```console\n$ helm install myapp ./myapp\n```\n\n新しい開発者がチームに加わりました。最初の日に本番クラスターを観察している際、キーボードにコーヒーをこぼしてしまう事故が発生し、`kubectl scale` で本番環境の Deployment のレプリカ数を 3 から 0 に変更してしまいました。\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nチームの別の開発者が本番サイトのダウンに気づき、release を以前の状態にロールバックすることにしました:\n\n```console\n$ helm rollback myapp\n```\n\n何が起こるでしょうか？\n\nHelm 2 では、古いマニフェストと新しいマニフェストを比較してパッチを生成します。これはロールバックなので、同じマニフェストです。Helm は、古いマニフェストと新しいマニフェストに差分がないため、変更の必要がないと判断します。レプリカ数はゼロのまま、問題が発生します。\n\nHelm 3 では、古いマニフェスト、ライブ状態、新しいマニフェストを使用してパッチを生成します。Helm は、古い状態が 3、ライブ状態が 0、新しいマニフェストが 3 に戻したいことを認識し、状態を 3 に戻すパッチを生成します。\n\n##### ライブ状態が変更された場合のアップグレード\n\n多くのサービスメッシュやコントローラーベースのアプリケーションは、Kubernetes オブジェクトにデータを注入します。サイドカー、ラベル、その他の情報などです。chart からレンダリングされた次のようなマニフェストがあるとします:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nライブ状態が別のアプリケーションによって以下のように変更されたとします:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nここで、`nginx` の image タグを `2.1.0` にアップグレードしたいとします。次のマニフェストを持つ chart にアップグレードします:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\n何が起こるでしょうか？\n\nHelm 2 では、古いマニフェストと新しいマニフェストの間で `containers` オブジェクトのパッチを生成します。パッチ生成時にクラスターのライブ状態は考慮されません。\n\nクラスターのライブ状態は次のように変更されます:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nサイドカー Pod がライブ状態から削除され、問題が発生します。\n\nHelm 3 では、古いマニフェスト、ライブ状態、新しいマニフェストの間で `containers` オブジェクトのパッチを生成します。新しいマニフェストが image タグを `2.1.0` に変更しようとしていることを認識し、同時にライブ状態にサイドカーコンテナが含まれていることも認識します。\n\nクラスターのライブ状態は次のように変更されます:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### release 名が namespace にスコープ化\n\nTiller の削除に伴い、各 release の情報を保存する場所が必要でした。Helm 2 では、Tiller と同じ namespace に保存されていました。そのため、一度 release に名前が使用されると、異なる namespace にデプロイされていても、他の release がその名前を使用できませんでした。\n\nHelm 3 では、特定の release に関する情報は release 自体と同じ namespace に保存されます。これにより、ユーザーは 2 つの異なる namespace で `helm install wordpress stable/wordpress` を実行でき、それぞれを現在の namespace コンテキストを変更して `helm list` で参照できます（例: `helm list --namespace foo`）。\n\nこの変更により、ネイティブのクラスター namespace との整合性が向上しました。`helm list` コマンドはデフォルトですべての release を一覧表示しなくなり、現在の Kubernetes コンテキストの namespace 内の release のみを一覧表示します（`kubectl config view --minify` を実行したときに表示される namespace）。Helm 2 と同様の動作を得るには、`helm list` に `--all-namespaces` フラグを指定する必要があります。\n\n### Secret がデフォルトのストレージドライバに\n\nHelm 3 では、Secret が[デフォルトのストレージドライバ](/topics/advanced.md#storage-backends)になりました。Helm 2 では、release 情報を保存するためにデフォルトで ConfigMap を使用していました。Helm 2.7.0 で Secret を使用する新しいストレージバックエンドが実装され、Helm 3 からデフォルトになりました。\n\nHelm 3 でデフォルトを Secret に変更することで、Kubernetes の Secret 暗号化機能と組み合わせて chart の追加的なセキュリティ保護が可能になります。\n\n[静止時の Secret 暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)は Kubernetes 1.7 でアルファ機能として利用可能になり、Kubernetes 1.13 で安定版になりました。これにより、ユーザーは Helm release のメタデータを静止時に暗号化でき、将来的に Vault などへの拡張の出発点となります。\n\n### Go import パスの変更\n\nHelm 3 では、Go import パスが `k8s.io/helm` から `helm.sh/helm/v3` に変更されました。Helm 3 の Go クライアントライブラリにアップグレードする場合は、import パスを変更してください。\n\n### Capabilities\n\nレンダリング段階で利用できる `.Capabilities` ビルトインオブジェクトが簡素化されました。\n\n[ビルトインオブジェクト](/chart_template_guide/builtin_objects.md)\n\n### JSONSchema による chart 値の検証\n\nchart 値に JSON Schema を適用できるようになりました。これにより、ユーザーが提供する値が chart メンテナーの定義したスキーマに従っていることが保証され、不正な値を指定した場合にはより良いエラーレポートが提供されます。\n\n検証は以下のコマンドの実行時に行われます:\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\n詳細は [Schema ファイル](/topics/charts.md#schema-files)のドキュメントを参照してください。\n\n### `requirements.yaml` の `Chart.yaml` への統合\n\nchart の依存関係管理システムが requirements.yaml と requirements.lock から Chart.yaml と Chart.lock に移行しました。Helm 3 向けの新しい chart は新しいフォーマットを使用することを推奨します。ただし、Helm 3 は Chart API バージョン 1（`v1`）も引き続き理解し、既存の `requirements.yaml` ファイルを読み込むことができます。\n\nHelm 2 での `requirements.yaml` は次のようになっていました:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nHelm 3 では、依存関係は同じように表現されますが、`Chart.yaml` に記述します:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nchart は引き続き `charts/` ディレクトリにダウンロードされるため、`charts/` ディレクトリにベンダリングされたサブチャートは変更なしで動作します。\n\n### インストール時に名前（または --generate-name）が必須に\n\nHelm 2 では、名前が指定されない場合、自動生成された名前が付けられました。本番環境では、これは便利な機能というよりも厄介な問題となることがわかりました。Helm 3 では、`helm install` で名前が指定されない場合、エラーが発生します。\n\n名前を自動生成したい場合は、`--generate-name` フラグを使用してください。\n\n### OCI レジストリへの chart プッシュ\n\nこれは Helm 3 で導入された実験的機能です。使用するには、環境変数 `HELM_EXPERIMENTAL_OCI=1` を設定してください。\n\n大まかに言うと、Chart リポジトリは chart を保存および共有できる場所です。Helm クライアントは Helm chart をパッケージ化して Chart リポジトリに送信します。簡単に言えば、Chart リポジトリは index.yaml ファイルといくつかのパッケージ化された chart を格納する基本的な HTTP サーバーです。\n\nChart リポジトリ API は最も基本的なストレージ要件を満たしていますが、いくつかの欠点が明らかになってきました:\n\n- Chart リポジトリでは、本番環境で必要なセキュリティ実装を抽象化することが困難です。本番シナリオでは、認証と認可のための標準 API が非常に重要です。\n- chart の署名と整合性・出所の検証に使用される Helm の chart 来歴ツールは、chart 公開プロセスのオプション部分です。\n- マルチテナントシナリオでは、同じ chart が別のテナントによってアップロードされる可能性があり、同じコンテンツを保存するのに 2 倍のストレージコストがかかります。よりスマートな chart リポジトリはこれに対処するように設計されていますが、正式な仕様の一部ではありません。\n- 検索、メタデータ情報、chart の取得に単一のインデックスファイルを使用することで、安全なマルチテナント実装の設計が困難になっています。\n\nDocker の Distribution プロジェクト（Docker Registry v2 とも呼ばれる）は、Docker Registry プロジェクトの後継です。多くの主要クラウドベンダーが Distribution プロジェクトの製品を提供しており、長年にわたる堅牢化、セキュリティベストプラクティス、実戦での検証の恩恵を受けてきました。\n\nchart をパッケージ化して Docker レジストリにプッシュする方法の詳細については、`helm help chart` と `helm help registry` を参照してください。\n\n詳細は[このページ](/topics/registries.md)を参照してください。\n\n### `helm serve` の削除\n\n`helm serve` は、開発目的でローカルマシン上で Chart リポジトリを実行するコマンドでした。しかし、開発ツールとしてあまり普及せず、設計上の問題が多数ありました。最終的に、これを削除してプラグインとして分離することにしました。\n\n`helm serve` と同様の体験を得るには、[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) のローカルファイルシステムストレージオプションと [servecm プラグイン](https://github.com/jdolitsky/helm-servecm)を参照してください。\n\n\n### ライブラリ chart のサポート\n\nHelm 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）に保つことができます。\n\nライブラリ chart は Chart.yaml の dependencies ディレクティブで宣言され、他の chart と同様にインストールおよび管理されます。\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nこの機能が chart 開発者にどのようなユースケースを開くか、またライブラリ chart を使用する際のベストプラクティスがどのように生まれるかを楽しみにしています。\n\n### Chart.yaml の apiVersion の変更\n\nライブラリ chart のサポートの導入と requirements.yaml の Chart.yaml への統合により、Helm 2 のパッケージフォーマットを理解するクライアントはこれらの新機能を理解できません。そのため、Chart.yaml の apiVersion を `v1` から `v2` に引き上げました。\n\n`helm create` は新しいフォーマットを使用して chart を作成するようになったため、デフォルトの apiVersion もそちらに変更されました。\n\n両方のバージョンの Helm chart をサポートしたいクライアントは、Chart.yaml の `apiVersion` フィールドを調べてパッケージフォーマットの解析方法を決定する必要があります。\n\n### XDG Base Directory のサポート\n\n[XDG Base Directory 仕様](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)は、設定、データ、キャッシュファイルをファイルシステムのどこに保存すべきかを定義するポータブルな標準です。\n\nHelm 2 では、すべての情報を `~/.helm`（俗称「helm home」）に保存していました。これは `$HELM_HOME` 環境変数または `--home` グローバルフラグで変更できました。\n\nHelm 3 では、XDG Base Directory 仕様に従って以下の環境変数を使用します:\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nHelm プラグインには、`$HELM_HOME` をスクラッチパッド環境として使用するプラグインとの後方互換性のために、`$HELM_HOME` が `$XDG_DATA_HOME` のエイリアスとして引き続き渡されます。\n\nこの変更に対応するために、プラグイン環境にいくつかの新しい環境変数も渡されるようになりました:\n\n- `$HELM_PATH_CACHE`: キャッシュパス\n- `$HELM_PATH_CONFIG`: 設定パス\n- `$HELM_PATH_DATA`: データパス\n\nHelm 3 をサポートする Helm プラグインは、これらの新しい環境変数の使用を検討してください。\n\n### CLI コマンドの名前変更\n\n他のパッケージマネージャーとの用語の整合性を高めるため、`helm delete` は `helm uninstall` に名前変更されました。`helm delete` は `helm uninstall` のエイリアスとして引き続き保持されているため、どちらの形式でも使用できます。\n\nHelm 2 では、release の台帳を削除するために `--purge` フラグを指定する必要がありました。この機能は現在デフォルトで有効になっています。以前の動作を維持するには、`helm uninstall --keep-history` を使用してください。\n\nまた、同じ規則に合わせるためにいくつかの他のコマンドも名前変更されました:\n\n- `helm inspect` → `helm show`\n- `helm fetch` → `helm pull`\n\nこれらのコマンドも以前の動詞がエイリアスとして保持されているため、どちらの形式でも引き続き使用できます。\n\n### namespace の自動作成\n\n存在しない namespace に release を作成する場合、Helm 2 は namespace を作成しました。Helm 3 は他の Kubernetes ツールの動作に従い、namespace が存在しない場合はエラーを返します。Helm 3 で namespace を作成するには、明示的に `--create-namespace` フラグを指定してください。\n\n### .Chart.ApiVersion はどうなったか？\n\nHelm は、頭字語を大文字にするという CamelCase の一般的な規則に従っています。これは `.Capabilities.APIVersions.Has` など、コードの他の場所でも行っています。Helm v3 では、このパターンに従うように `.Chart.ApiVersion` を修正し、`.Chart.APIVersion` に名前変更しました。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/faq/index.mdx",
    "content": "---\ntitle: よくある質問\nsidebar_position: 8\n---\n\n# よくある質問\n\n> Helm 2 と Helm 3 の主な違いはなんですか？\n> このページでは、最もよくある質問に答えることで、理解の助けとなる事柄を説明します。\n\nこのドキュメントを改善する**あなたの助けを歓迎します**。情報の追加、訂正、削除などを行うには、[issue を作る](https://github.com/helm/helm-www/issues)か、pull request を送ってください。\n\n## Helm 2 からの変更点\n\n以下に、Helm 3 で導入されたすべての主要な変更の包括的なリストを示します。\n\n### Tiller の削除\n\n\nHelm 2 の開発サイクルの中で、私たちは Tiller を導入しました。Tiller は共有クラスターで作業をするチームに対して重要な役割を果たしました。Tillerのおかげで複数の異なるオペレータが同じリリースセットとやり取りできるようになったのです。\n\nロールベースアクセス制御 (RBAC) が Kubernetes 1.6 でデフォルトで有効になると、Tiller を本番環境で使用し続けるのはしだいに管理が難しくなっていきました。セキュリティポリシーには非常に多くの可能性があるため、私たちはデフォルトでパーミッシブな設定にする立場を取りました。このおかげで、初めてのユーザーはセキュリティ制御に頭を悩ませずに Helm と Kubernetes を試せるようになりました。残念ながらこのパーミッシブな設定は、本来は持つべきではないユーザーに広範な権限を与えてしまう可能性があります。DevOps や SRE がマルチテナントのクラスターに Tiller をインストールするときには、追加のオペレーションのステップを学ばなければなりませんでした。\n\nコミュニティメンバーの特定のシナリオ下での Helm の使い方について調査をした結果、Tiller のリリース管理システムがステートを保持して Helm のリリース情報のセントラルハブとして動作するためには、クラスタ内のオペレータに依存する必要はなかったことがわかりました。\n\nTiller の主目的は Tiller がなくても実現できたことがわかったため、Helm 3 に関して私たちが下した最初の決定は Tiller を完全に取り除くことでした。\n\nTiller を取り除くと、Helm セキュリティモデルは著しく単純化されました。このおかげで Helm 3 は、最近の Kubernetes が持つモダンなセキュリティ、ID、認証の機能のすべてをサポートできるようになりました。Helm の権限は [kubeconfig\nfile](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) を使用して評価されます。クラスタ管理者は要求に合った任意の粒度でユーザー権限を制限できます。リリースは今でもクラスター内に保存され、Helm の他の機能もそのまま変わりません。\n\n### アップグレード戦略の改善: 3方向戦略的マージパッチ (3-way Strategic Merge Patches)\n\nHelm 2 では、2方向戦略的マージパッチが使用されていました。アップグレード時には、最新のチャートのマニフェストと (`helm upgrade` 中に) 与えられたチャートのマニフェストを比較します。Helm 2 はこの2つのチャート間で変更を比較して、Kubernetes 内のリソースに適用する必要がある変更を決定します。もしクラスターへの変更がチャート外で (たとえば `kubectl edit` などで) 適用されていた場合、この変更は考慮されません。その結果、リソースは過去の状態にロールバックできなくなります。Helm は最後に適用されたチャートのマニフェストだけを最新状態とみなすため、チャートの状態に変更がなければ、現在の状態は変更されていないと判断されるためです。\n\nHelm 3 では、新しく3方向戦略的マージパッチが使われるようになります。パッチの生成をするときに、Helm は古いマニフェスト、その現在の状態、新しいマニフェストを考慮します。\n\n#### 例\n\nLet's go through a few common examples what this change impacts.\n\n##### 実際の状態が変更した時点へのロールバック\n\nYour team just deployed their application to production on Kubernetes using\nHelm. The chart contains a Deployment object where the number of replicas is set\nto three:\n\n```console\n$ helm install myapp ./myapp\n```\n\nA new developer joins the team. On their first day while observing the\nproduction cluster, a horrible coffee-spilling-on-the-keyboard accident happens\nand they `kubectl scale` the production deployment from three replicas down to\nzero.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nAnother developer on your team notices that the production site is down and\ndecides to rollback the release to its previous state:\n\n```console\n$ helm rollback myapp\n```\n\nWhat happens?\n\nIn Helm 2, it would generate a patch, comparing the old manifest against the new\nmanifest. Because this is a rollback, it's the same manifest. Helm would\ndetermine that there is nothing to change because there is no difference between\nthe old manifest and the new manifest. The replica count continues to stay at\nzero. Panic ensues.\n\nIn Helm 3, the patch is generated using the old manifest, the live state, and\nthe new manifest. Helm recognizes that the old state was at three, the live\nstate is at zero and the new manifest wishes to change it back to three, so it\ngenerates a patch to change the state back to three.\n\n##### 実際の状態が変更した時点へのアップグレード\n\nMany service meshes and other controller-based applications inject data into\nKubernetes objects. This can be something like a sidecar, labels, or other\ninformation. Previously if you had the given manifest rendered from a Chart:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nAnd the live state was modified by another application to\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nNow, you want to upgrade the `nginx` image tag to `2.1.0`. So, you upgrade to a\nchart with the given manifest:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nWhat happens?\n\nIn Helm 2, Helm generates a patch of the `containers` object between the old\nmanifest and the new manifest. The cluster's live state is not considered during\nthe patch generation.\n\nThe cluster's live state is modified to look like the following:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nThe sidecar pod is removed from live state. More panic ensues.\n\nIn Helm 3, Helm generates a patch of the `containers` object between the old\nmanifest, the live state, and the new manifest. It notices that the new manifest\nchanges the image tag to `2.1.0`, but live state contains a sidecar container.\n\nThe cluster's live state is modified to look like the following:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### リリース名が名前空間でスコープされるようになった\n\nTiller の削除に伴い、各リリースの情報はどこか別の場所に移動する必要が出てきました。Helm 2 では、リリースの情報は Tiller と同じ名前空間に保存されていました。実際には、一度でもリリースで名前が使われてしまうと、たとえ他の名前空間にデプロイしたとしても、他のリリースが同じ名前を使えないということです。\n\nHelm 3 では、特定のリリースの情報は新しくリリース自体と同じ名前空間に保存されるようになりました。つまり、これからはユーザーが `helm install wrodpress stable/wordpress` というコマンドを2つの別の名前空間で実行できるようになったということです。それぞれのリリースは、現在の名前空間のコンテキストを切り替えることで (例: `helm list --namespace foo`)、`helm list` を使用して参照できます。\n\nネイティブのクラスターの名前空間に大きく近づけたことにより、`helm list` コマンドはデフォルトではすべてのリリースを一覧しなくなりました。代わりに、現在の Kubernetes のコンテキストの名前空間 (たとえば、`kubectl config view --minify` などを実行すると表示される名前空間) の中にあるリリースだけが表示されるようになります。Helm 2 に近い動作にするには、`helm list` に `--all-namespaces` フラッグを与える必要があります。\n\n### Secret がデフォルトのストレージドライバーになった\n\nHelm 3 からは、Secret が[デフォルトのストレージドライバー](/topics/advanced.md#storage-backends)として使われるようになりました。Helm 2 では、ConfigMap がデフォルトでリリース情報を保存するために使用されていました。Helm 2.7.0 でリリース情報を保存するために Secret を使用する新しいストレージバックエンドが実装され、Helm 3 からはデフォルトで使用されるようになりました。\n\nHelm 3 で Secret がデフォルトに変更されたことで、Kubernetes のリリースの Secret の暗号化と組み合わせて、チャートを保護する際のセキュリティが強化できます。\n\nKubernetesでのシークレット暗号化のリリースに関連してチャートを保護する際のセキュリティが強化されます。\n\n[Secret の保存時の暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)は Kubernetes 1.7 でアルファ版の機能として利用可能になり、Kubernetes 1.13 で安定版になりました。これを利用することで、ユーザーは Helm のリリースのメタデータを保存時に暗号化できるようになるため、あとで Vault などを利用する場合によい出発地点となります。\n\n### Go の import path の変更\n\nHelm 3 では、Helm は Go のインポートパスを `k8s.io/helm` から `helm.sh/helm/v3` に変更しました。Helm 3 の Go クライアントライブラリをアップグレードする場合には、手元のインポートパスも変更するようにしてください。\n\n### Capabilities\n\nレンダリングステージで利用可能な `.Capabilities` 組み込みオブジェクトが簡略されました。\n\n[ビルトインオブジェクト](/chart_template_guide/builtin_objects.md)\n\n### チャートの Values の JSONSchema による検証\n\nチャートの値に JSON Schema で制約を与えられるようになりました。これにより、ユーザーから与えられた値がチャートのメンテナが作ったスキーマに従っていることが保証されるため、ユーザーが間違った値をチャートに与えた場合によりよいエラー報告を行えるようになります。\n\n検証は次のいずれかのコマンドが呼ばれたときに行われます。\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\n詳しい情報は、ドキュメントの [Schema files](/topics/charts.md#schema-files) をご覧ください。\n\n### `requirements.yaml` の `Chart.yaml` への統合\n\nチャートの依存関係の管理システムは、requirements.yaml と\nrequirements.lock から、Chart.yaml と Chart.lock に変更されました。私たちは、Helm 3 向けの新しいチャートは新しいフォーマットを使用することを推奨します。しかし、Helm 3 は現在でも Chart API バージョン 1 (`v1`) も理解できるため、既存の `requirements.yaml` ファイルを読み込みます。\n\nHelm 2 の `requirements.yaml` は以下のような形式でした。\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nHelm 3 でも依存関係は同じように表現されますが、`Chart.yaml` 以下に移動されます。\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\n現在でもチャートは `charts/` ディレクトリに配置されるため、`charts/` ディレクトリに追加されたサブチャートは修正なしで動作し続けます。\n\n### Name (または --generate-name) がインストール時に必須となった\n\nHelm 2 では、名前が与えられなかった場合に、自動生成された名前が設定されるようになっていました。本番環境では、この機能は役に立つ場合よりも迷惑になる場合のほうが多いことがわかりました。そのため、Helm 3 では、`helm install` に名前が与えられなかった場合には Helm がエラーを返します。\n\nまだ名前の自動生成が必要なユーザーは、`--generate-name` フラグを使用すると名前を自動生成できます。\n\n### チャートを OCI レジストリに push する\n\nこれは Helm 3 で導入された実験的な機能です。使用するには、環境変数 `HELM_EXPERIMENTAL_OCI=1` を設定してください。\n\nAt a high level, a Chart Repository is a location where Charts can be stored and\nshared. The Helm client packs and ships Helm Charts to a Chart Repository.\nSimply put, a Chart Repository is a basic HTTP server that houses an index.yaml\nfile and some packaged charts.\n\nWhile there are several benefits to the Chart Repository API meeting the most\nbasic storage requirements, a few drawbacks have started to show:\n\n- Chart Repositories have a very hard time abstracting most of the security\n  implementations required in a production environment. Having a standard API\n  for authentication and authorization is very important in production\n  scenarios.\n- Helm’s Chart provenance tools used for signing and verifying the integrity and\n  origin of a chart are an optional piece of the Chart publishing process.\n- In multi-tenant scenarios, the same Chart can be uploaded by another tenant,\n  costing twice the storage cost to store the same content. Smarter chart\n  repositories have been designed to handle this, but it’s not a part of the\n  formal specification.\n- Using a single index file for search, metadata information, and fetching\n  Charts has made it difficult or clunky to design around in secure multi-tenant\n  implementations.\n\nDocker’s Distribution project (also known as Docker Registry v2) is the\nsuccessor to the Docker Registry project. Many major cloud vendors have a\nproduct offering of the Distribution project, and with so many vendors offering\nthe same product, the Distribution project has benefited from many years of\nhardening, security best practices, and battle-testing.\n\nPlease have a look at `helm help chart` and `helm help registry` for more\ninformation on how to package a chart and push it to a Docker registry.\n\nFor more info, please see [this page](/topics/registries.md).\n\n### `helm serve` の廃止\n\n`helm serve` ran a local Chart Repository on your machine for development\npurposes. However, it didn't receive much uptake as a development tool and had\nnumerous issues with its design. In the end, we decided to remove it and split\nit out as a plugin.\n\nFor a similar experience to `helm serve`, have a look at the local filesystem\nstorage option in\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\nand the [servecm plugin](https://github.com/jdolitsky/helm-servecm).\n\n\n### ライブラリチャートのサポート\n\nHelm 3 supports a class of chart called a “library chart”. This is a chart that\nis shared by other charts, but does not create any release artifacts of its own.\nA library chart’s templates can only declare `define` elements. Globally scoped\nnon-`define` content is simply ignored. This allows users to re-use and share\nsnippets of code that can be re-used across many charts, avoiding redundancy and\nkeeping charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nLibrary charts are declared in the dependencies directive in Chart.yaml, and are\ninstalled and managed like any other chart.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nWe’re very excited to see the use cases this feature opens up for chart\ndevelopers, as well as any best practices that arise from consuming library\ncharts.\n\n### Chart.yaml apiVersion のバージョンアップ\n\nWith the introduction of library chart support and the consolidation of\nrequirements.yaml into Chart.yaml, clients that understood Helm 2's package\nformat won't understand these new features. So, we bumped the apiVersion in\nChart.yaml from `v1` to `v2`.\n\n`helm create` now creates charts using this new format, so the default\napiVersion was bumped there as well.\n\nClients wishing to support both versions of Helm charts should inspect the\n`apiVersion` field in Chart.yaml to understand how to parse the package format.\n\n### XDG のベースディレクトリのサポート\n\n[XDG ベースディレクトリの仕様](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)は、ファイルシステム上の設定、データ、キャッシュの各ファイルの格納場所を定めたポータブルな標準です。\n\nIn Helm 2, Helm stored all this information in `~/.helm` (affectionately known\nas `helm home`), which could be changed by setting the `$HELM_HOME` environment\nvariable, or by using the global flag `--home`.\n\nIn Helm 3, Helm now respects the following environment variables as per the XDG\nBase Directory Specification:\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nHelm plugins are still passed `$HELM_HOME` as an alias to `$XDG_DATA_HOME` for\nbackwards compatibility with plugins looking to use `$HELM_HOME` as a scratchpad\nenvironment.\n\nSeveral new environment variables are also passed in to the plugin's environment\nto accommodate this change:\n\n- `$HELM_PATH_CACHE` for the cache path\n- `$HELM_PATH_CONFIG` for the config path\n- `$HELM_PATH_DATA` for the data path\n\nHelm plugins looking to support Helm 3 should consider using these new\nenvironment variables instead.\n\n### CLI コマンドの名前変更\n\nIn order to better align the verbiage from other package managers, `helm delete`\nwas re-named to `helm uninstall`. `helm delete` is still retained as an alias to\n`helm uninstall`, so either form can be used.\n\nIn Helm 2, in order to purge the release ledger, the `--purge` flag had to be\nprovided. This functionality is now enabled by default. To retain the previous\nbehavior, use `helm uninstall --keep-history`.\n\nAdditionally, several other commands were re-named to accommodate the same\nconventions:\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\nThese commands have also retained their older verbs as aliases, so you can\ncontinue to use them in either form.\n\n### 名前空間の自動生成\n\nWhen creating a release in a namespace that does not exist, Helm 2 created the\nnamespace.  Helm 3 follows the behavior of other Kubernetes tooling and returns\nan error if the namespace does not exist.  Helm 3 will create the namespace if\nyou explicitly specify `--create-namespace` flag.\n\n### .Chart.ApiVersion に何が起こりましたか？\n\nHelm follows the typical convention for CamelCasing which is to capitalize an\nacronym. We have done this elsewhere in the code, such as with\n`.Capabilities.APIVersions.Has`. In Helm v3, we corrected `.Chart.ApiVersion`\nto follow this pattern, renaming it to `.Chart.APIVersion`.\n\n## インストール\n\n### Fedora などの Linux ディストリビューション向けの Helm のネイティブパッケージが存在しないのはなぜですか？\n\nThe Helm project does not maintain packages for operating systems and\nenvironments. The Helm community may provide native packages and if the Helm\nproject is made aware of them they will be listed. This is how the Homebrew\nformula was started and listed. If you're interested in maintaining a package,\nwe'd love it.\n\n### なぜ `curl ...|bash` で実行するスクリプトを提供しているのですか？\n\nThere is a script in our repository (`scripts/get-helm-3`) that can be executed\nas a `curl ..|bash` script. The transfers are all protected by HTTPS, and the\nscript does some auditing of the packages it fetches. However, the script has\nall the usual dangers of any shell script.\n\nWe provide it because it is useful, but we suggest that users carefully read the\nscript first. What we'd really like, though, are better packaged releases of\nHelm.\n\n### Helm クライアントのファイルをデフォルト以外の場所に配置するにはどうすればいいですか？\n\nHelm uses the XDG structure for storing files. There are environment variables\nyou can use to override these locations:\n\n- `$XDG_CACHE_HOME`: set an alternative location for storing cached files.\n- `$XDG_CONFIG_HOME`: set an alternative location for storing Helm\n  configuration.\n- `$XDG_DATA_HOME`: set an alternative location for storing Helm data.\n\nNote that if you have existing repositories, you will need to re-add them with\n`helm repo add...`.\n\n## アンインストール\n\n### ローカルの Helm を削除したいです。Helm の全ファイルはどこにありますか？ \n\nAlong with the `helm` binary, Helm stores some files in the following locations:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nThe following table gives the default folder for each of these, by OS:\n\n| Operating System | Cache Path                  | Configuration Path               | Data Path                 |\n|------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux            | `$HOME/.cache/helm `        | `$HOME/.config/helm `            | `$HOME/.local/share/helm` |\n| macOS            | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm `     |\n| Windows          | `%TEMP%\\helm  `             | `%APPDATA%\\helm `                | `%APPDATA%\\helm`          |\n\n## トラブルシューティング\n\n### GKE (Google Container Engine) 上で \"No SSH tunnels currently open\" というメッセージが表示されました\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nエラーメッセージの変種には次のようなものもあります。\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nThe issue is that your local Kubernetes config file must have the correct\ncredentials.\n\nWhen you create a cluster on GKE, it will give you credentials, including SSL\ncertificates and certificate authorities. These need to be stored in a\nKubernetes config file (Default: `~/.kube/config` so that `kubectl` and `helm`\ncan access them.\n\n### Helm 2 からのマイグレーション後、`helm list` リリースの一部 (または全部) が表示されません\n\nIt is likely that you have missed the fact that Helm 3 now uses cluster\nnamespaces throughout to scope releases. This means that for all commands\nreferencing a release you must either:\n\n* rely on the current namespace in the active kubernetes context (as described\n  by the `kubectl config view --minify` command),\n* specify the correct namespace using the `--namespace`/`-n` flag, or\n* for the `helm list` command, specify the `--all-namespaces`/`-A` flag\n\nThis applies to `helm ls`, `helm uninstall`, and all other `helm` commands\nreferencing a release.\n\n### macOS 上で `/etc/.mdns_debug` というファイルへのアクセスがあります。なぜですか？\n\nWe are aware of a case on macOS where Helm will try to access a file named\n`/etc/.mdns_debug`. If the file exists, Helm holds the file handle open while it\nexecutes.\n\nThis is caused by macOS's MDNS library. It attempts to load that file to read\ndebugging settings (if enabled). The file handle probably should not be held open, and\nthis issue has been reported to Apple. However, it is macOS, not Helm, that causes this\nbehavior.\n\nIf you do not want Helm to load this file, you may be able to compile Helm to as\na static library that does not use the host network stack. Doing so will inflate the\nbinary size of Helm, but will prevent the file from being open.\n\nThis issue was originally flagged as a potential security problem. But it has since\nbeen determined that there is no flaw or vulnerability caused by this behavior.\n\n### 以前は動作していた helm repo add が失敗する\n\nIn helm 3.3.1 and before, the command `helm repo add <reponame> <url>` will give\nno output if you attempt to add a repo which already exists. The flag\n`--no-update` would raise an error if the repo was already registered.\n\nIn helm 3.3.2 and beyond, an attempt to add an existing repo will error:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nThe default behavior is now reversed. `--no-update` is now ignored, while if you\nwant to replace (overwrite) an existing repo, you can use `--force-update`.\n\nThis is due to a breaking change for a security fix as explained in the [Helm\n3.3.2 release notes](https://github.com/helm/helm/releases/tag/v3.3.2).\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: インストール\nsidebar_position: 2\n---\n\n## インストール\n\n### Fedora やその他の Linux ディストリビューション向けのネイティブパッケージがないのはなぜですか？\n\nHelm プロジェクトは、各オペレーティングシステムや環境向けのパッケージを保守していません。Helm コミュニティがネイティブパッケージを提供する場合があり、Helm プロジェクトがそれらを認識した場合はリストに掲載されます。Homebrew formula もこの方法で始まり、リストに掲載されました。パッケージの保守に興味がある方は歓迎します。\n\n### `curl ...|bash` スクリプトを提供しているのはなぜですか？\n\nリポジトリには `curl ..|bash` スクリプトとして実行できるスクリプト（`scripts/get-helm-3`）があります。すべての転送は HTTPS で保護されており、スクリプトは取得するパッケージに対していくつかの監査を行います。ただし、このスクリプトには他のシェルスクリプトと同様の危険性があります。\n\nこのスクリプトは便利なため提供していますが、まずスクリプトの内容を注意深く確認することをお勧めします。本当に望まれているのは、より充実したパッケージ版の Helm リリースです。\n\n### Helm クライアントのファイルをデフォルト以外の場所に配置するにはどうすればよいですか？\n\nHelm はファイルの保存に XDG 構造を使用しています。以下の環境変数でこれらの場所を上書きできます:\n\n- `$XDG_CACHE_HOME`: キャッシュファイルの保存場所を変更します。\n- `$XDG_CONFIG_HOME`: Helm 設定の保存場所を変更します。\n- `$XDG_DATA_HOME`: Helm データの保存場所を変更します。\n\n既存のリポジトリがある場合は、`helm repo add...` で再度追加する必要があります。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: トラブルシューティング\nsidebar_position: 4\n---\n\n## トラブルシューティング\n\n### 「\"stable\" chart リポジトリから更新を取得できません」という警告が表示される場合\n\n`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` で利用可能ですが、今後の更新は行われません。\n\n以下のコマンドを実行してリポジトリを修正してください:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\n`incubator` リポジトリについても同様で、アーカイブは https://charts.helm.sh/incubator で利用可能です。以下のコマンドを実行して修正してください:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### 「WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.」という警告が表示される場合\n\n旧 Google Helm chart リポジトリは、新しい Helm chart リポジトリに置き換えられました。\n\n以下のコマンドを実行して、この問題を恒久的に解決してください:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\n`incubator` についても同様のエラーが発生する場合は、以下のコマンドを実行してください:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Helm リポジトリを追加しようとすると「Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available」というエラーが発生する場合\n\nHelm 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 の追加を許可しません。\n\n### GKE (Google Container Engine) で「No SSH tunnels currently open」というエラーが発生する場合\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nこのエラーメッセージの別のバリエーションとして、以下のようなものもあります:\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nこの問題は、ローカルの Kubernetes 設定ファイルに正しい認証情報が含まれていないことが原因です。\n\nGKE でクラスターを作成すると、SSL 証明書や認証局などの認証情報が提供されます。これらの認証情報を Kubernetes 設定ファイル（デフォルト: `~/.kube/config`）に保存して、`kubectl` と `helm` がアクセスできるようにする必要があります。\n\n### Helm 2 から移行後、`helm list` で一部のリリースしか表示されない（または全く表示されない）場合\n\nHelm 3 では、release のスコープにクラスターの namespace を使用するようになったことを見落としている可能性があります。つまり、release を参照するすべてのコマンドで以下のいずれかを行う必要があります:\n\n* アクティブな Kubernetes コンテキストの現在の namespace に依存する（`kubectl config view --minify` コマンドで確認できます）\n* `--namespace`/`-n` フラグを使用して正しい namespace を指定する\n* `helm list` コマンドの場合は、`--all-namespaces`/`-A` フラグを指定する\n\nこれは `helm ls`、`helm uninstall`、およびその他の release を参照するすべての `helm` コマンドに適用されます。\n\n### macOS で Helm が `/etc/.mdns_debug` ファイルにアクセスするのはなぜですか？\n\nmacOS において、Helm が `/etc/.mdns_debug` という名前のファイルにアクセスしようとするケースがあることを認識しています。このファイルが存在する場合、Helm は実行中にファイルハンドルを開いたままにします。\n\nこれは macOS の MDNS ライブラリが原因です。このライブラリは、デバッグ設定を読み込むために（有効な場合）このファイルの読み込みを試みます。ファイルハンドルを開いたままにすべきではありませんが、この問題は Apple に報告されています。ただし、この動作を引き起こしているのは Helm ではなく macOS です。\n\nHelm にこのファイルを読み込ませたくない場合は、ホストのネットワークスタックを使用しない静的ライブラリとして Helm をコンパイルできます。これにより Helm のバイナリサイズは増加しますが、ファイルが開かれることを防ぐことができます。\n\nこの問題は当初、潜在的なセキュリティ問題として報告されました。しかし、その後の調査で、この動作による欠陥や脆弱性は存在しないことが判明しています。\n\n### 以前は動作していた `helm repo add` が失敗する場合\n\nHelm 3.3.1 以前では、`helm repo add <reponame> <url>` コマンドは、既に存在するリポジトリを追加しようとしても何も出力しませんでした。`--no-update` フラグは、リポジトリが既に登録されている場合にエラーを発生させていました。\n\nHelm 3.3.2 以降では、既存のリポジトリを追加しようとするとエラーが発生します:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nデフォルトの動作が逆転しました。`--no-update` は無視されるようになり、既存のリポジトリを置き換える（上書きする）場合は、`--force-update` を使用します。\n\nこれはセキュリティ修正に伴う破壊的変更です。詳細は [Helm 3.3.2 リリースノート](https://github.com/helm/helm/releases/tag/v3.3.2)で説明されています。\n\n### Kubernetes クライアントログの有効化\n\nKubernetes クライアントのデバッグ用ログメッセージを表示するには、[klog](https://pkg.go.dev/k8s.io/klog) フラグを使用します。`-v` フラグで詳細レベルを設定するだけで、ほとんどの場合は十分です。\n\n例:\n\n```\nhelm list -v 6\n```\n\n### Tiller のインストールが動作しなくなり、アクセスが拒否される場合\n\nHelm のリリースは以前 <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 イメージが利用可能です。\n\n以前使用していたストレージバケットから旧バージョンの Helm をダウンロードしようとすると、以下のようなエラーが表示される場合があります:\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\n[旧 Tiller イメージの場所](https://gcr.io/kubernetes-helm/tiller)は、2021 年 8 月にイメージの削除を開始しました。これらのイメージは [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) で利用可能です。例えば、バージョン v2.17.0 をダウンロードするには、以下を:\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\n以下に置き換えます:\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nHelm v2.17.0 で初期化するには:\n\n`helm init —upgrade`\n\nまたは、異なるバージョンが必要な場合は、--tiller-image フラグを使用してデフォルトの場所を上書きし、特定の Helm v2 バージョンをインストールします:\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**注:** 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)を計画してください。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: アンインストール\nsidebar_position: 3\n---\n\n## アンインストール\n\n### Helm をローカルから削除したい場合、関連ファイルはどこにありますか？\n\n`helm` バイナリ本体のほか、Helm は以下の場所にもファイルを保存しています:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\n上記の各環境変数に対応するデフォルトフォルダは、OS ごとに以下のとおりです:\n\n| オペレーティングシステム | キャッシュパス                  | 設定パス                          | データパス                 |\n|--------------------------|--------------------------------|----------------------------------|---------------------------|\n| Linux                    | `$HOME/.cache/helm `           | `$HOME/.config/helm `            | `$HOME/.local/share/helm` |\n| macOS                    | `$HOME/Library/Caches/helm`    | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm `     |\n| Windows                  | `%TEMP%\\helm  `                | `%APPDATA%\\helm `                | `%APPDATA%\\helm`          |\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/glossary/index.mdx",
    "content": "---\ntitle: 用語集\ndescription: Helm のアーキテクチャのコンポーネントを説明するために使用される用語。\nsidebar_position: 9\n---\n\n# 用語集\n\n## チャート\n\nKubernetes リソースのセットを Kubernetes クラスターにインストールするのに\n十分な情報が含まれている Helm パッケージ。\n\nチャートには、`Chart.yaml` ファイル、テンプレート、デフォルト値 (`values.yaml`)、\n依存関係が含まれています。\n\nチャートは明確に定義されたディレクトリ構造で開発され、\n_Chart アーカイブ_ と呼ばれるアーカイブ形式にパッケージ化されます。\n\n## Chart アーカイブ\n\n_Chart アーカイブ_ は、tar 形式で gzip 圧縮された (オプションで署名された) チャートです。\n\n## チャートの依存関係 (サブチャート)\n\nチャートは他のチャートに依存する場合があります。依存関係が発生する方法は2つあります。\n\n- ソフトな依存関係: 別のチャートがクラスターにインストールされていないと、チャートが機能しない可能性があります。\n  Helm はこの場合のツールを提供していません。\n  この場合、依存関係は個別に管理できます。\n- ハードな依存関係: チャートには、(`charts/` ディレクトリ内に) 依存する別のチャートが含まれる場合があります。\n  この場合、チャートをインストールすると、\n  その依存関係がすべてインストールされます。\n  この場合、チャートとその依存関係はコレクションとして管理されます。\n\nチャートが (`helm package` を介して) パッケージ化されると、\nそのすべてのハードな依存関係がチャートにバンドルされます。\n\n## チャートのバージョン\n\nチャートは、[SemVer 2 仕様](https://semver.org) に従ってバージョン管理されています。\nすべてのチャートにバージョン番号が必要です。\n\n## Chart.yaml\n\nチャートに関する情報は、`Chart.yaml` と呼ばれる特別なファイルに保存されます。\nすべてのチャートにこのファイルが必要です。\n\n## Helm (と helm)\n\nHelm は Kubernetes のパッケージマネージャーです。\nオペレーティングシステムのパッケージマネージャーを使用すると、OS にツールを簡単にインストールできます。\nHelm を使用すると、アプリケーションやリソースを Kubernetes クラスターに簡単にインストールできます。\n\n_Helm_ はプロジェクトの名前ですが、コマンドラインクライアントの名前も `helm` です。\n慣例により、プロジェクトについて言うとき、_Helm_ は大文字です。\nクライアントの場合、_helm_ は小文字です。\n\n## Helm 設定ファイル (XDG)\n\nHelm は構成ファイルを XDG ディレクトリに保存します。\nこれらのディレクトリは、`helm` が初めて実行されたときに作成されます。\n\n## Kube Config (KUBECONFIG)\n\nHelm クライアントは、_Kube config_ ファイル形式のファイルを使用して、\nKubernetes クラスターについて学習します。\nデフォルトでは、Helm はこのファイルを `kubectl` が作成した場所 (`$HOME/.kube/config`) で見つけようとします。\n\n## Lint (Linting)\n\nチャートを _lint_ するには、それが Helm チャート標準の規則と要件に従っていることを検証します。\nHelm はこれを行うためのツール、\n特に `helm lint` コマンドを提供します。\n\n## Provenance (Provenance ファイル)\n\nHelm チャートには、チャートの出所とその内容に関する情報を提供する\n_Provenance ファイル_ が添付されている場合があります。\n\nProvenance ファイルは、Helm のセキュリティストーリーの一部です。\nProvenance には、Chart アーカイブファイルの暗号化ハッシュ、Chart.yaml データ、\nおよび署名ブロック (OpenPGP \"clearsign\" ブロック) が含まれています。\nキーチェーンと組み合わせると、チャートユーザーは次のことができるようになります。\n\n- チャートが信頼できる当事者によって署名されたことを検証する\n- チャートのファイルが改ざんされていないことを検証する\n- チャートのメタデータ (`Chart.yaml`) の内容を検証する\n- チャートをその Provenance データにすばやく一致させる\n\nProvenance ファイルには `.prov` 拡張子が付いており、\nチャートリポジトリサーバーまたはその他の HTTP サーバーから提供できます。\n\n## リリース\n\nチャートがインストールされると、\nHelm ライブラリはそのインストールを追跡するための _リリース_ を作成します。\n\n1 つのチャートを同じクラスターに何度もインストールして、さまざまなリリースを作成できます。\nたとえば、`helm install` を異なるリリース名で 3 回実行することで、\n3 つの PostgreSQL データベースをインストールできます。\n\n## リリース番号 (リリースバージョン)\n\n1 つのリリースを複数回更新することができます。\nシーケンシャルカウンタは、リリースの変更を追跡するために使用されます。\n最初に `helm install` を実行すると、_リリース番号_ は 1 になります。\nリリースがアップグレードされたり、ロールバックされたりするたびに、リリース番号は増加します。\n\n## ロールバック\n\nリリースは、新しいチャートまたは構成にアップグレードできます。\nただし、リリース履歴が保存されているため、リリースを前のリリース番号に _ロールバックする_ こともできます。\nこれは、`helm rollback` コマンドで行われます。\n\n重要なのは、ロールバックされたリリースには新しいリリース番号が付与されます。\n\n| 操作  | リリース番号                                       |\n|------------|------------------------------------------------------|\n| インストール    | リリース 1                                            |\n| アップグレード    | リリース 2                                            |\n| アップグレード    | リリース 3                                            |\n| ロールバック 1 | リリース 4 (ただし リリース 1 と同じ構成を実行している) |\n\n上の表は、インストール、アップグレード、およびロールバックで\nリリース番号がどのように増加するかを示しています。\n\n## Helm ライブラリ (または SDK)\n\nHelm ライブラリ (または SDK) は、Kubernetes API サーバーと直接対話して、\nKubernetes リソースをインストール、アップグレード、クエリ、および削除する Go コードを指します。\nプロジェクトにインポートして、\nCLI の代わりに Helm をクライアントライブラリとして使用できます。\n\n## リポジトリ (レポ, チャートリポジトリ)\n\nHelm チャートは、_チャートリポジトリ_ (_リポジトリ_、または単に_レポ_) と呼ばれる\n専用の HTTP サーバに保存できます。\n\nチャートリポジトリサーバは、\nチャートのバッチを記述する `index.yaml` ファイルを提供できるシンプルな HTTP サーバであり、\n各チャートのダウンロード元に関する情報を提供します。\n(多くのチャートリポジトリは、チャートと `index.yaml` ファイルを提供します。)\n\nHelm クライアントは、0個以上のチャートリポジトリを指すことができます。\nデフォルトでは、Helm クライアントはチャートリポジトリで構成されていません。\nチャートリポジトリは、`helm repo add` コマンドを使用していつでも追加できます。\n\n## Values (Values ファイル, values.yaml)\n\nValues は、テンプレートのデフォルトを独自の情報で上書きする方法を提供します。\n\nHelm チャートは「パラメータ化」されています。\nつまり、チャートの開発者は、インストール時にオーバーライドできる構成を公開することがあります。\nたとえば、チャートは、サービスのユーザー名を設定できる `username` フィールドを公開する場合があります。\n\nこれらの公開された変数は、Helm の用語では _values_ と呼ばれます。\n\nValues は、`helm install` および `helm upgrade` の操作中に直接渡すか、\nまたは `values.yaml` ファイルを使用して設定できます。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/_category_.json",
    "content": "{\n  \"link\": { \"type\": \"doc\", \"id\": \"helm-category\" }\n}\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\nKubernetes 用 Helm パッケージマネージャー\n\n### 概要\n\nKubernetes 用パッケージマネージャー\n\nHelm の一般的な操作:\n\n- helm search:    chart を検索します\n- helm pull:      chart をローカルディレクトリにダウンロードして確認します\n- helm install:   chart を Kubernetes にアップロードします\n- helm list:      chart の release を一覧表示します\n\n環境変数:\n\n| 名前                               | 説明                                                                                                |\n|------------------------------------|------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | キャッシュファイルを保存する別の場所を設定します。                                                      |\n| $HELM_CONFIG_HOME                  | Helm 設定を保存する別の場所を設定します。                                                |\n| $HELM_DATA_HOME                    | Helm データを保存する別の場所を設定します。                                                         |\n| $HELM_DEBUG                        | Helm がデバッグモードで実行されているかどうかを示します。                                                      |\n| $HELM_DRIVER                       | バックエンドストレージドライバーを設定します。値: configmap, secret, memory, sql。                                |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | SQL ストレージドライバーが使用する接続文字列を設定します。                                               |\n| $HELM_MAX_HISTORY                  | Helm release 履歴の最大数を設定します。                                                            |\n| $HELM_NAMESPACE                    | Helm 操作に使用する namespace を設定します。                                                            |\n| $HELM_NO_PLUGINS                   | プラグインを無効にします。プラグインを無効にするには HELM_NO_PLUGINS=1 を設定します。                                                 |\n| $HELM_PLUGINS                      | プラグインディレクトリへのパスを設定します。                                                      |\n| $HELM_REGISTRY_CONFIG              | レジストリ設定ファイルへのパスを設定します。                                                          |\n| $HELM_REPOSITORY_CACHE             | リポジトリキャッシュディレクトリへのパスを設定します。                                             |\n| $HELM_REPOSITORY_CONFIG            | リポジトリファイルへのパスを設定します。                                                     |\n| $KUBECONFIG                        | 別の Kubernetes 設定ファイルを設定します（デフォルト \"~/.kube/config\"）。                                |\n| $HELM_KUBEAPISERVER                | 認証用の Kubernetes API サーバーエンドポイントを設定します。                                                  |\n| $HELM_KUBECAFILE                   | Kubernetes 認証局ファイルを設定します。                                                             |\n| $HELM_KUBEASGROUPS                 | 偽装に使用するグループをカンマ区切りのリストで設定します。                                      |\n| $HELM_KUBEASUSER                   | 操作時に偽装するユーザー名を設定します。                                                         |\n| $HELM_KUBECONTEXT                  | kubeconfig コンテキストの名前を設定します。                                                    |\n| $HELM_KUBETOKEN                    | 認証に使用する Bearer KubeToken を設定します。                                                          |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | Kubernetes API サーバーの証明書検証をスキップするかどうかを示します（非セキュア）。                |\n| $HELM_KUBETLS_SERVER_NAME          | Kubernetes API サーバー証明書の検証に使用するサーバー名を設定します。                                 |\n| $HELM_BURST_LIMIT                  | サーバーに多数の CRD が含まれる場合のデフォルトバースト制限を設定します（デフォルト 100、無効にするには -1）。         |\n| $HELM_QPS                          | 高いバースト値を超える多数の呼び出しがある場合の QPS（秒間クエリ数）を設定します。 |\n\nHelm は以下の設定順序に基づいてキャッシュ、設定、データを保存します:\n\n- HELM_*_HOME 環境変数が設定されている場合、その値が使用されます\n- それ以外の場合、XDG ベースディレクトリ仕様をサポートするシステムでは XDG 変数が使用されます\n- 他の場所が設定されていない場合、オペレーティングシステムに基づいたデフォルトの場所が使用されます\n\nデフォルトディレクトリはオペレーティングシステムによって異なります。デフォルトは以下のとおりです:\n\n| OS | キャッシュパス                | 設定パス             | データパス               |\n|------------------|---------------------------|--------------------------------|-------------------------|\n| Linux            | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm |\n| macOS            | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm      |\n| Windows          | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm          |\n\n\n### オプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n  -h, --help                            help for helm\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm completion](/helm/helm_completion.md)\t - 指定したシェル用の自動補完スクリプトを生成します\n* [helm create](/helm/helm_create.md)\t - 指定した名前で新しい chart を作成します\n* [helm dependency](/helm/helm_dependency.md)\t - chart の依存関係を管理します\n* [helm env](/helm/helm_env.md)\t - Helm クライアントの環境情報を表示します\n* [helm get](/helm/helm_get.md)\t - 指定した release の詳細情報をダウンロードします\n* [helm history](/helm/helm_history.md)\t - release の履歴を取得します\n* [helm install](/helm/helm_install.md)\t - chart をインストールします\n* [helm lint](/helm/helm_lint.md)\t - chart の問題点を検査します\n* [helm list](/helm/helm_list.md)\t - release を一覧表示します\n* [helm package](/helm/helm_package.md)\t - chart ディレクトリを chart アーカイブにパッケージ化します\n* [helm plugin](/helm/helm_plugin.md)\t - Helm プラグインをインストール、一覧表示、またはアンインストールします\n* [helm pull](/helm/helm_pull.md)\t - リポジトリから chart をダウンロードし、（オプションで）ローカルディレクトリに展開します\n* [helm push](/helm/helm_push.md)\t - chart をリモートにプッシュします\n* [helm registry](/helm/helm_registry.md)\t - レジストリにログインまたはログアウトします\n* [helm repo](/helm/helm_repo.md)\t - chart リポジトリの追加、一覧表示、削除、更新、およびインデックス作成を行います\n* [helm rollback](/helm/helm_rollback.md)\t - release を以前のリビジョンにロールバックします\n* [helm search](/helm/helm_search.md)\t - chart をキーワード検索します\n* [helm show](/helm/helm_show.md)\t - chart の情報を表示します\n* [helm status](/helm/helm_status.md)\t - 指定した release のステータスを表示します\n* [helm template](/helm/helm_template.md)\t - テンプレートをローカルでレンダリングします\n* [helm test](/helm/helm_test.md)\t - release のテストを実行します\n* [helm uninstall](/helm/helm_uninstall.md)\t - release をアンインストールします\n* [helm upgrade](/helm/helm_upgrade.md)\t - release をアップグレードします\n* [helm verify](/helm/helm_verify.md)\t - 指定したパスの chart が署名されており有効であることを検証します\n* [helm version](/helm/helm_version.md)\t - クライアントのバージョン情報を出力します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\n指定したシェル用の自動補完スクリプトを生成します\n\n### 概要\n\n指定したシェル用に Helm の自動補完スクリプトを生成します。\n\n\n### オプション\n\n```\n  -h, --help   help for completion\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n* [helm completion bash](/helm/helm_completion_bash.md)\t - bash 用の自動補完スクリプトを生成します\n* [helm completion fish](/helm/helm_completion_fish.md)\t - fish 用の自動補完スクリプトを生成します\n* [helm completion powershell](/helm/helm_completion_powershell.md)\t - PowerShell 用の自動補完スクリプトを生成します\n* [helm completion zsh](/helm/helm_completion_zsh.md)\t - zsh 用の自動補完スクリプトを生成します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\nbash 用の自動補完スクリプトを生成します\n\n### 概要\n\nHelm の bash シェル用自動補完スクリプトを生成します。\n\n現在のシェルセッションに補完を読み込むには：\n\n    source <(helm completion bash)\n\n新しいセッションごとに補完を読み込むには、次のコマンドを一度実行します：\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n\n```\nhelm completion bash [flags]\n```\n\n### オプション\n\n```\n  -h, --help              help for bash\n      --no-descriptions   disable completion descriptions\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm completion](/helm/helm_completion.md)\t - 指定したシェル用の自動補完スクリプトを生成します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\nfish 用の自動補完スクリプトを生成します\n\n### 概要\n\nHelm の fish シェル用自動補完スクリプトを生成します。\n\n現在のシェルセッションに補完を読み込むには：\n\n    helm completion fish | source\n\n新しいセッションごとに補完を読み込むには、次のコマンドを一度実行します：\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\nこの設定を有効にするには、新しいシェルを起動する必要があります。\n\n\n```\nhelm completion fish [flags]\n```\n\n### オプション\n\n```\n  -h, --help              help for fish\n      --no-descriptions   disable completion descriptions\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm completion](/helm/helm_completion.md)\t - 指定したシェル用の自動補完スクリプトを生成します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\nPowerShell 用の自動補完スクリプトを生成します\n\n### 概要\n\nHelm の PowerShell 用自動補完スクリプトを生成します。\n\n現在のシェルセッションに補完を読み込むには：\n\n    PS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\n新しいセッションごとに補完を自動で読み込むには、上記コマンドの出力を\nPowerShell プロファイルに追加してください。\n\n\n```\nhelm completion powershell [flags]\n```\n\n### オプション\n\n```\n  -h, --help              help for powershell\n      --no-descriptions   disable completion descriptions\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm completion](/helm/helm_completion.md)\t - 指定したシェル用の自動補完スクリプトを生成します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\nzsh 用の自動補完スクリプトを生成します\n\n### 概要\n\nHelm の zsh シェル用自動補完スクリプトを生成します。\n\n現在のシェルセッションに補完を読み込むには：\n\n    source <(helm completion zsh)\n\n新しいセッションごとに補完を読み込むには、次のコマンドを一度実行します：\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### オプション\n\n```\n  -h, --help              help for zsh\n      --no-descriptions   disable completion descriptions\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm completion](/helm/helm_completion.md)\t - 指定したシェル用の自動補完スクリプトを生成します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n\n指定された名前で新しい chart を作成します\n\n### 概要\n\nこのコマンドは、chart で一般的に使用されるファイルやディレクトリを含む chart ディレクトリを作成します。\n\n例えば、`helm create foo` を実行すると、次のようなディレクトリ構造が作成されます。\n\n    foo/\n    ├── .helmignore   # Helm chart のパッケージ化時に無視するパターンを記述します\n    ├── Chart.yaml    # chart に関する情報\n    ├── values.yaml   # テンプレートのデフォルト値\n    ├── charts/       # この chart が依存する chart\n    └── templates/    # テンプレートファイル\n        └── tests/    # テストファイル\n\n`helm create` は引数としてパスを受け取ります。指定されたパスにディレクトリが存在しない場合、Helm は必要に応じてディレクトリを作成します。指定された出力先が既に存在し、そのディレクトリにファイルがある場合、競合するファイルは上書きされますが、それ以外のファイルはそのまま残ります。\n\n\n```\nhelm create NAME [flags]\n```\n\n### オプション\n\n```\n  -h, --help             help for create\n  -p, --starter string   Helm starter scaffold の名前または絶対パス\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\nchart の依存関係を管理します\n\n### 概要\n\nchart の依存関係を管理します。\n\nHelm chart は依存関係を `charts/` ディレクトリに格納します。chart 開発者にとっては、すべての依存関係を宣言する `Chart.yaml` で依存関係を管理する方が簡単な場合が多いです。\n\ndependency コマンドはこのファイルを操作し、必要な依存関係と `charts/` ディレクトリに格納された実際の依存関係を簡単に同期できるようにします。\n\nたとえば、次の Chart.yaml は 2 つの依存関係を宣言しています:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\n`name` には chart の名前を指定します。この名前は、その chart の `Chart.yaml` ファイル内の名前と一致する必要があります。\n\n`version` フィールドには、セマンティックバージョンまたはバージョン範囲を指定します。\n\n`repository` URL は Chart Repository を指す必要があります。Helm は URL に `/index.yaml` を追加することで、chart リポジトリのインデックスを取得できることを期待します。注意: `repository` はエイリアスにすることもできます。エイリアスは `alias:` または `@` で始める必要があります。\n\nバージョン 2.2.0 以降、repository はローカルに格納された依存 chart のディレクトリパスとして定義することもできます。パスは `file://` のプレフィックスで始める必要があります。たとえば:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\n依存 chart がローカルから取得される場合、`helm repo add` でリポジトリを追加する必要はありません。この場合もバージョンマッチングがサポートされます。\n\n\n### オプション\n\n```\n  -h, --help   help for dependency\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用の Helm パッケージマネージャー\n* [helm dependency build](/helm/helm_dependency_build.md)\t - Chart.lock ファイルに基づいて charts/ ディレクトリを再構築します\n* [helm dependency list](/helm/helm_dependency_list.md)\t - 指定した chart の依存関係を一覧表示します\n* [helm dependency update](/helm/helm_dependency_update.md)\t - Chart.yaml の内容に基づいて charts/ ディレクトリを更新します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\n`Chart.lock` ファイルに基づいて `charts/` ディレクトリを再構築します\n\n### 概要\n\n`Chart.lock` ファイルから `charts/` ディレクトリを構築します。\n\nこのコマンドは、ロックファイルで指定された状態に chart の依存関係を再構築します。`helm dependency update` とは異なり、依存関係の再解決は行いません。\n\nロックファイルが見つからない場合、`helm dependency build` は `helm dependency update` と同じ動作をします。\n\n\n```\nhelm dependency build CHART [flags]\n```\n\n### オプション\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for build\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm dependency](/helm/helm_dependency.md)\t - chart の依存関係を管理します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\n指定した chart の依存関係を一覧表示します\n\n### 概要\n\nchart で宣言されているすべての依存関係を一覧表示します。\n\nこのコマンドは、chart アーカイブと chart ディレクトリの両方を入力として受け付けます。chart の内容を変更することはありません。\n\nchart を読み込めない場合はエラーが発生します。\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### オプション\n\n```\n  -h, --help                 help for list\n      --max-col-width uint   出力テーブルの最大列幅 (default 80)\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm dependency](/helm/helm_dependency.md)\t - chart の依存関係を管理します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\n`Chart.yaml` の内容に基づいて `charts/` ディレクトリを更新します\n\n### 概要\n\nディスク上の依存関係を `Chart.yaml` に合わせて更新します。\n\nこのコマンドは、`Chart.yaml` で指定された必要な chart が `charts/` ディレクトリに存在し、適切なバージョンであることを確認します。依存関係を満たす最新の chart をダウンロードし、古い依存関係を削除します。\n\n更新が成功すると、依存関係を正確なバージョンで再構築するために使用できるロックファイルが生成されます。\n\n依存関係は `Chart.yaml` に記載されている必要はありません。そのため、update コマンドが chart を削除するのは、(a) `Chart.yaml` ファイルに記載されていて、かつ (b) バージョンが正しくない場合のみです。\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### オプション\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for update\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm dependency](/helm/helm_dependency.md)\t - chart の依存関係を管理します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\nHelm クライアントの環境情報を表示します\n\n### 概要\n\nHelm が使用しているすべての環境情報を出力します。\n\n\n```\nhelm env [flags]\n```\n\n### オプション\n\n```\n  -h, --help   help for env\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\n指定した release の詳細情報を取得します\n\n### 概要\n\nこのコマンドは、release に関する詳細情報を取得するための複数のサブコマンドで構成されています。以下の情報を取得できます:\n\n- release 生成時に使用された values\n- 生成された manifest ファイル\n- chart が提供する notes\n- release に関連付けられた hook\n- release のメタデータ\n\n\n### オプション\n\n```\n  -h, --help   help for get\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n* [helm get all](/helm/helm_get_all.md)\t - 指定した release のすべての情報を取得します\n* [helm get hooks](/helm/helm_get_hooks.md)\t - 指定した release のすべての hook を取得します\n* [helm get manifest](/helm/helm_get_manifest.md)\t - 指定した release の manifest を取得します\n* [helm get metadata](/helm/helm_get_metadata.md)\t - 指定した release のメタデータを取得します\n* [helm get notes](/helm/helm_get_notes.md)\t - 指定した release の notes を取得します\n* [helm get values](/helm/helm_get_values.md)\t - 指定した release の values ファイルを取得します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\n指定された release のすべての情報をダウンロードします\n\n### 概要\n\nこのコマンドは、指定された release に関する notes、hook、提供された values、生成された manifest ファイルなどの情報を、読みやすい形式で出力します。\n\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### オプション\n\n```\n  -h, --help              help for all\n      --revision int      get the named release with revision\n      --template string   go template for formatting the output, eg: {{.Release.Name}}\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm get](/helm/helm_get.md)\t - 指定された release の拡張情報をダウンロードします\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\n指定された release のすべての hook をダウンロードします\n\n### 概要\n\nこのコマンドは、指定された release の hook をダウンロードします。\n\nhook は YAML 形式で出力され、`---\\n` で区切られます。\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### オプション\n\n```\n  -h, --help           help for hooks\n      --revision int   get the named release with revision\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm get](/helm/helm_get.md)\t - 指定された release の拡張情報をダウンロードします\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\n指定された release のマニフェストをダウンロードします\n\n### 概要\n\nこのコマンドは、指定された release に対して生成されたマニフェストを取得します。\n\nマニフェストは、この release の chart から生成された Kubernetes リソースを YAML 形式でエンコードしたものです。chart が他の chart に依存している場合、それらのリソースもマニフェストに含まれます。\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### オプション\n\n```\n  -h, --help           help for manifest\n      --revision int   get the named release with revision\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm get](/helm/helm_get.md)\t - 指定された release の拡張情報をダウンロードします\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\n指定された release のメタデータを取得します\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### オプション\n\n```\n  -h, --help            help for metadata\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    specify release revision\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm get](/helm/helm_get.md)\t - 指定された release の拡張情報をダウンロードします\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\n指定された release のノートをダウンロードします\n\n### 概要\n\nこのコマンドは、指定された release の chart が提供するノートを表示します。\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### オプション\n\n```\n  -h, --help           help for notes\n      --revision int   get the named release with revision\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm get](/helm/helm_get.md)\t - 指定された release の拡張情報をダウンロードします\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\n指定された release の values ファイルをダウンロードします\n\n### 概要\n\nこのコマンドは、指定された release の values ファイルをダウンロードします。\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### オプション\n\n```\n  -a, --all             dump all (computed) values\n  -h, --help            help for values\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    get the named release with revision\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm get](/helm/helm_get.md)\t - 指定された release の拡張情報をダウンロードします\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\nrelease の履歴を表示します\n\n### 概要\n\nこのコマンドは、指定した release の履歴（リビジョン一覧）を表示します。\n\nデフォルトでは最大 256 件のリビジョンが返されます。`--max` オプションで取得するリビジョンの最大件数を設定できます。\n\n履歴はテーブル形式で出力されます。例:\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### オプション\n\n```\n  -h, --help            help for history\n      --max int         履歴に含めるリビジョンの最大件数 (default 256)\n  -o, --output format   指定したフォーマットで出力します。使用可能な値: table, json, yaml (default table)\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\nchart をインストールします\n\n### 概要\n\nこのコマンドは chart アーカイブをインストールします。\n\ninstall の引数には、chart 参照、パッケージ化された chart へのパス、展開された chart ディレクトリへのパス、または URL を指定する必要があります。\n\nchart の値をオーバーライドするには、`--values` フラグでファイルを指定するか、`--set` フラグでコマンドラインから設定を渡します。文字列値を強制する場合は `--set-string` を使用します。値自体がコマンドラインには長すぎる場合や動的に生成される場合は、`--set-file` を使用して個々の値をファイルから設定できます。また、`--set-json` を使用してコマンドラインから JSON 値（スカラー/オブジェクト/配列）を設定することもできます。\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\nまたは\n\n    $ helm install --set name=prod myredis ./redis\n\nまたは\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\nまたは\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\nまたは\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\n`--values`/`-f` フラグは複数回指定できます。最後（右端）に指定されたファイルが優先されます。例えば、myvalues.yaml と override.yaml の両方に 'Test' というキーが含まれている場合、override.yaml に設定された値が優先されます。\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\n`--set` フラグは複数回指定できます。最後（右端）に指定された値が優先されます。例えば、'foo' というキーに対して 'bar' と 'newbar' の両方が設定されている場合、'newbar' の値が優先されます。\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\n同様に、次の例では 'foo' は '[\"four\"]' に設定されます。\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\nまた、次の例では 'foo' は '{\"key1\":\"value1\",\"key2\":\"bar\"}' に設定されます。\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\nchart を実際にインストールせずに release の生成されたマニフェストを確認するには、`--debug` フラグと `--dry-run` フラグを組み合わせて使用できます。\n\n`--dry-run` フラグは、Secret など機密情報を含む可能性があるリソースを含め、生成されたすべての chart マニフェストを出力します。Kubernetes の Secret を非表示にするには `--hide-secret` フラグを使用してください。これらのフラグの使用方法とタイミングには十分注意してください。\n\n`--verify` が設定されている場合、chart には provenance ファイルが必須であり、provenance ファイルはすべての検証ステップを通過する必要があります。\n\nインストールする chart を指定する方法は 6 通りあります。\n\n1. chart 参照: helm install mymaria example/mariadb\n2. パッケージ化された chart へのパス: helm install mynginx ./nginx-1.2.3.tgz\n3. 展開された chart ディレクトリへのパス: helm install mynginx ./nginx\n4. 絶対 URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. chart 参照とリポジトリ URL: helm install --repo https://example.com/charts/ mynginx nginx\n6. OCI レジストリ: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\nCHART 参照\n\nchart 参照は、chart リポジトリ内の chart を参照する便利な方法です。\n\nリポジトリ接頭辞を含む chart 参照（`example/mariadb`）を使用すると、Helm はローカル設定で 'example' という名前の chart リポジトリを探し、そのリポジトリ内で 'mariadb' という名前の chart を探します。`--devel` フラグを指定して開発バージョン（alpha、beta、リリース候補）も含めるか、`--version` フラグでバージョン番号を指定しない限り、その chart の最新の安定バージョンがインストールされます。\n\nchart リポジトリの一覧を表示するには `helm repo list` を使用します。リポジトリ内の chart を検索するには `helm search` を使用します。\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### オプション\n\n```\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for install\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\nchart の問題点を検査します\n\n### 概要\n\nこのコマンドは、chart のパスを受け取り、一連のテストを実行して chart が正しく構成されているか検証します。\n\nインストールに失敗する原因となる問題を検出した場合は、[ERROR] メッセージを出力します。規約や推奨事項に反する問題を検出した場合は、[WARNING] メッセージを出力します。\n\n\n```\nhelm lint PATH [flags]\n```\n\n### オプション\n\n```\n  -h, --help                      help for lint\n      --kube-version string       capabilities と非推奨チェックに使用する Kubernetes バージョン\n      --quiet                     警告とエラーのみを出力します\n      --set stringArray           コマンドラインで値を設定します（複数指定、またはカンマ区切りで指定可能: key1=val1,key2=val2）\n      --set-file stringArray      コマンドラインで指定したファイルから値を設定します（複数指定、またはカンマ区切りで指定可能: key1=path1,key2=path2）\n      --set-json stringArray      コマンドラインで JSON 値を設定します（複数指定、またはカンマ区切りで指定可能: key1=jsonval1,key2=jsonval2）\n      --set-literal stringArray   コマンドラインでリテラル STRING 値を設定します\n      --set-string stringArray    コマンドラインで STRING 値を設定します（複数指定、またはカンマ区切りで指定可能: key1=val1,key2=val2）\n      --skip-schema-validation    設定すると、JSON スキーマ検証を無効にします\n      --strict                    lint の警告を失敗として扱います\n  -f, --values strings            YAML ファイルまたは URL で値を指定します（複数指定可能）\n      --with-subcharts            依存 chart も lint します\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\nrelease を一覧表示します\n\n### 概要\n\nこのコマンドは、指定した namespace のすべての release を一覧表示します（namespace を指定しない場合は現在の namespace コンテキストを使用します）。\n\nデフォルトでは、deployed または failed 状態の release のみを表示します。`--uninstalled` や `--all` などのフラグを使用すると、この動作を変更できます。これらのフラグは組み合わせることもできます: `--uninstalled --failed`。\n\nデフォルトではアルファベット順にソートされます。リリース日でソートするには `-d` フラグを使用してください。\n\n`--filter` フラグを指定すると、フィルターとして扱われます。フィルターは正規表現（Perl 互換）で、release のリストに適用されます。フィルターに一致した項目のみが返されます。\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\n結果が見つからない場合、`helm list` は終了コード 0 で終了しますが、出力はありません（`-q` フラグを指定していない場合はヘッダーのみ表示されます）。\n\nデフォルトでは最大 256 件の結果が返されます。これを制限するには `--max` フラグを使用してください。`--max` を 0 に設定してもすべての結果が返されるわけではありません。代わりにサーバーのデフォルト値が使用され、これは 256 よりもはるかに大きい場合があります。`--max` フラグと `--offset` フラグを組み合わせることで、結果をページングできます。\n\n\n```\nhelm list [flags]\n```\n\n### オプション\n\n```\n  -a, --all                  フィルターを適用せずにすべての release を表示します\n  -A, --all-namespaces       すべての namespace の release を一覧表示します\n  -d, --date                 リリース日でソートします\n      --deployed             deployed 状態の release を表示します。他のフラグが指定されていない場合、自動的に有効になります\n      --failed               failed 状態の release を表示します\n  -f, --filter string        正規表現（Perl 互換）。この表現に一致するすべての release が結果に含まれます\n  -h, --help                 help for list\n  -m, --max int              取得する release の最大数 (default 256)\n      --no-headers           デフォルトの出力形式を使用する際にヘッダーを表示しません\n      --offset int           リストの次の release インデックス。開始値からのオフセットに使用します\n  -o, --output format        指定した形式で出力します。使用可能な値: table, json, yaml (default table)\n      --pending              pending 状態の release を表示します\n  -r, --reverse              ソート順を逆にします\n  -l, --selector string      フィルタリングに使用するセレクター（ラベルクエリ）。'='、'=='、'!=' をサポートします（例: -l key1=value1,key2=value2）。secret（デフォルト）および configmap ストレージバックエンドでのみ動作します\n  -q, --short                短い（静か）なリスト形式で出力します\n      --superseded           superseded 状態の release を表示します\n      --time-format string   Go の time フォーマッターを使用して時刻をフォーマットします。例: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          uninstalled 状態の release を表示します（'helm uninstall --keep-history' が使用された場合）\n      --uninstalling         現在アンインストール中の release を表示します\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\nchart ディレクトリを chart アーカイブにパッケージ化します\n\n### 概要\n\nこのコマンドは chart をバージョン付き chart アーカイブファイルにパッケージ化します。パスが指定された場合、そのパスにある chart を探し（`Chart.yaml` ファイルが含まれている必要があります）、そのディレクトリをパッケージ化します。\n\nバージョン付き chart アーカイブは Helm パッケージリポジトリで使用されます。\n\nchart に署名するには `--sign` フラグを使用します。ほとんどの場合、`--keyring path/to/secret/keys` と `--key keyname` も指定する必要があります。\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\n`--keyring` を指定しない場合、環境設定で別の場所が指定されていない限り、Helm は公開キーリングをデフォルトとして使用します。\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### オプション\n\n```\n      --app-version string         set the appVersion on the chart to this version\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -u, --dependency-update          update dependencies from \"Chart.yaml\" to dir \"charts/\" before packaging\n  -d, --destination string         location to write the chart. (default \".\")\n  -h, --help                       help for package\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key string                 name of the key to use when signing. Used if --sign is true\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of a public keyring (default \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     location of a file which contains the passphrase for the signing key. Use \"-\" in order to read from stdin.\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --sign                       use a PGP private key to sign this package\n      --username string            chart repository username where to locate the requested chart\n      --version string             set the version on the chart to this semver version\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用の Helm パッケージマネージャー\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\nHelm プラグインのインストール、一覧表示、アンインストールを行います\n\n### 概要\n\nクライアント側の Helm プラグインを管理します。\n\n\n### オプション\n\n```\n  -h, --help   help for plugin\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー\n* [helm plugin install](/helm/helm_plugin_install.md)\t - Helm プラグインをインストールします\n* [helm plugin list](/helm/helm_plugin_list.md)\t - インストール済みの Helm プラグインを一覧表示します\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md)\t - 1つまたは複数の Helm プラグインをアンインストールします\n* [helm plugin update](/helm/helm_plugin_update.md)\t - 1つまたは複数の Helm プラグインを更新します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\nHelm プラグインをインストールします\n\nVCS リポジトリの URL またはローカルパスからプラグインをインストールします。\n\n```\nhelm plugin install [options] <path|url> [flags]\n```\n\n### オプション\n\n```\n  -h, --help             help for install\n      --version string   specify a version constraint. If this is not specified, the latest version is installed\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm plugin](/helm/helm_plugin.md)\t - Helm プラグインのインストール、一覧表示、アンインストールを行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\nインストール済みの Helm プラグインを一覧表示します\n\n```\nhelm plugin list [flags]\n```\n\n### オプション\n\n```\n  -h, --help   help for list\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm plugin](/helm/helm_plugin.md)\t - Helm プラグインのインストール、一覧表示、アンインストールを行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\n1つまたは複数の Helm プラグインをアンインストールします\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### オプション\n\n```\n  -h, --help   help for uninstall\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm plugin](/helm/helm_plugin.md)\t - Helm プラグインのインストール、一覧表示、アンインストールを行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\n1つまたは複数の Helm プラグインを更新します\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### オプション\n\n```\n  -h, --help   help for update\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm plugin](/helm/helm_plugin.md)\t - Helm プラグインのインストール、一覧表示、アンインストールを行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\nリポジトリから chart をダウンロードし、（オプションで）ローカルディレクトリに展開します\n\n### 概要\n\nパッケージリポジトリからパッケージを取得し、ローカルにダウンロードします。\n\nパッケージを検査、変更、再パッケージ化する際に便利です。また、chart をインストールせずに暗号検証を行うためにも使用できます。\n\nダウンロード後に chart を展開するオプションがあります。この場合、chart 用のディレクトリが作成され、その中に展開されます。\n\n`--verify` フラグが指定された場合、要求された chart には provenance ファイルが必須であり、検証プロセスに合格する必要があります。いずれかの条件を満たさない場合はエラーとなり、chart はローカルに保存されません。\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### オプション\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -d, --destination string         location to write the chart. If this and untardir are specified, untardir is appended to this (default \".\")\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help                       help for pull\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --prov                       fetch the provenance file, but don't perform verification\n      --repo string                chart repository url where to locate the requested chart\n      --untar                      if set to true, will untar the chart after downloading it\n      --untardir string            if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default \".\")\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用の Helm パッケージマネージャー\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\nchart をリモートにプッシュします\n\n### 概要\n\nchart をレジストリにアップロードします。\n\nchart に関連する provenance ファイルがある場合、それも一緒にアップロードされます。\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### オプション\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify registry client using this SSL certificate file\n  -h, --help                       help for push\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart upload\n      --key-file string            identify registry client using this SSL key file\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart upload\n      --username string            chart repository username where to locate the requested chart\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用の Helm パッケージマネージャー\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\nレジストリへのログインおよびログアウトを行います\n\n### 概要\n\nこのコマンドは、レジストリを操作するための複数のサブコマンドで構成されています。\n\n\n### オプション\n\n```\n  -h, --help   help for registry\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用の Helm パッケージマネージャー\n* [helm registry login](/helm/helm_registry_login.md)\t - レジストリにログインします\n* [helm registry logout](/helm/helm_registry_logout.md)\t - レジストリからログアウトします\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\nレジストリにログインします\n\n### 概要\n\nリモートレジストリへの認証を行います。\n\n```\nhelm registry login [host] [flags]\n```\n\n### オプション\n\n```\n      --ca-file string     verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string   identify registry client using this SSL certificate file\n  -h, --help               help for login\n      --insecure           allow connections to TLS registry without certs\n      --key-file string    identify registry client using this SSL key file\n  -p, --password string    registry password or identity token\n      --password-stdin     read password or identity token from stdin\n      --plain-http         use insecure HTTP connections for the chart upload\n  -u, --username string    registry username\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm registry](/helm/helm_registry.md)\t - レジストリへのログインおよびログアウトを行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\nレジストリからログアウトします\n\n### 概要\n\nリモートレジストリに保存されている認証情報を削除します。\n\n```\nhelm registry logout [host] [flags]\n```\n\n### オプション\n\n```\n  -h, --help   help for logout\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm registry](/helm/helm_registry.md)\t - レジストリへのログインおよびログアウトを行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\nchart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います\n\n### 概要\n\nこのコマンドには、chart リポジトリを操作するための複数のサブコマンドがあります。\n\nリポジトリの追加、削除、一覧表示、インデックス作成に使用できます。\n\n\n### オプション\n\n```\n  -h, --help   help for repo\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー\n* [helm repo add](/helm/helm_repo_add.md)\t - chart リポジトリを追加します\n* [helm repo index](/helm/helm_repo_index.md)\t - パッケージ化された chart を含むディレクトリからインデックスファイルを生成します\n* [helm repo list](/helm/helm_repo_list.md)\t - chart リポジトリを一覧表示します\n* [helm repo remove](/helm/helm_repo_remove.md)\t - chart リポジトリを削除します\n* [helm repo update](/helm/helm_repo_update.md)\t - chart リポジトリの最新情報をローカルに取得します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\nchart リポジトリを追加します\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### オプション\n\n```\n      --allow-deprecated-repos     完全に削除された公式リポジトリの追加を許可します（デフォルトでは禁止）\n      --ca-file string             HTTPS 対応サーバーの証明書を検証するための CA バンドル\n      --cert-file string           HTTPS クライアント認証に使用する SSL 証明書ファイル\n      --force-update               リポジトリが既に存在する場合、上書きします\n  -h, --help                       help for add\n      --insecure-skip-tls-verify   リポジトリの TLS 証明書検証をスキップします\n      --key-file string            HTTPS クライアント認証に使用する SSL 鍵ファイル\n      --no-update                  無視されます。以前は強制更新を無効にしていましたが、現在は --force-update に置き換えられました。\n      --pass-credentials           すべてのドメインに認証情報を渡します\n      --password string            chart リポジトリのパスワード\n      --password-stdin             chart リポジトリのパスワードを標準入力から読み取ります\n      --timeout duration           インデックスファイルのダウンロード完了を待機する時間 (default 2m0s)\n      --username string            chart リポジトリのユーザー名\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm repo](/helm/helm_repo.md)\t - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\nchart リポジトリのインデックスファイルを生成します\n\n### 概要\n\nカレントディレクトリを読み取り、見つかった chart に基づいてインデックスファイルを生成し、結果を同ディレクトリの `index.yaml` に書き込みます。\n\nこのコマンドは chart リポジトリ用の `index.yaml` ファイルを作成します。chart の参照先となる絶対 URL を設定するには `--url` フラグを使用します。\n\n生成したインデックスを既存のインデックスファイルにマージするには `--merge` フラグを使用します。この場合、カレントディレクトリで見つかった chart が `--merge` で指定したインデックスにマージされます。同じ chart が存在する場合はローカルの chart が優先されます。\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### オプション\n\n```\n  -h, --help           help for index\n      --json           JSON 形式で出力します\n      --merge string   生成したインデックスを指定したインデックスファイルにマージします\n      --url string     chart リポジトリの URL\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm repo](/helm/helm_repo.md)\t - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\nchart リポジトリを一覧表示します\n\n```\nhelm repo list [flags]\n```\n\n### オプション\n\n```\n  -h, --help            help for list\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm repo](/helm/helm_repo.md)\t - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nchart リポジトリを削除します\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### オプション\n\n```\n  -h, --help   help for remove\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm repo](/helm/helm_repo.md)\t - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\nchart リポジトリの最新情報をローカルに取得します\n\n### 概要\n\n各 chart リポジトリから最新の chart 情報を取得します。\n取得した情報はローカルにキャッシュされ、`helm search` などのコマンドで使用されます。\n\n更新するリポジトリを指定することもできます。\n\n\t$ helm repo update <repo_name> ...\n\nすべてのリポジトリを更新するには `helm repo update` を実行します。\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### オプション\n\n```\n      --fail-on-repo-update-fail   いずれかのリポジトリの更新に失敗した場合、コマンド全体を失敗させます\n  -h, --help                       help for update\n      --timeout duration           インデックスファイルのダウンロード完了を待機する時間 (default 2m0s)\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm repo](/helm/helm_repo.md)\t - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\nrelease を以前のリビジョンにロールバックします\n\n### 概要\n\nこのコマンドは release を以前のリビジョンにロールバックします。\n\nrollback コマンドの第一引数は release 名、第二引数はリビジョン（バージョン）番号です。第二引数を省略するか 0 を指定すると、直前の release にロールバックします。\n\nリビジョン番号を確認するには `helm history RELEASE` を実行してください。\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### オプション\n\n```\n      --cleanup-on-fail    ロールバック失敗時に、このロールバックで作成された新しいリソースの削除を許可します\n      --dry-run            ロールバックをシミュレートします\n      --force              必要に応じて削除/再作成によるリソースの強制更新を行います\n  -h, --help               help for rollback\n      --history-max int    release ごとに保存するリビジョンの最大数を制限します。0 を指定すると無制限になります (default 10)\n      --no-hooks           ロールバック中に hook の実行を防止します\n      --recreate-pods      該当するリソースに対して Pod の再起動を行います\n      --timeout duration   個々の Kubernetes 操作（hook 用の Job など）を待機する時間 (default 5m0s)\n      --wait               指定した場合、すべての Pod、PVC、Service、および Deployment・StatefulSet・ReplicaSet の最小 Pod 数が Ready 状態になるまで待機してから release を成功とマークします。待機時間は --timeout で指定した値が上限となります\n      --wait-for-jobs      指定した場合、--wait が有効なときにすべての Job が完了するまで待機してから release を成功とマークします。待機時間は --timeout で指定した値が上限となります\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\nchart をキーワード検索します\n\n### 概要\n\nsearch コマンドは、Helm chart が保存されているさまざまな場所から chart を検索します。\n検索対象には Artifact Hub や、ユーザーが追加したリポジトリが含まれます。\n検索対象に応じたサブコマンドを使用してください。\n\n\n### オプション\n\n```\n  -h, --help   help for search\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー\n* [helm search hub](/helm/helm_search_hub.md)\t - Artifact Hub または独自の Hub インスタンスから chart を検索します\n* [helm search repo](/helm/helm_search_repo.md)\t - リポジトリから chart をキーワード検索します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\nArtifact Hub または独自の Hub インスタンスから chart を検索します\n\n### 概要\n\nArtifact Hub または独自の Hub インスタンスから chart を検索します。\n\nArtifact Hub は、CNCF プロジェクトのパッケージや設定を検索、インストール、公開できる Web アプリケーションです。一般公開されている Helm chart を含みます。Artifact Hub は Cloud Native Computing Foundation のサンドボックスプロジェクトです。https://artifacthub.io/ で閲覧できます。\n\n[KEYWORD] 引数には、キーワード文字列またはクォートで囲んだリッチクエリオプションを指定できます。リッチクエリオプションの詳細については、https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search を参照してください。\n\n以前のバージョンの Helm では、デフォルトの `endpoint` として Monocular インスタンスを使用していました。後方互換性のため、Artifact Hub は Monocular 検索 API と互換性があります。`endpoint` フラグを指定する場合は、Monocular 互換の検索 API エンドポイントを実装している必要があります。なお、Monocular インスタンスを `endpoint` として指定する場合、リッチクエリはサポートされません。API の詳細については、https://github.com/helm/monocular を参照してください。\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### オプション\n\n```\n      --endpoint string      Hub instance to query for charts (default \"https://hub.helm.sh\")\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for hub\n      --list-repo-url        print charts repository URL\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm search](/helm/helm_search.md)\t - chart をキーワード検索します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\nリポジトリから chart をキーワード検索します\n\n### 概要\n\nこのコマンドは、システムに設定されているすべてのリポジトリを読み込み、一致する chart を検索します。\nリポジトリの検索には、システムに保存されたメタデータを使用します。\n\nデフォルトでは、見つかった chart の最新安定バージョンが表示されます。\n`--devel` フラグを指定すると、プレリリースバージョンも出力に含まれます。\nバージョン制約を使用して検索する場合は、`--version` を使用します。\n\n使用例:\n\n    # \"nginx\" というキーワードに一致する安定リリースバージョンを検索\n    $ helm search repo nginx\n\n    # \"nginx\" というキーワードに一致するリリースバージョンを検索（プレリリースバージョンを含む）\n    $ helm search repo nginx --devel\n\n    # メジャーバージョン 1 の nginx-ingress の最新安定リリースを検索\n    $ helm search repo nginx-ingress --version ^1.0.0\n\nリポジトリは `helm repo` コマンドで管理します。\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### オプション\n\n```\n      --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\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for repo\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n  -r, --regexp               use regular expressions for searching repositories you have added\n      --version string       search using semantic versioning constraints on repositories you have added\n  -l, --versions             show the long listing, with each version of each chart on its own line, for repositories you have added\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm search](/helm/helm_search.md)\t - chart をキーワード検索します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\nchart の情報を表示します\n\n### 概要\n\nこのコマンドには、chart の情報を表示するサブコマンドが複数あります。\n\n\n### オプション\n\n```\n  -h, --help   help for show\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー\n* [helm show all](/helm/helm_show_all.md)\t - chart のすべての情報を表示します\n* [helm show chart](/helm/helm_show_chart.md)\t - chart の定義を表示します\n* [helm show crds](/helm/helm_show_crds.md)\t - chart の CRD を表示します\n* [helm show readme](/helm/helm_show_readme.md)\t - chart の README を表示します\n* [helm show values](/helm/helm_show_values.md)\t - chart の values を表示します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\nchart のすべての情報を表示します\n\n### 概要\n\nこのコマンドは chart（ディレクトリ、ファイル、または URL）のすべての内容（`values.yaml`、`Chart.yaml`、README）を表示します。\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### オプション\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for all\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm show](/helm/helm_show.md)\t - chart の情報を表示します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\nchart の定義を表示します\n\n### 概要\n\nこのコマンドは chart（ディレクトリ、ファイル、または URL）の `Chart.yaml` ファイルの内容を表示します。\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### オプション\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for chart\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm show](/helm/helm_show.md)\t - chart の情報を表示します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\nchart の CRD を表示します\n\n### 概要\n\nこのコマンドは chart（ディレクトリ、ファイル、または URL）の CustomResourceDefinition ファイルの内容を表示します。\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### オプション\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for crds\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm show](/helm/helm_show.md)\t - chart の情報を表示します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nchart の README を表示します\n\n### 概要\n\nこのコマンドは chart（ディレクトリ、ファイル、または URL）の README ファイルの内容を表示します。\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### オプション\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for readme\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm show](/helm/helm_show.md)\t - chart の情報を表示します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\nchart の values を表示します\n\n### 概要\n\nこのコマンドは chart（ディレクトリ、ファイル、または URL）の `values.yaml` ファイルの内容を表示します。\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### オプション\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for values\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --jsonpath string            supply a JSONPath expression to filter the output\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm show](/helm/helm_show.md)\t - chart の情報を表示します\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\n指定した release のステータスを表示します\n\n### 概要\n\nこのコマンドは、指定した release のステータスを表示します。\n表示されるステータスは以下の情報で構成されます。\n\n- 最後のデプロイ日時\n- release が存在する Kubernetes namespace\n- release の状態（unknown、deployed、uninstalled、superseded、failed、uninstalling、pending-install、pending-upgrade、pending-rollback のいずれか）\n- release のリビジョン\n- release の説明（完了メッセージまたはエラーメッセージ。--show-desc 指定時に表示）\n- release を構成するリソースの一覧（--show-resources 指定時に表示）\n- 最後のテスト実行結果（該当する場合）\n- chart が提供する追加の notes\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### オプション\n\n```\n  -h, --help             help for status\n  -o, --output format    prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int     if set, display the status of the named release with revision\n      --show-desc        if set, display the description message of the named release\n      --show-resources   if set, display the resources of the named release\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nテンプレートをローカルでレンダリングします\n\n### 概要\n\nchart のテンプレートをローカルでレンダリングし、出力を表示します。\n\n通常はクラスター内で参照・取得される値は、ローカルではダミー値で代用されます。また、chart の妥当性をサーバー側で検証する処理（例: 使用する API がサポートされているか）は実行されません。\n\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### オプション\n\n```\n  -a, --api-versions strings                       Kubernetes api versions used for Capabilities.APIVersions\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for template\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --include-crds                               include CRDs in the templated output\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --is-upgrade                                 set .Release.IsUpgrade instead of .Release.IsInstall\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        Kubernetes version used for Capabilities.KubeVersion\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n      --output-dir string                          writes the executed templates to files in output-dir instead of stdout\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --release-name                               use release name in the output-dir path.\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n  -s, --show-only stringArray                      only show manifests rendered from the given templates\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --skip-tests                                 skip tests from templated output\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n      --validate                                   validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\nrelease のテストを実行します\n\n### 概要\n\nこのコマンドは release のテストを実行します。\n\n引数にはデプロイ済みの release 名を指定します。\n実行するテストは、インストール時の chart 内で定義されています。\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### オプション\n\n```\n      --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)\n  -h, --help               help for test\n      --hide-notes         if set, do not show notes in test output. Does not affect presence in chart metadata\n      --logs               dump the logs from test pods (this runs after all tests are complete, but before any cleanup)\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\nrelease をアンインストールします\n\n### 概要\n\n\nこのコマンドは release 名を受け取り、その release をアンインストールします。\n\nchart の最新 release に関連付けられたすべてのリソースと release 履歴を削除し、release 名を再利用可能にします。\n\n`--dry-run` フラグを使用すると、実際にアンインストールせずに、どの release がアンインストールされるかを確認できます。\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### オプション\n\n```\n      --cascade string       \"background\"、\"orphan\"、または \"foreground\" のいずれかを指定します。依存リソースに対するカスケード削除の方式を選択します。デフォルトは background です。 (default \"background\")\n      --description string   カスタム説明を追加します\n      --dry-run              アンインストールをシミュレートします\n  -h, --help                 help for uninstall\n      --ignore-not-found     \"release not found\" を成功したアンインストールとして扱います\n      --keep-history         関連するすべてのリソースを削除し、release を削除済みとしてマークしますが、release 履歴は保持します\n      --no-hooks             アンインストール中に hook の実行を防止します\n      --timeout duration     個々の Kubernetes 操作（hook 用の Job など）を待機する時間 (default 5m0s)\n      --wait                 指定した場合、すべてのリソースが削除されるまで待機します。待機時間は `--timeout` で指定した値が上限となります\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nrelease をアップグレードします\n\n### 概要\n\nrelease を新しいバージョンの chart にアップグレードします。\n\n引数には release と chart を指定する必要があります。chart の引数には、chart 参照（`example/mariadb`）、chart ディレクトリへのパス、パッケージ化された chart、または完全な URL のいずれかを指定できます。chart 参照の場合、`--version` フラグを指定しない限り、最新バージョンが使用されます。\n\nchart の値をオーバーライドするには、`--values` フラグでファイルを指定するか、`--set` フラグでコマンドラインから設定を渡します。文字列値を強制する場合は `--set-string` を使用します。値自体がコマンドラインには長すぎる場合や動的に生成される場合は、`--set-file` を使用して個々の値をファイルから設定できます。また、`--set-json` を使用してコマンドラインから JSON 値（スカラー/オブジェクト/配列）を設定することもできます。\n\n`--values`/`-f` フラグは複数回指定できます。最後（右端）に指定されたファイルが優先されます。例えば、myvalues.yaml と override.yaml の両方に 'Test' というキーが含まれている場合、override.yaml に設定された値が優先されます。\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\n`--set` フラグは複数回指定できます。最後（右端）に指定された値が優先されます。例えば、'foo' というキーに対して 'bar' と 'newbar' の両方が設定されている場合、'newbar' の値が優先されます。\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\nこのコマンドで `--reuse-values` フラグを使用すると、既存の release の値を更新することもできます。`RELEASE` と `CHART` の引数には元のパラメータを設定し、既存の値は `--values`/`-f` または `--set` フラグで設定された値とマージされます。新しい値が優先されます。\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\n`--dry-run` フラグは、Secret など機密情報を含む可能性があるリソースを含め、生成されたすべての chart マニフェストを出力します。Kubernetes の Secret を非表示にするには `--hide-secret` フラグを使用してください。これらのフラグの使用には十分注意してください。\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### オプション\n\n```\n      --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\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --cleanup-on-fail                            allow deletion of new resources created in this upgrade when upgrade fails\n      --create-namespace                           if --install is set, create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -h, --help                                       help for upgrade\n      --hide-notes                                 if set, do not show notes in upgrade output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --history-max int                            limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n  -i, --install                                    if a release by this name doesn't already exist, run an install\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -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 [])\n      --no-hooks                                   disable pre/post upgrade hooks\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --repo string                                chart repository url where to locate the requested chart\n      --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\n      --reset-values                               when upgrading, reset the values to the ones built into the chart\n      --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\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\n指定されたパスの chart が署名済みで有効であることを検証します\n\n### 概要\n\n\n指定された chart に有効な provenance ファイルがあることを検証します。\n\nprovenance ファイルは、chart が改ざんされておらず、信頼できるプロバイダーによってパッケージ化されたことを暗号学的に証明します。\n\nこのコマンドはローカルの chart を検証するために使用できます。他のコマンドにも同様の検証を行う `--verify` フラグがあります。署名されたパッケージを生成するには、`helm package --sign` コマンドを使用してください。\n\n\n```\nhelm verify PATH [flags]\n```\n\n### オプション\n\n```\n  -h, --help             help for verify\n      --keyring string   keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n\nクライアントのバージョン情報を出力します\n\n### 概要\n\nHelm のバージョン情報を表示します。\n出力は以下のようになります。\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version はこのリリースのセマンティックバージョンです。\n- GitCommit はこのバージョンがビルドされたコミットの SHA です。\n- GitTreeState は、このバイナリのビルド時にローカルコードの変更がない場合は \"clean\"、ローカルで変更されたコードからビルドされた場合は \"dirty\" になります。\n- GoVersion は Helm のコンパイルに使用された Go のバージョンです。\n\n--template フラグを使用する場合、テンプレートで以下のプロパティを使用できます。\n\n- .Version には Helm のセマンティックバージョンが含まれます\n- .GitCommit には git コミットの SHA が含まれます\n- .GitTreeState には Helm がビルドされた時点の git ツリーの状態が含まれます\n- .GoVersion には Helm がコンパイルされた Go のバージョンが含まれます\n\n例: --template='Version: {{.Version}}' は 'Version: v3.2.1' を出力します。\n\n\n```\nhelm version [flags]\n```\n\n### オプション\n\n```\n  -h, --help              help for version\n      --short             print the version number\n      --template string   template for version string format\n```\n\n### 親コマンドから継承されたオプション\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 関連項目\n\n* [helm](/helm/helm.md)\t - Kubernetes 用パッケージマネージャー Helm\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/helm/index.mdx",
    "content": "---\ntitle: Helm コマンド\ndescription: helm CLI コマンドの完全なリストのドキュメント。\nsidebar_position: 6\nid: helm-category\n---\n\n# Helm コマンド\n\nここでは、Helm の CLI コマンドのリストと、それらの使用法に関するヘルプ情報を確認できます。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action による GitHub Pages での chart 自動公開\ndescription: Chart Releaser Action を使用して GitHub Pages で chart を自動公開する方法について説明します。\nsidebar_position: 3\n---\n\nこのガイドでは、[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 ワークフローです。\n\n## リポジトリの構成\n\nGitHub 組織の下に Git リポジトリを作成します。リポジトリ名は `helm-charts` などが考えられますが、他の名前でも問題ありません。すべての chart のソースは `main` ブランチに配置できます。chart はディレクトリツリーのトップレベルにある `/charts` ディレクトリに配置してください。\n\nchart の公開用に `gh-pages` という別のブランチが必要です。このブランチへの変更は、後述する Chart Releaser Action によって自動的に作成されます。ただし、事前に `gh-pages` ブランチを作成し、ページを訪れるユーザーに表示される `README.md` ファイルを追加することもできます。\n\n`README.md` に chart のインストール手順を追加できます（`<alias>`、`<orgname>`、`<chart-name>` を適切な値に置き換えてください）:\n\n```\n## Usage\n\n[Helm](https://helm.sh) must be installed to use the charts.  Please refer to\nHelm's [documentation](https://helm.sh/docs) to get started.\n\nOnce Helm has been set up correctly, add the repo as follows:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nIf you had already added this repo earlier, run `helm repo update` to retrieve\nthe latest versions of the packages.  You can then run `helm search repo\n<alias>` to see the charts.\n\nTo install the <chart-name> chart:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nTo uninstall the chart:\n\n    helm uninstall my-<chart-name>\n```\n\nchart は次のような URL の Web サイトに公開されます:\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions ワークフロー\n\n`main` ブランチの `.github/workflows/release.yml` に GitHub Actions ワークフローファイルを作成します。\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\n上記の設定では、[@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 でホストします。\n\n上記の例で使用している Chart Releaser Action のバージョンは `v1.6.0` です。[最新の利用可能なバージョン](https://github.com/helm/chart-releaser-action/releases)に変更できます。\n\n補足: Chart Releaser Action は、ほぼ常に [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) および [Kind Action](https://github.com/marketplace/actions/kind-cluster) と組み合わせて使用されます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: Chart リポジトリの同期\ndescription: ローカルとリモートの chart リポジトリを同期する方法について説明します。\nsidebar_position: 2\n---\n\n*注: この例は、chart リポジトリとして機能する Google Cloud Storage（GCS）バケット専用です。*\n\n## 前提条件\n* [gsutil](https://cloud.google.com/storage/docs/gsutil) ツールをインストールします。*gsutil rsync 機能を多用します*\n* Helm バイナリにアクセスできることを確認します\n* _オプション: 誤ってデータを削除した場合に備えて、GCS バケットで[オブジェクトのバージョニング](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)を設定することを推奨します。_\n\n## ローカル chart リポジトリディレクトリのセットアップ\n[chart リポジトリガイド](/topics/chart_repository.md)で説明したように、ローカルディレクトリを作成し、パッケージ化された chart をそのディレクトリに配置します。\n\n例:\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## 更新された index.yaml の生成\nHelm を使用して、ディレクトリパスとリモートリポジトリの URL を `helm repo index` コマンドに渡し、更新された index.yaml ファイルを生成します。\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\nこのコマンドは更新された index.yaml ファイルを生成し、`fantastic-charts/` ディレクトリに配置します。\n\n## ローカルとリモートの chart リポジトリを同期する\n`scripts/sync-repo.sh` を実行してディレクトリの内容を GCS バケットにアップロードします。ローカルディレクトリ名と GCS バケット名を引数として渡します。\n\n例:\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## chart リポジトリの更新\nchart リポジトリの内容のローカルコピーを保持することを推奨します。また、`gsutil rsync` を使用してリモート chart リポジトリの内容をローカルディレクトリにコピーすることもできます。\n\n例:\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\n参考リンク:\n* [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) ドキュメント\n* [Chart リポジトリガイド](/topics/chart_repository.md)\n* Google Cloud Storage の[オブジェクトのバージョニングと同時実行制御](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)ドキュメント\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Chart 開発のヒントとコツ\ndescription: Helm chart 開発者がプロダクション品質の chart を構築する際に学んだヒントとコツを紹介します。\nsidebar_position: 1\n---\n\nこのガイドでは、Helm chart 開発者がプロダクション品質の chart を構築する際に学んだヒントとコツを紹介します。\n\n## テンプレート関数を知る\n\nHelm はリソースファイルのテンプレート化に [Go テンプレート](https://godoc.org/text/template)を使用します。Go にはいくつかの組み込み関数がありますが、Helm ではさらに多くの関数を追加しています。\n\nまず、[Sprig ライブラリ](https://masterminds.github.io/sprig/)のすべての関数を追加しました。ただし、セキュリティ上の理由から `env` と `expandenv` は除外されています。\n\nまた、`include` と `required` という 2 つの特別なテンプレート関数も追加しました。`include` 関数を使用すると、別のテンプレートを取り込んで、その結果を他のテンプレート関数に渡すことができます。\n\nたとえば、次のテンプレートスニペットは `mytpl` というテンプレートを取り込み、その結果を小文字に変換し、二重引用符で囲みます。\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\n`required` 関数を使用すると、テンプレートのレンダリングに必要な特定の values エントリを宣言できます。値が空の場合、テンプレートのレンダリングはユーザーが指定したエラーメッセージとともに失敗します。\n\n次の `required` 関数の例では、`.Values.who` エントリが必須であることを宣言し、そのエントリがない場合にエラーメッセージを表示します。\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## 文字列は引用符で囲み、整数は囲まない\n\n文字列データを扱う場合は、そのまま記述するよりも引用符で囲む方が安全です。\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nただし、整数を扱う場合は _値を引用符で囲まないでください_。多くの場合、Kubernetes 内でパースエラーを引き起こす可能性があります。\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nこの注意点は、整数を表す場合でも文字列として期待される環境変数の値には適用されません。\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## 'include' 関数の使用\n\nGo には、組み込みの `template` ディレクティブを使用して、あるテンプレートを別のテンプレートに含める方法があります。しかし、この組み込み関数は Go テンプレートのパイプラインでは使用できません。\n\nテンプレートを含め、その出力に対して操作を行えるようにするため、Helm には特別な `include` 関数があります。\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\n上記では `toYaml` というテンプレートを含め、それに `$value` を渡し、そのテンプレートの出力を `indent` 関数に渡しています。\n\nYAML ではインデントレベルと空白が意味を持つため、これはコードスニペットを含めつつ、適切なコンテキストでインデントを処理する優れた方法です。\n\n## 'required' 関数の使用\n\nGo には、マップに存在しないキーでインデックス付けされた場合の動作を制御するためのテンプレートオプションを設定する方法があります。通常、これは `template.Options(\"missingkey=option\")` で設定し、`option` には `default`、`zero`、または `error` を指定できます。このオプションを error に設定するとエラーで実行が停止しますが、これはマップ内のすべての欠落キーに適用されます。chart 開発者が `values.yaml` ファイル内の選択した値に対してのみこの動作を強制したい場合があるかもしれません。\n\n`required` 関数は、テンプレートのレンダリングに必要な値エントリを宣言する機能を開発者に提供します。`values.yaml` でそのエントリが空の場合、テンプレートはレンダリングされず、開発者が指定したエラーメッセージを返します。\n\n例:\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\n上記では、`.Values.foo` が定義されている場合はテンプレートをレンダリングしますが、`.Values.foo` が未定義の場合はレンダリングに失敗して終了します。\n\n## 'tpl' 関数の使用\n\n`tpl` 関数を使用すると、開発者はテンプレート内で文字列をテンプレートとして評価できます。これは、テンプレート文字列を値として chart に渡したり、外部設定ファイルをレンダリングしたりする場合に便利です。構文: `{{ tpl TEMPLATE_STRING VALUES }}`\n\n例:\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\n外部設定ファイルのレンダリング:\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## イメージプル Secret の作成\n\nイメージプル Secret は、基本的に _registry_、_username_、_password_ の組み合わせです。デプロイするアプリケーションで必要になる場合がありますが、作成するには `base64` を数回実行する必要があります。Secret のペイロードとして使用する Docker 設定ファイルを構成するヘルパーテンプレートを作成できます。以下に例を示します。\n\nまず、`values.yaml` ファイルで認証情報が次のように定義されていると仮定します。\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\n次に、ヘルパーテンプレートを以下のように定義します。\n\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\n最後に、より大きなテンプレート内でヘルパーテンプレートを使用して Secret マニフェストを作成します。\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Deployment の自動ロール\n\nConfigMap や Secret がコンテナ内の設定ファイルとして注入されている場合や、その他の外部依存関係の変更により Pod のローリングが必要になる場合があります。アプリケーションによっては、後続の `helm upgrade` でこれらが更新された場合に再起動が必要になることがありますが、Deployment の spec 自体が変更されていない場合、アプリケーションは古い設定のまま実行され続け、一貫性のないデプロイメントが発生します。\n\n`sha256sum` 関数を使用すると、別のファイルが変更された場合に Deployment の annotation セクションを確実に更新できます。\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nNOTE: これを library chart に追加する場合、`$.Template.BasePath` でファイルにアクセスできません。代わりに、`{{ include (\"mylibchart.configmap\") . | sha256sum }}` のように定義を参照してください。\n\n常に Deployment をロールさせたい場合は、上記と同様の annotation ステップを使用しますが、代わりにランダムな文字列に置き換えて常に変化させ、Deployment がロールするようにします。\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nテンプレート関数の呼び出しごとに一意のランダム文字列が生成されます。つまり、複数のリソースで使用するランダム文字列を同期させる必要がある場合、関連するすべてのリソースを同じテンプレートファイルに配置する必要があります。\n\nこれらの方法はどちらも、Deployment に組み込まれた更新戦略ロジックを活用し、ダウンタイムを回避できます。\n\nNOTE: 以前は別のオプションとして `--recreate-pods` フラグの使用を推奨していました。このフラグは Helm 3 で非推奨となり、上記のより宣言的な方法が推奨されています。\n\n## リソースをアンインストールしないように Helm に指示する\n\nHelm が `helm uninstall` を実行する際にアンインストールすべきでないリソースが存在する場合があります。chart 開発者は、リソースに annotation を追加して、アンインストールされないようにすることができます。\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nannotation `helm.sh/resource-policy: keep` は、Helm の操作（`helm uninstall`、`helm upgrade`、`helm rollback` など）によってこのリソースが削除される場合に、削除をスキップするよう Helm に指示します。_ただし_、このリソースは孤立した状態になります。Helm はこのリソースをいかなる方法でも管理しなくなります。これは、既にアンインストールされているがリソースを保持している release に対して `helm install --replace` を使用する場合に問題を引き起こす可能性があります。\n\n## 「Partials」とテンプレートのインクルードの使用\n\nchart 内でブロックやテンプレートの部分的なパーツなど、再利用可能なパーツを作成したい場合があります。多くの場合、これらを独自のファイルに保持する方が整理しやすくなります。\n\n`templates/` ディレクトリでは、アンダースコア（`_`）で始まるファイルは Kubernetes マニフェストファイルを出力しないものと見なされます。そのため、慣例としてヘルパーテンプレートや Partials は `_helpers.tpl` ファイルに配置されます。\n\n## 多くの依存関係を持つ複雑な Chart\n\nCNCF の [Artifact Hub](https://artifacthub.io/packages/search?kind=0) にある多くの chart は、より高度なアプリケーションを作成するための「ビルディングブロック」です。ただし、chart は大規模なアプリケーションのインスタンスを作成するために使用されることもあります。そのような場合、単一のアンブレラ chart が複数のサブチャートを持ち、それぞれが全体の一部として機能することがあります。\n\n個別のパーツから複雑なアプリケーションを構成するための現在のベストプラクティスは、グローバル設定を公開するトップレベルのアンブレラ chart を作成し、`charts/` サブディレクトリを使用して各コンポーネントを埋め込むことです。\n\n## YAML は JSON のスーパーセット\n\nYAML 仕様によると、YAML は JSON のスーパーセットです。つまり、有効な JSON 構造はすべて YAML でも有効です。\n\nこれには利点があります。テンプレート開発者は、YAML の空白の扱いに対処するよりも、JSON ライクな構文でデータ構造を表現する方が簡単だと感じることがあります。\n\nベストプラクティスとして、JSON 構文がフォーマットの問題のリスクを大幅に軽減する場合を _除き_、テンプレートは YAML ライクな構文に従うべきです。\n\n## ランダム値の生成に注意する\n\nHelm にはランダムデータや暗号鍵などを生成する関数があります。これらを使用することは問題ありません。ただし、アップグレード中にテンプレートが再実行されることに注意してください。テンプレートの実行で前回の実行と異なるデータが生成されると、そのリソースの更新がトリガーされます。\n\n## 1 つのコマンドで release をインストールまたはアップグレード\n\nHelm では、インストールまたはアップグレードを単一のコマンドで実行できます。`helm upgrade` に `--install` オプションを付けて使用してください。これにより、Helm は release が既にインストールされているかどうかを確認します。インストールされていない場合はインストールを実行し、インストールされている場合は既存の release をアップグレードします。\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/howto/index.mdx",
    "content": "---\ntitle: How-to\nsidebar_position: 2\n---\n\n# How-to ガイド\n\nここでは、「どうすればよいですか？」といった種類の質問に対する短い回答を示します。\nこれらの How-to ガイドでは、トピックについて詳しく説明していません。\nそのトピックは[トピックガイド](/topics/index.mdx)に記載されています。\nただし、これらのガイドは、一般的なタスクをすばやく実行するのに役立ちます。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"ドキュメントホーム\"\ndescription: \"ドキュメントの構成について知っておく必要のあるすべて。\"\n---\n\n# ようこそ\n\n[Helm](https://helm.sh/) ドキュメントへようこそ。Helm は Kubernetes の\nパッケージマネージャーであり、[CNCF Helm プロジェクトジャーニーレポート](https://www.cncf.io/cncf-helm-project-journey/)で\n詳細な背景情報を読むことができます。\n\n# ドキュメントの構成\n\nHelm には多くのドキュメントがあります。それがどのように編成されているかについての\nハイレベルの概要は、特定のものを探す場所を知るのに役立ちます。\n\n- [チュートリアル](/intro/index.mdx) では、最初の Helm チャートを作成するための一連の手順を１つずつ説明します。\n  Helm を初めて使用する場合は、ここから始めてください。\n- [トピックガイド](/topics/index.mdx) では、主要なトピックと概念についてかなり高いレベルで説明し、\n  役立つ背景情報と説明を提供します。\n- [コミュニティガイド](/community)  は、Helm のコミュニティを中心としたトピックについて話し合っています。\n  Helm 自体の開発プロセスと貢献方法について詳しく知りたい場合は、\n  ここから始めてください。\n- [How-to ガイド](/howto/index.mdx) はレシピです。\n  これらは、主要な問題とユースケースへの対処に関連する手順を案内します。\n  これらはチュートリアルよりも高度で、Helm の動作に関するある程度の知識があることを前提としています。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: チートシート\ndescription: Helm チートシート\nsidebar_position: 4\n---\n\nこのチートシートでは、Helm でアプリケーションを管理するために必要なコマンドをまとめています。\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### 基本的な用語と解釈\n\nChart:\n- `helm pull` でダウンロードして展開した chart の場合は、そのディレクトリ名を指します。\n- リポジトリを追加済みだが chart を pull していない場合は、`<リポジトリ名>/<chart 名>` の形式で指定します。\n- chart への URL または絶対パスでも指定できます。\n\nName:\n- インストール時に chart に付ける名前です。\n\nRelease:\n- Helm によるインストールインスタンスを指します。\n\nRevision:\n- `helm history` コマンドで表示されるリビジョン番号です。\n\nRepo-name:\n- リポジトリの名前です。\n\nDIR:\n- ディレクトリ名またはパスです。\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Chart の管理\n\n```bash\nhelm create <name>                      # Creates a chart directory along with the common files and directories used in a chart.\nhelm package <chart-path>               # Packages a chart into a versioned chart archive file.\nhelm lint <chart>                       # Run tests to examine a chart and identify possible issues:\nhelm show all <chart>                   # Inspect a chart and list its contents:\nhelm show values <chart>                # Displays the contents of the values.yaml file\nhelm pull <chart>                       # Download/pull chart\nhelm pull <chart> --untar=true          # If set to true, will untar the chart after downloading it\nhelm pull <chart> --verify              # Verify the package before using it\nhelm pull <chart> --version <number>    # Default-latest is used, specify a version constraint for the chart version to use\nhelm dependency list <chart>            # Display a list of a chart's dependencies:\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### アプリケーションのインストールとアンインストール\n\n```bash\nhelm install <name> <chart>                           # Install the chart with a name\nhelm install <name> <chart> --namespace <namespace>   # Install the chart in a specific namespace\nhelm install <name> <chart> --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas)\nhelm install <name> <chart> --values <yaml-file/url>  # Install the chart with your specified values\nhelm install <name> <chart> --dry-run --debug         # Run a test installation to validate chart (p)\nhelm install <name> <chart> --verify                  # Verify the package before using it\nhelm install <name> <chart> --dependency-update       # update dependencies if they are missing before installing the chart\nhelm uninstall <name>                                 # Uninstalls a release from the current (default) namespace\nhelm uninstall <release-name> --namespace <namespace> # Uninstalls a release from the specified namespace\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### アプリケーションのアップグレードとロールバック\n\n```bash\nhelm upgrade <release> <chart>                            # Upgrade a release\nhelm upgrade <release> <chart> --rollback-on-failure      # If set, upgrade process rolls back changes made in case of failed upgrade.\nhelm upgrade <release> <chart> --dependency-update        # update dependencies if they are missing before installing the chart\nhelm upgrade <release> <chart> --version <version_number> # specify a version constraint for the chart version to use\nhelm upgrade <release> <chart> --values                   # specify values in a YAML file or a URL (can specify multiple)\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Set values on the command line (can specify multiple or separate valuese)\nhelm upgrade <release> <chart> --force                    # Force resource updates through a replacement strategy\nhelm rollback <release> <revision>                        # Roll back a release to a specific revision\nhelm rollback <release> <revision>  --cleanup-on-fail     # Allow deletion of new resources created in this rollback when rollback fails\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### リポジトリの一覧表示、追加、削除、更新\n\n```bash\nhelm repo add <repo-name> <url>   # Add a repository from the internet:\nhelm repo list                    # List added chart repositories\nhelm repo update                  # Update information of available charts locally from chart repositories\nhelm repo remove <repo_name>      # Remove one or more chart repositories\nhelm repo index <DIR>             # Read the current directory and generate an index file based on the charts found.\nhelm repo index <DIR> --merge     # Merge the generated index with an existing index file\nhelm search repo <keyword>        # Search repositories for a keyword in charts\nhelm search hub <keyword>         # Search for charts in the Artifact Hub or your own hub instance\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Helm release の監視\n\n```bash\nhelm list                       # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified\nhelm list --all                 # Show all releases without any filter applied, can use -a\nhelm list --all-namespaces      # List releases across all namespaces, we can use -A\nhelm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!='\nhelm list --date                # Sort by release date\nhelm list --deployed            # Show deployed releases. If no other is specified, this will be automatically enabled\nhelm list --pending             # Show pending releases\nhelm list --failed              # Show failed releases\nhelm list --uninstalled         # Show uninstalled releases (if 'helm uninstall --keep-history' was used)\nhelm list --superseded          # Show superseded releases\nhelm list -o yaml               # Prints the output in the specified format. Allowed values: table, json, yaml (default table)\nhelm status <release>           # This command shows the status of a named release.\nhelm status <release> --revision <number>   # if set, display the status of the named release with revision\nhelm history <release>          # Historical revisions for a given release.\nhelm env                        # Env prints out all the environment information in use by Helm.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### release 情報のダウンロード\n\n```bash\nhelm get all <release>      # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release.\nhelm get hooks <release>    # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\\n' separator.\nhelm get manifest <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.\nhelm get notes <release>    # Shows notes provided by the chart of a named release.\nhelm get values <release>   # Downloads a values file for a given release. use -o to format output\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### プラグイン管理\n\n```bash\nhelm plugin install <path/url>      # Install plugins\nhelm plugin list                    # View a list of all installed plugins\nhelm plugin update <plugin>         # Update plugins\nhelm plugin uninstall <plugin>      # Uninstall a plugin\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/intro/index.mdx",
    "content": "---\ntitle: 概要\nsidebar_position: 1\n---\n\n# Helm の概要\n\nHelm は初めてですか？ これが出発点です！\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: Helm のインストール\ndescription: Helm をインストールして実行する方法を学びます。\nsidebar_position: 2\n---\n\nこのガイドでは、Helm CLI のインストール方法を説明します。Helm はソースから、またはビルド済みのバイナリリリースからインストールできます。\n\n## Helm プロジェクトから\n\nHelm プロジェクトは、Helm を取得してインストールするための 2 つの公式の方法を提供しています。これに加えて、Helm コミュニティがさまざまなパッケージマネージャーを通じたインストール方法を提供しており、それらは公式の方法の後で説明します。\n\n### バイナリリリースから\n\nHelm のすべての[リリース](https://github.com/helm/helm/releases)は、さまざまな OS 向けのバイナリを提供しています。これらのバイナリは手動でダウンロードしてインストールできます。\n\n1. [任意のバージョン](https://github.com/helm/helm/releases)をダウンロードします\n2. 展開します（`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`）\n3. 展開したディレクトリ内の `helm` バイナリを目的の場所に移動します（`mv linux-amd64/helm /usr/local/bin/helm`）\n\nこれでクライアントを実行し、[chart リポジトリを初期化](/intro/quickstart.md#initialize-a-helm-chart-repository)できます。`helm help` を実行して確認してください。\n\n**注:** Helm の自動テストは、GitHub Actions のビルドおよびリリース時に Linux AMD64 に対してのみ実行されます。他の OS のテストは、その OS 向けの Helm を必要とするコミュニティの責任で行われます。\n\n### スクリプトから\n\nHelm には、最新バージョンの Helm を自動的に取得して[ローカルにインストールする](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3)インストーラースクリプトがあります。\n\nこのスクリプトを取得し、ローカルで実行できます。十分にドキュメント化されているため、実行前に内容を確認できます。\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\n手軽に済ませたい場合は、`curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` も使用できます。\n\n## パッケージマネージャー経由\n\nHelm コミュニティは、オペレーティングシステムのパッケージマネージャーを通じて Helm をインストールする方法を提供しています。これらは Helm プロジェクトによるサポート対象ではなく、信頼されたサードパーティとは見なされません。\n\n### Homebrew から（macOS）\n\nHelm コミュニティのメンバーが Homebrew に Helm フォーミュラを提供しています。このフォーミュラは一般的に最新の状態に保たれています。\n\n```console\nbrew install helm\n```\n\n（注：emacs-helm という別のプロジェクトのフォーミュラも存在します。）\n\n### Chocolatey から（Windows）\n\nHelm コミュニティのメンバーが [Chocolatey](https://chocolatey.org/) に [Helm パッケージ](https://chocolatey.org/packages/kubernetes-helm)を提供しています。このパッケージは一般的に最新の状態に保たれています。\n\n```console\nchoco install kubernetes-helm\n```\n\n### Scoop から（Windows）\n\nHelm コミュニティのメンバーが [Scoop](https://scoop.sh) に [Helm パッケージ](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json)を提供しています。このパッケージは一般的に最新の状態に保たれています。\n\n```console\nscoop install helm\n```\n\n### Winget から（Windows）\n\nHelm コミュニティのメンバーが [Winget](https://learn.microsoft.com/en-us/windows/package-manager/) に [Helm パッケージ](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm)を提供しています。このパッケージは一般的に最新の状態に保たれています。\n\n```console\nwinget install Helm.Helm\n```\n\n### Apt から（Debian/Ubuntu）\n\nHelm コミュニティのメンバーが Debian/Ubuntu 向けに Apt パッケージを提供しています。このパッケージは一般的に最新の状態に保たれています。リポジトリをホスティングしている [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) に感謝します。\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### dnf/yum から（Fedora）\n\nFedora 35 以降、Helm は公式リポジトリから利用可能です。次のコマンドでインストールできます。\n\n```console\nsudo dnf install helm\n```\n\n### Snap から\n\n[Snapcrafters](https://github.com/snapcrafters) コミュニティが [Helm パッケージ](https://snapcraft.io/helm)の Snap バージョンをメンテナンスしています。\n\n```console\nsudo snap install helm --classic\n```\n\n### pkg から（FreeBSD）\n\nFreeBSD コミュニティのメンバーが [FreeBSD Ports Collection](https://man.freebsd.org/ports) に [Helm パッケージ](https://www.freshports.org/sysutils/helm)を提供しています。このパッケージは一般的に最新の状態に保たれています。\n\n```console\npkg install helm\n```\n\n### 開発ビルド\n\nリリースバージョンに加えて、Helm の開発スナップショットをダウンロードまたはインストールできます。\n\n### Canary ビルドから\n\n「Canary」ビルドは、最新の `main` ブランチからビルドされた Helm のバージョンです。これらは公式リリースではなく、安定していない可能性があります。ただし、最新機能をテストする機会を提供します。\n\nCanary Helm バイナリは `get.helm.sh` にあります。一般的なビルドへのリンクは次のとおりです。\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### ソースから（Linux、macOS）\n\nソースから Helm をビルドするには多少の手間がかかりますが、最新の（プレリリース）Helm バージョンをテストする場合には最適な方法です。\n\n動作する Go 環境が必要です。\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\n必要に応じて依存関係を取得してキャッシュし、設定を検証します。その後、`helm` をコンパイルして `bin/helm` に配置します。\n\n## まとめ\n\nほとんどの場合、インストールはビルド済みの `helm` バイナリを取得するだけで完了します。このドキュメントでは、Helm でより高度なことを行いたい方向けの追加オプションについて説明しました。\n\nHelm クライアントのインストールが完了したら、Helm を使用して chart を管理し、[chart リポジトリを初期化](/intro/quickstart.md#initialize-a-helm-chart-repository)できます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: クイックスタートガイド\ndescription: Helm をインストールして使い始めるためのガイドです。\nsidebar_position: 1\n---\n\nこのガイドでは、Helm をすぐに使い始める方法を説明します。\n\n## 前提条件\n\nHelm を正しく安全に使用するには、以下の前提条件が必要です。\n\n1. Kubernetes クラスター\n2. インストールに適用するセキュリティ構成の決定（必要な場合）\n3. Helm のインストールと設定\n\n### Kubernetes をインストールするか、クラスターにアクセスする\n\n- Kubernetes がインストールされている必要があります。Helm の最新リリースには、Kubernetes の最新の安定リリースを推奨します。ほとんどの場合、これは2番目に新しいマイナーリリースです。\n- ローカルに設定された `kubectl` も必要です。\n\nHelm と Kubernetes 間でサポートされる最大バージョン差については、[Helm バージョンサポートポリシー](https://helm.sh/docs/topics/version_skew/)を参照してください。\n\n## Helm のインストール\n\nHelm クライアントのバイナリリリースをダウンロードします。`homebrew` などのツールを使用するか、[公式リリースページ](https://github.com/helm/helm/releases)を参照してください。\n\n詳細やその他のオプションについては、[インストールガイド](/intro/install.md)を参照してください。\n\n## Helm chart リポジトリを初期化する {#initialize-a-helm-chart-repository}\n\nHelm の準備ができたら、chart リポジトリを追加できます。利用可能な Helm chart リポジトリについては、[Artifact Hub](https://artifacthub.io/packages/search?kind=0) を確認してください。\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nリポジトリを追加すると、インストールできる chart を一覧表示できます。\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## サンプル chart をインストールする\n\nchart をインストールするには、`helm install` コマンドを実行します。Helm には chart を見つけてインストールする方法がいくつかありますが、最も簡単なのは `bitnami` chart を使用する方法です。\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\n上記の例では、`bitnami/mysql` chart がリリースされ、新しい release の名前は `mysql-1612624192` です。\n\n`helm show chart bitnami/mysql` を実行すると、この MySQL chart の機能の概要を確認できます。`helm show all bitnami/mysql` を実行すると、chart に関するすべての情報を取得できます。\n\nchart をインストールするたびに、新しい release が作成されます。そのため、1つの chart を同じクラスターに複数回インストールできます。各 release は個別に管理およびアップグレードできます。\n\n`helm install` コマンドは多くの機能を備えた強力なコマンドです。詳細については、[Helm の使い方ガイド](/intro/using_helm.md)を参照してください。\n\n## release について学ぶ\n\nHelm を使用してリリースした内容は簡単に確認できます。\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\n`helm list`（または `helm ls`）を実行すると、デプロイ済みのすべての release の一覧が表示されます。\n\n## release をアンインストールする\n\nrelease をアンインストールするには、`helm uninstall` コマンドを使用します。\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nこれにより、Kubernetes から `mysql-1612624192` がアンインストールされ、release に関連するすべてのリソースと release 履歴が削除されます。\n\n`--keep-history` フラグを指定すると、release 履歴が保持されます。その release に関する情報を取得できます。\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nHelm はアンインストール後も release を追跡するため、クラスターの履歴を監査したり、`helm rollback` で release を復元したりできます。\n\n## ヘルプテキストを読む\n\n利用可能な Helm コマンドの詳細については、`helm help` を使用するか、コマンドに `-h` フラグを付けて実行してください。\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: Helm の使い方\ndescription: Helm の基本について説明します。\nsidebar_position: 3\n---\n\nこのガイドでは、Helm を使用して Kubernetes クラスター上のパッケージを管理する基本について説明します。Helm クライアントが既に[インストール済み](/intro/install.md)であることを前提としています。\n\nコマンドをいくつか素早く試したい場合は、[クイックスタートガイド](/intro/quickstart.md)から始めてください。この章では Helm コマンドの詳細を説明し、Helm の使用方法を解説します。\n\n## 3つの重要な概念\n\n*chart* は Helm パッケージです。Kubernetes クラスター内でアプリケーション、ツール、またはサービスを実行するために必要なすべてのリソース定義が含まれています。Homebrew の formula、Apt の dpkg、Yum の RPM ファイルに相当する Kubernetes 版と考えてください。\n\n*repository* は chart を収集して共有できる場所です。Perl の [CPAN アーカイブ](https://www.cpan.org)や [Fedora Package Database](https://src.fedoraproject.org/) に似ていますが、Kubernetes パッケージを対象としています。\n\n*release* は Kubernetes クラスターで実行されている chart のインスタンスです。1つの chart を同じクラスターに何度もインストールできます。インストールするたびに新しい _release_ が作成されます。たとえば MySQL chart を考えてみます。クラスターで2つのデータベースを実行したい場合、その chart を2回インストールできます。それぞれに独自の _release_ があり、独自の _release 名_ が付けられます。\n\nこれらの概念を踏まえると、Helm を次のように説明できます。\n\nHelm は _chart_ を Kubernetes にインストールし、インストールごとに新しい _release_ を作成します。新しい chart を見つけるには、Helm chart _repository_ を検索します。\n\n## 'helm search': chart を見つける\n\nHelm には強力な検索コマンドがあります。2種類のソースを検索できます。\n\n- `helm search hub` は [Artifact Hub](https://artifacthub.io) を検索します。Artifact Hub には多数のリポジトリから Helm chart が集められています。\n- `helm search repo` は (`helm repo add` で) ローカルの Helm クライアントに追加したリポジトリを検索します。この検索はローカルデータに対して行われるため、パブリックネットワーク接続は不要です。\n\n`helm search hub` を実行すると、公開されている chart を見つけることができます。\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\n上記は Artifact Hub 上のすべての `wordpress` chart を検索しています。\n\nフィルターを指定しない場合、`helm search hub` は利用可能なすべての chart を表示します。\n\n`helm search hub` は [artifacthub.io](https://artifacthub.io/) 上の URL を表示しますが、実際の Helm リポジトリは表示しません。`helm search hub --list-repo-url` を使用すると、実際の Helm リポジトリ URL が表示されます。これは新しいリポジトリを追加する際に便利です: `helm repo add [NAME] [URL]`。\n\n`helm search repo` を使用すると、既に追加したリポジトリ内の chart 名を検索できます。\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nHelm の検索はあいまい文字列マッチングアルゴリズムを使用するため、単語やフレーズの一部を入力できます。\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\n検索は利用可能なパッケージを見つける良い方法です。インストールしたいパッケージが見つかったら、`helm install` でインストールできます。\n\n## 'helm install': パッケージをインストールする\n\n新しいパッケージをインストールするには、`helm install` コマンドを使用します。最もシンプルな形式では、2つの引数を取ります。任意の release 名と、インストールする chart の名前です。\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nこれで `wordpress` chart がインストールされました。chart をインストールすると新しい _release_ オブジェクトが作成されます。上記の release は `happy-panda` という名前です。(Helm に名前を自動生成させたい場合は、release 名を省略して `--generate-name` を使用してください。)\n\nインストール中、`helm` クライアントは作成されたリソース、release の状態、追加の設定手順など、有用な情報を出力します。\n\nHelm は以下の順序でリソースをインストールします。\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nHelm はすべてのリソースが実行状態になるまで待機してから終了するわけではありません。多くの chart は 600MB を超える Docker イメージを必要とし、クラスターへのインストールに時間がかかる場合があります。\n\nrelease の状態を追跡したり、設定情報を再度確認するには、`helm status` を使用します。\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\n上記は release の現在の状態を表示しています。\n\n### インストール前に chart をカスタマイズする\n\nここで説明した方法でインストールすると、その chart のデフォルト設定オプションのみが使用されます。多くの場合、好みの設定を使用するように chart をカスタマイズしたいでしょう。\n\nchart で設定可能なオプションを確認するには、`helm show values` を使用します。\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nYAML 形式のファイルでこれらの設定を上書きし、インストール時にそのファイルを渡すことができます。\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\n上記は `user0` という名前のデフォルト MariaDB ユーザーを作成し、新しく作成された `user0db` データベースへのアクセスを許可しますが、その chart の他のデフォルト設定はすべてそのまま使用します。\n\nインストール時に設定データを渡す方法は2つあります。\n\n- `--values` (または `-f`): 上書きする値を指定した YAML ファイルを指定します。複数回指定でき、最も右のファイルが優先されます。\n- `--set`: コマンドラインで上書きする値を指定します。\n\n両方を使用した場合、`--set` の値は `--values` にマージされ、`--set` が優先されます。`--set` で指定された上書きは Secret に永続化されます。`--set` された値は `helm get values <release-name>` で特定の release について確認できます。`--set` された値は `--reset-values` を指定して `helm upgrade` を実行することでクリアできます。\n\n#### `--set` の形式と制限\n\n`--set` オプションは0個以上の名前/値ペアを取ります。最もシンプルな形式は `--set name=value` です。これに相当する YAML は次のとおりです。\n\n```yaml\nname: value\n```\n\n複数の値は `,` 文字で区切ります。`--set a=b,c=d` は次のようになります。\n\n```yaml\na: b\nc: d\n```\n\nより複雑な式もサポートされています。たとえば、`--set outer.inner=value` は次のように変換されます。\n```yaml\nouter:\n  inner: value\n```\n\nリストは値を `{` と `}` で囲んで表現できます。たとえば、`--set name={a, b, c}` は次のように変換されます。\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\n特定の名前/キーを `null` または空の配列 `[]` に設定できます。たとえば、`--set name=[],a=null` は次のように変換されます。\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\nを\n\n```yaml\nname: []\na: null\n```\n\nに変換します。\n\nHelm 2.5.0 以降、配列インデックス構文を使用してリストアイテムにアクセスできます。たとえば、`--set servers[0].port=80` は次のようになります。\n\n```yaml\nservers:\n  - port: 80\n```\n\nこの方法で複数の値を設定できます。`--set servers[0].port=80,servers[0].host=example` は次のようになります。\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\n`--set` 行で特殊文字を使用する必要がある場合があります。バックスラッシュを使用して文字をエスケープできます。`--set name=value1\\,value2` は次のようになります。\n\n```yaml\nname: \"value1,value2\"\n```\n\n同様に、ドットシーケンスもエスケープできます。これは chart が `toYaml` 関数を使用してアノテーション、ラベル、ノードセレクターを解析する場合に便利です。`--set nodeSelector.\"kubernetes\\.io/role\"=master` の構文は次のようになります。\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\n深くネストされたデータ構造は `--set` で表現するのが難しい場合があります。chart の設計者は `values.yaml` ファイルの形式を設計する際に `--set` の使用を考慮することをお勧めします (詳細は [Values ファイル](/chart_template_guide/values_files.md)を参照してください)。\n\n### その他のインストール方法\n\n`helm install` コマンドは複数のソースからインストールできます。\n\n- chart repository (上記で見たとおり)\n- ローカルの chart アーカイブ (`helm install foo foo-0.1.1.tgz`)\n- 展開済みの chart ディレクトリ (`helm install foo path/to/foo`)\n- 完全な URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' と 'helm rollback': release のアップグレードと障害からの回復\n\nchart の新しいバージョンがリリースされたとき、または release の設定を変更したいときは、`helm upgrade` コマンドを使用します。\n\nアップグレードは既存の release を取得し、指定した情報に従ってアップグレードします。Kubernetes chart は大きく複雑になる可能性があるため、Helm は最も影響の少ないアップグレードを実行しようとします。前回の release 以降に変更されたものだけを更新します。\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\n上記の場合、`happy-panda` release は同じ chart でアップグレードされますが、新しい YAML ファイルが使用されます。\n\n```yaml\nmariadb.auth.username: user1\n```\n\n`helm get values` を使用して、新しい設定が有効になったかどうかを確認できます。\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\n`helm get` コマンドはクラスター内の release を確認するのに役立つツールです。上記のように、`panda.yaml` の新しい値がクラスターにデプロイされたことがわかります。\n\nrelease 中に何か予定どおりにいかなかった場合、`helm rollback [RELEASE] [REVISION]` を使用して以前の release に簡単にロールバックできます。\n\n```console\n$ helm rollback happy-panda 1\n```\n\n上記は happy-panda を最初の release バージョンにロールバックします。release バージョンは増分リビジョンです。インストール、アップグレード、またはロールバックが発生するたびに、リビジョン番号が1ずつ増加します。最初のリビジョン番号は常に1です。`helm history [RELEASE]` を使用して、特定の release のリビジョン番号を確認できます。\n\n## install/upgrade/rollback に役立つオプション\n\ninstall/upgrade/rollback 時の Helm の動作をカスタマイズするために指定できる便利なオプションがいくつかあります。これは CLI フラグの完全なリストではありません。すべてのフラグの説明を見るには、`helm <command> --help` を実行してください。\n\n- `--timeout`: Kubernetes コマンドが完了するまで待機する [Go duration](https://golang.org/pkg/time/#ParseDuration) 値。デフォルトは `5m0s` です。\n- `--wait`: すべての Pod が準備完了状態になり、PVC がバインドされ、Deployment が準備完了状態の最小 Pod 数 (`Desired` - `maxUnavailable`) を持ち、Service が IP アドレス (および `LoadBalancer` の場合は Ingress) を持つまで待機してから、release を成功とマークします。`--timeout` 値まで待機します。タイムアウトに達すると、release は `FAILED` としてマークされます。注: ローリング更新戦略の一部として Deployment の `replicas` が 1 に設定され、`maxUnavailable` が 0 に設定されていない場合、`--wait` は準備完了状態の最小 Pod 条件を満たしているため、準備完了として返します。\n- `--no-hooks`: コマンドの hook の実行をスキップします。\n- `--recreate-pods` (`upgrade` と `rollback` でのみ使用可能): このフラグはすべての Pod を再作成します (Deployment に属する Pod を除く)。(Helm 3 では非推奨)\n\n## 'helm uninstall': release をアンインストールする\n\nクラスターから release をアンインストールするときは、`helm uninstall` コマンドを使用します。\n\n```console\n$ helm uninstall happy-panda\n```\n\nこれにより、release がクラスターから削除されます。`helm list` コマンドで現在デプロイされているすべての release を確認できます。\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\n上記の出力から、`happy-panda` release がアンインストールされたことがわかります。\n\n以前のバージョンの Helm では、release が削除されると削除の記録が残りました。Helm 3 では、削除により release レコードも削除されます。削除された release のレコードを保持したい場合は、`helm uninstall --keep-history` を使用してください。`helm list --uninstalled` を使用すると、`--keep-history` フラグでアンインストールされた release のみが表示されます。\n\n`helm list --all` フラグは、失敗したアイテムや削除されたアイテム (`--keep-history` が指定されている場合) のレコードを含む、Helm が保持しているすべての release レコードを表示します。\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nrelease がデフォルトで削除されるようになったため、アンインストールされたリソースをロールバックすることはできなくなりました。\n\n## 'helm repo': repository を操作する\n\nHelm 3 にはデフォルトの chart repository が付属しなくなりました。`helm repo` コマンドグループは、repository を追加、一覧表示、削除するコマンドを提供します。\n\n`helm repo list` で設定されている repository を確認できます。\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\n新しい repository は `helm repo add [NAME] [URL]` で追加できます。\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nchart repository は頻繁に変更されるため、`helm repo update` を実行して Helm クライアントを最新の状態に保つことができます。\n\nrepository は `helm repo remove` で削除できます。\n\n## 独自の chart を作成する\n\n[Chart 開発ガイド](/topics/charts.md)で独自の chart を開発する方法を説明しています。`helm create` コマンドを使用すると、すぐに始めることができます。\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nこれで `./deis-workflow` に chart ができました。編集して独自のテンプレートを作成できます。\n\nchart を編集する際に、`helm lint` を実行してフォーマットが正しいかどうかを検証できます。\n\nchart を配布用にパッケージ化するときは、`helm package` コマンドを実行します。\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nそして、その chart は `helm install` で簡単にインストールできます。\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nパッケージ化された chart は chart repository にロードできます。詳細は [Helm chart repository](/topics/chart_repository.md) のドキュメントを参照してください。\n\n## まとめ\n\nこの章では、検索、インストール、アップグレード、アンインストールなど、`helm` クライアントの基本的な使用パターンについて説明しました。`helm status`、`helm get`、`helm repo` などの便利なユーティリティコマンドについても説明しました。\n\nこれらのコマンドの詳細については、Helm の組み込みヘルプ `helm help` を参照してください。\n\n[次の章](/howto/charts_tips_and_tricks.md)では、chart を開発するプロセスについて説明します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: はじめに\ndescription: Helm Go SDK の概要\nsidebar_position: 1\n---\nHelm の Go SDK を使用すると、カスタムソフトウェアから Helm chart と Helm の機能を活用して Kubernetes ソフトウェアのデプロイを管理できます（実際、Helm CLI もそのようなツールの一つです！）。\n\n現在、SDK は Helm CLI から機能的に分離されており、独立したツールから利用できます。Helm プロジェクトは SDK の API 安定性を約束しています。ただし、CLI と SDK の分離作業で残っている未整備な部分があることに注意してください。Helm プロジェクトはこれらを時間をかけて改善していく予定です。\n\n完全な API ドキュメントは [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3) で確認できます。\n\n以下では、主要なパッケージの概要と簡単な使用例を紹介します。より多くの例や、より充実した機能を持つ「ドライバー」については、[サンプル](/sdk/examples.mdx)セクションを参照してください。\n\n## 主要パッケージの概要\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action):\n  Helm アクションを実行するためのメイン「クライアント」を含みます。CLI が内部で使用しているパッケージと同じです。別の Go プログラムから基本的な Helm コマンドを実行するだけであれば、このパッケージが適しています。\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart)、[pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil):\n  chart の読み込みと操作に使用するメソッドとヘルパー関数\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) およびそのサブパッケージ:\n  標準の Helm 環境変数のすべてのハンドラーを含み、サブパッケージには出力と values ファイルの処理が含まれています\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release):\n  `Release` オブジェクトとステータスを定義します\n\nここで紹介したもの以外にも多くのパッケージがありますので、詳細はドキュメントを確認してください！\n\n### 簡単な使用例\nこれは Go SDK を使用して `helm list` を実行する簡単な例です。\nより充実した例については、[サンプル](/sdk/examples.mdx)セクションを参照してください。\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## 互換性\n\nHelm SDK は Helm の後方互換性ガイドラインに明示的に従っています。\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\nつまり、破壊的変更はメジャーバージョンの更新時にのみ行われます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: 高度な Helm テクニック\ndescription: Helm パワーユーザー向けのさまざまな高度な機能について説明します\nsidebar_position: 9\n---\n\nこのセクションでは、Helm を使用するためのさまざまな高度な機能とテクニックについて説明します。ここで紹介する内容は、chart や release の高度なカスタマイズや操作を行いたい Helm の「パワーユーザー」を対象としています。これらの高度な機能にはそれぞれトレードオフや注意点があり、Helm の深い知識を持って慎重に使用する必要があります。言い換えれば、[ピーター・パーカーの原則](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)を心に留めておいてください。\n\n## ポストレンダリング\n\nポストレンダリングは、chart インストーラーに対し、Helm がインストールする前にレンダリング済みマニフェストを手動で操作、設定、または検証する機能を提供します。これにより、高度な設定ニーズを持つユーザーは、パブリック chart をフォークしたり、chart メンテナーがソフトウェアのすべての設定オプションを指定したりする必要なく、[`kustomize`](https://kustomize.io) などのツールを使用して設定変更を適用できます。また、エンタープライズ環境で共通ツールやサイドカーを注入したり、デプロイ前にマニフェストを分析したりするユースケースもあります。\n\n### 前提条件\n\n- Helm 3.1 以上\n\n### 使用方法\n\nポストレンダラーは、STDIN でレンダリングされた Kubernetes マニフェストを受け取り、STDOUT で有効な Kubernetes マニフェストを返す任意の実行可能ファイルです。失敗した場合は、0 以外の終了コードを返す必要があります。これが 2 つのコンポーネント間の唯一の「API」です。これにより、ポストレンダリング処理で実行できる操作に大きな柔軟性がもたらされます。\n\nポストレンダラーは `install`、`upgrade`、`template` で使用できます。ポストレンダラーを使用するには、使用したいレンダラー実行可能ファイルへのパスを `--post-renderer` フラグで指定します。\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nパスにセパレータが含まれていない場合は $PATH から検索されます。それ以外の場合は、相対パスが絶対パスに解決されます。\n\n複数のポストレンダラーを使用したい場合は、スクリプト内ですべて呼び出すか、ビルドしたバイナリツールで一緒に呼び出します。bash では、`renderer1 | renderer2 | renderer3` のように簡単に記述できます。\n\n`kustomize` をポストレンダラーとして使用する例は[こちら](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render)で確認できます。\n\n### 注意事項\n\nポストレンダラーを使用する際には、いくつかの重要な点に注意してください。最も重要なのは、ポストレンダラーを使用する場合、その release を変更するすべてのユーザーが再現可能なビルドを実現するために**同じレンダラーを使用しなければならない**ということです。この機能は、ユーザーが使用するレンダラーを切り替えたり、レンダラーの使用を停止したりできるように意図的に構築されていますが、偶発的な変更やデータ損失を避けるために慎重に行う必要があります。\n\nもう一つの重要な注意点はセキュリティに関するものです。ポストレンダラーを使用する場合は、他の実行可能ファイルと同様に、信頼できるソースからのものであることを確認してください。信頼できない、または検証されていないレンダラーの使用は推奨しません。レンダリングされたテンプレートへの完全なアクセス権があり、機密データが含まれている可能性があるためです。\n\n### カスタムポストレンダラー\n\nポストレンダリングステップは、Go SDK で使用するとさらに柔軟性が高まります。ポストレンダラーは、以下の Go インターフェースを実装するだけで済みます。\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nGo SDK の使用方法の詳細については、[Go SDK セクション](#go-sdk)を参照してください。\n\n## Go SDK\n\nHelm 3 では、Helm を活用したソフトウェアやツールを構築する際の体験を向上させるため、完全に再構築された Go SDK が導入されました。詳細なドキュメントは [Go SDK セクション](/sdk/gosdk.md)を参照してください。\n\n## ストレージバックエンド {#storage-backends}\n\nHelm 3 では、デフォルトの release 情報ストレージが release の namespace 内の Secret に変更されました。Helm 2 では、デフォルトで release 情報を Tiller インスタンスの namespace 内の ConfigMap として保存していました。以下のサブセクションでは、異なるバックエンドの設定方法を示します。この設定は環境変数 `HELM_DRIVER` に基づいています。`[configmap, secret, sql]` のいずれかの値を設定できます。\n\n### ConfigMap ストレージバックエンド\n\nConfigMap バックエンドを有効にするには、環境変数 `HELM_DRIVER` を `configmap` に設定する必要があります。\n\nシェルで次のように設定できます。\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nデフォルトのバックエンドから ConfigMap バックエンドに切り替える場合は、自分でマイグレーションを行う必要があります。release 情報は以下のコマンドで取得できます。\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**本番環境に関する注意**: 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 バックエンドに切り替える場合は、アプリケーションの機密データが公開される可能性があることに注意してください。\n\n### SQL ストレージバックエンド\n\nrelease 情報を SQL データベースに保存する ***ベータ版*** の SQL ストレージバックエンドがあります。\n\nこのストレージバックエンドは、release 情報が 1MB を超える場合に特に便利です（Kubernetes の基盤となる etcd キーバリューストアの内部制限により、ConfigMap や Secret には保存できないため）。\n\nSQL バックエンドを有効にするには、SQL データベースをデプロイし、環境変数 `HELM_DRIVER` を `sql` に設定する必要があります。データベースの詳細は環境変数 `HELM_DRIVER_SQL_CONNECTION_STRING` で設定します。\n\nシェルで次のように設定できます。\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> 注意: 現時点では PostgreSQL のみがサポートされています。\n\n**本番環境に関する注意**: 以下を推奨します。\n- データベースを本番環境向けに準備すること。PostgreSQL の場合は、[Server Administration](https://www.postgresql.org/docs/12/admin.html) ドキュメントを参照してください\n- release 情報に対して Kubernetes の RBAC をミラーリングするために[権限管理](/topics/permissions_sql_storage_backend.md)を有効にすること\n\nデフォルトのバックエンドから SQL バックエンドに切り替える場合は、自分でマイグレーションを行う必要があります。release 情報は以下のコマンドで取得できます。\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Helm アーキテクチャ\ndescription: Helm アーキテクチャの概要を説明します。\nsidebar_position: 8\n---\n\n# Helm アーキテクチャ\n\nこのドキュメントでは、Helm アーキテクチャの概要を説明します。\n\n## Helm の目的\n\nHelm は _chart_ と呼ばれる Kubernetes パッケージを管理するツールです。Helm では以下のことができます。\n\n- 新しい chart をゼロから作成する\n- chart を chart アーカイブ（tgz）ファイルにパッケージ化する\n- chart が保存されている chart リポジトリと連携する\n- 既存の Kubernetes クラスターに chart をインストール・アンインストールする\n- Helm でインストールした chart の release サイクルを管理する\n\nHelm には 3 つの重要な概念があります。\n\n1. _chart_ は、Kubernetes アプリケーションのインスタンスを作成するために必要な情報をまとめたものです。\n2. _config_ は、パッケージ化された chart にマージしてリリース可能なオブジェクトを作成するための設定情報です。\n3. _release_ は、特定の _config_ と組み合わせた _chart_ の実行中のインスタンスです。\n\n## コンポーネント\n\nHelm は 2 つの部分で構成される実行可能ファイルです。\n\n**Helm クライアント**は、エンドユーザー向けのコマンドラインクライアントです。クライアントは以下を担当します。\n\n- ローカルでの chart 開発\n- リポジトリの管理\n- release の管理\n- Helm ライブラリとの連携\n  - インストールする chart の送信\n  - 既存 release のアップグレードまたはアンインストールのリクエスト\n\n**Helm ライブラリ**は、すべての Helm 操作を実行するロジックを提供します。Kubernetes API サーバーと連携し、以下の機能を提供します。\n\n- chart と config を組み合わせて release を構築する\n- chart を Kubernetes にインストールし、release オブジェクトを提供する\n- Kubernetes と連携して chart のアップグレードとアンインストールを行う\n\nスタンドアロンの Helm ライブラリは Helm のロジックをカプセル化しており、さまざまなクライアントから利用できます。\n\n## 実装\n\nHelm クライアントとライブラリは Go プログラミング言語で記述されています。\n\nライブラリは Kubernetes クライアントライブラリを使用して Kubernetes と通信します。現在、このライブラリは REST+JSON を使用しています。情報は Kubernetes 内の Secret に保存されます。独自のデータベースは必要ありません。\n\n設定ファイルは、可能な限り YAML で記述されます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: Chart リポジトリガイド\ndescription: Helm chart リポジトリの作成と操作方法について説明します。\nsidebar_position: 6\n---\n\nこのセクションでは、Helm chart リポジトリの作成と操作方法について説明します。chart リポジトリとは、パッケージ化された chart を保存・共有するための場所です。\n\n分散型のコミュニティ Helm chart リポジトリは [Artifact Hub](https://artifacthub.io/packages/search?kind=0) にあり、参加を歓迎しています。Helm では独自の chart リポジトリを作成・運用することも可能です。このガイドではその方法を説明します。chart リポジトリの作成を検討している場合は、[OCI レジストリ](/topics/registries.md)の使用も検討してください。\n\n## 前提条件\n\n* [クイックスタート](/intro/quickstart.md)ガイドを完了してください\n* [Chart](/topics/charts.md) ドキュメントを読んでください\n\n## Chart リポジトリの作成\n\n_chart リポジトリ_ は、`index.yaml` ファイルと、任意でいくつかのパッケージ化された chart をホストする HTTP サーバーです。chart を共有する準備ができたら、chart リポジトリにアップロードするのが推奨される方法です。\n\nHelm 2.2.0 以降、リポジトリへのクライアント側 SSL 認証がサポートされています。その他の認証プロトコルはプラグインとして利用できる場合があります。\n\nchart リポジトリは YAML ファイルと tar ファイルを提供し、GET リクエストに応答できる任意の HTTP サーバーで構成できるため、独自の chart リポジトリをホストする方法には多くの選択肢があります。たとえば、Google Cloud Storage（GCS）バケット、Amazon S3 バケット、GitHub Pages を使用したり、独自の Web サーバーを作成したりできます。\n\n### Chart リポジトリの構造\n\nchart リポジトリは、パッケージ化された chart と、リポジトリ内のすべての chart のインデックスを含む `index.yaml` という特別なファイルで構成されます。`index.yaml` が記述する chart は、同じサーバー上にホストされていることが多く、[来歴ファイル](/topics/provenance.md)も同様です。\n\nたとえば、リポジトリ `https://example.com/charts` のレイアウトは以下のようになります:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nこの場合、インデックスファイルには Alpine という 1 つの chart に関する情報が含まれ、その chart のダウンロード URL `https://example.com/charts/alpine-0.1.2.tgz` を提供します。\n\nchart パッケージが `index.yaml` ファイルと同じサーバーに配置されている必要はありませんが、そうすることが最も簡単な場合が多いです。\n\n### インデックスファイル\n\nインデックスファイルは `index.yaml` という名前の YAML ファイルです。chart の `Chart.yaml` ファイルの内容を含むパッケージに関するメタデータが含まれます。有効な chart リポジトリにはインデックスファイルが必要です。インデックスファイルには、chart リポジトリ内の各 chart に関する情報が含まれます。`helm repo index` コマンドは、パッケージ化された chart を含むローカルディレクトリに基づいてインデックスファイルを生成します。\n\n以下はインデックスファイルの例です:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Chart リポジトリのホスティング\n\nこのセクションでは、chart リポジトリを提供するいくつかの方法を紹介します。\n\n### Google Cloud Storage\n\n最初のステップは、**GCS バケットを作成する**ことです。ここでは `fantastic-charts` という名前にします。\n\n![GCS バケットを作成する](/img/helm2/create-a-bucket.png)\n\n次に、**バケットの権限を編集**してバケットを公開します。\n\n![権限を編集](/img/helm2/edit-permissions.png)\n\nこの行を追加して、**バケットを公開**します:\n\n![バケットを公開する](/img/helm2/make-bucket-public.png)\n\nこれで、chart を配信するための空の GCS バケットの準備が整いました。\n\nGoogle Cloud Storage コマンドラインツールまたは GCS Web UI を使用して chart リポジトリをアップロードできます。公開 GCS バケットには、次のアドレスでシンプルな HTTPS 経由でアクセスできます: `https://bucket-name.storage.googleapis.com/`\n\n### Cloudsmith\n\nCloudsmith を使用して chart リポジトリをセットアップすることもできます。Cloudsmith での chart リポジトリについては、[こちら](https://help.cloudsmith.io/docs/helm-chart-repository)を参照してください。\n\n### JFrog Artifactory\n\n同様に、JFrog Artifactory を使用して chart リポジトリをセットアップすることもできます。JFrog Artifactory での chart リポジトリについては、[こちら](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)を参照してください。\n\n### GitHub Pages の例\n\n同様の方法で、GitHub Pages を使用して chart リポジトリを作成できます。\n\nGitHub では、2 つの異なる方法で静的 Web ページを提供できます:\n\n- プロジェクトの `docs/` ディレクトリの内容を提供するように設定する\n- プロジェクトの特定のブランチを提供するように設定する\n\nここでは 2 番目のアプローチを使用しますが、1 番目も同様に簡単です。\n\n最初のステップは、**gh-pages ブランチを作成する**ことです。ローカルで以下のように実行できます:\n\n```console\n$ git checkout -b gh-pages\n```\n\nまたは、GitHub リポジトリの **Branch** ボタンを使用して Web ブラウザ経由で作成できます:\n\n![GitHub Pages ブランチを作成する](/img/helm2/create-a-gh-page-button.png)\n\n次に、**gh-pages ブランチ** が GitHub Pages として設定されていることを確認します。リポジトリの **Settings** をクリックし、**GitHub pages** セクションまでスクロールして、以下のように設定します:\n\n![GitHub Pages ブランチを作成する](/img/helm2/set-a-gh-page.png)\n\nデフォルトでは **Source** は通常 **gh-pages branch** に設定されます。デフォルトで設定されていない場合は、選択してください。\n\n必要に応じて、**カスタムドメイン**を使用することもできます。\n\nまた、**Enforce HTTPS** がチェックされていることを確認してください。これにより、chart が提供される際に **HTTPS** が使用されます。\n\nこのセットアップでは、デフォルトブランチを chart のコード保存に使用し、**gh-pages ブランチ**を chart リポジトリとして使用できます。例: `https://USERNAME.github.io/REPONAME`。デモンストレーション用の [TS Charts](https://github.com/technosophos/tscharts) リポジトリは `https://technosophos.github.io/tscharts/` でアクセスできます。\n\nGitHub 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 ワークフローです。\n\n### 通常の Web サーバー\n\nHelm chart を提供するために通常の Web サーバーを設定するには、以下の作業が必要です:\n\n- インデックスと chart をサーバーが提供できるディレクトリに配置する\n- `index.yaml` ファイルが認証なしでアクセスできることを確認する\n- `yaml` ファイルが正しいコンテンツタイプ（`text/yaml` または `text/x-yaml`）で提供されることを確認する\n\nたとえば、`$WEBROOT/charts` から chart を提供したい場合は、Web ルートに `charts/` ディレクトリがあることを確認し、そのフォルダ内にインデックスファイルと chart を配置します。\n\n### ChartMuseum リポジトリサーバー\n\nChartMuseum は 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/) などのクラウドストレージバックエンドをサポートしています。\n\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) サーバーを使用して、ローカルファイルシステムから chart リポジトリをホストすることもできます。\n\n### GitLab Package Registry\n\nGitLab では、プロジェクトの Package Registry で Helm chart を公開できます。GitLab で Helm パッケージリポジトリをセットアップする方法については、[こちら](https://docs.gitlab.com/ee/user/packages/helm_repository/)を参照してください。\n\n## Chart リポジトリの管理\n\nchart リポジトリができたので、このガイドの最後のパートでは、そのリポジトリで chart を管理する方法を説明します。\n\n### Chart リポジトリに chart を保存する\n\nchart リポジトリができたので、chart とインデックスファイルをリポジトリにアップロードしましょう。chart リポジトリ内の chart は、パッケージ化（`helm package chart-name/`）され、正しくバージョニングされている必要があります（[SemVer 2](https://semver.org/) ガイドラインに従います）。\n\n以下の手順はワークフローの例ですが、chart リポジトリへの chart の保存・更新には好みのワークフローを使用できます。\n\nパッケージ化された chart の準備ができたら、新しいディレクトリを作成し、パッケージ化された chart をそのディレクトリに移動します。\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\n最後のコマンドは、作成したローカルディレクトリのパスとリモート chart リポジトリの URL を受け取り、指定されたディレクトリパス内に `index.yaml` ファイルを生成します。\n\nこれで、同期ツールまたは手動で chart とインデックスファイルを chart リポジトリにアップロードできます。Google Cloud Storage を使用している場合は、gsutil クライアントを使用した[ワークフロー例](/howto/chart_repository_sync_example.md)を確認してください。GitHub の場合は、適切な宛先ブランチに chart を配置するだけです。\n\n### 既存のリポジトリに新しい chart を追加する\n\nリポジトリに新しい chart を追加するたびに、インデックスを再生成する必要があります。`helm repo index` コマンドは、ローカルで見つかった chart のみを含めて、`index.yaml` ファイルを最初から完全に再構築します。\n\nただし、`--merge` フラグを使用して、既存の `index.yaml` ファイルに新しい chart を増分的に追加できます（GCS などのリモートリポジトリで作業する場合に便利なオプションです）。詳細は `helm repo index --help` を実行してください。\n\n更新された `index.yaml` ファイルと chart の両方をアップロードしてください。来歴ファイルを生成した場合は、それもアップロードしてください。\n\n### Chart を他のユーザーと共有する\n\nchart を共有する準備ができたら、リポジトリの URL を他のユーザーに伝えるだけです。\n\n相手は、リポジトリを参照するために使用したい任意の名前で、`helm repo add [NAME] [URL]` コマンドを使用して Helm クライアントにリポジトリを追加します。\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nchart が HTTP ベーシック認証で保護されている場合は、ユーザー名とパスワードも指定できます:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**注:** 有効な `index.yaml` が含まれていない場合、リポジトリは追加されません。\n\n**注:** Helm リポジトリが自己署名証明書を使用している場合などは、`helm repo add --insecure-skip-tls-verify ...` を使用して CA 検証をスキップできます。\n\nその後、ユーザーは chart を検索できるようになります。リポジトリを更新した後は、`helm repo update` コマンドを使用して最新の chart 情報を取得できます。\n\n*内部的には、`helm repo add` と `helm repo update` コマンドは index.yaml ファイルを取得し、`$XDG_CACHE_HOME/helm/repository/cache/` ディレクトリに保存します。`helm search` 機能は、ここから chart に関する情報を検索します。*\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: chart のテスト\ndescription: chart のテスト方法について説明します。\nsidebar_position: 3\n---\n\nchart には、連携して動作する多くの Kubernetes リソースとコンポーネントが含まれています。chart 作成者は、chart がインストールされたときに期待どおりに動作することを検証するテストを作成できます。これらのテストは、chart 利用者が chart の目的を理解するのにも役立ちます。\n\nHelm chart における**テスト**は、`templates/` ディレクトリに配置され、特定のコマンドを実行するコンテナを指定する Job 定義です。テストが成功と判定されるには、コンテナが正常に終了（exit 0）する必要があります。Job 定義には、Helm テスト hook アノテーション `helm.sh/hook: test` を含める必要があります。\n\nHelm v3 より前は、Job 定義に `helm.sh/hook: test-success` または `helm.sh/hook: test-failure` のいずれかの Helm テスト hook アノテーションが必要でした。`helm.sh/hook: test-success` は、`helm.sh/hook: test` の後方互換として引き続き使用できます。\n\nテストの例:\n\n- `values.yaml` ファイルの設定が正しく注入されたことを検証する\n  - ユーザー名とパスワードが正しく機能することを確認する\n  - 不正なユーザー名とパスワードが機能しないことを確認する\n- サービスが稼働しており、正しくロードバランシングされていることを確認する\n- など\n\n`helm test <RELEASE_NAME>` コマンドを使用して、release に対して Helm で事前定義されたテストを実行できます。chart 利用者にとって、これは chart（またはアプリケーション）の release が期待どおりに動作することを確認する優れた方法です。\n\n## テストの例\n\n[helm create](/helm/helm_create.md) コマンドは、いくつかのフォルダとファイルを自動的に作成します。Helm テスト機能を試すには、まずデモ用の Helm chart を作成します。\n\n```console\n$ helm create demo\n```\n\n作成された demo chart の構造は以下のとおりです。\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\n`demo/templates/tests/test-connection.yaml` にテストが含まれています。Helm テスト Pod 定義は以下のとおりです:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## release でテストスイートを実行する手順\n\nまず、クラスターに chart をインストールして release を作成します。すべての Pod がアクティブになるまで待つ必要がある場合があります。インストール直後にテストを実行すると、一時的な失敗が発生する可能性があるため、再テストが必要になることがあります。\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## 備考\n\n- 単一の yaml ファイルで複数のテストを定義することも、`templates/` ディレクトリ内の複数の yaml ファイルに分散させることもできます。\n- テストスイートをより分離するために、`<chart-name>/templates/tests/` のように `tests/` ディレクトリの下にネストすることもできます。\n- テストは [Helm hook](/topics/charts_hooks.md) であるため、`helm.sh/hook-weight` や `helm.sh/hook-delete-policy` などのアノテーションをテストリソースで使用できます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: Chart\ndescription: chart フォーマットの説明と、Helm で chart を構築するための基本的なガイダンスを提供します。\nsidebar_position: 1\n---\n\nHelm は _chart_ と呼ばれるパッケージングフォーマットを使用します。chart は、関連する Kubernetes リソースを記述するファイル群です。単一の chart で、memcached pod のようなシンプルなものから、HTTP サーバー、データベース、キャッシュなどを含む完全な Web アプリケーションスタックまでデプロイできます。\n\nchart は特定のディレクトリ構造で作成され、バージョン付きアーカイブとしてパッケージ化してデプロイできます。\n\n公開された chart をインストールせずにダウンロードして中身を確認するには、`helm pull chartrepo/chartname` を使用します。\n\nこのドキュメントでは、chart フォーマットについて説明し、Helm で chart を構築するための基本的なガイダンスを提供します。\n\n## Chart のファイル構造\n\nchart は、ディレクトリ内のファイル群で構成されます。ディレクトリ名が chart の名前になります（バージョン情報は含みません）。たとえば、WordPress を記述する chart は `wordpress/` ディレクトリに格納されます。\n\nこのディレクトリ内で、Helm は以下のような構造を期待します:\n\n```text\nwordpress/\n  Chart.yaml          # chart に関する情報を含む YAML ファイル\n  LICENSE             # 任意: chart のライセンスを含むテキストファイル\n  README.md           # 任意: 人間が読める README ファイル\n  values.yaml         # この chart のデフォルト設定値\n  values.schema.json  # 任意: values.yaml ファイルに構造を課すための JSON Schema\n  charts/             # この chart が依存する chart を含むディレクトリ\n  crds/               # Custom Resource Definition\n  templates/          # values と組み合わせると、有効な Kubernetes マニフェストファイルを\n                      # 生成するテンプレートのディレクトリ\n  templates/NOTES.txt # 任意: 短い使用方法のメモを含むテキストファイル\n```\n\nHelm は `charts/`、`crds/`、`templates/` ディレクトリ、およびリストされたファイル名を予約しています。その他のファイルはそのまま残されます。\n\n## Chart.yaml ファイル\n\n`Chart.yaml` ファイルは chart に必須です。以下のフィールドが含まれます:\n\n```yaml\napiVersion: chart API バージョン（必須）\nname: chart の名前（必須）\nversion: chart のバージョン（必須）\nkubeVersion: 互換性のある Kubernetes バージョンの SemVer 範囲（任意）\ndescription: このプロジェクトの一文の説明（任意）\ntype: chart のタイプ（任意）\nkeywords:\n  - このプロジェクトに関するキーワードのリスト（任意）\nhome: このプロジェクトのホームページの URL（任意）\nsources:\n  - このプロジェクトのソースコードへの URL のリスト（任意）\ndependencies: # chart の依存関係のリスト（任意）\n  - name: chart の名前（nginx）\n    version: chart のバージョン（\"1.2.3\"）\n    repository: （任意）リポジトリ URL（\"https://example.com/charts\"）またはエイリアス（\"@repo-name\"）\n    condition: （任意）boolean に解決される yaml パスで、chart の有効化/無効化に使用（例: subchart1.enabled）\n    tags: # （任意）\n      - タグは chart をグループ化して一括で有効化/無効化するために使用できる\n    import-values: # （任意）\n      - ImportValues はソース値から親キーへのインポートマッピングを保持する。各項目は文字列または child/parent サブリスト項目のペア\n    alias: （任意）chart に使用するエイリアス。同じ chart を複数回追加する必要がある場合に便利\nmaintainers: # （任意）\n  - name: メンテナーの名前（各メンテナーに必須）\n    email: メンテナーのメールアドレス（各メンテナーに任意）\n    url: メンテナーの URL（各メンテナーに任意）\nicon: アイコンとして使用される SVG または PNG 画像への URL（任意）\nappVersion: これに含まれるアプリのバージョン（任意）。SemVer である必要はない。引用符推奨。\ndeprecated: この chart が非推奨かどうか（任意、boolean）\nannotations:\n  example: 名前をキーとしたアノテーションのリスト（任意）\n```\n\n[v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2) 以降、追加のフィールドは許可されていません。カスタムメタデータを追加する場合は `annotations` に追加することを推奨します。\n\n### Chart とバージョニング\n\nすべての chart にはバージョン番号が必要です。バージョンは [SemVer 2](https://semver.org/spec/v2.0.0.html) 標準に従う必要がありますが、厳密には強制されません。Helm Classic とは異なり、Helm v2 以降ではバージョン番号をリリースマーカーとして使用します。リポジトリ内のパッケージは名前とバージョンで識別されます。\n\nたとえば、version フィールドが `version: 1.2.3` に設定された `nginx` chart は以下のように名前が付けられます:\n\n```text\nnginx-1.2.3.tgz\n```\n\nより複雑な SemVer 2 の名前もサポートされています（例: `version: 1.2.3-alpha.1+ef365`）。ただし、非 SemVer 名はシステムによって明示的に禁止されています。例外として、`x` または `x.y` 形式のバージョンは許可されます。\nたとえば、先頭に v がある場合や、3 つのパーツすべてがないバージョン（例: v1.2）がある場合、有効なセマンティックバージョンに強制変換されます（例: v1.2.0）。\n\n**注:** Helm Classic と Deployment Manager は chart に関して GitHub 指向でしたが、Helm v2 以降は GitHub や Git に依存も要求もしません。そのため、バージョニングに Git SHA をまったく使用しません。\n\n`Chart.yaml` 内の `version` フィールドは、CLI を含む多くの Helm ツールで使用されます。パッケージを生成する際、`helm package` コマンドは `Chart.yaml` で見つけたバージョンをパッケージ名のトークンとして使用します。システムは、chart パッケージ名のバージョン番号が `Chart.yaml` のバージョン番号と一致することを想定しています。この想定を満たさないとエラーが発生します。\n\n### `apiVersion` フィールド\n\n`apiVersion` フィールドは、Helm 3 以上を必要とする Helm chart では `v2` にする必要があります。以前の Helm バージョンをサポートする chart は `apiVersion` が `v1` に設定されており、Helm 3 でもインストール可能です。\n\n`v1` から `v2` への変更点:\n\n- `v1` chart では別の `requirements.yaml` ファイルにあった chart 依存関係を定義する `dependencies` フィールド（[Chart 依存関係](#chart-依存関係)を参照）。\n- application chart と library chart を区別する `type` フィールド（[Chart タイプ](#chart-タイプ)を参照）。\n\n### `appVersion` フィールド\n\n`appVersion` フィールドは `version` フィールドとは関係ありません。これはアプリケーションのバージョンを指定するためのフィールドです。たとえば、`drupal` chart には `appVersion: \"8.2.1\"` があり、chart に含まれる Drupal のバージョン（デフォルト）が `8.2.1` であることを示しています。このフィールドは情報提供用であり、chart バージョンの計算には影響しません。バージョンを引用符で囲むことを強く推奨します。これにより YAML パーサーがバージョン番号を文字列として扱います。引用符で囲まないと、パースの問題が発生する場合があります。たとえば、YAML は `1.0` を浮動小数点値として、`1234e10` のような git commit SHA を指数表記として解釈します。\n\nHelm v3.5.0 以降、`helm create` はデフォルトの `appVersion` フィールドを引用符で囲むようになりました。\n\n### `kubeVersion` フィールド\n\n任意の `kubeVersion` フィールドでは、サポートされる Kubernetes バージョンの semver 制約を定義できます。Helm は chart をインストールする際にバージョン制約を検証し、クラスターがサポートされていない Kubernetes バージョンで実行されている場合は失敗します。\n\nバージョン制約には、以下のようなスペースで区切られた AND 比較を含めることができます:\n```\n>= 1.13.0 < 1.15.0\n```\nこれらは以下の例のように OR 演算子 `||` と組み合わせることができます:\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\nこの例では、バージョン `1.14.0` が除外されています。これは、特定のバージョンのバグにより chart が正しく動作しないことがわかっている場合に有用です。\n\n演算子 `=` `!=` `>` `<` `>=` `<=` を使用したバージョン制約の他に、以下の省略記法がサポートされています:\n\n * ハイフン範囲（閉区間）: `1.1 - 2.3.4` は `>= 1.1 <= 2.3.4` と同等です。\n * ワイルドカード `x`、`X`、`*`: `1.2.x` は `>= 1.2.0 < 1.3.0` と同等です。\n * チルダ範囲（パッチバージョンの変更を許可）: `~1.2.3` は `>= 1.2.3 < 1.3.0` と同等です。\n * キャレット範囲（マイナーバージョンの変更を許可）: `^1.2.3` は `>= 1.2.3 < 2.0.0` と同等です。\n\nサポートされる semver 制約の詳細については、[Masterminds/semver](https://github.com/Masterminds/semver) を参照してください。\n\n### Chart の非推奨化\n\nChart リポジトリで chart を管理する際、chart を非推奨にする必要がある場合があります。`Chart.yaml` の任意の `deprecated` フィールドを使用して、chart を非推奨としてマークできます。リポジトリ内の chart の**最新**バージョンが非推奨としてマークされている場合、chart 全体が非推奨と見なされます。非推奨としてマークされていない新しいバージョンを公開することで、chart 名を再利用できます。chart を非推奨にするワークフローは以下のとおりです:\n\n1. chart の `Chart.yaml` を更新して chart を非推奨としてマークし、バージョンをバンプする\n2. Chart リポジトリで新しい chart バージョンをリリースする\n3. ソースリポジトリ（例: git）から chart を削除する\n\n### Chart タイプ\n\n`type` フィールドは chart のタイプを定義します。タイプは `application` と `library` の 2 種類です。application がデフォルトタイプで、完全に操作可能な標準的な chart です。[library chart](/topics/library_charts.md) は chart ビルダー向けのユーティリティや関数を提供します。library chart は application chart とは異なり、インストールできず、通常はリソースオブジェクトを含みません。\n\n**注:** application chart を library chart として使用することもできます。type を `library` に設定すると有効になります。すべてのユーティリティと関数を活用できる library chart としてレンダリングされますが、chart のすべてのリソースオブジェクトはレンダリングされません。\n\n## Chart の LICENSE、README、NOTES\n\nchart には、インストール、設定、使用方法、ライセンスを説明するファイルも含めることができます。\n\nLICENSE は、chart の[ライセンス](https://en.wikipedia.org/wiki/Software_license)を含むテキストファイルです。chart にはテンプレート内にプログラミングロジックが含まれる場合があり、設定のみではないため、ライセンスを含めることができます。必要に応じて、chart によってインストールされるアプリケーションの個別のライセンスも含めることができます。\n\nchart の README は Markdown（README.md）でフォーマットする必要があり、一般的に以下を含めます:\n\n- chart が提供するアプリケーションまたはサービスの説明\n- chart を実行するための前提条件や要件\n- `values.yaml` のオプションとデフォルト値の説明\n- chart のインストールや設定に関連するその他の情報\n\nハブやその他のユーザーインターフェースで chart の詳細を表示する際、その詳細は `README.md` ファイルの内容から取得されます。\n\nchart には、インストール後や release のステータスを表示する際に出力される短いテキストの `templates/NOTES.txt` ファイルも含めることができます。このファイルは[テンプレート](#テンプレートと-values)として評価され、使用方法のメモ、次のステップ、または release に関連するその他の情報を表示するために使用できます。たとえば、データベースへの接続方法や Web UI へのアクセス方法の説明を提供できます。このファイルは `helm install` または `helm status` の実行時に STDOUT に出力されるため、内容は簡潔にし、詳細は README を参照するようにすることを推奨します。\n\n## Chart 依存関係\n\nHelm では、chart は任意の数の他の chart に依存できます。これらの依存関係は、`Chart.yaml` の `dependencies` フィールドを使用して動的にリンクするか、`charts/` ディレクトリに手動で配置して管理できます。\n\n### `dependencies` フィールドによる依存関係の管理\n\n現在の chart が必要とする chart は、`dependencies` フィールドにリストとして定義します。\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- `name` フィールドは必要な chart の名前です。\n- `version` フィールドは必要な chart のバージョンです。\n- `repository` フィールドは chart リポジトリへの完全な URL です。ローカルにそのリポジトリを追加するには `helm repo add` も使用する必要があります。\n- URL の代わりにリポジトリ名を使用することもできます\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\n依存関係を定義したら、`helm dependency update` を実行すると、依存ファイルを使用して指定されたすべての chart を `charts/` ディレクトリにダウンロードできます。\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\n`helm dependency update` が chart を取得すると、`charts/` ディレクトリに chart アーカイブとして保存されます。上記の例では、charts ディレクトリに以下のファイルが存在することになります:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### 依存関係の alias フィールド\n\n上記の他のフィールドに加えて、各依存関係エントリには任意の `alias` フィールドを含めることができます。\n\n依存関係 chart にエイリアスを追加すると、エイリアスを新しい依存関係の名前として使用して chart を依存関係に配置します。\n\n別の名前で chart にアクセスする必要がある場合に `alias` を使用できます。\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\n上記の例では、`parentchart` に対して合計 3 つの依存関係が取得されます:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nこれを手動で行う方法は、`charts/` ディレクトリに異なる名前で同じ chart を複数回コピー＆ペーストすることです。\n\n#### 依存関係の tags と condition フィールド\n\n上記の他のフィールドに加えて、各依存関係エントリには任意の `tags` と `condition` フィールドを含めることができます。\n\nすべての chart はデフォルトでロードされます。`tags` または `condition` フィールドが存在する場合、それらが評価され、適用される chart のロードを制御するために使用されます。\n\ncondition - condition フィールドは 1 つ以上の YAML パス（カンマ区切り）を保持します。このパスが最上位の親の values に存在し、boolean 値に解決される場合、その boolean 値に基づいて chart が有効または無効になります。リスト内で見つかった最初の有効なパスのみが評価され、パスが存在しない場合、condition は効果がありません。\n\ntags - tags フィールドは、この chart に関連付けるラベルの YAML リストです。最上位の親の values で、タグと boolean 値を指定することで、タグを持つすべての chart を有効または無効にできます。\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\n上記の例では、タグ `front-end` を持つすべての chart が無効になりますが、親の values で `subchart1.enabled` パスが 'true' と評価されるため、condition が `front-end` タグをオーバーライドし、`subchart1` が有効になります。\n\n`subchart2` はタグ `back-end` を持ち、そのタグが `true` と評価されるため、`subchart2` が有効になります。また、`subchart2` には condition が指定されていますが、親の values に対応するパスと値がないため、その condition は効果がありません。\n\n##### CLI での tags と conditions の使用\n\n`--set` パラメータを通常どおり使用して、tag と condition の値を変更できます。\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### tags と condition の解決\n\n- **conditions（values で設定されている場合）は常に tags をオーバーライドします。** 存在する最初の condition パスが優先され、その chart の後続のパスは無視されます。\n- tags は「chart のタグのいずれかが true の場合、chart を有効にする」として評価されます。\n- tags と conditions の値は最上位の親の values で設定する必要があります。\n- values の `tags:` キーはトップレベルキーである必要があります。グローバルおよびネストされた `tags:` テーブルは現在サポートされていません。\n\n#### dependencies による子の values のインポート\n\n場合によっては、子 chart の values を親 chart に伝播させ、共通のデフォルトとして共有することが望ましい場合があります。`exports` フォーマットを使用する追加の利点は、将来のツールがユーザー設定可能な値を調査できるようになることです。\n\nインポートする値を含むキーは、親 chart の `dependencies` の `import-values` フィールドで YAML リストを使用して指定できます。リストの各項目は、子 chart の `exports` フィールドからインポートされるキーです。\n\n`exports` キーに含まれていない値をインポートするには、[child-parent](#child-parent-フォーマットの使用) フォーマットを使用してください。両方のフォーマットの例を以下に示します。\n\n##### exports フォーマットの使用\n\n子 chart の `values.yaml` ファイルのルートに `exports` フィールドがある場合、以下の例のようにインポートするキーを指定することで、その内容を親の values に直接インポートできます:\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\nインポートリストでキー `data` を指定しているため、Helm は子 chart の `exports` フィールドで `data` キーを探し、その内容をインポートします。\n\n最終的な親の values にはエクスポートされたフィールドが含まれます:\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\n親キー `data` は親の最終 values に含まれないことに注意してください。親キーを指定する必要がある場合は、'child-parent' フォーマットを使用してください。\n\n##### child-parent フォーマットの使用\n\n子 chart の values の `exports` キーに含まれていない値にアクセスするには、インポートする値のソースキー（`child`）と親 chart の values の宛先パス（`parent`）を指定する必要があります。\n\n以下の例の `import-values` は、`child:` パスにある値を取得し、`parent:` で指定されたパスの親の values にコピーするよう Helm に指示しています:\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\n上記の例では、subchart1 の values の `default.data` にある値が、以下に詳述するように親 chart の values の `myimports` キーにインポートされます:\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\n親 chart の結果の values は以下のようになります:\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\n親の最終 values には、subchart1 からインポートされた `myint` と `mybool` フィールドが含まれるようになりました。\n\n### `charts/` ディレクトリによる手動の依存関係管理\n\n依存関係をより細かく制御したい場合、依存関係 chart を `charts/` ディレクトリにコピーすることで明示的に表現できます。\n\n依存関係は展開された chart ディレクトリである必要がありますが、名前は `_` または `.` で始めることはできません。そのようなファイルは chart ローダーによって無視されます。\n\nたとえば、WordPress chart が Apache chart に依存している場合、Apache chart（正しいバージョン）が WordPress chart の `charts/` ディレクトリに配置されます:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\n上記の例は、WordPress chart が Apache と MySQL への依存関係を、`charts/` ディレクトリ内にそれらの chart を含めることでどのように表現しているかを示しています。\n\n**ヒント:** _依存関係を `charts/` ディレクトリにドロップするには、`helm pull` コマンドを使用してください_\n\n### 依存関係使用時の操作面\n\n上記のセクションでは chart 依存関係の指定方法を説明しましたが、`helm install` や `helm upgrade` を使用した chart のインストールにどのように影響するのでしょうか？\n\n\"A\" という名前の chart が以下の Kubernetes オブジェクトを作成するとします:\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nさらに、A は以下のオブジェクトを作成する chart B に依存しています:\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nchart A のインストール/アップグレード後、単一の Helm release が作成/変更されます。この release は、上記のすべての Kubernetes オブジェクトを以下の順序で作成/更新します:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nこれは、Helm が chart とそのすべての依存関係をインストール/アップグレードする際に、Kubernetes オブジェクトが以下のように処理されるためです:\n\n- 単一のセットに集約される\n- タイプ順、次に名前順でソートされる\n- その順序で作成/更新される\n\nしたがって、chart とその依存関係のすべてのオブジェクトを含む単一の release が作成されます。\n\nKubernetes タイプのインストール順序は、kind_sorter.go の InstallOrder 列挙型で指定されています（[Helm ソースファイル](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)を参照）。\n\n## テンプレートと Values\n\nHelm Chart テンプレートは [Go テンプレート言語](https://golang.org/pkg/text/template/)で記述され、[Sprig ライブラリ](https://github.com/Masterminds/sprig)の 50 以上のアドオンテンプレート関数といくつかの[特殊な関数](/howto/charts_tips_and_tricks.md)が追加されています。\n\nすべてのテンプレートファイルは chart の `templates/` フォルダに格納されます。Helm が chart をレンダリングする際、そのディレクトリ内のすべてのファイルがテンプレートエンジンを通過します。\n\nテンプレートの values は 2 つの方法で提供されます:\n\n- chart 開発者は chart 内に `values.yaml` というファイルを提供できます。このファイルにはデフォルト値を含めることができます。\n- chart ユーザーは values を含む YAML ファイルを提供できます。これはコマンドラインで `helm install` を使用して提供できます。\n\nユーザーがカスタム values を提供すると、それらの値は chart の `values.yaml` ファイルの値をオーバーライドします。\n\n### テンプレートファイル\n\nテンプレートファイルは Go テンプレートを記述するための標準的な規約に従います（詳細は [text/template Go パッケージドキュメント](https://golang.org/pkg/text/template/)を参照）。テンプレートファイルの例は以下のようになります:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n上記の例は [https://github.com/deis/charts](https://github.com/deis/charts) に緩く基づいており、Kubernetes レプリケーションコントローラのテンプレートです。以下の 4 つのテンプレート値を使用できます（通常は `values.yaml` ファイルで定義されます）:\n\n- `imageRegistry`: Docker イメージのソースレジストリ。\n- `dockerTag`: docker イメージのタグ。\n- `pullPolicy`: Kubernetes のプルポリシー。\n- `storage`: ストレージバックエンド。デフォルトは `\"minio\"` に設定されています。\n\nこれらの値はすべてテンプレート作成者によって定義されています。Helm はパラメータを要求したり指定したりしません。\n\n動作する多くの chart を見るには、CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) をチェックしてください。\n\n### 事前定義された Values\n\n`values.yaml` ファイル（または `--set` フラグ）を通じて提供される values は、テンプレート内の `.Values` オブジェクトからアクセスできます。ただし、テンプレートでアクセスできる他の事前定義されたデータもあります。\n\n以下の values は事前定義されており、すべてのテンプレートで利用可能で、オーバーライドできません。すべての values と同様に、名前は_大文字と小文字を区別_します。\n\n- `Release.Name`: release の名前（chart ではない）\n- `Release.Namespace`: chart がリリースされた namespace。\n- `Release.Service`: release を実行したサービス。\n- `Release.IsUpgrade`: 現在の操作がアップグレードまたはロールバックの場合、これは true に設定されます。\n- `Release.IsInstall`: 現在の操作がインストールの場合、これは true に設定されます。\n- `Chart`: `Chart.yaml` の内容。したがって、chart バージョンは `Chart.Version` で取得でき、メンテナーは `Chart.Maintainers` にあります。\n- `Files`: chart 内のすべての非特殊ファイルを含むマップのようなオブジェクト。これはテンプレートへのアクセスは提供しませんが、存在する追加ファイルへのアクセスを提供します（`.helmignore` を使用して除外されていない限り）。ファイルは `{{ index .Files \"file.name\" }}` または `{{.Files.Get name }}` 関数を使用してアクセスできます。`{{ .Files.GetBytes }}` を使用してファイルの内容を `[]byte` としてアクセスすることもできます。\n- `Capabilities`: Kubernetes のバージョン（`{{ .Capabilities.KubeVersion }}`）やサポートされている Kubernetes API バージョン（`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`）に関する情報を含むマップのようなオブジェクト。\n\n**注:** 不明な `Chart.yaml` フィールドは削除されます。`Chart` オブジェクト内でアクセスできません。したがって、`Chart.yaml` を使用して任意の構造化データをテンプレートに渡すことはできません。ただし、values ファイルはそのために使用できます。\n\n### values ファイル\n\n前のセクションのテンプレートを考慮すると、必要な values を提供する `values.yaml` ファイルは以下のようになります:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nvalues ファイルは YAML でフォーマットされます。chart にはデフォルトの `values.yaml` ファイルを含めることができます。Helm install コマンドでは、追加の YAML 値を提供することで値をオーバーライドできます:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nこの方法で values が渡されると、デフォルトの values ファイルにマージされます。たとえば、以下のような `myvals.yaml` ファイルを考えてみましょう:\n\n```yaml\nstorage: \"gcs\"\n```\n\nこれが chart の `values.yaml` とマージされると、生成される内容は以下のようになります:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\n最後のフィールドのみがオーバーライドされたことに注意してください。\n\n**注:** chart 内に含まれるデフォルトの values ファイルは、`values.yaml` という名前である_必要があります_。ただし、コマンドラインで指定するファイルは任意の名前にできます。\n\n**注:** `helm install` または `helm upgrade` で `--set` フラグを使用すると、それらの値はクライアント側で単純に YAML に変換されます。\n\n**注:** values ファイルに必須のエントリが存在する場合、chart テンプレートで ['required' 関数](/howto/charts_tips_and_tricks.md)を使用して必須として宣言できます。\n\nこれらの values はすべて、`.Values` オブジェクトを使用してテンプレート内でアクセスできます:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### スコープ、依存関係、Values\n\nvalues ファイルは、トップレベル chart の値と、その chart の `charts/` ディレクトリに含まれる chart の値を宣言できます。言い換えると、values ファイルは chart とその依存関係のいずれにも値を提供できます。たとえば、上記のデモ用 WordPress chart には `mysql` と `apache` が依存関係としてあります。values ファイルはこれらすべてのコンポーネントに値を提供できます:\n\n```yaml\ntitle: \"My WordPress Site\" # WordPress テンプレートに送信される\n\nmysql:\n  max_connections: 100 # MySQL に送信される\n  password: \"secret\"\n\napache:\n  port: 8080 # Apache に渡される\n```\n\n上位レベルの chart は、下位で定義されたすべての変数にアクセスできます。したがって、WordPress chart は MySQL のパスワードに `.Values.mysql.password` としてアクセスできます。ただし、下位レベルの chart は親 chart のものにアクセスできないため、MySQL は `title` プロパティにアクセスできません。同様に、`apache.port` にもアクセスできません。\n\nvalues は名前空間化されていますが、名前空間はプルーニングされます。したがって、WordPress chart は MySQL のパスワードフィールドに `.Values.mysql.password` としてアクセスできます。しかし、MySQL chart では values のスコープが縮小され、名前空間プレフィックスが削除されるため、パスワードフィールドは単に `.Values.password` として見えます。\n\n#### グローバル Values\n\n2.0.0-Alpha.2 以降、Helm は特別な「グローバル」値をサポートしています。前の例の修正版を考えてみましょう:\n\n```yaml\ntitle: \"My WordPress Site\" # WordPress テンプレートに送信される\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # MySQL に送信される\n  password: \"secret\"\n\napache:\n  port: 8080 # Apache に渡される\n```\n\n上記は `app: MyWordPress` という値を持つ `global` セクションを追加しています。この値は `.Values.global.app` として_すべての_ chart で利用可能です。\n\nたとえば、`mysql` テンプレートは `app` に `{{ .Values.global.app}}` としてアクセスでき、`apache` chart も同様です。実質的に、上記の values ファイルは以下のように再生成されます:\n\n```yaml\ntitle: \"My WordPress Site\" # WordPress テンプレートに送信される\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # MySQL に送信される\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Apache に渡される\n```\n\nこれにより、1 つのトップレベル変数をすべてのサブチャートと共有できます。これは `metadata` プロパティ（ラベルなど）の設定に便利です。\n\nサブチャートがグローバル変数を宣言した場合、そのグローバルは（サブチャートのサブチャートに）_下方向_に渡されますが、親 chart には_上方向_に渡されません。サブチャートが親 chart の値に影響を与える方法はありません。\n\nまた、親 chart のグローバル変数はサブチャートのグローバル変数よりも優先されます。\n\n### スキーマファイル\n\nchart メンテナーは、values に構造を定義したい場合があります。これは `values.schema.json` ファイルでスキーマを定義することで実現できます。スキーマは [JSON Schema](https://json-schema.org/) として表現されます。以下のようになります:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nこのスキーマは values に適用され、検証が行われます。検証は以下のコマンドが実行されたときに行われます:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nこのスキーマの要件を満たす `values.yaml` ファイルの例は以下のようになります:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nスキーマは `values.yaml` ファイルだけでなく、最終的な `.Values` オブジェクトに適用されることに注意してください。つまり、以下の `yaml` ファイルは、以下に示す適切な `--set` オプションで chart がインストールされた場合に有効です。\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nさらに、最終的な `.Values` オブジェクトは*すべて*のサブチャートスキーマに対してチェックされます。これは、サブチャートの制限が親 chart によって回避できないことを意味します。これは逆方向にも機能します - サブチャートの `values.yaml` ファイルで満たされていない要件がある場合、親 chart はそれらの制限を満たす*必要があります*。\n\nスキーマ検証は以下のオプションを設定することで無効にできます。\nこれは、chart の JSON Schema ファイルにリモート参照が含まれているエアギャップ環境で特に便利です。\n```console\nhelm install --skip-schema-validation\n```\n\n### リファレンス\n\nテンプレート、values、スキーマファイルを記述する際に役立ついくつかの標準的なリファレンスがあります。\n\n- [Go templates](https://godoc.org/text/template)\n- [Extra template functions](https://godoc.org/github.com/Masterminds/sprig)\n- [The YAML format](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definition（CRD）\n\nKubernetes は、新しい種類の Kubernetes オブジェクトを宣言するメカニズムを提供しています。CustomResourceDefinition（CRD）を使用すると、Kubernetes 開発者はカスタムリソースタイプを宣言できます。\n\nHelm 3 では、CRD は特別な種類のオブジェクトとして扱われます。chart の残りの部分より前にインストールされ、いくつかの制限があります。\n\nCRD YAML ファイルは chart 内の `crds/` ディレクトリに配置する必要があります。複数の CRD（YAML の開始マーカーと終了マーカーで区切られた）を同じファイルに配置できます。Helm は CRD ディレクトリ内の_すべて_のファイルを Kubernetes にロードしようとします。\n\nCRD ファイルは_テンプレート化できません_。プレーンな YAML ドキュメントである必要があります。\n\nHelm が新しい chart をインストールする際、CRD をアップロードし、API サーバーによって CRD が利用可能になるまで一時停止し、その後テンプレートエンジンを起動して chart の残りをレンダリングし、Kubernetes にアップロードします。この順序のため、CRD 情報は Helm テンプレートの `.Capabilities` オブジェクトで利用可能であり、Helm テンプレートは CRD で宣言されたオブジェクトの新しいインスタンスを作成できます。\n\nたとえば、chart の `crds/` ディレクトリに `CronTab` の CRD がある場合、`templates/` ディレクトリで `CronTab` kind のインスタンスを作成できます:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\n`crontab.yaml` ファイルには、テンプレートディレクティブなしで CRD が含まれている必要があります:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nその後、テンプレート `mycrontab.yaml` は新しい `CronTab` を作成できます（通常どおりテンプレートを使用）:\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm は、`templates/` 内のものをインストールする前に、`CronTab` kind がインストールされ、Kubernetes API サーバーから利用可能であることを確認します。\n\n### CRD の制限\n\nKubernetes のほとんどのオブジェクトとは異なり、CRD はグローバルにインストールされます。そのため、Helm は CRD の管理に非常に慎重なアプローチを取ります。CRD には以下の制限があります:\n\n- CRD は再インストールされません。Helm が `crds/` ディレクトリの CRD がすでに存在すると判断した場合（バージョンに関係なく）、Helm はインストールやアップグレードを試みません。\n- CRD はアップグレードやロールバック時にインストールされません。Helm はインストール操作時のみ CRD を作成します。\n- CRD は削除されません。CRD を削除すると、クラスター内のすべての namespace にある CRD のすべてのコンテンツが自動的に削除されます。そのため、Helm は CRD を削除しません。\n\nCRD をアップグレードまたは削除したいオペレーターは、手動で十分注意して行うことを推奨します。\n\n## Helm を使用した Chart の管理\n\n`helm` ツールには chart を操作するためのいくつかのコマンドがあります。\n\n新しい chart を作成できます:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nchart を編集したら、`helm` で chart アーカイブにパッケージ化できます:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\n`helm` を使用して chart のフォーマットや情報の問題を見つけることもできます:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Chart リポジトリ\n\n_chart リポジトリ_は、1 つ以上のパッケージ化された chart をホストする HTTP サーバーです。`helm` はローカルの chart ディレクトリを管理するために使用できますが、chart を共有する際は chart リポジトリが推奨されるメカニズムです。\n\nYAML ファイルと tar ファイルを提供でき、GET リクエストに応答できる任意の HTTP サーバーをリポジトリサーバーとして使用できます。Helm チームは、Web サイトモードを有効にした Google Cloud Storage や、Web サイトモードを有効にした S3 など、いくつかのサーバーをテストしています。\n\nリポジトリは主に、リポジトリが提供するすべてのパッケージのリストと、それらのパッケージを取得して検証するためのメタデータを持つ `index.yaml` という特別なファイルの存在によって特徴付けられます。\n\nクライアント側では、リポジトリは `helm repo` コマンドで管理されます。ただし、Helm はリモートリポジトリサーバーに chart をアップロードするためのツールを提供していません。これは、実装するサーバーに大きな要件を追加し、リポジトリの設定の障壁を上げるためです。\n\n## Chart スターターパック\n\n`helm create` コマンドには、「スターター chart」を指定できる任意の `--starter` オプションがあります。また、starter オプションには短いエイリアス `-p` があります。\n\n使用例:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nスターターは通常の chart ですが、`$XDG_DATA_HOME/helm/starters` に配置されています。chart 開発者は、スターターとして使用するために特別に設計された chart を作成できます。そのような chart は以下の考慮事項を念頭に置いて設計する必要があります:\n\n- `Chart.yaml` はジェネレーターによって上書きされます。\n- ユーザーはそのような chart の内容を変更することを期待しているため、ドキュメントでユーザーがどのように変更できるかを示す必要があります。\n- `<CHARTNAME>` のすべての出現箇所は指定された chart 名に置き換えられるため、スターター chart をテンプレートとして使用できます。ただし、一部の変数ファイルは例外です。たとえば、`vars` ディレクトリ内のカスタムファイルや特定の `README.md` ファイルを使用する場合、それらの内部では `<CHARTNAME>` は置き換えられません。また、chart の説明は継承されません。\n\n現在、`$XDG_DATA_HOME/helm/starters` に chart を追加する唯一の方法は、手動でコピーすることです。chart のドキュメントで、そのプロセスを説明することを推奨します。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: Chart Hook\ndescription: chart hook の使い方を説明します。\nsidebar_position: 2\n---\n\nHelm は、chart 開発者が release のライフサイクルの特定のポイントに介入できる _hook_ メカニズムを提供します。たとえば、hook を使用して以下のことができます:\n\n- インストール時に他の chart がロードされる前に ConfigMap や Secret をロードする。\n- 新しい chart をインストールする前にデータベースをバックアップする Job を実行し、アップグレード後にデータを復元する 2 番目の Job を実行する。\n- release を削除する前に Job を実行し、サービスをローテーションから graceful に切り離してから削除する。\n\nhook は通常のテンプレートと同じように機能しますが、Helm が異なる方法で利用するための特別なアノテーションを持っています。このセクションでは、hook の基本的な使用パターンを説明します。\n\n## 利用可能な Hook\n\n以下の hook が定義されています:\n\n| アノテーション値 | 説明                                                                                           |\n| ---------------- | ---------------------------------------------------------------------------------------------- |\n| `pre-install`    | テンプレートがレンダリングされた後、Kubernetes にリソースが作成される前に実行されます             |\n| `post-install`   | すべてのリソースが Kubernetes にロードされた後に実行されます                                    |\n| `pre-delete`     | 削除リクエスト時、Kubernetes からリソースが削除される前に実行されます                           |\n| `post-delete`    | 削除リクエスト時、release のすべてのリソースが削除された後に実行されます                        |\n| `pre-upgrade`    | アップグレードリクエスト時、テンプレートがレンダリングされた後、リソースが更新される前に実行されます |\n| `post-upgrade`   | アップグレードリクエスト時、すべてのリソースがアップグレードされた後に実行されます              |\n| `pre-rollback`   | ロールバックリクエスト時、テンプレートがレンダリングされた後、リソースがロールバックされる前に実行されます |\n| `post-rollback`  | ロールバックリクエスト時、すべてのリソースが変更された後に実行されます                          |\n| `test`           | Helm test サブコマンドが実行されたときに実行されます（[テストのドキュメント](/topics/chart_tests.md)を参照） |\n\n_注: `crd-install` hook は Helm 3 で `crds/` ディレクトリに置き換えられ、削除されました。_\n\n## Hook と Release ライフサイクル\n\nhook を使用すると、chart 開発者は release ライフサイクルの戦略的なポイントで操作を実行できます。たとえば、`helm install` のライフサイクルを考えてみましょう。デフォルトでは、ライフサイクルは以下のようになります:\n\n1. ユーザーが `helm install foo` を実行します\n2. Helm ライブラリの install API が呼び出されます\n3. いくつかの検証の後、ライブラリが `foo` テンプレートをレンダリングします\n4. ライブラリが結果のリソースを Kubernetes にロードします\n5. ライブラリが release オブジェクト（およびその他のデータ）をクライアントに返します\n6. クライアントが終了します\n\nHelm は `install` ライフサイクルに対して 2 つの hook を定義しています: `pre-install` と `post-install` です。`foo` chart の開発者が両方の hook を実装した場合、ライフサイクルは以下のように変更されます:\n\n1. ユーザーが `helm install foo` を実行します\n2. Helm ライブラリの install API が呼び出されます\n3. `crds/` ディレクトリ内の CRD がインストールされます\n4. いくつかの検証の後、ライブラリが `foo` テンプレートをレンダリングします\n5. ライブラリが `pre-install` hook の実行を準備します（hook リソースを Kubernetes にロード）\n6. ライブラリが hook を weight でソートし（デフォルトは weight 0）、次にリソース kind、最後に名前の昇順でソートします\n7. ライブラリが最も低い weight の hook から順にロードします（負から正へ）\n8. ライブラリが hook が「Ready」になるまで待機します（CRD を除く）\n9. ライブラリが結果のリソースを Kubernetes にロードします。`--wait` フラグが設定されている場合、ライブラリはすべてのリソースが ready 状態になるまで待機し、ready になるまで `post-install` hook を実行しません。\n10. ライブラリが `post-install` hook を実行します（hook リソースをロード）\n11. ライブラリが hook が「Ready」になるまで待機します\n12. ライブラリが release オブジェクト（およびその他のデータ）をクライアントに返します\n13. クライアントが終了します\n\nhook が ready になるまで待機するとはどういう意味でしょうか？これは hook で宣言されたリソースによって異なります。リソースが `Job` または `Pod` kind の場合、Helm は正常に完了するまで待機します。hook が失敗すると、release は失敗します。これは _ブロッキング操作_ であり、Job の実行中は Helm クライアントが一時停止します。\n\nその他のすべての kind では、Kubernetes がリソースをロード済み（追加または更新）としてマークした時点で、そのリソースは「Ready」と見なされます。hook で多くのリソースが宣言されている場合、リソースは順次実行されます。hook weight がある場合（以下を参照）、weight 順に実行されます。Helm 3.2.0 以降、同じ weight を持つ hook リソースは、通常の非 hook リソースと同じ順序でインストールされます。それ以外の場合、順序は保証されません。（Helm 2.3.0 以降ではアルファベット順にソートされていました。ただし、この動作は拘束力があるとは見なされておらず、将来変更される可能性があります。）hook weight を追加し、weight が重要でない場合は `0` に設定することが推奨されます。\n\n### hook リソースは対応する release で管理されない\n\nhook が作成するリソースは、現在のところ release の一部として追跡または管理されません。Helm が hook が ready 状態に達したことを確認すると、hook リソースはそのまま残されます。対応する release が削除されたときの hook リソースのガベージコレクションは、将来の Helm 3 で追加される可能性があります。そのため、削除されてはならない hook リソースには `helm.sh/resource-policy: keep` アノテーションを付ける必要があります。\n\n実際には、hook でリソースを作成した場合、`helm uninstall` でそのリソースを削除することはできません。このようなリソースを破棄するには、hook テンプレートファイルに[カスタムの `helm.sh/hook-delete-policy` アノテーションを追加する](#hook-削除ポリシー)か、[Job リソースの TTL（Time To Live）フィールドを設定する](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/)必要があります。\n\n## Hook の記述\n\nhook は、`metadata` セクションに特別なアノテーションを持つ Kubernetes マニフェストファイルです。テンプレートファイルであるため、`.Values`、`.Release`、`.Template` の読み取りを含む、すべての通常のテンプレート機能を使用できます。\n\nたとえば、`templates/post-install-job.yaml` に保存されている以下のテンプレートは、`post-install` で実行される Job を宣言しています:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nこのテンプレートを hook にしているのは、以下のアノテーションです:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\n1 つのリソースで複数の hook を実装できます:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\n同様に、特定の hook を実装するリソースの数に制限はありません。たとえば、Secret と ConfigMap の両方を pre-install hook として宣言できます。\n\nsubchart が hook を宣言している場合、それらも評価されます。トップレベルの chart が subchart で宣言された hook を無効にする方法はありません。\n\nhook の weight を定義して、決定論的な実行順序を構築できます。weight は以下のアノテーションで定義します:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nhook weight は正または負の数値ですが、文字列として表現する必要があります。Helm が特定の Kind の hook の実行サイクルを開始するとき、それらの hook を昇順でソートします。\n\n### Hook 削除ポリシー\n\n対応する hook リソースをいつ削除するかを決定するポリシーを定義できます。hook 削除ポリシーは以下のアノテーションで定義します:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\n以下の定義済みアノテーション値から 1 つ以上を選択できます:\n\n| アノテーション値       | 説明                                                          |\n| ---------------------- | ------------------------------------------------------------- |\n| `before-hook-creation` | 新しい hook が起動される前に以前のリソースを削除します（デフォルト） |\n| `hook-succeeded`       | hook が正常に実行された後にリソースを削除します                |\n| `hook-failed`          | 実行中に hook が失敗した場合にリソースを削除します              |\n\nhook 削除ポリシーアノテーションが指定されていない場合、デフォルトで `before-hook-creation` の動作が適用されます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/index.mdx",
    "content": "---\ntitle: トピック\nsidebar_position: 3\n---\n\n# トピックガイド\n\nここでは、Helm の必要な、または知りたいすべての主要部分の概要を\n説明します。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: 非推奨の Kubernetes API\ndescription: Helm における非推奨の Kubernetes API について説明します\n---\n\nKubernetes は API 駆動型のシステムであり、システムへの理解が深まるにつれて API も進化します。これはシステムとその API において一般的なプラクティスです。API を進化させるうえで重要なのは、適切な非推奨ポリシーとプロセスを整備し、API の変更内容をユーザーに通知することです。API の利用者は、どの API がいつ削除または変更されるのかを事前に把握する必要があります。これにより、予期しない破壊的変更を回避できます。\n\n[Kubernetes の非推奨ポリシー](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)には、Kubernetes が API バージョンの変更をどのように扱うかが記載されています。このポリシーでは、非推奨の発表後に各 API バージョンがサポートされる期間が定められています。非推奨の発表を把握し、API バージョンがいつ削除されるかを知っておくことが、影響を最小限に抑えるために重要です。\n\n以下は、[Kubernetes 1.16 における非推奨 API バージョンの削除](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/)に関するアナウンスの例です。このアナウンスはリリースの数ヶ月前に告知されました。これらの API バージョンは、この発表より前にすでに非推奨として発表されていたものです。このように、API バージョンのサポート状況を利用者に適切に通知するポリシーが整備されています。\n\nHelm テンプレートでは、Kubernetes オブジェクトを定義する際に [Kubernetes API グループ](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)を指定します。これは Kubernetes のマニフェストファイルと同様です。API グループはテンプレートの `apiVersion` フィールドで指定し、Kubernetes オブジェクトの API バージョンを識別します。Helm ユーザーと chart メンテナーは、Kubernetes API バージョンがいつ非推奨となり、どの Kubernetes バージョンで削除されるかを把握しておく必要があります。\n\n## Chart メンテナー向け\n\nchart を監査し、非推奨または特定の Kubernetes バージョンで削除された API バージョンがないか確認してください。サポートが終了した、または終了予定の API バージョンが見つかった場合は、サポートされているバージョンに更新し、新しいバージョンの chart をリリースしてください。API バージョンは `kind` と `apiVersion` フィールドで定義されます。以下は、Kubernetes 1.16 で削除された `Deployment` オブジェクトの API バージョンの例です。\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Helm ユーザー向け\n\n使用している chart を監査し（[Chart メンテナー向け](#chart-メンテナー向け)と同様）、非推奨または特定の Kubernetes バージョンで削除された API バージョンがないか確認してください。該当する chart が見つかった場合は、サポートされている API バージョンを含む最新バージョンの chart を確認するか、自身で chart を更新してください。\n\nさらに、デプロイ済みの chart（Helm release）についても監査し、非推奨または削除された API バージョンがないか確認する必要があります。`helm get manifest` コマンドを使用して release の詳細を取得できます。\n\nサポートされている API への Helm release の更新方法は、調査結果に応じて以下のように異なります。\n\n1. 非推奨の API バージョンのみが見つかった場合:\n   - サポートされている Kubernetes API バージョンを含む chart で `helm upgrade` を実行します\n   - アップグレード時の説明（description）に、現在のバージョンより前にはロールバックしないよう注意書きを追加します\n2. 特定の Kubernetes バージョンで削除された API バージョンが見つかった場合:\n   - API バージョンがまだ利用可能な Kubernetes バージョンを実行している場合（例: Kubernetes 1.15 を使用しており、Kubernetes 1.16 で削除される API を使用している場合）:\n     - 手順 1 の方法に従います\n   - すでに一部の API バージョンが利用不可となっている Kubernetes バージョンを実行している場合（例: `helm get manifest` で報告された API バージョンの一部が、現在の Kubernetes バージョンでは利用不可）:\n     - クラスターに保存されている release マニフェストを編集し、API バージョンをサポートされている API に更新する必要があります。詳細は [Release マニフェストの API バージョンの更新](#release-マニフェストの-api-バージョンの更新)を参照してください\n\n> 注意: サポートされている API で Helm release を更新した後は、その更新バージョンより前のリリースバージョンには絶対にロールバックしないでください。\n\n> 推奨: ベストプラクティスとして、非推奨の API バージョンを使用している release は、それらの API バージョンが削除される Kubernetes バージョンへのアップグレード前に、サポートされている API バージョンに更新してください。\n\n上記の推奨手順で release を更新しない場合、API バージョンが削除された Kubernetes バージョンで release をアップグレードしようとすると、以下のようなエラーが発生します。\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nこのエラーが発生する理由は、Helm が現在デプロイされている release と、更新後の chart との間で差分パッチを作成しようとするためです。現在の release には、この Kubernetes バージョンで削除された API が含まれています。根本的な原因は、Kubernetes が API バージョンを削除すると、Kubernetes Go クライアントライブラリが非推奨のオブジェクトを解析できなくなることです。その結果、Helm はライブラリの呼び出し時に失敗します。残念ながら、Helm はこの状況から回復できず、該当する release を管理できなくなります。この状況からの回復方法については、[Release マニフェストの API バージョンの更新](#release-マニフェストの-api-バージョンの更新)を参照してください。\n\n## Release マニフェストの API バージョンの更新\n\nマニフェストは Helm release オブジェクトのプロパティであり、クラスター内の Secret（デフォルト）または ConfigMap のデータフィールドに保存されます。データフィールドには、gzip 圧縮され base64 エンコードされたオブジェクトが含まれます（Secret の場合は追加の base64 エンコードがあります）。release の namespace 内には、release のバージョン/リビジョンごとに Secret/ConfigMap が存在します。\n\nHelm の [mapkubeapis](https://github.com/helm/helm-mapkubeapis) プラグインを使用すると、release をサポートされている API に更新できます。詳細は readme を参照してください。\n\nまたは、以下の手動手順に従って release マニフェストの API バージョンを更新することもできます。構成に応じて、Secret または ConfigMap バックエンドの手順に従ってください。\n\n- 最新のデプロイ済み release に関連付けられた Secret または ConfigMap の名前を取得します:\n  - Secret バックエンド: `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - ConfigMap バックエンド: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- 最新のデプロイ済み release の詳細を取得します:\n  - Secret バックエンド: `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - ConfigMap バックエンド: `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- 問題が発生した場合に復元できるよう、release をバックアップします:\n  - `cp release.yaml release.bak`\n  - 問題発生時は次のコマンドで復元します: `kubectl apply -f release.bak -n\n    <release_namespace>`\n- release オブジェクトをデコードします:\n  - Secret バックエンド: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - ConfigMap バックエンド: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- マニフェストの API バージョンを変更します。任意のツール（エディタなど）を使用できます。変更対象は、デコードした release オブジェクト（`release.data.decoded`）の `manifest` フィールドです\n- release オブジェクトをエンコードします:\n  - Secret バックエンド: `cat release.data.decoded | gzip | base64 | base64`\n  - ConfigMap バックエンド: `cat release.data.decoded | gzip | base64`\n- デプロイ済み release ファイル（`release.yaml`）の `data.release` プロパティ値を、新しくエンコードした release オブジェクトで置き換えます\n- ファイルを namespace に適用します: `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- サポートされている Kubernetes API バージョンを含む chart で `helm upgrade` を実行します\n- アップグレード時の説明（description）に、現在のバージョンより前にはロールバックしないよう注意書きを追加します\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: Kubernetes ディストリビューションガイド\ndescription: 特定の Kubernetes 環境での Helm の使用に関する情報をまとめています。\nsidebar_position: 10\n---\n\nHelm は [CNCF 適合 Kubernetes](https://github.com/cncf/k8s-conformance)（[認定の有無](https://www.cncf.io/certification/software-conformance/)を問わず）で動作します。\n\nこのドキュメントでは、特定の Kubernetes 環境での Helm の使用に関する情報をまとめています。各ディストリビューションに関する情報の追加・更新にご協力いただけると幸いです。\n\n\n## AKS\n\nHelm は [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm) で動作します。\n\n## DC/OS\n\nHelm は Mesosphere の DC/OS 1.11 Kubernetes プラットフォームでテストされており、追加の設定なしで動作します。\n\n## EKS\n\nHelm は Amazon Elastic Kubernetes Service（Amazon EKS）で動作します。詳細は [Using Helm with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html) を参照してください。\n\n## GKE\n\nGoogle の GKE ホステッド Kubernetes プラットフォームは、Helm で動作することが確認されており、追加の設定は不要です。\n\n## `scripts/local-cluster` と Hyperkube\n\n`scripts/local-cluster.sh` で構成された Hyperkube は動作することが確認されています。Hyperkube を直接使用する場合は、手動での設定が必要になることがあります。\n\n## IKS\n\nHelm は [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm) で動作します。\n\n## KIND（Kubernetes IN Docker）\n\nHelm は [KIND](https://github.com/kubernetes-sigs/kind) で定期的にテストされています。\n\n## KubeOne\n\nHelm は KubeOne によって構築されたクラスターで問題なく動作します。\n\n## Kubermatic\n\nHelm は Kubermatic によって作成されたユーザークラスターで問題なく動作します。シードクラスターはさまざまな方法で構築できるため、Helm のサポートはその構成に依存します。\n\n## MicroK8s\n\nHelm は [MicroK8s](https://microk8s.io) で以下のコマンドを使用して有効化できます。\n`microk8s.enable helm3`\n\n## Minikube\n\nHelm は [Minikube](https://github.com/kubernetes/minikube) でテストされており、動作することが確認されています。追加の設定は不要です。\n\n## Openshift\n\nHelm は OpenShift Online、OpenShift Dedicated、OpenShift Container Platform（バージョン 3.6 以上）、または OpenShift Origin（バージョン 3.6 以上）で問題なく動作します。詳細は[こちらのブログ記事](https://blog.openshift.com/getting-started-helm-openshift/)を参照してください。\n\n## Platform9\n\nHelm は [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)を参照してください。\n\n## Ubuntu と `kubeadm`\n\n`kubeadm` でブートストラップされた Kubernetes は、以下の Linux ディストリビューションで動作することが確認されています。\n\n- Ubuntu 16.04\n- Fedora release 25\n\nHelm の一部のバージョン（v2.0.0-beta2）では、`export KUBECONFIG=/etc/kubernetes/admin.conf` を実行するか、`~/.kube/config` を作成する必要があります。\n\n## VMware Tanzu Kubernetes Grid\n\nHelm は 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) を参照してください。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: ライブラリ chart\ndescription: ライブラリ chart の概要と使用例を説明します\nsidebar_position: 4\n---\n\nライブラリ chart は、[Helm chart](/topics/charts.md) の一種で、他の chart の Helm テンプレートで共有できる chart プリミティブや定義を提供します。これにより、chart 間で再利用可能なコードスニペットを共有でき、繰り返しを避けて chart を [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) に保つことができます。\n\nライブラリ chart は Helm 3 で導入され、Helm 2 時代から chart メンテナーが使用してきた共通 chart やヘルパー chart を正式に認識するためのものです。chart タイプとして含めることで、以下のことが可能になります:\n\n- 共通 chart とアプリケーション chart を明確に区別する手段の提供\n- 共通 chart のインストールを防止するロジック\n- リリースアーティファクトを含む可能性のある共通 chart 内のテンプレートをレンダリングしない\n- 依存 chart がインポーター側のコンテキストを使用できるようにする\n\nchart メンテナーは、共通 chart をライブラリ chart として定義できるようになり、Helm が標準的で一貫した方法で chart を処理することを確信できます。また、chart タイプを変更するだけで、アプリケーション chart 内の定義を共有できるようになります。\n\n## シンプルなライブラリ chart の作成\n\n前述のとおり、ライブラリ chart は [Helm chart](/topics/charts.md) の一種です。つまり、スキャフォールド chart を作成することから始められます:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nこの例では独自のテンプレート定義を作成するため、まず `templates` ディレクトリ内のすべてのファイルを削除します。\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nvalues ファイルも不要です。\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\n共通コードの作成に入る前に、関連する Helm の概念を簡単に確認しておきましょう。[名前付きテンプレート](/chart_template_guide/named_templates.md)（パーシャルまたはサブテンプレートとも呼ばれます）は、ファイル内で定義され、名前が付けられたテンプレートです。`templates/` ディレクトリでは、アンダースコア（`_`）で始まるファイルは Kubernetes マニフェストファイルを出力しないことが期待されます。そのため、慣例としてヘルパーテンプレートやパーシャルは `_*.tpl` または `_*.yaml` ファイルに配置されます。\n\nこの例では、空の ConfigMap リソースを作成する共通 ConfigMap をコーディングします。共通 ConfigMap を `mylibchart/templates/_configmap.yaml` ファイルに以下のように定義します:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nConfigMap 構造体は名前付きテンプレート `mylibchart.configmap.tpl` で定義されています。これは空のリソース `data` を持つシンプルな ConfigMap です。このファイル内には `mylibchart.configmap` という別の名前付きテンプレートがあります。この名前付きテンプレートは `mylibchart.util.merge` という別の名前付きテンプレートをインクルードし、2 つの名前付きテンプレートを引数として受け取ります: `mylibchart.configmap` を呼び出すテンプレートと `mylibchart.configmap.tpl` です。\n\nヘルパー関数 `mylibchart.util.merge` は `mylibchart/templates/_util.yaml` にある名前付きテンプレートです。これは [The Common Helm Helper Chart](#the-common-helm-helper-chart) からの便利なユーティリティで、2 つのテンプレートをマージし、両方に共通する部分をオーバーライドします:\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nこれは、chart が自身の設定でカスタマイズする必要のある共通コードを使用したい場合に重要です。\n\n最後に、chart タイプを `library` に変更します。`mylibchart/Chart.yaml` を以下のように編集する必要があります:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\nライブラリ chart は共有の準備ができ、その ConfigMap 定義を再利用できるようになりました。\n\n先に進む前に、Helm がこの chart をライブラリ chart として認識しているかどうかを確認する価値があります:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## シンプルなライブラリ chart の使用\n\nライブラリ chart を使用する番です。これは再度スキャフォールド chart を作成することを意味します:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nConfigMap のみを作成したいので、テンプレートファイルを再度クリーンアップします:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nHelm テンプレートでシンプルな ConfigMap を作成する場合、以下のようになります:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nしかし、ここでは `mylibchart` で作成済みの共通コードを再利用します。ConfigMap は `mychart/templates/configmap.yaml` ファイルに以下のように作成できます:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nConfigMap の標準プロパティを追加する共通 ConfigMap 定義を継承することで、作業が簡略化されていることがわかります。テンプレートでは設定（この場合は data キー `myvalue` とその値）を追加しています。この設定は共通 ConfigMap の空のリソースをオーバーライドします。これは前のセクションで説明したヘルパー関数 `mylibchart.util.merge` によって実現されています。\n\n共通コードを使用するには、`mylibchart` を依存関係として追加する必要があります。`mychart/Chart.yaml` ファイルの末尾に以下を追加します:\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nこれにより、アプリケーション chart と同じ親パスにあるファイルシステムから、ライブラリ chart が動的依存関係としてインクルードされます。ライブラリ chart を動的依存関係としてインクルードしているため、`helm dependency update` を実行する必要があります。これにより、ライブラリ chart が `charts/` ディレクトリにコピーされます。\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nchart をデプロイする準備ができました。インストール前に、まずレンダリングされたテンプレートを確認する価値があります。\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nこれは `myvalue: Hello World` のデータオーバーライドを持つ、期待どおりの ConfigMap です。インストールしましょう:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nrelease を取得して、実際のテンプレートがロードされたことを確認できます。\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## ライブラリ chart の利点\n\nライブラリ chart はスタンドアロン chart として動作できないため、以下の機能を活用できます:\n\n- `.Files` オブジェクトは、ライブラリ chart のローカルパスではなく、親 chart のファイルパスを参照します\n- `.Values` オブジェクトは親 chart と同じです。これは、親の設定でヘッダー以下に設定された values セクションを受け取るアプリケーション [subchart](/chart_template_guide/subcharts_and_globals.md) とは対照的です\n\n\n## The Common Helm Helper Chart\n\n```markdown\nNote: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived.\n```\n\nこの [chart](https://github.com/helm/charts/tree/master/incubator/common) は、共通 chart の元となったパターンです。Kubernetes chart 開発のベストプラクティスを反映したユーティリティを提供します。最大の利点は、chart を開発する際にすぐに使用でき、便利な共有コードを利用できることです。\n\nここでは簡単な使用方法を示します。詳細については、[README](https://github.com/helm/charts/blob/master/incubator/common/README.md) を参照してください。\n\n再度スキャフォールド chart を作成します:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nヘルパー chart の共通コードを使用しましょう。まず、deployment の `demo/templates/deployment.yaml` を以下のように編集します:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\n次に、service ファイル `demo/templates/service.yaml` を以下のように編集します:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nこれらのテンプレートは、ヘルパー chart から共通コードを継承することで、コーディングがリソースの設定やカスタマイズに簡略化されることを示しています。\n\n共通コードを使用するには、`common` を依存関係として追加する必要があります。`demo/Chart.yaml` ファイルの末尾に以下を追加します:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\n注意: Helm リポジトリリストに `incubator` リポジトリを追加する必要があります（`helm repo add`）。\n\nchart を動的依存関係としてインクルードしているため、`helm dependency update` を実行する必要があります。これにより、ヘルパー chart が `charts/` ディレクトリにコピーされます。\n\nヘルパー chart は一部の Helm 2 構造を使用しているため、Helm 3 のスキャフォールド chart で更新された `nginx` イメージをロードできるように、`demo/values.yaml` に以下を追加する必要があります:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nデプロイ前に `helm lint` と `helm template` コマンドを使用して、chart テンプレートが正しいかテストできます。\n\n問題なければ、`helm install` でデプロイしてください！\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: SQL ストレージバックエンドの権限管理\ndescription: SQL ストレージバックエンドを使用する際の権限設定方法について説明します。\n---\n\nこのドキュメントでは、SQL ストレージバックエンドにおける権限の設定と管理について説明します。\n\n## はじめに\n\nHelm は権限管理に Kubernetes の RBAC 機能を利用しています。ただし、SQL ストレージバックエンドを使用する場合、Kubernetes の Role ではユーザーが特定のリソースにアクセスできるかどうかを判断できません。このドキュメントでは、これらの権限を作成・管理する方法を説明します。\n\n## 初期化\n\nHelm CLI が初めてデータベースに接続するとき、クライアントは初期化済みかどうかを確認します。未初期化の場合は、必要なセットアップを自動的に実行します。この初期化には、public スキーマに対する管理者権限、または少なくとも以下の権限が必要です:\n\n* テーブルの作成\n* public スキーマに対する権限の付与\n\nデータベースに対してマイグレーションを実行した後は、他のすべてのロールでクライアントを使用できます。\n\n## PostgreSQL で管理者以外のユーザーに権限を付与する\n\n権限管理のために、SQL バックエンドドライバは PostgreSQL の [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)（Row Level Security: 行レベルセキュリティ）機能を利用しています。RLS により、すべてのユーザーが同じテーブルに対して読み書きできますが、明示的に許可されていない行は操作できません。デフォルトでは、適切な権限が付与されていないロールは、`helm list` を実行しても空のリストが返され、クラスター内のリソースを取得・変更することはできません。\n\n以下に、特定のロールに特定の namespace へのアクセス権を付与する方法を示します:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nこのコマンドは、`namespace = 'default'` の条件を満たすすべてのリソースに対して、ロール `<role>` に読み取りおよび書き込み権限を付与します。このポリシーを作成すると、ロール `<role>` としてデータベースに接続しているユーザーは、`helm list` で `default` namespace 内のすべての release を確認でき、それらを変更・削除できるようになります。\n\nRLS では、テーブルのカラムに基づいて権限をより細かく管理することも可能です:\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Helm プラグインガイド\ndescription: Helm の機能を拡張するプラグインの使い方と作成方法を紹介します。\nsidebar_position: 12\n---\n\nHelm プラグインは、`helm` CLI からアクセスできるツールですが、Helm 本体のコードベースには含まれていません。\n\n既存のプラグインは、[関連プロジェクト](/community/related#helm-plugins)セクションや [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) で検索して見つけることができます。\n\nこのガイドでは、プラグインの使い方と作成方法を説明します。\n\n## 概要\n\nHelm プラグインは、Helm とシームレスに統合されるアドオンツールです。Helm のコア機能を拡張する手段を提供しますが、すべての新機能を Go で記述してコアツールに追加する必要はありません。\n\nHelm プラグインには以下の特徴があります:\n\n- コアの Helm ツールに影響を与えることなく、Helm インストールに追加・削除できます。\n- 任意のプログラミング言語で記述できます。\n- Helm と統合され、`helm help` やその他の場所に表示されます。\n\nHelm プラグインは `$HELM_PLUGINS` に配置されます。この値は、環境変数が設定されていない場合のデフォルト値を含めて、`helm env` コマンドで確認できます。\n\nHelm のプラグインモデルは、Git のプラグインモデルを部分的にベースにしています。そのため、`helm` を _porcelain_（磁器）層、プラグインを _plumbing_（配管）と呼ぶことがあります。これは、Helm がユーザー向けのインターフェースと全体的な処理ロジックを提供し、プラグインが目的のアクションを実行する「詳細な作業」を担当することを端的に表しています。\n\n## プラグインのインストール\n\nプラグインは `$ helm plugin install <path|url>` コマンドでインストールします。ローカルファイルシステム上のプラグインへのパスか、リモート VCS リポジトリの URL を指定できます。`helm plugin install` コマンドは、指定されたパス/URL のプラグインを `$HELM_PLUGINS` にクローンまたはコピーします。VCS からインストールする場合は、`--version` 引数でバージョンを指定できます。\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nプラグインの tar 配布物がある場合は、`$HELM_PLUGINS` ディレクトリに解凍するだけです。`helm plugin install https://domain/path/to/plugin.tar.gz` を実行すると、URL から tarball プラグインを直接インストールすることもできます。\n\n## プラグインのファイル構造\n\n多くの点で、プラグインは chart に似ています。各プラグインには、`plugin.yaml` ファイルを含むトップレベルディレクトリがあります。その他のファイルも存在できますが、必須なのは `plugin.yaml` ファイルのみです。\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## plugin.yaml ファイル\n\nplugin.yaml ファイルはプラグインに必須です。以下のフィールドが含まれます:\n\n```yaml\nname: The name of the plugin (REQUIRED)\nversion: A SemVer 2 version (REQUIRED)\nusage: Single line usage text shown in help\ndescription: Long description shown in places like helm help\nignoreFlags: Ignore flags passed in from Helm\nplatformCommand: # Configure command to run based on the platform\n  - os: OS match, can be empty or omitted to match all OS'\n    arch: Architecture match, can be empty or omitted to match all architectures\n    command: Plugin command to execute\n    args: Plugin command arguments\ncommand: (DEPRECATED) Plugin command, use platformCommand instead\nplatformHooks: # Configure plugin lifecycle hooks based on the platform\n  install: # Install lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin install command to execute\n      args: Plugin install command arguments\n  update: # Update lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin update command to execute\n      args: Plugin update command arguments\n  delete: # Delete lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin delete command to execute\n      args: Plugin delete command arguments\nhooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead\n  install: Command to install plugin\n  update: Command to update plugin\n  delete: Command to delete plugin\ndownloaders: # Configure downloaders capability\n  - command: Command to invoke\n    protocols:\n      - Protocol schema supported\n```\n\n### `name` フィールド\n\n`name` はプラグインの名前です。Helm がこのプラグインを実行するとき、この名前が使用されます（例: `helm NAME` でこのプラグインが呼び出されます）。\n\n_`name` はディレクトリ名と一致する必要があります。_ 上記の例では、`name: last` を持つプラグインは `last` という名前のディレクトリに格納する必要があります。\n\n`name` の制約:\n\n- `name` は既存の `helm` トップレベルコマンドと重複できません。\n- `name` は ASCII 文字 a-z、A-Z、0-9、`_`、`-` に制限されます。\n\n### `version` フィールド\n\n`version` はプラグインの SemVer 2 バージョンです。`usage` と `description` は両方ともコマンドのヘルプテキスト生成に使用されます。\n\n### `ignoreFlags` フィールド\n\n`ignoreFlags` スイッチは、Helm にフラグをプラグインに渡さ _ない_ よう指示します。プラグインが `helm myplugin --foo` で呼び出され、`ignoreFlags: true` の場合、`--foo` は静かに破棄されます。\n\n### `platformCommand` フィールド\n\n`platformCommand` は、プラグインが呼び出されたときに実行するコマンドを設定します。`platformCommand` と `command` の両方を設定するとエラーになります。使用するコマンドを決定する際には、以下のルールが適用されます:\n\n- `platformCommand` が存在する場合、それが使用されます。\n  - `os` と `arch` の両方が現在のプラットフォームに一致する場合、検索は停止し、そのコマンドが使用されます。\n  - `os` が一致し、`arch` が空の場合、そのコマンドが使用されます。\n  - `os` と `arch` の両方が空の場合、そのコマンドが使用されます。\n  - 一致するものがない場合、Helm はエラーで終了します。\n- `platformCommand` が存在せず、非推奨の `command` が存在する場合、それが使用されます。\n  - コマンドが空の場合、Helm はエラーで終了します。\n\n### `platformHooks` フィールド\n\n`platformHooks` は、ライフサイクルイベントに対してプラグインが実行するコマンドを設定します。`platformHooks` と `hooks` の両方を設定するとエラーになります。使用するフックコマンドを決定する際には、以下のルールが適用されます:\n\n- `platformHooks` が存在する場合、それが使用され、ライフサイクルイベントのコマンドが処理されます。\n  - `os` と `arch` の両方が現在のプラットフォームに一致する場合、検索は停止し、そのコマンドが使用されます。\n  - `os` が一致し、`arch` が空の場合、そのコマンドが使用されます。\n  - `os` と `arch` の両方が空の場合、そのコマンドが使用されます。\n  - 一致するものがない場合、Helm はそのイベントをスキップします。\n- `platformHooks` が存在せず、非推奨の `hooks` が存在する場合、ライフサイクルイベントのコマンドが使用されます。\n  - コマンドが空の場合、Helm はそのイベントをスキップします。\n\n## プラグインのビルド\n\n最後の release 名を取得するシンプルなプラグインの plugin YAML を以下に示します:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nプラグインには追加のスクリプトや実行可能ファイルが必要な場合があります。\nスクリプトはプラグインディレクトリに含めることができ、実行可能ファイルはフックを介してダウンロードできます。以下はプラグインの例です:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\n環境変数はプラグインの実行前に展開されます。上記のパターンは、プラグインの実行ファイルの場所を指定する推奨パターンです。\n\n### プラグインコマンド\n\nプラグインコマンドを扱うためのいくつかの戦略があります:\n\n- プラグインに実行可能ファイルが含まれる場合、`platformCommand:` 用の実行可能ファイルはプラグインディレクトリにパッケージ化するか、フックを介してインストールする必要があります。\n- `platformCommand:` または `command:` 行は、実行前に環境変数が展開されます。`$HELM_PLUGIN_DIR` はプラグインディレクトリを指します。\n- コマンド自体はシェルで実行されません。したがって、シェルスクリプトを 1 行で記述することはできません。\n- Helm は多くの設定を環境変数に注入します。利用可能な情報については環境を確認してください。\n- Helm はプラグインの言語について何も仮定しません。好みの言語で記述できます。\n- コマンドは `-h` と `--help` 用の特定のヘルプテキストを実装する責任があります。Helm は `helm help` と `helm help myplugin` に対して `usage` と `description` を使用しますが、`helm myplugin --help` は処理しません。\n\n### ローカルプラグインのテスト\n\nまず、`HELM_PLUGINS` パスを見つける必要があります。以下のコマンドを実行してください:\n\n``` bash\nhelm env\n```\n\nカレントディレクトリを `HELM_PLUGINS` が設定されているディレクトリに変更します。\n\nこれで、プラグインのビルド出力へのシンボリックリンクを追加できます。この例では `mapkubeapis` の場合を示しています。\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## ダウンローダープラグイン\n\nデフォルトでは、Helm は HTTP/S を使用して chart を取得できます。Helm 2.4.0 以降、プラグインは任意のソースから chart をダウンロードする特別な機能を持つことができます。\n\nプラグインは、この特別な機能を `plugin.yaml` ファイル（トップレベル）で宣言します:\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nこのようなプラグインがインストールされている場合、Helm は指定されたプロトコルスキームを使用して `command` を呼び出し、リポジトリとやり取りできます。特別なリポジトリは、通常のリポジトリと同様に追加します: `helm repo add favorite myprotocol://example.com/`。特別なリポジトリのルールは通常のリポジトリと同じです: Helm は利用可能な chart のリストを検出してキャッシュするために `index.yaml` ファイルをダウンロードできる必要があります。\n\n定義されたコマンドは次のスキームで呼び出されます: `command certFile keyFile caFile full-URL`。SSL 認証情報は、`$HELM_REPOSITORY_CONFIG`（つまり、`$HELM_CONFIG_HOME/repositories.yaml`）に保存されているリポジトリ定義から取得されます。ダウンローダープラグインは、生のコンテンツを標準出力にダンプし、エラーを標準エラー出力に報告することが期待されます。\n\nダウンローダーコマンドはサブコマンドや引数もサポートしており、`plugin.yaml` で `bin/mydownloader subcommand -d` のように指定できます。これは、メインプラグインコマンドとダウンローダーコマンドで同じ実行可能ファイルを使用したいが、それぞれに異なるサブコマンドを使用したい場合に便利です。\n\n## 環境変数\n\nHelm がプラグインを実行するとき、外部環境をプラグインに渡し、さらにいくつかの追加環境変数を注入します。\n\n`KUBECONFIG` などの変数は、外部環境で設定されている場合、プラグインに設定されます。\n\n以下の変数は常に設定されることが保証されています:\n\n- `HELM_PLUGINS`: プラグインディレクトリへのパス。\n- `HELM_PLUGIN_NAME`: `helm` によって呼び出されたプラグインの名前。`helm myplug` の場合、短縮名は `myplug` になります。\n- `HELM_PLUGIN_DIR`: プラグインが格納されているディレクトリ。\n- `HELM_BIN`: `helm` コマンドへのパス（ユーザーが実行したもの）。\n- `HELM_DEBUG`: helm でデバッグフラグが設定されているかどうかを示します。\n- `HELM_REGISTRY_CONFIG`: レジストリ設定の場所（使用している場合）。Helm でのレジストリの使用は実験的な機能です。\n- `HELM_REPOSITORY_CACHE`: リポジトリキャッシュファイルへのパス。\n- `HELM_REPOSITORY_CONFIG`: リポジトリ設定ファイルへのパス。\n- `HELM_NAMESPACE`: `helm` コマンドに指定された namespace（通常は `-n` フラグを使用）。\n- `HELM_KUBECONTEXT`: `helm` コマンドに指定された Kubernetes 設定コンテキストの名前。\n\nさらに、Kubernetes 設定ファイルが明示的に指定されている場合、`KUBECONFIG` 変数として設定されます。\n\n## フラグ解析に関する注意\n\nプラグインを実行するとき、Helm は自身が使用するためにグローバルフラグを解析します。これらのフラグはプラグインに渡されません。\n- `--burst-limit`: `$HELM_BURST_LIMIT` に変換されます\n- `--debug`: これが指定されると、`$HELM_DEBUG` が `1` に設定されます\n- `--kube-apiserver`: `$HELM_KUBEAPISERVER` に変換されます\n- `--kube-as-group`: `$HELM_KUBEASGROUPS` に変換されます\n- `--kube-as-user`: `$HELM_KUBEASUSER` に変換されます\n- `--kube-ca-file`: `$HELM_KUBECAFILE` に変換されます\n- `--kube-context`: `$HELM_KUBECONTEXT` に変換されます\n- `--kube-insecure-skip-tls-verify`: `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` に変換されます\n- `--kube-tls-server-name`: `$HELM_KUBETLS_SERVER_NAME` に変換されます\n- `--kube-token`: `$HELM_KUBETOKEN` に変換されます\n- `--kubeconfig`: `$KUBECONFIG` に変換されます\n- `--namespace` と `-n`: `$HELM_NAMESPACE` に変換されます\n- `--qps`: `$HELM_QPS` に変換されます\n- `--registry-config`: `$HELM_REGISTRY_CONFIG` に変換されます\n- `--repository-cache`: `$HELM_REPOSITORY_CACHE` に変換されます\n- `--repository-config`: `$HELM_REPOSITORY_CONFIG` に変換されます\n\nプラグインは `-h` と `--help` に対してヘルプテキストを表示して終了 _すべきです_。その他のすべての場合、プラグインは適切にフラグを使用できます。\n\n## シェル自動補完の提供\n\nHelm 3.2 以降、プラグインは Helm の既存の自動補完メカニズムの一部として、オプションでシェル自動補完をサポートできます。\n\n### 静的自動補完\n\nプラグインが独自のフラグやサブコマンドを提供する場合、プラグインのルートディレクトリに `completion.yaml` ファイルを配置することで、Helm に通知できます。`completion.yaml` ファイルの形式は以下のとおりです:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\n注意事項:\n\n1. すべてのセクションはオプションですが、該当する場合は記述してください。\n1. フラグには `-` または `--` プレフィックスを含めないでください。\n1. 短いフラグと長いフラグの両方を指定できます（また、指定すべきです）。短いフラグは対応する長い形式に関連付ける必要はありませんが、両方の形式をリストする必要があります。\n1. フラグは特定の順序で並べる必要はありませんが、ファイルのサブコマンド階層の正しい位置にリストする必要があります。\n1. Helm の既存のグローバルフラグは Helm の自動補完メカニズムですでに処理されているため、プラグインは `--debug`、`--namespace` または `-n`、`--kube-context`、`--kubeconfig`、およびその他のグローバルフラグを指定する必要はありません。\n1. `validArgs` リストは、サブコマンドの後に続く最初のパラメータに対して可能な補完の静的リストを提供します。このようなリストを事前に提供できない場合もあります（以下の[動的補完](#動的補完)セクションを参照）。その場合、`validArgs` セクションは省略できます。\n\n`completion.yaml` ファイルは完全にオプションです。提供されていない場合、Helm はプラグインに対してシェル自動補完を提供しません（プラグインが[動的補完](#動的補完)をサポートしている場合を除く）。また、`completion.yaml` ファイルを追加しても後方互換性があり、古いバージョンの Helm を使用している場合でもプラグインの動作に影響しません。\n\n例として、[`fullstatus` プラグイン](https://github.com/marckhouzam/helm-fullstatus)はサブコマンドを持ちませんが、`helm status` コマンドと同じフラグを受け入れます。その `completion.yaml` ファイルは以下のとおりです:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nより複雑な例として、[`2to3` プラグイン](https://github.com/helm/helm-2to3)の `completion.yaml` ファイルは以下のとおりです:\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### 動的補完\n\nHelm 3.2 以降、プラグインは独自の動的シェル自動補完を提供できます。動的シェル自動補完は、事前に定義できないパラメータ値やフラグ値の補完です。たとえば、クラスター上で現在利用可能な Helm release 名の補完などです。\n\nプラグインが動的自動補完をサポートするには、ルートディレクトリに `plugin.complete` という**実行可能**ファイルを提供する必要があります。Helm の補完スクリプトがプラグインに対して動的補完を必要とする場合、`plugin.complete` ファイルを実行し、補完が必要なコマンドラインを渡します。`plugin.complete` 実行可能ファイルは、適切な補完候補を決定し、Helm の補完スクリプトが使用するために標準出力に出力するロジックを持つ必要があります。\n\n`plugin.complete` ファイルは完全にオプションです。提供されていない場合、Helm はプラグインに対して動的自動補完を提供しません。また、`plugin.complete` ファイルを追加しても後方互換性があり、古いバージョンの Helm を使用している場合でもプラグインの動作に影響しません。\n\n`plugin.complete` スクリプトの出力は、以下のような改行区切りのリストである必要があります:\n\n```console\nrel1\nrel2\nrel3\n```\n\n`plugin.complete` が呼び出されると、プラグインのメインスクリプトが呼び出されるときと同様にプラグイン環境が設定されます。したがって、`$HELM_NAMESPACE`、`$HELM_KUBECONTEXT`、およびその他すべてのプラグイン変数はすでに設定されており、対応するグローバルフラグは削除されています。\n\n`plugin.complete` ファイルは任意の実行可能形式にできます。シェルスクリプト、Go プログラム、または Helm が実行できるその他の種類のプログラムにできます。`plugin.complete` ファイルは、ユーザーに対する実行権限を持って ***いなければなりません***。`plugin.complete` ファイルは成功コード（値 0）で終了 ***しなければなりません***。\n\n場合によっては、動的補完で Kubernetes クラスターから情報を取得する必要があります。たとえば、`helm fullstatus` プラグインは入力として release 名を必要とします。`fullstatus` プラグインでは、`plugin.complete` スクリプトが現在の release 名の補完を提供するために、単純に `helm list -q` を実行して結果を出力できます。\n\nプラグインの実行とプラグインの補完に同じ実行可能ファイルを使用したい場合、`plugin.complete` スクリプトは特別なパラメータやフラグを付けてメインプラグイン実行可能ファイルを呼び出すことができます。メインプラグイン実行可能ファイルが特別なパラメータやフラグを検出すると、補完を実行することがわかります。この例では、`plugin.complete` を以下のように実装できます:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\n`fullstatus` プラグインの実際のスクリプト（`status.sh`）は `--complete` フラグを探し、見つかった場合は適切な補完を出力する必要があります。\n\n### ヒントとコツ\n\n1. シェルはユーザー入力に一致しない補完候補を自動的にフィルタリングします。したがって、プラグインはユーザー入力に一致しないものを削除せずに、関連するすべての補完を返すことができます。たとえば、コマンドラインが `helm fullstatus ngin<TAB>` の場合、`plugin.complete` スクリプトは（`default` namespace の）*すべての* release 名を出力できます。`ngin` で始まるものだけではありません。シェルは `ngin` で始まるものだけを残します。\n1. 動的補完サポートを簡素化するために、特に複雑なプラグインの場合、`plugin.complete` スクリプトでメインプラグインスクリプトを呼び出して補完候補を要求できます。上記の[動的補完](#動的補完)セクションの例を参照してください。\n1. 動的補完と `plugin.complete` ファイルをデバッグするには、以下を実行して補完結果を確認できます:\n    - `helm __complete <pluginName> <arguments to complete>`。例:\n    - `helm __complete fullstatus --output js<ENTER>`\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: Helm の来歴と完全性\ndescription: chart の完全性と出所を検証する方法について説明します。\nsidebar_position: 5\n---\n\nHelm は、chart ユーザーがパッケージの完全性と出所を検証するための来歴検証ツールを備えています。PKI、GnuPG、および定評のあるパッケージマネージャーに基づいた業界標準のツールを使用して、署名ファイルの生成と検証を行えます。\n\n## 概要\n\n完全性は、chart と来歴レコードを比較することで確立されます。来歴レコードは、パッケージ化された chart と一緒に保存される _来歴ファイル_ に保存されます。たとえば、chart の名前が `myapp-1.2.3.tgz` の場合、その来歴ファイルは `myapp-1.2.3.tgz.prov` になります。\n\n来歴ファイルはパッケージング時に生成され（`helm package --sign ...`）、複数のコマンド（特に `helm install --verify`）で検証できます。\n\n## ワークフロー\n\nこのセクションでは、来歴データを効果的に使用するための一般的なワークフローについて説明します。\n\n前提条件:\n\n- バイナリ形式（ASCII-armored 形式ではない）の有効な PGP 鍵ペア\n- `helm` コマンドラインツール\n- GnuPG コマンドラインツール（オプション）\n- Keybase コマンドラインツール（オプション）\n\n**注意:** PGP 秘密鍵にパスフレーズが設定されている場合、`--sign` オプションをサポートするコマンドを実行するときにパスフレーズの入力を求められます。\n\n新しい chart の作成方法は従来と同じです:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nパッケージ化の準備ができたら、`helm package` に `--sign` フラグを追加します。また、署名鍵の名前と、対応する秘密鍵を含むキーリングを指定します:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**注意:** `--key` 引数の値は、目的の鍵の `uid`（`gpg --list-keys` の出力に表示される）の部分文字列である必要があります。たとえば、名前やメールアドレスです。**フィンガープリントは使用できません。**\n\n**TIP:** GnuPG ユーザーの場合、秘密キーリングは `~/.gnupg/secring.gpg` にあります。`gpg --list-secret-keys` を使用して、利用可能な鍵の一覧を表示できます。\n\n**警告:** GnuPG v2 では、秘密キーリングがデフォルトの場所 `~/.gnupg/pubring.kbx` に新しい `kbx` 形式で保存されます。次のコマンドを使用して、キーリングを従来の gpg 形式に変換してください:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nこの時点で、`mychart-0.1.0.tgz` と `mychart-0.1.0.tgz.prov` の両方のファイルが作成されているはずです。両方のファイルを最終的に目的の chart リポジトリにアップロードします。\n\n`helm verify` を使用して chart を検証できます:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\n検証に失敗すると、次のようになります:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nインストール時に検証するには、`--verify` フラグを使用します。\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\n署名済み chart に関連付けられた公開鍵を含むキーリングがデフォルトの場所にない場合は、`helm package` の例と同様に `--keyring PATH` でキーリングを指定する必要があります。\n\n検証に失敗すると、chart がレンダリングされる前にインストールが中止されます。\n\n### Keybase.io 認証情報の使用\n\n[Keybase.io](https://keybase.io) サービスを使用すると、暗号化 ID の信頼チェーンを簡単に確立できます。Keybase の認証情報を使用して chart に署名できます。\n\n前提条件:\n\n- 設定済みの Keybase.io アカウント\n- ローカルにインストールされた GnuPG\n- ローカルにインストールされた `keybase` CLI\n\n#### パッケージへの署名\n\n最初のステップは、Keybase の鍵をローカルの GnuPG キーリングにインポートすることです:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nこのコマンドは、Keybase の鍵を OpenPGP 形式に変換し、ローカルの `~/.gnupg/secring.gpg` ファイルにインポートします。\n\n`gpg --list-secret-keys` を実行して確認できます。\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\n秘密鍵には次のような識別子文字列があります:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nこれが鍵のフルネームです。\n\n次に、`helm package` を使用して chart をパッケージ化し、署名できます。`--key` には、この名前文字列の少なくとも一部を使用してください。\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nその結果、`package` コマンドは `.tgz` ファイルと `.tgz.prov` ファイルの両方を生成します。\n\n#### パッケージの検証\n\n同様の手順で、他のユーザーの Keybase 鍵で署名された chart を検証することもできます。たとえば、`keybase.io/technosophos` によって署名されたパッケージを検証する場合は、`keybase` ツールを使用します:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\n上記の最初のコマンドは、ユーザー `technosophos` をフォローします。次に `keybase pgp pull` を実行すると、フォローしているすべてのアカウントの OpenPGP 鍵がダウンロードされ、GnuPG キーリング（`~/.gnupg/pubring.gpg`）に配置されます。\n\nこの時点で、`helm verify` または `--verify` フラグを持つコマンドを使用できるようになります:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### chart が検証できない理由\n\n検証が失敗する一般的な理由を以下に示します。\n\n- `.prov` ファイルが見つからないか、破損しています。これは、何かが正しく設定されていないか、元のメンテナが来歴ファイルを作成しなかったことを示します。\n- ファイルの署名に使用された鍵がキーリングにありません。これは、chart に署名したエンティティが、信頼すると表明した相手ではないことを示します。\n- `.prov` ファイルの検証に失敗しました。これは、chart または来歴データに問題があることを示します。\n- 来歴ファイル内のファイルハッシュがアーカイブファイルのハッシュと一致しません。これは、アーカイブが改ざんされたことを示します。\n\n検証に失敗した場合は、そのパッケージを信頼しない理由があります。\n\n## 来歴ファイル\n\n来歴ファイルには、chart の YAML ファイルといくつかの検証情報が含まれています。来歴ファイルは自動的に生成されるように設計されています。\n\n以下の来歴データが追加されます:\n\n* chart ファイル（`Chart.yaml`）が含まれており、人間とツールの両方が chart の内容を簡単に確認できます。\n* chart パッケージ（`.tgz` ファイル）の署名（Docker と同様の SHA256）が含まれており、chart パッケージの完全性を検証するために使用できます。\n* 本文全体が OpenPGP で使用されるアルゴリズムで署名されています（暗号署名と検証を簡単にする新しい方法については [Keybase.io](https://keybase.io) を参照してください）。\n\nこれらの組み合わせにより、ユーザーは以下のことを保証されます:\n\n* パッケージ自体が改ざんされていないこと（パッケージ `.tgz` のチェックサム）。\n* このパッケージをリリースしたエンティティが既知であること（GnuPG/PGP 署名による）。\n\nファイルの形式は次のようになります:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nYAML セクションには 2 つのドキュメントが含まれています（`...\\n` で区切られています）。最初のファイルは `Chart.yaml` の内容です。2 番目はチェックサムで、パッケージング時のファイル名とそのファイル内容の SHA-256 ダイジェストのマップです。\n\n署名ブロックは標準の PGP 署名であり、[改ざん耐性](https://www.rossde.com/PGP/pgp_signatures.html)を提供します。\n\n## Chart リポジトリ\n\nChart リポジトリは、Helm chart の集約された集合として機能します。\n\nChart リポジトリは、特定のリクエストを介して HTTP 経由で来歴ファイルを提供できる必要があり、chart と同じ URI パスで利用可能にする必要があります。\n\nたとえば、パッケージのベース URL が `https://example.com/charts/mychart-1.2.3.tgz` の場合、来歴ファイルが存在する場合は `https://example.com/charts/mychart-1.2.3.tgz.prov` でアクセスできる必要があります。\n\nエンドユーザーの観点から、`helm install --verify myrepo/mychart-1.2.3` を実行すると、追加のユーザー設定やアクションなしに chart と来歴ファイルの両方がダウンロードされます。\n\n### OCI ベースのレジストリでの署名\n\nchart を [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` コマンドを使用して来歴を不変の透明性ログに公開できます。\n\n## 権威と真正性の確立\n\n信頼チェーンシステムを扱う場合、署名者の権威を確立できることが重要です。言い換えれば、上記のシステムは、chart に署名した人を信頼するという事実に基づいています。つまり、署名者の公開鍵を信頼する必要があります。\n\nHelm の設計上の決定の 1 つとして、Helm プロジェクトは信頼チェーンに必須の当事者として介入しないことにしました。すべての chart 署名者の「認証局」にはなりたくありません。代わりに、分散型モデルを強く支持しており、これが OpenPGP を基盤技術として選択した理由の一部です。そのため、権威の確立に関しては、Helm 2 ではこのステップをほぼ未定義のままにしています（この決定は Helm 3 にも引き継がれています）。\n\nただし、来歴システムの使用に興味がある方のために、いくつかのヒントと推奨事項を示します:\n\n- [Keybase](https://keybase.io) プラットフォームは、信頼情報の公開集中リポジトリを提供します。\n  - Keybase を使用して鍵を保存したり、他のユーザーの公開鍵を取得したりできます。\n  - Keybase には充実したドキュメントも用意されています。\n  - 検証していませんが、Keybase の「セキュアウェブサイト」機能を使用して Helm chart を配布できる可能性があります。\n  - 基本的な考え方は、公式の「chart レビュアー」が自分の鍵で chart に署名し、その来歴ファイルを chart リポジトリにアップロードするというものです。\n  - リポジトリの `index.yaml` ファイルに有効な署名鍵のリストを含めるというアイデアについて、検討が進められています。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: ロールベースアクセス制御\ndescription: Helm と Kubernetes のロールベースアクセス制御（RBAC）との連携について説明します。\nsidebar_position: 11\n---\n\nKubernetes では、ユーザーやアプリケーション固有のサービスアカウントにロールを付与することが推奨されます。これにより、アプリケーションを意図した範囲内で動作させることができます。サービスアカウントの権限については、[Kubernetes 公式ドキュメント](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions)を参照してください。\n\nKubernetes 1.6 以降、ロールベースアクセス制御（RBAC）はデフォルトで有効になっています。RBAC を使用すると、ユーザーとその組織内でのロールに応じて、許可されるアクションの種類を指定できます。\n\nRBAC を使用すると、以下のことが可能です:\n\n- 管理者に特権操作（クラスター全体のリソース作成、新しいロールの作成など）を付与する\n- ユーザーがリソース（Pod、PersistentVolume、Deployment など）を作成できる範囲を、特定の namespace またはクラスター全体のスコープ（ResourceQuota、Role、CustomResourceDefinition）に制限する\n- ユーザーがリソースを参照できる範囲を、特定の namespace またはクラスター全体のスコープに制限する\n\nこのガイドは、ユーザーと Kubernetes API のやり取りの範囲を制限したい管理者向けです。\n\n## ユーザーアカウントの管理\n\nすべての Kubernetes クラスターには、2 種類のユーザーカテゴリがあります: Kubernetes が管理するサービスアカウントと、通常のユーザーです。\n\n通常のユーザーは、外部の独立したサービスによって管理されることが想定されています。たとえば、秘密鍵を配布する管理者、Keystone や Google アカウントなどのユーザーストア、ユーザー名とパスワードを記載したファイルなどが該当します。そのため、Kubernetes には通常のユーザーアカウントを表すオブジェクトがありません。通常のユーザーは API 呼び出しでクラスターに追加することができません。\n\n一方、サービスアカウントは Kubernetes API によって管理されるユーザーです。サービスアカウントは特定の namespace にバインドされ、API サーバーによって自動的に作成されるか、API 呼び出しによって手動で作成されます。サービスアカウントは、Secret として保存された認証情報のセットに紐付けられています。この Secret は Pod にマウントされ、クラスター内のプロセスが Kubernetes API と通信できるようにします。\n\nAPI リクエストは、通常のユーザーまたはサービスアカウントに紐付けられるか、匿名リクエストとして扱われます。つまり、ワークステーションで `kubectl` を入力する人間のユーザーから、ノード上の kubelet、コントロールプレーンのメンバーに至るまで、クラスター内外のすべてのプロセスは、API サーバーへのリクエスト時に認証を行う必要があります。認証しない場合は匿名ユーザーとして扱われます。\n\n## Role、ClusterRole、RoleBinding、ClusterRoleBinding\n\nKubernetes では、ユーザーアカウントとサービスアカウントは、アクセスを付与されたリソースのみを参照および編集できます。このアクセスは、Role と RoleBinding を使用して付与されます。Role と RoleBinding は特定の namespace にバインドされ、その Role がアクセス権を提供する namespace 内のリソースを参照または編集する機能をユーザーに付与します。\n\nクラスタースコープでは、これらは ClusterRole と ClusterRoleBinding と呼ばれます。ユーザーに ClusterRole を付与すると、クラスター全体のリソースを参照または編集するアクセス権が付与されます。また、クラスタースコープのリソース（namespace、ResourceQuota、Node）を参照または編集するためにも必要です。\n\nClusterRole は、RoleBinding 内で参照することで、特定の namespace にバインドできます。デフォルトの ClusterRole である `admin`、`edit`、`view` は、一般的にこの方法で使用されます。\n\nKubernetes にはデフォルトで利用可能な ClusterRole がいくつかあります。これらはユーザー向けのロールとして設計されています。スーパーユーザーロール（`cluster-admin`）や、より細かいアクセス権を持つロール（`admin`、`edit`、`view`）が含まれます。\n\n| デフォルト ClusterRole | デフォルト ClusterRoleBinding | 説明\n|---------------------|----------------------------|-------------\n| `cluster-admin`     | `system:masters` グループ     | すべてのリソースに対してすべてのアクションを実行できるスーパーユーザーアクセスを許可します。ClusterRoleBinding で使用すると、クラスター内およびすべての namespace 内のすべてのリソースを完全に制御できます。RoleBinding で使用すると、その namespace 内のすべてのリソース（namespace 自体を含む）を完全に制御できます。\n| `admin`             | なし                       | 管理者アクセスを許可します。RoleBinding を使用して namespace 内で付与することを想定しています。RoleBinding で使用すると、namespace 内のほとんどのリソースへの読み取り/書き込みアクセス（Role と RoleBinding の作成機能を含む）が許可されます。ResourceQuota や namespace 自体への書き込みアクセスは許可されません。\n| `edit`              | なし                       | namespace 内のほとんどのオブジェクトへの読み取り/書き込みアクセスを許可します。Role や RoleBinding の参照や変更は許可されません。\n| `view`              | なし                       | namespace 内のほとんどのオブジェクトへの読み取り専用アクセスを許可します。Role や RoleBinding の参照は許可されません。Secret の参照も許可されません（権限昇格につながるため）。\n\n## RBAC を使用したユーザーアカウントのアクセス制限\n\nロールベースアクセス制御の基本を理解したところで、管理者がユーザーのアクセス範囲を制限する方法について説明します。\n\n### 例: 特定の namespace への読み取り/書き込みアクセスを付与する\n\nユーザーのアクセスを特定の namespace に制限するには、`edit` または `admin` ロールを使用します。chart が Role や RoleBinding を作成または操作する場合は、`admin` ClusterRole を使用してください。\n\nまた、`cluster-admin` アクセス権を持つ RoleBinding を作成することもできます。namespace スコープで `cluster-admin` アクセスをユーザーに付与すると、namespace 自体を含む namespace 内のすべてのリソースを完全に制御できます。\n\nこの例では、`edit` Role を持つユーザーを作成します。まず、namespace を作成します:\n\n```console\n$ kubectl create namespace foo\n```\n\n次に、その namespace で RoleBinding を作成し、ユーザーに `edit` ロールを付与します。\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### 例: クラスタースコープでの読み取り/書き込みアクセスを付与する\n\nユーザーがクラスタースコープのリソース（namespace、Role、CustomResourceDefinition など）をインストールする chart をインストールしたい場合、クラスタースコープの書き込みアクセスが必要になります。\n\nこれを行うには、ユーザーに `admin` または `cluster-admin` アクセスを付与します。\n\nユーザーに `cluster-admin` アクセスを付与すると、`kubectl drain` を使用したノードアクセスやその他の管理タスクを含む、Kubernetes で利用可能なすべてのリソースへのアクセスが付与されます。代わりにユーザーに `admin` アクセスを提供するか、ニーズに合わせたカスタム ClusterRole を作成することを強く推奨します。\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### 例: 特定の namespace への読み取り専用アクセスを付与する\n\nSecret を参照するための ClusterRole はデフォルトでは用意されていません。`view` ClusterRole は、権限昇格の懸念から、ユーザーに Secret への読み取りアクセスを付与しません。Helm はデフォルトで release のメタデータを Secret として保存します。\n\nユーザーが `helm list` を実行するには、これらの Secret を読み取る必要があります。そのために、`secret-reader` という ClusterRole を作成します。\n\n`cluster-role-secret-reader.yaml` ファイルを作成し、以下の内容を記述します:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\n次に、以下のコマンドで ClusterRole を作成します:\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nこれで、ユーザーにほとんどのリソースへの読み取りアクセスを付与し、さらに Secret への読み取りアクセスを付与できます:\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### 例: クラスタースコープでの読み取り専用アクセスを付与する\n\n特定のシナリオでは、ユーザーにクラスタースコープのアクセスを付与することが有益な場合があります。たとえば、ユーザーが `helm list --all-namespaces` コマンドを実行したい場合、API はユーザーにクラスタースコープの読み取りアクセスを要求します。\n\nこれを行うには、上記で説明したように、ユーザーに `view` と `secret-reader` の両方のアクセスを付与しますが、ClusterRoleBinding を使用します。\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## 補足\n\n上記の例では、Kubernetes に付属するデフォルトの ClusterRole を使用しています。ユーザーがアクセスできるリソースをより細かく制御するには、[Kubernetes のドキュメント](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)を参照して、独自のカスタム Role や ClusterRole を作成してください。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: OCI ベースのレジストリの使用\ndescription: OCI を使用した chart の配布方法について説明します。\nsidebar_position: 7\n---\n\nHelm 3 以降、[OCI](https://www.opencontainers.org/) をサポートするコンテナレジストリを使用して chart パッケージを保存・共有できます。Helm v3.8.0 以降、OCI サポートはデフォルトで有効になっています。\n\n\n## v3.8.0 より前の OCI サポート\n\nOCI サポートは Helm v3.8.0 で実験的機能から一般提供（GA）に昇格しました。それ以前のバージョンでは OCI サポートの動作が異なります。v3.8.0 より前に OCI サポートを使用していた場合は、各バージョンの変更点を確認してください。\n\n### v3.8.0 より前の OCI サポートの有効化\n\nHelm v3.8.0 より前では、OCI サポートは*実験的*機能であり、明示的に有効化する必要があります。\n\nv3.8.0 より前のバージョンで OCI サポートを有効にするには、環境変数 `HELM_EXPERIMENTAL_OCI` を設定します。例:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### v3.8.0 での OCI 機能の廃止と動作変更\n\n[Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) のリリースで、以下の機能と動作が以前のバージョンと異なっています:\n\n- 依存関係で chart を OCI として設定する場合、他の依存関係と同様にバージョンを範囲指定できます。\n- ビルド情報を含むセマンティックバージョンタグをプッシュして使用できます。OCI レジストリはタグ文字として `+` をサポートしていません。Helm はタグとして保存する際に `+` を `_` に変換します。\n- `helm registry login` コマンドは、認証情報の保存において Docker CLI と同じ構造に従うようになりました。レジストリ設定の同じ場所を Helm と Docker CLI の両方に渡すことができます。\n\n### v3.7.0 での OCI 機能の廃止と動作変更\n\n[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) の実装が含まれていました。その結果、以下の機能と動作が以前のバージョンと異なっています:\n\n- `helm chart` サブコマンドは削除されました。\n- chart キャッシュは削除されました（`helm chart list` などはありません）。\n- OCI レジストリ参照には常に `oci://` プレフィックスが必要です。\n- レジストリ参照のベース名は*常に* chart の名前と一致する必要があります。\n- レジストリ参照のタグは*常に* chart のセマンティックバージョンと一致する必要があります（`latest` タグは使用できません）。\n- chart レイヤーのメディアタイプが `application/tar+gzip` から `application/vnd.cncf.helm.chart.content.v1.tar+gzip` に変更されました。\n\n\n## OCI ベースのレジストリの使用\n\n### OCI ベースレジストリにおける Helm リポジトリ\n\n[Helm リポジトリ](/topics/chart_repository.md)は、パッケージ化された Helm chart を格納・配布する方法です。OCI ベースのレジストリには複数の Helm リポジトリを含めることができ、各リポジトリには複数のパッケージ化された Helm chart を含めることができます。\n\n### ホステッドレジストリの使用\n\nOCI 対応のホスト型コンテナレジストリがいくつかあります。例:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\nホステッドコンテナレジストリプロバイダーのドキュメントに従って、OCI サポート付きのレジストリを作成・設定してください。\n\n**注意:** ローカル環境で [Docker Registry](https://docs.docker.com/registry/deploying/) や [`zot`](https://github.com/project-zot/zot) などの OCI レジストリを実行することも可能です。ただし、ローカル環境での実行はテスト目的に限定してください。\n\n### sigstore を使用した OCI ベース chart の署名\n\n[`helm-sigstore`](https://github.com/sigstore/helm-sigstore) プラグインを使用すると、コンテナイメージの署名と同じツールで [Sigstore](https://sigstore.dev/) を使用して Helm chart に署名できます。これは、従来の [chart リポジトリ](/topics/chart_repository.md)でサポートされている [GPG ベースの provenance](/topics/provenance.md) の代替手段です。\n\n`helm sigstore` プラグインの使用方法の詳細は、[プロジェクトのドキュメント](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md)を参照してください。\n\n## レジストリ操作用のコマンド\n\n### `registry` サブコマンド\n\n#### `login`\n\nレジストリにログインします（パスワードを手動入力）\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nレジストリからログアウトします\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### `push` サブコマンド\n\nOCI ベースのレジストリに chart をアップロードします:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\n`push` サブコマンドは、事前に `helm package` で作成した `.tgz` ファイルに対してのみ使用できます。\n\n`helm push` を使用して chart を OCI レジストリにアップロードする場合、参照には `oci://` プレフィックスを付ける必要があり、ベース名やタグを含めてはいけません。\n\nレジストリ参照のベース名は chart の名前から推測され、タグは chart のセマンティックバージョンから推測されます。これは現在、厳格な要件です。\n\n一部のレジストリでは、リポジトリや namespace（指定する場合）を事前に作成しておく必要があります。そうしないと、`helm push` 操作中にエラーが発生します。\n\n[provenance ファイル](/topics/provenance.md)（`.prov`）を作成済みで、chart の `.tgz` ファイルと同じディレクトリにある場合、`push` 時に自動的にレジストリにアップロードされます。これにより、[Helm chart マニフェスト](#helm-chart-manifest)に追加のレイヤーが作成されます。\n\n[helm-push プラグイン](https://github.com/chartmuseum/helm-push)（[ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server) に chart をアップロードするためのプラグイン）のユーザーは、このプラグインが新しい組み込みの `push` と競合するため、問題が発生する可能性があります。バージョン v0.10.0 以降、このプラグインは `cm-push` に名前が変更されました。\n\n### その他のサブコマンド\n\n`oci://` プロトコルは、他のさまざまなサブコマンドでもサポートされています。以下は完全なリストです:\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nchart のダウンロードを伴うアクションでは、レジストリ参照のベース名（chart 名）を含めます（`helm push` ではベース名を省略）。\n\n以下は、上記のサブコマンドを OCI ベースの chart に対して使用する例です:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## 依存関係の指定\n\nchart の依存関係は、`dependency update` サブコマンドを使用してレジストリから取得できます。\n\n`Chart.yaml` 内の各エントリの `repository` は、ベース名を除いたレジストリ参照として指定します:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\n`dependency update` を実行すると、`oci://localhost:5000/myrepo/mychart:2.7.0` が取得されます。\n\n## Helm chart マニフェスト\n\nレジストリに表示される Helm chart マニフェストの例です（`mediaType` フィールドに注目してください）:\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\n以下の例には [provenance ファイル](/topics/provenance.md)が含まれています（追加のレイヤーに注目してください）:\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## chart リポジトリからの移行\n\n従来の [chart リポジトリ](/topics/chart_repository.md)（index.yaml ベースのリポジトリ）からの移行は、`helm pull` を使用してから、生成された `.tgz` ファイルを `helm push` でレジストリにアップロードするだけです。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: Helm v2 から v3 への移行\ndescription: Helm v2 から v3 への移行方法について説明します。\nsidebar_position: 13\n---\n\nこのガイドでは、Helm v2 から v3 への移行方法について説明します。Helm v2 がインストールされており、1 つ以上のクラスターで release を管理している環境が前提です。\n\n## Helm 3 の変更点の概要\n\nHelm 2 から 3 への変更点の完全なリストは、[FAQ セクション](/faq/changes_since_helm2.md)に記載されています。以下は、移行前および移行中にユーザーが認識しておくべき主な変更点の概要です。\n\n1. Tiller の廃止:\n   - クライアント/サーバー アーキテクチャからクライアント/ライブラリ アーキテクチャに変更（`helm` バイナリのみ）\n   - セキュリティはユーザー単位で管理（Kubernetes ユーザーのクラスターセキュリティに委任）\n   - release はクラスター内の Secret として保存され、release オブジェクトのメタデータが変更\n   - release は Tiller の namespace ではなく、release ごとの namespace 単位で永続化\n2. chart リポジトリの更新:\n   - `helm search` がローカルリポジトリ検索と Artifact Hub への検索クエリの両方をサポート\n3. chart の apiVersion が「v2」に更新され、以下の仕様変更を含む:\n   - 動的にリンクされる chart の依存関係が `Chart.yaml` に移動（`requirements.yaml` は廃止、requirements → dependencies に変更）\n   - ライブラリ chart（ヘルパー/共通 chart）を動的にリンクされた chart の依存関係として追加可能\n   - chart に `type` メタデータフィールドが追加され、`application` または `library` chart として定義可能。デフォルトは application で、レンダリングおよびインストールが可能\n   - Helm 2 の chart（apiVersion=v1）も引き続きインストール可能\n4. XDG ディレクトリ仕様の追加:\n   - Helm home が廃止され、構成ファイルの保存には XDG ディレクトリ仕様を使用\n   - Helm の初期化が不要に\n   - `helm init` と `helm home` は廃止\n5. その他の変更:\n   - Helm のインストール/セットアップが簡素化:\n     - Helm クライアント（helm バイナリ）のみ（Tiller 不要）\n     - インストール後すぐに使用可能\n   - `local` や `stable` リポジトリはデフォルトで設定されない\n   - `crd-install` hook は廃止され、chart 内の `crds` ディレクトリに置き換え。このディレクトリで定義されたすべての CRD は、chart のレンダリング前にインストールされる\n   - `test-failure` hook のアノテーション値は廃止、`test-success` は非推奨。代わりに `test` を使用\n   - コマンドの廃止/置き換え/追加:\n       - delete → uninstall：デフォルトですべての release 履歴を削除（以前は `--purge` が必要）\n       - fetch → pull\n       - home（廃止）\n       - init（廃止）\n       - install：release 名または `--generate-name` 引数が必須\n       - inspect → show\n       - reset（廃止）\n       - serve（廃止）\n       - template：`-x`/`--execute` 引数が `-s`/`--show-only` に名称変更\n       - upgrade：`--history-max` 引数が追加され、release ごとに保存されるリビジョンの最大数を制限可能（0 で無制限）\n   - Helm 3 の Go ライブラリは大幅に変更されており、Helm 2 ライブラリとは互換性がない\n   - リリースバイナリは `get.helm.sh` でホストされています\n\n## 移行のユースケース\n\n移行のユースケースは以下のとおりです。\n\n1. Helm v2 と v3 で同じクラスターを管理する場合:\n   - このユースケースは、Helm v2 を段階的に廃止する予定があり、v3 で v2 がデプロイした release を管理する必要がない場合にのみ推奨されます。新しい release はすべて v3 でデプロイし、既存の v2 でデプロイされた release は v2 のみで更新/削除してください\n   - Helm v2 と v3 は同じクラスターを問題なく管理できます。両方のバージョンは同じシステムまたは別々のシステムにインストールできます\n   - Helm v3 を同じシステムにインストールする場合、Helm v2 クライアントを削除する準備ができるまで、両方のクライアントバージョンが共存できるように追加の手順が必要です。競合を避けるため、Helm v3 バイナリの名前を変更するか、別のフォルダに配置してください\n   - それ以外の場合、以下の理由により両バージョン間で競合は発生しません:\n     - 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 の両方でインクリメンタルです\n     - 唯一の問題は、Kubernetes クラスタースコープのリソース（例: `clusterroles.rbac`）が chart で定義されている場合です。リソースが競合するため、namespace 内でユニークであっても v3 のデプロイは失敗します\n     - v3 の構成は `$HELM_HOME` を使用せず、代わりに XDG ディレクトリ仕様を使用します。また、必要に応じてオンデマンドで作成されます。そのため、v2 の構成とは独立しています。これは両方のバージョンが同じシステムにインストールされている場合にのみ適用されます\n\n2. Helm v2 から Helm v3 への移行:\n   - このユースケースは、Helm v3 で既存の Helm v2 release を管理したい場合に適用されます\n   - Helm v2 クライアントには以下の特徴があることに注意してください:\n     - 1 つ以上の Kubernetes クラスターを管理可能\n     - クラスターごとに 1 つ以上の Tiller インスタンスに接続可能\n   - つまり、release は Tiller とその namespace によってクラスターにデプロイされるため、移行時にはこの点を認識する必要があります。したがって、Helm v2 クライアントインスタンスが管理する各クラスターと各 Tiller インスタンスについて移行を行う必要があります\n   - 推奨されるデータ移行パスは以下のとおりです:\n     1. v2 データのバックアップ\n     2. Helm v2 構成の移行\n     3. Helm v2 release の移行\n     4. Helm v3 がすべての Helm v2 データ（Helm v2 クライアントインスタンスのすべてのクラスターと Tiller インスタンス）を期待どおりに管理していることを確認したら、Helm v2 データをクリーンアップ\n   - 移行プロセスは Helm v3 の [2to3](https://github.com/helm/helm-2to3) プラグインによって自動化されています\n\n## 参照\n\n- Helm v3 [2to3](https://github.com/helm/helm-2to3) プラグイン\n- `2to3` プラグインの使用例を説明したブログ[記事](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Helm バージョンサポートポリシー\"\ndescription: \"Helm のパッチリリースポリシーと、Helm と Kubernetes 間でサポートされる最大バージョン差について説明します。\"\n---\n\nこのドキュメントでは、Helm と Kubernetes 間でサポートされる最大バージョン差について説明します。\n\n## サポートされているバージョン\n\nHelm のバージョンは `x.y.z` の形式で表されます。ここで、`x` はメジャーバージョン、`y` はマイナーバージョン、`z` はパッチバージョンを表し、[セマンティックバージョニング](https://semver.org/spec/v2.0.0.html)の用語に従っています。\n\nHelm プロジェクトでは、最新のマイナーリリースに対応するリリースブランチを維持しています。重大度と実現可能性に応じて、セキュリティ修正を含む対象の修正がリリースブランチに取り込まれます。詳細は [Helm のリリースポリシー](/community/release_policy)を参照してください。\n\n## サポートされるバージョン差\n\nHelm の新しいバージョンがリリースされると、特定のマイナーバージョンの Kubernetes に対してコンパイルされます。たとえば、Helm 3.0.0 は Kubernetes 1.16.2 クライアントを使用して Kubernetes と通信するため、Kubernetes 1.16 と互換性があります。\n\nHelm 3 以降では、コンパイル対象となった Kubernetes のバージョンを基準に、そこから 3 つ前のマイナーバージョン（`n-3`）までの互換性が想定されています。Kubernetes はマイナーバージョン間で変更が発生するため、Helm 2 のサポートポリシーはやや厳格であり、1 つ前のバージョン（`n-1`）までの互換性が想定されています。\n\nたとえば、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 で安全に使用できます。\n\nHelm がコンパイル対象となったバージョンよりも新しいバージョンの Kubernetes で使用することは推奨されません。Helm は前方互換性を保証していないためです。\n\nHelm がサポートしていないバージョンの Kubernetes で Helm を使用する場合は、自己責任でご利用ください。\n\nクラスターと互換性のある Helm バージョンを確認するには、以下の表を参照してください。\n\n| Helm バージョン | サポートされている Kubernetes バージョン |\n|--------------|-------------------------------|\n| 3.20.x       | 1.35.x - 1.32.x               |\n| 3.19.x       | 1.34.x - 1.31.x               |\n| 3.18.x       | 1.33.x - 1.30.x               |\n| 3.17.x       | 1.32.x - 1.29.x               |\n| 3.16.x       | 1.31.x - 1.28.x               |\n| 3.15.x       | 1.30.x - 1.27.x               |\n| 3.14.x       | 1.29.x - 1.26.x               |\n| 3.13.x       | 1.28.x - 1.25.x               |\n| 3.12.x       | 1.27.x - 1.24.x               |\n| 3.11.x       | 1.26.x - 1.23.x               |\n| 3.10.x       | 1.25.x - 1.22.x               |\n| 3.9.x        | 1.24.x - 1.21.x               |\n| 3.8.x        | 1.23.x - 1.20.x               |\n| 3.7.x        | 1.22.x - 1.19.x               |\n| 3.6.x        | 1.21.x - 1.18.x               |\n| 3.5.x        | 1.20.x - 1.17.x               |\n| 3.4.x        | 1.19.x - 1.16.x               |\n| 3.3.x        | 1.18.x - 1.15.x               |\n| 3.2.x        | 1.18.x - 1.15.x               |\n| 3.1.x        | 1.17.x - 1.14.x               |\n| 3.0.x        | 1.16.x - 1.13.x               |\n| 2.16.x       | 1.16.x - 1.15.x               |\n| 2.15.x       | 1.15.x - 1.14.x               |\n| 2.14.x       | 1.14.x - 1.13.x               |\n| 2.13.x       | 1.13.x - 1.12.x               |\n| 2.12.x       | 1.12.x - 1.11.x               |\n| 2.11.x       | 1.11.x - 1.10.x               |\n| 2.10.x       | 1.10.x - 1.9.x                |\n| 2.9.x        | 1.10.x - 1.9.x                |\n| 2.8.x        | 1.9.x - 1.8.x                 |\n| 2.7.x        | 1.8.x - 1.7.x                 |\n| 2.6.x        | 1.7.x - 1.6.x                 |\n| 2.5.x        | 1.6.x - 1.5.x                 |\n| 2.4.x        | 1.6.x - 1.5.x                 |\n| 2.3.x        | 1.5.x - 1.4.x                 |\n| 2.2.x        | 1.5.x - 1.4.x                 |\n| 2.1.x        | 1.5.x - 1.4.x                 |\n| 2.0.x        | 1.4.x - 1.3.x                 |\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"はじめに\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"ハウツー\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"トピック\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"ベストプラクティス\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"チャートテンプレートガイド\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Helmコマンド\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"コミュニティ\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"よくある質問\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs-community/current/developers.md",
    "content": "---\ntitle: 開発者ガイド\ndescription: Helmを開発するための環境をセットアップする方法を説明します。\nsidebar_position: 1\n---\n\nこのガイドでは、Helmで開発するための環境をセットアップする方法について説明します。\n\n## 必要な環境\n\n- Goの最新バージョン\n- kubectlおよびKubernetesクラスター (optional)\n- Git\n\n## Helmをビルドする\n\nMakeを使用してプログラムを構築します。最も簡単な方法は次のとおりです:\n\n```console\n$ make\n```\n\n注意: `$GOPATH/src/helm.sh/helm` のパスにて実行されていない場合、このコマンドは失敗します。 また、`build`\nが関連するパッケージが見つけられないため、`helm.sh`ディレクトリをシンボリックリンクにしてはいけません。\n\nこのコマンドは必要に応じて依存関係をインストールし、`vendor/`ツリーを再ビルドしたのち、configurationを検証します。 その後に`helm`をコンパイルして`bin/helm`に配置します。\n\nHelmをローカルで実行するには、`bin/helm`を実行してください。\n\n- Helmは、macOSおよびAlpineを含んだほとんどのLinuxディストリビューションで動作することが知られています。\n\n## テストの実行\n\nすべてのテスト(`vendor/`のテストを除く)を実行するには、`make test`を実行してください。 前提条件として、[golangci-lint](https://golangci-lint.run)\nをインストールする必要があります 。\n\n## コントリビューションガイドライン\n\n私たちはコントリビューションを歓迎します。 このプロジェクトは、（a)\nコードの品質を高く保ち（b）プロジェクトの一貫性を保ち（c）コントリビューションがオープンソースの法的要件に従うことを保証するため、いくつかのガイドラインを設定しました。\n私たちの目的はコントリビューターに負担をかけることではなく、ユーザーが利益を得ることができるようにエレガントで高品質なオープンソースコードを構築することです。\n\nCONTRIBUTINGガイドを読み、理解していることを確認してください。\n\nhttps://github.com/helm/helm/blob/main/CONTRIBUTING.md\n\n### コードの構造\n\nHelmプロジェクトのコードは、以下のように構成されています。\n\n- 個々のプログラムは`cmd/`にあります。`cmd/`内のコードはライブラリ再利用を目的として設計されていません。\n- 共有ライブラリは`pkg/`にあります。\n- `scripts/`ディレクトリには多数のユーティリティスクリプトがあります。これらのほとんどはCI/CDパイプラインによって使用されます。\n\nGoの依存関係管理は流動的であり、Helmのライフサイクルの過程で変更される可能性があります。 依存関係を手動で管理 _しない_ ことをお勧めします。 その代わりに、プロジェクトの`Makefile`に依存して管理を行うことをお勧めします。\nHelm 3では、Goバージョン1.13以降を使用することをお勧めします。\n\n### ドキュメントの作成\n\nHelm 3以降、ドキュメントは独自のリポジトリに移動されました。 新しい機能を作成する場合は付属のドキュメントを作成して、[helm-www](https://github.com/helm/helm-www)にsubmitしてください。\n\n例外: [Helm CLI output (英語)](/docs/helm) は `helm` のバイナリ自体から生成されます。\nこのoutputを生成する方法については[Updating the Helm CLI Reference Docs](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs)\nをご覧ください。 翻訳された場合、CLI出力は生成されず`/content/<lang>/docs/helm`に生成されます。\n\n### Git 規約\n\nバージョン管理システムにはGitを使用しています。\n`main`ブランチは現在の開発候補の中心です。 リリースにはタグが付けられます。\n\nGitHubのPull Requests（PRs）を介してコードの変更を受け付けています。 これを行うためのワークフローの一例は次のとおりです。\n\n1. `$GOPATH/src` に移動して `mkdir helm.sh; cd helm.sh` を実行し、 `github.com/helm/helm`\n   のリポジトリを`git clone` します。\n2. リポジトリをあなたのGitHubアカウントにフォークします\n3. あなたのリポジトリを`$GOPATH/src/helm.sh/helm`のリモートとして追加します。\n4. 新しい作業ブランチ (`git checkout -b feat/my-feature`) 作成し、そのブランチで作業を行います。\n5. レビューの準備ができましたら、あなたのブランチをGitHubにプッシュして新しいプルリクエストを開いてください。\n\nGit commit messagesに関しては[Semantic Commit Messages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)\nに従います\n:\n\n```\nfix(helm): add --foo flag to 'helm install'\n\nWhen 'helm install --foo bar' is run, this will print \"foo\" in the\noutput regardless of the outcome of the installation.\n\nCloses #1234\n```\n\n一般的なコミットタイプ:\n\n- fix: バグまたはエラーを修正\n- feat: 新機能を追加\n- docs: ドキュメントを変更\n- test: テストを改善する\n- ref: 既存のコードのリファクタリング\n\n一般的なスコープ:\n\n- helm: The Helm CLI\n- pkg/lint: lintパッケージ。どのパッケージでも同様の規則に従ってください\n- `*`: 2つ以上のスコープ\n\nさらに読む:\n\n- [Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)\n  がこのセクションのインスピレーションになりました。\n- Karma Runner はthe semantic commit messageの考えを [定義しています](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)。\n\n### Go 規約\n\nGo coding style standardsに厳密に従っています。だいたいの場合`go fmt`を実行すればコードが美しくなります。\n\nまた、`go lint`および`gometalinter`によって推奨される規則に従います。\n`make test-style`を実行してスタイルの適合性をテストしてください。\n\nさらに読む:\n\n- Effective Go では[formattingを導入しています](https://golang.org/doc/effective_go.html#formatting).\n- The Go Wiki には\n  [formatting](https://github.com/golang/go/wiki/CodeReviewComments)に関して素晴らしい記事があります。\n\n`make test`ターゲットを実行すると、単体テストが実行されるだけでなく、スタイルテストも実行されます。\n`make test`ターゲットが失敗する場合は、それが文体に起因するものであったとしても、あなたのPRがマージに向けた準備ができていないと判断されます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs-community/current/history.mdx",
    "content": "---\ntitle: プロジェクトの歴史\ndescription: プロジェクトの歴史の概要を提供します。\nsidebar_position: 4\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm は [CNCF の Graduated プロジェクト](https://helm.sh/blog/celebrating-helms-cncf-graduation/)です。\n\nHelm は、現在 [Helm Classic](https://github.com/helm/helm-classic) として知られているものとして始まりました。\nこれは、2015年に開始され、\n最初の KubeCon で導入された Deis プロジェクトです。\n\n2016 年 1 月、プロジェクトは Kubernetes Deployment Manager と呼ばれる GCS ツールと統合され、\nプロジェクトは [Kubernetes](https://kubernetes.io) の下に移動されました。\nコードベースの統合の結果、\nHelm 2.0 がその年の後半にリリースされました。\nHelm 2 で生き残った Deployment Manager の主要な機能はサーバー側のコンポーネントで、\n最終的な Helm 2.0 リリースでは DM から Tiller に名前が変更されました。\n\nHelm は、2018 年 6 月に Kubernetes サブプロジェクトから本格的な CNCF プロジェクトに昇格しました。\nHelm はトップレベルの管理組織を形成し、\nMonocular、Helm Chart Repo、Chart Museum、そして後に Helm Hub など、\nいくつかのプロジェクトが Helm プロジェクトに組み込まれました。\n\nHelm 3 の開発サイクルが始まると、Tiller が削除され、\nHelm はクライアントツールであるという当初のビジョンに近づきました。\nただし、Helm 3 は引き続き Kubernetes クラスター内のリリースを追跡しているため、\nチームが共同で Helm リリースのセットで作業することができます。Helm 3 は 2019 年 11 月にリリースされました。\n\nHelm は、[2020 年 4 月に CNCF の Graduated プロジェクトになりました](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/)。"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs-community/current/localization.md",
    "content": "---\ntitle: Helm ドキュメントの国際化\ndescription: Helm ドキュメントを国際化するための手順。\nsidebar_position: 5\n---\n\nこのガイドでは Helm ドキュメントをどのように国際化するかを説明します。\n\n## はじめに\n\n翻訳への貢献にはドキュメントへの貢献と同様のプロセスを用います。翻訳は [helm-www](https://github.com/helm/helm-www) git リポジトリへの[プルリクエスト](https://help.github.com/ja/github/collaborating-with-issues-and-pull-requests/about-pull-requests)によって供給され、プルリクエストはウェブサイトの管理チームによってレビューされます。\n\n### 2文字言語コード {#two-letter-language-code}\n\nドキュメントは [ISO 639-1\n標準](https://www.loc.gov/standards/iso639-2/php/code_list.php) 言語コードによって管理されます。例えば、韓国語の2文字コードは `ko` です。\n\nコンテンツや設定でこの言語コードが使われます。3つ例を示します。\n\n- `content` ディレクトリ内で言語コードがサブディレクトリとして存在し、国際化されたコンテンツがそれぞれのディレクトリに入っています。\n- `i18n` ディレクトリはそれぞれの言語について、ウェブサイトで使用されるフレーズについての設定ファイルを保有しています。それらのファイルは `[LANG]` がその言語の2文字コードとなるような `[LANG].toml` というパターンで命名されています。\n- トップレベルの `config.toml` ファイルではナビゲーションやその他の詳細が言語コードごとに管理されています。\n\n言語コード `en` を持つ英語が、デフォルトの言語および翻訳元として用いられます。\n\n### フォーク、ブランチ、変更、プルリクエスト\n\n翻訳に貢献するために、まずは Github の [helm-www リポジトリ](https://github.com/helm/helm-www)の[フォークを作る](https://help.github.com/ja/github/getting-started-with-github/fork-a-repo)ことから始めましょう。あなたはまずあなたのフォークに変更をコミットすることから始めるでしょう。\n\n初期状態であなたのフォークは `main` として知られるデフォルトブランチに設定されているでしょう。あなたの変更を開発するあるいはプルリクエストを作成するためにブランチを使用してください。もしブランチについて不慣れなら[それらについて Github ドキュメントで読む](https://help.github.com/ja/github/collaborating-with-issues-and-pull-requests/about-branches)ことができます。\n\nブランチを作成出来たら、翻訳を追加したり、コンテンツを国際化したりしましょう。\n\n注：helm は [Developers Certificate of\nOrigin](https://developercertificate.org/) を利用しています。すべてのコミットは署名されている必要があります。コミットを作成する際に `-s` か `--signoff` フラグを用いることで、あなたの Git に設定されている名前とメールアドレスを用いてコミットに署名することができます。詳細については [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work) をご覧ください。\n\n準備ができたら、[プルリクエスト](https://help.github.com/ja/github/collaborating-with-issues-and-pull-requests/about-pull-requests) を作成し、helm-www リポジトリに反映しましょう。\n\n作成されたプルリクエストは管理者によってレビューされます。その過程についての詳細は [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md) を参照してください。\n\n## コンテンツの翻訳\n\n全ての Helm コンテンツを国際化するのは大きな仕事です。小さなことから初めて大丈夫です。時間をかけて翻訳を拡大することができます。\n\n### 新たな言語を開始する\n\n新たな言語を開始するには以下の最低要件が必要です。\n\n- `_index.md` ファイルを含む `content/[LANG]/docs` ディレクトリを追加する。これはドキュメントランディングページの最上位です。\n- `i18n` ディレクトリに `[LANG].toml` ファイルを作成する。まずは開始地点として `en.toml` ファイルをコピーすることができます。\n- 新たな言語を公開するため、`config.toml` ファイルにその言語のセクションを追加する。既に存在する言語のセクションを開始地点とすることができます。\n\n### 翻訳\n\n翻訳されたコンテンツは `content/[LANG]/docs` ディレクトリ内に存在する必要があります。それらは英語ソースと同じURLを持ちます。例えば、イントロダクションを韓国語に翻訳するなら以下のように英語ソースをコピーすると便利です。\n\n```sh\nmkdir -p content/ko/docs/intro\ncp content/en/docs/intro/install.md content/ko/docs/intro/install.md\n```\n\n新しいファイルの内容を別の言語に翻訳することができます。\n\n翻訳されていない英語ファイルのコピーを `content/[LANG]/` に追加しないでください。言語がその場所に存在する場合、未翻訳のページは自動的に英語にリダイレクトされます。翻訳には時間がかかるので、常に古いフォークではなく最新のドキュメントを翻訳するようにしてください。\n\n全ての `aliases` 行をヘッダーセクションから削除するよう気をつけてください。`aliases: [\"/docs/using_helm/\"]` のような行は翻訳では持ちません。それらは新たなページには存在しない古いリンクへのリダイレクトです。\n\n注：翻訳ツールが助けになるかもしれません。それには機械翻訳が含まれています。機械翻訳は公開前に編集される、またはネイティブ話者によって文法や意味をレビューされる必要があります。\n\n## 言語間のナビゲーション\n\n![Screen Shot 2020-05-11 at 11 24 22\nAM](https://user-images.githubusercontent.com/686194/81597103-035de600-937a-11ea-9834-cd9dcef4e914.png)\n\nサイトグローバルな　[config.toml](https://github.com/helm/helm-www/blob/main/config.toml#L83L89) ファイルで言語ナビゲーションが設定されています。\n\n新たな言語を追加するには、上で定義した新たな[2文字言語コード](#two-letter-language-code)を追加する必要があります。例：\n\n```\n# Korean\n[languages.ko]\ntitle = \"Helm\"\ndescription = \"Helm - The Kubernetes Package Manager.\"\ncontentDir = \"content/ko\"\nlanguageName = \"한국어 Korean\"\nweight = 1\n```\n\n## 内部リンクの解決\n\n翻訳されたコンテンツは時々別言語にしか存在しないページへのリンクを含んでいるでしょう。これによって[ビルドエラー](https://app.netlify.com/sites/helm-merge/deploys)が発生します。例：\n\n```\n12:45:31 PM: htmltest started at 12:45:30 on app\n12:45:31 PM: ========================================================================\n12:45:31 PM: ko/docs/chart_template_guide/accessing_files/index.html\n12:45:31 PM:   hash does not exist --- ko/docs/chart_template_guide/accessing_files/index.html --> #basic-example\n12:45:31 PM: ✘✘✘ failed in 197.566561ms\n12:45:31 PM: 1 error in 212 documents\n```\n\nこれを解決するために、あなたのコンテンツの内部リンクを確認する必要があります。\n\n* アンカーリンクは翻訳された `id` の値を反映する必要があります。\n* 内部リンクを修正する必要があります。\n\n存在しない _（もしくはまだ翻訳されていない）_ 内部ページについては、修正がされるまでサイトがビルドされません。代わりに、下記のようにコンテンツが _存在する_ 別の言語にURLを向けることができます。\n\n\n`< relref path=\"/docs/topics/library_charts.md\" lang=\"en\" >`\n\n詳細については [言語間相互リファレンスについての Hugo ドキュメント](https://gohugo.io/content-management/cross-references/#link-to-another-language-version) をご覧ください。\n"
  },
  {
    "path": "i18n/ja/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: \"リリーススケジュールポリシー\"\ndescription: \"Helm のリリーススケジュールポリシーについて説明します。\"\n---\n\nユーザーの利便性のため、Helm はリリース日を事前に定義し、公開しています。このドキュメントでは、Helm のリリーススケジュールを規定するポリシーについて説明します。\n\n## リリースカレンダー\n\n今後の Helm リリースを示す公開カレンダーは[こちら](https://helm.sh/calendar/release)で確認できます。\n\n## セマンティックバージョニング\n\nHelm のバージョンは `x.y.z` の形式で表されます。ここで、`x` はメジャーバージョン、`y` はマイナーバージョン、`z` はパッチバージョンを表し、[セマンティックバージョニング](https://semver.org/spec/v2.0.0.html)の用語に従っています。\n\n## パッチリリース\n\nパッチリリースは、バグ修正とセキュリティ修正をユーザーに提供します。新機能は含まれません。\n\n最新のマイナー/メジャーリリースに対する新しいパッチリリースは、通常、毎月第2水曜日に行われます。\n\n重大なリグレッションやセキュリティ問題を修正するパッチリリースは、随時行われます。\n\nパッチリリースは、以下のいずれかの理由によりキャンセルされる場合があります。\n- 前回のリリース以降に新しいコンテンツがない場合\n- パッチリリースの予定日が、今後のマイナーリリースの最初のリリース候補（RC1）の1週間前以内に該当する場合\n- パッチリリースの予定日が、マイナーリリース後4週間以内に該当する場合\n\n## マイナーリリース\n\nマイナーリリースには、セキュリティ修正、バグ修正、および新機能が含まれます。API と CLI の使用方法に関して後方互換性があります。\n\nKubernetes のリリースに合わせて、Helm のマイナーリリースは4ヶ月ごとに行われます（年3回のリリース）。\n\n追加のマイナーリリースは必要に応じて行われますが、次の定期リリースまで7日以上ある場合に限り、既存のリリーススケジュールには影響しません。\n\nリリースが公開されると同時に、次のマイナーリリースの日程が発表され、Helm のメイン Web ページに掲載されます。\n\n## メジャーリリース\n\nメジャーリリースには、破壊的変更が含まれます。このようなリリースはまれですが、Helm が重要な新しい方向に進化し続けるために必要な場合があります。\n\nメジャーリリースは計画が難しい場合があります。そのため、最終リリース日は、そのようなリリースの最初のベータバージョンが利用可能になった時点で決定し、発表されます。\n"
  },
  {
    "path": "i18n/ja/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Helmプロジェクト\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"開発\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"コミュニティ\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"ソースコード\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"ブログ\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"イベント\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"行動規範\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"はじめに\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Chartのコツ＆ヒント\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"Chartsの開発\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"800以上のChartsを検索\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"貢献ガイド\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"メンテナー\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"週次ミーティング\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"GitHubコミュニティ\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<a href=\\\"https://www.cncf.io/\\\">私たちはCloud Native Computing Foundationの卒業プロジェクトです。</a><br/>© Helm Authors 2025. ドキュメントは<a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0</a>の下で配布されています。<br/>© 2025 The Linux Foundation. All rights reserved. The Linux Foundationは登録商標を有し、商標を使用しています。Linux Foundationの商標リストについては、<a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">商標使用ページ</a>をご覧ください。\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"CNCFロゴ\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/ja/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Helmロゴ\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"ドキュメント\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"ブログ\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"コミュニティ\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/ko/code.json",
    "content": "{\n  \"home.features.manageComplexity\": {\n    \"message\": \"복잡성 관리\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"message\": \"차트는 가장 복잡한 앱도 설명하고, 반복 가능한 애플리케이션 설치를 제공하며, 단일 권한 소스 역할을 합니다.\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"쉬운 업데이트\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"제자리 업그레이드와 사용자 정의 후크로 업데이트의 어려움을 없애세요.\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"간단한 공유\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"차트는 버전 관리, 공유, 공개 또는 비공개 서버에서의 호스팅이 쉽습니다.\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"롤백\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"{helmRollback}을 사용하여 릴리스의 이전 버전으로 쉽게 롤백할 수 있습니다.\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"기능\",\n    \"description\": \"Features section title\"\n  },\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"다음 기능 릴리스\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"버전:\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"날짜:\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"릴리스 일정\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"다가오는 이벤트\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"다가오는 이벤트\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"지난 이벤트\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"도구와 프로젝트를 시연하고 논의하기 위해 {meetLink}. 커뮤니티 회의는 녹화되어 {youtubeLink}.\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"매주 모입니다\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"YouTube에 공유됩니다\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"개발자 스탠드업 회의\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"목요일 오전 9:30-10시 (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"이 회의는 모두에게 열려 있습니다. 메모와 세부 사항은 {communityRepoLink}를 확인하세요.\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"커뮤니티 저장소\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Helm 사용, 차트 작업 및 일반적인 오류 해결에 대한 토론.\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Helm 개발, 진행 중인 PR, 릴리스 등에 관한 주제.\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Helm Charts 사용자 및 기여자를 위한 토론.\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"Kubernetes Slack 팀에 참여하려면 {slackLink}.\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"여기에서 액세스 요청\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"기여하기\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"Helm은 항상 프로젝트에 대한 새로운 기여를 환영합니다!\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"어디서부터 시작할까요?\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Helm은 많은 사용자와 기여자가 있는 큰 프로젝트입니다. 받아들일 것이 많을 수 있습니다!\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"도움을 주고 싶지만 어디서 시작해야 할지 모르겠다면 {goodFirstIssuesLink} 목록이 있습니다.\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"적당한 첫번째 이슈\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"무엇을 해야 하나요?\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"코드를 기여하기 전에 {contributionGuideLink}를 읽어주세요. Pull Request 생성 및 검토 프로세스를 다룹니다.\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"기여 가이드\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"코드를 작성한 후 Helm이 {cncfLink}에서 사용하는 {dcoLink} 계약을 준수하도록 {signYourCommitsLink}를 해주세요.\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"커밋에 서명\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"커뮤니티 참여\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Helm 프로젝트에 대한 자세한 정보와 기여 방법.\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"시작하기\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"헬름 설치하기!\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"패키지 관리자로 Helm을 설치하거나 {downloadLink}.\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"바이너리를 다운로드하세요\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"message\": \"설치가 완료되면 helm 바이너리의 압축을 풀고 PATH에 추가하면 바로 사용할 수 있습니다! 자세한 {installationLink} 및 {usageLink}는 {docsLink}를 확인하세요.\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"문서\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"설치 방법\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"사용 방법\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"차트 받기\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"{artifactHubLink}를 방문하여 수많은 공개 저장소의 {helmChartsLink}를 탐색하세요.\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"Helm 차트\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.about.whatIsHelm\": {\n    \"message\": \"Helm은 Kubernetes 애플리케이션 관리를 도와줍니다 — Helm Charts는 가장 복잡한 Kubernetes 애플리케이션도 정의, 설치 및 업그레이드할 수 있도록 도와줍니다.\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"message\": \"차트는 생성, 버전 관리, 공유 및 게시가 쉽습니다 — 그러니 Helm을 사용하고 복사-붙여넣기는 그만하세요.\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Helm은 {cncfLink}의 졸업 프로젝트이며 {helmCommunityLink}에 의해 유지 관리됩니다.\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"Helm 커뮤니티\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"자세히 알아보기:\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Helm 아키텍처\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"빠른 시작 가이드\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"동영상: Helm 소개\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"Helm이란 무엇인가요?\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"Kubernetes를 위한 패키지 관리자\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Helm은 소프트웨어를 찾고, 공유하고, 사용하는 가장 좋은 방법입니다\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"페이지에 오류가 발생하였습니다.\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"맨 위로 스크롤하기\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"게시물 목록\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"게시물 목록\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"블로그 게시물 목록 탐색\",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"이전 페이지\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"다음 페이지\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"블로그 게시물 탐색\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"이전 게시물\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"다음 게시물\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"모든 태그 보기\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"탐색 경로\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"{count} 항목\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"시스템 모드\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"밝은 모드\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"어두운 모드\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"어두운 모드와 밝은 모드 전환하기 (현재 {mode})\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"문서 페이지\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"이전\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"다음\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"{count}개 문서가\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged} \\\"{tagName}\\\" 태그에 분류되었습니다\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"버전: {versionLabel}\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"{siteTitle} {versionLabel} 문서는 아직 정식 공개되지 않았습니다.\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"{siteTitle} {versionLabel} 문서는 더 이상 업데이트되지 않습니다.\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"최신 문서는 {latestVersionLink} ({versionLabel})을 확인하세요.\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"최신 버전\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"페이지 편집\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"{heading}에 대한 직접 링크\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \" {date}에\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \" {user}가\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"최종 수정: {atDate}{byUser}\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"버전\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"페이지를 찾을 수 없습니다.\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"태그:\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"주의\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"위험\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"정보\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"노트\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"팁\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"경고\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"닫기\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"최근 블로그 문서 둘러보기\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"사이드바 분류 '{label}' 펼치기\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"사이드바 분류 '{label}' 접기\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(새 탭에서 열림)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"메인\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"언어\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"원하는 페이지를 찾을 수 없습니다.\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"message\": \"사이트 관리자에게 링크가 깨진 것을 알려주세요.\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"이 페이지에서\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"자세히 보기\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"{title} 에 대해 더 읽어보기\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"약 {readingTime}분\",\n    \"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)\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"복사\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"복사했습니다\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"클립보드에 코드 복사\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"줄 바꿈 전환\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"홈\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"문서 사이드바\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"사이드바 숨기기\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"사이드바 숨기기\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"사이드바 닫기\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← 메인 메뉴로 돌아가기\",\n    \"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)\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"사이드바 펼치거나 접기\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"드롭다운 펼치기\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"드롭다운 접기\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"사이드바 열기\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"사이드바 열기\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"{count}개 게시물\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"\\\"{tagName}\\\" 태그로 연결된 {nPosts}개의 게시물이 있습니다.\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"저자\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"모든 저자 보기\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"작성자가 아직 게시글을 작성하지 않았습니다.\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"색인되지 않은 문서\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"message\": \"이 문서는 색인되지 않습니다. 검색 엔진이 이 문서를 색인하지 않으며, 주소를 알고 있는 사용자만 접근할 수 있습니다.\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"작성 중인 페이지\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"이 페이지는 아직 작성 중입니다. 개발 환경에서만 보이며 프로덕션 빌드에서는 제외됩니다.\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"다시 시도해 보세요\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"본문으로 건너뛰기\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"태그\",\n    \"description\": \"The title of the tag list page\"\n  }\n}\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/2019-11-13-helm-3-released.md",
    "content": "---\ntitle: \"Helm 3.0.0 출시!\"\nslug: \"helm-3-released\"\nauthors: [\"mattfisher\"]\ndate: \"2019-11-13\"\n---\n\n헬름 팀은 헬름 3의 첫번째 안정적 릴리스를 발표하게 된 것을 자랑스럽게 생각한다.\n\n헬름 3는 CLI 도구의 최신 주(major) 릴리스이다. 헬름 2의 성공을 기반으로, 헬름 3도 진화하는 생태계의 요구에 계속 부응하고 있다.<!-- truncate -->\n\n헬름 3의 내부 구현은 헬름 2와는 상당히 다르게 변경되었다. 가장 눈에 띄는 변화는 틸러(Tiller)가 제거된 것이다. 다만 새 릴리스에서 다른 변경사항들도 확인해두는 게 좋다. 커뮤니티의 의견과 요구사항에 따라 다양한 새로운 기능들이 추가되었다. 일부 기능은 헬름 2와 호환되지 않는 방식으로, 더 이상 사용되지 않거나 리팩토링되었다. OCI 지원을 포함하는 일부 실험적 기능도 도입되었다.\n\n추가로, 헬름 Go SDK 도 범용적으로 리팩토링되었다. 목표는 오픈 소스로 만든 코드를 Go 커뮤니티와 폭넓게 공유하고 재사용하는 것이다. 자신의 프로젝트에 헬름을 연계하여 사용하는 다른 엔지니어들의 의견을 활발하게 수용하고 있으며, [#헬름-개발 쿠버네티스 슬랙 채널](https://slack.k8s.io/)에서도 여러분들의 의견을 듣고자 한다.\n\n다음은 헬름 3의 몇 가지 리소스이다:\n\n- [문서](https://helm.sh/docs/)\n- [FAQ: 헬름 2에서 바뀐 점](https://helm.sh/docs/faq/#changes-since-helm-2)\n- [헬름 설치](https://helm.sh/docs/intro/install/)\n- [헬름 2에서 헬름 3로의 마이그레이션에 대한 문서](https://helm.sh/docs/topics/v2_v3_migration/)\n- [헬름 2에서 헬름 3로 마이그레이션하는데 도움이 되는 플러그인](https://github.com/helm/helm-2to3)\n- [#헬름-사용자 쿠버네티스 슬랙 채널](https://slack.k8s.io/)에서 개발자 및 참여자와 채팅\n- <https://github.com/helm/helm/issues>에서 버그 신고\n\n## 헬름이란?\n\n헬름은 쿠버네티스 내에서 애플리케이션의 생성, 설치, 관리를 협업하는 데에 필요한 도구를 팀에 제공한다.\n\n헬름을 통하여, 사용자는 다음과 같은 것들을 할 수 있다.\n\n- 설치하여 사용할만한 패키징된 소프트웨어(차트) 찾기\n- 자신만의 패키지를 쉽게 만들고 호스팅\n- 모든 쿠버네티스 클러스터에 패키지 설치\n- 클러스터에 질의하여 설치되어 실행중인 패키지 확인\n- 설치된 패키지의 이력을 업데이트, 삭제, 롤백 및 조회\n\n헬름을 사용하면 쉽게 쿠버네티스 내에서 애플리케이션을 실행할 수 있다.\n\n## 함께 살펴보자!\n\n쿠버네티스 클러스터가 구동 중이고 `kubectl` 이 알맞게 설정되었다면, 헬름 작업은 식은 죽 먹기이다.\n\n헬름을 사용하면 커뮤니티에서 호스팅하는 저장소를 추가하여 새 차트를 쉽게 검색할 수 있다.\n\n```bash\n$ helm repo add nginx https://helm.nginx.com/stable\n```\n\n저장소를 추가했다면 차트를 검색할 수 있다:\n\n```bash\n$ helm search repo nginx-ingress\nNAME                    CHART VERSION   APP VERSION     DESCRIPTION\nnginx/nginx-ingress     0.3.7           1.5.7           NGINX Ingress Controller\n```\n\n헬름은 `helm install` 을 사용하여 차트를 빠르게 설치할 수 있는 방법을 제공한다.\n\n```bash\n$ helm install my-ingress-controller nginx/nginx-ingress\n```\n\n`kubectl` 로 클러스터를 확인해 보면:\n\n```bash\n$ kubectl get deployments\n```\n\n구동 중인 인그레스 컨트롤러(ingress controller)가 있다! `helm uninstall my-ingress-controller` 로 간단히 제거할 수 있다.\n\n자, 이제 몇 가지 차트를 적용해보았다. 또한 일부를 커스터마이즈해보았다. 이제 직접 만들 준비가 되었다. 헬름은 이 부분도 쉽게 해준다.\n\n```bash\n$ helm create diy\nCreating diy\n```\n\n이제 `diy` 라는 새 차트가 생겼다. 해당 디렉터리로 이동하여 편집하거나 `helm template` 을 실행하여 렌더링된 출력 결과를 보거나 `helm install` 을 사용하여 설치할 수 있다.\n\n[헬름 허브](https://hub.helm.sh/)에 업스트림으로 제출할 것인가? 주의하자! 헬름 허브에 [나만의 저장소를 추가](https://github.com/helm/hub/blob/master/Repositories.md)하기 위한 문서를 따라야 한다.\n\n## 헬름 3에서 변경되는 사항은?\n\n이쯤에서 이런 의문이 들지도 모르겠다.\n\n> 헬름 2에서는 워크플로가 어떻게 변경되었나? 헬름 2로 이러한 명령을 실행하면 동일한 출력 결과가 표시될까?\n\n헬름 2는 차트 생성, 설치, 관리를 위한 워크플로를 기술하였다. 헬름 3는 이러한 워크플로를 기반으로 진화하는 생태계의 요구사항을 충족하도록 기본 인프라를 변경하였다.\n\n만약 사용자가 헬름 2에 익숙할 경우, 헬름 3 를 사용하면 마치 집에 있는 것처럼 편안하게 느껴질 것이다.\n\n내부적으로 변경된 사항에 대해 자세히 알아보기 위하여 문서의 [FAQ를 확인](https://helm.sh/docs/faq/)하자. 변경 목록과 관련된 변경 사항에 대한 설명이 여기 제공된다.\n\n## 헬름의 미래\n\n핵심 관리자들은 헬름 3를 출시하게 되어 매우 기쁘다. 헬름의 다음 개발 단계에서는 기존 기능에 대한 안정성 및 향상을 목표로 하는 새로운 기능을 볼 수 있다. 로드맵 상의 기능은 다음과 같다:\n\n- `helm test` 의 기능 향상\n- 헬름의 OCI 연계 개선\n- Go 클라이언트 라이브러리의 기능 향상\n\n### 헬름 2 지원 계획\n\n헬름 2.15.0 릴리스 발표에서 헬름 2의 향후 계획에 대한 세부사항을 공유했다. 이 계획에 대한 자세한 내용은 [공지 게시물](https://helm.sh/blog/2019-10-22-helm-2150-released/)에서 확인할 수 있다.\n\n## 헬름 3와 헬름 1, 2와의 관계\n\n2015년 11월, 첫 번째 KubeCon 에서 헬름 첫 번째 버전이 출시되었다. macOS 소프트웨어 인스톨러 [Homebrew](https://brew.sh/)에서 모델링된 헬름 1 (팀에서는 \"헬름 클래식\" 이라고 한다)은 개별 개발자가 쿠버네티스 리소스 패키지를 만들고 클러스터에 배포할 수 있도록 설계되었다.\n\n몇 달 후(2016년 1월), Deis 의 코어 헬름 팀은 구글, Skippbox, Bitnami 와 협력하여 개인들에서 팀으로 방점을 옮겨 새로운 버전의 헬름을 제작하였다. 그 과정에서 여러 경험과 교훈들이 적용되었다. 그 결과 팀워크는 핵심가치가 되었고, 정교한 애플리케이션을 설치하려는 쿠버네티스 사용자들의 참여로 급성장한 커뮤니티의  요구를 충족시키기 위해 설계된 도구가 탄생하였다.\n\n2018년 6월 헬름은 [Cloud Native Computing Foundation에 가입](https://helm.sh/blog/helm-enters-the-cncf/)했다. 헬름 3는 Microsoft, 삼성 SDS, IBM 및 Blood Orange의 구성원을 포함하는 주요 유지관리자들의 공통된 노력이다. 첫 번째 알파 릴리스 이래로, 헬름 3는 여러 시간대(time zone)에 걸쳐 커뮤니티 구성원 37명의 기여가 있었다. 그 결과물은 시시각각 변화하고 진화하며 커뮤니티의 요구를 담아낸 도구이다.\n\n## 결론\n\n우리는 쿠버네티스로의 진입로가 되는 도구를 만들었다. 쿠버네티스 사용자가 운영 수준의 워크로드를 더 쉽게 생성, 공유, 실행할 수 있도록 돕고자 했다.\n\n설립 이래 500명 이상의 커뮤니티 회원이 헬름 CLI를 위한 코드에 기여해왔다. 수천 명의 커뮤니티 회원이 헬름 허브에서 차트를 활성적으로 관리한다. 수많은 활성 커뮤니티 회원들이 있다. 이는 이 프로젝트를 간단한 Deis 인스톨러를 모든 쿠버네티스 사용자를 위한 강력한 도구로 탈바꿈시킨 쿠버네티스 커뮤니티의 엄청난 노력에 의한 산물이다.\n\n모두 감사합니다. 깃헙에서 또 봐요!\n\n- 헬름 팀 :heart:\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/2019-11-15-helm-at-cloudnativecon.md",
    "content": "---\ntitle: \"KubeCon + CloudNativeCon NA 2019 에서의 헬름\"\nauthors: [\"mattfarina\"]\ndate: \"2019-11-15\"\n---\n\n다음 주에는 연례행사인 [KubeCon 과 CloudNativeCon 이 북미에서](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/) 열린다. 헬름 프로젝트 및 유지관리자들은 몇 가지를 준비하고 있고 여러분을 초대하고 싶다.<!-- truncate -->\n\n헬름 관련으로는 유지관리자 트랙 세션이 2개 있으며, [_헬름 소개_](https://sched.co/UajI) 및 [_헬름 3 심층 분석_](https://sched.co/Uagg)에 초점을 둔 내용이다. 헬름을 처음 사용하거나, 사용해야 하는 이유와 방법에 관심이 있는 사람은 _헬름 소개_ 세션에 참석해보자. [최근 출시된 헬름 3](https://helm.sh/blog/helm-3-released/)가 궁금한 사용자는 _헬름 3 심층 분석_ 세션이 적당할 것 같다. 관심을 가질 법한 주변 사람들에게도 널리 알려주자.\n\n올해는 헬름 프로젝트가 자체 프로젝트만의 독립된 부스를 가지는 첫 해이기도 하다! 헬름 유지관리자와 얘기를 나누고 싶거나 프로젝트에 대해 질문이 있다면 부스를 방문하여, 정기적으로 프로젝트를 진행하는 사람들을 만나보도록 하자.\n\n올해는 커뮤니티에서 준비한 몇 가지 흥미로운 헬름 관련 세션들도 있다. 예를 들어, CERN 의 Ricarto Rocha 는 [_CERN 에서 Gitops와 함께 헬름 배포 관리하기_](https://sched.co/UabD)에 대한 내용을 발표한다. [공식 일정표](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/schedule/)에서 다른 세션에 대한 일정도 확인할 수 있다.\n\n컨퍼런스가 시작하기 전 주말에 가도 될까? [Cloud_Native Rejekts](https://cloud-native.rejekts.io/)가 계속 진행될 것이며, 헬름 프로젝트 유지관리자 중 한 명인 Taylor Thomas는 [_(헬름으로 배우는) 쿠버네티스와의 고급 상호작용_](https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-na-2019/talk/SQ9DWX/)을 발표할 예정이다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/2020-04-02-covid-19-extending-helm-v2-bug-fixes.md",
    "content": "---\ntitle: \"COVID-19: 헬름 v2 버그 수정 확장\"\nslug: \"covid-19-extending-helm-v2-bug-fixes\"\nauthorname: \"Matt Farina & Bridget Kromhout\"\nauthorlink: \"https://helm.sh\"\ndate: \"2020-04-03\"\n---\n\n전 세계가 전염병에 맞서 싸우기 위해 힘을 모으는 것처럼 헬름 유지관리자들도, 개발 및 운영 일정이 조정되는 시기에도 최대 수요로 작동하는 주요 시스템을 유지보수하는 사용자들에게, 도움을 주는 역할을 잘 수행하고 있는지 점검하고자 한다.<!-- truncate -->\n\n헬름 v3가 2019년 11월에 출시되었을 때, 원래의 약속은 6개월 동안 헬름 v2 버그 수정을 제공하겠다는 것이었다. 버그 수정은 2020년 5월 13일에 종료되고, 그 후로 6개월 간 보안 수정이 예정되어 있었다. 감염병 예방이 우선이라는 전제 하에, 헬름 v2 버그 수정을 2020년 8월 13일까지 3개월 연장하여 헬름 사용자들이 커뮤니티의 가장 필요한 요구 사항에 대응할 계획이다.\n\n여러 가지 상황으로 인해 추가 일정 조정이 필요한지 확인하기 위해 상황을 모니터링할 것이다. 현재로서는 헬름 v2 지원이 11월 13일에 종료될 예정이다. (다만 보안 수정만은 3개월간으로 계획되어 있다.) 핵심 업무의 단절을 방지하고 안전을 지키기 위해 우리가 할 수 있는 일이 있다면 [커뮤니티 연락, 채팅, 메일링 리스트, 깃헙 저장소'](https://github.com/helm/community/blob/main/communication.md)를 통해 얘기해보자!\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/2020-04-30-celebrating-helms-cncf-graduation.md",
    "content": "---\ntitle: \"헬름의 CNCF 졸업을 축하하며\"\nslug: \"celebrating-helms-cncf-graduation\"\nauthors: [\"mattbutcher\"]\ndate: \"2020-04-30\"\ntwittertype: \"summary_large_image\"\ntwitterimage: \"blog/images/helmgraduation-twitter.png\"\n---\n\n![../images/helmgraduation.png](./images/helmgraduation.png)\n\n오늘 헬름이 [CNCF 사다리의 마지막 단계에 도달한 것](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/)을 보게 되어 기쁘다. 헬름은 [CNCF 프로젝트](https://www.cncf.io/projects/)의 인큐베이팅 단계에서 졸업 단계로 이동하여, 쿠버네티스 등 다른 선택된 프로젝트들과 나란히 서게 되었다.<!-- truncate -->\n\n헬름은 작은 스타트업 Deis의 해커톤 프로젝트로 소박하게 시작되었는데, 우리의 작은 아기가 완전히 성인으로 성장한 것처럼 기분이 정말 좋다. 그리고 우리는 지난 5년 동안 코딩, 커뮤니티, 조직 정책에 대해 많은 것을 배웠다. 그러나 이것이 우리가 헬름의 졸업을 축하하는 주요 이유는 아니다.\n\n헬름 프로젝트를 시작하고 몇 달 후, 우리는 쿠버네티스의 하위 프로젝트가 되었다. 그게 2016년 초였는데, 얼마 지나지 않아 사이드 프로젝트 수준이 아닌 쿠버네티스 생태계의 패키지 관리자로 자리매김하게 되었다. 쿠버네티스는 복잡성을 감추지 않고 SRE 및 DevOps 스토리에 집중했지만, 헬름은 다른 접근 방식을 취했다. 2016년 2월 회의에서 [Michelle Noorali](https://twitter.com/michellenoorali)는 화이트 보드에 다음과 같은 문구를 썼다. \"5분만에 0에서 도파민까지\" 이것이 우리 헬름의 만트라였다. 새로운 사용자를 쿠버네티스에 더 쉽게 접근하게 할 수 있다고 보았다. 우리가 옳았다면, 사용자는 헬름을 설치하고 몇 분 내로 운영 수준의 규격품 구성요소들을 설치할 수 있을 것이다.\n\n요즘 헬름은 대학생부터 주요 클라우드 제공 업체에 이르기까지 [쿠버네티스 사용자의 70% 이상이 사용](https://www.cncf.io/wp-content/uploads/2020/03/CNCF_Survey_Report.pdf)하고 있다. 신규 쿠버네티스 사용자가 헬름 덕분에 빠르게 설치하고 구동시킬 수 있었다는 얘기를 들을 때가 가장 뿌듯하다.\n\n한편, 헬름의 졸업은 2번째 구별점을 뜻한다. 헬름의 첫 번째 커밋 이래로 우리는 이것을 \"쿠버네티스용 패키지 관리자\"라고 불렀다. 즉 전반적인 설계의 초점은 쿠버네티스 리소스 정의 번들의 재배포, 설치, 업그레이드, 삭제를 가능하게 하는 것이다. 우리의 목표는 macOS 에서의 homebrew, 데비안/우분투에서의 apt-get, 윈도우에서의 Chocolatey처럼 쿠버네티스에서의 패키지 관리자가 되는 것이었다.\n\n당시에는 대단하지 않은 목표로 보였다. 쿠버네티스(버전 1.2) 사용자도 거의 없었다. 그런데 갑자기 쿠버네티스의 인기가 폭발적으로 증가했다. 몇몇 유명 회사에서는 운영 환경에 사용하기 시작했다. 그런 다음에는 주요 클라우드 제공 업체가 호스팅된 쿠버네티스 상품을 만들었다. 그리고 화려함보다 안정성을 추구하던 대기업들도 쿠버네티스를 본격적으로 사용하기 시작했다. 이것은 헬름에 대한 시험대(acid test)였다. 서로 다른 목표와 요구를 가진 사용자 수십만 명의 요구를 충족시킬 수 있는가? 그런 것 같아 보인다.\n\n\"졸업\"이라는 용어는 주요 요구사항들을 완수했다는 것을 의미한다. 수많은 사용자 기반을 갖춘 것은 고무적이었지만, CNCF 는 엔터프라이즈 준비도를 시험하는 기준 목록을 제시한다. 안정성, 보안, 강건한 거버넌스, 강력한 커뮤니티 -- 대규모 오픈 소스 프로젝트가 성공하려면 이러한 것들이 절대적으로 필요하다.\n\nCNCF는 [프로젝트](https://www.cncf.io/projects/)가 대다수의 사용자들이 사용할 수 있도록 준비되었다는 것을 입증할 때만 졸업시킨다. 인큐베이션에서 졸업으로 이동하기 위한 기준 목록은 안정적인 오픈 소스 프로젝트가 무엇인지를 정의하고 있다. 헬름에는 졸업 기준들이 깊이 녹아있다. 헬름은 보안 검토를 그냥 통과한 수준이 아니라 아주 우수한 성적으로 통과했다. 우리는 [CII 뱃지](https://bestpractices.coreinfrastructure.org/en)를 획득했을 뿐 아니라, [인증테스트에서 198%](https://bestpractices.coreinfrastructure.org/en/projects?q=helm%20package%20manager)를 기록했다. 서로 다른 회사의 커미터 2명만 있었지만, 이제는 전세계적으로 수많은 기여자들이 있다. 그리고 지난 수년간 개방적이고 공정한 거버넌스라는 우리의 약속을 지켜왔다.\n\n그래서 지금 우리는 이 이정표에 서 있다. 우리는 졸업에 관한 마지막 요구사항을 완수하였다. CNCF 기술 감독위원회(TOC)에서 대다수는 헬름이 최고 수준의 프로젝트라는 데에 동의하여 투표하였다.\n\n그렇다면 앞으로 헬름에는 어떤 변화가 있을까? 프로세스 측면에서는 모든 것이 그대로 유지된다. 우리는 메이저 버전에서 마이너 버전까지 안정성과 호환성에 대한 확고한 약속을 계속 유지할 것이다. 헬름 4에서 어떤 것이 더 필요할지에 대한 초기 단계의 조사도 시작하였다. 우리는 (항상 그랬듯이), 커뮤니티에 자신의 경험을 공유하려는 사용자, 상당한 시간을 들여 프로젝트 유지에 기여하려는 노련한 전문가 등 새로운 참여자를 열렬히 환영한다. 또한 우리는 CNCF 내에서 몇 가지 주요 움직임을 하나로 모으게 될 [CNCF 아티팩트 허브](https://devclass.com/2020/03/12/cncf-starts-new-artifact-hub/)에 대해서도 기대하고 있다. CNCF 커뮤니티와의 협업을 계속 해나는 것도 신나는 일이다.\n\n우리의 전통에 따라, 헬름의 성공에 기여한 수만 명의 커뮤니티 회원들에게 커다란 감사의 마음으로 전하며 이 글을 마친다. \"5분만에 0에서 도파민까지\" 경험을 모든 쿠버네티스 사용자에게 전해주기 위한 오랜 노력이 여기에 있다!\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/2020-08-13-helm-v2-deprecation-timeline.md",
    "content": "---\ntitle: \"헬름 v2 사용중단 타임라인\"\nslug: \"helm-v2-deprecation-timeline\"\nauthors: [\"bridgetkromhout\"]\ndate: \"2020-08-12\"\n---\n\n\n_[루이스 캐롤에게 고개를 끄덕이며...](https://www.jabberwocky.com/carroll/walrus.html)_\n\n    “때가 되었습니다,” 메인테이너(maintainers)는 말한다,\n      “소프트웨어의 운명에 대하여 이야기하기 위해:\n    업그레이드와 -- 헬름 v3의 출시와 --\n      버그의 수정 -- 그리고 k8s. --”\n\n헬름 v3는 [2019년 11월에 출시되었으며](/blog/helm-3-released/), 커뮤니티의 요구에 부응하여 헬름을 계속 발전시켜온 커뮤니티의 노력의 결과입니다. 간소화된 클라이언트 단독 사용환경, 새로운 보안 관점, 쿠버네티스 API와의 더욱 긴밀한 연계를 통하여 헬름 v3는 쿠버네티스에 대한 운영 테스트 패키지 관리 기능을 계속 제공합니다. 그리고 [졸업한 CNCF 프로젝트](/blog/celebrating-helms-cncf-graduation/)인 헬름은 클라우드 네이티브 생태계의 핵심부분입니다.<!-- truncate -->\n\n운영 환경에 주(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)되어 나올 것이다.\n<!--more-->\n헬름 사용자에게 이는 어떤 의미인가?\n\n_2020년 8월 13일 이후, 다음의 변경 사항이 적용된다:_\n- 만약 아직 헬름 v2를 사용중인 경우 지금 [헬름 v3로 마이그레이션](/blog/migrate-from-helm-v2-to-helm-v3/)하는 것이 좋다. 헬름 3.2.4는 널리 사용되고 있으며 운영준비가 되어있다. 대체로 이전 버전과 호환되지만 마이그레이션을 수행할 때 알아야 할 변경사항들이 있다.\n- 지금부터, 헬름 v2에 대한 지속적인 지원은 향후 3개월의 보안패치로 제한된다. 즉, 확인된 보안 문제 외에는 더 이상 PR 요청을 수락하지 않는다.\n- `stable` 및 `incubator` 저장소는 [2018년 12월에 도입된](/blog/intro-helm-hub/) 헬름 허브에서 삭제된다. [헬름 허브](https://hub.helm.sh)에서 선호하는 저장소를 찾아 구성에 추가하고, [새로운 분산 저장소들로의 마이그레이션을 수행해야](https://github.com/helm/charts/issues/21103) 한다.\n\n\n_2020년 11월 13일 이후로 다음과 같은 변경사항이 적용된다._\n- 더 이상 헬름 v2는 릴리스되지 않는다. (보안 패치조차도)\n- 더 이상 [헬름 v2 문서](https://v2.helm.sh/docs)에 대한 업데이트도 없다. 현재로서는 계속 사용될 수도 있지만, 중단될 수도 있다.\n- v2와 관련된 기존 및 신규 이슈/PR 은 닫히게 된다.\n- [헬름 릴리스와 차트 호스팅에 대한 소유권(ownership)을 CNCF로 이관](https://github.com/helm/community/issues/114).\n\n| | |\n| - | - |\n| 제거 예정 | 교체 예정 |\n| 구글 클라우드 스토리지를 통한 헬름 v2 클라이언트 다운로드 | [get.helm.sh](/blog/get-helm-sh/)을 통한 클라이언트 다운로드 |\n| 구글 컨테이너 레지스트리에 저장된 틸러(Tiller)용 도커 이미지 | [대신 다른 위치에서 사용 가능한](https://github.com/helm/helm/issues/8346) 틸러 이미지를 배포하며, helm init --tiller-image 명령어로 업데이트 가능하게 할 것이다. |\n| 안정적(stable)인 인큐베이터 차트 저장소를 위한 구글 클라우드 버킷 | “안정적” 인 “인큐베이터” 저장소 사용 중단; https://github.com/helm/charts 는 사용되지 않음(obsolete)으로 표시 |\n\n커뮤니티는 헬름 v3가 훨씬 개선된 환경임을 확인했으며, [helm-2to3 플러그인](https://github.com/helm/helm-2to3)과 같은 커뮤니티 리소스를 사용하여 필수 마이그레이션을 지원할 수 있다. 더 이상 보안 패치가 제공되지 않는 소프트웨어를 운영하게 되는 위험을 피하는 가장 좋은 방법은, 11월 13일 이전에 헬름 v3로의 마이그레이션을 완료하는 것이다.\n\n이 자리를 빌어, 헬름을 사용하거나 개선을 위해 문제를 제기하거나 요청을 제출한 커뮤니티의 모든 분들께 감사드린다. 여러 훌륭한 아이디어들이 헬름에는 맞지 않더라도 [관련 생태계의 프로젝트](/community/related)에서 많은 성공을 거두었다. 문서에 대한 업데이트를 제출할 때마다 다른 사용자들이 헬름을 시작하고 더 효과적으로 사용하는 데 도움이 된다. 모두들 감사합니다!\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/2020-10-07-helm-hub-moving-artifact-hub.md",
    "content": "---\ntitle: \"헬름 허브의 아티팩트 허브로의 이동\"\nslug: \"helm-hub-moving-to-artifact-hub\"\nauthors: [\"mattfarina\"]\ndate: \"2020-10-07\"\n---\n\n오늘 헬름 허브가 [아티팩트 허브](https://artifacthub.io/)로 이동한다. 즉, 헬름 허브로 이동하면 아티팩트 허브로 리다이렉션된다.\n\n## 이것은 무엇을 의미하는가?\n\n헬름 허브를 검색하거나 헬름 허브에서 차트 목록을 조회할 때 의문이 들지도 모르겠다. 무슨 차이가 있는걸까? \n\n아티팩트 허브에서는 헬름 허브에서 조회된 것과 동일한 차트 목록이 모두 조회된다. 더 빠른 검색을 제공하며 [국면 검색](https://en.wikipedia.org/wiki/Faceted_search)을 포함한다. 이전과 비슷한 방식으로 차트를 검색할 수 있다. 검색은 헬름 CLI에서도 계속 작동한다.<!-- truncate -->\n\n아티팩트 허브에는 차트를 검색하는 것 외에도 많은 기능이 있다. 차트가 업데이트되면 이메일 또는 웹훅을 통해 알림을 받을 수 있다. 다른 아티팩트를 찾고 관련 아티팩트를 볼 수 있다. 아티팩트 허브에는 헬름 허브보다도 많은 것을 제공한다.\n\n헬름 허브에 차트 저장소를 나열하고 아티팩트 허브에 아직 나열하지 않은 경우 자동으로 가져온다. 아티팩트 허브는 저장소를 요청하고 새 저장소를 나열하는 수단을 제공한다. 저장소를 나열할 때 사용자 계정 또는 다중 사용자 조직에 연결할 수 있다.\n\n## 왜 이렇게 해야 하는가?\n\n헬름 허브는 모노큘러(Monocular) 프로젝트를 기반으로 구축되었다. 이 프로젝트는 제한된 수의 헬름 저장소를 처리하도록 빌드되었으며, 가능한한 많은 차트 저장소의 공개 목록과 약간 다른 사용 사례를 위해 설계되었다. 헬름 프로젝트를 잘 수행해왔지만, 헬름 차트 및 저장소 수가 증가함에 따라 몇가지 제한 사항들이 나타나기 시작했다.헬름 허브를 사용하여 이 문제에 대해 뭔가를 해야 한다는 것을 우리도 알고 있었다.\n\n우리가 성장에 대한 문제를 경험하기 시작하면서 아티팩트 허브가 등장했다. 아티팩트 허브의 자체 인스턴스를 운영하거나 스케일링 문제를 처리하기 위해 자체 소프트웨어를 작성하는 대신 차트 검색 및 관리를 처리하기 위해 아티팩트 허브를 사용하기로 결정했다. 아티팩트 허브는 단순히 차트만 제공하는 것이 아니라 더 많은 CNCF 생태계를 지원하고 홍보하고 있다.\n\n## 질문, 우려 또는 문제점\n\n만약 전환하다가 문제가 있으면 알려 달라. 알리는 방법은 몇 가지가 있다.\n\n1. 문제가 마이그레이션 간 아티팩트 허브의 차트 저장소에 대한 것이라면, [헬름 허브 저장소](https://github.com/helm/hub)에 이슈를 등록하자.\n2. 아티팩트 허브 사이트에 문제가 있다면 [아티팩트 허브 프로젝트](https://github.com/artifacthub/hub)에 이슈를 등록할 수 있다. 이 곳은 CNCF 프로젝트이자 오픈소스 프로젝트이다.\n3. 헬름 CLI를 사용하여 아티팩트 허브를 검색하는 데 문제가 있는가? [헬름](https://github.com/helm/helm)에 이 이슈를 등록할 수 있다. 차트의 URL은 검색에서 찾을 때 기본적으로 `hub.helm.sh` 로 시작된다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/2020-10-19-helm-turns-five.md",
    "content": "---\ntitle: \"헬름 5주년과 깃헙으로부터의 차트 선물\"\nslug: \"helm-turns-five\"\nauthors: [\"mattbutcher\", \"mattfarina\"]\ndate: \"2020-10-19\"\n---\n\n{{< figure src=\"https://helm.sh/blog/images/happy-5th.png\" alt=\"헬름의 5번째 생일 축하\" >}}\n\n5년 전, Deis(그 후 마이크로스프트에 인수됨)의 해커톤에서 헬름이 탄생했다.\n<!-- truncate -->\n\n```\ncommit ecad6e2ef9523a0218864ec552bbfc724f0b9d3d\nAuthor: Matt Butcher <mbutcher@engineyard.com>\nDate:   Mon Oct 19 17:43:26 2015 -0600\n\n    initial add\n```\n\n[이 커밋](https://github.com/helm/helm-classic/commit/ecad6e2ef9523a0218864ec552bbfc724f0b9d3d)은 헬름 v1 용 코드베이스가 있는 헬름 클래식 깃 저장소에서 찾을 수 있다. \n\n이것은 디플로이먼트 매니저와 병합되어 쿠버네티스에 합쳐지기 전의 원래 헬름이다. 이것이 모든 것이 시작된 곳이다.\n\n첫날부터 헬름 프로젝트는 소스 관리, 풀 요청 관리 및 문제 추적을 위해 깃헙을 사용해왔다. 졸업한 CNCF 프로젝트로서, 헬름 조직은 이제 수십 개의 깃헙 저장소를 운영하고 있다. 하지만 패키징된 차트를 호스팅할 때는, 구글 클라우드에서 호스팅하는 객체 스토리지 버킷에 저장했다. 당시의 이러한 결정은 구글이 헬름의 주요 기여자였다는 점이 반영된 것이다.\n\n최근, 구글의 공식 헬름 차트 저장소 지원기간이 종료되었다. 지난 몇 년동안 구글이 헬름 차트 저장소를 호스팅해준 것에 대해 감사한다. 또한 이 일은 차트 개발 파이프라인을 깃헙과 통합할 수 있는 기회가 되었다.\n\n{{< figure src=\"../images/octocat.png\" alt=\"Hello Github Octocat!\" width=\"350px\" >}}\n\n그래서 오늘의 생일 축하 행사에서,  헬름 `stable` 및 `incubator` 차트 저장소가 깃헙에서 직접 호스팅된다는 것을 알리고자 한다. 또한, 깃헙 액션으로 차트 게시를 위한 파이프라인이 강화되었다. 깃헙의 엄청 빠른 네트워크 덕분에 차트 다운로드가 그 어느 때보다 더욱 빨라졌다!\n\n깃헙 마켓 플레이스에 공식 헬름 깃헙 액션을 게시하였다. 깃헙에서 헬름 차트를 호스팅하는 방법에 대해서는 [헬름 차트 릴리서(Helm Chart Releaser)](https://github.com/marketplace/actions/helm-chart-releaser)를 참고하자.\n\n헬름 2는 지원이 종료되었지만, [공식 틸러 도커 이미지](https://github.com/orgs/helm/packages)는 깃헙의 컨테이너 저장소에도 옮겨 놓았다.\n\n깃헙에서 제공한 도구와 여러 오픈 소스 프로젝트에 대한 지원에 깊이 감사한다.\n\n생일 축하한다, 헬름!\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/2020-10-26-new-location-stable-incubator-charts.md",
    "content": "---\ntitle: \"Stable 및 Incubator 차트를 위한 새로운 공간\"\nslug: \"new-location-stable-incubator-charts\"\nauthors: [\"mattfarina\"]\ndate: \"2020-10-26\"\n---\n\n[이전에 발표한 것과 같이](https://helm.sh/ko/blog/helm-turns-five/), stable 및 incubator 저장소가 새로운 공간으로 이동하게 된다. \n이 게시물은 새로운 위치에 대한 업데이트를 제공하고 그것을 사용하는 방법을 제공한다.<!-- truncate -->\n\n_**중요한 참고사항:** 이는 2019 년에 발표된 stable 및 incubator 저장소의 오래된 타임 라인에 영향을 주지 않는다. \n2020 년 11 월 13 일에 stable 및 incubator 차트 저장소는 개발이 끝나고 아카이브가 된다. \n많은 차트가 커뮤니티에서 관리하는 다른 저장소로 이동했음을 알 수 있다. \n[아티팩트 허브](https://artifacthub.io/)에서 확인할 수 있다. \n노후화에 대한 자세한 정보는 향후 블로그 게시물 및 커뮤니케이션에서 이어질 예정이다._\n\nstable 저장소의 새 위치는 https://charts.helm.sh/stable이고 incubator 저장소의 새 위치는 https://charts.helm.sh/incubator 이다. \n아래의 이전 위치 중 하나에서 차트를 사용하는 경우 2020 년 11 월 13 일 이전에 사용하는 저장소를 업데이트 해야한다. \n새 위치는 깃헙 페이지를 사용하여 호스팅된다.\n\n| 이름        | 이전 위치       | 새 위치        |\n| --------- | ------------ | ------------ |\n| stable    | https://kubernetes-charts.storage.googleapis.com | https://charts.helm.sh/stable |\n| incubator | https://kubernetes-charts-incubator.storage.googleapis.com | https://charts.helm.sh/incubator |\n\n\n새 위치와 함께 헬름 v2.17.0 및 v3.4.0 이 릴리스 되어 새 위치에서 사용할 수 있다. \n최신 버전으로 업그레이드하는 것이 좋다. <!-more->\n\n## 헬름 v3.4.0\n\n헬름 v3.4.0은 이제 이전 위치로 구성된 안정 및 인큐베이터 저장소가 있는지 감지하고 구성을 새 위치로 업데이트해야 함을 경고한다. \n단일 명령을 사용하여 이를 수행 할 수 있다. \n예를 들어 `stable` 이라는 이름으로 설정된 안정적인 저장소를 업데이트하려면 다음을 실행할 수 있다.\n\n```\nhelm repo add stable https://charts.helm.sh/stable --force-update\n```\n\n이 명령은 v3.4.0 이전의 헬름 v3 버전에서도 작동한다. \n최신 헬름 v3 릴리스로 업데이트하지 않고도 사용할 수 있다.\n\n또한 `helm repo add` 를 사용하여 이전 위치에 있는 저장소 중 하나를 추가하려고 하면 Helm v3.4.0 이상 버전은 저장소를 추가하지 못하고 새 위치를 사용하도록 경고한다. \n자동으로 새 위치를 추가하는 대신 사람들에게 위치 변경을 알리고 싶은 의도이다. \n이전 위치 중 하나를 사용해야하는 이유가 있는 경우 새로운 `--allow-deprecated-repos` 플래그를 사용할 수 있다. \n플래그는 이전 위치가 계속 작동하는 동안에만 유용하다.\n\n## 헬름 v2.17.0\n\n헬름 v2 에서는 `helm init` 가 실행될 때 기본적으로 stable 저장소를 추가했다. \n이로 인해 v2.17.0 부터는 헬름 v2 에 대한 다른 솔루션이 도입되었다.\n\nstable 저장소 또는 로컬 저장소가 필요하지 않은 경우 `helm init` 를 실행할 때 `--skip-repos` 플래그를 사용할 수 있다. \n이것은 v2.17.0의 새로운 플래그이다. \n안정적인 저장소를 사용하지 않는 CI 시스템과 같은 일부 사용 사례에서 성능상의 이점이 있을 수 있다.\n\nv2.17.0 에서 `helm init` 가 실행되면 이전 위치 대신 새 위치가 사용된다. \n이것은 정기적으로 `helm init` 를 실행하는 CI 시스템에서 발생한다. \n이전 위치를 계속 사용해야 하는 경우 새로운 `--use-deprecated-stable-repository` 플래그를 `helm init` 에 전달할 수 있습니다. \n이것은 이전 위치가 계속 작동하는 동안에만 작동한다.\n\nstable 또는 incubator 저장소에 대해 구성된 이전 위치가 이미 있는 경우 헬름은 새 위치로 전환해야 한다는 경고를 표시한다. \nHelm v2에서는 작업 수행 시 두 개의 명령을 사용해야 한다는 점에서 \nHelm v3와 약간 다르다. \n예를 들어 `stable` 저장소를 변경하려면 다음을 실행할 수 있다.\n\n```\nhelm repo rm stable\nhelm repo add stable https://charts.helm.sh/stable\n```\n\n이 명령은 v2.17.0 이전의 Helm v2 버전에서 작동한다. \n최신 Helm v2 릴리스로 업데이트 하지 않고도 사용할 수 있다.\n\n_참고 : GitHub 페이지로 이동하는 stable 및 incubator 저장소 외에도 \n[틸러(Tiller)의 기본 위치가 GitHub 컨테이너 저장소 (ghcr.io)로 이동되었다](https://github.com/orgs/helm/packages/container/package/tiller). \n[틸러는 GCR에서 계속 사용할 수 있다](https://gcr.io/kubernetes-helm/tiller) (이전 위치). \n[도커 허브] (https://hub.docker.com/r/helmpack/tiller) 및 [Quay] (http://quay.io/helmpack/tiller)에서도 틸러를 다운로드 할 수 있다. \n틸러의 기본 위치가 아닌 위치를 지정하려면 `helm init`를 실행할 때 `-i` 또는 `--tiller-image` 플래그를 사용할 수 있다._\n\n## 사용자만의 복제본 호스팅 하기\n\n헬름이 네트워크 호출을 할 수 있는 위치를 제어 할 수 있고 \n헬름이 깃헙 페이지를 호출하지 않도록 하는 경우가 있다. \nstable 또는 incubator 저장소의 차트가 필요한 경우 한 가지 옵션은 \n자신의 저장소에 필요한 차트 및 차트 버전의 사본을 호스팅하는 것이다. \n[ChartMuseum] (https://github.com/helm/chartmuseum), [Harbor] (https://goharbor.io/), 정적 웹 서버 또는 다른 시스템으로 이 저장소를 호스팅 할 수 있다.\n\n헬름 조직 및 차트 관리자 중 한 명인 Scott Rigby는 [차트와 기록의 전체 또는 일부를 복사 할 수있는 스크립트](https://github.com/scottrigby/helm-adopt-package-history)를 만들었다(이전 차트 버전). \n이 도구 및 이와 유사한 도구를 사용하여 사용하는 차트의 복사본을 만들 수 있다. \n이것은 다른 위치에서 제공 될 수 있다.\n\n헬름 v2 에서는 `--stable-repo-url` 플래그를 사용하여 `helm init` 를 실행할 때 \n안정적인 저장소의 대체 위치를 지정할 수 있다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/2020-10-30-charts-repo-deprecation.md",
    "content": "---\ntitle: \"헬름 차트 저장소 지원 중단 업데이트\"\nslug: \"charts-repo-deprecation\"\nauthors: [\"viciglesias\"]\ndate: \"2020-10-30\"\n---\n\n2019 년에 헬름 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 개 이상으로 증가하여 저장소에 대한 풀 요청 및 업데이트가 이에 상응하게 증가했다. 안타깝게도 검토 및 유지 관리 작업을 자동화하려는 많은 노력에도 불구하고 관리자의 유지 관리 시간은 단축되지 않았다.<!-- truncate -->\n\n지원 중단을 발표했을 때 우리는 helm/charts repo를 유지하는 데 사용했던 도구와 지침도 공유하기 시작했다. 자체 저장소를 호스팅하고 유지하려는 사람들을 위해 이제 다음 도구를 사용하여 프로세스를 간소화 할 수 있다.\n\n- [차트 테스트](https://github.com/helm/chart-testing)는 차트에 대한 PR 린팅(Linting) 및 테스트를 제공한다.\n- [차트 Releaser](https://github.com/helm/chart-releaser) 는 아티팩트를 호스팅하는 데 사용되는 깃헙 릴리스 및 페이지를 사용하여 자체 차트 저장소를 호스팅 하는데 도움이 되는 도구를 제공한다.\n- [깃헙 동작 테스트 및 릴리징](https://github.com/helm?q=chart+action) 는 위에서 설명한 깃헙 동작을 사용하여 도구를 자동화 한다.\n\n이러한 도구를 사용하여 활성 유지 관리를 위해 많은 차트를 [자체 저장소로 마이그레이션] (https://github.com/helm/charts/issues/21103) 할 수 있다.\n\n## 주요 날짜 및 권장되는 조치\n\n계획이 수정되면서 다음에 일어날 일에 대한 혼란/질문이 있었기에 앞으로 진행할 주요 이벤트 및 ** 권장 조치 **의 타임 라인을 제공하고자 한다.\n\n* 2020년 11월 2일 - 지원 중단되지 않는 모든 차트의 README 에 더 이상 업데이트 되지 않는다는 메모가 추가된다.\n\t* **권장 조치** - 차트 저장소의 차트에 의존하는 경우 새 공식 위치를 찾아야 한다. 존재하지 않을 경우 차트의 적용을 고려하라.\n* 2020년 11월 6일 - [아티팩트 허브](https://artifacthub.io/)에서 stable 및 incubator 차트 저장소가 삭제된다.\n\t* **권장 조치** - 없음\n* 2020년 11월 13일 - [helm/charts 저장소](https://github.com/helm/chart)의 CI가 비활성화되고 더 이상 Pull Request 가 허용되지 않는다.\n\t* **권장 조치** - 차트를 새 저장소로 재배치하기 위한 진행중인 발의(initiative) 대한 자세한 내용은 [이 문제](https://github.com/helm/charts/issues/21103)를 참조하자.\n* 2020년 11월 13일 *이후* - 이전 위치에서 차트를 다운로드하면 GitHub 페이지에서 사용할 수있는 읽기 전용 아카이브로 리디렉션된다. 이 날짜 이후에는 이전 위치를 더 이상 사용할 수 없다.\n\t* **권장 조치** - [보관된 stable 및 incubator 차트로의 전환](https://helm.sh/docs/faq/#i-am-getting-a-warning-about-unable-to-get-an-update-from-the-stable-chart-repository)에 대한 정보를 참조하라. 이 차트는 더 이상 버그 수정이나 보안 패치로 업데이트되지 않는다.\n\n\n## 참조\n\n* [차트 저장소 지원 중단 일정](https://github.com/helm/charts/issues/23944)\n* [패키지 이력 재배치](https://github.com/helm/charts/issues/23850)\n* [헬름 차트 호스팅을 CNCF로 전환하도록 요청](https://github.com/helm/community/issues/114)\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"블로그\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"블로그\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"모든 게시물\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/_v4-in-progress.mdx",
    "content": ":::warning\n이 페이지는 아직 Helm 4에 맞게 업데이트되지 않았습니다. 일부 내용은 Helm 4에 부정확하거나 적용되지 않을 수 있습니다. Helm 4의 새로운 기능, 개선 사항, 그리고 비호환 변경 사항에 대한 자세한 내용은 [Helm 4 개요](/overview.md)를 참고하세요.\n:::"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/changelog.md",
    "content": "---\nsidebar_position: 2\nsidebar_label: 전체 체인지로그\n---\n\n# 헬름4 전체 체인지로그\n\n**범위**: `v3.19.0`과 비교, (`v4.0.0-rc.1`) 기준 290개의 PR  \n**v4 전용**: 257개의 PR (v3로 백포트된 33개의 PR 제외)\n\n이들 변경 사항에 대한 실질적 요약은 [개요](/overview.md)에서 확인하세요.\n\n## 새로운 기능 {#new-features}\n\nv3로 백포트되지 않은 헬름4의 새로운 기능\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31435 | 2025-11-03 | matheuscscp | Introduce a context for canceling wait operations |\n| #31389 | 2025-10-30 | TerryHowe | chore: fix pkg/registry warnings to reduce noise |\n| #31338 | 2025-10-21 | yzewei | Add loongarch64 support |\n| #31351 | 2025-10-21 | gjenkins8 | feat: `helm version` print Kubernetes (client-go) version |\n| #31376 | 2025-10-21 | benoittgt | Do not ignore *.yml file on linting while accepting *.yaml |\n| #31362 | 2025-10-21 | fabiocarneiro | Clarify the intent of the resource instructions |\n| #31392 | 2025-10-16 | TerryHowe | feature: create copilot structured context |\n| #31295 | 2025-10-13 | TerryHowe | Fix make helm list show all by default |\n| #31372 | 2025-10-10 | mattfarina | Enable Releases To Have Multiple Versions |\n| #31254 | 2025-09-23 | benoittgt | Warn when we fallback to a different version on `helm pull` |\n| #31275 | 2025-09-10 | benoittgt | Extend --skip-schema-validation for lint command |\n| #31116 | 2025-09-02 | banjoh | chore: check if go modules are tidy before build |\n| #31217 | 2025-09-01 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Move Postrenderer to a plugin type |\n| #31196 | 2025-08-31 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Remove unnecessary file i/o operations from signing and verifying |\n| #31176 | 2025-08-30 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin packaging, signing, and verification |\n| #31194 | 2025-08-28 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin extism/v1 runtime |\n| #30812 | 2025-08-27 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> HIP-0023: Helm support server-side apply |\n| #31174 | 2025-08-26 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin tarball support for HTTP and local installers |\n| #31172 | 2025-08-26 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin OCI installer |\n| #31146 | 2025-08-23 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin types and plugin apiVersion v1 |\n| #31145 | 2025-08-22 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin runtime interface |\n| #31142 | 2025-08-21 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Move pkg/plugin -> internal/plugin |\n| #31030 | 2025-08-14 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> HIP-0023: Kube client support server-side apply |\n| #12624 | 2025-08-13 | papdaniel | show crds command output separated by document separator |\n| #13111 | 2025-08-13 | rawtaz | style(pkg/chartutil): add missing dots and indentation to defaultValues |\n| #31076 | 2025-08-11 | matheuscscp | pkg/registry: Login option for passing TLS config in memory |\n| #31034 | 2025-08-05 | Mazafard | Feat: Add color output functionality and tests for release statuses |\n| #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 |\n| #31019 | 2025-07-17 | zachburg | Return early when linting if the `templates/` directory does not exist |\n| #31011 | 2025-07-17 | yalosev | feature: add labels to metadata |\n| #31015 | 2025-07-17 | zachburg | Add linter support for the `crds/` directory |\n| #13154 | 2025-07-10 | carloslima | Allow post-renderer to process hooks |\n| #13586 | 2025-06-04 | jessesimpson36 | feat: add formatting for errors to make multiline stacktraces in helm templates |\n| #30553 | 2025-05-07 | Zhanweelee | feat: Add mustToYaml and mustToJson template functions |\n| #30734 | 2025-04-21 | ipaqsa | feat(pkg/engine): add support for custom template funcs |\n| #13283 | 2025-04-14 | win-t | adding support for JSON Schema 2020 |\n| #30751 | 2025-04-13 | benoittgt | Add detailed debug logging for resource readiness states |\n| #30708 | 2025-04-11 | benoittgt | Migrate pkg to slog |\n| #13604 | 2025-04-05 | AustinAbro321 | Introduce kstatus watcher |\n| #13617 | 2025-02-27 | AustinAbro321 | <span class=\"breaking\">BREAKING CHANGE:</span>  Refactor cmd/helm to allow library usage |\n| #30571 | 2025-02-24 | yardenshoham | feat: error out when post-renderer produces no output |\n| #13655 | 2025-02-20 | LuBingtan | feat: support multi-document values files |\n| #13471 | 2025-02-19 | wangjingcun | Use a more direct and less error-prone return value |\n| #30294 | 2025-02-19 | Zhanweelee | Supports json arguments |\n| #13538 | 2025-01-17 | godhanipayal | Add Contextual Error Messages to RunWithContext |\n| #12588 | 2024-11-22 | rynowak | Make the authorizer and registry authorizer configurable |\n\n## 버그 수정 {#bug-fixes}\n\nv3로 백포트되지 않은 헬름4의 버그 수정\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31323 | 2025-10-29 | mattfarina | Reproducible chart archive builds |\n| #31411 | 2025-10-29 | banjoh | fix: reinstate logger parameter to actions package |\n| #31204 | 2025-10-22 | benoittgt | Avoid panic in helm.sh/helm/v3/pkg/chartutil.ValidateAgainstSchema |\n| #31337 | 2025-10-22 | rachelvweber | Fixing rollback and uninstall client WaitStrategy |\n| #31393 | 2025-10-21 | benoittgt | Return errors during upgrade when the deletion of resources fails |\n| #31406 | 2025-10-21 | jessesimpson36 | fix: kube client should return empty results objects instead of nil |\n| #31375 | 2025-10-13 | TerryHowe | fix: release info time parsing |\n| #31349 | 2025-10-07 | TerryHowe | fix: flakey lint test on shuffle |\n| #31327 | 2025-10-07 | TerryHowe | fix: broken `--html` flag to coverage script |\n| #31354 | 2025-10-07 | TerryHowe | fix: flake upgrade test |\n| #31227 | 2025-10-03 | evankanderson | Use filepath.Path when handling directory names |\n| #31307 | 2025-10-02 | TerryHowe | fix: Ignore absolute path when RepoUrl is provided |\n| #31334 | 2025-09-30 | fleaz | Fix typo in bug-report  issue template |\n| #31330 | 2025-09-25 | mattfarina | Restore lint rule for excluding meaningless name |\n| #31320 | 2025-09-25 | kosiew | provenance: allow RSA signing when ed25519 keys are present (switch to ProtonMail/go-crypto) |\n| #31285 | 2025-09-12 | bennsimon | fix: remove leftover debugging line that outputs invalid YAML for helm template command |\n| #31277 | 2025-09-11 | benoittgt | Fix deprecation warning for spf13/pflag from 1.0.7 to 1.0.10 |\n| #31272 | 2025-09-09 | TerryHowe | fix: idea gitignore entry |\n| #31252 | 2025-09-05 | kamilswiec | fix:chartfile tests - semver2 error message |\n| #31199 | 2025-09-05 | TerryHowe | fix: flaky registry data race on mockdns close |\n| #31200 | 2025-09-05 | TerryHowe | fix: installer action goroutine count |\n| #31222 | 2025-09-03 | benoittgt | Prevent failing `helm push` on ghcr.io using standard GET auth token flow |\n| #31191 | 2025-08-26 | TerryHowe | fix: send logging to stderr |\n| #31138 | 2025-08-19 | islewis | fix(helm-lint): Add HTTP/HTTPS URL support for json schema references |\n| #31152 | 2025-08-18 | TerryHowe | fix: enable shuffle in Makefile for unit tests |\n| #12968 | 2025-08-13 | sjeandeaux | helm uninstall dry run support `--ignore-not-found` |\n| #31126 | 2025-08-12 | paologallinaharbur | fix(transport): leverage same tls config |\n| #31109 | 2025-08-06 | carlossg | fix: prevent panic when ChartDownloader.getOciURI |\n| #31074 | 2025-07-18 | joejulian | add missing template directory to badcrdfile testdata |\n| #31042 | 2025-07-10 | TerryHowe | fix: test teardown dns data race |\n| #30898 | 2025-07-06 | AshmitBhardwaj | Fix issue 13198 |\n| #31021 | 2025-07-05 | zachburg | Update tests in create_test.go and package_test.go to work in a temp directory |\n| #31024 | 2025-07-03 | gjenkins8 | fix: 'TestRunLinterRule' stateful test |\n| #30900 | 2025-06-23 | unguiculus | Add timeout flag to repo add and update commands |\n| #30981 | 2025-06-15 | TerryHowe | fix: lint test SetEnv errors |\n| #30973 | 2025-06-12 | manslaughter03 | fix: wrap run release test error in case GetPodLogs failed. |\n| #30972 | 2025-06-10 | TerryHowe | fix: kube client create mutex |\n| #30958 | 2025-06-06 | TerryHowe | fix: repo update cmd mutex |\n| #30955 | 2025-06-04 | carloslima | Fix tests deleting XDG_DATA_HOME |\n| #30939 | 2025-06-03 | TerryHowe | fix: action hooks delete policy mutex |\n| #12581 | 2025-06-03 | MichaelMorrisEst | Consider full GroupVersionKind when matching resources |\n| #30930 | 2025-05-28 | benoittgt | Fix flaky TestFindChartURL due to non-deterministic map iteration |\n| #30884 | 2025-05-21 | mattfarina | Reverting fix \"renders int as float\" |\n| #30862 | 2025-05-20 | OmriSteiner | fix: correctly concat absolute URIs in repo cache |\n| #30864 | 2025-05-16 | jessesimpson36 | fix: remove duplicate error message |\n| #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 |\n| #30800 | 2025-04-25 | mmorel-35 | fix: dep fs errors |\n| #30803 | 2025-04-25 | mattfarina | Fixing windows build |\n| #30783 | 2025-04-23 | rpolishchuk | fix: chart icon presence test |\n| #30777 | 2025-04-23 | ryanhockstad | fix: null merge |\n| #9175 | 2025-04-23 | dastrobu | fix: copy dependencies on aliasing to avoid sharing chart references on multiply aliased dependencies |\n| #12382 | 2025-04-20 | edbmiller | fix(pkg/lint): unmarshals Chart.yaml strictly |\n| #30766 | 2025-04-17 | benoittgt | Fix main branch by defining wait strategy parameter on hooks |\n| #30718 | 2025-04-16 | klihub | Allow signing multiple charts with a single passphrase from stdin. |\n| #30752 | 2025-04-16 | benoittgt | Bump golangci lint to last major version and fix static-check errors |\n| #30737 | 2025-04-11 | rpolishchuk | fix: order dependent test |\n| #9318 | 2025-04-07 | wahabmk | Fix issue with helm pull failing if pulling from a repository that redirects to another domain |\n| #13119 | 2025-04-05 | idsulik | fix(concurrency): Use channel for repoFailList errors in updateCharts |\n| #30618 | 2025-03-04 | AustinAbro321 | Fix namespace flag not registering |\n| #30590 | 2025-03-01 | SantalScript | fix:add proxy support when mTLS configured |\n| #30572 | 2025-02-25 | yardenshoham | fix: error when more than one post-renderer is specified |\n| #30576 | 2025-02-23 | felipecrs | Fix flaky TestDedupeRepos |\n| #30562 | 2025-02-20 | robertsirc | fixing error handling from a previous PR |\n| #13656 | 2025-02-03 | gjenkins8 | fix: Bind repotest server to `localhost` |\n| #13633 | 2025-01-17 | mattfarina | Ensuring the file paths are clean prior to passing to securejoin |\n| #13425 | 2024-11-15 | MathieuCesbron | Fix typo \"re-use\" to \"reuse\" |\n\n## 리팩터링/정리 {#refactorcleanup}\n\n코드 품질 개선 및 현대화\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31440 | 2025-10-29 | mattfarina | Updating Go and golangci-lint versions |\n| #31408 | 2025-10-21 | AndiDog | Improve error message when plugin source cannot be determined or a non-directory is passed |\n| #31390 | 2025-10-21 | TerryHowe | fix: improve pkg/cmd/list test coverage |\n| #31365 | 2025-10-21 | reddaisyy | refactor: use reflect.TypeFor |\n| #31395 | 2025-10-21 | wyrapeseed | chore: fix some comment format |\n| #31401 | 2025-10-17 | TerryHowe | refactor: remove unused err from pkg/registry/client.go |\n| #31391 | 2025-10-15 | TerryHowe | chore: rename test registry |\n| #31302 | 2025-10-13 | TerryHowe | fix: helm verify Run signature |\n| #31270 | 2025-10-13 | TerryHowe | chore: registry utils clean up |\n| #31383 | 2025-10-13 | dirkmueller | Avoid accessing .Items on nil object |\n| #31379 | 2025-10-13 | TerryHowe | fix: clean up coverage script temp file |\n| #30980 | 2025-10-10 | gjenkins8 | cleanup: Remove/consolidate redundant kube client Interfaces |\n| #30712 | 2025-10-10 | gjenkins8 | cleanup: Remove extra lint/rules.Template functions |\n| #30833 | 2025-10-09 | gjenkins8 | refactor/cleanup: Replace action 'DryRun' string with DryRunStrategy type + deprecations |\n| #31326 | 2025-10-07 | TerryHowe | Update sign tests to use testify |\n| #31312 | 2025-10-01 | gjenkins8 | Remove unused 'Settings' from plugin schema |\n| #31143 | 2025-09-25 | TerryHowe | fix: remove redundant error check |\n| #31249 | 2025-09-25 | banjoh | chore: add additional logging to plugin installer |\n| #31321 | 2025-09-24 | juejinyuxitu | chore: fix some typos in comment |\n| #31297 | 2025-09-22 | TerryHowe | fix: hide notes in helm test command |\n| #31315 | 2025-09-22 | benoittgt | Remove unused golangci-lint rules that produce warning |\n| #31294 | 2025-09-19 | TerryHowe | Remove implicit support for helm lint current directory |\n| #31301 | 2025-09-19 | TerryHowe | chore: remove helm version `--client` option |\n| #31303 | 2025-09-18 | mattfarina | Update the action interfaces for chart apiversions |\n| #31198 | 2025-09-16 | TerryHowe | refactor: replace pkg/engine regular expressions with parser |\n| #31293 | 2025-09-16 | TerryHowe | chore: remove pkg/time which is no longer needed |\n| #31287 | 2025-09-16 | miledxz | improve fileutil test coverage |\n| #31292 | 2025-09-16 | reddaisyy | refactor: use strings.builder |\n| #31286 | 2025-09-12 | yajianggroup | refactor: use strings.CutPrefix |\n| #31258 | 2025-09-08 | StephanieHhnbrg | Refactor unreachableKubeClient for testing into failingKubeClient |\n| #31259 | 2025-09-07 | StephanieHhnbrg | Adapt test-coverage command to be able to run for a certain package |\n| #31225 | 2025-09-02 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move lint pkg to be part of each chart version |\n| #31220 | 2025-09-02 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> refactor: utilize `pluginTypesIndex` for config unmarshalling  |\n| #31219 | 2025-09-02 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove 'SetupPluginEnv' |\n| #31216 | 2025-09-02 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move to versioned packages |\n| #31224 | 2025-09-01 | gjenkins8 | fix: Adjust PostRenderer plugin output to value |\n| #31218 | 2025-09-01 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove legacy Command/Hooks from v1 Subprocess (#23) |\n| #31151 | 2025-08-30 | TerryHowe | fix: make file whitespace |\n| #31178 | 2025-08-28 | mattfarina | Add content cache to helm env |\n| #31165 | 2025-08-22 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Initial addition of content based cache |\n| #13629 | 2025-08-22 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Rename 'atomic' -> 'rollback-on-failure' |\n| #31175 | 2025-08-21 | cuiweixie | pkg/register: refactor to use atomic.Uint64 |\n| #31132 | 2025-08-19 | joemicky | refactor: replace []byte(fmt.Sprintf) with fmt.Appendf  |\n| #31133 | 2025-08-14 | joemicky | refactor: replace HasPrefix+TrimPrefix with CutPrefix |\n| #31134 | 2025-08-14 | joemicky | refactor: omit unnecessary reassignment |\n| #11700 | 2025-08-13 | suzaku | Refactor, use sort.Slice to reduce boilerplate code |\n| #31058 | 2025-08-07 | farazkhawaja | Add test coverage for get_values/metadata.go |\n| #31107 | 2025-08-06 | Pavanipogula | test(pkg/kube): Add unit tests to wait and roundtripper files. |\n| #31106 | 2025-08-05 | irikeish | test(pkg/kube): add test for Client.isReachable |\n| #30982 | 2025-08-05 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Rename 'force' to 'force-replace' |\n| #31094 | 2025-08-04 | mikelolasagasti | chore(deps): remove phayes/freeport module |\n| #31101 | 2025-07-30 | banjoh | feat: switch yaml library to go.yaml.in/yaml/v3 |\n| #31081 | 2025-07-25 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Initial addition of v3 charts |\n| #31079 | 2025-07-22 | gjenkins8 | cleanup: Remove plugin deprecated 'UseTunnelDeprecated' |\n| #31060 | 2025-07-18 | yumeiyin | refactor: replace Split in loops with more efficient SplitSeq |\n| #31065 | 2025-07-15 | TerryHowe | chore: improve OCI debug logging |\n| #31033 | 2025-07-14 | navinag1989 | test: increase test coverage for pkg/cli/options.go file |\n| #31029 | 2025-07-07 | gjenkins8 | chore(refactor): Privatize 'k8sYamlStruct' |\n| #31023 | 2025-07-03 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove deprecated '--create-pods' flag |\n| #31009 | 2025-07-02 | tpresa | test: increase test coverage for pkg/pusher |\n| #31018 | 2025-07-01 | mattfarina | Move logging setup to be configurable |\n| #30909 | 2025-06-03 | jinjiadu | refactor: replace HasPrefix+TrimPrefix with CutPrefix |\n| #30809 | 2025-06-03 | mmorel-35 | chore: enable usetesting linter |\n| #30865 | 2025-05-22 | mmorel-35 | refactor: update json-patch import path and add gomodguard settings |\n| #30871 | 2025-05-20 | gjenkins8 | Run test OCI registry localhost |\n| #30866 | 2025-05-20 | mmorel-35 | chore: enable thelper linter |\n| #30863 | 2025-05-16 | mattfarina | Adding test for list command |\n| #30850 | 2025-05-12 | yetyear | refactor: use maps.Copy for cleaner map handling |\n| #30829 | 2025-05-09 | TerryHowe | Increase pkg/time test coverage |\n| #30810 | 2025-05-08 | mmorel-35 | chore: enable usestdlibvars linter |\n| #30844 | 2025-05-08 | TerryHowe | fix: rename slave replica |\n| #30827 | 2025-05-06 | findnature | refactor: use slices.Contains to simplify code |\n| #13460 | 2025-04-23 | justenstall | fix: replace \"github.com/pkg/errors\" with stdlib \"errors\" package |\n| #30788 | 2025-04-23 | stephenpmurray | ref(helm): Export Chart Not Found error |\n| #30781 | 2025-04-22 | mmorel-35 | chore: remove `github.com/hashicorp/go-multierror` dependency |\n| #13578 | 2025-04-18 | gjenkins8 | refactor: Remove ChartRepository `[]ChartPaths` |\n| #30760 | 2025-04-16 | robertsirc | adding slog debug to a few points |\n| #30713 | 2025-04-11 | gjenkins8 | cleanup: Remove Helm v2 template lint rules |\n| #30749 | 2025-04-11 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Removing the alpine test chart |\n| #30686 | 2025-04-11 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Remove deprecated code |\n| #30736 | 2025-04-09 | robertsirc | manually updating go.mod file |\n| #13458 | 2025-04-05 | thudi | <span class=\"breaking\">BREAKING CHANGE:</span> #13449 Resolves: Replacing NewSimpleClientSet to NewClientSet due to deprecation |\n| #30684 | 2025-03-21 | twz123 | Remove ClientOptResolver from OCI Client |\n| #30603 | 2025-03-21 | robertsirc | converting inline log to slog |\n| #30699 | 2025-03-21 | mattfarina | Error when failed repo update. |\n| #30592 | 2025-02-28 | robertsirc | changing from log to slog |\n| #30589 | 2025-02-26 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move pkg/release to pkg/release/v1 to support v3 charts |\n| #30586 | 2025-02-25 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move pkg/chart to pkg/chart/v2 to prepare for v3 charts |\n| #30585 | 2025-02-25 | robertsirc | removing old apis |\n| #30580 | 2025-02-24 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move pkg/releaseutil to pkg/release/util |\n| #11112 | 2025-02-22 | felipecrs | perf(dep-up): do not update the same repo multiple times |\n| #30567 | 2025-02-21 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Moving chartutil to chart/util |\n| #30566 | 2025-02-21 | robertsirc | remove unused config.go |\n| #30470 | 2025-02-19 | gjenkins8 | Cleanup `repotest.Server` constructors |\n| #30550 | 2025-02-19 | mattfarina | Moving to SetOut and SetErr for Cobra |\n| #30546 | 2025-02-19 | hugehope | refactor: using slices.Contains to simplify the code |\n| #13535 | 2025-02-05 | gjenkins8 | refactor: tlsutil use options pattern |\n| #13665 | 2025-02-05 | gjenkins8 | chore: Remove unused `WaitAndGetCompletedPodPhase` |\n| #13579 | 2025-02-05 | gjenkins8 | refactor: Remove duplicate `FindChartIn*RepoURL` functions |\n| #13516 | 2025-01-24 | TerryHowe | chore: fix problems with latest lint |\n| #13494 | 2025-01-18 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove deprecated `repo add --no-update` flag |\n| #13602 | 2025-01-17 | crystalstall | refactor: using slices.Contains to simplify the code |\n| #13600 | 2025-01-14 | gjenkins8 | cleanup: `NewShowWithConfig` -> `NewShow` |\n| #13601 | 2025-01-09 | gjenkins8 | cleanup: Remove superseded 'lint/rules.Values' function |\n| #13611 | 2025-01-07 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Updating the internal version to v4 |\n| #13576 | 2025-01-07 | gjenkins8 | refactor: Consolidate lint package Run() functions |\n| #13577 | 2025-01-07 | gjenkins8 | refactor: Remove redundant `NewPullWithOpts` |\n| #13599 | 2025-01-07 | gjenkins8 | cleanup: `ProcessDependenciesWithMerge` -> `ProcessDependencies` |\n| #13573 | 2024-12-27 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Updating to helm.sh/helm/v4 |\n| #13444 | 2024-12-07 | justenstall | refactor(status): remove --show-desc and --show-resources flags |\n\n## 기타 {#other}\n\n인프라 및 프로젝트 관리 개선\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31197 | 2025-09-03 | tzchenxixi | chore: fix function name |\n| #31150 | 2025-08-18 | TerryHowe | Feature add stale pr workflow |\n| #31149 | 2025-08-18 | TerryHowe | fix: stale issue workflow |\n| #31077 | 2025-07-21 | gaspergrom | fix: LFX health score badge link |\n| #31047 | 2025-07-10 | jingchanglu | chore: fix typo in pkg/repo/chartrepo.go |\n| #31004 | 2025-06-26 | andreped | fix(docs): Typofix in README |\n| #31002 | 2025-06-26 | curlwget | chore: fix function in comment |\n| #30912 | 2025-06-17 | Bhargavkonidena | Fix #30893 - issue templates |\n| #30957 | 2025-06-04 | acceptacross | chore: fix some function names in comment |\n| #30914 | 2025-05-27 | benoittgt | Fix dependabot upgrade of jsonschema to v6.0.2 |\n| #30904 | 2025-05-23 | benoittgt | [Doc] Help users avoid specifying URL scheme and path with `helm registry` |\n| #30882 | 2025-05-20 | caniszczyk | Add new LFX Insights Health Score Badge |\n| #30872 | 2025-05-20 | benoittgt | Bump golangci-lint version to match last golangci-lint-action |\n| #30824 | 2025-05-05 | adharsh277 | Fix bug in .golangci.yml configuration |\n| #30786 | 2025-04-25 | mmorel-35 | refactor: reorganize .golangci.yml for better clarity and structure |\n| #30785 | 2025-04-23 | mmorel-35 | fix: govulncheck workflow |\n| #30784 | 2025-04-22 | scottrigby | chore(OWNERS): Add TerryHowe as Triage Maintainer |\n| #30773 | 2025-04-18 | wangcundashang | chore: fix function name in comment |\n| #30754 | 2025-04-16 | mattfarina | Simplify the JSON Schema checking |\n| #30693 | 2025-03-20 | linghuying | chore: make function comment match function name |\n| #30665 | 2025-03-13 | mattfarina | Updating to 0.37.0 for x/net |\n| #30611 | 2025-03-04 | gjenkins8 | chore: Remove 'coveralls' |\n| #30612 | 2025-03-04 | gjenkins8 | fix: Fix go report card badge reference/link |\n| #30508 | 2025-02-19 | eimhin-rover | Update version option description with more accurate info |\n| #30497 | 2025-02-12 | robertsirc | adding-my-key |\n| #30295 | 2025-02-07 | edithturn | Add Percona to the list of organizations using Helm |\n| #13653 | 2025-01-23 | petercover | chore: fix some comments |\n| #13625 | 2025-01-13 | shahbazaamir | ading info to install helm , referring the documentation |\n| #13563 | 2024-12-21 | gjenkins8 | Run `build-test` action on `dev-v3` branch |\n| #13552 | 2024-12-20 | gjenkins8 | Fix `dependabot.yml` `target-branch` typo |\n| #13529 | 2024-12-15 | godhanipayal | Adding Oracle to the adopters list |\n| #13509 | 2024-12-06 | gjenkins8 | Dependabot update `dev-v3` branch go modules |\n| #13212 | 2024-12-01 | mbianchidev | Update ADOPTERS.md |\n| #13465 | 2024-11-20 | banjoh | Add precommit config to .gitignore |\n| #13443 | 2024-11-15 | mattfarina | Updating docs around v3 and v4 |\n\n## v3로도 백포트된 v4 변경 사항 {#v4-changes-also-backported-to-v3}\n\n이 PR들은 v4에 포함됐지만 v3 릴리즈에도 백포트되었습니다.\n\n### (백포트된) 새로운 기능 {#new-features-backported}\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #30696 | 2025-03-24 | benoittgt | Inform about time spent waiting resources to be ready in slog format |\n| #12912 | 2025-03-11 | hegerdes | feat: add httproute from gateway-api to create chart template |\n| #10309 | 2025-02-21 | Bez625 | Add hook annotation to output hook logs to client on error |\n| #13481 | 2025-02-18 | banjoh | feat: Enable CPU and memory profiling |\n| #12690 | 2025-01-01 | TerryHowe | feat: OCI install by digest |\n| #13232 | 2024-12-20 | dnskr | ref(create): don't render empty resource fields |\n| #12962 | 2024-12-04 | stevehipwell | feat: Added multi-platform plugin hook support |\n| #13343 | 2024-11-19 | niladrih | Add annotations and dependencies to get metadata output |\n\n### (백포트된) 버그 수정 {#bug-fixes-backported}\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #31064 | 2025-09-05 | kamilswiec | lint: throw warning when chart version is not semverv2 |\n| #31156 | 2025-08-22 | estroz | fix: set repo authorizer in registry.Client.Resolve() |\n| #30992 | 2025-08-18 | TerryHowe | fix: force bearer oauth for if registry requests bearer auth |\n| #31115 | 2025-08-18 | banjoh | fix: use username and password if provided |\n| #30891 | 2025-08-13 | gjenkins8 | fix: Port pluginCommand & command warning |\n| #31050 | 2025-08-08 | heyLu | Fix `helm pull` untar dir check with repo urls |\n| #31078 | 2025-07-24 | 8tomat8 | fix: k8s version parsing to match original |\n| #30979 | 2025-06-17 | TerryHowe | fix: OAuth username password login for v4 |\n| #30917 | 2025-06-01 | TerryHowe | fix: add debug logging to oci transport |\n| #30937 | 2025-05-30 | TerryHowe | fix: legacy docker support broken for login |\n| #30928 | 2025-05-28 | TerryHowe | fix: plugin installer test with no Internet |\n| #30905 | 2025-05-23 | robertsirc | forward porting 30902 |\n| #30894 | 2025-05-23 | benoittgt | Prevent push cmd failure in 3.18 by handling version tag resolution in ORAS memory store |\n| #30697 | 2025-04-17 | p-se | Fix --take-ownership for custom resources - closes #30622 |\n| #30673 | 2025-04-16 | nvanthao | fix: Process all hook deletions on failure |\n| #30701 | 2025-04-11 | zanuka | updates mutate and validate web hook configs |\n| #13583 | 2025-01-15 | jiashengz | fix: check group for resource info match |\n\n### (백포트된) 리팩토링/정리 {#refactorcleanup-backported}\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #30677 | 2025-04-18 | dongjiang1989 | chore: Update Golang to v1.24 |\n| #30741 | 2025-04-11 | benoittgt | Bumps github.com/distribution/distribution/v3 from 3.0.0-rc.3 to 3.0.0 |\n| #13382 | 2025-02-03 | TerryHowe | chore(oci): migrate to ORAS Golang library v2 |\n| #13546 | 2024-12-19 | mattfarina | Update to Go 1.23 |\n| #13499 | 2024-12-06 | gjenkins8 | Shadow ORAS remote.Client interface |\n\n### (백포트된 기타) {#other-backported}\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n| #30775 | 2025-04-19 | benoittgt | Bump toml |\n| #13533 | 2025-01-24 | althmoha | fix: (toToml) renders int as float |\n| #13581 | 2024-12-31 | ldlb9527 | Upgrade golang.org/x/net to v0.33.0 to address CVE-2024-45338 |\n\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/index.mdx",
    "content": "---\ntitle: \"문서 홈\"\ndescription: \"문서 구성에 관해 알아야 할 모든 것\"\nsidebar_position: 1\n---\n\n# 환영합니다\n\n[헬름](https://helm.sh/) 문서에 오신 것을 환영합니다. \n헬름은 쿠버네티스 패키지 관리자이며, 자세한 배경 정보는 \n[CNCF 헬름 프로젝트 여정 보고서](https://www.cncf.io/cncf-helm-project-journey/)에서 \n확인할 수 있습니다.\n\nimport DocCardList from \"@theme/DocCardList\";\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/overview.md",
    "content": "---\nsidebar_position: 1\nsidebar_label: 헬름 4 개요\n---\n\n# 헬름 4 개요\n\n헬름 v4는 v3으로부터의 중대한 진화를 표하는 버전으로 차트에의 하위 호환성을 유지하는 한편으로 비호환적  변경사항, 새로운 아키텍처 패턴, 그리고 향상된 기능성을 도입합니다.\n\n헬름 4 출시 단계별 계획에 대한 자세한 내용은 [헬름 v4로의 여정](https://helm.sh/blog/path-to-helm-v4/)를 참고해주세요.\n\n## 무엇이 새로운가 {#whats-new}\n\n이 섹션에서는 비호환적 변경사항, 주요 신기능, 기타 개선 사항을 포함하여 헬름 4에서 무엇이 새로운지를 간략히 개괄합니다. 전체 기술 세부 정보는 [전체 변경 로그](./changelog.md)를 참조하세요.\n\n### 요약 {#summary}\n\n- **새 기능**: Wasm 기반 플러그인, kstatus 감시자, OCI 다이제스트 지원, 다중 문서 값, JSON 인수\n- **아키텍처 변경**: 플러그인 시스템 전면 재설계, 패키지 구조 개편, CLI 플래그 이름 변경, 버전 관리 패키지로 전환, 차트 v3 지원, 콘텐츠 기반 캐싱\n- **현대화**: slog 마이그레이션, Go 1.24 업데이트, 의존성 정리\n- **보안**: OCI/레지스트리 지원 강화, TLS 개선\n\n### 비호환적 변경사항 {#breaking-changes}\n\n#### 플러그인으로 구현된 포스트 렌더러 {#post-renderers-implemented-as-plugins}\n포스트 렌더러가 플러그인으로 구현됩니다. 이 변경과 함께 helm render --post-renderer에 실행 파일을 직접 전달하는 건 불가능해지며, 이후부터는 플러그인 이름을 전달해줘야 합니다. 이 변경으로 인해 기존 포스트 렌더러 워크플로우에 업데이트가 필요할 수도 있습니다.\n\n#### 레지스트리 로그인은 전체 URL을 허용하지 않음 {#registry-login-does-not-accept-full-urls}\nv4에서 `helm registry login` 명령은 반드시 도메인명으로 실행해야 합니다.\n이는 향후 레지스트리의 다양한 수준에서 로그인 범위를 지정할 수 있게 하기 위함입니다.\n\n### 새로운 기능 {#new-features}\n\n#### 플러그인 시스템 전면 개편 {#plugin-system-overhaul}\n헬름 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)을 참고하세요.\n\n:::tip\n기존 플러그인은 이전과 동일하게 동작합니다. 새로운 WebAssembly 런타임은 선택 사항이지만 보안 강화를 위해 권장됩니다.\n:::\n\n#### 향상된 리소스 모니터링 {#better-resource-monitoring}\n신규 kstatus 통합이 배포 상태를 더 상세하게 제공합니다. 이슈를 더 잘 포착하는지 복잡한 애플리케이션으로 테스트해보세요.\n\n#### 향상된 OCI 지원 {#enhanced-oci-support}\n공급망 보안 강화를 위해 다이제스트로 차트를 설치할 수 있습니다. 예를 들어 `helm install myapp oci://registry.example.com/charts/app@sha256:abc123...`와 같이 사용합니다. 다이제스트가 일치하지 않는 차트는 설치되지 않습니다.\n\n#### 다중 문서 값 {#multi-document-values}\n복잡한 값을 여러 개의 YAML 파일로 분리하여 관리하세요. 다양한 환경 설정을 테스트하는 데 용이합니다.\n\n#### 서버 사이드 Apply {#server-side-apply}\n여러 도구가 동일한 리소스를 관리할 때 충돌을 더 효과적으로 해결할 수 있습니다. 오퍼레이터나 다른 컨트롤러가 있는 환경에서 테스트해보세요.\n\n헬름4는 새로운 차트 릴리즈를 설치할 때 기본적으로 서버 사이드 apply를 사용합니다.\n\n업그레이드(또는 롤백)을 할 때는 기본적으로 이전 릴리즈의 apply 방식을 따릅니다.\n이러한 래칭 동작은 클라이언트 사이드 apply를 사용하던 기존 릴리즈의 운영 연속성을 보장하기 위한 의도입니다.\n`--server-side` 플래그를 명시적으로 설정하여 이 동작을 오버라이드할 수 있습니다.\n\n그러한 맥락에서 헬름3에 의해 생성된 모든 릴리즈는 헬름4로 업그레이드한 이후에도 기본적으로 클라이언트 사이드 apply를 사용할 것입니다.\n\n#### 사용자 정의 템플릿 함수 {#custom-template-functions}\n플러그인을 통해 추가한 자체 함수로 헬름의 템플릿 기능을 확장할 수 있습니다. 조직별 템플릿 요구사항에 적합합니다.\n\n#### 플러그인으로서의 포스트 렌더러 {#post-renderers-as-plugins}\n포스트 렌더러가 플러그인으로 구현되어 더 나은 통합성과 추가적인 기능을 제공합니다.\n\n#### 안정화된 SDK API (Stable SDK API) {#stable-sdk-api}\n\nAPI에 관해 호환성이 깨지는 변경 작업이 전부 완료되었습니다. 자유롭게 테스트하고, 문제를 발견하면 피드백을 보내주세요! 또한 이 API는 추가적인 차트 버전을 지원하여, 향후 출시될 차트 v3에서 새로운 기능을 도입할 수 있는 기반을 제공합니다.\n\n#### 차트 v3 {#charts-v3}\n\n곧 출시 예정입니다. v2 차트는 변경 없이 계속 사용할 수 있습니다.\n\n### 개선사항 {#improvements}\n\n#### 성능 {#performance}\n\n더 빠른 의존성 해결, 새로운 콘텐츠 기반 차트 캐싱을 제공합니다.\n\n#### 에러 메시지 {#error-messages}\n\n더 명확하고 유용한 에러 출력을 제공합니다.\n\n#### 레지스트리 인증 {#registry-authentication}\n\n프라이빗 레지스트리를 위한 향상된 OAuth 및 토큰 지원을 제공합니다.\n\n#### CLI 플래그 이름 변경 {#cli-flags-renamed}\n\n동작을 더 명료하게 표현하기 위해 일부 CLI 플래그명이 변경됐습니다.\n기존 플래그는 그대로 유지되지만, deprecated 경고가 출력될겁니다.\n\n- `--atomic` → `--rollback-on-failure`\n- `--force` → `--force-replace`\n\n이름이 변경된 이들 CLI 플래그를 사용하는 자동화 스크립트가 있다면 업데이트해주세요.\n\n## 헬름4로 업그레이드하기 {#upgrading-to-helm-4}\n\n헬름4를 사용자 모두에게 안정적으로 제공하고자 최선을 다하고 있다고 할지라도 헬름4는 완전히 새로운 버전입니다. 이를 고려하여, 기존 워크플로우에서 헬름4를 테스트할 때 업그레이드 전 주의해야 할 몇 가지 팁을 아래 정리해뒀습니다. 항상 그렇듯 잘 동작하는 사항, 문제가 발생하는 사항, 그리고 개선이 필요한 사항에 관한 모든 피드백을 환영합니다.\n\n### 최우선 고려사항 {#high-priority}\n* 기존 Chart와 릴리즈를 테스트하여 v4에서도 정상적으로 동작하는지 확인하세요.\n* 세 가지 플러그인 유형(CLI, getter, post-renderer)을 모두 테스트하세요.\n* 새로운 런타임으로 WebAssembly 플러그인 빌드를 시도해 보세요 (참고: [example plugins](https://github.com/scottrigby/h4-example-plugins))\n* SDK 사용자: 안정화된 API를 테스트해 보세요. 문제를 발견하면 피드백을 공유해 주세요.\n* CI/CD 파이프라인을 테스트하고, 이름이 변경된 CLI 플래그로 인한 스크립트 오류를 수정하세요.\n* 포스트 렌더러 통합을 테스트하세요.\n* OCI 워크플로우에서 레지스트리 인증 및 차트 설치를 테스트하세요.\n\n### 그 외 {#other}\n* 다중 문서 값 설정, 다이제스트 기반 설치, 사용자 정의 템플릿 함수 등 기타 새로운 기능도 테스트해보세요.\n* 크고 복잡한 Chart를 사용하여 헬름4의 성능을 테스트해보고 기존 워크로드에 대비해 눈에 띄게 빨라졌는지 확인해보세요.\n* 의도적으로 고장내어 업데이트된 에러 메시지가 도움되는지 확인해보세요.\n\n### 피드백 {#feedback}\n\n* 헬름의 코어 기능을 커스터마이징하기 위해 어떤 플러그인 유형이 추가되어야 한다고 생각하시나요?\n* API가 추가적인 차트 버전을 지원하게 된 만큼, 차트 v3에서 어떤 새로운 기능을 기대하시나요?\n\n## 피드백 제공 방법 {#how-to-give-feedback}\n\n이슈를 발견하셨나요? 제안이 있으신가요? 11월 릴리즈 전 여러분의 의견을 듣고 싶습니다:\n\n### 깃헙 이슈 {#github-issues}\n\n헬름 저장소의 [열린 이슈 및 기능 요청 목록](https://github.com/helm/helm/issues)을 확인하세요. 기존 항목에 댓글을 추가하거나, 새로운 이슈 및 요청을 [생성](https://github.com/helm/helm/issues/new/choose)하세요.\n\n### 커뮤니티 슬랙 {#community-slack}\n[쿠버네티스 슬랙](https://slack.kubernetes.io/) 채널에 참여하세요:\n- 개발 관련 논의는 `#helm-dev`\n- 사용자 지원 및 테스트 피드백은 `#helm-users`\n\n### 주간 개발자 미팅 {#weekly-dev-meetings}\n\n매주 목요일 오전 9시 30분에 [Zoom](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09)에서 유지관리자들과 함께하는 라이브 토론에 참여하세요.\n\n더 다양한 참여 방법은 Helm 커뮤니티의 [커뮤니케이션 안내](https://github.com/helm/community/blob/main/communication.md)를 참고하세요.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/plugins/developer/index.mdx",
    "content": "---\ntitle: 플러그인 개발자 가이드\nsidebar_position: 3\n---\n\nimport DocCardList from \"@theme/DocCardList\";\n\n헬름 플러그인의 개념, 그리고 어떻게 플러그인을 설계하고 설정하는지 개요는 [플러그인 개요](/plugins/overview.md)를 참고하세요.\n\n이번 섹션은 헬름 플러그인 개발에 초점을 두며 [튜토리얼](#tutorials), 사용법 가이드, 레퍼런스 가이드, 헬름 플러그인 작성에 관한 추가적인 개발자용 정보를 포함하고 있습니다.\n\n:::info\n플러그인 시스템 코드베이스 소개를 위해 문서의 [Go SDK](/sdk/index.mdx) 섹션에 곧 플러그인 페이지가 추가될 예정입니다!\n:::\n\n## 튜토리얼 {#tutorials}\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-cli-plugin.mdx",
    "content": "---\ntitle: \"튜토리얼: CLI 플러그인 빌드하기\"\n---\n\nimport GetVersion from \"@site/src/components/GetVersion\";\nimport CodeBlock from \"@theme/CodeBlock\";\n\n시스템 정보를 표시하는 `helm system-info` 명령어를 만들어봅시다.\n\n## 서브프로세스 런타임 {#subprocess-runtime}\n\n서브프로세스 런타임으로 CLI 플러그인을 만드는데서 시작합니다.\n\n### 사전 요구 사항 {#prerequisites}\n\n1. 최신 헬름4 릴리즈를 설치하세요: **<GetVersion majorVersion=\"4\" label={false} link={true} />**\n2. 터미널 세션에서 다운로드한 릴리즈에 관해서 `helm`을 별칭으로 설정하세요. 이제 `helm version --short`를 실행하면 해당 터미널 세션에서 올바른 Helm 버전이 표시됩니다.\n\n### 1. 플러그인 디렉터리 생성 {#1-create-plugin-directory}\n\n파일 시스템의 어디에서나 생성할 수 있습니다. 예를 들어:\n\n```bash\nmkdir -p $HOME/code/helm/plugins/system-info\ncd $HOME/code/helm/plugins/system-info\n```\n\n### 2. 플러그인 매니페스트 생성 {#2-create-plugin-manifest}\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: cli/v1\nname: \"system-info\"\nversion: \"0.1.0\"\nruntime: subprocess\nconfig:\n  usage: system-info\n  shortHelp: Display system and Helm information\n  longHelp: Shows OS info, Helm version, and environment details\nruntimeConfig:\n  platformCommand:\n    - command: ${HELM_PLUGIN_DIR}/system-info.sh\n```\n\n### 3. 스크립트 생성 {#3-create-script}\n\n```bash title=\"system-info.sh\" showLineNumbers\n#!/bin/bash\n\necho \"=== System Information ===\"\necho \"OS: $(uname -s)\"\necho \"Architecture: $(uname -m)\"\n\necho \"\"\necho \"=== Helm Information ===\"\necho \"Plugin Dir: $HELM_PLUGIN_DIR\"\necho \"Arguments: $*\"\n\necho \"\"\necho \"System info complete!\"\n```\n\n실행 가능하도록 설정합니다:\n\n```bash\nchmod +x system-info.sh\n```\n\n### 4. 개발 모드로 설치 및 테스트 {#4-install-in-dev-mode-and-test}\n\n파일 시스템에서 플러그인을 설치하면 로컬 개발 모드로 설치됩니다. 이 경우 출처 확인 및 검증을 건너뜁니다:\n\n```bash\n% helm plugin install $HOME/code/helm/plugins/system-info\nInstalling plugin from local directory (development mode)\nInstalled plugin: system-info\n```\n\n로컬 개발 모드 설치는 소스 디렉터리에서 플러그인 디렉터리로 심볼릭 링크를 생성하므로, 원하는 위치에서 계속 개발할 수 있습니다. 내부 환경 변수 `HELM_PLUGINS`로 디렉터리 위치를 나열하여 심볼릭 링크를 확인할 수 있습니다:\n\n```bash\n% ls -lah $(helm env HELM_PLUGINS)\ntotal 0\ndrwxr-xr-x@ 3 r6by  staff    96B Nov 10 02:18 .\ndrwxr-xr-x@ 3 r6by  staff    96B Jan 21  2025 ..\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info\n```\n\n설치된 플러그인의 `helm plugin list`에서 플러그인 세부 정보를 확인할 수 있습니다:\n\n```bash\n% helm plugin list\nNAME       \tVERSION\tTYPE  \tAPIVERSION\tPROVENANCE\tSOURCE\nsystem-info\t0.1.0  \tcli/v1\tv1        \tlocal dev \tunknown\n```\n\n`helm help`의 사용 가능한 명령어 목록에서도 플러그인을 확인할 수 있으며, `plugin.yaml`에 정의한 플러그인 자체의 도움말 메시지도 볼 수 있습니다:\n\n```bash\n% helm help | grep system-info\n  system-info Display system and Helm information\n\n% helm help system-info\nShows OS info, Helm version, and environment details\n\nUsage:\n  helm system-info [flags]\n```\n\nCLI 서브커맨드를 실행해봅시다:\n\n```bash\n% helm system-info\n=== System Information ===\nOS: Darwin\nArchitecture: arm64\n\n=== Helm Information ===\nPlugin Dir: /Users/r6by/Library/helm/plugins/system-info\nArguments:\n\nSystem info complete!\n```\n\n만들어냈습니다. 서브프로세스 런타임을 사용하는 CLI 플러그인을!\n\n다시 한 번 해봅시다. 이번에는 WASM 런타임으로...\n\n## WASM 런타임 {#wasm-runtime}\n\n### 사전 요구 사항 {#prerequisites}\n\n- [서브프로세스 런타임](#subprocess-runtime)의 사전 요구 사항\n- Go 1.25 설치\n\n:::warning\nTo-do: 섹션 추가 필요\n:::\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-getter-plugin.mdx",
    "content": "---\ntitle: \"튜토리얼: Getter 플러그인 만들기\"\n---\n\nimport GetVersion from \"@site/src/components/GetVersion\";\n\n시스템 정보를 표시하는 `helm system-info` 명령어를 만들어봅시다.\n\n## 서브프로세스 런타임 {#subprocess-runtime}\n\n서브프로세스 런타임을 사용하여 Getter 플러그인을 만들어봅시다.\n\n### 사전 요구 사항 {#prerequisites}\n\n1. 최신 헬름4 릴리즈를 설치하세요: **<GetVersion majorVersion=\"4\" label={false} link={true} />**\n2. 터미널 세션에서 다운로드한 릴리즈에 관해서 `helm`을 별칭으로 설정하세요. 이제 `helm version --short`를 실행하면 해당 터미널 세션에서 올바른 Helm 버전이 표시됩니다.\n\n### 1. 플러그인 디렉터리 생성 {#1-create-plugin-directory}\n\n파일 시스템의 어디에서나 생성할 수 있습니다. 예를 들어:\n\n```bash\nmkdir -p $HOME/code/helm/plugins/demo-getter\ncd $HOME/code/helm/plugins/demo-getter\n```\n\n### 2. 플러그인 매니페스트 생성 {#2-create-plugin-manifest}\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: getter/v1\nname: demo-getter\nversion: 0.1.0\nruntime: subprocess\nconfig:\n  protocols: [\"demo\"]\nruntimeConfig:\n  protocolCommands:\n    - protocols:\n        - demo\n      platformCommand:\n        - command: get-demo.sh\n```\n\n### 3. 스크립트 생성 {#3-create-script}\n\nGetter 플러그인은 패키지된 아티팩트(이 경우 차트)를 가져오거나 다운로드하고, 다운로드된 패키지의 경로를 반환하는 역할을 합니다. 데모 목적으로 시스템 유틸리티를 사용하여 임시 디렉터리를 만들고(시간이 지나면 자동으로 정리됩니다), `helm create`와 `helm package` 명령어로 임시 디렉터리에 데모 차트 패키지를 생성한 후 패키지 경로를 반환해봅시다:\n\n```bash title=\"get-demo.sh\" showLineNumbers\n#!/usr/bin/env sh\nset -e\n\nURI=$@\nTMPDIR=\"$(mktemp -d)\"\n\n# make a fake chart for testing with the passed URL basename\nFILENAME=$(basename -- $URI)\nhelm create $TMPDIR/$FILENAME 1>/dev/null\nhelm package $TMPDIR/$FILENAME -d $TMPDIR 1>/dev/null\n# cat $FILENAME-0.1.0.tgz\n# just to not need to know the chart version\nrm -r $TMPDIR/$FILENAME 1>/dev/null\ncat $TMPDIR/$FILENAME-*\n```\n\n실행 가능하도록 설정합니다:\n\n```bash\nchmod +x get-demo.sh\n```\n\n### 4. 개발 모드로 설치 및 테스트 {#4-install-in-dev-mode-and-test}\n\n파일 시스템에서 플러그인을 설치하면 로컬 개발 모드로 설치됩니다. 이 경우 출처 확인 및 검증을 건너뜁니다:\n\n```bash\n% helm plugin install $HOME/code/helm/plugins/demo-getter\nInstalling plugin from local directory (development mode)\nInstalled plugin: demo-getter\n```\n\n[CLI 플러그인 튜토리얼](/plugins/developer/tutorial-cli-plugin.mdx)에서 살펴봤듯이, 로컬 개발 모드 설치는 플러그인 소스 디렉터리에서 플러그인 디렉터리로 심볼릭 링크를 생성합니다. 이제 두 개의 플러그인이 설치되었습니다:\n\n```bash\n% ls -lah $(helm env HELM_PLUGINS)\ntotal 0\ndrwxr-xr-x@ 4 r6by  staff   160B Nov 10 04:04 .\ndrwxr-xr-x@ 3 r6by  staff    96B Jan 21  2025 ..\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info\n```\n\nCLI 플러그인 튜토리얼과 달리 이 플러그인은 `helm help`의 사용 가능한 명령어 목록에 표시되지 않습니다. CLI 플러그인 유형만 `helm` CLI 서브커맨드 목록에 나타납니다.\n\n하지만 모든 플러그인 유형과 마찬가지로, `helm plugin list`에서 설치된 포스트 렌더러 플러그인 세부 정보를 확인할 수 있습니다:\n\n```bash\n% helm plugin list\nNAME          \tVERSION\tTYPE           \tAPIVERSION\tPROVENANCE\tSOURCE\ndemo-getter   \t0.1.0  \tgetter/v1      \tv1        \tlocal dev \tunknown\nsystem-info   \t0.1.0  \tcli/v1         \tv1        \tlocal dev \tunknown\n```\n\n실행해봅시다. \"example\"이라는 이름의 차트에 대한 템플릿 YAML이 반환되어야 합니다:\n\n```bash\n% helm template example demo://does-not-matter/example\nLOTS OF YAML, INCLUDING:\n---\n# Source: example/templates/tests/test-connection.yaml\n```\n\n만들어냈습니다. 서브프로세스 런타임을 사용하는 데모 Getter 플러그인을!\n\n다음으로는 WASM 런타임으로 버전을 만들어봅시다...\n\n## Wasm 런타임 {#wasm-runtime}\n\n### 사전 요구 사항 {#prerequisites-1}\n\n- [서브프로세스 런타임](#subprocess-runtime)의 사전 요구 사항\n- Go 1.25 설치\n\n`demo://` URL을 `https://`로 변환하는 커스텀 프로토콜 getter를 만들어봅시다.\n\n### 1. 저장소 설정 {#1-set-up-repository}\n\n템플릿에서 새 저장소를 스캐폴드하거나 클론하세요:\nhttps://github.com/gjenkins8/helm-extism-plugin-template\n\n### 2. 플러그인 매니페스트 업데이트 {#2-update-plugin-manifest}\n\n서브프로세스 Getter의 동일한 단계와 거진 유사합니다. 클론한 Git 저장소에서 진행한다는 점만 제외하고 말이죠.\n\nWasm의 경우 `runtime`과 `runtimeConfig` 필드 값이 변경됩니다:\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: getter/v1\nname: demo-getter\nversion: 0.1.0\nruntime: extism/v1\nconfig:\n  protocols: [\"demo\"]\nruntimeConfig:\n  memory:\n    maxPages: 16\n  timeout: 30000\n```\n\n### 3. `main.go` 업데이트 {#3-update-maingo}\n\n플러그인의 입출력 메시지를 지정합니다:\n\n```go title=\"main.go\" showLineNumbers\npackage main\n\n...\n\ntype InputMessage struct {\n\tURL      string `json:\"url\"`\n\tProtocol string `json:\"protocol\"`\n}\n\ntype OutputMessage struct {\n\tData []byte `json:\"data\"`\n}\n```\n\n`replaceMeImplementationGoesHere` 함수를 실제 로직으로 교체합니다:\n\n```go\n...\n\n// Delete the `replaceMeImplementationGoesHere` function\n\nfunc demoDownloader(input InputMessage) (*OutputMessage, error) {\n\n\t// Convert demo:// to https://\n\tdownloadURL := strings.Replace(input.URL, \"demo://\", \"https://\", 1)\n\tpdk.Log(pdk.LogLevelInfo, fmt.Sprintf(\"Converted %s to %s\", input.URL, downloadURL))\n\n\t// Download content\n\tresp, err := http.Get(downloadURL)\n\tif err != nil {\n\t\treturn nil, fmt.Errorf(\"failed to download: %w\", err)\n\t}\n\tdefer resp.Body.Close()\n\n\t// Read and output content\n\tdata, _ := io.ReadAll(resp.Body)\n\toutput := OutputMessage{Data: data}\n\treturn &output, nil\n}\n\n```\n\n`demoDownloader`를 호출하도록 runPlugin 함수를 업데이트합니다:\n\n```go\nfunc runPlugin() error {\n\t...\n\t// Remove: output, err := replaceMeImplementationGoesHere(input)\n\toutput, err := demoDownloader(input)\n```\n\n### 4. WebAssembly 빌드 {#4-build-webassembly}\n\n```bash\n$ make build\n$ ls -la plugin.wasm\n```\n\n### 5. 개발 모드로 설치 및 테스트 {#5-install-in-dev-mode-and-test}\n\n서브프로세스 CLI 플러그인 단계와 동일합니다.\n\n만들어냈습니다. Extism PDK를 통한 샌드박스 실행과 구조화된 통신을 갖춘 WebAssembly 플러그인!\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-postrenderer-plugin.mdx",
    "content": "---\ntitle: \"튜토리얼: 포스트렌더러 플러그인 만들기\"\n---\n\nimport GetVersion from \"@site/src/components/GetVersion\";\nimport CodeBlock from \"@theme/CodeBlock\";\n\n모든 쿠버네티스 리소스에 커스텀 라벨을 추가하는 플러그인을 만들어봅시다.\n\n## 서브프로세스 런타임 {#subprocess-runtime}\n\n서브프로세스 런타임으로 포스트 렌더러 플러그인을 만들어봅시다.\n\n### 사전 요구 사항 {#prerequisites}\n\n1. 최신 헬름4 릴리즈를 설치하세요: **<GetVersion majorVersion=\"4\" label={false} link={true} />**\n2. 터미널 세션에서 다운로드한 릴리즈에 관해서 `helm`을 별칭으로 설정하세요. 이제 `helm version --short`를 실행하면 해당 터미널 세션에서 올바른 Helm 버전이 표시됩니다.\n3. `mikefarah/yq`를 설치하세요: https://github.com/mikefarah/yq/#install\n\n### 1. 플러그인 디렉터리 생성 {#1-create-plugin-directory}\n\n파일 시스템의 어디에서나 생성할 수 있습니다. 예를 들어:\n\n```bash\nmkdir -p $HOME/code/helm/plugins/label-injector\ncd $HOME/code/helm/plugins/label-injector\n```\n\n### 2. 플러그인 매니페스트 생성 {#2-create-plugin-manifest}\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: postrenderer/v1\nname: label-injector\nversion: 0.1.0\nruntime: subprocess\nruntimeConfig:\n  platformCommand:\n    - command: ${HELM_PLUGIN_DIR}/inject-labels.sh\n```\n\n### 3. 스크립트 생성 {#3-create-script}\n\n```bash title=\"inject-labels.sh\" showLineNumbers\n#!/usr/bin/env sh\n# set -e\ncat <&0 | yq '.metadata.labels.postrendered-by = \"helm-label-injector-plugin\"'\n```\n\n실행 가능하도록 설정합니다:\n\n```bash\nchmod +x inject-labels.sh\n```\n\n### 4. 개발 모드로 설치 및 테스트 {#4-install-in-dev-mode-and-test}\n\n파일 시스템에서 플러그인을 설치하면 로컬 개발 모드로 설치됩니다. 이 경우 출처 확인 및 검증을 건너뜁니다:\n\n```bash\n% helm plugin install $HOME/code/helm/plugins/label-injector\nInstalling plugin from local directory (development mode)\nInstalled plugin: label-injector\n```\n\n[CLI 플러그인](/plugins/developer/tutorial-cli-plugin.mdx) 및 [Getter 플러그인](/plugins/developer/tutorial-getter-plugin.mdx) 튜토리얼에서 살펴봤듯이 로컬 개발 모드 설치는 플러그인 소스 디렉터리에서 플러그인 디렉터리로 심볼릭 링크를 생성합니다. 이제 세 개의 플러그인이 설치되었습니다:\n\n```bash\n% ls -lah $(helm env HELM_PLUGINS)\ntotal 0\ndrwxr-xr-x@ 5 r6by  staff   160B Nov 10 04:04 .\ndrwxr-xr-x@ 3 r6by  staff    96B Jan 21  2025 ..\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter\nlrwxr-xr-x  1 r6by  staff    44B Nov 10 03:02 label-injector -> /Users/r6by/code/helm/plugins/label-injector\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info\n```\n\n`helm plugin list`를 사용하여 설치된 CLI 및 Getter 플러그인과 함께 설치된 포스트 렌더러 플러그인 세부 정보를 확인할 수 있습니다:\n\n```bash\n% helm plugin list\nNAME          \tVERSION\tTYPE           \tAPIVERSION\tPROVENANCE\tSOURCE\ndemo-getter   \t0.1.0  \tgetter/v1      \tv1        \tlocal dev \tunknown\nlabel-injector\t0.1.0  \tpostrenderer/v1\tv1        \tlocal dev \tunknown\nsystem-info   \t0.1.0  \tcli/v1         \tv1        \tlocal dev \tunknown\n```\n\n실행해봅시다:\n\n```bash\n% helm create ../mychart\n% helm template ../mychart --post-renderer label-injector\n```\n\n출력에서 다음과 같은 레이블을 확인할 수 있습니다:\n\n```yaml\nmetadata:\n  labels:\n    postrendered-by: helm-label-injector-plugin\n```\n\n만들었습니다. 서브프로세스 런타임을 사용한 포스트렌더러 플러그인을! \n이번에는 Wasm 런타임으로도 만들어봅시다…\n\n## Wasm 런타임 {#wasm-runtime}\n\n### 사전 요구 사항 {#prerequisites}\n\n- [서브프로세스 런타임](#subprocess-runtime)의 사전 요구 사항\n- Go 1.25 설치\n\n:::warning\nTo-do: 섹션 추가 필요\n:::\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/plugins/index.mdx",
    "content": "---\ntitle: 플러그인 가이드\nsidebar_label: 플러그인\nsidebar_position: 5.5\n---\n\n이 가이드는 Helm 플러그인이 무엇인지, 어떻게 사용하는지, 어떻게 만드는지를 설명합니다.\n\nimport DocCardList from \"@theme/DocCardList\";\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/plugins/overview.md",
    "content": "---\ntitle: 플러그인 개요\nsidebar_label: 개요\nsidebar_position: 1\n---\n\n헬름 플러그인은 유저가 모든 새로운 기능을 Go로 작성해 헬름 코어에 추가하지 않고도 Helm의 핵심 기능을 확장할 수 있게 해줍니다.\n\n플러그인은 어떤 프로그래밍 언어로도 작성할 수 있으며 헬름의 코어 기능을 망가뜨리지 않으며 헬름 설치에 추가하거나 제거할 수 있습니다.\n\n## 플러그인 타입 {#plugin-types}\n\n현재 헬름에는 세 가지 유형의 플러그인이 있습니다:\n\n- [CLI 플러그인](#cli-plugins): 사용자가 추가적인 `helm` CLI 하위 명령어를 덧붙일 수 있게 해줍니다.\n- [Getter 플러그인](#getter-plugins): 헬름 코어에서 기본적으로 지원하지 않는 위치에서도 차트나 다른 플러그인을 사용할 수 있게 합니다.\n- [Postrenderer 플러그인](#postrenderer-plugins): 사용자가 차트에 의해 렌더링된 매니페스트를 쿠버네티스 API로 전송하기 전 수정할 수 있게 해줍니다.\n\n헬름4부터 추가적인 플러그인 유형을 더 쉽게 추가할 수 있도록 플러그인 시스템이 설계되었고, 사용자는 헬름 기능의 다른 영역도 수정할 수 있게 됩니다.\n\n### CLI 플러그인 {#cli-plugins}\n\n별도의 스크립트나 자체적인 독립형 커멘드를 지닌 툴을 사용하는 것과 대비해 플러그인을 이용해 `helm` CLI 하위 명령어를 만드는 것의 이점이 무엇일까요? \n\n가장 큰 장점은 `helm` CLI 하위 명령어를 추가하는 플러그인이 독립 실행형 스크립트나 도구가 직접 구현해야 하는 헬름 고유의 설정, 컨텍스트 및 기능을 활용할 수 있다는 점입니다. 이를 통해 `helm` CLI 사용자 워크플로우를 보다 원활하게 확장할 수 있습니다.\n\n### Getter 플러그인 {#getter-plugins}\n\n헬름은 로컬 파일 시스템에 있거나 [OCI 레지스트리](/topics/registries.mdx)에 아티팩트로 저장된 [Chart](/glossary/index.mdx)와 플러그인을 다루는 기본 기능을 제공합니다. 차트는 추가적으로 [HTTP 저장소](/topics/chart_repository.md)에 저장할 수 있으며 플러그인은 추가적으로 Git과 같은 VCS 저장소에도 저장할 수 있습니다.\n\n헬름의 Getter 플러그인은 이러한 저장 및 다운로드 동작을 확장하여 다른 저장소를 지원할 수 있게 합니다.\n[s3 버킷](/community/related#helm-plugins)나 그 외 다른 어디든 차트와 플러그인을 저장할 수 있는 커뮤니티 Getter 플러그인이 있습니다. 헬름 워크플로우에서 추가적인 저장 옵션이 필요할 때 getter 플러그인을 사용하길 선호하게 될 겁니다.\n\n### 포스트렌더러 플러그인 {#postrenderer-plugins}\n\n헬름은 사용자가 커스텀 값을 제공해 차트를 구성하게 해줍니다. 사용자에 의해 제공된 값은 차트가 매니페스트를 렌더링하는 데 사용되는데, 이를 통해 헬름은 쿠버네티스에서 어플리케이션을 관리할 수 있습니다. \n\n자기 소유의 차트를 작성할 땐 렌더링된 매니페스트에 추가적인 구성 옵션이 필요할 때마다 템플릿을 업데이트할 수 있습니다. 하지만 자기 소유가 아닌 커뮤니티 차트를 사용한다면 포스트 렌더링으로 차트가 매니페스트를 렌더링한 시점, 하지만 아직 헬름이 그를 사용해 쿠버네티스 리소스를 관리하진 않은 이전 시점에 매니페스트를 수정할 수 있습니다. 헬름4부터는 포스트렌더러 플러그인으로 이를 수행할 수 있습니다.\n\n## 플러그인 API 버전 {#plugin-api-versions}\n\n헬름4부터 모든 플러그인에 포함된 `plugin.yaml` 파일에 `apiVersion` 필드가 추가되며 현재 값은 `v1`입니다.\n\n(API 버전 도입 이전의) 레거시 플러그인도 헬름4에서 계속 지원될 것이며, 따라서 헬름3에서 사용하던 기존 플러그인도 헬름5가 나오기 전까지는 계속 작동할 것입니다. 다만 자주 사용하는 플러그인의 개발자에게 새 버전 관리 시스템으로 업데이트하길 요청하는 게 좋습니다.\n\n플러그인 개발자라면, [플러그인 개발자 가이드](/plugins/developer/index.mdx)에서 이에 관해 더 자세히 읽어보세요.\n\n## 플러그인 런타임 {#plugin-runtimes}\n\n헬름은 현재 두 가지 플러그인 런타임을 지원합니다:\n\n- 서브프로세스 런타임\n- Wasm 런타임\n\n각 런타임에 대한 자세한 내용은 [플러그인 사용자 가이드](/plugins/user/index.md) 또는  [플러그인 개발자 가이드](/plugins/developer/index.mdx)를 참조하세요.\n\n## 파일 구조 {#file-structure}\n\n플러그인의 모든 파일은 단일 디렉터리에 위치하며, 이 디렉터리는 개발, 패키징, 설치에 사용됩니다.\n\n플러그인 디렉터리 내부에서 헬름은 다음 구조를 요구합니다:\n\n```\nexample-plugin\n├── plugin.yaml # REQUIRED\n├── plugin.sh   # OPTIONAL for Subprocess runtime\n└── plugin.wasm # REQUIRED for Wasm runtime\n```\n\n- 필수 파일은 [plugin.yaml](#pluginyaml)가 유일합니다.\n- [서브프로세스 런타임](#plugin-runtimes)에는 선택적으로 (노드, 파이썬, Go, 그 외 등등) 플러그인 코드가 담긴 한 가지 이상의 실행 파일을 넣을 수 있습니다. 이 런타임에서는 `plugin.yaml` [런타임 설정](#runtime-configuration)의 `platformCommand` 필드를 통해 사용자의 PATH에서 이미 사용 가능한 실행 파일을 직접 호출할 수도 있습니다.\n- [Wasm 런타임](#plugin-runtimes)의 경우 `.wasm` 파일을 포함해야 합니다. 이는 Wasm으로 컴파일된 플러그인 코드입니다(Node, Python, Go 등 가능).\n\n## Plugin.yaml {#plugin-yaml}\n\n`plugin.yaml` 파일은 플러그인에 필수 요소입니다. 이 파일은 플러그인에 관한 메타데이터와 구성을 담은 YAML 파일입니다.\n\n### 메타데이터 정보 {#metadata-information}\n\n```yaml\napiVersion: 필수 - 플러그인 API 버전. 값은 반드시 \"v1\"이어야 함.  \ntype: 필수 - 버전 관리된 플러그인 유형. \"cli/v1\", \"getter/v1\", 또는 \"postrenderer/v1\" 중 하나일 수 있음.  \nname: 필수 - 플러그인의 이름.  \nversion: 필수 - 플러그인의 버전.  \nruntime: 필수 - 플러그인 런타임. \"subprocess\" 또는 \"extism/v1\"(Wasm) 중 하나일 수 있음. \nsourceURL: 선택 - 플러그인 소스 코드를 가리키는 URL.  \nconfig: 플러그인 유형에 따라 달라짐  \nruntimeConfig: 런타임에 따라 달라짐\n```\n\n- `config` 필드는 [플러그인 유형 구성](#plugin-type-configuration)에 사용되며, `type` 필드에 정의된 [플러그인 유형](#plugin-types)에 따라 구조가 달라집니다.  \n- `runtimeConfig` 필드는 [런타임 구성](#runtime-configuration)에 사용되며, `runtime` 필드에 정의된 [런타임](#plugin-runtimes)에 따라 구조가 달라집니다.  \n- 💡 `sourceURL` 필드는 선택 사항이지만, 플러그인 작성자는 플러그인 소스 코드를 가리키도록 권장됩니다. 이는 플러그인 사용자가 코드가 무엇을 하는지 이해하고, 오픈소스 기여가 가능할 경우 플러그인에 기여할 수 있도록 돕기 위함입니다.\n\n### 플러그인 유형 구성 {#plugin-type-configuration}\n\n[plugin.yaml](#pluginyaml)의 `config` 필드는 [플러그인 유형](#plugin-types)마다 서로 다른 옵션을 가집니다. 플러그인의 유형은 `type` 필드로 정의됩니다.\n\n#### CLI 플러그인 설정 {#cli-plugin-configuration}\n\n만약 `type` 필드가 `cli/v1`이라면 [CLI 플러그인 유형](#cli-plugins)이며, 다음 플러그인 유형 설정이 허용됩니다:\n\n```yaml\nusage: 선택 사항 - 도움말에 표시되는 한 줄 사용법 텍스트  \nshortHelp: `helm help` 출력에 표시되는 짧은 설명  \nlongHelp: `helm help <this-command>` 출력에 표시되는 상세 메시지  \nignoreFlags: Helm에서 전달된 플래그를 무시합니다\n```\n\n- `usage`는 선택 사항입니다. 커스텀 사용법 문자열로 오버라이드하지 않으면 기본값은 \"helm PLUGIN_NAME [flags]\"입니다. 권장 문법은 [spf13/cobra.command.Command] Use 필드 주석을 참조하세요: https://pkg.go.dev/github.com/spf13/cobra#Command\n- `ignoreFlags`는 Helm이 플러그인에 플래그를 전달하지 않도록 합니다. 예를 들어 `helm myplugin --foo`로 플러그인을 호출하고 `ignoreFlags: true`인 경우 `--foo`는 자동으로 무시됩니다.\n\n#### Getter 플러그인 설정 {#getter-plugin-configuration}\n\n만약 `type` 필드가 `getter/v1`이라면 [Getter 플러그인 유형](#getter-plugins)이며, 다음 플러그인 유형 설정이 허용됩니다:\n\n```yaml\nprotocols: 이 플러그인이 지원하는 차트 URL의 스킴 목록입니다.\n```\n\n#### 포스트 렌더러 플러그인 설정 {#postrenderer-plugin-configuration}\n\n만약 `type` 필드가 `postrenderer/v1`이라면 [포스트 렌더러 플러그인 유형](#postrenderer-plugins)이며, 별도의 설정 옵션이 없습니다.\n\n### 런타임 설정 {#runtime-configuration}\n\n[plugin.yaml](#pluginyaml)의 `runtimeConfig` 필드는 [플러그인 런타임](#plugin-runtimes)에 따라 다른 옵션을 가집니다. 플러그인의 런타임은 `runtime` 필드로 정의됩니다.\n\n#### 서브프로세스 런타임 설정 {#subprocess-runtime-configuration}\n\n만약 `runtime` 필드가 `subprocess`라면 [서브프로세스 런타임](#plugin-runtimes) 플러그인이며, 다음 런타임 설정이 허용됩니다:\n\n```yaml\nruntimeConfig:\n    platformCommand: # 플랫폼에 따라 실행할 명령어 설정\n        - os: OS 일치 조건, 비워두거나 생략하면 모든 OS에 일치\n          arch: 아키텍처 일치 조건, 비워두거나 생략하면 모든 아키텍처에 일치\n          command: 실행할 플러그인 명령어\n          args: 플러그인 명령어 인수\n    platformHooks: # 플랫폼에 따라 플러그인 라이프사이클 훅 설정\n        install: # 설치 라이프사이클 명령어\n            - os: OS 일치 조건, 비워두거나 생략하면 모든 OS에 일치\n              arch: 아키텍처 일치 조건, 비워두거나 생략하면 모든 아키텍처에 일치\n              command: 실행할 플러그인 설치 명령어\n              args: 플러그인 설치 명령어 인수\n        update: # 업데이트 라이프사이클 명령어\n            - os: OS 일치 조건, 비워두거나 생략하면 모든 OS에 일치\n              arch: 아키텍처 일치 조건, 비워두거나 생략하면 모든 아키텍처에 일치\n              command: 실행할 플러그인 업데이트 명령어\n              args: 플러그인 업데이트 명령어 인수\n        delete: # 삭제 라이프사이클 명령어\n            - os: OS 일치 조건, 비워두거나 생략하면 모든 OS에 일치\n              arch: 아키텍처 일치 조건, 비워두거나 생략하면 모든 아키텍처에 일치\n              command: 실행할 플러그인 삭제 명령어\n              args: 플러그인 삭제 명령어 인수\n    protocolCommands: # 더 이상 사용되지 않음/지원 중단\n        - protocols: [] # 차트 URL의 스킴 목록\n          platformCommand: [] # 위의 \"platformCommand\"와 동일한 구조\n```\n\n- ⚠️ `protocolCommands`는 `obsolete/deprecated`로 표시되어 있으며, `apiVersion: v1` 이후의 플러그인 시스템 버전에서 제거될 예정입니다. 이 필드는 \"getter/v1\" 플러그인 유형에만 적용됩니다. 이는 단일 플러그인에서 여러 프로토콜을 지원하도록 확장된 구 플러그인 다운로더 메커니즘의 호환성 잔재입니다. PlatformCommand에 지정된 명령어는 다운로드 URL을 검사하여 프로토콜별 로직을 구현해야 됩니다.\n\n#### Wasm 런타임 설정 {#wasm-runtime-configuration}\n\n만약 `runtime` 필드가 `extism/v1`이라면 [Wasm 런타임](#plugin-runtimes) 플러그인이며, 다음 런타임 설정이 허용됩니다:\n\n```yaml\nruntimeConfig:\n    memory: # 플러그인에 할당될 수 있는 메모리 한도 설정\n        maxPages: 플러그인이 할당할 수 있는 최대 페이지 수. 1페이지는 64KiB. 예: 16페이지는 1MiB 필요. 기본값은 4페이지(256KiB).\n        maxHttpResponseBytes: Extism HTTP 응답의 최대 크기(바이트). 기본값은 4096바이트(4KiB).\n        maxVarBytes: 모든 Extism 변수의 최대 크기(바이트). 기본값은 4096바이트(4KiB).\n    config: {} # 플러그인에 전달할 수 있는 자유 형식 맵.\n    allowedHosts: [] # 이 플러그인이 통신할 수 있는 호스트 목록(선택 사항). 기본값은 허용된 호스트 없음.\n    fileSystem:\n        createTempDir: 파일 시스템에 임시 디렉터리를 생성할지 여부. \"true\" 또는 \"false\".\n    timeout: 플러그인 실행 타임아웃(밀리초)\n    hostFunctions: 플러그인이 접근할 수 있는 헬름에서 노출된 HostFunction 이름. https://extism.org/docs/concepts/host-functions/ 참조\n    entryFuncName: 플러그인에서 호출할 진입 함수 이름. 기본값은 \"helm_plugin_main\".\n```\n\n- `allowedHosts`는 플러그인이 HTTP 요청을 수행하는 경우에만 적용됩니다. 지정하지 않으면 어떤 호스트도 허용되지 않습니다."
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current/plugins/user/index.md",
    "content": "---\ntitle: 플러그인 유저 가이드\nsidebar_label: 플러그인 사용하기\nsidebar_position: 2\n---\n\n헬름 플러그인의 개념, 그리고 어떻게 그 구조를 읽는지, 어떻게 각 설정들이 사용자로서 당신에게 무얼 의미하는지 이해하려면 [플러그인 개요](/plugins/overview.md)를 참조하세요.\n\n이 섹션은 최종 사용자로서 Helm 플러그인을 사용하는 방법에 초점을 맞춥니다.\n\n## 플러그인 찾기 {#finding-plugins}\n\n[ArtifactHub에서 Helm 플러그인](https://artifacthub.io/packages/search?kind=6)을 이미 찾아볼 수 있습니다.\n\nHelm 4 플러그인 시스템은 완전히 새로운 기능입니다. 조만간 ArtifactHub에서 유형과 런타임별로 플러그인을 검색할 수 있게 될 예정입니다. 업데이트를 기대해주세요!\n\n## 플러그인 보안 {#plugin-security}\n\n플러그인 런타임에 따라, 시스템에서 실행하기 전에 서드파티 플러그인을 검사해보는 것이 좋습니다.\n\n- 서브프로세스 런타임은 명령어를 실행하는 사용자만큼 시스템 접근 권한을 가집니다. 플러그인을 설치하거나 제거하기 전, 또는 해당 플러그인이 실행될 수 있는 helm 명령어를 실행하기 전 반드시 플러그인 코드를 꼼꼼히 검토하세요.\n- 반면 Wasm 런타임은 명시적으로 승인한 시스템 접근 권한만 허용하는 보안 샌드박스에서 실행됩니다. 이 플러그인 런타임은 훨씬 강력한 제어와 내재적으로 높은 수준의 내장 보안을 제공합니다. 그래도 플러그인이 요청하는 권한을 파악하기 위해 `plugin.yaml`을 확인해보는 게 좋습니다.\n\n두 경우 모두 Wasm 런타임 플러그인일지라도 설치 전 출처를 검증하길 강력히 권장합니다. 어디에서 다운로드됐고 누가 만들었는지 신뢰하기 위해 말이죠. 이는 스푸핑된 URL 공격으로 플러그인을 실수로 설치하는 것을 방지할 뿐만 아니라, 네트워크 탈취 공격으로부터도 보호합니다. 플러그인 검증은 설치 전 차트가 손상되지 않았음을 암호학적으로 확인하게 해줍니다.\n\n`helm plugin install --help`의 `--verify` 플래그를 참조하세요.\n\n개발 목적으로 인해 설치 과정에서의 검증이 생략된 경우에도 이미 설치된 플러그인의 출처를 `helm plugin verify --help`를 사용하여 확인할 수 있으며, 또한 언제든 보안 준수 정보를 제공받는 데에도 도움을 줄 겁니다.\n\n`helm plugin list` 명령어는 출처 정보도 한눈에 확인할 수 있도록 제공합니다.\n\n## 플러그인 설치하기 {#installing-plugins}\n\nHelm에는 기본적으로 안전한 설치를 수행하는 플러그인 설치 명령어가 내장되어 있습니다. 그렇더라도 설치 전 무엇을 확인해봐야 될지 이해하기 위해 [플러그인 보안](#plugin-security) 문서를 반드시 읽어보시기 바랍니다.\n\n자세한 내용은 `helm plugin install --help`를 참조하세요.\n\n## 설치된 플러그인 목록 확인 {#listing-installed-plugins}\n\n플러그인 목록을 확인하는 명령어는 플러그인의 이름, 버전, 유형, API 버전, 출처(provenance) 및 소스를 표시합니다.  \n\n자세한 내용은 `helm plugin list --help`를 참조하세요.\n\n## 플러그인 제거 {#uninstalling-plugins}\n\n플러그인 제거는 간단하고 쉽게 수행되도록 설계되어 있습니다. 그렇더라도 제거 시의 위험을 이해하기 위해 [플러그인 보안](#plugin-security) 문서를 반드시 읽어보시기 바랍니다.  \n\n자세한 내용은 `helm plugin uninstall --help`를 참조하세요.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Helm 사용하기\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Helm 명령어\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"차트\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"템플릿 개발\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"모범 사례\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: 일반적인 관례\ndescription: 차트에 대한 일반적인 관례\nsidebar_position: 1\n---\n\n이 부분은 모범사례 가이드의 일부로서 일반적인 관례를 설명한다.\n\n## 차트 이름\n\n차트 이름은 소문자와 숫자여야 한다. 단어는 대시(-)로 구분할 수 있다.\n\n예시:\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\n대문자나 밑줄문자는 차트 이름에 사용할 수 없다. 점도 사용할 수 없다.\n\n## 버전 번호\n\n가능하다면 어디서든, 헬름은 버전 번호를 표현할 때 [SemVer 2](https://semver.org)를 사용한다.\n(도커 이미지 태그는 SemVer를 따를 필요가 없고\n아쉽지만 규칙에서 예외로 취급된다는 점을 알아두자.)\n\nSemVer 버전을 쿠버네티스 레이블로 저장할 때,\n관례적으로 `+` 문자를 `_` 문자로 변경하는데,\n`+` 기호는 레이블 값으로 허용되지 않기 때문이다.\n\n## YAML 형식\n\nYAML 파일은 _2칸_ (탭이 아니다) 들여쓰기해야 한다.\n\n## 헬름과 차트 단어의 사용\n\n_Helm_ 과 _helm_ 단어 사용에 관한 관례는 다음과 같다.\n\n- _Helm_(헬름)은 전체 프로젝트를 가리킨다.\n- `helm`은 클라이언트측 명령어를 가리킨다.\n- `chart`는 첫글자를 대문자로 쓸 필요가 없는데, 고유명사가 아니기 때문이다.\n- 반면, `Chart.yaml`는 첫글자를 대문자로 써야 하는데, 파일명에는 대소문자 구분이 있기 때문이다.\n\n애매할 때는 _Helm_(대문자 'H', 헬름)을 쓰자.\n\n## 차트 템플릿과 네임스페이스\n\n차트 템플릿의 `metadata` 섹션에 `namespace` 속성을 정의하는 것은 피하자.\n렌더링된 템플릿에 적용할 네임스페이스는 `--namespace`와 같은 플래그를 통해 쿠버네티스 클라이언트를 호출할 때 지정해야 한다.\nHelm은 템플릿을 있는 그대로 렌더링하여 쿠버네티스 클라이언트에 전달하는데, 이 클라이언트는 Helm 자체일 수도 있고 다른 프로그램(kubectl, flux, spinnaker 등)일 수도 있다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: 커스텀 리소스 데피니션(CRD)\ndescription: CRD를 생성하고 사용하는 방법\nsidebar_position: 7\n---\n\n이 부분은 모범사례 가이드의 일부로서 커스텀 리소스 데피니션 객체를 생성하고 사용하는 것을 다룬다.\n\n커스텀 리소스 데피니션(CRD)를 다룰 때에는, 다음 2가지를 구분하는 것이 중요하다.\n\n- CRD의 선언이 있다. 이것은 종류(kind)가 `CustomResourceDefinition`인 YAML 파일이다.\n- 그리고 그 CRD를 사용하는 리소스들이 있다. 어떤 CRD가 `foo.example.com/v1`를 정의한다고 해보자.\n  `apiVersion: example.com/v1`가 있고 종류(kind)가 `Foo`인 모든 리소스들은 그 CRD를 사용하는 리소스이다.\n\n## 리소스를 사용하기 전에 CRD 선언을 설치하기\n\n헬름은 되도록 많은 리소스들을 빨리 쿠버네티스 내에 로드(load)하도록 최적화되어 있다.\n설계상, 쿠버네티스는 전체 매니페스트 세트를 받고 온라인으로 반영한다(이것을 조정(reconciliation) 루프라고 한다).\n\n하지만 CRD의 경우는 약간 다르다.\n\n해당 CRD 종류(kind) 리소스가 사용되기 전에, CRD 선언이 먼저 등록되어 있어야 한다.\n그리고 등록 과정은 때에 따라 몇 초 정도 걸린다.\n\n### 방법 1: `helm`이 처리하게 하기\n\n헬름 3이 나오면서, 더 단순한 방안을 위해 구식 `crd-install` 훅(hook)은 없어졌다.\n이제는 `crds`라는 특수 디렉토리가 있어서, CRD를 만들고자 할 때 차트 내에 생성할 수 있다.\nCRD는 템플릿은 아니지만 차트를 `helm install`으로 실행하면 기본으로 설치될 것이다.\nCRD가 이미 있으면, 경고(warning)가 나오면서 넘어가게 된다.\nCRD 설치 단계를 그냥 넘기고 싶다면, `--skip-crds` 플래그를 쓰면 된다.\n\n#### 주의사항 (및 설명)\n\n지금으로서는 헬름으로 CRD를 업그레이드하거나 삭제하는 것이 지원되지 않는다.\n이는 의도치 않은 데이터 유실 위험을 우려한 커뮤니티 상의 많은 논의에 따른 명시적인 결정이다.\n또한, 현재로서는 CRD와 그 수명주기를 어떻게 다룰 지에 대해 커뮤니티의 컨센서스가 없다.\n논의가 진행되면 헬름은 그러한 사용사례에 대해 지원할 수 있게 될 것이다.\n\n현재 `helm install`와 `helm upgrade`의 `--dry-run` 플래그는 CRD를 지원하지 않는다.\n\"드라이런(Dry Run)\"의 목적은 차트가 실제로 서버에 전송되었을 때 처리되어 나올 결과물을 검증하는 것이다.\n그런데 CRD는 서버의 행동 자체를 변경시킨다.\n헬름은 드라이런으로 CRD를 설치할 수 없으므로, 디스커버리 클라이언트는 커스텀 리소스(CR)에 대해 알 수 없고 검증은 실패하게 될 것이다.\n대안으로 CRD를 별도의 CRD 자체의 차트로 옮기거나, `helm template`을 사용할 수 있다.\n\nCRD 지원 논의에서 고려할 다른 중요한 포인트는 템플릿 렌더링을 어떻게 처리할 것인지이다.\n헬름 2에서 사용되던 `crd-install`의 뚜렷한 단점의 하나는\nAPI 기능범위 변경 때문에 차트를 제대로 검증할 수 없다는 점이다(CRD는 쿠버네티스 클러스터에 사용가능한 API를 실제로 추가한다).\n차트가 CRD를 설치하면, `helm`이 사용하던 유효한 API 버전 세트가 더 이상 유효하지 않은 것이다.\n이는 CRD에서 템플릿 지원이 제거된 데에 깔린 이유이기도 한다.\nCRD를 설치하는 새로운 `crds` 방법에서는, `helm`이 클러스터의 현재 상태에 대해 완전히 유효한 정보를 가지고 있음이 보장된다.\n\n### 방법 2: 차트 분리하기\n\n다른 방법으로는 한 차트에는 CRD 정의(definition)를 넣고 _다른_ 차트에는 CRD를 사용하는 리소스들을 넣는 방법이 있다.\n\n이 방법으로 할 때는, 각 차트가 따로 설치되어야 한다. 하지만, 이러한 작업방식은 클러스터에 어드민으로 접근하는 클러스터 운영자들에게 더 유용할 것이다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: 의존성\ndescription: 차트 의존성에 관한 모범사례를 다룬다.\nsidebar_position: 4\n---\n\n이 부분은 가이드의 일부로서 `Chart.yaml`에서 선언되는 `dependencies`에 관한 모범사례를 다룬다.\n\n## 버전\n\n가능하면 특정 버전을 콕 집어서 사용하기 보다는 버전 범위를 사용하자.\n권장되는 기본값은 다음과 같이 패치-수준의 버전 매치(match)를 사용하는 것이다.\n\n```yaml\nversion: ~1.2.3\n```\n\n이렇게 하면 `1.2.3`과 그 릴리스의 다른 패치들도 매치된다.\n다시 말하면 `~1.2.3`은 `>= 1.2.3, < 1.3.0`과 동등하다.\n\n버전 매칭 구문에 대한 자세한 설명은 [semver\n문서](https://github.com/Masterminds/semver#checking-version-constraints)에서 볼 수 있다.\n\n### 프리릴리스 버전\n\n앞서 설명한 버전 제약 조건은 프리릴리스 버전에는 적용되지 않는다.\n예를 들어 `version: ~1.2.3`은 `version: ~1.2.4`와 매치되지만, `version: ~1.2.3-1`과는 매치되지 않는다.\n다음과 같이 하면 프리릴리스뿐 아니라 패치-수준의 매칭도 된다.\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### 리포지터리 URL\n\n가능하면 `https://` 리포지터리 URL을 우선으로 사용하고, 그 다음으로 `http://` URL을 사용하자.\n\n리포지터리가 리포지터리 인덱스 파일에 추가되면, 리포지터리 이름은 URL의 별칭으로 사용될 수 있다.\n`alias:`나 `@` 뒤에 리포지터리 이름을 쓰자.\n\n파일 URL(`file://...`)은 고정된 배포 파이프라인에서 조립되는 차트를 위한 \"특수한 경우\"로 간주된다.\n\n[다운로더 플러그인](../topics/plugins.md#downloader-plugins)을 사용하는 경우, URL 스킴은 해당 플러그인에 따라 달라진다. 차트 사용자는 의존성을 업데이트하거나 빌드하려면 해당 스킴을 지원하는 플러그인을 설치해야 한다.\n\n`repository` 필드를 비워두면 Helm은 해당 의존성에 대한 관리 작업을 수행할 수 없다. 이 경우 Helm은 의존성이 `charts` 폴더의 하위 디렉터리에 있고, 디렉터리 이름이 의존성의 `name` 속성과 같다고 가정한다.\n\n## 조건과 태그\n\n조건과 태그는 _선택적(optional)_인 모든 의존성에 추가되어야 한다. 기본적으로 `condition`은 `true`라는 점에 주의하자.\n\n조건의 권장되는 형식은 다음과 같다.\n\n```yaml\ncondition: somechart.enabled\n```\n\n여기서 `somechart`는 의존성의 차트 이름이다.\n\n여러 서브차트(의존성)들이 선택적 또는 교체가능한 기능을 공동으로 제공하는 경우,\n그 차트들은 동일한 태그를 사용해야 한다.\n\n예를 들어, `nginx`와 `memcached`가 차트 내 메인 앱에 대한 성능 최적화 기능을 \n공동으로 제공하는 경우, 그리고 그 기능의 활성화시에 둘다 있어야 한다면\n둘다 다음과 같은 태그 섹션이 있어야 한다.\n\n```yaml\ntags:\n  - webaccelerator\n```\n\n이렇게 하면 사용자는 하나의 태그로 기능을 켜거나 끌 수 있다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx",
    "content": "---\ntitle: 모범 사례\nsidebar: true\nsidebar_position: 4\n---\n\n# 차트 모범 사례 가이드\n\n이 가이드에서는 헬름 팀이 고려한 차트 생성 모범 사례를 다룹니다.\n주로 차트를 구성하는 방법에 중점을 둘 것입니다.\n\n여기에서는 주로 공개 배포 가능한 차트의 모범 사례에 중점을 둡니다. \n물론 많은 차트들이 내부 사용 목적으로 작성되고,\n그런 차트의 작성자들은 여기에 제안된 것들을 활용하여 내부에서 사용하는 방법을 찾을 것이라는 것도 알고 있습니다.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: 레이블과 어노테이션\ndescription: 차트 내에서 레이블과 어노테이션을 사용하는 모범사례를 다룬다.\nsidebar_position: 5\n---\n\n이 부분은 모범사례 가이드의 일부로서 차트 내에서 레이블과 어노테이션을 사용하는 모범사례에 대해 논한다.\n\n## 레이블인가, 어노테이션인가?\n\n다음 조건에 해당하는 메타데이터 항목은 레이블이어야 한다.\n\n- 쿠버네티스에서 해당 리소스를 식별하기 위해 사용된다.\n- 시스템 쿼리를 목적으로 운영자에게 유용하게 노출되어야 한다.\n\n예를 들어, `helm.sh/chart: NAME-VERSION`을 레이블로서 사용하는 것을 권장하는데,\n이렇게 하면 운영자는 레이블을 통해 특정 차트의 모든 인스턴스들을 편리하게 찾을 수 있다.\n\n메타데이터 항목이 쿼리에 사용되지 않는다면, 어노테이션으로 설정해야 한다.\n\n헬름 훅은 항상 어노테이션이다.\n\n## 표준 레이블\n\n아래 표에 헬름 차트에서 널리 사용되는 레이블이 있다.\n헬름 자체는 특정 레이블을 필요로 하지 않는다.\nREC로 표시된 레이블은 권장되는 것으로서, 전체적인 정합성 유지를 위해 차트에 있어야 한다.\nOPT로 표시된 레이블은 선택사항이다.\n이것들은 관용적 또는 일반적으로 사용하지만, 운영 목적에서는 그렇게 자주 사용하지 않는다.\n\n이름|상태|설명\n-----|------|----------\n`app.kubernetes.io/name` | REC | 전체 앱을 잘 나타내는 앱 이름을 써야 한다. 흔히 `{{ template \"name\" . }}`로 쓴다. 많은 쿠버네티스 매니페스트에서 사용되는 것으로서, 헬름에만 있는 것이 아니다.\n`helm.sh/chart` | REC | 차트 이름과 버전을 써야 한다. `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`.\n`app.kubernetes.io/managed-by` | REC | 항상 `{{ .Release.Service }}`로 설정해야 한다. 헬름이 관리하는 모든 것을 찾기 위한 것이다.\n`app.kubernetes.io/instance` | REC | `{{ .Release.Name }}`이어야 한다. 동일한 애플리케이션의 다른 인스턴스들을 구별하는 데 도움이 된다.\n`app.kubernetes.io/version` | OPT | 앱의 버전이며, `{{ .Chart.AppVersion }}`로 설정할 수 있다.\n`app.kubernetes.io/component` | OPT | 하나의 애플리케이션 내에서 각 부분들이 맡은 역할을 표시하는 일반적인 레이블이다. 예를 들면 `app.kubernetes.io/component: frontend`.\n`app.kubernetes.io/part-of` | OPT | 하나의 애플리케이션을 구성하는 데 여러 차트 또는 소프트웨어 부분들이 함께 사용되는 경우(예를 들어, 웹사이트를 제공하는 애플리케이션 소프트웨어와 데이터베이스), 그것들이 지원하는 최상위 애플리케이션으로 설정할 수 있다.\n\n`app.kubernetes.io` 접두어를 가진 쿠버네티스 레이블에 대한 더 자세한 정보는\n[쿠버네티스 문서](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)에서 찾아볼 수 있다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: 파드와 파드템플릿\ndescription: 차트 매니페스트에 있는 파드와 파드템플릿 부분의 형식을 논한다.\nsidebar_position: 6\n---\n\n이 부분은 모범사례 가이드의 일부로서 차트 매니페스트에 있는 파드와 파드템플릿 부분의 형식을 논한다.\n\n파드템플릿을 사용하는 리소스들(일부)은 다음과 같다.\n\n- 디플로이먼트(Deployment)\n- 레플리케이션컨트롤러(ReplicationController)\n- 레플리카셋(ReplicaSet)\n- 데몬셋(DaemonSet)\n- 스테이트풀셋(StatefulSet)\n\n## 이미지\n\n컨테이너 이미지는 고정된 태그나 이미지의 SHA를 사용해야 한다.\n`latest`, `head`, `canary` 등 \"유동적인\" 목적으로 고안된 태그를 \n사용해서는 안된다.\n\n이미지를 쉽게 교체하기 위해 `values.yaml` 파일 내에 이미지를 정의할 수 있다.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\n`values.yaml` 내에서 이미지와 태그를 각각의 필드로 정의할 수도 있다.\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create`는 `deployment.yaml` 파일에서 다음과 같이 설정하여 기본적으로 `imagePullPolicy`를 `IfNotPresent`로 설정한다.\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\n그리고 `values.yaml`에서는 다음과 같이 설정한다.\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\n마찬가지로, Kubernetes에서도 `imagePullPolicy`가 정의되지 않은 경우 기본값은 `IfNotPresent`이다.\n`IfNotPresent` 외에 다른 값을 사용하려면, `values.yaml`에 있는 값을 원하는 값으로 바꾸면 된다.\n\n\n## 파드템플릿에는 셀렉터가 선언되어야 한다\n\n모든 파드템플릿 섹션에는 셀렉터를 지정해야 한다. 예를 들면,\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\n이것은 리소스와 파드 간의 관계를 명확히 해주므로 좋은 사례이다.\n\nDeployment와 같은 리소스의 경우 이것이 더욱 중요하다.\n셀렉터를 지정하지 않으면 _모든_ 레이블이 매칭되는 파드를 선택하는 데 사용되며,\n버전이나 릴리스 날짜와 같이 변경되는 레이블을 사용하는 경우 깨질 수 있다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: 역할 기반 접근 제어\ndescription: 차트 매니페스트에 있는 RBAC 리소스의 생성과 형식을 논한다.\nsidebar_position: 8\n---\n\n이 부분은 모범사례 가이드의 일부로서 차트 매니페스트에 있는 RBAC 리소스의 생성과 형식을 논한다.\n\nRBAC 리소스는 다음과 같다.\n\n- ServiceAccount (네임스페이스 구분)\n- Role (네임스페이스 구분)\n- ClusterRole\n- RoleBinding (네임스페이스 구분)\n- ClusterRoleBinding\n\n## YAML 설정\n\nRBAC과 서비스어카운트(ServiceAccount) 설정은 개별 키로 되어야 한다.\n둘은 별개의 것이다.\n이 두가지 개념을 YAML 내에서 구분함으로써 둘 사이의 애매함을 없애고 명확히 할 수 있다.\n\n```yaml\nrbac:\n  # RBAC 리소스를 생성할지 지정\n  create: true\n\nserviceAccount:\n  # 서비스어카운트를 생성할지 지정\n  create: true\n  # 사용할 서비스어카운트 이름\n  # create가 true인데 이름이 지정되지 않으면, 풀네임 템플릿에 따라 이름이 생성됨\n  name:\n```\n\n이 구조는 여러 개의 서비스어카운트를 필요로 하는 더 복잡한 차트로 확장할 수 있다.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## RBAC 리소스는 기본값으로 생성해야 한다\n\n`rbac.create`는 RBAC 리소스를 생성할지를 컨트롤하는 불리언 값이어야 한다.\n기본값은 `true`여야 한다.\nRBAC 접근 제어를 직접 관리하려는 사용자는\n이 값을 `false`로 지정할 수 있다. (아래의 사례 참고)\n\n## RBAC 리소스 사용하기\n\n`serviceAccount.name`는 차트로 생성된 접근제어 리소스가 사용할\nServiceAccount 이름으로 설정해야 한다.\n`serviceAccount.create`가 true이면, 그 이름으로 서비스어카운트가 생성된다.\n이름이 설정되지 않았다면 `fullname` 템플릿을 사용하여 이름이 생성된다.\n`serviceAccount.create`이 false이면, 서비스어카운트가 생성되지는 않지만,\n나중에 RBAC 리소스를 수동으로 생성하고 참조하여 정상 작동하게 하려면 동일한 리소스들과 연계되어야 한다.\n`serviceAccount.create`가 false이고 이름이 지정되지 않으면, 기본 서비스어카운트를 사용한다.\n\n서비스어카운트에 다음 헬퍼 템플릿을 사용해야 한다.\n\n```yaml\n{{/*\n사용할 서비스어카운트 이름 생성\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: 템플릿\ndescription: 템플릿에 관한 모범사례 들여다보기\nsidebar_position: 3\n---\n\n이 부분은 모범사례 가이드의 일부로서 템플릿을 자세히 알아본다.\n\n## `templates/`의 구조\n\n`templates/` 디렉토리는 다음과 같이 구조화되어야 한다.\n\n- YAML을 만드는 템플릿 파일들은 확장자가 `.yaml`이어야 한다.\n  형식이 정해지지 않은 컨텐츠를 만드는 템플릿 파일에는 `.tpl` 확장자를 쓸 수\n  있다.\n- 템플릿 파일 이름은 대시 표기법(`my-example-configmap.yaml`)을 따라야 하며,\n  카멜 표기법이 아니다.\n- 각 리소스 정의는 자체 템플릿 파일 내에 있어야 한다.\n- 템플릿 파일 이름은 이름 내에 리소스 종류를 반영해야 한다. 예 :\n  `foo-pod.yaml`,`bar-svc.yaml`\n  \n## 정의된 템플릿의 이름\n\n정의된 템플릿 (`{{ define }}` 지시문 내에 생성된 템플릿)은\n전역에서 접근가능하다. 즉, 차트와 그 모든 하위 차트는\n`{{ define }}` 으로 생성된 모든 템플릿에 접근할 수 있다.\n\n위와 같은 이유로, _모든 정의된 템플릿 이름은 네임스페이스별로 구분되어야 한다._\n\n올바른 경우:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\n잘못된 경우:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\n이 모범 사례에 따라 템플릿 이름이 자동으로 정의되므로,\n`helm create` 명령을 통해 새 차트를 생성하는 것이 좋다.\n\n## 템플릿 형식\n\n템플릿은 _스페이스 2개_ (탭 아님)를 사용하여 들여쓰기 해야 한다.\n\n템플릿 지시문에서 여는 중괄호 뒤와 닫는 중괄호 앞에는\n공백을 두어야 한다.\n\n올바른 경우:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\n잘못된 경우:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\n템플릿은 가능한 경우 공백을 줄여야 한다.\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\n블록 (예 : 제어 구조)은 템플릿 코드의 흐름을 나타내기 위해\n들여쓰기 할 수 있다.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\n하지만, YAML은 공백 지향 언어이기 때문에, \n규칙에 따른 코드 들여쓰기가 불가능한 경우가 많다.\n\n## 생성된 템플릿의 화이트스페이스\n\n생성된 템플릿의 공백을 최소로 유지하는 것이 좋다.\n특히, 많은 수의 빈 줄이 서로 인접해 있으면 안된다.\n그러나 가끔씩 나오는 빈 줄(특히 논리 섹션 사이)은 \n무방하다.\n\n가장 좋은 경우:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\n괜찮은 경우:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\n지양해야 할 경우:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## 주석 (YAML 주석 vs. 템플릿 주석)\n\nYAML과 헬름 템플릿 모두 주석 마커가 있다.\n\nYAML 주석:\n```yaml\n# This is a comment\ntype: sprocket\n```\n\n템플릿 주석:\n```yaml\n{{- /*\nThis is a comment.\n*/}}\ntype: frobnitz\n```\n\n정의된 템플릿 설명과 같이 템플릿의 기능을 문서화할 때는,\n템플릿 주석을 사용해야 한다.\n\n```yaml\n{{- /*\nmychart.shortname 은 릴리스 이름에서 6자만 자른 것을 제공한다.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\n템플릿 내에서, YAML 주석은 헬름 사용자가 디버깅 중에 주석을 볼 때\n유용하게 사용될 수 있다.\n\n```yaml\n# 값이 100Gi를 넘으면 문제가 발생할 수 있다\nmemory: {{ .Values.maxMem | quote }}\n```\n\n위의 주석은 사용자가 `helm install --debug` 를 실행할 때 표시되는데,\n`{{-/ * * /-}}` 섹션에 지정된 주석은 표시되지 않는다.\n\n특정 템플릿 함수에서 필수로 요구될 수 있는 Helm 값이 포함된 템플릿 섹션에 `#` YAML 주석을 추가할 때 주의해야 한다.\n\n예를 들어, 위 예시에 `required` 함수가 추가되고 `maxMem`이 설정되지 않은 경우, `#` YAML 주석은 렌더링 오류를 발생시킨다.\n\n올바른 경우: `helm template`이 이 블록을 렌더링하지 않는다\n```yaml\n{{- /*\n# This may cause problems if the value is more than 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\n잘못된 경우: `helm template`이 `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` 오류를 반환한다\n```yaml\n# This may cause problems if the value is more than 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nYAML 주석이 그대로 유지되는 동작에 대한 다른 예시는 [템플릿 디버깅](../chart_template_guide/debugging.md)을 참고한다.\n\n## 템플릿과 템플릿 출력에서 JSON 사용하기\n\nYAML은 JSON의 상위집합이다. 경우에 따라서는, JSON 구문을 사용하는 것이\n다른 YAML 표현보다 더 읽기 쉬울 수 있다.\n\n예를 들어, 이 YAML은 목록을 표현하는 일반적인 YAML 방법에 더 가깝다.\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\n그러나 JSON 목록 스타일로 축약하면 읽기가 더 쉽다.\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\n가독성을 높이기 위해 JSON을 사용하는 것은 좋다. 하지만, 더 복잡한 구조를 나타내는 데에\nJSON 구문을 사용해서는 안된다.\n\nYAML (예를 들어 init 컨테이너 설정)에 포함된 순수 JSON을 다룰 때에는,\n당연히 JSON 형식을 사용하는 것이 적절하다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: 값\ndescription: 값을 구성하고 사용하는 방법을 집중적으로 다룬다.\nsidebar_position: 2\n---\n\n이 부분은 모범사례 가이드의 일부로서 값(values)을 사용하는 방법을 다룬다.\n여기서는 차트의 `values.yaml` 파일을 설계하는 데 초점을 맞추고, 값을 어떻게 구성하고 사용할지에 대한 권고사항을 제시한다.\n\n## 네이밍 컨벤션\n\n변수 이름은 소문자로 시작해야하며 단어는 카멜케이스로 \n구분해야 한다.\n\n올바른 경우:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\n잘못된 경우:\n\n```yaml\nChicken: true  # 첫 글자가 대문자이면 빌트인 변수와 충돌이 발생할 수 있다\nchicken-noodle-soup: true # 변수명에 하이픈(-)을 사용하지 말자\n```\n\n헬름의 모든 빌트인 변수는 사용자 정의 값과 쉽게 구분할 수 있도록\n대문자로 시작한다: `.Release.Name`,\n`.Capabilities.KubeVersion`.\n\n## 평면화(flat) 값, 중첩된(nested) 값\n\nYAML 은 유연한 형식으로, 값은 깊게 중첩되거나 평면화 될 수 있다.\n\n중첩된 경우:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\n평면화된 경우:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\n대부분의 경우, 중첩된 경우보다는 평면화된 경우를 선호하게 된다. 그 이유는 템플릿 개발자와\n사용자에게 더 간단하기 때문이다.\n\n\n최적의 안전성을 위해, 모든 수준에서 중첩된 값을 확인해야 한다.\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\n모든 중첩된 계층에 대하여 존재 유무를 점검해야 한다. 다만 평면화된\n구성의 경우, 이러한 검사를 건너뛸 수 있으므로 템플릿을 더 쉽게 읽고\n사용할 수 있다.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\n관련 변수가 많고 그 중 하나 이상이 선택 사항이 아닌 경우, 중첩된 값을\n사용하여 가독성을 높일 수 있다.\n\n## 자료형을 명확히 하자\n\nYAML 의 유형에 대한 강제적인 규칙은 때때로 직관적이지 못하다. 예를 들어\n`foo: false` 는 `foo: \"false\"` 와 동일하지 않다. `foo: 12345678` 과 같은\n큰 정수는 경우에 따라 수학적 표기법으로 변환된다.\n\n유형 변환 오류를 피하는 가장 쉬운 방법은 문자열에 대해서만 명시하고 이 외에는 명시하지 않는 것이다.\n혹은 더 간단하게, _모두 인용부호로 감싸서 문자열로 만드는 것이다_. \n\n종종 정수형의 캐스팅 문제를 방지하기위해, 정수도 문자열로 저장하고 템플릿에서 \n`{{ int $value }}` 를 사용하여 문자열에서 다시 정수로 변환하는 것이\n유리하다.\n\n대부분의 경우 명시적 유형 태그가 존중되므로 `foo: !!string 1234` 는\n`1234` 를 문자열로 처리해야 한다. _그러나_ YAML 파서는 태그를 사용하므로 한번의 구문 분석 후에는\n유형 데이터가 손실된다.\n\n## 사용자가 값을 어떻게 사용할지를 고려하자\n\n값에는 다음과 같은 세 가지 출처가 있다.\n\n- 차트의 `values.yaml` 파일\n- `helm install -f` 또는 `helm upgrade -f` 에서 제공하는 값 파일\n- `helm install` 또는 `helm upgrade` 의 `--set` 또는 `--set-string` 플래그에 \n  전달된 값\n\n값의 구조를 디자인 할 때 차트 사용자는 `-f` 플래그 또는 `--set` \n옵션을 통해 값을 재정의 \n할 수 있다.\n\n`--set` 은 표현력이 더 제한적이므로, `values.yaml` 파일을 작성하기 위한\n첫 번째 지침은, _`--set` 에서 쉽게 재정의 할 수 있도록 하는 것이다_.\n\n이러한 이유로 맵을 사용하여 값 파일을 구조화하는 것이 더 좋다.\n\n`--set` 과 함께 사용하기 어려운 경우\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\n위의 내용은 헬름 `<=2.4` 에서는 `--set` 으로 표현할 수 없다. 헬름 2.5 에서\nfoo 의 포트에 액세스 하는 것은 `--set servers[0].port=80` 이다.\n사용자가 파악하기 어려울 뿐만 아니라 나중에 `서버` 의 순서가 변경되면\n오류가 발생하기 쉽다.\n\n사용하기 쉬운 경우:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nfoo 의 포트에 접근하는 것이 훨씬 명확하다: `--set servers.foo.port=80`.\n\n## `values.yaml`을 문서화하자\n\n`values.yaml` 에 정의된 모든 속성은 문서화 되어야 한다. 문서\n문자열은 설명하는 속성의 이름으로 시작하고 최소한 한 문장으로 된\n설명을 제공해야 한다.\n\n잘못된 경우:\n\n```yaml\n# the host name for the webserver\nserverHost: example\nserverPort: 9191\n```\n\n올바른 경우:\n\n```yaml\n# serverHost is the host name for the webserver\nserverHost: example\n# serverPort is the HTTP listener port for the webserver\nserverPort: 9191\n```\n\n각 주석을 문서화하는 매개 변수의 이름으로 시작하면\n문서를 쉽게 정리할 수 있으며, 문서화 도구가 문서 문자열과 이를 설명하는 매개변수를 안정적으로 연관시킬 수 있게 해준다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: 템플릿 내부 파일 접근하기\ndescription: 템플릿 안에 있는 파일에 접근하는 방법\nsidebar_position: 10\n---\n\n이전 섹션에서 명명된 템플릿을 만들고 접근하는 몇 가지 방법을 살펴보았다.\n이를 통해 다른 템플릿에서 필요한 템플릿을 쉽게 가져올 수 있다.\n하지만 때로는 _템플릿이 아닌 파일_ 을 가져와서\n그 내용을 템플릿 렌더러를 거치지 않고 직접 주입하고 싶을 때가 있다.\n\nHelm은 `.Files` 객체를 통해 파일에 접근할 수 있게 해 준다. 템플릿 예제를 살펴보기 전에\n이 기능이 어떻게 작동하는지 알아야 할 몇 가지가 있다:\n\n- Helm 차트에 추가 파일을 넣어도 된다. 이 파일들은 함께 번들로 묶인다.\n  하지만 주의가 필요하다. Kubernetes 객체의 저장 제한 때문에\n  차트는 1M보다 작아야 한다.\n- 일부 파일은 `.Files` 객체를 통해 접근할 수 없는데,\n  주로 보안상의 이유 때문이다.\n  - `templates/` 안에 있는 파일은 접근할 수 없다.\n  - `.helmignore`를 사용하여 제외된 파일은 접근할 수 없다.\n  - 부모 차트를 포함하여, Helm 애플리케이션 [하위 차트](./subcharts_and_globals.md) 외부에 있는 파일은 접근할 수 없다.\n- 차트는 UNIX 모드 정보를 보존하지 않으므로, `.Files` 객체에 관해서는\n  파일 수준 권한이 파일 가용성에 영향을 미치지 않는다.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [기본 예제](#기본-예제)\n- [경로 헬퍼](#경로-헬퍼)\n- [글롭(Glob) 패턴](#글롭glob-패턴)\n- [ConfigMap과 Secret 유틸리티 함수](#configmap과-secret-유틸리티-함수)\n- [인코딩](#인코딩)\n- [Lines](#lines)\n\n<!-- tocstop -->\n\n## 기본 예제\n\n위의 주의 사항을 알았으니, 이제 세 개의 파일을 읽어서 ConfigMap에 넣는 템플릿을 작성해 보자.\n시작하기 위해 차트에 세 개의 파일을 추가하고, 세 파일 모두 `mychart/` 디렉토리 안에 직접 넣는다.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\n이 파일들은 각각 간단한 TOML 파일이다(옛날 Windows INI 파일을 생각하면 된다).\n파일 이름을 알고 있으므로 `range` 함수를 사용하여 파일들을 순회하며\n그 내용을 ConfigMap에 주입할 수 있다.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\n이 ConfigMap은 이전 섹션에서 논의한 여러 기법을 사용한다.\n예를 들어, `.Files` 객체에 대한 참조를 담기 위해 `$files` 변수를 만든다.\n또한 `tuple` 함수를 사용하여 순회할 파일 목록을 만든다.\n그런 다음 각 파일 이름(`{{ . }}: |-`)을 출력하고 그 뒤에 파일 내용(`{{ $files.Get . }}`)을 출력한다.\n\n이 템플릿을 실행하면 세 파일의 내용이 모두 포함된 단일 ConfigMap이 생성된다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## 경로 헬퍼\n\n파일을 다룰 때, 파일 경로 자체에 대한 표준 작업을 수행하는 것이 매우 유용할 수 있다.\n이를 돕기 위해 Helm은 Go의 [path](https://golang.org/pkg/path/) 패키지에서\n많은 함수를 가져와 사용할 수 있게 해 준다. 이 함수들은 Go 패키지와 같은 이름으로 접근할 수 있지만,\n첫 글자가 소문자이다. 예를 들어, `Base`는 `base`가 된다.\n\n가져온 함수들은 다음과 같다:\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## 글롭(Glob) 패턴\n\n차트가 커지면서 파일을 더 체계적으로 정리해야 할 필요가 생길 수 있다.\n이를 위해 [글롭 패턴](https://godoc.org/github.com/gobwas/glob)의 모든 유연성을 활용하여\n특정 파일을 추출하는 데 도움이 되는 `Files.Glob(pattern string)` 메서드를 제공한다.\n\n`.Glob`은 `Files` 타입을 반환하므로, 반환된 객체에서 `Files`의 모든 메서드를 호출할 수 있다.\n\n예를 들어, 다음과 같은 디렉토리 구조를 상상해 보자:\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nGlob을 사용하는 여러 방법이 있다:\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\n또는\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## ConfigMap과 Secret 유틸리티 함수\n\n(Helm 2.0.2 이후 사용 가능)\n\n파일 내용을 ConfigMap과 Secret에 넣어서 런타임에 파드에 마운트하는 것은 매우 일반적인 작업이다.\n이를 돕기 위해 `Files` 타입에 몇 가지 유틸리티 메서드를 제공한다.\n\n파일을 더 체계적으로 정리하려면 이러한 메서드를 `Glob` 메서드와 함께 사용하는 것이 특히 유용하다.\n\n위의 [글롭(Glob) 패턴](#글롭glob-패턴) 예제에서 나온 디렉토리 구조를 가정하면:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## 인코딩\n\n파일을 가져와서 템플릿이 base-64로 인코딩하도록 하여\n안전한 전송을 보장할 수 있다:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\n위 코드는 이전에 사용했던 동일한 `config1.toml` 파일을 가져와서 인코딩한다:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Lines\n\n때로는 템플릿에서 파일의 각 줄에 접근하는 것이 필요할 수 있다.\n이를 위해 편리한 `Lines` 메서드를 제공한다.\n\n`range` 함수를 사용하여 `Lines`를 순회할 수 있다:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\n`helm install` 중에 차트 외부의 파일을 전달할 방법은 없다.\n따라서 사용자에게 데이터를 제공받으려면 `helm install -f` 또는\n`helm install --set`을 사용하여 로드해야 한다.\n\n이것으로 Helm 템플릿 작성을 위한 도구와 기법에 대한 심층 탐구를 마친다.\n다음 섹션에서는 특별한 파일인 `templates/NOTES.txt`를 사용하여\n차트 사용자에게 설치 후 지침을 보내는 방법을 살펴볼 것이다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: 빌트인 객체\ndescription: 템플릿에서 사용가능한 빌트인 객체\nsidebar_position: 3\n---\n\n객체는 템플릿 엔진에서 템플릿으로 전달된다. 그리고 사용자의 코드는 \n객체를 전달할 수 있다. (`with` 와 `range` 문을 볼 때 \n예제로 확인할 수 있다.) 이후에 보게 될 `tuple` 함수와 같이 \n템플릿 내에서 새로운 객체를 만드는 몇 가지 방법이 있다.\n\n객체는 간단히 하나의 값만 가질 수도 있다. 또는 다른 \n객체나 기능을 포함할 수 있다. 예를 들어, `Release` 객체는 \n(`Release.Name` 과 같은) 여러 객체를 포함하며 `Files` 객체는 몇 가지 함수를 가지고 있다.\n\n이전 섹션에서는 템플릿에 릴리즈 이름을 삽입하기 위해\n`{{.Release.Name}}` 을 사용하였다. `Release` 는 내 템플릿에\n접근할 수 있는 최상위 객체 중 하나이다.\n\n- `Release`: 이 객체는 릴리스 자체를 서술한다. 여러 객체를 가지고 있다.\n  그 내부:\n  - `Release.Name`: 릴리스 이름\n  - `Release.Namespace`: 릴리스될 네임스페이스 (manifest에서\n    오버라이드하지 않은 경우)\n  - `Release.IsUpgrade`: 현재 작업이 업그레이드 또는 롤백인\n    경우 `true` 로 설정된다.\n  - `Release.IsInstall`: 현재 작업이 설치일\n    경우 `true` 로 설정.\n  - `Release.Revision`: 이 릴리스의 리비전 번호. 설치시에는 이 값이 \n    1이며 업그레이드나 롤백을 수행할 때마다 증가한다.\n  - `Release.Service`: 현재 템플릿을 렌더링하는 서비스. Helm 에서는\n    항상 `Helm` 이다.\n- `Values`: `values.yaml` 파일 및 사용자 제공 파일에서 템플릿으로 \n  전달된 값. 기본적으로 `Values` 는 비어 있다.\n- `Chart`: `Chart.yaml` 파일의 내용. `Chart.yaml` 안의 모든 데이터는 여기서 \n  접근 가능하다. 예를 들어 `{{ .Chart.Name }}-{{ .Chart.Version }}` 은 \n  `mychart-0.1.0` 를 출력한다.\n  - 사용가능한 필드는 [차트 가이드](/topics/charts.md#the-chartyaml-file)\n    에 나열되어 있다.\n- `Subcharts`: 부모 차트에서 서브차트의 스코프(.Values, .Charts, .Releases 등)에 \n  접근할 수 있게 해준다. 예를 들어 `.Subcharts.mySubChart.myValue` 로 \n  `mySubChart` 차트의 `myValue` 에 접근할 수 있다.\n- `Files`: 차트 내의 모든 특수하지 않은(non-special) 파일에 대한 접근을 제공한다.\n  템플릿에 접근하는 데에는 사용할 수 없지만, 차트 내의 다른 파일에 접근하는 데에는 사용할 수 있다.\n  자세한 내용은 [파일 접근하기](./accessing_files.md) 섹션을 참고하자.\n  - `Files.Get` 은 이름으로 파일을 가지고 오는 함수이다. (`.Files.Get\n    config.ini`)\n  - `Files.GetBytes` 는 파일의 내용을 문자열이 아닌 \n    바이트 배열로 가져오는 함수이다. 이미지 같은 것을\n    다룰 때 유용하다.\n  - `Files.Glob` 는 이름이 주어진 shell glob 패턴과 \n    매치되는 파일 목록을 반환하는 함수이다.\n  - `Files.Lines` 는 파일을 한 줄씩 읽는 함수이다. 이것은\n    파일 내의 각 행을 순회(iterate)하는데 유용하다.\n  - `Files.AsSecrets` 은 파일 본문을 Base64로 인코딩된 문자열로 반환하는\n    함수이다.\n  - `Files.AsConfig` 는 파일 본문을 YAML 맵으로 반환하는 함수이다.\n- `Capabilities`: 쿠버네티스 클러스터가 지원하는 기능에 대한\n  정보를 제공한다.\n  - `Capabilities.APIVersions` 는 버전의 집합이다.\n  - `Capabilities.APIVersions.Has $version` 은 버전(예:\n    `batch/v1`) 이나 리소스(예: `apps/v1/Deployment`) 를 클러스터에서 사용할 수 있는지\n    여부를 나타낸다.\n  - `Capabilities.KubeVersion` 과 `Capabilities.KubeVersion.Version` 는 쿠버네티스 버전이다.\n  - `Capabilities.KubeVersion.Major` 는 쿠버네티스 메이저 버전이다.\n  - `Capabilities.KubeVersion.Minor` 는 쿠버네티스 마이너 버전이다.\n  - `Capabilities.HelmVersion` 는 Helm 버전 정보를 담고 있는 객체이며, `helm version` 의 출력과 동일하다.\n  - `Capabilities.HelmVersion.Version` 는 semver 형식의 현재 Helm 버전이다.\n  - `Capabilities.HelmVersion.GitCommit` 는 Helm git sha1 이다.\n  - `Capabilities.HelmVersion.GitTreeState` 는 Helm git 트리의 상태이다.\n  - `Capabilities.HelmVersion.GoVersion` 는 사용된 Go 컴파일러의 버전이다.\n- `Template`: 실행 중인 현재 템플릿에 대한 정보를\n  포함한다.\n  - `Name`: 현재 템플릿에 대한 네임스페이스 파일 경로 (예:\n    `mychart/templates/mytemplate.yaml`)\n  - `BasePath`: 현재 차트의 템플릿 디렉토리에 대한 네임스페이스 경로\n    (예: `mychart/templates`).\n\n빌트인 값은 항상 대문자로 시작한다. 이것은 Go의 명명 규칙을 \n따르고 있다. 사용자는 자신만의 이름을 만들 때, 팀에 적합한 \n규칙을 자유롭게 사용할 수 있다. [Artifact Hub](https://artifacthub.io/packages/search?kind=0)에서 \n볼 수 있는 많은 차트를 만든 팀들처럼, 일부 팀에서는 로컬 이름과 빌트인 이름을 \n구분하기 위해 첫 글자로 소문자만 사용하도록 선택한다. 이 가이드에서는 \n해당 규칙을 따른다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: 흐름 제어\ndescription: 템플릿 내부의 흐름 구조에 대한 간단한 개요\nsidebar_position: 7\n---\n\n제어 구조(템플릿 용어로 \"액션\"이라 함)를 사용하면 템플릿 작성자가 템플릿 생성의 흐름을 제어할 수 있다.\nHelm의 템플릿 언어는 다음과 같은 제어 구조를 제공한다.\n\n- `if`/`else` - 조건부 블록 생성\n- `with` - 스코프 지정\n- `range` - \"for each\" 스타일 반복문 제공\n\n이 외에도 명명된(named) 템플릿 세그먼트를 선언하고 사용하기 위한 몇 가지 액션을 제공한다.\n\n- `define` - 템플릿 내부에서 새로운 명명된 템플릿을 선언한다\n- `template` - 명명된 템플릿을 가져온다\n- `block` - 채울 수 있는 특별한 종류의 템플릿 영역을 선언한다\n\n이 섹션에서는 `if`, `with`, `range`에 대해 설명한다. 나머지는 이 가이드의 뒷부분에 있는 \n\"명명된 템플릿\" 섹션에서 다룬다.\n\n## If/Else\n\n가장 먼저 살펴볼 제어 구조는 템플릿에 텍스트 블록을 조건부로 포함하기 위한 것이다.\n이것이 바로 `if`/`else` 블록이다.\n\n조건문의 기본 구조는 다음과 같다.\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\n여기서 값 대신 _파이프라인_ 에 대해 이야기하고 있다는 점에 주목하자.\n이는 제어 구조가 단순히 값을 평가하는 것이 아니라 전체 파이프라인을 실행할 수 있다는 것을 명확히 하기 위함이다.\n\n파이프라인은 다음과 같은 경우 _false_ 로 평가된다.\n\n- 불리언 false\n- 숫자 0\n- 빈 문자열\n- `nil` (비어있거나 null)\n- 빈 컬렉션 (`map`, `slice`, `tuple`, `dict`, `array`)\n\n그 외의 모든 조건에서는 true이다.\n\nConfigMap에 간단한 조건문을 추가해 보자. drink가 coffee로 설정된 경우 다른 설정을 추가할 것이다.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\n이전 예제에서 `drink: coffee`를 주석 처리했으므로 출력에는 `mug: \"true\"` 플래그가 포함되지 않을 것이다.\n하지만 `values.yaml` 파일에 해당 라인을 다시 추가하면 출력은 다음과 같이 된다.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## 공백 제어\n\n조건문을 살펴보는 김에 템플릿에서 공백을 제어하는 방법도 간단히 살펴보자.\n이전 예제를 좀 더 읽기 쉽게 포맷해 보자.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\n처음에는 괜찮아 보인다. 하지만 템플릿 엔진을 통해 실행하면 안타까운 결과를 얻게 된다.\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\n무슨 일이 일어난 걸까? 위의 공백 때문에 잘못된 YAML이 생성되었다.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug`의 들여쓰기가 잘못되었다. 해당 라인의 들여쓰기를 줄이고 다시 실행해 보자.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\n이렇게 보내면 유효한 YAML을 얻게 되지만, 여전히 조금 이상하게 보인다.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nYAML에 몇 개의 빈 줄이 있는 것을 주목하자. 왜 그럴까?\n템플릿 엔진이 실행될 때 `{{`와 `}}` 내부의 내용은 _제거_ 되지만,\n남은 공백은 그대로 유지된다.\n\nYAML은 공백에 의미를 부여하므로 공백 관리가 상당히 중요해진다.\n다행히 Helm 템플릿에는 이를 도와주는 몇 가지 도구가 있다.\n\n첫째, 템플릿 선언의 중괄호 구문에 특수 문자를 추가하여 템플릿 엔진에게\n공백을 제거하도록 지시할 수 있다.\n`{{- `(대시와 공백 추가)는 왼쪽 공백을 제거해야 함을 나타내고,\n` -}}`는 오른쪽 공백을 제거해야 함을 의미한다.\n_주의하자! 개행도 공백이다!_\n\n> `-`와 지시어의 나머지 부분 사이에 공백이 있어야 한다.\n> `{{- 3 }}`은 \"왼쪽 공백을 제거하고 3을 출력\"을 의미하고,\n> `{{-3 }}`은 \"-3을 출력\"을 의미한다.\n\n이 구문을 사용하여 템플릿을 수정하면 새 줄을 제거할 수 있다.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\n이 점을 명확히 하기 위해 위의 내용을 조정하고 이 규칙에 따라 삭제될 각 공백을 `*`로 대체해 보자.\n줄 끝의 `*`는 제거될 개행 문자를 나타낸다.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\n이를 염두에 두고 Helm을 통해 템플릿을 실행하면 다음과 같은 결과를 볼 수 있다.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n공백 제거 수정자를 사용할 때 주의하자. 다음과 같은 실수를 저지르기 쉽다.\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\n이렇게 하면 양쪽의 개행을 모두 제거하여 `food: \"PIZZA\"mug: \"true\"`가 출력된다.\n\n> 템플릿의 공백 제어에 대한 자세한 내용은 [공식 Go 템플릿 문서](https://godoc.org/text/template)를 참조하자.\n\n마지막으로, 템플릿 지시어의 간격을 숙달하려고 노력하는 대신 템플릿 시스템에게 \n들여쓰기를 지정하도록 하는 것이 더 쉬울 때가 있다.\n이런 이유로 `indent` 함수를 사용하는 것이 유용할 때가 있다 (`{{ indent 2\n\"mug:true\" }}`).\n\n## `with`를 사용하여 스코프 수정\n\n다음으로 살펴볼 제어 구조는 `with` 액션이다. 이것은 변수 스코프를 제어한다.\n`.`는 _현재 스코프_ 에 대한 참조임을 상기하자.\n따라서 `.Values`는 템플릿에게 현재 스코프에서 `Values` 객체를 찾으라고 지시한다.\n\n`with`의 구문은 간단한 `if` 문과 유사하다.\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\n스코프는 변경될 수 있다. `with`를 사용하면 현재 스코프(`.`)를 특정 객체로 설정할 수 있다.\n예를 들어, 우리는 `.Values.favorite`로 작업해 왔다.\n`.` 스코프가 `.Values.favorite`를 가리키도록 ConfigMap을 다시 작성해 보자.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\n이전 예제에서 `if` 조건문을 제거했다는 점에 주목하자.\n`PIPELINE`의 값이 비어 있지 않은 경우에만 `with` 뒤의 블록이 실행되기 때문에 \n이제 더 이상 필요하지 않다.\n\n이제 `.drink`와 `.food`를 전체 경로 없이 참조할 수 있다는 점에 주목하자.\n이는 `with` 문이 `.`를 `.Values.favorite`를 가리키도록 설정했기 때문이다.\n`.`는 `{{ end }}` 이후에 이전 스코프로 재설정된다.\n\n하지만 여기서 주의해야 할 점이 있다! 제한된 스코프 내에서는 `.`를 사용하여\n부모 스코프의 다른 객체에 접근할 수 없다. 예를 들어 다음은 실패한다.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name`이 `.`의 제한된 스코프 내에 없기 때문에 오류가 발생한다.\n그러나 마지막 두 줄을 바꾸면 `{{ end }}` 후에 스코프가 재설정되므로 예상대로 작동한다.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\n또는 `$`를 사용하여 부모 스코프에서 `Release.Name` 객체에 접근할 수 있다.\n`$`는 템플릿 실행이 시작될 때 루트 스코프에 매핑되며 템플릿 실행 중에 변경되지 않는다.\n다음도 작동한다.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\n`range`를 살펴본 후, 위의 스코프 문제에 대한 하나의 해결책을 제공하는 \n템플릿 변수에 대해 살펴볼 것이다.\n\n## `range` 액션으로 반복하기\n\n많은 프로그래밍 언어에서 `for` 루프, `foreach` 루프 또는 유사한 함수형 메커니즘을 사용한 \n반복을 지원한다. Helm의 템플릿 언어에서 컬렉션을 반복하는 방법은 `range` 연산자를 사용하는 것이다.\n\n시작하기 위해 `values.yaml` 파일에 피자 토핑 목록을 추가해 보자.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\n이제 `pizzaToppings` 목록(템플릿에서는 `slice`라고 함)이 생겼다.\n템플릿을 수정하여 이 목록을 ConfigMap에 출력할 수 있다.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\n`$`를 사용하여 부모 스코프에서 `Values.pizzaToppings` 목록에 접근할 수 있다.\n`$`는 템플릿 실행이 시작될 때 루트 스코프에 매핑되며 템플릿 실행 중에 변경되지 않는다.\n다음도 작동한다.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\n`toppings:` 목록을 더 자세히 살펴보자. `range` 함수는 `pizzaToppings` 목록을\n\"range over\"(반복) 한다. 하지만 여기서 흥미로운 일이 발생한다.\n`with`가 `.`의 스코프를 설정하는 것처럼 `range` 연산자도 그렇게 한다.\n루프를 통과할 때마다 `.`는 현재 피자 토핑으로 설정된다.\n즉, 처음에는 `.`가 `mushrooms`로 설정된다. 두 번째 반복에서는 `cheese`로 설정되는 식이다.\n\n`.`의 값을 파이프라인으로 직접 보낼 수 있으므로 `{{ . | title | quote }}`를 실행하면\n`.`를 `title`(타이틀 케이스 함수)로 보낸 다음 `quote`로 보낸다.\n이 템플릿을 실행하면 출력은 다음과 같다.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\n이 예제에서는 약간의 트릭을 사용했다. `toppings: |-` 줄은 여러 줄 문자열을 선언한다.\n따라서 토핑 목록은 실제로 YAML 목록이 아니라 큰 문자열이다.\n왜 이렇게 할까? ConfigMap의 `data`는 키와 값이 모두 단순 문자열인 키/값 쌍으로 구성되기 때문이다.\n이것이 왜 그런지 이해하려면 [Kubernetes ConfigMap 문서](https://kubernetes.io/docs/concepts/configuration/configmap/)를 참조하자.\n하지만 우리에게 이 세부 사항은 그다지 중요하지 않다.\n\n> YAML의 `|-` 마커는 여러 줄 문자열을 취한다. 이것은 여기서 예시된 것처럼\n> 매니페스트 내부에 큰 데이터 블록을 포함하는 데 유용한 기술일 수 있다.\n\n때때로 템플릿 내부에서 목록을 빠르게 만들고 해당 목록을 반복하는 것이 유용하다.\nHelm 템플릿에는 이를 쉽게 만드는 함수가 있다: `tuple`.\n컴퓨터 과학에서 튜플은 고정 크기이지만 임의의 데이터 타입을 가진 목록과 유사한 컬렉션이다.\n이것은 `tuple`이 사용되는 방식을 대략적으로 전달한다.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\n위의 내용은 다음과 같이 출력된다.\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\n목록과 튜플 외에도 `range`는 키와 값이 있는 컬렉션(`map` 또는 `dict` 같은)을 반복하는 데 \n사용할 수 있다. 다음 섹션에서 템플릿 변수를 소개할 때 그 방법을 살펴볼 것이다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"부록: Go 자료형과 템플릿\"\ndescription: 템플릿에서의 변수에 관한 간단한 개괄\nsidebar_position: 16\n---\n\n헬름 템플릿 언어는 강한 타이핑(strongly typed)인 Go 프로그래밍 언어로 구현된다.\n이러한 이유로, 템플릿에서의 변수는 _타이핑(typed)_된다.\n대부분의 경우, 변수는 다음 자료형 중 하나로 노출된다.\n\n- string: 텍스트 문자열\n- bool: `true` 또는 `false`\n- int: 정수 값 (8, 16, 32, 64 비트의 부호가 있거나(signed) 없는(unsigned) 다양한 자료형이 있다)\n- float64: 64비트 부동 소수점 값 (8, 16, 32 비트의 다양한 자료형이 있다)\n- byte slice(`[]byte`), 흔히 (잠재적으로) 바이너리 데이터를 담기 위해 사용된다.\n- struct(구조체): 프로퍼티와 메소드를 가지는 객체\n- 위의 자료형 중 하나에 대한 슬라이스(인덱스 있는 리스트)\n- 위의 자료형 중 하나에 대한 문자열-키 맵(`map[string]interface{}`)\n\nGo에는 다른 여러가지 자료형이 있는데, 템플릿에서는 때에 따라 자료형을 변환해야 할 수도 있다.\n객체 자료형을 디버그하는 가장 쉬운 방법은 템플릿 내에서 자료형을 출력하는 `printf \"%T\"`에 전달하는 것이다.\n또한 `typeOf`과 `kindOf` 함수도 살펴보자.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: 템플릿 디버깅\ndescription: 배포에 실패한 차트의 트러블슈팅\nsidebar_position: 13\n---\n\n렌더링된 템플릿이 쿠버네티스 API 서버로 전송될 때 문서 형식 \n이외의 이유로 YAML 파일들이 거부될 수 있기 때문에,\n템플릿 디버깅은 다소 까다로울 수 있다.\n\n디버깅에 도움이 되는 몇 가지 명령어들이 있다.\n\n- `helm lint` 는 내 차트가 모범 사례에 맞는지 검증하는 믿을만한\n  도구이다.\n- `helm template --debug` 는 차트 템플릿을 로컬에서 테스트 렌더링한다.\n- `helm install --dry-run --debug` 도 차트를 로컬에서 렌더링하지만, 실제로 설치하지는 \n  않는다. 클러스터에서 충돌하는 리소스가 이미 실행 중인지도 확인한다.\n  `--dry-run=server`를 설정하면 차트의 `lookup` 함수도 서버를 대상으로\n  실행한다.\n- `helm get manifest`: 서버에 어떤 템플릿들이 설치되어 있는지 알아 볼 수 있는 유용한 \n  방법이다.\n\n내 YAML이 파싱에 실패했지만, 무엇이 생성되는지를 확인해보고 싶을 때,\n템플릿에서 문제가 되는 섹션을 주석처리하고 `helm install --dry-run --debug` 를 다시 실행해보면\nYAML 을 쉽게 확인해 볼 수 있다.\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\n윗쪽 내용은 렌더링되고 주석은 그대로 반환된다.\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\n이렇게 하면 YAML 파싱 오류로 인한 차단 없이 생성되는 내용을 빠르게\n확인해 볼 수 있다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: 템플릿 함수 목록\ndescription: 헬름에서 사용가능한 템플릿 함수에 대한 목록\nsidebar_position: 6\n---\n\n헬름에는 템플릿에서 활용할 수 있는 많은 템플릿 함수들이 포함되어 있다.\n여기에 나열되며 다음 범주로 분류된다.\n\n* [암호화 및 보안](#암호화-및-보안-함수)\n* [날짜](#날짜-함수)\n* [사전](#사전-및-사전-함수)\n* [인코딩](#인코딩-함수)\n* [파일 경로](#파일-경로-함수)\n* [쿠버네티스 및 차트](#쿠버네티스-및-차트-함수)\n* [논리 및 흐름 제어](#논리-및-흐름-제어-함수)\n* [목록](#목록-및-목록-함수)\n* [수학](#수학-함수)\n* [실수 수학](#실수-수학-함수)\n* [네트워크](#네트워크-함수)\n* [리플렉션](#리플렉션-함수)\n* [정규 표현식](#정규-표현식)\n* [유의적 버전](#유의적-버전-함수)\n* [문자열](#문자열-함수)\n* [형 변환](#형-변환-함수)\n* [URL](#url-함수)\n* [UUID](#uuid-함수)\n\n## 논리 및 흐름 제어 함수\n\n헬름은 \n[and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), \n[ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or) 를\n포함한 수많은 논리 및 흐름 제어 기능이 포함되어 있다.\n\n### and\n\n두 인수의 불리언 and를 반환한다.\n\n```\nand .Arg1 .Arg2\n```\n\n### or\n\n두 인수의 불리언 or를 반환한다. \n비어 있지 않은 첫 번째 인수 또는 마지막 인수를 반환한다.\n\n```\nor .Arg1 .Arg2\n```\n\n### not\n\n인수의 불리언 부정을 반환한다.\n\n```\nnot .Arg\n```\n\n### eq\n\n인수들이 같은지 여부를 불리언으로 반환한다. (예: Arg1 == Arg2)\n\n```\neq .Arg1 .Arg2\n```\n\n### ne\n\n인수들이 같지 않은지 여부를 불리언으로 반환한다. (예: Arg1 != Arg2)\n\n```\nne .Arg1 .Arg2\n```\n\n### lt\n\n첫 번째 인수가 두 번째 인수보다 작으면 불리언 true를 반환한다. \n그렇지 않으면 False가 반환된다 (예 : Arg1 < Arg2).\n\n```\nlt .Arg1 .Arg2\n```\n\n### le\n\n첫 번째 인수가 두 번째 인수보다 작거나 같은 경우 불리언 true를 반환한다. \n그렇지 않으면 False가 반환된다 (예 : Arg1 <= Arg2).\n\n```\nle .Arg1 .Arg2\n```\n\n### gt\n\n첫 번째 인수가 두 번째 인수보다 크면 불리언 true를 반환한다. \n그렇지 않으면 False가 반환된다 (예 : Arg1 > Arg2).\n\n```\ngt .Arg1 .Arg2\n```\n\n### ge\n\n첫 번째 인수가 두 번째 인수보다 크거나 같은 경우 불리언 true를 반환한다. \n그렇지 않으면 False가 반환된다 (예 : Arg1 >= Arg2).\n\n```\nge .Arg1 .Arg2\n```\n\n### default\n\n간단한 기본값을 설정하려면 `default`를 사용한다.\n\n```\ndefault \"foo\" .Bar\n```\n\n위에서 `.Bar` 가 비어 있지 않은 값으로 평가되면 사용된다. \n하지만 비어 있으면 `foo` 가 대신 반환된다.\n\n\"비어 있음\"의 정의는 다음의 유형을 따른다.\n\n- 숫자: 0\n- 문자열: \"\"\n- 리스트형: `[]`\n- 딕셔너리형: `{}`\n- 불리언: `false`\n- `nil` 의 경우 항상 (null 이라고도 함)\n\n구조체의 경우 비어 있다는 정의가 없으므로, 구조체는\n기본값을 반환하지 않는다.\n\n### empty\n\n`empty` 함수는 주어진 값이 비어 있다고 간주되면 `true` 를 반환하고 \n그렇지 않으면 `false` 를 반환한다. 빈 값은 `default` 섹션에 나열된다.\n\n```\nempty .Foo\n```\n\nGo 템플릿 조건부에서는 비어 있음이 자동으로 계산된다. \n따라서 `if not empty .Foo` 는 거의 필요하지 않다. 대신 `if .Foo` 를 사용하도록 하자.\n\n### fail\n\n지정된 텍스트와 함께 빈 `문자열` 과 `오류` 를 무조건 반환한다. \n이는 다른 조건에서 템플릿 렌더링이 실패해야 한다고 \n결정한 시나리오에서 유용하다.\n\n```\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\n`coalesce` 함수는 값 목록을 가져와 비어 있지 않은 \n첫 번째 값을 반환한다.\n\n```\ncoalesce 0 1 2\n```\n\n위의 경우 `1` 을 반환한다.\n\n이 함수는 여러 변수 또는 값을 스캔하는데 유용하다.\n\n```\ncoalesce .name .parent.name \"Matt\"\n```\n\n위 코드는 먼저 `.name` 이 비어 있는지 확인한다. \n그렇지 않은 경우 해당 값을 반환한다. \n비어있는 경우 `coalesce` 는 `.parent.name` 이 비어 있는지 평가한다. \n마지막으로 `.name` 과 `.parent.name` 이 모두 비어 있으면 `Matt` 를 반환한다.\n\n### ternary\n\n`삼항(ternary)` 함수는 두 개의 값과 테스트 값을 취한다. \n테스트 값이 참이면 첫 번째 값이 반환된다. \n테스트 값이 비어 있으면 두 번째 값이 반환된다. 이것은 C 언어의 삼항 연산자와 유사하다.\n\n#### true 테스트 값\n\n```\nternary \"foo\" \"bar\" true\n```\n\n또는\n\n```\ntrue | ternary \"foo\" \"bar\"\n```\n\n위의 결과는 `\"foo\"` 를 반환한다.\n\n#### false 테스트 값\n\n```\nternary \"foo\" \"bar\" false\n```\n\n또는\n\n```\nfalse | ternary \"foo\" \"bar\"\n```\n\n위의 결과는 `\"bar\"` 를 반환한다.\n\n## 문자열 함수\n\n헬름은 다음과 같은 문자열 함수들을 포함한다. \n[abbrev](#abbrev),[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat),\n[contains](#contains), [hasPrefix](#hasprefix-및-hassuffix),\n[hasSuffix](#hasprefix-및-hassuffix), [indent](#indent), [initials](#initials),\n[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent),\n[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf),\n[println](#println), [quote](#quote-및-squote),\n[randAlpha](#randalphanum-randalpha-randnumeric-randascii),\n[randAlphaNum](#randalphanum-randalpha-randnumeric-randascii),\n[randAscii](#randalphanum-randalpha-randnumeric-randascii),\n[randNumeric](#randalphanum-randalpha-randnumeric-randascii),\n[repeat](#repeat), [replace](#replace), [shuffle](#shuffle),\n[snakecase](#snakecase), [squote](#quote-및-squote), [substr](#substr),\n[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall),\n[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc),\n[untitle](#untitle), [upper](#upper), [wrap](#wrap), [wrapWith](#wrapwith).\n\n### print\n\n일부의 조합에서 문자열을 반환한다.\n\n```\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\n문자열이 아닌 유형은 가능한 경우 문자열로 변환된다.\n\n서로 옆에 있는 두 인수가 문자열이 아닌 경우 그 사이에 \n공백이 추가된다.\n\n### println\n\n[print](#print) 와 같은 방식으로 동작하지만, 끝에 새 줄을 추가한다.\n\n### printf\n\n형식화 문자열과 순서대로 전달할 인수를 기반으로 문자열을 \n반환한다.\n\n```\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\n사용할 자리 표시자는 전달되는 인수의 유형에 따라 다르다.\n여기에는 다음이 포함된다.\n\n일반적인 목적:\n\n* `%v` 기본 형식의 값\n  * 사전형 출력의 경우, 더하기 플래그(%+v) 는 필드 이름을 추가\n* `%%` 는 리터럴 퍼센트 기호로  값을 소비하지 않음\n\n불리언:\n\n* `%t` 단어 true 또는 false\n\n정수:\n\n* `%b` 2진법\n* `%c` 해당 유니코드 포인트가 표현하는 문자\n* `%d` 10진법\n* `%o` 8진법\n* `%O` 접두사 0 이 있는 8진법\n* `%q` 홑따옴표로 묶인 문자는 안전하게 통과(escaped)\n* `%x` a-f 의 소문자를 사용하는 16진법\n* `%X` A-F 의 대문자를 사용하는 16진법\n* `%U` 유니코드 형식: U+1234(\"U+%04X\"와 동일)\n\n부동 소수점 및 복잡한 요소:\n\n* `%b` 지수가 2의 거듭제곱인, 십진수가 없는 과학적 표기법. 예를 들어,\n  -123456p-78\n* `%e` 과학적 표기법. 예: -1.234456e+78\n* `%E` 과학적 표기법. 예: -1.234456E+78\n* `%f` 지수가 없는 소수점. 예: 123.456\n* `%F` %f 와 동일\n* `%g` 지수가 클 경우 %e, 그렇지 않은 경우 %f.\n* `%G` 지수가 클 경우 %E, 그렇지 않은 경우 %F.\n* `%x` (두 지수의 10진수 거듭제곱 형태의) 16진수 표기법, 예를 들어,\n  -0x1.23abcp+20\n* `%X` 대문자 16진수 표기법. 예를 들어, -0X1.23ABCP+20\n\n바이트의 문자열 또는 슬라이스(이러한 동사들과 동일하게 취급):\n\n* `%s` 문자열 또는 슬라이스의 해석되지 않은 바이트\n* `%q` 안전하게 이스케이프된 겹따옴표 문자열\n* `%x` 16진법, 소문자이며 바이트 당 2자\n* `%X` 16진법, 대문자이며 바이트 당 2자\n\n슬라이스:\n\n* `%p` 0x로 시작하는, 16 진수 표기에서의 0번째 요소의 주소\n\n### trim\n\n`trim` 함수는 문자열의 양쪽에서 공백을 제거한다.\n\n```\ntrim \"   hello    \"\n```\n\n위 결과는 `hello` 이다.\n\n### trimAll\n\n문자열의 앞뒤에서 주어진 문자를 제거한다.\n\n```\ntrimAll \"$\" \"$5.00\"\n```\n\n위 결과는 (문자열인) `5.00` 이다.\n\n### trimPrefix\n\n문자열에서 접두어만 제거한다.\n\n```\ntrimPrefix \"-\" \"-hello\"\n```\n\n위 결과는 `hello` 를 반환한다.\n\n### trimSuffix\n\n문자열에서 접미어만 제거한다.\n\n```\ntrimSuffix \"-\" \"hello-\"\n```\n\n위 결과는 `hello` 를 반환한다.\n\n### lower\n\n전체 문자열을 소문자로 변환한다.\n\n```\nlower \"HELLO\"\n```\n\n위 결과는 `hello` 를 반환한다.\n\n### upper\n\n전체 문자열을 대문자로 반환한다.\n\n```\nupper \"hello\"\n```\n\n위 결과는 `HELLO` 를 반환한다.\n\n### title\n\n제목의 형식으로 변환한다.\n\n```\ntitle \"hello world\"\n```\n\n위 결과는 `Hello World` 반환한다.\n\n### untitle\n\n제목의 형식을 제거한다. `untitle \"Hello World\"` 는 `hello world` 를 반환한다..\n\n### repeat\n\n문자열을 여러 번 반복한다.\n\n```\nrepeat 3 \"hello\"\n```\n\n위의 결과는 `hellohellohello` 를 반환한다.\n\n### substr\n\n문자열에서 부분문자열을 가져온다. 세가지 매개변수가 필요하다.\n\n- 시작 지점 (int)\n- 끝 지점 (int)\n- 원본 문자열 (string)\n\n```\nsubstr 0 5 \"hello world\"\n```\n\n위 결과는 `hello` 를 반환한다.\n\n### nospace\n\n문자열에서 모든 공백을 제거한다.\n\n```\nnospace \"hello w o r l d\"\n```\n\n위 결과는 `helloworld` 를 반환한다.\n\n### trunc\n\n문자열을 자른다.\n\n```\ntrunc 5 \"hello world\"\n```\n\n위 결과는 `hello` 을 반환한다.\n\n```\ntrunc -5 \"hello world\"\n```\n\n위 결과는 `world` 를 반환한다.\n\n### abbrev\n\n줄임표 (`...`) 로 문자열을 자른다.\n\n매개변수:\n\n- 최대 길이\n- 문자열\n\n```\nabbrev 5 \"hello world\"\n```\n\n위 결과는 최대 길이에 대해 너비를 계산하므로, `he...` 를\n반환한다.\n\n### abbrevboth\n\n양쪽을 축약한다.\n\n```\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\n위 결과는 `...5678...` 를 반환한다.\n\n다음이 필요하다.\n\n- 왼쪽 오프셋\n- 최대 길이\n- 원본 문자열\n\n### initials\n\n주어진 여러 단어에서, 각 단어의 첫 단어를 취하고 결합한다.\n\n```\ninitials \"First Try\"\n```\n\n위 결과는 `FT` 를 반환한다.\n\n### randAlphaNum, randAlpha, randNumeric, randAscii\n\n이 네 가지 함수는 암호화적으로 안전한 (```crypto/rand``` 사용) 임의의 문자열을 생성하지만 \n기본 문자 집합은 상이하다.\n\n- `randAlphaNum` 는 `0-9a-zA-Z` 를 사용한다\n- `randAlpha` 는 `a-zA-Z` 를 사용한다\n- `randNumeric` 는 `0-9` 를 사용한다\n- `randAscii` 는 출력가능한 모든 ASCII 문자를 사용한다\n\n각각은 하나의 매개 변수, 즉 문자열의 정수 길이를 취한다.\n\n```\nrandNumeric 3\n```\n\n위 결과는 3자리 숫자로 된 임의의 문자열을 생성한다.\n\n### wrap\n\n주어진 열 개수로 텍스트를 래핑(wrap)한다.\n\n```\nwrap 80 $someText\n```\n\n위 결과는 80 번째 열에서 `$someText`의 문자열을 래핑한다.\n\n### wrapWith\n\n`wrapWith` 는 `wrap` 로 작동하지만, 래핑할 문자열을 지정할 수 있다.\n(`wrap` 은 `\\n` 을 사용)\n\n```\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\n위는 `hello world` 를 생성한다. \n(여기서 공백은 ASCII 탭 문자이다.)\n\n### contains\n\n한 문자열이 다른 문자열 안에 포함되어 있는지 테스트한다.\n\n```\ncontains \"cat\" \"catch\"\n```\n\n위 결과는 `catch` 에 `cat` 이 포함되어 있으므로 `true` 를 반환한다.\n\n### hasPrefix 및 hasSuffix\n\n`hasPrefix` 및 `hasSuffix` 함수는 문자열에 주어진 접두어 또는 접미어가 있는지\n여부를 테스트한다.\n\n```\nhasPrefix \"cat\" \"catch\"\n```\n\n위 결과는 `catch` 에 접두사 `cat` 이 있으므로, `true` 를 반환한다.\n\n### quote 및 squote\n\n이 함수는 문자열을 겹따옴표(\"quote\") 또는 홑따옴표(`quote`)로\n묶는다.\n\n### cat\n\n`cat` 함수는 여러 문자열을 하나로 결합하고\n공백으로 구분한다.\n\n```\ncat \"hello\" \"beautiful\" \"world\"\n```\n\n위 결과는 `hello beautiful world` 이다.\n\n### indent\n\n`indent` 함수는 주어진 문자열의 모든 줄을 지정된 들여쓰기 너비로 들여쓴다.\n이것은 여러 줄 문자열을 정렬할 때 유용하다.\n\n```\nindent 4 $lots_of_text\n```\n\n위 결과는 모든 텍스트 줄을 4개의 공백 문자로 들여쓴다.\n\n### nindent\n\n`nindent` 함수는 indent 함수와 동일하지만 문자열 시작 부분에\n새 줄을 추가한다.\n\n```\nnindent 4 $lots_of_text\n```\n\n위 결과는 모든 텍스트 줄을 공백 문자 4개로 들여쓰기하고 시작\n부분에 새 줄을 추가한다.\n\n### replace\n\n간단한 문자열 교체를 수행한다.\n\n3가지 인수를 필요로 한다.\n\n- 대체할 문자열\n- 대체될 문자열\n- 원본 문자열\n\n```\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\n위 결과는 `I-Am-Henry-VIII` 이다.\n\n### plural\n\n문자열을 복수(plural)화 한다.\n\n```\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\n위에서 문자열의 길이가 1이면 첫 번째 인수(`one anchovy`)가 출력된다. \n그렇지 않으면 두 번째 인수(`many anchovies`)가\n출력된다.\n\n인수는 다음과 같다.\n\n- 단수 문자열\n- 복수 문자열\n- 길이 정수\n\n참고: 헬름은 현재로서는 더 복잡한 복수화 규칙이 있는 언어를 지원하지 않는다.\n그리고 `0` 은, 영어가 그렇게 취급하기 때문에, 복수형으로 \n간주 된다. (`zero anchovies`)\n\n### snakecase\n\ncamelCase에서 snake_case로 변환한다.\n\n```\nsnakecase \"FirstName\"\n```\n\n위 결과는 `first_name` 이다.\n\n### camelcase\n\nsnake_case에서 camelCase로 변환한다.\n\n```\ncamelcase \"http_server\"\n```\n\n위 결과는 `HttpServer` 이다.\n\n### kebabcase\n\ncamelCase에서 kebab-case로 변환한다.\n\n```\nkebabcase \"FirstName\"\n```\n\n위 결과는 `first-name` 이다.\n\n### swapcase\n\n단어 기반 알고리즘을 사용하여 문자열의 대소문자를 바꾼다.\n\n변환 알고리즘:\n\n- 대문자는 소문자로 변환한다\n- 제목 형식의 문자는 소문자로 변환한다\n- 공백 뒤 또는 시작시의 소문자는 제목 형식의 대소문자로 변환한다\n- 기타 소문자는 대문자로 변환한다\n- 화이트스페이스는 unicode.IsSpace(char)로 정의된다\n\n```\nswapcase \"This Is A.Test\"\n```\n\n위 결과는 `tHIS iS a.tEST` 이다.\n\n### shuffle\n\n문자열을 섞는다.\n\n```\nshuffle \"hello\"\n```\n\n위 결과는 `hello` 의 문자를 무작위로 변경하여, `oelhl` 일 수도 있다.\n\n## 형 변환 함수\n\n헬름에서 제공하는 형 변환 함수는 다음과 같다.\n\n- `atoi`: 문자열을 정수로 변환한다.\n- `float64`: `float64` 로 변환한다.\n- `int`: 시스템 기준의 `int` 로 변환한다.\n- `int64`: `int64` 로 변환한다.\n- `toDecimal`: 유닉스 8진수를 `int64` 로 변환한다.\n- `toString`: 문자열로 변환한다.\n- `toStrings`: 목록, 슬라이스 또는 배열을 문자열 목록으로 변환한다.\n- `toJson` (`mustToJson`): 목록, 슬라이스, 배열, 사전형 또는 객체를 JSON 으로 변환한다.\n- `toPrettyJson` (`mustToPrettyJson`): 목록, 슬라이스, 배열, 사전형 또는 객체를 들여쓰기 된 \n  JSON 으로 변환한다.\n- `toRawJson` (`mustToRawJson`): 목록, 슬라이스, 배열, 사전형 또는 객체를\n  HTML 문자가 이스케이프 되지 않은 JSON 으로 변환한다.\n\n`atoi` 함수는 입력이 특정 유형이어야 한다. \n나머지는 모든 유형에서 대상 유형으로 변환을 시도한다. \n예를 들어 `int64` 는 부동 소수점을 정수로 변환 할 수 있으며 문자열을 정수로 변환 할 수도 있다.\n\n### toStrings\n\n목록과 같은 컬렉션이 주어지면 문자열 슬라이스를 생성한다.\n\n```\nlist 1 2 3 | toStrings\n```\n\n위는 결과는 `1` 을 `\"1\"` 로, `2` 를 `\"2\"` 로 변환한 다음 목록으로\n반환한다.\n\n### toDecimal\n\n주어진 유닉스 8진수 권한 값에 대하여, 10진수 값을 생성한다.\n\n```\n\"0777\" | toDecimal\n```\n\n위 코드는 `0777` 을 `511` 로 변환하고 값을 int64 형태로 변환한다.\n\n### toJson, mustToJson\n\n`toJson` 함수는 항목을 JSON 문자열로 인코딩한다. \n항목을 JSON으로 변환 할 수 없는 경우 함수는 빈 문자열을 반환한다. \n`mustToJson` 은 항목을 JSON으로 인코딩할 수 없는 경우 오류를 반환한다.\n\n```\ntoJson .Item\n```\n\n위 결과는 `.Item` 의 JSON 문자열 표현을 반환한다.\n\n### toPrettyJson, mustToPrettyJson\n\n`toPrettyJson` 함수는 항목을 잘 정제된(들여쓰기) JSON 문자열로 \n인코딩한다.\n\n```\ntoPrettyJson .Item\n```\n\n위 결과는 `.Item` 의 들여쓰기된 JSON 문자열 표현을 반환한다.\n\n### toRawJson, mustToRawJson\n\n`toRawJson` 함수는 특정 항목을 HTML 문자가 이스케이프 되지 않은 JSON 문자열로 \n인코딩한다. \n\n```\ntoRawJson .Item\n```\n\n위는 `.Item` 의 이스케이프 처리되지 않은 JSON 문자열 표현을 반환합니다.\n\n## 정규 표현식\n\n헬름에는 다음의 정규식 함수가 표현된다: [regexFind\n(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll\n(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch\n(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll\n(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall),\n[regexReplaceAllLiteral\n(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral),\n[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\n입력 문자열에 정규식과 일치하는 항목이 있으면 true 를 반환한다.\n\n```\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\n위 결과는 `true` 이다.\n\n`regexMatch` 는 문제가 있는 경우 패닉이 발생하며, `mustRegexMatch` 는 문제가 있을 경우\n템플릿 엔진에 오류를 반환한다.\n\n### regexFindAll, mustRegexFindAll\n\n입력 문자열에서 정규식과 일치하는 모든 항목의 슬라이스를 반환한다. \n마지막 매개 변수 n은 반환할 하위 문자열의 수를 결정한다. \n여기서 -1은 모든 일치 항목을 반환함을 의미한다.\n\n```\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\n위 결과는 `[2 4 6 8]` 이다.\n\n`regexFindAll` 은 문제가 있으면 패닉이 발생하며 \n`mustRegexFindAll` 은 문제가 있으면 템플릿 엔진에 오류를 반환한다.\n\n### regexFind, mustRegexFind\n\n입력 문자열에서 정규식의 첫 번째(가장 왼쪽) 일치 항목을 반환한다.\n\n```\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\n위 결과는 `d1` 이다.\n\n`regexFind` 는 문제가 있으면 패닉이 발생하며 \n`mustRegexFind` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다.\n\n### regexReplaceAll, mustRegexReplaceAll\n\n입력 문자열의 복사본을 반환하여 정규 표현식의 일치 항목을 \n교체 문자열로 바꾼다. 문자열 교체 내에서 $ 기호는 \n확장된 차트에서와 같이 해석되므로, 예를 들어 \n$1은 첫 번째 부분의 일치하는 텍스트를 나타낸다.\n\n```\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\n위 결과는 `-W-xxW-` 이다.\n\n`regexReplaceAll` 은 문제가 있는 경우 패닉이 발생하며 \n`mustRegexReplaceAll` 은 문제가 있는 경우 템플릿 엔진에 오류를 반환한다.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\n입력 문자열의 복사본을 반환하고 \n정규 표현식의 일치 항목을 대체 문자열로 변경한다. \n대체 문자열은 확장(Expand)를 사용하지 않고 직접 대체된다.\n\n```\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\n위 결과는 `-${1}-${1}-` 이다.\n\n`regexReplaceAllLiteral` 는 문제가 있으면 패닉이 발생하며,\n`mustRegexReplaceAllLiteral` 는 문제가 있으면 템플릿 엔진에 오류를 \n반환한다.\n\n### regexSplit, mustRegexSplit\n\n입력 문자열을 식으로 구분 된 하위 문자열로 분할하고 \n해당 식 일치 사이의 하위 문자열 슬라이스를 반환한다. \n마지막 매개 변수 `n` 은 반환 할 하위 문자열 수를 결정한다. \n여기서 `-1` 은 모든 일치 항목을 반환 함을 의미한다.\n\n```\nregexSplit \"z+\" \"pizza\" -1\n```\n\n위 결과는 `[pi a]` 이다.\n\n`regexSplit` 은 문제가 있는 경우 패닉이 발생하며 \n`mustRegexSplit` 는 문제가 있는 경우 템플릿 엔진에 오류를 반환한다.\n\n## 암호화 및 보안 함수\n\n헬름은 몇 가지 고급 암호화 함수를 제공한다.\n[adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert),\n[decryptAES](#decryptaes), [derivePassword](#derivepassword),\n[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey),\n[genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert),\n[htpasswd](#htpasswd), [sha1sum](#sha1sum), [sha256sum](#sha256sum).\n\n### sha1sum\n\n`sha1sum` 함수는 문자열을 수신하고 SHA1 다이제스트를 계산한다.\n\n```\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\n`sha256sum` 함수는 문자열을 수신하고 SHA256 다이제스트 값을 계산한다.\n\n```\nsha256sum \"Hello world!\"\n```\n\n위 결과는 출력을 위해 안전한 \"ASCII armored\" 형식의 SHA256 합을 \n계산한다. \n\n### adler32sum\n\n`adler32sum` 함수는 문자열을 수신하고 Adler-32 체크섬을 계산한다.\n\n```\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\n`htpasswd` 함수는 `username` 과 `password` 를 \n가져 와서 패스워드의 `bcrypt` 해시를 생성한다. \n결과는 [아파치 HTTP 서버] (https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic)에서 \n기본 인증에 사용될 수 있다.\n\n```\nhtpasswd \"myUser\" \"myPassword\"\n```\n\n템플릿에 직접 암호를 저장하는 것은 안전하지 않음을 유의하자.\n\n### derivePassword\n\n`derivePassword` 함수는 일부 공유되는 \"마스터 패스워드\" \n제약 조건을 기반으로 특정 패스워드를 도출하는 데 사용할 수 있다. \n이에 대한 알고리즘이 [잘 명세되어] (https://masterpassword.app/masterpassword-algorithm.pdf) 있다.\n\n```\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\n일부를 템플릿에 직접 저장하는 것은 안전하지 않을 수 있다는 점에 유의하자.\n\n### genPrivateKey\n\n`genPrivateKey` 함수는 PEM 블록으로 인코딩된 새 개인키를 \n생성한다.\n\n첫 번째 매개변수의 값 중 하나를 사용한다.\n\n- `ecdsa`: 타원 곡선 DSA 키 생성 (P256)\n- `dsa`: DSA 키 생성 (L2048N256)\n- `rsa`: RSA 4096 키 생성\n\n### buildCustomCert\n\n`buildCustomCert` 함수를 사용하면 커스텀 인증서 설정이 가능하다.\n\n다음의 문자열 매개변수를 사용한다.\n\n- base64 인코딩된 PEM 형식의 인증서\n- base64 인코딩된 PEM 형식의 개인키\n\n다음 속성을 가진 인증서 객체를 반환한다.\n\n- `Cert`: PEM 인코딩 인증서\n- `Key`: PEM 인코딩된 개인 키\n\n예:\n\n```\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\n반환된 객체는 `genSignedCert` 함수에 전달되어 이 CA를 사용하여\n인증서에 서명할 수 있다.\n\n### genCA\n\n`genCA` 함수는 자체 서명된 새로운 x509 인증기관을 생성한다.\n\n다음의 매개 변수를 사용한다.\n\n- 주체의 일반 이름 (common name. cn)\n- 인증서의 유효 기간 (일)\n\n다음 속성을 가진 객체를 반환한다.\n\n- `Cert`: PEM 인코딩 인증서\n- `Key`: PEM 인코딩된 개인키\n\n예:\n\n```\n$ca := genCA \"foo-ca\" 365\n```\n\n반환 된 객체는 `genSignedCert` 함수에 전달되어 이 CA를 사용하여 \n인증서에 서명 할 수 있습니다.\n\n### genSelfSignedCert\n\n`genSelfSignedCert` 함수는 자체 서명 된 새로운 x509 인증서를 생성한다.\n\n다음의 매개 변수를 사용한다.\n\n- 주체의 일반 이름 (cn)\n- 선택적인 IP 목록으로 nil도 가능\n- 선택적인 대체 DNS 이름으로 nil 도 가능\n- 인증서 유효 기간 (일)\n\n다음 속성을 가진 객체를 반환한다.\n\n- `Cert`: PEM 인코딩 인증서\n- `Key`: PEM 인코딩된 개인키\n\n예:\n\n```\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\n`genSignedCert` 함수는 지정된 CA에서 서명 한 새로운 x509 인증서를 \n생성한다.\n\n다음의 매개 변수를 사용한다.\n\n- 주체의 일반 이름 (cn)\n- 선택적인 IP 목록으로 nil도 가능\n- 선택적인 대체 DNS 이름으로 nil 도 가능\n- 인증서 유효 기간 (일)\n- CA (`genCA` 를 참조)\n\n예:\n\n```\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\n`encryptAES` 함수는 AES-256 CBC로 텍스트를 암호화하고 base64 인코딩된 문자열을 \n반환한다.\n\n```\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\n`decryptAES` 함수는 AES-256 CBC 알고리즘으로 인코딩된 base64 문자열을 수신하고 디코딩된 \n텍스트를 반환한다.\n\n```\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## 날짜 함수\n\n헬름에는 템플릿에서 사용할 수 있는 다음의 날짜 함수들이 포함되어 있다.\n[ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify\n(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration),\n[durationRound](#durationround), [htmlDate](#htmldate),\n[htmlDateInZone](#htmldateinzone), [now](#now), [toDate\n(mustToDate)](#todate-musttodate), [unixEpoch](#unixepoch).\n\n### now\n\n현재 날짜/시간으로, 다른 날짜 기능과 함께 사용한다.\n\n### ago\n\n`ago` 함수는 time.Now에서 초 단위로 기간을 반환한다.\n\n```\nago .CreatedAt\n```\n\n`time.Duration` String() 형식을 반환한다.\n\n```\n2h34m7s\n```\n\n### date\n\n`date` 함수는 날짜 형식을 지정한다.\n\n날짜 형식을 YEAR-MONTH-DAY로 지정한다.\n\n```\nnow | date \"2006-01-02\"\n```\n\nGo 에서의 날짜 형식은 \n[조금 상이하다](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\n간단히 말해서, 이것을 기준 날짜로 한다.\n\n```\nMon Jan 2 15:04:05 MST 2006\n```\n\n원하는 형식으로 작성하자.\n위의 경우, `2006-01-02` 와 같은 날짜이지만, 우리가 원하는 형식으로 작성되었다.\n\n### dateInZone\n\n`date` 와 동일하지만, 시간대가 있다.\n\n```\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\n주어진 시간(초)을 `time.Duration` 형식으로 지정한다.\n\n아래의 경우, 1분 35초를 반환한다.\n\n```\nduration 95\n```\n\n### durationRound\n\n주어진 기간을 가장 중요한 단위로 반올림한다. \n문자열과 `time.Duration` 은 기간으로 파싱되며, \n`time.Time` 은 경과한 기간으로 계산된다.\n\n아래의 경우, 2h 를 반환한다.\n\n```\ndurationRound \"2h10m5s\"\n```\n\n이 경우는 3mo를 반환한다.\n\n```\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\n`time.Time` 에 대한 유닉스 시간(unix epoch)를 반환한다.\n\n```\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\n`dateModify` 는 날짜를 가져와서 수정한 후에, 타임 스탬프를 반환한다.\n\n아래의 경우 현재 시간에서 1시간 30분을 뺀 시간을 반환한다.\n\n```\nnow | date_modify \"-1.5h\"\n```\n\n수정 형식이 잘못된 경우 `dateModify` 는 수정되지 않은 날짜를 반환한다.\n`mustDateModify` 는 수정 형식이 잘못된 경우 오류를 반환한다.\n\n### htmlDate\n\n`htmlDate` 함수는 HTML 날짜 선택기 입력 필드에 삽입할 날짜 형식을 \n지정한다.\n\n```\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nhtmlDate 와 동일하지만, 시간대가 추가된다.\n\n```\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\n`toDate` 는 문자열을 날짜로 변환한다. 첫 번째 인수는 날짜 레이아웃이고 두 번째 인수는 날짜 문자열이다. \n문자열을 변환할 수 없으면 0 값을 반환한다. \n`mustToDate` 는 문자열을 변환할 수 없는 경우 오류를 반환한다.\n\n이는 문자열 날짜를 파이프를 사용하여 다른 형식으로 변환하려는 경우에 유용하다. \n아래 예는 \"2017-12-31\" 을 \"31/12/2017\" 로 변환한다.\n\n```\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## 사전 및 사전 함수\n\n헬름은 `dict` (파이썬에서의 \"dictionary\"의 약자) 라는 키/값 저장소 유형을 제공한다.\n`dict` 는 _정렬되지 않는_ 유형이다.\n\n딕셔너리의 키는 **문자열이어야 한다.** 그러나 값은 모든 유형, 심지어\n다른 `dict` 또는 `list` 일 수도 있다.\n\n`list` 와 달리, `dict` 는 변경 불가능(immutable)하다. `set`과 `unset` 함수는 딕셔너리의\n내용을 변경한다.\n\n헬름은 딕셔너리에 대한 작업을 지원하기 위해 다음의 함수를 제공한다: [deepCopy\n(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [get](#get),\n[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge),\n[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite),\n[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), \n[values](#values).\n\n### dict\nㅣ\n`dict` 함수를 호출하고 키/값들의 리스트를 전달함으로써 사전이 \n생성된다. \n\n다음은 세 항목이 있는 사전을 만든다.\n\n```\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\n주어진 맵과 그 키에 대하여, 맵으로부터 값을 가져온다.\n\n```\nget $myDict \"key1\"\n```\n\n위 결과는 `\"value1\"` 을 반환한다.\n\n키를 찾을 수 없는 경우 이 작업은 단순히 `\"\"` 를 반환한다. \n별도의 오류가 발생하지는 않는다.\n\n### set\n\n`set` 을 사용하여 새 키/값 쌍을 사전에 추가한다.\n\n```\n$_ := set $myDict \"name4\" \"value4\"\n```\n\n`set` 은 (Go 템플릿 함수의 요구 사항으로) _사전을 반환함으로_ \n위와 같이 `$ _` 을 이용하여 값을 관리해야 \n할 수도 있다.\n\n### unset\n\n주어진 맵과 그 키에 대하여, 맵에서 키와 값을 삭제한다.\n\n```\n$_ := unset $myDict \"name4\"\n```\n\n`set` 과 마찬가지로, 사전을 반환한다.\n\n키를 찾을 수 없는 경우, 이 작업은 단순하게 반환된다.\n별도의 오류는 생성되지 않는다.\n\n### hasKey\n\n주어진 사전에 주어진 키가 포함되어 있으면, `hasKey` 함수는 `true` 를 반환한다.\n\n```\nhasKey $myDict \"name1\"\n```\n\n키를 찾을 수 없는 경우 `false` 를 반환한다.\n\n### pluck\n\n`pluck` 함수를 사용하면 하나의 키와 여러 맵을 제공하고 모든 일치 항목의 목록을 \n가져올 수 있다.\n\n```\npluck \"name1\" $myDict $myOtherDict\n```\n\n위는 발견된 모든 값 (`[value1 otherValue1]`)을 \n포함하는 `list` 를 반환한다.\n\n지정된 키가 맵에서 발견되지 _않으면_ 해당 맵은 \n목록에 항목이 없는 것이며 반환 된 목록의 길이는 `pluck` 호출의 \n딕셔너리 수보다 적게 된다.\n\n만약 키가 _발견되었는데_ 그 값이 빈 값이면 해당 값이 \n삽입된다.\n\n헬름 템플릿에서는 일반적으로, 사전 모음에서 첫 번째 일치하는 키를 가져오기 위해\n`pluck ... | first` 와 같이 사용한다.\n\n### merge, mustMerge\n\n둘 이상의 사전을 하나로 병합하여 대상 사전에 우선 순위를 \n부여한다.\n\n```\n$newdict := merge $dest $source1 $source2\n```\n\n이것은 전체 병합 작업이지만 전체 복사 작업은 아니다. \n병합되어 중첩된 개체는 두 딕셔너리에서 동일한 인스턴스이다. \n병합과 함께 깊은 복사(deep copy)를 원하면 병합하면서 `deepCopy` 기능을 사용하자. \n예를 들면\n\n```\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` 는 병합에 실패한 경우 오류를 반환한다.\n\n### mergeOverwrite, mustMergeOverwrite\n\n둘 이상의 사전을 하나로 병합하여 **오른쪽에서 왼쪽으로** 우선 순위를 지정하여 \n대상 사전의 값을 효과적으로 덮어쓴다.\n\n아래의 경우\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\n결과는 다음과 같다.\n\n```\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\n이것은 전체 병합 작업이지만 전체 복사 작업은 아니다. \n병합되어 중첩된(nested) 객체는 두 딕셔너리에서 동일한 인스턴스이다. \n병합과 함께 깊은 복사(deep copy)를 원하면 병합할 때 `deepCopy` 기능을 사용하자. \n예를 들면,\n\n```\ndeepCopy $source | mergeOverwrite $dest\n```\n\n병합에 실패한 경우 `mustMergeOverwrite` 는 오류를 반환한다.\n\n### keys\n\n`keys` 함수는 하나 이상의 `dict` 유형에 있는 모든 키의 `list` 를 반환한다. \n딕셔너리는 _정렬되어 있지 않으므로_ 키는 예측 가능한 순서가 아니다. \n`sortAlpha` 로 정렬할 수 있다.\n\n```\nkeys $myDict | sortAlpha\n```\n\n여러 딕셔너리를 제공할 때 키들은 결합된다(concatenated). `sortAlpha` 와 \n함께 `uniq` 함수를 사용하여 정렬된 키 목록을 얻을 수 있다.\n\n```\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\n`pick` 함수는 사전에서 주어진 키만 선택하여 \n새로운 `dict` 를 만든다.\n\n```\n$new := pick $myDict \"name1\" \"name2\"\n```\n\n위 결과는 `{name1 : value1, name2 : value2}` 를 반환한다.\n\n### omit\n\n`omit` 함수는 주어진 키와 일치하지 _않는_ 모든 키가 포함된 \n새로운 `dict` 를 반환한다는 점을 제외하면 `pick` 과 유사하다.\n\n```\n$new := omit $myDict \"name1\" \"name3\"\n```\n\n위 결과는 `{name2: value2}` 를 반환한다.\n\n### values\n\n`values` 함수는 원본 `dict` 의 모든 값이 포함된 새로운 \n`list` 를 반환한다는 점을 제외하면 `keys` 와 유사하다(오직 하나의 딕셔너리만 지원).\n\n```\n$vals := values $myDict\n```\n\n위 결과는 `list [ \"value1\", \"value2\", \"value 3\"]` 를 반환한다. \n`values` 함수는 결과에 대한 순서를 보장하지 않는다.\n필요시에는 `sortAlpha` 를 사용하자.\n\n### deepCopy, mustDeepCopy\n\n`deepCopy` 및 `mustDeepCopy` 함수는 값을 가져와 \n값의 깊은 복사본(deep copy)을 만든다. 여기에는 딕셔너리 등 다른 구조가 포함된다. \n문제가 있으면 `deepCopy` 의 경우 패닉이 발생하며,\n`mustDeepCopy` 는 오류가 있을 때 템플릿 시스템에 오류를 반환한다.\n\n```\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### Dict 내부에 대한 참고 사항\n\n`dict` 는 Go에서 `map[string] interface{}` 으로 구현된다. \nGo 개발자는 `map[string] interface{}` 값을 컨텍스트에 전달하여 \n템플릿에서 `dict` 로 사용하도록 할 수 있다.\n\n## 인코딩 함수\n\n헬름에는 다음과 같은 인코딩 및 디코딩 기능이 있다.\n\n- `b64enc`/`b64dec`: Base64로 인코딩 또는 디코딩\n- `b32enc`/`b32dec`: Base32로 인코딩 또는 디코딩\n\n## 목록 및 목록 함수\n\n헬름은 임의의 순차적 데이터 목록을 포함할 수 있는 간단한 `리스트` 형을 \n제공한다. 이것은 배열 또는 슬라이스와 유사하지만 목록은 변경 불가능한 \n데이터 유형으로 사용되도록 설계되었다.\n\n정수의 목록을 생성해보자.\n\n```\n$myList := list 1 2 3 4 5\n```\n\n위 결과는 `[1 2 3 4 5]` 의 목록을 생성한다.\n\n헬름은 다음의 함수 목록을 제공한다. [append\n(mustAppend)](#append-mustappend), [compact\n(mustCompact)](#compact-mustcompact), [concat](#concat), [first\n(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial\n(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast),\n[prepend (mustPrepend)](#prepend-mustprepend), [rest\n(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse),\n[seq](#seq), [slice (mustSlice)](#slice-mustslice), [uniq\n(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep),\n[without (mustWithout)](#without-mustwithout).\n\n### first, mustFirst\n\n목록에서 머리부분 항목을 얻어 오려면 `first` 를 사용하자.\n\n`first $myList` 는 `1` 를 반환한다.\n\n문제가 있으면 `first` 는 패닉이 발생하며, `mustFirst` 의 경우 문제가 있으면 \n템플릿 엔진에 오류를 반환한다.\n\n### rest, mustRest\n\n목록의 꼬리부분(첫 번째 항목을 제외한 모든 항목)을 얻으려면 `rest` 를 사용하자.\n\n`rest $myList` 는 `[2 3 4 5]` 반환한다.\n\n문제가 있으면 `rest` 는 패닉이 발생하며, `mustRest` 는 \n문제가 있으면 템플릿 엔진에 오류를 반환한다.\n\n### last, mustLast\n\n목록의 마지막 항목을 가져 오려면 `last` 를 사용하자.\n\n`last $myList` 는 `5` 를 반환한다.\n이것은 목록을 뒤집은 다음 `first` 를 호출하는 것과 거의 유사하다.\n\n### initial, mustInitial\n\n이 함수는 마지막 요소를 _제외한_ 모든 요소를 반환함으로써 `last` 를 보완한다. \n`initial $myList` 는 `[1 2 3 4]` 를 반환한다.\n\n문제가 있으면 `initial` 은 패닉이 발생하고 `mustInitial` 의 경우, \n템플릿 엔진에 오류를 반환한다.\n\n### append, mustAppend\n\n기존 목록에 새 항목을 추가하여 새 목록을 만든다.\n\n```\n$new = append $myList 6\n```\n\n위의 경우 `$new` 를 `[1 2 3 4 5 6]` 로 설정한다. `$myList` 는 변경되지 않는다.\n\n문제가 있으면 `append` 는 패닉이 발생하며 `mustAppend` 의 경우, \n문제가 있으면 템플릿 엔진에 오류를 반환한다.\n\n### prepend, mustPrepend\n\n요소를 목록의 맨 앞으로 밀어 새 목록을 만든다.\n\n```\nprepend $myList 0\n```\n\n위의 경우 `[0 1 2 3 4 5]` 가 생성된다. `$myList` 는 변경되지 않는다.\n\n문제가 있을 경우 `prepend` 는 패닉이 발생하며 `mustPrepend` 는 \n문제가 있을 경우 템플릿 엔진에 오류를 반환한다.\n\n### concat\n\n임의의 수의 목록을 하나로 결합한다.\n\n```\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\n위의 경우 `[1 2 3 4 5 6 7 8]` 이 생성된다. `$myList` 는 변경되지 않는다.\n\n### reverse, mustReverse\n\n주어진 목록의 반전 된 요소로 새 목록을 생성한다.\n\n```\nreverse $myList\n```\n\n위의 경우 `[5 4 3 2 1]` 목록이 반환된다.\n\n`reverse` 는 문제가 있으면 패닉이 발생하고\n`mustReverse` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다.\n\n### uniq, mustUniq\n\n모든 중복 항목이 제거 된 목록을 생성한다.\n\n```\nlist 1 1 1 2 | uniq\n```\n\n위의 경우 `[1 2]` 가 생성된다.\n\n문제가 있으면 `uniq` 는 패닉이 발생하고 \n`mustUniq` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다.\n\n### without, mustWithout\n\n`without` 함수는 목록에서 항목을 필터링한다.\n\n```\nwithout $myList 3\n```\n\n위의 경우`[1 2 4 5]` 가 생성된다.\n\nwithout 의 경우 하나 이상의 필터를 사용할 수도 있다.\n\n```\nwithout $myList 1 3 5\n```\n\n그러면 `[2 4]` 가 생성된다.\n\n문제가 있으면 `without` 의 경우 패닉이 발생하고\n`mustWithout` 의 경우는 문제가 있으면 템플릿 엔진에 오류를 반환한다.\n\n### has, mustHas\n\n목록에 특정 요소가 있는지를 테스트한다.\n\n```\nhas 4 $myList\n```\n\n위의 경우 `true` 를 반환하고 `has \"hello\" $myList` 는 false를 반환한다.\n\n문제가 있으면 `has` 는 패닉이 발생하고 `mustHas` 는 문제가 있으면 템플릿 엔진에 \n오류를 반환한다.\n\n### compact, mustCompact\n\n목록을 승인하고 값이 비어있는 항목을 제거한다.\n\n```\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` 는 비어 있는 항목(즉, \"\")이 제거된 새 목록을 반환한다.\n\n문제가 있는 경우 `compact` 는 패닉이 발생하고 \n`mustCompact` 의 경우 템플릿 엔진에 오류를 반환한다.\n\n### slice, mustSlice\n\n목록의 일부 요소를 가져 오려면 `slice list [n] [m]` 을 사용하자. `list [n : m]` 과도 \n동일하다.\n\n- `slice $myList` 는 `[1 2 3 4 5]` 을 반환한다. `myList[:]` 와 동일하다.\n- `slice $myList 3` 는 `[4 5]` 을 반환한다. `myList[3:]` 와 동일하다.\n- `slice $myList 1 3` 는 `[2 3]` 을 반환한다. `myList[1:3]` 와 동일하다.\n- `slice $myList 0 3` 는 `[1 2 3]` 을 반환한다. `myList[:3]` 와 동일하다.\n\n문제가 있으면 `slice` 는 패닉이 발생하며, `mustSlice` 는 문제가 있으면 \n템플릿 엔진에 오류를 반환한다.\n\n### until\n\n`until` 함수는 정수 범위를 만든다.\n\n```\nuntil 5\n```\n\n위 결과로 `[0, 1, 2, 3, 4]` 목록을 생성한다.\n\n이것은 `range $i, $e := until 5` 로 반복할 때 유용하다.\n\n### untilStep\n\n`until` 과 마찬가지로 `untilStep` 은 지표로서의 정수 목록을 생성한다. \n또한 시작 지표, 끝 지표 및 지표 증분을 정의 할 수 있다.\n\n```\nuntilStep 3 6 2\n```\n\n위의 코드는 3으로 시작하여 6보다 크거나 같을 때까지 2를 더하여 \n`[3 5]` 를 생성한다. 이것은 파이썬의 `range` 함수와 유사하다.\n\n### seq\n\nbash 셸의 `seq` 명령어와 유사하게 작동한다.\n\n* 1 개의 매개 변수 (끝) - 1과 `끝` 사이의 \n  모든 지표 정수를 생성.\n* 2 개의 매개 변수 (시작, 끝) - `start` 와 `end` 사이에 1 씩 \n  증가 또는 감소하는 모든 지표 정수를 생성.\n* 3 개의 매개 변수 (시작, 증분, 끝) - `start` 와 `end` 사이의 모든 \n  지표 정수 (`step` 단위 증가 또는 감소 포함)를 생성합니다.\n\n```\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\n목록을 지정된 크기의 청크로 분할하려면 `chunk size list`를 사용한다. 이는 페이지 매김에 유용하다.\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\n위의 경우 목록의 목록 `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`이 생성된다.\n\n## 수학 함수\n\n모든 수학 함수는 달리 지정하지 않는 한 `int64` 값으로 작동한다.\n\n다음의 수학 함수를 사용할 수 있다: [add](#add), [add1](#add1),\n[ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max),\n[min](#min), [mod](#mod), [mul](#mul), [round](#round), [sub](#sub).\n\n### add\n\n몇 개의 숫자를 더한다. 2개나 그 이상의 입력도 허용된다.\n\n```\nadd 1 2 3\n```\n\n### add1\n\n1만큼 증가시키려면 `add1` 을 사용하자.\n\n### sub\n\n빼려면 `sub` 를 사용한다.\n\n### div\n\n`div` 로 정수 나누기를 수행한다.\n\n### mod\n\n`mod` 로 모듈로 연산을 수행한다.\n\n### mul\n\n`mul` 로 곱하기 연산을 수행한다. 2개 이상의 입력을 허용한다.\n\n```\nmul 1 2 3\n```\n\n### max\n\n일련의 정수중 가장 큰 값을 반환한다.\n\n아래의 경우 `3` 을 반환한다.\n\n```\nmax 1 2 3\n```\n\n### min\n\n일련의 정수중 가장 작 값을 반환한다.\n\n아래의 경우 `1` 을 반환한다.\n\n### floor\n\n입력 값보다 작거나 같은 가장 큰 부동 소수점 값을 출력한다.\n\n`floor 123.9999` 의 경우 `123.0` 을 반환한다.\n\n### ceil\n\n입력 값보다 크거나 같은 가장 작은 부동 소수점 값을 출력한다.\n\n`ceil 123.001` 의 경우 `124.0` 을 반환한다.\n\n### round\n\n반올림하여, 주어진 소수점의 자리수를 갖는 부동 소수점 값을 \n반환한다.\n\n`round 123.555555 3` 의 경우 `123.556` 을 반환한다.\n\n### len\n\n인수의 길이를 정수로 반환한다.\n\n```\nlen .Arg\n```\n\n## 실수 수학 함수\n\n모든 수학 함수는 `float64` 값으로 작동한다.\n\n### addf\n\n`addf`로 숫자를 더한다.\n\n아래의 경우 `5.5`를 반환한다.\n\n```\naddf 1.5 2 2\n```\n\n### add1f\n\n1만큼 증가시키려면 `add1f`를 사용한다.\n\n### subf\n\n빼려면 `subf`를 사용한다.\n\n이것은 `7.5 - 2 - 3`과 동일하며 `2.5`를 반환한다.\n\n```\nsubf 7.5 2 3\n```\n\n### divf\n\n`divf`로 나눗셈을 수행한다.\n\n이것은 `10 / 2 / 4`와 동일하며 `1.25`를 반환한다.\n\n```\ndivf 10 2 4\n```\n\n### mulf\n\n`mulf`로 곱셈을 수행한다.\n\n아래의 경우 `6`을 반환한다.\n\n```\nmulf 1.5 2 2\n```\n\n### maxf\n\n일련의 실수 중 가장 큰 값을 반환한다.\n\n아래의 경우 `3`을 반환한다.\n\n```\nmaxf 1 2.5 3\n```\n\n### minf\n\n일련의 실수 중 가장 작은 값을 반환한다.\n\n아래의 경우 `1.5`를 반환한다.\n\n```\nminf 1.5 2 3\n```\n\n## 네트워크 함수\n\n헬름에는 `getHostByName` 하나의 네트워크 함수가 있다.\n\n`getHostByName` 은 도메인 이름을 받고 IP 주소를 반환한다.\n\n`getHostByName \"www.google.com\"`은 `www.google.com`의 해당 IP 주소를 반환한다.\n\n이 함수는 helm 명령줄에 `--enable-dns` 옵션을 전달해야 사용할 수 있다.\n\n## 파일 경로 함수\n\n헬름 템플릿 함수는 파일 시스템에 대한 액세스 권한을 부여하지 않지만 \n파일 경로 규칙을 따르는 문자열 작업을위한 함수 를 제공한다. \n여기에는 [base] (# base), [clean] (# clean), \n[dir] (# dir), [ext] (# ext) 및 [isAbs] (# isabs)가 포함된다.\n\n### base\n\n경로의 마지막 요소를 반환한다.\n\n```\nbase \"foo/bar/baz\"\n```\n\n위 결과는 \"baz\" 를 반환한다.\n\n### dir\n\n경로의  마지막 부분을 제거하여 디렉토리를 반환한다. 따라서 `dir \"foo/bar/baz\"` \n는 `foo/bar` 를 반환한다.\n\n### clean\n\n경로를 삭제한다.\n\n```\nclean \"foo/bar/../baz\"\n```\n\n위 결과는 `..` 을 찾아서 `foo/baz` 를 반환한다.\n\n### ext\n\n파일의 확장자를 반환한다.\n\n```\next \"foo.bar\"\n```\n\n위 결과는 `.bar` 를 반환한다.\n\n### isAbs\n\n파일 경로가 절대경로인지 확인하려는 경우 `isAbs` 를 사용한다.\n\n## 리플렉션 함수\n\n헬름은 기초적인 리플렉션 도구를 제공한다. \n이는 고급 템플릿 개발자가 특정 값에 대한 기본 Go 유형 정보를 이해하는 데 도움이 된다.\n헬름은 Go로 작성되었으며 강타입 언어이다. 타입 시스템은 템플릿 내에서 \n적용된다.\n\nGo 에는 `string`, `slice`, `int64`, `bool` 과 같은 몇 가지 기본(primitive) _유형(kind)_ 이 있다.\n\nGo 에는 개발자가 자신의 자료형을 만들 수 있는 개방형 _자료형_ 체계가 있다.\n\n헬름은 [유형 함수](#유형-함수) 및 [타입 함수](#타입-함수)을 통해 \n각각에 대한 함수 집합을 제공한다. \n값과 비교하기 위해 [deepEqual](#deepequal) 함수도 제공된다.\n\n### 유형 함수\n\n유형 함수에는 두 가지가 있다. `kindOf` 는 객체의 유형을 반환한다.\n\n```\nkindOf \"hello\"\n```\n\n위는 `string` 을 반환한다. (`if` 블록과 같은) 간단한 테스트의 경우 \n`isKind` 함수를 사용하면 값이 특정 유형인지 확인할 수 있다.\n\n```\nkindIs \"int\" 123\n```\n\n위 결과는 `true` 를 반환한다.\n\n### 타입 함수\n\n타입은 다루기가 약간 더 어렵기에, 타입 함수는 총 3가지가 있다. \n\n- `typeOf` 는 값의 기본 타입을 반환한다. 예) `typeOf $foo`\n- `typeIs` 는 `kindIs` 와 비슷하지만, 타입에 대한 것이다. 예) `typeIs \"*io.Buffer\" $myVal`\n- `typeIsLike` 는 포인터를 역참조한다는 점을 제외하면 `typeIs` 처럼 동작한다.\n\n**참고:** 이 중 어느 것도 주어진 인터페이스를 구현하는지 \n여부를 테스트할 수는 없다. 그렇게 하려면 인터페이스를 미리 컴파일해야\n하기 때문이다.\n\n### deepEqual\n\n`deepEqual` 은 두 값이 \n[\"깊은 같음\"](https://golang.org/pkg/reflect/#DeepEqual)이면 true를 반환한다.\n\n비-기본(non-primitive) 타입에서도 동작한다. (내장된 `eq`와 비교된다.)\n\n```\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\n위 결과는 `true` 를 반환한다.\n\n## 유의적 버전 함수\n\n일부 버전 체계는 쉽게 구문을 분석하고 비교할 수 있다. \n헬름은 [유의적 버전 2] (http://semver.org) 버전 작업을 위한 기능을 제공한다. \n여기에는 [semver](#semver) 및 [semverCompare](#semvercompare)가 포함된다. \n아래에서 비교를 위해 범위를 사용하는 방법에 대한 세부 정보도 찾을 수 있다.\n\n### semver\n\n`semver` 함수는 문자열을 유의적 버전으로 구문 분석한다.\n\n```\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_파서가 실패하면 템플릿 실행이 오류와 함께 중지된다._\n\n이 시점에서 `$version` 은 다음 속성을 가진 `Version` 객체에 대한 \n포인터이다.\n\n- `$version.Major` : 주 번호 (위의 `1`)\n- `$version.Minor` : 부 번호 (위의 `2`)\n- `$version.Patch` : 패치 번호 (위의 `3`)\n- `$version.Prerelease` : 프리 릴리스 (위의 `alpha.1`)\n- `$version.Metadata` : 빌드 메타 데이터 (위의 `123`)\n- `$version.Original` : 문자열로 된 원본 버전\n\n또한 `Compare` 함수를 사용하여 `버전` 을 다른 `버전` 과 비교할 수 \n있다.\n\n```\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\n위 결과는 `-1` 을 반환한다.\n\n반환 값은 다음과 같다.\n\n- 주어진 유의적 버전이 `Compare` 메소드로 호출된 \n  유의적 버전보다 큰 경우 `-1`\n- `Compare` 함수로 호출 된 버전이 더 큰 경우 `1`.\n- 동일한 버전인 경우 `0`\n\n(유의적 버전에서는 버전 비교 작업 중 `Metadata` 필드는 비교되지 않는 것에 \n유의하자.)\n\n### semverCompare\n\n보다 강력한 비교 기능은 `semverCompare` 를 통해 제공된다. \n이 버전은 버전의 범위를 지원한다.\n\n- `semverCompare \"1.2.3\" \"1.2.3\"` 은 정확히 일치하는지 확인합니다.\n- `semverCompare \"^ 1.2.0\" \"1.2.3\"` 은 주 버전과 부 버전이 일치하는지, \n  두 번째 버전의 패치 번호가 첫 번째 매개 변수보다 크거나 같은지 \n  확인한다.\n\nSemVer 함수는 Sprig 제작자의 \n[Masterminds semver 라이브러리] (https://github.com/Masterminds/semver)를 사용한다.\n\n### 기본 비교\n\n비교에는 두 가지 요소가 있다. \n첫째, 비교 문자열은 공백 또는 쉼표로 구분 된 AND 비교 목록이다. \n그런 다음 || (OR) 비교로 구분된다. \n예를 들어 `\"> = 1.2 <3.0.0 ||> = 4.2.3\"` 은 \n1.2보다 크거나 같고 3.0.0보다 작거나 4.2.3보다 크거나 같은지를 비교한다.\n\n기본 비교는 다음과 같다.\n\n- `=` : 같음 (연산자 없음으로 별칭 지정)\n- `! =` : 같지 않음\n- `>` : 보다 큼\n- `<` : 보다 작음\n- `> =` : 보다 크거나 같음\n- `<=` : 보다 작거나 같음\n\n_참고로, 유의적 버전 사양에 따라 프리 릴리스는 \n해당 릴리스의 대응하는 부분의 API를 준수하지 않을 수도 있다._\n\n### 프리 릴리스 버전으로 작업하기\n\n익숙하지 않은 사용자를 위해 프리-릴리스는, 안정된 릴리스 또는 일반적으로 \n사용 가능한 릴리스 이전의 소프트웨어 릴리스에 사용된다. \n프리-릴리스의 예로는 개발, 알파, 베타 및 릴리스 후보 릴리스가 있다. \n프리 릴리스는 `1.2.3-beta.1` 와 같은 버전 일 수 있고 안정된 릴리스는 `1.2.3` 이 될 수 있다. \n우선 순위에 따라 프리 릴리스가 관련 릴리스보다 먼저 나온다. \n이 예에서는 `1.2.3-beta.1 <1.2.3` 이다.\n\n유의적 버전 사양에 따라 프리 릴리스는 \n해당 릴리스의 대응하는 부분의 API를 준수하지 않을 수도 있다.\n\n> 프리-릴리스 버전은 버전이 불안정하고 \n> 관련 일반 버전에 표시된대로 의도 된 호환성 요구 사항을 \n> 충족하지 않을 수 있음을 나타낸다.\n\n프리-릴리스 버전을 비교하지 않고 제약 조건을 사용하는 유의적 버전의 비교는 프리-릴리스 버전을 건너 뛴다. \n예를 들어 `>=1.2.3` 은 출시 목록을 볼 때 프리 릴리스를 건너 뛰고 \n`>=1.2.3-0` 은 프리 릴리스를 평가하고 찾는다.\n\n비교의 예에서 `0` 이 출시 전 버전인 이유는 \n사양에 따라 출시 전 버전에 ASCII 영문/숫자 및 하이픈 (`.` 구분 기호 포함)만 \n포함할 수 있기 때문이다. \n정렬은 사양에 따라 ASCII 정렬 순서로 발생한다. \n가장 낮은 문자는 ASCII 정렬 순서로 `0` 이다([ASCII 테이블](http://www.asciitable.com/) 참조).\n\nASCII 정렬 순서를 이해하는 것은 A-Z가 a-z 앞에 오기 때문에 중요하다. \n즉, `>=1.2.3-BETA` 는 `1.2.3-alpha` 를 반환한다. \n대소문자는 구분되지 않는다.\n이것은 지정된 ASCII 정렬 순서 때문이다.\n\n### 하이픈 범위 비교\n\n범위를 처리하는 방법은 여러 가지가 있으며, 첫 번째 방법은 하이픈 범위이다.\n다음과 같다.\n\n- `1.2 - 1.4.5` 는 `>= 1.2 <= 1.4.5` 과 동일하다.\n- `2.3.4 - 4.5` 는 `>= 2.3.4 <= 4.5` 과 동일하다.\n\n### 비교에서의 와일드카드\n\n`x` , `X` , `*` 문자는 와일드 카드 문자로 사용할 수 있다. \n이것은 모든 비교 연산자에 적용된다. \n`=` 연산자에 사용하면 패치 수준의 비교로 돌아간다 (아래 물결표 참조). 예를 들면\n\n- `1.2.x` 는 `>= 1.2.0, < 1.3.0` 과 동일하다.\n- `>= 1.2.x` 는 `>= 1.2.0` 과 동일하다.\n- `<= 2.x` 는 `< 3` 과 동일하다.\n- `*` 는 `>= 0.0.0` 과 동일하다.\n\n### 물결표 범위 비교 (패치)\n\n물결표 (`~`) 비교 연산자는 부 버전이 지정되면 \n패치 수준 범위에 사용되며 부 번호가 누락되면 주 수준이 변경된다. \n예를 들면,\n\n- `~1.2.3` 는 `>= 1.2.3, < 1.3.0` 과 동일하다.\n- `~1` 는 `>= 1, < 2` 과 동일하다.\n- `~2.3` 는 `>= 2.3, < 2.4` 과 동일하다.\n- `~1.2.x` 는 `>= 1.2.0, < 1.3.0` 과 동일하다.\n- `~1.x` 는 `>= 1, < 2` 과 동일하다.\n\n### 캐럿 범위 비교 (주)\n\n캐럿 (`^`) 비교 연산자는 안정적인 (1.0.0) 릴리스가 발생했을 때 \n주요 레벨 변경을 위한 것이다. \n1.0.0 릴리스 이전에는 부 버전이 API 안정성 수준으로 작동한다. \nAPI 버전을 비교할 때 주요 변경 사항이 API 중단일 때 유용하다. 예를 들면,\n\n- `^1.2.3` 는 `>= 1.2.3, < 2.0.0` 과 동일하다.\n- `^1.2.x` 는 `>= 1.2.0, < 2.0.0` 과 동일하다.\n- `^2.3` 는 `>= 2.3, < 3` 과 동일하다.\n- `^2.x` 는 `>= 2.0.0, < 3` 과 동일하다.\n- `^0.2.3` 는 `>=0.2.3 <0.3.0` 과 동일하다.\n- `^0.2` 는 `>=0.2.0 <0.3.0` 과 동일하다.\n- `^0.0.3` 는 `>=0.0.3 <0.0.4` 과 동일하다.\n- `^0.0` 는 `>=0.0.0 <0.1.0` 과 동일하다.\n- `^0` 는 `>=0.0.0 <1.0.0` 과 동일하다.\n\n## URL 함수\n\n헬름에는 [urlParse](#urlparse), [urlJoin](#urljoin) 및 [urlquery](#urlquery) 함수가 \n포함되어있어 URL 부분으로 작업 할 수 있다다.\n\n### urlParse\n\nURL에 대한 문자열을 구문 분석하고 URL 부분으로 딕셔너리를 생성한다.\n\n```\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\n위는 URL 객체를 포함하는 딕셔너리를 반환한다.\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\n이것은 Go 표준 라이브러리의 URL 패키지를 사용하여 구현된다. \n자세한 내용은 https://golang.org/pkg/net/url/#URL을 확인하자.\n\n### urlJoin\n\n(`urlParse`에서 생성된) 맵을 결합하여 URL 문자열을 생성한다.\n\n```\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\n위는 다음 문자열을 반환한다.\n```\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nURL의 쿼리 부분에 포함하기에 적합하도록 인수로 전달된 값의 \n이스케이프된 버전을 반환한다.\n\n```\n$var := urlquery \"string for query\"\n```\n\n## UUID 함수\n\n헬름은 UUID v4 범용 고유 ID를 생성할 수 있다.\n\n```\nuuidv4\n```\n\n위는 v4 (무작위 생성) 유형의 새 UUID를 반환한다.\n\n## 쿠버네티스 및 차트 함수\n\n헬름에는 \n[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#파일-함수), [lookup](#lookup) 등 \n쿠버네티스 작업을 위한 함수가 포함되어 있다.\n\n### lookup\n\n`lookup` 은 실행중인 클러스터에서 리소스를 조회하는 데 사용된다. \n`helm template` 명령어와 함께 사용하면 항상 빈 응답을 반환한다.\n\n[조회 함수에 대한 문서](/chart_template_guide/functions_and_pipelines.md#lookup-함수-사용하기)에서 \n자세한 내용을 확인할 수 있다.\n\n### .Capabilities.APIVersions.Has\n\n클러스터에서 API 버전 또는 리소스를 사용할 수 있는지에 대한 여부를 반환한다.\n\n```\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\n더 많은 정보는 [내장 객체 문서](/chart_template_guide/builtin_objects.md)에서 \n확인할 수 있다.\n\n### 파일 함수\n\n차트 내에서 비 특수 파일을 얻을 수 있는 함수가 몇 가지 있다. \n예를 들면, 애플리케이션 구성 파일에 액세스하는 것이다. \n이는 [템플릿 내 파일 액세스](/chart_template_guide/accessing_files.md)에 설명되어 있다.\n\n_ 참고로, 이렇게 많은 함수들에 대한 문서화는 \n[Sprig](https://github.com/Masterminds/sprig)로 이루어졌다.\nSprig은 Go 애플리케이션에서 사용할 수 있는 템플릿 함수 라이브러리이다._\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: 템플릿 함수와 파이프라인\ndescription: 템플릿에서 함수 사용하기\nsidebar_position: 5\n---\n\n지금까지 템플릿에 정보를 넣는 방법을 살펴봤다. 하지만 그 정보는 수정 없이 그대로 삽입된다. 때로는 제공된 데이터를 더 유용하게 변환하고 싶을 때가 있다.\n\n가장 좋은 방법부터 시작해보자: `.Values` 객체의 문자열을 템플릿에 삽입할 때는 따옴표로 감싸야 한다. 템플릿 지시어에서 `quote` 함수를 호출하면 된다:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\n템플릿 함수는 `functionName arg1 arg2...` 구문을 따른다. 위 코드에서 `quote .Values.favorite.drink`는 `quote` 함수를 호출하고 단일 인자를 전달한다.\n\nHelm에는 60개 이상의 함수가 있다. 일부는 [Go 템플릿 언어](https://godoc.org/text/template) 자체에서 정의된 것이고, 대부분은 [Sprig 템플릿 라이브러리](https://masterminds.github.io/sprig/)의 일부다. 예제를 진행하면서 많은 함수들을 살펴볼 것이다.\n\n> \"Helm 템플릿 언어\"를 Helm에서만 사용하는 것처럼 말하지만, 실제로는 Go 템플릿 언어와 몇 가지 추가 함수, 그리고 특정 객체를 템플릿에 노출하기 위한 다양한 래퍼의 조합이다. Go 템플릿에 대한 많은 자료가 템플릿 학습에 도움이 될 것이다.\n\n## 파이프라인\n\n템플릿 언어의 강력한 기능 중 하나는 _파이프라인_ 개념이다. UNIX의 개념을 빌려와서, 파이프라인은 일련의 템플릿 명령을 연결하여 일련의 변환을 간결하게 표현하는 도구다. 다시 말해, 파이프라인은 여러 작업을 순서대로 효율적으로 처리하는 방법이다. 위 예제를 파이프라인을 사용해 다시 작성해보자.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\n이 예제에서는 `quote ARGUMENT`를 호출하는 대신 순서를 바꿨다. 파이프라인(`|`)을 사용하여 인자를 함수로 \"전송\"했다: `.Values.favorite.drink | quote`. 파이프라인을 사용하면 여러 함수를 연결할 수 있다:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> 순서를 바꾸는 것은 템플릿에서 흔한 방식이다. `quote .val`보다 `.val | quote`를 더 자주 보게 될 것이다. 두 방식 모두 괜찮다.\n\n위 템플릿을 평가하면 다음과 같은 결과가 나온다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\n원래 `pizza`가 `\"PIZZA\"`로 변환된 것에 주목하자.\n\n이렇게 인자를 파이프라인으로 전달할 때, 첫 번째 평가 결과(`.Values.favorite.drink`)는 _함수의 마지막 인자_로 전달된다. 두 개의 인자를 받는 함수를 사용하여 drink 예제를 수정해보자: `repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n`repeat` 함수는 주어진 문자열을 지정된 횟수만큼 반복 출력하므로, 다음과 같은 결과가 나온다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## `default` 함수 사용하기\n\n템플릿에서 자주 사용되는 함수 중 하나는 `default` 함수다: `default DEFAULT_VALUE GIVEN_VALUE`. 이 함수는 값이 생략된 경우 템플릿 내에서 기본값을 지정할 수 있게 해준다. 위 drink 예제를 수정해보자:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\n정상적으로 실행하면 `coffee`가 출력된다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\n이제 `values.yaml`에서 favorite drink 설정을 제거해보자:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\n이제 `helm install --dry-run --debug fair-worm ./mychart`를 다시 실행하면 다음 YAML이 생성된다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\n실제 차트에서는 모든 정적 기본값이 `values.yaml`에 있어야 하며, `default` 명령으로 반복해서는 안 된다(그렇지 않으면 중복이 된다). 하지만 `default` 명령은 `values.yaml` 내에 선언할 수 없는 계산된 값에 적합하다. 예를 들어:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\n어떤 곳에서는 `default`보다 `if` 조건문이 더 적합할 수 있다. 다음 섹션에서 이를 살펴볼 것이다.\n\n템플릿 함수와 파이프라인은 정보를 변환한 다음 YAML에 삽입하는 강력한 방법이다. 하지만 때로는 단순히 문자열을 삽입하는 것보다 더 복잡한 템플릿 로직이 필요할 때가 있다. 다음 섹션에서는 템플릿 언어가 제공하는 제어 구조를 살펴볼 것이다.\n\n## `lookup` 함수 사용하기\n\n`lookup` 함수를 사용하면 실행 중인 클러스터에서 리소스를 조회할 수 있다. lookup 함수의 구문은 `lookup apiVersion, kind, namespace, name -> resource or resource list`이다.\n\n| 파라미터   | 자료형 |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\n`name`과 `namespace`는 선택사항이며 빈 문자열(`\"\"`)로 전달할 수 있다. 하지만 namespace 범위의 리소스를 다룰 때는 `name`과 `namespace`를 모두 지정해야 한다.\n\n다음과 같은 파라미터 조합이 가능하다:\n\n| 동작                                   | lookup 함수                                |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\n`lookup`이 객체를 반환하면 딕셔너리를 반환한다. 이 딕셔너리를 탐색하여 특정 값을 추출할 수 있다.\n\n다음 예제는 `mynamespace` 객체에 있는 어노테이션을 반환한다:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\n`lookup`이 객체 목록을 반환하면 `items` 필드를 통해 객체 목록에 접근할 수 있다:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* do something with each service */}}\n{{ end }}\n```\n\n객체를 찾지 못하면 빈 값이 반환된다. 이를 사용하여 객체의 존재 여부를 확인할 수 있다.\n\n`lookup` 함수는 Helm의 기존 Kubernetes 연결 설정을 사용하여 Kubernetes에 쿼리한다. API 서버와 상호 작용할 때 오류가 반환되면(예: 리소스 접근 권한이 없는 경우) Helm의 템플릿 처리가 실패한다.\n\n`helm template|install|upgrade|delete|rollback --dry-run` 작업 중에는 Helm이 Kubernetes API 서버에 접속하지 않아야 한다는 점을 기억하자. 실행 중인 클러스터에서 `lookup`을 테스트하려면 `helm template|install|upgrade|delete|rollback --dry-run=server`를 사용하여 클러스터 연결을 허용해야 한다.\n\n## 연산자는 함수이다\n\n템플릿에서 연산자(`eq`, `ne`, `lt`, `gt`, `and`, `or` 등)는 모두 함수로 구현되어 있다. 파이프라인에서 연산은 괄호(`(`, `)`)로 그룹화할 수 있다.\n\n이제 함수와 파이프라인에서 조건문, 반복문, 스코프 수정자를 사용한 흐름 제어로 넘어가보자.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: 시작하기\ndescription: 차트 템플릿에 관한 빠른 가이드\nsidebar_position: 2\n---\n\n이 섹션에서는 차트를 만든 다음 첫 번째 템플릿을 추가할 것이다.\n우리가 여기서 만든 차트는 가이드의 나머지 부분에서 쭉 사용될 것이다.\n\n시작하기 위해 헬름 차트를 간단히 살펴보자.\n\n## 차트\n\n[차트 가이드](/topics/charts.md)에 설명된 대로,\n헬름 차트는 다음과 같이 구성된다:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\n`templates/` 디렉토리는 템플릿 파일을 위한 것이다.\n헬름이 차트를 평가할 때,\n`templates/` 디렉토리의 모든 파일을 템플릿 렌더링 엔진으로 전달한다.\n그리고 나서 처리 결과를 모아 쿠버네티스로 보낸다.\n\n`values.yaml` 파일도 템플릿에 중요하다.\n이 파일은 차트의 _기본값_ 을 포함한다.\n이 값들은 `helm install` 또는 `helm upgrade` 하는 중에 사용자가 재정의할 수 있다.\n\n`Chart.yaml` 파일은 차트에 대한 설명을 포함한다.\n템플릿 안에서 접근할 수 있다.\n`charts/` 디렉토리는 다른 차트(_하위차트_ 라고 함)를 포함 _할 수도_ 있다.\n본 가이드의 뒷부분에서 템플릿 렌더링과 관련하여 이러한 기능이 어떻게 작동하는지 알아볼 것이다.\n\n## 스타터 차트\n\n본 가이드를 위해 `mychart` 라는 간단한 차트를 만든 다음,\n차트 안에 템플릿을 만들 것이다.\n\n```console\n$ helm create mychart\nmychart 생성\n```\n\n### `mychart/templates/` 훑어보기\n\n`mychart/templates/` 를 보면 이미 몇 개의 파일이 있는 것을 알 수 있다.\n\n- `NOTES.txt` : 차트의 \"도움말\". 이것은 `helm install` 을 실행할 때 사용자에게 표시될 것이다.\n- `deployment.yaml` : 쿠버네티스\n  [디플로이먼트](https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/)를\n  생성하기 위한 기본 매니페스트\n- `service.yaml` : 디플로이먼트의 [서비스\n  엔드포인트](https://kubernetes.io/ko/docs/concepts/services-networking/service/)를\n  생성하기 위한 기본 매니페스트\n- `_helpers.tpl` : 차트 전체에서 다시 사용할 수 있는 템플릿 헬퍼를 지정하는 공간\n\n그리고 우리가 할 일은... _전부 제거하자!_\n그렇게 하면 우리는 튜토리얼의 맨 처음부터 끝까지 실행할 수 있다.\n실제로 우리만의 `NOTES.txt` 와 `_helpers.tpl` 을 만들 것이다.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\n프로덕션용 차트를 작성할 때는 차트의 기본 버전을 사용하는 것이 매우 유용할 수 있다.\n따라서 매일 차트를 작성할 때는 차트를 삭제하는 것을 원하지 않을 수도 있다.\n\n## 첫 번째 템플릿\n\n우리가 만들 첫 번째 템플릿은 `ConfigMap` 이 될 것이다.\n쿠버네티스에서 컨피그맵은 단순히 환경 설정 데이터를 저장하는 컨테이너일 뿐이다.\n파드 같은 다른 것들은 컨피그맵의 데이터에 접근할 수 있다.\n\n컨피그맵은 기본 리소스이기 때문에 우리에게 좋은 출발점이 된다.\n\n먼저 `mychart/templates/configmap.yaml` 이라는 파일을 만들어 보자.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**TIP:** 템플릿 이름은 엄격한 명명 패턴을 따르지 않는다.\n단, YAML 파일에는 접미사 `.yaml` 을, 헬퍼에는 `.tpl` 을 사용하는 것이 좋다.\n\n위의 YAML 파일은 최소한의 필수 필드를 가진 가장 기본적인 컨피그맵이다.\n이 파일은 `mychart/template/` 디렉토리에 있기 때문에 템플릿 엔진으로 전달된다.\n\n`mychart/template/` 디렉토리에 이와 같이 평범한 YAML 파일을 넣는 것은 괜찮다.\n헬름이 이 템플릿을 읽으면 쿠버네티스에게 그대로 보낼 뿐이다.\n\n이 간단한 템플릿으로 우리는 이제 설치 가능한 차트를 가지고 있다.\n이렇게 설치하면 된다:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\n헬름을 사용하면 릴리스를 검색해 실제 전송된 템플릿을 볼 수 있다.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n`helm get manifest` 명령은 릴리스 이름(`full-coral`)을 가지고\n서버에 업로드된 쿠버네티스 리소스를 모두 출력한다.\n각 파일은 `---`로 시작하여 YAML 문서의 시작을 표시한 다음\n자동으로 생성된 주석이 나타나 이 YAML 문서를 생성한 템플릿 파일을 알려준다.\n\n여기서 이 YAML 데이터가 정확히 `configmap.yaml` 파일에 입력한 것임을 알 수 있다.\n\n이제 릴리스를 제거해도 된다: `helm uninstall full-coral`.\n\n### 단순한 템플릿 호출 추가하기\n\n`name:` 을 리소스 안에 하드 코딩하는 것은 보통 좋지 못한 관행으로 간주된다.\n이름은 릴리스에 고유해야 한다.\n그래서 릴리스 이름을 삽입하여 이름 필드를 생성하기를 원할 수 있다.\n\n**TIP:** DNS 시스템에 대한 제한 때문에 `name:` 필드가 63자로 제한된다.\n이 때문에 릴리스 이름은 53자로 제한한다.\n쿠버네티스 1.3 이하에서는 단 24자(즉, 14자 이름)로 제한하였다.\n\n이에 따라 `configmap.yaml` 을 바꾸자.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n`name:` 필드의 값에서 `{{ .Release.Name }}-configmap` 이라고 큰 변화가 일어났다.\n\n> 템플릿 지시문은 `{{` 와 `}}` 으로 감싼다.\n\n템플릿 지시문 `{{ .Release.Name }}` 은 템플릿에 릴리스 이름을 주입한다.\n템플릿으로 전달되는 값은 _네임스페이스 객체_ 로 생각할 수 있으며,\n여기서 점(`.`)이 각 네임스페이스 요소를 구분한다.\n\n`Release` 앞의 점은 해당 스코프(조금 있으면 스코프에 대해 설명하겠다)의\n최상위 네임스페이스부터 시작한다는 것을 나타낸다.\n그래서 우리는 `.Release.Name`을\n\"최상위 네임스페이스에서부터 시작하여 `Release` 객체를 찾은 다음\n`Name`이라는 객체를 찾아보라\"로 읽을 수 있다.\n\n`Release` 객체는 헬름의 내장 객체 중 하나이며, 이후에 좀 더 심층적으로 다룰 것이다.\n현재로서는 헬름 라이브러리가 릴리스에 할당한 이름을 나타내는 것이라고 말해도\n손색이 없다.\n\n이제 리소스를 설치할 때 이 템플릿 지시어를 사용한 결과를 바로 볼 수 있다.\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\n쿠버네티스 안에 컨피그맵은 이전의 `mychart-configmap` 이 아닌\n`clunky-serval-configmap` 이라는 점에 주목하자.\n\n`helm get manifest clunky-serval`을 실행하여 생성된 전체 YAML을 볼 수 있다.\n\n이때 템플릿은 가장 기본적인 것으로, `{{` 와 `}}` 에 내장된 템플릿 지시문을 가진 YAML 파일이다.\n다음 단계에서는 템플릿에 대해 더 자세히 살펴보도록 하겠다.\n그러나 다음 단계로 넘어가기 전에 템플릿을 더 빨리 만들 수 있는 한 가지 요령을 보자:\n실제로 아무것도 설치하지 않지만 템플릿 렌더링을 테스트하고 싶다면\n`helm install --debug --dry-run goodly-guppy ./mychart` 를 사용할 수 있다.\n이렇게 하면 템플릿이 렌더링된다.\n그러나 차트를 설치하는 대신 렌더링 된 템플릿을 반환하여 이러한 출력을 볼 수 있다:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\n`--dry-run` 을 사용하면 코드를 쉽게 테스트할 수 있지만,\n쿠버네티스가 당신이 만든 템플릿을 받아들일지는 확신할 수 없을 것이다.\n`--dry-run` 이 작동됐다는 이유로 차트가 설치될 것이라고 생각하지 않는 것이 가장 좋다.\n\n[차트 템플릿 가이드](/chart_template_guide/index.mdx)에서는 여기서 정의한 기본 차트를 가지고 헬름 템플릿 언어를 자세히 살펴본다.\n그럼 내장 객체부터 시작하자.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: .helmignore 파일\ndescription: \"`.helmignore` 파일은 헬름 차트에 포함시키고 싶지 않은 파일들을 지정하는 데 사용한다.\"\nsidebar_position: 12\n---\n\n`.helmignore` 파일은 헬름 차트에 포함시키고 싶지 않은 파일들을 지정하는 데 사용한다.\n\n이 파일이 있으면, `helm package` 명령어는 애플리케이션을 패키징할 때 `.helmignore`에서 지정한 패턴에 매칭되는 모든 파일들을 무시할 것이다.\n\n이를 통해 불필요하거나 민감한 파일 또는 디렉토리들이 헬름 차트에 추가되는 것을 막을 수 있다.\n\n`.helmignore` 파일은 유닉스 쉘 글롭(glob) 매칭, 상대 경로 매칭, 부정(negation, 접두어 ! 사용)을 지원한다. 한 줄당 하나의 패턴만 인식된다.\n\n`.helmignore` 파일 예시는 다음과 같다.\n\n```\n# 주석\n\n# .helmignore라는 이름의 파일 또는 경로와 매칭\n.helmignore\n\n# .git이라는 이름의 파일 또는 경로와 매칭\n.git\n\n# 모든 텍스트 파일과 매칭\n*.txt\n\n# mydir이라는 이름의 디렉토리만 매칭\nmydir/\n\n# 최상위 디렉토리의 텍스트 파일만 매칭\n/*.txt\n\n# 최상위 디렉토리의 foo.txt 파일만 매칭\n/foo.txt\n\n# ab.txt, ac.txt, ad.txt 파일과 매칭\na[b-d].txt\n\n# subdir 하위의 temp*와 매칭되는 모든 파일과 매칭\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\n.gitignore와의 주목할 만한 차이점:\n- '**' 구문은 지원되지 않는다.\n- 글로빙 라이브러리는 fnmatch(3)가 아니라 Go의 'filepath.Match'이다.\n- 후행 공백은 항상 무시된다 (이를 유지하는 이스케이프 시퀀스가 없다).\n- '\\!'를 특수 선행 시퀀스로 지원하지 않는다.\n- 기본적으로 자기 자신을 제외하지 않으므로, `.helmignore`에 대한 명시적 항목을 추가해야 한다.\n\n\n이 문서를 개선하는 데 **여러분의 도움이 필요합니다.**\n정보를 추가, 수정, 삭제하려면, [이슈를 제기](https://github.com/helm/helm-www/issues)하거나 풀 리퀘스트를 보내주세요.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx",
    "content": "---\ntitle: 차트 템플릿 가이드\nsidebar_position: 5\n---\n\n# 차트 템플릿 개발자 가이드\n\n본 가이드는 헬름 차트 템플릿을 소개하며, 템플릿 언어를 중점적으로 다룬다.\n\n템플릿은 쿠버네티스가 이해할 수 있는 YAML-형식 리소스 명세인 매니페스트 파일을 생성한다.\n템플릿이 어떻게 구성되는지, 그것을 사용하는 방법, Go 템플릿을 작성하는 방법, 디버그 하는 방법을 살펴볼 것이다.\n\n이 가이드는 다음 개념들을 집중적으로 설명한다.\n\n- 헬름 템플릿 언어\n- 값(values) 사용\n- 템플릿 작성 기법\n\n이 가이드는 헬름 템플릿 언어를 세밀하게 알아 보는 것을 지향점으로 한다.\n다른 가이드에서는 소개 자료, 예시, 모범사례를 다룰 것이다.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: 네임드 템플릿\ndescription: 네임드 템플릿을 정의하는 방법\nsidebar_position: 9\n---\n\n이제 하나의 템플릿을 넘어 여러 템플릿을 만들어 볼 차례이다. 이 섹션에서는\n한 파일에서 _네임드 템플릿_을 정의하고 다른 곳에서 사용하는 방법을 알아본다.\n_네임드 템플릿_(때때로 _partial_ 또는 _subtemplate_이라고도 함)은 단순히\n파일 내에 정의되어 이름이 부여된 템플릿이다.\n템플릿을 만드는 두 가지 방법과 사용하는 여러 방법을 살펴보겠다.\n\n[흐름 제어](./control_structures.md) 섹션에서 템플릿을 선언하고 관리하기\n위한 세 가지 액션 `define`, `template`, `block`을 소개했다. 이 섹션에서는\n이 세 가지 액션을 다루고, `template` 액션과 유사하게 작동하는 특수 목적의\n`include` 함수도 소개한다.\n\n템플릿 이름을 지정할 때 염두에 두어야 할 중요한 사항: **템플릿 이름은\n전역적이다**. 동일한 이름으로 두 개의 템플릿을 선언하면 마지막에 로드된\n것이 사용된다. 서브차트의 템플릿은 최상위 템플릿과 함께 컴파일되므로\n_차트별 고유 이름_으로 템플릿 이름을 지정해야 한다.\n\n일반적인 명명 규칙은 정의된 각 템플릿 앞에 차트 이름을 접두사로 붙이는 것이다:\n`{{ define \"mychart.labels\" }}`. 특정 차트 이름을 접두사로 사용하면\n동일한 이름의 템플릿을 구현하는 서로 다른 두 차트로 인해 발생할 수 있는\n충돌을 피할 수 있다.\n\n이 동작은 차트의 다른 버전에도 적용된다. 한 가지 방식으로 템플릿을 정의한\n`mychart` 버전 `1.0.0`이 있고, 기존 네임드 템플릿을 수정하는 `mychart`\n버전 `2.0.0`이 있다면 마지막에 로드된 것이 사용된다. 차트 이름에 버전을\n추가하여 이 문제를 해결할 수 있다: `{{ define \"mychart.v1.labels\" }}`와\n`{{ define \"mychart.v2.labels\" }}`.\n\n## Partial과 `_` 파일\n\n지금까지 하나의 파일을 사용했고, 그 파일에는 단일 템플릿이 포함되어 있었다.\n하지만 Helm의 템플릿 언어를 사용하면 다른 곳에서 이름으로 접근할 수 있는\n네임드 임베디드 템플릿을 만들 수 있다.\n\n템플릿 작성의 핵심에 들어가기 전에, 언급할 가치가 있는 파일 명명 규칙이 있다:\n\n* `templates/`에 있는 대부분의 파일은 Kubernetes 매니페스트를 포함하는 것으로 취급된다\n* `NOTES.txt`는 예외이다\n* 그러나 이름이 밑줄(`_`)로 시작하는 파일은 내부에 매니페스트가 _없는_ 것으로\n  간주된다. 이 파일들은 Kubernetes 오브젝트 정의로 렌더링되지 않지만,\n  다른 차트 템플릿 어디서나 사용할 수 있다.\n\n이 파일들은 partial과 helper를 저장하는 데 사용된다. 실제로 처음\n`mychart`를 만들 때 `_helpers.tpl`이라는 파일을 보았다. 이 파일은\n템플릿 partial의 기본 위치이다.\n\n## `define`과 `template`으로 템플릿 선언 및 사용하기\n\n`define` 액션을 사용하면 템플릿 파일 내에 네임드 템플릿을 만들 수 있다.\n문법은 다음과 같다:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # body of template here\n{{- end }}\n```\n\n예를 들어, Kubernetes 레이블 블록을 캡슐화하는 템플릿을 정의할 수 있다:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\n이제 이 템플릿을 기존 ConfigMap에 포함시키고 `template` 액션으로\n포함할 수 있다:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\n템플릿 엔진이 이 파일을 읽으면 `template \"mychart.labels\"`가 호출될 때까지\n`mychart.labels` 참조를 저장한다. 그런 다음 해당 템플릿을 인라인으로\n렌더링한다. 결과는 다음과 같다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\n참고: `define`은 이 예제처럼 template으로 호출되지 않으면 출력을 생성하지 않는다.\n\n일반적으로 Helm 차트는 이러한 템플릿을 partial 파일, 보통 `_helpers.tpl`에 넣는다.\n이 함수를 그곳으로 옮겨 보자:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\n관례상, `define` 함수에는 기능을 설명하는 간단한 문서화 블록\n(`{{/* ... */}}`)이 있어야 한다.\n\n이 정의가 `_helpers.tpl`에 있더라도 `configmap.yaml`에서 여전히\n접근할 수 있다:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\n위에서 언급했듯이, **템플릿 이름은 전역적이다**. 결과적으로 동일한 이름으로\n두 개의 템플릿이 선언되면 마지막 것이 사용된다. 서브차트의 템플릿은\n최상위 템플릿과 함께 컴파일되므로 _차트별 고유 이름_으로 템플릿 이름을\n지정하는 것이 좋다. 일반적인 명명 규칙은 정의된 각 템플릿 앞에 차트\n이름을 접두사로 붙이는 것이다: `{{ define \"mychart.labels\" }}`.\n\n## 템플릿 스코프 설정하기\n\n위에서 정의한 템플릿에서는 어떤 오브젝트도 사용하지 않았다.\n함수만 사용했다. 차트 이름과 차트 버전을 포함하도록 정의된 템플릿을\n수정해 보자:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\n이것을 렌더링하면 다음과 같은 오류가 발생한다:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\n렌더링 결과를 보려면 `--disable-openapi-validation`과 함께 다시 실행한다:\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`.\n결과는 예상한 것과 다르다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\n이름과 버전은 어떻게 되었을까? 정의된 템플릿의 스코프에 포함되지\n않았다. 네임드 템플릿(`define`으로 생성된)이 렌더링될 때,\n`template` 호출에서 전달된 스코프를 받는다. 예제에서는\n다음과 같이 템플릿을 포함했다:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\n스코프가 전달되지 않았으므로 템플릿 내에서 `.`의 어떤 것도 접근할 수 없다.\n하지만 이것은 쉽게 수정할 수 있다. 템플릿에 스코프를 전달하면 된다:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\n`template` 호출 끝에 `.`를 전달했다. `.Values`나 `.Values.favorite` 또는\n원하는 스코프를 쉽게 전달할 수 있다. 하지만 우리가 원하는 것은\n최상위 스코프이다. 네임드 템플릿의 컨텍스트에서 `$`는 전역 스코프가\n아니라 전달한 스코프를 참조한다.\n\n이제 `helm install --dry-run --debug plinking-anaco ./mychart`로\n이 템플릿을 실행하면 다음을 얻는다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\n이제 `{{ .Chart.Name }}`은 `mychart`로, `{{ .Chart.Version }}`은\n`0.1.0`으로 해석된다.\n\n## `include` 함수\n\n다음과 같은 간단한 템플릿을 정의했다고 가정해 보자:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\n이제 이것을 템플릿의 `labels:` 섹션과 `data:` 섹션 모두에\n삽입하고 싶다고 가정해 보자:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\n이것을 렌더링하면 다음과 같은 오류가 발생한다:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\n렌더링 결과를 보려면 `--disable-openapi-validation`과 함께 다시 실행한다:\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`.\n출력은 예상한 것과 다르다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\n`app_version`의 들여쓰기가 두 곳 모두에서 잘못되어 있다. 왜일까?\n대체되는 템플릿의 텍스트가 왼쪽 정렬되어 있기 때문이다. `template`은\n액션이며 함수가 아니기 때문에 `template` 호출의 출력을 다른 함수에\n전달할 방법이 없다. 데이터는 단순히 인라인으로 삽입된다.\n\n이 경우를 해결하기 위해, Helm은 `template`의 대안으로 템플릿의 내용을\n현재 파이프라인으로 가져와서 파이프라인의 다른 함수에 전달할 수 있게\n해주는 `include`를 제공한다.\n\n다음은 위의 예제를 `indent`를 사용하여 `mychart.app` 템플릿을\n올바르게 들여쓰기하도록 수정한 것이다:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\n이제 생성된 YAML은 각 섹션에 대해 올바르게 들여쓰기된다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> Helm 템플릿에서 `template`보다 `include`를 사용하는 것이 선호된다.\n> 단순히 YAML 문서에 대한 출력 포맷팅을 더 잘 처리할 수 있기 때문이다.\n\n때로는 컨텐츠를 템플릿이 아닌 그대로 가져오고 싶을 때가 있다.\n즉, 파일을 있는 그대로 가져오고 싶은 경우이다. 다음 섹션에서 설명하는\n`.Files` 오브젝트를 통해 파일에 접근하면 이를 달성할 수 있다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: NOTES.txt 파일 작성하기\ndescription: 차트 사용자에게 설명서를 제공하는 방법\nsidebar_position: 10\n---\n\n이 섹션에서는 차트 사용자에게 지침을 제공하는 헬름의 도구들을 살펴본다.\n`helm install` 이나 `helm upgrade` 가 끝나면, \n헬름은 사용자에게 유용한 정보들을 출력할 수 있다. \n이 정보는 템플릿을 사용하여 많은 부분을 커스터마이징할 수 있다.\n\n차트에 설치 메모를 추가하기 위해, 간단하게 `templates/NOTES.txt` \n파일을 생성한다. 이 파일은 평범한 텍스트이지만, 템플릿처럼 처리되며 \n모든 일반 템플릿 기능과 객체를 사용할 수 있다.\n\n간단히 `NOTES.txt` 파일을 생성한다.\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\n이제 `helm install rude-cardinal ./mychart` 를 실행하면 하단에 이런 메세지가 \n표시된다.\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\n이러한 방식으로 `NOTES.txt` 를 사용하면 새로 설치된 차트를 \n사용하는 방법에 대한 자세한 정보를 사용자에게 제공할 수 있다. 필수는 아니지만, \n`NOTES.txt` 파일 생성을 강력히 추천한다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: 서브차트와 글로벌 값\ndescription: 서브차트 및 글로벌 값 사용하기\nsidebar_position: 11\n---\n\n지금까지 우리는 단일 차트만 가지고 작업해왔다. 하지만 차트는 자체적인 값과 템플릿을 가진 _서브차트_ 라고 불리는 의존성을 가질 수 있다. 이 섹션에서는 서브차트를 만들고 템플릿 내에서 값에 접근하는 다양한 방법을 살펴볼 것이다.\n\n코드로 들어가기 전에 애플리케이션 서브차트에 대해 알아야 할 몇 가지 중요한 사항이 있다.\n\n1. 서브차트는 \"독립적\"으로 간주된다. 이는 서브차트가 절대로 부모 차트에 명시적으로 의존할 수 없음을 의미한다.\n2. 그런 이유로 서브차트는 부모의 값에 접근할 수 없다.\n3. 부모 차트는 서브차트의 값을 오버라이드할 수 있다.\n4. Helm에는 모든 차트에서 접근할 수 있는 _글로벌 값_ 이라는 개념이 있다.\n\n> 이러한 제한 사항은 표준화된 헬퍼 기능을 제공하도록 설계된 [라이브러리 차트](/topics/library_charts.md)에는 반드시 적용되지 않는다.\n\n이 섹션의 예제를 살펴보면서 이러한 개념들이 더 명확해질 것이다.\n\n## 서브차트 작성\n\n이 실습에서는 가이드 시작 부분에서 만든 `mychart/` 차트를 가지고 시작하여 그 안에 새로운 차트를 추가할 것이다.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\n이전과 마찬가지로 처음부터 시작할 수 있도록 모든 기본 템플릿을 삭제했다. 이 가이드에서는 의존성 관리가 아닌 템플릿 작동 방식에 초점을 맞추고 있다. 서브차트 작동 방식에 대한 자세한 내용은 [차트 가이드](/topics/charts.md)를 참조하라.\n\n## 서브차트에 값과 템플릿 추가하기\n\n다음으로 `mysubchart` 차트를 위한 간단한 템플릿과 values 파일을 만들어 보자. `mychart/charts/mysubchart`에 이미 `values.yaml`이 있을 것이다. 다음과 같이 설정하자:\n\n```yaml\ndessert: cake\n```\n\n다음으로 `mychart/charts/mysubchart/templates/configmap.yaml`에 새 ConfigMap 템플릿을 만들자:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\n모든 서브차트는 _독립적인 차트_ 이기 때문에 `mysubchart`를 단독으로 테스트할 수 있다:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## 부모 차트에서 값 오버라이드하기\n\n원래의 `mychart` 차트가 이제 `mysubchart`의 _부모_ 차트이다. 이 관계는 `mysubchart`가 `mychart/charts` 내에 있기 때문에 성립한다.\n\n`mychart`가 부모이기 때문에 `mychart`에서 구성을 지정하고 그 구성을 `mysubchart`로 전달할 수 있다. 예를 들어 `mychart/values.yaml`을 다음과 같이 수정할 수 있다:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\n마지막 두 줄에 주목하라. `mysubchart` 섹션 안의 모든 지시문은 `mysubchart` 차트로 전달된다. 따라서 `helm install --generate-name --dry-run --debug mychart`를 실행하면 `mysubchart` ConfigMap을 볼 수 있다:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\n최상위 레벨의 값이 서브차트의 값을 오버라이드한 것이다.\n\n여기서 주목해야 할 중요한 세부 사항이 있다. `mychart/charts/mysubchart/templates/configmap.yaml`의 템플릿을 `.Values.mysubchart.dessert`를 가리키도록 변경하지 않았다. 해당 템플릿의 관점에서 값은 여전히 `.Values.dessert`에 위치한다. 템플릿 엔진이 값을 전달할 때 스코프를 설정한다. 따라서 `mysubchart` 템플릿의 경우 `mysubchart`에 특정한 값만 `.Values`에서 사용할 수 있다.\n\n하지만 때로는 특정 값을 모든 템플릿에서 사용할 수 있도록 하고 싶을 때가 있다. 이럴 때 글로벌 차트 값을 사용하면 된다.\n\n## 글로벌 차트 값\n\n글로벌 값은 정확히 같은 이름으로 모든 차트나 서브차트에서 접근할 수 있는 값이다. 글로벌은 명시적 선언이 필요하다. 기존의 비글로벌 값을 글로벌인 것처럼 사용할 수는 없다.\n\nValues 데이터 타입에는 글로벌 값을 설정할 수 있는 `Values.global`이라는 예약된 섹션이 있다. `mychart/values.yaml` 파일에 하나를 설정해 보자.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\n글로벌의 작동 방식 때문에 `mychart/templates/configmap.yaml`과 `mysubchart/templates/configmap.yaml` 모두 `{{ .Values.global.salad }}`로 해당 값에 접근할 수 있어야 한다.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\n이제 dry run 설치를 실행하면 두 출력에서 같은 값을 볼 수 있다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\n글로벌은 이와 같은 정보를 전달하는 데 유용하지만, 올바른 템플릿이 글로벌을 사용하도록 구성되어 있는지 확인하기 위해 약간의 계획이 필요하다.\n\n## 템플릿과 서브차트 공유하기\n\n부모 차트와 서브차트는 템플릿을 공유할 수 있다. 모든 차트에서 정의된 블록은 다른 차트에서 사용할 수 있다.\n\n예를 들어 다음과 같이 간단한 템플릿을 정의할 수 있다:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\n템플릿의 레이블이 _전역적으로 공유_ 된다는 것을 상기하라. 따라서 `labels` 차트는 다른 어떤 차트에서도 포함될 수 있다.\n\n차트 개발자는 `include`와 `template` 중에서 선택할 수 있지만, `include`를 사용하는 한 가지 장점은 `include`가 템플릿을 동적으로 참조할 수 있다는 것이다:\n\n```yaml\n{{ include $mytemplate }}\n```\n\n위의 코드는 `$mytemplate`을 역참조한다. 반면에 `template` 함수는 문자열 리터럴만 받아들인다.\n\n## 블록 사용 피하기\n\nGo 템플릿 언어는 개발자가 나중에 오버라이드되는 기본 구현을 제공할 수 있게 해주는 `block` 키워드를 제공한다. Helm 차트에서는 동일한 블록의 여러 구현이 제공되면 어떤 것이 선택될지 예측할 수 없기 때문에 블록은 오버라이드하기에 최적의 도구가 아니다.\n\n대신 `include`를 사용하는 것을 권장한다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Values 파일\ndescription: \"--values 플래그 사용법 설명\"\nsidebar_position: 4\n---\n\n이전 섹션에서 우리는 헬름 템플릿에서 제공하는 빌트인 객체를 살펴봤다. 빌트인 객체 중 하나는 `Values`이다. 이 객체는 차트로 전달된 값에 접근할 수 있게 해준다. 이 객체의 내용들은 여러 출처에서 나온다:\n\n- 본 차트에 포함된 `values.yaml` 파일\n- 서브 차트의 경우, 부모 차트의 `values.yaml` 파일\n- `-f` 플래그 (`helm install -f myvals.yaml ./mychart`)가 있는 `helm install` 또는 `helm upgrade`로 전달된 `values.yaml` 파일\n- `--set` (예: `helm install --set foo=bar ./mychart`)과 함께 전달된 개별 매개변수\n\n위 목록은 적용될 값의 순서이다: 기본 값인 `values.yaml`은 부모 차트의 `values.yaml`에 의해 재정의될 수 있고, 사용자가 제공한 `values.yaml` 파일에 의해 재정의될 수 있으며, `--set` 매개변수에 의해 재정의될 수 있다.\n\nValues 파일은 일반 YAML 파일이다. `mychart/values.yaml` 파일을 편집한 후 ConfigMap 템플릿을 편집해보자.\n\n`values.yaml`의 기본값을 제거하고, 다음 하나의 매개변수만 설정하자:\n\n```yaml\nfavoriteDrink: coffee\n```\n\n이제 템플릿 내부에서 다음과 같이 사용할 수 있다: \n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\n마지막 줄에서 `Values`의 속성으로 `favoriteDrink`를 사용했다:\n`{{ .Values.favoriteDrink }}`.\n\n적용된 결과를 확인해보자.\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\n`favoriteDrink`가 기본 `values.yaml` 파일에서 `coffee`로 설정했기 때문에, 그 값이 템플릿에 표시되었다. 우리는 `helm install` 사용 시 `--set` 플래그를 추가하여 해당 값을 쉽게 재정의할 수 있다:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\n`--set` 플래그는 기본 `values.yaml` 파일보다 높은 우선순위를 가지고 있으므로, 템플릿의 값이 `drink: slurm`으로 재정의되었다.\n\nValues 파일에는 구조화된 값들을 더 추가할 수 있다. 예를 들어, `values.yaml` 파일에 `favorite` 섹션을 추가한 다음 몇 가지 키를 더 추가할 수 있다:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\n이를 적용하기 위해 템플릿을 약간 수정해보자:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\n이런 방식으로 중첩된 값을 사용할 수 있지만, 평면화(flat)한 값을 사용하여 트리 구조를 얕게 유지하는 것을 권장한다. 서브 차트에 값을 할당할 때, 트리 구조를 사용하여 값을 지정하는 방법을 알아보자.\n\n## 기본 키 삭제하기\n\n기본 값에서 키를 삭제하는 경우, 삭제할 키의 값을 `null`로 지정할 수 있다. 이 경우 헬름은 재정의된 키를 제거할 것이다. \n\n예를 들어, Drupal 차트는 사용자 정의 이미지 사용하는 경우 활성 프로브를 구성할 수 있다. 기본 값은 다음과 같다:\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\n만약 활성 프로브를 `httpGet` 대신에 `exec`를 사용하여 `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`로 대체하고 싶다면, Helm은 기본 키와 재정의된 키를 함께 병합하여 다음과 같은 YAML을 생성할 것이다:\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\n하지만, Kubernetes는 둘 이상의 활성 프로브 핸들러를 정의할 수 없기 때문에 실행에 실패한다. 이 문제를 해결하려면, `livenessProbe.httpGet`을 null로 설정하여 해당 키를 삭제해야 한다:\n\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\n몇 가지의 빌트인 객체를 이용하여 템플릿에 값을 전달했다. 이제 템플릿 엔진의 함수와 파이프라인에 대해 알아보자. \n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: 변수\ndescription: 템플릿에서 변수 사용하기\nsidebar_position: 7\n---\n\n함수, 파이프라인, 객체, 그리고 흐름 제어 구조를 모두 살펴봤으니, 이제 많은 프로그래밍 언어에서\n기본적으로 다루는 개념 중 하나인 변수에 대해 알아보겠습니다. 템플릿에서 변수는 자주 사용되지는 않지만,\n코드를 단순화하고 `with` 및 `range`를 더 효과적으로 사용하는 방법을 살펴보겠습니다.\n\n이전 예제에서 다음 코드가 실패하는 것을 확인했습니다:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name`은 `with` 블록에서 제한된 스코프 안에 포함되어 있지 않습니다.\n스코프 문제를 해결하는 한 가지 방법은 현재 스코프와 관계없이 접근할 수 있는 변수에 객체를 할당하는 것입니다.\n\nHelm 템플릿에서 변수는 다른 객체에 대한 이름이 있는 참조입니다. 변수는 `$name` 형식을 따릅니다.\n변수는 특별한 할당 연산자 `:=`를 사용하여 할당됩니다. 위의 예제를 `Release.Name`에 변수를 사용하도록 다시 작성해 보겠습니다.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\n`with` 블록을 시작하기 전에 `$relname := .Release.Name`을 할당했습니다.\n이제 `with` 블록 안에서도 `$relname` 변수는 여전히 릴리스 이름을 가리킵니다.\n\n위 코드를 실행하면 다음과 같은 결과가 생성됩니다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\n변수는 특히 `range` 루프에서 유용합니다. 리스트 형태의 객체에서 인덱스와 값을 모두 캡처하는 데 사용할 수 있습니다:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\n`range`가 먼저 오고, 그 다음 변수, 할당 연산자, 그리고 리스트 순서입니다.\n이렇게 하면 정수 인덱스(0부터 시작)가 `$index`에 할당되고 값이 `$topping`에 할당됩니다.\n실행하면 다음과 같이 생성됩니다:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\n키와 값이 모두 있는 데이터 구조의 경우, `range`를 사용하여 둘 다 가져올 수 있습니다.\n예를 들어, `.Values.favorite`를 다음과 같이 순회할 수 있습니다:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\n첫 번째 반복에서 `$key`는 `drink`이고 `$val`은 `coffee`가 되며,\n두 번째 반복에서 `$key`는 `food`이고 `$val`은 `pizza`가 됩니다.\n위 코드를 실행하면 다음과 같이 생성됩니다:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\n변수는 일반적으로 \"전역\"이 아닙니다. 변수는 선언된 블록 내에서만 스코프가 유효합니다.\n앞서 템플릿의 최상위 레벨에서 `$relname`을 할당했습니다.\n해당 변수는 전체 템플릿에서 스코프 내에 있습니다. 하지만 마지막 예제에서\n`$key`와 `$val`은 `{{ range... }}{{ end }}` 블록 안에서만 스코프 내에 있습니다.\n\n그러나 항상 루트 컨텍스트를 가리키는 특별한 변수 `$`가 있습니다.\nrange 루프 안에서 차트의 릴리스 이름을 알아야 할 때 매우 유용합니다.\n\n다음은 이를 보여주는 예제입니다:\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Many helm templates would use `.` below, but that will not work,\n    # however `$` will work here\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # I cannot reference .Chart.Name, but I can do $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Value from appVersion in Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\n지금까지 하나의 파일에 선언된 하나의 템플릿만 살펴봤습니다. 하지만 Helm 템플릿 언어의 강력한 기능 중\n하나는 여러 템플릿을 선언하고 함께 사용할 수 있다는 것입니다. 다음 섹션에서 이에 대해 알아보겠습니다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: 다음 단계\ndescription: 마무리 - 도움이 되는 다른 유용한 문서들\nsidebar_position: 14\n---\n\n본 가이드는 차트 개발자에게 Helm의 템플릿 언어를 사용하는 방법을 깊이 이해시키기 위한 것이다.\n템플릿 개발의 기술적 관점이 중심이 된다.\n\n그러나 이 가이드에서도 실제 차트 개발에 필요한 많은 것들을 모두 다루지는 못했다.\n새로운 차트를 작성할 때 도움이 되는 다른 유용한 문서들은 다음과 같다.\n\n- CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0)는\n  차트를 찾는 데 없어서는 안 될 소스이다.\n- Kubernetes [문서](https://kubernetes.io/docs/home/)에서는\n  ConfigMap과 Secret부터 DaemonSet과 Deployment까지, \n  사용할 수 있는 다양한 리소스의 자세한 예시를 제공한다.\n- Helm [차트 가이드](/topics/charts.md)에서는 \n  차트 사용 워크플로우를 설명한다.\n- Helm [차트 훅 가이드](/topics/charts_hooks.md)에서는 \n  라이프사이클 훅을 만드는 방법을 설명한다.\n- Helm [차트 팁과 트릭](/howto/charts_tips_and_tricks.md) 문서에서는 \n  차트 작성에 유용한 팁을 제공한다.\n- [Sprig 문서](https://github.com/Masterminds/sprig)에는 \n  60개 이상의 템플릿 함수가 문서화되어 있다.\n- [Go 템플릿 문서](https://godoc.org/text/template)에서는 \n  템플릿 문법을 자세히 설명한다.\n- [Schelm 도구](https://github.com/databus23/schelm)는 \n  차트 디버깅에 유용한 헬퍼 유틸리티이다.\n\n때로는 질문을 하고 경험 많은 개발자에게 답을 얻는 것이 더 쉬울 수 있다.\n가장 좋은 곳은 [Kubernetes Slack](https://kubernetes.slack.com)의 Helm 채널들이다:\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\n마지막으로, 이 문서에서 오류나 누락을 찾았거나,\n새로운 컨텐츠를 제안하거나 기여하고자 한다면, \n[Helm 프로젝트](https://github.com/helm/helm-www)를 방문하자.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"부록: YAML 기법\"\ndescription: YAML 명세와 그것이 Helm에 어떻게 적용되는지 자세히 알아보기\nsidebar_position: 15\n---\n\n이 가이드의 대부분은 템플릿 언어 작성에 초점을 맞추었다.\n여기서는 YAML 형식을 살펴볼 것이다.\nYAML에는 템플릿 작성자로서 템플릿의 오류를 줄이고 가독성을 높이는 데 활용할 수 있는 유용한 기능들이 있다.\n\n## 스칼라(scalar)와 콜렉션(collection)\n\n[YAML 명세](https://yaml.org/spec/1.2/spec.html)에 따르면,\n두 가지 유형의 콜렉션과 다양한 스칼라 자료형이 있다.\n\n두 가지 콜렉션 유형은 맵(map)과 시퀀스(sequence)이다:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\n스칼라 값은 (콜렉션과 반대되는) 개별 값이다.\n\n### YAML에서의 스칼라 자료형\n\nHelm의 YAML 방언에서 값의 스칼라 자료형은 Kubernetes의 리소스 정의 스키마를 포함한\n복잡한 규칙 집합에 의해 결정된다.\n하지만 자료형을 추론할 때 다음 규칙들이 일반적으로 적용된다.\n\n정수나 부동 소수점이 따옴표 없는 값이면 일반적으로 숫자형으로 처리된다:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\n그러나 따옴표로 감싸면 문자열로 처리된다:\n\n```yaml\ncount: \"1\" # <-- string, not int\nsize: '2.34' # <-- string, not float\n```\n\n불리언도 마찬가지다:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # string\n```\n\n빈 값을 나타내는 단어는 `null`이다 (`nil`이 아님).\n\n`port: \"80\"`은 유효한 YAML이며 템플릿 엔진과 YAML 파서를 모두 통과하지만,\nKubernetes가 `port`를 정수로 기대하는 경우 실패한다는 점에 유의하자.\n\n어떤 경우에는 YAML 노드 태그를 사용하여 특정 자료형 추론을 강제할 수 있다:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\n위 예제에서 `!!str`은 파서에게 `age`가 정수처럼 보여도 문자열이라고 알려준다.\n그리고 `port`는 따옴표로 감싸져 있어도 정수로 처리된다.\n\n\n## YAML에서의 문자열\n\nYAML 문서에 넣는 데이터의 대부분은 문자열이다.\nYAML에는 문자열을 표현하는 여러 가지 방법이 있다.\n이 섹션에서는 그 방법들을 설명하고 일부를 사용하는 방법을 보여준다.\n\n문자열을 선언하는 세 가지 \"인라인\" 방식이 있다:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\n모든 인라인 스타일은 한 줄에 있어야 한다.\n\n- 따옴표 없는 값은 이스케이프되지 않는다. 따라서 어떤 문자를 사용할지 주의해야 한다.\n- 큰따옴표 문자열은 `\\`로 특정 문자를 이스케이프할 수 있다.\n  예를 들어 `\"\\\"Hello\\\", she said\"`처럼 쓸 수 있다. `\\n`으로 줄바꿈을 이스케이프할 수 있다.\n- 작은따옴표 문자열은 \"리터럴\" 문자열이며 `\\`를 사용하여 문자를 이스케이프하지 않는다.\n  유일한 이스케이프 시퀀스는 `''`이며, 이것은 단일 `'`로 디코딩된다.\n\n한 줄 문자열 외에도 멀티라인 문자열을 선언할 수 있다:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\n위 예제에서 `coffee`의 값은 `Latte\\nCappuccino\\nEspresso\\n`과 동일한 단일 문자열로 처리된다.\n\n`|` 다음의 첫 번째 줄은 올바르게 들여쓰기해야 한다는 점에 유의하자.\n따라서 다음과 같이 하면 위 예제가 깨질 수 있다:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\n`Latte`가 잘못 들여쓰기되었기 때문에 다음과 같은 오류가 발생한다:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\n템플릿에서는 위 오류를 방지하기 위해 멀티라인 문서에 가짜 \"첫 번째 줄\" 내용을 넣는 것이\n더 안전한 경우가 있다:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\n첫 번째 줄이 무엇이든 문자열의 출력에 그대로 유지된다는 점에 유의하자.\n예를 들어 이 기법을 사용하여 파일 내용을 ConfigMap에 주입하는 경우,\n주석은 해당 항목을 읽는 쪽에서 기대하는 유형이어야 한다.\n\n### 멀티라인 문자열에서 스페이스 처리\n\n위 예제에서 `|`를 사용하여 멀티라인 문자열을 나타냈다.\n그런데 문자열 내용 뒤에 후행 `\\n`이 붙는다는 점을 주목하자.\nYAML 프로세서가 후행 줄바꿈을 제거하게 하려면 `|` 뒤에 `-`를 추가하면 된다:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\n이제 `coffee` 값은 `Latte\\nCappuccino\\nEspresso`가 된다 (후행 `\\n` 없음).\n\n반대로 모든 후행 공백을 유지하고 싶을 때도 있다.\n`|+` 표기법을 사용하면 된다:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\n이제 `coffee` 값은 `Latte\\nCappuccino\\nEspresso\\n\\n\\n`이 된다.\n\n텍스트 블록 내부의 들여쓰기는 그대로 유지되며, 줄바꿈도 보존된다:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\n위 경우 `coffee`는 `Latte\\n  12 oz\\n  16 oz\\nCappuccino\\nEspresso`가 된다.\n\n### 들여쓰기와 템플릿\n\n템플릿을 작성할 때 파일 내용을 템플릿에 주입하고 싶을 수 있다.\n이전 챕터에서 보았듯이 두 가지 방법이 있다:\n\n- `{{ .Files.Get \"FILENAME\" }}`을 사용하여 차트 내 파일의 내용을 가져온다.\n- `{{ include \"TEMPLATE\" . }}`을 사용하여 템플릿을 렌더링한 다음 그 내용을 차트에 배치한다.\n\n파일을 YAML에 삽입할 때 위의 멀티라인 규칙을 이해하는 것이 좋다.\n정적 파일을 삽입하는 가장 쉬운 방법은 보통 다음과 같다:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\n위에서 들여쓰기하는 방식에 주목하자: `indent 2`는 템플릿 엔진에게\n\"myfile.txt\"의 모든 줄을 두 칸 들여쓰기하라고 지시한다.\n해당 템플릿 줄 자체는 들여쓰기하지 않는다는 점에 유의하자.\n만약 그렇게 하면 첫 번째 줄의 파일 내용이 두 번 들여쓰기되기 때문이다.\n\n### 접힌 멀티라인 문자열\n\nYAML에서 여러 줄로 문자열을 표현하되 해석될 때는 하나의 긴 줄로 처리되길 원할 때가 있다.\n이것을 \"접기(folding)\"라고 한다.\n접힌 블록을 선언하려면 `|` 대신 `>`를 사용한다:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\n위에서 `coffee` 값은 `Latte Cappuccino Espresso\\n`이 된다.\n마지막 줄바꿈을 제외한 모든 줄바꿈이 공백으로 변환된다.\n공백 제어를 접힌 텍스트 마커와 결합할 수 있으므로, `>-`는 모든 줄바꿈을 대체하거나 제거한다.\n\n접힌 구문에서 텍스트를 들여쓰기하면 줄이 그대로 보존된다는 점에 유의하자.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\n위 예제는 `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`를 생성한다.\n공백과 줄바꿈이 모두 그대로 남아 있다.\n\n## 하나의 파일에 여러 문서 넣기\n\n단일 파일에 둘 이상의 YAML 문서를 넣을 수 있다.\n새 문서 앞에 `---`를 붙이고 문서 끝에 `...`을 붙이면 된다.\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\n대부분의 경우 `---`나 `...`을 생략할 수 있다.\n\nHelm의 일부 파일은 둘 이상의 문서를 포함할 수 없다.\n예를 들어 `values.yaml` 파일 내에 둘 이상의 문서가 제공되면 첫 번째 문서만 사용된다.\n\n그러나 템플릿 파일은 둘 이상의 문서를 가질 수 있다.\n이 경우 파일(및 모든 문서)은 템플릿 렌더링 중에 하나의 객체로 처리된다.\n그러나 결과 YAML은 Kubernetes로 전달되기 전에 여러 문서로 분할된다.\n\n파일당 여러 문서는 절대적으로 필요한 경우에만 사용하는 것을 권장한다.\n파일에 여러 문서가 있으면 디버깅이 어려울 수 있다.\n\n## YAML은 JSON의 상위집합이다\n\nYAML은 JSON의 상위집합이므로, 유효한 JSON 문서는 _모두_ 유효한 YAML이어야 한다.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\n위는 다음을 표현하는 또 다른 방법이다:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\n그리고 이 둘을 (주의하여) 혼합할 수 있다:\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\n세 가지 모두 동일한 내부 표현으로 파싱되어야 한다.\n\n이것은 `values.yaml` 같은 파일이 JSON 데이터를 포함할 수 있다는 것을 의미하지만,\nHelm은 파일 확장자 `.json`을 유효한 접미사로 취급하지 않는다.\n\n## YAML 앵커(anchor)\n\nYAML 명세는 값에 대한 참조를 저장하고 나중에 그 참조로 값을 참조하는 방법을 제공한다.\nYAML에서는 이것을 \"앵커링(anchoring)\"이라고 한다:\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\n위에서 `&favoriteCoffee`는 `Cappuccino`에 대한 참조를 설정한다.\n나중에 해당 참조는 `*favoriteCoffee`로 사용된다.\n따라서 `coffees`는 `Latte, Cappuccino, Espresso`가 된다.\n\n앵커가 유용한 경우가 몇 가지 있지만, 미묘한 버그를 일으킬 수 있는 측면이 하나 있다:\nYAML이 처음 소비될 때 참조가 확장된 다음 버려진다.\n\n따라서 위 예제를 디코딩한 다음 다시 인코딩하면 결과 YAML은 다음과 같다:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nHelm과 Kubernetes는 종종 YAML 파일을 읽고, 수정하고, 다시 작성하기 때문에\n앵커가 손실된다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: 헬름 2 이후의 변경사항\nsidebar_position: 1\n---\n\n## 헬름 2 이후의 변경사항\n\n다음은 헬름 3에서 도입된 모든 주요 변경사항에 대한 전체 목록이다.\n\n### Tiller 제거\n\n헬름 2 개발 주기 동안 Tiller가 도입되었다. Tiller는 공유 클러스터에서 \n작업하는 팀에 중요한 역할을 했다 - 여러 운영자가 동일한 릴리스 세트와 \n상호 작용할 수 있도록 해주었다.\n\n쿠버네티스 1.6에서 역할 기반 접근 제어(RBAC)가 기본으로 활성화되면서, \n프로덕션 시나리오에서 Tiller를 잠그는 것이 관리하기 더 어려워졌다. \n가능한 보안 정책의 수가 방대하기 때문에, 우리의 입장은 허용적인 기본 \n구성을 제공하는 것이었다. 이를 통해 처음 사용하는 사용자가 보안 제어에 \n먼저 뛰어들지 않고도 헬름과 쿠버네티스를 실험해 볼 수 있었다. \n안타깝게도 이 허용적인 구성은 사용자에게 의도하지 않은 광범위한 \n권한을 부여할 수 있었다. DevOps와 SRE는 멀티테넌트 클러스터에 \nTiller를 설치할 때 추가적인 운영 단계를 배워야 했다.\n\n커뮤니티 구성원들이 특정 시나리오에서 헬름을 어떻게 사용하는지 들은 후, \nTiller의 릴리스 관리 시스템이 상태를 유지하거나 헬름 릴리스 정보의 \n중앙 허브 역할을 하기 위해 클러스터 내 운영자에 의존할 필요가 없다는 \n것을 발견했다. 대신, 쿠버네티스 API 서버에서 정보를 가져오고, \n클라이언트 측에서 차트를 렌더링하고, 쿠버네티스에 설치 기록을 \n저장하면 되었다.\n\nTiller의 주요 목표는 Tiller 없이도 달성할 수 있었으므로, 헬름 3에 \n관한 첫 번째 결정 중 하나는 Tiller를 완전히 제거하는 것이었다.\n\nTiller가 사라지면서 헬름의 보안 모델이 근본적으로 단순해졌다. \n헬름 3는 이제 현대 쿠버네티스의 모든 보안, 신원 확인 및 권한 부여 \n기능을 지원한다. 헬름의 권한은 [kubeconfig\n파일](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 \n사용하여 평가된다. 클러스터 관리자는 원하는 세분화 수준으로 \n사용자 권한을 제한할 수 있다. 릴리스는 여전히 클러스터 내에 \n기록되며, 헬름의 나머지 기능은 그대로 유지된다.\n\n### 개선된 업그레이드 전략: 3-way 전략적 병합 패치\n\n헬름 2는 2-way 전략적 병합 패치를 사용했다. 업그레이드 중에 가장 \n최근 차트의 매니페스트와 제안된 차트의 매니페스트(`helm upgrade` \n중에 제공된 것)를 비교했다. 이 두 차트 간의 차이를 비교하여 \n쿠버네티스의 리소스에 적용해야 할 변경 사항을 결정했다. \n대역 외에서 변경이 적용된 경우(예: `kubectl edit` 중에), \n해당 변경 사항은 고려되지 않았다. 이로 인해 리소스가 이전 상태로 \n롤백할 수 없게 되었다: 헬름은 마지막으로 적용된 차트의 매니페스트만을 \n현재 상태로 간주했기 때문에, 차트 상태에 변경이 없으면 라이브 \n상태는 변경되지 않고 그대로 유지되었다.\n\n헬름 3에서는 이제 3-way 전략적 병합 패치를 사용한다. 헬름은 \n패치를 생성할 때 이전 매니페스트, 라이브 상태, 새 매니페스트를 \n고려한다.\n\n#### 예시\n\n이 변경 사항이 영향을 미치는 몇 가지 일반적인 예시를 살펴보자.\n\n##### 라이브 상태가 변경된 곳에서 롤백\n\n팀이 방금 헬름을 사용하여 쿠버네티스의 프로덕션에 애플리케이션을 \n배포했다. 차트에는 레플리카 수가 3으로 설정된 Deployment 객체가 \n포함되어 있다:\n\n```console\n$ helm install myapp ./myapp\n```\n\n새 개발자가 팀에 합류한다. 프로덕션 클러스터를 관찰하던 첫날, \n끔찍한 커피-키보드-엎지름 사고가 발생하고 그들은 `kubectl scale`로 \n프로덕션 deployment를 3개 레플리카에서 0개로 줄인다.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\n팀의 다른 개발자가 프로덕션 사이트가 다운된 것을 발견하고 \n릴리스를 이전 상태로 롤백하기로 결정한다:\n\n```console\n$ helm rollback myapp\n```\n\n무슨 일이 일어날까?\n\n헬름 2에서는 이전 매니페스트와 새 매니페스트를 비교하여 패치를 \n생성했다. 이것은 롤백이기 때문에 동일한 매니페스트이다. 헬름은 \n이전 매니페스트와 새 매니페스트 사이에 차이가 없기 때문에 변경할 \n것이 없다고 판단했다. 레플리카 수는 계속 0으로 유지된다. \n큰 혼란에 빠진다.\n\n헬름 3에서는 이전 매니페스트, 라이브 상태, 새 매니페스트를 \n사용하여 패치를 생성한다. 헬름은 이전 상태가 3이었고, 라이브 \n상태가 0이며, 새 매니페스트가 다시 3으로 변경하기를 원한다는 \n것을 인식하므로, 상태를 다시 3으로 변경하는 패치를 생성한다.\n\n##### 라이브 상태가 변경된 곳에서 업그레이드\n\n많은 서비스 메시와 다른 컨트롤러 기반 애플리케이션은 쿠버네티스 \n객체에 데이터를 주입한다. 이것은 사이드카, 레이블 또는 기타 정보일 \n수 있다. 이전에 차트에서 렌더링된 다음 매니페스트가 있었다면:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\n그리고 라이브 상태가 다른 애플리케이션에 의해 다음과 같이 \n수정되었다면:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n이제 `nginx` 이미지 태그를 `2.1.0`으로 업그레이드하려고 한다. \n따라서 다음 매니페스트가 있는 차트로 업그레이드한다:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\n무슨 일이 일어날까?\n\n헬름 2에서 헬름은 이전 매니페스트와 새 매니페스트 사이의 \n`containers` 객체 패치를 생성한다. 패치 생성 중에 클러스터의 \n라이브 상태는 고려되지 않는다.\n\n클러스터의 라이브 상태는 다음과 같이 수정된다:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\n사이드카 파드가 라이브 상태에서 제거된다. 더 큰 혼란에 빠진다.\n\n헬름 3에서 헬름은 이전 매니페스트, 라이브 상태, 새 매니페스트 \n사이의 `containers` 객체 패치를 생성한다. 새 매니페스트가 \n이미지 태그를 `2.1.0`으로 변경하지만, 라이브 상태에는 사이드카 \n컨테이너가 포함되어 있다는 것을 인식한다.\n\n클러스터의 라이브 상태는 다음과 같이 수정된다:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### 릴리스 이름이 이제 네임스페이스 범위로 지정됨\n\nTiller가 제거되면서 각 릴리스에 대한 정보를 어딘가에 저장해야 했다. \n헬름 2에서는 Tiller와 동일한 네임스페이스에 저장되었다. \n실제로 이는 릴리스에서 이름이 사용되면 다른 네임스페이스에 \n배포되더라도 다른 릴리스가 동일한 이름을 사용할 수 없음을 의미했다.\n\n헬름 3에서는 특정 릴리스에 대한 정보가 이제 릴리스 자체와 동일한 \n네임스페이스에 저장된다. 이는 사용자가 이제 두 개의 별도 \n네임스페이스에서 `helm install wordpress stable/wordpress`를 \n실행할 수 있으며, 현재 네임스페이스 컨텍스트를 변경하여 \n`helm list`로 각각을 참조할 수 있음을 의미한다 \n(예: `helm list --namespace foo`).\n\n네이티브 클러스터 네임스페이스와의 이러한 더 큰 정렬로 인해 \n`helm list` 명령은 더 이상 기본적으로 모든 릴리스를 나열하지 \n않는다. 대신 현재 쿠버네티스 컨텍스트의 네임스페이스에 있는 \n릴리스만 나열한다(즉, `kubectl config view --minify`를 \n실행할 때 표시되는 네임스페이스). 또한 헬름 2와 유사한 동작을 \n얻으려면 `helm list`에 `--all-namespaces` 플래그를 \n제공해야 한다.\n\n### 기본 스토리지 드라이버로 Secrets 사용\n\n헬름 3에서는 이제 Secrets이 [기본 스토리지\n드라이버](/topics/advanced.md#storage-backends)로 사용된다. \n헬름 2는 기본적으로 릴리스 정보를 저장하기 위해 ConfigMaps를 \n사용했다. 헬름 2.7.0에서 릴리스 정보를 저장하기 위해 Secrets를 \n사용하는 새로운 스토리지 백엔드가 구현되었으며, 이제 헬름 3에서 \n기본값이 되었다.\n\n헬름 3 기본값으로 Secrets로 변경하면 쿠버네티스의 Secret 암호화 \n릴리스와 함께 차트를 보호하는 추가 보안이 가능해진다.\n\n[저장 시 secrets \n암호화](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)는 \n쿠버네티스 1.7에서 알파 기능으로 사용 가능해졌으며 쿠버네티스 \n1.13에서 안정화되었다. 이를 통해 사용자는 저장 시 헬름 릴리스 \n메타데이터를 암호화할 수 있으므로, 나중에 Vault와 같은 것을 \n사용하도록 확장할 수 있는 좋은 시작점이다.\n\n### Go import 경로 변경\n\n헬름 3에서 헬름은 Go import 경로를 `k8s.io/helm`에서 \n`helm.sh/helm/v3`로 전환했다. 헬름 3 Go 클라이언트 라이브러리로 \n업그레이드하려는 경우 import 경로를 변경해야 한다.\n\n### Capabilities\n\n렌더링 단계에서 사용할 수 있는 `.Capabilities` 내장 객체가 \n단순화되었다.\n\n[내장 객체](/chart_template_guide/builtin_objects.md)\n\n### JSONSchema를 사용한 차트 값 검증\n\n이제 차트 값에 JSON Schema를 적용할 수 있다. 이를 통해 사용자가 \n제공한 값이 차트 관리자가 설정한 스키마를 따르도록 보장하여, \n사용자가 차트에 잘못된 값 세트를 제공할 때 더 나은 오류 보고를 \n제공한다.\n\n검증은 다음 명령어가 호출될 때 발생한다:\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\n자세한 정보는 [스키마 파일](/topics/charts.md#schema-files) \n문서를 참조하라.\n\n### `requirements.yaml`을 `Chart.yaml`로 통합\n\n차트 의존성 관리 시스템이 requirements.yaml 및 requirements.lock에서 \nChart.yaml 및 Chart.lock으로 이동했다. 헬름 3용 새 차트는 \n새 형식을 사용하는 것이 좋다. 그러나 헬름 3는 여전히 Chart API \n버전 1(`v1`)을 이해하고 기존 `requirements.yaml` 파일을 로드한다.\n\n헬름 2에서 `requirements.yaml`은 다음과 같았다:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\n헬름 3에서 의존성은 동일한 방식으로 표현되지만, 이제 \n`Chart.yaml`에서 표현된다:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\n차트는 여전히 `charts/` 디렉토리에 다운로드되고 배치되므로, \n`charts/` 디렉토리에 벤더링된 서브차트는 수정 없이 계속 작동한다.\n\n### 설치 시 이름(또는 --generate-name) 필수\n\n헬름 2에서는 이름이 제공되지 않으면 자동 생성된 이름이 부여되었다. \n프로덕션에서 이것은 유용한 기능이라기보다는 골칫거리로 판명되었다. \n헬름 3에서 `helm install`에 이름이 제공되지 않으면 헬름은 오류를 \n발생시킨다.\n\n여전히 자동으로 이름이 생성되기를 원하는 사람들은 `--generate-name` \n플래그를 사용하여 생성할 수 있다.\n\n### OCI 레지스트리에 차트 푸시\n\n이것은 헬름 3에서 도입된 실험적 기능이다. 사용하려면 환경 변수 \n`HELM_EXPERIMENTAL_OCI=1`을 설정한다.\n\n높은 수준에서 차트 리포지토리는 차트를 저장하고 공유할 수 있는 \n장소이다. 헬름 클라이언트는 헬름 차트를 패키징하여 차트 \n리포지토리로 전송한다. 간단히 말해, 차트 리포지토리는 index.yaml \n파일과 일부 패키지된 차트를 호스팅하는 기본 HTTP 서버이다.\n\n차트 리포지토리 API가 가장 기본적인 스토리지 요구 사항을 \n충족하는 데는 여러 이점이 있지만, 몇 가지 단점이 나타나기 시작했다:\n\n- 차트 리포지토리는 프로덕션 환경에서 필요한 대부분의 보안 구현을 \n  추상화하기가 매우 어렵다. 프로덕션 시나리오에서 인증 및 권한 \n  부여를 위한 표준 API를 갖는 것이 매우 중요하다.\n- 차트의 무결성과 출처를 서명하고 확인하는 데 사용되는 헬름의 \n  차트 출처 도구는 차트 게시 프로세스의 선택적 부분이다.\n- 멀티테넌트 시나리오에서 동일한 차트가 다른 테넌트에 의해 \n  업로드될 수 있어 동일한 콘텐츠를 저장하는 데 두 배의 스토리지 \n  비용이 든다. 이를 처리하도록 설계된 더 스마트한 차트 \n  리포지토리가 있지만 공식 사양의 일부는 아니다.\n- 검색, 메타데이터 정보 및 차트 가져오기에 단일 인덱스 파일을 \n  사용하면 안전한 멀티테넌트 구현에서 설계하기 어렵거나 투박해진다.\n\nDocker의 Distribution 프로젝트(Docker Registry v2라고도 함)는 \nDocker Registry 프로젝트의 후속작이다. 많은 주요 클라우드 공급업체가 \nDistribution 프로젝트의 제품을 제공하고 있으며, 많은 공급업체가 \n동일한 제품을 제공함에 따라 Distribution 프로젝트는 수년간의 \n강화, 보안 모범 사례 및 실전 테스트의 혜택을 받았다.\n\n차트를 패키징하고 Docker 레지스트리에 푸시하는 방법에 대한 자세한 \n정보는 `helm help chart` 및 `helm help registry`를 참조하라.\n\n자세한 정보는 [이 페이지](/topics/registries.md)를 참조하라.\n\n### `helm serve` 제거\n\n`helm serve`는 개발 목적으로 로컬 차트 리포지토리를 머신에서 \n실행했다. 그러나 개발 도구로서 많은 채택을 받지 못했고 설계에 \n수많은 문제가 있었다. 결국 우리는 이를 제거하고 플러그인으로 \n분리하기로 결정했다.\n\n`helm serve`와 유사한 경험을 위해 \n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)의 \n로컬 파일 시스템 스토리지 옵션과 \n[servecm 플러그인](https://github.com/jdolitsky/helm-servecm)을 \n살펴보라.\n\n\n### 라이브러리 차트 지원\n\n헬름 3는 \"라이브러리 차트\"라는 차트 클래스를 지원한다. 이것은 \n다른 차트에서 공유되지만 자체 릴리스 아티팩트를 생성하지 않는 \n차트이다. 라이브러리 차트의 템플릿은 `define` 요소만 선언할 수 \n있다. 전역 범위의 비-`define` 콘텐츠는 단순히 무시된다. \n이를 통해 사용자는 많은 차트에서 재사용할 수 있는 코드 스니펫을 \n재사용하고 공유하여 중복을 피하고 차트를 \n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)하게 \n유지할 수 있다.\n\n라이브러리 차트는 Chart.yaml의 dependencies 지시문에서 선언되며, \n다른 차트와 마찬가지로 설치 및 관리된다.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\n우리는 이 기능이 차트 개발자에게 열어주는 사용 사례와 라이브러리 \n차트를 사용함으로써 발생하는 모범 사례를 보게 되어 매우 기쁘다.\n\n### Chart.yaml apiVersion 증가\n\n라이브러리 차트 지원의 도입과 requirements.yaml의 Chart.yaml로의 \n통합으로, 헬름 2의 패키지 형식을 이해하는 클라이언트는 이러한 \n새로운 기능을 이해하지 못할 것이다. 그래서 Chart.yaml의 \napiVersion을 `v1`에서 `v2`로 증가시켰다.\n\n`helm create`는 이제 이 새로운 형식을 사용하여 차트를 생성하므로, \n기본 apiVersion도 거기서 증가되었다.\n\n두 버전의 헬름 차트를 모두 지원하려는 클라이언트는 패키지 형식을 \n구문 분석하는 방법을 이해하기 위해 Chart.yaml의 `apiVersion` \n필드를 검사해야 한다.\n\n### XDG 기본 디렉토리 지원\n\n[XDG 기본 디렉토리 \n사양](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)은 \n구성, 데이터 및 캐시 파일이 파일 시스템에 저장되어야 하는 위치를 \n정의하는 이식 가능한 표준이다.\n\n헬름 2에서 헬름은 이 모든 정보를 `~/.helm`(애칭으로 `helm home`으로 \n알려진)에 저장했으며, `$HELM_HOME` 환경 변수를 설정하거나 전역 \n플래그 `--home`을 사용하여 변경할 수 있었다.\n\n헬름 3에서 헬름은 이제 XDG 기본 디렉토리 사양에 따라 다음 환경 \n변수를 존중한다:\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\n헬름 플러그인은 `$HELM_HOME`을 스크래치패드 환경으로 사용하려는 \n플러그인과의 하위 호환성을 위해 `$XDG_DATA_HOME`의 별칭으로 \n여전히 `$HELM_HOME`을 전달받는다.\n\n이 변경을 수용하기 위해 플러그인 환경에 여러 새로운 환경 변수도 \n전달된다:\n\n- 캐시 경로를 위한 `$HELM_PATH_CACHE`\n- 구성 경로를 위한 `$HELM_PATH_CONFIG`\n- 데이터 경로를 위한 `$HELM_PATH_DATA`\n\n헬름 3를 지원하려는 헬름 플러그인은 이러한 새로운 환경 변수를 \n대신 사용하는 것을 고려해야 한다.\n\n### CLI 명령어 이름 변경\n\n다른 패키지 관리자의 용어와 더 잘 맞추기 위해 `helm delete`가 \n`helm uninstall`로 이름이 변경되었다. `helm delete`는 여전히 \n`helm uninstall`의 별칭으로 유지되므로 어느 형태든 사용할 수 있다.\n\n헬름 2에서 릴리스 원장을 제거하려면 `--purge` 플래그를 제공해야 \n했다. 이 기능은 이제 기본적으로 활성화되어 있다. 이전 동작을 \n유지하려면 `helm uninstall --keep-history`를 사용하라.\n\n추가로 동일한 규칙을 수용하기 위해 여러 다른 명령어의 이름이 \n변경되었다:\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\n이러한 명령어들도 이전 동사를 별칭으로 유지하므로 어느 형태로든 \n계속 사용할 수 있다.\n\n### 자동 네임스페이스 생성\n\n존재하지 않는 네임스페이스에 릴리스를 생성할 때, 헬름 2는 \n네임스페이스를 생성했다. 헬름 3는 다른 쿠버네티스 도구의 동작을 \n따르며 네임스페이스가 존재하지 않으면 오류를 반환한다. \n`--create-namespace` 플래그를 명시적으로 지정하면 헬름 3가 \n네임스페이스를 생성한다.\n\n### .Chart.ApiVersion은 어떻게 되었나?\n\n헬름은 약어를 대문자로 표기하는 일반적인 CamelCasing 규칙을 \n따른다. 우리는 `.Capabilities.APIVersions.Has`와 같이 코드의 \n다른 곳에서도 이 작업을 수행했다. 헬름 v3에서 우리는 \n`.Chart.ApiVersion`을 이 패턴을 따르도록 수정하여 \n`.Chart.APIVersion`으로 이름을 변경했다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/faq/index.mdx",
    "content": "---\ntitle: 자주 묻는 질문\nsidebar_position: 8\n---\n\n# 자주 묻는 질문\n\n> 헬름 2와 헬름 3의 중요한 차이점은 무엇일까요?\n> 이 페이지는 가장 자주 나오는 질문들에 대한 도움말을 제공합니다.\n\n이 문서를 개선시킬 수 있도록 **도와주시면 감사하겠습니다**.\n정보를 추가, 수정, 삭제하려면 [이슈를 등록](https://github.com/helm/helm-www/issues)하거나\n풀 리퀘스트를 보내주세요.\n\n## 헬름 2 이후 변화\n\n다음은 헬름 3에 도입된 주요 변경사항의 상세 목록입니다.\n\n### 틸러(tiller) 제거\n\n헬름 2 개발 주기에 틸러를 도입했었습니다.\n틸러는 공유 클러스터에서 작업하는 팀에게 중요한 역할을 했습니다.\n서로 다른 운영자가 동일한 릴리스 집합과 상호 작용할 수 있도록 만들어 주었습니다.\n\n쿠버네티스 1.6에서 역할 기반 접근 제어(RBAC)가 기본적으로 활성화되면서,\n운영 시나리오에서 틸러 접근제어를 관리하는 것이 더욱 어려워졌습니다.\n수많은 보안 정책 때문에\n우리의 입장은 허용 가능한 기본 설정을 제공하는 것이었습니다.\n이를 통해 헬름을 처음 접한 사용자는 처음부터 보안 제어를 깊이 알지 못해도\n헬름과 쿠버네티스를 시작해볼 수 있었습니다. 아쉽지만,\n이러한 허용적(permissive) 설정은 의도치 않게 사용자에게 광범위한 권한을 부여할 수 있습니다.\n데브옵스(DevOps)와 사이트 신뢰성 엔지니어(SRE)는 멀티 테넌트 클러스터에 틸러를\n설치할 때 추가적인 작업 단계를 알아야 했습니다.\n\n커뮤니티 구성원들이 특정 시나리오에서 헬름을 어떻게 사용하는지 들은 후,\n틸러의 릴리스 관리 시스템은\n상태를 유지하거나 헬름 릴리스 정보의 중심 허브 역할을 하기 위해\n클러스터 내 운영자에게 의존할 필요가 없다는 것을 알게 되었습니다.\n그 대신 쿠버네티스 API 서버에서 정보를 간단히 가져오고,\n차트 클라이언트 측을 렌더링하며 쿠버네티스에 설치 기록을 보관할 수 있습니다.\n\n틸러의 주요 목표는 틸러 없이도 달성될 수 있습니다.\n그래서 헬름 3와 관련하여 우리가 내린 첫 번째 결정 중 하나는 틸러를 완전히 제거하는 것입니다.\n\n틸러가 사라지면 헬름의 보안 모델이 획기적으로 간소화됩니다.\n헬름 3는 이제 현대 쿠버네티스의 모든 현대적인 보안, 신원 확인 및 인가 기능을 지원합니다. 헬름의 권한은\n[kubeconfig 파일](https://kubernetes.io/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을\n사용하여 평가됩니다.\n클러스터 관리자는 세세하게 사용자 권한을 제한할 수 있습니다.\n릴리스는 여전히 클러스터 내에 기록되며,\n헬름의 나머지 기능은 그대로 유지됩니다.\n\n### 업그레이드 전략 개선: 3 방향 전략적 병합 패치\n\n헬름 2는 양방향 전략적 병합 패치를 사용했었습니다. 업그레이드할 때\n최근 차트의 매니페스트와 새로 제시된 차트의 매니페스트(`helm upgrade` 중에 제공된 것 중\n하나)를 비교했습니다. 쿠버네티스 리소스에 적용해야 할 변경 사항을 알아내기 위해\n두 차트 간의 차이를 비교했습니다.\n클러스터 외부의 활동(예: `kubectl edit` 하는) 중에 변경 사항이 적용되었다면,\n그러한 변경은 고려되지 않았습니다. 이로 인해 리소스가 이전 상태로 롤백할 수 없게 되었습니다.\n헬름은 마지막으로 적용된 차트의 매니페스트만 현재 상태로 간주했기 때문에\n차트의 상태가 변경되지 않은 경우\n활성 상태는 변경되지 않은 상태로 그대로 유지됩니다.\n\n헬름 3는 현재 3 방향 전략적 병합 패치를 사용하고 있습니다.\n헬름은 패치를 생성할 때 이전 매니페스트, 라이브 상태, 새 매니페스트를 고려합니다.\n\n#### 예시\n\n이러한 변화가 어떤 영향을 미치는지 몇 가지 일반적인 예를 살펴보겠습니다.\n\n##### 라이브 상태 변경 시 롤백\n\n당신의 팀은 방금 헬름을 사용하여 쿠버네티스 프로덕션 서버에 애플리케이션을 배포했습니다.\n차트에는 레플리카 수가 3개로 설정된 디플로이먼트(Deployment) 오브젝트를\n포함합니다.\n\n```console\n$ helm install myapp ./myapp\n```\n\n새로운 개발자가 팀에 합류합니다.\n첫날에 프로덕션 클러스터를 살펴보다가, 키보드에 커피를 쏟는 끔찍한 사고가 발생하여\n`kubectl scale` 명령어로 프로덕션 디플로이먼트\n레플리카 수를 3개에서 0개로 축소시킵니다.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\n팀의 다른 개발자는 프로덕션 사이트가 다운된 것을 확인하고\n릴리스를 이전 상태로 롤백하기로 합니다.\n\n```console\n$ helm rollback myapp\n```\n\n어떻게 될까요?\n\n헬름 2에서는 이전 매니페스트를 새 매니페스트와 비교하여 패치를 생성합니다.\n이것은 롤백이기 때문에 동일한 매니페스트입니다.\n헬름에서는 이전 매니페스트와 새 매니페스트 간에\n차이가 없기 때문에 변경할 사항이 없다고 판단합니다.\n레플리카 수는 계속 0입니다. 패닉은 계속됩니다.\n\n헬름 3에서 패치는 이전 매니페스트, 라이브 상태, 새 매니페스트를 사용하여 생성됩니다.\n헬름은 기존 상태가 3이고 라이브 상태가 0에 있으며,\n새 매니페스트는 그것을 다시 3으로 바꾸기를 원하기 때문에,\n패치를 생성하여 상태를 다시 3으로 바꾸게 됩니다.\n\n##### 라이브 상태 변경 시 업그레이드\n\n많은 서비스 메쉬 및 기타 컨트롤러 기반 애플리케이션은 데이터를 쿠버네티스 오브젝트에 주입합니다.\n이것은 사이드카, 레이블 또는 다른 정보일 수 있습니다.\n이전에 차트에서 렌더링된 매니페스트가 있다면 다음과 같습니다.\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\n그리고 다른 애플리케이션이 라이브 상태를 다음과 같이 수정했습니다.\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n이제 `nginx` 이미지 태그를 `2.1.0`으로 업그레이드하려고 합니다.\n따라서 다음과 같은 매니페스트가 있는 차트로 업그레이드합니다.\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\n어떻게 될까요?\n\n헬름 2에서 헬름은 기존 매니페스트와 새로운 매니페스트 사이에\n`containers` 오브젝트의 패치를 생성합니다.\n패치 생성 중에는 클러스터의 라이브 상태가 고려되지 않습니다.\n\n클러스터의 라이브 상태가 다음과 같이 수정됩니다.\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\n사이드카 파드가 라이브 상태에서 제거됩니다. 더 많은 공포가 뒤따릅니다.\n\n헬름 3에서 헬름은 기존 매니페스트, 라이브 상태, 새 매니페스트 사이에\n`container` 오브젝트의 패치를 생성합니다. 새로운 매니페스트가 이미지 태그를\n`2.1.0` 으로 바꾸지만 라이브 상태는 사이드카 컨테이너를 포함합니다.\n\n클러스터의 라이브 상태가 다음과 같이 수정됩니다.\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### 이제 릴리스 이름이 네임스페이스에 할당됩니다\n\n틸러가 제거되면서 각 릴리스에 대한 정보는 어디론가 이동해야 했습니다.\n헬름 2에서는 틸러와 동일한 네임스페이스에 저장되었습니다.\n이는 실제로 릴리스에 이름이 사용되면 다른 네임스페이스에 배포되었더라도\n다른 릴리스에서는 동일한 이름을 사용할 수 없음을 의미합니다.\n\n헬름 3에서는 특정 릴리스에 대한 정보가 릴리스 자체와 동일한 네임스페이스에\n저장됩니다. 즉, 이제 사용자는 별도의 두 네임스페이스에서\n`helm install wordpress stable/wordpress`를 수행할 수 있으며,\n현재 네임스페이스 컨텍스트를 변경하여 `helm list` 를 조회할 수 있습니다.\n(예: `helm list --namespace foo`)\n\n이렇게 네이티브 클러스터 네임스페이스가 보다 개선되면서\n`helm list` 명령은 기본적으로 모든 릴리스를 나열하지 않습니다.\n대신 현재 쿠버네티스 컨텍스트의 네임스페이스에 있는 릴리스만\n나열됩니다(즉, `kubectl config view --minify`를 실행할 때 표시되는 네임스페이스).\n또한 헬름 2와 유사한 동작을 수행하려면 `helm list`에\n`--all-namespaces` 플래그를 주어야 합니다.\n\n### 기본 스토리지 드라이버로서의 시크릿(Secret)\n\n헬름 3에서 시크릿은 이제 [기본 스토리지\n드라이버](//docs/topics/advanced.md#storage-backends)로 사용됩니다. 헬름 2는\n기본적으로 컨피그맵(ConfigMap)을 사용하여 릴리스 정보를 저장합니다. 헬름 2.7.0에서\n릴리스 정보를 저장하기 위해 시크릿을 사용하는 새로운 스토리지 백엔드가 구현되었으며\n헬름 3부터는 기본값이 되었습니다.\n\n헬름 3 기본값을 시크릿으로 변경하면 쿠버네티스의\n시크릿 암호화(Secret Encryption) 릴리스와 함께\n차트를 보호할 수 있습니다.\n\n[미사용 시크릿을 암호화하는\n것](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)은\n쿠버네티스 1.7에서 알파 기능으로 사용 가능하게 되었고\n쿠버네티스 1.13을 기점으로 안정화되었습니다. 이를 통해 사용자는\n미사용 헬름 릴리스 메타데이터를 암호화할 수 있으므로\n나중에 볼트(Vault)와 같은 용도로 확장할 수 있습니다.\n\n### Go import 경로 변경\n\n헬름 3에서 헬름은 Go import 경로를 `k8s.io/helm`에서\n`helm.sh/helm/v3`으로 전환했습니다. 헬름 3 Go 클라이언트 라이브러리로\n업그레이드하려면 import 경로를 변경해야 합니다.\n\n### Capabilities\n\n렌더링 단계에서 사용 가능한 `.Capabilities` 빌트인 객체가\n간소화되었습니다.\n\n[빌트인 객체](/chart_template_guide/builtin_objects.md)\n\n### JSON 스키마로 차트 값 유효성 검사\n\n이제 차트 값(values)에 JSON 스키마를 적용할 수 있습니다.\n이렇게 하면 사용자가 입력한 값이 차트 관리자가 제공한\n스키마를 따르므로 사용자가 차트에 잘못된 값들을 입력할 때\n오류 보고 기능이 향상됩니다.\n\n다음 명령어 중 하나가 호출될 때 유효성 검사가 수행됩니다.\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\n자세한 내용은 [스키마 파일](/topics/charts.md#schema-files) 문서를\n참조하십시오.\n\n### `requirements.yaml`이 `Chart.yaml` 로 통합\n\n차트 의존성 관리 시스템이 requirements.yaml 와 requirements.lock에서\nChart.yaml 와 Chart.lock으로 이동했습니다. 헬름 3에서 새로운 차트는\n새로운 형식을 사용하는 것이 권장됩니다. 그러나 헬름 3는 여전히 차트 API\n버전 1(`v1`)을 이해하고 있으며 기존 `requirements.yaml` 파일을 로드합니다.\n\n헬름 2에서는 `requirements.yaml`이 이렇게 생겼습니다.\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://kubernetes-charts.storage.googleapis.com/\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\n헬름 3에서는 의존성이 동일한 방식으로 표현되지만\n이제 `Chart.yaml`에서 표현됩니다.\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://kubernetes-charts.storage.googleapis.com/\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\n차트는 여전히 `charts/` 디렉토리에 다운로드되므로\n`charts/` 디렉토리에 제공된 하위 차트는\n수정 없이 계속 동작합니다.\n\n### 설치 시 이름(또는 --generate-name)이 필요합니다\n\n헬름 2에서 이름이 주어지지 않은 경우 자동으로 생성된 이름이 지정됩니다. 프로덕션에서\n이것은 유용한 기능이라기보다는 오히려 골칫거리로 판명되었습니다. 헬름 3에서\n`helm install`과 함께 이름이 주어지지 않으면 헬름이 오류를 던집니다.\n\n이름이 자동으로 생성되기를 원하는 사용자는 `--generate-name` 플래그를\n사용하여 자동으로 생성할 수 있습니다.\n\n### OCI 레지스트리로 차트 밀어내기\n\n이것은 헬름 3에 도입된 실험적인(experimental) 기능입니다.\n사용하려면 환경 변수 `HELM_EXPERIMENTAL_OCI=1`을 설정합니다.\n\n높은 수준에서 차트 저장소는 차트를 저장하고 공유할 수 있는 곳입니다.\n헬름 클라이언트는 헬름 차트를 패키징하여 차트 저장소로 보냅니다.\n간단히 말해 차트 저장소는 index.yaml 파일과 일부 패키지형 차트를 저장하는\n기본 HTTP 서버입니다.\n\n차트 저장소 API가 가장 기본적인 스토리지 요구 사항을 충족하면 몇 가지 이점이 있지만\n다음과 같은 몇 가지 문제점이 나타나기 시작했습니다.\n\n- 차트 저장소는 프로덕션 환경에 필요한 대부분의 보안 구현을\n  추상화하는 데 매우 어려움을 겪고 있습니다. 인증 및 인가를\n  위한 표준 API를 갖는 것은 프로덕션 시나리오에서\n  매우 중요합니다.\n- 차트의 무결성과 원본을 표시 및 검증하는 데 사용되는 헬름의 차트 출처(provenance)\n  도구는 차트 발행 프로세스의 선택 사항입니다.\n- 멀티 테넌트 시나리오에서는 다른 테넌트에서 동일한 차트를 업로드할 수 있으므로\n  동일한 컨텐츠를 저장하는 데 드는 스토리지 비용이 두 배가 됩니다.\n  보다 스마트한 차트 저장소는 이 문제를 처리하도록 설계되었지만 정식 사양에는\n  포함되지 않습니다.\n- 검색, 메타데이터 정보, 차트 가져오기에 단일 인덱스 파일을\n  사용하면 안전한 멀티 테넌트 구현으로 설계하기가 어렵거나\n  복잡해졌습니다.\n\n도커의 분산 프로젝트(Distribution prject, 도커 레지스트리 v2라고도 함)는\n도커 레지스트리 프로젝트의 후속 작업입니다. 많은 주요 클라우드 벤더가\n분산 프로젝트를 제공하는 상품을 보유하고 있으며, 수많은 벤더가 동일한 제품을\n제공함에 따라 분산 프로젝트는 수년간의 개선, 보안 모범 사례, 실전 테스트의\n혜택을 받아 왔습니다.\n\n차트를 패키징하고 도커 레지스트리에 밀어내는 방법에 대한 자세한 내용은\n`helm help chart` 및 `helm help registry`를 참조하시기 바랍니다.\n\n자세한 내용은 [이 페이지](/topics/registries.md)를 참조하시기 바랍니다.\n\n### `helm serve` 제거\n\n`helm serve`는 개발 목적으로 머신에서 로컬 차트 저장소를\n실행했습니다. 하지만 개발 도구로서 그다지 많은 관심을 받지 못했고\n설계에도 많은 문제가 있었습니다. 결국 우리는 이것을 제거하고\n플러그인으로 분리하기로 했습니다.\n\n`helm serve`와 유사한 경험을 위해서는 [차트뮤지엄\n(ChartMuseum)](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)의\n로컬 파일 시스템 스토리지 옵션과\n[servecm 플러그인](https://github.com/jdolitsky/helm-servecm)에 대해 살펴보세요.\n\n\n### 라이브러리 차트 지원\n\n헬름 3는 \"라이브러리 차트\"라고 하는 차트의 클래스를 지원합니다. 다른 차트에서\n공유하지만 자체 릴리스 아티팩트는 생성하지 않는 차트입니다. 라이브러리 차트의\n템플릿은 `define` 요소만 선언할 수 있습니다. 전역 범위 `define`이 아닌 콘텐츠는\n무시됩니다. 이를 통해 사용자는 여러 차트에서 재사용할 수 있는 코드 조작(snippet)을\n재사용하고 공유할 수 있으므로 중복성을 방지하고\n차트 [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)를 유지할 수 있습니다.\n\n라이브러리 차트는 Chart.yaml의 dependencies 지시어에 선언되며\n다른 차트처럼 설치 및 관리됩니다.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\n이 기능이 차트 개발자에게 제공되는 유즈 케이스와\n라이브러리 차트를 사용하면서 생긴 모범 사례을 보게 되어\n매우 기쁩니다.\n\n### Chart.yaml apiVersion 격상\n\n라이브러리 차트 지원이 도입되고 requirements.yaml이 Chart.yaml로\n통합됨에 따라 헬름 2의 패키지 형식을 이해하고 있는 클라이언트는\n이러한 새로운 기능을 이해할 수 없게 되었습니다. 따라서 Chart.yaml의\napiVersion을 v1에서 v2로 격상했습니다.\n\n`helm create`는 이제 이 새로운 형식을 사용하여 차트를 생성하므로\n기본 apiVersion도 격상했습니다.\n\n헬름 차트의 두 버전을 모두 지원하려는 클라이언트는 패키지 형식을 해석하는\n방법을 이해하기 위해 Chart.yaml의 `apiVersion` 필드를 검사하는 것이 좋습니다.\n\n### XDG 베이스 디렉토리 지원\n\n[XDG 베이스 디렉토리\n사양](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)은\n파일 시스템에 설정, 데이터, 캐시된 파일을 저장할 위치를 정의하는\n이식 가능한 표준입니다.\n\n헬름 2에서 헬름은 이 모든 정보를 `~/.helm`(정확히 `helm home`이라고 함)에\n저장했으며, `$HELM_HOME` 환경 변수를 설정하여 변경하거나,\n전역 플래그 `--home` 을 사용하여 변경할 수 있습니다.\n\n헬름 3에서 헬름은 XDG 기본 디렉토리 사양에 따라 다음 환경 변수를\n고려합니다.\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\n헬름 플러그인은 `$HELM_HOME`을 스크래치패드 환경으로\n사용하려는 플러그인과의 하위 호환성을 위해\n`$XDG_DATA_HOME`의 별칭으로 `$HELM_HOME`을 여전히 전달됩니다.\n\n이러한 변화에 맞추기 위해 몇 가지 새로운 환경 변수도\n플러그인 환경에 전달됩니다.\n\n- `$HELM_PATH_CACHE` 로 캐시 경로 지정\n- `$HELM_PATH_CONFIG` 로 설정 경로 지정\n- `$HELM_PATH_DATA` 로 데이터 경로 지정\n\n헬름 3를 지원하려는 헬름 플러그인은 이 새로운 환경 변수들을\n고려해야 합니다.\n\n### CLI 명령어 이름을 변경했습니다\n\n다른 패키지 매니저의 용어와 잘 조화시키기 위해 `helm delete`를 `helm uninstall`로\n개명했습니다. `helm delete`은 여전히 `helm uninstall`의 별칭으로 유지되므로\n두 형식 중 하나를 사용할 수 있습니다.\n\n헬름 2에서는 릴리스 기록을 제거하기 위해 `--purge` 플래그를 써야\n했습니다. 이제 이 기능은 기본적으로 활성화됩니다. 예전 동작을 유지하려면\n`helm uninstall --keep-history`를 사용합시다.\n\n또한 동일한 규칙을 수용하기 위해 일부 다른 명령어들이\n개명되었습니다.\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\n이러한 명령어는 예전 동사도 별칭으로 유지하므로\n두 가지 형식에서 계속 사용할 수 있습니다.\n\n### 네임스페이스 자동 생성\n\n존재하지 않는 네임스페이스에 릴리스를 생성할 때 헬름 2가 네임스페이스를 만들었습니다.\n헬름 3는 다른 쿠버네티스 도구의 동작을 따르며 네임스페이스가 없는 경우\n오류를 반환합니다. `--create-namespace` 플래그를 명시적으로 지정하면 헬름 3가\n네임스페이스를 만듭니다.\n\n### .Chart.ApiVersion 은 없어졌나요?\n\n헬름은 머리글자를 대문자로 나타내는 일반적인 낙타 표기법(CamelCasing)을\n따릅니다. `.Capabilities.APIVersions.Has` 와 같은 모든 코드에서 해당\n표기법을 사용했습니다. 헬름 3에서는 이 패턴을 지키기 위해 `.Chart.ApiVersion`\n을 `.Chart.APIVersion` 으로 변경했습니다.\n\n## 설치\n\n### 페도라(Fedora) 등의 다른 리눅스 배포판을 위한 네이티브 헬름 패키지는 왜 없나요?\n\n헬름 프로젝트는 운영 체제 및 환경에 대한 패키지를 관리하지 않습니다.\n헬름 커뮤니티는 네이티브 패키지를 제공할 수 있으며 헬름 프로젝트에서\n알게 되면 목록에 포함될 것입니다. 이렇게 해서\n홈브루 포뮬러(HomeBrew formula)가 시작되고 포함되었습니다.\n패키지 관리에 관심이 있으시다면 감사하겠습니다.\n\n### 왜 `curl ...|bash` 스크립트를 제공하나요?\n\n저장소에 `curl ..|bash` 스크립트로 실행할 수 있는 스크립트(`scripts/get-helm-3`)가\n있습니다. 전송은 모두 HTTPS에 의해 보호되며 스크립트는 가져오는 패키지에 대해 일부\n감사를 수행합니다. 그러나 이 스크립트는 쉘 스크립트의 모든 일반적인 위험을\n가지고 있습니다.\n\n유용하기 때문에 제공하지만 사용자들이 먼저 대본을 주의 깊게\n읽어보는 것이 좋습니다. 우리가 정말 원하는 것은 더 나은\n패키지형 헬름 릴리스입니다.\n\n### 헬름 클라이언트 파일들을 기본값 말고 다른 곳에 두려면 어떻게 하나요?\n\n헬름은 파일을 보관할 때 XDG 구조를 사용합니다.\n그 위치를 재정의(override)할 수 있는 환경변수를 사용할 수 있습니다.\n\n- `$XDG_CACHE_HOME`: 캐시 파일 보관 장소를 다른 곳으로 설정\n- `$XDG_CONFIG_HOME`: 헬름 설정 파일 보관 장소를 다른 곳으로\n  설정\n- `$XDG_DATA_HOME`: 헬름 데이터 보관 장소를 다른 곳으로 설정\n\n기존 저장소가 있는 경우, `helm repo add...`를 사용하여 저장소를 다시 추가해야\n합니다.\n\n\n## 삭제\n\n### 로컬 헬름을 삭제하고 싶어요. 그 파일들은 모두 어디에 있나요?\n\n헬름은 `helm` 바이너리 파일과 함께 일부 파일을 다음 위치에 저장합니다.\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\n다음 표에서는 OS 별로 각 항목에 대한 기본 폴더를 제공합니다.\n\n| 운영 체제        | 캐시 경로                   | 설정 경로                        | 데이터 경로               |\n|------------------|-----------------------------|----------------------------------|---------------------------|\n| 리눅스           | `$HOME/.cache/helm `        | `$HOME/.config/helm `            | `$HOME/.local/share/helm` |\n| 맥OS             | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm `     |\n| 윈도우           | `%TEMP%\\helm  `             | `%APPDATA%\\helm `                | `%APPDATA%\\helm`          |\n\n## 트러블슈팅\n\n### \"Unable to get an update from the \"stable\" chart repository\"라는 경고가 표시됩니다.\n\n`helm repo list` 를 실행합니다. `storage.googleapis.com` URL을 가리키고 있는 `stable` 저장소가 표시되면 해당 저장소를 업데이트해야 합니다.\n2020년 11월 13일에 헬름 차트 저장소는 일년 간의 유예기간을 거친 후 [더 이상 지원되지 않습니다](https://github.com/helm/charts#deprecation-timeline).\n아카이브를 `https://charts.helm.sh/stable` 에서 사용할 수 있지만 더 이상 업데이트를 받을 수 없습니다.\n\n다음 명령을 실행하여 저장소를 수정할 수 있습니다.\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update\n```\n\nhttps://charts.helm.sh/incubator 에서 사용할 수 있는 아카이브가 있는 `incubator` 저장소도 마찬가지입니다.\n다음 명령을 실행하여 고칠 수 있습니다.\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update\n```\n\n### 'WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.'라는 경고가 표시됩니다.\n\n기존의 구글 헬름 차트 저장소가 새로운 헬름 차트 저장소로 대체되었습니다.\n\n다음 명령을 실행하여 이 문제를 해결합니다.\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update\n```\n\n`incubator` 에 비슷한 오류가 발생한다면 다음 명령을 실행합니다.\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update\n```\n\n### 헬름 저장소를 추가하면 'Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available'라는 오류가 표시됩니다.\n\n헬름 차트 저장소는 [1년 동안의 유예기간](https://github.com/helm/charts#deprecation-timeline)이 지나면 더 이상 지원되지 않습니다.\n해당 저장소의 아카이브는 `https://charts.helm.sh/stable` 및 `https://charts.helm.sh/incubator` 에서 사용할 수 있지만, 더 이상 업데이트되지 않습니다.\n`--use-deprecated-repos` 를 지정하지 않으면 `helm repo add` 명령어로 기존 저장소의 URL을 추가할 수 없습니다.\n\n### GKE (구글 컨테이너 엔진)에서 \"현재 열려 있는 SSH 터널이 없습니다\"라고 나와요\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\n오류 메시지의 또 다른 변형판은 다음과 같습니다.\n\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\n해당 이슈는 로컬 쿠버네티스 설정 파일에 올바른 인증서가 있어야 한다는\n것입니다.\n\nGKE에 클러스터를 생성하면 SSL 인증서 및 인증 기관을 포함한\n인증서가 제공됩니다. 이러한 파일은 `kubectl`과 `helm`이\n접근할 수 있도록 쿠버네티스 설정 파일에 저장되어야\n합니다(기본값: `~/.kube/config`).\n\n### 헬름 2에서 마이그레이션한 후, `helm list`에는 릴리스들이 일부만 보여요(또는 안 보여요).\n\n헬름 3는 이제 클러스터 네임스페이스를 사용하여 릴리스들을\n구획한다는 사실을 깜빡하신 것 같습니다.\n릴리스를 참조하는 모든 명령어는 다음 중 하나로 수행해야 합니다.\n\n* 활성 쿠버네티스 컨텍스트의 현재 네임스페이스에 의존합니다\n  (`kubectl config view --minify` 명령어로 확인).\n* `--namespace`/`-n` 플래그를 사용하여 올바른 네임스페이스를 지정합니다.\n* `helm list` 명령어에 대해서는 `--all-namespaces`/`-A` 플래그를 지정합니다.\n\n이는 릴리스를 참조하는 `helm list`, `helm uninstall` 및\n기타 모든 `helm` 명령어에 적용됩니다.\n\n\n### 맥OS에서는 `/etc/.mdns_debug` 파일에 접근합니다. 왜 그런가요?\n\n맥OS에서는 헬름이 `/etc/.mdns_debug`라는 파일에 접근하려고\n하는 것으로 알려져 있습니다. 파일이 있는 경우, 헬름은 파일이 실행되는 동안\n파일 핸들을 열어 둡니다.\n\n이 문제는 맥OS의 MDNS 라이브러리로 인해 발생합니다.\n디버깅 설정을 읽기 위해 MDNS 라이브러리를 로드하려고 시도합니다(활성화된 경우).\n파일 핸들을 열지 말아야 하며, 이 문제는 애플(Apple)에도 보고되었습니다.\n다만, 이러한 동작을 일으키는 것은 헬름이 아닌 맥OS입니다.\n\n헬름이 이 파일을 로드하지 않도록 하려면 호스트 네트워크 스택을 사용하지 않는\n정적 라이브러리로서 헬름을 컴파일하면 됩니다. 이렇게 하면 헬름의 바이너리 크기가\n커지기는 하지만, 그 파일이 열리는 것은 막을 수 있습니다.\n\n이 문제는 원래 잠재적인 보안 문제로 분류되기도 했습니다.\n그러나 이후 이 동작으로 인한 결함이나 취약점은 없는 것으로 판명되었습니다.\n\n### helm repo add가 동작한 후 실패합니다.\n\n헬름 3.3.1 및 이전 버전에서 이미 존재하는 저장소(repo)를 추가하려고 하면\n`helm repo add <reponame> <url>` 명령어를 실행해도 출력되는 내용은 없습니다.\n`--no-update` 플래그를 사용하면 저장소가 이미 등록되어 있는 경우 오류를 발생시킵니다.\n\n헬름 3.3.2 이상에서 기존 저장소를 추가하려고 하면 다음 오류가 발생합니다.\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\n이제 기본 동작은 반대가 됩니다. `--no-update`는 이제 무시되며,\n기존 저장소를 교체(덮어쓰기)하려면 `--force-update`를 사용할 수 있습니다.\n\n이는 [헬름 3.3.2 릴리스 노트](https://github.com/helm/helm/releases/tag/v3.3.2)에서\n설명된대로 보안 픽스에 따라 단절적 변경(breaking change)이 있었기 때문입니다.\n\n### 쿠버네티스 클라이언트 로깅 활성화\n\n[klog](https://pkg.go.dev/k8s.io/klog) 플래그를 사용하여 쿠버네티스 클라이언트를\n디버깅하기 위한 로그 메시지를 출력할 수 있습니다. 대부분의 경우에는 `-v` 플래그를\n사용하여 자세한 수준(verbosity level)으로 설정하는 것만으로도 충분합니다.\n\n예시:\n\n```\nhelm list -v 6\n```\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: 설치\nsidebar_position: 2\n---\n\n## 설치\n\n### Fedora나 다른 Linux 배포판에 Helm 네이티브 패키지가 없는 이유는 무엇인가요?\n\nHelm 프로젝트는 운영 체제 및 환경별 패키지를 직접 유지 관리하지 않는다. Helm 커뮤니티에서 네이티브 패키지를 제공할 수 있으며, Helm 프로젝트에 알려진 경우 목록에 추가된다. Homebrew formula가 이런 방식으로 시작되어 목록에 추가되었다. 패키지 유지 관리에 관심이 있다면 언제든지 환영한다.\n\n### 왜 `curl ...|bash` 스크립트를 제공하나요?\n\n저장소에 `curl ..|bash` 스크립트로 실행할 수 있는 스크립트(`scripts/get-helm-3`)가 있다. 모든 전송은 HTTPS로 보호되며, 스크립트는 가져온 패키지에 대해 일부 검증을 수행한다. 그러나 이 스크립트는 모든 셸 스크립트가 갖는 일반적인 위험성이 있다.\n\n유용하기 때문에 제공하지만, 사용자가 먼저 스크립트를 주의 깊게 읽어보기를 권장한다. 우리가 정말로 바라는 것은 더 나은 패키지 형태의 Helm 릴리스이다.\n\n### Helm 클라이언트 파일을 기본 위치가 아닌 다른 곳에 저장하려면 어떻게 하나요?\n\nHelm은 파일 저장에 XDG 구조를 사용한다. 다음 환경 변수를 사용하여 이 위치들을 변경할 수 있다:\n\n- `$XDG_CACHE_HOME`: 캐시 파일 저장을 위한 대체 위치를 설정한다.\n- `$XDG_CONFIG_HOME`: Helm 설정 저장을 위한 대체 위치를 설정한다.\n- `$XDG_DATA_HOME`: Helm 데이터 저장을 위한 대체 위치를 설정한다.\n\n참고: 기존 리포지토리가 있는 경우, `helm repo add...`로 다시 추가해야 한다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: 문제 해결\nsidebar_position: 4\n---\n\n## 문제 해결\n\n### \"stable\" 차트 리포지토리에서 업데이트를 가져올 수 없다는 경고가 나타나요\n\n`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`에 제공되고 있지만, 더 이상 업데이트되지 않는다.\n\n다음 명령어를 실행하여 리포지토리를 수정할 수 있다:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\n`incubator` 리포지토리도 마찬가지로 https://charts.helm.sh/incubator 에서 아카이브를 사용할 수 있다. 다음 명령어를 실행하여 수정할 수 있다:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### 'WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.' 경고가 나타나요\n\n이전 Google helm 차트 리포지토리가 새로운 Helm 차트 리포지토리로 대체되었다.\n\n다음 명령어를 실행하여 영구적으로 수정할 수 있다:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\n`incubator`에서 비슷한 오류가 발생한다면, 다음 명령어를 실행한다:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Helm 리포지토리를 추가할 때 'Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available' 오류가 발생해요\n\nHelm 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을 추가할 수 없다.\n\n### GKE(Google Container Engine)에서 \"No SSH tunnels currently open\" 오류가 발생해요\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\n다른 형태의 오류 메시지:\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\n이 문제는 로컬 Kubernetes 설정 파일에 올바른 자격 증명이 없어서 발생한다.\n\nGKE에서 클러스터를 생성하면, SSL 인증서와 인증 기관을 포함한 자격 증명이 제공된다. 이것들은 Kubernetes 설정 파일(기본값: `~/.kube/config`)에 저장되어야 `kubectl` 및 `helm`이 접근할 수 있다.\n\n### Helm 2에서 마이그레이션한 후, `helm list`에서 일부(또는 전체) 릴리스가 표시되지 않아요\n\nHelm 3에서는 릴리스 범위를 지정하기 위해 클러스터 네임스페이스를 사용한다는 사실을 놓쳤을 가능성이 높다. 이는 릴리스를 참조하는 모든 명령어에서 다음 중 하나를 수행해야 함을 의미한다:\n\n* 활성 kubernetes 컨텍스트의 현재 네임스페이스에 의존하거나(`kubectl config view --minify` 명령어로 확인 가능),\n* `--namespace`/`-n` 플래그를 사용하여 올바른 네임스페이스를 지정하거나,\n* `helm list` 명령어의 경우, `--all-namespaces`/`-A` 플래그를 지정한다.\n\n이는 `helm ls`, `helm uninstall` 및 릴리스를 참조하는 모든 `helm` 명령어에 적용된다.\n\n\n### macOS에서 `/etc/.mdns_debug` 파일에 접근하는 이유가 뭔가요?\n\nmacOS에서 Helm이 `/etc/.mdns_debug`라는 파일에 접근하려고 하는 경우가 있다. 해당 파일이 존재하면, Helm은 실행 중에 파일 핸들을 열린 상태로 유지한다.\n\n이는 macOS의 MDNS 라이브러리 때문이다. 이 라이브러리는 디버깅 설정(활성화된 경우)을 읽기 위해 해당 파일을 로드하려고 시도한다. 파일 핸들이 열린 상태로 유지되는 것은 적절하지 않으며, 이 문제는 Apple에 보고되었다. 그러나 이 동작을 일으키는 것은 Helm이 아니라 macOS이다.\n\nHelm이 이 파일을 로드하지 않도록 하려면, 호스트 네트워크 스택을 사용하지 않는 정적 라이브러리로 Helm을 컴파일할 수 있다. 이렇게 하면 Helm의 바이너리 크기가 증가하지만, 파일이 열리는 것을 방지할 수 있다.\n\n이 문제는 원래 잠재적인 보안 문제로 보고되었다. 그러나 이후 이 동작으로 인한 결함이나 취약점이 없는 것으로 확인되었다.\n\n### helm repo add가 예전에는 작동했는데 지금은 실패해요\n\nhelm 3.3.1 이전에는, `helm repo add <reponame> <url>` 명령어가 이미 존재하는 리포지토리를 추가하려고 해도 아무런 출력을 하지 않았다. `--no-update` 플래그는 리포지토리가 이미 등록된 경우 오류를 발생시켰다.\n\nhelm 3.3.2부터는, 기존 리포지토리를 추가하려고 하면 오류가 발생한다:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\n이제 기본 동작이 반대로 바뀌었다. `--no-update`는 이제 무시되며, 기존 리포지토리를 대체(덮어쓰기)하려면 `--force-update`를 사용해야 한다.\n\n이는 [Helm 3.3.2 릴리스 노트](https://github.com/helm/helm/releases/tag/v3.3.2)에 설명된 보안 수정을 위한 호환성 변경 때문이다.\n\n### Kubernetes 클라이언트 로깅 활성화\n\nKubernetes 클라이언트 디버깅을 위한 로그 메시지 출력은 [klog](https://pkg.go.dev/k8s.io/klog) 플래그를 사용하여 활성화할 수 있다. 대부분의 경우 `-v` 플래그를 사용하여 상세 수준(verbosity level)을 설정하면 충분하다.\n\n예시:\n\n```\nhelm list -v 6\n```\n\n### Tiller 설치가 작동하지 않고 접근이 거부돼요\n\nHelm 릴리스는 이전에 <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 이미지를 제공하고 있다.\n\n이전에 사용하던 스토리지 버킷에서 이전 버전의 Helm을 다운로드하려고 하면 해당 파일이 누락된 것을 발견할 수 있다:\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\n[레거시 Tiller 이미지 위치](https://gcr.io/kubernetes-helm/tiller)에서 2021년 8월부터 이미지 제거가 시작되었다. 이러한 이미지는 [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) 위치에서 사용할 수 있다. 예를 들어, v2.17.0 버전을 다운로드하려면 다음을 대체한다:\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\n다음으로 변경:\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nHelm v2.17.0으로 초기화하려면:\n\n`helm init —upgrade`\n\n또는 다른 버전이 필요한 경우, --tiller-image 플래그를 사용하여 기본 위치를 재정의하고 특정 Helm v2 버전을 설치할 수 있다:\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**참고:** 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)할 계획을 세우기 바란다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: 삭제\nsidebar_position: 3\n---\n\n## 삭제\n\n### 로컬 헬름을 삭제하고 싶어요. 그 파일들은 모두 어디에 있나요?\n\n`helm` 바이너리 외에도 헬름은 일부 파일을 다음 위치에 저장합니다:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\n다음 표는 운영 체제별 각 항목의 기본 폴더를 보여줍니다:\n\n| 운영 체제 | 캐시 경로                   | 설정 경로                        | 데이터 경로               |\n|-----------|-----------------------------|---------------------------------|---------------------------|\n| Linux     | `$HOME/.cache/helm `        | `$HOME/.config/helm `            | `$HOME/.local/share/helm` |\n| macOS     | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm `     |\n| Windows   | `%TEMP%\\helm  `             | `%APPDATA%\\helm `                | `%APPDATA%\\helm`          |\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/glossary/index.mdx",
    "content": "---\ntitle: 용어집\ndescription: 헬름 아키텍처의 컴포넌트들을 기술하기 위해 사용된 용어.\nsidebar_position: 9\n---\n\r\n# 용어집\r\n\r\n## 차트\r\n\r\n쿠버네티스 클러스터 내에 리소스 세트를 설치하는 데 필요한 정보를 담고 있는 헬름 패키지\r\n\r\n차트는 템플릿을 비롯하여 `Chart.yaml` 파일, 기본 값(`values.yaml`), 의존성(dependencies)을 포함한다.\r\n\r\n차트는 잘 정의된 디렉토리 구조 속에서 개발되며, _chart archive_라고 하는 아카이브 형식으로 패키징된다.\r\n\r\n## 차트 아카이브\r\n\r\n_chart archive_는 tar와 gzip으로 (필요시 서명을 추가한) 묶인 차트이다.\r\n\r\n## 차트 의존성 (서브차트)\r\n\r\n차트는 다른 차트에 의존(depend)할 수 있다. 의존성을 일으키는 2가지 방법은 다음과 같다.\r\n\r\n- 약한 의존성: 클러스터에 다른 차트가 없으면 차트가 동작하지 않을 수 있다. \r\n  헬름은 이런 경우에 필요한 도구를 제공하지 않으며, 별도로 의존성을 관리해야 한다.\r\n- 강한 의존성: A chart may contain (inside of its `charts/` directory)\r\n  another chart upon which it depends. In this case, installing the chart will\r\n  install all of its dependencies. In this case, a chart and its dependencies\r\n  are managed as a collection.\r\n\r\nWhen a chart is packaged (via `helm package`) all of its hard dependencies are\r\nbundled with it.\r\n\r\n## Chart Version\r\n\r\nCharts are versioned according to the [SemVer 2 spec](https://semver.org). A\r\nversion number is required on every chart.\r\n\r\n## Chart.yaml\r\n\r\nInformation about a chart is stored in a special file called `Chart.yaml`. Every\r\nchart must have this file.\r\n\r\n## Helm (and helm)\r\n\r\nHelm is the package manager for Kubernetes. As an operating system package\r\nmanager makes it easy to install tools on an OS, Helm makes it easy to install\r\napplications and resources into Kubernetes clusters.\r\n\r\nWhile _Helm_ is the name of the project, the command line client is also named\r\n`helm`. By convention, when speaking of the project, _Helm_ is capitalized. When\r\nspeaking of the client, _helm_ is in lowercase.\r\n\r\n## Helm Configuration Files (XDG)\r\n\r\nHelm stores its configuration files in XDG directories. These directories are\r\ncreated the first time `helm` is run.\r\n\r\n## Kube Config (KUBECONFIG)\r\n\r\nThe Helm client learns about Kubernetes clusters by using files in the _Kube\r\nconfig_ file format. By default, Helm attempts to find this file in the place\r\nwhere `kubectl` creates it (`$HOME/.kube/config`).\r\n\r\n## Lint (Linting)\r\n\r\nTo _lint_ a chart is to validate that it follows the conventions and\r\nrequirements of the Helm chart standard. Helm provides tools to do this, notably\r\nthe `helm lint` command.\r\n\r\n## Provenance (Provenance file)\r\n\r\nHelm charts may be accompanied by a _provenance file_ which provides information\r\nabout where the chart came from and what it contains.\r\n\r\nProvenance files are one part of the Helm security story. A provenance contains\r\na cryptographic hash of the chart archive file, the Chart.yaml data, and a\r\nsignature block (an OpenPGP \"clearsign\" block). When coupled with a keychain,\r\nthis provides chart users with the ability to:\r\n\r\n- Validate that a chart was signed by a trusted party\r\n- Validate that the chart file has not been tampered with\r\n- Validate the contents of a chart metadata (`Chart.yaml`)\r\n- Quickly match a chart to its provenance data\r\n\r\nProvenance files have the `.prov` extension, and can be served from a chart\r\nrepository server or any other HTTP server.\r\n\r\n## Release\r\n\r\nWhen a chart is installed, the Helm library creates a _release_ to track that\r\ninstallation.\r\n\r\nA single chart may be installed many times into the same cluster, and create\r\nmany different releases. For example, one can install three PostgreSQL databases\r\nby running `helm install` three times with a different release name.\r\n\r\n## Release Number (Release Version)\r\n\r\nA single release can be updated multiple times. A sequential counter is used to\r\ntrack releases as they change. After a first `helm install`, a release will have\r\n_release number_ 1. Each time a release is upgraded or rolled back, the release\r\nnumber will be incremented.\r\n\r\n## Rollback\r\n\r\nA release can be upgraded to a newer chart or configuration. But since release\r\nhistory is stored, a release can also be _rolled back_ to a previous release\r\nnumber. This is done with the `helm rollback` command.\r\n\r\nImportantly, a rolled back release will receive a new release number.\r\n\r\n| Operation  | Release Number                                       |\r\n|------------|------------------------------------------------------|\r\n| install    | release 1                                            |\r\n| upgrade    | release 2                                            |\r\n| upgrade    | release 3                                            |\r\n| rollback 1 | release 4 (but running the same config as release 1) |\r\n\r\nThe above table illustrates how release numbers increment across install,\r\nupgrade, and rollback.\r\n\r\n## Helm Library (or SDK)\r\n\r\nThe Helm Library (or SDK) refers to the Go code that interacts directly with the\r\nKubernetes API server to install, upgrade, query, and remove Kubernetes\r\nresources. It can be imported into a project to use Helm as a client library\r\ninstead of a CLI.\r\n\r\n## Repository (Repo, Chart Repository)\r\n\r\nHelm charts may be stored on dedicated HTTP servers called _chart repositories_\r\n(_repositories_, or just _repos_).\r\n\r\nA chart repository server is a simple HTTP server that can serve an `index.yaml`\r\nfile that describes a batch of charts, and provides information on where each\r\nchart can be downloaded from. (Many chart repositories serve the charts as well\r\nas the `index.yaml` file.)\r\n\r\nA Helm client can point to zero or more chart repositories. By default, Helm\r\nclients are not configured with any chart repositories. Chart repositories can\r\nbe added at any time using the `helm repo add` command.\r\n\r\n## Values (Values Files, values.yaml)\r\n\r\nValues provide a way to override template defaults with your own information.\r\n\r\nHelm Charts are \"parameterized\", which means the chart developer may expose\r\nconfiguration that can be overridden at installation time. For example, a chart\r\nmay expose a `username` field that allows setting a user name for a service.\r\n\r\nThese exposed variables are called _values_ in Helm parlance.\r\n\r\nValues can be set during `helm install` and `helm upgrade` operations, either by\r\npassing them in directly, or by using a `values.yaml` file.\r\n\r\nimport DocCardList from '@theme/DocCardList';\r\n\r\n<DocCardList />"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/_category_.json",
    "content": "{\n  \"link\": { \"type\": \"doc\", \"id\": \"helm-category\" }\n}\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\n쿠버네티스를 위한 Helm 패키지 매니저\n\n### 개요\n\n쿠버네티스 패키지 매니저\n\n일반적으로 사용되는 Helm 작업:\n\n- helm search:    차트를 검색\n- helm pull:      차트를 로컬 디렉토리에 다운로드하여 확인\n- helm install:   쿠버네티스에 차트 업로드\n- helm list:      차트 릴리스 목록 표시\n\n환경 변수:\n\n| Name                               | Description                                                                                                |\n|------------------------------------|------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | 캐시된 파일을 저장할 대체 위치를 지정                                                                      |\n| $HELM_CONFIG_HOME                  | Helm 설정을 저장할 대체 위치를 지정                                                                        |\n| $HELM_DATA_HOME                    | Helm 데이터를 저장할 대체 위치를 지정                                                                      |\n| $HELM_DEBUG                        | Helm이 디버그 모드에서 실행 중인지 여부 표시                                                               |\n| $HELM_DRIVER                       | 백엔드 스토리지 드라이버 설정. 값: configmap, secret, memory, sql                                          |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | SQL 스토리지 드라이버가 사용해야 하는 연결 문자열 지정                                                     |\n| $HELM_MAX_HISTORY                  | Helm 릴리스 내역의 최대 수 설정                                                                            |\n| $HELM_NAMESPACE                    | Helm 작업에 사용되는 네임스페이스 지정                                                                     |\n| $HELM_NO_PLUGINS                   | 플러그인 비활성화. 비활성화하려면 HELM_NO_PLUGINS=1로 지정                                                 |\n| $HELM_PLUGINS                      | 플러그인 디렉토리에 대한 경로 설정                                                                         |\n| $HELM_REGISTRY_CONFIG              | 레지스트리 구성 파일의 경로를 설정                                                                         |\n| $HELM_REPOSITORY_CACHE             | 리포지토리 캐시 디렉토리에 대한 경로 설정                                                                  |\n| $HELM_REPOSITORY_CONFIG            | 리포지토리 파일의 경로 설정                                                                                |\n| $KUBECONFIG                        | 대체 Kubernetes 설정 파일 지정 (기본값 \"~/.kube/config\")                                                   |\n| $HELM_KUBEAPISERVER                | 인증을 위한 Kubernetes API 서버의 엔드포인트 설정                                                          |\n| $HELM_KUBECAFILE                   | Kubernetes 인증 기관 파일 설정                                                                             |\n| $HELM_KUBEASGROUPS                 | 쉼표로 구분된 목록을 사용하여, 작업에 가장(impersonation)할 그룹 지정                                      |\n| $HELM_KUBEASUSER                   | 작업에 가장(impersonation)할 사용자 이름 설정                                                              |\n| $HELM_KUBECONTEXT                  | kubeconfig 컨텍스트의 이름 설정                                                                            |\n| $HELM_KUBETOKEN                    | 인증에 사용되는 Bearer KubeToken 설정                                                                      |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | Kubernetes API 서버의 인증서 유효성 검사를 건너뛸지 여부 표시 (안전하지 않음)                              |\n| $HELM_KUBETLS_SERVER_NAME          | Kubernetes API 서버 인증서를 검증하는 데 사용할 서버 이름 설정                                             |\n| $HELM_BURST_LIMIT                  | 서버에 CRD가 많은 경우의 기본 버스트 제한 설정 (기본값 100, 비활성화하려면 -1)                             |\n| $HELM_QPS                          | 높은 버스트 값 옵션을 초과하는 호출이 많은 경우의 초당 쿼리 수(QPS) 설정                                   |\n\nHelm은 다음 설정 순서를 기반으로 캐시, 설정 정보, 데이터를 저장한다:\n\n- HELM_*_HOME 환경변수가 설정된 경우 이 변수를 사용함\n- 그렇지 않으면, XDG 기반 디렉토리 사양을 지원하는 시스템에서 XDG 변수를 사용함\n- 다른 위치를 설정하지 않은 경우 운영 체제의 기본 위치를 사용함\n\n기본적으로 기본 디렉토리는 운영체제에 따라 다르며, 기본값은 아래와 같다:\n\n| 운영체제 | 캐시 경로                   | 설정 경로                          | 데이터 경로               |\n|----------|---------------------------|----------------------------------|-------------------------|\n| Linux    | $HOME/.cache/helm         | $HOME/.config/helm               | $HOME/.local/share/helm |\n| macOS    | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm   | $HOME/Library/helm      |\n| Windows  | %TEMP%\\helm               | %APPDATA%\\helm                   | %APPDATA%\\helm          |\n\n\n### 옵션\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세한(verbose) 출력 활성화\n  -h, --help                            helm 명령어에 대한 도움말\n      --kube-apiserver string           Kubernetes API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 가장할 그룹. 이 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 가장할 사용자명\n      --kube-ca-file string             Kubernetes API 서버 연결에 사용할 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, Kubernetes API 서버의 인증서 유효성을 검사하지 않음. 이 옵션을 사용하면 HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     Kubernetes API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 Bearer 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 범위\n      --qps float32                     Kubernetes API와 통신 시 사용할 초당 쿼리 수(버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm completion](/helm/helm_completion.md)\t - 지정된 셸에 대한 자동 완성 스크립트 생성\n* [helm create](/helm/helm_create.md)\t - 주어진 이름으로 새 차트 생성\n* [helm dependency](/helm/helm_dependency.md)\t - 차트의 종속성 관리\n* [helm env](/helm/helm_env.md)\t - Helm 클라이언트 환경 정보\n* [helm get](/helm/helm_get.md)\t - 명명된 릴리스의 확장 정보 다운로드\n* [helm history](/helm/helm_history.md)\t - 릴리스 기록 가져오기\n* [helm install](/helm/helm_install.md)\t - 차트 설치\n* [helm lint](/helm/helm_lint.md)\t - 차트에서 발생 가능한 이슈 검사\n* [helm list](/helm/helm_list.md)\t - 릴리스 목록\n* [helm package](/helm/helm_package.md)\t - 차트 디렉토리를 차트 아카이브로 패키징\n* [helm plugin](/helm/helm_plugin.md)\t - Helm 플러그인 설치, 조회, 제거\n* [helm pull](/helm/helm_pull.md)\t - 리포지토리에서 차트를 다운로드하고 (선택적으로) 로컬 디렉토리에 압축 해제\n* [helm push](/helm/helm_push.md)\t - 차트를 원격에 푸시\n* [helm registry](/helm/helm_registry.md)\t - 레지스트리에 로그인 또는 로그아웃\n* [helm repo](/helm/helm_repo.md)\t - 차트 리포지토리의 추가, 조회, 제거, 업데이트 및 인덱스 생성\n* [helm rollback](/helm/helm_rollback.md)\t - 릴리스를 이전 리비전으로 롤백\n* [helm search](/helm/helm_search.md)\t - 차트에서 키워드 검색\n* [helm show](/helm/helm_show.md)\t - 차트 정보 표시\n* [helm status](/helm/helm_status.md)\t - 명명된 릴리스의 상태 표시\n* [helm template](/helm/helm_template.md)\t - 로컬에서 템플릿 렌더링\n* [helm test](/helm/helm_test.md)\t - 릴리스 테스트 수행\n* [helm uninstall](/helm/helm_uninstall.md)\t - 릴리스 제거\n* [helm upgrade](/helm/helm_upgrade.md)\t - 릴리스 업그레이드\n* [helm verify](/helm/helm_verify.md)\t - 지정된 경로의 차트가 서명되었고 유효한지 검증\n* [helm version](/helm/helm_version.md)\t - 클라이언트 버전 정보 표시\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\n지정된 셸에 대한 자동 완성 스크립트 생성\n\n### 개요\n\n\n지정된 셸의 Helm에 대한 자동 완성 스크립트를 생성한다.\n\n\n### 옵션\n\n```\n  -h, --help   completion에 대한 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           Kubernetes API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다.\n      --kube-as-user string             작업에 대해 가장할 사용자 이름\n      --kube-ca-file string             Kubernetes API 서버 연결에 사용할 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다.\n      --kube-tls-server-name string     Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다.\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](/helm/helm.md)\t - Kubernetes용 Helm 패키지 관리자\n* [helm completion bash](/helm/helm_completion_bash.md)\t - bash에 대한 자동 완성 스크립트 생성\n* [helm completion fish](/helm/helm_completion_fish.md)\t - fish에 대한 자동 완성 스크립트 생성\n* [helm completion powershell](/helm/helm_completion_powershell.md)\t - powershell에 대한 자동 완성 스크립트 생성\n* [helm completion zsh](/helm/helm_completion_zsh.md)\t - zsh에 대한 자동 완성 스크립트 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\nbash에 대한 자동 완성 스크립트 생성\n\n### 개요\n\n\nbash 셸의 Helm에 대한 자동 완성 스크립트를 생성한다.\n\n현재 셸 세션에서 완성 기능을 로드하려면:\n\n    source <(helm completion bash)\n\n새로운 세션마다 완성 기능을 로드하려면 다음 작업을 한 번 실행한다:\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n\n```\nhelm completion bash [flags]\n```\n\n### 옵션\n\n```\n  -h, --help              bash에 대한 도움말\n      --no-descriptions   완성 설명 비활성화\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           Kubernetes API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다.\n      --kube-as-user string             작업에 대해 가장할 사용자 이름\n      --kube-ca-file string             Kubernetes API 서버 연결에 사용할 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다.\n      --kube-tls-server-name string     Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다.\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm completion](/helm/helm_completion.md)\t - 지정된 셸에 대한 자동 완성 스크립트 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\nfish에 대한 자동 완성 스크립트 생성\n\n### 개요\n\n\nfish 셸의 Helm에 대한 자동 완성 스크립트를 생성한다.\n\n현재 셸 세션에서 완성 기능을 로드하려면:\n\n    helm completion fish | source\n\n새로운 세션마다 완성 기능을 로드하려면 다음 작업을 한 번 실행한다:\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\n이 설정을 적용하려면 새 셸을 시작해야 한다.\n\n\n```\nhelm completion fish [flags]\n```\n\n### 옵션\n\n```\n  -h, --help              fish에 대한 도움말\n      --no-descriptions   완성 설명 비활성화\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           Kubernetes API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다.\n      --kube-as-user string             작업에 대해 가장할 사용자 이름\n      --kube-ca-file string             Kubernetes API 서버 연결에 사용할 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다.\n      --kube-tls-server-name string     Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다.\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm completion](/helm/helm_completion.md)\t - 지정된 셸에 대한 자동 완성 스크립트 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\npowershell에 대한 자동 완성 스크립트 생성\n\n### 개요\n\n\npowershell 셸의 Helm에 대한 자동 완성 스크립트를 생성한다.\n\n현재 셸 세션에서 완성 기능을 로드하려면:\n\n    PS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\n새로운 세션마다 완성 기능을 로드하려면, 위 명령어의 출력을 powershell 프로필에 추가한다.\n\n\n```\nhelm completion powershell [flags]\n```\n\n### 옵션\n\n```\n  -h, --help              powershell에 대한 도움말\n      --no-descriptions   완성 설명 비활성화\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           Kubernetes API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다.\n      --kube-as-user string             작업에 대해 가장할 사용자 이름\n      --kube-ca-file string             Kubernetes API 서버 연결에 사용할 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다.\n      --kube-tls-server-name string     Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다.\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm completion](/helm/helm_completion.md)\t - 지정된 셸에 대한 자동 완성 스크립트 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\nzsh에 대한 자동 완성 스크립트 생성\n\n### 개요\n\n\nzsh 셸의 Helm에 대한 자동 완성 스크립트를 생성한다.\n\n현재 셸 세션에서 완성 기능을 로드하려면:\n\n    source <(helm completion zsh)\n\n새로운 세션마다 완성 기능을 로드하려면 다음 작업을 한 번 실행한다:\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### 옵션\n\n```\n  -h, --help              zsh에 대한 도움말\n      --no-descriptions   완성 설명 비활성화\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           Kubernetes API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다.\n      --kube-as-user string             작업에 대해 가장할 사용자 이름\n      --kube-ca-file string             Kubernetes API 서버 연결에 사용할 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다.\n      --kube-tls-server-name string     Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다.\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm completion](/helm/helm_completion.md)\t - 지정된 셸에 대한 자동 완성 스크립트 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n주어진 이름으로 새로운 차트를 생성한다.\n\n### 개요\n\n\n이 명령은 차트에 사용되는 공통 파일 및 디렉토리와 함께\n차트 디렉토리를 만든다.\n\n예를 들어, 'helm create foo'는 다음과 같은 디렉토리\n구조를 생성한다:\n\n    foo/\n    ├── .helmignore   # Helm 차트를 패키징할 때 무시할 패턴 포함\n    ├── Chart.yaml    # 차트에 대한 정보\n    ├── values.yaml   # 템플릿의 기본값\n    ├── charts/       # 이 차트가 의존하는 차트\n    └── templates/    # 템플릿 파일\n        └── tests/    # 테스트 파일\n\n'helm create'는 인수로 경로를 받는다. 지정된 경로에 디렉토리가\n존재하지 않으면 Helm은 디렉토리를 생성하려고 시도한다.\n지정된 대상이 있고 해당 디렉토리에 파일이 있으면 충돌하는 파일을\n덮어 쓰지만 다른 파일은 그대로 둔다.\n\n\n```\nhelm create NAME [flags]\n```\n\n### 옵션\n\n```\n  -h, --help             create에 대한 도움말\n  -p, --starter string   Helm 스타터 스캐폴드의 이름 또는 절대 경로\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           Kubernetes API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다.\n      --kube-as-user string             작업에 대해 가장할 사용자 이름\n      --kube-ca-file string             Kubernetes API 서버 연결에 사용할 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다.\n      --kube-tls-server-name string     Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다.\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](/helm/helm.md)\t - Kubernetes용 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n차트의 종속성을 관리\n\n### 개요\n\n\n차트의 종속성을 관리한다.\n\n헬름 차트는 종속성을 'charts/' 에 저장한다. 차트 개발자의 경우\n모든 종속성을 선언하는 'Chart.yaml' 에서 종속성을 관리하는 것이\n더 쉬운 경우가 많다.\n\n종속성 명령은 해당 파일에서 작동하므로 원하는 종속성과 \n'charts/' 디렉토리에 저장된 실제 종속성을 쉽게 \n동기화할 수 있다.\n\n예를 들어 이 Chart.yaml 은 두 가지 종속성을 선언한다.\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\n'name' 은 차트의 이름이어야 한다. 여기서 해당 이름은 해당 차트의 \n'Chart.yaml' 파일에 있는 이름과 일치해야 한다.\n\n'version' 필드에는 의미론적 버전 또는 버전 범위가 포함되어야 한다.\n\n'repository' URL은 차트 리포지토리를 가리켜야한다. 헬름은 URL에\n'/index.yaml' 을 추가하여 차트 리포지토리의 인덱스를 검색할 수 있어야 한다고 예상한다.\n참고: 'repository' 는 별칭이 될 수도 있다. 별칭은\n'alias:' 나 '@'로 시작해야 한다.\n\n2.2.0 부터는 저장소는 로컬에 저장된 종속성 차트의 디렉토리 경로로 정의할 \n수 있다. 경로는 \"file://\" 접두사로 시작해야 한다.\n예를 들면,\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\n종속성 차트가 로컬로 검색되는 경우 \"helm add repo\" 를 통해 \n저장소를 헬름에 추가할 필요가 없다. 이 경우 버전 일치 \n또한 지원된다.\n\n\n### 옵션\n\n```\n  -h, --help   helm dependency 명령어의 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                       장황한(verbose) 출력 활성화\n      --kube-apiserver string       쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray   작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string         작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string         사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 접속할 때 사용한 호스트명이 사용된다\n      --kube-token string           인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string           kubeconfig 파일 경로\n  -n, --namespace string            이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string     캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string    저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm](/helm/helm.md)\t - 쿠버네티스에 대한 헬름 패키지 매니저.\n* [helm dependency build](/helm/helm_dependency_build.md)\t - Chart.lock 파일을 기반으로 charts/ 디렉토리를 다시 빌드\n* [helm dependency list](/helm/helm_dependency_list.md)\t - 주어진 차트에 대한 종속성 나열\n* [helm dependency update](/helm/helm_dependency_update.md)\t - Chart.yaml 의 내용에 따라 charts/ 업데이트\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\nChart.lock 파일을 기반으로 charts/ 디렉토리를 다시 빌드\n\n### 개요\n\n\nChart.lock 파일에서 charts/ 디렉토리를 빌드한다.\n\n빌드는 잠금 파일에 지정된 상태로 차트의 종속성을 재구성하는데\n사용된다. 이것은 'helm dependency update'처럼 \n종속성을 다시 협상하지 않는다.\n\n잠금 파일이 없으면 'helm dependency build'는 \n'helm dependency update'의 동작을 미러링한다.\n\n\n```\nhelm dependency build CHART [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string             이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서 확인\n      --cert-file string           이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n  -h, --help                       build 명령어에 대한 도움말\n      --insecure-skip-tls-verify   차트 다운로드에 대한 TLS 인증서 검사 건너뛰기\n      --key-file string            이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string             공개키를 포함하는 키링 (기본값 \"~/.gnupg/pubring.gpg\")\n      --password string            요청한 차트가 있는 차트 저장소 비밀번호\n      --plain-http                 차트 다운로드에 비보안 HTTP 연결 사용\n      --skip-refresh               로컬 저장소 캐시를 새로 고치지 않음\n      --username string            요청한 차트가 있는 차트 저장소 사용자명\n      --verify                     서명과 비교하여 패키지를 확인\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는데 사용된 호스트명이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용하는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm dependency](/helm/helm_dependency.md)\t - 차트의 종속성을 관리\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n주어진 차트에 대한 종속성을 나열\n\n### 개요\n\n\n차트에 선언된 모든 종속성을 나열한다.\n\n이 명령은 차트 아카이브 및 차트 디렉토리를 입력으로 사용할 수 있다.\n차트의 내용은 변경되지 않는다.\n\n차트를 로드할 수 없는 경우 오류가 발생한다.\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### 옵션\n\n```\n  -h, --help                 list 명령어에 대한 도움말\n      --max-col-width uint   출력 테이블의 최대 열 너비 (기본값 80)\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않는다. HTTPS 연결이 안전하지 않게 된다.\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트 이름이 사용된다.\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm dependency](/helm/helm_dependency.md)\t - 차트의 종속성을 관리\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\nChart.yaml 의 내용에 따라 charts/ 업데이트\n\n### 개요\n\n\nChart.yaml 을 미러링하도록 온-디스크 종속성을 업데이트한다.\n\n이 명령은 'Chart.yaml' 에 표현된 필수 차트가 'charts/' 에\n있고 허용 가능한 버전인지를 확인한다. 종속성을 충족하는 최신 차트를\n풀다운(pull down)하고 이전 종속성을 정리한다.\n\n업데이트가 성공하면 종속성을 정확한 버전으로 다시\n빌드하는데 사용할 수 있는 잠금파일이 생성된다.\n\n종속성은 'Chart.yaml' 에 표시할 필요가 없다. 따라서 업데이트 명령은\n차트가 (a)Chart.yaml 파일에 있지만, (b)잘못된 버전이 아니면\n차트를 제거하지 않는다.\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string             이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서 확인\n      --cert-file string           이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n  -h, --help                       helm dependency update 명령어에 대한 도움말\n      --insecure-skip-tls-verify   차트 다운로드에 대한 TLS 인증서 검사 건너뛰기\n      --key-file string            이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string             공개키를 포함하는 키링 (기본값 \"~/.gnupg/pubring.gpg\")\n      --password string            요청한 차트가 있는 차트 저장소 비밀번호\n      --plain-http                 차트 다운로드에 비보안 HTTP 연결 사용\n      --skip-refresh               로컬 저장소 캐시를 새로 고치지 않음\n      --username string            요청한 차트가 있는 차트 저장소 사용자명\n      --verify                     서명과 비교하여 패키지를 확인\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는데 사용된 호스트명이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용하는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm dependency](/helm/helm_dependency.md)\t - 차트의 종속성을 관리\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\nHelm 클라이언트 환경 정보\n\n### 개요\n\n\nEnv 는 Helm에서 사용 중인 모든 환경 정보를 출력한다.\n\n\n```\nhelm env [flags]\n```\n\n### 옵션\n\n```\n  -h, --help   env 에 대한 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스에 대한 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\n명명된 릴리스의 확장 정보 다운로드\n\n### 개요\n\n\n이 명령어는 다음을 포함하여 릴리스에 대한 확장 정보를 가져오는 데 사용할 수 있는\n여러 하위 명령어로 구성된다.\n\n- 릴리스 생성에 사용된 값\n- 생성된 매니페스트 파일\n- 릴리스 차트에서 제공하는 노트\n- 릴리스와 관련된 훅(hooks)\n- 릴리스의 메타데이터\n\n\n### 옵션\n\n```\n  -h, --help   get 에 대한 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스에 대한 Helm 패키지 매니저\n* [helm get all](./helm_get_all.md)\t - 명명된 릴리스에 대한 모든 정보 다운로드\n* [helm get hooks](./helm_get_hooks.md)\t - 명명된 릴리스에 대한 모든 훅 다운로드\n* [helm get manifest](./helm_get_manifest.md)\t - 명명된 릴리스에 대한 매니페스트 다운로드\n* [helm get metadata](./helm_get_metadata.md)\t - 주어진 릴리스의 메타데이터를 가져온다\n* [helm get notes](./helm_get_notes.md)\t - 명명된 릴리스에 대한 노트 다운로드\n* [helm get values](./helm_get_values.md)\t - 명명된 릴리스에 대한 값 파일 다운로드\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\n명명된 릴리스에 대한 모든 정보 다운로드\n\n### 개요\n\n이 명령어는 지정한 릴리스에서 노트, 훅, 제공된 값 및 생성된\n매니페스트 파일에 대한 정보를 사람이 읽을 수 있는 형식으로 출력한다.\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### 옵션\n\n```\n  -h, --help              all 에 대한 도움말\n      --revision int      해당 리비전의 릴리스 정보 가져오기\n      --template string   출력 형식 지정을 위한 go 템플릿. 예: {{.Release.Name}}\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm get](./helm_get.md)\t - 명명된 릴리스의 확장 정보 다운로드\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\n명명된 릴리스에 대한 모든 훅 다운로드\n\n### 개요\n\n\n이 명령은 주어진 릴리스에 대한 훅을 다운로드한다.\n\n훅은 YAML 형식이며 YAML '---\\n' 구분자로 구분된다.\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### 옵션\n\n```\n  -h, --help           hooks 에 대한 도움말\n      --revision int   지정한 리비전의 릴리스 가져오기\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm get](./helm_get.md)\t - 명명된 릴리스의 확장 정보 다운로드\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\n명명된 릴리스에 대한 매니페스트 다운로드\n\n### 개요\n\n\n이 명령은 주어진 릴리스에 대해 생성된 매니페스트를 가져온다.\n\n매니페스트는 해당 릴리스의 차트에서 생성된 Kubernetes 리소스를 YAML로 인코딩하여 표현한 것이다.\n차트가 다른 차트에 의존하는 경우, 해당 리소스도 매니페스트에 포함된다.\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### 옵션\n\n```\n  -h, --help           manifest 에 대한 도움말\n      --revision int   지정한 리비전의 릴리스 가져오기\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm get](./helm_get.md)\t - 명명된 릴리스의 확장 정보 다운로드\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\n주어진 릴리스의 메타데이터를 가져온다.\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### 옵션\n\n```\n  -h, --help            metadata 에 대한 도움말\n  -o, --output format   지정한 형식으로 출력 표시. 허용되는 값: table, json, yaml (기본값 table)\n      --revision int    릴리스 리비전 지정\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm get](./helm_get.md)\t - 명명된 릴리스의 확장 정보 다운로드\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\n명명된 릴리스에 대한 노트 다운로드\n\n### 개요\n\n\n이 명령어는 명명된 릴리스의 차트에서 제공하는 노트를 보여준다.\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### 옵션\n\n```\n  -h, --help           notes 에 대한 도움말\n      --revision int   리비전으로 명명된 릴리스 가져오기\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm get](./helm_get.md)\t - 명명된 릴리스의 확장 정보 다운로드\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\n명명된 릴리스에 대한 값 파일 다운로드\n\n### 개요\n\n\n이 명령어는 주어진 릴리스에 대한 값 파일을 다운로드한다.\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### 옵션\n\n```\n  -a, --all             모든 (계산된) 값 덤프\n  -h, --help            values 에 대한 도움말\n  -o, --output format   지정한 형식으로 출력 표시. 허용되는 값: table, json, yaml (기본값 table)\n      --revision int    리비전으로 명명된 릴리스 가져오기\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm get](./helm_get.md)\t - 명명된 릴리스의 확장 정보 다운로드\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n릴리스 히스토리를 가져온다.\n\n### 개요\n\nHistory는 주어진 릴리스에 대한 리비전 기록을 출력한다.\n\n기본적으로 최대 256개의 리비전이 반환된다. '--max' 옵션으로\n반환되는 리비전 목록의 최대 길이를 지정할 수 있다.\n\n릴리스 기록은 형식이 지정된 테이블의 형태로 출력된다. 예:\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### 옵션\n\n```\n  -h, --help            history 명령어에 대한 도움말\n      --max int         기록에 포함할 최대 리비전 수 (기본값 256)\n  -o, --output format   지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table)\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않은 경우, 서버에 연결하는 데 사용된 호스트 이름이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     버스트를 제외한 쿠버네티스 API와의 통신에 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스에 대한 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n차트를 설치한다.\n\n### 개요\n\n\n이 명령은 차트 아카이브를 설치한다.\n\ninstall 인수는 차트 참조, 패키지된 차트 경로,\n압축 해제된 차트 디렉토리 경로 또는 URL이어야 한다.\n\n차트의 값을 재정의하려면 '--values' 플래그를 사용하여 파일을 전달하거나\n'--set' 플래그를 사용하여 명령줄에서 구성을 전달한다. 문자열 값을 강제하려면\n'--set-string'을 사용한다. 값 자체가 명령줄에 사용하기엔 너무 길거나\n동적으로 생성되는 경우 '--set-file'을 사용하여 파일에서 개별 값을 설정할 수 있다.\n'--set-json'을 사용하여 명령줄에서 JSON 값(스칼라/객체/배열)을 설정할 수도 있다.\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\n또는\n\n    $ helm install --set name=prod myredis ./redis\n\n또는\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\n또는\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\n또는\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\n'--values'/'-f' 플래그를 여러 번 지정할 수 있다. 지정된 마지막(가장 오른쪽) 파일에\n우선순위가 부여된다. 예를 들어 myvalues.yaml과 override.yaml에 'Test'라는 키가\n포함된 경우 override.yaml에 설정된 값이 우선한다:\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\n'--set' 플래그를 여러 번 지정할 수 있다. 지정된 마지막(가장 오른쪽) 세트에\n우선순위가 부여된다. 예를 들어 'foo'라는 키에 대해 'bar'와 'newbar' 값이 모두\n설정된 경우 'newbar' 값이 우선한다:\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\n마찬가지로, 다음 예제에서 'foo'는 '[\"four\"]'로 설정된다:\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\n그리고 다음 예제에서 'foo'는 '{\"key1\":\"value1\",\"key2\":\"bar\"}'로 설정된다:\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\n차트를 설치하지 않고 릴리스의 생성된 매니페스트를 확인하려면\n--debug와 --dry-run 플래그를 함께 사용할 수 있다.\n\n--dry-run 플래그는 민감한 값을 포함할 수 있는 Secret을 포함하여\n생성된 모든 차트 매니페스트를 출력한다. Kubernetes Secret을 숨기려면\n--hide-secret 플래그를 사용한다. 이러한 플래그를 사용하는 방법과 시기를\n신중하게 고려해야 한다.\n\n--verify가 설정된 경우, 차트에는 출처 파일이 반드시 있어야 하며,\n출처 파일은 모든 검증 단계를 반드시 통과해야 한다.\n\n설치할 차트를 표현하는 여섯 가지 방법이 있다:\n\n1. 차트 참조: helm install mymaria example/mariadb\n2. 패키지된 차트 경로: helm install mynginx ./nginx-1.2.3.tgz\n3. 압축 해제된 차트 디렉토리 경로: helm install mynginx ./nginx\n4. 절대 URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. 차트 참조 및 저장소 URL: helm install --repo https://example.com/charts/ mynginx nginx\n6. OCI 레지스트리: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\n차트 참조\n\n차트 참조는 차트 저장소에서 차트를 참조하는 편리한 방법이다.\n\n저장소 접두사가 있는 차트 참조('example/mariadb')를 사용하면, Helm은\n로컬 구성에서 'example'이라는 차트 저장소를 찾은 다음\n해당 저장소에서 'mariadb'라는 이름의 차트를 찾는다.\n개발 버전(알파, 베타, 릴리스 후보)도 포함하려면 '--devel' 플래그를 지정하거나\n'--version' 플래그로 버전 번호를 제공하지 않는 한,\n해당 차트의 최신 안정 버전을 설치한다.\n\n차트 저장소 목록을 보려면 'helm repo list'를 사용한다.\n저장소에서 차트를 검색하려면 'helm search'를 사용한다.\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### 옵션\n\n```\n      --atomic                                     설정된 경우, 설치 실패 시 설치를 삭제. --atomic을 사용하면 --wait 플래그가 자동으로 설정\n      --ca-file string                             이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인\n      --cert-file string                           이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트를 식별\n      --create-namespace                           릴리스 네임스페이스가 없는 경우 생성\n      --dependency-update                          차트를 설치하기 전에 의존성이 누락된 경우 업데이트\n      --description string                         사용자 정의 설명 추가\n      --devel                                      개발 버전도 사용. 버전 '>0.0.0-0'과 동일. --version이 설정되면 무시\n      --disable-openapi-validation                 설정된 경우, 설치 프로세스는 렌더링된 템플릿을 Kubernetes OpenAPI 스키마에 대해 검증하지 않음\n      --dry-run string[=\"client\"]                  설치를 시뮬레이션. --dry-run이 옵션 없이 설정되거나 '--dry-run=client'로 설정된 경우, 클러스터 연결을 시도하지 않음. '--dry-run=server'를 설정하면 클러스터 연결을 시도 가능\n      --enable-dns                                 템플릿 렌더링 시 DNS 조회를 활성화\n      --force                                      교체 전략을 통해 리소스 업데이트를 강제\n  -g, --generate-name                              이름을 생성(NAME 매개변수 생략)\n  -h, --help                                       install 도움말\n      --hide-notes                                 설정된 경우, 설치 출력에 notes를 표시하지 않음. 차트 메타데이터에는 영향을 주지 않음\n      --hide-secret                                --dry-run 플래그와 함께 사용할 때 Kubernetes Secret을 숨김\n      --insecure-skip-tls-verify                   차트 다운로드를 위한 TLS 인증서 검사를 건너뜀\n      --key-file string                            이 SSL 키 파일을 사용하여 HTTPS 클라이언트를 식별\n      --keyring string                             검증에 사용되는 공개 키의 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      릴리스 메타데이터에 추가할 레이블. 쉼표로 구분 (기본값 [])\n      --name-template string                       릴리스 이름을 지정하는 데 사용되는 템플릿 지정\n      --no-hooks                                   설치 중 훅 실행을 방지\n  -o, --output format                              지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table)\n      --pass-credentials                           모든 도메인에 자격 증명을 전달\n      --password string                            요청된 차트가 위치한 차트 저장소 비밀번호\n      --plain-http                                 차트 다운로드에 보안되지 않은 HTTP 연결을 사용\n      --post-renderer postRendererString           포스트 렌더링에 사용할 실행 파일의 경로. $PATH에 있으면 바이너리가 사용되고, 그렇지 않으면 지정된 경로에서 실행 파일을 탐색\n      --post-renderer-args postRendererArgsSlice   포스트 렌더러에 대한 인수 (여러 개 지정 가능) (기본값 [])\n      --render-subchart-notes                      설정된 경우, 부모 차트와 함께 하위 차트 notes를 렌더링\n      --replace                                    지정된 이름이 히스토리에 남아 있는 삭제된 릴리스인 경우에만 해당 이름을 재사용. 프로덕션 환경에서는 안전하지 않음\n      --repo string                                요청된 차트가 위치한 차트 저장소 URL\n      --set stringArray                            명령줄에서 값을 설정 (여러 개 또는 쉼표로 구분된 값을 지정 가능: key1=val1,key2=val2)\n      --set-file stringArray                       명령줄에서 지정된 해당 파일에서 값을 설정 (여러 개 또는 쉼표로 구분된 값을 지정 가능: key1=path1,key2=path2)\n      --set-json stringArray                       명령줄에서 JSON 값을 설정 (여러 개 또는 쉼표로 구분된 값을 지정 가능: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    명령줄에서 리터럴 STRING 값을 설정\n      --set-string stringArray                     명령줄에서 STRING 값을 설정 (여러 개 또는 쉼표로 구분된 값을 지정 가능: key1=val1,key2=val2)\n      --skip-crds                                  설정된 경우, CRD가 설치되지 않음. 기본적으로 CRD가 아직 없으면 설치\n      --skip-schema-validation                     설정된 경우, JSON 스키마 검증을 비활성화\n      --take-ownership                             설정된 경우, install은 helm 어노테이션 검사를 무시하고 기존 리소스의 소유권을 가져옴\n      --timeout duration                           개별 Kubernetes 작업(예: 훅에 대한 Job)을 기다리는 시간 (기본값 5m0s)\n      --username string                            요청된 차트가 위치한 차트 저장소 사용자명\n  -f, --values strings                             YAML 파일 또는 URL에서 값을 지정 (여러 개 지정 가능)\n      --verify                                     사용하기 전에 패키지를 검증\n      --version string                             사용할 차트 버전에 대한 버전 제약을 지정. 이 제약은 특정 태그(예: 1.1.1)일 수도 있고 유효한 범위(예: ^2.0.0)를 참조할 수도 있음. 지정하지 않으면 최신 버전이 사용\n      --wait                                       설정된 경우, 릴리스를 성공으로 표시하기 전에 모든 Pod, PVC, Service, 그리고 Deployment, StatefulSet 또는 ReplicaSet의 최소 Pod 수가 준비 상태가 될 때까지 --timeout 만큼 대기\n      --wait-for-jobs                              설정되고 --wait가 활성화된 경우, 릴리스를 성공으로 표시하기 전에 모든 Job이 완료될 때까지 --timeout 만큼 대기\n```\n\n### 부모 명령에서 상속된 옵션\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력을 활성화\n      --kube-apiserver string           Kubernetes API 서버의 주소와 포트\n      --kube-as-group stringArray       작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름을 지정\n      --kube-ca-file string             Kubernetes API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, Kubernetes API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     Kubernetes API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     Kubernetes API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - Kubernetes를 위한 Helm 패키지 매니저.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n차트에 발생 가능한 문제가 있는지 검사한다\n\n### 개요\n\n\n이 명령은 차트 경로를 받아 해당 차트가 올바른\n형식(well-formed)인지 검증하는 일련의 테스트를 실행한다.\n\n린터(linter)가 차트 설치 실패를 일으킬 사항을 발견하면\n[ERROR] 메시지를 출력한다. 컨벤션이나 권장 사항에 어긋난 이슈를 발견하면\n[WARNING] 메시지를 출력한다.\n\n\n```\nhelm lint PATH [flags]\n```\n\n### 옵션\n\n```\n  -h, --help                      lint에 대한 도움말\n      --kube-version string       기능 및 사용 중단(deprecation) 검사에 사용할 쿠버네티스 버전\n      --quiet                     경고와 오류만 출력\n      --set stringArray           명령줄에서 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=val1,key2=val2)\n      --set-file stringArray      명령줄에서 지정한 파일로부터 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=path1,key2=path2)\n      --set-json stringArray      명령줄에서 JSON 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray   명령줄에서 리터럴 STRING 값 설정\n      --set-string stringArray    명령줄에서 STRING 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=val1,key2=val2)\n      --skip-schema-validation    설정 시 JSON 스키마 검증을 비활성화\n      --strict                    lint 경고 시 실패로 처리\n  -f, --values strings            YAML 파일 또는 URL에서 값 지정 (여러 개 지정 가능)\n      --with-subcharts            의존 차트도 함께 lint\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름을 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스를 위한 헬름 패키지 매니저.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\n릴리스를 나열한다.\n\n### 개요\n\n이 명령은 지정된 네임스페이스에 대한 모든 릴리스를 나열한다 (네임스페이스가 지정되지 않은 경우 현재 네임스페이스 컨텍스트 사용).\n\n기본적으로는, 배포되었거나 실패한 릴리스만 나열한다.\n'--uninstalled' 및 '--all' 과 같은 플래그는 이 동작을 변경한다.\n이러한 플래그는 '--uninstalled --failed' 와 같이 결합할 수 있다.\n\n기본적으로, 항목은 알파벳순으로 정렬된다. 릴리스 날짜별로 정렬하려면 '-d' 플래그를\n사용한다.\n\n--filter 플래그가 제공되면 필터로 처리된다.\n필터는 릴리스 목록에 적용되는 정규식 (Perl 호환)이다.\n필터와 일치하는 항목만 반환된다.\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\n결과가 없으면 'helm list' 는 0으로 종료되지만\n출력은 표시되지 않는다(또는 '-q' 플래그가 없는 경우 헤더만 표시된다).\n\n기본적으로 최대 256개의 항목이 반환될 수 있다. 이를 제한하려면 '--max' 플래그를 사용한다.\n'--max' 를 0으로 설정하면 모든 결과가 반환되지 않는다.\n대신 서버의 기본값을 반환하는데, 이는 256보다 훨씬 더 클 수 있다.\n'--max' 플래그와 '--offset' 플래그를 함께 사용하면 결과를 페이징할 수 있다.\n\n\n```\nhelm list [flags]\n```\n\n### 옵션\n\n```\n  -a, --all                  필터가 적용되지 않은 모든 릴리스를 표시\n  -A, --all-namespaces       모든 네임스페이스의 릴리스를 나열\n  -d, --date                 릴리스 날짜로 정렬\n      --deployed             배포된 릴리스를 표시. 다른 것을 지정하지 않으면 자동으로 활성화\n      --failed               실패한 릴리스를 표시\n  -f, --filter string        정규 표현식(Perl 호환). 표현식과 일치하는 모든 릴리스가 결과에 포함된다\n  -h, --help                 list 명령어에 대한 도움말\n  -m, --max int              가져올 최대 릴리스 수 (기본값 256)\n      --no-headers           기본 출력 형식 사용 시 헤더를 출력하지 않음\n      --offset int           시작 값에서 오프셋하기 위한 목록의 다음 릴리스 인덱스\n  -o, --output format        지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table)\n      --pending              보류 중인 릴리스를 표시\n  -r, --reverse              정렬 순서 반전\n  -l, --selector string      필터링할 셀렉터(레이블 쿼리)로, '=', '==', '!='를 지원 (예: -l key1=value1,key2=value2). secret(기본값) 및 configmap 스토리지 백엔드에서만 작동\n  -q, --short                짧은(간략한) 목록 형식 출력\n      --superseded           대체된 릴리스를 표시\n      --time-format string   golang 시간 포맷터를 사용한 시간 형식. 예: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          제거된 릴리스 표시('helm uninstall --keep-history' 를 사용한 경우)\n      --uninstalling         현재 제거 중인 릴리스 표시\n```\n\n### 상위 명령에서 상속된 옵션\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 여러 그룹을 지정하려면 이 플래그를 반복 사용\n      --kube-as-user string             작업을 수행할 사용자로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. 이 경우 HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않은 경우, 서버에 연결하는 데 사용된 호스트 이름이 사용된다\n      --kube-token string               인증에 사용할 bearer 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와의 통신에 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL이 포함된 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스용 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n차트 디렉토리를 차트 아카이브로 패키징\n\n### 개요\n\n\n이 명령어는 차트를 버전이 지정된 차트 아카이브 파일로 패키징한다. \n경로가 지정되면 차트(Chart.yaml 파일을 포함해야 함)에 대한 그 경로를 찾은 다음\n해당 디렉토리를 패키징한다.\n\n버전이 지정된 차트 아카이브는 헬름 패키지 저장소에서 사용된다.\n\n차트에 서명하려면 '--sign' 플래그를 사용하자. 대부분의 경우, \n'--keyring path/to/secret/keys' 와 '--key keyname' 도 지정해야 할 것이다.\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\n'--keyring' 을 지정하지 않았고 별다른 설정을 하지 않은 환경이라면\n헬름은 보통 공개 키링을 기본값으로 사용한다.\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### 옵션\n\n```\n      --app-version string         차트의 appVersion 을 이 버전으로 설정\n      --ca-file string             이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서 확인\n      --cert-file string           이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n  -u, --dependency-update          패키징 전에 \"Chart.yaml\" 에서 \"charts/\" 디렉토리로 의존성 업데이트\n  -d, --destination string         차트를 기록할 위치 지정 (기본값 \".\")\n  -h, --help                       package 에 대한 도움말\n      --insecure-skip-tls-verify   차트 다운로드 시 TLS 인증서 검사 건너뛰기\n      --key string                 서명할 때 사용하는 키의 이름. --sign 이 true 일 경우 사용\n      --key-file string            이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string             공개 키링의 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     서명 키의 암호문이 포함된 파일의 위치. 표준 입력에서 읽으려면 \"-\" 사용.\n      --password string            요청된 차트를 찾을 수 있는 차트 저장소 비밀번호\n      --plain-http                 차트 다운로드에 안전하지 않은 HTTP 연결 사용\n      --sign                       PGP 개인 키를 사용하여 패키지에 서명\n      --username string            요청된 차트를 찾을 수 있는 차트 저장소 사용자 이름\n      --version string             차트의 버전을 이 유의적(semver) 버전으로 설정\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹. 여러 그룹을 지정하려면 이 플래그를 반복 사용할 수 있음.\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true 이면 쿠버네티스 API 서버의 인증서 유효성 검사 미수행. HTTPS 연결이 안전하지 않게 됨.\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름 사용.\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수, 버스트 제외\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스에 대한 헬름 패키지 매니저.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\n헬름 플러그인 설치, 나열, 제거\n\n### 개요\n\n\n클라이언트 측 헬름 플러그인을 관리한다.\n\n\n### 옵션\n\n```\n  -h, --help   helm plugin 명령어의 도움말\n```\n\n### 부모 명령어로부터 상속된 옵션\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                       자세한 출력 활성화\n      --kube-apiserver string       쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray   작업을 가장(impersonate)하기 위한 그룹. 이 플래그를 반복하여 여러 그룹을 지정 가능\n      --kube-as-user string         작업을 가장할 사용자 이름\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string         사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용된다\n      --kube-token string           인증에 사용할 전달자(bearer) 토큰\n      --kubeconfig string           kubeconfig 파일 경로\n  -n, --namespace string            이 요청의 네임스페이스 범위\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string     캐시된 저장소 색인을 포함하는 파일 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string    저장소 이름 및 URL 이 포함된 파일 경로(기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm](/helm/helm.md)\t - 쿠버네티스용 헬름 패키지 관리자\n* [helm plugin install](/helm/helm_plugin_install.md)\t - 하나 이상의 헬름 플러그인 설치\n* [helm plugin list](/helm/helm_plugin_list.md)\t - 설치된 헬름 플러그인 나열\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md)\t - 하나 이상의 헬름 플러그인 제거\n* [helm plugin update](/helm/helm_plugin_update.md)\t - 하나 이상의 헬름 플러그인 업데이트\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\n헬름 플러그인을 설치한다\n\n### 개요\n\n\n이 명령을 사용하면 VCS 저장소의 URL 또는 로컬 경로에서 플러그인을 설치할 수 있다.\n\n\n```\nhelm plugin install [options] <path|url> [flags]\n```\n\n### 옵션\n\n```\n  -h, --help             install 명령어에 대한 도움말\n      --version string   버전 제약 조건을 지정한다. 지정하지 않으면 최신 버전이 설치된다\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm plugin](./helm_plugin.md)\t - 헬름 플러그인 설치, 나열, 제거\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\n설치된 헬름 플러그인 나열\n\n### 개요\n\n설치된 헬름 플러그인을 나열한다.\n\n```\nhelm plugin list [flags]\n```\n\n### 옵션\n\n```\n  -h, --help   helm plugin list 명령어의 도움말\n```\n\n### 부모 명령어로부터 상속된 옵션\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           자세한 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 가장(impersonate)하기 위한 그룹. 이 플래그를 반복하여 여러 그룹을 지정 가능\n      --kube-as-user string             작업을 가장할 사용자 이름\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용된다\n      --kube-token string               인증에 사용할 전달자(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청의 네임스페이스 범위\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인을 포함하는 파일 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 이 포함된 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm plugin](./helm_plugin.md)\t - 헬름 플러그인 설치, 나열, 제거\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n하나 이상의 헬름 플러그인을 제거\n\n### 개요\n\n하나 이상의 헬름 플러그인을 제거한다.\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### 옵션\n\n```\n  -h, --help   uninstall 명령어에 대한 도움말\n```\n\n### 상위 명령에서 상속된 옵션\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 여러 그룹을 지정하려면 이 플래그를 반복 사용\n      --kube-as-user string             작업을 수행할 사용자로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. 이 경우 HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않은 경우, 서버에 연결하는 데 사용된 호스트 이름이 사용된다\n      --kube-token string               인증에 사용할 bearer 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와의 통신에 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL이 포함된 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm plugin](./helm_plugin.md)\t - 헬름 플러그인 설치, 나열, 제거\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n하나 이상의 헬름 플러그인 업데이트\n\n### Synopsis\n\n하나 이상의 헬름 플러그인을 업데이트한다.\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### 옵션\n\n```\n  -h, --help   helm plugin update 명령어의 도움말\n```\n\n### 부모 명령어로부터 상속된 옵션\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           자세한 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 가장(impersonate)하기 위한 그룹. 이 플래그를 반복하여 여러 그룹을 지정 가능\n      --kube-as-user string             작업을 가장할 사용자 이름\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용할 전달자(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청의 네임스페이스 범위\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인을 포함하는 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL이 포함된 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm plugin](/helm/helm_plugin.md)\t - 헬름 플러그인 설치, 나열, 제거\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\n저장소에서 차트를 다운로드하고 (선택적으로) 로컬 디렉터리에 압축 해제\n\n### 개요\n\n\n패키지 저장소에서 패키지를 검색하고 로컬로 다운로드한다.\n\n이는 검사, 수정 또는 리패키지를 위하여 패키지를 가져올 때 유용하다. 또한\n설치하지 않고 차트의 암호화 검증을 수행하는 데 사용할\n수도 있다.\n\n다운로드 후 차트를 풀 수 있는 옵션이 있다. 그러면 차트에 대한\n디렉터리가 생성되고 해당 디렉터리에 압축이 해제된다.\n\n--verify 플래그가 지정된 경우, 요청된 차트에는 출처 파일이 있어야 하며 확인 프로세스를\n통과해야 한다. 프로세스 중 어느 부분에서라도 실패할 경우 오류가 발생하며,\n차트가 로컬에 저장되지 않는다.\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string             이 CA 번들을 사용하여 HTTPS 지원 서버의 인증서를 확인\n      --cert-file string           이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n  -d, --destination string         차트를 저장할 위치. 이 옵션과 untardir이 지정되면 untardir이 여기에 추가된다. (기본값 \".\")\n      --devel                      개발용 버전으로도 사용 가능. 버전 '>0.0.0-0'과 동일하다. --version 플래그가 설정되면 이 옵션은 무시된다.\n  -h, --help                       pull에 대한 도움말\n      --insecure-skip-tls-verify   차트 다운로드 시 TLS 인증서 확인 생략\n      --key-file string            이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string             확인에 사용되는 공개 키의 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           모든 도메인에 자격 증명 전달\n      --password string            요청된 차트를 찾을 수 있는 차트 저장소 비밀번호\n      --plain-http                 차트 다운로드에 비보안 HTTP 연결 사용\n      --prov                       출처 파일을 가져오기만 하고 확인은 수행하지 않음\n      --repo string                요청된 차트를 찾을 수 있는 차트 저장소 URL\n      --untar                      true로 설정하면 차트를 다운로드한 후 압축을 해제\n      --untardir string            untar가 지정된 경우 차트가 확장되는 디렉터리의 이름을 지정 (기본값 \".\")\n      --username string            요청된 차트를 찾을 수 있는 차트 저장소 사용자 이름\n      --verify                     사용하기 전에 패키지 확인\n      --version string             사용할 차트 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정하지 않으면 최신 버전이 사용된다.\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 가장할 그룹. 여러 그룹을 지정하려면 이 플래그를 반복할 수 있다.\n      --kube-as-user string             작업을 가장할 사용자 이름\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true이면 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다.\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용된다.\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스를 위한 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\n차트를 원격 저장소로 푸시\n\n### 개요\n\n\n차트를 레지스트리에 업로드한다.\n\n차트에 연관된 출처(provenance) 파일이 있으면\n함께 업로드한다.\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string             이 CA 번들을 사용하여 HTTPS 활성화된 서버의 인증서를 확인\n      --cert-file string           이 SSL 인증서 파일을 사용하여 레지스트리 클라이언트 식별\n  -h, --help                       push 에 대한 도움말\n      --insecure-skip-tls-verify   차트 업로드 시 TLS 인증서 확인 생략\n      --key-file string            이 SSL 키 파일을 사용하여 레지스트리 클라이언트 식별\n      --password string            요청된 차트를 찾을 수 있는 차트 저장소 비밀번호\n      --plain-http                 차트 업로드에 비보안 HTTP 연결 사용\n      --username string            요청된 차트를 찾을 수 있는 차트 저장소 사용자 이름\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능\n      --kube-as-user string             작업을 수행할 사용자 이름으로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - Kubernetes용 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\n레지스트리에 로그인 또는 로그아웃\n\n### 개요\n\n\n이 명령어는 레지스트리와 상호 작용하기 위한 여러 하위 명령어로 구성된다.\n\n\n### 옵션\n\n```\n  -h, --help   registry 명령어에 대한 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - Kubernetes용 Helm 패키지 매니저\n* [helm registry login](./helm_registry_login.md)\t - 레지스트리에 로그인\n* [helm registry logout](./helm_registry_logout.md)\t - 레지스트리에서 로그아웃\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\n레지스트리에 로그인\n\n### 개요\n\n\n원격 레지스트리에 인증한다.\n\n\n```\nhelm registry login [host] [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string     이 CA 번들을 사용하여 HTTPS 지원 서버의 인증서를 검증\n      --cert-file string   이 SSL 인증서 파일을 사용하여 레지스트리 클라이언트를 식별\n  -h, --help               login 명령어에 대한 도움말\n      --insecure           인증서 없이 TLS 레지스트리에 연결 허용\n      --key-file string    이 SSL 키 파일을 사용하여 레지스트리 클라이언트를 식별\n  -p, --password string    레지스트리 비밀번호 또는 ID 토큰\n      --password-stdin     stdin에서 비밀번호 또는 ID 토큰 읽기\n      --plain-http         차트 업로드에 안전하지 않은 HTTP 연결 사용\n  -u, --username string    레지스트리 사용자명\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm registry](./helm_registry.md)\t - 레지스트리에 로그인 또는 로그아웃\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\n레지스트리에서 로그아웃\n\n### 개요\n\n\n원격 레지스트리에 저장된 자격 증명을 제거한다.\n\n\n```\nhelm registry logout [host] [flags]\n```\n\n### 옵션\n\n```\n  -h, --help   logout 명령어에 대한 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm registry](./helm_registry.md)\t - 레지스트리에 로그인 또는 로그아웃\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\n차트 저장소 추가, 나열, 제거, 업데이트, 색인 생성\n\n### 개요\n\n이 명령은 차트 저장소와 상호작용하는 여러 하위명령으로 구성된다.\n\n차트 저장소를 추가, 제거, 나열, 색인화하는 데 사용할 수 있다.\n\n### 옵션\n\n```\n  -h, --help   repo 명령어에 대한 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm](./helm.md)\t - 쿠버네티스를 위한 Helm 패키지 매니저\n* [helm repo add](./helm_repo_add.md)\t - 차트 저장소 추가\n* [helm repo index](./helm_repo_index.md)\t - 패키지된 차트가 포함된 디렉터리에서 인덱스 파일 생성\n* [helm repo list](./helm_repo_list.md)\t - 차트 저장소 나열\n* [helm repo remove](./helm_repo_remove.md)\t - 하나 이상의 차트 저장소 제거\n* [helm repo update](./helm_repo_update.md)\t - 차트 저장소에서 로컬로 사용 가능한 차트 정보 업데이트\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\n차트 저장소를 추가한다\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### 옵션\n\n```\n      --allow-deprecated-repos     기본적으로, 이 명령은 영구적으로 삭제된 공식 저장소를 추가하는 것을 허용하지 않으며, 이 옵션을 통해 해당 동작을 비활성화한다\n      --ca-file string             이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인한다\n      --cert-file string           이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트를 식별한다\n      --force-update               저장소가 이미 있는 경우 교체(덮어쓰기)한다\n  -h, --help                       add 명령어에 대한 도움말\n      --insecure-skip-tls-verify   저장소에 대한 TLS 인증서 검사를 건너뛴다\n      --key-file string            이 SSL 키 파일을 사용하여 HTTPS 클라이언트를 식별한다\n      --no-update                  무시됨. 이전에는 강제 업데이트를 비활성화하기 위해 사용되었다. force-update로 대체되어 더 이상 사용되지 않는다.\n      --pass-credentials           모든 도메인에 자격 증명을 전달한다\n      --password string            차트 저장소 비밀번호\n      --password-stdin             표준 입력에서 차트 저장소 비밀번호를 읽는다\n      --timeout duration           인덱스 파일 다운로드 완료를 기다리는 시간 (기본값 2m0s)\n      --username string            차트 저장소 사용자 이름\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm repo](./helm_repo.md)\t - 차트 저장소 추가, 나열, 제거, 업데이트, 색인 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\n패키지된 차트가 포함된 디렉터리에서 인덱스 파일을 생성한다\n\n### 개요\n\n\n현재 디렉터리를 읽고, 발견된 차트를 기반으로 인덱스 파일을 생성한 후,\n결과를 현재 디렉터리의 'index.yaml' 파일에 저장한다.\n\n이 도구는 차트 저장소용 'index.yaml' 파일을 생성하는 데 사용된다.\n차트에 대한 절대 URL을 설정하려면 '--url' 플래그를 사용한다.\n\n생성된 인덱스를 기존 인덱스 파일과 병합하려면 '--merge' 플래그를 사용한다.\n이 경우 현재 디렉터리에서 발견된 차트가 --merge로 전달된 인덱스에 병합되며,\n로컬 차트가 기존 차트보다 우선한다.\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### 옵션\n\n```\n  -h, --help           index 명령어에 대한 도움말\n      --json           JSON 형식으로 출력\n      --merge string   생성된 인덱스를 지정된 인덱스에 병합\n      --url string     차트 저장소의 URL\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm repo](./helm_repo.md)\t - 차트 저장소 추가, 나열, 제거, 업데이트, 인덱스 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n차트 저장소 나열\n\n### 개요\n\n차트 저장소를 나열한다.\n\n```\nhelm repo list [flags]\n```\n\n### Options\n\n```\n  -h, --help            helm repo list 명령어의 도움말\n  -o, --output format   지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table)\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm repo](/helm/helm_repo.md)\t - 차트 저장소 추가, 나열, 제거, 업데이트, 색인 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n하나 이상의 차트 저장소 제거\n\n### 개요\n\n하나 이상의 차트 저장소를 제거한다.\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### 옵션\n\n```\n  -h, --help   remove 명령어에 대한 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm repo](./helm_repo.md)\t - 차트 저장소 추가, 나열, 제거, 업데이트, 인덱스 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n차트 저장소에서 로컬로 사용 가능한 차트의 정보를 업데이트한다\n\n### 개요\n\n\n업데이트 명령어는 각 차트 저장소에서 차트에 대한 최신 정보를 가져온다.\n이 정보는 로컬에 캐싱되어 'helm search' 등의 명령에서 사용된다.\n\n원하는 저장소만 지정하여 업데이트할 수도 있다.\n\t$ helm repo update <repo_name> ...\n모든 저장소를 업데이트하려면 'helm repo update'를 사용한다.\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### 옵션\n\n```\n      --fail-on-repo-update-fail   저장소 중 하나라도 업데이트에 실패하면 전체 업데이트 실패로 처리\n  -h, --help                       update 명령어에 대한 도움말\n      --timeout duration           인덱스 파일 다운로드 완료까지 대기 시간 (기본값 2m0s)\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm repo](./helm_repo.md)\t - 차트 저장소 추가, 나열, 제거, 업데이트, 인덱스 생성\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\n릴리스를 이전 리비젼으로 롤백한다.\n\n### 개요\n\n\n이 명령은 릴리스를 이전 리비젼으로 롤백한다.\n\nrollback 명령어의 첫 번째 인수는 릴리스의 이름이고,\n두 번째 인수는 리비젼(버전) 번호이다.\n이 인수를 생략하거나 0으로 설정하면 바로 이전 릴리스로 롤백된다.\n\n리비젼 번호를 보려면 'helm history RELEASE'를 실행한다.\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### 옵션\n\n```\n      --cleanup-on-fail    롤백이 실패할 때 이 롤백에서 생성된 새 리소스의 삭제를 허용\n      --dry-run            롤백 모의 실행\n      --force              필요한 경우 삭제/재생성을 통해 리소스를 강제로 업데이트\n  -h, --help               rollback 명령어에 대한 도움말\n      --history-max int    릴리스당 저장되는 최대 리비젼 수를 제한. 제한이 없는 경우 0을 사용 (기본값 10)\n      --no-hooks           롤백 중 훅 실행 방지\n      --recreate-pods      해당되는 경우 리소스에 대해 파드 재시작 수행\n      --timeout duration   개별 쿠버네티스 작업(예: 훅에 대한 작업)을 기다리는 시간 (기본값 5m0s)\n      --wait               설정된 경우, 릴리스를 성공으로 표시하기 전에 모든 파드, PVC, 서비스, 디플로이먼트, 스테이트풀셋, 레플리카셋의 최소 파드 수가 Ready 상태가 될 때까지 대기. --timeout 만큼 대기\n      --wait-for-jobs      설정되고 --wait가 활성화된 경우, 릴리스를 성공으로 표시하기 전에 모든 잡(Job)이 완료될 때까지 대기. --timeout 만큼 대기\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용되는 호스트 이름을 사용\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스를 위한 헬름 패키지 매니저.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\n차트에서 키워드 검색\n\n### 개요\n\n\n검색은 Artifact Hub 및 추가한 리포지토리 등 Helm 차트가 \n저장되어 있는 다양한 위치에서 차트를 검색하는 기능을 제공한다.\nsearch 하위 명령어로 다양한 위치의 차트를 검색할 수 있다.\n\n\n### 옵션\n\n```\n  -h, --help   search 명령어에 대한 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우 쿠버네티스 API 서버 인증서를 검증하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 미지정 시 서버 연결에 사용한 호스트명 사용\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API 통신 시 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 인덱스 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm](./helm.md)\t - 쿠버네티스용 Helm 패키지 매니저\n* [helm search hub](./helm_search_hub.md)\t - Artifact Hub 또는 사용자 지정 Hub 인스턴스에서 차트 검색\n* [helm search repo](./helm_search_repo.md)\t - 차트에서 키워드에 대한 리포지토리 검색\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\nArtifact Hub 또는 사용자 지정 Hub 인스턴스에서 차트를 검색한다.\n\n### 개요\n\n\nArtifact Hub 또는 사용자 지정 Hub 인스턴스에서 Helm 차트를 검색한다.\n\nArtifact Hub는 공개적으로 사용 가능한 분산 Helm 차트를 포함하여\nCNCF 프로젝트의 패키지와 설정을 검색, 설치, 게시할 수 있는\n웹 기반 애플리케이션이다. Cloud Native Computing Foundation 샌드박스\n프로젝트이며, https://artifacthub.io/ 에서 방문할 수 있다.\n\n[KEYWORD] 인수로는 단순 키워드 문자열 또는 따옴표로 묶은 고급 쿼리 옵션을\n사용할 수 있다. 고급 쿼리 옵션 문서는\nhttps://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n를 참고한다.\n\n이전 버전의 Helm은 Monocular 인스턴스를 기본 'endpoint'로 사용했으므로,\n하위 호환성을 위해 Artifact Hub는 Monocular 검색 API와 호환된다.\n마찬가지로 'endpoint' 플래그를 설정할 때 지정된 엔드포인트도\nMonocular 호환 검색 API 엔드포인트를 구현해야 한다.\nMonocular 인스턴스를 'endpoint'로 지정하면 고급 쿼리는 지원되지 않는다.\nAPI 상세 정보는 https://github.com/helm/monocular 를 참고한다.\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### 옵션\n\n```\n      --endpoint string      차트 검색을 위한 Hub 인스턴스 (기본값 \"https://hub.helm.sh\")\n      --fail-on-no-result    결과가 없으면 검색 실패 처리\n  -h, --help                 hub 명령어에 대한 도움말\n      --list-repo-url        차트 리포지토리 URL 출력\n      --max-col-width uint   출력 테이블의 최대 열 너비 (기본값 50)\n  -o, --output format        지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table)\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우 쿠버네티스 API 서버 인증서를 검증하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 미지정 시 서버 연결에 사용한 호스트명 사용\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API 통신 시 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 인덱스 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm search](./helm_search.md)\t - 차트에서 키워드 검색\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\n차트에서 키워드에 대한 저장소 검색\n\n### 개요\n\n\n검색은 시스템에 구성된 모든 저장소를 읽고 일치하는 \n항목을 찾는다. 이러한 저장소 검색은 시스템에 \n저장된 메타 데이터를 사용한다.\n\n찾은 차트의 최신 안정 버전을 표시한다. \n--devel 플래그를 지정하면 출력에 시험판 버전이 포함된다. \n버전 제약을 사용하여 검색하려면 --version 을 사용한다.\n\n예:\n\n    # 키워드 \"nginx\" 와 일치하는 안정적인 릴리스 버전 검색\n    $ helm search repo nginx\n\n    # 시험판 버전을 포함하여 키워드 \"nginx\" 와 일치하는 릴리스 버전 검색\n    $ helm search repo nginx --devel\n\n    # 주 버전이 1인 nginx-ingress 의 최신 안정 릴리스 검색\n    $ helm search repo nginx-ingress --version ^1.0.0\n\n저장소는 'helm repo' 명령어로 관리된다.\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### 옵션\n\n```\n      --devel                개발 버전(알파, 베타 및 릴리스 후보 릴리스)도 사용. 버전 '>0.0.0-0' 에 해당하며 --version이 설정되어 있으면 무시됨\n      --fail-on-no-result    검색 결과가 없으면 실패 처리\n  -h, --help                 repo 명령어에 대한 도움말\n      --max-col-width uint   출력 테이블의 최대 열 너비 (기본값 50)\n  -o, --output format        지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table)\n  -r, --regexp               추가한 저장소 검색에 정규식 사용\n      --version string       추가한 저장소에 유의적 버전 제약을 사용하여 검색\n  -l, --versions             추가한 저장소에 대해 각 차트의 각 버전을 한 줄씩 긴 목록으로 표시\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일의 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm search](./helm_search.md)\t - 차트에서 키워드 검색\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\n차트의 정보를 표시한다\n\n### 개요\n\n\n이 명령어는 차트에 대한 정보를 표시하는 여러 하위 명령어들로 구성된다\n\n\n### 옵션\n\n```\n  -h, --help   show 에 대한 도움말\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일의 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스에 대한 Helm 패키지 매니저\n* [helm show all](./helm_show_all.md)\t - 차트의 모든 정보를 표시\n* [helm show chart](./helm_show_chart.md)\t - 차트의 정의를 표시\n* [helm show crds](./helm_show_crds.md)\t - 차트의 CRD를 표시\n* [helm show readme](./helm_show_readme.md)\t - 차트의 README를 표시\n* [helm show values](./helm_show_values.md)\t - 차트의 값을 표시\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\n차트의 모든 정보를 표시한다\n\n### 개요\n\n\n이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고 모든 내용을 \n표시한다. (values.yaml, Chart.yaml, README)\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string             CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인\n      --cert-file string           SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n      --devel                      개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨\n  -h, --help                       all 에 대한 도움말\n      --insecure-skip-tls-verify   차트 다운로드 시 TLS 인증서 확인을 건너뜀\n      --key-file string            SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string             확인에 사용되는 공개 키의 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           모든 도메인에 자격 증명을 전달\n      --password string            요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호\n      --plain-http                 차트 다운로드에 안전하지 않은 HTTP 연결 사용\n      --repo string                요청된 차트를 찾을 수 있는 차트 리포지토리 URL\n      --username string            요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름\n      --verify                     패키지를 사용하기 전에 확인\n      --version string             사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일의 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm show](./helm_show.md)\t - 차트의 정보를 표시\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\n차트의 정의를 표시한다\n\n### 개요\n\n\n이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고, Chart.yaml 파일의 내용을 표시한다.\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string             CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인\n      --cert-file string           SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n      --devel                      개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨\n  -h, --help                       chart 에 대한 도움말\n      --insecure-skip-tls-verify   차트 다운로드 시 TLS 인증서 확인을 건너뜀\n      --key-file string            SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string             확인에 사용되는 공개 키의 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           모든 도메인에 자격 증명을 전달\n      --password string            요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호\n      --plain-http                 차트 다운로드에 안전하지 않은 HTTP 연결 사용\n      --repo string                요청된 차트를 찾을 수 있는 차트 리포지토리 URL\n      --username string            요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름\n      --verify                     패키지를 사용하기 전에 확인\n      --version string             사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일의 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm show](./helm_show.md)\t - 차트의 정보를 표시\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\n차트의 CRD를 표시한다\n\n### 개요\n\n\n이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고, CustomResourceDefinition 파일의 내용을 표시한다.\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string             CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인\n      --cert-file string           SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n      --devel                      개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨\n  -h, --help                       crds 에 대한 도움말\n      --insecure-skip-tls-verify   차트 다운로드 시 TLS 인증서 확인을 건너뜀\n      --key-file string            SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string             확인에 사용되는 공개 키의 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           모든 도메인에 자격 증명을 전달\n      --password string            요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호\n      --plain-http                 차트 다운로드에 안전하지 않은 HTTP 연결 사용\n      --repo string                요청된 차트를 찾을 수 있는 차트 리포지토리 URL\n      --username string            요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름\n      --verify                     패키지를 사용하기 전에 확인\n      --version string             사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일의 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm show](./helm_show.md)\t - 차트의 정보를 표시\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\n차트의 README 파일을 표시한다\n\n### 개요\n\n\n이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고, README 파일의 내용을 보여준다.\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string             CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인\n      --cert-file string           SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n      --devel                      개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨\n  -h, --help                       readme 에 대한 도움말\n      --insecure-skip-tls-verify   차트 다운로드 시 TLS 인증서 확인을 건너뜀\n      --key-file string            SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string             확인에 사용되는 공개 키의 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           모든 도메인에 자격 증명을 전달\n      --password string            요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호\n      --plain-http                 차트 다운로드에 안전하지 않은 HTTP 연결 사용\n      --repo string                요청된 차트를 찾을 수 있는 차트 리포지토리 URL\n      --username string            요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름\n      --verify                     패키지를 사용하기 전에 확인\n      --version string             사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일의 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm show](./helm_show.md)\t - 차트의 정보를 표시\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\n차트의 값을 표시한다\n\n### 개요\n\n\n이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고, values.yaml 파일의 내용을 보여준다.\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### 옵션\n\n```\n      --ca-file string             CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인\n      --cert-file string           SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n      --devel                      개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨\n  -h, --help                       values 에 대한 도움말\n      --insecure-skip-tls-verify   차트 다운로드 시 TLS 인증서 확인을 건너뜀\n      --jsonpath string            출력을 필터링하기 위한 JSONPath 표현식 제공\n      --key-file string            SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string             확인에 사용되는 공개 키의 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           모든 도메인에 자격 증명을 전달\n      --password string            요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호\n      --plain-http                 차트 다운로드에 안전하지 않은 HTTP 연결 사용\n      --repo string                요청된 차트를 찾을 수 있는 차트 리포지토리 URL\n      --username string            요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름\n      --verify                     패키지를 사용하기 전에 확인\n      --version string             사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일의 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm show](./helm_show.md)\t - 차트의 정보를 표시\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\n명명된 릴리스의 상태를 표시한다\n\n### 개요\n\n\n이 명령어는 명명된 릴리스의 상태를 표시한다.\n상태는 다음으로 구성된다:\n- 마지막 배포 시간\n- 릴리스가 있는 k8s 네임스페이스\n- 릴리스의 상태 (가능한 값: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade or pending-rollback)\n- 릴리스의 리비전\n- 릴리스의 설명 (완료 메시지 또는 오류 메시지일 수 있으며, --show-desc 옵션 필요)\n- 이 릴리스를 구성하는 리소스 목록 (--show-resources 옵션 필요)\n- 해당되는 경우, 마지막 테스트 스위트 수행에 관한 세부 정보\n- 차트에서 제공하는 추가 참고 사항\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### 옵션\n\n```\n  -h, --help             helm status 에 대한 도움말\n  -o, --output format    지정된 형식으로 결과를 표시한다. 허용되는 값: table, json, yaml (기본값 table)\n      --revision int     설정된 경우, 해당 리비전의 명명된 릴리스 상태를 표시한다\n      --show-desc        설정된 경우, 명명된 릴리스의 설명 메시지를 표시한다\n      --show-resources   설정된 경우, 명명된 릴리스의 리소스를 표시한다\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외)\n      --registry-config string          레지스트리 구성 파일의 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스용 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\n로컬에서 템플릿을 렌더링한다.\n\n### 개요\n\n\n차트 템플릿을 로컬에서 렌더링하고 그 결과를 표시한다.\n\n일반적으로 클러스터 내에서 조회되거나 검색되는 모든 값은 로컬에서 모의 처리된다.\n또한 차트 유효성에 대한 서버 측 테스트(예: API 지원 여부)는 수행되지 않는다.\n\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### 옵션\n\n```\n  -a, --api-versions strings                       Capabilities.APIVersions에 사용되는 쿠버네티스 API 버전\n      --atomic                                     설정된 경우, 설치 프로세스는 실패 시 설치본을 삭제한다. --atomic을 사용하면 --wait 플래그가 자동으로 설정된다\n      --ca-file string                             이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인\n      --cert-file string                           이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별\n      --create-namespace                           릴리스 네임스페이스가 없는 경우 생성\n      --dependency-update                          차트를 설치하기 전에 누락된 종속성을 업데이트\n      --description string                         사용자 정의 설명 추가\n      --devel                                      개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며, --version이 설정된 경우 무시된다\n      --disable-openapi-validation                 설정된 경우, 설치 프로세스는 쿠버네티스 OpenAPI 스키마에 대해 렌더링된 템플릿의 유효성 검사를 수행하지 않는다\n      --dry-run string[=\"client\"]                  설치를 시뮬레이션한다. --dry-run을 옵션 없이 설정하거나 '--dry-run=client'로 설정하면 클러스터 연결을 시도하지 않는다. '--dry-run=server'를 설정하면 클러스터 연결을 시도할 수 있다.\n      --enable-dns                                 템플릿 렌더링 시 DNS 조회 활성화\n      --force                                      교체 전략을 통해 리소스 업데이트를 강제 수행\n  -g, --generate-name                              이름을 생성한다 (NAME 매개변수 생략)\n  -h, --help                                       template 명령어에 대한 도움말\n      --hide-notes                                 설정된 경우, 설치 출력에 노트를 표시하지 않는다. 차트 메타데이터의 존재에는 영향을 미치지 않는다\n      --include-crds                               템플릿 출력에 CRD 포함\n      --insecure-skip-tls-verify                   차트 다운로드 시 TLS 인증서 검사 건너뛰기\n      --is-upgrade                                 .Release.IsInstall 대신 .Release.IsUpgrade 설정\n      --key-file string                            이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string                             검증에 사용되는 공개 키 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        Capabilities.KubeVersion에 사용되는 쿠버네티스 버전\n  -l, --labels stringToString                      릴리스 메타데이터에 추가될 레이블. 쉼표로 구분한다. (기본값 [])\n      --name-template string                       릴리스 이름 지정에 사용되는 템플릿 지정\n      --no-hooks                                   설치 중 훅 실행 방지\n      --output-dir string                          실행된 템플릿을 표준 출력 대신 지정된 출력 디렉터리의 파일에 작성\n      --pass-credentials                           모든 도메인에 자격 증명 전달\n      --password string                            요청된 차트를 찾을 차트 리포지토리의 비밀번호\n      --plain-http                                 차트 다운로드에 안전하지 않은 HTTP 연결 사용\n      --post-renderer postRendererString           포스트 렌더링에 사용될 실행 파일 경로. $PATH에 있으면 바이너리가 사용되고, 그렇지 않으면 주어진 경로에서 실행 파일을 찾는다\n      --post-renderer-args postRendererArgsSlice   포스트 렌더러에 전달할 인수 (여러 개 지정 가능) (기본값 [])\n      --release-name                               출력 디렉터리 경로에 릴리스 이름 사용\n      --render-subchart-notes                      설정된 경우, 상위 차트와 함께 하위 차트 노트를 렌더링\n      --replace                                    해당 이름이 기록에 남아있는 삭제된 릴리스인 경우에만 주어진 이름을 재사용. 운영 환경에서는 안전하지 않다\n      --repo string                                요청된 차트를 찾을 차트 리포지토리 URL\n      --set stringArray                            명령줄에서 값 설정 (쉼표로 여러 값 또는 개별 값 지정 가능: key1=val1,key2=val2)\n      --set-file stringArray                       명령줄에서 지정한 파일에서 값 설정 (쉼표로 여러 값 또는 개별 값 지정 가능: key1=path1,key2=path2)\n      --set-json stringArray                       명령줄에서 JSON 값 설정 (쉼표로 여러 값 또는 개별 값 지정 가능: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    명령줄에서 리터럴 STRING 값 설정\n      --set-string stringArray                     명령줄에서 STRING 값 설정 (쉼표로 여러 값 또는 개별 값 지정 가능: key1=val1,key2=val2)\n  -s, --show-only stringArray                      주어진 템플릿에서 렌더링된 매니페스트만 표시\n      --skip-crds                                  설정된 경우, CRD를 설치하지 않는다. 기본적으로 CRD가 없으면 설치된다\n      --skip-schema-validation                     설정된 경우, JSON 스키마 유효성 검사를 비활성화한다\n      --skip-tests                                 템플릿 출력에서 테스트 건너뛰기\n      --take-ownership                             설정된 경우, 설치 시 헬름 어노테이션 확인을 무시하고 기존 리소스의 소유권을 가져온다\n      --timeout duration                           개별 쿠버네티스 작업(예: 훅에 대한 Job)을 기다리는 시간 (기본값 5m0s)\n      --username string                            요청된 차트를 찾을 차트 리포지토리의 사용자 이름\n      --validate                                   현재 가리키는 쿠버네티스 클러스터에 대해 매니페스트의 유효성을 검사한다. 설치 시 수행되는 것과 동일한 유효성 검사이다\n  -f, --values strings                             YAML 파일 또는 URL에 값 지정 (여러 개 지정 가능)\n      --verify                                     사용하기 전에 패키지 확인\n      --version string                             사용할 차트 버전에 대한 버전 제약 조건 지정. 특정 태그(예: 1.1.1)이거나 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정하지 않으면 최신 버전이 사용된다\n      --wait                                       설정된 경우, 릴리스를 성공으로 표시하기 전에 모든 파드, PVC, 서비스, 그리고 Deployment, StatefulSet, ReplicaSet의 최소 파드 수가 Ready 상태가 될 때까지 대기한다. --timeout 시간만큼 대기한다\n      --wait-for-jobs                              설정되고 --wait가 활성화된 경우, 릴리스를 성공으로 표시하기 전에 모든 Job이 완료될 때까지 대기한다. --timeout 시간만큼 대기한다\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 대해 가장할 사용자 이름\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용된다\n      --kube-token string               인증에 사용할 베어러 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 범위\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 리포지토리 인덱스가 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        리포지토리 이름과 URL이 포함된 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 함께 보기\n\n* [helm](/helm/helm.md)\t - 쿠버네티스용 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n릴리스에 대하여 테스트를 수행한다.\n\n### 개요\n\n\ntest 명령어는 릴리스에 대한 테스트를 실행한다.\n\n이 명령어가 받는 인수는 배포된 릴리스의 이름이다.\n실행할 테스트는 설치된 차트에 정의되어 있다.\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### 옵션\n\n```\n      --filter strings     attribute=value 구문 또는 '!attribute=value'를 사용하여 속성(현재는 \"name\")으로 테스트 지정 (제외하려면 !를 사용하고, 쉼표로 구분하거나 여러 번 지정 가능: name=test1,name=test2)\n  -h, --help               helm test 에 대한 도움말\n      --hide-notes         설정된 경우, 테스트 출력에 notes를 표시하지 않음. 차트 메타데이터에는 영향 없음\n      --logs               테스트 파드에서 로그를 덤프 (모든 테스트가 완료된 후 정리 전에 실행)\n      --timeout duration   개별 쿠버네티스 작업(예: 훅에 대한 작업)을 기다리는 시간 제한 (기본값 5m0s)\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능\n      --kube-as-user string             작업에 관해 제시할 사용자명\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트명이 사용됨\n      --kube-token string               인증에 사용될 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                이 요청에 대한 네임스페이스 스코프\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일에 대한 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스를 위한 헬름 패키지 매니저.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n릴리스 삭제\n\n### 개요\n\n\n이 명령어는 릴리스 이름을 사용하여 릴리스를 삭제한다.\n\n차트의 마지막 릴리스와 관련된 모든 리소스 및 릴리스 내역을 제거하여\n나중에 다시 사용할 수 있도록 해제한다.\n\n실제 삭제를 수행하지 않고 어떤 릴리스가 삭제될지 확인하려면\n'--dry-run' 플래그를 사용한다.\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### 옵션\n\n```\n      --cascade string       \"background\", \"orphan\", 또는 \"foreground\" 중 하나. 종속 항목의 삭제 전략을 선택한다. 기본값은 background. (기본값 \"background\")\n      --description string   사용자 정의 설명 추가\n      --dry-run              삭제 시뮬레이션\n  -h, --help                 uninstall 명령어에 대한 도움말\n      --ignore-not-found     \"릴리스를 찾을 수 없음\"을 성공적인 삭제로 처리\n      --keep-history         모든 관련 리소스를 제거하고 릴리스를 삭제됨으로 표시하지만 릴리스 내역은 유지\n      --no-hooks             삭제 중 훅(hook) 실행 방지\n      --timeout duration     개별 쿠버네티스 작업(예: 훅을 위한 작업)을 기다리는 시간 (기본값 5m0s)\n      --wait                 설정된 경우, 반환하기 전에 모든 리소스가 삭제될 때까지 대기한다. --timeout에 지정된 시간 동안 대기\n```\n\n### 상위 명령에서 상속된 옵션\n\n```\n      --burst-limit int                 클라이언트 측 기본 스로틀링 제한 (기본값 100)\n      --debug                           상세 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹으로 가장. 여러 그룹을 지정하려면 이 플래그를 반복 사용\n      --kube-as-user string             작업을 수행할 사용자로 가장\n      --kube-ca-file string             쿠버네티스 API 서버 연결용 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. 이 경우 HTTPS 연결이 안전하지 않게 된다\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않은 경우, 서버에 연결하는 데 사용된 호스트 이름이 사용된다\n      --kube-token string               인증에 사용할 bearer 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 범위\n      --qps float32                     버스트를 제외한 쿠버네티스 API와의 통신에 사용되는 초당 쿼리 수\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL이 포함된 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스용 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n릴리스를 업그레이드한다.\n\n### 개요\n\n\n이 명령어는 릴리스를 새 버전의 차트로 업그레이드한다.\n\n업그레이드 시 사용되는 인수는 릴리스 및 차트여야 한다.\n차트 인수는 차트 참조('example/mariadb'), 차트 디렉터리 경로,\n패키지 차트 또는 정규화된 URL 중 하나일 수 있다.\n차트 참조 시 '--version' 플래그가 설정되지 않았을 경우 최신 버전이 지정된다.\n\n차트의 값을 재정의하려면 '--values' 플래그를 사용하고 파일을\n전달하거나 '--set' 플래그를 사용하고 명령줄에서 구성을 전달한다.\n문자열 값을 강제하려면 '--set-string'을 사용한다.\n값 자체가 명령줄에 사용하기엔 너무 길거나 동적으로 생성되는 경우\n'--set-file'을 사용하여 파일에서 개별 값을 설정할 수 있다.\n'--set-json'을 사용하여 명령줄에서 JSON 값(스칼라/객체/배열)을\n설정할 수도 있다.\n\n'--values'/'-f' 플래그를 여러 번 지정할 수 있다. 지정된 마지막(가장 오른쪽) 파일에 우선 순위가 부여된다.\n예를 들어 myvalues.yaml과 override.yaml에 'Test'라는 키가 포함된 경우\noverride.yaml에 설정된 값이 우선한다.\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\n'--set' 플래그도 여러 번 지정할 수 있다. 지정된 마지막(가장 오른쪽) 세트에\n우선 순위가 부여된다. 예를 들어 'foo'라는 키에 대해 'bar'와 'newbar'에서\n값이 모두 설정된 경우 'newbar'가 우선한다.\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\n'--reuse-values' 플래그를 사용하여 기존 릴리스의 값을 업데이트할 수도 있다.\n'RELEASE'와 'CHART' 인수는 원래 매개변수로 설정해야 하며,\n기존 값은 '--values'/'-f' 또는 '--set' 플래그를 통해 설정된 값과 병합된다.\n새 값에 우선 순위가 부여된다.\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\n--dry-run 플래그는 민감한 값을 포함할 수 있는 Secret을 포함하여\n생성된 모든 차트 매니페스트를 출력한다. Kubernetes Secret을 숨기려면\n--hide-secret 플래그를 사용한다. 이러한 플래그를 사용하는 방법과 시기를\n신중하게 고려해야 한다.\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### 옵션\n\n```\n      --atomic                                     설정된 경우, 업그레이드 실패 시 변경 사항을 롤백. --atomic을 사용하면 --wait 플래그가 자동으로 설정\n      --ca-file string                             이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인\n      --cert-file string                           이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트를 식별\n      --cleanup-on-fail                            업그레이드 실패 시, 이 업그레이드에서 생성된 새 리소스 삭제를 허용\n      --create-namespace                           --install이 설정된 경우 릴리스 네임스페이스가 없으면 생성\n      --dependency-update                          차트를 설치하기 전에 종속성이 누락된 경우 업데이트\n      --description string                         사용자 정의 설명을 추가\n      --devel                                      개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version이 설정되어 있으면 무시\n      --disable-openapi-validation                 설정된 경우, 업그레이드 프로세스는 쿠버네티스 OpenAPI 스키마에 대해 렌더링된 템플릿의 유효성 검사 미수행\n      --dry-run string[=\"client\"]                  설치를 시뮬레이션. --dry-run이 옵션 없이 설정되거나 '--dry-run=client'로 설정되면 클러스터 연결을 시도하지 않음. '--dry-run=server'로 설정하면 클러스터 연결을 시도\n      --enable-dns                                 템플릿 렌더링 시 DNS 조회 활성화\n      --force                                      대체 전략을 통해 리소스 강제 업데이트\n  -h, --help                                       upgrade 명령어에 대한 도움말\n      --hide-notes                                 설정된 경우, 업그레이드 출력에 notes를 표시하지 않음. 차트 메타데이터에는 영향 없음\n      --hide-secret                                --dry-run 플래그와 함께 사용 시 Kubernetes Secret을 숨김\n      --history-max int                            릴리스당 저장되는 최대 리비전 수를 제한. 0은 무제한 (기본값 10)\n      --insecure-skip-tls-verify                   차트 다운로드를 위한 TLS 인증서 검사 건너뛰기\n  -i, --install                                    이 이름의 릴리스가 아직 없는 경우 설치 수행\n      --key-file string                            이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별\n      --keyring string                             확인에 사용되는 공개키의 위치 (기본값 \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      릴리스 메타데이터에 추가될 레이블. 쉼표로 구분해야 함. 원래 릴리스 레이블이 업그레이드 레이블과 병합됨. null을 사용하여 레이블 해제 가능 (기본값 [])\n      --no-hooks                                   사전/사후 업그레이드 훅 비활성화\n  -o, --output format                              지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table)\n      --pass-credentials                           모든 도메인에 자격 증명 전달\n      --password string                            요청된 차트를 찾을 수 있는 차트 저장소 비밀번호\n      --plain-http                                 차트 다운로드에 안전하지 않은 HTTP 연결 사용\n      --post-renderer postRendererString           포스트 렌더링에 사용될 실행 파일의 경로. $PATH에 있으면 바이너리가 사용되며 그렇지 않은 경우 주어진 경로에서 실행 파일을 탐색\n      --post-renderer-args postRendererArgsSlice   포스트 렌더러에 대한 인수 (여러 개 지정 가능) (기본값 [])\n      --render-subchart-notes                      설정된 경우, 상위 차트와 함께 하위 차트 notes도 렌더링\n      --repo string                                요청된 차트를 찾을 수 있는 차트 저장소 URL\n      --reset-then-reuse-values                    업그레이드 할 때, 값을 차트에 내장된 값으로 재설정하고, 마지막 릴리스의 값을 적용한 다음 명령줄의 --set 및 -f를 통한 재정의와 병합. '--reset-values' 또는 '--reuse-values'가 지정되면 무시\n      --reset-values                               업그레이드 할 때, 값을 차트에 내장된 값으로 재설정\n      --reuse-values                               업그레이드 할 때, 마지막 릴리스의 값을 재사용하고 --set 및 -f를 통해 명령줄에서 재정의를 병합. '--reset-values'가 지정되면 무시\n      --set stringArray                            명령줄에서 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=val1,key2=val2)\n      --set-file stringArray                       명령줄을 통해 지정된 각 파일에서 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=path1,key2=path2)\n      --set-json stringArray                       명령줄에서 JSON 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    명령줄에서 리터럴 STRING 값 설정\n      --set-string stringArray                     명령줄에서 STRING 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=val1,key2=val2)\n      --skip-crds                                  설정된 경우, 설치 플래그가 활성화된 상태에서 업그레이드를 수행할 때 CRD 미설치. 기본적으로 설치 플래그가 활성화된 상태에서 업그레이드가 수행될 때 CRD가 없으면 설치\n      --skip-schema-validation                     설정된 경우, JSON 스키마 유효성 검사 비활성화\n      --take-ownership                             설정된 경우, 업그레이드는 helm 어노테이션 검사를 무시하고 기존 리소스의 소유권을 가져옴\n      --timeout duration                           개별 쿠버네티스 작업(훅에 대한 Job 등)을 기다리는 시간 (기본값 5m0s)\n      --username string                            요청된 차트를 찾을 수 있는 차트 저장소 사용자 이름\n  -f, --values strings                             YAML 파일 또는 URL에 값 지정 (여러 개 지정 가능)\n      --verify                                     사용하기 전에 패키지 확인\n      --version string                             사용할 차트 버전에 대한 버전 제약 조건 지정. 이 제약 조건은 특정 태그(예: 1.1.1)이거나 유효한 범위(예: ^2.0.0)를 참조할 수 있음. 지정하지 않으면 최신 버전 사용\n      --wait                                       설정된 경우, 릴리스를 성공으로 표시하기 전에 모든 Pod, PVC, Service, 및 Deployment, StatefulSet 또는 ReplicaSet의 최소 Pod 수가 준비 상태가 될 때까지 대기. --timeout으로 설정된 시간까지 대기\n      --wait-for-jobs                              설정되고 --wait가 활성화된 경우, 릴리스를 성공으로 표시하기 전에 모든 Job이 완료될 때까지 대기. --timeout으로 설정된 시간까지 대기\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름을 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스를 위한 헬름 패키지 매니저.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\n주어진 경로의 차트가 서명되었고 유효한지 확인한다.\n\n### 개요\n\n주어진 차트에 유효한 출처(provenance) 파일이 있는지 검증한다.\n\n출처 파일은 차트가 변조되지 않았으며 신뢰할 수 있는 공급자가\n패키징했다는 암호화 검증을 제공한다.\n\n이 명령어는 로컬 차트를 검증하는 데 사용할 수 있다. 다른 여러 명령어는\n동일한 유효성 검사를 실행하는 '--verify' 플래그를 제공한다. 서명된 패키지를 생성하려면\n'helm package --sign' 명령어를 사용한다.\n\n\n```\nhelm verify PATH [flags]\n```\n\n### 옵션\n\n```\n  -h, --help             verify에 대한 도움말\n      --keyring string   공개 키를 포함하는 키링(keyring) (기본값 \"~/.gnupg/pubring.gpg\")\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름을 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스에 대한 Helm 패키지 매니저\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n클라이언트 버전 정보를 출력한다.\n\n### 개요\n\n\n헬름의 버전을 표시한다.\n\n이 명령어는 헬름 버전을 특정 형식으로 출력한다.\n출력 결과는 대략 다음과 같을 것이다.\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version은 릴리스의 유의적(semantic) 버전이다.\n- GitCommit은 이 버전이 빌드된 커밋의 SHA 값이다.\n- GitTreeState는 이 바이너리를 빌드할 때 로컬 코드 변경이 없었으면 \"clean\"이고,\n  로컬에서 수정된 코드로 빌드한 바이너리이면 \"dirty\"이다.\n- GoVersion은 헬름을 컴파일할 때 사용된 Go 버전이다.\n\n--template 플래그를 사용하면 템플릿에서 다음 속성을 사용할 수 있다:\n\n- .Version은 헬름의 유의적 버전을 포함한다.\n- .GitCommit은 깃 커밋을 의미한다.\n- .GitTreeState는 헬름이 빌드되었을 때 깃 트리의 상태이다.\n- .GoVersion은 헬름이 컴파일된 Go 버전을 포함한다.\n\n예: --template='Version: {{.Version}}'은 'Version: v3.2.1'을 출력한다.\n\n\n```\nhelm version [flags]\n```\n\n### 옵션\n\n```\n  -h, --help              version에 대한 도움말\n      --short             버전 번호만 출력\n      --template string   버전 문자열 형식에 대한 템플릿\n```\n\n### 부모 명령어에서 상속된 옵션들\n\n```\n      --burst-limit int                 클라이언트 측 기본 쓰로틀링 제한 (기본값 100)\n      --debug                           장황한(verbose) 출력 활성화\n      --kube-apiserver string           쿠버네티스 API 서버의 주소 및 포트\n      --kube-as-group stringArray       작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능\n      --kube-as-user string             작업을 수행할 사용자 이름을 지정\n      --kube-ca-file string             쿠버네티스 API 서버 연결을 위한 인증 기관 파일\n      --kube-context string             사용할 kubeconfig 컨텍스트 이름\n      --kube-insecure-skip-tls-verify   true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨\n      --kube-tls-server-name string     쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용\n      --kube-token string               인증에 사용할 베어러(bearer) 토큰\n      --kubeconfig string               kubeconfig 파일 경로\n  -n, --namespace string                요청에 대한 네임스페이스 지정\n      --qps float32                     쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외)\n      --registry-config string          레지스트리 구성 파일 경로 (기본값 \"~/.config/helm/registry/config.json\")\n      --repository-cache string         캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 \"~/.cache/helm/repository\")\n      --repository-config string        저장소 이름 및 URL을 포함하는 파일 경로 (기본값 \"~/.config/helm/repositories.yaml\")\n```\n\n### 참조\n\n* [helm](./helm.md)\t - 쿠버네티스를 위한 헬름 패키지 매니저.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/helm/index.mdx",
    "content": "---\ntitle: 헬름 명령어\ndescription: 헬름 CLI 명령어 전체 목록 문서\nsidebar_position: 6\nid: helm-category\n---\n\n# 헬름 명령어\n\n이곳에서 헬름 CLI 명령어 목록을 찾고, 그 사용법 정보를 얻을 수 있다.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action으로 GitHub Pages 차트 릴리스 자동화하기\ndescription: Chart Releaser Action을 사용하여 GitHub Pages를 통해 차트 릴리스를 자동화하는 방법을 설명합니다.\nsidebar_position: 3\n---\n\n이 가이드는 [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 워크플로우입니다.\n\n## 리포지토리 설정\n\nGitHub 조직 아래에 Git 리포지토리를 생성합니다. 리포지토리 이름은 `helm-charts`로 지정할 수 있지만, 다른 이름도 사용 가능합니다. 모든 차트의 소스는 `main` 브랜치에 배치할 수 있습니다. 차트는 최상위 `/charts` 디렉터리에 위치해야 합니다.\n\n차트를 게시하려면 `gh-pages`라는 이름의 별도 브랜치가 필요합니다. 이 브랜치에 대한 변경 사항은 Chart Releaser Action이 자동으로 생성합니다. 단, 해당 `gh-pages` 브랜치를 직접 생성하고 `README.md` 파일을 추가할 수도 있으며, 이 파일은 페이지 방문자에게 표시됩니다.\n\n`README.md`에 다음과 같은 차트 설치 안내를 추가할 수 있습니다(`<alias>`, `<orgname>`, `<chart-name>`을 실제 값으로 바꿔주세요):\n\n```\n## Usage\n\n[Helm](https://helm.sh) must be installed to use the charts.  Please refer to\nHelm's [documentation](https://helm.sh/docs) to get started.\n\nOnce Helm has been set up correctly, add the repo as follows:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nIf you had already added this repo earlier, run `helm repo update` to retrieve\nthe latest versions of the packages.  You can then run `helm search repo\n<alias>` to see the charts.\n\nTo install the <chart-name> chart:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nTo uninstall the chart:\n\n    helm uninstall my-<chart-name>\n```\n\n차트는 다음과 같은 URL의 웹사이트에 게시됩니다:\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions 워크플로우\n\n`main` 브랜치의 `.github/workflows/release.yml` 경로에 GitHub Actions 워크플로우 파일을 생성합니다.\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\n위 설정은 [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action)을 사용하여 GitHub 프로젝트를 자체 호스팅 Helm 차트 리포지토리로 전환합니다. main 브랜치에 푸시할 때마다 프로젝트의 각 차트를 확인하고, 새로운 차트 버전이 발견되면 해당 버전 이름으로 GitHub 릴리스를 생성합니다. 그런 다음 Helm 차트 아티팩트를 릴리스에 추가하고, 릴리스 메타데이터가 포함된 `index.yaml` 파일을 생성하거나 업데이트합니다. 이 파일은 GitHub Pages에서 호스팅됩니다.\n\n위 예제에서 사용된 Chart Releaser Action 버전은 `v1.6.0`입니다. [최신 버전](https://github.com/helm/chart-releaser-action/releases)으로 변경할 수 있습니다.\n\n참고: Chart Releaser Action은 거의 항상 [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) 및 [Kind Action](https://github.com/marketplace/actions/kind-cluster)과 함께 사용됩니다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: 차트 리포지토리 동기화\ndescription: 로컬 및 원격 차트 리포지토리를 동기화하는 방법\nsidebar_position: 2\n---\n\n*참고: 이곳의 예제들은 차트 리포지토리를 제공하는*\n*Google Cloud Storage (GCS) 버킷에 맞게 작성되었다.*\n\n## 전제 조건\n* [gsutil](https://cloud.google.com/storage/docs/gsutil) 툴을 설치해야 한다. *gsutil rsync 기능이 필요하다.*\n* 헬름 바이너리에 대한 접근 권한이 있어야 한다.\n* _선택 사항: 실수로 파일을 삭제할 경우를 대비하여 GCS 버킷에 [오브젝트 버전 관리](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)를 설정하는 것을 추천한다._\n\n## 로컬 차트 리포지토리 디렉터리 설정\n[차트 리포지토리 가이드](/topics/chart_repository.md)에서 한 것처럼 로컬 디렉터리를 만들고, 패키지된 차트를 그 디렉터리로 옮긴다.\n\n예제:\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## 업데이트 된 index.yaml 생성\n다음과 같이 `helm repo index` 헬름 명령어에 원격 리포지토리의 디렉터리 경로와 URL을 전달하여 \n업데이트된 index.yaml 파일을 생성한다.\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\n그러면 업데이트된 index.yaml 파일이 생성되고 \n`fantastic-charts/` 디렉터리에 위치하게 된다.\n\n## 로컬 및 원격 차트 리포지토리 동기화\n`scripts/sync-repo.sh` 명령어에 로컬 디렉터리명과 \nGCS 버킷명을 전달하여 디렉터리 컨텐츠를 GCS 버킷에 업로드한다.\n\n예제:\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## 차트 리포지토리 업데이트\n필요시 차트 리포지토리 컨텐츠의 로컬 복사본을 따로 보관하거나\n`gsutil rsync` 를 사용하여 원격 차트 리포지토리 컨텐츠를 로컬 디렉터리에 \n복사해 둘 수 있다.\n\n예제:\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\n유용한 링크:\n* [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) 에 \n  대한 문서\n* [차트 리포지토리 가이드](/topics/chart_repository.md)\n* Google Cloud Storage의 \n  [오브젝트 버전 관리 및 동시성 제어](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)에 \n  대한 문서\n  \n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: 차트 개발 팁과 비법\ndescription: 헬름 차트 개발자들이 프로덕션 수준의 차트를 만들면서 배운 팁과 비법을 다룹니다.\nsidebar_position: 1\n---\n\n이 가이드는 헬름 차트 개발자들이 프로덕션 수준의 차트를 만들면서 배운 팁과 비법을 담고 있습니다.\n\n## 템플릿 함수 이해하기\n\n헬름은 리소스 파일의 템플릿을 위해 [Go 템플릿](https://godoc.org/text/template)을 사용합니다. Go는 여러 가지 내장 함수를 제공하지만, 헬름은 많은 추가 함수들을 제공합니다.\n\n먼저 [Sprig 라이브러리](https://masterminds.github.io/sprig/)에 있는 모든 함수를 추가했습니다. 보안상의 이유로 `env`와 `expandenv`는 제외됩니다.\n\n그리고 두 가지 특별한 템플릿 함수인 `include`와 `required`를 추가했습니다. `include` 함수는 다른 템플릿을 불러오고, 그 결과를 다른 템플릿 함수에 전달할 수 있게 해줍니다.\n\n예를 들어, 이 템플릿 조각은 `mytpl`이라는 템플릿을 포함한 후, 결과를 소문자로 변환하고, 그것을 큰따옴표로 감쌉니다.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\n`required` 함수는 템플릿 렌더링을 위해 특정 값 항목이 필수임을 선언할 수 있게 해줍니다. 만약 값이 비어있다면, 템플릿 렌더링은 사용자가 제출한 오류 메시지와 함께 실패하게 됩니다.\n\n다음은 `required` 함수의 예시로, `.Values.who` 항목이 필수로 선언되며, 해당 항목이 없을 경우 오류 메시지를 출력합니다:\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## 문자열에는 따옴표를 쓰고, 정수형에는 쓰지 말자\n\n문자열 데이터를 사용할 때에는 문자열을 그대로 두기보다 쌍따옴표로 값을 묶는 것이 안전합니다:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\n하지만 정수형의 경우 많은 경우에 쿠버네티스에서 파싱 에러가 발생할 수 있으니 _쌍따옴표를 사용하지 마세요._\n\n```yaml\nport: {{ .Values.Port }}\n```\n\n이 내용은 env 변수 값에는 적용되지 않습니다. 정수를 나타내더라도 문자열로 처리되어야 합니다:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## 'include' 함수 사용하기\n\nGo 언어의 내장 지시어인 `template`를 사용해 다른 템플릿으로부터 템플릿을 가져올 수 있습니다. 하지만 이 지시어는 Go 템플릿 파이프라인과는 함께 사용할 수 없습니다.\n\n헬름에는 특별한 함수 `include`가 있습니다. 이 함수는 다른 템플릿을 가져오고 그 템플릿의 출력 값에 연산을 수행할 수 있도록 합니다:\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\n위의 예제에는 `toYaml`이라고 불리는 템플릿이 포함되어 있습니다. 이 템플릿은 `$value`에 값을 전달하고 그 출력 값을 `indent` 함수에 전달합니다.\n\nYAML이 들여쓰기와 공백을 중요하게 생각하기 때문에 이 방법은 문맥에 맞는 적절한 들여쓰기를 하면서 코드 스니펫을 가져올 수 있는 좋은 방법입니다.\n\n## 'required' 함수 사용하기\n\nGo 언어는 map에 존재하지 않는 키에 접근하는 상황을 제어하기 위한 템플릿 옵션이 있습니다. 주로 `template.Options(\"missingkey=option\")`로 설정되며 `option` 값은 `default`, `zero` 혹은 `error`가 될 수 있습니다. 옵션 설정을 error로 하면 map에 존재하지 않는 키에 접근하려는 모든 상황에서 에러를 발생하며 실행을 멈출 것입니다. 차트 개발자가 `values.yaml`의 특정 값에 대해 이러한 규칙을 적용하고 싶은 상황이 있을 수 있습니다.\n\n`required` 함수는 개발자가 템플릿 렌더링 시 필수로 입력되어야 하는 값 항목을 선언할 수 있도록 합니다. 이 항목이 `values.yaml`에서 비어있다면, 템플릿은 렌더링되지 않고 개발자가 작성한 에러 메시지를 반환할 것입니다.\n\n예를 들어:\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\n위의 예제는 `.Values.foo`가 정의되어 있다면 값을 렌더링하고, `.Values.foo`가 정의되어 있지 않다면 렌더링에 실패하고 종료할 것입니다.\n\n## 'tpl' 함수 사용하기\n\n`tpl` 함수를 이용하여 템플릿 내에 정의된 템플릿 형식의 문자열의 렌더링 값을 구할 수 있습니다. 이 함수는 차트에 템플릿 문자열을 변수로 전달하거나 외부 설정 파일들을 렌더링할 때 유용합니다. 문법: `{{ tpl TEMPLATE_STRING VALUES }}`\n\n예를 들어:\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\n외부 설정 파일을 렌더링하는 예제:\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## 이미지 풀 시크릿 생성하기\n\n이미지 풀 시크릿은 기본적으로 _registry_, _username_, 그리고 _password_의 조합입니다. 앱을 배포하는 데 이 값들이 필요할 수 있지만, 이를 만들기 위해서는 `base64`를 몇 번 실행해야 합니다. 헬퍼 템플릿을 작성하여 시크릿 페이로드로 사용될 Docker 설정 파일을 구성할 수 있습니다. 여기 예제가 있습니다:\n\n먼저 `values.yaml`에 다음과 같은 자격 증명이 정의되어 있다고 가정해 봅시다:\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\n그 다음, 헬퍼 템플릿을 다음과 같이 정의합니다:\n\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\n마지막으로 더 큰 템플릿에서 헬퍼 템플릿을 사용해 시크릿 매니페스트를 생성합니다:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## 자동 디플로이먼트 롤링\n\nConfigMap이나 Secret이 컨테이너에 설정 파일로 주입되거나 다른 외부 의존성 변경으로 인해 파드를 롤링해야 하는 경우가 종종 있습니다. 애플리케이션에 따라 후속 `helm upgrade` 시 재시작이 필요할 수 있지만, 디플로이먼트 스펙 자체가 변경되지 않으면 애플리케이션은 이전 설정으로 계속 실행되어 일관성 없는 배포가 발생합니다.\n\n`sha256sum` 함수를 사용하여 다른 파일이 변경되면 디플로이먼트의 annotation 섹션이 업데이트되도록 할 수 있습니다:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nNOTE: 라이브러리 차트에 이것을 추가하는 경우 `$.Template.BasePath`에서 파일에 접근할 수 없습니다. 대신 `{{ include (\"mylibchart.configmap\") . | sha256sum }}`과 같이 정의를 참조할 수 있습니다.\n\n항상 디플로이먼트를 롤링하고 싶다면, 위와 비슷한 annotation 단계를 사용하되 랜덤 문자열로 대체하여 항상 변경되고 디플로이먼트가 롤링되도록 할 수 있습니다:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\n템플릿 함수를 호출할 때마다 고유한 랜덤 문자열이 생성됩니다. 즉, 여러 리소스에서 사용하는 랜덤 문자열을 동기화해야 하는 경우, 관련된 모든 리소스가 동일한 템플릿 파일에 있어야 합니다.\n\n이 두 가지 방법 모두 디플로이먼트가 내장된 업데이트 전략 로직을 활용하여 다운타임을 방지할 수 있습니다.\n\nNOTE: 과거에는 `--recreate-pods` 플래그를 다른 옵션으로 권장했습니다. 이 플래그는 위의 더 선언적인 방법을 위해 Helm 3에서 deprecated 되었습니다.\n\n## 헬름에 리소스를 삭제하지 않도록 알리기\n\n`helm uninstall`을 실행할 때 삭제되지 않아야 하는 리소스가 있을 수 있습니다. 차트 개발자는 리소스에 annotation을 추가하여 삭제되지 않도록 할 수 있습니다.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\n`helm.sh/resource-policy: keep` annotation은 헬름 작업(`helm uninstall`, `helm upgrade` 또는 `helm rollback`)으로 인해 이 리소스가 삭제될 때 헬름이 삭제를 건너뛰도록 지시합니다. _하지만_ 이 리소스는 고아 상태가 됩니다. 헬름은 더 이상 어떤 방식으로도 이 리소스를 관리하지 않습니다. 이미 제거되었지만 리소스는 유지된 릴리스에 `helm install --replace`를 사용하면 문제가 발생할 수 있습니다.\n\n## \"Partials\" 및 템플릿 포함 사용하기\n\n차트에서 재사용 가능한 부분을 만들고 싶을 때가 있습니다. 블록이든 템플릿 partial이든 말입니다. 그리고 종종 이것들을 별도의 파일에 보관하는 것이 더 깔끔합니다.\n\n`templates/` 디렉터리에서 밑줄(`_`)로 시작하는 파일은 쿠버네티스 매니페스트 파일을 출력하지 않습니다. 따라서 관례적으로 헬퍼 템플릿과 partial은 `_helpers.tpl` 파일에 배치합니다.\n\n## 의존성이 많은 복잡한 차트\n\nCNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0)에 있는 많은 차트들은 더 고급 애플리케이션을 만들기 위한 \"빌딩 블록\"입니다. 하지만 차트는 대규모 애플리케이션의 인스턴스를 만드는 데 사용될 수도 있습니다. 이러한 경우, 단일 우산(umbrella) 차트가 여러 서브차트를 가질 수 있으며, 각 서브차트는 전체의 일부로 기능합니다.\n\n개별 부분들로 복잡한 애플리케이션을 구성하는 현재 모범 사례는 글로벌 설정을 노출하는 최상위 우산 차트를 만들고, `charts/` 하위 디렉터리를 사용하여 각 컴포넌트를 포함시키는 것입니다.\n\n## YAML은 JSON의 상위집합이다\n\nYAML 명세에 따르면, YAML은 JSON의 상위집합입니다. 즉, 모든 유효한 JSON 구조는 YAML에서도 유효해야 합니다.\n\n이것의 장점이 있습니다: 때때로 템플릿 개발자들은 YAML의 공백 민감성을 다루는 것보다 JSON과 유사한 문법으로 데이터 구조를 표현하는 것이 더 쉽다고 느낄 수 있습니다.\n\n모범 사례로서, 템플릿은 JSON 문법이 포맷팅 문제의 위험을 크게 줄이는 경우가 _아니라면_ YAML과 유사한 문법을 따라야 합니다.\n\n## 랜덤 값을 생성할 때는 주의하자\n\n헬름에는 랜덤 데이터, 암호화 키 등을 생성하는 함수들이 있습니다. 이것들을 사용해도 괜찮습니다. 하지만 업그레이드 중에 템플릿이 다시 실행된다는 점에 유의하세요. 템플릿 실행이 이전 실행과 다른 데이터를 생성하면, 해당 리소스의 업데이트가 트리거됩니다.\n\n## 하나의 명령어로 설치 또는 업그레이드하기\n\n헬름은 설치 또는 업그레이드를 단일 명령으로 수행하는 방법을 제공합니다. `helm upgrade`에 `--install` 플래그를 사용하세요. 이렇게 하면 헬름은 릴리스가 이미 설치되어 있는지 확인합니다. 설치되어 있지 않으면 설치를 실행하고, 설치되어 있으면 기존 릴리스를 업그레이드합니다.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/howto/index.mdx",
    "content": "---\ntitle: 사용법\nsidebar_position: 2\n---\n\r\n# 사용법 가이드\r\n\r\n이곳에서는 “…를 어떻게 하나요.?”와 같은 질문에 대한 짧은 답변들을 찾을 수 있을 것이다.\r\n이 사용법 가이드는 주제를 깊이 있게 다루지는 않으며, 그런 것은 [주제 가이드](/topics/index.mdx)내 자료에서 찾을 수 있을 것이다.\r\n다만, 이곳의 가이드는 일반적인 작업들을 빨리 완수할 수 있게 도움을 줄 것이다.\r\n\r\nimport DocCardList from '@theme/DocCardList';\r\n\r\n<DocCardList />"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"문서 홈\"\ndescription: \"문서 구성에 관해 알아야 할 모든 것\"\n---\n\n# 환영\n\n[헬름](https://helm.sh/ko) 문서에 온 것을 환영한다. \n헬름은 쿠버네티스를 위한 패키지 관리 도구이며, \n자세한 배경 지식은 \n[CNCF 헬름 프로젝트 여정 보고서](https://www.cncf.io/cncf-helm-project-journey/)에서 확인할 수 있다. \n\n# 문서 구성\n\n헬름은 많은 문서를 가지고 있다. 구성 방법에 대한 대략의 개요를 보면\n무엇을 어디서 찾아볼지를 알 수 있어 도움이 될 것이다.\n\n- [튜토리얼](/intro/index.mdx)은 나의 첫번째 차트 만들기 단계별 과정을 통해 이끌어 준다.\n  헬름이 처음이라면 여기서 시작하자.\n- [주제 가이드](/topics/index.mdx)는 대략의 핵심 주제와 개념을 다루며\n  유용한 배경 정보와 설명을 제공한다.\n- [커뮤니티 가이드](/community)는 헬름 커뮤니터와 관련된 주제를 다룬다.\n  헬름 자체의 개발 과정이나 기여하는 방법을 알아보려면 여기서 시작하자.\n- [방법 가이드](/howto/index.mdx)는 일종의 요리법(recipes)이다. \n  주요 문제 및 사용 사례들을 다루는 절차를 안내한다.\n  튜토리얼보다 심화된 내용으로서, 헬름이 작동하는 방식에 대한 지식이 어느 정도 있다고 가정한다.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: 치트 시트\ndescription: Helm 치트 시트\nsidebar_position: 4\n---\n\nHelm을 통해 애플리케이션을 관리하는 데 필요한 모든 명령어를 담은 치트 시트입니다.\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### 기본 해석/맥락\n\nChart:\n- pull하여 압축 해제한 차트의 이름입니다.\n- 저장소는 추가했지만 차트를 pull하지 않은 경우 <repo_name>/<chart_name> 형식입니다.\n- 차트의 URL 또는 절대 경로입니다.\n\nName:\n- 현재 Helm 차트 설치에 부여할 이름입니다.\n\nRelease:\n- 설치 인스턴스에 할당한 이름입니다.\n\nRevision:\n- Helm history 명령어에서 확인할 수 있는 값입니다.\n\nRepo-name:\n- 저장소의 이름입니다.\n\nDIR:\n- 디렉토리 이름 또는 경로입니다.\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### 차트 관리\n\n```bash\nhelm create <name>                      # 차트에서 사용되는 공통 파일 및 디렉토리와 함께 차트 디렉토리를 생성합니다.\nhelm package <chart-path>               # 차트를 버전이 지정된 차트 아카이브 파일로 패키징합니다.\nhelm lint <chart>                       # 차트를 검사하고 가능한 문제를 식별하는 테스트를 실행합니다.\nhelm show all <chart>                   # 차트를 검사하고 내용을 나열합니다.\nhelm show values <chart>                # values.yaml 파일의 내용을 표시합니다.\nhelm pull <chart>                       # 차트를 다운로드/pull 합니다.\nhelm pull <chart> --untar=true          # true로 설정하면 다운로드 후 차트 압축을 해제합니다.\nhelm pull <chart> --verify              # 사용 전에 패키지를 검증합니다.\nhelm pull <chart> --version <number>    # 기본값은 최신 버전이며, 사용할 차트 버전에 대한 버전 제약을 지정합니다.\nhelm dependency list <chart>            # 차트의 의존성 목록을 표시합니다.\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### 애플리케이션 설치 및 제거\n\n```bash\nhelm install <name> <chart>                           # 이름을 지정하여 차트를 설치합니다.\nhelm install <name> <chart> --namespace <namespace>   # 특정 네임스페이스에 차트를 설치합니다.\nhelm install <name> <chart> --set key1=val1,key2=val2 # 명령줄에서 값을 설정합니다 (여러 값을 쉼표로 구분하여 지정 가능).\nhelm install <name> <chart> --values <yaml-file/url>  # 지정한 값으로 차트를 설치합니다.\nhelm install <name> <chart> --dry-run --debug         # 차트를 검증하기 위한 테스트 설치를 실행합니다.\nhelm install <name> <chart> --verify                  # 사용 전에 패키지를 검증합니다.\nhelm install <name> <chart> --dependency-update       # 차트 설치 전에 누락된 의존성을 업데이트합니다.\nhelm uninstall <name>                                 # 현재(기본) 네임스페이스에서 릴리스를 제거합니다.\nhelm uninstall <release-name> --namespace <namespace> # 지정된 네임스페이스에서 릴리스를 제거합니다.\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### 애플리케이션 업그레이드 및 롤백\n\n```bash\nhelm upgrade <release> <chart>                            # 릴리스를 업그레이드합니다.\nhelm upgrade <release> <chart> --rollback-on-failure      # 설정 시, 업그레이드 실패 시 변경 사항을 롤백합니다.\nhelm upgrade <release> <chart> --dependency-update        # 차트 설치 전에 누락된 의존성을 업데이트합니다.\nhelm upgrade <release> <chart> --version <version_number> # 사용할 차트 버전에 대한 버전 제약을 지정합니다.\nhelm upgrade <release> <chart> --values                   # YAML 파일 또는 URL로 값을 지정합니다 (여러 개 지정 가능).\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # 명령줄에서 값을 설정합니다 (여러 값 지정 가능).\nhelm upgrade <release> <chart> --force                    # 교체 전략을 통해 리소스를 강제 업데이트합니다.\nhelm rollback <release> <revision>                        # 릴리스를 특정 리비전으로 롤백합니다.\nhelm rollback <release> <revision>  --cleanup-on-fail     # 롤백 실패 시 이 롤백에서 생성된 새 리소스 삭제를 허용합니다.\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### 저장소 목록 조회, 추가, 삭제 및 업데이트\n\n```bash\nhelm repo add <repo-name> <url>   # 인터넷에서 저장소를 추가합니다.\nhelm repo list                    # 추가된 차트 저장소를 나열합니다.\nhelm repo update                  # 차트 저장소에서 사용 가능한 차트 정보를 로컬에서 업데이트합니다.\nhelm repo remove <repo_name>      # 하나 이상의 차트 저장소를 제거합니다.\nhelm repo index <DIR>             # 현재 디렉토리를 읽고 발견된 차트를 기반으로 인덱스 파일을 생성합니다.\nhelm repo index <DIR> --merge     # 생성된 인덱스를 기존 인덱스 파일과 병합합니다.\nhelm search repo <keyword>        # 차트에서 키워드로 저장소를 검색합니다.\nhelm search hub <keyword>         # Artifact Hub 또는 사용자 허브 인스턴스에서 차트를 검색합니다.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Helm 릴리스 모니터링\n\n```bash\nhelm list                       # 지정된 네임스페이스의 모든 릴리스를 나열합니다. 네임스페이스를 지정하지 않으면 현재 네임스페이스 컨텍스트를 사용합니다.\nhelm list --all                 # 필터 없이 모든 릴리스를 표시합니다. -a 사용 가능합니다.\nhelm list --all-namespaces      # 모든 네임스페이스의 릴리스를 나열합니다. -A 사용 가능합니다.\nhelm list -l key1=value1,key2=value2 # 필터링할 셀렉터(레이블 쿼리)입니다. '=', '==', '!='를 지원합니다.\nhelm list --date                # 릴리스 날짜로 정렬합니다.\nhelm list --deployed            # 배포된 릴리스를 표시합니다. 다른 옵션이 지정되지 않으면 자동으로 활성화됩니다.\nhelm list --pending             # 대기 중인 릴리스를 표시합니다.\nhelm list --failed              # 실패한 릴리스를 표시합니다.\nhelm list --uninstalled         # 제거된 릴리스를 표시합니다 ('helm uninstall --keep-history'를 사용한 경우).\nhelm list --superseded          # 대체된 릴리스를 표시합니다.\nhelm list -o yaml               # 지정된 형식으로 출력합니다. 허용 값: table, json, yaml (기본값 table).\nhelm status <release>           # 지정된 릴리스의 상태를 표시합니다.\nhelm status <release> --revision <number>   # 설정 시, 지정된 리비전의 릴리스 상태를 표시합니다.\nhelm history <release>          # 지정된 릴리스의 히스토리 리비전을 표시합니다.\nhelm env                        # Helm에서 사용 중인 모든 환경 정보를 출력합니다.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### 릴리스 정보 다운로드\n\n```bash\nhelm get all <release>      # 지정된 릴리스의 notes, hooks, 제공된 values, 생성된 manifest 파일에 대한 사람이 읽을 수 있는 정보 모음입니다.\nhelm get hooks <release>    # 지정된 릴리스의 hooks를 다운로드합니다. Hooks는 YAML 형식이며 YAML '---\\n' 구분자로 분리됩니다.\nhelm get manifest <release> # manifest는 이 릴리스의 차트에서 생성된 Kubernetes 리소스의 YAML 인코딩 표현입니다. 차트가 다른 차트에 의존하는 경우 해당 리소스도 manifest에 포함됩니다.\nhelm get notes <release>    # 지정된 릴리스의 차트에서 제공하는 notes를 표시합니다.\nhelm get values <release>   # 지정된 릴리스의 values 파일을 다운로드합니다. 출력 형식을 지정하려면 -o를 사용합니다.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### 플러그인 관리\n\n```bash\nhelm plugin install <path/url>      # 플러그인을 설치합니다.\nhelm plugin list                    # 설치된 모든 플러그인 목록을 봅니다.\nhelm plugin update <plugin>         # 플러그인을 업데이트합니다.\nhelm plugin uninstall <plugin>      # 플러그인을 제거합니다.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/intro/index.mdx",
    "content": "---\ntitle: 소개\nsidebar_position: 1\n---\n\r\n# 헬름 소개\r\n\r\n헬름이 처음이신가요? 이곳에서 시작하세요!\r\n\r\nimport DocCardList from '@theme/DocCardList';\r\n\r\n<DocCardList />"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: 헬름 설치하기\ndescription: 헬름 설치하고 작동하는 방법 배우기.\nsidebar_position: 2\n---\n\n이 가이드는 헬름 CLI를 설치하는 방법을 설명합니다.\n헬름은 소스 또는 미리-빌드된(pre-built)\n바이너리 릴리스로 설치할 수 있습니다.\n\n## 헬름 프로젝트 설치 방법\n\n헬름 프로젝트는 헬름을 가져와서 설치하는데 2가지 방법을 제공합니다.\n이 방법들은 헬름 공식 릴리스를 설치하는 공식적인 방법입니다.\n또한, 커뮤니티에서는 다양한 패키지 관리자를 통해 헬름을 설치할 수 있는 방법을 제공합니다. 이러한 방법을 통한 설치는 아래에 있는 공식적인 방법들에서 확인할 수 있습니다.\n\n### 바이너리 릴리스로\n\n헬름의 모든 [릴리스](https://github.com/helm/helm/releases)는\n다양한 OS들을 위한 바이너리 릴리스를 제공합니다.\n이 바이너리 버전들은 수동으로 다운로드하여 설치할 수 있습니다.\n\n1. [원하는 버전](https://github.com/helm/helm/releases)을 다운로드\n2. 압축해제 (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)\n3. 압축해제된 디렉토리에서 `helm` 파일을 찾아서, 원하는 목적지로 이동\n   (`mv linux-amd64/helm /usr/local/bin/helm`)\n\n설치가 완료되면 헬름 클라이언트를 실행하고 [stable 저장소를\n추가](/intro/quickstart.md#initialize-a-helm-chart-repository)할 수 있습니다:\n`helm help`.\n\n**참고:** 헬름 자동화 테스트는 GitHub Actions 빌드 및 릴리스 과정에서 리눅스 AMD64에서만 수행됩니다. 다른 OS에 대한 테스트는 해당 OS의 헬름 지원을 요청한 커뮤니티에서 담당합니다.\n\n### 설치 스크립트로\n\n헬름은 최신 버전을 자동으로 가져와서 [로컬에 설치](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3)하는 설치 스크립트를 제공합니다.\n\n이 스크립트를 받아서 로컬에서 실행할 수 있습니다.\n문서가 잘 작성되어 있으므로, 실행 전에 읽어보면 어떤 작업을 하는 것인지 이해할 수 있습니다.\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\n최신 버전을 설치하려면 `curl\nhttps://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`\n로 설치할 수 있습니다.\n\n## 패키지 매니저를 통해서\n\n헬름 커뮤니티 운영체제 패키지 관리자를 통해서 헬름을 설치할 수 있는 기능을 제공합니다.\n이것들은 헬름 공식 지원은 아니며, 신뢰할 수 있는 서드파티로 간주되지 않습니다.\n\n### Homebrew로 (맥OS)\n\n헬름 커뮤니티 멤버들은 Homebrew용 헬름 포뮬러 빌드를 기여했습니다.\n이 포뮬러는 일반적으로 최신 상태로 유지됩니다.\n\n```console\nbrew install helm\n```\n\n(참고: emacs-helm이라는 포뮬러도 있지만, 이는 다른 프로젝트입니다.)\n\n### Chocolatey로 (윈도우)\n\n헬름 커뮤니티 멤버들은 [Chocolatey](https://chocolatey.org/)용\n[헬름 패키지](https://chocolatey.org/packages/kubernetes-helm) 빌드를 기여했습니다.\n이 패키지는 일반적으로 최신 상태로 유지됩니다.\n\n```console\nchoco install kubernetes-helm\n```\n\n### Scoop으로 (윈도우)\n\n헬름 커뮤니티 멤버들은 [Scoop](https://scoop.sh)용\n[헬름 패키지](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) 빌드를 기여했습니다. 이 패키지는 일반적으로 최신 상태로 유지됩니다.\n\n```console\nscoop install helm\n```\n\n### Winget로 (윈도우)\n\n헬름 커뮤니티 멤버들은 [Winget](https://learn.microsoft.com/en-us/windows/package-manager/)용\n[헬름 패키지](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) 빌드를 기여했습니다.\n이 패키지는 일반적으로 최신 상태로 유지됩니다.\n\n```console\nwinget install Helm.Helm\n```\n\n### Apt로 (데비안/우분투)\n\n헬름 커뮤니티 멤버들은 Debian/Ubuntu용 Apt 패키지를 기여했습니다. 이 패키지는 일반적으로 최신 상태로 유지됩니다. 저장소 호스팅을 제공해준 [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian)에 감사드립니다.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### dnf/yum로 (페도라)\n\nFedora 35부터, 공식 저장소에서 헬름을 사용할 수 있습니다.\n다음 명령으로 헬름을 설치할 수 있습니다.\n\n```console\nsudo dnf install helm\n```\n\n### Snap으로\n\n[Snapcrafters](https://github.com/snapcrafters) 커뮤니티에서\n[헬름 패키지](https://snapcraft.io/helm)의 Snap 버전을 유지보수하고 있습니다.\n\n```console\nsudo snap install helm --classic\n```\n\n### pkg로 (FreeBSD)\n\nFreeBSD 커뮤니티 멤버들은 [FreeBSD Ports Collections](https://man.freebsd.org/ports)용\n[헬름 패키지](https://www.freshports.org/sysutils/helm)\n빌드를 기여했습니다. 이 패키지는 일반적으로 최신 상태로 유지됩니다.\n\n```console\npkg install helm\n```\n\n### 개발용 빌드\n\n릴리스 외에도 헬름의 개발 스냅샷을 다운로드하거나 설치할 수 있습니다.\n\n### 카나리(canary) 빌드에서\n\n\"카나리\" 빌드는 최신 `main` 브랜치로부터 빌드된 헬름 소프트웨어의 버전입니다.\n공식 릴리스가 아니므로 안정적이지 않을 수 있습니다. 하지만 최신 기능을 테스트할 기회를 제공합니다.\n\n카나리 헬름 바이너리는 [get.helm.sh](https://get.helm.sh)에서 제공됩니다.\n아래는 일반적인 빌드에 대한 링크들입니다:\n\n- [리눅스 AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [맥OS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [테스트용 윈도우\n  AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### 소스에서 (리눅스, 맥OS)\n\n소스로 헬름을 빌드하는 것은 약간 더 많은 작업이 필요하지만, 최신(프리릴리스) Helm 버전을 테스트하려는 경우 가장 좋은 방법입니다.\n\n정상적으로 작동하는 Go 환경이 필요합니다.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\n필요한 경우 의존성을 가져와 캐시하고 설정을 검증합니다.\n그 후 `helm`을 컴파일하여 `bin/helm`에 생성합니다.\n\n## 맺음말\n\n대부분의 경우, 미리-빌드된(pre-built) `helm` 바이너리를 가져오는 것으로 설치할 수 있습니다.\n이 문서는 헬름으로 더 정교한 작업을 하려는 사용자를 위한 추가적인 경우들을 다룹니다.\n\n헬름 클라이언트가 성공적으로 설치되면, 헬름을 사용하여 차트를 관리하고\n[stable 차트 저장소를 추가](/intro/quickstart.md#initialize-a-helm-chart-repository)할 수 있습니다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: 퀵스타트 가이드\ndescription: 배포판, FAQ, 플러그인의 설명을 포함한 헬름 설치 및 시작 방법\nsidebar_position: 1\n---\n\n이 가이드는 헬름을 빠르게 시작하는 방법에 대해 다룬다.\n\n## 전제 조건\n\n헬름을 성공적이고 안전하게 사용하려면 다음과 같은 전제 조건들이 필요하다.\n\n1. 쿠버네티스 클러스터\n2. 설치를 위해 어떤 보안 구성을 사용할 것인지 결정하기(필요시)\n3. 헬름 설치 및 구성\n\n### 쿠버네티스 설치 혹은 클러스터에 접근\n\n- 쿠버네티스가 설치되어 있어야 한다. 최신 릴리스의 헬름을 사용하기 위해서, 대부분의 경우 두번째 최신 마이너 릴리스 버전인 쿠버네티스 최신 안정(latest stable) 릴리스 버전 설치를 권장한다.\n- 또한 로컬로 구성된 `kubectl` 복사본이 있어야 한다.\n\n헬름과 쿠버네티스 사이의 버전차이정책(skew) 최대 버전은 [헬름 버전 지원 정책](https://helm.sh/docs/topics/version_skew/)을 참고한다.\n\n## 헬름 설치\n\n헬름 클라이언트의 바이너리 릴리스를 다운로드한다. `homebrew`와 같은 툴을 사용하거나 [공식 릴리스 페이지](https://github.com/helm/helm/releases)를 참고하면 된다.\n\n자세한 내용이나 다른 옵션에 대해서는 [설치 가이드](/intro/install.md)를 참고한다.\n\n## 헬름 차트 리포지토리 초기화 {#initialize-a-helm-chart-repository}\n\n헬름이 준비되면, 차트 리포지토리를 추가할 수 있다. 사용 가능한 헬름 차트 리포지토리는 [Artifact Hub](https://artifacthub.io/packages/search?kind=0)에서 확인할 수 있다.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\n차트 리포지토리 추가가 완료되면 설치할 수 있는 차트들의 목록을 볼 수 있다.\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## 예제 차트 설치\n\n차트를 설치하기 위해서, `helm install` 커맨드를 실행한다. 헬름은 차트를 설치하기 위한 몇가지 방법들이 존재하는데, 가장 쉬운 방법은 `bitnami` 차트들을 이용하는 것이다.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\n위의 예에서, `bitnami/mysql` 차트가 릴리스되었고, 새로운 릴리스의 이름은 `mysql-1612624192`이다.\n\nMySQL 차트에 대한 간단한 정보를 보려면 `helm show chart bitnami/mysql`를 실행한다. 또는 차트에 대한 모든 정보를 보려면 `helm show all bitnami/mysql`를 실행할 수도 있다.\n\n차트를 설치할 때마다, 새로운 릴리스가 생성된다. 따라서 하나의 차트를 동일한 클러스터에 여러 번 설치할 수 있다. 각각을 독립적으로 관리 및 업그레이드 할 수 있다.\n\n`helm install` 커맨드는 다양한 기능을 가진 매우 강력한 커맨드이다. 더 많은 정보를 얻으려면 [헬름 사용 가이드](/intro/using_helm.md)를 참고한다.\n\n## 릴리스에 대해 알아보기\n\n헬름을 사용하여 릴리스된 내용을 쉽게 확인할 수 있다.\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\n`helm list` (또는 `helm ls`) 함수는 배포된 모든 릴리스 목록을 보여준다.\n\n## 릴리스 설치 제거\n\n릴리스를 설치 제거하려면, `helm uninstall` 커맨드를 사용한다.\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\n쿠버네티스에서 `mysql-1612624192`를 설치 제거하면, 릴리스 이력 뿐 아니라 릴리스와 관련된 리소스들도 모두 제거된다.\n\n`--keep-history` 플래그가 제공되면, 릴리스 이력은 유지된다. 그러면 릴리스에 대한 정보를 요청할 수 있다.\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\n헬름은 릴리스를 제거한 후에도 릴리스를 추적하므로, 클러스터 이력을 감사(audit)할 수 있고, 릴리스 삭제 취소도 가능하다. (`helm rollback`을 사용)\n\n## 도움말 읽기\n\n헬름 커맨드 사용법에 대해 더 배우려면, `helm help`을 사용하거나 커맨드 뒤에 `-h` 플래그를 사용한다.\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: 헬름 사용하기\ndescription: 헬름의 기본사항을 설명한다.\nsidebar_position: 3\n---\n\n이 가이드는, 쿠버네티스 클러스터에서 패키지를 관리하는, 헬름 사용시의 기본사항을 설명한다.\n헬름 클라이언트는 이미 [설치되어](/intro/install.md) 있다고 가정한다.\n\n명령어 몇 개를 빨리 실행해보는 데에 관심이 있다면 [퀵스타트 가이드](/intro/quickstart.md)를 참고하는 것도 좋다.\n이 장은 헬름 명령어들의 세부사항을 다루며, 헬름을 사용하는 방법을 설명한다.\n\n## 주요 개념 3가지\n\n*차트*는 헬름 패키지이다. \n이 패키지에는 쿠버네티스 클러스터 내에서 애플리케이션, 도구, 서비스를 구동하는데 필요한 모든 리소스 정의가 포함되어 있다.\n쿠버네티스에서의 Homebrew 포뮬러, Apt dpkg, YUM RPM 파일과 같은 것으로 생각할 수 있다.\n\n*저장소*는 차트를 모아두고 공유하는 장소이다.\n이것은 마치 Perl의 [CPAN 아카이브](https://www.cpan.org)나 [페도라 패키지 데이터베이스](https://src.fedoraproject.org/)와 같은데, 쿠버네티스 패키지용이라고 보면 된다.\n\n*릴리스*는 쿠버네티스 클러스터에서 구동되는 차트의 인스턴스이다.\n일반적으로 하나의 차트는 동일한 클러스터내에 여러 번 설치될 수 있다.\n설치될 때마다, 새로운 _release_ 가 생성된다.\nMySQL 차트의 경우를 생각해보자. \n클러스터 내에 데이터베이스 2대를 구동하려면, 차트를 두번 설치하면 된다.\n차례로 각각의 _release name_ 을 가지는, 각각의 _release_ 를 가지게 될 것이다.\n\n이러한 개념을 염두에 두고, 헬름 설명을 이어간다.\n\n헬름은 쿠버네티스 내부에 _charts_ 를 설치하고, 각 설치에 대해 새로운 _release_ 를 생성한다.\n새로운 차트를 찾기 위해 헬름 차트 _repositories_ 를 검색할 수 있다.\n\n## 'helm search': 차트 찾기\n\n헬름은 강력한 검색 명령어를 제공한다. 서로 다른 2가지 소스 유형을 검색하는데 사용할 수 있다.\n\n- `helm search hub`는 여러 저장소들에 있는 헬름 차트들을 포괄하는 [Artifact Hub](https://artifacthub.io)를 검색한다.\n- `helm search repo`는 `helm repo add`를 사용하여 로컬 헬름 클라이언트에 추가된 저장소들을 검색한다.\n   검색은 로컬 데이터 상에서 이루어지며, 퍼블릭 네트워크 접속이 필요하지 않다.\n\n`helm search hub`를 실행하면 공개적으로 사용 가능한 차트들을 찾아볼 수 있다.\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\n위와 같이 하면 Artifact Hub에서 모든 `wordpress` 차트를 찾는다.\n\n필터 없이 `helm search hub`을 실행하면 사용 가능한 모든 차트를 보여준다.\n\n`helm search hub`는 [artifacthub.io](https://artifacthub.io/)의 위치 URL을 표시하지만, 실제 Helm 리포지토리 URL은 표시하지 않는다. `helm search hub --list-repo-url`을 사용하면 실제 Helm 리포지토리 URL을 확인할 수 있어서 새 리포지토리를 추가할 때 유용하다: `helm repo add [NAME] [URL]`.\n\n`helm search repo`를 사용하면, 기존에 추가된 저장소들에 있는 차트 이름을 볼 수 있다.\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nhelm search는 퍼지 문자열 매칭 알고리즘을 사용하므로, 단어 또는 문구의 일부분만 입력해도 된다.\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nsearch는 사용 가능한 패키지를 찾는 좋은 방법이다.\n설치하려는 패키지를 찾았다면 `helm install`을 이용하여 설치할 수 있다.\n\n## 'helm install': 패키지 설치\n\n새 패키지를 설치하려면, `helm install` 명령어를 사용하자. \n\n가장 간단하게는 사용자가 지정한 릴리스 이름, 설치하려는 차트 이름의 2개 인수를 받는다.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\n이제 `wordpress` 차트가 설치되었다.\n차트를 설치하면 새 _release_ 오브젝트가 생성된다는 점을 알아두자.\n위에서 릴리스의 이름이 `happy-panda`이다. \n(헬름이 생성해주는 이름을 그대로 사용하려면 릴리스 이름을 넣지 말고 `--generate-name`을 사용하자.)\n\n설치하는 동안, `helm` 클라이언트는 어떤 리소스가 생성되는지, 릴리스의 상태는 어떤지, 추가 설정단계가 있는지에 관한 유용한 정보를 출력할 것이다.\n\n헬름은 다음 순서대로 리소스를 설치한다:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\n헬름은 모든 리소스가 구동(running)할 때까지 기다리지 않는다.\n많은 차트들이 크기 600M 이상의 Docker 이미지를 필요로 하며, 클러스터에 설치되기까지는 상당한 시간이 걸린다.\n\n릴리스의 상태 추적을 계속하거나, 구성 정보를 재확인하려면, `helm status`를 사용하자.\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\n위와 같이 릴리스의 현재 상태가 표시된다.\n\n### 설치 전 차트 커스터마이징\n\n여기서는 이 차트의 기본 구성 옵션들만 사용할 것이다.\n대부분의 경우 선호하는 구성을 사용하기 위해 차트를 커스터마이징하게 될 것이다.\n\n차트에 어떤 옵션이 구성 가능한지 보려면, `helm show values`를 사용하자.\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nYAML 형식 파일에 있는 이러한 설정들을 오버라이드(override)하여, 설치시 파일과 함께 반영시킬 수 있다.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\n위와 같이 하면 `user0`이라는 기본 MariaDB 사용자가 생성될 것이고,\n이 사용자에게는 새로 생성된 `user0db` 데이터베이스에 대한 접근권한이 부여되지만,\n나머지 모든 기본설정은 해당 차트를 따르게 된다.\n\n설치 작업에 구성 데이터를 전달하는 방법에는 두가지가 있다.\n\n- `--values` (또는 `-f`): 오버라이드(override)할 YAML 파일을 지정한다.\n  여러 번 지정할 수 있지만 가장 오른쪽에 있는 파일이 우선시된다.\n- `--set`: 명령줄 상에서 오버라이드(override)를 지정한다.\n\n둘 다 사용하면, `--set` 값은 더 높은 우선순위를 가진 `--values`으로 병합된다.\n`--set`에 명시된 오버라이드 사항들은 Secret으로 보관된다.\n`helm get values <release-name>`로 해당 릴리스에 대한 `--set` 설정값들을 조회할 수 있다.\n`--set` 설정값들은 `helm upgrade`를 실행할 때 `--reset-values`를 명시하여 제거할 수 있다.\n\n#### `--set`의 형식과 제한점\n\n`--set` 옵션은 0개 이상의 이름/값 쌍을 받는다.\n가장 간단하게는 `--set name=value`와 같이 사용할 수 있다.\nYAML로 표현하면 다음과 같다.\n\n```yaml\nname: value\n```\n\n여러 개의 값들은 `,` 문자로 구분된다. 그래서 `--set a=b,c=d`는 다음과 같다.\n\n```yaml\na: b\nc: d\n```\n\n더 복잡한 표현도 지원한다. 예를 들어, `--set outer.inner=value`는 다음과 같이 표현된다.\n\n```yaml\nouter:\n  inner: value\n```\n\n리스트는 `{`, `}` 를 사용하여 표현할 수 있다.\n예를 들어, `--set name={a, b, c}`는 다음과 같이 표현된다.\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\n특정 이름/키는 `null`이나 빈 배열 `[]`로 설정할 수 있다. 예를 들어, `--set name=[],a=null`은 다음을\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\n다음과 같이 바꾼다.\n\n```yaml\nname: []\na: null\n```\n\n헬름 2.5.0부터는, 배열 인덱스 문법을 써서 리스트 항목들에 접근할 수 있다.\n예를 들어 `--set servers[0].port=80`은 다음과 같이 된다.\n\n```yaml\nservers:\n  - port: 80\n```\n\n여러 개의 값들이 이런 방식으로 설정될 수 있다.\n`--set servers[0].port=80,servers[0].host=example` 행은 다음과 같이 된다.\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\n때로는 `--set` 행에 특수문자를 써야할 필요가 있을 것이다.\n문자를 이스케이프하기 위해 백슬래시를 사용할 수 있다. `--set name=value1\\,value2`는 다음과 같다.\n\n```yaml\nname: \"value1,value2\"\n```\n\n비슷한 예로, `toYaml` 기능으로 어노테이션, 레이블, 노드 셀렉터를 파싱하는 차트에서 편리하게 사용되는 점 표기를 이스케이프할 수 있다.\n`--set nodeSelector.\"kubernetes\\.io/role\"=master`를 나타내는 구문은 다음과 같다.\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\n여러 단계로 중첩된 자료구조는 `--set`로 표현하기 어려울 수 있다.\n차트 설계자는 `values.yaml` 파일의 형식을 설계할 때 `--set`를 사용하는 경우도 고려해주면 좋다\n(자세한 내용은 [Values 파일](/chart_template_guide/values_files.md)을 참조).\n\n### 더 많은 설치 방법들\n\n`helm install` 명령어를 사용하여 여러 소스에서 설치를 수행할 수 있다.\n\n- 차트 저장소 (위에서 살펴본 것)\n- 로컬 차트 압축파일 (`helm install foo foo-0.1.1.tgz`)\n- 압축해제된 차트 디렉토리 (`helm install foo path/to/foo`)\n- 완전한 URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' 및 'helm rollback': 릴리스 업그레이드 및 실패 복구\n\n새로운 버전의 차트가 릴리스되었을 때, 또는 릴리스의 구성을 변경하고자 할 때,\n`helm upgrade` 명령어를 사용할 수 있다.\n\n업그레이드는 현존하는 릴리스를 가지고, 사용자가 입력한 정보에 따라 업그레이드한다.\n쿠버네티스 차트는 크고 복잡할 수 있기 때문에, 헬름은 최소한의 개입으로 업그레이드를 수행하려고 한다.\n최근 릴리스 이후로 변경된 것들만 업데이트하게 될 것이다.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\n위의 경우, `happy-panda` 릴리스의 차트가 업그레이드되는데 새 YAML 파일도 반영된다.\n\n```yaml\nmariadb.auth.username: user1\n```\n\n`helm get values`를 사용하여 새로운 설정이 적용되었는지 확인해 볼 수 있다.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\n`helm get` 명령어는 클러스터에서 릴리스 정보를 확인할 때 유용한 도구이다.\n위의 예에서 `panda.yaml`의 새로운 값이 클러스터에 배포되었음을 확인할 수 있다.\n\n릴리스가 계획대로 되지 않는다면, \n`helm rollback [RELEASE] [REVISION]`를 사용하여 이전 릴리스로 간단히 롤백할 수 있다.\n\n```console\n$ helm rollback happy-panda 1\n```\n\n위와 같이 하면 happy-panda가 맨 첫번째 릴리스 버전으로 롤백된다.\n릴리스 버전은 증분 리비전(incremental revision)을 나타낸다.\n설치, 업그레이드, 롤백 등이 실행될 때마다, 리비전 번호는 1씩 증가한다.\n첫 번째 리비전 번호는 항상 1이다.\n특정 릴리스의 리비전 번호를 확인하기 위해서는 `helm history [RELEASE]`를 사용할 수 있다.\n\n## 설치/업그레이드/롤백에 관한 유용한 옵션들\n\n설치/업그레이드/롤백 시의 헬름 작동을 커스터마이징하는 다른 여러 유용한 옵션들이 있다.\n아래 나열한 CLI 플래그가 전체 목록은 아니라는 점을 알아두자.\n모든 플래그들에 관한 설명을 보려면, `helm <command> --help`을 실행하자.\n\n- `--timeout`: 쿠버네티스 명령어가 완료되기를 기다려주는 [Go duration](https://golang.org/pkg/time/#ParseDuration) 형식의 시간 값.\n  기본값은 `5m0s`.\n- `--wait`: 릴리스가 성공적이었다고 기록하기 전에,\n  모든 포드들이 준비 상태가 되고 PVC들이 연결되고\n  디플로이먼트가 최소한(`Desired` - `maxUnavailable`)의 준비 상태 포드 수를 갖추며\n  서비스들이 IP 주소(`LoadBalancer`라면 인그레스)를 가질 때까지\n  기다린다. `--timeout` 값만큼 기다릴 것이다.\n  타임아웃되면 릴리스는 `FAILED`로 기록될 것이다. 참고: \n  롤링 업데이트 전략의 일부로서 `replicas` 설정은 1이고 `maxUnavailable` 설정은 0이 아닌 디플로이먼트의 경우,\n  `--wait`는 최소 준비 상태 포드 수를 만족하면 준비 상태로 응답할 것이다.\n- `--no-hooks`: 명령어에 대한 훅(hook) 작동을 생략함\n- `--recreate-pods` (`upgrade`와 `rollback`에만 적용가능): 이 플래그는\n  모든 포드들의 재생성을 일으킬 수 있다 (디플로이먼트에 속한 포드들은 제외). (헬름 3에서 사용 중단(DEPRECATED))\n\n## 'helm uninstall': 릴리스 언인스톨하기\n\n클러스터에서 릴리스를 언인스톨하고자 할 때, `helm uninstall`을 사용해보자.\n\n```console\n$ helm uninstall happy-panda\n```\n\n이렇게 하면 클러스터에서 릴리스가 제거될 것이다.\n`helm list` 명령어로 현재 배포된 모든 릴리스들을 확인할 수 있다.\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\n위의 결과에서 `happy-panda` 릴리스가 언인스톨된 것을 확인할 수 있다.\n\nHelm 구버전에서는 릴리스를 삭제하면 삭제된 기록이 남았는데,\nHelm 3에서는 삭제시에 릴리스 기록도 제거한다.\n삭제 릴리스 기록을 보존하고 싶다면, `helm uninstall --keep-history`을 사용하자.\n`helm list --uninstalled`를 사용하면, `--keep-history` 플래그로 언인스톨된 릴리스들만 볼 수 있다.\n\n`helm list --all` 플래그는, 실패하거나 삭제(`--keep-history` 지정된 경우)된 기록을 포함하여,\n헬름이 가지고 있는 모든 릴리스 기록들을 보여준다.\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\n기본적으로 릴리스는 바로 삭제되기 때문에, 언인스톨된 리소스를 롤백하는 것은 불가능하다는 것을 알아두자.\n\n## 'helm repo': 저장소 작업하기\n\n헬름 3는 더 이상 기본 차트 저장소를 제공하지 않는다.\n`helm repo` 명령어 그룹은 저장소를 추가, 목록조회, 제거하는 명령어를 제공한다.\n\n`helm repo list`를 사용하여 어떤 저장소들이 설정되어 있는지 확인할 수 있다.\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\n`helm repo add`로 새 저장소들을 추가할 수 있다.\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\n차트 저장소는 자주 바뀌므로, `helm repo update`를 실행하여 언제든 헬름 클라이언트를 \n업데이트할 수 있다.\n\n`helm repo remove`로 저장소들을 삭제할 수 있다.\n\n## 내 차트 만들기\n\n[차트 개발 가이드](/topics/charts.md)는 내 차트를 개발하는 방법을 설명한다.\n하지만 `helm create` 명령어를 사용하여 빠르게 시작해볼 수 있다:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\n이제 `./deis-workflow`에 차트가 생겼다.\n생성된 차트를 편집하거나 내 템플릿을 생성할 수 있다.\n\n차트를 편집했다면, `helm lint`를 실행하여 형식이 맞는지 검증할 수 있다.\n\n배포용 차트로 패키징하고자 할 때는, `helm package` 명령어를 사용할 수 있다:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\n이 차트는 이제 `helm install`로 쉽게 설치할 수 있다:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\n패키징된 차트들은 차트 저장소에 보관할 수 있다.\n자세한 내용은 [헬름 차트 저장소](/topics/chart_repository.md) 문서를 참조하자.\n\n## 맺음말\n\n이 장은 검색, 설치, 업그레이드, 언인스톨을 포함한 `helm` 클라이언트의 기본 사용패턴을 다룬다.\n또한 `helm status`, `helm get`, `helm repo`와 같은 유용한 도구 명령어도 다루었다.\n\n이 명령어들에 대해 더 알아보려면, 헬름에 내장된 도움말을 보도록 하자.\n`helm help`\n\n[다음 장](/howto/charts_tips_and_tricks.md)에서는, 차트 개발 프로세스를 살펴볼 것이다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_install.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tinstallClient := action.NewInstall(actionConfig)\n\n\tinstallClient.DryRunOption = \"none\"\n\tinstallClient.ReleaseName = releaseName\n\tinstallClient.Namespace = settings.Namespace()\n\tinstallClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tinstallClient.CertFile,\n\t\tinstallClient.KeyFile,\n\t\tinstallClient.CaFile,\n\t\tinstallClient.InsecureSkipTLSverify,\n\t\tinstallClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tinstallClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tif chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil {\n\t\tif err := action.CheckDependencies(chart, chartDependencies); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !installClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tmanager := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          installClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t\tRegistryClient:   installClient.GetRegistryClient(),\n\t\t\t}\n\t\t\tif err := manager.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := installClient.RunWithContext(ctx, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run install: %w\", err)\n\t}\n\n\tlogger.Printf(\"release created:\\n%+v\", *release)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_list.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runList(logger *log.Logger, settings *cli.EnvSettings) error {\n\n\tactionConfig, err := initActionConfigList(settings, logger, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tlistClient := action.NewList(actionConfig)\n\t// Only list deployed\n\t//listClient.Deployed = true\n\tlistClient.All = true\n\tlistClient.SetStateMask()\n\n\tresults, err := listClient.Run()\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run list action: %w\", err)\n\t}\n\n\tfor _, rel := range results {\n\t\tlogger.Printf(\"list result: %+v\", rel)\n\t}\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_main.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"bufio\"\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\t\"os\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/registry\"\n)\n\nvar helmDriver string = os.Getenv(\"HELM_DRIVER\")\n\nfunc initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) {\n\treturn initActionConfigList(settings, logger, false)\n}\n\nfunc initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) {\n\n\tactionConfig := new(action.Configuration)\n\n\tnamespace := func() string {\n\t\t// For list action, you can pass an empty string instead of settings.Namespace() to list\n\t\t// all namespaces\n\t\tif allNamespaces {\n\t\t\treturn \"\"\n\t\t}\n\t\treturn settings.Namespace()\n\t}()\n\n\tif err := actionConfig.Init(\n\t\tsettings.RESTClientGetter(),\n\t\tnamespace,\n\t\thelmDriver,\n\t\tlogger.Printf); err != nil {\n\t\treturn nil, err\n\t}\n\n\treturn actionConfig, nil\n}\n\nfunc newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) {\n\topts := []registry.ClientOption{\n\t\tregistry.ClientOptDebug(settings.Debug),\n\t\tregistry.ClientOptEnableCache(true),\n\t\tregistry.ClientOptWriter(os.Stderr),\n\t\tregistry.ClientOptCredentialsFile(settings.RegistryConfig),\n\t}\n\tif plainHTTP {\n\t\topts = append(opts, registry.ClientOptPlainHTTP())\n\t}\n\n\t// Create a new registry client\n\tregistryClient, err := registry.NewClient(opts...)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) {\n\tif certFile != \"\" && keyFile != \"\" || caFile != \"\" || insecureSkipTLSverify {\n\t\tregistryClient, err := registry.NewRegistryClientWithTLS(\n\t\t\tlogger.Writer(),\n\t\t\tcertFile,\n\t\t\tkeyFile,\n\t\t\tcaFile,\n\t\t\tinsecureSkipTLSverify,\n\t\t\tsettings.RegistryConfig,\n\t\t\tsettings.Debug)\n\n\t\tif err != nil {\n\t\t\treturn nil, err\n\t\t}\n\t\treturn registryClient, nil\n\t}\n\tregistryClient, err := newRegistryClient(settings, plainHTTP)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc main() {\n\n\tlogger := log.Default()\n\n\t// For convenience, initialize SDK setting via CLI mechanism\n\tsettings := cli.New()\n\n\t// Release name, chart and values\n\treleaseName := \"helm-sdk-example\"\n\tchartRef := \"oci://ghcr.io/stefanprodan/charts/podinfo\"\n\treleaseValues := map[string]interface{}{\n\t\t\"replicaCount\": \"2\",\n\t}\n\n\t// Pull the chart to the local filesystem\n\tif err := runPull(logger, settings, chartRef, \"6.4.1\"); err != nil {\n\t\tfmt.Printf(\"failed to run pull: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// Install the chart (from the pulled chart local archive)\n\tif err := runInstall(context.TODO(), logger, settings, releaseName, \"./podinfo-6.4.1.tgz\", \"\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run install: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart installed. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Upgrade to version 6.5.4, updating the replicaCount to three\n\treleaseValues[\"replicaCount\"] = \"3\"\n\tif err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, \"6.5.4\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run upgrade: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart upgraded. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Uninstall the chart\n\tif err := runUninstall(logger, settings, releaseName); err != nil {\n\t\tfmt.Printf(\"failed to run uninstall: %+v\", err)\n\t\tos.Exit(1)\n\t}\n}\n\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_pull.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tregistryClient, err := newRegistryClient(settings, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tactionConfig.RegistryClient = registryClient\n\n\tpullClient := action.NewPullWithOpts(\n\t\taction.WithConfig(actionConfig))\n\t// client.RepoURL = \"\"\n\tpullClient.DestDir = \"./\"\n\tpullClient.Settings = settings\n\tpullClient.Version = chartVersion\n\n\tresult, err := pullClient.Run(chartRef)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to pull chart: %w\", err)\n\t}\n\n\tlogger.Printf(\"%+v\", result)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_uninstall.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tuninstallClient := action.NewUninstall(actionConfig)\n\tuninstallClient.DeletionPropagation = \"foreground\" // \"background\" or \"orphan\"\n\n\tresult, err := uninstallClient.Run(releaseName)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run uninstall action: %w\", err)\n\t}\n\tif result != nil {\n\t\tlogger.Printf(\"result: %+v\\n\", *result.Release)\n\t}\n\n\tlogger.Printf(\"release \\\"%s\\\" uninstalled\\n\", releaseName)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_upgrade.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tupgradeClient := action.NewUpgrade(actionConfig)\n\n\tupgradeClient.Namespace = settings.Namespace()\n\tupgradeClient.DryRunOption = \"none\"\n\tupgradeClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tupgradeClient.CertFile,\n\t\tupgradeClient.KeyFile,\n\t\tupgradeClient.CaFile,\n\t\tupgradeClient.InsecureSkipTLSverify,\n\t\tupgradeClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"missing registry client: %w\", err)\n\t}\n\tupgradeClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to load chart: %w\", err)\n\t}\n\tif req := chart.Metadata.Dependencies; req != nil {\n\t\tif err := action.CheckDependencies(chart, req); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !upgradeClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tman := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          upgradeClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t}\n\t\t\tif err := man.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run upgrade action: %w\", err)\n\t}\n\n\tlogger.Printf(\"release: %+v\", release)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx",
    "content": "---\ntitle: 예제\ndescription: Helm SDK의 다양한 기능 예제\nsidebar_position: 2\n---\nimport Install from './_install.mdx'\nimport List from './_list.mdx'\nimport Main from './_main.mdx'\nimport Pull from './_pull.mdx'\nimport Uninstall from './_uninstall.mdx'\nimport Upgrade from './_upgrade.mdx'\n\n이 문서에서는 Helm SDK 사용 예제를 다룬다.\n다양한 SDK 기능을 문서화하기 위한 것이다.\n\n마지막 예제는 `main.go` 드라이버([링크](#driver))를 보여준다. 이 드라이버는 아래 작업들을 실행하며 필요한 헬퍼 함수들을 포함한다.\n\n예제 코드는 [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples) 디렉토리에 있다.\n완전히 동작하는 코드이다.\n\n## 작업 {#actions}\n\n\n### Install 작업 {#install-action}\n\n이 예제는 지정된 차트/릴리스를 주어진 버전과 values로 설치한다:\n\n<Install />\n\n### Upgrade 작업 {#upgrade-action}\n\n이 예제는 지정된 릴리스를 주어진 차트, 버전, values로 업그레이드한다:\n\n<Upgrade />\n\n### Uninstall 작업 {#uninstall-action}\n\n이 예제는 지정된 릴리스를 삭제한다\n\n<Uninstall />\n\n### List 작업 {#list-action}\n\n이 예제는 현재 설정된 네임스페이스의 모든 릴리스된 차트를 나열한다\n\n<List />\n\n### Pull 작업 {#pull-action}\n\n이 예제는 OCI 저장소에서 차트를 가져온다\n\n<Pull />\n\n## 드라이버 {#driver}\n\n여기서 드라이버는 Helm SDK 작업이 동작하는 데 필요한 보조 함수들을 보여준다. 그리고 위의 예제들을 실제로 실행하여 OCI 저장소에서 'podinfo' 차트를 가져오고, 설치하고, 업데이트하고, 삭제한다.\n\n<Main />\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: 소개\ndescription: Helm Go SDK 소개\nsidebar_position: 1\n---\nHelm Go SDK를 사용하면 커스텀 소프트웨어에서 Helm 차트와 Helm 기능을 활용하여 Kubernetes 소프트웨어 배포를 관리할 수 있다.\n(실제로 Helm CLI도 이러한 도구 중 하나일 뿐이다!)\n\n현재 SDK는 Helm CLI와 기능적으로 분리되어 있다.\nSDK는 독립적인 도구에서 사용할 수 있으며, 실제로 사용되고 있다.\nHelm 프로젝트는 SDK에 대한 API 안정성을 보장한다.\n참고로, SDK에는 CLI와 SDK를 분리하는 초기 작업에서 남은 다듬어지지 않은 부분이 있다. Helm 프로젝트는 이를 시간이 지남에 따라 개선할 계획이다.\n\n전체 API 문서는 [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3)에서 확인할 수 있다.\n\n아래에서는 주요 패키지 유형에 대한 간략한 개요와 간단한 예제를 제공한다.\n더 많은 예제와 더 완전한 기능의 '드라이버'는 [예제](/sdk/examples.mdx) 섹션을 참조한다.\n\n## 주요 패키지 개요\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action):\n  Helm 작업을 수행하기 위한 주요 \"클라이언트\"를 포함한다.\n  이것은 CLI가 내부적으로 사용하는 것과 동일한 패키지이다.\n  다른 Go 프로그램에서 기본적인 Helm 명령어만 수행하면 되는 경우 이 패키지를 사용하면 된다.\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil):\n  차트를 로드하고 조작하는 데 사용되는 메서드와 헬퍼\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) 및 하위 패키지:\n  표준 Helm 환경 변수에 대한 모든 핸들러를 포함하며, 하위 패키지에는 출력 및 values 파일 처리가 포함되어 있다.\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release):\n  `Release` 객체와 상태를 정의한다.\n\n이 외에도 더 많은 패키지가 있으므로 자세한 내용은 문서를 확인한다!\n\n### 간단한 예제\n다음은 Go SDK를 사용하여 `helm list`를 수행하는 간단한 예제이다.\n더 완전한 기능의 예제는 [예제](/sdk/examples.mdx) 섹션을 참조한다.\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## 호환성\n\nHelm SDK는 명시적으로 Helm의 하위 호환성 보장을 따른다:\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\n즉, 주요 버전이 변경될 때만 호환성을 깨는 변경이 이루어진다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/index.mdx",
    "content": "---\ntitle: Go SDK\nsidebar_position: 7\n---\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: 고급 헬름 기법\ndescription: 헬름의 숙련된 사용자를 위한 다양한 고급 기능을 설명한다.\nsidebar_position: 9\n---\n\n이 섹션에서는 헬름 사용에 관한 다양한 고급 기능과 기법을 설명한다. \n이 섹션의 정보는 차트 및 릴리스의 고급 사용자 정의 및 조작을 \n수행하려는 헬름의 \"숙련 사용자\"를 위한 것이다. 이러한 각 \n고급 기능에는 고유한 장단점 및 주의사항이 있으므로, 각 기능은 \n헬름에 대해 충분한 지식을 가지고 신중하게 사용해야한다. \n바꿔 말해서, [Peter Parker \n원칙](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)을 유념하자.\n\n## 포스트 렌더링\n포스트 렌더링은 차트 설치 프로그램이 헬름으로 설치하기 전에\n렌더링된 매니페스트를 수동으로 조작, 구성 및 유효성 검사를 할 수 있는 기능을 제공한다.\n이를 통해 [`kustomize`](https://kustomize.io) 같은 도구를 사용하는 고급 구성 사용자들이, \n공개 차트를 포크하거나 차트 유지관리자에게 소프트웨어에 대한\n모든 최종 구성옵션을 지정하도록 요구하지 않고도\n구성 변경사항을 적용할 수 있도록 해준다. 또한 엔터프라이즈 환경이나\n배포 전 매니페스트 분석시에 공통 도구와 사이트카를 주입하는\n사용 사례도 있다.\n\n### 전제 조건\n- 헬름 버전 3.1 이상\n\n### 사용법\n포스트 렌더러는 STDIN 에서 렌더링된 쿠버네티스 매니페스트를 받고\nSTDOUT 으로 유효한 쿠버네티스 매니페스트를 반환하는 실행파일이면 된다.\n실패 시에는 0이 아닌 종료 코드를 반환해야 한다. \n이것은 두 구성 요소 사이의 유일한 \"API\" 이다. \n이러한 구조는 포스트 렌더 프로세스로 수행할 수 있는 작업에 유연성을 제공한다.\n\n포스트 렌더러는 `install`, `upgrade`, `template` 과 함께 사용할 수 있다. 포스트 \n렌더러를 사용하려면 렌더러 실행파일의 경로와 함께 \n`--post-renderer` 플래그를 사용한다.\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\n경로에 구분자가 없으면 $PATH 에서 검색하고, 그렇지 않으면 상대경로를 \n완전한 전체 경로로 풀어낸다.\n\n여러 개의 포스트 렌더러를 사용하려면 스크립트에서 모두 호출하거나 빌드한 \n바이너리 도구에서 함께 호출해야 한다. bash의 경우, \n`renderer1 | renderer2 | renderer3` 와 같이 간단하게 표현할 수 있다.\n\n`kustomize` 를 포스트 렌더러로 사용하는 예는\n[이곳](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render)에서 확인할 수 있다.\n\n### 주의사항\n포스트 렌더러를 사용할 때 유의해야 하는 몇 가지 중요한 사항들이 있다.\n포스트 렌더러를 사용할 때 가장 중요한 것은, 해당 릴리스를 \n수정하는 모든 사람들이 반복 가능한 빌드를 갖기 위해서는 **반드시** 동일한 \n렌더러를 사용해야 한다는 것이다. 이 기능은 사용자가 사용 중인 \n렌더러를 전환하거나 렌더러 사용을 중지할 수 있게 하려고 만들어졌지만 \n우발적인 수정이나 데이터 손실을 방지하기 위해서는 신중하게 수행해야 한다.\n\n또 다른 중요한 사항은 보안에 관한 것이다. 포스트 렌더러를 사용하는 \n경우 다른 임의의 실행 파일의 경우와 마찬가지로 신뢰할 수 있는 \n소스에서 가져온 것인지 확인해야 한다. 신뢰할 수 없거나 확인되지 \n않은 렌더러를 사용하는 것은 종종 시크릿 데이터를 포함하는 렌더링 \n된 템플릿에 대한 전체 접근 권한을 갖게 되므로 권장되지 않는다.\n\n### 사용자 정의 포스트 렌더러\n포스트 렌더러 단계는 Go SDK에서 사용할 때 훨씬 더 많은 유연성을 제공한다.\n모든 포스트 렌더러는 다음 Go 인터페이스만 구현하면 된다.\n\n```go\ntype PostRenderer interface {\n    // Run 함수는 헬름 렌더링 매니페스트로 채워진 단일 버퍼가 필요하다. \n    // 수정된 결과가 별도의 버퍼에 반환되거나 포스트 렌더링 단계를 실행하는 \n    // 동안 이슈나 실패가 발생한 경우 오류가 반환된다.\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nGo SDK 사용에 대한 자세한 내용은 [Go SDK 섹션](#go-sdk)를 참조하자.\n\n## Go SDK\n헬름 3는 헬름을 활용하는 소프트웨어 및 도구를 \n빌드할 때 더 나은 경험을 제공하기 위해 완전 \n재구성된 Go SDK를 선보였다. \n전체 문서는 [Go SDK 섹션](/sdk/gosdk.md)에서 \n찾을 수 있으며, 가장 일반적인 패키지 중 일부와 간단한 예제는 다음과 같다.\n\n### 패키지 개요\n다음은 가장 널리 사용되는 패키지들의 목록과\n그에 관한 간단한 설명이다.\n\n- `pkg/action`: 헬름 작업을 수행하기 위한 기본 \"클라이언트\"를 \n  포함해야 한다. 이것은 CLI가 내부적으로 사용하는 것과 \n  동일한 패키지이다. 다른 Go 프로그램에서 기본 헬름 명령어만 \n  수행하고자 하는 경우 이 패키지가 적합하다.\n- `pkg/{chart,chartutil}`: 차트를 로드하고 조작하는데 사용되는 메서드 및 \n  헬퍼이다.\n- `pkg/cli` 및 해당 하위 패키지: 표준 헬름 환경 변수에 대한 모든 \n  핸들러를 포함하고 하위 패키지에는 출력 및 값 파일 \n  처리를 포함한다.\n- `pkg/release`: `Release` 오브젝트 및 상태를 정의한다.\n\n이 외에도 더 많은 패키지가 있으므로, 자세한 내용은 설명서를 확인하자!\n\n### 간단한 예\n다음은 Go SDK를 사용하여 `helm list` 를 수행하는 간단한 예이다.\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n## 스토리지 백엔드 {#storage-backends}\n\n헬름 3는 기본 릴리스 정보 저장소를 릴리스의 네임스페이스에서 \n시크릿으로 변경하였다. 헬름 2는 기본적으로 릴리스 정보를 \n틸러(Tiller) 인스턴스 네임스페이스의 컨피그맵으로 저장한다. \n다음 하위 섹션에서는 다양한 백엔드를 구성하는 방법을 보여준다. \n이 구성은 `HELM_DRIVER` 환경 변수를 기반으로 한다. \n값은 `[configmap, secret, sql]` 중 하나로 설정될 수 있다.\n\n### 컨피그맵 스토리지 백엔드\n\n컨피그맵 백엔드를 활성화 하려면 환경 변수를 `HELM_DRIVER` 에서 `configmap` 로 \n설정해야 한다.\n\n다음과 같이 셸에서 설정할 수 있다.\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\n기본 백엔드에서 컨피그맵 백엔드로 전환하려면 \n직접 마이그레이션을 수행해야 한다. 다음 명령어를 \n사용하여 릴리스 정보를 검색할 수 있다.\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**운영 참고사항**: 출시 정보에는 무단 접근으로부터 \n보호해야 하는 민감한 데이터(예: 비밀번호, 개인키 및 \n기타 자격증명)가 포함될 수 있다. 예를 들어 \n[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 \n사용하여 쿠버네티스 인증을 관리할 때 컨피그맵 \n리소스에 대한 광범위한 접근 권한을 부여하는 \n동시에 시크릿 리소스에 대한 접근을 제한할 수 있다.\n예를 들어 기본 [사용자 대면 역할](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) 보기 \n권한은 대부분의 리소스에 접근 권한을 부여하지만, 보안 시크릿에는 부여하지 않는다. \n또한 [암호화 된 저장소](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)에 \n대해 시크릿 데이터를 구성할 수 있다.\n컨피그맵 백엔드로 전환하기로 결정한 경우 애플리케이션의 민감한 데이터가 노출될 수 있으므로 유의해야 한다.\n\n### SQL 스토리지 백엔드\n\nSQL 데이터베이스에 릴리스 정보를 저장하는 ***베타*** SQL \n스토리지 백엔드가 있다.\n\n이러한 스토리지 백엔드는 릴리스 정보의 무게가 1MB를 초과하는 경우에 사용하면 \n특히 유용하다. (이 경우 쿠버네티스의 기본 etcd 키-값 저장소의 \n내부 제한으로 인해 컨피그맵/시크릿에 저장할 수 없다.)\n\nSQL 백엔드를 활성화하려면 SQL 데이터베이스를 배포하고 환경변수 \n`HELM_DRIVER` 에서 `sql` 로 설정해야 한다. DB 세부 정보는 \n환경변수 `HELM_DRIVER_SQL_CONNECTION_STRING` 으로 설정된다.\n\n다음과 같이 셸에서 설정할 수 있다.\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> 참고: 현재 PostgreSQL 만 지원된다.\n\n**운영 참고사항**: 다음을 권장한다.\n- 운영 데이터베이스를 준비하자. PostgreSQL에 대한 자세한 내용은 [서버 관리](https://www.postgresql.org/docs/12/admin.html) 문서를 참조하자.\n- 릴리스 정보를 위해 쿠버네티스 RBAC를 미러링하도록 [권한 관리](/topics/permissions_sql_storage_backend.md)를 \n활성화하자.\n\n기본 백엔드에서 SQL 백엔드로 전환하려면 \n직접 마이그레이션을 수행해야 한다. 다음 \n명령어를 통해 릴리스 정보를 검색할 수 있다.\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: 헬름 아키텍처\ndescription: 헬름 아키텍처를 개괄적으로 설명한다.\nsidebar_position: 8\n---\n\n# 헬름 아키텍처\n\n이 문서에서는 헬름 아키텍처를 개괄적으로 설명한다.\n\n## 헬름의 목적\n\n헬름은 _차트_라고 하는 쿠버네티스 패키지를 관리하는 도구이다.\n헬름으로 다음과 같은 것들을 할 수 있다.\n\n- 스크래치(scratch)부터 새로운 차트 생성\n- 차트 아카이브(tgz) 파일로 차트 패키징\n- 차트가 저장되는 곳인 차트 리포지터리와 상호작용\n- 쿠버네티스 클러스터에 차트 인스톨 및 언인스톨\n- 헬름으로 설치된 차트들의 릴리스 주기 관리\n\n헬름에는 다음과 같은 중요한 3가지 개념이 있다.\n\n1. _차트_는 쿠버네티스 애플리케이션의 인스턴스를 생성하는 데에 필요한 정보의 꾸러미이다.\n2. _설정_은 릴리스 가능한 객체를 생성하기 위해 패키징된 차트로 병합될 수 있는 설정 정보를 가진다.\n3. _릴리스_는 _차트_의 구동중 인스턴스이며, 특정 _설정_이 결합되어 있다.\n\n## 컴포넌트\n\n헬름은 실행프로그램이며, 다음 2가지 부분으로 나누어 구현되었다.\n\n**헬름 클라이언트**는 엔드유저용 명령줄 클라이언트이다.\n이 클라이언트는 다음과 같은 것들을 관장한다.\n\n- 로컬 차트 개발\n- 리포지터리 관리\n- 릴리스 관리\n- 헬름 라이브러리와 인터페이스 제공\n  - 설치할 차트를 전달\n  - 기존 릴리스에 대한 업그레이드 또는 언인스톨 요청\n\n**헬름 라이브러리**는 모든 헬름 동작 수행에 대한 로직을 제공한다.\n쿠버네티스 API 서버에 대한 인터페이스 역할을 하며 다음의 기능들을 제공한다.\n\n- 릴리스를 빌드하기 위해 차트와 설정 결합\n- 쿠버네티스에 차트 설치, 후속 릴리스 객체 제공\n- 쿠버네티스와 상호작용하여 업그레이드 및 언인스톨 수행\n\n단독형 헬름 라이브러리에는 헬름 로직이 캡슐화되어 있어\n다른 클라이언트에서 효과적으로 활용할 수 있다.\n\n## 구현\n\n헬름 클라이언트와 라이브러리는 Go 프로그래밍 언어로 작성되었다.\n\n라이브러리는 쿠버네티스와 소통하기 위해 쿠버네티스 클라이언트 라이브러리를 사용한다.\n현재, 라이브러리는 REST+JSON을 사용하며,\n쿠버네티스 내부에 위치한 시크릿(secret) 안에 정보를 저장한다.\n따라서 별도의 데이터베이스가 필요하지 않다.\n\n설정 파일은 가능하면 YAML로 작성한다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: 차트 저장소 가이드\ndescription: Helm 차트 저장소를 만들고 작업하는 방법\nsidebar_position: 6\n---\n\n이 섹션에서는 Helm 차트 저장소를 만들고 작업하는 방법을 설명한다.\n고수준에서 차트 저장소는 패키지형 차트를 저장하고\n공유할 수 있는 장소다.\n\n분산 커뮤니티 Helm 차트 저장소는 [Artifact Hub](https://artifacthub.io/packages/search?kind=0)에\n있으며 참여를 환영한다. 하지만 Helm도 자신만의 차트 저장소를\n만들고 운영할 수 있게 해준다. 이 가이드에서는 그렇게 하는 방법을 설명한다.\n차트 저장소를 만들려고 한다면 대신 [OCI 레지스트리](/topics/registries.md)\n사용을 고려해 볼 수도 있다.\n\n## 전제 조건\n\n* [빠른 시작](/intro/quickstart.md) 가이드 살펴보기\n* [차트](/topics/charts.md) 문서 읽기\n\n## 차트 저장소 생성\n\n_차트 저장소_ 는 `index.yaml` 파일과 선택적으로 일부\n패키지화된 차트를 저장하는 HTTP 서버다. 차트를 공유할 준비가 되면\n차트 저장소에 업로드하는 것이 가장 선호되는 방법이다.\n\nHelm 2.2.0부터 저장소에 대한 클라이언트 측 SSL 인증이 지원된다.\n다른 인증 프로토콜은 플러그인으로 사용할 수 있다.\n\n차트 저장소는 YAML과 tar 파일을 서비스할 수 있고\nGET 요청에 응답할 수 있는 모든 HTTP 서버가 될 수 있기 때문에,\n자신만의 차트 저장소를 호스팅하는 것에 관한 한 수많은 옵션이 있다.\n예를 들어 Google Cloud Storage(GCS) 버킷, Amazon S3 버킷, GitHub Pages를\n사용하거나 직접 웹 서버를 만들 수도 있다.\n\n### 차트 저장소 구조\n\n차트 저장소는 패키지형 차트와 저장소에 있는 모든 차트의 인덱스를 가진 `index.yaml` 이라는\n특수 파일로 구성된다. 종종 `index.yaml` 에 기술된 차트도\n[출처 파일](/topics/provenance.md)처럼 동일한 서버에서\n호스팅된다.\n\n예를 들어, 저장소 `https://example.com/charts` 의 레이아웃은\n다음과 같을 수 있다:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\n이 경우에는 인덱스 파일에 하나의 차트, 즉 Alpine 차트에 대한 정보가 포함되며,\n해당 차트에 대한 다운로드 URL\n`https://example.com/charts/alpine-0.1.2.tgz` 을 제공한다.\n\n차트 패키지가 `index.yaml` 파일과 동일한 서버에 위치할 필요는 없다.\n하지만 그렇게 하는 것이 종종 가장 쉽다.\n\n### 인덱스 파일\n\n인덱스 파일은 `index.yaml` 이라는 yaml 파일이다. 차트의\n`Chart.yaml` 파일의 내용을 포함하여 패키지에 대한 메타데이터가\n포함되어 있다. 적합한 차트 저장소는 인덱스 파일이 있어야 한다.\n인덱스 파일에는 차트 저장소의 각 차트에 대한 정보가 들어 있다.\n`helm repo index` 명령은 패키지형 차트를 포함하는 지정된\n로컬 디렉토리를 기반으로 인덱스 파일을 생성한다.\n\n인덱스 파일의 예:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## 차트 저장소 호스팅\n\n이 절은 차트 저장소를 서비스하는 몇 가지 방법을 보여준다.\n\n### Google Cloud Storage\n\n첫 번째 단계는 **GCS 버킷 만들기**다. `fantastic-charts` 라고 부를 것이다.\n\n![GCS 버킷 생성](/img/helm2/create-a-bucket.png)\n\n다음으로, **버킷 권한을 수정**하여 버킷을 공개하자.\n\n![권한 수정](/img/helm2/edit-permissions.png)\n\n**버킷을 공개하기 위해** 다음 줄을 넣자:\n\n![버킷 공개](/img/helm2/make-bucket-public.png)\n\n축하한다, 이제 차트를 서비스할 빈 GCS 버킷이 준비되었다!\n\nGoogle Cloud Storage 명령줄 도구 또는 GCS 웹 UI를 사용하여 차트\n저장소를 업로드할 수 있다. 공용 GCS 버킷은 `https://bucket-name.storage.googleapis.com/`\n주소로 간단한 HTTPS를 통해 접근할 수 있다.\n\n### Cloudsmith\n\nCloudsmith를 사용하여 차트 저장소를 설정할 수도 있다. Cloudsmith가 있는\n차트 저장소에 대한 자세한 내용은\n[여기](https://help.cloudsmith.io/docs/helm-chart-repository)를 참조하자.\n\n### JFrog Artifactory\n\nJFrog Artifactory를 사용하여 차트 저장소를 만들 수도 있다. JFrog Artifactory가 있는\n차트 저장소에 대한 자세한 내용은\n[여기](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)를 참조하자.\n\n### GitHub Pages 예제\n\n비슷한 방법으로 GitHub Pages를 사용하여 차트 저장소를 만들 수 있다.\n\nGitHub은 두 가지 방법으로 정적 웹 페이지를 서비스할 수 있도록 한다:\n\n- `docs/` 디렉토리의 내용을 서비스하도록 프로젝트를 설정\n- 특정 브랜치를 서비스하도록 프로젝트를 설정\n\n두 번째 방법을 택할 것이지만, 첫 번째 방법도 똑같이 쉽다.\n\n첫 번째 단계는 **gh-pages 브랜치를 만드는** 것이다. 로컬에서 만들 수 있다:\n\n```console\n$ git checkout -b gh-pages\n```\n\nGitHub 저장소의 **Branch** 버튼을 눌러 웹 브라우저를 통해 만들 수도 있다:\n\n![GitHub Pages 브랜치 생성](/img/helm2/create-a-gh-page-button.png)\n\n그런 다음 **gh-pages 브랜치**가 GitHub Pages로 설정되어 있는지\n확인하고, 저장소의 **Settings**를 클릭한 다음 **GitHub Pages** 섹션으로\n스크롤하여 아래와 같이 설정하자:\n\n![GitHub Pages 브랜치 설정](/img/helm2/set-a-gh-page.png)\n\n기본적으로 **Source**는 **gh-pages 브랜치**로 설정된다. 기본적으로 설정되어 있지\n않으면 선택하자.\n\n원한다면 거기서 **사용자 지정 도메인(custom domain)** 을 사용할 수 있다.\n\n그리고 차트를 서비스할 때 **HTTPS**가 사용되도록 **Enforce HTTPS**가 선택되어\n있는지 확인하자.\n\n이러한 설정에서 기본 브랜치를 사용하여 차트 코드를 저장하고\n**gh-pages 브랜치**를 차트 저장소로 사용할 수 있다.\n예: `https://USERNAME.github.io/REPONAME`. 데모 [TS Charts](https://github.com/technosophos/tscharts)\n저장소는 `https://technosophos.github.io/tscharts/` 에서\n접근할 수 있다.\n\nGitHub Pages를 사용하여 차트 저장소를 호스팅하기로 결정했다면\n[Chart Releaser Action](/howto/chart_releaser_action.md)을 확인하자.\nChart Releaser Action은 [helm/chart-releaser](https://github.com/helm/chart-releaser)\nCLI 도구를 사용하여 GitHub 프로젝트를 자체 호스팅 Helm 차트 저장소로 전환하는\nGitHub Action 워크플로우다.\n\n### 일반 웹 서버\n\nHelm 차트를 서비스하도록 일반 웹 서버를 설정하려면\n다음 작업만 수행하면 된다:\n\n- 서버가 서비스할 수 있는 디렉토리에 인덱스 및 차트 저장\n- 인증 요구 사항 없이 `index.yaml` 파일에 접근할 수\n  있는지 확인\n- `yaml` 파일이 올바른 내용 유형(`text/yaml` 또는 `text/x-yaml`)과 함께 서비스되는지\n  확인\n\n예를 들어, `$WEBROOT/charts` 에서 차트를 서비스하려면\n웹 루트에 `charts/` 디렉토리가 있는지 확인하고 인덱스 파일과\n차트를 해당 폴더 안에 넣자.\n\n### ChartMuseum 저장소 서버\n\nChartMuseum은 Go 언어로 작성된 오픈소스 Helm 차트 저장소 서버로,\n[Google Cloud Storage](https://cloud.google.com/storage/), [Amazon\nS3](https://aws.amazon.com/s3/), [Microsoft Azure Blob\nStorage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba\nCloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object\nStorage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud\nInfrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud\nBOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object\nStorage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean\nSpaces](https://www.digitalocean.com/products/spaces/),\n[Minio](https://min.io/), [etcd](https://etcd.io/)를 포함한 클라우드 스토리지\n백엔드를 지원한다.\n\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\n서버를 사용하여 로컬 파일 시스템에서\n차트 저장소를 호스팅할 수도 있다.\n\n### GitLab Package Registry\n\nGitLab을 사용하면 프로젝트의 Package Registry에 Helm 차트를 게시할 수 있다.\nGitLab에서 Helm 패키지 저장소를 설정하는 방법에 대한 자세한 내용은\n[여기](https://docs.gitlab.com/ee/user/packages/helm_repository/)를 참조하자.\n\n## 차트 저장소 관리\n\n차트 저장소가 생겼으니 이 가이드의 마지막 부분에서는 해당 저장소에서 차트를\n유지하는 방법을 설명한다.\n\n\n### 차트 저장소에 차트 저장\n\n차트 저장소가 생겼으니 차트와 인덱스 파일을 저장소에\n업로드하자. 차트 저장소의 차트는\n올바르게 패키징하고(`helm package chart-name/`) 버전([SemVer 2](https://semver.org/)\n가이드라인에 따라)이 제공되어야 한다.\n\n다음 단계는 예제 워크플로우를 구성하지만, 차트\n저장소에 차트를 저장하고 갱신하는 데 원하는\n워크플로우를 모두 사용해도 좋다.\n\n패키지형 차트가 준비되면 새 디렉토리를 만들고\n패키지형 차트를 해당 디렉토리로 이동시키자.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\n마지막 명령은 방금 생성한 로컬 디렉토리의 경로와\n원격 차트 저장소의 URL을 사용하여 지정된 디렉토리\n경로 내에 `index.yaml` 파일을 구성한다.\n\n이제 동기화 도구를 사용하거나 수동으로 차트 저장소에\n차트 및 인덱스 파일을 업로드할 수 있다. Google Cloud Storage를\n사용하는 경우 gsutil 클라이언트를 사용하는 이 [예제 워크플로우](/howto/chart_repository_sync_example.md)를\n확인하자. GitHub의 경우 해당 목적지 브랜치에 차트를 간단히 넣을 수 있다.\n\n### 기존 저장소에 새로운 차트 추가\n\n저장소에 새로운 차트를 추가할 때마다 인덱스를 재생성해야 한다.\n`helm repo index` 명령은 로컬에서 찾은 차트만 포함하여\n`index.yaml` 파일을 처음부터 완전히 재구성한다.\n\n그러나 `--merge` 플래그를 사용하여 새 차트를 기존 `index.yaml` 파일(GCS와 같은\n원격 저장소로 작업할 때 유용한 옵션)에 점진적으로 추가할 수 있다. 자세히 알아보려면\n`helm repo index --help`를 실행하자.\n\n수정된 `index.yaml` 파일과 차트를 모두 업로드하자. 그리고 출처 파일을 생성했다면\n그것도 업로드하자.\n\n### 다른 사람과 차트 공유\n\n차트를 공유할 준비가 되면 다른 사람에게\n저장소의 URL을 알려주자.\n\n그들은 저장소를 조회하기 위해 사용하고자 하는\n이름과 `helm repo add [NAME] [URL]` 명령을 통해\n저장소를 Helm 클라이언트에 추가할 것이다.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n차트가 HTTP 기본 인증을 지원할 경우 사용자 이름과 암호도 제공할 수 있다:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**참고:** 저장소에 유효한 `index.yaml`이 포함되어 있지 않으면 저장소가 추가되지 않는다.\n\n**참고:** Helm 저장소가 자체 서명된 인증서를 사용하는 경우\nCA 검증을 건너뛰기 위해서\n`helm repo add --insecure-skip-tls-verify ...` 를 사용할\n수 있다.\n\n그 후에 사용자들은 당신의 차트를 검색할 수 있을 것이다.\n저장소를 업데이트한 후에는 사용자들이 `helm repo update` 명령을\n사용하여 최신 차트 정보를 가져올 수 있다.\n\n*내부에서 `helm repo add` 및 `helm repo update` 명령은\nindex.yaml 파일을 가져와 `$XDG_CACHE_HOME/helm/repository/cache/` 디렉토리에\n저장한다. 여기는 `helm search` 기능이\n차트에 대한 정보를 찾는 곳이다.*\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: 차트 테스트\ndescription: 차트를 실행하고 테스트하는 방법을 설명한다.\nsidebar_position: 3\n---\n\n차트에는 함께 작동하는 여러 쿠버네티스 리소스 및 구성요소가 포함되어\n있다. 차트 작성자는 차트가 설치될 때 예상대로 작동하는지 확인하는 몇 가지\n테스트를 작성할 수 있다. 이러한 테스트는 차트 사용자가 차트에 따라 수행될\n작업을 이해하는 데에도 도움이 된다.\n\n헬름 차트의 **테스트**는 `templates/` 디렉토리에 있으며 실행하기 위해\n주어진 명령어로 컨테이너를 지정하는 작업 정의이다. 테스트가 성공한 것으로\n판정되려면 컨테이너가 성공적으로 종료되어야 한다(exit 0). 작업 정의에는\n헬름 테스트 훅 어노테이션(`helm.sh/hook: test`)이 반드시 포함되어야 한다.\n\n헬름 v3까지는, 작업 정의에 `helm.sh/hook: test-success` 또는 `helm.sh/hook: test-failure`와\n같은 헬름 테스트 훅 어노테이션 중 하나가 포함되어야 했다.\n`helm.sh/hook: test-success`는 여전히 `helm.sh/hook: test`과\n하위 호환되는 대안으로 허용된다.\n\n예제 테스트:\n\n- values.yaml 파일의 구성이 제대로 삽입되었는지 확인\n  - 사용자 이름과 비밀번호가 올바르게 작동하는지 확인\n  - 잘못된 사용자 이름과 비밀번호가 작동하지는 않는지 확인\n- 서비스가 작동하고 올바르게 로드 밸런싱되는지 확인\n- 기타\n\n`helm test <RELEASE_NAME>` 명령어를 사용하여 헬름에서 릴리스에 대한 사전\n정의된 테스트를 실행할 수 있다. 이렇게 하면 차트 사용자가 차트(또는 애플리케이션)의 릴리스가\n기대한대로 작동하는지 확인할 수 있다.\n\n## 예제 테스트\n\n[helm create](/helm/helm_create.md) 명령어는 자동으로 여러 폴더와 파일을 생성한다. 헬름 테스트 기능을 사용해 보려면 먼저 데모 헬름 차트를 생성한다.\n\n```console\n$ helm create demo\n```\n\n이제 데모 헬름 차트에서 다음과 같은 구조를 볼 수 있다.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\n`demo/templates/tests/test-connection.yaml`에서 테스트를 확인할 수 있다. 다음은 헬름 테스트 파드 정의이다:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## 릴리스에서 테스트 스위트를 실행하는 단계\n\n먼저 클러스터에 차트를 설치하여 릴리스를 만든다. 모든 파드가\n활성화될 때까지 기다려야 할 수도 있다. 설치 직후 바로 테스트하는 경우,\n일시적인 오류가 발생할 수도 있고, 다시 테스트해야 할 수도 있다.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## 참고\n\n- 테스트를 정의할 때는 단일 yaml 파일에 하거나 또는 `templates/` 디렉토리의 여러\n  yaml 파일에 분산하여 할 수도 있다.\n- 따로 분리하기 위해 `<차트-이름>/templates/tests/`와 같은 `tests/` 디렉토리 아래에\n  테스트 스위트를 넣어둘 수도 있다.\n- 테스트는 [헬름 훅](/topics/charts_hooks.md)이므로,\n  `helm.sh/hook-weight`나 `helm.sh/hook-delete-policy`와 같은 어노테이션을 테스트\n  리소스와 함께 사용할 수 있다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: 차트\ndescription: 차트 형식을 설명하고, 헬름으로 차트를 빌드하기 위한 기본지침을 제공한다.\nsidebar_position: 1\n---\n\n헬름은 *charts* 라는 패키지 포맷을 사용한다. 차트는 쿠버네티스 리소스와\n관련된 셋을 설명하는 파일의 모음이다. 하나의 차트는 memcached 파드를\n배포하는 것처럼 단순한 형태나 HTTP 서버, 데이터베이스, 캐시 등으로\n구성된 완전한 웹앱 같이 복잡한 형태로 사용될수 있다.\n\n차트는 특정한 디렉터리 구조를 가진 파일들로 생성된다. 이 파일들은\n배포할 버전이 지정된 아카이브로 패키지화 될 수 있다. \n\n설치하지 않고 공개된 차트를 다운로드 받거나 보기 위해,\n`helm pull chartrepo/chartname` 명령을 사용할 수 있다.\n\n이 문서는 차트 형식을 설명하고, 차트를 헬름으로 구성하는\n기본 가이드를 제공한다.\n\n## 차트 파일 구조\n\n차트는 디렉터리 안에 파일들의 모음으로 구성된다. 디렉터리명은\n(버전 정보 없는) 차트명이다. 따라서,\nWordPress 를 설명하는 차트는 `wordpress/` 디렉터리에 저장된다.\n\n디렉터리 안에서 헬름은 다음과 같은 구조를 가진다.\n\n```text\nwordpress/\n  Chart.yaml          # 차트에 대한 정보를 가진 YAML 파일\n  LICENSE             # 옵션: 차트의 라이센스 정보를 가진 텍스트 파일\n  README.md           # 옵션: README 파일\n  values.yaml         # 차트에 대한 기본 환경설정 값들\n  values.schema.json  # 옵션: values.yaml 파일의 구조를 제약하는 JSON 파일\n  charts/             # 이 차트에 종속된 차트들을 포함하는 디렉터리\n  crds/               # 커스텀 자원에 대한 정의\n  templates/          # values와 결합될 때, 유효한 쿠버네티스 manifest 파일들이 생성될 템플릿들의 디렉터리\n  templates/NOTES.txt # 옵션: 간단한 사용법을 포함하는 텍스트 파일\n```\n\n헬름은 `charts/`, `crds/`, `templates/` 디렉터리와 나열된 파일명의 사용을\n예약한다. 다른 파일들은 그대로 남는다.\n\n## Chart.yaml 파일 {#the-chartyaml-file}\n\n`Chart.yaml` 파일은 차트의 필수 요소이다. 다음과 같은 필드를 포함한다.\n\n```yaml\napiVersion: 차트 API 버전 (필수)\nname: 차트명 (필수)\nversion: SemVer 2 버전 (필수)\nkubeVersion: 호환되는 쿠버네티스 버전의 SemVer 범위 (선택)\ndescription: 이 프로젝트에 대한 간략한 설명 (선택)\ntype: 차트 타입 (선택)\nkeywords:\n  - 이 프로젝트에 대한 키워드 리스트 (선택)\nhome: 프로젝트 홈페이지의 URL (선택)\nsources:\n  - 이 프로젝트의 소스코드 URL 리스트 (선택)\ndependencies: # 차트 필요조건들의 리스트 (optional)\n  - name: 차트명 (nginx)\n    version: 차트의 버전 (\"1.2.3\")\n    repository: 저장소 URL (\"https://example.com/charts\") 또는 (\"@repo-name\")\n    condition: (선택) 차트들의 활성/비활성을 결정하는 boolean 값을 만드는 yaml 경로 (예시: subchart1.enabled)\n    tags: # (선택)\n      - 활성화 / 비활성을 함께하기 위해 차트들을 그룹화 할 수 있는 태그들\n    enabled: (선택) 차트가 로드될수 있는지 결정하는 boolean\n    import-values: # (선택)\n      - ImportValues 는 가져올 상위 키에 대한 소스 값의 맵핑을 보유한다. 각 항목은 문자열이거나 하위 / 상위 하위 목록 항목 쌍일 수 있다.\n    alias: (선택) 차트에 대한 별명으로 사용된다. 같은 차트를 여러번 추가해야할때 유용하다.\nmaintainers: # (선택)\n  - name: maintainer들의 이름 (각 maintainer마다 필수)\n    email: maintainer들의 email (각 maintainer마다 선택)\n    url: maintainer에 대한 URL (각 maintainer마다 선택)\nicon: 아이콘으로 사용될 SVG나 PNG 이미지 URL (선택)\nappVersion: 이 앱의 버전 (선택). SemVer인 필요는 없다.\ndeprecated: 차트의 deprecated 여부 (선택, boolean)\nannotations:\n  example: 키로 매핑된 주석들의 리스트 (선택).\n```\n\n[v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2) 버전부터 추가 필드는 허용되지 않습니다. 권장되는 방식은 `annotations`에 사용자 정의 메타데이터를 추가하는 것입니다.\n\n### 차트와 버저닝\n\n모든 차트는 버전 번호를 가져야한다. 버전은 [SemVer2](https://semver.org/spec/v2.0.0.html)\n표준을 따라야 한다. 이전 헬름과 다르게,\n헬름 v2 이상은 버전 번호를 release 마커로 사용한다.\n저장소에 있는 패키지들은 이름과 버전으로 구분된다.\n\n예를 들어, 버전 필드가 `version: 1.2.3` 으로 설정된 `nginx` 차트는\n다음같이 이름이 지어진다. \n\n```text\nnginx-1.2.3.tgz\n```\n\n`version:1.2.3-alpha.1+ef365` 같은 더 복잡한 SemVer 2\n이름도 지원된다. SemVer가 아닌 이름은 시스템에 의해\n명백하게 허용되지 않습니다. 예외적으로 `x` 또는 `x.y` 형식의 버전은 허용됩니다.\n예를 들어, 앞에 v가 붙거나 세 부분이 모두 없는 버전(예: v1.2)은\n유효한 시맨틱 버전(예: v1.2.0)으로 변환하려고 시도합니다.\n\n**참고:** 헬름 클래식과 배포 매니저는 둘다 깃허브를\n지향한 차트였지만, 헬름 v2와 이후 버전은 깃허브나 깃에\n의존하지도, 필요로 하지도 않는다. 따라서 깃 SHA 값의 버전관리에서는 모두\n사용하지 않는다.\n\n`Chart.yaml` 의 안에 있는 `version` 필드는 CLI를 포함한\n많은 헬름 툴에서 사용된다. 패키지를 생성할 때,\n`helm package` 명령은 `Chart.yaml` 에서 찾은 버전을\n패키지 이름에 있는 토큰으로 사용한다. 시스템은 차트\n패키지명 안의 버전 번호가 `Chart.yaml` 안의 버전 번호와\n일치한다고 가정한다. 이 가정을 충족하지 못하면 에러가 발생한다.\n\n### `apiVersion` 필드\n\n`apiVersion` 필드는 최소 헬름 3을 필요로 하는 헬름 차트에\n대해 `v2` 여야 한다. 이전 헬름 버전을 지원하는 차트는\n`apiVersion` 이 `v1` 으로 설정되어 있고, 헬름 3에 의해 여전히 설치 가능하다.\n\n`v1` 에서 `v2` 로 변경하기:\n\n- 종속성을 정의하는 `dependencies`필드는 `v1` 차트를 위한\n  독립된 `requirements.yaml` 파일에 위치([Chart\n  Dependencies](#차트-의존성) 보기).\n- `type`필드는 어플리케이션과 라이브러리 차트를\n  식별([ChartTypes](#차트-타입) 보기)\n\n### `appVersion` 필드\n\n`appVersion` 필드는 `version` 필드와 관련이 없음을 주의하라. 이 필드는\n어플리케이션의 버전을 명시하는 방법이다. 예를 들어, `drupal` 차트가\n`appVersion: 8.2.1` 을 가진다면, 차트에 (기본값으로) 포함되는 Drupal의\n버전은 `8.2.1`임을 나타낸다. 이 필드는 정보만 제공하고,\n차트 버전 계산에 영향이 없다. 버전을 따옴표로 감싸는 것을 매우\n권장한다. 이것은 YAML 파서가 버전 번호를 string으로 다루게 한다. 따옴표 없이\n남기면 몇몇의 경우에 파싱 문제가 생길 수 있다. 예를 들어, YAML은 `1.0` 을\n소숫점으로, `1234e10` 같은 깃 커밋 SHA를 과학적 기수법으로 해석한다.\n\n현재 헬름 v3.5.0에서, `helm create`는 기본값으로 `appVersion` 필드를 따옴표로 감싼다.\n\n### `kubeVersion` 필드\n\n선택 필드인 `kubeVersion` 은 지원되는 쿠버네티스 버전에 대한\nsemver 제약 조건을 정의할 수 있다. 헬름은 차트를 설치할 때 버전 제약을 판단하고,\n클러스터가 지원되지 않는 쿠버네티스 버전을 구동하면 실패한다.\n\n버전 제약은 공백으로 분리된 AND 비교로 다음과 같이 구성된다.\n```\n>= 1.13.0 < 1.15.0\n```\n다음 예제와 같이 표현 각각은 OR `||` 연산과\n결합될 수 있다.\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\n이 예제에서 버전 `1.14.0` 은 제외되어, 특정 버전의 버그가\n차트를 제대로 실행하지 못하게 하는 것으로 이해할 수 있다. \n\n버전 제약에 사용하는 `=` `!=` `>` `<` `>=` `<=` 연산 외에도,\n다음 약칭 표기법이 지원된다.\n\n * 닫힌 간격에 대한 하이픈 범위, `1.1 - 2.3.4` 는 `>=1.1 <= 2.3.4` 와\n   동일하다.\n * 와일드카드 `x`, `X` ,`*`, 예를 들어 `1.2.x` 는 `>= 1.2.0 < 1.3.0` 와\n   동일하다.\n * 물결 범위 (패치 버전 변화는 허용), `~1.2.3`는 `>= 1.2.3 < 1.3.0` 와\n   동일하다.\n * 탈자 범위 (마이너 버전 변화는 허용), `^1.2.3` 는`>= 1.2.3 < 2.0.0` 와\n   동일하다.\n\n지원되는 유의적 버전 제약의 상세한 표현은\n[Masterminds/semver](https://github.com/Masterminds/semver)에서 확인한다.\n\n### 미사용 예정 차트\n\n차트 저장소에서 차트를 관리할 때, 가끔 차트를 미사용 예정으로 표시하는 것이\n필요하다. `Chart.yaml` 에 있는 선택 필드인 `deprecated` 는 차트가 미사용\n예정임을 표시하는데 사용될 수 있다. 저장소에 있는 차트의 **최신** 버전이\n미사용 예정으로 표시 된다면, 차트는 전체가 미사용 예정이라고 판단한다.\n미사용 예정을 체크하지 않은 새로운 버전을 발행함으로써 차트명을\n이후에 재사용 할 수 있습니다. 차트를 미사용 예정으로 만드는 작업흐름은 다음과 같습니다:\n\n1. 차트의 `Chart.yaml` 를 업데이트 하여 차트를 미사용 예정으로 표시하여\n   버전을 올린다.\n2. 차트 저장소에 새로운 차트 버전을 발행한다.\n3. 차트를 소스 저장소에서 삭제한다 (예. git)\n\n### 차트 타입\n\n`type` 필드는 차트의 타입을 정의한다. `application`, `library` 의\n두가지 타입이 있다. Application은 기본 타입이며\n온전하게 작동할 수 있는 표준 차트이다.\n[library chart](/topics/library_charts.md) 는 차트 빌더에\n유틸리티나 함수를 제공한다. library chart는 설치가 불가능하고, 보통\n어떤 리소스 오브젝트도 갖지 않는다는 점에서 application chart와는 다르다.\n\n**참고:** application chart는 library chart로 사용될 수 있다. 타입을\n`library` 로 설정하여 활성화 한다. 차트는 모든 유틸리티와\n함수 기능을 활용할 수 있는 상태의 library chart로 렌더링된다. 차트의\n모든 리소스 오브젝트는 렌더링되지 않는다.\n\n## 차트 라이센스, README 와 NOTES\n\n차트는 설치, 구성, 사용법, 라이센스를\n설명하는 파일을 가질 수 있다.\n\nLICENSE는 차트에 대한 [license](https://en.wikipedia.org/wiki/Software_license) 를\n포함하는 일반 텍스트 파일이다. 차트는 템플릿 안에서 프로그래밍 로직을\n가지는 것으로써의 라이센스를 포함할 수 있으므로 환경 설정\n전용이 아니다. 필요한 경우, 차트에 의해 설치된 어플리케이션을 위해\n별도의 라이센스로 나눠질 수 있다.\n\n차트에 대한 README는 마크다운(README.md)의 포맷이어야 하며,\n일반적으로 다음을 포함한다.\n\n- 차트가 제공하는 어플리케이션이나 서비스에 관한 설명\n- 차트를 실행하기 위한 전제조건이나 필요조건\n- `values.yaml` 에 있는 옵션과 기본값에 대한 설명\n- 차트의 설치나 환경설정에 관련이 있을 수\n  있는 다른 정보\n\n허브 및 기타 사용자 인터페이스가 `README.md` 파일의 콘텐츠에서\n가져온 차트에 대한 세부 정보를 표시하는 경우\n\n차트는 릴리즈의 상태를 보여줄때와 설치 후에 출력될 짧은 일반 텍스트를\n`template/NOTES.txt` 파일에 적을 수 있다. 이 파일은\n[template](#템플릿과-값)으로 평가되고 사용법 메모, 다음 스텝, 차트의\n릴리즈와 관련된 다른 정보를 표시하기 위해 사용될 수 있다. 예를 들어,\n지시 사항(instructions)은 데이터베이스에 연결하기, 웹 UI에 액세스하기\n등에 대해 제공될 수 있다. 이 파일이 `helm install` 이나 `helm status` 가\n실행될 때 STDOUT으로 출력되기 때문에, 내용을 간단하게 유지하고,\n상세 내용은 README를 참조하도록 하는 것을 권장한다.\n\n## 차트 의존성\n\n헬름에서 하나의 차트는 0개 이상의 다른 차트에 의존한다.\n이 의존성은 `Chart.yaml` 에 `dependencies` 필드를 사용하여 직접 연결되거나\n`charts/` 디렉터리로 가져와서 수동으로 관리할 수 있다.\n\n### `dependencies` 필드를 통해 의존성 관리하기\n\n현재 차트가 필요로 하는 차트들은 `dependencies` 필드에\n리스트로 정의된다.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- `name` 필드는 사용할 차트명이다.\n- `version` 필드는 사용할 차트의 버전이다.\n- `repository` 필드는 차트 저장소의 완전한 URL 이다. 반드시 로컬 환경에서\n  `helm repo add` 를 사용해야 함을 주의하라.\n- URL 대신 저장소의 이름을 사용할 수 있다.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\n일단 종속성을 정의하면, `helm dependency update` 를 실행할 수 있고,\n실행하면 종속성 파일을 사용해서 모든 명시된\n차트를 `charts/` 디렉터리 안에 다운로드 받는다.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\n`helm dependency update` 가 차트를 가져올 때,\n차트 아카이브의 형태로 `charts/` 디렉터리에 저장한다.\n위의 예제 같은 경우, 다음 파일들을 차트 디렉터리에서 볼수 있다.\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### 의존성 안에서의 대체 필드\n\n위에서 본 필드 외에도, 각각의 필요 엔트리는\n선택적 필드인 `alias` 를 가질 수 있다.\n\n종속성 차트에 대한 별명(alias)을  추가하여, dependencies 안에\n새로운 종속성 이름을 별명으로 사용하여 넣게 된다.\n\n다른 이름으로 차트에 엑세스 해야 하는 경우\n`alias` 를 사용할 수 있다.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\n위의 예에서 `parentchart` 에 대해 모두 3개의 종속성을 얻게 된다.\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\n같은 동작을 수동으로 하는 방법은 `charts/` 디렉터리에 같은 차트를 여러번 다른 이름으로\n복사/붙여넣기 하면된다.\n\n#### 의존성 안에서의 태그와 조건 필드\n\n위에서 본 필드 외에도, 각각의 필요 엔트리는 선택필드인\n`tags` 와 `condition` 을 가질 수 있다.\n\n모든 차트는 기본으로 로드된다. `tags` 나 `condition` 필드가\n존재하면, 차트가 적용될지에 대한 로딩 제어를 위해\n사용되고 평가된다.\n\nCondition - condition 필드는 1개 이상의 (콤마로 구분되는)\nYAML 경로이다. 최상단 부모의 values에 이 경로가 존재하고\nboolean 값으로 판단할수 있다면, 차트는 boolean 값에 의해\n활성화 혹은 비활성화 된다. 리스트에서 발견된 유효한 첫번째 경로만이 평가되고,\n이 경로가 존재하지 않으면 해당 condition은 무효하다.\n\nTags - tags 필드는 이 차트와 관련된 레이블의 YAML 리스트이다.\n최상단 부모의 values에서, 태그를 가진 모든 차트는\n특정한 태그와 boolean 값에 의해 활성화 또는 비활성화 된다.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled, global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\n위 예에서 `front-end` 태그를 가진 모든 차트는 비활성화 되지만, 부모의 values에서\n`subchart1.enabled` 가 true로 평가되었기 때문에, condition은 `front-end` 태그를\n덮어쓰고 `subchart1` 은 활성화된다.\n\n`subchart2` 는 `back-end` 와 태그되었고 이 태그는 `true` 로 평가되어서,\n`subchart2` 는 활성화된다. 또한 `subchart2` 가 특정한\ncondition을 가지지만, 부모의 values에 대응되는 경로가 없어서,\n이 condition은 아무 영향이 없다.\n\n##### 태그 및 조건과 함께 CLI 사용\n\n`--set` 파라미터는 보통 tag와 condition 값을 수정할때 사용할 수 있다.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### 태그 및 조건 확인\n\n- **(values에 셋팅된) Condition은 항상 tag를 덮어쓴다.** 존재하는 첫번째 condition 경로가 사용되고 그 차트의 다른 것들은 무시된다.\n- tag는 '어떤 차트의 tag라도 true면 차트를 활성화 시킬것' 으로 평가한다.\n- tag와 condition 값은 최상단 부모의 values에 셋팅되어야 한다.\n- values의 `tags:` 키는 최상단 레벨의 키여야 한다. 전역과 중첩된 `tags:` 테이블은 현재 지원되지 않는다.\n\n#### 의존성을 통해 자식 값 가져오기\n\n몇몇 케이스에서 자식 차트의 values가 부모의 차트에 영향을 미치고\n공통 기본값으로 공유되도록 하고싶을 수 있다. `exports` 포맷을\n사용하는 것의 추가 이점은 향후 도구를 통해 사용자가 설정할수 있는 값을\n가능하게 하는 것이다.\n\nimport 될 값을 포함하는 키는 YAML 리스트를 사용해서 부모 차트의 `dependencies` 안에\n`import-values` 필드로 명시할 수 있다. 리스트의 각 아이템은\n자식 차트의 `exports` 필드로부터 import 되는 키이다.\n\n`exports` 키 안에 포함되지 않은 import value를\n사용하려면, [child-parent](#자식-부모-형식-사용하기) 포맷을 사용하라. 두 포맷 모두\n아래에서 설명한다.\n\n##### 내보내기 형식 사용하기\n\n자식의 `values.yaml` 파일이 루트에 `exports` 필드를 가진다면,\n이 필드의 내용은 다음 예제처럼 import 하기 위한 키를 명시함으로써\n부모의 values에 직접 import 될수 있다.\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\nimport 리스트에 `data` 키를 명시했기 때문에, 헬름은 `data` 키에 대한\n자식 차트의 `exports` 필드를 찾고 그것의 내용을 import 한다.\n\n최종 부모의 values는 export된 필드를 포함한다.\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\n부모의 `data` 키가 부모의 최종 values에 포함되지 않음을 주의하라.\n부모의 키에 명시할 필요가 있다면, 'child-parent' 포맷을 사용하라.\n\n##### 자식-부모 형식 사용하기\n\n자식 차트의 values의 `exports` 키에 포함되지 않은\nvalues에 접근하려면, import될 (자식) values의\n키와 부모 차트의 values (부모)안의 목적지 경로를\n명시해야 한다.\n\n아래의 예제에 있는 `import-values` 는 `child` 경로에서 발견된어떤 값이든 취하고,\n값들을 `parent:` 에 명시된 경로에 부모의 값들로 복사하라고\n헬름에게 지시한다. \n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\n위의 예제에서, subchart1의 값들 안에 `default.data` 에서 발견된\nvalues는 다음과 같이 부모 차트의 values 안의\n`myimports` 키로 import 된다.\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\n부모 차트의 values 결과는 다음과 같다.\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\n부모의 최종 values는 이제 subchart1에서 import된\n`myint` 와 `mybool` 필드를 가진다.\n\n### `charts/` 디렉터리를 통해 수동으로 의존성 관리\n\n더 많은 종속성 제어가 필요하다면,\n이 종속성들은 dependency 차트를 `charts/` 디렉터리로\n복사함으로써 정확하게 표현될 수 있다.\n\n종속성은 압축 해제된 차트 디렉터리여야 하며, 이름은 `_`나 `.`로 시작될 수 없습니다.\n차트 로더가 무시한다.\n\n예를 들어서, WordPress 차트가 Apache 차트에 의존한다면,\n(올바른 버전의) Apache 차트는 WordPress 차트의\n`charts/` 디렉터리 안에 저장된다.\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\n위의 예제는 어떻게 WordPress 차트가 Apache와 MySQL에 대한 의존성을\n표현하는지 `charts/` 디렉터리에 이 차트들을 포함시킴으로써 보여준다.\n\n**팁:** _`charts/` 디렉터리 안에 종속성을 가져오려면,\n`helm pull` 명령을 사용하라._\n\n### 의존성 사용의 운영적 관점\n\n위 섹션은 차트 종속성을 어떻게 명시하는지 설명하지만, `helm install` 과 \n`helm upgrade` 를 사용하는 차트 설치에 어떻게 영향을 미치는가?\n\n\"A\"라는 차트가 다음과 같은 쿠버네티스 오브젝트를 생성한다고 가정하자.\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nA가 오브젝트를 생성하는 B 차트에 의존성을 가진다고 하자.\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\n차트 A의 installation / upgrade 후에, 단일 헬름 릴리즈가 생성 / 수정 된다.\n릴리즈는 다음 순서로 위의 쿠버네티스 오브젝트를 전부를\n생성 / 업데이트한다.\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\n왜냐하면 헬름이 차트를 설치/업그레이드 할때,\n차트와 모든 종속성으로부터 쿠버네티스 오브젝트가\n\n- 단일 집합으로 통합된다.\n- 이름에 따른 타입으로 정렬된다.\n- 그 순서에 의해 생성/업데이트 된다.\n\n이런 이유로 단일 릴리즈는 차트와 종속성에 대한 모든\n오브젝트와 함께 생성된다.\n\n쿠버네티스 타입의 설치 순서는\nkind_sorter.go([the Helm source file](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go))의 열거형 타입 설치 순서에 의해\n제공된다.\n\n## 템플릿과 값\n\n헬름 차트 템플릿은 [sprig 라이브러리](https://github.com/Masterminds/sprig)에서\n50개 정도의 애드온 템플릿 함수와\n몇가지 기타 [특수 함수](/howto/charts_tips_and_tricks.md)가\n추가된 [Go template language](https://golang.org/pkg/text/template/)로\n작성되었다.\n\n모든 템플릿 파일은 차트의 `templates` 디렉터리 안에 저장된다.\n헬름이 차트를 렌더링할때, 템플릿 엔진을 통해 이 디렉터리 안에\n모든 파일을 전달한다.\n\n템플릿에 대한 values는 2가지 방법으로 제공된다.\n\n- 차트 개발자는 차트의 안에 `values.yaml` 이라 부르는 파일을 제공할 수 있다. 이 파일은 기본 값을 포함할 수 있다.\n- 차트 사용자는 값을 포함한 YAML파일을 제공할 수 있다. `helm install` 커맨드 라인으로 제공받을 수 있다.\n\n사용자가 커스텀 값을 제공할 때, 차트의 `values.yaml` 파일에\n있는 값을 덮어쓴다.\n\n### 템플릿 파일\n\n템플릿 파일은 Go 템플릿 작성에 대한 표준 규약을 따른다\n([텍스트/템플릿 Go 패키지 문서](https://golang.org/pkg/text/template/)).\n예제 템플릿 파일은\n다음과 같을 수 있다.\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n([https://github.com/deis/charts](https://github.com/deis/charts)에 느슨하게 결합된) 위의 예는\n쿠버네티스 리플리케이션 컨트롤러에 대한 템플릿이다.\n다음 4가지 템플릿 값을 사용할 수 있다.\n(보통  `values.yaml` 에 정의된다.)\n\n- `imageRegistry`: 도커 이미지의 소스 레지스트리\n- `dockerTag`: 도커 이미지의 태그\n- `pullPolicy`: 쿠버네티스의 pull 정책\n- `storage`: 기본값이 `\"minio\"`로 설정되는 저장소 백엔드\n\n이 모든 값은 템플릿 작성자에 의해 정의된다. 헬름은\n파라미터를 요구하거나 지시하지 않는다.\n\n많은 작동중인 차트를 보려면, [쿠버네티스 차트 프로젝트](https://github.com/helm/charts)를\n참고하라.\n\n### 미리 정의된 값\n\n`values.yaml` 파일 (혹은 `--set` 플래그)로 제공되는 값은 템플릿 안에서\n`.Values` 객체로 접근 가능하다. 그러나 템플릿 안에서 접근 가능한\n다른 미리 정의된 데이터의 조각이 있다.\n\n다음 값은 미리 정의되었고, 모든 템플릿에서 접근 가능하며, 덮어쓸수 없다. 모든 값과\n마찬가지로, 이름은 대소문자를 구별한다.\n\n- `Release.Name`: 릴리즈의 이름(차트의 이름 아님)\n- `Release.Namespace`: 차트가 릴리즈된 네임스페이스\n- `Release.Service`: 릴리즈를 수행하는 서비스\n- `Release.IsUpgrade`: 현재 업그레이드나 롤백중이면 true로 설정된다.\n- `Release.IsInstall`: 현재 설치중이면 true로 설정된다.\n- `Chart`: `Chart.yaml`의 내용. 차트의 버전은 `Chart.Version`으로, 메인테이너는 `Chart.Maintainers`로 얻을 수 있다.\n- `Files`: 차트에 모든 특별하지 않은 파일을 포함하는 맵과 같은 오브젝트입니다. 템플릿에 접근을 제공하지는 않지만, (`.helmignore`로 배제되지 않았다면) 존재하는 추가 파일에 대한 액세스를 제공합니다. 파일은 `{{ index .Files \"file.name\" }}`나 `{{.Files.Get name }}` 함수를 사용해서 접근할 수 있습니다. `{{ .Files.GetBytes }}`를 사용하여 파일 내용을 `[]byte`로 액세스할 수도 있습니다.\n- `Capabilities`: 쿠버네티스의 버전(`{{ .Capabilities.KubeVersion }}`)과 지원되는 쿠버네티스 API 버전 (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)에 대한 정보를 포함하는 맵과 같은 오브젝트입니다.\n\n**주의:** 익명의 `Chart.yaml` 필드는 무시된다. 이 필드는\n`Chart` 오브젝트의 안에서 접근이 불가능하다. 따라서\n`Chart.yaml` 은 템플릿으로 구조화된 데이터를 제멋대로\n전달하기 위해 사용될 수 없다.\n\n### 값 파일\n\n이전 섹션에서의 템플릿을 고려할때, 필수적인 값을 제공하는\n`values.yaml` 은 다음과 같다.\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nvalues 파일은 YAML 포맷이다. 차트는 기본 `values.yaml`\n파일을 포함한다. 헬름 설치 명령은 추가 YAML 값을 제공함으로써\n사용자가 값을 덮어쓸 수 있게한다.\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\n이 방법으로 값이 전달될때, 디폴트 values 파일로 이 값들은 병합된다.\n예를 들어, `myvals.yaml` 파일은 다음과 같다고 하자.\n\n```yaml\nstorage: \"gcs\"\n```\n\n차트의 `values.yaml` 로 병합될때, 생성된 내용의 결과는\n다음과 같다.\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\n오직 마지막 필드가 덮여쓰여짐을 주의하라.\n\n**참고:** 차트의 안에 포함된 디폴트 값 파일은 `values.yaml` 의 이름을 가져야한다. 반면에,\n커맨드 라인에 명시하는 파일은 아무 이름이나 가질 수 있다.\n\n**참고:** `--set` 플래그가  `helm install` 이나 `helm upgrade` 에 사용된다면,\n이 값들은 클라이언트에서 YAML로 간단하게 변환된다.\n\n**참고:** values 파일에 필수적인 엔트리가 있다면, 차트 템플릿에서\n['required' 함수](/howto/charts_tips_and_tricks.md)를 사용함으로써 필수로 정의될 수 있다.\n\n값중 어떤 것이라도 템플릿의 안에서 `.Values` 오브젝트를 사용하여\n접근이 가능하다.\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### 범위, 의존성, 값\n\nvalues 파일은 최상위 차트에 대한 값과 차트의 `charts/` 디렉터리에\n포함된 차트중 어떤 것이라도 정의할 수 있다. 또는, 다르게 표현하면,\nvalues 파일은 차트와 그것의 종속성 모두에게 값을 제공할 수 있다.\n예를 들어 위의 데모 WordPress 차트는 `mysql` 과 `apaches`\n모두를 종속성으로 가진다. values 파일은 이 요소들의 모두를\n값으로 제공할 수 있다.\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\n더 높은 레벨의 차트는 더 아래 레벨에서 정의된 변수에 대해 엑세스할 수 있다.\n그러므로 WordPress 차트는 `.Values.mysql.password` 로 MySQL\n패스워드에 접근할 수 있다. 더 낮은 레벨의 차트는 부모차트에 엑세스가 불가능하므로,\nMySQL은 `title` 속성에 접근할 수 없다. 이 문제로 `apache.port` 에도\n접근할 수 없다.\n\n값은 네임스페이스가 지정되지만, 네임스페이스는 정리된다. WordPress 차트에서는\nMySQL 패스워드 필드를 `.Values.mysql.password` 로 접근 가능하다. 그러나\nMySQL 차트에서는 값의 범위가 축소되고 네임스페이스 접두사가 삭제되므로,\n`.Values.password` 로 간단히 패스워드 필드를 볼수 있다.\n\n#### 전역 값\n\n2.0.0-Alpha.2 현재로, 헬름은 특별한 \"전역\" 값을 제공한다.\n이전 예제의 수정된 버전을 보자.\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\n위에서 값 `app: MyWordPress` 도 함께 `global` 섹션에 추가했다.\n이 값은 `.Values.global.app` 으로 모든 차트에서 이용 가능하다.\n\n예를 들어, `mysql` 템플릿은 `app` 을 `{{.Values.global.app}}` 로\n접근할 수 있고, `apache` 에서도 마찬가지 이다. 사실상, 위의 values 파일은\n다음과 같이 다시 만들어진다.\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\n전역값은 하나의 최상위 레벨 변수를 모든 서브 차트와 공유하는 방법을 제공하고,\nlabel 같은 `metadata` 속성을 셋팅하는 것 같은 일에서 유용하다.\n\n서브 차트가 전역 변수를 선언하면, (서브차트의 서브차트에게) _하향_으로 전달되지만,\n부모의 차트로 _상향_되지는 않는다. 서브차트가 부모 차트의 값에\n영향을 주는 방법은 없다.\n\n또한 부모 차트의 전역 변수는 서브 차트의\n전역 변수보다 우선한다.\n\n### 스키마 파일 {#schema-files}\n\n가끔, 차트 메인테이너는 값에 구조를 정의하고 싶을 수 있다.\n`values.schema.json` 파일에 스키마를 정의함으로써 가능하다.\n스키마는 [JSON 스키마](https://json-schema.org/)로 표현된다.\n이 스키마는 다음과 같이 보인다.\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\n이 스키마는 유효성 검사를 위해 값에 적용된다.\n유효성 검사는 다음 명령중 하나가 일어날때 발생한다.\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\n이 스키마의 필요조건을 만족한 `values.yaml` 파일의 예는\n다음과 같다.\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\n스키마가 최종 `.Values` 오브젝트에 적용되고, `values.yaml` 파일에만\n적용되지 않는 다는 것을 주의하라. 즉, 다음과 같이 적절한\n`--set` 옵션과 함께 차트가 설치되면,\n다음 `yaml` 파일은 유효하다.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\n게다가, 최종 `.Values` 오브젝트는 _모든_ 서브차트 스키마에서 체크된다.\n즉, 부모차트에 의해 서브차트의 제한은 우회될수 없다.\n이 또한 반대 방향으로 작동한다. 서브차트가 서브차트의\n`values.yaml` 파일에서 만족하지 못한 필요조건을 가진다면,\n부모 차트는 이 조건을 만족 시켜야만한다.\n\n스키마 유효성 검사는 아래 옵션을 설정하여 비활성화할 수 있습니다.\n이 기능은 특히 차트의 JSON 스키마 파일에 원격 참조가 포함된 경우 에어갭(air-gapped) 환경에서 유용합니다.\n```console\nhelm install --skip-schema-validation\n```\n\n### 참고 자료\n\n템플릿, values, 스키마 파일등을 작성하려면 다음 표준 참고자료가\n도움이 될 것이다.\n\n- [Go templates](https://godoc.org/text/template)\n- [Extra template functions](https://godoc.org/github.com/Masterminds/sprig)\n- [The YAML format](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## 사용자 지정 리소스정의 (CRDs)\n\n쿠버네티스는 쿠버네티스 오브젝트의 새로운 타입을 정의하는 것에 대한 메커니즘을 제공한다.\n사용자 지정 리소스 정의(CRDs, Custom Resource Definitions)를 사용해서,\n쿠버네티스 개발자는 커스텀 리소스 타입을 정의할 수 있다.\n\n헬름 3에서, CRDs는 특별한 객체 종류로 다뤄진다. CRDs는 차트의 나머지보다\n먼저 설치되고, 몇몇 제한이 적용된다.\n\nCRD YAML 파일은 차트안의 `crds/` 디렉터리에 위치해야한다.\n(YAML 시작과 끝 마커로 분리된) 다수의 CRDs는 같은 파일에\n위치할수 있다. 헬름은 CRD 디렉터리의 _모든_ 파일을 쿠버네티스로\n로드하려고 시도한다.\n\nCRD 파일은 _템플릿화 될수 없다_. 순수 YAML 문서여야 한다.\n헬름이 새로운 차트를 설치할때, CRDs를 업로드 하고, API 서버에\n의해 이용가능해지도록 CRD가 만들때까지 정지되며, 템플릿 엔진이\n시작하고, 나머지 차트를 렌더링 하고, 쿠버네티스로 업로드한다.\n순서때문에, CRD 정보는 헬름 템플릿의 `Capabilities` 오브젝트에서\n이용 가능하고, 헬름 템플릿은 CRDs에서 정의된 오브젝트의 새로운\n인스턴스를 만들 수 있다.\n\n예를 들어, 차트가 `crds/` 디렉터리에 `CronTab` 에 대한 CRD를 가진다면, `templates/`\n디렉터리 안에 `CronTab` 종류의 인스턴스를 생성할 수 있다.\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\n`crontab.yaml` 파일은 반드시 템플릿 명령 없이 CRD를 포함해야한다.\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\n그러면 템플릿 `mycrontab.yaml` 은 (보통 템플릿을 사용하여) 새로운\n`CronTab` 을 생성할 수 있다.\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\n헬름은 `templates/` 안에 것들을 설치하기 전에 `CronTab` kind가\n설치되어 있고, 쿠버네티스 API 서버에서 이용 가능한지\n확인한다.\n\n### CRD 에서의 제약사항\n\n대부분의 쿠버네티스에서의 오브젝트와 다르게, CRDs는 전역으로 설치된다.\n이 이유로, 헬름은 CRDs를 관리하는 것에 매우 조심스럽게 접근한다.\nCRDs는 다음 제약이 적용된다.\n\n- CRDs는 절대 재설치 불가능하다. 헬름이 (버전에 상관 없이) `crds/` 디렉터리에 CRDs가 존재한다는 것을 알아낸다면, 헬름은 설치나 업그레이드 시도를 하지 않는다.\n- CRDs는 절대 업그레이드나 롤백이 불가능하다. 헬름은 오직 설치 작업시에만 CRDs를 생성한다.\n- CRDs는 절대 삭제될수 없다. CRD를 자동으로 지우는 것은 모든 클러스터 안의 네임스페이스에 영향을 주는 CRD's 내용의 모든것을 삭제한다. 따라서, 헬름은 CRDs를 삭제하지 않는다.\n\nCRDs를 업그레이드나 삭제하고 싶으면 몹시 조심하여 수동으로\n수행하라.\n\n## 헬름을 사용하여 차트 관리하기\n\n`helm` 도구에는 차트 작업을 위한 몇몇 명령이 있다.\n\n다음은 새로운 차트를 생성한다.\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\n일단 차트를 수정하면, `helm` 은 차트아카이브로\n패키징할 수 있다.\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\n차트의 포맷이나 정보 이슈를 찾는 것에 `helm` 을\n사용할 수 있다.\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## 차트 저장소\n\n차트 저장소는 한 개 이상의 패키징된 차트를 저장할 공간을 제공하는 HTTP 서버이다.\n`helm` 은 로컬 차트 디렉터리를 관리하는데 사용되는 반면, 차트를 공유하려면 우선되는\n메커니즘은 차트 저장소이다.\n\nYAML 파일과 tar 파일을 제공하고 GET 요청에 응답할 수 있는 어떤 HTTP서버든\n저장소 서버로 사용될 수 있다. 헬름 팀은 웹 사이트 모드 활성화로\n구글 클라우드 스토리지(Google Cloud Storage) 및 S3를 포함해서\n몇몇 서버를 테스트했다. \n\n주로 저장소에 의해 제공되는 패키지의 모든 리스트를 가진 특별한\n`index.yaml` 파일의존재와 검색 및 패키지 검증을 허용하는\n메타데이터로 저장소를 특정한다.\n\n클라이언트 측면에서, 저장소는 `helm repo` 명령으로 관리된다.\n그러나, 헬름은 원격 저장소 서버에 차트를 업로드하는 것에 대한 도구를 제공하지 않는다.\n그렇게 하는 것이 서버를 구현하기 위해 상당한 요구사항을 추가하고,\n저장소를 셋팅하는 것에 대한 장벽을 만들어내기 때문이다.\n\n## 차트 사용 팩\n\n`helm create` 명령은 \"스타터 차트\"를 지정할 수 있는 선택적 `--starter` 옵션을 제공합니다. 또한 스타터 옵션은 `-p` 단축 별칭을 가지고 있습니다.\n\n사용 예제:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\n스타터는 일반적인 차트이지만 `$XDG_DATA_HOME/helm/starters`에 위치합니다. 차트 개발자는 스타터로 사용하도록 특별히 디자인된 차트를 작성할 수 있습니다. 이런 차트는 다음 고려사항을 염두에 두고 디자인되어야 합니다:\n\n- `Chart.yaml`은 제너레이터에 의해 덮어쓰여진다.\n- 사용자는 이 차트의 내용을 수정하기 원하므로, 문서는 어떻게 사용자가 그럴 수 있는지 알려줘야한다.\n- 모든 `<CHARTNAME>` 항목은 지정된 차트 이름으로 교체되어 스타터 차트를 템플릿으로 사용할 수 있습니다. 단, `vars` 디렉터리의 사용자 정의 파일이나 특정 `README.md` 파일 같은 일부 변수 파일은 예외입니다. `<CHARTNAME>`은 이러한 파일 내부에서는 교체되지 않습니다. 또한 차트 설명은 상속되지 않습니다.\n\n현재 `$XDG_DATA_HOME/helm/starters`에 차트를 추가하는 유일한 방법은 수동으로 복사하는 것입니다. 차트의 문서에서 이 과정을 설명할 수 있습니다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: 차트 훅(hooks)\ndescription: 차트 훅을 이용하여 작업하는 방법을 설명한다.\nsidebar_position: 2\n---\n\n헬름은 차트 개발자가 릴리스 수명주기의 특정 지점에 개입할 수 있도록 _hook_ 매커니즘을 제공한다.\n예를 들어 다음과 같은 것들을 하기 위해 훅을 사용할 수 있다.\n\n- 설치 시 다른 차트가 로드되기 전에 컨피그맵이나 시크릿을 로드한다.\n- 새 차트를 설치하기 전에 데이터베이스를 백업하는 작업을 실행하고, \n  데이터 복원을 위해 업그레이드 후 2번째 작업을 수행한다. \n- 릴리스를 제거하기 전에 서비스를 순환에서 안전하게 제거하기 위하여,\n  릴리스 삭제 전에 작업을 수행한다.\n\n훅은 일반적인 템플릿처럼 작동하지만 헬름이 다른 방식으로 \n처리하도록 하는 특수한 어노테이션이 있다.\n이 섹션에서는 훅의 기본 사용 패턴을 다룬다.\n\n## 사용 가능한 훅\n\n훅은 다음과 같이 정의되어 있다.\n\n| 어노테이션 값\t       | 설명                                                                                                   |\n| ---------------- | ----------------------------------------------------------------------------------------------------- |\n| `pre-install`    | 템플릿은 렌더링되었지만, 쿠버네티스에서 아직 아무 리소스도 생성되기 전에 실행된다. |\n| `post-install`   | 쿠버네티스에 모든 리소스가 로드된 후에 실행된다.                                                                   |\n| `pre-delete`     | 삭제 요청 중에서, 쿠버네티스에서 리소스가 삭제되기 전에 실행된다.                                                         |\n| `post-delete`    | 삭제 요청 중에서, 릴리스의 모든 리소스가 삭제된 후 실행된다.                                                            |\n| `pre-upgrade`    | 업그레이드 요청 중에서, 템플릿은 렌더링되었지만 리소스는 업데이트되기 전에 실행된다.                                            |\n| `post-upgrade`   | 업그레이드 요청 중에서, 모든 리소스가 업그레이드된 후 실행된다.                                                             |\n| `pre-rollback`   | 롤백 요청 중에서, 템플릿은 렌더링되었지만 아직 아무 리소스도 롤백되지 않은 시점에 실행된다.                                                    |\n| `post-rollback`  | 롤백 요청 중에서, 모든 리소스가 수정된 후에 실행된다.                                                                 |\n| `test`           | 헬름 test 하위 명령어가 호출될 때 실행된다. ([테스트 문서 보기](/topics/chart_tests.md))                                  |\n\n_헬름 3에서는 `crd-install` 훅은 제거되었고 대신 `crds/` 디렉터리를 \n사용한다는 점을 잊지 말자._ \n\n## 훅과 릴리스 수명주기\n\n훅을 사용하면 차트 개발자는 릴리스 수명주기 상의 중요 시점에서 \n작업이 수행되도록 할 수 있다. 예를 들어 `helm install` 의 수명주기를 \n생각해보자. 기본적으로 수명주기는 다음과 같다.\n\n1. 사용자가 `helm install foo` 를 실행한다.\n2. 헬름 라이브러리 설치 API가 호출된다.\n3. 검증 후, 라이브러리는 `foo` 템플릿을 렌더링한다.\n4. 라이브러리는 결과로 나온 리소스를 쿠버네티스에 로드한다.\n5. 라이브러리는 릴리스 객체(및 다른 데이터)를 클라이언트에 반환한다.\n6. 클라이언트가 종료된다.\n\n헬름은 `install` 수명주기에 대해 `pre-install` 및 `post-install` \n의 두 가지 훅을 정의한다. `foo` 차트의 개발자가 두 훅을 모두 구현하면 수명주기는 \n다음과 같이 바뀐다.\n\n1. 사용자가 `helm install foo` 를 실행한다.\n2. 헬름 라이브러리 설치 API가 호출된다.\n3. `crds/` 디렉터리의 CRD가 설치된다.\n4. 검증 후 라이브러리는 `foo` 템플릿을 렌더링한다.\n5. 라이브러리는 `pre-install` 훅 실행을 준비한다. (쿠버네티스에\n   훅 리소스 로딩)\n6. 라이브러리는 가중치(기본값으로는 0을 할당), 리소스 종류, \n   이름을 기준으로 훅을 오름차순으로 정렬한다.\n7. 라이브러리는 가장 낮은 가중치의 훅을 먼저 로드한다.(음수에서 \n   양수로)\n8. 라이브러리는 훅이 \"Ready\" 될 때까지 대기한다(CRD 제외).\n9. 라이브러리는 결과로 나온 리소스를 쿠버네티스에 로드한다. \n   `--wait` 플래그가 설정된 경우 라이브러리는 모든 리소스가 \"Ready\" 상태가 될 때까지 대기하고, \n   준비가 될 때까지 `post-install` 훅을 실행하지 않는다.\n10. 라이브러리는 `post-install` 훅을 실행한다. (훅 리소스 로딩)\n11. 라이브러리는 훅이 \"Ready\" 될 때까지 기다린다.\n12. 라이브러리는 릴리스 객체(및 다른 데이터)를 클라이언트에 반환한다.\n13. 클라이언트가 종료된다.\n\n훅이 준비될 때까지 기다린다는 것은 무엇을 의미하는가? 이것은 \n훅에 선언된 리소스에 따라 다르다. 리소스가 `Job` 또는 `Pod` 종류인 경우 \n헬름은 성공적으로 실행 완료될 때까지 기다린다. 훅이 실패하면 릴리스는 실패하게 된다. \n이것은 _블로킹(blocking) 작업_이므로 작업이 실행되는 \n동안 헬름 클라이언트는 일시정지될 것이다.\n\n다른 모든 종류의 경우, 쿠버네티스가 리소스를 로드(추가 또는 업데이트)하였다고 \n표시하는 즉시, 리소스는 \"Ready\" 로 간주된다.\n훅에 많은 리소스가 선언되면 리소스들은 연속적으로 실행된다.\n훅 가중치(아래 참조)가 있으면, 가중치 순서대로 실행된다.\n헬름 3.2.0 부터 같은 가중치를 가진 훅 리소스들은 훅이 없는 일반 리소스와 \n같은 순서로 설치된다. 그밖의 경우에는 순서가 보장되지 않는다. (헬름 2.3.0 \n이상에서는 알파벳순으로 정렬된다. 그러나 이 동작은 바인딩으로 간주되지 않으며 \n향후 변경될 수 있다.) 여기까지가 훅 가중치 추가시 고려할 사항이며,\n만약 가중치가 중요하지 않다면 `0` 으로 설정하는 것이 \n좋다.\n\n### 해당 릴리스에 의해 관리되지 않는 훅 리소스\n\n훅이 생성하는 리소스는 현재 릴리스의 일부로 추적되거나 \n관리되지 않는다. 헬름은 훅이 준비 상태까지 도달했는지를 확인했다면\n훅 리소스를 그대로 남겨둔다. 향후 헬름 3에 릴리스 삭제시 \n훅 리소스에 대한 가비지 수집 기능이 추가될 수 있으므로, \n삭제되면 안되는 모든 훅 리소스에 `helm.sh/resource-policy: keep` 어노테이션을 \n추가해야 한다.\n\n실질적으로, 이는 훅 리소스를 만드는 경우 `helm uninstall` 으로 \n리소스를 제거할 수 없음을 의미한다. 이러한 리소스를 \n삭제하려면 훅 템플릿 파일에 [사용자 지정 `helm.sh/hook-delete-policy` 어노테이션을 추가](#훅-삭제-정책)하거나 \n작업(Job) 리소스의 \n[time to live(TTL) 필드를 설정](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/)해야 \n한다.\n\n## 훅 작성하기\n\n훅은 `metadata` 섹션에 특별한 어노테이션이 있는 \n쿠버네티스 매니페스트 파일이다. 템플릿 파일이기 때문에 \n`.Values`, `.Release` 및 `.Template` 을 \n읽기를 포함한 모든 일반 템플릿 기능을 사용할 수 있다.\n\n예를 들어 `templates/post-install-job.yaml` 에 저장된 템플릿은\n`post-install` 에서 실행할 작업을 선언한다.\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\n다음의 어노테이션으로 이 템플릿을 훅으로 만든다.\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\n하나의 리소스는 여러 개의 훅으로 구현할 수 있다.\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\n마찬가지로, 주어진 훅을 구현하는 다양한 리소스의 수에는 \n제한이 없다. 예를 들어 시크릿과 컨피그맵을 둘다\npre-install 훅으로 선언할 수 있다.\n\n하위 차트에 훅이 선언되면 해당 훅도 평가된다.\n최상위 차트가 하위 차트에 선언된 훅을 비활성화할 수 있는 방법은 없다.\n\n결정적 실행순서를 정하는데 도움이 되는 훅에 대한 가중치를 \n정의할 수 있다. 가중치는 다음의 어노테이션을 사용하여 \n정의한다.\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\n훅 가중치는 양수여도 되고 음수여도 되지만 문자열로 표기해야\n한다. 헬름이 특정 종류의 훅 실행주기를 시작하면 해당 훅을\n오름차순으로 정렬한다.\n\n### 훅 삭제 정책\n\n대상 훅 리소스를 언제 삭제할지를 결정하는 정책을 정의할 \n수 있다. 훅 삭제 정책은 다음과 같은 어노테이션을 사용하여 \n정의한다.\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\n한개 혹은 그 이상의 정의된 어노테이션 값을 선택할 수 있다.\n\n| 어노테이션 값              | 설명                                                                  |\n| ---------------------- | -------------------------------------------------------------------- |\n| `before-hook-creation` | 새 훅이 시작되기 전에 이전 리소스를 삭제한다. (기본값)                             |\n| `hook-succeeded`       | 훅이 성공적으로 실행된 후에 리소스를 삭제한다.                                    |\n| `hook-failed`          | 실행 중 훅이 실패한 경우 리소스를 삭제한다.                                      |\n\n훅 삭제 정책 어노테이션이 지정되지 않은 경우, 기본적으로 `before-hook-creation` 동작이\n적용된다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/index.mdx",
    "content": "---\ntitle: 주제\nsidebar_position: 3\n---\n\r\n# 주제 가이드\r\n\r\n알고 싶었던 헬름의 모든 핵심부분에 관한 설명을 이곳에서 찾을 수 있을 것이다.\r\n\r\nimport DocCardList from '@theme/DocCardList';\r\n\r\n<DocCardList />"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: \"사용 중단된 쿠버네티스 APIs\"\ndescription: \"헬름에서 사용 중단된 쿠버네티스 API에 대해 설명한다.\"\n---\n\n쿠버네티스는 API 주도 시스템이며, 시간이 지남에 따라\n문제 공간(problem space)에 대한 이해가 깊어지면서 이를 반영하기 위해 API 도 진화한다.\n이는 어떤 시스템이나 그에 따른 API에서 나타나는 일반적인 관행이다.\n진화하는 API에서 중요한 것은, 적절한 지원 중단 정책과\n구현된 API의 변화를 사용자에게 알리는 프로세스이다. 다시 말해서,\nAPI 소비자는 사전에 API 가 제거되거나 변경되는 릴리스에 대하여 알 수 있어야 한다.\n그렇게 해야 소비자는 예상하지 못한 부분이나 규모가 단절적(breaking) 변화의 요소를 방지할 수 있다.\n\n[쿠버네티스 사용\n중단 정책](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)은\n쿠버네티스가 API 버전의 변경 사항을 처리하는 방법을 담은 문서이다.\n지원 중단 정책에는 지원 중단 발표 후 API\n버전이 지원되는 기간이 명시되어 있다. 따라서 영향도를 최소화하려면\n지원 중단 공지를 주시하고 API 버전이 제거되는 시기를 알아두는 것이\n중요하다.\n\n이것은 [쿠버네티스 1.16에서\n더 이상 사용되지 않는 API\n버전을 제거하기 위한](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) 발표의 예시이며\n릴리스 몇 달 전에 발표되었다. 이러한 API 버전은\n지원중단에 앞서 한번 더 안내되었다.\n이는 API 버전 지원을 소비자에게 알리는 적절한 정책이 있음을 나타낸다.\n\n헬름 템플릿은 쿠버네티스 메니페스트 파일과 유사하게\n쿠버네티스 객체를 정의할 때 [쿠버네티스 API\n그룹](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)을 지정한다.\n템플릿의 `apiVersion` 필드에 지정되며 쿠버네티스 객체의\nAPI 버전을 식별한다. 즉, 헬름 사용자와 차트 유지관리자는\n쿠버네티스 API 버전이 언제 사용 중단(deprecated)되고\n어느 쿠버네티스 버전에서 제거되는지를 알고 있어야 한다.\n\n## 차트 관리자\n\n차트에 있는 쿠버네티스 API 버전이 어느 쿠버네티스 버전에서\n사용중단되거나 제거되는지를 감사(audit)해야 한다.\n지원 중단이 예정되어 있거나 이미 중단된 API 버전은 지원되는 버전으로 바꾸고\n출시되는 차트도 새로운 버전으로 업데이트해야 한다. API 버전은 `kind` 및\n`apiVersion` 필드로 정의된다. 예를 들어 쿠버네티스 1.16\n에서 제거된 `Deployment` 객체의 API 버전은 다음과 같다.\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## 헬름 사용자\n\n사용자는 ([차트 관리자](#차트-관리자)와 유사하게) 사용하는\n차트를 감사(audit)하고, 쿠버네티스 버전에서 API 버전이\n사용중단되거나 제거된 차트를 식별해야 한다.\n식별된 차트의 경우 최신 버전의 차트(API 버전을 지원하는)가 있는지\n확인하거나 직접 차트를 업데이트해야 한다.\n\n또한, 배포된 모든 차트(예: 헬름 릴리스)를 감사(audit)하여\n사용중단되거나 제거된 API 버전을 다시 확인해야 한다.\n`helm get manifest` 명령어를 사용하여 릴리스의 세부사항을 보면 된다.\n\n확인한 바에 따라, 헬름 릴리스를 지원되는 API로 업데이트하는 방법은\n다음과 같다.\n\n1. 지원 중단된 API 버전만을 찾는 경우,\n  - 지원되는 쿠버네티스 API 버전이 포함된 차트 버전으로 `helm upgrade`\n    수행\n  - 현재 버전 이전의 헬름 버전으로 롤백되지 않도록\n    업그레이드에 대한 설명(description) 추가\n2.  쿠버네티스 버전에서 제거된 API 버전을 찾는\n    경우,\n  - API 버전을 계속 사용할 수 있는 쿠버네티스 버전을 실행 중이라면(예: 쿠버네티스 1.15 에 있고, 쿠버네티스 1.16 에서 제거될 API를 사용하는 경우):\n    - 1 단계 절차를 수행한다.\n  - 그렇지 않다면(예: `helm get manifest` 에서 나온 API 버전을\n    더 이상 사용할 수 없는 쿠버네티스 버전을 사용 중인 경우):\n    - API 버전을 지원되는 API로 업데이트하려면 클러스터에\n  \t  저장된 릴리스 매니페스트를 편집해야 한다.\n  \t  자세한 내용은 [릴리스 매니페스트의 api 버전 업데이트](#릴리스-매니페스트의-api-버전-업데이트)를\n  \t  참조하자.\n\n> 참고: 지원되는 API로 헬름 릴리스를 업데이트하는 모든 경우에,\n지원되는 API 가 있는 릴리스 버전 이전 버전으로 릴리스를\n롤백해서는 안된다.\n\n> 권고: 해당 API 버전이 제거되는 쿠버네티스 클러스터 업그레이드 작업 전에,\n사용중단된 API 버전을 사용하는 릴리스를\n지원되는 API 버전으로 업그레이드하는 것이 모범사례이다.\n\n위와 같이 릴리스를 업데이트하지 않으면, API 버전이\n제거된 쿠버네티스 버전에서 릴리스를 업그레이드하려고 할 때\n다음과 유사한 오류가 발생할 수 있다.\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\n헬름은 업데이트/지원되는 API 버전과 함께\n전달받은 차트를 가지고, 현재 배포된 릴리스간의\ndiff 패치(이 쿠버네티스 버전에서 제거된 쿠버네티스 API를 포함)를\n만드려고 하기 때문에 이 시나리오는 실패하게 된다.\n실패의 근본적인 이유는, 쿠버네티스가 API 버전을 제거하면\n쿠버네티스 Go 클라이언트 라이브러리가 더 이상 지원 중단된\n객체를 파싱할 수 없기 때문에 헬름이 라이브러리를\n호출할 수 없기 때문이다. 헬름은 안타깝게도 이 상황을\n복구할 수 없으며 더 이상 이러한 릴리스는 관리할 수 없다. 이 시나리오에서 복구하는 방법에 대한 자세한 내용은\n[릴리스 매니페스트의 api 버전 업데이트](#릴리스-매니페스트의-api-버전-업데이트)를 참조하자.\n\n## 릴리스 매니페스트의 api 버전 업데이트\n\n매니페스트는 클러스터에서 시크릿(기본값) 또는 컨피그맵의 데이터 필드에 저장되는\n헬름 릴리스 객체의 속성이다. 데이터 필드에는 base 64 로 인코딩되어\ngzip 으로 압축된 객체가 담겨 있다. (시크릿에는 추가적인 base 64 인코딩이\n적용된다.) 릴리스의 네임스페이스에는 릴리스 버전/리비전마다의\n시크릿/컨피그맵들이 있게 된다.\n\n사용자는 헬름 [mapkubeapis](https://github.com/helm/helm-mapkubeapis) 플러그인을\n사용하여 지원되는 API에 대한 릴리스 업데이트를\n수행할 수 있다. 자세한 내용은 readme 를 확인하자.\n\n또는 다음의 단계에 따라 수동으로 릴리스 매니페스트의 API 버전\n업데이트를 수행할 수 있다. 구성에 따라 시크릿 또는 컨피그맵 백엔드에 대한\n작업단계를 따라야 한다.\n\n- 배포된 최신 릴리스와 관련된 시크릿 또는 컨피그맵의 이름을\n  가져온다.\n  - 시크릿 백엔드: `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - 컨피그맵 백엔드: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- 배포된 최신 릴리스 정보를 가져온다.\n  - 시크릿 백엔드: `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - 컨피그맵 백엔드: `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- 문제가 발생하여 복원해야 하는 경우 릴리스를 백업한다.:\n  - `cp release.yaml release.bak`\n  - 비상시에 복구해야 할 경우: `kubectl apply -f release.bak -n\n    <release_namespace>`\n- 릴리스 객체를 디코딩한다:\n  - 시크릿 백엔드:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - 컨피그맵 백엔드: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- 매니페스트의 API 버전을 변경한다. 모든 도구(예: 편집기)를 사용하여\n  변경할 수 있다. 이것은 디코딩 된 릴리스\n  객체의 (`release.data.decoded`)의 `manifest` 필드에 존재한다.\n- 릴리스 객체를 인코딩한다:\n  - 시크릿 백엔드: `cat release.data.decoded | gzip | base64 | base64`\n  - 컨피그맵 백엔드: `cat release.data.decoded | gzip | base64`\n- 배포된 릴리스 파일(`release.yaml`)의\n  `data.release` 속성 값을 인코딩 된 새 릴리스 객체로 변경한다.\n- 파일을 네임스페이스에 적용한다: `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- 지원되는 쿠버네티스 API 버전이 있는 차트 버전으로 `helm upgrade` 를\n  수행한다.\n- 현재 버전 이전의 헬름 버전으로 롤백하지 않도록 업그레이드에\n  설명을 추가한다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: 쿠버네티스 배포판 가이드\ndescription: 특정 쿠버네티스 환경에서 헬름 사용에 대한 정보 정리.\nsidebar_position: 10\n---\n\n헬름은 ([인증 여부](https://www.cncf.io/certification/software-conformance/)와 \n관계 없이) 모든 [쿠버네티스 적합 버전](https://github.com/cncf/k8s-conformance)에서 \n작동해야 한다.\n\n이 문서는 특정 쿠버네티스 환경에서 헬름을 사용하는 방법에 대한 정보를 정리한다.\n원한다면, 특정 배포판(알파벳순 정렬)에 \n대한 추가 내용을 기여하자.\n\n\n## AKS\n\n헬름은 [Azure 쿠버네티스 서비스](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm)에서 \n동작한다.\n\n## DC/OS\n\n헬름은 Mesospheres DC/OS 1.11 쿠버네티스 플랫폼에서 테스트를 거쳤고 동작하며,\n추가 구성이 필요치 않다.\n\n## EKS\n\n헬름은 Amazon Elastic 쿠버네티스 서비스 (Amazon EKS)에서 동작한다.\n[Amazon EKS에서 \n헬름 사용](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\n구글의 GKE 호스팅 쿠버네티스 플랫폼은 헬름이 동작하는 것으로 \n알려져 있으며, 추가 구성이 필요치 않다.\n\n## `scripts/local-cluster` 와 Hyperkube\n\n`scripts/local-cluster.sh` 를 통해 구성된 Hyperkube 에서 동작하는 것으로 알려져 있다.\n원시(raw) Hyperkube 는 몇 가지 수동 구성이 필요할 수도 있다.\n\n## IKS\n\n헬름은 [IBM 클라우드 쿠버네티스 서비스](https://cloud.ibm.com/docs/containers?topic=containers-helm)에서 \n동작한다.\n\n## KIND (Kubernetes IN Docker)\n\n헬름은 [KIND](https://github.com/kubernetes-sigs/kind)에서 정기적으로 테스트된다.\n\n## KubeOne\n\n헬름은 별다른 특이사항 없이 KubeOne 으로 구성된 클러스터에서 동작한다.\n\n## Kubermatic\n\n헬름은 별다른 특이사항 없이 Kubermatic 으로 생성된 사용자 클러스터에서 동작한다.\n시드(seed) 클러스터는 다양한 방식으로 설정될 수 있으므로 헬름 지원은 \n그 설정에 따라 달라진다.\n\n## MicroK8s\n\n[MicroK8s](https://microk8s.io) 에서는 명령어 `microk8s.enable helm3`를 사용하여 헬름을 활성화할 수 있다.\n\n## Minikube\n\n헬름은 [Minikube](https://github.com/kubernetes/minikube) 에서 테스트를 거쳤고\n동작하는 것으로 알려져 있다. \n추가적인 구성이 필요하지 않다.\n\n## Openshift\n\n헬름은 OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (버전 3.6 이상) 또는 \nOpenShift Origin (버전 3.6 이상)에서 동작한다.\n자세한 내용은 \n[이 블로그](https://blog.openshift.com/getting-started-helm-openshift/) 의 게시물을 참조하자.\n\n## Platform9\n\n헬름은 [Platform9 Managed\nKubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes)와 함께 사전 설치된다.\nPlatform9 은 앱 카탈로그 UI 및 기본 쿠버네티스 CLI를 통해 \n모든 공식 헬름 차트에 대한 접근을 제공한다. 추가적인 레포지토리들도 수동으로 추가할 수 있다.\n상세한 내용은 [Platform9 App Catalog\narticle](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes)에서 확인할 수 있다.\n\n## 우분투와 `kubeadm`\n\n`kubeadm` 으로 구성된(bootstrapped) 쿠버네티스는 다음 리눅스 배포판에서 \n동작하는 것으로 알려져 있다.\n\n- 우분투 16.04\n- 페도라 릴리스 25\n\n헬름 일부 버전(v2.0.0-beta2)은 `export KUBECONFIG=/etc/kubernetes/admin.conf` 를 수행하거나\n`~/.kube/config` 를 생성해야 한다.\n\n## VMware Tanzu Kubernetes Grid\n\n헬름은 VMware Tanzu Kubernetes Grid(TKG)에서 추가 구성 변경 없이 동작한다.\nTanzu CLI는 [helm-controller](https://fluxcd.io/flux/components/helm/) 패키지 설치를 관리할 수 있다. 이를 통해 헬름 차트 릴리스를 선언적으로 관리할 수 있다.\n자세한 내용은 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)를 참조하자.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: 라이브러리 차트\ndescription: 라이브러리 차트의 개념과 사용 예제를 설명합니다\nsidebar_position: 4\n---\n\n라이브러리 차트는 [Helm 차트](/topics/charts.md)의 한 유형으로,\n다른 차트의 Helm 템플릿에서 공유할 수 있는 차트 기본 요소나 정의를 제공합니다.\n이를 통해 사용자는 여러 차트에서 재사용할 수 있는 코드 조각을 공유하고,\n반복을 피하며 차트를 [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)하게\n유지할 수 있습니다.\n\n라이브러리 차트는 Helm 2부터 차트 관리자들이 사용해온 공용 또는 헬퍼 차트를\n공식적으로 인정하기 위해 Helm 3에서 도입되었습니다.\n차트 유형으로 포함함으로써 다음과 같은 기능을 제공합니다:\n- 공용 차트와 애플리케이션 차트를 명확하게 구분하는 수단\n- 공용 차트의 설치를 방지하는 로직\n- 릴리스 아티팩트를 포함할 수 있는 공용 차트의 템플릿 렌더링 방지\n- 의존하는 차트가 가져오는 쪽의 컨텍스트를 사용할 수 있도록 허용\n\n차트 관리자는 공용 차트를 라이브러리 차트로 정의하면\nHelm이 표준화되고 일관된 방식으로 해당 차트를 처리할 것이라고 확신할 수 있습니다.\n또한 차트 유형을 변경하여 애플리케이션 차트의 정의를 공유할 수 있습니다.\n\n## 간단한 라이브러리 차트 만들기\n\n앞서 언급했듯이, 라이브러리 차트는 [Helm 차트](/topics/charts.md)의 한 유형입니다.\n따라서 스캐폴드 차트를 생성하는 것부터 시작할 수 있습니다:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\n먼저 `templates` 디렉토리의 모든 파일을 삭제합니다.\n이 예제에서는 직접 템플릿 정의를 만들 것입니다.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nvalues 파일도 필요하지 않습니다.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\n공용 코드를 작성하기 전에, 관련된 Helm 개념을 간단히 살펴보겠습니다.\n[이름이 지정된 템플릿](/chart_template_guide/named_templates.md)(partial 또는\nsubtemplate이라고도 함)은 파일 내에 정의되고 이름이 부여된 템플릿입니다.\n`templates/` 디렉토리에서 밑줄(_)로 시작하는 파일은 Kubernetes 매니페스트 파일을\n출력하지 않습니다. 따라서 관례적으로 헬퍼 템플릿과 partial은\n`_*.tpl` 또는 `_*.yaml` 파일에 배치합니다.\n\n이 예제에서는 빈 ConfigMap 리소스를 생성하는 공용 ConfigMap을 작성합니다.\n공용 ConfigMap은 `mylibchart/templates/_configmap.yaml` 파일에 다음과 같이 정의합니다:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nConfigMap 구조는 `mylibchart.configmap.tpl`이라는 이름이 지정된 템플릿에 정의됩니다.\n빈 리소스 `data`를 가진 간단한 ConfigMap입니다. 이 파일에는\n`mylibchart.configmap`이라는 또 다른 이름이 지정된 템플릿이 있습니다.\n이 템플릿은 `mylibchart.util.merge`라는 또 다른 이름이 지정된 템플릿을 포함하며,\n`mylibchart.configmap`을 호출하는 템플릿과 `mylibchart.configmap.tpl`이라는\n두 개의 이름이 지정된 템플릿을 인수로 받습니다.\n\n헬퍼 함수 `mylibchart.util.merge`는 `mylibchart/templates/_util.yaml`에 있는\n이름이 지정된 템플릿입니다. 이것은 [공용 Helm 헬퍼 차트](#공용-helm-헬퍼-차트)에서\n가져온 유용한 유틸리티로, 두 템플릿을 병합하고 공통 부분을 덮어씁니다:\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\n차트가 자체 설정으로 사용자 정의해야 하는 공용 코드를 사용하려는 경우에 이것이 중요합니다.\n\n마지막으로 차트 유형을 `library`로 변경합니다.\n`mylibchart/Chart.yaml`을 다음과 같이 편집합니다:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\n이제 라이브러리 차트를 공유할 준비가 되었으며, ConfigMap 정의를 재사용할 수 있습니다.\n\n계속 진행하기 전에, Helm이 해당 차트를 라이브러리 차트로 인식하는지 확인해 볼 가치가 있습니다:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## 간단한 라이브러리 차트 사용하기\n\n이제 라이브러리 차트를 사용할 차례입니다. 다시 스캐폴드 차트를 생성합니다:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nConfigMap만 생성할 것이므로 템플릿 파일들을 다시 정리합니다:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nHelm 템플릿에서 간단한 ConfigMap을 생성하려면 다음과 비슷한 형태가 됩니다:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\n그러나 우리는 `mylibchart`에 이미 작성된 공용 코드를 재사용할 것입니다.\nConfigMap은 `mychart/templates/configmap.yaml` 파일에 다음과 같이 생성할 수 있습니다:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nConfigMap의 표준 속성을 추가하는 공용 ConfigMap 정의를 상속받아\n작업을 단순화한 것을 볼 수 있습니다. 우리의 템플릿에서는 설정만 추가합니다.\n이 경우 데이터 키 `myvalue`와 그 값입니다. 이 설정은 공용 ConfigMap의 빈 리소스를\n덮어씁니다. 이것은 이전 섹션에서 언급한 헬퍼 함수 `mylibchart.util.merge` 덕분에 가능합니다.\n\n공용 코드를 사용하려면 `mylibchart`를 의존성으로 추가해야 합니다.\n`mychart/Chart.yaml` 파일 끝에 다음을 추가합니다:\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\n이것은 애플리케이션 차트와 동일한 상위 경로에 있는 파일 시스템에서\n라이브러리 차트를 동적 의존성으로 포함합니다. 라이브러리 차트를 동적 의존성으로 포함하므로\n`helm dependency update`를 실행해야 합니다. 이 명령은 라이브러리 차트를\n`charts/` 디렉토리로 복사합니다.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\n이제 차트를 배포할 준비가 되었습니다. 설치하기 전에 먼저 렌더링된 템플릿을 확인해 보는 것이 좋습니다.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\n원하는 대로 `myvalue: Hello World` 데이터가 덮어씌워진 ConfigMap처럼 보입니다. 설치해 봅시다:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\n릴리스를 조회하여 실제 템플릿이 로드되었는지 확인할 수 있습니다.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## 라이브러리 차트의 장점\n\n라이브러리 차트는 독립 실행형 차트로 동작할 수 없기 때문에 다음과 같은 기능을 활용할 수 있습니다:\n- `.Files` 객체는 라이브러리 차트의 로컬 경로가 아닌 부모 차트의 파일 경로를 참조합니다\n- `.Values` 객체는 부모 차트와 동일합니다. 이는 부모의 헤더 아래에 설정된\n  값 섹션을 받는 애플리케이션 [서브차트](/chart_template_guide/subcharts_and_globals.md)와 대조됩니다\n\n\n## 공용 Helm 헬퍼 차트\n\n```markdown\n참고: GitHub의 공용 Helm 헬퍼 차트 리포지토리는 더 이상 적극적으로 유지 관리되지 않으며, 해당 리포지토리는 더 이상 사용되지 않고 보관되었습니다.\n```\n\n이 [차트](https://github.com/helm/charts/tree/master/incubator/common)는\n공용 차트의 원래 패턴이었습니다. Kubernetes 차트 개발의 모범 사례를 반영하는\n유틸리티를 제공합니다. 무엇보다도 차트를 개발할 때 바로 사용하여 편리한 공유 코드를\n활용할 수 있습니다.\n\n다음은 이를 사용하는 빠른 방법입니다. 자세한 내용은\n[README](https://github.com/helm/charts/blob/master/incubator/common/README.md)를 참조하세요.\n\n다시 스캐폴드 차트를 생성합니다:\n\n```console\n$ helm create demo\nCreating demo\n```\n\n헬퍼 차트의 공용 코드를 사용해 봅시다. 먼저 deployment\n`demo/templates/deployment.yaml`을 다음과 같이 편집합니다:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\n그리고 service 파일 `demo/templates/service.yaml`을 다음과 같이 편집합니다:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\n이 템플릿들은 헬퍼 차트의 공용 코드를 상속받아\n리소스의 설정 또는 사용자 정의만으로 코딩을 단순화하는 방법을 보여줍니다.\n\n공용 코드를 사용하려면 `common`을 의존성으로 추가해야 합니다.\n`demo/Chart.yaml` 파일 끝에 다음을 추가합니다:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\n참고: Helm 리포지토리 목록에 `incubator` 리포지토리를 추가해야 합니다\n(`helm repo add`).\n\n차트를 동적 의존성으로 포함하므로 `helm dependency update`를 실행해야 합니다.\n이 명령은 헬퍼 차트를 `charts/` 디렉토리로 복사합니다.\n\n헬퍼 차트가 일부 Helm 2 구조를 사용하므로, Helm 3 스캐폴드 차트에서 업데이트된\n`nginx` 이미지를 로드하려면 `demo/values.yaml`에 다음을 추가해야 합니다:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\n`helm lint`와 `helm template` 명령을 사용하여 배포 전에 차트 템플릿이 올바른지 테스트할 수 있습니다.\n\n문제가 없다면 `helm install`을 사용하여 배포하세요!\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: \"SQL 스토리지 백엔드에 대한 권한 관리\"\ndescription: \"SQL 스토리지 백엔드를 사용할 때 권한을 설정하는 방법을 알아본다.\"\n---\n\n이 문서에서는 SQL 스토리지 백엔드 사용 시 권한을 설정하고 관리하는 방법을 설명한다.\n\n## 소개\n\n권한을 처리하기 위해 헬름은 쿠버네티스의 RBAC 기능을 사용한다. SQL 스토리지\n백엔드를 사용할 때는 쿠버네티스의 역할을 사용하여 사용자가 특정\n리소스에 액세스할 수 있는지 여부를 결정할 수 없다. 이 문서는 이러한 권한을\n생성하고 관리하는 방법을 보여준다.\n\n## 초기화\n\n헬름 CLI가 처음으로 데이터베이스에 연결되면, 클라이언트는 이전에 초기화되었는지 \n확인한다. 그렇지 않은 경우 필요한 설정을 자동으로 처리한다.\n이 초기화에는 퍼블릭 스키마에 대한 관리자 권한이 필요하거나 최소한\n다음을 수행할 수 있어야 한다.\n\n* 테이블 생성\n* 퍼블릭 스키마에 대한 권한 부여\n\n데이터베이스에 대한 마이그레이션이 실행된 후, 다른 모든 역할은 \n클라이언트를 사용할 수 있다.\n\n## PostgreSQL에서 관리자가 아닌 사용자에게 권한 부여\n\n권한을 관리하기 위해 SQL 백엔드 드라이버는 PostgreSQL의 \n[RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)(행 수준 \n보안) 기능을 활용한다. RLS를 사용하면 모든 사용자가 같은 \n테이블에서 읽고 쓸 수 있지만, 명시적으로 허용된 행만 \n조작할 수 있다. 기본적으로 올바른 권한이 명시적으로 부여되지 않은 \n역할은 `helm list`를 실행할 때 항상 빈 목록을 반환하며, \n클러스터의 리소스를 검색하거나 수정할 수 없다.\n\n지정된 역할에 특정 네임스페이스에 대한 액세스 권한을 부여하는 방법을 알아보자:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\n이 명령어는 `namespace = 'default'` 조건을 충족하는 모든 리소스를 읽고 쓸 수 있는 \n권한을 `role` 역할에 부여한다. 이 정책을 만든 후 `role` 역할을 대신하여 \n데이터베이스에 연결된 사용자는 `helm list`를 실행할 때 \n`default` 네임스페이스에 있는 모든 릴리스를 볼 수 있으며, 수정 및 삭제할 수 있다.\n\n권한은 RLS를 사용하여 세분화하여 관리할 수 있으며, 테이블의 다른 열에 대한 \n접근을 제한할 수도 있다:\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Helm 플러그인 가이드\ndescription: Helm의 기능을 확장하기 위해 플러그인을 사용하고 만드는 방법을 소개한다.\nsidebar_position: 12\n---\n\nHelm 플러그인은 `helm` CLI를 통해 접근할 수 있지만, 기본 제공되는\nHelm 코드베이스에 포함되지는 않는 도구이다.\n\n기존 플러그인은 [관련](/community/related#helm-plugins) 섹션 또는\n[GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)을\n검색하여 찾을 수 있다.\n\n이 가이드에서는 플러그인을 사용하고 만드는 방법을 설명한다.\n\n## 개요\n\nHelm 플러그인은 Helm과 원활하게 통합되는 애드온 도구이다.\n모든 새 기능을 Go로 작성하거나 코어 도구에 추가하지 않고도\nHelm의 핵심 기능 세트를 확장하는 방법을 제공한다.\n\nHelm 플러그인에는 다음과 같은 특징이 있다.\n\n- 코어 Helm 도구에 영향을 주지 않고 Helm 설치에서 추가하거나\n  제거할 수 있다.\n- 어떤 프로그래밍 언어로도 작성할 수 있다.\n- Helm과 통합되며 `helm help` 및 기타 위치에 표시된다.\n\nHelm 플러그인은 `$HELM_PLUGINS`에 위치한다. 환경에 설정되지 않은 경우\n기본값을 포함하여 현재 값은 `helm env` 명령어로 확인할 수 있다.\n\nHelm 플러그인 모델은 부분적으로 Git의 플러그인 모델을 기반으로 한다.\n그래서 때때로 `helm`을 _도자기(porcelain)_ 레이어로, 플러그인을\n_배관(plumbing)_ 이라고 부르기도 한다. 이것은 Helm이 사용자 경험과\n최상위 수준의 처리 로직을 제공하고, 플러그인은 원하는 작업을\n수행하는 \"세부 작업\"을 담당한다는 것을 간략히 표현한 것이다.\n\n## 플러그인 설치하기\n\n플러그인은 `$ helm plugin install <path|url>` 명령어를 사용하여 설치한다.\n로컬 파일 시스템의 플러그인 경로 또는 원격 VCS 저장소의 URL을 전달할 수 있다.\n`helm plugin install` 명령어는 지정된 경로/URL에서 플러그인을 `$HELM_PLUGINS`로\n복제하거나 복사한다. VCS에서 설치하는 경우 `--version` 인수로 버전을 지정할 수 있다.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\n플러그인 tar 배포판이 있는 경우, 플러그인을 `$HELM_PLUGINS` 디렉터리에\n압축 해제하면 된다. `helm plugin install\nhttps://domain/path/to/plugin.tar.gz`를 실행하여 URL에서 직접\ntarball 플러그인을 설치할 수도 있다.\n\n## 플러그인 파일 구조\n\n여러 면에서 플러그인은 차트와 유사하다. 각 플러그인에는 `plugin.yaml`\n파일이 포함된 최상위 디렉터리가 있다. 추가 파일이 있을 수 있지만\n`plugin.yaml` 파일만 필수이다.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## plugin.yaml 파일\n\nplugin.yaml 파일은 플러그인에 필수이다. 다음 필드를 포함한다.\n\n```yaml\nname: The name of the plugin (REQUIRED)\nversion: A SemVer 2 version (REQUIRED)\nusage: Single line usage text shown in help\ndescription: Long description shown in places like helm help\nignoreFlags: Ignore flags passed in from Helm\nplatformCommand: # Configure command to run based on the platform\n  - os: OS match, can be empty or omitted to match all OS'\n    arch: Architecture match, can be empty or omitted to match all architectures\n    command: Plugin command to execute\n    args: Plugin command arguments\ncommand: (DEPRECATED) Plugin command, use platformCommand instead\nplatformHooks: # Configure plugin lifecycle hooks based on the platform\n  install: # Install lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin install command to execute\n      args: Plugin install command arguments\n  update: # Update lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin update command to execute\n      args: Plugin update command arguments\n  delete: # Delete lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin delete command to execute\n      args: Plugin delete command arguments\nhooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead\n  install: Command to install plugin\n  update: Command to update plugin\n  delete: Command to delete plugin\ndownloaders: # Configure downloaders capability\n  - command: Command to invoke\n    protocols:\n      - Protocol schema supported\n```\n\n### `name` 필드\n\n`name`은 플러그인의 이름이다. Helm은 이 플러그인을 실행할 때\n이 이름을 사용한다(예: `helm NAME`이 이 플러그인을 호출한다).\n\n_`name`은 디렉터리 이름과 일치해야 한다._ 위의 예에서 `name: last`인\n플러그인은 `last`라는 이름의 디렉터리에 포함되어야 한다.\n\n`name`에 대한 제한 사항:\n\n- `name`은 기존 `helm` 최상위 명령어와 중복될 수 없다.\n- `name`은 ASCII 문자 a-z, A-Z, 0-9, `_`, `-`로 제한된다.\n\n### `version` 필드\n\n`version`은 플러그인의 SemVer 2 버전이다. `usage`와 `description`은\n모두 명령어의 도움말 텍스트를 생성하는 데 사용된다.\n\n### `ignoreFlags` 필드\n\n`ignoreFlags` 스위치는 Helm에 플래그를 플러그인에 전달하지 _않도록_ 지시한다.\n따라서 플러그인이 `helm myplugin --foo`로 호출되고 `ignoreFlags: true`인 경우,\n`--foo`는 조용히 무시된다.\n\n### `platformCommand` 필드\n\n`platformCommand`는 플러그인이 호출될 때 실행할 명령어를 구성한다.\n`platformCommand`와 `command`를 동시에 설정하면 오류가 발생한다.\n사용할 명령어를 결정할 때 다음 규칙이 적용된다.\n\n- `platformCommand`가 있으면 사용된다.\n  - `os`와 `arch`가 모두 현재 플랫폼과 일치하면, 검색을 중지하고\n  해당 명령어를 사용한다.\n  - `os`가 일치하고 `arch`가 비어 있으면, 해당 명령어를 사용한다.\n  - `os`와 `arch`가 모두 비어 있으면, 해당 명령어를 사용한다.\n  - 일치하는 항목이 없으면, Helm은 오류와 함께 종료된다.\n- `platformCommand`가 없고 더 이상 사용되지 않는 `command`가 있으면\n해당 명령어를 사용한다.\n  - 명령어가 비어 있으면, Helm은 오류와 함께 종료된다.\n\n### `platformHooks` 필드\n\n`platformHooks`는 플러그인이 라이프사이클 이벤트에 대해 실행할 명령어를 구성한다.\n`platformHooks`와 `hooks`를 동시에 설정하면 오류가 발생한다.\n사용할 훅 명령어를 결정할 때 다음 규칙이 적용된다.\n\n- `platformHooks`가 있으면 사용되고, 라이프사이클 이벤트에 대한\n명령어가 처리된다.\n  - `os`와 `arch`가 모두 현재 플랫폼과 일치하면, 검색을 중지하고\n  해당 명령어를 사용한다.\n  - `os`가 일치하고 `arch`가 비어 있으면, 해당 명령어를 사용한다.\n  - `os`와 `arch`가 모두 비어 있으면, 해당 명령어를 사용한다.\n  - 일치하는 항목이 없으면, Helm은 해당 이벤트를 건너뛴다.\n- `platformHooks`가 없고 더 이상 사용되지 않는 `hooks`가 있으면,\n라이프사이클 이벤트에 대한 명령어를 사용한다.\n  - 명령어가 비어 있으면, Helm은 해당 이벤트를 건너뛴다.\n\n## 플러그인 빌드하기\n\n다음은 마지막 릴리스 이름을 가져오는 간단한 플러그인의 YAML이다.\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\n플러그인에는 추가 스크립트와 실행 파일이 필요할 수 있다.\n스크립트는 플러그인 디렉터리에 포함하고, 실행 파일은\n훅을 통해 다운로드할 수 있다. 다음은 예제 플러그인이다.\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\n플러그인이 실행되기 전에 환경 변수가 보간된다.\n위의 패턴은 플러그인 프로그램의 위치를 나타내는 권장 방식이다.\n\n### 플러그인 명령어\n\n플러그인 명령어 작업을 위한 몇 가지 전략이 있다.\n\n- 플러그인에 실행 파일이 포함된 경우, `platformCommand:` 또는\n  에 해당하는 실행 파일은 플러그인 디렉터리에 패키징하거나\n  훅을 통해 설치해야 한다.\n- `platformCommand:` 또는 `command:` 줄은 실행 전에 환경 변수가\n  확장된다. `$HELM_PLUGIN_DIR`은 플러그인 디렉터리를 가리킨다.\n- 명령어 자체는 셸에서 실행되지 않는다. 따라서 셸 스크립트를\n  한 줄로 작성할 수 없다.\n- Helm은 많은 설정을 환경 변수에 주입한다. 사용 가능한 정보를\n  확인하려면 환경을 살펴보자.\n- Helm은 플러그인 언어에 대해 가정하지 않는다. 원하는 언어로\n  작성할 수 있다.\n- 명령어는 `-h`와 `--help`에 대한 특정 도움말 텍스트를 구현해야 한다.\n  Helm은 `helm help`와 `helm help myplugin`에 `usage`와 `description`을\n  사용하지만, `helm myplugin --help`는 처리하지 않는다.\n\n### 로컬 플러그인 테스트하기\n\n먼저 `HELM_PLUGINS` 경로를 찾아야 한다. 다음 명령어를 실행한다.\n\n``` bash\nhelm env\n```\n\n현재 디렉터리를 `HELM_PLUGINS`가 설정된 디렉터리로 변경한다.\n\n이제 플러그인의 빌드 출력에 대한 심볼릭 링크를 추가할 수 있다.\n이 예에서는 `mapkubeapis`에 대해 수행했다.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## 다운로더 플러그인\n\n기본적으로 Helm은 HTTP/S를 사용하여 차트를 가져올 수 있다.\nHelm 2.4.0부터 플러그인은 임의의 소스에서 차트를 다운로드하는\n특수 기능을 가질 수 있다.\n\n플러그인은 `plugin.yaml` 파일(최상위 수준)에서 이 특수 기능을\n선언해야 한다.\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\n이러한 플러그인이 설치되면, Helm은 `command`를 호출하여 지정된\n프로토콜 스키마를 사용하여 저장소와 상호 작용할 수 있다.\n특수 저장소는 일반 저장소와 유사하게 추가된다:\n`helm repo add favorite myprotocol://example.com/`\n특수 저장소에 대한 규칙은 일반 저장소와 동일하다:\nHelm이 사용 가능한 차트 목록을 검색하고 캐시하려면\n`index.yaml` 파일을 다운로드할 수 있어야 한다.\n\n정의된 명령어는 `command certFile keyFile caFile full-URL` 스키마로\n호출된다. SSL 자격 증명은 `$HELM_REPOSITORY_CONFIG`\n(즉, `$HELM_CONFIG_HOME/repositories.yaml`)에 저장된\n저장소 정의에서 가져온다. 다운로더 플러그인은 원시 콘텐츠를\nstdout에 덤프하고 오류를 stderr에 보고해야 한다.\n\n다운로더 명령어는 하위 명령어나 인수도 지원하므로, 예를 들어\n`plugin.yaml`에 `bin/mydownloader subcommand -d`를 지정할 수 있다.\n이것은 메인 플러그인 명령어와 다운로더 명령어에 동일한 실행 파일을\n사용하되, 각각에 대해 다른 하위 명령어를 사용하려는 경우에 유용하다.\n\n## 환경 변수\n\nHelm은 플러그인을 실행할 때 외부 환경을 플러그인에 전달하고,\n추가 환경 변수도 주입한다.\n\n`KUBECONFIG`와 같은 변수는 외부 환경에서 설정된 경우\n플러그인에 대해 설정된다.\n\n다음 변수는 항상 설정된다.\n\n- `HELM_PLUGINS`: 플러그인 디렉터리의 경로.\n- `HELM_PLUGIN_NAME`: `helm`에 의해 호출된 플러그인의 이름.\n  따라서 `helm myplug`는 짧은 이름 `myplug`를 갖는다.\n- `HELM_PLUGIN_DIR`: 플러그인이 포함된 디렉터리.\n- `HELM_BIN`: (사용자가 실행한) `helm` 명령어의 경로.\n- `HELM_DEBUG`: Helm에 의해 디버그 플래그가 설정되었는지 나타낸다.\n- `HELM_REGISTRY_CONFIG`: (사용하는 경우) 레지스트리 설정 위치.\n  레지스트리와 함께 Helm을 사용하는 것은 실험적 기능임에 유의하자.\n- `HELM_REPOSITORY_CACHE`: 저장소 캐시 파일의 경로.\n- `HELM_REPOSITORY_CONFIG`: 저장소 설정 파일의 경로.\n- `HELM_NAMESPACE`: `helm` 명령어에 지정된 네임스페이스\n  (일반적으로 `-n` 플래그 사용).\n- `HELM_KUBECONTEXT`: `helm` 명령어에 제공된 Kubernetes 설정\n  컨텍스트의 이름.\n\n또한, Kubernetes 설정 파일이 명시적으로 지정된 경우\n`KUBECONFIG` 변수로 설정된다.\n\n## 플래그 파싱에 대한 참고 사항\n\n플러그인을 실행할 때, Helm은 자체 사용을 위해 전역 플래그를 파싱한다.\n이러한 플래그는 플러그인에 전달되지 않는다.\n\n- `--burst-limit`: `$HELM_BURST_LIMIT`로 변환된다.\n- `--debug`: 지정하면 `$HELM_DEBUG`가 `1`로 설정된다.\n- `--kube-apiserver`: `$HELM_KUBEAPISERVER`로 변환된다.\n- `--kube-as-group`: `$HELM_KUBEASGROUPS`로 변환된다.\n- `--kube-as-user`: `$HELM_KUBEASUSER`로 변환된다.\n- `--kube-ca-file`: `$HELM_KUBECAFILE`로 변환된다.\n- `--kube-context`: `$HELM_KUBECONTEXT`로 변환된다.\n- `--kube-insecure-skip-tls-verify`: `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`로 변환된다.\n- `--kube-tls-server-name`: `$HELM_KUBETLS_SERVER_NAME`로 변환된다.\n- `--kube-token`: `$HELM_KUBETOKEN`로 변환된다.\n- `--kubeconfig`: `$KUBECONFIG`로 변환된다.\n- `--namespace` 및 `-n`: `$HELM_NAMESPACE`로 변환된다.\n- `--qps`: `$HELM_QPS`로 변환된다.\n- `--registry-config`: `$HELM_REGISTRY_CONFIG`로 변환된다.\n- `--repository-cache`: `$HELM_REPOSITORY_CACHE`로 변환된다.\n- `--repository-config`: `$HELM_REPOSITORY_CONFIG`로 변환된다.\n\n플러그인은 `-h`와 `--help`에 대해 도움말 텍스트를 표시하고 종료해야 _한다_.\n다른 모든 경우에는 플러그인이 적절하게 플래그를 사용할 수 있다.\n\n## 셸 자동 완성 제공\n\nHelm 3.2부터 플러그인은 Helm의 기존 자동 완성 메커니즘의 일부로\n셸 자동 완성 지원을 선택적으로 제공할 수 있다.\n\n### 정적 자동 완성\n\n플러그인이 자체 플래그 및/또는 하위 명령어를 제공하는 경우,\n플러그인의 루트 디렉터리에 `completion.yaml` 파일을 두어\nHelm에 알릴 수 있다. `completion.yaml` 파일의 형식은 다음과 같다.\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\n유의 사항:\n\n1. 모든 섹션은 선택 사항이지만 해당되는 경우 제공해야 한다.\n1. 플래그에는 `-` 또는 `--` 접두사를 포함하지 않아야 한다.\n1. 짧은 플래그와 긴 플래그 모두 지정할 수 있고 지정해야 한다.\n   짧은 플래그가 해당하는 긴 형식과 연결될 필요는 없지만,\n   두 형식 모두 나열해야 한다.\n1. 플래그는 어떤 방식으로든 정렬할 필요가 없지만, 파일의\n   하위 명령어 계층 구조에서 올바른 위치에 나열해야 한다.\n1. Helm의 기존 전역 플래그는 이미 Helm의 자동 완성 메커니즘에서\n   처리되므로, 플러그인은 `--debug`, `--namespace` 또는 `-n`,\n   `--kube-context`, `--kubeconfig` 또는 기타 전역 플래그를\n   지정할 필요가 없다.\n1. `validArgs` 목록은 하위 명령어 다음의 첫 번째 매개변수에 대해\n   가능한 완성의 정적 목록을 제공한다. 이러한 목록을 미리\n   제공하는 것이 항상 가능하지는 않다(아래 [동적\n   완성](#동적-완성) 섹션 참조). 이 경우 `validArgs` 섹션을\n   생략할 수 있다.\n\n`completion.yaml` 파일은 전적으로 선택 사항이다. 제공되지 않으면\nHelm은 플러그인에 대한 셸 자동 완성을 제공하지 않는다(플러그인이\n[동적 완성](#동적-완성)을 지원하지 않는 한). 또한, `completion.yaml`\n파일을 추가하는 것은 이전 버전과 호환되며 이전 Helm 버전을 사용할 때\n플러그인 동작에 영향을 주지 않는다.\n\n예를 들어, 하위 명령어는 없지만 `helm status` 명령어와 동일한 플래그를\n허용하는 [`fullstatus 플러그인`](https://github.com/marckhouzam/helm-fullstatus)의\n경우, `completion.yaml` 파일은 다음과 같다.\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\n더 복잡한 예로 [`2to3 플러그인`](https://github.com/helm/helm-2to3)의\n`completion.yaml` 파일은 다음과 같다.\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### 동적 완성\n\nHelm 3.2부터 플러그인은 자체 동적 셸 자동 완성을 제공할 수 있다.\n동적 셸 자동 완성은 미리 정의할 수 없는 매개변수 값 또는 플래그 값의\n완성이다. 예를 들어, 현재 클러스터에서 사용 가능한 Helm 릴리스 이름의 완성이 있다.\n\n플러그인이 동적 자동 완성을 지원하려면, 루트 디렉터리에 `plugin.complete`라는\n**실행 파일**을 제공해야 한다. Helm 완성 스크립트가 플러그인에 대한\n동적 완성을 필요로 할 때, 완성해야 할 명령줄을 전달하여 `plugin.complete`\n파일을 실행한다. `plugin.complete` 실행 파일에는 적절한 완성 선택지가\n무엇인지 결정하고 Helm 완성 스크립트가 사용할 수 있도록 표준 출력으로\n출력하는 로직이 있어야 한다.\n\n`plugin.complete` 파일은 전적으로 선택 사항이다. 제공되지 않으면\nHelm은 플러그인에 대한 동적 자동 완성을 제공하지 않는다. 또한,\n`plugin.complete` 파일을 추가하는 것은 이전 버전과 호환되며\n이전 Helm 버전을 사용할 때 플러그인 동작에 영향을 주지 않는다.\n\n`plugin.complete` 스크립트의 출력은 다음과 같이 줄바꿈으로 구분된\n목록이어야 한다.\n\n```console\nrel1\nrel2\nrel3\n```\n\n`plugin.complete`가 호출되면, 플러그인의 메인 스크립트가 호출될 때와\n마찬가지로 플러그인 환경이 설정된다. 따라서 `$HELM_NAMESPACE`,\n`$HELM_KUBECONTEXT` 및 기타 모든 플러그인 변수가 이미 설정되어 있고,\n해당하는 전역 플래그는 제거된다.\n\n`plugin.complete` 파일은 어떤 실행 형식이든 될 수 있다. 셸 스크립트,\nGo 프로그램 또는 Helm이 실행할 수 있는 다른 유형의 프로그램이 될 수 있다.\n`plugin.complete` 파일은 사용자에 대해 ***반드시*** 실행 권한이 있어야 한다.\n`plugin.complete` 파일은 ***반드시*** 성공 코드(값 0)와 함께 종료되어야 한다.\n\n경우에 따라 동적 완성은 Kubernetes 클러스터에서 정보를 가져와야 한다.\n예를 들어, `helm fullstatus` 플러그인은 입력으로 릴리스 이름이 필요하다.\n`fullstatus` 플러그인에서 `plugin.complete` 스크립트가 현재 릴리스 이름에\n대한 완성을 제공하려면, 단순히 `helm list -q`를 실행하고 결과를 출력하면 된다.\n\n플러그인 실행과 플러그인 완성에 동일한 실행 파일을 사용하려면,\n`plugin.complete` 스크립트가 특별한 매개변수나 플래그와 함께\n메인 플러그인 실행 파일을 호출하도록 만들 수 있다.\n메인 플러그인 실행 파일이 특별한 매개변수나 플래그를 감지하면,\n완성을 실행해야 함을 알게 된다.\n이 예에서 `plugin.complete`는 다음과 같이 구현할 수 있다.\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\n`fullstatus` 플러그인의 실제 스크립트(`status.sh`)는 `--complete` 플래그를\n찾아야 하며, 발견되면 적절한 완성을 출력해야 한다.\n\n### 팁과 요령\n\n1. 셸은 사용자 입력과 일치하지 않는 완성 선택지를 자동으로 필터링한다.\n   따라서 플러그인은 사용자 입력과 일치하지 않는 것을 제거하지 않고\n   관련된 모든 완성을 반환할 수 있다. 예를 들어, 명령줄이\n   `helm fullstatus ngin<TAB>`인 경우, `plugin.complete` 스크립트는\n   `ngin`으로 시작하는 것뿐만 아니라 (`default` 네임스페이스의)\n   *모든* 릴리스 이름을 출력할 수 있다. 셸이 `ngin`으로 시작하는\n   것만 유지한다.\n1. 특히 복잡한 플러그인이 있는 경우, 동적 완성 지원을 단순화하기 위해\n   `plugin.complete` 스크립트가 메인 플러그인 스크립트를 호출하고\n   완성 선택지를 요청하도록 할 수 있다. 예제는 위의\n   [동적 완성](#동적-완성) 섹션을 참조하자.\n1. 동적 완성과 `plugin.complete` 파일을 디버깅하려면, 다음을 실행하여\n   완성 결과를 확인할 수 있다.\n    - `helm __complete <pluginName> <arguments to complete>`. 예를 들어:\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: 헬름 출처 및 무결성\ndescription: 차트의 무결성과 출처를 검증하는 방법을 설명한다.\nsidebar_position: 5\n---\n\n헬름에는 차트 사용자가 패키지의 무결성과 출처를 검증하는 데 도움이 되는 출처 도구가 있다.\n헬름은 PKI, GnuPG 및 평판이 좋은 패키지 관리자에 기반한 업계 표준 도구를 사용하여\n서명 파일을 생성하고 검증할 수 있다.\n\n## 개요\n\n무결성은 차트를 출처기록과 비교하여 설정된다. 출처 레코드는 \n패키지된 차트와 함께 저장되는 _출처 파일_에 저장된다. 예를 들어 차트 이름이 `myapp-1.2.3.tgz` 인 경우 \n출처 파일은 `myapp-1.2.3.tgz.prov` 이 된다.\n\n출처 파일은 패키징 시 (`helm package --sign ...`) 에 생성되며, 여러 가지 명령어로\n확인할 수 있는데 흔히 `helm install --verify` 를 사용한다.\n\n## 작업흐름\n\n이 섹션에서는 출처 데이터를 효과적으로 사용하기 위한 작업흐름 예시를 \n설명한다.\n\n전제 조건:\n\n- (ASCII-armored가 아닌) 바이너리 형식의 유효한 PGP 키페어\n- `helm` 명령줄 도구\n- GnuPG 명령줄 도구 (선택사항)\n- 키베이스(Keybase) 명령줄 도구 (선택사항)\n\n**참고:** PGP 개인 키에 암호가 있을 경우 `--sign` 옵션을 지원하는\n명령어에 대해 해당 암호를 입력하라는 메시지가 표시된다.\n\n새 차트를 만드는 방법은 이전과 동일하다.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n패키징할 준비가 되면 `--sign` 플래그를 `helm package` 에 \n추가해야 한다. 또한 서명 키가 알려진 이름과 해당 개인 키를 포함하는 \n키링을 지정해야 한다.\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**참고:** `--key` 인수의 값은 이름 또는 이메일과 같이 원하는 키의 \n`uid` (`gpg --list-keys` 출력에 존재)의 \n하위 문자여야 한다. **지문(fingerprint)은 사용할 수 _없다_**\n\n**팁:** GnuPG 사용자의 경우 비밀 키링은 `~/.gnupg/secring.gpg` 에 존재한다.\n`gpg --list-secret-keys` 를 사용하여 보유한 키를 나열할 수 있다.\n\n**경고:** GnuPG v2는 기본 위치 `~/.gnupg/pubring.kbx` 에 \n새로운 형식 `kbx` 를 사용하여 비밀 키링을 저장한다.\n다음 명령어를 사용하여 키링을 레거시 gpg 형식으로 변환한다.\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\n이 시점에서, `mychart-0.1.0.tgz` 와 \n`mychart-0.1.0.tgz.prov` 가 모두 표시되어야 한다. 결국 두 파일 모두\n원하는 차트 저장소에 업로드되어야 한다.\n\n`helm verify` 를 사용하여 차트를 검증할 수 있다.\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\n검증에 실패한 경우 다음과 같다.\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\n설치 중에 검증하려면 `--verify` 플래그를 사용한다.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\n서명된 차트와 연결된 공개키와 포함된 키링이 기본 위치에 없으면 \n`helm package` 예제에서와 같이 사용자가 `--keyring PATH`로\n키링의 위치를 지정해야 할 수 있다.\n\n검증에 실패하면 차트가 렌더링되기 전에 설치가 \n중단된다.\n\n### Keybase.io 자격증명 사용하기\n\n[Keybase.io](https://keybase.io) 서비스를 사용하면 암호화 ID에 대한\n신뢰 체인을 쉽게 설정할 수 있다. keybase 자격 증명은 차트에 서명하는데\n사용될 수 있다.\n\n전제 조건:\n\n- 구성된 Keybase.io 계정\n- 로컬에 설치된 GnuPG\n- 로컬에 설치된 `keybase` CLI\n\n#### 패키지 서명하기\n\n첫 번째 단계는 keybase 키를 로컬 GnuPG 키링으로 가져오는 것이다.\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\n이렇게 하면 Kyebase 키가 OpenPGP 형식으로 변환된 다음 \n`~/.gnupg/secring.gpg` 파일로 로컬에 저장한다.\n\n`gpg --list-secret-keys` 를 실행하여 다시 확인할 수 있다.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\n비밀 키에는 식별자 문자열이 있다.\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\n이것이 키의 전체 이름이다.\n\n다음으로 `helm package` 로 차트를 패키징하고 서명할 수 있다.\n최소한 `--key` 에서 해당 이름 문자열의 일부는 사용해야 한다.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\n결과적으로, `package` 명령어는 `.tgz` 파일과 `.tgz.prov` 파일 모두를\n생성해야 한다.\n\n#### 패키지 검증하기\n\n유사한 기술을 사용하여 다른 사람의 keybase 키로 서명된 차트를 검증할 수 있다. \n`keybase.io/technosophos` 로 서명된 패키지를 검증하려는 경우를 생각해보자. \n그런 경우 `keybase` 도구를 사용해야 한다.\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\n위의 첫 번째 명령어는 `technosophos` 사용자를 추적한다. 다음으로 \n`keybase pgp pull` 은 팔로우하는 모든 계정의 OpenPGP 키를 다운로드하여\nGnuPG 키링(`~/.gnupg/pubring.gpg`)에 배치한다.\n\n이 시점에서 이제 `helm verify` 또는 `--verify` 플래그가 있는 명령어를 사용할\n수 있다.\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### 차트가 검증되지 않는 이유\n\n실패하는 이유는 주로 다음과 같다.\n\n- `.prov` 파일이 없거나 손상된 경우다. 이것은 무언가가 \n  잘못 구성되었거나 기존 관리자가 출처 파일을 \n  만들지 않은 경우이다.\n- 파일 서명에 사용된 키가 키링에 없는 경우이다. \n  이는 차트에 서명한 엔티티가 사용자가 \n  신뢰한다고 신호를 보낸 사람이 아님을 의미한다.\n- `.prov` 파일 검증에 실패한 경우다. 이는 차트 또는 출처 데이터에 문제가 있음을\n  나타낸다.\n- 출처 파일의 파일 해시가 아카이브 파일의 해시와 일치하지 않는 경우이다.\n  이는 아카이브가 변조되었음을 나타낸다.\n\n검증이 실패한다면 그 패키지를 신뢰할 수 없는 이유가 된다.\n\n## 출처 파일\n\n출처 파일에는 차트의 YAML 파일과 몇 가지 \n검증 정보가 포함되어 있다.\n출처 파일은 자동으로 생성되도록 설계되어 있다.\n\n다음과 같은 출처 데이터가 추가된다.\n\n* 차트 파일(`Chart.yaml`) 이 포함되어 있어 사람과 도구 모두 차트 내용을 쉽게 \n  볼 수 있다.\n* 차트 패키지(`.tgz` 파일)의 서명(도커와 마찬가지로 SHA256)이 포함되어 있으며\n  차트 패키지의 무결성을 검증하는 데\n  사용할 수 있다.\n* 전체 본문은 OpenPGP 에서 사용하는 \n  알고리즘을 사용하여 서명된다(암호화 서명 및 \n  검증을 쉽게 하는 새로운 방법은 [Keybase.io](https://keybase.io) 참고하자).\n\n이러한 조합은 사용자에게 다음과 같은 보증을 제공한다.\n\n* 패키지 자체가 변경되지 않았다. (체크섬 패키지 `.tgz`)\n* 이 패키지를 출시한 엔티티가 (GnuPG/PGP 서명을 통해) 알려져 있다. \n\n파일 형식은 다음과 같다.\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: 1.16.0\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nYAML 섹션에는 (`...\\n` 로 구분되는) 두 개의 문서가 포함되어 있다. \n첫 번째 파일은 `Chart.yaml` 의 내용이다. \n두 번째는 패키징 시 해당 파일 콘텐츠의 SHA-256 다이제스트에 대한 파일 이름 맵인 체크섬 파일이다.\n\n서명 블록은 [변조 방지](https://www.rossde.com/PGP/pgp_signatures.html)를 \n제공하는 표준 PGP 서명이다.\n\n## 차트 저장소\n\n차트 저장소는 헬름 차트의 중앙 집중식 콜렉션 역할을 한다.\n\n차트 저장소는 특정 요청을 통해 HTTP를 통해 \n출처 파일을 제공할 수 있도록 해야 하며 차트와 \n동일하게 URI 경로에서 사용할 수 있도록 해야 한다.\n\n예를 들어 패키지의 기본 URL이 \n`https://example.com/charts/mychart-1.2.3.tgz` 일 때 \n출처 파일이 있는 경우에는, \n`https://example.com/charts/mychart-1.2.3.tgz.prov` 에서 접근할 수 있어야 한다. \n\n최종 사용자의 관점에서 `helm install --verify myrepo/mychart-1.2.3` 은 \n추가 사용자 구성이나 작업없이 차트와 출처 파일을 모두\n다운로드해야 한다.\n\n### OCI 기반 레지스트리에서의 서명\n\n차트를 [OCI 기반 레지스트리](./registries.md)에 게시할 때,\n[`helm-sigstore` 플러그인](https://github.com/sigstore/helm-sigstore/)을 사용하여\n[sigstore](https://sigstore.dev/)에 출처를 게시할 수 있다.\n[문서에 설명된 바와 같이](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md),\n출처를 생성하고 GPG 키로 서명하는 과정은 동일하지만,\n`helm sigstore upload` 명령어를 사용하여 출처를 불변의 투명성 로그에 게시할 수 있다.\n\n## 권한 및 인증 확립하기\n\n신뢰 체인 시스템을 다룰 때는 서명자의 권한을 수립할 수 있게\n하는 것이 중요하다. 쉽게 말하면, 이 체계는 \n차트에 서명한 사람을 신뢰할 수 있는지에 달려 있다.\n바꿔 말하면, 서명자의 공개키를 신뢰할 필요가 있다는 것을 의미한다.\n\n헬름의 디자인 철학 중 하나는, 헬름 프로젝트가 신뢰 체인에 \n필요한 당사자로 자기 자신을 포함시키지 않는다는 것이다. \n우리는 모든 차트 서명자의 \"인증기관\"이 되고 싶지 않다.\n대신 우리는 탈중앙화 모델을 선호하며, \nOpenPGP를 기반 기술로 선택한 이유 중 하나이다.\n따라서 권한 수립에 관한 진행단계는 헬름 2(헬름 3로 넘김)에서\n정의되지 않은 채로 남아 있다 .\n\n하지만, 출처 시스템 사용에 관심이 있는 분들을 위한 몇 가지 조언과\n권장 사항은 있다.\n\n- [Keybase](https://keybase.io) 플랫폼은 신뢰 정보를 위한 공개 중앙 \n  저장소를 제공한다.\n  - Keybase를 사용하여 키를 저장하거나 다른 사람의 공개 키를 가져올 수 있다.\n  - Keybase 에는 사용 가능한 훌륭한 문서도 존재한다.\n  - 테스트되진 않았지만, Keybase 의 \"보안 웹사이트\" 기능을 사용하여\n    헬름 차트를 제공할 수도 있다.\n  - 기본 아이디어는 공식 \"차트 리뷰어\"가 자신의 키로 차트에 서명하고\n    생성된 출처 파일을 차트 저장소에 업로드하는 것이다.\n  - 저장소의 `index.yaml` 파일에 유효한 서명 키 목록이 포함될 수 있다는 \n    아이디어에 대한 몇 가지 작업이 있었다.\n\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: 역할 기반 접근 제어\ndescription: 헬름이 쿠버네티스의 역할 기반 접근 제어와 상호 작용하는 방법을 설명한다.\nsidebar_position: 11\n---\n\n쿠버네티스에서 사용자 또는 애플리케이션별 서비스 계정에 \n역할을 부여하는 것은 애플리케이션이 지정한 권한범위 내에서 작동하도록 \n하는 모범 사례이다. [공식 쿠버네티스 \n문서에서](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions) 서비스 계정 권한에 대해 \n자세히 알아보도록 하자.\n\n쿠버네티스 1.6 부터는 역할 기반 접근 제어(RBAC)가 기본적으로 활성화된다.\nRBAC을 사용하면 조직에서 사용자와 역할에 따라 허용되는\n작업유형을 지정할 수 있다.\n\nRBAC을 사용하여, 사용자는 다음을 수행할 수 있다.\n\n- 관리자에게 특별 작업권한(새 역할과 같은 클러스터 전체 리소스 생성)을 \n  부여한다.\n- 리소스(파드, 퍼시스턴트 볼륨, \n  디플로이먼트)를 생성하는 사용자의 권한을 특정 네임스페이스 또는 클러스터 전체 범위(리소스 \n  할당량, 역할, 사용자 지정 리소스 정의)로 제한한다.\n- 특정 네임스페이스 또는 클러스터 전체 범위에서 리소스를 볼 수 있는 사용자의\n  권한을 제한한다.\n\n이 가이드는 사용자와 쿠버네티스 API 의 상호작용 범위를 제한하려는\n관리자를 위한 것이다.\n\n## 사용자 계정 관리\n\n모든 쿠버네티스 클러스터에는 2가지 사용자 카테고리가 있다: 일반 사용자와 쿠버네티스가 관리하는\n서비스 계정\n\n일반 사용자는 외부의 독립적인 서비스에 의해 관리되는 것으로 간주한다. 관리자가 개인키를 \n발급해주면, 사용자는 키스톤이나 구글 어카운트(Google Accounts)에 보관하거나 그냥\n사용자 이름 및 비밀번호 목록을 파일에 보관할 수도 있다. 이와 관련하여 쿠버네티스에는 \n일반 사용자 계정을 나타내는 객체가 없다. 일반 사용자는 \nAPI 호출을 통해 클러스터에 추가될 수 없다.\n\n반대로 서비스 계정은 쿠버네티스 API로 관리되는 사용자이다. 특정 \n네임스페이스에 바인딩 되며 API 서버에 의해 자동으로 생성되거나 \nAPI 호출을 통해 수동으로 생성된다. 서비스 계정은 시크릿으로 \n저장된 자격증명 집합에 연결되어 있으며, 파드에 마운트되어 클러스터 \n내 프로세스가 쿠버네티스 API와 통신할 수 있도록 한다.\n\nAPI 요청은 일반 사용자 또는 서비스 계정에 연결되거나 \n익명의 요청으로 처리된다. 즉, 워크스테이션에서 `kubectl` 을 \n입력하는 실제 사용자, 노드의 kubelet, 컨트롤 플레인의 구성원에 \n이르기까지 클러스터 내부 또는 외부의 모든 프로세스는 API 서버에 요청할 때 \n인증을 받거나 익명의 사용자로 취급되어야 한다는 것을 의미한다. \n\n## 롤, 클러스터롤, 롤바인딩, 클러스터롤바인딩\n\n쿠버네티스에서 사용자 계정 및 서비스 계정은 \n접근 권한이 부여된 리소스만을 보고 편집할 수 있다. \n이 접근은 롤 및 롤바인딩을 통해 부여된다. 롤 및 롤바인딩은 \n특정 네임스페이스에 바인딩되어 롤이 사용자에게 접근을 제공하는 \n동안 네임스페이스 내의 리소스를 보거나 편집할 수 있는 권한이 부여된다.\n\n클러스터 범위에서는 이를 클러스터롤 및 클러스터롤바인딩이라고 한다. \n사용자에게 클러스터롤을 부여하면 전체 클러스터에서 리소스를 보거나 \n편집할 수 있는 접근 권한이 부여된다. 또한 클러스터 범위(네임스페이스, \n리소스 할당량, 노드)에서 리소스를 보거나 편집할 수 있다.\n\n클러스터롤은 롤바인딩의 참조를 통해 특정 네임스페이스에 바인딩 \n될 수 있다. `admin`, `edit` 및 `view` 기본 클러스터롤은 \n일반적으로 이러한 방식으로 사용된다.\n\n쿠버네티스에서 기본적으로 사용할 수 있는 몇가지 클러스터롤들이 있다. 이는 \n사용자와 직접 연계하기 위해서이다. 여기에는 super-user 롤 \n(`cluster-admin`)과 더 세분화된 접근 권한(`admin`, `edit`, \n`view`)이 포함된다.\n\n| 기본 클러스터롤           | 기본 클러스터롤바인딩              | 설명\n|---------------------|----------------------------|-------------\n| `cluster-admin`     | `system:masters` group     | super-user를 허용하여 모든 리소스에서 작업을 수행할 수 있다. 클러스터롤바인딩에서 사용하면 클러스터 및 모든 네임스페이스의 모든 리소스를 완전히 제어할 수 있다. 롤바인딩에서 사용하면 네임스페이스 자체를 포함하여 롤바인딩의 네임스페이스에 있는 모든 리소스에 대한 모든 권한을 제공한다.\n| `admin`             | None                       | 롤바인딩을 사용하여 네임스페이스 내에서 부여되도록 의도된 관리자 접근을 허용한다. 롤바인딩에서 사용되는 경우 네임스페이스 내에서 롤 및 롤바인딩을 만드는 기능을 포함하여 네임스페이스의 대부분의 리소스에 대한 읽기/쓰기 접근을 허용한다. 리소스 할당량 또는 네임스페이스 자체에 대한 쓰기 접근은 허용하지 않는다.\n| `edit`              | None                       | 네임스페이스에 있는 대부분의 오브젝트에 대한 읽기/쓰기 접근을 허용한다. 롤 및 롤바인딩을 보거나 수정할수는 없다.\n| `view`              | None                       | 읽기 전용 접근을 허용하여 네임스페이스에 있는 대부분의 오브젝트를 볼 수 있다. 롤 및 롤바인딩을 보는 것은 허용되지 않는다. 마찬가지로 시크릿을 보는 것은 허용되지 않는다.\n\n## RBAC을 사용하여 사용자 계정의 접근 제한하기\n\n이제 역할 기반 접근의 기본 사항을 이해했으므로, 관리자가 사용자의 접근 범위를\n제한하는 방법에 대해 알아보자.\n\n### 예: 사용자에게 특정 네임스페이스에 대한 읽기/쓰기 접근 권한 부여하기\n\n특정 네임스페이스에 대한 사용자의 접근을 제한하려면 `edit` 또는 `admin` \n롤을 사용할 수 있다. 차트가 롤 및 롤바인딩을 생성하거나 상호작용하는 경우 \n`admin` 클러스터롤을 사용하는 것이 좋다.\n\n또한 `cluster-admin` 접근 권한으로 롤바인딩을 만들 수도 있다. \n네임스페이스 범위에서 사용자에게 `cluster-admin` 접근 권한을 부여하면 \n네임스페이스 자체를 포함하여 네임스페이스의 모든 리소스를 완전히 제어할 수 있다.\n\n이 예시에서는 `edit` 역할을 가진 사용자를 생성한다. 먼저 네임스페이스를\n만든다.\n\n```console\n$ kubectl create namespace foo\n```\n\n이제 해당 네임스페이스에 롤바인딩을 만들어서 사용자에게 `edit` 롤을 부여한다.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### 예: 사용자에게 클러스터 범위에서 읽기/쓰기 접근 권한 부여하기\n\n사용자가 클러스터 범위 리소스\n(네임스페이스, 롤, 사용자 지정 리소스 정의 등)를 \n설치하는 차트를 설치하려는 경우, 클러스터 범위의 쓰기 접근이 필요하다.\n\n이를 위해 사용자에게 `admin` 또는 `cluster-admin` 접근 권한을 부여한다.\n\n사용자에게 `cluster-admin` 접근 권한을 부여하면 \n`kubectl drain` 을 사용한 노드 접근 및 기타 관리 작업을 \n포함하여 쿠버네티스에서 사용할 수 있는 모든 리소스에 대한 접근 권한이 \n부여된다. 이 방식보다는 사용자에 `admin` 접근을 제공하거나 필요에 \n맞는 사용자 지정 클러스터롤을 생성하는 것을 권장한다.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### 예: 사용자에게 특정 네임스페이스에 대한 읽기 전용 접근 권한 부여하기\n\n시크릿을 볼 수 있는 클러스터롤이 없다는 것을 알아챘을지도 모르겠다.\n`view` 클러스터롤은 에스컬레이션 문제로 인해 사용자에게 시크릿에 \n대한 읽기 접근 권한을 부여하지 않는다. 헬름은 기본적으로 릴리스 메타 데이터를 시크릿으로 저장한다.\n\n사용자가 `helm list` 를 실행하려면 이러한 시크릿을 읽을 수 있어야 한다. 이를 위해\n특별한 `secret-reader` 클러스터롤을 생성한다.\n\n`cluster-role-secret-reader.yaml` 파일을 만들고 아래의 \n내용을 파일에 작성한다.\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\n그러고 나서, 다음을 사용하여 클러스터롤을 만든다.\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\n완료되면 사용자에게 대부분의 리소스에 대한 접근 권한을 부여한 다음 시크릿에 대한\n읽기 접근 권한을 부여할 수 있다.\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### 예: 클러스터 범위에서 사용자에게 읽기전용 접근 권한 부여하기\n\n특정 시나리오에서는 사용자에게 클러스터 범위 접근 권한을 부여하는 것이 유용할 수 있다. \n예를 들어 사용자가 `helm list --all-namespaces` 명령을 \n실행하려는 경우 API는 사용자에게 클러스터 범위 읽기 접근 권한이 있어야 한다.\n\n그렇게 하려면 위에서 설명한대로 사용자에게 `view` 및 `secret-reader` 접근 권한을 \n부여하되, 클러스터롤바인딩을 사용한다.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## 추가적인 고려사항\n\n위에 표시된 예는 쿠버네티스와 함께 제공되는 기본 클러스터롤을 \n활용한다. 사용자에게 접근 권한이 부여된 리소스를 더 세밀하게 \n제어하려면 고유한 사용자 지정 역할 및 클러스터롤 생성에 대한 \n[쿠버네티스 문서](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)를 \n참조하자.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: OCI 기반 레지스트리 사용\ndescription: 차트 배포를 위한 OCI 사용법을 설명한다.\nsidebar_position: 7\n---\n\nHelm 3부터 [OCI](https://www.opencontainers.org/) 지원이 가능한 컨테이너 레지스트리를 사용하여 차트 패키지를 저장하고 공유할 수 있다. Helm v3.8.0부터 OCI 지원이 기본적으로 활성화되어 있다.\n\n\n## v3.8.0 이전의 OCI 지원\n\nOCI 지원은 Helm v3.8.0에서 실험적 기능에서 정식(GA) 기능으로 전환되었다. 이전 버전의 Helm에서는 OCI 지원이 다르게 동작했다. Helm v3.8.0 이전에 OCI 지원을 사용했다면, 버전별로 변경된 사항을 이해하는 것이 중요하다.\n\n### v3.8.0 이전 OCI 지원 활성화\n\nHelm v3.8.0 이전에는 OCI 지원이 *실험적* 기능이었으며 수동으로 활성화해야 했다.\n\nHelm v3.8.0 이전 버전에서 OCI 실험적 지원을 활성화하려면 환경에서 `HELM_EXPERIMENTAL_OCI`를 설정한다. 예시:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### v3.8.0의 OCI 기능 지원 중단 및 동작 변경\n\n[Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) 릴리스에서는 이전 버전과 다음 기능 및 동작이 다르다:\n\n- 차트의 dependencies에서 OCI로 설정할 때 버전을 다른 dependencies처럼 범위로 지정할 수 있다.\n- 빌드 정보가 포함된 SemVer 태그를 푸시하고 사용할 수 있다. OCI 레지스트리는 태그 문자로 `+`를 지원하지 않는다. Helm은 태그로 저장할 때 `+`를 `_`로 변환한다.\n- `helm registry login` 명령이 이제 자격 증명 저장에 Docker CLI와 동일한 구조를 따른다. 레지스트리 설정에 동일한 위치를 Helm과 Docker CLI 모두에 전달할 수 있다.\n\n### v3.7.0의 OCI 기능 지원 중단 및 동작 변경\n\n[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) 구현이 포함되었다. 그 결과, 이전 버전과 다음 기능 및 동작이 다르다:\n\n- `helm chart` 하위 명령이 제거되었다.\n- 차트 캐시가 제거되었다 (`helm chart list` 등이 없음).\n- OCI 레지스트리 참조에는 이제 항상 `oci://` 접두사가 붙는다.\n- 레지스트리 참조의 기본 이름(basename)은 *항상* 차트의 이름과 일치해야 한다.\n- 레지스트리 참조의 태그는 *항상* 차트의 시맨틱 버전과 일치해야 한다 (즉, `latest` 태그 사용 불가).\n- 차트 레이어 미디어 타입이 `application/tar+gzip`에서 `application/vnd.cncf.helm.chart.content.v1.tar+gzip`으로 변경되었다.\n\n\n## OCI 기반 레지스트리 사용\n\n### OCI 기반 레지스트리의 Helm 리포지토리\n\n[Helm 리포지토리](/topics/chart_repository.md)는 패키지된 Helm 차트를 저장하고 배포하는 장소다. OCI 기반 레지스트리는 0개 이상의 Helm 리포지토리를 포함할 수 있으며, 각 리포지토리는 0개 이상의 패키지된 Helm 차트를 포함할 수 있다.\n\n### 호스팅 레지스트리 사용\n\nHelm 차트에 사용할 수 있는 OCI 지원 호스팅 컨테이너 레지스트리가 여러 개 있다. 예시:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\n호스팅 컨테이너 레지스트리 제공자의 문서를 따라 OCI 지원이 가능한 레지스트리를 생성하고 구성한다.\n\n**참고:** 개발 컴퓨터에서 OCI 기반 레지스트리인 [Docker Registry](https://docs.docker.com/registry/deploying/)나 [`zot`](https://github.com/project-zot/zot)를 실행할 수 있다. 개발 컴퓨터에서 OCI 기반 레지스트리를 실행하는 것은 테스트 목적으로만 사용해야 한다.\n\n### sigstore를 사용한 OCI 기반 차트 서명\n\n[`helm-sigstore`](https://github.com/sigstore/helm-sigstore) 플러그인을 사용하면 컨테이너 이미지 서명에 사용하는 것과 동일한 도구로 [Sigstore](https://sigstore.dev/)를 사용하여 Helm 차트에 서명할 수 있다. 이는 기존 [차트 리포지토리](/topics/chart_repository.md)에서 지원하는 [GPG 기반 출처 확인](/topics/provenance.md)의 대안을 제공한다.\n\n`helm sigstore` 플러그인 사용에 대한 자세한 내용은 [해당 프로젝트 문서](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md)를 참조한다.\n\n## 레지스트리 작업 명령어\n\n### `registry` 하위 명령\n\n#### `login`\n\n레지스트리에 로그인 (암호 수동 입력)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\n레지스트리에서 로그아웃\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### `push` 하위 명령\n\n차트를 OCI 기반 레지스트리에 업로드:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\n`push` 하위 명령은 `helm package`를 사용하여 미리 생성된 `.tgz` 파일에 대해서만 사용할 수 있다.\n\n`helm push`를 사용하여 OCI 레지스트리에 차트를 업로드할 때, 참조에는 반드시 `oci://` 접두사가 붙어야 하며 기본 이름(basename)이나 태그를 포함해서는 안 된다.\n\n레지스트리 참조의 기본 이름(basename)은 차트 이름에서 추론되고, 태그는 차트의 시맨틱 버전에서 추론된다. 이는 현재 엄격하게 요구되는 사항이다.\n\n일부 레지스트리에서는 리포지토리 및/또는 네임스페이스(지정된 경우)를 미리 생성해야 한다. 그렇지 않으면 `helm push` 작업 중 오류가 발생한다.\n\n[출처 파일](/topics/provenance.md) (`.prov`)을 생성했고, 이 파일이 차트 `.tgz` 파일 옆에 있으면 `push` 시 자동으로 레지스트리에 업로드된다. 이 경우 [Helm 차트 매니페스트](#helm-차트-매니페스트)에 추가 레이어가 생성된다.\n\n[helm-push 플러그인](https://github.com/chartmuseum/helm-push) (차트를 [ChartMuseum](/topics/chart_repository.md#chartmuseum-리포지토리-서버)에 업로드하기 위한) 사용자는 이 플러그인이 새로운 내장 `push`와 충돌하기 때문에 문제가 발생할 수 있다. v0.10.0 버전부터 플러그인은 `cm-push`로 이름이 변경되었다.\n\n### 기타 하위 명령\n\n`oci://` 프로토콜 지원은 다양한 다른 하위 명령에서도 사용할 수 있다. 전체 목록은 다음과 같다:\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\n차트 다운로드가 관련된 모든 유형의 작업에는 레지스트리 참조의 기본 이름(차트 이름)이 포함된다 (`helm push`에서는 생략됨).\n\n다음은 위에 나열된 하위 명령을 OCI 기반 차트에 사용하는 몇 가지 예시다:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## 다이제스트를 사용한 차트 설치\n\n다이제스트를 사용하여 차트를 설치하는 것은 태그보다 더 안전하다. 다이제스트는 불변이기 때문이다.\n다이제스트는 차트 URI에 지정한다:\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## dependencies 지정\n\n`dependency update` 하위 명령을 사용하여 레지스트리에서 차트의 dependencies를 가져올 수 있다.\n\n`Chart.yaml`의 특정 항목에 대한 `repository`는 기본 이름 없이 레지스트리 참조로 지정한다:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\n`dependency update`가 실행되면 `oci://localhost:5000/myrepo/mychart:2.7.0`을 가져온다.\n\n## Helm 차트 매니페스트\n\n레지스트리에 표시되는 Helm 차트 매니페스트 예시 (`mediaType` 필드 참고):\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\n다음 예시에는 [출처 파일](/topics/provenance.md)이 포함되어 있다 (추가 레이어 참고):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## 차트 리포지토리에서 마이그레이션\n\n기존 [차트 리포지토리](/topics/chart_repository.md) (index.yaml 기반 리포지토리)에서 마이그레이션하는 작업은 `helm pull`을 사용한 다음 `helm push`를 사용하여 생성된 `.tgz` 파일을 레지스트리에 업로드하면 된다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: 헬름 v2를 v3로 마이그레이션\ndescription: 헬름 v2를 v3로 마이그레이션하는 방법을 배운다.\nsidebar_position: 13\n---\n\n이 가이드에서는 헬름 v2를 v3로 마이그레이션하는 방법을 보여준다.\n헬름 v2가 설치되어 있어야 하며, 하나 이상의 클러스터에서 릴리스가 관리되어야 한다.\n\n## 헬름 3 변경사항 개요\n\n헬름 2 에서 3로의 변경사항 전체 목록은 [FAQ](/faq/changes_since_helm2.md)\n에 작성되어 있다. 다음은 \n마이그레이션 준비 및 작업간에 사용자가 알아야 할 몇 가지 변경 사항에 \n대한 요약이다:\n\n1. Tiller 제거:\n   - 클라이언트/서버 구조는 클라이언트/라이브러리 아키텍처로 대체됨 (`helm` 바이너리만\n     해당)\n   - 보안 서비스는 이제 사용자 단위로 제공됨 (쿠버네티스 사용자 클러스터 보안에\n     위임)\n   - 릴리스는 이제 클러스터 내의 시크릿으로 저장되고 릴리스 객체 메타 \n     데이터도 변경됨\n   - 릴리스는 더 이상 Tiller 네임스페이스가 아니라 릴리스 네임스페이스 \n     기반으로 유지됨\n2. 차트 저장소 업데이트:\n   - `helm search` 는 이제 로컬 저장소 검색과 Artifact Hub에 대한 검색 쿼리를 \n     모두 지원함\n3. 다음의 사양 변경에 대하여 차트 apiVersion 이 \"v2\"로 증가:\n   - 동적으로 연결된 차트 의존성이 `Chart.yaml` 로 이동됨\n     (`requirements.yaml` 제거되고, 요구사항(requirements) --> 의존성(dependencies)으로 변경)\n   - 라이브러리 차트(헬퍼/공통 차트)를 동적으로 연결된 차트 \n     의존성으로 추가 가능\n   - 차트를 `application` 또는 `library` 차트로 \n     정의하는 `type` 메타 데이터 필드를 가짐.\n     기본값은 application이며 렌더링 및 설치 가능하다는 의미\n   - 헬름 2 차트 (apiVersion=v1) 도 여전히 설치 가능함\n4. XDG 디렉토리 사양 추가:\n   - 헬름 홈이 제거되고 구성 파일 저장을 위한 XDG 디렉토리 \n     사양으로 대체\n   - 헬름 초기화 불필요\n   - `helm init` 와 `helm home` 명령어 제거\n5. 추가 변경 사항:\n   - Helm 설치/설정 단순화:\n     - 헬름 클라이언트 (헬름 바이너리) 만 있으면 됨 (Tiller 불필요)\n     - Run-as-is 패러다임\n   - `local` 또는 `stable` 저장소는 기본적으로 미설정 \n   - `crd-install` 훅은 제거되고,\n     차트 내 모든 CRD가 정의되어 있고 차트 렌더링 전에 설치되는\n     `crds` 디렉토리로 대체됨\n   - `test-failure` 훅 어노테이션 값은 제거되고, `test-success`는\n     사용 중단(deprecated).  대신 `test` 를 사용하자\n   - 제거/교체/추가 된 명령어:\n       - delete --> uninstall : 기본적으로 모든 릴리스 기록 제거\n         (예전에는 `--purge` 옵션이 필요했음)\n       - fetch --> pull\n       - home (제거됨)\n       - init (제거됨)\n       - install: 릴리스 이름 또는 `--generate-name` 인수 필요\n       - inspect --> show\n       - reset (제거됨)\n       - serve (제거됨)\n       - template: `-x`/`--execute` 인수의 이름이 `-s`/`--show-only` 로 변경\n       - upgrade: 릴리스당 저장되는 최대 리비젼 수를 제한하는 인수 `--history-max` 추가됨\n         (0은 무제한)\n   - 헬름 3 Go 라이브러리는 많은 변경을 거쳤으며, 헬름 2 라이브러리와는\n     호환되지 않음\n   - 릴리스 바이너리가 이제 `get.helm.sh` 에서 호스팅됨\n\n## 마이그레이션 사용 사례\n\n마이그레이션 사용 사례는 다음과 같다:\n\n1. 동일 클러스터를 관리하는 헬름 v2 및 v3:\n   - 이 사용 사례는 헬름 v2 를 단계적으로 제거하려는 경우에만 권장되며 \n     v2로 배포한 릴리스를 관리하는 데 v3가 필요한 것은 아니다. \n     배포되는 모든 새 릴리스는 v3 에서 수행해야 하며, \n     기존에 v2 로 배포된 릴리스는 v2 에서만 업데이트/제거된다.\n   - 헬름 v2 와 v3 는 같은 클러스터를 원활하게 관리할 수 있다.\n     헬름 버전들은 동일 또는 개별 시스템에 설치될 수 있다.\n   - 만약 동일한 시스템에 헬름 v3를 설치하는 경우, 헬름 v2 \n     클라이언트를 제거할 준비가 될 때까지 두 클라이언트 버전이 공존할 수 있도록 추가 \n     작업을 수행해야 한다. 충돌을 피하기 위해 \n     헬름 v3 바이너리의 이름을 바꾸거나 다른 폴더에 넣도록 한다.\n   - 그밖에는 다음과 같은 구별에 따라\n     두 버전 간에 충돌이 발생하지 않는다.\n\t - v2 및 v3 릴리스 (이력) 저장소는 서로 독립적이다. 변경 사항으로는\n\t   스토리지용 쿠버네티스 리소스와, 리소스에 포함된 릴리스 객체 메타 데이터가 있다.\n\t   릴리스는 또한 Tiller 네임스페이스를 사용하는 대신 사용자별 네임스페이스에\n\t   있게 된다 (예: v2의 기본 Tiller 네임스페이스는 kube-system).\n\t   v2는 Tiller 네임스페이스 및 `TILLER` 소유권 아래의 \"ConfigMaps\" \n\t   또는 \"Secrets\" 를 사용한다.\n\t   v3는 사용자 네임스페이스에 있는 \"Secrets\" 과 `helm` 소유권을 사용한다. \n\t   릴리스는 v2 및 v3에서 모두 증가한다.\n\t - 유일한 문제는 쿠버네티스 클러스터 범위의 \n\t   리소스(예: `clusterroles.rbac`)가 차트에 정의된 경우이다.\n\t   이런 경우 리소스가 충돌할 수 있으므로 네임스페이스에서 고유하더라도 v3 배포는 실패하게 된다.\n\t - v3 구성은 더이상 `$HELM_HOME` 을 사용하지 않고 대신 XDG 디렉토리 사양을 \n\t   사용한다. 또한 필요에 따라 즉시 생성된다. 따라서 v2 구성과는 \n\t   독립적이다. 이것은 동일한 시스템에 두 버전이 \n\t   설치된 경우에만 적용된다.\n\n2. 헬름 v2 에서 헬름 v3 로 마이그레이션:\n   - 이 사용 사례는 헬름 v3 에서 기존 헬름 v2 릴리스를 관리하려는 경우에\n     적용된다.\n   - 헬름 v2 클라이언트에 대해서는 다음과 같은 부분에 유의해야 한다:\n     - 헬름 v2 클라이언트 1개에서 다수의 쿠버네티스 클러스터 관리 가능\n     - 클러스터에 대해 헬름 v2 클라이언트 1 개가 여러 개의 Tiller 인스턴스에 연결 가능\n   - 이는 릴리스가 Tiller 및 해당 네임스페이스에 의해 클러스터에 \n     배치되므로 마이그레이션 할 때 이를 알고 있어야 한다는 것을 의미한다. \n     따라서 헬름 v2 클라이언트 인스턴스에서 관리하는 각 클러스터 \n     및 각 Tiller 인스턴스에 대한 마이그레이션을 알고 있어야 한다.\n   - 권장되는 데이터 마이그레이션 절차는 다음과 같다:\n     1. v2 데이터 백업\n     2. 헬름 v2 구성 마이그레이션\n     3. 헬름 v2 릴리스 마이그레이션\n     4. 헬름 v3가 모든 헬름 v2 데이터(헬름 v2 클라이언트 인스턴스의 모든 \n\t    클러스터 및 Tiller 인스턴스에 대한)를 예상한대로 잘 관리한다고 확신할 경우, \n\t    헬름 v2 데이터 소거\n   - 마이그레이션 과정은 헬름 v3 [2to3](https://github.com/helm/helm-2to3) 플러그인으로\n     자동화된다.\n\n## 참조\n\n   - 헬름 v3 [2to3](https://github.com/helm/helm-2to3) 플러그인\n   - `2to3` 플러그인 사용법을 예제와 함께 설명하는\n     블로그 [게시글](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)\n\t \n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"헬름 버전 지원 정책\"\ndescription: \"헬름의 패치 릴리스 정책 및 헬름과 쿠버네티스 간에 지원되는 최대의 버전 차이를 설명\"\n---\n\n이 문서는 헬름과 쿠버네티스 간에 지원되는 최대의 버전 차이를\n설명한다.\n\n## 지원되는 버전\n\n헬름 버전들은 `x.y.z` 로 표현된다. 여기서 `x` 는 주 버전, \n`y` 는 부 버전, z는 패치 버전으로 [유의적\n버전](https://semver.org/spec/v2.0.0.html) 을 따른다.\n\n헬름 프로젝트는 최신 부 릴리스에 대한 릴리스 브랜치를 유지한다.\n보안 픽스를 포함하여 적용가능한 픽스는 심각도와 타당성에 따라\n릴리스 브랜치로 선별 적용된다. 자세한 내용은 \n[헬름 릴리스 정책](/community/release_policy)을 참조한다.\n\n## 지원되는 버전 차이(skew)\n\n헬름의 새 버전이 출시 되면, 쿠버네티스의 특정 부 버전에 \n대해 컴파일된다. 예를 들어 헬름 3.0.0은 쿠버네티스 1.16.2 클라이언트를 사용하여 \n쿠버네티스와 상호작용하므로 쿠버네티스 1.16 과 호환된다고 할 수 있다.\n\n헬름 3부터는, 헬름은 그에 대응하여 컴파일되는 쿠버네티스 `n-3` 버전과 호환되는 \n것으로 간주된다. 쿠버네티스 마이너 버전 간의 차이로 인해 헬름 2의 \n지원 정책은 약간 더 엄격한데, 쿠버네티스의 `n-1` 버전과 호환되는 것으로\n간주한다.\n\n예를 들어, 쿠버네티스 1.17 클라이언트 API 에 대응하여 컴파일된\n헬름 3 버전을 사용하는 경우, 쿠버네티스 1.17, 1.16, 1.15 \n및 1.14 와 함께 사용하는 것이 안전할 것이다. 쿠버네티스 1.16 클라이언트 \nAPI 에 대해 컴파일 된 헬름 2 버전을 사용하는 경우, \n쿠버네티스 1.16 및 1.15 와 함께 사용하는 것이 안전할 것이다.\n\n헬름은 상위호환성을 보장하지 않으므로, 대응하여 컴파일된\n버전보다 더 높은 쿠버네티스 버전에서\n헬름을 사용하는 것은 권장되지 않는다.\n\n만약 지원하지 않는 쿠버네티스 버전에서 헬름을 사용하고자 하는 경우, \n사용자는 위험을 감수하고 사용하게 된다.\n\n클러스터와 호환되는 헬름 버전을 확인하려면 아래의 표를 \n참조하자.\n\n| 헬름 버전       | 지원하는 쿠버네티스 버전              |\n|--------------|-------------------------------|\n| 3.20.x       | 1.35.x - 1.32.x               |\n| 3.19.x       | 1.34.x - 1.31.x               |\n| 3.18.x       | 1.33.x - 1.30.x               |\n| 3.17.x       | 1.32.x - 1.29.x               |\n| 3.16.x       | 1.31.x - 1.28.x               |\n| 3.15.x       | 1.30.x - 1.27.x               |\n| 3.14.x       | 1.29.x - 1.26.x               |\n| 3.13.x       | 1.28.x - 1.25.x               |\n| 3.12.x       | 1.27.x - 1.24.x               |\n| 3.11.x       | 1.26.x - 1.23.x               |\n| 3.10.x       | 1.25.x - 1.22.x               |\n| 3.9.x        | 1.24.x - 1.21.x               |\n| 3.8.x        | 1.23.x - 1.20.x               |\n| 3.7.x        | 1.22.x - 1.19.x               |\n| 3.6.x        | 1.21.x - 1.18.x               |\n| 3.5.x        | 1.20.x - 1.17.x               |\n| 3.4.x        | 1.19.x - 1.16.x               |\n| 3.3.x        | 1.18.x - 1.15.x               |\n| 3.2.x        | 1.18.x - 1.15.x               |\n| 3.1.x        | 1.17.x - 1.14.x               |\n| 3.0.x        | 1.16.x - 1.13.x               |\n| 2.16.x       | 1.16.x - 1.15.x               |\n| 2.15.x       | 1.15.x - 1.14.x               |\n| 2.14.x       | 1.14.x - 1.13.x               |\n| 2.13.x       | 1.13.x - 1.12.x               |\n| 2.12.x       | 1.12.x - 1.11.x               |\n| 2.11.x       | 1.11.x - 1.10.x               |\n| 2.10.x       | 1.10.x - 1.9.x                |\n| 2.9.x        | 1.10.x - 1.9.x                |\n| 2.8.x        | 1.9.x - 1.8.x                 |\n| 2.7.x        | 1.8.x - 1.7.x                 |\n| 2.6.x        | 1.7.x - 1.6.x                 |\n| 2.5.x        | 1.6.x - 1.5.x                 |\n| 2.4.x        | 1.6.x - 1.5.x                 |\n| 2.3.x        | 1.5.x - 1.4.x                 |\n| 2.2.x        | 1.5.x - 1.4.x                 |\n| 2.1.x        | 1.5.x - 1.4.x                 |\n| 2.0.x        | 1.4.x - 1.3.x                 |\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"소개\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"사용법\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"주제\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"모범 사례\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"차트 템플릿 가이드\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Helm 명령어\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"커뮤니티\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"자주 묻는 질문\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs-community/current/developers.md",
    "content": "---\ntitle: 개발자 가이드\ndescription: 헬름을 개발하는 사용자의 환경을 구성하기 위한 지침\nsidebar_position: 1\n---\n\n이 가이드에서는 헬름을 개발하기 위해 환경을 설정하는 방법을 설명한다. \n\n## 전제 조건\n\n- Go 최신버전\n- kubectl 을 쓸 수 있는 쿠버네티스 클러스터 (선택사항)\n- Git\n\n## 헬름 빌드하기\n\n프로그램을 빌드하기 위해 Make를 사용한다. 시작하는 가장 간단한 방법은 다음과 같다.\n\n```console\n$ make\n```\n\n유의사항: `$ GOPATH / src / helm.sh / helm` 경로에서 실행하지 않으면 실패하게 된다. \n`helm.sh` 디렉토리는 심볼릭 링크가 아니어야 한다. \n심볼릭 링크이면 `build`가 관련 패키지를 찾지 못한다.\n\n필요한 경우 먼저 의존성을 설치하고 `vendor/` 트리를 \n다시 빌드하고 구성을 확인한다. 그런 다음 `helm` 을 컴파일하여 \n`bin/helm` 로 옮긴다.\n\n(`vendor/` 에 대한 테스트는 실행하지 않고) 모든 테스트를 실행하려면  `make test` 를 실행한다.\n\n헬름을 로컬에서 실행하려면 `bin/helm` 을 실행한다.\n\n- 헬름은 맥OS 및 Alpine을 포함한 대부분의 리눅스 배포판에서 실행되는 것으로 알려져 있다.\n\n## 기여 가이드라인\n\n우리는 기여를 환영한다. 이 프로젝트는 (a) 코드 품질이 높게 유지되고, \n(b) 프로젝트가 일관되게 유지되고, (c) 기여가 오픈 소스 법적 요건을 \n따르기 위해 몇 가지 지침을 설정했다. 우리의 의도는 기여자에게 \n부담을 주는 것이 아니라 사용자가 혜택을 받을 수 있도록 우아하고 \n고품질의 오픈 소스 코드를 만드는 것이다.\n\n가장 중심이라 할 수 있는 기여(CONTRIBUTING) 가이드를 읽고 숙지하자.\n\nhttps://github.com/helm/helm/blob/main/CONTRIBUTING.md\n\n### 코드의 구조\n\nHelm 프로젝트의 코드는 다음과 같이 구성된다.\n\n- 개별 프로그램은 `cmd/`에 위치한다.\n  `cmd/` 내부의 코드는 라이브러리 재사용을 위해 설계되지는 않았다.\n- 공유 라이브러리는 `pkg/` 에 저장된다.\n- `scripts/` 디렉토리에는 여러 유틸리티 스크립트가 들어 있다.\n  대부분 CI/CD 파이프라인에서 사용한다.\n\nGo 의존성 관리는 유동적이며 Helm의 수명주기 동안 \n변경될 수 있다. 개발자는 의존성을 수동으로 관리하지 \n_않기를_ 권장한다. 대신 프로젝트의 `Makefile` 에 \n의존하여 이를 수행하는 것이 좋다. Helm 3에서는 \nGo 버전 1.13 이상을 사용하는 것이 좋다.\n\n### 문서 작성하기\n\nHelm 3 이후의 문서는 자체 저장소로 이동되었다. \n새로운 기능을 작성할 때 함께 제공되는 문서를 작성하여 \n[helm-www] (https://github.com/helm/helm-www) 레포지터리에 제출하자.\n\n### Git 관례\n\n버전 제어 시스템으로는 Git을 사용한다. `main` 브랜치는 현재 개발 \n예정 브랜치의 홈 브랜치이다. 릴리스는 태그가 지정되며.\n\nGitHub PR (Pull Requests)을 통한 코드 변경을 허용한다. \n이를 위한 작업 흐름은 다음과 같다.\n\n1. `$GOPATH/src` 디렉토리로 이동한 후에, `mkdir helm.sh; cd helm.sh` 을 수행하고,\n   `git clone` 으로 `github.com/helm/helm` 레포지터리를 복제한다.\n2. 해당 레포지터리를 GitHub 계정으로 포크한다.\n3. 레포지터리를 `$GOPATH/src/helm.sh/helm` 에 대한 원격 레포지터리로 추가한다.\n4. 새로운 작업 브랜치를 만들고(`git checkout -b feat/my-feature`) 해당 브랜치에서\n   작업을 수행한다.\n5. 리뷰를 위한 준비가 되면 브랜치를 GitHub으로 푸시한 다음 \n   새로운 풀 리퀘스트를 생성한다.\n\nGit 커밋 메세지의 경우, 우리는 [유의적 커밋 메세지](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)를 \n따른다.\n\n```\nfix(helm): add --foo flag to 'helm install'\n\nWhen 'helm install --foo bar' is run, this will print \"foo\" in the\noutput regardless of the outcome of the installation.\n\nCloses #1234\n```\n\n일반적인 커밋 유형:\n\n- fix: 버그 또는 오류 수정\n- feat: 새로운 기능 추가\n- docs: 문서 변경\n- test: 테스트 개선\n- ref: 기존 코드 리팩터링\n\n일반적인 범위:\n\n- helm: 헬름 CLI\n- pkg/lint: 린트(lint) 패키지. 어떤 패키지든 유사한 관례에 따르자.\n- `*`: 두 개 이상의 스코프\n\n더 읽어보기:\n- 이 섹션은 [Deis \n  가이드라인](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)에서 영감을 받아 작성되었다.\n- Karma Runner는 유의적 커밋 메세지에 대한 아이디어를 \n  [정의](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)\n  한다.\n\n### Go 관례\n\n우리는 Go 코딩 스타일 표준을 매우 밀접하게 따른다. 일반적으로 `go fmt` 를 실행하여\n사용자의 코드를 더욱 아름답게 만들수 있다.\n\n또한 일반적으로 `go lint` 및 `gometalinter` 에서 권장하는 규칙을 따른다.\n스타일 적합성을 테스트하려는 경우 `make test-style` 을 실행하자.\n\n더 읽어보기:\n\n- Effective Go [포맷\n  소개](https://golang.org/doc/effective_go.html#formatting).\n- Go 위키에서 볼 수 있는 훌륭한 \n  [포맷](https://github.com/golang/go/wiki/CodeReviewComments) 글\n\n`make test` 타겟을 실행하면 단위 테스트뿐만 아니라 스타일 테스트도 실행된다.\n`make test` 대상이 스타일 상의 이유로 실패하면 PR 은 병합할 준비가\n되지 않은 것으로 간주한다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs-community/current/history.mdx",
    "content": "---\ntitle: 프로젝트 연혁\ndescription: 프로젝트의 연혁에 대한 개요를 설명한다.\nsidebar_position: 4\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\n헬름 3는 [인큐베이션(incubation) 최종단계](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc)에 있는 [CNCF 프로젝트](https://www.cncf.io/projects/)이다.\n\n헬름은, 2015년에 시작되어 KubeCon에서 소개된 바 있는 [헬름 클래식](https://github.com/helm/helm-classic)이라 하는 멋진 프로젝트에서 시작되었다.\n\n2016년 1월, 프로젝트는 쿠버네티스 디플로이먼트 매니저라고 불리는 GCS 도구로 병합되며, [쿠버네티스](https://kubernetes.io) 산하로 옮겨갔다.\n코드베이스 병합의 결과로, 그 이듬해 헬름 2.0이 릴리스되었다.\n디플로이먼트 매니저(Deployment Manager)의 핵심기능은 헬름 2로 이어져, 최종 헬름 2.0 릴리스에서 틸러(Tiller)라고 명명된 서버측 컴포넌트가 되었다.\n\n2018년 6월에 헬름은 쿠버네티스의 서브프로젝트에서 본격적인 CNCF 프로젝트로 승격되었다.\n헬름은 최상위 관리조직을 구성하고 헬름 프로젝트 산하로 여러 프로젝트들을 포괄하였는데,\n모노큘러(Monocular), 헬름 차트 저장소(Helm Chart Repo), 차트 뮤지엄(Chart Museum), 나중에 헬름 허브(Helm Hub)를 포함하였다.\n\n헬름 3 개발 사이클이 시작되면서, 틸러(Tiller)가 제거되고, 클라이언트 도구로서의 본래의 지향점에 더 가까워졌다.\n그러면서도 헬름 3는 쿠버네티스 클러스터 내부의 릴리스 추적을 계속하여,\n팀에서 공동의 헬름 릴리스 세트를 함께 다룰 수 있게 해준다.\n\n헬름 3는 2019년 11월에 릴리스되었다.\n\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs-community/current/localization.md",
    "content": "---\ntitle: 헬름 문서 현지화\ndescription: 헬름 문서 현지화를 위한 설명서\nsidebar_position: 5\n---\n\n이 가이드에서는 헬름 문서를 현지화하는 방법에 대해 설명한다.\n\n## 시작하기\n\n번역 기여는 문서 기여와 동일한 과정을 거친다.\n번역본은 [풀\n리퀘스트](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)\n를 통해 [helm-www](https://github.com/helm/helm-www) 깃 저장소에 제공되며 풀 리퀘스트는\n웹사이트를 관리하는 팀이 검토한다.\n\n### 두 글자 언어 코드 {#two-letter-language-code}\n\n문서는 언어 코드를 [ISO 639-1\n표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)으로 구성한다.\n예를 들어, 한국어의 두 글자 코드는 `ko` 이다.\n\n내용 및 설정에서 사용 중인 언어 코드를 찾을 수 있다.\n세 가지 예:\n\n- `content` 디렉토리에 언어 코드가 하위 디렉토리로 있고\n  각 디렉토리마다 번역된 콘텐츠가 있는데,\n  주로 `docs` 하위 디렉토리에 있다.\n- `i18n` 디렉토리에는 웹사이트에서 사용하는 문구가 포함된\n  각 언어에 대한 설정 파일이 있다.\n  파일 이름은 `[LANG].toml` 로 지정되며, 여기서 `[LANG]` 은 두 글자 언어 코드다.\n- 프로젝트 최상위에 위치한 `config.toml` 파일에는 언어 코드별로 구성된 네비게이션 및\n  기타 세부 사항에 대한 설정 정보가 있다.\n\n언어 코드가 `en` 인 영어는,\n번역을 위한 기본 언어이자 원본이다.\n\n### 포크, 브랜치, 변경, 풀 리퀘스트\n\n번역본을 기여하려면 먼저 깃헙에 [helm-www 저장소](https://github.com/helm/helm-www)의\n[포크를 만드는 것](https://help.github.com/en/github/getting-started-with-github/fork-a-repo)부터\n시작한다.\n사용자는 자신의 포크를 커밋함으로써 시작하게 된다.\n\n기본적으로 포크는 master라는 기본 브랜치에서 동작하도록 설정된다.\n변경 사항을 개발하고 풀 리퀘스트를 생성하기 위해 브랜치를 사용하자. 브랜치가 익숙하지 않다면\n[깃헙 문서를\n읽어볼 수 있다](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches).\n\n브랜치가 있다면 번역을 추가하고 내용을\n현지화하자.\n\n참고로 헬름은 [원본 개발자 증명서](https://developercertificate.org/)를 사용한다.\n모든 커밋은 서명이 필요하다.\n커밋을 생성할 때, 깃에 설정된 이름과 이메일 주소로 서명하기 위해\n`-s` 또는 `--signoff` 플래그를 쓸 수 있다.\n자세한 내용은\n[CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work)에서\n확인할 수 있다.\n\n준비되면 번역본과 함께 다시 helm-www 저장소로 [풀\n리퀘스트](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)를\n생성하자.\n\n풀 리퀘스트를 생성하면 관리자 중 한 명이 검토할 것이다.\n그 과정에 대한 세부사항은\n[CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md)에\n있다.\n\n## 콘텐츠 번역하기\n\n헬름의 모든 내용을 현지화하는 것은 상당한 작업이다.\n작은 부분부터 시작해도 괜찮다. 이 후에 더 번역할 수 있다.\n\n### 새로운 언어 등록하기\n\n새로운 언어를 등록할 때 필요한 최소 요건이 있다. 여기에는 다음이 포함된다:\n\n- `index.md` 파일이 들어 있는 `content/[LANG]/docs` 디렉토리 추가.\n  이것은 최상위 문서 랜딩 페이지다.\n- `i18n` 디렉토리에 `[LANG].toml` 파일 생성.\n  `en.toml` 파일을 복사해서 시작할 수 있다.\n- 새로운 언어를 서비스하기 위해 `config.toml` 파일에 해당 언어 섹션 추가.\n  기존 언어 섹션을 써서 등록할 수도 있다.\n\n### 번역하기\n\n번역된 콘텐츠는 `content/[LANG]/docs` 디렉토리에 있어야 한다. 이것은 영어 원문과 동일한 URL을\n가져야 한다. 예를 들어, 소개 부분을 한국어로 번역하려면 다음과 같이 영어 원문을 복사하는 것이\n유용할 수 있다:\n\n```sh\nmkdir -p content/ko/docs/intro\ncp content/en/docs/intro/install.md content/ko/docs/intro/install.md\n```\n\n그러면 새 파일의 내용을 다른 언어로 번역할 수 있다.\n\n영문 파일의 번역되지 않은 사본을 `content/[LANG]/` 에 추가하지 않도록 한다.\n사이트에 해당 언어가 존재하면 번역되지 않은 페이지는 자동으로 영문 페이지로 리다이렉션된다.\n번역에는 시간이 필요하고,\n사용자들은 오래된 버전의 포크가 아닌 최신 버전의 문서를 번역하길 원한다.\n\n헤더 섹션에서 `aliases` 행을 반드시 제거하자.\n`aliases: [\"/docs/using_helm/\"]` 과 같은 행은 번역에 속하지 않는다.\n이것은 새로운 페이지 링크로 인해 없어진 링크에 대한 리다이렉션이다.\n\n참고로 번역 도구는 이 과정에 도움을 줄 수 있다.\n여기에는 번역기로 생성한 번역도 포함된다.\n번역기로 생성한 번역은 내보내기 전에\n원어민이 문법과 의미를 편집하거나 검토해야 한다.\n\n\n## 언어 변경\n\n![Screen Shot 2020-05-11 at 11 24 22\nAM](https://user-images.githubusercontent.com/686194/81597103-035de600-937a-11ea-9834-cd9dcef4e914.png)\n\n사이트 전역 [config.toml](https://github.com/helm/helm-www/blob/main/config.toml#L83L89)\n파일에서 언어 변경을 구성한다.\n\n새로운 언어를 추가하려면 위에서 정의한 [두 글자\n언어 코드](#two-letter-language-code)를 사용하여 새로운 매개 변수 집합을\n추가하자. 예:\n\n```\n# Korean\n[languages.ko]\ntitle = \"Helm\"\ndescription = \"Helm - The Kubernetes Package Manager.\"\ncontentDir = \"content/ko\"\nlanguageName = \"한국어 Korean\"\nweight = 1\n```\n\n## 내부 링크 결정하기\n\n번역된 콘텐츠는 간혹 번역되지 않은 페이지에 대한 링크를 포함한다. 이로 인해 사이트 [빌드\n오류](https://app.netlify.com/sites/helm-merge/deploys)가 발생할 수 있다.\n예:\n\n```\n12:45:31 PM: htmltest started at 12:45:30 on app\n12:45:31 PM: ========================================================================\n12:45:31 PM: ko/docs/chart_template_guide/accessing_files/index.html\n12:45:31 PM:   hash does not exist --- ko/docs/chart_template_guide/accessing_files/index.html --> #basic-example\n12:45:31 PM: ✘✘✘ failed in 197.566561ms\n12:45:31 PM: 1 error in 212 documents\n```\n\n이 문제를 해결하려면 콘텐츠에서 내부 링크를 확인해야 한다.\n\n* 앵커 링크는 번역된 `id` 값을 반영해야 한다.\n* 내부 페이지 링크를 고쳐야 한다.\n\n존재하지 않는 _(혹은 아직 번역되지 않은)_ 내부 페이지가 있을 경우,\n교정될 때까지 사이트가 빌드되지 않는다.\n그 대신 URL은 다음과 같이 해당 콘텐츠가 _존재하는_ 다른 언어를 가리킬 수 있다.\n\n`< relref path=\"/docs/topics/library_charts.md\" lang=\"en\" >`\n\n자세한 내용은 [언어 간 상호 참조에 대한 휴고(Hugo)\n문서](https://gohugo.io/content-management/cross-references/#link-to-another-language-version)\n를 참조하자.\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs-community/current/related.md",
    "content": "---\ntitle: 관련 프로젝트와 문서\ndescription: 커뮤니티에서 제공하는 서드파티 도구, 플러그인 및 문서\nsidebar_position: 3\n---\n\n헬름 커뮤니티는 헬름에 대한 많은 추가 도구, 플러그인 및 문서를 만들었습니다. 우리는\n이러한 프로젝트에 대해 듣고 싶습니다.\n\n이 목록에 추가하고 싶은 것이 있으면 \n[이슈](https://github.com/helm/helm-www/issues)나 [풀 \n리퀘스트(PR)](https://github.com/helm/helm-www/pulls) 할 수 있습니다.\n\n## 헬름 플러그인 {#helm-plugins}\n\n- [Helm Diff](https://github.com/databus23/helm-diff) - 컬러 diff로 `helm upgrade` \n  미리보기\n- [helm-gcs](https://github.com/hayorov/helm-gcs) - Google Cloud Storage에서 \n  저장소를 관리하는 플러그인\n- [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - 프로메테우스/엘라스틱서치 쿼리를 기반으로 \n  릴리스 및 롤백을 모니터링하는 플러그인\n- [helm-k8comp](https://github.com/cststack/k8comp) - k8comp 를 사용하여 hiera 에서 \n  헬름 차트를 생성하는 플러그인\n- [helm-unittest](https://github.com/helm-unittest/helm-unittest) - YAML로 \n  로컬에서 차트를 단위 테스트하기 위한 플러그인\n- [hc-unit](https://github.com/xchapter7x/hcunit) - OPA (Open Policy Agent) 및 Rego로\n  로컬에서 차트를 단위 테스트하기 위한 플러그인\n- [helm-s3](https://github.com/hypnoglow/helm-s3) - [프라이빗] 차트 저장소로 AWS S3를 \n  사용할 수 있게 해주는 헬름 플러그인\n- [helm-secrets](https://github.com/jkroepke/helm-secrets) - 비밀정보를 안전하게 관리하고\n  보관하기 위한 플러그인 ([sops](https://github.com/mozilla/sops) 기반)\n\nGitHub 작성자가 플러그인 저장소에 \n[helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) 태그를 \n사용할 것을 권장한다.\n\n## 추가적인 도구들\n\n헬름의 상위 계층 도구들.\n\n- [Chartify](https://github.com/appscode/chartify) - 기존 쿠버네티스 리소스에서 \n  헬름 차트를 생성\n- [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - 쿠버네티스 및 헬름용(用)\n  VIM 플러그인\n- [Landscaper](https://github.com/Eneco/landscaper/) - \"Landscaper 는 값(원하는 상태)을 가진 \n  헬름 차트 참조 집합을 가져와서\n  쿠버네티스 클러스터에서 실현한다.\"\n- [Helmfile](https://github.com/helmfile/helmfile) - Helmfile은 헬름 차트 배포를 \n  위한 선언적 사양이다\n- [Helmsman](https://github.com/Praqma/helmsman) - Helmsman은\n  버전 관리되는 원하는 상태 파일들(간단한 TOML 형식으로 기술됨)로부터\n  릴리스를 설치/업그레이드/보호/이동/삭제할 수 있는 \n  코드로서의-헬름-차트(helm-charts-as-code) 도구이다\n- [Terraform Helm Provider](https://github.com/hashicorp/terraform-provider-helm) - HashiCorp \n  Terraform용 헬름 공급자(provider)는 선언적 코드형 인프라(infrastructure-as-code) 구문으로\n  헬름 차트의 수명주기를 관리할 수 있게 해준다. 헬름 공급자는 쿠버네티스 공급자처럼,\n  모든 인프라 서비스에서 통용되는 워크플로를 만들기 위해, 다른 테라폼 공급자와 \n  쌍을 이루는 경우가 많다.\n- [Monocular](https://github.com/helm/monocular) - 헬름 차트 저장소를 \n  위한 웹 UI\n- [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) - 여러 \n  쿠버네티스 네임스페이스에 걸쳐 접두어가 붙은 릴리스들을 관리하며,\n  복잡한 배포에서의 완료된 작업들을 제거한다\n- [ChartMuseum](https://github.com/helm/chartmuseum) - Amazon S3와\n  Google Cloud Storage를 지원하는 헬름 차트 저장소\n- [Codefresh](https://codefresh.io) - 헬름 차트 및 릴리스를 관리하기 위한\n  UI 대시보드가 있는 쿠버네티스 네이티브 CI/CD 및 관리 플랫폼 \n- [Captain](https://github.com/alauda/captain) - HelmRequest 및 \n  릴리스 CRD를 사용하는 Helm3 컨트롤러\n- [chart-registry](https://github.com/hangyan/chart-registry) - OCI 저장소 상의\n  헬름 차트 호스트\n- [avionix](https://github.com/zbrookle/avionix) - 상속과 코드중복 저감을 할 수 있는\n  헬름 차트와 쿠버네티스 yaml 을 생성하는 파이썬 인터페이스. \n\n## 헬름 지원\n\n헬름 지원을 포함하는 플랫폼, 배포판 및 서비스.\n\n- [Kubernetic](https://kubernetic.com/) - 쿠버네티스 데스크탑 클라이언트\n- [Jenkins X](https://jenkins-x.io/) - GitOps 환경을 통해 애플리케이션을 \n  [프로모션(promotion)](https://jenkins-x.io/docs/getting-started/promotion/)하기 위해\n  헬름을 사용하는 쿠버네티스용 오픈소스 자동화 CI/CD\n\n## 기타\n\n차트 작성자와 헬름 사용자에게 유용한 것 모음.\n\n- [Await](https://github.com/saltside/await) - 다른 조건들에 대해 \"대기(await)\"하는 \n  도커 이미지--특히 초기화 컨테이너에 유용하다. [더 \n  보기](https://blog.slashdeploy.com/2017/02/16/introducing-await/)\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs-community/current/release_checklist.md",
    "content": "---\ntitle: 릴리스 체크리스트\ndescription: 다음 버전의 헬름을 출시할 때 유지관리자를 위한 체크리스트\nsidebar_position: 2\n---\n\n# 헬름 릴리스에 대한 유지관리자 가이드\n\n새로운 헬름을 출시할 시간이다! 릴리스를 끊는 헬름 유지관리자로서,\n자신의 경험이 여기에 문서화된 내용과 다른 점이 있다면\n이 릴리스 체크리스트를 업데이트하기에 \n딱 맞는 사람이다.\n\n모든 릴리스는 vX.Y.Z 형식이다. \n여기서 X는 주 버전 번호, Y는 부 버전 번호, Z는 패치 릴리스 번호이다. \n이 프로젝트는 [유의적 버전 관리] (https://semver.org/)를 엄격히 따르므로 \n이 단계를 따르는 것이 매우 중요하다.\n\n헬름은 다음 마이너 릴리스 날짜를 미리 발표한다. \n발표된 날짜를 지키기 위해 최선을 다해야 한다. \n또한 릴리스 프로세스를 시작할 때, 다음 릴리스 날짜를 선택해야 하며\n릴리스 프로세스의 일환이다.\n\n이 지침은 초기 구성에 이어 세 가지 \n다른 종류의 릴리스에 대한 릴리스 절차를 다룬다.\n\n* 주 릴리스 - 상대적으로 낮은 빈도로 릴리스 - 주요 변경 사항이 있음\n* 부 릴리스 - 3~4개월마다 릴리스 - 주요 변경 사항 없음\n* 패치 릴리스 - 매월 릴리스 - 이 가이드의 모든 단계가 불필요\n\n[초기 구성](#초기-구성)\n\n1. [릴리스 브랜치 생성](#1-릴리스-브랜치-생성)\n2. [주 또는 부 릴리스: git에서 버전 번호 변경](#2-git에서-주-또는-부-버전-번호-변경)\n3. [주/부 릴리스: 릴리스 브랜치 커밋 및 푸시](#3-주부-릴리스-릴리스-브랜치-커밋-및-푸시)\n4. [주/부 릴리스: 릴리스 후보 생성](#4-주부-릴리스-릴리스-후보-생성)\n5. [주/부 릴리스: 연속 릴리스 후보 개선](#5-주부-릴리스-연속-릴리스-후보-개선)\n6. [릴리스 확정](#6-릴리스-확정)\n7. [릴리스 노트 작성](#7-릴리스-노트-작성)\n8. [다운로드에 PGP 서명](#8-다운로드에-pgp-서명)\n9. [릴리스 출간](#9-릴리스-출간)\n10. [문서 업데이트](#10-문서-업데이트)\n11. [커뮤니티에 알리기](#11-커뮤니티에-알리기)\n\n## 초기 구성\n\n### Git 원격 설정하기\n\n이 문서에서는 저장소에서 <https://github.com/helm/helm>에 해당하는 \nGit 원격의 이름이 \"upstream\"이라고 가정한다는 점에 유의해야 한다. \n그렇지 않은 경우(예: 이름을 \"origin\" 또는 이와 유사한 이름으로 선택한 경우) \n그에 따라 로컬 환경에 맞게 나열된 스니핏(snippet)을 조정해야 한다. \n업스트림 원격의 이름이 확실하지 않은 경우 `git remote -v` 와 \n같은 명령을 사용하여 확인하자.\n\n[업스트림 원격](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork)이 \n없는 경우 \n다음과 같이 추가할 수 있다.\n\n```shell\ngit remote add upstream git@github.com:helm/helm.git\n```\n\n### 환경 변수 설정하기\n\n이 문서에서는 편의를 위해 설정할 수 있는 몇 가지 환경 변수를 \n소개한다. 주/부 릴리스의 경우 \n다음을 사용하자.\n\n```shell\nexport RELEASE_NAME=vX.Y.0\nexport RELEASE_BRANCH_NAME=\"release-X.Y\"\nexport RELEASE_CANDIDATE_NAME=\"$RELEASE_NAME-rc.1\"\n```\n\n패치 릴리스를 만드는 경우 대신 다음을 사용하자.\n\n```shell\nexport PREVIOUS_PATCH_RELEASE=vX.Y.Z\nexport RELEASE_NAME=vX.Y.Z+1\nexport RELEASE_BRANCH_NAME=\"release-X.Y\"\n```\n\n### 서명 키 설정하기\n\n또한 바이너리를 해싱하고 서명 파일을 제공하여 릴리스 \n프로세스의 보안 및 검증을 추가한다. 이 작업은 \n[GitHub 및 GPG] (https://help.github.com/en/articles/about-commit-signature-verification)를 \n이용하여 수행한다. \nGPG가 아직 설정되지 않은 경우, 다음 단계를 수행할 수 있다.\n\n1. [GPG 설치] (https://gnupg.org/index.html)\n2. [GPG 키 \n   생성] (https://help.github.com/en/articles/generating-a-new-gpg-key)\n3. [GitHub 계정에 \n   키 추가] (https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account)\n4. [Git에서 서명 \n   키 설정] (https://help.github.com/en/articles/telling-git-about-your-signing-key)\n\n서명 키가 있으면 저장소 루트에 있는 KEYS 파일에 추가해야 \n한다. KEYS 파일에 추가하는 지시어는 그 파일 안에 있다. 아직\n공개 키를 키 서버 네트워크에 추가하지 않았다면 추가해야 한다. \nGnuPG를 사용하는 경우 \n[Debian에서 제공하는 지침] (https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver)을 따를 수 있다.\n\n## 1. 릴리스 브랜치 생성\n\n### 주/부 릴리스\n\n주요 릴리스는 *이전 호환성을 깨는* 새로운 기능의 추가 및 동작 \n변경을 위한 것이다. 부 릴리스는 이전 버전과의 호환성을 깨지 않는 선에서 \n새로운 기능 추가를 위한 것이다. 주 또는 부 릴리스를 생성하려면 \n먼저 main에서 `release-X.Y` 브랜치를 생성한다.\n\n```shell\ngit fetch upstream\ngit checkout upstream/main\ngit checkout -b $RELEASE_BRANCH_NAME\n```\n\n이 새 브랜치는 릴리스의 기반이 되며,\n이를 기반으로 하여 변경해 나갈 것이다.\n\n릴리스에 대한 \n[헬름/헬름 마일스톤] (https://github.com/helm/helm/milestones)이 GitHub에 있는지 확인한다(필요한 경우 생성). \n이 릴리스에 대한 PR 및 이슈가 이 마일스톤에 있는지 확인하자.\n\n주 또는 부 릴리스의 경우 2 단계로 이동한다. \n[주 또는 부 릴리스: \ngit에서 버전 번호 변경](#2-git에서-주-또는-부-버전-번호-변경)\n\n### 패치 릴리스\n\n패치 릴리스는 기존 릴리스에 대한 몇 가지 중요한 수정 사항이다. \n`release-X.Y` 브랜치를 생성하여 시작한다.\n\n```shell\ngit fetch upstream\ngit checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME\n```\n\n여기에서 패치 릴리스로 가져올 커밋을 \n선택할 수 있다.\n\n```shell\n# 체리-픽(cherry-pick)하려는 커밋 ID 목록 조회\ngit log --oneline\n# 병합 커밋을 포함하지 않고 가장 오래된 커밋부터 골라서 선택\ngit cherry-pick -x <commit-id>\n```\n\n커밋이 체리픽되면 릴리스 브랜치를 푸시해야 한다.\n\n```shell\ngit push upstream $RELEASE_BRANCH_NAME\n```\n\n분기를 푸시하면 테스트가 실행되며, 태그를 만들기 전에 통과해야 한다. \n이 새로운 태그는 패치 릴리스의 기반이 된다.\n\n패치 릴리스의 경우 \n[헬름/헬름 마일스톤] (https://github.com/helm/helm/milestones) \n생성은 선택사항이다.\n\n계속 진행하기 전에 릴리스가 CI를 통과했는지 [GitHub Actions 에서의 헬름](https://github.com/helm/helm/actions)를\n확인하자. 패치 릴리스는 2-5 단계를 건너 뛰고 6 단계로 진행하여 \n[릴리스 확정](#6-릴리스-확정)를 수행할 수 있다.\n\n## 2. git에서 주 또는 부 버전 번호 변경\n\n주 또는 부 릴리스를 수행할 때 `internal/version/version.go` 를 \n새 릴리스 버전으로 업데이트해야 한다.\n\n```shell\n$ git diff internal/version/version.go\ndiff --git a/internal/version/version.go b/internal/version/version.go\nindex 712aae64..c1ed191e 100644\n--- a/internal/version/version.go\n+++ b/internal/version/version.go\n@@ -30,7 +30,7 @@ var (\n        // Increment major number for new feature additions and behavioral changes.\n        // Increment minor number for bug fixes and performance enhancements.\n        // Increment patch number for critical fixes to existing releases.\n-       version = \"v3.3\"\n+       version = \"v3.4\"\n\n        // metadata is extra build time data\n        metadata = \"\"\n```\n\n`version.go` 파일에서 버전을 업데이트하는 것 외에도 \n해당 버전 번호를 사용하는 해당 테스트도 업데이트해야 한다.\n\n* `cmd/helm/testdata/output/version.txt`\n* `cmd/helm/testdata/output/version-client.txt`\n* `cmd/helm/testdata/output/version-client-shorthand.txt`\n* `cmd/helm/testdata/output/version-short.txt`\n* `cmd/helm/testdata/output/version-template.txt`\n* `pkg/chartutil/capabilities_test.go`\n\n```shell\ngit add .\ngit commit -m \"bump version to $RELEASE_NAME\"\n```\n\n이는 $RELEASE_BRANCH_NAME에 대해서만 업데이트된다. \n[3.2에서 3.3으로의 \n이 예제](https://github.com/helm/helm/pull/8411/files)에서와 \n같이 다음 릴리스가 생성될 때 이 변경 사항을 마스터 브랜치로 \n가져와야 하며, 다음 릴리스의 마일스톤에 추가해야 한다.\n\n```shell\n# 버전을 올리기 위해 마지막 커밋을 획득\ngit log --format=\"%H\" -n 1\n\n# 마스터에서 새 브랜치를 생성\ngit checkout main\ngit checkout -b bump-version-<release_version>\n\n# 첫 번째 명령으로부터 ID를 사용하여 커밋을 체리픽\ngit cherry-pick -x <commit-id>\n\n# 변경 사항 커밋\ngit push origin bump-version-<release-version>\n```\n\n## 3. 주/부 릴리스: 릴리스 브랜치 커밋 및 푸시\n\n다른 사람들이 테스트를 시작하기 위해 이제 릴리스 브랜치를 업스트림으로 푸시하고 \n테스트 프로세스를 시작할 수 있다.\n\n```shell\ngit push upstream $RELEASE_BRANCH_NAME\n```\n\n계속 진행하기 전에 릴리스가 CI를 통과했는지 \n[GitHub Actions 에서의 헬름] (https://github.com/helm/helm/actions)을 확인하자.\n\n사용 가능한 사람이 있는 경우 모든 적절한 변경 사항이 적용되고 \n릴리스에 대한 모든 커밋이 있는지 계속 확인하기 전에 \n다른 사용자와 브랜치에 대해 동료-평가를 진행하자.\n\n## 4. 주/부 릴리스: 릴리스 후보 생성\n\n이제 릴리스 브랜치가 나왔고 준비되었으므로 \n릴리스 후보를 만들고 반복할 차례이다.\n\n```shell\ngit tag --sign --annotate \"${RELEASE_CANDIDATE_NAME}\" --message \"Helm release ${RELEASE_CANDIDATE_NAME}\"\ngit push upstream $RELEASE_CANDIDATE_NAME\n```\n\nGitHub Actions는 테스트할 태그된 릴리스 이미지와 클라이언트 바이너리를 \n자동으로 생성한다.\n\n테스터의 경우 GitHub Actions가 아티팩트 빌드를 완료한 후 \n테스트를 시작하는 프로세스에는 다음과 같이 클라이언트를 받는 단계가 포함된다.\n\n리눅스/amd64 의 경우, /bin/bash 를 사용한다\n\n```shell\nwget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz\n```\n\ndarwin/amd64 의 경우, Terminal.app 을 사용한다.\n\n```shell\nwget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz\n```\n\n윈도우/amd64, 파워셸(PowerShell)을 사용한다.\n\n```shell\nPS C:\\> Invoke-WebRequest -Uri \"https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz\" -OutFile \"helm-$ReleaseCandidateName-windows-amd64.tar.gz\"\n```\n\n그런 다음 바이너리의 압축을 풀고 $PATH의 특정 장소로 이동하거나 \n특정 장소로 이동하여 $PATH에 추가한다 \n(예 : linux/macOS의 경우 /usr/local/bin/helm,  Windows의 경우 C:\\Program Files\\helm\\helm.exe).\n\n## 5. 주/부 릴리스: 연속 릴리스 후보 개선\n\n릴리스와 관련된 모든 결과를 문서화하여 가능한 \n모든 방법으로 헬름 테스트를 시도하고 중단하기 위해 \n명시적으로 시간과 리소스를 투자하는 데 여러 시간을 보내게 된다. \n이 시간은 릴리스가 다양한 기능 또는 업그레이드 환경에, \n코딩이 아닌 문제를 유발할 수있는 방법을 테스트하고 찾는데 소비되어야 한다. \n이 기간 동안 릴리스는 코드 동결 상태이며 추가 코드 변경 사항은 다음 릴리스로 푸시된다.\n\n이 단계에서 $RELEASE_BRANCH_NAME 브랜치는 \n새로운 출시 후보를 생성함에 따라 계속 발전하게 된다. \n새로운 후보의 빈도는 릴리스 관리자에게 달려 있다.\n보고된 문제의 심각도, 테스터의 가용성 및 릴리스 기한을 고려하여 \n최선의 판단을 내리자. 일반적인 경우, 손상된 릴리스를 전달하는 것보다는 \n릴리스가 마감일을 넘기는게 차라리 더 좋다.\n\n새 릴리스 후보를 생성 할 때마다 마스터 브랜치에서 체리픽 하여 \n브랜치에 커밋을 추가하는 것으로 시작한다.\n\n```shell\ngit cherry-pick -x <commit_id>\n```\n\n또한 분기를 GitHub으로 푸시하고 CI를 통과하는지도 확인해야 한다.\n\n그럼 다음 태그를 지정하고 사용자들에게 새 릴리스 후보에 대해 알린다.\n\n```shell\nexport RELEASE_CANDIDATE_NAME=\"$RELEASE_NAME-rc.2\"\ngit tag --sign --annotate \"${RELEASE_CANDIDATE_NAME}\" --message \"Helm release ${RELEASE_CANDIDATE_NAME}\"\ngit push upstream $RELEASE_CANDIDATE_NAME\n```\n\nGitHub에 푸시되면 이 태그가 있는 브랜치가 CI에 빌드 되는지 확인한다.\n\n여기서부터는 이 프로세스를 반복하고 릴리스 후보에 만족할 때까지 지속적으로 테스트한다. \n릴리스 후보의 경우 전체 노트를 작성하지는 않지만 일부 \n[릴리스 노트](#7-릴리스-노트-작성)를 미리 작성(scaffold)할 수 있다.\n\n## 6. 릴리스 확정\n\n최종적으로 릴리스 후보의 품질에 만족한다면 계속 진행하여 진짜를 \n만들 수 있다. 마지막으로 한 번 더 확인하여 모든 것이 \n정상인지 확인한 다음, 마지막으로 릴리스 태그를 푸시한다.\n\n```shell\ngit checkout $RELEASE_BRANCH_NAME\ngit tag --sign --annotate \"${RELEASE_NAME}\" --message \"Helm release ${RELEASE_NAME}\"\ngit push upstream $RELEASE_NAME\n```\n\n릴리스가 [GitHub Actions](https://github.com/helm/helm/actions)에서 \n성공했는지 확인하자. 그렇지 않은 경우 릴리스를 수정하고 \n릴리스를 다시 푸시해야 한다.\n\nCI 작업을 실행하는 데 약간의 시간이 걸리므로 완료될 때까지 \n기다리는 동안 릴리스 정보 작성 단계로 넘어갈 수 있다.\n\n## 7. 릴리스 노트 작성\n\n릴리스 주기 동안 발생한 커밋을 기반으로 변경 로그를 자동 생성하지만 \n일반적으로 수동으로, 인간 생명체든/마케팅 팀이든/심지어 고양이라도 릴리스 노트는 손으로 작성한 경우가 \n최종 사용자에게 더 유용하다.\n\n주/부 릴리스를 릴리스하는 경우 일반적으로 주목할만한 \n사용자용 기능을 나열하는 것으로 충분하다. 패치 릴리스의 경우 \n동일하게 하되 증상이나 영향을 받을 수 있는 사용자에 대해 기재하자.\n\n릴리스 정보에는 다음 릴리스의 버전과 계획된 날짜가 포함되어야 한다.\n\n부 릴리스에 대한 예제 릴리스 노트는 다음과 같다.\n\n```markdown\n## vX.Y.Z\n\nHelm vX.Y.Z는 기능 릴리스이다. 이번 릴리스에서는 <insert focal point>에 중점을 두었다. 사용자는 최상의 환경을 위해 업그레이드하는 것이 좋다.\n\n커뮤니티는 계속 성장하고 있으며, 함께하면 좋겠다!\n\n- [Kubernetes Slack] (https://kubernetes.slack.com)에서 토론에 참여해보자.\n  - 질문을 하려면 `#helm-users`\n  - PR, 코드, 버그를 논의하려면 `#helm-dev`\n- 공개 개발자 전화 : 목요일 오전 9시 30 분 [Zoom]을 통해 행 아웃 (https://zoom.us/j/696660622)\n- 차트 테스트, 디버그, 기여 : [GitHub/헬름/차트] (https://github.com/helm/charts)\n\n## 주목할 만한 변화\n\n- Kubernetes 1.16은 이제 새 매니페스트 apiVersion도 지원한다.\n- Sprig은 2.22으로 업그레이드되었다.\n\n## 설치 및 업그레이드\n\n헬름 X.Y 를 다운로드한다. 일반적인 플랫폼 바이너리는 다음과 같다.\n\n- [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)\n- [리눅스 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)\n- [리눅스 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)\n- [리눅스 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)\n- [리눅스 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)\n- [리눅스 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)\n- [리눅스 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)\n- [윈도우 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)\n\n[빠른 시작 가이드](/intro/quickstart.md)를 참조하세요. **업그레이드 안내** 또는 자세한 설치 정보는 [설치 가이드](/intro/install.md)를 확인하세요. `bash` 가 있는 모든 시스템에서 [설치할 스크립트] (https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3)를 사용할 수도 있다.\n\n## 향후 계획\n\n- vX.Y.Z + 1 에는 버그 수정만 포함되며 <날짜 삽입>에 릴리스 예정이다.\n- vX.Y + 1.0 은 다음 기능 릴리스이며 <날짜 삽입>에 릴리스 예정이다. 이 릴리스는 ...\n\n## 변경로그\n\n- chore(*) v2.7.0 로 버전 업(bump) 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese) \n- 태그를 작성하지 않는 버그 수정 f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher)\n```\n\n변경 로그를 포함하여 부분적으로 완료된 릴리스 정보 \n집합은 다음 명령을 실행하여 작성할 수 있다.\n\n```shell\nexport VERSION=\"$RELEASE_NAME\"\nexport PREVIOUS_RELEASE=vX.Y.Z\nmake clean\nmake fetch-dist\nmake release-notes\n```\n\n이렇게하면 **주요 변경 사항** 및 **다음 단계** 섹션을 \n작성하기만 하면 되는 훌륭한 기본 출시 노트 세트가 생성된다.\n\n릴리스 노트에 의견을 자유롭게 추가하도록 하자. \n사람들이 볼 때, 우리가 로봇이라는 생각이 들지 않도록 하는 것이 좋다.\n\n또한 자동 생성된 릴리스 노트에서 URL과 \n체크섬이 올바른지 다시 확인해야 한다.\n\n완료되면 GitHub에서 [헬름/헬름 릴리스](https://github.com/helm/helm/releases)로 \n이동하고 여기에 작성된 메모로 태그가 지정된 \n릴리스의 릴리스 노트를 편집한다. 대상 분기의 경우 \n$RELEASE_BRANCH_NAME로 설정한다.\n\n이제는 릴리스가 게시되기 전에 다른 사람들에게 릴리스 정보를 보여주어\n검토 받을 필요가 있다. 검토를 받기 위해\n[#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG)로 \n요청을 보내자. 누구든 놓치는 부분이 있을 수 있기 때문에 항상 도움이 된다.\n\n## 8. 다운로드에 PGP 서명\n\n해시는 다운로드 내용이 어떤 것으로 생성되었는지에 대한 서명을 \n제공하지만, 서명된 패키지는 그 패키지가 어디서 왔는지 출처를\n추적할 수 있게 해준다.\n\n이렇게 하기 위하여 다음의 `make` 명령을 실행한다.\n\n```shell\nexport VERSION=\"$RELEASE_NAME\"\nmake clean\t\t# if not already run\nmake fetch-dist\t# if not already run\nmake sign\n```\n\n이렇게 하면 CI가 푸시한 개별 파일에 대하여, ASCII 아머드 서명 파일을\n생성한다.\n\n모든 서명 파일(`*.asc`)을 GitHub의 릴리스에 업로드해야\n한다. (바이너리 첨부)\n\n## 9. 릴리스 출간\n\n이제 출시를 공식화할 차례이다!\n\n릴리스 노트가 GitHub에 저장되고 CI 빌드가 완료되고 \n릴리스에 서명 파일을 추가한 후 릴리스에서 \"게시\"를 누를 수 있다. \n그러면 릴리스가 게시되고 \"최신(latest)\"으로 나열되며 \n[helm/helm] (https://github.com/helm/helm) 저장소의 첫 페이지에 이 릴리스가 표시된다.\n\n## 10. 문서 업데이트\n\n[헬름 웹 사이트 문서 섹션](/docs)에는 \n문서의 헬름 버전이 나열된다. 사이트에서 주, 부, 패치 버전을 \n업데이트해야 한다. 다음 부 릴리스 날짜도 사이트에 \n게시되며 업데이트해야 한다.\n이를 위해 [helm-www 저장소] (https://github.com/helm/helm-www)에 \n대한 pull 요청을 생성한다. \n`config.toml` 파일에서 \n적절한 `params.versions` 섹션을 찾고 [현재 버전 업데이트](https://github.com/helm/helm-www/pull/676/files)의 \n예와 같이 헬름 버전을 업데이트한다. 동일한`config.toml` 파일에서\n`params.nextversion` 섹션을 업데이트한다. \n\n해당되는 경우 릴리스의 [helm/helm 마일스톤](https://github.com/helm/helm/milestones)을 \n닫는다.\n\n주/부 릴리스의 \n[버전 차이] (https://github.com/helm/helm-www/blob/main/content/en/docs/topics/version_skew.md)를 \n업데이트한다.\n\n[여기](https://helm.sh/calendar/release)에서 릴리스 달력을 업데이트한다.\n* 당일 오후 5시 GMT에 대한 알림과 함께 다음 마이너 릴리스에 대한 항목을 생성한다.\n* 계획된 릴리스 전의 월요일에 다음 마이너 릴리스의 RC1 항목을 만들고 그날 오후 5시 GMT에 대한 알림을 생성한다.\n\n## 11. 커뮤니티에 알리기\n\n축하한다! 모두 완료했다. $DRINK_OF_CHOICE 를 한모금 하자.\n당신은 그럴만한 일을 했다.\n\n좋은 $DRINK_OF_CHOICE 를 즐긴 후, Slack과 Twitter에\n[GitHub 릴리스] (https://github.com/helm/helm/releases) 링크를 통해 \n새 릴리스를 발표하자.\n\n선택적으로, 새 릴리스에 대한 블로그 게시물을 작성하고 그 곳에 몇 가지 새로운 기능을\n보여주도록 하자!\n"
  },
  {
    "path": "i18n/ko/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: \"릴리스 스케줄 정책\"\ndescription: \"헬름의 출시 스케줄 정책을 설명한다.\"\n---\n\n사용자를 위해 헬름은 사전에 출시 날짜를 정의하고 발표한다.\n이 문서는 헬름의 출시 스케줄을 관리하는 정책을 설명한다.\n\n## 릴리스 캘린더 {#release-calendar}\n\n예정된 헬름 릴리스를 보여주는 공개 캘린더는 [여기](https://helm.sh/calendar/release)에서 확인할 수 있다.\n\n## 유의적 버전 {#semantic-versioning}\n\n헬름 버전은 `x.y.z` 로 표시된다. 여기서 `x` 는 주 버전, `y` 는\n부 버전, `z` 는 패치 버전으로서 [유의적 버전](https://semver.org/spec/v2.0.0.html)을\n따른 것이다.\n\n## 패치 릴리스 {#patch-releases}\n\n패치 릴리스는 사용자에게 버그 수정 및 보안 수정을 제공한다. 새로운 기능은 포함되어\n있지 않다.\n\n최신 부/주 릴리스와 관련된 새 패치 릴리스는 일반적으로 한 달에 한 번,\n각 달의 두 번째 수요일에 나온다.\n\n우선순위가 높은 회귀 또는 보안 문제를 수정하는 패치 릴리스는 필요시마다\n나올 수 있다.\n\n다음 이유 중 하나에 해당되면 패치 릴리스가 취소된다:\n- 이전 릴리스 이후 새로운 콘텐츠가 없는 경우\n- 패치 릴리스 날짜가 예정된 부 릴리스의 첫 번째 릴리스 후보(RC1) 1주일 이내인 경우\n- 패치 릴리스 날짜가 부 릴리스 이후 4주 이내인 경우\n\n## 부 릴리스 {#minor-releases}\n\n부 릴리스에는 보안 및 버그 수정과 새로운 기능이 포함되어 있다.\nAPI 및 CLI 사용법에 대해서는 하위호환된다.\n\n쿠버네티스 릴리스에 맞추기 위해 부 헬름 릴리스는 4개월마다 나온다.\n(1년에 릴리스 3개)\n\n필요한 경우 추가 부 릴리스가 나올 수도 있지만 발표된 릴리스가\n7일 이내가 아니라면 발표된 향후 릴리스의 일정에 영향을 주지는\n않는다.\n\n릴리스가 게시됨과 동시에 다음 부 릴리스 날짜가 발표되고 헬름 메인 웹페이지에\n게시된다.\n\n## 주 릴리스 {#major-releases}\n\n주 릴리스에는 단절적(breaking) 변경이 포함되어 있다. 이러한 출시는 드물지만\n때로는 새로운 방향으로 헬름을 계속 진화시켜 나가기 위해\n필요하다.\n\n주 릴리스는 계획하기 어려울 수 있다. 이를 염두에 두고 최종 릴리스\n날짜는 해당 릴리스의 첫 번째 베타 버전이 제공될 때만\n선택되고 발표된다.\n"
  },
  {
    "path": "i18n/ko/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Helm 프로젝트\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"차트\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"개발\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"커뮤니티\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"소스 코드\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"블로그\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"이벤트\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"행동 강령\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"소개\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"차트 팁과 요령\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"차트 개발하기\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"800개 이상의 차트 검색\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"기여 가이드\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"유지관리자\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"주간 회의\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"GitHub 커뮤니티\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<a href=\\\"https://www.cncf.io/\\\">우리는 Cloud Native Computing Foundation의 졸업 프로젝트입니다.</a><br/>© Helm Authors 2025. 문서는 <a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0</a> 하에 배포됩니다.<br/>© 2025 The Linux Foundation. 모든 권리 보유. The Linux Foundation은 등록 상표를 보유하고 사용합니다. The Linux Foundation의 상표 목록은 <a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">상표 사용 페이지</a>를 참조하세요.\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"CNCF 로고\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/ko/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Helm 로고\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"문서\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"차트\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"블로그\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"커뮤니티\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/pt/code.json",
    "content": "{\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"Próximos Lançamentos de Funcionalidades\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"Versão:\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"Data:\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"Calendário de Lançamentos\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"Próximos Eventos\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"Próximos Eventos\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"Eventos Anteriores\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"Eles {meetLink} para demonstrar e discutir ferramentas e projetos. As reuniões da comunidade são gravadas e {youtubeLink}.\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"reúnem-se semanalmente\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"partilhadas no YouTube\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"Encontro com Desenvolvedores\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"Quintas-feiras 9:30-10am (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"Estas reuniões estão abertas a todos. Consulte o {communityRepoLink} para notas e detalhes.\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"repositório da comunidade\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Discussão sobre o uso do Helm, trabalho com charts e resolução de erros comuns.\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Tópicos relacionados com o desenvolvimento do Helm, PRs em curso, lançamentos, etc.\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Discussão para utilizadores e colaboradores dos Helm Charts.\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"{slackLink} para se juntar à equipa Kubernetes Slack.\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"Solicite acesso aqui\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"Contribuir\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"O Helm sempre dá boas-vindas a novas contribuições para o projeto!\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"Por onde começar?\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"O Helm é um grande projeto com muitos utilizadores e colaboradores. Pode ser muito para absorver!\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"Temos uma lista de {goodFirstIssuesLink} se quiser ajudar mas não sabe por onde começar.\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"boas primeiras issues\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"O que devo fazer?\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"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.\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"Guia de Contribuição\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"Depois de escrever algum código, por favor {signYourCommitsLink} para garantir que o Helm adere ao acordo {dcoLink} usado pela {cncfLink}.\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"assine os seus commits\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"Entre na Comunidade\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Mais informações sobre o projeto Helm e como contribuir.\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.about.whatIsHelm\": {\n    \"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.\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"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.\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"O Helm é um projeto graduado na {cncfLink} e é mantido pela {helmCommunityLink}.\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"comunidade Helm\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"Saber mais:\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Arquitetura do Helm\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"Guia de Início Rápido\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"Vídeo: Uma Introdução ao Helm\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"O que é o Helm?\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"Gerir Complexidade\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"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.\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"Atualizações Fáceis\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"Elimine a dor das atualizações com atualizações no local e hooks personalizados.\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"Partilha Simples\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"Os Charts são fáceis de versionar, partilhar e hospedar em servidores públicos ou privados.\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"Reversões\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"Use {helmRollback} para reverter facilmente para uma versão anterior de um lançamento.\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"Funcionalidades\",\n    \"description\": \"Features section title\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"O gestor de pacotes para Kubernetes\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"O Helm é a melhor forma de encontrar, partilhar e usar software construído para\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"Começar\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"Baixe o Helm!\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"Instale o Helm com um gestor de pacotes, ou {downloadLink}.\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"transfira um binário\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"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}.\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"documentação\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"instalação\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"instruções de utilização\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"Baixe os Charts do Helm\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"Visite {artifactHubLink} para explorar {helmChartsLink} de inúmeros repositórios públicos.\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"Helm charts\",\n    \"description\": \"Helm charts link\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"Esta página deu erro.\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"Voltar para o topo\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"Navegação da página de listagem do blog\",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"Publicações mais recentes\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"Publicações mais antigas\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"Arquivo\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"Arquivo\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"Navegação da página de publicação do blog\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"Publicação mais recente\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"Publicação mais antiga\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"Ver todas as etiquetas\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"Trilha\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"modo do sistema\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"modo claro\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"modo escuro\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"Mudar entre modo claro e escuro ({mode} está ativo)\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"1 item|{count} itens\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"Páginas de documento\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"Anterior\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"Próxima\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"Um documento marcado|{count} documentos marcados\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged} com \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"Versão: {versionLabel}\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"Esta é uma documentação não lançada da versão {versionLabel} para {siteTitle}.\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"Esta é a documentação para {siteTitle} {versionLabel}, que não é mais mantida ativamente.\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"Para a documentação atualizada, consulte a {latestVersionLink} ({versionLabel}).\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"versão mais recente\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"Editar esta página\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"Link direto para {heading}\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \" em {date}\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \" por {user}\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"Última atualização{atDate}{byUser}\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"Página não encontrada\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"Versões\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"Etiquetas:\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"cuidado\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"perigo\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"informação\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"observação\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"dica\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"aviso\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"Fechar\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"Navegação das publicações recentes do blog\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"Expandir a categoria '{label}'\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"Recolher a categoria '{label}'\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(abre num novo separador)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"Navegação principal\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"Não foi possível encontrar o que você está procurando.\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"message\": \"Por favor, entre em contato com o dono do site que ligou você à URL original e informe que o link está quebrado.\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"Línguas\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"Nesta página\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"Ler mais\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"Ler mais sobre {title}\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"Copiar\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"Copiado\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"Copiar código para a área de transferência\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"Um minuto para ler|{readingTime} min para ler\",\n    \"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)\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"Alternar quebra de linha\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"Recolher painel lateral\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"Recolher painel lateral\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"Página Inicial\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"Painel lateral de documentos\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"Fechar painel de navegação\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← Voltar para o menu principal\",\n    \"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)\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"Alternar painel de navegação\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"Expandir a seleção\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"Recolher a seleção\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"Expandir painel lateral\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"Expandir painel lateral\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"Uma publicação|{count} publicações\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"{nPosts} com a etiqueta \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"Autores\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"Ver todos os autores\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"Este autor ainda não escreveu nenhuma publicação.\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"Página não listada\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"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\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"Página de rascunho\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"Esta página é um rascunho. Ela estará visível apenas no desenvolvimento e será excluída da compilação de produção.\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"Tentar novamente\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"Pular para o conteúdo principal\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"Etiquetas\",\n    \"description\": \"The title of the tag list page\"\n  }\n}\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Blog\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"Blog\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"Todos os artigos\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Usando o Helm\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Comandos do Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"Desenvolvendo Templates\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Melhores Práticas\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: Convenções Gerais\ndescription: Convenções gerais para charts.\nsidebar_position: 1\n---\n\nEsta parte do guia de boas práticas aborda convenções gerais.\n\n## Nomes de Charts\n\nOs nomes de charts devem conter apenas letras minúsculas e números. Palavras\n_podem_ ser separadas com hífens (-):\n\nExemplos:\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nLetras maiúsculas e underscores não podem ser usados em nomes de charts. Pontos\ntambém não devem ser usados.\n\n## Números de Versão\n\nSempre que possível, o Helm usa [SemVer 2](https://semver.org) para representar\nnúmeros de versão. (Note que tags de imagens Docker não seguem necessariamente\no SemVer, sendo consideradas uma exceção infeliz à regra.)\n\nQuando versões SemVer são armazenadas em labels do Kubernetes, convencionalmente\nalteramos o caractere `+` para `_`, pois labels não permitem o sinal `+` como\nvalor.\n\n## Formatação YAML\n\nArquivos YAML devem ser indentados usando _dois espaços_ (nunca tabs).\n\n## Uso das Palavras Helm e Chart\n\nExistem algumas convenções para o uso das palavras _Helm_ e _helm_.\n\n- _Helm_ refere-se ao projeto como um todo\n- `helm` refere-se ao comando do lado do cliente\n- O termo `chart` não precisa ser capitalizado, pois não é um nome próprio\n- No entanto, `Chart.yaml` deve ser capitalizado porque o nome do arquivo é\n  sensível a maiúsculas e minúsculas\n\nEm caso de dúvida, use _Helm_ (com 'H' maiúsculo).\n\n## Chart templates e namespaces\n\nEvite definir a propriedade `namespace` na seção `metadata` dos seus templates\nde chart. O namespace a ser aplicado aos templates renderizados deve ser\nespecificado na chamada ao cliente Kubernetes através de uma flag como\n`--namespace`. O Helm renderiza seus templates como estão e os envia ao cliente\nKubernetes, seja o próprio Helm ou outro programa (kubectl, flux, spinnaker,\netc).\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Custom Resource Definitions\ndescription: Como criar e utilizar CRDs.\nsidebar_position: 7\n---\n\nEsta seção do guia de boas práticas aborda a criação e utilização de objetos\nCustom Resource Definition.\n\nAo trabalhar com Custom Resource Definitions (CRDs), é importante distinguir\nduas partes diferentes:\n\n- Existe uma declaração de um CRD. Este é o arquivo YAML que tem kind\n  `CustomResourceDefinition`\n- Depois existem recursos que _usam_ o CRD. Digamos que um CRD define\n  `foo.example.com/v1`. Qualquer recurso que tenha `apiVersion: example.com/v1` e\n  kind `Foo` é um recurso que usa o CRD.\n\n## Instalar uma Declaração de CRD Antes de Usar o Recurso\n\nO Helm é otimizado para carregar o máximo de recursos possível no Kubernetes o\nmais rápido possível. Por design, o Kubernetes pode pegar um conjunto inteiro de\nmanifests e colocá-los todos online (isso é chamado de loop de reconciliação).\n\nMas há uma diferença com CRDs.\n\nPara um CRD, a declaração deve ser registrada antes que quaisquer recursos dos\ntipos do CRD possam ser usados. E o processo de registro às vezes leva alguns\nsegundos.\n\n### Método 1: Deixe o `helm` Fazer Por Você\n\nCom a chegada do Helm 3, removemos os antigos hooks `crd-install` por uma\nmetodologia mais simples. Agora existe um diretório especial chamado `crds` que\nvocê pode criar no seu chart para armazenar seus CRDs. Esses CRDs não são\ntemplateados, mas serão instalados por padrão ao executar `helm install` para o\nchart. Se o CRD já existir, ele será ignorado com um aviso. Se você deseja pular\na etapa de instalação de CRD, pode passar a flag `--skip-crds`.\n\n#### Algumas ressalvas (e explicações)\n\nNo momento não há suporte para atualizar ou excluir CRDs usando o Helm. Esta foi\numa decisão explícita após muita discussão na comunidade devido ao perigo de\nperda acidental de dados. Além disso, atualmente não há consenso na comunidade\nsobre como lidar com CRDs e seu ciclo de vida. À medida que isso evolui, o Helm\nadicionará suporte para esses casos de uso.\n\nA flag `--dry-run` de `helm install` e `helm upgrade` não é suportada atualmente\npara CRDs. O propósito do \"Dry Run\" é validar que a saída do chart realmente\nfuncionará se enviada ao servidor. Mas CRDs são uma modificação do comportamento\ndo servidor. O Helm não pode instalar o CRD em um dry run, então o cliente de\ndiscovery não saberá sobre aquele Custom Resource (CR), e a validação falhará.\nComo alternativa, você pode mover os CRDs para seu próprio chart ou usar\n`helm template` em vez disso.\n\nOutro ponto importante a considerar na discussão sobre suporte a CRD é como a\nrenderização de templates é tratada. Uma das desvantagens distintas do método\n`crd-install` usado no Helm 2 era a incapacidade de validar charts corretamente\ndevido à mudança na disponibilidade de API (um CRD está na verdade adicionando\noutra API disponível ao seu cluster Kubernetes). Se um chart instalava um CRD,\no `helm` não tinha mais um conjunto válido de versões de API para trabalhar.\nEsta também é a razão para remover o suporte a templates dos CRDs. Com o novo\nmétodo `crds` de instalação de CRD, agora garantimos que o `helm` tenha\ninformações completamente válidas sobre o estado atual do cluster.\n\n### Método 2: Charts Separados\n\nOutra forma de fazer isso é colocar a definição do CRD em um chart, e depois\ncolocar quaisquer recursos que usam esse CRD em _outro_ chart.\n\nNeste método, cada chart deve ser instalado separadamente. No entanto, esse\nfluxo de trabalho pode ser mais útil para operadores de cluster que têm acesso\nde administrador a um cluster.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: Dependências\ndescription: Aborda boas práticas para dependências declaradas no Chart.\nsidebar_position: 4\n---\n\nEsta seção do guia aborda boas práticas para `dependencies` declaradas no\n`Chart.yaml`.\n\n## Versões\n\nSempre que possível, use intervalos de versão em vez de fixar uma versão exata.\nO padrão sugerido é usar correspondência no nível de patch:\n\n```yaml\nversion: ~1.2.3\n```\n\nIsso corresponderá à versão `1.2.3` e quaisquer patches dessa release. Em outras\npalavras, `~1.2.3` é equivalente a `>= 1.2.3, < 1.3.0`\n\nPara a sintaxe completa de correspondência de versão, consulte a [documentação\ndo semver](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Versões de Pré-lançamento\n\nAs restrições de versão acima não corresponderão a versões de pré-lançamento.\nPor exemplo, `version: ~1.2.3` corresponderá a `version: ~1.2.4`, mas não a\n`version: ~1.2.3-1`. O seguinte fornece correspondência tanto para pré-lançamento\nquanto para nível de patch:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### URLs de Repositório\n\nSempre que possível, use URLs de repositório `https://`, seguidas por URLs `http://`.\n\nSe o repositório foi adicionado ao arquivo de índice de repositórios, o nome do\nrepositório pode ser usado como alias da URL. Use `alias:` ou `@` seguido do nome\ndo repositório.\n\nURLs de arquivo (`file://...`) são consideradas um \"caso especial\" para charts\nmontados por um pipeline de deploy fixo.\n\nAo usar [plugins de download](/topics/plugins.md#downloader-plugins), o esquema\nde URL será específico do plugin. Note que um usuário do chart precisará ter um\nplugin que suporte o esquema instalado para atualizar ou construir a dependência.\n\nO Helm não pode realizar operações de gerenciamento de dependências quando o campo\n`repository` é deixado em branco. Nesse caso, o Helm assumirá que a dependência\nestá em um subdiretório da pasta `charts` com o nome sendo o mesmo da propriedade\n`name` da dependência.\n\n## Condições e Tags\n\nCondições ou tags devem ser adicionadas a quaisquer dependências que _sejam\nopcionais_. Note que, por padrão, uma `condition` é `true`.\n\nA forma preferida de uma condição é:\n\n```yaml\ncondition: somechart.enabled\n```\n\nOnde `somechart` é o nome do chart da dependência.\n\nQuando múltiplos subcharts (dependências) juntos fornecem uma funcionalidade\nopcional ou substituível, esses charts devem compartilhar as mesmas tags.\n\nPor exemplo, se tanto `nginx` quanto `memcached` juntos fornecem otimizações de\ndesempenho para a aplicação principal no chart, e ambos precisam estar presentes\nquando essa funcionalidade está habilitada, então ambos devem ter uma seção de\ntags assim:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nIsso permite que um usuário ative ou desative essa funcionalidade com uma única tag.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: Labels e Annotations\ndescription: Aborda as boas práticas para o uso de labels e annotations no seu chart.\nsidebar_position: 5\n---\n\nEsta parte do guia de boas práticas discute o uso de labels e annotations no\nseu chart.\n\n## É uma Label ou uma Annotation?\n\nUm item de metadados deve ser uma label nas seguintes condições:\n\n- É usado pelo Kubernetes para identificar este recurso\n- É útil expor aos operadores para fins de consulta ao sistema.\n\nPor exemplo, sugerimos usar `helm.sh/chart: NAME-VERSION` como uma label para\nque os operadores possam encontrar convenientemente todas as instâncias de um\nchart específico.\n\nSe um item de metadados não for usado para consultas, deve ser definido como\numa annotation.\n\nHooks do Helm são sempre annotations.\n\n## Labels Padrão\n\nA tabela a seguir define labels comuns que os charts do Helm usam. O próprio\nHelm nunca exige que uma label específica esteja presente. Labels marcadas como\nREC são recomendadas e _devem_ ser incluídas em um chart para consistência\nglobal. As marcadas como OPT são opcionais. Estas são idiomáticas ou comumente\nusadas, mas não são frequentemente utilizadas para fins operacionais.\n\n| Nome | Status | Descrição |\n|------|--------|-----------|\n| `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. |\n| `helm.sh/chart` | REC | Deve ser o nome e a versão do chart: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`. |\n| `app.kubernetes.io/managed-by` | REC | Deve sempre ser definido como `{{ .Release.Service }}`. Serve para encontrar tudo que é gerenciado pelo Helm. |\n| `app.kubernetes.io/instance` | REC | Deve ser o `{{ .Release.Name }}`. Ajuda a diferenciar entre diferentes instâncias da mesma aplicação. |\n| `app.kubernetes.io/version` | OPT | A versão da aplicação, podendo ser definida como `{{ .Chart.AppVersion }}`. |\n| `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`. |\n| `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. |\n\nVocê pode encontrar mais informações sobre as labels do Kubernetes, prefixadas\ncom `app.kubernetes.io`, na [documentação do\nKubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pods e PodTemplates\ndescription: Discute a formatação das seções Pod e PodTemplate nos manifestos de charts.\nsidebar_position: 6\n---\n\nEsta parte do guia de boas práticas discute a formatação das seções Pod e\nPodTemplate nos manifestos de charts.\n\nA seguinte lista (não exaustiva) de recursos utiliza PodTemplates:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Imagens\n\nUma imagem de container deve usar uma tag fixa ou o SHA da imagem. Não deve\nusar as tags `latest`, `head`, `canary`, ou outras tags flutuantes.\n\nImagens _podem_ ser definidas no arquivo `values.yaml` para facilitar a troca\nde imagens.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nUma imagem e uma tag _podem_ ser definidas no `values.yaml` como dois campos\nseparados:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` define a `imagePullPolicy` como `IfNotPresent` por padrão,\nfazendo o seguinte no seu `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nE no `values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nDa mesma forma, o Kubernetes assume por padrão a `imagePullPolicy` como\n`IfNotPresent` se ela não for definida. Se você quiser um valor diferente de\n`IfNotPresent`, simplesmente atualize o valor em `values.yaml` para o valor\ndesejado.\n\n## PodTemplates Devem Declarar Selectors\n\nTodas as seções de PodTemplate devem especificar um selector. Por exemplo:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nEsta é uma boa prática porque torna explícita a relação entre o conjunto de\nworkload e o pod.\n\nMas isto é ainda mais importante para conjuntos como Deployment. Sem isso, o\nconjunto _inteiro_ de labels é usado para selecionar pods correspondentes, e\nisso pode falhar se você usar labels que mudam, como versão ou data de\nlançamento.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: Controle de Acesso Baseado em Funções\ndescription: Discute a criação e formatação de recursos RBAC em manifestos de Chart.\nsidebar_position: 8\n---\n\nEsta parte do guia de boas práticas discute a criação e formatação de recursos\nRBAC em manifestos de chart.\n\nOs recursos RBAC são:\n\n- ServiceAccount (com namespace)\n- Role (com namespace)\n- ClusterRole\n- RoleBinding (com namespace)\n- ClusterRoleBinding\n\n## Configuração YAML\n\nA configuração de RBAC e ServiceAccount deve ser feita em chaves separadas. São\nconceitos distintos. Separá-los no YAML deixa essa distinção mais clara.\n\n```yaml\nrbac:\n  # Especifica se os recursos RBAC devem ser criados\n  create: true\n\nserviceAccount:\n  # Especifica se uma ServiceAccount deve ser criada\n  create: true\n  # O nome da ServiceAccount a ser usada.\n  # Se não definido e create for true, um nome é gerado usando o template fullname\n  name:\n```\n\nEsta estrutura pode ser estendida para charts mais complexos que requerem\nmúltiplas ServiceAccounts.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## Recursos RBAC Devem Ser Criados por Padrão\n\n`rbac.create` deve ser um valor booleano que controla se os recursos RBAC são\ncriados. O padrão deve ser `true`. Usuários que desejam gerenciar os controles\nde acesso RBAC por conta própria podem definir este valor como `false` (nesse\ncaso, veja abaixo).\n\n## Usando Recursos RBAC\n\n`serviceAccount.name` deve ser definido como o nome da ServiceAccount a ser\nusada pelos recursos com controle de acesso criados pelo chart. Se\n`serviceAccount.create` for true, então uma ServiceAccount com este nome deve\nser criada. Se o nome não for definido, então um nome é gerado usando o template\n`fullname`. Se `serviceAccount.create` for false, então ela não deve ser criada,\nmas ainda deve ser associada aos mesmos recursos para que recursos RBAC criados\nmanualmente posteriormente que a referenciem funcionem corretamente. Se\n`serviceAccount.create` for false e o nome não for especificado, então a\nServiceAccount padrão é usada.\n\nO seguinte template auxiliar deve ser usado para a ServiceAccount.\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: Templates\ndescription: Uma visão mais detalhada das boas práticas relacionadas a templates.\nsidebar_position: 3\n---\n\nEsta parte do guia de boas práticas foca em templates.\n\n## Estrutura de `templates/`\n\nO diretório `templates/` deve ser estruturado da seguinte forma:\n\n- Arquivos de template devem ter a extensão `.yaml` se produzirem saída YAML.\n  A extensão `.tpl` pode ser usada para arquivos de template que não produzem\n  conteúdo formatado.\n- Nomes de arquivos de template devem usar notação com hífens (`my-example-configmap.yaml`),\n  não camelCase.\n- Cada definição de recurso deve estar em seu próprio arquivo de template.\n- Nomes de arquivos de template devem refletir o tipo de recurso no nome. Ex.:\n  `foo-pod.yaml`, `bar-svc.yaml`\n\n## Nomes de Templates Definidos\n\nTemplates definidos (templates criados dentro de uma diretiva `{{ define }}`) são\nglobalmente acessíveis. Isso significa que um chart e todos os seus subcharts terão\nacesso a todos os templates criados com `{{ define }}`.\n\nPor esse motivo, _todos os nomes de templates definidos devem usar namespace._\n\nCorreto:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nIncorreto:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\n\nÉ altamente recomendado que novos charts sejam criados através do comando `helm create`,\npois os nomes dos templates são automaticamente definidos de acordo com esta boa prática.\n\n## Formatação de Templates\n\nTemplates devem ser indentados usando _dois espaços_ (nunca tabs).\n\nAs diretivas de template devem ter espaço em branco após as chaves de abertura e antes\ndas chaves de fechamento:\n\nCorreto:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nIncorreto:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nTemplates devem suprimir espaços em branco quando possível:\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nBlocos (como estruturas de controle) podem ser indentados para indicar o fluxo do\ncódigo do template.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nNo entanto, como YAML é uma linguagem orientada a espaços em branco, nem sempre é\npossível que a indentação do código siga essa convenção.\n\n## Espaços em Branco nos Templates Gerados\n\nÉ preferível manter a quantidade de espaços em branco nos templates gerados no\nmínimo. Em particular, várias linhas em branco não devem aparecer adjacentes umas\nàs outras. Porém, linhas vazias ocasionais (particularmente entre seções lógicas) são\naceitáveis.\n\nIdeal:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nAceitável:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nMas isto deve ser evitado:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Comentários (Comentários YAML vs. Comentários de Template)\n\nTanto YAML quanto Helm Templates possuem marcadores de comentário.\n\nComentários YAML:\n```yaml\n# This is a comment\ntype: sprocket\n```\n\nComentários de Template:\n```yaml\n{{- /*\nThis is a comment.\n*/}}\ntype: frobnitz\n```\n\nComentários de template devem ser usados ao documentar funcionalidades de um template,\ncomo explicar um template definido:\n\n```yaml\n{{- /*\nmychart.shortname provides a 6 char truncated version of the release name.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nDentro dos templates, comentários YAML podem ser usados quando for útil para os\nusuários do Helm (possivelmente) verem os comentários durante a depuração.\n\n```yaml\n# This may cause problems if the value is more than 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nO comentário acima é visível quando o usuário executa `helm install --debug`, enquanto\ncomentários especificados em seções `{{- /* */}}` não são.\n\nTenha 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.\n\nPor 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.\n\nCorreto: `helm template` não renderiza este bloco\n```yaml\n{{- /*\n# This may cause problems if the value is more than 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nIncorreto: `helm template` retorna `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n```yaml\n# This may cause problems if the value is more than 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nConsulte [Depuração de Templates](../chart_template_guide/debugging.md) para outro exemplo deste comportamento de como comentários YAML são mantidos intactos.\n\n## Uso de JSON em Templates e Saída de Template\n\nYAML é um superconjunto de JSON. Em alguns casos, usar uma sintaxe JSON pode ser mais\nlegível do que outras representações YAML.\n\nPor exemplo, este YAML está mais próximo do método normal de YAML para expressar listas:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nMas é mais fácil de ler quando colapsado em estilo de lista JSON:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nUsar JSON para maior legibilidade é bom. No entanto, a sintaxe JSON não deve ser\nusada para representar construções mais complexas.\n\nAo lidar com JSON puro incorporado dentro de YAML (como configuração de init container),\né claro que é apropriado usar o formato JSON.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: Values\ndescription: Foca em como você deve estruturar e usar seus values.\nsidebar_position: 2\n---\n\nEsta parte do guia de boas práticas aborda o uso de values. Nesta parte do\nguia, fornecemos recomendações sobre como você deve estruturar e usar seus\nvalues, com foco no design do arquivo `values.yaml` do chart.\n\n## Convenções de Nomenclatura\n\nOs nomes das variáveis devem começar com uma letra minúscula, e as palavras\ndevem ser separadas com camelCase:\n\nCorreto:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nIncorreto:\n\n```yaml\nChicken: true  # letras maiúsculas iniciais podem conflitar com variáveis internas\nchicken-noodle-soup: true # não use hífens no nome\n```\n\nNote que todas as variáveis internas do Helm começam com uma letra maiúscula\npara facilitar a distinção das variáveis definidas pelo usuário: `.Release.Name`,\n`.Capabilities.KubeVersion`.\n\n## Values Planos ou Aninhados\n\nYAML é um formato flexível, e os values podem ser profundamente aninhados ou\nplanos.\n\nAninhado:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nPlano:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nNa maioria dos casos, prefira o formato plano ao aninhado. O motivo é que ele é\nmais simples tanto para desenvolvedores de templates quanto para usuários.\n\nPara segurança ideal, um valor aninhado deve ser verificado em cada nível:\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nPara cada camada de aninhamento, uma verificação de existência deve ser feita.\nMas para configuração plana, tais verificações podem ser ignoradas, tornando o\ntemplate mais fácil de ler e usar.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\nQuando há um grande número de variáveis relacionadas, e pelo menos uma delas é\nobrigatória, values aninhados podem ser usados para melhorar a legibilidade.\n\n## Seja Claro com os Tipos\n\nAs regras de conversão de tipos do YAML às vezes são contraintuitivas. Por\nexemplo, `foo: false` não é o mesmo que `foo: \"false\"`. Inteiros grandes como\n`foo: 12345678` serão convertidos para notação científica em alguns casos.\n\nA maneira mais fácil de evitar erros de conversão de tipo é ser explícito sobre\nstrings e implícito sobre todo o resto. Ou, em resumo, _coloque aspas em todas\nas strings_.\n\nFrequentemente, para evitar problemas de conversão de inteiros, é vantajoso\narmazenar seus inteiros como strings também, e usar `{{ int $value }}` no\ntemplate para converter de uma string de volta para um inteiro.\n\nNa maioria dos casos, tags de tipo explícitas são respeitadas, então `foo:\n!!string 1234` deve tratar `1234` como uma string. _No entanto_, o parser YAML\nconsome as tags, então os dados de tipo são perdidos após um parse.\n\n## Considere Como os Usuários Usarão Seus Values\n\nExistem três fontes potenciais de values:\n\n- O arquivo `values.yaml` do chart\n- Um arquivo de values fornecido por `helm install -f` ou `helm upgrade -f`\n- Os values passados para a flag `--set` ou `--set-string` no `helm install` ou\n  `helm upgrade`\n\nAo projetar a estrutura dos seus values, tenha em mente que os usuários do seu\nchart podem querer sobrescrevê-los via flag `-f` ou com a opção `--set`.\n\nComo `--set` é mais limitado em expressividade, a primeira diretriz para\nescrever seu arquivo `values.yaml` é _facilitar a sobrescrita via `--set`_.\n\nPor essa razão, geralmente é melhor estruturar seu arquivo de values usando maps.\n\nDifícil de usar com `--set`:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nO exemplo acima não pode ser expresso com `--set` no Helm `<=2.4`. No Helm 2.5,\nacessar a porta em foo é `--set servers[0].port=80`. Não apenas é mais difícil\npara o usuário descobrir, mas também é propenso a erros se em algum momento\nfuturo a ordem dos `servers` for alterada.\n\nFácil de usar:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nAcessar a porta de foo é muito mais óbvio: `--set servers.foo.port=80`.\n\n## Documente o `values.yaml`\n\nCada propriedade definida no `values.yaml` deve ser documentada. A string de\ndocumentação deve começar com o nome da propriedade que ela descreve e depois\nfornecer pelo menos uma descrição de uma frase.\n\nIncorreto:\n\n```yaml\n# o nome do host para o servidor web\nserverHost: example\nserverPort: 9191\n```\n\nCorreto:\n\n```yaml\n# serverHost é o nome do host para o servidor web\nserverHost: example\n# serverPort é a porta do listener HTTP para o servidor web\nserverPort: 9191\n```\n\nComeçar cada comentário com o nome do parâmetro que ele documenta facilita a\nbusca por documentação com grep, e permitirá que ferramentas de documentação\ncorrelacionem de forma confiável as strings de documentação com os parâmetros\nque elas descrevem.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Acessando Arquivos Dentro de Templates\ndescription: Como acessar arquivos de dentro de um template.\nsidebar_position: 10\n---\n\nNa seção anterior, vimos várias maneiras de criar e acessar templates nomeados.\nIsso facilita a importação de um template de dentro de outro template. Mas às\nvezes é desejável importar um _arquivo que não é um template_ e injetar seu\nconteúdo sem enviá-lo pelo renderizador de templates.\n\nO Helm fornece acesso a arquivos através do objeto `.Files`. Antes de começarmos\ncom os exemplos de templates, porém, há algumas coisas a observar sobre como\nisso funciona:\n\n- É permitido adicionar arquivos extras ao seu chart do Helm. Esses arquivos serão\n  empacotados. Mas tenha cuidado. Charts devem ter menos de 1M devido às limitações\n  de armazenamento dos objetos do Kubernetes.\n- Alguns arquivos não podem ser acessados através do objeto `.Files`, geralmente\n  por razões de segurança.\n  - Arquivos em `templates/` não podem ser acessados.\n  - Arquivos excluídos usando `.helmignore` não podem ser acessados.\n  - Arquivos fora de um [subchart](./subcharts_and_globals.md) de uma aplicação Helm, incluindo os do chart pai, não podem ser acessados\n- Charts não preservam informações de modo UNIX, portanto as permissões a nível\n  de arquivo não terão impacto na disponibilidade de um arquivo quando se trata\n  do objeto `.Files`.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Exemplo básico](#exemplo-básico)\n- [Helpers de caminho](#helpers-de-caminho)\n- [Padrões glob](#padrões-glob)\n- [Funções utilitárias para ConfigMap e Secrets](#funções-utilitárias-para-configmap-e-secrets)\n- [Codificação](#codificação)\n- [Linhas](#linhas)\n\n<!-- tocstop -->\n\n## Exemplo básico\n\nCom essas ressalvas em mente, vamos escrever um template que lê três arquivos\nem nosso ConfigMap. Para começar, adicionaremos três arquivos ao chart, colocando\nos três diretamente dentro do diretório `mychart/`.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nCada um destes é um arquivo TOML simples (pense nos arquivos INI do Windows antigo).\nSabemos os nomes desses arquivos, então podemos usar uma função `range` para\niterar sobre eles e injetar seu conteúdo em nosso ConfigMap.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nEste ConfigMap usa várias das técnicas discutidas nas seções anteriores.\nPor exemplo, criamos uma variável `$files` para manter uma referência ao objeto\n`.Files`. Também usamos a função `tuple` para criar uma lista de arquivos pela\nqual iteramos. Então imprimimos cada nome de arquivo (`{{ . }}: |-`) seguido pelo\nconteúdo do arquivo `{{ $files.Get . }}`.\n\nExecutar este template produzirá um único ConfigMap com o conteúdo de todos\nos três arquivos:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Helpers de caminho\n\nAo trabalhar com arquivos, pode ser muito útil realizar algumas operações padrão\nnos próprios caminhos dos arquivos. Para ajudar com isso, o Helm importa muitas\ndas funções do pacote [path](https://golang.org/pkg/path/) do Go para seu uso.\nElas são todas acessíveis com os mesmos nomes do pacote Go, mas com a primeira\nletra em minúsculo. Por exemplo, `Base` se torna `base`, etc.\n\nAs funções importadas são:\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Padrões glob\n\nÀ medida que seu chart cresce, você pode descobrir que tem uma necessidade maior\nde organizar seus arquivos, e por isso fornecemos um método\n`Files.Glob(pattern string)` para ajudar a extrair certos arquivos com toda a\nflexibilidade dos [padrões glob](https://godoc.org/github.com/gobwas/glob).\n\n`.Glob` retorna um tipo `Files`, então você pode chamar qualquer um dos métodos\n`Files` no objeto retornado.\n\nPor exemplo, imagine a estrutura de diretórios:\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nVocê tem múltiplas opções com Globs:\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nOu\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## Funções utilitárias para ConfigMap e Secrets\n\n(Disponível no Helm 2.0.2 e posteriores)\n\nÉ muito comum querer colocar conteúdo de arquivos tanto em ConfigMaps quanto em\nSecrets, para montá-los em seus pods em tempo de execução. Para ajudar com isso,\nfornecemos alguns métodos utilitários no tipo `Files`.\n\nPara maior organização, é especialmente útil usar esses métodos em conjunto com\no método `Glob`.\n\nDada a estrutura de diretórios do exemplo [Glob](#padrões-glob) acima:\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Codificação\n\nVocê pode importar um arquivo e fazer o template codificá-lo em base-64 para\ngarantir uma transmissão bem-sucedida:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nO exemplo acima pegará o mesmo arquivo `config1.toml` que usamos antes e o codificará:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Linhas\n\nÀs vezes é desejável acessar cada linha de um arquivo em seu template. Fornecemos\num método conveniente `Lines` para isso.\n\nVocê pode percorrer `Lines` usando uma função `range`:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nNão há como passar arquivos externos ao chart durante `helm install`. Portanto,\nse você está pedindo aos usuários que forneçam dados, eles devem ser carregados\nusando `helm install -f` ou `helm install --set`.\n\nEsta discussão encerra nosso aprofundamento nas ferramentas e técnicas para\nescrever templates do Helm. Na próxima seção, veremos como você pode usar um\narquivo especial, `templates/NOTES.txt`, para enviar instruções pós-instalação\naos usuários do seu chart.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Objetos Embutidos\ndescription: Objetos embutidos disponíveis para templates.\nsidebar_position: 3\n---\n\nObjetos são passados para um template pelo motor de templates. Seu código também pode\npassar objetos adiante (veremos exemplos quando analisarmos as instruções `with` e `range`).\nExistem até algumas formas de criar novos objetos dentro dos seus templates, como\ncom a função `tuple` que veremos mais adiante.\n\nObjetos podem ser simples e ter apenas um valor. Ou podem conter outros objetos\nou funções. Por exemplo, o objeto `Release` contém vários objetos (como\n`Release.Name`) e o objeto `Files` possui algumas funções.\n\nNa seção anterior, usamos `{{ .Release.Name }}` para inserir o nome de um release\nem um template. `Release` é um dos objetos de nível superior que você pode\nacessar nos seus templates.\n\n- `Release`: Este objeto descreve o próprio release. Ele contém vários objetos:\n  - `Release.Name`: O nome do release\n  - `Release.Namespace`: O namespace no qual o release será instalado (se o\n    manifesto não sobrescrever)\n  - `Release.IsUpgrade`: Este valor é definido como `true` se a operação atual\n    for um upgrade ou rollback.\n  - `Release.IsInstall`: Este valor é definido como `true` se a operação atual\n    for uma instalação.\n  - `Release.Revision`: O número de revisão deste release. Na instalação, este\n    valor é 1, e é incrementado a cada upgrade e rollback.\n  - `Release.Service`: O serviço que está renderizando o template atual. No\n    Helm, este valor é sempre `Helm`.\n- `Values`: Valores passados para o template a partir do arquivo `values.yaml` e\n  de arquivos fornecidos pelo usuário. Por padrão, `Values` está vazio.\n- `Chart`: O conteúdo do arquivo `Chart.yaml`. Qualquer dado em `Chart.yaml`\n  estará acessível aqui. Por exemplo, `{{ .Chart.Name }}-{{ .Chart.Version }}`\n  exibirá `mychart-0.1.0`.\n  - Os campos disponíveis estão listados no [Guia de Charts](/topics/charts.md#the-chartyaml-file)\n- `Subcharts`: Fornece acesso ao escopo (.Values, .Charts, .Releases etc.) dos\n  subcharts para o chart pai. Por exemplo, `.Subcharts.mySubChart.myValue` para\n  acessar o valor `myValue` no chart `mySubChart`.\n- `Files`: Fornece acesso a todos os arquivos não especiais em um chart. Embora\n  você não possa usá-lo para acessar templates, pode usá-lo para acessar outros\n  arquivos no chart. Consulte a seção [Acessando Arquivos](/chart_template_guide/accessing_files.md)\n  para mais informações.\n  - `Files.Get` é uma função para obter um arquivo pelo nome (`.Files.Get\n    config.ini`)\n  - `Files.GetBytes` é uma função para obter o conteúdo de um arquivo como um\n    array de bytes em vez de uma string. Isso é útil para coisas como imagens.\n  - `Files.Glob` é uma função que retorna uma lista de arquivos cujos nomes\n    correspondem ao padrão glob fornecido.\n  - `Files.Lines` é uma função que lê um arquivo linha por linha. Isso é útil\n    para iterar sobre cada linha de um arquivo.\n  - `Files.AsSecrets` é uma função que retorna o conteúdo dos arquivos como\n    strings codificadas em Base 64.\n  - `Files.AsConfig` é uma função que retorna o conteúdo dos arquivos como um\n    mapa YAML.\n- `Capabilities`: Fornece informações sobre as capacidades que o cluster\n  Kubernetes suporta.\n  - `Capabilities.APIVersions` é um conjunto de versões.\n  - `Capabilities.APIVersions.Has $version` indica se uma versão (por exemplo,\n    `batch/v1`) ou recurso (por exemplo, `apps/v1/Deployment`) está disponível\n    no cluster.\n  - `Capabilities.KubeVersion` e `Capabilities.KubeVersion.Version` é a versão\n    do Kubernetes.\n  - `Capabilities.KubeVersion.Major` é a versão major do Kubernetes.\n  - `Capabilities.KubeVersion.Minor` é a versão minor do Kubernetes.\n  - `Capabilities.HelmVersion` é o objeto que contém os detalhes da versão do Helm, o mesmo resultado de `helm version`.\n  - `Capabilities.HelmVersion.Version` é a versão atual do Helm no formato semver.\n  - `Capabilities.HelmVersion.GitCommit` é o sha1 do git do Helm.\n  - `Capabilities.HelmVersion.GitTreeState` é o estado da árvore git do Helm.\n  - `Capabilities.HelmVersion.GoVersion` é a versão do compilador Go utilizado.\n- `Template`: Contém informações sobre o template atual que está sendo executado\n  - `Template.Name`: Um caminho de arquivo com namespace para o template atual\n    (por exemplo, `mychart/templates/mytemplate.yaml`)\n  - `Template.BasePath`: O caminho com namespace para o diretório de templates\n    do chart atual (por exemplo, `mychart/templates`).\n\nOs valores embutidos sempre começam com letra maiúscula. Isso segue a convenção\nde nomenclatura do Go. Quando você cria seus próprios nomes, você é livre para\nusar uma convenção que se adeque à sua equipe. Algumas equipes, como muitas\ncujos charts você pode ver no [Artifact Hub](https://artifacthub.io/packages/search?kind=0),\nescolhem usar apenas letras minúsculas iniciais para distinguir nomes locais\ndaqueles embutidos. Neste guia, seguimos essa convenção.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Controle de Fluxo\ndescription: Uma visão rápida sobre a estrutura de fluxo dentro dos templates.\nsidebar_position: 7\n---\n\nEstruturas de controle (chamadas de \"actions\" na terminologia de templates)\nfornecem a você, o autor do template, a capacidade de controlar o fluxo de\ngeração de um template. A linguagem de template do Helm oferece as seguintes\nestruturas de controle:\n\n- `if`/`else` para criar blocos condicionais\n- `with` para especificar um escopo\n- `range`, que fornece um loop no estilo \"for each\"\n\nAlém destas, ela fornece algumas actions para declarar e usar segmentos\nde template nomeados:\n\n- `define` declara um novo template nomeado dentro do seu template\n- `template` importa um template nomeado\n- `block` declara um tipo especial de área de template preenchível\n\nNesta seção, falaremos sobre `if`, `with` e `range`. Os outros são\nabordados na seção \"Templates Nomeados\" mais adiante neste guia.\n\n## If/Else\n\nA primeira estrutura de controle que veremos é para incluir condicionalmente\nblocos de texto em um template. Este é o bloco `if`/`else`.\n\nA estrutura básica de uma condicional é assim:\n\n```\n{{ if PIPELINE }}\n  # Faça algo\n{{ else if OTHER PIPELINE }}\n  # Faça outra coisa\n{{ else }}\n  # Caso padrão\n{{ end }}\n```\n\nNote que agora estamos falando sobre _pipelines_ em vez de valores. O motivo\né deixar claro que estruturas de controle podem executar um pipeline inteiro,\nnão apenas avaliar um valor.\n\nUm pipeline é avaliado como _false_ se o valor for:\n\n- um booleano false\n- um zero numérico\n- uma string vazia\n- um `nil` (vazio ou nulo)\n- uma coleção vazia (`map`, `slice`, `tuple`, `dict`, `array`)\n\nEm todas as outras condições, a condição é verdadeira.\n\nVamos adicionar uma condicional simples ao nosso ConfigMap. Adicionaremos\noutra configuração se a bebida estiver definida como coffee:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nComo comentamos `drink: coffee` no nosso último exemplo, a saída não\ndeve incluir a flag `mug: \"true\"`. Mas se adicionarmos essa linha de volta\nao nosso arquivo `values.yaml`, a saída deve ficar assim:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Controlando Espaços em Branco\n\nEnquanto olhamos para condicionais, devemos dar uma olhada rápida na forma\ncomo os espaços em branco são controlados em templates. Vamos pegar o exemplo\nanterior e formatá-lo para ser um pouco mais fácil de ler:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nInicialmente, isso parece bom. Mas se passarmos pelo motor de template, teremos\num resultado infeliz:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nO que aconteceu? Geramos YAML incorreto por causa dos espaços em branco acima.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` está indentado incorretamente. Vamos apenas remover a indentação\ndessa linha e executar novamente:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nQuando enviarmos isso, obteremos um YAML que é válido, mas ainda parece\num pouco estranho:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nNote que recebemos algumas linhas vazias no nosso YAML. Por quê? Quando o\nmotor de template executa, ele _remove_ o conteúdo dentro de `{{` e `}}`,\nmas deixa os espaços em branco restantes exatamente como estão.\n\nO YAML atribui significado aos espaços em branco, então gerenciar os espaços\nem branco se torna bastante importante. Felizmente, os templates do Helm têm\nalgumas ferramentas para ajudar.\n\nPrimeiro, a sintaxe de chaves das declarações de template pode ser modificada\ncom caracteres especiais para instruir o motor de template a consumir espaços\nem branco. `{{- ` (com o hífen e espaço adicionados) indica que os espaços em\nbranco à esquerda devem ser consumidos, enquanto ` -}}` significa que os\nespaços em branco à direita devem ser consumidos. _Cuidado! Quebras de linha\nsão espaços em branco!_\n\n> Certifique-se de que há um espaço entre o `-` e o resto da sua diretiva.\n> `{{- 3 }}` significa \"remover espaços à esquerda e imprimir 3\" enquanto\n> `{{-3 }}` significa \"imprimir -3\".\n\nUsando essa sintaxe, podemos modificar nosso template para eliminar essas\nnovas linhas:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nApenas para deixar esse ponto claro, vamos ajustar o texto acima e\nsubstituir um `*` para cada espaço em branco que será removido seguindo\nesta regra. Um `*` no final da linha indica um caractere de nova linha\nque seria removido\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nTendo isso em mente, podemos executar nosso template através do Helm e\nver o resultado:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nTenha cuidado com os modificadores de remoção de espaços. É fácil\nacidentalmente fazer coisas assim:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nIsso produzirá `food: \"PIZZA\"mug: \"true\"` porque consumiu as novas linhas\nem ambos os lados.\n\n> Para detalhes sobre controle de espaços em branco em templates, veja a\n> [documentação oficial de templates do Go](https://godoc.org/text/template)\n\nFinalmente, às vezes é mais fácil dizer ao sistema de templates como indentar\npara você em vez de tentar dominar o espaçamento das diretivas de template.\nPor essa razão, você pode às vezes achar útil usar a função `indent`\n(`{{ indent 2 \"mug:true\" }}`).\n\n## Modificando o Escopo com `with`\n\nA próxima estrutura de controle a ser analisada é a action `with`. Ela controla\no escopo de variáveis. Lembre-se de que `.` é uma referência ao _escopo atual_.\nEntão `.Values` diz ao template para encontrar o objeto `Values` no escopo\natual.\n\nA sintaxe do `with` é similar a uma instrução `if` simples:\n\n```\n{{ with PIPELINE }}\n  # escopo restrito\n{{ end }}\n```\n\nEscopos podem ser alterados. `with` permite que você defina o escopo atual (`.`)\npara um objeto específico. Por exemplo, estivemos trabalhando com\n`.Values.favorite`. Vamos reescrever nosso ConfigMap para alterar o escopo de `.`\npara apontar para `.Values.favorite`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nNote que removemos a condicional `if` do exercício anterior porque agora ela\né desnecessária - o bloco após `with` só é executado se o valor de `PIPELINE`\nnão for vazio.\n\nObserve que agora podemos referenciar `.drink` e `.food` sem qualificá-los.\nIsso porque a instrução `with` define `.` para apontar para `.Values.favorite`.\nO `.` é redefinido para seu escopo anterior após `{{ end }}`.\n\nMas aqui vai uma nota de cautela! Dentro do escopo restrito, você não poderá\nacessar os outros objetos do escopo pai usando `.`. Por exemplo, isso falhará:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nIsso produzirá um erro porque `Release.Name` não está dentro do escopo\nrestrito de `.`. No entanto, se trocarmos as duas últimas linhas, tudo\nfuncionará como esperado porque o escopo é redefinido após `{{ end }}`.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nOu, podemos usar `$` para acessar o objeto `Release.Name` do escopo pai.\n`$` é mapeado para o escopo raiz quando a execução do template começa e\nnão muda durante a execução do template. O seguinte também funcionaria:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nDepois de ver `range`, daremos uma olhada nas variáveis de template, que\noferecem uma solução para o problema de escopo acima.\n\n## Iterando com a Action `range`\n\nMuitas linguagens de programação têm suporte para iteração usando loops `for`,\nloops `foreach` ou mecanismos funcionais similares. Na linguagem de template\ndo Helm, a forma de iterar através de uma coleção é usar o operador `range`.\n\nPara começar, vamos adicionar uma lista de coberturas de pizza ao nosso\narquivo `values.yaml`:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nAgora temos uma lista (chamada de `slice` em templates) de `pizzaToppings`.\nPodemos modificar nosso template para imprimir essa lista no nosso ConfigMap:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nPodemos usar `$` para acessar a lista `Values.pizzaToppings` do escopo pai.\n`$` é mapeado para o escopo raiz quando a execução do template começa e\nnão muda durante a execução do template. O seguinte também funcionaria:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nVamos olhar mais de perto a lista `toppings:`. A função `range` irá\n\"iterar sobre\" (percorrer) a lista `pizzaToppings`. Mas agora algo\ninteressante acontece. Assim como `with` define o escopo de `.`, um\noperador `range` também faz isso. Cada vez que passa pelo loop, `.`\né definido para a cobertura de pizza atual. Ou seja, na primeira vez,\n`.` é definido como `mushrooms`. Na segunda iteração, é definido como\n`cheese`, e assim por diante.\n\nPodemos enviar o valor de `.` diretamente para um pipeline, então quando\nfazemos `{{ . | title | quote }}`, ele envia `.` para `title` (função que\ncoloca em título) e depois para `quote`. Se executarmos esse template,\na saída será:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nAgora, neste exemplo fizemos algo astuto. A linha `toppings: |-` está\ndeclarando uma string de múltiplas linhas. Então nossa lista de coberturas\nna verdade não é uma lista YAML. É uma grande string. Por que faríamos isso?\nPorque os dados em `data` de ConfigMaps são compostos de pares chave/valor,\nonde tanto a chave quanto o valor são strings simples. Para entender por que\né assim, dê uma olhada na\n[documentação de ConfigMap do Kubernetes](https://kubernetes.io/docs/concepts/configuration/configmap/).\nPara nós, porém, esse detalhe não importa muito.\n\n> O marcador `|-` no YAML recebe uma string de múltiplas linhas. Essa pode ser\n> uma técnica útil para incorporar grandes blocos de dados dentro dos seus\n> manifests, como exemplificado aqui.\n\nÀs vezes é útil poder criar rapidamente uma lista dentro do seu template,\ne depois iterar sobre essa lista. Os templates do Helm têm uma função para\nfacilitar isso: `tuple`. Em ciência da computação, uma tupla é uma coleção\nsemelhante a uma lista de tamanho fixo, mas com tipos de dados arbitrários.\nIsso transmite aproximadamente a forma como um `tuple` é usado.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nO código acima produzirá isso:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nAlém de listas e tuplas, `range` pode ser usado para iterar sobre coleções\nque têm uma chave e um valor (como um `map` ou `dict`). Veremos como fazer\nisso na próxima seção quando introduzirmos variáveis de template.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Apêndice: Tipos de Dados Go e Templates\"\ndescription: Uma visão geral rápida sobre variáveis em templates.\nsidebar_position: 16\n---\n\nA linguagem de templates do Helm é implementada na linguagem de programação Go,\nque é fortemente tipada. Por isso, variáveis em templates são _tipadas_. Na\nmaior parte dos casos, as variáveis serão expostas como um dos seguintes tipos:\n\n- string: Uma cadeia de texto\n- bool: `true` ou `false`\n- int: Um valor inteiro (há também variantes de 8, 16, 32 e 64 bits, com sinal\n  e sem sinal)\n- float64: Um valor de ponto flutuante de 64 bits (há também variantes de 8, 16\n  e 32 bits)\n- um slice de bytes (`[]byte`), frequentemente usado para armazenar dados\n  (potencialmente) binários\n- struct: um objeto com propriedades e métodos\n- um slice (lista indexada) de um dos tipos anteriores\n- um map com chaves string (`map[string]interface{}`) onde o valor é um dos\n  tipos anteriores\n\nExistem muitos outros tipos em Go, e às vezes você precisará converter entre eles\nnos seus templates. A forma mais fácil de identificar o tipo de um objeto é usar\n`printf \"%T\"` em um template, que exibirá o tipo. Veja também as funções `typeOf`\ne `kindOf`.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: Depurando Templates\ndescription: Solucionando problemas em charts que falham ao fazer deploy.\nsidebar_position: 13\n---\n\nDepurar templates pode ser complicado porque os templates renderizados são enviados\npara o servidor da API do Kubernetes, que pode rejeitar os arquivos YAML por razões\nalém de formatação.\n\nExistem alguns comandos que podem ajudar você a depurar.\n\n- `helm lint` é sua ferramenta principal para verificar se seu chart segue as\n  melhores práticas\n- `helm template --debug` testa a renderização dos templates do chart localmente.\n- `helm install --dry-run --debug` também renderiza seu chart localmente sem\ninstalá-lo, mas também verifica se recursos conflitantes já estão em execução\nno cluster. Configurar `--dry-run=server` também executará qualquer\n`lookup` no seu chart contra o servidor.\n- `helm get manifest`: Esta é uma boa maneira de ver quais templates estão instalados\n  no servidor.\n\nQuando seu YAML falha ao ser analisado, mas você quer ver o que é gerado, uma\nmaneira fácil de obter o YAML é comentar a seção problemática no template\ne então executar novamente `helm install --dry-run --debug`:\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\nO exemplo acima será renderizado e retornado com os comentários intactos:\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\nIsso fornece uma maneira rápida de visualizar o conteúdo gerado sem que erros de\nanálise YAML bloqueiem o processo.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: Lista de Funções de Template\ndescription: Uma lista de funções de template disponíveis no Helm\nsidebar_position: 6\n---\n\nO Helm inclui muitas funções de template que você pode utilizar em seus templates.\nElas estão listadas aqui e organizadas nas seguintes categorias:\n\n* [Criptográficas e de Segurança](#funções-criptográficas-e-de-segurança)\n* [Data](#funções-de-data)\n* [Dicionários](#funções-de-dicionário-e-dict)\n* [Codificação](#funções-de-codificação)\n* [Caminhos de Arquivo](#funções-de-caminho-de-arquivo)\n* [Kubernetes e Chart](#funções-de-kubernetes-e-chart)\n* [Lógica e Controle de Fluxo](#funções-de-lógica-e-controle-de-fluxo)\n* [Listas](#funções-de-lista-e-list)\n* [Matemática](#funções-matemáticas)\n* [Matemática com Float](#funções-matemáticas-com-float)\n* [Rede](#funções-de-rede)\n* [Reflexão](#funções-de-reflexão)\n* [Expressões Regulares](#expressões-regulares)\n* [Versões Semânticas](#funções-de-versão-semântica)\n* [String](#funções-de-string)\n* [Conversão de Tipos](#funções-de-conversão-de-tipos)\n* [URL](#funções-de-url)\n* [UUID](#funções-de-uuid)\n\n## Funções de Lógica e Controle de Fluxo\n\nO Helm inclui diversas funções de lógica e controle de fluxo, incluindo [and](#and),\n[coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq),\n[fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne),\n[not](#not), [or](#or) e [required](#required).\n\n### and\n\nRetorna o AND booleano de dois ou mais argumentos\n(o primeiro argumento vazio, ou o último argumento).\n\n```\nand .Arg1 .Arg2\n```\n\n### or\n\nRetorna o OR booleano de dois ou mais argumentos\n(o primeiro argumento não vazio, ou o último argumento).\n\n```\nor .Arg1 .Arg2\n```\n\n### not\n\nRetorna a negação booleana do seu argumento.\n\n```\nnot .Arg\n```\n\n### eq\n\nRetorna a igualdade booleana dos argumentos (ex.: Arg1 == Arg2).\n\n```\neq .Arg1 .Arg2\n```\n\n### ne\n\nRetorna a desigualdade booleana dos argumentos (ex.: Arg1 != Arg2)\n\n```\nne .Arg1 .Arg2\n```\n\n### lt\n\nRetorna verdadeiro se o primeiro argumento for menor que o segundo. Caso\ncontrário, retorna falso (ex.: Arg1 < Arg2).\n\n```\nlt .Arg1 .Arg2\n```\n\n### le\n\nRetorna verdadeiro se o primeiro argumento for menor ou igual ao segundo.\nCaso contrário, retorna falso (ex.: Arg1 <= Arg2).\n\n```\nle .Arg1 .Arg2\n```\n\n### gt\n\nRetorna verdadeiro se o primeiro argumento for maior que o segundo. Caso\ncontrário, retorna falso (ex.: Arg1 > Arg2).\n\n```\ngt .Arg1 .Arg2\n```\n\n### ge\n\nRetorna verdadeiro se o primeiro argumento for maior ou igual ao segundo.\nCaso contrário, retorna falso (ex.: Arg1 >= Arg2).\n\n```\nge .Arg1 .Arg2\n```\n\n### default\n\nPara definir um valor padrão simples, use `default`:\n\n```\ndefault \"foo\" .Bar\n```\n\nNo exemplo acima, se `.Bar` for avaliado como um valor não vazio, ele será\nusado. Mas se estiver vazio, `foo` será retornado em seu lugar.\n\nA definição de \"vazio\" depende do tipo:\n\n- Numérico: 0\n- String: \"\"\n- Listas: `[]`\n- Dicts: `{}`\n- Booleano: `false`\n- E sempre `nil` (também conhecido como null)\n\nPara structs, não há definição de vazio, então uma struct nunca retornará o\nvalor padrão.\n\n### required\n\nEspecifique valores que devem ser definidos com `required`:\n\n```\nrequired \"A valid foo is required!\" .Bar\n```\n\nSe `.Bar` estiver vazio ou não definido (veja [default](#default) para saber como isso é \navaliado), o template não será renderizado e retornará a mensagem de erro \nfornecida.\n\n### empty\n\nA função `empty` retorna `true` se o valor fornecido for considerado vazio, e\n`false` caso contrário. Os valores vazios estão listados na seção `default`.\n\n```\nempty .Foo\n```\n\nNote que em condicionais de templates Go, o vazio é calculado automaticamente.\nAssim, raramente você precisará usar `if not empty .Foo`. Em vez disso, use\napenas `if .Foo`.\n\n### fail\n\nRetorna incondicionalmente uma `string` vazia e um `error` com o texto\nespecificado. Isso é útil em cenários onde outras condicionais determinaram que\na renderização do template deve falhar.\n\n```\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\nA função `coalesce` recebe uma lista de valores e retorna o primeiro que não\nestiver vazio.\n\n```\ncoalesce 0 1 2\n```\n\nO exemplo acima retorna `1`.\n\nEsta função é útil para verificar múltiplas variáveis ou valores:\n\n```\ncoalesce .name .parent.name \"Matt\"\n```\n\nO exemplo acima primeiro verificará se `.name` está vazio. Se não estiver,\nretornará esse valor. Se _estiver_ vazio, `coalesce` avaliará `.parent.name`\npara verificar se está vazio. Finalmente, se tanto `.name` quanto `.parent.name`\nestiverem vazios, retornará `Matt`.\n\n### ternary\n\nA função `ternary` recebe dois valores e um valor de teste. Se o valor de teste\nfor verdadeiro, o primeiro valor será retornado. Se o valor de teste estiver\nvazio, o segundo valor será retornado. Isso é semelhante ao operador ternário em\nC e outras linguagens de programação.\n\n#### valor de teste verdadeiro\n\n```\nternary \"foo\" \"bar\" true\n```\n\nou\n\n```\ntrue | ternary \"foo\" \"bar\"\n```\n\nO exemplo acima retorna `\"foo\"`.\n\n#### valor de teste falso\n\n```\nternary \"foo\" \"bar\" false\n```\n\nou\n\n```\nfalse | ternary \"foo\" \"bar\"\n```\n\nO exemplo acima retorna `\"bar\"`.\n\n## Funções de String\n\nO Helm inclui as seguintes funções de string: [abbrev](#abbrev),\n[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat),\n[contains](#contains), [hasPrefix](#hasprefix-e-hassuffix),\n[hasSuffix](#hasprefix-e-hassuffix), [indent](#indent), [initials](#initials),\n[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent),\n[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf),\n[println](#println), [quote](#quote-e-squote),\n[randAlpha](#randalphanum-randalpha-randnumeric-e-randascii),\n[randAlphaNum](#randalphanum-randalpha-randnumeric-e-randascii),\n[randAscii](#randalphanum-randalpha-randnumeric-e-randascii),\n[randNumeric](#randalphanum-randalpha-randnumeric-e-randascii),\n[repeat](#repeat), [replace](#replace), [shuffle](#shuffle),\n[snakecase](#snakecase), [squote](#quote-e-squote), [substr](#substr),\n[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall),\n[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc),\n[untitle](#untitle), [upper](#upper), [wrap](#wrap) e [wrapWith](#wrapwith).\n\n### print\n\nRetorna uma string a partir da combinação de suas partes.\n\n```\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\nTipos que não são strings são convertidos para strings quando possível.\n\nNote que quando dois argumentos adjacentes não são strings, um espaço é\nadicionado entre eles.\n\n### println\n\nFunciona da mesma forma que [print](#print), mas adiciona uma nova linha no\nfinal.\n\n### printf\n\nRetorna uma string baseada em uma string de formatação e nos argumentos\npassados a ela em ordem.\n\n```\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\nO placeholder a ser usado depende do tipo do argumento que está sendo passado.\nIsso inclui:\n\nPropósito geral:\n\n* `%v` o valor em um formato padrão\n  * ao imprimir dicts, a flag plus (%+v) adiciona nomes de campos\n* `%%` um sinal de porcentagem literal; não consome nenhum valor\n\nBooleano:\n\n* `%t` a palavra true ou false\n\nInteiro:\n\n* `%b` base 2\n* `%c` o caractere representado pelo ponto de código Unicode correspondente\n* `%d` base 10\n* `%o` base 8\n* `%O` base 8 com prefixo 0o\n* `%q` um caractere literal entre aspas simples, escapado de forma segura\n* `%x` base 16, com letras minúsculas para a-f\n* `%X` base 16, com letras maiúsculas para A-F\n* `%U` formato Unicode: U+1234; mesmo que \"U+%04X\"\n\n Ponto flutuante e constituintes complexos:\n\n* `%b` notação científica decimal com expoente sendo potência de dois, ex.: -123456p-78\n* `%e` notação científica, ex.: -1.234456e+78\n* `%E` notação científica, ex.: -1.234456E+78\n* `%f` ponto decimal sem expoente, ex.: 123.456\n* `%F` sinônimo para %f\n* `%g` %e para expoentes grandes, %f caso contrário.\n* `%G` %E para expoentes grandes, %F caso contrário\n* `%x` notação hexadecimal (com expoente decimal de potência de dois), ex.: -0x1.23abcp+20\n* `%X` notação hexadecimal maiúscula, ex.: -0X1.23ABCP+20\n\nString e slice de bytes (tratados de forma equivalente com estes verbos):\n\n* `%s` os bytes não interpretados da string ou slice\n* `%q` uma string entre aspas duplas, escapada de forma segura\n* `%x` base 16, minúsculo, dois caracteres por byte\n* `%X` base 16, maiúsculo, dois caracteres por byte\n\nSlice:\n\n* `%p` endereço do elemento 0 em notação base 16, com 0x inicial\n\n### trim\n\nA função `trim` remove espaços em branco de ambos os lados de uma string:\n\n```\ntrim \"   hello    \"\n```\n\nO exemplo acima produz `hello`\n\n### trimAll\n\nRemove os caracteres especificados do início e do final de uma string:\n\n```\ntrimAll \"$\" \"$5.00\"\n```\n\nO exemplo acima retorna `5.00` (como uma string).\n\n### trimPrefix\n\nRemove apenas o prefixo de uma string:\n\n```\ntrimPrefix \"-\" \"-hello\"\n```\n\nO exemplo acima retorna `hello`\n\n### trimSuffix\n\nRemove apenas o sufixo de uma string:\n\n```\ntrimSuffix \"-\" \"hello-\"\n```\n\nO exemplo acima retorna `hello`\n\n### lower\n\nConverte toda a string para minúsculas:\n\n```\nlower \"HELLO\"\n```\n\nO exemplo acima retorna `hello`\n\n### upper\n\nConverte toda a string para maiúsculas:\n\n```\nupper \"hello\"\n```\n\nO exemplo acima retorna `HELLO`\n\n### title\n\nConverte para formato de título:\n\n```\ntitle \"hello world\"\n```\n\nO exemplo acima retorna `Hello World`\n\n### untitle\n\nRemove a formatação de título. `untitle \"Hello World\"` produz `hello world`.\n\n### repeat\n\nRepete uma string múltiplas vezes:\n\n```\nrepeat 3 \"hello\"\n```\n\nO exemplo acima retorna `hellohellohello`\n\n### substr\n\nObtém uma substring de uma string. Recebe três parâmetros:\n\n- start (int)\n- end (int)\n- string (string)\n\n```\nsubstr 0 5 \"hello world\"\n```\n\nO exemplo acima retorna `hello`\n\n### nospace\n\nRemove todos os espaços em branco de uma string.\n\n```\nnospace \"hello w o r l d\"\n```\n\nO exemplo acima retorna `helloworld`\n\n### trunc\n\nTrunca uma string\n\n```\ntrunc 5 \"hello world\"\n```\n\nO exemplo acima produz `hello`.\n\n```\ntrunc -5 \"hello world\"\n```\n\nO exemplo acima produz `world`.\n\n### abbrev\n\nTrunca uma string com reticências (`...`)\n\nParâmetros:\n\n- comprimento máximo\n- a string\n\n```\nabbrev 5 \"hello world\"\n```\n\nO exemplo acima retorna `he...`, pois conta a largura das reticências contra o\ncomprimento máximo.\n\n### abbrevboth\n\nAbrevia em ambos os lados:\n\n```\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\nO exemplo acima produz `...5678...`\n\nRecebe:\n\n- deslocamento à esquerda\n- comprimento máximo\n- a string\n\n### initials\n\nDadas múltiplas palavras, pega a primeira letra de cada palavra e as combina.\n\n```\ninitials \"First Try\"\n```\n\nO exemplo acima retorna `FT`\n\n### randAlphaNum, randAlpha, randNumeric e randAscii\n\nEstas quatro funções geram strings aleatórias criptograficamente seguras (usam\n```crypto/rand```), mas com diferentes conjuntos de caracteres base:\n\n- `randAlphaNum` usa `0-9a-zA-Z`\n- `randAlpha` usa `a-zA-Z`\n- `randNumeric` usa `0-9`\n- `randAscii` usa todos os caracteres ASCII imprimíveis\n\nCada uma delas recebe um parâmetro: o comprimento inteiro da string.\n\n```\nrandNumeric 3\n```\n\nO exemplo acima produzirá uma string aleatória com três dígitos.\n\n### wrap\n\nQuebra texto em uma contagem de colunas especificada:\n\n```\nwrap 80 $someText\n```\n\nO exemplo acima quebrará a string em `$someText` em 80 colunas.\n\n### wrapWith\n\n`wrapWith` funciona como `wrap`, mas permite especificar a string usada para\nquebrar. (`wrap` usa `\\n`)\n\n```\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\nO exemplo acima produz `Hello World` (onde o espaço em branco é um caractere de\ntabulação ASCII)\n\n### contains\n\nTesta se uma string está contida dentro de outra:\n\n```\ncontains \"cat\" \"catch\"\n```\n\nO exemplo acima retorna `true` porque `catch` contém `cat`.\n\n### hasPrefix e hasSuffix\n\nAs funções `hasPrefix` e `hasSuffix` testam se uma string tem um determinado\nprefixo ou sufixo:\n\n```\nhasPrefix \"cat\" \"catch\"\n```\n\nO exemplo acima retorna `true` porque `catch` tem o prefixo `cat`.\n\n### quote e squote\n\nEstas funções envolvem uma string em aspas duplas (`quote`) ou aspas simples\n(`squote`).\n\n### cat\n\nA função `cat` concatena múltiplas strings em uma, separando-as com espaços:\n\n```\ncat \"hello\" \"beautiful\" \"world\"\n```\n\nO exemplo acima produz `hello beautiful world`\n\n### indent\n\nA função `indent` indenta cada linha de uma string com a largura de indentação\nespecificada. Isso é útil ao alinhar strings de múltiplas linhas:\n\n```\nindent 4 $lots_of_text\n```\n\nO exemplo acima indentará cada linha de texto com 4 caracteres de espaço.\n\n### nindent\n\nA função `nindent` é igual à função indent, mas adiciona uma nova linha no\ninício da string.\n\n```\nnindent 4 $lots_of_text\n```\n\nO exemplo acima indentará cada linha de texto com 4 caracteres de espaço e\nadicionará uma nova linha no início.\n\n### replace\n\nRealiza substituição simples de string.\n\nRecebe três argumentos:\n\n- string a ser substituída\n- string de substituição\n- string fonte\n\n```\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\nO exemplo acima produzirá `I-Am-Henry-VIII`\n\n### plural\n\nPluraliza uma string.\n\n```\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\nNo exemplo acima, se o comprimento da string for 1, o primeiro argumento será\nimpresso (`one anchovy`). Caso contrário, o segundo argumento será impresso\n(`many anchovies`).\n\nOs argumentos são:\n\n- string singular\n- string plural\n- inteiro de comprimento\n\nNOTA: O Helm atualmente não suporta idiomas com regras de pluralização mais\ncomplexas. E `0` é considerado plural porque o idioma inglês o trata assim\n(`zero anchovies`).\n\n### snakecase\n\nConverte string de camelCase para snake_case.\n\n```\nsnakecase \"FirstName\"\n```\n\nO exemplo acima produzirá `first_name`.\n\n### camelcase\n\nConverte string de snake_case para CamelCase\n\n```\ncamelcase \"http_server\"\n```\n\nO exemplo acima produzirá `HttpServer`.\n\n### kebabcase\n\nConverte string de camelCase para kebab-case.\n\n```\nkebabcase \"FirstName\"\n```\n\nO exemplo acima produzirá `first-name`.\n\n### swapcase\n\nTroca o caso de uma string usando um algoritmo baseado em palavras.\n\nAlgoritmo de conversão:\n\n- Caractere maiúsculo converte para minúsculo\n- Caractere de título converte para minúsculo\n- Caractere minúsculo após espaço em branco ou no início converte para título\n- Outro caractere minúsculo converte para maiúsculo\n- Espaço em branco é definido por unicode.IsSpace(char)\n\n```\nswapcase \"This Is A.Test\"\n```\n\nO exemplo acima produzirá `tHIS iS a.tEST`.\n\n### shuffle\n\nEmbaralha uma string.\n\n```\nshuffle \"hello\"\n```\n\nO exemplo acima randomizará as letras em `hello`, possivelmente produzindo\n`oelhl`.\n\n## Funções de Conversão de Tipos\n\nAs seguintes funções de conversão de tipos são fornecidas pelo Helm:\n\n- `atoi`: Converte uma string para um inteiro.\n- `float64`: Converte para um `float64`.\n- `int`: Converte para um `int` com a largura do sistema.\n- `int64`: Converte para um `int64`.\n- `toDecimal`: Converte um octal unix para um `int64`.\n- `toString`: Converte para uma string.\n- `toStrings`: Converte uma list, slice ou array para uma lista de strings.\n- `toJson` (`mustToJson`): Converte list, slice, array, dict ou objeto para JSON.\n- `toPrettyJson` (`mustToPrettyJson`): Converte list, slice, array, dict ou\n  objeto para JSON indentado.\n- `toRawJson` (`mustToRawJson`): Converte list, slice, array, dict ou objeto\n  para JSON com caracteres HTML não escapados.\n- `fromYaml`: Converte uma string YAML para um objeto.\n- `fromJson`: Converte uma string JSON para um objeto.\n- `fromJsonArray`: Converte um array JSON para uma lista.\n- `toYaml`: Converte list, slice, array, dict ou objeto para yaml indentado,\n  pode ser usado para copiar trechos de yaml de qualquer fonte. Esta função é\n  equivalente à função GoLang yaml.Marshal, veja a documentação aqui:\n  https://pkg.go.dev/gopkg.in/yaml.v2#Marshal\n- `toYamlPretty`: Converte list, slice, array, dict ou objeto para yaml\n  indentado. Equivalente a `toYaml`, mas adicionalmente indenta listas em 2\n  espaços.\n- `toToml`: Converte list, slice, array, dict ou objeto para toml, pode ser\n  usado para copiar trechos de toml de qualquer fonte.\n- `fromYamlArray`: Converte um array YAML para uma lista.\n\nApenas `atoi` requer que a entrada seja de um tipo específico. As outras\ntentarão converter de qualquer tipo para o tipo de destino. Por exemplo, `int64`\npode converter floats para ints, e também pode converter strings para ints.\n\n### toStrings\n\nDada uma coleção similar a lista, produz uma slice de strings.\n\n```\nlist 1 2 3 | toStrings\n```\n\nO exemplo acima converte `1` para `\"1\"`, `2` para `\"2\"`, e assim por diante, e\nentão os retorna como uma lista.\n\n### toDecimal\n\nDada uma permissão octal unix, produz um decimal.\n\n```\n\"0777\" | toDecimal\n```\n\nO exemplo acima converte `0777` para `511` e retorna o valor como um int64.\n\n### toJson, mustToJson\n\nA função `toJson` codifica um item em uma string JSON. Se o item não puder ser\nconvertido para JSON, a função retornará uma string vazia. `mustToJson`\nretornará um erro caso o item não possa ser codificado em JSON.\n\n```\ntoJson .Item\n```\n\nO exemplo acima retorna a representação em string JSON de `.Item`.\n\n### toPrettyJson, mustToPrettyJson\n\nA função `toPrettyJson` codifica um item em uma string JSON formatada\n(indentada).\n\n```\ntoPrettyJson .Item\n```\n\nO exemplo acima retorna a representação indentada em string JSON de `.Item`.\n\n### toRawJson, mustToRawJson\n\nA função `toRawJson` codifica um item em uma string JSON com caracteres HTML não\nescapados.\n\n```\ntoRawJson .Item\n```\n\nO exemplo acima retorna a representação em string JSON não escapada de `.Item`.\n\n### fromYaml\n\nA função `fromYaml` recebe uma string YAML e retorna um objeto que pode ser\nusado em templates.\n\n`Arquivo em: yamls/person.yaml`\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n```yaml\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\nA função `fromJson` recebe uma string JSON e retorna um objeto que pode ser\nusado em templates.\n\n`Arquivo em: jsons/person.json`\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n\n### fromJsonArray\n\nA função `fromJsonArray` recebe um Array JSON e retorna uma lista que pode ser\nusada em templates.\n\n`Arquivo em: jsons/people.json`\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml, toYamlPretty\n\nAs funções `toYaml` e `toYamlPretty` codificam um objeto (list, slice, array,\ndict ou objeto) em uma string YAML indentada.\n\n> Note que `toYamlPretty` é funcionalmente equivalente, mas produzirá YAML com\n> indentação adicional para elementos de lista\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\nA função `fromYamlArray` recebe um Array YAML e retorna uma lista que pode ser\nusada em templates.\n\n`Arquivo em: yamls/people.yml`\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n\n## Expressões Regulares\n\nO Helm inclui as seguintes funções de expressões regulares: [regexFind\n(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll\n(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch\n(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll\n(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall),\n[regexReplaceAllLiteral\n(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral),\n[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\nRetorna true se a string de entrada contiver qualquer correspondência da\nexpressão regular.\n\n```\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\nO exemplo acima produz `true`\n\n`regexMatch` causa panic se houver um problema e `mustRegexMatch` retorna um\nerro para o motor de templates se houver um problema.\n\n### regexFindAll, mustRegexFindAll\n\nRetorna uma slice de todas as correspondências da expressão regular na string de\nentrada. O último parâmetro n determina o número de substrings a retornar, onde\n-1 significa retornar todas as correspondências\n\n```\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\nO exemplo acima produz `[2 4 6 8]`\n\n`regexFindAll` causa panic se houver um problema e `mustRegexFindAll` retorna\num erro para o motor de templates se houver um problema.\n\n### regexFind, mustRegexFind\n\nRetorna a primeira (mais à esquerda) correspondência da expressão regular na\nstring de entrada\n\n```\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\nO exemplo acima produz `d1`\n\n`regexFind` causa panic se houver um problema e `mustRegexFind` retorna um erro\npara o motor de templates se houver um problema.\n\n### regexReplaceAll, mustRegexReplaceAll\n\nRetorna uma cópia da string de entrada, substituindo correspondências da Regexp\npela string de substituição. Dentro da string de substituição, sinais $ são\ninterpretados como em Expand, então, por exemplo, $1 representa o texto da\nprimeira subcorrespondência. O primeiro argumento é `<pattern>`, o segundo é\n`<input>`, e o terceiro é `<replacement>`.\n\n```\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\nO exemplo acima produz `-W-xxW-`\n\n`regexReplaceAll` causa panic se houver um problema e `mustRegexReplaceAll`\nretorna um erro para o motor de templates se houver um problema.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\nRetorna uma cópia da string de entrada, substituindo correspondências da Regexp\npela string de substituição. A string de substituição é substituída diretamente,\nsem usar Expand. O primeiro argumento é `<pattern>`, o segundo é `<input>`, e o\nterceiro é `<replacement>`.\n\n```\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\nO exemplo acima produz `-${1}-${1}-`\n\n`regexReplaceAllLiteral` causa panic se houver um problema e\n`mustRegexReplaceAllLiteral` retorna um erro para o motor de templates se houver\num problema.\n\n### regexSplit, mustRegexSplit\n\nDivide a string de entrada em substrings separadas pela expressão e retorna uma\nslice das substrings entre essas correspondências da expressão. O último\nparâmetro `n` determina o número de substrings a retornar, onde `-1` significa\nretornar todas as correspondências\n\n```\nregexSplit \"z+\" \"pizza\" -1\n```\n\nO exemplo acima produz `[pi a]`\n\n`regexSplit` causa panic se houver um problema e `mustRegexSplit` retorna um\nerro para o motor de templates se houver um problema.\n\n## Funções Criptográficas e de Segurança\n\nO Helm fornece algumas funções criptográficas avançadas. Elas incluem\n[adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert),\n[decryptAES](#decryptaes), [derivePassword](#derivepassword),\n[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey),\n[genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert),\n[htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum) e\n[sha256sum](#sha256sum).\n\n### sha1sum\n\nA função `sha1sum` recebe uma string e calcula seu digest SHA1.\n\n```\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\nA função `sha256sum` recebe uma string e calcula seu digest SHA256.\n\n```\nsha256sum \"Hello world!\"\n```\n\nO exemplo acima calculará a soma SHA 256 em um formato \"ASCII armored\" que é\nseguro para imprimir.\n\n### adler32sum\n\nA função `adler32sum` recebe uma string e calcula seu checksum Adler-32.\n\n```\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\nA função `htpasswd` recebe um `username` e `password` e gera um hash `bcrypt` da\nsenha. O resultado pode ser usado para autenticação básica em um [Servidor HTTP\nApache](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic).\n\n```\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nNote que é inseguro armazenar a senha diretamente no template.\n\n### randBytes\n\nA função randBytes aceita um número N e gera uma sequência aleatória\ncriptograficamente segura (usa crypto/rand) de N bytes. A sequência é retornada\ncomo uma string codificada em base64.\n\n```\nrandBytes 24\n```\n\n### derivePassword\n\nA função `derivePassword` pode ser usada para derivar uma senha específica\nbaseada em algumas restrições de \"senha mestre\" compartilhadas. O algoritmo para\nisso é [bem\nespecificado](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf).\n\n```\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nNote que é considerado inseguro armazenar as partes diretamente no template.\n\n### genPrivateKey\n\nA função `genPrivateKey` gera uma nova chave privada codificada em um bloco PEM.\n\nEla aceita um dos seguintes valores para seu primeiro parâmetro:\n\n- `ecdsa`: Gera uma chave DSA de curva elíptica (P256)\n- `dsa`: Gera uma chave DSA (L2048N256)\n- `rsa`: Gera uma chave RSA 4096\n\n### buildCustomCert\n\nA função `buildCustomCert` permite personalizar o certificado.\n\nEla recebe os seguintes parâmetros string:\n\n- Um certificado em formato PEM codificado em base64\n- Uma chave privada em formato PEM codificada em base64\n\nRetorna um objeto de certificado com os seguintes atributos:\n\n- `Cert`: Um certificado codificado em PEM\n- `Key`: Uma chave privada codificada em PEM\n\nExemplo:\n\n```\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\nNote que o objeto retornado pode ser passado para a função `genSignedCert` para\nassinar um certificado usando esta CA.\n\n### genCA\n\nA função `genCA` gera uma nova autoridade certificadora x509 autoassinada.\n\nEla recebe os seguintes parâmetros:\n\n- Nome comum do sujeito (cn)\n- Duração da validade do certificado em dias\n\nRetorna um objeto com os seguintes atributos:\n\n- `Cert`: Um certificado codificado em PEM\n- `Key`: Uma chave privada codificada em PEM\n\nExemplo:\n\n```\n$ca := genCA \"foo-ca\" 365\n```\n\nNote que o objeto retornado pode ser passado para a função `genSignedCert` para\nassinar um certificado usando esta CA.\n\n### genSelfSignedCert\n\nA função `genSelfSignedCert` gera um novo certificado x509 autoassinado.\n\nEla recebe os seguintes parâmetros:\n\n- Nome comum do sujeito (cn)\n- Lista opcional de IPs; pode ser nil\n- Lista opcional de nomes DNS alternativos; pode ser nil\n- Duração da validade do certificado em dias\n\nRetorna um objeto com os seguintes atributos:\n\n- `Cert`: Um certificado codificado em PEM\n- `Key`: Uma chave privada codificada em PEM\n\nExemplo:\n\n```\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\nA função `genSignedCert` gera um novo certificado x509 assinado pela CA\nespecificada.\n\nEla recebe os seguintes parâmetros:\n\n- Nome comum do sujeito (cn)\n- Lista opcional de IPs; pode ser nil\n- Lista opcional de nomes DNS alternativos; pode ser nil\n- Duração da validade do certificado em dias\n- CA (veja `genCA`)\n\nExemplo:\n\n```\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\nA função `encryptAES` criptografa texto com AES-256 CBC e retorna uma string\ncodificada em base64.\n\n```\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\nA função `decryptAES` recebe uma string base64 codificada pelo algoritmo AES-256\nCBC e retorna o texto decodificado.\n\n```\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Funções de Data\n\nO Helm inclui as seguintes funções de data que você pode usar em templates:\n[ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify\n(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration),\n[durationRound](#durationround), [htmlDate](#htmldate),\n[htmlDateInZone](#htmldateinzone), [now](#now), [toDate\n(mustToDate)](#todate-musttodate) e [unixEpoch](#unixepoch).\n\n### now\n\nA data/hora atual. Use isso em conjunto com outras funções de data.\n\n### ago\n\nA função `ago` retorna a duração desde o momento. Agora em resolução de segundos.\n\n```\nago .CreatedAt\n```\n\nretorna no formato String() de `time.Duration`\n\n```\n2h34m7s\n```\n\n### date\n\nA função `date` formata uma data.\n\nFormata a data para ANO-MÊS-DIA:\n\n```\nnow | date \"2006-01-02\"\n```\n\nA formatação de datas em Go é [um pouco\ndiferente](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\nEm resumo, use isso como a data base:\n\n```\nMon Jan 2 15:04:05 MST 2006\n```\n\nEscreva-a no formato que você deseja. Acima, `2006-01-02` é a mesma data, mas no\nformato que queremos.\n\n### dateInZone\n\nIgual a `date`, mas com um fuso horário.\n\n```\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\nFormata uma quantidade de segundos como um `time.Duration`.\n\nIsso retorna 1m35s\n\n```\nduration \"95\"\n```\n\n### durationRound\n\nArredonda uma duração para a unidade mais significativa. Strings e\n`time.Duration` são analisados como uma duração, enquanto um `time.Time` é\ncalculado como a duração desde então.\n\nIsso retorna 2h\n\n```\ndurationRound \"2h10m5s\"\n```\n\nIsso retorna 3mo\n\n```\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\nRetorna os segundos desde a época unix para um `time.Time`.\n\n```\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\nO `dateModify` recebe uma modificação e uma data e retorna o timestamp.\n\nSubtrai uma hora e trinta minutos do horário atual:\n\n```\nnow | dateModify \"-1.5h\"\n```\n\nSe o formato de modificação estiver errado, `dateModify` retornará a data sem\nmodificação. `mustDateModify` retornará um erro caso contrário.\n\n### htmlDate\n\nA função `htmlDate` formata uma data para inserir em um campo de entrada de\nseleção de data HTML.\n\n```\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nIgual a htmlDate, mas com um fuso horário.\n\n```\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\n`toDate` converte uma string para uma data. O primeiro argumento é o layout da\ndata e o segundo é a string da data. Se a string não puder ser convertida,\nretorna o valor zero. `mustToDate` retornará um erro caso a string não possa ser\nconvertida.\n\nIsso é útil quando você quer converter uma data em string para outro formato\n(usando pipe). O exemplo abaixo converte \"2017-12-31\" para \"31/12/2017\".\n\n```\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Funções de Dicionário e Dict\n\nO Helm fornece um tipo de armazenamento chave/valor chamado `dict` (abreviação\nde \"dictionary\", como em Python). Um `dict` é um tipo _não ordenado_.\n\nA chave de um dicionário **deve ser uma string**. No entanto, o valor pode ser\nde qualquer tipo, incluindo outro `dict` ou `list`.\n\nDiferente de `list`s, `dict`s não são imutáveis. As funções `set` e `unset`\nmodificarão o conteúdo de um dicionário.\n\nO Helm fornece as seguintes funções para trabalhar com dicts: [deepCopy\n(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get),\n[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge),\n[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite),\n[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) e\n[values](#values).\n\n### dict\n\nCriar dicionários é feito chamando a função `dict` e passando uma lista de\npares.\n\nO seguinte cria um dicionário com três itens:\n\n```\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nDado um map e uma chave, obtém o valor do map.\n\n```\nget $myDict \"name1\"\n```\n\nO exemplo acima retorna `\"value1\"`\n\nNote que se a chave não for encontrada, esta operação simplesmente retornará\n`\"\"`. Nenhum erro será gerado.\n\n### set\n\nUse `set` para adicionar um novo par chave/valor a um dicionário.\n\n```\n$_ := set $myDict \"name4\" \"value4\"\n```\n\nNote que `set` _retorna o dicionário_ (um requisito das funções de template Go),\nentão você pode precisar capturar o valor como feito acima com a atribuição\n`$_`.\n\n### unset\n\nDado um map e uma chave, remove a chave do map.\n\n```\n$_ := unset $myDict \"name4\"\n```\n\nAssim como `set`, isso retorna o dicionário.\n\nNote que se a chave não for encontrada, esta operação simplesmente retornará.\nNenhum erro será gerado.\n\n### hasKey\n\nA função `hasKey` retorna `true` se o dict fornecido contiver a chave\nespecificada.\n\n```\nhasKey $myDict \"name1\"\n```\n\nSe a chave não for encontrada, retorna `false`.\n\n### pluck\n\nA função `pluck` permite fornecer uma chave e múltiplos maps, e obter uma lista\nde todas as correspondências:\n\n```\npluck \"name1\" $myDict $myOtherDict\n```\n\nO exemplo acima retornará uma `list` contendo cada valor encontrado (`[value1\notherValue1]`).\n\nSe a chave _não for encontrada_ em um map, esse map não terá um item na lista (e\no comprimento da lista retornada será menor que o número de dicts na chamada de\n`pluck`).\n\nSe a chave _for encontrada_ mas o valor estiver vazio, esse valor será inserido.\n\nUm idioma comum em templates Helm é usar `pluck... | first` para obter a\nprimeira chave correspondente de uma coleção de dicionários.\n\n### dig\n\nA função `dig` percorre um conjunto aninhado de dicts, selecionando chaves de\numa lista de valores. Ela retorna um valor padrão se alguma das chaves não for\nencontrada no dict associado.\n\n```\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\nDado um dict estruturado como\n```\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\no exemplo acima retornaria `\"curator\"`. Se o dict não tivesse nem um campo\n`user`, o resultado seria `\"guest\"`.\n\nDig pode ser muito útil em casos onde você gostaria de evitar cláusulas de\nguarda, especialmente porque o `and` do pacote de templates Go não faz\ncurto-circuito. Por exemplo, `and a.maybeNil a.maybeNil.iNeedThis` sempre\navaliará `a.maybeNil.iNeedThis`, e causará panic se `a` não tiver um campo\n`maybeNil`.)\n\n`dig` aceita seu argumento dict por último para suportar pipelining. Por\nexemplo:\n```\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\nMescla dois ou mais dicionários em um, dando precedência ao dicionário de\ndestino:\n\nDado:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nresultará em:\n\n```\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n```\n$newdict := merge $dest $source1 $source2\n```\n\nEsta é uma operação de mesclagem profunda, mas não uma operação de cópia\nprofunda. Objetos aninhados que são mesclados são a mesma instância em ambos os\ndicts. Se você quiser uma cópia profunda junto com a mesclagem, use a função\n`deepCopy` junto com a mesclagem. Por exemplo,\n\n```\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` retornará um erro em caso de mesclagem malsucedida.\n\n### mergeOverwrite, mustMergeOverwrite\n\nMescla dois ou mais dicionários em um, dando precedência **da direita para a\nesquerda**, efetivamente sobrescrevendo valores no dicionário de destino:\n\nDado:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nresultará em:\n\n```\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nEsta é uma operação de mesclagem profunda, mas não uma operação de cópia\nprofunda. Objetos aninhados que são mesclados são a mesma instância em ambos os\ndicts. Se você quiser uma cópia profunda junto com a mesclagem, use a função\n`deepCopy` junto com a mesclagem. Por exemplo,\n\n```\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` retornará um erro em caso de mesclagem malsucedida.\n\n### keys\n\nA função `keys` retornará uma `list` de todas as chaves em um ou mais tipos\n`dict`. Como um dicionário é _não ordenado_, as chaves não estarão em uma ordem\nprevisível. Elas podem ser ordenadas com `sortAlpha`.\n\n```\nkeys $myDict | sortAlpha\n```\n\nAo fornecer múltiplos dicionários, as chaves serão concatenadas. Use a função\n`uniq` junto com `sortAlpha` para obter uma lista única e ordenada de chaves.\n\n```\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\nA função `pick` seleciona apenas as chaves especificadas de um dicionário,\ncriando um novo `dict`.\n\n```\n$new := pick $myDict \"name1\" \"name2\"\n```\n\nO exemplo acima retorna `{name1: value1, name2: value2}`\n\n### omit\n\nA função `omit` é similar a `pick`, exceto que retorna um novo `dict` com todas\nas chaves que _não_ correspondem às chaves especificadas.\n\n```\n$new := omit $myDict \"name1\" \"name3\"\n```\n\nO exemplo acima retorna `{name2: value2}`\n\n### values\n\nA função `values` é similar a `keys`, exceto que retorna uma nova `list` com\ntodos os valores do `dict` de origem (apenas um dicionário é suportado).\n\n```\n$vals := values $myDict\n```\n\nO exemplo acima retorna `list[\"value1\", \"value2\", \"value 3\"]`. Note que a função\n`values` não dá garantias sobre a ordenação do resultado; se você se importa com\nisso, use `sortAlpha`.\n\n### deepCopy, mustDeepCopy\n\nAs funções `deepCopy` e `mustDeepCopy` recebem um valor e fazem uma cópia\nprofunda dele. Isso inclui dicts e outras estruturas. `deepCopy` causa panic\nquando há um problema, enquanto `mustDeepCopy` retorna um erro para o sistema de\ntemplates quando há um erro.\n\n```\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### Uma Nota sobre Internos de Dict\n\nUm `dict` é implementado em Go como um `map[string]interface{}`. Desenvolvedores\nGo podem passar valores `map[string]interface{}` para o contexto para\ndisponibilizá-los para templates como `dict`s.\n\n## Funções de Codificação\n\nO Helm tem as seguintes funções de codificação e decodificação:\n\n- `b64enc`/`b64dec`: Codifica ou decodifica com Base64\n- `b32enc`/`b32dec`: Codifica ou decodifica com Base32\n\n## Funções de Lista e List\n\nO Helm fornece um tipo simples `list` que pode conter listas sequenciais\narbitrárias de dados. Isso é similar a arrays ou slices, mas listas são\nprojetadas para serem usadas como tipos de dados imutáveis.\n\nCrie uma lista de inteiros:\n\n```\n$myList := list 1 2 3 4 5\n```\n\nO exemplo acima cria uma lista `[1 2 3 4 5]`.\n\nO Helm fornece as seguintes funções de lista: [append\n(mustAppend)](#append-mustappend), [chunk](#chunk), [compact\n(mustCompact)](#compact-mustcompact), [concat](#concat), [first\n(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial\n(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast),\n[prepend (mustPrepend)](#prepend-mustprepend), [rest\n(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse),\n[seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq\n(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) e\n[without (mustWithout)](#without-mustwithout).\n\n### first, mustFirst\n\nPara obter o primeiro item de uma lista, use `first`.\n\n`first $myList` retorna `1`\n\n`first` causa panic se houver um problema, enquanto `mustFirst` retorna um erro\npara o motor de templates se houver um problema.\n\n### rest, mustRest\n\nPara obter a cauda da lista (tudo exceto o primeiro item), use `rest`.\n\n`rest $myList` retorna `[2 3 4 5]`\n\n`rest` causa panic se houver um problema, enquanto `mustRest` retorna um erro\npara o motor de templates se houver um problema.\n\n### last, mustLast\n\nPara obter o último item de uma lista, use `last`:\n\n`last $myList` retorna `5`. Isso é aproximadamente análogo a inverter uma lista\ne então chamar `first`.\n\n### initial, mustInitial\n\nIsso complementa `last` retornando todos os elementos _exceto_ o último.\n`initial $myList` retorna `[1 2 3 4]`.\n\n`initial` causa panic se houver um problema, enquanto `mustInitial` retorna um\nerro para o motor de templates se houver um problema.\n\n### append, mustAppend\n\nAdiciona um novo item a uma lista existente, criando uma nova lista.\n\n```\n$new = append $myList 6\n```\n\nO exemplo acima definiria `$new` como `[1 2 3 4 5 6]`. `$myList` permaneceria\ninalterada.\n\n`append` causa panic se houver um problema, enquanto `mustAppend` retorna um\nerro para o motor de templates se houver um problema.\n\n### prepend, mustPrepend\n\nAdiciona um elemento no início de uma lista, criando uma nova lista.\n\n```\nprepend $myList 0\n```\n\nO exemplo acima produziria `[0 1 2 3 4 5]`. `$myList` permaneceria inalterada.\n\n`prepend` causa panic se houver um problema, enquanto `mustPrepend` retorna um\nerro para o motor de templates se houver um problema.\n\n### concat\n\nConcatena um número arbitrário de listas em uma.\n\n```\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\nO exemplo acima produziria `[1 2 3 4 5 6 7 8]`. `$myList` permaneceria\ninalterada.\n\n### reverse, mustReverse\n\nProduz uma nova lista com os elementos invertidos da lista fornecida.\n\n```\nreverse $myList\n```\n\nO exemplo acima geraria a lista `[5 4 3 2 1]`.\n\n`reverse` causa panic se houver um problema, enquanto `mustReverse` retorna um\nerro para o motor de templates se houver um problema.\n\n### uniq, mustUniq\n\nGera uma lista com todas as duplicatas removidas.\n\n```\nlist 1 1 1 2 | uniq\n```\n\nO exemplo acima produziria `[1 2]`\n\n`uniq` causa panic se houver um problema, enquanto `mustUniq` retorna um erro\npara o motor de templates se houver um problema.\n\n### without, mustWithout\n\nA função `without` filtra itens de uma lista.\n\n```\nwithout $myList 3\n```\n\nO exemplo acima produziria `[1 2 4 5]`\n\n`without` pode receber mais de um filtro:\n\n```\nwithout $myList 1 3 5\n```\n\nIsso produziria `[2 4]`\n\n`without` causa panic se houver um problema, enquanto `mustWithout` retorna um\nerro para o motor de templates se houver um problema.\n\n### has, mustHas\n\nTesta se uma lista contém um determinado elemento.\n\n```\nhas 4 $myList\n```\n\nO exemplo acima retornaria `true`, enquanto `has \"hello\" $myList` retornaria\nfalse.\n\n`has` causa panic se houver um problema, enquanto `mustHas` retorna um erro para\no motor de templates se houver um problema.\n\n### compact, mustCompact\n\nAceita uma lista e remove entradas com valores vazios.\n\n```\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` retornará uma nova lista com o item vazio (ou seja, \"\") removido.\n\n`compact` causa panic se houver um problema e `mustCompact` retorna um erro para\no motor de templates se houver um problema.\n\n### index\n\nPara obter o n-ésimo elemento de uma lista, use `index list [n]`. Para indexar\nem listas multidimensionais, use `index list [n] [m] ...`\n- `index $myList 0` retorna `1`. É o mesmo que `myList[0]`\n- `index $myList 0 1` seria o mesmo que `myList[0][1]`\n\n### slice, mustSlice\n\nPara obter elementos parciais de uma lista, use `slice list [n] [m]`. É\nequivalente a `list[n:m]`.\n\n- `slice $myList` retorna `[1 2 3 4 5]`. É o mesmo que `myList[:]`.\n- `slice $myList 3` retorna `[4 5]`. É o mesmo que `myList[3:]`.\n- `slice $myList 1 3` retorna `[2 3]`. É o mesmo que `myList[1:3]`.\n- `slice $myList 0 3` retorna `[1 2 3]`. É o mesmo que `myList[:3]`.\n\n`slice` causa panic se houver um problema, enquanto `mustSlice` retorna um erro\npara o motor de templates se houver um problema.\n\n### until\n\nA função `until` constrói um intervalo de inteiros.\n\n```\nuntil 5\n```\n\nO exemplo acima gera a lista `[0, 1, 2, 3, 4]`.\n\nIsso é útil para fazer loop com `range $i, $e := until 5`.\n\n### untilStep\n\nComo `until`, `untilStep` gera uma lista de inteiros contados. Mas permite\ndefinir um início, fim e passo:\n\n```\nuntilStep 3 6 2\n```\n\nO exemplo acima produzirá `[3 5]` começando com 3 e adicionando 2 até que seja\nigual ou maior que 6. Isso é similar à função `range` do Python.\n\n### seq\n\nFunciona como o comando `seq` do bash.\n\n* 1 parâmetro (end) - gerará todos os inteiros contados entre 1 e `end`\n  inclusive.\n* 2 parâmetros (start, end) - gerará todos os inteiros contados entre `start` e\n  `end` inclusive, incrementando ou decrementando por 1.\n* 3 parâmetros (start, step, end) - gerará todos os inteiros contados entre\n  `start` e `end` inclusive, incrementando ou decrementando por `step`.\n\n```\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\nPara dividir uma lista em pedaços de tamanho especificado, use `chunk size\nlist`. Isso é útil para paginação.\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\nIsso produz uma lista de listas `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`.\n\n## Funções Matemáticas\n\nTodas as funções matemáticas operam em valores `int64`, a menos que especificado\nde outra forma.\n\nAs seguintes funções matemáticas estão disponíveis: [add](#add), [add1](#add1),\n[ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max),\n[min](#min), [mod](#mod), [mul](#mul), [round](#round) e [sub](#sub).\n\n### add\n\nSoma números com `add`. Aceita duas ou mais entradas.\n\n```\nadd 1 2 3\n```\n\n### add1\n\nPara incrementar por 1, use `add1`.\n\n### sub\n\nPara subtrair, use `sub`.\n\n### div\n\nRealiza divisão inteira com `div`.\n\n### mod\n\nMódulo com `mod`.\n\n### mul\n\nMultiplica com `mul`. Aceita duas ou mais entradas.\n\n```\nmul 1 2 3\n```\n\n### max\n\nRetorna o maior de uma série de inteiros.\n\nIsso retornará `3`:\n\n```\nmax 1 2 3\n```\n\n### min\n\nRetorna o menor de uma série de inteiros.\n\n`min 1 2 3` retornará `1`.\n\n### len\n\nRetorna o comprimento do argumento como um inteiro.\n\n```\nlen .Arg\n```\n\n## Funções Matemáticas com Float\n\nTodas as funções matemáticas operam em valores `float64`.\n\n### addf\n\nSoma números com `addf`\n\nIsso retornará `5.5`:\n\n```\naddf 1.5 2 2\n```\n\n### add1f\n\nPara incrementar por 1, use `add1f`\n\n### subf\n\nPara subtrair, use `subf`\n\nIsso é equivalente a `7.5 - 2 - 3` e retornará `2.5`:\n\n```\nsubf 7.5 2 3\n```\n\n### divf\n\nRealiza divisão inteira com `divf`\n\nIsso é equivalente a `10 / 2 / 4` e retornará `1.25`:\n\n```\ndivf 10 2 4\n```\n\n### mulf\n\nMultiplica com `mulf`\n\nIsso retornará `6`:\n\n```\nmulf 1.5 2 2\n```\n\n### maxf\n\nRetorna o maior de uma série de floats:\n\nIsso retornará `3`:\n\n```\nmaxf 1 2.5 3\n```\n\n### minf\n\nRetorna o menor de uma série de floats.\n\nIsso retornará `1.5`:\n\n```\nminf 1.5 2 3\n```\n\n### floor\n\nRetorna o maior valor float menor ou igual ao valor de entrada.\n\n`floor 123.9999` retornará `123.0`.\n\n### ceil\n\nRetorna o maior valor float maior ou igual ao valor de entrada.\n\n`ceil 123.001` retornará `124.0`.\n\n### round\n\nRetorna um valor float com o resto arredondado para o número de dígitos\nespecificado após o ponto decimal.\n\n`round 123.555555 3` retornará `123.556`.\n\n## Funções de Rede\n\nO Helm tem uma única função de rede, `getHostByName`.\n\nO `getHostByName` recebe um nome de domínio e retorna o endereço IP.\n\n`getHostByName \"www.google.com\"` retornaria o endereço IP correspondente de\n`www.google.com`.\n\nEsta função requer que a opção `--enable-dns` seja passada na linha de comando\ndo helm.\n\n## Funções de Caminho de Arquivo\n\nEmbora as funções de template do Helm não concedam acesso ao sistema de\narquivos, elas fornecem funções para trabalhar com strings que seguem convenções\nde caminhos de arquivo. Essas incluem [base](#base), [clean](#clean),\n[dir](#dir), [ext](#ext) e [isAbs](#isabs).\n\n### base\n\nRetorna o último elemento de um caminho.\n\n```\nbase \"foo/bar/baz\"\n```\n\nO exemplo acima imprime \"baz\".\n\n### dir\n\nRetorna o diretório, removendo a última parte do caminho. Então `dir\n\"foo/bar/baz\"` retorna `foo/bar`.\n\n### clean\n\nLimpa um caminho.\n\n```\nclean \"foo/bar/../baz\"\n```\n\nO exemplo acima resolve o `..` e retorna `foo/baz`.\n\n### ext\n\nRetorna a extensão do arquivo.\n\n```\next \"foo.bar\"\n```\n\nO exemplo acima retorna `.bar`.\n\n### isAbs\n\nPara verificar se um caminho de arquivo é absoluto, use `isAbs`.\n\n## Funções de Reflexão\n\nO Helm fornece ferramentas rudimentares de reflexão. Estas ajudam\ndesenvolvedores de templates avançados a entender as informações de tipo Go\nsubjacentes para um determinado valor. O Helm é escrito em Go e é fortemente\ntipado. O sistema de tipos se aplica dentro de templates.\n\nGo tem vários _kinds_ primitivos, como `string`, `slice`, `int64` e `bool`.\n\nGo tem um sistema de _tipos_ aberto que permite desenvolvedores criar seus\npróprios tipos.\n\nO Helm fornece um conjunto de funções para cada através de [funções\nkind](#funções-kind) e [funções type](#funções-type). Uma função\n[deepEqual](#deepequal) também é fornecida para comparar dois valores.\n\n### Funções Kind\n\nExistem duas funções Kind: `kindOf` retorna o kind de um objeto.\n\n```\nkindOf \"hello\"\n```\n\nO exemplo acima retornaria `string`. Para testes simples (como em blocos `if`),\na função `kindIs` permitirá verificar se um valor é de um kind específico:\n\n```\nkindIs \"int\" 123\n```\n\nO exemplo acima retornará `true`.\n\n### Funções Type\n\nTipos são um pouco mais difíceis de trabalhar, então existem três funções\ndiferentes:\n\n- `typeOf` retorna o tipo subjacente de um valor: `typeOf $foo`\n- `typeIs` é como `kindIs`, mas para tipos: `typeIs \"*io.Buffer\" $myVal`\n- `typeIsLike` funciona como `typeIs`, exceto que também desreferencia ponteiros\n\n**Nota:** Nenhuma dessas pode testar se algo implementa uma determinada\ninterface, pois fazer isso exigiria compilar a interface antecipadamente.\n\n### deepEqual\n\n`deepEqual` retorna true se dois valores são [\"profundamente\niguais\"](https://golang.org/pkg/reflect/#DeepEqual)\n\nFunciona para tipos não primitivos também (comparado ao `eq` embutido).\n\n```\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\nO exemplo acima retornará `true`.\n\n## Funções de Versão Semântica\n\nAlguns esquemas de versão são facilmente analisáveis e comparáveis. O Helm\nfornece funções para trabalhar com versões [SemVer 2](http://semver.org). Essas\nincluem [semver](#semver) e [semverCompare](#semvercompare). Abaixo você também\nencontrará detalhes sobre o uso de intervalos para comparações.\n\n### semver\n\nA função `semver` analisa uma string em uma Versão Semântica:\n\n```\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_Se o analisador falhar, causará a interrupção da execução do template com um\nerro._\n\nNeste ponto, `$version` é um ponteiro para um objeto `Version` com as seguintes\npropriedades:\n\n- `$version.Major`: O número major (`1` acima)\n- `$version.Minor`: O número minor (`2` acima)\n- `$version.Patch`: O número patch (`3` acima)\n- `$version.Prerelease`: O prerelease (`alpha.1` acima)\n- `$version.Metadata`: Os metadados de build (`123` acima)\n- `$version.Original`: A versão original como string\n\nAdicionalmente, você pode comparar uma `Version` com outra `version` usando a\nfunção `Compare`:\n\n```\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\nO exemplo acima retornará `-1`.\n\nOs valores de retorno são:\n\n- `-1` se a semver fornecida for maior que a semver cujo método `Compare` foi\n  chamado\n- `1` se a versão cujo função `Compare` foi chamada for maior.\n- `0` se forem a mesma versão\n\n(Note que em SemVer, o campo `Metadata` não é comparado durante operações de\ncomparação de versão.)\n\n### semverCompare\n\nUma função de comparação mais robusta é fornecida como `semverCompare`. Esta\nversão suporta intervalos de versão:\n\n- `semverCompare \"1.2.3\" \"1.2.3\"` verifica uma correspondência exata\n- `semverCompare \"~1.2.0\" \"1.2.3\"` verifica se as versões major e minor\n  correspondem, e que o número patch do segundo parâmetro é _maior ou igual_ ao\n  primeiro parâmetro.\n\nAs funções SemVer usam a [biblioteca semver\nMasterminds](https://github.com/Masterminds/semver), dos criadores do Sprig.\n\n### Comparações Básicas\n\nExistem dois elementos nas comparações. Primeiro, uma string de comparação é uma\nlista de comparações AND separadas por espaço ou vírgula. Estas são então\nseparadas por || (comparações OR). Por exemplo, `\">= 1.2 < 3.0.0 || >= 4.2.3\"`\nestá procurando uma comparação que seja maior ou igual a 1.2 e menor que 3.0.0\nou que seja maior ou igual a 4.2.3.\n\nAs comparações básicas são:\n\n- `=`: igual (alias para nenhum operador)\n- `!=`: diferente\n- `>`: maior que\n- `<`: menor que\n- `>=`: maior ou igual a\n- `<=`: menor ou igual a\n\n### Trabalhando com Versões Prerelease\n\nPrereleases, para quem não está familiarizado com elas, são usadas para\nlançamentos de software antes de lançamentos estáveis ou geralmente disponíveis.\nExemplos de prereleases incluem lançamentos de desenvolvimento, alpha, beta e\nrelease candidate. Uma prerelease pode ser uma versão como `1.2.3-beta.1`,\nenquanto o lançamento estável seria `1.2.3`. Na ordem de precedência,\nprereleases vêm antes de seus lançamentos associados. Neste exemplo\n`1.2.3-beta.1 < 1.2.3`.\n\nDe acordo com a especificação de Versão Semântica, prereleases podem não ser\ncompatíveis com a API de sua contraparte de lançamento. Ela diz,\n\n> Uma versão prerelease indica que a versão é instável e pode não satisfazer os\n> requisitos de compatibilidade pretendidos, conforme indicado por sua versão\n> normal associada.\n\nComparações SemVer usando restrições sem um comparador de prerelease irão pular\nversões prerelease. Por exemplo, `>=1.2.3` pulará prereleases ao olhar uma lista\nde lançamentos, enquanto `>=1.2.3-0` avaliará e encontrará prereleases.\n\nA razão para o `0` como uma versão prerelease no exemplo de comparação é porque\nprereleases podem conter apenas alfanuméricos ASCII e hífens (junto com\nseparadores `.`), conforme a especificação. A ordenação acontece em ordem de\nclassificação ASCII, novamente conforme a especificação. O caractere mais baixo\né um `0` na ordem de classificação ASCII (veja uma [Tabela\nASCII](http://www.asciitable.com/))\n\nEntender a ordenação de classificação ASCII é importante porque A-Z vem antes de\na-z. Isso significa que `>=1.2.3-BETA` retornará `1.2.3-alpha`. O que você pode\nesperar da sensibilidade a maiúsculas/minúsculas não se aplica aqui. Isso se\ndeve à ordenação de classificação ASCII, que é o que a especificação determina.\n\n### Comparações de Intervalo com Hífen\n\nExistem múltiplos métodos para lidar com intervalos e o primeiro são intervalos\ncom hífen. Eles se parecem com:\n\n- `1.2 - 1.4.5` que é equivalente a `>= 1.2 <= 1.4.5`\n- `2.3.4 - 4.5` que é equivalente a `>= 2.3.4 <= 4.5`\n\n### Curingas em Comparações\n\nOs caracteres `x`, `X` e `*` podem ser usados como caractere curinga. Isso\nfunciona para todos os operadores de comparação. Quando usado no operador `=`,\nele volta para a comparação de nível patch (veja til abaixo). Por exemplo,\n\n- `1.2.x` é equivalente a `>= 1.2.0, < 1.3.0`\n- `>= 1.2.x` é equivalente a `>= 1.2.0`\n- `<= 2.x` é equivalente a `< 3`\n- `*` é equivalente a `>= 0.0.0`\n\n### Comparações de Intervalo Til (Patch)\n\nO operador de comparação til (`~`) é para intervalos de nível patch quando uma\nversão minor é especificada e mudanças de nível major quando o número minor está\nfaltando. Por exemplo,\n\n- `~1.2.3` é equivalente a `>= 1.2.3, < 1.3.0`\n- `~1` é equivalente a `>= 1, < 2`\n- `~2.3` é equivalente a `>= 2.3, < 2.4`\n- `~1.2.x` é equivalente a `>= 1.2.0, < 1.3.0`\n- `~1.x` é equivalente a `>= 1, < 2`\n\n### Comparações de Intervalo Circunflexo (Major)\n\nO operador de comparação circunflexo (`^`) é para mudanças de nível major uma\nvez que um lançamento estável (1.0.0) tenha ocorrido. Antes de um lançamento\n1.0.0, as versões minor funcionam como o nível de estabilidade da API. Isso é\nútil ao comparar versões de API, pois uma mudança major quebra a API. Por\nexemplo,\n\n- `^1.2.3` é equivalente a `>= 1.2.3, < 2.0.0`\n- `^1.2.x` é equivalente a `>= 1.2.0, < 2.0.0`\n- `^2.3` é equivalente a `>= 2.3, < 3`\n- `^2.x` é equivalente a `>= 2.0.0, < 3`\n- `^0.2.3` é equivalente a `>=0.2.3 <0.3.0`\n- `^0.2` é equivalente a `>=0.2.0 <0.3.0`\n- `^0.0.3` é equivalente a `>=0.0.3 <0.0.4`\n- `^0.0` é equivalente a `>=0.0.0 <0.1.0`\n- `^0` é equivalente a `>=0.0.0 <1.0.0`\n\n## Funções de URL\n\nO Helm inclui as funções [urlParse](#urlparse), [urlJoin](#urljoin) e\n[urlquery](#urlquery) permitindo que você trabalhe com partes de URL.\n\n### urlParse\n\nAnalisa uma string para URL e produz um dict com as partes da URL\n\n```\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\nO exemplo acima retorna um dict, contendo o objeto URL:\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nIsso é implementado usando os pacotes URL da biblioteca padrão Go. Para mais\ninformações, consulte https://golang.org/pkg/net/url/#URL\n\n### urlJoin\n\nUne um map (produzido por `urlParse`) para produzir uma string URL\n\n```\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\nO exemplo acima retorna a seguinte string:\n```\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nRetorna a versão escapada do valor passado como argumento para que seja\nadequado para incorporação na parte de query de uma URL.\n\n```\n$var := urlquery \"string for query\"\n```\n\n## Funções de UUID\n\nO Helm pode gerar UUIDs v4 universalmente únicos.\n\n```\nuuidv4\n```\n\nO exemplo acima retorna um novo UUID do tipo v4 (gerado aleatoriamente).\n\n## Funções de Kubernetes e Chart\n\nO Helm inclui funções para trabalhar com Kubernetes, incluindo\n[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas),\n[Files](#funções-de-arquivo) e [lookup](#lookup).\n\n### lookup\n\n`lookup` é usado para consultar recursos em um cluster em execução. Quando usado\ncom o comando `helm template`, sempre retorna uma resposta vazia.\n\nVocê pode encontrar mais detalhes na [documentação sobre a função\nlookup](./functions_and_pipelines.md#usando-a-função-lookup).\n\n### .Capabilities.APIVersions.Has\n\nRetorna se uma versão da API ou recurso está disponível em um cluster.\n\n```\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\nMais informações estão disponíveis na [documentação de objetos\nembutidos](./builtin_objects.md).\n\n### Funções de Arquivo\n\nExistem várias funções que permitem acessar arquivos não especiais dentro de um\nchart. Por exemplo, para acessar arquivos de configuração de aplicação. Estas\nestão documentadas em [Acessando Arquivos Dentro de\nTemplates](./accessing_files.md).\n\n_Nota: a documentação para muitas dessas funções vem do\n[Sprig](https://github.com/Masterminds/sprig). Sprig é uma biblioteca de funções\nde template disponível para aplicações Go._\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: Funções de Template e Pipelines\ndescription: Usando funções em templates.\nsidebar_position: 5\n---\n\nAté agora, vimos como inserir informações em um template. Porém, essas\ninformações são inseridas sem modificação. Às vezes, queremos transformar\nos dados fornecidos de uma forma que seja mais útil para nós.\n\nUma boa prática: ao injetar strings do objeto `.Values` no template, devemos\ncolocá-las entre aspas. Podemos fazer isso chamando a função `quote` na\ndiretiva do template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nAs funções de template seguem a sintaxe `nomeDaFuncao arg1 arg2...`. No trecho\nacima, `quote .Values.favorite.drink` chama a função `quote` e passa um\núnico argumento para ela.\n\nO Helm tem mais de 60 funções disponíveis. Algumas delas são definidas pela própria\n[linguagem de template do Go](https://godoc.org/text/template). A maioria das outras\nfaz parte da [biblioteca de templates Sprig](https://masterminds.github.io/sprig/).\nVeremos muitas delas conforme avançamos pelos exemplos.\n\n> Embora falemos da \"linguagem de template do Helm\" como se fosse específica do Helm,\n> na verdade é uma combinação da linguagem de template do Go, algumas funções extras\n> e uma variedade de wrappers para expor certos objetos aos templates. Muitos\n> recursos sobre templates do Go podem ser úteis enquanto você aprende sobre templating.\n\n## Pipelines\n\nUma das funcionalidades poderosas da linguagem de template é o conceito de\n_pipelines_. Baseando-se em um conceito do UNIX, pipelines são uma ferramenta para\nencadear uma série de comandos de template para expressar de forma compacta uma série\nde transformações. Em outras palavras, pipelines são uma forma eficiente de fazer\nvárias coisas em sequência. Vamos reescrever o exemplo acima usando um pipeline.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nNeste exemplo, em vez de chamar `quote ARGUMENTO`, invertemos a ordem.\n\"Enviamos\" o argumento para a função usando um pipeline (`|`):\n`.Values.favorite.drink | quote`. Usando pipelines, podemos encadear várias\nfunções juntas:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Inverter a ordem é uma prática comum em templates. Você verá `.val |\n> quote` com mais frequência do que `quote .val`. Ambas as práticas são válidas.\n\nQuando avaliado, esse template produzirá:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nObserve que nosso `pizza` original agora foi transformado em `\"PIZZA\"`.\n\nQuando usamos pipelines assim, o resultado da primeira avaliação\n(`.Values.favorite.drink`) é enviado como o _último argumento para a função_. Podemos\nmodificar o exemplo da bebida acima para ilustrar com uma função que recebe dois\nargumentos: `repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nA função `repeat` irá ecoar a string fornecida o número de vezes especificado, então\nteremos esta saída:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Usando a função `default`\n\nUma função frequentemente usada em templates é a função `default`: `default\nVALOR_PADRAO VALOR_FORNECIDO`. Esta função permite especificar um valor padrão\ndentro do template, caso o valor seja omitido. Vamos usá-la para modificar o\nexemplo da bebida acima:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nSe executarmos isso normalmente, obteremos nosso `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nAgora, vamos remover a configuração da bebida favorita do `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nAgora, executar novamente `helm install --dry-run --debug fair-worm ./mychart` produzirá\neste YAML:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nEm um chart real, todos os valores padrão estáticos devem estar no `values.yaml`\ne não devem ser repetidos usando o comando `default` (caso contrário, seriam\nredundantes). No entanto, o comando `default` é perfeito para valores computados,\nque não podem ser declarados dentro do `values.yaml`. Por exemplo:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nEm alguns casos, uma condição `if` pode ser mais adequada do que `default`.\nVeremos isso na próxima seção.\n\nFunções e pipelines de template são uma forma poderosa de transformar informações e\ninseri-las no seu YAML. Mas às vezes é necessário adicionar alguma lógica de template\nque seja um pouco mais sofisticada do que apenas inserir uma string. Na próxima\nseção, veremos as estruturas de controle fornecidas pela linguagem de template.\n\n## Usando a função `lookup`\n\nA função `lookup` pode ser usada para _consultar_ recursos em um cluster em execução.\nA sintaxe da função lookup é `lookup apiVersion, kind, namespace, name\n-> recurso ou lista de recursos`.\n\n| parâmetro  | tipo   |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\nTanto `name` quanto `namespace` são opcionais e podem ser passados como uma string\nvazia (`\"\"`). No entanto, se você estiver trabalhando com um recurso com escopo de\nnamespace, tanto `name` quanto `namespace` devem ser especificados.\n\nAs seguintes combinações de parâmetros são possíveis:\n\n| Comportamento                          | Função lookup                              |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\nQuando `lookup` retorna um objeto, ele retornará um dicionário. Este dicionário\npode ser navegado para extrair valores específicos.\n\nO exemplo a seguir retornará as annotations presentes no objeto `mynamespace`:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nQuando `lookup` retorna uma lista de objetos, é possível acessar a lista de objetos\natravés do campo `items`:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* faça algo com cada serviço */}}\n{{ end }}\n```\n\nQuando nenhum objeto é encontrado, um valor vazio é retornado. Isso pode ser usado para\nverificar a existência de um objeto.\n\nA função `lookup` usa a configuração de conexão existente do Helm com o Kubernetes\npara consultar o Kubernetes. Se algum erro for retornado ao interagir com o servidor\nda API (por exemplo, devido à falta de permissão para acessar um recurso), o\nprocessamento de template do Helm falhará.\n\nTenha em mente que o Helm não deve contatar o Servidor da API do Kubernetes durante\numa operação `helm template|install|upgrade|delete|rollback --dry-run`. Para testar\n`lookup` contra um cluster em execução, deve-se usar\n`helm template|install|upgrade|delete|rollback --dry-run=server` para permitir a\nconexão com o cluster.\n\n## Operadores são funções\n\nPara templates, os operadores (`eq`, `ne`, `lt`, `gt`, `and`, `or` e assim por diante)\nsão todos implementados como funções. Em pipelines, operações podem ser agrupadas com\nparênteses (`(` e `)`).\n\nAgora podemos passar de funções e pipelines para controle de fluxo com condições,\nloops e modificadores de escopo.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Primeiros Passos\ndescription: Um guia rápido sobre templates de Chart.\nsidebar_position: 2\n---\n\nNesta seção do guia, criaremos um chart e adicionaremos um primeiro template.\nO chart que criaremos aqui será usado ao longo do restante do guia.\n\nPara começar, vamos dar uma breve olhada em um chart do Helm.\n\n## Charts\n\nConforme descrito no [Guia de Charts](../topics/charts.md), os charts do Helm são\nestruturados assim:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nO diretório `templates/` é para arquivos de template. Quando o Helm avalia um chart,\nele passa todos os arquivos do diretório `templates/` pelo motor de templates.\nEm seguida, coleta os resultados desses templates e os envia ao Kubernetes.\n\nO arquivo `values.yaml` também é importante para templates. Este arquivo contém os\n_valores padrão_ de um chart. Esses valores podem ser sobrescritos pelos usuários durante\n`helm install` ou `helm upgrade`.\n\nO arquivo `Chart.yaml` contém uma descrição do chart. Você pode acessá-lo\nde dentro de um template.\n\nO diretório `charts/` _pode_ conter outros charts (que chamamos de _subcharts_).\nMais adiante neste guia veremos como eles funcionam quando se trata de renderização\nde templates.\n\n## Um Chart Inicial\n\nPara este guia, criaremos um chart simples chamado `mychart`, e depois criaremos\nalguns templates dentro dele.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### Uma Visão Rápida de `mychart/templates/`\n\nSe você olhar o diretório `mychart/templates/`, notará que alguns arquivos\njá estão lá.\n\n- `NOTES.txt`: O \"texto de ajuda\" do seu chart. Será exibido para os usuários\n  quando executarem `helm install`.\n- `deployment.yaml`: Um manifesto básico para criar um\n  [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n  do Kubernetes\n- `service.yaml`: Um manifesto básico para criar um [endpoint de\n  serviço](https://kubernetes.io/docs/concepts/services-networking/service/) para seu deployment\n- `_helpers.tpl`: Um lugar para colocar helpers de template que você pode reutilizar\n  em todo o chart\n\nE o que vamos fazer é... _remover todos eles!_ Dessa forma, podemos trabalhar no nosso\ntutorial do zero. Na verdade, criaremos nossos próprios `NOTES.txt` e\n`_helpers.tpl` conforme avançamos.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nQuando você estiver escrevendo charts de nível de produção, ter versões básicas desses\narquivos pode ser muito útil. Então, no seu dia a dia de criação de charts, você provavelmente\nnão vai querer removê-los.\n\n## Um Primeiro Template\n\nO primeiro template que vamos criar será um `ConfigMap`. No Kubernetes, um ConfigMap\né simplesmente um objeto para armazenar dados de configuração. Outras coisas, como\npods, podem acessar os dados em um ConfigMap.\n\nComo ConfigMaps são recursos básicos, eles são um ótimo ponto de partida para nós.\n\nVamos começar criando um arquivo chamado `mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**DICA:** Os nomes dos templates não seguem um padrão rígido de nomenclatura. No entanto,\nrecomendamos usar a extensão `.yaml` para arquivos YAML e `.tpl` para helpers.\n\nO arquivo YAML acima é um ConfigMap básico, com os campos mínimos necessários.\nPor estar no diretório `mychart/templates/`, ele passará pelo motor de templates.\n\nNão há problema em colocar um arquivo YAML simples como este no diretório\n`mychart/templates/`. Quando o Helm lê este template, ele simplesmente o envia ao\nKubernetes como está.\n\nCom este template simples, agora temos um chart instalável. E podemos instalá-lo\nassim:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nUsando o Helm, podemos recuperar a release e ver o template real que foi carregado.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nO comando `helm get manifest` recebe um nome de release (`full-coral`) e imprime\ntodos os recursos do Kubernetes que foram enviados ao servidor. Cada arquivo\ncomeça com `---` para indicar o início de um documento YAML, e depois é seguido\npor uma linha de comentário gerada automaticamente que nos diz qual arquivo de template\ngerou este documento YAML.\n\nA partir daí, podemos ver que os dados YAML são exatamente o que colocamos no nosso\narquivo `configmap.yaml`.\n\nAgora podemos desinstalar nossa release: `helm uninstall full-coral`.\n\n### Adicionando uma Chamada de Template Simples\n\nCodificar o `name:` diretamente em um recurso é geralmente considerado uma má\nprática. Os nomes devem ser únicos para uma release. Então, podemos querer gerar\num campo name inserindo o nome da release.\n\n**DICA:** O campo `name:` é limitado a 63 caracteres devido a limitações do sistema\nDNS. Por isso, os nomes de release são limitados a 53 caracteres.\nO Kubernetes 1.3 e anteriores eram limitados a apenas 24 caracteres (portanto,\nnomes de 14 caracteres).\n\nVamos alterar `configmap.yaml` de acordo.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nA grande mudança está no valor do campo `name:`, que agora é\n`{{ .Release.Name }}-configmap`.\n\n> Uma diretiva de template é delimitada por blocos `{{` e `}}`.\n\nA diretiva de template `{{ .Release.Name }}` injeta o nome da release no template.\nOs valores passados para um template podem ser pensados como _objetos com namespace_,\nonde um ponto (`.`) separa cada elemento do namespace.\n\nO ponto inicial antes de `Release` indica que começamos no namespace de nível mais\nalto para este escopo (falaremos sobre escopo em breve). Assim, podemos ler\n`.Release.Name` como \"comece no namespace de nível superior, encontre o objeto\n`Release`, e então procure dentro dele por um objeto chamado `Name`\".\n\nO objeto `Release` é um dos objetos embutidos do Helm, e o abordaremos com mais\nprofundidade depois. Mas, por enquanto, basta dizer que isso exibirá o nome da\nrelease que a biblioteca atribui à nossa release.\n\nAgora, quando instalamos nosso recurso, veremos imediatamente o resultado de usar\nesta diretiva de template:\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nVocê pode executar `helm get manifest clunky-serval` para ver o YAML completo gerado.\n\nNote que o ConfigMap dentro do Kubernetes agora se chama `clunky-serval-configmap`\nem vez de `mychart-configmap` como antes.\n\nNeste ponto, vimos templates em sua forma mais básica: arquivos YAML que têm\ndiretivas de template incorporadas em `{{` e `}}`. Na próxima parte, daremos uma\nolhada mais profunda nos templates. Mas antes de seguir em frente, há um truque\nrápido que pode tornar a construção de templates mais rápida: quando você quiser\ntestar a renderização do template, mas não quiser realmente instalar nada, você\npode usar `helm install --debug --dry-run goodly-guppy ./mychart`. Isso renderizará\nos templates. Mas em vez de instalar o chart, retornará o template renderizado\npara você, para que você possa ver a saída:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nUsar `--dry-run` facilitará o teste do seu código, mas não garantirá que o\nKubernetes em si aceitará os templates que você gerar. É melhor não presumir que\nseu chart será instalado só porque `--dry-run` funciona.\n\nNo [Guia de Templates de Chart](/chart_template_guide/index.mdx), pegamos o chart básico que definimos\naqui e exploramos a linguagem de templates do Helm em detalhes. E começaremos com\nos objetos embutidos.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: O arquivo .helmignore\ndescription: O arquivo `.helmignore` é usado para especificar arquivos que você não deseja incluir no seu chart Helm.\nsidebar_position: 12\n---\n\nO arquivo `.helmignore` é usado para especificar arquivos que você não deseja\nincluir no seu chart Helm.\n\nSe este arquivo existir, o comando `helm package` ignorará todos os arquivos que\ncorresponderem aos padrões especificados no `.helmignore` ao empacotar sua\naplicação.\n\nIsso ajuda a evitar que arquivos ou diretórios desnecessários ou sensíveis\nsejam adicionados ao seu chart.\n\nO arquivo `.helmignore` suporta padrões glob do shell Unix, correspondência\nde caminhos relativos e negação (prefixada com !). Apenas um padrão por linha é\nconsiderado.\n\nAqui está um exemplo de arquivo `.helmignore`:\n\n```\n# comment\n\n# Match any file or path named .helmignore\n.helmignore\n\n# Match any file or path named .git\n.git\n\n# Match any text file\n*.txt\n\n# Match only directories named mydir\nmydir/\n\n# Match only text files in the top-level directory\n/*.txt\n\n# Match only the file foo.txt in the top-level directory\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt\na[b-d].txt\n\n# Match any file under subdir matching temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nAlgumas diferenças notáveis em relação ao .gitignore:\n- A sintaxe '**' não é suportada.\n- A biblioteca de globbing é `filepath.Match` do Go, não fnmatch(3)\n- Espaços em branco no final são sempre ignorados (não há sequência de escape para preservá-los)\n- Não há suporte para '\\!' como sequência especial inicial.\n- O arquivo não se exclui automaticamente; você precisa adicionar uma entrada explícita para `.helmignore`\n\n\n**Adoraríamos sua ajuda** para melhorar este documento. Para adicionar, corrigir\nou remover informações, [abra uma issue](https://github.com/helm/helm-www/issues)\nou envie-nos um pull request.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Templates Nomeados\ndescription: Como definir templates nomeados.\nsidebar_position: 9\n---\n\nÉ hora de ir além de um único template e começar a criar outros. Nesta seção,\nveremos como definir _templates nomeados_ em um arquivo e usá-los em outros\nlugares. Um _template nomeado_ (às vezes chamado de _partial_ ou _subtemplate_)\né simplesmente um template definido dentro de um arquivo, que recebe um nome.\nVeremos duas formas de criá-los e algumas formas diferentes de usá-los.\n\nNa seção [Estruturas de Controle](/chart_template_guide/control_structures.md) introduzimos três ações\npara declarar e gerenciar templates: `define`, `template` e `block`. Nesta\nseção, abordaremos essas três ações e também apresentaremos uma função especial\nchamada `include`, que funciona de forma semelhante à ação `template`.\n\nUm detalhe importante a ter em mente ao nomear templates: **os nomes de templates\nsão globais**. Se você declarar dois templates com o mesmo nome, aquele que for\ncarregado por último será o utilizado. Como templates em subcharts são compilados\njunto com templates de nível superior, você deve ter cuidado ao nomear seus\ntemplates com _nomes específicos do chart_.\n\nUma convenção de nomenclatura popular é prefixar cada template definido com o\nnome do chart: `{{ define \"mychart.labels\" }}`. Usando o nome específico do\nchart como prefixo, podemos evitar conflitos que possam surgir devido a dois\ncharts diferentes que implementam templates com o mesmo nome.\n\nEsse comportamento também se aplica a diferentes versões de um chart. Se você\ntiver `mychart` versão `1.0.0` que define um template de uma forma, e `mychart`\nversão `2.0.0` que modifica o template nomeado existente, será usado aquele que\nfoi carregado por último. Você pode contornar esse problema adicionando também\numa versão no nome do chart: `{{ define \"mychart.v1.labels\" }}` e\n`{{ define \"mychart.v2.labels\" }}`.\n\n## Partials e arquivos `_`\n\nAté agora, usamos um único arquivo, e esse arquivo continha um único template.\nMas a linguagem de templates do Helm permite criar templates incorporados\nnomeados, que podem ser acessados pelo nome em outros lugares.\n\nAntes de escrever esses templates, há uma convenção de nomenclatura de arquivos\nque vale mencionar:\n\n* A maioria dos arquivos em `templates/` é tratada como se contivesse manifestos\n  Kubernetes\n* O `NOTES.txt` é uma exceção\n* Mas arquivos cujo nome começa com underscore (`_`) assumem-se como _não_ tendo\n  um manifesto dentro. Esses arquivos não são renderizados como definições de\n  objetos Kubernetes, mas estão disponíveis em todos os outros templates do\n  chart para uso.\n\nEsses arquivos são usados para armazenar partials e helpers. Na verdade, quando\ncriamos `mychart` pela primeira vez, vimos um arquivo chamado `_helpers.tpl`.\nEsse arquivo é o local padrão para partials de template.\n\n## Declarando e usando templates com `define` e `template`\n\nA ação `define` permite criar um template nomeado dentro de um arquivo de\ntemplate. Sua sintaxe é assim:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # corpo do template aqui\n{{- end }}\n```\n\nPor exemplo, podemos definir um template para encapsular um bloco de labels\ndo Kubernetes:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nAgora podemos incorporar esse template dentro do nosso ConfigMap existente e\nincluí-lo com a ação `template`:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nQuando o motor de templates lê este arquivo, ele armazena a referência ao\n`mychart.labels` até que `template \"mychart.labels\"` seja chamado. Então ele\nrenderiza esse template inline. O resultado será assim:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nNota: um `define` não produz saída a menos que seja chamado com um template,\ncomo neste exemplo.\n\nConvencionalmente, os charts do Helm colocam esses templates dentro de um\narquivo de partials, geralmente `_helpers.tpl`. Vamos mover esta função para lá:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nPor convenção, funções `define` devem ter um bloco de documentação simples\n(`{{/* ... */}}`) descrevendo o que fazem.\n\nMesmo que esta definição esteja em `_helpers.tpl`, ela ainda pode ser acessada\nem `configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nComo mencionado acima, **os nomes de templates são globais**. Como resultado,\nse dois templates forem declarados com o mesmo nome, a última ocorrência será\na utilizada. Como templates em subcharts são compilados junto com templates de\nnível superior, é melhor nomear seus templates com _nomes específicos do chart_.\nUma convenção de nomenclatura popular é prefixar cada template definido com o\nnome do chart: `{{ define \"mychart.labels\" }}`.\n\n## Definindo o escopo de um template\n\nNo template que definimos acima, não usamos nenhum objeto. Apenas usamos\nfunções. Vamos modificar nosso template definido para incluir o nome e a versão\ndo chart:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nSe renderizarmos isso, obteremos um erro como este:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nPara ver o que foi renderizado, execute novamente com `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`.\nO resultado não será o que esperamos:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\nO que aconteceu com o nome e a versão? Eles não estavam no escopo do nosso\ntemplate definido. Quando um template nomeado (criado com `define`) é\nrenderizado, ele recebe o escopo passado pela chamada `template`. No nosso\nexemplo, incluímos o template assim:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nNenhum escopo foi passado, então dentro do template não podemos acessar nada em\n`.`. Isso é fácil de corrigir. Basta passar um escopo para o template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nNote que passamos `.` no final da chamada `template`. Poderíamos facilmente\npassar `.Values` ou `.Values.favorite` ou qualquer escopo que quisermos. Mas o\nque queremos é o escopo de nível superior. No contexto do template nomeado, `$`\nse referirá ao escopo que você passou, e não a algum escopo global.\n\nAgora, quando executamos este template com `helm install --dry-run --debug\nplinking-anaco ./mychart`, obtemos isto:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nAgora `{{ .Chart.Name }}` resolve para `mychart`, e `{{ .Chart.Version }}`\nresolve para `0.1.0`.\n\n## A função `include`\n\nDigamos que definimos um template simples assim:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nAgora digamos que quero inserir isso tanto na seção `labels:` do meu template,\nquanto na seção `data:`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nSe renderizarmos isso, obteremos um erro como este:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nPara ver o que foi renderizado, execute novamente com `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`.\nA saída não será o que esperamos:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nNote que a indentação de `app_version` está errada em ambos os lugares. Por quê?\nPorque o template substituído tem o texto alinhado à esquerda. Como `template`\né uma ação, e não uma função, não há como passar a saída de uma chamada\n`template` para outras funções; os dados são simplesmente inseridos inline.\n\nPara contornar esse caso, o Helm fornece uma alternativa ao `template` que\nimporta o conteúdo de um template para o pipeline atual, onde pode ser passado\npara outras funções no pipeline.\n\nAqui está o exemplo acima, corrigido usando `indent` para indentar o template\n`mychart.app` corretamente:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nAgora o YAML produzido está corretamente indentado para cada seção:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> É considerado preferível usar `include` em vez de `template` em templates do\n> Helm simplesmente para que a formatação de saída possa ser melhor controlada\n> para documentos YAML.\n\nÀs vezes queremos importar conteúdo, mas não como templates. Ou seja, queremos\nimportar arquivos literalmente. Podemos fazer isso acessando arquivos através do\nobjeto `.Files` descrito na próxima seção.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Criando um Arquivo NOTES.txt\ndescription: Como fornecer instruções para os usuários do seu Chart.\nsidebar_position: 10\n---\n\nNesta seção vamos ver a ferramenta do Helm para fornecer instruções aos usuários\ndo seu chart. No final de um `helm install` ou `helm upgrade`, o Helm pode\nexibir um bloco de informações úteis para os usuários. Essas informações podem\nser personalizadas usando templates.\n\nPara adicionar notas de instalação ao seu chart, basta criar um arquivo\n`templates/NOTES.txt`. Este arquivo é texto simples, mas é processado como um\ntemplate e tem todas as funções e objetos de template disponíveis.\n\nVamos criar um arquivo `NOTES.txt` simples:\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nAgora, se executarmos `helm install rude-cardinal ./mychart`, veremos esta\nmensagem no final:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nUsar o `NOTES.txt` dessa forma é uma ótima maneira de fornecer aos seus usuários\ninformações detalhadas sobre como utilizar o chart recém-instalado. A criação de\num arquivo `NOTES.txt` é fortemente recomendada, embora não obrigatória.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Subcharts e Valores Globais\ndescription: Como trabalhar com subcharts e valores globais.\nsidebar_position: 11\n---\n\nAté este ponto, trabalhamos apenas com um único chart. Mas charts podem ter\ndependências, chamadas _subcharts_, que também possuem seus próprios values e\ntemplates. Nesta seção, vamos criar um subchart e ver as diferentes formas de\nacessar values dentro de templates.\n\nAntes de entrarmos no código, há alguns detalhes importantes sobre subcharts\nde aplicação:\n\n1. Um subchart é considerado \"independente\", o que significa que um subchart\n   nunca pode depender explicitamente de seu chart pai.\n2. Por essa razão, um subchart não pode acessar os values de seu chart pai.\n3. Um chart pai pode sobrescrever values para subcharts.\n4. O Helm possui um conceito de _valores globais_ que podem ser acessados por\n   todos os charts.\n\n> Essas limitações não se aplicam necessariamente a [library charts](/topics/library_charts.md), que são projetados para fornecer funcionalidade auxiliar padronizada.\n\nÀ medida que avançamos pelos exemplos desta seção, muitos desses conceitos\nficarão mais claros.\n\n## Criando um Subchart\n\nPara estes exercícios, vamos começar com o chart `mychart/` que criamos no\ninício deste guia e adicionar um novo chart dentro dele.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nNote que, assim como antes, excluímos todos os templates base para que possamos\ncomeçar do zero. Neste guia, estamos focados em como os templates funcionam, não\nem gerenciar dependências. Mas o [Guia de Charts](/topics/charts.md)\ntem mais informações sobre como subcharts funcionam.\n\n## Adicionando Values e um Template ao Subchart\n\nEm seguida, vamos criar um template simples e um arquivo de values para nosso\nchart `mysubchart`. Já deve existir um `values.yaml` em `mychart/charts/mysubchart`.\nVamos configurá-lo assim:\n\n```yaml\ndessert: cake\n```\n\nEm seguida, vamos criar um novo template de ConfigMap em\n`mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nComo cada subchart é um _chart independente_, podemos testar `mysubchart`\nseparadamente:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Sobrescrevendo Values de um Chart Pai\n\nNosso chart original, `mychart`, agora é o _chart pai_ de `mysubchart`. Essa\nrelação é baseada inteiramente no fato de que `mysubchart` está dentro de\n`mychart/charts`.\n\nComo `mychart` é um chart pai, podemos especificar configuração em `mychart` e\nter essa configuração aplicada ao `mysubchart`. Por exemplo, podemos modificar\n`mychart/values.yaml` assim:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nNote as duas últimas linhas. Qualquer diretiva dentro da seção `mysubchart` será\nenviada para o chart `mysubchart`. Então, se executarmos `helm install --generate-name --dry-run --debug\nmychart`, uma das coisas que veremos é o ConfigMap do `mysubchart`:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nO valor no nível superior agora sobrescreveu o valor do subchart.\n\nHá um detalhe importante a notar aqui. Não alteramos o template de\n`mychart/charts/mysubchart/templates/configmap.yaml` para apontar para\n`.Values.mysubchart.dessert`. Da perspectiva desse template, o valor ainda está\nlocalizado em `.Values.dessert`. À medida que o motor de templates passa os\nvalues, ele define o escopo. Então, para os templates do `mysubchart`, apenas\nvalues específicos para `mysubchart` estarão disponíveis em `.Values`.\n\nÀs vezes, porém, você quer que certos values estejam disponíveis para todos os\ntemplates. Isso é realizado usando valores globais de chart.\n\n## Valores Globais de Chart\n\nValores globais são values que podem ser acessados de qualquer chart ou subchart\npelo exato mesmo nome. Valores globais requerem declaração explícita. Você não\npode usar um valor não-global existente como se fosse global.\n\nO tipo de dados Values possui uma seção reservada chamada `Values.global` onde\nvalores globais podem ser definidos. Vamos definir um no nosso arquivo\n`mychart/values.yaml`.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nDevido à forma como os valores globais funcionam, tanto `mychart/templates/configmap.yaml`\nquanto `mysubchart/templates/configmap.yaml` devem ser capazes de acessar esse\nvalor como `{{ .Values.global.salad }}`.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nAgora, se executarmos uma instalação dry run, veremos o mesmo valor em ambas as\nsaídas:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nValores globais são úteis para passar informações assim, embora exija algum\nplanejamento para garantir que os templates corretos estejam configurados para\nusar valores globais.\n\n## Compartilhando Templates com Subcharts\n\nCharts pai e subcharts podem compartilhar templates. Qualquer bloco definido em\nqualquer chart está disponível para outros charts.\n\nPor exemplo, podemos definir um template simples assim:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nLembre-se de como os labels em templates são _globalmente compartilhados_. Assim,\no chart `labels` pode ser incluído de qualquer outro chart.\n\nEmbora desenvolvedores de charts possam escolher entre `include` e `template`,\numa vantagem de usar `include` é que `include` pode referenciar templates\ndinamicamente:\n\n```yaml\n{{ include $mytemplate }}\n```\n\nO código acima desreferencia `$mytemplate`. A função `template`, em contraste,\naceita apenas uma string literal.\n\n## Evite Usar Blocks\n\nA linguagem de template Go fornece uma palavra-chave `block` que permite aos\ndesenvolvedores fornecer uma implementação padrão que é sobrescrita posteriormente.\nEm charts do Helm, blocks não são a melhor ferramenta para sobrescrita porque,\nse múltiplas implementações do mesmo block forem fornecidas, a selecionada é\nimprevisível.\n\nA recomendação é usar `include` em vez disso.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Arquivos de Values\ndescription: Instruções sobre como utilizar a flag --values.\nsidebar_position: 4\n---\n\nNa seção anterior, vimos os objetos embutidos que os templates do Helm oferecem.\nUm dos objetos embutidos é `Values`. Este objeto fornece acesso aos valores\npassados para o chart. Seu conteúdo pode vir de múltiplas fontes:\n\n- O arquivo `values.yaml` no chart\n- Se este for um subchart, o arquivo `values.yaml` de um chart pai\n- Um arquivo de values passado ao `helm install` ou `helm upgrade` com a flag `-f`\n  (`helm install -f myvals.yaml ./mychart`)\n- Parâmetros individuais passados com `--set` (como `helm install --set foo=bar\n  ./mychart`)\n\nA lista acima está em ordem de especificidade: `values.yaml` é o padrão, que pode\nser sobrescrito pelo `values.yaml` de um chart pai, que por sua vez pode ser\nsobrescrito por um arquivo de values fornecido pelo usuário, que por sua vez pode\nser sobrescrito por parâmetros `--set`.\n\nArquivos de values são arquivos YAML simples. Vamos editar `mychart/values.yaml`\ne depois editar nosso template de ConfigMap.\n\nRemovendo os valores padrão em `values.yaml`, vamos definir apenas um parâmetro:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nAgora podemos usar isso dentro de um template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nObserve que na última linha acessamos `favoriteDrink` como um atributo de `Values`:\n`{{ .Values.favoriteDrink }}`.\n\nVamos ver como isso é renderizado.\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nComo `favoriteDrink` está definido no arquivo `values.yaml` padrão como `coffee`,\nesse é o valor exibido no template. Podemos facilmente sobrescrever isso\nadicionando a flag `--set` na nossa chamada ao `helm install`:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nComo `--set` tem maior precedência que o arquivo `values.yaml` padrão, nosso\ntemplate gera `drink: slurm`.\n\nArquivos de values também podem conter conteúdo mais estruturado. Por exemplo, podemos\ncriar uma seção `favorite` no nosso arquivo `values.yaml` e adicionar várias chaves\nnela:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nAgora precisamos modificar ligeiramente o template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nEmbora seja possível estruturar dados dessa forma, a recomendação é manter suas\nárvores de values rasas, favorecendo a simplicidade. Quando vermos como atribuir\nvalues a subcharts, entenderemos como os values são nomeados usando uma estrutura\nde árvore.\n\n## Excluindo uma chave padrão\n\nSe você precisar excluir uma chave dos values padrão, pode sobrescrever o valor\nda chave para `null`, e nesse caso o Helm removerá a chave da mesclagem de\nvalues sobrescritos.\n\nPor exemplo, o chart stable do Drupal permite configurar o liveness probe, caso\nvocê configure uma imagem personalizada. Aqui estão os values padrão:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nSe você tentar sobrescrever o handler do livenessProbe para `exec` em vez de `httpGet`\nusando `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, o Helm irá\nmesclar as chaves padrão e sobrescritas, resultando no seguinte YAML:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nNo entanto, o Kubernetes falharia porque não é possível declarar mais de um\nhandler de livenessProbe. Para contornar isso, você pode instruir o Helm a excluir\no `livenessProbe.httpGet` definindo-o como null:\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nNeste ponto, já vimos vários objetos embutidos e os utilizamos para injetar\ninformações em um template. Agora vamos analisar outro aspecto do motor de\ntemplates: funções e pipelines.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: Variáveis\ndescription: Usando variáveis em templates.\nsidebar_position: 8\n---\n\nCom funções, pipelines, objetos e estruturas de controle em mãos, podemos\npassar para uma das ideias mais básicas em muitas linguagens de programação:\nvariáveis. Em templates, elas são usadas com menos frequência. Mas veremos como\nutilizá-las para simplificar o código e fazer melhor uso de `with` e `range`.\n\nEm um exemplo anterior, vimos que este código vai falhar:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` não está dentro do escopo restrito pelo bloco `with`.\nUma forma de contornar problemas de escopo é atribuir objetos a variáveis que podem\nser acessadas fora do escopo atual.\n\nEm templates do Helm, uma variável é uma referência nomeada para outro objeto. Ela\nsegue a forma `$nome`. Variáveis são atribuídas com um operador especial de\natribuição: `:=`. Podemos reescrever o exemplo acima para usar uma variável para\n`Release.Name`.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nObserve que antes de iniciar o bloco `with`, atribuímos `$relname :=\n.Release.Name`. Agora, dentro do bloco `with`, a variável `$relname` ainda\naponta para o nome da release.\n\nAo executar, teremos:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nVariáveis são particularmente úteis em loops `range`. Elas podem ser usadas em\nobjetos do tipo lista para capturar tanto o índice quanto o valor:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nNote que `range` vem primeiro, depois as variáveis, em seguida o operador de\natribuição e por fim a lista. Isso atribuirá o índice inteiro (começando do zero)\na `$index` e o valor a `$topping`. O resultado será:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nPara estruturas de dados que possuem tanto uma chave quanto um valor, podemos usar\n`range` para obter ambos. Por exemplo, podemos iterar sobre `.Values.favorite`\ndesta forma:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nAgora, na primeira iteração, `$key` será `drink` e `$val` será `coffee`, e na\nsegunda, `$key` será `food` e `$val` será `pizza`. Executar o exemplo acima irá\ngerar:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nVariáveis normalmente não são \"globais\". Elas têm escopo limitado ao bloco onde\nforam declaradas. Anteriormente, atribuímos `$relname` no nível superior do\ntemplate. Essa variável estará disponível em todo o template. Mas no nosso último\nexemplo, `$key` e `$val` só estarão disponíveis dentro do bloco\n`{{ range... }}{{ end }}`.\n\nNo entanto, há uma variável que sempre aponta para o contexto raiz: `$`.\nIsso pode ser muito útil quando você está iterando em um range e precisa saber o\nnome da release do chart.\n\nUm exemplo ilustrando isso:\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Muitos templates do Helm usariam `.` abaixo, mas isso não funcionará,\n    # porém `$` funcionará aqui\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # Não posso referenciar .Chart.Name, mas posso fazer $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Valor de appVersion em Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nAté agora vimos apenas um template declarado em um único arquivo. Mas um dos\nrecursos poderosos da linguagem de templates do Helm é a capacidade de declarar\nmúltiplos templates e usá-los juntos. Abordaremos isso na próxima seção.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Próximos Passos\ndescription: Finalizando - alguns apontamentos úteis para outras documentações que irão ajudá-lo.\nsidebar_position: 14\n---\n\nEste guia tem o objetivo de fornecer a você, desenvolvedor de charts, uma compreensão\nsólida de como utilizar a linguagem de templates do Helm. O guia foca nos aspectos\ntécnicos do desenvolvimento de templates.\n\nMas há muitas coisas que este guia não cobriu quando se trata do desenvolvimento\nprático do dia a dia de charts. Aqui estão alguns apontamentos úteis para outras\ndocumentações que irão ajudá-lo na criação de novos charts:\n\n- O [Artifact Hub](https://artifacthub.io/packages/search?kind=0) da CNCF é uma\n  fonte indispensável de charts.\n- A [Documentação](https://kubernetes.io/docs/home/) do Kubernetes fornece\n  exemplos detalhados dos diversos tipos de recursos que você pode utilizar, desde\n  ConfigMaps e Secrets até DaemonSets e Deployments.\n- O [Guia de Charts](/topics/charts.md) do Helm explica o fluxo de trabalho com\n  charts.\n- O [Guia de Hooks de Charts](/topics/charts_hooks.md) do Helm explica como\n  criar lifecycle hooks.\n- O artigo [Dicas e Truques para Charts](/howto/charts_tips_and_tricks.md) do Helm\n  fornece algumas dicas úteis para escrever charts.\n- A [documentação do Sprig](https://github.com/Masterminds/sprig) documenta mais\n  de sessenta funções de template.\n- A [documentação de templates Go](https://godoc.org/text/template) explica a\n  sintaxe de templates em detalhes.\n- A [ferramenta Schelm](https://github.com/databus23/schelm) é um utilitário\n  auxiliar útil para depuração de charts.\n\nÀs vezes é mais fácil fazer algumas perguntas e obter respostas de desenvolvedores\nexperientes. O melhor lugar para isso é nos canais do Helm no [Slack do\nKubernetes](https://kubernetes.slack.com):\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nPor fim, se você encontrar erros ou omissões neste documento, quiser sugerir algum\nnovo conteúdo, ou gostaria de contribuir, visite o [Projeto\nHelm](https://github.com/helm/helm-www).\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Apêndice: Técnicas de YAML\"\ndescription: Uma análise mais detalhada da especificação YAML e como ela se aplica ao Helm.\nsidebar_position: 15\n---\n\nA maior parte deste guia foi focada em escrever a linguagem de template. Aqui,\nvamos analisar o formato YAML. O YAML tem alguns recursos úteis que nós, como\nautores de templates, podemos usar para tornar nossos templates menos propensos\na erros e mais fáceis de ler.\n\n## Escalares e Coleções\n\nDe acordo com a [especificação YAML](https://yaml.org/spec/1.2/spec.html), existem dois\ntipos de coleções e muitos tipos escalares.\n\nOs dois tipos de coleções são mapas e sequências:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nValores escalares são valores individuais (em oposição a coleções)\n\n### Tipos Escalares em YAML\n\nNo dialeto YAML do Helm, o tipo de dados escalar de um valor é determinado por um\nconjunto complexo de regras, incluindo o schema do Kubernetes para definições de recursos.\nMas ao inferir tipos, as seguintes regras geralmente se aplicam.\n\nSe um inteiro ou float for uma palavra simples sem aspas, ele é tipicamente tratado como um\ntipo numérico:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nMas se estiverem entre aspas, são tratados como strings:\n\n```yaml\ncount: \"1\" # <-- string, não int\nsize: '2.34' # <-- string, não float\n```\n\nO mesmo vale para booleanos:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # string\n```\n\nA palavra para um valor vazio é `null` (não `nil`).\n\nNote que `port: \"80\"` é YAML válido e passará tanto pelo motor de template quanto\npelo parser YAML, mas falhará se o Kubernetes esperar que `port` seja um\ninteiro.\n\nEm alguns casos, você pode forçar uma inferência de tipo específica usando tags de tipo YAML:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nNo exemplo acima, `!!str` informa ao parser que `age` é uma string, mesmo que pareça\num int. E `port` é tratado como int, mesmo estando entre aspas.\n\n\n## Strings em YAML\n\nGrande parte dos dados que colocamos em documentos YAML são strings. O YAML tem mais de\numa maneira de representar uma string. Esta seção explica as diferentes formas e demonstra\ncomo usar algumas delas.\n\nExistem três formas \"inline\" de declarar uma string:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nTodos os estilos inline devem estar em uma única linha.\n\n- Palavras simples não têm aspas e não são escapadas. Por isso, você precisa ter\n  cuidado com os caracteres que usa.\n- Strings com aspas duplas podem ter caracteres específicos escapados com `\\`. Por\n  exemplo `\"\\\"Hello\\\", she said\"`. Você pode escapar quebras de linha com `\\n`.\n- Strings com aspas simples são strings \"literais\" e não usam `\\` para escapar\n  caracteres. A única sequência de escape é `''`, que é decodificada como um único\n  `'`.\n\nAlém das strings de uma linha, você pode declarar strings de múltiplas linhas:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nO exemplo acima tratará o valor de `coffee` como uma única string equivalente a\n`Latte\\nCappuccino\\nEspresso\\n`.\n\nNote que a primeira linha após o `|` deve estar corretamente indentada. Então poderíamos\nquebrar o exemplo acima fazendo isso:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nComo `Latte` está incorretamente indentado, teríamos um erro como este:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nEm templates, às vezes é mais seguro colocar uma \"primeira linha\" fictícia de conteúdo em um\ndocumento de múltiplas linhas para proteção contra o erro acima:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nSeja qual for essa primeira linha, ela será preservada na saída da\nstring. Então, se você estiver usando essa técnica para injetar o conteúdo de um arquivo\nem um ConfigMap, o comentário deve ser do tipo esperado por\nqualquer coisa que esteja lendo essa entrada.\n\n### Controlando Espaços em Strings de Múltiplas Linhas\n\nNo exemplo acima, usamos `|` para indicar uma string de múltiplas linhas. Mas note\nque o conteúdo da nossa string era seguido por um `\\n` final. Se quisermos que o\nprocessador YAML remova a nova linha final, podemos adicionar um `-` após o\n`|`:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nAgora o valor de `coffee` será: `Latte\\nCappuccino\\nEspresso` (sem o\n`\\n` final).\n\nOutras vezes, podemos querer preservar todos os espaços em branco finais. Podemos fazer\nisso com a notação `|+`:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nAgora o valor de `coffee` será `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nA indentação dentro de um bloco de texto é preservada e resulta na preservação\nde quebras de linha também:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nNo caso acima, `coffee` será `Latte\\n  12 oz\\n  16\noz\\nCappuccino\\nEspresso`.\n\n### Indentação e Templates\n\nAo escrever templates, você pode precisar injetar o conteúdo de\num arquivo no template. Como vimos em capítulos anteriores, existem duas maneiras de\nfazer isso:\n\n- Use `{{ .Files.Get \"FILENAME\" }}` para obter o conteúdo de um arquivo no chart.\n- Use `{{ include \"TEMPLATE\" . }}` para renderizar um template e então colocar seu\n  conteúdo no chart.\n\nAo inserir arquivos em YAML, é bom entender as regras de múltiplas linhas\nacima. Frequentemente, a maneira mais fácil de inserir um arquivo estático é fazer algo\ncomo isto:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nNote como fazemos a indentação acima: `indent 2` instrui o motor de template a\nindentar cada linha em \"myfile.txt\" com dois espaços. Note que não indentamos\nessa linha de template. Isso porque, se fizéssemos, o conteúdo do arquivo da primeira linha\nseria indentado duas vezes.\n\n### Strings de Múltiplas Linhas Dobradas\n\nÀs vezes você quer representar uma string em seu YAML com múltiplas linhas, mas\nquer que ela seja tratada como uma única linha longa quando interpretada. Isso é chamado\nde \"dobramento\" (folding). Para declarar um bloco dobrado, use `>` em vez de `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nO valor de `coffee` acima será `Latte Cappuccino Espresso\\n`. Note que todas\nas quebras de linha, exceto a última, serão convertidas em espaços. Você pode combinar os\ncontroles de espaço em branco com o marcador de texto dobrado, então `>-` substituirá ou removerá\ntodas as novas linhas.\n\nNote que na sintaxe dobrada, indentar o texto fará com que as linhas sejam preservadas.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nO exemplo acima produzirá `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Note que\ntanto o espaçamento quanto as novas linhas ainda estão lá.\n\n## Incorporando Múltiplos Documentos em Um Arquivo\n\nÉ possível colocar mais de um documento YAML em um único arquivo. Isso é\nfeito prefixando um novo documento com `---` e terminando o documento com\n`...`\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nEm muitos casos, tanto o `---` quanto o `...` podem ser omitidos.\n\nAlguns arquivos no Helm não podem conter mais de um documento. Se, por exemplo, mais de\num documento for fornecido dentro de um arquivo `values.yaml`, apenas o primeiro será\nusado.\n\nArquivos de template, no entanto, podem ter mais de um documento. Quando isso acontece, o\narquivo (e todos os seus documentos) é tratado como um objeto durante a renderização do template.\nMas então o YAML resultante é dividido em múltiplos documentos antes\nde ser enviado ao Kubernetes.\n\nRecomendamos usar múltiplos documentos por arquivo apenas quando for absolutamente\nnecessário. Ter múltiplos documentos em um arquivo pode ser difícil de depurar.\n\n## YAML é um Superconjunto de JSON\n\nComo YAML é um superconjunto de JSON, qualquer documento JSON válido _deve_ ser YAML válido.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nO exemplo acima é outra forma de representar isto:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nE os dois podem ser misturados (com cuidado):\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nTodos os três devem resultar na mesma representação interna.\n\nEmbora isso signifique que arquivos como `values.yaml` podem conter dados JSON, o Helm\nnão trata a extensão de arquivo `.json` como um sufixo válido.\n\n## Âncoras YAML\n\nA especificação YAML fornece uma maneira de armazenar uma referência a um valor e depois referir-se\na esse valor por referência. O YAML chama isso de \"ancoragem\":\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nNo exemplo acima, `&favoriteCoffee` define uma referência para `Cappuccino`. Depois, essa\nreferência é usada como `*favoriteCoffee`. Então `coffees` se torna `Latte, Cappuccino,\nEspresso`.\n\nEmbora existam alguns casos em que âncoras são úteis, há um aspecto delas que\npode causar bugs sutis: Na primeira vez que o YAML é consumido, a\nreferência é expandida e depois descartada.\n\nEntão, se decodificássemos e depois recodificássemos o exemplo acima, o YAML resultante\nseria:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nComo o Helm e o Kubernetes frequentemente leem, modificam e depois reescrevem arquivos YAML, as\nâncoras serão perdidas.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: Mudanças Desde o Helm 2\nsidebar_position: 1\n---\n\n## Mudanças desde o Helm 2\n\nAqui está uma lista completa de todas as principais mudanças introduzidas no Helm 3.\n\n### Remoção do Tiller\n\nDurante o ciclo de desenvolvimento do Helm 2, introduzimos o Tiller. O Tiller\nteve um papel importante para equipes que trabalhavam em um cluster compartilhado\n— ele tornava possível que vários operadores diferentes interagissem com o mesmo\nconjunto de releases.\n\nCom o controle de acesso baseado em funções (RBAC) habilitado por padrão no\nKubernetes 1.6, restringir o Tiller para uso em cenários de produção se tornou\nmais difícil de gerenciar. Devido ao grande número de possíveis políticas de\nsegurança, nossa posição era fornecer uma configuração permissiva por padrão.\nIsso permitia que usuários iniciantes começassem a experimentar o Helm e o\nKubernetes sem ter que mergulhar de cabeça nos controles de segurança.\nInfelizmente, essa configuração permissiva podia conceder a um usuário uma ampla\ngama de permissões que ele não deveria ter. DevOps e SREs precisavam aprender\netapas operacionais adicionais ao instalar o Tiller em um cluster multi-tenant.\n\nApós ouvir como os membros da comunidade estavam usando o Helm em determinados\ncenários, descobrimos que o sistema de gerenciamento de releases do Tiller não\nprecisava depender de um operador no cluster para manter o estado ou atuar como\num hub central para informações de releases do Helm. Em vez disso, podíamos\nsimplesmente buscar informações do servidor de API do Kubernetes, renderizar os\nCharts no lado do cliente e armazenar um registro da instalação no Kubernetes.\n\nO objetivo principal do Tiller podia ser alcançado sem o Tiller, então uma das\nprimeiras decisões que tomamos em relação ao Helm 3 foi remover completamente o\nTiller.\n\nCom o Tiller removido, o modelo de segurança do Helm foi radicalmente\nsimplificado. O Helm 3 agora suporta todos os recursos modernos de segurança,\nidentidade e autorização do Kubernetes moderno. As permissões do Helm são\navaliadas usando seu [arquivo\nkubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/).\nOs administradores de cluster podem restringir as permissões dos usuários na\ngranularidade que considerarem adequada. As releases ainda são registradas no\ncluster, e o restante da funcionalidade do Helm permanece inalterado.\n\n### Estratégia de Upgrade Aprimorada: 3-way Strategic Merge Patches\n\nO Helm 2 usava um patch de mesclagem estratégica de duas vias. Durante um\nupgrade, ele comparava o manifesto do chart mais recente com o manifesto do\nchart proposto (aquele fornecido durante o `helm upgrade`). Ele comparava as\ndiferenças entre esses dois charts para determinar quais mudanças precisavam ser\naplicadas aos recursos no Kubernetes. Se alterações fossem aplicadas ao cluster\nfora de banda (como durante um `kubectl edit`), essas alterações não eram\nconsideradas. Isso resultava em recursos que não conseguiam reverter para seu\nestado anterior: como o Helm considerava apenas o manifesto do último chart\naplicado como seu estado atual, se não houvesse mudanças no estado do chart, o\nestado ativo permanecia inalterado.\n\nNo Helm 3, agora usamos um patch de mesclagem estratégica de três vias. O Helm\nconsidera o manifesto antigo, seu estado ativo e o novo manifesto ao gerar um\npatch.\n\n#### Exemplos\n\nVamos examinar alguns exemplos comuns de como essa mudança impacta.\n\n##### Revertendo quando o estado ativo foi alterado\n\nSua equipe acabou de implantar a aplicação em produção no Kubernetes usando o\nHelm. O chart contém um objeto Deployment onde o número de réplicas está\nconfigurado como três:\n\n```console\n$ helm install myapp ./myapp\n```\n\nUm novo desenvolvedor entra na equipe. No primeiro dia, enquanto observa o\ncluster de produção, acontece um acidente com café derramado no teclado e ele\nacaba executando `kubectl scale` no deployment de produção, reduzindo de três\nréplicas para zero.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nOutro desenvolvedor da sua equipe percebe que o site de produção está fora do ar\ne decide reverter a release para seu estado anterior:\n\n```console\n$ helm rollback myapp\n```\n\nO que acontece?\n\nNo Helm 2, ele geraria um patch comparando o manifesto antigo com o novo\nmanifesto. Como é um rollback, é o mesmo manifesto. O Helm determinaria que não\nhá nada a mudar porque não há diferença entre o manifesto antigo e o novo\nmanifesto. A contagem de réplicas continua em zero. Pânico geral.\n\nNo Helm 3, o patch é gerado usando o manifesto antigo, o estado ativo e o novo\nmanifesto. O Helm reconhece que o estado antigo era três, o estado ativo é zero\ne o novo manifesto deseja alterá-lo de volta para três, então ele gera um patch\npara mudar o estado de volta para três.\n\n##### Upgrades quando o estado ativo foi alterado\n\nMuitas service meshes e outras aplicações baseadas em controllers injetam dados\nnos objetos do Kubernetes. Isso pode ser algo como um sidecar, labels ou outras\ninformações. Anteriormente, se você tivesse o seguinte manifesto renderizado a\npartir de um Chart:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nE o estado ativo fosse modificado por outra aplicação para\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nAgora, você quer atualizar a tag da imagem `nginx` para `2.1.0`. Então, você faz\nupgrade para um chart com o seguinte manifesto:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nO que acontece?\n\nNo Helm 2, o Helm gera um patch do objeto `containers` entre o manifesto antigo\ne o novo manifesto. O estado ativo do cluster não é considerado durante a\ngeração do patch.\n\nO estado ativo do cluster é modificado para ficar assim:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nO pod sidecar é removido do estado ativo. Mais pânico.\n\nNo Helm 3, o Helm gera um patch do objeto `containers` entre o manifesto antigo,\no estado ativo e o novo manifesto. Ele nota que o novo manifesto muda a tag da\nimagem para `2.1.0`, mas o estado ativo contém um container sidecar.\n\nO estado ativo do cluster é modificado para ficar assim:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### Nomes de Releases Agora Têm Escopo por Namespace\n\nCom a remoção do Tiller, as informações sobre cada release precisavam ser\narmazenadas em algum lugar. No Helm 2, isso era armazenado no mesmo namespace\nque o Tiller. Na prática, isso significava que uma vez que um nome era usado por\numa release, nenhuma outra release podia usar esse mesmo nome, mesmo se fosse\nimplantada em um namespace diferente.\n\nNo Helm 3, as informações sobre uma release específica agora são armazenadas no\nmesmo namespace que a própria release. Isso significa que os usuários agora\npodem executar `helm install wordpress stable/wordpress` em dois namespaces\nseparados, e cada um pode ser referenciado com `helm list` alterando o contexto\ndo namespace atual (por exemplo, `helm list --namespace foo`).\n\nCom esse maior alinhamento aos namespaces nativos do cluster, o comando `helm\nlist` não lista mais todas as releases por padrão. Em vez disso, ele listará\napenas as releases no namespace do seu contexto atual do Kubernetes (ou seja, o\nnamespace mostrado quando você executa `kubectl config view --minify`). Isso\ntambém significa que você deve fornecer a flag `--all-namespaces` ao `helm list`\npara obter um comportamento similar ao do Helm 2.\n\n### Secrets como Driver de Armazenamento Padrão\n\nNo Helm 3, Secrets agora são usados como o [driver de armazenamento\npadrão](/topics/advanced.md#storage-backends). O Helm 2 usava ConfigMaps por\npadrão para armazenar informações de releases. No Helm 2.7.0, um novo backend de\narmazenamento que usa Secrets para armazenar informações de releases foi\nimplementado, e agora é o padrão a partir do Helm 3.\n\nA mudança para Secrets como padrão no Helm 3 permite segurança adicional na\nproteção de charts em conjunto com o lançamento da criptografia de Secrets no\nKubernetes.\n\n[Criptografar secrets em\nrepouso](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)\ntornou-se disponível como um recurso alpha no Kubernetes 1.7 e se tornou estável\na partir do Kubernetes 1.13. Isso permite que os usuários criptografem os\nmetadados de releases do Helm em repouso, sendo um bom ponto de partida que pode\nser expandido posteriormente para usar algo como o Vault.\n\n### Mudanças no Caminho de Import do Go\n\nNo Helm 3, o Helm alterou o caminho de import do Go de `k8s.io/helm` para\n`helm.sh/helm/v3`. Se você pretende atualizar para as bibliotecas cliente do\nHelm 3 em Go, certifique-se de alterar seus caminhos de import.\n\n### Capabilities\n\nO objeto embutido `.Capabilities` disponível durante o estágio de renderização\nfoi simplificado.\n\n[Objetos Embutidos](/chart_template_guide/builtin_objects.md)\n\n### Validando Valores de Charts com JSONSchema\n\nUm JSON Schema agora pode ser imposto sobre os valores do chart. Isso garante\nque os valores fornecidos pelo usuário sigam o schema definido pelo mantenedor\ndo chart, fornecendo melhor relatório de erros quando o usuário fornece um\nconjunto incorreto de valores para um chart.\n\nA validação ocorre quando qualquer um dos seguintes comandos é invocado:\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\nConsulte a documentação sobre [Arquivos de Schema](/topics/charts.md#schema-files)\npara mais informações.\n\n### Consolidação do `requirements.yaml` no `Chart.yaml`\n\nO sistema de gerenciamento de dependências de Charts foi movido de\nrequirements.yaml e requirements.lock para Chart.yaml e Chart.lock.\nRecomendamos que novos charts destinados ao Helm 3 usem o novo formato. No\nentanto, o Helm 3 ainda entende a versão 1 da API de Chart (`v1`) e carregará\narquivos `requirements.yaml` existentes.\n\nNo Helm 2, era assim que um `requirements.yaml` se parecia:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nNo Helm 3, a dependência é expressa da mesma forma, mas agora a partir do seu\n`Chart.yaml`:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nOs charts ainda são baixados e colocados no diretório `charts/`, então subcharts\nincluídos no diretório `charts/` continuarão a funcionar sem modificação.\n\n### Nome (ou --generate-name) Agora é Obrigatório na Instalação\n\nNo Helm 2, se nenhum nome fosse fornecido, um nome gerado automaticamente seria\ndado. Em produção, isso provou ser mais um incômodo do que um recurso útil. No\nHelm 3, o Helm lançará um erro se nenhum nome for fornecido com `helm install`.\n\nPara aqueles que ainda desejam que um nome seja gerado automaticamente, você\npode usar a flag `--generate-name` para criar um para você.\n\n### Enviando Charts para Registries OCI\n\nEste é um recurso experimental introduzido no Helm 3. Para usar, defina a\nvariável de ambiente `HELM_EXPERIMENTAL_OCI=1`.\n\nDe forma geral, um Repositório de Charts é um local onde Charts podem ser\narmazenados e compartilhados. O cliente Helm empacota e envia Charts do Helm\npara um Repositório de Charts. Simplificando, um Repositório de Charts é um\nservidor HTTP básico que hospeda um arquivo index.yaml e alguns charts\nempacotados.\n\nEmbora haja vários benefícios na API do Repositório de Charts atender aos\nrequisitos de armazenamento mais básicos, algumas desvantagens começaram a\naparecer:\n\n- Repositórios de Charts têm muita dificuldade em abstrair a maioria das\n  implementações de segurança exigidas em um ambiente de produção. Ter uma API\n  padrão para autenticação e autorização é muito importante em cenários de\n  produção.\n- As ferramentas de proveniência de Charts do Helm usadas para assinar e\n  verificar a integridade e origem de um chart são uma parte opcional do\n  processo de publicação de Charts.\n- Em cenários multi-tenant, o mesmo Chart pode ser enviado por outro tenant,\n  custando o dobro do custo de armazenamento para armazenar o mesmo conteúdo.\n  Repositórios de charts mais inteligentes foram projetados para lidar com isso,\n  mas não faz parte da especificação formal.\n- Usar um único arquivo de índice para pesquisa, informações de metadados e\n  busca de Charts tornou difícil ou desajeitado projetar implementações\n  multi-tenant seguras.\n\nO projeto Distribution do Docker (também conhecido como Docker Registry v2) é o\nsucessor do projeto Docker Registry. Muitos grandes provedores de nuvem têm uma\noferta de produto do projeto Distribution, e com tantos fornecedores oferecendo\no mesmo produto, o projeto Distribution se beneficiou de muitos anos de\nhardening, melhores práticas de segurança e testes extensivos em produção.\n\nPor favor, consulte `helm help chart` e `helm help registry` para mais\ninformações sobre como empacotar um chart e enviá-lo para um registro Docker.\n\nPara mais informações, consulte [esta página](/topics/registries.md).\n\n### Remoção do `helm serve`\n\nO `helm serve` executava um Repositório de Charts local na sua máquina para fins\nde desenvolvimento. No entanto, ele não recebeu muita adoção como ferramenta de\ndesenvolvimento e tinha vários problemas com seu design. No final, decidimos\nremovê-lo e separá-lo como um plugin.\n\nPara uma experiência similar ao `helm serve`, dê uma olhada na opção de\narmazenamento em sistema de arquivos local no\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\ne no [plugin servecm](https://github.com/jdolitsky/helm-servecm).\n\n### Suporte a Library Charts\n\nO Helm 3 suporta uma classe de chart chamada \"library chart\". Este é um chart\nque é compartilhado por outros charts, mas não cria nenhum artefato de release\npróprio. Os templates de um library chart podem apenas declarar elementos\n`define`. Conteúdo de escopo global que não seja `define` é simplesmente\nignorado. Isso permite que os usuários reutilizem e compartilhem trechos de\ncódigo que podem ser reutilizados em muitos charts, evitando redundância e\nmantendo os charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nLibrary charts são declarados na diretiva dependencies no Chart.yaml e são\ninstalados e gerenciados como qualquer outro chart.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nEstamos muito empolgados em ver os casos de uso que esse recurso abre para\ndesenvolvedores de charts, bem como quaisquer melhores práticas que surjam do\nconsumo de library charts.\n\n### Atualização da apiVersion do Chart.yaml\n\nCom a introdução do suporte a library charts e a consolidação do\nrequirements.yaml no Chart.yaml, clientes que entendiam o formato de pacote do\nHelm 2 não entenderão esses novos recursos. Então, atualizamos a apiVersion no\nChart.yaml de `v1` para `v2`.\n\nO `helm create` agora cria charts usando este novo formato, então a apiVersion\npadrão também foi atualizada lá.\n\nClientes que desejam suportar ambas as versões de charts do Helm devem\ninspecionar o campo `apiVersion` no Chart.yaml para entender como analisar o\nformato do pacote.\n\n### Suporte ao XDG Base Directory\n\nA [Especificação XDG Base\nDirectory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)\né um padrão portável que define onde arquivos de configuração, dados e cache\ndevem ser armazenados no sistema de arquivos.\n\nNo Helm 2, o Helm armazenava todas essas informações em `~/.helm` (carinhosamente\nconhecido como `helm home`), que podia ser alterado definindo a variável de\nambiente `$HELM_HOME` ou usando a flag global `--home`.\n\nNo Helm 3, o Helm agora respeita as seguintes variáveis de ambiente conforme a\nEspecificação XDG Base Directory:\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nOs plugins do Helm ainda recebem `$HELM_HOME` como um alias para `$XDG_DATA_HOME`\npara compatibilidade com plugins que procuram usar `$HELM_HOME` como um ambiente\nde rascunho.\n\nVárias novas variáveis de ambiente também são passadas para o ambiente do plugin\npara acomodar essa mudança:\n\n- `$HELM_PATH_CACHE` para o caminho de cache\n- `$HELM_PATH_CONFIG` para o caminho de configuração\n- `$HELM_PATH_DATA` para o caminho de dados\n\nPlugins do Helm que desejam suportar o Helm 3 devem considerar o uso dessas\nnovas variáveis de ambiente.\n\n### Renomeação de Comandos CLI\n\nPara melhor alinhar a terminologia com outros gerenciadores de pacotes, `helm\ndelete` foi renomeado para `helm uninstall`. O `helm delete` ainda é mantido\ncomo um alias para `helm uninstall`, então qualquer uma das formas pode ser\nusada.\n\nNo Helm 2, para limpar o registro da release, a flag `--purge` precisava ser\nfornecida. Essa funcionalidade agora está habilitada por padrão. Para manter o\ncomportamento anterior, use `helm uninstall --keep-history`.\n\nAdicionalmente, vários outros comandos foram renomeados para acomodar as mesmas\nconvenções:\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\nEsses comandos também mantiveram seus verbos antigos como aliases, então você\npode continuar a usá-los em qualquer forma.\n\n### Criação Automática de Namespaces\n\nAo criar uma release em um namespace que não existe, o Helm 2 criava o\nnamespace. O Helm 3 segue o comportamento de outras ferramentas do Kubernetes e\nretorna um erro se o namespace não existir. O Helm 3 criará o namespace se você\nespecificar explicitamente a flag `--create-namespace`.\n\n### O que aconteceu com .Chart.ApiVersion?\n\nO Helm segue a convenção típica de CamelCasing, que é capitalizar um acrônimo.\nFizemos isso em outros lugares no código, como com\n`.Capabilities.APIVersions.Has`. No Helm v3, corrigimos `.Chart.ApiVersion` para\nseguir esse padrão, renomeando-o para `.Chart.APIVersion`.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: Instalação\nsidebar_position: 2\n---\n\n## Instalação\n\n### Por que não existem pacotes nativos do Helm para Fedora e outras distribuições Linux?\n\nO 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.\n\n### Por que vocês fornecem um script `curl ...|bash`?\n\nExiste 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\nNó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.\n\n### Como coloco os arquivos do cliente Helm em um local diferente dos padrões?\n\nO Helm usa a estrutura XDG para armazenar arquivos. Existem variáveis de ambiente que você pode usar para substituir esses locais:\n\n- `$XDG_CACHE_HOME`: define um local alternativo para armazenar arquivos em cache.\n- `$XDG_CONFIG_HOME`: define um local alternativo para armazenar a configuração do Helm.\n- `$XDG_DATA_HOME`: define um local alternativo para armazenar dados do Helm.\n\nNote que, se você tiver repositórios existentes, precisará adicioná-los novamente com `helm repo add...`.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: Solução de Problemas\nsidebar_position: 4\n---\n\n## Solução de Problemas\n\n### Estou recebendo um aviso sobre \"Unable to get an update from the 'stable' chart repository\"\n\nExecute `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.\n\nVocê pode executar o seguinte comando para corrigir o seu repositório:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nO mesmo vale para o repositório `incubator`, que tem um arquivo disponível em https://charts.helm.sh/incubator.\nVocê pode executar o seguinte comando para corrigi-lo:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Estou recebendo o aviso 'WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.'\n\nO antigo repositório de charts do Google foi substituído por um novo repositório de charts do Helm.\n\nExecute o seguinte comando para corrigir isso permanentemente:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nSe você receber um erro semelhante para o `incubator`, execute este comando:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### Quando adiciono um repositório Helm, recebo o erro 'Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available'\n\nOs 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). \nArquivos 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\n`helm repo add` não permitirá que você adicione as URLs antigas, a menos que especifique `--use-deprecated-repos`.\n\n### No GKE (Google Container Engine) recebo \"No SSH tunnels currently open\"\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nOutra variação da mensagem de erro é:\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nO problema é que o seu arquivo de configuração local do Kubernetes deve ter as credenciais corretas.\n\nQuando 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.\n\n### Após a migração do Helm 2, `helm list` mostra apenas algumas (ou nenhuma) das minhas releases\n\nProvavelmente 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:\n\n* usar o namespace atual no contexto ativo do Kubernetes (conforme mostrado pelo comando `kubectl config view --minify`),\n* especificar o namespace correto usando a flag `--namespace`/`-n`, ou\n* para o comando `helm list`, especificar a flag `--all-namespaces`/`-A`\n\nIsso se aplica a `helm ls`, `helm uninstall` e todos os outros comandos `helm` que referenciam uma release.\n\n\n### No macOS, o arquivo `/etc/.mdns_debug` é acessado. Por quê?\n\nTemos 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.\n\nIsso é 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.\n\nSe 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.\n\nEsse 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.\n\n### helm repo add falha quando funcionava antes\n\nNo Helm 3.3.1 e anteriores, o comando `helm repo add <reponame> <url>` 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.\n\nNo Helm 3.3.2 e posteriores, uma tentativa de adicionar um repositório existente resultará em erro:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nO comportamento padrão agora é invertido. `--no-update` agora é ignorado, enquanto se você quiser substituir (sobrescrever) um repositório existente, você pode usar `--force-update`.\n\nEssa 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).\n\n### Habilitando logs do cliente Kubernetes\n\nA 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.\n\nPor exemplo:\n\n```\nhelm list -v 6\n```\n\n### Instalações do Tiller pararam de funcionar e o acesso é negado\n\nAs releases do Helm costumavam estar disponíveis em <https://storage.googleapis.com/kubernetes-helm/>. 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.\n\n\nSe 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:\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\nO [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:\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\npor:\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nPara inicializar com o Helm v2.17.0:\n\n`helm init —upgrade`\n\nOu 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:\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**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.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: Desinstalação\nsidebar_position: 3\n---\n\n## Desinstalação\n\n### Quero remover minha instalação local do Helm. Onde estão todos os seus arquivos?\n\nAlém do binário `helm`, o Helm armazena alguns arquivos nos seguintes locais:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nA tabela a seguir mostra a pasta padrão para cada um desses locais, por sistema operacional:\n\n| Sistema Operacional | Caminho do Cache            | Caminho de Configuração          | Caminho de Dados          |\n|---------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux               | `$HOME/.cache/helm `        | `$HOME/.config/helm `            | `$HOME/.local/share/helm` |\n| macOS               | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm `     |\n| Windows             | `%TEMP%\\helm  `             | `%APPDATA%\\helm `                | `%APPDATA%\\helm`          |\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/glossary/index.mdx",
    "content": "---\ntitle: Glossário\ndescription: Termos utilizados para descrever a arquitetura do Helm.\nsidebar_position: 9\n---\n\n# Glossário\n\n## Chart\n\nÉ um pacote Helm que contém as informações necessárias para instalar\numa série de recursos e manifestos do Kubernetes em um cluster.\n\nOs Charts contém um arquivo `Chart.yaml` bem como _templates_ dos manifestos,\nvalores padrão (`values.yaml`), e outras dependêncas.\n\nOs Charts são desenvolvidos dentro de uma estrutura de diretório bem definida,\ne depois empacotados em um formato de arquivo chamado _chart archive_.\n\n## Chart Archive\n\nUm _chart archive_ é um Chart compactado, em tar e gzip, (e opcionalmente\nassinado).\n\n## Dependência de Charts (Subcharts)\n\nCharts podem depender de outros Charts. Há duas maneiras que dependência de Charts\npodem ocorrer:\n\n- _Soft dependency_: Um Chart pode não funcionar se um outro Chart não estiver instalado\n  no cluster. O Helm não fornece ferramental para resolver esse caso. Nesse\n  cenário as dependências são gerenciadas separadamente.\n- _Hard dependency_: Um Chart pode conter (dentro do diretório `charts/`)\n  outro Chart no qual seja dependente. Nesse caso, ao instalar o Chart também\n  será instalado todas as suas dependências. Os Charts e suas dependências são gerenciadas\n  como uma coleção.\n\nQuando um Chart é empacotado (via `helm package`) todas as suas\n_hard dependencies_ são agrupadas com ele.\n\n## Versão do Chart\n\nCharts são versionados de acordo com as [especificações da SemVer 2](https://semver.org).\nUm número de versão é necessário para cada Chart.\n\n## Chart.yaml\n\nInformações sobre o Chart são armazenadas num arquivo específico chamado `Chart.yaml`.\nCada Chart deve ter esse arquivo.\n\n## Helm (e o cliente helm)\n\nHelm é o gerenciador de pacotes para o Kubernetes. Assim como gerenciadores de\npacotes facilitam a instalação de ferramentas para sistemas operacionais, o Helm\nfacilita a instalação de aplicações nos clusters Kubernetes.\n\nEnquanto _Helm_ (em maiúsculo) é o nome do projeto, a ferramenta de linha de comando\ntambém se chama `helm`. Por convenção utiliza-se _Helm_ em maiúsculo ao falar do\nprojeto. Quando se faz referência ao cliente utiliza-se _helm_ em mínusculo.\n\n## Arquivos de configuração do Helm (XDG)\n\nO Helm armazena suas configurações em arquivos de diretórios XDG. Esses diretórios\nsão criados quando o `helm` é executado pela primeira vez.\n\n## Kube Config (KUBECONFIG)\n\nO cliente helm tenta encontrar as configurações do cluster Kubernetes utilizando\ncomo base o arquivo no formato _Kube config_. Por padrão o helm tentará localizá-lo\nno mesmo local que o `kubectl` o cria (`$HOME/.kube/config`).\n\n## Lint (Formatação de Charts)\n\nFormatar um Chart significa validar se este segue as converções e requerimentos\npadrões de um Chart do Helm. O Helm tem ferramentas de formatação através do comando\n`helm lint`.\n\n## Linhagem (Arquivo de Linhagem)\n\nOs Charts Helm podem ser acompanhados de _arquivos de linhagem_ o qual provêm informações\na cerca da origem do Chart e o que ele contém.\n\nArquivos de Linhagem fazem parte do histórico de segurança do Helm. Uma linhagem\ncontém um hash criptografado do arquivo _chart archive_, dados do Chart.yaml, e,\num bloco de assinatura (um bloco \"clearsign\" OpenPGP). Quando utilizados em conjuto\ncom uma chave habilita o usuário a:\n\n- Validar se o Chart foi assinado por uma entidade acreditada\n- Validar se o arquivo do Chart não foi modificado\n- Validar o conteúdo dos metadados do Chart (`Chart.yaml`)\n- Correlacionar rapidamente o Chart com os seus dados de linhagem\n\nArquivos de linhagem tem a extensão `.prov`, e podem ser servidos a partir de um\n_repositório de Charts_ ou qualquer outro servidor HTTP.\n\n## Release\n\nQuando um Chart é instalado, a biblioteca do Helm cria uma _release_  para monitorar\naquela instalação em particular.\n\nUm mesmo Chart pode ser instalado diversas vezes em um mesmo cluster e criar _releases_\ndiferentes. Por exemplo, uma pessoa pode instalar três bancos de dados PostgreSQL,\na partir de um mesmo Chart, rodando o comando `helm install` três vezes com diferentes\nnomes para cada _release_.\n\n## Número da _Release_ (Versão da _Release_)\n\nUma única _release_  pode ser atualizada diversas vezes. Um contador sequencial\né utilizado para monitorar as alterações da _release_. Após o primerio `helm install`\ndo Chart, a _release_ terá um número de _release_ igual a 1. A cada vez que uma release\nfor atualizada ou regredida, a versão da release será **incrementada**.\n\n## Regressão (Rollback)\n\nUma _release_ pode ser atualizada para uma nova configuração do chart. Contudo é\npossível regredir a uma versão anterior da release, uma vez que o histórico de\n_releases_ é armazenado. Essa operação é realizada com o comando `helm rollback`.\n\nImportante: uma _release_ regredida recebe um novo número de _release_.\n\n| Operação   | Número da Release                                    |\n|------------|------------------------------------------------------|\n| install    | release 1                                            |\n| upgrade    | release 2                                            |\n| upgrade    | release 3                                            |\n| rollback 1 | release 4 (mantendo a configuração da release 1)     |\n\nA tabela acima ilustra como as versões de release são incrementadas entre as\noperações de instalação, atualização e regressão.\n\n## Biblioteca do Helm (SDK)\n\nA biblioteca do Helm (SDK) refere-se ao código em Go que interage diretamente com\no API Server do Kubernetes para instalar, atualizar, buscar e remover recursos\ndo Kubernetes. Ela pode ser importada em um projeto para utilizar o Helm como cliente\nao invés da CLI.\n\n## Repositório (Repo, Repositório de Charts)\n\nOs Charts do Helm podem ser armazenados em servidores dedicados HTTP chamados\n_repositório de Charts_ (_repositórios_, ou somente _repos_).\n\nUm repositório de Charts é simplesmente um servidor HTTP que retorna um arquivo `index.yaml`\no qual descreve um grupo de Charts e identifica onde cada Chart pode ser baixado.\n(Muitos repositórios também hospedam os Charts para serem baixados, além do arquivo\n`index.yaml`.)\n\nO cliente helm pode apontar para zero ou mais repositórios de Charts. Por padrão\no cliente helm não é pré-configurado com nenhum repositório. Um repositório pode\nser adicionado a qualquer momento através do comando `helm repo add`.\n\n## Valores de Configuração (values.yaml)\n\nValores de configuração são uma forma de sobrescrever valores padrão dos templates\ncom seu próprio conteúdo.\n\nOs Charts do Helm são \"parametrizados\", o que significa dizer que um desenvolvedor\npode expôr configurações padrão que podem ser sobrescritas durante a instalação.\nPor exemplo, um chart pode expôr o campo `username` que permite configurar um nome\nde usuário para um serviço.\n\nEssas variáveis expostas são chamados de _values_ no linguajar do Helm.\n\nOs valores podem ser configurados durante as operações de `helm install` e\n`helm upgrade`, tanto passando-as diretamente como argumentos de linha de comando,\nou, usando um arquivo `values.yaml`.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/_category_.json",
    "content": "{\n  \"link\": { \"type\": \"doc\", \"id\": \"helm-category\" }\n}\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\nO gerenciador de pacotes para o Kubernetes.\n\n### Sinopse\n\nO gerenciador de pacotes para o Kubernetes.\n\nComandos comuns para o Helm:\n\n- helm search:    busca por charts\n- helm pull:      baixa um chart em seu diretório local para visualização\n- helm install:   aplica um chart no Kubernetes\n- helm list:      lista as _releases_ dos charts\n\nVariáveis de ambiente:\n\n| Nome                               | Descrição                                                                                                       |\n|------------------------------------|-----------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | configura um local alternativo para armazenamento dos arquivos de cache.                                        |\n| $HELM_CONFIG_HOME                  | configura um local alternativo para armazenamento das configurações do Helm.                                    |\n| $HELM_DATA_HOME                    | configura um local alternativo para armazenamento dos dados do Helm.                                            |\n| $HELM_DEBUG                        | indica se o Helm rodará ou não em modo debug.                                                                   |\n| $HELM_DRIVER                       | configura o driver de armazenamento backend. Valores: configmap, secret, memory, sql.                           |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | configura a string de conexão a ser utilizada pelo driver de armazenamento SQL.                                 |\n| $HELM_MAX_HISTORY                  | configura o número máximo de _releases_ armazenadas no histórico do Helm.                                       |\n| $HELM_NAMESPACE                    | configura o namespace usado para as operações do Helm.                                                          |\n| $HELM_NO_PLUGINS                   | desabilita os plugins. Configure HELM_NO_PLUGINS=1 para desabilitar os plugins.                                 |\n| $HELM_PLUGINS                      | configura o caminho para o diretório dos plugins.                                                               |\n| $HELM_REGISTRY_CONFIG              | configura o caminho para o arquivo de configuração do registry.                                                 |\n| $HELM_REPOSITORY_CACHE             | configura o caminho para o diretório de cache do repositório.                                                   |\n| $HELM_REPOSITORY_CONFIG            | configura o caminho para o arquivo de repositórios.                                                             |\n| $KUBECONFIG                        | configura um arquivo de configuração alternativo para o Kubernetes (padrão \"~/.kube/config\").                   |\n| $HELM_KUBEAPISERVER                | configura o endpoint do Kubernetes API Server para autenticação.                                                |\n| $HELM_KUBECAFILE                   | configura o arquivo de autoridade certificadora do Kubernetes.                                                  |\n| $HELM_KUBEASGROUPS                 | configura os grupos para impersonação, sendo esta uma lista separada por vírgula.                               |\n| $HELM_KUBEASUSER                   | configura o nome de usuário para impersonação da operação.                                                      |\n| $HELM_KUBECONTEXT                  | configura o nome do contexto do kubeconfig.                                                                     |\n| $HELM_KUBETOKEN                    | configura o Bearer KubeToken usado para autenticação.                                                           |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indica se a validação do certificado do Kubernetes API server deve ser ignorada (inseguro).                     |\n| $HELM_KUBETLS_SERVER_NAME          | configura o nome do servidor usado para validar o certificado do Kubernetes API server.                         |\n| $HELM_BURST_LIMIT                  | configura o limite de burst padrão caso o servidor contenha muitos CRDs (padrão 100, -1 para desabilitar).      |\n| $HELM_QPS                          | configura as Queries Por Segundo para casos onde muitas chamadas excedem a opção para valores de burst maiores. |\n\nO Helm armazena arquivos de cache, configuração, e dados de acordo com a seguinte ordem:\n\n- Se uma variável de ambiente HELM_*_HOME é configurada, ela será utilizada.\n- Caso contrário, em sistemas que suportam a especificação de diretório XDG, as variáveis XDG serão utilizadas.\n- Quando nenhum outro local é configurado, será utilizado um caminho padrão baseado no sistema operacional.\n\nPor padrão, os diretórios dependem do Sistema Operacional. Abaixo seguem os caminhos padrão:\n\n| Sistema Operacional | Caminho do Cache          | Caminho de Configuração        | Caminho para os Dados     |\n|---------------------|---------------------------|--------------------------------|---------------------------|\n| Linux               | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm   |\n| macOS               | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm        |\n| Windows             | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm            |\n\n\n### Opções\n\n```\n      --burst-limit int                 limite de throttling padrão no lado do cliente (padrão 100)\n      --debug                           habilita saída verbosa\n  -h, --help                            exibe ajuda para o helm\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo para impersonação da operação, esse argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário para impersonação da operação\n      --kube-ca-file string             arquivo de autoridade certificadora para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --kube-insecure-skip-tls-verify   se verdadeiro, o certificado do Kubernetes API server não será validado. Isso tornará suas conexões HTTPS inseguras\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                namespace para essa requisição\n      --qps float32                     queries por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm completion](/helm/helm_completion.md)\t - gera scripts de autocompletar para o shell especificado\n* [helm create](/helm/helm_create.md)\t - cria um novo chart com o nome fornecido\n* [helm dependency](/helm/helm_dependency.md)\t - gerencia as dependências de um chart\n* [helm env](/helm/helm_env.md)\t - informações do ambiente do cliente Helm\n* [helm get](/helm/helm_get.md)\t - obtém informações estendidas de uma _release_\n* [helm history](/helm/helm_history.md)\t - obtém o histórico de uma _release_\n* [helm install](/helm/helm_install.md)\t - instala um chart\n* [helm lint](/helm/helm_lint.md)\t - examina um chart em busca de possíveis problemas\n* [helm list](/helm/helm_list.md)\t - lista _releases_\n* [helm package](/helm/helm_package.md)\t - empacota um diretório de chart em um chart archive\n* [helm plugin](/helm/helm_plugin.md)\t - instala, lista ou desinstala plugins do Helm\n* [helm pull](/helm/helm_pull.md)\t - baixa um chart de um repositório e (opcionalmente) descompacta em um diretório local\n* [helm push](/helm/helm_push.md)\t - envia um chart para um registry remoto\n* [helm registry](/helm/helm_registry.md)\t - faz login ou logout de um registry\n* [helm repo](/helm/helm_repo.md)\t - adiciona, lista, remove, atualiza e indexa repositórios de charts\n* [helm rollback](/helm/helm_rollback.md)\t - reverte uma _release_ para uma revisão anterior\n* [helm search](/helm/helm_search.md)\t - busca por uma palavra-chave em charts\n* [helm show](/helm/helm_show.md)\t - exibe informações de um chart\n* [helm status](/helm/helm_status.md)\t - exibe o status de uma _release_\n* [helm template](/helm/helm_template.md)\t - renderiza templates localmente\n* [helm test](/helm/helm_test.md)\t - executa os testes de uma _release_\n* [helm uninstall](/helm/helm_uninstall.md)\t - desinstala uma _release_\n* [helm upgrade](/helm/helm_upgrade.md)\t - atualiza uma _release_\n* [helm verify](/helm/helm_verify.md)\t - verifica se um chart em um dado caminho foi assinado e é válido\n* [helm version](/helm/helm_version.md)\t - exibe informações sobre a versão do cliente\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\nGera scripts de preenchimento automático para o shell especificado\n\n### Sinopse\n\nGera scripts de preenchimento automático do Helm para o shell especificado.\n\n\n### Opções\n\n```\n  -h, --help   ajuda para o completion\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a ser representado para a operação, esse argumento pode ser repetido para especificar múltiplos grupos\n      --kube-as-user string             usuário a ser representado para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --kube-insecure-skip-tls-verify   se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo do namespace para essa requisição\n      --qps float32                     consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices do repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs dos repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm](helm.md)\t - Helm, o gerenciador de pacotes para o Kubernetes.\n* [helm completion bash](helm_completion_bash.md)\t - gera o script de preenchimento automático para o bash\n* [helm completion fish](helm_completion_fish.md)\t - gera o script de preenchimento automático para o fish\n* [helm completion powershell](helm_completion_powershell.md)\t - gera o script de preenchimento automático para o powershell\n* [helm completion zsh](helm_completion_zsh.md)\t - gera o script de preenchimento automático para o zsh\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\nGera o script de preenchimento automático para o bash\n\n### Sinopse\n\nGera o script de preenchimento automático do Helm para o bash shell.\n\nPara carregar o preenchimento automático na sessão atual do shell:\n\n    source <(helm completion bash)\n\nPara carregar o preenchimento automático para cada nova sessão, execute uma vez:\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n\n```\nhelm completion bash [flags]\n```\n\n### Opções\n\n```\n  -h, --help              ajuda para o bash\n      --no-descriptions   desabilita descrições do preenchimento automático\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a ser representado para a operação, esse argumento pode ser repetido para especificar múltiplos grupos\n      --kube-as-user string             usuário a ser representado para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --kube-insecure-skip-tls-verify   se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo do namespace para essa requisição\n      --qps float32                     consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices do repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs dos repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm completion](helm_completion.md)\t - gera scripts de preenchimento automático para o shell especificado\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\nGera scripts de preenchimento automático para o fish\n\n### Sinopse\n\nGera scripts de preenchimento automático do Helm para o fish shell.\n\nPara carregar o script de preenchimento automático na sessão ativa do fish:\n\n    helm completion fish | source\n\nPara carregar o script para cada nova sessão, execute uma vez:\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\nSerá necessário iniciar um novo shell para que as modificações tenham efeito.\n\n\n```\nhelm completion fish [flags]\n```\n\n### Opções\n\n```\n  -h, --help              ajuda para o preenchimento automático do fish\n      --no-descriptions   desabilita descrições do preenchimento automático\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           exibe uma saída verbosa\n      --kube-apiserver string           o endereço e porta do Kubernetes API server\n      --kube-as-group stringArray       o grupo que representará essa operação, esse argumento pode ser repetido para indicar múltiplos grupos\n      --kube-as-user string             o usuário que representará essa operação\n      --kube-ca-file string             caminho para o certificado para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --kube-insecure-skip-tls-verify   se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso torna suas conexões HTTPS inseguras\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                namespace para essa requisição\n      --qps float32                     consultas por segundo usadas na comunicação com a API do Kubernetes, sem incluir bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm completion](helm_completion.md)\t - gera scripts de preenchimento automático para um shell específico\n\n###### Gerado automaticamente pelo spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\nGera o script de preenchimento automático para o powershell\n\n### Sinopse\n\nGera o script de preenchimento automático para o powershell.\n\nPara carregar o preenchimento automático na sessão atual do shell:\n\n    PS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\nPara carregar o preenchimento automático para cada nova sessão, adicione a saída do\ncomando acima ao seu perfil do powershell.\n\n\n```\nhelm completion powershell [flags]\n```\n\n### Opções\n\n```\n  -h, --help              ajuda para o powershell\n      --no-descriptions   desabilita descrições do preenchimento automático\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a ser representado para a operação, esse argumento pode ser repetido para especificar múltiplos grupos\n      --kube-as-user string             usuário a ser representado para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --kube-insecure-skip-tls-verify   se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo do namespace para essa requisição\n      --qps float32                     consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices do repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs dos repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm completion](helm_completion.md)\t - gera scripts de preenchimento automático para o shell especificado\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\nGera o script de preenchimento automático para o zsh\n\n### Sinopse\n\nGera o script de preenchimento automático do Helm para o zsh shell.\n\nPara carregar o preenchimento automático na sessão atual do shell:\n\n    source <(helm completion zsh)\n\nPara carregar o preenchimento automático para cada nova sessão, execute uma vez:\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### Opções\n\n```\n  -h, --help              ajuda para o zsh\n      --no-descriptions   desabilita descrições do preenchimento automático\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a ser representado para a operação, esse argumento pode ser repetido para especificar múltiplos grupos\n      --kube-as-user string             usuário a ser representado para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --kube-insecure-skip-tls-verify   se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo do namespace para essa requisição\n      --qps float32                     consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices do repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs dos repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm completion](helm_completion.md)\t - gera scripts de preenchimento automático para o shell especificado\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\nCria um novo Chart com um dado nome\n\n### Sinopse\n\nEsse comando cria um diretório para o Chart, bem como os arquivos comuns\nnecessários para o Chart.\n\nPor exemplo, `helm create foo` criará uma estrutura de diretório como:\n\n    foo/\n    ├── .helmignore   # Descreve os arquivos a serem ignorados durante o empacotamento do Chart.\n    ├── Chart.yaml    # Informação sobre o seu Chart\n    ├── values.yaml   # Valores padrão para os seus templates\n    ├── charts/       # Charts que este Chart depende\n    └── templates/    # Arquivos de template: deployment, service e outros manifestos\n        └── tests/    # Arquivos de teste\n\n`helm create` cria um diretório a partir do argumento passado. Se o diretório não\nexistir o helm tentará criá-lo. Se o destino já existir e tiver arquivos dentro\ndo diretório, os arquivos conflitantes serão sobrescritos e os demais serão mantidos.\n```\nhelm create NOME [argumentos]\n```\n\n### Opções\n\n```\n  -h, --help             ajuda para criação do Chart\n  -p, --starter string   nome ou caminho absoluto para a base inicial do Helm\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de requisições do lado do cliente (default 100)\n      --debug                       exibe uma saída verbosa\n      --kube-apiserver string       o endereço e porta do Kubernetes API server\n      --kube-as-group stringArray   o grupo que representará essa operação, esse argumento pode ser repetido para indicar múltiplos grupos\n      --kube-as-user string         o usuário que representará essa operação\n      --kube-ca-file string         caminho para o certificado para conexão com o Kubernetes API server\n      --kube-context string         nome do contexto do kubeconfig a ser usado\n      --kube-insecure-skip-tls-verify   se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras\n      --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\n      --kube-token string           bearer token usado para autenticação\n      --kubeconfig string           caminho para o arquivo kubeconfig\n  -n, --namespace string            namespace para essa requisição\n      --qps float32                     consultas por segundo usadas na comunicação com a Kubernetes API, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string     caminho para os índices \"cacheados\" no repositório (default \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs dos repositórios (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](/helm/helm.md) - Helm, o gerenciador de pacotes para o Kubernetes."
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\nGerencia as dependências de um chart\n\n### Sinopse\n\n\nGerencia as dependências de um chart.\n\nOs charts do Helm armazenam suas dependências em 'charts/'. Para desenvolvedores de charts,\ngeralmente é mais fácil gerenciar dependências em 'Chart.yaml', que declara todas\nas dependências.\n\nOs comandos de dependência operam nesse arquivo, facilitando a sincronização\nentre as dependências desejadas e as dependências reais armazenadas no\ndiretório 'charts/'.\n\nPor exemplo, este Chart.yaml declara duas dependências:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\nO 'name' deve ser o nome de um chart, que deve corresponder ao nome\nno arquivo 'Chart.yaml' desse chart.\n\nO campo 'version' deve conter uma versão semântica ou um intervalo de versões.\n\nA URL 'repository' deve apontar para um repositório de charts. O Helm espera que,\nao adicionar '/index.yaml' à URL, seja possível obter o índice do repositório\nde charts. Nota: 'repository' pode ser um alias. O alias deve começar\ncom 'alias:' ou '@'.\n\nA partir da versão 2.2.0, o repository pode ser definido como o caminho para o diretório\ndos charts de dependência armazenados localmente. O caminho deve começar com um prefixo\n\"file://\". Por exemplo,\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\nSe o chart de dependência for obtido localmente, não é necessário ter o\nrepositório adicionado ao helm por \"helm add repo\". A correspondência de versão também\né suportada neste caso.\n\n\n### Opções\n\n```\n  -h, --help   help for dependency\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm](/helm/helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n* [helm dependency build](/helm/helm_dependency_build.md)\t - reconstrói o diretório charts/ com base no arquivo Chart.lock\n* [helm dependency list](/helm/helm_dependency_list.md)\t - lista as dependências para o chart especificado\n* [helm dependency update](/helm/helm_dependency_update.md)\t - atualiza charts/ com base no conteúdo de Chart.yaml\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\nReconstrói o diretório charts/ com base no arquivo Chart.lock\n\n### Sinopse\n\n\nConstrói o diretório charts/ a partir do arquivo Chart.lock.\n\nBuild é usado para reconstruir as dependências de um chart para o estado especificado\nno arquivo de lock. Isso não renegocia as dependências, ao contrário de 'helm dependency update'.\n\nSe nenhum arquivo de lock for encontrado, 'helm dependency build' irá espelhar o comportamento\nde 'helm dependency update'.\n\n\n```\nhelm dependency build CHART [flags]\n```\n\n### Opções\n\n```\n      --ca-file string             verifica certificados de servidores habilitados para HTTPS usando este pacote CA\n      --cert-file string           identifica cliente HTTPS usando este arquivo de certificado SSL\n  -h, --help                       ajuda para build\n      --insecure-skip-tls-verify   ignora verificações de certificado tls para o download do chart\n      --key-file string            identifica cliente HTTPS usando este arquivo de chave SSL\n      --keyring string             keyring contendo chaves públicas (padrão \"~/.gnupg/pubring.gpg\")\n      --password string            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                 usa conexões HTTP inseguras para o download do chart\n      --skip-refresh               não atualiza o cache local do repositório\n      --username string            nome de usuário do repositório de charts onde localizar o chart solicitado\n      --verify                     verifica os pacotes contra assinaturas\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm dependency](/helm/helm_dependency.md)\t - gerencia as dependências de um chart\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\nLista as dependências de um chart especificado\n\n### Sinopse\n\n\nLista todas as dependências declaradas em um chart.\n\nEste comando aceita pacotes de chart e diretórios de chart como entrada. Ele não\naltera o conteúdo de um chart.\n\nSerá retornado um erro se o chart não puder ser carregado.\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### Opções\n\n```\n  -h, --help                 ajuda para list\n      --max-col-width uint   largura máxima da coluna para tabela de saída (padrão 80)\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm dependency](./helm_dependency.md)\t - gerencia as dependências de um chart\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\nAtualiza charts/ com base no conteúdo de Chart.yaml\n\n### Sinopse\n\n\nAtualiza as dependências locais para corresponder ao Chart.yaml.\n\nEste comando verifica que os charts necessários, conforme expressos em 'Chart.yaml',\nestão presentes em 'charts/' e em versões aceitáveis. Ele baixará\nos charts mais recentes que atendam às dependências e removerá dependências antigas.\n\nEm uma atualização bem-sucedida, isso gerará um arquivo de lock que pode ser usado para\nreconstruir as dependências em uma versão exata.\n\nAs dependências não precisam estar representadas em 'Chart.yaml'. Por isso,\num comando de atualização não removerá charts a menos que eles estejam presentes\nno arquivo Chart.yaml, mas em uma versão incorreta.\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### Opções\n\n```\n      --ca-file string             verifica certificados de servidores habilitados para HTTPS usando este pacote CA\n      --cert-file string           identifica cliente HTTPS usando este arquivo de certificado SSL\n  -h, --help                       ajuda para update\n      --insecure-skip-tls-verify   ignora verificações de certificado tls para o download do chart\n      --key-file string            identifica cliente HTTPS usando este arquivo de chave SSL\n      --keyring string             keyring contendo chaves públicas (padrão \"~/.gnupg/pubring.gpg\")\n      --password string            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                 usa conexões HTTP inseguras para o download do chart\n      --skip-refresh               não atualiza o cache local do repositório\n      --username string            nome de usuário do repositório de charts onde localizar o chart solicitado\n      --verify                     verifica os pacotes contra assinaturas\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm dependency](/helm/helm_dependency.md)\t - gerencia as dependências de um chart\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\nInformações do ambiente do cliente Helm\n\n### Sinopse\n\nEsse comando exibe todas as informações de ambiente utilizadas pelo Helm.\n\n\n```\nhelm env [flags]\n```\n\n### Opções\n\n```\n  -h, --help   ajuda para o comando env\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](./helm.md) - Helm, o gerenciador de pacotes para o Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\nBaixa informações adicionais de uma dada _release_\n\n### Sinopse\n\nEsse comando consiste em múltiplos subcomandos utilizados para recuperar informações\nadicionais sobre uma dada _release_, incluindo:\n\n- Os valores utilizados para gerar a _release_\n- O arquivo de manifesto gerado\n- As notas advindas do Chart da _release_\n- Os _hooks_ associados a uma _release_\n- Os metadados da _release_\n\n\n### Opções\n\n```\n  -h, --help   ajuda para o comando get\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](./helm.md) - Helm, o gerenciador de pacotes para o Kubernetes.\n* [helm get all](./helm_get_all.md) - baixa todas as informações de uma dada _release_\n* [helm get hooks](./helm_get_hooks.md) - baixa todos os _hooks_ de uma dada _release_\n* [helm get manifest](./helm_get_manifest.md) - baixa o manifesto de uma dada _release_\n* [helm get metadata](./helm_get_metadata.md) - busca os metadados de uma dada release\n* [helm get notes](./helm_get_notes.md) - baixa as notas de uma dada _release_\n* [helm get values](./helm_get_values.md) - baixa o arquivo de valores de uma dada _release_\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\nBaixa toda informação sobre uma dada _release_\n\n### Sinopse\n\nEsse comando exibe um conjunto de informações, legíveis para o ser humano, sobre\nas notas, _hooks_, valores passados e o manifesto gerado para uma dada _release_.\n\n\n```\nhelm get all NOME_DA_RELEASE [argumentos]\n```\n\n### Opções\n\n```\n  -h, --help              ajuda para o comando all\n      --revision int      recupera uma revisão específica de uma release\n      --template string   template em go para formatar a saída do comando, ex: {{.Release.Name}}\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm get](./helm_get.md) - baixa informações adicionais de uma dada release\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\nBaixa todos os _hooks_ de uma dada _release_\n\n### Sinopse\n\nEsse comando baixa os _hooks_ de uma dada _release_.\n\n_Hooks_ são formatados em YAML e separados pelo separador YAML '---\\n'.\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Opções\n\n```\n  -h, --help           ajuda para hooks\n      --revision int   recupera a release nomeada com a revisão especificada\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string           bearer token usado para autenticação\n      --kubeconfig string           caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\nBaixa o manifesto de uma dada _release_\n\n### Sinopse\n\nEsse comando recupera o manifesto gerado de uma dada _release_.\n\nUm manifesto é a representação dos recursos do Kubernetes em um arquivo YAML, o qual\nfoi gerado a partir do(s) chart(s) da _release_ em questão. Se o chart depender de outros\ncharts, os recursos Kubernetes das dependências também serão incluídos no manifesto.\n\n\n```\nhelm get manifest NOME_DA_RELEASE [argumentos]\n```\n\n### Opções\n\n```\n  -h, --help           ajuda para recuperar um manifesto\n      --revision int   recupera uma revisão específica de uma release\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\nRecupera os metadados de uma dada _release_\n\n### Sinopse\n\nEsse comando recupera os metadados de uma dada _release_.\n\n```\nhelm get metadata NOME_DA_RELEASE [argumentos]\n```\n\n### Opções\n\n```\n  -h, --help            ajuda para metadata\n  -o, --output format   exibe a saída em um formato específico. Formatos: table, json, yaml (padrão table)\n      --revision int    especifica a revisão da release\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\nBaixa as notas de uma dada _release_\n\n### Sinopse\n\nEsse comando exibe as notas fornecidas pelo chart de uma dada _release_.\n\n```\nhelm get notes NOME_DA_RELEASE [argumentos]\n```\n\n### Opções\n\n```\n  -h, --help           ajuda para recuperar as notas\n      --revision int   recupera uma revisão específica de uma release\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\nBaixa o arquivo com os valores de uma dada _release_\n\n### Sinopse\n\nEsse comando recupera o arquivo com os valores utilizados em uma dada _release_.\n\n```\nhelm get values NOME_DA_RELEASE [argumentos]\n```\n\n### Opções\n\n```\n  -a, --all             exibe todos os valores (computados)\n  -h, --help            ajuda para recuperar os valores\n  -o, --output format   exibe a saída em um formato específico. Formatos: table, json, yaml (padrão table)\n      --revision int    recupera uma revisão específica de uma release\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string           bearer token usado para autenticação\n      --kubeconfig string           caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\nExibe o histórico de revisões de uma release\n\n### Sinopse\n\nEsse comando imprime as revisões históricas de uma determinada release.\n\nPor padrão, serão retornadas no máximo 256 revisões. Utilize o argumento '--max'\npara configurar o comprimento máximo da lista de revisões retornada.\n\nO histórico de releases é exibido como uma tabela formatada, por exemplo:\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### Opções\n\n```\n  -h, --help            exibe ajuda para o comando history\n      --max int         número máximo de revisões a incluir no histórico (padrão 256)\n  -o, --output format   exibe a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table)\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída verbosa\n      --kube-apiserver string           o endereço e porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, esse argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             usuário a representar para a operação\n      --kube-ca-file string             arquivo de autoridade de certificado para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo do namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositórios em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](/helm/helm.md)\t - O gerenciador de pacotes Helm para o Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\nInstala um chart\n\n### Sinopse\n\n\nEsse comando instala um chart archive.\n\nO argumento de instalação deve ser uma referência a um chart, um caminho para\num chart empacotado, um caminho para um diretório de chart descompactado ou uma URL.\n\nPara sobrescrever valores em um chart, use o argumento `--values` indicando um arquivo\nou use o argumento `--set` passando configurações pela linha de comando. Para forçar\num valor no formato string use `--set-string`. Você pode usar `--set-file` para definir\nvalores individuais a partir de um arquivo quando o valor é muito longo para a linha\nde comando ou é gerado dinamicamente. Você também pode usar `--set-json` para definir\nvalores JSON (valores escalares, objetos ou arrays) pela linha de comando.\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\nou\n\n    $ helm install --set name=prod myredis ./redis\n\nou\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\nou\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\nou\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\nVocê pode especificar o argumento `--values`/`-f` várias vezes. A prioridade será dada ao\núltimo arquivo especificado (mais à direita). Por exemplo, se tanto myvalues.yaml quanto override.yaml\ncontêm uma chave chamada 'Test', o valor definido em override.yaml terá precedência:\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\nVocê pode especificar o argumento `--set` várias vezes. A prioridade será dada ao\núltimo valor especificado (mais à direita). Por exemplo, se ambos os valores 'bar' e 'newbar' são\ndefinidos para uma chave chamada 'foo', o valor 'newbar' terá precedência:\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\nDa mesma forma, no exemplo a seguir 'foo' é definido como '[\"four\"]':\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\nE no exemplo a seguir, 'foo' é definido como '{\"key1\":\"value1\",\"key2\":\"bar\"}':\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\nPara verificar os manifestos gerados de uma release sem instalar o chart,\nos argumentos --debug e --dry-run podem ser combinados.\n\nO argumento --dry-run exibirá todos os manifestos gerados do chart, incluindo Secrets\nque podem conter valores sensíveis. Para ocultar Secrets do Kubernetes use o\nargumento --hide-secret. Por favor, considere cuidadosamente como e quando usar esses argumentos.\n\nSe --verify for definido, o chart DEVE ter um arquivo de proveniência, e o arquivo\nde proveniência DEVE passar em todas as etapas de verificação.\n\nHá seis maneiras diferentes de expressar o chart que você deseja instalar:\n\n1. Por referência do chart: helm install mymaria example/mariadb\n2. Por caminho para um chart empacotado: helm install mynginx ./nginx-1.2.3.tgz\n3. Por caminho para um diretório de chart descompactado: helm install mynginx ./nginx\n4. Por URL absoluta: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. Por referência do chart e URL do repositório: helm install --repo https://example.com/charts/ mynginx nginx\n6. Por registries OCI: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\nREFERÊNCIAS DE CHART\n\nUma referência de chart é uma forma conveniente de referenciar um chart em um repositório de charts.\n\nQuando você usa uma referência de chart com um prefixo de repositório ('example/mariadb'), o Helm procurará na\nconfiguração local por um repositório de charts chamado 'example', e então procurará um\nchart nesse repositório cujo nome é 'mariadb'. Ele instalará a última versão estável desse chart\naté que você especifique o argumento '--devel' para também incluir versões de desenvolvimento (releases alfa, beta e candidatas), ou\nforneça um número de versão com o argumento '--version'.\n\nPara ver a lista de repositórios de charts, use 'helm repo list'. Para pesquisar\ncharts em um repositório, use 'helm search'.\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### Opções\n\n```\n      --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\n      --ca-file string                             verifica certificados de servidores habilitados para HTTPS usando este pacote CA\n      --cert-file string                           identifica cliente HTTPS usando este arquivo de certificado SSL\n      --create-namespace                           cria o namespace da release se não estiver presente\n      --dependency-update                          atualiza dependências se estiverem faltando antes de instalar o chart\n      --description string                         adiciona uma descrição personalizada\n      --devel                                      usa versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version for definido, isso é ignorado\n      --disable-openapi-validation                 se definido, o processo de instalação não validará templates renderizados contra o Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 habilita pesquisas DNS ao renderizar templates\n      --force                                      força atualizações de recursos através de uma estratégia de substituição\n  -g, --generate-name                              gera o nome (e omite o parâmetro NAME)\n  -h, --help                                       ajuda para install\n      --hide-notes                                 se definido, não mostra notas na saída de instalação. Não afeta a presença nos metadados do chart\n      --hide-secret                                oculta Secrets do Kubernetes quando também estiver usando o argumento --dry-run\n      --insecure-skip-tls-verify                   ignora verificações de certificado tls para o download do chart\n      --key-file string                            identifica cliente HTTPS usando este arquivo de chave SSL\n      --keyring string                             localização das chaves públicas usadas para verificação (padrão \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Labels que seriam adicionados aos metadados da release. Devem ser separados por vírgula. (padrão [])\n      --name-template string                       especifica template usado para nomear a release\n      --no-hooks                                   impede que hooks sejam executados durante a instalação\n  -o, --output format                              imprime a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table)\n      --pass-credentials                           passa credenciais para todos os domínios\n      --password string                            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                                 usa conexões HTTP inseguras para o download do chart\n      --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\n      --post-renderer-args postRendererArgsSlice   um argumento para o post-renderer (pode especificar múltiplos) (padrão [])\n      --render-subchart-notes                      se definido, renderiza notas de subcharts junto com o principal\n      --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\n      --repo string                                URL do repositório de charts onde localizar o chart solicitado\n      --set stringArray                            define valores na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       define valores JSON na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    define um valor STRING literal na linha de comando\n      --set-string stringArray                     define valores STRING na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2)\n      --skip-crds                                  se definido, nenhum CRD será instalado. Por padrão, CRDs são instalados se ainda não estiverem presentes\n      --skip-schema-validation                     se definido, desabilita a validação de JSON schema\n      --take-ownership                             se definido, install ignorará a verificação de anotações helm e assumirá a propriedade dos recursos existentes\n      --timeout duration                           tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s)\n      --username string                            nome de usuário do repositório de charts onde localizar o chart solicitado\n  -f, --values strings                             especifica valores em um arquivo YAML ou uma URL (pode especificar múltiplos)\n      --verify                                     verifica o pacote antes de usá-lo\n      --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\n      --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\n      --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\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade de certificação para a conexão com o Kubernetes API server\n      --kube-context string             nome do contexto kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja também\n\n* [helm](/helm/helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\nexamina um chart em busca de possíveis problemas\n\n### Sinopse\n\nEste comando recebe um caminho para um chart e executa uma série de testes para verificar se o chart está bem-formado.\n\nSe 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].\n\n\n```\nhelm lint PATH [flags]\n```\n\n### Opções\n\n```\n  -h, --help                      exibe ajuda para o comando lint\n      --kube-version string       versão do Kubernetes utilizada para verificações de capacidades e depreciação\n      --quiet                     exibe apenas avisos e erros\n      --set stringArray           define valores na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray      define valores JSON na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray   define um valor STRING literal na linha de comando\n      --set-string stringArray    define valores STRING na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2)\n      --skip-schema-validation    se definido, desabilita a validação de JSON schema\n      --strict                    falha em avisos do lint\n  -f, --values strings            especifica valores em um arquivo YAML ou URL (pode especificar múltiplos)\n      --with-subcharts            executa lint nos charts dependentes\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\nlista as releases\n\n### Sinopse\n\nEste comando lista todas as releases de um namespace especificado (utiliza o namespace do contexto atual se nenhum namespace for especificado).\n\nPor 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'.\n\nPor padrão, os itens são ordenados alfabeticamente. Utilize o argumento '-d' para ordenar por data da release.\n\nSe 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.\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\nSe 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).\n\nPor 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.\n\n\n```\nhelm list [flags]\n```\n\n### Opções\n\n```\n  -a, --all                  exibe todas as releases sem nenhum filtro aplicado\n  -A, --all-namespaces       lista releases em todos os namespaces\n  -d, --date                 ordena por data da release\n      --deployed             exibe releases implantadas. Se nenhuma outra opção for especificada, esta será habilitada automaticamente\n      --failed               exibe releases com falha\n  -f, --filter string        uma expressão regular (compatível com Perl). Qualquer release que corresponda à expressão será incluída nos resultados\n  -h, --help                 exibe ajuda para o comando list\n  -m, --max int              número máximo de releases a buscar (padrão 256)\n      --no-headers           não exibe cabeçalhos ao utilizar o formato de saída padrão\n      --offset int           próximo índice de release na lista, utilizado para deslocar do valor inicial\n  -o, --output format        imprime a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table)\n      --pending              exibe releases pendentes\n  -r, --reverse              inverte a ordem de classificação\n  -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.\n  -q, --short                formato de saída resumido\n      --superseded           exibe releases substituídas\n      --time-format string   formata a hora utilizando o formatador de tempo do golang. Exemplo: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          exibe releases desinstaladas (se 'helm uninstall --keep-history' foi utilizado)\n      --uninstalling         exibe releases que estão sendo desinstaladas no momento\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\nempacota um diretório de chart em um arquivo de chart\n\n### Sinopse\n\nEste comando empacota um chart em um arquivo de chart versionado. Se um caminho\nfor fornecido, ele procurará nesse caminho por um chart (que deve conter um\narquivo Chart.yaml) e então empacotará esse diretório.\n\nRepositórios de pacotes do Helm utilizam arquivos de chart versionados.\n\nPara assinar um chart, utilize a flag '--sign'. Geralmente, você também\ndeve fornecer '--keyring caminho/para/chaves/secretas' e '--key nome_da_chave'.\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\nSe '--keyring' não for especificado, o Helm normalmente utiliza o chaveiro público\npor padrão, a menos que seu ambiente esteja configurado de outra forma.\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Opções\n\n```\n      --app-version string         define a appVersion do chart para esta versão\n      --ca-file string             verifica certificados de servidores com HTTPS utilizando este pacote CA\n      --cert-file string           identifica o cliente HTTPS utilizando este arquivo de certificado SSL\n  -u, --dependency-update          atualiza dependências do \"Chart.yaml\" para o diretório \"charts/\" antes de empacotar\n  -d, --destination string         local para salvar o chart. (padrão \".\")\n  -h, --help                       exibe ajuda para o comando package\n      --insecure-skip-tls-verify   ignora verificações de certificado TLS para o download do chart\n      --key string                 nome da chave a ser usada ao assinar. Utilizado se --sign for verdadeiro\n      --key-file string            identifica o cliente HTTPS utilizando este arquivo de chave SSL\n      --keyring string             local do chaveiro público (padrão \"~/.gnupg/pubring.gpg\")\n      --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.\n      --password string            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                 utiliza conexões HTTP inseguras para o download do chart\n      --sign                       utiliza uma chave privada PGP para assinar este pacote\n      --username string            nome de usuário do repositório de charts onde localizar o chart solicitado\n      --version string             define a versão do chart para esta versão semver\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               token bearer utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta solicitação\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registro (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositórios em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\ninstala, lista ou desinstala plugins do Helm\n\n### Sinopse\n\nGerencia plugins do Helm no lado do cliente.\n\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando plugin\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes para o Kubernetes.\n* [helm plugin install](./helm_plugin_install.md)\t - instala um plugin do Helm\n* [helm plugin list](./helm_plugin_list.md)\t - lista os plugins instalados do Helm\n* [helm plugin uninstall](./helm_plugin_uninstall.md)\t - desinstala um ou mais plugins do Helm\n* [helm plugin update](./helm_plugin_update.md)\t - atualiza um ou mais plugins do Helm\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\ninstala um plugin do Helm\n\n### Sinopse\n\nEste comando permite instalar um plugin a partir de uma URL de um repositório VCS ou de um caminho local.\n\n```\nhelm plugin install [options] <path|url> [flags]\n```\n\n### Opções\n\n```\n  -h, --help             exibe ajuda para o comando install\n      --version string   especifica uma restrição de versão. Se não for especificado, a versão mais recente será instalada\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm plugin](./helm_plugin.md)\t - instala, lista ou desinstala plugins do Helm\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\nlista os plugins do Helm instalados\n\n```\nhelm plugin list [flags]\n```\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando list\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm plugin](./helm_plugin.md)\t - instala, lista ou desinstala plugins do Helm\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\ndesinstala um ou mais plugins do Helm\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando uninstall\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm plugin](./helm_plugin.md)\t - instala, lista ou desinstala plugins do Helm\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\natualiza um ou mais plugins do Helm\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando update\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm plugin](./helm_plugin.md)\t - instala, lista ou desinstala plugins do Helm\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\nbaixa um chart de um repositório e (opcionalmente) extrai em um diretório local\n\n### Sinopse\n\nObtém um pacote de um repositório de pacotes e faz o download localmente.\n\nIsso é útil para obter pacotes para inspecionar, modificar ou reempacotar. Também\npode ser usado para realizar verificação criptográfica de um chart sem instalá-lo.\n\nExistem opções para descompactar o chart após o download. Isso criará um diretório\npara o chart e descompactará o conteúdo nesse diretório.\n\nSe a flag --verify for especificada, o chart solicitado DEVE ter um arquivo de\nprocedência e DEVE passar pelo processo de verificação. Falha em qualquer parte\ndesse processo resultará em erro, e o chart não será salvo localmente.\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### Opções\n\n```\n      --ca-file string             verifica certificados de servidores com HTTPS utilizando este pacote CA\n      --cert-file string           identifica o cliente HTTPS utilizando este arquivo de certificado SSL\n  -d, --destination string         local para salvar o chart. Se este e untardir forem especificados, untardir é anexado a este (padrão \".\")\n      --devel                      utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version for definido, este é ignorado.\n  -h, --help                       exibe ajuda para o comando pull\n      --insecure-skip-tls-verify   ignora verificações de certificado TLS para o download do chart\n      --key-file string            identifica o cliente HTTPS utilizando este arquivo de chave SSL\n      --keyring string             local das chaves públicas usadas para verificação (padrão \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           passa credenciais para todos os domínios\n      --password string            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                 utiliza conexões HTTP inseguras para o download do chart\n      --prov                       obtém o arquivo de procedência, mas não realiza verificação\n      --repo string                URL do repositório de charts onde localizar o chart solicitado\n      --untar                      se definido como true, descompacta o chart após o download\n      --untardir string            se untar for especificado, esta flag especifica o nome do diretório no qual o chart será extraído (padrão \".\")\n      --username string            nome de usuário do repositório de charts onde localizar o chart solicitado\n      --verify                     verifica o pacote antes de utilizá-lo\n      --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\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\nenvia um chart para um registry remoto\n\n### Sinopse\n\nEnvia um chart para um registry.\n\nSe o chart possuir um arquivo de procedência associado,\nele também será enviado.\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### Opções\n\n```\n      --ca-file string             verifica certificados de servidores com HTTPS utilizando este pacote CA\n      --cert-file string           identifica o cliente do registry utilizando este arquivo de certificado SSL\n  -h, --help                       exibe ajuda para o comando push\n      --insecure-skip-tls-verify   ignora verificações de certificado TLS para o upload do chart\n      --key-file string            identifica o cliente do registry utilizando esta chave SSL\n      --password string            senha do repositório de charts\n      --plain-http                 utiliza conexões HTTP inseguras para o upload do chart\n      --username string            nome de usuário do repositório de charts\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\nefetua login ou logout de um registry\n\n### Sinopse\n\nEste comando possui vários subcomandos para interagir com registries.\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando registry\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n* [helm registry login](./helm_registry_login.md)\t - efetua login em um registry\n* [helm registry logout](./helm_registry_logout.md)\t - encerra sessão de um registry\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\nefetua login em um registry\n\n### Sinopse\n\nAutentica em um registry remoto.\n\n```\nhelm registry login [host] [flags]\n```\n\n### Opções\n\n```\n      --ca-file string     verifica certificados de servidores HTTPS usando este pacote de CA\n      --cert-file string   identifica o cliente do registry usando este arquivo de certificado SSL\n  -h, --help               exibe ajuda para o comando login\n      --insecure           permite conexões a registries TLS sem certificados\n      --key-file string    identifica o cliente do registry usando este arquivo de chave SSL\n  -p, --password string    senha do registry ou token de identidade\n      --password-stdin     lê a senha ou token de identidade da entrada padrão (stdin)\n      --plain-http         usa conexões HTTP inseguras para o upload do chart\n  -u, --username string    nome de usuário do registry\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm registry](./helm_registry.md)\t - efetua login ou logout de um registry\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\nencerra sessão de um registry\n\n### Sinopse\n\nRemove as credenciais armazenadas para um registry remoto.\n\n```\nhelm registry logout [host] [flags]\n```\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando logout\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm registry](./helm_registry.md)\t - efetua login ou logout de um registry\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\nadiciona, lista, remove, atualiza e indexa repositórios de charts\n\n### Sinopse\n\nEste comando possui vários subcomandos para interagir com repositórios de charts.\n\nCom ele você pode adicionar, remover, listar e indexar repositórios de charts.\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando repo\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n* [helm repo add](./helm_repo_add.md)\t - adiciona um repositório de charts\n* [helm repo index](./helm_repo_index.md)\t - gera um arquivo de índice dado um diretório contendo charts empacotados\n* [helm repo list](./helm_repo_list.md)\t - lista repositórios de charts\n* [helm repo remove](./helm_repo_remove.md)\t - remove um ou mais repositórios de charts\n* [helm repo update](./helm_repo_update.md)\t - atualiza informações de charts disponíveis localmente a partir dos repositórios de charts\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\nadiciona um repositório de charts\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Opções\n\n```\n      --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\n      --ca-file string             verifica certificados de servidores com HTTPS utilizando este pacote CA\n      --cert-file string           identifica o cliente HTTPS utilizando este arquivo de certificado SSL\n      --force-update               substitui (sobrescreve) o repositório se ele já existir\n  -h, --help                       exibe ajuda para o comando add\n      --insecure-skip-tls-verify   ignora verificações de certificado TLS para o repositório\n      --key-file string            identifica o cliente HTTPS utilizando esta chave SSL\n      --no-update                  Ignorado. Anteriormente, desabilitava atualizações forçadas. Está obsoleto em favor de force-update.\n      --pass-credentials           passa credenciais para todos os domínios\n      --password string            senha do repositório de charts\n      --password-stdin             lê a senha do repositório de charts da entrada padrão\n      --timeout duration           tempo de espera para o download do arquivo de índice ser concluído (padrão 2m0s)\n      --username string            nome de usuário do repositório de charts\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm repo](./helm_repo.md)\t - adiciona, lista, remove, atualiza e indexa repositórios de charts\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\ngera um arquivo de índice a partir de um diretório contendo charts empacotados\n\n### Sinopse\n\nLê o diretório atual, gera um arquivo de índice baseado nos charts encontrados\ne escreve o resultado em 'index.yaml' no diretório atual.\n\nEsta ferramenta é utilizada para criar um arquivo 'index.yaml' para um repositório de charts. Para\ndefinir uma URL absoluta para os charts, utilize o argumento '--url'.\n\nPara mesclar o índice gerado com um arquivo de índice existente, utilize o argumento '--merge'.\nNeste caso, os charts encontrados no diretório atual serão mesclados\nao índice passado em --merge, com charts locais tendo prioridade sobre\ncharts existentes.\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### Opções\n\n```\n  -h, --help           exibe ajuda para o comando index\n      --json           saída em formato JSON\n      --merge string   mescla o índice gerado ao índice informado\n      --url string     url do repositório de charts\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm repo](./helm_repo.md)\t - adiciona, lista, remove, atualiza e indexa repositórios de charts\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\nlista repositórios de charts\n\n```\nhelm repo list [flags]\n```\n\n### Opções\n\n```\n  -h, --help            exibe ajuda para o comando list\n  -o, --output format   imprime a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table)\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm repo](./helm_repo.md)\t - adiciona, lista, remove, atualiza e indexa repositórios de charts\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nremove um ou mais repositórios de charts\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando remove\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm repo](./helm_repo.md)\t - adiciona, lista, remove, atualiza e indexa repositórios de charts\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\natualiza informações de charts disponíveis localmente a partir dos repositórios de charts\n\n### Sinopse\n\nO comando update obtém as informações mais recentes sobre charts dos respectivos repositórios de charts.\nAs informações são armazenadas em cache localmente, onde são utilizadas por comandos como 'helm search'.\n\nVocê pode opcionalmente especificar uma lista de repositórios que deseja atualizar.\n\t$ helm repo update <repo_name> ...\nPara atualizar todos os repositórios, use 'helm repo update'.\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Opções\n\n```\n      --fail-on-repo-update-fail   a atualização falha se qualquer uma das atualizações de repositório falhar\n  -h, --help                       exibe ajuda para o comando update\n      --timeout duration           tempo de espera para o download do arquivo de índice ser concluído (padrão 2m0s)\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm repo](./helm_repo.md)\t - adiciona, lista, remove, atualiza e indexa repositórios de charts\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\nReverte uma release para uma revisão anterior\n\n### Sinopse\n\nEsse comando reverte uma release para uma revisão anterior.\n\nO primeiro argumento do comando rollback é o nome de uma release, e o\nsegundo é o número de uma revisão (versão). Se esse argumento for omitido\nou definido como 0, a release será revertida para a revisão anterior.\n\nPara ver os números de revisão, execute 'helm history RELEASE'.\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Opções\n\n```\n      --cleanup-on-fail    permite a exclusão de novos recursos criados neste rollback quando o rollback falhar\n      --dry-run            simula um rollback\n      --force              força atualização de recursos através de exclusão/recriação se necessário\n  -h, --help               exibe ajuda para o comando rollback\n      --history-max int    limita o número máximo de revisões salvas por release. Use 0 para sem limite (padrão 10)\n      --no-hooks           impede a execução de hooks durante o rollback\n      --recreate-pods      reinicia os pods do recurso se aplicável\n      --timeout duration   tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s)\n      --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\n      --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\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída verbosa\n      --kube-apiserver string           o endereço e porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, esse argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             usuário a representar para a operação\n      --kube-ca-file string             arquivo de autoridade de certificado para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo do namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositórios em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](/helm/helm.md)\t - O gerenciador de pacotes Helm para o Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\nbusca por uma palavra-chave em charts\n\n### Sinopse\n\n\nO search permite buscar charts do Helm nos diversos locais\nonde podem estar armazenados, incluindo o Artifact Hub e repositórios que você adicionou.\nUse os subcomandos do search para buscar charts em diferentes locais.\n\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando search\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes para o Kubernetes.\n* [helm search hub](./helm_search_hub.md)\t - busca por charts no Artifact Hub ou na sua própria instância de hub\n* [helm search repo](./helm_search_repo.md)\t - busca por uma palavra-chave em charts nos repositórios\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\npesquisa por charts no Artifact Hub ou na sua própria instância de hub\n\n### Sinopse\n\nPesquisa por Helm charts no Artifact Hub ou na sua própria instância de hub.\n\nO Artifact Hub é uma aplicação web que permite encontrar, instalar e\npublicar pacotes e configurações para projetos CNCF, incluindo charts Helm\nde distribuição pública. É um projeto sandbox da Cloud Native Computing\nFoundation. Você pode navegar pelo hub em https://artifacthub.io/\n\nO argumento [KEYWORD] aceita uma palavra-chave ou uma consulta avançada entre aspas.\nPara mais detalhes sobre consultas avançadas, consulte\nhttps://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n\nVersões anteriores do Helm utilizavam uma instância do Monocular como 'endpoint'\npadrão. Por isso, para manter compatibilidade, o Artifact Hub é compatível com a\nAPI de pesquisa do Monocular. Da mesma forma, ao definir o argumento 'endpoint',\no endpoint especificado também deve implementar uma API de pesquisa compatível\ncom o Monocular. Note que ao especificar uma instância do Monocular como\n'endpoint', consultas avançadas não são suportadas. Para detalhes da API, consulte\nhttps://github.com/helm/monocular\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### Opções\n\n```\n      --endpoint string      instância do Hub para consultar charts (padrão \"https://hub.helm.sh\")\n      --fail-on-no-result    a pesquisa falha se nenhum resultado for encontrado\n  -h, --help                 exibe ajuda para o comando hub\n      --list-repo-url        exibe a URL do repositório dos charts\n      --max-col-width uint   largura máxima das colunas na tabela de saída (padrão 50)\n  -o, --output format        exibe a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table)\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm search](./helm_search.md)\t - pesquisa por uma palavra-chave em charts\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\npesquisa repositórios por uma palavra-chave em charts\n\n### Sinopse\n\nO comando search percorre todos os repositórios configurados no sistema e\nprocura por correspondências. A pesquisa desses repositórios utiliza os\nmetadados armazenados no sistema.\n\nSerão exibidas as últimas versões estáveis dos charts encontrados. Se você\nespecificar o argumento --devel, a saída incluirá versões de pré-lançamento.\nSe você deseja pesquisar usando uma restrição de versão, use --version.\n\nExemplos:\n\n    # Pesquisa por versões de release estáveis correspondentes à palavra-chave \"nginx\"\n    $ helm search repo nginx\n\n    # Pesquisa por versões de release correspondentes à palavra-chave \"nginx\", incluindo versões de pré-lançamento\n    $ helm search repo nginx --devel\n\n    # Pesquisa pela última versão estável do nginx-ingress com uma versão major 1\n    $ helm search repo nginx-ingress --version ^1.0.0\n\nRepositórios são gerenciados com os comandos 'helm repo'.\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### Opções\n\n```\n      --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\n      --fail-on-no-result    a pesquisa falha se nenhum resultado for encontrado\n  -h, --help                 exibe ajuda para o comando repo\n      --max-col-width uint   largura máxima das colunas na tabela de saída (padrão 50)\n  -o, --output format        exibe a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table)\n  -r, --regexp               utiliza expressões regulares para pesquisar nos repositórios que você adicionou\n      --version string       pesquisa usando restrições de versionamento semântico nos repositórios que você adicionou\n  -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\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm search](./helm_search.md)\t - pesquisa por uma palavra-chave em charts\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\nexibe informações de um chart\n\n### Sinopse\n\nEste comando consiste em múltiplos subcomandos para exibir informações sobre um chart\n\n\n### Opções\n\n```\n  -h, --help   exibe ajuda para o comando show\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes para o Kubernetes.\n* [helm show all](./helm_show_all.md)\t - exibe todas as informações do chart\n* [helm show chart](./helm_show_chart.md)\t - exibe a definição do chart\n* [helm show crds](./helm_show_crds.md)\t - exibe os CRDs do chart\n* [helm show readme](./helm_show_readme.md)\t - exibe o README do chart\n* [helm show values](./helm_show_values.md)\t - exibe os valores do chart\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\nexibe todas as informações do chart\n\n### Sinopse\n\nEste comando inspeciona um chart (diretório, arquivo ou URL) e exibe todo o conteúdo\n(values.yaml, Chart.yaml, README)\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### Opções\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS utilizando este pacote de CA\n      --cert-file string           identifica o cliente HTTPS utilizando este arquivo de certificado SSL\n      --devel                      utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado\n  -h, --help                       exibe ajuda para o comando all\n      --insecure-skip-tls-verify   ignora verificações de certificado TLS no download do chart\n      --key-file string            identifica o cliente HTTPS utilizando este arquivo de chave SSL\n      --keyring string             localização das chaves públicas usadas para verificação (padrão \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           passa credenciais para todos os domínios\n      --password string            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                 utiliza conexões HTTP inseguras para o download do chart\n      --repo string                URL do repositório de charts onde localizar o chart solicitado\n      --username string            nome de usuário do repositório de charts onde localizar o chart solicitado\n      --verify                     verifica o pacote antes de usá-lo\n      --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\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm show](./helm_show.md)\t - exibe informações de um chart\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\nexibe a definição do chart\n\n### Sinopse\n\nEste comando inspeciona um chart (diretório, arquivo ou URL) e exibe o conteúdo\ndo arquivo Chart.yaml\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### Opções\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS utilizando este pacote de CA\n      --cert-file string           identifica o cliente HTTPS utilizando este arquivo de certificado SSL\n      --devel                      utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado\n  -h, --help                       exibe ajuda para o comando chart\n      --insecure-skip-tls-verify   ignora verificações de certificado TLS no download do chart\n      --key-file string            identifica o cliente HTTPS utilizando este arquivo de chave SSL\n      --keyring string             localização das chaves públicas usadas para verificação (padrão \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           passa credenciais para todos os domínios\n      --password string            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                 utiliza conexões HTTP inseguras para o download do chart\n      --repo string                URL do repositório de charts onde localizar o chart solicitado\n      --username string            nome de usuário do repositório de charts onde localizar o chart solicitado\n      --verify                     verifica o pacote antes de usá-lo\n      --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\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm show](./helm_show.md)\t - exibe informações de um chart\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\nexibe os CRDs do chart\n\n### Sinopse\n\nEste comando inspeciona um chart (diretório, arquivo ou URL) e exibe o conteúdo\ndos arquivos CustomResourceDefinition\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### Opções\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS utilizando este pacote de CA\n      --cert-file string           identifica o cliente HTTPS utilizando este arquivo de certificado SSL\n      --devel                      utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado\n  -h, --help                       exibe ajuda para o comando crds\n      --insecure-skip-tls-verify   ignora verificações de certificado TLS no download do chart\n      --key-file string            identifica o cliente HTTPS utilizando este arquivo de chave SSL\n      --keyring string             localização das chaves públicas usadas para verificação (padrão \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           passa credenciais para todos os domínios\n      --password string            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                 utiliza conexões HTTP inseguras para o download do chart\n      --repo string                URL do repositório de charts onde localizar o chart solicitado\n      --username string            nome de usuário do repositório de charts onde localizar o chart solicitado\n      --verify                     verifica o pacote antes de usá-lo\n      --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\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm show](./helm_show.md)\t - exibe informações de um chart\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nexibe o README do chart\n\n### Sinopse\n\nEste comando inspeciona um chart (diretório, arquivo ou URL) e exibe o conteúdo\ndo arquivo README\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### Opções\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS utilizando este pacote de CA\n      --cert-file string           identifica o cliente HTTPS utilizando este arquivo de certificado SSL\n      --devel                      utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado\n  -h, --help                       exibe ajuda para o comando readme\n      --insecure-skip-tls-verify   ignora verificações de certificado TLS no download do chart\n      --key-file string            identifica o cliente HTTPS utilizando este arquivo de chave SSL\n      --keyring string             localização das chaves públicas usadas para verificação (padrão \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           passa credenciais para todos os domínios\n      --password string            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                 utiliza conexões HTTP inseguras para o download do chart\n      --repo string                URL do repositório de charts onde localizar o chart solicitado\n      --username string            nome de usuário do repositório de charts onde localizar o chart solicitado\n      --verify                     verifica o pacote antes de usá-lo\n      --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\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm show](./helm_show.md)\t - exibe informações de um chart\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\nexibe os valores do chart\n\n### Sinopse\n\nEste comando inspeciona um chart (diretório, arquivo ou URL) e exibe o conteúdo\ndo arquivo values.yaml\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### Opções\n\n```\n      --ca-file string             verifica certificados de servidores HTTPS utilizando este pacote de CA\n      --cert-file string           identifica o cliente HTTPS utilizando este arquivo de certificado SSL\n      --devel                      utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado\n  -h, --help                       exibe ajuda para o comando values\n      --insecure-skip-tls-verify   ignora verificações de certificado TLS no download do chart\n      --jsonpath string            fornece uma expressão JSONPath para filtrar a saída\n      --key-file string            identifica o cliente HTTPS utilizando este arquivo de chave SSL\n      --keyring string             localização das chaves públicas usadas para verificação (padrão \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           passa credenciais para todos os domínios\n      --password string            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                 utiliza conexões HTTP inseguras para o download do chart\n      --repo string                URL do repositório de charts onde localizar o chart solicitado\n      --username string            nome de usuário do repositório de charts onde localizar o chart solicitado\n      --verify                     verifica o pacote antes de usá-lo\n      --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\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm show](./helm_show.md)\t - exibe informações de um chart\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\nexibe o status de uma release nomeada\n\n### Sinopse\n\nEste comando exibe o status de uma release nomeada.\nO status consiste em:\n- data e hora da última implantação\n- namespace do Kubernetes da release\n- estado da release (pode ser: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade ou pending-rollback)\n- revisão da release\n- descrição da release (pode ser mensagem de conclusão ou mensagem de erro, necessário habilitar --show-desc)\n- lista de recursos que compõem esta release (necessário habilitar --show-resources)\n- detalhes da última execução de testes, se aplicável\n- notas adicionais fornecidas pelo chart\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### Opções\n\n```\n  -h, --help             exibe ajuda para o comando status\n  -o, --output format    imprime a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table)\n      --revision int     se configurado, exibe o status da release nomeada com a revisão especificada\n      --show-desc        se configurado, exibe a mensagem de descrição da release nomeada\n      --show-resources   se configurado, exibe os recursos da release nomeada\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           endereço e porta do servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser representado para a operação\n      --kube-ca-file string             arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               bearer token utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### VEJA TAMBÉM\n\n* [helm](./helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nRenderiza templates localmente\n\n### Sinopse\n\nRenderiza templates de chart localmente e exibe a saída.\n\nTodos os valores que normalmente seriam consultados ou recuperados do cluster\nsão simulados localmente. Além disso, nenhuma validação do lado do servidor\nsobre a validade do chart (por exemplo, se uma API é suportada) é realizada.\n\n```\nhelm template [NOME] [CHART] [flags]\n```\n\n### Opções\n\n```\n  -a, --api-versions strings                       Kubernetes api versions used for Capabilities.APIVersions\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for template\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --include-crds                               include CRDs in the templated output\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --is-upgrade                                 set .Release.IsUpgrade instead of .Release.IsInstall\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        Kubernetes version used for Capabilities.KubeVersion\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n      --output-dir string                          writes the executed templates to files in output-dir instead of stdout\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --release-name                               use release name in the output-dir path.\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n  -s, --show-only stringArray                      only show manifests rendered from the given templates\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --skip-tests                                 skip tests from templated output\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n      --validate                                   validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](/helm/helm.md)\t - Helm, o gerenciador de pacotes para o Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\nExecuta os testes de uma release\n\n### Sinopse\n\nO comando test executa os testes de uma release.\n\nEste comando recebe como argumento o nome de uma release implantada.\nOs testes executados são definidos no chart que foi instalado.\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### Opções\n\n```\n      --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)\n  -h, --help               ajuda para test\n      --hide-notes         se definido, não mostra notas na saída do teste. Não afeta a presença nos metadados do chart\n      --logs               exibe os logs dos pods de teste (isso é executado após todos os testes serem concluídos, mas antes de qualquer limpeza)\n      --timeout duration   tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s)\n```\n\n### Opções herdadas dos comandos superiores\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída detalhada\n      --kube-apiserver string           o endereço e a porta para o servidor da API do Kubernetes\n      --kube-as-group stringArray       grupo a ser personificado para a operação, este argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a ser personificado para a operação\n      --kube-ca-file string             o arquivo de autoridade certificadora para a conexão com o servidor da API do Kubernetes\n      --kube-context string             nome do contexto kubeconfig a ser utilizado\n      --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\n      --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\n      --kube-token string               token bearer utilizado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo do namespace para esta solicitação\n      --qps float32                     consultas por segundo utilizadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositórios em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](/helm/helm.md) - Helm, o gerenciador de pacotes para o Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\nDesinstala uma release\n\n### Sinopse\n\nEsse comando recebe o nome de uma release e a desinstala.\n\nEle remove todos os recursos associados à última release do chart,\nassim como o histórico da release, liberando-o para uso futuro.\n\nUse o argumento '--dry-run' para visualizar quais releases serão desinstaladas\nsem realmente desinstalá-las.\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Opções\n\n```\n      --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\")\n      --description string   adiciona uma descrição personalizada\n      --dry-run              simula uma desinstalação\n  -h, --help                 exibe ajuda para o comando uninstall\n      --ignore-not-found     Trata \"release not found\" como uma desinstalação bem-sucedida\n      --keep-history         remove todos os recursos associados e marca a release como deletada, mas mantém o histórico da release\n      --no-hooks             evita que hooks sejam executados durante a desinstalação\n      --timeout duration     tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s)\n      --wait                 se configurado, esperará até que todos os recursos sejam deletados antes de retornar. Esperará pelo tempo definido em --timeout\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída verbosa\n      --kube-apiserver string           o endereço e porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, esse argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             usuário a representar para a operação\n      --kube-ca-file string             arquivo de autoridade de certificado para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo do namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositórios em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](/helm/helm.md)\t - O gerenciador de pacotes Helm para o Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nAtualiza uma release para uma nova versão de um chart\n\n### Sinopse\n\nEsse comando atualiza uma release para uma nova versão de um chart.\n\nOs argumentos do comando upgrade devem ser uma release e um chart. O argumento\ndo chart pode ser: uma referência de chart ('example/mariadb'), um caminho para\num diretório de chart, um chart empacotado, ou uma URL completa. Para referências\nde chart, a versão mais recente será utilizada a menos que o argumento `--version`\nseja especificado.\n\nPara sobrescrever valores em um chart, use o argumento `--values` indicando um\narquivo ou use o argumento `--set` passando a configuração via linha de comando.\nPara forçar valores no formato string use `--set-string`. Você pode usar `--set-file`\npara configurar valores individuais a partir de um arquivo quando o valor é muito\ngrande para a linha de comando ou é gerado dinamicamente. Você também pode usar\n`--set-json` para configurar valores JSON (escalares/objetos/arrays) via linha\nde comando.\n\nVocê pode especificar o argumento `--values`/`-f` diversas vezes. A prioridade\nserá concedida para o último (mais a direita) arquivo especificado. Por exemplo,\nse ambos myvalues.yaml e override.yaml contêm uma chave chamada 'Test', o valor\nconfigurado em override.yaml terá precedência:\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\nVocê pode especificar o argumento `--set` diversas vezes. A prioridade será\nconcedida para o último (mais a direita) valor especificado. Por exemplo, se\nambos os valores 'bar' e 'newbar' são configurados para uma chave chamada 'foo',\no valor 'newbar' terá precedência:\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\nVocê pode atualizar os valores de uma release existente com esse comando usando\no argumento `--reuse-values`. Os argumentos 'RELEASE' e 'CHART' devem ser definidos\ncom os parâmetros originais, e os valores existentes serão mesclados com quaisquer\nvalores configurados via `--values`/`-f` ou argumentos `--set`. A prioridade é\nconcedida aos novos valores.\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\nO argumento --dry-run exibirá todos os manifestos gerados do chart, incluindo\nSecrets que podem conter valores sensíveis. Para ocultar Kubernetes Secrets use\no argumento --hide-secret. Por favor considere cuidadosamente como e quando esses\nargumentos são utilizados.\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Opções\n\n```\n      --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\n      --ca-file string                             verifica os certificados dos servidores HTTPS utilizando o pacote CA especificado\n      --cert-file string                           identifica o cliente HTTPS utilizando o certificado SSL especificado\n      --cleanup-on-fail                            permite a exclusão de novos recursos criados neste upgrade quando o upgrade falhar\n      --create-namespace                           se --install for configurado, cria o namespace da release se não existir\n      --dependency-update                          atualiza as dependências se estiverem faltando antes de instalar o chart\n      --description string                         adiciona uma descrição personalizada\n      --devel                                      também considera versões de desenvolvimento. Equivalente a versão '>0.0.0-0'. Ignorado se --version for configurado\n      --disable-openapi-validation                 se configurado, o processo de upgrade não validará os templates renderizados contra o Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 habilita consultas DNS ao renderizar templates\n      --force                                      força atualizações de recursos através de uma estratégia de substituição\n  -h, --help                                       exibe ajuda para o comando upgrade\n      --hide-notes                                 se configurado, não exibe as notas na saída do upgrade. Não afeta a presença nos metadados do chart\n      --hide-secret                                oculta Kubernetes Secrets quando também usar o argumento --dry-run\n      --history-max int                            limita o número máximo de revisões salvas por release. Use 0 para sem limite (padrão 10)\n      --insecure-skip-tls-verify                   ignora a verificação do certificado TLS para o download do chart\n  -i, --install                                    se uma release com esse nome não existir, executa uma instalação\n      --key-file string                            identifica o cliente HTTPS utilizando a chave SSL especificada\n      --keyring string                             caminho das chaves públicas para verificação (padrão \"~/.gnupg/pubring.gpg\")\n  -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 [])\n      --no-hooks                                   desabilita hooks de pré/pós upgrade\n  -o, --output format                              exibe a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table)\n      --pass-credentials                           passa as credenciais para todos os domínios\n      --password string                            senha do repositório de charts onde localizar o chart solicitado\n      --plain-http                                 usa conexões HTTP inseguras para o download do chart\n      --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\n      --post-renderer-args postRendererArgsSlice   um argumento para o post-renderer (pode especificar múltiplos) (padrão [])\n      --render-subchart-notes                      se configurado, renderiza notas de subcharts juntamente com o chart principal\n      --repo string                                URL do repositório de charts onde localizar o chart solicitado\n      --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\n      --reset-values                               ao atualizar, redefine os valores para os embutidos no chart\n      --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\n      --set stringArray                            configura valores via linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       configura valores JSON via linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    configura um valor STRING literal via linha de comando\n      --set-string stringArray                     configura valores STRING via linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2)\n      --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\n      --skip-schema-validation                     se configurado, desabilita a validação do JSON schema\n      --take-ownership                             se configurado, o upgrade ignorará a verificação de anotações do helm e assumirá a propriedade dos recursos existentes\n      --timeout duration                           tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s)\n      --username string                            usuário do repositório de charts onde localizar o chart solicitado\n  -f, --values strings                             especifica valores em um arquivo YAML ou uma URL (pode especificar múltiplos)\n      --verify                                     verifica o pacote antes de utilizá-lo\n      --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\n      --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\n      --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\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída verbosa\n      --kube-apiserver string           o endereço e porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, esse argumento pode ser repetido para especificar múltiplos grupos.\n      --kube-as-user string             usuário a representar para a operação\n      --kube-ca-file string             arquivo de autoridade de certificado para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a usar\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo do namespace para esta requisição\n      --qps float32                     consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo índices de repositórios em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs de repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](/helm/helm.md)\t - O gerenciador de pacotes Helm para o Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\nverifica se um chart no caminho especificado foi assinado e é válido\n\n### Sinopse\n\n\nVerifica se o chart fornecido possui um arquivo de proveniência válido.\n\nArquivos de proveniência fornecem verificação criptográfica de que um chart não foi\nadulterado e foi empacotado por um provedor confiável.\n\nEste comando pode ser usado para verificar um chart local. Vários outros comandos fornecem\nflags '--verify' que executam a mesma validação. Para gerar um pacote assinado, use\no comando 'helm package --sign'.\n\n\n```\nhelm verify PATH [flags]\n```\n\n### Opções\n\n```\n  -h, --help             ajuda para verify\n      --keyring string   keyring contendo chaves públicas (padrão \"~/.gnupg/pubring.gpg\")\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída verbosa\n      --kube-apiserver string           o endereço e porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, esta flag pode ser repetida para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade certificadora para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs dos repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](/helm/helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n\nexibe a versão do cliente\n\n### Sinopse\n\nExibe a versão do Helm.\n\nEste comando exibirá uma representação da versão do Helm.\nA saída será algo como:\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version é a versão semântica da release.\n- GitCommit é o SHA do commit a partir do qual esta versão foi construída.\n- GitTreeState é \"clean\" se não havia alterações locais no código quando este binário foi\n  construído, e \"dirty\" se o binário foi construído a partir de código modificado localmente.\n- GoVersion é a versão do Go utilizada para compilar o Helm.\n\nAo utilizar a flag `--template`, as seguintes propriedades estão disponíveis para uso\nno template:\n\n- .Version contém a versão semântica do Helm\n- .GitCommit é o commit git\n- .GitTreeState é o estado da árvore git quando o Helm foi construído\n- .GoVersion contém a versão do Go com a qual o Helm foi compilado\n\nPor exemplo, `--template='Version: {{.Version}}'` produz a saída 'Version: v3.2.1'.\n\n\n```\nhelm version [flags]\n```\n\n### Opções\n\n```\n  -h, --help              ajuda para version\n      --short             exibe o número da versão\n      --template string   template para o formato da string de versão\n```\n\n### Opções gerais\n\n```\n      --burst-limit int                 limite de throttling padrão do lado do cliente (padrão 100)\n      --debug                           habilita saída verbosa\n      --kube-apiserver string           o endereço e porta do Kubernetes API server\n      --kube-as-group stringArray       grupo a representar para a operação, esta flag pode ser repetida para especificar múltiplos grupos.\n      --kube-as-user string             nome de usuário a representar para a operação\n      --kube-ca-file string             o arquivo de autoridade certificadora para conexão com o Kubernetes API server\n      --kube-context string             nome do contexto do kubeconfig a ser usado\n      --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\n      --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\n      --kube-token string               bearer token usado para autenticação\n      --kubeconfig string               caminho para o arquivo kubeconfig\n  -n, --namespace string                escopo de namespace para esta requisição\n      --qps float32                     consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting\n      --registry-config string          caminho para o arquivo de configuração do registry (padrão \"~/.config/helm/registry/config.json\")\n      --repository-cache string         caminho para o diretório contendo os índices de repositório em cache (padrão \"~/.cache/helm/repository\")\n      --repository-config string        caminho para o arquivo contendo nomes e URLs dos repositórios (padrão \"~/.config/helm/repositories.yaml\")\n```\n\n### Veja Também\n\n* [helm](/helm/helm.md)\t - O gerenciador de pacotes Helm para Kubernetes.\n\n###### Gerado automaticamente por spf13/cobra em 14-Jan-2026\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/helm/index.mdx",
    "content": "---\ntitle: Comandos Helm\ndescription: Documentação para a lista completa de comandos da CLI do helm.\nsidebar_position: 6\nid: helm-category\n---\n\n# Comandos Helm\n\nAqui você encontrará uma lista de comandos da CLI do helm, com informações sobre\nseu uso.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action para Automatizar Charts no GitHub Pages\ndescription: Descreve como usar o Chart Releaser Action para automatizar a publicação de charts através do GitHub Pages.\nsidebar_position: 3\n---\n\nEste guia descreve como usar o [Chart Releaser\nAction](https://github.com/marketplace/actions/helm-chart-releaser) para automatizar\na publicação de charts através do GitHub Pages. O Chart Releaser Action é um workflow\ndo GitHub Actions para transformar um projeto do GitHub em um repositório de charts do\nHelm auto-hospedado, usando a ferramenta CLI\n[helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n## Alterações no Repositório\n\nCrie um repositório Git na sua organização do GitHub. Você pode dar ao repositório\no nome `helm-charts`, embora outros nomes também sejam aceitáveis. Os arquivos fonte\nde todos os charts podem ser colocados na branch `main`. Os charts devem ser colocados\nno diretório `/charts` na raiz da árvore de diretórios.\n\nVocê também precisará de uma branch chamada `gh-pages` para publicar os charts. As\nalterações nessa branch serão criadas automaticamente pelo Chart Releaser Action descrito aqui.\nNo entanto, você pode criar a branch `gh-pages` e adicionar um arquivo `README.md`,\nque ficará visível para os usuários que visitarem a página.\n\nVocê pode adicionar instruções no `README.md` para instalação dos charts assim\n(substitua `<alias>`, `<orgname>` e `<chart-name>`):\n\n```\n## Usage\n\n[Helm](https://helm.sh) must be installed to use the charts.  Please refer to\nHelm's [documentation](https://helm.sh/docs) to get started.\n\nOnce Helm has been set up correctly, add the repo as follows:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nIf you had already added this repo earlier, run `helm repo update` to retrieve\nthe latest versions of the packages.  You can then run `helm search repo\n<alias>` to see the charts.\n\nTo install the <chart-name> chart:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nTo uninstall the chart:\n\n    helm uninstall my-<chart-name>\n```\n\nOs charts serão publicados em um site com URL assim:\n\n    https://<orgname>.github.io/helm-charts\n\n## Workflow do GitHub Actions\n\nCrie o arquivo de workflow do GitHub Actions na branch `main` em\n`.github/workflows/release.yml`\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nA configuração acima usa o\n[@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) para\ntransformar seu projeto do GitHub em um repositório de charts do Helm auto-hospedado.\nEle faz isso — sempre que houver um push para a branch main — verificando cada chart\nno seu projeto e, quando encontra uma nova versão, cria uma release correspondente no\nGitHub com o nome da versão do chart, adiciona os artefatos do chart do Helm à release\ne cria ou atualiza um arquivo `index.yaml` com metadados sobre essas releases, que é\nentão hospedado no GitHub Pages.\n\nA versão do Chart Releaser Action usada no exemplo acima é `v1.6.0`. Você pode\nalterá-la para a [versão mais recente\ndisponível](https://github.com/helm/chart-releaser-action/releases).\n\nNota: O Chart Releaser Action é quase sempre usado em conjunto com o [Helm Testing\nAction](https://github.com/marketplace/actions/helm-chart-testing) e o [Kind\nAction](https://github.com/marketplace/actions/kind-cluster).\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: Sincronizando Seu Repositório de Charts\ndescription: Como sincronizar seus repositórios de charts local e remoto.\nsidebar_position: 2\n---\n\n*Nota: Este exemplo é especificamente para um bucket do Google Cloud Storage (GCS)\nque hospeda um repositório de charts.*\n\n## Pré-requisitos\n* Instale a ferramenta [gsutil](https://cloud.google.com/storage/docs/gsutil). *Este\n  processo depende fortemente da funcionalidade gsutil rsync*\n* Certifique-se de ter acesso ao binário do Helm\n* _Opcional: Recomendamos que você ative o [versionamento de\n  objetos](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)\n  no seu bucket do GCS para o caso de excluir algo acidentalmente._\n\n## Configure um diretório de repositório de charts local\nCrie um diretório local como fizemos no [guia do repositório de charts](/topics/chart_repository.md), e coloque seus charts empacotados nesse\ndiretório.\n\nPor exemplo:\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Gere um index.yaml atualizado\nUse o Helm para gerar um arquivo index.yaml atualizado passando o caminho do diretório\ne a URL do repositório remoto para o comando `helm repo index` assim:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\nIsso gerará um arquivo index.yaml atualizado e o colocará no\ndiretório `fantastic-charts/`.\n\n## Sincronize seus repositórios de charts local e remoto\nFaça upload do conteúdo do diretório para seu bucket do GCS executando\n`scripts/sync-repo.sh` e passando o nome do diretório local e o nome do bucket\ndo GCS.\n\nPor exemplo:\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## Atualizando seu repositório de charts\nVocê vai querer manter uma cópia local do conteúdo do seu repositório de charts ou usar\n`gsutil rsync` para copiar o conteúdo do seu repositório de charts remoto para um diretório\nlocal.\n\nPor exemplo:\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nLinks Úteis:\n* Documentação sobre o [gsutil\n  rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [O Guia do Repositório de Charts](/topics/chart_repository.md)\n* Documentação sobre [versionamento de objetos e controle de\n  concorrência](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)\n  no Google Cloud Storage\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Dicas e Truques de Desenvolvimento de Charts\ndescription: Cobre algumas das dicas e truques que desenvolvedores de charts do Helm aprenderam enquanto criavam charts de qualidade para produção.\nsidebar_position: 1\n---\n\nEste guia cobre algumas das dicas e truques que desenvolvedores de charts do Helm\naprenderam enquanto criavam charts de qualidade para produção.\n\n## Conheça as Funções de Template\n\nO Helm usa [Go templates](https://godoc.org/text/template) para criar templates\ndos seus arquivos de recursos. Embora o Go já inclua várias funções nativas,\nadicionamos muitas outras.\n\nPrimeiro, adicionamos todas as funções da [biblioteca\nSprig](https://masterminds.github.io/sprig/), exceto `env` e `expandenv`, por\nrazões de segurança.\n\nTambém adicionamos duas funções especiais de template: `include` e `required`. A\nfunção `include` permite trazer outro template e então passar os resultados para\noutras funções de template.\n\nPor exemplo, este trecho de template inclui um template chamado `mytpl`, então\nconverte o resultado para minúsculas e o envolve em aspas duplas.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nA função `required` permite declarar uma entrada de valores específica como\nobrigatória para a renderização do template. Se o valor estiver vazio, a\nrenderização do template falhará com uma mensagem de erro enviada pelo usuário.\n\nO exemplo a seguir da função `required` declara que uma entrada para\n`.Values.who` é obrigatória, e exibirá uma mensagem de erro quando essa entrada\nestiver ausente:\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## Use Aspas em Strings, Não em Inteiros\n\nQuando você está trabalhando com dados de string, é sempre mais seguro colocar\naspas nas strings do que deixá-las sem:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nMas quando estiver trabalhando com inteiros, _não coloque aspas nos valores._\nIsso pode, em muitos casos, causar erros de parsing dentro do Kubernetes.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nEsta observação não se aplica a valores de variáveis de ambiente que são\nesperados como strings, mesmo quando representam inteiros:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Usando a Função 'include'\n\nO Go fornece uma maneira de incluir um template em outro usando a diretiva\nnativa `template`. No entanto, a função nativa não pode ser usada em pipelines\nde template do Go.\n\nPara tornar possível incluir um template e então realizar uma operação na saída\ndesse template, o Helm tem uma função especial `include`:\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nO código acima inclui um template chamado `toYaml`, passa `$value` para ele, e\nentão passa a saída desse template para a função `indent`.\n\nComo o YAML atribui significado aos níveis de indentação e espaços em branco,\nesta é uma ótima maneira de incluir trechos de código, enquanto manipula a\nindentação em um contexto relevante.\n\n## Usando a Função 'required'\n\nO Go fornece uma maneira de definir opções de template para controlar o\ncomportamento quando um mapa é indexado com uma chave que não está presente no\nmapa. Isso é tipicamente configurado com `template.Options(\"missingkey=option\")`,\nonde `option` pode ser `default`, `zero` ou `error`. Embora definir esta opção\ncomo error vá parar a execução com um erro, isso se aplicaria a cada chave\nausente no mapa. Pode haver situações em que um desenvolvedor de chart queira\nimpor esse comportamento para valores selecionados no arquivo `values.yaml`.\n\nA função `required` dá aos desenvolvedores a capacidade de declarar uma entrada\nde valor como obrigatória para a renderização do template. Se a entrada estiver\nvazia em `values.yaml`, o template não será renderizado e retornará uma mensagem\nde erro fornecida pelo desenvolvedor.\n\nPor exemplo:\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nO código acima renderizará o template quando `.Values.foo` estiver definido, mas\nfalhará na renderização e sairá quando `.Values.foo` estiver indefinido.\n\n## Usando a Função 'tpl'\n\nA função `tpl` permite que desenvolvedores avaliem strings como templates dentro\nde um template. Isso é útil para passar uma string de template como valor para\num chart ou renderizar arquivos de configuração externos. Sintaxe:\n`{{ tpl TEMPLATE_STRING VALUES }}`\n\nExemplos:\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\nRenderizando um arquivo de configuração externo:\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## Criando Image Pull Secrets\n\nImage pull secrets são essencialmente uma combinação de _registry_, _username_ e\n_password_. Você pode precisar deles em uma aplicação que está implantando, mas\npara criá-los é necessário executar `base64` algumas vezes. Podemos escrever um\ntemplate auxiliar para compor o arquivo de configuração do Docker para uso como\npayload do Secret. Aqui está um exemplo:\n\nPrimeiro, assuma que as credenciais estão definidas no arquivo `values.yaml`\nassim:\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nEm seguida, definimos nosso template auxiliar assim:\n\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nFinalmente, usamos o template auxiliar em um template maior para criar o\nmanifesto do Secret:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Reiniciando Deployments Automaticamente\n\nMuitas vezes ConfigMaps ou Secrets são injetados como arquivos de configuração\nem containers ou existem outras mudanças de dependências externas que exigem\nreiniciar pods. Dependendo da aplicação, uma reinicialização pode ser necessária\nse eles forem atualizados com um subsequente `helm upgrade`, mas se a spec do\ndeployment em si não mudou, a aplicação continua executando com a configuração\nantiga, resultando em um deployment inconsistente.\n\nA função `sha256sum` pode ser usada para garantir que a seção de annotations de\num deployment seja atualizada se outro arquivo mudar:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nNOTA: Se você está adicionando isso a um library chart, você não conseguirá\nacessar seu arquivo em `$.Template.BasePath`. Em vez disso, você pode referenciar\nsua definição com `{{ include (\"mylibchart.configmap\") . | sha256sum }}`.\n\nNo caso de você sempre querer reiniciar seu deployment, você pode usar um passo\nde annotation similar ao acima, substituindo por uma string aleatória para que\nela sempre mude e cause a reinicialização do deployment:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nCada invocação da função de template gerará uma string aleatória única. Isso\nsignifica que se for necessário sincronizar as strings aleatórias usadas por\nmúltiplos recursos, todos os recursos relevantes precisarão estar no mesmo\narquivo de template.\n\nAmbos os métodos permitem que seu Deployment aproveite a lógica de estratégia de\natualização nativa para evitar downtime.\n\nNOTA: No passado, recomendávamos usar a flag `--recreate-pods` como outra opção.\nEsta flag foi marcada como obsoleta no Helm 3 em favor do método declarativo\nacima.\n\n## Instruindo o Helm a Não Desinstalar um Recurso\n\nÀs vezes existem recursos que não devem ser desinstalados quando o Helm executa\num `helm uninstall`. Desenvolvedores de chart podem adicionar uma annotation a\num recurso para prevenir que ele seja desinstalado.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nA annotation `helm.sh/resource-policy: keep` instrui o Helm a pular a exclusão\ndeste recurso quando uma operação do helm (como `helm uninstall`, `helm upgrade`\nou `helm rollback`) resultaria em sua exclusão. _No entanto_, este recurso se\ntorna órfão. O Helm não o gerenciará mais de forma alguma. Isso pode levar a\nproblemas se usar `helm install --replace` em uma release que já foi\ndesinstalada, mas manteve recursos.\n\n## Usando \"Partials\" e Template Includes\n\nÀs vezes você quer criar algumas partes reutilizáveis em seu chart, sejam elas\nblocos ou partials de template. E frequentemente, é mais limpo mantê-los em seus\npróprios arquivos.\n\nNo diretório `templates/`, qualquer arquivo que começa com um underscore (`_`)\nnão é esperado que produza um arquivo de manifesto Kubernetes. Então, por\nconvenção, templates auxiliares e partials são colocados em um arquivo\n`_helpers.tpl`.\n\n## Charts Complexos com Muitas Dependências\n\nMuitos dos charts no [Artifact Hub](https://artifacthub.io/packages/search?kind=0)\nda CNCF são \"blocos de construção\" para criar aplicações mais avançadas. Mas\ncharts podem ser usados para criar instâncias de aplicações em grande escala.\nNesses casos, um único chart guarda-chuva pode ter múltiplos subcharts, cada um\nfuncionando como uma peça do todo.\n\nA prática recomendada atual para compor uma aplicação complexa a partir de\npartes discretas é criar um chart guarda-chuva de nível superior que expõe as\nconfigurações globais, e então usar o subdiretório `charts/` para incorporar\ncada um dos componentes.\n\n## YAML é um Superset de JSON\n\nDe acordo com a especificação YAML, YAML é um superset de JSON. Isso significa\nque qualquer estrutura JSON válida deveria ser válida em YAML.\n\nIsso tem uma vantagem: Às vezes, desenvolvedores de template podem achar mais\nfácil expressar uma estrutura de dados com uma sintaxe similar ao JSON em vez de\nlidar com a sensibilidade de espaços em branco do YAML.\n\nComo melhor prática, templates devem seguir uma sintaxe similar ao YAML _a menos\nque_ a sintaxe JSON reduza substancialmente o risco de um problema de formatação.\n\n## Cuidado ao Gerar Valores Aleatórios\n\nExistem funções no Helm que permitem gerar dados aleatórios, chaves\ncriptográficas, e assim por diante. São boas para usar. Mas esteja ciente de que\ndurante upgrades, os templates são re-executados. Quando uma execução de\ntemplate gera dados que diferem da última execução, isso acionará uma atualização\ndesse recurso.\n\n## Instalar ou Atualizar uma Release com um Único Comando\n\nO Helm fornece uma maneira de realizar um install-or-upgrade como um único\ncomando. Use `helm upgrade` com o comando `--install`. Isso fará com que o Helm\nverifique se a release já está instalada. Se não estiver, ele executará um\ninstall. Se estiver, então a release existente será atualizada.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/howto/index.mdx",
    "content": "---\ntitle: Guias de Instruções\nsidebar_position: 2\n---\n\n# Guias de Instruções\n\nNesta seção você encontrará respostas para perguntas do tipo \"Como eu faço...?\".\nOs guias de instruções não cobrem a fundo os tópicos abordados - você encontrará\nmais detalhamento desse material na seção [Guias Temáticos](/topics/index.mdx). Contudo,\nos Guias de Instruções lhe auxiliarão em realizar tarefas comuns para um usuário\ndo Helm.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"Início da Documentação\"\ndescription: \"Tudo o que você precisa saber em como essa documentação é organizada.\"\n---\n\n# Bem-vindo\n\nBem-vindo a documentação do [Helm](https://helm.sh/). Helm é um gerenciador de\npacotes para o Kubernetes, e você pode ler mais sobre o seu contexto detalhado no\n[Relatório da Jornada do Projeto Helm\nna CNCF](https://www.cncf.io/cncf-helm-project-journey/).\n\n# Como essa documentação é organizada?\n\nO Helm tem uma vasta documentação. Uma visão geral em alto nível de como ela é organizada\nlhe ajudará por onde procurar certas informações:\n\n- [Tutoriais](/intro/index.mdx) pegam na sua mão e lhe guiam por uma série de passos para criar\n  seu primeiro Chart no Helm. Comece por aqui se você é novo no Helm.\n- [Guias Temáticos](/topics/index.mdx) abordam os principais tópicos e conceitos em alto nível,\n  além de prover contexto e explicações utéis sobre o Helm.\n- [Guias da Comunidade](/community) abordam tópicos centrados ao redor\n  da comunidade do Helm. Comece por aqui se você quiser se informar sobre o\n  processo de desenvolvimento do Helm em si e como contribuir com o projeto.\n- [Guias de Instruções](/howto/index.mdx) são receitas prontas. Eles lhe guiam através dos passos\n  envolvidos na resolução dos principais problemas e casos de uso. São mais avançados\n  que tutoriais e demandam conhecimento prévio de como o Helm funciona.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: Guia de Referência Rápida\ndescription: Guia de referência rápida do Helm\nsidebar_position: 4\n---\n\nGuia de referência rápida do Helm contendo todos os comandos necessários para gerenciar uma aplicação através do Helm.\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### Conceitos e Contexto Básicos\n\nChart:\n- É o nome do seu chart caso ele tenha sido baixado e descompactado.\n- É <nome_do_repo>/<nome_do_chart> caso o repositório tenha sido adicionado mas o chart não foi baixado.\n- É a URL/Caminho absoluto para o chart.\n\nName:\n- É o nome que você deseja dar à sua instalação atual do chart Helm.\n\nRelease:\n- É o nome que você atribuiu a uma instância de instalação.\n\nRevision:\n- É o valor obtido do comando Helm history.\n\nRepo-name:\n- O nome de um repositório.\n\nDIR:\n- Nome/caminho do diretório.\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Gerenciamento de Charts\n\n```bash\nhelm create <name>                      # Creates a chart directory along with the common files and directories used in a chart.\nhelm package <chart-path>               # Packages a chart into a versioned chart archive file.\nhelm lint <chart>                       # Run tests to examine a chart and identify possible issues:\nhelm show all <chart>                   # Inspect a chart and list its contents:\nhelm show values <chart>                # Displays the contents of the values.yaml file\nhelm pull <chart>                       # Download/pull chart\nhelm pull <chart> --untar=true          # If set to true, will untar the chart after downloading it\nhelm pull <chart> --verify              # Verify the package before using it\nhelm pull <chart> --version <number>    # Default-latest is used, specify a version constraint for the chart version to use\nhelm dependency list <chart>            # Display a list of a chart's dependencies:\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Instalar e Desinstalar Aplicações\n\n```bash\nhelm install <name> <chart>                           # Install the chart with a name\nhelm install <name> <chart> --namespace <namespace>   # Install the chart in a specific namespace\nhelm install <name> <chart> --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas)\nhelm install <name> <chart> --values <yaml-file/url>  # Install the chart with your specified values\nhelm install <name> <chart> --dry-run --debug         # Run a test installation to validate chart (p)\nhelm install <name> <chart> --verify                  # Verify the package before using it\nhelm install <name> <chart> --dependency-update       # update dependencies if they are missing before installing the chart\nhelm uninstall <name>                                 # Uninstalls a release from the current (default) namespace\nhelm uninstall <release-name> --namespace <namespace> # Uninstalls a release from the specified namespace\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Atualizar Aplicações e Reverter Versões\n\n```bash\nhelm upgrade <release> <chart>                            # Upgrade a release\nhelm upgrade <release> <chart> --rollback-on-failure      # If set, upgrade process rolls back changes made in case of failed upgrade.\nhelm upgrade <release> <chart> --dependency-update        # update dependencies if they are missing before installing the chart\nhelm upgrade <release> <chart> --version <version_number> # specify a version constraint for the chart version to use\nhelm upgrade <release> <chart> --values                   # specify values in a YAML file or a URL (can specify multiple)\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Set values on the command line (can specify multiple or separate valuese)\nhelm upgrade <release> <chart> --force                    # Force resource updates through a replacement strategy\nhelm rollback <release> <revision>                        # Roll back a release to a specific revision\nhelm rollback <release> <revision>  --cleanup-on-fail     # Allow deletion of new resources created in this rollback when rollback fails\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Listar, Adicionar, Remover e Atualizar Repositórios\n\n```bash\nhelm repo add <repo-name> <url>   # Add a repository from the internet:\nhelm repo list                    # List added chart repositories\nhelm repo update                  # Update information of available charts locally from chart repositories\nhelm repo remove <repo_name>      # Remove one or more chart repositories\nhelm repo index <DIR>             # Read the current directory and generate an index file based on the charts found.\nhelm repo index <DIR> --merge     # Merge the generated index with an existing index file\nhelm search repo <keyword>        # Search repositories for a keyword in charts\nhelm search hub <keyword>         # Search for charts in the Artifact Hub or your own hub instance\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Monitoramento de Releases do Helm\n\n```bash\nhelm list                       # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified\nhelm list --all                 # Show all releases without any filter applied, can use -a\nhelm list --all-namespaces      # List releases across all namespaces, we can use -A\nhelm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!='\nhelm list --date                # Sort by release date\nhelm list --deployed            # Show deployed releases. If no other is specified, this will be automatically enabled\nhelm list --pending             # Show pending releases\nhelm list --failed              # Show failed releases\nhelm list --uninstalled         # Show uninstalled releases (if 'helm uninstall --keep-history' was used)\nhelm list --superseded          # Show superseded releases\nhelm list -o yaml               # Prints the output in the specified format. Allowed values: table, json, yaml (default table)\nhelm status <release>           # This command shows the status of a named release.\nhelm status <release> --revision <number>   # if set, display the status of the named release with revision\nhelm history <release>          # Historical revisions for a given release.\nhelm env                        # Env prints out all the environment information in use by Helm.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Baixar Informações de Releases\n\n```bash\nhelm get all <release>      # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release.\nhelm get hooks <release>    # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\\n' separator.\nhelm get manifest <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.\nhelm get notes <release>    # Shows notes provided by the chart of a named release.\nhelm get values <release>   # Downloads a values file for a given release. use -o to format output\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Gerenciamento de Plugins\n\n```bash\nhelm plugin install <path/url>      # Install plugins\nhelm plugin list                    # View a list of all installed plugins\nhelm plugin update <plugin>         # Update plugins\nhelm plugin uninstall <plugin>      # Uninstall a plugin\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/intro/index.mdx",
    "content": "---\ntitle: Introdução\nsidebar_position: 1\n---\n\n# Introdução ao Helm\n\nVocê é novo no Helm? Esse é o lugar por onde começar!\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: Instalando o Helm\ndescription: Aprenda como instalar e rodar o Helm.\nsidebar_position: 2\n---\n\nEsse guia ensina como instalar a CLI do Helm. O Helm pode ser instalado\na partir do código-fonte, ou mesmo de um binário pré-buildado.\n\n## A partir do Projeto Helm\n\nO projeto Helm disponibiliza duas maneiras de baixar e instalar o Helm. Essas são\nas formas oficiais de se obter as versões do Helm. Além disso, a comunidade do Helm\ndisponibiliza alternativas de download através de diversos gerenciadores de pacotes.\nA seção de instalação pelos gerenciadores de pacotes se encontra abaixo dos métodos\noficiais.\n\n### A partir das _Releases_ dos Binários\n\nCada [_release_](https://github.com/helm/helm/releases) do Helm gera distribuições\ndo binário para uma gama de sistemas operacionais. Essas versões de binários podem\nser baixadas manualmente e instaladas.\n\n1. Baixe uma [versão desejada](https://github.com/helm/helm/releases)\n2. Descompacte-a (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)\n3. Encontre o binário `helm` no diretório descompactado e mova-o para um diretório\nde destino (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nA partir daí, você já deve conseguir rodar o cliente e [adicionar\num repositório dos Charts do Helm](/intro/quickstart.md#initialize-a-helm-chart-repository):\n`helm help`.\n\n**Nota:** Os testes automatizados do Helm são realizados para a plataforma Linux\nAMD64 somente durante os _builds_ e _releases_ do GitHub Actions. Testes para outros\nsistemas operacionais não estão cobertos e são de responsabilidade da comunidade\nem solicitá-los.\n\n### A partir do _Script_\n\nO Helm agora conta com um _script_ que automaticamente baixará a última versão disponível\ndo Helm e [instalará localmente](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3).\n\nBaixe o _script_ e execute-o localmente. O _script_ está bem escrito e documentado,\npodendo ser verificado e revisado antes de proceder com a instalação local.\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\nSim, você pode executar `curl\nhttps://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` se\nvocê gosta de viver perigosamente.\n\n## Através de Gerenciadores de Pacote\n\nA comunidade do Helm disponibiliza a instalação através de diversos gerenciadores\nde pacotes para diferentes sistemas operacionais. Eles não são mantidos pelo projeto\nHelm e não são considerados provedores terceiros acreditados.\n\n### Homebrew (macOS)\n\nMembros da comunidade Helm adicionaram uma formula do Helm ao Homebrew.\nA fórmula geralmente está atualizada.\n\n```console\nbrew install helm\n```\n\n(Nota: Atenção, existe uma fórmula do emacs-helm, que é um projeto distinto!)\n\n### Chocolatey (Windows)\n\nMembros da comunidade Helm contribuíram com um build do [pacote Helm](https://chocolatey.org/packages/kubernetes-helm)\npara o [Chocolatey](https://chocolatey.org/). Esse pacote geralmente está atualizado.\n\n```console\nchoco install kubernetes-helm\n```\n\n### Scoop (Windows)\n\nMembros 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.\n\n```console\nscoop install helm\n```\n\n### Winget (Windows)\n\nMembros da comunidade Helm contribuíram com um build do [pacote Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm)\npara o [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Esse pacote geralmente está atualizado.\n\n```console\nwinget install Helm.Helm\n```\n\n### Apt (Debian/Ubuntu)\n\nMembros 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.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### dnf/yum (fedora)\n\nA partir do Fedora 35, o Helm está disponível no repositório oficial. Você pode instalar o Helm executando:\n\n```console\nsudo dnf install helm\n```\n\n### Snap\n\nA comunidade dos [_Snapcrafters_](https://github.com/snapcrafters) mantém a versão\ndo [pacote Helm](https://snapcraft.io/helm) para o Snap:\n\n```console\nsudo snap install helm --classic\n```\n\n### pkg (FreeBSD)\n\nMembros da comunidade do FreeBSD contribuíram com um [pacote Helm](https://www.freshports.org/sysutils/helm)\nbuildado para o [_FreeBSD Ports Collection_](https://man.freebsd.org/ports).\nEsse pacote geralmente está atualizado.\n\n```console\npkg install helm\n```\n\n### _Builds_ de Desenvolvimento\n\nAlém das releases estáveis, é possível baixar e instalar versões de desenvolvimento\ndo Helm.\n\n### _Canary Builds_\n\n_Builds \"Canary\"_ são versões do Helm construídas a partir das últimas atualizações\nda branch `main`. Eles não são releases oficiais e podem não ser estáveis!\nContudo, oferecem a oportunidade de testar as funcionalidades mais recentes do Helm.\n\nOs binários _Canary_ do Helm são armazenados em [get.helm.sh](https://get.helm.sh).\nEstes são alguns links de _builds_ comuns:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows\n  AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### A partir do Código-Fonte (Linux, macOS)\n\n_Buildar_ o Helm a partir do código-fonte é mais trabalhoso, mas é a melhor forma\nde testar as últimas versões (pré-release) do Helm.\n\nVocê deve ter um ambiente de execução Go instalado em seu host.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\nSe necessário, essa abordagem irá baixar as dependências, armazená-las em cache\ne validará a configuração. Irá compilar o `helm` e o mover para `bin/helm` também.\n\n## Conclusão\n\nNa maioria dos casos, a instalação é simples como baixar um binário pré-buildado\ndo `helm`. Este documento cobre casos de pessoas que querem executar cargas de\ntrabalho mais sofisticadas com o Helm.\n\nUma vez instalado com sucesso o cliente Helm, você pode seguir com o uso do Helm\npara o gerenciamento de charts e [adicionar um repositório estável](/intro/quickstart.md#initialize-a-helm-chart-repository).\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: Guia de Início Rápido\ndescription: >-\n  Como instalar e começar com os primeiros passos no Helm, incluindo instruções para Distros, Perguntas Frequentes e\n  plugins.\nsidebar_position: 1\n---\n\nEsse guia cobre como você rapidamente pode começar a utilizar o Helm.\n\n## Pré-requisitos\n\nOs pré-requisitos a seguir são exigidos para uma experiência bem sucedida e segura\ndo uso do Helm.\n\n1. Ter acesso a um cluster Kubernetes\n2. Decidir quais configurações de segurança serão aplicadas durante a instalação,\nse houver alguma\n3. Instalar e configurar o Helm.\n\n### Instale o Kubernetes ou tenha acesso a um cluster\n\n- Você deve ter o Kubernetes instalado. Para a utilização da última versão do Helm,\n  nós recomendamos a última versão estável do Kubernetes, que geralmente é a penúltima\n  _minor version_.\n- Você deve ter também instalado localmente a ferramenta `kubectl`.\n\nConsulte a [Política de Suporte de Versões do Helm](https://helm.sh/docs/topics/version_skew/)\npara a máxima diferença de versões suportadas entre o Helm e o Kubernetes.\n\n## Instalando o Helm\n\nFaça o download do binário do cliente Helm. Você pode utilizar ferramentas\ncomo o `homebrew` ou pesquisar na [página oficial de _releases_ do Helm](https://github.com/helm/helm/releases).\n\nPara mais detalhes ou outras opções veja o [guia de instalação](/intro/install.md).\n\n## Inicialize um Repositório para os Charts do Helm {#initialize-a-helm-chart-repository}\n\nDepois de tudo pronto com a instalação do Helm você pode adicionar um repositório\nde Charts. Dê uma olhada no [Artifact Hub](https://artifacthub.io/packages/search?kind=0)\npara encontrar repositórios de Charts do Helm disponíveis.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nVocê poderá listar os Charts que deseja instalar do repositório recém adicionado:\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## Instalando um Chart de exemplo\n\nPara instalar um Chart você pode rodar o comando `helm install`. O Helm\ntem diversas formas de encontrar e instalar Charts, porém a mais fácil é utilizar\nos Charts da `bitnami`.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nNo exemplo acima o Chart `bitnami/mysql` foi aplicado no cluster e o\nnome da nossa nova _release_ é `mysql-1612624192`.\n\nVocê pode ter uma ideia das funcionalidades deste Chart MySQL ao rodar o comando\n`helm show chart bitnami/mysql`. Se você quiser ter uma visão completa execute o\ncomando `helm show all bitnami/mysql` para mais informações do Chart.\n\nSempre que você instalar um Chart uma nova _release_ é criada. Dessa forma um mesmo\nChart pode ser instalado diversas vezes em um mesmo cluster. Assim cada Chart pode\nser gerenciado e atualizado de forma independente.\n\nO comando `helm install` é bem poderoso e com muitas funcionalidades. Para saber\nmais acesse o [Guia de Utilização do Helm](/intro/using_helm.md).\n\n## Saiba mais sobre _Releases_\n\nÉ fácil visualizar o que foi aplicado utilizando o Helm:\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nO comando `helm list` (ou `helm ls`) irá lhe mostrar uma lista de todos os Charts\naplicados.\n\n## Desinstalando uma Release\n\nPara desinstalar uma _release_ utilize o comando `helm uninstall`:\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nO comando desinstalará o Chart `mysql-1612624192` do Kubernetes, assim como\ntodos os recursos associados a _release_, além  do histórico da _release_.\n\nSe o argumento `--keep-history` for passado, o histórico da _release_ será mantido.\nAssim será possível recuperar informações sobre a _release_ específica:\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nPelo fato do Helm monitorar as _releases_ até mesmo depois de desinstalá-las com\no argumento `--keep-history`, é possível auditar o histórico do cluster,\nsendo até mesmo capaz de recuperar a _release_ (com o comando `helm rollback`).\n\n## Ajuda no Cliente Helm\n\nUse `helm help` ou digite um comando seguido pelo argumento `-h`\npara saber mais sobre os comandos disponíveis no cliente Helm:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: Utilizando o Helm\ndescription: Explica os fundamentos do Helm.\nsidebar_position: 3\n---\n\nEsse guia explica os fundamentos da utilização do Helm para gerenciar pacotes\nem seu cluster Kubernetes. Ele assume que você já [instalou](/intro/install.md) o cliente Helm.\n\nSe você está simplesmente interessado em executar alguns comandos rápidos, talvez\nprefira começar pelo [Guia de Início Rápido](/intro/quickstart.md). Este capítulo\naborda os detalhes dos comandos do Helm e explica como utilizá-lo.\n\n## Três Grandes Conceitos\n\nUm *Chart* é um pacote do Helm. Ele contém todas as definições de recursos\nnecessárias para executar uma aplicação, ferramenta ou serviço dentro de um cluster\nKubernetes. Pense nele como o equivalente do Kubernetes a uma fórmula do Homebrew,\num pacote dpkg do Apt ou um arquivo RPM do Yum.\n\nUm *Repositório* é o lugar onde os Charts podem ser coletados e compartilhados. É como\no [arquivo CPAN](https://www.cpan.org) do Perl ou o [Banco de Dados de Pacotes do\nFedora](https://src.fedoraproject.org/), mas para pacotes Kubernetes.\n\nUma *Release* é uma instância de um Chart em execução em um cluster Kubernetes. Um Chart\nfrequentemente pode ser instalado várias vezes no mesmo cluster. E cada vez que é\ninstalado, uma nova _release_ é criada. Considere um Chart MySQL. Se você quer dois\nbancos de dados em execução em seu cluster, você pode instalar esse Chart duas vezes.\nCada um terá sua própria _release_, que por sua vez terá seu próprio _release name_.\n\nCom esses conceitos em mente, podemos explicar o Helm da seguinte forma:\n\nO Helm instala _charts_ no Kubernetes, criando uma nova _release_ para cada\ninstalação. E para encontrar novos Charts, você pode pesquisar em _repositórios_ de Charts do Helm.\n\n## 'helm search': Encontrando Charts\n\nO Helm vem com um poderoso comando de pesquisa. Ele pode ser utilizado para pesquisar dois\ntipos diferentes de fontes:\n\n- `helm search hub` pesquisa no [Artifact Hub](https://artifacthub.io), que\n  lista Charts do Helm de dezenas de repositórios diferentes.\n- `helm search repo` pesquisa nos repositórios que você adicionou ao seu cliente\n  Helm local (com `helm repo add`). Essa pesquisa é feita sobre dados locais, e\n  nenhuma conexão de rede pública é necessária.\n\nVocê pode encontrar Charts disponíveis publicamente executando `helm search hub`:\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\nO comando acima pesquisa todos os Charts de `wordpress` no Artifact Hub.\n\nSem nenhum filtro, `helm search hub` mostra todos os Charts disponíveis.\n\n`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]`.\n\nUsando `helm search repo`, você pode encontrar os nomes dos Charts nos repositórios\nque você já adicionou:\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nA pesquisa do Helm usa um algoritmo de correspondência aproximada de strings, então você pode digitar partes\nde palavras ou frases:\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nA pesquisa é uma boa maneira de encontrar pacotes disponíveis. Depois de encontrar um pacote\nque deseja instalar, você pode usar `helm install` para instalá-lo.\n\n## 'helm install': Instalando um Pacote\n\nPara instalar um novo pacote, use o comando `helm install`. Na sua forma mais simples, ele\nrecebe dois argumentos: um nome de release que você escolhe e o nome do Chart que\ndeseja instalar.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nAgora o Chart `wordpress` está instalado. Note que instalar um Chart cria um\nnovo objeto de _release_. A release acima é chamada `happy-panda`. (Se você quiser\nque o Helm gere um nome para você, omita o nome da release e use\n`--generate-name`.)\n\nDurante a instalação, o cliente `helm` imprimirá informações úteis sobre quais\nrecursos foram criados, qual é o estado da release, e também se há\netapas adicionais de configuração que você pode ou deve executar.\n\nO Helm instala os recursos na seguinte ordem:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nO Helm não espera até que todos os recursos estejam em execução antes de finalizar. Muitos\nCharts requerem imagens Docker com mais de 600MB de tamanho e podem levar muito\ntempo para serem instalados no cluster.\n\nPara acompanhar o estado de uma release ou reler informações de configuração, você\npode usar `helm status`:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nO comando acima mostra o estado atual da sua release.\n\n### Personalizando o Chart Antes de Instalar\n\nA instalação da forma que fizemos aqui usará apenas as opções de configuração padrão\npara este Chart. Muitas vezes, você vai querer personalizar o Chart para usar sua\nconfiguração preferida.\n\nPara ver quais opções são configuráveis em um Chart, use `helm show values`:\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nVocê pode então sobrescrever qualquer uma dessas configurações em um arquivo formatado em YAML e\npassá-lo durante a instalação.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nO comando acima criará um usuário MariaDB padrão com o nome `user0` e concederá\na esse usuário acesso a um banco de dados `user0db` recém-criado, mas aceitará todos os\noutros padrões desse Chart.\n\nExistem duas formas de passar dados de configuração durante a instalação:\n\n- `--values` (ou `-f`): Especifica um arquivo YAML com sobrescritas. Isso pode ser\n  especificado várias vezes, e o arquivo mais à direita terá precedência\n- `--set`: Especifica sobrescritas na linha de comando.\n\nSe ambos forem usados, os valores de `--set` são mesclados em `--values` com maior\nprecedência. As sobrescritas especificadas com `--set` são persistidas em um Secret.\nValores que foram definidos com `--set` podem ser visualizados para uma release específica com `helm get\nvalues <release-name>`. Valores que foram definidos com `--set` podem ser limpos executando\n`helm upgrade` com `--reset-values` especificado.\n\n#### Formato e Limitações do `--set`\n\nA opção `--set` recebe zero ou mais pares de nome/valor. Na sua forma mais simples, é\nusada assim: `--set name=value`. O equivalente em YAML seria:\n\n```yaml\nname: value\n```\n\nMúltiplos valores são separados por vírgulas. Então `--set a=b,c=d` se torna:\n\n```yaml\na: b\nc: d\n```\n\nExpressões mais complexas são suportadas. Por exemplo, `--set outer.inner=value`\né traduzido para:\n```yaml\nouter:\n  inner: value\n```\n\nListas podem ser expressas envolvendo valores em `{` e `}`. Por exemplo, `--set\nname={a, b, c}` se traduz em:\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nCertos nomes/chaves podem ser definidos como `null` ou como um array vazio `[]`. Por exemplo, `--set name=[],a=null` transforma\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\nem\n\n```yaml\nname: []\na: null\n```\n\nA partir do Helm 2.5.0, é possível acessar itens de lista usando uma sintaxe de índice\nde array. Por exemplo, `--set servers[0].port=80` se torna:\n\n```yaml\nservers:\n  - port: 80\n```\n\nMúltiplos valores podem ser definidos dessa forma. A linha `--set\nservers[0].port=80,servers[0].host=example` se torna:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nÀs vezes você precisa usar caracteres especiais nas suas linhas `--set`. Você pode usar\numa barra invertida para escapar os caracteres; `--set name=value1\\,value2` se tornará:\n\n```yaml\nname: \"value1,value2\"\n```\n\nDa mesma forma, você pode escapar sequências de pontos, o que pode ser útil quando\nos Charts usam a função `toYaml` para analisar annotations, labels e node\nselectors. A sintaxe de `--set nodeSelector.\"kubernetes\\.io/role\"=master`\nse torna:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nEstruturas de dados muito aninhadas podem ser difíceis de expressar usando `--set`. Recomenda-se\nque os desenvolvedores de Charts considerem o uso de `--set` ao projetar o formato\nde um arquivo `values.yaml` (consulte [Arquivos de Values](/chart_template_guide/values_files.md)).\n\n### Mais Métodos de Instalação\n\nO comando `helm install` pode instalar a partir de várias fontes:\n\n- Um repositório de Charts (como vimos acima)\n- Um arquivo de Chart local (`helm install foo foo-0.1.1.tgz`)\n- Um diretório de Chart descompactado (`helm install foo path/to/foo`)\n- Uma URL completa (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' e 'helm rollback': Atualizando uma Release e Revertendo em Caso de Falha\n\nQuando uma nova versão de um Chart é lançada, ou quando você quer alterar a\nconfiguração da sua release, você pode usar o comando `helm upgrade`.\n\nUm upgrade pega uma release existente e a atualiza de acordo com as\ninformações que você fornece. Como os Charts do Kubernetes podem ser grandes e complexos,\no Helm tenta realizar o upgrade menos invasivo possível. Ele atualizará apenas o que\nmudou desde a última release.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nNo caso acima, a release `happy-panda` é atualizada com o mesmo Chart,\nmas com um novo arquivo YAML:\n\n```yaml\nmariadb.auth.username: user1\n```\n\nPodemos usar `helm get values` para ver se essa nova configuração foi aplicada.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nO comando `helm get` é uma ferramenta útil para examinar uma release no cluster.\nE como podemos ver acima, ele mostra que nossos novos valores de `panda.yaml` foram\naplicados no cluster.\n\nAgora, se algo não sair como planejado durante uma release, é fácil reverter\npara uma release anterior usando `helm rollback [RELEASE] [REVISION]`.\n\n```console\n$ helm rollback happy-panda 1\n```\n\nO comando acima reverte nossa happy-panda para sua primeira versão de release. Uma\nversão de release é uma revisão incremental. Cada vez que uma instalação, upgrade ou\nrollback acontece, o número de revisão é incrementado em 1. O primeiro número de revisão\né sempre 1. E podemos usar `helm history [RELEASE]` para ver os números de revisão\nde uma release específica.\n\n## Opções Úteis para Install/Upgrade/Rollback\n\nExistem várias outras opções úteis que você pode especificar para personalizar o\ncomportamento do Helm durante uma instalação/upgrade/rollback. Por favor, note que esta não é\numa lista completa de flags do CLI. Para ver uma descrição de todas as flags, execute `helm\n<command> --help`.\n\n- `--timeout`: Um valor de [duração Go](https://golang.org/pkg/time/#ParseDuration)\n  para esperar a conclusão dos comandos do Kubernetes. O padrão é `5m0s`.\n- `--wait`: Aguarda até que todos os Pods estejam em estado pronto, PVCs estejam vinculados,\n  Deployments tenham o mínimo (`Desired` menos `maxUnavailable`) de Pods em estado\n  pronto e Services tenham um endereço IP (e Ingress se for um `LoadBalancer`) antes\n  de marcar a release como bem-sucedida. Aguardará pelo tempo definido em `--timeout`.\n  Se o timeout for atingido, a release será marcada como `FAILED`. Nota: Em\n  cenários onde o Deployment tem `replicas` definido como 1 e `maxUnavailable` não está\n  definido como 0 como parte da estratégia de rolling update, `--wait` retornará como pronto assim\n  que satisfizer a condição mínima de Pod pronto.\n- `--no-hooks`: Pula a execução dos hooks para o comando\n- `--recreate-pods` (disponível apenas para `upgrade` e `rollback`): Esta flag\n  fará com que todos os pods sejam recriados (com exceção de pods pertencentes a\n  deployments). (DESCONTINUADO no Helm 3)\n\n## 'helm uninstall': Desinstalando uma Release\n\nQuando chegar a hora de desinstalar uma release do cluster, use o comando `helm\nuninstall`:\n\n```console\n$ helm uninstall happy-panda\n```\n\nIsso removerá a release do cluster. Você pode ver todas as suas releases\natualmente implantadas com o comando `helm list`:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nNa saída acima, podemos ver que a release `happy-panda` foi\ndesinstalada.\n\nEm versões anteriores do Helm, quando uma release era excluída, um registro de sua\nexclusão permanecia. No Helm 3, a exclusão remove o registro da release também.\nSe você deseja manter um registro de exclusão da release, use `helm uninstall\n--keep-history`. Usando `helm list --uninstalled` mostrará apenas as releases que\nforam desinstaladas com a flag `--keep-history`.\n\nA flag `helm list --all` mostrará todos os registros de release que o Helm manteve,\nincluindo registros de itens com falha ou excluídos (se `--keep-history` foi\nespecificado):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nNote que, como as releases agora são excluídas por padrão, não é mais possível\nreverter um recurso desinstalado.\n\n## 'helm repo': Trabalhando com Repositórios\n\nO Helm 3 não vem mais com um repositório de Charts padrão. O grupo de comandos `helm repo`\nfornece comandos para adicionar, listar e remover repositórios.\n\nVocê pode ver quais repositórios estão configurados usando `helm repo list`:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nE novos repositórios podem ser adicionados com `helm repo add [NAME] [URL]`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nComo os repositórios de Charts mudam frequentemente, a qualquer momento você pode garantir\nque seu cliente Helm esteja atualizado executando `helm repo update`.\n\nRepositórios podem ser removidos com `helm repo remove`.\n\n## Criando Seus Próprios Charts\n\nO [Guia de Desenvolvimento de Charts](/topics/charts.md) explica como\ndesenvolver seus próprios Charts. Mas você pode começar rapidamente usando o comando `helm\ncreate`:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nAgora há um Chart em `./deis-workflow`. Você pode editá-lo e criar seus próprios\ntemplates.\n\nEnquanto edita seu Chart, você pode validar se ele está bem formado executando `helm\nlint`.\n\nQuando chegar a hora de empacotar o Chart para distribuição, você pode executar o comando `helm\npackage`:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nE esse Chart agora pode ser facilmente instalado com `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nCharts que são empacotados podem ser carregados em repositórios de Charts. Consulte a\ndocumentação sobre [repositórios de Charts do\nHelm](/topics/chart_repository.md) para mais detalhes.\n\n## Conclusão\n\nEste capítulo abordou os padrões básicos de uso do cliente `helm`,\nincluindo pesquisa, instalação, upgrade e desinstalação. Também abordou\ncomandos utilitários úteis como `helm status`, `helm get` e `helm repo`.\n\nPara mais informações sobre esses comandos, consulte a ajuda integrada do Helm:\n`helm help`.\n\nNo [próximo capítulo](/howto/charts_tips_and_tricks.md), veremos o processo de desenvolvimento de Charts.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: Introdução\ndescription: Apresenta o SDK Go do Helm\nsidebar_position: 1\n---\nO 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\n(Na verdade, a CLI do Helm é efetivamente apenas uma dessas ferramentas!)\n\nAtualmente, o SDK foi funcionalmente separado da CLI do Helm.\nO SDK pode ser (e é) utilizado por ferramentas independentes.\nO projeto Helm se comprometeu com a estabilidade da API para o SDK.\nVale 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.\n\nA 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).\n\nUma breve visão geral de alguns dos principais tipos de pacotes e um exemplo simples seguem abaixo.\nConsulte a seção [Exemplos](/sdk/examples.mdx) para mais exemplos e um 'driver' mais completo.\n\n## Visão geral dos principais pacotes\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action):\n  Contém o \"cliente\" principal para executar ações do Helm.\n  Este é o mesmo pacote que a CLI usa internamente.\n  Se você precisa apenas executar comandos básicos do Helm a partir de outro programa Go, este pacote é para você\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil):\n  Métodos e utilitários utilizados para carregar e manipular charts\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) e seus subpacotes:\n  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\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release):\n  Define o objeto `Release` e seus status\n\nExistem muitos outros pacotes além desses, então consulte a documentação para mais informações!\n\n### Exemplo simples\nEste é um exemplo simples de como executar um `helm list` usando o SDK Go.\nConsulte a seção [Exemplos](/sdk/examples.mdx) para exemplos mais completos.\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## Compatibilidade\n\nO SDK do Helm segue explicitamente as garantias de compatibilidade retroativa do Helm:\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\nOu seja, mudanças que quebram compatibilidade só serão feitas em versões principais (major).\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: Técnicas Avançadas do Helm\ndescription: Explica várias funcionalidades avançadas para usuários experientes do Helm\nsidebar_position: 9\n---\n\nEsta seção explica várias funcionalidades e técnicas avançadas para usar o Helm.\nAs informações nesta seção são destinadas a \"usuários experientes\" do Helm que\ndesejam fazer personalizações e manipulações avançadas de seus charts e releases.\nCada uma dessas funcionalidades avançadas vem com seus próprios compromissos e\nressalvas, então cada uma deve ser usada com cuidado e com conhecimento\naprofundado do Helm. Em outras palavras, lembre-se do [Princípio do Peter\nParker](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility).\n\n## Pós-Renderização\n\nA pós-renderização permite que instaladores de charts manipulem, configurem e/ou\nvalidem manualmente os manifests renderizados antes de serem instalados pelo\nHelm. Isso permite que usuários com necessidades de configuração avançadas usem\nferramentas como [`kustomize`](https://kustomize.io) para aplicar mudanças de\nconfiguração sem a necessidade de fazer fork de um chart público ou exigir que\nos mantenedores de charts especifiquem cada última opção de configuração para um\nsoftware. Também existem casos de uso para injetar ferramentas comuns e sidecars\nem ambientes corporativos ou análise dos manifests antes da implantação.\n\n### Pré-requisitos\n\n- Helm 3.1+\n\n### Uso\n\nUm pós-renderizador pode ser qualquer executável que aceite manifests Kubernetes\nrenderizados via STDIN e retorne manifests Kubernetes válidos via STDOUT. Ele\ndeve retornar um código de saída diferente de 0 em caso de falha. Esta é a única\n\"API\" entre os dois componentes. Isso permite grande flexibilidade no que você\npode fazer com seu processo de pós-renderização.\n\nUm pós-renderizador pode ser usado com `install`, `upgrade` e `template`. Para\nusar um pós-renderizador, use a flag `--post-renderer` com o caminho para o\nexecutável do renderizador que você deseja usar:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nSe o caminho não contiver nenhum separador, ele será buscado em $PATH, caso\ncontrário, caminhos relativos serão resolvidos para um caminho totalmente\nqualificado.\n\nSe você deseja usar múltiplos pós-renderizadores, chame todos eles em um script\nou em qualquer ferramenta binária que você tenha construído. Em bash, isso seria\ntão simples quanto `renderer1 | renderer2 | renderer3`.\n\nVocê pode ver um exemplo de uso do `kustomize` como pós-renderizador\n[aqui](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n### Ressalvas\n\nAo usar pós-renderizadores, existem várias coisas importantes a ter em mente.\nA mais importante delas é que, ao usar um pós-renderizador, todas as pessoas\nque modificam essa release **DEVEM** usar o mesmo renderizador para ter builds\nreprodutíveis. Esta funcionalidade foi propositalmente construída para permitir\nque qualquer usuário troque qual renderizador está usando ou pare de usar um\nrenderizador, mas isso deve ser feito deliberadamente para evitar modificações\nacidentais ou perda de dados.\n\nOutra nota importante é sobre segurança. Se você está usando um pós-renderizador,\nvocê deve garantir que ele venha de uma fonte confiável (como é o caso para\nqualquer outro executável arbitrário). Usar renderizadores não confiáveis ou não\nverificados NÃO é recomendado, pois eles têm acesso completo aos templates\nrenderizados, que frequentemente contêm dados sensíveis.\n\n### Pós-Renderizadores Personalizados\n\nO passo de pós-renderização oferece ainda mais flexibilidade quando usado no\nGo SDK. Qualquer pós-renderizador só precisa implementar a seguinte interface Go:\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nPara mais informações sobre como usar o Go SDK, veja a [seção Go SDK](#go-sdk).\n\n## Go SDK\n\nO Helm 3 introduziu um Go SDK completamente reestruturado para uma melhor\nexperiência ao construir software e ferramentas que aproveitam o Helm.\nDocumentação completa pode ser encontrada na [Seção Go SDK](/sdk/gosdk.md).\n\n## Backends de armazenamento\n\nO Helm 3 mudou o armazenamento padrão de informações de release para Secrets no\nnamespace da release. O Helm 2 armazenava por padrão informações de release como\nConfigMaps no namespace da instância do Tiller. As subseções a seguir mostram\ncomo configurar diferentes backends. Esta configuração é baseada na variável de\nambiente `HELM_DRIVER`. Ela pode ser definida como um dos valores:\n`[configmap, secret, sql]`.\n\n### Backend de armazenamento ConfigMap\n\nPara habilitar o backend ConfigMap, você precisará definir a variável de ambiente\n`HELM_DRIVER` para `configmap`.\n\nVocê pode defini-la no shell da seguinte forma:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nSe você deseja mudar do backend padrão para o backend ConfigMap, você terá que\nfazer a migração por conta própria. Você pode recuperar as informações de\nrelease com o seguinte comando:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**NOTAS DE PRODUÇÃO**: As informações de release incluem o conteúdo dos charts e\narquivos values, e portanto podem conter dados sensíveis (como senhas, chaves\nprivadas e outras credenciais) que precisam ser protegidos de acesso não\nautorizado. Ao gerenciar autorização no Kubernetes, por exemplo com\n[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), é possível\nconceder acesso mais amplo a recursos ConfigMap, enquanto restringe acesso a\nrecursos Secret. Por exemplo, a [role padrão voltada para\nusuários](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\n\"view\" concede acesso à maioria dos recursos, mas não a Secrets. Além disso, os\ndados de secrets podem ser configurados para [armazenamento\ncriptografado](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).\nPor favor, tenha isso em mente se você decidir mudar para o backend ConfigMap,\npois isso pode expor dados sensíveis da sua aplicação.\n\n### Backend de armazenamento SQL\n\nExiste um backend de armazenamento SQL em ***beta*** que armazena informações de\nrelease em um banco de dados SQL.\n\nUsar tal backend de armazenamento é particularmente útil se suas informações de\nrelease pesam mais de 1MB (nesse caso, não podem ser armazenadas em\nConfigMaps/Secrets devido a limites internos no armazenamento key-value etcd\nsubjacente do Kubernetes).\n\nPara habilitar o backend SQL, você precisará implantar um banco de dados SQL e\ndefinir a variável de ambiente `HELM_DRIVER` para `sql`. Os detalhes do banco\nde dados são definidos com a variável de ambiente\n`HELM_DRIVER_SQL_CONNECTION_STRING`.\n\nVocê pode defini-las no shell da seguinte forma:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Nota: Apenas PostgreSQL é suportado no momento.\n\n**NOTAS DE PRODUÇÃO**: É recomendado:\n- Deixar seu banco de dados pronto para produção. Para PostgreSQL, consulte a\ndocumentação de [Administração de Servidor](https://www.postgresql.org/docs/12/admin.html)\npara mais detalhes\n- Habilitar [gerenciamento de permissões](/topics/permissions_sql_storage_backend.md)\npara espelhar o RBAC do Kubernetes para informações de release\n\nSe você deseja mudar do backend padrão para o backend SQL, você terá que fazer a\nmigração por conta própria. Você pode recuperar as informações de release com o\nseguinte comando:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Arquitetura do Helm\ndescription: Descreve a arquitetura do Helm em alto nível.\nsidebar_position: 8\n---\n\n# Arquitetura do Helm\n\nEste documento descreve a arquitetura do Helm em alto nível.\n\n## O Propósito do Helm\n\nO Helm é uma ferramenta para gerenciar pacotes do Kubernetes chamados _charts_.\nO Helm pode fazer o seguinte:\n\n- Criar novos charts do zero\n- Empacotar charts em arquivos compactados (tgz)\n- Interagir com repositórios de charts onde os charts são armazenados\n- Instalar e desinstalar charts em um cluster Kubernetes existente\n- Gerenciar o ciclo de vida de releases de charts que foram instalados com o Helm\n\nPara o Helm, existem três conceitos importantes:\n\n1. O _chart_ é um pacote de informações necessárias para criar uma instância de\n   uma aplicação Kubernetes.\n2. A _config_ contém informações de configuração que podem ser mescladas em um\n   chart empacotado para criar um objeto de release.\n3. Uma _release_ é uma instância em execução de um _chart_, combinada com uma\n   _config_ específica.\n\n## Componentes\n\nO Helm é um executável que é implementado em duas partes distintas:\n\n**O Cliente Helm** é um cliente de linha de comando para usuários finais. O\ncliente é responsável pelo seguinte:\n\n- Desenvolvimento local de charts\n- Gerenciamento de repositórios\n- Gerenciamento de releases\n- Interface com a biblioteca do Helm\n  - Enviar charts para serem instalados\n  - Solicitar atualização ou desinstalação de releases existentes\n\n**A Biblioteca do Helm** fornece a lógica para executar todas as operações do\nHelm. Ela interage com o servidor de API do Kubernetes e oferece as seguintes\nfuncionalidades:\n\n- Combinar um chart e uma configuração para construir uma release\n- Instalar charts no Kubernetes e fornecer o objeto de release subsequente\n- Atualizar e desinstalar charts interagindo com o Kubernetes\n\nA biblioteca independente do Helm encapsula a lógica do Helm para que possa ser\naproveitada por diferentes clientes.\n\n## Implementação\n\nO cliente e a biblioteca do Helm são escritos na linguagem de programação Go.\n\nA biblioteca usa a biblioteca cliente do Kubernetes para se comunicar com o\nKubernetes. Atualmente, essa biblioteca usa REST+JSON. Ela armazena informações\nem Secrets localizados dentro do Kubernetes. Ela não necessita de um banco de\ndados próprio.\n\nOs arquivos de configuração são, quando possível, escritos em YAML.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: Guia do Repositório de Charts\ndescription: Como criar e trabalhar com repositórios de charts do Helm.\nsidebar_position: 6\n---\n\nEsta seção explica como criar e trabalhar com repositórios de charts do Helm. De\nforma geral, um repositório de charts é um local onde charts empacotados podem\nser armazenados e compartilhados.\n\nO repositório comunitário distribuído de charts do Helm está localizado no\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) e aceita\nparticipação. Mas o Helm também permite criar e executar seu próprio repositório\nde charts. Este guia explica como fazer isso. Se você está considerando criar um\nrepositório de charts, pode ser interessante considerar o uso de um\n[registry OCI](./registries.md) como alternativa.\n\n## Pré-requisitos\n\n* Consulte o guia de [Início Rápido](/intro/quickstart.md)\n* Leia o documento sobre [Charts](./charts.md)\n\n## Criar um repositório de charts\n\nUm _repositório de charts_ é um servidor HTTP que hospeda um arquivo\n`index.yaml` e, opcionalmente, alguns charts empacotados. Quando você estiver\npronto para compartilhar seus charts, a forma preferida de fazer isso é\nenviá-los para um repositório de charts.\n\nA partir do Helm 2.2.0, há suporte para autenticação SSL do lado do cliente em\num repositório. Outros protocolos de autenticação podem estar disponíveis como\nplugins.\n\nComo um repositório de charts pode ser qualquer servidor HTTP capaz de servir\narquivos YAML e tar e responder a requisições GET, há diversas opções para\nhospedar seu próprio repositório de charts. Por exemplo, você pode usar um\nbucket do Google Cloud Storage (GCS), um bucket do Amazon S3, GitHub Pages, ou\naté mesmo criar seu próprio servidor web.\n\n### A estrutura do repositório de charts\n\nUm repositório de charts consiste em charts empacotados e um arquivo especial\nchamado `index.yaml` que contém um índice de todos os charts no repositório.\nFrequentemente, os charts que o `index.yaml` descreve também são hospedados no\nmesmo servidor, assim como os [arquivos de proveniência](./provenance.md).\n\nPor exemplo, o layout do repositório `https://example.com/charts` pode ser assim:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nNeste caso, o arquivo de índice conteria informações sobre um chart, o chart\nAlpine, e forneceria a URL de download\n`https://example.com/charts/alpine-0.1.2.tgz` para esse chart.\n\nNão é obrigatório que o pacote do chart esteja localizado no mesmo servidor que\no arquivo `index.yaml`. No entanto, fazer isso é frequentemente a opção mais\nsimples.\n\n### O arquivo de índice\n\nO arquivo de índice é um arquivo yaml chamado `index.yaml`. Ele contém alguns\nmetadados sobre o pacote, incluindo o conteúdo do arquivo `Chart.yaml` do chart.\nUm repositório de charts válido deve ter um arquivo de índice. O arquivo de\níndice contém informações sobre cada chart no repositório de charts. O comando\n`helm repo index` gera um arquivo de índice com base em um diretório local que\ncontém charts empacotados.\n\nEste é um exemplo de um arquivo de índice:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Hospedando Repositórios de Charts\n\nEsta parte mostra várias formas de servir um repositório de charts.\n\n### Google Cloud Storage\n\nO primeiro passo é **criar seu bucket GCS**. Vamos chamar o nosso de\n`fantastic-charts`.\n\n![Criar um Bucket GCS](/img/helm2/create-a-bucket.png)\n\nEm seguida, torne seu bucket público **editando as permissões do bucket**.\n\n![Editar Permissões](/img/helm2/edit-permissions.png)\n\nInsira esta linha para **tornar seu bucket público**:\n\n![Tornar o Bucket Público](/img/helm2/make-bucket-public.png)\n\nParabéns, agora você tem um bucket GCS vazio pronto para servir charts!\n\nVocê pode enviar seu repositório de charts usando a ferramenta de linha de\ncomando do Google Cloud Storage ou usando a interface web do GCS. Um bucket GCS\npúblico pode ser acessado via HTTPS simples neste endereço:\n`https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith\n\nVocê também pode configurar repositórios de charts usando o Cloudsmith. Leia\nmais sobre repositórios de charts com Cloudsmith\n[aqui](https://help.cloudsmith.io/docs/helm-chart-repository)\n\n### JFrog Artifactory\n\nDa mesma forma, você também pode configurar repositórios de charts usando o\nJFrog Artifactory. Leia mais sobre repositórios de charts com JFrog Artifactory\n[aqui](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)\n\n### Exemplo com GitHub Pages\n\nDe maneira semelhante, você pode criar um repositório de charts usando GitHub\nPages.\n\nO GitHub permite servir páginas web estáticas de duas formas diferentes:\n\n- Configurando um projeto para servir o conteúdo do seu diretório `docs/`\n- Configurando um projeto para servir uma branch específica\n\nVamos usar a segunda abordagem, embora a primeira seja igualmente fácil.\n\nO primeiro passo será **criar sua branch gh-pages**. Você pode fazer isso\nlocalmente assim:\n\n```console\n$ git checkout -b gh-pages\n```\n\nOu pelo navegador web usando o botão **Branch** no seu repositório GitHub:\n\n![Criar branch GitHub Pages](/img/helm2/create-a-gh-page-button.png)\n\nEm seguida, você vai querer ter certeza de que sua **branch gh-pages** está\nconfigurada como GitHub Pages. Clique nas **Configurações** do seu repositório e\nrole para baixo até a seção **GitHub pages** e configure conforme abaixo:\n\n![Criar branch GitHub Pages](/img/helm2/set-a-gh-page.png)\n\nPor padrão, a **Source** geralmente é configurada para a **branch gh-pages**. Se\nisso não estiver configurado por padrão, selecione-a.\n\nVocê pode usar um **domínio personalizado** ali, se desejar.\n\nE verifique se **Enforce HTTPS** está marcado, para que o **HTTPS** seja usado\nquando os charts forem servidos.\n\nCom essa configuração, você pode usar sua branch padrão para armazenar o código\ndos seus charts, e a **branch gh-pages** como repositório de charts, por\nexemplo: `https://USERNAME.github.io/REPONAME`. O repositório de demonstração\n[TS Charts](https://github.com/technosophos/tscharts) está acessível em\n`https://technosophos.github.io/tscharts/`.\n\nSe você decidiu usar o GitHub Pages para hospedar o repositório de charts,\nconsulte a [Chart Releaser Action](/howto/chart_releaser_action.md). A Chart\nReleaser Action é um workflow do GitHub Action para transformar um projeto\nGitHub em um repositório de charts Helm auto-hospedado, usando a ferramenta CLI\n[helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n### Servidores web comuns\n\nPara configurar um servidor web comum para servir charts do Helm, você\nsimplesmente precisa fazer o seguinte:\n\n- Colocar seu índice e charts em um diretório que o servidor possa servir\n- Garantir que o arquivo `index.yaml` possa ser acessado sem requisitos de\n  autenticação\n- Garantir que arquivos `yaml` sejam servidos com o tipo de conteúdo correto\n  (`text/yaml` ou `text/x-yaml`)\n\nPor exemplo, se você quiser servir seus charts a partir de `$WEBROOT/charts`,\ncertifique-se de que existe um diretório `charts/` na raiz web, e coloque o\narquivo de índice e os charts dentro dessa pasta.\n\n### Servidor de Repositório ChartMuseum\n\nO ChartMuseum é um servidor de Repositório de Charts Helm de código aberto\nescrito em Go (Golang), com suporte para backends de armazenamento em nuvem,\nincluindo [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon\nS3](https://aws.amazon.com/s3/), [Microsoft Azure Blob\nStorage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba\nCloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object\nStorage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud\nInfrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud\nBOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object\nStorage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean\nSpaces](https://www.digitalocean.com/products/spaces/),\n[Minio](https://min.io/) e [etcd](https://etcd.io/).\n\nVocê também pode usar o servidor\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\npara hospedar um repositório de charts a partir de um sistema de arquivos local.\n\n### GitLab Package Registry\n\nCom o GitLab, você pode publicar charts Helm no Package Registry do seu projeto.\nLeia mais sobre como configurar um repositório de pacotes helm com o GitLab\n[aqui](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Gerenciando Repositórios de Charts\n\nAgora que você tem um repositório de charts, a última parte deste guia explica\ncomo manter charts nesse repositório.\n\n### Armazenar charts no seu repositório de charts\n\nAgora que você tem um repositório de charts, vamos fazer upload de um chart e um\narquivo de índice para o repositório. Charts em um repositório de charts devem\nser empacotados (`helm package chart-name/`) e versionados corretamente\n(seguindo as diretrizes do [SemVer 2](https://semver.org/)).\n\nOs próximos passos compõem um exemplo de fluxo de trabalho, mas você pode usar\nqualquer fluxo de trabalho que preferir para armazenar e atualizar charts no seu\nrepositório de charts.\n\nUma vez que você tenha um chart empacotado pronto, crie um novo diretório e mova\nseu chart empacotado para esse diretório.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nO último comando pega o caminho do diretório local que você acabou de criar e a\nURL do seu repositório de charts remoto e compõe um arquivo `index.yaml` dentro\ndo caminho do diretório fornecido.\n\nAgora você pode fazer upload do chart e do arquivo de índice para seu\nrepositório de charts usando uma ferramenta de sincronização ou manualmente. Se\nvocê estiver usando o Google Cloud Storage, confira este\n[exemplo de fluxo de trabalho](/howto/chart_repository_sync_example.md)\nusando o cliente gsutil. Para o GitHub, você pode simplesmente colocar os charts\nna branch de destino apropriada.\n\n### Adicionar novos charts a um repositório existente\n\nCada vez que você quiser adicionar um novo chart ao seu repositório, você deve\nregenerar o índice. O comando `helm repo index` irá reconstruir completamente o\narquivo `index.yaml` do zero, incluindo apenas os charts que encontrar\nlocalmente.\n\nNo entanto, você pode usar a flag `--merge` para adicionar incrementalmente\nnovos charts a um arquivo `index.yaml` existente (uma ótima opção ao trabalhar\ncom um repositório remoto como o GCS). Execute `helm repo index --help` para\nsaber mais.\n\nCertifique-se de fazer upload tanto do arquivo `index.yaml` revisado quanto do\nchart. E se você gerou um arquivo de proveniência, faça upload dele também.\n\n### Compartilhar seus charts com outros\n\nQuando estiver pronto para compartilhar seus charts, simplesmente informe a\nalguém qual é a URL do seu repositório.\n\nA partir daí, eles adicionarão o repositório ao seu cliente helm via o comando\n`helm repo add [NOME] [URL]` com qualquer nome que desejarem usar para\nreferenciar o repositório.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nSe os charts estiverem protegidos por autenticação básica HTTP, você também pode\nfornecer o nome de usuário e senha aqui:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Nota:** Um repositório não será adicionado se não contiver um `index.yaml`\nválido.\n\n**Nota:** Se seu repositório helm usa, por exemplo, um certificado\nautoassinado, você pode usar `helm repo add --insecure-skip-tls-verify ...` para\nignorar a verificação de CA.\n\nDepois disso, seus usuários poderão pesquisar seus charts. Após você atualizar o\nrepositório, eles podem usar o comando `helm repo update` para obter as\ninformações mais recentes do chart.\n\n*Por baixo dos panos, os comandos `helm repo add` e `helm repo update` buscam o\narquivo index.yaml e o armazenam no diretório\n`$XDG_CACHE_HOME/helm/repository/cache/`. É onde a função `helm search` encontra\ninformações sobre os charts.*\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: Testes de Chart\ndescription: Descreve como executar e testar seus charts.\nsidebar_position: 3\n---\n\nUm chart contém vários recursos e componentes do Kubernetes que funcionam\njuntos. Como autor de um chart, você pode querer escrever alguns testes que\nvalidem que seu chart funciona conforme esperado quando é instalado. Esses\ntestes também ajudam o consumidor do chart a entender o que seu chart deve\nfazer.\n\nUm **teste** em um chart Helm fica no diretório `templates/` e é uma definição\nde job que especifica um container com um comando dado para executar. O\ncontainer deve sair com sucesso (exit 0) para que o teste seja considerado\nbem-sucedido. A definição do job deve conter a anotação de hook de teste do\nHelm: `helm.sh/hook: test`.\n\nNote que até o Helm v3, a definição do job precisava conter uma dessas\nanotações de hook de teste do Helm: `helm.sh/hook: test-success` ou\n`helm.sh/hook: test-failure`. `helm.sh/hook: test-success` ainda é aceita como\numa alternativa para compatibilidade com versões anteriores de\n`helm.sh/hook: test`.\n\nExemplos de testes:\n\n- Validar que sua configuração do arquivo values.yaml foi injetada corretamente.\n  - Certificar-se de que seu nome de usuário e senha funcionam corretamente\n  - Certificar-se de que um nome de usuário e senha incorretos não funcionam\n- Verificar que seus serviços estão ativos e fazendo balanceamento de carga\n  corretamente\n- etc.\n\nVocê pode executar os testes pré-definidos no Helm em uma release usando o\ncomando `helm test <RELEASE_NAME>`. Para um consumidor de chart, esta é uma\nótima maneira de verificar que a release de um chart (ou aplicação) funciona\nconforme esperado.\n\n## Exemplo de Teste\n\nO comando [helm create](/helm/helm_create.md) criará automaticamente várias\npastas e arquivos. Para experimentar a funcionalidade de teste do Helm,\nprimeiro crie um chart Helm de demonstração.\n\n```console\n$ helm create demo\n```\n\nAgora você poderá ver a seguinte estrutura no seu chart Helm de demonstração.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nEm `demo/templates/tests/test-connection.yaml` você verá um teste que pode\nexperimentar. Você pode ver a definição do pod de teste do Helm aqui:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Passos para Executar uma Suíte de Testes em uma Release\n\nPrimeiro, instale o chart no seu cluster para criar uma release. Você pode\nprecisar esperar que todos os pods fiquem ativos; se você testar imediatamente\napós esta instalação, é provável que ocorra uma falha transitória, e você vai\nquerer testar novamente.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Notas\n\n- Você pode definir quantos testes quiser em um único arquivo yaml ou\n  distribuí-los em vários arquivos yaml no diretório `templates/`.\n- Você pode aninhar sua suíte de testes em um diretório `tests/` como\n  `<chart-name>/templates/tests/` para maior isolamento.\n- Um teste é um [hook do Helm](/topics/charts_hooks.md), então anotações como\n  `helm.sh/hook-weight` e `helm.sh/hook-delete-policy` podem ser usadas com\n  recursos de teste.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: Charts\ndescription: Explica o formato de chart e fornece orientações básicas para criar charts com o Helm.\nsidebar_position: 1\n---\n\nO Helm usa um formato de empacotamento chamado _charts_. Um chart é uma coleção\nde arquivos que descrevem um conjunto relacionado de recursos do Kubernetes. Um\núnico chart pode ser usado para implantar algo simples, como um pod do memcached,\nou algo complexo, como uma pilha completa de aplicação web com servidores HTTP,\nbancos de dados, caches e assim por diante.\n\nOs charts são criados como arquivos organizados em uma estrutura de diretórios\nespecífica. Eles podem ser empacotados em arquivos compactados versionados para\nserem implantados.\n\nSe você deseja baixar e examinar os arquivos de um chart publicado, sem\ninstalá-lo, você pode fazer isso com `helm pull chartrepo/chartname`.\n\nEste documento explica o formato de chart e fornece orientações básicas para\ncriar charts com o Helm.\n\n## A Estrutura de Arquivos do Chart\n\nUm chart é organizado como uma coleção de arquivos dentro de um diretório. O\nnome do diretório é o nome do chart (sem informações de versão). Assim, um chart\nque descreve o WordPress seria armazenado em um diretório `wordpress/`.\n\nDentro deste diretório, o Helm espera uma estrutura que corresponda a isto:\n\n```text\nwordpress/\n  Chart.yaml          # Um arquivo YAML contendo informações sobre o chart\n  LICENSE             # OPCIONAL: Um arquivo de texto simples contendo a licença do chart\n  README.md           # OPCIONAL: Um arquivo README legível\n  values.yaml         # Os valores de configuração padrão para este chart\n  values.schema.json  # OPCIONAL: Um JSON Schema para impor uma estrutura ao arquivo values.yaml\n  charts/             # Um diretório contendo quaisquer charts dos quais este chart depende.\n  crds/               # Custom Resource Definitions\n  templates/          # Um diretório de templates que, quando combinados com values,\n                      # irão gerar arquivos de manifesto Kubernetes válidos.\n  templates/NOTES.txt # OPCIONAL: Um arquivo de texto simples contendo notas de uso breves\n```\n\nO Helm reserva o uso dos diretórios `charts/`, `crds/` e `templates/`, e dos\nnomes de arquivos listados. Outros arquivos serão deixados como estão.\n\n## O Arquivo Chart.yaml\n\nO arquivo `Chart.yaml` é obrigatório para um chart. Ele contém os seguintes\ncampos:\n\n```yaml\napiVersion: A versão da API do chart (obrigatório)\nname: O nome do chart (obrigatório)\nversion: A versão do chart (obrigatório)\nkubeVersion: Um intervalo SemVer de versões compatíveis do Kubernetes (opcional)\ndescription: Uma descrição de uma frase deste projeto (opcional)\ntype: O tipo do chart (opcional)\nkeywords:\n  - Uma lista de palavras-chave sobre este projeto (opcional)\nhome: A URL da página inicial deste projeto (opcional)\nsources:\n  - Uma lista de URLs para o código-fonte deste projeto (opcional)\ndependencies: # Uma lista das dependências do chart (opcional)\n  - name: O nome do chart (nginx)\n    version: A versão do chart (\"1.2.3\")\n    repository: (opcional) A URL do repositório (\"https://example.com/charts\") ou alias (\"@repo-name\")\n    condition: (opcional) Um caminho yaml que resolve para um booleano, usado para habilitar/desabilitar charts (ex: subchart1.enabled)\n    tags: # (opcional)\n      - Tags podem ser usadas para agrupar charts para habilitar/desabilitar juntos\n    import-values: # (opcional)\n      - 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.\n    alias: (opcional) Alias a ser usado para o chart. Útil quando você precisa adicionar o mesmo chart várias vezes\nmaintainers: # (opcional)\n  - name: O nome do mantenedor (obrigatório para cada mantenedor)\n    email: O email do mantenedor (opcional para cada mantenedor)\n    url: Uma URL para o mantenedor (opcional para cada mantenedor)\nicon: Uma URL para uma imagem SVG ou PNG para ser usada como ícone (opcional).\nappVersion: A versão da aplicação que este contém (opcional). Não precisa ser SemVer. Aspas recomendadas.\ndeprecated: Se este chart está obsoleto (opcional, booleano)\nannotations:\n  example: Uma lista de anotações identificadas por nome (opcional).\n```\n\nA partir da [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), campos\nadicionais não são permitidos. A abordagem recomendada é adicionar metadados\npersonalizados em `annotations`.\n\n### Charts e Versionamento\n\nCada chart deve ter um número de versão. Uma versão deve seguir o padrão\n[SemVer 2](https://semver.org/spec/v2.0.0.html), mas não é rigorosamente\nobrigatório. Diferente do Helm Classic, o Helm v2 e posteriores usam números de\nversão como marcadores de release. Pacotes em repositórios são identificados por\nnome mais versão.\n\nPor exemplo, um chart `nginx` cujo campo de versão é definido como `version:\n1.2.3` será nomeado:\n\n```text\nnginx-1.2.3.tgz\n```\n\nNomes SemVer 2 mais complexos também são suportados, como `version:\n1.2.3-alpha.1+ef365`. Mas nomes não-SemVer são explicitamente proibidos pelo\nsistema. Exceções são feitas para versões no formato `x` ou `x.y`. Por exemplo,\nse houver um `v` inicial ou uma versão listada sem todas as 3 partes (ex: v1.2),\no sistema tentará convertê-la para uma versão semântica válida (ex: v1.2.0).\n\n**NOTA:** Enquanto o Helm Classic e o Deployment Manager eram muito orientados\nao GitHub quando se tratava de charts, o Helm v2 e posteriores não dependem ou\nexigem GitHub ou mesmo Git. Consequentemente, ele não usa Git SHAs para\nversionamento.\n\nO campo `version` dentro do `Chart.yaml` é usado por muitas ferramentas do Helm,\nincluindo a CLI. Ao gerar um pacote, o comando `helm package` usará a versão que\nencontrar no `Chart.yaml` como um token no nome do pacote. O sistema assume que\no número da versão no nome do pacote do chart corresponde ao número da versão no\n`Chart.yaml`. Se essa condição não for atendida, ocorrerá um erro.\n\n### O Campo `apiVersion`\n\nO campo `apiVersion` deve ser `v2` para charts Helm que requerem pelo menos Helm\n3. Charts que suportam versões anteriores do Helm têm um `apiVersion` definido\ncomo `v1` e ainda são instaláveis pelo Helm 3.\n\nMudanças de `v1` para `v2`:\n\n- Um campo `dependencies` definindo dependências do chart, que estavam\n  localizadas em um arquivo `requirements.yaml` separado para charts `v1` (veja\n  [Dependências do Chart](#dependências-do-chart)).\n- O campo `type`, discriminando charts de aplicação e biblioteca (veja [Tipos\n  de Chart](#tipos-de-chart)).\n\n### O Campo `appVersion`\n\nNote que o campo `appVersion` não está relacionado ao campo `version`. É uma\nforma de especificar a versão da aplicação. Por exemplo, o chart `drupal` pode\nter um `appVersion: \"8.2.1\"`, indicando que a versão do Drupal incluída no chart\n(por padrão) é `8.2.1`. Este campo é informativo e não tem impacto nos cálculos\nde versão do chart. Colocar a versão entre aspas é altamente recomendado. Isso\nforça o parser YAML a tratar o número da versão como uma string. Deixá-lo sem\naspas pode levar a problemas de parsing em alguns casos. Por exemplo, o YAML\ninterpreta `1.0` como um valor de ponto flutuante, e um SHA de commit git como\n`1234e10` como notação científica.\n\nA partir do Helm v3.5.0, `helm create` coloca o campo `appVersion` padrão entre\naspas.\n\n### O Campo `kubeVersion`\n\nO campo opcional `kubeVersion` pode definir restrições semver em versões\nsuportadas do Kubernetes. O Helm validará as restrições de versão ao instalar o\nchart e falhará se o cluster executar uma versão não suportada do Kubernetes.\n\nAs restrições de versão podem incluir comparações AND separadas por espaços como\n```\n>= 1.13.0 < 1.15.0\n```\nque podem ser combinadas com o operador OR `||` como no exemplo a seguir\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\nNeste exemplo, a versão `1.14.0` é excluída, o que pode fazer sentido se um bug\nem certas versões é conhecido por impedir o funcionamento adequado do chart.\n\nAlém das restrições de versão usando operadores `=` `!=` `>` `<` `>=` `<=`, as\nseguintes notações abreviadas são suportadas:\n\n * intervalos com hífen para intervalos fechados, onde `1.1 - 2.3.4` é\n   equivalente a `>= 1.1 <= 2.3.4`.\n * curingas `x`, `X` e `*`, onde `1.2.x` é equivalente a `>= 1.2.0 < 1.3.0`.\n * intervalos til (mudanças de versão patch permitidas), onde `~1.2.3` é\n   equivalente a `>= 1.2.3 < 1.3.0`.\n * intervalos circunflexo (mudanças de versão minor permitidas), onde `^1.2.3` é\n   equivalente a `>= 1.2.3 < 2.0.0`.\n\nPara uma explicação detalhada das restrições semver suportadas, veja\n[Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Descontinuando Charts\n\nAo gerenciar charts em um Repositório de Charts, às vezes é necessário\ndescontinuar um chart. O campo opcional `deprecated` no `Chart.yaml` pode ser\nusado para marcar um chart como descontinuado. Se a **última** versão de um\nchart no repositório estiver marcada como descontinuada, então o chart como um\ntodo é considerado descontinuado. O nome do chart pode ser reutilizado\nposteriormente publicando uma versão mais nova que não esteja marcada como\ndescontinuada. O fluxo de trabalho para descontinuar charts é:\n\n1. Atualizar o `Chart.yaml` do chart para marcá-lo como descontinuado,\n   incrementando a versão\n2. Publicar a nova versão do chart no Repositório de Charts\n3. Remover o chart do repositório de código-fonte (ex: git)\n\n### Tipos de Chart\n\nO campo `type` define o tipo do chart. Existem dois tipos: `application` e\n`library`. Application é o tipo padrão e é o chart padrão que pode ser operado\ncompletamente. O [chart de biblioteca](/topics/library_charts.md) fornece\nutilitários ou funções para o construtor do chart. Um chart de biblioteca\ndifere de um chart de aplicação porque não é instalável e geralmente não contém\nobjetos de recursos.\n\n**Nota:** Um chart de aplicação pode ser usado como um chart de biblioteca. Isso\né habilitado definindo o tipo como `library`. O chart será então renderizado\ncomo um chart de biblioteca onde todos os utilitários e funções podem ser\naproveitados. Todos os objetos de recursos do chart não serão renderizados.\n\n## Chart LICENSE, README e NOTES\n\nOs charts também podem conter arquivos que descrevem a instalação, configuração,\nuso e licença de um chart.\n\nUma LICENSE é um arquivo de texto simples contendo a\n[licença](https://en.wikipedia.org/wiki/Software_license) do chart. O chart pode\nconter uma licença pois pode ter lógica de programação nos templates e,\nportanto, não seria apenas configuração. Também pode haver licença(s) separadas\npara a aplicação instalada pelo chart, se necessário.\n\nUm README para um chart deve ser formatado em Markdown (README.md), e\ngeralmente deve conter:\n\n- Uma descrição da aplicação ou serviço que o chart fornece\n- Quaisquer pré-requisitos ou requisitos para executar o chart\n- Descrições das opções em `values.yaml` e valores padrão\n- Qualquer outra informação que possa ser relevante para a instalação ou\n  configuração do chart\n\nQuando hubs e outras interfaces de usuário exibem detalhes sobre um chart, esses\ndetalhes são extraídos do conteúdo do arquivo `README.md`.\n\nO chart também pode conter um breve arquivo de texto simples\n`templates/NOTES.txt` que será impresso após a instalação e ao visualizar o\nstatus de uma release. Este arquivo é avaliado como um\n[template](#templates-e-values), e pode ser usado para exibir notas de uso,\npróximos passos ou qualquer outra informação relevante para uma release do\nchart. Por exemplo, instruções podem ser fornecidas para conectar a um banco de\ndados ou acessar uma interface web. Como este arquivo é impresso no STDOUT ao\nexecutar `helm install` ou `helm status`, é recomendado manter o conteúdo breve\ne apontar para o README para mais detalhes.\n\n## Dependências do Chart\n\nNo Helm, um chart pode depender de qualquer número de outros charts. Essas\ndependências podem ser vinculadas dinamicamente usando o campo `dependencies` no\n`Chart.yaml` ou trazidas para o diretório `charts/` e gerenciadas manualmente.\n\n### Gerenciando Dependências com o campo `dependencies`\n\nOs charts requeridos pelo chart atual são definidos como uma lista no campo\n`dependencies`.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- O campo `name` é o nome do chart que você deseja.\n- O campo `version` é a versão do chart que você deseja.\n- O campo `repository` é a URL completa para o repositório de charts. Note que\n  você também deve usar `helm repo add` para adicionar esse repositório\n  localmente.\n- Você pode usar o nome do repositório em vez da URL\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nDepois de definir as dependências, você pode executar `helm dependency update` e\nele usará seu arquivo de dependências para baixar todos os charts especificados\npara o seu diretório `charts/`.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nQuando `helm dependency update` obtém os charts, ele os armazenará como arquivos\ncompactados de chart no diretório `charts/`. Então, para o exemplo acima, seria\nesperado ver os seguintes arquivos no diretório charts:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Campo alias em dependencies\n\nAlém dos outros campos acima, cada entrada de requisitos pode conter o campo\nopcional `alias`.\n\nAdicionar um alias para um chart de dependência colocaria um chart nas\ndependências usando o alias como nome da nova dependência.\n\nPode-se usar `alias` nos casos em que precisam acessar um chart com outro(s)\nnome(s).\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nNo exemplo acima, teremos 3 dependências no total para `parentchart`:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nA forma manual de conseguir isso é copiar/colar o mesmo chart no diretório\n`charts/` várias vezes com nomes diferentes.\n\n#### Campos Tags e Condition em dependencies\n\nAlém dos outros campos acima, cada entrada de requisitos pode conter os campos\nopcionais `tags` e `condition`.\n\nTodos os charts são carregados por padrão. Se os campos `tags` ou `condition`\nestiverem presentes, eles serão avaliados e usados para controlar o carregamento\ndo(s) chart(s) aos quais são aplicados.\n\nCondition - O campo condition contém um ou mais caminhos YAML (delimitados por\nvírgulas). Se este caminho existir nos values do pai de nível superior e\nresolver para um valor booleano, o chart será habilitado ou desabilitado com\nbase nesse valor booleano. Apenas o primeiro caminho válido encontrado na lista\né avaliado e se nenhum caminho existir, então a condição não tem efeito.\n\nTags - O campo tags é uma lista YAML de rótulos para associar com este chart.\nNos values do pai de nível superior, todos os charts com tags podem ser\nhabilitados ou desabilitados especificando a tag e um valor booleano.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nNo exemplo acima, todos os charts com a tag `front-end` seriam desabilitados,\nmas como o caminho `subchart1.enabled` avalia para 'true' nos values do pai, a\ncondição sobrescreverá a tag `front-end` e `subchart1` será habilitado.\n\nComo `subchart2` está marcado com `back-end` e essa tag avalia para `true`,\n`subchart2` será habilitado. Note também que embora `subchart2` tenha uma\ncondição especificada, não há caminho e valor correspondente nos values do pai,\nentão essa condição não tem efeito.\n\n##### Usando a CLI com Tags e Conditions\n\nO parâmetro `--set` pode ser usado como de costume para alterar valores de tags\ne conditions.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Resolução de Tags e Condition\n\n- **Conditions (quando definidas em values) sempre sobrescrevem tags.** O\n  primeiro caminho de condition que existir vence e os subsequentes para esse\n  chart são ignorados.\n- Tags são avaliadas como 'se qualquer uma das tags do chart for true, então\n  habilite o chart'.\n- Valores de tags e conditions devem ser definidos nos values do pai de nível\n  superior.\n- A chave `tags:` nos values deve ser uma chave de nível superior. Globals e\n  tabelas `tags:` aninhadas não são atualmente suportadas.\n\n#### Importando Child Values via dependencies\n\nEm alguns casos, é desejável permitir que os values de um chart filho se\npropaguem para o chart pai e sejam compartilhados como padrões comuns. Um\nbenefício adicional de usar o formato `exports` é que ele permitirá que\nferramentas futuras inspecionem valores configuráveis pelo usuário.\n\nAs chaves contendo os valores a serem importados podem ser especificadas no\ncampo `import-values` nas `dependencies` do chart pai usando uma lista YAML.\nCada item na lista é uma chave que é importada do campo `exports` do chart\nfilho.\n\nPara importar valores não contidos na chave `exports`, use o formato\n[child-parent](#usando-o-formato-child-parent). Exemplos de ambos os formatos\nsão descritos abaixo.\n\n##### Usando o formato exports\n\nSe o arquivo `values.yaml` de um chart filho contiver um campo `exports` na\nraiz, seu conteúdo pode ser importado diretamente para os values do pai\nespecificando as chaves a importar como no exemplo abaixo:\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\nComo estamos especificando a chave `data` em nossa lista de importação, o Helm\nprocura no campo `exports` do chart filho pela chave `data` e importa seu\nconteúdo.\n\nOs values finais do pai conteriam nosso campo exportado:\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\nNote que a chave pai `data` não está contida nos values finais do pai. Se você\nprecisar especificar a chave pai, use o formato 'child-parent'.\n\n##### Usando o formato child-parent\n\nPara acessar valores que não estão contidos na chave `exports` dos values do\nchart filho, você precisará especificar a chave de origem dos valores a serem\nimportados (`child`) e o caminho de destino nos values do chart pai (`parent`).\n\nO `import-values` no exemplo abaixo instrui o Helm a pegar quaisquer valores\nencontrados no caminho `child:` e copiá-los para os values do pai no caminho\nespecificado em `parent:`\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nNo exemplo acima, os valores encontrados em `default.data` nos values do\nsubchart1 serão importados para a chave `myimports` nos values do chart pai como\ndetalhado abaixo:\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nOs values resultantes do chart pai seriam:\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nOs values finais do pai agora contêm os campos `myint` e `mybool` importados do\nsubchart1.\n\n### Gerenciando Dependências manualmente via o diretório `charts/`\n\nSe mais controle sobre as dependências for desejado, essas dependências podem\nser expressas explicitamente copiando os charts de dependência para o diretório\n`charts/`.\n\nUma dependência deve ser um diretório de chart descompactado, mas seu nome não\npode começar com `_` ou `.`. Tais arquivos são ignorados pelo carregador de\ncharts.\n\nPor exemplo, se o chart WordPress depende do chart Apache, o chart Apache (da\nversão correta) é fornecido no diretório `charts/` do chart WordPress:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nO exemplo acima mostra como o chart WordPress expressa sua dependência do Apache\ne MySQL incluindo esses charts dentro de seu diretório `charts/`.\n\n**DICA:** _Para colocar uma dependência em seu diretório `charts/`, use o\ncomando `helm pull`_\n\n### Aspectos operacionais do uso de dependências\n\nAs seções acima explicam como especificar dependências de charts, mas como isso\nafeta a instalação de charts usando `helm install` e `helm upgrade`?\n\nSuponha que um chart chamado \"A\" crie os seguintes objetos Kubernetes\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nAlém disso, A é dependente do chart B que cria os objetos\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nApós a instalação/atualização do chart A, uma única release Helm é\ncriada/modificada. A release criará/atualizará todos os objetos Kubernetes acima\nna seguinte ordem:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nIsso ocorre porque quando o Helm instala/atualiza charts, os objetos Kubernetes\ndos charts e todas as suas dependências são\n\n- agregados em um único conjunto; então\n- ordenados por tipo seguido de nome; e então\n- criados/atualizados nessa ordem.\n\nPortanto, uma única release é criada com todos os objetos do chart e suas\ndependências.\n\nA ordem de instalação dos tipos Kubernetes é dada pela enumeração InstallOrder\nem kind_sorter.go (veja [o arquivo fonte do\nHelm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n## Templates e Values\n\nOs templates de Chart Helm são escritos na [linguagem de template\nGo](https://golang.org/pkg/text/template/), com a adição de 50 ou mais funções\nde template adicionais [da biblioteca\nSprig](https://github.com/Masterminds/sprig) e algumas outras [funções\nespecializadas](/howto/charts_tips_and_tricks.md).\n\nTodos os arquivos de template são armazenados na pasta `templates/` de um chart.\nQuando o Helm renderiza os charts, ele passará cada arquivo nesse diretório pelo\nmotor de templates.\n\nOs values para os templates são fornecidos de duas formas:\n\n- Desenvolvedores de charts podem fornecer um arquivo chamado `values.yaml`\n  dentro de um chart. Este arquivo pode conter valores padrão.\n- Usuários de charts podem fornecer um arquivo YAML que contém values. Isso pode\n  ser fornecido na linha de comando com `helm install`.\n\nQuando um usuário fornece values personalizados, esses valores sobrescreverão os\nvalores no arquivo `values.yaml` do chart.\n\n### Arquivos de Template\n\nOs arquivos de template seguem as convenções padrão para escrever templates Go\n(veja [a documentação do pacote Go\ntext/template](https://golang.org/pkg/text/template/) para detalhes). Um exemplo\nde arquivo de template pode parecer algo assim:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nO exemplo acima, baseado livremente em\n[https://github.com/deis/charts](https://github.com/deis/charts), é um template\npara um replication controller do Kubernetes. Ele pode usar os seguintes quatro\nvalores de template (geralmente definidos em um arquivo `values.yaml`):\n\n- `imageRegistry`: O registro de origem para a imagem Docker.\n- `dockerTag`: A tag para a imagem docker.\n- `pullPolicy`: A política de pull do Kubernetes.\n- `storage`: O backend de armazenamento, cujo padrão é definido como `\"minio\"`\n\nTodos esses valores são definidos pelo autor do template. O Helm não requer ou\ndetermina parâmetros.\n\nPara ver muitos charts funcionando, confira o [Artifact\nHub](https://artifacthub.io/packages/search?kind=0) da CNCF.\n\n### Values Predefinidos\n\nValues que são fornecidos via um arquivo `values.yaml` (ou via a flag `--set`)\nsão acessíveis a partir do objeto `.Values` em um template. Mas existem outros\ndados predefinidos que você pode acessar em seus templates.\n\nOs seguintes values são predefinidos, estão disponíveis para todo template, e\nnão podem ser sobrescritos. Como todos os values, os nomes diferenciam maiúsculas\nde minúsculas.\n\n- `Release.Name`: O nome da release (não o chart)\n- `Release.Namespace`: O namespace em que o chart foi liberado.\n- `Release.Service`: O serviço que conduziu a release.\n- `Release.IsUpgrade`: Isso é definido como true se a operação atual for um\n  upgrade ou rollback.\n- `Release.IsInstall`: Isso é definido como true se a operação atual for uma\n  instalação.\n- `Chart`: O conteúdo do `Chart.yaml`. Assim, a versão do chart é obtida como\n  `Chart.Version` e os mantenedores estão em `Chart.Maintainers`.\n- `Files`: Um objeto semelhante a um mapa contendo todos os arquivos não especiais no\n  chart. Isso não dará acesso a templates, mas dará acesso a arquivos adicionais\n  que estão presentes (a menos que sejam excluídos usando `.helmignore`).\n  Arquivos podem ser acessados usando `{{ index .Files \"file.name\" }}` ou usando\n  a função `{{.Files.Get name }}`. Você também pode acessar o conteúdo do\n  arquivo como `[]byte` usando `{{ .Files.GetBytes }}`\n- `Capabilities`: Um objeto semelhante a um mapa que contém informações sobre as versões do\n  Kubernetes (`{{ .Capabilities.KubeVersion }}`) e as versões de API do\n  Kubernetes suportadas (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n**NOTA:** Qualquer campo desconhecido do `Chart.yaml` será descartado. Eles não\nserão acessíveis dentro do objeto `Chart`. Assim, `Chart.yaml` não pode ser\nusado para passar dados estruturados arbitrariamente para o template. O arquivo\nvalues pode ser usado para isso.\n\n### Arquivos de Values\n\nConsiderando o template na seção anterior, um arquivo `values.yaml` que fornece\nos valores necessários seria assim:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nUm arquivo de values é formatado em YAML. Um chart pode incluir um arquivo\n`values.yaml` padrão. O comando helm install permite que um usuário sobrescreva\nvalores fornecendo valores YAML adicionais:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nQuando os values são passados desta forma, eles serão mesclados no arquivo de\nvalues padrão. Por exemplo, considere um arquivo `myvals.yaml` que se parece com\nisto:\n\n```yaml\nstorage: \"gcs\"\n```\n\nQuando isso é mesclado com o `values.yaml` no chart, o conteúdo gerado\nresultante será:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nNote que apenas o último campo foi sobrescrito.\n\n**NOTA:** O arquivo de values padrão incluído dentro de um chart _deve_ ser\nnomeado `values.yaml`. Mas arquivos especificados na linha de comando podem ter\nqualquer nome.\n\n**NOTA:** Se a flag `--set` for usada em `helm install` ou `helm upgrade`, esses\nvalores são simplesmente convertidos para YAML no lado do cliente.\n\n**NOTA:** Se existirem entradas obrigatórias no arquivo de values, elas podem\nser declaradas como obrigatórias no template do chart usando a [função\n'required'](/howto/charts_tips_and_tricks.md)\n\nQualquer um desses valores é então acessível dentro de templates usando o objeto\n`.Values`:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Escopo, Dependências e Values\n\nArquivos de values podem declarar valores para o chart de nível superior, bem\ncomo para qualquer um dos charts que estão incluídos no diretório `charts/`\ndesse chart. Ou, para colocar de outra forma, um arquivo de values pode fornecer\nvalores para o chart assim como para qualquer uma de suas dependências. Por\nexemplo, o chart de demonstração WordPress acima tem tanto `mysql` quanto\n`apache` como dependências. O arquivo de values poderia fornecer valores para\ntodos esses componentes:\n\n```yaml\ntitle: \"My WordPress Site\" # Enviado para o template WordPress\n\nmysql:\n  max_connections: 100 # Enviado para MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passado para Apache\n```\n\nCharts de níveis superiores têm acesso a todas as variáveis definidas abaixo.\nEntão o chart WordPress pode acessar a senha do MySQL como\n`.Values.mysql.password`. Mas charts de níveis inferiores não podem acessar\ncoisas em charts pais, então MySQL não será capaz de acessar a propriedade\n`title`. Nem, aliás, pode acessar `apache.port`.\n\nOs values têm namespaces, mas os namespaces são podados. Então para o chart\nWordPress, ele pode acessar o campo de senha do MySQL como\n`.Values.mysql.password`. Mas para o chart MySQL, o escopo dos values foi\nreduzido e o prefixo de namespace removido, então ele verá o campo password\nsimplesmente como `.Values.password`.\n\n#### Global Values\n\nA partir da versão 2.0.0-Alpha.2, o Helm suporta um \"global\" value especial.\nConsidere esta versão modificada do exemplo anterior:\n\n```yaml\ntitle: \"My WordPress Site\" # Enviado para o template WordPress\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Enviado para MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passado para Apache\n```\n\nO acima adiciona uma seção `global` com o valor `app: MyWordPress`. Este valor\nestá disponível para _todos_ os charts como `.Values.global.app`.\n\nPor exemplo, os templates `mysql` podem acessar `app` como `{{\n.Values.global.app}}`, e assim pode o chart `apache`. Efetivamente, o arquivo de\nvalues acima é regenerado assim:\n\n```yaml\ntitle: \"My WordPress Site\" # Enviado para o template WordPress\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Enviado para MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passado para Apache\n```\n\nIsso fornece uma maneira de compartilhar uma variável de nível superior com\ntodos os subcharts, o que é útil para coisas como definir propriedades de\n`metadata` como labels.\n\nSe um subchart declarar uma variável global, essa global será passada _para\nbaixo_ (para os subcharts do subchart), mas não _para cima_ para o chart pai.\nNão há como um subchart influenciar os values do chart pai.\n\nAlém disso, variáveis globais de charts pais têm precedência sobre as variáveis\nglobais de subcharts.\n\n### Arquivos de Schema\n\nÀs vezes, um mantenedor de chart pode querer definir uma estrutura em seus\nvalues. Isso pode ser feito definindo um schema no arquivo `values.schema.json`.\nUm schema é representado como um [JSON Schema](https://json-schema.org/). Pode\nparecer algo assim:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nEste schema será aplicado aos values para validá-lo. A validação ocorre quando\nqualquer um dos seguintes comandos é invocado:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nUm exemplo de um arquivo `values.yaml` que atende aos requisitos deste schema\npode parecer algo assim:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nNote que o schema é aplicado ao objeto `.Values` final, e não apenas ao arquivo\n`values.yaml`. Isso significa que o seguinte arquivo `yaml` é válido, dado que o\nchart é instalado com a opção `--set` apropriada mostrada abaixo.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nAlém disso, o objeto `.Values` final é verificado contra *todos* os schemas de\nsubcharts. Isso significa que restrições em um subchart não podem ser\ncontornadas por um chart pai. Isso também funciona ao contrário - se um subchart\ntem um requisito que não é atendido no arquivo `values.yaml` do subchart, o\nchart pai *deve* satisfazer essas restrições para ser válido.\n\nA validação de schema pode ser desabilitada definindo a opção mostrada abaixo.\nIsso é particularmente útil em ambientes air-gapped quando o arquivo JSON Schema\nde um chart contém referências remotas.\n```console\nhelm install --skip-schema-validation\n```\n\n### Referências\n\nQuando se trata de escrever templates, values e arquivos de schema, existem\nvárias referências padrão que ajudarão você.\n\n- [Templates Go](https://godoc.org/text/template)\n- [Funções de template extras](https://godoc.org/github.com/Masterminds/sprig)\n- [O formato YAML](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRDs)\n\nO Kubernetes fornece um mecanismo para declarar novos tipos de objetos\nKubernetes. Usando CustomResourceDefinitions (CRDs), desenvolvedores Kubernetes\npodem declarar tipos de recursos personalizados.\n\nNo Helm 3, CRDs são tratados como um tipo especial de objeto. Eles são\ninstalados antes do resto do chart e estão sujeitos a algumas limitações.\n\nArquivos YAML de CRD devem ser colocados no diretório `crds/` dentro de um\nchart. Múltiplos CRDs (separados por marcadores de início e fim YAML) podem ser\ncolocados no mesmo arquivo. O Helm tentará carregar _todos_ os arquivos no\ndiretório CRD para o Kubernetes.\n\nArquivos CRD _não podem conter templates_. Eles devem ser documentos YAML\nsimples.\n\nQuando o Helm instala um novo chart, ele fará upload dos CRDs, pausará até que\nos CRDs estejam disponíveis pelo servidor de API, e então iniciará o motor de\ntemplates, renderizará o resto do chart, e fará upload para o Kubernetes. Por\ncausa dessa ordenação, informações de CRD estão disponíveis no objeto\n`.Capabilities` nos templates Helm, e templates Helm podem criar novas\ninstâncias de objetos que foram declarados em CRDs.\n\nPor exemplo, se seu chart tiver um CRD para `CronTab` no diretório `crds/`, você\npode criar instâncias do kind `CronTab` no diretório `templates/`:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nO arquivo `crontab.yaml` deve conter o CRD sem diretivas de template:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nEntão o template `mycrontab.yaml` pode criar um novo `CronTab` (usando templates\ncomo de costume):\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nO Helm garantirá que o kind `CronTab` foi instalado e está disponível no\nservidor de API do Kubernetes antes de prosseguir instalando as coisas em\n`templates/`.\n\n### Limitações em CRDs\n\nDiferente da maioria dos objetos no Kubernetes, CRDs são instalados globalmente.\nPor essa razão, o Helm adota uma abordagem muito cautelosa no gerenciamento de\nCRDs. CRDs estão sujeitos às seguintes limitações:\n\n- CRDs nunca são reinstalados. Se o Helm determinar que os CRDs no diretório\n  `crds/` já estão presentes (independentemente da versão), o Helm não tentará\n  instalar ou atualizar.\n- CRDs nunca são instalados em upgrade ou rollback. O Helm só criará CRDs em\n  operações de instalação.\n- CRDs nunca são deletados. Deletar um CRD automaticamente deleta todo o\n  conteúdo do CRD em todos os namespaces no cluster. Consequentemente, o Helm\n  não deletará CRDs.\n\nOperadores que desejam atualizar ou deletar CRDs são encorajados a fazer isso\nmanualmente e com muito cuidado.\n\n## Usando o Helm para Gerenciar Charts\n\nA ferramenta `helm` tem vários comandos para trabalhar com charts.\n\nEla pode criar um novo chart para você:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nUma vez que você tenha editado um chart, `helm` pode empacotá-lo em um arquivo\ncompactado de chart para você:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nVocê também pode usar `helm` para ajudá-lo a encontrar problemas com a\nformatação ou informações do seu chart:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Repositórios de Charts\n\nUm _repositório de charts_ é um servidor HTTP que hospeda um ou mais charts\nempacotados. Embora `helm` possa ser usado para gerenciar diretórios de charts\nlocais, quando se trata de compartilhar charts, o mecanismo preferido é um\nrepositório de charts.\n\nQualquer servidor HTTP que pode servir arquivos YAML e tar e pode responder\nrequisições GET pode ser usado como um servidor de repositório. A equipe do Helm\ntestou alguns servidores, incluindo Google Cloud Storage com modo website\nhabilitado, e S3 com modo website habilitado.\n\nUm repositório é caracterizado principalmente pela presença de um arquivo\nespecial chamado `index.yaml` que tem uma lista de todos os pacotes fornecidos\npelo repositório, junto com metadados que permitem obter e verificar esses\npacotes.\n\nNo lado do cliente, repositórios são gerenciados com os comandos `helm repo`. No\nentanto, o Helm não fornece ferramentas para fazer upload de charts para\nservidores de repositório remotos. Isso ocorre porque fazer isso adicionaria\nrequisitos substanciais a um servidor implementador, e assim aumentaria a\nbarreira para configurar um repositório.\n\n## Chart Starter Packs\n\nO comando `helm create` aceita uma opção opcional `--starter` que permite\nespecificar um \"starter chart\". A opção starter também tem um alias curto `-p`.\n\nExemplos de uso:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nStarters são apenas charts regulares, mas estão localizados em\n`$XDG_DATA_HOME/helm/starters`. Como desenvolvedor de charts, você pode criar\ncharts que são especificamente projetados para serem usados como starters. Tais\ncharts devem ser projetados com as seguintes considerações em mente:\n\n- O `Chart.yaml` será sobrescrito pelo gerador.\n- Os usuários esperarão modificar o conteúdo de tal chart, então a documentação\n  deve indicar como os usuários podem fazer isso.\n- Todas as ocorrências de `<CHARTNAME>` serão substituídas pelo nome do chart\n  especificado para que starter charts possam ser usados como templates, exceto\n  para alguns arquivos variáveis. Por exemplo, se você usar arquivos\n  personalizados no diretório `vars` ou certos arquivos `README.md`,\n  `<CHARTNAME>` NÃO será substituído dentro deles. Além disso, a descrição do\n  chart não é herdada.\n\nAtualmente, a única maneira de adicionar um chart a `$XDG_DATA_HOME/helm/starters`\né copiá-lo manualmente para lá. Na documentação do seu chart, você pode querer\nexplicar esse processo.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: Hooks de Chart\ndescription: Descreve como trabalhar com hooks de chart.\nsidebar_position: 2\n---\n\nO Helm fornece um mecanismo de _hook_ que permite aos desenvolvedores de charts\nintervir em certos pontos do ciclo de vida de uma release. Por exemplo, você\npode usar hooks para:\n\n- Carregar um ConfigMap ou Secret durante a instalação antes que qualquer outro\n  chart seja carregado.\n- Executar um Job para fazer backup de um banco de dados antes de instalar um\n  novo chart, e então executar um segundo job após a atualização para restaurar\n  os dados.\n- Executar um Job antes de deletar uma release para retirar um serviço de\n  operação de forma controlada antes de removê-lo.\n\nOs hooks funcionam como templates normais, mas possuem anotações especiais que\nfazem com que o Helm os utilize de forma diferente. Nesta seção, abordamos o\npadrão básico de uso de hooks.\n\n## Os Hooks Disponíveis\n\nOs seguintes hooks são definidos:\n\n| Valor da Anotação  | Descrição                                                                                             |\n| ------------------ | ----------------------------------------------------------------------------------------------------- |\n| `pre-install`      | Executa após os templates serem renderizados, mas antes de qualquer recurso ser criado no Kubernetes  |\n| `post-install`     | Executa após todos os recursos serem carregados no Kubernetes                                         |\n| `pre-delete`       | Executa em uma requisição de exclusão antes de qualquer recurso ser deletado do Kubernetes            |\n| `post-delete`      | Executa em uma requisição de exclusão após todos os recursos da release terem sido deletados          |\n| `pre-upgrade`      | Executa em uma requisição de upgrade após os templates serem renderizados, mas antes de qualquer recurso ser atualizado |\n| `post-upgrade`     | Executa em uma requisição de upgrade após todos os recursos terem sido atualizados                    |\n| `pre-rollback`     | Executa em uma requisição de rollback após os templates serem renderizados, mas antes de qualquer recurso ser revertido |\n| `post-rollback`    | Executa em uma requisição de rollback após todos os recursos terem sido modificados                   |\n| `test`             | Executa quando o subcomando helm test é invocado ([veja a documentação de testes](/topics/chart_tests.md)) |\n\n_Nota: o hook `crd-install` foi removido em favor do diretório `crds/` no\nHelm 3._\n\n## Hooks e o Ciclo de Vida da Release\n\nHooks permitem que você, o desenvolvedor do chart, tenha a oportunidade de\nrealizar operações em pontos estratégicos do ciclo de vida de uma release. Por\nexemplo, considere o ciclo de vida para um `helm install`. Por padrão, o ciclo\nde vida se parece com isto:\n\n1. Usuário executa `helm install foo`\n2. A API de instalação da biblioteca Helm é chamada\n3. Após alguma verificação, a biblioteca renderiza os templates de `foo`\n4. A biblioteca carrega os recursos resultantes no Kubernetes\n5. A biblioteca retorna o objeto da release (e outros dados) para o cliente\n6. O cliente encerra\n\nO Helm define dois hooks para o ciclo de vida do `install`: `pre-install` e\n`post-install`. Se o desenvolvedor do chart `foo` implementar ambos os hooks, o\nciclo de vida é alterado desta forma:\n\n1. Usuário executa `helm install foo`\n2. A API de instalação da biblioteca Helm é chamada\n3. CRDs no diretório `crds/` são instalados\n4. Após alguma verificação, a biblioteca renderiza os templates de `foo`\n5. A biblioteca se prepara para executar os hooks `pre-install` (carregando\n   recursos de hook no Kubernetes)\n6. A biblioteca ordena os hooks por peso (atribuindo um peso de 0 por padrão),\n   pelo tipo de recurso e finalmente pelo nome em ordem crescente.\n7. A biblioteca então carrega o hook com o menor peso primeiro (negativo para\n   positivo)\n8. A biblioteca espera até que o hook esteja \"Pronto\" (exceto para CRDs)\n9. A biblioteca carrega os recursos resultantes no Kubernetes. Note que se a\n   flag `--wait` estiver definida, a biblioteca esperará até que todos os\n   recursos estejam em estado pronto e não executará o hook `post-install` até\n   que estejam prontos.\n10. A biblioteca executa o hook `post-install` (carregando recursos de hook)\n11. A biblioteca espera até que o hook esteja \"Pronto\"\n12. A biblioteca retorna o objeto da release (e outros dados) para o cliente\n13. O cliente encerra\n\nO que significa esperar até que um hook esteja pronto? Isso depende do recurso\ndeclarado no hook. Se o recurso for do tipo `Job` ou `Pod`, o Helm esperará até\nque ele seja executado com sucesso até a conclusão. E se o hook falhar, a\nrelease falhará. Esta é uma _operação bloqueante_, então o cliente Helm pausará\nenquanto o Job é executado.\n\nPara todos os outros tipos, assim que o Kubernetes marcar o recurso como\ncarregado (adicionado ou atualizado), o recurso é considerado \"Pronto\". Quando\nmuitos recursos são declarados em um hook, os recursos são executados em série.\nSe eles tiverem pesos de hook (veja abaixo), são executados em ordem de peso.\nA partir do Helm 3.2.0, recursos de hook com o mesmo peso são instalados na\nmesma ordem que os recursos normais não-hook. Caso contrário, a ordenação não é\ngarantida. (No Helm 2.3.0 e posteriores, eles são ordenados alfabeticamente.\nEsse comportamento, no entanto, não é considerado vinculante e pode mudar no\nfuturo.) É considerado boa prática adicionar um peso de hook, e definí-lo como\n`0` se o peso não for importante.\n\n### Recursos de hook não são gerenciados com as releases correspondentes\n\nOs recursos que um hook cria atualmente não são rastreados ou gerenciados como\nparte da release. Assim que o Helm verificar que o hook atingiu seu estado\npronto, ele deixará o recurso de hook intocado. A coleta de lixo de recursos de\nhook quando a release correspondente é deletada pode ser adicionada ao Helm 3 no\nfuturo, portanto qualquer recurso de hook que nunca deve ser deletado deve ser\nanotado com `helm.sh/resource-policy: keep`.\n\nNa prática, isso significa que se você criar recursos em um hook, você não pode\ndepender do `helm uninstall` para remover os recursos. Para destruir tais\nrecursos, você precisa ou [adicionar uma anotação personalizada\n`helm.sh/hook-delete-policy`](#hook-deletion-policies) ao arquivo de template do\nhook, ou [definir o campo time to live (TTL) de um recurso\nJob](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Escrevendo um Hook\n\nOs hooks são simplesmente arquivos de manifesto Kubernetes com anotações\nespeciais na seção `metadata`. Como são arquivos de template, você pode usar\ntodos os recursos normais de template, incluindo ler `.Values`, `.Release` e\n`.Template`.\n\nPor exemplo, este template, armazenado em `templates/post-install-job.yaml`,\ndeclara um job para ser executado em `post-install`:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nO que faz este template um hook é a anotação:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nUm recurso pode implementar múltiplos hooks:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nDa mesma forma, não há limite para o número de recursos diferentes que podem\nimplementar um dado hook. Por exemplo, pode-se declarar tanto um secret quanto\num config map como um hook pre-install.\n\nQuando subcharts declaram hooks, esses também são avaliados. Não há como um\nchart de nível superior desabilitar os hooks declarados por subcharts.\n\nÉ possível definir um peso para um hook que ajudará a construir uma ordem de\nexecução determinística. Pesos são definidos usando a seguinte anotação:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nPesos de hook podem ser números positivos ou negativos, mas devem ser\nrepresentados como strings. Quando o Helm inicia o ciclo de execução de hooks de\num tipo particular, ele ordenará esses hooks em ordem crescente.\n\n### Políticas de exclusão de hook\n\nÉ possível definir políticas que determinam quando deletar os recursos de hook\ncorrespondentes. Políticas de exclusão de hook são definidas usando a seguinte\nanotação:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nVocê pode escolher um ou mais valores de anotação definidos:\n\n| Valor da Anotação      | Descrição                                                                |\n| ---------------------- | ------------------------------------------------------------------------ |\n| `before-hook-creation` | Deleta o recurso anterior antes que um novo hook seja lançado (padrão)   |\n| `hook-succeeded`       | Deleta o recurso após o hook ser executado com sucesso                   |\n| `hook-failed`          | Deleta o recurso se o hook falhou durante a execução                     |\n\nSe nenhuma anotação de política de exclusão de hook for especificada, o\ncomportamento `before-hook-creation` é aplicado por padrão.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/index.mdx",
    "content": "---\ntitle: Guias Temáticos\nsidebar_position: 3\n---\n\n# Guias Temáticos\n\nAqui você encontrará introdução a todos os principais conceitos do Helm que você\nprecisará saber.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: APIs do Kubernetes Obsoletas\ndescription: Explica APIs do Kubernetes obsoletas no Helm\n---\n\nO 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.\n\nA [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.\n\nEste é 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.\n\nOs 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.\n\n## Mantenedores de Charts\n\nVocê 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:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Usuários do Helm\n\nVocê 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.\n\nAlé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`.\n\nA forma de atualizar um release do Helm para APIs suportadas depende das suas descobertas, conforme segue:\n\n1. Se você encontrar apenas versões de API obsoletas:\n  - Execute um `helm upgrade` com uma versão do chart que possui versões de API do Kubernetes suportadas\n  - Adicione uma descrição no upgrade, algo como \"não realizar rollback para uma versão do Helm anterior a esta versão atual\"\n2. Se você encontrar alguma versão de API que foi removida em uma versão do Kubernetes:\n  - 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):\n    - Siga o procedimento do passo 1\n  - 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):\n    - 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\n\n> 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.\n\n> 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.\n\nSe 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):\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nO 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.\n\n## Atualizando Versões de API de um Manifesto de Release\n\nO 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.\n\nVocê 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.\n\nAlternativamente, 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.\n\n- Obtenha o nome do Secret ou ConfigMap associado ao último release implantado:\n  - Backend Secrets: `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - Backend ConfigMap: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- Obtenha os detalhes do último release implantado:\n  - Backend Secrets: `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - Backend ConfigMap: `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- Faça backup do release caso precise restaurar se algo der errado:\n  - `cp release.yaml release.bak`\n  - Em caso de emergência, restaure: `kubectl apply -f release.bak -n\n    <release_namespace>`\n- Decodifique o objeto release:\n  - Backend Secrets: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - Backend ConfigMap: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- 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`)\n- Codifique o objeto release:\n  - Backend Secrets: `cat release.data.decoded | gzip | base64 | base64`\n  - Backend ConfigMap: `cat release.data.decoded | gzip | base64`\n- Substitua o valor da propriedade `data.release` no arquivo do release implantado (`release.yaml`) pelo novo objeto release codificado\n- Aplique o arquivo ao namespace: `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- Execute um `helm upgrade` com uma versão do chart que possui versões de API do Kubernetes suportadas\n- Adicione uma descrição no upgrade, algo como \"não realizar rollback para uma versão do Helm anterior a esta versão atual\"\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: Guia de Distribuições Kubernetes\ndescription: Informações sobre o uso do Helm em ambientes Kubernetes específicos.\nsidebar_position: 10\n---\n\nO Helm deve funcionar com qualquer [versão conforme do\nKubernetes](https://github.com/cncf/k8s-conformance) (seja ela\n[certificada](https://www.cncf.io/certification/software-conformance/) ou não).\n\nEste documento contém informações sobre o uso do Helm em ambientes Kubernetes\nespecíficos. Contribua com mais detalhes sobre quaisquer distribuições\n(ordenadas alfabeticamente), se desejar.\n\n\n## AKS\n\nO Helm funciona com o [Azure Kubernetes\nService](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nO Helm foi testado e funciona na plataforma Kubernetes do DC/OS 1.11 da\nMesosphere, e não requer configuração adicional.\n\n## EKS\n\nO Helm funciona com o Amazon Elastic Kubernetes Service (Amazon EKS):\n[Usando o Helm com o Amazon\nEKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nA plataforma Kubernetes hospedada do Google, GKE, funciona com o Helm e não\nrequer configuração adicional.\n\n## `scripts/local-cluster` e Hyperkube\n\nO Hyperkube configurado via `scripts/local-cluster.sh` funciona corretamente.\nPara o Hyperkube direto, pode ser necessário realizar alguma configuração manual.\n\n## IKS\n\nO Helm funciona com o [IBM Cloud Kubernetes\nService](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nO Helm é testado regularmente no [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne\n\nO Helm funciona em clusters configurados pelo KubeOne sem ressalvas.\n\n## Kubermatic\n\nO Helm funciona em clusters de usuário criados pelo Kubermatic sem ressalvas.\nComo o seed cluster pode ser configurado de diferentes maneiras, o suporte ao\nHelm depende da configuração específica.\n\n## MicroK8s\n\nO Helm pode ser habilitado no [MicroK8s](https://microk8s.io) usando o comando:\n`microk8s.enable helm3`\n\n## Minikube\n\nO Helm é testado e funciona com o\n[Minikube](https://github.com/kubernetes/minikube). Não requer configuração\nadicional.\n\n## Openshift\n\nO Helm funciona diretamente no OpenShift Online, OpenShift Dedicated, OpenShift\nContainer Platform (versão >= 3.6) ou OpenShift Origin (versão >= 3.6). Para\nsaber mais, leia esta [postagem no\nblog](https://blog.openshift.com/getting-started-helm-openshift/).\n\n## Platform9\n\nO Helm vem pré-instalado no [Platform9 Managed\nKubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes).\nO Platform9 fornece acesso a todos os charts oficiais do Helm através da\ninterface App Catalog e da CLI nativa do Kubernetes. Repositórios adicionais\npodem ser adicionados manualmente. Mais detalhes estão disponíveis neste [artigo\ndo Platform9 App\nCatalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes).\n\n## Ubuntu com `kubeadm`\n\nO Kubernetes inicializado com `kubeadm` funciona nas seguintes distribuições\nLinux:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nAlgumas versões do Helm (v2.0.0-beta2) requerem que você execute `export\nKUBECONFIG=/etc/kubernetes/admin.conf` ou crie um arquivo `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid\n\nO Helm funciona no VMware Tanzu Kubernetes Grid, TKG, sem necessidade de\nalterações na configuração. A CLI do Tanzu pode gerenciar a instalação de\npacotes para o [helm-controller](https://fluxcd.io/flux/components/helm/),\npermitindo o gerenciamento declarativo de releases de charts Helm. Mais detalhes\nestão disponíveis na documentação do TKG para [CLI-Managed\nPackages](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).\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: Charts de Biblioteca\ndescription: Explica charts de biblioteca e exemplos de uso\nsidebar_position: 4\n---\n\nUm chart de biblioteca é um tipo de [chart Helm](/topics/charts.md)\nque define primitivas ou definições de charts que podem ser compartilhadas por\ntemplates Helm em outros charts. Isso permite que os usuários compartilhem\ntrechos de código que podem ser reutilizados em diferentes charts, evitando\nrepetição e mantendo os charts\n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nO chart de biblioteca foi introduzido no Helm 3 para reconhecer formalmente os\ncharts comuns ou auxiliares que têm sido usados por mantenedores de charts desde\no Helm 2. Ao incluí-lo como um tipo de chart, ele fornece:\n- Um meio de distinguir explicitamente entre charts comuns e de aplicação\n- Lógica para impedir a instalação de um chart comum\n- Sem renderização de templates em um chart comum que pode conter artefatos de\n  release\n- Permite que charts dependentes usem o contexto do chart importador\n\nUm mantenedor de chart pode definir um chart comum como um chart de biblioteca e\nter a confiança de que o Helm irá manipular o chart de forma padrão e\nconsistente. Também significa que definições em um chart de aplicação podem ser\ncompartilhadas alterando o tipo do chart.\n\n## Criando um Chart de Biblioteca Simples\n\nComo mencionado anteriormente, um chart de biblioteca é um tipo de [chart Helm](/topics/charts.md). Isso significa que você pode começar criando um\nchart base:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nPrimeiro, você vai remover todos os arquivos no diretório `templates`, pois\ncriaremos nossas próprias definições de templates neste exemplo.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nO arquivo values também não será necessário.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nAntes de começarmos a criar código comum, vamos fazer uma rápida revisão de\nalguns conceitos relevantes do Helm. Um [template nomeado](/chart_template_guide/named_templates.md) (às vezes chamado de partial\nou subtemplate) é simplesmente um template definido dentro de um arquivo e que\nrecebe um nome. No diretório `templates/`, qualquer arquivo que começa com\nunderscore (_) não é esperado que gere um arquivo de manifesto do Kubernetes.\nEntão, por convenção, templates auxiliares e partials são colocados em arquivos\n`_*.tpl` ou `_*.yaml`.\n\nNeste exemplo, vamos criar um ConfigMap comum que cria um recurso ConfigMap\nvazio. Vamos definir o ConfigMap comum no arquivo\n`mylibchart/templates/_configmap.yaml` da seguinte forma:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nA estrutura do ConfigMap é definida no template nomeado\n`mylibchart.configmap.tpl`. É um ConfigMap simples com um recurso vazio, `data`.\nDentro deste arquivo, há outro template nomeado chamado `mylibchart.configmap`.\nEste template nomeado inclui outro template nomeado `mylibchart.util.merge` que\nrecebe 2 templates nomeados como argumentos: o template que chama\n`mylibchart.configmap` e `mylibchart.configmap.tpl`.\n\nA função auxiliar `mylibchart.util.merge` é um template nomeado em\n`mylibchart/templates/_util.yaml`. É um utilitário prático do [Chart Auxiliar\nComum do Helm](#o-chart-auxiliar-comum-do-helm) porque ele mescla os 2 templates\ne sobrescreve quaisquer partes comuns em ambos:\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nIsso é importante quando um chart deseja usar código comum que precisa\npersonalizar com sua configuração.\n\nFinalmente, vamos alterar o tipo do chart para `library`. Isso requer editar\n`mylibchart/Chart.yaml` da seguinte forma:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\nO chart de biblioteca agora está pronto para ser compartilhado e sua definição\nde ConfigMap para ser reutilizada.\n\nAntes de prosseguir, vale verificar se o Helm reconhece o chart como um chart de\nbiblioteca:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Usando o Chart de Biblioteca Simples\n\nÉ hora de usar o chart de biblioteca. Isso significa criar um chart base\nnovamente:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nVamos limpar os arquivos de template novamente, pois queremos criar apenas um\nConfigMap:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nQuando queremos criar um ConfigMap simples em um template Helm, ele poderia se\nparecer com o seguinte:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nNo entanto, vamos reutilizar o código comum já criado em `mylibchart`. O\nConfigMap pode ser criado no arquivo `mychart/templates/configmap.yaml` da\nseguinte forma:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nVocê pode ver que isso simplifica o trabalho que temos que fazer ao herdar a\ndefinição comum do ConfigMap que adiciona propriedades padrão para o ConfigMap.\nEm nosso template, adicionamos a configuração, neste caso a chave de dados\n`myvalue` e seu valor. A configuração sobrescreve o recurso vazio do ConfigMap\ncomum. Isso é possível por causa da função auxiliar `mylibchart.util.merge` que\nmencionamos na seção anterior.\n\nPara poder usar o código comum, precisamos adicionar `mylibchart` como uma\ndependência. Adicione o seguinte ao final do arquivo `mychart/Chart.yaml`:\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nIsso inclui o chart de biblioteca como uma dependência dinâmica do sistema de\narquivos que está no mesmo caminho pai do nosso chart de aplicação. Como estamos\nincluindo o chart de biblioteca como uma dependência dinâmica, precisamos\nexecutar `helm dependency update`. Ele copiará o chart de biblioteca para o\ndiretório `charts/`.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nAgora estamos prontos para implantar nosso chart. Antes de instalar, vale\nverificar o template renderizado primeiro.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nIsso parece o ConfigMap que queremos com a sobrescrita de dados de `myvalue:\nHello World`. Vamos instalá-lo:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nPodemos recuperar o release e ver que o template real foi carregado.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## Benefícios do Chart de Biblioteca\nPor causa da sua incapacidade de atuar como charts independentes, charts de biblioteca podem aproveitar as seguintes funcionalidades:\n- O objeto `.Files` referencia os caminhos de arquivo no chart pai, em vez do caminho local do chart de biblioteca\n- 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.\n\n\n## O Chart Auxiliar Comum do Helm\n\n```markdown\nNota: O repositório do Chart Auxiliar Comum do Helm no GitHub não é mais mantido ativamente, e o repositório foi descontinuado e arquivado.\n```\n\nEste [chart](https://github.com/helm/charts/tree/master/incubator/common) foi o\npadrão original para charts comuns. Ele fornece utilitários que refletem as\nmelhores práticas do desenvolvimento de charts Kubernetes. Melhor ainda, você\npode usá-lo imediatamente ao desenvolver seus charts para obter código\ncompartilhado útil.\n\nAqui está uma maneira rápida de usá-lo. Para mais detalhes, consulte o\n[README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nCrie um chart base novamente:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nVamos usar o código comum do chart auxiliar. Primeiro, edite o deployment\n`demo/templates/deployment.yaml` da seguinte forma:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nE agora o arquivo de service, `demo/templates/service.yaml` da seguinte forma:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nEstes templates mostram como herdar o código comum do chart auxiliar simplifica\nsua codificação até a configuração ou personalização dos recursos.\n\nPara poder usar o código comum, precisamos adicionar `common` como uma\ndependência. Adicione o seguinte ao final do arquivo `demo/Chart.yaml`:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nNota: Você precisará adicionar o repositório `incubator` à lista de repositórios\ndo Helm (`helm repo add`).\n\nComo estamos incluindo o chart como uma dependência dinâmica, precisamos\nexecutar `helm dependency update`. Ele copiará o chart auxiliar para o diretório\n`charts/`.\n\nComo o chart auxiliar usa algumas estruturas do Helm 2, você precisará adicionar\no seguinte ao `demo/values.yaml` para habilitar o carregamento da imagem `nginx`\npois isso foi atualizado no chart base do Helm 3:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nVocê pode testar se os templates do chart estão corretos antes de implantar usando os comandos `helm lint` e `helm template`.\n\nSe estiver tudo certo, implante usando `helm install`!\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Gerenciamento de permissões para backend de armazenamento SQL\ndescription: Saiba como configurar permissões ao usar o backend de armazenamento SQL.\n---\n\nEste documento fornece orientações para configurar e gerenciar permissões ao\nusar o backend de armazenamento SQL.\n\n## Introdução\n\nPara gerenciar permissões, o Helm utiliza o recurso RBAC do Kubernetes. Ao usar\no backend de armazenamento SQL, os roles do Kubernetes não podem ser usados para\ndeterminar se um usuário pode acessar um determinado recurso. Este documento\nmostra como criar e gerenciar essas permissões.\n\n## Inicialização\n\nNa primeira vez que o CLI do Helm se conectar ao seu banco de dados, o client\nverificará se ele foi previamente inicializado. Caso contrário, realizará a\nconfiguração necessária automaticamente. Esta inicialização requer privilégios\nde administrador no schema public, ou pelo menos a capacidade de:\n\n* criar uma tabela\n* conceder privilégios no schema public\n\nApós a migração ser executada no seu banco de dados, todos os outros roles\npodem usar o client.\n\n## Conceder privilégios a um usuário não administrador no PostgreSQL\n\nPara gerenciar permissões, o driver do backend SQL utiliza o recurso\n[RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security\nLevel) do PostgreSQL. O RLS permite que todos os usuários possam ler/escrever\nna mesma tabela, sem conseguir manipular as mesmas linhas se não tiverem sido\nexplicitamente autorizados. Por padrão, qualquer role que não tenha recebido\nexplicitamente os privilégios adequados sempre retornará uma lista vazia ao\nexecutar `helm list` e não conseguirá recuperar ou modificar nenhum recurso no\ncluster.\n\nVeja como conceder a um determinado role acesso a namespaces específicos:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nEste comando concederá as permissões de leitura e escrita de todos os recursos\nque atendem à condição `namespace = 'default'` ao role `role`. Após criar esta\npolítica, o usuário conectado ao banco de dados com o role `role` poderá ver\ntodos os releases no namespace `default` ao executar `helm list`, além de\nmodificá-los e excluí-los.\n\nOs privilégios podem ser gerenciados de forma granular com RLS, e pode ser\ninteressante restringir o acesso de acordo com as diferentes colunas da tabela:\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Guia de Plugins do Helm\ndescription: Apresenta como usar e criar plugins para estender a funcionalidade do Helm.\nsidebar_position: 12\n---\n\nUm plugin do Helm é uma ferramenta que pode ser acessada através da CLI `helm`,\nmas que não faz parte do código-base principal do Helm.\n\nPlugins existentes podem ser encontrados na seção\n[relacionados](/community/related#helm-plugins) ou pesquisando no\n[GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).\n\nEste guia explica como usar e criar plugins.\n\n## Visão Geral\n\nPlugins do Helm são ferramentas complementares que se integram perfeitamente com\no Helm. Eles fornecem uma maneira de estender o conjunto de recursos principais\ndo Helm, sem exigir que cada novo recurso seja escrito em Go e adicionado à\nferramenta principal.\n\nPlugins do Helm têm as seguintes características:\n\n- Podem ser adicionados e removidos de uma instalação do Helm sem impactar a\n  ferramenta principal.\n- Podem ser escritos em qualquer linguagem de programação.\n- Integram-se com o Helm e aparecem em `helm help` e outros locais.\n\nPlugins do Helm ficam em `$HELM_PLUGINS`. Você pode encontrar o valor atual\ndesta variável, incluindo o valor padrão quando não definida no ambiente,\nusando o comando `helm env`.\n\nO modelo de plugins do Helm é parcialmente baseado no modelo de plugins do Git.\nPor isso, você pode às vezes ouvir o `helm` ser referido como a camada\n_porcelain_, com os plugins sendo a _plumbing_. Isso significa que o Helm\nfornece a interface de alto nível para o usuário, enquanto os plugins realizam o\n\"trabalho pesado\" de executar ações específicas.\n\n## Instalando um Plugin\n\nPlugins são instalados usando o comando `$ helm plugin install <path|url>`. Você\npode passar um caminho para um plugin no seu sistema de arquivos local ou uma\nURL de um repositório VCS remoto. O comando `helm plugin install` clona ou copia\no plugin do caminho/URL fornecido para `$HELM_PLUGINS`. Se você estiver\ninstalando a partir de um VCS, pode especificar a versão com o argumento\n`--version`.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nSe você tiver uma distribuição tar de um plugin, extraia o plugin no diretório\n`$HELM_PLUGINS`. Você também pode instalar plugins tarball diretamente de uma\nURL usando `helm plugin install https://domain/path/to/plugin.tar.gz`\n\n## Estrutura de Arquivos do Plugin\n\nDe muitas formas, um plugin é semelhante a um chart. Cada plugin tem um\ndiretório de nível superior contendo um arquivo `plugin.yaml`. Arquivos\nadicionais podem estar presentes, mas apenas o arquivo `plugin.yaml` é\nobrigatório.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## O Arquivo plugin.yaml\n\nO arquivo plugin.yaml é obrigatório para um plugin. Ele contém os seguintes\ncampos:\n\n```yaml\nname: The name of the plugin (REQUIRED)\nversion: A SemVer 2 version (REQUIRED)\nusage: Single line usage text shown in help\ndescription: Long description shown in places like helm help\nignoreFlags: Ignore flags passed in from Helm\nplatformCommand: # Configure command to run based on the platform\n  - os: OS match, can be empty or omitted to match all OS'\n    arch: Architecture match, can be empty or omitted to match all architectures\n    command: Plugin command to execute\n    args: Plugin command arguments\ncommand: (DEPRECATED) Plugin command, use platformCommand instead\nplatformHooks: # Configure plugin lifecycle hooks based on the platform\n  install: # Install lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin install command to execute\n      args: Plugin install command arguments\n  update: # Update lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin update command to execute\n      args: Plugin update command arguments\n  delete: # Delete lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin delete command to execute\n      args: Plugin delete command arguments\nhooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead\n  install: Command to install plugin\n  update: Command to update plugin\n  delete: Command to delete plugin\ndownloaders: # Configure downloaders capability\n  - command: Command to invoke\n    protocols:\n      - Protocol schema supported\n```\n\n### O Campo `name`\n\nO `name` é o nome do plugin. Quando o Helm executa este plugin, este é o nome\nque ele usará (por exemplo, `helm NAME` invocará este plugin).\n\n_`name` deve corresponder ao nome do diretório._ No nosso exemplo acima, isso\nsignifica que o plugin com `name: last` deve estar contido em um diretório\nchamado `last`.\n\nRestrições em `name`:\n\n- `name` não pode duplicar um dos comandos de nível superior existentes do\n  `helm`.\n- `name` deve ser restrito aos caracteres ASCII a-z, A-Z, 0-9, `_` e `-`.\n\n### O Campo `version`\n\nO `version` é a versão SemVer 2 do plugin. `usage` e `description` são ambos\nusados para gerar o texto de ajuda de um comando.\n\n### O Campo `ignoreFlags`\n\nA opção `ignoreFlags` diz ao Helm para _não_ passar flags para o plugin. Então,\nse um plugin for chamado com `helm myplugin --foo` e `ignoreFlags: true`, então\n`--foo` é silenciosamente descartado.\n\n### O Campo `platformCommand`\n\nO `platformCommand` configura o comando que o plugin executará quando for\nchamado. Você não pode definir tanto `platformCommand` quanto `command`, pois\nisso resultará em um erro. As seguintes regras se aplicam na decisão de qual\ncomando usar:\n\n- Se `platformCommand` estiver presente, ele será usado.\n  - Se tanto `os` quanto `arch` corresponderem à plataforma atual, a busca\n    parará e o comando será usado.\n  - Se `os` corresponder e `arch` estiver vazio, o comando será usado.\n  - Se `os` e `arch` estiverem ambos vazios, o comando será usado.\n  - Se não houver correspondência, o Helm sairá com um erro.\n- Se `platformCommand` não estiver presente e o `command` depreciado estiver\n  presente, ele será usado.\n  - Se o comando estiver vazio, o Helm sairá com um erro.\n\n### O Campo `platformHooks`\n\nO `platformHooks` configura os comandos que o plugin executará para eventos de\nciclo de vida. Você não pode definir tanto `platformHooks` quanto `hooks`, pois\nisso resultará em um erro. As seguintes regras se aplicam na decisão de qual\ncomando de hook usar:\n\n- Se `platformHooks` estiver presente, ele será usado e os comandos para o\n  evento de ciclo de vida serão processados.\n  - Se tanto `os` quanto `arch` corresponderem à plataforma atual, a busca\n    parará e o comando será usado.\n  - Se `os` corresponder e `arch` estiver vazio, o comando será usado.\n  - Se `os` e `arch` estiverem ambos vazios, o comando será usado.\n  - Se não houver correspondência, o Helm pulará o evento.\n- Se `platformHooks` não estiver presente e o `hooks` depreciado estiver\n  presente, o comando para o evento de ciclo de vida será usado.\n  - Se o comando estiver vazio, o Helm pulará o evento.\n\n## Construindo um Plugin\n\nAqui está o YAML do plugin para um plugin simples que ajuda a obter o nome do\núltimo release:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nPlugins podem requerer scripts e executáveis adicionais. Scripts podem ser\nincluídos no diretório do plugin e executáveis podem ser baixados via hook. O\nseguinte é um exemplo de plugin:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nVariáveis de ambiente são interpoladas antes do plugin ser executado. O padrão\nacima ilustra a maneira preferida de indicar onde o programa do plugin está\nlocalizado.\n\n### Comandos de Plugin\n\nExistem algumas estratégias para trabalhar com comandos de plugin:\n\n- Se um plugin inclui um executável, o executável para um `platformCommand:` ou\n  deve ser empacotado no diretório do plugin ou instalado via hook.\n- A linha `platformCommand:` ou `command:` terá quaisquer variáveis de ambiente\n  expandidas antes da execução. `$HELM_PLUGIN_DIR` apontará para o diretório do\n  plugin.\n- O comando em si não é executado em um shell. Então você não pode colocar um\n  script shell em uma linha.\n- O Helm injeta muitas configurações em variáveis de ambiente. Examine o\n  ambiente para ver quais informações estão disponíveis.\n- O Helm não faz suposições sobre a linguagem do plugin. Você pode escrevê-lo na\n  linguagem que preferir.\n- Comandos são responsáveis por implementar texto de ajuda específico para `-h`\n  e `--help`. O Helm usará `usage` e `description` para `helm help` e\n  `helm help myplugin`, mas não tratará `helm myplugin --help`.\n\n### Testando um Plugin Local\n\nPrimeiro você precisa encontrar o caminho do seu `HELM_PLUGINS`. Para isso,\nexecute o seguinte comando:\n\n``` bash\nhelm env\n```\n\nMude seu diretório atual para o diretório definido em `HELM_PLUGINS`.\n\nAgora você pode adicionar um link simbólico para a saída de build do seu plugin.\nNeste exemplo, fizemos isso para o `mapkubeapis`.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Plugins de Download\n\nPor padrão, o Helm pode baixar Charts usando HTTP/S. A partir do Helm 2.4.0,\nplugins podem ter uma capacidade especial de baixar Charts de fontes\narbitrárias.\n\nPlugins devem declarar esta capacidade especial no arquivo `plugin.yaml` (nível\nsuperior):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nSe tal plugin for instalado, o Helm pode interagir com o repositório usando o\nesquema de protocolo especificado, invocando o `command`. O repositório especial\ndeve ser adicionado de forma similar aos regulares:\n`helm repo add favorite myprotocol://example.com/`. As regras para repositórios\nespeciais são as mesmas dos regulares: o Helm deve ser capaz de baixar o arquivo\n`index.yaml` para descobrir e armazenar em cache a lista de Charts disponíveis.\n\nO comando definido será invocado com o seguinte esquema:\n`command certFile keyFile caFile full-URL`. As credenciais SSL vêm da definição\ndo repositório, armazenadas em `$HELM_REPOSITORY_CONFIG` (ou seja,\n`$HELM_CONFIG_HOME/repositories.yaml`). Um plugin de download deve enviar o\nconteúdo bruto para stdout e reportar erros em stderr.\n\nO comando de download também suporta subcomandos ou argumentos, permitindo que\nvocê especifique, por exemplo, `bin/mydownloader subcommand -d` no\n`plugin.yaml`. Isso é útil se você quiser usar o mesmo executável para o comando\nprincipal do plugin e o comando de download, mas com um subcomando diferente\npara cada um.\n\n## Variáveis de Ambiente\n\nQuando o Helm executa um plugin, ele passa o ambiente externo para o plugin e\ntambém injeta algumas variáveis de ambiente adicionais.\n\nVariáveis como `KUBECONFIG` são definidas para o plugin se estiverem definidas\nno ambiente externo.\n\nAs seguintes variáveis são garantidas de estar definidas:\n\n- `HELM_PLUGINS`: O caminho para o diretório de plugins.\n- `HELM_PLUGIN_NAME`: O nome do plugin, como invocado pelo `helm`. Então\n  `helm myplug` terá o nome curto `myplug`.\n- `HELM_PLUGIN_DIR`: O diretório que contém o plugin.\n- `HELM_BIN`: O caminho para o comando `helm` (como executado pelo usuário).\n- `HELM_DEBUG`: Indica se a flag de debug foi definida pelo helm.\n- `HELM_REGISTRY_CONFIG`: A localização para a configuração do registro (se\n  usado). Note que o uso do Helm com registros é um recurso experimental.\n- `HELM_REPOSITORY_CACHE`: O caminho para os arquivos de cache do repositório.\n- `HELM_REPOSITORY_CONFIG`: O caminho para o arquivo de configuração do\n  repositório.\n- `HELM_NAMESPACE`: O namespace dado ao comando `helm` (geralmente usando a flag\n  `-n`).\n- `HELM_KUBECONTEXT`: O nome do contexto de configuração do Kubernetes dado ao\n  comando `helm`.\n\nAlém disso, se um arquivo de configuração do Kubernetes foi especificado\nexplicitamente, ele será definido como a variável `KUBECONFIG`.\n\n## Uma Nota sobre Processamento de Flags\n\nAo executar um plugin, o Helm processa as flags globais para seu próprio uso.\nNenhuma dessas flags é passada para o plugin.\n\n- `--burst-limit`: Convertido para `$HELM_BURST_LIMIT`\n- `--debug`: Se especificado, `$HELM_DEBUG` é definido como `1`\n- `--kube-apiserver`: Convertido para `$HELM_KUBEAPISERVER`\n- `--kube-as-group`: Convertido para `$HELM_KUBEASGROUPS`\n- `--kube-as-user`: Convertido para `$HELM_KUBEASUSER`\n- `--kube-ca-file`: Convertido para `$HELM_KUBECAFILE`\n- `--kube-context`: Convertido para `$HELM_KUBECONTEXT`\n- `--kube-insecure-skip-tls-verify`: Convertido para\n  `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`\n- `--kube-tls-server-name`: Convertido para `$HELM_KUBETLS_SERVER_NAME`\n- `--kube-token`: Convertido para `$HELM_KUBETOKEN`\n- `--kubeconfig`: Convertido para `$KUBECONFIG`\n- `--namespace` e `-n`: Convertido para `$HELM_NAMESPACE`\n- `--qps`: Convertido para `$HELM_QPS`\n- `--registry-config`: Convertido para `$HELM_REGISTRY_CONFIG`\n- `--repository-cache`: Convertido para `$HELM_REPOSITORY_CACHE`\n- `--repository-config`: Convertido para `$HELM_REPOSITORY_CONFIG`\n\nPlugins _devem_ exibir texto de ajuda e então sair para `-h` e `--help`. Em\ntodos os outros casos, plugins podem usar flags conforme apropriado.\n\n## Fornecendo Auto-Completação de Shell\n\nA partir do Helm 3.2, um plugin pode opcionalmente fornecer suporte para\nauto-completação de shell como parte do mecanismo de auto-completação existente\ndo Helm.\n\n### Auto-Completação Estática\n\nSe um plugin fornece suas próprias flags e/ou subcomandos, ele pode informar o\nHelm sobre eles tendo um arquivo `completion.yaml` localizado no diretório raiz\ndo plugin. O arquivo `completion.yaml` tem a seguinte forma:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nNotas:\n\n1. Todas as seções são opcionais, mas devem ser fornecidas se aplicável.\n1. Flags não devem incluir o prefixo `-` ou `--`.\n1. Tanto flags curtas quanto longas podem e devem ser especificadas. Uma flag\n   curta não precisa estar associada à sua forma longa correspondente, mas ambas\n   as formas devem ser listadas.\n1. Flags não precisam estar ordenadas de nenhuma forma, mas precisam estar\n   listadas no ponto correto na hierarquia de subcomandos do arquivo.\n1. As flags globais existentes do Helm já são tratadas pelo mecanismo de\n   auto-completação do Helm, portanto os plugins não precisam especificar as\n   seguintes flags: `--debug`, `--namespace` ou `-n`, `--kube-context` e\n   `--kubeconfig`, ou qualquer outra flag global.\n1. A lista `validArgs` fornece uma lista estática de possíveis completações para\n   o primeiro parâmetro após um subcomando. Nem sempre é possível fornecer tal\n   lista antecipadamente (veja a seção [Completação\n   Dinâmica](#completação-dinâmica) abaixo), caso em que a seção `validArgs`\n   pode ser omitida.\n\nO arquivo `completion.yaml` é totalmente opcional. Se não for fornecido, o Helm\nsimplesmente não fornecerá auto-completação de shell para o plugin (a menos que\n[Completação Dinâmica](#completação-dinâmica) seja suportada pelo plugin). Além\ndisso, adicionar um arquivo `completion.yaml` é retrocompatível e não impactará\no comportamento do plugin ao usar versões mais antigas do Helm.\n\nComo exemplo, para o [plugin\n`fullstatus`](https://github.com/marckhouzam/helm-fullstatus) que não tem\nsubcomandos mas aceita as mesmas flags que o comando `helm status`, o arquivo\n`completion.yaml` é:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nUm exemplo mais elaborado para o [plugin\n`2to3`](https://github.com/helm/helm-2to3), tem um arquivo `completion.yaml` de:\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### Completação Dinâmica\n\nTambém a partir do Helm 3.2, plugins podem fornecer sua própria auto-completação\ndinâmica de shell. Auto-completação dinâmica de shell é a completação de valores\nde parâmetros ou valores de flags que não podem ser definidos antecipadamente.\nPor exemplo, completação dos nomes de releases do Helm atualmente disponíveis no\ncluster.\n\nPara que o plugin suporte completação dinâmica, ele deve fornecer um arquivo\n**executável** chamado `plugin.complete` em seu diretório raiz. Quando o script\nde completação do Helm requer completações dinâmicas para o plugin, ele\nexecutará o arquivo `plugin.complete`, passando a linha de comando que precisa\nser completada. O executável `plugin.complete` precisará ter a lógica para\ndeterminar quais são as escolhas de completação adequadas e exibi-las na saída\npadrão para serem consumidas pelo script de completação do Helm.\n\nO arquivo `plugin.complete` é totalmente opcional. Se não for fornecido, o Helm\nsimplesmente não fornecerá auto-completação dinâmica para o plugin. Além disso,\nadicionar um arquivo `plugin.complete` é retrocompatível e não impactará o\ncomportamento do plugin ao usar versões mais antigas do Helm.\n\nA saída do script `plugin.complete` deve ser uma lista separada por novas linhas\ncomo:\n\n```console\nrel1\nrel2\nrel3\n```\n\nQuando `plugin.complete` é chamado, o ambiente do plugin é configurado da mesma\nforma que quando o script principal do plugin é chamado. Portanto, as variáveis\n`$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` e todas as outras variáveis do plugin já\nestarão definidas, e suas flags globais correspondentes terão sido removidas.\n\nO arquivo `plugin.complete` pode estar em qualquer forma executável; pode ser um\nscript shell, um programa Go, ou qualquer outro tipo de programa que o Helm\npossa executar. O arquivo `plugin.complete` ***deve*** ter permissões de\nexecução para o usuário. O arquivo `plugin.complete` ***deve*** sair com um\ncódigo de sucesso (valor 0).\n\nEm alguns casos, a completação dinâmica precisará obter informações do cluster\nKubernetes. Por exemplo, o plugin `helm fullstatus` requer um nome de release\ncomo entrada. No plugin `fullstatus`, para que seu script `plugin.complete`\nforneça completação para nomes de releases atuais, ele pode simplesmente\nexecutar `helm list -q` e exibir o resultado.\n\nSe for desejado usar o mesmo executável para execução do plugin e para\ncompletação do plugin, o script `plugin.complete` pode ser feito para chamar o\nexecutável principal do plugin com algum parâmetro ou flag especial; quando o\nexecutável principal do plugin detectar o parâmetro ou flag especial, ele saberá\nque deve executar a completação. No nosso exemplo, `plugin.complete` poderia ser\nimplementado assim:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nO script real do plugin `fullstatus` (`status.sh`) deve então procurar pela flag\n`--complete` e, se encontrada, exibir as completações adequadas.\n\n### Dicas e Truques\n\n1. O shell filtrará automaticamente escolhas de completação que não correspondam\n   à entrada do usuário. Um plugin pode, portanto, retornar todas as completações\n   relevantes sem remover as que não correspondem à entrada do usuário. Por\n   exemplo, se a linha de comando for `helm fullstatus ngin<TAB>`, o script\n   `plugin.complete` pode exibir *todos* os nomes de releases (do namespace\n   `default`), não apenas os que começam com `ngin`; o shell reterá apenas os\n   que começam com `ngin`.\n1. Para simplificar o suporte à completação dinâmica, especialmente se você\n   tiver um plugin complexo, você pode fazer seu script `plugin.complete` chamar\n   seu script principal do plugin e solicitar escolhas de completação. Veja a\n   seção [Completação Dinâmica](#completação-dinâmica) acima para um exemplo.\n1. Para depurar a completação dinâmica e o arquivo `plugin.complete`, você pode\n   executar o seguinte para ver os resultados de completação:\n    - `helm __complete <pluginName> <arguments to complete>`. Por exemplo:\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: Proveniência e Integridade do Helm\ndescription: Descreve como verificar a integridade e origem de um Chart.\nsidebar_position: 5\n---\n\nO 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.\n\n## Visão Geral\n\nA 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`.\n\nOs 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`.\n\n## O Fluxo de Trabalho\n\nEsta seção descreve um fluxo de trabalho potencial para usar dados de proveniência de forma eficaz.\n\nPré-requisitos:\n\n- Um par de chaves PGP válido em formato binário (não ASCII-armored)\n- A ferramenta de linha de comando `helm`\n- Ferramentas de linha de comando GnuPG (opcional)\n- Ferramentas de linha de comando Keybase (opcional)\n\n**NOTA:** Se sua chave privada PGP possui uma passphrase, você será solicitado a digitá-la para qualquer comando que suporte a opção `--sign`.\n\nCriar um novo chart é igual a antes:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nQuando 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:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**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.**\n\n**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.\n\n**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:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nNeste 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.\n\nVocê pode verificar um chart usando `helm verify`:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nUma verificação com falha aparece assim:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nPara verificar durante uma instalação, use a flag `--verify`.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nSe 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`.\n\nSe a verificação falhar, a instalação será abortada antes mesmo do chart ser renderizado.\n\n### Usando credenciais do Keybase.io\n\nO 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.\n\nPré-requisitos:\n\n- Uma conta Keybase.io configurada\n- GnuPG instalado localmente\n- A CLI `keybase` instalada localmente\n\n#### Assinando pacotes\n\nO primeiro passo é importar suas chaves Keybase para seu keyring GnuPG local:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nEste comando converte sua chave Keybase para o formato OpenPGP e a importa para o arquivo local `~/.gnupg/secring.gpg`.\n\nVocê pode verificar executando `gpg --list-secret-keys`.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nNote que sua chave secreta terá uma string identificadora:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nEsse é o nome completo da sua chave.\n\nEm seguida, você pode empacotar e assinar um chart com `helm package`. Certifique-se de usar pelo menos parte dessa string de nome em `--key`.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nComo resultado, o comando `package` deve produzir tanto um arquivo `.tgz` quanto um arquivo `.tgz.prov`.\n\n#### Verificando pacotes\n\nVocê 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`:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nO 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`).\n\nNeste ponto, você agora pode usar `helm verify` ou qualquer um dos comandos com a flag `--verify`:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Razões pelas quais um chart pode não ser verificado\n\nEstas são razões comuns para falha.\n\n- 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.\n- 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.\n- A verificação do arquivo `.prov` falhou. Isso indica que algo está errado com o chart ou com os dados de proveniência.\n- 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.\n\nSe uma verificação falhar, há razão para desconfiar do pacote.\n\n## O Arquivo de Proveniência\n\nO 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.\n\nOs seguintes dados de proveniência são adicionados:\n\n* 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.\n* 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.\n* 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).\n\nA combinação disso dá aos usuários as seguintes garantias:\n\n* O pacote em si não foi adulterado (checksum do pacote `.tgz`).\n* A entidade que lançou este pacote é conhecida (via a assinatura GnuPG/PGP).\n\nO formato do arquivo se parece com algo assim:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nNote 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.\n\nO bloco de assinatura é uma assinatura PGP padrão, que fornece [resistência à adulteração](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Repositórios de Charts\n\nOs repositórios de charts servem como uma coleção centralizada de charts Helm.\n\nOs 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.\n\nPor 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`.\n\nDa 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.\n\n### Assinaturas em registries baseados em OCI\n\nAo 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.\n\n## Estabelecendo Autoridade e Autenticidade\n\nAo 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.\n\nUma 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).\n\nNo entanto, temos algumas indicações e recomendações para aqueles interessados em usar o sistema de proveniência:\n\n- A plataforma [Keybase](https://keybase.io) fornece um repositório público centralizado para informações de confiança.\n  - Você pode usar o Keybase para armazenar suas chaves ou para obter as chaves públicas de outros.\n  - O Keybase também tem documentação fantástica disponível\n  - Embora não tenhamos testado, o recurso \"secure website\" do Keybase poderia ser usado para servir charts Helm.\n  - 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.\n  - 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.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: Controle de Acesso Baseado em Funções\ndescription: Explica como o Helm interage com o Controle de Acesso Baseado em Funções (RBAC) do Kubernetes.\nsidebar_position: 11\n---\n\nNo Kubernetes, conceder funções a um usuário ou a uma service account específica\nda aplicação é uma prática recomendada para garantir que sua aplicação esteja\noperando dentro do escopo que você especificou. Leia mais sobre permissões de\nservice account [na documentação oficial do\nKubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nA partir do Kubernetes 1.6, o Controle de Acesso Baseado em Funções é habilitado\npor padrão. O RBAC permite especificar quais tipos de ações são permitidas\ndependendo do usuário e de sua função na organização.\n\nCom o RBAC, você pode\n\n- conceder operações privilegiadas (como criar recursos com escopo de cluster,\n  como novas funções) a administradores\n- limitar a capacidade de um usuário criar recursos (pods, persistent volumes,\n  deployments) a namespaces específicos, ou em escopos de todo o cluster\n  (resource quotas, roles, custom resource definitions)\n- limitar a capacidade de um usuário visualizar recursos em namespaces\n  específicos ou em escopo de todo o cluster.\n\nEste guia é para administradores que desejam restringir o escopo de interação de\num usuário com a API do Kubernetes.\n\n## Gerenciando contas de usuário\n\nTodos os clusters Kubernetes possuem duas categorias de usuários: service\naccounts gerenciadas pelo Kubernetes e usuários normais.\n\nUsuários normais são assumidos como gerenciados por um serviço externo e\nindependente. Um administrador distribuindo chaves privadas, um armazenamento de\nusuários como Keystone ou Google Accounts, ou mesmo um arquivo com uma lista de\nnomes de usuário e senhas. Nesse sentido, o Kubernetes não possui objetos que\nrepresentem contas de usuário normais. Usuários normais não podem ser\nadicionados a um cluster através de uma chamada de API.\n\nEm contraste, service accounts são usuários gerenciados pela API do Kubernetes.\nElas são vinculadas a namespaces específicos e criadas automaticamente pelo API\nserver ou manualmente através de chamadas de API. As service accounts estão\nassociadas a um conjunto de credenciais armazenadas como Secrets, que são\nmontados em pods permitindo que processos dentro do cluster se comuniquem com a\nAPI do Kubernetes.\n\nRequisições de API são associadas a um usuário normal ou a uma service account,\nou são tratadas como requisições anônimas. Isso significa que todo processo\ndentro ou fora do cluster, desde um usuário humano digitando `kubectl` em uma\nestação de trabalho, até kubelets nos nós, até membros do control plane, deve se\nautenticar ao fazer requisições ao API server, ou ser tratado como um usuário\nanônimo.\n\n## Roles, ClusterRoles, RoleBindings e ClusterRoleBindings\n\nNo Kubernetes, contas de usuário e service accounts só podem visualizar e editar\nrecursos aos quais foi concedido acesso. Esse acesso é concedido através do uso\nde Roles e RoleBindings. Roles e RoleBindings são vinculados a um namespace\nespecífico, concedendo aos usuários a capacidade de visualizar e/ou editar\nrecursos dentro desse namespace aos quais o Role fornece acesso.\n\nEm escopo de cluster, estes são chamados de ClusterRoles e ClusterRoleBindings.\nConceder a um usuário um ClusterRole concede acesso para visualizar e/ou editar\nrecursos em todo o cluster. Também é necessário para visualizar e/ou editar\nrecursos em escopo de cluster (namespaces, resource quotas, nodes).\n\nClusterRoles podem ser vinculados a um namespace específico através de\nreferência em um RoleBinding. Os ClusterRoles padrão `admin`, `edit` e `view`\nsão comumente usados dessa maneira.\n\nExistem alguns ClusterRoles disponíveis por padrão no Kubernetes. Eles são\ndestinados a ser funções voltadas para o usuário. Incluem funções de\nsuper-usuário (`cluster-admin`) e funções com acesso mais granular (`admin`,\n`edit`, `view`).\n\n| ClusterRole Padrão | ClusterRoleBinding Padrão | Descrição\n|---------------------|----------------------------|-------------\n| `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.\n| `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.\n| `edit`              | Nenhum                     | Permite acesso de leitura/escrita à maioria dos objetos em um namespace. Não permite visualizar ou modificar roles ou rolebindings.\n| `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.\n\n## Restringindo o acesso de uma conta de usuário usando RBAC\n\nAgora que entendemos os conceitos básicos de Controle de Acesso Baseado em\nFunções, vamos discutir como um administrador pode restringir o escopo de acesso\nde um usuário.\n\n### Exemplo: Conceder acesso de leitura/escrita a um namespace específico\n\nPara restringir o acesso de um usuário a um namespace específico, podemos usar\no role `edit` ou `admin`. Se seus charts criam ou interagem com Roles e\nRoleBindings, você deve usar o ClusterRole `admin`.\n\nAlém disso, você também pode criar um RoleBinding com acesso `cluster-admin`.\nConceder a um usuário acesso `cluster-admin` no escopo do namespace fornece\ncontrole total sobre todos os recursos no namespace, incluindo o próprio\nnamespace.\n\nPara este exemplo, criaremos um usuário com o Role `edit`. Primeiro, crie o\nnamespace:\n\n```console\n$ kubectl create namespace foo\n```\n\nAgora, crie um RoleBinding nesse namespace, concedendo ao usuário o role `edit`.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Exemplo: Conceder acesso de leitura/escrita em escopo de cluster\n\nSe um usuário deseja instalar um chart que instala recursos com escopo de\ncluster (namespaces, roles, custom resource definitions, etc.), ele precisará de\nacesso de escrita em escopo de cluster.\n\nPara isso, conceda ao usuário acesso `admin` ou `cluster-admin`.\n\nConceder a um usuário acesso `cluster-admin` concede acesso a absolutamente\ntodos os recursos disponíveis no Kubernetes, incluindo acesso a nós com\n`kubectl drain` e outras tarefas administrativas. É altamente recomendado\nconsiderar fornecer ao usuário acesso `admin` em vez disso, ou criar um\nClusterRole personalizado adaptado às suas necessidades.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Exemplo: Conceder acesso somente leitura a um namespace específico\n\nVocê pode ter notado que não há um ClusterRole disponível para visualizar\nsecrets. O ClusterRole `view` não concede acesso de leitura a Secrets devido a\npreocupações de escalação. O Helm armazena metadados de release como Secrets por\npadrão.\n\nPara que um usuário possa executar `helm list`, ele precisa ser capaz de ler\nesses secrets. Para isso, criaremos um ClusterRole especial `secret-reader`.\n\nCrie o arquivo `cluster-role-secret-reader.yaml` e escreva o seguinte conteúdo\nno arquivo:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nEm seguida, crie o ClusterRole usando\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nUma vez feito isso, podemos conceder a um usuário acesso de leitura à maioria\ndos recursos e, em seguida, conceder acesso de leitura aos secrets:\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Exemplo: Conceder acesso somente leitura em escopo de cluster\n\nEm certos cenários, pode ser benéfico conceder a um usuário acesso em escopo de\ncluster. Por exemplo, se um usuário deseja executar o comando\n`helm list --all-namespaces`, a API requer que o usuário tenha acesso de leitura\nem escopo de cluster.\n\nPara isso, conceda ao usuário acesso `view` e `secret-reader` conforme descrito\nacima, mas com um ClusterRoleBinding.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Considerações Adicionais\n\nOs exemplos mostrados acima utilizam os ClusterRoles padrão fornecidos com o\nKubernetes. Para um controle mais refinado sobre quais recursos os usuários\npodem acessar, consulte [a documentação do\nKubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) sobre\ncomo criar seus próprios Roles e ClusterRoles personalizados.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: Usando registries baseados em OCI\ndescription: Descreve como usar OCI para distribuição de charts.\nsidebar_position: 7\n---\n\nA 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.\n\n\n## Suporte a OCI antes da v3.8.0\n\nO 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.\n\n### Habilitando o suporte a OCI antes da v3.8.0\n\nAntes do Helm v3.8.0, o suporte a OCI é *experimental* e deve ser habilitado manualmente.\n\nPara habilitar o suporte experimental a OCI para versões do Helm anteriores à v3.8.0, defina `HELM_EXPERIMENTAL_OCI` no seu ambiente. Por exemplo:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### Depreciações e mudanças de comportamento do OCI com a v3.8.0\n\nCom 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:\n\n- Ao definir um chart nas dependências como OCI, a versão pode ser definida como um intervalo, assim como outras dependências.\n- 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.\n- 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.\n\n### Depreciações e mudanças de comportamento do OCI com a v3.7.0\n\nCom 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:\n\n- O subcomando `helm chart` foi removido.\n- O cache de charts foi removido (sem `helm chart list` etc.).\n- Referências a registries OCI agora sempre são prefixadas com `oci://`.\n- O nome base da referência do registry deve *sempre* corresponder ao nome do chart.\n- A tag da referência do registry deve *sempre* corresponder à versão semântica do chart (ou seja, sem tags `latest`).\n- O media type da camada do chart foi alterado de `application/tar+gzip` para `application/vnd.cncf.helm.chart.content.v1.tar+gzip`.\n\n\n## Usando um registry baseado em OCI\n\n### Repositórios Helm em registries baseados em OCI\n\nUm [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.\n\n### Usando registries hospedados\n\nExistem vários registries de containers hospedados com suporte a OCI que você pode usar para seus charts Helm. Por exemplo:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\nSiga a documentação do provedor do registry de containers hospedado para criar e configurar um registry com suporte a OCI.\n\n**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.\n\n### Usando sigstore para assinar charts baseados em OCI\n\nO 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.\n\nPara 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).\n\n## Comandos para trabalhar com registries\n\n### O subcomando `registry`\n\n#### `login`\n\nfazer login em um registry (com entrada manual de senha)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nfazer logout de um registry\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### O subcomando `push`\n\nEnviar um chart para um registry baseado em OCI:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nO subcomando `push` só pode ser usado com arquivos `.tgz`\ncriados anteriormente usando `helm package`.\n\nAo usar `helm push` para enviar um chart para um registry OCI, a referência\ndeve ser prefixada com `oci://` e não deve conter o nome base ou a tag.\n\nO nome base da referência do registry é inferido do nome do chart,\ne a tag é inferida da versão semântica do chart. Este é\natualmente um requisito estrito.\n\nCertos registries exigem que o repositório e/ou namespace (se especificado)\nsejam criados previamente. Caso contrário, um erro será produzido durante a\noperação `helm push`.\n\nSe você criou um [arquivo de provenance](/topics/provenance.md) (`.prov`) e ele estiver presente ao lado do arquivo `.tgz` do chart, ele será\nautomaticamente enviado para o registry durante o `push`. Isso resulta em\numa camada extra no [manifesto do chart Helm](#manifesto-do-chart-helm).\n\nUsuários do [plugin helm-push](https://github.com/chartmuseum/helm-push) (para enviar charts ao [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server))\npodem ter problemas, já que o plugin conflita com o novo `push` integrado.\nA partir da versão v0.10.0, o plugin foi renomeado para `cm-push`.\n\n### Outros subcomandos\n\nO suporte para o protocolo `oci://` também está disponível em vários outros subcomandos.\nAqui está a lista completa:\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nO nome base (nome do chart) da referência do registry *é*\nincluído para qualquer tipo de ação envolvendo download de chart\n(diferente do `helm push` onde é omitido).\n\nAqui estão alguns exemplos de uso dos subcomandos listados acima com\ncharts baseados em OCI:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Instalando charts com digest\n\nInstalar um chart com um digest é mais seguro do que com uma tag, pois os digests são imutáveis.\nO digest é especificado na URI do chart:\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## Especificando dependências\n\nAs dependências de um chart podem ser baixadas de um registry usando o subcomando `dependency update`.\n\nO `repository` para uma entrada específica no `Chart.yaml` é especificado como a referência do registry sem o nome base:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\nIsso buscará `oci://localhost:5000/myrepo/mychart:2.7.0` quando `dependency update` for executado.\n\n## Manifesto do chart Helm\n\nExemplo de manifesto de chart Helm como representado em um registry\n(observe os campos `mediaType`):\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nO exemplo a seguir contém um\n[arquivo de provenance](/topics/provenance.md)\n(observe a camada extra):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Migrando de repositórios de charts\n\nMigrar dos [repositórios de charts](/topics/chart_repository.md) clássicos\n(repositórios baseados em index.yaml) é simples: use `helm pull` e depois `helm push` para enviar os arquivos `.tgz` resultantes para um registry.\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: Migrando do Helm v2 para v3\ndescription: Aprenda como migrar do Helm v2 para o v3.\nsidebar_position: 13\n---\n\nEste guia mostra como migrar do Helm v2 para o v3. O Helm v2 precisa estar\ninstalado e gerenciando releases em um ou mais clusters.\n\n## Visão Geral das Mudanças do Helm 3\n\nA lista completa de mudanças do Helm 2 para o 3 está documentada na [seção de\nFAQ](/faq/changes_since_helm2.md). A seguir está um resumo de algumas dessas\nmudanças que o usuário deve conhecer antes e durante a migração:\n\n1. Remoção do Tiller:\n   - Substitui a arquitetura cliente/servidor por uma arquitetura\n     cliente/biblioteca (apenas o binário `helm`)\n   - A segurança agora é baseada por usuário (delegada à segurança do usuário\n     no cluster Kubernetes)\n   - Os releases agora são armazenados como secrets dentro do cluster e os\n     metadados do objeto release foram alterados\n   - Os releases são persistidos com base no namespace do release e não mais\n     no namespace do Tiller\n2. Repositório de charts atualizado:\n   - `helm search` agora suporta tanto buscas em repositórios locais quanto\n     consultas no Artifact Hub\n3. apiVersion do chart elevada para \"v2\" devido às seguintes mudanças na\n   especificação:\n   - Dependências de charts vinculadas dinamicamente foram movidas para\n     `Chart.yaml` (`requirements.yaml` removido e requirements --> dependencies)\n   - Charts de biblioteca (helper/common charts) agora podem ser adicionados\n     como dependências de charts vinculadas dinamicamente\n   - Charts possuem um campo de metadados `type` para definir se o chart é do\n     tipo `application` ou `library`. Por padrão, é application, o que significa\n     que é renderizável e instalável\n   - Charts do Helm 2 (apiVersion=v1) ainda podem ser instalados\n4. Especificação de diretórios XDG adicionada:\n   - Helm home foi removido e substituído pela especificação de diretórios XDG\n     para armazenar arquivos de configuração\n   - Não é mais necessário inicializar o Helm\n   - `helm init` e `helm home` foram removidos\n5. Mudanças adicionais:\n   - A instalação/configuração do Helm foi simplificada:\n     - Apenas o cliente Helm (binário helm) (sem Tiller)\n     - Paradigma de execução direta\n   - Repositórios `local` ou `stable` não são configurados por padrão\n   - O hook `crd-install` foi removido e substituído pelo diretório `crds` no\n     chart, onde todos os CRDs definidos nele serão instalados antes de qualquer\n     renderização do chart\n   - O valor de anotação do hook `test-failure` foi removido, e `test-success`\n     foi descontinuado. Use `test` em vez disso\n   - Comandos removidos/substituídos/adicionados:\n       - delete --> uninstall : remove todo o histórico de releases por padrão\n         (anteriormente era necessário `--purge`)\n       - fetch --> pull\n       - home (removido)\n       - init (removido)\n       - install: requer nome do release ou argumento `--generate-name`\n       - inspect --> show\n       - reset (removido)\n       - serve (removido)\n       - template: argumento `-x`/`--execute` renomeado para `-s`/`--show-only`\n       - upgrade: Adicionado argumento `--history-max` que limita o número\n         máximo de revisões salvas por release (0 para sem limite)\n   - A biblioteca Go do Helm 3 passou por muitas mudanças e é incompatível com\n     a biblioteca do Helm 2\n   - Os binários de release agora são hospedados em `get.helm.sh`\n\n## Casos de Uso da Migração\n\nOs casos de uso da migração são os seguintes:\n\n1. Helm v2 e v3 gerenciando o mesmo cluster:\n   - Esse caso de uso é recomendado apenas se você pretende descontinuar o\n     Helm v2 gradualmente e não precisa que o v3 gerencie nenhum release\n     implantado pelo v2. Todos os novos releases sendo implantados devem ser\n     realizados pelo v3 e os releases existentes implantados pelo v2 devem ser\n     atualizados/removidos apenas pelo v2\n   - O Helm v2 e v3 podem gerenciar o mesmo cluster sem problemas. As versões\n     do Helm podem ser instaladas no mesmo sistema ou em sistemas separados\n   - Se instalar o Helm v3 no mesmo sistema, você precisa realizar um passo\n     adicional para garantir que ambas as versões do cliente possam coexistir\n     até que você esteja pronto para remover o cliente Helm v2. Renomeie ou\n     coloque o binário do Helm v3 em uma pasta diferente para evitar conflitos\n   - Caso contrário, não há conflitos entre ambas as versões devido às\n     seguintes distinções:\n     - O armazenamento de releases (histórico) do v2 e v3 são independentes um\n       do outro. As mudanças incluem o recurso Kubernetes usado para\n       armazenamento e os metadados do objeto release contidos no recurso. Os\n       releases também estarão em um namespace por usuário em vez de usar o\n       namespace do Tiller (por exemplo, namespace padrão do Tiller no v2 é\n       kube-system). O v2 usa \"ConfigMaps\" ou \"Secrets\" no namespace do Tiller\n       com propriedade `TILLER`. O v3 usa \"Secrets\" no namespace do usuário com\n       propriedade `helm`. Os releases são incrementais tanto no v2 quanto no v3\n     - O único problema possível seria se recursos com escopo de cluster\n       Kubernetes (por exemplo, `clusterroles.rbac`) forem definidos em um\n       chart. A implantação do v3 falharia mesmo sendo única no namespace, pois\n       os recursos entrariam em conflito\n     - A configuração do v3 não usa mais `$HELM_HOME` e usa a especificação de\n       diretórios XDG em vez disso. Ela também é criada sob demanda. Portanto,\n       é independente da configuração do v2. Isso se aplica apenas quando ambas\n       as versões estão instaladas no mesmo sistema\n\n2. Migrando do Helm v2 para o Helm v3:\n   - Esse caso de uso se aplica quando você deseja que o Helm v3 gerencie\n     releases existentes do Helm v2\n   - Deve-se observar que um cliente Helm v2:\n     - pode gerenciar 1 ou mais clusters Kubernetes\n     - pode conectar-se a 1 ou mais instâncias do Tiller em um cluster\n   - Isso significa que você deve estar ciente disso ao migrar, pois os\n     releases são implantados nos clusters pelo Tiller e seu namespace. Você\n     deve, portanto, estar ciente de migrar cada cluster e cada instância do\n     Tiller que é gerenciada pela instância do cliente Helm v2\n   - O caminho recomendado para migração de dados é o seguinte:\n     1. Fazer backup dos dados do v2\n     2. Migrar a configuração do Helm v2\n     3. Migrar os releases do Helm v2\n     4. Quando estiver confiante de que o Helm v3 está gerenciando todos os\n        dados do Helm v2 (para todos os clusters e instâncias do Tiller da\n        instância do cliente Helm v2) conforme esperado, então limpe os dados\n        do Helm v2\n   - O processo de migração é automatizado pelo plugin\n     [2to3](https://github.com/helm/helm-2to3) do Helm v3\n\n## Referência\n\n   - Plugin [2to3](https://github.com/helm/helm-2to3) do Helm v3\n   - [Post](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) do blog\n     explicando o uso do plugin `2to3` com exemplos\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Política de Suporte de Versão do Helm\"\ndescription: \"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.\"\n---\n\nEste documento descreve a diferença máxima de versões suportada entre o Helm e\no Kubernetes.\n\n## Versões Suportadas\n\nAs versões do Helm são expressas como `x.y.z`, onde `x` é a versão principal\n(major), `y` é a versão secundária (minor) e `z` é a versão de correção (patch),\nseguindo a terminologia de [Versionamento Semântico](https://semver.org/spec/v2.0.0.html).\n\nO projeto Helm mantém um branch de release para a versão secundária mais recente.\nCorreções aplicáveis, incluindo correções de segurança, são incorporadas ao branch\nde release, dependendo da severidade e viabilidade. Mais detalhes podem ser\nencontrados na [política de releases do Helm](/community/release_policy).\n\n## Diferença de Versão Suportada\n\nQuando uma nova versão do Helm é lançada, ela é compilada com uma versão secundária\nespecífica do Kubernetes. Por exemplo, o Helm 3.0.0 interage com o Kubernetes\nusando o cliente Kubernetes 1.16.2, portanto é compatível com o Kubernetes 1.16.\n\nA partir do Helm 3, o Helm é compatível com versões `n-3` do Kubernetes com o\nqual foi compilado. Devido às mudanças do Kubernetes entre versões secundárias,\na política de suporte do Helm 2 é um pouco mais restrita, sendo compatível com\nversões `n-1` do Kubernetes.\n\nPor exemplo, se você estiver usando uma versão do Helm 3 que foi compilada com\nas APIs do cliente Kubernetes 1.17, ela deve funcionar de forma segura com o\nKubernetes 1.17, 1.16, 1.15 e 1.14. Se você estiver usando uma versão do Helm 2\nque foi compilada com as APIs do cliente Kubernetes 1.16, ela deve funcionar de\nforma segura com o Kubernetes 1.16 e 1.15.\n\nNão é recomendado usar o Helm com uma versão do Kubernetes mais recente do que\naquela com a qual ele foi compilado, pois o Helm não oferece garantias de\ncompatibilidade futura.\n\nSe você optar por usar o Helm com uma versão do Kubernetes que não é suportada,\nvocê estará fazendo isso por sua própria conta e risco.\n\nConsulte a tabela abaixo para determinar qual versão do Helm é compatível com\no seu cluster.\n\n| Versão do Helm | Versões do Kubernetes Suportadas |\n|----------------|----------------------------------|\n| 3.20.x         | 1.35.x - 1.32.x                  |\n| 3.19.x         | 1.34.x - 1.31.x                  |\n| 3.18.x         | 1.33.x - 1.30.x                  |\n| 3.17.x         | 1.32.x - 1.29.x                  |\n| 3.16.x         | 1.31.x - 1.28.x                  |\n| 3.15.x         | 1.30.x - 1.27.x                  |\n| 3.14.x         | 1.29.x - 1.26.x                  |\n| 3.13.x         | 1.28.x - 1.25.x                  |\n| 3.12.x         | 1.27.x - 1.24.x                  |\n| 3.11.x         | 1.26.x - 1.23.x                  |\n| 3.10.x         | 1.25.x - 1.22.x                  |\n| 3.9.x          | 1.24.x - 1.21.x                  |\n| 3.8.x          | 1.23.x - 1.20.x                  |\n| 3.7.x          | 1.22.x - 1.19.x                  |\n| 3.6.x          | 1.21.x - 1.18.x                  |\n| 3.5.x          | 1.20.x - 1.17.x                  |\n| 3.4.x          | 1.19.x - 1.16.x                  |\n| 3.3.x          | 1.18.x - 1.15.x                  |\n| 3.2.x          | 1.18.x - 1.15.x                  |\n| 3.1.x          | 1.17.x - 1.14.x                  |\n| 3.0.x          | 1.16.x - 1.13.x                  |\n| 2.16.x         | 1.16.x - 1.15.x                  |\n| 2.15.x         | 1.15.x - 1.14.x                  |\n| 2.14.x         | 1.14.x - 1.13.x                  |\n| 2.13.x         | 1.13.x - 1.12.x                  |\n| 2.12.x         | 1.12.x - 1.11.x                  |\n| 2.11.x         | 1.11.x - 1.10.x                  |\n| 2.10.x         | 1.10.x - 1.9.x                   |\n| 2.9.x          | 1.10.x - 1.9.x                   |\n| 2.8.x          | 1.9.x - 1.8.x                    |\n| 2.7.x          | 1.8.x - 1.7.x                    |\n| 2.6.x          | 1.7.x - 1.6.x                    |\n| 2.5.x          | 1.6.x - 1.5.x                    |\n| 2.4.x          | 1.6.x - 1.5.x                    |\n| 2.3.x          | 1.5.x - 1.4.x                    |\n| 2.2.x          | 1.5.x - 1.4.x                    |\n| 2.1.x          | 1.5.x - 1.4.x                    |\n| 2.0.x          | 1.4.x - 1.3.x                    |\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"Introdução\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"Como fazer\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"Tópicos\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Melhores Práticas\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"Guia de Templates de Chart\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Comandos do Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"Comunidade\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"Perguntas Frequentes\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/pt/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: \"Política de Cronograma de Releases\"\ndescription: \"Descreve a política de cronograma de releases do Helm.\"\n---\n\nPara benefício de seus usuários, o Helm define e anuncia as datas de releases\ncom antecedência. Este documento descreve a política que governa o cronograma\nde releases do Helm.\n\n## Calendário de Releases\n\nUm calendário público mostrando os próximos releases do Helm pode ser encontrado [aqui](https://helm.sh/calendar/release).\n\n## Versionamento Semântico\n\nAs versões do Helm são expressas como `x.y.z`, onde `x` é a versão principal\n(major), `y` é a versão secundária (minor) e `z` é a versão de correção (patch),\nseguindo a terminologia de [Versionamento Semântico](https://semver.org/spec/v2.0.0.html).\n\n## Releases de Correção\n\nOs releases de correção fornecem aos usuários correções de bugs e correções de\nsegurança. Eles não contêm novas funcionalidades.\n\nUm novo release de correção relacionado ao release secundário/principal mais\nrecente normalmente será feito uma vez por mês, na segunda quarta-feira de cada\nmês.\n\nUm release de correção para resolver uma regressão de alta prioridade ou um\nproblema de segurança pode ser feito sempre que necessário.\n\nUm release de correção será cancelado por qualquer um dos seguintes motivos:\n- se não houver novo conteúdo desde o release anterior\n- se a data do release de correção cair dentro de uma semana antes do primeiro\n  release candidate (RC1) de um próximo release secundário\n- se a data do release de correção cair dentro de quatro semanas após um release\n  secundário\n\n## Releases Secundários\n\nOs releases secundários contêm correções de segurança e bugs, bem como novas\nfuncionalidades. Eles são retrocompatíveis em relação à API e ao uso da CLI.\n\nPara alinhar com os releases do Kubernetes, um release secundário do Helm será\nfeito a cada 4 meses (3 releases por ano).\n\nReleases secundários extras podem ser feitos se necessário, mas não afetarão o\ncronograma de um release futuro anunciado, a menos que o release anunciado\nesteja a menos de 7 dias.\n\nAo mesmo tempo em que um release é publicado, a data do próximo release secundário\nserá anunciada e publicada na página principal do Helm.\n\n## Releases Principais\n\nOs releases principais contêm mudanças incompatíveis. Tais releases são raros,\nmas às vezes são necessários para permitir que o Helm continue a evoluir em\nnovas direções importantes.\n\nOs releases principais podem ser difíceis de planejar. Com isso em mente, uma\ndata final de release só será escolhida e anunciada quando a primeira versão\nbeta de tal release estiver disponível.\n"
  },
  {
    "path": "i18n/pt/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Projeto Helm\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"Desenvolvimento\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"Comunidade\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"Código fonte\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"Eventos\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"Código de Conduta\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"Introdução\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Dicas e truques de Charts\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"Desenvolver Charts\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"Pesquisar 800+ Charts\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"Guia de Contribuição\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"Mantenedores\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"Reuniões Semanais\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"Comunidade no GitHub\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<a href=\\\"https://www.cncf.io/\\\">Somos um projeto graduado da Cloud Native Computing Foundation.</a><br/>© Autores do Helm 2025. Documentação distribuída sob <a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0.</a><br/>© 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 <a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">página de Uso de Marcas</a>.\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Logótipo CNCF\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/pt/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Logótipo Helm\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"Documentação\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"Blog\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"Comunidade\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/ru/code.json",
    "content": "{\n  \"home.about.whatIsHelm\": {\n    \"message\": \"Helm помогает управлять приложениями Kubernetes — Helm Charts помогают определять, устанавливать и обновлять даже самые сложные приложения Kubernetes.\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"message\": \"Charts легко создавать, версионировать, делиться ими и публиковать — поэтому начните использовать Helm и прекратите копировать и вставлять.\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Helm — это дипломированный проект в {cncfLink} и поддерживается {helmCommunityLink}.\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"сообществом Helm\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"Узнать больше:\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Архитектура Helm\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"Руководство по быстрому старту\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"Видео: Введение в Helm\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"Что такое Helm?\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"Следующая версия\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"Версия:\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"Дата:\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"Календарь релизов\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"Предстоящие события\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"Предстоящие события\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"Прошедшие события\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"Они {meetLink}, чтобы демонстрировать и обсуждать инструменты и проекты. Встречи сообщества записываются и {youtubeLink}.\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"встречаются каждую неделю\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"публикуются на YouTube\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"Стендапы разработчиков\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"Четверг 9:30-10am (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"Эти встречи открыты для всех. Проверьте {communityRepoLink} для заметок и деталей.\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"репозиторий сообщества\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Обсуждение использования Helm, работы с чартами и решения распространённых ошибок.\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Темы, касающиеся разработки Helm, текущих PR, релизов и т.д.\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Обсуждение для пользователей и разработчиков Helm Charts.\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"{slackLink}, чтобы присоединиться к команде Kubernetes Slack.\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"Запросите доступ здесь\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"Вклад в проект\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"Helm всегда приветствует новые вклады в проект!\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"С чего начать?\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Helm — это большой проект с множеством пользователей и разработчиков. Это может быть сложно для восприятия!\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"У нас есть список {goodFirstIssuesLink}, если вы хотите помочь, но не знаете, с чего начать.\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"хороших первых задач\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"Что мне делать?\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"Прежде чем вносить код, пожалуйста, прочитайте наше {contributionGuideLink}. Оно описывает процессы создания и проверки пул-реквестов.\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"Руководство по вкладу\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"После того, как вы напишете код, пожалуйста, {signYourCommitsLink}, чтобы убедиться, что Helm соблюдает соглашение {dcoLink}, используемое {cncfLink}.\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"подпишите свои коммиты\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"Присоединиться к сообществу\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Больше информации о проекте Helm и о том, как внести свой вклад.\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"Управление сложностью\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"message\": \"Charts описывают даже самые сложные приложения, обеспечивают повторяемую установку приложений и служат единой точкой авторитета.\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"Простые обновления\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"Избавьтесь от проблем с обновлениями благодаря обновлениям на месте и пользовательским хукам.\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"Простой обмен\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"Charts легко версионировать, делиться ими и размещать на публичных или частных серверах.\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"Откаты\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"Используйте {helmRollback}, чтобы легко откатиться к более старой версии релиза.\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"Возможности\",\n    \"description\": \"Features section title\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"Начало работы\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"Скачайте Helm!\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"Установите Helm с помощью менеджера пакетов или {downloadLink}.\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"скачайте бинарный файл\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"message\": \"После установки распакуйте бинарный файл helm, добавьте его в ваш PATH — и всё готово! Проверьте {docsLink} для получения дополнительной информации об {installationLink} и {usageLink}.\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"документацию\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"установке\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"инструкциях по использованию\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"Скачайте Chart-ы\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"Посетите {artifactHubLink}, чтобы изучить {helmChartsLink} из множества публичных репозиториев.\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"чарты Helm\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"Менеджер пакетов для Kubernetes\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Helm — лучший способ находить, делиться и использовать программное обеспечение, созданное для\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"На странице произошёл сбой.\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"Прокрутка к началу\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"Архив\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"Архив\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"Навигация по странице списка блогов\",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"Следующие записи\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"Предыдущие записи\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"Навигация по странице поста блога\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"Следующий пост\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"Предыдущий пост\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"Посмотреть все теги\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"системный режим\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"Светлый режим\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"Тёмный режим\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"Переключение между темным и светлым режимом (сейчас используется {mode})\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"Навигационная цепочка текущей страницы\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"{count} элемент|{count} элемента|{count} элементов\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"Страница документа\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"Предыдущая страница\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"Следующая страница\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"Одна страница|{count} страницы|{count} страниц\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged} с тегом \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"Версия: {versionLabel}\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"Это документация для будущей версии {siteTitle} {versionLabel}.\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"Это документация {siteTitle} для версии {versionLabel}, которая уже не поддерживается.\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"Актуальная документация находится на странице {latestVersionLink} ({versionLabel}).\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"последней версии\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"Отредактировать эту страницу\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \" {date}\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \" от {user}\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"Последнее обновление{atDate}{byUser}\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"Прямая ссылка на {heading}\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"Страница не найдена\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"Версии\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"Теги:\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"Закрыть\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"предупреждение\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"осторожно\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"к сведению\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"примечание\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"подсказка\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"предупреждение\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"Навигация по последним постам в блоге\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"Развернуть категорию сайдбара '{label}'\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"Свернуть категорию сайдбара '{label}'\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(откроется в новой вкладке)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"Главная\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"К сожалению, мы не смогли найти запрашиваемую вами страницу.\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"message\": \"Пожалуйста, обратитесь к владельцу сайта, с которого вы перешли на эту ссылку, чтобы сообщить ему, что ссылка не работает.\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"Содержание этой страницы\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"Языки\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"Читать дальше\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"Подробнее о {title}\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"{readingTime} мин. чтения|{readingTime} мин. чтения|{readingTime} мин. чтения\",\n    \"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)\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"Скопировать\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"Скопировано\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"Скопировать в буфер обмена\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"Переключить перенос по строкам\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"Главная страница\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"Свернуть сайдбар\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"Свернуть сайдбар\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"Сайдбар документации\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"Закрыть панель навигации\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"Переключить навигационную панель\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← Перейти к главному меню\",\n    \"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)\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"Развернуть выпадающее меню\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"Свернуть выпадающее меню\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"Развернуть сайдбар\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"Развернуть сайдбар\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"{count} запись|{count} записи|{count} записей\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"{nPosts} с тегом \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"Авторы\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"Посмотреть всех авторов\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"Этот автор ещё не написал ни одной публикации.\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"Страница не в списке\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"message\": \"Эта страница не включена в список. Поисковые системы не будут индексировать её, и доступ к ней имеют только пользователи с прямой ссылкой.\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"Черновик страницы\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"Это черновик страницы. Она будет видна только в режиме разработки и будет исключена из продакшен-сборки.\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"Попробуйте ещё раз\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"Перейти к основному содержимому\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"Теги\",\n    \"description\": \"The title of the tag list page\"\n  }\n}\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Блог\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"Блог\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"Все записи\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Использование Helm\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Команды Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"Чарты\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"Разработка шаблонов\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Лучшие практики\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: Общие соглашения\ndescription: Общие соглашения для чартов.\nsidebar_position: 1\n---\n\nЭта часть руководства по лучшим практикам посвящена общим соглашениям.\n\n## Названия чартов\n\nНазвания чартов должны содержать только строчные буквы и цифры. Слова _могут_ быть разделены дефисами (-):\n\nПримеры:\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nВ названиях чартов нельзя использовать заглавные буквы и подчёркивания. Точки также не следует использовать в названиях чартов.\n\n## Номера версий\n\nПо возможности Helm использует [SemVer 2](https://semver.org) для представления номеров версий. (Обратите внимание, что теги Docker-образов не обязательно соответствуют SemVer и поэтому считаются досадным исключением из этого правила.)\n\nПри хранении версий SemVer в метках Kubernetes символ `+` принято заменять на `_`, так как метки не допускают использование символа `+` в качестве значения.\n\n## Форматирование YAML\n\nФайлы YAML должны использовать отступы в _два пробела_ (и никогда табуляцию).\n\n## Использование слов Helm и чарт\n\nСуществует несколько соглашений по использованию слов _Helm_ и _helm_.\n\n- _Helm_ относится к проекту в целом\n- `helm` относится к клиентской команде\n- Термин `chart` не нужно писать с заглавной буквы, так как это не имя собственное\n- Однако `Chart.yaml` нужно писать с заглавной буквы, так как имя файла чувствительно к регистру\n\nЕсли есть сомнения, используйте _Helm_ (с заглавной «H»).\n\n## Шаблоны чартов и пространства имён\n\nИзбегайте определения свойства `namespace` в секции `metadata` шаблонов вашего чарта. Пространство имён для применения отрендеренных шаблонов должно указываться при вызове клиента Kubernetes через флаг `--namespace`. Helm рендерит ваши шаблоны как есть и отправляет их клиенту Kubernetes — будь то сам Helm или другая программа (kubectl, flux, spinnaker и т.д.).\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Пользовательские определения ресурсов\ndescription: Как создавать и использовать CRD.\nsidebar_position: 7\n---\n\nЭта часть руководства по лучшим практикам посвящена созданию и использованию\nобъектов Custom Resource Definition.\n\nПри работе с Custom Resource Definition (CRD) важно различать две составляющие:\n\n- Есть декларация CRD. Это YAML-файл с kind `CustomResourceDefinition`\n- Есть ресурсы, которые _используют_ CRD. Например, если CRD определяет\n  `foo.example.com/v1`, то любой ресурс с `apiVersion: example.com/v1` и\n  kind `Foo` является ресурсом, использующим этот CRD.\n\n## Установите декларацию CRD перед использованием ресурса\n\nHelm оптимизирован для максимально быстрой загрузки ресурсов в Kubernetes.\nKubernetes спроектирован так, что может принять целый набор манифестов и привести\nв рабочее состояние (это называется циклом согласования).\n\nНо с CRD есть одно отличие.\n\nДля CRD декларация должна быть зарегистрирована до того, как можно будет\nиспользовать какие-либо ресурсы этого типа CRD. А процесс регистрации\nиногда занимает несколько секунд.\n\n### Метод 1: Позвольте `helm` сделать это за вас\n\nС выходом Helm 3 мы убрали старые хуки `crd-install` в пользу более простой\nметодологии. Теперь вы можете создать в своём чарте специальную директорию `crds`\nдля хранения ваших CRD. Эти CRD не шаблонизируются, но устанавливаются по умолчанию\nпри выполнении `helm install` для чарта. Если CRD уже существует, он будет пропущен\nс предупреждением. Если вы хотите пропустить шаг установки CRD, можете передать\nфлаг `--skip-crds`.\n\n#### Некоторые оговорки (и объяснения)\n\nНа данный момент обновление или удаление CRD с помощью Helm не поддерживается.\nЭто было осознанное решение после длительного обсуждения в сообществе из-за\nопасности непреднамеренной потери данных. Кроме того, в настоящее время нет\nконсенсуса в сообществе относительно того, как обращаться с CRD и их жизненным\nциклом. По мере развития ситуации Helm добавит поддержку этих сценариев использования.\n\nФлаг `--dry-run` команд `helm install` и `helm upgrade` в настоящее время не\nподдерживается для CRD. Цель «Dry Run» — проверить, что вывод чарта действительно\nбудет работать при отправке на сервер. Но CRD изменяют поведение сервера. Helm\nне может установить CRD при dry run, поэтому клиент обнаружения не будет знать\nоб этом Custom Resource (CR), и валидация завершится неудачей. В качестве\nальтернативы вы можете вынести CRD в отдельный чарт или использовать\n`helm template` вместо этого.\n\nЕщё один важный момент при обсуждении поддержки CRD — это то, как обрабатывается\nрендеринг шаблонов. Одним из существенных недостатков метода `crd-install`,\nиспользовавшегося в Helm 2, была невозможность правильной валидации чартов\nиз-за изменения доступности API (CRD фактически добавляет ещё один доступный API\nв ваш кластер Kubernetes). Если чарт устанавливал CRD, у `helm` больше не было\nактуального набора версий API для работы. Это также причина удаления поддержки\nшаблонизации из CRD. С новым методом установки CRD через директорию `crds`\nмы теперь гарантируем, что `helm` имеет полностью достоверную информацию о\nтекущем состоянии кластера.\n\n### Метод 2: Разделение на отдельные чарты\n\nДругой способ — поместить определение CRD в один чарт, а все ресурсы,\nиспользующие этот CRD, — в _другой_ чарт.\n\nПри этом методе каждый чарт должен устанавливаться отдельно. Однако такой рабочий\nпроцесс может быть более полезен для операторов кластера, имеющих административный\nдоступ к кластеру.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: Зависимости\ndescription: Рекомендации по работе с зависимостями чартов.\nsidebar_position: 4\n---\n\nЭта часть руководства по лучшим практикам посвящена зависимостям (`dependencies`), объявленным в файле `Chart.yaml`.\n\n## Версии\n\nПо возможности используйте диапазоны версий вместо фиксации на конкретной версии. Рекомендуемый подход — использовать соответствие на уровне патч-версии:\n\n```yaml\nversion: ~1.2.3\n```\n\nЭто выражение соответствует версии `1.2.3` и всем патчам этого релиза. Другими словами, `~1.2.3` эквивалентно `>= 1.2.3, < 1.3.0`.\n\nПолное описание синтаксиса версий см. в [документации semver](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Предварительные версии (prerelease)\n\nУказанные выше ограничения версий не применяются к предварительным версиям. Например, `version: ~1.2.3` будет соответствовать `version: ~1.2.4`, но не `version: ~1.2.3-1`. Следующий синтаксис позволяет сопоставлять как патч-версии, так и предварительные версии:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### URL репозиториев\n\nПо возможности используйте URL с `https://`, затем — с `http://`.\n\nЕсли репозиторий добавлен в индексный файл репозиториев, имя репозитория можно использовать как псевдоним URL. Используйте `alias:` или `@` перед именем репозитория.\n\nURL-адреса файлов (`file://...`) рассматриваются как «особый случай» для чартов, которые собираются в рамках фиксированного конвейера развёртывания.\n\nПри использовании [плагинов-загрузчиков](../topics/plugins.md#плагины-загрузчики) схема URL будет специфичной для плагина. Обратите внимание: пользователю чарта потребуется установленный плагин, поддерживающий данную схему, для обновления или сборки зависимости.\n\nHelm не может выполнять операции управления зависимостями, если поле `repository` оставлено пустым. В этом случае Helm предполагает, что зависимость находится в подкаталоге папки `charts` с именем, совпадающим со значением свойства `name` зависимости.\n\n## Условия и теги\n\nУсловия (conditions) или теги (tags) следует добавлять к любым зависимостям, которые являются _опциональными_. Обратите внимание, что по умолчанию `condition` имеет значение `true`.\n\nПредпочтительная форма условия:\n\n```yaml\ncondition: somechart.enabled\n```\n\nГде `somechart` — это имя чарта-зависимости.\n\nКогда несколько подчартов (зависимостей) вместе предоставляют опциональную или взаимозаменяемую функциональность, эти чарты должны использовать одинаковые теги.\n\nНапример, если `nginx` и `memcached` вместе обеспечивают оптимизацию производительности основного приложения в чарте и должны присутствовать одновременно при включении этой функции, то оба должны иметь следующий раздел тегов:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nЭто позволяет пользователю включать или отключать данную функциональность с помощью одного тега.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx",
    "content": "---\ntitle: Лучшие практики\nsidebar: true\nsidebar_position: 4\n---\n\n# Руководство по лучшим практикам для чартов\n\nЭто руководство описывает лучшие практики создания чартов, рекомендованные командой Helm.\nОно фокусируется на том, как должны быть структурированы чарты.\n\nМы уделяем основное внимание лучшим практикам для чартов, которые могут быть публично развёрнуты.\nМы понимаем, что многие чарты предназначены только для внутреннего использования, и авторы таких чартов\nмогут обнаружить, что их внутренние требования расходятся с нашими рекомендациями.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: Метки и аннотации\ndescription: Рекомендации по использованию меток и аннотаций в чартах.\nsidebar_position: 5\n---\n\nЭта часть руководства по лучшим практикам посвящена использованию меток и аннотаций в чартах.\n\n## Метка или аннотация?\n\nЭлемент метаданных должен быть меткой, если:\n\n- Он используется Kubernetes для идентификации ресурса\n- Он полезен администраторам для запросов к системе.\n\nНапример, мы рекомендуем использовать `helm.sh/chart: NAME-VERSION` в качестве метки, чтобы администраторы могли легко находить все экземпляры определённого чарта.\n\nЕсли элемент метаданных не используется для запросов, его следует устанавливать как аннотацию.\n\nХуки Helm всегда являются аннотациями.\n\n## Стандартные метки\n\nВ таблице ниже перечислены общепринятые метки, используемые в чартах Helm. Сам Helm не требует наличия какой-либо конкретной метки. Метки, отмеченные как REC, являются рекомендуемыми и **должны** присутствовать в чарте для обеспечения единообразия. Метки, отмеченные как OPT, являются опциональными. Они широко распространены, но редко требуются в рабочих процессах.\n\nИмя|Статус|Описание\n-----|------|----------\n`app.kubernetes.io/name` | REC | Название приложения целиком. Обычно используется `{{ template \"name\" . }}`. Эта метка используется во многих манифестах Kubernetes, не только в Helm.\n`helm.sh/chart` | REC | Название и версия чарта: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`.\n`app.kubernetes.io/managed-by` | REC | Всегда устанавливается в `{{ .Release.Service }}`. Используется для поиска всех ресурсов, управляемых Helm.\n`app.kubernetes.io/instance` | REC | Устанавливается в `{{ .Release.Name }}`. Помогает различать разные экземпляры одного и того же приложения.\n`app.kubernetes.io/version` | OPT | Версия приложения. Может быть установлена в `{{ .Chart.AppVersion }}`.\n`app.kubernetes.io/component` | OPT | Общепринятая метка для обозначения роли компонентов в приложении. Например, `app.kubernetes.io/component: frontend`.\n`app.kubernetes.io/part-of` | OPT | Используется, когда несколько чартов или программных компонентов вместе составляют единое приложение. Например, прикладное ПО и база данных для создания веб-сайта. Может быть установлена в название приложения верхнего уровня.\n\nПодробную информацию о метках Kubernetes с префиксом `app.kubernetes.io` можно найти в [документации Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pod и PodTemplate\ndescription: Рекомендации по форматированию секций Pod и PodTemplate в манифестах чартов.\nsidebar_position: 6\n---\n\nЭта часть руководства по лучшим практикам посвящена форматированию секций Pod и\nPodTemplate в манифестах чартов.\n\nСледующий (неполный) список ресурсов использует PodTemplate:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Образы\n\nОбраз контейнера должен использовать фиксированный тег или SHA образа. Не следует\nиспользовать теги `latest`, `head`, `canary` или другие теги, которые являются\n«плавающими».\n\nОбразы _могут_ быть определены в файле `values.yaml` для удобной замены образов.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nОбраз и тег _могут_ быть определены в `values.yaml` как два отдельных поля:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\nКоманда `helm create` устанавливает `imagePullPolicy` в значение `IfNotPresent`\nпо умолчанию, добавляя следующее в ваш `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nИ в `values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nАналогично, Kubernetes устанавливает `imagePullPolicy` в значение `IfNotPresent`\nпо умолчанию, если оно не задано вообще. Если вам нужно значение, отличное от\n`IfNotPresent`, просто обновите значение в `values.yaml` на желаемое.\n\n## Секции PodTemplate должны объявлять селекторы\n\nВсе секции PodTemplate должны указывать селектор. Например:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nЭто хорошая практика, поскольку она явно определяет связь между набором и Pod.\n\nНо это ещё более важно для таких ресурсов, как Deployment. Без этого для выбора\nсоответствующих Pod будет использоваться _весь_ набор меток, что приведёт к сбоям,\nесли вы используете метки, которые изменяются, например версию или дату релиза.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: Управление доступом на основе ролей\ndescription: Рекомендации по созданию и форматированию ресурсов RBAC в манифестах чартов.\nsidebar_position: 8\n---\n\nЭта часть руководства по лучшим практикам посвящена созданию и форматированию\nресурсов RBAC в манифестах чартов.\n\nК ресурсам RBAC относятся:\n\n- ServiceAccount (namespaced)\n- Role (namespaced)\n- ClusterRole\n- RoleBinding (namespaced)\n- ClusterRoleBinding\n\n## Конфигурация YAML\n\nНастройки RBAC и ServiceAccount должны располагаться в отдельных ключах. Это разные\nсущности. Разделение этих концепций в YAML устраняет неоднозначность и делает\nконфигурацию более понятной.\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\nЭту структуру можно расширить для более сложных чартов, требующих несколько\nServiceAccount.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## Ресурсы RBAC должны создаваться по умолчанию\n\nПараметр `rbac.create` должен быть булевым значением, управляющим созданием ресурсов\nRBAC. Значение по умолчанию должно быть `true`. Пользователи, которые хотят\nуправлять доступом RBAC самостоятельно, могут установить это значение в `false`\n(в этом случае см. ниже).\n\n## Использование ресурсов RBAC\n\nВ параметре `serviceAccount.name` должно быть указано имя ServiceAccount, который\nбудет использоваться ресурсами с контролем доступа, создаваемыми чартом. Если\n`serviceAccount.create` равен true, то ServiceAccount с этим именем должен быть\nсоздан. Если имя не указано, оно генерируется с помощью шаблона `fullname`. Если\n`serviceAccount.create` равен false, то ServiceAccount не создаётся, но он всё\nравно должен быть связан с теми же ресурсами, чтобы вручную созданные ресурсы RBAC,\nссылающиеся на него, работали корректно. Если `serviceAccount.create` равен false\nи имя не указано, используется ServiceAccount по умолчанию.\n\nДля ServiceAccount следует использовать следующий вспомогательный шаблон.\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: Шаблоны\ndescription: Подробные рекомендации по работе с шаблонами.\nsidebar_position: 3\n---\n\nЭта часть руководства по лучшим практикам посвящена работе с шаблонами.\n\n## Структура директории `templates/`\n\nДиректория `templates/` должна быть организована следующим образом:\n\n- Файлы шаблонов должны иметь расширение `.yaml`, если они генерируют YAML-вывод.\n  Расширение `.tpl` может использоваться для файлов шаблонов, которые не производят\n  форматированного содержимого.\n- Имена файлов шаблонов должны использовать нотацию с дефисами (`my-example-configmap.yaml`),\n  а не camelCase.\n- Каждое определение ресурса должно находиться в отдельном файле шаблона.\n- Имена файлов шаблонов должны отражать тип ресурса в названии, например:\n  `foo-pod.yaml`, `bar-svc.yaml`\n\n## Имена именованных шаблонов\n\nИменованные шаблоны (шаблоны, созданные внутри директивы `{{ define }}`) доступны\nглобально. Это означает, что чарт и все его субчарты будут иметь доступ ко всем\nшаблонам, созданным с помощью `{{ define }}`.\n\nПо этой причине _все имена именованных шаблонов должны иметь уникальный префикс._\n\nПравильно:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nНеправильно:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\n\nНастоятельно рекомендуется создавать новые чарты с помощью команды `helm create`,\nпоскольку при этом имена шаблонов автоматически формируются в соответствии с этой лучшей практикой.\n\n## Форматирование шаблонов\n\nШаблоны должны иметь отступы в _два пробела_ (никогда не используйте табуляцию).\n\nДирективы шаблона должны иметь пробел после открывающих фигурных скобок и перед\nзакрывающими фигурными скобками:\n\nПравильно:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nНеправильно:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nПо возможности шаблоны должны удалять лишние пробельные символы:\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nБлоки (такие как управляющие конструкции) могут иметь отступы для отображения потока\nкода шаблона.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nОднако, поскольку YAML является языком, ориентированным на пробельные символы,\nчасто невозможно следовать этому соглашению для отступов кода.\n\n## Пробельные символы в сгенерированных шаблонах\n\nПредпочтительно минимизировать количество пробельных символов в сгенерированных шаблонах.\nВ частности, множество пустых строк не должно располагаться рядом друг с другом.\nОднако отдельные пустые строки (особенно между логическими секциями) допустимы.\n\nЛучше всего так:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nТак тоже допустимо:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nНо такого следует избегать:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Комментарии (YAML-комментарии и комментарии шаблонов)\n\nИ YAML, и шаблоны Helm имеют маркеры комментариев.\n\nYAML-комментарии:\n```yaml\n# Это комментарий\ntype: sprocket\n```\n\nКомментарии шаблонов:\n```yaml\n{{- /*\nЭто комментарий.\n*/}}\ntype: frobnitz\n```\n\nКомментарии шаблонов следует использовать для документирования возможностей шаблона,\nнапример, для пояснения именованного шаблона:\n\n```yaml\n{{- /*\nmychart.shortname предоставляет обрезанную до 6 символов версию имени релиза.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nВнутри шаблонов YAML-комментарии могут использоваться, когда полезно, чтобы пользователи\nHelm могли (возможно) видеть комментарии во время отладки.\n\n```yaml\n# Это может вызвать проблемы, если значение превышает 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nКомментарий выше виден, когда пользователь выполняет `helm install --debug`, тогда как\nкомментарии, указанные в секциях `{{- /* */}}`, не видны.\n\nБудьте осторожны при добавлении YAML-комментариев `#` к секциям шаблона, содержащим значения Helm, которые могут потребоваться для некоторых функций шаблона.\n\nНапример, если к приведённому выше примеру добавить функцию `required`, и `maxMem` не задано, то YAML-комментарий `#` вызовет ошибку рендеринга.\n\nПравильно: `helm template` не выполняет рендеринг этого блока\n```yaml\n{{- /*\n# Это может вызвать проблемы, если значение превышает 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nНеправильно: `helm template` возвращает `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n```yaml\n# Это может вызвать проблемы, если значение превышает 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nСмотрите [Отладка шаблонов](/chart_template_guide/debugging.md), где приведён другой пример такого поведения — YAML-комментарии остаются без изменений.\n\n## Использование JSON в шаблонах и выводе шаблонов\n\nYAML является надмножеством JSON. В некоторых случаях использование синтаксиса JSON\nможет быть более читаемым, чем другие представления YAML.\n\nНапример, этот YAML ближе к обычному методу YAML для выражения списков:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nНо его легче читать, когда он свёрнут в стиле JSON-списка:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nИспользование JSON для повышения читаемости — хорошая практика. Однако синтаксис JSON\nне следует использовать для представления более сложных конструкций.\n\nПри работе с чистым JSON, встроенным в YAML (например, конфигурация init-контейнера),\nконечно, уместно использовать формат JSON.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: Values\ndescription: Рекомендации по структуре и использованию values.\nsidebar_position: 2\n---\n\nЭта часть руководства по лучшим практикам посвящена использованию values. Здесь мы даём рекомендации по структуре и использованию values с акцентом на проектирование файла `values.yaml` чарта.\n\n## Соглашения об именовании\n\nИмена переменных должны начинаться со строчной буквы, а слова разделяться в стиле camelCase:\n\nПравильно:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nНеправильно:\n\n```yaml\nChicken: true  # заглавная буква может конфликтовать со встроенными переменными\nchicken-noodle-soup: true # не используйте дефисы в именах\n```\n\nОбратите внимание, что все встроенные переменные Helm начинаются с заглавной буквы, чтобы их можно было легко отличить от пользовательских значений: `.Release.Name`, `.Capabilities.KubeVersion`.\n\n## Плоские или вложенные значения\n\nYAML — гибкий формат, и значения могут быть как глубоко вложенными, так и плоскими.\n\nВложенные:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nПлоские:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nВ большинстве случаев плоская структура предпочтительнее вложенной. Причина в том, что так проще и для разработчиков шаблонов, и для пользователей.\n\nДля обеспечения безопасности вложенное значение необходимо проверять на каждом уровне:\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nДля каждого уровня вложенности требуется проверка существования. Для плоской конфигурации такие проверки можно пропустить, что делает шаблон проще для чтения и использования.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\nВложенные значения можно использовать для улучшения читаемости, когда имеется большое количество связанных переменных и хотя бы одна из них является обязательной.\n\n## Явно указывайте типы\n\nПравила приведения типов в YAML иногда неинтуитивны. Например, `foo: false` — это не то же самое, что `foo: \"false\"`. Большие целые числа, такие как `foo: 12345678`, в некоторых случаях преобразуются в экспоненциальную запись.\n\nСамый простой способ избежать ошибок преобразования типов — быть явным со строками и неявным со всем остальным. Или, коротко, _заключайте все строки в кавычки_.\n\nЧасто бывает полезно хранить целые числа также в виде строк, чтобы избежать проблем с приведением типов, и использовать `{{ int $value }}` в шаблоне для преобразования строки обратно в целое число.\n\nВ большинстве случаев явные теги типов корректно обрабатываются, поэтому `foo: !!string 1234` будет воспринимать `1234` как строку. _Однако_ YAML-парсер обрабатывает теги, и информация о типе теряется после первого разбора.\n\n## Учитывайте, как пользователи будут использовать ваши values\n\nСуществует три возможных источника values:\n\n- Файл `values.yaml` чарта\n- Файл values, переданный через `helm install -f` или `helm upgrade -f`\n- Значения, переданные через флаг `--set` или `--set-string` при выполнении `helm install` или `helm upgrade`\n\nПри проектировании структуры values помните, что пользователи вашего чарта могут захотеть переопределить их с помощью флага `-f` или опции `--set`.\n\nПоскольку `--set` более ограничен в выразительности, первое правило при написании файла `values.yaml` — _упростите переопределение через `--set`_.\n\nПо этой причине часто лучше структурировать файл values с помощью словарей (maps).\n\nСложно использовать с `--set`:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nПриведённую выше структуру невозможно выразить с помощью `--set` в Helm `<=2.4`. В Helm 2.5 обращение к порту foo выглядит как `--set servers[0].port=80`. Это не только сложнее для понимания пользователем, но и подвержено ошибкам, если впоследствии порядок `servers` изменится.\n\nУдобно использовать:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nОбращение к порту foo гораздо очевиднее: `--set servers.foo.port=80`.\n\n## Документируйте `values.yaml`\n\nКаждое определённое свойство в `values.yaml` должно быть задокументировано. Строка документации должна начинаться с имени свойства, которое она описывает, и содержать как минимум одно предложение с описанием.\n\nНеправильно:\n\n```yaml\n# имя хоста для веб-сервера\nserverHost: example\nserverPort: 9191\n```\n\nПравильно:\n\n```yaml\n# serverHost — имя хоста для веб-сервера\nserverHost: example\n# serverPort — порт HTTP-слушателя для веб-сервера\nserverPort: 9191\n```\n\nНачало каждого комментария с имени параметра, который он документирует, упрощает поиск документации с помощью grep и позволяет инструментам документирования надёжно сопоставлять строки документации с описываемыми параметрами.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Доступ к файлам внутри шаблонов\ndescription: Как получить доступ к файлам из шаблона.\nsidebar_position: 10\n---\n\nВ предыдущем разделе мы рассмотрели несколько способов создания и использования именованных шаблонов. Это упрощает импорт одного шаблона из другого. Однако иногда необходимо импортировать _файл, который не является шаблоном_, и вставить его содержимое без обработки движком шаблонов.\n\nHelm предоставляет доступ к файлам через объект `.Files`. Прежде чем мы перейдём к примерам шаблонов, следует учесть несколько особенностей работы этого механизма:\n\n- В чарт Helm можно добавлять дополнительные файлы. Эти файлы будут включены в пакет чарта. Однако будьте осторожны: из-за ограничений на размер объектов Kubernetes чарты должны быть меньше 1 МБ.\n- Некоторые файлы недоступны через объект `.Files`, как правило, по соображениям безопасности:\n  - Файлы в директории `templates/` недоступны.\n  - Файлы, исключённые с помощью `.helmignore`, недоступны.\n  - Файлы, находящиеся за пределами приложения Helm — [субчарта](/chart_template_guide/subcharts_and_globals.md), включая файлы родительского чарта, недоступны.\n- Чарты не сохраняют информацию о правах доступа UNIX, поэтому права на уровне файлов не влияют на доступность файла через объект `.Files`.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Базовый пример](#базовый-пример)\n- [Вспомогательные функции для путей](#вспомогательные-функции-для-путей)\n- [Glob-паттерны](#glob-паттерны)\n- [Вспомогательные функции для ConfigMap и Secret](#вспомогательные-функции-для-configmap-и-secret)\n- [Кодирование](#кодирование)\n- [Строки](#строки)\n\n<!-- tocstop -->\n\n## Базовый пример\n\nУчитывая вышеописанные ограничения, давайте напишем шаблон, который читает три файла и помещает их в ConfigMap. Для начала добавим три файла в чарт, разместив их непосредственно в директории `mychart/`.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nКаждый из этих файлов представляет собой простой TOML-файл (напоминает старые INI-файлы Windows). Мы знаем имена этих файлов, поэтому можем использовать функцию `range` для перебора и вставки их содержимого в ConfigMap.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nВ этом ConfigMap используются несколько техник, рассмотренных в предыдущих разделах. Например, мы создаём переменную `$files` для хранения ссылки на объект `.Files`. Также мы используем функцию `tuple` для создания списка файлов, по которому выполняем перебор. Затем выводим имя каждого файла (`{{ . }}: |-`), а за ним — содержимое файла `{{ $files.Get . }}`.\n\nВыполнение этого шаблона создаст один ConfigMap с содержимым всех трёх файлов:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Вспомогательные функции для путей\n\nПри работе с файлами часто бывает полезно выполнять стандартные операции над путями. Для этого Helm импортирует многие функции из пакета Go [path](https://golang.org/pkg/path/). Все они доступны с теми же именами, что и в Go, но с первой буквой в нижнем регистре. Например, `Base` становится `base` и так далее.\n\nИмпортированные функции:\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Glob-паттерны\n\nПо мере роста вашего чарта может возникнуть потребность в лучшей организации файлов. Для этого мы предоставляем метод `Files.Glob(pattern string)`, который помогает извлекать определённые файлы с гибкостью [glob-паттернов](https://godoc.org/github.com/gobwas/glob).\n\n`.Glob` возвращает объект типа `Files`, поэтому вы можете вызывать любые методы `Files` на возвращённом объекте.\n\nНапример, представим следующую структуру директорий:\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nС glob-паттернами у вас есть несколько вариантов:\n\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nИли\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## Вспомогательные функции для ConfigMap и Secret\n\n(Доступно начиная с Helm 2.0.2)\n\nОчень часто возникает необходимость помещать содержимое файлов в ConfigMap и Secret для монтирования в Pod'ы во время выполнения. Для этого мы предоставляем несколько вспомогательных методов для типа `Files`.\n\nДля лучшей организации особенно полезно использовать эти методы совместно с методом `Glob`.\n\nИспользуя структуру директорий из примера [Glob-паттернов](#glob-паттерны):\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Кодирование\n\nВы можете импортировать файл и закодировать его в base64 в шаблоне для обеспечения успешной передачи:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nЭтот пример возьмёт тот же файл `config1.toml`, который мы использовали ранее, и закодирует его:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Строки\n\nИногда бывает необходимо получить доступ к каждой строке файла в шаблоне. Для этого мы предоставляем удобный метод `Lines`.\n\nВы можете выполнить перебор строк с помощью функции `range`:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nНевозможно передать файлы извне чарта во время выполнения `helm install`. Поэтому, если вы хотите, чтобы пользователи предоставили данные, их необходимо загрузить с помощью `helm install -f` или `helm install --set`.\n\nНа этом мы завершаем изучение инструментов и техник написания шаблонов Helm. В следующем разделе мы рассмотрим, как использовать специальный файл `templates/NOTES.txt` для отправки инструкций по завершении установки пользователям вашего чарта.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Встроенные объекты\ndescription: Встроенные объекты, доступные в шаблонах.\nsidebar_position: 3\n---\n\nОбъекты передаются в шаблон движком шаблонов. Ваш код может передавать объекты дальше (мы увидим примеры при рассмотрении операторов `with` и `range`). Существует даже несколько способов создания новых объектов внутри шаблонов, например, с помощью функции `tuple`, которую мы рассмотрим позже.\n\nОбъекты могут быть простыми и содержать только одно значение. Или они могут содержать другие объекты или функции. Например, объект `Release` содержит несколько объектов (таких как `Release.Name`), а объект `Files` имеет несколько функций.\n\nВ предыдущем разделе мы использовали `{{ .Release.Name }}` для вставки имени релиза в шаблон. `Release` — это один из объектов верхнего уровня, к которым вы можете обращаться в своих шаблонах.\n\n- `Release`: Этот объект описывает сам релиз. Он содержит несколько объектов:\n  - `Release.Name`: Имя релиза\n  - `Release.Namespace`: Пространство имён, в которое будет выполнен релиз (если манифест не переопределяет его)\n  - `Release.IsUpgrade`: Устанавливается в `true`, если текущая операция — обновление или откат.\n  - `Release.IsInstall`: Устанавливается в `true`, если текущая операция — установка.\n  - `Release.Revision`: Номер ревизии для этого релиза. При установке равен 1 и увеличивается с каждым обновлением и откатом.\n  - `Release.Service`: Сервис, который выполняет рендеринг текущего шаблона. В Helm это всегда `Helm`.\n- `Values`: Значения, переданные в шаблон из файла `values.yaml` и из пользовательских файлов. По умолчанию `Values` пуст.\n- `Chart`: Содержимое файла `Chart.yaml`. Любые данные из `Chart.yaml` будут доступны здесь. Например, `{{ .Chart.Name }}-{{ .Chart.Version }}` выведет `mychart-0.1.0`.\n  - Доступные поля перечислены в [Руководстве по чартам](/topics/charts.md#the-chartyaml-file)\n- `Subcharts`: Обеспечивает доступ к области видимости (.Values, .Charts, .Releases и т.д.) субчартов из родительского чарта. Например, `.Subcharts.mySubChart.myValue` для доступа к `myValue` в чарте `mySubChart`.\n- `Files`: Обеспечивает доступ ко всем неспециальным файлам в чарте. Хотя вы не можете использовать его для доступа к шаблонам, вы можете использовать его для доступа к другим файлам в чарте. Подробнее см. в разделе [Доступ к файлам](/chart_template_guide/accessing_files.md).\n  - `Files.Get` — функция для получения файла по имени (`.Files.Get config.ini`)\n  - `Files.GetBytes` — функция для получения содержимого файла в виде массива байтов вместо строки. Это полезно для таких вещей, как изображения.\n  - `Files.Glob` — функция, возвращающая список файлов, имена которых соответствуют заданному шаблону glob.\n  - `Files.Lines` — функция для построчного чтения файла. Полезна для перебора каждой строки в файле.\n  - `Files.AsSecrets` — функция, возвращающая содержимое файлов в виде строк, закодированных в Base 64.\n  - `Files.AsConfig` — функция, возвращающая содержимое файлов в виде YAML-карты.\n- `Capabilities`: Предоставляет информацию о возможностях, которые поддерживает кластер Kubernetes.\n  - `Capabilities.APIVersions` — набор версий.\n  - `Capabilities.APIVersions.Has $version` — указывает, доступна ли в кластере версия (например, `batch/v1`) или ресурс (например, `apps/v1/Deployment`).\n  - `Capabilities.KubeVersion` и `Capabilities.KubeVersion.Version` — версия Kubernetes.\n  - `Capabilities.KubeVersion.Major` — мажорная версия Kubernetes.\n  - `Capabilities.KubeVersion.Minor` — минорная версия Kubernetes.\n  - `Capabilities.HelmVersion` — объект, содержащий информацию о версии Helm; это тот же вывод, что и у `helm version`.\n  - `Capabilities.HelmVersion.Version` — текущая версия Helm в формате semver.\n  - `Capabilities.HelmVersion.GitCommit` — git sha1 Helm.\n  - `Capabilities.HelmVersion.GitTreeState` — состояние git-дерева Helm.\n  - `Capabilities.HelmVersion.GoVersion` — версия использованного компилятора Go.\n- `Template`: Содержит информацию о текущем выполняемом шаблоне\n  - `Template.Name`: Путь к текущему шаблону с указанием пространства имён (например, `mychart/templates/mytemplate.yaml`)\n  - `Template.BasePath`: Путь к директории templates текущего чарта с указанием пространства имён (например, `mychart/templates`).\n\nИмена встроенных значений всегда начинаются с заглавной буквы. Это соответствует соглашению об именовании Go. При создании собственных имён вы можете использовать любое соглашение, которое подходит вашей команде. Некоторые команды, в том числе многие авторы чартов на [Artifact Hub](https://artifacthub.io/packages/search?kind=0), предпочитают использовать только строчные буквы в начале имён, чтобы отличать локальные имена от встроенных. В этом руководстве мы следуем этому соглашению.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Управление потоком выполнения\ndescription: Краткий обзор управляющих структур в шаблонах.\nsidebar_position: 7\n---\n\nУправляющие структуры (называемые в терминологии шаблонов «действиями») позволяют вам, как автору шаблона, управлять генерацией шаблона. Язык шаблонов Helm предоставляет следующие управляющие структуры:\n\n- `if`/`else` для создания условных блоков\n- `with` для указания области видимости\n- `range` для организации цикла в стиле «для каждого»\n\nКроме того, язык предоставляет несколько действий для объявления и использования именованных фрагментов шаблонов:\n\n- `define` объявляет новый именованный шаблон внутри вашего шаблона\n- `template` импортирует именованный шаблон\n- `block` объявляет особый вид заполняемой области шаблона\n\nВ этом разделе мы рассмотрим `if`, `with` и `range`. Остальные описаны в разделе «Именованные шаблоны» далее в этом руководстве.\n\n## If/Else\n\nПервая управляющая структура предназначена для условного включения блоков текста в шаблон. Это блок `if`/`else`.\n\nБазовая структура условия выглядит следующим образом:\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\nОбратите внимание: речь идёт о _конвейерах_, а не просто о значениях. Это подчёркивает, что управляющие структуры могут выполнять целый конвейер, а не только вычислять одно значение.\n\nКонвейер вычисляется как _false_, если значение:\n\n- булево false\n- числовой ноль\n- пустая строка\n- `nil` (пустое или null)\n- пустая коллекция (`map`, `slice`, `tuple`, `dict`, `array`)\n\nВо всех остальных случаях условие истинно.\n\nДобавим простое условие в наш ConfigMap. Мы добавим ещё одну настройку, если напиток установлен как coffee:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nПоскольку в предыдущем примере мы закомментировали `drink: coffee`, в выводе не будет флага `mug: \"true\"`. Но если добавить эту строку обратно в файл `values.yaml`, вывод будет выглядеть так:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Управление пробелами\n\nРассматривая условия, стоит кратко остановиться на управлении пробелами в шаблонах. Возьмём предыдущий пример и отформатируем его для удобства чтения:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nНа первый взгляд всё хорошо. Но если пропустить его через движок шаблонов, получим неожиданный результат:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nЧто произошло? Мы сгенерировали некорректный YAML из-за пробелов.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` имеет неправильный отступ. Уберём лишний отступ в этой строке и запустим снова:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nТеперь YAML корректен, но выглядит несколько странно:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nВ YAML появились пустые строки. Почему? Движок шаблонов _удаляет_ содержимое внутри `{{` и `}}`, но оставляет окружающие пробелы без изменений.\n\nВ YAML пробелы имеют значение, поэтому управление ими становится важным. К счастью, в шаблонах Helm есть несколько инструментов для этого.\n\nВо-первых, синтаксис фигурных скобок можно модифицировать специальными символами, чтобы указать движку обрезать пробелы. `{{- ` (с дефисом и пробелом) означает, что пробелы слева должны быть обрезаны, а ` -}}` — что пробелы справа должны быть обрезаны. _Будьте внимательны! Переводы строк тоже считаются пробелами!_\n\n> Убедитесь, что между `-` и остальной частью директивы есть пробел.\n> `{{- 3 }}` означает «обрезать пробелы слева и вывести 3», тогда как `{{-3 }}` означает «вывести -3».\n\nИспользуя этот синтаксис, мы можем изменить наш шаблон, чтобы избавиться от пустых строк:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nДля наглядности заменим символом `*` каждый пробел, который будет обрезан согласно этому правилу. Символ `*` в конце строки обозначает перевод строки, который будет удалён:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nУчитывая это, запустим наш шаблон через Helm и посмотрим результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nБудьте осторожны с модификаторами обрезки. Легко случайно сделать что-то вроде этого:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nЭто даст `food: \"PIZZA\"mug: \"true\"`, потому что будут обрезаны переводы строк с обеих сторон.\n\n> Подробнее об управлении пробелами в шаблонах см. в [официальной документации Go template](https://godoc.org/text/template).\n\nНаконец, иногда проще указать системе шаблонов, как делать отступы, вместо того чтобы пытаться управлять пробелами вручную. Для этого может быть полезна функция `indent` (`{{ indent 2 \"mug:true\" }}`).\n\n## Изменение области видимости с помощью `with`\n\nСледующая управляющая структура — действие `with`. Оно управляет областью видимости переменных. Напомним, что `.` — это ссылка на _текущую область видимости_. Таким образом, `.Values` указывает шаблону искать объект `Values` в текущей области видимости.\n\nСинтаксис `with` похож на простой оператор `if`:\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\nОбласть видимости можно изменять. `with` позволяет установить текущую область видимости (`.`) на конкретный объект. Например, мы работали с `.Values.favorite`. Перепишем наш ConfigMap, изменив область видимости `.` так, чтобы она указывала на `.Values.favorite`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nОбратите внимание: мы убрали условие `if` из предыдущего примера, поскольку оно больше не нужно — блок после `with` выполняется только если значение `PIPELINE` не пустое.\n\nТеперь мы можем ссылаться на `.drink` и `.food` без полного пути. Это возможно потому, что оператор `with` устанавливает `.` так, чтобы она указывала на `.Values.favorite`. После `{{ end }}` область видимости `.` сбрасывается к предыдущему значению.\n\nНо будьте осторожны! Внутри ограниченной области видимости вы не сможете обращаться к другим объектам из родительской области через `.`. Например, следующий код не сработает:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nЭто вызовет ошибку, потому что `Release.Name` недоступен внутри ограниченной области видимости `.`. Однако если поменять местами две последние строки, всё будет работать корректно, поскольку область видимости сбрасывается после `{{ end }}`:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nТакже можно использовать `$` для доступа к объекту `Release.Name` из родительской области видимости. Переменная `$` указывает на корневую область видимости при начале выполнения шаблона и не изменяется в процессе выполнения. Следующий вариант тоже будет работать:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nПосле рассмотрения `range` мы разберём переменные шаблонов, которые предлагают ещё одно решение описанной выше проблемы с областью видимости.\n\n## Циклы с действием `range`\n\nМногие языки программирования поддерживают циклы с помощью `for`, `foreach` или аналогичных механизмов. В языке шаблонов Helm для итерации по коллекции используется оператор `range`.\n\nДля начала добавим список начинок для пиццы в файл `values.yaml`:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nТеперь у нас есть список (в терминологии шаблонов называемый `slice`) `pizzaToppings`. Мы можем изменить шаблон, чтобы вывести этот список в ConfigMap:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nМы можем использовать `$` для доступа к списку `Values.pizzaToppings` из родительской области видимости. Переменная `$` указывает на корневую область видимости при начале выполнения шаблона и не изменяется в процессе выполнения. Следующий вариант тоже будет работать:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nРассмотрим список `toppings:` подробнее. Функция `range` перебирает (итерирует) список `pizzaToppings`. Здесь происходит кое-что интересное: как и `with`, оператор `range` устанавливает область видимости `.`. На каждой итерации `.` устанавливается на текущий элемент списка. То есть на первой итерации `.` равна `mushrooms`, на второй — `cheese`, и так далее.\n\nМы можем передать значение `.` напрямую в конвейер, поэтому когда мы пишем `{{ . | title | quote }}`, `.` передаётся в `title` (функция преобразования к заглавным буквам), а затем в `quote`. Результат выполнения:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nВ этом примере мы применили один трюк. Строка `toppings: |-` объявляет многострочную строку. Таким образом, наш список начинок на самом деле не является YAML-списком — это одна большая строка. Почему? Потому что данные в ConfigMap `data` состоят из пар ключ/значение, где и ключ, и значение являются простыми строками. Подробнее об этом см. в [документации Kubernetes по ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/). Впрочем, для нас эта деталь не так важна.\n\n> Маркер `|-` в YAML обозначает многострочную строку. Это полезный приём для встраивания больших блоков данных в манифесты, как показано здесь.\n\nИногда бывает удобно быстро создать список прямо в шаблоне и затем перебрать его. В шаблонах Helm есть функция для этого: `tuple`. В информатике кортеж — это коллекция фиксированного размера, похожая на список, но с произвольными типами данных. Примерно так `tuple` используется и здесь.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nРезультат:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nПомимо списков и кортежей, `range` можно использовать для итерации по коллекциям с ключом и значением (таким как `map` или `dict`). Мы рассмотрим это в следующем разделе, когда познакомимся с переменными шаблонов.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Приложение: типы данных Go и шаблоны\"\ndescription: Краткий обзор переменных в шаблонах.\nsidebar_position: 16\n---\n\nЯзык шаблонов Helm реализован на строго типизированном языке программирования Go. По этой причине переменные в шаблонах являются _типизированными_. Как правило, переменные имеют один из следующих типов:\n\n- string: строка текста\n- bool: значение `true` или `false`\n- int: целочисленное значение (существуют также 8-, 16-, 32- и 64-битные варианты со знаком и без знака)\n- float64: 64-битное значение с плавающей точкой (существуют также 8-, 16- и 32-битные варианты)\n- срез байтов (`[]byte`), часто используется для хранения (потенциально) бинарных данных\n- struct: объект со свойствами и методами\n- срез (индексированный список) одного из предыдущих типов\n- словарь со строковыми ключами (`map[string]interface{}`), где значение относится к одному из предыдущих типов\n\nВ Go существует множество других типов, и иногда вам придётся преобразовывать их в шаблонах. Самый простой способ узнать тип объекта — передать его в `printf \"%T\"` внутри шаблона, что выведет тип. Также смотрите функции `typeOf` и `kindOf`.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: Отладка шаблонов\ndescription: Устранение неполадок в чартах, которые не удаётся развернуть.\nsidebar_position: 13\n---\n\nОтладка шаблонов может быть сложной, поскольку обработанные шаблоны отправляются на сервер API Kubernetes, который может отклонить YAML-файлы по причинам, не связанным с форматированием.\n\nНесколько команд помогут вам в отладке:\n\n- `helm lint` — ваш главный инструмент для проверки соответствия чарта лучшим практикам.\n- `helm template --debug` позволяет протестировать рендеринг шаблонов чарта локально.\n- `helm install --dry-run --debug` также рендерит чарт локально без фактической установки, но дополнительно проверяет, не запущены ли уже конфликтующие ресурсы в кластере. При указании `--dry-run=server` также выполняются все функции `lookup` из вашего чарта на сервере.\n- `helm get manifest` — хороший способ увидеть, какие шаблоны установлены на сервере.\n\nКогда YAML не удаётся разобрать, но вы хотите увидеть сгенерированный результат, простой способ получить YAML — закомментировать проблемный участок в шаблоне и повторно выполнить `helm install --dry-run --debug`:\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\nЭтот код будет обработан и возвращён с сохранёнными комментариями:\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\nЭто позволяет быстро просмотреть сгенерированное содержимое, не сталкиваясь с ошибками парсинга YAML.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: Список функций шаблонов\ndescription: Список функций шаблонов, доступных в Helm\nsidebar_position: 6\n---\n\nHelm включает множество функций шаблонов, которые вы можете использовать в шаблонах.\nОни перечислены здесь и разбиты на следующие категории:\n\n* [Криптографические функции и функции безопасности](#криптографические-функции-и-функции-безопасности)\n* [Функции даты](#функции-даты)\n* [Словари](#словари-и-функции-dict)\n* [Функции кодирования](#функции-кодирования)\n* [Функции путей файлов](#функции-путей-файлов)\n* [Функции Kubernetes и Chart](#функции-kubernetes-и-chart)\n* [Логика и управление потоком](#функции-логики-и-управления-потоком)\n* [Списки](#списки-и-функции-list)\n* [Математические функции](#математические-функции)\n* [Математические функции с плавающей точкой](#математические-функции-с-плавающей-точкой)\n* [Сетевые функции](#сетевые-функции)\n* [Функции рефлексии](#функции-рефлексии)\n* [Регулярные выражения](#регулярные-выражения)\n* [Семантические версии](#функции-семантических-версий)\n* [Строковые функции](#строковые-функции)\n* [Функции преобразования типов](#функции-преобразования-типов)\n* [URL-функции](#url-функции)\n* [UUID-функции](#uuid-функции)\n\n## Функции логики и управления потоком\n\nHelm включает множество функций логики и управления потоком, включая [and](#and),\n[coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq),\n[fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne),\n[not](#not), [or](#or) и [required](#required).\n\n### and\n\nВозвращает логическое И двух или более аргументов\n(первый пустой аргумент или последний аргумент).\n\n```\nand .Arg1 .Arg2\n```\n\n### or\n\nВозвращает логическое ИЛИ двух или более аргументов\n(первый непустой аргумент или последний аргумент).\n\n```\nor .Arg1 .Arg2\n```\n\n### not\n\nВозвращает логическое отрицание аргумента.\n\n```\nnot .Arg\n```\n\n### eq\n\nВозвращает логическое равенство аргументов (например, Arg1 == Arg2).\n\n```\neq .Arg1 .Arg2\n```\n\n### ne\n\nВозвращает логическое неравенство аргументов (например, Arg1 != Arg2)\n\n```\nne .Arg1 .Arg2\n```\n\n### lt\n\nВозвращает `true`, если первый аргумент меньше второго. В противном случае\nвозвращается `false` (например, Arg1 < Arg2).\n\n```\nlt .Arg1 .Arg2\n```\n\n### le\n\nВозвращает `true`, если первый аргумент меньше или равен второму.\nВ противном случае возвращается `false` (например, Arg1 <= Arg2).\n\n```\nle .Arg1 .Arg2\n```\n\n### gt\n\nВозвращает `true`, если первый аргумент больше второго. В противном случае\nвозвращается `false` (например, Arg1 > Arg2).\n\n```\ngt .Arg1 .Arg2\n```\n\n### ge\n\nВозвращает `true`, если первый аргумент больше или равен второму.\nВ противном случае возвращается `false` (например, Arg1 >= Arg2).\n\n```\nge .Arg1 .Arg2\n```\n\n### default\n\nЧтобы задать простое значение по умолчанию, используйте `default`:\n\n```\ndefault \"foo\" .Bar\n```\n\nВыше, если `.Bar` имеет непустое значение, оно будет использовано. Если же\nоно пустое, вместо него будет возвращено `foo`.\n\nОпределение «пустого» зависит от типа:\n\n- Числовые: 0\n- Строки: \"\"\n- Списки: `[]`\n- Словари: `{}`\n- Логические: `false`\n- И всегда `nil` (также называемый null)\n\nДля структур определения пустоты не существует, поэтому структура никогда\nне вернёт значение по умолчанию.\n\n### required\n\nУкажите значения, которые должны быть заданы, с помощью `required`:\n\n```\nrequired \"A valid foo is required!\" .Bar\n```\n\nЕсли `.Bar` пустой или не определён (см. [default](#default) о том, как это\nвычисляется), шаблон не будет отрисован и вместо этого будет возвращено\nуказанное сообщение об ошибке.\n\n### empty\n\nФункция `empty` возвращает `true`, если данное значение считается пустым, и\n`false` в противном случае. Пустые значения перечислены в разделе `default`.\n\n```\nempty .Foo\n```\n\nОбратите внимание, что в условных конструкциях шаблонов Go пустота вычисляется\nавтоматически. Поэтому вам редко нужен `if not empty .Foo`. Вместо этого\nиспользуйте просто `if .Foo`.\n\n### fail\n\nБезусловно возвращает пустую строку (`string`) и ошибку (`error`) с указанным\nтекстом. Это полезно в сценариях, когда другие условия определили, что\nотрисовка шаблона должна завершиться неудачей.\n\n```\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\nФункция `coalesce` принимает список значений и возвращает первое непустое\nиз них.\n\n```\ncoalesce 0 1 2\n```\n\nВернёт `1`.\n\nЭта функция полезна для проверки нескольких переменных или значений:\n\n```\ncoalesce .name .parent.name \"Matt\"\n```\n\nВыше сначала проверяется, пусто ли `.name`. Если нет, это значение будет\nвозвращено. Если оно _пустое_, `coalesce` проверит `.parent.name` на пустоту.\nНаконец, если и `.name`, и `.parent.name` пусты, будет возвращено `Matt`.\n\n### ternary\n\nФункция `ternary` принимает два значения и тестовое значение. Если тестовое\nзначение истинно, возвращается первое значение. Если тестовое значение пустое,\nвозвращается второе значение. Это похоже на тернарный оператор в C и других\nязыках программирования.\n\n#### Истинное тестовое значение\n\n```\nternary \"foo\" \"bar\" true\n```\n\nили\n\n```\ntrue | ternary \"foo\" \"bar\"\n```\n\nВыше возвращается `\"foo\"`.\n\n#### Ложное тестовое значение\n\n```\nternary \"foo\" \"bar\" false\n```\n\nили\n\n```\nfalse | ternary \"foo\" \"bar\"\n```\n\nВыше возвращается `\"bar\"`.\n\n## Строковые функции\n\nHelm включает следующие строковые функции: [abbrev](#abbrev),\n[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat),\n[contains](#contains), [hasPrefix](#hasprefix-и-hassuffix),\n[hasSuffix](#hasprefix-и-hassuffix), [indent](#indent), [initials](#initials),\n[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent),\n[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf),\n[println](#println), [quote](#quote-и-squote),\n[randAlpha](#randalphanum-randalpha-randnumeric-и-randascii),\n[randAlphaNum](#randalphanum-randalpha-randnumeric-и-randascii),\n[randAscii](#randalphanum-randalpha-randnumeric-и-randascii),\n[randNumeric](#randalphanum-randalpha-randnumeric-и-randascii),\n[repeat](#repeat), [replace](#replace), [shuffle](#shuffle),\n[snakecase](#snakecase), [squote](#quote-и-squote), [substr](#substr),\n[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall),\n[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc),\n[untitle](#untitle), [upper](#upper), [wrap](#wrap) и [wrapWith](#wrapwith).\n\n### print\n\nВозвращает строку из комбинации своих частей.\n\n```\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\nТипы, не являющиеся строками, преобразуются в строки, где это возможно.\n\nОбратите внимание: когда два соседних аргумента не являются строками, между\nними добавляется пробел.\n\n### println\n\nРаботает так же, как [print](#print), но добавляет новую строку в конце.\n\n### printf\n\nВозвращает строку на основе форматирующей строки и передаваемых ей аргументов\nпо порядку.\n\n```\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\nИспользуемый заполнитель зависит от типа передаваемого аргумента.\nЭто включает:\n\nОбщего назначения:\n\n* `%v` значение в формате по умолчанию\n  * при выводе словарей флаг плюс (%+v) добавляет имена полей\n* `%%` буквальный знак процента; не потребляет значение\n\nЛогические:\n\n* `%t` слово true или false\n\nЦелочисленные:\n\n* `%b` по основанию 2\n* `%c` символ, соответствующий данной кодовой точке Unicode\n* `%d` по основанию 10\n* `%o` по основанию 8\n* `%O` по основанию 8 с префиксом 0o\n* `%q` символьный литерал в одинарных кавычках, безопасно экранированный\n* `%x` по основанию 16 со строчными буквами a-f\n* `%X` по основанию 16 с заглавными буквами A-F\n* `%U` формат Unicode: U+1234; эквивалентно \"U+%04X\"\n\nДля чисел с плавающей точкой и комплексных чисел:\n\n* `%b` десятичная запись без научной нотации с показателем степени, являющимся\n  степенью двойки, например -123456p-78\n* `%e` научная нотация, например -1.234456e+78\n* `%E` научная нотация, например -1.234456E+78\n* `%f` десятичная точка без экспоненты, например 123.456\n* `%F` синоним для %f\n* `%g` %e для больших экспонент, %f в остальных случаях\n* `%G` %E для больших экспонент, %F в остальных случаях\n* `%x` шестнадцатеричная нотация (с десятичной степенью двойки), например\n  -0x1.23abcp+20\n* `%X` шестнадцатеричная нотация в верхнем регистре, например -0X1.23ABCP+20\n\nСтроки и срезы байтов (обрабатываются одинаково с этими спецификаторами):\n\n* `%s` неинтерпретированные байты строки или среза\n* `%q` строка в двойных кавычках, безопасно экранированная\n* `%x` по основанию 16, нижний регистр, два символа на байт\n* `%X` по основанию 16, верхний регистр, два символа на байт\n\nСрезы:\n\n* `%p` адрес 0-го элемента в шестнадцатеричной нотации с ведущим 0x\n\n### trim\n\nФункция `trim` удаляет пробельные символы с обеих сторон строки:\n\n```\ntrim \"   hello    \"\n```\n\nРезультат: `hello`\n\n### trimAll\n\nУдаляет указанные символы с начала и конца строки:\n\n```\ntrimAll \"$\" \"$5.00\"\n```\n\nРезультат: `5.00` (как строка).\n\n### trimPrefix\n\nУдаляет только префикс строки:\n\n```\ntrimPrefix \"-\" \"-hello\"\n```\n\nРезультат: `hello`\n\n### trimSuffix\n\nУдаляет только суффикс строки:\n\n```\ntrimSuffix \"-\" \"hello-\"\n```\n\nРезультат: `hello`\n\n### lower\n\nПреобразует всю строку в нижний регистр:\n\n```\nlower \"HELLO\"\n```\n\nРезультат: `hello`\n\n### upper\n\nПреобразует всю строку в верхний регистр:\n\n```\nupper \"hello\"\n```\n\nРезультат: `HELLO`\n\n### title\n\nПреобразует в заглавный регистр:\n\n```\ntitle \"hello world\"\n```\n\nРезультат: `Hello World`\n\n### untitle\n\nУбирает заглавный регистр. `untitle \"Hello World\"` возвращает `hello world`.\n\n### repeat\n\nПовторяет строку несколько раз:\n\n```\nrepeat 3 \"hello\"\n```\n\nРезультат: `hellohellohello`\n\n### substr\n\nПолучает подстроку из строки. Принимает три параметра:\n\n- start (int)\n- end (int)\n- string (string)\n\n```\nsubstr 0 5 \"hello world\"\n```\n\nРезультат: `hello`\n\n### nospace\n\nУдаляет все пробельные символы из строки.\n\n```\nnospace \"hello w o r l d\"\n```\n\nРезультат: `helloworld`\n\n### trunc\n\nОбрезает строку\n\n```\ntrunc 5 \"hello world\"\n```\n\nРезультат: `hello`.\n\n```\ntrunc -5 \"hello world\"\n```\n\nВыше возвращается `world`.\n\n### abbrev\n\nОбрезает строку с многоточием (`...`)\n\nПараметры:\n\n- максимальная длина\n- строка\n\n```\nabbrev 5 \"hello world\"\n```\n\nВыше возвращается `he...`, так как ширина многоточия учитывается в\nмаксимальной длине.\n\n### abbrevboth\n\nСокращает с обеих сторон:\n\n```\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\nВыше возвращается `...5678...`\n\nПринимает:\n\n- смещение слева\n- максимальную длину\n- строку\n\n### initials\n\nПри наличии нескольких слов берёт первую букву каждого слова и объединяет.\n\n```\ninitials \"First Try\"\n```\n\nРезультат: `FT`\n\n### randAlphaNum, randAlpha, randNumeric и randAscii\n\nЭти четыре функции генерируют криптографически безопасные (используют\n```crypto/rand```) случайные строки с разными базовыми наборами символов:\n\n- `randAlphaNum` использует `0-9a-zA-Z`\n- `randAlpha` использует `a-zA-Z`\n- `randNumeric` использует `0-9`\n- `randAscii` использует все печатные ASCII-символы\n\nКаждая из них принимает один параметр: целочисленную длину строки.\n\n```\nrandNumeric 3\n```\n\nВыше возвращается случайная строка из трёх цифр.\n\n### wrap\n\nПереносит текст на заданное количество столбцов:\n\n```\nwrap 80 $someText\n```\n\nВыше переносит строку в `$someText` на 80 столбцах.\n\n### wrapWith\n\n`wrapWith` работает как `wrap`, но позволяет указать строку для переноса.\n(`wrap` использует `\\n`)\n\n```\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\nРезультат: `Hello World` (где пробельный символ — это ASCII-символ\nтабуляции)\n\n### contains\n\nПроверяет, содержится ли одна строка внутри другой:\n\n```\ncontains \"cat\" \"catch\"\n```\n\nРезультат: `true`, потому что `catch` содержит `cat`.\n\n### hasPrefix и hasSuffix\n\nФункции `hasPrefix` и `hasSuffix` проверяют, имеет ли строка заданный\nпрефикс или суффикс:\n\n```\nhasPrefix \"cat\" \"catch\"\n```\n\nРезультат: `true`, потому что `catch` имеет префикс `cat`.\n\n### quote и squote\n\nЭти функции оборачивают строку в двойные кавычки (`quote`) или одинарные\nкавычки (`squote`).\n\n### cat\n\nФункция `cat` объединяет несколько строк в одну, разделяя их пробелами:\n\n```\ncat \"hello\" \"beautiful\" \"world\"\n```\n\nРезультат: `hello beautiful world`\n\n### indent\n\nФункция `indent` добавляет отступ к каждой строке заданной строки на\nуказанную ширину отступа. Это полезно при выравнивании многострочных строк:\n\n```\nindent 4 $lots_of_text\n```\n\nВыше добавляет отступ в 4 пробела к каждой строке текста.\n\n### nindent\n\nФункция `nindent` аналогична функции indent, но добавляет новую строку\nв начало.\n\n```\nnindent 4 $lots_of_text\n```\n\nВыше добавляет отступ в 4 пробела к каждой строке текста и добавляет новую\nстроку в начало.\n\n### replace\n\nВыполняет простую замену строки.\n\nПринимает три аргумента:\n\n- строку для замены\n- строку для замены ею\n- исходную строку\n\n```\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\nРезультат: `I-Am-Henry-VIII`\n\n### plural\n\nСклоняет строку.\n\n```\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\nВыше, если длина строки равна 1, будет выведен первый аргумент (`one anchovy`).\nВ противном случае будет выведен второй аргумент (`many anchovies`).\n\nАргументы:\n\n- строка единственного числа\n- строка множественного числа\n- целое число длины\n\nПРИМЕЧАНИЕ: Helm в настоящее время не поддерживает языки с более сложными\nправилами склонения. И `0` считается множественным числом, потому что\nанглийский язык обрабатывает его таким образом (`zero anchovies`).\n\n### snakecase\n\nПреобразует строку из camelCase в snake_case.\n\n```\nsnakecase \"FirstName\"\n```\n\nРезультат: `first_name`.\n\n### camelcase\n\nПреобразует строку из snake_case в CamelCase\n\n```\ncamelcase \"http_server\"\n```\n\nРезультат: `HttpServer`.\n\n### kebabcase\n\nПреобразует строку из camelCase в kebab-case.\n\n```\nkebabcase \"FirstName\"\n```\n\nРезультат: `first-name`.\n\n### swapcase\n\nМеняет регистр строки с использованием алгоритма на основе слов.\n\nАлгоритм преобразования:\n\n- Символ верхнего регистра преобразуется в нижний регистр\n- Символ титульного регистра преобразуется в нижний регистр\n- Символ нижнего регистра после пробела или в начале преобразуется в\n  титульный регистр\n- Другие символы нижнего регистра преобразуются в верхний регистр\n- Пробел определяется функцией unicode.IsSpace(char)\n\n```\nswapcase \"This Is A.Test\"\n```\n\nРезультат: `tHIS iS a.tEST`.\n\n### shuffle\n\nПеремешивает строку.\n\n```\nshuffle \"hello\"\n```\n\nВыше перемешает буквы в `hello`, возможно возвращая `oelhl`.\n\n## Функции преобразования типов\n\nHelm предоставляет следующие функции преобразования типов:\n\n- `atoi`: Преобразует строку в целое число.\n- `float64`: Преобразует в `float64`.\n- `int`: Преобразует в `int` системной разрядности.\n- `int64`: Преобразует в `int64`.\n- `toDecimal`: Преобразует восьмеричное число unix в `int64`.\n- `toString`: Преобразует в строку.\n- `toStrings`: Преобразует список, срез или массив в список строк.\n- `toJson` (`mustToJson`): Преобразует список, срез, массив, словарь или\n  объект в JSON.\n- `toPrettyJson` (`mustToPrettyJson`): Преобразует список, срез, массив,\n  словарь или объект в форматированный JSON с отступами.\n- `toRawJson` (`mustToRawJson`): Преобразует список, срез, массив, словарь\n  или объект в JSON с неэкранированными HTML-символами.\n- `fromYaml`: Преобразует YAML-строку в объект.\n- `fromJson`: Преобразует JSON-строку в объект.\n- `fromJsonArray`: Преобразует JSON-массив в список.\n- `toYaml`: Преобразует список, срез, массив, словарь или объект в\n  форматированный yaml, может использоваться для копирования фрагментов yaml\n  из любого источника. Эта функция эквивалентна функции GoLang yaml.Marshal,\n  см. документацию: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal\n- `toYamlPretty`: Преобразует список, срез, массив, словарь или объект в\n  форматированный yaml. Эквивалентно `toYaml`, но дополнительно добавляет\n  отступ в 2 пробела для списков.\n- `toToml`: Преобразует список, срез, массив, словарь или объект в toml,\n  может использоваться для копирования фрагментов toml из любого источника.\n- `fromYamlArray`: Преобразует YAML-массив в список.\n\nТолько `atoi` требует, чтобы входные данные были определённого типа. Остальные\nпопытаются преобразовать любой тип в целевой. Например, `int64` может\nпреобразовывать числа с плавающей точкой в целые числа, а также строки в\nцелые числа.\n\n### toStrings\n\nПри наличии коллекции, похожей на список, возвращает срез строк.\n\n```\nlist 1 2 3 | toStrings\n```\n\nВыше преобразует `1` в `\"1\"`, `2` в `\"2\"` и так далее, а затем возвращает их\nкак список.\n\n### toDecimal\n\nПри наличии восьмеричного разрешения unix возвращает десятичное число.\n\n```\n\"0777\" | toDecimal\n```\n\nВыше преобразует `0777` в `511` и возвращает значение как int64.\n\n### toJson, mustToJson\n\nФункция `toJson` кодирует элемент в JSON-строку. Если элемент не может быть\nпреобразован в JSON, функция вернёт пустую строку. `mustToJson` вернёт\nошибку, если элемент не может быть закодирован в JSON.\n\n```\ntoJson .Item\n```\n\nВыше возвращается строковое представление `.Item` в формате JSON.\n\n### toPrettyJson, mustToPrettyJson\n\nФункция `toPrettyJson` кодирует элемент в форматированную (с отступами)\nJSON-строку.\n\n```\ntoPrettyJson .Item\n```\n\nВыше возвращается форматированное строковое представление `.Item` в\nформате JSON.\n\n### toRawJson, mustToRawJson\n\nФункция `toRawJson` кодирует элемент в JSON-строку с неэкранированными\nHTML-символами.\n\n```\ntoRawJson .Item\n```\n\nВыше возвращается неэкранированное строковое представление `.Item` в\nформате JSON.\n\n### fromYaml\n\nФункция `fromYaml` принимает YAML-строку и возвращает объект, который\nможно использовать в шаблонах.\n\n`Файл: yamls/person.yaml`\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n```yaml\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\nФункция `fromJson` принимает JSON-строку и возвращает объект, который\nможно использовать в шаблонах.\n\n`Файл: jsons/person.json`\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n\n### fromJsonArray\n\nФункция `fromJsonArray` принимает JSON-массив и возвращает список, который\nможно использовать в шаблонах.\n\n`Файл: jsons/people.json`\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml, toYamlPretty\n\nФункции `toYaml` и `toYamlPretty` кодируют объект (список, срез, массив,\nсловарь или объект) в форматированную YAML-строку.\n\n> Обратите внимание, что `toYamlPretty` функционально эквивалентна, но выводит\n> YAML с дополнительными отступами для элементов списка\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\nФункция `fromYamlArray` принимает YAML-массив и возвращает список, который\nможно использовать в шаблонах.\n\n`Файл: yamls/people.yml`\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n\n## Регулярные выражения\n\nHelm включает следующие функции регулярных выражений: [regexFind\n(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll\n(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch\n(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll\n(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall),\n[regexReplaceAllLiteral\n(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral),\n[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\nВозвращает true, если входная строка содержит любое совпадение с регулярным\nвыражением.\n\n```\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\nРезультат: `true`\n\n`regexMatch` вызывает панику при возникновении проблемы, а `mustRegexMatch`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n### regexFindAll, mustRegexFindAll\n\nВозвращает срез всех совпадений регулярного выражения во входной строке.\nПоследний параметр n определяет количество возвращаемых подстрок, где -1\nозначает возврат всех совпадений.\n\n```\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\nВыше возвращается `[2 4 6 8]`\n\n`regexFindAll` вызывает панику при возникновении проблемы, а `mustRegexFindAll`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n### regexFind, mustRegexFind\n\nВозвращает первое (самое левое) совпадение регулярного выражения во входной\nстроке.\n\n```\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\nВыше возвращается `d1`\n\n`regexFind` вызывает панику при возникновении проблемы, а `mustRegexFind`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n### regexReplaceAll, mustRegexReplaceAll\n\nВозвращает копию входной строки, заменяя совпадения с регулярным выражением\nстрокой замены. Внутри строки замены знаки $ интерпретируются как в Expand,\nпоэтому, например, $1 представляет текст первого подсовпадения. Первый\nаргумент — `<pattern>`, второй — `<input>`, третий — `<replacement>`.\n\n```\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\nВыше возвращается `-W-xxW-`\n\n`regexReplaceAll` вызывает панику при возникновении проблемы, а\n`mustRegexReplaceAll` возвращает ошибку в движок шаблонов при возникновении\nпроблемы.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\nВозвращает копию входной строки, заменяя совпадения с регулярным выражением\nстрокой замены. Строка замены подставляется напрямую, без использования\nExpand. Первый аргумент — `<pattern>`, второй — `<input>`, третий —\n`<replacement>`.\n\n```\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\nВыше возвращается `-${1}-${1}-`\n\n`regexReplaceAllLiteral` вызывает панику при возникновении проблемы, а\n`mustRegexReplaceAllLiteral` возвращает ошибку в движок шаблонов при\nвозникновении проблемы.\n\n### regexSplit, mustRegexSplit\n\nРазбивает входную строку на подстроки, разделённые выражением, и возвращает\nсрез подстрок между совпадениями выражения. Последний параметр `n` определяет\nколичество возвращаемых подстрок, где `-1` означает возврат всех совпадений.\n\n```\nregexSplit \"z+\" \"pizza\" -1\n```\n\nВыше возвращается `[pi a]`\n\n`regexSplit` вызывает панику при возникновении проблемы, а `mustRegexSplit`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n## Криптографические функции и функции безопасности\n\nHelm предоставляет несколько продвинутых криптографических функций, включая\n[adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert),\n[decryptAES](#decryptaes), [derivePassword](#derivepassword),\n[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey),\n[genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert),\n[htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum) и\n[sha256sum](#sha256sum).\n\n### sha1sum\n\nФункция `sha1sum` получает строку и вычисляет её дайджест SHA1.\n\n```\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\nФункция `sha256sum` получает строку и вычисляет её дайджест SHA256.\n\n```\nsha256sum \"Hello world!\"\n```\n\nВыше вычисляется SHA 256 сумма в «ASCII armored» формате, который безопасен\nдля вывода.\n\n### adler32sum\n\nФункция `adler32sum` получает строку и вычисляет её контрольную сумму\nAdler-32.\n\n```\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\nФункция `htpasswd` принимает `username` и `password` и генерирует\n`bcrypt`-хэш пароля. Результат можно использовать для базовой аутентификации\nна [сервере Apache HTTP](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic).\n\n```\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nОбратите внимание, что хранение пароля непосредственно в шаблоне небезопасно.\n\n### randBytes\n\nФункция randBytes принимает число N и генерирует криптографически безопасную\n(использует crypto/rand) случайную последовательность из N байт.\nПоследовательность возвращается как строка в кодировке base64.\n\n```\nrandBytes 24\n```\n\n### derivePassword\n\nФункция `derivePassword` может использоваться для получения конкретного пароля\nна основе некоторого общего «мастер-пароля» с ограничениями. Алгоритм для этого\n[хорошо описан](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf).\n\n```\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nОбратите внимание, что хранение частей непосредственно в шаблоне считается\nнебезопасным.\n\n### genPrivateKey\n\nФункция `genPrivateKey` генерирует новый закрытый ключ, закодированный в\nблок PEM.\n\nПринимает одно из значений в качестве первого параметра:\n\n- `ecdsa`: Генерирует ключ эллиптической кривой DSA (P256)\n- `dsa`: Генерирует ключ DSA (L2048N256)\n- `rsa`: Генерирует ключ RSA 4096\n\n### buildCustomCert\n\nФункция `buildCustomCert` позволяет настроить сертификат.\n\nПринимает следующие строковые параметры:\n\n- Сертификат в формате PEM, закодированный в base64\n- Закрытый ключ в формате PEM, закодированный в base64\n\nВозвращает объект сертификата со следующими атрибутами:\n\n- `Cert`: Сертификат в кодировке PEM\n- `Key`: Закрытый ключ в кодировке PEM\n\nПример:\n\n```\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\nОбратите внимание, что возвращённый объект можно передать в функцию\n`genSignedCert` для подписания сертификата этим CA.\n\n### genCA\n\nФункция `genCA` генерирует новый самоподписанный центр сертификации x509.\n\nПринимает следующие параметры:\n\n- Common name субъекта (cn)\n- Срок действия сертификата в днях\n\nВозвращает объект со следующими атрибутами:\n\n- `Cert`: Сертификат в кодировке PEM\n- `Key`: Закрытый ключ в кодировке PEM\n\nПример:\n\n```\n$ca := genCA \"foo-ca\" 365\n```\n\nОбратите внимание, что возвращённый объект можно передать в функцию\n`genSignedCert` для подписания сертификата этим CA.\n\n### genSelfSignedCert\n\nФункция `genSelfSignedCert` генерирует новый самоподписанный сертификат x509.\n\nПринимает следующие параметры:\n\n- Common name субъекта (cn)\n- Необязательный список IP-адресов; может быть nil\n- Необязательный список альтернативных DNS-имён; может быть nil\n- Срок действия сертификата в днях\n\nВозвращает объект со следующими атрибутами:\n\n- `Cert`: Сертификат в кодировке PEM\n- `Key`: Закрытый ключ в кодировке PEM\n\nПример:\n\n```\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\nФункция `genSignedCert` генерирует новый сертификат x509, подписанный\nуказанным CA.\n\nПринимает следующие параметры:\n\n- Common name субъекта (cn)\n- Необязательный список IP-адресов; может быть nil\n- Необязательный список альтернативных DNS-имён; может быть nil\n- Срок действия сертификата в днях\n- CA (см. `genCA`)\n\nПример:\n\n```\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\nФункция `encryptAES` шифрует текст с помощью AES-256 CBC и возвращает строку\nв кодировке base64.\n\n```\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\nФункция `decryptAES` получает строку base64, закодированную алгоритмом\nAES-256 CBC, и возвращает расшифрованный текст.\n\n```\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Функции даты\n\nHelm включает следующие функции даты, которые вы можете использовать в\nшаблонах: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify\n(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration),\n[durationRound](#durationround), [htmlDate](#htmldate),\n[htmlDateInZone](#htmldateinzone), [now](#now), [toDate\n(mustToDate)](#todate-musttodate) и [unixEpoch](#unixepoch).\n\n### now\n\nТекущая дата/время. Используйте это в сочетании с другими функциями даты.\n\n### ago\n\nФункция `ago` возвращает продолжительность от текущего времени с разрешением\nв секундах.\n\n```\nago .CreatedAt\n```\n\nвозвращает в формате `time.Duration` String()\n\n```\n2h34m7s\n```\n\n### date\n\nФункция `date` форматирует дату.\n\nФорматирует дату в формате ГОД-МЕСЯЦ-ДЕНЬ:\n\n```\nnow | date \"2006-01-02\"\n```\n\nФорматирование даты в Go [немного\nотличается](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\nВкратце, возьмите это как базовую дату:\n\n```\nMon Jan 2 15:04:05 MST 2006\n```\n\nЗапишите её в нужном формате. Выше `2006-01-02` — это та же дата, но в\nнужном нам формате.\n\n### dateInZone\n\nТо же, что и `date`, но с часовым поясом.\n\n```\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\nФорматирует заданное количество секунд как `time.Duration`.\n\nРезультат: 1m35s\n\n```\nduration \"95\"\n```\n\n### durationRound\n\nОкругляет заданную продолжительность до наиболее значимой единицы. Строки и\n`time.Duration` парсятся как продолжительность, а `time.Time` вычисляется\nкак продолжительность с того момента.\n\nРезультат: 2h\n\n```\ndurationRound \"2h10m5s\"\n```\n\nРезультат: 3mo\n\n```\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\nВозвращает количество секунд с начала эпохи unix для `time.Time`.\n\n```\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\n`dateModify` принимает модификацию и дату и возвращает метку времени.\n\nВычесть час и тридцать минут из текущего времени:\n\n```\nnow | dateModify \"-1.5h\"\n```\n\nЕсли формат модификации неверен, `dateModify` вернёт дату без изменений.\n`mustDateModify` вернёт ошибку в противном случае.\n\n### htmlDate\n\nФункция `htmlDate` форматирует дату для вставки в поле ввода выбора даты HTML.\n\n```\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nТо же, что и htmlDate, но с часовым поясом.\n\n```\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\n`toDate` преобразует строку в дату. Первый аргумент — это формат даты,\nвторой — строка даты. Если строка не может быть преобразована, возвращается\nнулевое значение. `mustToDate` вернёт ошибку, если строка не может быть\nпреобразована.\n\nЭто полезно, когда вы хотите преобразовать строковую дату в другой формат\n(используя конвейер). Пример ниже преобразует \"2017-12-31\" в \"31/12/2017\".\n\n```\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Словари и функции Dict\n\nHelm предоставляет тип хранения ключ/значение, называемый `dict` (сокращение\nот «dictionary», как в Python). `dict` — это _неупорядоченный_ тип.\n\nКлючом словаря **должна быть строка**. Однако значением может быть любой\nтип, даже другой `dict` или `list`.\n\nВ отличие от `list`, `dict` не является неизменяемым. Функции `set` и `unset`\nбудут изменять содержимое словаря.\n\nHelm предоставляет следующие функции для работы со словарями: [deepCopy\n(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get),\n[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge),\n[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite),\n[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) и\n[values](#values).\n\n### dict\n\nСоздание словарей выполняется вызовом функции `dict` с передачей списка пар.\n\nСледующее создаёт словарь с тремя элементами:\n\n```\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nПри наличии map и ключа получает значение из map.\n\n```\nget $myDict \"name1\"\n```\n\nВернёт `\"value1\"`\n\nОбратите внимание, что если ключ не найден, операция просто вернёт `\"\"`.\nОшибка не будет сгенерирована.\n\n### set\n\nИспользуйте `set` для добавления новой пары ключ/значение в словарь.\n\n```\n$_ := set $myDict \"name4\" \"value4\"\n```\n\nОбратите внимание, что `set` _возвращает словарь_ (требование функций\nшаблонов Go), поэтому вам может потребоваться перехватить значение, как\nпоказано выше с присваиванием `$_`.\n\n### unset\n\nПри наличии map и ключа удаляет ключ из map.\n\n```\n$_ := unset $myDict \"name4\"\n```\n\nКак и `set`, это возвращает словарь.\n\nОбратите внимание, что если ключ не найден, операция просто вернётся.\nОшибка не будет сгенерирована.\n\n### hasKey\n\nФункция `hasKey` возвращает `true`, если данный словарь содержит данный ключ.\n\n```\nhasKey $myDict \"name1\"\n```\n\nЕсли ключ не найден, возвращается `false`.\n\n### pluck\n\nФункция `pluck` позволяет задать один ключ и несколько map и получить список\nвсех совпадений:\n\n```\npluck \"name1\" $myDict $myOtherDict\n```\n\nВыше вернётся `list`, содержащий каждое найденное значение (`[value1\notherValue1]`).\n\nЕсли данный ключ _не найден_ в map, этот map не будет иметь элемента в списке\n(и длина возвращённого списка будет меньше количества словарей в вызове\n`pluck`).\n\nЕсли ключ _найден_, но значение является пустым, это значение будет вставлено.\n\nРаспространённая идиома в шаблонах Helm — использовать `pluck... | first`\nдля получения первого совпадающего ключа из коллекции словарей.\n\n### dig\n\nФункция `dig` проходит по вложенному набору словарей, выбирая ключи из\nсписка значений. Возвращает значение по умолчанию, если какой-либо из ключей\nне найден в соответствующем словаре.\n\n```\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\nПри наличии словаря со структурой\n```\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\nвыше вернётся `\"curator\"`. Если в словаре отсутствует даже поле `user`,\nрезультатом будет `\"guest\"`.\n\nDig может быть очень полезен в случаях, когда вы хотите избежать защитных\nусловий, особенно учитывая, что `and` в пакете шаблонов Go не использует\nкороткое замыкание. Например, `and a.maybeNil a.maybeNil.iNeedThis` всегда\nбудет вычислять `a.maybeNil.iNeedThis` и вызовет панику, если у `a`\nотсутствует поле `maybeNil`.)\n\n`dig` принимает аргумент словаря последним для поддержки конвейеров.\nНапример:\n```\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\nОбъединяет два или более словарей в один, отдавая приоритет целевому\nсловарю:\n\nПри наличии:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nрезультатом будет:\n\n```\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n```\n$newdict := merge $dest $source1 $source2\n```\n\nЭто операция глубокого объединения, но не глубокого копирования. Вложенные\nобъекты, которые объединяются, являются одним и тем же экземпляром в обоих\nсловарях. Если вы хотите глубокое копирование вместе с объединением,\nиспользуйте функцию `deepCopy` вместе с объединением. Например,\n\n```\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` вернёт ошибку в случае неудачного объединения.\n\n### mergeOverwrite, mustMergeOverwrite\n\nОбъединяет два или более словарей в один, отдавая приоритет **справа налево**,\nфактически перезаписывая значения в целевом словаре:\n\nПри наличии:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nрезультатом будет:\n\n```\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nЭто операция глубокого объединения, но не глубокого копирования. Вложенные\nобъекты, которые объединяются, являются одним и тем же экземпляром в обоих\nсловарях. Если вы хотите глубокое копирование вместе с объединением,\nиспользуйте функцию `deepCopy` вместе с объединением. Например,\n\n```\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` вернёт ошибку в случае неудачного объединения.\n\n### keys\n\nФункция `keys` вернёт `list` всех ключей в одном или нескольких типах\n`dict`. Поскольку словарь _неупорядочен_, ключи не будут в предсказуемом\nпорядке. Их можно отсортировать с помощью `sortAlpha`.\n\n```\nkeys $myDict | sortAlpha\n```\n\nПри передаче нескольких словарей ключи будут объединены. Используйте\nфункцию `uniq` вместе с `sortAlpha` для получения уникального\nотсортированного списка ключей.\n\n```\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\nФункция `pick` выбирает только указанные ключи из словаря, создавая новый\n`dict`.\n\n```\n$new := pick $myDict \"name1\" \"name2\"\n```\n\nВыше возвращается `{name1: value1, name2: value2}`\n\n### omit\n\nФункция `omit` похожа на `pick`, но возвращает новый `dict` со всеми\nключами, которые _не соответствуют_ указанным ключам.\n\n```\n$new := omit $myDict \"name1\" \"name3\"\n```\n\nВыше возвращается `{name2: value2}`\n\n### values\n\nФункция `values` похожа на `keys`, но возвращает новый `list` со всеми\nзначениями исходного `dict` (поддерживается только один словарь).\n\n```\n$vals := values $myDict\n```\n\nВыше возвращается `list[\"value1\", \"value2\", \"value 3\"]`. Обратите внимание,\nчто функция `values` не гарантирует порядок результата; если это важно,\nиспользуйте `sortAlpha`.\n\n### deepCopy, mustDeepCopy\n\nФункции `deepCopy` и `mustDeepCopy` принимают значение и делают его глубокую\nкопию. Это включает словари и другие структуры. `deepCopy` вызывает панику\nпри возникновении проблемы, а `mustDeepCopy` возвращает ошибку в систему\nшаблонов при возникновении ошибки.\n\n```\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### Примечание о внутренней реализации Dict\n\n`dict` реализован в Go как `map[string]interface{}`. Разработчики Go могут\nпередавать значения `map[string]interface{}` в контекст, чтобы сделать их\nдоступными для шаблонов как `dict`.\n\n## Функции кодирования\n\nHelm имеет следующие функции кодирования и декодирования:\n\n- `b64enc`/`b64dec`: Кодирование или декодирование с помощью Base64\n- `b32enc`/`b32dec`: Кодирование или декодирование с помощью Base32\n\n## Списки и функции List\n\nHelm предоставляет простой тип `list`, который может содержать произвольные\nпоследовательные списки данных. Это похоже на массивы или срезы, но списки\nразработаны для использования как неизменяемые типы данных.\n\nСоздание списка целых чисел:\n\n```\n$myList := list 1 2 3 4 5\n```\n\nВыше создаётся список `[1 2 3 4 5]`.\n\nHelm предоставляет следующие функции списков: [append\n(mustAppend)](#append-mustappend), [chunk](#chunk), [compact\n(mustCompact)](#compact-mustcompact), [concat](#concat), [first\n(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial\n(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast),\n[prepend (mustPrepend)](#prepend-mustprepend), [rest\n(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse),\n[seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq\n(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) и\n[without (mustWithout)](#without-mustwithout).\n\n### first, mustFirst\n\nЧтобы получить первый элемент списка, используйте `first`.\n\n`first $myList` возвращает `1`\n\n`first` вызывает панику при возникновении проблемы, а `mustFirst` возвращает\nошибку в движок шаблонов при возникновении проблемы.\n\n### rest, mustRest\n\nЧтобы получить хвост списка (всё, кроме первого элемента), используйте `rest`.\n\n`rest $myList` возвращает `[2 3 4 5]`\n\n`rest` вызывает панику при возникновении проблемы, а `mustRest` возвращает\nошибку в движок шаблонов при возникновении проблемы.\n\n### last, mustLast\n\nЧтобы получить последний элемент списка, используйте `last`:\n\n`last $myList` возвращает `5`. Это примерно аналогично обращению списка и\nпоследующему вызову `first`.\n\n### initial, mustInitial\n\nЭто дополняет `last`, возвращая всё, _кроме_ последнего элемента. `initial\n$myList` возвращает `[1 2 3 4]`.\n\n`initial` вызывает панику при возникновении проблемы, а `mustInitial`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n### append, mustAppend\n\nДобавляет новый элемент в существующий список, создавая новый список.\n\n```\n$new = append $myList 6\n```\n\nВыше установит `$new` в `[1 2 3 4 5 6]`. `$myList` останется неизменным.\n\n`append` вызывает панику при возникновении проблемы, а `mustAppend`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n### prepend, mustPrepend\n\nДобавляет элемент в начало списка, создавая новый список.\n\n```\nprepend $myList 0\n```\n\nВыше вернёт `[0 1 2 3 4 5]`. `$myList` останется неизменным.\n\n`prepend` вызывает панику при возникновении проблемы, а `mustPrepend`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n### concat\n\nОбъединяет произвольное количество списков в один.\n\n```\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\nВыше вернёт `[1 2 3 4 5 6 7 8]`. `$myList` останется неизменным.\n\n### reverse, mustReverse\n\nСоздаёт новый список с обратным порядком элементов данного списка.\n\n```\nreverse $myList\n```\n\nВыше сгенерирует список `[5 4 3 2 1]`.\n\n`reverse` вызывает панику при возникновении проблемы, а `mustReverse`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n### uniq, mustUniq\n\nГенерирует список с удалением всех дубликатов.\n\n```\nlist 1 1 1 2 | uniq\n```\n\nВыше вернёт `[1 2]`\n\n`uniq` вызывает панику при возникновении проблемы, а `mustUniq` возвращает\nошибку в движок шаблонов при возникновении проблемы.\n\n### without, mustWithout\n\nФункция `without` отфильтровывает элементы из списка.\n\n```\nwithout $myList 3\n```\n\nВыше вернёт `[1 2 4 5]`\n\n`without` может принимать более одного фильтра:\n\n```\nwithout $myList 1 3 5\n```\n\nЭто вернёт `[2 4]`\n\n`without` вызывает панику при возникновении проблемы, а `mustWithout`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n### has, mustHas\n\nПроверяет, содержит ли список определённый элемент.\n\n```\nhas 4 $myList\n```\n\nВыше вернёт `true`, тогда как `has \"hello\" $myList` вернёт false.\n\n`has` вызывает панику при возникновении проблемы, а `mustHas` возвращает\nошибку в движок шаблонов при возникновении проблемы.\n\n### compact, mustCompact\n\nПринимает список и удаляет записи с пустыми значениями.\n\n```\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` вернёт новый список с удалённым пустым (т.е. \"\") элементом.\n\n`compact` вызывает панику при возникновении проблемы, а `mustCompact`\nвозвращает ошибку в движок шаблонов при возникновении проблемы.\n\n### index\n\nЧтобы получить n-й элемент списка, используйте `index list [n]`. Для\nиндексации многомерных списков используйте `index list [n] [m] ...`\n- `index $myList 0` возвращает `1`. Это то же самое, что `myList[0]`\n- `index $myList 0 1` было бы эквивалентно `myList[0][1]`\n\n### slice, mustSlice\n\nЧтобы получить частичные элементы списка, используйте `slice list [n] [m]`.\nЭто эквивалентно `list[n:m]`.\n\n- `slice $myList` возвращает `[1 2 3 4 5]`. Это то же самое, что `myList[:]`.\n- `slice $myList 3` возвращает `[4 5]`. Это то же самое, что `myList[3:]`.\n- `slice $myList 1 3` возвращает `[2 3]`. Это то же самое, что `myList[1:3]`.\n- `slice $myList 0 3` возвращает `[1 2 3]`. Это то же самое, что `myList[:3]`.\n\n`slice` вызывает панику при возникновении проблемы, а `mustSlice` возвращает\nошибку в движок шаблонов при возникновении проблемы.\n\n### until\n\nФункция `until` создаёт диапазон целых чисел.\n\n```\nuntil 5\n```\n\nВыше генерируется список `[0, 1, 2, 3, 4]`.\n\nЭто полезно для циклов с `range $i, $e := until 5`.\n\n### untilStep\n\nКак и `until`, `untilStep` генерирует список счётных целых чисел. Но позволяет\nопределить начало, конец и шаг:\n\n```\nuntilStep 3 6 2\n```\n\nВыше вернёт `[3 5]`, начиная с 3 и прибавляя 2, пока значение не станет равным\nили больше 6. Это похоже на функцию `range` в Python.\n\n### seq\n\nРаботает как команда bash `seq`.\n\n* 1 параметр (end) - сгенерирует все счётные целые числа от 1 до `end`\n  включительно.\n* 2 параметра (start, end) - сгенерирует все счётные целые числа от `start`\n  до `end` включительно с шагом 1 или -1.\n* 3 параметра (start, step, end) - сгенерирует все счётные целые числа от\n  `start` до `end` включительно с указанным `step`.\n\n```\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\nЧтобы разбить список на части заданного размера, используйте `chunk size list`.\nЭто полезно для пагинации.\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\nЭто создаёт список списков `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`.\n\n## Математические функции\n\nВсе математические функции работают со значениями `int64`, если не указано\nиное.\n\nДоступны следующие математические функции: [add](#add), [add1](#add1),\n[ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max),\n[min](#min), [mod](#mod), [mul](#mul), [round](#round) и [sub](#sub).\n\n### add\n\nСуммирует числа с помощью `add`. Принимает два или более входных значения.\n\n```\nadd 1 2 3\n```\n\n### add1\n\nЧтобы увеличить на 1, используйте `add1`.\n\n### sub\n\nДля вычитания используйте `sub`.\n\n### div\n\nВыполняет целочисленное деление с помощью `div`.\n\n### mod\n\nОстаток от деления с помощью `mod`.\n\n### mul\n\nУмножает с помощью `mul`. Принимает два или более входных значения.\n\n```\nmul 1 2 3\n```\n\n### max\n\nВозвращает наибольшее из серии целых чисел.\n\nЭто вернёт `3`:\n\n```\nmax 1 2 3\n```\n\n### min\n\nВозвращает наименьшее из серии целых чисел.\n\n`min 1 2 3` вернёт `1`.\n\n### len\n\nВозвращает длину аргумента как целое число.\n\n```\nlen .Arg\n```\n\n## Математические функции с плавающей точкой\n\nВсе математические функции работают со значениями `float64`.\n\n### addf\n\nСуммирует числа с помощью `addf`\n\nЭто вернёт `5.5`:\n\n```\naddf 1.5 2 2\n```\n\n### add1f\n\nЧтобы увеличить на 1, используйте `add1f`\n\n### subf\n\nДля вычитания используйте `subf`\n\nЭто эквивалентно `7.5 - 2 - 3` и вернёт `2.5`:\n\n```\nsubf 7.5 2 3\n```\n\n### divf\n\nВыполняет деление с плавающей точкой с помощью `divf`\n\nЭто эквивалентно `10 / 2 / 4` и вернёт `1.25`:\n\n```\ndivf 10 2 4\n```\n\n### mulf\n\nУмножает с помощью `mulf`\n\nЭто вернёт `6`:\n\n```\nmulf 1.5 2 2\n```\n\n### maxf\n\nВозвращает наибольшее из серии чисел с плавающей точкой:\n\nЭто вернёт `3`:\n\n```\nmaxf 1 2.5 3\n```\n\n### minf\n\nВозвращает наименьшее из серии чисел с плавающей точкой.\n\nЭто вернёт `1.5`:\n\n```\nminf 1.5 2 3\n```\n\n### floor\n\nВозвращает наибольшее значение с плавающей точкой, меньшее или равное\nвходному значению.\n\n`floor 123.9999` вернёт `123.0`.\n\n### ceil\n\nВозвращает наименьшее значение с плавающей точкой, большее или равное\nвходному значению.\n\n`ceil 123.001` вернёт `124.0`.\n\n### round\n\nВозвращает значение с плавающей точкой с остатком, округлённым до указанного\nколичества цифр после десятичной точки.\n\n`round 123.555555 3` вернёт `123.556`.\n\n## Сетевые функции\n\nHelm имеет одну сетевую функцию, `getHostByName`.\n\n`getHostByName` получает доменное имя и возвращает IP-адрес.\n\n`getHostByName \"www.google.com\"` вернёт соответствующий IP-адрес\n`www.google.com`.\n\nЭта функция требует передачи опции `--enable-dns` в командной строке helm.\n\n## Функции путей файлов\n\nХотя функции шаблонов Helm не предоставляют доступа к файловой системе, они\nпредоставляют функции для работы со строками, которые следуют соглашениям\nо путях файлов. К ним относятся [base](#base), [clean](#clean), [dir](#dir),\n[ext](#ext) и [isAbs](#isabs).\n\n### base\n\nВозвращает последний элемент пути.\n\n```\nbase \"foo/bar/baz\"\n```\n\nВыше выводится \"baz\".\n\n### dir\n\nВозвращает директорию, удаляя последнюю часть пути. Так `dir\n\"foo/bar/baz\"` возвращает `foo/bar`.\n\n### clean\n\nОчищает путь.\n\n```\nclean \"foo/bar/../baz\"\n```\n\nВыше разрешается `..` и возвращается `foo/baz`.\n\n### ext\n\nВозвращает расширение файла.\n\n```\next \"foo.bar\"\n```\n\nВыше возвращается `.bar`.\n\n### isAbs\n\nЧтобы проверить, является ли путь файла абсолютным, используйте `isAbs`.\n\n## Функции рефлексии\n\nHelm предоставляет базовые инструменты рефлексии. Они помогают продвинутым\nразработчикам шаблонов понять информацию о базовом типе Go для конкретного\nзначения. Helm написан на Go и является строго типизированным. Система типов\nприменяется внутри шаблонов.\n\nGo имеет несколько примитивных _видов_ (kinds), таких как `string`, `slice`,\n`int64` и `bool`.\n\nGo имеет открытую _систему типов_, которая позволяет разработчикам создавать\nсобственные типы.\n\nHelm предоставляет набор функций для каждого через [функции kind](#функции-kind)\nи [функции type](#функции-type). Также предоставляется функция [deepEqual](#deepequal)\nдля сравнения двух значений.\n\n### Функции Kind\n\nСуществует две функции Kind: `kindOf` возвращает вид объекта.\n\n```\nkindOf \"hello\"\n```\n\nВыше вернёт `string`. Для простых тестов (например, в блоках `if`) функция\n`kindIs` позволит вам проверить, что значение является определённым видом:\n\n```\nkindIs \"int\" 123\n```\n\nВыше вернёт `true`.\n\n### Функции Type\n\nС типами немного сложнее работать, поэтому существует три разные функции:\n\n- `typeOf` возвращает базовый тип значения: `typeOf $foo`\n- `typeIs` похож на `kindIs`, но для типов: `typeIs \"*io.Buffer\" $myVal`\n- `typeIsLike` работает как `typeIs`, но также разыменовывает указатели\n\n**Примечание:** Ни одна из этих функций не может проверить, реализует ли\nчто-то данный интерфейс, так как для этого потребовалось бы скомпилировать\nинтерфейс заранее.\n\n### deepEqual\n\n`deepEqual` возвращает true, если два значения [\"глубоко\nравны\"](https://golang.org/pkg/reflect/#DeepEqual)\n\nРаботает и для непримитивных типов (в отличие от встроенного `eq`).\n\n```\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\nВыше вернёт `true`.\n\n## Функции семантических версий\n\nНекоторые схемы версионирования легко парсятся и сравниваются. Helm\nпредоставляет функции для работы с версиями [SemVer 2](http://semver.org).\nК ним относятся [semver](#semver) и [semverCompare](#semvercompare). Ниже\nвы также найдёте подробности об использовании диапазонов для сравнений.\n\n### semver\n\nФункция `semver` парсит строку в семантическую версию:\n\n```\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_Если парсер завершится с ошибкой, это приведёт к остановке выполнения\nшаблона с ошибкой._\n\nНа этом этапе `$version` является указателем на объект `Version` со следующими\nсвойствами:\n\n- `$version.Major`: Мажорный номер (`1` выше)\n- `$version.Minor`: Минорный номер (`2` выше)\n- `$version.Patch`: Номер патча (`3` выше)\n- `$version.Prerelease`: Пререлиз (`alpha.1` выше)\n- `$version.Metadata`: Метаданные сборки (`123` выше)\n- `$version.Original`: Оригинальная версия как строка\n\nКроме того, вы можете сравнить `Version` с другой `version`, используя\nфункцию `Compare`:\n\n```\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\nВыше вернёт `-1`.\n\nВозвращаемые значения:\n\n- `-1` если данный semver больше, чем semver, метод `Compare` которого\n  был вызван\n- `1` если версия, чья функция `Compare` была вызвана, больше\n- `0` если это одна и та же версия\n\n(Обратите внимание, что в SemVer поле `Metadata` не сравнивается при\nоперациях сравнения версий.)\n\n### semverCompare\n\nБолее надёжная функция сравнения предоставляется как `semverCompare`.\nЭта версия поддерживает диапазоны версий:\n\n- `semverCompare \"1.2.3\" \"1.2.3\"` проверяет на точное совпадение\n- `semverCompare \"~1.2.0\" \"1.2.3\"` проверяет, что мажорная и минорная версии\n  совпадают, и что номер патча второго параметра _больше или равен_ первому\n  параметру.\n\nФункции SemVer используют [библиотеку semver от\nMasterminds](https://github.com/Masterminds/semver), от создателей Sprig.\n\n### Базовые сравнения\n\nВ сравнениях есть два элемента. Во-первых, строка сравнения — это список\nсравнений И, разделённых пробелами или запятыми. Затем они разделяются\n|| (ИЛИ). Например, `\">= 1.2 < 3.0.0 || >= 4.2.3\"` ищет сравнение, которое\nбольше или равно 1.2 и меньше 3.0.0 или больше или равно 4.2.3.\n\nБазовые сравнения:\n\n- `=`: равно (синоним отсутствия оператора)\n- `!=`: не равно\n- `>`: больше чем\n- `<`: меньше чем\n- `>=`: больше или равно\n- `<=`: меньше или равно\n\n### Работа с пререлизными версиями\n\nПререлизы, для тех, кто не знаком с ними, используются для релизов\nпрограммного обеспечения до стабильного или общедоступного релиза.\nПримерами пререлизов являются релизы development, alpha, beta и release\ncandidate. Пререлиз может быть версией, такой как `1.2.3-beta.1`, тогда как\nстабильный релиз будет `1.2.3`. В порядке приоритета пререлизы идут перед\nсвязанными с ними релизами. В этом примере `1.2.3-beta.1 < 1.2.3`.\n\nСогласно спецификации семантического версионирования, пререлизы могут не\nбыть API-совместимыми со своим релизным аналогом. Она гласит:\n\n> Пререлизная версия указывает, что версия нестабильна и может не\n> удовлетворять предполагаемым требованиям совместимости, обозначенным её\n> соответствующей нормальной версией.\n\nСравнения SemVer с использованием ограничений без компаратора пререлиза\nбудут пропускать пререлизные версии. Например, `>=1.2.3` пропустит\nпререлизы при просмотре списка релизов, тогда как `>=1.2.3-0` оценит и\nнайдёт пререлизы.\n\nПричина `0` в качестве пререлизной версии в примере сравнения в том, что\nпререлизы могут содержать только ASCII буквенно-цифровые символы и дефисы\n(вместе с разделителями `.`), согласно спецификации. Сортировка происходит\nв порядке ASCII, снова согласно спецификации. Наименьший символ — `0` в\nпорядке сортировки ASCII (см. [таблицу\nASCII](http://www.asciitable.com/))\n\nПонимание порядка сортировки ASCII важно, потому что A-Z идёт перед a-z.\nЭто означает, что `>=1.2.3-BETA` вернёт `1.2.3-alpha`. То, что вы могли бы\nожидать от чувствительности к регистру, здесь не применяется. Это связано с\nпорядком сортировки ASCII, который указан в спецификации.\n\n### Сравнения с диапазонами через дефис\n\nСуществует несколько методов работы с диапазонами, и первый — это диапазоны\nчерез дефис. Они выглядят так:\n\n- `1.2 - 1.4.5` что эквивалентно `>= 1.2 <= 1.4.5`\n- `2.3.4 - 4.5` что эквивалентно `>= 2.3.4 <= 4.5`\n\n### Подстановочные знаки в сравнениях\n\nСимволы `x`, `X` и `*` могут использоваться как подстановочный знак. Это\nработает для всех операторов сравнения. При использовании с оператором `=`\nон возвращается к сравнению на уровне патча (см. тильду ниже). Например,\n\n- `1.2.x` эквивалентно `>= 1.2.0, < 1.3.0`\n- `>= 1.2.x` эквивалентно `>= 1.2.0`\n- `<= 2.x` эквивалентно `< 3`\n- `*` эквивалентно `>= 0.0.0`\n\n### Сравнения с диапазоном тильды (Patch)\n\nОператор сравнения тильда (`~`) предназначен для диапазонов на уровне патча,\nкогда указана минорная версия, и изменений на уровне мажорной версии, когда\nминорный номер отсутствует. Например,\n\n- `~1.2.3` эквивалентно `>= 1.2.3, < 1.3.0`\n- `~1` эквивалентно `>= 1, < 2`\n- `~2.3` эквивалентно `>= 2.3, < 2.4`\n- `~1.2.x` эквивалентно `>= 1.2.0, < 1.3.0`\n- `~1.x` эквивалентно `>= 1, < 2`\n\n### Сравнения с диапазоном каретки (Major)\n\nОператор сравнения каретка (`^`) предназначен для изменений на уровне\nмажорной версии после выхода стабильного релиза (1.0.0). До релиза 1.0.0\nминорные версии действуют как уровень стабильности API. Это полезно при\nсравнении версий API, так как мажорное изменение ломает API. Например,\n\n- `^1.2.3` эквивалентно `>= 1.2.3, < 2.0.0`\n- `^1.2.x` эквивалентно `>= 1.2.0, < 2.0.0`\n- `^2.3` эквивалентно `>= 2.3, < 3`\n- `^2.x` эквивалентно `>= 2.0.0, < 3`\n- `^0.2.3` эквивалентно `>=0.2.3 <0.3.0`\n- `^0.2` эквивалентно `>=0.2.0 <0.3.0`\n- `^0.0.3` эквивалентно `>=0.0.3 <0.0.4`\n- `^0.0` эквивалентно `>=0.0.0 <0.1.0`\n- `^0` эквивалентно `>=0.0.0 <1.0.0`\n\n## URL-функции\n\nHelm включает функции [urlParse](#urlparse), [urlJoin](#urljoin) и\n[urlquery](#urlquery), позволяющие работать с частями URL.\n\n### urlParse\n\nПарсит строку для URL и возвращает словарь с частями URL\n\n```\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\nВыше возвращается словарь, содержащий объект URL:\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nЭто реализовано с использованием пакетов URL из стандартной библиотеки Go.\nДля дополнительной информации см. https://golang.org/pkg/net/url/#URL\n\n### urlJoin\n\nОбъединяет map (созданный `urlParse`) для создания строки URL\n\n```\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\nВыше возвращается следующая строка:\n```\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nВозвращает экранированную версию переданного значения, чтобы его можно было\nбезопасно встроить в запросную часть URL.\n\n```\n$var := urlquery \"string for query\"\n```\n\n## UUID-функции\n\nHelm может генерировать универсально уникальные идентификаторы UUID v4.\n\n```\nuuidv4\n```\n\nВыше возвращается новый UUID типа v4 (случайно сгенерированный).\n\n## Функции Kubernetes и Chart\n\nHelm включает функции для работы с Kubernetes, включая\n[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas),\n[Files](#функции-files) и [lookup](#lookup).\n\n### lookup\n\n`lookup` используется для поиска ресурса в работающем кластере. При\nиспользовании с командой `helm template` всегда возвращается пустой ответ.\n\nВы можете найти более подробную информацию в [документации по функции\nlookup](./functions_and_pipelines.md#использование-функции-lookup).\n\n### .Capabilities.APIVersions.Has\n\nВозвращает, доступна ли версия API или ресурс в кластере.\n\n```\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\nДополнительная информация доступна в [документации по встроенным\nобъектам](./builtin_objects.md).\n\n### Функции Files\n\nСуществует несколько функций, которые позволяют получить доступ к\nнеспециальным файлам внутри chart. Например, для доступа к файлам\nконфигурации приложения. Они документированы в [Доступ к файлам внутри\nшаблонов](./accessing_files.md).\n\n_Примечание: документация для многих из этих функций взята из\n[Sprig](https://github.com/Masterminds/sprig). Sprig — это библиотека\nфункций шаблонов, доступная для приложений Go._\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: Функции шаблонов и конвейеры\ndescription: Использование функций в шаблонах.\nsidebar_position: 5\n---\n\nДо сих пор мы рассматривали, как размещать информацию в шаблоне. Но эта\nинформация вставляется в шаблон без изменений. Иногда нам нужно\nпреобразовать полученные данные, чтобы сделать их более полезными.\n\nНачнём с рекомендации: при вставке строк из объекта `.Values`\nв шаблон следует заключать эти строки в кавычки. Для этого можно\nвызвать функцию `quote` в директиве шаблона:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nФункции шаблона имеют синтаксис `functionName arg1 arg2...`. В приведённом выше\nпримере `quote .Values.favorite.drink` вызывает функцию `quote` и передаёт ей\nодин аргумент.\n\nВ Helm доступно более 60 функций. Некоторые из них определены в самом [языке\nшаблонов Go](https://godoc.org/text/template). Большинство остальных являются\nчастью [библиотеки шаблонов Sprig](https://masterminds.github.io/sprig/).\nМы рассмотрим многие из них по мере изучения примеров.\n\n> Хотя мы говорим о «языке шаблонов Helm» как о чём-то специфичном для Helm, на\n> самом деле это комбинация языка шаблонов Go, некоторых дополнительных функций\n> и различных обёрток для предоставления определённых объектов шаблонам. Многие\n> ресурсы по шаблонам Go могут быть полезны при изучении шаблонизации.\n\n## Конвейеры\n\nОдной из мощных возможностей языка шаблонов является концепция _конвейеров_\n(pipelines). Заимствуя идею из UNIX, конвейеры позволяют объединять\nнесколько команд шаблона в цепочку для компактного выражения серии\nпреобразований. Другими словами, конвейеры — это эффективный способ\nвыполнить несколько операций последовательно. Давайте перепишем\nприведённый выше пример, используя конвейер.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nВ этом примере вместо вызова `quote ARGUMENT` мы изменили порядок. Мы\n«отправили» аргумент в функцию с помощью конвейера (`|`):\n`.Values.favorite.drink | quote`. Используя конвейеры, можно объединять\nнесколько функций в цепочку:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Изменение порядка — распространённая практика в шаблонах. Вы будете чаще\n> встречать `.val | quote`, чем `quote .val`. Оба варианта допустимы.\n\nПри обработке этот шаблон создаст следующий результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nОбратите внимание, что исходное значение `pizza` теперь преобразовано в `\"PIZZA\"`.\n\nПри передаче аргументов через конвейер результат первого вычисления\n(`.Values.favorite.drink`) передаётся как _последний аргумент функции_. Мы\nможем модифицировать пример с напитком, чтобы проиллюстрировать это\nс помощью функции, принимающей два аргумента: `repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nФункция `repeat` повторяет заданную строку указанное количество раз,\nпоэтому результат будет следующим:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Использование функции `default`\n\nОдна из часто используемых в шаблонах функций — это `default`: `default\nDEFAULT_VALUE GIVEN_VALUE`. Эта функция позволяет указать значение по умолчанию\nвнутри шаблона на случай, если значение не задано. Давайте используем её для\nмодификации примера с напитком:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nЕсли мы запустим это как обычно, получим наш `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nТеперь удалим настройку любимого напитка из `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nТеперь повторный запуск `helm install --dry-run --debug fair-worm ./mychart` \nсоздаст следующий YAML:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nВ реальном чарте все статические значения по умолчанию должны находиться в файле\n`values.yaml` и не должны дублироваться с помощью команды `default` (иначе они\nбудут избыточными). Однако функция `default` идеально подходит для вычисляемых\nзначений, которые нельзя объявить внутри `values.yaml`. Например:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nВ некоторых случаях условная проверка с `if` может быть более подходящей, чем\n`default`. Мы рассмотрим их в следующем разделе.\n\nФункции шаблонов и конвейеры — это мощный способ преобразования информации\nи её вставки в YAML. Но иногда необходимо добавить логику шаблона, которая\nнемного сложнее, чем просто вставка строки. В следующем разделе мы рассмотрим\nуправляющие конструкции, предоставляемые языком шаблонов.\n\n## Использование функции `lookup`\n\nФункция `lookup` может использоваться для _поиска_ ресурсов в работающем кластере.\nСинтаксис функции lookup: `lookup apiVersion, kind, namespace, name\n-> resource or resource list`.\n\n| параметр   | тип    |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\nПараметры `name` и `namespace` являются необязательными и могут быть переданы как\nпустая строка (`\"\"`). Однако при работе с ресурсом, ограниченным пространством имён,\nоба параметра `name` и `namespace` должны быть указаны.\n\nВозможны следующие комбинации параметров:\n\n| Поведение                              | Функция lookup                             |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\nКогда `lookup` возвращает объект, он представляет собой словарь (dictionary). Этот\nсловарь можно использовать для извлечения конкретных значений.\n\nСледующий пример вернёт аннотации объекта `mynamespace`:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nКогда `lookup` возвращает список объектов, доступ к списку можно получить\nчерез поле `items`:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* do something with each service */}}\n{{ end }}\n```\n\nЕсли объект не найден, возвращается пустое значение. Это можно использовать для\nпроверки существования объекта.\n\nФункция `lookup` использует существующую конфигурацию подключения Helm к Kubernetes\nдля выполнения запросов к Kubernetes. Если при взаимодействии с API-сервером\nвозвращается ошибка (например, из-за отсутствия прав доступа к ресурсу),\nобработка шаблона Helm завершится с ошибкой.\n\nИмейте в виду, что Helm не должен обращаться к API-серверу Kubernetes во время\nопераций `helm template|install|upgrade|delete|rollback --dry-run`. Чтобы протестировать\n`lookup` на работающем кластере, следует использовать\n`helm template|install|upgrade|delete|rollback --dry-run=server`,\nчто позволит установить соединение с кластером.\n\n## Операторы — это функции\n\nДля шаблонов операторы (`eq`, `ne`, `lt`, `gt`, `and`, `or` и т.д.) реализованы\nкак функции. В конвейерах операции можно группировать с помощью\nкруглых скобок (`(` и `)`).\n\nТеперь мы можем перейти от функций и конвейеров к управлению потоком выполнения\nс помощью условий, циклов и модификаторов области видимости.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Начало работы\ndescription: Краткое руководство по шаблонам чартов.\nsidebar_position: 2\n---\n\nВ этом разделе руководства мы создадим чарт и добавим первый шаблон. Созданный здесь чарт будет использоваться на протяжении всего руководства.\n\nДля начала давайте кратко рассмотрим структуру чарта Helm.\n\n## Чарты\n\nКак описано в [Руководстве по чартам](/topics/charts.md), чарты Helm имеют следующую структуру:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nДиректория `templates/` предназначена для файлов шаблонов. Когда Helm обрабатывает чарт, он пропускает все файлы из директории `templates/` через движок шаблонов. Затем собирает результаты обработки шаблонов и отправляет их в Kubernetes.\n\nФайл `values.yaml` также важен для шаблонов. Этот файл содержит _значения по умолчанию_ для чарта. Эти значения могут быть переопределены пользователями при выполнении команд `helm install` или `helm upgrade`.\n\nФайл `Chart.yaml` содержит описание чарта. Вы можете обращаться к нему изнутри шаблона.\n\nДиректория `charts/` _может_ содержать другие чарты (которые мы называем _субчартами_). Далее в этом руководстве мы рассмотрим, как они работают при рендеринге шаблонов.\n\n## Создание начального чарта\n\nДля этого руководства мы создадим простой чарт под названием `mychart`, а затем добавим в него несколько шаблонов.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### Краткий обзор `mychart/templates/`\n\nЕсли вы посмотрите в директорию `mychart/templates/`, то увидите несколько уже существующих файлов:\n\n- `NOTES.txt`: «Текст справки» для вашего чарта. Он будет показан пользователям при выполнении команды `helm install`.\n- `deployment.yaml`: Базовый манифест для создания [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) в Kubernetes.\n- `service.yaml`: Базовый манифест для создания [Service](https://kubernetes.io/docs/concepts/services-networking/service/) для вашего Deployment.\n- `_helpers.tpl`: Место для размещения вспомогательных шаблонов, которые можно повторно использовать в чарте.\n\nИ мы собираемся... _удалить их все!_ Таким образом, мы сможем пройти руководство с нуля. На самом деле мы создадим собственные `NOTES.txt` и `_helpers.tpl` по ходу работы.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nПри написании production-чартов наличие базовых версий этих файлов может быть очень полезным. Поэтому в повседневной работе с чартами вы, скорее всего, не будете их удалять.\n\n## Первый шаблон\n\nПервый шаблон, который мы создадим — это `ConfigMap`. В Kubernetes ConfigMap — это простой объект для хранения конфигурационных данных. Другие объекты, например Pod'ы, могут получать доступ к данным в ConfigMap.\n\nПоскольку ConfigMap — это базовый ресурс, он отлично подходит для начала работы.\n\nДавайте создадим файл `mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**СОВЕТ:** Имена шаблонов не следуют строгим правилам именования. Однако мы рекомендуем использовать расширение `.yaml` для файлов YAML и `.tpl` для вспомогательных шаблонов.\n\nПриведённый выше YAML-файл — это минимальный ConfigMap с необходимыми полями. Поскольку этот файл находится в директории `mychart/templates/`, он будет обработан движком шаблонов.\n\nСовершенно нормально размещать обычные YAML-файлы в директории `mychart/templates/`. Когда Helm прочитает этот шаблон, он просто отправит его в Kubernetes как есть.\n\nС этим простым шаблоном у нас уже есть чарт, готовый к установке. Установить его можно так:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nС помощью Helm мы можем получить релиз и увидеть фактический шаблон, который был загружен.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nКоманда `helm get manifest` принимает имя релиза (`full-coral`) и выводит все ресурсы Kubernetes, которые были загружены на сервер. Каждый файл начинается с `---` для обозначения начала YAML-документа, за которым следует автоматически сгенерированный комментарий, указывающий, какой файл шаблона создал этот YAML-документ.\n\nДалее мы видим, что YAML-данные полностью соответствуют тому, что мы написали в файле `configmap.yaml`.\n\nТеперь мы можем удалить наш релиз: `helm uninstall full-coral`.\n\n### Добавление простого вызова шаблона\n\nЖёстко заданное значение `name:` в ресурсе обычно считается плохой практикой. Имена должны быть уникальными для каждого релиза. Поэтому мы можем сгенерировать поле name, подставив в него имя релиза.\n\n**СОВЕТ:** Поле `name:` ограничено 63 символами из-за ограничений системы DNS. По этой причине имена релизов ограничены 53 символами. Kubernetes 1.3 и более ранние версии ограничивались только 24 символами (то есть 14 символами для имени).\n\nДавайте изменим `configmap.yaml` соответствующим образом.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nГлавное изменение — в значении поля `name:`, которое теперь равно `{{ .Release.Name }}-configmap`.\n\n> Директива шаблона заключается в блоки `{{` и `}}`.\n\nДиректива шаблона `{{ .Release.Name }}` подставляет имя релиза в шаблон. Значения, передаваемые в шаблон, можно рассматривать как _объекты с пространством имён_, где точка (`.`) разделяет каждый элемент пространства имён.\n\nНачальная точка перед `Release` означает, что мы начинаем с самого верхнего пространства имён для данной области видимости (об областях видимости мы поговорим чуть позже). Таким образом, `.Release.Name` можно прочитать как «начать с верхнего пространства имён, найти объект `Release`, затем найти внутри него объект `Name`».\n\nОбъект `Release` — это один из встроенных объектов Helm, и мы рассмотрим его подробнее позже. Пока достаточно сказать, что он отображает имя релиза, которое библиотека присваивает нашему релизу.\n\nТеперь, когда мы установим наш ресурс, мы сразу увидим результат использования этой директивы шаблона:\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nВы можете выполнить `helm get manifest clunky-serval`, чтобы увидеть весь сгенерированный YAML.\n\nОбратите внимание, что имя ConfigMap внутри Kubernetes теперь `clunky-serval-configmap` вместо прежнего `mychart-configmap`.\n\nНа данный момент мы рассмотрели шаблоны в их самом базовом виде: YAML-файлы с директивами шаблонов, заключёнными в `{{` и `}}`. В следующей части мы подробнее изучим шаблоны. Но прежде чем двигаться дальше, есть один полезный приём, который может ускорить создание шаблонов: если вы хотите протестировать рендеринг шаблона, но не устанавливать ничего, используйте команду `helm install --debug --dry-run goodly-guppy ./mychart`. Она отрендерит шаблоны, но вместо установки чарта вернёт вам результат рендеринга, чтобы вы могли увидеть вывод:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nИспользование `--dry-run` упростит тестирование вашего кода, но не гарантирует, что Kubernetes примет сгенерированные шаблоны. Лучше не предполагать, что ваш чарт установится только потому, что `--dry-run` отработал успешно.\n\nВ [Руководстве по шаблонам чартов](/chart_template_guide/index.mdx) мы возьмём базовый чарт, созданный здесь, и подробно изучим язык шаблонов Helm. А начнём мы со встроенных объектов.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: Файл .helmignore\ndescription: Файл `.helmignore` используется для указания файлов, которые не должны включаться в ваш чарт.\nsidebar_position: 12\n---\n\nФайл `.helmignore` используется для указания файлов, которые не должны включаться в ваш чарт.\n\nЕсли этот файл существует, команда `helm package` при упаковке вашего приложения будет игнорировать все файлы, соответствующие шаблонам, указанным в файле `.helmignore`.\n\nЭто помогает избежать включения ненужных или конфиденциальных файлов и директорий в ваш чарт.\n\nФайл `.helmignore` поддерживает шаблоны glob в стиле Unix shell, относительные пути и отрицание (с префиксом !). На каждой строке допускается только один шаблон.\n\nВот пример файла `.helmignore`:\n\n```\n# comment\n\n# Match any file or path named .helmignore\n.helmignore\n\n# Match any file or path named .git\n.git\n\n# Match any text file\n*.txt\n\n# Match only directories named mydir\nmydir/\n\n# Match only text files in the top-level directory\n/*.txt\n\n# Match only the file foo.txt in the top-level directory\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt\na[b-d].txt\n\n# Match any file under subdir matching temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nНекоторые важные отличия от .gitignore:\n- Синтаксис '**' не поддерживается\n- Библиотека для glob-шаблонов — это Go 'filepath.Match', а не fnmatch(3)\n- Завершающие пробелы всегда игнорируются (способа их сохранить не предусмотрено)\n- Нет поддержки '\\!' в качестве специальной начальной последовательности\n- Файл `.helmignore` не исключает сам себя по умолчанию — вам нужно явно добавить для него запись `.helmignore`\n\n\n**Мы будем рады вашей помощи** в улучшении этого документа. Чтобы добавить, исправить или удалить информацию, [создайте issue](https://github.com/helm/helm-www/issues) или отправьте нам pull request.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx",
    "content": "---\ntitle: Руководство по шаблонам чартов\nsidebar_position: 5\n---\n\n# Руководство разработчика шаблонов чартов\n\nЭто руководство представляет введение в шаблоны чартов Helm с акцентом на\nязык шаблонов.\n\nШаблоны генерируют файлы манифестов — описания ресурсов в формате YAML,\nкоторые понимает Kubernetes. Мы рассмотрим, как структурированы шаблоны,\nкак их можно использовать, как писать шаблоны Go и как отлаживать\nвашу работу.\n\nЭто руководство фокусируется на следующих концепциях:\n\n- Язык шаблонов Helm\n- Использование значений (values)\n- Техники работы с шаблонами\n\nЭто руководство ориентировано на изучение тонкостей языка шаблонов Helm.\nДругие руководства предоставляют вводные материалы, примеры и лучшие\nпрактики.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Именованные шаблоны\ndescription: Как определять именованные шаблоны.\nsidebar_position: 9\n---\n\nПришло время выйти за рамки одного шаблона и начать создавать новые. В этом разделе мы рассмотрим, как определять _именованные шаблоны_ в одном файле и использовать их в других местах. _Именованный шаблон_ (иногда называемый _частичным шаблоном_ или _подшаблоном_) — это просто шаблон, определённый внутри файла, которому присвоено имя. Мы рассмотрим два способа их создания и несколько способов использования.\n\nВ разделе [Управление потоком выполнения](./control_structures.md) мы познакомились с тремя действиями для объявления и управления шаблонами: `define`, `template` и `block`. В этом разделе мы подробнее рассмотрим эти три действия, а также специальную функцию `include`, которая работает аналогично действию `template`.\n\nВажная деталь, которую следует помнить при именовании шаблонов: **имена шаблонов глобальны**. Если вы объявите два шаблона с одинаковым именем, будет использован тот, который загружен последним. Поскольку шаблоны субчартов компилируются вместе с шаблонами верхнего уровня, следует давать шаблонам _имена, специфичные для чарта_.\n\nПопулярное соглашение об именовании — добавлять к каждому определённому шаблону префикс с именем чарта: `{{ define \"mychart.labels\" }}`. Использование конкретного имени чарта в качестве префикса позволяет избежать конфликтов, которые могут возникнуть из-за двух разных чартов с шаблонами одинакового имени.\n\nЭто поведение также применимо к разным версиям одного чарта. Если у вас есть `mychart` версии `1.0.0`, который определяет шаблон одним способом, и `mychart` версии `2.0.0`, который изменяет существующий именованный шаблон, будет использован тот, который загружен последним. Чтобы обойти эту проблему, можно также добавить версию в имя чарта: `{{ define \"mychart.v1.labels\" }}` и `{{ define \"mychart.v2.labels\" }}`.\n\n## Частичные шаблоны и файлы с `_`\n\nДо сих пор мы использовали один файл с одним шаблоном. Но язык шаблонов Helm позволяет создавать именованные встроенные шаблоны, к которым можно обращаться по имени из других мест.\n\nПрежде чем перейти к деталям написания таких шаблонов, стоит упомянуть соглашение об именовании файлов:\n\n* Большинство файлов в `templates/` обрабатываются как содержащие манифесты Kubernetes\n* `NOTES.txt` является исключением\n* Однако файлы, имена которых начинаются с подчёркивания (`_`), считаются _не содержащими_ манифестов. Эти файлы не преобразуются в определения объектов Kubernetes, но доступны везде в других шаблонах чарта для использования.\n\nЭти файлы используются для хранения частичных шаблонов и вспомогательных функций. Когда мы впервые создали `mychart`, мы видели файл `_helpers.tpl`. Этот файл является местом по умолчанию для хранения частичных шаблонов.\n\n## Объявление и использование шаблонов с `define` и `template`\n\nДействие `define` позволяет создать именованный шаблон внутри файла шаблона. Его синтаксис выглядит так:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # тело шаблона здесь\n{{- end }}\n```\n\nНапример, мы можем определить шаблон для инкапсуляции блока меток Kubernetes:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nТеперь мы можем встроить этот шаблон в наш существующий ConfigMap и включить его с помощью действия `template`:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nКогда шаблонизатор читает этот файл, он сохраняет ссылку на `mychart.labels` до тех пор, пока не будет вызван `template \"mychart.labels\"`. Затем он отрисует этот шаблон на месте. Результат будет выглядеть так:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nПримечание: `define` не производит вывод, пока не будет вызван с помощью `template`, как в этом примере.\n\nПо соглашению, в чартах Helm эти шаблоны помещаются в файл частичных шаблонов, обычно `_helpers.tpl`. Давайте переместим эту функцию туда:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nПо соглашению, функции `define` должны иметь простой блок документации (`{{/* ... */}}`), описывающий их назначение.\n\nХотя это определение находится в `_helpers.tpl`, к нему всё равно можно обращаться из `configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nКак упоминалось выше, **имена шаблонов глобальны**. В результате, если два шаблона объявлены с одинаковым именем, будет использован последний. Поскольку шаблоны субчартов компилируются вместе с шаблонами верхнего уровня, лучше давать шаблонам _имена, специфичные для чарта_. Популярное соглашение об именовании — добавлять к каждому определённому шаблону префикс с именем чарта: `{{ define \"mychart.labels\" }}`.\n\n## Установка области видимости шаблона\n\nВ определённом выше шаблоне мы не использовали никаких объектов — только функции. Давайте изменим наш определённый шаблон, чтобы включить имя и версию чарта:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nЕсли мы отрисуем это, получим ошибку:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nЧтобы увидеть результат рендеринга, выполните команду с `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`.\nРезультат будет не таким, как ожидалось:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\nЧто произошло с именем и версией? Они не были в области видимости нашего определённого шаблона. Когда именованный шаблон (созданный с помощью `define`) отрисовывается, он получает область видимости, переданную при вызове `template`. В нашем примере мы включили шаблон так:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nОбласть видимости не была передана, поэтому внутри шаблона мы не можем обращаться к чему-либо в `.`. Это легко исправить — просто передайте область видимости в шаблон:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nОбратите внимание, что мы передаём `.` в конце вызова `template`. Мы могли бы также передать `.Values` или `.Values.favorite` или любую другую нужную область видимости. Но нам нужна область видимости верхнего уровня. В контексте именованного шаблона `$` будет ссылаться на переданную область видимости, а не на какую-то глобальную.\n\nТеперь, если мы выполним этот шаблон с `helm install --dry-run --debug plinking-anaco ./mychart`, получим:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nТеперь `{{ .Chart.Name }}` преобразуется в `mychart`, а `{{ .Chart.Version }}` — в `0.1.0`.\n\n## Функция `include`\n\nДопустим, мы определили простой шаблон, который выглядит так:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nТеперь допустим, что мы хотим вставить его как в раздел `labels:` нашего шаблона, так и в раздел `data:`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nЕсли мы отрисуем это, получим ошибку:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nЧтобы увидеть результат рендеринга, выполните команду с `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`.\nРезультат будет не таким, как ожидалось:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nОбратите внимание, что отступы у `app_version` неправильные в обоих местах. Почему? Потому что подставляемый шаблон имеет текст, выровненный по левому краю. Поскольку `template` является действием, а не функцией, невозможно передать вывод вызова `template` другим функциям — данные просто вставляются на место.\n\nЧтобы обойти этот случай, Helm предоставляет альтернативу `template`, которая импортирует содержимое шаблона в текущий конвейер, где его можно передать другим функциям в конвейере.\n\nВот исправленный пример с использованием `indent` для правильного отступа шаблона `mychart.app`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nТеперь сгенерированный YAML правильно отформатирован для каждого раздела:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> В шаблонах Helm предпочтительнее использовать `include` вместо `template`, чтобы лучше контролировать форматирование вывода для YAML-документов.\n\nИногда нам нужно импортировать содержимое, но не как шаблоны — то есть импортировать файлы как есть. Мы можем сделать это, обращаясь к файлам через объект `.Files`, который описан в следующем разделе.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Создание файла NOTES.txt\ndescription: Как предоставить инструкции пользователям вашего чарта.\nsidebar_position: 10\n---\n\nВ этом разделе мы рассмотрим инструмент Helm для предоставления инструкций пользователям вашего чарта. По завершении команды `helm install` или `helm upgrade` Helm может вывести блок полезной информации для пользователей. Эта информация легко настраивается с помощью шаблонов.\n\nЧтобы добавить инструкции по установке в ваш чарт, просто создайте файл `templates/NOTES.txt`. Это обычный текстовый файл, но он обрабатывается как шаблон и имеет доступ ко всем стандартным функциям и объектам шаблонов.\n\nДавайте создадим простой файл `NOTES.txt`:\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nТеперь, если мы выполним `helm install rude-cardinal ./mychart`, в конце вывода мы увидим следующее сообщение:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nИспользование `NOTES.txt` таким образом — отличный способ предоставить пользователям подробную информацию о том, как работать с только что установленным чартом. Создание файла `NOTES.txt` настоятельно рекомендуется, хотя и не является обязательным.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Субчарты и глобальные значения\ndescription: Работа со значениями субчартов и глобальными значениями.\nsidebar_position: 11\n---\n\nДо сих пор мы работали только с одним чартом. Но чарты могут иметь зависимости, называемые _субчартами_, которые также имеют собственные значения и шаблоны. В этом разделе мы создадим субчарт и рассмотрим различные способы доступа к значениям из шаблонов.\n\nПрежде чем перейти к коду, следует узнать несколько важных деталей о субчартах приложений:\n\n1. Субчарт считается «автономным», то есть субчарт никогда не может явно зависеть от родительского чарта.\n2. По этой причине субчарт не может обращаться к значениям родительского чарта.\n3. Родительский чарт может переопределять значения субчартов.\n4. В Helm существует концепция _глобальных значений_, которые доступны всем чартам.\n\n> Эти ограничения не обязательно применимы к [library-чартам](/topics/library_charts.md), которые предназначены для предоставления стандартизированных вспомогательных функций.\n\nВ процессе изучения примеров этого раздела многие концепции станут понятнее.\n\n## Создание субчарта\n\nДля этих упражнений мы начнём с чарта `mychart/`, созданного в начале руководства, и добавим внутрь него новый чарт.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nОбратите внимание: как и ранее, мы удалили все базовые шаблоны, чтобы начать с нуля. В этом руководстве мы сосредоточены на работе шаблонов, а не на управлении зависимостями. Дополнительную информацию о работе субчартов можно найти в [руководстве по чартам](/topics/charts.md).\n\n## Добавление значений и шаблона в субчарт\n\nДалее создадим простой шаблон и файл values для нашего чарта `mysubchart`. В директории `mychart/charts/mysubchart` уже должен быть файл `values.yaml`. Настроим его следующим образом:\n\n```yaml\ndessert: cake\n```\n\nЗатем создадим новый шаблон ConfigMap в `mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nПоскольку каждый субчарт является _автономным чартом_, мы можем протестировать `mysubchart` отдельно:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Переопределение значений из родительского чарта\n\nНаш исходный чарт `mychart` теперь является _родительским чартом_ для `mysubchart`. Эта связь основана исключительно на том, что `mysubchart` находится внутри `mychart/charts`.\n\nПоскольку `mychart` является родительским, мы можем указать конфигурацию в `mychart` и передать её в `mysubchart`. Например, можно изменить `mychart/values.yaml` следующим образом:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nОбратите внимание на последние две строки. Все директивы внутри секции `mysubchart` будут переданы в чарт `mysubchart`. Поэтому, если мы выполним `helm install --generate-name --dry-run --debug mychart`, среди прочего мы увидим ConfigMap субчарта `mysubchart`:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nЗначение верхнего уровня переопределило значение субчарта.\n\nЗдесь важно отметить одну деталь. Мы не изменяли шаблон `mychart/charts/mysubchart/templates/configmap.yaml`, чтобы он указывал на `.Values.mysubchart.dessert`. С точки зрения этого шаблона значение по-прежнему находится в `.Values.dessert`. Когда движок шаблонов передаёт значения, он устанавливает область видимости. Поэтому для шаблонов `mysubchart` в `.Values` будут доступны только значения, предназначенные специально для `mysubchart`.\n\nОднако иногда требуется, чтобы определённые значения были доступны всем шаблонам. Это достигается с помощью глобальных значений чарта.\n\n## Глобальные значения чарта\n\nГлобальные значения — это значения, к которым можно обращаться из любого чарта или субчарта по одному и тому же имени. Глобальные значения требуют явного объявления. Нельзя использовать существующее неглобальное значение как глобальное.\n\nТип данных Values имеет зарезервированную секцию `Values.global`, в которой можно задавать глобальные значения. Давайте добавим её в файл `mychart/values.yaml`.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nБлагодаря тому, как работают глобальные значения, и `mychart/templates/configmap.yaml`, и `mysubchart/templates/configmap.yaml` смогут получить доступ к этому значению через `{{ .Values.global.salad }}`.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nТеперь, если мы выполним пробную установку, мы увидим одинаковое значение в обоих результатах:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nГлобальные значения полезны для передачи подобной информации, хотя их использование требует предварительного планирования, чтобы правильно настроить соответствующие шаблоны.\n\n## Совместное использование шаблонов с субчартами\n\nРодительские чарты и субчарты могут совместно использовать шаблоны. Любой определённый блок в любом чарте доступен другим чартам.\n\nНапример, можно определить простой шаблон следующим образом:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nНапомним, что метки в шаблонах являются _глобально разделяемыми_. Поэтому шаблон `labels` может быть включён из любого другого чарта.\n\nХотя разработчики чартов могут выбирать между `include` и `template`, одно из преимуществ использования `include` заключается в том, что `include` позволяет динамически ссылаться на шаблоны:\n\n```yaml\n{{ include $mytemplate }}\n```\n\nПриведённый код разыменует переменную `$mytemplate`. Функция `template`, напротив, принимает только строковый литерал.\n\n## Избегайте использования блоков\n\nЯзык шаблонов Go предоставляет ключевое слово `block`, которое позволяет разработчикам задавать реализацию по умолчанию, переопределяемую позднее. В чартах Helm блоки — не лучший инструмент для переопределения, поскольку при наличии нескольких реализаций одного и того же блока выбор реализации непредсказуем.\n\nВместо этого рекомендуется использовать `include`.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Файлы Values\ndescription: Инструкции по использованию флага --values.\nsidebar_position: 4\n---\n\nВ предыдущем разделе мы рассмотрели встроенные объекты, которые предоставляют шаблоны Helm. Один из встроенных объектов — `Values`. Этот объект обеспечивает доступ к значениям, переданным в чарт. Его содержимое формируется из нескольких источников:\n\n- Файл `values.yaml` в чарте\n- Если это субчарт — файл `values.yaml` родительского чарта\n- Файл values, переданный в `helm install` или `helm upgrade` с помощью флага `-f` (`helm install -f myvals.yaml ./mychart`)\n- Отдельные параметры, переданные с помощью `--set` (например, `helm install --set foo=bar ./mychart`)\n\nСписок выше приведён в порядке возрастания приоритета: `values.yaml` используется по умолчанию и может быть переопределён файлом `values.yaml` родительского чарта, который, в свою очередь, может быть переопределён пользовательским файлом values, а тот — параметрами `--set`.\n\nФайлы values — это обычные YAML-файлы. Давайте отредактируем `mychart/values.yaml`, а затем изменим наш шаблон ConfigMap.\n\nУдалим значения по умолчанию из `values.yaml` и установим только один параметр:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nТеперь мы можем использовать это значение в шаблоне:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nОбратите внимание: в последней строке мы обращаемся к `favoriteDrink` как к атрибуту `Values`: `{{ .Values.favoriteDrink }}`.\n\nПосмотрим на результат.\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nПоскольку `favoriteDrink` в файле `values.yaml` по умолчанию установлен как `coffee`, именно это значение отображается в шаблоне. Мы можем легко переопределить его, добавив флаг `--set` при вызове `helm install`:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nПоскольку `--set` имеет более высокий приоритет, чем файл `values.yaml` по умолчанию, наш шаблон генерирует `drink: slurm`.\n\nФайлы values также могут содержать более структурированное содержимое. Например, мы можем создать раздел `favorite` в нашем файле `values.yaml` и добавить туда несколько ключей:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nТеперь нам нужно немного изменить шаблон:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nХотя такая структуризация данных возможна, рекомендуется сохранять деревья значений неглубокими, отдавая предпочтение плоской структуре. Когда мы рассмотрим присвоение значений субчартам, вы увидите, как значения именуются с использованием древовидной структуры.\n\n## Удаление ключа по умолчанию\n\nЕсли вам нужно удалить ключ из значений по умолчанию, вы можете переопределить его значение как `null` — тогда Helm удалит этот ключ при слиянии переопределённых значений.\n\nНапример, стабильный чарт Drupal позволяет настраивать проверку работоспособности (liveness probe), если вы используете собственный образ. Вот значения по умолчанию:\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nЕсли вы попытаетесь переопределить обработчик livenessProbe на `exec` вместо `httpGet` с помощью `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm объединит ключи по умолчанию и переопределённые, что приведёт к следующему YAML:\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nОднако Kubernetes выдаст ошибку, поскольку нельзя объявлять более одного обработчика livenessProbe. Чтобы решить эту проблему, вы можете указать Helm удалить `livenessProbe.httpGet`, установив его в null:\n\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nНа данный момент мы рассмотрели несколько встроенных объектов и использовали их для внедрения информации в шаблон. Теперь перейдём к другому аспекту движка шаблонов: функциям и конвейерам.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: Переменные\ndescription: Использование переменных в шаблонах.\nsidebar_position: 8\n---\n\nОсвоив функции, конвейеры, объекты и управляющие структуры, мы можем перейти к одной из базовых концепций многих языков программирования: переменным. В шаблонах они используются реже. Тем не менее мы рассмотрим, как с их помощью упростить код и более эффективно использовать конструкции `with` и `range`.\n\nВ предыдущем примере мы видели, что этот код не работает:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` недоступен внутри области видимости, ограниченной блоком `with`. Один из способов обойти проблемы с областью видимости — присвоить объекты переменным, к которым можно обращаться независимо от текущей области видимости.\n\nВ шаблонах Helm переменная — это именованная ссылка на другой объект. Она записывается в формате `$name`. Переменные присваиваются с помощью специального оператора присваивания: `:=`. Перепишем приведённый выше пример, используя переменную для `Release.Name`.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nОбратите внимание: перед началом блока `with` мы присваиваем `$relname :=\n.Release.Name`. Теперь внутри блока `with` переменная `$relname` по-прежнему указывает на имя релиза.\n\nВыполнение даст следующий результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nПеременные особенно полезны в циклах `range`. Их можно использовать с объектами типа списка для получения как индекса, так и значения:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nОбратите внимание: сначала идёт `range`, затем переменные, оператор присваивания и список. Это присвоит целочисленный индекс (начиная с нуля) переменной `$index`, а значение — переменной `$topping`. Выполнение даст:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nДля структур данных, содержащих и ключ, и значение, можно использовать `range` для получения обоих. Например, мы можем перебрать `.Values.favorite` следующим образом:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nНа первой итерации `$key` будет равен `drink`, а `$val` — `coffee`. На второй итерации `$key` будет равен `food`, а `$val` — `pizza`. Результат выполнения:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nПеременные обычно не являются «глобальными». Их область видимости ограничена блоком, в котором они объявлены. Ранее мы присвоили `$relname` на верхнем уровне шаблона. Эта переменная будет доступна во всём шаблоне. Но в последнем примере `$key` и `$val` будут доступны только внутри блока `{{ range... }}{{ end }}`.\n\nОднако существует одна переменная, которая всегда указывает на корневой контекст: `$`. Она позволяет обращаться к данным верхнего уровня (например, `.Release.Name` или `.Chart.Name`) из любого места шаблона, даже внутри цикла `range`.\n\nПример:\n\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Many helm templates would use `.` below, but that will not work,\n    # however `$` will work here\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # I cannot reference .Chart.Name, but I can do $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Value from appVersion in Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nДо сих пор мы рассматривали только один шаблон в одном файле. Но язык шаблонов Helm позволяет объявлять несколько шаблонов и использовать их совместно. Об этом пойдёт речь в следующем разделе.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Дальнейшие шаги\ndescription: Подведение итогов — полезные ссылки на другую документацию, которая поможет вам в работе.\nsidebar_position: 14\n---\n\nЭто руководство создано для того, чтобы дать вам, как разработчику чартов, глубокое понимание языка шаблонов Helm. Основной акцент сделан на технических аспектах разработки шаблонов.\n\nОднако многие вопросы практической повседневной разработки чартов здесь не рассмотрены. Ниже приведены полезные ссылки на другую документацию, которая поможет вам при создании новых чартов:\n\n- [Artifact Hub](https://artifacthub.io/packages/search?kind=0) от CNCF — незаменимый источник чартов.\n- [Документация Kubernetes](https://kubernetes.io/docs/home/) содержит подробные примеры различных видов ресурсов: от ConfigMaps и Secrets до DaemonSets и Deployments.\n- [Руководство по чартам](/topics/charts.md) описывает рабочий процесс использования чартов.\n- [Руководство по хукам чартов](/topics/charts_hooks.md) объясняет, как создавать хуки жизненного цикла.\n- [Советы и рекомендации по чартам](/howto/charts_tips_and_tricks.md) — полезные советы по написанию чартов.\n- [Документация Sprig](https://github.com/Masterminds/sprig) описывает более шестидесяти функций шаблонов.\n- [Документация Go template](https://godoc.org/text/template) подробно объясняет синтаксис шаблонов.\n- [Schelm](https://github.com/databus23/schelm) — удобная утилита для отладки чартов.\n\nИногда проще задать несколько вопросов и получить ответы от опытных разработчиков. Лучшее место для этого — каналы Helm в [Kubernetes Slack](https://kubernetes.slack.com):\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nЕсли вы обнаружите ошибки или пропуски в этом документе, хотите предложить новый контент или внести свой вклад, посетите [The Helm Project](https://github.com/helm/helm-www).\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Приложение: Техники работы с YAML\"\ndescription: Подробный обзор спецификации YAML и её применения в Helm.\nsidebar_position: 15\n---\n\nБольшая часть этого руководства была посвящена написанию языка шаблонов. В этом разделе мы рассмотрим формат YAML. YAML обладает рядом полезных возможностей, которые мы, как авторы шаблонов, можем использовать для уменьшения количества ошибок и улучшения читаемости наших шаблонов.\n\n## Скаляры и коллекции\n\nСогласно [спецификации YAML](https://yaml.org/spec/1.2/spec.html), существует два типа коллекций и множество скалярных типов.\n\nДва типа коллекций — это словари (map) и последовательности (sequence):\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nСкалярные значения — это отдельные значения (в отличие от коллекций).\n\n### Скалярные типы в YAML\n\nВ диалекте YAML, используемом Helm, тип данных скалярного значения определяется сложным набором правил, включая схему Kubernetes для определений ресурсов. Однако при выводе типов обычно действуют следующие правила.\n\nЕсли целое число или число с плавающей точкой записано без кавычек, оно обычно рассматривается как числовой тип:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nНо если они заключены в кавычки, они рассматриваются как строки:\n\n```yaml\ncount: \"1\" # <-- строка, не int\nsize: '2.34' # <-- строка, не float\n```\n\nТо же самое относится к булевым значениям:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # строка\n```\n\nСлово для пустого значения — `null` (не `nil`).\n\nОбратите внимание, что `port: \"80\"` является допустимым YAML и пройдёт как через движок шаблонов, так и через парсер YAML, но вызовет ошибку, если Kubernetes ожидает, что `port` будет целым числом.\n\nВ некоторых случаях можно принудительно указать определённый тип с помощью тегов узлов YAML:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nВ примере выше `!!str` указывает парсеру, что `age` является строкой, даже если выглядит как целое число. А `port` рассматривается как целое число, несмотря на то что заключён в кавычки.\n\n## Строки в YAML\n\nБольшая часть данных, которые мы размещаем в документах YAML, — это строки. YAML предоставляет несколько способов представления строк. В этом разделе описываются эти способы и демонстрируется применение некоторых из них.\n\nСуществует три «встроенных» способа объявления строки:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nВсе встроенные стили должны располагаться на одной строке.\n\n- Слова без кавычек (bare words) не экранируются. По этой причине нужно внимательно следить за используемыми символами.\n- Строки в двойных кавычках могут содержать экранированные символы с помощью `\\`. Например, `\"\\\"Hello\\\", she said\"`. Переносы строк можно экранировать с помощью `\\n`.\n- Строки в одинарных кавычках являются «литеральными» строками и не используют `\\` для экранирования символов. Единственная последовательность экранирования — `''`, которая декодируется как одинарная кавычка `'`.\n\nПомимо однострочных строк, можно объявлять многострочные строки:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nВ примере выше значение `coffee` будет рассматриваться как единая строка, эквивалентная `Latte\\nCappuccino\\nEspresso\\n`.\n\nОбратите внимание, что первая строка после `|` должна иметь правильный отступ. Поэтому мы можем нарушить работу примера выше, сделав так:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nПоскольку `Latte` имеет неправильный отступ, мы получим ошибку вроде этой:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nВ шаблонах иногда безопаснее добавить фиктивную «первую строку» содержимого в многострочном документе для защиты от подобной ошибки:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nОбратите внимание, что какой бы ни была первая строка, она сохранится в выходных данных строки. Поэтому если вы используете эту технику для вставки содержимого файла в ConfigMap, комментарий должен быть того типа, который ожидается программой, читающей эту запись.\n\n### Управление пробелами в многострочных строках\n\nВ примере выше мы использовали `|` для обозначения многострочной строки. Обратите внимание, что содержимое строки заканчивается символом `\\n`. Если нужно, чтобы процессор YAML убрал завершающий перенос строки, можно добавить `-` после `|`:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nТеперь значение `coffee` будет: `Latte\\nCappuccino\\nEspresso` (без завершающего `\\n`).\n\nВ других случаях может потребоваться сохранить все завершающие пробельные символы. Это можно сделать с помощью нотации `|+`:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nТеперь значение `coffee` будет `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nОтступы внутри текстового блока сохраняются, что также приводит к сохранению переносов строк:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nВ этом случае `coffee` будет `Latte\\n  12 oz\\n  16 oz\\nCappuccino\\nEspresso`.\n\n### Отступы и шаблоны\n\nПри написании шаблонов вам может понадобиться вставить содержимое файла в шаблон. Как мы видели в предыдущих главах, есть два способа сделать это:\n\n- Используйте `{{ .Files.Get \"FILENAME\" }}` для получения содержимого файла из чарта.\n- Используйте `{{ include \"TEMPLATE\" . }}` для рендеринга шаблона и последующей вставки его содержимого в чарт.\n\nПри вставке файлов в YAML полезно знать правила работы с многострочными строками, описанные выше. Часто самый простой способ вставить статический файл — сделать что-то вроде этого:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nОбратите внимание на отступ выше: `indent 2` указывает движку шаблонов добавить отступ в два пробела к каждой строке «myfile.txt». Обратите внимание, что мы не делаем отступ для самой строки шаблона. Если бы мы это сделали, содержимое первой строки файла имело бы двойной отступ.\n\n### Свёрнутые многострочные строки\n\nИногда нужно представить строку в YAML на нескольких строках, но при интерпретации она должна рассматриваться как одна длинная строка. Это называется «свёртывание» (folding). Чтобы объявить свёрнутый блок, используйте `>` вместо `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nЗначение `coffee` выше будет `Latte Cappuccino Espresso\\n`. Обратите внимание, что все переносы строк, кроме последнего, будут преобразованы в пробелы. Вы можете комбинировать управление пробельными символами с маркером свёртывания, поэтому `>-` заменит или обрежет все переносы строк.\n\nОбратите внимание, что в синтаксисе свёртывания текст с отступом сохраняет переносы строк.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nРезультат будет `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Обратите внимание, что пробелы и переносы строк сохранены.\n\n## Размещение нескольких документов в одном файле\n\nВ один файл можно поместить несколько документов YAML. Для этого новый документ начинается с `---`, а заканчивается `...`\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nВо многих случаях `---` или `...` можно опустить.\n\nНекоторые файлы в Helm не могут содержать более одного документа. Например, если в файле `values.yaml` указано более одного документа, будет использован только первый.\n\nОднако файлы шаблонов могут содержать несколько документов. В этом случае файл (и все его документы) обрабатывается как один объект во время рендеринга шаблона. Но затем результирующий YAML разделяется на несколько документов перед отправкой в Kubernetes.\n\nМы рекомендуем использовать несколько документов в одном файле только при крайней необходимости. Наличие нескольких документов в файле может усложнить отладку.\n\n## YAML — надмножество JSON\n\nПоскольку YAML является надмножеством JSON, любой допустимый документ JSON _должен_ быть допустимым YAML.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nВыше показан другой способ представления этого:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nИ их можно смешивать (с осторожностью):\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nВсе три варианта должны разбираться в одно и то же внутреннее представление.\n\nХотя это означает, что такие файлы, как `values.yaml`, могут содержать данные JSON, Helm не рассматривает расширение файла `.json` как допустимый суффикс.\n\n## Якоря YAML\n\nСпецификация YAML предоставляет способ сохранить ссылку на значение и затем обращаться к этому значению по ссылке. YAML называет это «якорением» (anchoring):\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nВ примере выше `&favoriteCoffee` устанавливает ссылку на `Cappuccino`. Позже эта ссылка используется как `*favoriteCoffee`. Таким образом, `coffees` становится `Latte, Cappuccino, Espresso`.\n\nХотя есть несколько случаев, когда якоря полезны, есть один аспект, который может вызвать незаметные ошибки: при первом чтении YAML ссылка раскрывается, а затем отбрасывается.\n\nПоэтому если мы декодируем и затем снова закодируем пример выше, результирующий YAML будет таким:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nПоскольку Helm и Kubernetes часто читают, модифицируют и затем перезаписывают файлы YAML, якоря будут утеряны.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: Изменения с Helm 2\ndescription: Исчерпывающий список всех основных изменений, появившихся в Helm 3.\nsidebar_position: 1\n---\n\n## Изменения с Helm 2\n\nНиже приведён исчерпывающий список всех основных изменений, появившихся в Helm 3.\n\n### Удаление Tiller\n\nВ процессе разработки Helm 2 мы представили Tiller. Tiller играл важную роль\nдля команд, работающих в общем кластере — он позволял нескольким операторам\nвзаимодействовать с одним и тем же набором релизов.\n\nС включением управления доступом на основе ролей (RBAC) по умолчанию в\nKubernetes 1.6, защита Tiller для использования в production-среде стала\nсложнее в управлении. Из-за множества возможных политик безопасности мы\nпридерживались позиции предоставления разрешительной конфигурации по умолчанию.\nЭто позволяло новым пользователям начать экспериментировать с Helm и Kubernetes\nбез необходимости сразу погружаться в настройки безопасности. К сожалению,\nтакая разрешительная конфигурация могла предоставить пользователю широкий\nнабор прав, которые не были предусмотрены. DevOps-инженерам и SRE приходилось\nизучать дополнительные операционные шаги при установке Tiller в мультитенантный\nкластер.\n\nУзнав, как участники сообщества использовали Helm в определённых сценариях, мы\nобнаружили, что системе управления релизами Tiller не обязательно полагаться на\nоператор внутри кластера для поддержания состояния или как на центральный узел\nдля информации о релизах Helm. Вместо этого мы могли просто получать информацию\nот API-сервера Kubernetes, выполнять рендеринг чартов на стороне клиента и\nсохранять запись об установке в Kubernetes.\n\nОсновная цель Tiller могла быть достигнута без него, поэтому одним из первых\nрешений относительно Helm 3 стало полное удаление Tiller.\n\nС удалением Tiller модель безопасности Helm радикально упростилась. Helm 3\nтеперь поддерживает все современные функции безопасности, идентификации и\nавторизации Kubernetes. Права Helm определяются с помощью вашего [файла\nkubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/).\nАдминистраторы кластера могут ограничивать права пользователей с любой\nнеобходимой детализацией. Релизы по-прежнему записываются в кластер, а остальная\nфункциональность Helm сохраняется.\n\n### Улучшенная стратегия обновления: трёхстороннее стратегическое слияние патчей\n\nВ Helm 2 использовалось двухстороннее стратегическое слияние патчей. При\nобновлении сравнивался манифест последнего чарта с предложенным манифестом чарта\n(предоставленным во время `helm upgrade`). Сравнивались различия между этими\nдвумя чартами, чтобы определить, какие изменения необходимо применить к ресурсам\nв Kubernetes. Если изменения вносились в кластер вне Helm (например, во время\n`kubectl edit`), они не учитывались. Это приводило к невозможности откатить\nресурсы к предыдущему состоянию: поскольку Helm рассматривал только последний\nприменённый манифест чарта как текущее состояние, при отсутствии изменений в\nсостоянии чарта фактическое состояние оставалось неизменным.\n\nВ Helm 3 мы используем трёхстороннее стратегическое слияние патчей. При\nгенерации патча Helm учитывает старый манифест, его фактическое состояние и\nновый манифест.\n\n#### Примеры\n\nРассмотрим несколько типичных примеров того, на что влияет это изменение.\n\n##### Откат при изменении фактического состояния\n\nВаша команда только что развернула приложение в production на Kubernetes с\nпомощью Helm. Чарт содержит объект Deployment, в котором количество реплик\nустановлено на три:\n\n```console\n$ helm install myapp ./myapp\n```\n\nВ команду приходит новый разработчик. В первый рабочий день, наблюдая за\nproduction-кластером, он случайно проливает кофе на клавиатуру и выполняет\n`kubectl scale`, уменьшая количество реплик production-deployment с трёх до нуля.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nДругой разработчик в команде замечает, что production-сайт не работает, и\nрешает откатить релиз к предыдущему состоянию:\n\n```console\n$ helm rollback myapp\n```\n\nЧто происходит?\n\nВ Helm 2 генерировался патч путём сравнения старого манифеста с новым. Поскольку\nэто откат, манифесты одинаковые. Helm определял, что нечего менять, так как нет\nразличий между старым и новым манифестом. Количество реплик продолжало\nоставаться на нуле. Начиналась паника.\n\nВ Helm 3 патч генерируется с использованием старого манифеста, фактического\nсостояния и нового манифеста. Helm распознаёт, что старое состояние было три,\nфактическое состояние — ноль, а новый манифест хочет вернуть значение к трём,\nпоэтому генерирует патч для возврата состояния к трём.\n\n##### Обновление при изменении фактического состояния\n\nМногие service mesh и другие приложения на основе контроллеров внедряют данные\nв объекты Kubernetes. Это может быть sidecar-контейнер, метки или другая\nинформация. Допустим, у вас был такой манифест, сгенерированный из чарта:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nА фактическое состояние было изменено другим приложением на:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nТеперь вы хотите обновить тег образа `nginx` до `2.1.0`. Вы обновляетесь до\nчарта с таким манифестом:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nЧто происходит?\n\nВ Helm 2 генерировался патч объекта `containers` между старым и новым\nманифестом. Фактическое состояние кластера не учитывалось при генерации патча.\n\nФактическое состояние кластера изменялось на:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nSidecar-контейнер удалялся из фактического состояния. Опять паника.\n\nВ Helm 3 генерируется патч объекта `containers` между старым манифестом,\nфактическим состоянием и новым манифестом. Helm замечает, что новый манифест\nизменяет тег образа на `2.1.0`, но фактическое состояние содержит\nsidecar-контейнер.\n\nФактическое состояние кластера изменяется на:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### Имена релизов теперь ограничены namespace\n\nС удалением Tiller информация о каждом релизе должна была где-то храниться. В\nHelm 2 она хранилась в том же namespace, что и Tiller. На практике это означало,\nчто после использования имени для релиза никакой другой релиз не мог\nиспользовать то же имя, даже при развёртывании в другом namespace.\n\nВ Helm 3 информация о конкретном релизе теперь хранится в том же namespace, что\nи сам релиз. Это означает, что пользователи могут выполнить `helm install\nwordpress stable/wordpress` в двух разных namespace, и на каждый можно ссылаться\nчерез `helm list`, изменив контекст текущего namespace (например, `helm list\n--namespace foo`).\n\nБлагодаря лучшему соответствию нативным namespace кластера, команда `helm list`\nбольше не показывает все релизы по умолчанию. Вместо этого она показывает только\nрелизы в namespace вашего текущего контекста Kubernetes (то есть namespace,\nотображаемый при выполнении `kubectl config view --minify`). Это также означает,\nчто необходимо указать флаг `--all-namespaces` для команды `helm list`, чтобы\nполучить поведение, аналогичное Helm 2.\n\n### Secrets как хранилище по умолчанию\n\nВ Helm 3 Secrets теперь используются как [хранилище по\nумолчанию](/topics/advanced.md#storage-backends). В Helm 2 по умолчанию\nиспользовались ConfigMaps для хранения информации о релизах. В Helm 2.7.0 был\nреализован новый бэкенд хранилища, использующий Secrets, и теперь он является\nзначением по умолчанию в Helm 3.\n\nПереход на Secrets в Helm 3 по умолчанию обеспечивает дополнительную\nбезопасность для защиты чартов в сочетании с появлением шифрования Secrets в\nKubernetes.\n\n[Шифрование secrets в\nпокое](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)\nпоявилось как alpha-функция в Kubernetes 1.7 и стало стабильным в Kubernetes\n1.13. Это позволяет пользователям шифровать метаданные релизов Helm в покое, что\nявляется хорошей отправной точкой для последующего расширения на использование\nчего-то вроде Vault.\n\n### Изменения путей импорта Go\n\nВ Helm 3 путь импорта Go изменился с `k8s.io/helm` на `helm.sh/helm/v3`. Если\nвы планируете перейти на клиентские библиотеки Go Helm 3, убедитесь, что\nизменили пути импорта.\n\n### Capabilities\n\nВстроенный объект `.Capabilities`, доступный на этапе рендеринга, был упрощён.\n\n[Встроенные объекты](/chart_template_guide/builtin_objects.md)\n\n### Валидация значений чарта с помощью JSONSchema\n\nТеперь к значениям чарта можно применить JSON Schema. Это гарантирует, что\nзначения, предоставленные пользователем, соответствуют схеме, определённой\nразработчиком чарта, обеспечивая лучшую отчётность об ошибках при\nпредоставлении некорректных значений.\n\nВалидация выполняется при вызове следующих команд:\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\nПодробнее см. в документации по [файлам схем](/topics/charts.md#schema-files).\n\n### Консолидация `requirements.yaml` в `Chart.yaml`\n\nСистема управления зависимостями чартов переехала из requirements.yaml и\nrequirements.lock в Chart.yaml и Chart.lock. Мы рекомендуем использовать новый\nформат для новых чартов, предназначенных для Helm 3. Однако Helm 3 по-прежнему\nпонимает Chart API версии 1 (`v1`) и загрузит существующие файлы\n`requirements.yaml`.\n\nВ Helm 2 `requirements.yaml` выглядел так:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nВ Helm 3 зависимость выражается так же, но теперь в вашем `Chart.yaml`:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nЧарты по-прежнему загружаются и помещаются в директорию `charts/`, поэтому\nподчарты, находящиеся в директории `charts/`, продолжат работать без изменений.\n\n### Имя (или --generate-name) теперь обязательно при установке\n\nВ Helm 2 при отсутствии имени автоматически генерировалось имя. На практике это\nоказалось скорее неудобством, чем полезной функцией. В Helm 3 Helm выдаст\nошибку, если имя не указано при `helm install`.\n\nДля тех, кто по-прежнему хочет автоматически сгенерированное имя, можно\nиспользовать флаг `--generate-name`.\n\n### Публикация чартов в OCI-реестры\n\nЭто экспериментальная функция, представленная в Helm 3. Для её использования\nустановите переменную окружения `HELM_EXPERIMENTAL_OCI=1`.\n\nНа высоком уровне репозиторий чартов — это место, где чарты могут храниться и\nраспространяться. Клиент Helm упаковывает и отправляет чарты в репозиторий.\nПроще говоря, репозиторий чартов — это базовый HTTP-сервер, содержащий файл\nindex.yaml и упакованные чарты.\n\nХотя API репозитория чартов удовлетворяет базовым требованиям к хранению, у\nнего есть ряд недостатков:\n\n- Репозиториям чартов очень сложно абстрагировать большинство реализаций\n  безопасности, необходимых в production-среде. Стандартный API для\n  аутентификации и авторизации очень важен в production-сценариях.\n- Инструменты Helm для подписи и проверки целостности и происхождения чарта\n  являются необязательной частью процесса публикации чарта.\n- В мультитенантных сценариях один и тот же чарт может быть загружен другим\n  арендатором, что удваивает затраты на хранение одного и того же содержимого.\n  Более продвинутые репозитории чартов были разработаны для решения этой\n  проблемы, но это не является частью формальной спецификации.\n- Использование одного индексного файла для поиска, информации о метаданных и\n  получения чартов затрудняет проектирование безопасных мультитенантных\n  реализаций.\n\nПроект Distribution от Docker (также известный как Docker Registry v2) является\nпреемником проекта Docker Registry. Многие крупные облачные провайдеры\nпредлагают продукты на основе проекта Distribution, и благодаря этому проект\nполучил многолетнюю закалку, лучшие практики безопасности и проверку в боевых\nусловиях.\n\nПодробнее о том, как упаковать чарт и отправить его в Docker-реестр, см. в\n`helm help chart` и `helm help registry`.\n\nДополнительная информация на [этой странице](/topics/registries.md).\n\n### Удаление `helm serve`\n\n`helm serve` запускал локальный репозиторий чартов на вашем компьютере для\nцелей разработки. Однако он не получил широкого распространения как инструмент\nразработки и имел множество проблем с архитектурой. В итоге мы решили удалить\nего и выделить в плагин.\n\nДля аналогичного опыта работы с `helm serve` обратите внимание на опцию\nлокального файлового хранилища в\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\nи [плагин servecm](https://github.com/jdolitsky/helm-servecm).\n\n### Поддержка библиотечных чартов\n\nHelm 3 поддерживает класс чартов, называемых «библиотечными чартами». Это чарты,\nкоторые используются другими чартами, но не создают собственных артефактов\nрелиза. Шаблоны библиотечного чарта могут объявлять только элементы `define`.\nГлобальный контент, не являющийся `define`, просто игнорируется. Это позволяет\nпользователям повторно использовать и делиться фрагментами кода, которые можно\nиспользовать в нескольких чартах, избегая избыточности и сохраняя чарты\n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nБиблиотечные чарты объявляются в директиве dependencies в Chart.yaml и\nустанавливаются и управляются как любой другой чарт.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nМы с нетерпением ждём сценариев использования, которые откроет эта функция для\nразработчиков чартов, а также лучших практик, возникающих при использовании\nбиблиотечных чартов.\n\n### Обновление apiVersion в Chart.yaml\n\nС появлением поддержки библиотечных чартов и консолидацией requirements.yaml в\nChart.yaml, клиенты, понимавшие формат пакетов Helm 2, не смогут понять эти\nновые функции. Поэтому мы изменили apiVersion в Chart.yaml с `v1` на `v2`.\n\n`helm create` теперь создаёт чарты с использованием нового формата, поэтому\napiVersion по умолчанию также был изменён.\n\nКлиенты, желающие поддерживать обе версии чартов Helm, должны проверять поле\n`apiVersion` в Chart.yaml, чтобы понять, как разбирать формат пакета.\n\n### Поддержка XDG Base Directory\n\n[Спецификация XDG Base\nDirectory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)\n— это переносимый стандарт, определяющий, где в файловой системе должны\nхраниться файлы конфигурации, данных и кэша.\n\nВ Helm 2 вся эта информация хранилась в `~/.helm` (известной как `helm home`),\nкоторую можно было изменить, установив переменную окружения `$HELM_HOME` или\nиспользуя глобальный флаг `--home`.\n\nВ Helm 3 Helm теперь использует следующие переменные окружения в соответствии\nсо спецификацией XDG Base Directory:\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nПлагинам Helm по-прежнему передаётся `$HELM_HOME` как псевдоним для\n`$XDG_DATA_HOME` для обратной совместимости с плагинами, использующими\n`$HELM_HOME` как рабочую директорию.\n\nДля адаптации к этому изменению в окружение плагина также передаются несколько\nновых переменных окружения:\n\n- `$HELM_PATH_CACHE` — путь к кэшу\n- `$HELM_PATH_CONFIG` — путь к конфигурации\n- `$HELM_PATH_DATA` — путь к данным\n\nПлагинам Helm, желающим поддерживать Helm 3, следует рассмотреть использование\nэтих новых переменных окружения.\n\n### Переименование команд CLI\n\nДля лучшего соответствия терминологии других пакетных менеджеров `helm delete`\nбыла переименована в `helm uninstall`. `helm delete` по-прежнему сохраняется\nкак псевдоним для `helm uninstall`, поэтому можно использовать любую форму.\n\nВ Helm 2 для очистки истории релиза необходимо было указать флаг `--purge`. Эта\nфункциональность теперь включена по умолчанию. Чтобы сохранить предыдущее\nповедение, используйте `helm uninstall --keep-history`.\n\nКроме того, несколько других команд были переименованы для соответствия тем же\nсоглашениям:\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\nЭти команды также сохранили свои старые названия как псевдонимы, поэтому вы\nможете продолжать использовать их в любой форме.\n\n### Автоматическое создание namespace\n\nПри создании релиза в несуществующем namespace Helm 2 создавал namespace. Helm 3\nследует поведению других инструментов Kubernetes и возвращает ошибку, если\nnamespace не существует. Helm 3 создаст namespace, если вы явно укажете флаг\n`--create-namespace`.\n\n### Что произошло с .Chart.ApiVersion?\n\nHelm следует типичному соглашению CamelCase, которое требует использования\nзаглавных букв в аббревиатурах. Мы применяли это в других частях кода, например,\nв `.Capabilities.APIVersions.Has`. В Helm v3 мы исправили `.Chart.ApiVersion`\nв соответствии с этим паттерном, переименовав его в `.Chart.APIVersion`.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/faq/index.mdx",
    "content": "---\ntitle: Часто задаваемые вопросы\nsidebar_position: 9\n---\n\n# Часто задаваемые вопросы\n\n> Этот раздел содержит ответы на наиболее распространённые вопросы.\n\n**Мы будем рады вашей помощи** в улучшении этого документа. Чтобы добавить, исправить или удалить\nинформацию, [создайте issue](https://github.com/helm/helm-www/issues) или отправьте нам\npull request.\n\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: Установка\nsidebar_position: 2\n---\n\n## Установка\n\n### Почему нет нативных пакетов Helm для Fedora и других дистрибутивов Linux?\n\nПроект Helm не поддерживает пакеты для операционных систем и окружений. Сообщество Helm может предоставлять нативные пакеты, и если проект узнает о них, они будут добавлены в список. Именно так появилась и была добавлена формула для Homebrew. Если вы заинтересованы в поддержке пакета, мы будем рады вашему участию.\n\n### Почему вы предоставляете скрипт `curl ...|bash`?\n\nВ нашем репозитории есть скрипт (`scripts/get-helm-3`), который можно выполнить как `curl ..|bash`. Все передачи данных защищены протоколом HTTPS, а скрипт выполняет проверку загружаемых пакетов. Тем не менее, он несёт все риски, характерные для любого shell-скрипта.\n\nМы предоставляем его, потому что он полезен, но рекомендуем пользователям внимательно изучить скрипт перед использованием. В идеале мы бы предпочли более качественные упакованные релизы Helm.\n\n### Как разместить файлы клиента Helm в месте, отличном от расположения по умолчанию?\n\nHelm использует структуру XDG для хранения файлов. Для изменения этих расположений вы можете использовать следующие переменные окружения:\n\n- `$XDG_CACHE_HOME`: альтернативное расположение для кэшированных файлов.\n- `$XDG_CONFIG_HOME`: альтернативное расположение для конфигурации Helm.\n- `$XDG_DATA_HOME`: альтернативное расположение для данных Helm.\n\nОбратите внимание: если у вас есть существующие репозитории, вам потребуется добавить их заново с помощью `helm repo add...`.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: Решение проблем\nsidebar_position: 4\n---\n\n## Решение проблем\n\n### Я получаю предупреждение «Unable to get an update from the \"stable\" chart repository»\n\nВыполните `helm repo list`. Если вы видите, что ваш репозиторий `stable` указывает на URL `storage.googleapis.com`, вам необходимо обновить этот репозиторий. 13 ноября 2020 года репозиторий Helm Charts [прекратил поддержку](https://github.com/helm/charts#deprecation-timeline) после годового периода устаревания. Архив доступен по адресу `https://charts.helm.sh/stable`, но больше не будет получать обновления.\n\nВы можете выполнить следующую команду для исправления репозитория:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update\n```\n\nТо же самое относится к репозиторию `incubator`, архив которого доступен по адресу https://charts.helm.sh/incubator. Вы можете выполнить следующую команду для его исправления:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update\n```\n\n### Я получаю предупреждение 'WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.'\n\nСтарый репозиторий чартов Google Helm был заменён новым репозиторием чартов Helm.\n\nВыполните следующую команду для окончательного решения этой проблемы:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update\n```\n\nЕсли вы получаете аналогичную ошибку для `incubator`, выполните эту команду:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update\n```\n\n### При добавлении репозитория Helm я получаю ошибку 'Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available'\n\nРепозитории 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`.\n\n### В GKE (Google Container Engine) я получаю ошибку «No SSH tunnels currently open»\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nДругой вариант сообщения об ошибке:\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nПроблема в том, что ваш локальный файл конфигурации Kubernetes должен содержать корректные учётные данные.\n\nПри создании кластера в GKE вы получаете учётные данные, включая SSL-сертификаты и центры сертификации. Они должны храниться в файле конфигурации Kubernetes (по умолчанию: `~/.kube/config`), чтобы `kubectl` и `helm` могли получить к ним доступ.\n\n### После миграции с Helm 2 команда `helm list` показывает только часть (или ни одного) моих релизов\n\nСкорее всего, вы упустили тот факт, что Helm 3 теперь использует пространства имён кластера для определения области видимости релизов. Это означает, что для всех команд, обращающихся к релизу, вы должны либо:\n\n* полагаться на текущее пространство имён в активном контексте Kubernetes (как показывает команда `kubectl config view --minify`),\n* указать корректное пространство имён с помощью флага `--namespace`/`-n`, или\n* для команды `helm list` указать флаг `--all-namespaces`/`-A`\n\nЭто относится к `helm ls`, `helm uninstall` и всем другим командам `helm`, которые обращаются к релизу.\n\n\n### В macOS происходит обращение к файлу `/etc/.mdns_debug`. Почему?\n\nНам известен случай в macOS, когда Helm пытается получить доступ к файлу `/etc/.mdns_debug`. Если файл существует, Helm удерживает дескриптор файла открытым во время выполнения.\n\nЭто вызвано библиотекой MDNS в macOS. Она пытается загрузить этот файл для чтения настроек отладки (если они включены). Дескриптор файла, вероятно, не должен удерживаться открытым, и об этой проблеме сообщено в Apple. Однако это поведение вызвано macOS, а не Helm.\n\nЕсли вы не хотите, чтобы Helm загружал этот файл, вы можете скомпилировать Helm как статическую библиотеку, которая не использует сетевой стек хоста. Это увеличит размер бинарного файла Helm, но предотвратит открытие файла.\n\nИзначально эта проблема была отмечена как потенциальная уязвимость безопасности. Однако позже было установлено, что данное поведение не вызывает никаких уязвимостей или недостатков.\n\n### helm repo add завершается ошибкой, хотя раньше работал\n\nВ Helm 3.3.1 и более ранних версиях команда `helm repo add <reponame> <url>` не выдавала никакого вывода при попытке добавить уже существующий репозиторий. Флаг `--no-update` вызывал ошибку, если репозиторий уже был зарегистрирован.\n\nВ Helm 3.3.2 и более поздних версиях попытка добавить существующий репозиторий вызовет ошибку:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nПоведение по умолчанию теперь изменено на противоположное. Флаг `--no-update` теперь игнорируется, а если вы хотите заменить (перезаписать) существующий репозиторий, используйте `--force-update`.\n\nЭто связано с критическим изменением для исправления уязвимости безопасности, как описано в [примечаниях к релизу Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2).\n\n### Включение логирования клиента Kubernetes\n\nВывод логов для отладки клиента Kubernetes можно включить с помощью флагов [klog](https://pkg.go.dev/k8s.io/klog). Использование флага `-v` для установки уровня подробности будет достаточно в большинстве случаев.\n\nНапример:\n\n```\nhelm list -v 6\n```\n\n### Установка Tiller перестала работать, и доступ запрещён\n\nРелизы Helm раньше были доступны по адресу <https://storage.googleapis.com/kubernetes-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.\n\nЕсли вы пытаетесь загрузить старые версии Helm из бакета хранилища, который использовали ранее, вы можете обнаружить, что они отсутствуют:\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\n[Устаревшее расположение образов Tiller](https://gcr.io/kubernetes-helm/tiller) начало удаление образов в августе 2021 года. Мы сделали эти образы доступными в [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Например, чтобы загрузить версию v2.17.0, замените:\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\nна:\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nДля инициализации с Helm v2.17.0:\n\n`helm init —upgrade`\n\nИли, если нужна другая версия, используйте флаг --tiller-image для переопределения расположения по умолчанию и установки определённой версии Helm v2:\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**Примечание:** Мейнтейнеры 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) уже сегодня.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: Удаление\nsidebar_position: 3\n---\n\n## Удаление\n\n### Я хочу удалить локальную установку Helm. Где находятся все его файлы?\n\nПомимо бинарного файла `helm`, Helm хранит файлы в следующих местах:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nВ следующей таблице приведены пути по умолчанию для каждой из этих директорий в зависимости от операционной системы:\n\n| Операционная система | Путь к кэшу                 | Путь к конфигурации              | Путь к данным             |\n|----------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux                | `$HOME/.cache/helm`         | `$HOME/.config/helm`             | `$HOME/.local/share/helm` |\n| macOS                | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm`      |\n| Windows              | `%TEMP%\\helm`               | `%APPDATA%\\helm`                 | `%APPDATA%\\helm`          |\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/glossary/index.mdx",
    "content": "---\ntitle: Глоссарий\ndescription: Термины, используемые для описания компонентов архитектуры Helm.\nsidebar_position: 10\n---\n\n# Глоссарий\n\n## Chart (Чарт)\n\nПакет Helm, содержащий информацию, достаточную для установки набора\nресурсов Kubernetes в кластер Kubernetes.\n\nЧарты содержат файл `Chart.yaml`, а также шаблоны, значения по умолчанию\n(`values.yaml`) и зависимости.\n\nЧарты разрабатываются в чётко определённой структуре каталогов, а затем упаковываются\nв архивный формат, называемый _архивом чарта_.\n\n## Chart Archive (Архив чарта)\n\n_Архив чарта_ — это упакованный в tar и сжатый gzip (и опционально подписанный) чарт.\n\n## Chart Dependency (Зависимость чарта, подчарты)\n\nЧарты могут зависеть от других чартов. Существует два способа возникновения зависимости:\n\n- Мягкая зависимость: чарт может просто не функционировать без установки другого чарта\n  в кластере. Helm не предоставляет инструментов для этого случая. В этом\n  случае зависимости управляются отдельно.\n- Жёсткая зависимость: чарт может содержать (внутри своего каталога `charts/`)\n  другой чарт, от которого он зависит. В этом случае установка чарта приведёт\n  к установке всех его зависимостей. В этом случае чарт и его зависимости\n  управляются как единое целое.\n\nКогда чарт упаковывается (с помощью `helm package`), все его жёсткие зависимости\nвключаются в пакет.\n\n## Chart Version (Версия чарта)\n\nЧарты версионируются в соответствии со [спецификацией SemVer 2](https://semver.org). Номер\nверсии обязателен для каждого чарта.\n\n## Chart.yaml\n\nИнформация о чарте хранится в специальном файле `Chart.yaml`. Каждый\nчарт должен иметь этот файл.\n\n## Helm (и helm)\n\nHelm — это менеджер пакетов для Kubernetes. Подобно тому, как менеджер пакетов\nоперационной системы упрощает установку инструментов в ОС, Helm упрощает установку\nприложений и ресурсов в кластеры Kubernetes.\n\nХотя _Helm_ — это название проекта, клиент командной строки также называется\n`helm`. По соглашению, когда речь идёт о проекте, _Helm_ пишется с заглавной буквы. Когда\nречь идёт о клиенте, _helm_ пишется строчными буквами.\n\n## Helm Configuration Files (Файлы конфигурации Helm, XDG)\n\nHelm хранит свои файлы конфигурации в каталогах XDG. Эти каталоги\nсоздаются при первом запуске `helm`.\n\n## Kube Config (KUBECONFIG)\n\nКлиент Helm получает информацию о кластерах Kubernetes с помощью файлов в формате _Kube\nconfig_. По умолчанию Helm пытается найти этот файл в том месте,\nгде `kubectl` его создаёт (`$HOME/.kube/config`).\n\n## Lint (Линтинг)\n\n_Линтинг_ чарта — это проверка того, что он соответствует соглашениям и\nтребованиям стандарта чартов Helm. Helm предоставляет для этого инструменты, в частности\nкоманду `helm lint`.\n\n## Provenance (Файл происхождения)\n\nЧарты Helm могут сопровождаться _файлом происхождения_, который предоставляет информацию\nо том, откуда взялся чарт и что он содержит.\n\nФайлы происхождения являются частью модели безопасности Helm. Файл происхождения содержит\nкриптографический хеш файла архива чарта, данные Chart.yaml и\nблок подписи (блок OpenPGP \"clearsign\"). При наличии связки ключей\nэто даёт пользователям чарта возможность:\n\n- Проверить, что чарт был подписан доверенной стороной\n- Проверить, что файл чарта не был изменён\n- Проверить содержимое метаданных чарта (`Chart.yaml`)\n- Быстро сопоставить чарт с его данными происхождения\n\nФайлы происхождения имеют расширение `.prov` и могут размещаться на сервере\nрепозитория чартов или любом другом HTTP-сервере.\n\n## Release (Релиз)\n\nКогда чарт устанавливается, библиотека Helm создаёт _релиз_ для отслеживания этой\nустановки.\n\nОдин чарт может быть установлен много раз в один и тот же кластер и создавать\nмножество разных релизов. Например, можно установить три базы данных PostgreSQL,\nвыполнив `helm install` три раза с разными именами релизов.\n\n## Release Number (Номер релиза, версия релиза)\n\nОдин релиз может быть обновлён несколько раз. Последовательный счётчик используется для\nотслеживания релизов по мере их изменения. После первого `helm install` релиз будет иметь\n_номер релиза_ 1. Каждый раз при обновлении или откате релиза номер релиза\nбудет увеличиваться.\n\n## Rollback (Откат)\n\nРелиз может быть обновлён до более нового чарта или конфигурации. Но поскольку история релизов\nсохраняется, релиз также может быть _откачен_ к предыдущему номеру релиза.\nЭто делается командой `helm rollback`.\n\nВажно отметить, что откаченный релиз получит новый номер релиза.\n\n| Операция   | Номер релиза                                              |\n|------------|-----------------------------------------------------------|\n| install    | релиз 1                                                   |\n| upgrade    | релиз 2                                                   |\n| upgrade    | релиз 3                                                   |\n| rollback 1 | релиз 4 (но с той же конфигурацией, что и релиз 1)        |\n\nПриведённая выше таблица иллюстрирует, как номера релизов увеличиваются при установке,\nобновлении и откате.\n\n## Helm Library (Библиотека Helm, или SDK)\n\nБиблиотека Helm (или SDK) относится к коду Go, который напрямую взаимодействует с\nAPI-сервером Kubernetes для установки, обновления, запроса и удаления ресурсов Kubernetes.\nОна может быть импортирована в проект для использования Helm как клиентской библиотеки\nвместо CLI.\n\n## Repository (Репозиторий, Repo, репозиторий чартов)\n\nЧарты Helm могут храниться на выделенных HTTP-серверах, называемых _репозиториями чартов_\n(_репозиториями_ или просто _repo_).\n\nСервер репозитория чартов — это простой HTTP-сервер, который может отдавать файл `index.yaml`,\nописывающий набор чартов и предоставляющий информацию о том, откуда можно скачать каждый\nчарт. (Многие репозитории чартов также предоставляют сами чарты вместе с файлом `index.yaml`.)\n\nКлиент Helm может указывать на ноль или более репозиториев чартов. По умолчанию клиенты Helm\nне настроены ни на один репозиторий чартов. Репозитории чартов могут быть добавлены\nв любое время с помощью команды `helm repo add`.\n\n## Chart Registry (Реестр чартов, реестр на основе OCI)\n\nРеестр чартов Helm — это система хранения и распространения на основе [OCI](https://opencontainers.org/about/overview/), которая используется для размещения и распространения пакетов чартов Helm. Дополнительную информацию см. в [документации Helm по реестрам](https://helm.sh/docs/topics/registries/).\n\n## Values (Значения, файлы значений, values.yaml)\n\nЗначения позволяют переопределять значения по умолчанию из шаблонов вашей собственной информацией.\n\nЧарты Helm являются «параметризованными», что означает, что разработчик чарта может предоставить\nконфигурацию, которую можно переопределить во время установки. Например, чарт\nможет предоставлять поле `username`, позволяющее задать имя пользователя для сервиса.\n\nЭти предоставляемые переменные называются _значениями_ в терминологии Helm.\n\nЗначения можно задавать во время операций `helm install` и `helm upgrade`, либо\nпередавая их напрямую, либо используя файл `values.yaml`.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\nПакетный менеджер Helm для Kubernetes.\n\n### Краткое описание\n\nПакетный менеджер для Kubernetes\n\nОсновные действия в Helm:\n\n- helm search:    поиск чартов\n- helm pull:      загрузка чарта в локальную директорию для просмотра\n- helm install:   установка чарта в Kubernetes\n- helm list:      вывод списка релизов чартов\n\nПеременные окружения:\n\n| Имя                                | Описание                                                                                                   |\n|------------------------------------|------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | альтернативное расположение для хранения кэшированных файлов.                                              |\n| $HELM_CONFIG_HOME                  | альтернативное расположение для хранения конфигурации Helm.                                                |\n| $HELM_DATA_HOME                    | альтернативное расположение для хранения данных Helm.                                                      |\n| $HELM_DEBUG                        | указывает, запущен ли Helm в режиме отладки                                                                |\n| $HELM_DRIVER                       | драйвер хранилища. Возможные значения: configmap, secret, memory, sql.                                     |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | строка подключения для SQL-драйвера хранилища.                                                             |\n| $HELM_MAX_HISTORY                  | максимальное количество записей в истории релизов helm.                                                    |\n| $HELM_NAMESPACE                    | пространство имён для операций helm.                                                                       |\n| $HELM_NO_PLUGINS                   | отключение плагинов. Установите HELM_NO_PLUGINS=1 для отключения.                                          |\n| $HELM_PLUGINS                      | путь к директории с плагинами                                                                              |\n| $HELM_REGISTRY_CONFIG              | путь к файлу конфигурации реестра.                                                                         |\n| $HELM_REPOSITORY_CACHE             | путь к директории с кэшем репозиториев                                                                     |\n| $HELM_REPOSITORY_CONFIG            | путь к файлу с репозиториями.                                                                              |\n| $KUBECONFIG                        | альтернативный файл конфигурации Kubernetes (по умолчанию \"~/.kube/config\")                                |\n| $HELM_KUBEAPISERVER                | адрес сервера API Kubernetes для аутентификации                                                            |\n| $HELM_KUBECAFILE                   | файл центра сертификации Kubernetes.                                                                       |\n| $HELM_KUBEASGROUPS                 | группы для имперсонации, через запятую.                                                                    |\n| $HELM_KUBEASUSER                   | имя пользователя для имперсонации.                                                                         |\n| $HELM_KUBECONTEXT                  | имя контекста kubeconfig.                                                                                  |\n| $HELM_KUBETOKEN                    | Bearer-токен для аутентификации.                                                                           |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | указывает, следует ли пропустить проверку сертификата сервера API Kubernetes (небезопасно)                 |\n| $HELM_KUBETLS_SERVER_NAME          | имя сервера для проверки сертификата сервера API Kubernetes                                                |\n| $HELM_BURST_LIMIT                  | лимит burst по умолчанию при большом количестве CRD на сервере (по умолчанию 100, -1 для отключения)       |\n| $HELM_QPS                          | количество запросов в секунду при большом числе вызовов, превышающих лимит burst                           |\n\nHelm хранит кэш, конфигурацию и данные в соответствии со следующим порядком приоритета:\n\n- Если установлена переменная окружения HELM_*_HOME, она будет использоваться\n- Иначе, в системах, поддерживающих спецификацию XDG base directory, используются переменные XDG\n- Если другое расположение не задано, используется расположение по умолчанию для операционной системы\n\nПо умолчанию директории зависят от операционной системы. Значения по умолчанию приведены ниже:\n\n| Операционная система | Путь к кэшу               | Путь к конфигурации            | Путь к данным             |\n|----------------------|---------------------------|--------------------------------|---------------------------|\n| Linux                | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm   |\n| macOS                | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm        |\n| Windows              | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm            |\n\n\n### Опции\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n  -h, --help                            help for helm\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### СМ. ТАКЖЕ\n\n* [helm completion](/helm/helm_completion.md)\t - генерация скриптов автодополнения для указанной оболочки\n* [helm create](/helm/helm_create.md)\t - создание нового чарта с указанным именем\n* [helm dependency](/helm/helm_dependency.md)\t - управление зависимостями чарта\n* [helm env](/helm/helm_env.md)\t - информация об окружении клиента helm\n* [helm get](/helm/helm_get.md)\t - получение расширенной информации об именованном релизе\n* [helm history](/helm/helm_history.md)\t - получение истории релиза\n* [helm install](/helm/helm_install.md)\t - установка чарта\n* [helm lint](/helm/helm_lint.md)\t - проверка чарта на возможные проблемы\n* [helm list](/helm/helm_list.md)\t - вывод списка релизов\n* [helm package](/helm/helm_package.md)\t - упаковка директории чарта в архив чарта\n* [helm plugin](/helm/helm_plugin.md)\t - установка, вывод списка или удаление плагинов Helm\n* [helm pull](/helm/helm_pull.md)\t - загрузка чарта из репозитория и (опционально) распаковка в локальную директорию\n* [helm push](/helm/helm_push.md)\t - отправка чарта на удалённый сервер\n* [helm registry](/helm/helm_registry.md)\t - вход или выход из реестра\n* [helm repo](/helm/helm_repo.md)\t - добавление, вывод списка, удаление, обновление и индексация репозиториев чартов\n* [helm rollback](/helm/helm_rollback.md)\t - откат релиза к предыдущей ревизии\n* [helm search](/helm/helm_search.md)\t - поиск по ключевому слову в чартах\n* [helm show](/helm/helm_show.md)\t - показ информации о чарте\n* [helm status](/helm/helm_status.md)\t - отображение статуса именованного релиза\n* [helm template](/helm/helm_template.md)\t - локальный рендеринг шаблонов\n* [helm test](/helm/helm_test.md)\t - запуск тестов для релиза\n* [helm uninstall](/helm/helm_uninstall.md)\t - удаление релиза\n* [helm upgrade](/helm/helm_upgrade.md)\t - обновление релиза\n* [helm verify](/helm/helm_verify.md)\t - проверка подписи и валидности чарта по указанному пути\n* [helm version](/helm/helm_version.md)\t - вывод информации о версии клиента\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\nгенерация скриптов автодополнения для указанной оболочки\n\n### Краткое описание\n\n\nГенерирует скрипты автодополнения Helm для указанной оболочки.\n\n\n### Опции\n\n```\n  -h, --help   help for completion\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes.\n* [helm completion bash](./helm_completion_bash.md)\t - генерация скрипта автодополнения для bash\n* [helm completion fish](./helm_completion_fish.md)\t - генерация скрипта автодополнения для fish\n* [helm completion powershell](./helm_completion_powershell.md)\t - генерация скрипта автодополнения для powershell\n* [helm completion zsh](./helm_completion_zsh.md)\t - генерация скрипта автодополнения для zsh\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\nгенерация скрипта автодополнения для bash\n\n### Краткое описание\n\n\nГенерирует скрипт автодополнения Helm для оболочки bash.\n\nДля загрузки автодополнения в текущей сессии:\n\n    source <(helm completion bash)\n\nДля загрузки автодополнения во всех новых сессиях выполните однократно:\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n\n```\nhelm completion bash [flags]\n```\n\n### Опции\n\n```\n  -h, --help              help for bash\n      --no-descriptions   disable completion descriptions\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm completion](./helm_completion.md)\t - генерация скриптов автодополнения для указанной оболочки\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\nгенерация скрипта автодополнения для fish\n\n### Краткое описание\n\n\nГенерирует скрипт автодополнения Helm для оболочки fish.\n\nДля загрузки автодополнения в текущей сессии:\n\n    helm completion fish | source\n\nДля загрузки автодополнения во всех новых сессиях выполните однократно:\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\nЧтобы изменения вступили в силу, необходимо перезапустить оболочку.\n\n\n```\nhelm completion fish [flags]\n```\n\n### Опции\n\n```\n  -h, --help              help for fish\n      --no-descriptions   disable completion descriptions\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm completion](./helm_completion.md)\t - генерация скриптов автодополнения для указанной оболочки\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\nгенерация скрипта автодополнения для powershell\n\n### Краткое описание\n\n\nГенерирует скрипт автодополнения Helm для оболочки powershell.\n\nДля загрузки автодополнения в текущей сессии выполните:\n\n    PS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\nДля загрузки автодополнения во всех новых сессиях добавьте вывод указанной выше команды в ваш профиль powershell.\n\n\n```\nhelm completion powershell [flags]\n```\n\n### Опции\n\n```\n  -h, --help              help for powershell\n      --no-descriptions   disable completion descriptions\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm completion](./helm_completion.md)\t - генерация скриптов автодополнения для указанной оболочки\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\nгенерация скрипта автодополнения для zsh\n\n### Краткое описание\n\n\nГенерирует скрипт автодополнения Helm для оболочки zsh.\n\nДля загрузки автодополнения в текущей сессии:\n\n    source <(helm completion zsh)\n\nДля загрузки автодополнения во всех новых сессиях выполните однократно:\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### Опции\n\n```\n  -h, --help              help for zsh\n      --no-descriptions   disable completion descriptions\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm completion](./helm_completion.md)\t - генерация скриптов автодополнения для указанной оболочки\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n\nсоздание нового чарта с указанным именем\n\n### Краткое описание\n\n\nЭта команда создаёт директорию чарта вместе со стандартными файлами и\nдиректориями, используемыми в чарте.\n\nНапример, 'helm create foo' создаст структуру директорий, которая\nвыглядит примерно так:\n\n    foo/\n    ├── .helmignore   # Шаблоны для игнорирования при упаковке чартов Helm\n    ├── Chart.yaml    # Информация о вашем чарте\n    ├── values.yaml   # Значения по умолчанию для ваших шаблонов\n    ├── charts/       # Чарты, от которых зависит данный чарт\n    └── templates/    # Файлы шаблонов\n        └── tests/    # Файлы тестов\n\n'helm create' принимает путь в качестве аргумента. Если директории в указанном пути\nне существуют, Helm попытается создать их. Если указанная\nдиректория уже существует и в ней есть файлы, конфликтующие файлы\nбудут перезаписаны, но остальные файлы останутся нетронутыми.\n\n\n```\nhelm create NAME [flags]\n```\n\n### Опции\n\n```\n  -h, --help             help for create\n  -p, --starter string   the name or absolute path to Helm starter scaffold\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\nуправление зависимостями чарта\n\n### Краткое описание\n\n\nУправление зависимостями чарта.\n\nЧарты Helm хранят свои зависимости в каталоге 'charts/'. Для разработчиков чартов\nчасто удобнее управлять зависимостями в файле 'Chart.yaml', в котором объявляются\nвсе зависимости.\n\nКоманды для работы с зависимостями оперируют этим файлом, упрощая синхронизацию\nмежду желаемым и фактическим состоянием зависимостей в каталоге 'charts/'.\n\nНапример, этот Chart.yaml объявляет две зависимости:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\nПоле 'name' должно содержать имя чарта, которое должно совпадать с именем\nв файле 'Chart.yaml' соответствующего чарта.\n\nПоле 'version' должно содержать семантическую версию или диапазон версий.\n\nURL в поле 'repository' должен указывать на репозиторий чартов. Helm ожидает,\nчто при добавлении '/index.yaml' к URL он сможет получить индекс репозитория\nчартов. Примечание: 'repository' может быть псевдонимом. Псевдоним должен\nначинаться с 'alias:' или '@'.\n\nНачиная с версии 2.2.0, в качестве репозитория можно указать путь к локальному\nкаталогу, содержащему зависимые чарты. Путь должен начинаться с префикса\n\"file://\". Например:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\nПри использовании локального чарта добавление репозитория через команду\n\"helm add repo\" не требуется. Сопоставление версий также поддерживается\nв этом случае.\n\n\n### Параметры\n\n```\n  -h, --help   help for dependency\n```\n\n### Параметры, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](/helm/helm.md)\t — менеджер пакетов Helm для Kubernetes.\n* [helm dependency build](/helm/helm_dependency_build.md)\t — пересборка каталога charts/ на основе файла Chart.lock\n* [helm dependency list](/helm/helm_dependency_list.md)\t — просмотр списка зависимостей указанного чарта\n* [helm dependency update](/helm/helm_dependency_update.md)\t — обновление каталога charts/ на основе содержимого Chart.yaml\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\nпересборка каталога charts/ на основе файла Chart.lock\n\n### Краткое описание\n\nСобирает каталог charts/ из файла Chart.lock.\n\nКоманда build используется для восстановления зависимостей чарта в состояние,\nуказанное в lock-файле. В отличие от 'helm dependency update', эта команда\nне пересогласовывает зависимости.\n\nЕсли lock-файл не найден, 'helm dependency build' будет работать аналогично\n'helm dependency update'.\n\n\n```\nhelm dependency build CHART [flags]\n```\n\n### Параметры\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for build\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Параметры, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm dependency](/helm/helm_dependency.md) — управление зависимостями чарта\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\nвывод списка зависимостей для указанного чарта\n\n### Краткое описание\n\nВыводит все зависимости, объявленные в чарте.\n\nКоманда принимает на вход как архивы чартов, так и каталоги с чартами.\nСодержимое чарта не изменяется.\n\nЕсли чарт не удаётся загрузить, команда завершится с ошибкой.\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### Параметры\n\n```\n  -h, --help                 help for list\n      --max-col-width uint   maximum column width for output table (default 80)\n```\n\n### Параметры, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm dependency](/helm/helm_dependency.md) — управление зависимостями чарта\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\nобновление каталога charts/ на основе содержимого Chart.yaml\n\n### Краткое описание\n\nОбновляет зависимости на диске в соответствии с Chart.yaml.\n\nЭта команда проверяет, что необходимые чарты, указанные в 'Chart.yaml',\nприсутствуют в каталоге 'charts/' и имеют допустимую версию. Команда загружает\nпоследние версии чартов, соответствующих требованиям зависимостей, и удаляет устаревшие зависимости.\n\nПри успешном обновлении создаётся lock-файл, который можно использовать для\nвосстановления зависимостей до точной версии.\n\nЧарты в каталоге charts/ не обязательно должны быть объявлены в 'Chart.yaml'. Поэтому\nкоманда обновления удалит чарт только в том случае, если он (a) указан\nв файле Chart.yaml, но (b) имеет неправильную версию.\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### Параметры\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for update\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Параметры, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm dependency](/helm/helm_dependency.md) — управление зависимостями чарта\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\nинформация об окружении клиента Helm\n\n### Краткое описание\n\n\nКоманда env выводит всю информацию об окружении, используемом Helm.\n\n\n```\nhelm env [flags]\n```\n\n### Опции\n\n```\n  -h, --help   help for env\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\nполучение расширенной информации об указанном релизе\n\n### Краткое описание\n\n\nЭта команда состоит из нескольких подкоманд, которые можно использовать\nдля получения расширенной информации о релизе, включая:\n\n- Значения, использованные для создания релиза\n- Сгенерированный файл манифеста\n- Заметки чарта релиза\n- Хуки, связанные с релизом\n- Метаданные релиза\n\n\n### Опции\n\n```\n  -h, --help   help for get\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes\n* [helm get all](./helm_get_all.md)\t - получение всей информации об указанном релизе\n* [helm get hooks](./helm_get_hooks.md)\t - получение всех хуков для указанного релиза\n* [helm get manifest](./helm_get_manifest.md)\t - получение манифеста для указанного релиза\n* [helm get metadata](./helm_get_metadata.md)\t - получение метаданных для указанного релиза\n* [helm get notes](./helm_get_notes.md)\t - получение заметок для указанного релиза\n* [helm get values](./helm_get_values.md)\t - получение файла values для указанного релиза\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\nполучение всей информации об указанном релизе\n\n### Краткое описание\n\nЭта команда выводит удобочитаемую сводку информации об указанном релизе, включая\nзаметки, хуки, переданные значения и сгенерированный манифест.\n\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### Опции\n\n```\n  -h, --help              help for all\n      --revision int      get the named release with revision\n      --template string   go template for formatting the output, eg: {{.Release.Name}}\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm get](./helm_get.md)\t - получение расширенной информации об указанном релизе\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\nполучение всех хуков для указанного релиза\n\n### Краткое описание\n\nЭта команда получает хуки для указанного релиза.\n\nХуки представлены в формате YAML и разделены стандартным YAML-разделителем '---\\n'.\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Опции\n\n```\n  -h, --help           help for hooks\n      --revision int   get the named release with revision\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm get](./helm_get.md)\t - получение расширенной информации об указанном релизе\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\nполучение манифеста для указанного релиза\n\n### Краткое описание\n\nЭта команда получает сгенерированный манифест для указанного релиза.\n\nМанифест представляет собой YAML-описание ресурсов Kubernetes, сгенерированных из чартов данного релиза. Если чарт зависит от других чартов, их ресурсы также будут включены в манифест.\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### Опции\n\n```\n  -h, --help           help for manifest\n      --revision int   get the named release with revision\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm get](./helm_get.md)\t - получение расширенной информации об указанном релизе\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\nполучение метаданных для указанного релиза\n\nЭта команда получает метаданные для указанного релиза.\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### Опции\n\n```\n  -h, --help            help for metadata\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    specify release revision\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm get](./helm_get.md)\t - получение расширенной информации об указанном релизе\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\nполучение примечаний для указанного релиза\n\n### Краткое описание\n\nЭта команда показывает примечания, предоставленные чартом для указанного релиза.\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### Опции\n\n```\n  -h, --help           help for notes\n      --revision int   get the named release with revision\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm get](./helm_get.md)\t - получение расширенной информации об указанном релизе\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\nполучение файла values для указанного релиза\n\n### Краткое описание\n\nЭта команда получает файл values для указанного релиза.\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### Опции\n\n```\n  -a, --all             dump all (computed) values\n  -h, --help            help for values\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    get the named release with revision\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm get](./helm_get.md)\t - получение расширенной информации об указанном релизе\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\nвывод истории релиза\n\n### Краткое описание\n\nЭта команда выводит историю ревизий для указанного релиза.\n\nПо умолчанию возвращается не более 256 ревизий. Флаг '--max' позволяет\nнастроить максимальную длину возвращаемого списка ревизий.\n\nИстория релиза выводится в виде форматированной таблицы, например:\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### Опции\n\n```\n  -h, --help            help for history\n      --max int         maximum number of revision to include in history (default 256)\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\nустановка чарта\n\n### Краткое описание\n\nЭта команда устанавливает чарт.\n\nАргументом команды install должна быть ссылка на чарт, путь к упакованному чарту,\nпуть к директории с распакованным чартом или URL-адрес.\n\nЧтобы переопределить значения в чарте, используйте флаг '--values' и передайте файл\nили используйте флаг '--set' для передачи конфигурации из командной строки. Для принудительного\nзадания строковых значений используйте '--set-string'. Флаг '--set-file' позволяет задавать\nотдельные значения из файла, когда значение слишком длинное для командной строки\nили генерируется динамически. Также можно использовать '--set-json' для задания JSON-значений\n(скаляров/объектов/массивов) из командной строки.\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\nили\n\n    $ helm install --set name=prod myredis ./redis\n\nили\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\nили\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\nили\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\nФлаг '--values'/'-f' можно указывать несколько раз. Приоритет отдаётся\nпоследнему (самому правому) указанному файлу. Например, если оба файла myvalues.yaml и override.yaml\nсодержат ключ 'Test', значение из override.yaml будет иметь приоритет:\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\nФлаг '--set' можно указывать несколько раз. Приоритет отдаётся\nпоследнему (самому правому) указанному значению. Например, если для ключа 'foo'\nзаданы значения 'bar' и 'newbar', значение 'newbar' будет иметь приоритет:\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\nАналогично, в следующем примере 'foo' принимает значение '[\"four\"]':\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\nА в следующем примере 'foo' принимает значение '{\"key1\":\"value1\",\"key2\":\"bar\"}':\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\nЧтобы проверить сгенерированные манифесты релиза без фактической установки чарта,\nможно комбинировать флаги --debug и --dry-run.\n\nФлаг --dry-run выведет все сгенерированные манифесты чарта, включая Secrets,\nкоторые могут содержать конфиденциальные данные. Чтобы скрыть Kubernetes Secrets,\nиспользуйте флаг --hide-secret. Используйте эти флаги с осторожностью.\n\nЕсли указан флаг --verify, чарт ДОЛЖЕН иметь файл происхождения (provenance),\nи этот файл ДОЛЖЕН пройти все проверки.\n\nСуществует шесть различных способов указать чарт для установки:\n\n1. По ссылке на чарт: helm install mymaria example/mariadb\n2. По пути к упакованному чарту: helm install mynginx ./nginx-1.2.3.tgz\n3. По пути к директории с распакованным чартом: helm install mynginx ./nginx\n4. По абсолютному URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. По ссылке на чарт и URL репозитория: helm install --repo https://example.com/charts/ mynginx nginx\n6. Через OCI-реестры: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\nССЫЛКИ НА ЧАРТЫ\n\nСсылка на чарт — это удобный способ обращения к чарту в репозитории чартов.\n\nПри использовании ссылки на чарт с префиксом репозитория ('example/mariadb'), Helm ищет\nв локальной конфигурации репозиторий чартов с именем 'example', а затем ищет\nв этом репозитории чарт с именем 'mariadb'. Будет установлена последняя стабильная версия чарта,\nесли не указан флаг '--devel' для включения версий в разработке (alpha, beta и release candidate),\nили если не указана конкретная версия с помощью флага '--version'.\n\nДля просмотра списка репозиториев чартов используйте 'helm repo list'. Для поиска\nчартов в репозитории используйте 'helm search'.\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### Опции\n\n```\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for install\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\nпроверка чарта на наличие возможных проблем\n\n### Краткое описание\n\nЭта команда принимает путь к чарту и запускает серию тестов, чтобы проверить,\nчто чарт правильно сформирован.\n\nЕсли линтер обнаруживает проблемы, которые помешают установке чарта,\nон выводит сообщения [ERROR]. При обнаружении отклонений от соглашений\nили рекомендаций выводятся сообщения [WARNING].\n\n\n```\nhelm lint PATH [flags]\n```\n\n### Опции\n\n```\n  -h, --help                      help for lint\n      --kube-version string       Kubernetes version used for capabilities and deprecation checks\n      --quiet                     print only warnings and errors\n      --set stringArray           set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray      set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray   set a literal STRING value on the command line\n      --set-string stringArray    set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-schema-validation    if set, disables JSON schema validation\n      --strict                    fail on lint warnings\n  -f, --values strings            specify values in a YAML file or a URL (can specify multiple)\n      --with-subcharts            lint dependent charts\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](/helm/helm.md)\t - менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\nвывод списка релизов\n\n### Краткое описание\n\nЭта команда выводит список всех релизов для указанного namespace (если namespace не указан, используется текущий контекст kubeconfig).\n\nПо умолчанию выводятся только релизы со статусом deployed или failed. Флаги\n'--uninstalled' и '--all' изменяют это поведение. Эти флаги можно комбинировать:\n'--uninstalled --failed'.\n\nПо умолчанию элементы сортируются в алфавитном порядке. Используйте флаг '-d'\nдля сортировки по дате релиза.\n\nЕсли указан флаг --filter, его значение будет использоваться как фильтр. Фильтры —\nэто регулярные выражения (Perl-совместимые), которые применяются к списку релизов.\nБудут возвращены только элементы, соответствующие фильтру.\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\nЕсли результаты не найдены, 'helm list' завершится с кодом 0, но без вывода\n(или, если флаг '-q' не указан, только с заголовками).\n\nПо умолчанию возвращается не более 256 элементов. Чтобы изменить лимит,\nиспользуйте флаг '--max'. Установка '--max' в 0 не вернёт все результаты. Вместо\nэтого будет использовано значение по умолчанию сервера, которое может быть\nзначительно больше 256. Комбинация флагов '--max' и '--offset' позволяет\nосуществлять постраничный вывод результатов.\n\n\n```\nhelm list [flags]\n```\n\n### Опции\n\n```\n  -a, --all                  show all releases without any filter applied\n  -A, --all-namespaces       list releases across all namespaces\n  -d, --date                 sort by release date\n      --deployed             show deployed releases. If no other is specified, this will be automatically enabled\n      --failed               show failed releases\n  -f, --filter string        a regular expression (Perl compatible). Any releases that match the expression will be included in the results\n  -h, --help                 help for list\n  -m, --max int              maximum number of releases to fetch (default 256)\n      --no-headers           don't print headers when using the default output format\n      --offset int           next release index in the list, used to offset from start value\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pending              show pending releases\n  -r, --reverse              reverse the sort order\n  -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.\n  -q, --short                output short (quiet) listing format\n      --superseded           show superseded releases\n      --time-format string   format time using golang time formatter. Example: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          show uninstalled releases (if 'helm uninstall --keep-history' was used)\n      --uninstalling         show releases that are currently being uninstalled\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\nупаковка директории чарта в архив чарта\n\n### Краткое описание\n\n\nЭта команда упаковывает чарт в версионированный архивный файл чарта. Если\nуказан путь, команда будет искать чарт по этому пути (который должен содержать\nфайл Chart.yaml) и затем упакует эту директорию.\n\nВерсионированные архивы чартов используются репозиториями пакетов Helm.\n\nДля подписи чарта используйте флаг '--sign'. В большинстве случаев вам также\nследует указать '--keyring path/to/secret/keys' и '--key keyname'.\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\nЕсли '--keyring' не указан, Helm обычно использует публичное хранилище ключей,\nесли ваше окружение не настроено иначе.\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Опции\n\n```\n      --app-version string         set the appVersion on the chart to this version\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -u, --dependency-update          update dependencies from \"Chart.yaml\" to dir \"charts/\" before packaging\n  -d, --destination string         location to write the chart. (default \".\")\n  -h, --help                       help for package\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key string                 name of the key to use when signing. Used if --sign is true\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of a public keyring (default \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     location of a file which contains the passphrase for the signing key. Use \"-\" in order to read from stdin.\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --sign                       use a PGP private key to sign this package\n      --username string            chart repository username where to locate the requested chart\n      --version string             set the version on the chart to this semver version\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\nустановка, просмотр и удаление плагинов Helm\n\n### Краткое описание\n\nУправление клиентскими плагинами Helm.\n\n\n### Опции\n\n```\n  -h, --help   help for plugin\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes.\n* [helm plugin install](./helm_plugin_install.md)\t - установка плагина Helm\n* [helm plugin list](./helm_plugin_list.md)\t - просмотр списка установленных плагинов Helm\n* [helm plugin uninstall](./helm_plugin_uninstall.md)\t - удаление одного или нескольких плагинов Helm\n* [helm plugin update](./helm_plugin_update.md)\t - обновление одного или нескольких плагинов Helm\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\nустановка плагина Helm\n\nЭта команда позволяет установить плагин по URL VCS-репозитория или по локальному пути.\n\n```\nhelm plugin install [options] <path|url> [flags]\n```\n\n### Опции\n\n```\n  -h, --help             help for install\n      --version string   specify a version constraint. If this is not specified, the latest version is installed\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm plugin](./helm_plugin.md)\t - установка, просмотр и удаление плагинов Helm\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\nпросмотр установленных плагинов Helm\n\n```\nhelm plugin list [flags]\n```\n\n### Опции\n\n```\n  -h, --help   help for list\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm plugin](./helm_plugin.md)\t - установка, просмотр и удаление плагинов Helm\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\nудаление одного или нескольких плагинов Helm\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Опции\n\n```\n  -h, --help   help for uninstall\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm plugin](./helm_plugin.md)\t - установка, просмотр и удаление плагинов Helm\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\nобновление одного или нескольких плагинов Helm\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### Опции\n\n```\n  -h, --help   help for update\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm plugin](./helm_plugin.md)\t - установка, просмотр и удаление плагинов Helm\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\nскачивание чарта из репозитория с возможностью локальной распаковки\n\n### Краткое описание\n\n\nЗагружает пакет из репозитория пакетов и сохраняет его локально.\n\nПолезно для получения пакетов, чтобы изучить, изменить или перепаковать их.\nТакже позволяет выполнить криптографическую проверку чарта без его установки.\n\nЕсть опции для распаковки чарта после загрузки. При этом создаётся директория\nдля чарта, в которую он распаковывается.\n\nЕсли указан флаг --verify, запрашиваемый чарт ДОЛЖЕН иметь файл provenance\nи ДОЛЖЕН пройти проверку. Любая ошибка приведёт к прерыванию операции,\nи чарт не будет сохранён локально.\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### Опции\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -d, --destination string         location to write the chart. If this and untardir are specified, untardir is appended to this (default \".\")\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help                       help for pull\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --prov                       fetch the provenance file, but don't perform verification\n      --repo string                chart repository url where to locate the requested chart\n      --untar                      if set to true, will untar the chart after downloading it\n      --untardir string            if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default \".\")\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\nотправка чарта в реестр\n\n### Краткое описание\n\n\nЗагружает чарт в реестр.\n\nЕсли у чарта есть связанный файл provenance,\nон также будет загружен.\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### Опции\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify registry client using this SSL certificate file\n  -h, --help                       help for push\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart upload\n      --key-file string            identify registry client using this SSL key file\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart upload\n      --username string            chart repository username where to locate the requested chart\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\nвход в реестр или выход из реестра\n\n### Краткое описание\n\nЭта команда включает несколько подкоманд для взаимодействия с реестрами.\n\n\n### Опции\n\n```\n  -h, --help   help for registry\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes.\n* [helm registry login](./helm_registry_login.md)\t - вход в реестр\n* [helm registry logout](./helm_registry_logout.md)\t - выход из реестра\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\nвход в реестр\n\n### Краткое описание\n\nАутентификация в удалённом реестре.\n\n\n```\nhelm registry login [host] [flags]\n```\n\n### Опции\n\n```\n      --ca-file string     verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string   identify registry client using this SSL certificate file\n  -h, --help               help for login\n      --insecure           allow connections to TLS registry without certs\n      --key-file string    identify registry client using this SSL key file\n  -p, --password string    registry password or identity token\n      --password-stdin     read password or identity token from stdin\n      --plain-http         use insecure HTTP connections for the chart upload\n  -u, --username string    registry username\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm registry](./helm_registry.md)\t - вход в реестр или выход из реестра\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\nвыход из реестра\n\n### Краткое описание\n\nУдаление сохранённых учётных данных для удалённого реестра.\n\n\n```\nhelm registry logout [host] [flags]\n```\n\n### Опции\n\n```\n  -h, --help   help for logout\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm registry](./helm_registry.md)\t - вход в реестр или выход из реестра\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\nдобавление, просмотр, удаление, обновление и индексирование репозиториев чартов\n\n### Краткое описание\n\nЭта команда включает несколько подкоманд для работы с репозиториями чартов: добавление, удаление, просмотр списка и индексирование.\n\n\n### Опции\n\n```\n  -h, --help   help for repo\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes.\n* [helm repo add](./helm_repo_add.md)\t - добавление репозитория чартов\n* [helm repo index](./helm_repo_index.md)\t - генерация индексного файла для директории с упакованными чартами\n* [helm repo list](./helm_repo_list.md)\t - просмотр списка репозиториев чартов\n* [helm repo remove](./helm_repo_remove.md)\t - удаление одного или нескольких репозиториев чартов\n* [helm repo update](./helm_repo_update.md)\t - обновление информации о доступных чартах из репозиториев\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\nдобавление репозитория чартов\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Опции\n\n```\n      --allow-deprecated-repos     by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --force-update               replace (overwrite) the repo if it already exists\n  -h, --help                       help for add\n      --insecure-skip-tls-verify   skip tls certificate checks for the repository\n      --key-file string            identify HTTPS client using this SSL key file\n      --no-update                  Ignored. Formerly, it would disabled forced updates. It is deprecated by force-update.\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password\n      --password-stdin             read chart repository password from stdin\n      --timeout duration           time to wait for the index file download to complete (default 2m0s)\n      --username string            chart repository username\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm repo](./helm_repo.md)\t - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\nгенерация индексного файла на основе директории с упакованными чартами\n\n### Описание\n\nСканирует текущую директорию, генерирует индексный файл на основе найденных\nчартов и записывает результат в файл 'index.yaml' в текущей директории.\n\nЭтот инструмент используется для создания файла 'index.yaml' для репозитория\nчартов. Для указания абсолютного URL чартов используйте флаг '--url'.\n\nДля объединения сгенерированного индекса с существующим файлом индекса\nиспользуйте флаг '--merge'. В этом случае чарты из текущей директории будут\nобъединены с индексом, указанным в --merge. Локальные чарты имеют приоритет\nнад существующими.\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### Опции\n\n```\n  -h, --help           help for index\n      --json           output in JSON format\n      --merge string   merge the generated index into the given index\n      --url string     url of chart repository\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm repo](./helm_repo.md)\t - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\nвывод списка репозиториев чартов\n\n```\nhelm repo list [flags]\n```\n\n### Опции\n\n```\n  -h, --help            help for list\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm repo](./helm_repo.md)\t - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nудаление одного или нескольких репозиториев чартов\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Опции\n\n```\n  -h, --help   help for remove\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm repo](./helm_repo.md)\t - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\nобновление локальной информации о доступных чартах из репозиториев\n\n### Краткое описание\n\nКоманда update получает актуальную информацию о чартах из соответствующих репозиториев.\nИнформация кешируется локально и используется такими командами, как 'helm search'.\n\nВы можете указать список репозиториев, которые хотите обновить.\n\t$ helm repo update <repo_name> ...\nЧтобы обновить все репозитории, используйте 'helm repo update'.\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Опции\n\n```\n      --fail-on-repo-update-fail   update fails if any of the repository updates fail\n  -h, --help                       help for update\n      --timeout duration           time to wait for the index file download to complete (default 2m0s)\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm repo](./helm_repo.md)\t - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\nоткат релиза к предыдущей ревизии\n\n### Краткое описание\n\nЭта команда откатывает релиз к предыдущей ревизии.\n\nПервым аргументом команды rollback является имя релиза, вторым — номер\nревизии (версии). Если этот аргумент опущен или установлен в 0,\nоткат будет выполнен к предыдущему релизу.\n\nЧтобы увидеть номера ревизий, выполните 'helm history RELEASE'.\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Опции\n\n```\n      --cleanup-on-fail    allow deletion of new resources created in this rollback when rollback fails\n      --dry-run            simulate a rollback\n      --force              force resource update through delete/recreate if needed\n  -h, --help               help for rollback\n      --history-max int    limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --no-hooks           prevent hooks from running during rollback\n      --recreate-pods      performs pods restart for the resource if applicable\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --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\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\nпоиск по ключевому слову в чартах\n\n### Краткое описание\n\nSearch позволяет искать Helm чарты в разных местах их хранения, включая\nArtifact Hub и добавленные вами репозитории. Используйте подкоманды search\nдля поиска чартов в разных источниках.\n\n\n### Опции\n\n```\n  -h, --help   help for search\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes.\n* [helm search hub](./helm_search_hub.md)\t - поиск чартов в Artifact Hub или вашем собственном экземпляре hub\n* [helm search repo](./helm_search_repo.md)\t - поиск чартов по ключевому слову в репозиториях\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\nпоиск чартов в Artifact Hub или вашем собственном экземпляре hub\n\n### Краткое описание\n\nЭта команда выполняет поиск Helm чартов в Artifact Hub или вашем собственном\nэкземпляре hub.\n\nArtifact Hub — это веб-приложение для поиска, установки и публикации пакетов\nи конфигураций для проектов CNCF, включая публично доступные Helm чарты.\nЭто проект-песочница Cloud Native Computing Foundation. Вы можете просмотреть\nhub по адресу https://artifacthub.io/\n\nВ качестве аргумента [KEYWORD] можно указать строку ключевого слова или строку\nв кавычках с расширенными параметрами запроса. Документацию по расширенным\nпараметрам запроса см. на\nhttps://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n\nПредыдущие версии Helm использовали экземпляр Monocular в качестве значения по\nумолчанию для 'endpoint'. Для обратной совместимости Artifact Hub поддерживает\nAPI поиска Monocular. При установке флага 'endpoint' указанная конечная точка\nтакже должна реализовывать совместимый с Monocular API поиска. Обратите внимание:\nпри указании экземпляра Monocular в качестве 'endpoint' расширенные запросы\nне поддерживаются. Подробности см. на https://github.com/helm/monocular\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### Опции\n\n```\n      --endpoint string      Hub instance to query for charts (default \"https://hub.helm.sh\")\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for hub\n      --list-repo-url        print charts repository URL\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm search](./helm_search.md)\t - поиск по ключевому слову в чартах\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\nпоиск чартов по ключевому слову в репозиториях\n\n### Краткое описание\n\nЭта команда просматривает все репозитории, настроенные в системе,\nи ищет совпадения. Поиск по этим репозиториям использует метаданные,\nсохранённые в системе.\n\nКоманда отображает последние стабильные версии найденных чартов. При указании\nфлага --devel в результаты будут включены предварительные версии.\nДля поиска с ограничением версии используйте флаг --version.\n\nПримеры:\n\n    # Поиск стабильных версий по ключевому слову \"nginx\"\n    $ helm search repo nginx\n\n    # Поиск версий по ключевому слову \"nginx\", включая предварительные версии\n    $ helm search repo nginx --devel\n\n    # Поиск последней стабильной версии nginx-ingress с мажорной версией 1\n    $ helm search repo nginx-ingress --version ^1.0.0\n\nРепозитории управляются командами 'helm repo'.\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### Опции\n\n```\n      --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\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for repo\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n  -r, --regexp               use regular expressions for searching repositories you have added\n      --version string       search using semantic versioning constraints on repositories you have added\n  -l, --versions             show the long listing, with each version of each chart on its own line, for repositories you have added\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm search](./helm_search.md)\t - поиск по ключевому слову в чартах\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\nотображение информации о чарте\n\n### Краткое описание\n\nЭта команда состоит из нескольких подкоманд для отображения информации о чарте\n\n\n### Опции\n\n```\n  -h, --help   help for show\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - менеджер пакетов Helm для Kubernetes.\n* [helm show all](./helm_show_all.md)\t - показать всю информацию о чарте\n* [helm show chart](./helm_show_chart.md)\t - показать определение чарта\n* [helm show crds](./helm_show_crds.md)\t - показать CRD чарта\n* [helm show readme](./helm_show_readme.md)\t - показать README чарта\n* [helm show values](./helm_show_values.md)\t - показать values чарта\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\nпоказать всю информацию о чарте\n\n### Краткое описание\n\nЭта команда анализирует чарт (директорию, файл или URL) и отображает всё его\nсодержимое (values.yaml, Chart.yaml, README)\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### Опции\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for all\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm show](./helm_show.md)\t - отображение информации о чарте\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\nпоказать определение чарта\n\n### Краткое описание\n\nЭта команда анализирует чарт (директорию, файл или URL) и отображает содержимое\nфайла Chart.yaml\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### Опции\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for chart\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm show](./helm_show.md)\t - отображение информации о чарте\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\nпоказать CRD чарта\n\n### Краткое описание\n\nЭта команда анализирует чарт (директорию, файл или URL) и отображает содержимое\nфайлов CustomResourceDefinition\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### Опции\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for crds\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm show](./helm_show.md)\t - отображение информации о чарте\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nпоказать README чарта\n\n### Краткое описание\n\nЭта команда анализирует чарт (директорию, файл или URL) и отображает содержимое\nфайла README\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### Опции\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for readme\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm show](./helm_show.md)\t - отображение информации о чарте\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\nпоказать значения чарта\n\n### Краткое описание\n\nЭта команда анализирует чарт (директорию, файл или URL) и отображает содержимое\nфайла values.yaml\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### Опции\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for values\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --jsonpath string            supply a JSONPath expression to filter the output\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm show](./helm_show.md)\t - отображение информации о чарте\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\nотображение статуса указанного релиза\n\n### Краткое описание\n\nЭта команда отображает статус указанного релиза.\nСтатус включает:\n- время последнего развёртывания\n- namespace Kubernetes, в котором находится релиз\n- состояние релиза (возможные значения: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade или pending-rollback)\n- ревизия релиза\n- описание релиза (может быть сообщением о завершении или сообщением об ошибке, требуется флаг --show-desc)\n- список ресурсов данного релиза (требуется флаг --show-resources)\n- результаты последнего тестирования, если применимо\n- дополнительные примечания, предоставленные чартом\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### Опции\n\n```\n  -h, --help             help for status\n  -o, --output format    prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int     if set, display the status of the named release with revision\n      --show-desc        if set, display the description message of the named release\n      --show-resources   if set, display the resources of the named release\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nлокальный рендеринг шаблонов\n\n### Краткое описание\n\nРендеринг шаблонов чарта локально с выводом результата.\n\nЗначения, которые обычно запрашиваются из кластера, будут эмулированы локально.\nСерверная проверка валидности чарта также не выполняется (например, проверка\nподдержки конкретного API).\n\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### Опции\n\n```\n  -a, --api-versions strings                       Kubernetes api versions used for Capabilities.APIVersions\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for template\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --include-crds                               include CRDs in the templated output\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --is-upgrade                                 set .Release.IsUpgrade instead of .Release.IsInstall\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        Kubernetes version used for Capabilities.KubeVersion\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n      --output-dir string                          writes the executed templates to files in output-dir instead of stdout\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --release-name                               use release name in the output-dir path.\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n  -s, --show-only stringArray                      only show manifests rendered from the given templates\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --skip-tests                                 skip tests from templated output\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n      --validate                                   validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\nзапуск тестов для релиза\n\n### Краткое описание\n\nКоманда test запускает тесты для релиза.\n\nКоманда принимает в качестве аргумента имя развёрнутого релиза.\nТесты, которые будут запущены, определены в установленном чарте.\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### Опции\n\n```\n      --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)\n  -h, --help               help for test\n      --hide-notes         if set, do not show notes in test output. Does not affect presence in chart metadata\n      --logs               dump the logs from test pods (this runs after all tests are complete, but before any cleanup)\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\nудаление релиза\n\n### Краткое описание\n\nЭта команда принимает имя релиза и удаляет его.\n\nОна удаляет все ресурсы, связанные с последним релизом чарта,\nа также историю релиза, освобождая имя для повторного использования.\n\nИспользуйте флаг '--dry-run', чтобы увидеть, какие релизы будут удалены,\nбез фактического удаления.\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Опции\n\n```\n      --cascade string       Must be \"background\", \"orphan\", or \"foreground\". Selects the deletion cascading strategy for the dependents. Defaults to background. (default \"background\")\n      --description string   add a custom description\n      --dry-run              simulate a uninstall\n  -h, --help                 help for uninstall\n      --ignore-not-found     Treat \"release not found\" as a successful uninstall\n      --keep-history         remove all associated resources and mark the release as deleted, but retain the release history\n      --no-hooks             prevent hooks from running during uninstallation\n      --timeout duration     time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --wait                 if set, will wait until all the resources are deleted before returning. It will wait for as long as --timeout\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nобновление релиза до новой версии чарта\n\n### Краткое описание\n\nЭта команда обновляет релиз до новой версии чарта.\n\nАргументами команды upgrade должны быть релиз и чарт. Аргумент чарта\nможет быть: ссылкой на чарт ('example/mariadb'), путём к директории с чартом,\nупакованным чартом или полным URL-адресом. Если не указан флаг '--version',\nбудет использоваться последняя версия чарта.\n\nЧтобы переопределить значения в чарте, используйте флаг '--values' и передайте файл\nили используйте флаг '--set' для передачи конфигурации из командной строки. Для принудительного\nзадания строковых значений используйте '--set-string'. Флаг '--set-file' позволяет задавать\nотдельные значения из файла, когда значение слишком длинное для командной строки\nили генерируется динамически. Также можно использовать '--set-json' для задания JSON-значений\n(скаляров/объектов/массивов) из командной строки.\n\nФлаг '--values'/'-f' можно указывать несколько раз. Приоритет отдаётся\nпоследнему (самому правому) указанному файлу. Например, если оба файла myvalues.yaml и override.yaml\nсодержат ключ 'Test', значение из override.yaml будет иметь приоритет:\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\nФлаг '--set' можно указывать несколько раз. Приоритет отдаётся\nпоследнему (самому правому) указанному значению. Например, если для ключа 'foo'\nзаданы значения 'bar' и 'newbar', значение 'newbar' будет иметь приоритет:\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\nС помощью этой команды также можно обновить значения существующего релиза,\nиспользуя флаг '--reuse-values'. Аргументы 'RELEASE' и 'CHART' должны соответствовать\nисходным параметрам, и существующие значения будут объединены со значениями,\nуказанными через флаги '--values'/'-f' или '--set'. Приоритет отдаётся новым значениям.\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\nФлаг --dry-run выведет все сгенерированные манифесты чарта, включая Secrets,\nкоторые могут содержать конфиденциальные данные. Чтобы скрыть Kubernetes Secrets,\nиспользуйте флаг --hide-secret. Используйте эти флаги с осторожностью.\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Опции\n\n```\n      --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\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --cleanup-on-fail                            allow deletion of new resources created in this upgrade when upgrade fails\n      --create-namespace                           if --install is set, create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -h, --help                                       help for upgrade\n      --hide-notes                                 if set, do not show notes in upgrade output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --history-max int                            limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n  -i, --install                                    if a release by this name doesn't already exist, run an install\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -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 [])\n      --no-hooks                                   disable pre/post upgrade hooks\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --repo string                                chart repository url where to locate the requested chart\n      --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\n      --reset-values                               when upgrading, reset the values to the ones built into the chart\n      --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\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\nпроверка подписи и валидности чарта по указанному пути\n\n### Краткое описание\n\nПроверяет, что указанный чарт имеет действительный файл происхождения (provenance).\n\nФайлы происхождения обеспечивают криптографическую проверку того, что чарт\nне был изменён и упакован доверенным поставщиком.\n\nЭту команду можно использовать для проверки локального чарта. У некоторых других\nкоманд есть флаг '--verify', который выполняет ту же проверку. Чтобы создать\nподписанный пакет, используйте команду 'helm package --sign'.\n\n\n```\nhelm verify PATH [flags]\n```\n\n### Опции\n\n```\n  -h, --help             help for verify\n      --keyring string   keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n\nвывод информации о версии клиента\n\n### Краткое описание\n\nПоказывает версию Helm.\n\nЭта команда выводит информацию о версии Helm.\nВывод будет выглядеть примерно так:\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version — это семантическая версия релиза.\n- GitCommit — это SHA коммита, из которого была собрана эта версия.\n- GitTreeState имеет значение \"clean\", если при сборке бинарного файла не было локальных изменений кода, и \"dirty\", если бинарный файл был собран из локально изменённого кода.\n- GoVersion — это версия Go, которая использовалась для компиляции Helm.\n\nПри использовании флага --template доступны следующие свойства для использования в шаблоне:\n\n- .Version содержит семантическую версию Helm\n- .GitCommit — это git-коммит\n- .GitTreeState — это состояние git-дерева на момент сборки Helm\n- .GoVersion содержит версию Go, с которой был скомпилирован Helm\n\nНапример, --template='Version: {{.Version}}' выведет 'Version: v3.2.1'.\n\n\n```\nhelm version [flags]\n```\n\n### Опции\n\n```\n  -h, --help              help for version\n      --short             print the version number\n      --template string   template for version string format\n```\n\n### Опции, унаследованные от родительских команд\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### Смотрите также\n\n* [helm](./helm.md)\t - Менеджер пакетов Helm для Kubernetes.\n\n###### Автоматически сгенерировано spf13/cobra 14-Jan-2026\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/helm/index.mdx",
    "content": "---\ntitle: Команды Helm\ndescription: Документация по полному списку команд CLI Helm.\nsidebar_position: 6\nid: helm-category\n---\n\n# Команды Helm\n\nЗдесь вы найдёте список команд CLI для Helm со справочной информацией по их использованию.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action для автоматизации публикации чартов на GitHub Pages\ndescription: Как использовать Chart Releaser Action для автоматической публикации чартов через GitHub Pages.\nsidebar_position: 3\n---\n\nЭто руководство описывает, как использовать [Chart Releaser\nAction](https://github.com/marketplace/actions/helm-chart-releaser) для автоматической\nпубликации чартов через GitHub Pages. Chart Releaser Action — это GitHub Action,\nкоторый превращает проект GitHub в собственный репозиторий Helm-чартов с помощью\nCLI-инструмента [helm/chart-releaser](https://github.com/helm/chart-releaser).\n\n## Изменения в репозитории\n\nСоздайте Git-репозиторий в вашей организации GitHub. Вы можете назвать репозиторий\n`helm-charts`, хотя допустимы и другие имена. Исходные файлы всех чартов можно\nразместить в ветке `main`. Чарты должны находиться в каталоге `/charts` в корне\nдерева каталогов.\n\nТакже необходима отдельная ветка `gh-pages` для публикации чартов. Изменения в этой\nветке будут автоматически создаваться Chart Releaser Action, описанным здесь.\nОднако вы можете создать ветку `gh-pages` и добавить файл `README.md`, который\nбудет виден пользователям, посещающим страницу.\n\nВы можете добавить инструкции по установке чартов в `README.md` следующим образом\n(замените `<alias>`, `<orgname>` и `<chart-name>`):\n\n```\n## Usage\n\n[Helm](https://helm.sh) must be installed to use the charts.  Please refer to\nHelm's [documentation](https://helm.sh/docs) to get started.\n\nOnce Helm has been set up correctly, add the repo as follows:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nIf you had already added this repo earlier, run `helm repo update` to retrieve\nthe latest versions of the packages.  You can then run `helm search repo\n<alias>` to see the charts.\n\nTo install the <chart-name> chart:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nTo uninstall the chart:\n\n    helm uninstall my-<chart-name>\n```\n\nЧарты будут опубликованы на сайте с URL вида:\n\n    https://<orgname>.github.io/helm-charts\n\n## Рабочий процесс GitHub Actions\n\nСоздайте файл рабочего процесса GitHub Actions в ветке `main` по пути\n`.github/workflows/release.yml`\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nЭта конфигурация использует\n[@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action),\nчтобы превратить ваш проект GitHub в собственный репозиторий Helm-чартов.\nПри каждом push в ветку `main` он проверяет все чарты в проекте и при обнаружении\nновой версии чарта выполняет следующие действия:\n\n- Создаёт GitHub-релиз с именем, соответствующим версии чарта\n- Добавляет артефакты Helm-чарта к релизу\n- Создаёт или обновляет файл `index.yaml` с метаданными об этих релизах\n\nФайл `index.yaml` затем размещается на GitHub Pages.\n\nВ примере выше используется Chart Releaser Action версии `v1.6.0`.\nВы можете заменить её на [последнюю доступную\nверсию](https://github.com/helm/chart-releaser-action/releases).\n\nПримечание: Chart Releaser Action почти всегда используется совместно с\n[Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) и\n[Kind Action](https://github.com/marketplace/actions/kind-cluster).\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: Синхронизация репозитория чартов\ndescription: Как синхронизировать локальный и удалённый репозитории чартов.\nsidebar_position: 2\n---\n\n*Примечание: этот пример предназначен специально для бакета Google Cloud Storage (GCS),\nиспользуемого в качестве репозитория чартов.*\n\n## Предварительные требования\n* Установите инструмент [gsutil](https://cloud.google.com/storage/docs/gsutil). *Основная\n  часть работы выполняется через gsutil rsync*\n* Убедитесь, что Helm установлен и доступен\n* _Опционально: мы рекомендуем включить [версионирование объектов](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)\n  в вашем GCS-бакете на случай случайного удаления данных._\n\n## Настройка локального каталога репозитория чартов\nСоздайте локальный каталог, как описано в [руководстве по репозиториям чартов](/topics/chart_repository.md), и поместите в него упакованные чарты.\n\nНапример:\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Генерация обновлённого index.yaml\nИспользуйте Helm для генерации обновлённого файла index.yaml, передав путь к каталогу\nи URL удалённого репозитория команде `helm repo index`:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\nЭта команда сгенерирует обновлённый файл index.yaml и поместит его в каталог\n`fantastic-charts/`.\n\n## Синхронизация локального и удалённого репозиториев чартов\nЗагрузите содержимое каталога в ваш GCS-бакет, запустив скрипт\n`scripts/sync-repo.sh` с указанием имени локального каталога и имени GCS-бакета.\n\nНапример:\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## Обновление репозитория чартов\nХраните локальную копию содержимого вашего репозитория чартов или используйте\n`gsutil rsync` для копирования содержимого удалённого репозитория чартов\nв локальный каталог.\n\nНапример:\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nПолезные ссылки:\n* Документация по [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [Руководство по репозиториям чартов](/topics/chart_repository.md)\n* Документация по [версионированию объектов и управлению конкурентным доступом](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)\n  в Google Cloud Storage\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Советы и приёмы при разработке чартов\ndescription: Описание советов и приёмов, которые разработчики чартов Helm освоили при создании чартов производственного качества.\nsidebar_position: 1\n---\n\nВ этом руководстве описаны советы и приёмы, которые разработчики чартов Helm\nосвоили при создании чартов производственного качества.\n\n## Знайте свои функции шаблонов\n\nHelm использует [Go templates](https://godoc.org/text/template) для шаблонизации\nваших файлов ресурсов. Хотя Go включает несколько встроенных функций, мы добавили\nмножество других.\n\nВо-первых, мы добавили все функции из [библиотеки Sprig](https://masterminds.github.io/sprig/),\nза исключением `env` и `expandenv` по соображениям безопасности.\n\nТакже мы добавили две специальные функции шаблонов: `include` и `required`. Функция\n`include` позволяет подключить другой шаблон, а затем передать результат другим\nфункциям шаблонов.\n\nНапример, этот фрагмент шаблона подключает шаблон `mytpl`, приводит результат\nк нижнему регистру, а затем оборачивает его в двойные кавычки.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nФункция `required` позволяет объявить определённое значение как обязательное для\nрендеринга шаблона. Если значение пустое, рендеринг шаблона завершится с ошибкой,\nсодержащей сообщение, указанное пользователем.\n\nСледующий пример функции `required` объявляет запись `.Values.who` как обязательную\nи выводит сообщение об ошибке, если эта запись отсутствует:\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## Оборачивайте строки в кавычки, не оборачивайте целые числа\n\nПри работе со строковыми данными всегда безопаснее оборачивать строки в кавычки,\nчем оставлять их без кавычек:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nНо при работе с целыми числами _не оборачивайте значения в кавычки._ Это может\nво многих случаях вызвать ошибки парсинга в Kubernetes.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nЭто замечание не относится к значениям переменных окружения, которые ожидаются\nкак строки, даже если представляют собой числа:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Использование функции 'include'\n\nGo предоставляет способ подключения одного шаблона в другой с помощью встроенной\nдирективы `template`. Однако встроенную функцию нельзя использовать в конвейерах\nGo templates.\n\nЧтобы сделать возможным подключение шаблона и последующее выполнение операции\nнад его выводом, Helm предоставляет специальную функцию `include`:\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nПриведённый выше код подключает шаблон `toYaml`, передаёт ему `$value`, а затем\nпередаёт вывод этого шаблона функции `indent`.\n\nПоскольку YAML придаёт значение уровням отступов и пробелам, это отличный способ\nподключать фрагменты кода с правильной обработкой отступов в нужном контексте.\n\n## Использование функции 'required'\n\nGo позволяет устанавливать параметры шаблона для управления поведением при обращении\nк map с ключом, который в ней отсутствует. Обычно это делается с помощью\n`template.Options(\"missingkey=option\")`, где `option` может быть `default`,\n`zero` или `error`. Установка этого параметра в значение error остановит выполнение\nс ошибкой, но это будет применяться к каждому отсутствующему ключу в map. Могут\nвозникать ситуации, когда разработчик чарта хочет применить такое поведение\nк определённым значениям в файле `values.yaml`.\n\nФункция `required` позволяет разработчикам объявлять значение как обязательное\nдля рендеринга шаблона. Если запись пуста в `values.yaml`, шаблон не будет\nотрендерен и вернёт сообщение об ошибке, указанное разработчиком.\n\nПример:\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nПриведённый выше код отрендерит шаблон, когда `.Values.foo` определена, но не\nсможет отрендерить его и завершится с ошибкой, когда `.Values.foo` не определена.\n\n## Использование функции 'tpl'\n\nФункция `tpl` позволяет разработчикам вычислять строки как шаблоны внутри шаблона.\nЭто полезно для передачи строки шаблона в качестве значения чарту или для рендеринга\nвнешних конфигурационных файлов. Синтаксис: `{{ tpl TEMPLATE_STRING VALUES }}`\n\nПримеры:\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\nРендеринг внешнего конфигурационного файла:\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## Создание Image Pull Secrets\n\nImage pull secrets — это комбинация _registry_, _username_ и _password_.\nОни могут понадобиться в развёртываемом приложении, но для их создания необходимо\nнесколько раз выполнить кодирование `base64`. Можно написать вспомогательный шаблон,\nкоторый создаст конфигурационный файл Docker для использования в Secret.\nВот пример:\n\nСначала предположим, что учётные данные определены в файле `values.yaml`\nследующим образом:\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nЗатем мы определяем вспомогательный шаблон следующим образом:\n\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nНаконец, мы используем вспомогательный шаблон в более крупном шаблоне для создания\nманифеста Secret:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Автоматический перезапуск Deployment\n\nЧасто ConfigMap или Secret внедряются как конфигурационные файлы в контейнеры,\nили есть другие изменения внешних зависимостей, требующие перезапуска подов.\nВ зависимости от приложения при последующем `helm upgrade` может потребоваться\nперезапуск, но если спецификация deployment не изменилась, приложение продолжит\nработать со старой конфигурацией, что приведёт к несогласованному развёртыванию.\n\nФункцию `sha256sum` можно использовать для обновления секции аннотаций deployment\nпри изменении другого файла:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nПРИМЕЧАНИЕ: Если вы добавляете это в библиотечный чарт, вы не сможете получить\nдоступ к вашему файлу через `$.Template.BasePath`. Вместо этого вы можете\nсослаться на ваше определение с помощью `{{ include (\"mylibchart.configmap\") . | sha256sum }}`.\n\nЕсли вы хотите, чтобы ваш deployment всегда перезапускался, можно использовать\nаналогичную аннотацию, заменив значение случайной строкой, чтобы оно всегда\nменялось и вызывало перезапуск deployment:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nКаждый вызов функции шаблона будет генерировать уникальную случайную строку.\nЭто означает, что если необходимо синхронизировать случайные строки, используемые\nфайле шаблона.\n\nОба эти метода позволяют вашему Deployment использовать встроенную логику стратегии\nобновления для избежания простоев.\n\nПРИМЕЧАНИЕ: Ранее мы рекомендовали использовать флаг `--recreate-pods` как\nальтернативный вариант. Этот флаг был помечен как устаревший в Helm 3 в пользу\nболее декларативного метода, описанного выше.\n\n## Запрет удаления ресурса при деинсталляции\n\nИногда есть ресурсы, которые не должны удаляться при выполнении `helm uninstall`.\nРазработчики чартов могут добавить аннотацию к ресурсу, чтобы предотвратить его\nудаление.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nАннотация `helm.sh/resource-policy: keep` указывает Helm пропустить удаление\nэтого ресурса при операции helm (например, `helm uninstall`, `helm upgrade` или\n`helm rollback`), которая привела бы к его удалению. _Однако_ этот ресурс становится\nосиротевшим. Helm больше не будет им управлять. Это может привести к проблемам\nпри использовании `helm install --replace` для релиза, который был удалён,\nно сохранил ресурсы.\n\n## Использование «Partials» и подключение шаблонов\n\nИногда требуется создать переиспользуемые части в чарте — блоки или частичные\nшаблоны. Часто удобнее хранить их в отдельных файлах.\n\nВ директории `templates/` любой файл, начинающийся с подчёркивания (`_`), не будет\nвыводиться как манифест Kubernetes. По соглашению вспомогательные шаблоны\nи partials размещаются в файле `_helpers.tpl`.\n\n## Сложные чарты с множеством зависимостей\n\nМногие чарты в [Artifact Hub](https://artifacthub.io/packages/search?kind=0) CNCF\nявляются «строительными блоками» для создания более сложных приложений. Но чарты\nтакже могут использоваться для создания экземпляров крупномасштабных приложений.\nВ таких случаях один зонтичный чарт может иметь несколько подчартов, каждый из\nкоторых функционирует как часть целого.\n\nТекущая лучшая практика для создания сложного приложения из отдельных частей —\nсоздать зонтичный чарт верхнего уровня, который предоставляет глобальные\nконфигурации, и использовать поддиректорию `charts/` для встраивания каждого\nиз компонентов.\n\n## YAML — это надмножество JSON\n\nСогласно спецификации YAML, YAML является надмножеством JSON. Это означает, что\nлюбая допустимая структура JSON должна быть допустимой в YAML.\n\nЭто даёт преимущество: иногда разработчикам шаблонов может быть проще выразить\nструктуру данных с помощью JSON-подобного синтаксиса, чем работать с\nчувствительностью YAML к пробелам.\n\nВ качестве лучшей практики шаблоны должны следовать YAML-подобному синтаксису,\n_если только_ синтаксис JSON существенно не снижает риск проблем с форматированием.\n\n## Будьте осторожны при генерации случайных значений\n\nВ Helm есть функции для генерации случайных данных, криптографических ключей\nи т.д. Их можно использовать. Но имейте в виду, что при обновлениях шаблоны\nвыполняются повторно. Когда выполнение шаблона генерирует данные, отличающиеся\nот предыдущего выполнения, это вызовет обновление этого ресурса.\n\n## Установка или обновление релиза одной командой\n\nHelm предоставляет возможность выполнить установку или обновление одной командой.\nИспользуйте `helm upgrade` с флагом `--install`. Это заставит Helm проверить,\nустановлен ли уже релиз. Если нет — будет выполнена установка. Если да —\nсуществующий релиз будет обновлён.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/howto/index.mdx",
    "content": "---\ntitle: Практические руководства\nsidebar_position: 2\n---\n\n# Практические руководства\n\nЗдесь вы найдёте краткие ответы на вопросы типа «Как мне…?». Эти практические\nруководства не рассматривают темы углублённо — подробный материал вы найдёте в [Тематических\nруководствах](/topics/index.mdx). Однако эти руководства помогут вам быстро выполнить\nтипичные задачи.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"Документация Главная\"\ndescription: \"Все то, что вам необходимо знать о том, как организована документация.\"\n---\n\n# Добро пожаловать\n\nДобро пожаловать в документацию по [Helm](https://helm.sh/). Helm – это менеджер пакетов Kubernetes. Подробную справочную информацию можно прочитать в отчете\n[CNCF Helm Project Journey\nreport](https://www.cncf.io/cncf-helm-project-journey/).\n\n# Как организована документация\n\nУ Helm много документации. Обзор поможет узнать, где искать необходимую информацию\n\n- [Обучающие материалы](https://helm.sh/docs/intro) проведут вас за руку через ряд шагов, которые помогут создать\n  первый Helm chart Начните с этого, если вы новичок в Helm.\n- [Тематические руководства](https://helm.sh/docs/topics) обсуждают ключевые темы и концепции на достаточно высоком уровне,\n  предоставляют полезную справочную информацию и разъяснения.\n- [Путеводители сообщества](/community) обсуждают темы, сосредоточенные вокруг Helm сообщества.\n  Начните отсюда, если вы хотите узнать больше о процессе разработки самого Helm и о том, как вы можете внести свой вклад.\n- [Инструкции по применению](https://helm.sh/docs/howto) это готовые советы по использованию.\n  Они проведут вас через шаги, связанные с решением ключевых проблем и вариантов их разрешения.\n  Инструкции по применению более продвинуты, чем [обучающие материалы](https://helm.sh/docs/intro), и предлагают некоторые расширенные знания о том, как работает Helm.\n---\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: Шпаргалка\ndescription: Шпаргалка по Helm\nsidebar_position: 4\n---\n\nШпаргалка Helm со всеми командами, необходимыми для управления приложениями.\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### Основные термины\n\nChart:\n- Это имя вашего чарта, если он был загружен и распакован.\n- Это <имя_репозитория>/<имя_чарта>, если репозиторий был добавлен, но чарт не загружен.\n- Это URL или абсолютный путь к чарту.\n\nName:\n- Это имя, которое вы хотите присвоить текущей установке чарта Helm.\n\nRelease:\n- Это имя, которое вы присвоили экземпляру установки.\n\nRevision:\n- Это значение из вывода команды `helm history`.\n\nRepo-name:\n- Имя репозитория.\n\nDIR:\n- Имя директории или путь к ней.\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Управление чартами\n\n```bash\nhelm create <name>                      # Создаёт директорию чарта вместе с общими файлами и директориями, используемыми в чарте.\nhelm package <chart-path>               # Упаковывает чарт в версионированный архивный файл.\nhelm lint <chart>                       # Запускает тесты для проверки чарта и выявления возможных проблем.\nhelm show all <chart>                   # Проверяет чарт и выводит его содержимое.\nhelm show values <chart>                # Отображает содержимое файла values.yaml.\nhelm pull <chart>                       # Скачивает чарт.\nhelm pull <chart> --untar=true          # Если true, распаковывает чарт после скачивания.\nhelm pull <chart> --verify              # Проверяет пакет перед использованием.\nhelm pull <chart> --version <number>    # По умолчанию используется последняя версия; указывает ограничение версии чарта.\nhelm dependency list <chart>            # Отображает список зависимостей чарта.\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Установка и удаление приложений\n\n```bash\nhelm install <name> <chart>                           # Устанавливает чарт с указанным именем.\nhelm install <name> <chart> --namespace <namespace>   # Устанавливает чарт в указанное пространство имён.\nhelm install <name> <chart> --set key1=val1,key2=val2 # Задаёт значения в командной строке (можно указать несколько значений через запятую).\nhelm install <name> <chart> --values <yaml-file/url>  # Устанавливает чарт с указанными значениями.\nhelm install <name> <chart> --dry-run --debug         # Запускает тестовую установку для проверки чарта.\nhelm install <name> <chart> --verify                  # Проверяет пакет перед использованием.\nhelm install <name> <chart> --dependency-update       # Обновляет зависимости, если они отсутствуют, перед установкой чарта.\nhelm uninstall <name>                                 # Удаляет релиз из текущего (по умолчанию) пространства имён.\nhelm uninstall <release-name> --namespace <namespace> # Удаляет релиз из указанного пространства имён.\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Обновление и откат приложений\n\n```bash\nhelm upgrade <release> <chart>                            # Обновляет релиз.\nhelm upgrade <release> <chart> --rollback-on-failure      # При неудачном обновлении откатывает внесённые изменения.\nhelm upgrade <release> <chart> --dependency-update        # Обновляет зависимости, если они отсутствуют, перед установкой чарта.\nhelm upgrade <release> <chart> --version <version_number> # Указывает ограничение версии чарта.\nhelm upgrade <release> <chart> --values                   # Указывает значения в YAML-файле или по URL (можно указать несколько).\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Задаёт значения в командной строке (можно указать несколько значений через запятую).\nhelm upgrade <release> <chart> --force                    # Принудительно обновляет ресурсы через стратегию замены.\nhelm rollback <release> <revision>                        # Откатывает релиз к указанной ревизии.\nhelm rollback <release> <revision>  --cleanup-on-fail     # Позволяет удалить новые ресурсы, созданные при откате, если откат не удался.\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Работа с репозиториями\n\n```bash\nhelm repo add <repo-name> <url>   # Добавляет репозиторий из интернета.\nhelm repo list                    # Выводит список добавленных репозиториев чартов.\nhelm repo update                  # Обновляет локальную информацию о доступных чартах из репозиториев.\nhelm repo remove <repo_name>      # Удаляет один или несколько репозиториев чартов.\nhelm repo index <DIR>             # Читает текущую директорию и генерирует индексный файл на основе найденных чартов.\nhelm repo index <DIR> --merge     # Объединяет сгенерированный индекс с существующим индексным файлом.\nhelm search repo <keyword>        # Ищет чарты по ключевому слову в репозиториях.\nhelm search hub <keyword>         # Ищет чарты в Artifact Hub или вашем собственном хабе.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Мониторинг релизов Helm\n\n```bash\nhelm list                       # Выводит все релизы для указанного пространства имён; использует текущий контекст, если пространство имён не указано.\nhelm list --all                 # Показывает все релизы без фильтров (можно использовать -a).\nhelm list --all-namespaces      # Выводит релизы из всех пространств имён (можно использовать -A).\nhelm list -l key1=value1,key2=value2 # Селектор (запрос по меткам) для фильтрации; поддерживает '=', '==' и '!='.\nhelm list --date                # Сортирует по дате релиза.\nhelm list --deployed            # Показывает развёрнутые релизы. Включается автоматически, если не указано иное.\nhelm list --pending             # Показывает ожидающие релизы.\nhelm list --failed              # Показывает неудавшиеся релизы.\nhelm list --uninstalled         # Показывает удалённые релизы (если использовался 'helm uninstall --keep-history').\nhelm list --superseded          # Показывает замещённые релизы.\nhelm list -o yaml               # Выводит результат в указанном формате. Допустимые значения: table, json, yaml (по умолчанию table).\nhelm status <release>           # Показывает статус указанного релиза.\nhelm status <release> --revision <number>   # Показывает статус указанного релиза с определённой ревизией.\nhelm history <release>          # Показывает историю ревизий для указанного релиза.\nhelm env                        # Выводит всю информацию об окружении, используемую Helm.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Получение информации о релизе\n\n```bash\nhelm get all <release>      # Выводит удобочитаемую информацию о заметках, хуках, переданных значениях и сгенерированном манифесте релиза.\nhelm get hooks <release>    # Скачивает хуки для указанного релиза. Хуки форматируются в YAML и разделяются разделителем '---\\n'.\nhelm get manifest <release> # Манифест — это YAML-представление ресурсов Kubernetes, сгенерированных из чарта(ов) релиза. Включает ресурсы зависимых чартов.\nhelm get notes <release>    # Показывает заметки, предоставленные чартом указанного релиза.\nhelm get values <release>   # Скачивает файл значений для указанного релиза. Используйте -o для форматирования вывода.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Управление плагинами\n\n```bash\nhelm plugin install <path/url>      # Устанавливает плагины.\nhelm plugin list                    # Показывает список всех установленных плагинов.\nhelm plugin update <plugin>         # Обновляет плагины.\nhelm plugin uninstall <plugin>      # Удаляет плагин.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/intro/index.mdx",
    "content": "---\ntitle: Введение\nsidebar_position: 1\n---\n\n# Введение в Helm\n\nВы новичок в Helm? Это самое подходящее место для начала!\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: Установка Helm\ndescription: Узнайте, как установить и начать работать с Helm.\nsidebar_position: 2\n---\n\nВ этом руководстве описывается, как установить CLI Helm. Helm можно установить из\nисходного кода или из предварительно собранных бинарных файлов.\n\n## Из проекта Helm\n\nПроект Helm предоставляет два способа получения и установки Helm. Это\nофициальные методы получения релизов Helm. Помимо этого, сообщество Helm\nпредоставляет методы установки через различные менеджеры пакетов.\nУстановка с помощью этих методов описана ниже.\n\n### Из бинарных релизов\n\nКаждый [релиз](https://github.com/helm/helm/releases) Helm предоставляет бинарные\nфайлы для различных операционных систем. Эти бинарные версии можно загрузить и установить вручную.\n\n1. Скачайте нужную вам [версию](https://github.com/helm/helm/releases)\n2. Распакуйте её (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)\n3. Найдите бинарный файл `helm` в распакованной директории и переместите его в нужное место (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nПосле этого вы сможете запустить клиент и [добавить репозиторий чартов stable](/intro/quickstart.md#initialize-a-helm-chart-repository):\n`helm help`.\n\n**Примечание:** Автоматические тесты Helm выполняются только для Linux AMD64 во время\nсборок и релизов в GitHub Actions. Тестирование на других ОС является обязанностью\nсообщества, использующего Helm на этих системах.\n\n### Из скрипта\n\nHelm теперь имеет скрипт установки, который автоматически загружает последнюю версию\nHelm и [устанавливает её локально](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3).\n\nВы можете скачать этот скрипт и затем выполнить его локально.\nОн хорошо документирован, так что вы можете прочитать его и понять, что он делает, прежде чем запускать.\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\nДа, вы можете выполнить `curl\nhttps://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`, если\nхотите рискнуть.\n\n## Через менеджеры пакетов\n\nСообщество Helm предоставляет возможность установки Helm через\nменеджеры пакетов операционной системы.\nОни не поддерживаются проектом Helm и не считаются доверенными сторонними источниками.\n\n### Используя Homebrew (macOS)\n\nУчастники сообщества Helm добавили формулу Helm в Homebrew.\nЭта формула обычно актуальна.\n\n```console\nbrew install helm\n```\n\n(Примечание: Существует также формула для emacs-helm — это другой проект.)\n\n### Используя Chocolatey (Windows)\n\nУчастники сообщества Helm добавили [пакет Helm](https://chocolatey.org/packages/kubernetes-helm) в\n[Chocolatey](https://chocolatey.org/). Этот пакет обычно актуален.\n\n```console\nchoco install kubernetes-helm\n```\n\n### Используя Scoop (Windows)\n\nУчастники сообщества Helm добавили [пакет Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) в [Scoop](https://scoop.sh). Этот пакет обычно актуален.\n\n```console\nscoop install helm\n```\n\n### Используя Winget (Windows)\n\nУчастники сообщества Helm добавили [пакет Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) в [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Этот пакет обычно актуален.\n\n```console\nwinget install Helm.Helm\n```\n\n### Используя Apt (Debian/Ubuntu)\n\nУчастники сообщества Helm добавили пакет Apt для Debian/Ubuntu. Этот пакет обычно\nактуален. Благодарим [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) за хостинг репозитория.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### Используя dnf/yum (Fedora)\n\nНачиная с Fedora 35, Helm доступен в официальном репозитории.\nВы можете установить Helm, выполнив:\n\n```console\nsudo dnf install helm\n```\n\n### Используя Snap\n\nСообщество [Snapcrafters](https://github.com/snapcrafters) поддерживает Snap-версию\n[пакета Helm](https://snapcraft.io/helm):\n\n```console\nsudo snap install helm --classic\n```\n\n### Используя pkg (FreeBSD)\n\nУчастники сообщества FreeBSD добавили [пакет Helm](https://www.freshports.org/sysutils/helm) в\n[FreeBSD Ports Collection](https://man.freebsd.org/ports).\nЭтот пакет обычно актуален.\n\n```console\npkg install helm\n```\n\n### Сборки для разработчиков\n\nПомимо релизов вы можете скачать или установить сборки для разработки Helm.\n\n### Canary-сборки\n\nCanary-сборки — это версии программного обеспечения Helm, собранные из последней\nветки `main`. Они не являются официальными релизами и могут быть нестабильными. Тем не менее,\nони позволяют протестировать новейшие функции.\n\nБинарные файлы Canary Helm хранятся на `get.helm.sh`. Вот\nссылки на распространённые сборки:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows\n  AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### Из исходного кода (Linux, macOS)\n\nСборка Helm из исходного кода требует немного больше усилий, но это лучший способ, если\nвы хотите протестировать последнюю (предрелизную) версию Helm.\n\nУ вас должна быть настроена рабочая среда Go.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\nПри необходимости скрипт загружает зависимости, кэширует их и проверяет\nконфигурацию. Затем он скомпилирует `helm` и поместит его в `bin/helm`.\n\n## Заключение\n\nВ большинстве случаев установка сводится к получению предварительно собранного бинарного файла `helm`.\nВ этом документе описаны дополнительные варианты для тех, кто хочет делать\nс Helm более сложные вещи.\n\nПосле успешной установки клиента Helm вы можете перейти к использованию\nHelm для управления чартами и [добавить репозиторий чартов stable](/intro/quickstart.md#initialize-a-helm-chart-repository).\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: Краткое руководство\ndescription: Как установить и начать работу с Helm, включая инструкции для дистрибутивов, FAQ и плагины.\nsidebar_position: 1\n---\n\nЭто руководство описывает, как быстро начать использовать Helm.\n\n## Предварительные требования\n\nДля успешного и безопасного использования Helm необходимо:\n\n1. Кластер Kubernetes\n2. Определение настроек безопасности для вашей установки (если требуется)\n3. Установка и настройка Helm\n\n### Установите Kubernetes или получите доступ к кластеру\n\n- У вас должен быть установлен Kubernetes. Для последней версии Helm мы рекомендуем последнюю стабильную версию Kubernetes, которая в большинстве случаев является предпоследней минорной версией.\n- Также у вас должна быть локально настроенная копия `kubectl`.\n\nСмотрите [Политику поддержки версий Helm](https://helm.sh/docs/topics/version_skew/), чтобы узнать максимально допустимое расхождение версий между Helm и Kubernetes.\n\n## Установка Helm\n\nЗагрузите бинарный релиз клиента Helm. Вы можете использовать такие инструменты, как `homebrew`, или посмотреть [официальную страницу релизов](https://github.com/helm/helm/releases).\n\nДля получения более подробной информации или других вариантов смотрите [руководство по установке](/intro/install.md).\n\n## Инициализация репозитория чартов Helm\n\nПосле установки Helm вы можете добавить репозиторий чартов. Смотрите [Artifact Hub](https://artifacthub.io/packages/search?kind=0) для поиска доступных репозиториев чартов Helm.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nПосле этого вы сможете посмотреть список чартов, которые можно установить:\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## Пример установки чарта\n\nЧтобы установить чарт, используйте команду `helm install`. У Helm есть несколько способов найти и установить чарт, но самый простой — использовать чарты `bitnami`.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nВ приведённом выше примере был установлен чарт `bitnami/mysql`, а имя нашего нового релиза — `mysql-1612624192`.\n\nЧтобы получить представление о возможностях этого чарта MySQL, выполните команду `helm show chart bitnami/mysql`. Или выполните `helm show all bitnami/mysql`, чтобы получить всю информацию о чарте.\n\nПри каждой установке чарта создаётся новый релиз. Таким образом, один чарт можно установить несколько раз в один и тот же кластер. И каждый из них может управляться и обновляться независимо.\n\nКоманда `helm install` очень мощная и имеет множество возможностей. Чтобы узнать больше, смотрите [Руководство по использованию Helm](/intro/using_helm.md).\n\n## Информация о релизах\n\nС помощью Helm легко увидеть, что было развёрнуто:\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nФункция `helm list` (или `helm ls`) покажет вам список всех развёрнутых релизов.\n\n## Удаление релиза\n\nЧтобы удалить релиз, используйте команду `helm uninstall`:\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nЭта команда удалит `mysql-1612624192` из Kubernetes, а также удалит все ресурсы, связанные с этим релизом, и историю релизов.\n\nЕсли указать флаг `--keep-history`, история релизов будет сохранена. В этом случае вы сможете запросить информацию об этом релизе:\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nПоскольку Helm отслеживает ваши релизы даже после их удаления, вы можете проверить историю кластера и даже восстановить релиз с помощью команды `helm rollback`.\n\n## Чтение справки\n\nЧтобы узнать больше о доступных командах Helm, используйте `helm help` или введите команду с флагом `-h`:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: Использование Helm\ndescription: Объясняет основы работы с Helm.\nsidebar_position: 3\n---\n\nВ этом руководстве объясняются основы использования Helm для управления пакетами на вашем кластере Kubernetes. Руководство предполагает, что вы уже [установили](/intro/install.md) Helm.\n\nЕсли вас просто интересует выполнение нескольких команд, вы можете начать с [Краткого руководства](/intro/quickstart.md). В этой главе описаны особенности команд Helm и объясняется, как использовать Helm.\n\n## Три основных концепции\n\n*Чарт* — это пакет Helm. Он содержит все определения ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes. Можно представить его как Kubernetes-эквивалент формулы Homebrew, пакета Apt dpkg или RPM-файла Yum.\n\n*Репозиторий* — это место, где можно собирать чарты и делиться ими. Это похоже на [архив CPAN](https://www.cpan.org) для Perl или [базу пакетов Fedora](https://src.fedoraproject.org/), но для пакетов Kubernetes.\n\n*Релиз* — это экземпляр чарта, работающий в кластере Kubernetes. Один чарт часто может быть установлен многократно в одном и том же кластере. Каждый раз при установке создаётся новый _релиз_. Рассмотрим чарт MySQL. Если вам нужны две базы данных в кластере, вы можете установить этот чарт дважды. Каждая установка будет иметь свой собственный _релиз_ со своим уникальным _именем релиза_.\n\nЗная эти концепции, можно описать работу Helm так:\n\nHelm устанавливает _чарты_ в Kubernetes, создавая новый _релиз_ для каждой установки. Чтобы найти новые чарты, можно воспользоваться поиском в _репозиториях_ чартов Helm.\n\n## 'helm search': Поиск чартов\n\nHelm поставляется с мощной командой поиска. Она может использоваться для поиска в двух различных типах источников:\n\n- `helm search hub` выполняет поиск в [Artifact Hub](https://artifacthub.io), который содержит списки чартов Helm из множества различных репозиториев.\n- `helm search repo` выполняет поиск в репозиториях, которые вы добавили в свой локальный клиент Helm (с помощью `helm repo add`). Этот поиск выполняется по локальным данным и не требует подключения к сети.\n\nВы можете найти общедоступные чарты, выполнив `helm search hub`:\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\nКоманда выше ищет все чарты `wordpress` в Artifact Hub.\n\nБез фильтра `helm search hub` показывает все доступные чарты.\n\n`helm search hub` показывает URL-адрес на [artifacthub.io](https://artifacthub.io/), но не фактический репозиторий Helm. `helm search hub --list-repo-url` показывает фактический URL репозитория Helm, что удобно, когда вы хотите добавить новый репозиторий: `helm repo add [NAME] [URL]`.\n\nИспользуя `helm search repo`, вы можете найти названия чартов в уже добавленных вами репозиториях:\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nHelm search использует нечёткий поиск (fuzzy string matching), поэтому вы можете вводить части слов или фраз:\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nПоиск — это хороший способ найти доступные пакеты. Как только вы нашли пакет, который хотите установить, вы можете использовать `helm install` для его установки.\n\n## 'helm install': Установка пакета\n\nЧтобы установить новый пакет, используйте команду `helm install`. В простейшем случае она принимает два аргумента: имя релиза, которое вы выбираете, и имя чарта, который вы хотите установить.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nТеперь чарт `wordpress` установлен. Обратите внимание, что при установке чарта создаётся новый объект _релиза_. Релиз выше называется `happy-panda`. (Если вы хотите, чтобы Helm сгенерировал имя за вас, не указывайте имя релиза и используйте `--generate-name`.)\n\nВо время установки клиент `helm` выводит полезную информацию о том, какие ресурсы были созданы, каково состояние релиза, а также есть ли дополнительные шаги настройки, которые вы можете или должны выполнить.\n\nHelm устанавливает ресурсы в следующем порядке:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nHelm не ждёт, пока все ресурсы будут запущены, прежде чем завершить работу. Многие чарты требуют Docker-образы размером более 600 МБ, и их установка в кластер может занять много времени.\n\nЧтобы отслеживать состояние релиза или повторно прочитать информацию о конфигурации, вы можете использовать `helm status`:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nВыше показано текущее состояние вашего релиза.\n\n### Настройка чарта перед установкой\n\nПри установке описанным способом будут использованы только параметры конфигурации по умолчанию для данного чарта. Часто вам потребуется настроить чарт в соответствии с вашими предпочтениями.\n\nЧтобы увидеть, какие параметры можно настроить в чарте, используйте `helm show values`:\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nЗатем вы можете переопределить любой из этих параметров в файле формата YAML и передать этот файл при установке.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nКоманда выше создаст пользователя MariaDB с именем `user0` и предоставит этому пользователю доступ к вновь созданной базе данных `user0db`, но примет все остальные значения по умолчанию для этого чарта.\n\nСуществует два способа передачи конфигурационных данных во время установки:\n\n- `--values` (или `-f`): указывает YAML-файл с переопределениями. Можно указать несколько раз, при этом самый правый файл будет иметь приоритет.\n- `--set`: указывает переопределения в командной строке.\n\nЕсли используются оба параметра, значения `--set` объединяются со значениями `--values` с более высоким приоритетом. Переопределения, указанные с помощью `--set`, сохраняются в Secret. Значения, которые были заданы через `--set`, можно просмотреть для данного релиза с помощью `helm get values <release-name>`. Значения `--set` можно сбросить, выполнив `helm upgrade` с указанием `--reset-values`.\n\n#### Формат и ограничения `--set`\n\nПараметр `--set` принимает ноль или более пар имя/значение. В простейшем случае он используется так: `--set name=value`. Эквивалент в YAML:\n\n```yaml\nname: value\n```\n\nНесколько значений разделяются символом `,`. Таким образом, `--set a=b,c=d` становится:\n\n```yaml\na: b\nc: d\n```\n\nПоддерживаются более сложные выражения. Например, `--set outer.inner=value` преобразуется в:\n\n```yaml\nouter:\n  inner: value\n```\n\nСписки можно задать, заключив значения в `{` и `}`. Например, `--set name={a, b, c}` преобразуется в:\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nОпределённые имена/ключи можно установить в `null` или в пустой массив `[]`. Например, `--set name=[],a=null` преобразует\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\nв\n\n```yaml\nname: []\na: null\n```\n\nНачиная с Helm 2.5.0, доступ к элементам списка возможен с помощью синтаксиса индекса массива. Например, `--set servers[0].port=80` становится:\n\n```yaml\nservers:\n  - port: 80\n```\n\nТаким образом можно задать несколько значений. Строка `--set servers[0].port=80,servers[0].host=example` становится:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nИногда вам нужно использовать специальные символы в строках `--set`. Вы можете использовать обратную косую черту для экранирования символов; `--set name=value1\\,value2` станет:\n\n```yaml\nname: \"value1,value2\"\n```\n\nАналогично можно экранировать точки, что может пригодиться, когда чарты используют функцию `toYaml` для разбора аннотаций, меток и селекторов узлов. Синтаксис `--set nodeSelector.\"kubernetes\\.io/role\"=master` становится:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nГлубоко вложенные структуры данных может быть сложно выразить с помощью `--set`. Разработчикам чартов рекомендуется учитывать использование `--set` при проектировании формата файла `values.yaml` (подробнее см. [Файлы Values](/chart_template_guide/values_files.md)).\n\n### Дополнительные методы установки\n\nКоманда `helm install` может устанавливать из нескольких источников:\n\n- Репозиторий чартов (как мы видели выше)\n- Локальный архив чарта (`helm install foo foo-0.1.1.tgz`)\n- Распакованная директория чарта (`helm install foo path/to/foo`)\n- Полный URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' и 'helm rollback': Обновление релиза и восстановление после сбоя\n\nКогда выходит новая версия чарта или когда вы хотите изменить конфигурацию своего релиза, вы можете использовать команду `helm upgrade`.\n\nОбновление берёт существующий релиз и обновляет его согласно предоставленной вами информации. Поскольку чарты Kubernetes могут быть большими и сложными, Helm пытается выполнить наименее инвазивное обновление. Он обновит только то, что изменилось с момента последнего релиза.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nВ приведённом выше случае релиз `happy-panda` обновляется тем же чартом, но с новым YAML-файлом:\n\n```yaml\nmariadb.auth.username: user1\n```\n\nМы можем использовать `helm get values`, чтобы проверить, применились ли новые настройки.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nКоманда `helm get` — полезный инструмент для просмотра релиза в кластере. Как мы видим выше, она показывает, что наши новые значения из `panda.yaml` были развёрнуты в кластере.\n\nТеперь, если что-то пошло не так во время релиза, легко откатиться к предыдущему релизу с помощью `helm rollback [RELEASE] [REVISION]`.\n\n```console\n$ helm rollback happy-panda 1\n```\n\nКоманда выше откатывает happy-panda к самой первой версии релиза. Версия релиза — это инкрементная ревизия. Каждый раз при установке, обновлении или откате номер ревизии увеличивается на 1. Первый номер ревизии всегда 1. Мы можем использовать `helm history [RELEASE]`, чтобы увидеть номера ревизий для определённого релиза.\n\n## Полезные опции для установки/обновления/отката\n\nСуществует несколько других полезных параметров, которые вы можете указать для настройки поведения Helm во время установки/обновления/отката. Обратите внимание, что это не полный список флагов CLI. Чтобы увидеть описание всех флагов, просто выполните `helm <command> --help`.\n\n- `--timeout`: значение [Go duration](https://golang.org/pkg/time/#ParseDuration), определяющее время ожидания завершения команд Kubernetes. По умолчанию `5m0s`.\n- `--wait`: ожидает, пока все Pod не перейдут в состояние готовности, PVC не будут привязаны, Deployment не будут иметь минимум (`Desired` минус `maxUnavailable`) Pod в состоянии готовности, а Service не получат IP-адрес (и Ingress при наличии `LoadBalancer`), прежде чем пометить релиз как успешный. Ожидание продолжается в течение времени, указанного в `--timeout`. Если таймаут достигнут, релиз будет помечен как `FAILED`. Примечание: в сценариях, где у Deployment значение `replicas` равно 1, а `maxUnavailable` не установлен в 0 как часть стратегии rolling update, `--wait` вернёт готовность, как только будет удовлетворено условие минимального количества Pod в состоянии готовности.\n- `--no-hooks`: пропускает выполнение хуков для команды.\n- `--recreate-pods` (доступно только для `upgrade` и `rollback`): этот флаг приведёт к пересозданию всех Pod (за исключением Pod, принадлежащих Deployment). (УСТАРЕЛО в Helm 3)\n\n## 'helm uninstall': Удаление релиза\n\nКогда потребуется удалить релиз из кластера, используйте команду `helm uninstall`:\n\n```console\n$ helm uninstall happy-panda\n```\n\nЭто удалит релиз из кластера. Вы можете просмотреть все ваши текущие развёрнутые релизы с помощью команды `helm list`:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nИз вывода выше видно, что релиз `happy-panda` был удалён.\n\nВ предыдущих версиях Helm при удалении релиза запись о его удалении сохранялась. В Helm 3 удаление также удаляет запись о релизе. Если вы хотите сохранить запись об удалении релиза, используйте `helm uninstall --keep-history`. Команда `helm list --uninstalled` покажет только те релизы, которые были удалены с флагом `--keep-history`.\n\nФлаг `helm list --all` покажет вам все записи о релизах, которые сохранил Helm, включая записи о неудачных или удалённых элементах (если был указан `--keep-history`):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nОбратите внимание, что поскольку релизы теперь удаляются по умолчанию, откат удалённого ресурса больше невозможен.\n\n## 'helm repo': Работа с репозиториями\n\nHelm 3 больше не поставляется с репозиторием чартов по умолчанию. Группа команд `helm repo` предоставляет команды для добавления, просмотра и удаления репозиториев.\n\nВы можете посмотреть, какие репозитории настроены, с помощью `helm repo list`:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nНовые репозитории можно добавить с помощью `helm repo add [NAME] [URL]`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nПоскольку репозитории чартов часто меняются, в любой момент вы можете убедиться, что ваш клиент Helm обновлён, выполнив `helm repo update`.\n\nРепозитории можно удалить с помощью `helm repo remove`.\n\n## Создание собственных чартов\n\n[Руководство по разработке чартов](/topics/charts.md) объясняет, как создавать свои собственные чарты. Но вы можете быстро начать работу с помощью команды `helm create`:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nТеперь у вас есть чарт в `./deis-workflow`. Вы можете редактировать его и создавать свои собственные шаблоны.\n\nПо мере редактирования чарта вы можете проверить его корректность с помощью `helm lint`.\n\nКогда придёт время упаковать чарт для распространения, вы можете выполнить команду `helm package`:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nИ этот чарт теперь можно легко установить с помощью `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nУпакованные чарты могут быть загружены в репозитории чартов. Подробнее см. документацию по [репозиториям чартов Helm](/topics/chart_repository.md).\n\n## Заключение\n\nВ этой главе рассмотрены основные способы использования клиента `helm`, включая поиск, установку, обновление и удаление. Также были рассмотрены полезные служебные команды, такие как `helm status`, `helm get` и `helm repo`.\n\nДля получения дополнительной информации об этих командах обратитесь к встроенной справке Helm: `helm help`.\n\nВ [следующей главе](/howto/charts_tips_and_tricks.md) мы рассмотрим процесс разработки чартов.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_install.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tinstallClient := action.NewInstall(actionConfig)\n\n\tinstallClient.DryRunOption = \"none\"\n\tinstallClient.ReleaseName = releaseName\n\tinstallClient.Namespace = settings.Namespace()\n\tinstallClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tinstallClient.CertFile,\n\t\tinstallClient.KeyFile,\n\t\tinstallClient.CaFile,\n\t\tinstallClient.InsecureSkipTLSverify,\n\t\tinstallClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tinstallClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tif chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil {\n\t\tif err := action.CheckDependencies(chart, chartDependencies); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !installClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tmanager := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          installClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t\tRegistryClient:   installClient.GetRegistryClient(),\n\t\t\t}\n\t\t\tif err := manager.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := installClient.RunWithContext(ctx, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run install: %w\", err)\n\t}\n\n\tlogger.Printf(\"release created:\\n%+v\", *release)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_list.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runList(logger *log.Logger, settings *cli.EnvSettings) error {\n\n\tactionConfig, err := initActionConfigList(settings, logger, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tlistClient := action.NewList(actionConfig)\n\t// Only list deployed\n\t//listClient.Deployed = true\n\tlistClient.All = true\n\tlistClient.SetStateMask()\n\n\tresults, err := listClient.Run()\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run list action: %w\", err)\n\t}\n\n\tfor _, rel := range results {\n\t\tlogger.Printf(\"list result: %+v\", rel)\n\t}\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_main.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"bufio\"\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\t\"os\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/registry\"\n)\n\nvar helmDriver string = os.Getenv(\"HELM_DRIVER\")\n\nfunc initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) {\n\treturn initActionConfigList(settings, logger, false)\n}\n\nfunc initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) {\n\n\tactionConfig := new(action.Configuration)\n\n\tnamespace := func() string {\n\t\t// For list action, you can pass an empty string instead of settings.Namespace() to list\n\t\t// all namespaces\n\t\tif allNamespaces {\n\t\t\treturn \"\"\n\t\t}\n\t\treturn settings.Namespace()\n\t}()\n\n\tif err := actionConfig.Init(\n\t\tsettings.RESTClientGetter(),\n\t\tnamespace,\n\t\thelmDriver,\n\t\tlogger.Printf); err != nil {\n\t\treturn nil, err\n\t}\n\n\treturn actionConfig, nil\n}\n\nfunc newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) {\n\topts := []registry.ClientOption{\n\t\tregistry.ClientOptDebug(settings.Debug),\n\t\tregistry.ClientOptEnableCache(true),\n\t\tregistry.ClientOptWriter(os.Stderr),\n\t\tregistry.ClientOptCredentialsFile(settings.RegistryConfig),\n\t}\n\tif plainHTTP {\n\t\topts = append(opts, registry.ClientOptPlainHTTP())\n\t}\n\n\t// Create a new registry client\n\tregistryClient, err := registry.NewClient(opts...)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) {\n\tif certFile != \"\" && keyFile != \"\" || caFile != \"\" || insecureSkipTLSverify {\n\t\tregistryClient, err := registry.NewRegistryClientWithTLS(\n\t\t\tlogger.Writer(),\n\t\t\tcertFile,\n\t\t\tkeyFile,\n\t\t\tcaFile,\n\t\t\tinsecureSkipTLSverify,\n\t\t\tsettings.RegistryConfig,\n\t\t\tsettings.Debug)\n\n\t\tif err != nil {\n\t\t\treturn nil, err\n\t\t}\n\t\treturn registryClient, nil\n\t}\n\tregistryClient, err := newRegistryClient(settings, plainHTTP)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc main() {\n\n\tlogger := log.Default()\n\n\t// For convenience, initialize SDK setting via CLI mechanism\n\tsettings := cli.New()\n\n\t// Release name, chart and values\n\treleaseName := \"helm-sdk-example\"\n\tchartRef := \"oci://ghcr.io/stefanprodan/charts/podinfo\"\n\treleaseValues := map[string]interface{}{\n\t\t\"replicaCount\": \"2\",\n\t}\n\n\t// Pull the chart to the local filesystem\n\tif err := runPull(logger, settings, chartRef, \"6.4.1\"); err != nil {\n\t\tfmt.Printf(\"failed to run pull: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// Install the chart (from the pulled chart local archive)\n\tif err := runInstall(context.TODO(), logger, settings, releaseName, \"./podinfo-6.4.1.tgz\", \"\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run install: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart installed. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Upgrade to version 6.5.4, updating the replicaCount to three\n\treleaseValues[\"replicaCount\"] = \"3\"\n\tif err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, \"6.5.4\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run upgrade: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart upgraded. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Uninstall the chart\n\tif err := runUninstall(logger, settings, releaseName); err != nil {\n\t\tfmt.Printf(\"failed to run uninstall: %+v\", err)\n\t\tos.Exit(1)\n\t}\n}\n\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_pull.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tregistryClient, err := newRegistryClient(settings, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tactionConfig.RegistryClient = registryClient\n\n\tpullClient := action.NewPullWithOpts(\n\t\taction.WithConfig(actionConfig))\n\t// client.RepoURL = \"\"\n\tpullClient.DestDir = \"./\"\n\tpullClient.Settings = settings\n\tpullClient.Version = chartVersion\n\n\tresult, err := pullClient.Run(chartRef)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to pull chart: %w\", err)\n\t}\n\n\tlogger.Printf(\"%+v\", result)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_uninstall.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tuninstallClient := action.NewUninstall(actionConfig)\n\tuninstallClient.DeletionPropagation = \"foreground\" // \"background\" or \"orphan\"\n\n\tresult, err := uninstallClient.Run(releaseName)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run uninstall action: %w\", err)\n\t}\n\tif result != nil {\n\t\tlogger.Printf(\"result: %+v\\n\", *result.Release)\n\t}\n\n\tlogger.Printf(\"release \\\"%s\\\" uninstalled\\n\", releaseName)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_upgrade.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tupgradeClient := action.NewUpgrade(actionConfig)\n\n\tupgradeClient.Namespace = settings.Namespace()\n\tupgradeClient.DryRunOption = \"none\"\n\tupgradeClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tupgradeClient.CertFile,\n\t\tupgradeClient.KeyFile,\n\t\tupgradeClient.CaFile,\n\t\tupgradeClient.InsecureSkipTLSverify,\n\t\tupgradeClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"missing registry client: %w\", err)\n\t}\n\tupgradeClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to load chart: %w\", err)\n\t}\n\tif req := chart.Metadata.Dependencies; req != nil {\n\t\tif err := action.CheckDependencies(chart, req); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !upgradeClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tman := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          upgradeClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t}\n\t\t\tif err := man.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run upgrade action: %w\", err)\n\t}\n\n\tlogger.Printf(\"release: %+v\", release)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx",
    "content": "---\ntitle: Примеры\ndescription: Примеры различных возможностей Helm SDK\nsidebar_position: 2\n---\nimport Install from './_install.mdx'\nimport List from './_list.mdx'\nimport Main from './_main.mdx'\nimport Pull from './_pull.mdx'\nimport Uninstall from './_uninstall.mdx'\nimport Upgrade from './_upgrade.mdx'\n\nВ этом документе представлен ряд примеров использования Helm SDK.\nЦель — продемонстрировать различные функциональные возможности SDK.\n\nФинальный пример показывает драйвер `main.go` ([ссылка](#driver)), который запускает приведённые ниже действия и включает необходимые вспомогательные функции.\n\nКод примеров находится в директории [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples).\nОн полностью функционален.\n\n## Действия\n\n\n### Действие Install\n\nЭтот пример устанавливает указанный чарт/релиз для заданной версии и значений:\n\n<Install />\n\n### Действие Upgrade\n\nЭтот пример обновляет указанный релиз с заданным чартом, версией и значениями:\n\n<Upgrade />\n\n### Действие Uninstall\n\nЭтот пример удаляет указанный релиз:\n\n<Uninstall />\n\n### Действие List\n\nЭтот пример выводит список всех установленных чартов (в текущем настроенном пространстве имён):\n\n<List />\n\n### Действие Pull\n\nЭтот пример загружает чарт из OCI-репозитория:\n\n<Pull />\n\n## Драйвер\n\nДрайвер демонстрирует вспомогательные функции, необходимые для работы действий Helm SDK. Он показывает приведённые выше примеры в действии: загрузку, установку, обновление и удаление чарта 'podinfo' из OCI-репозитория.\n\n<Main />\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: Введение\ndescription: Введение в Helm Go SDK\nsidebar_position: 1\n---\nHelm Go SDK позволяет пользовательскому программному обеспечению использовать чарты Helm и функциональность Helm для управления развёртыванием программного обеспечения в Kubernetes.\n(На самом деле, CLI Helm — это всего лишь один из таких инструментов!)\n\nВ настоящее время SDK функционально отделён от CLI Helm.\nSDK может использоваться (и используется) автономными инструментами.\nПроект Helm гарантирует стабильность API для SDK.\nСледует отметить, что в SDK всё ещё есть некоторые шероховатости, оставшиеся после первоначальной работы по отделению CLI и SDK. Проект Helm намерен улучшить их со временем.\n\nПолная документация API доступна по адресу [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3).\n\nНиже приведён краткий обзор основных типов пакетов и простой пример.\nДополнительные примеры и более полнофункциональный драйвер смотрите в разделе [Примеры](/sdk/examples.mdx).\n\n## Обзор основных пакетов\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action):\n  Содержит основной «клиент» для выполнения операций Helm.\n  Это тот же пакет, который CLI использует «под капотом».\n  Если вам нужно просто выполнять базовые команды Helm из другой программы на Go, этот пакет для вас\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil):\n  Методы и вспомогательные функции для загрузки и работы с чартами\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) и его подпакеты:\n  Содержит все обработчики для стандартных переменных окружения Helm, а подпакеты отвечают за обработку вывода и файлов values\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release):\n  Определяет объект `Release` и статусы\n\nПомимо этих существует множество других пакетов, поэтому обратитесь к документации за дополнительной информацией!\n\n### Простой пример\nЭто простой пример выполнения `helm list` с использованием Go SDK.\nДополнительные примеры смотрите в разделе [Примеры](/sdk/examples.mdx).\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## Совместимость\n\nHelm SDK явно следует гарантиям обратной совместимости Helm:\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\nТо есть несовместимые изменения будут вноситься только при смене мажорных версий.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/index.mdx",
    "content": "---\ntitle: Go SDK\nsidebar_position: 7\n---\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: Расширенные методы работы с Helm\ndescription: Описание различных расширенных возможностей для опытных пользователей Helm\nsidebar_position: 9\n---\n\nВ этом разделе описываются различные расширенные возможности и методы использования Helm.\nИнформация предназначена для опытных пользователей Helm, которые хотят\nвыполнять расширенную настройку и управление чартами и релизами. Каждая\nиз этих возможностей имеет свои особенности и ограничения, поэтому использовать\nих следует осторожно и с глубоким пониманием Helm. Иными словами,\nпомните о [принципе Питера Паркера](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility).\n\n## Пост-рендеринг\nПост-рендеринг позволяет вручную изменять, настраивать и проверять отрендеренные\nманифесты перед их установкой в Helm. Это даёт возможность пользователям\nс расширенными потребностями применять инструменты вроде [`kustomize`](https://kustomize.io)\nдля изменения конфигурации без необходимости форкать публичный чарт или требовать\nот разработчиков чарта указания каждого параметра. Также существуют сценарии\nдля внедрения общих инструментов и sidecar-контейнеров в корпоративных средах\nили анализа манифестов перед развёртыванием.\n\n### Предварительные требования\n- Helm 3.1+\n\n### Использование\nПост-рендерер может быть любым исполняемым файлом, который принимает отрендеренные\nманифесты Kubernetes через STDIN и возвращает валидные манифесты Kubernetes\nчерез STDOUT. В случае ошибки он должен вернуть ненулевой код завершения.\nЭто единственный «API» между двумя компонентами и он обеспечивает большую\nгибкость в работе с процессом пост-рендеринга.\n\nПост-рендерер можно использовать с командами `install`, `upgrade` и `template`.\nДля этого укажите флаг `--post-renderer` с путём к исполняемому файлу рендерера:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nЕсли путь не содержит разделителей, поиск будет выполняться в $PATH, в противном случае\nотносительные пути будут преобразованы в полные.\n\nЕсли вы хотите использовать несколько пост-рендереров, вызывайте их все в скрипте или\nвместе в любом созданном вами бинарном инструменте. В bash это может выглядеть так:\n`renderer1 | renderer2 | renderer3`.\n\nПример использования `kustomize` в качестве пост-рендерера можно посмотреть\n[здесь](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n### Предостережения\nПри использовании пост-рендереров важно помнить о нескольких вещах.\nГлавное — все, кто изменяет данный релиз, **ДОЛЖНЫ** использовать тот же рендерер\nдля обеспечения воспроизводимых сборок. Эта функция намеренно позволяет любому\nпользователю менять или отключать используемый рендерер, но делать это следует\nосознанно, чтобы избежать случайных изменений или потери данных.\n\nЕщё один важный момент — безопасность. Если вы используете пост-рендерер,\nубедитесь, что он получен из надёжного источника (как и любой другой\nисполняемый файл). Использование непроверенных или ненадёжных рендереров НЕ\nрекомендуется, поскольку они имеют полный доступ к отрендеренным шаблонам,\nкоторые часто содержат секретные данные.\n\n### Пользовательские пост-рендереры\nЭтап пост-рендеринга предоставляет ещё большую гибкость при использовании Go SDK.\nПост-рендерер должен лишь реализовать следующий интерфейс:\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nДля получения дополнительной информации об использовании Go SDK смотрите [раздел Go SDK](#go-sdk).\n\n## Go SDK\nВ Helm 3 появился полностью переработанный Go SDK для улучшения работы при\nсоздании программного обеспечения и инструментов, использующих Helm. Полная документация\nнаходится в [разделе Go SDK](/sdk/gosdk.md).\n\n## Бэкенды хранения\n\nВ Helm 3 по умолчанию информация о релизах хранится в объектах Secret в\nпространстве имён релиза. В Helm 2 по умолчанию информация о релизах хранилась\nв объектах ConfigMap в пространстве имён экземпляра Tiller. В следующих\nподразделах описывается настройка различных бэкендов. Конфигурация выполняется\nчерез переменную окружения `HELM_DRIVER`, которую можно установить в одно из значений:\n`[configmap, secret, sql]`.\n\n### Бэкенд хранения ConfigMap\n\nЧтобы включить бэкенд ConfigMap, установите переменную окружения\n`HELM_DRIVER` в значение `configmap`.\n\nВ оболочке это делается так:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nЕсли вы хотите перейти с бэкенда по умолчанию на бэкенд ConfigMap, вам придётся\nвыполнить миграцию самостоятельно. Получить информацию о релизах можно с помощью\nследующей команды:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**ВАЖНО ДЛЯ ПРОДАКШЕНА**: Информация о релизах включает содержимое чартов и\nфайлов values, поэтому может содержать конфиденциальные данные (пароли,\nзакрытые ключи и другие учётные данные), которые необходимо защищать от\nнесанкционированного доступа. При управлении авторизацией Kubernetes с помощью\n[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) можно\nпредоставить более широкий доступ к ресурсам ConfigMap, ограничив при этом\nдоступ к ресурсам Secret. Например, встроенная [роль](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\n«view» предоставляет доступ к большинству ресурсов, но не к Secret. Кроме того,\nданные Secret можно настроить для [зашифрованного хранения](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).\nУчитывайте это при переходе на бэкенд ConfigMap, так как это может раскрыть\nконфиденциальные данные вашего приложения.\n\n### Бэкенд хранения SQL\n\nСуществует бэкенд хранения SQL в ***бета***-версии, который хранит информацию\nо релизах в базе данных SQL.\n\nТакой бэкенд хранения особенно полезен, если информация о ваших релизах\nпревышает 1 МБ (в этом случае её нельзя хранить в ConfigMap/Secret\nиз-за внутренних ограничений базового хранилища etcd в Kubernetes).\n\nЧтобы включить бэкенд SQL, разверните базу данных SQL и установите переменную\nокружения `HELM_DRIVER` в значение `sql`. Данные подключения к БД задаются через\nпеременную окружения `HELM_DRIVER_SQL_CONNECTION_STRING`.\n\nВ оболочке это делается так:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Примечание: На данный момент поддерживается только PostgreSQL.\n\n**ВАЖНО ДЛЯ ПРОДАКШЕНА**: Рекомендуется:\n- Подготовить базу данных для продакшена. Для PostgreSQL обратитесь к документации по [администрированию сервера](https://www.postgresql.org/docs/12/admin.html)\n- Включить [управление правами доступа](/topics/permissions_sql_storage_backend.md) для\nотражения Kubernetes RBAC для информации о релизах\n\nЕсли вы хотите перейти с бэкенда по умолчанию на бэкенд SQL, вам придётся\nвыполнить миграцию самостоятельно. Получить информацию о релизах можно с помощью\nследующей команды:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Архитектура Helm\ndescription: Описание архитектуры Helm на высоком уровне.\nsidebar_position: 8\n---\n\n# Архитектура Helm\n\nЭтот документ описывает архитектуру Helm на высоком уровне.\n\n## Назначение Helm\n\nHelm — это инструмент для управления пакетами Kubernetes, называемыми _чартами_. Helm может выполнять следующие задачи:\n\n- Создавать новые чарты с нуля\n- Упаковывать чарты в архивные файлы (tgz)\n- Взаимодействовать с репозиториями чартов, где они хранятся\n- Устанавливать и удалять чарты в существующий кластер Kubernetes\n- Управлять жизненным циклом релизов чартов, установленных с помощью Helm\n\nДля Helm существуют три важных концепции:\n\n1. _Чарт_ — это набор информации, необходимой для создания экземпляра приложения Kubernetes.\n2. _Конфигурация_ содержит информацию о настройках, которая может быть объединена с упакованным чартом для создания объекта, готового к релизу.\n3. _Релиз_ — это работающий экземпляр _чарта_, объединённый с конкретной _конфигурацией_.\n\n## Компоненты\n\nHelm — это исполняемый файл, реализованный в виде двух отдельных частей:\n\n**Клиент Helm** — это клиент командной строки для конечных пользователей. Клиент отвечает за следующее:\n\n- Локальная разработка чартов\n- Управление репозиториями\n- Управление релизами\n- Взаимодействие с библиотекой Helm\n  - Отправка чартов на установку\n  - Запрос на обновление или удаление существующих релизов\n\n**Библиотека Helm** предоставляет логику для выполнения всех операций Helm. Она взаимодействует с сервером API Kubernetes и обеспечивает следующие возможности:\n\n- Объединение чарта и конфигурации для создания релиза\n- Установка чартов в Kubernetes с предоставлением соответствующего объекта релиза\n- Обновление и удаление чартов посредством взаимодействия с Kubernetes\n\nАвтономная библиотека Helm инкапсулирует логику Helm, что позволяет использовать её различными клиентами.\n\n## Реализация\n\nКлиент и библиотека Helm написаны на языке программирования Go.\n\nБиблиотека использует клиентскую библиотеку Kubernetes для взаимодействия с Kubernetes. В настоящее время эта библиотека использует REST+JSON. Информация хранится в объектах Secret в Kubernetes. Для работы Helm не требуется собственная база данных.\n\nФайлы конфигурации по возможности пишутся на YAML.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: Руководство по репозиториям чартов\ndescription: Как создавать репозитории чартов Helm и работать с ними.\nsidebar_position: 6\n---\n\nВ этом разделе объясняется, как создавать репозитории чартов Helm и работать с ними. Репозиторий чартов — это место, где можно хранить и распространять упакованные чарты.\n\nРаспределённый репозиторий чартов сообщества Helm находится на [Artifact Hub](https://artifacthub.io/packages/search?kind=0) и открыт для участия. Однако Helm также позволяет создавать и запускать собственный репозиторий чартов. Это руководство объясняет, как это сделать. Если вы планируете создать репозиторий чартов, возможно, стоит рассмотреть использование [OCI-реестра](/topics/registries.md).\n\n## Предварительные требования\n\n* Пройдите [Руководство по быстрому старту](/intro/quickstart.md)\n* Ознакомьтесь с документом [Чарты](/topics/charts.md)\n\n## Создание репозитория чартов\n\n_Репозиторий чартов_ — это HTTP-сервер, содержащий файл `index.yaml` и, опционально, упакованные чарты. Когда вы готовы поделиться своими чартами, предпочтительный способ — загрузить их в репозиторий чартов.\n\nНачиная с Helm 2.2.0 поддерживается клиентская SSL-аутентификация к репозиторию. Другие протоколы аутентификации могут быть доступны через плагины.\n\nПоскольку репозиторий чартов может быть любым HTTP-сервером, способным отдавать YAML и tar-файлы и отвечать на GET-запросы, у вас есть множество вариантов для размещения собственного репозитория чартов. Например, вы можете использовать бакет Google Cloud Storage (GCS), бакет Amazon S3, GitHub Pages или даже создать собственный веб-сервер.\n\n### Структура репозитория чартов\n\nРепозиторий чартов состоит из упакованных чартов и специального файла `index.yaml`, содержащего индекс всех чартов в репозитории. Часто чарты, описанные в `index.yaml`, размещаются на том же сервере, что и [файлы происхождения](/topics/provenance.md).\n\nНапример, структура репозитория `https://example.com/charts` может выглядеть так:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nВ этом случае индексный файл будет содержать информацию об одном чарте — Alpine — и предоставлять URL для скачивания `https://example.com/charts/alpine-0.1.2.tgz` для этого чарта.\n\nНе обязательно, чтобы пакет чарта находился на том же сервере, что и файл `index.yaml`. Однако часто это самый простой вариант.\n\n### Индексный файл\n\nИндексный файл — это YAML-файл с именем `index.yaml`. Он содержит метаданные о пакете, включая содержимое файла `Chart.yaml` чарта. Валидный репозиторий чартов должен иметь индексный файл. Индексный файл содержит информацию о каждом чарте в репозитории чартов. Команда `helm repo index` генерирует индексный файл на основе заданного локального каталога, содержащего упакованные чарты.\n\nВот пример индексного файла:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Размещение репозиториев чартов\n\nВ этой части показаны несколько способов размещения репозитория чартов.\n\n### Google Cloud Storage\n\nПервый шаг — **создать бакет GCS**. Назовём его `fantastic-charts`.\n\n![Создание бакета GCS](/img/helm2/create-a-bucket.png)\n\nЗатем сделайте бакет публичным, **отредактировав права доступа**.\n\n![Редактирование прав](/img/helm2/edit-permissions.png)\n\nДобавьте эту запись, чтобы **сделать бакет публичным**:\n\n![Сделать бакет публичным](/img/helm2/make-bucket-public.png)\n\nПоздравляем, теперь у вас есть пустой бакет GCS, готовый для размещения чартов!\n\nВы можете загружать репозиторий чартов с помощью командной строки Google Cloud Storage или через веб-интерфейс GCS. Публичный бакет GCS доступен по простому HTTPS-адресу: `https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith\n\nВы также можете настроить репозитории чартов с помощью Cloudsmith. Подробнее о репозиториях чартов с Cloudsmith читайте [здесь](https://help.cloudsmith.io/docs/helm-chart-repository).\n\n### JFrog Artifactory\n\nАналогично вы можете настроить репозитории чартов с помощью JFrog Artifactory. Подробнее о репозиториях чартов с JFrog Artifactory читайте [здесь](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories).\n\n### Пример с GitHub Pages\n\nАналогичным образом можно создать репозиторий чартов с помощью GitHub Pages.\n\nGitHub позволяет размещать статические веб-страницы двумя способами:\n\n- Настроив проект для обслуживания содержимого каталога `docs/`\n- Настроив проект для обслуживания определённой ветки\n\nМы используем второй подход, хотя первый столь же прост.\n\nПервый шаг — **создать ветку gh-pages**. Вы можете сделать это локально:\n\n```console\n$ git checkout -b gh-pages\n```\n\nИли через веб-браузер, используя кнопку **Branch** в вашем репозитории GitHub:\n\n![Создание ветки GitHub Pages](/img/helm2/create-a-gh-page-button.png)\n\nДалее убедитесь, что ваша **ветка gh-pages** настроена как GitHub Pages. Перейдите в **Settings** репозитория и прокрутите вниз до раздела **GitHub Pages**, настроив его следующим образом:\n\n![Настройка ветки GitHub Pages](/img/helm2/set-a-gh-page.png)\n\nПо умолчанию **Source** обычно устанавливается на **gh-pages branch**. Если это не так, выберите её.\n\nПри желании вы можете использовать **собственный домен**.\n\nТакже убедитесь, что включена опция **Enforce HTTPS**, чтобы при обслуживании чартов использовался **HTTPS**.\n\nПри такой настройке вы можете использовать основную ветку для хранения кода чартов, а **ветку gh-pages** — как репозиторий чартов, например: `https://USERNAME.github.io/REPONAME`. Демонстрационный репозиторий [TS Charts](https://github.com/technosophos/tscharts) доступен по адресу `https://technosophos.github.io/tscharts/`.\n\nЕсли вы решили использовать 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).\n\n### Обычные веб-серверы\n\nЧтобы настроить обычный веб-сервер для обслуживания чартов Helm, вам нужно сделать следующее:\n\n- Поместите индекс и чарты в каталог, который может обслуживать сервер\n- Убедитесь, что файл `index.yaml` доступен без аутентификации\n- Убедитесь, что файлы `yaml` отдаются с правильным типом содержимого (`text/yaml` или `text/x-yaml`)\n\nНапример, если вы хотите обслуживать чарты из `$WEBROOT/charts`, создайте каталог `charts/` в корне веб-сервера и поместите индексный файл и чарты в эту папку.\n\n### Сервер репозитория ChartMuseum\n\nChartMuseum — это сервер репозитория чартов 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/).\n\nВы также можете использовать сервер [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) для размещения репозитория чартов в локальной файловой системе.\n\n### GitLab Package Registry\n\nС помощью GitLab вы можете публиковать чарты Helm в Package Registry вашего проекта. Подробнее о настройке репозитория пакетов Helm с GitLab читайте [здесь](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Управление репозиториями чартов\n\nТеперь, когда у вас есть репозиторий чартов, в последней части этого руководства объясняется, как поддерживать чарты в этом репозитории.\n\n### Хранение чартов в репозитории\n\nТеперь загрузим чарт и индексный файл в репозиторий. Чарты в репозитории должны быть упакованы (`helm package chart-name/`) и правильно версионированы (в соответствии с рекомендациями [SemVer 2](https://semver.org/)).\n\nСледующие шаги представляют пример рабочего процесса, но вы можете использовать любой удобный вам процесс для хранения и обновления чартов в репозитории.\n\nКогда у вас есть готовый упакованный чарт, создайте новый каталог и переместите упакованный чарт в него.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nПоследняя команда принимает путь к только что созданному локальному каталогу и URL вашего удалённого репозитория чартов, создавая файл `index.yaml` в указанном каталоге.\n\nТеперь вы можете загрузить чарт и индексный файл в репозиторий с помощью инструмента синхронизации или вручную. Если вы используете Google Cloud Storage, посмотрите этот [пример рабочего процесса](/howto/chart_repository_sync_example.md) с использованием клиента gsutil. Для GitHub просто поместите чарты в соответствующую целевую ветку.\n\n### Добавление новых чартов в существующий репозиторий\n\nКаждый раз, когда вы хотите добавить новый чарт в репозиторий, необходимо заново сгенерировать индекс. Команда `helm repo index` полностью перестраивает файл `index.yaml` с нуля, включая только те чарты, которые находятся локально.\n\nОднако вы можете использовать флаг `--merge` для инкрементального добавления новых чартов в существующий файл `index.yaml` (отличный вариант при работе с удалённым репозиторием, таким как GCS). Выполните `helm repo index --help`, чтобы узнать больше.\n\nУбедитесь, что вы загружаете как обновлённый файл `index.yaml`, так и чарт. И если вы сгенерировали файл происхождения, загрузите и его.\n\n### Распространение чартов\n\nКогда вы готовы поделиться своими чартами, просто сообщите кому-нибудь URL вашего репозитория.\n\nОттуда они добавят репозиторий в свой клиент Helm с помощью команды `helm repo add [NAME] [URL]`, используя любое имя для ссылки на репозиторий.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nЕсли чарты защищены HTTP-аутентификацией (Basic Auth), вы также можете указать имя пользователя и пароль:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Примечание:** Репозиторий не будет добавлен, если он не содержит валидного файла `index.yaml`.\n\n**Примечание:** Если ваш репозиторий Helm использует, например, самоподписанный сертификат, вы можете использовать `helm repo add --insecure-skip-tls-verify ...`, чтобы пропустить проверку CA.\n\nПосле этого ваши пользователи смогут искать ваши чарты. После обновления репозитория они могут использовать команду `helm repo update` для получения актуальной информации о чартах.\n\n*Под капотом команды `helm repo add` и `helm repo update` загружают файл index.yaml и сохраняют его в каталоге `$XDG_CACHE_HOME/helm/repository/cache/`. Именно там функция `helm search` находит информацию о чартах.*\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: Тестирование чартов\ndescription: Описывает, как запускать и тестировать ваши чарты.\nsidebar_position: 3\n---\n\nЧарт содержит множество ресурсов и компонентов Kubernetes, работающих вместе. Как автор чарта, вы можете написать тесты, которые проверят, что ваш чарт работает корректно после установки. Эти тесты также помогут пользователям чарта понять, что именно должен делать ваш чарт.\n\n**Тест** в Helm-чарте располагается в директории `templates/` и представляет собой определение Job, указывающее контейнер с заданной командой для выполнения. Контейнер должен завершиться успешно (код выхода 0), чтобы тест считался пройденным. Определение Job должно содержать аннотацию тестового хука: `helm.sh/hook: test`.\n\nОбратите внимание, что до Helm v3 определение Job должно было содержать одну из следующих аннотаций: `helm.sh/hook: test-success` или `helm.sh/hook: test-failure`. Аннотация `helm.sh/hook: test-success` по-прежнему принимается для обратной совместимости как альтернатива `helm.sh/hook: test`.\n\nПримеры тестов:\n\n- Проверка того, что конфигурация из файла values.yaml была правильно применена.\n  - Убедитесь, что имя пользователя и пароль работают корректно\n  - Убедитесь, что неправильные имя пользователя и пароль не работают\n- Проверка того, что ваши сервисы запущены и правильно балансируют нагрузку\n- и т.д.\n\nВы можете запустить предопределённые тесты Helm для релиза с помощью команды `helm test <RELEASE_NAME>`. Для пользователя чарта это отличный способ убедиться, что их релиз чарта (или приложения) работает как ожидается.\n\n## Пример теста\n\nКоманда [helm create](/helm/helm_create.md) автоматически создаёт ряд папок и файлов. Чтобы попробовать функциональность helm test, сначала создайте демо-чарт.\n\n```console\n$ helm create demo\n```\n\nТеперь вы увидите следующую структуру в вашем демо-чарте.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nВ файле `demo/templates/tests/test-connection.yaml` вы найдёте тест, который можете попробовать. Ниже приведено определение тестового Pod:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Запуск набора тестов для релиза\n\nСначала установите чарт в ваш кластер для создания релиза. Возможно, вам придётся подождать, пока все Pod станут активными; если вы запустите тест сразу после установки, велика вероятность временного сбоя, и вам потребуется повторить тестирование.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Примечания\n\n- Вы можете определить любое количество тестов в одном yaml-файле или распределить их по нескольким yaml-файлам в директории `templates/`.\n- Рекомендуется размещать набор тестов в поддиректории `tests/`, например `<chart-name>/templates/tests/`, для лучшей изоляции.\n- Тест является [хуком Helm](/topics/charts_hooks.md), поэтому к тестовым ресурсам можно применять аннотации `helm.sh/hook-weight` и `helm.sh/hook-delete-policy`.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: Чарты\ndescription: Описывает формат чартов и даёт базовое руководство по созданию чартов в Helm.\nsidebar_position: 1\n---\n\nHelm использует формат упаковки, называемый _чартами_. Чарт — это набор файлов, описывающих связанный набор ресурсов Kubernetes. Один чарт может использоваться для развёртывания чего-то простого, например пода с memcached, или чего-то сложного, например полного стека веб-приложения с HTTP-серверами, базами данных, кешами и так далее.\n\nЧарты создаются как файлы, организованные в определённую структуру каталогов. Их можно упаковывать в версионированные архивы для развёртывания.\n\nЕсли вы хотите скачать и посмотреть файлы опубликованного чарта без его установки, вы можете сделать это с помощью команды `helm pull chartrepo/chartname`.\n\nЭтот документ описывает формат чартов и даёт базовое руководство по созданию чартов в Helm.\n\n## Файловая структура чарта\n\nЧарт организован как набор файлов внутри каталога. Имя каталога — это имя чарта (без информации о версии). Таким образом, чарт, описывающий WordPress, будет храниться в каталоге `wordpress/`.\n\nВнутри этого каталога Helm ожидает структуру, соответствующую следующей:\n\n```text\nwordpress/\n  Chart.yaml          # A YAML file containing information about the chart\n  LICENSE             # OPTIONAL: A plain text file containing the license for the chart\n  README.md           # OPTIONAL: A human-readable README file\n  values.yaml         # The default configuration values for this chart\n  values.schema.json  # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file\n  charts/             # A directory containing any charts upon which this chart depends.\n  crds/               # Custom Resource Definitions\n  templates/          # A directory of templates that, when combined with values,\n                      # will generate valid Kubernetes manifest files.\n  templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes\n```\n\nHelm резервирует использование каталогов `charts/`, `crds/` и `templates/`, а также перечисленных имён файлов. Остальные файлы останутся без изменений.\n\n## Файл Chart.yaml\n\nФайл `Chart.yaml` является обязательным для чарта. Он содержит следующие поля:\n\n```yaml\napiVersion: The chart API version (required)\nname: The name of the chart (required)\nversion: The version of the chart (required)\nkubeVersion: A SemVer range of compatible Kubernetes versions (optional)\ndescription: A single-sentence description of this project (optional)\ntype: The type of the chart (optional)\nkeywords:\n  - A list of keywords about this project (optional)\nhome: The URL of this projects home page (optional)\nsources:\n  - A list of URLs to source code for this project (optional)\ndependencies: # A list of the chart requirements (optional)\n  - name: The name of the chart (nginx)\n    version: The version of the chart (\"1.2.3\")\n    repository: (optional) The repository URL (\"https://example.com/charts\") or alias (\"@repo-name\")\n    condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )\n    tags: # (optional)\n      - Tags can be used to group charts for enabling/disabling together\n    import-values: # (optional)\n      - 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.\n    alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times\nmaintainers: # (optional)\n  - name: The maintainers name (required for each maintainer)\n    email: The maintainers email (optional for each maintainer)\n    url: A URL for the maintainer (optional for each maintainer)\nicon: A URL to an SVG or PNG image to be used as an icon (optional).\nappVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.\ndeprecated: Whether this chart is deprecated (optional, boolean)\nannotations:\n  example: A list of annotations keyed by name (optional).\n```\n\nНачиная с версии [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), дополнительные поля не допускаются. Рекомендуемый подход — добавлять пользовательские метаданные в `annotations`.\n\n### Чарты и версионирование\n\nКаждый чарт должен иметь номер версии. Версия должна соответствовать стандарту [SemVer 2](https://semver.org/spec/v2.0.0.html), но это не строго обязательно. В отличие от Helm Classic, Helm v2 и более поздние версии используют номера версий как маркеры релизов. Пакеты в репозиториях идентифицируются по имени и версии.\n\nНапример, чарт `nginx`, в котором поле version установлено как `version: 1.2.3`, будет называться:\n\n```text\nnginx-1.2.3.tgz\n```\n\nПоддерживаются и более сложные имена SemVer 2, такие как `version: 1.2.3-alpha.1+ef365`. Однако имена, не соответствующие SemVer, явно запрещены системой. Исключение составляют версии в формате `x` или `x.y`. Например, если указана версия с начальной буквой v или без всех 3 частей (например, v1.2), система попытается преобразовать её в корректную семантическую версию (например, v1.2.0).\n\n**ПРИМЕЧАНИЕ:** В то время как Helm Classic и Deployment Manager были сильно ориентированы на GitHub при работе с чартами, Helm v2 и более поздние версии не полагаются на GitHub или даже Git и не требуют их. Соответственно, Git SHA вообще не используются для версионирования.\n\nПоле `version` внутри `Chart.yaml` используется многими инструментами Helm, включая CLI. При создании пакета команда `helm package` использует версию из `Chart.yaml` как токен в имени пакета. Система предполагает, что номер версии в имени пакета чарта соответствует номеру версии в `Chart.yaml`. Несоответствие этому требованию приведёт к ошибке.\n\n### Поле `apiVersion`\n\nПоле `apiVersion` должно быть `v2` для чартов Helm, требующих как минимум Helm 3. Чарты, поддерживающие предыдущие версии Helm, имеют `apiVersion`, установленный в `v1`, и по-прежнему могут быть установлены Helm 3.\n\nИзменения с `v1` на `v2`:\n\n- Поле `dependencies`, определяющее зависимости чарта, которое для чартов `v1` находилось в отдельном файле `requirements.yaml` (см. [Зависимости чартов](#зависимости-чартов)).\n- Поле `type`, разделяющее прикладные и библиотечные чарты (см. [Типы чартов](#типы-чартов)).\n\n### Поле `appVersion`\n\nОбратите внимание, что поле `appVersion` не связано с полем `version`. Это способ указания версии приложения. Например, чарт `drupal` может иметь `appVersion: \"8.2.1\"`, указывающий, что версия Drupal, включённая в чарт (по умолчанию), — `8.2.1`. Это поле носит информационный характер и не влияет на расчёт версии чарта. Рекомендуется заключать версию в кавычки. Это заставляет парсер YAML обрабатывать номер версии как строку. Без кавычек в некоторых случаях могут возникнуть проблемы парсинга. Например, YAML интерпретирует `1.0` как число с плавающей точкой, а git commit SHA вроде `1234e10` — как научную нотацию.\n\nНачиная с Helm v3.5.0, `helm create` заключает поле `appVersion` по умолчанию в кавычки.\n\n### Поле `kubeVersion`\n\nНеобязательное поле `kubeVersion` позволяет определить ограничения на поддерживаемые версии Kubernetes в формате semver. Helm проверяет ограничения версий при установке чарта и завершается с ошибкой, если кластер работает на неподдерживаемой версии Kubernetes.\n\nОграничения версий могут включать сравнения AND, разделённые пробелами, например:\n```\n>= 1.13.0 < 1.15.0\n```\nкоторые можно комбинировать с оператором OR `||`, как в следующем примере:\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\nВ этом примере версия `1.14.0` исключена, что может иметь смысл, если известно о баге в определённых версиях, препятствующем корректной работе чарта.\n\nПомимо ограничений версий с использованием операторов `=` `!=` `>` `<` `>=` `<=`, поддерживаются следующие сокращённые нотации:\n\n * диапазоны через дефис для закрытых интервалов, где `1.1 - 2.3.4` эквивалентно `>= 1.1 <= 2.3.4`.\n * подстановочные знаки `x`, `X` и `*`, где `1.2.x` эквивалентно `>= 1.2.0 < 1.3.0`.\n * тильда-диапазоны (допускаются изменения патч-версии), где `~1.2.3` эквивалентно `>= 1.2.3 < 1.3.0`.\n * каретка-диапазоны (допускаются изменения минорной версии), где `^1.2.3` эквивалентно `>= 1.2.3 < 2.0.0`.\n\nПодробное объяснение поддерживаемых ограничений semver см. в [Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Устаревание чартов\n\nПри управлении чартами в репозитории чартов иногда необходимо пометить чарт как устаревший. Для этого можно использовать необязательное поле `deprecated` в `Chart.yaml`. Если **последняя** версия чарта в репозитории помечена как устаревшая, то весь чарт считается устаревшим. Имя чарта можно использовать повторно, опубликовав более новую версию, не помеченную как устаревшая. Процедура устаревания чартов:\n\n1. Обновите `Chart.yaml` чарта, чтобы пометить его как устаревший, увеличив версию\n2. Опубликуйте новую версию чарта в репозитории чартов\n3. Удалите чарт из исходного репозитория (например, git)\n\n### Типы чартов\n\nПоле `type` определяет тип чарта. Есть два типа: `application` и `library`. Application — это тип по умолчанию, представляющий собой стандартный чарт, с которым можно выполнять все операции. [Библиотечный чарт](/topics/library_charts.md) предоставляет утилиты или функции для разработчика чартов. Библиотечный чарт отличается от прикладного тем, что он не устанавливается и обычно не содержит объектов ресурсов.\n\n**Примечание:** Прикладной чарт может использоваться как библиотечный. Для этого нужно установить тип в `library`. Тогда чарт будет отрендерен как библиотечный, где можно использовать все утилиты и функции. Все объекты ресурсов чарта не будут рендериться.\n\n## Файлы LICENSE, README и NOTES чарта\n\nЧарты также могут содержать файлы, описывающие установку, конфигурацию, использование и лицензию чарта.\n\nLICENSE — это простой текстовый файл, содержащий [лицензию](https://en.wikipedia.org/wiki/Software_license) чарта. Чарт может содержать лицензию, так как может иметь программную логику в шаблонах и, следовательно, не является только конфигурацией. При необходимости могут быть также отдельные лицензии для приложения, устанавливаемого чартом.\n\nREADME для чарта должен быть отформатирован в Markdown (README.md) и обычно содержит:\n\n- Описание приложения или сервиса, предоставляемого чартом\n- Любые предварительные требования для запуска чарта\n- Описание опций в `values.yaml` и значений по умолчанию\n- Любую другую информацию, которая может быть полезна при установке или конфигурации чарта\n\nКогда хабы и другие пользовательские интерфейсы отображают информацию о чарте, эта информация берётся из содержимого файла `README.md`.\n\nЧарт также может содержать короткий текстовый файл `templates/NOTES.txt`, который будет выводиться после установки и при просмотре статуса релиза. Этот файл обрабатывается как [шаблон](#шаблоны-и-значения) и может использоваться для отображения примечаний по использованию, следующих шагов или любой другой информации, относящейся к релизу чарта. Например, можно предоставить инструкции по подключению к базе данных или доступу к веб-интерфейсу. Поскольку этот файл выводится в STDOUT при выполнении `helm install` или `helm status`, рекомендуется делать содержимое кратким и ссылаться на README для получения более подробной информации.\n\n## Зависимости чартов\n\nВ Helm один чарт может зависеть от любого количества других чартов. Эти зависимости могут быть динамически связаны с помощью поля `dependencies` в `Chart.yaml` или добавлены в каталог `charts/` и управляться вручную.\n\n### Управление зависимостями с помощью поля `dependencies`\n\nЧарты, требуемые текущим чартом, определяются как список в поле `dependencies`.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- Поле `name` — это имя нужного вам чарта.\n- Поле `version` — это версия нужного вам чарта.\n- Поле `repository` — это полный URL репозитория чартов. Обратите внимание, что вы также должны использовать `helm repo add` для локального добавления этого репозитория.\n- Вы можете использовать имя репозитория вместо URL\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nПосле определения зависимостей вы можете выполнить `helm dependency update`, и команда использует ваш файл зависимостей для загрузки всех указанных чартов в каталог `charts/`.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nКогда `helm dependency update` получает чарты, она сохраняет их как архивы чартов в каталоге `charts/`. Таким образом, для примера выше можно ожидать следующие файлы в каталоге charts:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Поле alias в зависимостях\n\nВ дополнение к другим полям выше, каждая запись зависимости может содержать необязательное поле `alias`.\n\nДобавление псевдонима для зависимого чарта добавляет чарт в зависимости, используя псевдоним в качестве имени новой зависимости.\n\n`alias` можно использовать, когда нужно обращаться к чарту под другим именем (именами).\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nВ примере выше мы получим 3 зависимости для `parentchart`:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nРучной способ достижения этого — копирование одного и того же чарта в каталог `charts/` несколько раз с разными именами.\n\n#### Поля tags и condition в зависимостях\n\nВ дополнение к другим полям выше, каждая запись зависимости может содержать необязательные поля `tags` и `condition`.\n\nПо умолчанию загружаются все чарты. Если присутствуют поля `tags` или `condition`, они вычисляются и используются для управления загрузкой чартов, к которым они применяются.\n\nCondition — поле condition содержит один или несколько путей YAML (разделённых запятыми). Если этот путь существует в значениях верхнего родительского чарта и разрешается в булево значение, чарт будет включён или отключён в зависимости от этого булева значения. Вычисляется только первый найденный допустимый путь из списка, и если ни один путь не существует, условие не имеет эффекта.\n\nTags — поле tags представляет собой YAML-список меток для ассоциации с этим чартом. В значениях верхнего родительского чарта все чарты с тегами могут быть включены или отключены путём указания тега и булева значения.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nВ примере выше все чарты с тегом `front-end` будут отключены, но поскольку путь `subchart1.enabled` в значениях родителя разрешается в 'true', условие переопределяет тег `front-end`, и `subchart1` будет включён.\n\nПоскольку `subchart2` помечен тегом `back-end`, и этот тег разрешается в `true`, `subchart2` будет включён. Также обратите внимание, что хотя для `subchart2` указано условие, в значениях родителя нет соответствующего пути и значения, поэтому это условие не имеет эффекта.\n\n##### Использование CLI с тегами и условиями\n\nПараметр `--set` можно использовать как обычно для изменения значений тегов и условий.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Разрешение тегов и условий\n\n- **Условия (когда установлены в значениях) всегда переопределяют теги.** Первый существующий путь условия побеждает, последующие пути для этого чарта игнорируются.\n- Теги вычисляются как «если любой из тегов чарта истинен, то включить чарт».\n- Значения тегов и условий должны быть установлены в значениях верхнего родительского чарта.\n- Ключ `tags:` в значениях должен быть ключом верхнего уровня. Глобальные и вложенные таблицы `tags:` в настоящее время не поддерживаются.\n\n#### Импорт значений дочерних чартов через dependencies\n\nВ некоторых случаях желательно, чтобы значения дочернего чарта передавались в родительский чарт и использовались как общие значения по умолчанию. Дополнительное преимущество использования формата `exports` заключается в том, что это позволит будущим инструментам анализировать настраиваемые пользователем значения.\n\nКлючи, содержащие импортируемые значения, могут быть указаны в `dependencies` родительского чарта в поле `import-values` с использованием YAML-списка. Каждый элемент списка — это ключ, который импортируется из поля `exports` дочернего чарта.\n\nДля импорта значений, не содержащихся в ключе `exports`, используйте формат [child-parent](#использование-формата-child-parent). Примеры обоих форматов описаны ниже.\n\n##### Использование формата exports\n\nЕсли файл `values.yaml` дочернего чарта содержит поле `exports` в корне, его содержимое может быть импортировано непосредственно в значения родителя путём указания ключей для импорта, как в примере ниже:\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\nПоскольку мы указываем ключ `data` в нашем списке импорта, Helm ищет в поле `exports` дочернего чарта ключ `data` и импортирует его содержимое.\n\nИтоговые значения родителя будут содержать наше экспортированное поле:\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\nОбратите внимание, что родительский ключ `data` не содержится в итоговых значениях родителя. Если вам нужно указать родительский ключ, используйте формат 'child-parent'.\n\n##### Использование формата child-parent\n\nДля доступа к значениям, не содержащимся в ключе `exports` значений дочернего чарта, вам нужно указать исходный ключ импортируемых значений (`child`) и путь назначения в значениях родительского чарта (`parent`).\n\n`import-values` в примере ниже указывает Helm взять любые значения по пути `child:` и скопировать их в значения родителя по пути, указанному в `parent:`\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nВ примере выше значения, найденные по пути `default.data` в значениях subchart1, будут импортированы в ключ `myimports` в значениях родительского чарта, как показано ниже:\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nИтоговые значения родительского чарта будут:\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nИтоговые значения родителя теперь содержат поля `myint` и `mybool`, импортированные из subchart1.\n\n### Ручное управление зависимостями через каталог `charts/`\n\nЕсли требуется больший контроль над зависимостями, их можно явно указать, скопировав зависимые чарты в каталог `charts/`.\n\nЗависимость должна быть распакованным каталогом чарта, но её имя не может начинаться с `_` или `.`. Такие файлы игнорируются загрузчиком чартов.\n\nНапример, если чарт WordPress зависит от чарта Apache, чарт Apache (правильной версии) поставляется в каталоге `charts/` чарта WordPress:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nПример выше показывает, как чарт WordPress выражает свою зависимость от Apache и MySQL, включая эти чарты в свой каталог `charts/`.\n\n**СОВЕТ:** _Чтобы добавить зависимость в каталог `charts/`, используйте команду `helm pull`_\n\n### Операционные аспекты использования зависимостей\n\nРазделы выше объясняют, как указывать зависимости чартов, но как это влияет на установку чарта с помощью `helm install` и `helm upgrade`?\n\nПредположим, что чарт с именем \"A\" создаёт следующие объекты Kubernetes:\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nКроме того, A зависит от чарта B, который создаёт объекты:\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nПосле установки/обновления чарта A создаётся/модифицируется один релиз Helm. Релиз создаст/обновит все вышеперечисленные объекты Kubernetes в следующем порядке:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nЭто происходит потому, что при установке/обновлении чартов объекты Kubernetes из чартов и всех их зависимостей:\n\n- агрегируются в единый набор; затем\n- сортируются по типу, а затем по имени; и затем\n- создаются/обновляются в этом порядке.\n\nТаким образом, создаётся один релиз со всеми объектами для чарта и его зависимостей.\n\nПорядок установки типов Kubernetes задаётся перечислением InstallOrder в kind_sorter.go (см. [исходный файл Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n## Шаблоны и значения\n\nШаблоны чартов Helm написаны на [языке шаблонов Go](https://golang.org/pkg/text/template/) с добавлением около 50 дополнительных функций шаблонов [из библиотеки Sprig](https://github.com/Masterminds/sprig) и нескольких других [специализированных функций](/howto/charts_tips_and_tricks.md).\n\nВсе файлы шаблонов хранятся в папке `templates/` чарта. Когда Helm рендерит чарты, он пропускает каждый файл в этом каталоге через движок шаблонов.\n\nЗначения для шаблонов предоставляются двумя способами:\n\n- Разработчики чартов могут предоставить файл `values.yaml` внутри чарта. Этот файл может содержать значения по умолчанию.\n- Пользователи чартов могут предоставить YAML-файл со значениями. Его можно указать в командной строке с помощью `helm install`.\n\nКогда пользователь предоставляет пользовательские значения, они переопределяют значения в файле `values.yaml` чарта.\n\n### Файлы шаблонов\n\nФайлы шаблонов следуют стандартным соглашениям для написания шаблонов Go (подробности см. в [документации пакета text/template Go](https://golang.org/pkg/text/template/)). Пример файла шаблона может выглядеть примерно так:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nПример выше, основанный на [https://github.com/deis/charts](https://github.com/deis/charts), является шаблоном для контроллера репликации Kubernetes. Он может использовать следующие четыре значения шаблона (обычно определяемые в файле `values.yaml`):\n\n- `imageRegistry`: Исходный реестр для Docker-образа.\n- `dockerTag`: Тег для docker-образа.\n- `pullPolicy`: Политика pull для Kubernetes.\n- `storage`: Бэкенд хранилища, значение по умолчанию — `\"minio\"`\n\nВсе эти значения определяются автором шаблона. Helm не требует и не диктует параметры.\n\nЧтобы увидеть множество работающих чартов, посетите CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0).\n\n### Предопределённые значения\n\nЗначения, предоставляемые через файл `values.yaml` (или через флаг `--set`), доступны из объекта `.Values` в шаблоне. Но есть и другие предопределённые данные, к которым вы можете получить доступ в шаблонах.\n\nСледующие значения предопределены, доступны в каждом шаблоне и не могут быть переопределены. Как и все значения, имена _чувствительны к регистру_.\n\n- `Release.Name`: Имя релиза (не чарта)\n- `Release.Namespace`: Пространство имён, в которое был выпущен чарт.\n- `Release.Service`: Сервис, выполнивший релиз.\n- `Release.IsUpgrade`: Устанавливается в true, если текущая операция — обновление или откат.\n- `Release.IsInstall`: Устанавливается в true, если текущая операция — установка.\n- `Chart`: Содержимое `Chart.yaml`. Таким образом, версия чарта доступна как `Chart.Version`, а мейнтейнеры — в `Chart.Maintainers`.\n- `Files`: Объект, подобный map, содержащий все неспециальные файлы в чарте. Он не даст вам доступа к шаблонам, но предоставит доступ к дополнительным файлам, которые присутствуют (если они не исключены с помощью `.helmignore`). Доступ к файлам осуществляется с помощью `{{ index .Files \"file.name\" }}` или функции `{{.Files.Get name }}`. Вы также можете получить доступ к содержимому файла как `[]byte` с помощью `{{ .Files.GetBytes }}`\n- `Capabilities`: Объект, подобный map, содержащий информацию о версиях Kubernetes (`{{ .Capabilities.KubeVersion }}`) и поддерживаемых версиях API Kubernetes (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n**ПРИМЕЧАНИЕ:** Любые неизвестные поля `Chart.yaml` будут отброшены. Они не будут доступны внутри объекта `Chart`. Таким образом, `Chart.yaml` нельзя использовать для передачи произвольно структурированных данных в шаблон. Для этого можно использовать файл values.\n\n### Файлы values\n\nРассматривая шаблон из предыдущего раздела, файл `values.yaml`, предоставляющий необходимые значения, будет выглядеть так:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nФайл values форматируется в YAML. Чарт может включать файл `values.yaml` по умолчанию. Команда helm install позволяет пользователю переопределять значения, предоставляя дополнительные YAML-значения:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nКогда значения передаются таким образом, они объединяются с файлом значений по умолчанию. Например, рассмотрим файл `myvals.yaml`, который выглядит так:\n\n```yaml\nstorage: \"gcs\"\n```\n\nКогда он объединяется с `values.yaml` в чарте, результирующее сгенерированное содержимое будет:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nОбратите внимание, что было переопределено только последнее поле.\n\n**ПРИМЕЧАНИЕ:** Файл значений по умолчанию, включённый в чарт, _должен_ называться `values.yaml`. Но файлы, указанные в командной строке, могут называться как угодно.\n\n**ПРИМЕЧАНИЕ:** Если флаг `--set` используется с `helm install` или `helm upgrade`, эти значения просто преобразуются в YAML на стороне клиента.\n\n**ПРИМЕЧАНИЕ:** Если в файле values существуют обязательные записи, они могут быть объявлены как обязательные в шаблоне чарта с помощью [функции 'required'](/howto/charts_tips_and_tricks.md)\n\nЛюбые из этих значений затем доступны внутри шаблонов с помощью объекта `.Values`:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Область видимости, зависимости и значения\n\nФайлы values могут объявлять значения для чарта верхнего уровня, а также для любых чартов, включённых в каталог `charts/` этого чарта. Или, другими словами, файл values может предоставлять значения как чарту, так и любым его зависимостям. Например, демонстрационный чарт WordPress выше имеет `mysql` и `apache` в качестве зависимостей. Файл values может предоставлять значения всем этим компонентам:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nЧарты более высокого уровня имеют доступ ко всем переменным, определённым ниже. Поэтому чарт WordPress может обращаться к паролю MySQL как `.Values.mysql.password`. Но чарты более низкого уровня не могут обращаться к данным в родительских чартах, поэтому MySQL не сможет получить доступ к свойству `title`. Также он не может обратиться к `apache.port`.\n\nЗначения имеют пространства имён, но пространства имён обрезаются. Поэтому для чарта WordPress можно обращаться к полю пароля MySQL как `.Values.mysql.password`. Но для чарта MySQL область значений была сужена, и префикс пространства имён удалён, поэтому он увидит поле пароля просто как `.Values.password`.\n\n#### Глобальные значения\n\nНачиная с версии 2.0.0-Alpha.2, Helm поддерживает специальные \"глобальные\" значения. Рассмотрим эту модифицированную версию предыдущего примера:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nВыше добавлен раздел `global` со значением `app: MyWordPress`. Это значение доступно _всем_ чартам как `.Values.global.app`.\n\nНапример, шаблоны `mysql` могут обращаться к `app` как `{{ .Values.global.app}}`, и так же может чарт `apache`. Фактически файл values выше регенерируется следующим образом:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\nЭто обеспечивает способ совместного использования одной переменной верхнего уровня со всеми подчартами, что полезно для таких вещей, как установка свойств `metadata`, например меток.\n\nЕсли подчарт объявляет глобальную переменную, эта глобальная переменная передаётся _вниз_ (подчартам подчарта), но не _вверх_ к родительскому чарту. Подчарт не может влиять на значения родительского чарта.\n\nКроме того, глобальные переменные родительских чартов имеют приоритет над глобальными переменными подчартов.\n\n### Файлы Schema\n\nИногда мейнтейнер чарта может захотеть определить структуру своих значений. Это можно сделать, определив схему в файле `values.schema.json`. Схема представляется в виде [JSON Schema](https://json-schema.org/). Она может выглядеть примерно так:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nЭта схема будет применяться к значениям для их валидации. Валидация происходит при вызове любой из следующих команд:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nПример файла `values.yaml`, соответствующего требованиям этой схемы, может выглядеть примерно так:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nОбратите внимание, что схема применяется к итоговому объекту `.Values`, а не только к файлу `values.yaml`. Это означает, что следующий `yaml` файл валиден при условии, что чарт установлен с соответствующей опцией `--set`, показанной ниже.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nКроме того, итоговый объект `.Values` проверяется на соответствие *всем* схемам подчартов. Это означает, что ограничения подчарта нельзя обойти через родительский чарт. Это также работает в обратную сторону — если подчарт имеет требование, которое не выполнено в файле `values.yaml` подчарта, родительский чарт *должен* удовлетворить эти ограничения, чтобы быть валидным.\n\nВалидацию схемы можно отключить, установив опцию, показанную ниже. Это особенно полезно в изолированных средах, когда файл JSON Schema чарта содержит удалённые ссылки.\n```console\nhelm install --skip-schema-validation\n```\n\n### Справочные материалы\n\nКогда дело доходит до написания шаблонов, значений и файлов схем, есть несколько стандартных справочных материалов, которые вам помогут.\n\n- [Шаблоны Go](https://godoc.org/text/template)\n- [Дополнительные функции шаблонов](https://godoc.org/github.com/Masterminds/sprig)\n- [Формат YAML](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRD)\n\nKubernetes предоставляет механизм для объявления новых типов объектов Kubernetes. С помощью CustomResourceDefinitions (CRD) разработчики Kubernetes могут объявлять пользовательские типы ресурсов.\n\nВ Helm 3 CRD рассматриваются как особый вид объектов. Они устанавливаются перед остальной частью чарта и имеют некоторые ограничения.\n\nФайлы CRD YAML должны размещаться в каталоге `crds/` внутри чарта. Несколько CRD (разделённых маркерами начала и конца YAML) могут быть размещены в одном файле. Helm попытается загрузить _все_ файлы из каталога CRD в Kubernetes.\n\nФайлы CRD _не могут быть шаблонизированы_. Они должны быть обычными YAML-документами.\n\nКогда Helm устанавливает новый чарт, он загружает CRD, приостанавливается до тех пор, пока CRD не станут доступны через API-сервер, а затем запускает движок шаблонов, рендерит остальную часть чарта и загружает её в Kubernetes. Благодаря такому порядку информация о CRD доступна в объекте `.Capabilities` в шаблонах Helm, и шаблоны Helm могут создавать новые экземпляры объектов, объявленных в CRD.\n\nНапример, если ваш чарт имеет CRD для `CronTab` в каталоге `crds/`, вы можете создавать экземпляры вида `CronTab` в каталоге `templates/`:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nФайл `crontab.yaml` должен содержать CRD без директив шаблона:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nЗатем шаблон `mycrontab.yaml` может создать новый `CronTab` (используя шаблоны как обычно):\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm убедится, что вид `CronTab` установлен и доступен из API-сервера Kubernetes, прежде чем продолжить установку объектов из `templates/`.\n\n### Ограничения CRD\n\nВ отличие от большинства объектов в Kubernetes, CRD устанавливаются глобально. По этой причине Helm очень осторожен в управлении CRD. CRD имеют следующие ограничения:\n\n- CRD никогда не переустанавливаются. Если Helm определяет, что CRD в каталоге `crds/` уже присутствуют (независимо от версии), Helm не будет пытаться установить или обновить их.\n- CRD никогда не устанавливаются при обновлении или откате. Helm создаёт CRD только при операциях установки.\n- CRD никогда не удаляются. Удаление CRD автоматически удаляет всё содержимое CRD во всех пространствах имён кластера. Следовательно, Helm не удаляет CRD.\n\nОператорам, желающим обновить или удалить CRD, рекомендуется делать это вручную и с большой осторожностью.\n\n## Использование Helm для управления чартами\n\nИнструмент `helm` имеет несколько команд для работы с чартами.\n\nОн может создать для вас новый чарт:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nПосле редактирования чарта `helm` может упаковать его в архив чарта:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nВы также можете использовать `helm` для поиска проблем с форматированием или информацией вашего чарта:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Репозитории чартов\n\n_Репозиторий чартов_ — это HTTP-сервер, на котором размещается один или несколько упакованных чартов. Хотя `helm` можно использовать для управления локальными каталогами чартов, когда дело доходит до совместного использования чартов, предпочтительным механизмом является репозиторий чартов.\n\nЛюбой HTTP-сервер, который может обслуживать YAML-файлы и tar-файлы и отвечать на GET-запросы, может использоваться в качестве сервера репозитория. Команда Helm протестировала некоторые серверы, включая Google Cloud Storage с включённым режимом веб-сайта и S3 с включённым режимом веб-сайта.\n\nРепозиторий характеризуется в первую очередь наличием специального файла `index.yaml`, который содержит список всех пакетов, предоставляемых репозиторием, вместе с метаданными, позволяющими получить и проверить эти пакеты.\n\nНа стороне клиента управление репозиториями осуществляется командами `helm repo`. Однако Helm не предоставляет инструментов для загрузки чартов на удалённые серверы репозиториев. Это связано с тем, что это добавило бы существенные требования к реализующему серверу и, таким образом, повысило бы барьер для настройки репозитория.\n\n## Стартовые пакеты чартов\n\nКоманда `helm create` принимает необязательную опцию `--starter`, позволяющую указать \"стартовый чарт\". Также опция starter имеет короткий псевдоним `-p`.\n\nПримеры использования:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nСтартеры — это обычные чарты, расположенные в `$XDG_DATA_HOME/helm/starters`. Как разработчик чартов, вы можете создавать чарты, специально предназначенные для использования в качестве стартеров. Такие чарты должны разрабатываться со следующими соображениями:\n\n- `Chart.yaml` будет перезаписан генератором.\n- Пользователи будут ожидать возможности изменять содержимое такого чарта, поэтому документация должна указывать, как пользователи могут это делать.\n- Все вхождения `<CHARTNAME>` будут заменены указанным именем чарта, чтобы стартовые чарты могли использоваться как шаблоны, за исключением некоторых переменных файлов. Например, если вы используете пользовательские файлы в каталоге `vars` или определённые файлы `README.md`, `<CHARTNAME>` НЕ будет переопределён внутри них. Кроме того, описание чарта не наследуется.\n\nВ настоящее время единственный способ добавить чарт в `$XDG_DATA_HOME/helm/starters` — скопировать его туда вручную. В документации вашего чарта вы можете описать этот процесс.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: Хуки чартов\ndescription: Описывает работу с хуками чартов.\nsidebar_position: 2\n---\n\nHelm предоставляет механизм _хуков_, позволяющий разработчикам чартов вмешиваться в определённые этапы жизненного цикла релиза. Например, хуки можно использовать для:\n\n- Загрузки ConfigMap или Secret перед загрузкой остальных чартов при установке.\n- Выполнения Job для резервного копирования базы данных перед установкой нового чарта, а затем выполнения другого Job после обновления для восстановления данных.\n- Запуска Job перед удалением релиза для корректного вывода сервиса из ротации.\n\nХуки работают как обычные шаблоны, но имеют специальные аннотации, которые указывают Helm обрабатывать их особым образом. В этом разделе рассматриваются основные паттерны использования хуков.\n\n## Доступные хуки\n\nОпределены следующие хуки:\n\n| Значение аннотации | Описание                                                                                                  |\n| ------------------ | --------------------------------------------------------------------------------------------------------- |\n| `pre-install`      | Выполняется после рендеринга шаблонов, но до создания каких-либо ресурсов в Kubernetes                    |\n| `post-install`     | Выполняется после загрузки всех ресурсов в Kubernetes                                                     |\n| `pre-delete`       | Выполняется при запросе на удаление до удаления каких-либо ресурсов из Kubernetes                         |\n| `post-delete`      | Выполняется при запросе на удаление после удаления всех ресурсов релиза                                   |\n| `pre-upgrade`      | Выполняется при запросе на обновление после рендеринга шаблонов, но до обновления каких-либо ресурсов     |\n| `post-upgrade`     | Выполняется при запросе на обновление после обновления всех ресурсов                                      |\n| `pre-rollback`     | Выполняется при запросе на откат после рендеринга шаблонов, но до отката каких-либо ресурсов              |\n| `post-rollback`    | Выполняется при запросе на откат после изменения всех ресурсов                                            |\n| `test`             | Выполняется при вызове подкоманды Helm test ([см. документацию по тестам](/topics/chart_tests.md))        |\n\n_Обратите внимание, что хук `crd-install` был удалён в Helm 3 в пользу директории `crds/`._\n\n## Хуки и жизненный цикл релиза\n\nХуки позволяют разработчику чарта выполнять операции в ключевых точках жизненного цикла релиза. Например, рассмотрим жизненный цикл команды `helm install`. По умолчанию он выглядит так:\n\n1. Пользователь запускает `helm install foo`\n2. Вызывается API установки библиотеки Helm\n3. После проверки библиотека рендерит шаблоны `foo`\n4. Библиотека загружает полученные ресурсы в Kubernetes\n5. Библиотека возвращает объект релиза (и другие данные) клиенту\n6. Клиент завершает работу\n\nHelm определяет два хука для жизненного цикла установки: `pre-install` и `post-install`. Если разработчик чарта `foo` реализует оба хука, жизненный цикл изменяется следующим образом:\n\n1. Пользователь запускает `helm install foo`\n2. Вызывается API установки библиотеки Helm\n3. Устанавливаются CRD из директории `crds/`\n4. После проверки библиотека рендерит шаблоны `foo`\n5. Библиотека готовится к выполнению хуков `pre-install` (загружая ресурсы хуков в Kubernetes)\n6. Библиотека сортирует хуки по весу (по умолчанию вес равен 0), затем по типу ресурса и, наконец, по имени в порядке возрастания\n7. Библиотека загружает хук с наименьшим весом первым (от отрицательных к положительным)\n8. Библиотека ждёт, пока хук не станет «Ready» (за исключением CRD)\n9. Библиотека загружает полученные ресурсы в Kubernetes. Обратите внимание: если указан флаг `--wait`, библиотека будет ждать, пока все ресурсы не перейдут в состояние готовности, и не запустит хук `post-install` до их готовности.\n10. Библиотека выполняет хук `post-install` (загружая ресурсы хука)\n11. Библиотека ждёт, пока хук не станет «Ready»\n12. Библиотека возвращает объект релиза (и другие данные) клиенту\n13. Клиент завершает работу\n\nЧто означает ожидание готовности хука? Это зависит от типа ресурса, объявленного в хуке. Если ресурс имеет тип `Job` или `Pod`, Helm будет ждать его успешного завершения. Если хук завершается с ошибкой, релиз также завершится с ошибкой. Это _блокирующая операция_, поэтому клиент Helm приостановит выполнение на время работы Job.\n\nДля всех остальных типов ресурсов, как только Kubernetes отметит ресурс как загруженный (добавленный или обновлённый), он считается готовым («Ready»). Когда в хуке объявлено много ресурсов, они выполняются последовательно. Если у них есть веса (см. ниже), они выполняются в порядке весов. Начиная с Helm 3.2.0, ресурсы хуков с одинаковым весом устанавливаются в том же порядке, что и обычные ресурсы без хуков. В противном случае порядок не гарантируется. (В Helm 2.3.0 и новее они сортируются по алфавиту. Однако это поведение не является обязательным и может измениться в будущем.) Рекомендуется указывать вес хука и устанавливать его в `0`, если порядок не важен.\n\n### Ресурсы хуков не управляются вместе с релизами\n\nРесурсы, создаваемые хуком, в настоящее время не отслеживаются и не управляются как часть релиза. После того как Helm убедится, что хук достиг состояния готовности, он оставляет ресурс хука без изменений. Сборка мусора для ресурсов хуков при удалении соответствующего релиза может быть добавлена в Helm 3 в будущем, поэтому любые ресурсы хуков, которые не должны удаляться, следует аннотировать с помощью `helm.sh/resource-policy: keep`.\n\nНа практике это означает, что если вы создаёте ресурсы в хуке, вы не можете полагаться на `helm uninstall` для их удаления. Чтобы удалить такие ресурсы, вам нужно либо [добавить аннотацию `helm.sh/hook-delete-policy`](#hook-deletion-policies) в файл шаблона хука, либо [установить поле времени жизни (TTL) для ресурса Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Написание хука\n\nХуки — это обычные файлы манифестов Kubernetes со специальными аннотациями в секции `metadata`. Поскольку они являются файлами шаблонов, вы можете использовать все стандартные возможности шаблонизации, включая чтение `.Values`, `.Release` и `.Template`.\n\nНапример, этот шаблон, сохранённый в `templates/post-install-job.yaml`, объявляет Job, который будет выполнен после установки (`post-install`):\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nЧто делает этот шаблон хуком — это аннотация:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nОдин ресурс может реализовывать несколько хуков:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nАналогично, нет ограничений на количество ресурсов, которые могут реализовывать один хук. Например, можно объявить и Secret, и ConfigMap как хуки `pre-install`.\n\nКогда субчарты объявляют хуки, они также обрабатываются. Родительский чарт не может отключить хуки, объявленные в субчартах.\n\nМожно определить вес хука, который поможет установить детерминированный порядок выполнения. Вес определяется с помощью следующей аннотации:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nВес хука может быть положительным или отрицательным числом, но должен быть представлен в виде строки. Когда Helm начинает цикл выполнения хуков определённого типа, он сортирует их в порядке возрастания веса.\n\n### Политики удаления хуков\n\nМожно определить политики, определяющие, когда удалять соответствующие ресурсы хуков. Политики удаления хуков определяются с помощью следующей аннотации:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nВы можете выбрать одно или несколько значений аннотации:\n\n| Значение аннотации     | Описание                                                              |\n| ---------------------- | --------------------------------------------------------------------- |\n| `before-hook-creation` | Удалить предыдущий ресурс перед запуском нового хука (по умолчанию)   |\n| `hook-succeeded`       | Удалить ресурс после успешного выполнения хука                        |\n| `hook-failed`          | Удалить ресурс, если хук завершился с ошибкой                         |\n\nЕсли аннотация политики удаления хука не указана, по умолчанию применяется поведение `before-hook-creation`.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/index.mdx",
    "content": "---\ntitle: Темы\nsidebar_position: 3\n---\n\n# Тематические руководства\n\nЗдесь вы найдёте введение во все ключевые части Helm, которые вам нужно или хочется\nзнать.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: Устаревшие API Kubernetes\ndescription: Объясняет работу с устаревшими API Kubernetes в Helm\n---\n\nKubernetes — это система, управляемая через API, и этот API развивается со временем,\nотражая всё более глубокое понимание предметной области. Это обычная практика для\nсистем и их API. Важная часть развития API — это грамотная политика устаревания\nи процесс информирования пользователей об изменениях в API. Иными словами,\nпользователи вашего API должны заранее знать, в каком релизе API будет\nудалён или изменён. Это устраняет неожиданности и предотвращает\nкритические изменения для пользователей.\n\n[Политика устаревания\nKubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\nописывает, как Kubernetes обрабатывает изменения версий API. Политика\nопределяет сроки поддержки версий API после объявления об их устаревании.\nПоэтому важно следить за объявлениями об устаревании и знать,\nкогда версии API будут удалены, чтобы минимизировать последствия.\n\nВот пример объявления [об удалении устаревших версий API в Kubernetes\n1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/),\nкоторое было опубликовано за несколько месяцев до выхода релиза. Эти версии API\nбыли объявлены устаревшими ещё раньше. Это показывает, что существует\nграмотная политика информирования пользователей о поддержке версий API.\n\nШаблоны Helm указывают [группу API\nKubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)\nпри определении объекта Kubernetes, аналогично файлу манифеста Kubernetes.\nГруппа указывается в поле `apiVersion` шаблона и идентифицирует версию\nAPI объекта Kubernetes. Это означает, что пользователи Helm и мейнтейнеры\nчартов должны знать, когда версии API Kubernetes устарели и в какой\nверсии Kubernetes они будут удалены.\n\n## Мейнтейнеры чартов\n\nВам следует проверить свои чарты на наличие версий API Kubernetes, которые\nустарели или удалены в определённой версии Kubernetes. Найденные версии API,\nкоторые скоро перестанут поддерживаться или уже не поддерживаются, следует\nобновить до поддерживаемой версии и выпустить новую версию чарта.\nВерсия API определяется полями `kind` и `apiVersion`. Например, вот\nудалённая версия API объекта `Deployment` в Kubernetes 1.16:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Пользователи Helm\n\nВам следует проверить используемые чарты (аналогично [мейнтейнерам\nчартов](#мейнтейнеры-чартов)) и выявить те, где версии API устарели\nили удалены в определённой версии Kubernetes. Для выявленных чартов\nвам нужно найти последнюю версию чарта (с поддерживаемыми версиями API)\nили обновить чарт самостоятельно.\n\nКроме того, вам необходимо проверить все развёрнутые чарты (то есть релизы Helm),\nтакже проверяя наличие устаревших или удалённых версий API. Это можно сделать,\nполучив информацию о релизе с помощью команды `helm get manifest`.\n\nСпособ обновления релиза Helm до поддерживаемых API зависит от результатов\nпроверки:\n\n1. Если вы обнаружили только устаревшие версии API:\n  - Выполните `helm upgrade` с версией чарта, содержащей поддерживаемые\n    версии API Kubernetes\n  - Добавьте описание при обновлении, примерно следующего содержания:\n    не выполнять откат к версии Helm, предшествующей текущей\n2. Если вы обнаружили версии API, удалённые в определённой версии Kubernetes:\n  - Если вы используете версию Kubernetes, где эти версии API ещё доступны\n    (например, вы на Kubernetes 1.15 и обнаружили API, которые будут\n    удалены в Kubernetes 1.16):\n    - Следуйте процедуре из пункта 1\n  - В противном случае (например, вы уже используете версию Kubernetes,\n    где некоторые версии API, отображаемые `helm get manifest`, более недоступны):\n    - Вам нужно отредактировать манифест релиза, хранящийся в кластере,\n      чтобы обновить версии API до поддерживаемых. Подробнее см.\n      [Обновление версий API в манифесте релиза](#обновление-версий-api-в-манифесте-релиза)\n\n> Примечание: Во всех случаях обновления релиза Helm до поддерживаемых API\nникогда не выполняйте откат релиза к версии, предшествующей версии\nс поддерживаемыми API.\n\n> Рекомендация: Лучшая практика — обновлять релизы с устаревшими версиями API\nдо поддерживаемых версий API до обновления кластера Kubernetes,\nв котором эти версии API будут удалены.\n\nЕсли вы не обновите релиз, как было предложено выше, вы получите ошибку,\nпохожую на следующую, при попытке обновить релиз в версии Kubernetes,\nгде его версии API удалены:\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm завершается с ошибкой в этом сценарии, потому что пытается создать\ndiff-патч между текущим развёрнутым релизом (содержащим версии API Kubernetes,\nудалённые в этой версии Kubernetes) и чартом, который вы передаёте с\nобновлёнными/поддерживаемыми версиями API. Основная причина ошибки в том,\nчто когда Kubernetes удаляет версию API, клиентская библиотека Kubernetes Go\nбольше не может разбирать устаревшие объекты, и Helm завершается с ошибкой\nпри вызове библиотеки. К сожалению, Helm не может восстановиться после этой\nситуации и больше не может управлять таким релизом. Подробнее о том, как\nвосстановиться после этого сценария, см. [Обновление версий API в манифесте\nрелиза](#обновление-версий-api-в-манифесте-релиза).\n\n## Обновление версий API в манифесте релиза\n\nМанифест — это свойство объекта релиза Helm, которое хранится в поле data\nSecret (по умолчанию) или ConfigMap в кластере. Поле data содержит\nсжатый gzip объект, закодированный в base64 (для Secret применяется\nдополнительное кодирование base64). Для каждой версии/ревизии релиза\nсуществует отдельный Secret/ConfigMap в пространстве имён релиза.\n\nВы можете использовать плагин Helm\n[mapkubeapis](https://github.com/helm/helm-mapkubeapis) для обновления\nрелиза до поддерживаемых API. Подробности см. в readme плагина.\n\nАльтернативно вы можете выполнить следующие ручные шаги для обновления\nверсий API в манифесте релиза. В зависимости от вашей конфигурации\nследуйте шагам для Secret или ConfigMap.\n\n- Получите имя Secret или ConfigMap, связанного с последним развёрнутым релизом:\n  - Для Secret: `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - Для ConfigMap: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- Получите данные последнего развёрнутого релиза:\n  - Для Secret: `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - Для ConfigMap: `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- Создайте резервную копию релиза на случай, если что-то пойдёт не так:\n  - `cp release.yaml release.bak`\n  - В случае проблем восстановите: `kubectl apply -f release.bak -n\n    <release_namespace>`\n- Декодируйте объект релиза:\n  - Для Secret: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - Для ConfigMap: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- Измените версии API в манифестах. Можно использовать любой инструмент\n  (например, редактор) для внесения изменений. Это находится в поле `manifest`\n  вашего декодированного объекта релиза (`release.data.decoded`)\n- Закодируйте объект релиза:\n  - Для Secret: `cat release.data.decoded | gzip | base64 | base64`\n  - Для ConfigMap: `cat release.data.decoded | gzip | base64`\n- Замените значение свойства `data.release` в файле развёрнутого релиза\n  (`release.yaml`) на новый закодированный объект релиза\n- Примените файл к пространству имён: `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- Выполните `helm upgrade` с версией чарта, содержащей поддерживаемые\n  версии API Kubernetes\n- Добавьте описание при обновлении, примерно следующего содержания:\n  не выполнять откат к версии Helm, предшествующей текущей\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: \"Руководство по дистрибутивам Kubernetes\"\ndescription: \"Содержит информацию об использовании Helm в различных средах Kubernetes.\"\nsidebar_position: 10\n---\n\nHelm должен работать с любой [совместимой версией\nKubernetes](https://github.com/cncf/k8s-conformance) (как\n[сертифицированной](https://www.cncf.io/certification/software-conformance/), так и нет).\n\nВ этом документе собрана информация об использовании Helm в конкретных средах\nKubernetes. Пожалуйста, добавляйте информацию о других дистрибутивах\n(в алфавитном порядке) при необходимости.\n\n\n## AKS\n\nHelm работает с [Azure Kubernetes\nService](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nHelm протестирован и работает на платформе Kubernetes в Mesosphere DC/OS 1.11,\nдополнительная настройка не требуется.\n\n## EKS\n\nHelm работает с Amazon Elastic Kubernetes Service (Amazon EKS):\n[Использование Helm с Amazon\nEKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nОблачная платформа Google GKE работает с Helm и не требует дополнительной\nнастройки.\n\n## `scripts/local-cluster` и Hyperkube\n\nHyperkube, настроенный через `scripts/local-cluster.sh`, работает без проблем.\nДля чистого Hyperkube может потребоваться ручная настройка.\n\n## IKS\n\nHelm работает с [IBM Cloud Kubernetes\nService](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nHelm регулярно тестируется на [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne\n\nHelm работает в кластерах, созданных KubeOne, без ограничений.\n\n## Kubermatic\n\nHelm работает в пользовательских кластерах, созданных Kubermatic, без ограничений.\nПоскольку seed-кластер может быть настроен различными способами, поддержка Helm\nзависит от его конфигурации.\n\n## MicroK8s\n\nHelm можно включить в [MicroK8s](https://microk8s.io) с помощью команды:\n`microk8s.enable helm3`\n\n## Minikube\n\nHelm протестирован и работает с\n[Minikube](https://github.com/kubernetes/minikube). Дополнительная настройка\nне требуется.\n\n## OpenShift\n\nHelm работает на OpenShift Online, OpenShift Dedicated, OpenShift Container\nPlatform (версия >= 3.6) и OpenShift Origin (версия >= 3.6). Подробнее читайте\nв [этой статье в блоге](https://blog.openshift.com/getting-started-helm-openshift/).\n\n## Platform9\n\nHelm предустановлен в [Platform9 Managed\nKubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes).\nPlatform9 предоставляет доступ ко всем официальным чартам Helm через интерфейс\nApp Catalog и CLI Kubernetes. Дополнительные репозитории можно добавить вручную.\nПодробнее см. в [статье о Platform9 App\nCatalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes).\n\n## Ubuntu с `kubeadm`\n\nKubernetes, развёрнутый с помощью `kubeadm`, работает на следующих дистрибутивах\nLinux:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nНекоторые версии Helm (v2.0.0-beta2) требуют выполнения `export\nKUBECONFIG=/etc/kubernetes/admin.conf` или создания файла `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid\n\nHelm работает на VMware Tanzu Kubernetes Grid (TKG) без дополнительной настройки.\nTanzu CLI позволяет управлять установкой пакетов для [helm-controller](https://fluxcd.io/flux/components/helm/),\nчто обеспечивает декларативное управление релизами чартов Helm.\nПодробнее см. в документации 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).\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: Библиотечные чарты\ndescription: Описывает библиотечные чарты и примеры их использования\nsidebar_position: 4\n---\n\nБиблиотечный чарт — это тип [чарта Helm](/topics/charts.md), который определяет примитивы или конструкции, которые могут использоваться шаблонами Helm в других чартах. Это позволяет разработчикам создавать повторно используемые фрагменты кода, избегая дублирования и соблюдая принцип [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) (не повторяйся).\n\nБиблиотечные чарты были введены в Helm 3 для формализации общих или вспомогательных чартов, которые использовались разработчиками чартов ещё со времён Helm 2. Выделение их в отдельный тип чарта обеспечивает:\n- Возможность явно различать общие и прикладные чарты\n- Логику, предотвращающую установку общего чарта\n- Отсутствие рендеринга шаблонов в общем чарте, которые могут содержать артефакты релиза\n- Возможность зависимым чартам использовать контекст импортирующего чарта\n\nРазработчик чартов может определить общий чарт как библиотечный и быть уверенным, что Helm будет обрабатывать его стандартным, согласованным образом. Это также означает, что определения из прикладного чарта можно переиспользовать, изменив тип чарта.\n\n## Создание простого библиотечного чарта\n\nКак упоминалось ранее, библиотечный чарт — это тип [чарта Helm](/topics/charts.md). Это означает, что вы можете начать с создания заготовки чарта:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nСначала удалите все файлы в директории `templates`, поскольку в этом примере мы создадим собственные определения шаблонов.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nФайл values также не потребуется.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nПрежде чем создавать общий код, рассмотрим несколько важных концепций Helm. [Именованный шаблон](/chart_template_guide/named_templates.md) (иногда называемый partial или subtemplate) — это просто шаблон, определённый внутри файла и имеющий имя. В директории `templates/` любой файл, имя которого начинается с подчёркивания (_), не предполагает вывод манифеста Kubernetes. По соглашению вспомогательные шаблоны и partial размещаются в файлах `_*.tpl` или `_*.yaml`.\n\nВ этом примере мы создадим общий ConfigMap, который генерирует пустой ресурс ConfigMap. Определим общий ConfigMap в файле `mylibchart/templates/_configmap.yaml` следующим образом:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nКонструкция ConfigMap определена в именованном шаблоне `mylibchart.configmap.tpl`. Это простой ConfigMap с пустым ресурсом `data`. В этом же файле есть другой именованный шаблон `mylibchart.configmap`, который вызывает именованный шаблон `mylibchart.util.merge`, принимающий 2 именованных шаблона в качестве аргументов: шаблон, вызывающий `mylibchart.configmap`, и `mylibchart.configmap.tpl`.\n\nВспомогательная функция `mylibchart.util.merge` — это именованный шаблон в файле `mylibchart/templates/_util.yaml`. Это полезная утилита из [Common Helm Helper Chart](#common-helm-helper-chart), которая объединяет 2 шаблона и переопределяет общие части в обоих:\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nЭто важно, когда чарт использует общий код, который нужно настроить под собственную конфигурацию.\n\nНаконец, изменим тип чарта на `library`. Для этого отредактируйте файл `mylibchart/Chart.yaml` следующим образом:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\nБиблиотечный чарт готов к использованию, и его определение ConfigMap можно переиспользовать.\n\nПрежде чем продолжить, стоит проверить, распознаёт ли Helm чарт как библиотечный:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Использование простого библиотечного чарта\n\nТеперь используем библиотечный чарт. Для этого снова создадим заготовку чарта:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nСнова очистим файлы шаблонов, так как мы хотим создать только ConfigMap:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nЕсли бы мы хотели создать простой ConfigMap в шаблоне Helm, он мог бы выглядеть примерно так:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nОднако мы собираемся переиспользовать общий код, уже созданный в `mylibchart`. ConfigMap можно создать в файле `mychart/templates/configmap.yaml` следующим образом:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nЭто упрощает работу: мы наследуем общее определение ConfigMap, которое добавляет стандартные свойства. В нашем шаблоне мы добавляем конфигурацию — в данном случае ключ данных `myvalue` и его значение. Конфигурация переопределяет пустой ресурс общего ConfigMap. Это возможно благодаря вспомогательной функции `mylibchart.util.merge`, которую мы упомянули в предыдущем разделе.\n\nЧтобы использовать общий код, нужно добавить `mylibchart` как зависимость. Добавьте следующее в конец файла `mychart/Chart.yaml`:\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nЭто подключает библиотечный чарт как динамическую зависимость из файловой системы, расположенную на том же родительском уровне, что и наш прикладной чарт. Поскольку мы подключаем библиотечный чарт как динамическую зависимость, нужно выполнить `helm dependency update`. Эта команда скопирует библиотечный чарт в директорию `charts/`.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nТеперь мы готовы развернуть наш чарт. Перед установкой стоит сначала проверить отрендеренный шаблон.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nЭто выглядит как ConfigMap, который нам нужен, с переопределением данных `myvalue: Hello World`. Установим его:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nМы можем получить релиз и убедиться, что фактический шаблон был загружен.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## Преимущества библиотечных чартов\n\nПоскольку библиотечные чарты не могут работать как самостоятельные чарты, они могут использовать следующие возможности:\n- Объект `.Files` ссылается на пути к файлам в родительском чарте, а не в локальном пути библиотечного чарта\n- Объект `.Values` такой же, как у родительского чарта, в отличие от прикладных [субчартов](/chart_template_guide/subcharts_and_globals.md), которые получают раздел значений, настроенный под их именем в родительском чарте\n\n\n## Common Helm Helper Chart\n\n```markdown\nNote: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived.\n```\n\nЭтот [чарт](https://github.com/helm/charts/tree/master/incubator/common) был оригинальным примером общих чартов. Он предоставляет утилиты, отражающие лучшие практики разработки чартов Kubernetes. Его можно сразу использовать при разработке ваших чартов, чтобы получить удобный общий код.\n\nВот краткое руководство по его использованию. Подробнее читайте в [README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nСнова создайте заготовку чарта:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nИспользуем общий код из вспомогательного чарта. Сначала отредактируйте deployment `demo/templates/deployment.yaml` следующим образом:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nТеперь файл сервиса `demo/templates/service.yaml`:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nЭти шаблоны показывают, как наследование общего кода из вспомогательного чарта упрощает написание кода до настройки или кастомизации ресурсов.\n\nЧтобы использовать общий код, нужно добавить `common` как зависимость. Добавьте следующее в конец файла `demo/Chart.yaml`:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nПримечание: вам потребуется добавить репозиторий `incubator` в список репозиториев Helm (`helm repo add`).\n\nПоскольку мы подключаем чарт как динамическую зависимость, нужно выполнить `helm dependency update`. Эта команда скопирует вспомогательный чарт в директорию `charts/`.\n\nТак как вспомогательный чарт использует некоторые конструкции Helm 2, вам потребуется добавить следующее в файл `demo/values.yaml`, чтобы образ `nginx` загрузился, поскольку это было обновлено в базовой структуре чарта Helm 3:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nВы можете проверить корректность шаблонов чарта перед развёртыванием с помощью команд `helm lint` и `helm template`.\n\nЕсли всё в порядке, развёртывайте с помощью `helm install`!\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Управление правами доступа для SQL-хранилища\ndescription: Узнайте, как настроить права доступа при использовании SQL-хранилища.\n---\n\nЭтот документ содержит руководство по настройке и управлению правами доступа при использовании SQL в качестве хранилища данных.\n\n## Введение\n\nДля управления правами доступа Helm использует функциональность RBAC в Kubernetes. При использовании SQL-хранилища роли Kubernetes не могут использоваться для определения того, имеет ли пользователь доступ к конкретному ресурсу. В этом документе описывается, как создавать и управлять такими правами.\n\n## Инициализация\n\nПри первом подключении Helm CLI к вашей базе данных клиент проверяет, была ли она ранее инициализирована. Если нет, необходимая настройка выполняется автоматически. Для этой инициализации требуются права администратора на схему public или, как минимум, возможность:\n\n* создавать таблицы\n* назначать привилегии на схему public\n\nПосле выполнения миграции в вашей базе данных все остальные роли смогут использовать клиент.\n\n## Предоставление привилегий пользователю без прав администратора в PostgreSQL\n\nДля управления правами доступа драйвер SQL-хранилища использует функцию [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Level Security — безопасность на уровне строк) в PostgreSQL. RLS позволяет всем пользователям читать и записывать данные в одну и ту же таблицу, не имея при этом возможности манипулировать строками, к которым им явно не предоставлен доступ.\n\nПо умолчанию любая роль без соответствующих привилегий будет получать пустой список при выполнении `helm list` и не сможет получить или изменить какой-либо ресурс в кластере.\n\nРассмотрим, как предоставить роли доступ к определённым namespace:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nЭта команда предоставляет роли `role` права на чтение и запись всех ресурсов, соответствующих условию `namespace = 'default'`. После создания этой политики пользователь, подключённый к базе данных от имени роли `role`, сможет видеть все релизы в namespace `default` при выполнении `helm list`, а также изменять и удалять их.\n\nС помощью RLS привилегии можно настраивать детально. Вы можете ограничивать доступ на основе различных столбцов таблицы:\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Руководство по плагинам Helm\ndescription: Описывает, как использовать и создавать плагины для расширения функциональности Helm.\nsidebar_position: 12\n---\n\nПлагин Helm — это инструмент, доступный через CLI `helm`, но не являющийся частью встроенной кодовой базы Helm.\n\nСуществующие плагины можно найти в разделе [связанные проекты](/community/related#helm-plugins) или в результатах поиска на [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).\n\nВ этом руководстве описывается, как использовать и создавать плагины.\n\n## Обзор\n\nПлагины Helm — это дополнительные инструменты, которые легко интегрируются с Helm. Они позволяют расширять основную функциональность Helm без необходимости писать каждую новую возможность на Go и добавлять её в основной инструмент.\n\nПлагины Helm имеют следующие особенности:\n\n- Их можно добавлять и удалять из установки Helm без влияния на основной инструмент.\n- Они могут быть написаны на любом языке программирования.\n- Они интегрируются с Helm и отображаются в `helm help` и других местах.\n\nПлагины Helm располагаются в директории `$HELM_PLUGINS`. Вы можете узнать текущее значение этой переменной, включая значение по умолчанию, если она не задана в окружении, с помощью команды `helm env`.\n\nМодель плагинов Helm частично основана на модели плагинов Git. По этой причине `helm` иногда называют _фарфоровым_ (porcelain) слоем, а плагины — _сантехникой_ (plumbing). Иными словами, Helm отвечает за пользовательский интерфейс и логику верхнего уровня, а плагины выполняют конкретную работу по реализации нужного действия.\n\n## Установка плагина\n\nПлагины устанавливаются с помощью команды `$ helm plugin install <path|url>`. Вы можете указать путь к плагину в локальной файловой системе или URL удалённого VCS-репозитория. Команда `helm plugin install` клонирует или копирует плагин по указанному пути/URL в директорию `$HELM_PLUGINS`. При установке из VCS вы можете указать версию с помощью аргумента `--version`.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nЕсли у вас есть архив плагина в формате tar, просто распакуйте его в директорию `$HELM_PLUGINS`. Вы также можете установить плагин непосредственно из URL архива, выполнив команду `helm plugin install https://domain/path/to/plugin.tar.gz`\n\n## Структура файлов плагина\n\nВо многих отношениях плагин похож на чарт. Каждый плагин имеет директорию верхнего уровня, содержащую файл `plugin.yaml`. Могут присутствовать дополнительные файлы, но обязательным является только `plugin.yaml`.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## Файл plugin.yaml\n\nФайл plugin.yaml является обязательным для плагина. Он содержит следующие поля:\n\n```yaml\nname: Имя плагина (ОБЯЗАТЕЛЬНО)\nversion: Версия в формате SemVer 2 (ОБЯЗАТЕЛЬНО)\nusage: Однострочный текст использования, отображаемый в справке\ndescription: Длинное описание, отображаемое в helm help и т.д.\nignoreFlags: Игнорировать флаги, переданные из Helm\nplatformCommand: # Настройка команды для выполнения в зависимости от платформы\n  - os: Совпадение с ОС, можно оставить пустым или опустить для совпадения со всеми ОС\n    arch: Совпадение с архитектурой, можно оставить пустым или опустить для совпадения со всеми архитектурами\n    command: Команда плагина для выполнения\n    args: Аргументы команды плагина\ncommand: (УСТАРЕЛО) Команда плагина, используйте platformCommand вместо этого\nplatformHooks: # Настройка хуков жизненного цикла плагина в зависимости от платформы\n  install: # Команды установки\n    - os: Совпадение с ОС, можно оставить пустым или опустить для совпадения со всеми ОС\n      arch: Совпадение с архитектурой, можно оставить пустым или опустить для совпадения со всеми архитектурами\n      command: Команда установки плагина для выполнения\n      args: Аргументы команды установки\n  update: # Команды обновления\n    - os: Совпадение с ОС, можно оставить пустым или опустить для совпадения со всеми ОС\n      arch: Совпадение с архитектурой, можно оставить пустым или опустить для совпадения со всеми архитектурами\n      command: Команда обновления плагина для выполнения\n      args: Аргументы команды обновления\n  delete: # Команды удаления\n    - os: Совпадение с ОС, можно оставить пустым или опустить для совпадения со всеми ОС\n      arch: Совпадение с архитектурой, можно оставить пустым или опустить для совпадения со всеми архитектурами\n      command: Команда удаления плагина для выполнения\n      args: Аргументы команды удаления\nhooks: # (Устарело) Хуки жизненного цикла плагина, используйте platformHooks вместо этого\n  install: Команда для установки плагина\n  update: Команда для обновления плагина\n  delete: Команда для удаления плагина\ndownloaders: # Настройка возможности загрузки\n  - command: Команда для вызова\n    protocols:\n      - Поддерживаемая схема протокола\n```\n\n### Поле `name`\n\nПоле `name` определяет имя плагина. Когда Helm выполняет этот плагин, он использует именно это имя (например, `helm NAME` вызовет данный плагин).\n\n_`name` должно совпадать с именем директории._ В нашем примере выше плагин с `name: last` должен находиться в директории с именем `last`.\n\nОграничения для `name`:\n\n- `name` не может дублировать одну из существующих команд верхнего уровня `helm`.\n- `name` должно содержать только символы ASCII a-z, A-Z, 0-9, `_` и `-`.\n\n### Поле `version`\n\nПоле `version` содержит версию плагина в формате SemVer 2. Поля `usage` и `description` используются для генерации текста справки команды.\n\n### Поле `ignoreFlags`\n\nПараметр `ignoreFlags` указывает Helm _не_ передавать флаги плагину. Если плагин вызывается с `helm myplugin --foo` и установлено `ignoreFlags: true`, то флаг `--foo` будет проигнорирован.\n\n### Поле `platformCommand`\n\nПоле `platformCommand` настраивает команду, которую плагин выполнит при вызове. Нельзя одновременно задавать `platformCommand` и `command` — это приведёт к ошибке. При выборе команды применяются следующие правила:\n\n- Если присутствует `platformCommand`, он будет использоваться.\n  - Если и `os`, и `arch` совпадают с текущей платформой, поиск прекращается и команда выполняется.\n  - Если `os` совпадает, а `arch` пуст, команда выполняется.\n  - Если `os` и `arch` оба пусты, команда выполняется.\n  - Если совпадение не найдено, Helm завершится с ошибкой.\n- Если `platformCommand` отсутствует, но присутствует устаревшее поле `command`, оно будет использовано.\n  - Если команда пуста, Helm завершится с ошибкой.\n\n### Поле `platformHooks`\n\nПоле `platformHooks` настраивает команды, которые плагин выполнит для событий жизненного цикла. Нельзя одновременно задавать `platformHooks` и `hooks` — это приведёт к ошибке. При выборе команды хука применяются следующие правила:\n\n- Если присутствует `platformHooks`, он будет использоваться и команды для события жизненного цикла будут обработаны.\n  - Если и `os`, и `arch` совпадают с текущей платформой, поиск прекращается и команда выполняется.\n  - Если `os` совпадает, а `arch` пуст, команда выполняется.\n  - Если `os` и `arch` оба пусты, команда выполняется.\n  - Если совпадение не найдено, Helm пропустит событие.\n- Если `platformHooks` отсутствует, но присутствует устаревшее поле `hooks`, команда для события жизненного цикла будет использована.\n  - Если команда пуста, Helm пропустит событие.\n\n## Создание плагина\n\nНиже приведён YAML плагина для простого плагина, который помогает получить имя последнего релиза:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nПлагинам могут потребоваться дополнительные скрипты и исполняемые файлы.\nСкрипты можно включить в директорию плагина, а исполняемые файлы загрузить через хук. Вот пример плагина:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nПеременные окружения интерполируются перед выполнением плагина. Паттерн выше демонстрирует рекомендуемый способ указания расположения программы плагина.\n\n### Команды плагина\n\nСуществует несколько стратегий работы с командами плагина:\n\n- Если плагин включает исполняемый файл, он для `platformCommand:` должен быть упакован в директорию плагина или установлен через хук.\n- В строке `platformCommand:` или `command:` все переменные окружения будут раскрыты перед выполнением. `$HELM_PLUGIN_DIR` будет указывать на директорию плагина.\n- Сама команда не выполняется в оболочке. Поэтому нельзя записать shell-скрипт в одну строку.\n- Helm добавляет множество конфигурационных данных в переменные окружения. Изучите окружение, чтобы узнать, какая информация доступна.\n- Helm не делает предположений о языке плагина. Вы можете писать на любом языке, который предпочитаете.\n- Команды должны самостоятельно реализовывать текст справки для `-h` и `--help`. Helm будет использовать `usage` и `description` для `helm help` и `helm help myplugin`, но не будет обрабатывать `helm myplugin --help`.\n\n### Тестирование локального плагина\n\nСначала необходимо найти путь `HELM_PLUGINS`. Для этого выполните команду:\n\n``` bash\nhelm env\n```\n\nПерейдите в директорию, на которую указывает `HELM_PLUGINS`.\n\nТеперь вы можете создать символическую ссылку на выходные файлы сборки вашего плагина. В этом примере мы делаем это для `mapkubeapis`:\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Плагины-загрузчики\n\nПо умолчанию Helm может скачивать чарты по протоколам HTTP/S. Начиная с Helm 2.4.0, плагины могут иметь специальную возможность загружать чарты из произвольных источников.\n\nПлагины объявляют эту специальную возможность в файле `plugin.yaml` (на верхнем уровне):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nЕсли такой плагин установлен, Helm может взаимодействовать с репозиторием, используя указанную схему протокола, вызывая `command`. Специальный репозиторий добавляется так же, как обычный: `helm repo add favorite myprotocol://example.com/` Правила для специальных репозиториев такие же, как для обычных: Helm должен иметь возможность загрузить файл `index.yaml`, чтобы обнаружить и закешировать список доступных чартов.\n\nОпределённая команда будет вызываться по схеме: `command certFile keyFile caFile full-URL`. SSL-учётные данные берутся из определения репозитория, хранящегося в `$HELM_REPOSITORY_CONFIG` (то есть `$HELM_CONFIG_HOME/repositories.yaml`). Плагин-загрузчик должен выводить сырое содержимое в stdout и сообщать об ошибках в stderr.\n\nКоманда загрузчика также поддерживает подкоманды или аргументы, что позволяет указать, например, `bin/mydownloader subcommand -d` в `plugin.yaml`. Это полезно, если вы хотите использовать один исполняемый файл как для основной команды плагина, так и для команды загрузчика, но с разными подкомандами.\n\n## Переменные окружения\n\nКогда Helm выполняет плагин, он передаёт плагину внешнее окружение, а также добавляет некоторые дополнительные переменные окружения.\n\nПеременные вроде `KUBECONFIG` будут установлены для плагина, если они заданы во внешнем окружении.\n\nСледующие переменные гарантированно установлены:\n\n- `HELM_PLUGINS`: Путь к директории плагинов.\n- `HELM_PLUGIN_NAME`: Имя плагина в том виде, в котором оно было вызвано через `helm`. Так, `helm myplug` будет иметь короткое имя `myplug`.\n- `HELM_PLUGIN_DIR`: Директория, содержащая плагин.\n- `HELM_BIN`: Путь к команде `helm` (как она была выполнена пользователем).\n- `HELM_DEBUG`: Указывает, был ли установлен флаг debug в helm.\n- `HELM_REGISTRY_CONFIG`: Расположение конфигурации реестра (при использовании). Обратите внимание, что использование Helm с реестрами является экспериментальной возможностью.\n- `HELM_REPOSITORY_CACHE`: Путь к файлам кеша репозиториев.\n- `HELM_REPOSITORY_CONFIG`: Путь к файлу конфигурации репозиториев.\n- `HELM_NAMESPACE`: namespace, переданный команде `helm` (обычно с флагом `-n`).\n- `HELM_KUBECONTEXT`: Имя контекста конфигурации Kubernetes, переданное команде `helm`.\n\nКроме того, если файл конфигурации Kubernetes был явно указан, он будет установлен как переменная `KUBECONFIG`.\n\n## Замечание о разборе флагов\n\nПри выполнении плагина Helm разбирает глобальные флаги для собственного использования. Ни один из этих флагов не передаётся плагину.\n- `--burst-limit`: Преобразуется в `$HELM_BURST_LIMIT`\n- `--debug`: Если указан, `$HELM_DEBUG` устанавливается в `1`\n- `--kube-apiserver`: Преобразуется в `$HELM_KUBEAPISERVER`\n- `--kube-as-group`: Преобразуется в `$HELM_KUBEASGROUPS`\n- `--kube-as-user`: Преобразуется в `$HELM_KUBEASUSER`\n- `--kube-ca-file`: Преобразуется в `$HELM_KUBECAFILE`\n- `--kube-context`: Преобразуется в `$HELM_KUBECONTEXT`\n- `--kube-insecure-skip-tls-verify`: Преобразуется в `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`\n- `--kube-tls-server-name`: Преобразуется в `$HELM_KUBETLS_SERVER_NAME`\n- `--kube-token`: Преобразуется в `$HELM_KUBETOKEN`\n- `--kubeconfig`: Преобразуется в `$KUBECONFIG`\n- `--namespace` и `-n`: Преобразуется в `$HELM_NAMESPACE`\n- `--qps`: Преобразуется в `$HELM_QPS`\n- `--registry-config`: Преобразуется в `$HELM_REGISTRY_CONFIG`\n- `--repository-cache`: Преобразуется в `$HELM_REPOSITORY_CACHE`\n- `--repository-config`: Преобразуется в `$HELM_REPOSITORY_CONFIG`\n\nПлагины _должны_ выводить справочный текст и завершаться для `-h` и `--help`. В остальных случаях плагины могут использовать флаги по своему усмотрению.\n\n## Поддержка автодополнения в оболочке\n\nНачиная с Helm 3.2, плагин может опционально предоставлять поддержку автодополнения в оболочке как часть существующего механизма автодополнения Helm.\n\n### Статическое автодополнение\n\nЕсли плагин предоставляет собственные флаги и/или подкоманды, он может сообщить о них Helm, разместив файл `completion.yaml` в корневой директории плагина. Файл `completion.yaml` имеет следующий формат:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <и так далее, рекурсивно>\n```\n\nПримечания:\n\n1. Все секции необязательны, но должны быть предоставлены при необходимости.\n1. Флаги не должны включать префикс `-` или `--`.\n1. Следует указывать как короткие, так и длинные флаги. Короткий флаг не обязательно должен быть связан с соответствующей длинной формой, но обе формы должны быть перечислены.\n1. Флаги не требуют определённого порядка, но должны быть указаны в правильной точке иерархии подкоманд файла.\n1. Существующие глобальные флаги Helm уже обрабатываются механизмом автодополнения Helm, поэтому плагинам не нужно указывать флаги `--debug`, `--namespace` или `-n`, `--kube-context`, `--kubeconfig` и другие глобальные флаги.\n1. Список `validArgs` предоставляет статический список возможных вариантов завершения для первого параметра после подкоманды. Не всегда возможно предоставить такой список заранее (см. раздел [Динамическое автодополнение](#динамическое-автодополнение) ниже), в этом случае секцию `validArgs` можно опустить.\n\nФайл `completion.yaml` полностью необязателен. Если он не предоставлен, Helm просто не будет предоставлять автодополнение в оболочке для плагина (если только плагин не поддерживает [Динамическое автодополнение](#динамическое-автодополнение)). Кроме того, добавление файла `completion.yaml` обратно совместимо и не повлияет на поведение плагина при использовании более старых версий Helm.\n\nВ качестве примера для плагина [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus), который не имеет подкоманд, но принимает те же флаги, что и команда `helm status`, файл `completion.yaml` выглядит так:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nБолее сложный пример для плагина [`2to3`](https://github.com/helm/helm-2to3), файл `completion.yaml` которого:\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### Динамическое автодополнение\n\nТакже начиная с Helm 3.2, плагины могут предоставлять собственное динамическое автодополнение в оболочке. Динамическое автодополнение — это завершение значений параметров или флагов, которые невозможно определить заранее. Например, автодополнение имён релизов Helm, доступных в кластере.\n\nДля поддержки динамического автодополнения плагин должен предоставить **исполняемый** файл `plugin.complete` в своей корневой директории. Когда скрипту автодополнения Helm требуются динамические варианты для плагина, он выполняет файл `plugin.complete`, передавая ему командную строку, которую нужно завершить. Исполняемый файл `plugin.complete` должен содержать логику для определения подходящих вариантов завершения и выводить их на стандартный вывод для использования скриптом автодополнения Helm.\n\nФайл `plugin.complete` полностью необязателен. Если он не предоставлен, Helm просто не будет предоставлять динамическое автодополнение для плагина. Кроме того, добавление файла `plugin.complete` обратно совместимо и не повлияет на поведение плагина при использовании более старых версий Helm.\n\nВывод скрипта `plugin.complete` должен быть списком, разделённым символами новой строки:\n\n```console\nrel1\nrel2\nrel3\n```\n\nПри вызове `plugin.complete` окружение плагина настраивается так же, как при вызове основного скрипта плагина. Поэтому переменные `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` и все остальные переменные плагина уже будут установлены, а соответствующие глобальные флаги будут удалены.\n\nФайл `plugin.complete` может быть в любой исполняемой форме: shell-скрипт, программа на Go или любая другая программа, которую Helm может выполнить. Файл `plugin.complete` ***должен*** иметь права на выполнение для пользователя. Файл `plugin.complete` ***должен*** завершаться с кодом успеха (значение 0).\n\nВ некоторых случаях для динамического автодополнения потребуется получить информацию из кластера Kubernetes. Например, плагину `helm fullstatus` требуется имя релиза на входе. В плагине `fullstatus` скрипт `plugin.complete` может просто выполнить `helm list -q` и вывести результат для автодополнения текущих имён релизов.\n\nЕсли желательно использовать один исполняемый файл как для выполнения плагина, так и для автодополнения плагина, скрипт `plugin.complete` может вызывать основной исполняемый файл плагина с каким-либо специальным параметром или флагом; когда основной исполняемый файл обнаружит специальный параметр или флаг, он будет знать, что нужно запустить автодополнение. В нашем примере `plugin.complete` может быть реализован так:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" — это вся командная строка, требующая завершения.\n# Важно заключить \"$@\" в двойные кавычки, чтобы сохранить возможно пустой последний параметр.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nРеальный скрипт плагина `fullstatus` (`status.sh`) должен искать флаг `--complete` и при его обнаружении выводить соответствующие варианты завершения.\n\n### Советы и рекомендации\n\n1. Оболочка автоматически отфильтровывает варианты завершения, не соответствующие вводу пользователя. Поэтому плагин может возвращать все релевантные варианты, не удаляя те, что не соответствуют вводу. Например, если командная строка `helm fullstatus ngin<TAB>`, скрипт `plugin.complete` может вывести *все* имена релизов (в namespace `default`), а не только начинающиеся с `ngin`; оболочка оставит только те, что начинаются с `ngin`.\n1. Для упрощения поддержки динамического автодополнения, особенно для сложного плагина, скрипт `plugin.complete` может вызывать основной скрипт плагина и запрашивать варианты завершения. См. раздел [Динамическое автодополнение](#динамическое-автодополнение) выше для примера.\n1. Для отладки динамического автодополнения и файла `plugin.complete` можно выполнить следующее, чтобы увидеть результаты завершения:\n    - `helm __complete <pluginName> <arguments to complete>`. Например:\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: Происхождение и целостность Helm\ndescription: Описывает проверку целостности и происхождения чарта.\nsidebar_position: 5\n---\n\nHelm предоставляет инструменты проверки происхождения, которые помогают пользователям чартов подтвердить целостность и происхождение пакета. Используя отраслевые стандарты на основе PKI, GnuPG и проверенных менеджеров пакетов, Helm может генерировать и проверять файлы подписей.\n\n## Обзор\n\nЦелостность устанавливается путём сравнения чарта с записью о происхождении. Записи о происхождении хранятся в *файлах происхождения*, которые размещаются вместе с упакованным чартом. Например, если чарт называется `myapp-1.2.3.tgz`, его файл происхождения будет называться `myapp-1.2.3.tgz.prov`.\n\nФайлы происхождения создаются при упаковке (`helm package --sign ...`) и могут быть проверены несколькими командами, в частности `helm install --verify`.\n\n## Рабочий процесс\n\nВ этом разделе описывается возможный рабочий процесс для эффективного использования данных о происхождении.\n\nПредварительные требования:\n\n- Действительная пара ключей PGP в бинарном формате (не ASCII-armored)\n- Инструмент командной строки `helm`\n- Инструменты командной строки GnuPG (опционально)\n- Инструменты командной строки Keybase (опционально)\n\n**ПРИМЕЧАНИЕ:** Если ваш закрытый ключ PGP защищён парольной фразой, вам будет предложено ввести её для всех команд, поддерживающих опцию `--sign`.\n\nСоздание нового чарта выполняется как обычно:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nКогда чарт готов к упаковке, добавьте флаг `--sign` к команде `helm package`. Также укажите имя, под которым известен ключ подписи, и связку ключей, содержащую соответствующий закрытый ключ:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**Примечание:** Значение аргумента `--key` должно быть подстрокой `uid` нужного ключа (из вывода `gpg --list-keys`), например, именем или email. **Отпечаток (fingerprint) использовать _нельзя_.**\n\n**СОВЕТ:** Для пользователей GnuPG секретная связка ключей находится в `~/.gnupg/secring.gpg`. Вы можете использовать команду `gpg --list-secret-keys` для просмотра доступных ключей.\n\n**Предупреждение:** В GnuPG v2 секретная связка ключей хранится в новом формате `kbx` в стандартном расположении `~/.gnupg/pubring.kbx`. Используйте следующую команду для преобразования связки ключей в устаревший формат gpg:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nНа этом этапе вы должны увидеть файлы `mychart-0.1.0.tgz` и `mychart-0.1.0.tgz.prov`. Оба файла следует загрузить в выбранный вами репозиторий чартов.\n\nВы можете проверить чарт с помощью `helm verify`:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nНеудачная проверка выглядит следующим образом:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nДля проверки при установке используйте флаг `--verify`:\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nЕсли связка ключей с открытым ключом, соответствующим подписанному чарту, находится не в стандартном расположении, вам может потребоваться указать путь к ней с помощью `--keyring PATH`, как в примере с `helm package`.\n\nПри неудачной проверке установка будет прервана ещё до рендеринга чарта.\n\n### Использование учётных данных Keybase.io\n\nСервис [Keybase.io](https://keybase.io) упрощает создание цепочки доверия для криптографической идентичности. Учётные данные Keybase можно использовать для подписи чартов.\n\nПредварительные требования:\n\n- Настроенная учётная запись Keybase.io\n- Локально установленный GnuPG\n- Локально установленный CLI `keybase`\n\n#### Подпись пакетов\n\nПервый шаг — импорт ваших ключей Keybase в локальную связку ключей GnuPG:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nЭта команда преобразует ваш ключ Keybase в формат OpenPGP и импортирует его локально в файл `~/.gnupg/secring.gpg`.\n\nВы можете проверить результат командой `gpg --list-secret-keys`:\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nОбратите внимание, что ваш секретный ключ имеет идентификационную строку:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nЭто полное имя вашего ключа.\n\nТеперь вы можете упаковать и подписать чарт командой `helm package`. Убедитесь, что используете хотя бы часть этой строки имени в аргументе `--key`:\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nВ результате команда `package` создаст файлы `.tgz` и `.tgz.prov`.\n\n#### Проверка пакетов\n\nАналогичным образом можно проверить чарт, подписанный ключом Keybase другого пользователя. Допустим, вы хотите проверить пакет, подписанный `keybase.io/technosophos`. Для этого используйте инструмент `keybase`:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nПервая команда начинает отслеживание пользователя `technosophos`. Затем `keybase pgp pull` загружает OpenPGP-ключи всех отслеживаемых вами учётных записей и помещает их в вашу связку ключей GnuPG (`~/.gnupg/pubring.gpg`).\n\nПосле этого вы можете использовать `helm verify` или любые команды с флагом `--verify`:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Причины, по которым проверка чарта может не пройти\n\nВот типичные причины неудачной проверки:\n\n- Файл `.prov` отсутствует или повреждён. Это указывает на ошибку конфигурации или на то, что исходный сопровождающий не создал файл происхождения.\n- Ключ, использованный для подписи файла, отсутствует в вашей связке ключей. Это означает, что подписавшая сторона не входит в число тех, кому вы уже выразили доверие.\n- Проверка файла `.prov` не прошла. Это указывает на проблему либо с чартом, либо с данными о происхождении.\n- Хеши файлов в файле происхождения не совпадают с хешем файла архива. Это указывает на то, что архив был изменён.\n\nПри неудачной проверке есть основания не доверять пакету.\n\n## Файл происхождения\n\nФайл происхождения содержит YAML-файл чарта плюс несколько элементов проверочной информации. Файлы происхождения предназначены для автоматической генерации.\n\nДобавляются следующие данные о происхождении:\n\n* Файл чарта (`Chart.yaml`) включается для того, чтобы люди и инструменты могли легко просмотреть содержимое чарта.\n* Подпись (SHA256, как в Docker) пакета чарта (файла `.tgz`) включается для проверки целостности пакета.\n* Всё тело подписывается с использованием алгоритма OpenPGP (см. [Keybase.io](https://keybase.io) как современный способ упростить криптографическую подпись и проверку).\n\nКомбинация этих элементов даёт пользователям следующие гарантии:\n\n* Сам пакет не был изменён (контрольная сумма пакета `.tgz`).\n* Сторона, выпустившая этот пакет, известна (через подпись GnuPG/PGP).\n\nФормат файла выглядит примерно так:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nОбратите внимание, что YAML-секция содержит два документа (разделённых `...\\n`). Первый файл — содержимое `Chart.yaml`. Второй — контрольные суммы: соответствие имён файлов и SHA-256 дайджестов содержимого этих файлов на момент упаковки.\n\nБлок подписи — это стандартная PGP-подпись, обеспечивающая [защиту от изменений](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Репозитории чартов\n\nРепозитории чартов служат централизованным хранилищем чартов Helm.\n\nРепозитории чартов должны обеспечивать возможность получения файлов происхождения по HTTP через определённый запрос и делать их доступными по тому же URI-пути, что и чарт.\n\nНапример, если базовый URL пакета — `https://example.com/charts/mychart-1.2.3.tgz`, то файл происхождения, если он существует, ДОЛЖЕН быть доступен по адресу `https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nС точки зрения конечного пользователя, команда `helm install --verify myrepo/mychart-1.2.3` должна приводить к загрузке как чарта, так и файла происхождения без дополнительной настройки или действий со стороны пользователя.\n\n### Подписи в реестрах на базе OCI\n\nПри публикации чартов в [реестре на базе 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` позволяет опубликовать данные о происхождении в неизменяемый журнал прозрачности.\n\n## Установление авторитета и подлинности\n\nПри работе с системами цепочки доверия важно иметь возможность установить авторитет подписывающей стороны. Иными словами, описанная выше система основана на том, что вы доверяете лицу, подписавшему чарт. А это, в свою очередь, означает, что вам нужно доверять открытому ключу подписывающей стороны.\n\nОдним из проектных решений Helm стало то, что проект Helm не будет включать себя в цепочку доверия как обязательную сторону. Мы не хотим быть «центром сертификации» для всех подписывающих чарты. Вместо этого мы настоятельно поддерживаем децентрализованную модель, что является одной из причин выбора OpenPGP в качестве базовой технологии. Поэтому, когда речь идёт об установлении авторитета, мы оставили этот шаг практически неопределённым в Helm 2 (это решение сохранено и в Helm 3).\n\nТем не менее у нас есть рекомендации для тех, кто заинтересован в использовании системы происхождения:\n\n- Платформа [Keybase](https://keybase.io) предоставляет публичный централизованный репозиторий информации о доверии.\n  - Вы можете использовать Keybase для хранения своих ключей или получения открытых ключей других пользователей.\n  - Keybase также предоставляет отличную документацию.\n  - Хотя мы не тестировали это, функция «безопасного веб-сайта» Keybase может использоваться для размещения чартов Helm.\n  - Основная идея заключается в том, что официальный «рецензент чартов» подписывает чарты своим ключом, а полученный файл происхождения загружается в репозиторий чартов.\n  - Ведётся работа над идеей включения списка допустимых ключей подписи в файл `index.yaml` репозитория.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: Управление доступом на основе ролей\ndescription: Описывает взаимодействие Helm с системой управления доступом на основе ролей (RBAC) в Kubernetes.\nsidebar_position: 11\n---\n\nВ Kubernetes назначение ролей пользователям или сервисным учётным записям приложений является лучшей практикой, позволяющей ограничить права приложения заданной областью. Подробнее о правах сервисных учётных записей читайте в [официальной документации Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nНачиная с Kubernetes 1.6, управление доступом на основе ролей (RBAC) включено по умолчанию. RBAC позволяет определять, какие типы действий разрешены в зависимости от пользователя и его роли в организации.\n\nС помощью RBAC вы можете:\n\n- предоставлять администраторам привилегированные операции (создание ресурсов на уровне кластера, таких как новые роли)\n- ограничивать возможности пользователя по созданию ресурсов (Pod, PersistentVolume, Deployment) в определённых namespace или на уровне всего кластера (квоты ресурсов, роли, CustomResourceDefinition)\n- ограничивать возможности пользователя по просмотру ресурсов в определённых namespace или на уровне всего кластера\n\nРуководство адресовано администраторам, которые хотят ограничить область взаимодействия пользователей с API Kubernetes.\n\n## Управление учётными записями пользователей\n\nВсе кластеры Kubernetes имеют две категории пользователей: сервисные учётные записи, управляемые Kubernetes, и обычные пользователи.\n\nПредполагается, что обычные пользователи управляются внешним независимым сервисом — администратор распределяет приватные ключи, используется хранилище пользователей вроде Keystone или Google Accounts, либо файл со списком имён пользователей и паролей. Поэтому в Kubernetes нет объектов, представляющих обычные учётные записи пользователей. Обычных пользователей нельзя добавить в кластер через вызов API.\n\nСервисные учётные записи, напротив, управляются через API Kubernetes. Они привязаны к определённым namespace и создаются автоматически сервером API или вручную через вызовы API. Сервисные учётные записи связаны с набором учётных данных, хранящихся как Secret, которые монтируются в Pod, позволяя процессам внутри кластера взаимодействовать с API Kubernetes.\n\nЗапросы к API связаны либо с обычным пользователем, либо с сервисной учётной записью, либо обрабатываются как анонимные. Это означает, что каждый процесс — как внутри, так и вне кластера — от пользователя, выполняющего `kubectl` на рабочей станции, до kubelet на узлах и компонентов плоскости управления, должен аутентифицироваться при обращении к серверу API или будет рассматриваться как анонимный пользователь.\n\n## Role, ClusterRole, RoleBinding и ClusterRoleBinding\n\nВ Kubernetes учётные записи пользователей и сервисные учётные записи могут просматривать и редактировать только те ресурсы, к которым им предоставлен доступ. Этот доступ предоставляется с помощью Role и RoleBinding. Role и RoleBinding привязаны к определённому namespace и предоставляют пользователям возможность просматривать и/или редактировать ресурсы в этом namespace в соответствии с назначенной Role.\n\nНа уровне кластера используются ClusterRole и ClusterRoleBinding. Предоставление пользователю ClusterRole даёт ему доступ к просмотру и/или редактированию ресурсов во всём кластере. Это также необходимо для просмотра и/или редактирования ресурсов на уровне кластера (namespace, квоты ресурсов, узлы).\n\nClusterRole можно привязать к определённому namespace через RoleBinding. Стандартные ClusterRole `admin`, `edit` и `view` часто используются таким образом.\n\nВ Kubernetes по умолчанию доступно несколько ClusterRole. Они предназначены для пользователей и включают роли суперпользователя (`cluster-admin`) и роли с более детальным контролем доступа (`admin`, `edit`, `view`).\n\n| Стандартная ClusterRole | Стандартный ClusterRoleBinding | Описание\n|---------------------|----------------------------|-------------\n| `cluster-admin`     | группа `system:masters`     | Предоставляет доступ суперпользователя для выполнения любого действия над любым ресурсом. При использовании в ClusterRoleBinding даёт полный контроль над всеми ресурсами в кластере и во всех namespace. При использовании в RoleBinding даёт полный контроль над всеми ресурсами в namespace привязки роли, включая сам namespace.\n| `admin`             | Нет                       | Предоставляет административный доступ, предназначенный для назначения в рамках namespace через RoleBinding. При использовании в RoleBinding разрешает чтение/запись большинства ресурсов в namespace, включая возможность создания Role и RoleBinding в этом namespace. Не разрешает запись в квоты ресурсов или сам namespace.\n| `edit`              | Нет                       | Разрешает чтение/запись большинства объектов в namespace. Не разрешает просмотр или изменение Role или RoleBinding.\n| `view`              | Нет                       | Разрешает просмотр большинства объектов в namespace (только чтение). Не разрешает просмотр Role, RoleBinding или Secret из соображений безопасности.\n\n## Ограничение доступа учётной записи пользователя с помощью RBAC\n\nТеперь, когда мы разобрались с основами управления доступом на основе ролей, рассмотрим, как администратор может ограничить область доступа пользователя.\n\n### Пример: предоставление пользователю доступа на чтение/запись в определённом namespace\n\nЧтобы ограничить доступ пользователя определённым namespace, можно использовать роль `edit` или `admin`. Если ваши чарты создают или взаимодействуют с Role и RoleBinding, следует использовать ClusterRole `admin`.\n\nКроме того, можно создать RoleBinding с доступом `cluster-admin`. Предоставление пользователю доступа `cluster-admin` на уровне namespace даёт полный контроль над всеми ресурсами в этом namespace, включая сам namespace.\n\nВ этом примере мы создадим пользователя с ролью `edit`. Сначала создайте namespace:\n\n```console\n$ kubectl create namespace foo\n```\n\nТеперь создайте RoleBinding в этом namespace, назначив пользователю роль `edit`.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Пример: предоставление пользователю доступа на чтение/запись на уровне кластера\n\nЕсли пользователю нужно устанавливать чарты, создающие ресурсы на уровне кластера (namespace, роли, CustomResourceDefinition и т.д.), ему потребуется доступ на запись на уровне кластера.\n\nДля этого предоставьте пользователю доступ `admin` или `cluster-admin`.\n\nПредоставление пользователю доступа `cluster-admin` даёт доступ абсолютно ко всем ресурсам в Kubernetes, включая доступ к узлам через `kubectl drain` и другие административные операции. Настоятельно рекомендуется предоставлять пользователю доступ `admin` или создать пользовательскую ClusterRole, соответствующую его потребностям.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Пример: предоставление пользователю доступа только на чтение в определённом namespace\n\nВы могли заметить, что стандартной ClusterRole для просмотра Secret не существует. ClusterRole `view` не предоставляет доступ на чтение Secret из соображений безопасности. По умолчанию Helm хранит метаданные релиза как Secret.\n\nЧтобы пользователь мог выполнить `helm list`, ему нужен доступ на чтение Secret. Для этого мы создадим специальную ClusterRole `secret-reader`.\n\nСоздайте файл `cluster-role-secret-reader.yaml` и добавьте в него следующее содержимое:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nЗатем создайте ClusterRole с помощью команды:\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nПосле этого мы можем предоставить пользователю доступ на чтение большинства ресурсов, а затем добавить доступ на чтение Secret:\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Пример: предоставление пользователю доступа только на чтение на уровне кластера\n\nВ некоторых сценариях может быть полезно предоставить пользователю доступ на уровне кластера. Например, если пользователь хочет выполнить команду `helm list --all-namespaces`, API требует, чтобы у пользователя был доступ на чтение на уровне кластера.\n\nДля этого предоставьте пользователю доступ `view` и `secret-reader`, как описано выше, но с использованием ClusterRoleBinding.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Дополнительные соображения\n\nВ приведённых выше примерах используются стандартные ClusterRole, поставляемые с Kubernetes. Для более детального контроля над доступом пользователей к ресурсам обратитесь к [документации Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) по созданию собственных Role и ClusterRole.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: Использование реестров на базе OCI\ndescription: Описывает, как использовать OCI для распространения чартов.\nsidebar_position: 7\n---\n\nНачиная с Helm 3, вы можете использовать контейнерные реестры с поддержкой [OCI](https://www.opencontainers.org/) для хранения и распространения пакетов чартов. Начиная с Helm v3.8.0, поддержка OCI включена по умолчанию.\n\n\n## Поддержка OCI до версии v3.8.0\n\nПоддержка OCI перешла из экспериментальной стадии в общедоступную в Helm v3.8.0. В более ранних версиях Helm поддержка OCI работала иначе. Если вы использовали поддержку OCI до Helm v3.8.0, важно понимать, что изменилось в разных версиях Helm.\n\n### Включение поддержки OCI до версии v3.8.0\n\nДо версии Helm v3.8.0 поддержка OCI была *экспериментальной* и требовала явного включения.\n\nЧтобы включить экспериментальную поддержку OCI для версий Helm до v3.8.0, установите переменную окружения `HELM_EXPERIMENTAL_OCI`. Например:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### Устаревшие возможности OCI и изменения поведения в v3.8.0\n\nВ релизе [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) следующие возможности и поведение отличаются от предыдущих версий Helm:\n\n- При указании чарта в зависимостях как OCI версию можно задавать в виде диапазона, как и для других зависимостей.\n- Теги SemVer, содержащие информацию о сборке, можно отправлять и использовать. Реестры OCI не поддерживают символ `+` в тегах. Helm преобразует `+` в `_` при сохранении в виде тега.\n- Команда `helm registry login` теперь следует той же структуре, что и Docker CLI для хранения учётных данных. Одно и то же расположение конфигурации реестра можно использовать как для Helm, так и для Docker CLI.\n\n### Устаревшие возможности OCI и изменения поведения в v3.7.0\n\nВ релизе [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:\n\n- Подкоманда `helm chart` удалена.\n- Кеш чартов удалён (нет `helm chart list` и т.д.).\n- Ссылки на реестры OCI теперь всегда должны иметь префикс `oci://`.\n- Базовое имя ссылки на реестр *всегда* должно совпадать с именем чарта.\n- Тег ссылки на реестр *всегда* должен совпадать с семантической версией чарта (т.е. теги `latest` не поддерживаются).\n- Медиатип слоя чарта изменён с `application/tar+gzip` на `application/vnd.cncf.helm.chart.content.v1.tar+gzip`.\n\n\n## Использование реестров на базе OCI\n\n### Репозитории Helm в реестрах на базе OCI\n\n[Репозиторий Helm](/topics/chart_repository.md) — это способ размещения и распространения упакованных чартов Helm. Реестр на базе OCI может содержать ноль или более репозиториев Helm, и каждый из этих репозиториев может содержать ноль или более упакованных чартов Helm.\n\n### Использование облачных реестров\n\nСуществует несколько облачных контейнерных реестров с поддержкой OCI, которые вы можете использовать для своих чартов Helm. Например:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\nСледуйте документации вашего провайдера облачных контейнерных реестров для создания и настройки реестра с поддержкой OCI.\n\n**Примечание:** Вы можете запустить [Docker Registry](https://docs.docker.com/registry/deploying/) или [`zot`](https://github.com/project-zot/zot) — реестры на базе OCI — на локальном компьютере. Локальные реестры следует использовать только для тестирования.\n\n### Использование sigstore для подписи чартов на базе OCI\n\nПлагин [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) позволяет использовать [Sigstore](https://sigstore.dev/) для подписи чартов Helm теми же инструментами, что используются для подписи контейнерных образов. Это альтернатива [происхождению на основе GPG](/topics/provenance.md), поддерживаемому классическими [репозиториями чартов](/topics/chart_repository.md).\n\nПодробнее об использовании плагина `helm sigstore` см. в [документации проекта](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md).\n\n## Команды для работы с реестрами\n\n### Подкоманда `registry`\n\n#### `login`\n\nвход в реестр (с ручным вводом пароля)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nвыход из реестра\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### Подкоманда `push`\n\nЗагрузка чарта в реестр на базе OCI:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nПодкоманда `push` работает только с файлами `.tgz`,\nпредварительно созданными с помощью `helm package`.\n\nПри использовании `helm push` для загрузки чарта в реестр OCI ссылка\nдолжна иметь префикс `oci://` и не должна содержать базовое имя или тег.\n\nБазовое имя берётся из имени чарта, а тег — из семантической версии чарта.\nэто строгое требование.\n\nНекоторые реестры требуют предварительного создания репозитория и/или namespace (если указан).\nВ противном случае во время операции `helm push` возникнет ошибка.\n\nЕсли вы создали [файл происхождения](/topics/provenance.md) (`.prov`) и он находится рядом с файлом чарта `.tgz`, он будет автоматически загружен в реестр при выполнении `push`. Это приводит к появлению дополнительного слоя в [манифесте чарта Helm](#манифест-чарта-helm).\n\nПользователи [плагина helm-push](https://github.com/chartmuseum/helm-push) (для загрузки чартов в [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server))\nмогут столкнуться с проблемами, поскольку плагин конфликтует с новой встроенной командой `push`.\nНачиная с версии v0.10.0, плагин был переименован в `cm-push`.\n\n### Другие подкоманды\n\nПоддержка протокола `oci://` также доступна в различных других подкомандах.\nВот полный список:\n\n- `helm pull`\n- `helm push`\n- `helm show`\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nБазовое имя (имя чарта) ссылки на реестр *включается*\nдля любых действий, связанных с загрузкой чарта\n(в отличие от `helm push`, где оно опускается).\n\nПримеры использования подкоманд с OCI-чартами:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Установка чартов с использованием дайджеста\n\nУстановка чарта с использованием дайджеста более безопасна, чем с использованием тега, поскольку дайджесты неизменяемы.\nДайджест указывается в URI чарта:\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## Указание зависимостей\n\nЗависимости чарта можно загружать из реестра с помощью подкоманды `dependency update`.\n\nЗначение `repository` для записи в `Chart.yaml` указывается как ссылка на реестр без базового имени:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\nПри выполнении `dependency update` будет загружен `oci://localhost:5000/myrepo/mychart:2.7.0`.\n\n## Манифест чарта Helm\n\nПример манифеста чарта Helm в том виде, как он представлен в реестре\n(обратите внимание на поля `mediaType`):\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nСледующий пример содержит\n[файл происхождения](/topics/provenance.md)\n(обратите внимание на дополнительный слой):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Миграция с репозиториев чартов\n\nМиграция с классических [репозиториев чартов](/topics/chart_repository.md)\n(репозиториев на основе index.yaml) выполняется просто: используйте `helm pull`, а затем `helm push` для загрузки полученных файлов `.tgz` в реестр.\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: Миграция с Helm v2 на v3\ndescription: Узнайте, как мигрировать с Helm v2 на v3.\nsidebar_position: 13\n---\n\nВ этом руководстве описано, как мигрировать с Helm v2 на v3. Helm v2 должен быть\nустановлен и управлять релизами в одном или нескольких кластерах.\n\n## Обзор изменений в Helm 3\n\nПолный список изменений между Helm 2 и 3 задокументирован в\n[FAQ](/faq/changes_since_helm2.md). Ниже приведено краткое\nизложение некоторых изменений, о которых пользователю следует знать до и\nво время миграции:\n\n1. Удаление Tiller:\n   - Архитектура клиент/сервер заменена на клиент/библиотека (только бинарный\n     файл `helm`)\n   - Безопасность теперь реализована на уровне пользователя (делегирована\n     системе безопасности кластера Kubernetes)\n   - Релизы теперь хранятся как Secrets внутри кластера, и метаданные объекта\n     релиза изменились\n   - Релизы сохраняются в namespace релиза, а не в namespace Tiller\n2. Обновления репозитория чартов:\n   - `helm search` теперь поддерживает как поиск по локальным репозиториям, так\n     и запросы к Artifact Hub\n3. Версия apiVersion чарта обновлена до \"v2\" для следующих изменений спецификации:\n   - Динамически связанные зависимости чартов перенесены в `Chart.yaml`\n     (`requirements.yaml` удалён, requirements --> dependencies)\n   - Чарты-библиотеки (вспомогательные/общие чарты) теперь можно добавлять как\n     динамически связанные зависимости\n   - У чартов появилось поле метаданных `type` для определения типа чарта:\n     `application` или `library`. По умолчанию — application, что означает\n     возможность рендеринга и установки\n   - Чарты Helm 2 (apiVersion=v1) по-прежнему можно устанавливать\n4. Добавлена спецификация директорий XDG:\n   - Домашняя директория Helm удалена и заменена спецификацией директорий XDG\n     для хранения файлов конфигурации\n   - Больше не нужно инициализировать Helm\n   - Команды `helm init` и `helm home` удалены\n5. Дополнительные изменения:\n   - Упрощена установка/настройка Helm:\n     - Только клиент Helm (бинарный файл helm), без Tiller\n     - Парадигма «запустил и работает»\n   - Репозитории `local` и `stable` не настраиваются по умолчанию\n   - Хук `crd-install` удалён и заменён директорией `crds` в чарте, где все\n     CRD устанавливаются перед рендерингом чарта\n   - Значение аннотации хука `test-failure` удалено, `test-success` объявлено\n     устаревшим. Используйте `test` вместо них\n   - Команды удалены/заменены/добавлены:\n       - delete --> uninstall: по умолчанию удаляет всю историю релиза\n         (раньше требовался флаг `--purge`)\n       - fetch --> pull\n       - home (удалена)\n       - init (удалена)\n       - install: требует имя релиза или аргумент `--generate-name`\n       - inspect --> show\n       - reset (удалена)\n       - serve (удалена)\n       - template: аргумент `-x`/`--execute` переименован в `-s`/`--show-only`\n       - upgrade: добавлен аргумент `--history-max`, ограничивающий максимальное\n         количество сохраняемых ревизий на релиз (0 — без ограничений)\n   - Go-библиотека Helm 3 значительно изменилась и несовместима с библиотекой\n     Helm 2\n   - Бинарные файлы релизов теперь размещаются на `get.helm.sh`\n\n## Сценарии миграции\n\nВозможны следующие сценарии миграции:\n\n1. Helm v2 и v3 управляют одним кластером:\n   - Этот сценарий рекомендуется только если вы планируете постепенно отказаться\n     от Helm v2 и не нуждаетесь в управлении v3 релизами, развёрнутыми через v2.\n     Все новые релизы должны развёртываться через v3, а существующие релизы v2\n     обновляются/удаляются только через v2\n   - Helm v2 и v3 могут без проблем управлять одним кластером. Версии Helm\n     можно установить на одной или разных системах\n   - Если вы устанавливаете Helm v3 на ту же систему, необходим дополнительный\n     шаг для сосуществования обеих версий клиента до удаления клиента Helm v2.\n     Переименуйте бинарный файл Helm v3 или поместите его в другую папку для\n     избежания конфликта\n   - В остальном конфликтов между версиями нет благодаря следующим различиям:\n     - Хранилища релизов (истории) v2 и v3 независимы друг от друга. Изменения\n       включают ресурс Kubernetes для хранения и метаданные объекта релиза.\n       Релизы также привязаны к namespace пользователя, а не к namespace Tiller\n       (например, namespace Tiller по умолчанию в v2 — kube-system). v2\n       использует \"ConfigMaps\" или \"Secrets\" в namespace Tiller с владельцем\n       `TILLER`. v3 использует \"Secrets\" в namespace пользователя с владельцем\n       `helm`. Релизы инкрементальны как в v2, так и в v3\n     - Единственная проблема может возникнуть, если в чарте определены\n       кластерные ресурсы Kubernetes (например, `clusterroles.rbac`).\n       В этом случае развёртывание v3 завершится ошибкой, даже если ресурс\n       уникален в namespace, поскольку ресурсы будут конфликтовать\n     - Конфигурация v3 больше не использует `$HELM_HOME` и вместо этого\n       использует спецификацию директорий XDG. Она создаётся по мере\n       необходимости и независима от конфигурации v2. Это актуально только\n       при установке обеих версий на одной системе\n\n2. Миграция с Helm v2 на Helm v3:\n   - Этот сценарий применяется, когда вы хотите, чтобы Helm v3 управлял\n     существующими релизами Helm v2\n   - Следует учитывать, что клиент Helm v2:\n     - может управлять от 1 до нескольких кластеров Kubernetes\n     - может подключаться к нескольким экземплярам Tiller в кластере\n   - Это означает, что при миграции нужно учитывать, что релизы развёртываются\n     в кластеры через Tiller и его namespace. Поэтому необходимо выполнять\n     миграцию для каждого кластера и каждого экземпляра Tiller, которыми\n     управляет экземпляр клиента Helm v2\n   - Рекомендуемый путь миграции данных:\n     1. Создайте резервную копию данных v2\n     2. Мигрируйте конфигурацию Helm v2\n     3. Мигрируйте релизы Helm v2\n     4. Когда убедитесь, что Helm v3 управляет всеми данными Helm v2 (для всех\n        кластеров и экземпляров Tiller экземпляра клиента Helm v2) как\n        ожидалось, очистите данные Helm v2\n   - Процесс миграции автоматизирован плагином Helm v3\n     [2to3](https://github.com/helm/helm-2to3)\n\n## Справочные материалы\n\n- Плагин Helm v3 [2to3](https://github.com/helm/helm-2to3)\n- [Статья в блоге](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)\n  с описанием использования плагина `2to3` и примерами\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Политика поддержки версий Helm\"\ndescription: \"Описывает политику патч-релизов Helm, а также максимально допустимое расхождение версий между Helm и Kubernetes.\"\n---\n\nВ этом документе описывается максимально допустимое расхождение версий между Helm и\nKubernetes.\n\n## Поддерживаемые версии\n\nВерсии Helm записываются в формате `x.y.z`, где `x` — мажорная версия, `y` —\nминорная версия, а `z` — патч-версия, в соответствии с терминологией [семантического\nверсионирования](https://semver.org/spec/v2.0.0.html).\n\nПроект Helm поддерживает ветку релиза для последней минорной версии.\nПрименимые исправления, включая исправления безопасности, переносятся в ветку\nрелиза в зависимости от серьёзности и выполнимости. Подробнее см. в\n[политике релизов Helm](/community/release_policy).\n\n## Поддерживаемое расхождение версий\n\nПри выпуске новой версии Helm она компилируется с определённой\nминорной версией Kubernetes. Например, Helm 3.0.0 взаимодействует с Kubernetes\nчерез клиент Kubernetes 1.16.2, поэтому совместим с Kubernetes 1.16.\n\nНачиная с Helm 3, он совместим с версиями Kubernetes `n-3` относительно\nтой версии, с которой был скомпилирован. Для Helm 2 политика поддержки строже\nиз-за различий между минорными версиями Kubernetes — он совместим\nтолько с версиями `n-1`.\n\nНапример, если вы используете версию Helm 3, скомпилированную с клиентскими API\nKubernetes 1.17, то её безопасно использовать с Kubernetes 1.17,\n1.16, 1.15 и 1.14. Если вы используете версию Helm 2, скомпилированную\nс клиентскими API Kubernetes 1.16, то её безопасно использовать с\nKubernetes 1.16 и 1.15.\n\nНе рекомендуется использовать Helm с версией Kubernetes новее той,\nс которой он был скомпилирован, поскольку Helm не гарантирует\nсовместимость с более новыми версиями.\n\nЕсли вы решите использовать Helm с неподдерживаемой версией Kubernetes,\nвы делаете это на свой страх и риск.\n\nИспользуйте таблицу ниже, чтобы определить, какая версия Helm совместима\nс вашим кластером.\n\n| Версия Helm  | Поддерживаемые версии Kubernetes |\n|--------------|----------------------------------|\n| 3.20.x       | 1.35.x - 1.32.x                  |\n| 3.19.x       | 1.34.x - 1.31.x                  |\n| 3.18.x       | 1.33.x - 1.30.x                  |\n| 3.17.x       | 1.32.x - 1.29.x                  |\n| 3.16.x       | 1.31.x - 1.28.x                  |\n| 3.15.x       | 1.30.x - 1.27.x                  |\n| 3.14.x       | 1.29.x - 1.26.x                  |\n| 3.13.x       | 1.28.x - 1.25.x                  |\n| 3.12.x       | 1.27.x - 1.24.x                  |\n| 3.11.x       | 1.26.x - 1.23.x                  |\n| 3.10.x       | 1.25.x - 1.22.x                  |\n| 3.9.x        | 1.24.x - 1.21.x                  |\n| 3.8.x        | 1.23.x - 1.20.x                  |\n| 3.7.x        | 1.22.x - 1.19.x                  |\n| 3.6.x        | 1.21.x - 1.18.x                  |\n| 3.5.x        | 1.20.x - 1.17.x                  |\n| 3.4.x        | 1.19.x - 1.16.x                  |\n| 3.3.x        | 1.18.x - 1.15.x                  |\n| 3.2.x        | 1.18.x - 1.15.x                  |\n| 3.1.x        | 1.17.x - 1.14.x                  |\n| 3.0.x        | 1.16.x - 1.13.x                  |\n| 2.16.x       | 1.16.x - 1.15.x                  |\n| 2.15.x       | 1.15.x - 1.14.x                  |\n| 2.14.x       | 1.14.x - 1.13.x                  |\n| 2.13.x       | 1.13.x - 1.12.x                  |\n| 2.12.x       | 1.12.x - 1.11.x                  |\n| 2.11.x       | 1.11.x - 1.10.x                  |\n| 2.10.x       | 1.10.x - 1.9.x                   |\n| 2.9.x        | 1.10.x - 1.9.x                   |\n| 2.8.x        | 1.9.x - 1.8.x                    |\n| 2.7.x        | 1.8.x - 1.7.x                    |\n| 2.6.x        | 1.7.x - 1.6.x                    |\n| 2.5.x        | 1.6.x - 1.5.x                    |\n| 2.4.x        | 1.6.x - 1.5.x                    |\n| 2.3.x        | 1.5.x - 1.4.x                    |\n| 2.2.x        | 1.5.x - 1.4.x                    |\n| 2.1.x        | 1.5.x - 1.4.x                    |\n| 2.0.x        | 1.4.x - 1.3.x                    |\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"Введение\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"Как делать\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"Темы\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Лучшие практики\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"Руководство по шаблонам чартов\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Команды Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"Сообщество\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"Часто задаваемые вопросы\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/ru/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: \"Политика расписания релизов\"\ndescription: \"Описывает политику расписания релизов Helm.\"\n---\n\nДля удобства пользователей Helm объявляет даты релизов заранее. В этом документе\nописывается политика, определяющая расписание релизов Helm.\n\n## Календарь релизов\n\nПубличный календарь с предстоящими релизами Helm доступен [здесь](https://helm.sh/calendar/release).\n\n## Семантическое версионирование\n\nВерсии Helm записываются в формате `x.y.z`, где `x` — мажорная версия, `y` —\nминорная версия, а `z` — патч-версия, в соответствии с терминологией [семантического\nверсионирования](https://semver.org/spec/v2.0.0.html).\n\n## Патч-релизы\n\nПатч-релизы предоставляют пользователям исправления ошибок и исправления\nбезопасности. Они не содержат новых функций.\n\nНовый патч-релиз для последней минорной/мажорной версии обычно выпускается\nво вторую среду каждого месяца.\n\nПатч-релиз для исправления критической регрессии или проблемы безопасности\nможет быть выпущен в любое время.\n\nПатч-релиз будет отменён по любой из следующих причин:\n- если с момента предыдущего релиза нет новых изменений\n- если дата патч-релиза попадает в период за неделю до первого релиз-кандидата (RC1) предстоящего минорного релиза\n- если дата патч-релиза попадает в период четырёх недель после минорного релиза\n\n## Минорные релизы\n\nМинорные релизы содержат исправления безопасности и ошибок, а также новые функции.\nОни обратно совместимы с точки зрения API и использования CLI.\n\nДля согласования с релизами Kubernetes минорный релиз Helm выпускается каждые\n4 месяца (3 релиза в год).\n\nДополнительные минорные релизы могут быть выпущены при необходимости, но это не\nповлияет на график объявленного будущего релиза, если до объявленного релиза\nне осталось менее 7 дней.\n\nОдновременно с публикацией релиза объявляется дата следующего минорного релиза,\nкоторая размещается на главной странице сайта Helm.\n\n## Мажорные релизы\n\nМажорные релизы содержат изменения, нарушающие обратную совместимость. Такие\nрелизы редки, но иногда необходимы, чтобы позволить Helm развиваться в важных\nновых направлениях.\n\nМажорные релизы сложно планировать. С учётом этого окончательная дата релиза\nбудет выбрана и объявлена только после выхода первой бета-версии такого релиза.\n"
  },
  {
    "path": "i18n/ru/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Проект Helm\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"Разработка\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"Сообщество\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"Исходный код\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"Блог\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"События\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"Кодекс поведения\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"Введение\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Советы и хитрости для чартов\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"Разработка чартов\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"Поиск 800+ чартов\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"Руководство по вкладу\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"Мейнтейнеры\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"Еженедельные встречи\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"Сообщество на GitHub\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<a href=\\\"https://www.cncf.io/\\\">Мы — дипломированный проект Cloud Native Computing Foundation.</a><br/>© Авторы Helm 2025. Документация распространяется под лицензией <a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0.</a><br/>© 2025 The Linux Foundation. Все права защищены. The Linux Foundation имеет зарегистрированные товарные знаки и использует товарные знаки. Для получения списка товарных знаков The Linux Foundation посетите нашу <a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">страницу использования товарных знаков</a>.\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Логотип CNCF\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/ru/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Логотип Helm\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"Документация\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"Блог\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"Сообщество\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/uk/code.json",
    "content": "{\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"Наступний реліз\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"Версія:\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"Дата:\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"Календар релізів\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.events\": {\n    \"message\": \"Події\",\n    \"description\": \"Events section title\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"Майбутні події\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"Майбутні події\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"Минулі події\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"Робоча група SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"Зустрічі робочої групи проходять {meetLink}. На зустрічах відбуваються обговорення та демонстрації інструментів та проєктів. Зустрічі спільноти записуються та {youtubeLink}.\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"щотижня\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"розміщуються на YouTube\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"Зустрічі розробників\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"Четвер 9:30-10am (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"Ці зустрічі відкриті для всіх. Перегляньте {communityRepoLink} для ознайомалення з нотатками зустрічей та отримання докладних відомостей.\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"репозиторій спільноти\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"Обговорення використання Helm, роботи з чартами та вирішення типових помилок.\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"Теми, що стосуються розробки Helm, поточних PR, релізів тощо.\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"Обговорення для користувачів та контрибʼюторів чартів Helm.\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"{slackLink}, щоб приєднатися до команди в Slack Kubernetes.\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"Отримайте доступ тут\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"Участь в проєкті\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"Helm завжди радий вашій допомозі!\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"З чого почати?\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Helm — це великий проєкт з багатьма користувачами та учасниками. Тут багато чого можна дізнатися!\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"У нас є список {goodFirstIssuesLink}, якщо ви хочете допомогти, але не знаєте, з чого розпочати.\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"перших завдань\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"Що мені робити?\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"Перш ніж писати код, будь ласка, прочитайте наші {contributionGuideLink}. Вони описують процеси створення та рецензування пул-реквестів.\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"Настанови щодо участі\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"Після того, як ви напишете код, будь ласка, {signYourCommitsLink}, щоб переконатися, що Helm дотримується угоди {dcoLink}, яка використовується {cncfLink}.\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"підпишіть свої коміти\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"Приєднуйтесь до спільноти\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"Більше інформації про проєкт Helm та про те, як зробити свій внесок.\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.about.whatIsHelm\": {\n    \"message\": \"Helm допомагає керувати застосунками Kubernetes — чарти Helm допомагають визначати, встановлювати та оновлювати навіть найскладніші застосунки Kubernetes.\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"message\": \"Чарти легко створювати, версіонувати, ділитися ними та публікувати — тому почніть використовувати Helm і перестаньте займатися копіюванням та вставкою.\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Helm є дипломованим проєктом {cncfLink}, який підтримується {helmCommunityLink}.\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"спільнотою Helm\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"Дізнайтеся більше:\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Архітектура Helm\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"Швидкий старт\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"Відео: Вступ до Helm\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"Що таке Helm?\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"Керування складністю\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"message\": \"Чарти описують навіть найскладніші застосунки, забезпечують повторюваність встановлення застосунків і слугують єдиним авторитетним джерелом інформації.\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"Прості оновлення\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"Позбудьтеся складнощів оновлення за допомогою оновлень на місці та використання власних хуків.\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"Просте поширення\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"Чарти легко версіонувати, поширювати та розміщувати на публічних або приватних серверах.\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"Відкат змін\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"Використовуйте {helmRollback}, щоб легко повернутися до старішої версії релізу.\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"Функції\",\n    \"description\": \"Features section title\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"Менеджер пакетів для Kubernetes\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Helm — найкращий спосіб знайти, поділитися та використовувати програмне забезпечення, створене для\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"Початок роботи\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"Отримайте Helm!\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"Встановіть Helm за допомогою менеджера пакетів або {downloadLink}.\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"завантажте бінарний файл\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"message\": \"Після встановлення розпакуйте бінарний файл helm, додайте його до вашого PATH — і все готово! Ознайомтесь з {docsLink} для отримання детальної інформації про {installationLink} та {usageLink}.\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"документацією\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"встановлення\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"інструкціями з використання\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"Отримання чартів\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"Відвідайте {artifactHubLink}, щоб ознайомитися з {helmChartsLink} з численних публічних репозиторіїв.\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"чартами Helm\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.support.title\": {\n    \"message\": \"Нас підтримують\",\n    \"description\": \"Community support section title\"\n  },\n  \"home.support.subtitle\": {\n    \"message\": \"Helm підтримується та розвивається спільнотою, що налічує понад 400 розробників.\",\n    \"description\": \"Community support section subtitle\"\n  },\n  \"home.support.maintainers\": {\n    \"message\": \"...та {maintainersLink}.\",\n    \"description\": \"Link to core maintainers\"\n  },\n  \"home.support.maintainersLink\": {\n    \"message\": \"багато інших чудових розробників ядра Helm\",\n    \"description\": \"Core maintainers link text\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"На сторінці стався збій.\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"Архів\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"Архів\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"Прокрутити до початку\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"Навігація по сторінці списку блогів\",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"Наступні дописи\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"Попередні дописи\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"Навігація по сторінці посту блогу\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"Наступний пост\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"Попередній пост\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"Переглянути всі теґи\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"Автоматичний режим\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"Світлий режим\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"Темний режим\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"Перемикання між темним та світлим режимом (зараз використовується {mode})\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"{count} елемент|{count} елементи|{count} елементів\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"Навігаційний ланцюжок поточної сторінки\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"сторінка документації\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"Попередня сторінка\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"Наступна сторінка\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"Одна сторінка|{count} сторінки|{count} сторінок\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged} з теґом \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"Це документація для майбутньої версії {siteTitle} {versionLabel}.\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"Це документація {siteTitle} для версії {versionLabel}, яка вже не підтримується.\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"Актуальна документація знаходиться на сторінці {latestVersionLink} ({versionLabel}).\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"останньої версії\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"Версія: {versionLabel}\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"Редагувати цю сторінку\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \" {date}\",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \" від {user}\",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"Останнє оновлення{atDate}{byUser}\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"Пряме посилання на {heading}\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"Сторінку не знайдено\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"Версії\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"Теґи:\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"обережно\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"небезпека\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"інформація\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"примітка\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"порада\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"попередження\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"Закрити\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"Навігація за останніми постами у блозі\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"Розгорнути категорію в панелі '{label}'\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"Згорнути категорію в панелі '{label}'\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(відкриється в новій вкладці)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"Головна\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"На жаль, ми не змогли знайти сторінку, яку ви запитували.\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"message\": \"Будь ласка, зверніться до власника сайту, з якого ви перейшли за цим посиланням, щоб повідомити, що воно не працює.\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"Мови\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"Зміст цієї сторінки\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"Читати далі\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"Докладніше про {title}\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"{readingTime} хв. читання|{readingTime} хв. читання|{readingTime} хв. читання\",\n    \"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)\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"Копіювати\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"Скопійовано\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"Копіювати в буфер обміну\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"Перенос рядків\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"Головна сторінка\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"Згорнути панель\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"Згорнути панель\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"Панель документації\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"Закрити панель\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"Показати/сховати панель\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← Перейти до головного меню\",\n    \"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)\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"Розгорнути випадаючий список\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"Згорнути випадаючий список\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"Розгорнути панель\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"Розгорнути панель\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"{count} запис|{count} записи|{count} записів\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"{nPosts} з теґом \\\"{tagName}\\\"\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"Автори\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"Переглянути всіх авторів\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"Цей автор ще не написав жодної публікації.\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"Непублічна сторінка\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"message\": \"Ця сторінка є непублічною. Пошукові системи її не індексуватимуть, і доступ до неї матимуть лише користувачі з прямим посиланням.\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"Чернетка\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"Це чернетка. Ця сторінка видима лише в режимі розробки й буде виключена з фінальної збірки.\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"Спробуйте ще раз\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"Перейти до основного вмісту\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"Теґи\",\n    \"description\": \"The title of the tag list page\"\n  }\n}\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-blog/2024-10-07-kubecon-na-24/index.md",
    "content": "---\ntitle: \"Helm на KubeCon/CloudNativeCon SLC\"\nslug: \"kubecon-slc\"\nauthors: [\"mattfarina\"]\ndate: \"2024-11-07\"\n---\n\n![Логотип KubeCon / CloudNativeCon](kubecon.png)\n\nHelm буде присутній на KubeCon / CloudNativeCon North America в Солт-Лейк-Сіті. Щодня під час основної частини конференції відбуватимуться різні події, зокрема:<!-- truncate -->\n\n* Середа:\n  * Присутність на стенді в павільйоні проєктів з 3:15pm до 8pm.\n  * О 7pm MST ми плануємо наживо зробити реліз.\n* Четвер:\n  * Присутність на стенді в павільйоні проєктів з 1:45pm до 5pm.\n  * Сесія: [Contribfest: Helm 4: Наступне покоління менеджера пакетів для Kubernetes](https://kccncna2024.sched.com/event/1howt)\n  * Сесія: [Шлях до Helm 4](https://kccncna2024.sched.com/event/1hoxU)\n* Пʼятниця:\n  * З 12:30pm до 2:30pm у павільйоні проєктів\n\nЯкщо ви хочете поспілкуватися з мейнтейнером, щоб дізнатися більше про Helm або залишити свої відгуки, павільйон проєктів — це ідеальне місце для цього. Якщо вас цікавить Helm v4, сесія \"Шлях до Helm 4\" надасть огляд. А якщо ви хочете зробити свій перший внесок у Helm, сесія Contribfest стане гарним стартом.\n\nЯкщо ви будете в Солт-Лейк-Сіті, сподіваємось побачити вас там.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-blog/2025-09-09-path-to-helm-v4.md",
    "content": "---\ntitle: \"Шлях до випуску Helm v4\"\nslug: \"path-to-helm-v4\"\nauthors: [\"mattfarina\"]\ndate: \"2025-09-09\"\n---\n\nВипущено [першу альфа-версію Helm v4](https://github.com/helm/helm/releases/tag/v4.0.0-alpha.1). Тепер, коли розробка Helm v4 вступає у фінальну стадію, ми хотіли б поділитися деталями про те, що відбувається, і як широкий загал може долучитися до цього процесу.\n<!-- truncate -->\n\n## Альфа-період {#alpha-period}\n\nЗ початком вересня введення нових основних функцій для Helm v4 призупинено. Починається альфа-фаза, під час якої все ще будуть відбуватися зміни, що порушують API, але основна увага приділятиметься стабільності та забезпеченню очікуваної роботи вже внесених змін.\n\nЯкщо ви користуєтеся Helm, протягом цього періоду ви можете протестувати поточні можливості та надати відгук, якщо щось не працює як очікується. Просто памʼятайте, що це програмне забезпечення альфа-якості, і зміни все ще відбуваються.\n\nДля користувачів Helm SDK зараз хороший час, щоб ознайомитися з API і перевірити, чи є якісь занепокоєння щодо змін у дизайні, а також чи вплинуть вони на вашу роботу.\n\nПеріод Альфа триватиме протягом вересня.\n\n## Бета-період {#beta-period}\n\nБета-період розпочинається в жовтні. На цьому етапі основна увага приділяється стабільності в рамках підготовки до випуску. Зміни, що порушують API, повинні бути завершені, і основна увага переходить до виправлення будь-яких помилок, щоб забезпечити стабільний випуск.\n\nТестувальники повинні повідомляти про помилки, коли вони стикаються з будь-якими проблемами.\n\nВідповідно до [політики випуску версій](/community/release_policy#major-releases), після виходу першої бета-версії буде обрано та оголошено остаточну дату випуску версії 4.0.0.\n\n## Претенденти на випуск {#release-candidates}\n\nНаприкінці жовтня буде створено першого претендента на випуск. Він представляє те, що, на нашу думку, буде випущено як Helm v4. Якщо будуть виявлені якісь серйозні проблеми, їх буде виправлено і буде створено нового претендента на випуск.\n\n## 🎉 Випуск 🎉 {#-release-}\n\nВипуск заплановано на KubeCon + CloudNativeCon North America 2025 в середині листопада, що через 6 років після випуску Helm v3 і через 10 років після створення Helm. Більш детальну інформацію про випуск буде надано згодом.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Блог\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"Блог\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"Всі записи\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/_v4-in-progress.mdx",
    "content": ":::warning\nЦю сторінку ще не було оновлено для Helm 4. Деякі відомості можуть бути неточними або не стосуватися Helm 4. Докладнішу інформацію про нові функції, вдосконалення та істотні зміни в Helm 4 див. в [Огляді Helm 4](/overview.md).\n:::\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/changelog.md",
    "content": "---\nsidebar_position: 2\nsidebar_label: Повний список змін\n---\n\n# Helm 4 Повний список змін\n\n**Обсяг**: 290 PR від (`v4.0.0-rc.1`) порівняно з `v3.19.0` <br/>\n**Тільки v4**: 257 PR (33, перенесені до v3, виключені)\n\nДивіться [Огляд](/overview.md) для отримання детального опису цих змін.\n\n## Нові функції {#new-features}\n\nНові функції в Helm 4, які не були перенесені в v3\n\n| PR | Дата | Автор | Назва |\n|---|---|---|---|\n| #31435 | 2025-11-03 | matheuscscp | Introduce a context for canceling wait operations |\n| #31389 | 2025-10-30 | TerryHowe | chore: fix pkg/registry warnings to reduce noise |\n| #31338 | 2025-10-21 | yzewei | Add loongarch64 support |\n| #31351 | 2025-10-21 | gjenkins8 | feat: `helm version` print Kubernetes (client-go) version |\n| #31376 | 2025-10-21 | benoittgt | Do not ignore *.yml file on linting while accepting *.yaml |\n| #31362 | 2025-10-21 | fabiocarneiro | Clarify the intent of the resource instructions |\n| #31392 | 2025-10-16 | TerryHowe | feature: create copilot structured context |\n| #31295 | 2025-10-13 | TerryHowe | Fix make helm list show all by default |\n| #31372 | 2025-10-10 | mattfarina | Enable Releases To Have Multiple Versions |\n| #31254 | 2025-09-23 | benoittgt | Warn when we fallback to a different version on `helm pull` |\n| #31275 | 2025-09-10 | benoittgt | Extend --skip-schema-validation for lint command |\n| #31116 | 2025-09-02 | banjoh | chore: check if go modules are tidy before build |\n| #31217 | 2025-09-01 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Move Postrenderer to a plugin type |\n| #31196 | 2025-08-31 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Remove unnecessary file i/o operations from signing and verifying |\n| #31176 | 2025-08-30 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin packaging, signing, and verification |\n| #31194 | 2025-08-28 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin extism/v1 runtime |\n| #30812 | 2025-08-27 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> HIP-0023: Helm support server-side apply |\n| #31174 | 2025-08-26 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin tarball support for HTTP and local installers |\n| #31172 | 2025-08-26 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin OCI installer |\n| #31146 | 2025-08-23 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin types and plugin apiVersion v1 |\n| #31145 | 2025-08-22 | scottrigby | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Plugin runtime interface |\n| #31142 | 2025-08-21 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> [HIP-0026] Move pkg/plugin -> internal/plugin |\n| #31030 | 2025-08-14 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> HIP-0023: Kube client support server-side apply |\n| #12624 | 2025-08-13 | papdaniel | show crds command output separated by document separator |\n| #13111 | 2025-08-13 | rawtaz | style(pkg/chartutil): add missing dots and indentation to defaultValues |\n| #31076 | 2025-08-11 | matheuscscp | pkg/registry: Login option for passing TLS config in memory |\n| #31034 | 2025-08-05 | Mazafard | Feat: Add color output functionality and tests for release statuses |\n| #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 |\n| #31019 | 2025-07-17 | zachburg | Return early when linting if the `templates/` directory does not exist |\n| #31011 | 2025-07-17 | yalosev | feature: add labels to metadata |\n| #31015 | 2025-07-17 | zachburg | Add linter support for the `crds/` directory |\n| #13154 | 2025-07-10 | carloslima | Allow post-renderer to process hooks |\n| #13586 | 2025-06-04 | jessesimpson36 | feat: add formatting for errors to make multiline stacktraces in helm templates |\n| #30553 | 2025-05-07 | Zhanweelee | feat: Add mustToYaml and mustToJson template functions |\n| #30734 | 2025-04-21 | ipaqsa | feat(pkg/engine): add support for custom template funcs |\n| #13283 | 2025-04-14 | win-t | adding support for JSON Schema 2020 |\n| #30751 | 2025-04-13 | benoittgt | Add detailed debug logging for resource readiness states |\n| #30708 | 2025-04-11 | benoittgt | Migrate pkg to slog |\n| #13604 | 2025-04-05 | AustinAbro321 | Introduce kstatus watcher |\n| #13617 | 2025-02-27 | AustinAbro321 | <span class=\"breaking\">BREAKING CHANGE:</span>  Refactor cmd/helm to allow library usage |\n| #30571 | 2025-02-24 | yardenshoham | feat: error out when post-renderer produces no output |\n| #13655 | 2025-02-20 | LuBingtan | feat: support multi-document values files |\n| #13471 | 2025-02-19 | wangjingcun | Use a more direct and less error-prone return value |\n| #30294 | 2025-02-19 | Zhanweelee | Supports json arguments |\n| #13538 | 2025-01-17 | godhanipayal | Add Contextual Error Messages to RunWithContext |\n| #12588 | 2024-11-22 | rynowak | Make the authorizer and registry authorizer configurable |\n\n## Виправлення помилок {#bug-fixes}\n\nВиправлення в Helm 4, які не були перенесені в v3\n\n| PR | Дата | Автор | Назва |\n|---|---|---|---|\n| #31323 | 2025-10-29 | mattfarina | Reproducible chart archive builds |\n| #31411 | 2025-10-29 | banjoh | fix: reinstate logger parameter to actions package |\n| #31204 | 2025-10-22 | benoittgt | Avoid panic in helm.sh/helm/v3/pkg/chartutil.ValidateAgainstSchema |\n| #31337 | 2025-10-22 | rachelvweber | Fixing rollback and uninstall client WaitStrategy |\n| #31393 | 2025-10-21 | benoittgt | Return errors during upgrade when the deletion of resources fails |\n| #31406 | 2025-10-21 | jessesimpson36 | fix: kube client should return empty results objects instead of nil |\n| #31375 | 2025-10-13 | TerryHowe | fix: release info time parsing |\n| #31349 | 2025-10-07 | TerryHowe | fix: flakey lint test on shuffle |\n| #31327 | 2025-10-07 | TerryHowe | fix: broken `--html` flag to coverage script |\n| #31354 | 2025-10-07 | TerryHowe | fix: flake upgrade test |\n| #31227 | 2025-10-03 | evankanderson | Use filepath.Path when handling directory names |\n| #31307 | 2025-10-02 | TerryHowe | fix: Ignore absolute path when RepoUrl is provided |\n| #31334 | 2025-09-30 | fleaz | Fix typo in bug-report  issue template |\n| #31330 | 2025-09-25 | mattfarina | Restore lint rule for excluding meaningless name |\n| #31320 | 2025-09-25 | kosiew | provenance: allow RSA signing when ed25519 keys are present (switch to ProtonMail/go-crypto) |\n| #31285 | 2025-09-12 | bennsimon | fix: remove leftover debugging line that outputs invalid YAML for helm template command |\n| #31277 | 2025-09-11 | benoittgt | Fix deprecation warning for spf13/pflag from 1.0.7 to 1.0.10 |\n| #31272 | 2025-09-09 | TerryHowe | fix: idea gitignore entry |\n| #31252 | 2025-09-05 | kamilswiec | fix:chartfile tests - semver2 error message |\n| #31199 | 2025-09-05 | TerryHowe | fix: flaky registry data race on mockdns close |\n| #31200 | 2025-09-05 | TerryHowe | fix: installer action goroutine count |\n| #31222 | 2025-09-03 | benoittgt | Prevent failing `helm push` on ghcr.io using standard GET auth token flow |\n| #31191 | 2025-08-26 | TerryHowe | fix: send logging to stderr |\n| #31138 | 2025-08-19 | islewis | fix(helm-lint): Add HTTP/HTTPS URL support for json schema references |\n| #31152 | 2025-08-18 | TerryHowe | fix: enable shuffle in Makefile for unit tests |\n| #12968 | 2025-08-13 | sjeandeaux | helm uninstall dry run support `--ignore-not-found` |\n| #31126 | 2025-08-12 | paologallinaharbur | fix(transport): leverage same tls config |\n| #31109 | 2025-08-06 | carlossg | fix: prevent panic when ChartDownloader.getOciURI |\n| #31074 | 2025-07-18 | joejulian | add missing template directory to badcrdfile testdata |\n| #31042 | 2025-07-10 | TerryHowe | fix: test teardown dns data race |\n| #30898 | 2025-07-06 | AshmitBhardwaj | Fix issue 13198 |\n| #31021 | 2025-07-05 | zachburg | Update tests in create_test.go and package_test.go to work in a temp directory |\n| #31024 | 2025-07-03 | gjenkins8 | fix: 'TestRunLinterRule' stateful test |\n| #30900 | 2025-06-23 | unguiculus | Add timeout flag to repo add and update commands |\n| #30981 | 2025-06-15 | TerryHowe | fix: lint test SetEnv errors |\n| #30973 | 2025-06-12 | manslaughter03 | fix: wrap run release test error in case GetPodLogs failed. |\n| #30972 | 2025-06-10 | TerryHowe | fix: kube client create mutex |\n| #30958 | 2025-06-06 | TerryHowe | fix: repo update cmd mutex |\n| #30955 | 2025-06-04 | carloslima | Fix tests deleting XDG_DATA_HOME |\n| #30939 | 2025-06-03 | TerryHowe | fix: action hooks delete policy mutex |\n| #12581 | 2025-06-03 | MichaelMorrisEst | Consider full GroupVersionKind when matching resources |\n| #30930 | 2025-05-28 | benoittgt | Fix flaky TestFindChartURL due to non-deterministic map iteration |\n| #30884 | 2025-05-21 | mattfarina | Reverting fix \"renders int as float\" |\n| #30862 | 2025-05-20 | OmriSteiner | fix: correctly concat absolute URIs in repo cache |\n| #30864 | 2025-05-16 | jessesimpson36 | fix: remove duplicate error message |\n| #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 |\n| #30800 | 2025-04-25 | mmorel-35 | fix: dep fs errors |\n| #30803 | 2025-04-25 | mattfarina | Fixing windows build |\n| #30783 | 2025-04-23 | rpolishchuk | fix: chart icon presence test |\n| #30777 | 2025-04-23 | ryanhockstad | fix: null merge |\n| #9175 | 2025-04-23 | dastrobu | fix: copy dependencies on aliasing to avoid sharing chart references on multiply aliased dependencies |\n| #12382 | 2025-04-20 | edbmiller | fix(pkg/lint): unmarshals Chart.yaml strictly |\n| #30766 | 2025-04-17 | benoittgt | Fix main branch by defining wait strategy parameter on hooks |\n| #30718 | 2025-04-16 | klihub | Allow signing multiple charts with a single passphrase from stdin. |\n| #30752 | 2025-04-16 | benoittgt | Bump golangci lint to last major version and fix static-check errors |\n| #30737 | 2025-04-11 | rpolishchuk | fix: order dependent test |\n| #9318 | 2025-04-07 | wahabmk | Fix issue with helm pull failing if pulling from a repository that redirects to another domain |\n| #13119 | 2025-04-05 | idsulik | fix(concurrency): Use channel for repoFailList errors in updateCharts |\n| #30618 | 2025-03-04 | AustinAbro321 | Fix namespace flag not registering |\n| #30590 | 2025-03-01 | SantalScript | fix:add proxy support when mTLS configured |\n| #30572 | 2025-02-25 | yardenshoham | fix: error when more than one post-renderer is specified |\n| #30576 | 2025-02-23 | felipecrs | Fix flaky TestDedupeRepos |\n| #30562 | 2025-02-20 | robertsirc | fixing error handling from a previous PR |\n| #13656 | 2025-02-03 | gjenkins8 | fix: Bind repotest server to `localhost` |\n| #13633 | 2025-01-17 | mattfarina | Ensuring the file paths are clean prior to passing to securejoin |\n| #13425 | 2024-11-15 | MathieuCesbron | Fix typo \"re-use\" to \"reuse\" |\n\n## Рефакторинг/Очищення {#refactorcleanup}\n\nПокращення якості коду та модернізація\n\n| PR | Дата | Автор | Назва |\n|---|---|---|---|\n| #31440 | 2025-10-29 | mattfarina | Updating Go and golangci-lint versions |\n| #31408 | 2025-10-21 | AndiDog | Improve error message when plugin source cannot be determined or a non-directory is passed |\n| #31390 | 2025-10-21 | TerryHowe | fix: improve pkg/cmd/list test coverage |\n| #31365 | 2025-10-21 | reddaisyy | refactor: use reflect.TypeFor |\n| #31395 | 2025-10-21 | wyrapeseed | chore: fix some comment format |\n| #31401 | 2025-10-17 | TerryHowe | refactor: remove unused err from pkg/registry/client.go |\n| #31391 | 2025-10-15 | TerryHowe | chore: rename test registry |\n| #31302 | 2025-10-13 | TerryHowe | fix: helm verify Run signature |\n| #31270 | 2025-10-13 | TerryHowe | chore: registry utils clean up |\n| #31383 | 2025-10-13 | dirkmueller | Avoid accessing .Items on nil object |\n| #31379 | 2025-10-13 | TerryHowe | fix: clean up coverage script temp file |\n| #30980 | 2025-10-10 | gjenkins8 | cleanup: Remove/consolidate redundant kube client Interfaces |\n| #30712 | 2025-10-10 | gjenkins8 | cleanup: Remove extra lint/rules.Template functions |\n| #30833 | 2025-10-09 | gjenkins8 | refactor/cleanup: Replace action 'DryRun' string with DryRunStrategy type + deprecations |\n| #31326 | 2025-10-07 | TerryHowe | Update sign tests to use testify |\n| #31312 | 2025-10-01 | gjenkins8 | Remove unused 'Settings' from plugin schema |\n| #31143 | 2025-09-25 | TerryHowe | fix: remove redundant error check |\n| #31249 | 2025-09-25 | banjoh | chore: add additional logging to plugin installer |\n| #31321 | 2025-09-24 | juejinyuxitu | chore: fix some typos in comment |\n| #31297 | 2025-09-22 | TerryHowe | fix: hide notes in helm test command |\n| #31315 | 2025-09-22 | benoittgt | Remove unused golangci-lint rules that produce warning |\n| #31294 | 2025-09-19 | TerryHowe | Remove implicit support for helm lint current directory |\n| #31301 | 2025-09-19 | TerryHowe | chore: remove helm version `--client` option |\n| #31303 | 2025-09-18 | mattfarina | Update the action interfaces for chart apiversions |\n| #31198 | 2025-09-16 | TerryHowe | refactor: replace pkg/engine regular expressions with parser |\n| #31293 | 2025-09-16 | TerryHowe | chore: remove pkg/time which is no longer needed |\n| #31287 | 2025-09-16 | miledxz | improve fileutil test coverage |\n| #31292 | 2025-09-16 | reddaisyy | refactor: use strings.builder |\n| #31286 | 2025-09-12 | yajianggroup | refactor: use strings.CutPrefix |\n| #31258 | 2025-09-08 | StephanieHhnbrg | Refactor unreachableKubeClient for testing into failingKubeClient |\n| #31259 | 2025-09-07 | StephanieHhnbrg | Adapt test-coverage command to be able to run for a certain package |\n| #31225 | 2025-09-02 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move lint pkg to be part of each chart version |\n| #31220 | 2025-09-02 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> refactor: utilize `pluginTypesIndex` for config unmarshalling  |\n| #31219 | 2025-09-02 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove 'SetupPluginEnv' |\n| #31216 | 2025-09-02 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move to versioned packages |\n| #31224 | 2025-09-01 | gjenkins8 | fix: Adjust PostRenderer plugin output to value |\n| #31218 | 2025-09-01 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove legacy Command/Hooks from v1 Subprocess (#23) |\n| #31151 | 2025-08-30 | TerryHowe | fix: make file whitespace |\n| #31178 | 2025-08-28 | mattfarina | Add content cache to helm env |\n| #31165 | 2025-08-22 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Initial addition of content based cache |\n| #13629 | 2025-08-22 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Rename 'atomic' -> 'rollback-on-failure' |\n| #31175 | 2025-08-21 | cuiweixie | pkg/register: refactor to use atomic.Uint64 |\n| #31132 | 2025-08-19 | joemicky | refactor: replace []byte(fmt.Sprintf) with fmt.Appendf  |\n| #31133 | 2025-08-14 | joemicky | refactor: replace HasPrefix+TrimPrefix with CutPrefix |\n| #31134 | 2025-08-14 | joemicky | refactor: omit unnecessary reassignment |\n| #11700 | 2025-08-13 | suzaku | Refactor, use sort.Slice to reduce boilerplate code |\n| #31058 | 2025-08-07 | farazkhawaja | Add test coverage for get_values/metadata.go |\n| #31107 | 2025-08-06 | Pavanipogula | test(pkg/kube): Add unit tests to wait and roundtripper files. |\n| #31106 | 2025-08-05 | irikeish | test(pkg/kube): add test for Client.isReachable |\n| #30982 | 2025-08-05 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Rename 'force' to 'force-replace' |\n| #31094 | 2025-08-04 | mikelolasagasti | chore(deps): remove phayes/freeport module |\n| #31101 | 2025-07-30 | banjoh | feat: switch yaml library to go.yaml.in/yaml/v3 |\n| #31081 | 2025-07-25 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Initial addition of v3 charts |\n| #31079 | 2025-07-22 | gjenkins8 | cleanup: Remove plugin deprecated 'UseTunnelDeprecated' |\n| #31060 | 2025-07-18 | yumeiyin | refactor: replace Split in loops with more efficient SplitSeq |\n| #31065 | 2025-07-15 | TerryHowe | chore: improve OCI debug logging |\n| #31033 | 2025-07-14 | navinag1989 | test: increase test coverage for pkg/cli/options.go file |\n| #31029 | 2025-07-07 | gjenkins8 | chore(refactor): Privatize 'k8sYamlStruct' |\n| #31023 | 2025-07-03 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove deprecated '--create-pods' flag |\n| #31009 | 2025-07-02 | tpresa | test: increase test coverage for pkg/pusher |\n| #31018 | 2025-07-01 | mattfarina | Move logging setup to be configurable |\n| #30909 | 2025-06-03 | jinjiadu | refactor: replace HasPrefix+TrimPrefix with CutPrefix |\n| #30809 | 2025-06-03 | mmorel-35 | chore: enable usetesting linter |\n| #30865 | 2025-05-22 | mmorel-35 | refactor: update json-patch import path and add gomodguard settings |\n| #30871 | 2025-05-20 | gjenkins8 | Run test OCI registry localhost |\n| #30866 | 2025-05-20 | mmorel-35 | chore: enable thelper linter |\n| #30863 | 2025-05-16 | mattfarina | Adding test for list command |\n| #30850 | 2025-05-12 | yetyear | refactor: use maps.Copy for cleaner map handling |\n| #30829 | 2025-05-09 | TerryHowe | Increase pkg/time test coverage |\n| #30810 | 2025-05-08 | mmorel-35 | chore: enable usestdlibvars linter |\n| #30844 | 2025-05-08 | TerryHowe | fix: rename slave replica |\n| #30827 | 2025-05-06 | findnature | refactor: use slices.Contains to simplify code |\n| #13460 | 2025-04-23 | justenstall | fix: replace \"github.com/pkg/errors\" with stdlib \"errors\" package |\n| #30788 | 2025-04-23 | stephenpmurray | ref(helm): Export Chart Not Found error |\n| #30781 | 2025-04-22 | mmorel-35 | chore: remove `github.com/hashicorp/go-multierror` dependency |\n| #13578 | 2025-04-18 | gjenkins8 | refactor: Remove ChartRepository `[]ChartPaths` |\n| #30760 | 2025-04-16 | robertsirc | adding slog debug to a few points |\n| #30713 | 2025-04-11 | gjenkins8 | cleanup: Remove Helm v2 template lint rules |\n| #30749 | 2025-04-11 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Removing the alpine test chart |\n| #30686 | 2025-04-11 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Remove deprecated code |\n| #30736 | 2025-04-09 | robertsirc | manually updating go.mod file |\n| #13458 | 2025-04-05 | thudi | <span class=\"breaking\">BREAKING CHANGE:</span> #13449 Resolves: Replacing NewSimpleClientSet to NewClientSet due to deprecation |\n| #30684 | 2025-03-21 | twz123 | Remove ClientOptResolver from OCI Client |\n| #30603 | 2025-03-21 | robertsirc | converting inline log to slog |\n| #30699 | 2025-03-21 | mattfarina | Error when failed repo update. |\n| #30592 | 2025-02-28 | robertsirc | changing from log to slog |\n| #30589 | 2025-02-26 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move pkg/release to pkg/release/v1 to support v3 charts |\n| #30586 | 2025-02-25 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move pkg/chart to pkg/chart/v2 to prepare for v3 charts |\n| #30585 | 2025-02-25 | robertsirc | removing old apis |\n| #30580 | 2025-02-24 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Move pkg/releaseutil to pkg/release/util |\n| #11112 | 2025-02-22 | felipecrs | perf(dep-up): do not update the same repo multiple times |\n| #30567 | 2025-02-21 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Moving chartutil to chart/util |\n| #30566 | 2025-02-21 | robertsirc | remove unused config.go |\n| #30470 | 2025-02-19 | gjenkins8 | Cleanup `repotest.Server` constructors |\n| #30550 | 2025-02-19 | mattfarina | Moving to SetOut and SetErr for Cobra |\n| #30546 | 2025-02-19 | hugehope | refactor: using slices.Contains to simplify the code |\n| #13535 | 2025-02-05 | gjenkins8 | refactor: tlsutil use options pattern |\n| #13665 | 2025-02-05 | gjenkins8 | chore: Remove unused `WaitAndGetCompletedPodPhase` |\n| #13579 | 2025-02-05 | gjenkins8 | refactor: Remove duplicate `FindChartIn*RepoURL` functions |\n| #13516 | 2025-01-24 | TerryHowe | chore: fix problems with latest lint |\n| #13494 | 2025-01-18 | gjenkins8 | <span class=\"breaking\">BREAKING CHANGE:</span> Remove deprecated `repo add --no-update` flag |\n| #13602 | 2025-01-17 | crystalstall | refactor: using slices.Contains to simplify the code |\n| #13600 | 2025-01-14 | gjenkins8 | cleanup: `NewShowWithConfig` -> `NewShow` |\n| #13601 | 2025-01-09 | gjenkins8 | cleanup: Remove superseded 'lint/rules.Values' function |\n| #13611 | 2025-01-07 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Updating the internal version to v4 |\n| #13576 | 2025-01-07 | gjenkins8 | refactor: Consolidate lint package Run() functions |\n| #13577 | 2025-01-07 | gjenkins8 | refactor: Remove redundant `NewPullWithOpts` |\n| #13599 | 2025-01-07 | gjenkins8 | cleanup: `ProcessDependenciesWithMerge` -> `ProcessDependencies` |\n| #13573 | 2024-12-27 | mattfarina | <span class=\"breaking\">BREAKING CHANGE:</span> Updating to helm.sh/helm/v4 |\n| #13444 | 2024-12-07 | justenstall | refactor(status): remove --show-desc and --show-resources flags |\n\n## Інше {#other}\n\nПокращення інфраструктури та управління проєктом\n\n| PR | Дата | Автор | Назва |\n|---|---|---|---|\n| #31197 | 2025-09-03 | tzchenxixi | chore: fix function name |\n| #31150 | 2025-08-18 | TerryHowe | Feature add stale pr workflow |\n| #31149 | 2025-08-18 | TerryHowe | fix: stale issue workflow |\n| #31077 | 2025-07-21 | gaspergrom | fix: LFX health score badge link |\n| #31047 | 2025-07-10 | jingchanglu | chore: fix typo in pkg/repo/chartrepo.go |\n| #31004 | 2025-06-26 | andreped | fix(docs): Typofix in README |\n| #31002 | 2025-06-26 | curlwget | chore: fix function in comment |\n| #30912 | 2025-06-17 | Bhargavkonidena | Fix #30893 - issue templates |\n| #30957 | 2025-06-04 | acceptacross | chore: fix some function names in comment |\n| #30914 | 2025-05-27 | benoittgt | Fix dependabot upgrade of jsonschema to v6.0.2 |\n| #30904 | 2025-05-23 | benoittgt | [Doc] Help users avoid specifying URL scheme and path with `helm registry` |\n| #30882 | 2025-05-20 | caniszczyk | Add new LFX Insights Health Score Badge |\n| #30872 | 2025-05-20 | benoittgt | Bump golangci-lint version to match last golangci-lint-action |\n| #30824 | 2025-05-05 | adharsh277 | Fix bug in .golangci.yml configuration |\n| #30786 | 2025-04-25 | mmorel-35 | refactor: reorganize .golangci.yml for better clarity and structure |\n| #30785 | 2025-04-23 | mmorel-35 | fix: govulncheck workflow |\n| #30784 | 2025-04-22 | scottrigby | chore(OWNERS): Add TerryHowe as Triage Maintainer |\n| #30773 | 2025-04-18 | wangcundashang | chore: fix function name in comment |\n| #30754 | 2025-04-16 | mattfarina | Simplify the JSON Schema checking |\n| #30693 | 2025-03-20 | linghuying | chore: make function comment match function name |\n| #30665 | 2025-03-13 | mattfarina | Updating to 0.37.0 for x/net |\n| #30611 | 2025-03-04 | gjenkins8 | chore: Remove 'coveralls' |\n| #30612 | 2025-03-04 | gjenkins8 | fix: Fix go report card badge reference/link |\n| #30508 | 2025-02-19 | eimhin-rover | Update version option description with more accurate info |\n| #30497 | 2025-02-12 | robertsirc | adding-my-key |\n| #30295 | 2025-02-07 | edithturn | Add Percona to the list of organizations using Helm |\n| #13653 | 2025-01-23 | petercover | chore: fix some comments |\n| #13625 | 2025-01-13 | shahbazaamir | ading info to install helm , referring the documentation |\n| #13563 | 2024-12-21 | gjenkins8 | Run `build-test` action on `dev-v3` branch |\n| #13552 | 2024-12-20 | gjenkins8 | Fix `dependabot.yml` `target-branch` typo |\n| #13529 | 2024-12-15 | godhanipayal | Adding Oracle to the adopters list |\n| #13509 | 2024-12-06 | gjenkins8 | Dependabot update `dev-v3` branch go modules |\n| #13212 | 2024-12-01 | mbianchidev | Update ADOPTERS.md |\n| #13465 | 2024-11-20 | banjoh | Add precommit config to .gitignore |\n| #13443 | 2024-11-15 | mattfarina | Updating docs around v3 and v4 |\n\n## Зміни v4 також перенесені до v3 {#v4-changes-also-backported-to-v3}\n\nЦі PR були включені до v4, але також перенесені до випусків v3.\n\n### Нові функції {#new-features-backported}\n\n| PR | Дата | Автор | Назва |\n|---|---|---|---|\n| #30696 | 2025-03-24 | benoittgt | Inform about time spent waiting resources to be ready in slog format |\n| #12912 | 2025-03-11 | hegerdes | feat: add httproute from gateway-api to create chart template |\n| #10309 | 2025-02-21 | Bez625 | Add hook annotation to output hook logs to client on error |\n| #13481 | 2025-02-18 | banjoh | feat: Enable CPU and memory profiling |\n| #12690 | 2025-01-01 | TerryHowe | feat: OCI install by digest |\n| #13232 | 2024-12-20 | dnskr | ref(create): don't render empty resource fields |\n| #12962 | 2024-12-04 | stevehipwell | feat: Added multi-platform plugin hook support |\n| #13343 | 2024-11-19 | niladrih | Add annotations and dependencies to get metadata output |\n\n### Виправлення помилок {#bug-fixes-backported}\n\n| PR | Дата | Автор | Назва |\n|---|---|---|---|\n| #31064 | 2025-09-05 | kamilswiec | lint: throw warning when chart version is not semverv2 |\n| #31156 | 2025-08-22 | estroz | fix: set repo authorizer in registry.Client.Resolve() |\n| #30992 | 2025-08-18 | TerryHowe | fix: force bearer oauth for if registry requests bearer auth |\n| #31115 | 2025-08-18 | banjoh | fix: use username and password if provided |\n| #30891 | 2025-08-13 | gjenkins8 | fix: Port pluginCommand & command warning |\n| #31050 | 2025-08-08 | heyLu | Fix `helm pull` untar dir check with repo urls |\n| #31078 | 2025-07-24 | 8tomat8 | fix: k8s version parsing to match original |\n| #30979 | 2025-06-17 | TerryHowe | fix: OAuth username password login for v4 |\n| #30917 | 2025-06-01 | TerryHowe | fix: add debug logging to oci transport |\n| #30937 | 2025-05-30 | TerryHowe | fix: legacy docker support broken for login |\n| #30928 | 2025-05-28 | TerryHowe | fix: plugin installer test with no Internet |\n| #30905 | 2025-05-23 | robertsirc | forward porting 30902 |\n| #30894 | 2025-05-23 | benoittgt | Prevent push cmd failure in 3.18 by handling version tag resolution in ORAS memory store |\n| #30697 | 2025-04-17 | p-se | Fix --take-ownership for custom resources - closes #30622 |\n| #30673 | 2025-04-16 | nvanthao | fix: Process all hook deletions on failure |\n| #30701 | 2025-04-11 | zanuka | updates mutate and validate web hook configs |\n| #13583 | 2025-01-15 | jiashengz | fix: check group for resource info match |\n\n### Рефакторинг/очищення {#refactorcleanup-backported}\n\n| PR | Дата | Автор | Назва |\n|---|---|---|---|\n| #30677 | 2025-04-18 | dongjiang1989 | chore: Update Golang to v1.24 |\n| #30741 | 2025-04-11 | benoittgt | Bumps github.com/distribution/distribution/v3 from 3.0.0-rc.3 to 3.0.0 |\n| #13382 | 2025-02-03 | TerryHowe | chore(oci): migrate to ORAS Golang library v2 |\n| #13546 | 2024-12-19 | mattfarina | Update to Go 1.23 |\n| #13499 | 2024-12-06 | gjenkins8 | Shadow ORAS remote.Client interface |\n\n### Інше {#other-backported}\n\n| PR | Дата | Автор | Назва |\n|---|---|---|---|\n| #30775 | 2025-04-19 | benoittgt | Bump toml |\n| #13533 | 2025-01-24 | althmoha | fix: (toToml) renders int as float |\n| #13581 | 2024-12-31 | ldlb9527 | Upgrade golang.org/x/net to v0.33.0 to address CVE-2024-45338 |\n\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/conventions.md",
    "content": "---\ntitle: Загальні домовленості\ndescription: Загальні домовленості для чартів.\nsidebar_position: 1\n---\n\nЦя частина Посібника з найкращих практик пояснює загальні домовленості.\n\n## Назви чартів {#chart-names}\n\nНазви чартів повинні складатися з літер нижнього регістру та цифр. Слова _можуть_ бути розділені дефісами (-):\n\nПриклади:\n\n```none\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nУ назвах чартів не можна використовувати великі літери та підкреслення. Також не слід використовувати крапки.\n\n## Номери версій {#version-numbers}\n\nПо можливості, Helm використовує [SemVer 2](https://semver.org/lang/uk/) для позначення номерів версій. (Зверніть увагу, що теґи Docker-образів не завжди відповідають SemVer і тому вважаються невдалим винятком з правила.)\n\nКоли версії SemVer зберігаються в мітках Kubernetes, ми умовно змінюємо символ `+` на `_`, оскільки мітки не допускають використання знака `+` як значення.\n\n## Форматування YAML {#formatting-yaml}\n\nФайли YAML повинні використовувати відступи у _два пробіли_ (і ніколи табуляцією).\n\n## Використання слів Helm і Chart {#usage-of-the-words-helm-and-chart}\n\nІснує кілька домовленостей щодо використання слів _Helm_ і _helm_.\n\n- _Helm_ відноситься до проєкту в цілому\n- `helm` відноситься до клієнтської команди\n- Термін `chart` не потрібно писати з великої літери, оскільки це не власна назва\n- Однак `Chart.yaml` необхідно писати з великої літери, оскільки назва файлу чутлива до регістру\n\nУ разі сумніву використовуйте _Helm_ (з великої літери \"H\").\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Custom Resource Definitions\ndescription: Як створювати та використовувати CRDs (Custom Resource Definitions).\nsidebar_position: 7\n---\n\nЦей розділ Посібника з найкращих практик присвячений створенню та використанню обʼєктів Custom Resource Definition.\n\nПри роботі з Custom Resource Definitions (CRDs) важливо розрізняти два різні аспекти:\n\n- Існує декларація CRD. Це YAML файл, який має `kind: CustomResourceDefinition`.\n- Потім є ресурси, які _використовують_ CRD. Наприклад, якщо CRD визначає `foo.example.com/v1`, будь-який ресурс, який має `apiVersion: example.com/v1` і `kind: Foo`, є ресурсом, що використовує цей CRD.\n\n## Встановлення декларації CRD перед використанням ресурсу {#install-a-crd-declaration-before-using-the-resource}\n\nHelm оптимізований для швидкого завантаження якомога більшої кількості ресурсів у Kubernetes. За дизайном Kubernetes може обробити цілий набір маніфестів і активувати їх усі (це називається процедурою узгодження).\n\nАле є різниця з CRDs.\n\nДля CRD декларація повинна бути зареєстрована до того, як будь-які ресурси цього типу CRD можуть бути використані. Процес реєстрації іноді займає кілька секунд.\n\n### Метод 1: Нехай `helm` зробить це за вас {#method-1-let-helm-do-it-for-you}\n\nЗ приходом Helm 3 ми видалили старі `crd-install` хуки на користь простішої методології. Тепер існує спеціальна тека `crds`, яку ви можете створити у вашому чарті для зберігання CRDs. Ці CRDs не підлягають шаблонізації, але будуть стандартно встановлені під час виконання `helm install` для чарту. Якщо CRD вже існує, його буде пропущена з попередженням. Якщо ви бажаєте пропустити крок встановлення CRD, ви можете використовувати прапорець `--skip-crds`.\n\n#### Декілька застережень (і пояснень) {#some-caveats-and-explanations}\n\nЗараз не підтримується оновлення або видалення CRDs за допомогою Helm. Це було зроблено після тривалого обговорення у спільноті через небезпеку випадкової втрати даних. Крім того, наразі немає консенсусу в спільноті щодо того, як управляти CRDs та їх життєвим циклом. Як це буде розвиватися, Helm додасть підтримку для цих випадків.\n\nПрапорець `--dry-run` для `helm install` і `helm upgrade` наразі не підтримується для CRDs. Мета \"Dry Run\" полягає в перевірці того, що вивід чарту дійсно працюватиме, якщо буде надіслано на сервер. Але CRDs є модифікацією поведінки сервера. Helm не може встановити CRD під час тестового запуску, тому клієнт виявлення не дізнається про цей Custom Resource (CR), і перевірка не пройде. Ви можете перемістити CRDs до окремого чарту або використовувати `helm template` замість цього.\n\nЩе один важливий момент, який слід врахувати в обговоренні підтримки CRD, — це те, як обробляється рендеринг шаблонів. Одним з явних недоліків методу `crd-install`, що використовувався в Helm 2, була неспроможність правильно перевіряти чарти через зміну доступності API (CRD фактично додає ще один доступний API до вашого кластера Kubernetes). Якщо чарт встановлював CRD, `helm` більше не мав дійсного набору версій API, з якими можна було працювати. Це також є причиною видалення підтримки шаблонізації для CRDs. З новим методом `crds` для встановлення CRD ми тепер забезпечуємо, що `helm` має абсолютно достовірну інформацію про поточний стан кластера.\n\n### Метод 2: Окремі чарти {#method-2-separate-charts}\n\nЩе один спосіб зробити це — помістити визначення CRD в один чарт, а потім розмістити будь-які ресурси, які використовують цей CRD, в _іншому_ чарті.\n\nВ цьому методі кожен чарт потрібно встановлювати окремо. Однак цей робочий процес може бути більш корисним для адміністраторів кластерів, які мають права адміністратора на кластер.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/dependencies.mdx",
    "content": "---\ntitle: Залежності\ndescription: Охоплює найкращі практики щодо залежностей чартів.\nsidebar_position: 4\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nЦей розділ посібника охоплює найкращі практики для `dependencies`, оголошених у `Chart.yaml`.\n\n## Версії {#versions}\n\nПо можливості використовуйте діапазони версій замість привʼязки до точної версії. Рекомендоване стандартне значення — це використання відповідності на рівні патчу:\n\n```yaml\nversion: ~1.2.3\n```\n\nЦе буде відповідати версії `1.2.3` та будь-яким патчам для цього випуску. Іншими словами, `~1.2.3` є еквівалентом `>= 1.2.3, < 1.3.0`.\n\nДля повної синтаксичної відповідності версій див. [документацію semver](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Передрелізні версії {#prereleases-versions}\n\nВищезазначені обмеження версій не будуть відповідати передрелізним версіям. Наприклад, `version: ~1.2.3` буде відповідати `version: ~1.2.4`, але не `version: ~1.2.3-1`. Нижче наведено приклад передрелізного та патч-рівня відповідності:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### URL-адреси репозиторіїв {#repository-urls}\n\nПо можливості використовуйте URL-адреси репозиторію `https://`, а потім URL-адреси `http://`.\n\nЯкщо репозиторій був доданий до файлу індексу репозиторіїв, імʼя репозиторію може бути використане як псевдонім URL. Використовуйте `alias:` або `@`, за яким слідують імена репозиторіїв.\n\nURL-адреси файлів (`file://...`) вважаються \"особливим випадком\" для чартів, які збираються фіксованим процесом розгортання.\n\nПри використанні [втулків завантажувача](/topics/plugins.mdx#downloader-plugins) схема URL буде специфічною для втулка. Зверніть увагу, що користувачеві чарту буде потрібно мати втулок, що підтримує схему, встановлений для оновлення або побудови залежності.\n\nHelm не може виконувати операції управління залежностями для залежності, коли поле `repository` залишено порожнім. У цьому випадку Helm припускатиме, що залежність знаходиться в підтеці теки `charts` з іменем, яке відповідає властивості `name` для залежності.\n\n## Умови та теґи {#conditions-and-tags}\n\nУмови або теґи слід додавати до будь-яких залежностей, які _є необовʼязковими_.\n\nБажана форма умови є такою:\n\n```yaml\ncondition: somechart.enabled\n```\n\nДе `somechart` є іменем чарту залежності.\n\nКоли кілька субчартів (залежностей) разом забезпечують необовʼязкову або замінну функцію, ці чарт можуть мати спільні теґи.\n\nНаприклад, якщо як `nginx`, так і `memcached` разом забезпечують оптимізації продуктивності для основного застосунку в чарті та вони потрібні, щоб обидва були присутні, коли ця функція увімкнена, то вони повинні мати розділ теґів як цей:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nЦе дозволяє користувачеві вмикати або вимикати цю функцію за допомогою одного теґу.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/index.mdx",
    "content": "---\ntitle: Найкращі практики\nsidebar: true\nsidebar_position: 4\n---\n\n# Поради щодо використання чартів\n\nЦей посібник охоплює найкращі практики створення чартів, які команда Helm вважає оптимальними. Основна увага приділяється структурі чартів.\n\nМи зосереджуємося переважно на найкращих практиках для чартів, які можуть бути публічно розгорнуті. Ми розуміємо, що багато чартів призначені лише для внутрішнього використання, і автори таких чартів можуть вважати, що їхні внутрішні інтереси мають пріоритет над нашими пропозиціями, викладеними тут.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/labels.md",
    "content": "---\ntitle: Мітки та Анотації\ndescription: Охоплює найкращі практики використання міток та анотацій у вашому чарті.\nsidebar_position: 5\n---\n\nУ цій частині Посібника розглядаються найкращі практики використання міток та анотацій у ваших чартах.\n\n## Це мітка чи анотація? {#is-it-a-label-or-an-annotation}\n\nЕлемент метаданих слід вважати міткою за таких умов:\n\n- Він використовується Kubernetes для ідентифікації цього ресурсу\n- Він корисний для експонування операторам з метою запиту системи.\n\nНаприклад, рекомендується використовувати `helm.sh/chart: NAME-VERSION` як мітку, щоб оператори могли зручно знаходити всі екземпляри конкретного чарту.\n\nЯкщо елемент метаданих не використовується для запитів, його слід встановити як анотацію.\n\nHelm hooks завжди є анотаціями.\n\n## Стандартні Мітки {#standard-labels}\n\nНаступна таблиця визначає загальні мітки, які використовуються в Helm чарті. Helm сам по собі ніколи не вимагає наявності конкретної мітки. Мітки, які позначені як REC, є рекомендованими та _повинні_ бути розміщені в чарті для глобальної узгодженості. Ті, що позначені як OPT, є необовʼязковими. Це ідіоматичні або часто використовувані мітки, але не є критично важливими для операційних цілей.\n\nНазва|Статус|Опис\n-----|------|----------\n`app.kubernetes.io/name` | REC | Це повинно бути імʼя застосунку, яке відображає весь застосунок. Зазвичай використовується `{{ template \"name\" . }}`. Це використовується багатьма маніфестами Kubernetes і не є специфічним для Helm.\n`helm.sh/chart` | REC | Це повинно бути імʼя чарту та версія: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`.\n`app.kubernetes.io/managed-by` | REC | Це завжди повинно бути встановлено як `{{ .Release.Service }}`. Це для знаходження всього, що управляється Helm.\n`app.kubernetes.io/instance` | REC | Це повинно бути `{{ .Release.Name }}`. Це допомагає відрізняти різні екземпляри одного й того ж застосунку.\n`app.kubernetes.io/version` | OPT | Версія застосунку і може бути встановлена як `{{ .Chart.AppVersion }}`.\n`app.kubernetes.io/component` | OPT | Це загальна мітка для позначення різних ролей, які елементи можуть відігравати в застосунку. Наприклад, `app.kubernetes.io/component: frontend`.\n`app.kubernetes.io/part-of` | OPT | Коли кілька чартів або програмних частин використовуються разом для створення одного застосунку. Наприклад, програмне забезпечення та база даних для створення вебсайту. Це можна встановити на рівні основного застосунку, що підтримується.\n\nВи можете знайти більше інформації про мітки Kubernetes, що починаються з `app.kubernetes.io`, в [документації Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/pods.md",
    "content": "---\ntitle: Pods та PodTemplates\ndescription: Розглядається форматування частин Pod і PodTemplate в маніфестах чартів.\nsidebar_position: 6\n---\n\nУ цій частині посібника з найкращих практик розглядається форматування частин Pod і PodTemplate у маніфестах чартів.\n\nНаступний (неповний) список ресурсів використовує PodTemplates:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Образи {#images}\n\nОбраз контейнера повинен використовувати фіксований теґ або SHA образу. Він не повинен використовувати теги `latest`, `head`, `canary` або інші теґи, які призначені для \"плаваючих\" версій.\n\nОбрази _можуть_ бути визначені у файлі `values.yaml`, щоб спростити заміну образів.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nОбраз та теґ можуть бути визначені у файлі `values.yaml` як два окремі поля:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` стандартно встановлює `imagePullPolicy` на `IfNotPresent`, роблячи це у вашому `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nА у `values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nАналогічно, Kubernetes стандартно встановлює `imagePullPolicy` на `IfNotPresent`, якщо він зовсім не визначений. Якщо вам потрібне інше значення, просто оновіть його в `values.yaml` на потрібне значення.\n\n## PodTemplates повинні оголошувати селектори {#podtemplates-should-declare-selectors}\n\nУсі розділи PodTemplate повинні містити селектор. Наприклад:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nЦе хороша практика, оскільки вона встановлює звʼязок між набором і podʼом.\n\nАле це ще важливіше для таких наборів, як Deployment. Без цього, _весь_ набір міток використовується для вибору відповідних podʼів, і це може зламатися, якщо ви використовуєте мітки, які змінюються, такі як версія або дата релізу.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/rbac.md",
    "content": "---\ntitle: Role-Based Access Control\ndescription: Розглядається створення та форматування ресурсів RBAC у маніфестах чартів.\nsidebar_position: 8\n---\n\nУ цій частині Посібника з найкращих практик розглядається створення та форматування ресурсів RBAC у маніфестах чартів.\n\nРесурси RBAC це:\n\n- ServiceAccount (обмежений простором імен)\n- Role (обмежений простором імен)\n- ClusterRole\n- RoleBinding (обмежений простором імен)\n- ClusterRoleBinding\n\n## Конфігурація YAML {#yaml-configuration}\n\nКонфігурація RBAC та ServiceAccount повинна здійснюватися під окремими ключами. Це окремі речі. Розділення цих двох концепцій у YAML знімає неоднозначність і робить це яснішим.\n\n```yaml\nrbac:\n  # Вказує, чи повинні бути створені ресурси RBAC\n  create: true\n\nserviceAccount:\n  # Вказує, чи повинен бути створений ServiceAccount\n  create: true\n  # Імʼя ServiceAccount для використання.\n  # Якщо не вказано і create дорівнює true, імʼя генерується за допомогою шаблону fullname\n  name:\n```\n\nЦю структуру можна розширити для комплексних чартів, які потребують кількох ServiceAccount.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## Ресурси RBAC повинні бути стандартно створені {#rbac-resources-should-be-created-by-default}\n\n`rbac.create` має бути булевим значенням, яке контролює, чи створюються ресурси RBAC. Стандартне значення має бути `true`. Користувачі, які бажають самостійно управляти контролем доступу RBAC, можуть встановити це значення в `false` (у цьому випадку дивіться нижче).\n\n## Using RBAC Resources\n\n`serviceAccount.name` має бути встановлено на імʼя ServiceAccount, яке буде використовуватися доступними ресурсами, створеними чартом. Якщо `serviceAccount.create` дорівнює true, то ServiceAccount з цим імʼям має бути створено. Якщо імʼя не вказано, то імʼя генерується за допомогою шаблону `fullname`. Якщо `serviceAccount.create` дорівнює false, то ServiceAccount не створюється, але він має бути асоційований з тими ж ресурсами, щоб пізніше створені вручну ресурси RBAC, що посилаються на нього, функціонували правильно. Якщо `serviceAccount.create` дорівнює false та імʼя не вказано, то використовується стандартний ServiceAccount.\n\nДля ServiceAccount слід використовувати наступний допоміжний шаблон.\n\n```go\n{{/*\nСтворення імені службового облікового запису, який буде використовуватися\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/templates.md",
    "content": "---\ntitle: Шаблони\ndescription: Детальний огляд найкращих практик щодо шаблонів.\nsidebar_position: 3\n---\n\nЦя частина Посібника з найкращих практик присвячена шаблонам.\n\n## Структура `templates/` {#structure-of-templates}\n\nТеку `templates/` слід структурувати наступним чином:\n\n- Файли шаблонів повинні мати розширення `.yaml`, якщо вони генерують YAML-вихід. Розширення `.tpl` можна використовувати для файлів шаблонів, які не генерують форматований контент.\n- Імена файлів шаблонів повинні використовувати дефіси (`my-example-configmap.yaml`), а не camelCase.\n- Кожне визначення ресурсу повинно бути у власному файлі шаблону.\n- Імена файлів шаблонів повинні відображати тип ресурсу в імені. Наприклад, `foo-pod.yaml`, `bar-svc.yaml`.\n\n## Імена визначених шаблонів {#names-of-defined-templates}\n\nВизначені шаблони (шаблони, створені всередині директиви `{{ define }}`) є глобально доступними. Це означає, що чарт і всі його субчарти матимуть доступ до всіх шаблонів, створених з `{{ define }}`.\n\nЗ цієї причини _усі імена визначених шаблонів повинні обмежені простором імен_.\n\nПравильно:\n\n```go\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nНеправильно:\n\n```go\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\n\nРекомендується, щоб нові чарти створювалися за допомогою команди `helm create`, оскільки імена шаблонів автоматично визначаються відповідно до цієї найкращої практики.\n\n## Форматування шаблонів {#formatting-templates}\n\nШаблони повинні мати відступи у _два пробіли_ (ніколи табуляцію).\n\nДирективи шаблону повинні мати пробіл після відкриваючих дужок і перед закриваючими дужками:\n\nПравильно:\n\n```go\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nНеправильно:\n\n```go\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nШаблони повинні обрізати пробіли, де це можливо:\n\n```go\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nБлоки (такі як структури управління) можуть бути з відступами, щоб позначити потік коду шаблону.\n\n```go\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nОднак, оскільки YAML є мовою, орієнтованою на пробіли, часто неможливо, щоб відступи коду слідували цій конвенції.\n\n## Пробіли у згенерованих шаблонах {#whitespace-in-generated-templates}\n\nБажано мінімізувати кількість пробілів у згенерованих шаблонах. Особливо слід уникати численних порожніх рядків, які йдуть один за одним. Але випадкові порожні рядки (особливо між логічними секціями) допустимі.\n\nЦе краще:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nЦе прийнятно:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nАле цього слід уникати:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Коментарі (Коментарі YAML vs. Коментарі шаблонів){#comments-yaml-comments-vs-template-comments}\n\nЯк YAML, так і шаблони Helm мають маркери коментарів.\n\nКоментарі YAML:\n\n```yaml\n# Це коментар\ntype: sprocket\n```\n\nКоментарі шаблонів:\n\n```go\n{{- /*\nЦе коментар.\n*/}}\ntype: frobnitz\n```\n\nКоментарі шаблонів слід використовувати для документування функцій шаблону, наприклад, пояснюючи визначений шаблон:\n\n```go\n{{- /*\nmychart.shortname надає скорочену версію імені релізу до 6 символів.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nВсередині шаблонів коментарі YAML можуть використовуватися, коли це корисно для користувачів Helm (можливо) бачити коментарі під час налагодження.\n\n```yaml\n# Це може спричинити проблеми, якщо значення більше ніж 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nВищенаведений коментар видимий, коли користувач виконує `helm install --debug`, тоді як коментарі, вказані в секціях `{{- /* */}}`, не видно.\n\nОстерігайтеся додавання `#` коментарів YAML у секції шаблону, що містять значення Helm, які можуть бути потрібні для деяких функцій шаблону.\n\nНаприклад, якщо функція `required` вводиться у наведеному вище прикладі, і `maxMem` не встановлено, коментар `#` YAML спричинить помилку рендерингу.\n\nПравильно: `helm template` не рендерить цей блок\n\n```go\n{{- /*\n# Це може спричинити проблеми, якщо значення більше ніж 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nНеправильно: `helm template` повертає `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n\n```yaml\n# Це може спричинити проблеми, якщо значення більше ніж 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nГляньте [Налагодження шаблонів](/chart_template_guide/debugging.md) для іншого прикладу цієї поведінки того, як коментарі YAML залишаються недоторканими.\n\n## Використання JSON у шаблонах і виході шаблонів {#use-of-json-in-templates-and-template-output}\n\nYAML є надмножиною JSON. У деяких випадках використання синтаксису JSON може бути більш читабельним, ніж інші представлення YAML.\n\nНаприклад, цей YAML ближчий до звичайного методу представлення списків у YAML:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nАле його легше читати, коли його стисло представлено у стилі списку JSON:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nВикористання JSON для підвищення читабельності є корисним. Однак синтаксис JSON не слід використовувати для представлення cкладніших конструкцій.\n\nПри роботі з чистим JSON, вбудованим всередині YAML (наприклад, конфігурація контейнера ініціалізації), звичайно, доречно використовувати формат JSON.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/values.md",
    "content": "---\ntitle: Значення\ndescription: Орієнтовано на те, як ви повинні структурувати та використовувати значення.\nsidebar_position: 2\n---\n\nЦя частина посібника з найкращих практик охоплює використання значень. Ми надаємо рекомендації щодо структурування та використання значень, зосереджуючись на дизайні файлу `values.yaml` чарту.\n\n## Домовленості щодо назв {#naming-conventions}\n\nНазви змінних повинні починатися з малої літери, а слова мають поєднуватись верблюжим регістром (camelCase):\n\nПравильно:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nНеправильно:\n\n```yaml\nChicken: true  # початкова велика літера може конфліктувати з вбудованими змінними\nchicken-noodle-soup: true # не використовуйте дефіси в назвах\n```\n\nЗверніть увагу, що всі вбудовані змінні Helm починаються з великої літери, щоб їх легко було відрізнити від користувацьких значень: `.Release.Name`, `.Capabilities.KubeVersion`.\n\n## Пласкі або вкладені значення {#flat-or-nested-values}\n\nYAML — це гнучкий формат, і значення можуть бути вкладеними або пласкими.\n\nВкладені:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nПласкі:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nУ більшості випадків слід віддавати перевагу пласким структурам над вкладеними. Це зумовлено тим, що їх простіше використовувати розробникам шаблонів та користувачам.\n\nДля забезпечення максимальної безпеки вкладене значення має перевірятися на кожному рівні:\n\n```go\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nДля кожного шару вкладення необхідно виконувати перевірку на наявність. Однак для пласкої конфігурації такі перевірки можна пропустити, що спрощує читання та використання шаблону.\n\n```go\n{{ default \"none\" .Values.serverName }}\n```\n\nКоли існує велика кількість пов’язаних змінних і хоча б одна з них є обов’язковою, вкладені значення можуть використовуватися для підвищення зручності читання.\n\n## Чітке визначення типів {#make-types-clear}\n\nПравила перетворення типів YAML іноді можуть бути неінтуїтивними. Наприклад, `foo: false` не те саме, що і `foo: \"false\"`. Великі цілі числа, такі як `foo: 12345678`, у деяких випадках будуть перетворюватися на наукову нотацію.\n\nНайпростіший спосіб уникнути помилок перетворення типів — бути явним щодо рядків і неявним щодо всього іншого. Або, коротко кажучи, _беріть всі рядки в лапки_.\n\nЧасто для уникнення проблем із перетворенням чисел наукової нотації вигідно зберігати ваші цілі числа у вигляді рядків і використовувати `{{ int $value }}` у шаблоні для перетворення з рядкового значення назад на ціле число.\n\nУ більшості випадків явні типи поважаються, тому `foo: !!string 1234` має обробляти `1234` як рядок. _Проте_ парсер YAML споживає теґи, тому дані про типи втрачаються після одного аналізу.\n\n## Враховуйте, як користувачі будуть використовувати ваші значення {#consider-how-users-will-use-your-values}\n\nІснує три потенційні джерела значень:\n\n- Файл `values.yaml` чарту\n- Файл значень, переданий за допомогою `helm install -f` або `helm upgrade -f`\n- Значення, передані з прапорцем `--set` або `--set-string` під час `helm install` або `helm upgrade`\n\nПри проєктуванні структури ваших значень майте на увазі, що користувачі вашого чарту можуть захотіти перевизначити їх за допомогою прапорця `-f` або опції `--set`.\n\nОскільки `--set` більш обмежений у виразності, перше правило написання файлу `values.yaml` — _зробіть його зручним для перевизначення за допомогою `--set`_.\n\nЗ цієї причини часто краще структурувати файл значень, використовуючи map.\n\nВажко використовувати з `--set`:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nВищезазначене не можна виразити за допомогою `--set` у Helm `<=2.4`. У Helm 2.5 доступ до порту на foo здійснюється за допомогою `--set servers[0].port=80`. Це не тільки ускладнює розуміння для користувача, але й може призвести до помилок, якщо пізніше порядок `servers` буде змінено.\n\nЛегше використовувати:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nОтримання доступу до порту foo стає набагато очевиднішим: `--set servers.foo.port=80`.\n\n## Документуйте `values.yaml` {#document-valuesyaml}\n\nКожна визначена властивість у `values.yaml` повинна бути задокументована. Рядок документації повинен починатися з назви властивості, яку він описує, а потім надавати принаймні одне речення опису.\n\nНеправильно:\n\n```yaml\n# назва хосту для вебсервера\nserverHost: example\nserverPort: 9191\n```\n\nПравильно:\n\n```yaml\n# serverHost - це назва хосту для вебсервера\nserverHost: example\n# serverPort - це порт HTTP-сервера для вебсервера\nserverPort: 9191\n```\n\nПочаток кожного коментаря з назви параметра, який він документує, дозволяє легко знаходити документацію та дозволяє інструментам документації надійно співвідносити рядки документації з параметрами, які вони описують.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Доступ до файлів всередині шаблонів\ndescription: Як отримати доступ до файлів зсередини шаблону.\nsidebar_position: 10\n---\n\nУ попередньому розділі ми розглянули кілька способів створення та доступу до іменованих шаблонів. Це полегшує імпорт одного шаблону в інший шаблон. Але іноді корисно імплементувати _файл, який не є шаблоном_ і вбудувати його вміст без використання рендерера шаблонів.\n\nHelm надає доступ до файлів через обʼєкт `.Files`. Перш ніж переходити до прикладів шаблонів, є кілька моментів, які слід врахувати:\n\n- Можна додавати додаткові файли до вашого Helm чарту. Ці файли будуть упаковані. Але будьте обережні. Чарти мають бути меншими за 1М через обмеження зберігання обʼєктів Kubernetes.\n- Деякі файли не можна отримати через обʼєкт `.Files`, зазвичай з міркувань безпеки.\n  - Файли в `templates/` не можна отримати.\n  - Файли, виключені за допомогою `.helmignore`, не можна отримати.\n  - Файли поза межами [субчартів](/chart_template_guide/subcharts_and_globals.md) застосунків, включаючи файли батьківського чарту, не можна отримати.\n- Чарти не зберігають інформацію про режим UNIX, тому дозволи на рівні файлу не вплинуть на доступність файлу в обʼєкті `.Files`.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Базовий приклад](#basic-example)\n- [Помічники оброки шляхів](#path-helpers)\n- [Шаблони Glob](#glob-patterns)\n- [Утиліти для ConfigMap і Secrets](#configmap-and-secrets-utility-functions)\n- [Кодування](#encoding)\n- [Рядки](#lines)\n\n<!-- tocstop -->\n\n## Базовий приклад {#basic-example}\n\nЗ урахуванням цих застережень, створимо шаблон, який читає три файли в наш ConfigMap. Для початку додамо три файли до чарту, розміщуючи всі три безпосередньо в теці `mychart/`.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nКожен з цих файлів є простим TOML-файлом (згадайте про старі INI-файли Windows). Ми знаємо імена цих файлів, тому можемо використовувати функцію `range`, щоб перебрати їх і вставити їх вміст у наш ConfigMap.\n\n```go\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nЦей ConfigMap використовує кілька технік, обговорених у попередніх розділах. Наприклад, ми створюємо змінну `$files`, щоб зберегти посилання на обʼєкт `.Files`. Ми також використовуємо функцію `tuple`, щоб створити список файлів, які ми перебираємо. Потім ми виводимо кожне імʼя файлу (`{{ . }}: |-`) після чого йде вміст файлу `{{ $files.Get . }}`.\n\nЗапуск цього шаблону створить один ConfigMap з вмістом усіх трьох файлів:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Помічники оброки шляхів {#path-helpers}\n\nПри роботі з файлами може бути дуже корисно виконувати деякі стандартні операції з самими шляхами файлів. Для цього Helm імплементує багато функцій з пакета Go [path](https://golang.org/pkg/path/). Вони всі доступні з такими ж іменами, як у пакеті Go, але з маленькою першою літерою. Наприклад, `Base` стає `base` і т.д.\n\nІмпортовані функції:\n\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Шаблони glob {#glob-patterns}\n\nКоли ваш чарт зростає, ви можете знайти необхідність організувати ваші файли більше, і тому ми надаємо метод `Files.Glob(pattern string)` для допомоги у витягуванні певних файлів з усією гнучкістю [шаблонів glob](https://godoc.org/github.com/gobwas/glob).\n\n`.Glob` повертає тип `Files`, тому ви можете викликати будь-які методи `Files` на повернутому обʼєкті.\n\nНаприклад, уявіть структуру директорій:\n\n```none\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nУ вас є кілька варіантів з Globs:\n\n```go\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nабо\n\n```go\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## Утиліти для ConfigMap і Secrets {#configmap-and-secrets-utility-functions}\n\n(Доступні з Helm 2.0.2 і далі)\n\nДуже часто потрібно помістити вміст файлів як у ConfigMaps, так і в Secrets, для монтування в ваші podʼи під час виконання. Для цього ми надаємо кілька методів утиліт для типу `Files`.\n\nДля подальшої організації особливо корисно використовувати ці методи разом з методом `Glob`.\n\nЗадана структура теки з прикладу [Glob](#glob-patterns):\n\n```go\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Кодування {#encoding}\n\nВи можете імплементувати файл і змусити шаблон закодувати його в base-64, щоб забезпечити успішну передачу:\n\n```go\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nВищенаведене візьме той самий файл `config1.toml`, який ми використовували раніше, і закодує його:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Рядки {#lines}\n\nІноді потрібно отримати доступ до кожного рядка файлу у вашому шаблоні. Ми надаємо зручний метод `Lines` для цього.\n\nВи можете перебрати `Lines`, використовуючи функцію `range`:\n\n```go\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nНемає можливості передавати файли, що знаходяться поза чартом, під час `helm install`. Тому, якщо ви просите користувачів надати дані, їх потрібно завантажити за допомогою `helm install -f` або `helm install --set`.\n\nЦе опис завершує наше занурення в інструменти та техніки написання шаблонів Helm. У наступному розділі ми побачимо, як можна використовувати один спеціальний файл, `templates/NOTES.txt`, для надсилання інструкцій після установки користувачам вашого чарту.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Вбудовані обʼєкти\ndescription: Вбудовані обʼєкти, доступні для шаблонів.\nsidebar_position: 3\n---\n\nОбʼєкти передаються в шаблон з рушія обробки шаблонів. І ваш код може передавати обʼєкти далі (ми побачимо приклади, коли розглянемо оператори `with` та `range`). Є навіть кілька способів створити нові обʼєкти всередині ваших шаблонів, як, наприклад, з функцією `tuple`, яку ми розглянемо пізніше.\n\nОбʼєкти можуть бути простими та мати лише одне значення. Або вони можуть містити інші обʼєкти чи функції. Наприклад, обʼєкт `Release` містить кілька обʼєктів (наприклад, `Release.Name`), а обʼєкт `Files` має кілька функцій.\n\nУ попередньому розділі ми використовували `{{ .Release.Name }}`, щоб вставити імʼя релізу в шаблон. `Release` — один з обʼєктів верхнього рівня, до якого ви можете отримати доступ у своїх шаблонах.\n\n- `Release`: Цей обʼєкт описує сам реліз. Він містить кілька обʼєктів:\n  - `Release.Name`: Імʼя релізу\n  - `Release.Namespace`: Простір імен, у який буде здійснено реліз (якщо маніфест не перевизначить)\n  - `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом.\n  - `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням.\n  - `Release.Revision`: Номер ревізії для цього релізу. Під час встановлення це 1, і він збільшується з кожним оновленням або відкатом.\n  - `Release.Service`: Сервіс, який обробляє поточний шаблон. У Helm це завжди `Helm`.\n- `Values`: Значення, передані в шаблон з файлу `values.yaml` і з файлів, наданих користувачем. Стандартно `Values` порожній.\n- `Chart`: Вміст файлу `Chart.yaml`. Будь-які дані в `Chart.yaml` будуть доступні тут. Наприклад, `{{ .Chart.Name }}-{{ .Chart.Version }}` виведе `mychart-0.1.0`.\n  - Доступні поля перелічені в [Посібнику чартів](/topics/charts.mdx#the-chartyaml-file)\n- `Subcharts`: Надає доступ до області дії (.Values, .Charts, .Releases тощо) субшаблонів з батьківського шаблону. Наприклад, `.Subcharts.mySubChart.myValue`, щоб отримати доступ до `myValue` у шаблоні `mySubChart`.\n- `Files`: Надає доступ до всіх не-спеціальних файлів у шаблоні. Ви не можете використовувати його для доступу до шаблонів, але можете використовувати його для доступу до інших файлів у шаблоні. Див. розділ [Доступ до файлів](/chart_template_guide/accessing_files.md) для отримання додаткової інформації.\n  - `Files.Get` — це функція для отримання файлу за іменем (`.Files.Get config.ini`).\n  - `Files.GetBytes` — це функція для отримання вмісту файлу у вигляді масиву байтів, а не рядка. Це корисно для таких речей, як образи.\n  - `Files.Glob` — це функція, яка повертає список файлів, імена яких відповідають заданому шаблону оболонки.\n  - `Files.Lines` — це функція, яка зчитує файл рядок за рядком. Це корисно для ітерації по кожному рядку у файлі.\n  - `Files.AsSecrets` — це функція, яка повертає вміст файлів у вигляді Base64-кодованих рядків.\n  - `Files.AsConfig` — це функція, яка повертає вміст файлів у вигляді YAML map.\n- `Capabilities`: Надає інформацію про можливості, які підтримує кластер Kubernetes.\n  - `Capabilities.APIVersions` — це набір версій.\n  - `Capabilities.APIVersions.Has $version` вказує на те, чи доступна версія (наприклад, `batch/v1`) або ресурс (наприклад, `apps/v1/Deployment`) у кластері.\n  - `Capabilities.KubeVersion` і `Capabilities.KubeVersion.Version` — це версія Kubernetes.\n  - `Capabilities.KubeVersion.Major` — це основна версія Kubernetes.\n  - `Capabilities.KubeVersion.Minor` — це мінорна версія Kubernetes.\n  - `Capabilities.HelmVersion` — це обʼєкт, який містить деталі версії Helm, це той самий вивід, що і `helm version`.\n  - `Capabilities.HelmVersion.Version` — це поточна версія Helm у форматі semver.\n  - `Capabilities.HelmVersion.GitCommit` — це Git-ідентифікатор SHA1 для Helm.\n  - `Capabilities.HelmVersion.GitTreeState` — це стан дерева git для Helm.\n  - `Capabilities.HelmVersion.GoVersion` — це версія компілятора Go, який використовувався.\n- `Template`: Містить інформацію про поточний шаблон, який виконується.\n  - `Template.Name`: Шлях до файлу поточного шаблону з простору імен (наприклад, `mychart/templates/mytemplate.yaml`)\n  - `Template.BasePath`: Шлях до теки шаблонів поточного чарта з простору імен (наприклад, `mychart/templates`).\n\nВбудовані значення завжди починаються з великої літери. Це відповідає угоді про найменування у Go. Коли ви створюєте власні імена, ви можете використовувати угоду, яка підходить вашій команді. Деякі команди, як і багато тих, чиї шаблони ви можете бачити на [Artifact Hub](https://artifacthub.io/packages/search?kind=0), обирають використовувати лише початкові малі літери, щоб відрізнити локальні імена від вбудованих. У цьому посібнику ми дотримуємося цієї угоди.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Керування потоком\ndescription: Швидкий огляд структури керування потоком в шаблонах.\nsidebar_position: 7\n---\n\nСтруктури керування (називаються \"діями\" (actions) в термінології шаблонів) надають вам, автору шаблонів, можливість контролювати потік генерації шаблону. Мова шаблонів Helm надає такі структури керування:\n\n- `if`/`else` для створення умовних блоків\n- `with` для визначення області видимості\n- `range`, який надає цикл \"for each\"\n\nОкрім цих, є кілька дій для оголошення та використання іменованих сегментів шаблону:\n\n- `define` оголошує новий іменований шаблон всередині вашого шаблону\n- `template` імплементує іменований шаблон\n- `block` оголошує спеціальний тип заповнювальної області шаблону\n\nУ цьому розділі ми розглянемо `if`, `with` та `range`. Інші дії будуть розглянуті в розділі \"Іменовані шаблони\" пізніше в цьому посібнику.\n\n## If/Else\n\nПерша структура керування, яку ми розглянемо, використовується для умовного включення блоків тексту в шаблоні. Це блоки `if`/`else`.\n\nОсновна структура блоку з умовою виглядає так:\n\n```go\n{{ if PIPELINE }}\n  # Щось зробити\n{{ else if OTHER PIPELINE }}\n  # Зробити щось інше\n{{ else }}\n  # Стандартне значення\n{{ end }}\n```\n\nЗверніть увагу, що зараз ми говоримо про _конвеєри_, а не про значення. Причина цього полягає в тому, щоб чітко показати, що структури управління можуть виконувати весь конвеєр, а не тільки обчислювати значення.\n\nКонвеєр вважається _false_, якщо значення є:\n\n- логічне значення false\n- числове значення нуль\n- порожній рядок\n- значення `nil` (порожнє або null)\n- порожня колекція (`map`, `slice`, `tuple`, `dict`, `array`)\n\nУ всіх інших умовах умова є істинною.\n\nДодамо просту умовну конструкцію до нашого ConfigMap. Ми додамо ще одне налаштування, якщо напій встановлений на каву:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nОскільки ми закоментували `drink: coffee` у нашому останньому прикладі, вихідний файл не повинен містити прапорець `mug: \"true\"`. Але якщо ми додамо цей рядок назад у наш файл `values.yaml`, вихід виглядатиме так:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Контроль пробілів {#controlling-whitespace}\n\nПід час роботи з умовами варто звернути увагу на те, як контролюється кількість пробілів у шаблонах. Розглянемо попередній приклад і відформатуємо його для зручнішого читання:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nСпочатку це має гарний вигляд. Але якщо ми пропустимо його через рушій шаблонів, отримаємо неприємний результат:\n\n```sh\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nЩо сталося? Ми створили некоректний YAML через пробіли, зазначені вище.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` має невірний відступ. Виправимо це, зменшивши відступ цього рядка, і запустимо знову:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nКоли ми запустимо це, отримаємо валідний YAML, але з кількома порожніми рядками:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nПомітно, що у нас є кілька пустих рядків у YAML. Чому? Коли рушій шаблонів виконує шаблон, він _видаляє_ вміст всередині `{{` і `}}`, але залишає пробіли без змін.\n\nYAML надає значення пробілам, тому управління пробілами стає важливим. На щастя, шаблони Helm мають кілька інструментів у поміч.\n\nПо-перше, синтаксис фігурних дужок шаблонів можна модифікувати за допомогою спеціальних символів, щоб вказати рушію шаблонів обрізати пробіли. `{{- ` (з тире і пробілом) вказує, що пробіли зліва повинні бути видалені, тоді як ` -}}` означає, що пробіли справа повинні бути видалені. _Будьте обережні! Нові рядки — це пробіли!_\n\n> Переконайтеся, що є пробіл між `-` і рештою вашої директиви. `{{- 3 }}` означає \"вирізати ліві пробіли та вивести 3\", тоді як `{{-3 }}` означає \"вивести -3\".\n\nВикористовуючи цей синтаксис, ми можемо змінити наш шаблон, щоб позбутися від тих нових рядків:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nЩоб прояснити це, відзначимо кожен пробіл, який буде видалено відповідно до цього правила. `*` в кінці рядка вказує на символ нового рядка, який буде видалений:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nЗважаючи на це, ми можемо запустити наш шаблон через Helm і побачити результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nБудьте обережні з модифікаторами обрізання пробілів. Легко випадково зробити ось так:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nЦе створить `food: \"PIZZA\"mug: \"true\"`, оскільки пробіли з обох сторін будуть видалені.\n\n> Для деталей про контроль пробілів у шаблонах дивіться [Офіційну документацію Go шаблонів](https://godoc.org/text/template)\n\nНарешті, іноді легше сказати системі шаблонів, як вам потрібно робити відступи, замість того, щоб намагатися освоїти розташування пробілів у директивах шаблону. З цієї причини іноді корисно використовувати функцію `indent` (`{{ indent 2 \"mug:true\" }}`).\n\n## Модифікація області видимості за допомогою `with` {#modifying-scope-using-with}\n\nНаступна структура управління, яку розглянемо, це дія `with`. Вона контролює область видимості змінних. Нагадаємо, що `.` є посиланням на _поточну область видимості_. Отже, `.Values` вказує шаблону знайти обʼєкт `Values` у поточній області видимості.\n\nСинтаксис для `with` схожий на простий оператор `if`:\n\n```go\n{{ with PIPELINE }}\n  # обмежена область видимості\n{{ end }}\n```\n\nОбласті видимості можуть змінюватися. `with` дозволяє вам встановити поточну область видимості (`.`) на певний обʼєкт. Наприклад, ми працювали з `.Values.favorite`. Перепишемо наш ConfigMap, щоб змінити область видимості `.` на `.Values.favorite`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nЗверніть увагу, що ми видалили умову `if` з попереднього прикладу, оскільки вона тепер непотрібна — блок після `with` виконується лише якщо значення `PIPELINE` не є порожнім.\n\nТепер ми можемо звертатися до `.drink` і `.food` без додаткових уточнень. Це відбувається тому, що оператор `with` встановлює `.` на `.Values.favorite`. `.` скидається до попередньої області видимості після `{{ end }}`.\n\nАле є одне застереження! Усередині обмеженої області видимості ви не зможете отримати доступ до інших обʼєктів з батьківської області видимості за допомогою `.`. Наприклад, це не спрацює:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nЦе викличе помилку, оскільки `Release.Name` не знаходиться в межах обмеженої області видимості для `.`. Однак, якщо ми поміняємо місцями останні два рядки, все працюватиме як очікувалося, тому що область видимості скидається після `{{ end }}`.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nАбо ми можемо використовувати `$` для доступу до обʼєкта `Release.Name` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nПісля розгляду `range` ми перейдемо до змінних шаблону, які пропонують одне рішення для проблеми з областю видимості вище.\n\n## Цикли за допомогою дії `range` {#looping-with-the-range-action}\n\nБагато мов програмування підтримують цикли за допомогою `for` циклів, `foreach` циклів або подібних функціональних механізмів. У мові шаблонів Helm, для перебору колекції використовується оператор `range`.\n\nСпочатку додамо список інгредієнтів для піци до нашого файлу `values.yaml`:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nТепер у нас є список (в шаблонах він називається `slice`) інгредієнтів для піци. Ми можемо змінити наш шаблон, щоб вивести цей список у наш ConfigMap:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nМи можемо використовувати `$` для доступу до списку `Values.pizzaToppings` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nРозглянемо детальніше список `toppings:`. Функція `range` буде \"перебирати\" список `pizzaToppings`. Але тепер відбувається щось цікаве. Так само як `with` встановлює область видимості для `.`, так і оператор `range` встановлює область видимості. Кожного разу під час циклу `.` встановлюється на поточний інгредієнт для піци. Тобто, під час першої ітерації `.` буде дорівнювати `mushrooms`. Під час другої ітерації він буде дорівнювати `cheese`, і так далі.\n\nМи можемо безпосередньо передавати значення `.` в конвеєр, тому коли ми використовуємо `{{ . | title | quote }}`, воно передається в `title` (функцію для перетворення на заголовні літери) і потім в `quote`. Якщо ми запустимо цей шаблон, результат буде:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nУ цьому прикладі ми зробили дещо хитре. Лінія `toppings: |-` оголошує багаторядковий рядок. Отже, наш список інгредієнтів для піци насправді не є YAML списком. Це великий рядок. Чому ми так робимо? Тому що дані в ConfigMaps `data` складаються з пар ключ/значення, де і ключ, і значення є простими рядками. Щоб зрозуміти, чому це так, ознайомтеся з [документацією Kubernetes ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/). Для нас цей нюанс не так важливий.\n\n> Маркер `|-` в YAML приймає багаторядковий рядок. Це може бути корисною технікою для вбудовування великих блоків даних у ваші маніфести, як показано тут.\n\nІноді корисно швидко створити список у шаблоні, а потім перебирати цей список. Шаблони Helm мають функцію для спрощення цього завдання: `tuple`. У компʼютерних науках кортеж (tuple) — це список фіксованого розміру, але з довільними типами даних. Це приблизно передає те, як використовується `tuple`.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nThe above will produce this:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nОкрім списків і кортежів, `range` можна використовувати для перебору колекцій, які мають ключ і значення (як `map` або `dict`). Ми розглянемо, як це зробити в наступному розділі, коли введемо змінні шаблону.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Додаток: Типи даних Go та шаблони\"\ndescription: Короткий огляд змінних у шаблонах.\nsidebar_position: 16\n---\n\nМова шаблонів Helm реалізована мовою програмування Go, яка має сувору типізацію. З цієї причини змінні в шаблонах мають _типи_. Здебільшого змінні будуть представлені одним із наступних типів:\n\n- `string`: Рядок тексту\n- `bool`: значення `true` або `false`\n- `int`: Ціле число (існують також 8, 16, 32 і 64-бітні знакові та беззнакові варіанти)\n- `float64`: 64-бітне число з плаваючою комою (також є 8, 16 та 32-бітні різновиди)\n- `byte slice` (`[]byte`): Масив байтів, часто використовується для зберігання (потенційно) бінарних даних\n- `struct`: Обʼєкт із властивостями та методами\n- `slice`: (індексований список) одного з попередніх типів\n- `map`: словник з ключами-рядками (`map[string]interface{}`), де значенням є один із попередніх типів\n\nУ Go існує багато інших типів, і іноді вам доведеться виконувати перетворення між ними у своїх шаблонах. Найпростіший спосіб налагодження типу обʼєкта — це передати його через `printf \"%T\"` у шаблоні, що виведе тип на екран. Дивіться також функції `typeOf` та `kindOf`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/debugging.md",
    "content": "---\ntitle: Виправлення помилок у шаблонах\ndescription: Виправлення проблем з розгортанням чартів.\nsidebar_position: 13\n---\n\nВідлагодження шаблонів може бути складним, оскільки відрендерений шаблон надсилається на сервер API Kubernetes, який може відхилити файли YAML з причин, не повʼязаних із форматуванням.\n\nІснує кілька команд, які можуть допомогти у відлагодженні.\n\n- `helm lint` — це ваш основний інструмент для перевірки того, чи відповідає ваш чарт найкращим\nпрактикам\n- `helm template --debug` перевірить рендеринг шаблонів чартів локально.\n- `helm install --dry-run --debug` також візуалізує чарт локально без його встановлення, але також перевірить, чи конфліктують ресурси з іншими, що вже працюють у кластері. Встановлення `--dry-run=server` додатково виконає будь-який\n`lookup` у чарті щодо сервера.\n- `helm get manifest`: це хороший спосіб перевірити, які шаблони встановлені на сервері.\n\nКоли ваш YAML не проходить перевірку, але ви хочете побачити, що було згенеровано, простий спосіб отримати YAML — закоментувати проблемний розділ у шаблоні, а потім повторно запустити `helm install --dry-run --debug`:\n\n```go\napiVersion: v2\n# деяка: проблемна секція\n# {{ .Values.foo | quote }}\n```\n\nВищезазначене буде відтворено та повернуто з коментарями без змін:\n\n```yaml\napiVersion: v2\n# деяка: проблемна секція\n#  \"bar\"\n```\n\nЦе забезпечує швидкий спосіб перегляду згенерованого контенту без блокування помилками парсингу YAML.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/function_list.mdx",
    "content": "---\ntitle: Список функцій шаблонів\ndescription: Список функцій шаблонів, доступних у Helm\nsidebar_position: 6\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm містить багато функцій шаблонів, якими ви можете скористатися у шаблонах. Вони перераховані тут і розбиті на наступні категорії:\n\n* [Криптографія та безпека](#cryptographic-and-security-functions)\n* [Дата](#date-functions)\n* [Словники](#dictionaries-and-dict-functions)\n* [Кодування](#encoding-functions)\n* [Шлях до файлу](#file-path-functions)\n* [Kubernetes та чарти](#kubernetes-and-chart-functions)\n* [Логіка та керування потоком](#logic-and-flow-control-functions)\n* [Списки](#lists-and-list-functions)\n* [Математичні функції](#math-functions)\n* [Математичні обчислення з комою](#float-math-functions)\n* [Мережа](#network-functions)\n* [Аналіз](#reflection-functions)\n* [Регулярні вирази](#regular-expressions)\n* [Семантичні версії](#semantic-version-functions)\n* [Рядки](#string-functions)\n* [Перетворення типів](#type-conversion-functions)\n* [URL](#url-functions)\n* [UUID](#uuid-functions)\n\n## Логічні функції та функції керування потоком {#logic-and-flow-control-functions}\n\nHelm включає в себе численні логічні функції та функції управління потоком, включаючи [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).\n\n### and\n\nПовертає логічне AND для двох або більше аргументів (перший порожній аргумент або останній аргумент).\n\n```go\nand .Arg1 .Arg2\n```\n\n### or\n\nПовертає логічне OR двох або більше аргументів (перший непорожній аргумент або останній аргумент).\n\n```go\nor .Arg1 .Arg2\n```\n\n### not\n\nПовертає логічне заперечення свого аргументу.\n\n```go\nnot .Arg\n```\n\n### eq\n\nПовертає логічну рівність аргументів (наприклад, Arg1 == Arg2).\n\n```go\neq .Arg1 .Arg2\n```\n\n### ne\n\nПовертає логічну нерівність аргументів (наприклад, Arg1 != Arg2)\n\n```go\nne .Arg1 .Arg2\n```\n\n### lt\n\nПовертає логічне `true`, якщо перший аргумент менший за другий. В іншому випадку повертає `false` (наприклад, Arg1 < Arg2).\n\n```go\nlt .Arg1 .Arg2\n```\n\n### le\n\nПовертає логічне `true`, якщо перший аргумент менший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 &lt;= Arg2).\n\n```go\nle .Arg1 .Arg2\n```\n\n### gt\n\nПовертає логічне `true`, якщо перший аргумент більший за другий. В іншому випадку повертає `false` (наприклад, Arg1 > Arg2).\n\n```go\ngt .Arg1 .Arg2\n```\n\n### ge\n\nПовертає логічне `true`, якщо перший аргумент більший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 >= Arg2).\n\n```go\nge .Arg1 .Arg2\n```\n\n### default\n\nЩоб встановити просте стандартне значення, використовуйте `default`:\n\n```go\ndefault \"foo\" .Bar\n```\n\nУ наведеному прикладі, якщо `.Bar` має непорожнє значення, воно буде використане. Якщо ж воно порожнє, повернеться `foo`.\n\nВизначення \"порожньості\" залежить від типу:\n\n* Числові: 0\n* Рядок: \"\"\n* Списки: `[]`\n* Словники: `{}`\n* Логічний: `false`\n* І завжди `nil` (або null)\n\nДля структур немає визначення порожнього значення, тому структура ніколи не поверне стандартного значення.\n\n### required\n\nВкажіть значення, які повинні бути встановлені, за допомогою `required`:\n\n```go\nrequired \"A valid foo is required!\" .Bar\n```\n\nЯкщо `.Bar` є порожнім або не визначеним (див. [default](#default) щодо того, як це оцінюється), шаблон не буде згенерований і поверне надане повідомлення про помилку.\n\n### empty\n\nФункція `empty` повертає `true`, якщо надане значення вважається порожнім, і `false` в іншому випадку. Пусті значення перелічені в розділі `default`.\n\n```go\nempty .Foo\n```\n\nЗверніть увагу, що в умовах шаблонів Go порожність розраховується автоматично. Таким чином, рідко потрібно використовувати `if not empty .Foo`. Замість цього просто використовуйте `if .Foo`.\n\n### fail\n\nБезумовно повертає порожні `string` та `error` з зазначеним текстом. Це корисно в ситуаціях, коли інші умови визначили, що рендеринг шаблону повинен зазнати невдачі.\n\n```go\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\nФункція `coalesce` приймає список значень і повертає перше непорожнє значення.\n\n```go\ncoalesce 0 1 2\n```\n\nУ наведеному випадку повертає `1`.\n\nЦя функція корисна для перевірки кількох змінних або значень:\n\n```go\ncoalesce .name .parent.name \"Matt\"\n```\n\nЦей приклад спочатку перевірить, чи `.name` порожній. Якщо ні, то поверне це значення. Якщо він _є_ порожнім, `coalesce` перевірить `.parent.name` на порожність. Нарешті, якщо і `.name`, і `.parent.name` порожні, то поверне `Matt`.\n\n### ternary\n\nФункція `ternary` приймає два значення і тестове значення. Якщо тестове значення є `true`, повернеться перше значення. Якщо тестове значення є порожнім, повернеться друге значення. Це подібно до тернарного оператора в C та інших мовах програмування.\n\n#### тестове значення true {#true-test-value}\n\n```go\nternary \"foo\" \"bar\" true\n```\n\nабо\n\n```go\ntrue | ternary \"foo\" \"bar\"\n```\n\nУ цьому випадку повертається `\"foo\"`.\n\n#### тестове значення false {#false-test-value}\n\n```go\nternary \"foo\" \"bar\" false\n```\n\nабо\n\n```gol\nfalse | ternary \"foo\" \"bar\"\n```\n\nУ цьому випадку повертається `\"bar\"`.\n\n## Функції для роботи з рядками {#string-functions}\n\nHelm має такі функції для обробки рядків: [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).\n\n### print\n\nПовертає рядок, що є комбінацією його частин.\n\n```go\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\nТипи, які не є рядками, перетворюються на рядки, якщо це можливо.\n\nЗверніть увагу, що коли два аргументи поруч один з одним не є рядками, між ними додається пробіл.\n\n### println\n\nПрацює так само як [print](#print), але додає новий рядок наприкінці.\n\n### printf\n\nПовертає рядок на основі відформатованого рядка та аргументів, що передаються у до нього.\n\n```go\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\nЗаповнювач, який слід використовувати, залежить від типу переданого аргументу. Серед них:\n\nЗагального призначення:\n\n* `%v` значення в стандартному форматі\n  * при друку словників, прапорець `+` (%+v) додає імена полів\n* `%%` літеральний знак відсотка; не використовує значення\n\nЛогічний:\n\n* `%t` слово true або false\n\nЦілі числа:\n\n* `%b` двійкові, основа 2\n* `%c` символ, представлений відповідною кодовою точкою Unicode\n* `%d` десяткові, основа 10\n* `%o` вісімкові, основа 8\n* `%O` основа 8 з префіксом 0o\n* `%q` вісімкові, однорядковий літерал символу, безпечно екранований\n* `%x` шістнадцяткові, основа 16, з малими літерами для a-f\n* `%X` шістнадцяткові, основа 16, з великими літерами для A-F\n* `%U` Unicode формат: U+1234; те ж саме, що \"U+%04X\"\n\nКомпоненти з рухомою комою та комплексні компоненти:\n\n* `%b` десятковий формат без наукової нотації з показником ступеня двійки, наприклад -123456p-78\n* `%e` наукова нотація, наприклад -1.234456e+78\n* `%E` наукова нотація, наприклад -1.234456E+78\n* `%f` десятковий формат без експоненти, наприклад 123.456\n* `%F` синонім для %f\n* `%g` %e для великих експонент, %f в іншому випадку\n* `%G` %E для великих експонент, %F в іншому випадку\n* `%x` шістнадцяткова нотація (з десятковим показником ступеня), наприклад -0x1.23abcp+20\n* `%X` шістнадцяткова нотація у верхньому регістрі, наприклад -0X1.23ABCP+20\n\nРядок та зріз (slice) байтів (обробляються однаково з цими діями):\n\n* `%s` необроблені байти рядка або зрізу\n* `%q` рядок в подвійних лапках, безпечно екранований\n* `%x` основа 16, малий регістр, два символи на байт\n* `%X` основа 16, великий регістр, два символи на байт\n\nЗріз (Slice):\n\n* `%p` адреса 0-го елемента у шістнадцятковій нотації, з передуючим 0x\n\n### trim\n\nФункція `trim` видаляє пробіли з обох сторін рядка:\n\n```go\ntrim \"   hello    \"\n```\n\nУ результаті отримаємо `hello`.\n\n### trimAll\n\nВидаляє зазначені символи з початку та кінця рядка:\n\n```go\ntrimAll \"$\" \"$5.00\"\n```\n\nУ результаті отримаємо `5.00` (як рядок).\n\n### trimPrefix\n\nВидаляє лише префікс з рядка:\n\n```go\ntrimPrefix \"-\" \"-hello\"\n```\n\nУ результаті отримаємо `hello`.\n\n### trimSuffix\n\nВидаляє лише суфікс з рядка:\n\n```go\ntrimSuffix \"-\" \"hello-\"\n```\n\nУ результаті отримаємо `hello`.\n\n### lower\n\nПеретворює весь рядок у нижній регістр:\n\n```go\nlower \"HELLO\"\n```\n\nУ результаті отримаємо `hello`.\n\n### upper\n\nПеретворює весь рядок у верхній регістр:\n\n```go\nupper \"hello\"\n```\n\nУ результаті отримаємо `HELLO`.\n\n### title\n\nПеретворює рядок у титульний регістр:\n\n```go\ntitle \"hello world\"\n```\n\nУ результаті отримаємо `Hello World`.\n\n### untitle\n\nВидаляє титульне оформлення. `untitle \"Hello World\"` поверне `hello world`.\n\n### repeat\n\nПовторює рядок кілька разів:\n\n```go\nrepeat 3 \"hello\"\n```\n\nУ результаті отримаємо `hellohellohello`.\n\n### substr\n\nОтримує підрядок з рядка. Приймає три парамтери:\n\n* початок (int)\n* кінець (int)\n* рядок (string)\n\n```go\nsubstr 0 5 \"hello world\"\n```\n\nУ результаті отримаємо `hello`.\n\n### nospace\n\nВидаляє всі пробіли з рядка:\n\n```go\nnospace \"hello w o r l d\"\n```\n\nУ результаті отримаємо `helloworld`.\n\n### trunc\n\nОбрізає рядок:\n\n```go\ntrunc 5 \"hello world\"\n```\n\nУ результаті отримаємо `hello`.\n\n```go\ntrunc -5 \"hello world\"\n```\n\nУ результаті отримаємо `world`.\n\n### abbrev\n\nОбрізає рядок додаючи три крапки (`...`):\n\nПараметри:\n\n* максимальна довжина\n* рядок\n\n```go\nabbrev 5 \"hello world\"\n```\n\nУ результаті отримаємо `he...`, оскільки ширина трьох крапок враховується до максимальної довжини.\n\n### abbrevboth\n\nОбрізає обидві сторони:\n\n```go\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\nУ результаті отримаємо `...5678...`.\n\nПараметри:\n\n* зсув ліворуч\n* максимальна довжина\n* рядок\n\n### initials\n\nДля кількох слів бере першу літеру кожного слова та обʼєднує їх:\n\n```go\ninitials \"First Try\"\n```\n\nУ результаті отримаємо `FT`.\n\n### randAlphaNum, randAlpha, randNumeric та randAscii {#randalphanum-randalpha-randnumeric-and-randascii}\n\nЦі чотири функції генерують криптографічно безпечні (використовує ```crypto/rand```) випадкові рядки, але з різними базовими наборами символів:\n\n* `randAlphaNum` використовує `0-9a-zA-Z`\n* `randAlpha` використовує `a-zA-Z`\n* `randNumeric` використовує `0-9`\n* `randAscii` використовує всі друковані ASCII символи\n\nКожна з них приймає один параметр: цілу довжину рядка.\n\n```go\nrandNumeric 3\n```\n\nУ результаті отримаємо випадковий рядок з трьох цифр.\n\n### wrap\n\nВиконує перенесення тексту на вказаній кількості стовпців:\n\n```go\nwrap 80 $someText\n```\n\nУ результаті для рядка `$someText` буде виконано перенесення на 80-му стовпці.\n\n### wrapWith\n\n`wrapWith` працює так само як і `wrap`, але дозволяє вказати рядок для перенесення. (`wrap` використовує `\\n`)\n\n```go\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\nУ результаті отримаємо `Hello World` (де пробіл є символом ASCII табуляції).\n\n### contains\n\nПеревіряє, чи один рядок міститься всередині іншого:\n\n```go\ncontains \"cat\" \"catch\"\n```\n\nУ результаті отримаємо `true`, оскільки `catch` містить `cat`.\n\n### hasPrefix і hasSuffix {#hasprefix-and-hassuffix}\n\nФункції `hasPrefix` і `hasSuffix` перевіряють, чи має рядок заданий префікс або суфікс:\n\n```go\nhasPrefix \"cat\" \"catch\"\n```\n\nУ результаті отримаємо `true`, оскільки `catch` має префікс `cat`.\n\n### quote і squote {#quote-and-squote}\n\nЦі функції обгортають рядок у подвійні лапки (`quote`) або одинарні лапки (`squote`).\n\n### cat\n\nФункція `cat` обʼєднує кілька рядків в один, розділяючи їх пробілами:\n\n```go\ncat \"hello\" \"beautiful\" \"world\"\n```\n\nУ результаті отримаємо `hello beautiful world`.\n\n### indent\n\nФункція `indent` додає відступ у кожному рядку вказаного тексту на зазначену кількість символів. Це корисно для вирівнювання багаторядкових текстів:\n\n```go\nindent 4 $lots_of_text\n```\n\nУ результаті кожен рядок тексту буде мати відступ на 4 символи пробілу.\n\n### nindent\n\nФункція `nindent` є такою ж, як і `indent`, але додає новий рядок на початку рядка.\n\n```go\nnindent 4 $lots_of_text\n```\n\nУ результаті кожен рядок тексту буде мати відступ на 4 символи пробілу, а також буде додано новий рядок на початку.\n\n### replace\n\nВиконує просту заміну рядків.\n\nВона приймає три аргументи:\n\n* рядок для заміни\n* рядок, на який замінювати\n* вихідний рядок\n\n```go\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\nУ результаті отримаємо `I-Am-Henry-VIII`.\n\n### plural\n\nФорма множини.\n\n```go\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\nУ наведеному випадку, якщо довжина рядка дорівнює 1, буде надруковано перший аргумент (`one anchovy`). В іншому випадку буде надруковано другий аргумент (`many anchovies`).\n\nАргументи:\n\n* однина\n* множина\n* довжина (ціле число)\n\n:::note\nHelm наразі не підтримує мови зі складнішими правилами множини. І `0` вважається множиною, оскільки англійська мова ставиться до нього саме так (`zero anchovies`).\n:::\n\n### snakecase\n\nПеретворює рядок з camelCase в snake_case.\n\n```go\nsnakecase \"FirstName\"\n```\n\nУ результаті отримаємо `first_name`.\n\n### camelcase\n\nПеретворює рядок з snake_case в CamelCase.\n\n```go\ncamelcase \"http_server\"\n```\n\nУ результаті отримаємо `HttpServer`.\n\n### kebabcase\n\nПеретворює рядок з camelCase в kebab-case.\n\n```go\nkebabcase \"FirstName\"\n```\n\nУ результаті отримаємо `first-name`.\n\n### swapcase\n\nЗмінює регістр рядка за допомогою алгоритму на основі слів.\n\nАлгоритм перетворення:\n\n* Символи у верхньому регістрі перетворюються у нижній регістр\n* Символи в титульному регістрі перетворюються у нижній регістр\n* Символи у нижньому регістрі після пробілу або на початку перетворюються у титульний регістр\n* Інші символи у нижньому регістрі перетворюються у верхній регістр\n* Пробіли визначаються як unicode.IsSpace(char)\n\n```go\nswapcase \"This Is A.Test\"\n```\n\nУ результаті отримаємо `tHIS iS a.tEST`.\n\n### shuffle\n\nПеремішує рядок.\n\n```go\nshuffle \"hello\"\n```\n\nУ результаті отримаємо випадковий порядок літер у `hello`, можливо, `oelhl`.\n\n## Функції перетворення типів {#type-conversion-functions}\n\nHelm пропонує такі функції для перетворення типів:\n\n* `atoi`: Перетворює рядок на ціле число.\n* `float64`: Перетворює на `float64`.\n* `int`: Перетворює на `int` відповідно до ширини системи.\n* `int64`: Перетворює на `int64`.\n* `toDecimal`: Перетворює unix octal на `int64`.\n* `toString`: Перетворює на рядок.\n* `toStrings`: Перетворює список, зріз або масив на список рядків.\n* `toJson` (`mustToJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON.\n* `toPrettyJson` (`mustToPrettyJson`): Перетворює список, зріз, масив, словник або обʼєкт на форматований JSON.\n* `toRawJson` (`mustToRawJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON з неекранованими HTML символами.\n* `fromYaml`: Перетворює YAML рядок на обʼєкт.\n* `fromJson`: Перетворює JSON рядок на обʼєкт.\n* `fromJsonArray`: Перетворює JSON масив на список.\n* `toYaml`: Перетворює список, зріз, масив, словник або обʼєкт у формат YAML з відступами, може використовуватися для копіювання фрагментів YAML з будь-якого джерела. Ця функція еквівалентна функції GoLang yaml.Marshal, див. документацію тут: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal\n* `toYamlPretty`: Перетворює список, зріз, масив, словник або обʼєкт у формат YAML з відступами. Еквівалентний функції `toYaml`, але додатково робить відступи у списках на 2 пробіли.\n* `toToml`: Перетворює список, зріз, масив, словник або обʼєкт у toml, може використовуватися для копіювання фрагментів toml з будь-якого джерела.\n* `fromYamlArray`: Перетворює YAML масив на список.\n\nТільки `atoi` вимагає, щоб вхідні дані були певного типу. Інші функції намагатимуться перетворити будь-який тип у тип призначення. Наприклад, `int64` може перетворювати числа з рухомою комою в цілі числа, а також перетворювати рядки в цілі числа.\n\n### toStrings\n\nПеретворює колекцію схожу на список на зріз рядків.\n\n```go\nlist 1 2 3 | toStrings\n```\n\nПеретворює `1` на `\"1\"`, `2` на `\"2\"` і так далі, а потім повертає їх як список.\n\n### toDecimal\n\nПеретворює unix octal на десятковий формат.\n\n```go\n\"0777\" | toDecimal\n```\n\nПеретворює `0777` на `511` і повертає значення як int64.\n\n### toJson, mustToJson\n\nThe `toJson` function encodes an item into a JSON string. If the item cannot be\nconverted to JSON the function will return an empty string. `mustToJson` will\nreturn an error in case the item cannot be encoded in JSON.\n\n```go\ntoJson .Item\n```\n\nПоверне JSON рядкове представлення `.Item`.\n\n### toPrettyJson, mustToPrettyJson\n\nФункція `toPrettyJson` кодує елемент у форматований (з відступами) JSON рядок.\n\n```go\ntoPrettyJson .Item\n```\n\nПоверне відформатоване JSON рядкове представлення `.Item`.\n\n### toRawJson, mustToRawJson\n\nThe `toRawJson` function encodes an item into JSON string with HTML characters\nunescaped.\n\n```go\ntoRawJson .Item\n```\n\nПоверне неекрановане JSON рядкове представлення `.Item`.\n\n### fromYaml\n\nФункція `fromYaml` приймає YAML рядок і повертає обʼєкт, який можна використовувати в шаблонах.\n\nФайл `yamls/person.yaml`:\n\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```go\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\nФункція `fromJson` приймає JSON рядок і повертає обʼєкт, який можна використовувати в шаблонах.\n\nФайл `jsons/person.json`:\n\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n\n```go\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJsonArray\n\nФункція `fromJsonArray` приймає JSON масив і повертає список, який можна використовувати в шаблонах.\n\nФайл `jsons/people.json`:\n\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n\n```go\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml, toYamlPretty\n\nФункції `toYaml` та `toYamlPretty` кодують обʼєкт (список, зріз, масив, словник або обʼєкт) у формат YAML із відступами.\n\n> Зверніть увагу, що `toYamlPretty` є функціонально еквівалентним, але виведе YAML з додатковими відступами для елементів списку.\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\nФункція `fromYamlArray` приймає YAML масив і повертає список, який можна використовувати в шаблонах.\n\nФайл `yamls/people.yml`:\n\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n\n```go\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n## Регулярні Вирази {#regular-expressions}\n\nHelm включає такі функції для роботи з регулярними виразами: [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\nПовертає `true`, якщо вхідний рядок містить хоча б один збіг для регулярного виразу.\n\n```go\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\nПоверне `true`.\n\n`regexMatch` викликає паніку у разі проблеми, а `mustRegexMatch` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexFindAll, mustRegexFindAll\n\nПовертає зріз усіх збігів регулярного виразу у вхідному рядку. Останній параметр `n` визначає кількість підрядків для повернення, де `-1` означає повернути всі збіги.\n\n```go\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\nПоверне `[2 4 6 8]`.\n\n`regexFindAll` викликає паніку у разі проблеми, а `mustRegexFindAll` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexFind, mustRegexFind\n\nПовертає перший (зліва) збіг регулярного виразу у вхідному рядку.\n\n```go\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\nПоверне `d1`.\n\n`regexFind` викликає паніку у разі проблеми, а `mustRegexFind` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexReplaceAll, mustRegexReplaceAll\n\nПовертає копію вхідного рядка, замінюючи збіги Regexp на рядок заміни replacement. Усередині заміни рядка знаки $ інтерпретуються як в Expand, тому, наприклад, $1 представляє текст першого підзбігу. Перший аргумент — `<pattern>`, другий — `<input>`, а третій — `<replacement>`.\n\n```go\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\nПоверне `-W-xxW-`.\n\n`regexReplaceAll` викликає паніку у разі проблеми, а `mustRegexReplaceAll` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\nПовертає копію вхідного рядка, замінюючи збіги Regexp на рядок заміни replacement. Рядок заміни підставляється безпосередньо, без використання Expand. Перший аргумент — `<pattern>`, другий — `<input>`, третій — `<replacement>`.\n\n```go\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\nПоверне `-${1}-${1}-`.\n\n`regexReplaceAllLiteral` викликає паніку у разі проблеми, а `mustRegexReplaceAllLiteral` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexSplit, mustRegexSplit\n\nРозбиває вхідний рядок на підрядки, розділені виразом, і повертає фрагмент підрядків між цими збігами виразу. Останній параметр `n` визначає кількість підрядків, що повертаються, де `-1` означає повернути всі збіги.\n\n```go\nregexSplit \"z+\" \"pizza\" -1\n```\n\nПоверне `[pi a]`.\n\n`regexSplit` викликає паніку у разі проблеми, а `mustRegexSplit` поверне помилку у рушії шаблонів у разі проблеми.\n\n## Функції криптографії та безпеки {#cryptographic-and-security-functions}\n\nHelm надає декілька розширених криптографічних функцій, серед яких: [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).\n\n### sha1sum\n\nФункція `sha1sum` отримує рядок і обчислює його SHA1-дайджест.\n\n```go\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\nФункція `sha256sum` отримує рядок і обчислює його SHA256-дайджест.\n\n```go\nsha256sum \"Hello world!\"\n```\n\nЦе обчислює SHA 256 контрольну суму у форматі \"ASCII armored\", який є безпечним для друку.\n\n### adler32sum\n\nФункція `adler32sum` отримує рядок і обчислює його контрольну суму Adler-32.\n\n```go\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\nФункція `htpasswd` приймає `username` та `password` і генерує хеш `bcrypt` пароля. Результат можна використовувати для базової автентифікації в [Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic).\n\n```go\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nЗверніть увагу, що небезпечно зберігати пароль безпосередньо в шаблоні.\n\n### randBytes\n\nФункція randBytes приймає число N і генерує криптографічно захищену (використовує crypto/rand) випадкову послідовність з N байтів. Послідовність повертається у вигляді рядка, закодованого в base64.\n\n```go\nrandBytes 24\n```\n\n### derivePassword\n\nФункція `derivePassword` може бути використана для отримання конкретного пароля на основі деяких спільних обмежень «головного пароля». Алгоритм для цього добре [описаний](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf).\n\n```go\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nЗверніть увагу, що небезпечно зберігати частини безпосередньо в шаблоні.\n\n### genPrivateKey\n\nФункція `genPrivateKey` генерує новий приватний ключ, закодований у PEM-блок.\n\nВона приймає одне з наступних значень для свого першого параметра:\n\n* `ecdsa`: Генерує ключ еліптичної кривої DSA (P256)\n* `dsa`: Генерує DSA ключ (L2048N256)\n* `rsa`: Генерує RSA 4096 ключ\n\n### buildCustomCert\n\nФункція `buildCustomCert` дозволяє налаштувати сертифікат.\n\nВона приймає наступні строкові параметри:\n\n* Сертифікат у форматі PEM, закодований у base64\n* Приватний ключ у форматі PEM, закодований у base64\n\nФункція повертає обʼєкт сертифіката з наступними атрибутами:\n\n* `Cert`: Сертифікат у форматі PEM\n* `Key`: Приватний ключ у форматі PEM\n\nПриклад:\n\n```go\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\nЗверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA.\n\n### genCA\n\nФункція `genCA` генерує новий самопідписний сертифікат x509 для центру сертифікацї.\n\nВона приймає наступні параметри:\n\n* Загальне імʼя субʼєкта (cn)\n* Термін дії сертифіката у днях\n\nФункція повертає обʼєкт з наступними атрибутами:\n\n* `Cert`: Сертифікат у форматі PEM\n* `Key`: Приватний ключ у форматі PEM\n\nПриклад:\n\n```go\n$ca := genCA \"foo-ca\" 365\n```\n\nЗверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA.\n\n### genSelfSignedCert\n\nФункція `genSelfSignedCert` генерує новий самопідписаний сертифікат x509.\n\nВона приймає наступні параметри:\n\n* Загальне імʼя субʼєкта (cn)\n* Необовʼязковий список IP-адрес; може бути nil\n* Необовʼязковий список альтернативних DNS-імен; може бути nil\n* Термін дії сертифіката у днях\n\nФункція повертає обʼєкт з наступними атрибутами:\n\n* `Cert`: Сертифікат у форматі PEM\n* `Key`: Приватний ключ у форматі PEM\n\nПриклад:\n\n```go\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\nФункція `genSignedCert` генерує новий сертифікат x509, підписаний зазначеним CA.\n\nВона приймає наступні параметри:\n\n* Спільне імʼя субʼєкта (cn)\n* Необовʼязковий список IP-адрес; може бути nil\n* Необовʼязковий список альтернативних DNS-імен; може бути nil\n* Термін дії сертифіката у днях\n* CA (див. `genCA`)\n\nПриклад:\n\n```go\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\nФункція `encryptAES` шифрує текст за допомогою AES-256 CBC і повертає рядок, закодований у base64.\n\n```go\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\nФункція `decryptAES` отримує рядок у форматі base64, закодований за допомогою алгоритму AES-256 CBC, і повертає розкодований текст.\n\n```go\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Функції дати {#date-functions}\n\nHelm включає наступні функції дати, які ви можете використовувати в шаблонах: [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).\n\n### now\n\nПоточна дата/час. Використовуйте це разом з іншими функціями дати.\n\n### ago\n\nФункція `ago` повертає тривалість від часу. Зараз у секундах.\n\n```go\nago .CreatedAt\n```\n\nповертає у форматі `time.Duration` String()\n\n```go\n2h34m7s\n```\n\n### date\n\nФункція `date` форматує дату.\n\nФормат дати до РІК-МІСЯЦЬ-ДЕНЬ:\n\n```go\nnow | date \"2006-01-02\"\n```\n\nФорматування дати в Go [дещо відрізняється](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\nКоротко, візьміть цю базову дату:\n\n```go\nMon Jan 2 15:04:05 MST 2006\n```\n\nЗапишіть її у потрібному форматі. Вище, `2006-01-02` — це та ж дата, але в потрібному форматі.\n\n### dateInZone\n\nТе ж саме, що і `date`, але з часовою зоною.\n\n```go\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\nФорматує задану кількість секунд як `time.Duration`.\n\nЦе повертає 1m35s\n\n```go\nduration \"95\"\n```\n\n### durationRound\n\nОкруглює задану тривалість до найзначнішої одиниці. Рядки та `time.Duration` аналізуються як тривалість, тоді як `time.Time` обчислюється як тривалість з моменту.\n\nЦе повертає 2h\n\n```go\ndurationRound \"2h10m5s\"\n```\n\nЦе повертає 3mo\n\n```go\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\nПовертає кількість секунд з unix-епохи для `time.Time`.\n\n```go\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\nФункція `dateModify` приймає модифікацію та дату і повертає часову мітку.\n\nВідніміть годину і тридцять хвилин від поточного часу:\n\n```go\nnow | dateModify \"-1.5h\"\n```\n\nЯкщо формат модифікації неправильний, `dateModify` поверне дату немодифікованою. `mustDateModify` поверне помилку в іншому випадку.\n\n### htmlDate\n\nФункція `htmlDate` форматує дату для вставки в поле введення дати в HTML.\n\n```go\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nТе ж саме, що і htmlDate, але з часовою зоною.\n\n```go\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\nФункція `toDate` перетворює рядок у дату. Перший аргумент — це макет дати, а другий — рядок дати. Якщо рядок не можна перетворити, він поверне нульове значення. `mustToDate` поверне помилку в разі, якщо рядок не можна перетворити.\n\nЦе корисно, коли ви хочете перетворити дату-рядок в інший формат (використовуючи конвеєр). Нижче наведений приклад перетворює \"2017-12-31\" на \"31/12/2017\".\n\n```go\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Словники та функції словників {#dictionaries-and-dict-functions}\n\nHelm надає тип зберігання ключ/значення, який називається `dict` (скорочено від \"dictionary\" [\"словник\"], як у Python). `dict` є _невпорядкованим_ типом.\n\nКлюч у словнику **має бути рядком**. Однак значення може бути будь-якого типу, навіть іншим `dict` або `list`.\n\nНа відміну від `list`, `dict` не є незмінним. Функції `set` та `unset` змінюють вміст словника.\n\nHelm надає такі функції для роботи зі словниками: [deepCopy\n(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).\n\n### dict\n\nСтворення словників здійснюється шляхом виклику функції `dict` і передачі їй списку пар.\n\nНаступний приклад створює словник з трьома елементами:\n\n```go\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nЗа наявності map і ключа отримає значення з map.\n\n```go\nget $myDict \"name1\"\n```\n\nНаведений вище приклад поверне `\"value1\"`.\n\nЗверніть увагу, що якщо ключ не знайдено, ця операція просто поверне `\"\"`. Помилка не буде згенерована.\n\n### set\n\nВикористовуйте `set`, щоб додати нову пару ключ/значення до словника.\n\n```go\n$_ := set $myDict \"name4\" \"value4\"\n```\n\nЗверніть увагу, що `set` _повертає словник_ (вимога функцій шаблону Go), тому вам може знадобитися захопити значення, як це зроблено вище за допомогою присвоєння `$_`.\n\n### unset\n\nЗа наявності map і ключа видалить ключ з map.\n\n```go\n$_ := unset $myDict \"name4\"\n```\n\nAs with `set`, this returns the dictionary.\n\nЗверніть увагу, що якщо ключ не знайдено, ця операція просто виконає вивід. Помилка не буде згенерована.\n\n### hasKey\n\nФункція `hasKey` повертає `true`, якщо даний словник містить даний ключ.\n\n```go\nhasKey $myDict \"name1\"\n```\n\nЯкщо ключ не знайдено, це повертає `false`.\n\n### pluck\n\nФункція `pluck` дозволяє вказати один ключ і кілька map, і отримати список усіх знайдених збігів:\n\n```go\npluck \"name1\" $myDict $myOtherDict\n```\n\nНаведений вище приклад поверне `list`, що містить усі знайдені значення (`[value1 otherValue1]`).\n\nЯкщо даний ключ _не знайдено_ в map, цей map не буде мати елемента у списку (і довжина повернутого списку буде меншою, ніж кількість словників у виклику `pluck`).\n\nЯкщо ключ _знайдено_, але значення є порожнім, це значення буде вставлено.\n\nПоширеною ідіомою у шаблонах Helm є використання `pluck... | first`, щоб отримати перший відповідний ключ із колекції словників.\n\n### dig\n\nФункція `dig` проходить через вкладені набори словників, вибираючи ключі зі списку значень. Вона повертає стандартне значення, якщо будь-який з ключів не знайдено в асоційованому словнику.\n\n```go\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\nЗа наявності словника, структурованого таким чином:\n\n```json\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\nнаведений вище приклад поверне `\"curator\"`. Якщо у словнику навіть не було поля `user`, результатом буде `\"guest\"`.\n\nDig може бути дуже корисним у випадках, коли ви хочете уникнути захисних конструкцій, особливо з огляду на те, що `and` у пакеті шаблонів Go не є скороченням. Наприклад, `and a.maybeNil a.maybeNil.iNeedThis` завжди оцінюватиме `a.maybeNil.iNeedThis` і викликатиме паніку, якщо `a` не має поля `maybeNil`.\n\n`dig` приймає свій аргумент словника останнім, щоб підтримувати конвеєрну обробку. Наприклад:\n\n```go\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\nОбʼєднує два або більше словників в один, надаючи перевагу словнику призначення:\n\nНаприклад:\n\n```yaml\ndst:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nрезультатом буде:\n\n```yaml\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n\n```go\n$newdict := merge $dest $source1 $source2\n```\n\nЦе операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад,\n\n```go\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` поверне помилку в разі невдалого обʼєднання.\n\n### mergeOverwrite, mustMergeOverwrite\n\nОбʼєднує два або більше словників в один, надаючи перевагу **зправа наліво**, ефективно перезаписуючи значення в словнику призначення:\n\nНаприклад:\n\n```yaml\ndst:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nрезультатом буде:\n\n```yaml\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```go\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nЦе операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад,\n\n```go\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` поверне помилку в разі невдалого обʼєднання.\n\n### keys\n\nФункція `keys` повертає `list` усіх ключів одного або декількох типів `dict`. Оскільки словник є _невпорядкованим_, ключі не будуть у передбачуваному порядку. Їх можна відсортувати за допомогою `sortAlpha`.\n\n```go\nkeys $myDict | sortAlpha\n```\n\nПри поданні кількох словників ключі будуть обʼєднані. Використовуйте функцію `uniq` разом із `sortAlpha`, щоб отримати унікальний, відсортований список ключів.\n\n```go\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\nФункція `pick` вибирає тільки зазначені ключі зі словника, створюючи новий `dict`.\n\n```go\n$new := pick $myDict \"name1\" \"name2\"\n```\n\nНаведений вище приклад поверне `{name1: value1, name2: value2}`.\n\n### omit\n\nФункція `omit` схожа на `pick`, за винятком того, що вона повертає новий `dict` з усіма ключами, які _не_ збігаються з даними ключами.\n\n```go\n$new := omit $myDict \"name1\" \"name3\"\n```\n\nНаведений вище приклад поверне `{name2: value2}`.\n\n### values\n\nФункція `values` схожа на `keys`, за винятком того, що вона повертає новий `list` з усіма значеннями вихідного `dict` (підтримується тільки один словник).\n\n```go\n$vals := values $myDict\n```\n\nНаведений вище приклад поверне `list[\"value1\", \"value2\", \"value 3\"]`. Зверніть увагу, що функція `values` не дає жодних гарантій щодо порядку результатів; якщо це важливо, використовуйте `sortAlpha`.\n\n### deepCopy, mustDeepCopy\n\nФункції `deepCopy` і `mustDeepCopy` приймають значення і роблять глибоку копію цього значення. Це включає словники та інші структури. `deepCopy` викликає паніку, коли виникає проблема, тоді як `mustDeepCopy` повертає помилку системі шаблонів, коли виникає помилка.\n\n```go\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### Примітка про внутрішню структуру Dict {#a-note-on-dict-internals}\n\n`dict` реалізовано в Go як `map[string]interface{}`. Розробники Go можуть передавати значення `map[string]interface{}` у контекст, щоб зробити їх доступними для шаблонів як `dict`.\n\n## Функції кодування {#encoding-functions}\n\nHelm має такі функції для кодування та декодування:\n\n* `b64enc`/`b64dec`: Кодування або декодування з використанням Base64\n* `b32enc`/`b32dec`: Кодування або декодування з використанням Base32\n\n## Списки та функції для роботи зі списками {#lists-and-list-functions}\n\nHelm надає простий тип `list`, який може містити довільні послідовні дані. Це схоже на масиви або зрізи, але списки призначені для використання як незмінні типи даних.\n\nСтворення списку цілих чисел:\n\n```go\n$myList := list 1 2 3 4 5\n```\n\nЦе створить список `[1 2 3 4 5]`.\n\nHelm надає наступні функції для роботи зі списками:  [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).\n\n### first, mustFirst\n\nЩоб отримати перший елемент списку, використовуйте `first`.\n\n`first $myList` повертає `1`.\n\n`first` викликає panic у разі проблеми, тоді як `mustFirst` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### rest, mustRest\n\nЩоб отримати залишок списку (все, окрім першого елемента), використовуйте `rest`.\n\n`rest $myList` повертає `[2 3 4 5]`.\n\n`rest` викликає panic у разі проблеми, тоді як `mustRest` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### last, mustLast\n\nЩоб отримати останній елемент списку, використовуйте `last`:\n\n`last $myList` повертає `5`. Це аналогічно до реверсування списку та виклику `first`.\n\n### initial, mustInitial\n\nЦя функція доповнює `last`, повертаючи всі елементи, окрім останнього. `initial $myList` повертає `[1 2 3 4]`.\n\n`initial` викликає panic у разі проблеми, тоді як `mustInitial` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### append, mustAppend\n\nДодає новий елемент до існуючого списку, створюючи новий список.\n\n```go\n$new = append $myList 6\n```\n\nЦе встановлює `$new` до `[1 2 3 4 5 6]`. `$myList` залишається незмінним.\n\n`append` викликає panic у разі проблеми, тоді як `mustAppend` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### prepend, mustPrepend\n\nДодає елемент на початок списку, створюючи новий список.\n\n```go\nprepend $myList 0\n```\n\nЦе створить `[0 1 2 3 4 5]`. `$myList` залишається незмінним.\n\n`prepend` викликає panic у разі проблеми, тоді як `mustPrepend` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### concat\n\nОбʼєднує довільну кількість списків в один.\n\n```go\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\nЦе створить `[1 2 3 4 5 6 7 8]`. `$myList` залишається незмінним.\n\n### reverse, mustReverse\n\nСтворює новий список з елементами у зворотному порядку.\n\n```go\nreverse $myList\n```\n\nЦе генерує список `[5 4 3 2 1]`.\n\n`reverse` викликає panic у разі проблеми, тоді як `mustReverse` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### uniq, mustUniq\n\nСтворює список, з якого видалено всі дублікати.\n\n```go\nlist 1 1 1 2 | uniq\n```\n\nThe above would produce `[1 2]`\n\n`uniq` викликає panic у разі проблеми, тоді як `mustUniq` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### without, mustWithout\n\nФункція `without` відфільтровує елементи зі списку.\n\n```go\nwithout $myList 3\n```\n\nЦе створить `[1 2 4 5]`.\n\n`without` може приймати більше одного фільтра:\n\n```go\nwithout $myList 1 3 5\n```\n\nЦе створить `[2 4]`.\n\n`without` викликає panic у разі проблеми, тоді як `mustWithout` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### has, mustHas\n\nПеревіряє, чи містить список певний елемент.\n\n```go\nhas 4 $myList\n```\n\nЦе поверне `true`, а `has \"hello\" $myList` поверне `false`.\n\n`has` викликає panic у разі проблеми, тоді як `mustHas` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### compact, mustCompact\n\nПриймає список та видаляє елементи з пустими значеннями.\n\n```go\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` поверне новий список з видаленим пустим (тобто \"\") елементом.\n\n`compact` викликає panic у разі проблеми, тоді як `mustCompact` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### index\n\nЩоб отримати n-й елемент списку, використовуйте `index list [n]`. Щоб отримати\nелемент у багатовимірних списках, використовуйте `index list [n] [m] ...`.\n\n* `index $myList 0` повертає `1`. Це те саме, що і `myList[0]`.\n* `index $myList 0 1` повертає той самий результат, що і `myList[0][1]`.\n\n### slice, mustSlice\n\nЩоб отримати часткові елементи списку, використовуйте `slice list [n] [m]`. Це еквівалентно до `list[n:m]`.\n\n* `slice $myList` повертає `[1 2 3 4 5]`. Це те саме, що і `myList[:]`.\n* `slice $myList 3` повертає `[4 5]`. Це те саме, що і `myList[3:]`.\n* `slice $myList 1 3` повертає `[2 3]`. Це те саме, що і `myList[1:3]`.\n* `slice $myList 0 3` повертає `[1 2 3]`. Це те саме, що і `myList[:3]`.\n\n`slice` викликає panic у разі проблеми, тоді як `mustSlice` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### until\n\nФункція `until` створює діапазон цілих чисел.\n\n```go\nuntil 5\n```\n\nЦе генерує список `[0, 1, 2, 3, 4]`.\n\nЦе корисно для циклів з `range $i, $e := until 5`.\n\n### untilStep\n\nЯк і `until`, функція `untilStep` створює список рахуючих цілих чисел. Але вона дозволяє визначити початок, кінець та крок:\n\n```go\nuntilStep 3 6 2\n```\n\nЦе створить `[3 5]`, починаючи з 3 та додаючи 2, поки не буде досягнуто або перевищено 6. Це схоже на функцію `range` в Python.\n\n### seq\n\nПрацює як команда `seq` у bash.\n\n* 1 параметр  (end) — генерує всі натуральні числа від 1 до `end` включно.\n* 2 параметри (start, end) — генерує всі натуральні числа від `start` до `end` включно, збільшуючи або зменшуючи їх на 1.\n* 3 параметри (start, step, end) — генерують всі натуральні числа від `start` до `end` включно, збільшуючи або зменшуючи їх на `step`.\n\n```go\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\nЩоб розділити список на частини заданого розміру, використовуйте `chunk size list`. Це корисно для розбиття на сторінки.\n\n```go\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\nЦе створює список списків `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`.\n\n## Математичні функції {#math-functions}\n\nУсі математичні функції працюють із значеннями типу `int64`, якщо не зазначено інше.\n\nДоступні наступні математичні функції: [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).\n\n### add\n\nДодавайте числа за допомогою `add`. Приймає два або більше аргументів.\n\n```go\nadd 1 2 3\n```\n\n### add1\n\nЩоб збільшити на 1, використовуйте `add1`.\n\n### sub\n\nЩоб відняти, використовуйте `sub`.\n\n### div\n\nВиконуйте цілочисельне ділення за допомогою `div`.\n\n### mod\n\nЗалишок від ділення можна отримати за допомогою `mod`.\n\n### mul\n\nМножте за допомогою `mul`. Приймає два або більше аргументів.\n\n```go\nmul 1 2 3\n```\n\n### max\n\nПовертає найбільше із серії цілих чисел.\n\nЦе поверне `3`:\n\n```go\nmax 1 2 3\n```\n\n### min\n\nПовертає найменше із серії цілих чисел.\n\n`min 1 2 3` поверне `1`.\n\n### len\n\nПовертає довжину аргументу у вигляді цілого числа.\n\n```go\nlen .Arg\n```\n\n## Математичні функції з рухомою комою {#float-math-functions}\n\nУсі математичні функції працюють із значеннями типу `float64`.\n\n### addf\n\nДодавайте числа за допомогою `addf`.\n\nЦе поверне `5.5`:\n\n```go\naddf 1.5 2 2\n```\n\n### add1f\n\nЩоб збільшити на 1, використовуйте `add1f`.\n\n### subf\n\nЩоб відняти, використовуйте `subf`.\n\nЦе еквівалентно `7.5 - 2 - 3` і поверне `2.5`:\n\n```go\nsubf 7.5 2 3\n```\n\n### divf\n\nВиконуйте ділення з рухомою комою за допомогою `divf`.\n\nЦе еквівалентно `10 / 2 / 4` і поверне `1.25`:\n\n```go\ndivf 10 2 4\n```\n\n### mulf\n\nМножте за допомогою `mulf`.\n\nЦе поверне `6`:\n\n```go\nmulf 1.5 2 2\n```\n\n### maxf\n\nПовертає найбільше із серії чисел з рухомою комою:\n\nЦе поверне `3`:\n\n```go\nmaxf 1 2.5 3\n```\n\n### minf\n\nПовертає найменше із серії чисел з рухомою комою.\n\nЦе поверне `1.5`:\n\n```go\nminf 1.5 2 3\n```\n\n### floor\n\nПовертає найбільше число з рухомою комою, яке менше або рівне вхідному значенню.\n\n`floor 123.9999` поверне `123.0`.\n\n### ceil\n\nПовертає найбільше число з рухомою комою, яке більше або рівне вхідному значенню.\n\n`ceil 123.001` поверне `124.0`.\n\n### round\n\nПовертає значення типу float, округленого до заданої кількості знаків після десяткової крапки.\n\n`round 123.555555 3` поверне `123.556`.\n\n## Мережеві функції {#network-functions}\n\nHelm має одну мережеву функцію, `getHostByName`.\n\nФункція `getHostByName` приймає доменне імʼя і повертає IP-адресу.\n\n`getHostByName \"www.google.com\"` поверне відповідну IP-адресу для `www.google.com`.\n\nДля роботи цієї функції необхідно передати опцію `--enable-dns` у командному рядку helm.\n\n## Функції роботи з шляхами до файлів {#file-path-functions}\n\nХоча функції шаблонів Helm не надають доступу до файлової системи, вони надають функції для роботи з рядками, які відповідають домовленостям щодо шляхів до файлів. До них належать: [base](#base), [clean](#clean), [dir](#dir), [ext](#ext) та [isAbs](#isabs).\n\n### base\n\nПовертає останній елемент шляху.\n\n```go\nbase \"foo/bar/baz\"\n```\n\nВищезазначене поверне \"baz\".\n\n### dir\n\nПовертає теку, видаляючи останню частину шляху. Отже, `dir \"foo/bar/baz\"` повертає `foo/bar`.\n\n### clean\n\nОчищує шлях.\n\n```go\nclean \"foo/bar/../baz\"\n```\n\nВищезазначене знаходить `..` і повертає `foo/baz`.\n\n### ext\n\nПовертає розширення файлу.\n\n```go\next \"foo.bar\"\n```\n\nВищезазначене поверне `.bar`.\n\n### isAbs\n\nЩоб перевірити, чи є шлях до файлу абсолютним, використовуйте `isAbs`.\n\n## Функції аналізу {#reflection-functions}\n\nHelm надає базові інструменти аналізу. Це допомагає розробникам шаблонів зрозуміти основну інформацію про типи Go для конкретного значення. Helm написано на Go і він має строгий типізований підхід. Система типів застосовується всередині шаблонів.\n\nGo має кілька примітивів _видів (kind)_, таких як `string`, `slice`, `int64` і `bool`.\n\nGo має відкриту систему _типів_, яка дозволяє розробникам створювати власні типи.\n\nHelm надає набір функцій для кожного з них через [функції kind](#kind-functions) і [функції type](#type-functions). Також надана функція [deepEqual](#deepequal) для порівняння значень.\n\n### Функції kind {#kind-functions}\n\nЄ дві функції видів: `kindOf` повертає вид обʼєкта.\n\n```go\nkindOf \"hello\"\n```\n\nВищезазначене поверне `string`. Для простих тестів (наприклад, у блоці `if`), функція `kindIs` дозволяє перевірити, що значення має певний вид:\n\n```go\nkindIs \"int\" 123\n```\n\nВищезазначене поверне `true`.\n\n### Type Functions\n\nТипи трохи складніше обробляти, тому є три різні функції:\n\n* `typeOf` повертає основний тип значення: `typeOf $foo`\n* `typeIs` подібна до `kindIs`, але для типів: `typeIs \"*io.Buffer\" $myVal`\n* `typeIsLike` працює як `typeIs`, але також розіменовує покажчики\n\n:::note\nЖодна з цих функцій не може перевірити, чи реалізує щось певний інтерфейс, оскільки це вимагало б компіляції інтерфейсу заздалегідь.\n:::\n\n### deepEqual\n\n`deepEqual` повертає `true`, якщо два значення є [\"глибоко рівними\"](https://golang.org/pkg/reflect/#DeepEqual).\n\nПрацює і для типів непримітивів (в порівнянні з вбудованим `eq`).\n\n```go\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\nВищезазначене поверне `true`.\n\n## Функції семантичного версіонування {#semantic-version-functions}\n\nSome version schemes are easily parseable and comparable. Helm Деякі схеми версій легко розпізнати та порівнювати. Helm надає функції для роботи з версіями [SemVer 2](https://semver.org/lang/uk/). До них відносяться [semver](#semver) і [semverCompare](#semvercompare). Нижче ви також знайдете деталі про використання діапазонів для порівнянь.\n\n### semver\n\nФункція `semver` розбирає рядок у семантичну версію:\n\n```go\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_Якщо синтаксичний аналізатор не спрацює, виконання шаблону буде зупинено з помилкою._\n\nНа цьому етапі `$version` є покажчиком на обʼєкт `Version` з наступними властивостями:\n\n* `$version.Major`: Основний номер (`1` вище)\n* `$version.Minor`: Мінорний номер (`2` вище)\n* `$version.Patch`: Номер патчу (`3` вище)\n* `$version.Prerelease`: Пре-реліз (`alpha.1` вище)\n* `$version.Metadata`: Метадані збірки (`123` вище)\n* `$version.Original`: Оригінальна версія у вигляді рядка\n\nКрім того, ви можете порівнювати `Version` з іншою версією, використовуючи функцію `Compare`:\n\n```go\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\nВищезазначене поверне `-1`.\n\nЗначення повернення такі:\n\n* `-1`, якщо дана версія SemVer більша за версію, метод `Compare` якої був викликаний\n* `1`, якщо версія, для якої була викликана функція `Compare`, більша\n* `0`, якщо версії однакові\n\n(Зверніть увагу, що в SemVer поле `Metadata` не порівнюється під час операцій порівняння версій.)\n\n### semverCompare\n\nБільш надійна функція порівняння надається як `semverCompare`. Ця версія підтримує діапазони версій:\n\n* `semverCompare \"1.2.3\" \"1.2.3\"` перевіряє на точний збіг\n* `semverCompare \"~1.2.0\" \"1.2.3\"` перевіряє, що основні та мінорні версії збігаються, і що номер патчу другої версії _більший або рівний_ першому параметру.\n\nФункції SemVer використовують бібліотеку [Masterminds semver](https://github.com/Masterminds/semver), від авторів Sprig.\n\n### Основні порівняння {#basic-comparisons}\n\nЄ два елементи порівнянь. По-перше, рядок порівняння є списком порівнянь з AND, розділених пробілом або комою. Ці порівняння потім розділяються операцією || (OR). Наприклад, `\">= 1.2 < 3.0.0 || >= 4.2.3\"` шукає порівняння, яке більше або дорівнює 1.2 і менше 3.0.0 або більше або дорівнює 4.2.3.\n\nОсновні порівняння:\n\n* `=`: рівно (аналогічно відсутності оператора)\n* `!=`: не рівно\n* `>`: більше ніж\n* `<`: менше ніж\n* `>=`: більше або рівно\n* `<=`: менше або рівно\n\n### Робота з версіями пре-релізів {#working-with-prerelease-versions}\n\nПре-релізи, для тих, хто не знайомий з ними, використовуються для випусків програмного забезпечення до стабільних або загальнодоступних випусків. Прикладами пре-релізів є розробка, альфа, бета та реліз-кандидат. Пре-реліз може бути версією, наприклад, `1.2.3-beta.1`, в той час як стабільний реліз буде `1.2.3`. За порядком пріоритету пре-релізи йдуть перед їх повʼязаними релізами. У цьому прикладі `1.2.3-beta.1 < 1.2.3`.\n\nЗгідно з специфікацією Semantic Version, пре-релізи можуть не відповідати API сумісності зі своїм релізом. Вона говорить,\n\n> Версія пре-релізу вказує, що версія нестабільна і може не відповідати запланованим вимогам сумісності, як зазначено у відповідній нормальній версії.\n\nПорівняння SemVer з використанням обмежень без компаратора пре-релізу пропустять пре-релізи. Наприклад, `>=1.2.3` пропустить пре-релізи при перегляді списку релізів, тоді як `>=1.2.3-0` буде оцінювати і знаходити пре-релізи.\n\nПричина для `0` як версії пре-релізу у прикладі порівняння полягає в тому, що пре-релізи можуть містити лише ASCII числа, літери та дефіси (разом з роздільниками `.`), згідно з специфікацією. Сортування відбувається в ASCII порядку сортування, згідно з специфікацією. Найнижчий символ — це `0` в ASCII порядку сортування (див. [ASCII Таблицю](http://www.asciitable.com/)).\n\nРозуміння ASCII порядку сортування важливе, оскільки A-Z йде перед a-z. Це означає, що `>=1.2.3-BETA` поверне `1.2.3-alpha`. Те, що ви могли б очікувати від чутливості до регістру, тут не застосовується. Це через ASCII порядок сортування, який зазначено у специфікації.\n\n### Порівняння діапазонів з дефісами {#hyphen-range-comparisons}\n\nЄ кілька методів обробки діапазонів, і перший — діапазони з дефісами. Вони виглядають так:\n\n* `1.2 - 1.4.5`, що еквівалентно `>= 1.2 <= 1.4.5`\n* `2.3.4 - 4.5`, що еквівалентно `>= 2.3.4 <= 4.5`\n\n### Підстановочні символи в порівняннях {#wildcard-in-comparisons}\n\nСимволи `x`, `X` та `*` можуть використовуватися як символи заміщення. Це працює для всіх операторів порівняння. Коли використовується з оператором `=`, він переходить до порівняння рівня патчу (див. тильду нижче). Наприклад,\n\n* `1.2.x` еквівалентно `>= 1.2.0, < 1.3.0`\n* `>= 1.2.x` еквівалентно `>= 1.2.0`\n* `<= 2.x` еквівалентно `< 3`\n* `*` еквівалентно `>= 0.0.0`\n\n### Порівняння діапазонів з тильдою (patch) {#tilde-range-comparisons-patch}\n\nОператор порівняння тильди (`~`) використовується для діапазонів рівня патчу, коли вказана мінорна версія, і для змін на рівні основної версії, коли мінорний номер відсутній. Наприклад,\n\n* `~1.2.3` еквівалентно `>= 1.2.3, < 1.3.0`\n* `~1` еквівалентно `>= 1, < 2`\n* `~2.3` еквівалентно `>= 2.3, < 2.4`\n* `~1.2.x` еквівалентно `>= 1.2.0, < 1.3.0`\n* `~1.x` еквівалентно `>= 1, < 2`\n\n### Порівняння діапазонів з кареткою (major) {#caret-range-comparisons-major}\n\nОператор порівняння каретка (`^`) використовується для змін на рівні основної версії після випуску стабільної (1.0.0) версії. До випуску 1.0.0 мінорні версії діють як рівень стабільності API. Це корисно при порівнянні версій API, оскільки велика зміна є порушенням API. Наприклад,\n\n* `^1.2.3` еквівалентно `>= 1.2.3, < 2.0.0`\n* `^1.2.x` еквівалентно `>= 1.2.0, < 2.0.0`\n* `^2.3` еквівалентно `>= 2.3, < 3`\n* `^2.x` еквівалентно `>= 2.0.0, < 3`\n* `^0.2.3` еквівалентно `>=0.2.3 <0.3.0`\n* `^0.2` еквівалентно `>=0.2.0 <0.3.0`\n* `^0.0.3` еквівалентно `>=0.0.3 <0.0.4`\n* `^0.0` еквівалентно `>=0.0.0 <0.1.0`\n* `^0` еквівалентно `>=0.0.0 <1.0.0`\n\n## Функції URL {#url-functions}\n\nHelm включає функції [urlParse](#urlparse), [urlJoin](#urljoin) і [urlquery](#urlquery), які дозволяють працювати з частинами URL.\n\n### urlParse\n\nРозбирає рядок для URL і створює словник з частинами URL\n\n```go\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\nВищезазначене повертає словник, що містить обʼєкт URL:\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nЦе реалізовано за допомогою пакетів URL з стандартної бібліотеки Go. Для отримання додаткової інформації перевірте https://golang.org/pkg/net/url/#URL\n\n### urlJoin\n\nОбʼєднує словник (створений за допомогою `urlParse`) для створення рядка URL\n\n```go\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\nВищезазначене поверне наступний рядок:\n\n```go\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nПовертає екрановану версію значення, переданого як аргумент, так що воно підходить для вбудовування в частину запиту URL.\n\n```go\n$var := urlquery \"string for query\"\n```\n\n## Функції UUID {#uuid-functions}\n\nHelm може генерувати UUID v4, унікальні ідентифікатори.\n\n```go\nuuidv4\n```\n\nВищезазначене повертає новий UUID типу v4 (згенерований випадковим чином).\n\n## Функції Kubernetes і Chart {#kubernetes-and-chart-functions}\n\nHelm включає функції для роботи з Kubernetes, зокрема [`.Capabilities.APIVersions.Has`](#capabilitiesapiversionshas), [Files](#file-functions) та [lookup](#lookup).\n\n### lookup\n\n`lookup` використовується для пошуку ресурсу в працюючому кластері. При використанні з командою `helm template` він завжди повертає порожній результат.\n\nБільше деталей можна знайти в [документації по функції lookup](/chart_template_guide/functions_and_pipelines.mdx#using-the-lookup-function).\n\n### .Capabilities.APIVersions.Has\n\nПовертає, чи доступна API-версія або ресурс у кластері.\n\n```go\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\nБільше інформації доступно в [документації по вбудованих обʼєктах](/chart_template_guide/builtin_objects.md).\n\n### Функції файлів {#file-functions}\n\nЄ кілька функцій, які дозволяють отримати доступ до не-спеціальних файлів всередині chart. Наприклад, для доступу до конфігураційних файлів програми. Ці функції документовані в [Доступ до файлів всередині шаблонів](/chart_template_guide/accessing_files.md).\n\n_Зверніть увагу, що документація для багатьох з цих функцій надходить з [Sprig](https://github.com/Masterminds/sprig). Sprig — це бібліотека функцій шаблонів, доступна для застосунків на Go._\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/functions_and_pipelines.mdx",
    "content": "---\ntitle: Функції шаблонів та конвеєри\ndescription: Використання функцій у шаблонах.\nsidebar_position: 5\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nДотепер ми бачили, як розміщувати інформацію в шаблоні. Але ця інформація розміщується в шаблоні без змін. Іноді ми хочемо перетворити надані дані таким чином, щоб вони були більш корисними для нас.\n\nПочнемо з найкращої практики: коли вставляємо рядки з об’єкта `.Values` у шаблон, ми повинні обов’язково обгорнути ці рядки в лапки. Ми можемо зробити це, викликавши функцію `quote` в директиві шаблону:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nФункції шаблонів дотримуються синтаксису `functionName arg1 arg2...`. У наведеному вище фрагменті `quote .Values.favorite.drink` викликає функцію `quote` і передає їй один аргумент.\n\nHelm має понад 60 доступних функцій. Деякі з них визначені [мовою шаблонів Go](https://godoc.org/text/template). Більшість інших є частиною [бібліотеки шаблонів Sprig](https://masterminds.github.io/sprig/). Ми побачимо багато з них у міру того, як будемо розглядати приклади.\n\n> Хоча ми говоримо про \"мову шаблонів Helm\", як про щось специфічне для Helm, насправді це комбінація мови шаблонів Go, деяких додаткових функцій і різноманітних обгорток, які дозволяють передавати певні обʼєкти в шаблони. Багато ресурсів про шаблони Go можуть бути корисними, коли ви вивчаєте шаблони.\n\n## Конвеєри {#pipelines}\n\nОднією з потужних функцій мови шаблонів є концепція _конвеєрів_. Запозичивши концепцію з UNIX, конвеєри є інструментом для обʼєднання серії команд шаблонів для компактного вираження низки перетворень. Іншими словами, конвеєри — це ефективний спосіб виконання кількох завдань послідовно. Перепишемо наведений вище приклад, використовуючи конвеєр.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nУ цьому прикладі замість виклику `quote ARGUMENT` ми інвертували порядок. Ми \"надіслали\" аргумент функції за допомогою конвеєра (`|`): `.Values.favorite.drink | quote`. Використовуючи конвеєри, ми можемо обʼєднати кілька функцій:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Інверсія порядку є поширеною практикою в шаблонах. Ви частіше побачите `.val | quote`, ніж `quote .val`. Обидві практики є правильними.\n\nПід час обробки цей шаблон створить такий результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nЗверніть увагу, що наша початкова `pizza` тепер перетворилася на `\"PIZZA\"`.\n\nКоли аргументи передаються за допомогою конвеєра, результат першого обчислення (`.Values.favorite.drink`) надсилається як _останній аргумент функції_. Ми можемо змінити приклад із напоєм вище, щоб продемонструвати функцію, яка приймає два аргументи: `repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nФункція `repeat` буде повторювати даний рядок задану кількість разів, тому ми отримаємо такий вихідний результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Використання функції `default` {#using-the-default-function}\n\nОднією з функцій, яку часто використовують у шаблонах, є функція `default`: `default DEFAULT_VALUE GIVEN_VALUE`. Ця функція дозволяє вам вказати стандартне значення в шаблоні, у разі якщо значення відсутнє. Використаємо її, щоб змінити приклад з напоєм вище:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nЯкщо ми запустимо це як зазвичай, ми отримаємо наш `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nТепер ми видалимо параметр улюбленого напою з `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nТепер повторний запуск `helm install --dry-run --debug fair-worm ./mychart` створить такий YAML:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nВ реальній схемі всі статичні стандартні значення повинні зберігатися у файлі `values.yaml` і не повинні дублюватися за допомогою команди `default` (інакше вони будуть надлишковими). Однак команда `default` ідеально підходить для обчислюваних значень, які не можуть бути оголошені у файлі `values.yaml`. Наприклад:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nУ деяких випадках умова `if` може бути кращим рішенням, ніж `default`. Ми побачимо їх у наступному розділі.\n\nФункції та конвеєри шаблонів — це потужний спосіб перетворення інформації та її вставки у ваш YAML. Але іноді необхідно додати деяку логіку шаблонів, яка трохи складніша, ніж просто вставка рядка. У наступному розділі ми розглянемо структури керування, які надає мова шаблонів.\n\n## Використання функції `lookup` {#using-the-lookup-function}\n\nФункцію `lookup` можна використовувати для _пошуку_ ресурсів у працюючому кластері. Синопсис функції lookup — це `lookup apiVersion, kind, namespace, name -> resource or resource list`.\n\n| параметр   | тип    |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\nЯк `name`, так і `namespace` є необовʼязковими і можуть бути передані як порожній рядок (`\"\"`). Однак, якщо ви працюєте з ресурсом, що належить до простору імен, необхідно вказати як `name`, так і `namespace`.\n\nМожливі такі комбінації параметрів:\n\n| Поведінка                              | Функція пошуку                             |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\nКоли `lookup` повертає обʼєкт, він поверне словник. Цей словник може бути додатково досліджений для отримання конкретних значень.\n\nНаступний приклад поверне анотації, присутні для обʼєкта `mynamespace`:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nКоли `lookup` повертає список обʼєктів, можливо отримати доступ до списку обʼєктів через поле `items`:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* робимо щось з кожним сервісом */}}\n{{ end }}\n```\n\nКоли обʼєкт не знайдено, повертається порожнє значення. Це може бути використано для перевірки наявності обʼєкта.\n\nФункція `lookup` використовує поточну конфігурацію зʼєднання Kubernetes Helm для запиту до Kubernetes. Якщо при взаємодії з викликом сервера API виникає помилка (наприклад, через відсутність дозволу на доступ до ресурсу), обробка шаблонів Helm зазнає невдачі.\n\nМайте на увазі, що Helm не призначений для контакту з Kubernetes API Server під час операцій `helm template|install|upgrade|delete|rollback --dry-run`. Щоб протестувати `lookup` на працюючому кластера, слід використовувати `helm template|install|upgrade|delete|rollback --dry-run=server`, щоб дозволити з’єднання з кластером.\n\n## Оператори як функції {#operators-are-functions}\n\nДля шаблонів оператори (`eq`, `ne`, `lt`, `gt`, `and`, `or` і так далі) реалізовані як функції. У конвеєрах операції можуть бути згруповані дужками (`(` і `)`).\n\nТепер ми можемо перейти від функцій і конвеєрів до управління потоком з умовами, циклами та модифікаторами області видимості.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Початок роботи\ndescription: Короткий посібник з шаблонів чартів\nsidebar_position: 2\n---\n\nУ цьому розділі посібника ми створимо чарт і додамо перший шаблон. Чарт, який ми створимо тут, буде використовуватися протягом усього цього посібника.\n\nЩоб розпочати, давайте швидко ознайомимося з чартом Helm.\n\n## Чарти {#charts}\n\nЯк описано в [Посібнику з чартів](/topics/charts.mdx), чарти Helm мають таку структуру:\n\n```none\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nТека `templates/` призначена для файлів шаблонів. Коли Helm обробляє чарт, він передає всі файли з теки `templates/` до механізму рендерингу шаблонів. Потім збирає результати цих шаблонів і передає їх до Kubernetes.\n\nФайл `values.yaml` також важливий для шаблонів. Цей файл містить _стандартні значення_ для чарту. Користувачі можуть перевизначити ці значення виконуючи `helm install` або `helm upgrade`.\n\nФайл `Chart.yaml` містить опис чарту. Ви можете отримати до нього доступ із шаблону.\n\nТека `charts/` _може_ містити інші чарти (які ми називаємо _субчартами_). Пізніше в цьому посібнику ми побачимо, як вони працюють під час рендерингу шаблонів.\n\n## Простий чарт {#a-starter-chart}\n\nУ цьому посібнику ми створимо простий чарт з назвою `mychart`, а потім створимо кілька шаблонів всередині чарту.\n\n```sh\n$ helm create mychart\nCreating mychart\n```\n\n### Швидкий огляд `mychart/templates/` {#a-quick-glimpse-of-mycharttemplates}\n\nЯкщо ви поглянете на теку `mychart/templates/`, то помітите кілька файлів, які вже там є.\n\n- `NOTES.txt`: Вміст тексту довідки для вашого чарту. Його буде показана користувачам під час виконання `helm install`.\n- `deployment.yaml`: Основний маніфест для створення [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) у Kubernetes.\n- `service.yaml`: Основний маніфест для створення [точки доступу сервісу](https://kubernetes.io/docs/concepts/services-networking/service/) для вашого deployment.\n- `_helpers.tpl`: Місце для розміщення допоміжних шаблонів, які ви можете використовувати повторно по всьому чарту.\n\nІ що ми збираємося зробити, це… _видалити їх усі!_ Таким чином, ми зможемо працювати з нашим посібником з нуля. Ми фактично створимо власні `NOTES.txt` та `_helpers.tpl` під час роботи.\n\n```sh\n$ rm -rf mychart/templates/*\n```\n\nКоли ви створюєте чарти промислового рівня, наявність базових версій цих чартів може бути дуже корисною. Тому під час щоденного створення чартів ви, ймовірно, не захочете їх видаляти.\n\n## Перший шаблон {#a-first-template}\n\nПерший шаблон, який ми створимо, буде `ConfigMap`. У Kubernetes ConfigMap — це просто об'єкт для зберігання даних конфігурації. Інші об'єкти, наприклад, pods, можуть отримувати доступ до даних у ConfigMap.\n\nОскільки ConfigMaps є базовими ресурсами, вони є для нас чудовою відправною точкою.\n\nПочнемо зі створення файлу з назвою `mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n:::tip\nІмена шаблонів не підпорядковуються жорстким правилам іменування. Однак ми рекомендуємо використовувати розширення `.yaml` для файлів YAML і `.tpl` для допоміжних файлів.\n:::\n\nВищезазначений файл YAML є базовим ConfigMap, що містить мінімально необхідні поля. Оскільки цей файл знаходиться в теці `mychart/templates/`, він буде переданий до рушія шаблонів.\n\nЦей простий файл YAML можна розмістити в теці `mychart/templates/`. Коли Helm прочитає цей шаблон, він просто надішле його до Kubernetes у незмінному вигляді.\n\nЗавдяки цьому простому шаблону ми тепер маємо чарт, який можна встановити. І ми можемо встановити\nйого наступним чином:\n\n```sh\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nЗа допомогою Helm ми можемо отримати реліз і побачити фактичний шаблон, який був завантажений.\n\n```sh\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nКоманда `helm get manifest` використовує імʼя релізу (`full-coral`) і виводить всі ресурси Kubernetes, які були завантажені на сервер. Кожен файл починається з `---`, що позначає початок документа YAML, а потім йде автоматично згенерований рядок коментаря, який повідомляє, який файл шаблону згенерував цей документ YAML.\n\nЗ цього моменту ми можемо побачити, що YAML-дані саме такі, як ми їх розмістили у файлі `configmap.yaml`.\n\nТепер ми можемо видалити наш реліз: `helm uninstall full-coral`.\n\n### Додавання простого виклику шаблону {#adding-a-simple-template-call}\n\nЖорстке кодування поля `name:` у ресурсі зазвичай вважається поганою практикою. Імена повинні бути унікальними для кожного релізу. Тому ми можемо захотіти згенерувати поле імені, вставивши назву релізу.\n\n:::info\nПоле `name:` обмежене 63 символами через обмеження системи DNS. З цієї причини імена релізів обмежені 53 символами. У Kubernetes версії 1.3 та раніше було обмежено лише 24 символами (тобто імена довжиною до 14 символів).\n:::\n\nЗмінимо файл `configmap.yaml` відповідно.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nОсновна зміна полягає в значенні поля `name:`, яке тепер має вигляд `{{ .Release.Name }}-configmap`.\n\n> Директива шаблону міститься у дужках `{{` та `}}`.\n\nДиректива шаблону `{{ .Release.Name }}` вставляє назву релізу в шаблон. Значення, які передаються в шаблон, можна вважати _обʼєктами в просторах імен_, де точка (`.`) розділяє кожен елемент простору імен.\n\nТочка перед `Release` вказує, що ми починаємо з найвищого простору імен для цієї області застосування (про область ми поговоримо трохи пізніше). Таким чином, ми могли б прочитати `Release.Name` як: \"почати з верхнього простору імен, знайти обʼєкт `Release`, а потім шукати всередині нього обʼєкт з назвою `Name`\".\n\nОбʼєкт `Release` є одним із вбудованих обʼєктів для Helm, і ми розглянемо його більш детально пізніше. Але поки достатньо сказати, що це покаже назву релізу, яку бібліотека присвоює нашому релізу.\n\nТепер, коли ми встановлюємо наш ресурс, ми одразу побачимо результат використання цієї директиви шаблону:\n\n```sh\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nВи можете запустити `helm get manifest clunky-serval`, щоб побачити весь згенерований YAML.\n\nЗверніть увагу, що ConfigMap всередині Kubernetes має назву `clunky-serval-configmap`, а не `mychart-configmap`, як раніше.\n\nНа цьому етапі ми розглянули найпростіші шаблони: файли YAML, що містять директиви шаблону, вкладені в `{{` та `}}`. У наступній частині ми детальніше розглянемо шаблони. Але перш ніж рухатися далі, є один швидкий трюк, який може пришвидшити створення шаблонів: якщо ви хочете протестувати рендеринг шаблону, але не встановлювати нічого, ви можете використати `helm install --debug --dry-run goodly-guppy ./mychart`. Ця команда рендерить шаблони. Але замість встановлення чарту, вона поверне вам опрацьований шаблон, щоб ви могли побачити результат:\n\n```sh\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nВикористання `--dry-run` полегшить тестування вашого коду, але це не гарантує, що сам Kubernetes прийме згенеровані вами шаблони. Краще не припускати, що ваш чарт буде встановлений тільки тому, що `--dry-run` працює.\n\nУ [Посібнику з шаблонів чарту](/chart_template_guide/index.mdx) ми розглянемо базовий чарт, який ми визначили тут, і детально дослідимо мову шаблонів Helm. І ми почнемо з вбудованих обʼєктів.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: Файл .helmignore\ndescription: Файл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт.\nsidebar_position: 12\n---\n\nФайл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт.\n\nЯкщо цей файл існує, команда `helm package` ігноруватиме всі файли, які відповідають шаблону, зазначеному у файлі `.helmignore`, під час упаковки вашого застосунку.\n\nЦе може допомогти уникнути додавання непотрібних або конфіденційних файлів або тек у ваш Helm чарт.\n\nФайл `.helmignore` підтримує глобальне зіставлення оболонки Unix, зіставлення відносних шляхів та заперечення (з префіксом !). Враховується лише один шаблон на рядок.\n\nОсь приклад файлу `.helmignore`:\n\n```none\n# коментар\n\n# Відповідає будь-якому файлу або шляху з імʼям .helmignore\n.helmignore\n\n# Відповідає будь-якому файлу або шляху з імʼям .git\n.git\n\n# Відповідає будь-якому текстовому файлу\n*.txt\n\n# Відповідає тільки текам з імʼям mydir\nmydir/\n\n# Відповідає тільки текстовим файлам на верхньому рівні теки\n/*.txt\n\n# Відповідає тільки файлу foo.txt в теці верхнього рівня\n/foo.txt\n\n# Відповідає будь-якому файлу з імʼям ab.txt, ac.txt або ad.txt\na[b-d].txt\n\n# Відповідає будь-якому файлу у субтеці subdir, що відповідає temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nДекілька важливих відмінностей від `.gitignore`:\n\n- Синтаксис '**' не підтримується.\n- Бібліотека globbing є Go's `filepath.Match`, а не `fnmatch(3)`.\n- Пробіли на кінці ігноруються завжди (немає підтримки екранованих послідовностей).\n- Немає підтримки '\\!' як спеціальної початкової послідовності.\n- Файл `.helmignore` стандартно не виключає себе, потрібно додати явний запис для `.helmignore`.\n\n**Ми будемо вдячні за вашу допомогу** у покращенні цього документа. Щоб додати, виправити або видалити інформацію, [відкрийте тікет](https://github.com/helm/helm-www/issues) або надішліть нам запит на внесення змін.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/index.mdx",
    "content": "---\ntitle: Шаблони чартів\nsidebar_position: 5\n---\n\n# Посібник розробника шаблонів чартів\n\nЦей посібник надає введення в шаблони чартів Helm, з акцентом на мову шаблонів.\n\nШаблони генерують файли маніфестів, які є описами ресурсів у форматі YAML, зрозумілому для Kubernetes. Ми розглянемо, як побудовані шаблони, як їх можна використовувати, як створювати шаблони Go та як відлагоджувати свою роботу.\n\nЦей посібник зосереджується на таких поняттях:\n\n- Мова шаблонів Helm\n- Використання значень\n- Техніки роботи з шаблонами\n\nЦей посібник орієнтований на вивчення особливостей мови шаблонів Helm. Інші посібники надають вступні матеріали, приклади та найкращі практики.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Іменовані шаблони\ndescription: Як визначити іменовані шаблони.\nsidebar_position: 9\n---\n\nПора перейти від одного шаблону до створення інших. У цьому розділі ми побачимо, як визначити _іменовані шаблони_ в одному файлі, а потім використовувати їх в інших місцях. _Іменований шаблон_ (іноді його називають _partial_ або _субшаблоном_) — це просто шаблон, визначений у файлі, якому надали імʼя. Ми розглянемо два способи створення таких шаблонів і кілька способів їх використання.\n\nУ розділі [Керування потоком](/chart_template_guide/control_structures.md) ми представили три дії для оголошення та управління шаблонами: `define`, `template` і `block`. У цьому розділі ми розглянемо ці три дії, а також введемо спеціальну функцію `include`, яка працює подібно до дії `template`.\n\nВажлива деталь, яку слід памʼятати при іменуванні шаблонів: **імена шаблонів є глобальними**. Якщо ви оголосите два шаблони з однаковим імʼям, використовуватиметься той, який був завантажений останнім. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, слід бути обережним при іменуванні шаблонів, використовуючи _імена, специфічні для чарту_.\n\nПопулярним способом іменування є префіксування кожного визначеного шаблону іменем чарту: `{{ define \"mychart.labels\" }}`. Використовуючи конкретне імʼя чарту як префікс, ми можемо уникнути будь-яких конфліктів, які можуть виникнути через два різних чарти, що реалізують шаблони з однаковим іменем.\n\nЦя поведінка також стосується різних версій чарту. Якщо у вас є `mychart` версії `1.0.0`, яка визначає шаблон одним способом, і `mychart` версії `2.0.0`, яка змінює наявний іменований шаблон, буде використовуватися той, який був завантажений останнім. Ви можете обійти цю проблему, додавши версію в імʼя чарту: `{{ define \"mychart.v1.labels\" }}` та `{{ define \"mychart.v2.labels\" }}`.\n\n## Файли partials та `_` {#partials-and-_files}\n\nДо цього часу ми використовували один файл, і цей один файл містив один шаблон. Але мова шаблонів Helm дозволяє створювати іменовані вкладені шаблони, до яких можна звертатися за іменем в інших місцях.\n\nПеред тим як перейти до деталей написання цих шаблонів, варто згадати про правила іменування файлів:\n\n* Більшість файлів у `templates/` обробляються як файли з маніфестами Kubernetes\n* `NOTES.txt` є винятком\n* Але файли, імʼя яких починається з підкреслення (`_`), вважаються такими, що _не мають_ маніфесту всередині. Ці файли не перетворюються на обʼєкти Kubernetes, але доступні в інших шаблонах чартів для використання.\n\nЦі файли використовуються для зберігання часток шаблонів і допоміжних функцій. Насправді коли ми вперше створили `mychart`, ми бачили файл з назвою `_helpers.tpl`. Цей файл є стандартним місцем для часток шаблонів.\n\n## Оголошення та використання шаблонів з `define` та `template` {#declaring-and-using-templates-with-define-and-template}\n\nДія `define` дозволяє створювати іменовані шаблони всередині файлу шаблону. Її синтаксис виглядає так:\n\n```go\n{{- define \"MY.NAME\" }}\n  # тіло шаблону тут\n{{- end }}\n```\n\nНаприклад, ми можемо визначити шаблон для інкапсуляції блоку міток Kubernetes:\n\n```go\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nТепер ми можемо вбудувати цей шаблон всередині нашого наявного ConfigMap і включити його за допомогою дії `template`:\n\n```go\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nКоли рушій шаблонів читає цей файл, він зберігає посилання на `mychart.labels` до того часу, поки не буде викликано `template \"mychart.labels\"`. Тоді він рендерить цей шаблон безпосередньо. Результат виглядатиме так:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\n:::note\n`define` не створює виводу, якщо не буде викликано шаблон, як у цьому прикладі.\n:::\n\nЗазвичай шаблони Helm розміщують у файлах часток шаблонів, зазвичай у `_helpers.tpl`. Перенесемо цю функцію туди:\n\n```go\n{{/* Генерація базових міток */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nЗгідно з домовленостями, функції `define` повинні мати простий блок документації (`{{/* ... */}}`), що описує їх призначення.\n\nНавіть якщо це визначення знаходиться в `_helpers.tpl`, його все ще можна використовувати в `configmap.yaml`:\n\n```go\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nЯк уже згадувалося, **імена шаблонів є глобальними**. В результаті, якщо два шаблони оголошені з однаковим імʼям, буде використано останній варіант. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, краще давати шаблонам _специфічні для чарту імена_. Популярний спосіб іменування — це префіксувати кожен визначений шаблон іменем чарту: `{{ define \"mychart.labels\" }}`.\n\n## Встановлення області видимості шаблону {#setting-the-scope-of-a-template}\n\nУ шаблоні, який ми визначили вище, ми не використовували жодних обʼєктів. Ми просто використовували функції. Змінимо наш визначений шаблон, щоб включити назву чарту та версію чарту:\n\n```go\n{{/* Генерація базових міток */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nЯкщо ми його відрендеримо, ми отримаємо помилку, схожу на цю:\n\n```sh\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nЩоб побачити, що було відрендерено, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Результат не буде таким, як ми очікували:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\nЩо сталося з назвою та версією? Вони не були в області видимості для нашого визначеного шаблону. Коли іменований шаблон (створений за допомогою `define`) рендериться, він отримує область видимості, передану через виклик `template`. У нашому прикладі ми включили шаблон ось так:\n\n```go\n{{- template \"mychart.labels\" }}\n```\n\nОбласть видимості не була передана, тому в шаблоні ми не можемо отримати доступ до чогось в `.`. Однак це легко виправити. Ми просто передаємо область видимості в шаблон:\n\n```go\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nЗверніть увагу, що ми передаємо `.` в кінці виклику `template`. Ми могли б так само легко передати `.Values` або `.Values.favorite`, або будь-яку іншу область видимості, яку хочемо. Але те, що нам потрібно, це область видимості верхнього рівня.\n\nТепер, коли ми виконаємо цей шаблон з `helm install --dry-run --debug plinking-anaco ./mychart`, ми отримаємо таке:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nТепер `{{ .Chart.Name }}` стає `mychart`, а `{{ .Chart.Version }}` стає `0.1.0`.\n\n## Функція `include` {#the-include-function}\n\nПрипустимо, ми визначили простий шаблон, який виглядає ось так:\n\n```go\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nТепер припустимо, я хочу вставити це як в розділ `labels:`, так і в розділ `data:`:\n\n```go\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nЯкщо ми це відрендеримо, ми отримаємо помилку, схожу на цю:\n\n```sh\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nЩоб побачити, що було відрендеровано, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. Вихідні дані не будуть такими, як ми очікували:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nЗверніть увагу, що відступ на `app_version` неправильний в обох місцях. Чому? Тому що шаблон, який вставляється, має текст вирівняний по лівому краю. Оскільки `template` є дією, а не функцією, немає способу передати вихідний результат виклику `template` іншим функціям; дані просто вставляються в рядок.\n\nЩоб обійти цю проблему, Helm надає альтернативу `template`, яка імплементує вміст шаблону в поточний конвеєр, де він може бути переданий іншим функціям у конвеєрі.\n\nОсь приклад вище, виправлений з використанням `indent`, щоб правильно відступити шаблон `mychart.app`:\n\n```go\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nТепер створений YAML має вірний відступ для кожного розділу:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> Вважається за краще використовувати `include` замість `template` у шаблонах Helm, щоб краще керувати форматуванням виводу для YAML-документів.\n\nІноді ми хочемо імплементувати вміст, але не як шаблони. Тобто, ми хочемо імплементувати файли без змін. Ми можемо досягти цього, звертаючись до файлів через обʼєкт `.Files`, описаний у наступному розділі.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Створення файлу NOTES.txt\ndescription: Як надати інструкції користувачам вашого чарту.\nsidebar_position: 10\n---\n\nУ цьому розділі ми розглянемо інструмент Helm для надання інструкцій користувачам вашого чарту. Після виконання `helm install` або `helm upgrade` Helm може вивести блок корисної інформації для користувачів. Цю інформацію можна налаштувати за допомогою шаблонів.\n\nЩоб додати нотатки по установці до вашого чарту, просто створіть файл `templates/NOTES.txt`. Цей файл є звичайним текстовим файлом, але обробляється як шаблон і має всі звичайні функції та обʼєкти шаблонів.\n\nСтворимо простий файл `NOTES.txt`:\n\n```go\nДякуємо за встановлення {{ .Chart.Name }}.\n\nВаш реліз називається {{ .Release.Name }}.\n\nЩоб дізнатися більше про реліз, спробуйте:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nТепер, якщо ми виконаємо `helm install rude-cardinal ./mychart`, ми побачимо це повідомлення внизу:\n\n```none\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nДякуємо за встановлення mychart.\n\nВаш реліз називається rude-cardinal.\n\nЩоб дізнатися більше про реліз, спробуйте:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nВикористання `NOTES.txt` таким чином є чудовим способом надати вашим користувачам детальну інформацію про те, як використовувати новостворений чарт. Створення файлу `NOTES.txt` наполегливо рекомендується, хоча це і не є обовʼязковим.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Субчарти та глобальні значення\ndescription: Взаємодія з значеннями субчартів і глобальними значеннями.\nsidebar_position: 11\n---\n\nДо цього моменту ми працювали тільки з одним чартом. Але чарти можуть мати залежності, які називаються _субчартами_, що також мають свої власні значення і шаблони. У цьому розділі ми створимо субчарт і розглянемо різні способи доступу до значень зсередини шаблонів.\n\nПеред тим, як перейти до коду, є кілька важливих деталей, які слід знати про субчарти:\n\n1. Субчарт вважається \"автономним\", що означає, що субчарт ніколи не може прямо залежати від батьківського чарту.\n2. Тому субчарт не може отримувати доступ до значень свого пращура.\n3. Батьківський чарт може перевизначати значення для субчартів.\n4. Helm має концепцію _глобальних значень_, які можуть бути доступні всім чартам.\n\n> Ці обмеження не завжди застосовуються до [бібліотечних чартів](/topics/library_charts.md), які розроблені для надання стандартної функціональності.\n\nПід час роботи з прикладами в цьому розділі ці концепції стануть зрозумілішими.\n\n## Створення субчарту {#creating-a-subchart}\n\nДля цих вправ ми почнемо з чарту `mychart/`, який ми створили на початку цього посібника, і додамо новий чарт всередину його.\n\n```sh\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nЗверніть увагу, що ми видалили всі базові шаблони, щоб почати з нуля. У цьому посібнику ми зосереджені на тому, як працюють шаблони, а не на управлінні залежностями. Але [Посібник з Чартів](/topics/charts.mdx) містить більше інформації про те, як працюють субчарти.\n\n## Додавання значень та шаблону до субчарту {#adding-values-and-a-template-to-the-subchart}\n\nДалі створимо простий шаблон і файл значень для чарту `mysubchart`. У `mychart/charts/mysubchart` вже має бути файл `values.yaml`. Налаштуємо його так:\n\n```yaml\ndessert: cake\n```\n\nДалі створимо новий шаблон ConfigMap у `mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```go\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nОскільки кожен субчарт є _самостіним чартом_, ми можемо протестувати `mysubchart` окремо:\n\n```sh\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Перевизначення значень з батьківського чарту {#overriding-values-from-a-parent-chart}\n\nНаш оригінальний чарт, `mychart`, тепер є _батьківським_ чартом для `mysubchart`. Ці стосунки базується виключно на тому, що `mysubchart` знаходиться в `mychart/charts`.\n\nОскільки `mychart` є батьківським чартом, ми можемо вказати конфігурацію в `mychart` і передати цю конфігурацію в `mysubchart`. Наприклад, ми можемо змінити `mychart/values.yaml` таким чином:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nЗверніть увагу на останні два рядки. Будь-які директиви всередині секції `mysubchart` будуть передані в чарт `mysubchart`. Отже, якщо ми виконаємо `helm install --generate-name --dry-run --debug mychart`, однією з речей, які ми побачимо, буде ConfigMap `mysubchart`:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nЗначення на верхньому рівні тепер замінило значення субчарту.\n\nТут слід звернути увагу на важливу деталь. Ми не змінювали шаблон `mychart/charts/mysubchart/templates/configmap.yaml`, щоб він вказував на `.Values.mysubchart.dessert`. З точки зору цього шаблону, значення все ще знаходиться в `.Values.dessert`. Коли рушій шаблонів передає значення, він встановлює область дії. Тому для шаблонів `mysubchart` у `.Values` будуть доступні тільки значення, що стосуються конкретно `mysubchart`.\n\nОднак іноді ви хочете, щоб певні значення були доступні для всіх шаблонів. Це можна зробити за допомогою глобальних значень чартів.\n\n## Глобальні значення чарту {#global-chart-values}\n\nГлобальні значення — це значення, до яких можна отримати доступ з будь-якого ччарту або субчарту за допомогою однакового імені. Глобальні значення вимагають явного оголошення. Ви не можете використовувати існуюче неглобальне значення так, ніби воно є глобальним.\n\nТип даних Values має зарезервовану секцію `Values.global`, де можна задати глобальні значення. Визначимо одне в нашому файлі `mychart/values.yaml`.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nЗавдяки способу роботи глобальних значень, як `mychart/templates/configmap.yaml`, так і `mysubchart/templates/configmap.yaml` повинні мати змогу отримати це значення як `{{ .Values.global.salad }}`.\n\n`mychart/templates/configmap.yaml`:\n\n```go\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```go\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nТепер, якщо ми протестуємо установку в режимі dry run, ми побачимо одне й те ж значення в обох виводах:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nГлобальні значення корисні для передачі такої інформації, хоча це вимагає певного планування, щоб переконатися, що правильні шаблони налаштовані для використання глобальних значень.\n\n## Поширення шаблонів з субчартами {#sharing-templates-with-subcharts}\n\nБатьківські чарти та субчарти можуть ділитися шаблонами. Будь-який визначений блок у будь-якому чарті доступний іншим чартам.\n\nНаприклад, ми можемо визначити простий шаблон таким чином:\n\n```go\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nЗгадайте, як мітки в шаблонах є _глобально спільними_. Отже, шаблон `labels` можна включити з будь-якого іншого чарту.\n\nХоча розробники чартів можуть вибирати між `include` та `template`, однією з переваг використання `include` є те, що `include` може динамічно посилатися на шаблони:\n\n```go\n{{ include $mytemplate }}\n```\n\nThe above will dereference `$mytemplate`. The `template` function, in contrast,\nwill only accept a string literal.\n\n## Уникнення використання блоків {#avoid-using-blocks}\n\nМова шаблонів Go надає ключове слово `block`, яке дозволяє розробникам надавати стандартну реалізацію, яка згодом замінюється. У чартах Helm блоки не є найкращим інструментом для заміни, оскільки якщо надано кілька реалізацій одного і того ж блоку, вибір конкретної реалізації є непередбачуваним.\n\nЗамість цього рекомендується використовувати `include`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/values_files.mdx",
    "content": "---\ntitle: Файли значень\ndescription: Інструкції щодо використання прапорця --values.\nsidebar_position: 4\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nУ попередньому розділі ми розглянули вбудовані обʼєкти, які пропонують шаблони Helm. Один з вбудованих обʼєктів — це `Values`. Цей обʼєкт надає доступ до значень, переданих у шаблон. Його вміст походить з кількох джерел:\n\n- Файл `values.yaml` у чарті\n- Якщо це субчарт, файл `values.yaml` батьківського чарту\n- Файл значень передається в `helm install` або `helm upgrade` з прапорцем `-f` (`helm install -f myvals.yaml ./mychart`)\n- Окремі параметри передаються за допомогою `--set` (наприклад, `helm install --set foo=bar ./mychart`)\n\nВищезазначений список наведений у порядку специфічності: `values.yaml` є стандартним, який може бути замінений файлом `values.yaml` батьківського чарту, який, у свою чергу, може бути замінений файлом значень, наданим користувачем, який, у свою чергу, може бути замінений параметрами `--set`.\n\nФайли значень є простими файлами YAML. Давайте відредагуємо `mychart/values.yaml`, а потім відредагуємо наш шаблон ConfigMap.\n\nВидаливши стандартні значення у `values.yaml`, ми встановимо лише один параметр:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nТепер ми можемо використовувати його всередині шаблону:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nЗверніть увагу, що в останньому рядку ми отримуємо доступ до `favoriteDrink` як до атрибута `Values`: `{{ .Values.favoriteDrink }}`.\n\nПодивімося, як це відобразиться.\n\n```sh\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nОскільки `favoriteDrink` встановлено в стандартне значення у файлі `values.yaml` як `coffee`, це значення відображається в шаблоні. Ми можемо легко перевизначити його, додавши прапорець `--set` у наш виклик `helm install`:\n\n```sh\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nОскільки `--set` має вищий пріоритет, ніж файл `values.yaml`, наш шаблон генерує `drink: slurm`.\n\nФайли значень також можуть містити більш структурований контент. Наприклад, ми могли б створити розділ `favorite` у нашому файлі `values.yaml`, а потім додати туди кілька ключів:\nthere:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nТепер нам потрібно трохи змінити шаблон:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nХоча структурування даних таким чином є можливим, рекомендується зберігати дерева значень неглибокими, віддаючи перевагу пласким структурам. Коли ми розглянемо присвоєння значень субчартам, ми побачимо, як значення називаються, використовуючи структуру дерева.\n\n## Видалення стандартного ключа {#deleting-a-default-key}\n\nЯкщо вам потрібно видалити ключ зі стандартних значень, ви можете перевизначити значення ключа як `null`, у цьому випадку Helm видалить ключ з злиття перевизначених значень.\n\nНаприклад, стабільний шаблон Drupal дозволяє налаштовувати перевірку життєздатності (liveness probe) у випадку, якщо ви налаштовуєте власний образ. Ось стандартні значення:\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nЯкщо ви спробуєте перевизначити обробник livenessProbe на `exec` замість `httpGet`, використовуючи `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm обʼєднає стандартні ключі разом з перевизначеними, що дасть нам наступний YAML:\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nОднак Kubernetes тоді видасть помилку, оскільки не можна оголошувати більше одного обробника livenessProbe. Щоб це обійти, ви можете інструктувати Helm видалити `livenessProbe.httpGet`, встановивши його значення в null:\n\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nНа цьому етапі ми розглянули кілька вбудованих обʼєктів і використали їх для вставки інформації в шаблон. Тепер ми розглянемо інший аспект рушія шаблонів: функції та конвеєри.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/variables.md",
    "content": "---\ntitle: Змінні\ndescription: Використання змінних у шаблонах.\nsidebar_position: 8\n---\n\nМаючи функції, конвеєри, обʼєкти та структури управління, ми можемо перейти до однієї з основних ідей у багатьох мовах програмування: змінних. У шаблонах вони використовуються рідше. Але ми побачимо, як їх можна використовувати для спрощення коду та для кращого використання `with` і `range`.\n\nУ попередньому прикладі ми побачили, що цей код не працює:\n\n```go\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` не знаходиться в межах області видимості, обмеженої блоком `with`. Один зі способів обійти проблеми з областю видимості — присвоїти обʼєкти змінним, до яких можна отримати доступ без врахування поточної області видимості.\n\nУ шаблонах Helm змінна є іменованим посиланням на інший обʼєкт. Вона має формат `$name`. Змінні присвоюються за допомогою спеціального оператора присвоєння: `:=`. Ми можемо переписати вищезазначене, використовуючи змінну для `Release.Name`.\n\n```go\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nЗверніть увагу, що перед тим як почати блок `with`, ми присвоюємо `$relname := .Release.Name`. Тепер всередині блоку `with` змінна `$relname` все ще вказує на імʼя релізу.\n\nЗапуск цього коду дасть наступний результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nЗмінні особливо корисні в циклах `range`. Їх можна використовувати для спископодібних обʼєктів, щоб захопити як індекс, так і значення:\n\n```go\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nЗверніть увагу, що `range` йде першим, потім змінні, потім оператор присвоєння, а потім список. Це присвоїть ціле число (починаючи з нуля) змінній `$index` і значення змінній `$topping`. Запуск цього коду дасть:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nДля структур даних, які мають як ключ, так і значення, ми можемо використовувати `range`, щоб отримати обидва. Наприклад, ми можемо перебрати `.Values.favorite` таким чином:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nТепер на першій ітерації `$key` буде `drink`, а `$val` буде `coffee`, а на другій `$key` буде `food`, а `$val` буде `pizza`. Запуск цього коду створить:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nЗмінні зазвичай не є \"глобальними\". Вони мають область видимості в межах блоку, в якому вони оголошені. Раніше ми присвоїли `$relname` на верхньому рівні шаблону. Ця змінна буде видима для всього шаблону. Але в нашому останньому прикладі змінні `$key` і `$val` будуть видимі лише всередині блоку `{{ range... }}{{ end }}`.\n\nОднак є одна змінна, яка завжди є глобальною — `$`, ця змінна завжди буде вказувати на кореневий контекст. Це може бути дуже корисно, коли ви перебираєте в діапазоні і вам потрібно знати імʼя релізу чарту.\n\nПриклад, що ілюструє це:\n\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Багато шаблонів Helm використовували б `.` тут, але це не спрацює,\n    # однак `$` спрацює тут\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # Я не можу звертатися до .Chart.Name, але можу використовувати $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Значення з appVersion у Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nДо цього часу ми розглянули лише один шаблон, оголошений в одному файлі. Але одна з потужних можливостей мови шаблонів Helm — це можливість оголошувати кілька шаблонів і використовувати їх разом. Ми перейдемо до цього в наступному розділі.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Наступні кроки\ndescription: \"Підсумок — корисні вказівки на іншу документацію, яка може допомогти вам.\"\nsidebar_position: 14\n---\n\nЦей посібник призначений для того, щоб дати вам, розробнику чартів, глибоке розуміння того, як використовувати мову шаблонів Helm. Посібник зосереджується на технічних аспектах розробки шаблонів.\n\nОднак є багато речей, які цей посібник не охоплює, коли йдеться про практичну щоденну розробку чартів. Ось кілька корисних посилань на іншу документацію, яка допоможе вам під час створення нових чартів:\n\n- CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є незамінним джерелом чартів.\n- [Документація Kubernetes](https://kubernetes.io/docs/home/) надає детальні приклади різних ресурсів, які ви можете використовувати, від ConfigMaps і Secrets до DaemonSets і Deployments.\n- Посібник [Чарти Helm](/topics/charts.mdx) пояснює робочий процес використання чартів.\n- Посібник [Хуки чартів Helm](/topics/charts_hooks.md) пояснює, як створювати хуки життєвого циклу.\n- Стаття [Поради та підказки для розробки чартів](/howto/charts_tips_and_tricks.md) надає кілька корисних порад для написання чартів.\n- Документація [Sprig](https://github.com/Masterminds/sprig) описує більше ніж шістдесят функцій шаблонів.\n- Документація [Go templates](https://godoc.org/text/template) детально пояснює синтаксис шаблонів.\n- Інструмент [Schelm](https://github.com/databus23/schelm) є корисною утилітою для налагодження чартів.\n\nІноді легше поставити кілька запитань і отримати відповіді від досвідчених розробників. Найкраще місце для цього — канали Helm у [Slack Kubernetes](https://kubernetes.slack.com):\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nНарешті, якщо ви знайдете помилки або упущення в цьому документі, хочете запропонувати новий контент або хотіли б внести зробити внесок, відвідайте [The Helm Project](https://github.com/helm/helm-www).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Додаток: Техніки YAML\"\ndescription: Ближчий погляд на специфікацію YAML та її застосування в Helm.\nsidebar_position: 15\n---\n\nБільшість цього посібника зосереджена на мові шаблонів. Тут ми розглянемо формат YAML. YAML має кілька корисних функцій, які ми, як автори шаблонів, можемо використовувати для того, щоб зробити наші шаблони менш схильними до помилок і легшими для читання.\n\n## Масиви та Колекції {#scalars-and-collections}\n\nЗгідно зі [специфікацією YAML](https://yaml.org/spec/1.2/spec.html), існують два типи колекцій та багато типів скалярів.\n\nДва типи колекцій — це map та послідовності:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nСкалярні значення – це окремі значення (на відміну від колекцій).\n\n### Типи скалярів у YAML {#scalar-types-in-yaml}\n\nУ діалекті YAML від Helm тип скалярних даних значення визначається складною сукупністю правил, включаючи схему Kubernetes для визначень ресурсів. Але при виведенні типів, як правило, діють наступні правила.\n\nЯкщо ціле число або число з рухомою комою є словом без лапок, воно зазвичай розглядається як числовий тип:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nАле якщо вони укладені в лапки, вони трактуються як рядки:\n\n```yaml\ncount: \"1\" # <-- рядок, не int\nsize: '2.34' # <-- рядок, не float\n```\n\nТе ж саме стосується булевих значень:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # рядок\n```\n\nСлово для порожнього значення — `null` (не `nil`).\n\nЗверніть увагу, що `port: \"80\"` є дійсним YAML і пройде через рушій шаблонів та парсер YAML, але зазнає невдачі, якщо Kubernetes очікує, що `port` буде цілим числом.\n\nУ деяких випадках ви можете примусово визначити певний тип, використовуючи теґи вузлів YAML:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nУ наведеному вище прикладі `!!str` говорить парсеру, що `age` є рядком, навіть якщо він виглядає як int. А `port` трактуватиметься як int, навіть якщо він укладений в лапки.\n\n## Рядки в YAML {#strings-in-yaml}\n\nБільшість даних, які ми розміщуємо в документах YAML, є рядками. YAML має кілька способів представлення рядків. Цей розділ пояснює способи та демонструє, як використовувати деякі з них.\n\nІснують три \"вбудовані\" способи оголошення рядка:\n\n```yaml\nway1: просто слова\nway2: \"рядки в подвійних лапках\"\nway3: 'рядки в одинарних лапках'\n```\n\nВсі вбудовані стилі мають бути в одному рядку.\n\n- Невкладені слова не мають лапок і не екрановані. Тому потрібно бути обережним із символами, які ви використовуєте.\n- Рядки в подвійних лапках можуть мати спеціальні символи екрановані за допомогою `\\`. Наприклад, `\"\\\"Hello\\\", she said\"`. Можна екранувати розриви рядка за допомогою `\\n`.\n- Рядки в одинарних лапках є \"літеральними\" рядками та не використовують `\\` для екранування символів. Єдине екранування — це `''`, яке декодується як один символ `'`.\n\nОкрім рядків в один рядок, можна оголосити багаторядкові рядки:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nВищенаведене буде трактувати значення `coffee` як один рядок, еквівалентний `Latte\\nCappuccino\\nEspresso\\n`.\n\nЗверніть увагу, що перший рядок після `|` повинен мати вірний відступ. Тому ми можемо зламати приклад вище, зробивши це:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nОскільки `Latte` має неправильний відступ, ми отримаємо помилку на кшталт:\n\n```none\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nУ шаблонах іноді безпечніше помістити несправжній \"перший рядок\" у багаторядковому документі лише для захисту від цієї помилки:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nЗауважте, що яким би не був цей перший рядок, його буде збережено у виведенні рядка. Тому, якщо ви, наприклад, використовуєте цю техніку для вливання вмісту файлу в ConfigMap, коментар має бути типу, який очікується тим, хто читає цей запис.\n\n### Керування пробілами в багаторядкових рядках {#controlling-spaces-in-multiline-strings}\n\nУ наведеному вище прикладі ми використовували `|`, щоб позначити багаторядковий рядок. Але зверніть увагу, що вміст нашого рядка завершувався з кінцевим `\\n`. Якщо ми хочемо, щоб обробник YAML видалив кінцевий перенос рядка, ми можемо додати `-` після `|`:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nТепер значення `coffee` буде: `Latte\\nCappuccino\\nEspresso` (без кінцевого `\\n`).\n\nВ інших випадках ми можемо захотіти зберегти весь кінцевий пробіл. Ми можемо зробити це за допомогою позначення `|+`:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nТепер значення `coffee` буде `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nВідступи всередині текстового блоку зберігаються, що призводить до збереження переносу рядків:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nУ наведеному вище випадку значення `coffee` буде `Latte\\n  12 oz\\n  16 oz\\nCappuccino\\nEspresso`.\n\n### Відступи та шаблони {#indenting-and-templates}\n\nКоли ви пишете шаблони, ви можете захотіти вставити вміст файлу в шаблон. Як ми бачили в попередніх розділах, є два способи зробити це:\n\n- Використовуйте `{{ .Files.Get \"FILENAME\" }}`, щоб отримати вміст файлу в чартах.\n- Використовуйте `{{ include \"TEMPLATE\" . }}`, щоб відобразити шаблон, а потім вставити його вміст у чарти.\n\nКоли ви вставляєте файли в YAML, корисно розуміти правила багаторядкових рядків. Найчастіше найпростіший спосіб вставити статичний файл — зробити щось на кшталт цього:\n\n```go\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nЗверніть увагу, як ми робимо відступ вище: `indent 2` вказує рушію шаблонів зробити відступ у два пробіли в кожному рядку файлу «myfile.txt». Зверніть увагу, що ми не робимо відступ у цьому рядку шаблону. Це тому, що якщо ми це зробимо, вміст першого рядка файлу буде відступлений двічі.\n\n### Згортання багаторядкових рядків {#folded-multi-line-strings}\n\nІноді вам потрібно представити рядок у вашому YAML на кількох рядках, але ви хочете, щоб він трактувався як один довгий рядок під час інтерпретації. Це називається \"згортанням\". Щоб оголосити згортання блоку, використовуйте `>` замість `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nЗначення `coffee` буде `Latte Cappuccino Espresso\\n`. Зверніть увагу, що всі, крім останнього переносу рядка, будуть перетворені на пробіли. Ви можете поєднувати контроль пробілів із позначкою згортання тексту, тому `>-` замінить або обрізає всі нові рядки.\n\nЗверніть увагу, що в згортанні синтаксису відступ тексту призведе до збереження рядків.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nНаведене вище створить `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Зверніть увагу, що і пробіли, і нові рядки все ще присутні.\n\n## Вбудовування кількох документів в один файл {#embedding-multiple-documents-in-one-file}\n\nМожливо розмістити більше одного YAML-документа в одному файлі. Це робиться шляхом префіксації нового документа `---` і закінчення документа `...`\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nУ багатьох випадках можна опустити `---` або `...`.\n\nДеякі файли в Helm не можуть містити більше одного документа. Якщо, наприклад, у файлі `values.yaml` надано більше одного документа, буде використано лише перший.\n\nОднак файли шаблонів можуть мати більше одного документа. Коли це трапляється, файл (і всі його документи) обробляється як один обʼєкт під час рендерингу шаблонів. Але потім отриманий YAML розділяється на кілька документів, перш ніж він буде переданий Kubernetes.\n\nМи рекомендуємо використовувати кілька документів у файлі лише в разі крайньої потреби. Наявність кількох документів у файлі може ускладнити налагодження.\n\n## YAML є надмножиною JSON {#yaml-is-a-superset-of-json}\n\nОскільки YAML є надмножиною JSON, будь-який дійсний JSON-документ _повинен_ бути дійсним YAML.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nВищенаведене є іншим способом представлення цього:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nІ їх можна змішувати (з обережністю):\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nУсі три повинні перетворюватись в однакове внутрішнє подання.\n\nЦе означає, що файли, такі як `values.yaml`, можуть містити дані JSON, але Helm не трактує розширення файлу `.json` як дійсний суфікс.\n\n## Якорі YAML {#yaml-anchors}\n\nСпецифікація YAML надає спосіб зберігати посилання на значення і пізніше посилатися на це значення за допомогою посилання. YAML називає це \"якорінням\":g\":\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nУ наведеному вище прикладі `&favoriteCoffee` встановлює посилання на `Cappuccino`. Пізніше це посилання використовується як `*favoriteCoffee`. Таким чином, `coffees` стає `Latte, Cappuccino, Espresso`.\n\nХоча є кілька випадків, коли якорі корисні, існує один аспект їх використання, який може спричинити тонкі помилки: під час першого використання YAML посилання розширюється і потім видаляється.\n\nТому, якщо ми декодуємо і потім повторно кодуємо приклад вище, отриманий YAML буде таким:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nОскільки Helm і Kubernetes часто читають, змінюють і потім переписують файли YAML, якорі будуть втрачені.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/faq/index.mdx",
    "content": "---\ntitle: Часті питання\nsidebar_position: 9\n---\n\n# Часті питання\n\n> В цьому розділі містяться відповіді на поширені запитання.\n\n**Ми будемо вдячні за вашу допомогу** у покращенні цього документу. Щоб додати, виправити або видалити інформацію, [створіть тікет](https://github.com/helm/helm-www/issues) або надішліть нам пул-реквест.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/faq/installing.mdx",
    "content": "---\ntitle: Встановлення\nsidebar_position: 2\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\n## Встановлення {#installing}\n\n### Чому немає нативних пакетів Helm для Fedora та інших дистрибутивів Linux? {#why-arent-there-native-packages-of-helm-for-fedora-and-other-linux-distros}\n\nПроєкт Helm не підтримує пакети для операційних систем та середовищ. Спільнота Helm може надавати нативні пакети, і якщо проєкт Helm дізнається про них, вони будуть внесені до списку. Саме так було започатковано та внесено до списку формулу Homebrew. Якщо ви зацікавлені в підтримці пакета, ми будемо раді.\n\n### Чому ви надаєте скрипт `curl ...|bash`? {#why-do-you-provide-a-curl-bash-script}\n\nУ нашому репозиторії є скрипт (`scripts/get-helm-3`), який можна виконати як скрипт `curl ..|bash`. Передача захищена HTTPS, а скрипт проводить деякий аудит пакетів, які він завантажує. Проте скрипт має всі звичайні небезпеки будь-якого скрипта оболонки.\n\nМи надаємо його, тому що це корисно, але ми радимо користувачам ретельно ознайомитися зі скриптом перед виконанням. Те, що ми насправді хотіли б, — це кращі упаковані релізи Helm.\n\n### Як мені помістити файли клієнта Helm в інше місце, не стандартне місце? {#how-do-i-put-the-helm-client-files-somewhere-other-than-their-defaults}\n\nHelm використовує структуру XDG для зберігання файлів. Існують змінні середовища, які ви можете використовувати для зміни цих місць:\n\n- `$XDG_CACHE_HOME`: встановіть альтернативне місце для зберігання кешованих файлів.\n- `$XDG_CONFIG_HOME`: встановіть альтернативне місце для зберігання конфігурацій Helm.\n- `$XDG_DATA_HOME`: встановіть альтернативне місце для зберігання даних Helm.\n\nЗверніть увагу, що якщо у вас є наявні репозиторії, вам доведеться повторно їх додати за допомогою `helm repo add...`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/faq/uninstalling.mdx",
    "content": "---\ntitle: Видалення\nsidebar_position: 3\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\n## Видалення {#uninstalling}\n\n### Я хочу видалити свій локальний Helm. Де зберігаються всі його файли? {#i-want-to-delete-my-local-helm-where-are-all-its-files}\n\nРазом з бінарним файлом `helm`, Helm зберігає деякі файли в наступних розташуваннях:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nНаступна таблиця показує стандартні теки для кожного з цих розташувань, за операційними системами:\n\n| Операційна система | Шлях до кешу                | Шлях до конфігурацій             | Шлях до даних             |\n|--------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux              | `$HOME/.cache/helm`         | `$HOME/.config/helm`             | `$HOME/.local/share/helm` |\n| macOS              | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm`      |\n| Windows            | `%TEMP%\\helm`               | `%APPDATA%\\helm`                 | `%APPDATA%\\helm`          |\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/glossary/index.mdx",
    "content": "---\ntitle: Глосарій\ndescription: Терміни, які використовуються для опису компонентів архітектури Helm.\nsidebar_position: 10\n---\n\n# Глосарій\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\n## Чарт {#chart}\n\nПакет Helm, що містить інформацію, достатню для встановлення набору\nресурсів Kubernetes у кластер Kubernetes.\n\nЧарти містять файл `Chart.yaml`, а також шаблони, стандартні значення\n(`values.yaml`) та залежності.\n\nЧарти створюються у чітко визначеній структурі тек, а потім упаковуються\nв архів, який називається _архів чарту_.\n\n## Архів чарту {#chart-archive}\n\n_Архів чарту_ — це архів у форматі tar та gzip (та підписом, за бажанням).\n\n## Залежності чартів (субчарти) {#chart-dependency-subcharts}\n\nЧарти можуть залежати від інших чартів. Існує два типи залежностей:\n\n- Мʼякі залежності: чарт може просто не працювати без іншого чарту, встановленого в кластері. Helm не надає інструментів для цього випадку. У цьому випадку залежності можна керувати окремо.\n- Жорсткі залежності: чарт може містити (у своїй теці `charts/`) інший чарт, від якого він залежить. У цьому випадку під час встановлення чарту будуть встановлені всі його залежності. У цьому випадку чарт і його залежності управляються як колекція.\n\nКоли чарт упаковується (за допомогою `helm package`), всі його жорсткі залежності додаються до нього.\n\n## Версія чарту {#chart-version}\n\nЧарти версіонуються відповідно до [специфікації SemVer 2](https://semver.org). Номер версії обовʼязково вказується у кожному чарті.\n\n## Chart.yaml\n\nІнформація про чарт зберігається в спеціальному файлі з назвою `Chart.yaml`. Кожен чарт повинен мати цей файл.\n\n## Helm (та helm) {#helm-and-helm}\n\nHelm — це менеджер пакетів для Kubernetes. Так само, як менеджер пакетів операційної системи спрощує встановлення інструментів в ОС, Helm спрощує встановлення застосунків та ресурсів у кластерах Kubernetes.\n\nХоча _Helm_ — це назва проєкту, клієнт командного рядка також називається `helm`. За домовленістю, коли йдеться про проєкт, _Helm_ пишеться з великої літери. Коли йдеться про клієнта, _helm_ пишеться з малої літери.\n\n## Файли конфігурації Helm (XDG) {#helm-configuration-files-xdg}\n\nHelm зберігає свої файли конфігурації в теках XDG. Ці теки створюються під час першого запуску `helm`.\n\n## Kube Config (KUBECONFIG) {#kube-config-kubeconfig}\n\nКлієнт Helm отримує інформацію про кластери Kubernetes за допомогою файлів у форматі _Kube config_. Стандартно Helm намагається знайти цей файл у місці, де його створює `kubectl` (`$HOME/.kube/config`).\n\n## Lint (Перевірка) {#lint-linting}\n\n_Lint_ чартів означає перевірку їх відповідності стандартам і вимогам Helm chart. Helm надає інструменти для цього, зокрема команду `helm lint`.\n\n## Походження (файл походження) {#provenance-provenance-file}\n\nДо чартів Helm може додаватися файл походження, який містить інформацію про походження чарту та його вміст.\n\nФайли походження є частиною системи безпеки Helm. Походження містить криптографічний хеш файлу архіву чарта, дані Chart.yaml та блок підпису (блок OpenPGP «clearsign»). У поєднанні з ланцюжком ключів це надає користувачам чартів можливість:\n\n- Перевірити, чи чарт було підписано довіреною стороною\n- Перевірити, чи файл чарту не було підроблено\n- Перевірити вміст метаданих чарту (`Chart.yaml`)\n- Швидко порівняти чарт з даними про його походження\n\nФайли provenance мають розширення `.prov` і можуть бути надані з сервера репозиторію чартів або будь-якого іншого HTTP-сервера.\n\n## Release\n\nКоли чарт встановлено, бібліотека Helm створює _release_ для відстеження цього встановлення.\n\nОдин чарт може бути встановлений багато разів в одному кластері і може створити багато різних релізів. Наприклад, можна встановити три бази даних PostgreSQL, тричі запустивши `helm install` з різними іменами релізів.\n\n## Номер релізу (версія релізу) {#release-number-release-version}\n\nОдин реліз може бути оновлений кілька разів. Для відстеження змін у релізах використовується послідовний лічильник. Після першого `helm install` реліз матиме _номер релізу_ 1. Кожного разу, коли реліз оновлюється або відкочується, номер релізу збільшується.\n\n## Відкат {#rollback}\n\nРеліз можна оновити до нової версії або конфігурації. Але оскільки історія релізів зберігається, реліз також можна повернути до попереднього номера релізу. Це робиться за допомогою команди `helm rollback`.\n\nВажливо, що повернений реліз отримає новий номер релізу.\n\n| Операція   | Номер релізу                                            |\n|------------|---------------------------------------------------------|\n| install    | release 1                                               |\n| upgrade    | release 2                                               |\n| upgrade    | release 3                                               |\n| rollback 1 | release 4 (але з тією ж конфігурацією, що і у версії 1) |\n\nУ таблиці вище показано, як збільшуються номери релізів під час встановлення, оновлення та відкату.\n\n## Бібліотека Helm (або SDK) {#helm-library-or-sdk}\n\nБібліотека Helm (або SDK) — це код Go, який безпосередньо взаємодіє з сервером API Kubernetes для встановлення, оновлення, запиту та видалення ресурсів Kubernetes. Її можна імпортувати в проєкт, щоб використовувати Helm як клієнтську бібліотеку замість CLI.\n\n## Репозиторій (Repo, Chart Repository) {#repository-repo-chart-repository}\n\nHelm-чарти можуть зберігатися на спеціальних HTTP-серверах, які називаються _репозиторіями чартів_ (_репозиторіями_ або просто _репозиторіями_).\n\nСервер репозиторію чарту — це простий HTTP-сервер, здатний обробляти файл `index.yaml`, що описує набір чартів і надає інформацію про те, звідки можна завантажити кожен чарт. (Багато репозиторіїв чартів підтримують як чарти, так і файл `index.yaml`.)\n\nКлієнт Helm може вказувати на нуль або більше репозиторіїв чартів. Стандартно клієнти Helm не налаштовані на жодні репозиторії чартів. Репозиторії чартів можна додати в будь-який час за допомогою команди `helm repo add`.\n\n## Реєстр чартів (реєстр OCI) {#chart-registry-oci-based-registry}\n\nРеєстр чартів Helm — це система зберігання та розподілу на основі [OCI](https://opencontainers.org/about/overview/), яка використовується для розміщення та обміну пакетами чартів Helm. Докладнішу інформацію див. у [документації Helm про реєстри](https://helm.sh/docs/topics/registries/).\n\n## Значення (файли значень, values.yaml) {#values-values-files-valuesyaml}\n\nЗначення дають змогу замінити стандартні значення шаблону вашою власною інформацією.\n\nЧарти Helm є «параметризованими», що означає, що розробник чарту може надати конфігурацію, яку можна замінити під час встановлення. Наприклад, чарт може надати поле `username`, яке дозволяє встановити імʼя користувача для сервісу.\n\nЦі доступні змінні в термінології Helm називаються _values_.\n\nЗначення можна встановити під час операцій `helm install` та `helm upgrade`, або шляхом їх прямого введення, або за допомогою файлу `values.yaml`.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/_category_.json",
    "content": "{\n  \"link\": {\n    \"type\": \"doc\",\n    \"id\": \"helm-category\"\n  }\n}\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\nМенеджер пакетів Helm для Kubernetes.\n\n### Опис {#synopsis}\n\nМенеджер пакетів для Kubernetes\n\nЗагальні дії для Helm:\n\n- helm search:    пошук чартів\n- helm pull:      завантаження чарту у вашу локальну теку для перегляду\n- helm install:   завантаження чарту в Kubernetes\n- helm list:      перегляд списку релізів чартів\n\nЗмінні середовища:\n\n| Імʼя                               | Опис                                                                                                                                                   |\n|------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | вказує альтернативне місце для зберігання кешованих файлів.                                                                                            |\n| $HELM_CONFIG_HOME                  | вказує альтернативне місце для зберігання конфігурації Helm.                                                                                           |\n| $HELM_DATA_HOME                    | sвказує альтернативне місце для зберігання даних Helm.                                                                                                 |\n| $HELM_DEBUG                        | вказує, чи працює Helm в режимі налагодження.                                                                                                          |\n| $HELM_DRIVER                       | вказує драйвер бекенду для зберігання. Значення: configmap, secret, memory, sql..                                                                      |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | визначає рядок зʼєднання, який повинен використовувати драйвер сховища SQL.                                                                            |\n| $HELM_MAX_HISTORY                  | вказує максимальну кількість історії релізів Helm.                                                                                                     |\n| $HELM_NAMESPACE                    | вказує простір імен, що використовується для операцій Helm.                                                                                            |\n| $HELM_NO_PLUGINS                   | відключає втулки. Встановіть HELM_NO_PLUGINS=1, щоб відключити втулки.                                                                                 |\n| $HELM_PLUGINS                      | вказує шлях до теки втулків.                                                                                                                           |\n| $HELM_REGISTRY_CONFIG              | вказує шлях до файлу конфігурації реєстру.                                                                                                             |\n| $HELM_REPOSITORY_CACHE             | вказує шлях до теки кешу репозиторіїв.                                                                                                                 |\n| $HELM_REPOSITORY_CONFIG            | вказує шлях до файлу репозиторіїв.                                                                                                                     |\n| $KUBECONFIG                        | вказує альтернативний файл конфігурації Kubernetes (стандартно \"~/.kube/config\")                                                                       |\n| $HELM_KUBEAPISERVER                | вказує точку доступу сервера API Kubernetes для автентифікації.                                                                                        |\n| $HELM_KUBECAFILE                   | вказує файл центру сертифікації для Kubernetes.                                                                                                        |\n| $HELM_KUBEASGROUPS                 | вказує групи для використання імперсонації, використовуючи список, розділений комами.                                                                  |\n| $HELM_KUBEASUSER                   | вказує імʼя користувача для імперсонації під час операції.                                                                                             |\n| $HELM_KUBECONTEXT                  | вказує імʼя контексту kubeconfig.                                                                                                                      |\n| $HELM_KUBETOKEN                    | вказує токен Bearer KubeToken для автентифікації.                                                                                                      |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | вказує, чи слід пропустити перевірку сертифіката сервера API Kubernetes (небезпечний режим).                                                           |\n| $HELM_KUBETLS_SERVER_NAME          | вказує імʼя сервера для перевірки сертифіката сервера API Kubernetes.                                                                                  |\n| $HELM_BURST_LIMIT                  | вказує стандартне обмеження на кількість викликів у випадку великої кількості CRD (стандартно — 100, -1 для відключення)                               |\n| $HELM_QPS                          | вказує кількість запитів в секунду (Queries Per Second — QPS) у випадках, коли велика кількість викликів перевищує параметр для більш високих значень. |\n| $HELM_COLOR                        | встановлює режим кольорового виводу. Допустимі значення: never, always, auto (стандартно: never)                                                       |\n| $NO_COLOR                          | встановлює будь-яке непорожнє значення, щоб вимкнути будь-який кольоровий вивід (перевизначає $HELM_COLOR)                                             |\n\nHelm зберігає кеш, конфігурацію та дані відповідно до наступного порядку конфігурації:\n\n- Якщо встановлено змінну середовища HELM_*_HOME, вона буде використовуватися\n- В іншому випадку, в системах, що підтримують специфікацію базової теки XDG, будуть використовуватися змінні XDG\n- Якщо не встановлено інше місце розташування, буде використовуватися стандартне місце розташування, залежно від операційної системи\n\nТипово, стандартні теки залежать від операційної системи. Нижче наведені їх значення:\n\n| Операційна система | Шлях до кешу              | Шлях до конфігурації           | Шлях до даних           |\n|--------------------|---------------------------|--------------------------------|-------------------------|\n| Linux              | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm |\n| macOS              | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm      |\n| Windows            | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm          |\n\n### Параметри {#options}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n  -h, --help                            довідка helm\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки\n* [helm create](/helm/helm_create.md) — створення нового чарта з вказаною назвою\n* [helm dependency](/helm/helm_dependency.md) — керування залежностями чарта\n* [helm env](/helm/helm_env.md) — інформація про середовище клієнта helm\n* [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз\n* [helm history](/helm/helm_history.md) — отримання історії релізу\n* [helm install](/helm/helm_install.md) — встановлення чарту\n* [helm lint](/helm/helm_lint.md) — перевірка чарту на предмет можливих проблем\n* [helm list](/helm/helm_list.md) — отримати перелік релізів\n* [helm package](/helm/helm_package.md) — упакувати теку чарту в архів чарту\n* [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm\n* [helm pull](/helm/helm_pull.md) — завантажити чарт з репозиторію та (за бажанням) розпакувати його в локальній теці\n* [helm push](/helm/helm_push.md) — завантажити чарт до віддаленого сервера\n* [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру\n* [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів\n* [helm rollback](/helm/helm_rollback.md) — відкотити реліз до попередньої версії\n* [helm search](/helm/helm_search.md) — пошук за ключовим словом в чартах\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n* [helm status](/helm/helm_status.md) — показати статус зазначеного релізу\n* [helm template](/helm/helm_template.md) — локально рендерити шаблони\n* [helm test](/helm/helm_test.md) — запустити тести для релізу\n* [helm uninstall](/helm/helm_uninstall.md) — видалити реліз\n* [helm upgrade](/helm/helm_upgrade.md) — оновити реліз\n* [helm verify](/helm/helm_verify.md) — перевірити, чи підписаний та, чи є дійсним чарт за вказаним шляхом\n* [helm version](/helm/helm_version.md) — показати інформацію про версію helm\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\nГенерація скриптів автодоповнення для вказаної оболонки\n\n### Опис {#synopsis}\n\nГенерація скриптів автодоповнення Helm для вказаної оболонки.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка completion\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n* [helm completion bash](/helm/helm_completion_bash.md) — скрипт автодоповнення для bash\n* [helm completion fish](/helm/helm_completion_fish.md) — скрипт автодоповнення для fish\n* [helm completion powershell](/helm/helm_completion_powershell.md) — скрипт автодоповнення для powershell\n* [helm completion zsh](/helm/helm_completion_zsh.md) — скрипт автодоповнення для zsh\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\nГенерація скрипта автодоповнення для bash\n\n### Опис {#synopsis}\n\nГенерація скрипта автодоповнення Helm для shell bash.\n\nДля завантаження автодоповнень у вашій поточній shell-сесії:\n\n```shell\nsource <(helm completion bash)\n```\n\nДля завантаження автодоповнень для кожної нової сесії, виконайте один раз:\n\n Linux:\n\n  ```shell\n  helm completion bash > /etc/bash_completion.d/helm\n  ```\n\n- MacOS:\n\n  ```shell\n  helm completion bash > /usr/local/etc/bash_completion.d/helm\n  ```\n\n```shell\nhelm completion bash [прапорці]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка bash\n      --no-descriptions   вимкнути описи автодоповнення\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\nГенерація скрипта автодоповнення для fish\n\n### Опис {#synopsis}\n\nГенерація скрипта автодоповнення Helm для shell fish.\n\nДля завантаження автодоповнень у вашій поточній shell-сесії:\n\n```shell\nhelm completion fish | source\n```\n\nДля завантаження автодоповнень для кожної нової сесії, виконайте один раз:\n\n```shell\nhelm completion fish > ~/.config/fish/completions/helm.fish\n```\n\nПотрібно запустити нову shell-сесію, щоб ці налаштування набули чинності.\n\n```shell\nhelm completion fish [прапорці]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка fish\n      --no-descriptions   вимкнути описи автодоповнення\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\nГенерація скрипта автодоповнення для powershell\n\n### Опис {#synopsis}\n\nГенерація скрипта автодоповнення для PowerShell.\n\nДля завантаження автодоповнень у вашій поточній shell-сесії:\n\n```powershell\nPS C:\\> helm completion powershell | Out-String | Invoke-Expression\n```\n\nДля завантаження автодоповнень для кожної нової сесії, додайте вивід вищенаведеної команди до вашого профілю PowerShell.\n\n```powershell\nhelm completion powershell [прапорці]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка powershell\n      --no-descriptions   вимкнути описи автодоповнення\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\nГенерація скрипта автодоповнення для zsh\n\n### Опис {#synopsis}\n\nГенерація скрипта автодоповнення Helm для оболонки zsh.\n\nДля завантаження автодоповнень у вашій поточній shell-сесії:\n\n```shell\nsource <(helm completion zsh)\n```\n\nДля завантаження автодоповнень для кожної нової сесії, виконайте один раз:\n\n```shell\nhelm completion zsh > \"${fpath[1]}/_helm\"\n```\n\n```shell\nhelm completion zsh [прапорці]\n```\n\n### Параметри {#options}\n\n```\n  -h, --help              довідка zsh\n      --no-descriptions   вимкнути описи автодоповнення\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n\nСтворення нового чарта з вказаним іменем\n\n### Опис {#synopsis}\n\nЦя команда створює теку чарта разом із загальними файлами та\nтеками, що використовуються в чартах.\n\nНаприклад, `helm create foo` створить структуру тек, що виглядає\nприблизно так:\n\n```none\n    foo/\n    ├── .helmignore   # Містить шаблони для ігнорування при упаковці Helm-чартів.\n    ├── Chart.yaml    # Інформація про ваш чарт\n    ├── values.yaml   # Стандартні значення для ваших шаблонів\n    ├── charts/       # Чарти, від яких залежить цей чарт\n    └── templates/    # Файли шаблонів\n        └── tests/    # Файли тестів\n```\n\n`helm create` приймає шлях як аргумент. Якщо теки у вказаному шляху не існують, Helm спробує створити їх у процесі роботи. Якщо вказане місце призначення існує і в цій теці є файли, що викликають конфлікт, вони будуть перезаписані, а інші файли залишаться без змін.\n\n\n```sh\nhelm create NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help             довідка create\n  -p, --starter string   імʼя або абсолютний шлях до стартового шаблону Helm\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\nКерування залежностями чарту\n\n### Опис {#synopsis}\n\nКеруйте залежностями чарту.\n\nЧарти Helm зберігають свої залежності в теці `charts/`. Розробникам чартів\nчасто простіше керувати залежностями у файлі `Chart.yaml`, який декларує всі\nзалежності.\n\nКоманди `dependency` працюють з цим файлом, полегшуючи синхронізацію між бажаними залежностями та фактичними залежностями, збереженими в теці `charts/`.\n\nНаприклад, цей файл Chart.yaml декларує дві залежності:\n\n```yaml\n# Chart.yaml\ndependencies:\n- name: nginx\n  version: \"1.2.3\"\n  repository: \"https://example.com/charts\"\n- name: memcached\n  version: \"3.2.1\"\n  repository: \"https://another.example.com/charts\"\n```\n\nПоле 'name' повинно містити імʼя чарту, яке повинно збігатися з імʼям у файлі 'Chart.yaml' цього чарту.\n\nПоле 'version' повинно містити семантичну версію або діапазон версій.\n\nURL-адреса 'repository' повинна вказувати на репозиторій чарту. Helm очікує, що додавання '/index.yaml' до URL-адреси дозволить отримати індекс репозиторію чарту.\n\n:::note\n'repository' може бути псевдонімом, який повинен починатися з 'alias:' або '@'.\n:::\n\nПочинаючи з версії 2.2.0, репозиторій може бути визначений як шлях до теки залежних чартів, збережених локально. Шлях повинен починатися з префіксу \"file://\". Наприклад,\n\n```yaml\n# Chart.yaml\ndependencies:\n- name: nginx\n  version: \"1.2.3\"\n  repository: \"file://../dependency_chart/nginx\"\n```\n\nЯкщо залежний чарт отримано локально, його не потрібно додавати до helm за допомогою команди \"helm repo add\". Підтримується також відповідність версій для цього випадку.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка dependency\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n* [helm dependency build](/helm/helm_dependency_build.md) —\tвідновлення теки charts/ на основі файлу Chart.lock\n* [helm dependency list](/helm/helm_dependency_list.md) — перелік залежностей для даного чарта\n* [helm dependency update](/helm/helm_dependency_update.md) — оновлення charts/ на основі вмісту Chart.yaml\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\nВідновлення теки charts/ на основі файлу Chart.lock\n\n### Опис {#synopsis}\n\nЦя команда будує теку `charts/` на основі файлу `Chart.lock`.\n\nКоманда `build` використовується для відновлення залежностей чарту до стану, зазначеного у файлі блокування. Вона не переузгоджуватиме залежності, як це робить `helm dependency update`.\n\nЯкщо файл блокування не знайдено, `helm dependency build` дзеркально повторюватиме поведінку команди `helm dependency update`.\n\n```sh\nhelm dependency build CHART [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n  -h, --help                       довідка build\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string             вʼязка ключів, що містить відкриті ключі ( стандартно \"~/.gnupg/pubring.gpg\")\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --skip-refresh               не оновлювати кеш локального репозиторію\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n      --verify                     перевірити пакети на відповідність підписам\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm dependency](/helm/helm_dependency.md) — керування залежностями чарта\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\nСписок залежностей для заданого чарту\n\n### Опис {#synopsis}\n\nПерелічує всі залежності, зазначені в чарті.\n\nЦя команда приймає на вхід як архіви чарту, так і теки чарту. Вона не змінює вміст чарту.\n\nВикликається помилка, якщо чарт не може бути завантажений.\n\n```sh\nhelm dependency list CHART [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help                 довідка list\n      --max-col-width uint   максимальна ширина стовпця для таблиці виводу (стандартно 80)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm dependency](/helm/helm_dependency.md) — керування залежностями чарта\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\nОновлення charts/ на основі вмісту Chart.yaml\n\n### Опис {#synopsis}\n\nОновлює залежності на диску, щоб відобразити стан, зазначений у Chart.yaml.\n\nЦя команда перевіряє, що необхідні чарти, зазначені в `Chart.yaml`, присутні в `charts/` і відповідають прийнятній версії. Вона завантажує найновіші чарти, що задовольняють залежності, та очищає застарілі залежності.\n\nУ разі успішного оновлення буде згенеровано файл блокування, який можна використовувати для відновлення залежностей до точної версії.\n\nЗалежності не обовʼязково повинні бути представлені в `Chart.yaml`. З цієї причини команда оновлення не видалить чарти, якщо вони (а) присутні у файлі `Chart.yaml`, але (б) мають неправильну версію.\n\n```sh\nhelm dependency update CHART [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n  -h, --help                       довідка update\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string             вʼязка ключів, що містить відкриті ключі ( стандартно \"~/.gnupg/pubring.gpg\")\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --skip-refresh               не оновлювати кеш локального репозиторію\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n      --verify                     перевірити пакети на відповідність підписам\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm dependency](/helm/helm_dependency.md) — керування залежностями чарта\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\nІнформація про середовище клієнта Helm\n\n### Опис {#synopsis}\n\nКоманда `helm env` виводить усю інформацію про середовище, в якому використовється Helm.\n\n```sh\nhelm env [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка env\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\nЗавантаження розширеної інформації про вказаний реліз\n\n### Опис {#synopsis}\n\nЦя команда складається з кількох підкоманд, які можна використовувати для отримання розширеної інформації про реліз, включаючи:\n\n- Значення, що використовувалися для генерації релізу\n- Сгенерований файл маніфесту\n- Примітки, надані чартом релізу\n- Хуки, асоційовані з релізом\n- Метадані релізу\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка get\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n* [helm get all](/helm/helm_get_all.md) — завантажити всю інформацію про вказаний реліз\n* [helm get hooks](/helm/helm_get_hooks.md) — завантажити всі хуки для вказаного релізу\n* [helm get manifest](/helm/helm_get_manifest.md) — завантажити маніфест для вказаного релізу\n* [helm get metadata](/helm/helm_get_metadata.md) — отримати метадані для вказаного релізу\n* [helm get notes](/helm/helm_get_notes.md) — завантажити примітки для вказаного релізу\n* [helm get values](/helm/helm_get_values.md) — завантажити файл значень для вказаного релізу\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\nЗавантажити всю інформацію про вказаний реліз\n\n### Опис {#synopsis}\n\nЦя команда виводить зрозумілий для людини набір інформації про нотатки, хуки, надані значення та згенерований маніфест для вказаного релізу.\n\n```shell\nhelm get all RELEASE_NAME [flags]\n``` get all RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка all\n      --revision int      отримати вказаний реліз з ревізією\n      --template string   шаблон Go для форматування виводу, напр: {{.Release.Name}}\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\nЗавантажити всі хуки для вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда завантажує хуки для вказаного релізу.\n\nХуки форматуються у YAML і розділені роздільником YAML '---\\n'.\n\n```shell\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help           довідка hooks\n      --revision int   отримати вказаний реліз з ревізією\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\nЗавантажити маніфест для вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда завантажує згенерований маніфест для вказаного релізу.\n\nМаніфест є YAML-кодованим представленням ресурсів Kubernetes, які були згенеровані з чарту(ів) цього релізу. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені в маніфест.\n\n```shell\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help           довідка manifest\n      --revision int   отримати вказаний реліз з ревізією\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\nЦя команда завантажує метадані для вказаного релізу\n\n```shell\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help            довідка metadata\n  -o, --output format   виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --revision int    вказати версію релізу\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\nЗавантажити нотатки для вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда відображає нотатки, надані чартом для вказаного релізу.\n\n```shell\nhelm get notes RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help           довідка notes\n      --revision int   отримати вказаний реліз з ревізією\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\nЗавантажити файл значень для вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда завантажує файл значень для вказаного релізу.\n\n```shell\nhelm get values RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -a, --all             вивести всі (обчислені) значення\n  -h, --help            довідка values\n  -o, --output format   виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --revision int    отримати вказаний реліз з ревізією\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\nОтримати історію релізу\n\n### Опис {#synopsis}\n\nHistory виводить історичні ревізії для вказаного релізу.\n\nСтандартна максимальна кількість ревізій, що повертається — 256. Встановлення '--max' налаштовує максимальну довжину списку ревізій, що повертаються.\n\nІсторичний набір релізів виводиться у вигляді відформатованої таблиці, наприклад:\n\n```console\n$ helm history angry-bird\nREVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n```\n\n```shell\nhelm history RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help            довідка history\n      --max int         максимальна кількість ревізій, включених в історію (стандартно 256)\n  -o, --output format   виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\nВстановлює чарт\n\n### Опис {#synopsis}\n\nЦя команда встановлює архів чарту.\n\nАргумент для `install` має бути посиланням на чарт, шляхом до запакованого чарту, шляхом до розпакованої теки чарту або URL.\n\nЩоб перезаписати значення в чартах, використовуйте прапорець `--values` та передайте файл або прапорець `--set`, щоб передати конфігурацію з командного рядка. Щоб примусово встановити значення string, використовуйте `--set-string`. Ви також можете використовувати `--set-file`, щоб задати окремі значення з файлу, якщо значення занадто велике для командного рядка або є динамічно згенерованим. Ви також можете використовувати `--set-json`, щоб встановити значення JSON (скаляри/обʼєкти/масиви) з командного рядка.\n\n```shell\n$ helm install -f myvalues.yaml myredis ./redis\n```\n\nабо\n\n```shell\n$ helm install --set name=prod myredis ./redis\n```\n\nабо\n\n```shell\n$ helm install --set-string long_int=1234567890 myredis ./redis\n```\n\nабо\n\n```shell\n$ helm install --set-file my_script=dothings.sh myredis ./redis\n```\n\nабо\n\n```shell\n$ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n```\n\nабо\n\n```shell\n$ helm install --set-json '{\"master\":{\"sidecars\":[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]}}' myredis ./redis\n```\n\nВи можете вказати прапорець `--values`/`-f` кілька разів. Пріоритет буде наданий останньому (правому) файлу, що вказаний. Наприклад, якщо як `myvalues.yaml`, так і `override.yaml` містять ключ `Test`, значення, встановлене в `override.yaml`, матиме пріоритет:\n\n```shell\n$ helm install -f myvalues.yaml -f override.yaml myredis ./redis\n```\n\nВи можете вказати прапорець `--set` кілька разів. Пріоритет буде наданий останньому (правому) встановленому значенню. Наприклад, якщо для ключа `foo` встановлені значення `bar` і `newbar`, значення `newbar` матиме пріоритет:\n\n```shell\n$ helm install --set foo=bar --set foo=newbar myredis ./redis\n```\n\nАналогічно, у наступному прикладі `foo` встановлено в `[\"four\"]`:\n\n```shell\n$ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n```\n\nА в наступному прикладі `foo` встановлено в `{\"key1\":\"value1\",\"key2\":\"bar\"}`:\n\n```shell\n$ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n```\n\nЩоб перевірити згенеровані маніфести релізу без встановлення чарту, можна поєднати прапорці `--debug` і `--dry-run`.\n\nПрапорець `--dry-run` виведе усі згенеровані маніфести чартів, включно з Secrets які можуть містити конфіденційні значення. Щоб приховати секрети Kubernetes, скористайтеся прапорцем `--hide-secret`. Будь ласка, ретельно обміркуйте, як і коли використовувати ці прапорці.\n\nЯкщо встановлено прапорець `--verify`, чарт ПОВИНЕН мати файл автентифікації, і цей файл ПОВИНЕН пройти всі кроки перевірки.\n\nЄ шість різних способів вказати чарт, який ви хочете встановити:\n\n1. З посиланням на чарт: `helm install mymaria example/mariadb`\n2. З шляхом до запакованого чарту: `helm install mynginx ./nginx-1.2.3.tgz`\n3. З шляхом до розпакованої теки чарту: `helm install mynginx ./nginx`\n4. З абсолютним URL: `helm install mynginx https://example.com/charts/nginx-1.2.3.tgz`\n5. З посиланням на чарт і URL репозиторію: `helm install --repo https://example.com/charts/ mynginx nginx`\n6. З OCI реєстрами: `helm install mynginx --version 1.2.3 oci://example.com/charts/nginx`\n\nПОСИЛАННЯ НА ЧАРТ\n\nПосилання на чарт — це зручний спосіб посилатися на чарт у репозиторії чарту.\n\nКоли ви використовуєте посилання на чарт з префіксом репозиторію (`example/mariadb`), Helm шукатиме в локальній конфігурації репозиторій чарту з імʼям `example`, а потім шукатиме чарт у цьому репозиторії, чия назва є `mariadb`. Він встановить останню стабільну версію цього чарту, поки ви не вкажете прапорець `--devel`, щоб також включити версії розробки (альфа, бета та реліз-кандидати), або не надасте номер версії за допомогою прапорця `--version`.\n\nЩоб переглянути список репозиторіїв чартів, використовуйте `helm repo list`. Щоб шукати чарти в репозиторії, використовуйте `helm search`.\n\n```shell\nhelm install [NAME] [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string                             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string                           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n      --create-namespace                           створити простір імен релізу, якщо його не існує\n      --dependency-update                          оновити залежності, якщо вони відсутні, перед встановленням чарту\n      --description string                         додати власний опис\n      --devel                                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n      --disable-openapi-validation                 якщо вказано, процес встановлення не буде перевіряти відрендерені шаблони за схемою OpenAPI Kubernetes\n      --dry-run string[=\"unset\"]                   імітує операцію без збереження змін. Повинно бути одним із таких: \"none\" (стандартно), \"client\" або \"server\". '--dry-run=none' виконує операцію у звичайному режимі та зберігає зміни (без імітації). \"--dry-run=client\" імітує операцію лише на стороні клієнта та уникає підключень до кластера. \"--dry-run=server\" імітує операцію на сервері, вимагаючи підключення до кластера. (стандартно \"none\")\n      --enable-dns                                 увімкнути DNS запити при рендерингу шаблонів\n      --force-conflicts                            якщо встановлено, 'застосування на стороні сервера' примусово застосує зміни, незважаючи на конфлікти\n      --force-replace                              примусове оновлення ресурсів шляхом заміни\n  -g, --generate-name                              згенерувати імʼя (та опустити параметр NAME)\n  -h, --help                                       довідка install\n      --hide-notes                                 якщо встановлено, не показувати нотатки у виводі встановлення. Не впливає на присутність у метаданих чарту\n      --hide-secret                                приховати Kubernetes Secrets, якщо також використовується прапорець --dry-run\n      --insecure-skip-tls-verify                   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key-file string                            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string                             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно [])\n      --name-template string                       вказати шаблон для назви релізу\n      --no-hooks                                   запобігти виконанню хуків під час встановлення\n  -o, --output format                              виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --pass-credentials                           передати облікові дані всім доменам\n      --password string                            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --post-renderer postRendererString           назва втулка типу postrenderer, який буде використовуватися для пострендерингу. Якщо він існує, втулок буде використовуватися\n      --post-renderer-args postRendererArgsSlice   аргумент до пост-рендерера (можна вказати кілька) (стандартно [])\n      --render-subchart-notes                      якщо вказано, рендерити нотатки субчартів разом з батьківським\n      --replace                                    повторно використовувати задане імʼя, тільки якщо це імʼя є видаленим релізом, який залишається в історії. Це небезпечно в операційному середовищі.\n      --repo string                                URL репозиторію чартів, де розташований запитуваний чарт\n      --rollback-on-failure                        якщо встановлено, Helm скасує (деінсталює) встановлення у разі невдачі. Прапорець --wait буде стандартно встановлений у \"watcher\", якщо встановлено --rollback-on-failure.\n      --server-side                                оновлення обʼєктів виконуються на сервері, а не на клієнті (стандартно true)\n      --set stringArray                            встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --set-file stringArray                       встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2)\n      --set-json stringArray                       встановити значення JSON у командному рядку (можна вказати кілька значень або розділити їх комами: key1=jsonval1,key2=jsonval2 або використовувати формат json: {\"key1\": jsonval1, \"key2\": \"jsonval2\"})\n      --set-literal stringArray                    встановити літеральне значення STRING в командному рядку\n      --set-string stringArray                     встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --skip-crds                                  якщо вказано, CRD не буде встановлено. Стандартно CRD встановлюються, якщо їх ще немає\n      --skip-schema-validation                     якщо встановлено, вимикає перевірку схеми JSON\n      --take-ownership                             якщо встановлено, встановлення ігноруватиме перевірку анотацій Helm і перейматиме право власності на наявні ресурси\n      --timeout duration                           очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s)\n      --username string                            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n  -f, --values strings                             вказати значення в YAML файлі або URL (можна вказати кілька)\n      --verify                                     перевірити пакет перед використанням\n      --version string                             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest'\n      --wait WaitStrategy[=watcher]                якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: \"watcher\" і \"legacy\" (стандартно hookOnly).\n      --wait-for-jobs                              якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки вказано в --timeout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\nПеревіряє чарт на можливі проблеми\n\n### Опис {#synopsis}\n\nЦя команда приймає шлях до чарту і виконує ряд тестів, щоб перевірити, чи чарт добре сформований.\n\nЯкщо лінтер знайде речі, які можуть призвести до помилки при встановленні чарту, він видасть повідомлення [ERROR]. Якщо він знайде проблеми, які порушують конвенції або рекомендації, він видасть повідомлення [WARNING].\n\n```shell\nhelm lint PATH [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help                      довідка lint\n      --kube-version string       версія Kubernetes, що використовується для перевірки можливостей і застарілостей\n      --quiet                     виводити лише попередження та помилки\n      --set stringArray           встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --set-file stringArray      встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=pshellath2)\n      --set-json stringArray      встановити значення JSON у командному рядку (можна вказати кілька значень або розділити їх комами: key1=jsonval1,key2=jsonval2 або використовувати формат json: {\"key1\": jsonval1, \"key2\": \"jsonval2\"})\n      --set-literal stringArray   встановити літеральне значення STRING в командному рядку\n      --set-string stringArray    встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --skip-schema-validation    якщо встановлено, вимикає перевірку схеми JSON\n      --strict                    видавати стан помилки на попередження перевірки\n  -f, --values strings            вказати значення в YAML файлі або URL (можна вказати кілька)\n      --with-subcharts            перевірити залежні чарти\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\nВивід списку релізів\n\n### Опис {#synopsis}\n\nЦя команда виводить список усіх релізів для вказаного простору імен (використовується поточний контекст простору імен, якщо не вказано).\n\nСтандартно показуються всі релізи в будь-якому статусі. Для показу релізів у певному статусі можна використовувати окремі фільтри статусу, такі як `--deployed`, `--failed`, `--pending`, `--uninstalled`, `--superseded` та `--uninstalling`. Ці прапорці можна комбінувати: `--deployed --failed`.\n\nЯк правило елементи сортуються в алфавітному порядку. Використовуйте прапорець `-d`, щоб сортувати за датою релізу.\n\nЯкщо надано прапорець `--filter`, він буде використовуватися як фільтр. Фільтри є регулярними виразами (сумісними з Perl), які застосовуються до списку релізів. Будуть повернуті тільки ті елементи, які відповідають фільтру.\n\n```console\n$ helm list --filter 'ara[a-z]+'\nNAME                UPDATED                                  CHART\nmaudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n```\n\nЯкщо результати не знайдені, команда `helm list` завершиться з кодом 0, але без виводу (або, у випадку без прапорця `-q`, тільки заголовки).\n\nСтандартно повертається до 256 елементів. Щоб обмежити це, використовуйте прапорець `--max`. Встановлення `--max` в 0 не поверне всі результати. Замість цього повернеться стандартне значення сервера, яке може бути значно більше ніж 256. Поєднання прапорців `--max` та `--offset` дозволяє переглядати результати посторінково.\n\n```shell\nhelm list [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -A, --all-namespaces       список релізів по всіх просторах імен\n  -d, --date                 сортувати за датою релізу\n      --deployed             показати розгорнуті релізи\n      --failed               показати релізи, що зазнали невдачі\n  -f, --filter string        регулярний вираз (сумісний з Perl). Будь-які релізи, що відповідають виразу, будуть включені в результати\n  -h, --help                 довідка list\n  -m, --max int              максимальна кількість релізів для отримання (стандартно 256)\n      --no-headers           не друкувати заголовки при використанні стандартного формату виводу\n      --offset int           наступний індекс релізу у списку, використовується для зсуву від початкового значення\n  -o, --output format        виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --pending              показати релізи, які перебувають в очікуванні\n  -r, --reverse              змінити порядок сортування на зворотний\n  -l, --selector string      Селектор (запит за міткою) для фільтрації, підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Працює тільки для сховищ secret (стандартно) та configmap.\n  -q, --short                короткий (простий) формат виводу списку\n      --superseded           показати замінені релізи\n      --time-format string   форматувати час використовуючи форматування часу golang. Наприклад: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          показати видалені релізи (якщо використовувався 'helm uninstall --keep-history')\n      --uninstalling         показати релізи, які в даний час видаляються\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\nУпакувати теку чарту в архів чартів\n\n### Опис {#synopsis}\n\nЦя команда упаковує чарт в архів чартів з версією. Якщо вказано шлях, команда перевіряє цей шлях на наявність чарту (який повинен містити файл `Chart.yaml`) і потім упаковує цю теку.\n\nАрхіви чартів з версією використовуються репозиторіями пакетів Helm.\n\nЩоб підписати чарт, використовуйте прапорець `--sign`. У більшості випадків вам також слід вказати `--keyring path/to/secret/keys` та `--key keyname`.\n\n```shell\n$ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n```\n\nЯкщо `--keyring` не вказано, Helm зазвичай використовує публічний ключ, якщо тільки ваше середовище не налаштоване інакше.\n\n\n```shell\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --app-version string         встановити appVersion в чарті на цю версію\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n  -u, --dependency-update          оновити залежності з \"Chart.yaml\" в теці \"charts/\" перед упаковкою\n  -d, --destination string         місце для збереження чарту. (стандартно \".\")\n  -h, --help                       довідка package\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key string                 імʼя ключа для використання під час підписання. Використовується, якщо `--sign` є true\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string             місце для публічного ключа (стандартно \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     місце розташування файлу, що містить пароль для ключа підпису. Використовуйте \"-\" для читання з stdin.\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --sign                       використовувати приватний ключ PGP для підписання цього пакета\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n      --version string             встановити версію чарту на цю версію semver\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\nВстановлення, перегляд списку або видалення втулків Helm\n\n### Опис {#synopsis}\n\nКерування втулками Helm на стороні клієнта.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка plugin\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n* [helm plugin install](/helm/helm_plugin_install.md) — встановлення втулків Helm\n* [helm plugin list](/helm/helm_plugin_list.md) — перегляд встановлених втулків Helm\n* [helm plugin package](/helm/helm_plugin_package.md) — створення пакунку з теки втулка\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md) — видалення одного чи кількох втулків Helm\n* [helm plugin update](/helm/helm_plugin_update.md) — оновлення одного чи кількох втулків Helm\n* [helm plugin verify](/helm/helm_plugin_verify.md) — перевірка, що втулок за вказаним шляхом має підпис і є дійсним\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\nВстановлення втулків Helm\n\n### Опис {#synopsis}\n\nЦя команда дозволяє встановити втулок з вказаної URL-адреси в репозиторій VCS або з локального шляху.\n\nЗазвичай підписи втулків перевіряються перед встановленням під час встановлення з архівів (.tgz або .tar.gz). Для цього потрібно, щоб відповідний файл .prov був доступний разом з архівом. Для локальної розробки втулки, встановлені з локальних текстових файлів, автоматично розглядаються як «локальна розробка» і не потребують підписів. Використовуйте `--verify=false`, щоб пропустити перевірку підписів для віддалених втулків.\n\n```shell\nhelm plugin install [options] <path|url> [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта реєстру за допомогою цього файлу сертифіката SSL\n  -h, --help                       довідка install\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження втулка\n      --key-file string            ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL\n      --keyring string             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --password string            пароль реєстру\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження втулка\n      --username string            імʼя користувача реєстру\n      --verify                     перевірити підпис втулка перед встановленням (стандартно true)\n      --version string             вказати обмеження версії. Якщо це не вказано, встановлюється остання версія 'latest'\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\nВивести перелік встановлених втулків Helm\n\n```shell\nhelm plugin list [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help          довідка list\n      --type string   тип втулка\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_package.md",
    "content": "---\ntitle: helm plugin package\n---\n\nУпакувати теку втулка в архів втулка\n\n### Опис {#synopsis}\n\nЦя команда упаковує теку втулка Helm в архів tarball.\n\nЗазвичай, команда створює файл provenance, підписаний ключем PGP. Це гарантує, що втулок можна перевірити після встановлення.\n\nВикористовуйте `--sign=false`, щоб пропустити підписання (не рекомендується для розповсюдження).\n\n```shell\nhelm plugin package [PATH] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -d, --destination string       місце для збереження архіву втулка. (стандартно \".\")\n  -h, --help                     довідка package\n      --key string               імʼя ключа для використання під час підписання. Використовується, якщо `--sign` є true\n      --keyring string           місце для публічного ключа (стандартно \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string   розташування файлу, що містить пароль для ключа підпису. Використовуйте \"-\" для читання зі стандартного вводу.\n      --sign                     використовувати приватний ключ PGP для підписання цього втулка (стандартно true)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\nВидалити один або кілька втулків Helm\n\n```shell\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка uninstall\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\nОновити один або кілька втулків Helm\n\n```shell\nhelm plugin update <plugin>... [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка update\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_verify.md",
    "content": "---\ntitle: helm plugin verify\n---\n\nПеревірити, чи втулок за вказаним шляхом має підпис і є дійсним\n\n### Опис {#synopsis}\n\nЦя команда перевіряє, чи має втулок Helm дійсний файл походження і чи підписаний цей файл походження надійним ключем PGP.\n\nВона підтримує обидва типи:\n\n- Архіви втулків (файли .tgz або .tar.gz)\n- Теки встановлених втулків\n\nДля встановлених втулків використовуйте шлях, показаний командою `helm env HELM_PLUGINS`, а потім вкажіть назву втулка. Наприклад:\n\n```shell\nhelm plugin verify ~/.local/share/helm/plugins/example-cli\n```\n\nЩоб створити підписаний втулок, використовуйте команду `helm plugin package --sign`.\n\n```shell\nhelm plugin verify [PATH] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help             довідка verify\n      --keyring string   вʼязка ключів, що містить відкриті ключі ( стандартно \"~/.gnupg/pubring.gpg\")\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\nЗавантажити чарт з репозиторію та (за бажанням) розпакувати його в локальну теку\n\n### Опис {#synopsis}\n\nОтримати пакет із репозиторію пакетів і завантажити його локально.\n\nЦе корисно для отримання пакетів з метою перевірки, модифікації або перепакування. Також це можна використовувати для криптографічної перевірки чарта без його встановлення\n.\n\nІснують опції для розпакування чарта після завантаження. Це створить теку для чарта і розпакує його в цю теку.\n\nЯкщо вказано прапорець `--verify`, запитуваний чарт ПОВИНЕН мати файл походження і ПОВИНЕН пройти процес перевірки. Неуспіх у будь-якій частині цього призведе до помилки, і чарт не буде збережений локально.\n\n```shell\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n  -d, --destination string         місце для збереження чарту. Якщо вказано разом із untardir, то untardir буде додано до нього (стандартно \".\")\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка pull\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --prov                       завантажити файл підтвердження автентичності, але не виконувати перевірку\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --untar                      якщо встановлено, чарт буде розпаковано після завантаження\n      --untardir string            якщо вказано untar, цей прапорець вказує назву теки, в яку буде розпаковано чарт (стандартно \".\")\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest'\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\nЗавантажити чарт на віддалений сервер\n\n### Опис {#synopsis}\n\nЗавантаження чарту до реєстру.\n\nЯкщо чарт має повʼязаний файл підтвердження автентичності, він також буде завантажений.\n\n```shell\nhelm push [chart] [remote] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта реєстру за допомогою цього файлу сертифіката SSL\n  -h, --help                       довідка push\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key-file string            ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\nВхід до або вихід з реєстру\n\n### Опис {#synopsis}\n\nЦя команда містить декілька субкоманд для взаємодії з реєстрами.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка registry\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n* [helm registry login](/helm/helm_registry_login.md) — вхід до реєстру\n* [helm registry logout](/helm/helm_registry_logout.md) — вихід з реєстру\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\nВхід до реєстру\n\n### Опис {#synopsis}\n\nАвтентифікація у віддаленому реєстрі.\n\nНаприклад, для реєстру контейнерів Github:\n\n```shell\necho \"$GITHUB_TOKEN\" | helm registry login ghcr.io -u $GITHUB_USER --password-stdin\n```\n\n```shell\nhelm registry login [host] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string     перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string   ідентифікувати клієнта реєстру за допомогою цього файлу сертифіката SSL\n  -h, --help               довідка login\n      --insecure           дозволити зʼєднання з TLS-реєстром без сертифікатів\n      --key-file string    ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL\n  -p, --password string    пароль для реєстру або токен ідентифікації\n      --password-stdin     пароль для реєстру або токен ідентифікації\n      --plain-http         використовувати незахищені HTTP-зʼєднання для завантаження чартів\n  -u, --username string    імʼя користувача реєстру\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\nВихід з реєстру\n\n### Опис {#synopsis}\n\nВидалення збережених облікових даних для віддаленого реєстру.\n\n```shell\nhelm registry logout [host] [flags]\n```registry logout [host] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка logout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\nДодати, вивести перелік, видалити, оновити та індексувати репозиторії чартів\n\n### Опис {#synopsis}\n\nЦя команда містить кілька субкоманд для взаємодії з репозиторіями чартів.\n\nВона може використовуватися для додавання, видалення, виводу переліку та індексування репозиторіїв чартів.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка repo\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n* [helm repo add](/helm/helm_repo_add.md) — додати репозиторій чартів\n* [helm repo index](/helm/helm_repo_index.md) — згенерувати файл індексу для теки, що містить упаковані чарти\n* [helm repo list](/helm/helm_repo_list.md) — вивести перелік репозиторіїв чартів\n* [helm repo remove](/helm/helm_repo_remove.md) — видалити один або кілька репозиторіїв чартів\n* [helm repo update](/helm/helm_repo_update.md) — оновити інформацію про доступні чарти локально з репозиторіїв чартів\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\nДодати репозиторій чартів\n\n```shell\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --allow-deprecated-repos     стандартно ця команда не дозволяє додавати офіційні репозиторії, які були назавжди видалені. Ця опція вимикає таку поведінку\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n      --force-update               замінити (перезаписати) репозиторій, якщо він уже існує\n  -h, --help                       довідка add\n      --insecure-skip-tls-verify   пропустити перевірку tls-сертифікатів для репозиторію\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль до репозиторію чартів\n      --password-stdin             зчитати пароль до репозиторію чартів з stdin\n      --timeout duration           час очікування завершення завантаження індексного файлу (стандартно 2m0s)\n      --username string            імʼя користувача репозиторію чартів\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\nЗгенерувати файл індексу для теки, що містить упаковані чарти\n\n### Опис {#synopsis}\n\nЧитає поточну теку, створює індексний файл на основі знайдених чартів і записує результат у файл `index.yaml` у поточній теці.\n\nЦей інструмент використовується для створення файлу `index.yaml` для репозиторію чартів. Щоб встановити абсолютний URL-адресу чартів, використовуйте прапорець `--url`.\n\nЩоб обʼєднати згенерований індекс з наявним індексним файлом, використовуйте прапорець `--merge`. У цьому випадку чарти, знайдені в поточній теці, будуть обʼєднані з індексом, переданим за допомогою `--merge`, причому локальні чарти матимуть пріоритет над наявними чартами.\n\n```shell\nhelm repo index [DIR] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help           довідка index\n      --json           вивід у форматі JSON\n      --merge string   обʼєднати згенерований індекс із вказаним індексом\n      --url string     URL репозиторію чартів\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\nВивести перелік репозиторії чартів\n\n```shell\nhelm repo list [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help            довідка list\n  -o, --output format   виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nВидалити один або кілька репозиторіїв чартів\n\n```shell\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка remove\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\nОновити інформацію про доступні чарти локально з репозиторіїв чартів\n\n### Опис {#synopsis}\n\nКоманда update отримує останню інформацію про чарти з відповідних репозиторіїв чартів. Інформація кешується локально, де її використовують такі команди, як `helm search`.\n\nВи можете опційно вказати список репозиторіїв, які ви хочете оновити.\n\n```shell\nhelm repo update <repo_name> ...\n```\n\nЩоб оновити всі репозиторії, використовуйте `helm repo update`.\n\n```shell\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help               довідка update\n      --timeout duration   час очікування завершення завантаження індексного файлу (стандартно 2m0s)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\nВідкотити реліз до попередньої версії\n\n### Опис {#synopsis}\n\nЦя команда відкотить реліз до попередньої версії.\n\nПерший аргумент команди rollback — це імʼя релізу, а другий — номер версії (revision). Якщо цей аргумент пропущений або встановлений на 0, реліз буде повернено до попередньої версії.\n\nЩоб побачити номери версій, виконайте команду `helm history RELEASE`.\n\n```shell\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --cleanup-on-fail               дозволити видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдається\n      --dry-run string[=\"unset\"]      імітує операцію без збереження змін. Повинно бути одним із таких: \"none\" (стандартно), \"client\" або \"server\". '--dry-run=none' виконує операцію у звичайному режимі та зберігає зміни (без імітації). \"--dry-run=client\" імітує операцію лише на стороні клієнта та уникає підключень до кластера. \"--dry-run=server\" імітує операцію на сервері, вимагаючи підключення до кластера. (стандартно \"none\")\n      --force-conflicts               якщо встановлено, 'застосування на стороні сервера' примусово застосує зміни, незважаючи на конфлікти\n      --force-replace                 примусове оновлення ресурсів шляхом заміни\n  -h, --help                          довідка rollback\n      --history-max int               обмежити максимальну кількість збережених ревізій для кожного релізу. Вкажіть 0, щоб не встановлювати обмеження (стандартно 10).\n      --no-hooks                      запобігти виконанню хуків під час відкату\n      --server-side string            повинно бути \"true\", \"false\" або \"auto\". Оновлення обʼєкта виконуються на сервері, а не на клієнті (стандартно \"auto\" використовує значення з попереднього релізу чарту) (стандартно \"auto\")\n      --timeout duration              очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s)\n      --wait WaitStrategy[=watcher]   якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: \"watcher\" і \"legacy\" (стандартно hookOnly).\n      --wait-for-jobs                 якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки вказано в --timeout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\nПошук за ключовим словом у чартах\n\n### Опис {#synopsis}\n\nКоманда Search надає можливість шукати чарти Helm у різних місцях, де вони можуть зберігатися, включаючи Artifact Hub та репозиторії, які ви додали. Використовуйте підкоманди search для пошуку чартів у різних місцях.\n\n### Параметри {#options}\n\n```\n  -h, --help   довідка search\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n* [helm search hub](/helm/helm_search_hub.md) — шукати чарти в Artifact Hub або у власному екземплярі хабу\n* [helm search repo](/helm/helm_search_repo.md) — шукати репозиторії за ключовим словом у чартах\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\nШукати чарти в Artifact Hub або у власному екземплярі хабу\n\n### Опис {#synopsis}\n\nШукайте Helm чарти в Artifact Hub або у власному екземплярі хабу.\n\nArtifact Hub — це вебдодаток, що дозволяє знаходити, встановлювати та публікувати пакети та конфігурації для проєктів CNCF, включаючи загальнодоступні розподілені чарти Helm. Це проєкт пісочниці Cloud Native Computing Foundation. Ви можете переглянути хаб за адресою https://artifacthub.io/\n\nАргумент [KEYWORD] приймає або рядок ключового слова, або рядок у лапках з розширеними параметрами запиту. Документацію щодо розширених параметрів запиту див. за адресою https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n\nПопередні версії Helm використовували екземпляр Monocular як стандартну «точку доступу», тому для забезпечення зворотної сумісності Artifact Hub сумісний з API пошуку Monocular. Аналогічно, при встановленні прапорця `endpoint` вказана точка доступу також повинна реалізовувати точку доступу API пошуку, сумісну з Monocular. Зверніть увагу, що при вказанні екземпляра Monocular як `endpoint` розширені запити не підтримуються. Детальні відомості про API див. на https://github.com/helm/monocular\n\n```shell\nhelm search hub [KEYWORD] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --endpoint string      Екземпляр хаба для запитів чартів (стандартно \"https://hub.helm.sh\")\n      --fail-on-no-result    пошук завершується невдачею, якщо немає результатів\n  -h, --help                 довідка hub\n      --list-repo-url        вивести URL репозиторію чартів\n      --max-col-width uint   максимальна ширина стовпця для таблиці виводу (стандартно 50)\n  -o, --output format        виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm search](/helm/helm_search.md) — пошук за ключовим словом в чартах\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\nПошук репозиторіїв за ключовим словом у чартах\n\n### Опис {#synopsis}\n\nКоманда search проходить через всі репозиторії, налаштовані в системі, і шукає збіги. Пошук цих репозиторіїв використовує метадані, збережені в системі.\n\nВона відобразить останні стабільні версії знайдених чартів. Якщо ви вказуєте прапорець `--devel`, у виводі будуть включені передрелізні версії. Якщо ви хочете шукати за допомогою обмеження версії, використовуйте `--version`.\n\nПриклади:\n\n```shell\n# Шукати стабільні версії релізів, що відповідають ключовому слову \"nginx\"\n$ helm search repo nginx\n\n# Шукати версії релізів, що відповідають ключовому слову \"nginx\", включаючи передрелізні версії\n$ helm search repo nginx --devel\n\n# Шукати останній стабільний реліз для nginx-ingress з основною версією 1\n$ helm search repo nginx-ingress --version ^1.0.0\n```\n\nРепозиторії управляються командами `helm repo`.\n\n```shell\nhelm search repo [keyword] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --devel                використовувати також версії, що знаходяться в розробці ( alpha, beta та release candidate). Еквівалентно версії “>0.0.0-0”. Якщо встановлено --version, це ігнорується.\n      --fail-on-no-result    пошук завершується невдачею, якщо немає результатів\n  -h, --help                 довідка repo\n      --max-col-width uint   максимальна ширина стовпця для таблиці виводу (стандартно 50)\n  -o, --output format        виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n  -r, --regexp               використовувати регулярні вирази для пошуку в репозиторіях, які ви додали\n      --version string       шукати, використовуючи обмеження семантичного версіонування в репозиторіях, які ви додали\n  -l, --versions             показати довгий список, з кожною версією кожного чарту на окремому рядку, для репозиторіїв, які ви додали\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm search](/helm/helm_search.md) — пошук за ключовим словом в чартах\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\nпоказати інформацію про чарт\n\n### Опис {#synopsis}\n\nЦя команда складається з кількох підкоманд для показу інформації про чарт\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка show\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n* [helm show all](/helm/helm_show_all.md) — показати всю інформацію про чарт\n* [helm show chart](/helm/helm_show_chart.md) — показати визначення чарту\n* [helm show crds](/helm/helm_show_crds.md) — показати CRDs чарту\n* [helm show readme](/helm/helm_show_readme.md) — показати README чарту\n* [helm show values](/helm/helm_show_values.md) — показати значення чарту\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\nПоказати всю інформацію про чарт\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) та показує весь його вміст (values.yaml, Chart.yaml, README).\n\n```shell\nhelm show all [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка all\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest'\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\nПоказати визначення чарту\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) і показує вміст файлу Chart.yaml.\n\n```shell\nhelm show chart [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка chart\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest'\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\nПоказати CRDs чарту\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) та показує вміст\nфайлів CustomResourceDefinition (CRD).\n\n```shell\nhelm show crds [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка crds\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest'\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nПоказати README файл чарту\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) та показує вміст файлу README\n\n```shell\nhelm show readme [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка readme\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest'\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\nПоказати значення чарту\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) та показує вміст файлу values.yaml\n\n```shell\nhelm show values [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка values\n      --insecure-skip-tls-verify   пропустити перевірку сертифіката TLS для завантаження чарта\n      --jsonpath string            надайте вираз JSONPath для фільтрування виводу\n      --key-file string            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest'\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\nПоказати статус вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда показує статус вказаного релізу. Статус складається з:\n\n- часу останнього розгортання\n- простору імен k8s, в якому знаходиться реліз\n- стану релізу (може бути: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade або pending-rollback)\n- ревізії релізу\n- опис релізу (може бути повідомленням про завершення або повідомленням про помилку)\n- списку ресурсів, які входять до складу цього релізу\n- детальної інформації про останнє виконання набору тестів, якщо це доречно\n- додаткових приміток, надані в чарті\n\n```shell\nhelm status RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help            довідка status\n  -o, --output format   виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --revision int    якщо вказано, показати статус вказаного релізу з ревізією\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nЛокальний рендеринг шаблонів\n\n### Опис {#synopsis}\n\nСтворює локально шаблон чарту та показує результат.\n\nБудь-які значення, які зазвичай шукалися б або отримувалися в кластері, будуть імітуватися локально. Крім того, жодна з перевірок валідності чарту на сервері (наприклад, перевірка підтримки API) не проводиться.\n\n```shell\nhelm template [NAME] [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -a, --api-versions strings                       версії API Kubernetes, які використовуються для Capabilities.APIVersions (можна вказати декілька)\n      --ca-file string                             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string                           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n      --create-namespace                           створити простір імен релізу, якщо його не існує\n      --dependency-update                          оновити залежності, якщо вони відсутні, перед встановленням чарту\n      --description string                         додати власний опис\n      --devel                                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n      --disable-openapi-validation                 якщо вказано, процес встановлення не буде перевіряти відрендерені шаблони за схемою OpenAPI Kubernetes\n      --dry-run string[=\"unset\"]                   імітує роботу на стороні клієнта або сервера. Повинно бути або: \"client\", або \"server\". '--dry-run=client' імітує роботу тільки на стороні клієнта і уникає підключень до кластера. '--dry-run=server' імітує/перевіряє роботу на сервері, вимагаючи підключення до кластера. (стандартно \"client\")\n      --enable-dns                                 увімкнути DNS запити при рендерингу шаблонів\n      --force-conflicts                            якщо встановлено, 'застосування на стороні сервера' примусово застосує зміни, незважаючи на конфлікти\n      --force-replace                              примусове оновлення ресурсів шляхом заміни\n  -g, --generate-name                              згенерувати імʼя (та опустити параметр NAME)\n  -h, --help                                       довідка template\n      --hide-notes                                 якщо встановлено, не показувати нотатки у виводі встановлення. Не впливає на присутність у метаданих чарту\n      --include-crds                               включити CRDs у вивід шаблонів\n      --insecure-skip-tls-verify                   пропустити перевірку сертифіката TLS для завантаження чарта\n      --is-upgrade                                 встановити .Release.IsUpgrade замість .Release.IsInstall\n      --key-file string                            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string                             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        версія Kubernetes, яка використовується для Capabilities.KubeVersion\n  -l, --labels stringToString                      Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно [])\n      --name-template string                       вказати шаблон для назви релізу\n      --no-hooks                                   запобігти виконанню хуків під час встановлення\n      --output-dir string                          записувати оброблені шаблони у файли в output-dir замість stdout\n      --pass-credentials                           передати облікові дані всім доменам\n      --password string                            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --post-renderer postRendererString           назва втулка типу postrenderer, який буде використовуватися для пострендерингу. Якщо він існує, втулок буде використовуватися\n      --post-renderer-args postRendererArgsSlice   аргумент до пост-рендерера (можна вказати кілька) (стандартно [])\n      --release-name                               використовувати імʼя релізу в шляху output-dir\n      --render-subchart-notes                      якщо вказано, рендерити нотатки субчартів разом з батьківським\n      --replace                                    повторно використовувати задане імʼя, тільки якщо це імʼя є видаленим релізом, який залишається в історії. Це небезпечно в операційному середовищі.\n      --repo string                                URL репозиторію чартів, де розташований запитуваний чарт\n      --rollback-on-failure                        якщо встановлено, Helm скасує (деінсталює) встановлення у разі невдачі. Прапорець --wait буде стандартно встановлений у \"watcher\", якщо встановлено --rollback-on-failure.\n      --server-side                                оновлення обʼєктів виконуються на сервері, а не на клієнті (стандартно true)\n      --set stringArray                            встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --set-file stringArray                       встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2)\n      --set-json stringArray                       встановити значення JSON у командному рядку (можна вказати кілька значень або розділити їх комами: key1=jsonval1,key2=jsonval2 або використовувати формат json: {\"key1\": jsonval1, \"key2\": \"jsonval2\"})\n      --set-literal stringArray                    встановити літеральне значення STRING в командному рядку\n      --set-string stringArray                     встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n  -s, --show-only stringArray                      only show manifests rendered from the given templates\n      --skip-crds                                  якщо вказано, CRD не буде встановлено. Стандартно CRD встановлюються, якщо їх ще немає\n      --skip-schema-validation                     якщо встановлено, вимикає перевірку схеми JSON\n      --skip-tests                                 пропустити тести з виводу шаблонів\n      --take-ownership                             якщо встановлено, встановлення ігноруватиме перевірку анотацій Helm і перейматиме право власності на наявні ресурси\n      --timeout duration                           очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s)\n      --username string                            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n  -f, --values strings                             вказати значення в YAML файлі або URL (можна вказати кілька)\n      --verify                                     перевірити пакет перед використанням\n      --version string                             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest'\n      --wait WaitStrategy[=watcher]                якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: \"watcher\" і \"legacy\" (стандартно hookOnly).\n      --wait-for-jobs                              якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки вказано в --timeout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\nЗапуск тестів для релізу\n\n### Опис {#synopsis}\n\nКоманда test запускає тести для релізу.\n\nАргументом цієї команди є імʼя розгорнутого релізу. Тести, що будуть виконані, визначені у чарті, який був встановлений.\n\n```shell\nhelm test [RELEASE] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --filter strings     вказати тести за атрибутом (в даний час \"name\") використовуючи синтаксис attribute=value або '!attribute=value', щоб виключити тест (можна вказати кілька або розділити значення комами: name=test1,name=test2)\n  -h, --help               довідка test\n      --logs               отримати логи з тестових podʼів (це виконується після завершення всіх тестів, але перед будь-яким очищенням)\n      --timeout duration   очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\nВидалення релізу\n\n### Опис {#synopsis}\n\nЦя команда приймає імʼя релізу і видаляє його.\n\nВона видаляє всі ресурси, асоційовані з останнім релізом чарту, а також історію релізу, звільняючи його для подальшого використання.\n\nВикористовуйте прапорець `--dry-run`, щоб побачити, які релізи будуть видалені без фактичного видалення.\n\n```shell\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --cascade string                Має бути \"background\", \"orphan\" або \"foreground\". Вибирає стратегію каскадного видалення для залежних ресурсів. Стандартно background. (стандартно \"background\")\n      --description string            додати власний опис\n      --dry-run                       симулювати видалення\n  -h, --help                          довідка uninstall\n      --ignore-not-found              Вважати \"release not found\" як успішне видалення\n      --keep-history                  видалити всі асоційовані ресурси і помітити реліз як видалений, але зберегти історію релізу\n      --no-hooks                      запобігти виконанню хуків під час видалення\n      --timeout duration              очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s)\n      --wait WaitStrategy[=watcher]   якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: \"watcher\" і \"legacy\" (стандартно hookOnly).\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nОновлення релізу\n\n### Опис {#synopsis}\n\nЦя команда оновлює реліз до нової версії чарту.\n\nАргументи для оновлення повинні містити реліз і чарт. Аргумент чарту може бути або: посилання на чарт ('example/mariadb'), шлях до теки з чартом, упакований чарт або повністю кваліфікований URL. Для посилань на чарт буде використовуватись остання версія 'latest', якщо не встановлено прапорець `--version`.\n\nЩоб перевизначити значення в чарті, використовуйте прапорець `--values` з файлом або прапорець `--set` з конфігурацією з командного рядка. Щоб примусово встановити значення string, використовуйте `--set-string`. Ви можете використовувати `--set-file`, щоб встановити окремі значення з файлу, якщо саме значення занадто довге для командного рядка або генерується динамічно. Ви також можете використовувати `--set-json` для встановлення значень json (скалярів/обʼєктів/масивів) з командного рядка. Крім того, ви можете використовувати `--set-json` і передавати обʼєкт json як рядок.\n\nВи можете вказати прапорець `--values`/`-f` кілька разів. Пріоритет буде надано останньому (правому) файлу. Наприклад, якщо і myvalues.yaml, і override.yaml містять ключ 'Test', значення, задане в override.yaml, матиме пріоритет:\n\n```shell\n$ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n```\n\nВи можете вказати прапорець `--set` кілька разів. Пріоритет буде надано останньому (правому) заданому значенню. Наприклад, якщо значення 'bar' і 'newbar' встановлені для ключа 'foo', значення 'newbar' матиме пріоритет:\n\n```shell\n$ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n```\n\nВи також можете оновити значення для поточного релізу за допомогою цієї команди з прапорцем `--reuse-values`. Аргументи 'RELEASE' і 'CHART' повинні бути встановлені на оригінальні параметри, поточні значення будуть обʼєднані з будь-якими значеннями, заданими через прапорці `--values`/`-f` або `--set`. Пріоритет надається новим значенням.\n\n```shell\n$ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n```\n\nПрапорець `--dry-run` виведе усі згенеровані маніфести чартів, включно з секретами, які можуть містити конфіденційні значення. Для приховування секретів Kubernetes використовуйте прапорець `--hide-secret`.  Будь ласка, ретельно обміркуйте, як і коли використовувати ці прапорці.\n\n```shell\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string                             перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA\n      --cert-file string                           ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL\n      --cleanup-on-fail                            дозволити видалення нових ресурсів, створених в цьому оновленні, коли оновлення не вдалося\n      --create-namespace                           якщо встановлено --install, створити простір імен релізу, якщо його немає\n      --dependency-update                          оновити залежності, якщо вони відсутні, перед встановленням чарту\n      --description string                         додати власний опис\n      --devel                                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n      --disable-openapi-validation                 якщо встановлено, процес оновлення не буде перевіряти відрендерені шаблони на відповідність Kubernetes OpenAPI Schema\n      --dry-run string[=\"unset\"]                   імітує операцію без збереження змін. Повинно бути одним із таких: \"none\" (стандартно), \"client\" або \"server\". '--dry-run=none' виконує операцію у звичайному режимі та зберігає зміни (без імітації). \"--dry-run=client\" імітує операцію лише на стороні клієнта та уникає підключень до кластера. \"--dry-run=server\" імітує операцію на сервері, вимагаючи підключення до кластера. (стандартно \"none\")\n      --enable-dns                                 увімкнути DNS запити при рендерингу шаблонів\n      --force-conflicts                            якщо встановлено, 'застосування на стороні сервера' примусово застосує зміни, незважаючи на конфлікти\n      --force-replace                              примусове оновлення ресурсів шляхом заміни\n  -h, --help                                       довідка upgrade\n      --hide-notes                                 якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту\n      --hide-secret                                приховати Kubernetes Secrets, якщо також використовується прапорець --dry-run\n      --history-max int                            обмежити максимальну кількість збережених ревізій для кожного релізу. Вкажіть 0, щоб не встановлювати обмеження (стандартно 10).\n      --insecure-skip-tls-verify                   пропустити перевірку сертифіката TLS для завантаження чарта\n  -i, --install                                    якщо релізу з цим імʼям ще не існує, виконується установка\n      --key-file string                            ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL\n      --keyring string                             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Мітки, які будуть додані до метаданих релізу. Мають бути розділені комою. Оригінальні мітки релізу будуть обʼєднані з мітками оновлення. Ви можете скинути мітку, використовуючи null. (стандартно [])\n      --no-hooks                                   вимкнути хуки перед/після оновлення\n  -o, --output format                              виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --pass-credentials                           передати облікові дані всім доменам\n      --password string                            пароль сховища чартів, де знаходиться запитуваний чарт\n      --plain-http                                 використовувати незахищені HTTP-зʼєднання для завантаження чартів\n      --post-renderer postRendererString           назва втулка типу postrenderer, який буде використовуватися для пострендерингу. Якщо він існує, втулок буде використовуватися\n      --post-renderer-args postRendererArgsSlice   аргумент до пост-рендерера (можна вказати кілька) (стандартно [])\n      --render-subchart-notes                      якщо вказано, рендерити нотатки субчартів разом з батьківським\n      --repo string                                URL репозиторію чартів, де розташований запитуваний чарт\n      --reset-then-reuse-values                    при оновленні, скинути значення до вбудованих у чарт значень, застосувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values' або '--reuse-values', це буде проігноровано\n      --reset-values                               при оновленні, скинути значення до вбудованих у чарт значень\n      --reuse-values                               при оновленні, повторно використовувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values', це буде проігноровано\n      --rollback-on-failure                        якщо встановлено, Helm відновить попередній успішний реліз у разі невдачі. Прапорець --wait буде стандартно встановлений на \"watcher\", якщо встановлено --rollback-on-failure.\n      --server-side string                         повинно бути \"true\", \"false\" або \"auto\". Оновлення обʼєкта виконуються на сервері, а не на клієнті (стандартно \"auto\" використовує значення з попереднього релізу чарту) (стандартно \"auto\")\n      --set stringArray                            встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --set-file stringArray                       встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2)\n      --set-json stringArray                       встановити значення JSON у командному рядку (можна вказати кілька значень або розділити їх комами: key1=jsonval1,key2=jsonval2 або використовувати формат json: {\"key1\": jsonval1, \"key2\": \"jsonval2\"})\n      --set-literal stringArray                    встановити літеральне значення STRING в командному рядку\n      --set-string stringArray                     встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --skip-crds                                  якщо встановлено, CRDs не будуть встановлені під час виконання оновлення з увімкненим прапорцем install. Стандартно, CRDs встановлюються, якщо ще не присутні, під час виконання оновлення з увімкненим прапорцем install\n      --skip-schema-validation                     якщо встановлено, вимикає перевірку схеми JSON\n      --take-ownership                             якщо встановлено, оновлення проігнорує перевірку анотацій Helm і перейме право власності на наявні ресурси\n      --timeout duration                           очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s)\n      --username string                            імʼя користувача сховища чартів, де знаходиться запитуваний чарт\n  -f, --values strings                             вказати значення в YAML файлі або URL (можна вказати кілька)\n      --verify                                     перевірити пакет перед використанням\n      --version string                             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest'\n      --wait WaitStrategy[=watcher]                якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: \"watcher\" і \"legacy\" (стандартно hookOnly).\n      --wait-for-jobs                              якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки вказано в --timeout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\nПеревірити, що чарт за вказаним шляхом підписаний і є дійсним\n\n### Опис {#synopsis}\n\nПеревірте, чи має даний чарт дійсний файл походження.\n\nФайли походження забезпечують криптографічну перевірку того, що чарт не був підроблений і був упакований надійним постачальником.\n\nЦю команду можна використовувати для перевірки локального чарту. Декілька інших команд мають прапорці `—verify`, які виконують ту саму перевірку. Щоб створити підписаний пакет, використовуйте команду `helm package --sign`.\n\n```shell\nhelm verify PATH [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help             довідка verify\n      --keyring string   вʼязка ключів, що містить відкриті ключі ( стандартно \"~/.gnupg/pubring.gpg\")\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n\nВивід інформації про версію Helm\n\n### Опис {#synopsis}\n\nПоказує версію Helm.\n\nКоманда виведе на екран інформацію про версію Helm. Результат буде виглядати приблизно так:\n\n```console\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n```\n\n- Version — семантична версія релізу.\n- GitCommit — SHA коміту, з якого була збудована ця версія.\n- GitTreeState — \"clean\", якщо при створенні цього бінарного файлу не було локальних змін у коді, і \"dirty\", якщо бінарний файл був збудований з локально зміненого коду.\n- GoVersion — версія Go, яка була використана для компіляції Helm.\n\nПри використанні прапорця `--template` доступні такі властивості для використання в шаблоні:\n\n- `.Version` — містить семантичну версію Helm\n- `.GitCommit` — git коміт\n- `.GitTreeState` — стан git дерева, коли був збудований Helm\n- `.GoVersion` — містить версію Go, з якою був зібраний Helm\n\nНаприклад, `--template='Version: {{.Version}}'` надрукує `'Version: v3.2.1'`.\n\n```shell\nhelm version [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка version\n      --short             вивести номер версії\n      --template string   шаблон для формату рядка версії\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --color string                    використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --colour string                   використовувати кольоровий вивід (never, auto, always) (стандартно \"auto\")\n      --content-cache string            шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно \"~/.cache/helm/content\")\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці (СА) для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 14 січня 2026 року\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/helm/index.mdx",
    "content": "---\ntitle: Команди Helm\ndescription: Документація для повного списку команд CLI для Helm.\nsidebar_position: 6\nid: helm-category\n---\n\n# Команди Helm {#helm-commands}\n\nТут ви знайдете список команд CLI для Helm з інформацією щодо їх використання.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action для автоматизації публікації чартів на GitHub Pages\ndescription: Описує, як використовувати Chart Releaser Action для автоматизації публікації чартів за допомогою GitHub Pages.\nsidebar_position: 3\n---\n\nЦей посібник описує, як використовувати [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).\n\n## Зміни в репозиторії {#repository-changes}\n\nСтворіть Git-репозиторій у вашій організації на GitHub. Ви можете назвати репозиторій `helm-charts`, хоча інші назви також прийнятні. Сирці всіх чартів можуть бути розміщені в гілці `main`. Чарти повинні бути розміщені в теці `/charts` на верхньому рівні дерева тек.\n\nТакож має бути інша гілка з назвою `gh-pages`, щоб публікувати чарти. Зміни в цій гілці будуть автоматично створюватися за допомогою Chart Releaser Action, описаного тут. Крім створення гілки `gh-pages` ви можете додати файл `README.md` до неї, який буде показуватись користувачам, що відвідують сторінку.\n\nВи можете додати інструкції в `README.md` щодо встановлення чартів, як показано нижче (замініть `<alias>`, `<orgname>`, і `<chart-name>`):\n\n```md\n## Використання\n\nЩоб використовувати чарти, необхідно встановити [Helm](https://helm.sh/uk).\nБудь ласка, ознайомтеся з [документацією Helm](https://helm.sh/uk/docs), щоб розпочати.\n\nЯк тільки Helm буде налаштовано правильно, додайте репозиторій наступним чином:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nЯкщо ви вже додавали цей репозиторій раніше, виконайте команду `helm repo update`,\nщоб отримати останні версії пакетів. Потім ви можете виконати `helm search repo <alias>`, щоб побачити чарти.\n\nЩоб встановити чарт `<chart-name>`:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nЩоб видалити чарт:\n\n    helm uninstall my-<chart-name>\n```\n\nЧарти будуть опубліковані на вебсайті з URL-адресою типу:\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions Workflow {#github-actions-workflow}\n\nСтворіть файл GitHub Actions workflow в гілці `main` за адресою `.github/workflows/release.yml`:\n\n```yaml\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v5\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.7.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nНаведена конфігурація використовує [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action), щоб перетворити ваш GitHub проєкт на самостійний репозиторій чартів Helm. Вона виконує це під час кожної операції push в гілку `main` шляхом перевірки кожного чарту у вашому проєкті, і коли знаходить нову версію чарту, створює відповідний реліз GitHub, додає артефакти Helm чарту до релізу і створює або оновлює файл `index.yaml` з метаданими про ці релізи, який потім хоститься на GitHub Pages.\n\nВерсія Chart Releaser Action, використана в наведеному прикладі, — `v1.7.0`. Ви можете змінити її на [останню доступну версію](https://github.com/helm/chart-releaser-action/releases).\n\n:::note\nChart Releaser Action майже завжди використовується в парі з [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) та [Kind Action](https://github.com/marketplace/actions/kind-cluster).\n:::\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: Синхронізація вашого репозиторію чартів\ndescription: Описує, як синхронізувати ваші локальні та віддалені репозиторії чартів.\nsidebar_position: 2\n---\n\n:::note\nЦей приклад для хмарного сховища Google (Google Cloud Storage, GCS), кошик якого використовується як репозиторій чартів.\n:::\n\n## Попередні умови {#prerequisites}\n\n* Встановіть [gsutil](https://cloud.google.com/storage/docs/gsutil). *Ми значною мірою покладаємося на використання gsutil rsync.*\n* Переконайтеся, що у вас є доступ до бінарного файлу Helm.\n* _Опціонально: Ми рекомендуємо увімкнути [версіювання обʼєктів](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) у вашому сховищі GCS, на випадок, якщо ви випадково щось видалите._\n\n## Налаштування локальної теки репозиторію чартів {#set-up-a-local-chart-repository-directory\n\nСтворіть локальну теку, як ми це робили в [керівництві з репозиторію чартів](/topics/chart_repository.md), і помістіть ваші упаковані чарти в цю теку.\n\nНаприклад:\n\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Генерація оновленого файлу index.yaml {#generate-an-updated-index.yaml}\n\nВикористовуйте Helm для генерації оновленого файлу index.yaml, передавши шлях до теки та URL-адресу віддаленого репозиторію команді `helm repo index`, як показано нижче:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\n\nЦе згенерує оновлений файл index.yaml і помістить його в теку `fantastic-charts/`.\n\n## Синхронізація ваших локальних та віддалених репозиторіїв чартів {#sync-your-local-and-remote-chart-repositories}\n\nЗавантажте вміст теки у ваше сховище GCS, запустивши `scripts/sync-repo.sh` та передавши назву локальної теки та назву сховища GCS.\n\nНаприклад:\n\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n\n## Оновлення вашого репозиторію чартів {#updating-your-chart-repository}\n\nВи захочете зберегти локальну копію вмісту вашого репозиторію чартів або використати `gsutil rsync` для копіювання вмісту вашого віддаленого репозиторію чартів до локальної теки.\n\nНаприклад:\n\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # прапорець -n виконує пробний запуск\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # виконує дії копіювання\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nКорисні посилання:\n\n* Документація [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [Керівництво репозиторію чартів](/topics/chart_repository.md)\n* Документація щодо [версіювання обʼєктів та керування паралельністю](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) в Google Cloud Storage\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Поради та підказки щодо створення чартів\ndescription: Містить деякі поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової якості.\nsidebar_position: 1\n---\n\nЦей посібник містить поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової якості.\n\n## Знайомство з функціями шаблону {#know-your-template-functions}\n\nHelm використовує [шаблони Go](https://godoc.org/text/template) для шаблонування ваших ресурсних файлів. Хоча Go поставляється з кількома вбудованими функціями, ми додали багато інших.\n\nПо-перше, ми додали всі функції з [бібліотеки Sprig](https://masterminds.github.io/sprig/), за винятком `env` та `expandenv`, з міркувань безпеки.\n\nМи також додали дві спеціальні функції шаблонів: `include` і `required`. Функція `include` дозволяє додавати інший шаблон і передавати результати іншим функціям шаблонів.\n\nНаприклад, цей фрагмент шаблону включає шаблон з назвою `mytpl`, потім приводить результат у нижньому регістрі та огртає його подвійними лапками.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nФункція `required` дозволяє оголосити певне значення як обовʼязкове для рендерингу шаблону.  Якщо значення порожнє, рендеринг шаблону завершиться з помилкою, про яку буде повідомлено користувачеві.\n\nНаступний приклад використання функції `required` оголошує запис для `.Values.who` обовʼязковим і виводить повідомлення про помилку, якщо цього запис відсутній:\n\n```yaml\nvalue: {{ required \"Потрібен запис .Values.who!\" .Values.who }}\n```\n\n## Використовуйте лапки для рядків, не використовуйте лапки для цілих чисел {#quote-strings-dont-quote-integers}\n\nКоли ви працюєте з рядковими даними, завжди безпечніше використовувати лапки для рядків, ніж залишати їх без лапок:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nАле при роботі з цілими числами _не беріть значення в лапки._ Це може викликати помилки розбору значень всередині Kubernetes.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nЦе зауваження не стосується значень змінних середовища, які повинні бути рядками, навіть якщо вони представляють цілі числа:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Використання функції 'include' {#using-the-include-function}\n\nGo надає спосіб включати один шаблон в інший за допомогою вбудованої директиви `template`. Однак вбудована функція не може використовуватися в конвеєрах шаблонів Go.\n\nЩоб включити шаблон і виконати операцію з його результатом, Helm має спеціальну функцію `include`:\n\n```go\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nВищезазначене включає шаблон з назвою `toYaml`, передає йому `$value`, а потім передає результат з цього шаблону у функцію `indent`.\n\nОскільки в YAML важливі відступи, це чудовий спосіб включати фрагменти коду, зберігаючи відступи в релевантному контексті.\n\n## Використання функції 'required' {#using-the-required-function}\n\nGo надає можливість налаштування опцій шаблону для контролю поведінки, коли map індексується за допомогою ключа, якого немає в map. Зазвичай це налаштовується за допомогою `template.Options(\"missingkey=option\")`, де `option` може бути `default`, `zero` або `error`. Якщо встановити цю опцію на error, виконання зупиниться з помилкою, але це стосуватиметься кожного відсутнього ключа в map. Можуть бути ситуації, коли розробник чарту хоче застосувати цю поведінку для вибраних значень у файлі `values.yaml`.\n\nФункція `required` дає розробникам можливість оголосити значення обовʼязковим для роботи в шаблоні. Якщо значення відсутнє в `values.yaml`, шаблон повертає повідомлення про помилку, надане розробником.\n\nНаприклад:\n\n```go\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nНаведена вище конструкція використає шаблон, коли `.Values.foo` визначено, але не зможе це зробити та вийде з помилкою, коли `.Values.foo` не визначено.\n\n## Використання функції 'tpl' {#using-the-tpl-function}\n\nФункція `tpl` дозволяє розробникам обробляти рядки як шаблони всередині шаблону. Це корисно для передачі рядка шаблону як значення до чарту або для рендерингу зовнішніх файлів конфігурації. Синтаксис: `{{ tpl TEMPLATE_STRING VALUES }}`\n\nПриклади:\n\n```yaml\n# значення\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# шаблон\n{{ tpl .Values.template . }}\n\n# результат\nTom\n```\n\nСтворення зовнішнього файлу конфігурації:\n\n```yaml\n# зовнішній конфігураційний файл conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# значення\nfirstName: Peter\nlastName: Parker\n\n# шаблон\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# результат\nfirstName=Peter\nlastName=Parker\n```\n\n## Створення секретів для отримання образів {#creating-image-pull-secrets}\n\nСекрети для отримання образів по суті є комбінацією _registry_, _username_ та _password_. Вони можуть знадобитися у застосунку, який ви розгортаєте, але для їх створення потрібно кілька разів запустити `base64`. Ми можемо написати допоміжний шаблон, щоб скласти файл конфігурації Docker для використання у вигляді даних для секрету. Ось приклад:\n\nПо-перше, припустимо, що облікові дані визначені у файлі `values.yaml` наступним чином:\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nМи визначаємо наш допоміжний шаблон наступним чином:\n\n```go\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":\\\"%s\\\",\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username .password .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nНарешті, ми використовуємо допоміжний шаблон у більшому шаблоні для створення маніфесту Secret:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Автоматичне викатування розгортань {#automatically-roll-deployments}\n\nЧасто ConfigMaps або Secrets підключаються як конфігураційні файли в контейнери або є інші зовнішні зміни залежностей, які вимагають перезапуску podʼів. Залежно від застосунку, перезапуск може знадобитися, якщо вони оновлюються при наступному `helm upgrade`, але якщо самі специфікації deployment не змінюються, застосунок продовжує працювати зі старою конфігурацією, що призводить до неконсистентного deployment.\n\nФункція `sha256sum` може бути використана для забезпечення оновлення секції анотацій розгортання, якщо змінюється інший файл:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\n:::note\nЯкщо ви додаєте це до бібліотечного чарту, ви не зможете отримати доступ до вашого файлу в `$.Template.BasePath`. Замість цього можна посилатися на ваше визначення за допомогою `{{ include (\"mylibchart.configmap\") . | sha256sum }}`.\n:::\n\nУ випадку, коли ви завжди хочете перезапустити свій deployment, ви можете використати аналогічний крок з анотацією, як вище, замінивши його випадковим рядком, щоб він завжди змінювався і викликав перезапуск deployment:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nКожен виклик функції шаблону генеруватиме унікальний випадковий рядок. Це означає, що якщо необхідно синхронізувати випадкові рядки, що використовуються декількома ресурсами, всі відповідні ресурси повинні бути в одному файлі шаблону.\n\nОбидва ці методи дозволяють вашому deployment використовувати вбудовану логіку стратегії оновлення, щоб уникнути простоїв.\n\n:::note\nРаніше ми рекомендували використовувати прапорець `--recreate-pods` як інший варіант. Цей прапорець було позначено застарілим у Helm 3 на користь більш декларативного методу, описаного вище.\n:::\n\n## Скажіть Helm не видаляти ресурс {#tell-helm-not-to-uninstall-a-resource}\n\nІноді є ресурси, які не слід видаляти під час виконання команди `helm uninstall`. Розробники чартів можуть додати анотацію до ресурсу, щоб запобігти його видаленню.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nАнотація `helm.sh/resource-policy: keep` говорить Helm не видаляти цей ресурс, коли операція Helm (така як `helm uninstall`, `helm upgrade` або `helm rollback`) призвела б до його видалення. _Однак_, цей ресурс стає сиротою. Helm більше не керує ним у будь-який спосіб. Це може призвести до проблем, якщо використовувати `helm install --replace` для релізу, який вже був видалений, але зберіг ресурси.\n\n## Використання \"Partials\" та включень шаблонів {#using-partials-and-template-includes}\n\nІноді ви хочете створити в чарті деякі повторно використовувані частини, будь то блоки або часткові шаблони. І часто зручніше зберігати їх у власних файлах.\n\nУ теці `templates/`, будь-який файл, що починається з підкреслення (`_`), не призначений для виведення файлу маніфесту Kubernetes. Таким чином, за домовленістю, допоміжні шаблони та частки шаблонів розміщуються у файлі `_helpers.tpl`.\n\n## Комплексні чарти з багатьма залежностями {#complex-charts-with-many-dependencies}\n\nБагато чартів у CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є \"будівельними блоками\" для створення складніших застосунків. Але чарти можуть бути використані для створення екземплярів великомасштабних застосунків. У таких випадках один основний чарт може мати декілька вкладених субчартів, кожен з яких функціонує як частина цілого.\n\nНайкращою практикою для збирання комплексного застосунку з окремих частин є створення основного чарту, який надає глобальні конфігурації, а потім використання підтеки `charts/` для вбудовування кожного з компонентів.\n\n## YAML — це надмножина JSON {#yaml-is-a-superset-of-json}\n\nЗгідно зі специфікацією YAML, YAML є надмножиною JSON. Це означає, що будь-яка допустима структура JSON має бути дійсною в YAML.\n\nЦе має перевагу: іноді розробникам шаблонів може бути простіше виразити структуру даних з синтаксисом, схожим на JSON, ніж мати справу з чутливістю YAML до пробілів.\n\nЯк правило, шаблони повинні відповідати синтаксису, схожому на YAML, _якщо_ синтаксис JSON суттєво не знижує ризик виникнення проблем з форматуванням.\n\n## Будьте обережні з генерацією випадкових значень {#be-careful-with-generating-random-values}\n\nУ Helm є функції, які дозволяють генерувати випадкові дані, криптографічні ключі тощо. Вони цілком придатні для використання. Але майте на увазі, що під час оновлень шаблони виконуються знову. Коли виконання шаблону генерує дані, що відрізняються від останнього виконання, це викликає оновлення цього ресурсу.\n\n## Встановлення або оновлення релізу однією командою {#install-or-upgrade-a-release-with-one-command}\n\nHelm надає можливість виконати встановлення або оновлення як одну команду. Використовуйте команду `helm upgrade` з прапорцем `--install`. Це змусить Helm перевірити, чи реліз вже встановлено. Якщо ні, буде виконано встановлення. Якщо так, то наявний реліз буде оновлено.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/howto/index.mdx",
    "content": "---\ntitle: Поради\nsidebar_position: 3\n---\n\n# Поради\n\nТут ви знайдете короткі відповіді на питання типу «Як я можу….?» Ці посібники не охоплюють теми в деталях — ви знайдете такі матеріали в [Тематичних посібниках](/topics/index.mdx). Однак ці посібники допоможуть вам швидко виконати поширені завдання.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/index.mdx",
    "content": "---\ntitle: Документація\ndescription: Все, що вам потрібно знати про те, як організована документація.\nsidebar_position: 1\n---\n\n# Ласкаво просимо\n\nЛаскаво просимо до документації [Helm](https://helm.sh/). Helm — це менеджер пакетів для Kubernetes. Детальну інформацію про нього можна знайти у [звіті CNCF Helm Project Journey](https://www.cncf.io/cncf-helm-project-journey/).\n\nimport DocCardList from \"@theme/DocCardList\";\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/intro/CheatSheet.mdx",
    "content": "---\ntitle: Шпаргалка\ndescription: Шпаргалка Helm\nsidebar_position: 4\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nПідказки Helm з усіма необхідними командами для керування застосунками за допомогою Helm.\n\n---\n\n### Основні інтерпретації/контекст {#basic-interpretationscontext}\n\n**Chart (Чарт):**\n\n- Це назва вашого чарту у випадку, якщо його було завантажено та розпаковано.\n- Це `<repo_name>/<chart_name>`, якщо репозиторій був доданий, але чарт не завантажений.\n- Це URL/Абсолютний шлях до чарту.\n\n**Name (Назва):**\n\n- Це назва, яку ви хочете надати вашій поточній установці Helm-чарту.\n\n**Release (Реліз):**\n\n- Це назва, яку ви присвоїли екземпляру установки.\n\n**Revision (Версія):**\n\n- Це значення з команди Helm history.\n\n**Repo-name (Назва репозиторію):**\n\n- Назва репозиторію.\n\n**DIR (Тека):**\n\n- Назва/шлях теки.\n\n---\n\n### Управління чартами {#chart-management}\n\n```bash\nhelm create <name>                      # Cтворює теку чарту разом з загальними файлами та теками, які використовуються в чарті.\nhelm package <chart-path>               # Упаковує чарт у файл архіву з версією.\nhelm lint <chart>                       # Запускає тести для перевірки чарту та виявлення можливих проблем.\nhelm show all <chart>                   # Переглядає чарт та виводить його вміст.\nhelm show values <chart>                # Показує вміст файлу values.yaml.\nhelm pull <chart>                       # Завантажує/витягує чарт.\nhelm pull <chart> --untar=true          # Якщо встановлено в true, розпаковує чарт після завантаження.\nhelm pull <chart> --verify              # Перевіряє пакет перед використанням.\nhelm pull <chart> --version <number>    # Стандартно використовується остання версія, вкажіть обмеження версії для використання чарту.\nhelm dependency list <chart>            # Відображає список залежностей чарту.\n```\n\n---\n\n### Встановлення та видалення застосунків {#install-and-uninstall-apps}\n\n```bash\nhelm install <name> <chart>                           # Встановлює чарт з зазначеною назвою.\nhelm install <name> <chart> --namespace <namespace>   # Встановлює чарт у певному просторі імен.\nhelm install <name> <chart> --set key1=val1,key2=val2 # Встановлює значення в командному рядку (можна вказати кілька значень, розділених комами).\nhelm install <name> <chart> --values <yaml-file/url>  # Встановлює чарт з вказаними вами значеннями.\nhelm install <name> <chart> --dry-run --debug         # Запускає тестове встановлення для перевірки чарту.\nhelm install <name> <chart> --verify                  # Перевіряє пакет перед використанням.\nhelm install <name> <chart> --dependency-update       # Оновлює залежності, якщо вони відсутні, перед встановленням чарту.\nhelm uninstall <name>                                 # Видаляє реліз з поточного (default) простору імен\nhelm uninstall <release-name> --namespace <namespace> # Видаляє реліз із зазначеного простору імен\n```\n\n---\n\n### Оновлення та відкат застосунків {#perform-app-upgrade-and-rollback}\n\n```bash\nhelm upgrade <release> <chart>                            # Оновлює реліз.\nhelm upgrade <release> <chart> --atomic                   # Якщо встановлено, процес оновлення поверне зміни в разі невдалого оновлення.\nhelm upgrade <release> <chart> --dependency-update        # Оновлює залежності, якщо вони відсутні, перед встановленням чарту.\nhelm upgrade <release> <chart> --version <version_number> # Вказує обмеження версії для використання чарту.\nhelm upgrade <release> <chart> --values                   # Вказує значення у YAML файлі або URL (можна вказати кілька).\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Встановлює значення в командному рядку (можна вказати кілька значень).\nhelm upgrade <release> <chart> --force                    # Примусове оновлення ресурсів з використанням  стратегії заміни.\nhelm rollback <release> <revision>                        # Повертає реліз до певної версії.\nhelm rollback <release> <revision>  --cleanup-on-fail     # Дозволяє видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдалося здійснити.\n```\n\n---\n\n### Вивід списку, додавання, видалення та оновлення репозиторіїв {#list-add-remove-and-update-repositories}\n\n```bash\nhelm repo add <repo-name> <url>   # Додає репозиторій з Інтернету.\nhelm repo list                    # Переглядає список доданих репозиторіїв чартів.\nhelm repo update                  # Оновлює інформацію про доступні чарти локально з репозиторіїв чартів.\nhelm repo remove <repo_name>      # Видаляє один або кілька репозиторіїв чартів.\nhelm repo index <DIR>             # Читає поточну теку та генерує файл індексу на основі знайдених чартів.\nhelm repo index <DIR> --merge     # Зливає згенерований індекс з наявним файлом індексу.\nhelm search repo <keyword>        # Шукає в репозиторіях за ключовим словом в чарті.\nhelm search hub <keyword>         # Шукає чарт в Artifact Hub або у вашому власному хабі.\n```\n\n---\n\n## Моніторинг релізів Helm {#helm-release-monitoring}\n\n```bash\nhelm list                       # Виводить список всіх релізів для вказаного простору імен, використовує поточний контекст простору імен, якщо простір імен не вказано.\nhelm list --all                 # Показує всі релізи без жодних фільтрів, можна використовувати -a.\nhelm list --all-namespaces      # Переглядає релізи по всіх просторах імен, можна використовувати -A.\nhelm list -l key1=value1,key2=value2 # Селектор (запит за мітками) для фільтрації, підтримує '=', '==' і '!='.\nhelm list --date                # Сортує за датою релізу.\nhelm list --deployed            # Показує розгорнуті релізи. Якщо не вказано інше, це буде автоматично увімкнено.\nhelm list --pending             # Показує очікуючі релізи.\nhelm list --failed              # Показує невдалі релізи.\nhelm list --uninstalled         # Показує видалені релізи (якщо використовувався 'helm uninstall --keep-history').\nhelm list --superseded          # Показує замінені релізи.\nhelm list -o yaml               # Виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table).\nhelm status <release>           # Ця команда показує статус зазначеного релізу.\nhelm status <release> --revision <number>   # Якщо встановлено, показує статус зазначеного релізу з версією.\nhelm history <release>          # Історичні версії для даного релізу.\nhelm env                        # Env виводить всю інформацію про середовище, що використовується Helm.\n```\n\n---\n\n### Завантаження інформації про реліз {#download-release-information}\n\n```bash\nhelm get all <release>      # Зручний для сприйняття набір інформації про нотатки, хуки, надані значення та згенерований маніфест-файл даного релізу.\nhelm get hooks <release>    # Завантажує хуки для вказаного релізу. Хуки форматує у YAML і розділяє за допомогою роздільника YAML '---\\n'.\nhelm get manifest <release> # Маніфест — це представлення ресурсів Kubernetes у форматі YAML, які були згенеровані з чартів цього релізу. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені до маніфесту.\nhelm get notes <release>    # Показує нотатки, надані чартом для зазначеного релізу.\nhelm get values <release>   # Завантажує файл значень для даного релізу. Використовуйте -o для форматування виводу.\n```\n\n---\n\n### Управління втулками {#plugin-management}\n\n```bash\nhelm plugin install <path/url1>     # Встановлення втулків.\nhelm plugin list                    # Перегляд списку всіх встановлених втулків.\nhelm plugin update <plugin>         # Оновлення втулків.\nhelm plugin uninstall <plugin>      # Видалення втулка.\n```\n\n---\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/intro/index.mdx",
    "content": "---\ntitle: Вступ\nsidebar_position: 2\n---\n\n# Вступ до Helm\n\nВи не знайомі з Helm? Тоді почніть звідси!\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/intro/install.mdx",
    "content": "---\ntitle: Встановлення Helm\ndescription: Дізнайтеся, як встановити та почати працювати з Helm.\nsidebar_position: 2\n---\n\nЦей посібник показує, як встановити Helm CLI. Helm можна встановити або з вихідного коду, або з попередньо скомпільованих бінарних випусків.\n\n## Від проєкту Helm {#from-the-helm-project}\n\nПроєкт Helm пропонує два способи завантаження та встановлення Helm. Це офіційні методи отримання випусків Helm. Крім того, спільнота Helm пропонує методи встановлення Helm за допомогою різних менеджерів пакетів. Інформацію про встановлення за допомогою цих методів можна знайти нижче за офіційними методами.\n\n### З бінарних випусків {#from-the-binary-releases}\n\nКожен [випуск](https://github.com/helm/helm/releases) Helm надає бінарні випуски для різних операційних систем. Ці бінарні версії можна завантажити та встановити вручну.\n\n1. Завантажте [бажану версію](https://github.com/helm/helm/releases)\n2. Розпакуйте її (`tar -zxvf helm-v4.0.0-linux-amd64.tar.gz`)\n3. Знайдіть бінарний файл `helm` у розпакованій теці та перемістіть його у потрібне місце (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nПісля цього ви зможете запустити клієнта та [додати стабільне сховище чартів](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`.\n\n**Примітка:** Автоматизовані тести Helm виконуються лише для Linux AMD64 під час GitHub Actions збірок та випусків. Тестування інших операційних систем є відповідальністю спільноти, якій потрібен Helm для цієї операційної системи.\n\n### Зі скрипту {#from-script}\n\nHelm має скрипт встановлення, який автоматично завантажує останню версію Helm і [встановлює її локально](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4).\n\nВи можете завантажити цей скрипт, а потім виконати його локально. Він добре задокументований, щоб ви могли ознайомитися з ним і зрозуміти, що він робить перед його запуском.\n\n```console\n$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4\n$ chmod 700 get_helm.sh\n$ ./get_helm.sh\n```\n\nТак, ви можете виконати команду `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 | bash`, якщо хочете ризикнути.\n\n## Через менеджери пакетів {#through-package-managers}\n\nСпільнота Helm надає можливість встановлювати Helm через менеджери пакетів операційної системи. Вони не підтримуються проєктом Helm і не вважаються надійними постачальниками.\n\n### За допомогою Homebrew (macOS) {#from-homebrew-macos}\n\nЧлени спільноти Helm зробили свій внесок у створення формули Helm для Homebrew. Ця формула, як правило, є актуальною.\n\n```console\nbrew install helm\n```\n\n(Примітка: Існує також формула для emacs-helm, який є іншим проєктом.)\n\n### За допомогою Chocolatey (Windows) {#from-chocolatey-windows}\n\nЧлени спільноти Helm зробили свій внесок у створення [пакета Helm](https://chocolatey.org/packages/kubernetes-helm) для [Chocolatey](https://chocolatey.org/). Цей пакет, як правило, є актуальним.\n\n```console\nchoco install kubernetes-helm\n```\n\n### За допомогою Scoop (Windows) {#from-scoop-windows}\n\nЧлени спільноти Helm зробили свій внесок у створення [пакета Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) для [Scoop](https://scoop.sh). Цей пакет, як правило, є актуальним.\n\n```console\nscoop install helm\n```\n\n### За допомогою Winget (Windows) {#from-winget-windows}\n\nЧлени спільноти Helm зробили свій внесок у створення [пакета Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) для [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Цей пакет, як правило, є актуальним.\n\n```console\nwinget install Helm.Helm\n```\n\n### За допомогою Apt (Debian/Ubuntu) {#from-apt-debianubuntu}\n\nЧлени спільноти Helm зробили свій внесок у створення пакета Apt для Debian/Ubuntu. Цей пакет, як правило, є актуальним. Дякуємо [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) за підтримку репозиторію.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### За допомогою dnf/yum (fedora) {#from-dnfyum-fedora}\n\nЗ Fedora 35 Helm доступний у офіційному репозиторії. Ви можете встановити Helm, виконавши:\n\n```console\nsudo dnf install helm\n```\n\n### За допомогою Snap {#from-snap}\n\nСпільнота [Snapcrafters](https://github.com/snapcrafters) підтримує версію Snap пакета [Helm](https://snapcraft.io/helm):\n\n```console\nsudo snap install helm --classic\n```\n\n### За допомогою pkg (FreeBSD) {#from-pkg-freebsd}\n\nЧлени спільноти FreeBSD зробили свій внесок у створення пакета [Helm](https://www.freshports.org/sysutils/helm) для [FreeBSD Ports Collection](https://man.freebsd.org/ports). Цей пакет, як правило, є актуальним.\n\n```console\npkg install helm\n```\n\n### Збірки для розробки {#development-builds}\n\nОкрім випусків, ви можете завантажити або встановити зліпки Helm для розробки.\n\n### Збірки Canary {#from-canary-builds}\n\n«Canary» — це версії програмного забезпечення Helm, створені на основі останньої гілки «main». Вони не є офіційними релізами і можуть бути нестабільними. Однак вони дають можливість протестувати найновіші функції.\n\nБінарні файли Canary Helm зберігаються на сайті [get.helm.sh](https://get.helm.sh). Ось посилання на найпоширеніші версії:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### Збірки з сирців (Linux, macOS) {#from-source-linux-macos}\n\nСтворення Helm з сирців вимагає трохи більше зусиль, але це найкращий спосіб, якщо ви хочете протестувати останню версію Helm.\n\nУ вас повинно бути налаштоване середовище Go.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\nЗа необхідності, буде отримано залежності та збережено їх у кеші, а також перевірено конфігурацію. Потім буде скомпільовано `helm` та розміщено його у `bin/helm`.\n\n## Підсумки {#conclusion}\n\nУ більшості випадків встановлення є таким же простим, як отримання готового бінарного файлу `helm`. Цей документ охоплює додаткові випадки для тих, хто хоче робити складніші речі з Helm.\n\nПісля успішного встановлення клієнта Helm ви можете перейти до використання Helm для управління чартами та [додавання репозиторію стабільних чартів](/intro/quickstart.md#initialize-a-helm-chart-repository).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/intro/quickstart.md",
    "content": "---\ntitle: Швидкий старт\ndescription: Як встановити та розпочати роботу з Helm, включаючи інструкції для дистрибутивів, поширені запитання та втулки.\nsidebar_position: 1\n---\n\nЦей посібник описує, як швидко розпочати роботу з Helm.\n\n## Передумови {#prerequisites}\n\nДля успішного та належного використання Helm необхідні такі передумови.\n\n1. Кластер Kubernetes\n2. Визначення конфігурацій безпеки, які слід застосувати до вашого встановлення, якщо такі є\n3. Встановлення та налаштування Helm.\n\n### Встановіть Kubernetes або отримайте доступ до кластера {#install-kubernetes-or-have-access-to-a-cluster}\n\n- Ви повинні мати встановлений Kubernetes. Для останньої версії Helm ми рекомендуємо останню стабільну версію Kubernetes, яка в більшості випадків є передостанньою мінорною версією.\n- Ви також повинні мати локальну налаштовану копію `kubectl`.\n\nДивіться [Політику підтримки версій Helm](https://helm.sh/docs/topics/version_skew/) для отримання інформації про максимальну розбіжність версій, що підтримується між Helm і Kubernetes.\n\n## Встановіть Helm {#install-helm}\n\nЗавантажте бінарну версію клієнта Helm. Ви можете скористатися такими інструментами, як `homebrew`, або переглянути [офіційну сторінку випусків](https://github.com/helm/helm/releases).\n\nБільш детальну інформацію та інші варіанти дивіться в [посібнику з встановлення](/intro/install.mdx).\n\n## Ініціалізуйте репозиторій чартів Helm {#initialize-a-helm-chart-repository}\n\nПісля підготовки Helm ви можете додати репозиторій чартів. Перевірте [Artifact Hub](https://artifacthub.io/packages/search?kind=0), щоб дізнатися про доступні репозиторії чартів Helm.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nПісля встановлення ви зможете переглянути список чартів, які можна встановити:\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## Встановіть демонстраційний чарт {#install-an-example-chart}\n\nЩоб встановити чарт, можна виконати команду `helm install`. Helm має кілька способів пошуку та встановлення чартів, але найпростіший — це використання чартів `bitnami`.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nУ наведеному вище прикладі було встановлено чарт `bitnami/mysql`, а назва нашого нового релізу — `mysql-1612624192`.\n\nВи можете отримати загальне уявлення про функції цього чарту MySQL, виконавши команду `helm show chart bitnami/mysql`. Або ви можете виконати команду `helm show all bitnami/mysql`, щоб отримати всю інформацію про чарт.\n\nКожного разу, коли ви встановлюєте чарт, створюється новий реліз. Отже, один чарт можна встановити кілька разів в один і той самий кластер. І кожним з них можна керувати та оновлювати незалежно.\n\nКоманда `helm install` — це дуже потужна команда з багатьма можливостями. Щоб дізнатися більше про неї, перегляньте [Посібник з використання Helm](/intro/using_helm.mdx).\n\n## Дізнайтеся про релізи {#learn-about-releases}\n\nЗа допомогою Helm легко побачити, що було встановлено:\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nФункція `helm list` (або `helm ls`) покаже вам список усіх розгорнутих релізів.\n\n## Видалення релізу {#uninstall-a-release}\n\nЩоб видалити реліз, скористайтеся командою `helm uninstall`:\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nЦе видалить `mysql-1612624192` з Kubernetes, що призведе до видалення всіх ресурсів, повʼязаних з релізом, а також історії релізів.\n\nЯкщо вказано прапорець `--keep-history`, історія релізів буде збережена. Ви зможете запитувати інформацію про цей реліз:\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nОскільки Helm відстежує ваші релізи навіть після їх видалення, ви можете перевіряти історію кластера і навіть відновлювати релізи (за допомогою команди `helm rollback`).\n\n## Ознайомлення з довідкою {#reading-the-help-text}\n\nЩоб дізнатися більше про доступні команди Helm, скористайтеся командою `helm help` або введіть команду, додавши до неї прапорець `-h`:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/intro/using_helm.mdx",
    "content": "---\ntitle: Використання Helm\ndescription: Описує основи роботи з Helm.\nsidebar_position: 3\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nЦей посібник пояснює основи використання Helm для керування пакетами у вашому кластері Kubernetes. Передбачається, що ви вже [встановили](/intro/install.mdx) клієнт Helm.\n\nЯкщо вас цікавить лише виконання кількох швидких команд, можливо, ви захочете почати з [Посібника зі швидкого старту](/intro/quickstart.md). У цьому розділі розглядаються особливості команд Helm та пояснюється, як використовувати Helm.\n\n## Три головні концепції {#three-big-concepts}\n\n*Chart* — це пакет Helm. Він містить усі необхідні визначення ресурсів для запуску застосунку, інструменту або сервісу всередині кластера Kubernetes. Думайте про це як про еквівалент формули Homebrew, пакету Apt dpkg або файлу Yum RPM для Kubernetes.\n\n*Repository* — це місце, де можна зібрати та поділитися чартами. Це як [архів CPAN](https://www.cpan.org) для Perl або [база пакетів Fedora](https://src.fedoraproject.org/), але для пакетів Kubernetes.\n\n*Release* — це екземпляр чарту, що працює в кластері Kubernetes. Один чарт можна встановити в кластер кілька разів. І кожного разу при встановленні створюється новий *реліз*. Наприклад, чарт MySQL. Якщо ви хочете, щоб у вашому кластері працювали дві бази даних, ви можете встановити цей чарт двічі. Кожен екземпляр матиме свій *реліз*, а також своє *імʼя релізу*.\n\nМаючи ці концепції на увазі, можна пояснити Helm так:\n\nHelm встановлює *чарти* у Kubernetes, створюючи новий *реліз* для кожного встановлення. А щоб знайти нові чарти, ви можете шукати їх у репозиторіях *чартів* Helm.\n\n## 'helm search': Пошук чартів {#helm-search-finding-charts}\n\nHelm постачається з потужною командою пошуку. Її можна використовувати для пошуку двох типів джерел:\n\n- `helm search hub` здійснює пошук у [Artifact Hub](https://artifacthub.io), який містить чарти helm із десятків різних репозиторіїв.\n- `helm search repo` здійснює пошук у репозиторіях, які ви додали до свого локального клієнта helm (за допомогою `helm repo add`). Цей пошук здійснюється за локальними даними, і підключення до публічної мережі не потрібно.\n\nВи можете знайти загальнодоступні чарти, виконавши команду `helm search hub`:\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\nВищенаведений пошук знаходить усі чарти `wordpress` в Artifact Hub.\n\nБез фільтрації `helm search hub` показує всі доступні чарти.\n\n`helm search hub` показує URL-адресу розташування на [artifacthub.io](https://artifacthub.io/), але не власне репозиторій Helm. `helm search hub --list-repo-url` показує фактичну URL-адресу репозиторію Helm, що може бути корисним, коли ви хочете додати новий репозиторій: `helm repo add [NAME] [URL]`.\n\nЗа допомогою `helm search repo` ви можете знайти імена чартів у репозиторіях, які ви вже додали:\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nHelm search використовує алгоритм нечіткого порівняння рядків, тому можна вводити частини слів або фраз:\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nПошук — це чудовий спосіб знайти доступні пакети. Коли ви знайшли потрібний пакет, можете використовувати `helm install`, щоб встановити його.\n\n## 'helm install': Встановлення пакета {#helm-install-installing-a-package}\n\nЩоб встановити новий пакет, скористайтеся командою `helm install`. У найпростішому випадку вона приймає два аргументи: потрібне вам імʼя релізу та імʼя чарту, який ви хочете встановити.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Будь ласка, будьте терплячими, поки чарт розгортається **\n\nДоступ до вашого сайту WordPress можна отримати у вашому кластері за допомогою наступного імені DNS:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nЩоб отримати доступ до вашого сайту WordPress з-за меж кластера, виконайте наступні кроки:\n\n1. Отримайте URL WordPress, виконавши наступні команди:\n\n  ПРИМІТКА: Може знадобитися кілька хвилин для отримання IP-адреси LoadBalancer.\n        Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Відкрийте оглядач та отримайте доступ до WordPress, використовуючи отриманий URL.\n\n3. Увійдіть за допомогою наступних облікових даних:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\n:::info\n☝️ Тут і далі по тексту переклад українською виводу в терміналі надано для зручності сприйняття. Скоріше за все він буде відсутній в реальному застосуванні.\n:::\n\nТепер чарт `wordpress` встановлено. Зверніть увагу, що встановлення чарту створює новий обʼєкт *реліз*. Реліз вище називається `happy-panda`. (Якщо ви хочете, щоб Helm згенерував імʼя для вас, не вказуйте імʼя релізу і використовуйте `--generate-name`.)\n\nПід час встановлення клієнт `helm` надасть корисну інформацію про те, які ресурси були створені, який стан релізу, і чи є додаткові кроки конфігурації, які ви можете або повинні виконати.\n\nHelm встановлює ресурси в наступному порядку:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nHelm не чекає, поки всі ресурси будуть запущені, перш ніж завершити роботу. Багато чартів потребують Docker-образів розміром понад 600MB, і їхнє встановлення в кластер може тривати певний час.\n\nЩоб відстежувати стан релізу або повторно прочитати конфігураційну інформацію, ви можете використати команду `helm status`:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Будь ласка, будьте терплячими, поки чарт розгортається **\n\nДоступ до вашого сайту WordPress можна отримати у вашому кластері за допомогою наступного імені DNS:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nЩоб отримати доступ до вашого сайту WordPress з-за меж кластера, виконайте наступні кроки:\n\n1. Отримайте URL WordPress, виконавши наступні команди:\n\n  ПРИМІТКА: Може знадобитися кілька хвилин для отримання IP-адреси LoadBalancer.\n        Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Відкрийте оглядач та отримайте доступ до WordPress, використовуючи отриманий URL.\n\n3. Увійдіть за допомогою наступних облікових даних:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nВищенаведене показує поточний стан вашого релізу.\n\n### Налаштування чарту перед встановленням {#customizing-the-chart-before-installing}\n\nВстановлення у спосіб, який ми розглянули, використовуватиме лише стандартні параметри конфігурації для цього чарту. У багатьох випадках вам захочеться налаштувати чарт для використання ваших налаштувань.\n\nЩоб побачити, які параметри можна налаштувати в чарті, використовуйте команду `helm show values`:\n\n```console\n$ helm show values bitnami/wordpress\n## Глобальні параметри образу Docker\n## Зверніть увагу, що це замінить параметри образу, включаючи залежності, налаштовані для використання глобальних значень.\n## Наразі доступні такі глобальні параметри образу Docker: imageRegistry та imagePullSecrets.\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Версія образу Bitnami WordPress\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nВи можете перевизначити будь-які з цих налаштувань у файлі у форматі YAML, а потім передати цей файл під час встановлення.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nВищенаведене створить стандартного користувача MariaDB з імʼям `user0` і надасть цьому користувачеві доступ до новоствореної бази даних `user0db`, але всі інші параметри цього чарту залишаться стандартними.\n\nІснує два способи передати дані конфігурації під час встановлення:\n\n- `--values` (або `-f`): Вказати YAML-файл із перевизначеннями. Їх можна вказувати кілька разів, причому файл, що стоїть праворуч, матиме пріоритет\n- `--set`: Вказати перевизначення в командному рядку.\n\nЯкщо обидва варіанти використовуються, значення `--set` зливаються з `--values` з вищим пріоритетом. Перевизначення, зазначені за допомогою `--set`, зберігаються у Secret. Значення, що були встановлені через `--set`, можна переглянути для конкретного релізу за допомогою команди `helm get values <release-name>`. Значення, встановлені за допомогою `--set`, можна скинути, виконавши `helm upgrade` з параметром `--reset-values`.\n\n#### Формат і обмеження параметра `--set` {#the-format-and-limitations-of---set}\n\nОпція `--set` приймає нуль або більше пар імʼя/значення. У найпростішому випадку вона використовується так: `--set name=value`. Еквівалент у YAML виглядає так:\n\n```yaml\nname: value\n```\n\nКілька значень розділяються символами `,`. Отже, `--set a=b,c=d` стає:\n\n```yaml\na: b\nc: d\n```\n\nПідтримуються складніші вирази. Наприклад, `--set outer.inner=value` перетворюється на наступне:\n\n```yaml\nouter:\n  inner: value\n```\n\nСписки можна записати, включивши значення в `{` і `}`. Наприклад, `--set name={a, b, c}` перетворюється на:\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nДеякі пари імʼя/ключ можна встановити як `null` або як порожній масив `[]`. Наприклад, `--set name=[],a=null` перетворює:\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\nна\n\n```yaml\nname: []\na: null\n```\n\nПочинаючи з Helm 2.5.0, можна отримувати доступ до елементів списку, використовуючи синтаксис індексу масиву. Наприклад, `--set servers[0].port=80` стає:\n\n```yaml\nservers:\n  - port: 80\n```\n\nКілька значень можна встановити таким чином. Наприклад, рядок `--set servers[0].port=80,servers[0].host=example` перетворюється на:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nІноді вам потрібно використовувати спеціальні символи у ваших рядках `--set`. Ви можете використовувати зворотний слеш для екранування символів; `--set name=value1\\,value2` перетвориться на:\n\n```yaml\nname: \"value1,value2\"\n```\n\nАналогічно, можна екранувати послідовності крапок, що може знадобитися, коли чарти використовують функцію `toYaml` для аналізу анотацій, міток і вибору вузлів. Синтаксис для `--set nodeSelector.\"kubernetes\\.io/role\"=master`виглядає так:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nГлибоко вкладені структури даних може бути важко вказати використовуючи `--set`. Розробникам чартів рекомендується враховувати використання `--set` при розробці формату файлу `values.yaml` (докладніше про [Файли значень](/chart_template_guide/values_files.mdx)).\n\n### Інші методи встановлення {#more-installation-methods}\n\nКоманда `helm install` може встановлювати чарт із кількох джерел:\n\n- Репозиторій чартів (як ми бачили вище)\n- Локальний архів чарту (`helm install foo foo-0.1.1.tgz`)\n- Тека із розпакованим чартом (`helm install foo path/to/foo`)\n- Повний URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' та 'helm rollback': Оновлення релізу та відновлення у разі невдачі  {#helm-upgrade-and-helm-rollback-upgrading-a-release-and-recovering-on-failure}\n\nКоли виходить нова версія чарту або коли ви хочете змінити конфігурацію вашого релізу, ви можете скористатися командою `helm upgrade`.\n\nОновлення бере поточний реліз і оновлює його відповідно до інформації, що міститься в чарті. Оскільки чарти Kubernetes можуть бути великими та складними,\nHelm намагається виконати найменш інвазивне оновлення. Він оновлюватиме лише ті елементи, які змінилися з моменту останнього релізу.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nУ наведеному випадку реліз `happy-panda` оновлюється з використанням того ж чарту, але з новим YAML файлом:\n\n```yaml\nmariadb.auth.username: user1\n```\n\nМи можемо використати команду `helm get values`, щоб переконатися, що нові налаштування набрали чинності.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nКоманда `helm get` є корисним інструментом для перегляду релізу в кластері. І як ми бачили вище, вона показує, що наші нові значення з `panda.yaml` були розгорнуті в кластері.\n\nТепер, якщо під час релізу щось піде не так, можна легко повернутися до попереднього релізу, використовуючи команду `helm rollback [RELEASE] [REVISION]`.\n\n```console\n$ helm rollback happy-panda 1\n```\n\nЦя команда повертає наш реліз `happy-panda` до його першої версії. Версія релізу є інкрементною. Кожного разу, коли відбувається встановлення, оновлення або відкат, номер версії збільшується на 1. Перша версія завжди має номер 1. І ми можемо використовувати команду `helm history [RELEASE]`, щоб побачити номери версій для певного релізу.\n\n## Корисні опції для Install/Upgrade/Rollback {#helpful-options-for-installupgraderollback}\n\nЄ кілька інших корисних опцій, які можна вказати для налаштування поведінки Helm під час встановлення/оновлення/відкату. Зауважте, що це не повний список CLI-прапорців. Щоб побачити опис усіх прапорців, просто запустіть `helm <command> --help`.\n\n- `--timeout`: Значення [Go duration](https://golang.org/pkg/time/#ParseDuration), яке визначає, скільки чекати на завершення команд Kubernetes. Стандартно `5m0s`.\n- `--wait`: Очікує, доки всі Podʼи не перейдуть у стан готовності, PVC не будуть повʼязані, а Deployment не матиме мінімальну кількість Podʼів у стані готовності (`Desired` мінус `maxUnavailable`), а Services отримає IP-адресу (і Ingress, якщо це `LoadBalancer`) перед тим, як визнати реліз успішним. Чекання триватиме стільки часу, скільки вказано в опції `--timeout`. Якщо тайм-аут досягнуто, реліз буде позначено як `FAILED`. Примітка: У ситуаціях, коли Deployment має в `replicas` значення 1, а `maxUnavailable` не встановлено в 0 як частина стратегії rolling update, `--wait` поверне готовність, коли задоволено мінімальну кількість Podʼів у готовому стані.\n- `--no-hooks`: Пропускає запуск хуків для команди.\n- `--recreate-pods` (доступно лише для `upgrade` та `rollback`): Цей прапорець викличе повторне створення всіх Podʼів (за винятком Podʼів, що належать до Deployment). (Визнано застаріле в Helm 3)\n\n## 'helm uninstall': Видалення релізу {#helm-uninstall-uninstalling-a-release}\n\nКоли настає час видалити реліз з кластера, використовуйте команду `helm uninstall`:\n\n```console\n$ helm uninstall happy-panda\n```\n\nЦе видалить реліз з кластера. Ви можете переглянути всі ваші поточні розгорнуті релізи за допомогою команди `helm list`:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nЗ виводу вище ми можемо побачити, що реліз `happy-panda` було видалено.\n\nУ попередніх версіях Helm, коли реліз видалявся, запис про його видалення залишався. У Helm 3 видалення також видаляє запис про реліз. Якщо ви хочете зберегти запис про видалений реліз, використовуйте `helm uninstall --keep-history`. Використання `helm list --uninstalled` покаже лише ті релізи, які були видалені з прапорцем `--keep-history`.\n\nПрапорець `helm list --all` покаже вам всі записи релізів, які зберіг Helm, включаючи записи про елементи, які зазнали збою або записи ппро видалені елементів (якщо було вказано `--keep-history`):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nЗверніть увагу, що через те, що релізи тепер стандартно видаляються, більше неможливо зробити відкат до видаленого ресурсу.\n\n## 'helm repo': Робота з репозиторіями {#helm-repo-working-with-repositories}\n\nHelm 3 більше не постачається зі стандартним репозиторієм чартів. Група команд `helm repo` надає команди для додавання, перегляду та видалення репозиторіїв.\n\nВи можете переглянути, які репозиторії налаштовані, використовуючи `helm repo list`:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nНові репозиторії можна додати за допомогою `helm repo add [NAME] [URL]`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nОскільки репозиторії чартів часто змінюються, у будь-який момент ви можете переконатися, що ваш клієнт Helm актуальний, запустивши `helm repo update`.\n\nРепозиторії можна видалити за допомогою `helm repo remove`.\n\n## Створення власних чартів {#creating-your-own-charts}\n\n[Посібник з розробки чартів](/topics/charts.mdx) пояснює, як створювати власні чарти. Але ви можете швидко розпочати, використовуючи команду `helm create`:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nТепер у вас є чарт в теці `./deis-workflow`. Ви можете редагувати його та створювати власні шаблони.\n\nКоли ви редагуєте свій чарт, ви можете перевірити, чи він добре сформований, запустивши команду `helm lint`.\n\nКоли настане час упакувати чарт для розповсюдження, ви можете скористатися командою `helm package`:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nІ цей чарт тепер може бути легко встановлена за допомогою `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nУпаковані чарти можуть бути завантажені в репозиторії чартів. Для отримання додаткової інформації дивіться документацію про [репозиторії чартів Helm](/topics/chart_repository.md).\n\n## Висновки {#conclusion}\n\nУ цьому розділі було розглянуто основні шаблони використання клієнта `helm`, включаючи пошук, встановлення, оновлення та видалення. Також було розглянуто корисні утиліти, такі як `helm status`, `helm get` і `helm repo`.\n\nДля отримання додаткової інформації про ці команди перегляньте вбудовану довідку Helm: `helm help`.\n\nУ [наступному розділі](/howto/charts_tips_and_tricks.md) ми розглянемо процес створення чартів.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/overview.md",
    "content": "---\nsidebar_position: 1\nsidebar_label: Огляд Helm 4\n---\n\n# Огляд Helm 4\n\nHelm v4 є значним кроком вперед порівняно з v3, запроваджуючи кардинальні зміни, нові архітектурні шаблони та розширену функціональність, зберігаючи при цьому зворотну сумісність чартів.\n\nБільш детальну інформацію про заплановані етапи випуску Helm 4 дивіться у статті [Шлях до випуску Helm v4](/blog/path-to-helm-v4/).\n\n## Що нового {#whats-new}\n\nУ цьому розділі наведено огляд нововведень у Helm 4, включаючи кардинальні зміни, основні нові функції та інші вдосконалення. Повні технічні деталі див. у [Повному переліку змін](changelog.md).\n\n### Огляд {#summary}\n\n- **Нові функції**: втулки на основі Wasm, kstatus watcher, підтримка OCI digest, значення multi-doc, аргументи JSON\n- **Зміни в архітектурі**: повністю перероблена система втулків, реструктуризація пакетів, перейменування прапорців CLI, перехід на версійні пакети, підтримка chart v3, кешування на основі вмісту\n- **Модернізація**: міграція slog, оновлення до Go 1.24, очищення залежностей\n- **Безпека**: розширена підтримка OCI/реєстру, вдосконалення TLS\n\n### Істотні зміни {#breaking-changes}\n\n#### Пострендери, реалізовані як втулки {#post-renderers-implemented-as-plugins}\n\nПострендери реалізовані як втулки. З цією зміною більше неможливо передавати виконуваний файл безпосередньо до `helm render --post-renderer`, але необхідно передавати назву втулка. Це може вимагати оновлення наявних робочих процесів пострендера.\n\n#### Для входу в реєстр не приймаються повні URL-адреси {#registry-login-does-not-accept-full-urls}\n\nКоманда `helm registry login` повинна виконуватися тільки з доменним імʼям у v4. Це необхідно для того, щоб у майбутньому можна було здійснювати вхід на різних рівнях реєстру.\n\n### Нові функції {#new-features}\n\n#### Переробка системи втулків {#plugin-system-overhaul}\n\nHelm 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).\n\n:::tip\nІснуючі втулки працюють як і раніше. Нова система виконання WebAssembly є опціональною, але рекомендується для підвищення безпеки.\n:::\n\n#### Кращий моніторинг ресурсів {#better-resource-monitoring}\n\nНова інтеграція kstatus показує детальний статус ваших розгортань (deployments). Протестуйте її на комплексних застосунках, щоб перевірити, чи вона краще виявляє проблеми.\n\n#### Розширена підтримка OCI {#enhanced-oci-support}\n\nВстановлюйте чарти за допомогою дайджестів для кращої безпеки ланцюгів постачання. Наприклад, `helm install myapp oci://registry.example.com/charts/app@sha256:abc123...`. Чарти з невідповідними дайджестами не встановлюються.\n\n#### Значення з декількох документів {#multi-document-values}\n\nРозділіть комплексні значення між декількома файлами YAML. Ідеально підходить для тестування різних конфігурацій середовища.\n\n#### Застосування на стороні сервера {#server-side-apply}\n\nКраще вирішення конфліктів, коли кілька інструментів керують тими самими ресурсами. Тестуйте в середовищах з операторами або іншими контролерами.\n\n#### Функції у шаблонах користувачів {#custom-template-functions}\n\nРозширте можливості шаблонів Helm власними функціями за допомогою втулків. Чудово підходить для потреб організації у створенні шаблонів.\n\n#### Пострендери як втулки {#post-renderers-as-plugins}\n\nПострендери реалізовані як втулки, що забезпечує кращу інтеграцію та більше можливостей.\n\n#### Стабільний SDK API {#stable-sdk-api}\n\nЗміни в API, що порушують сумісність, тепер завершені. Тестуйте, ламайте, давайте відгуки! API також підтримує додаткові версії чартів, відкриваючи можливості для нових функцій у майбутній версії Charts v3.\n\n#### Charts v3\n\nСкоро. Чарти v2 продовжують працювати без змін.\n\n### Покращення {#improvements}\n\n#### Продуктивність {#performance}\n\nШвидша обробка залежностей та нове кешування чартів на основі вмісту.\n\n#### Повідомлення про помилки {#error-messages}\n\nБільш чіткі та корисні повідомлення про помилки.\n\n#### Автентифікація в реєстрі {#registry-authentication}\n\nКраща підтримка OAuth та токенів для приватних реєстрів.\n\n#### Перейменовані прапорці CLI {#cli-flags-renamed}\n\nДеякі поширені прапорці CLI перейменовано, щоб краще пояснити їхню роботу. Наявні прапорці залишаються, але видають попередження про їхню застарілість:\n\n- `--atomic` → `--rollback-on-failure`\n- `--force` → `--force-replace`\n\nОновіть будь-які автоматизації, які використовують ці перейменовані прапорці CLI.\n\n## Оновлення до Helm 4 {#upgrading-to-helm-4}\n\nХоча ми докладаємо всіх зусиль, щоб Helm 4 був надійним для всіх, Helm 4 є абсолютно новим. З цією метою перед оновленням ми додали нижче кілька порад щодо конкретних речей, на які слід звернути увагу під час тестування Helm 4 з вашими наявними робочими процесами. Як завжди, ми будемо вдячні за всі відгуки про те, що працює, що не працює і що можна покращити.\n\n### Високий пріоритет {#high-priority}\n\n* Перевірте свої наявні чарти та випуски, щоб переконатися, що вони все ще працюють з v4.\n* Перевірте всі 3 типи втулків (CLI, getter, post-renderer).\n* Спробуйте створити втулки WebAssembly з новим середовищем виконання (дивіться [приклади втулків](https://github.com/scottrigby/h4-example-plugins))\n* Користувачі SDK: протестуйте стабільний API. Спробуйте зламати його та поділіться своїми відгуками.\n* Протестуйте свої CI/CD- конвеєри та виправте будь-які помилки скриптів, повʼязані зі зміною імен прапорців CLI.\n* Протестуйте інтеграції post-renderer.\n* Протестуйте автентифікацію в реєстрі та встановлення чартів у ваших робочих процесах OCI.\n\n### Інше {#other}\n\n* Випробуйте інші нові функції, зокрема значення для декількох документів, встановлення на основі дайджесту та функції налаштування шаблонів.\n* Випробуйте продуктивність Helm 4 із великими комплексними чартами, щоб перевірити, чи помітно пришвидшиться робота ваших робочих навантажень.\n* Спробуйте навмисно порушити роботу системи, щоб перевірити, чи корисні оновлені повідомлення про помилки.\n\n### Відгуки {#feedback}\n\n* Які ще типи втулків ви хотіли б додати для налаштування основних функцій Helm?\n* З огляду на те, що API підтримує додаткові версії чартів, які нові функції ви хотіли б бачити в Charts v3?\n\n## Як надати відгук {#how-to-give-feedback}\n\nЗнайшли проблеми? Маєте пропозиції? Ми хочемо почути вашу думку до випуску в листопаді:\n\n### GitHub Issues {#github-issues}\n\nПерегляньте [список відкритих питань та запитів на додавання функцій](https://github.com/helm/helm/issues) у репозиторії Helm. Додайте коментарі до наявних або [створіть нові](https://github.com/helm/helm/issues/new/choose) питання та запити.\n\n### Slack спільноти {#community-slack}\n\nПриєднуйтесь до каналів в [Slack Kubernetes](https://slack.kubernetes.io/):\n\n- `#helm-dev` для обговорення питань розробки\n- `#helm-users` для підтримки користувачів та відгуків про тестування\n\n### Щотижневі зустрічі розробників {#weekly-dev-meetings}\n\nПриєднуйтесь до живої дискусії з супровідниками щочетверга о 9:30 за тихоокеанським часом на [Zoom](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09).\n\nБільше варіантів можна знайти в [інформації про комунікацію](https://github.com/helm/community/blob/main/communication.md) спільноти Helm.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/plugins/developer/index.mdx",
    "content": "---\ntitle: Посібник розробника втулків\nsidebar_label: Створення втулків\nsidebar_position: 3\n---\n\nimport DocCardList from \"@theme/DocCardList\";\n\nДля ознайомлення з концепціями втулків Helm, а також з тим, як структурувати та налаштовувати втулки, ознайомтеся з [Оглядом втулків](/plugins/overview.md).\n\nЦей розділ присвячений розробці втулків Helm — він містить [посібники](#tutorials), інструкції, довідники та додаткову інформацію для розробників щодо створення втулків Helm.\n\n:::info\nВступ до кодової бази системи втулків буде розміщено на сторінці Втулки в розділі [Go SDK](/sdk/index.mdx) документації, яка зʼявиться найближчим часом!\n:::\n\n## Посібники {#tutorials}\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-cli-plugin.mdx",
    "content": "---\ntitle: \"Посібник: Створення втулків CLI\"\nsidebar_label: Створення втулків CLI\n---\n\nimport GetVersion from \"@site/src/components/GetVersion\";\nimport CodeBlock from \"@theme/CodeBlock\";\n\nСтворіть команду `helm system-info`, яка виводить інформацію про систему.\n\n## Subprocess Runtime\n\nПочнемо з створення втулка CLI з середовищем виконання Subprocess.\n\n### Передумови {#prerequisites}\n\n1. Встановіть останню версію Helm 4: **<GetVersion majorVersion=\"4\" label={false} link={true} />**\n2. У терміналі створіть аліас `helm` для завантаженої версії. Команда `helm version --short` повинна показати правильну версію Helm у цьому терміналі.\n\n### 1. Створіть теку для втулка {#1-create-plugin-directory}\n\nВи можете створити її в будь-якому місці вашої файлової системи. Наприклад:\n\n```bash\nmkdir -p $HOME/code/helm/plugins/system-info\ncd $HOME/code/helm/plugins/system-info\n```\n\n### 2. Створіть маніфест втулка {#2-create-plugin-manifest}\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: cli/v1\nname: \"system-info\"\nversion: \"0.1.0\"\nruntime: subprocess\nconfig:\n  usage: system-info\n  shortHelp: Показує системну інформацію та інформацію Helm\n  longHelp: Показує інформацію про ОС, версію Helm та деталі середовища\nruntimeConfig:\n  platformCommand:\n    - command: ${HELM_PLUGIN_DIR}/system-info.sh\n```\n\n### 3. Створіть скрипт {#3-create-script}\n\n```bash title=\"system-info.sh\" showLineNumbers\n#!/bin/bash\n\necho \"=== System Information ===\"\necho \"OS: $(uname -s)\"\necho \"Architecture: $(uname -m)\"\n\necho \"\"\necho \"=== Helm Information ===\"\necho \"Plugin Dir: $HELM_PLUGIN_DIR\"\necho \"Arguments: $*\"\n\necho \"\"\necho \"System info complete!\"\n```\n\nЗробіть його виконуваним:\n\n```bash\nchmod +x system-info.sh\n```\n\n### 4. Встановлення в режимі розробки та тестування {#4-install-in-dev-mode-and-test}\n\nВстановлення втулка з вашої файлової системи відбувається в локальному режимі розробки. Це дозволяє обійти перевірку або підтвердження походження:\n\n```bash\n% helm plugin install $HOME/code/helm/plugins/system-info\nInstalling plugin from local directory (development mode)\nInstalled plugin: system-info\n```\n\nВстановлення в локальному режимі розробки створює символічне посилання з вашого теки джерел до теки втулків, тому ви можете продовжувати розробку в бажаному місці. Ви можете побачити символічне посилання, переглянувши розташування теки за допомогою внутрішньої змінної середовища HELM_PLUGINS:\n\n```bash\n% ls -lah $(helm env HELM_PLUGINS)\ntotal 0\ndrwxr-xr-x@ 3 r6by  staff    96B Nov 10 02:18 .\ndrwxr-xr-x@ 3 r6by  staff    96B Jan 21  2025 ..\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info\n```\n\nВи можете переглянути детальну інформацію про втулок у списку встановлених втулків `helm plugin list`:\n\n```bash\n% helm plugin list\nNAME       \tVERSION\tTYPE  \tAPIVERSION\tPROVENANCE\tSOURCE\nsystem-info\t0.1.0  \tcli/v1\tv1        \tlocal dev \tunknown\n```\n\nТепер ви також можете побачити свій втулок у списку доступних команд за допомогою команди `helm help` і переглянути власне повідомлення довідки, яке ви визначили у файлі `plugin.yaml`:\n\n```bash\n% helm help | grep system-info\n  system-info Показує системну інформацію та інформацію Helm\n\n% helm help system-info\nПоказує інформацію про ОС, версію Helm та деталі середовища\n\nUsage:\n  helm system-info [flags]\n```\n\nСпробуємо запустити команду CLI:\n\n```bash\n% helm system-info\n=== System Information ===\nOS: Darwin\nArchitecture: arm64\n\n=== Helm Information ===\nPlugin Dir: /Users/r6by/Library/helm/plugins/system-info\nArguments:\n\nSystem info complete!\n```\n\nЩо ви створили: втулок CLI з використанням середовища виконання Subprocess!\n\nТепер давайте зробимо це ще раз, але цього разу з використанням середовища виконання Wasm…\n\n## Wasm Runtime\n\n### Передумови {#prerequisites-1}\n\n- Передумови з [Subprocess Runtime](#subprocess-runtime)\n- Встановлений Go 1.25\n\n:::warning\nTo-do: додати цей розділ\n:::\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-getter-plugin.mdx",
    "content": "---\ntitle: \"Посібник: Створення втулків Getter\"\nsidebar_label: Створення втулків Getter\n---\n\nimport GetVersion from \"@site/src/components/GetVersion\";\n\nСтворіть команду `helm system-info`, яка виводить інформацію про систему.\n\n## Subprocess Runtime\n\nСтворімо втулок Getter, який виконується в Subprocess.\n\n### Передумови {#prerequisites}\n\n1. Встановіть останню версію Helm 4: **<GetVersion majorVersion=\"4\" label={false} link={true} />**\n2. У терміналі створіть аліас `helm` для завантаженої версії. Команда `helm version --short` повинна показати правильну версію Helm у цьому терміналі.\n\n### 1. Створіть теку для втулка {#1-create-plugin-directory}\n\nВи можете створити її в будь-якому місці вашої файлової системи. Наприклад:\n\n```bash\nmkdir -p $HOME/code/helm/plugins/demo-getter\ncd $HOME/code/helm/plugins/demo-getter\n```\n\n### 2. Створіть маніфест втулка {#2-create-plugin-manifest}\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: getter/v1\nname: demo-getter\nversion: 0.1.0\nruntime: subprocess\nconfig:\n  protocols: [\"demo\"]\nruntimeConfig:\n  protocolCommands:\n    - protocols:\n        - demo\n      platformCommand:\n        - command: get-demo.sh\n```\n\n### 3. Створіть скрипт {#3-create-script}\n\nВтулки Getter відповідають за отримання/завантаження упакованого артефакту, в даному випадку чарта, та повернення шляху до завантаженого пакета. Для демонстрації скористаймося утилітою вашої системи, щоб створити тимчасову теку (вона автоматично очищатиметься з часом), а також командами `helm create` та `helm package`, щоб створити демонстраційний пакет чарта в тимчасовій теці та повернути шлях до пакета:\n\n```bash title=\"get-demo.sh\" showLineNumbers\n#!/usr/bin/env sh\nset -e\n\nURI=$@\nTMPDIR=\"$(mktemp -d)\"\n\n# створення фальшивого чарта для тестування з переданим базовим імʼям URL\nFILENAME=$(basename -- $URI)\nhelm create $TMPDIR/$FILENAME 1>/dev/null\nhelm package $TMPDIR/$FILENAME -d $TMPDIR 1>/dev/null\n# cat $FILENAME-0.1.0.tgz\n# щоб не потрібно було знати версію чарта\nrm -r $TMPDIR/$FILENAME 1>/dev/null\ncat $TMPDIR/$FILENAME-*\n```\n\nЗробіть його виконуваним:\n\n```bash\nchmod +x get-demo.sh\n```\n\n### 4. Встановлення в режимі розробки та тестування {#4-install-in-dev-mode-and-test}\n\nВстановлення втулка з вашої файлової системи відбувається в локальному режимі розробки. Це дозволяє обійти перевірку або підтвердження походження:\n\n```bash\n% helm plugin install $HOME/code/helm/plugins/demo-getter\nInstalling plugin from local directory (development mode)\nInstalled plugin: demo-getter\n```\n\nЯк ми бачили в [посібнику з втулків CLI](/plugins/developer/tutorial-cli-plugin.mdx), встановлення в локальному режимі розробки створює символічне посилання з теки джерел вашого втулка до теки втулків. Тепер у вас встановлено два втулки:\n\n```bash\n% ls -lah $(helm env HELM_PLUGINS)\ntotal 0\ndrwxr-xr-x@ 4 r6by  staff   160B Nov 10 04:04 .\ndrwxr-xr-x@ 3 r6by  staff    96B Jan 21  2025 ..\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info\n```\n\nНа відміну від посібника втулків CLI, ви не побачите цей втулок у списку доступних команд за допомогою команди `helm help`. У списку команд CLI `helm` відображаються лише типи втулків CLI.\n\nАле, як і для всіх типів втулків, ви можете переглянути детальну інформацію про встановлений втулок Getter за допомогою команди `helm plugin list`:\n\n```bash\n% helm plugin list\nNAME          \tVERSION\tTYPE           \tAPIVERSION\tPROVENANCE\tSOURCE\ndemo-getter   \t0.1.0  \tgetter/v1      \tv1        \tlocal dev \tunknown\nsystem-info   \t0.1.0  \tcli/v1         \tv1        \tlocal dev \tunknown\n```\n\nСпробуймо. Маємо отримати шаблон YAML для чарту з назвою «example»:\n\n```bash\n% helm template example demo://does-not-matter/example\nLOTS OF YAML, INCLUDING:\n---\n# Source: example/templates/tests/test-connection.yaml\n```\n\nЩо ви створили: демо-втулок Getter, що використовує середовище виконання Subprocess!\n\nДалі створімо версію в середовищі виконання Wasm…\n\n## Wasm Runtime\n\n### Передумови {#prerequisites-1}\n\n- Вимоги з [Subprocess Runtime](#subprocess-runtime)\n- Встановлений Go 1.25\n\nСтворіть власний протокол getter, який перетворює URL-адреси `demo://` на `https://`.\n\n### 1. Налаштування репозиторію {#1-set-up-repository}\n\nСтворіть новий репозиторій на основі шаблону (або просто клонуйте): https://github.com/gjenkins8/helm-extism-plugin-template\n\n### 2. Оновлення маніфесту втулка {#2-update-plugin-manifest}\n\nАналогічно до того ж кроку для Subprocess Getter, за винятком того, що ви будете робити це у власному клонованому репозиторії Git.\n\nЗверніть увагу, що значення полів `runtime` та `runtimeConfig` зміняться для Wasm:\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: getter/v1\nname: demo-getter\nversion: 0.1.0\nruntime: extism/v1\nconfig:\n  protocols: [\"demo\"]\nruntimeConfig:\n  memory:\n    maxPages: 16\n  timeout: 30000\n```\n\n### 3. Update `main.go` {#3-update-maingo}\n\nВизначте вхідні/вихідні повідомлення втулків:\n\n```go title=\"main.go\" showLineNumbers\npackage main\n\n...\n\ntype InputMessage struct {\n\tURL      string `json:\"url\"`\n\tProtocol string `json:\"protocol\"`\n}\n\ntype OutputMessage struct {\n\tData []byte `json:\"data\"`\n}\n```\n\nЗамініть функцію `replaceMeImplementationGoesHere` фактичною логікою:\n\n```go\n...\n\n// Видаліть функцію `replaceMeImplementationGoesHere`.\n\nfunc demoDownloader(input InputMessage) (*OutputMessage, error) {\n\n\t// Перетворення demo:// на https://\n\tdownloadURL := strings.Replace(input.URL, \"demo://\", \"https://\", 1)\n\tpdk.Log(pdk.LogLevelInfo, fmt.Sprintf(\"Converted %s to %s\", input.URL, downloadURL))\n\n\t// Завантаження вмісту\n\tresp, err := http.Get(downloadURL)\n\tif err != nil {\n\t\treturn nil, fmt.Errorf(\"failed to download: %w\", err)\n\t}\n\tdefer resp.Body.Close()\n\n\t// Читання та виведення вмісту\n\tdata, _ := io.ReadAll(resp.Body)\n\toutput := OutputMessage{Data: data}\n\treturn &output, nil\n}\n\n```\n\nОновіть функцію runPlugin, щоб замість цього викликати `demoDownloader`:\n\n```go\nfunc runPlugin() error {\n\t...\n\t// Вилучим: output, err := replaceMeImplementationGoesHere(input)\n\toutput, err := demoDownloader(input)\n```\n\n### 4. Збирання WebAssembly {#4-build-webassembly}\n\n```bash\n$ make build\n$ ls -la plugin.wasm\n```\n\n### 5. Встановлення в режимі розробки та тестування {#5-install-in-dev-mode-and-test}\n\nТе саме, що і крок Втулок CLI у Subprocess.\n\nЩо ви створили: втулок WebAssembly із виконанням у пісочниці та структурованою комунікацією через Extism PDK!\n\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-postrenderer-plugin.mdx",
    "content": "---\ntitle: \"Посібник: Створення втулків Postrenderer\"\nsidebar_label: Створення втулків Postrenderer\n---\n\nimport GetVersion from \"@site/src/components/GetVersion\";\nimport CodeBlock from \"@theme/CodeBlock\";\n\nСтворіть втулок, який додає власні мітки до всіх ресурсів Kubernetes.\n\n## Subprocess Runtime\n\nСтворімо втулок Postrenderer, який виконується в Subprocess.\n\n### Передумови {#prerequisites}\n\n1. Встановіть останню версію Helm 4: **<GetVersion majorVersion=\"4\" label={false} link={true} />**\n2. В терміналі створіть аліас `helm` для завантаженої версії. Команда `helm version --short` повинна показати правильну версію Helm у цьому терміналі.\n3. Встановіть `mikefarah/yq`: https://github.com/mikefarah/yq/#install\n\n### 1. Створіть теку для втулка {#1-create-plugin-directory}\n\nВи можете створити її в будь-якому місці вашої файлової системи. Наприклад:\n\n```bash\nmkdir -p $HOME/code/helm/plugins/label-injector\ncd $HOME/code/helm/plugins/label-injector\n```\n\n### 2. Створіть маніфест втулка {#2-create-plugin-manifest}\n\n```yaml title=\"plugin.yaml\" showLineNumbers\napiVersion: v1\ntype: postrenderer/v1\nname: label-injector\nversion: 0.1.0\nruntime: subprocess\nruntimeConfig:\n  platformCommand:\n    - command: ${HELM_PLUGIN_DIR}/inject-labels.sh\n```\n\n### 3. Створіть скрипт {#3-create-script}\n\n```bash title=\"inject-labels.sh\" showLineNumbers\n#!/usr/bin/env sh\n# set -e\ncat <&0 | yq '.metadata.labels.postrendered-by = \"helm-label-injector-plugin\"'\n```\n\nЗробіть його виконуваним:\n\n```bash\nchmod +x inject-labels.sh\n```\n\n### 4. Встановлення в режимі розробки та тестування {#4-install-in-dev-mode-and-test}\n\nВстановлення втулка з вашої файлової системи відбувається в локальному режимі розробки. Це дозволяє обійти перевірку або підтвердження походження:\n\n```bash\n% helm plugin install $HOME/code/helm/plugins/label-injector\nInstalling plugin from local directory (development mode)\nInstalled plugin: label-injector\n```\n\nЯк ми бачили в [посібнику з втулків CLI](/plugins/developer/tutorial-cli-plugin.mdx) та [Getter](/plugins/developer/tutorial-getter-plugin.mdx), встановлення в локальному режимі розробки створює символічне посилання з теки джерел вашого втулка до теки втулків. Тепер у вас встановлено три втулки:\n\n```bash\n% ls -lah $(helm env HELM_PLUGINS)\ntotal 0\ndrwxr-xr-x@ 5 r6by  staff   160B Nov 10 04:04 .\ndrwxr-xr-x@ 3 r6by  staff    96B Jan 21  2025 ..\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter\nlrwxr-xr-x  1 r6by  staff    44B Nov 10 03:02 label-injector -> /Users/r6by/code/helm/plugins/label-injector\nlrwxr-xr-x  1 r6by  staff    41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info\n```\n\nТепер ви можете переглянути детальну інформацію про встановлений втулок Postrenderer, а також про встановлені втулки CLI та Getter, використовуючи команду `helm plugin list`:\n\n```bash\n% helm plugin list\nNAME          \tVERSION\tTYPE           \tAPIVERSION\tPROVENANCE\tSOURCE\ndemo-getter   \t0.1.0  \tgetter/v1      \tv1        \tlocal dev \tunknown\nlabel-injector\t0.1.0  \tpostrenderer/v1\tv1        \tlocal dev \tunknown\nsystem-info   \t0.1.0  \tcli/v1         \tv1        \tlocal dev \tunknown\n```\n\nДавайте спробуємо:\n\n```bash\n% helm create ../mychart\n% helm template ../mychart --post-renderer label-injector\n```\n\nУ вихідних даних ви повинні побачити такі мітки:\n\n```yaml\nmetadata:\n  labels:\n    postrendered-by: helm-label-injector-plugin\n```\n\nЩо ви створили: втулок Postrenderer, що використовує середовище виконання Subprocess!\n\nДалі створімо версію в середовищі виконання Wasm…\n\n## Wasm Runtime\n\n### Передумови {#prerequisites-1}\n\n- Вимоги з [Subprocess Runtime](#subprocess-runtime)\n- Встановлений Go 1.25\n\n:::warning\nTo-do: додати цей розділ\n:::\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/plugins/index.mdx",
    "content": "---\ntitle: Посібник з втулків\nsidebar_label: Втулки\nsidebar_position: 5.5\n---\n\nУ цьому посібнику пояснюється, що таке втулки Helm, як їх використовувати та як створювати.\n\nimport DocCardList from \"@theme/DocCardList\";\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/plugins/overview.md",
    "content": "---\ntitle: Огляд втулків\nsidebar_label: Огляд\nsidebar_position: 1\n---\n\nВтулки Helm дозволяють користувачам розширювати набір основних функцій Helm, не вимагаючи, щоб кожна нова функція була написана на Go і додана до ядра Helm.\n\nВони можуть бути написані будь-якою мовою програмування і можуть бути додані та видалені з встановлення Helm без порушення основної функціональності Helm.\n\n## Типи втулків {#plugin-types}\n\nНаразі Helm має 3 типи втулків:\n\n- [Втулки CLI](#cli-plugins): дозволяють користувачам додавати додаткові команди CLI `helm`.\n- [Втулки Getter](#getter-plugins): дозволяють користувачам використовувати чарти та навіть інші втулки в місцях, де ядро Helm не має вбудованої підтримки.\n- [Втулки Postrenderer](#postrenderer-plugins): дозволяють користувачам модифікувати маніфести, отримані в результаті рендерингу чартів, перед їх надсиланням до API Kubernetes.\n\nПочинаючи з Helm 4, система втулків налаштована таким чином, щоб полегшити додавання додаткових типів втулків, що дозволить користувачам модифікувати інші області функціональності Helm.\n\n### Втулки CLI {#cli-plugins}\n\nУ чому полягає перевага використання втулків для створення командних підпрограм CLI `helm` порівняно з використанням окремих скриптів або інструментів із власними автономними командами?\n\nГоловною причиною є те, що втулки, які додають команди CLI `helm`, можуть використовувати конфігурацію, контекст і функціональність, специфічні для Helm, які в іншому випадку автономні скрипти та інструменти мали б створювати самостійно. Вони дозволяють легше розширювати робочі процеси користувачів CLI `helm`.\n\n### Втулки Getter {#getter-plugins}\n\nHelm має вбудовану підтримку для роботи з [чартами](/glossary/index.mdx#chart) та втулками у вашій локальній файловій системі або збереженими як артефакти в [реєстрах OCI](/topics/registries.mdx). Чарти також можна зберігати в [HTTP-репозиторіях](/topics/chart_repository.md), а втулки — у репозиторіях VCS, таких як Git.\n\nВтулки Helm Getter дозволяють розширити це сховище та поведінку завантаження для підтримки інших місць зберігання. Існують втулки Getter від спільноти для зберігання чартів та втулків у [s3 buckets](/community/related#helm-plugins) та в інших місцях. Вам знадобляться втулки getter, якщо вам потрібні додаткові опції зберігання для ваших робочих процесів Helm.\n\n### Втулки PostRenderer {#postrenderer-plugins}\n\nHelm дозволяє користувачам налаштовувати чарти, вводячи власні значення. Ці значення, надані користувачами, використовуються чартами для рендерингу маніфестів, які дозволяють Helm керувати вашими застосунками в Kubernetes.\n\nЯкщо ви створюєте власні чарти, ви можете оновлювати шаблони, коли вам потрібна додаткова конфігурація для відрендерених маніфестів. Однак, якщо ви використовуєте чарти спільноти, які вам не належать, пост-рендеринг дозволяє модифікувати маніфести після того, як чарти їх відрендерили, але до того, як Helm використовує їх для управління вашими ресурсами Kubernetes. Починаючи з Helm 4, для цього використовуються втулки postrenderer.\n\n## Версії API втулків {#plugin-api-versions}\n\nПочинаючи з Helm 4, файл `plugin.yaml`, що входить до складу кожного втулка, тепер має поле `apiVersion`, яке наразі має значення `v1`.\n\nСтарі втулки (до появи версій API) будуть підтримуватися протягом усього терміну дії Helm 4, тому ваші наявні втулки з Helm 3 будуть працювати до Helm 5. Однак вам слід звернутися до авторів ваших улюблених втулків із проханням оновити їх до нової системи версій.\n\nЯкщо ви розробник втулків, дізнайтеся більше про це в [Посібнику для розробників втулків](/plugins/developer/index.mdx).\n\n## Середовища виконання втулків {#plugin-runtimes}\n\nHelm наразі підтримує 2 середовища виконання втулків:\n\n- Середовище виконання Subprocess\n- Середовище виконання Wasm\n\nВідповідну інформацію про кожне середовище виконання дивіться в [Посібнику користувача втулків](/plugins/user/index.md) або [Посібнику розробника втулків](/plugins/developer/index.mdx).\n\n## Структура файлів {#file-structure}\n\nУсі файли втулка знаходяться в одній теці, яка використовується для розробки, пакування та встановлення.\n\nУсередині теки втулка Helm очікує таку структуру:\n\n```none\nexample-plugin\n├── plugin.yaml # ОБОВʼЯЗКОВИЙ\n├── plugin.sh   # ОПЦІЙНИЙ для середовища Subprocess\n└── plugin.wasm # ОБОВʼЯЗКОВИЙ для середовища Wasm\n```\n\n- Єдиним обовʼязковим файлом є [plugin.yaml](#pluginyaml).\n- [Subprocess runtime](#plugin-runtimes) може опціонально містити один або декілька власних виконуваних файлів, що містять код вашого втулка (може бути Node, Python, Go тощо). Для цього середовища виконання ви можете також викликати будь-який виконуваний файл, що вже доступний у PATH користувача, безпосередньо з поля `plugin.yaml` [runtime configuration](#runtime-configuration) `platformCommand`.\n- Для [Wasm runtime](#plugin-runtimes) вам потрібно буде включити файл `.wasm`. Це код вашого втулка (може бути Node, Python, Go тощо), скомпільований у Wasm.\n\n## Plugin.yaml\n\nФайл `plugin.yaml` необхідний для роботи втулка. Це файл YAML, що містить метадані та конфігурацію втулка.\n\n### Інформація про метадані {#metadata-information}\n\n```yaml\napiVersion: ОБОВʼЯЗКОВО — Версія API втулка. Повинна бути \"v1\"\ntype: ОБОВʼЯЗКОВО — Версія типу втулка. Може бути \"cli/v1\", \"getter/v1\" або \"postrenderer/v1\"\nname: ОБОВʼЯЗКОВО — Назва втулка\nversion: ОБОВ'ЯЗКОВО — Версія втулка\nruntime: ОБОВ'ЯЗКОВО — Час виконання втулка. Може бути \"subprocess\" або \"extism/v1\" (Wasm).\nsourceURL: OPTIONAL — URL-адреса, що вказує на початковий код вашого втулка.\nconfig: ЗАЛЕЖИТЬ ВІД ТИПУ ВТУЛКА.\nruntimeConfig: ЗАЛЕЖИТЬ ВІД СЕРЕДОВИЩА ВИКОНАННЯ.\n```\n\n- Поле `config` призначене для [конфігурації типу втулка](#plugin-type-configuration) і має структуру, яка відрізняється залежно від [типу втулка](#plugin-types), як визначено полем `type`.\n- Поле `runtimeConfig` призначене для [конфігурації середовища виконання](#runtime-configuration) і має структуру, яка відрізняється залежно від [середовища виконання](#plugin-runtimes), як визначено полем `runtime`.\n- 💡 Хоча поле `sourceURL` є необовʼязковим, авторам втулків наполегливо рекомендується вказувати на початковий код втулка, оскільки це допомагає користувачам втулка зрозуміти, що робить код, і зробити свій внесок у розвиток втулка, якщо він приймає відкриті внески.\n\n### Конфігурація типу втулка {#plugin-type-configuration}\n\nПоле `config` у файлі [plugin.yaml](#pluginyaml) має різні опції для кожного [типу втулка](#plugin-types). Тип втулка визначається полем `type`.\n\n#### Конфігурація втулка CLI {#cli-plugin-configuration}\n\nЯкщо поле `type` має значення `cli/v1`, це [тип втулка CLI](#cli-plugins), і дозволені такі конфігурації типу втулка:\n\n```yaml\nusage: ОПЦІОНАЛЬНО — однорядковий текст використання, що показується в довідці\nshortHelp: короткий опис, що показується у виводі 'helm help'\nlongHelp: довге повідомлення, що показується у виводі \"helm help <ця-команда>\"\nignoreFlags: ігнорує будь-які прапорці, передані з Helm\n```\n\n- `usage` є необовʼязковим. Стандартно встановлено \"helm PLUGIN_NAME [прапорці]\", якщо не перевизначено за допомогою власного рядка використання. Рекомендовану синтаксичну конструкцію див. у [spf13/cobra.command.Command] Використовуйте коментар до поля: <https://pkg.go.dev/github.com/spf13/cobra#Command>\n- Перемикач `ignoreFlags` вказує Helm не передавати прапорці до втулка. Отже, якщо втулок викликається за допомогою `helm myplugin --foo` та `ignoreFlags: true`, то `--foo` мовчки відкидається.\n\n#### Конфігурація втулка Getter {#getter-plugin-configuration}\n\nЯкщо поле `type` має значення `getter/v1`, це [тип втулка Getter](#getter-plugins), і дозволені такі конфігурації типу втулка:\n\n```yaml\nprotocols: Список схем з URL-адреси чартів, які підтримує цей втулок.\n```\n\n#### Конфігурація втулка Postrenderer {#postrenderer-plugin-configuration}\n\nЯкщо поле `type` має значення `postrenderer/v1`, це [тип втулка Postrenderer](#postrenderer-plugins), який не має жодних опцій конфігурації.\n\n### Конфігурація середовища виконання {#runtime-configuration}\n\nПоле `runtimeConfig` у файлі [plugin.yaml](#pluginyaml) має різні опції для кожного [середовища виконання втулка](#plugin-runtimes). Середовище виконання втулка визначається полем `runtime`.\n\n#### Конфігурація runtime Subprocess  {#subprocess-runtime-configuration}\n\nЯкщо поле `runtime` має значення `subprocess`, це середовище виконання втулків [Subprocess Runtime](#plugin-runtimes), і дозволені такі налаштування:\n\n```yaml\nruntimeconfig:\n    platformCommand: # Налаштування команди для запуску на основі платформи\n        - os: відповідність ОС, може бути порожньою або пропущеною для відповідності будь-якій ОС\n          arch: відповідність архітектури, може бути порожньою або пропущеною для відповідності будь-якій архітектурі\n          command: команда втулка для виконання\n          args: аргументи команди втулка\n    platformHooks: # Налаштування хуків життєвого циклу втулка відповідно до платформи\n        install: # Команди життєвого циклу встановлення\n            - os: відповідність ОС, може бути порожнім або пропущеним для відповідності будь-якій ОС\n              arch: відповідність архітектури, може бути порожнім або пропущеним для відповідності будь-якій архітектурі\n              command: Команда встановлення втулка для виконання\n              args: Аргументи команди встановлення втулка\n        update: # Команди життєвого циклу оновлення\n            - os: відповідність ОС, може бути порожньою або пропущеною для відповідності будь-якій ОС\n              arch: відповідність архітектури, може бути порожньою або пропущеною для відповідності будь-якій архітектурі\n              command: Команда оновлення втулка для виконання\n              args: Аргументи команди оновлення втулка\n        delete: # Команди життєвого циклу видалення\n            - os: відповідність ОС, може бути порожньою або пропущеною для відповідності будь-якій ОС\n              arch: відповідність архітектури, може бути порожньою або пропущеною для відповідності будь-якій архітектурі\n              command: команда видалення втулка для виконання\n              args: аргументи команди видалення втулка\n    protocolCommands: # Obsolete/deprecated\n        - protocols: [] # Протоколи — це список схем з URL-адреси чарта.\n          platformCommand: [] # Та сама структура, що й \"platformCommand\" вище\n```\n\n- ⚠️ `protocolCommands` позначено як `obsolete/deprecated` і буде видалено в майбутніх версіях системи втулків після `apiVersion: v1`. Це стосується лише типу втулка \"getter/v1\". Це залишок сумісності зі старим механізмом завантаження втулків, який було розширено для підтримки декількох протоколів у певному втулку. Команда, надана в PlatformCommand, повинна реалізовувати логіку, специфічну для протоколу, шляхом перевірки URL-адреси завантаження.\n\n#### Конфігурація runtime Wasm {#wasm-runtime-configuration}\n\nЯкщо поле `runtime` має значення `extism/v1`, це середовище виконання втулків [Wasm Runtime](#plugin-runtimes), і дозволені такі налаштування:\n\n```yaml\nruntimeconfig:\n    memory: # Описує обмеження памʼяті, яку може бути виділено втулку\n        maxPages: Максимальна кількість сторінок, яку може виділити втулок. Одна сторінка становить 64 Кб. Наприклад, 16 сторінок потребують 1 Мб. Стандартно — 4 сторінки (256 Кб).\n        maxHttpResponseBytes: Максимальний розмір відповіді Extism HTTP у байтах. Стандартно — 4096 байт (4 Кбайт).\n        maxVarBytes: Максимальний розмір усіх змінних Extism у байтах. Стандартно — 4096 байт (4 Кбайт).\n    config: {} # Map у довільній формі, який можна передати втулку.\n    allowedHosts: [] # Опціональний набір хостів, з якими цей втулок може спілкуватися. Стандартно жоден хост не дозволений.\n    fileSystem:\n        createTempDir: Чи створювати тимчасову теку в файловій системі. Може бути \"true\" або \"false\".\n    timeout: Час очікування в мілісекундах для виконання втулка.\n    hostFunctions: Імена HostFunction, відкриті в Helm, до яких втулок може отримати доступ. Див. https://extism.org/docs/concepts/host-functions/\n    entryFuncName: Імʼя функції, яку потрібно викликати у втулку. Стандартно — \"helm_plugin_main\".\n```\n\n- `allowedHosts` діє лише в тому випадку, якщо втулок надсилає HTTP-запити. Якщо не вказано, жодні хости не дозволені.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/plugins/user/index.md",
    "content": "---\ntitle: Посібник користувача втулків\nsidebar_label: Використання втулків\nsidebar_position: 2\n---\n\nДля ознайомлення з концепціями втулків Helm, їхньою структурою та значенням налаштувань для користувачів, прочитайте [Огляд втулків](/plugins/overview.md).\n\nЦей розділ присвячений використанню втулків Helm кінцевими користувачами.\n\n## Пошук втулків {#finding-plugins}\n\nВи вже можете знайти [втулки Helm на ArtifactHub](https://artifacthub.io/packages/search?kind=6).\n\nСистема втулків Helm 4 є абсолютно новою. У найближчому майбутньому ви зможете шукати втулки за типом і середовищем виконання на ArtifactHub. Слідкуйте за оновленнями!\n\n## Безпека втулків {#plugin-security}\n\nЗалежно від середовища виконання втулків, перед запуском у вашій системі слід перевіряти будь-які втулки від сторонніх розробників.\n\n- Subprocess runtime має такий самий доступ до вашої системи, як і користувач, що виконує команди. Обовʼязково ретельно перевіряйте код втулків перед їх встановленням, видаленням або запуском будь-яких команд Helm, які також можуть запускати ці втулки.\n- На відміну від цього, середовище виконання Wasm працює в безпечній пісочниці з доступом до вашої системи, який ви явно затверджуєте. Це середовище виконання втулків має набагато сильніший контроль і вбудований вищий рівень безпеки. Вам все одно слід перевірити файл `plugin.yaml`, щоб дізнатися, які дозволи запитує втулок.\n\nВ обох випадках наполегливо рекомендується перевіряти походження навіть втулків Wasm runtime перед їх встановленням, щоб ви могли бути впевнені в надійності джерела завантаження та авторів. Це не тільки захистить вас від випадкового встановлення втулків із підроблених URL-адрес, але й від атак з перехопленням мережі. Перевірка втулків дозволяє криптографічно переконатися, що чарт не був скомпрометований, перш ніж ви його встановите.\n\nДивіться прапорець `--verify` в `helm plugin install --help`.\n\nВи також можете перевірити походження вже встановлених втулків за допомогою `helm plugin verify --help`, якщо перевірка була пропущена під час встановлення (для цілей розробки), а також для того, щоб у будь-який момент отримати інформацію про відповідність вимогам безпеки.\n\nКоманда `helm plugin list` також містить загальну інформацію про походження.\n\n## Встановлення втулків {#installing-plugins}\n\nHelm має вбудовану команду для встановлення втулків, яка стандартно забезпечує безпечне встановлення. Однак обовʼязково ознайомтесь із розділом [Безпека втулків](#plugin-security), щоб зрозуміти, що слід перевірити перед встановленням.\n\nДокладнішу інформацію див. у `helm plugin install --help`.\n\n## Виведення списку встановлених втулків {#listing-installed-plugins}\n\nКоманда для виведення списку втулків включає назву втулка, версію, тип, версію API, походження та джерело.\n\nДокладнішу інформацію див. у `helm plugin list --help`.\n\n## Видалення втулків {#uninstalling-plugins}\n\nВидалення втулків має бути простим і легким. Однак обовʼязково ознайомтеся з розділом [Безпека втулків](#plugin-security), щоб зрозуміти ризики, повʼязані з видаленням.\n\nДив. `helm plugin uninstall --help`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/sdk/examples.mdx",
    "content": "---\ntitle: Приклади\ndescription: Приклади різних функцій Helm SDK\nsidebar_position: 2\n---\nimport CodeBlock from '@theme/CodeBlock';\n\nimport MainExampleGo from '!!raw-loader!/sdkexamples/main.go';\nimport InstallExampleGo from '!!raw-loader!/sdkexamples/install.go';\nimport ListExampleGo from '!!raw-loader!/sdkexamples/list.go';\nimport PullExampleGo from '!!raw-loader!/sdkexamples/pull.go';\nimport UninstallExampleGo from '!!raw-loader!/sdkexamples/uninstall.go';\nimport UpgradeExampleGo from '!!raw-loader!/sdkexamples/upgrade.go';\n\nЦей документ містить низку прикладів використання Helm SDK.\nПризначений для документування різних функціональних можливостей SDK.\n\nОстанній приклад показує драйвер `main.go` ([посилання](#driver)). Він виконує наведені нижче дії та містить необхідні допоміжні функції.\n\nКод для прикладів знаходиться в теці [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples).\nВін є повністю функціональним.\n\n## Actions\n\n### Install Action\n\nЦей приклад встановлює вказаний чарт/реліз для вказаної версії та значень:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/install.go\" showLineNumbers>{InstallExampleGo}</CodeBlock>\n\n### Upgrade Action\n\nУ цьому прикладі оновлюється вказана версія з вказаним чартом, версією та значеннями:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/upgrade.go\" showLineNumbers>{UpgradeExampleGo}</CodeBlock>\n\n### Uninstall Action\n\nЦей приклад видаляє вказану версію:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/uninstall.go\" showLineNumbers>{UninstallExampleGo}</CodeBlock>\n\n### List Action\n\nУ цьому прикладі перелічено всі опубліковані чарти (у поточному просторі імен):\n\n<CodeBlock language=\"go\" title=\"sdkexamples/list.go\" showLineNumbers>{ListExampleGo}</CodeBlock>\n\n### Pull Action\n\nЦей приклад витягує чарт з репозиторію OCI:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/pull.go\" showLineNumbers>{PullExampleGo}</CodeBlock>\n\n## Driver\n\nДрайвер тут показує необхідні допоміжні функції, потрібні для роботи Helm SDK. А також демонструє на практиці наведені вище приклади, щоб витягнути, встановити, оновити та видалити чарт 'podinfo' з репозиторію OCI:\n\n<CodeBlock language=\"go\" title=\"sdkexamples/main.go\" showLineNumbers>{MainExampleGo}</CodeBlock>\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/sdk/gosdk.mdx",
    "content": "---\ntitle: Вступ\ndescription: Представляємо SDK Helm Go\nsidebar_position: 1\n---\n\nHelm's Go SDK дозволяє користувацькому програмному забезпеченню використовувати чарти Helm та функціонал Helm для управління розгортанням програмного забезпечення Kubernetes (насправді, Helm CLI є саме таким інструментом!).\n\nНаразі SDK функціонально відокремлений від Helm CLI. SDK може використовуватися (і використовується) окремими інструментами. Проєкт Helm прагне забезпечити стабільність API для SDK. Застереження: SDK має деякі недоліки, що залишилися від початкової роботи з відокремлення CLI та SDK. Проєкт Helm прагне виправити це з часом.\n\nПовну документацію API можна знайти за адресою [https://pkg.go.dev/helm.sh/helm/v4](https://pkg.go.dev/helm.sh/helm/v4).\n\nНижче наведено короткий огляд деяких основних типів пакетів та простий приклад. Більше прикладів та більш повнофункціональний 'driver' можна знайти в [Прикладах](/sdk/examples.mdx).\n\n## Огляд пакунка main {#main-package-overview}\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v4/pkg/action): Містить основного «клієнта» для виконання дій Helm. Це той самий пакунок, який використовує CLI під капотом. Якщо вам потрібно лише виконувати основні команди Helm з іншої програми Go, цей пакунок саме для вас:\n- [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): методи та допоміжні засоби, що використовуються для завантаження та обробки чартів\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v4/pkg/cli) та його підпакети: містять усі обробники для стандартних змінних середовища Helm, а його підпакети містять обробку файлів виводу та значень\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v4/pkg/release): Визначає об'єкт `Release` та статуси.\n\nКрім цих пакетів, існує ще багато інших, тож перегляньте документацію, щоб отримати додаткову інформацію!\n\n### Простий приклад {#simple-example}\n\nЦе простий приклад виконання команди `helm list` за допомогою Go SDK. Більш повні приклади дивіться в розділі [Приклади](/sdk/examples.mdx).\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v4/pkg/action\"\n    \"helm.sh/helm/v4/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // Ви можете передати порожній рядок замість settings.Namespace(), щоб перелічити\n    // всі простори імен\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Тільки список розгорнутих\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n## Сумісність {#compatibility}\n\nHelm SDK чітко дотримується гарантій зворотної сумісності Helm:\n\nhttps://github.com/helm/community/blob/main/hips/hip-0004.md\n\nТобто, кардинальні зміни будуть вноситися тільки при випуску нової основної версії або для усунення проблеми безпеки.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/sdk/index.mdx",
    "content": "---\ntitle: Go SDK\nsidebar_position: 7\n---\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/advanced.mdx",
    "content": "---\ntitle: Розширені техніки Helm\ndescription: Різні розширені функції для досвідчених користувачів Helm\nsidebar_position: 9\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nЦей розділ пояснює різні розширені функції та техніки використання Helm. Інформація в цьому розділі призначена для \"досвідчених користувачів\" Helm, які бажають здійснювати докладні налаштування та маніпуляції з їх чартами та релізами. Кожна з цих розширених функцій має свої переваги та обмеження, тому кожну з них потрібно використовувати обережно і з глибокими знаннями Helm. Іншими словами, памʼятайте про [принцип Пітера Паркера](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility).\n\n## Пост-рендеринг {#post-rendering}\n\nПост-рендеринг дає можливість встановлювачу чартів вручну маніпулювати, налаштовувати та/або перевіряти створені маніфести перед їх встановленням через Helm. Це дозволяє користувачам з додатковими потребами у налаштуванні використовувати інструменти, такі як [`kustomize`](https://kustomize.io), для застосування змін конфігурації без необхідності створювати форк публічного чарту або вимагати від супроводжувачів чартів вказувати всі можливі опції конфігурації для програмного забезпечення. Є також випадки для впровадження загальних інструментів та контейнерів sidecar у корпоративних середовищах або для аналізу маніфестів перед розгортанням.\n\n### Передумови {#prerequisites}\n\n- Helm 3.1+\n\n### Використання {#usage}\n\nПост-рендерер може бути будь-яким виконуваним файлом, який приймає створені маніфести Kubernetes через STDIN та повертає дійсні маніфести Kubernetes через STDOUT. Він повинен повертати ненульовий код завершення у випадку помилки. Це єдиний \"API\" між двома компонентами. Це дозволяє значну гнучкість у тому, що ви можете робити з вашим процесом пост-рендерингу.\n\nПост-рендерер можна використовувати з `install`, `upgrade` і `template`. Щоб використовувати пост-рендерер, використовуйте прапорець `--post-renderer` з шляхом до виконуваного файлу рендерера, який ви бажаєте використовувати:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nЯкщо шлях не містить жодних роздільників, пошук буде здійснюватись в $PATH, в іншому випадку буде створено будь-які відносні шляхи до повністю кваліфікованого шляху.\n\nЯкщо ви бажаєте використовувати кілька пост-рендерерів, викликайте їх усіх у скрипті або разом у будь-якому бінарному інструменті, який ви створили. У bash це буде так просто, як `renderer1 | renderer2 | renderer3`.\n\nПриклад використання `kustomize` як пост-рендерера можна побачити [тут](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n#### Імена файлів {#filenames}\n\nКожен маніфест, що передається до пост-рендерера, містить тимчасову анотацію:\n\n```yaml\nmetadata:\n  annotations:\n    postrenderer.helm.sh/postrender-filename: <original-template-filename>\n```\n\nHelm використовує цю анотацію під час зчитування вихідних даних пост-рендерера, щоб визначити, яке імʼя файлу повʼязати з кожним маніфестом для подальшої обробки. Якщо анотація відсутня, Helm автоматично генерує імʼя файлу у форматі `generated-by-postrender-<id>.yaml`. Нарешті, Helm видаляє анотацію перед надсиланням маніфестів до Kubernetes.\n\n### Обмеження {#caveats}\n\nПри використанні пост-рендерерів є кілька важливих моментів, які слід враховувати. Найважливіше з них полягає в тому, що при використанні пост-рендерера всі особи, які модифікують реліз, **МУСЯТЬ** використовувати той же рендерер для забезпечення повторюваних збірок. Ця функція спеціально створена для того, щоб дозволити будь-якому користувачеві змінювати рендерер або перестати використовувати рендерер, але це слід робити обережно, щоб уникнути випадкових змін або втрати даних.\n\nЩе одне важливе зауваження стосується безпеки. Якщо ви використовуєте пост-рендерер, ви повинні впевнитися, що він надходить з надійного джерела (так само як і будь-яке інше програмне забезпечення). Використання ненадійних або неперевірених рендерерів НЕ рекомендовано, оскільки вони мають повний доступ до створених шаблонів, які часто містять секретні дані.\n\n### Власні пост-рендерери {#custom-post-renderers}\n\nКрок пост-рендерингу пропонує ще більше гнучкості при використанні в Go SDK. Будь-який пост-рендерер повинен реалізувати наступний Go інтерфейс:\n\n```go\ntype PostRenderer interface {\n    // Run очікує один буфер, заповнений відрендереними маніфестами Helm. Він\n    // очікує, що модифіковані результати будуть повернені в окремому буфері або\n    // помилку, якщо виникла проблема або збій під час виконання кроку пост-рендерингу\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nБільше інформації про використання Go SDK можна знайти в [розділі Go SDK](#go-sdk).\n\n## Go SDK {#go-sdk}\n\nHelm 3 представив повністю реструктуризований Go SDK для кращого результату при створенні програмного забезпечення та інструментів, що використовують Helm. Повна документація знаходиться в [розділі Go SDK](/sdk/gosdk.mdx).\n\n## Сховища даних {#storage-backends}\n\nСтандартно інформація про реліз зберігається в Secrets в просторі імен релізу. У наступних розділах показано, як налаштувати різні бекенди. Ця конфігурація заснована на змінній середовища `HELM_DRIVER`. Її можна встановити на одне з таких значень: `[configmap, secret, sql]`.\n\n### Бекенд зберігання ConfigMap {#configmap-storage-backend}\n\nЩоб активувати бекенд ConfigMap, потрібно встановити змінну середовища `HELM_DRIVER` на `configmap`.\n\nВи можете встановити її в оболонці наступним чином:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nЯкщо ви хочете перемикнутися зі стандартного бекенду на бекенд ConfigMap, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про релізи за допомогою наступної команди:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n:::note Примітки щодо операційної діяльності\nІнформація про реліз включає вміст чартів і файлів значень, а тому може містити конфіденційні дані (такі як паролі, приватні ключі та інші облікові дані), які необхідно захищати від несанкціонованого доступу. При управлінні авторизацією 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, оскільки це може призвести до розкриття конфіденційних даних вашого застосунку.\n:::\n\n### Бекенд зберігання SQL {#sql-storage-backend}\n\nІснує ***бета-версія*** бекенду зберігання SQL, який зберігає інформацію про релізи в SQL базі даних.\n\nВикористання такого бекенду для зберігання даних є особливо корисним, якщо розмір інформації про реліз перевищує 1 МБ (у цьому випадку її неможливо зберігати в ConfigMaps/Secrets через внутрішні обмеження в базовому сховищі ключів-значень etcd Kubernetes).\n\nЩоб активувати SQL бекенд, потрібно розгорнути SQL базу даних і встановити змінну середовища `HELM_DRIVER` на `sql`. Деталі бази даних задаються змінною середовища `HELM_DRIVER_SQL_CONNECTION_STRING`.\n\nВи можете встановити її в оболонці наступним чином:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n:::note\nЗараз підтримується лише PostgreSQL.\n:::\n\n:::note Примітки щодо операційної діяльності\nРекомендується:\n\n- Підготувати вашу базу даних для операційної діяльності. Для PostgreSQL перегляньте [документацію з адміністрування сервера](https://www.postgresql.org/docs/12/admin.html) для отримання додаткової інформації.\n- Увімкнути [управління дозволами](/topics/permissions_sql_storage_backend.md) для дзеркального відображення Kubernetes RBAC для інформації про випуски.\n:::\n\nЯкщо ви хочете перемикнутися зі стандартного бекенду на SQL бекенд, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про релізи за допомогою наступної команди:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/architecture.md",
    "content": "---\ntitle: Архітектура Helm\ndescription: Загальний опис архітектури Helm.\nsidebar_position: 8\n---\n\n# Архітектура Helm\n\nЦей документ описує загальну архітектуру Helm.\n\n## Призначення Helm {#the-purpose-of-helm}\n\nHelm — є інструментом для управління пакетами Kubernetes, які називаються _чарти_. Helm може виконувати такі дії:\n\n- Створювати нові чарти з нуля\n- Пакувати чарти в файли архіву чартів (tgz)\n- Взаємодіяти з репозиторіями чартів, де зберігаються чарти\n- Встановлювати та видаляти чарти в наявному кластері Kubernetes\n- Керувати циклом релізів чартів, які були встановлені за допомогою Helm\n\nВ Helm є три важливі концепції:\n\n1. _Chart_ — це пакет інформації, необхідної для створення екземпляра застосунку Kubernetes.\n2. _Config_ — містить конфігураційну інформацію, яку можна обʼєднати з упакованим чартом для створення обʼєкта, що підлягає випуску.\n3. _Release_ — це запущений екземпляр _чарту_, поєднаний з конкретним _конфігом_.\n\n## Компоненти {#components}\n\nHelm — це виконуваний файл, який складається з двох окремих частин:\n\n**Клієнт Helm** — це клієнт командного рядка для кінцевих користувачів. Клієнт відповідає за наступне:\n\n- Розробка локальних чартів\n- Управління репозиторіями\n- Управління релізами\n- Взаємодія з бібліотекою Helm\n  - Надсилання чартів для встановлення\n  - Запит на оновлення або видалення наявних релізів\n\n**Бібліотека Helm** забезпечує логіку виконання всіх операцій Helm. Вона взаємодіє з сервером API Kubernetes і надає такі можливості:\n\n- Обʼєднання чартів і конфігурацій для створення релізу\n- Встановлення чартів у Kubernetes і надання подальшого обʼєкта релізу\n- Оновлення та видалення чартів шляхом взаємодії з Kubernetes\n\nОкрема бібліотека Helm інкапсулює логіку Helm, щоб її можна було використовувати різними клієнтами.\n\n## Реалізація {#implementation}\n\nКлієнт та бібліотека Helm написані мовою програмування Go.\n\nБібліотека використовує клієнтську бібліотеку Kubernetes для комунікації з Kubernetes. Зараз ця бібліотека використовує REST+JSON. Інформація зберігається у Secrets, розташованих всередині Kubernetes. Вона не потребує власної бази даних.\n\nКонфігураційні файли, коли це можливо, написані у YAML.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/chart_repository.md",
    "content": "---\ntitle: Довідник репозиторіїв чартів\ndescription: Як створити та працювати з репозиторіями чартів Helm.\nsidebar_position: 6\n---\n\nУ цьому розділі пояснюється, як створювати та працювати з репозиторіями чартів Helm. На загальному рівні репозиторій чартів — це місце, де можуть зберігатися та розповсюджуватися упаковані чарти.\n\nРозподілений репозиторій спільноти чартів Helm знаходиться на [Artifact Hub](https://artifacthub.io/packages/search?kind=0) та запрошує вас долучитися. Однак Helm також дозволяє вам створювати власні репозиторії чартів. Цей посібник пояснює, як це зробити. Якщо ви плануєте створити репозиторій чартів, можливо, вам варто розглянути можливість використання [OCI-реєстру](/topics/registries.mdx) замість цього.\n\n## Передумови {#prerequisites}\n\n* Ознайомтесь з посібником [Швидкий старт](/intro/quickstart.md)\n* Ознайомтесь з розділом [Чарти](/topics/charts.mdx)\n\n## Створення репозиторію чартів {#create-a-chart-repository}\n\n_Репозиторій чартів_ — це HTTP-сервер, який містить файл `index.yaml` і, за бажанням, деякі упаковані чарти. Коли ви готові поділитися своїми чартами, найкращий спосіб зробити це — завантажити їх до репозиторію чартів.\n\nПочинаючи з Helm 2.2.0, для репозиторіїв підтримується автентифікація SSL на боці клієнта. Інші протоколи автентифікації можуть бути доступні у вигляді втулків.\n\nОскільки репозиторій чартів може бути будь-яким HTTP-сервером, який може обслуговувати YAML і tar файли та відповідати на GET-запити, у вас є безліч варіантів для хостингу власного репозиторію чартів. Наприклад, ви можете використовувати Google Cloud Storage (GCS), Amazon S3, GitHub Pages або навіть розгорнути власний вебсервер.\n\n### Структура репозиторію чартів {#the-chart-repository-structure}\n\nРепозиторій чартів складається з упакованих чартів і спеціального файлу з назвою `index.yaml`, який містить індекс усіх чартів у репозиторії. Зазвичай чарти, описані в `index.yaml`, також розміщуються на тому ж сервері, що й [файли походження](/topics/provenance.mdx).\n\nНаприклад, структура репозиторію `https://example.com/charts` може виглядати так:\n\n```none\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nУ цьому випадку файл індексу міститиме інформацію про один чарт, Alpine, і надаватиме URL для завантаження `https://example.com/charts/alpine-0.1.2.tgz` для цього чарту.\n\nНе обовʼязково, щоб пакет чарту розміщувався на тому ж сервері, що й файл `index.yaml`. Однак, це часто є найпростішим варіантом.\n\n### Файл індексу {#the-index-file}\n\nФайл індексу — це YAML-файл з назвою `index.yaml`. Він містить деякі метадані про пакети, включаючи вміст файлу `Chart.yaml` чарту. Дійсний репозиторій чартів повинен мати файл індексу. Файл індексу містить інформацію про кожен чарт у репозиторії чартів. Команда `helm repo index` створить файл індексу на основі заданої локальної теки, яка містить упаковані чарти.\n\nПриклад файлу індексу:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Хостинг репозиторіїв чартів {#hosting-chart-repositories}\n\nУ цьому розділі показано кілька способів хостингу репозиторію чартів.\n\n### Google Cloud Storage\n\nПершим кроком є **створення кошика GCS**. Назвемо його `fantastic-charts`.\n\n![Створення кошика GCS](/img/helm2/create-a-bucket.png)\n\nДалі, зробіть свій кошик публічним, **встановивши дозволи кошику**.\n\n![Редагування дозволів](/img/helm2/edit-permissions.png)\n\nДодайте цей пункт, щоб **зробити кошик публічним**:\n\n![Зробити кошик публічним](/img/helm2/make-bucket-public.png)\n\nВітаємо, тепер у вас є порожній кошик GCS, готовий для обслуговування чартів!\n\nВи можете завантажити свій репозиторій чартів за допомогою командного рядка Google Cloud Storage або через вебінтерфейс GCS. Доступ до публічного кошика GCS можна отримати через простий HTTPS за цією адресою: `https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith {#cloudsmith}\n\nВи також можете налаштувати репозиторії чартів за допомогою Cloudsmith. Дізнайтеся більше про репозиторії чартів з Cloudsmith [тут](https://help.cloudsmith.io/docs/helm-chart-repository).\n\n### JFrog Artifactory {#jfrog-artifactory}\n\nАналогічно, ви можете налаштувати репозиторії чартів за допомогою JFrog Artifactory. Дізнайтеся більше про репозиторії чартів з JFrog Artifactory [тут](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories).\n\n### Приклад GitHub Pages {#github-pages-example}\n\nПодібним чином ви можете створити репозиторій чартів за допомогою GitHub Pages.\n\nGitHub дозволяє обслуговувати статичні вебсторінки двома різними способами:\n\n- Налаштувавши проєкт на обслуговування вмісту його теки `docs/`\n- Налаштувавши проєкт на обслуговування певної гілки\n\nМи скористаємося другим підходом, хоча перший також простий.\n\nПерший крок — **створити гілку gh-pages**. Ви можете зробити це локально:\n\n```console\n$ git checkout -b gh-pages\n```\n\nАбо через вебоглядач, використовуючи кнопку **Branch** у вашому репозиторії GitHub:\n\n![Створення гілки GitHub Pages](/img/helm2/create-a-gh-page-button.png)\n\nДалі потрібно переконатися, що ваша **гілка gh-pages** налаштована як GitHub Pages. Для цього натисніть у вашому репо кнопку **Settings** і прокрутіть до розділу **GitHub pages** і налаштуйте його, як показано нижче:\n\n![Налаштування гілки GitHub Pages](/img/helm2/set-a-gh-page.png)\n\nСтандартно **Source** зазвичай встановлюється на **gh-pages branch**. Якщо це не встановлено, виберіть його.\n\nВи можете використовувати **власний домен**, якщо бажаєте.\n\nІ переконайтеся, що **Enforce HTTPS** відмічено, щоб **HTTPS** використовувався під час обслуговування чартів.\n\nУ такому налаштуванні ви можете використовувати основну гілку для зберігання коду чартів, а **гілку gh-pages** як репозиторій чартів, наприклад: `https://USERNAME.github.io/REPONAME`. Демонстраційний репозиторій [TS Charts](https://github.com/technosophos/tscharts) доступний за адресою `https://technosophos.github.io/tscharts/`.\n\nЯкщо ви вирішили використовувати 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).\n\n### Звичайні вебсервери {#ordinary-web-servers}\n\nЩоб налаштувати звичайний вебсервер для обслуговування чартів Helm, вам достатньо зробити наступне:\n\n- Помістіть ваш індекс і чарти в теку, яку сервер може обслуговувати\n- Переконайтеся, що файл `index.yaml` доступний без необхідності автентифікації\n- Переконайтеся, що файли `yaml` обслуговуються з правильним типом вмісту (`text/yaml` або `text/x-yaml`)\n\nНаприклад, якщо ви хочете обслуговувати свої чарти з теки `$WEBROOT/charts`, переконайтеся, що у вашому вебкорені є тека `charts/`, і помістіть туди файл індексу та чарти.\n\n### Сервер репозиторію ChartMuseum {#chartmuseum-repository-server}\n\nChartMuseum — це сервер репозиторію чартів 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/).\n\nВи також можете використовувати сервер [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) для хостингу репозиторію чартів з локальної файлової системи.\n\n### GitLab Package Registry\n\nЗ GitLab ви можете публікувати чарти Helm у Package Registry вашого проєкту. Дізнайтеся більше про налаштування репозиторію пакетів Helm за допомогою GitLab [тут](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Управління репозиторіями чартів {#managing-chart-repositories}\n\nТепер, коли у вас є репозиторій чартів, остання частина цього посібника пояснює, як підтримувати чарти в цьому репозиторії.\n\n### Зберігання чартів у вашому репозиторії чартів {#store-charts-in-your-chart-repository}\n\nТепер, коли у вас є репозиторій чартів, завантажимо чарти та файл індексу до репозиторію. Чарти в репозиторії мають бути запаковані (`helm package chart-name/`) та правильно версійовані (відповідно до рекомендацій [SemVer 2](https://semver.org/lang/uk/)).\n\nНаступні кроки складають приклад робочого процесу, але ви можете використовувати будь-який зручний вам процес для зберігання та оновлення чартів у вашому репозиторії.\n\nЯк тільки у вас є готовий запакований чарт, створіть нову теку і перемістіть туди ваш запакований чарт.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nОстання команда бере шлях до щойно створеної локальної теки та URL вашого віддаленого репозиторію чартів і створює файл `index.yaml` у вказаній теці.\n\nТепер ви можете завантажити чарт і файл індексу у ваш репозиторій чартів, використовуючи інструмент синхронізації або вручну. Якщо ви використовуєте Google Cloud Storage, ознайомтеся з цим [прикладом робочого процесу](/howto/chart_repository_sync_example.md), що використовує клієнт gsutil. Для GitHub ви можете просто помістити чарти у відповідну гілку призначення.\n\n### Додавання нових чартів до наявного репозиторію {#adding-new-charts-to-an-existing-repository}\n\nЩоразу, коли ви хочете додати новий чарт у ваш репозиторій, потрібно перестворити індекс. Команда `helm repo index` повністю перебудовує файл `index.yaml` з нуля, включаючи лише ті чарти, які вона знаходить локально.\n\nОднак, ви можете використовувати прапорець `--merge` для поступового додавання нових чартів до наявного файлу `index.yaml` (чудовий варіант під час роботи з віддаленим репозиторієм, як-от GCS). Виконайте команду `helm repo index --help`, щоб дізнатися більше.\n\nПереконайтеся, що ви завантажили як оновлений файл `index.yaml`, так і чарт. Якщо ви згенерували файл підтвердження цілісності, завантажте і його.\n\n### Поділитися чартами з іншими {#share-your-charts-with-others}\n\nКоли ви готові поділитися чартами, просто повідомте комусь URL вашого репозиторію.\n\nПісля цього вони додадуть репозиторій до свого клієнта helm через команду `helm repo add [NAME] [URL]` з будь-яким імʼям, яке вони хочуть використовувати для позначення репозиторію.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nЯкщо чарти захищені за допомогою базової автентифікації HTTP, ви також можете вказати імʼя користувача та пароль як тут:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n:::note\nРепозиторій не буде додано, якщо він не містить дійсний файл `index.yaml`.\n:::\n\n:::note\nЯкщо ваш репозиторій helm, наприклад, використовує самопідписний сертифікат, ви можете використовувати `helm repo add --insecure-skip-tls-verify ...`, щоб пропустити перевірку CA.\n:::\n\nПісля цього ваші користувачі зможуть шукати серед ваших чартів. Після того, як ви оновите репозиторій, вони можуть використовувати команду `helm repo update`, щоб отримати найновішу інформацію про чарт.\n\n_Під капотом команди `helm repo add` і `helm repo update` завантажують файл index.yaml і зберігають його в теці `$XDG_CACHE_HOME/helm/repository/cache/`. Саме тут функція `helm search` знаходить інформацію про чарти._\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/chart_tests.md",
    "content": "---\ntitle: Тести чартів\ndescription: Опис того, як запускати та тестувати ваші чарти.\nsidebar_position: 3\n---\n\nЧарт містить ряд ресурсів та компонентів Kubernetes, які працюють разом. Як автор чарту, ви можете захотіти написати деякі тести, щоб перевірити, чи ваш чарт працює відповідно до очікувань після його встановлення. Ці тести також допомагають споживачеві чарту зрозуміти, що саме повинен робити ваш чарт.\n\n**Тест** у Helm чарті розміщується в теці `templates/` і є визначенням Job, яке вказує контейнер з певною командою для виконання. Контейнер повинен успішно завершити роботу (exit 0), щоб тест вважався успішним. Визначення Job повинно містити анотацію хука Helm: `helm.sh/hook: test`.\n\nЗверніть увагу, що до Helm v3, визначення Job повинно було містити одну з цих анотацій хука Helm: `helm.sh/hook: test-success` або `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` все ще приймається як зворотно сумісна альтернатива `helm.sh/hook: test`.\n\nПриклади тестів:\n\n- Перевірити, чи правильно завантажено вашу конфігурацію з файлу values.yaml.\n  - Перевірити, чи правильно працюють ваше імʼя користувача та пароль.\n  - Перевірити, чи не працюють неправильне імʼя користувача та пароль.\n- Перевірити, чи працюють ваші сервіси та чи правильно розподіляється навантаження.\n- тощо.\n\nВи можете запустити заздалегідь визначені тести у Helm для релізу за допомогою команди `helm test <RELEASE_NAME>`. Для споживача чарту це чудовий спосіб перевірити, чи їх реліз чарту (або застосунку) працює відповідно до очікувань.\n\n## Приклад тесту {#example-test}\n\nКоманда [helm create](/helm/helm_create.md) автоматично створює кілька тек і файлів. Щоб спробувати функціональність тестів Helm, спочатку створіть демонстраційний Helm чарт.\n\n```console\n$ helm create demo\n```\n\nТепер ви побачите таку структуру у вашому демонстраційному Helm чарті.\n\n```console\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nУ `demo/templates/tests/test-connection.yaml` ви побачите тест, який ви можете спробувати. Ось визначення Pod для тесту:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Кроки для запуску набору тестів для релізу {#steps-to-run-a-test-suite-on-a-release}\n\nПо-перше, встановіть чарт у ваш кластер, щоб створити реліз. Можливо, вам доведеться почекати, поки всі podʼи стануть активними; якщо ви запустите тест одразу після цього встановлення, він може показати транзитивну помилку, і вам доведеться повторити тестування.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Примітки {#notes}\n\n- Ви можете визначити стільки тестів, скільки бажаєте, в одному файлі yaml або розподілити їх між декількома файлами yaml у теці `templates/`.\n- Ви можете розмістити набір тестів у теці `tests/`, наприклад `<CHART-name>/templates/tests/`, для більшої ізоляції.\n- Тест є [хуком Helm](/topics/charts_hooks.md), тому з тестовими ресурсами можна використовувати такі анотації, як `helm.sh/hook-weight` та `helm.sh/hook-delete-policy`.\n- Зазвичай вміст теки `tests/` не потрібно пакувати та публікувати. Розгляньте можливість додавання `tests/` до файлу `.helmignore`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/charts.mdx",
    "content": "---\ntitle: Чарти\ndescription: Пояснення формату чартів та основні рекомендації щодо створення чартів з використанням Helm.\nsidebar_position: 1\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm використовує формат пакування, який називається _чарти_. Чарт — це набір файлів, які описують повʼязаний набір ресурсів Kubernetes. Один чарт може бути використаний для розгортання чогось простого, як, наприклад, memcached pod, або чогось складного, як повний вебстек з HTTP серверами, базами даних, кешами й так далі.\n\nЧарти створюються як файли, розташовані в певній структурі тек. Вони можуть бути упаковані у версійні архіви для розгортання.\n\nЯкщо ви хочете завантажити та переглянути файли опублікованого чарту без його встановлення, ви можете зробити це за допомогою команди `helm pull chartrepo/chartname`.\n\nЦей документ пояснює формат чарту та надає основні рекомендації щодо створення чартів з використанням Helm.\n\n## Структура файлів чарту {#the-chart-file-structure}\n\nЧарт організовано як набір файлів всередині теки. Назва теки відповідає назві чарту (без інформації про версію). Наприклад, чарт, який описує WordPress, буде зберігатися в теці `wordpress/`.\n\nВсередині цієї теки Helm очікує структуру, яка відповідає наступному:\n\n```text\nwordpress/\n  Chart.yaml          # YAML файл, що містить інформацію про чарт\n  LICENSE             # НЕОБОВʼЯЗКОВО: Текстовий файл, що містить ліцензію для чарту\n  README.md           # НЕОБОВʼЯЗКОВО: Файл README\n  values.yaml         # Файл стандартної конфігурації для цього чарту\n  values.schema.json  # НЕОБОВʼЯЗКОВО: JSON-схема для накладання структури на файл values.yaml\n  charts/             # Тека, що містить чарти, від яких залежить цей чарт.\n  crds/               # Custom Resource Definitions\n  templates/          # Тека шаблонів, які в поєднанні з values\n                      # генерують валідні файли маніфестів Kubernetes.\n  templates/NOTES.txt # НЕОБОВʼЯЗКОВО: Текстовий файл з короткими інструкціями\n```\n\nHelm резервує використання тек `charts/`, `crds/` і `templates/`, а також перелічених назв файлів. Інші файли буде залишено без змін.\n\n## Файл Chart.yaml {#the-chartyaml-file}\n\nФайл `Chart.yaml` є обовʼязковим для чарту. Він містить наступні поля:\n\n```yaml\napiVersion: Версія API чарту (обовʼязкове)\nname: Назва чарту (обовʼязкове)\nversion: Версія чарту (обовʼязково)\nkubeVersion: Діапазон сумісних версій Kubernetes за стандартом SemVer (опціонально)\ndescription: Короткий опис цього проєкту (опціонально)\ntype: Тип чарту (опціонально)\nkeywords:\n  - Перелік ключів цього проєкту (опціонально)\nhome: URL головної сторінки проєкту (опціонально)\nsources:\n  - Список URL-адрес з вихідним кодом проєкту (опціонально)\ndependencies: # Список залежностей чарту (опціонально)\n  - name: Назва чарту (nginx)\n    version: Версія чарту (\"1.2.3\")\n    repository: (опціонально) URL репозиторію (\"https://example.com/charts\") або аліас (\"@repo-name\")\n    condition: (опціонально) Шлях yaml, який перетворюється на логічне значення, використовується для ввімкнення/вимкнення чартів (наприклад, subchart1.enabled)\n    tags: # (опціонально)\n      - Теґи можуть бути використані для групування чартів для одночасного увімкнення/вимкнення\n    import-values: # (опціонально)\n      - ImportValues містить зіставлення вихідних значень з ключем батьківського елемента для імпорту. Кожен елемент може бути рядком або парою дочірніх/батьківських субсписків.\n    alias: (опціонально) Аліас, який буде використовуватися для чарту. Корисно, коли потрібно додати один і той же чарт кілька разів.\nmaintainers: # (опціонально)\n  - name: Імʼя мейнтейнера (обовʼязкове для кожного мейнтейнера)\n    email: Електронна пошта мейнтейнера (опціонально для кожного мейнтейнера)\n    url: URL для мейнтейнера (опціонально для кожного мейнтейнера)\nicon: URL-адреса зображення SVG або PNG, яке буде використовуватися як піктограма (опціонально).\nappVersion: Версія застосунку, що містить цей чарт  (опціонально). Не обовʼязково має бути SemVer. Рекомендується використовувати лапки.\ndeprecated: Чи цей чарт застарілий (опціонально, булеве значення)\nannotations:\n  example: Список анотацій, згрупованих за іменами  (опціонально).\n```\n\nПочинаючи з [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), додаткові поля не дозволені. Рекомендований підхід — додавати власні метадані в `annotations`.\n\n### Чарти та версіювання {#charts-and-versioning}\n\nКожен чарт повинен мати номер версії. Версія повинна відповідати стандарту [SemVer 2](https://semver.org/lang/uk/spec/v2.0.0.html). На відміну від Helm Classic, Helm версії 2 та новіші використовують номери версій як маркери випуску. Пакети в репозиторіях ідентифікуються за назвою та версією.\n\nНаприклад, чарт `nginx`, у якого в полі версії вказано `version: 1.2.3`, буде мати таку назву:\n\n```text\nnginx-1.2.3.tgz\n```\n\nТакож підтримуються більш складні імена SemVer 2, такі як `version: 1.2.3-alpha.1+ef365`. Але імена, що не відповідають SemVer, явно заборонені системою. Виняток становлять версії у форматі `x` або `x.y`. Наприклад, якщо на початку є v або версія вказана без усіх 3 частин (наприклад, v1.2), система спробує перетворити її на коректну семантичну версію (наприклад, v1.2.0).\n\n:::note\nЯкщо Helm Classic та Deployment Manager були тісно повʼязані з GitHub у контексті чартів, то Helm версії 2 та новіші не залежать від GitHub або навіть Git. Відповідно, Git SHAs не використовує для версіювання.\n:::\n\nПоле `version` у файлі `Chart.yaml` використовується багатьма інструментами Helm, включаючи CLI. При генерації пакета, команда `helm package` використовує версію, яку знаходить у `Chart.yaml`, як частину назви пакета. Система припускає, що номер версії в назві пакета чарту збігається з номером версії у `Chart.yaml`. Невідповідність цьому припущенню призведе до помилки.\n\n### Поле `apiVersion` {#the-apiversion-field}\n\nПоле `apiVersion` має бути `v2` для чартів Helm, які вимагають Helm версії 3 або новішої. Чарти, які підтримують попередні версії Helm, мають `apiVersion`, встановлену на `v1`, і все ще можуть бути встановлені за допомогою Helm 3.\n\nЗміни з `v1` на `v2`:\n\n- Поле `dependencies`, що визначає залежності чарту, яке в чартах `v1` знаходилося в окремому файлі `requirements.yaml` (див. [Залежності чарту](#chart-dependencies)).\n- Поле `type`, що дозволяє відрізняти чарт-застосунок від бібліотеки (див. [Типи чартів](#chart-types)).\n\n### Поле `appVersion` {#the-appversion-field}\n\nЗверніть увагу, що поле `appVersion` не повʼязане з полем `version`. Це спосіб вказати версію застосунку. Наприклад, чарт `drupal` може мати `appVersion: \"8.2.1\"`, що вказує на версію Drupal, включену в чарт (стандартно), і це буде версія `8.2.1`. Це поле є інформаційним і не впливає на розрахунки версії чарту. Наполегливо рекомендується використовувати лапки навколо значення версії. Це змушує YAML-парсер сприймати номер версії як рядок. Якщо залишити його без лапок, це може призвести до проблем із парсингом у деяких випадках. Наприклад, YAML інтерпретує `1.0` як число з плаваючою точкою, а SHA git-коміту типу `1234e10`, як наукову нотацію.\n\nЗ версії Helm v3.5.0 команда `helm create` автоматично обгортає поле `appVersion` у лапки.\n\n### Поле `kubeVersion` {#the-kubeversion-field}\n\nНеобовʼязкове поле `kubeVersion` може визначати обмеження версій semver для підтримуваної версії Kubernetes. Helm перевірить обмеження версії під час встановлення чарту та відхилить дію, якщо кластер працює на непідтримуваній версії Kubernetes.\n\nОбмеження версій можуть складатися з розділених пробілами AND-порівнянь, таких як:\n\n```semver\n>= 1.13.0 < 1.15.0\n```\n\nякі можуть бути обʼєднані за допомогою оператора OR `||`, як у наступному прикладі:\n\n```semver\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\n\nУ цьому прикладі версія `1.14.0` виключена, що може мати сенс, якщо відомо про помилку в певних версіях, яка не дозволяє чарту працювати правильно.\n\nОкрім обмежень версій з використанням операторів `=` `!=` `>` `<` `>=` `<=`, підтримуються такі скорочені нотації:\n\n* Діапазони з дефісом для закритих інтервалів, де `1.1 - 2.3.4` еквівалентно `>= 1.1 <= 2.3.4`.\n* Підстановочні знаки `x`, `X` та `*`, де `1.2.x` еквівалентно `>= 1.2.0 < 1.3.0`.\n* Діапазони з тильдою (допускаються зміни патч-версії), де `~1.2.3` еквівалентно `>= 1.2.3 < 1.3.0`.\n* Діапазони з кареткою `^` (допускаються зміни мінорної версії), де `^1.2.3` еквівалентно `>= 1.2.3 < 2.0.0`.\n\nДля детального пояснення підтримуваних обмежень версій semver див. [Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Застарівання чартів {#deprecating-charts}\n\nПід час керування чартами в репозиторії чартів іноді виникає необхідність зняти чарт з підтримки, визнати його застарілим (deprecated). Для цього можна використовувати необовʼязкове поле `deprecated` у файлі `Chart.yaml`. Якщо **latest** версія чарту в репозиторії позначена як знята з підтримки, тоді весь чарт вважається застарілим. Назву чарту можна пізніше використовувати повторно, опублікувавши нову версію, яка не позначена як знята з підтримки. Процедура зняття чартів з підтримки включає такі кроки:\n\n1. Оновіть файл `Chart.yaml` чарту, позначивши його як знятий з підтримки, і збільште номер версії.\n2. Опублікуйте нову версію чарту в репозиторії чартів.\n3. Видаліть чарт із репозиторію коду (наприклад, з git).\n\n### Типи чартів {#chart-types}\n\nПоле `type` визначає тип чарту. Є два типи: `application` та `library`. Стандартний тип — `application`, і це стандартний чарт, з яким можна повністю працювати. [Чарт-бібліотека](/topics/library_charts.md) надає утиліти або функції для розробників чарту. Чарт-бібліотека відрізняється від чарту-застосунку тим, що він не встановлюється і зазвичай не містить жодних ресурсних обʼєктіх.\n\n:::note\nЧарт-застосунок можна використовувати як чарт-бібліотеку. Це активується шляхом встановлення типу `library`. Чарт тоді буде оброблятися як чарт-бібліотека, де всі утиліти та функції можуть бути використані. Усі ресурсні обʼєкти чарту не будуть оброблені.\n:::\n\n## LICENSE, README та NOTES до чарту {#chart-license-readme-and-notes}\n\nЧарти також можуть містити файли, які описують встановлення, конфігурацію, використання та ліцензію чарту.\n\nФайл LICENSE є простим текстовим файлом, який містить [ліцензію](https://en.wikipedia.org/wiki/Software_license) для чарту. Чарт може містити ліцензію, оскільки він може містити програмну логіку в шаблонах і, отже, не буде лише конфігураційним. Також можуть бути окремі ліцензії для застосунку, який встановлюється чартом, якщо це необхідно.\n\nФайл README чарту повинен бути відформатований у Markdown (README.md) і, як правило, містити:\n\n- Опис застосунку або служби, яку надає чарт\n- Будь-які передумови або вимоги для використання чарту\n- Опис опцій у `values.yaml` та стандартні значення\n- Будь-яку іншу інформацію, яка може бути релевантною для встановлення або конфігурування чарту\n\nКоли хаби та інші інтерфейси користувача відображають деталі про чарт, ці дані витягуються з вмісту файлу `README.md`.\n\nЧарт також може містити короткий текстовий файл `templates/NOTES.txt`, який буде надрукований після встановлення і під час перегляду статусу релізу. Цей файл обробляється як [шаблон](#templates-and-values) і може використовуватися для показу заміток щодо використання, наступних кроків або будь-якої іншої інформації, яка стосується релізу чарту. Наприклад, можна надати інструкції щодо підключення до бази даних або доступу до вебінтерфейсу. Оскільки цей файл виводиться в STDOUT під час виконання команд `helm install` або `helm status`, рекомендується зберігати вміст коротким та вказувати на README для детальнішої інформації.\n\n## Залежності чартів {#chart-dependencies}\n\nУ Helm один чарт може залежати від будь-якої кількості інших чартів. Ці залежності можна динамічно звʼязувати за допомогою поля `dependencies` у файлі `Chart.yaml` або вручну керувати ними в теці `charts/`.\n\n### Керування залежностями за допомогою поля `dependencies` {#managing-dependencies-with-the-dependencies-field}\n\nЧарти, від яких залежить поточний чарт, визначаються як список у полі `dependencies`.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- Поле `name` містить імʼя потрібного чарту.\n- Поле `version` містить версію потрібного чарту.\n- Поле `repository` містить повну URL-адресу репозиторію чартів. Зверніть увагу, що ви також повинні використовувати команду `helm repo add`, щоб додати цей репозиторій локально.\n- Ви можете використовувати імʼя репозиторію замість URL-адреси.\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nПісля того як ви визначили залежності, ви можете виконати команду `helm dependency update`, і вона використає ваш файл залежностей для завантаження всіх вказаних чартів у вашу теку `charts/`.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nКоли `helm dependency update` отримує чарти, їх буде збережено як архіви чартів у теці `charts/`. Тому в наведеному вище прикладі очікується, що в теці charts будуть такі файли:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Поле alias у залежностях {#alias-field-in-dependencies}\n\nКрім інших полів, кожен запис у вимогах може містити необовʼязкове поле `alias`.\n\nДодавання псевдоніма для чарту-залежності дозволяє додати чарт у залежності, використовуючи псевдонім як назву нової залежності.\n\nМожна використовувати `alias` у випадках, коли потрібно отримати доступ до чарту за іншою назвою (назвами).\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nУ наведеному вище прикладі для `parentchart` буде три залежності:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nРучний спосіб досягнення цього — копіювання/вставка одного й того ж чарту в теку `charts/` кілька разів з різними іменами.\n\n#### Поля tags та condition у залежностях {#tags-and-condition-fields-in-dependencies}\n\nКрім інших полів, кожен запис у вимогах може містити необовʼязкові поля `tags` та `condition`.\n\nСтандартно завантажуються всі чарти. Якщо присутні поля `tags` або `condition`, вони будуть оброблені та використані для управління завантаженням чартів, до яких вони застосовуються.\n\n**Condition** — поле condition містить один або кілька шляхів YAML (розділених комами). Якщо цей шлях існує у значеннях основного чарту та оцінюється як булеве значення, чарт буде включений або виключений залежно від цього булевого значення. Оцінюється лише перший дійсний шлях у списку, і якщо шляхи не існують, то condition не має жодного ефекту.\n\n**Tags** — поле tags є списком міток YAML, повʼязаних із цим чартом. У значеннях основного чарту всі чарти з мітками можуть бути включені або виключені шляхом вказання мітки та булевого значення.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nУ наведеному вище прикладі всі чарти з міткою `front-end` будуть вимкнені, але оскільки шлях `subchart1.enabled` у значеннях основного чарту має значення `true`, умова переважає мітку `front-end`, і `subchart1` буде включений.\n\nОскільки `subchart2` має мітку `back-end`, і ця мітка має значення `true`, `subchart2` буде включений. Також зверніть увагу, що хоча `subchart2` має зазначену умову, у значеннях основного чарту немає відповідного шляху та значення, тому ця умова не має ефекту.\n\n##### Використання CLI з Tags та Conditions {#using-the-cli-with-tags-and-conditions}\n\nПараметр `--set` можна використовувати як зазвичай для зміни значень міток та умов.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Опрацювання Tags та Conditions {#tags-and-conditions-resolution}\n\n- **Conditions (коли вони встановлені в значеннях) завжди переважають Tags.** Перемагає перший наявний шлях умови, а наступні для цього чарту ігноруються.\n- Tags оцінюються так: \"якщо будь-яка з міток чарту має значення true, тоді увімкніть чарт\".\n- Значення міток та умов повинні бути встановлені у значеннях основного чарту.\n- Ключ `tags:` у значеннях має бути ключем верхнього рівня. Глобальні та вкладені таблиці `tags:` наразі не підтримуються.\n\n#### Імпорт значень дочірніх чартів через залежності  {#importing-child-values-via-dependencies}\n\nУ деяких випадках бажано дозволити значенням дочірнього чарту поширюватися на батьківський чарт і бути спільними стандартними значеннями. Додатковою перевагою використання формату `exports` є те, що він дозволить майбутнім інструментам виконувати інтерпретацію значень, які може встановлювати користувач.\n\nКлючі, що містять значення для імпорту, можуть бути вказані у полі `dependencies` батьківського чарту в полі `import-values`, використовуючи список YAML. Кожен елемент у списку — це ключ, який імпортується з поля `exports` дочірнього чарту.\n\nДля імпорту значень, які не містяться в ключі `exports`, використовуйте [формат child-parent](#using-the-child-parent-format). Приклади обох форматів описані нижче.\n\n##### Використання формату exports {#using-the-exports-format}\n\nЯкщо файл `values.yaml` дочірнього чарту містить поле `exports` на рівні кореня, його вміст може бути імпортований безпосередньо у значення батьківського чарту, через вказання ключів для імпорту, як у прикладі нижче:\n\n```yaml\n# файл Chart.yaml батьківського чарту\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# файл values.yaml дочірнього чарту\n\nexports:\n  data:\n    myint: 99\n```\n\nОскільки ми вказуємо ключ `data` у нашому списку імпорту, Helm шукає цей ключ у полі `exports` дочірнього чарту та імпортує його вміст.\n\nФінальні значення батьківського чарту міститимуть наше експортоване поле:\n\n```yaml\n# значення батьківського чарту\n\nmyint: 99\n```\n\nЗверніть увагу, що ключ `data` не міститься у фінальних значеннях батьківського чарту. Якщо вам потрібно вказати ключ батьківського чарту, використовуйте формат 'child-parent'.\n\n##### Використання формату child-parent {#using-the-child-parent-format}\n\nЩоб отримати доступ до значень, які не містяться у ключі `exports` значень дочірнього чарту, вам потрібно вказати шлях до джерела значень для імпорту (`child`) та шлях до місця призначення у значеннях батьківського чарту (`parent`).\n\nУ прикладі нижче `import-values` інструктує Helm взяти будь-які значення, знайдені в шляху `child:`, та скопіювати їх у значення батьківського чарту в шлях, вказаний у `parent:`.\n\n```yaml\n# файл Chart.yaml батьківського чарту\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nУ наведеному вище прикладі значення, знайдені у шляху `default.data` у значеннях subchart1, будуть імпортовані до ключа `myimports` у значеннях батьківського чарту, як показано нижче:\n\n```yaml\n# файл values.yaml батьківського чарту\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# файл values.yaml subchart1\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nФінальні значення батьківського чарту будуть такими:\n\n```yaml\n# фінальні значення батьківського чарту\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nФінальні значення батьківського чарту тепер містять поля `myint` та `mybool`, імпортовані з subchart1.\n\n### Керування залежностями вручну через теку `charts/` {#managing-dependencies-manually-via-the-charts-directory}\n\nЯкщо потрібен більший контроль над залежностями, їх можна визначити явно, скопіювавши залежні чарти в теку `charts/`.\n\nЗалежність повинна бути розпакованою текою чарту, але її імʼя не може починатися з `_` або `.`. Такі файли ігноруються завантажувачем чартів.\n\nНаприклад, якщо чарт WordPress залежить від чарту Apache, то чарт Apache (відповідної версії) розміщується в теці `charts/` чарту WordPress:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nНаведений вище приклад показує, як чарт WordPress виражає свою залежність від Apache та MySQL, включаючи ці чарти всередині своєї текиу `charts/`.\n\n:::tip\n_Щоб завантажити залежність у вашу теку `charts/`, використовуйте команду `helm pull`._\n:::\n\n### Операційні аспекти використання залежностей {#operational-aspects-of-using-dependencies}\n\nПопередні розділи пояснюють, як визначати залежності чартів, але як це впливає на встановлення чарту за допомогою `helm install` і `helm upgrade`?\n\nПрипустимо, що чарт з назвою \"A\" створює такі обʼєкти Kubernetes:\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nКрім того, A залежить від чарту B, який створює обʼєкти:\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nПісля встановлення/оновлення чарту A створюється або змінюється єдиний реліз Helm. Цей реліз створить або оновить усі вищевказані обʼєкти Kubernetes у такому порядку:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nЦе відбувається тому що, коли Helm встановлює/оновлює чарти, обʼєкти Kubernetes з чартів та всі їх залежності\n\n- обʼєднуються в єдиний набір; потім\n- сортуються за типом, а потім за назвою; і потім\n- створюються/оновлюються в тому ж порядку.\n\nТаким чином, створюється єдиний реліз, який містить усі обʼєкти для чарту та його залежностей.\n\nПорядок встановлення типів Kubernetes визначається переліком InstallOrder у файлі kind_sorter.go (див. [вихідний файл Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n## Шаблони та Значення {#templates-and-values}\n\nШаблони Helm Chart написані мовою [шаблонів Go](https://golang.org/pkg/text/template/) з додаванням близько 50 додаткових функцій шаблонів із бібліотеки [Sprig](https://github.com/Masterminds/sprig) та декількох інших [спеціалізованих функцій](/howto/charts_tips_and_tricks.md).\n\nВсі файли шаблонів зберігаються у теці `templates/` чарту. Коли Helm обробляє чарти, він пропускає кожен файл у цій теці через рушій шаблонів.\n\nЗначення для шаблонів надаються двома способами:\n\n- Розробники чартів можуть надати файл з назвою `values.yaml` всередині чарту. Цей файл може містити стандартні значення.\n- Користувачі чартів можуть надати YAML файл, який містить значення. Це можна зробити за допомогою команди `helm install`.\n\nКоли користувач надає власні значення, ці значення перезаписують значення у файлі `values.yaml` чарту.\n\n### Template Files\n\nФайли шаблонів дотримуються стандартних домовленостей написання Go шаблонів (див. [документацію пакету text/template Go](https://golang.org/pkg/text/template/) для деталей). Приклад файлу шаблону може виглядати так:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nВищенаведений приклад, заснований на [https://github.com/deis/charts](https://github.com/deis/charts), є шаблоном для контролера реплікацій Kubernetes. Він може використовувати наступні чотири значення шаблону (зазвичай визначені у файлі `values.yaml`):\n\n- `imageRegistry`: Джерело реєстру для Docker образу.\n- `dockerTag`: Теґ для образу Docker.\n- `pullPolicy`: Політика отримання образу Docker в Kubernetes.\n- `storage`: Сховище, стандартне значення для якого є `\"minio\"`\n\nВсі ці значення визначені автором шаблону. Helm не вимагає або не диктує параметри.\n\nДля ознайомлення з більшою кількістю робочих чартів, перегляньте CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0).\n\n### Попередньо визначені значення {#predefined-values}\n\nЗначення, які постачаються через файл `values.yaml` (або за допомогою прапорця `--set`), доступні у обʼєкті `.Values` в шаблоні. Але є й інші попередньо визначені дані, які можна використовувати у ваших шаблонах.\n\nНаступні значення є попередньо визначеними, доступні кожному шаблону і не можуть бути перевизначені. Як і всі значення, імена є _чутливими до регістру_:\n\n- `Release.Name`: Назва релізу (не чарту)\n- `Release.Namespace`: Простір імен, в який був розгорнутий чарт.\n- `Release.Service`: Сервіс, який здійснив реліз.\n- `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом.\n- `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням.\n- `Chart`: Зміст `Chart.yaml`. Таким чином, версію чарту можна отримати як `Chart.Version`, а авторів — з `Chart.Maintainers`.\n- `Files`: Обʼєкт, подібний до map, що містить усі звичайні файли в чарті. Він не надає доступу до шаблонів, але надає доступ до додаткових файлів, що присутні (якщо вони не виключені за допомогою `.helmignore`). Доступ до файлів можна отримати за допомогою `{{ index .Files \"file.name\" }}` або функції `{{.Files.Get name }}`. Ви також можете отримати доступ до вмісту файлу як `[]byte` за допомогою `{{ .Files.GetBytes }}`.\n- `Capabilities`: Обʼєкт, сподібний до map, що містить інформацію про версії Kubernetes (`{{ .Capabilities.KubeVersion }}`) та підтримувані версії API Kubernetes (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n:::note\nБудь-які невідомі поля `Chart.yaml` будуть відкинуті. Вони не будуть доступні всередині обʼєкта `Chart`. Таким чином, `Chart.yaml` не можна використовувати для передачі довільно структурованих даних у шаблон. Проте для цього можна використовувати файл значень.\n:::\n\n### Файли значень {#values-files}\n\nБеручи до уваги шаблон у попередньому розділі, файл `values.yaml`, який постачає необхідні значення, виглядатиме так:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nФайл значень має формат YAML. Чарт може містити файл стандартних значень `values.yaml`. Команда Helm install дозволяє користувачеві перевизначити значення, надавши додаткові YAML значення:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nКоли значення передаються таким чином, вони зливаються з файлом стандартних значень. Наприклад, розглянемо файл `myvals.yaml`, який виглядає так:\n\n```yaml\nstorage: \"gcs\"\n```\n\nПри злитті з `values.yaml` у чарті, результат буде:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nЗверніть увагу, що тільки останнє поле було перевизначене.\n\n:::note\nФайл стандартних значень, що включений всередині чарту, _повинен_ називатися `values.yaml`. Але файли, вказані в командному рядку, можуть мати будь-яке імʼя.\n:::\n\n:::note\nЯкщо прапорець `--set` використовується з `helm install` або `helm upgrade`, ці значення просто перетворюються в YAML на клієнтському боці.\n:::\n\n:::note\nЯкщо будь-які необхідні записи у файлі значень існують, їх можна оголосити як обовʼязкові в шаблоні чарту, використовуючи функцію [ʼrequiredʼ](/howto/charts_tips_and_tricks.md).\n:::\n\nБудь-які з цих значень доступні всередині шаблонів, використовуючи обʼєкт `.Values`:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Область видимості, залежності та значення {#scope-dependencies-and-values}\n\nФайли значень можуть оголошувати значення як для чарту верхнього рівня, так і для будь-яких чартів, які включені у теку `charts/` цього чарту. Інакше кажучи, файл значень може надавати значення чарту та його залежностям. Наприклад, чарт WordPress, що демонструється вище, має як `mysql`, так і `apache` як залежності. Файл значень може надавати значення всім цим компонентам:\n\n```yaml\ntitle: \"My WordPress Site\" # Надсилається до шаблону WordPress\n\nmysql:\n  max_connections: 100 # Надсилається до MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Передається Apache\n```\n\nЧарти вищого рівня мають доступ до всіх змінних, визначених нижче. Отже, чарт WordPress може отримати пароль MySQL як `.Values.mysql.password`. Але чарт нижчого рівня не може отримати доступ до елементів в батьківських чартах, тому MySQL не зможе отримати доступ до властивості `title`. Так само він не може отримати доступ до `apache.port`.\n\nЗначення обмежені просторами імен, але префікси просторів імен обрізаються. Тобто для чарту WordPress, він може отримати доступ до поля пароля MySQL як `.Values.mysql.password`. Але для чарту MySQL область значень зменшена і префікс простору видалено, тому він буде бачити поле пароля просто як `.Values.password`.\n\n#### Глобальні значення {#global-values}\n\nЗ версії 2.0.0-Alpha.2, Helm підтримує спеціальне \"глобальне\" значення. Розгляньте цю змінену версію попереднього прикладу:\n\n```yaml\ntitle: \"My WordPress Site\" # Надсилається до шаблону WordPress\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Надсилається до MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Передається Apache\n```\n\nВищенаведене додає розділ `global` зі значенням `app: MyWordPress`. Це значення доступне _всім_ чартам як `.Values.global.app`.\n\nНаприклад, шаблони `mysql` можуть отримати доступ до `app` як `{{ .Values.global.app }}`, так само і чарт `apache`. Фактично, файл значень вище перегенерується таким чином:\n\n```yaml\ntitle: \"My WordPress Site\" # Надсилається до шаблону WordPress\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Надсилається до MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Передається Apache\n```\n\nЦе забезпечує спосіб поділитися однією змінною верхнього рівня з усіма субчартами, що корисно для таких речей, як встановлення властивостей `metadata`, наприклад, міток.\n\nЯкщо субчарт оголошує глобальну змінну, ця глобальна змінна буде передана _далі вниз_ (в субчарти субчартів), але не _вгору_ до батьківського чарту. Немає способу, щоб субчарт впливав на значення батьківського чарту.\n\nТакож, глобальні змінні батьківських чартів мають перевагу над глобальними змінними з субчартів.\n\n### Файли схем {#schema-files}\n\nІноді розробник чарту може захотіти визначити структуру для своїх значень. Це можна зробити, визначивши схему у файлі `values.schema.json`. Схема представляється як [JSON Schema](https://json-schema.org/). Вона може виглядати приблизно так:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nЦя схема буде застосовуватися до значень для їх перевірки. Перевірка відбувається при виконанні будь-якої з наступних команд:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nПриклад файлу `values.yaml`, який відповідає вимогам цієї схеми, може виглядати так:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nЗверніть увагу, що схема застосовується до фінального обʼєкта `.Values`, а не тільки до файлу `values.yaml`. Це означає, що наступний `yaml` файл є дійсним, за умови що чарт встановлюється з відповідним параметром `--set`, як показано нижче:\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nКрім того, фінальний обʼєкт `.Values` перевіряється на відповідність _усім_ схемам субчартів. Це означає, що обмеження на субчарт не можуть бути обійдені батьківським чартом. Це також працює в зворотному напрямку — якщо субчарт має вимогу, яка не виконується у файлі `values.yaml` субчарту, батьківський чарт _повинен_ задовольняти ці вимоги, щоб бути дійсним.\n\nПеревірку схеми можна вимкнути, встановивши наведену нижче опцію. Це особливо корисно в ізольованих середовищах, коли файл JSON Schema чарту містить віддалені посилання.\n\n```console\nhelm install --skip-schema-validation\n```\n\n### Довідники {#references}\n\nЩо стосується написання шаблонів, значень та файлів схем, існує кілька стандартних довідників, які можуть вам допомогти.\n\n- [Go templates](https://godoc.org/text/template)\n- [Extra template functions](https://godoc.org/github.com/Masterminds/sprig)\n- [The YAML format](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRDs) {#custom-resource-definitions-crds}\n\nKubernetes надає механізм для оголошення нових типів обʼєктів Kubernetes. Використовуючи CustomResourceDefinitions (CRDs), розробники Kubernetes можуть оголошувати власні типи ресурсів.\n\nУ Helm 3, CRDs розглядаються як особливий вид обʼєктів. Вони встановлюються перед рештою чарту і мають певні обмеження.\n\nФайли CRD YAML повинні бути поміщені в теку `crds/` всередині чарту. Можна помістити кілька CRDs (розділених маркерами початку та кінця YAML) в один файл. Helm спробує завантажити _всі_ файли в теці CRD в Kubernetes.\n\nФайли CRD _не можуть бути шаблонізовані_. Вони повинні бути звичайними YAML документами.\n\nКоли Helm встановлює новий чарт, він завантажує CRDs, призупиняється, поки CRDs не будуть доступні через API сервер, а потім запускає рушій шаблонів, рендерить решту чарту та завантажує її в Kubernetes. Завдяки такому порядку інформація CRD доступна в обʼєкті `.Capabilities` в шаблонах Helm, і шаблони Helm можуть створювати нові екземпляри обʼєктів, які були оголошені в CRDs.\n\nНаприклад, якщо у вашому чарті є CRD для `CronTab` в теці `crds/`, ви можете створити екземпляри типу `CronTab` в теці `templates/`:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nФайл `crontab.yaml` повинен містити CRD без директив шаблона:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nТоді шаблон `mycrontab.yaml` може створити новий `CronTab` (використовуючи шаблони як звичайно):\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm забезпечить, що тип обʼєкта `CronTab` був встановлений і доступний з API сервера Kubernetes, перш ніж продовжити встановлення обʼєктів з `templates/`.\n\n### Обмеження CRDs {#limitations-on-crds}\n\nНа відміну від більшості обʼєктів у Kubernetes, CRDs встановлюються глобально. З цієї причини Helm застосовує дуже обережний підхід до управління CRDs. CRDs підлягають таким обмеженням:\n\n- CRDs ніколи не перевстановлюються. Якщо Helm визначає, що CRDs у теці `crds/` вже присутні (незалежно від версії), Helm не намагатиметься їх встановити чи оновити.\n- CRDs ніколи не встановлюються під час оновлення або відкату. Helm створює CRDs тільки під час операцій встановлення.\n- CRDs ніколи не видаляються. Видалення CRD автоматично видаляє весь вміст CRD у всіх просторах імен у кластері. Тому Helm не видалятиме CRDs.\n\nОператорам, які хочуть оновити або видалити CRDs, рекомендується робити це вручну і з великою обережністю.\n\n## Використання Helm для управління чартами {#using-helm-to-manage-charts}\n\nІнструмент `helm` має кілька команд для роботи з чартами.\n\nВін може створити новий чарт для вас:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nПісля редагування чарта, `helm` може упакувати його в архів чартів:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nВи також можете використовувати `helm`, щоб знайти проблеми з форматуванням або інформацією вашого чарта:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Репозиторії чартів {#chart-repositories}\n\n_Репозиторій чартів_ — це HTTP-сервер, який містить один або більше упакованих чартів. Хоча `helm` можна використовувати для управління локальними теками чартів, для обміну чартами переважно використовують репозиторій чартів.\n\nБудь-який HTTP-сервер, який може надавати YAML файли та tar файли та може відповідати на GET запити, можна використовувати як сервер репозиторіїв. Команда Helm тестувала деякі сервери, включаючи Google Cloud Storage з увімкненим режимом вебсайту та S3 з увімкненим режимом вебсайту.\n\nРепозиторій характеризується наявністю спеціального файлу з назвою `index.yaml`, який містить список всіх пакетів, наданих репозиторієм, разом із метаданими, які дозволяють отримувати та перевіряти ці пакети.\n\nНа стороні клієнта репозиторії управляються командами `helm repo`. Однак Helm не надає інструменти для завантаження чартів на віддалені сервери репозиторіїв. Це повʼязано з тим, що така функціональність вимагала б значних вимог до сервера, що реалізує репозиторій, і підвищувала б барʼєр для налаштування репозиторію.\n\n## Стартер-паки чартів {#chart-starter-packs}\n\nКоманда `helm create` має необовʼязковий параметр `--starter`, який дозволяє вказати \"стартовий чарт\". Також параметр стартера має короткий псевдонім `-p`.\n\nПриклади використання:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nСтартери — це звичайні чарти, але вони розташовані в `$XDG_DATA_HOME/helm/starters`. Як розробник чартів, ви можете створювати чарти, які спеціально призначені для використання як стартери. Такі чарти повинні бути спроєктовані з урахуванням наступних міркувань:\n\n- Файл `Chart.yaml` буде перезаписаний генератором.\n- Користувачі очікують, що зміст такого чарта буде змінений, тому документація повинна вказувати, як користувачі можуть це зробити.\n- Всі входження `<CHARTNAME>` будуть замінені на вказане імʼя чарту, щоб стартові чарти можна було використовувати як шаблони, за винятком деяких файлів змінних. Наприклад, якщо ви використовуєте власні файли в теці `vars` або певні файли `README.md`, `<CHARTNAME>` НЕ буде перевстановлено всередині них. Крім того, опис чарту не успадковується.\n\nНа даний момент єдиний спосіб додати чарт до `$XDG_DATA_HOME/helm/starters` — це вручну скопіювати його туди. У документації вашого чарту ви можете пояснити цей процес.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/charts_hooks.md",
    "content": "---\ntitle: Хуки чартів\ndescription: Описує, як працювати з хуками чартів.\nsidebar_position: 2\n---\n\nHelm надає механізм _хуків_, що дозволяє розробникам чартів втручатися на певних етапах життєвого циклу релізу. Наприклад, ви можете використовувати хуки для:\n\n- Завантаження ConfigMap або Secret під час встановлення до завантаження будь-яких інших чартів.\n- Виконання Job для резервного копіювання бази даних перед встановленням нового чарту, а потім виконання другого Job після оновлення для відновлення даних.\n- Запуску Job перед видаленням релізу для належного виведення сервісу з обігу перед його видаленням.\n\nХуки працюють як звичайні шаблони, але мають спеціальні анотації, які змушують Helm використовувати їх по-іншому. У цьому розділі ми розглянемо базовий шаблон використання хуків.\n\n## Доступні хуки {#the-available-hooks}\n\nВизначено наступні хуки:\n\n| Значення анотації | Опис                                                                                                   |\n| ----------------- | ------------------------------------------------------------------------------------------------------ |\n| `pre-install`     | Виконується після рендерингу шаблонів, але до створення будь-яких ресурсів у Kubernetes                |\n| `post-install`    | Виконується після завантаження всіх ресурсів у Kubernetes                                              |\n| `pre-delete`      | Виконується під час запиту на видалення перед видаленням будь-яких ресурсів з Kubernetes               |\n| `post-delete`     | Виконується під час запиту на видалення після видалення всіх ресурсів релізу                           |\n| `pre-upgrade`     | Виконується під час запиту на оновлення після рендерингу шаблонів, але до оновлення будь-яких ресурсів |\n| `post-upgrade`    | Виконується під час запиту на оновлення після оновлення всіх ресурсів релізу                           |\n| `pre-rollback`    | Виконується під час запиту на відкат після рендерингу шаблонів, але до відкату будь-яких ресурсів      |\n| `post-rollback`   | Виконується під час запиту на відкат після модифікації всіх ресурсів                                   |\n| `test`            | Виконується, коли викликано підкоманду Helm test ([див документацію тестів](/topics/chart_tests.md))   |\n\n_Зверніть увагу, що хук `crd-install` був видалений на користь теки `crds/` у Helm 3._\n\n## Хуки та життєвий цикл релізу {#hooks-and-the-release-lifecycle}\n\nХуки дозволяють вам, як розробнику чартів, виконувати операції на стратегічних етапах життєвого циклу релізу. Наприклад, розглянемо життєвий цикл для `helm install`. Стандартно життєвий цикл виглядає так:\n\n1. Користувач виконує `helm install foo`.\n2. Викликається API бібліотеки Helm для встановлення.\n3. Після деякої перевірки бібліотека рендерить шаблони `foo`.\n4. Бібліотека завантажує результуючі ресурси у Kubernetes.\n5. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту.\n6. Клієнт завершує роботу.\n\nHelm визначає два хуки для життєвого циклу `install`: `pre-install` і `post-install`. Якщо розробник чарту `foo` реалізує обидва хуки, життєвий цикл змінюється таким чином:\n\n1. Користувач виконує `helm install foo`.\n2. Викликається API бібліотеки Helm для встановлення.\n3. CRDs у теці `crds/` встановлюються.\n4. Після деякої перевірки бібліотека рендерить шаблони `foo`.\n5. Бібліотека готується виконати хуки `pre-install` (завантаження ресурсів хука у Kubernetes).\n6. Бібліотека сортує хуки за вагою (стандартно вага дорівнює 0), за типом ресурсу та нарешті за імʼям за зростанням.\n7. Бібліотека завантажує хук з найменшою вагою спочатку (від негативної до позитивної)\n8. Бібліотека чекає, поки хук стане \"Ready\" (крім CRDs)\n9. Бібліотека завантажує результуючі ресурси у Kubernetes. Зверніть увагу, що якщо встановлено прапорець `--wait`, бібліотека чекатиме, поки всі ресурси не стануть готовими, і не запустить хук `post-install`, поки вони не будуть готові.\n10. Бібліотека виконує хук `post-install` (завантаження ресурсів хука).\n11. Бібліотека чекає, поки хук стане \"Ready\".\n12. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту.\n13. Клієнт завершує роботу.\n\nЩо означає чекати, поки хук стане готовим? Це залежить від ресурсу, оголошеного в хуку. Якщо ресурс є типу `Job` або `Pod`, Helm чекатиме, поки він успішно виконається. І якщо хук не вдається, реліз зазнає невдачі. Це _блокуюча операція_, тому клієнт Helm призупиниться, поки Job виконується.\n\nДля всіх інших типів, як тільки Kubernetes позначає ресурс як завантажений (доданий або оновлений), ресурс вважається \"Ready\". Коли оголошено багато ресурсів у хуку, ресурси виконуються послідовно. Якщо у них є ваги хуків (див. нижче), вони виконуються в порядку ваг. Починаючи з Helm 3.2.0, ресурси хуків з однаковою вагою встановлюються в тому ж порядку, що і звичайні не-хукові ресурси. В іншому випадку, порядок не гарантується. (У Helm 2.3.0 і пізніше вони сортуються в алфавітному порядку. Це поведінка не є обовʼязковою і може змінитися в майбутньому.) Вважається гарною практикою додати вагу хуку та встановити її на `0`, якщо вага не є важливою.\n\n## Ресурси хуків не управляються відповідними релізами {#hook-resources-are-not-managed-with-corresponding-releases}\n\nРесурси, які створює хук, наразі не відстежуються та не управляються як частина релізу. Як тільки Helm перевіряє, що хук досяг свого готового стану, він залишає ресурс хука без змін. Збір сміття ресурсів хуків при видаленні відповідного релізу може бути додано до Helm 3 у майбутньому, тому будь-які ресурси хуків, які ніколи не повинні бути видалені, повинні бути анотовані як `helm.sh/resource-policy: keep`.\n\nПрактично це означає, що якщо ви створюєте ресурси в хуку, ви не можете покладатися на `helm uninstall`, щоб видалити ресурси. Щоб знищити такі ресурси, вам потрібно або [додати власну анотацію `helm.sh/hook-delete-policy`](#hook-deletion-policies) до файлу шаблону хука, або [встановити поле часу життя (TTL) ресурсу Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Написання хуку {#writing-a-hook}\n\nХуки — це просто манифести Kubernetes з особливими анотаціями в секції `metadata`. Оскільки це шаблони, ви можете використовувати всі звичайні можливості шаблонів, включаючи читання `.Values`, `.Release` та `.Template`.\n\nНаприклад, цей шаблон, збережений у `templates/post-install-job.yaml`, оголошує Job, який буде виконаний при `post-install`:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # Це те, що визначає цей ресурс як хук. Без цього рядка\n    # job вважається частиною релізу.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nЩо робить цей шаблон хуком, так це анотація:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nОдин ресурс може реалізовувати кілька хуків:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nАналогічно, немає обмежень на кількість різних ресурсів, які можуть реалізувати даний хук. Наприклад, можна оголосити як secret, так і config map як pre-install хук.\n\nКоли субчарти оголошують хуки, вони також оцінюються. Немає способу для основного чарту відключити хуки, оголошені субчартами.\n\nМожливо визначити вагу для хука, що допоможе створити детерміністичний порядок виконання. Ваги визначаються за допомогою наступної анотації:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nВаги хуків можуть бути позитивними або негативними числами, але повинні бути представлені як рядки. Коли Helm починає цикл виконання хуків певного типу, він сортує ці хуки у висхідному порядку.\n\n### Політики видалення хуків {#hook-deletion-policies}\n\nМожливо визначити політики, які визначають, коли видаляти відповідні ресурси хуків. Політики видалення хуків визначаються за допомогою наступної анотації:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nВи можете вибрати одне або кілька визначених значень анотацій:\n\n| Значення анотації      | Опис                                                               |\n| ---------------------- | ------------------------------------------------------------------ |\n| `before-hook-creation` | Видалити попередній ресурс перед запуском нового хуку (стандартно) |\n| `hook-succeeded`       | Видалити ресурс після успішного виконання хука                     |\n| `hook-failed`          | Видалити ресурс, якщо хук зазнав невдачі під час виконання         |\n\nЯкщо анотація політики видалення хука не вказана, стандартно застосовується поведінка `before-hook-creation`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/index.mdx",
    "content": "---\ntitle: Посібники\nsidebar_position: 3\n---\n\n# Тематичні посібники\n\nТут ви знайдете опис усіх основних частин Helm, які вам знадобляться або про які ви хочете дізнатися.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/kubernetes_apis.md",
    "content": "---\ntitle: Застарілі API Kubernetes\ndescription: Пояснення щодо застарілих API Kubernetes у Helm\n---\n\nKubernetes є системою, що керується API, і API еволюціонує з часом, відображаючи зміну розуміння проблемного простору. Це загальноприйнята практика для систем та їх API. Важливою частиною еволюції API є наявність чіткої політики застарівання та процесу, який інформує користувачів про те, як впроваджуються зміни до API. Іншими словами, споживачі вашого API повинні знати заздалегідь, коли та в якій версії API буде видалено або змінено. Це дозволяє уникнути неприємних сюрпризів та руйнівних змін для споживачів.\n\n[Політика застарівання Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) документує, як Kubernetes обробляє зміни версій API. Політика щодо застарівання визначає часові рамки підтримки версій API після оголошення про їх застарівання. Тому важливо бути в курсі оголошень про застарівання та знати, коли версії API будуть видалені, щоб мінімізувати вплив.\n\nПрикладом такого оголошення є [оголошення про видалення застарілих версій API у Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), яке було опубліковано за кілька місяців до релізу. Ці версії API були оголошені застарілими ще раніше. Це свідчить про наявність чіткої політики, яка інформує споживачів про підтримку версій API.\n\nШаблони Helm вказують [групу API Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) при визначенні обʼєкта Kubernetes, аналогічно до маніфесту Kubernetes. Це вказується в полі `apiVersion` шаблону і визначає версію API обʼєкта Kubernetes. Це означає, що користувачі Helm та підтримувачі чартів повинні знати, коли версії API Kubernetes були оголошені застарілими та в якій версії Kubernetes вони будуть видалені.\n\n## Підтримувачі чартів {#chart-maintainers}\n\nВам слід перевіряти свої чарти на наявність версій API Kubernetes, які оголошені застарілими або видаленими у певній версії Kubernetes. Виявлені версії API, які скоро перестануть підтримуватися або вже не підтримуються, слід оновити до підтримуваних версій і випустити нову версію чарту. Версія API визначається полями `kind` і `apiVersion`. Наприклад, ось версія API обʼєкта `Deployment`, яка була видалена в Kubernetes 1.16:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Користувачі Helm {#helm-users}\n\nВам слід перевірити чарти, які ви використовуєте (аналогічно до [підтримувачів чартів](#chart-maintainers)), і визначити будь-які чарти, у яких версії API застарілі або видалені у певній версії Kubernetes. Для виявлених чартів вам потрібно знайти останню версію чарту (яка містить підтримувані версії API) або оновити чарт самостійно.\n\nКрім того, вам також потрібно перевірити будь-які розгорнуті чарти (тобто релізи Helm) на наявність застарілих або видалених версій API. Це можна зробити, отримавши деталі релізу за допомогою команди `helm get manifest`.\n\nМетод оновлення релізу Helm до підтримуваних API залежить від ваших знахідок, як описано нижче:\n\n1. Якщо ви знайшли лише застарілі версії API, то:\n   - Виконайте `helm upgrade` з версією чарту, яка підтримує версії API Kubernetes.\n   - Додайте опис до оновлення, щось на зразок \"не виконувати відкат до версії Helm, що передує цій поточній версії\".\n\n2. Якщо ви знайшли будь-яку версію API, яка була видалена у версії Kubernetes, то:\n   - Якщо ви використовуєте версію Kubernetes, де ці версії API все ще доступні (наприклад, ви використовуєте Kubernetes 1.15 і виявили, що використовуєте API, які будуть видалені у Kubernetes 1.16):\n     - Дотримуйтесь процедури, описаної у пункті 1.\n   - Інакше (наприклад, ви вже використовуєте версію Kubernetes, де деякі версії API, зазначені у `helm get manifest`, більше не доступні):\n     - Вам потрібно відредагувати маніфест релізу, який зберігається в кластері, щоб оновити версії API до підтримуваних. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації.\n\n:::note\nУ всіх випадках оновлення релізу Helm до підтримуваних API ніколи не слід виконувати відкат релізу до версії, яка передує версії релізу з підтримуваними API.\n:::\n\n:::tip Рекомендація\nНайкраща практика — оновлювати релізи, використовуючи застарілі версії API, до підтримуваних версій API до того, як виконати оновлення кластера Kubernetes, який видаляє ці версії API.\n:::\n\nЯкщо ви не оновите реліз, як запропоновано вище, ви отримаєте помилку, схожу на наступну, при спробі оновити реліз у версії Kubernetes, де його версія API була видалена:\n\n```log\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm не вдається виконати оновлення в такому випадку, оскільки він намагається створити патч відмінностей між поточним розгорнутим релізом (який містить версії API Kubernetes, що були видалені в цій версії Kubernetes) та чартом, який ви передаєте з оновленими/підтримуваними версіями API. Основна причина невдачі полягає в тому, що коли Kubernetes видаляє версію API, клієнтська бібліотека Go для Kubernetes більше не може аналізувати застарілі обʼєкти, і тому Helm зазнає невдачі при виклику бібліотеки. На жаль, Helm не в змозі відновитися з такої ситуації та більше не може керувати таким релізом. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації про те, як відновитися з такої ситуації.\n\n## Оновлення версій API маніфесту релізу {#updating-api-versions-of-a-release-manifest}\n\nМаніфест є властивістю обʼєкта релізу Helm, який зберігається в полі `data` в Secret (стандартно) або ConfigMap у кластері. Поле `data` містить обʼєкт у стиснутому вигляді, закодований у base64 (існує додаткове кодування base64 для Secret). Для кожної версії/ревізії релізу існує свій Secret/ConfigMap у просторі імен релізу.\n\nВи можете використовувати втулок Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) для оновлення релізу до підтримуваних API. Ознайомтеся з readme для отримання додаткової інформації.\n\nАльтернативно, ви можете дотримуватися цих ручних кроків для оновлення версій API маніфесту релізу. Залежно від вашої конфігурації, дотримуйтесь кроків для Secret або ConfigMap.\n\n- Отримайте імʼя Secret або ConfigMap, повʼязане з останнім розгорнутим релізом:\n  - Secrets backend: `kubectl get secret -l owner=helm,status=deployed,name=<release_name> --namespace <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - ConfigMap backend: `kubectl get configmap -l owner=helm,status=deployed,name=<release_name> --namespace <release_namespace> | awk '{print $1}' | grep -v NAME`\n- Отримайте деталі останнього розгорнутого релізу:\n  - Secrets backend: `kubectl get secret <release_secret_name> -n <release_namespace> -o yaml > release.yaml`\n  - ConfigMap backend: `kubectl get configmap <release_configmap_name> -n <release_namespace> -o yaml > release.yaml`\n- Зробіть резервну копію релізу на випадок, якщо вам знадобиться відновлення у разі помилки:\n  - `cp release.yaml release.bak`\n  - У разі необхідності, відновіть: `kubectl apply -f release.bak -n <release_namespace>`\n- Розкодуйте обʼєкт релізу:\n  - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded`\n  - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded`\n- Змініть версії API маніфестів. Ви можете використовувати будь-який інструмент (наприклад, редактор) для внесення змін. Це знаходиться у полі `manifest` вашого розкодованого обʼєкта релізу (`release.data.decoded`).\n- Закодуйте обʼєкт релізу:\n  - Secrets backend: `cat release.data.decoded | gzip | base64 | base64`\n  - ConfigMap backend: `cat release.data.decoded | gzip | base64`\n- Замість значення властивості `data.release` у файлі розгорнутого релізу (`release.yaml`) вставте новий закодований обʼєкт релізу.\n- Застосуйте файл до простору імен: `kubectl apply -f release.yaml -n <release_namespace>`\n- Виконайте `helm upgrade` з версією чарта, яка підтримує версії API Kubernetes.\n- Додайте опис до оновлення, щось на зразок \"не виконувати відкат до версії Helm, що передує цій поточній версії\".\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/kubernetes_distros.md",
    "content": "---\ntitle: Дистрибутиви Kubernetes\ndescription: Зберігає інформацію про використання Helm у конкретних середовищах Kubernetes.\nsidebar_position: 10\n---\n\nHelm повинен працювати з будь-якою [сумісною версією Kubernetes](https://github.com/cncf/k8s-conformance) (незалежно від того, чи є вона [сертифікованою](https://www.cncf.io/certification/software-conformance/) чи ні).\n\nЦей документ містить інформацію про використання Helm у специфічних середовищах Kubernetes. Будь ласка, додайте більше деталей про будь-які дистрибутиви (відсортовано за алфавітом), якщо це потрібно.\n\n## AKS\n\nHelm працює з [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nHelm було протестовано і він працює на платформі Kubernetes Mesosphere DC/OS 1.11, і не вимагає додаткової конфігурації.\n\n## EKS\n\nHelm працює з Amazon Elastic Kubernetes Service (Amazon EKS): [Використання Helm з Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nПлатформа Kubernetes, що розміщена на GKE від Google, відома тим, що працює з Helm і не вимагає додаткової конфігурації.\n\n## `scripts/local-cluster` та Hyperkube {#scriptslocal-cluster-and-hyperkube}\n\nHyperkube, налаштований за допомогою `scripts/local-cluster.sh`, працює без проблем. Для використання Hyperkube у початковому вигляді може знадобитися ручне налаштування.\n\n## IKS\n\nHelm працює з [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nHelm регулярно тестується з [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne\n\nHelm працює у кластерах, які налаштовані за допомогою KubeOne без обмежень.\n\n## Kubermatic\n\nHelm працює в кластерах користувачів, які створюються Kubermatic без застережень. Оскільки початковий кластер можна налаштувати різними способами, підтримка Helm залежить від їх конфігурації.\n\n## MicroK8s\n\nHelm можна активувати в [MicroK8s](https://microk8s.io) за допомогою команди: `microk8s.enable helm3`\n\n## Minikube\n\nHelm протестований і відомий своєю сумісністю з [Minikube](https://github.com/kubernetes/minikube). Додаткової конфігурації не потребує.\n\n## Openshift\n\nHelm працює безпосередньо на OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (версія >= 3.6) або OpenShift Origin (версія >= 3.6). Дізнайтеся більше в [цьому блозі](https://blog.openshift.com/getting-started-helm-openshift/).\n\n## Platform9\n\nHelm попередньо встановлений у [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).\n\n## Ubuntu з `kubeadm` {#ubuntu-with-kubeadm}\n\nKubernetes, налаштований за допомогою `kubeadm`, відомий своєю сумісністю з наступними дистрибутивами Linux:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nДеякі версії Helm (v2.0.0-beta2) вимагають від вас `export KUBECONFIG=/etc/kubernetes/admin.conf` або створення `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid\n\nHelm працює на 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).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/library_charts.md",
    "content": "---\ntitle: Бібліотечні чарти\ndescription: Опис бібліотечних чартів та приклади їх використання\nsidebar_position: 4\n---\n\nБібліотечний чарт — це тип [Helm чарту](/topics/charts.mdx), який визначає примітиви або визначення, що можуть бути спільно використані шаблонами Helm в інших чартах. Це дозволяє користувачам ділитися фрагментами коду, які можна повторно використовувати у різних чартах, уникаючи повторень та підтримуючи чарти [DRY](https://uk.wikipedia.org/wiki/Don%27t_repeat_yourself) (Don't Repeat Yourself).\n\nБібліотечні чарти було представлено у Helm 3 для формального визнання загальних або допоміжних чартів, які використовувалися авторами чартів ще з Helm 2. Додавши їх як тип чарту, вони надають:\n\n- Спосіб чітко розрізняти загальні та чарти застосунків\n- Логіку, що запобігає встановленню загального чарту\n- Відсутність рендерингу шаблонів у загальному чарті, які можуть містити артефакти релізу\n- Дозвіл залежним чартам використовувати контекст імпортера\n\nРозробник чарту може визначити загальний чарт як бібліотечний чарт і бути впевненим, що Helm оброблятиме цей чарт стандартним та узгодженим чином. Це також означає, що визначення в чарті застосунку можна спільного використання шляхом зміни типу чарту.\n\n## Створення простого бібліотечного чарту {#creating-a-simple-library-chart}\n\nЯк згадувалося раніше, бібліотечний чарт є різновидом [Helm-чарту](/topics/charts.mdx). Це означає, що ви можете почати з створення шаблонного чарту:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nСпочатку видаліть усі файли в теці `templates`, оскільки ми будемо створювати власні визначення шаблонів у цьому прикладі.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nФайл значень (values.yaml) також не буде потрібен.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nПерш ніж перейти до створення загального коду, давайте швидко переглянемо деякі відповідні концепції Helm. [Іменований шаблон](/chart_template_guide/named_templates.md) (іноді називають partial або субшаблоном) — це просто шаблон, визначений у файлі та який має назву. У теці `templates/` будь-який файл, який починається з підкреслення (_), не призначений для виводу маніфесту Kubernetes. Тому зазвичай допоміжні шаблони та partials розміщуються у файлах `_*.tpl` або `_*.yaml`.\n\nУ цьому прикладі ми створимо загальний ConfigMap, який створює порожній ресурс ConfigMap. Ми визначимо загальний ConfigMap у файлі `mylibchart/templates/_configmap.yaml` наступним чином:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nСтруктура ConfigMap визначена в іменованому шаблоні `mylibchart.configmap.tpl`. Це простий ConfigMap з порожнім ресурсом `data`. У цьому файлі є інший іменований шаблон з назвою `mylibchart.configmap`. Цей іменований шаблон включає інший іменований шаблон `mylibchart.util.merge`, який приймає 2 іменованих шаблони як аргументи, шаблон, що викликає `mylibchart.configmap` і `mylibchart.configmap.tpl`.\n\nДопоміжна функція `mylibchart.util.merge` є іменованим шаблоном у `mylibchart/templates/_util.yaml`. Це зручний інструмент з [Загального допоміжного чарту Helm](#the-common-helm-helper-chart), оскільки він обʼєднує 2 шаблони та перевизначає будь-які спільні частини в обох:\n\n```yaml\n{{- /*\nmylibchart.util.merge обʼєднає два шаблони YAML і виведе результат.\nВін приймає масив із трьох значень:\n- контекст верхнього рівня\n- назву шаблону перевизначення (призначення)\n- назву базового шаблону (джерело)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nЦе важливо, коли чарт хоче використовувати загальний код, який йому потрібно налаштувати за допомогою своєї конфігурації.\n\nНарешті, змініть тип чарту на `library`. Це вимагає зміни файлу `mylibchart/Chart.yaml` наступним чином:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: Helm чарт для Kubernetes\n\n# Чарт може бути або 'application', або 'library'.\n#\n# Чарти застосунків — це набори шаблонів, які можна упакувати в архіви\n# з версіями для розгортання.\n#\n# # Чарт може бути чартом  'application' або 'library'.\n#\n# Чарти застосунків — це набір шаблонів, які можна упакувати в архіви з версіями для розгортання.\n#\n# Чарти бібліотек надають корисні утиліти або функції для розробника чартів. Вони включаються\n# як залежності чартів застосунків, щоб вставити ці утиліти та функції в конвеєр рендерингу.\n# Чарти бібліотек не визначають жодних шаблонів, тому їх неможливо розгорнути.\n# type: application\ntype: library\n\n# Це версія чарту. Це номер версії повинен збільшуватися кожного разу,\n# коли ви вносите зміни в чарт і його шаблони, включаючи версію програми.\nversion: 0.1.0\n\n# Це номер версії застосунку, що розгортається. Цей номер версії повинен\n# збільшуватися кожного разу, коли ви вносите зміни в застосунок,\n# рекомендується використовувати з лапками.\nappVersion: \"1.16.0\"\n```\n\nТепер бібліотечний чарт готовий до спільного використання, а його визначення ConfigMap — до повторного використання.\n\nПерш ніж продовжити, варто перевірити, чи розпізнає Helm чарт як бібліотечний:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Використання простого бібліотечного чарту {#use-the-simple-library-chart}\n\nНастав час використати бібліотечний чарт. Для цього створимо знову шаблонний чарт:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nЗнову очистимо файли шаблонів, оскільки ми хочемо створити лише ConfigMap:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nЯкщо ми хочемо створити простий ConfigMap у шаблоні Helm, він може виглядати приблизно так:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nОднак, ми будемо повторно використовувати загальний код, створений у `mylibchart`. ConfigMap можна створити у файлі `mychart/templates/configmap.yaml` наступним чином:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nВи можете побачити, що це спрощує роботу, яку ми маємо виконати, завдяки успадкуванню загального визначення ConfigMap, яке додає стандартні властивості для ConfigMap. У нашому шаблоні ми додаємо конфігурацію, в даному випадку ключ даних `myvalue` та його значення. Конфігурація замінює порожній ресурс загального ConfigMap. Це можливо завдяки допоміжній функції `mylibchart.util.merge`, про яку ми згадували в попередньому розділі.\n\nЩоб мати можливість використовувати загальний код, нам потрібно додати `mylibchart` як залежність. Додайте наступний код в кінець файлу `mychart/Chart.yaml`:\n\n```yaml\n# Загальний код у бібліотечному чарті\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nЦе включає бібліотечний чарт як динамічну залежність у файловій системі, яка знаходиться в тому ж батьківському шляху, що і чарт нашого застосунку. Оскільки ми включаємо бібліотечний чарт як динамічну залежність, нам потрібно запустити `helm dependency update`. Це скопіює бібліотечний чарт у вашу теку `charts/`.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nТепер ми готові розгорнути наш чарт. Перш ніж встановлювати, варто перевірити спочатку рендеринг шаблону.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nЦе виглядає як ConfigMap, який нам потрібен, з перезаписуванням даних `myvalue: Hello World`. Встановімо його:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nМи можемо отримати реліз і побачити, що фактичний шаблон був завантажений.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## Переваги бібліотечних чартів {#library-chart-benefits}\n\nЗ огляду на те, що бібліотечні чарти не можуть працювати як самостійні чарти, вони можуть використовувати такі функції:\n\n- Об’єкт `.Files` посилається на шляхи файлів у головному чарті, а не на локальний шлях бібліотечного чарту.\n- Об’єкт `.Values` є таким самим, як і в головному чарті, на відміну від [субчартів](/chart_template_guide/subcharts_and_globals.md) застосунків, які отримують розділ значень, налаштованих під їхнім заголовком у головному чарті.\n\n## Common Helm Helper Chart {#the-common-helm-helper-chart}\n\n:::info\nРепозиторій Common Helm Helper Chart на Github більше не підтримується, і репозиторій було визнано застарілим та зархівовано.\n:::\n\nЦей [чарт](https://github.com/helm/charts/tree/master/incubator/common) був початковим зразком для спільних чартів. Він надає утиліти, що відповідають найкращим практикам розробки чартів Kubernetes. Найкраще те, що ви можете відразу ж використовувати його під час створення своїх чартів, щоб отримати зручний код для спільного використання.\n\nОсь короткий опис того, як ним користуватися. Більш детальну інформацію можна знайти в файлі [README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nСтворіть знову шаблонний чарт:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nВикористаймо загальний код з helper chart. Спочатку відредагуйте файл deployment `demo/templates/deployment.yaml` наступним чином:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Вкажіть перевизначення для вашого ресурсу Deployment тут, наприклад\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nІ тепер файл сервісу, `demo/templates/service.yaml`, наступним чином:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Вкажіть перевизначення для вашого ресурсу Service тут, наприклад\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nЦі шаблони показують, як успадкування загального коду з helper chart спрощує написання коду до конфігурації або налаштування ресурсів.\n\nЩоб мати можливість використовувати загальний код, нам потрібно додати `common` як залежність. Додайте наступне в кінець файлу `demo/Chart.yaml`:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\n:::note\nВам потрібно буде додати `incubator` до списку репозиторіїв Helm (`helm repo add`).\n:::\n\nОскільки ми включаємо чарт як динамічну залежність, нам потрібно виконати `helm dependency update`. Це скопіює helper chart у вашу теку `charts/`.\n\nОскільки helper chart використовує деякі конструкції Helm 2, вам потрібно буде додати наступне до `demo/values.yaml`, щоб дозволити завантаження образу `nginx`, оскільки це було оновлено в шаблонному чарті Helm 3:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nВи можете перевірити, чи правильні шаблони чарту, перед розгортанням, використовуючи команди `helm lint` і `helm template`.\n\nЯкщо все добре, розгорніть чарт, використовуючи `helm install`!\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Управління правами доступу для SQL-сховища\ndescription: Дізнайтеся, як налаштувати права доступу при використанні SQL-сховища.\n---\n\nЦей документ надає рекомендації користувачам щодо налаштування та управління правами доступу при використанні SQL-сховища.\n\n## Вступ {#introduction}\n\nДля управління дозволами Helm використовує функцію RBAC Kubernetes. При використанні бекенду зберігання SQL ролі Kubernetes не можуть бути використані для визначення того, чи може користувач отримати доступ до певного ресурсу. У цьому документі показано, як створювати та керувати цими дозволами.\n\n## Ініціалізація {#initialization}\n\nПри першому підключенні CLI Helm до вашої бази даних клієнт перевірить, чи було її попередньо ініціалізовано. Якщо ні, клієнт автоматично подбає про необхідне налаштування. Для цього ініціалізація потребує адміністративних привілеїв у схемі public або принаймні можливості:\n\n* створення таблиці;\n* надання привілеїв на схему public.\n\nПісля виконання міграції в базі даних всі інші ролі зможуть використовувати клієнта.\n\n## Надання привілеїв користувачеві не адміністратору в PostgreSQL {#grant-privileges-to-a-non-admin-user-in-postgresql}\n\nДля керування правами доступу драйвер SQL-сховища використовує функцію [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row-Level Security) PostgreSQL. RLS дозволяє всім користувачам читати/записувати в одну й ту ж таблицю, але без можливості маніпулювати однаковими рядками, якщо їм це не було явно дозволено. Стандартно будь-яка роль, яка не отримала відповідних привілеїв, завжди отримуватиме порожній список при виконанні команди `helm list` і не матиме змоги отримати або змінити будь-який ресурс у кластері.\n\nРозглянемо, як надати певній ролі доступ до конкретних просторів імен:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nЦя команда надасть дозволи на читання та запис всіх ресурсів, які відповідають умові `namespace = 'default'`, для ролі `role`. Після створення цієї політики користувач, підключений до бази даних від імені ролі `role`, зможе бачити всі релізи в просторі імен `default` при виконанні команди `helm list`, а також змінювати та видаляти їх.\n\nПривілеями можна детально керувати за допомогою RLS, і ви можете бути зацікавлені в обмеженні доступу до різних стовпців таблиці:\n\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/plugins.mdx",
    "content": "---\ntitle: Втулки Helm\ndescription: Вступ до використання та створення втулків для розширення функціональних можливостей Helm.\nsidebar_position: 12\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nВтулок Helm — це інструмент, до якого можна отримати доступ через CLI `helm`, але який не є частиною основного коду Helm.\n\nНаявні втулки можна знайти у [відповідному](/community/related#helm-plugins) розділі або шукаючи на [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).\n\nЦей посібник пояснює, як використовувати та створювати втулки.\n\n## Огляд {#an-overview}\n\nВтулки Helm — це додаткові інструменти, які легко інтегруються з Helm. Вони дають змогу розширити базовий набір функцій Helm, але без необхідності писати кожну нову функцію на Go та додавати її до основного інструменту.\n\nВтулки Helm мають такі особливості:\n\n- Їх можна додавати та видаляти з установки Helm без впливу на основний інструмент Helm.\n- Вони можуть бути написані будь-якою мовою програмування.\n- Вони інтегруються з Helm і будуть відображатися в `helm help` та інших місцях.\n\nВтулки Helm знаходяться в `$HELM_PLUGINS`. Ви можете дізнатися поточне значення цієї змінної, включаючи стандартні значення, коли не задано в середовищі, за допомогою команди `helm env`.\n\nМодель втулок Helm частково базується на моделі втулків Git. Тому інколи можна почути, що `helm` називають шаром _porcelain_, а втулки — _plumbing_. Це скорочений спосіб сказати, що Helm забезпечує взаємодію з користувачем і логіку обробки на найвищому рівні, а втулки виконують «детальну роботу» з виконання бажаних дій.\n\n## Встановлення втулків {#installing-a-plugin}\n\nВтулки встановлюються за допомогою команди `$ helm plugin install <path|url>`. Ви можете передати шлях до втулка у вашій локальній файловій системі або URL віддаленого репозиторію VCS. Команда `helm plugin install` клонуватиме або копіюватиме втулок за вказаним шляхом/URL у `$HELM_PLUGINS`.\n\n```shell\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nЯкщо у вас є дистрибутив втулка у форматі tar, просто розпакуйте втулок у теку `$HELM_PLUGINS`. Ви також можете встановлювати втулки з архівів безпосередньо з URL, використовуючи `helm plugin install https://domain/path/to/plugin.tar.gz`.\n\n## Структура файлів втулка {#the-plugin-file-structure}\n\nБагато в чому втулок схожий на чарт. Кожен втулок має теку верхнього рівня, що містить файл `plugin.yaml`. Можуть бути присутні додаткові файли, але обовʼязковим є лише файл `plugin.yaml`.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## Файл plugin.yaml {#the-pluginyaml-file}\n\nФайл plugin.yaml є обовʼязковим для втулка. Він містить такі поля:\n\n```yaml\nname: Назва втулка (ОБОВʼЯЗКОВО)\nversion: Версія в форматі SemVer 2 (ОБОВʼЯЗКОВО)\nusage: Текст використання в один рядок, що показується в довідці\ndescription: Довгий опис, що показується в таких місцях, як довідка helm\nignoreFlags: Ігнорувати прапорці передані з Helm\nplatformCommand: # Параметри конфігурації команди для виконання залежно від платформи\n  - os: Відповідність ОС, може бути порожньою або відсутньою для відповідності всім ОС\n    arch: Відповідність архітектури, може бути порожньою або відсутньою для відповідності всім архітектурам\n    command: Команда втулка для запуску\n    args: Аргументи команди втулка\ncommand: (ЗАСТАРІЛЕ) Команда втулка, використовуйте  platformCommand натомість\nplatformHooks: # Параметри життєвого циклу втулка залежно від платформи\n  install: # Параметри команд встановлення життєвого циклу\n    - os: Відповідність ОС, може бути порожньою або відсутньою для відповідності всім ОС\n      arch: Відповідність архітектури, може бути порожньою або відсутньою для відповідності всім архітектурам\n      command: Команда встановлення втулка для виконання\n      args: Аргументи команди встановлення втулка\n  update: # Параметри команд оновлення життєвого циклу\n    - os: Відповідність ОС, може бути порожньою або відсутньою для відповідності всім ОС\n      arch: Відповідність архітектури, може бути порожньою або відсутньою для відповідності всім архітектурам\n      command: Команда оновлення втулка для виконання\n      args: Аргументи команди оновлення втулка\n  delete: # Параметри команд видалення життєвого циклу\n    - os: Відповідність ОС, може бути порожньою або відсутньою для відповідності всім ОС\n      arch: Відповідність архітектури, може бути порожньою або відсутньою для відповідності всім архітектурам\n      command: Команда видалення втулка для виконання\n      args: Аргументи команди видалення втулка\nhooks: # (ЗАСТАРІЛЕ) Життєвий цикл втулка, використовуйте platformHooks натомість\n  install: Команда встановлення втулка\n  update: Команда оновлення втулка\n  delete: Команда видалення втулка\ndownloaders: # Налаштування можливостей завантажувачів\n  - command: Команда для виклику\n    protocols:\n      - Схема протоколу, що підтримується\n```\n\n### Поле `name` {#the-name-field}\n\nПоле `name` є назвою втулка. Коли Helm виконує цей втулок, буде використане це імʼя (наприклад, `helm NAME` викличе цей втулок).\n\n_`name` має збігатись з назвою теки._ У нашому прикладі вище це означає, що втулок з `name: last` повинен міститися в теці з назвою `last`.\n\nОбмеження для `name`:\n\n- `name` не може дублювати одну з наявних верхньорівневих команд `helm`.\n- `name` повинен містити лише символи ASCII a-z, A-Z, 0-9, `_` та `-`.\n\n### Поле `version` {#the-version-field}\n\nПоле `version` є версією втулка у форматі SemVer 2. `usage` та `description` використовуються для генерації тексту довідки команди.\n\n### Поле `ignoreFlags` {#the-ignoreflags-field}\n\nПоле `ignoreFlags` вказує Helm _не_ передавати прапорці втулку. Тож, якщо\nвтулок викликається з `helm myplugin --foo` і `ignoreFlags: true`, тоді\n`--foo` буде мовчки проігноровано.\n\n### Поле `platformCommand` {#the-platformcommand-field}\n\nПоле `platformCommand` налаштовує команду, яку втулок виконуватиме при\nвиклику. Ви не можете встановлювати одночасно `platformCommand` та `command`, оскільки це призведе до помилки. Наступні правила застосовуватимуться при виборі команди:\n\n- Якщо `platformCommand` присутнє, буде використана вказана команда.\n  - Якщо і `os`, і `arch` збігаються з поточною платформою, пошук припиниться і\n  команда буде використана.\n  - Якщо `os` збігається, а `arch` порожнє, команда буде використана.\n  - Якщо і `os`, і `arch` порожні, команда буде використана.\n  - Якщо немає збігу, Helm завершить роботу з помилкою.\n- Якщо `platformCommand` відсутнє, а застаріле поле `command` присутнє, воно буде використане.\n  - Якщо команда не вказана, Helm завершить роботу з помилкою.\n\n### Поле `platformHooks` {#the-platformhooks-field}\n\nПоле `platformHooks` налаштовує команди, які втулок виконуватиме для подій життєвого циклу. Ви не можете встановлювати одночасно `platformHooks` та `hooks`, оскільки це призведе до помилки. Наступні правила застосовуватимуться при виборі команди для хуку:\n\n- Якщо `platformHooks` присутнє, воно буде використане, і команди для події життєвого циклу будуть оброблені.\n  - Якщо і `os`, і `arch` збігаються з поточною платформою, пошук припиниться і команда буде використана.\n  - Якщо `os` збігається, а `arch` порожнє, команда буде використана.\n  - Якщо і `os`, і `arch` порожні, команда буде використана.\n  - Якщо немає збігу, Helm пропустить подію.\n- Якщо `platformHooks` відсутнє, а застаріле поле `hooks` присутнє, команда для події життєвого циклу буде використана.\n  - Якщо команда не вказана, Helm пропустить подію.\n\n## Створення втулків {#building-a-plugin}\n\nОсь YAML-файл для простого втулка, який допомагає отримати назву останнього релізу:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: отримує назву останнього релізу\ndescription: отримує назву останнього релізу\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nВтулки можуть вимагати додаткових скриптів та виконуваних файлів. Скрипти можуть бути включені в теку втулка, а виконувані файли можна завантажити за допомогою хука. Нижче наведено приклад:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: демонстраційний втулок\ndescription: демонстраційний втулок\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nЗмінні середовища інтерполюються перед виконанням втулка. Наведений вище шаблон ілюструє найкращий спосіб вказати місцезнаходження застосунку втулка.\n\n### Команди втулка {#plugin-commands}\n\nІснує кілька стратегій роботи з командами втулка:\n\n- Якщо втулок містить виконуваний файл, виконуваний файл для `platformCommand:` або повинен бути упакований у теку втулка або встановлений за допомогою хука.\n- Перед виконанням рядка `platformCommand:` або `command:` будуть розгорнуті всі змінні середовища. `$HELM_PLUGIN_DIR` вказуватиме на теку втулка.\n- Сама команда не виконується в оболонці. Тому ви не можете виконати скрипт оболонки в одному рядку.\n- Helm вводить багато конфігурацій у змінні середовища. Подивіться на середовище, щоб побачити, яка інформація доступна.\n- Helm не робить жодних припущень щодо мови втулка. Ви можете писати його будь-якою мовою, яку вважаєте за потрібне.\n- Команди відповідають за реалізацію конкретного тексту довідки для `-h` та `--help`. Helm використовуватиме `usage` та `description` для `helm help` та `helm help myplugin`, але не оброблятиме `helm myplugin --help`.\n\n### Тестування локального втулка {#testing-a-local-plugin}\n\nСпочатку потрібно знайти шлях `HELM_PLUGINS`, для цього виконайте наступну команду:\n\n``` bash\nhelm env\n```\n\nЗмініть поточну теку на теку, в яку встановлено `HELM_PLUGINS`.\n\nТепер ви можете додати символічне посилання на збірку вашого втулка, у цьому прикладі ми зробили це для `mapkubeapis`.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Завантажувач втулків {#downloader-plugins}\n\nСтандартно Helm здатен завантажувати чарти за допомогою HTTP/S. Починаючи з версії Helm 2.4.0, втулки можуть мати спеціальну можливість завантажувати чарти з довільних джерел.\n\nВтулки повинні оголосити цю спеціальну можливість у файлі `plugin.yaml` (на верхньому рівні):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nЯкщо такий втулок встановлений, Helm може взаємодіяти з репозиторієм, використовуючи вказану схему протоколу, викликавши `command`. Спеціальний репозиторій слід додати так само як і звичайні: `helm repo add favorite myprotocol://example.com/`. Правила для спеціальних репозиторіїв такі ж, як і для звичайних: Helm повинен бути здатен завантажити файл `index.yaml`, щоб виявити та зберегти список доступних чартів.\n\nВизначена команда буде викликана за схемою: `command certFile keyFile caFile full-URL`. Облікові відомості SSL беруться з визначення репозиторію, що зберігається в `$HELM_REPOSITORY_CONFIG` (тобто `$HELM_CONFIG_HOME/repositories.yaml`). Очікується, що команда завантажувача виведе сирий контент на stdout і повідомить про помилки на stderr.\n\nКоманда завантажувача також підтримує підкоманди або аргументи, що дозволяє, наприклад, вказати `bin/mydownloader subcommand -d` у `plugin.yaml`. Це корисно, якщо ви хочете використовувати один і той же виконуваний файл для основної команди втулка та команди завантажувача, але з різною підкомандою для кожної.\n\n## Змінні середовища {#environment-variables}\n\nКоли Helm виконує втулок, він передає змінну зовнішнього середовища втулку та також деякі додаткові змінні середовища.\n\nЗмінні, такі як `KUBECONFIG`, встановлюються для втулка, якщо вони встановлені у зовнішньому середовищі.\n\nГарантовано будуть встановлені такі змінні:\n\n- `HELM_PLUGINS`: Шлях до теки втулків.\n- `HELM_PLUGIN_NAME`: Імʼя втулка, яке використовується при виклику через `helm`. Тобто `helm myplug` матиме коротке імʼя `myplug`.\n- `HELM_PLUGIN_DIR`: Тека, що містить втулок.\n- `HELM_BIN`: Шлях до команди `helm` (як виконана користувачем).\n- `HELM_DEBUG`: Вказує, чи був встановлений прапорець налагодження.\n- `HELM_REGISTRY_CONFIG`: Місце для конфігурації реєстру (якщо використовується). Зазначте, що використання Helm з реєстрами є експериментальною функцією.\n- `HELM_REPOSITORY_CACHE`: Шлях до кеш-файлів репозиторіїв.\n- `HELM_REPOSITORY_CONFIG`: Шлях до файлу конфігурації репозиторію.\n- `HELM_NAMESPACE`: Простір імен, вказаний команді `helm` (зазвичай за допомогою прапорця `-n`).\n- `HELM_KUBECONTEXT`: Назва контексту конфігурації Kubernetes, наданого команді `helm`.\n\nКрім того, якщо конфігураційний файл Kubernetes був явно вказаний, він буде встановлений як змінна `KUBECONFIG`.\n\n## Примітка про парсинг прапорців {#note-on-flag-parsing}\n\nПри виконанні втулка Helm буде розбирати глобальні прапорці для власного використання. Жоден з цих пропорців не передається втулку.\n\n- `--burst-limit`: Це перетворюється в `$HELM_BURST_LIMIT`.\n- `--debug`: Якщо цей прапорець вказаний, `$HELM_DEBUG` встановлюється в `1`.\n- `--kube-apiserver`: Це перетворюється в `$HELM_KUBEAPISERVER`.\n- `--kube-as-group`: Ці перетворюються в `$HELM_KUBEASGROUPS`.\n- `--kube-as-user`: Це перетворюється в `$HELM_KUBEASUSER`.\n- `--kube-ca-file`: Це перетворюється в `$HELM_KUBECAFILE`.\n- `--kube-context`: Це перетворюється в `$HELM_KUBECONTEXT`.\n- `--kube-insecure-skip-tls-verify`: Це перетворюється в `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`.\n- `--kube-tls-server-name`: Це перетворюється в `$HELM_KUBETLS_SERVER_NAME`.\n- `--kube-token`: Це перетворюється в `$HELM_KUBETOKEN`.\n- `--kubeconfig`: Це перетворюється в `$KUBECONFIG`.\n- `--namespace` and `-n`: Це перетворюється в `$HELM_NAMESPACE`.\n- `--qps`: Це перетворюється в `$HELM_QPS`.\n- `--registry-config`: Це перетворюється в `$HELM_REGISTRY_CONFIG`.\n- `--repository-cache`: Це перетворюється в `$HELM_REPOSITORY_CACHE`.\n- `--repository-config`: Це перетворюється в `$HELM_REPOSITORY_CONFIG`.\n\nВтулки _повинні_ відображати текст довідки та виходити для `-h` та `--help`. У всіх інших випадках втулки можуть використовувати прапорці за потреби.\n\n## Надання автозавершення оболонки {#providing-shell-auto-completion}\n\nПочинаючи з Helm 3.2, втулок може додатково підтримувати автозавершення оболонки як частину наявного механізму автозавершення Helm.\n\n### Статичне автозавершення {#static-auto-completion}\n\nЯкщо втулок надає свої власні прапорці та/або підкоманди, він може сповістити Helm про них, маючи файл `completion.yaml`, розташований у кореневій теці втулка. Файл `completion.yaml` має форму:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nПримітки:\n\n1. Усі секції є необовʼязковими, але їх слід надати, якщо треба.\n1. Прапорці не повинні включати префікс `-` або `--`.\n1. Як короткі, так і довгі прапорці можуть і повинні бути вказані. Короткий прапорець не потребує асоціації з відповідною довгою формою, але обидві форми слід перерахувати.\n1. Прапорці не потрібно упорядковувати будь-яким чином, але їх слід перераховувати в правильному місці в ієрархії підкоманд файлу.\n1. Глобальні прапорці Helm вже обробляються механізмом автозавершення Helm, тому втулкам не потрібно вказувати наступні прапорці `--debug`, `--namespace` або `-n`, `--kube-context`, і `--kubeconfig`, або будь-які інші глобальні прапорці.\n1. Список `validArgs` надає статичний список можливих завершень для першого параметра після підкоманди. Можливо не завжди надати такий список заздалегідь (див. розділ [Динамічне завершення](#dynamic-completion) нижче), у цьому випадку розділ `validArgs` можна пропустити.\n\nФайл `completion.yaml` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати автозавершення оболонки для втулка (якщо не підтримується [Динамічне завершення](#dynamic-completion) втулком). Крім того, додавання файлу `completion.yaml` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm.\n\nЯк приклад, для втулка [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus), який не має підкоманд, але приймає ті ж прапорці, що й команда `helm status`, файл `completion.yaml` виглядає так:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\n### Динамічне автозавершення {#dynamic-completion}\n\nПочинаючи з Helm 3.2, втулки можуть надавати динамічне автозавершення оболонки. Динамічне автозавершення забезпечує завершення значень параметрів або прапорців, які не можуть бути визначені заздалегідь. Наприклад, завершення імен Helm релізів, які наразі доступні в кластері.\n\nЩоб втулок підтримував динамічне автозавершення, він повинен надати **виконуваний** файл з назвою `plugin.complete` у своїй кореневій теці. Коли скрипт автозавершення Helm потребує динамічного завершення для втулка, він виконає файл `plugin.complete`, передаючи йому командний рядок, який потрібно завершити. Виконуваний файл `plugin.complete` повинен містити логіку для визначення правильних варіантів завершення та виводити їх на стандартний вихід, щоб їх можна було спожити скриптом автозавершення Helm.\n\nФайл `plugin.complete` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати динамічне автозавершення для втулка. Крім того, додавання файлу `plugin.complete` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm.\n\nВихідний результат скрипту `plugin.complete` повинен бути списком, розділеним символом нового рядка (`\\n`), наприклад:\n\n```console\nrel1\nrel2\nrel3\n```\n\nКоли `plugin.complete` викликаний, середовище втулка встановлено так само, як і при виклику основного скрипту втулка. Отже, змінні `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` та всі інші змінні втулка вже будуть встановлені, а відповідні глобальні прапорці будуть видалені.\n\nФайл `plugin.complete` може бути будь-якої виконуваної форми; це може бути shell-скрипт, програма на Go або будь-яка інша програма, яку Helm може виконати. Файл `plugin.complete` _**повинен**_ мати права на виконання для користувача. Файл `plugin.complete` _**повинен**_ завершитися з кодом успіху (значення 0).\n\nУ деяких випадках динамічне завершення вимагатиме отримання інформації з кластера Kubernetes. Наприклад, втулок `helm fullstatus` потребує імені релізу як вводу. У втулку `fullstatus`, щоб скрипт `plugin.complete` надав завершення для поточних імен релізів, він може просто виконати `helm list -q` і вивести результат.\n\nЯкщо ви бажаєте використовувати один і той же виконуваний файл для виконання втулка та для завершення втулка, скрипт `plugin.complete` може викликати основний виконуваний файл втулка з певним спеціальним параметром або прапорцем; коли основний виконуваний файл втулка виявляє спеціальний параметр або прапорець, він буде знати, що потрібно виконати завершення. У нашому прикладі `plugin.complete` може бути реалізований так:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" є всім командним рядком, який потребує завершення.\n# Важливо використовувати подвійні лапки в змінній \"$@\", щоб зберегти можливий пустий останній параметр.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nСправжній скрипт втулка `fullstatus` (`status.sh`) повинен тоді шукати прапорець `--complete` і, якщо знайде його, вивести правильні завершення.\n\n### Поради та підказки {#tips-and-tricks}\n\n1. Оболонка автоматично відфільтровує варіанти завершення, які не відповідають введенню користувача. Отже, втулок може повернути всі відповідні завершення без видалення тих, які не відповідають введенню користувача. Наприклад, якщо командний рядок `helm fullstatus ngin<TAB>`, скрипт `plugin.complete` може вивести _всі_ імена релізів (з простору імен `default`), а не лише ті, що починаються з `ngin`; оболонка зберігає лише ті, що починаються з `ngin`.\n2. Щоб спростити підтримку динамічного завершення, особливо якщо у вас складний втулок, ви можете налаштувати скрипт `plugin.complete`, щоб він викликав основний скрипт втулка і запитував варіанти завершення. Дивіться розділ [Динамічне завершення](#dynamic-completion) вище для прикладу.\n3. Для налагодження динамічного завершення та файлу `plugin.complete` можна виконати наступне, щоб побачити результати завершення:\n   - `helm __complete <pluginName> <arguments to complete>`. Наприклад:\n   - `helm __complete fullstatus --output js<ENTER>`,\n   - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/provenance.mdx",
    "content": "---\ntitle: Підтвердження походження та цілісності в Helm\ndescription: Як перевірити цілісність та походження чарту.\nsidebar_position: 5\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm має інструменти підтвердження походження, які допомагають користувачам чартів перевіряти цілісність та походження пакета. Використовуючи інструменти на основі PKI, GnuPG та відомих менеджерів пакетів, Helm може генерувати та перевіряти файли підписів.\n\n## Огляд {#overview}\n\nЦілісність встановлюється шляхом порівняння чарту з записом про походження. Записи про походження зберігаються у _файлах походження_, які зберігаються поряд з упакованим чартом. Наприклад, якщо чарт називається `myapp-1.2.3.tgz`, то файл походження буде `myapp-1.2.3.tgz.prov`.\n\nФайли походження генеруються під час пакування (`helm package --sign ...`) і можуть бути перевірені кількома командами, зокрема `helm install --verify`.\n\n## Робочий процес {#the-workflow}\n\nУ цьому розділі описано можливий порядок дій для ефективного використання даних про походження.\n\nПередумови:\n\n- Дійсна пара ключів PGP у бінарному (не ASCII-зашифрованому) форматі\n- Інструмент командного рядка `helm`\n- Інструменти командного рядка GnuPG (необов’язково)\n- Інструменти командного рядка Keybase (необов’язково)\n\n:::note\nЯкщо ваш приватний ключ PGP має парольну фразу, вам буде запропоновано ввести її для будь-яких команд, які підтримують опцію `--sign`.\n:::\n\nСтворення нового чарту виконується так само як і раніше:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nКоли все буде готово до пакування, додайте прапорець `--sign` до `helm package`. Також вкажіть ім'я, за яким відомий ключ підпису, та вʼязку ключів, що містить відповідний приватний ключ:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n:::note\nЗначення аргументу `--key` повинно бути субрядком бажаного `uid` ключа (виведеного командою `gpg --list-keys`), наприклад імʼя або електронна пошта. **Відбиток (fingerprint) _не може_ бути використаний.**\n:::\n\n:::tip\nДля користувачів GnuPG ваша секретна вʼязка ключів знаходиться в `~/.gnupg/secring.gpg`. Ви можете використовувати команду `gpg --list-secret-keys`, щоб переглянути наявні ключі.\n:::\n\n:::warning\nу GnuPG версії 2 ваша секретна вʼязка ключів зберігається у новому форматі `kbx` стандартно у `~/.gnupg/pubring.kbx`. Будь ласка, використовуйте такі команди, щоб перетворити свою вʼязку ключів у старий формат gpg:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n:::\n\nНа цьому етапі ви повинні побачити як `mychart-0.1.0.tgz`, так і `mychart-0.1.0.tgz.prov`. Обидва файли зрештою мають бути завантажені у ваш репозиторій чартів.\n\nВи можете перевірити чарт за допомогою команди `helm verify`:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nПриклад невдалої перевірки:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nЩоб виконати перевірку під час встановлення, використовуйте прапорець `--verify`.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nЯкщо вʼязка ключів, що містить публічний ключ, асоційований із підписаним чартом, не знаходиться в стандартному місці, можливо, вам доведеться вказати шлях до вʼязки ключів за допомогою `--keyring PATH`, як у прикладі з `helm package`.\n\nЯкщо перевірка не вдалася, встановлення буде перервано ще до того, як чарт буде навіть оброблено.\n\n### Використання облікових даних Keybase.io {#using-keybaseio-credentials}\n\nСервіс [Keybase.io](https://keybase.io) дозволяє легко створити ланцюжок довіри для криптографічної ідентифікації. Повноваження Keybase можна використовувати для підписання чартів.\n\nПередумови:\n\n- Налаштований обліковий запис Keybase.io\n- Встановлений локально GnuPG\n- Встановлений локально `keybase` CLI\n\n#### Підписання пакетів {#signing-packages}\n\nПершим кроком є імпорт ваших ключів Keybase у вашу локальну вʼязку ключів GnuPG:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nЦе перетворить ваш ключ Keybase у формат OpenPGP і потім імпортує його локально у файл `~/.gnupg/secring.gpg`.\n\nВи можете перевірити це, виконавши команду `gpg --list-secret-keys`.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nЗверніть увагу, що ваш секретний ключ матиме рядок ідентифікатора:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nЦе повне імʼя вашого ключа.\n\nДалі, ви можете упакувати та підписати чарт за допомогою `helm package`. Переконайтеся, що ви використовуєте хоча б частину цього рядка назви у `--key`.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nЯк результат, команда `package` має створити як файл `.tgz`, так і файл `.tgz.prov`.\n\n#### Перевірка пакетів {#verifying-packages}\n\nВи також можете використовувати аналогічний метод для перевірки чарту, підписаного ключем Keybase іншого користувача. Наприклад, ви хочете перевірити пакет, підписаний `keybase.io/technosophos`. Для цього скористайтесь інструментом `keybase`:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nПерша команда вище відстежує користувача `technosophos`. Далі `keybase pgp pull` завантажує ключі OpenPGP усіх облікових записів, за якими ви стежите, і розміщує їх у вашій вʼязці ключів GnuPG (`~/.gnupg/pubring.gpg`).\n\nНа цьому етапі ви можете використовувати `helm verify` або будь-яку з команд із прапорцем `--verify`:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Причини, через які чарт може не пройти перевірку {#reasons-a-chart-may-not-verify}\n\nЦе поширені причини невдач.\n\n- Файл `.prov` відсутній або пошкоджений. Це вказує на те, що щось налаштовано неправильно або що оригінальний мейнтейнер не створив файл походження.\n- Ключ, використаний для підписання файлу, відсутній у вашій вʼязці ключів. Це вказує на те, що субʼєкт, який підписав чарт, не є тим, кому ви вже довіряєте.\n- Перевірка файлу `.prov` не вдалася. Це означає, що щось не так з чартом або даними про походження.\n- Хеші файлів у файлі походження не збігаються з хешем архівного файлу. Це свідчить про те, що архів було підроблено.\n\nЯкщо перевірка не пройшла, це є підставою для недовіри до пакета.\n\n## Файл походження {#the-provenance-file}\n\nФайл походження містить файл YAML чарту та кілька елементів інформації для перевірки. Файли походження призначені для автоматичного генерування.\n\nДодаються наступні частини даних про походження:\n\n- Файл чарту (`Chart.yaml`) включається для зручного перегляду вмісту чарту як людьми, так і інструментами.\n- Підпис (SHA256, аналогічно до Docker) пакету чарту (файл `.tgz`) включається та може бути використаний для перевірки цілісності пакета чарту.\n- Весь зміст підписується за допомогою алгоритму OpenPGP (див. [Keybase.io](https://keybase.io) для спрощення процесу криптографічного підпису та перевірки).\n\nЦе надає користувачам такі гарантії:\n\n- Пакет не було підроблено (перевірка контрольної суми пакета `.tgz`).\n- Особа, яка випустила цей пакет, є відомою (через підпис GnuPG/PGP).\n\nФормат файлу виглядає приблизно так:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nЗверніть увагу, що розділ YAML містить два документи (розділені `...\\n`). Перший файл — це вміст `Chart.yaml`. Другий — це контрольні суми, map імен файлів та SHA-256 дайджестів вмісту цього файлу на момент пакування.\n\nБлок підпису є стандартним підписом PGP, який забезпечує [стійкість до підробок](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Репозиторії чартів {#chart-repositories}\n\nРепозиторії чартів виконують функцію централізованого сховища чартів Helm.\n\nРепозиторії чартів повинні забезпечувати можливість надання файлів походження через HTTP за певним запитом і повинні робити їх доступними за тим же шляхом URI, що й чарт.\n\nНаприклад, якщо базовий URL для пакета — `https://example.com/charts/mychart-1.2.3.tgz`, файл походження, якщо він існує, ПОВИНЕН бути доступний за адресою `https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nЗ погляду кінцевого користувача, команда `helm install --verify myrepo/mychart-1.2.3` повинна призвести до завантаження як чарту, так і файлу походження без додаткових налаштувань або дій користувача.\n\n### Підписи в OCI-реєстрах {#signatures-in-oci-based-registries}\n\nПід час публікації чартів в [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` можна використовувати для публікації походження в незмінному прозорому лозі.\n\n## Запровадження перевірки повноважень та автентичності{#establishing-authority-and-authenticity}\n\nПри роботі з системами ланцюжків довіри важливо мати можливість встановити повноваження підписувача. Іншими словами, система, описана вище, базується на тому, що ви довіряєте особі, яка підписала чарт. Це, своєю чергою, означає, що ви повинні довіряти відкритому ключу підписувача.\n\nОдним із технічних рішень щодо Helm полягало в тому, що проєкт Helm не буде вставляти себе в ланцюжок довіри як обовʼязкову ланку. Ми не хочемо бути «центром сертифікації» для всіх підписувачів чартів. Натомість ми всіляко підтримуємо децентралізовану модель, що є однією з причин, чому ми обрали OpenPGP нашою базовою технологією. Тому, коли йдеться про встановлення повноважень, ми залишили цей крок більш-менш невизначеним у Helm 2 (рішення, яке було перенесено в Helm 3).\n\nПроте, у нас є кілька порад і рекомендацій для тих, хто зацікавлений у використанні системи перевірки походження:\n\n- Платформа [Keybase](https://keybase.io) надає публічне централізоване сховище для інформації про довіру.\n  - Ви можете використовувати Keybase для зберігання своїх ключів або отримання публічних ключів інших.\n  - Keybase також має чудову документацію.\n  - Хоча ми не тестували це, функція \"захищений вебсайт\" Keybase може бути використана для сервісу чартів Helm.\n  - Основна ідея полягає в тому, що офіційний \"рецензент чартів\" підписує чарти своїм ключем, а отриманий файл походження потім завантажується в репозиторій чартів.\n  - Було проведено деяку роботу стосовно ідеї включення списку дійсних ключів підпису до файлу `index.yaml` репозиторію.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/rbac.md",
    "content": "---\ntitle: Контроль доступу на основі ролей\ndescription: Пояснює, як Helm взаємодіє з контролем доступу на основі ролей Kubernetes.\nsidebar_position: 11\n---\n\nУ Kubernetes надання ролей користувачу або службовому обліковому запису, специфічному для застосунку, є найкращою практикою для забезпечення роботи вашого застосунку в межах, які ви визначили. Дізнайтеся більше про дозволи службових облікових записів [в офіційній документації Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nЗ версії Kubernetes 1.6 контроль доступу на основі ролей (RBAC) стандартно увімкнено. RBAC дозволяє вам визначати, які типи дій дозволені залежно від користувача та його ролі у вашій організації.\n\nЗ RBAC ви можете:\n\n- надавати привілейовані операції (створення ресурсів на рівні кластеру, таких як нові ролі) адміністраторам\n- обмежити можливість користувача створювати ресурси (pods, persistent volumes, deployments) до певних просторів імен або в межах кластера (квоти ресурсів, ролі, визначення власних ресурсів)\n- обмежити можливість користувача переглядати ресурси або в певних просторах імен, або в межах кластера.\n\nЦей посібник призначений для адміністраторів, які хочуть обмежити область доступу користувача до API Kubernetes.\n\n## Управління обліковими записами користувачів {#managing-user-accounts}\n\nУсі кластери Kubernetes мають дві категорії користувачів: службові облікові записи, керовані Kubernetes, та звичайні користувачі.\n\nПередбачається, що управління обліковими записами звичайних користувачів здійснюється зовнішньою незалежною службою. Це може бути адміністратор, який розподіляє приватні ключі, сховище користувачів, таке як Keystone або Google Accounts, або навіть файл зі списком імен користувачів та паролів. Стосовно цього, Kubernetes не має обʼєктів, які представляють облікові записи звичайних користувачів. Звичайних користувачів не можна додати до кластера за допомогою виклику API.\n\nНа відміну від цього, службові облікові записи є користувачами, керованими API Kubernetes. Вони привʼязані до певних просторів імен і створюються автоматично API сервером або вручну через API-запити. Службові облікові записи привʼязані до набору облікових даних, які зберігаються як Secrets і монтуються в podʼи, що дозволяє процесам всередині кластера спілкуватися з API Kubernetes.\n\nЗапити API привʼязані або до звичайного користувача, або до службового облікового запису, або розглядаються як анонімні запити. Це означає, що кожен процес усередині або поза кластером, від користувача, який вводить `kubectl` на робочій станції, до kubelets на вузлах, до членів панелі управління, повинен пройти автентифікацію під час надсилання запитів до сервера API, або розглядатися як анонімний користувач.\n\n## Roles, ClusterRoles, RoleBindings та ClusterRoleBindings {#roles-clusterroles-rolebindings-and-clusterrolebindings}\n\nУ Kubernetes облікові записи користувачів і службові облікові записи можуть переглядати та редагувати лише ресурси, до яких їм надано доступ. Цей доступ надається за допомогою Roles і RoleBindings. Ролі та RoleBindings привʼязані до певного простору імен, надаючи користувачам можливість переглядати та/або редагувати ресурси в цьому просторі імен, до яких надає доступ Role.\n\nНа рівні кластера вони називаються ClusterRoles і ClusterRoleBindings. Надання користувачеві ClusterRole надає йому доступ до перегляду та/або редагування ресурсів у всьому кластері. Це також необхідно для перегляду та/або редагування ресурсів на рівні кластера (простори імен, квоти ресурсів, вузли).\n\nClusterRoles можна привʼязати до певного простору імен через посилання в RoleBinding. `admin`, `edit` та `view` стандартні ClusterRoles часто використовуються таким чином.\n\nОсь кілька ClusterRoles, стандартно доступних у Kubernetes. Вони призначені для користувачів. До них відносяться суперкористувацькі ролі (`cluster-admin`) та ролі з більш детальним доступом (`admin`, `edit`, `view`).\n\n| Стандартна ClusterRole | Стандартна ClusterRoleBinding | Опис\n|------------------------|-------------------------------|-------------\n| `cluster-admin`        | Група `system:masters`.       | Дозволяє суперкористувачеві виконувати будь-які дії з будь-яким ресурсом. При використанні в ClusterRoleBinding надає повний контроль над усіма ресурсами в кластері та в усіх просторах імен. При використанні в RoleBinding надає повний контроль над усіма ресурсами в просторі імен rolebinding, включаючи сам простір імен.\n| `admin`                | Немає                         | Дозволяє доступ адміністратора, який має бути наданий в межах простору імен за допомогою RoleBinding. Якщо використовується в RoleBinding, дозволяє доступ для читання/запису до більшості ресурсів в просторі імен, включаючи можливість створювати ролі та rolebindings в просторі імен. Не дозволяє доступ для запису до квоти ресурсів або до самого простору імен.\n| `edit`                 | Немає                         | Дозволяє читати/записувати більшість обʼєктів в просторі імен. Не дозволяє переглядати або змінювати ролі чи привʼязки ролей.\n| `view`                 | Немає                         | Дозволяє доступ тільки для читання, щоб бачити більшість обʼєктів в просторі імен. Не дозволяє переглядати ролі або привʼязки ролей. Не дозволяє переглядати секрети, оскільки останні мають підвищений рівень доступу.\n\n## Обмеження доступу облікових записів користувачів за допомогою RBAC {#restricting-a-user-accounts-access-using-rbac}\n\nТепер, коли ми розуміємо основи контролю доступу на основі ролей, розглянемо, як адміністратор може обмежити область доступу користувача.\n\n### Приклад: Надання користувачеві доступу для читання/запису в певному просторі імен {#example-grant-a-user-readwrite-access-to-a-particular-namespace}\n\nЩоб обмежити доступ користувача до певного простору імен, можна використовувати роль `edit` або `admin`. Якщо ваші чарти створюють або взаємодіють з Roles і RoleBindings, ви захочете використовувати ClusterRole `admin`.\n\nКрім того, ви також можете створити RoleBinding з доступом `cluster-admin`. Надаючи користувачу доступ `cluster-admin` на рівні простору імен, ви надаєте повний контроль над кожним ресурсом у просторі імен, включаючи сам простір імен.\n\nДля цього прикладу ми створимо користувача з роллю `edit`. Спочатку створіть простір імен:\n\n```shell\n$ kubectl create namespace foo\n```\n\nТепер створіть RoleBinding у цьому просторі імен, надаючи користувачу роль `edit`.\n\n```shell\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Приклад: Надання користувачу доступу для читання/запису на рівні кластера {#example-grant-a-user-readwrite-access-at-the-cluster-scope}\n\nЯкщо користувач хоче встановити чарт, який встановлює ресурси на рівні кластера (простори імен, ролі, визначення власних ресурсів тощо), їм знадобиться доступ для запису на рівні кластера.\n\nДля цього надайте користувачу доступ `admin` або `cluster-admin`.\n\nНадання користувачу доступу `cluster-admin` надає їм доступ до всіх ресурсів Kubernetes, включаючи доступ до вузлів з `kubectl drain` та інших адміністративних завдань. Рекомендується розглянути можливість надання користувачу доступу `admin`, або створити власну ClusterRole, адаптовану до їхніх потреб.\n\n```shell\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Приклад: Надання користувачу доступу лише для читання до певного простору імен {#example-grant-a-user-read-only-access-to-a-particular-namespace}\n\nВи, мабуть, помітили, що для перегляду секретів немає ClusterRole. ClusterRole `view` не надає користувачеві права доступу до Secrets через ризик підвищення привілеїв. Helm стандартно зберігає метадані релізів як Secrets.\n\nЩоб користувач міг виконати команду `helm list`, їм потрібно мати можливість читати ці секрети. Для цього ми створимо спеціальний ClusterRole `secret-reader`.\n\nСтворіть файл `cluster-role-secret-reader.yaml` і додайте до нього такий вміст:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nПотім створіть ClusterRole за допомогою:\n\n```shell\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nЯк тільки це буде зроблено, ми можемо надати користувачу доступ для читання до більшості ресурсів, а потім надати їм доступ до секретів:\n\n```shell\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Приклад: Надання користувачу доступу лише для читання на рівні кластера {#example-grant-a-user-read-only-access-at-the-cluster-scope}\n\nВ деяких випадках може бути корисно надати користувачу доступ на рівні кластера. Наприклад, якщо користувач хоче виконати команду `helm list --all-namespaces`, API вимагає, щоб користувач мав доступ для читання на рівні кластера.\n\nДля цього надайте користувачу як `view`, так і `secret-reader` доступ, як описано вище, але за допомогою ClusterRoleBinding..\n\n```shell\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Додатково {#additional-thoughts}\n\nВищезазначені приклади використовують стандартні ClusterRoles, надані Kubernetes. Для більш детального контролю за ресурсами, до яких користувачі мають доступ, ознайомтеся з [документацією Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) по створенню власних Roles і ClusterRoles.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/registries.mdx",
    "content": "---\ntitle: Використання OCI-реєстрів\ndescription: Як використовувати OCI для розповсюдження чартів.\nsidebar_position: 7\n---\n\nimport Helm4 from \"../_v4-in-progress.mdx\"\n\n<Helm4/>\n\nРекомендується використовувати реєстри контейнерів з підтримкою [OCI](https://www.opencontainers.org/) для зберігання та обміну пакетами чартів.\n\n\n## Використання OCI-реєстрів {#using-an-oci-based-registry}\n\n### Репозиторії Helm в OCI-реєстрах {#helm-repositories-in-oci-based-registries}\n\n[Репозиторій Helm](/topics/chart_repository.md) — це спосіб зберігання та розповсюдження пакетів чартів Helm. OCI-реєстр може містити нуль або більше репозиторіїв Helm, а кожен з цих репозиторіїв може містити нуль або більше пакетів чартів Helm.\n\n### Використання послуг реєстрів {#use-hosted-registries}\n\nІснує кілька реєстрів контейнерів з підтримкою OCI, які ви можете використовувати для ваших чартів Helm. Наприклад:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n\nЩоб створити та налаштувати реєстр з підтримкою OCI, дотримуйтесь документації постачальника реєстру контейнерів на хостингу.\n\n:::note\nВи можете використовувати [Docker Registry](https://docs.docker.com/registry/deploying/) або [`zot`](https://github.com/project-zot/zot), які є реєстрами з підтримкою OCI, на вашому компʼютері для розробки. Запуск реєстру з підтримкою OCI на вашому компʼютері, де відбувається розробка, слід використовувати лише для тестування.\n:::\n\n### Використання sigstore для підписування чартів з підтримкою OCI{#using-sigstore-to-sign-oci-based-charts}\n\nВтулок [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) дозволяє використовувати [Sigstore](https://sigstore.dev/) для підписування чартів Helm тими ж інструментами, що й для підписування образів контейнерів.  Це є альтернативою [перевірки походження на основі GPG](/topics/provenance.mdx), що підтримуються класичними [репозиторіями чартів](/topics/chart_repository.md).\n\nДетальнішу інформацію про використання втулка `helm sigstore` дивіться в [документації проєкту Sigstore](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md).\n\n## Команди для роботи з реєстрами {#commands-for-working-with-registries}\n\n### Команда `registry` {#the-registry-subcommand}\n\n#### `login`\n\nВхід до реєстру (зручний варіант з ручним введенням пароля)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nВихід з реєстру\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### Команда `push` {#the-push-subcommand}\n\nЗавантажити чарт до реєстру на основі OCI:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nКоманда `push` може використовуватися тільки для `.tgz` файлів, створених заздалегідь за допомогою `helm package`.\n\nПри використанні `helm push` для завантаження чарту до реєстру OCI, посилання має починатися з `oci://` і не повинно містити базове імʼя або теґ.\n\nБазове імʼя посилання на реєстр визначається з імені чарту, а теґ визначається з семантичної версії чарту. Це наразі є строгими вимогами.\n\nДеякі реєстри вимагають, щоб репозиторій та/або простір імен (якщо вказано) були створені заздалегідь. В іншому випадку під час операції `helm push` буде згенеровано помилку.\n\nЯкщо ви створили [файл походження](/topics/provenance.mdx) (`.prov`) і він знаходиться поруч із файлом чарту `.tgz`, він буде автоматично завантажений до реєстру при виконанні команди `push`. Це призведе до створення додаткового шару в [маніфесті чарту Helm](#helm-chart-manifest).\n\nКористувачі втулка [helm-push](https://github.com/chartmuseum/helm-push) (для завантаження чартів до [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) можуть зіткнутися з проблемами, оскільки втулок конфліктує з новою вбудованою функцією `push`. Починаючи з версії v0.10.0, втулок було перейменовано на `cm-push`.\n\n### Інші команди {#other-subcommands}\n\nПідтримка протоколу `oci://` також доступна в різних інших командах. Ось повний список:\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nБазова назва (назва чарту) посилання реєстру *включається* для будь-якого типу дії, повʼязаної із завантаженням чарту (на відміну від `helm push`, де вона не вказується).\n\nОсь декілька прикладів використання перерахованих вище команд для чартів з підтримкою OCI:\n\n```shell\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Вказання залежностей {#specifying-dependencies}\n\nЗалежності чарту можна витягнути з реєстру за допомогою команди `dependency update`.\n\nПоле `repository` для певного запису в `Chart.yaml` вказується як посилання на реєстр без базового імені:\n\n```yaml\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\n\nЦе завантажить `oci://localhost:5000/myrepo/mychart:2.7.0`, коли виконується `dependency update`.\n\n## Маніфест Helm чарту {#helm-chart-manifest}\n\nПриклад маніфесту Helm чарту, представленого в реєстрі (зверніть увагу на поля `mediaType`):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nНаступний приклад містить [файл походження](/topics/provenance.mdx) (зверніть увагу на додатковий шар):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Міграція з репозиторіїв чартів {#migrating-from-chart-repos}\n\nМіграція з класичних [репозиторіїв чартів](/topics/chart_repository.md) (репозиторіїв на основі index.yaml) є простим процесом: використовуйте `helm pull`, а потім `helm push`, щоб завантажити отримані файли `.tgz` до реєстру.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current/topics/version_skew.mdx",
    "content": "---\ntitle: Політика підтримки версій Helm\ndescription: Описує політику випуску патчів Helm, а також максимальну підтримувану різницю версій між Helm і Kubernetes.\n---\n\nЦей документ описує максимальну підтримувану різницю версій між Helm і Kubernetes.\n\n## Підтримувані версії {#supported-versions}\n\nВерсії Helm виражаються у форматі `x.y.z`, де `x` — це основна версія, `y` — це мінорна версія, а `z` — це версія патчу, відповідно до [семантичного версіювання](https://semver.org/lang/uk/spec/v2.0.0.html).\n\nПроєкт Helm підтримує релізну гілку для останнього мінорного випуску. Застосовні виправлення, включаючи виправлення безпеки, додаються в релізну гілку залежно від їх серйозності та можливості впровадження. Більше деталей можна знайти в [політиці випусків Helm](/community/release_policy).\n\n## Підтримувана різниця версій {#supported-version-skew}\n\nКоли виходить нова версія Helm, вона компілюється для конкретної мінорної версії Kubernetes. Наприклад, Helm v4.0.0 взаємодіє з Kubernetes за допомогою клієнта Kubernetes 1.34.1, тому він сумісний з Kubernetes 1.34.\n\nПочинаючи з Helm 4, Helm вважається сумісним з версіями Kubernetes `n-3`, для яких він був скомпільований.\n\nНаприклад, якщо ви використовуєте версію Helm 4, яка була скомпільована для клієнтських API Kubernetes v1.35, то її можна безпечно використовувати з Kubernetes v1.35, v1.34, v1.33 та v1.32.\n\nНе рекомендується використовувати Helm з версією Kubernetes, яка є новішою за версію, для якої він був скомпільований, оскільки Helm не дає жодних гарантій сумісності з майбутніми версіями.\n\nЯкщо ви вирішили використовувати Helm з версією Kubernetes, яку він не підтримує, ви використовуєте його на власний ризик.\n\nБудь ласка, зверніться до таблиці нижче, щоб визначити, яка версія Helm сумісна з вашим кластером.\n\n| Версія Helm | Підтримувані версії Kubernetes |\n|--------------|-------------------------------|\n| 4.0.x        | 1.34.x - 1.31.x               |\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"Використання Helm\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Команди Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"Чарти\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"Розробка шаблонів\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Найкращі практики\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: Загальні домовленості\ndescription: Загальні домовленості для чартів.\nsidebar_position: 1\n---\n\nЦя частина Посібника з найкращих практик пояснює загальні домовленості.\n\n## Назви чартів {#chart-names}\n\nНазви чартів повинні складатися з літер нижнього регістру та цифр. Слова _можуть_ бути розділені дефісами (-):\n\nПриклади:\n\n```none\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nУ назвах чартів не можна використовувати великі літери та підкреслення. Також не слід використовувати крапки.\n\n## Номери версій {#version-numbers}\n\nПо можливості, Helm використовує [SemVer 2](https://semver.org) для позначення номерів версій. (Зверніть увагу, що теґи Docker-образів не завжди відповідають SemVer і тому вважаються невдалим винятком з правила.)\n\nКоли версії SemVer зберігаються в мітках Kubernetes, ми умовно змінюємо символ `+` на `_`, оскільки мітки не допускають використання знака `+` як значення.\n\n## Форматування YAML {#formatting-yaml}\n\nФайли YAML повинні використовувати відступи у _два пробіли_ (і ніколи табуляцією).\n\n## Використання слів Helm і Chart {#usage-of-the-words-helm-and-chart}\n\nІснує кілька конвенцій щодо використання слів _Helm_ і _helm_.\n\n- _Helm_ відноситься до проєкту в цілому\n- `helm` відноситься до клієнтської команди\n- Термін `chart` не потрібно писати з великої літери, оскільки це не власна назва\n- Однак `Chart.yaml` необхідно писати з великої літери, оскільки назва файлу чутлива до регістру\n\nУ разі сумніву використовуйте _Helm_ (з великої літери \"H\").\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Custom Resource Definitions\ndescription: Як створювати та використовувати CRD (Custom Resource Definitions).\nsidebar_position: 7\n---\n\nЦей розділ посібника з найкращих практик розглядає створення та використання обʼєктів Custom Resource Definition (CRD).\n\nПри роботі з CRD важливо розрізняти два різні аспекти:\n\n- Існує декларація CRD. Це YAML файл, який має `kind: CustomResourceDefinition`.\n- Потім є ресурси, які _використовують_ CRD. Наприклад, якщо CRD визначає `foo.example.com/v1`, будь-який ресурс, який має `apiVersion: example.com/v1` і `kind: Foo`, є ресурсом, що використовує цей CRD.\n\n## Встановлення декларації CRD перед використанням ресурсу {#install-a-crd-declaration-before-using-the-resource}\n\nHelm оптимізований для швидкого завантаження якомога більшої кількості ресурсів у Kubernetes. За дизайном Kubernetes може обробити цілий набір маніфестів і активувати їх усі (це називається циклом узгодження).\n\nАле є різниця з CRD.\n\nДля CRD декларація повинна бути зареєстрована до того, як будь-які ресурси цього типу CRD можуть бути використані. Процес реєстрації іноді займає кілька секунд.\n\n### Метод 1: Нехай `helm` зробить це за вас {#method-1-let-helm-do-it-for-you}\n\nЗ приходом Helm 3 ми видалили старі `crd-install` хуки на користь простішої методології. Тепер існує спеціальна тека `crds`, яку ви можете створити у вашому чарті для зберігання CRD. Ці CRD не підлягають шаблонізації, але будуть стандартно встановлені під час виконання `helm install` для чарту. Якщо CRD вже існує, його буде пропущена з попередженням. Якщо ви бажаєте пропустити крок встановлення CRD, ви можете використовувати прапорець `--skip-crds`.\n\n#### Декілька застережень (і пояснень) {#some-caveats-and-explanations}\n\nЗараз не підтримується оновлення або видалення CRD за допомогою Helm. Це було зроблено після тривалого обговорення у спільноті через небезпеку випадкової втрати даних. Крім того, наразі немає консенсусу в спільноті щодо того, як управляти CRD та їх життєвим циклом. Як це буде розвиватися, Helm додасть підтримку для цих випадків.\n\nПрапорець `--dry-run` для `helm install` і `helm upgrade` наразі не підтримується для CRD. Мета \"Dry Run\" полягає в перевірці того, що вивід чарту дійсно працюватиме, якщо буде надіслано на сервер. Але CRD є модифікацією поведінки сервера. Helm не може встановити CRD під час сухого запуску, тому клієнт виявлення не дізнається про цей Custom Resource (CR), і перевірка не пройде. Ви можете перемістити CRD до окремого чарту або використовувати `helm template` замість цього.\n\nЩе один важливий момент, який слід врахувати в обговоренні підтримки CRD, — це те, як обробляється рендеринг шаблонів. Одним з відмінних недоліків методу `crd-install`, що використовувався в Helm 2, була неспроможність правильно перевіряти чарти через зміну доступності API (CRD фактично додає ще один доступний API до вашого кластера Kubernetes). Якщо чарт встановлював CRD, `helm` більше не мав дійсного набору версій API, з якими можна було працювати. Це також є причиною видалення підтримки шаблонізації для CRD. З новим методом `crds` для встановлення CRD ми тепер забезпечуємо, що `helm` має абсолютно достовірну інформацію про поточний стан кластера.\n\n### Метод 2: Окремі чарти {#method-2-separate-charts}\n\nЩе один спосіб зробити це — помістити визначення CRD в один чарт, а потім розмістити будь-які ресурси, які використовують цей CRD, в _іншому_ чарті.\n\nВ цьому методі кожен чарт потрібно встановлювати окремо. Однак цей робочий процес може бути більш корисним для адміністраторів кластерів, які мають права адміністратора на кластер.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: Залежності\ndescription: Охоплює найкращі практики для залежностей Charts.\nsidebar_position: 4\n---\n\nЦей розділ посібника охоплює найкращі практики для `залежностей`, оголошених у `Chart.yaml`.\n\n## Версії {#versions}\n\nПо можливості використовуйте діапазони версій замість привʼязки до точної версії. Рекомендоване стандартне значення — це використання відповідності на рівні патчу:\n\n```yaml\nversion: ~1.2.3\n```\n\nЦе буде відповідати версії `1.2.3` та будь-яким патчам для цього випуску. Іншими словами, `~1.2.3` є еквівалентом `>= 1.2.3, < 1.3.0`.\n\nДля повної синтаксичної відповідності версій див. [документацію semver](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Попередні версії {#prereleases-versions}\n\nВищезгадані обмеження версій не будуть відповідати попереднім версіям. Наприклад, `version: ~1.2.3` буде відповідати `version: ~1.2.4`, але не `version: ~1.2.3-1`. Наступне забезпечує відповідність як попередніх версій, так і на рівні патчу:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### URL-адреси репозиторіїв {#repository-urls}\n\nПо можливості використовуйте URL-адреси репозиторіїв `https://`, далі `http://`.\n\nЯкщо репозиторій був доданий до файлу індексу репозиторіїв, імʼя репозиторію може бути використане як псевдонім URL. Використовуйте `alias:` або `@`, за яким слідують імена репозиторіїв.\n\nURL-адреси файлів (`file://...`) вважаються \"особливим випадком\" для чартів, які збираються фіксованим процесом розгортання.\n\nПри використанні [втулків завантажувача](/topics/plugins.md#downloader-plugins) схема URL буде специфічною для втулка. Зверніть увагу, що користувачеві чарту буде потрібно мати втулок, що підтримує схему, встановлений для оновлення або побудови залежності.\n\nHelm не може виконувати операції управління залежностями для залежності, коли поле `repository` залишено порожнім. У цьому випадку Helm припускатиме, що залежність знаходиться в підтеці теки `charts` з іменем, яке відповідає властивості `name` для залежності.\n\n## Умови та теґи {#conditions-and-tags}\n\nУмови або теґи слід додавати до будь-яких залежностей, які _є необовʼязковими_.\n\nБажана форма умови є такою:\n\n```yaml\ncondition: somechart.enabled\n```\n\nДе `somechart` є іменем чарту залежності.\n\nКоли кілька субчартів (залежностей) разом забезпечують необовʼязкову або замінну функцію, ці чарт можуть мати спільні теґи.\n\nНаприклад, якщо як `nginx`, так і `memcached` разом забезпечують оптимізації продуктивності для основного застосунку в чарті та вони потрібні, щоб обидва були присутні, коли ця функція увімкнена, то вони повинні мати розділ теґів як цей:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nЦе дозволяє користувачеві вмикати або вимикати цю функцію за допомогою одного теґу.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx",
    "content": "---\ntitle: Найкращі практики\nsidebar: true\nsidebar_position: 4\n---\n\n# Посібник з найкращих практик створення чартів\n\nЦей посібник охоплює найкращі практики, рекомендовані командою Helm, для створення чартів. Основна увага приділяється тому, як повинні бути структуровані чарти.\n\nМи зосереджуємось головним чином на найкращих практиках для чартів, які можуть бути опубліковані публічно. Ми розуміємо, що багато чартів використовуються виключно для внутрішніх потреб, і автори таких чартів можуть вважати, що їхні внутрішні інтереси переважають наші рекомендації тут.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: Мітки та Анотації\ndescription: Охоплює найкращі практики використання міток та анотацій у вашому Chart.\nsidebar_position: 5\n---\n\nЦей розділ посібника з найкращих практик обговорює найкращі практики для використання міток та анотацій у вашому чарті.\n\n## Це мітка чи анотація? {#is-it-a-label-or-an-annotation}\n\nЕлемент метаданих слід вважати міткою за таких умов:\n\n- Він використовується Kubernetes для ідентифікації цього ресурсу\n- Він корисний для експонування операторам з метою запиту системи.\n\nНаприклад, рекомендується використовувати `helm.sh/chart: NAME-VERSION` як мітку, щоб оператори могли зручно знаходити всі екземпляри конкретного чарту.\n\nЯкщо елемент метаданих не використовується для запитів, його слід встановити як анотацію.\n\nHelm hooks завжди є анотаціями.\n\n## Стандартні Мітки {#standard-labels}\n\nНаступна таблиця визначає загальні мітки, які використовуються в Helm чарті. Helm сам по собі ніколи не вимагає наявності конкретної мітки. Мітки, які позначені як REC, є рекомендованими та _повинні_ бути розміщені в чарті для глобальної узгодженості. Ті, що позначені як OPT, є необовʼязковими. Це ідіоматичні або часто використовувані мітки, але не є критично важливими для операційних цілей.\n\n| Назва | Статус | Опис |\n|-------|--------|------|\n| `app.kubernetes.io/name` | REC | Це повинно бути імʼя застосунку, яке відображає весь застосунок. Зазвичай використовується `{{ template \"name\" . }}`. Це використовується багатьма маніфестами Kubernetes і не є специфічним для Helm. |\n| `helm.sh/chart` | REC | Це повинно бути імʼя чарту та версія: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`. |\n| `app.kubernetes.io/managed-by` | REC | Це завжди повинно бути встановлено як `{{ .Release.Service }}`. Це для знаходження всього, що управляється Helm. |\n| `app.kubernetes.io/instance` | REC | Це повинно бути `{{ .Release.Name }}`. Це допомагає відрізняти різні екземпляри одного й того ж застосунку. |\n| `app.kubernetes.io/version` | OPT | Версія застосунку і може бути встановлена як `{{ .Chart.AppVersion }}`. |\n| `app.kubernetes.io/component` | OPT | Це загальна мітка для позначення різних ролей, які елементи можуть відігравати в застосунку. Наприклад, `app.kubernetes.io/component: frontend`. |\n| `app.kubernetes.io/part-of` | OPT | Коли кілька чартів або програмних частин використовуються разом для створення одного застосунку. Наприклад, програмне забезпечення та база даних для створення вебсайту. Це можна встановити на рівні основного застосунку, що підтримується. |\n\nВи можете знайти більше інформації про мітки Kubernetes, що починаються з `app.kubernetes.io`, в [документації Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pods та PodTemplates\ndescription: Обговорює форматування частин Pod та PodTemplate у маніфестах Chart.\nsidebar_position: 6\n---\n\nЦей розділ посібника з найкращих практик обговорює форматування частин Pod та PodTemplate у маніфестах чарту.\n\nНаступний (неповний) список ресурсів використовує PodTemplates:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Образи {#images}\n\nОбрази контейнера повинні використовувати фіксовану мітку або SHA образу. Не слід використовувати мітки `latest`, `head`, `canary` або інші мітки, які призначені для \"плаваючих\" версій.\n\nОбрази _можуть_ бути визначені у файлі `values.yaml`, щоб спростити заміну образів.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nОбрази та мітка _можуть_ бути визначені в `values.yaml` як два окремих поля:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` стандартно встановлює `imagePullPolicy` на `IfNotPresent`, роблячи це у вашому `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nА у `values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nАналогічно, Kubernetes стандартно встановлює `imagePullPolicy` на `IfNotPresent`, якщо він зовсім не визначений. Якщо вам потрібне інше значення, просто оновіть його в `values.yaml` на потрібне значення.\n\n## PodTemplates повинні оголошувати селектори\n\nУсі секції PodTemplate повинні вказувати селектор. Наприклад:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nЦе гарна практика, оскільки вона робить відносини між набором і pod чіткішими.\n\nАле це ще важливіше для таких наборів, як Deployment. Без цього, _весь_ набір міток використовується для вибору відповідних pod, і це може зламатися, якщо ви використовуєте мітки, які змінюються, такі як версія або дата релізу.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: Role-Based Access Control\ndescription: Обговорює створення та форматування RBAC ресурсів у маніфестах чарта.\nsidebar_position: 8\n---\n\nЦей розділ посібника з найкращих практик розглядає створення та форматування ресурсів RBAC у маніфестах чарту.\n\nРесурси RBAC це:\n\n- ServiceAccount (обмежений простором імен)\n- Role (обмежений простором імен)\n- ClusterRole\n- RoleBinding (обмежений простором імен)\n- ClusterRoleBinding\n\n## Конфігурація YAML {#yaml-configuration}\n\nКонфігурація RBAC та ServiceAccount повинна здійснюватися під окремими ключами. Це окремі речі. Розділення цих двох концепцій у YAML знімає неоднозначність і робить це ясніше.\n\n```yaml\nrbac:\n  # Вказує, чи повинні бути створені ресурси RBAC\n  create: true\n\nserviceAccount:\n  # Вказує, чи повинен бути створений ServiceAccount\n  create: true\n  # Імʼя ServiceAccount для використання.\n  # Якщо не вказано і create дорівнює true, імʼя генерується за допомогою шаблону fullname\n  name:\n```\n\nЦю структуру можна розширити для складніших чартів, які потребують кількох ServiceAccount.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## Ресурси RBAC повинні бути стандартно створені {#rbac-resources-should-be-created-by-default}\n\n`rbac.create` має бути булевим значенням, яке контролює, чи створюються ресурси RBAC. Стандартне значення має бути `true`. Користувачі, які бажають самостійно управляти контролем доступу RBAC, можуть встановити це значення в `false` (у цьому випадку дивіться нижче).\n\n## Використання ресурсів RBAC {#using-rbac-resources}\n\n`serviceAccount.name` має бути встановлено на імʼя ServiceAccount, яке буде використовуватися доступними ресурсами, створеними чартом. Якщо `serviceAccount.create` дорівнює true, то ServiceAccount з цим імʼям має бути створено. Якщо імʼя не вказано, то імʼя генерується за допомогою шаблону `fullname`. Якщо `serviceAccount.create` дорівнює false, то ServiceAccount не створюється, але він має бути асоційований з тими ж ресурсами, щоб пізніше створені вручну ресурси RBAC, що посилаються на нього, функціонували правильно. Якщо `serviceAccount.create` дорівнює false та імʼя не вказано, то використовується стандартний ServiceAccount.\n\nДля ServiceAccount слід використовувати наступний допоміжний шаблон.\n\n```yaml\n{{/*\nСтворіть імʼя ServiceAccount для використання\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: Шаблони\ndescription: Ближче ознайомлення з найкращими практиками щодо шаблонів.\nsidebar_position: 3\n---\n\nЦя частина посібника з найкращих практик фокусується на шаблонах.\n\n## Структура `templates/` {#structure-of-templates}\n\nТеку `templates/` слід структурувати наступним чином:\n\n- Файли шаблонів повинні мати розширення `.yaml`, якщо вони генерують YAML-вихід. Розширення `.tpl` можна використовувати для файлів шаблонів, які не генерують форматований контент.\n- Імена файлів шаблонів повинні використовувати дефіси (`my-example-configmap.yaml`), а не camelCase.\n- Кожне визначення ресурсу повинно бути у власному файлі шаблону.\n- Імена файлів шаблонів повинні відображати тип ресурсу в імені. Наприклад, `foo-pod.yaml`, `bar-svc.yaml`.\n\n## Імена визначених шаблонів {#names-of-defined-templates}\n\nВизначені шаблони (шаблони, створені всередині директиви `{{ define }}`) є глобально доступними. Це означає, що чарт і всі його субчарти матимуть доступ до всіх шаблонів, створених з `{{ define }}`.\n\nЗ цієї причини _усі імена визначених шаблонів повинні бути просторово іменовані_.\n\nПравильно:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nНеправильно:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\n\nРекомендується, щоб нові чарти створювалися за допомогою команди `helm create`, оскільки імена шаблонів автоматично визначаються відповідно до цієї найкращої практики.\n\n## Форматування шаблонів {#formatting-templates}\n\nШаблони повинні мати відступи у _два пробіли_ (ніколи не табуляцією).\n\nДирективи шаблону повинні мати пробіл після відкриваючих дужок і перед закриваючими дужками:\n\nПравильно:\n\n```go\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nНеправильно:\n\n```go\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nШаблони повинні обрізати пробіли, де це можливо:\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nБлоки (такі як контрольні структури) можуть мати відступи для вказівки потоку коду шаблону.\n\n```go\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nОднак, оскільки YAML є мовою, орієнтованою на пробіли, часто неможливо, щоб відступи коду слідували цій конвенції.\n\n## Пробіли у згенерованих шаблонах {#whitespace-in-generated-templates}\n\nБажано мінімізувати кількість пробілів у згенерованих шаблонах. Особливо слід уникати численних порожніх рядків, які йдуть один за одним. Але випадкові порожні рядки (особливо між логічними секціями) допустимі.\n\nЦе краще:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nЦе прийнятно:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nАле це слід уникати:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Коментарі (Коментарі YAML vs. Коментарі шаблонів) {#comments-yaml-comments-vs-template-comments}\n\nЯк YAML, так і шаблони Helm мають маркери коментарів.\n\nКоментарі YAML:\n\n```yaml\n# Це коментар\ntype: sprocket\n```\n\nКоментарі шаблонів:\n\n```yaml\n{{- /*\nЦе коментар.\n*/}}\ntype: frobnitz\n```\n\nКоментарі шаблонів слід використовувати для документування функцій шаблону, наприклад, пояснюючи визначений шаблон:\n\n```yaml\n{{- /*\nmychart.shortname надає скорочену версію імені релізу до 6 символів.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nВсередині шаблонів коментарі YAML можуть використовуватися, коли це корисно для користувачів Helm (можливо) бачити коментарі під час налагодження.\n\n```yaml\n# Це може спричинити проблеми, якщо значення більше ніж 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nВищенаведений коментар видимий, коли користувач виконує `helm install --debug`, тоді як коментарі, вказані в секціях `{{- /* */}}`, не видно.\n\nОстерігайтеся додавання `#` коментарів YAML у секції шаблону, що містять значення Helm, які можуть бути потрібні для деяких функцій шаблону.\n\nНаприклад, якщо функція `required` вводиться у наведеному вище прикладі, і `maxMem` не встановлено, коментар `#` YAML спричинить помилку рендерингу.\n\nПравильно: `helm template` не рендерить цей блок\n\n```yaml\n{{- /*\n# Це може спричинити проблеми, якщо значення більше ніж 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nНеправильно: `helm template` повертає `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n\n```yaml\n# Це може спричинити проблеми, якщо значення більше ніж 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nОгляньте [Налагодження шаблонів](/chart_template_guide/debugging.md) для іншого прикладу цієї поведінки того, як коментарі YAML залишаються недоторканими.\n\n## Використання JSON у шаблонах і виході шаблонів {#use-of-json-in-templates-and-template-output}\n\nYAML є надмножиною JSON. У деяких випадках використання синтаксису JSON може бути більш читабельним, ніж інші представлення YAML.\n\nНаприклад, цей YAML ближчий до звичайного методу представлення списків у YAML:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nАле його легше читати, коли його стисло представлено у стилі списку JSON:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nВикористання JSON для підвищення читабельності є корисним. Однак синтаксис JSON не слід використовувати для представлення cкладніших конструкцій.\n\nПри роботі з чистим JSON, вбудованим всередині YAML (наприклад, конфігурація контейнера ініціалізації), звичайно, доречно використовувати формат JSON.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: Значення\ndescription: Орієнтовано на те, як ви повинні структурувати та використовувати значення.\nsidebar_position: 2\n---\n\nЦя частина посібника з найкращих практик охоплює використання значень. Ми надаємо рекомендації щодо структурування та використання значень, зосереджуючись на дизайні файлу `values.yaml` чарту.\n\n## Домовленості щодо назв {#naming-conventions}\n\nНазви змінних повинні починатися з малої літери, а слова мають розділятися верблюжим регістром (camelCase):\n\nПравильно:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nНеправильно:\n\n```yaml\nChicken: true  # початкова велика літера може конфліктувати з вбудованими змінними\nchicken-noodle-soup: true # не використовуйте дефіси в назвах\n```\n\nЗверніть увагу, що всі вбудовані змінні Helm починаються з великої літери, щоб їх легко було відрізнити від користувацьких значень: `.Release.Name`, `.Capabilities.KubeVersion`.\n\n## Пласкі або вкладені значення {#flat-or-nested-values}\n\nYAML — це гнучкий формат, і значення можуть бути вкладеними або пласкими.\n\nВкладені:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nПласкі:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nУ більшості випадків слід віддавати перевагу пласким структурам над вкладеними. Це зумовлено тим, що їх простіше використовувати розробникам шаблонів та користувачам.\n\nДля забезпечення максимальної безпеки вкладене значення має перевірятися на кожному рівні:\n\n```go\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nДля кожного шару вкладення необхідно виконувати перевірку на наявність. Однак для пласкої конфігурації такі перевірки можна пропустити, що спрощує читання та використання шаблону.\n\n```go\n{{ default \"none\" .Values.serverName }}\n```\n\nКоли існує велика кількість пов’язаних змінних і хоча б одна з них є обов’язковою, вкладені значення можуть використовуватися для підвищення зручності читання.\n\n## Чітке визначення типів {#make-types-clear}\n\nПравила перетворення типів YAML іноді можуть бути неінтуїтивними. Наприклад, `foo: false` не те саме, що і `foo: \"false\"`. Великі цілі числа, такі як `foo: 12345678`, у деяких випадках будуть перетворюватися на наукову нотацію.\n\nНайпростіший спосіб уникнути помилок перетворення типів — бути явним щодо рядків і неявним щодо всього іншого. Або, коротко кажучи, _беріть всі рядки в лапки_.\n\nЧасто для уникнення проблем із перетворенням чисел наукової нотації вигідно зберігати ваші цілі числа у вигляді рядків і використовувати `{{ int $value }}` у шаблоні для перетворення з рядкового значення назад на ціле число.\n\nУ більшості випадків явні типи поважаються, тому `foo: !!string 1234` має обробляти `1234` як рядок. _Проте_ парсер YAML споживає теґи, тому дані про типи втрачаються після одного аналізу.\n\n## Розгляд використання ваших значень користувачами {#consider-your-values-used-by-users}\n\nІснує три потенційні джерела значень:\n\n- Файл `values.yaml` чарту\n- Файл значень, переданий за допомогою `helm install -f` або `helm upgrade -f`\n- Значення, передані з прапорцем `--set` або `--set-string` під час `helm install` або `helm upgrade`\n\nПри проєктуванні структури ваших значень майте на увазі, що користувачі вашого чарту можуть захотіти перевизначити їх за допомогою прапорця `-f` або опції `--set`.\n\nОскільки `--set` більш обмежений у виразності, перше правило написання файлу `values.yaml` — _зробіть його зручним для перевизначення за допомогою `--set`_.\n\nЗ цієї причини часто краще структурувати файл значень, використовуючи map.\n\nВажко використовувати з `--set`:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nВищенаведене не можна виразити за допомогою `--set` у Helm `<=2.4`. У Helm 2.5 доступ до порту на foo здійснюється через `--set servers[0].port=80`. Не тільки це важче зрозуміти для користувача, але це ще й схильне до помилок, якщо пізніше порядок серверів зміниться.\n\nЛегко використовувати:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nОтримання доступу до порту foo стає набагато очевиднішим: `--set servers.foo.port=80`.\n\n## Документуйте `values.yaml` {#document-valuesyaml}\n\nКожна визначена властивість у `values.yaml` повинна бути задокументована. Рядок документації повинен починатися з назви властивості, яку він описує, а потім надавати принаймні одне речення опису.\n\nНеправильно:\n\n```yaml\n# назва хосту для веб-сервера\nserverHost: example\nserverPort: 9191\n```\n\nПравильно:\n\n```yaml\n# serverHost - це назва хосту для веб-сервера\nserverHost: example\n# serverPort - це порт HTTP-сервера для веб-сервера\nserverPort: 9191\n```\n\nПочаток кожного коментаря з назви параметра, який він документує, дозволяє легко знаходити документацію та дозволяє інструментам документації надійно співвідносити рядки документації з параметрами, які вони описують.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Доступ до файлів всередині шаблонів\ndescription: Як отримати доступ до файлів зсередини шаблону.\nsidebar_position: 10\n---\n\nУ попередньому розділі ми розглянули кілька способів створення та доступу до іменованих шаблонів. Це полегшує імпорт одного шаблону в інший шаблон. Але іноді корисно імплементувати _файл, який не є шаблоном_ і вбудувати його вміст без використання рендерера шаблонів.\n\nHelm надає доступ до файлів через обʼєкт `.Files`. Перш ніж переходити до прикладів шаблонів, є кілька моментів, які слід врахувати:\n\n- Можна додавати додаткові файли до вашого Helm чарту. Ці файли будуть упаковані. Але будьте обережні. Чарти мають бути меншими за 1М через обмеження зберігання обʼєктів Kubernetes.\n- Деякі файли не можна отримати через обʼєкт `.Files`, зазвичай з міркувань безпеки.\n  - Файли в `templates/` не можна отримати.\n  - Файли, виключені за допомогою `.helmignore`, не можна отримати.\n  - Файли поза Helm-застосукном [subchart](/chart_template_guide/subcharts_and_globals.md), включаючи файли батьківського чарту, не можна отримати.\n- Чарти не зберігають інформацію про режим UNIX, тому дозволи на рівні файлу не вплинуть на доступність файлу в обʼєкті `.Files`.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Базовий приклад](#basic-example)\n- [Помічники оброки шляхів](#path-helpers)\n- [Шаблони Glob](#glob-patterns)\n- [Утиліти для ConfigMap і Secrets](#configmap-and-secrets-utility-functions)\n- [Кодування](#encoding)\n- [Рядки](#lines)\n\n<!-- tocstop -->\n\n## Базовий приклад {#basic-example}\n\nЗ урахуванням цих застережень, напишемо шаблон, який читає три файли в наш ConfigMap. Для початку додамо три файли до чарту, розміщуючи всі три безпосередньо в теці `mychart/`.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nКожен з цих файлів є простим TOML-файлом (згадайте про старі INI-файли Windows). Ми знаємо імена цих файлів, тому можемо використовувати функцію `range`, щоб перебрати їх і вставити їх вміст у наш ConfigMap.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nЦей ConfigMap використовує кілька технік, обговорених у попередніх розділах. Наприклад, ми створюємо змінну `$files`, щоб зберегти посилання на обʼєкт `.Files`. Ми також використовуємо функцію `tuple`, щоб створити список файлів, які ми перебираємо. Потім ми виводимо кожне імʼя файлу (`{{ . }}: |-`) після чого йде вміст файлу `{{ $files.Get . }}`.\n\nЗапуск цього шаблону створить один ConfigMap з вмістом усіх трьох файлів:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Помічники оброки шляхів {#path-helpers}\n\nПри роботі з файлами може бути дуже корисно виконувати деякі стандартні операції з самими шляхами файлів. Для цього Helm імплементує багато функцій з пакета Go [path](https://golang.org/pkg/path/). Вони всі доступні з такими ж іменами, як у пакеті Go, але з маленькою першою літерою. Наприклад, `Base` стає `base` і т.д.\n\nІмпортовані функції:\n\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Шаблони glob {#glob-patterns}\n\nКоли ваш чарт зростає, ви можете знайти необхідність організувати ваші файли більше, і тому ми надаємо метод `Files.Glob(pattern string)` для допомоги у витягуванні певних файлів з усією гнучкістю [шаблонів glob](https://godoc.org/github.com/gobwas/glob).\n\n`.Glob` повертає тип `Files`, тому ви можете викликати будь-які методи `Files` на повернутому обʼєкті.\n\nНаприклад, уявіть структуру директорій:\n\n```none\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nУ вас є кілька варіантів з Globs:\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nАбо\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## Утиліти для ConfigMap і Secrets {#configmap-and-secrets-utility-functions}\n\n(Доступні з Helm 2.0.2 і пізніше)\n\nДуже часто потрібно помістити вміст файлів як у ConfigMaps, так і в Secrets, для монтування в ваші podʼи під час виконання. Для цього ми надаємо кілька методів утиліт для типу `Files`.\n\nДля подальшої організації особливо корисно використовувати ці методи разом з методом `Glob`.\n\nЗадана структура теки з прикладу [Glob](#glob-patterns):\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Кодування {#encoding}\n\nВи можете імплементувати файл і змусити шаблон закодувати його в base-64, щоб забезпечити успішну передачу:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nВищенаведене візьме той самий файл `config1.toml`, який ми використовували раніше, і закодує його:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Рядки {#lines}\n\nІноді потрібно отримати доступ до кожного рядка файлу у вашому шаблоні. Ми надаємо зручний метод `Lines` для цього.\n\nВи можете перебрати `Lines`, використовуючи функцію `range`:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nНемає можливості передавати файли, що знаходяться поза чартом, під час `helm install`. Тому, якщо ви просите користувачів надати дані, їх потрібно завантажити за допомогою `helm install -f` або `helm install --set`.\n\nЦе обговорення завершує наше занурення в інструменти та техніки написання шаблонів Helm. У наступному розділі ми побачимо, як можна використовувати один спеціальний файл, `templates/NOTES.txt`, для надсилання інструкцій після установки користувачам вашого чарту.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Вбудовані обʼєкти\ndescription: Вбудовані обʼєкти, доступні для шаблонів.\nsidebar_position: 3\n---\n\nОбʼєкти передаються в шаблон з рушія обробки шаблонів. І ваш код може передавати обʼєкти далі (ми побачимо приклади, коли розглянемо оператори `with` та `range`). Є навіть кілька способів створити нові обʼєкти всередині ваших шаблонів, як, наприклад, з функцією `tuple`, яку ми розглянемо пізніше.\n\nОбʼєкти можуть бути простими та мати лише одне значення. Або вони можуть містити інші обʼєкти чи функції. Наприклад, обʼєкт `Release` містить кілька обʼєктів (наприклад, `Release.Name`), а обʼєкт `Files` має кілька функцій.\n\nУ попередньому розділі ми використовували `{{ .Release.Name }}`, щоб вставити імʼя релізу в шаблон. `Release` — один з обʼєктів верхнього рівня, до якого ви можете отримати доступ у своїх шаблонах.\n\n- `Release`: Цей обʼєкт описує сам реліз. Він містить кілька обʼєктів:\n  - `Release.Name`: Імʼя релізу\n  - `Release.Namespace`: Простір імен, у який буде здійснено реліз (якщо маніфест не перевизначить)\n  - `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом.\n  - `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням.\n  - `Release.Revision`: Номер ревізії для цього релізу. Під час встановлення це 1, і він збільшується з кожним оновленням або відкатом.\n  - `Release.Service`: Сервіс, який обробляє поточний шаблон. У Helm це завжди `Helm`.\n- `Values`: Значення, передані в шаблон з файлу `values.yaml` і з файлів, наданих користувачем. Стандартно `Values` порожній.\n- `Chart`: Вміст файлу `Chart.yaml`. Будь-які дані в `Chart.yaml` будуть доступні тут. Наприклад, `{{ .Chart.Name }}-{{ .Chart.Version }}` виведе `mychart-0.1.0`.\n  - Доступні поля перелічені в [довіднику по Chart](/topics/charts.md#the-chart-yaml-file)\n- `Subcharts`: Надає доступ до області дії (.Values, .Charts, .Releases тощо) субшаблонів з батьківського шаблону. Наприклад, `.Subcharts.mySubChart.myValue`, щоб отримати доступ до `myValue` у шаблоні `mySubChart`.\n- `Files`: Це надає доступ до всіх не-спеціальних файлів у шаблоні. Ви не можете використовувати його для доступу до шаблонів, але можете використовувати його для доступу до інших файлів у шаблоні. Див. розділ [Доступ до файлів](/chart_template_guide/accessing_files.md) для отримання додаткової інформації.\n  - `Files.Get` — це функція для отримання файлу за іменем (`.Files.Get config.ini`).\n  - `Files.GetBytes` — це функція для отримання вмісту файлу у вигляді масиву байтів, а не рядка. Це корисно для таких речей, як образи.\n  - `Files.Glob` — це функція, яка повертає список файлів, імена яких відповідають заданому шаблону оболонки.\n  - `Files.Lines` — це функція, яка зчитує файл рядок за рядком. Це корисно для ітерації по кожному рядку у файлі.\n  - `Files.AsSecrets` — це функція, яка повертає вміст файлів у вигляді Base64-кодованих рядків.\n  - `Files.AsConfig` — це функція, яка повертає вміст файлів у вигляді YAML map.\n- `Capabilities`: Надає інформацію про можливості, які підтримує кластер Kubernetes.\n  - `Capabilities.APIVersions` — це набір версій.\n  - `Capabilities.APIVersions.Has $version` вказує на те, чи доступна версія (наприклад, `batch/v1`) або ресурс (наприклад, `apps/v1/Deployment`) у кластері.\n  - `Capabilities.KubeVersion` і `Capabilities.KubeVersion.Version` — це версія Kubernetes.\n  - `Capabilities.KubeVersion.Major` — це основна версія Kubernetes.\n  - `Capabilities.KubeVersion.Minor` — це мінорна версія Kubernetes.\n  - `Capabilities.HelmVersion` — це обʼєкт, який містить деталі версії Helm, це той самий вивід, що і `helm version`.\n  - `Capabilities.HelmVersion.Version` — це поточна версія Helm у форматі semver.\n  - `Capabilities.HelmVersion.GitCommit` — це Git-ідентифікатор SHA1 для Helm.\n  - `Capabilities.HelmVersion.GitTreeState` — це стан дерева git для Helm.\n  - `Capabilities.HelmVersion.GoVersion` — це версія компілятора Go, який використовувався.\n- `Template`: Містить інформацію про поточний шаблон, який виконується.\n  - `Template.Name`: Іменований шлях до поточного шаблону (наприклад, `mychart/templates/mytemplate.yaml`).\n  - `Template.BasePath`: Іменований шлях до теки шаблонів поточного шаблону (наприклад, `mychart/templates`).\n\nВбудовані значення завжди починаються з великої літери. Це відповідає угоді про найменування у Go. Коли ви створюєте власні імена, ви можете використовувати угоду, яка підходить вашій команді. Деякі команди, як і багато тих, чиї шаблони ви можете бачити на [Artifact Hub](https://artifacthub.io/packages/search?kind=0), обирають використовувати лише початкові малі літери, щоб відрізнити локальні імена від вбудованих. У цьому посібнику ми дотримуємося цієї угоди.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Керування потоком\ndescription: Швидкий огляд структури керування потоком в шаблонах.\nsidebar_position: 7\n---\n\nСтруктури керування (називаються \"діями\" в термінології шаблонів) надають вам, автору шаблонів, можливість контролювати потік генерації шаблону. Мова шаблонів Helm надає такі структури керування:\n\n- `if`/`else` для створення умовних блоків\n- `with` для визначення області видимості\n- `range`, який надає цикл \"for each\"\n\nОкрім цих, є кілька дій для оголошення та використання іменованих сегментів шаблону:\n\n- `define` оголошує новий іменований шаблон всередині вашого шаблону\n- `template` імплементує іменований шаблон\n- `block` оголошує спеціальний тип заповнювальної області шаблону\n\nУ цьому розділі ми розглянемо `if`, `with` та `range`. Інші дії будуть розглянуті в розділі \"Іменовані шаблони\" пізніше в цьому посібнику.\n\n## If/Else\n\nПерша структура керування, яку ми розглянемо, використовується для умовного включення блоків тексту в шаблоні. Це блоки `if`/`else`.\n\nОсновна структура блоку з умовою виглядає так:\n\n```none\n{{ if PIPELINE }}\n  # Щось зробити\n{{ else if OTHER PIPELINE }}\n  # Зробити щось інше\n{{ else }}\n  # Стандартне значення\n{{ end }}\n```\n\nЗверніть увагу, що тепер ми говоримо про _пайплайни_ замість значень. Причина в цьому полягає в тому, щоб уточнити, що структури керування можуть виконувати цілий пайплайн, а не лише оцінювати значення.\n\nПайплайн вважається _хибним_, якщо значення є:\n\n- булевим хибним\n- числовим нулем\n- порожнім рядком\n- `nil` (порожнім або null)\n- порожньою колекцією (`map`, `slice`, `tuple`, `dict`, `array`)\n\nУ всіх інших умовах умова є істинною.\n\nДодамо просту умовну конструкцію до нашого ConfigMap. Ми додамо ще одне налаштування, якщо напій встановлений на каву:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nОскільки ми закоментували `drink: coffee` у нашому останньому прикладі, вихідний файл не повинен містити прапорець `mug: \"true\"`. Але якщо ми додамо цей рядок назад у наш файл `values.yaml`, вихід виглядатиме так:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Контроль пробілів {#controlling-whitespace}\n\nПід час роботи з умовами варто звернути увагу на те, як контролюється кількість пробілів у шаблонах. Розглянемо попередній приклад і відформатуємо його для зручнішого читання:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nСпочатку це має гарний вигляд. Але якщо ми пропустимо його через рушій шаблонів, отримаємо неприємний результат:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nЩо сталося? Ми згенерували некоректний YAML через пробіли.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` має невірний відступ. Виправимо це, зменшивши відступ цього рядка, і запустимо знову:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nКоли ми запустимо це, отримаємо валідний YAML, але з кількома порожніми рядками:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n```\n\nПомітно, що у нас є кілька пустих рядків у YAML. Чому? Коли рушій шаблонів виконує шаблон, він _видаляє_ вміст всередині `{{` і `}}`, але залишає пробіли без змін.\n\nYAML надає значення пробілам, тому управління пробілами стає важливим. На щастя, шаблони Helm мають кілька інструментів у поміч.\n\nПо-перше, синтаксис фігурних дужок шаблонів можна модифікувати за допомогою спеціальних символів, щоб вказати движку шаблонів обрізати пробіли. `{{- ` (з тире і пробілом) вказує, що пробіли зліва повинні бути видалені, тоді як ` -}}` означає, що пробіли справа повинні бути видалені. _Будьте обережні! Нові рядки — це пробіли!_\n\n> Переконайтеся, що є пробіл між `-` і рештою вашої директиви. `{{- 3 }}` означає \"вирізати ліві пробіли та вивести 3\", тоді як `{{-3 }}` означає \"вивести -3\".\n\nВикористовуючи цей синтаксис, ми можемо змінити наш шаблон, щоб позбутися від тих нових рядків:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nЩоб прояснити це, відзначимо кожен пробіл, який буде видалено відповідно до цього правила. `*` в кінці рядка вказує на символ нового рядка, який буде видалений:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nЗважаючи на це, ми можемо запустити наш шаблон через Helm і побачити результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nБудьте обережні з модифікаторами обрізання пробілів. Легко випадково зробити ось так:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nЦе створить `food: \"PIZZA\"mug: \"true\"`, оскільки пробіли з обох сторін будуть видалені.\n\n> Для деталей про контроль пробілів у шаблонах дивіться [Офіційну документацію Go шаблонів](https://godoc.org/text/template)\n\nНарешті, іноді легше сказати системі шаблонів, як вам потрібно робити відступи, замість того, щоб намагатися освоїти розташування пробілів у директивах шаблону. З цієї причини іноді корисно використовувати функцію `indent` (`{{ indent 2 \"mug:true\" }}`).\n\n## Модифікація області видимості за допомогою `with` {#modifying-scope-using-with}\n\nНаступна структура управління, яку розглянемо, це дія `with`. Вона контролює область видимості змінних. Нагадаємо, що `.` є посиланням на _поточну область видимості_. Отже, `.Values` вказує шаблону знайти обʼєкт `Values` у поточній області видимості.\n\nСинтаксис для `with` схожий на простий оператор `if`:\n\n```none\n{{ with PIPELINE }}\n  # обмежена область видимості\n{{ end }}\n```\n\nОбласті видимості можуть змінюватися. `with` дозволяє вам встановити поточну область видимості (`.`) на певний обʼєкт. Наприклад, ми працювали з `.Values.favorite`. Перепишемо наш ConfigMap, щоб змінити область видимості `.` на `.Values.favorite`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nЗверніть увагу, що ми видалили умову `if` з попереднього прикладу, оскільки вона тепер непотрібна — блок після `with` виконується лише якщо значення `PIPELINE` не є порожнім.\n\nТепер ми можемо звертатися до `.drink` і `.food` без додаткових уточнень. Це відбувається тому, що оператор `with` встановлює `.` на `.Values.favorite`. `.` скидається до попередньої області видимості після `{{ end }}`.\n\nАле є одне застереження! Усередині обмеженої області видимості ви не зможете отримати доступ до інших обʼєктів з батьківської області видимості за допомогою `.`. Наприклад, це не спрацює:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nЦе викличе помилку, оскільки `Release.Name` не знаходиться в межах обмеженої області видимості для `.`. Однак, якщо ми поміняємо місцями останні два рядки, все працюватиме як очікувалося, тому що область видимості скидається після `{{ end }}`.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nАбо ми можемо використовувати `$` для доступу до обʼєкта `Release.Name` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nПісля розгляду `range` ми перейдемо до змінних шаблону, які пропонують одне рішення для проблеми з областю видимості вище.\n\n## Цикли за допомогою дії `range` {#looping-with-the-range-action}\n\nБагато мов програмування підтримують цикли за допомогою `for` циклів, `foreach` циклів або подібних функціональних механізмів. У мові шаблонів Helm, для перебору колекції використовується оператор `range`.\n\nСпочатку додамо список інгредієнтів для піци до нашого файлу `values.yaml`:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n```\n\nТепер у нас є список (в шаблонах він називається `slice`) інгредієнтів для піци. Ми можемо змінити наш шаблон, щоб вивести цей список у наш ConfigMap:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n```\n\nМи можемо використовувати `$` для доступу до списку `Values.pizzaToppings` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nРозглянемо детальніше список `toppings:`. Функція `range` буде \"перебирати\" список `pizzaToppings`. Але тепер відбувається щось цікаве. Так само як `with` встановлює область видимості для `.`, так і оператор `range` встановлює область видимості. Кожного разу під час циклу `.` встановлюється на поточний інгредієнт для піци. Тобто, під час першої ітерації `.` буде дорівнювати `mushrooms`. Під час другої ітерації він буде дорівнювати `cheese`, і так далі.\n\nМи можемо безпосередньо передавати значення `.` в конвеєр, тому коли ми використовуємо `{{ . | title | quote }}`, воно передається в `title` (функцію для перетворення на заголовні літери) і потім в `quote`. Якщо ми запустимо цей шаблон, результат буде:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n```\n\nУ цьому прикладі ми зробили дещо хитре. Лінія `toppings: |-` оголошує багаторядковий рядок. Отже, наш список інгредієнтів для піци насправді не є YAML списком. Це великий рядок. Чому ми так робимо? Тому що дані в ConfigMaps `data` складаються з пар ключ/значення, де і ключ, і значення є простими рядками. Щоб зрозуміти, чому це так, ознайомтеся з [документацією Kubernetes ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/). Для нас цей нюанс не так важливий.\n\n> Маркер `|-` в YAML приймає багаторядковий рядок. Це може бути корисною технікою для вбудовування великих блоків даних у ваші маніфести, як показано тут.\n\nІноді корисно швидко створити список у шаблоні, а потім перебирати цей список. Шаблони Helm мають функцію для спрощення цього завдання: `tuple`. У компʼютерних науках кортеж (tuple) — це список фіксованого розміру, але з довільними типами даних. Це приблизно передає те, як використовується `tuple`.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nВищезазначене створить:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nОкрім списків і кортежів, `range` можна використовувати для перебору колекцій, які мають ключ і значення (як `map` або `dict`). Ми розглянемо, як це зробити в наступному розділі, коли введемо змінні шаблону.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Додаток: Типи даних Go та шаблони\"\ndescription: Короткий огляд змінних у шаблонах.\nsidebar_position: 16\n---\n\nМова шаблонів Helm реалізована мовою програмування Go, яка має сувору типізацію. З цієї причини змінні в шаблонах мають _типи_. Здебільшого змінні будуть представлені одним із наступних типів:\n\n- `string`: Рядок тексту\n- `bool`: значення `true` або `false`\n- `int`: Ціле число (існують також 8, 16, 32 і 64-бітні знакові та беззнакові варіанти)\n- `float64`: 64-бітне число з плаваючою комою (також є 8, 16 та 32-бітні різновиди)\n- `byte slice` (`[]byte`): Масив байтів, часто використовується для зберігання (можливо) бінарних даних\n- `struct`: Обʼєкт із властивостями та методами\n- `slice`: Список з індексами одного з попередніх типів\n- `map`: Map з ключами-рядками (`map[string]interface{}`), де значенням є один із попередніх типів\n\nІснує багато інших типів у Go, і іноді вам доведеться конвертувати між ними в шаблонах. Найпростіший спосіб налагодження типу обʼєкта — передати його через `printf \"%T\"` у шаблоні, що виведе тип. Також корисно ознайомитись із функціями `typeOf` та `kindOf`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: Виправлення помилок у шаблонах\ndescription: Виправлення проблем з розгортанням чартів.\nsidebar_position: 13\n---\n\nВиправлення помилок у шаблонах може бути складним, оскільки відрендерені шаблони надсилаються на сервер API Kubernetes, який може відхиляти YAML-файли з інших причин, окрім форматування.\n\nЄ кілька команд, які можуть допомогти в процесі налагодження:\n\n- `helm lint` є вашим основним інструментом для перевірки того, чи ваш чарт відповідає найкращим практикам.\n- `helm template --debug` дозволяє тестувати рендеринг шаблонів чарту локально.\n- `helm install --dry-run --debug` також рендерить ваш чарт локально без його встановлення, але також перевіряє, чи конфліктують ресурси вже з запущеними на кластері. Налаштування `--dry-run=server` додатково виконає будь-які `lookup` у вашому чарті на сервері.\n- `helm get manifest`: Це хороший спосіб побачити, які шаблони встановлені на сервері.\n\nКоли ваш YAML не проходить перевірку, але ви хочете побачити, що було згенеровано, простий спосіб отримати YAML — закоментувати проблемний розділ у шаблоні, а потім повторно запустити `helm install --dry-run --debug`:\n\n```yaml\napiVersion: v2\n# деяка: проблемна секція\n# {{ .Values.foo | quote }}\n```\n\nВищенаведене буде відрендерене і повернуто з коментарями, що дозволяє швидко переглядати згенерований контент без помилок парсингу YAML:\n\n```yaml\napiVersion: v2\n# деяка: проблемна секція\n#  \"bar\"\n```\n\nЦе забезпечує швидкий спосіб перегляду згенерованого контенту без блокування помилками парсингу YAML.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: Список функцій шаблонів\ndescription: Список функцій шаблонів, доступних у Helm\nsidebar_position: 6\n---\n\nHelm містить багато функцій шаблонів, якими ви можете скористатися у шаблонах. Вони перераховані тут і розбиті на наступні категорії:\n\n* [Криптографія та безпека](#cryptographic-and-security-functions)\n* [Дата](#date-functions)\n* [Словники](#dictionaries-and-dict-functions)\n* [Кодування](#encoding-functions)\n* [Шлях до файлу](#file-path-functions)\n* [Kubernetes та чарти](#kubernetes-and-chart-functions)\n* [Логіка та керування потоком](#logic-and-flow-control-functions)\n* [Списки](#lists-and-list-functions)\n* [Математичні функції](#math-functions)\n* [Математичні обчислення з комою](#float-math-functions)\n* [Мережа](#network-functions)\n* [Аналіз](#reflection-functions)\n* [Регулярні вирази](#regular-expressions)\n* [Семантичні версії](#semantic-version-functions)\n* [Рядки](#string-functions)\n* [Перетворення типів](#type-conversion-functions)\n* [URL](#url-functions)\n* [UUID](#uuid-functions)\n\n## Логічні функції та функції керування потоком {#logic-and-flow-control-functions}\n\nHelm містить численні логічні та контрольні функції, включаючи [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).\n\n### and\n\nПовертає логічне AND для двох або більше аргументів (перший пустий аргумент або останній аргумент).\n\n```none\nand .Arg1 .Arg2\n```\n\n### or\n\nПовертає логічне OR для двох або більше аргументів (перший непустий аргумент або останній аргумент).\n\n```none\nor .Arg1 .Arg2\n```\n\n### not\n\nПовертає логічне заперечення свого аргументу.\n\n```none\nnot .Arg\n```\n\n### eq\n\nПовертає логічну рівність аргументів (наприклад, Arg1 == Arg2).\n\n```none\neq .Arg1 .Arg2\n```\n\n### ne\n\nПовертає логічну нерівність аргументів (наприклад, Arg1 != Arg2)\n\n```none\nne .Arg1 .Arg2\n```\n\n### lt\n\nПовертає логічне `true`, якщо перший аргумент менший за другий. В іншому випадку повертає `false` (наприклад, Arg1 < Arg2).\n\n```none\nlt .Arg1 .Arg2\n```\n\n### le\n\nПовертає логічне `true`, якщо перший аргумент менший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 <= Arg2).\n\n```none\nle .Arg1 .Arg2\n```\n\n### gt\n\nПовертає логічне `true`, якщо перший аргумент більший за другий. В іншому випадку повертає `false` (наприклад, Arg1 > Arg2).\n\n```none\ngt .Arg1 .Arg2\n```\n\n### ge\n\nПовертає логічне `true`, якщо перший аргумент більший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 >= Arg2).\n\n```none\nge .Arg1 .Arg2\n```\n\n### default\n\nЩоб встановити просте стандартне значення, використовуйте `default`:\n\n```none\ndefault \"foo\" .Bar\n```\n\nУ наведеному прикладі, якщо `.Bar` має непусте значення, воно буде використане. Якщо ж воно пусте, повернеться `foo`.\n\nВизначення \"пустого\" залежить від типу:\n\n* Числові: 0\n* Рядок: \"\"\n* Списки: `[]`\n* Словники: `{}`\n* Логічний: `false`\n* І завжди `nil` (або null)\n\nДля структур немає визначення пустого значення, тому структура ніколи не поверне стандартного значення.\n\n### required\n\nВкажіть значення, які повинні бути встановлені, за допомогою `required`:\n\n```none\nrequired \"A valid foo is required!\" .Bar\n```\n\nЯкщо `.Bar` є пустим або не визначеним (див. [default](#default) щодо того, як це оцінюється), шаблон не буде згенерований і поверне надане повідомлення про помилку.\n\n### empty\n\nФункція `empty` повертає `true`, якщо надане значення вважається пустим, і `false` в іншому випадку. Пусті значення перелічені в розділі `default`.\n\n```none\nempty .Foo\n```\n\nЗверніть увагу, що в умовах шаблонів Go пустота розраховується автоматично. Таким чином, рідко потрібно використовувати `if not empty .Foo`. Замість цього просто використовуйте `if .Foo`.\n\n### fail\n\nБезумовно повертає пустий `string` та `error` з зазначеним текстом. Це корисно в ситуаціях, коли інші умови визначили, що рендеринг шаблону повинен зазнати невдачі.\n\n```none\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\nФункція `coalesce` приймає список значень і повертає перше непусте.\n\n```none\ncoalesce 0 1 2\n```\n\nУ наведеному випадку повертає `1`.\n\nЦя функція корисна для перевірки кількох змінних або значень:\n\n```none\ncoalesce .name .parent.name \"Matt\"\n```\n\nЦей приклад спочатку перевірить, чи є `.name` непустим. Якщо це так, буде повернене це значення. Якщо ж воно _пусте_, `coalesce` перевірить `.parent.name` на пустоту. Нарешті, якщо обидва `.name` і `.parent.name` пусті, буде повернене `Matt`.\n\n### ternary\n\nФункція `ternary` приймає два значення і тестове значення. Якщо тестове значення є `true`, повернеться перше значення. Якщо тестове значення є пустим, повернеться друге значення. Це подібно до тернарного оператора в C та інших мовах програмування.\n\n#### тестове значення true {#true-test-value}\n\n```none\nternary \"foo\" \"bar\" true\n```\n\nабо\n\n```none\ntrue | ternary \"foo\" \"bar\"\n```\n\nУ цьому випадку повертається `\"foo\"`.\n\n#### тестове значення false {#false-test-value}\n\n```none\nternary \"foo\" \"bar\" false\n```\n\nабо\n\n```none\nfalse | ternary \"foo\" \"bar\"\n```\n\nУ цьому випадку повертається `\"bar\"`.\n\n## Функції для роботи з рядками {#string-functions}\n\nHelm включає такі функції для рядків: [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).\n\n### print\n\nПовертає рядок, що є комбінацією його частин.\n\n```none\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\nТипи, які не є рядками, перетворюються на рядки, якщо це можливо.\n\nЗверніть увагу, що коли два аргументи поруч один з одним не є рядками, між ними додається пробіл.\n\n### println\n\nПрацює так само як [print](#print), але додає новий рядок наприкінці.\n\n### printf\n\nПовертає рядок на основі відформатованого рядка та аргументів, що передаються у до нього.\n\n```none\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\nЗаповнювач, який слід використовувати, залежить від типу переданого аргументу. Серед них:\n\nЗагального призначення:\n\n* `%v` значення в стандартному форматі\n  * при друку словників, прапорець `+` (%+v) додає імена полів\n* `%%` літеральний знак відсотка; не використовує значення\n\nЛогічний:\n\n* `%t` слово true або false\n\nЦілі числа:\n\n* `%b` двійкові, основа 2\n* `%c` символ, що відповідає точці Unicode\n* `%d` десяткові, основа 10\n* `%o` вісімкові, основа 8\n* `%O` основа 8 з префіксом 0o\n* `%q` вісімкові, однорядковий літерал символу, безпечно екранований\n* `%x` шістнадцяткові, основа 16, з малими літерами для a-f\n* `%X` шістнадцяткові, основа 16, з великими літерами для A-F\n* `%U` Unicode формат: U+1234; те ж саме, що \"U+%04X\"\n\nЧисла з плаваючою комою та складові частини:\n\n* `%b` десятковий формат без наукової нотації з показником ступеня двійки, наприклад\n  -123456p-78\n* `%e` наукова нотація, наприклад -1.234456e+78\n* `%E` наукова нотація, наприклад -1.234456E+78\n* `%f` десятковий формат без експоненти, наприклад 123.456\n* `%F` синонім для %f\n* `%g` %e для великих експонент, %f в іншому випадку\n* `%G` %E для великих експонент, %F в іншому випадку\n* `%x` шістнадцяткова нотація (з десятковим показником ступеня), наприклад -0x1.23abcp+20\n* `%X` шістнадцяткова нотація у верхньому регістрі, наприклад -0X1.23ABCP+20\n\nРядок та зріз байтів (обробляються однаково з цими діями):\n\n* `%s` необроблені байти рядка або зрізу\n* `%q` рядок в подвійних лапках, безпечно екранований\n* `%x` основа 16, малий регістр, два символи на байт\n* `%X` основа 16, великий регістр, два символи на байт\n\nЗріз:\n\n* `%p` адреса 0-го елемента у шістнадцятковій нотації, з передуючим 0x\n\n### trim\n\nФункція `trim` видаляє пробіли з обох сторін рядка:\n\n```none\ntrim \"   hello    \"\n```\n\nУ результаті отримаємо `hello`.\n\n### trimAll\n\nВидаляє зазначені символи з початку та кінця рядка:\n\n```none\ntrimAll \"$\" \"$5.00\"\n```\n\nУ результаті отримаємо `5.00` (як рядок).\n\n### trimPrefix\n\nВидаляє лише префікс з рядка:\n\n```none\ntrimPrefix \"-\" \"-hello\"\n```\n\nУ результаті отримаємо `hello`.\n\n### trimSuffix\n\nВидаляє лише суфікс з рядка:\n\n```none\ntrimSuffix \"-\" \"hello-\"\n```\n\nУ результаті отримаємо `hello`.\n\n### lower\n\nПеретворює весь рядок у нижній регістр:\n\n```none\nlower \"HELLO\"\n```\n\nУ результаті отримаємо `hello`.\n\n### upper\n\nПеретворює весь рядок у верхній регістр:\n\n```none\nupper \"hello\"\n```\n\nУ результаті отримаємо `HELLO`.\n\n### title\n\nПеретворює рядок у титульний регістр:\n\n```none\ntitle \"hello world\"\n```\n\nУ результаті отримаємо `Hello World`.\n\n### untitle\n\nВидаляє титульне оформлення. `untitle \"Hello World\"` поверне `hello world`.\n\n### repeat\n\nПовторює рядок кілька разів:\n\n```none\nrepeat 3 \"hello\"\n```\n\nУ результаті отримаємо `hellohellohello`.\n\n### substr\n\nОтримує підрядок з рядка. Параметри:\n\n* start (int)\n* end (int)\n* рядок (string)\n\n```none\nsubstr 0 5 \"hello world\"\n```\n\nУ результаті отримаємо `hello`.\n\n### nospace\n\nВидаляє всі пробіли з рядка:\n\n```none\nnospace \"hello w o r l d\"\n```\n\nУ результаті отримаємо `helloworld`.\n\n### trunc\n\nОбрізає рядок:\n\n```none\ntrunc 5 \"hello world\"\n```\n\nУ результаті отримаємо `hello`.\n\n```none\ntrunc -5 \"hello world\"\n```\n\nУ результаті отримаємо `world`.\n\n### abbrev\n\nОбрізає рядок додаючи три крапки (`...`):\n\nПараметри:\n\n* максимальна довжина\n* рядок\n\n```none\nabbrev 5 \"hello world\"\n```\n\nУ результаті отримаємо `he...`, оскільки ширина трьох крапок враховується до максимальної довжини.\n\n### abbrevboth\n\nОбрізає обидві сторони:\n\n```none\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\nУ результаті отримаємо `...5678...`.\n\nПараметри:\n\n* зсув ліворуч\n* максимальна довжина\n* рядок\n\n### initials\n\nДля кількох слів бере першу літеру кожного слова та обʼєднує їх:\n\n```none\ninitials \"First Try\"\n```\n\nУ результаті отримаємо `FT`.\n\n### randAlphaNum, randAlpha, randNumeric та randAscii {#randalphanum-randalpha-randnumeric-and-randascii}\n\nЦі чотири функції генерують криптографічно безпечні (використовує ```crypto/rand```) випадкові рядки, але з різними базовими наборами символів:\n\n* `randAlphaNum` використовує `0-9a-zA-Z`\n* `randAlpha` використовує `a-zA-Z`\n* `randNumeric` використовує `0-9`\n* `randAscii` використовує всі друковані ASCII символи\n\nКожна з них приймає один параметр: цілу довжину рядка.\n\n```none\nrandNumeric 3\n```\n\nУ результаті отримаємо випадковий рядок з трьох цифр.\n\n### wrap\n\nВиконує перенесення тексту на вказаній кількості стовпців:\n\n```none\nwrap 80 $someText\n```\n\nУ результаті для рядка `$someText` буде виконано перенесення на 80-му стовпці.\n\n### wrapWith\n\n`wrapWith` працює так само як і `wrap`, але дозволяє вказати рядок для перенесення.\n(`wrap` використовує `\\n`)\n\n```none\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\nУ результаті отримаємо `Hello World` (де пробіл є символом ASCII табуляції).\n\n### contains\n\nПеревіряє, чи один рядок міститься всередині іншого:\n\n```none\ncontains \"cat\" \"catch\"\n```\n\nУ результаті отримаємо `true`, оскільки `catch` містить `cat`.\n\n### hasPrefix і hasSuffix {#hasprefix-and-hassuffix}\n\nФункції `hasPrefix` і `hasSuffix` перевіряють, чи має рядок заданий префікс або суфікс:\n\n```none\nhasPrefix \"cat\" \"catch\"\n```\n\nУ результаті отримаємо `true`, оскільки `catch` має префікс `cat`.\n\n### quote і squote {#quote-and-squote}\n\nЦі функції обгортають рядок у подвійні лапки (`quote`) або одинарні лапки (`squote`).\n\n### cat\n\nФункція `cat` обʼєднує кілька рядків в один, розділяючи їх пробілами:\n\n```none\ncat \"hello\" \"beautiful\" \"world\"\n```\n\nУ результаті отримаємо `hello beautiful world`.\n\n### indent\n\nФункція `indent` додає відступ у кожному рядку вказаного тексту на зазначену кількість символів. Це корисно для вирівнювання багаторядкових текстів:\n\n```none\nindent 4 $lots_of_text\n```\n\nУ результаті кожен рядок тексту буде мати відступ на 4 символи пробілу.\n\n### nindent\n\nФункція `nindent` є такою ж, як і `indent`, але додає новий рядок на початку рядка.\n\n```none\nnindent 4 $lots_of_text\n```\n\nУ результаті кожен рядок тексту буде мати відступ на 4 символи пробілу, а також буде додано новий рядок на початку.\n\n### replace\n\nВиконує просту заміну рядків.\n\nВона приймає три аргументи:\n\n* рядок для заміни\n* рядок, на який замінювати\n* вихідний рядок\n\n```none\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\nУ результаті отримаємо `I-Am-Henry-VIII`.\n\n### plural\n\nФорма множини.\n\n```none\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\nУ наведеному випадку, якщо довжина рядка дорівнює 1, буде надруковано перший аргумент (`one anchovy`). В іншому випадку буде надруковано другий аргумент (`many anchovies`).\n\nАргументи:\n\n* однина\n* множина\n* довжина (ціле число)\n\nПРИМІТКА: Helm наразі не підтримує мови зі складнішими правилами множини. І `0` вважається множиною, оскільки англійська мова ставиться до нього саме так (`zero anchovies`).\n\n### snakecase\n\nПеретворює рядок з camelCase в snake_case.\n\n```none\nsnakecase \"FirstName\"\n```\n\nУ результаті отримаємо `first_name`.\n\n### camelcase\n\nПеретворює рядок з snake_case в CamelCase.\n\n```none\ncamelcase \"http_server\"\n```\n\nУ результаті отримаємо `HttpServer`.\n\n### kebabcase\n\nПеретворює рядок з camelCase в kebab-case.\n\n```none\nkebabcase \"FirstName\"\n```\n\nУ результаті отримаємо `first-name`.\n\n### swapcase\n\nЗмінює регістр рядка за допомогою алгоритму на основі слів.\n\nАлгоритм перетворення:\n\n* Символи у верхньому регістрі перетворюються у нижній регістр\n* Символи в титульному регістрі перетворюються у нижній регістр\n* Символи у нижньому регістрі після пробілу або на початку перетворюються у титульний регістр\n* Інші символи у нижньому регістрі перетворюються у верхній регістр\n* Пробіли визначаються як unicode.IsSpace(char)\n\n```none\nswapcase \"This Is A.Test\"\n```\n\nУ результаті отримаємо `tHIS iS a.tEST`.\n\n### shuffle\n\nПеремішує рядок.\n\n```none\nshuffle \"hello\"\n```\n\nУ результаті отримаємо випадковий порядок літер у `hello`, можливо, `oelhl`.\n\n## Функції перетворення типів {#type-conversion-functions}\n\nHelm пропонує такі функції для перетворення типів:\n\n* `atoi`: Перетворює рядок на ціле число.\n* `float64`: Перетворює на `float64`.\n* `int`: Перетворює на `int` відповідно до ширини системи.\n* `int64`: Перетворює на `int64`.\n* `toDecimal`: Перетворює unix octal на `int64`.\n* `toString`: Перетворює на рядок.\n* `toStrings`: Перетворює список, зріз або масив на список рядків.\n* `toJson` (`mustToJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON.\n* `toPrettyJson` (`mustToPrettyJson`): Перетворює список, зріз, масив, словник або обʼєкт на форматований JSON.\n* `toRawJson` (`mustToRawJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON з неекранованими HTML символами.\n* `fromYaml`: Перетворює YAML рядок на обʼєкт.\n* `fromJson`: Перетворює JSON рядок на обʼєкт.\n* `fromJsonArray`: Перетворює JSON масив на список.\n* `toYaml`: Перетворює список, зріз, масив, словник або обʼєкт на відформатований YAML.\n* `toToml`: Перетворює список, зріз, масив, словник або обʼєкт на TOML.\n* `fromYamlArray`: Перетворює YAML масив на список.\n\n### toStrings\n\nПеретворює колекцію схожу на список на зріз рядків.\n\n```none\nlist 1 2 3 | toStrings\n```\n\nПеретворює `1` на `\"1\"`, `2` на `\"2\"` і так далі, а потім повертає їх як список.\n\n### toDecimal\n\nПеретворює unix octal на десятковий формат.\n\n```none\n\"0777\" | toDecimal\n```\n\nПеретворює `0777` на `511` і повертає значення як int64.\n\n### toJson, mustToJson\n\nФункція `toJson` кодує елемент у JSON рядок. Якщо елемент не може бути перетворений на JSON, функція поверне порожній рядок. `mustToJson` поверне помилку, якщо елемент не може бути закодований в JSON.\n\n```none\ntoJson .Item\n```\n\nПоверне JSON рядкове представлення `.Item`.\n\n### toPrettyJson, mustToPrettyJson\n\nФункція `toPrettyJson` кодує елемент у форматований (з відступами) JSON рядок.\n\n```none\ntoPrettyJson .Item\n```\n\nПоверне відформатоване JSON рядкове представлення `.Item`.\n\n### toRawJson, mustToRawJson\n\nФункція `toRawJson` кодує елемент у JSON рядок з неекранованими HTML символами.\n\n```none\ntoRawJson .Item\n```\n\nПоверне неекрановане JSON рядкове представлення `.Item`.\n\n### fromYaml\n\nФункція `fromYaml` приймає YAML рядок і повертає обʼєкт, який можна використовувати в шаблонах.\n\nФайл `yamls/person.yaml`:\n\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml \n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\nФункція `fromJson` приймає JSON рядок і повертає обʼєкт, який можна використовувати в шаблонах.\n\nФайл `jsons/person.json`:\n\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJsonArray\n\nФункція `fromJsonArray` приймає JSON масив і повертає список, який можна використовувати в шаблонах.\n\nФайл `jsons/people.json`:\n\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### fromYamlArray\n\nФункція `fromYamlArray` приймає YAML масив і повертає список, який можна використовувати в шаблонах.\n\nФайл `yamls/people.yml`:\n\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n## Регулярні Вирази {#regular-expressions}\n\nHelm включає такі функції для роботи з регулярними виразами: [regexMatch](#regexmatch-mustregexmatch), [regexFindAll](#regexfindall-mustregexfindall), [regexFind](#regexfind-mustregexfind), [regexReplaceAll](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\nПовертає `true`, якщо вхідний рядок містить хоча б один збіг для регулярного виразу.\n\n```yaml\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\nПоверне `true`.\n\n`regexMatch` викликає паніку у разі проблеми, а `mustRegexMatch` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexFindAll, mustRegexFindAll\n\nПовертає зріз усіх збігів регулярного виразу у вхідному рядку. Останній параметр `n` визначає кількість підрядків для повернення, де `-1` означає повернути всі збіги.\n\n```yaml\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\nПоверне `[2 4 6 8]`.\n\n`regexFindAll` викликає паніку у разі проблеми, а `mustRegexFindAll` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexFind, mustRegexFind\n\nПовертає перший (зліва) збіг регулярного виразу у вхідному рядку.\n\n```yaml\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\nПоверне `d1`.\n\n`regexFind` викликає паніку у разі проблеми, а `mustRegexFind` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexReplaceAll, mustRegexReplaceAll\n\nПовертає копію вхідного рядка, замінюючи збіг регулярного виразу на рядок заміни `replacement`. У рядку заміни знаки `$` інтерпретуються як в Expand, тому, наприклад, `$1` представляє текст першого збігу.\n\n```yaml\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\nПоверне `-W-xxW-`.\n\n`regexReplaceAll` викликає паніку у разі проблеми, а `mustRegexReplaceAll` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\nПовертає копію вхідного рядка, замінюючи збіг регулярного виразу на рядок заміни `replacement`. Рядок заміни підставляється без використання Expand.\n\n```yaml\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\nПоверне `-${1}-${1}-`.\n\n`regexReplaceAllLiteral` викликає паніку у разі проблеми, а `mustRegexReplaceAllLiteral` поверне помилку у рушії шаблонів у разі проблеми.\n\n### regexSplit, mustRegexSplit\n\nРозбиває вхідний рядок на підрядки, розділені виразом, і повертає зріз підрядків між збігами цього виразу. Останній параметр `n` визначає кількість підрядків для повернення, де `-1` означає повернути всі збіги.\n\n```yaml\nregexSplit \"z+\" \"pizza\" -1\n```\n\nПоверне `[pi a]`.\n\n`regexSplit` викликає паніку у разі проблеми, а `mustRegexSplit` поверне помилку у рушії шаблонів у разі проблеми.\n\n## Функції криптографії та безпеки {#cryptographic-and-security-functions}\n\nHelm надає декілька розширених криптографічних функцій, серед яких: [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [sha1sum](#sha1sum), та [sha256sum](#sha256sum).\n\n### sha1sum\n\nФункція `sha1sum` отримує рядок і обчислює його SHA1-дайджест.\n\n```yaml\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\nФункція `sha256sum` отримує рядок і обчислює його SHA256-дайджест.\n\n```yaml\nsha256sum \"Hello world!\"\n```\n\nЦе обчислює SHA 256 контрольну суму у форматі \"ASCII armored\", який є безпечним для друку.\n\n### adler32sum\n\nФункція `adler32sum` отримує рядок і обчислює його контрольну суму Adler-32.\n\n```yaml\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\nФункція `htpasswd` приймає `username` і `password` та генерує `bcrypt` хеш паролю. Результат може бути використаний для базової автентифікації на [Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic).\n\n```yaml\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nЗверніть увагу, що небезпечно зберігати пароль безпосередньо в шаблоні.\n\n### derivePassword\n\nФункція `derivePassword` може бути використана для виведення певного пароля на основі деяких спільних \"основних\" обмежень пароля. Алгоритм для цього добре [описаний](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf).\n\n```yaml\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nЗверніть увагу, що небезпечно зберігати частини безпосередньо в шаблоні.\n\n### genPrivateKey\n\nФункція `genPrivateKey` генерує новий приватний ключ, закодований у PEM-блок.\n\nВона приймає одне з наступних значень для свого першого параметра:\n\n* `ecdsa`: Генерує ключ еліптичної кривої DSA (P256)\n* `dsa`: Генерує DSA ключ (L2048N256)\n* `rsa`: Генерує RSA 4096 ключ\n\n### buildCustomCert\n\nФункція `buildCustomCert` дозволяє налаштувати сертифікат.\n\nВона приймає наступні строкові параметри:\n\n* Сертифікат у форматі PEM, закодований у base64\n* Приватний ключ у форматі PEM, закодований у base64\n\nФункція повертає обʼєкт сертифіката з наступними атрибутами:\n\n* `Cert`: Сертифікат у форматі PEM\n* `Key`: Приватний ключ у форматі PEM\n\nПриклад:\n\n```yaml\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\nЗверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA.\n\n### genCA\n\nФункція `genCA` генерує новий самопідписний сертифікат x509 для центру сертифікацї.\n\nВона приймає наступні параметри:\n\n* Загальне імʼя субʼєкта (cn)\n* Термін дії сертифіката у днях\n\nФункція повертає обʼєкт з наступними атрибутами:\n\n* `Cert`: Сертифікат у форматі PEM\n* `Key`: Приватний ключ у форматі PEM\n\nПриклад:\n\n```yaml\n$ca := genCA \"foo-ca\" 365\n```\n\nЗверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA.\n\n### genSelfSignedCert\n\nФункція `genSelfSignedCert` генерує новий самопідписаний сертифікат x509.\n\nВона приймає наступні параметри:\n\n* Загальне імʼя субʼєкта (cn)\n* Необовʼязковий список IP-адрес; може бути nil\n* Необовʼязковий список альтернативних DNS-імен; може бути nil\n* Термін дії сертифіката у днях\n\nФункція повертає обʼєкт з наступними атрибутами:\n\n* `Cert`: Сертифікат у форматі PEM\n* `Key`: Приватний ключ у форматі PEM\n\nПриклад:\n\n```yaml\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\nФункція `genSignedCert` генерує новий сертифікат x509, підписаний зазначеним CA.\n\nВона приймає наступні параметри:\n\n* Спільне імʼя субʼєкта (cn)\n* Необовʼязковий список IP-адрес; може бути nil\n* Необовʼязковий список альтернативних DNS-імен; може бути nil\n* Термін дії сертифіката у днях\n* CA (див. `genCA`)\n\nПриклад:\n\n```yaml\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\nФункція `encryptAES` шифрує текст за допомогою AES-256 CBC і повертає рядок, закодований у base64.\n\n```yaml\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\nФункція `decryptAES` отримує рядок у форматі base64, закодований за допомогою алгоритму AES-256 CBC, і повертає розкодований текст.\n\n```yaml\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Функції дати {#date-functions}\n\nHelm включає наступні функції дати, які ви можете використовувати в шаблонах: [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).\n\n### now\n\nПоточна дата/час. Використовуйте це разом з іншими функціями дати.\n\n### ago\n\nФункція `ago` повертає тривалість від часу. Зараз у секундах.\n\n```none\nago .CreatedAt\n```\n\nповертає у форматі `time.Duration` String()\n\n```none\n2h34m7s\n```\n\n### date\n\nФункція `date` форматує дату.\n\nФормат дати до РІК-МІСЯЦЬ-ДЕНЬ:\n\n```none\nnow | date \"2006-01-02\"\n```\n\nФорматування дати в Go [дещо відрізняється](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\nКоротко, візьміть цю базову дату:\n\n```none\nMon Jan 2 15:04:05 MST 2006\n```\n\nЗапишіть її у потрібному форматі. Вище, `2006-01-02` — це та ж дата, але в потрібному форматі.\n\n### dateInZone\n\nТе ж саме, що і `date`, але з часовою зоною.\n\n```none\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\nФорматує задану кількість секунд як `time.Duration`.\n\nЦе повертає 1m35s\n\n```none\nduration \"95\"\n```\n\n### durationRound\n\nОкруглює задану тривалість до найзначнішої одиниці. Рядки та `time.Duration` аналізуються як тривалість, тоді як `time.Time` обчислюється як тривалість з моменту.\n\nЦе повертає 2h\n\n```none\ndurationRound \"2h10m5s\"\n```\n\nЦе повертає 3mo\n\n```none\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\nПовертає кількість секунд з unix-епохи для `time.Time`.\n\n```none\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\nФункція `dateModify` приймає модифікацію та дату і повертає часову мітку.\n\nВідніміть годину і тридцять хвилин від поточного часу:\n\n```none\nnow | dateModify \"-1.5h\"\n```\n\nЯкщо формат модифікації неправильний, `dateModify` поверне дату немодифікованою. `mustDateModify` поверне помилку в іншому випадку.\n\n### htmlDate\n\nФункція `htmlDate` форматує дату для вставки в поле введення дати в HTML.\n\n```none\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nТе ж саме, що і htmlDate, але з часовою зоною.\n\n```none\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\nФункція `toDate` перетворює рядок у дату. Перший аргумент — це макет дати, а другий — рядок дати. Якщо рядок не можна перетворити, він поверне нульове значення. `mustToDate` поверне помилку в разі, якщо рядок не можна перетворити.\n\nЦе корисно, коли ви хочете перетворити дату-рядок в інший формат (використовуючи конвеєр). Нижче наведений приклад перетворює \"2017-12-31\" на \"31/12/2017\".\n\n```none\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Словники та функції словників {#dictionaries-and-dict-functions}\n\nHelm надає тип зберігання ключ/значення, який називається `dict` (скорочено від \"dictionary\" [\"словник\"], як у Python). `dict` є _невпорядкованим_ типом.\n\nКлюч у словнику **має бути рядком**. Однак значення може бути будь-якого типу, навіть іншим `dict` або `list`.\n\nНа відміну від `list`, `dict` не є незмінним. Функції `set` та `unset` змінюють вміст словника.\n\nHelm надає такі функції для роботи зі словниками: [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).\n\n### dict\n\nСтворення словників здійснюється шляхом виклику функції `dict` і передачі їй списку пар.\n\nНаступний приклад створює словник з трьома елементами:\n\n```none\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nЗа наявності map і ключа отримає значення з map.\n\n```none\nget $myDict \"name1\"\n```\n\nНаведений вище приклад поверне `\"value1\"`.\n\nЗверніть увагу, що якщо ключ не знайдено, ця операція просто поверне `\"\"`. Помилка не буде згенерована.\n\n### set\n\nВикористовуйте `set`, щоб додати нову пару ключ/значення до словника.\n\n```none\n$_ := set $myDict \"name4\" \"value4\"\n```\n\nЗверніть увагу, що `set` _повертає словник_ (вимога функцій шаблону Go), тому вам може знадобитися захопити значення, як це зроблено вище за допомогою присвоєння `$_`.\n\n### unset\n\nЗа наявності map і ключа видалить ключ з map.\n\n```none\n$_ := unset $myDict \"name4\"\n```\n\nЯк і у випадку з `set`, це повертає словник.\n\nЗверніть увагу, що якщо ключ не знайдено, ця операція просто повернеться. Помилка не буде згенерована.\n\n### hasKey\n\nФункція `hasKey` повертає `true`, якщо даний словник містить даний ключ.\n\n```none\nhasKey $myDict \"name1\"\n```\n\nЯкщо ключ не знайдено, це повертає `false`.\n\n### pluck\n\nФункція `pluck` дозволяє вказати один ключ і кілька map, і отримати список усіх знайдених збігів:\n\n```none\npluck \"name1\" $myDict $myOtherDict\n```\n\nНаведений вище приклад поверне `list`, що містить усі знайдені значення (`[value1 otherValue1]`).\n\nЯкщо даний ключ _не знайдено_ в map, цей map не буде мати елемента у списку (і довжина повернутого списку буде меншою, ніж кількість словників у виклику `pluck`).\n\nЯкщо ключ _знайдено_, але значення є порожнім, це значення буде вставлено.\n\nПоширеною ідіомою у шаблонах Helm є використання `pluck... | first`, щоб отримати перший відповідний ключ із колекції словників.\n\n### dig\n\nФункція `dig` проходить через вкладені набори словників, вибираючи ключі зі списку значень. Вона повертає стандартне значення, якщо будь-який з ключів не знайдено в асоційованому словнику.\n\n```none\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\nЗа наявності словника, структурованого таким чином:\n\n```none\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\nнаведений вище приклад поверне `\"curator\"`. Якщо у словнику навіть не було поля `user`, результатом буде `\"guest\"`.\n\n`dig` може бути дуже корисним у випадках, коли ви хочете уникнути охоронних конструкцій, особливо тому, що `and` у пакеті шаблонів Go не є скороченим. Наприклад, `and a.maybeNil a.maybeNil.iNeedThis` завжди буде оцінювати `a.maybeNil.iNeedThis` і викличе паніку, якщо у `a` відсутнє поле `maybeNil`.\n\n`dig` приймає свій аргумент словника останнім, щоб підтримувати конвеєрну обробку. Наприклад:\n\n```none\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\nОбʼєднує два або більше словників в один, надаючи перевагу словнику призначення:\n\nНаприклад:\n\n```yaml\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nрезультатом буде:\n\n```yaml\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n\n```none\n$newdict := merge $dest $source1 $source2\n```\n\nЦе операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад,\n\n```none\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` поверне помилку в разі невдалого обʼєднання.\n\n### mergeOverwrite, mustMergeOverwrite {#mergeoverwrite-mustmergeoverwrite}\n\nОбʼєднує два або більше словників в один, надаючи перевагу з **права наліво**, ефективно перезаписуючи значення в словнику призначення:\n\nНаприклад:\n\n```yaml\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nрезультатом буде:\n\n```yaml\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```none\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nЦе операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад,\n\n```none\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` поверне помилку в разі невдалого обʼєднання.\n\n### keys\n\nФункція `keys` повертає `list` усіх ключів одного або декількох типів `dict`. Оскільки словник є _невпорядкованим_, ключі не будуть у передбачуваному порядку. Їх можна відсортувати за допомогою `sortAlpha`.\n\n```none\nkeys $myDict | sortAlpha\n```\n\nПри поданні кількох словників ключі будуть обʼєднані. Використовуйте функцію `uniq` разом із `sortAlpha`, щоб отримати унікальний, відсортований список ключів.\n\n```none\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\nФункція `pick` вибирає тільки зазначені ключі зі словника, створюючи новий `dict`.\n\n```none\n$new := pick $myDict \"name1\" \"name2\"\n```\n\nНаведений вище приклад поверне `{name1: value1, name2: value2}`.\n\n### omit\n\nФункція `omit` схожа на `pick`, за винятком того, що вона повертає новий `dict` з усіма ключами, які _не_ збігаються з даними ключами.\n\n```none\n$new := omit $myDict \"name1\" \"name3\"\n```\n\nНаведений вище приклад поверне `{name2: value2}`.\n\n### values\n\nФункція `values` схожа на `keys`, за винятком того, що вона повертає новий `list` з усіма значеннями вихідного `dict` (підтримується тільки один словник).\n\n```none\n$vals := values $myDict\n```\n\nНаведений вище приклад поверне `list[\"value1\", \"value2\", \"value 3\"]`. Зверніть увагу, що функція `values` не дає жодних гарантій щодо порядку результатів; якщо це важливо, використовуйте `sortAlpha`.\n\n### deepCopy, mustDeepCopy\n\nФункції `deepCopy` і `mustDeepCopy` приймають значення і роблять глибоку копію цього значення. Це включає словники та інші структури. `deepCopy` викликає паніку, коли виникає проблема, тоді як `mustDeepCopy` повертає помилку системі шаблонів, коли виникає помилка.\n\n```none\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### Примітка про внутрішню структуру Dict {#a-note-on-dict-internals}\n\n`dict` реалізовано в Go як `map[string]interface{}`. Розробники Go можуть передавати значення `map[string]interface{}` у контекст, щоб зробити їх доступними для шаблонів як `dict`.\n\n## Функції кодування {#encoding-functions}\n\nHelm має такі функції для кодування та декодування:\n\n* `b64enc`/`b64dec`: Кодування або декодування з використанням Base64\n* `b32enc`/`b32dec`: Кодування або декодування з використанням Base32\n\n## Списки та функції для роботи зі списками {#lists-and-list-functions}\n\nHelm надає простий тип `list`, який може містити довільні послідовні дані. Це схоже на масиви або зрізи, але списки призначені для використання як незмінні типи даних.\n\nСтворення списку цілих чисел:\n\n```none\n$myList := list 1 2 3 4 5\n```\n\nЦе створить список `[1 2 3 4 5]`.\n\nHelm надає наступні функції для роботи зі списками: [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).\n\n### first, mustFirst\n\nЩоб отримати перший елемент списку, використовуйте `first`.\n\n`first $myList` повертає `1`.\n\n`first` викликає panic у разі проблеми, тоді як `mustFirst` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### rest, mustRest\n\nЩоб отримати залишок списку (все, окрім першого елемента), використовуйте `rest`.\n\n`rest $myList` повертає `[2 3 4 5]`.\n\n`rest` викликає panic у разі проблеми, тоді як `mustRest` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### last, mustLast\n\nЩоб отримати останній елемент списку, використовуйте `last`:\n\n`last $myList` повертає `5`. Це аналогічно до реверсування списку та виклику `first`.\n\n### initial, mustInitial\n\nЦя функція доповнює `last`, повертаючи всі елементи, окрім останнього. `initial $myList` повертає `[1 2 3 4]`.\n\n`initial` викликає panic у разі проблеми, тоді як `mustInitial` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### append, mustAppend\n\nДодає новий елемент до існуючого списку, створюючи новий список.\n\n```none\n$new = append $myList 6\n```\n\nЦе встановлює `$new` до `[1 2 3 4 5 6]`. `$myList` залишається незмінним.\n\n`append` викликає panic у разі проблеми, тоді як `mustAppend` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### prepend, mustPrepend\n\nДодає елемент на початок списку, створюючи новий список.\n\n```none\nprepend $myList 0\n```\n\nЦе створить `[0 1 2 3 4 5]`. `$myList` залишається незмінним.\n\n`prepend` викликає panic у разі проблеми, тоді як `mustPrepend` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### concat\n\nОбʼєднує довільну кількість списків в один.\n\n```none\nconcat $myList (list 6 7) (list 8)\n```\n\nЦе створить `[1 2 3 4 5 6 7 8]`. `$myList` залишається незмінним.\n\n### reverse, mustReverse\n\nСтворює новий список з елементами у зворотному порядку.\n\n```none\nreverse $myList\n```\n\nЦе генерує список `[5 4 3 2 1]`.\n\n`reverse` викликає panic у разі проблеми, тоді як `mustReverse` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### uniq, mustUniq\n\nСтворює список без дублікатів.\n\n```none\nlist 1 1 1 2 | uniq\n```\n\nЦе створить `[1 2]`.\n\n`uniq` викликає panic у разі проблеми, тоді як `mustUniq` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### without, mustWithout\n\nФункція `without` видаляє елементи зі списку.\n\n```none\nwithout $myList 3\n```\n\nЦе створить `[1 2 4 5]`.\n\n`without` може приймати більше одного фільтра:\n\n```none\nwithout $myList 1 3 5\n```\n\nЦе створить `[2 4]`.\n\n`without` викликає panic у разі проблеми, тоді як `mustWithout` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### has, mustHas\n\nПеревіряє, чи містить список певний елемент.\n\n```none\nhas 4 $myList\n```\n\nЦе поверне `true`, а `has \"hello\" $myList` поверне `false`.\n\n`has` викликає panic у разі проблеми, тоді як `mustHas` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### compact, mustCompact\n\nПриймає список та видаляє елементи з пустими значеннями.\n\n```none\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` поверне новий список з видаленим пустим (тобто \"\") елементом.\n\n`compact` викликає panic у разі проблеми, тоді як `mustCompact` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### index\n\nЩоб отримати n-й елемент списку, використовуйте `index list [n]`. Щоб отримати\nелемент у багатовимірних списках, використовуйте `index list [n] [m] ...`.\n\n* `index $myList 0` повертає `1`. Це те саме, що і `myList[0]`.\n* `index $myList 0 1` повертає той самий результат, що і `myList[0][1]`.\n\n### slice, mustSlice\n\nЩоб отримати часткові елементи списку, використовуйте `slice list [n] [m]`. Це еквівалентно до `list[n:m]`.\n\n* `slice $myList` повертає `[1 2 3 4 5]`. Це те саме, що і `myList[:]`.\n* `slice $myList 3` повертає `[4 5]`. Це те саме, що і `myList[3:]`.\n* `slice $myList 1 3` повертає `[2 3]`. Це те саме, що і `myList[1:3]`.\n* `slice $myList 0 3` повертає `[1 2 3]`. Це те саме, що і `myList[:3]`.\n\n`slice` викликає panic у разі проблеми, тоді як `mustSlice` повертає помилку в рушій шаблонів, якщо виникає проблема.\n\n### until\n\nФункція `until` створює діапазон цілих чисел.\n\n```none\nuntil 5\n```\n\nЦе генерує список `[0, 1, 2, 3, 4]`.\n\nЦе корисно для циклів з `range $i, $e := until 5`.\n\n### untilStep\n\nЯк і `until`, функція `untilStep` створює список рахуючих цілих чисел. Але вона дозволяє визначити початок, кінець та крок:\n\n```none\nuntilStep 3 6 2\n```\n\nЦе створить `[3 5]`, починаючи з 3 та додаючи 2, поки не буде досягнуто або перевищено 6. Це схоже на функцію `range` в Python.\n\n### seq\n\nПрацює як команда `seq` у bash.\n\n* 1 параметр (end) — генерує всі рахуючі цілі числа між 1 та `end` включно.\n* 2 параметри (start, end) — генерує всі рахуючі цілі числа між `start` та `end` включно, збільшуючи або зменшуючи на 1.\n* 3 параметри (start, step, end) — генерує всі рахуючі цілі числа між `start` та `end` включно, збільшуючи або зменшуючи на `step`.\n\n```none\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n## Математичні функції {#math-functions}\n\nУсі математичні функції працюють із значеннями типу `int64`, якщо не зазначено інше.\n\nДоступні наступні математичні функції: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round) та [sub](#sub).\n\n### add\n\nДодавайте числа за допомогою `add`. Приймає два або більше аргументів.\n\n```none\nadd 1 2 3\n```\n\n### add1\n\nЩоб збільшити на 1, використовуйте `add1`.\n\n### sub\n\nЩоб відняти, використовуйте `sub`.\n\n### div\n\nВиконуйте цілочисельне ділення за допомогою `div`.\n\n### mod\n\nЗалишок від ділення можна отримати за допомогою `mod`.\n\n### mul\n\nМножте за допомогою `mul`. Приймає два або більше аргументів.\n\n```none\nmul 1 2 3\n```\n\n### max\n\nПовертає найбільше із серії цілих чисел.\n\nЦе поверне `3`:\n\n```none\nmax 1 2 3\n```\n\n### min\n\nПовертає найменше із серії цілих чисел.\n\n`min 1 2 3` поверне `1`.\n\n### len\n\nПовертає довжину аргументу у вигляді цілого числа.\n\n```none\nlen .Arg\n```\n\n## Математичні функції з плаваючою комою {#float-math-functions}\n\nУсі математичні функції працюють із значеннями типу `float64`.\n\n### addf\n\nДодавайте числа за допомогою `addf`.\n\nЦе поверне `5.5`:\n\n```none\naddf 1.5 2 2\n```\n\n### add1f\n\nЩоб збільшити на 1, використовуйте `add1f`.\n\n### subf\n\nЩоб відняти, використовуйте `subf`.\n\nЦе еквівалентно `7.5 - 2 - 3` і поверне `2.5`:\n\n```none\nsubf 7.5 2 3\n```\n\n### divf\n\nВиконуйте ділення з плаваючою комою за допомогою `divf`.\n\nЦе еквівалентно `10 / 2 / 4` і поверне `1.25`:\n\n```none\ndivf 10 2 4\n```\n\n### mulf\n\nМножте за допомогою `mulf`.\n\nЦе поверне `6`:\n\n```none\nmulf 1.5 2 2\n```\n\n### maxf\n\nПовертає найбільше із серії чисел з плаваючою комою:\n\nЦе поверне `3`:\n\n```none\nmaxf 1 2.5 3\n```\n\n### minf\n\nПовертає найменше із серії чисел з плаваючою комою.\n\nЦе поверне `1.5`:\n\n```none\nminf 1.5 2 3\n```\n\n### floor\n\nПовертає найбільше число з плаваючою комою, яке менше або рівне вхідному значенню.\n\n`floor 123.9999` поверне `123.0`.\n\n### ceil\n\nПовертає найбільше число з плаваючою комою, яке більше або рівне вхідному значенню.\n\n`ceil 123.001` поверне `124.0`.\n\n### round\n\nПовертає число з плаваючою комою з округленим залишком до зазначеної кількості цифр\nпісля десяткової крапки.\n\n`round 123.555555 3` поверне `123.556`.\n\n## Мережеві функції {#network-functions}\n\nHelm має одну мережеву функцію, `getHostByName`.\n\nФункція `getHostByName` приймає доменне імʼя і повертає IP-адресу.\n\n`getHostByName \"www.google.com\"` поверне відповідну IP-адресу для `www.google.com`.\n\n## Функції роботи з шляхами до файлів {#file-path-functions}\n\nХоча функції шаблонів Helm не надають доступ до файлової системи, вони забезпечують функції для роботи з рядками, які відповідають конвенціям шляхів до файлів. До них відносяться [base](#base), [clean](#clean), [dir](#dir), [ext](#ext) та [isAbs](#isabs).\n\n### base\n\nПовертає останній елемент шляху.\n\n```none\nbase \"foo/bar/baz\"\n```\n\nВищезазначене поверне \"baz\".\n\n### dir\n\nПовертає теку, видаляючи останню частину шляху. Отже, `dir \"foo/bar/baz\"` повертає `foo/bar`.\n\n### clean\n\nОчищує шлях.\n\n```none\nclean \"foo/bar/../baz\"\n```\n\nВищезазначене знаходить `..` і повертає `foo/baz`.\n\n### ext\n\nПовертає розширення файлу.\n\n```none\next \"foo.bar\"\n```\n\nВищезазначене поверне `.bar`.\n\n### isAbs\n\nЩоб перевірити, чи є шлях до файлу абсолютним, використовуйте `isAbs`.\n\n## Функції аналізу {#reflection-functions}\n\nHelm надає базові інструменти аналізу. Це допомагає розробникам шаблонів зрозуміти основну інформацію про типи Go для конкретного значення. Helm написано на Go і він має строгий типізований підхід. Система типів застосовується всередині шаблонів.\n\nGo має кілька примітивів _видів (kind)_, таких як `string`, `slice`, `int64` і `bool`.\n\nGo має відкриту систему _типів_, яка дозволяє розробникам створювати власні типи.\n\nHelm надає набір функцій для кожного з них через [функції kind](#kind-functions) і [функції type](#type-functions). Також надана функція [deepEqual](#deepequal) для порівняння значень.\n\n### Функції kind {#kind-functions}\n\nЄ дві функції видів: `kindOf` повертає вид обʼєкта.\n\n```none\nkindOf \"hello\"\n```\n\nВищезазначене поверне `string`. Для простих тестів (наприклад, у блоці `if`), функція `kindIs` дозволяє перевірити, що значення має певний вид:\n\n```none\nkindIs \"int\" 123\n```\n\nВищезазначене поверне `true`.\n\n### Функції type {#type-functions}\n\nТипи трохи складніше обробляти, тому є три різні функції:\n\n* `typeOf` повертає основний тип значення: `typeOf $foo`\n* `typeIs` подібна до `kindIs`, але для типів: `typeIs \"*io.Buffer\" $myVal`\n* `typeIsLike` працює як `typeIs`, але також розіменовує покажчики\n\n**Примітка:** Жодна з цих функцій не може перевірити, чи реалізує щось певний інтерфейс, оскільки це вимагало б компіляції інтерфейсу заздалегідь.\n\n### deepEqual\n\n`deepEqual` повертає `true`, якщо два значення є [\"глибоко рівними\"](https://golang.org/pkg/reflect/#DeepEqual).\n\nПрацює і для типів непримітивів (в порівнянні з вбудованим `eq`).\n\n```none\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\nВищезазначене поверне `true`.\n\n## Функції семантичного версіонування {#semantic-version-functions}\n\nДеякі схеми версій легко розпізнати та порівнювати. Helm надає функції для роботи з версіями [SemVer 2](http://semver.org). До них відносяться [semver](#semver) і [semverCompare](#semvercompare). Нижче ви також знайдете деталі про використання діапазонів для порівнянь.\n\n### semver\n\nФункція `semver` розбирає рядок у семантичну версію:\n\n```none\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_Якщо синтаксичний аналізатор не спрацює, виконання шаблону буде зупинено з помилкою._\n\nНа цьому етапі `$version` є покажчиком на обʼєкт `Version` з наступними властивостями:\n\n* `$version.Major`: Основний номер (`1` вище)\n* `$version.Minor`: Мінорний номер (`2` вище)\n* `$version.Patch`: Номер патчу (`3` вище)\n* `$version.Prerelease`: Пре-реліз (`alpha.1` вище)\n* `$version.Metadata`: Метадані збірки (`123` вище)\n* `$version.Original`: Оригінальна версія у вигляді рядка\n\nКрім того, ви можете порівнювати `Version` з іншою версією, використовуючи функцію `Compare`:\n\n```none\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\nВищезазначене поверне `-1`.\n\nЗначення повернення такі:\n\n* `-1`, якщо дана версія SemVer більша за версію, метод `Compare` якої був викликаний\n* `1`, якщо версія, для якої була викликана функція `Compare`, більша\n* `0`, якщо версії однакові\n\n(Зверніть увагу, що в SemVer поле `Metadata` не порівнюється під час операцій порівняння версій.)\n\n### semverCompare\n\nБільш надійна функція порівняння надається як `semverCompare`. Ця версія підтримує діапазони версій:\n\n* `semverCompare \"1.2.3\" \"1.2.3\"` перевіряє на точний збіг\n* `semverCompare \"~1.2.0\" \"1.2.3\"` перевіряє, що основні та мінорні версії збігаються, і що номер патчу другої версії _більший або рівний_ першому параметру.\n\nФункції SemVer використовують бібліотеку [Masterminds semver](https://github.com/Masterminds/semver), від творців Sprig.\n\n### Основні порівняння {#basic-comparisons}\n\nЄ два елементи порівнянь. По-перше, рядок порівняння є списком порівнянь з AND, розділених пробілом або комою. Ці порівняння потім розділяються операцією || (OR). Наприклад, `\">= 1.2 < 3.0.0 || >= 4.2.3\"` шукає порівняння, яке більше або дорівнює 1.2 і менше 3.0.0 або більше або дорівнює 4.2.3.\n\nОсновні порівняння:\n\n* `=`: рівно (аналогічно відсутності оператора)\n* `!=`: не рівно\n* `>`: більше ніж\n* `<`: менше ніж\n* `>=`: більше або рівно\n* `<=`: менше або рівно\n\n### Робота з версіями пре-релізів {#working-with-prerelease-versions}\n\nПре-релізи, для тих, хто не знайомий з ними, використовуються для випусків програмного забезпечення до стабільних або загальнодоступних випусків. Прикладами пре-релізів є розробка, альфа, бета та реліз-кандидат. Пре-реліз може бути версією, наприклад, `1.2.3-beta.1`, в той час як стабільний реліз буде `1.2.3`. За порядком пріоритету пре-релізи йдуть перед їх повʼязаними релізами. У цьому прикладі `1.2.3-beta.1 < 1.2.3`.\n\nЗгідно з специфікацією Semantic Version, пре-релізи можуть не відповідати API сумісності зі своїм релізом. Вона говорить,\n\n> Версія пре-релізу вказує, що версія нестабільна і може не відповідати запланованим вимогам сумісності, як зазначено у відповідній нормальній версії.\n\nПорівняння SemVer з використанням обмежень без компаратора пре-релізу пропустять пре-релізи. Наприклад, `>=1.2.3` пропустить пре-релізи при перегляді списку релізів, тоді як `>=1.2.3-0` буде оцінювати і знаходити пре-релізи.\n\nПричина для `0` як версії пре-релізу у прикладі порівняння полягає в тому, що пре-релізи можуть містити лише ASCII числа, літери та дефіси (разом з роздільниками `.`), згідно з специфікацією. Сортування відбувається в ASCII порядку сортування, згідно з специфікацією. Найнижчий символ — це `0` в ASCII порядку сортування (див. [ASCII Таблицю](http://www.asciitable.com/)).\n\nРозуміння ASCII порядку сортування важливе, оскільки A-Z йде перед a-z. Це означає, що `>=1.2.3-BETA` поверне `1.2.3-alpha`. Те, що ви могли б очікувати від чутливості до регістру, тут не застосовується. Це через ASCII порядок сортування, який зазначено у специфікації.\n\n### Порівняння діапазонів з дефісами {#hyphen-range-comparisons}\n\nЄ кілька методів обробки діапазонів, і перший — діапазони з дефісами. Вони виглядають так:\n\n* `1.2 - 1.4.5`, що еквівалентно `>= 1.2 <= 1.4.5`\n* `2.3.4 - 4.5`, що еквівалентно `>= 2.3.4 <= 4.5`\n\n### Підстановочні символи в порівняннях {#wildcard-in-comparisons}\n\nСимволи `x`, `X` та `*` можуть використовуватися як символи заміщення. Це працює для всіх операторів порівняння. Коли використовується з оператором `=`, він переходить до порівняння рівня патчу (див. тильду нижче). Наприклад,\n\n* `1.2.x` еквівалентно `>= 1.2.0, < 1.3.0`\n* `>= 1.2.x` еквівалентно `>= 1.2.0`\n* `<= 2.x` еквівалентно `< 3`\n* `*` еквівалентно `>= 0.0.0`\n\n### Порівняння діапазонів з тильдою (patch) {#tilde-range-comparisons-patch}\n\nОператор порівняння тильди (`~`) використовується для діапазонів рівня патчу, коли вказана мінорна версія, і для змін на рівні основної версії, коли мінорний номер відсутній. Наприклад,\n\n* `~1.2.3` еквівалентно `>= 1.2.3, < 1.3.0`\n* `~1` еквівалентно `>= 1, < 2`\n* `~2.3` еквівалентно `>= 2.3, < 2.4`\n* `~1.2.x` еквівалентно `>= 1.2.0, < 1.3.0`\n* `~1.x` еквівалентно `>= 1, < 2`\n\n### Порівняння діапазонів з кареткою (major) {#caret-range-comparisons-major}\n\nОператор порівняння каретки (`^`) використовується для змін на рівні основної версії після випуску стабільної (1.0.0) версії. До випуску 1.0.0 мінорні версії діють як рівень стабільності API. Це корисно при порівнянні версій API, оскільки велика зміна є порушенням API. Наприклад,\n\n* `^1.2.3` еквівалентно `>= 1.2.3, < 2.0.0`\n* `^1.2.x` еквівалентно `>= 1.2.0, < 2.0.0`\n* `^2.3` еквівалентно `>= 2.3, < 3`\n* `^2.x` еквівалентно `>= 2.0.0, < 3`\n* `^0.2.3` еквівалентно `>=0.2.3 <0.3.0`\n* `^0.2` еквівалентно `>=0.2.0 <0.3.0`\n* `^0.0.3` еквівалентно `>=0.0.3 <0.0.4`\n* `^0.0` еквівалентно `>=0.0.0 <0.1.0`\n* `^0` еквівалентно `>=0.0.0 <1.0.0`\n\n## Функції URL {#url-functions}\n\nHelm включає функції [urlParse](#urlparse), [urlJoin](#urljoin) і [urlquery](#urlquery), які дозволяють працювати з частинами URL.\n\n### urlParse\n\nРозбирає рядок для URL і створює словник з частинами URL\n\n```none\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\nВищезазначене повертає словник, що містить обʼєкт URL:\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nЦе реалізовано за допомогою пакетів URL з стандартної бібліотеки Go. Для отримання додаткової інформації перевірте https://golang.org/pkg/net/url/#URL\n\n### urlJoin\n\nОбʼєднує словник (створений за допомогою `urlParse`) для створення рядка URL\n\n```none\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\nВищезазначене поверне наступний рядок:\n\n```none\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nПовертає екрановану версію значення, переданого як аргумент, так що воно підходить для вбудовування в частину запиту URL.\n\n```none\n$var := urlquery \"string for query\"\n```\n\n## Функції UUID {#uuid-functions}\n\nHelm може генерувати UUID v4, унікальні ідентифікатори.\n\n```none\nuuidv4\n```\n\nВищезазначене повертає новий UUID типу v4 (згенерований випадковим чином).\n\n## Функції Kubernetes і Chart {#kubernetes-and-chart-functions}\n\nHelm включає функції для роботи з Kubernetes, зокрема [`.Capabilities.APIVersions.Has`](#capabilitiesapiversionshas), [Files](#file-functions) та [lookup](#lookup).\n\n### lookup\n\n`lookup` використовується для пошуку ресурсу в працюючому кластері. При використанні з командою `helm template` він завжди повертає порожній результат.\n\nБільше деталей можна знайти в [документації по функції lookup](/chart_template_guide/functions_and_pipelines.md#using-the-lookup-function).\n\n### .Capabilities.APIVersions.Has\n\nПовертає, чи доступна API-версія або ресурс у кластері.\n\n```none\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\nБільше інформації доступно в [документації по вбудованих обʼєктах](/chart_template_guide/builtin_objects.md).\n\n### Функції файлів {#file-functions}\n\nЄ кілька функцій, які дозволяють отримати доступ до не-спеціальних файлів всередині chart. Наприклад, для доступу до конфігураційних файлів програми. Ці функції документовані в [Доступ до файлів всередині шаблонів](/chart_template_guide/accessing_files.md).\n\n_Зверніть увагу, що документація для багатьох з цих функцій надходить з [Sprig](https://github.com/Masterminds/sprig). Sprig — це бібліотека функцій шаблонів, доступна для застосунків на Go._\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: Функції шаблонів та конвеєри\ndescription: Використання функцій у шаблонах.\nsidebar_position: 5\n---\n\nДотепер ми бачили, як розміщувати інформацію в шаблоні. Але ця інформація розміщується в шаблоні без змін. Іноді ми хочемо перетворити надані дані таким чином, щоб вони були більш корисними для нас.\n\nПочнемо з найкращої практики: коли вставляємо рядки з об’єкта `.Values` у шаблон, ми повинні обов’язково обгорнути ці рядки в лапки. Ми можемо зробити це, викликавши функцію `quote` в директиві шаблону:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nФункції шаблонів дотримуються синтаксису `functionName arg1 arg2...`. У наведеному вище фрагменті `quote .Values.favorite.drink` викликає функцію `quote` і передає їй один аргумент.\n\nHelm має понад 60 доступних функцій. Деякі з них визначені [мовою шаблонів Go](https://godoc.org/text/template). Більшість інших є частиною [бібліотеки шаблонів Sprig](https://masterminds.github.io/sprig/). Ми побачимо багато з них у міру того, як будемо розглядати приклади.\n\n> Хоча ми говоримо про \"мову шаблонів Helm\", як про щось специфічне для Helm, насправді це комбінація мови шаблонів Go, деяких додаткових функцій і різноманітних обгорток, які дозволяють передавати певні обʼєкти в шаблони. Багато ресурсів про шаблони Go можуть бути корисними, коли ви вивчаєте шаблони.\n\n## Конвеєри {#pipelines}\n\nОднією з потужних функцій мови шаблонів є концепція _конвеєрів_. Запозичивши концепцію з UNIX, конвеєри є інструментом для обʼєднання серії команд шаблонів для компактного вираження низки перетворень. Іншими словами, конвеєри — це ефективний спосіб виконання кількох завдань послідовно. Перепишемо наведений вище приклад, використовуючи конвеєр.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nУ цьому прикладі замість виклику `quote ARGUMENT` ми інвертували порядок. Ми \"надіслали\" аргумент функції за допомогою конвеєра (`|`): `.Values.favorite.drink | quote`. Використовуючи конвеєри, ми можемо обʼєднати кілька функцій:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Інверсія порядку є поширеною практикою в шаблонах. Ви частіше побачите `.val | quote`, ніж `quote .val`. Обидві практики є правильними.\n\nПід час обробки цей шаблон створить такий результат:\n\n```yaml\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nЗверніть увагу, що наша початкова `pizza` тепер перетворилася на `\"PIZZA\"`.\n\nКоли аргументи передаються за допомогою конвеєра, результат першого обчислення (`.Values.favorite.drink`) надсилається як _останній аргумент функції_. Ми можемо змінити приклад із напоєм вище, щоб продемонструвати функцію, яка приймає два аргументи: `repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nФункція `repeat` буде повторювати даний рядок задану кількість разів, тому ми отримаємо такий вихідний результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Використання функції `default` {#using-the-default-function}\n\nОднією з функцій, яку часто використовують у шаблонах, є функція `default`: `default DEFAULT_VALUE GIVEN_VALUE`. Ця функція дозволяє вам вказати стандартне значення в шаблоні, у разі якщо значення відсутнє. Використаємо її, щоб змінити приклад з напоєм вище:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nЯкщо ми запустимо це як зазвичай, ми отримаємо наш `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nТепер ми видалимо параметр улюбленого напою з `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nТепер повторний запуск `helm install --dry-run --debug fair-worm ./mychart` створить такий YAML:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nВ реальній схемі всі статичні стандартні значення повинні зберігатися у файлі `values.yaml` і не повинні дублюватися за допомогою команди `default` (інакше вони будуть надлишковими). Однак команда `default` ідеально підходить для обчислюваних значень, які не можуть бути оголошені у файлі `values.yaml`. Наприклад:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nУ деяких випадках умова `if` може бути кращим рішенням, ніж `default`. Ми побачимо їх у наступному розділі.\n\nФункції та конвеєри шаблонів — це потужний спосіб перетворення інформації та її вставки у ваш YAML. Але іноді необхідно додати деяку логіку шаблонів, яка трохи складніша, ніж просто вставка рядка. У наступному розділі ми розглянемо структури керування, які надає мова шаблонів.\n\n## Використання функції `lookup` {#using-the-lookup-function}\n\nФункцію `lookup` можна використовувати для _пошуку_ ресурсів у працюючому кластері. Синопсис функції lookup — це `lookup apiVersion, kind, namespace, name -> resource or resource list`.\n\n| параметр | тип |\n|------------|--------|\n| apiVersion | string |\n| kind | string |\n| namespace | string |\n| name | string |\n\nОбидва параметри `name` та `namespace` є необов’язковими та можуть передаватися як порожній рядок (`\"\"`).\n\nМожливі такі комбінації параметрів:\n\n| Поведінка | Функція пошуку |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"` |\n| `kubectl get pods -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"` |\n| `kubectl get pods --all-namespaces` | `lookup \"v1\" \"Pod\" \"\" \"\"` |\n| `kubectl get namespace mynamespace` | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces` | `lookup \"v1\" \"Namespace\" \"\" \"\"` |\n\nКоли `lookup` повертає обʼєкт, він поверне словник. Цей словник може бути додатково досліджений для отримання конкретних значень.\n\nНаступний приклад поверне анотації, присутні для обʼєкта `mynamespace`:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nКоли `lookup` повертає список обʼєктів, можливо отримати доступ до списку обʼєктів через поле `items`:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* робимо щось з кожним сервісом */}}\n{{ end }}\n```\n\nКоли обʼєкт не знайдено, повертається порожнє значення. Це може бути використано для перевірки наявності обʼєкта.\n\nФункція `lookup` використовує поточну конфігурацію зʼєднання Kubernetes Helm для запиту до Kubernetes. Якщо при взаємодії з викликом сервера API виникає помилка (наприклад, через відсутність дозволу на доступ до ресурсу), обробка шаблонів Helm зазнає невдачі.\n\nМайте на увазі, що Helm не призначений для контакту з Kubernetes API Server під час операцій `helm template|install|upgrade|delete|rollback --dry-run`. Щоб протестувати `lookup` на працюючому кластера, слід використовувати `helm template|install|upgrade|delete|rollback --dry-run=server`, щоб дозволити з’єднання з кластером.\n\n## Оператори як функції {#operators-are-functions}\n\nДля шаблонів оператори (`eq`, `ne`, `lt`, `gt`, `and`, `or` і так далі) реалізовані як функції. У конвеєрах операції можуть бути згруповані дужками (`(` і `)`).\n\nТепер ми можемо перейти від функцій і конвеєрів до управління потоком з умовами, циклами та модифікаторами області видимості.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Початок роботи\ndescription: Короткий посібник з шаблонів чартів.\nsidebar_position: 2\n---\n\nУ цьому розділі посібника ми створимо чарт і додамо перший шаблон. Чарт, який ми створимо тут, буде використовуватися протягом усього цього посібника.\n\nЩоб розпочати, давайте коротко ознайомимося з чартом Helm.\n\n## Чарти {#charts}\n\nЯк описано в [Посібнику з чартів](/topics/charts.md), чарти Helm мають таку структуру:\n\n```none\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nТека `templates/` призначена для файлів шаблонів. Коли Helm обробляє чарт, він передає всі файли з теки`templates/` до механізму рендерингу шаблонів. Потім збирає результати цих шаблонів і передає їх до Kubernetes.\n\nФайл `values.yaml` також важливий для шаблонів. Цей файл містить _стандартні значення_ для чарту. Користувачі можуть перевизначити ці значення під час `helm install` або `helm upgrade`.\n\nФайл `Chart.yaml` містить опис чарту. Ви можете отримати до нього доступ із шаблону.\n\nТека `charts/` _може_ містити інші чарти (які ми називаємо _субчартами_). Пізніше в цьому посібнику ми побачимо, як вони працюють під час рендерингу шаблонів.\n\n## Стартовий чарт {#starter-chart}\n\nУ цьому посібнику ми створимо простий чарт з назвою `mychart`, а потім створимо кілька шаблонів всередині чарту.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### Швидкий огляд `mychart/templates/` {#quick-glimpse-of-mychart-templates}\n\nЯкщо ви поглянете на теку `mychart/templates/`, то помітите кілька файлів, які вже там є.\n\n- `NOTES.txt`: Вміст тексту довідки для вашого чарту. Його буде показана користувачам під час виконання `helm install`.\n- `deployment.yaml`: Основний маніфест для створення [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) у Kubernetes.\n- `service.yaml`: Основний маніфест для створення [точки доступу сервісу](https://kubernetes.io/docs/concepts/services-networking/service/) для вашого deployment.\n- `_helpers.tpl`: Місце для розміщення допоміжних шаблонів, які ви можете використовувати повторно по всьому чарту.\n\nІ що ми збираємося зробити, це… _видалити їх усі!_ Таким чином, ми зможемо працювати з нашим посібником з нуля. Ми фактично створимо власні `NOTES.txt` та `_helpers.tpl` під час роботи.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nКоли ви пишете чарти для операційної діяльності, мати базові версії цих чартів може бути дійсно корисно. Тож у повсякденному створенні чартів ви, ймовірно, не захочете їх видаляти.\n\n## Перший шаблон {#a-first-template}\n\nПерший шаблон, який ми збираємося створити, буде `ConfigMap`. У Kubernetes `ConfigMap` — це обʼєкт для зберігання конфігураційних даних. Інші речі, такі як podʼи, можуть отримувати доступ до даних у `ConfigMap`.\n\nОскільки `ConfigMap` є базовим ресурсом, він стане чудовою відправною точкою для нас.\n\nПочнемо зі створення файлу з назвою `mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**ПОРАДА:** Імена шаблонів не слідують жорсткому шаблону іменування. Проте ми рекомендуємо використовувати розширення `.yaml` для YAML-файлів та `.tpl` для допоміжних шаблонів.\n\nНаведений вище YAML-файл є мінімальною версією `ConfigMap`, що містить лише необхідні поля. Завдяки тому, що цей файл знаходиться в теці `mychart/templates/`, він буде переданий через механізм рендерингу шаблонів.\n\nМожна просто помістити звичайний YAML-файл, як цей, у теку `mychart/templates/`. Коли Helm читає цей шаблон, він просто передає його в Kubernetes у такому вигляді.\n\nЗа допомогою цього простого шаблону ми отримали чарт, який можна інсталювати. І ми можемо встановити його ось так:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nЗа допомогою Helm ми можемо отримати реліз і побачити фактичний шаблон, який був завантажений.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nКоманда `helm get manifest` приймає імʼя релізу (`full-coral`) і виводить усі ресурси Kubernetes, які були завантажені на сервер. Кожен файл починається з `---`, що вказує на початок YAML-документа, а потім слідує автоматично згенерований коментар, який повідомляє нам, який файл шаблону згенерував цей YAML-документ.\n\nЗ цього моменту ми можемо побачити, що YAML-дані саме такі, як ми їх розмістили у файлі `configmap.yaml`.\n\nТепер ми можемо видалити наш реліз: `helm uninstall full-coral`.\n\n### Додавання виклику простого шаблону {#adding-a-simple-template-call}\n\nЖорстке кодування поля `name:` у ресурсі зазвичай вважається поганою практикою. Імена повинні бути унікальними для кожного релізу. Тому ми можемо захотіти згенерувати поле імені, вставивши назву релізу.\n\n**ПОРАДА:** Поле `name:` обмежене 63 символами через обмеження системи DNS. З цієї причини імена релізів обмежені 53 символами. У Kubernetes версії 1.3 та раніше було обмежено лише 24 символами (тобто імена довжиною до 14 символів).\n\nЗмінимо файл `configmap.yaml` відповідно.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nОсновна зміна полягає в значенні поля `name:`, яке тепер має вигляд `{{ .Release.Name }}-configmap`.\n\n> Директива шаблону міститься у дужках `{{` та `}}`.\n\nДиректива шаблону `{{ .Release.Name }}` вставляє назву релізу в шаблон. Значення, які передаються в шаблон, можна вважати _обʼєктами з просторами імен_, де точка (`.`) розділяє кожен елемент простору імен.\n\nТочка перед `Release` вказує, що ми починаємо з найвищого простору імен для цієї області застосування (про область ми поговоримо трохи пізніше). Таким чином, ми могли б прочитати `Release.Name` як: \"почати з верхнього простору імен, знайти обʼєкт `Release`, а потім шукати всередині нього обʼєкт з назвою `Name`\".\n\nОбʼєкт `Release` є одним із вбудованих обʼєктів для Helm, і ми розглянемо його більш детально пізніше. Але поки достатньо сказати, що це покаже назву релізу, яку бібліотека присвоює нашому релізу.\n\nТепер, коли ми встановлюємо наш ресурс, ми одразу побачимо результат використання цієї директиви шаблону:\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nВи можете запустити `helm get manifest clunky-serval`, щоб побачити весь згенерований YAML.\n\nЗверніть увагу, що імʼя ConfigMap всередині Kubernetes тепер є `clunky-serval-configmap`, замість попереднього `mychart-configmap`.\n\nНа цьому етапі ми бачили шаблони в їх найпростішому вигляді: YAML-файли з вбудованими директивами шаблонів між `{{` та `}}`. У наступній частині ми глибше розглянемо шаблони. Але перед тим, як перейти далі, є один простий трюк, який може зробити створення шаблонів швидшим: коли ви хочете протестувати рендеринг шаблону, але насправді нічого не встановлювати, ви можете використати `helm install --debug --dry-run goodly-guppy ./mychart`. Це опрацює шаблони, але замість того, щоб встановити чарт, він поверне вам опрацьований шаблон, щоб ви могли побачити результат:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nВикористання `--dry-run` полегшить тестування вашого коду, але це не гарантує, що сам Kubernetes прийме згенеровані вами шаблони. Краще не припускати, що ваш чарт буде встановлений тільки тому, що `--dry-run` працює.\n\nУ [Посібнику з шаблонів чарту](/chart_template_guide/index.mdx) ми розглянемо базовий чарт, який ми визначили тут, і детально дослідимо мову шаблонів Helm. І ми почнемо з вбудованих обʼєктів.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: Файл .helmignore\ndescription: Файл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт.\nsidebar_position: 12\n---\n\nФайл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт.\n\nЯкщо цей файл існує, команда `helm package` ігноруватиме всі файли, які відповідають шаблону, зазначеному у файлі `.helmignore`, під час упаковки вашого застосунку.\n\nЦе може допомогти уникнути додавання непотрібних або конфіденційних файлів або тек у ваш Helm чарт.\n\nФайл `.helmignore` підтримує глобальний збіх Unix shell, відносний збіг шляхів та заперечення (з префіксом !). Розглядається лише один шаблон на рядок.\n\nОсь приклад файлу `.helmignore`:\n\n```none\n# коментар\n\n# Відповідає будь-якому файлу або шляху з імʼям .helmignore\n.helmignore\n\n# Відповідає будь-якому файлу або шляху з імʼям .git\n.git\n\n# Відповідає будь-якому текстовому файлу\n*.txt\n\n# Відповідає тільки текам з імʼям mydir\nmydir/\n\n# Відповідає тільки текстовим файлам на верхньому рівні теки\n/*.txt\n\n# Відповідає тільки файлу foo.txt на верхньому рівні теки\n/foo.txt\n\n# Відповідає будь-якому файлу з імʼям ab.txt, ac.txt або ad.txt\na[b-d].txt\n\n# Відповідає будь-якому файлу у субтеці subdir, що відповідає temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nДекілька важливих відмінностей від `.gitignore`:\n\n- Синтаксис '**' не підтримується.\n- Бібліотека globbing є Go's `filepath.Match`, а не `fnmatch(3)`.\n- Пробіли на кінці ігноруються завжди (немає підтримки екранованих послідовностей).\n- Немає підтримки '\\!' як спеціальної початкової послідовності.\n- Файл `.helmignore` стандартно не виключає себе, потрібно додати явний запис для `.helmignore`.\n\n**Ми будемо вдячні за вашу допомогу** у покращенні цього документа. Щоб додати, виправити або видалити інформацію, [відкрийте тікет](https://github.com/helm/helm-www/issues) або надішліть нам запит на внесення змін.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx",
    "content": "---\ntitle: Шаблони чартів\nsidebar_position: 5\n---\n\n# Посібник розробника шаблонів чартів\n\nЦей посібник надає введення в шаблони чартів Helm, з акцентом на мову шаблонів.\n\nШаблони генерують файли маніфестів, які є YAML-форматованими описами ресурсів, які Kubernetes може зрозуміти. Ми розглянемо, як структуровані шаблони, як їх можна використовувати, як писати шаблони на Go і як налагоджувати вашу роботу.\n\nЦей посібник зосереджений на наступних концепціях:\n\n- Мова шаблонів Helm\n- Використання значень\n- Техніки роботи з шаблонами\n\nЦей посібник орієнтований на вивчення особливостей мови шаблонів Helm. Інші посібники надають вступні матеріали, приклади та найкращі практики.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Іменовані шаблони\ndescription: Як визначити іменовані шаблони.\nsidebar_position: 9\n---\n\nПора перейти від одного шаблону до створення інших. У цьому розділі ми побачимо, як визначити _іменовані шаблони_ в одному файлі, а потім використовувати їх в інших місцях. _Іменований шаблон_ (іноді його називають _частковим_ або _підшаблоном_) — це просто шаблон, визначений у файлі, якому надали імʼя. Ми розглянемо два способи створення таких шаблонів і кілька способів їх використання.\n\nУ розділі [Керування потоком](/chart_template_guide/control_structures.md) ми представили три дії для оголошення та управління шаблонами: `define`, `template` і `block`. У цьому розділі ми розглянемо ці три дії, а також введемо спеціальну функцію `include`, яка працює подібно до дії `template`.\n\nВажлива деталь, яку слід памʼятати при іменуванні шаблонів: **імена шаблонів є глобальними**. Якщо ви оголосите два шаблони з однаковим імʼям, використовуватиметься той, який був завантажений останнім. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, слід бути обережним при іменуванні шаблонів, використовуючи _імена, специфічні для чарту_.\n\nПопулярним способом іменування є префіксування кожного визначеного шаблону іменем чарту: `{{ define \"mychart.labels\" }}`. Використовуючи конкретне імʼя чарту як префікс, ми можемо уникнути будь-яких конфліктів, які можуть виникнути через два різних чарти, що реалізують шаблони з однаковим іменем.\n\nЦя поведінка також стосується різних версій чарту. Якщо у вас є `mychart` версії `1.0.0`, яка визначає шаблон одним способом, і `mychart` версії `2.0.0`, яка змінює наявний іменований шаблон, буде використовуватися той, який був завантажений останнім. Ви можете обійти цю проблему, додавши версію в імʼя чарту: `{{ define \"mychart.v1.labels\" }}` та `{{ define \"mychart.v2.labels\" }}`.\n\n## Часткові та `_` файли {#partials-and-_files}\n\nДо цього часу ми використовували один файл, і цей один файл містив один шаблон. Але мова шаблонів Helm дозволяє створювати іменовані вкладені шаблони, до яких можна звертатися за іменем в інших місцях.\n\nПеред тим як перейти до деталей написання цих шаблонів, варто згадати про правила іменування файлів:\n\n* Більшість файлів у `templates/` обробляються як файли з маніфестами Kubernetes\n* `NOTES.txt` є винятком\n* Але файли, імʼя яких починається з підкреслення (`_`), вважаються такими, що _не мають_ маніфесту всередині. Ці файли не перетворюються на обʼєкти Kubernetes, але доступні в інших шаблонах чартів для використання.\n\nЦі файли використовуються для зберігання часткових шаблонів і допоміжних функцій. Насправді коли ми вперше створили `mychart`, ми бачили файл з назвою `_helpers.tpl`. Цей файл є стандартним місцем для часткових шаблонів.\n\n## Оголошення та використання шаблонів з `define` та `template` {#declaring-and-using-templates-with-define-and-template}\n\nДія `define` дозволяє створювати іменовані шаблони всередині файлу шаблону. Її синтаксис виглядає так:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # тіло шаблону тут\n{{- end }}\n```\n\nНаприклад, ми можемо визначити шаблон для інкапсуляції блоку міток Kubernetes:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nТепер ми можемо вбудувати цей шаблон всередині нашого наявного ConfigMap і включити його за допомогою дії `template`:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nКоли рушій шаблонів читає цей файл, він зберігає посилання на `mychart.labels` до того часу, поки не буде викликано `template \"mychart.labels\"`. Тоді він рендерить цей шаблон безпосередньо. Результат виглядатиме так:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nПримітка: `define` не створює виводу, якщо не буде викликано шаблон, як у цьому прикладі.\n\nЗазвичай шаблони Helm розміщують у файлах часткових шаблонів, зазвичай у `_helpers.tpl`. Перенесемо цю функцію туди:\n\n```yaml\n{{/* Генерація базових міток */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nЗгідно з домовленостями, функції `define` повинні мати простий блок документації (`{{/* ... */}}`), що описує їх призначення.\n\nНавіть якщо це визначення знаходиться в `_helpers.tpl`, його все ще можна використовувати в `configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nЯк уже згадувалося, **імена шаблонів є глобальними**. В результаті, якщо два шаблони оголошені з однаковим імʼям, буде використано останній варіант. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, краще давати шаблонам _специфічні для чарту імена_. Популярний спосіб іменування — це префіксувати кожен визначений шаблон іменем чарту: `{{ define \"mychart.labels\" }}`.\n\n## Встановлення області видимості шаблону {#setting-the-scope-of-a-template}\n\nУ шаблоні, який ми визначили вище, ми не використовували жодних обʼєктів. Ми просто використовували функції. Змінимо наш визначений шаблон, щоб включити назву чарту та версію чарту:\n\n```yaml\n{{/* Генерація базових міток */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nЯкщо ми його відрендеримо, ми отримаємо помилку, схожу на цю:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nЩоб побачити, що було відрендерено, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Результат не буде таким, як ми очікували:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\nЩо сталося з назвою та версією? Вони не були в області видимості для нашого визначеного шаблону. Коли іменований шаблон (створений за допомогою `define`) рендериться, він отримує область видимості, передану через виклик `template`. У нашому прикладі ми включили шаблон ось так:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nОбласть видимості не була передана, тому всередині шаблону ми не можемо звертатися до нічого в `.`. Це досить легко виправити. Ми просто передаємо область видимості до шаблону:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nЗверніть увагу, що ми передаємо `.` в кінці виклику `template`. Ми могли б так само легко передати `.Values` або `.Values.favorite`, або будь-яку іншу область видимості, яку хочемо. Але те, що нам потрібно, це область видимості верхнього рівня.\n\nТепер, коли ми виконаємо цей шаблон з `helm install --dry-run --debug plinking-anaco ./mychart`, ми отримаємо таке:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nТепер `{{ .Chart.Name }}` розвʼязується в `mychart`, а `{{ .Chart.Version }}` розвʼязується в `0.1.0`.\n\n## Функція `include` {#the-include-function}\n\nПрипустимо, ми визначили простий шаблон, який виглядає ось так:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nТепер припустимо, я хочу вставити це як в розділ `labels:`, так і в розділ `data:`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nЯкщо ми це відрендеримо, ми отримаємо помилку, схожу на цю:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nЩоб побачити, що було відрендеровано, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. Вихідні дані не будуть такими, як ми очікували:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nЗверніть увагу, що відступ на `app_version` неправильний в обох місцях. Чому? Тому що шаблон, який вставляється, має текст вирівняний по лівому краю. Оскільки `template` є дією, а не функцією, немає способу передати вихідний результат виклику `template` іншим функціям; дані просто вставляються в рядок.\n\nЩоб обійти цю проблему, Helm надає альтернативу `template`, яка імплементує вміст шаблону в поточний конвеєр, де він може бути переданий іншим функціям у конвеєрі.\n\nОсь приклад вище, виправлений з використанням `indent`, щоб правильно відступити шаблон `mychart.app`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nТепер створений YAML має вірний відступ для кожного розділу:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> Вважається за краще використовувати `include` замість `template` у шаблонах Helm, щоб краще керувати форматуванням виходу для YAML-документів.\n\nІноді ми хочемо імплементувати вміст, але не як шаблони. Тобто, ми хочемо імплементувати файли без змін. Ми можемо досягти цього, звертаючись до файлів через обʼєкт `.Files`, описаний у наступному розділі.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Створення файлу NOTES.txt\ndescription: Як надати інструкції користувачам вашого чарту.\nsidebar_position: 10\n---\n\nУ цьому розділі ми розглянемо інструмент Helm для надання інструкцій користувачам вашого чарту. Після виконання `helm install` або `helm upgrade` Helm може вивести блок корисної інформації для користувачів. Цю інформацію можна налаштувати за допомогою шаблонів.\n\nЩоб додати нотатки по установці до вашого чарту, просто створіть файл `templates/NOTES.txt`. Цей файл є звичайним текстовим файлом, але обробляється як шаблон і має всі звичайні функції та обʼєкти шаблонів.\n\nСтворимо простий файл `NOTES.txt`:\n\n```none\nДякуємо за встановлення {{ .Chart.Name }}.\n\nВаш реліз називається {{ .Release.Name }}.\n\nЩоб дізнатися більше про реліз, спробуйте:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nТепер, якщо ми виконаємо `helm install rude-cardinal ./mychart`, ми побачимо це повідомлення внизу:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nДякуємо за встановлення mychart.\n\nВаш реліз називається rude-cardinal.\n\nЩоб дізнатися більше про реліз, спробуйте:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nВикористання `NOTES.txt` таким чином є чудовим способом надати вашим користувачам детальну інформацію про те, як використовувати новостворений чарт. Створення файлу `NOTES.txt` наполегливо рекомендується, хоча це і не є обовʼязковим.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Субчарти та глобальні значення\ndescription: Взаємодія з значеннями субчартів і глобальними значеннями.\nsidebar_position: 11\n---\n\nДо цього моменту ми працювали тільки з одним чартом. Але чарти можуть мати залежності, які називаються _субчартами_, що також мають свої власні значення і шаблони. У цьому розділі ми створимо субчарт і розглянемо різні способи доступу до значень зсередини шаблонів.\n\nПеред тим, як перейти до коду, є кілька важливих деталей, які слід знати про субчарти:\n\n1. Субчарт вважається \"автономним\", що означає, що субчарт ніколи не може прямо залежати від батьківського чарту.\n2. Тому субчарт не може отримувати доступ до значень свого пращура.\n3. Батьківський чарт може перевизначати значення для субчартів.\n4. Helm має концепцію _глобальних значень_, які можуть бути доступні всім чартам.\n\n> Ці обмеження не завжди застосовуються до [бібліотечних чартів](/topics/library_charts.md), які розроблені для надання стандартної функціональності.\n\nПід час роботи з прикладами в цьому розділі ці концепції стануть зрозумілішими.\n\n## Створення субчарту {#creating-a-subchart}\n\nДля цих вправ ми почнемо з чарту `mychart/`, який ми створили на початку цього посібника, і додамо новий чарт всередину його.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nЗверніть увагу, що ми видалили всі базові шаблони, щоб почати з нуля. У цьому посібнику ми зосереджені на тому, як працюють шаблони, а не на управлінні залежностями. Але [Посібник з Чартів](/topics/charts.md) містить більше інформації про те, як працюють субчарти.\n\n## Додавання значень та шаблону до субчарту {#adding-values-and-a-template-to-the-subchart}\n\nДалі створимо простий шаблон і файл значень для чарту `mysubchart`. У `mychart/charts/mysubchart` вже має бути файл `values.yaml`. Налаштуємо його так:\n\n```yaml\ndessert: cake\n```\n\nДалі створимо новий шаблон ConfigMap у `mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nОскільки кожен субчарт є _самостіним чартом_, ми можемо протестувати `mysubchart` окремо:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Перевизначення значень з батьківського чарту {#overriding-values-from-a-parent-chart}\n\nНаш оригінальний чарт, `mychart`, тепер є _батьківським_ чартом для `mysubchart`. Ці стосунки базується виключно на тому, що `mysubchart` знаходиться в `mychart/charts`.\n\nОскільки `mychart` є батьківським чартом, ми можемо вказати конфігурацію в `mychart` і передати цю конфігурацію в `mysubchart`. Наприклад, ми можемо змінити `mychart/values.yaml` таким чином:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nЗверніть увагу на останні два рядки. Будь-які директиви всередині секції `mysubchart` будуть передані в чарт `mysubchart`. Отже, якщо ми виконаємо `helm install --generate-name --dry-run --debug mychart`, однією з речей, які ми побачимо, буде ConfigMap `mysubchart`:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nЗначення на верхньому рівні тепер перевизначило значення субчарту.\n\nВажливо помітити, що ми не змінили шаблон `mychart/charts/mysubchart/templates/configmap.yaml`, щоб вказати на `.Values.mysubchart.dessert`. З точки зору цього шаблону, значення все ще розташоване в `.Values.dessert`. Оскільки шаблонний движок передає значення далі, він встановлює область видимості. Отже, для шаблонів `mysubchart` тільки значення, специфічні для `mysubchart`, будуть доступні в `.Values`.\n\nІноді, проте, ви хочете, щоб певні значення були доступні всім шаблонам. Це досягається за допомогою глобальних значень чарту.\n\n## Глобальні значення чарту {#global-chart-values}\n\nГлобальні значення — це значення, які можуть бути доступні з будь-якого чарту або субчарту під тим самим імʼям. Глобальні значення потребують явного оголошення. Ви не можете використовувати вже наявні неглобальні значення як глобальні.\n\nТип даних Values має зарезервовану секцію `Values.global`, де можна задати глобальні значення. Визначимо одне в нашому файлі `mychart/values.yaml`.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nЗавдяки способу роботи глобальних значень, як `mychart/templates/configmap.yaml`, так і `mysubchart/templates/configmap.yaml` повинні мати змогу отримати це значення як `{{ .Values.global.salad }}`.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nТепер, якщо ми виконаємо установку в режимі dry run, ми побачимо одне й те ж значення в обох виводах:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nГлобальні значення корисні для передачі такої інформації, хоча це вимагає певного планування, щоб переконатися, що правильні шаблони налаштовані для використання глобальних значень.\n\n## Поширення шаблонів з субчартами {#sharing-templates-with-subcharts}\n\nБатьківські чарти та субчарти можуть ділитися шаблонами. Будь-який визначений блок у будь-якому чарті доступний іншим чартам.\n\nНаприклад, ми можемо визначити простий шаблон таким чином:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nЗгадайте, як мітки на шаблонах є _глобально спільними_. Отже, шаблон `labels` можна включити з будь-якого іншого чарту.\n\nХоча розробники чартів можуть вибирати між `include` та `template`, однією з переваг використання `include` є те, що `include` може динамічно посилатися на шаблони:\n\n```yaml\n{{ include $mytemplate }}\n```\n\nВищезазначене призведе до розʼєднання посилань на `$mytemplate`. Функція `template`, навпаки, приймає тільки рядковий літерал.\n\n## Уникнення використання блоків {#avoid-using-blocks}\n\nМова шаблонів Go надає ключове слово `block`, яке дозволяє розробникам надати стандартну реалізацію, яка потім перевизначається. У чарті Helm блоки не є найкращим інструментом для перевизначення, оскільки якщо кілька реалізацій одного блоку надаються, вибір однієї з них є непередбачуваним.\n\nРекомендація — використовувати `include`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Файли значень\ndescription: Інструкції щодо використання прапорця --values.\nsidebar_position: 4\n---\n\nУ попередньому розділі ми розглянули вбудовані обʼєкти, які пропонують шаблони Helm. Один з вбудованих обʼєктів — це `Values`. Цей обʼєкт надає доступ до значень, переданих у шаблон. Його вміст походить з кількох джерел:\n\n- Файл `values.yaml` у шаблоні\n- Якщо це субшаблон, файл `values.yaml` батьківського шаблону\n- Файл значень передається в `helm install` або `helm upgrade` з прапорцем `-f` (`helm install -f myvals.yaml ./mychart`)\n- Окремі параметри передаються з `--set` (наприклад, `helm install --set foo=bar ./mychart`)\n\nНаведений вище список розташований у порядку специфічності: `values.yaml` є стандартним, яке може бути перевизначене файлом `values.yaml` батьківського шаблону, який, своєю чергою, може бути перевизначений файлом значень, наданим користувачем, який, своєю чергою, може бути перевизначений параметрами `--set`.\n\nФайли значень — це прості YAML-файли. Відредагуємо `mychart/values.yaml`, а потім відредагуємо наш шаблон ConfigMap.\n\nВидаливши стандартні значення у `values.yaml`, ми встановимо лише один параметр:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nТепер ми можемо використовувати його всередині шаблону:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nЗверніть увагу, що в останньому рядку ми отримуємо доступ до `favoriteDrink` як до атрибута `Values`: `{{ .Values.favoriteDrink }}`.\n\nПодивімося, як це відобразиться.\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nОскільки `favoriteDrink` встановлено в стандартне значення у файлі `values.yaml` як `coffee`, це значення відображається в шаблоні. Ми можемо легко перевизначити його, додавши прапорець `--set` у наш виклик `helm install`:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nОскільки `--set` має вищий пріоритет, ніж файл `values.yaml`, наш шаблон генерує `drink: slurm`.\n\nФайли значень також можуть містити більш структурований контент. Наприклад, ми могли б створити розділ `favorite` у нашому файлі `values.yaml`, а потім додати туди кілька ключів:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nТепер нам потрібно трохи змінити шаблон:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nХоча структурування даних таким чином є можливим, рекомендується тримати дерева значень пласкими, надаючи перевагу рівній структурі. Коли ми розглядатимемо призначення значень субшаблонам, ми побачимо, як значення називаються, використовуючи структуру дерева.\n\n## Видалення стандартного ключа {#deleting-a-default-key}\n\nЯкщо вам потрібно видалити ключ зі стандартних значень, ви можете перевизначити значення ключа як `null`, у цьому випадку Helm видалить ключ з злиття перевизначених значень.\n\nНаприклад, стабільний шаблон Drupal дозволяє налаштовувати перевірку життєздатності (liveness probe) у випадку, якщо ви налаштовуєте власний образ. Ось стандартні значення:\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nЯкщо ви спробуєте перевизначити обробник livenessProbe на `exec` замість `httpGet`, використовуючи `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm обʼєднає стандартні ключі разом з перевизначеними, що дасть нам наступний YAML:\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nОднак Kubernetes тоді видасть помилку, оскільки не можна оголошувати більше одного обробника livenessProbe. Щоб це обійти, ви можете інструктувати Helm видалити `livenessProbe.httpGet`, встановивши його значення в null:\n\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nНа цьому етапі ми розглянули кілька вбудованих обʼєктів і використали їх для вставки інформації в шаблон. Тепер ми розглянемо інший аспект шаблонного механізму: функції та конвеєри.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: Змінні\ndescription: Використання змінних у шаблонах.\nsidebar_position: 8\n---\n\nМаючи функції, конвеєри, обʼєкти та структури управління, ми можемо перейти до однієї з основних ідей у багатьох мовах програмування: змінних. У шаблонах вони використовуються рідше. Але ми побачимо, як їх можна використовувати для спрощення коду та для кращого використання `with` і `range`.\n\nУ попередньому прикладі ми побачили, що цей код не працює:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` не знаходиться в межах області видимості, обмеженої блоком `with`. Один зі способів обійти проблеми з областю видимості — присвоїти обʼєкти змінним, до яких можна отримати доступ без врахування поточної області видимості.\n\nУ шаблонах Helm змінна є іменованим посиланням на інший обʼєкт. Вона має формат `$name`. Змінні присвоюються за допомогою спеціального оператора присвоєння: `:=`. Ми можемо переписати вищезазначене, використовуючи змінну для `Release.Name`.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nЗверніть увагу, що перед тим як почати блок `with`, ми присвоюємо `$relname := .Release.Name`. Тепер всередині блоку `with` змінна `$relname` все ще вказує на імʼя релізу.\n\nЗапуск цього коду дасть наступний результат:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nЗмінні особливо корисні в циклах `range`. Їх можна використовувати для спископодібних обʼєктів, щоб захопити як індекс, так і значення:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n```\n\nЗверніть увагу, що `range` йде першим, потім змінні, потім оператор присвоєння, а потім список. Це присвоїть ціле число (починаючи з нуля) змінній `$index` і значення змінній `$topping`. Запуск цього коду дасть:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nДля структур даних, які мають як ключ, так і значення, ми можемо використовувати `range`, щоб отримати обидва. Наприклад, ми можемо перебрати `.Values.favorite` таким чином:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nТепер на першій ітерації `$key` буде `drink`, а `$val` буде `coffee`, а на другій `$key` буде `food`, а `$val` буде `pizza`. Запуск цього коду створить:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nЗмінні зазвичай не є \"глобальними\". Вони мають область видимості в межах блоку, в якому вони оголошені. Раніше ми присвоїли `$relname` на верхньому рівні шаблону. Ця змінна буде видима для всього шаблону. Але в нашому останньому прикладі змінні `$key` і `$val` будуть видимі лише всередині блоку `{{ range... }}{{ end }}`.\n\nОднак є одна змінна, яка завжди є глобальною — `$`, ця змінна завжди буде вказувати на кореневий контекст. Це може бути дуже корисно, коли ви перебираєте в діапазоні і вам потрібно знати імʼя релізу чарту.\n\nПриклад, що ілюструє це:\n\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Багато шаблонів Helm використовували б `.` тут, але це не спрацює,\n    # однак `$` спрацює тут\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # Я не можу звертатися до .Chart.Name, але можу використовувати $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Значення з appVersion у Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nДо цього часу ми розглянули лише один шаблон, оголошений в одному файлі. Але одна з потужних можливостей мови шаблонів Helm — це можливість оголошувати кілька шаблонів і використовувати їх разом. Ми перейдемо до цього в наступному розділі.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Наступні кроки\ndescription: \"Підсумок\\_— корисні вказівки на іншу документацію, яка може допомогти вам.\"\nsidebar_position: 14\n---\n\nЦей посібник має на меті надати вам, розробнику чартів, глибоке розуміння того, як використовувати мову шаблонів Helm. Посібник зосереджений на технічних аспектах розробки шаблонів.\n\nАле є багато аспектів практичного щоденного розроблення чартів, які цей посібник не охоплює. Ось кілька корисних вказівок на іншу документацію, яка допоможе вам у створенні нових чартів:\n\n- CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є незамінним джерелом чартів.\n- [Документація Kubernetes](https://kubernetes.io/docs/home/) надає детальні приклади різних ресурсів, які ви можете використовувати, від ConfigMaps і Secrets до DaemonSets і Deployments.\n- Посібник [Чарти Helm](/topics/charts.md) пояснює робочий процес використання чартів.\n- Посібник [Хуки чартів Helm](/topics/charts_hooks.md) пояснює, як створювати хук для життєвого циклу.\n- Стаття [Поради та підказки для розробки чартів](/howto/charts_tips_and_tricks.md) надає кілька корисних порад для написання чартів.\n- Документація [Sprig](https://github.com/Masterminds/sprig) описує більше ніж шістдесят функцій шаблонів.\n- Документація [Go templates](https://godoc.org/text/template) детально пояснює синтаксис шаблонів.\n- Інструмент [Schelm](https://github.com/databus23/schelm) є корисною утилітою для налагодження чартів.\n\nІноді легше поставити кілька запитань і отримати відповіді від досвідчених розробників. Найкраще місце для цього — канали Helm у [Slack Kubernetes](https://kubernetes.slack.com):\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nНарешті, якщо ви знайдете помилки або упущення в цьому документі, хочете запропонувати новий контент або хотіли б внести свій внесок, відвідайте [The Helm Project](https://github.com/helm/helm-www).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Додаток: Техніки YAML\"\ndescription: Ближчий погляд на специфікацію YAML та її застосування до Helm.\nsidebar_position: 15\n---\n\nБільшість цього посібника зосереджена на написанні мови шаблонів. Тут ми розглянемо формат YAML. YAML має кілька корисних функцій, які ми, як автори шаблонів, можемо використовувати для того, щоб зробити наші шаблони менш схильними до помилок і легшими для читання.\n\n## Масиви та Колекції {#scalars-and-collections}\n\nЗгідно зі [специфікацією YAML](https://yaml.org/spec/1.2/spec.html), існують два типи колекцій та багато типів скалярів.\n\nДва типи колекцій — це map та послідовності:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nСкалярні значення – це окремі значення (на відміну від колекцій).\n\n### Типи скалярів у YAML {#scalar-types-in-yaml}\n\nУ діалекті YAML Helm тип даних значення визначається складним набором правил, включаючи схему Kubernetes для ресурсних визначень. Але при визначенні типів, наступні правила зазвичай є правильними.\n\nЯкщо ціле число або десяткове число є без лапок, це зазвичай трактуватиметься як числовий тип:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nАле якщо вони укладені в лапки, вони трактуються як рядки:\n\n```yaml\ncount: \"1\" # <-- рядок, не int\nsize: '2.34' # <-- рядок, не float\n```\n\nТе ж саме стосується булевих значень:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # рядок\n```\n\nСлово для пустого значення — `null` (не `nil`).\n\nЗверніть увагу, що `port: \"80\"` є дійсним YAML і пройде через рушій шаблонів та парсер YAML, але зазнає невдачі, якщо Kubernetes очікує, що `port` буде цілим числом.\n\nУ деяких випадках ви можете примусово визначити певний тип, використовуючи теґи вузлів YAML:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nУ наведеному вище прикладі `!!str` говорить парсеру, що `age` є рядком, навіть якщо він виглядає як int. А `port` трактуватиметься як int, навіть якщо він укладений в лапки.\n\n## Рядки в YAML {#strings-in-yaml}\n\nБільшість даних, які ми розміщуємо в документах YAML, є рядками. YAML має кілька способів представлення рядків. Цей розділ пояснює способи та демонструє, як використовувати деякі з них.\n\nІснують три \"вбудовані\" способи оголошення рядка:\n\n```yaml\nway1: просто слова\nway2: \"рядки в подвійних лапках\"\nway3: 'рядки в одинарних лапках'\n```\n\nВсі вбудовані стилі мають бути в одному рядку.\n\n- Невкладені слова не мають лапок і не екрановані. Тому потрібно бути обережним із символами, які ви використовуєте.\n- Рядки в подвійних лапках можуть мати спеціальні символи екрановані за допомогою `\\`. Наприклад, `\"\\\"Hello\\\", she said\"`. Можна екранувати розриви рядка за допомогою `\\n`.\n- Рядки в одинарних лапках є \"літеральними\" рядками та не використовують `\\` для екранування символів. Єдине екранування — це `''`, яке декодується як один символ `'`.\n\nОкрім рядків в один рядок, можна оголосити багаторядкові рядки:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nВищенаведене буде трактувати значення `coffee` як один рядок, еквівалентний `Latte\\nCappuccino\\nEspresso\\n`.\n\nЗверніть увагу, що перший рядок після `|` повинен мати вірний відступ. Тому ми можемо зламати приклад вище, зробивши це:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nОскільки `Latte` має неправильний відступ, ми отримаємо помилку на кшталт:\n\n```none\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nУ шаблонах іноді безпечніше помістити несправжній \"перший рядок\" у багаторядковому документі лише для захисту від цієї помилки:\n\n```yaml\ncoffee: |\n  # Коментований перший рядок\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nЗауважте, що яким би не був цей перший рядок, його буде збережено у виведенні рядка. Тому, якщо ви, наприклад, використовуєте цю техніку для вливання вмісту файлу в ConfigMap, коментар має бути типу, який очікується тим, хто читає цей запис.\n\n### Керування пробілами в багаторядкових рядках {#controlling-spaces-in-multiline-strings}\n\nУ наведеному вище прикладі ми використовували `|`, щоб позначити багаторядковий рядок. Але зверніть увагу, що вміст нашого рядка завершувався з кінцевим `\\n`. Якщо ми хочемо, щоб обробник YAML видалив кінцевий перенос рядка, ми можемо додати `-` після `|`:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nТепер значення `coffee` буде: `Latte\\nCappuccino\\nEspresso` (без кінцевого `\\n`).\n\nВ інших випадках ми можемо захотіти зберегти весь кінцевий пробіл. Ми можемо зробити це за допомогою позначення `|+`:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nТепер значення `coffee` буде `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nВідступи всередині текстового блоку зберігаються, що призводить до збереження переносу рядків:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nУ наведеному вище випадку значення `coffee` буде `Latte\\n  12 oz\\n  16 oz\\nCappuccino\\nEspresso`.\n\n### Відступи та шаблони {#indenting-and-templates}\n\nКоли ви пишете шаблони, ви можете захотіти вставити вміст файлу в шаблон. Як ми бачили в попередніх розділах, є два способи зробити це:\n\n- Використовуйте `{{ .Files.Get \"FILENAME\" }}`, щоб отримати вміст файлу в чартах.\n- Використовуйте `{{ include \"TEMPLATE\" . }}`, щоб відобразити шаблон, а потім вставити його вміст у чарти.\n\nКоли ви вставляєте файли в YAML, корисно розуміти правила багаторядкових рядків. Найчастіше найпростіший спосіб вставити статичний файл — зробити щось на кшталт цього:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nЗверніть увагу, як ми виконуємо відступ вище: `indent 2` говорить шаблонному двигуну відступити кожен рядок у \"myfile.txt\" на два пробіли. Зверніть увагу, що ми не відступаємо сам рядок шаблону. Це тому, що якщо ми це зробимо, вміст файлу першого рядка буде відступлений двічі.\n\n### Згортання багаторядкових рядків {#folded-multi-line-strings}\n\nІноді вам потрібно представити рядок у вашому YAML на кількох рядках, але ви хочете, щоб він трактувався як один довгий рядок під час інтерпретації. Це називається \"згортанням\". Щоб оголосити згортання блоку, використовуйте `>` замість `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nЗначення `coffee` буде `Latte Cappuccino Espresso\\n`. Зверніть увагу, що всі, крім останнього переносу рядка, будуть перетворені на пробіли. Ви можете поєднувати контроль пробілів із позначкою згортання тексту, тому `>-` замінить або обрізає всі нові рядки.\n\nЗверніть увагу, що в згортанні синтаксису відступ тексту призведе до збереження рядків.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nНаведене вище створить `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Зверніть увагу, що і пробіли, і нові рядки все ще присутні.\n\n## Вбудовування кількох документів в один файл {#embedding-multiple-documents-in-one-file}\n\nМожливо розмістити більше одного YAML-документа в одному файлі. Це робиться шляхом префіксації нового документа `---` і закінчення документа `...`\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nУ багатьох випадках можна опустити `---` або `...`.\n\nДеякі файли в Helm не можуть містити більше одного документа. Якщо, наприклад, у файлі `values.yaml` надано більше одного документа, буде використано лише перший.\n\nОднак файли шаблонів можуть мати більше одного документа. Коли це трапляється, файл (і всі його документи) обробляється як один обʼєкт під час рендерингу шаблонів. Але потім отриманий YAML розділяється на кілька документів, перш ніж він буде переданий Kubernetes.\n\nМи рекомендуємо використовувати кілька документів у файлі лише в разі крайньої потреби. Наявність кількох документів у файлі може ускладнити налагодження.\n\n## YAML є надмножиною JSON {#yaml-is-a-superset-of-json}\n\nОскільки YAML є надмножиною JSON, будь-який дійсний JSON-документ _повинен_ бути дійсним YAML.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nВищенаведене є іншим способом представлення цього:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nІ їх можна змішувати (з обережністю):\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nУсі три повинні перетворюватись в однакове внутрішнє подання.\n\nЦе означає, що файли, такі як `values.yaml`, можуть містити дані JSON, але Helm не трактує розширення файлу `.json` як дійсний суфікс.\n\n## Якорі YAML {#yaml-anchors}\n\nСпецифікація YAML надає спосіб зберігати посилання на значення і пізніше посилатися на це значення за допомогою посилання. YAML називає це \"якорінням\":\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nУ наведеному вище прикладі `&favoriteCoffee` встановлює посилання на `Cappuccino`. Пізніше це посилання використовується як `*favoriteCoffee`. Таким чином, `coffees` стає `Latte, Cappuccino, Espresso`.\n\nХоча є кілька випадків, коли якорі корисні, існує один аспект їх використання, який може спричинити тонкі помилки: під час першого використання YAML посилання розширюється і потім видаляється.\n\nТому, якщо ми декодуємо і потім повторно кодуємо приклад вище, отриманий YAML буде таким:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nОскільки Helm і Kubernetes часто читають, змінюють і потім переписують файли YAML, якорі будуть втрачені.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: Зміни з часів Helm 2\nsidebar_position: 1\n---\n\n## Зміни з часів Helm 2 {#changes-since-helm-2}\n\nОсь вичерпний список усіх основних змін, введених у Helm 3.\n\n### Видалення Tiller {#removal-of-tiller}\n\nПід час циклу розробки Helm 2 ми впровадили Tiller. Tiller відігравав важливу роль для команд, що працюють на спільному кластері — він дозволяв кільком різним операторам взаємодіяти з одним і тим же набором релізів.\n\nЗ увімкненим контролем доступу на основі ролей (RBAC) у Kubernetes 1.6, контроль доступу до Tiller у випадках операційної діяльності став важчим у керуванні. Через велику кількість можливих політик безпеки наше ставлення полягало в тому, щоб забезпечити стандартну дозвільну конфігурацію. Це дозволяло новачкам почати експериментувати з Helm і Kubernetes без необхідності заглиблюватися в керування безпекою. На жаль, ця дозвільна конфігурація могла надавати користувачеві широкий спектр дозволів, які йому не були надані. DevOps і SRE доводилося вивчати додаткові оперативні кроки при встановленні Tiller в мультиорендний кластер.\n\nПісля того як ми дізналися, як члени спільноти використовують Helm у певних сценаріях, ми виявили, що система управління релізами Tiller не має покладатися на оператора в кластері для підтримки стану або дії як центральний центр інформації про релізи Helm. Натомість ми могли просто отримувати інформацію з сервера API Kubernetes, рендерити чарти на стороні клієнта і зберігати запис про установку в Kubernetes.\n\nОсновна мета Tiller могла бути досягнута без Tiller, тому одне з перших рішень, яке ми прийняли щодо Helm 3, полягало в повному видаленні Tiller.\n\nЗ відсутністю Tiller модель безпеки Helm радикально спростилася. Helm 3 тепер підтримує всі сучасні функції безпеки, ідентифікації та авторизації сучасного Kubernetes. Дозволи Helm оцінюються за допомогою вашого [файлу kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Адміністратори кластерів можуть обмежити дозволи користувачів на будь-якому рівні деталізації, який вони вважають за потрібний. Релізи все ще записуються в кластері, а решта функціональності Helm залишається.\n\n### Поліпшена стратегія оновлення: 3-сторонні стратегічні зливання патчів {#improved-upgrade-strategy-3-way-strategic-merge-patches}\n\nHelm 2 використовував двостороннє стратегічне злиття патчів. Під час оновлення він порівнював маніфест останньої версії чарту з маніфестом запропонованого чарту (той, що надається під час `helm upgrade`). Він порівнював різницю між цими двома чартами, щоб визначити, які зміни потрібно застосувати до ресурсів у Kubernetes. Якщо зміни були внесені до кластера поза планом (наприклад, під час `kubectl edit`), ці зміни не враховувалися. Це призводило до того, що ресурси не могли повернутися до попереднього стану: оскільки Helm розглядав тільки останній застосований маніфест чарту як поточний стан, якщо у стані чарту не було змін, поточний стан залишався незмінним.\n\nУ Helm 3 тепер використовується тристороннє стратегічне злиття патчів. Helm враховує старий маніфест, його поточний стан і новий маніфест при генерації патчу.\n\n#### Приклади {#examples}\n\nРозглянемо кілька поширених прикладів того, на що впливають ці зміни.\n\n##### Повернення до попереднього стану, де поточний стан змінився {#rolling-back-where-live-state-has-changed}\n\nВаша команда щойно розгорнула свій застосунок для операційної діяльності на Kubernetes за допомогою Helm. Чарт містить обʼєкт Deployment, де кількість реплік встановлено на три:\n\n```console\n$ helm install myapp ./myapp\n```\n\nНовий розробник приєднується до команди. В перший день, спостерігаючи за операційним кластером, трапляється жахлива аварія, коли кава проливається на клавіатуру, в наслідок чого `kubectl scale` згортає deployment з трьох реплік до нуля.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nЩе один розробник у вашій команді помічає, що операційний сайт не працює, і вирішує повернути реліз до попереднього стану:\n\n```console\n$ helm rollback myapp\n```\n\nЩо відбувається?\n\nУ Helm 2 буде згенеровано патч, порівнюючи старий маніфест з новим маніфестом. Оскільки це повернення, це той самий маніфест. Helm визначає, що немає нічого для зміни, оскільки немає різниці між старим і новим маніфестом. Кількість реплік продовжує залишатися на нулі. Паніка зростає.\n\nУ Helm 3 патч генерується з використанням старого маніфесту, поточного стану і нового маніфесту. Helm визнає, що старий стан був на трьох, поточний стан — на нулі, а новий маніфест хоче змінити його назад на три, тому він генерує патч, щоб змінити стан назад на три екземпляри.\n\n##### Оновлення, де поточний стан змінився {#updating-where-live-state-has-changed}\n\nБагато сервісних мереж та інших застосунків на основі контролерів вбудовують дані в обʼєкти Kubernetes. Це може бути щось на кшталт sidecar, міток або іншої інформації. Раніше, якщо у вас був даний маніфест, створений з чарту:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nА поточний стан був змінений іншим застосунком на\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nТепер ви хочете оновити теґ образу `nginx` до `2.1.0`. Отже, ви оновлюєте чарт до маніфесту:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nЩо відбувається?\n\nУ Helm 2 Helm генерує патч обʼєкта `containers` між старим маніфестом і новим маніфестом. Поточний стан кластера не враховується під час генерації патчу.\n\nПоточний стан кластера модифікується, щоб виглядати наступним чином:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nВиникає більше паніки.\n\nУ Helm 3 Helm генерує патч обʼєкта `containers` між старим маніфестом, поточним станом і новим маніфестом. Він помічає, що новий маніфест змінює теґ образу на `2.1.0`, але поточний стан містить контейнер sidecar.\n\nПоточний стан кластера модифікується, щоб виглядати наступним чином:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### Імена релізів тепер обмежені простором імен {#release-names-are-now-scoped-to-the-namespace}\n\nЗ видаленням Tiller інформація про кожен реліз повинна була десь зберігатися. У Helm 2 вона зберігалась в тому ж просторі імен, що й Tiller. Це означало, що після використання імені для одного релізу жоден інший реліз не міг використовувати те ж саме імʼя, навіть якщо він був розгорнутий в іншому просторі імен.\n\nУ Helm 3 інформація про конкретний реліз тепер зберігається в тому ж просторі імен, що і сам реліз. Це означає, що користувачі тепер можуть робити `helm install wordpress stable/wordpress` у двох окремих просторах імен, і кожен з них можна буде переглядати за допомогою `helm list`, змінивши контекст простору імен (наприклад, `helm list --namespace foo`).\n\nЗ цим більшим узгодженням з нативними просторами імен кластера команда `helm list` більше не стандартно виводить перелік всіх релізів. Натомість вона буде виводити лише релізи в просторі імен вашого поточного контексту Kubernetes (тобто простір імен, що відображається, коли ви виконуєте `kubectl config view --minify`). Це також означає, що ви повинні вказати прапорець `--all-namespaces` для `helm list`, щоб отримати поведінку, подібну до Helm 2.\n\n### Secrets як стандартний драйвер зберігання {#secrets-as-the-default-storage-driver}\n\nУ Helm 3 Secrets тепер використовуються як [стандартний драйвер зберігання](/topics/advanced.md#storage-backends). Helm 2 стандартно використовував ConfigMaps для зберігання інформації про релізи. У Helm 2.7.0 було впроваджено новий бекенд зберігання, що використовує Secrets для зберігання інформації про релізи, і тепер це є стандартним починаючи з Helm 3.\n\nПерехід на Secrets як стандарт для Helm 3 забезпечує додаткову безпеку у захисті чарту разом з випуском шифрування Secrets у Kubernetes.\n\n[Шифрування секретів в спокої](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) стало доступним як альфа функція в Kubernetes 1.7 і стало стабільним починаючи з Kubernetes 1.13. Це дозволяє користувачам шифрувати метадані релізів Helm в спокої, і це є хорошою відправною точкою, яку можна пізніше розширити на використання чогось на кшталт Vault.\n\n### Зміни в шляху Go import {#go-import-path-changes}\n\nУ Helm 3 шлях імпорту Go був змінений з `k8s.io/helm` на `helm.sh/helm/v3`. Якщо ви плануєте оновити бібліотеки клієнтів Go для Helm 3, переконайтеся, що змінюєте свої шляхи імпорту.\n\n### Можливості {#capabilities}\n\nВбудований обʼєкт `.Capabilities`, доступний під час етапу рендерингу, був спрощений.\n\n[Вбудовані Обʼєкти](/chart_template_guide/builtin_objects.md)\n\n### Перевірка значень чарту з JSONSchema {#validating-chart-values-with-jsonschema}\n\nТепер можна накласти JSON Schema на значення чарту. Це забезпечує, що значення, надані користувачем, відповідають схемі, визначеній автором чарту, що забезпечує кращу звітність про помилки, коли користувач надає неправильний набір значень для чарту.\n\nПеревірка відбувається при виконанні будь-якої з наступних команд:\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\nДивіться документацію про [Файли схем](/topics/charts.md#schema-files) для додаткової інформації.\n\n### Консолідація `requirements.yaml` в `Chart.yaml` {#consolidation-of-requirementsyaml-into-chartyaml}\n\nСистема управління залежностями чартів перейшла з `requirements.yaml` та `requirements.lock` у `Chart.yaml` та `Chart.lock`. Рекомендується, щоб нові чарти для Helm 3 використовували новий формат. Тим не менш, Helm 3 все ще розуміє API версію 1 (`v1`) і буде завантажувати наявні файли `requirements.yaml`.\n\nУ Helm 2 файл `requirements.yaml` виглядав так:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nУ Helm 3 залежність виражена так само, але тепер у вашому `Chart.yaml`:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nЧарти все ще завантажуються і розміщуються в теці `charts/`, тому субчарти, які знаходяться в теці `charts/`, будуть продовжувати працювати без змін.\n\n### Імʼя (або `--generate-name`) тепер необхідне при встановленні {#name-or---generate-name-is-now-required-on-install}\n\nУ Helm 2, якщо імʼя не було надане, імʼя автоматично генерувалося. В операційній експлуатації це виявилося більше проблемою, ніж корисною функцією. У Helm 3 Helm видасть помилку, якщо імʼя не буде надано при `helm install`.\n\nДля тих, хто все ще бажає автоматичне генерування імені, можна використовувати прапорець `--generate-name`, щоб створити його.\n\n### Публікація чартів в OCI реєстрах {#publishing-charts-to-oci-registries}\n\nЦе експериментальна функція, введена в Helm 3. Щоб використовувати, встановіть змінну середовища `HELM_EXPERIMENTAL_OCI=1`.\n\nНа високому рівні, репозиторій чартів — це місце, де чарти можуть зберігатися та ними можна обмінюватися. Клієнт Helm пакує і відправляє чарт в репозиторій чартів. Простими словами, репозиторій чартів — це базовий HTTP сервер, який містить файл `index.yaml` і деякі упаковані чарти.\n\nХоча є кілька переваг в API репозиторію чартів, що відповідає найосновнішим вимогам зберігання, деякі недоліки почали виявлятися:\n\n* Репозиторії чартів мають великі труднощі з абстрагуванням більшості реалізацій безпеки, необхідних у виробничому середовищі. Наявність стандартного API для автентифікації та авторизації є дуже важливим в операційних сценаріях.\n* Інструменти перевірки походження чартів Helm, що використовуються для підписання та перевірки цілісності та походження чарту, є необовʼязковою частиною процесу публікації чарту.\n* У багатокористувацьких сценаріях один і той же чарт може бути завантажений іншим користувачем, що призводить до двократних витрат на зберігання того ж контенту. Розумніші репозиторії чартів були спроєктовані для обробки цього, але це не є частиною офіційної специфікації.\n* Використання одного індексного файлу для пошуку, інформації про метадані та отримання чартів ускладнило проєктування у безпечних багатокористувацьких реалізаціях.\n\nПроєкт Docker Distribution (також відомий як Docker Registry v2) є спадкоємцем проєкту Docker Registry. Багато великих хмарних постачальників мають промислову пропозицію проєкту Distribution, і з такою кількістю постачальників, які пропонують один і той же продукт, проєкт Distribution отримав багато років удосконалення, кращих практик безпеки та випробувань у бою.\n\nБудь ласка, ознайомтеся з `helm help chart` та `helm help registry` для отримання додаткової інформації про те, як упакувати чарт і опублікувати його в Docker реєстрі.\n\nБільше інформації можна знайти на [цій сторінці](/topics/registries.md).\n\n### Видалення `helm serve` {#removal-of-helm-serve}\n\n`helm serve` запускав локальний репозиторій чартів на вашій машині для цілей розробки. Проте, він не отримав великого визнання як інструмент для розробки та мав численні проблеми з його дизайном. Зрештою, ми вирішили видалити його та винести у втулок.\n\nДля досвіду подібного до `helm serve`, подивіться на локальний файловий системний варіант у [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) та втулок [servecm](https://github.com/jdolitsky/helm-servecm).\n\n### Підтримка бібліотечних чартів {#library-chart-support}\n\nHelm 3 підтримує клас чартів, що називається “бібліотечний чарт”. Це чарт, який використовується іншими чартами, але не створює жодних артефактів релізів самостійно. Шаблони бібліотечного чарту можуть лише оголошувати елементи `define`. Глобально скопійовані не-`define` вмісти просто ігноруються. Це дозволяє користувачам повторно використовувати та ділитися фрагментами коду, які можна використовувати в багатьох чартах, уникати повторюваності та зберігати чарт [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nБібліотечні чарти оголошуються в директиві залежностей у Chart.yaml, і їх можна встановлювати та керувати як будь-яким іншим чартом.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nМи дуже раді бачити сценарії використання цієї функції для розробників чартів, а також будь-які найкращі практики, які виникають від споживання бібліотечних чартів.\n\n### Зміна apiVersion Chart.yaml {#chartyaml-apiversion-bump}\n\nЗ впровадженням підтримки бібліотечних чартів та консолідацією `requirements.yaml` в `Chart.yaml`, клієнти, які розуміли формат пакетів Helm 2, не зможуть зрозуміти ці нові функції. Тому, ми підняли версію apiVersion у Chart.yaml з `v1` на `v2`.\n\n`helm create` тепер створює чарт з використанням цього нового формату, тому стандартний apiVersion був піднятий там також.\n\nКлієнти, які бажають підтримувати обидві версії чартів Helm, повинні перевіряти поле `apiVersion` у Chart.yaml, щоб зрозуміти, як розібрати формат пакету.\n\n### Підтримка XDG Base Directory {#xdg-base-directory-support}\n\n[Специфікація XDG Base Directory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) є портативним стандартом, що визначає, де слід зберігати конфігурації, дані та кешовані файли у файловій системі.\n\nУ Helm 2 Helm зберігав всю цю інформацію в `~/.helm` (відомій як `helm home`), що можна було змінити, встановивши змінну середовища `$HELM_HOME`, або використовуючи глобальний прапорець `--home`.\n\nУ Helm 3 тепер Helm поважає наступні змінні середовища відповідно до специфікації XDG Base Directory:\n\n* `$XDG_CACHE_HOME`\n* `$XDG_CONFIG_HOME`\n* `$XDG_DATA_HOME`\n\nВтулки Helm все ще отримують `$HELM_HOME` як псевдонім до `$XDG_DATA_HOME` для зворотної сумісності з втулками, які використовують `$HELM_HOME` як середовище для тимчасових даних.\n\nТакож кілька нових змінних середовища передаються в середовище втулка для врахування цієї зміни:\n\n* `$HELM_PATH_CACHE` для кешованого шляху\n* `$HELM_PATH_CONFIG` для конфігураційного шляху\n* `$HELM_PATH_DATA` для шляхів даних\n\nВтулки Helm, які прагнуть підтримувати Helm 3, повинні розглянути можливість використання цих нових змінних середовища замість старих.\n\n### Перейменування команд CLI {#cli-command-renames}\n\nЩоб краще узгодити термінологію з іншими менеджерами пакетів, `helm delete` було перейменовано на `helm uninstall`. `helm delete` все ще зберігається як псевдонім до `helm uninstall`, тож можна використовувати будь-яку форму.\n\nУ Helm 2, щоб очистити лог релізів, потрібно було вказати прапорець `--purge`. Ця функціональність тепер є стандартно увімкненою. Щоб зберегти попередню поведінку, використовуйте `helm uninstall --keep-history`.\n\nКрім того, кілька інших команд були перейменовані для узгодження з тією ж термінологією:\n\n* `helm inspect` -> `helm show`\n* `helm fetch` -> `helm pull`\n\nЦі команди також зберегли старі дієслова як псевдоніми, тому ви можете продовжувати використовувати їх у будь-якому вигляді.\n\n### Автоматичне створення просторів імен {#automatically-creating-namespaces}\n\nПри створенні релізу в просторі імен, який не існує, Helm 2 створював простір імен. Helm 3 дотримується поведінки іншого інструменту Kubernetes і повертає помилку, якщо простір імен не існує. Helm 3 створить простір імен, якщо ви явно вкажете прапорець `--create-namespace`.\n\n### Що сталося з .Chart.ApiVersion? {#what-happened-to-chartapiversion}\n\nHelm дотримується звичайної домовленості CamelCasing, яка передбачає використання великої літери для абревіатури. Ми зробили це і в іншому коді, наприклад, у `.Capabilities.APIVersions.Has`. У Helm v3 ми виправили `.Chart.ApiVersion`, перейменувавши його на `.Chart.APIVersion`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/faq/index.mdx",
    "content": "---\ntitle: Часті питання\nsidebar_position: 9\n---\n\n# Часті питання\n\n> Цей розділ надає допомогу з найпоширенішими питаннями.\n\n**Ми будемо вдячні за вашу допомогу** у покращенні цього документу. Щоб додати, виправити або видалити інформацію, [створіть тікет](https://github.com/helm/helm-www/issues) або надішліть нам пул-реквест.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: Встановлення\nsidebar_position: 2\n---\n\n## Встановлення {#installing}\n\n### Чому немає рідних пакетів Helm для Fedora та інших дистрибутивів Linux? {#why-aren-t-there-native-packages-of-helm-for-fedora-and-other-linux-distros}\n\nПроєкт Helm не підтримує пакети для операційних систем та середовищ. Спільнота Helm може надати рідні пакети, і якщо проєкт Helm дізнається про них, вони будуть вказані. Саме так почалася та була вказана формула Homebrew. Якщо ви зацікавлені в підтримці пакета, ми будемо раді цьому.\n\n### Чому ви надаєте скрипт `curl ...|bash`? {#why-do-you-provide-a-curl-bash-script}\n\nУ нашому репозиторії є скрипт (`scripts/get-helm-3`), який можна виконати як `curl ..|bash` скрипт. Передача захищена HTTPS, а скрипт проводить деякий аудит пакетів, які він завантажує. Проте скрипт має всі звичайні небезпеки будь-якого скрипта оболонки.\n\nМи надаємо його, тому що це корисно, але ми радимо користувачам ретельно ознайомитися зі скриптом перед виконанням. Те, що ми насправді хотіли б, — це кращі упаковані релізи Helm.\n\n### Як мені помістити файли клієнта Helm в інше місце, не стандартне місце? {#how-do-i-put-the-helm-client-files-somewhere-other-than-their-defaults}\n\nHelm використовує структуру XDG для зберігання файлів. Існують змінні середовища, які ви можете використовувати для зміни цих місць:\n\n- `$XDG_CACHE_HOME`: встановіть альтернативне місце для зберігання кешованих файлів.\n- `$XDG_CONFIG_HOME`: встановіть альтернативне місце для зберігання конфігурацій Helm.\n- `$XDG_DATA_HOME`: встановіть альтернативне місце для зберігання даних Helm.\n\nЗверніть увагу, що якщо у вас є наявні репозиторії, вам доведеться повторно їх додати за допомогою `helm repo add...`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: Усунення несправностей\nsidebar_position: 4\n---\n\n## Усунення несправностей {#troubleshooting}\n\n### Я отримую попередження про \"Не вдалося отримати оновлення з репозиторію чартів 'stable'\" {#i-am-getting-a-warning-about-unable-to-get-an-update-from-the-stable-chart-repository}\n\nЗапустіть `helm repo list`. Якщо він показує ваш репозиторій `stable`, який вказує на URL `storage.googleapis.com`, вам потрібно оновити цей репозиторій. 13 листопада 2020 року репозиторій Helm Charts [перестав підтримуватися](https://github.com/helm/charts#deprecation-timeline) після річного періоду відмови від обслуговування. Архів доступний за адресою `https://charts.helm.sh/stable`, але більше не отримуватиме оновлень.\n\nВи можете виконати наступну команду для виправлення репозиторію:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update\n```\n\nТе ж саме стосується репозиторію `incubator`, для якого є архів за адресою https://charts.helm.sh/incubator. Ви можете виконати наступну команду для його відновлення:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update\n```\n\n### Я отримую попередження '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}\n\nСтарий репозиторій чартів Google було замінено новим репозиторієм Helm чартів.\n\nЗапустіть наступну команду для остаточного виправлення цього:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update\n```\n\nЯкщо ви отримуєте подібну помилку для `incubator`, виконайте цю команду:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update\n```\n\n### Коли я додаю репозиторій 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}\n\nРепозиторії чартів 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`.\n\n### На GKE (Google Container Engine) я отримую \"No SSH tunnels currently open\" {#on-gke-google-container-engine-i-get-no-ssh-tunnels-currently-open}\n\n```none\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nЩе одна версія повідомлення про помилку:\n\n```none\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nПроблема в тому, що ваш локальний файл конфігурації Kubernetes повинен містити правильні облікові дані.\n\nКоли ви створюєте кластер на GKE, він надає вам облікові дані, включаючи SSL сертифікати та центри сертифікації. Їх потрібно зберігати у файлі конфігурації Kubernetes (стандартно: `~/.kube/config`), щоб `kubectl` та `helm` могли їх використовувати.\n\n### Після міграції з Helm 2 команда `helm list` показує лише деякі (або жодного) мої релізи {#after-migration-from-helm-2-helm-list-shows-only-some-or-none-of-my-releases}\n\nМожливо, ви пропустили те, що Helm 3 тепер використовує простори імен кластера для визначення релізів. Це означає, що для всіх команд, що посилаються на реліз, ви повинні або:\n\n* покластися на поточний простір імен в активному контексті kubernetes (як описано командою `kubectl config view --minify`),\n* вказати правильний простір імен, використовуючи прапорець `--namespace`/`-n`, або\n* для команди `helm list`, вказати прапорець `--all-namespaces`/`-A`.\n\nЦе стосується `helm ls`, `helm uninstall` та всіх інших команд `helm`, що посилаються на реліз.\n\n### На macOS звертається до файлу `/etc/.mdns_debug`. Чому? {#on-macos-the-file-etcmdns_debug-is-accessed-why}\n\nМи знаємо про випадок на macOS, коли Helm намагається звернутися до файлу з назвою `/etc/.mdns_debug`. Якщо файл існує, Helm тримає дескриптор файлу відкритим під час виконання.\n\nЦе викликано бібліотекою MDNS macOS. Вона намагається завантажити цей файл для читання налаштувань відладки (якщо увімкнено). Дескриптор файлу, ймовірно, не повинен залишатися відкритим, і ця проблема була передана Apple. Однак це macOS, а не Helm, викликає цю поведінку.\n\nЯкщо ви не хочете, щоб Helm завантажував цей файл, ви можете спробувати скомпілювати Helm як статичну бібліотеку, яка не використовує стек мережі хосту. Це збільшить розмір бінарного файлу Helm, але завадить відкриттю файлу.\n\nЦю проблему спочатку було позначено як потенційну проблему безпеки. Але з того часу було визначено, що ця поведінка не має жодних недоліків або вразливостей.\n\n### helm repo add не вдається, хоча раніше працювало {#helm-repo-add-fails-when-it-used-to-work}\n\nУ helm 3.3.1 та раніше команда `helm repo add <reponame> <url>` не видає жодного виходу, якщо ви намагаєтеся додати репозиторій, який вже існує. Прапорець `--no-update` викликав помилку, якщо репозиторій вже був зареєстрований.\n\nУ helm 3.3.2 та пізніших версіях спроба додати наявний репозиторій викличе помилку:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nТепер стандартна поведінка змінилася. Прапорець `--no-update` тепер ігнорується, а якщо ви хочете замінити (перезаписати) наявний репозиторій, ви можете використовувати `--force-update`.\n\nЦе повʼязано з переломною зміною для виправлення проблеми безпеки, як пояснено в [замітках про реліз Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2).\n\n### Увімкнення ведення логів клієнта Kubernetes {#enabling-kubernetes-client-logging}\n\nДрук повідомлень логу для відладки клієнта Kubernetes можна увімкнути за допомогою прапорців [klog](https://pkg.go.dev/k8s.io/klog). Використання прапорця `-v` для налаштування рівня деталізації буде достатнім для більшості випадків.\n\nНаприклад:\n\n```shell\nhelm list -v 6\n```\n\n### Встановлення Tiller припинило працювати і доступ заборонено {#installing-tiller-stopped-working-and-access-is-denied}\n\nРелізи Helm раніше були доступні за адресою <https://storage.googleapis.com/kubernetes-helm/>. Як пояснюється в [\"Announcing get.helm.sh\"](/blog/get-helm-sh/), офіційне місце розташування змінилося у червні 2019 року. [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) робить всі старі образи Tiller доступними.\n\nЯкщо ви намагаєтеся завантажити старі версії Helm з кошику зберігання, який ви використовували раніше, ви можете виявити, що вони відсутні:\n\n```none\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\n[Місце розташування старих образів Tiller](https://gcr.io/kubernetes-helm/tiller) розпочало видалення образів у серпні 2021 року. Ми зробили ці образи доступними за адресою [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Наприклад, щоб завантажити версію v2.17.0, замініть:\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\nна:\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nЩоб ініціалізувати Helm v2.17.0:\n\n`helm init —upgrade`\n\nАбо, якщо потрібна інша версія, використовуйте прапорець `--tiller-image`, щоб перевизначити стандартне місце розташування та встановити конкретну версію Helm v2:\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**Примітка:** Розробники 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) сьогодні.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: Видалення\nsidebar_position: 3\n---\n\n## Видалення {#uninstalling}\n\n### Я хочу видалити свій локальний Helm. Де зберігаються всі його файли? {#i-want-to-uninstall-my-local-helm-where-are-all-of-its-files}\n\nРазом з бінарним файлом `helm`, Helm зберігає деякі файли в наступних розташуваннях:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nНаступна таблиця показує стандартні теки для кожного з цих розташувань, за операційними системами:\n\n| Операційна система | Шлях до кешу                | Шлях до конфігурацій             | Шлях до даних               |\n|--------------------|-----------------------------|----------------------------------|-----------------------------|\n| Linux              | `$HOME/.cache/helm`         | `$HOME/.config/helm`             | `$HOME/.local/share/helm`   |\n| macOS              | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm`        |\n| Windows            | `%TEMP%\\helm`               | `%APPDATA%\\helm`                 | `%APPDATA%\\helm`            |\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/glossary/index.mdx",
    "content": "---\ntitle: Глосарій\ndescription: Терміни, що використовуються для опису компонентів архітектури Helm.\nsidebar_position: 10\n---\n\n# Глосарій {#glossary}\n\n## Чарт {#chart}\n\nПакет Helm, що містить інформацію, достатню для встановлення набору ресурсів Kubernetes у кластер Kubernetes.\n\nЧарти містять файл `Chart.yaml`, а також шаблони, стандартні значення (`values.yaml`) та залежності.\n\nЧарти розробляються у чітко визначеній структурі тек, а потім упаковуються у формат архіву, що називається _чарт-архівом_.\n\n## Чарт-архів {#chart-archive}\n\n_Чарт-архів_ — це архів, що містить tar і gzipped (і, за бажанням, підписаний) чарт.\n\n## Залежність чарту (субчарти) {#chart-dependency-subcharts}\n\nЧарти можуть залежати від інших чартів. Залежність може бути здійснена двома способами:\n\n- М’яка залежність: Чарт може просто не функціонувати без іншого чарту, встановленого в кластері. Helm не надає інструментів для цього випадку. У цьому випадку залежності можуть управлятися окремо.\n- Жорстка залежність: Чарт може містити (всередині теки `charts/`) інший чарт, від якого він залежить. У цьому випадку, встановлення чарту також встановить усі його залежності. У цьому випадку чарт і його залежності управляються як колекція.\n\nКоли чарт упаковується (через `helm package`), всі його жорсткі залежності упаковуються разом з ним.\n\n## Версія чарту {#chart-version}\n\nЧарти версіонуються відповідно до [специфікації SemVer 2](https://semver.org). Номер версії є обов’язковим для кожного чарта.\n\n## Chart.yaml\n\nІнформація про чарт зберігається в спеціальному файлі з назвою `Chart.yaml`. Кожен чарт повинен мати цей файл.\n\n## Helm (та helm) {#helm-and-helm}\n\nHelm — це менеджер пакетів для Kubernetes. Як менеджер пакетів для операційних систем полегшує встановлення інструментів на ОС, так Helm полегшує встановлення застосунків та ресурсів у кластери Kubernetes.\n\nХоча _Helm_ — це назва проєкту, клієнт командного рядка також називається `helm`. Зазвичай, коли йдеться про проєкт, _Helm_ пишеться з великої літери. Коли йдеться про клієнт, _helm_ пишеться з маленької літери.\n\n## Конфігураційні файли Helm (XDG) {#helm-configuration-files-xdg}\n\nHelm зберігає свої конфігураційні файли в теках XDG. Ці теки створюються при першому запуску `helm`.\n\n## Kube Config (KUBECONFIG)\n\nКлієнт Helm дізнається про кластери Kubernetes, використовуючи файли у форматі _Kube config_. Стандартно, Helm намагається знайти цей файл у місці, де його створює `kubectl` (`$HOME/.kube/config`).\n\n## Лінтинг (Linting) {#lint-linting}\n\nЛінтинг чарта — це перевірка того, що він відповідає домовленостям і вимогам стандарту чарту Helm. Helm надає інструменти для цього, зокрема команду `helm lint`.\n\n## Provenance (Файл provenance) {#provenance-provenance-file}\n\nЧарти Helm можуть супроводжуватися _файлом provenance_, який надає інформацію про те, звідки походить чарт і що він містить.\n\nФайли provenance є частиною історії безпеки Helm. Файл provenance містить криптографічний хеш файлу чарт-архіву, дані Chart.yaml і блок підпису (блок OpenPGP \"clearsign\"). У поєднанні з вʼязкою ключів він надає користувачам чартів можливість:\n\n- Перевірити, що чарт був підписаний довіреною стороною\n- Перевірити, що файл чарту не був змінений\n- Перевірити вміст метаданих чарту (`Chart.yaml`)\n- Швидко зіставити чарт з даними provenance\n\nФайли provenance мають розширення `.prov` і можуть бути надані з сервера репозиторію чартів або будь-якого іншого HTTP-сервера.\n\n## Реліз {#release}\n\nКоли чарт встановлюється, бібліотека Helm створює _реліз_, щоб відстежувати це встановлення.\n\nОдин і той же чарт може бути встановлений кілька разів в одному кластері, створюючи багато різних релізів. Наприклад, можна встановити три бази даних PostgreSQL, запустивши `helm install` три рази з різними іменами релізів.\n\n## Номер релізу (Версія релізу) {#release-number-release-version}\n\nОдин реліз може бути оновлений кілька разів. Для відстеження релізів, коли вони змінюються, використовується послідовний лічильник. Після першого `helm install` реліз матиме _номер релізу_ 1. Кожного разу, коли реліз оновлюється або скасовується, номер релізу буде збільшений.\n\n## Відкат {#rollback}\n\nРеліз можна оновити до новішого чарту або конфігурації. Але оскільки історія релізів зберігається, реліз також може бути _відкочений_ до попереднього номера релізу. Це робиться за допомогою команди `helm rollback`.\n\nВажливо, що реліз, що відкочується, отримає новий номер релізу.\n\n| Операція  | Номер релізу                                       |\n|-----------|----------------------------------------------------|\n| встановлення | реліз 1                                          |\n| оновлення    | реліз 2                                          |\n| оновлення    | реліз 3                                          |\n| відкат 1   | реліз 4 (але виконує ту ж конфігурацію, що й реліз 1) |\n\nВищенаведена таблиця ілюструє, як номери релізів збільшуються під час встановлення, оновлення та відкату.\n\n## Бібліотека Helm (або SDK) {#helm-library-or-sdk}\n\nБібліотека Helm (або SDK) належить до коду Go, який безпосередньо взаємодіє з сервером API Kubernetes для встановлення, оновлення, запиту та видалення ресурсів Kubernetes. Її можна імплементувати у проєкт для використання Helm як бібліотеки клієнта замість CLI.\n\n## Репозиторій (Repo, Репозиторій чартів) {#repository-repo-chart-repository}\n\nЧарти Helm можуть зберігатися на спеціалізованих HTTP-серверах, які називаються _репозиторіями чартів_ (_репозиторіями_, або просто _repo_).\n\nСервер репозиторію чартів є простим HTTP-сервером, який може надавати файл `index.yaml`, який описує групу чартів, і надає інформацію про те, звідки можна завантажити кожен чарт. (Багато серверів репозиторіїв чартів надають як чарт, так і файл `index.yaml`.)\n\nКлієнт Helm може вказати нуль або більше репозиторіїв чартів. Стандартно клієнти Helm не налаштовані на жодні репозиторії чартів. Репозиторії чартів можна додати в будь-який час за допомогою команди `helm repo add`.\n\n## Реєстр чартів (OCI реєстр) {#chart-registry-oci-based-registry}\n\nРеєстр чартів Helm є системою зберігання та розподілу на основі [OCI](https://opencontainers.org/about/overview/), яка використовується для розміщення та обміну пакетами чартів Helm. Для отримання додаткової інформації див. [документацію Helm про реєстри](/topics/registries.md).\n\n## Значення (Файли значень, values.yaml) {#values-values-files-valuesyaml}\n\nЗначення надають спосіб перевизначити стандартні значення  шаблонів вашою інформацією.\n\nЧарти Helm є \"параметризованими\", що означає, що розробник чарта може експонувати конфігурацію, яку можна перевизначити під час установки. Наприклад, чарт може експонувати поле `username`, яке дозволяє встановити імʼя користувача для сервісу.\n\nЦі експоновані змінні називаються _значеннями_ в термінах Helm.\n\nЗначення можна встановити під час операцій `helm install` та `helm upgrade`, або безпосередньо передаючи їх, або використовуючи файл `values.yaml`.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/_category_.json",
    "content": "{\n  \"link\": { \"type\": \"doc\", \"id\": \"helm-category\" }\n}\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\nМенеджер пакетів Helm для Kubernetes.\n\n### Опис {#synopsis}\n\nМенеджер пакетів для Kubernetes\n\nЗагальні дії для Helm:\n\n- helm search:    пошук чартів\n- helm pull:      завантаження чарту у вашу локальну теку для перегляду\n- helm install:   завантаження чарту в Kubernetes\n- helm list:      перегляд списку релізів чартів\n\nЗмінні середовища:\n\n| Імʼя                               | Опис                                                                                                       |\n|------------------------------------|------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | вказує альтернативне місце для зберігання кешованих файлів.                                                 |\n| $HELM_CONFIG_HOME                  | вказує альтернативне місце для зберігання конфігурації Helm.                                                |\n| $HELM_DATA_HOME                    | вказує альтернативне місце для зберігання даних Helm.                                                       |\n| $HELM_DEBUG                        | вказує, чи працює Helm в режимі налагодження                                                               |\n| $HELM_DRIVER                       | вказує драйвер бекенду для зберігання. Значення: configmap, secret, memory, sql.                            |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | вказує рядок підключення, який повинен використовувати SQL-драйвер для зберігання.                          |\n| $HELM_MAX_HISTORY                  | вказує максимальну кількість історії релізів Helm.                                                          |\n| $HELM_NAMESPACE                    | вказує простір імен, що використовується для операцій Helm.                                                 |\n| $HELM_NO_PLUGINS                   | відключає втулки. Встановіть HELM_NO_PLUGINS=1, щоб відключити втулки.                                    |\n| $HELM_PLUGINS                      | вказує шлях до теки плагінів                                                                          |\n| $HELM_REGISTRY_CONFIG              | вказує шлях до файлу конфігурації реєстру.                                                                  |\n| $HELM_REPOSITORY_CACHE             | вказує шлях до теки кешу репозиторіїв                                                                 |\n| $HELM_REPOSITORY_CONFIG            | вказує шлях до файлу репозиторіїв                                                                           |\n| $KUBECONFIG                        | вказує альтернативний файл конфігурації Kubernetes (стандартно \"~/.kube/config\")                       |\n| $HELM_KUBEAPISERVER                | вказує точку доступу сервера API Kubernetes для автентифікації                                              |\n| $HELM_KUBECAFILE                   | вказує файл центру сертифікації для Kubernetes.                                                          |\n| $HELM_KUBEASGROUPS                 | вказує групи для використання імперсонації, використовуючи список, розділений комами.                       |\n| $HELM_KUBEASUSER                   | вказує імʼя користувача для імперсонації під час операції.                                                  |\n| $HELM_KUBECONTEXT                  | вказує імʼя контексту kubeconfig.                                                                           |\n| $HELM_KUBETOKEN                    | вказує токен Bearer KubeToken для автентифікації.                                                          |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | вказує, чи слід пропустити перевірку сертифіката сервера API Kubernetes (небезпечний режим)                 |\n| $HELM_KUBETLS_SERVER_NAME          | вказує імʼя сервера для перевірки сертифіката сервера API Kubernetes                                         |\n| $HELM_BURST_LIMIT                  | вказує стандартне обмеження на кількість викликів у випадку великої кількості CRD (стандартно — 100, -1 для відключення) |\n| $HELM_QPS                          | вказує кількість запитів в секунду у випадках, коли велика кількість викликів перевищує параметр для більш високих значень |\n\nHelm зберігає кеш, конфігурацію та дані на основі наступного порядку конфігурації:\n\n- Якщо встановлена змінна середовища HELM_*_HOME, вона буде використана\n- В іншому випадку на системах, що підтримують специфікацію базової теки XDG, будуть використані змінні XDG\n- Якщо не встановлено інше місце, буде використане стандартне місце залежно від операційної системи\n\nТипово, стандартні теки залежать від операційної системи. Нижче наведені їх значення:\n\n| Операційна система | Шлях до кешу               | Шлях до конфігурації          | Шлях до даних            |\n|--------------------|---------------------------|------------------------------|--------------------------|\n| Linux              | $HOME/.cache/helm         | $HOME/.config/helm           | $HOME/.local/share/helm  |\n| macOS              | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm      |\n| Windows            | %TEMP%\\helm               | %APPDATA%\\helm               | %APPDATA%\\helm           |\n\n### Параметри {#options}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           вмикає розширений вивід\n  -h, --help                            довідка helm\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n- [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell\n- [helm create](/helm/helm_create.md) — створити новий чарт з вказаною назвою\n- [helm dependency](/helm/helm_dependency.md) — керування залежностями чарту\n- [helm env](/helm/helm_env.md) — інформація про середовище клієнта helm\n- [helm get](/helm/helm_get.md) — завантажити розширену інформацію про зазначений реліз\n- [helm history](/helm/helm_history.md) — отримати історію релізу\n- [helm install](/helm/helm_install.md) — встановити чарт\n- [helm lint](/helm/helm_lint.md) — перевірити чарт на можливі проблеми\n- [helm list](/helm/helm_list.md) — переглянути список релізів\n- [helm package](/helm/helm_package.md) — упакувати теку чарту в архів чарту\n- [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm\n- [helm pull](/helm/helm_pull.md) — завантажити чарт з репозиторію та (за бажанням) розпакувати його в локальній теці\n- [helm push](/helm/helm_push.md) — завантажити чарт до віддаленого сервера\n- [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру\n- [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів\n- [helm rollback](/helm/helm_rollback.md) — відкотити реліз до попередньої версії\n- [helm search](/helm/helm_search.md) — шукати ключове слово в чартах\n- [helm show](/helm/helm_show.md) — показати інформацію про чарт\n- [helm status](/helm/helm_status.md) — відобразити статус зазначеного релізу\n- [helm template](/helm/helm_template.md) — локально рендерити шаблони\n- [helm test](/helm/helm_test.md) — запустити тести для релізу\n- [helm uninstall](/helm/helm_uninstall.md) — видалити реліз\n- [helm upgrade](/helm/helm_upgrade.md) — оновити реліз\n- [helm verify](/helm/helm_verify.md) — перевірити, чи підписаний та, чи є дійсним чарт за вказаним шляхом\n- [helm version](/helm/helm_version.md) — відобразити інформацію про версію клієнта\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\nГенерація скриптів автодоповнення для вказаної оболонки\n\n### Опис {#synopsis}\n\nГенерація скриптів автодоповнення Helm для вказаної оболонки.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка для completion\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           включити розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n* [helm completion bash](/helm/helm_completion_bash.md) — генерувати скрипт автодоповнення для bash\n* [helm completion fish](/helm/helm_completion_fish.md) — генерувати скрипт автодоповнення для fish\n* [helm completion powershell](/helm/helm_completion_powershell.md) — генерувати скрипт автодоповнення для powershell\n* [helm completion zsh](/helm/helm_completion_zsh.md) — генерувати скрипт автодоповнення для zsh\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\nГенерація скрипта автодоповнення для bash\n\n### Опис {#synopsis}\n\nГенерація скрипта автодоповнення Helm для shell bash.\n\nДля завантаження автодоповнень у вашій поточній shell-сесії:\n\n```shell\nsource <(helm completion bash)\n```\n\nДля завантаження автодоповнень для кожної нової сесії, виконайте один раз:\n\n- Linux:\n\n  ```shell\n  helm completion bash > /etc/bash_completion.d/helm\n  ```\n\n- MacOS:\n\n  ```shell\n  helm completion bash > /usr/local/etc/bash_completion.d/helm\n  ```\n\n```shell\nhelm completion bash [прапорці]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка для bash\n      --no-descriptions   вимкнути описи автодоповнення\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           вмикає розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n- [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\nГенерація скрипта автодоповнення для fish\n\n### Опис {#synopsis}\n\nГенерація скрипта автодоповнення Helm для shell fish.\n\nДля завантаження автодоповнень у вашій поточній shell-сесії:\n\n```shell\nhelm completion fish | source\n```\n\nДля завантаження автодоповнень для кожної нової сесії, виконайте один раз:\n\n```shell\nhelm completion fish > ~/.config/fish/completions/helm.fish\n```\n\nПотрібно запустити нову shell-сесію, щоб ці налаштування набули чинності.\n\n```shell\nhelm completion fish [прапорці]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка для fish\n      --no-descriptions   вимкнути описи автодоповнення\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           включити розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\nГенерація скрипта автодоповнення для PowerShell\n\n### Опис {#synopsis}\n\nГенерація скрипта автодоповнення для PowerShell.\n\nДля завантаження автодоповнень у вашій поточній shell-сесії:\n\n```powershell\nPS C:\\> helm completion powershell | Out-String | Invoke-Expression\n```\n\nДля завантаження автодоповнень для кожної нової сесії, додайте вивід вищенаведеної команди до вашого профілю PowerShell.\n\n\n```shell\nhelm completion powershell [прапорці]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка для PowerShell\n      --no-descriptions   вимкнути описи автодоповнення\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           включити розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\nГенерація скрипта автодоповнення для zsh\n\n### Опис {#synopsis}\n\nГенерація скрипта автодоповнення Helm для оболонки zsh.\n\nДля завантаження автодоповнень у вашій поточній shell-сесії:\n\n```shell\nsource <(helm completion zsh)\n```\n\nДля завантаження автодоповнень для кожної нової сесії, виконайте один раз:\n\n```shell\nhelm completion zsh > \"${fpath[1]}/_helm\"\n```\n\n```shell\nhelm completion zsh [прапорці]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка для zsh\n      --no-descriptions   вимкнути описи автодоповнення\n```\n\n### Параметри, успадковані від батьківських команд\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           включити розширений вивід\n      --kube-apiserver string           адреса і порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВИТИСЯ ТАКОЖ {#see-also}\n\n* [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\nстворити новий чарт із вказаним імʼям\n\n### Опис {#synopsis}\n\nЦя команда створює теку чарта разом із загальними файлами та\nтеками, що використовуються в чартах.\n\nНаприклад, `helm create foo` створить структуру тек, що виглядає\nприблизно так:\n\n```none\n    foo/\n    ├── .helmignore   # Містить шаблони для ігнорування при упаковці Helm-чартів.\n    ├── Chart.yaml    # Інформація про ваш чарт\n    ├── values.yaml   # Стандартні значення для ваших шаблонів\n    ├── charts/       # Чарти, від яких залежить цей чарт\n    └── templates/    # Файли шаблонів\n        └── tests/    # Файли тестів\n```\n\n`helm create` приймає шлях як аргумент. Якщо теки у вказаному шляху не існують, Helm спробує створити їх по ходу. Якщо вказане призначення існує і там є файли, конфліктуючі файли будуть перезаписані, але інші файли залишаться незмінними.\n\n```none\nhelm create NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help             довідка для create\n  -p, --starter string   імʼя або абсолютний шлях до стартового шаблону Helm\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\nкерування залежностями чарту\n\n### Опис {#synopsis}\n\nКеруйте залежностями чарту.\n\nЧарти Helm зберігають свої залежності в теці `charts/`. Для розробників чарту часто простіше керувати залежностями у файлі `Chart.yaml`, який декларує всі залежності.\n\nКоманди залежностей працюють з цим файлом, полегшуючи синхронізацію між бажаними залежностями та фактичними залежностями, збереженими в теці `charts/`.\n\nНаприклад, цей файл Chart.yaml декларує дві залежності:\n\n```yaml\n# Chart.yaml\ndependencies:\n- name: nginx\n  version: \"1.2.3\"\n  repository: \"https://example.com/charts\"\n- name: memcached\n  version: \"3.2.1\"\n  repository: \"https://another.example.com/charts\"\n```\n\nПоле 'name' повинно містити імʼя чарту, яке повинно збігатися з імʼям у файлі 'Chart.yaml' цього чарту.\n\nПоле 'version' повинно містити семантичну версію або діапазон версій.\n\nURL-адреса 'repository' повинна вказувати на репозиторій чарту. Helm очікує, що додавання '/index.yaml' до URL-адреси дозволить отримати індекс репозиторію чарту. Примітка: 'repository' може бути псевдонімом, який повинен починатися з 'alias:' або '@'.\n\nПочинаючи з версії 2.2.0, репозиторій може бути визначений як шлях до теки залежних чартів, збережених локально. Шлях повинен починатися з префіксу \"file://\". Наприклад,\n\n```yaml\n# Chart.yaml\ndependencies:\n- name: nginx\n  version: \"1.2.3\"\n  repository: \"file://../dependency_chart/nginx\"\n```\n\nЯкщо залежний чарт отримано локально, його не потрібно додавати до helm за допомогою команди \"helm repo add\". Підтримується також відповідність версій для цього випадку.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка для dependency\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації підучас операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для викорисуання\n      --kube-insecure-skip-tls-verify   якщо встановлено truу, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить вашу HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифікату сервера API Kubernetes. Якщо уе вказано, використовується імʼя хоста, що використовуєтуся для пудключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconуig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32           у         кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n* [helm dependency build](/helm/helm_dependency_build.md) — відновлення теки charts/ на основі файлу Chart.lock\n* [helm dependency list](/helm/helm_dependency_list.md) — перелік залежностей для даного чарта\n* [helm dependency update](/helm/helm_dependency_update.md) — оновлення charts/ на основі вмісту Chart.yaml\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\nперебудувати теку charts/ на основі файлу Chart.lock\n\n### Опис {#synopsis}\n\nЦя команда будує теку `charts/` на основі файлу `Chart.lock`.\n\nКоманда `build` використовується для відновлення залежностей чарту до стану, зазначеного у файлі блокування. Вона не переузгоджуватиме залежності, як це робить `helm dependency update`.\n\nЯкщо файл блокування не знайдено, `helm dependency build` дзеркально повторюватиме поведінку команди `helm dependency update`.\n\n```none\nhelm dependency build CHART [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help             довідка для build\n      --keyring string   вʼязка ключів, що містить публічні ключі (стандартно \"~/.gnupg/pubring.gpg\")\n      --skip-refresh     не оновлювати кеш локального репозиторію\n      --verify           перевіряти пакети за підписами\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm dependency](/helm/helm_dependency.md) — керувати залежностями чарту\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\nсписок залежностей для заданого чарту\n\n### Опис {#synopsis}\n\nПерелічує всі залежності, зазначені в чарті.\n\nЦя команда приймає на вхід як архіви чарту, так і теки чарту. Вона не змінює вміст чарту.\n\nВикликається помилка, якщо чарт не може бути завантажений.\n\n```none\nhelm dependency list CHART [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help                 довідка для list\n      --max-col-width uint   максимальна ширина стовпця для таблиці виводу (стандартно 80)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm dependency](/helm/helm_dependency.md) — керувати залежностями чарту\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\nоновлення charts/ на основі вмісту Chart.yaml\n\n### Опис {#synopsis}\n\nОновлює залежності на диску, щоб відобразити стан, зазначений у Chart.yaml.\n\nЦя команда перевіряє, що необхідні чарти, зазначені в `Chart.yaml`, присутні в `charts/` і відповідають прийнятній версії. Вона завантажує найновіші чарти, що задовольняють залежності, та очищає застарілі залежності.\n\nУ разі успішного оновлення буде згенеровано файл блокування, який можна використовувати для відновлення залежностей до точної версії.\n\nЗалежності не обовʼязково повинні бути представлені в `Chart.yaml`. З цієї причини команда оновлення не видалить чарти, якщо вони (а) присутні у файлі `Chart.yaml`, але (б) мають неправильну версію.\n\n```none\nhelm dependency update CHART [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help             довідка для update\n      --keyring string   вʼязка ключів, що містить публічні ключі (стандартно \"~/.gnupg/pubring.gpg\")\n      --skip-refresh     не оновлювати локальний кеш репозиторіїв\n      --verify           перевірити пакети на відповідність підписам\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm dependency](/helm/helm_dependency.md) — керувати залежностями чарту\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\nінформація про середовище клієнта Helm\n\n### Опис {#synopsis}\n\nКоманда `helm env` виводить усю інформацію про середовище, яке використовується Helm.\n\n```shell\nhelm env [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка для env\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\nзавантажити розширену інформацію про вказаний реліз\n\n### Опис {#synopsis}\n\nЦя команда складається з кількох підкоманд, які можна використовувати для отримання розширеної інформації про реліз, включаючи:\n\n- Значення, що використовувалися для генерації релізу\n- Сформований файл маніфесту\n- Примітки, надані чартом релізу\n- Хуки, асоційовані з релізом\n- Метадані релізу\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка для get\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n- [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n- [helm get all](/helm/helm_get_all.md) — завантажити всю інформацію про вказаний реліз\n- [helm get hooks](/helm/helm_get_hooks.md) — завантажити всі хуки для вказаного релізу\n- [helm get manifest](/helm/helm_get_manifest.md) — завантажити маніфест для вказаного релізу\n- [helm get metadata](/helm/helm_get_metadata.md) — отримати метадані для вказаного релізу\n- [helm get notes](/helm/helm_get_notes.md) — завантажити примітки для вказаного релізу\n- [helm get values](/helm/helm_get_values.md) — завантажити файл значень для вказаного релізу\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\nзавантажити всю інформацію про вказаний реліз\n\n### Опис {#synopsis}\n\nЦя команда виводить зрозумілий для людини набір інформації про нотатки, хуки, надані значення та згенерований маніфест для вказаного релізу.\n\n```shell\nhelm get all RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка для all\n      --revision int      отримати вказаний реліз з версією\n      --template string   шаблон Go для форматування виводу, напр: {{.Release.Name}}\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\nзавантажити всі хуки для вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда завантажує хуки для вказаного релізу.\n\nХуки форматуються у YAML і розділені роздільником YAML '---\\n'.\n\n```shell\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Параметри\n\n```none\n  -h, --help           довідка для hooks\n      --revision int   отримати вказаний реліз з версією\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (станлартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (станлартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (станлартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\nзавантажити маніфест для вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда завантажує згенерований маніфест для вказаного релізу.\n\nМаніфест є YAML-кодованим представленням ресурсів Kubernetes, які були згенеровані з чарту(ів) цього релізу. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені в маніфест.\n\n```shell\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help           довідка для manifest\n      --revision int   отримати вказаний реліз з версією\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\nЦя команда завантажує метадані для вказаного релізу\n\n```shell\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help            довідка для metadata\n  -o, --output format   виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --revision int    вказати версію релізу\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\nзавантажити нотатки для вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда відображає нотатки, надані чартом для вказаного релізу.\n\n```shell\nhelm get notes RELEASE_NAME [flags]\n```\n\n### Параметри\n\n```none\n  -h, --help           довідка для notes\n      --revision int   отримати реліз з вказаною версією\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\nзавантажити файл значень для вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда завантажує файл значень для вказаного релізу.\n\n```shell\nhelm get values RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -a, --all             вивести всі (обчислені) значення\n  -h, --help            довідка для values\n  -o, --output format   друкує вихід у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --revision int    отримати реліз з вказаною версією\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\nотримати історію релізу\n\n### Опис {#synopsis}\n\nHistory виводить історичні ревізії для вказаного релізу.\n\nСтандартна максимальна кількість ревізій, що повертається — 256. Встановлення '--max' налаштовує максимальну довжину списку ревізій, що повертаються.\n\nІсторичний набір релізів виводиться у вигляді відформатованої таблиці, наприклад:\n\n```console\n$ helm history angry-bird\nREVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n```\n\n```shell\nhelm history RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help            довідка для history\n      --max int         максимальна кількість ревізій, включених в історію (стандартно 256)\n  -o, --output format   виводити результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### Дивіться також {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\nВстановлює чарт\n\n### Опис {#synopsis}\n\nЦя команда встановлює архів чарту.\n\nАргумент для `install` має бути посиланням на чарт, шляхом до запакованого чарту, шляхом до розпакованої теки чарту або URL.\n\nЩоб перезаписати значення в чартах, використовуйте прапорець `--values` та передайте файл або прапорець `--set`, щоб передати конфігурацію з командного рядка. Щоб примусово встановити значення рядка, використовуйте `--set-string`. Ви також можете використовувати `--set-file`, щоб задати окремі значення з файлу, якщо значення занадто велике для командного рядка або є динамічно згенерованим. Ви також можете використовувати `--set-json`, щоб встановити значення JSON (скаляри/обʼєкти/масиви) з командного рядка.\n\n```shell\n$ helm install -f myvalues.yaml myredis ./redis\n```\n\nабо\n\n```shell\n$ helm install --set name=prod myredis ./redis\n```\n\nабо\n\n```shell\n$ helm install --set-string long_int=1234567890 myredis ./redis\n```\n\nабо\n\n```shell\n$ helm install --set-file my_script=dothings.sh myredis ./redis\n```\n\nабо\n\n```shell\n$ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n```\n\nВи можете вказати прапорець `--values`/'-f' кілька разів. Пріоритет буде наданий останньому (правому) файлу, що вказаний. Наприклад, якщо як `myvalues.yaml`, так і `override.yaml` містять ключ `Test`, значення, встановлене в `override.yaml`, матиме пріоритет:\n\n```shell\n$ helm install -f myvalues.yaml -f override.yaml myredis ./redis\n```\n\nВи можете вказати прапорець `--set` кілька разів. Пріоритет буде наданий останньому (правому) встановленому значенню. Наприклад, якщо для ключа `foo` встановлені значення `bar` і `newbar`, значення `newbar` матиме пріоритет:\n\n```shell\n$ helm install --set foo=bar --set foo=newbar myredis ./redis\n```\n\nАналогічно, у наступному прикладі `foo` встановлено в `[\"four\"]`:\n\n```shell\n$ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n```\n\nА в наступному прикладі `foo` встановлено в `{\"key1\":\"value1\",\"key2\":\"bar\"}`:\n\n```shell\n$ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n```\n\nЩоб перевірити згенеровані маніфести релізу без встановлення чарту, можна поєднати прапорці `--debug` і `--dry-run`.\n\nПрапорець `--dry-run` виведе усі згенеровані маніфести чартів, включно з Secrets які можуть містити конфіденційні значення. Щоб приховати секрети Kubernetes, скористайтеся прапорцем `--hide-secret`. Будь ласка, уважно вивчіть, як і коли використовувати ці прапорці.\n\nЯкщо встановлено прапорець `--verify`, чарт ПОВИНЕН мати файл автентифікації, і цей файл ПОВИНЕН пройти всі кроки перевірки.\n\nЄ шість різних способів казати чарт, який ви хочете встановити:\n\n1. З посиланням на чарт: `helm install mymaria example/mariadb`\n2. З шляхом до запакованого чарту: `helm install mynginx ./nginx-1.2.3.tgz`\n3. З шляхом до розпакованої теки чарту: `helm install mynginx ./nginx`\n4. З абсолютним URL: `helm install mynginx https://example.com/charts/nginx-1.2.3.tgz`\n5. З посиланням на чарт і URL репозиторію: `helm install --repo https://example.com/charts/ mynginx nginx`\n6. З OCI реєстрами: `helm install mynginx --version 1.2.3 oci://example.com/charts/nginx`\n\nПОСИЛАННЯ НА ЧАРТ\n\nПосилання на чарт — це зручний спосіб посилатися на чарт у репозиторії чарту.\n\nКоли ви використовуєте посилання на чарт з префіксом репозиторію (`example/mariadb`), Helm шукатиме в локальній конфігурації репозиторій чарту з імʼям `example`, а потім шукатиме чарт у цьому репозиторії, чия назва є `mariadb`. Він встановить останню стабільну версію цього чарту, поки ви не вкажете прапорець `--devel`, щоб також включити версії розробки (альфа, бета та реліз-кандидати), або не надасте номер версії за допомогою прапорця `--version`.\n\nЩоб переглянути список репозиторіїв чартів, використовуйте `helm repo list`. Щоб шукати чарти в репозиторії, використовуйте `helm search`.\n\n```shell\nhelm install [NAME] [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --atomic                                     якщо вказано, процес встановлення видалить всnановлення у разі невдачі. Прапорець --wait буде встановлено автоматично, якщо використовується --atomic\n      --ca-file string                             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string                           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n      --create-namespace                           створити простір імен релізу, якщо його не існує\n      --description string                         додати власний опис\n      --devel                                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n      --disable-openapi-validation                 якщо вказано, процес встановлення не буде перевіряти відрендерені шаблони за схемою OpenAPI Kubernetes\n      --dry-run string[=\"client\"]                  імітувати встановлення. Якщо --dry-run вказано без жодної опції або як '--dry-run=client', він не буде намагатися підключитися до кластера. Встановлення '--dry-run=server' дозволяє намагатися підключитися до кластера.\n      --enable-dns                                 увімкнути DNS запити при рендерингу шаблонів\n      --force                                      примусово оновлювати ресурси через стратегію заміни\n  -g, --generate-name                              згенерувати імʼя (та опустити параметр NAME)\n  -h, --help                                       довідка install\n      --hide-notes                                 якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту\n      --hide-secret                                приховати Kubernetes Secrets, якщо також використовується прапорець --dry-run\n      --insecure-skip-tls-verify                   пропустити перевірку сертифікатів TLS для завантаження чарту\n      --key-file string                            ідентифікувати клієнта HTTPS за допомогою цього SSL ключового файлу\n      --keyring string                             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно [])\n      --name-template string                       вказати шаблон для назви релізу\n      --no-hooks                                   запобігти виконанню хуків під час встановлення\n  -o, --output format                              виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --pass-credentials                           передати облікові дані всім доменам\n      --password string                            пароль до репозиторію чартів, де розташований запитуваний чарт\n      --plain-http                                 використовувати небезпечні HTTP зʼєднання для завантаження чарту\n      --post-renderer postRendererString           шлях до виконуваного файлу, що використовується для пост-рендерингу. Якщо він існує в $PATH, буде використано двійковий файл, в іншому випадку буде намагатися знайти виконуваний файл за вказаним шляхом\n      --post-renderer-args postRendererArgsSlice   аргумент до пост-рендерера (можна вказати кілька) (стандартно [])\n      --render-subchart-notes                      якщо вказано, рендерити нотатки субчартів разом з батьківським\n      --replace                                    повторно використовувати дане імʼя, тільки якщо це імʼя є вилученим релізом, який залишається в і єсторії. Це є небезпечним в операційному середовищі\n      --repo string                                URL репозиторію чартів, де розташований запитуваний чарт\n      --set stringArray                            встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --set-file stringArray                       встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=pshellath2)\n      --set-json stringArray                       встановити значення JSON в командному рядку (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    встановити літеральне значення STRING в командному рядку\n      --set-string stringArray                     встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --skip-crds                                  якщо вказано, CRD не буде встановлено. Стандартно CRD встановлюються, якщо їх ще немає\n      --skip-schema-validation                     якщо встановлено, вимикає перевірку схеми JSON\n      --timeout duration                           час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с)\n      --username string                            імʼя користувача репозиторію чартів, де розташований запитуваний чарт\n  -f, --values strings                             вказати значення в YAML файлі або URL (можна вказати кілька)\n      --verify                                     перевірити пакет перед використанням\n      --version string                             вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія\n      --wait                                       якщо вказано, буде чекати, поки всі Pods, PVCs, Сервіси і мінімальна кількість Pods Deployment, StatefulSet або ReplicaSet не будуть готові перед позначенням релізу як успішного. Чекати буде стільки, скільки встановлено --timeout\n      --wait-for-jobs                              якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки встановлено --timeout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\nперевіряє чарт на можливі проблеми\n\n### Опис {#synopsis}\n\nЦя команда приймає шлях до чарту і виконує ряд тестів, щоб перевірити, чи чарт добре сформований.\n\nЯкщо лінтер знайде речі, які можуть призвести до помилки при встановленні чарту, він видасть повідомлення [ERROR]. Якщо він знайде проблеми, які порушують конвенції або рекомендації, він видасть повідомлення [WARNING].\n\n```shell\nhelm lint PATH [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help                      довідка lint\n      --kube-version string       версія Kubernetes, що використовується для перевірки можливостей і застарілостей\n      --quiet                     виводити лише попередження та помилки\n      --set stringArray           встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --set-file stringArray      встановити значення з відповідних файлів, зазначених через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2)\n      --set-json stringArray      встановити JSON-значення в командному рядку (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray   встановити літеральне STRING-значення в командному рядку\n      --set-string stringArray    встановити STRING-значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --skip-schema-validation    якщо встановлено, вимикає перевірку схеми JSON\n      --strict                    видавати стан помилки на попередженнях lint\n  -f, --values strings            вказати значення в YAML-файлі або URL (можна вказати кілька)\n      --with-subcharts            перевірити залежні чарти\n```\n\n### Опції, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\nПерегляд релізів\n\n### Опис {#synopsis}\n\nЦя команда виводить список усіх релізів для вказаного простору імен (використовується поточний контекст простору імен, якщо не вказано).\n\nСтандартно вона перераховує тільки ті релізи, які розгорнуті або зазнали невдачі. Прапорці, такі як `--uninstalled` і `--all`, змінюють цю поведінку. Такі прапорці можна комбінувати: `--uninstalled --failed`.\n\nЯк правило елементи сортуються в алфавітному порядку. Використовуйте прапорець `-d`, щоб сортувати за датою релізу.\n\nЯкщо надано прапорець `--filter`, він буде використовуватися як фільтр. Фільтри є регулярними виразами (сумісними з Perl), які застосовуються до списку релізів. Будуть повернуті тільки ті елементи, які відповідають фільтру.\n\n```console\n$ helm list --filter 'ara[a-z]+'\nNAME                UPDATED                                  CHART\nmaudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n```\n\nЯкщо результати не знайдені, команда `helm list` завершиться з кодом 0, але без виводу (або, у випадку без прапорця `-q`, тільки заголовки).\n\nСтандартно повертається до 256 елементів. Щоб обмежити це, використовуйте прапорець `--max`. Встановлення `--max` в 0 не поверне всі результати. Замість цього повернеться стандартне значення сервера, яке може бути значно більше ніж 256. Поєднання прапорців `--max` та `--offset` дозволяє переглядати результати посторінково.\n\n```shell\nhelm list [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -a, --all                  показати всі релізи без жодного фільтра\n  -A, --all-namespaces       список релізів по всіх просторах імен\n  -d, --date                 сортувати за датою релізу\n      --deployed             показати розгорнуті релізи. Якщо нічого іншого не вказано, це буде автоматично увімкнено\n      --failed               показати релізи з помилками\n  -f, --filter string        регулярний вираз (сумісний з Perl). Будь-які релізи, що відповідають виразу, будуть включені в результати\n  -h, --help                 довідка list\n  -m, --max int              максимальна кількість релізів для отримання (стандартно 256)\n      --no-headers           не друкувати заголовки при використанні стандартного формату виводу\n      --offset int           наступний індекс релізу у списку, використовується для зсуву від початкового значення\n  -o, --output format        виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --pending              показати невирішені релізи\n  -r, --reverse              змінити порядок сортування на зворотний\n  -l, --selector string      Селектор (запит за міткою) для фільтрації, підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Працює тільки для сховищ secret (стандартно) та configmap.\n  -q, --short                короткий (тихий) формат виводу\n      --superseded           показати замінені релізи\n      --time-format string   форматувати час, використовуючи форматувальник часу golang. Приклад: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          показати видалені релізи (якщо використовувався `helm uninstall --keep-history`)\n      --uninstalling         показати релізи, які в даний час видаляються\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\nупакувати теку чарту в архів чартів\n\n### Опис {#synopsis}\n\nЦя команда упаковує чарт в архів чартів з версією. Якщо вказано шлях, команда перевіряє цей шлях на наявність чарту (який повинен містити файл `Chart.yaml`) і потім упаковує цю теку.\n\nАрхіви чартів з версією використовуються репозиторіями пакетів Helm.\n\nЩоб підписати чарт, використовуйте прапорець `--sign`. У більшості випадків вам також слід вказати `--keyring path/to/secret/keys` та `--key keyname`.\n\n```shell\nhelm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n```\n\nЯкщо `--keyring` не вказано, Helm зазвичай використовує публічний ключ, якщо тільки ваше середовище не налаштоване інакше.\n\n```shell\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --app-version string       встановити appVersion в чарті на цю версію\n  -u, --dependency-update        оновити залежності з \"Chart.yaml\" в теці \"charts/\" перед упаковкою\n  -d, --destination string       місце для запису чарту. (стандатно \".\")\n  -h, --help                     довідка package\n      --key string               імʼя ключа для використання під час підписання. Використовується, якщо `--sign` є true\n      --keyring string           місце для публічного ключа (стандартно \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string   місце розташування файлу, що містить пароль для ключа підпису. Використовуйте \"-\" для читання з stdin.\n      --sign                     використовувати приватний ключ PGP для підписання цього пакету\n      --version string           встановити версію чарту на цю версію semver\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\nвстановлення, перегляд списку або видалення втулків Helm\n\n### Опис {#synopsis}\n\nКерування втулками Helm на стороні клієнта.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка plugin\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n* [helm plugin install](/helm/helm_plugin_install.md) — встановити втулок Helm\n* [helm plugin list](/helm/helm_plugin_list.md) — переглянути встановлені втулки Helm\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md) — видалити один або кілька втулків Helm\n* [helm plugin update](/helm/helm_plugin_update.md) — оновити один або кілька втулків Helm\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\nвстановити втулок Helm\n\n### Опис {#synopsis}\n\nЦя команда дозволяє встановити втулок з URL до VCS репозиторію або з локального шляху.\n\n```shell\nhelm plugin install [options] <path|url> [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help             довідка install\n      --version string   вказати обмеження версії. Якщо це не вказано, буде встановлена остання версія\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\nвивести перелік встановлених втулків Helm\n\n```shell\nhelm plugin list [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка  list\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\nвидалити один або кілька втулків Helm\n\n```shell\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка uninstall\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\nоновити один або кілька втулків Helm\n\n```shell\nhelm plugin update <plugin>... [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка update\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm plugin](/helm/helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\nзавантажити чарт з репозиторію та (за бажанням) розпакувати його в локальну теку\n\n### Опис {#synopsis}\n\nОтримати пакет із репозиторію пакетів та завантажити його локально.\n\nЦе корисно для отримання пакетів для інспекції, модифікації або перепакування. Також це можна використовувати для криптографічної перевірки чарту без його встановлення.\n\nІснують параметри для розпакування чарту після завантаження. Це створить теку для чарту та розпакує в неї файли.\n\nЯкщо вказано прапорець `--verify`, запитуваний чарт ПОВИНЕН мати файл підтвердження автентичності та ПОВИНЕН пройти процес перевірки. Будь-яка помилка призведе до помилки, і чарт не буде збережено локально.\n\n```shell\nhelm pull [URL чарта | репозиторій/назвачартa] [...] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n  -d, --destination string         місце для збереження чарту. Якщо вказано разом із untardir, то untardir буде додано до нього (стандартно \".\")\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка pull\n      --insecure-skip-tls-verify   пропустити перевірку TLS-сертифікатів для завантаження чарту\n      --key-file string            ідентифікувати HTTPS-клієнта за допомогою цього SSL-ключа\n      --keyring string             місце розташування публічних ключів для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передавати облікові дані всім доменам\n      --password string            пароль для репозиторію чарта, де знаходиться запитуваний чарт\n      --plain-http                 використовувати незахищені HTTP-зʼєднання для завантаження чарта\n      --prov                       завантажити файл підтвердження автентичності, але не виконувати перевірку\n      --repo string                URL репозиторію чарта, де знаходиться запитуваний чарт\n      --untar                      якщо встановлено, чарт буде розпаковано після завантаження\n      --untardir string            якщо вказано untar, цей прапорець вказує назву теки, в яку буде розпаковано чарт (стандартно \".\")\n      --username string            імʼя користувача для репозиторію чарта, де знаходиться запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження на версію чарта для використання. Це обмеження може бути конкретною міткою (наприклад, 1.1.1) або посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо не вказано, використовується остання версія\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\nзавантажити чарт на віддалений сервер\n\n### Опис {#synopsis}\n\nЗавантаження чарту до реєстру.\n\nЯкщо чарт має повʼязаний файл підтвердження автентичності, він також буде завантажений.\n\n```shell\nhelm push [chart] [remote] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n  -h, --help                       довідка push\n      --insecure-skip-tls-verify   пропустити перевірку tls-сертифікатів під час завантаження чарту\n      --key-file string            ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL\n      --plain-http                 використовувати небезпечні HTTP-зʼєднання для завантаження чарту\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\nвхід до або вихід з реєстру\n\n### Опис {#synopsis}\n\nЦя команда містить декілька субкоманд для взаємодії з реєстрами.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка registry\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes.\n* [helm registry login](/helm/helm_registry_login.md) — вхід до реєстру\n* [helm registry logout](/helm/helm_registry_logout.md) — вихід з реєстру\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\nвхід до реєстру\n\n### Опис {#synopsis}\n\nАвтентифікація на віддаленому реєстрі.\n\n```shell\nhelm registry login [host] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string     перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string   ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n  -h, --help               довідка login\n      --insecure           дозволити зʼєднання з TLS-реєстром без сертифікатів\n      --key-file string    ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL\n  -p, --password string    пароль для реєстру або токен ідентифікації\n      --password-stdin     зчитати пароль або токен ідентифікації з stdin\n  -u, --username string    імʼя користувача реєстру\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\nвихід з реєстру\n\n### Опис {#synopsis}\n\nВидалення збережених облікових даних для віддаленого реєстру.\n\n```shell\nhelm registry logout [host] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка logout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\nдодати, вивести перелік, видалити, оновити та індексувати репозиторії чартів\n\n### Опис {#synopsis}\n\nЦя команда містить кілька субкоманд для взаємодії з репозиторіями чартів.\n\nВона може використовуватися для додавання, видалення, виводу переліку та індексування репозиторіїв чартів.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка repo\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n* [helm repo add](/helm/helm_repo_add.md) — додати репозиторій чартів\n* [helm repo index](/helm/helm_repo_index.md) — згенерувати файл індексу для теки, що містить упаковані чарти\n* [helm repo list](/helm/helm_repo_list.md) — вивести перелік репозиторіїв чартів\n* [helm repo remove](/helm/helm_repo_remove.md) — видалити один або кілька репозиторіїв чартів\n* [helm repo update](/helm/helm_repo_update.md) — оновити інформацію про доступні чарти локально з репозиторіїв чартів\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\nдодати репозиторій чартів\n\n```shell\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --allow-deprecated-repos     стандартно ця команда не дозволяє додавати офіційні репозиторії, які були назавжди видалені. Ця опція вимикає таку поведінку\n      --ca-file string             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n      --force-update               замінити (перезаписати) репозиторій, якщо він уже існує\n  -h, --help                       довідка add\n      --insecure-skip-tls-verify   пропустити перевірку tls-сертифікатів для репозиторію\n      --key-file string            ідентифікувати HTTPS-клієнта за допомогою цього файлу ключа SSL\n      --no-update                  Ігнорується. Раніше ця опція відключала примусові оновлення. Застаріла через force-update.\n      --pass-credentials           передавати облікові дані всім доменам\n      --password string            пароль до репозиторію чартів\n      --password-stdin             зчитати пароль до репозиторію чартів з stdin\n      --username string            імʼя користувача репозиторію чартів\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\nзгенерувати файл індексу для теки, що містить упаковані чарти\n\n### Опис {#synopsis}\n\nПрочитати поточну теку і згенерувати файл індексу на основі знайдених чартів.\n\nЦей інструмент використовується для створення файлу 'index.yaml' для репозиторію чартів. Щоб встановити абсолютну URL-адресу для чартів, використовуйте прапорець '--url'.\n\nЩоб обʼєднати згенерований індекс із наявним файлом індексу, використовуйте прапорець '--merge'. У цьому випадку чарти, знайдені в поточній теці, будуть обʼєднані з наявним індексом, причому локальні чарти матимуть пріоритет над теперішніми.\n\n```shell\nhelm repo index [DIR] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help           довідка index\n      --json           вивід у форматі JSON\n      --merge string   обʼєднати згенерований індекс із вказаним індексом\n      --url string     URL репозиторію чартів\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\nвивести перелік репозиторії чартів\n\n```shell\nhelm repo list [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help            довідка list\n  -o, --output format   вивести результат у вказаному форматі. Доступні значення: table, json, yaml (стандартно table)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\nвидалити один або кілька репозиторіїв чартів\n\n```shell\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка remove\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\nоновити інформацію про доступні чарти локально з репозиторіїв чартів\n\n### Опис {#synopsis}\n\nКоманда update отримує останню інформацію про чарти з відповідних репозиторіїв чартів. Інформація кешується локально, де її використовують такі команди, як 'helm search'.\n\nВи можете опційно вказати список репозиторіїв, які ви хочете оновити.\n\n```shell\nhelm repo update <repo_name> ...\n```\n\nЩоб оновити всі репозиторії, використовуйте 'helm repo update'.\n\n```shell\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --fail-on-repo-update-fail   оновлення не буде завершене, якщо будь-яке з оновлень репозиторіїв зазнає невдачі\n  -h, --help                       довідка update\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\nвідкотити реліз до попередньої версії\n\n### Опис {#synopsis}\n\nЦя команда відкотить реліз до попередньої версії.\n\nПерший аргумент команди rollback — це імʼя релізу, а другий — номер версії (revision). Якщо цей аргумент пропущений або встановлений на 0, реліз буде повернено до попередньої версії.\n\nЩоб побачити номери версій, виконайте команду 'helm history RELEASE'.\n\n```shell\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --cleanup-on-fail    дозволити видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдається\n      --dry-run            імітувати відкат\n      --force              примусово оновити ресурси через видалення/пересворення, якщо потрібно\n  -h, --help               довдідка rollback\n      --history-max int    обмежити максимальну кількість збережених версій для кожного релізу. Використовуйте 0 для безмежної кількості (стандартно 10)\n      --no-hooks           запобігти виконанню хуків під час відкату\n      --recreate-pods      перезапускати podʼи для ресурсу, якщо це застосовується\n      --timeout duration   час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s)\n      --wait               якщо встановлено, буде чекати, поки всі Pods, PVCs, Services і мінімальна кількість Pods у Deployment, StatefulSet або ReplicaSet не перейдуть у стан готовності, перш ніж позначити реліз як успішний. Чекатиме стільки, скільки вказано у --timeout\n      --wait-for-jobs      якщо встановлено і --wait увімкнено, буде чекати, поки всі Jobs не будуть завершені, перш ніж позначити реліз як успішний. Чекатиме стільки, скільки вказано у --timeout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\nшукати ключове слово у чартах\n\n### Опис {#synopsis}\n\nКоманда search надає можливість шукати Helm чарти в різних місцях,\nде вони можуть зберігатися, включаючи Artifact Hub і репозиторії, які ви додали. Використовуйте субкоманди search для пошуку в різних місцях для чартів.\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка search\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n* [helm search hub](/helm/helm_search_hub.md) — шукати чарти в Artifact Hub або у власному екземплярі хабу\n* [helm search repo](/helm/helm_search_repo.md) — шукати репозиторії за ключовим словом у чартах\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\nшукати чарти в Artifact Hub або у власному екземплярі хабу\n\n### Опис {#synopsis}\n\nШукайте Helm чарти в Artifact Hub або у власному екземплярі хабу.\n\nArtifact Hub — це вебзастосунок, що дозволяє знаходити, встановлювати та публікувати пакети та конфігурації для проєктів CNCF, включаючи публічно доступні розподілені Helm чарти. Це проєкт Sandbox Cloud Native Computing Foundation. Ви можете переглянути хаб за адресою https://artifacthub.io/\n\nАргумент [KEYWORD] приймає як ключове слово, так і рядок з параметрами розширеного запиту. Документацію з параметрів розширеного запиту дивіться на https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n\nПопередні версії Helm використовували екземпляр Monocular як стандартне значення для 'endpoint', тому для зворотної сумісності Artifact Hub сумісний з API пошуку Monocular. Аналогічно, при встановленні прапорця 'endpoint' зазначена точка доступу також має реалізовувати API пошуку, сумісний з Monocular. Зверніть увагу, що при вказівці екземпляра Monocular як 'endpoint', розширені запити не підтримуються. Для деталей API дивіться https://github.com/helm/monocular\n\n```shell\nhelm search hub [KEYWORD] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --endpoint string      Екземпляр хаба для запитів чартів (стандартно \"https://hub.helm.sh\")\n      --fail-on-no-result    пошук не вдається, якщо результати не знайдені\n  -h, --help                 довідка hub\n      --list-repo-url        вивести URL репозиторію чартів\n      --max-col-width uint   максимальна ширина стовпця для таблиці виводу (стандартно 50)\n  -o, --output format        вивести результат у вказаному форматі. Доступні значення: table, json, yaml (стандартно table)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm search](/helm/helm_search.md) — пошук ключового слова в чартах\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\nшукати репозиторії за ключовим словом у чартах\n\n### Опис {#synopsis}\n\nКоманда search проходить через всі репозиторії, налаштовані в системі, і шукає збіги. Пошук цих репозиторіїв використовує метадані, збережені в системі.\n\nВона відобразить останні стабільні версії знайдених чартів. Якщо ви вказуєте прапорець --devel, у виводі будуть включені передрелізні версії. Якщо ви хочете шукати за допомогою обмеження версії, використовуйте --version.\n\nПриклади:\n\n```console\n# Шукати стабільні версії релізів, що відповідають ключовому слову \"nginx\"\n$ helm search repo nginx\n\n# Шукати версії релізів, що відповідають ключовому слову \"nginx\", включаючи версії передрелізні\n$ helm search repo nginx --devel\n\n# Шукати останній стабільний реліз для nginx-ingress з основною версією 1\n$ helm search repo nginx-ingress --version ^1.0.0\n```\n\nРепозиторії управляються командами 'helm repo'.\n\n```shell\nhelm search repo [keyword] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --devel                використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n      --fail-on-no-result    повертає помилку, якщо результати не знайдені\n  -h, --help                 довідка repo\n      --max-col-width uint   максимальна ширина стовпця для таблиці виводу (стандартно 50)\n  -o, --output format        вивести результат у вказаному форматі. Доступні значення: table, json, yaml (стандартно table)\n  -r, --regexp               використовувати регулярні вирази для пошуку в репозиторіях, які ви додали\n      --version string       шукати, використовуючи обмеження семантичного версіонування в репозиторіях, які ви додали\n  -l, --versions             показати довгий список, з кожною версією кожного чарту на окремому рядку, для репозиторіїв, які ви додали\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm search](/helm/helm_search.md) — пошук ключового слова в чартах\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\nпоказати інформацію про чарт\n\n### Опис {#synopsis}\n\nЦя команда складається з кількох підкоманд для відображення інформації про чарт\n\n### Параметри {#options}\n\n```none\n  -h, --help   довідка show\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n* [helm show all](/helm/helm_show_all.md) — показати всю інформацію про чарт\n* [helm show chart](/helm/helm_show_chart.md) — показати визначення чарту\n* [helm show crds](/helm/helm_show_crds.md) — показати CRD чарту\n* [helm show readme](/helm/helm_show_readme.md) — показати README чарту\n* [helm show values](/helm/helm_show_values.md) — показати значення чарту\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\nпоказати всю інформацію про чарт\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) та показує весь його вміст (values.yaml, Chart.yaml, README).\n\n```shell\nhelm show all [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n      --devel                      використовувати версії в розробці також. Еквівалентно версії '>0.0.0-0'. Якщо вказано --version, це ігнорується\n  -h, --help                       довідка all\n      --insecure-skip-tls-verify   пропустити перевірку сертифікатів TLS для завантаження чарту\n      --key-file string            ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу\n      --keyring string             розташування публічних ключів, які використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль репозиторію чартів, де розташований запитуваний чарт\n      --plain-http                 використовувати небезпечні HTTP зʼєднання для завантаження чарту\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача репозиторію чартів, де розташований запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\nпоказати визначення чарту\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) і показує вміст файлу Chart.yaml.\n\n```shell\nhelm show chart [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка chart\n      --insecure-skip-tls-verify   пропустити перевірку сертифікатів TLS для завантаження чарту\n      --key-file string            ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу\n      --keyring string             розташування публічних ключів, які використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль репозиторію чартів, де розташований запитуваний чарт\n      --plain-http                 використовувати небезпечні HTTP з'єднання для завантаження чарту\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача репозиторію чартів, де розташований запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\nпоказати CRD чарту\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) та показує вміст\nфайлів CustomResourceDefinition (CRD).\n\n```shell\nhelm show crds [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка crds\n      --insecure-skip-tls-verify   пропустити перевірку сертифікатів TLS для завантаження чарту\n      --key-file string            ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу\n      --keyring string             розташування публічних ключів, які використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль репозиторію чартів, де розташований запитуваний чарт\n      --plain-http                 використовувати небезпечні HTTP зʼєднання для завантаження чарту\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача репозиторію чартів, де розташований запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\nпоказати README файл чарту\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) та показує вміст файлу README\n\n```shell\nhelm show readme [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка readme\n      --insecure-skip-tls-verify   пропустити перевірку сертифікатів TLS для завантаження чарту\n      --key-file string            ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу\n      --keyring string             розташування публічних ключів, які використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль репозиторію чартів, де розташований запитуваний чарт\n      --plain-http                 використовувати небезпечні HTTP зʼєднання для завантаження чарту\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача репозиторію чартів, де розташований запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\nпоказати значення чарту\n\n### Опис {#synopsis}\n\nЦя команда перевіряє чарт (теку, файл або URL) та показує вміст файлу values.yaml\n\n```shell\nhelm show values [CHART] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --ca-file string             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n      --devel                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n  -h, --help                       довідка values\n      --insecure-skip-tls-verify   пропустити перевірку сертифікатів TLS для завантаження чарту\n      --key-file string            ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу\n      --keyring string             розташування публічних ключів, які використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           передати облікові дані всім доменам\n      --password string            пароль репозиторію чартів, де розташований запитуваний чарт\n      --plain-http                 використовувати небезпечні HTTP зʼєднання для завантаження чарту\n      --repo string                URL репозиторію чартів, де розташований запитуваний чарт\n      --username string            імʼя користувача репозиторію чартів, де розташований запитуваний чарт\n      --verify                     перевірити пакет перед використанням\n      --version string             вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n* [helm show](/helm/helm_show.md) — показати інформацію про чарт\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\nпоказати статус вказаного релізу\n\n### Опис {#synopsis}\n\nЦя команда показує статус вказаного релізу. Статус складається з:\n\n- часу останнього розгортання\n- простору імен k8s, в якому знаходиться реліз\n- стану релізу (може бути: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade або pending-rollback)\n- ревізії релізу\n- опису релізу (може бути повідомленням про завершення або помилкою, потрібно увімкнути --show-desc)\n- списку ресурсів, які входять до складу цього релізу (потрібно увімкнути --show-resources)\n- деталей останнього запуску тестового набору, якщо застосовується\n- додаткових приміток, наданих чартом\n\n```shell\nhelm status RELEASE_NAME [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help             довідка status\n  -o, --output format    виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --revision int     якщо вказано, показати статус вказаного релізу з ревізією\n      --show-desc        якщо вказано, показати описове повідомлення вказаного релізу\n      --show-resources   якщо вказано, показати ресурси вказаного релізу\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n- [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\nлокальний рендеринг шаблонів\n\n### Опис {#synopsis}\n\nРендерить шаблони чарту локально та показує результат.\n\nБудь-які значення, які зазвичай шукалися або отримувалися в кластері, будуть імітуватися локально. Крім того, жодна з перевірок валідності чарту на сервері (наприклад, перевірка підтримки API) не проводиться.\n\n```shell\nhelm template [NAME] [CHART] [flags]\n```\n\n### Параметри\n\n```none\n  -a, --api-versions strings                       версії API Kubernetes, які використовуються для Capabilities.APIVersions\n      --atomic                                     якщо вказано, процес встановлення видалить інсталяцію у разі невдачі. Прапорець --wait буде встановлено автоматично, якщо використовується --atomic\n      --ca-file string                             перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету\n      --cert-file string                           ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату\n      --create-namespace                           створити простір імен релізу, якщо його не існує\n      --dependency-update                          оновити залежності, якщо вони відсутні перед установкою чарту\n      --description string                         додати власний опис\n      --devel                                      використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується.\n      --disable-openapi-validation                 якщо вказано, процес встановлення не буде перевіряти шаблони за схемою OpenAPI Kubernetes\n      --dry-run string[=\"client\"]                  імітувати встановлення. Якщо --dry-run вказано без жодної опції або як '--dry-run=client', він не буде намагатися підключитися до кластера. Встановлення '--dry-run=server' дозволяє намагатися підключитися до кластера.\n      --enable-dns                                 увімкнути DNS запити при рендерингу шаблонів\n      --force                                      примусово оновлювати ресурси через стратегію заміни\n  -g, --generate-name                              згенерувати імʼя (та опустити параметр NAME)\n  -h, --help                                       довідка по template\n      --hide-notes                                 якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту\n      --include-crds                               включити CRD у вивід шаблонів\n      --insecure-skip-tls-verify                   пропустити перевірки TLS сертифікатів для завантаження чарту\n      --is-upgrade                                 встановити .Release.IsUpgrade замість .Release.IsInstall\n      --key-file string                            ідентифікувати клієнта HTTPS, використовуючи цей файл SSL ключа\n      --keyring string                             розташування публічних ключів, використовуваних для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        версія Kubernetes, яка використовується для Capabilities.KubeVersion\n  -l, --labels stringToString                      Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно [])\n      --name-template string                       вказати шаблон, використаний для іменування релізу\n      --no-hooks                                   запобігти виконанню хуків у процесі установки\n      --output-dir string                          записувати виконані шаблони у файли в output-dir замість stdout\n      --pass-credentials                           передати облікові дані всім доменам\n      --password string                            пароль до репозиторію чартів, де знайти запитуваний чарт\n      --plain-http                                 використовувати небезпечні HTTP зʼєднання для завантаження чарту\n      --post-renderer postRendererString           шлях до виконуваного файлу, який буде використаний для пост-рендерингу. Якщо він існує в $PATH, буде використано цей бінарний файл, інакше спробує знайти виконуваний файл за вказаним шляхом\n      --post-renderer-args postRendererArgsSlice   аргумент для пост-рендерера (можна вказати кілька) (стандартно [])\n      --release-name                               використовувати імʼя релізу в шляху output-dir\n      --render-subchart-notes                      якщо вказано, рендерити нотатки субчарту разом з батьківським\n      --replace                                    повторно використовувати дане імʼя, тільки якщо це імʼя є видаленим релізом, який залишається в історії. Це небезпечно в операційному середовищі\n      --repo string                                URL репозиторію чартів, де знайти запитуваний чарт\n      --set stringArray                            встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --set-file stringArray                       встановити значення з відповідних файлів, зазначених через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2)\n      --set-json stringArray                       встановити JSON значення в командному рядку (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    встановити літеральне STRING значення на командному рядку\n      --set-string stringArray                     встановити STRING значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n  -s, --show-only stringArray                      показати тільки маніфести, відрендерені з вказаних шаблонів\n      --skip-crds                                  якщо вказано, CRD не будуть встановлені. Ствндартно CRD встановлюються, якщо ще не присутні\n      --skip-schema-validation                     якщо встановлено, вимикає перевірку схеми JSON\n      --skip-tests                                 пропустити тести з виводу шаблонів\n      --timeout duration                           час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хук) (стандартно 5м0с)\n      --username string                            імʼя користувача репозиторію чартів, де знайти запитуваний чарт\n      --validate                                   перевірити ваші маніфести на відповідність кластеру Kubernetes, до якого ви в даний час звертаєтеся. Це така ж перевірка, яка виконується при установці\n  -f, --values strings                             вказати значення в YAML файлі або URL (можна вказати кілька)\n      --verify                                     перевірити пакет перед його використанням\n      --version string                             вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія\n      --wait                                       якщо вказано, буде чекати, поки всі Pods, PVCs, Services та мінімальна кількість Pods Deployment, StatefulSet або ReplicaSet не будуть у стані готовності, перш ніж позначити реліз як успішний. Це буде чекати стільки, скільки вказано у --timeout\n      --wait-for-jobs                              якщо вказано і --wait увімкнено, буде чекати, поки всі Jobs не будуть завершені перед тим, як позначити реліз як успішний. Це буде чекати стільки, скільки вказано у --timeout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n- [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\nзапустити тести для релізу\n\n### Опис {#synopsis}\n\nКоманда test запускає тести для релізу.\n\nАргументом цієї команди є імʼя розгорнутого релізу. Тести, що будуть виконані, визначені у чарті, який був встановлений.\n\n```shell\nhelm test [RELEASE] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --filter strings     вказати тести за атрибутом (в даний час \"name\") використовуючи синтаксис attribute=value або '!attribute=value', щоб виключити тест (можна вказати кілька або розділити значення комами: name=test1,name=test2)\n  -h, --help               довідка test\n      --hide-notes         якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту\n      --logs               отримати логи з тестових podʼів (це виконується після завершення всіх тестів, але перед будь-яким очищенням)\n      --timeout duration   час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с)\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n- [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\nвидалити реліз\n\n### Опис {#synopsis}\n\nЦя команда приймає імʼя релізу і видаляє його.\n\nВона видаляє всі ресурси, асоційовані з останнім релізом чарту, а також історію релізу, звільняючи його для подальшого використання.\n\nВикористовуйте прапор '--dry-run', щоб побачити, які релізи будуть видалені без фактичного видалення.\n\n```shell\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Параметри {#options}\n\n```none\n      --cascade string       Має бути \"background\", \"orphan\" або \"foreground\". Вибирає стратегію каскадного видалення для залежних ресурсів. Стандартно background. (стандартно \"background\")\n      --description string   додати власний опис\n      --dry-run              симулювати видалення\n  -h, --help                 довідка uninstall\n      --ignore-not-found     Вважати \"release not found\" як успішне видалення\n      --keep-history         видалити всі асоційовані ресурси і помітити реліз як видалений, але зберегти історію релізу\n      --no-hooks             запобігти виконанню хуків під час видалення\n      --timeout duration     час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с)\n      --wait                 якщо вказано, буде чекати, поки всі ресурси не будуть видалені перед поверненням. Буде чекати стільки, скільки вказано у --timeout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n- [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\nоновити реліз\n\n### Опис {#synopsis}\n\nЦя команда оновлює реліз до нової версії чарту.\n\nАргументи для оновлення повинні містити реліз і чарт. Аргумент чарту може бути або: посилання на чарт ('example/mariadb'), шлях до теки з чартом, упакований чарт або повністю кваліфікований URL. Для посилань на чарт буде вказана остання версія, якщо не встановлено прапорець '--version'.\n\nЩоб перевизначити значення в чарті, використовуйте або прапорець '--values' та передайте файл, або прапорець '--set' і передайте конфігурацію з командного рядка. Для примусового використання рядкових значень використовуйте '--set-string'. Можна також використовувати '--set-file', щоб задати окремі значення з файлу, коли значення занадто довге для командного рядка або генерується динамічно. Ви також можете використовувати '--set-json', щоб задати json-значення (скаляри/обʼєкти/масиви) з командного рядка.\n\nВи можете вказати прапорець '--values'/'-f' кілька разів. Пріоритет буде надано останньому (правому) файлу. Наприклад, якщо і myvalues.yaml, і override.yaml містять ключ 'Test', значення, задане в override.yaml, матиме пріоритет:\n\n```shell\n$ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n```\n\nВи можете вказати прапорець '--set' кілька разів. Пріоритет буде надано останньому (правому) заданому значенню. Наприклад, якщо значення 'bar' і 'newbar' встановлені для ключа 'foo', значення 'newbar' матиме пріоритет:\n\n```shell\n$ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n```\n\nВи також можете оновити значення для поточного релізу за допомогою цієї команди з прапорцем '--reuse-values'. Аргументи 'RELEASE' і 'CHART' повинні бути встановлені на оригінальні параметри, поточні значення будуть обʼєднані з будь-якими значеннями, заданими через прапорці '--values'/'-f' або '--set'. Пріоритет надається новим значенням.\n\n```shell\n$ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n```\n\nПрапорець `--dry-run` виведе усі згенеровані маніфести чартів, включно з секретами, які можуть містити конфіденційні значення. Для приховування секретів Kubernetes використовуйте прапорець `--hide-secret`. Будь ласка, уважно вивчіть, як і коли використовувати ці прапорці.\n\n```shell\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Параметри\n\n```none\n      --atomic                                     якщо встановлено, процес оновлення скасовує зміни у разі невдалого оновлення. Прапорець --wait буде автоматично встановлено, якщо використовується --atomic\n      --ca-file string                             перевіряти сертифікати HTTPS-серверів, використовуючи цей CA пакет\n      --cert-file string                           ідентифікувати HTTPS-клієнта, використовуючи цей SSL сертифікат\n      --cleanup-on-fail                            дозволити видалення нових ресурсів, створених в цьому оновленні, коли оновлення не вдалося\n      --create-namespace                           якщо встановлено --install, створити простір імен релізу, якщо він не присутній\n      --dependency-update                          оновити залежності, якщо вони відсутні, перед встановленням чарту\n      --description string                         додати власний опис\n      --devel                                      використовувати також версії в розробці. Еквівалентно версії '>0.0.0-0'. Якщо вказано --version, це буде проігноровано\n      --disable-openapi-validation                 якщо встановлено, процес оновлення не буде перевіряти відрендерені шаблони на відповідність Kubernetes OpenAPI Schema\n      --dry-run string[=\"client\"]                  симулювати установку. Якщо --dry-run встановлено без вказання опції або як '--dry-run=client', не буде спроб зʼєднання з кластером. Встановлення '--dry-run=server' дозволяє спробувати зʼєднання з кластером.\n      --enable-dns                                 увімкнути DNS запити під час рендерингу шаблонів\n      --force                                      примусове оновлення ресурсів через стратегію заміни\n  -h, --help                                       довідка upgrade\n      --hide-notes                                 якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту\n      --hide-secret                                приховати Kubernetes Secrets, якщо також використовується прапорець --dry-run\n      --history-max int                            обмежити максимальну кількість ревізій, збережених для релізу. Використовуйте 0 для відсутності обмежень (стандартно 10)\n      --insecure-skip-tls-verify                   пропустити перевірки сертифікатів TLS для завантаження чарту\n  -i, --install                                    якщо реліз з цим імʼям ще не існує, виконується установка\n      --key-file string                            ідентифікувати HTTPS-клієнта, використовуючи цей файл SSL ключа\n      --keyring string                             розташування публічних ключів, що використовуються для перевірки (стандартно \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Мітки, які будуть додані до метаданих релізу. Мають бути розділені комою. Оригінальні мітки релізу будуть обʼєднані з мітками оновлення. Ви можете скинути мітку, використовуючи null. (стандартно [])\n      --no-hooks                                   вимкнути хуки перед/після оновлення\n  -o, --output format                              друкує вивід у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table)\n      --pass-credentials                           передати облікові дані всім доменам\n      --password string                            пароль репозиторію чарту для розташування запитуваного чарту\n      --plain-http                                 використовувати небезпечні HTTP зʼєднання для завантаження чарту\n      --post-renderer postRendererString           шлях до виконуваного файлу, що буде використано для пост-рендерингу. Якщо він існує в $PATH, буде використано двійковий файл, інакше буде спробовано знайти виконуваний файл за вказаним шляхом\n      --post-renderer-args postRendererArgsSlice   аргумент для пост-рендерера (можна вказати кілька) (стандартно [])\n      --render-subchart-notes                      якщо встановлено, рендерити нотатки субчарту разом з батьківським чартом\n      --repo string                                URL репозиторію чарту для розташування запитуваного чарту\n      --reset-then-reuse-values                    при оновленні, скинути значення до вбудованих у чарт значень, застосувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values' або '--reuse-values', це буде проігноровано\n      --reset-values                               при оновленні, скинути значення до вбудованих у чарт значень\n      --reuse-values                               при оновленні, повторно використовувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values', це буде проігноровано\n      --set stringArray                            встановити значення з командного рядка (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --set-file stringArray                       встановити значення з відповідних файлів, зазначених через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2)\n      --set-json stringArray                       встановити JSON значення з командного рядка (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    встановити літеральне STRING значення з командного рядка\n      --set-string stringArray                     встановити STRING значення з командного рядка (можна вказати кілька або розділити значення комами: key1=val1,key2=val2)\n      --skip-crds                                  якщо встановлено, CRD не будуть встановлені під час виконання оновлення з увімкненим прапорцем install. Стандартно, CRD встановлюються, якщо ще не присутні, під час виконання оновлення з увімкненим прапорцем install\n      --skip-schema-validation                     якщо встановлено, вимикає перевірку схеми JSON\n      --timeout duration                           час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с)\n      --username string                            імʼя користувача репозиторію чарту для розташування запитуваного чарту\n  -f, --values strings                             вказати значення у YAML файлі або URL (можна вказати кілька)\n      --verify                                     перевірити пакет перед використанням\n      --version string                             вказати обмеження версії для версії чарту, яку слід використовувати. Це обмеження може бути конкретною міткою (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо не вказано, буде використана остання версія\n      --wait                                       якщо встановлено, чекатиме, поки всі Pods, PVC, Services і мінімальна кількість Pods Deployment, StatefulSet або ReplicaSet не перебуватимуть у стані готовності перед поміткою релізу як успішного. Буде чекати стільки, скільки вказано у --timeout\n      --wait-for-jobs                              якщо встановлено і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед поміткою релізу як успішного. Це буде чекати стільки, скільки вказано у --timeout\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n- [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\nперевірити, що чарт за вказаним шляхом підписаний і є дійсним\n\n### Опис {#synopsis}\n\nПеревірте, чи має вказаний чарт дійсний файл автентичності.\n\nФайли автентичності забезпечують криптографічну перевірку того, що чарт не був зміненим і був упакований надійним постачальником.\n\nЦю команду можна використовувати для перевірки локального чарту. Декілька інших команд надають прапорці '--verify', які виконують ту ж саму валідацію. Щоб згенерувати підписаний пакет, використовуйте команду 'helm package --sign'.\n\n```shell\nhelm verify PATH [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help             довідка verify\n      --keyring string   вєящка ключів, що містить публічні ключі (стандартно \"~/.gnupg/pubring.gpg\")\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n- [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\nдрукує інформацію про версію клієнта\n\n### Опис {#synopsis}\n\nПоказує версію для Helm.\n\nКоманда надрукує представлення версії Helm. Вивід виглядатиме приблизно так:\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version — семантична версія релізу.\n- GitCommit — SHA коміту, з якого була збудована ця версія.\n- GitTreeState — \"clean\", якщо при створенні цього бінарного файлу не було локальних змін у коді, і \"dirty\", якщо бінарний файл був збудований з локально зміненого коду.\n- GoVersion — версія Go, яка була використана для компіляції Helm.\n\nПри використанні прапорця --template доступні такі властивості для використання в шаблоні:\n\n- .Version містить семантичну версію Helm\n- .GitCommit — git коміт\n- .GitTreeState — стан git дерева, коли був збудований Helm\n- .GoVersion містить версію Go, з якою був зібраний Helm\n\nНаприклад, --template='Version: {{.Version}}' надрукує 'Version: v3.2.1'.\n\n```shell\nhelm version [flags]\n```\n\n### Параметри {#options}\n\n```none\n  -h, --help              довідка version\n      --short             надрукувати номер версії\n      --template string   шаблон для формату рядка версії\n```\n\n### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands}\n\n```none\n      --burst-limit int                 стандартні обмеження на стороні клієнта (стандартно 100)\n      --debug                           увімкнути розширений вивід\n      --kube-apiserver string           адреса та порт сервера API Kubernetes\n      --kube-as-group stringArray       група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп.\n      --kube-as-user string             імʼя користувача для імперсонації під час операції\n      --kube-ca-file string             файл центру сертифікаці СА для підключення до сервера API Kubernetes\n      --kube-context string             імʼя контексту kubeconfig для використання\n      --kube-insecure-skip-tls-verify   якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними\n      --kube-tls-server-name string     імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера\n      --kube-token string               токен на предʼявника, який використовується для автентифікації\n      --kubeconfig string               шлях до файлу kubeconfig\n  -n, --namespace string                простір імен для цього запиту\n      --qps float32                     кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески\n      --registry-config string          шлях до файлу конфігурації реєстру (стандартно \"~/.config/helm/registry/config.json\")\n      --repository-cache string         шлях до теки, що містить кешовані індекси репозиторіїв (стандартно \"~/.cache/helm/repository\")\n      --repository-config string        шлях до файлу, що містить імена та URL репозиторіїв (стандартно \"~/.config/helm/repositories.yaml\")\n```\n\n### ДИВІТЬСЯ ТАКОЖ {#see-also}\n\n- [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes.\n\n###### Автоматично згенеровано spf13/cobra 11 вересня 2024\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/helm/index.mdx",
    "content": "---\ntitle: Команди Helm\ndescription: Документація для повного списку команд CLI для Helm.\nsidebar_position: 6\nid: helm-category\n---\n\n# Команди Helm {#helm-commands}\n\nТут ви знайдете список команд CLI для Helm з інформацією щодо їх використання.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action для автоматизації випуску чартів на GitHub Pages\ndescription: Описує, як використовувати Chart Releaser Action для автоматизації випуску чартів через GitHub Pages.\nsidebar_position: 3\n---\n\nЦей посібник описує, як використовувати [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).\n\n## Зміни в репозиторії {#repository-changes}\n\nСтворіть Git-репозиторій у вашій організації на GitHub. Ви можете назвати репозиторій `helm-charts`, хоча також прийнятні інші назви. Джерела всіх чартів можуть бути розміщені на гілці `main`. Чарти повинні бути розміщені в теці `/charts` на верхньому рівні дерева тек.\n\nТакож має бути інша гілка з назвою `gh-pages`, щоб публікувати чарти. Зміни в цій гілці будуть автоматично створюватися за допомогою Chart Releaser Action, описаного тут. Крім створення гілку `gh-pages` ви можете додати файл `README.md` до неї, який буде видимим користувачам, що відвідують сторінку.\n\nВи можете додати інструкції в `README.md` щодо встановлення чартів, як показано нижче (замініть `<alias>`, `<orgname>`, і `<chart-name>`):\n\n```md\n## Використання\n\nЩоб використовувати чарти, необхідно встановити [Helm](https://helm.sh/uk).\nБудь ласка, ознайомтеся з [документацією Helm](https://helm.sh/uk/docs), щоб розпочати.\n\nЯк тільки Helm буде налаштовано правильно, додайте репозиторій наступним чином:\n\n    helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nЯкщо ви вже додавали цей репозиторій раніше, виконайте команду `helm repo update`,\nщоб отримати останні версії пакетів. Потім ви можете виконати `helm search repo <alias>`, щоб побачити чарти.\n\nЩоб встановити чарт `<chart-name>`:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nЩоб видалити чарт:\n\n    helm uninstall my-<chart-name>\n```\n\nЧарти будуть опубліковані на вебсайті з URL-адресою типу:\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions Workflow {#github-actions-workflow}\n\nСтворіть файл GitHub Actions workflow в гілці `main` за адресою `.github/workflows/release.yml`:\n\n```yaml\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nНаведена конфігурація використовує [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action), щоб перетворити ваш GitHub проєкт на самостійний репозиторій чартів Helm. Вона виконує це під час кожної операції push в гілку `main` шляхом перевірки кожного чарту у вашому проєкті, і коли знаходить нову версію чарту, створює відповідний реліз GitHub, додає артефакти Helm чарту до релізу і створює або оновлює файл `index.yaml` з метаданими про ці релізи, який потім хоститься на GitHub Pages.\n\nВерсія Chart Releaser Action, використана в наведеному прикладі, — `v1.6.0`. Ви можете змінити її на [останню доступну версію](https://github.com/helm/chart-releaser-action/releases).\n\nПримітка: Chart Releaser Action майже завжди використовується в парі з [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) та [Kind Action](https://github.com/marketplace/actions/kind-cluster).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: Синхронізація вашого репозиторію чартів\ndescription: Описує, як синхронізувати ваші локальні та віддалені репозиторії чартів.\nsidebar_position: 2\n---\n\n*Примітка: Цей приклад для хмарного сховища Google (GCS), яке обслуговує репозиторій чартів.*\n\n## Попередні умови {#prerequisites}\n\n* Встановіть інструмент [gsutil](https://cloud.google.com/storage/docs/gsutil). *Ми значною мірою покладаємося на функціональність gsutil rsync.*\n* Переконайтеся, що у вас є доступ до бінарного файлу Helm.\n* *Необовʼязково: Ми рекомендуємо встановити [версіювання обʼєктів](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) у вашому сховищі GCS, на випадок, якщо ви випадково щось видалите.*\n\n## Налаштування теки локального репозиторію чартів {#set-up-a-local-chart-repository-directory}\n\nСтворіть локальну теку, як ми це робили в [керівництві з репозиторію чартів](/topics/chart_repository.md), і помістіть ваші упаковані чарти в цю теку.\n\nНаприклад:\n\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Генерація оновленого файлу index.yaml {#generate-an-updated-index.yaml}\n\nВикористовуйте Helm для генерації оновленого файлу index.yaml, передавши шлях до теки та URL-адресу віддаленого репозиторію команді `helm repo index`, як показано нижче:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\n\nЦе згенерує оновлений файл index.yaml і помістить його в теку `fantastic-charts/`.\n\n## Синхронізація ваших локальних та віддалених репозиторіїв чартів {#sync-your-local-and-remote-chart-repositories}\n\nЗавантажте вміст теки у ваше сховище GCS, запустивши `scripts/sync-repo.sh` та передавши назву локальної теки та назву сховища GCS.\n\nНаприклад:\n\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n\n## Оновлення вашого репозиторію чартів {#updating-your-chart-repository}\n\nВи захочете зберегти локальну копію вмісту вашого репозиторію чартів або використати `gsutil rsync` для копіювання вмісту вашого віддаленого репозиторію чартів до локальної теки.\n\nНаприклад:\n\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # прапорець -n виконує пробний запуск\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # виконує дії копіювання\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nКорисні посилання:\n\n* Документація щодо [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [Керівництво репозиторію чартів](/topics/chart_repository.md)\n* Документація щодо [версіювання обʼєктів та керування паралельністю](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) у хмарному сховищі Google\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Поради та підказки для розробки чартів\ndescription: >-\n  Містить деякі поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової\n  якості.\nsidebar_position: 1\n---\n\nЦей посібник містить поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової якості.\n\n## Знайомство з функціями шаблону {#know-your-template-functions}\n\nHelm використовує [шаблони Go](https://godoc.org/text/template) для шаблонування ваших ресурсних файлів. Хоча Go поставляється з кількома вбудованими функціями, ми додали багато інших.\n\nПо-перше, ми додали всі функції з [бібліотеки Sprig](https://masterminds.github.io/sprig/), за винятком `env` і `expandenv`, з міркувань безпеки.\n\nМи також додали дві спеціальні функції шаблонів: `include` і `required`. Функція `include` дозволяє додавати інший шаблон і передавати результати іншим функціям шаблонів.\n\nНаприклад, цей фрагмент шаблону включає шаблон з назвою `mytpl`, потім приводить результат у нижньому регістрі та обертає його в подвійні лапки.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nФункція `required` дозволяє оголосити певний запис значення обовʼязковим для рендерингу шаблону. Якщо значення порожнє, рендеринг шаблону завершиться з повідомленням про помилку, наданим користувачем.\n\nНаступний приклад використання функції `required` оголошує запис для `.Values.who` обовʼязковим і виводить повідомлення про помилку, якщо цього запису не вистачає:\n\n```yaml\nvalue: {{ required \"Потрібен дійсний запис .Values.who!\" .Values.who }}\n```\n\n## Використовуйте лапки для рядків, не використовуйте лапки для цілих чисел {#quote-strings-don-t-quote-integers}\n\nКоли ви працюєте з рядковими даними, завжди безпечніше використовувати лапки для рядків, ніж залишати їх без лапок:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nАле при роботі з цілими числами _не беріть значення в лапки._ Це може викликати помилки парсингу всередині Kubernetes.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nЦе зауваження не стосується значень змінних середовища, які повинні бути рядками, навіть якщо вони представляють цілі числа:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Використання функції `include` {#using-the-include-function}\n\nGo надає спосіб включати один шаблон в інший за допомогою вбудованої директиви `template`. Однак вбудована функція не може використовуватися в конвеєрах шаблонів Go.\n\nЩоб включити шаблон і виконати операцію з його результатом, Helm має спеціальну функцію `include`:\n\n```yaml\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nВищезазначене включає шаблон з назвою `toYaml`, передає йому `$value`, а потім передає результат з цього шаблону у функцію `indent`.\n\nОскільки в YAML важливі відступи, це чудовий спосіб включати фрагменти коду, зберігаючи відступи в релевантному контексті.\n\n## Використання функції `required` {#using-the-required-function}\n\nGo надає спосіб налаштувати опції шаблону для керування поведінкою при зверненні до ключа, якого немає в map. Це зазвичай налаштовується за допомогою `template.Options(\"missingkey=option\")`, де `option` може бути `default`, `zero` або `error`. Якщо встановити цю опцію з помилкою, виконання зупиниться з помилкою, але це стосуватиметься кожного відсутнього ключа в map. Можуть бути ситуації, коли розробник чарту захоче застосувати цю поведінку лише для певних значень у файлі `values.yaml`.\n\nФункція `required` дає розробникам можливість оголосити значення обовʼязковим для роботи в шаблоні. Якщо значення відсутнє в `values.yaml`, шаблон повертає повідомлення про помилку, надане розробником.\n\nНаприклад:\n\n```yaml\n{{ required \"Потрібен дійсний foo!\" .Values.foo }}\n```\n\nНаведена вище конструкція використає шаблон, коли `.Values.foo` визначено, але не зможе це зробити та вийде з помилкою, коли `.Values.foo` не визначено.\n\n## Використання функції `tpl` {#using-the-tpl-function}\n\nФункція `tpl` дозволяє розробникам оцінювати рядки як шаблони всередині іншого шаблону. Це корисно для передачі рядка шаблону як значення до чарту або використання зовнішніх конфігураційних файлів. Синтаксис: `{{ tpl TEMPLATE_STRING VALUES }}`.\n\nПриклади:\n\n```yaml\n# значення\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# шаблон\n{{ tpl .Values.template . }}\n\n# результат\nTom\n```\n\nВикористання зовнішнього конфігураційного файлу:\n\n```yaml\n# зовнішній конфігураційний файл conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# значення\nfirstName: Peter\nlastName: Parker\n\n# шаблон\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# результат\nfirstName=Peter\nlastName=Parker\n```\n\n## Створення секретів для отримання образів {#creating-image-pull-secrets}\n\nСекрети для отримання образів по суті є комбінацією _registry_, _username_ та _password_. Вони можуть знадобитися у застосунку, який ви розгортаєте, але для їх створення потрібно кілька разів запустити `base64`. Ми можемо написати допоміжний шаблон, щоб скласти файл конфігурації Docker для використання у вигляді даних для секрету. Ось приклад:\n\nПо-перше, припустимо, що облікові дані визначені у файлі `values.yaml` наступним чином:\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nМи визначаємо наш допоміжний шаблон наступним чином:\n\n```go\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nНарешті, ми використовуємо допоміжний шаблон у більшому шаблоні для створення маніфесту секрету:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Автоматичне викатування розгортань {#automatically-roll-deployments}\n\nЧасто ConfigMaps або Secrets підключаютсья як конфігураційні файли в контейнери або є інші зовнішні зміни залежностей, які вимагають перезапуску podʼів. Залежно від застосунку, перезапуск може знадобитися, якщо вони оновлюються при наступному `helm upgrade`, але якщо самі специфікації deployment не змінюються, застосунок продовжує працювати зі старою конфігурацією, що призводить до неконсистентного deployment.\n\nФункція `sha256sum` може бути використана для забезпечення оновлення секції анотацій розгортання, якщо змінюється інший файл:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nПРИМІТКА: Якщо ви додаєте це до бібліотечного чарту, ви не зможете отримати доступ до вашого файлу в `$.Template.BasePath`. Замість цього можна посилатися на ваше визначення за допомогою `{{ include (\"mylibchart.configmap\") . | sha256sum }}`.\n\nУ випадку, коли ви завжди хочете перезапустити свій deployment, ви можете використати аналогічний крок з анотацією, як вище, замінивши його випадковим рядком, щоб він завжди змінювався і викликав перезапуск deployment:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nКожен виклик функції шаблону генеруватиме унікальний випадковий рядок. Це означає, що якщо необхідно синхронізувати випадкові рядки, що використовуються декількома ресурсами, всі відповідні ресурси повинні бути в одному файлі шаблону.\n\nОбидва ці методи дозволяють вашому deployment використовувати вбудовану логіку стратегії оновлення, щоб уникнути простоїв.\n\nПРИМІТКА: Раніше ми рекомендували використовувати прапорець `--recreate-pods` як інший варіант. Цей прапорець було позначено застарілим у Helm 3 на користь більш декларативного методу, описаного вище.\n\n## Скажіть Helm не видаляти ресурс {#tell-helm-not-to-uninstall-a-resource}\n\nІноді є ресурси, які не слід видаляти під час виконання команди `helm uninstall`. Розробники чартів можуть додати анотацію до ресурсу, щоб запобігти його видаленню.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nАнотація `helm.sh/resource-policy: keep` говорить Helm не видаляти цей ресурс, коли операція Helm (така як `helm uninstall`, `helm upgrade` або `helm rollback`) призвела б до його видалення. _Однак_, цей ресурс стає сиротою. Helm більше не керує ним у будь-який спосіб. Це може призвести до проблем, якщо використовувати `helm install --replace` для релізу, який вже був видалений, але зберіг ресурси.\n\n## Використання \"Partials\" та включень шаблонів {#using-partials-and-template-includes}\n\nІноді ви хочете створити деякі багаторазові частини у вашому чарті, незалежно від того, чи це блоки або часткові шаблони. І часто, чистіше зберігати їх у власних файлах.\n\nУ теці `templates/`, будь-який файл, що починається з підкреслення (`_`), не призначений для виведення файлу маніфесту Kubernetes. Таким чином, за домовленістю, допоміжні шаблони та часткові шаблони розміщуються у файлі `_helpers.tpl`.\n\n## Складні чарти з багатьма залежностями {#complex-charts-with-many-dependencies}\n\nБагато чартів у CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є \"будівельними блоками\" для створення складніших застосунків. Але чарти можуть бути використані для створення екземплярів великомасштабних застосунків. У таких випадках один основний чарт може мати декілька вкладених субчартів, кожен з яких функціонує як частина цілого.\n\nНайкращою практикою для збирання складного застосунку з окремих частин є створення основного чарту, який надає глобальні конфігурації, а потім використання підтеки `charts/` для вбудовування кожного з компонентів.\n\n## YAML — це надмножина JSON {#yaml-is-a-superset-of-json}\n\nЗгідно зі специфікацією YAML, YAML є надмножиною JSON. Це означає, що будь-яка допустима структура JSON має бути дійсною в YAML.\n\nЦе має перевагу: іноді розробникам шаблонів може бути простіше виразити структуру даних з синтаксисом, схожим на JSON, ніж мати справу з чутливістю YAML до пробілів.\n\nЯк правило, шаблони повинні відповідати синтаксису, схожому на YAML, _якщо_ синтаксис JSON суттєво не знижує ризик виникнення проблем з форматуванням.\n\n## Будьте обережні з генерацією випадкових значень {#be-careful-with-generating-random-values}\n\nУ Helm є функції, які дозволяють генерувати випадкові дані, криптографічні ключі тощо. Вони цілком придатні для використання. Але майте на увазі, що під час оновлень шаблони виконуються знову. Коли виконання шаблону генерує дані, що відрізняються від останнього виконання, це викликає оновлення цього ресурсу.\n\n## Встановлення або оновлення релізу однією командою\n\nHelm надає можливість виконати встановлення або оновлення як одну команду. Використовуйте `helm upgrade` з командою `--install`. Це змусить Helm перевірити, чи реліз вже встановлено. Якщо ні, буде виконано встановлення. Якщо так, то наявний реліз буде оновлено.\n\n```console\n$ helm upgrade --install <назва релізу> --values <файл значень> <тека чарту>\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/howto/index.mdx",
    "content": "---\ntitle: Поради\nsidebar_position: 2\n---\n\n---\n\n### Поради {#how-to-guides}\n\nТут ви знайдете короткі відповіді на питання типу «Як я можу….?»\nЦі посібники не охоплюють теми в деталях — ви знайдете такі\nматеріали в [Тематичних посібниках](/topics/index.mdx). Однак ці\nпосібники допоможуть вам швидко виконати поширені завдання.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"Документація\"\ndescription: \"Все, що вам потрібно знати про те, як організована документація.\"\n---\n\n# Ласкаво просимо {#welcome}\n\nЛаскаво просимо до документації [Helm](https://helm.sh/). Helm — це менеджер пакунків для Kubernetes, і ви можете прочитати детальну довідкову інформацію у [звіті CNCF Helm Project Journey](https://www.cncf.io/cncf-helm-project-journey/).\n\n# Як організована документація {#how-the-documentation-is-organized}\n\nHelm має багато документації. Загальний огляд того, як все організовано допоможе вам зрозуміти, де шукати певні речі:\n\n- [Підручники](/chart_template_guide/getting_started.md) проведуть вас через низку кроків для створення вашого першого чарту Helm. Почніть тут, якщо ви новачок у Helm.\n- [Тематичні посібники](/topics/index.mdx) обговорюють ключові теми та концепції на досить високому рівні та надають корисну довідкову інформацію та пояснення.\n- [Настанови для спільноти](/community) обговорюють теми, повʼязані зі спільнотою Helm. Почніть тут, якщо ви хочете дізнатися більше про процес розробки Helm і про те, як ви можете до нього долучитися.\n- [Посібники](/howto/index.mdx) — це рецепти. Вони проведуть вас через кроки, повʼязані з розвʼязанням ключових проблем та варіантів використання. Вони більш докладні, ніж підручників і передбачають певні знання про те, як працює Helm.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: Шпаргалка\ndescription: Шпаргалка Helm\nsidebar_position: 4\n---\n\nПідказка Helm з усіма необхідними командами для керування програмою через Helm.\n\n---\n\n### Основні інтерпретації/контекст {#basic-interpretations-context}\n\n**Chart (Чарт):**\n- Це назва вашого чарту у випадку, якщо його було завантаженла та розпаковано.\n- Це `<repo_name>/<chart_name>`, якщо репозиторій був доданий, але чарт не завантажений.\n- Це URL/Абсолютний шлях до чарту.\n\n**Name (Назва):**\n- Це назва, яку ви хочете надати вашій поточній установці Helm-чарту.\n\n**Release (Реліз):**\n- Це назва, яку ви присвоїли екземпляру установки.\n\n**Revision (Версія):**\n- Це значення з команди Helm history.\n\n**Repo-name (Назва репозиторію):**\n- Назва репозиторію.\n\n**DIR (Тека):**\n- Назва/шлях теки.\n\n---\n\n### Управління чартами {#chart-management}\n\n```bash\nhelm create <name>                      # Створює теку чарту разом з загальними файлами та теками, які використовуються в чарті.\nhelm package <chart-path>               # Упаковує чарт у файл архіву з версією.\nhelm lint <chart>                       # Запускає тести для перевірки чарту та виявлення можливих проблем.\nhelm show all <chart>                   # Переглядає чарт та виводить його вміст.\nhelm show values <chart>                # Показує вміст файлу values.yaml.\nhelm pull <chart>                       # Завантажує/витягує чарт.\nhelm pull <chart> --untar=true          # Якщо встановлено в true, розпаковує чарт після завантаження.\nhelm pull <chart> --verify              # Перевіряє пакет перед використанням.\nhelm pull <chart> --version <number>    # СТандартно використовується остання версія, вкажіть обмеження версії для використання чарту.\nhelm dependency list <chart>            # Відображає список залежностей чарту.\n```\n\n---\n\n### Встановлення та видалення застосунків {#install-and-uninstall-apps}\n\n```bash\nhelm install <name> <chart>                           # Встановлює чарт з зазначеною назвою.\nhelm install <name> <chart> --namespace <namespace>   # Встановлює чарт у певному просторі імен.\nhelm install <name> <chart> --set key1=val1,key2=val2 # Встановлює значення в командному рядку (можна вказати кілька значень, розділених комами).\nhelm install <name> <chart> --values <yaml-file/url>  # Встановлює чарт з вказаними вами значеннями.\nhelm install <name> <chart> --dry-run --debug         # Запускає тестове встановлення для перевірки чарту.\nhelm install <name> <chart> --verify                  # Перевіряє пакет перед використанням.\nhelm install <name> <chart> --dependency-update       # Оновлює залежності, якщо вони відсутні, перед встановленням чарту.\nhelm uninstall <name>                                 # Видаляє реліз.\n```\n\n---\n\n### Оновлення застосунків та відкат {#perform-app-upgrade-and-rollback}\n\n```bash\nhelm upgrade <release> <chart>                            # Оновлює реліз.\nhelm upgrade <release> <chart> --atomic                   # Якщо встановлено, процес оновлення поверне зміни в разі невдалого оновлення.\nhelm upgrade <release> <chart> --dependency-update        # Оновлює залежності, якщо вони відсутні, перед встановленням чарту.\nhelm upgrade <release> <chart> --version <version_number> # Вказує обмеження версії для використання чарту.\nhelm upgrade <release> <chart> --values                   # Вказує значення у YAML файлі або URL (можна вказати кілька).\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Встановлює значення d командному рядку (можна вказати кілька значень).\nhelm upgrade <release> <chart> --force                    # Примусове оновлення ресурсів через стратегію заміни.\nhelm rollback <release> <revision>                        # Повертає реліз до певної версії.\nhelm rollback <release> <revision>  --cleanup-on-fail     # Дозволяє видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдалося здійснити.\n``` \n\n---\n\n### Вивід списку, додавання, видалення та оновлення репозиторіїв {#list-add-remove-and-update-repositories}\n\n```bash\nhelm repo add <repo-name> <url>   # Додає репозиторій з Інтернету.\nhelm repo list                    # Переглядає список доданих репозиторіїв чартів.\nhelm repo update                  # Оновлює інформацію про доступні чарти локально з репозиторіїв чартів.\nhelm repo remove <repo_name>      # Видаляє один або кілька репозиторіїв чартів.\nhelm repo index <DIR>             # Читає поточну теку та генерує файл індексу на основі знайдених чартів.\nhelm repo index <DIR> --merge     # Зливає згенерований індекс з існуючим файлом індексу.\nhelm search repo <keyword>        # Шукає в репозиторіях за ключовим словом в чарті.\nhelm search hub <keyword>         # Шукає чарт в Artifact Hub або у вашому власному хабі.\n```\n\n---\n\n### Моніторинг релізів Helm {#helm-release-monitoring}\n\n```bash\nhelm list                       # Переглядає всі релізи для вказаного простору імен, використовує поточний контекст простору імен, якщо простір не вказано.\nhelm list --all                 # Показує всі релізи без жодних фільтрів, можна використовувати -a.\nhelm list --all-namespaces      # Переглядає релізи по всіх просторах імен, можна використовувати -A.\nhelm list -l key1=value1,key2=value2 # Селектор (запит за мітками) для фільтрації, підтримує '=', '==' і '!='.\nhelm list --date                # Сортує за датою релізу.\nhelm list --deployed            # Показує розгорнуті релізи. Якщо не вказано інше, це буде автоматично увімкнено.\nhelm list --pending             # Показує очікуючі релізи.\nhelm list --failed              # Показує невдалі релізи.\nhelm list --uninstalled         # Показує видалені релізи (якщо використовувався 'helm uninstall --keep-history').\nhelm list --superseded          # Показує замінені релізи.\nhelm list -o yaml               # Виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table).\nhelm status <release>           # Ця команда показує статус зазначеного релізу.\nhelm status <release> --revision <number>   # Якщо встановлено, відображає статус зазначеного релізу з версією.\nhelm history <release>          # Історичні версії для даного релізу.\nhelm env                        # Env виводить всю інформацію про середовище, що використовується Helm.\n```\n\n---\n\n### Завантаження інформації про реліз {#download-release-information}\n\n```bash\nhelm get all <release>      # Колекція інформації про нотатки, хуки, надані значення та згенерований маніфест файлу для вказаного релізу.\nhelm get hooks <release>    # Завантажує хуки для вказаного релізу. Хуки форматує у YAML і розділяє за допомогою роздільника YAML '---\\n'.\nhelm get manifest <release> # Маніфест є YAML-кодованим поданням ресурсів Kubernetes, що були згенеровані з цього релізу чарту. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені в маніфест.\nhelm get notes <release>    # Показує нотатки, надані чартом для зазначеного релізу.\nhelm get values <release>   # Завантажує файл значень для даного релізу. Використовуйте -o для форматування виходу.\n```\n\n---\n\n### Управління втулками {#plugin-management}\n\n```bash\nhelm plugin install <path/url1>     # Встановлення втулків.\nhelm plugin list                    # Перегляд списку всіх встановлених втулків.\nhelm plugin update <plugin>         # Оновлення втулків.\nhelm plugin uninstall <plugin>      # Видалення втулка.\n```\n\n---\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/intro/index.mdx",
    "content": "---\ntitle: Вступ\nsidebar_position: 1\n---\n\n# Введення в Helm {#introduction-to-helm}\n\nВи новачок у Helm? Це місце, з якого варто почати!\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: Встановлення Helm\ndescription: Дізнайтеся, як встановити та розпочати роботу з Helm.\nsidebar_position: 2\n---\n\nЦей посібник показує, як встановити Helm CLI. Helm можна встановити або з джерела, або з попередньо зібраних бінарних релізів.\n\n## Від проєкту Helm {#from-the-helm-project}\n\nПроєкт Helm надає два способи отримання та встановлення Helm. Це офіційні методи отримання релізів Helm. Крім того, спільнота Helm пропонує методи встановлення Helm через різні менеджери пакетів. Встановлення через ці методи можна знайти нижче офіційних методів.\n\n### З бінарних релізів {#from-the-binary-releases}\n\nКожен [реліз](https://github.com/helm/helm/releases) Helm надає бінарні релізи для різних операційних систем. Ці бінарні версії можна завантажити та встановити вручну.\n\n1. Завантажте [бажану версію](https://github.com/helm/helm/releases)\n2. Розпакуйте її (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)\n3. Знайдіть бінарний файл `helm` у розпакованій директорії та перемістіть його в потрібне місце (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nПісля цього ви повинні мати можливість запускати клієнт і [додати стабільний репозиторій чарту](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`.\n\n**Примітка:** Автоматизовані тести Helm виконуються лише для Linux AMD64 під час GitHub Actions збірок та релізів. Тестування інших операційних систем є відповідальністю спільноти, якій потрібен Helm для цієї операційної системи.\n\n### Зі сценарію {#from-script}\n\nТепер Helm має скрипт інсталятора, який автоматично завантажує останню версію Helm і [встановлює її локально](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3).\n\nВи можете завантажити цей скрипт, а потім виконати його локально. Він добре задокументований, щоб ви могли ознайомитися з ним і зрозуміти, що він робить перед його запуском.\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\nТак, ви можете виконати `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`, якщо хочете жити на межі.\n\n## Через менеджери пакетів {#through-package-managers}\n\nСпільнота Helm надає можливість встановити Helm через менеджери пакетів операційних систем. Ці методи не підтримуються проєктом Helm і не вважаються надійними третіми сторонами.\n\n### Через Homebrew (macOS) {#from-homebrew-macos}\n\nЧлени спільноти Helm додали формулу Helm до Homebrew. Ця формула зазвичай оновлюється.\n\n```console\nbrew install helm\n```\n\n(Примітка: Також існує формула для emacs-helm, яка є іншим проєктом.)\n\n### Через Chocolatey (Windows) {#from-chocolatey-windows}\n\nЧлени спільноти Helm додали [пакет Helm](https://chocolatey.org/packages/kubernetes-helm) до [Chocolatey](https://chocolatey.org/). Цей пакет зазвичай оновлюється.\n\n```console\nchoco install kubernetes-helm\n```\n\n### Через Scoop (Windows) {#from-scoop-windows}\n\nЧлени спільноти Helm додали [пакет Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) до [Scoop](https://scoop.sh). Цей пакет зазвичай оновлюється.\n\n```console\nscoop install helm\n```\n\n### Через Winget (Windows) {#from-winget-windows}\n\nЧлени спільноти Helm додали [пакет Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) до [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Цей пакет зазвичай оновлюється.\n\n```console\nwinget install Helm.Helm\n```\n\n### Через Apt (Debian/Ubuntu) {#from-apt-debian-ubuntu}\n\nЧлени спільноти Helm додали [пакет Helm](https://helm.baltorepo.com/stable/debian/) для Apt. Цей пакет зазвичай оновлюється.\n\n```console\ncurl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\nsudo apt-get install apt-transport-https --yes\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### Через dnf/yum (fedora) {#from-dnf-yum-fedora}\n\nПочинаючи з Fedora 35, helm доступний в офіційному репозиторії. Ви можете встановити helm, виконавши:\n\n```console\nsudo dnf install helm\n```\n\n### Через Snap {#from-snap}\n\nСпільнота [Snapcrafters](https://github.com/snapcrafters) підтримує версію Snap пакету [Helm](https://snapcraft.io/helm):\n\n```console\nsudo snap install helm --classic\n```\n\n### Через pkg (FreeBSD) {#from-pkg-freebsd}\n\nЧлени спільноти FreeBSD додали [пакет Helm](https://www.freshports.org/sysutils/helm) до [Колекції портів FreeBSD](https://man.freebsd.org/ports). Цей пакет зазвичай оновлюється.\n\n```console\npkg install helm\n```\n\n### Збірки для розробників {#development-builds}\n\nОкрім релізів, ви можете завантажити або встановити розробницькі версії Helm.\n\n### З Canary збірок {#from-canary-builds}\n\n\"Canary\" збірки — це версії програмного забезпечення Helm, які створюються з останньої гілки `main`. Вони не є офіційними релізами та можуть бути нестабільними. Однак, вони надають можливість тестувати найновіші функції.\n\nCanary бінарні файли Helm зберігаються на [get.helm.sh](https://get.helm.sh). Ось посилання на основні збірки:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Експериментальний Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### З сирців (Linux, macOS) {#from-source}\n\nЗбірка Helm з сирців є дещо більш трудомісткою, але це найкращий спосіб, якщо ви хочете тестувати найновішу (передрелізну) версію Helm.\n\nУ вас повинно бути налаштоване середовище Go.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\nЗа необхідності, будуть завантажені залежності та збережені в кеші, а також перевірено конфігурацію. Після цього `helm` буде скомпільований і розміщений у `bin/helm`.\n\n## Підсумки {#conclusion}\n\nУ більшості випадків, встановлення настільки просте, як отримання попередньо зібраного бінарного файлу `helm`. Цей документ охоплює додаткові випадки для тих, хто хоче робити складніші речі з Helm.\n\nПісля успішного встановлення клієнта Helm, ви можете перейти до використання Helm для керування чартами та [додавання стабільного репозиторію чартів](/intro/quickstart.md#initialize-a-helm-chart-repository).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: Швидкий старт\ndescription: Як встановити та почати роботу з Helm, включаючи інструкції для дистрибутивів, поширені запитання та втулки.\nsidebar_position: 1\n---\n\nУ цьому посібнику ви дізнаєтеся, як швидко почати користуватися Helm.\n\n## Попередні умови {#prerequisites}\n\nДля успішного та належного використання Helm потрібні наступні умови.\n\n1. Кластер Kubernetes\n2. Визначення, які конфігурації безпеки застосувати до вашої інсталяції, якщо такі є\n3. Встановлення та налаштування Helm.\n\n### Встановлення Kubernetes або доступ до кластера {#install-kubernetes-or-have-access-to-a-cluster}\n\n- У вас повинен бути встановлений Kubernetes. Для останньої версії Helm ми рекомендуємо використовувати останню стабільну версію Kubernetes, що в більшості випадків є передостанньою мінорною версією.\n- У вас також має бути локально налаштована копія `kubectl`.\n\nДивіться [Політику підтримки версій Helm](/topics/version_skew.md) щодо максимальної підтримуваної різниці версій між Helm і Kubernetes.\n\n## Встановлення Helm {#install-helm}\n\nЗавантажте бінарний реліз клієнта Helm. Ви можете використовувати такі інструменти, як `homebrew`, або перегляньте [сторінку офіційних релізів](https://github.com/helm/helm/releases).\n\nДля отримання більш детальної інформації або інших варіантів, дивіться [посібник з встановлення](/intro/install.md).\n\n## Ініціалізація репозиторію Helm Chart {#initialize-a-helm-chart-repository}\n\nЯк тільки Helm буде готовий, ви можете додати репозиторій чартів. Перевірте [Artifact Hub](https://artifacthub.io/packages/search?kind=0) для доступних репозиторіїв чартів Helm.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nПісля цього ви зможете переглянути доступні для встановлення чарти:\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... і багато інших\n```\n\n## Встановлення прикладу чарту {#install-an-example-chart}\n\nДля встановлення чарту можна використати команду `helm install`. Helm пропонує кілька способів знаходження та встановлення чарту, але найпростіший — це використання чартів від `bitnami`.\n\n```console\n$ helm repo update              # Переконайтеся, що ви отримали останній список чартів\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nУ наведеному вище прикладі чарт `bitnami/mysql` було розгорнуто, а імʼя нашого нового релізу — `mysql-1612624192`.\n\nВи можете отримати уявлення про можливості цього чарту MySQL, виконавши команду `helm show chart bitnami/mysql`. Або ви можете виконати `helm show all bitnami/mysql`, щоб отримати всю інформацію про чарт.\n\nКожного разу, коли ви встановлюєте чарт, створюється новий реліз. Отже, один чарт може бути встановлений кілька разів у тому ж кластері. І кожен може керуватися та оновлюватися незалежно.\n\nКоманда `helm install` є дуже потужною з багатьма можливостями. Щоб дізнатися більше про неї, перегляньте\n[Посібник з використання Helm](/intro/using_helm.md).\n\n## Дізнайтеся про релізи {#learn-about-releases}\n\nДуже просто побачити, що було розгорнуто за допомогою Helm:\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nФункція `helm list` (або `helm ls`) покаже вам список усіх розгорнутих релізів.\n\n## Видалення релізу {#uninstall-a-release}\n\nЩоб видалити реліз, скористайтеся командою `helm uninstall`:\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nЦе видалить `mysql-1612624192` з Kubernetes, що видалить всі ресурси, повʼязані з релізом, а також історію релізу.\n\nЯкщо буде надано прапорець `--keep-history`, історія релізу буде збережена. Ви зможете запитувати інформацію про цей реліз:\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nОскільки Helm відстежує ваші релізи навіть після того, як ви їх видалили, ви можете переглядати історію кластера і навіть відновити реліз (за допомогою `helm rollback`).\n\n## Ознайомлення з довідкою {#reading-the-help-text}\n\nЩоб дізнатися більше про доступні команди Helm, використовуйте `helm help` або введіть команду з прапорцем `-h`:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: Використання Helm\ndescription: Описує основи роботи з Helm.\nsidebar_position: 3\n---\n\nЦей посібник пояснює основи використання Helm для керування пакетами у вашому кластері Kubernetes. Передбачається, що ви вже [встановили](/intro/install.md) клієнт Helm.\n\nЯкщо вас цікавить лише виконання кількох швидких команд, можливо, ви захочете почати з [Посібника зі швидкого старту](/intro/quickstart.md). У цьому розділі розглядаються особливості команд Helm та пояснюється, як використовувати Helm.\n\n## Три головні концепції {#three-big-concepts}\n\n*Chart* — це пакет Helm. Він містить усі необхідні визначення ресурсів для запуску застосунку, інструменту або сервісу всередині кластера Kubernetes. Думайте про це як про еквівалент формули Homebrew, пакету Apt dpkg або файлу Yum RPM для Kubernetes.\n\n*Repository* — це місце, де можна зібрати та поділитися чартами. Це як [архів CPAN](https://www.cpan.org) для Perl або [база пакетів Fedora](https://src.fedoraproject.org/), але для пакетів Kubernetes.\n\n*Release* — це екземпляр чарту, що працює в кластері Kubernetes. Один чарт можна встановити в кластер кілька разів. І кожного разу при встановленні створюється новий *реліз*. Наприклад, чарт MySQL. Якщо ви хочете, щоб у вашому кластері працювали дві бази даних, ви можете встановити цей чарт двічі. Кожен екземпляр матиме свій *реліз*, а також своє *імʼя релізу*.\n\nМаючи ці концепції на увазі, можна пояснити Helm так:\n\nHelm встановлює *чарти* у Kubernetes, створюючи новий *реліз* для кожного встановлення. А щоб знайти нові чарти, ви можете шукати їх у *репозиторіях чартів* Helm.\n\n## 'helm search': Пошук чартів {#helm-search-finding-charts}\n\nHelm постачається з потужною командою пошуку. Її можна використовувати для пошуку двох типів джерел:\n\n- `helm search hub` здійснює пошук у [Artifact Hub](https://artifacthub.io), який містить чарти helm із десятків різних репозиторіїв.\n- `helm search repo` здійснює пошук у репозиторіях, які ви додали до свого локального клієнта helm (за допомогою `helm repo add`). Цей пошук здійснюється за локальними даними, і підключення до публічної мережі не потрібно.\n\nВи можете знайти загальнодоступні чарти, виконавши команду `helm search hub`:\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Платформа для веб-публікацій для створення блогів і ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Чарт Helm для розгортання сайту WordPress на ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      Оператор WordPress для Helm\n```\n\nВищенаведений пошук знаходить усі чарти `wordpress` в Artifact Hub.\n\nБез фільтрації `helm search hub` показує всі доступні чарти.\n\n`helm search hub` показує URL-адресу розташування на [artifacthub.io](https://artifacthub.io/), але не власне репозиторій Helm. `helm search hub --list-repo-url` показує фактичну URL-адресу репозиторію Helm, що може бути корисним, коли ви хочете додати новий репозиторій: `helm repo add [NAME] [URL]`.\n\nЗа допомогою `helm search repo` ви можете знайти імена чартів у репозиторіях, які ви вже додали:\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nHelm search використовує алгоритм нечіткого порівняння рядків, тому можна вводити частини слів або фраз:\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nПошук — це чудовий спосіб знайти доступні пакети. Коли ви знайшли потрібний пакет, можете використовувати `helm install`, щоб встановити його.\n\n## 'helm install': Встановлення пакета {#helm-install-installing-a-package}\n\nЩоб встановити новий пакет, скористайтеся командою `helm install`. У найпростішому випадку вона приймає два аргументи: Імʼя релізу, яке ви вибираєте, та імʼя чарту, який ви хочете встановити.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Вт Січ 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Будь ласка, будьте терплячими, поки чарт розгортається **\n\nВаш сайт WordPress можна відкрити за наступною DNS-адресою зсередини вашого кластера:\n\n    happy-panda-wordpress.default.svc.cluster.local (порт 80)\n\nЩоб отримати доступ до вашого сайту WordPress з-за меж кластера, дотримуйтесь наступних кроків:\n\n1. Отримайте URL WordPress, виконавши наступні команди:\n\n  ПРИМІТКА: Може знадобитися кілька хвилин для отримання IP-адреси LoadBalancer.\n        Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"URL WordPress: http://$SERVICE_IP/\"\n   echo \"Адмінка WordPress: http://$SERVICE_IP/admin\"\n\n2. Відкрийте оглядач та отримайте доступ до WordPress, використовуючи отриманий URL.\n\n3. Увійдіть за допомогою наступних облікових даних:\n\n  echo Логін: user\n  echo Пароль: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nТепер чарт `wordpress` встановлено. Зверніть увагу, що встановлення чарту створює новий *реліз* обʼєкта. Реліз вище називається `happy-panda`. (Якщо ви хочете, щоб Helm згенерував імʼя для вас, не вказуйте імʼя релізу і використовуйте `--generate-name`.)\n\nПід час встановлення клієнт `helm` надасть корисну інформацію про те, які ресурси були створені, який стан релізу, і чи є додаткові кроки конфігурації, які ви можете або повинні виконати.\n\nHelm встановлює ресурси в наступному порядку:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n\nHelm не чекає, поки всі ресурси будуть запущені, перш ніж завершити роботу. Багато чартів потребують Docker-образів розміром понад 600MB, і їхнє встановлення в кластер може тривати певний час.\n\nЩоб відстежувати стан релізу або повторно прочитати конфігураційну інформацію, ви можете використати команду `helm status`:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Будь ласка, будьте терплячими, поки чарт розгортається **\n\nВаш сайт WordPress можна відкрити за наступною DNS-адресою в межах вашого кластера:\n\n    happy-panda-wordpress.default.svc.cluster.local (порт 80)\n\nЩоб отримати доступ до вашого сайту WordPress ззовні кластера, виконайте наступні дії:\n\n1. Отримайте URL WordPress, виконавши ці команди:\n\n  ЗАУВАЖЕННЯ: Для появи IP LoadBalancer може знадобитися кілька хвилин.\n        Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Відкрийте оглядач і перейдіть на WordPress, використовуючи отриманий URL.\n\n3. Увійдіть за допомогою наведених нижче облікових даних, щоб побачити ваш блог:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nВищенаведене показує поточний стан вашого релізу.\n\n### Налаштування чарту перед встановленням {#customizing-the-chart-before-installing}\n\nВстановлення у спосіб, який ми розглянули, використовуватиме лише стандартні параметри конфігурації для цього чарту. У багатьох випадках вам захочеться налаштувати чарт для використання ваші налаштування.\n\nЩоб побачити, які параметри можна налаштувати в чарті, використовуйте команду `helm show values`:\n\n```console\n$ helm show values bitnami/wordpress\n## Параметри глобального Docker-образу\n## Зверніть увагу, що це перевизначить параметри образу, включаючи залежності, налаштовані на використання глобального значення\n## Наявні глобальні параметри Docker-образу: imageRegistry та imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Версія образу Bitnami WordPress\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nВи можете перевизначити будь-які з цих налаштувань у файлі у форматі YAML, а потім передати цей файл під час встановлення.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nВищенаведене створить стандартного користувача MariaDB з імʼям `user0` і надасть цьому користувачеві доступ до новоствореної бази даних `user0db`, але всі інші параметри цього чарту залишаться стандартними.\n\nІснує два способи передати дані конфігурації під час встановлення:\n\n- `--values` (або `-f`): Вказати YAML-файл із перевизначеннями. Їх можна вказувати кілька разів, причому файл, що стоїть праворуч, матиме пріоритет\n- `--set`: Вказати перевизначення в командному рядку.\n\nЯкщо обидва варіанти використовуються, значення `--set` зливаються з `--values` з вищим пріоритетом. Перевизначення, зазначені за допомогою `--set`, зберігаються у Secret. Значення, що були встановлені через `--set`, можна переглянути для конкретного релізу за допомогою команди `helm get values <release-name>`. Значення, встановлені за допомогою `--set`, можна скинути, виконавши `helm upgrade` з параметром `--reset-values`.\n\n#### Формат і обмеження параметра `--set` {#the-format-and-limitations-of-set}\n\nОпція `--set` приймає нуль або більше пар імʼя/значення. У найпростішому випадку вона використовується так: `--set name=value`. Еквівалент у YAML виглядає так:\n\n```yaml\nname: value\n```\n\nКілька значень розділяються символами `,`. Отже, `--set a=b,c=d` стає:\n\n```yaml\na: b\nc: d\n```\n\nПідтримуються складніші вирази. Наприклад, `--set outer.inner=value` перетворюється на наступне:\n\n```yaml\nouter:\n  inner: value\n```\n\nСписки можна записати, включивши значення в `{` і `}`. Наприклад, `--set name={a, b, c}` перетворюється на:\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nДеякі пари імʼя/ключ можна встановити як `null` або як порожній масив `[]`. Наприклад, `--set name=[],a=null` перетворюється на:\n\n```yaml\nname: []\na: null\n```\n\nПочинаючи з Helm 2.5.0, можна отримувати доступ до елементів списку, використовуючи синтаксис індексу масиву. Наприклад, `--set servers[0].port=80` стає:\n\n```yaml\nservers:\n  - port: 80\n```\n\nКілька значень можна встановити таким чином. Наприклад, рядок `--set servers[0].port=80,servers[0].host=example` перетворюється на:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nІноді вам потрібно використовувати спеціальні символи у ваших рядках `--set`. Ви можете використовувати зворотний слеш для екранування символів; `--set name=value1\\,value2` перетвориться на:\n\n```yaml\nname: \"value1,value2\"\n```\n\nАналогічно, можна екранувати послідовності крапок, що може знадобитися, коли чарти використовують функцію `toYaml` для аналізу анотацій, міток і вибору вузлів. Синтаксис для `--set nodeSelector.\"kubernetes\\.io/role\"=master` виглядає так:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nГлибоко вкладені структури даних можуть бути складними для виразу через `--set`. Розробникам чартів рекомендується враховувати використання `--set` при розробці формату файлу `values.yaml` (докладніше про [Файли значень](/chart_template_guide/values_files.md)).\n\n### Інші методи встановлення {#more-installation-methods}\n\nКоманда `helm install` може встановлювати чарт із кількох джерел:\n\n- Репозиторій чартів (як ми бачили вище)\n- Локальний архів чарту (`helm install foo foo-0.1.1.tgz`)\n- Тека із розпакованим чартом (`helm install foo path/to/foo`)\n- Повний URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' і 'helm rollback': Оновлення релізу та відновлення у разі невдачі {#helm-upgrade-and-helm-rollback-updating-a-release-and-reverting-on-failure}\n\nКоли виходить нова версія чарту або коли ви хочете змінити конфігурацію вашого релізу, ви можете скористатися командою `helm upgrade`.\n\nОновлення бере поточний реліз і оновлює його відповідно до інформації, що міститься в чарті. Ви можете оновити чарт, який було встановлено зі сховища, або чарт, який знаходиться на вашому локальному диску.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nУ наведеному випадку реліз `happy-panda` оновлюється з використанням того ж чарту, але з новим YAML файлом:\n\n```yaml\nmariadb.auth.username: user1\n```\n\nМи можемо використати команду `helm get values`, щоб переконатися, що нові налаштування набрали чинності.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nКоманда `helm get` є корисним інструментом для перегляду релізу в кластері. І як ми бачили вище, вона показує, що наші нові значення з `panda.yaml` були розгорнуті в кластері.\n\nТепер, якщо під час релізу щось піде не так, можна легко повернутися до попереднього релізу, використовуючи команду `helm rollback [RELEASE] [REVISION]`.\n\n```console\n$ helm rollback happy-panda 1\n```\n\nЦя команда повертає наш реліз `happy-panda` до його першої версії. Версія релізу є інкрементним переглядом. Кожного разу, коли відбувається встановлення, оновлення або відкат, номер версії збільшується на 1. Перша версія завжди має номер 1. І ми можемо використовувати команду `helm history [RELEASE]`, щоб побачити номери версій для певного релізу.\n\n## Корисні опції для Install/Upgrade/Rollback {#useful-options-for-install-upgrade-rollback}\n\nЄ кілька інших корисних опцій, які можна вказати для налаштування поведінки Helm під час встановлення/оновлення/відкату. Зауважте, що це не повний список CLI-прапорців. Щоб побачити опис усіх прапорців, просто запустіть `helm <command> --help`.\n\n- `--timeout`: Значення [Go duration](https://golang.org/pkg/time/#ParseDuration), яке визначає, скільки чекати на завершення команд Kubernetes. Стандартно `5m0s`.\n- `--wait`: Очікує, доки всі Podʼи не перейдуть у стан готовності, PVC не будуть повʼязані, а Deployment не матиме мінімальну кількість Podʼів у стані готовності (`Desired` мінус `maxUnavailable`), а також не отримає IP-адресу (і Ingress, якщо це `LoadBalancer`) перед тим, як визнати реліз успішним. Чекання триватиме стільки часу, скільки вказано в опції `--timeout`. Якщо тайм-аут досягнуто, реліз буде позначено як `FAILED`. Примітка: У ситуаціях, коли Deployment має `replicas` значення 1, а `maxUnavailable` не встановлено в 0 як частина стратегії rolling update, `--wait` поверне готовність, коли задоволено мінімальну кількість Podʼів у готовому стані.\n- `--no-hooks`: Пропускає запуск хук для команди.\n- `--recreate-pods` (доступно лише для `upgrade` та `rollback`): Цей прапорець викличе повторне створення всіх Podʼів (за винятком Podʼів, що належать до Deployment). (Застаріле в Helm 3)\n\n## `helm uninstall`: Видалення релізу {#helm-uninstall-uninstalling-a-release}\n\nКоли настає час видалити реліз з кластера, використовуйте команду `helm uninstall`:\n\n```console\n$ helm uninstall happy-panda\n```\n\nЦе видалить реліз з кластера. Ви можете переглянути всі ваші поточні розгорнуті релізи за допомогою команди `helm list`:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nЗ виводу вище ми можемо побачити, що реліз `happy-panda` було видалено.\n\nУ попередніх версіях Helm, коли реліз видалявся, запис про його видалення залишався. У Helm 3 видалення також видаляє запис про реліз. Якщо ви хочете зберегти запис про видалений реліз, використовуйте `helm uninstall --keep-history`. Використання `helm list --uninstalled` покаже лише ті релізи, які були видалені з прапорцем `--keep-history`.\n\nПрапорець `helm list --all` покаже вам всі записи релізів, які зберіг Helm, включаючи записи для невдалих або видалених елементів (якщо було вказано `--keep-history`):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nЗверніть увагу, що через те, що релізи тепер стандартно видаляються, більше неможливо зробити відкат до видаленого ресурсу.\n\n## `helm repo`: Робота з репозиторіями {#helm-repo-working-with-repositories}\n\nHelm 3 більше не постачається зі стандартним репозиторієм чартів. Група команд `helm repo` надає команди для додавання, перегляду та видалення репозиторіїв.\n\nВи можете переглянути, які репозиторії налаштовані, використовуючи `helm repo list`:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nНові репозиторії можна додати за допомогою `helm repo add [NAME] [URL]`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nОскільки репозиторії чартів часто змінюються, у будь-який момент ви можете переконатися, що ваш клієнт Helm актуальний, запустивши `helm repo update`.\n\nРепозиторії можна видалити за допомогою `helm repo remove`.\n\n## Створення власних чартів {#creating-your-own-charts}\n\n[Посібник з розробки чартів](/topics/charts.md) пояснює, як розробляти власні чарти. Але ви можете швидко розпочати, використовуючи команду `helm create`:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nТепер у вас є чарт в теці `./deis-workflow`. Ви можете редагувати його та створювати власні шаблони.\n\nКоли ви редагуєте свій чарт, ви можете перевірити, чи він добре сформований, запустивши команду `helm lint`.\n\nКоли настане час упакувати чарт для розповсюдження, ви можете скористатися командою `helm package`:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nІ цей чарт тепер може бути легко встановлена за допомогою `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nУпаковані чарти можуть бути завантажені в репозиторії чартів. Для отримання додаткової інформації дивіться документацію про [репозиторії чартів Helm](/topics/chart_repository.md).\n\n## Висновки {#conclusion}\n\nУ цьому розділі було розглянуто основні шаблони використання клієнта `helm`, включаючи пошук, встановлення, оновлення та видалення. Також було розглянуто корисні утиліти, такі як `helm status`, `helm get` і `helm repo`.\n\nДля отримання додаткової інформації про ці команди перегляньте вбудовану довідку Helm: `helm help`.\n\nУ [наступному розділі](/howto/charts_tips_and_tricks.md) ми розглянемо процес створення чартів.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_install.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tinstallClient := action.NewInstall(actionConfig)\n\n\tinstallClient.DryRunOption = \"none\"\n\tinstallClient.ReleaseName = releaseName\n\tinstallClient.Namespace = settings.Namespace()\n\tinstallClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tinstallClient.CertFile,\n\t\tinstallClient.KeyFile,\n\t\tinstallClient.CaFile,\n\t\tinstallClient.InsecureSkipTLSverify,\n\t\tinstallClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tinstallClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tif chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil {\n\t\tif err := action.CheckDependencies(chart, chartDependencies); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !installClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tmanager := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          installClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t\tRegistryClient:   installClient.GetRegistryClient(),\n\t\t\t}\n\t\t\tif err := manager.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := installClient.RunWithContext(ctx, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run install: %w\", err)\n\t}\n\n\tlogger.Printf(\"release created:\\n%+v\", *release)\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_list.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runList(logger *log.Logger, settings *cli.EnvSettings) error {\n\n\tactionConfig, err := initActionConfigList(settings, logger, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tlistClient := action.NewList(actionConfig)\n\t// Only list deployed\n\t//listClient.Deployed = true\n\tlistClient.All = true\n\tlistClient.SetStateMask()\n\n\tresults, err := listClient.Run()\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run list action: %w\", err)\n\t}\n\n\tfor _, rel := range results {\n\t\tlogger.Printf(\"list result: %+v\", rel)\n\t}\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_main.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"bufio\"\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\t\"os\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/registry\"\n)\n\nvar helmDriver string = os.Getenv(\"HELM_DRIVER\")\n\nfunc initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) {\n\treturn initActionConfigList(settings, logger, false)\n}\n\nfunc initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) {\n\n\tactionConfig := new(action.Configuration)\n\n\tnamespace := func() string {\n\t\t// For list action, you can pass an empty string instead of settings.Namespace() to list\n\t\t// all namespaces\n\t\tif allNamespaces {\n\t\t\treturn \"\"\n\t\t}\n\t\treturn settings.Namespace()\n\t}()\n\n\tif err := actionConfig.Init(\n\t\tsettings.RESTClientGetter(),\n\t\tnamespace,\n\t\thelmDriver,\n\t\tlogger.Printf); err != nil {\n\t\treturn nil, err\n\t}\n\n\treturn actionConfig, nil\n}\n\nfunc newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) {\n\topts := []registry.ClientOption{\n\t\tregistry.ClientOptDebug(settings.Debug),\n\t\tregistry.ClientOptEnableCache(true),\n\t\tregistry.ClientOptWriter(os.Stderr),\n\t\tregistry.ClientOptCredentialsFile(settings.RegistryConfig),\n\t}\n\tif plainHTTP {\n\t\topts = append(opts, registry.ClientOptPlainHTTP())\n\t}\n\n\t// Create a new registry client\n\tregistryClient, err := registry.NewClient(opts...)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) {\n\tif certFile != \"\" && keyFile != \"\" || caFile != \"\" || insecureSkipTLSverify {\n\t\tregistryClient, err := registry.NewRegistryClientWithTLS(\n\t\t\tlogger.Writer(),\n\t\t\tcertFile,\n\t\t\tkeyFile,\n\t\t\tcaFile,\n\t\t\tinsecureSkipTLSverify,\n\t\t\tsettings.RegistryConfig,\n\t\t\tsettings.Debug)\n\n\t\tif err != nil {\n\t\t\treturn nil, err\n\t\t}\n\t\treturn registryClient, nil\n\t}\n\tregistryClient, err := newRegistryClient(settings, plainHTTP)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc main() {\n\n\tlogger := log.Default()\n\n\t// For convenience, initialize SDK setting via CLI mechanism\n\tsettings := cli.New()\n\n\t// Release name, chart and values\n\treleaseName := \"helm-sdk-example\"\n\tchartRef := \"oci://ghcr.io/stefanprodan/charts/podinfo\"\n\treleaseValues := map[string]interface{}{\n\t\t\"replicaCount\": \"2\",\n\t}\n\n\t// Pull the chart to the local filesystem\n\tif err := runPull(logger, settings, chartRef, \"6.4.1\"); err != nil {\n\t\tfmt.Printf(\"failed to run pull: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// Install the chart (from the pulled chart local archive)\n\tif err := runInstall(context.TODO(), logger, settings, releaseName, \"./podinfo-6.4.1.tgz\", \"\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run install: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart installed. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Upgrade to version 6.5.4, updating the replicaCount to three\n\treleaseValues[\"replicaCount\"] = \"3\"\n\tif err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, \"6.5.4\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run upgrade: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart upgraded. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Uninstall the chart\n\tif err := runUninstall(logger, settings, releaseName); err != nil {\n\t\tfmt.Printf(\"failed to run uninstall: %+v\", err)\n\t\tos.Exit(1)\n\t}\n}\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_pull.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tregistryClient, err := newRegistryClient(settings, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tactionConfig.RegistryClient = registryClient\n\n\tpullClient := action.NewPullWithOpts(\n\t\taction.WithConfig(actionConfig))\n\t// client.RepoURL = \"\"\n\tpullClient.DestDir = \"./\"\n\tpullClient.Settings = settings\n\tpullClient.Version = chartVersion\n\n\tresult, err := pullClient.Run(chartRef)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to pull chart: %w\", err)\n\t}\n\n\tlogger.Printf(\"%+v\", result)\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_uninstall.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tuninstallClient := action.NewUninstall(actionConfig)\n\tuninstallClient.DeletionPropagation = \"foreground\" // \"background\" or \"orphan\"\n\n\tresult, err := uninstallClient.Run(releaseName)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run uninstall action: %w\", err)\n\t}\n\tif result != nil {\n\t\tlogger.Printf(\"result: %+v\\n\", *result.Release)\n\t}\n\n\tlogger.Printf(\"release \\\"%s\\\" uninstalled\\n\", releaseName)\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_upgrade.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tupgradeClient := action.NewUpgrade(actionConfig)\n\n\tupgradeClient.Namespace = settings.Namespace()\n\tupgradeClient.DryRunOption = \"none\"\n\tupgradeClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tupgradeClient.CertFile,\n\t\tupgradeClient.KeyFile,\n\t\tupgradeClient.CaFile,\n\t\tupgradeClient.InsecureSkipTLSverify,\n\t\tupgradeClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"missing registry client: %w\", err)\n\t}\n\tupgradeClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to load chart: %w\", err)\n\t}\n\tif req := chart.Metadata.Dependencies; req != nil {\n\t\tif err := action.CheckDependencies(chart, req); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !upgradeClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tman := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          upgradeClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t}\n\t\t\tif err := man.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run upgrade action: %w\", err)\n\t}\n\n\tlogger.Printf(\"release: %+v\", release)\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx",
    "content": "---\ntitle: Приклади\ndescription: Приклади різних функцій Helm SDK\nsidebar_position: 2\n---\nimport Install from './_install.mdx'\nimport List from './_list.mdx'\nimport Main from './_main.mdx'\nimport Pull from './_pull.mdx'\nimport Uninstall from './_uninstall.mdx'\nimport Upgrade from './_upgrade.mdx'\n\nЦей документ містить серію прикладів використання Helm SDK. Призначений для документування різних функціональних можливостей SDK.\n\nОстанній приклад показує драйвер `main.go` ([посилання](#driver)). Він виконує наведені нижче дії та включає необхідні допоміжні функції.\n\nКод для прикладів знаходиться в директорії [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples). І він повністю функціональний.\n\n## Дії {#actions}\n\n### Встановлення (Install) {#install-action}\n\nЦей приклад встановлює вказаний чарт/реліз для вказаної версії та значень:\n\n<Install />\n\n### Оновлення (Upgrade) {#upgrade-action}\n\nЦей приклад оновлює вказаний реліз з вказаним чартом, версією та значеннями:\n\n<Upgrade />\n\n### Видалення (Uninstall) {#uninstall-action}\n\nЦей приклад видаляє вказаний реліз\n\n<Uninstall />\n\n### Виводу списку чартів (List) {#list-action}\n\nЦей приклад показує всі чарти (в поточному налаштованому просторі імен)\n\n<List />\n\n### Завантаження чартів (Pull) {#pull-action}\n\nЦей приклад завантажує чарт з OCI репозиторію\n\n<Pull />\n\n## Драйвер {#driver}\n\nТут драйвер показує необхідні допоміжні функції, потрібні для роботи дій Helm SDK. І показує наведені вище приклади в дії, щоб завантажити, встановити, оновити та видалити чарт 'podinfo' з OCI репозиторію.\n\n<Main />\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: Вступ\ndescription: Представляємо Helm Go SDK\naliases:\n  - /docs/gosdk\nsidebar_position: 1\n---\nGo SDK Helm дозволяє програмному забезпеченню користувача використовувати чарти Helm та функціональність Helm для керування розгортанням програмного забезпечення Kubernetes\n(Насправді, інтерфейс командного рядка Helm — це просто один з таких інструментів!)\n\nЗараз SDK функціонально відокремлений від CLI Helm. І SDK може використовуватися (і використовується) окремими інструментами. Проєкт Helm зобовʼязується зберігати стабільність API для SDK. Варто зауважити, що SDK все ще має деякі шорсткості, що залишилися від початкової роботи з відокремлення CLI та SDK. Проєкт Helm має на меті покращити це з часом.\n\nПовну документацію API можна знайти за посиланням [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3).\n\nНижче наведено короткий огляд основних типів пакетів та простий приклад. Дивіться розділ [Приклади](/sdk/examples.mdx) для більшої кількості прикладів та більш повнофункціонального 'драйвера'.\n\n## Огляд основних пакетів {#main-package-overview}\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Містить основний \"клієнт\" для виконання дій Helm. Це той самий пакет, який використовує CLI під капотом. Якщо вам потрібно виконувати базові команди Helm з іншої Go програми, цей пакет для вас\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): Методи та допоміжні функції для завантаження та маніпулювання чартами\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) та його підпакети: Містить усі обробники для стандартних змінних середовища Helm, а його підпакети містять обробку виводу та файлів значень\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): Визначає обʼєкт `Release` та статуси\n\nОкрім цих є ще багато інших пакетів, тож перегляньте документацію для отримання додаткової інформації!\n\n### Простий приклад {#simple-example}\n\nЦе простий приклад виконання команди `helm list` за допомогою Go SDK. Дивіться розділ [Приклади](/sdk/examples.mdx) для більш повнофункціональних прикладів.\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // Ви можете передати порожній рядок замість settings.Namespace(), щоб\n    // перелічити всі простори імен\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Вивести перелік тільки розгорнутих\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n## Сумісність {#compatibility}\n\nHelm SDK чітко дотримується гарантій зворотної сумісності Helm:\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\nТобто, значні зміни буде внесено лише в основних (major) версіях.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/index.mdx",
    "content": "---\ntitle: Go SDK\nsidebar_position: 7\n---\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: Розширені техніки Helm\ndescription: Описує різні розширені функції для досвдічених користувачів Helm\nsidebar_position: 9\n---\n\nЦей розділ пояснює різні розширені функції та техніки використання Helm. Інформація в цьому розділі призначена для \"досвідчених користувачів\" Helm, які бажають здійснювати докладні налаштування та маніпуляції з їх чартами та випусками. Кожна з цих розширених функцій має свої переваги та обмеження, тому кожну з них потрібно використовувати обережно і з глибокими знаннями Helm. Іншими словами, памʼятайте про [принцип Пітера Паркера](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility).\n\n## Пост-рендеринг {#post-rendering}\n\nПост-рендеринг дає можливість встановлювачу чартів вручну маніпулювати, налаштовувати та/або перевіряти створені маніфести перед їх встановленням через Helm. Це дозволяє користувачам з додатковими потребами у налаштуванні використовувати інструменти, такі як [`kustomize`](https://kustomize.io), для застосування змін конфігурації без необхідності створювати форк публічного чарту або вимагати від супроводжувачів чартів вказувати всі можливі опції конфігурації для програмного забезпечення. Є також випадки для впровадження загальних інструментів та контейнерів sidecar у корпоративних середовищах або для аналізу маніфестів перед розгортанням.\n\n### Передумови {#prerequisites}\n\n- Helm 3.1+\n\n### Використання {#usage}\n\nПост-рендерер може бути будь-яким виконуваним файлом, який приймає створені маніфести Kubernetes через STDIN та повертає дійсні маніфести Kubernetes через STDOUT. Він повинен повертати ненульовий код завершення у випадку помилки. Це єдиний \"API\" між двома компонентами. Це дозволяє значну гнучкість у тому, що ви можете робити з вашим процесом пост-рендерингу.\n\nПост-рендерер можна використовувати з `install`, `upgrade` і `template`. Щоб використовувати пост-рендерер, використовуйте прапорець `--post-renderer` з шляхом до виконуваного файлу рендерера, який ви бажаєте використовувати:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nЯкщо шлях не містить жодних роздільників, пошук буде здійснюватись в $PATH, в іншому випадку буде створено будь-які відносні шляхи до повністю кваліфікованого шляху.\n\nЯкщо ви бажаєте використовувати кілька пост-рендерерів, викликайте їх усіх у скрипті або разом у будь-якому бінарному інструменті, який ви створили. У bash це буде так просто, як `renderer1 | renderer2 | renderer3`.\n\nПриклад використання `kustomize` як пост-рендерера можна побачити [тут](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n### Обмеження {#caveats}\n\nПри використанні пост-рендерерів є кілька важливих моментів, які слід враховувати. Найважливіше з них полягає в тому, що при використанні пост-рендерера всі особи, які модифікують цей випуск, **МУСЯТЬ** використовувати той же рендерер для забезпечення повторюваних збірок. Ця функція спеціально створена для того, щоб дозволити будь-якому користувачеві змінювати рендерер або перестати використовувати рендерер, але це слід робити обережно, щоб уникнути випадкових змін або втрати даних.\n\nЩе одне важливе зауваження стосується безпеки. Якщо ви використовуєте пост-рендерер, ви повинні впевнитися, що він надходить з надійного джерела (так само як і будь-яке інше програмне забезпечення). Використання ненадійних або неперевірених рендерерів НЕ рекомендовано, оскільки вони мають повний доступ до створених шаблонів, які часто містять секретні дані.\n\n### Власні пост-рендерери {#custom-post-renderers}\n\nКрок пост-рендерингу пропонує ще більше гнучкості при використанні в Go SDK. Будь-який пост-рендерер повинен реалізувати наступний Go інтерфейс:\n\n```go\ntype PostRenderer interface {\n    // Run очікує один буфер, заповнений відрендереними маніфестами Helm. Він\n    // очікує, що модифіковані результати будуть повернені в окремому буфері або\n    // помилку, якщо виникла проблема або збій під час виконання кроку пост-рендерингу\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nБільше інформації про використання Go SDK можна знайти в [розділі Go SDK](#go-sdk).\n\n## Go SDK {#go-sdk}\n\nHelm 3 представив повністю переписаний Go SDK для кращого досвіду при розробці програмного забезпечення та інструментів, які використовують Helm. Повну документацію можна знайти в [розділі Go SDK](/sdk/gosdk.md).\n\n## Сховища даних {#storage-backends}\n\nHelm 3 змінив стандартне зберігання інформації про випуски на Secrets у просторі імен випуску. Helm 2 стандартно зберігає інформацію про випуски як ConfigMaps у просторі імен екземпляра Tiller. Підрозділи, що йдуть далі, показують, як налаштувати різні бекенди. Це налаштування базується на змінній середовища `HELM_DRIVER`. Вона може бути встановлена на одне зі значень: `[configmap, secret, sql]`.\n\n### Бекенд зберігання ConfigMap {#configmap-storage-backend}\n\nЩоб активувати бекенд ConfigMap, потрібно встановити змінну середовища `HELM_DRIVER` на `configmap`.\n\nВи можете встановити її в оболонці наступним чином:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nЯкщо ви хочете перемикнутися зі стандартного бекенду на бекенд ConfigMap, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про випуски за допомогою наступної команди:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**Примітки щодо операційної діяльності**: Інформація про випуски включає вміст чартів та файлів значень і тому може містити чутливі дані (наприклад, паролі, приватні ключі та інші облікові дані), які потрібно захищати від несанкціонованого доступу. При керуванні авторизацією 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, оскільки це може розкрити чутливі дані вашого застосунку.\n\n### Бекенд зберігання SQL {#sql-storage-backend}\n\nІснує ***бета*** бекенд зберігання SQL, який зберігає інформацію про випуски в SQL базі даних.\n\nВикористання такого бекенду зберігання є особливо корисним, якщо інформація про ваші випуски перевищує 1 МБ (у цьому випадку її не можна зберігати в ConfigMaps/Secrets через внутрішні обмеження сховища ключ-значення etcd у Kubernetes).\n\nЩоб активувати SQL бекенд, потрібно розгорнути SQL базу даних і встановити змінну середовища `HELM_DRIVER` на `sql`. Деталі бази даних задаються змінною середовища `HELM_DRIVER_SQL_CONNECTION_STRING`.\n\nВи можете встановити її в оболонці наступним чином:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Примітка: Зараз підтримується лише PostgreSQL.\n\n**Примітки щодо операційної діяльності**:\n\nРекомендується:\n\n- Підготувати вашу базу даних для операційної діяльності. Для PostgreSQL перегляньте [документацію з адміністрування сервера](https://www.postgresql.org/docs/12/admin.html) для отримання додаткової інформації.\n- Увімкнути [управління дозволами](/topics/permissions_sql_storage_backend.md) для дзеркального відображення Kubernetes RBAC для інформації про випуски.\n\nЯкщо ви хочете перемикнутися зі стандартного бекенду на SQL бекенд, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про випуски за допомогою наступної команди:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Архітектура Helm\ndescription: Описує архітектуру Helm на високому рівні.\nsidebar_position: 8\n---\n\n# Архітектура Helm {#helm-architecture}\n\nЦей документ описує архітектуру Helm на високому рівні.\n\n## Призначення Helm {#the-purpose-of-helm}\n\nHelm — це інструмент для керування пакетами Kubernetes, що називаються _чартами_. Helm може:\n\n- Створювати нові чарти з нуля\n- Упаковувати чарт в архіви чартів (tgz)\n- Взаємодіяти з репозиторіями чартів, де зберігаються чарти\n- Встановлювати та видаляти чарти в наявному кластері Kubernetes\n- Керувати циклом випуску чартів, які були встановлені за допомогою Helm\n\nДля Helm є три важливі концепції:\n\n1. _Chart_ — це пакет інформації, необхідної для створення екземпляра застосунку Kubernetes.\n2. _Config_ містить конфігураційну інформацію, яку можна обʼєднати з упакованим чартом для створення обʼєкта, що підлягає випуску.\n3. _Release_ — це запущений екземпляр _чарту_, поєднаний з конкретним _конфігом_.\n\n## Компоненти {#components}\n\nHelm є виконуваним файлом, який реалізовано в двох окремих частинах:\n\n**Клієнт Helm** — це клієнт командного рядка для кінцевих користувачів. Клієнт відповідає за:\n\n- Розробку локальних чартів\n- Керування репозиторіями\n- Керування випусками\n- Взаємодію з бібліотекою Helm\n  - Надсилання чартів для встановлення\n  - Запит на оновлення або видалення наявних випусків\n\n**Бібліотека Helm** надає логіку для виконання всіх операцій Helm. Вона взаємодіє з API-сервером Kubernetes і забезпечує такі можливості:\n\n- Обʼєднання чарту і конфігурації для створення випуску\n- Встановлення чартів у Kubernetes і надання наступного обʼєкта випуску\n- Оновлення та видалення чартів шляхом взаємодії з Kubernetes\n\nОкрема бібліотека Helm інкапсулює логіку Helm, щоб її можна було використовувати різними клієнтами.\n\n## Реалізація {#implementation}\n\nКлієнт та бібліотека Helm написані мовою програмування Go.\n\nБібліотека використовує клієнтську бібліотеку Kubernetes для комунікації з Kubernetes.Зараз ця бібліотека використовує REST+JSON. Інформація зберігається у Secrets, розташованих всередині Kubernetes. Вона не потребує власної бази даних.\n\nКонфігураційні файли, коли це можливо, написані у YAML.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: Репозиторій чартів\ndescription: Як створити та працювати з репозиторіями чартів Helm.\nsidebar_position: 6\n---\n\nЦей розділ пояснює, як створювати та працювати з репозиторіями чартів Helm. На високому рівні, репозиторій чартів — це місце, де можуть зберігатися та розповсюджуватися упаковані чарти.\n\nРозподілений репозиторій спільноти чартів Helm знаходиться на [Artifact Hub](https://artifacthub.io/packages/search?kind=0) та запрошує вас долучитися. Однак Helm також дозволяє вам створювати власні репозиторії чартів. Цей посібник пояснює, як це зробити.\n\n### Передумови {#prerequisites}\n\n- Пройдіть [Керівництво з швидкого старту](/intro/quickstart.md)\n- Ознайомтеся з документом [Чарти](/topics/charts.md)\n\n### Створення репозиторію чартів {#create-a-chart-repository}\n\n_Репозиторій чартів_ — це HTTP-сервер, який містить файл `index.yaml` і, за бажанням, деякі упаковані чарти. Коли ви готові поділитися своїми чартами, найкращий спосіб зробити це — завантажити їх до репозиторію чартів.\n\nЗ версії Helm 2.2.0 підтримується SSL-автентифікація клієнта для репозиторіїв. Інші протоколи автентифікації можуть бути доступні як втулки.\n\nОскільки репозиторій чартів може бути будь-яким HTTP-сервером, який може обслуговувати YAML і tar файли та відповідати на GET-запити, у вас є безліч варіантів для хостингу власного репозиторію чартів. Наприклад, ви можете використовувати Google Cloud Storage (GCS), Amazon S3, GitHub Pages або навіть розгорнути власний вебсервер.\n\n### Структура репозиторію чартів {#the-chart-repository-structure}\n\nРепозиторій чартів складається з упакованих чартів і спеціального файлу з назвою `index.yaml`, який містить індекс усіх чартів у репозиторії. Зазвичай чарти, описані в `index.yaml`, також розміщуються на тому ж сервері, як і [файли походження](/topics/provenance.md).\n\nНаприклад, структура репозиторію `https://example.com/charts` може виглядати так:\n\n```none\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nУ цьому випадку файл індексу міститиме інформацію про один чарт, Alpine, і надаватиме URL для завантаження `https://example.com/charts/alpine-0.1.2.tgz` для цього чарту.\n\nНе обовʼязково, щоб пакет чарту розміщувався на тому ж сервері, що й файл `index.yaml`. Однак, це часто є найпростішим варіантом.\n\n### Файл індексу {#the-index-file}\n\nФайл індексу — це YAML-файл з назвою `index.yaml`. Він містить деякі метадані про пакети, включаючи вміст файлу `Chart.yaml` чарту. Дійсний репозиторій чартів повинен мати файл індексу. Файл індексу містить інформацію про кожен чарт у репозиторії чартів. Команда `helm repo index` створить файл індексу на основі заданої локальної теки, яка містить упаковані чарти.\n\nПриклад файлу індексу:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Хостинг репозиторіїв чартів {#hosting-chart-repositories}\n\nУ цьому розділі показано кілька способів хостингу репозиторію чартів.\n\n### Google Cloud Storage (GCS)\n\nПершим кроком є **створення кошика GCS**. Назвемо його `fantastic-charts`.\n\n![Створення кошика GCS](/img/helm2/create-a-bucket.png)\n\nДалі, зробіть свій кошик публічним, **редагувавши дозволи кошику**.\n\n![Редагування дозволів](/img/helm2/edit-permissions.png)\n\nДодайте цей пункт, щоб **зробити кошик публічним**:\n\n![Зробити кошик публічним](/img/helm2/make-bucket-public.png)\n\nВітаємо, тепер у вас є порожній кошик GCS, готовий для обслуговування чартів!\n\nВи можете завантажити свій репозиторій чартів за допомогою командного рядка Google Cloud Storage або через вебінтерфейс GCS. Доступ до публічного кошика GCS можна отримати через простий HTTPS за цією адресою: `https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith {#cloudsmith}\n\nВи також можете налаштувати репозиторії чартів за допомогою Cloudsmith. Дізнайтеся більше про репозиторії чартів з Cloudsmith [тут](https://help.cloudsmith.io/docs/helm-chart-repository).\n\n### JFrog Artifactory {#jfrog-artifactory}\n\nАналогічно, ви можете налаштувати репозиторії чартів за допомогою JFrog Artifactory. Дізнайтеся більше про репозиторії чартів з JFrog Artifactory [тут](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories).\n\n### Приклад GitHub Pages {#github-pages-example}\n\nПодібним чином ви можете створити репозиторій чартів за допомогою GitHub Pages.\n\nGitHub дозволяє обслуговувати статичні вебсторінки двома різними способами:\n\n- Налаштувавши проєкт на обслуговування вмісту його теки `docs/`\n- Налаштувавши проєкт на обслуговування певної гілки\n\nМи скористаємося другим підходом, хоча перший також простий.\n\nПерший крок — **створити гілку gh-pages**. Ви можете зробити це локально:\n\n```console\n$ git checkout -b gh-pages\n```\n\nАбо через веббраузер, використовуючи кнопку **Branch** у вашому репозиторії GitHub:\n\n![Створення гілки GitHub Pages](/img/helm2/create-a-gh-page-button.png)\n\nДалі потрібно переконатися, що ваша **гілка gh-pages** налаштована як GitHub Pages. Для цього натисніть у вашому репо кнопку **Settings** і прокрутіть до розділу **GitHub pages** і налаштуйте його, як показано нижче:\n\n![Налаштування гілки GitHub Pages](/img/helm2/set-a-gh-page.png)\n\nСтандартно **Source** зазвичай встановлюється на **gh-pages branch**. Якщо це не встановлено, виберіть його.\n\nВи можете використовувати **власний домен**, якщо бажаєте.\n\nІ переконайтеся, що **Enforce HTTPS** відмічено, щоб **HTTPS** використовувався під час обслуговування чартів.\n\nУ такому налаштуванні ви можете використовувати основну гілку для зберігання коду чартів, а **гілку gh-pages** як репозиторій чартів, наприклад: `https://USERNAME.github.io/REPONAME`. Демонстраційний репозиторій [TS Charts](https://github.com/technosophos/tscharts) доступний за адресою `https://technosophos.github.io/tscharts/`.\n\nЯкщо ви вирішили використовувати 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).\n\n### Звичайні вебсервери {#ordinary-web-servers}\n\nЩоб налаштувати звичайний вебсервер для обслуговування чартів Helm, вам просто потрібно зробити наступне:\n\n- Помістіть ваш індекс і чарти в теку, яку сервер може обслуговувати\n- Переконайтеся, що файл `index.yaml` доступний без необхідності автентифікації\n- Переконайтеся, що файли `yaml` обслуговуються з правильним типом вмісту (`text/yaml` або `text/x-yaml`)\n\nНаприклад, якщо ви хочете обслуговувати свої чарти з теки `$WEBROOT/charts`, переконайтеся, що у вашому вебкорені є тека `charts/`, і помістіть туди файл індексу та чарти.\n\n### Сервер репозиторію ChartMuseum {#chartmuseum-repository-server}\n\nChartMuseum — це сервер репозиторію чартів 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/).\n\nВи також можете використовувати сервер [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) для хостингу репозиторію чартів з локальної файлової системи.\n\n### Реєстр пакетів GitLab {#gitlab-package-registry}\n\nЗ GitLab ви можете публікувати чарти Helm у реєстрі пакетів вашого проєкту. Дізнайтеся більше про налаштування репозиторію пакетів Helm за допомогою GitLab [тут](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Управління репозиторіями чартів {#managing-chart-repositories}\n\nТепер, коли у вас є репозиторій чартів, остання частина цього посібника пояснює, як підтримувати чарти в цьому репозиторії.\n\n### Зберігання чартів у вашому репозиторії чартів {#storing-charts-in-your-chart-repository}\n\nТепер, коли у вас є репозиторій чартів, завантажимо чарти та файл індексу до репозиторію. Чарти в репозиторії мають бути запаковані (`helm package chart-name/`) та правильно версійовані (відповідно до рекомендацій [SemVer 2](https://semver.org/)).\n\nНаступні кроки складають приклад робочого процесу, але ви можете використовувати будь-який зручний вам процес для зберігання та оновлення чартів у вашому репозиторії.\n\nЯк тільки у вас є готовий запакований чарт, створіть нову теку і перемістіть туди ваш запакований чарт.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nОстання команда бере шлях до щойно створеної локальної теки та URL вашого віддаленого репозиторію чартів і створює файл `index.yaml` у вказаній теці.\n\nТепер ви можете завантажити чарт і файл індексу у ваш репозиторій чартів, використовуючи інструмент синхронізації або вручну. Якщо ви використовуєте Google Cloud Storage, ознайомтеся з цим [прикладом робочого процесу](/howto/chart_repository_sync_example.md), що використовує клієнт gsutil. Для GitHub ви можете просто помістити чарти у відповідну гілку призначення.\n\n### Додавання нових чартів до наявного репозиторію {#adding-new-charts-to-an-existing-repository}\n\nЩоразу, коли ви хочете додати новий чарт у ваш репозиторій, потрібно перестворити індекс. Команда `helm repo index` повністю перебудовує файл `index.yaml` з нуля, включаючи лише ті чарти, які вона знаходить локально.\n\nОднак, ви можете використовувати прапорець `--merge` для поступового додавання нових чартів до наявного файлу `index.yaml` (чудовий варіант під час роботи з віддаленим репозиторієм, як-от GCS). Виконайте команду `helm repo index --help`, щоб дізнатися більше.\n\nПереконайтеся, що ви завантажили як оновлений файл `index.yaml`, так і чарт. Якщо ви згенерували файл підтвердження цілісності, завантажте і його.\n\n### Поділитися чартами з іншими {#share-your-charts-with-others}\n\nКоли ви готові поділитися чартами, просто повідомте комусь URL вашого репозиторію.\n\nПісля цього вони додадуть репозиторій до свого клієнта helm через команду `helm repo add [NAME] [URL]` з будь-яким імʼям, яке вони хочуть використовувати для позначення репозиторію.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nЯкщо чарти захищені за допомогою базової автентифікації HTTP, ви також можете вказати імʼя користувача та пароль тут:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Примітка:** Репозиторій не буде додано, якщо він не містить дійсний файл `index.yaml`.\n\n**Примітка:** Якщо ваш репозиторій helm, наприклад, використовує самопідписний сертифікат, ви можете використовувати `helm repo add --insecure-skip-tls-verify ...`, щоб пропустити перевірку CA.\n\nПісля цього ваші користувачі зможуть шукати серед ваших чартів. Після того, як ви оновите репозиторій, вони можуть використовувати команду `helm repo update`, щоб отримати найновішу інформацію про чарт.\n\n_Під капотом команди `helm repo add` і `helm repo update` завантажують файл index.yaml і зберігають його в теці `$XDG_CACHE_HOME/helm/repository/cache/`. Саме тут функція `helm search` знаходить інформацію про чарти._\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: Тести чартів\ndescription: Опис того, як запускати та тестувати ваші чарти.\nsidebar_position: 3\n---\n\nЧарт містить ряд ресурсів та компонентів Kubernetes, які працюють разом. Як автор чарту, ви можете захотіти написати деякі тести, щоб перевірити, чи ваш чарт працює відповідно до очікувань після його встановлення. Ці тести також допомагають споживачеві чарту зрозуміти, що саме повинен робити ваш чарт.\n\n**Тест** у Helm чарті розміщується в теці `templates/` і є визначенням Job, яке вказує контейнер з певною командою для виконання. Контейнер повинен успішно завершити роботу (exit 0), щоб тест вважався успішним. Визначення Job повинно містити анотацію хука Helm: `helm.sh/hook: test`.\n\nЗверніть увагу, що до Helm v3, визначення Job повинно було містити одну з цих анотацій хука Helm: `helm.sh/hook: test-success` або `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` все ще приймається як зворотно сумісна альтернатива `helm.sh/hook: test`.\n\nПриклади тестів:\n\n- Перевірте, що ваша конфігурація з файлу values.yaml була правильно вбудована.\n  - Переконайтеся, що ваше імʼя користувача та пароль працюють правильно.\n  - Переконайтеся, що неправильне імʼя користувача та пароль не працюють.\n- Перевірте, що ваші сервіси працюють та правильно здійснюють балансування навантаження.\n- тощо.\n\nВи можете запустити заздалегідь визначені тести у Helm для релізу за допомогою команди `helm test <RELEASE_NAME>`. Для споживача чарту це чудовий спосіб перевірити, чи їх реліз чарту (або програми) працює відповідно до очікувань.\n\n## Приклад тесту {#example-test}\n\nКоманда [helm create](/helm/helm_create.md) автоматично створює кілька тек і файлів. Щоб спробувати функціональність тестів Helm, спочатку створіть демонстраційний Helm чарт.\n\n```console\n$ helm create demo\n```\n\nТепер ви побачите таку структуру у вашому демонстраційному Helm чарті.\n\n```none\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nУ `demo/templates/tests/test-connection.yaml` ви побачите тест, який ви можете спробувати. Ось визначення Pod для тесту:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n```\n\n## Кроки для запуску тестового набору на релізі\n\nПо-перше, встановіть чарт у ваш кластер, щоб створити реліз. Можливо, вам доведеться почекати, поки всі podʼи стануть активними; якщо ви запустите тест одразу після цього встановлення, це може показати транзитивну помилку, і вам доведеться повторити тестування.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Примітки {#notes}\n\n- Ви можете визначити стільки тестів, скільки бажаєте, в одному yaml файлі або розподілити їх по кількох yaml файлах у теці `templates/`.\n- Ви можете організувати ваші тести у теці `tests/`, наприклад, `<chart-name>/templates/tests/` для більшої ізоляції.\n- Тест є [Helm хуком](/topics/charts_hooks.md), тому анотації, такі як `helm.sh/hook-weight` і `helm.sh/hook-delete-policy`, можуть використовуватися з ресурсами тестів.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: Чарти\ndescription: Пояснює формат чартів та надає основні рекомендації щодо створення чартів з використанням Helm.\nsidebar_position: 1\n---\n\nHelm використовує формат пакування, який називається _чарти_. Чарт — це набір файлів, які описують повʼязаний набір ресурсів Kubernetes. Один чарт може бути використаний для розгортання чогось простого, як, наприклад, pod з memcached, або чогось складного, як повний вебстек з HTTP серверами, базами даних, кешами й так далі.\n\nЧарти створюються як файли, розташовані в певній структурі тек. Вони можуть бути упаковані у версійні архіви для розгортання.\n\nЯкщо ви хочете завантажити та переглянути файли опублікованого чарту без його встановлення, ви можете зробити це за допомогою команди `helm pull chartrepo/chartname`.\n\nЦей документ пояснює формат чарту та надає основні рекомендації щодо створення чартів з використанням Helm.\n\n## Структура файлів чарту {#chart-file-structure}\n\nЧарт організовано як набір файлів всередині теки. Назва теки відповідає назві чарту (без інформації про версію). Наприклад, чарт, який описує WordPress, буде зберігатися в теці `wordpress/`.\n\nВсередині цієї теки Helm очікує структуру, яка відповідає наступному:\n\n```text\nwordpress/\n  Chart.yaml          # YAML файл, що містить інформацію про чарт\n  LICENSE             # НЕОБОВʼЯЗКОВО: Текстовий файл, що містить ліцензію для чарту\n  README.md           # НЕОБОВʼЯЗКОВО: Файл README\n  values.yaml         # Файл стандартної конфігурації для цього чарту\n  values.schema.json  # НЕОБОВʼЯЗКОВО: JSON-схема для накладання структури на файл values.yaml\n  charts/             # Тека, що містить чарти, від яких залежить цей чарт.\n  crds/               # Custom Resource Definitions\n  templates/          # Тека шаблонів, які в поєднанні з values\n                      # генерують валідні файли маніфестів Kubernetes.\n  templates/NOTES.txt # НЕОБОВʼЯЗКОВО: Текстовий файл з короткими інструкціями\n```\n\nHelm резервує використання тек `charts/`, `crds/` і `templates/`, а також перелічених назв файлів. Інші файли буде залишено без змін.\n\n## Файл Chart.yaml {#the-chart-yaml-file}\n\nФайл `Chart.yaml` є обовʼязковим для чарту. Він містить наступні поля:\n\n```yaml\napiVersion: Версія API чарту (обовʼязкове)\nname: Назва чарту (обовʼязкове)\nversion: Версія SemVer 2 (обовʼязкове)\nkubeVersion: Діапазон сумісних версій Kubernetes (необовʼязкове)\ndescription: Короткий опис цього проєкту (необовʼязкове)\ntype: Тип чарту (необовʼязкове)\nkeywords:\n  - Список ключових слів про цей проєкт (необовʼязкове)\nhome: URL головної сторінки проєкту (необовʼязкове)\nsources:\n  - Список URL-адрес з вихідним кодом проєкту (необовʼязкове)\ndependencies: # Список залежностей чарту (необовʼязкове)\n  - name: Назва чарту (nginx)\n    version: Версія чарту (\"1.2.3\")\n    repository: (необовʼязкове) URL репозиторію (\"https://example.com/charts\") або псевдонім (\"@repo-name\")\n    condition: (необовʼязкове) YAML шлях, який відповідає за логічне значення, використовується для увімкнення/вимкнення чартів (наприклад, subchart1.enabled )\n    tags: # (необовʼязкове)\n      - Теґи можуть бути використані для групування чартів для одночасного увімкнення/вимкнення\n    import-values: # (необовʼязкове)\n      - ImportValues містить зіставлення вихідних значень з ключем батьківського елемента для імпорту. Кожен елемент може бути рядком або парою дочірніх/батьківських субсписків.\n    alias: (необовʼязкове) Псевдонім для чарту. Корисно, коли вам потрібно додати той самий чарт кілька разів\nmaintainers: # (необовʼязкове)\n  - name: Імʼя мейнтейнера (обовʼязкове для кожного мейнтейнера)\n    email: Електронна пошта мейнтейнера (необовʼязкове для кожного мейнтейнера)\n    url: URL для мейнтейнера (необовʼязкове для кожного мейнтейнера)\nicon: URL до SVG або PNG зображення для використання як іконки (необовʼязкове).\nappVersion: Версія програми, яку містить цей чарт (необовʼязкове). Не обовʼязково має бути SemVer. Рекомендується використовувати лапки.\ndeprecated: Чи цей чарт застарілий (необовʼязкове, булеве значення)\nannotations:\n  example: Список анотацій, згрупованих за іменами (необовʼязкове).\n```\n\nПочинаючи з [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), додаткові поля не дозволені. Рекомендований підхід — додавати власні метадані в `annotations`.\n\n### Чарти та версіювання {#charts-and-versioning}\n\nКожен чарт повинен мати номер версії. Версія повинна відповідати стандарту [SemVer 2](https://semver.org/spec/v2.0.0.html). На відміну від Helm Classic, Helm версії 2 та новіші використовують номери версій як маркери випуску. Пакети в репозиторіях ідентифікуються за назвою та версією.\n\nНаприклад, чарт `nginx`, у якого в полі версії вказано `version: 1.2.3`, буде мати таку назву:\n\n```text\nnginx-1.2.3.tgz\n```\n\nПідтримуються також складніші імена SemVer 2, такі як `version: 1.2.3-alpha.1+ef365`. Але імена, які не відповідають стандарту SemVer, системою не допускаються.\n\n**Примітка:** Якщо Helm Classic та Deployment Manager були тісно повʼязані з GitHub у контексті чартів, то Helm версії 2 та новіші не залежать від GitHub або навіть Git. Відповідно, він не використовує Git SHAs для версіювання.\n\nПоле `version` у файлі `Chart.yaml` використовується багатьма інструментами Helm, включаючи CLI. При генерації пакета, команда `helm package` використовує версію, яку знаходить у `Chart.yaml`, як частину назви пакета. Система припускає, що номер версії в назві пакета чарту збігається з номером версії у `Chart.yaml`. Невідповідність цього припущення викличе помилку.\n\n### Поле `apiVersion` {#the-apiversion-field}\n\nПоле `apiVersion` має бути `v2` для чартів Helm, які вимагають Helm версії 3 або новішої. Чарти, які підтримують попередні версії Helm, мають `apiVersion`, встановлену на `v1`, і все ще можуть бути встановлені за допомогою Helm 3.\n\nЗміни з `v1` на `v2`:\n\n- Поле `dependencies`, що визначає залежності чарту, яке в чартах `v1` знаходилося в окремому файлі `requirements.yaml` (див. [Залежності чарту](#chart-dependencies)).\n- Поле `type`, що дозволяє відрізняти чарт-застосунок від бібліотеки (див. [Типи чартів](#chart-types)).\n\n### Поле `appVersion` {#the-appversion-field}\n\nЗверніть увагу, що поле `appVersion` не повʼязане з полем `version`. Це спосіб вказати версію застосунку. Наприклад, чарт `drupal` може мати `appVersion: \"8.2.1\"`, що вказує на версію Drupal, включену в чарт (стандартно), і це буде версія `8.2.1`. Це поле є інформаційним і не впливає на розрахунки версії чарту. Наполегливо рекомендується використовувати лапки навколо значення версії. Це змушує YAML-парсер сприймати номер версії як рядок. Якщо залишити його без лапок, це може призвести до проблем із парсингом у деяких випадках. Наприклад, YAML інтерпретує `1.0` як число з плаваючою точкою, а git-коміт SHA, як `1234e10`, як наукову нотацію.\n\nЗ версії Helm v3.5.0 команда `helm create` автоматично обгортає поле `appVersion` у лапки.\n\n### Поле `kubeVersion` {#the-kubeversion-field}\n\nНеобовʼязкове поле `kubeVersion` може визначати обмеження версій semver для підтримуваної версії Kubernetes. Helm перевірить обмеження версії під час встановлення чарту та відхилить дію, якщо кластер працює на непідтримуваній версії Kubernetes.\n\nОбмеження версій можуть складатися з розділених пробілами AND-порівнянь, таких як:\n\n```yaml\n>= 1.13.0 < 1.15.0\n```\n\nякі можуть бути обʼєднані за допомогою оператора OR `||`, як у наступному прикладі:\n\n```yaml\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\n\nУ цьому прикладі версія `1.14.0` виключена, що може мати сенс, якщо відомо про помилку в певних версіях, яка не дозволяє чарту працювати правильно.\n\nОкрім обмежень версій з використанням операторів `=` `!=` `>` `<` `>=` `<=`, підтримуються такі скорочені нотації:\n\n- діапазони для закритих інтервалів, де `1.1 - 2.3.4` еквівалентно `>= 1.1 <= 2.3.4`.\n- підстановки `x`, `X` і `*`, де `1.2.x` еквівалентно `>= 1.2.0 < 1.3.0`.\n- діапазони з тильдою (допускаються зміни патч-версії), де `~1.2.3` еквівалентно `>= 1.2.3 < 1.3.0`.\n- діапазони з `^` (допускаються зміни мінорної версії), де `^1.2.3` еквівалентно `>= 1.2.3 < 2.0.0`.\n\nДля детального пояснення підтримуваних обмежень версій semver див. [Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Застарівання чартів {#deprecating-charts}\n\nПід час керування чартами в репозиторії чартів іноді виникає необхідність зняти чарт з підтримки, визнати його застарілим (deprecated). Для цього можна використовувати необовʼязкове поле `deprecated` у файлі `Chart.yaml`. Якщо **остання** версія чарту в репозиторії позначена як знята з підтримки, тоді весь чарт вважається застарілим. Назву чарту можна пізніше використовувати повторно, опублікувавши нову версію, яка не позначена як знята з підтримки. Процедура зняття чартів з підтримки включає такі кроки:\n\n1. Оновіть файл `Chart.yaml` чарту, позначивши його як знятий з підтримки, і збільште номер версії.\n2. Опублікуйте нову версію чарту в репозиторії чартів.\n3. Видаліть чарт із репозиторію коду (наприклад, з git).\n\n### Типи чартів {#chart-types}\n\nПоле `type` визначає тип чарту. Є два типи: `application` та `library`. Стандартний тип — `application`, і це стандартний чарт, з яким можна повністю працювати. [Чарт-бібліотека](/topics/library_charts.md) надає утиліти або функції для розробників чарту. Чарт-бібліотека відрізняється від чарту-застосунку тим, що він не встановлюється і зазвичай не містить жодних обʼєктів ресурсу.\n\n**Примітка:** Чарт-застосунок можна використовувати як чарт-бібліотеку. Це активується шляхом встановлення типу `library`. Чарт тоді буде оброблятися як чарт-бібліотека, де всі утиліти та функції можуть бути використані. Усі обʼєкти ресурсів чарту не будуть оброблені.\n\n## Ліцензії, README та ПРИМІТКИ до чарту {#chart-license-readme-and-notes}\n\nЧарти також можуть містити файли, які описують встановлення, конфігурацію, використання та ліцензію чарту.\n\nФайл LICENSE є простим текстовим файлом, який містить [ліцензію](https://en.wikipedia.org/wiki/Software_license) для чарту. Чарт може містити ліцензію, оскільки він може містити програмну логіку в шаблонах і, отже, не буде лише конфігураційним. Також можуть бути окремі ліцензії для застосунку, який встановлюється чартом, якщо це необхідно.\n\nREADME для чарту повинен бути відформатований у Markdown (README.md) і, як правило, містити:\n\n- Опис застосунку або служби, яку надає чарт\n- Будь-які передумови або вимоги для запуску чарту\n- Опис опцій у `values.yaml` та стандартні значення\n- Будь-яку іншу інформацію, яка може бути релевантною для встановлення або конфігурації чарту\n\nКоли хаби та інші інтерфейси користувача відображають деталі про чарт, ці дані витягуються з вмісту файлу `README.md`.\n\nЧарт також може містити короткий текстовий файл `templates/NOTES.txt`, який буде надрукований після встановлення і під час перегляду статусу релізу. Цей файл обробляється як [шаблон](#templates-and-values) і може використовуватися для відображення заміток щодо використання, наступних кроків або будь-якої іншої інформації, яка стосується релізу чарту. Наприклад, можна надати інструкції щодо підключення до бази даних або доступу до вебінтерфейсу. Оскільки цей файл друкується в STDOUT під час виконання команд `helm install` або `helm status`, рекомендується зберігати вміст коротким та вказувати на README для детальнішої інформації.\n\n## Залежності чартів {#chart-dependencies}\n\nУ Helm один чарт може залежати від будь-якої кількості інших чартів. Ці залежності можна динамічно звʼязувати за допомогою поля `dependencies` у файлі `Chart.yaml` або вручну керувати ними в теці `charts/`.\n\n### Керування залежностями за допомогою поля `dependencies` {#managing-dependencies-with-the-dependencies-field}\n\nЧарти, від яких залежить поточний чарт, визначаються як список у полі `dependencies`.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- Поле `name` містить імʼя потрібного чарту.\n- Поле `version` містить версію потрібного чарту.\n- Поле `repository` містить повну URL-адресу репозиторію чартів. Зверніть увагу, що ви також повинні використовувати команду `helm repo add`, щоб додати цей репозиторій локально.\n- Ви можете використовувати імʼя репозиторію замість URL-адреси.\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nПісля того як ви визначили залежності, ви можете виконати команду `helm dependency update`, і вона використає ваш файл залежностей для завантаження всіх вказаних чартів у вашу теку `charts/`.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nКоли `helm dependency update` отримує чарти, вона зберігає їх як архіви чартів у теці `charts/`. Тому в наведеному вище прикладі очікується, що в теці charts будуть такі файли:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Поле `alias` у залежностях {#alias-field-in-dependencies}\n\nКрім інших полів, кожен запис у вимогах може містити необовʼязкове поле `alias`.\n\nДодавання псевдоніма для чарту-залежності дозволяє додати чарт у залежності, використовуючи псевдонім як назву нової залежності.\n\nПсевдонім може бути корисним, коли вам потрібно отримати доступ до чарту під іншим імʼям (іменами).\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nУ наведеному вище прикладі для `parentchart` буде три залежності:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nРучний спосіб досягнення цього — копіювання/вставка одного й того ж чарту в теку `charts/` кілька разів під різними іменами.\n\n#### Поля `tags` та `condition` у залежностях {#tags-and-condition-fields-in-dependencies}\n\nКрім інших полів, кожен запис у вимогах може містити необовʼязкові поля `tags` та `condition`.\n\nВсі чарти будуть стандартно завантажені. Якщо присутні поля `tags` або `condition`, вони будуть оцінені та використані для керування завантаженням чартів, до яких вони застосовуються.\n\n**Condition** — поле condition містить один або кілька шляхів YAML (розділених комами). Якщо цей шлях існує у значеннях основного чарту та оцінюється як булеве значення, чарт буде включений або виключений залежно від цього булевого значення. Оцінюється лише перший дійсний шлях у списку, і якщо шляхи не існують, то condition не має жодного ефекту.\n\n**Tags** — поле tags є списком міток YAML, повʼязаних із цим чартом. У значеннях основного чарту всі чарти з мітками можуть бути включені або виключені шляхом вказання мітки та булевого значення.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nУ наведеному вище прикладі всі чарти з міткою `front-end` будуть вимкнені, але оскільки шлях `subchart1.enabled` у значеннях основного чарту має значення `true`, умова переважає мітку `front-end`, і `subchart1` буде включений.\n\nОскільки `subchart2` має мітку `back-end`, і ця мітка має значення `true`, `subchart2` буде включений. Також зверніть увагу, що хоча `subchart2` має зазначену умову, у значеннях основного чарту немає відповідного шляху та значення, тому ця умова не має ефекту.\n\n##### Використання CLI з Tags та Conditions {#using-the-cli-with-tags-and-conditions}\n\nПараметр `--set` можна використовувати як зазвичай для зміни значень міток та умов.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Опрацювання Tags та Conditions {#tags-and-conditions-resolution}\n\n- **Умови (коли вони встановлені в значеннях) завжди переважають мітки.** Перемагає перший існуючий шлях умови, а наступні для цього чарту ігноруються.\n- Мітки оцінюються так: \"якщо будь-яка з міток чарту має значення true, тоді увімкніть чарт\".\n- Значення міток та умов повинні бути встановлені у значеннях основного чарту.\n- Ключ `tags:` у значеннях має бути ключем верхнього рівня. Глобальні та вкладені таблиці `tags:` наразі не підтримуються.\n\n#### Імпорт значень дочірніх чартів через залежності {#importing-values-from-child-charts-via-dependencies}\n\nУ деяких випадках корисно, щоб значення дочірнього чарту передавалися до батьківського чарту та використовувалися як стандартні загальні значення. Додаткова перевага використання формату `exports` полягає в тому, що це дозволяє майбутнім інструментам інспектувати значення, які може налаштувати користувач.\n\nКлючі, що містять значення для імпорту, можуть бути вказані у полі `dependencies` батьківського чарту в полі `import-values`, використовуючи список YAML. Кожен елемент у списку — це ключ, який імпортується з поля `exports` дочірнього чарту.\n\nДля імпорту значень, які не містяться в ключі `exports`, використовуйте [формат child-parent](#using-the-child-parent-format). Приклади обох форматів описані нижче.\n\n##### Використання формату `exports` {#using-the-exports-format}\n\nЯкщо файл `values.yaml` дочірнього чарту містить поле `exports` на рівні кореня, його вміст може бути імпортований безпосередньо у значення батьківського чарту, через вказання ключів для імпорту, як у прикладі нижче:\n\n```yaml\n# файл Chart.yaml батьківського чарту\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# файл values.yaml дочірнього чарту\n\nexports:\n  data:\n    myint: 99\n```\n\nОскільки ми вказуємо ключ `data` у нашому списку імпорту, Helm шукає цей ключ у полі `exports` дочірнього чарту та імпортує його вміст.\n\nФінальні значення батьківського чарту міститимуть наше експортоване поле:\n\n```yaml\n# значення батьківського чарту\n\nmyint: 99\n```\n\nЗверніть увагу, що ключ `data` не міститься у фінальних значеннях батьківського чарту. Якщо вам потрібно вказати ключ батьківського чарту, використовуйте формат \"child-parent\".\n\n##### Використання формату `child-parent` {#using-the-child-parent-format}\n\nЩоб отримати доступ до значень, які не містяться у ключі `exports` значень дочірнього чарту, вам потрібно вказати шлях до джерела значень для імпорту (`child`) та шлях до місця призначення у значеннях батьківського чарту (`parent`).\n\nУ прикладі нижче `import-values` інструктує Helm взяти будь-які значення, знайдені в шляху `child:`, та скопіювати їх у значення батьківського чарту в шлях, вказаний у `parent:`.\n\n```yaml\n# файл Chart.yaml батьківського чарту\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nУ наведеному вище прикладі значення, знайдені у шляху `default.data` у значеннях subchart1, будуть імпортовані до ключа `myimports` у значеннях батьківського чарту, як показано нижче:\n\n```yaml\n# файл values.yaml батьківського чарту\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# файл values.yaml subchart1\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nФінальні значення батьківського чарту будуть такими:\n\n```yaml\n# фінальні значення батьківського чарту\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nФінальні значення батьківського чарту тепер містять поля `myint` та `mybool`, імпортовані з subchart1.\n\n### Керування залежностями вручну через теку `charts/` {#managing-dependencies-manually-via-the-charts-directory}\n\nЯкщо потрібен більший контроль над залежностями, їх можна визначити явно, скопіювавши залежні чарти в теку `charts/`.\n\nЗалежність повинна бути розпакованою текою чарту, але її імʼя не може починатися з `_` або `.`. Такі файли ігноруються завантажувачем чартів.\n\nНаприклад, якщо чарт WordPress залежить від чарту Apache, то чарт Apache (відповідної версії) розміщується в теці `charts/` чарту WordPress:\n\n```yaml\nwordpress/\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nНаведений вище приклад показує, як чарт WordPress виражає свою залежність від Apache та MySQL, включаючи ці чарти всередині своєї текиу `charts/`.\n\n**ПОРАДА:** _Щоб завантажити залежність у вашу теку `charts/`, використовуйте команду `helm pull`._\n\n### Операційні аспекти використання залежностей {#operational-aspects-of-using-dependencies}\n\nПопередні розділи пояснюють, як визначати залежності чартів, але як це впливає на встановлення чарту за допомогою `helm install` і `helm upgrade`?\n\nПрипустимо, що чарт з назвою \"A\" створює такі обʼєкти Kubernetes:\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nКрім того, A залежить від чарту B, який створює обʼєкти:\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nПісля встановлення/оновлення чарту A створюється або змінюється єдиний реліз Helm. Цей реліз створить або оновить усі вищевказані обʼєкти Kubernetes у такому порядку:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nЦе відбувається тому, що під час встановлення/оновлення чартів Helm агрегує обʼєкти Kubernetes з чарту та всіх його залежностей в єдиний набір, який потім сортується за типом, а потім за іменем, і створюється або оновлюється в такому порядку.\n\nТаким чином, створюється єдиний реліз, який містить усі обʼєкти для чарту та його залежностей.\n\nПорядок встановлення типів Kubernetes визначається переліком InstallOrder у файлі kind_sorter.go (див. [вихідний файл Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n### Шаблони та Значення {#templates-and-values}\n\nШаблони Helm Chart написані на [Go template](https://golang.org/pkg/text/template/), з додатковими функціями з бібліотеки [Sprig](https://github.com/Masterminds/sprig) та кількома іншими [спеціалізованими функціями](/howto/charts_tips_and_tricks.md).\n\nВсі файли шаблонів зберігаються у теці `templates/` чарту. Коли Helm обробляє чарти, він пропускає кожен файл у цій теці через механізм шаблонів.\n\nЗначення для шаблонів надаються двома способами:\n\n- Розробники чартів можуть надати файл з назвою `values.yaml` всередині чарту. Цей файл може містити стандартні значення.\n- Користувачі чартів можуть надати YAML файл, який містить значення. Це можна зробити за допомогою команди `helm install`.\n\nКоли користувач надає власні значення, ці значення перезаписують значення у файлі `values.yaml` чарту.\n\n### Файли шаблонів {#template-files}\n\nФайли шаблонів дотримуються стандартних конвенцій написання Go шаблонів (див. [документацію пакету text/template Go](https://golang.org/pkg/text/template/) для деталей). Приклад файлу шаблону може виглядати так:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nВищенаведений приклад, заснований на [https://github.com/deis/charts](https://github.com/deis/charts), є шаблоном для контролера реплікацій Kubernetes. Він може використовувати наступні чотири значення шаблону (зазвичай визначені у файлі `values.yaml`):\n\n- `imageRegistry`: Джерело реєстру для Docker образу.\n- `dockerTag`: Теґ для образу Docker.\n- `pullPolicy`: Політика отримання образу Docker в Kubernetes.\n- `storage`: Сховище, стандартне значення для якого є `\"minio\"`\n\nВсі ці значення визначені автором шаблону. Helm не вимагає або не диктує параметри.\n\nЩоб побачити багато робочих чартів, перегляньте CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0).\n\n### Попередньо визначені значення {#predefined-values}\n\nЗначення, які постачаються через файл `values.yaml` (або за допомогою прапорця `--set`), доступні з обʼєкта `.Values` у шаблоні. Але є й інші попередньо визначені дані, які можна використовувати у ваших шаблонах.\n\nНаступні значення є попередньо визначеними, доступні кожному шаблону і не можуть бути перевизначені. Як і всі значення, імена є _чутливими до регістру_:\n\n- `Release.Name`: Назва релізу (не чарту)\n- `Release.Namespace`: Простір імен, в який був розгорнутий чарт.\n- `Release.Service`: Сервіс, який здійснив реліз.\n- `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом.\n- `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням.\n- `Chart`: Зміст `Chart.yaml`. Таким чином, версію чарту можна отримати як `Chart.Version`, а авторів — з `Chart.Maintainers`.\n- `Files`: Обʼєкт, схожий на map, який містить всі неспеціальні файли в чарті. Це не дає вам доступ до шаблонів, але надає доступ до додаткових файлів, які присутні (якщо вони не виключені за допомогою `.helmignore`). До файлів можна отримати доступ, використовуючи `{{ index .Files \"file.name\" }}` або функцію `{{.Files.Get name }}`. Також можна отримати вміст файлу як `[]byte`, використовуючи `{{ .Files.GetBytes }}`\n- `Capabilities`: Обʼєкт, схожий на map, який містить інформацію про версії Kubernetes (`{{ .Capabilities.KubeVersion }}`) та підтримувані версії API Kubernetes (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n**ПРИМІТКА:** Будь-які невідомі поля `Chart.yaml` будуть відкинуті. Вони не будуть доступні всередині обʼєкта `Chart`. Таким чином, `Chart.yaml` не можна використовувати для передачі довільно структурованих даних у шаблон. Проте для цього можна використовувати файл значень.\n\n### Файли значень {#values-files}\n\nБеручи до уваги шаблон у попередньому розділі, файл `values.yaml`, який постачає необхідні значення, виглядатиме так:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nФайл значень має формат YAML. Чарт може містити файл стандартних значень `values.yaml`. Команда Helm install дозволяє користувачеві перевизначити значення, надавши додаткові YAML значення:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nКоли значення передаються таким чином, вони зливаються з файлом стандартних значень. Наприклад, розглянемо файл `myvals.yaml`, який виглядає так:\n\n```yaml\nstorage: \"gcs\"\n```\n\nПри злитті з `values.yaml` у чарті, результат буде:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nЗверніть увагу, що тільки останнє поле було перевизначене.\n\n**ПРИМІТКА:** Файл стандартних значень, що включений всередині чарту, _повинен_ називатися `values.yaml`. Але файли, вказані в командному рядку, можуть мати будь-яке імʼя.\n\n**ПРИМІТКА:** Якщо прапорець `--set` використовується з `helm install` або `helm upgrade`, ці значення просто перетворюються в YAML на клієнтському боці.\n\n**ПРИМІТКА:** Якщо будь-які необхідні записи у файлі значень існують, їх можна оголосити як обовʼязкові в шаблоні чарту, використовуючи функцію [ʼrequiredʼ](/howto/charts_tips_and_tricks.md).\n\nБудь-які з цих значень доступні всередині шаблонів, використовуючи обʼєкт `.Values`:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Область видимості, залежності та значення {#scope-dependencies-and-values}\n\nФайли значень можуть оголошувати значення як для верхнього рівня чарту, так і для будь-яких чартів, які включені у теку `charts/` цього чарту. Інакше кажучи, файл значень може надавати значення чарту та його залежностям. Наприклад, чарт WordPress, що демонструється вище, має як `mysql`, так і `apache` як залежності. Файл значень може надавати значення всім цим компонентам:\n\n```yaml\ntitle: \"My WordPress Site\" # Надсилається до шаблону WordPress\n\nmysql:\n  max_connections: 100 # Надсилається до MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Передається Apache\n```\n\nЧарти вищого рівня мають доступ до всіх змінних, визначених нижче. Отже, чарт WordPress може отримати пароль MySQL як `.Values.mysql.password`. Але чарт нижчого рівня не може отримати доступ до елементів в батьківських чартах, тому MySQL не зможе отримати доступ до властивості `title`. Так само він не може отримати доступ до `apache.port`.\n\nЗначення обмежені просторами імен, але префікси просторів імен обрізаються. Тобто для чарту WordPress, він може отримати доступ до поля пароля MySQL як `.Values.mysql.password`. Але для чарту MySQL область значень зменшена і префікс простору видалено, тому він буде бачити поле пароля просто як `.Values.password`.\n\n#### Глобальні значення {#global-values}\n\nЗ версії 2.0.0-Alpha.2, Helm підтримує спеціальне \"глобальне\" значення. Розгляньте цю змінену версію попереднього прикладу:\n\n```yaml\ntitle: \"My WordPress Site\" # Надсилається до шаблону WordPress\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Надсилається до MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Передається Apache\n```\n\nВищенаведене додає розділ `global` зі значенням `app: MyWordPress`. Це значення доступне _всім_ чартам як `.Values.global.app`.\n\nНаприклад, шаблони `mysql` можуть отримати доступ до `app` як `{{ .Values.global.app }}`, так само і чарт `apache`. Фактично, файл значень вище перегенерується таким чином:\n\n```yaml\ntitle: \"My WordPress Site\" # Надсилається до шаблону WordPress\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Надсилається до MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Передається Apache\n```\n\nЦе забезпечує спосіб поділитися однією змінною верхнього рівня з усіма субчартами, що корисно для таких речей, як встановлення властивостей `metadata`, наприклад, міток.\n\nЯкщо субчарт оголошує глобальну змінну, ця глобальна змінна буде передана _далі вниз_ (в субчарти субчартів), але не _вгору_ до батьківського чарту. Немає способу, щоб субдчарт впливав на значення батьківського чарту.\n\nТакож, глобальні змінні батьківських чартів мають перевагу над глобальними змінними з субчартів.\n\n### Файли схем {#schema-files}\n\nІноді розробник чарту може захотіти визначити структуру для своїх значень. Це можна зробити, визначивши схему у файлі `values.schema.json`. Схема представляється як [JSON Schema](https://json-schema.org/). Вона може виглядати приблизно так:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nЦя схема буде застосовуватися до значень для їх перевірки. Перевірка відбувається при виконанні будь-якої з наступних команд:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nПриклад файлу `values.yaml`, який відповідає вимогам цієї схеми, може виглядати так:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nЗверніть увагу, що схема застосовується до фінального обʼєкта `.Values`, а не тільки до файлу `values.yaml`. Це означає, що наступний `yaml` файл є дійсним, за умови що чарт встановлюється з відповідним параметром `--set`, як показано нижче:\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nКрім того, фінальний обʼєкт `.Values` перевіряється на відповідність _усім_ схемам субчартів. Це означає, що обмеження на субчарт не можуть бути обійдені батьківським чартом. Це також працює в зворотному напрямку — якщо субчарт має вимогу, яка не виконується у файлі `values.yaml` субчарту, батьківський чарт _повинен_ задовольняти ці вимоги, щоб бути дійсним.\n\n### Посилання {#references}\n\nПри написанні шаблонів, файлів значень і схем є кілька стандартних посилань, які можуть бути корисними:\n\n- [Go шаблони](https://godoc.org/text/template)\n- [Додаткові функції шаблонів](https://godoc.org/github.com/Masterminds/sprig)\n- [Формат YAML](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRD) {#custom-resource-definitions-crd}\n\nKubernetes надає механізм для оголошення нових типів обʼєктів Kubernetes. Використовуючи CustomResourceDefinitions (CRD), розробники Kubernetes можуть оголошувати власні типи ресурсів.\n\nУ Helm 3, CRD розглядаються як особливий вид обʼєктів. Вони встановлюються перед рештою чарту і мають певні обмеження.\n\nФайли CRD YAML повинні бути поміщені в теку `crds/` всередині чарту. Можна помістити кілька CRD (розділених маркерами початку та кінця YAML) в один файл. Helm спробує завантажити _всі_ файли в теці CRD в Kubernetes.\n\nФайли CRD _не можуть бути шаблонізовані_. Вони повинні бути звичайними YAML документами.\n\nКоли Helm встановлює новий чарт, він завантажує CRD, призупиняється, поки CRD не будуть доступні через API сервер, а потім запускає механізм шаблонів, рендерить решту чарту та завантажує її в Kubernetes. Завдяки цьому CRD інформація доступна в обʼєкті `.Capabilities` в шаблонах Helm, і шаблони Helm можуть створювати нові екземпляри обʼєктів, які були оголошені в CRD.\n\nНаприклад, якщо у вашому чарті є CRD для `CronTab` в теці `crds/`, ви можете створити екземпляри типу `CronTab` в теці `templates/`:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nФайл `crontab.yaml` повинен містити CRD без директив шаблона:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nТоді шаблон `mycrontab.yaml` може створити новий `CronTab` (використовуючи шаблони як звичайно):\n\n```yaml\napiVersion: stable.example.com/v1\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm забезпечить, що тип обʼєкта `CronTab` був встановлений і доступний з API сервера Kubernetes, перш ніж продовжити встановлення обʼєктів в `templates/`.\n\n### Обмеження на CRD {#limitations-on-crds}\n\nНа відміну від більшості обʼєктів у Kubernetes, CRD (Custom Resource Definitions) встановлюються глобально. Тому Helm вживає дуже обережний підхід до управління CRD. CRD підлягають таким обмеженням:\n\n- CRD ніколи не перевстановлюються. Якщо Helm визначає, що CRD у теці `crds/` вже присутні (незалежно від версії), Helm не намагатиметься їх встановити чи оновити.\n- CRD ніколи не встановлюються під час оновлення або відкату. Helm створює CRD тільки під час операцій встановлення.\n- CRD ніколи не видаляються. Видалення CRD автоматично видаляє весь вміст CRD у всіх просторах імен у кластері. Тому Helm не видалятиме CRD.\n\nОператорам, які хочуть оновити або видалити CRD, рекомендується робити це вручну і з великою обережністю.\n\n## Використання Helm для управління чартами {#using-helm-to-manage-charts}\n\nІнструмент `helm` має кілька команд для роботи з чартами.\n\nВін може створити новий чарт для вас:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nПісля редагування чарта, `helm` може упакувати його в архів чартів для вас:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nВи також можете використовувати `helm`, щоб знайти проблеми з форматуванням або інформацією вашого чарта:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Репозиторії чартів {#chart-repositories}\n\nРепозиторій чартів — це HTTP-сервер, який містить один або більше упакованих чартів. Хоча `helm` можна використовувати для управління локальними теками чартів, для обміну чартами переважно використовують репозиторій чартів.\n\nБудь-який HTTP-сервер, який може надавати YAML файли та tar файли та може відповідати на GET запити, можна використовувати як сервер репозиторіїв. Команда Helm тестувала деякі сервери, включаючи Google Cloud Storage з увімкненим режимом веб-сайту та S3 з увімкненим режимом веб-сайту.\n\nРепозиторій характеризується наявністю спеціального файлу з назвою `index.yaml`, який містить список всіх пакетів, наданих репозиторієм, разом із метаданими, які дозволяють отримувати та перевіряти ці пакети.\n\nНа стороні клієнта репозиторії управляються командами `helm repo`. Однак Helm не надає інструменти для завантаження чартів на віддалені сервери репозиторіїв. Це повʼязано з тим, що така функціональність вимагала б значних вимог до сервера, що реалізує репозиторій, і підвищувала б барʼєр для налаштування репозиторію.\n\n## Стартер-паки чартів {#chart-starter-packs}\n\nКоманда `helm create` має необовʼязковий параметр `--starter`, який дозволяє вказати \"стартовий чарт\". Також параметр стартера має короткий псевдонім `-p`.\n\nПриклади використання:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nСтартери — це звичайні чарти, але вони розташовані в `$XDG_DATA_HOME/helm/starters`. Як розробник чартів, ви можете створювати чарти, які спеціально призначені для використання як стартери. Такі чарти повинні бути спроєктовані з урахуванням наступних міркувань:\n\n- Файл `Chart.yaml` буде перезаписаний генератором.\n- Користувачі очікують, що зміст такого чарта буде змінений, тому документація повинна вказувати, як користувачі можуть це зробити.\n- Всі входження `<CHARTNAME>` будуть замінені на вказане імʼя чарту, щоб стартові чарти можна було використовувати як шаблони, за винятком деяких змінних файлів. Наприклад, якщо ви використовуєте власні файли в теці `vars` або певні файли `README.md`, `<CHARTNAME>` НЕ буде переважати всередині них. Крім того, опис чарту не успадковується.\n\nНа даний момент єдиний спосіб додати чарт до `$XDG_DATA_HOME/helm/starters` — це вручну скопіювати його туди. У документації вашого чарту ви можете пояснити цей процес.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: Хуки чартів\ndescription: Опис, як працювати з хуками чартів.\nsidebar_position: 2\n---\n\nHelm надає механізм _хуків_, що дозволяє розробникам чартів втручатися на певних етапах життєвого циклу релізу. Наприклад, ви можете використовувати хуки для:\n\n- Завантаження ConfigMap або Secret під час встановлення до завантаження будь-яких інших чартів.\n- Виконання Job для резервного копіювання бази даних перед встановленням нового чарту, а потім виконання другого Job після оновлення для відновлення даних.\n- Запуску Job перед видаленням релізу для мʼякого виведення сервісу з обігу перед його видаленням.\n\nХуки працюють як звичайні шаблони, але мають спеціальні анотації, які змушують Helm використовувати їх по-іншому. У цьому розділі ми розглянемо базовий шаблон використання хуків.\n\n## Доступні хуки {#available-hooks}\n\nОсь які хуки визначені:\n\n| Значення анотації | Опис                                                                                                     |\n| ----------------- | -------------------------------------------------------------------------------------------------------- |\n| `pre-install`     | Виконується після рендерингу шаблонів, але до створення будь-яких ресурсів у Kubernetes                    |\n| `post-install`    | Виконується після завантаження всіх ресурсів у Kubernetes                                                  |\n| `pre-delete`      | Виконується під час запиту на видалення перед видаленням будь-яких ресурсів з Kubernetes                   |\n| `post-delete`     | Виконується під час запиту на видалення після видалення всіх ресурсів релізу                               |\n| `pre-upgrade`     | Виконується під час запиту на оновлення після рендерингу шаблонів, але до оновлення будь-яких ресурсів     |\n| `post-upgrade`    | Виконується під час запиту на оновлення після оновлення всіх ресурсів                                      |\n| `pre-rollback`    | Виконується під час запиту на відкат після рендерингу шаблонів, але до відкату будь-яких ресурсів           |\n| `post-rollback`   | Виконується під час запиту на відкат після модифікації всіх ресурсів                                        |\n| `test`            | Виконується, коли викликано підкоманду Helm test ([переглянути документацію тестів](/topics/chart_tests.md))  |\n\n_Зверніть увагу, що хук `crd-install` був видалений на користь теки `crds/` у Helm 3._\n\n## Хуки та життєвий цикл релізу {#hooks-and-the-release-lifecycle}\n\nХуки дозволяють вам, як розробнику чартів, виконувати операції на стратегічних етапах життєвого циклу релізу. Наприклад, розглянемо життєвий цикл для `helm install`. Стандартно життєвий цикл виглядає так:\n\n1. Користувач виконує `helm install foo`.\n2. Викликається API бібліотеки Helm для встановлення.\n3. Після деякої перевірки бібліотека рендерить шаблони `foo`.\n4. Бібліотека завантажує результуючі ресурси у Kubernetes.\n5. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту.\n6. Клієнт виходить.\n\nHelm визначає два хуки для життєвого циклу `install`: `pre-install` і `post-install`. Якщо розробник чарту `foo` реалізує обидва хуки, життєвий цикл змінюється таким чином:\n\n1. Користувач виконує `helm install foo`.\n2. Викликається API бібліотеки Helm для встановлення.\n3. CRD у теці `crds/` встановлюються.\n4. Після деякої перевірки бібліотека рендерить шаблони `foo`.\n5. Бібліотека готується виконати хуки `pre-install` (завантаження ресурсів хука у Kubernetes).\n6. Бібліотека сортує хуки за вагою (стандартно вага дорівнює 0), за типом ресурсу та нарешті за імʼям за зростанням.\n7. Бібліотека завантажує хук з найменшою вагою спочатку (від негативної до позитивної)\n8. Бібліотека чекає, поки хук стане \"Ready\" (крім CRD)\n9. Бібліотека завантажує результуючі ресурси у Kubernetes. Зверніть увагу, що якщо встановлено прапорець `--wait`, бібліотека чекатиме, поки всі ресурси не стануть готовими, і не запустить хук `post-install`, поки вони не будуть готові.\n10. Бібліотека виконує хук `post-install` (завантаження ресурсів хука).\n11. Бібліотека чекає, поки хук стане \"Ready\".\n12. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту.\n13. Клієнт виходить.\n\nЩо означає чекати, поки хук стане готовим? Це залежить від ресурсу, оголошеного в хуку. Якщо ресурс є типу `Job` або `Pod`, Helm чекатиме, поки він успішно виконається. І якщо хук не вдається, реліз зазнає невдачі. Це _блокуюча операція_, тому клієнт Helm призупиниться, поки Job виконується.\n\nДля всіх інших типів, як тільки Kubernetes позначає ресурс як завантажений (доданий або оновлений), ресурс вважається \"Ready\". Коли оголошено багато ресурсів у хуку, ресурси виконуються послідовно. Якщо у них є ваги хуків (див. нижче), вони виконуються в порядку ваг. Починаючи з Helm 3.2.0, ресурси хуків з однаковою вагою встановлюються в тому ж порядку, що і звичайні не-хукові ресурси. В іншому випадку, порядок не гарантується. (У Helm 2.3.0 і пізніше вони сортуються в алфавітному порядку. Це поведінка не є обовʼязковою і може змінитися в майбутньому.) Вважається гарною практикою додати вагу хуку та встановити її на `0`, якщо вага не є важливою.\n\n### Ресурси хуків не управляються відповідними релізами {#hook-resources-are-not-managed-by-releases}\n\nРесурси, які створює хук, наразі не відстежуються та не управляються як частина релізу. Як тільки Helm перевіряє, що хук досяг свого готового стану, він залишає ресурс хука без змін. Збір сміття ресурсів хуків при видаленні відповідного релізу може бути додано до Helm 3 у майбутньому, тому будь-які ресурси хуків, які ніколи не повинні бути видалені, повинні бути анотовані як `helm.sh/resource-policy: keep`.\n\nПрактично це означає, що якщо ви створюєте ресурси в хуку, ви не можете покладатися на `helm uninstall`, щоб видалити ресурси. Щоб знищити такі ресурси, вам потрібно або [додати власну анотацію `helm.sh/hook-delete-policy`](#hook-deletion-policies) до файлу шаблону хука, або [встановити поле часу життя (TTL) ресурсу Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Написання хуку {#writing-a-hook}\n\nХуки — це просто манифести Kubernetes з особливими анотаціями в секції `metadata`. Оскільки це шаблони, ви можете використовувати всі звичайні можливості шаблонів, включаючи читання `.Values`, `.Release` та `.Template`.\n\nНаприклад, цей шаблон, збережений у `templates/post-install-job.yaml`, оголошує Job, який буде виконаний при `post-install`:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # Це те, що визначає цей ресурс як хук. Без цього рядка\n    # job вважається частиною релізу.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n```\n\nЩо робить цей шаблон хуком, так це анотація:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nОдин ресурс може реалізовувати кілька хуків:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nАналогічно, немає обмежень на кількість різних ресурсів, які можуть реалізувати даний хук. Наприклад, можна оголосити як secret, так і config map як pre-install хук.\n\nКоли субчарти оголошують хуки, вони також оцінюються. Немає способу для основного чарту відключити хуки, оголошені субчартами.\n\nМожливо визначити вагу для хука, що допоможе створити детерміністичний порядок виконання. Ваги визначаються за допомогою наступної анотації:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nВаги хуків можуть бути позитивними або негативними числами, але повинні бути представлені як рядки. Коли Helm починає цикл виконання хуків певного типу, він сортує ці хуки у висхідному порядку.\n\n### Політики видалення хуків {#hook-deletion-policies}\n\nМожливо визначити політики, які визначають, коли видаляти відповідні ресурси хуків. Політики видалення хуків визначаються за допомогою наступної анотації:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nВи можете вибрати одне або кілька визначених значень анотацій:\n\n| Значення анотації       | Опис                                                             |\n| ----------------------- | ---------------------------------------------------------------- |\n| `before-hook-creation` | Видалити попередній ресурс перед запуском нового хуку (стандартно) |\n| `hook-succeeded`       | Видалити ресурс після успішного виконання хука                    |\n| `hook-failed`          | Видалити ресурс, якщо хук зазнав невдачі під час виконання         |\n\nЯкщо анотація політики видалення хука не вказана, стандартно застосовується поведінка `before-hook-creation`.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/index.mdx",
    "content": "---\ntitle: Посібники\nsidebar_position: 3\n---\n\n# Тематичні посібники\n\nТут ви знайдете вступ до всіх ключових частин Helm, які вам знадобляться або які ви хочете знати.\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: Застарілі API Kubernetes\ndescription: Пояснення щодо застарілих API Kubernetes у Helm\nsidebar_position: 14\n---\n\nKubernetes є системою, що керується API, і API еволюціонує з часом, відображаючи зміну розуміння проблемного простору. Це загальноприйнята практика для систем та їх API. Важливою частиною еволюції API є наявність чіткої політики застарівання та процесу, який інформує користувачів про те, як впроваджуються зміни до API. Іншими словами, споживачі вашого API повинні знати заздалегідь, коли та в якій версії API буде видалено або змінено. Це дозволяє уникнути неприємних сюрпризів та руйнівних змін для споживачів.\n\n[Політика застарівання Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) документує, як Kubernetes обробляє зміни версій API. Політика щодо застарівання визначає часові рамки підтримки версій API після оголошення про їх застарівання. Тому важливо бути в курсі оголошень про застарівання та знати, коли версії API будуть видалені, щоб мінімізувати вплив.\n\nПрикладом такого оголошення є [оголошення про видалення застарілих версій API у Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), яке було опубліковано за кілька місяців до релізу. Ці версії API були оголошені застарілими ще раніше. Це свідчить про наявність чіткої політики, яка інформує споживачів про підтримку версій API.\n\nШаблони Helm вказують [групу API Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) при визначенні обʼєкта Kubernetes, аналогічно до маніфесту Kubernetes. Це вказується в полі `apiVersion` шаблону і визначає версію API обʼєкта Kubernetes. Це означає, що користувачі Helm та підтримувачі чартів повинні знати, коли версії API Kubernetes були оголошені застарілими та в якій версії Kubernetes вони будуть видалені.\n\n## Підтримувачі чартів {#chart-maintainers}\n\nВам слід перевіряти свої чарти на наявність версій API Kubernetes, які оголошені застарілими або видаленими у певній версії Kubernetes. Виявлені версії API, які скоро перестануть підтримуватися або вже не підтримуються, слід оновити до підтримуваних версій і випустити нову версію чарту. Версія API визначається полями `kind` і `apiVersion`. Наприклад, ось версія API обʼєкта `Deployment`, яка була видалена в Kubernetes 1.16:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Користувачі Helm {#helm-users}\n\nВам слід перевірити чарти, які ви використовуєте (аналогічно до [підтримувачів чартів](#chart-maintainers)), і визначити будь-які чарти, у яких версії API застарілі або видалені у певній версії Kubernetes. Для виявлених чартів вам потрібно знайти останню версію чарту (яка містить підтримувані версії API) або оновити чарт самостійно.\n\nКрім того, вам також потрібно перевірити будь-які розгорнуті чарти (тобто релізи Helm) на наявність застарілих або видалених версій API. Це можна зробити, отримавши деталі релізу за допомогою команди `helm get manifest`.\n\nМетод оновлення релізу Helm до підтримуваних API залежить від ваших знахідок, як описано нижче:\n\n1. Якщо ви знайшли лише застарілі версії API, то:\n   - Виконайте `helm upgrade` з версією чарту, яка підтримує версії API Kubernetes.\n   - Додайте опис до оновлення, щось на зразок \"не виконувати відкат до версії Helm, що передує цій поточній версії\".\n\n2. Якщо ви знайшли будь-яку версію API, яка була видалена у версії Kubernetes, то:\n   - Якщо ви використовуєте версію Kubernetes, де ці версії API все ще доступні (наприклад, ви використовуєте Kubernetes 1.15 і виявили, що використовуєте API, які будуть видалені у Kubernetes 1.16):\n     - Дотримуйтесь процедури, описаної у пункті 1.\n   - Інакше (наприклад, ви вже використовуєте версію Kubernetes, де деякі версії API, зазначені у `helm get manifest`, більше не доступні):\n     - Вам потрібно відредагувати маніфест релізу, який зберігається в кластері, щоб оновити версії API до підтримуваних. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації.\n\n> Примітка: У всіх випадках оновлення релізу Helm до підтримуваних API ніколи не слід виконувати відкат релізу до версії, яка передує версії релізу з підтримуваними API.\n\n> Рекомендація: Найкраща практика — оновлювати релізи, використовуючи застарілі версії API, до підтримуваних версій API до того, як виконати оновлення кластера Kubernetes, який видаляє ці версії API.\n\nЯкщо ви не оновите реліз, як запропоновано вище, ви отримаєте помилку, схожу на наступну, при спробі оновити реліз у версії Kubernetes, де його версія API була видалена:\n\n```log\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm не вдається виконати оновлення в такому випадку, оскільки він намагається створити патч відмінностей між поточним розгорнутим релізом (який містить версії API Kubernetes, що були видалені в цій версії Kubernetes) та чартом, який ви передаєте з оновленими/підтримуваними версіями API. Основна причина невдачі полягає в тому, що коли Kubernetes видаляє версію API, клієнтська бібліотека Go для Kubernetes більше не може аналізувати застарілі обʼєкти, і тому Helm зазнає невдачі при виклику бібліотеки. На жаль, Helm не в змозі відновитися з такої ситуації та більше не може керувати таким релізом. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації про те, як відновитися з такої ситуації.\n\n## Оновлення версій API маніфесту релізу {#updating-api-versions-of-a-release-manifest}\n\nМаніфест є властивістю обʼєкта релізу Helm, який зберігається в полі `data` в Secret (стандартно) або ConfigMap у кластері. Поле `data` містить обʼєкт у стиснутому вигляді, закодований у base64 (існує додаткове кодування base64 для Secret). Для кожної версії/ревізії релізу існує свій Secret/ConfigMap у просторі імен релізу.\n\nВи можете використовувати втулок Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) для оновлення релізу до підтримуваних API. Ознайомтеся з readme для отримання додаткової інформації.\n\nАльтернативно, ви можете дотримуватися цих ручних кроків для оновлення версій API маніфесту релізу. Залежно від вашої конфігурації, дотримуйтесь кроків для Secret або ConfigMap.\n\n- Отримайте імʼя Secret або ConfigMap, повʼязане з останнім розгорнутим релізом:\n  - Secret: `kubectl get secret -l owner=helm,status=deployed,name=<release_name> --namespace <release_namespace> | awk ʼ{print $1}ʼ | grep -v NAME`\n  - ConfigMap: `kubectl get configmap -l owner=helm,status=deployed,name=<release_name> --namespace <release_namespace> | awk ʼ{print $1}ʼ | grep -v NAME`\n- Отримайте деталі останнього розгорнутого релізу:\n  - Secret: `kubectl get secret <release_secret_name> -n <release_namespace> -o yaml > release.yaml`\n  - ConfigMap: `kubectl get configmap <release_configmap_name> -n <release_namespace> -o yaml > release.yaml`\n- Зробіть резервну копію релізу на випадок, якщо вам знадобиться відновлення у разі помилки:\n  - `cp release.yaml release.bak`\n  - У разі необхідності, відновіть: `kubectl apply -f release.bak -n <release_namespace>`\n- Розкодуйте обʼєкт релізу:\n  - Secret: `cat release.yaml | grep -oP ʼ(?<=release: ).*ʼ | base64 -d | base64 -d | gzip -d > release.data.decoded`\n  - ConfigMap: `cat release.yaml | grep -oP ʼ(?<=release: ).*ʼ | base64 -d | gzip -d > release.data.decoded`\n- Змініть версії API маніфестів. Ви можете використовувати будь-який інструмент (наприклад, редактор) для внесення змін. Це знаходиться у полі `manifest` вашого розкодованого обʼєкта релізу (`release.data.decoded`).\n- Закодуйте обʼєкт релізу:\n  - Secret: `cat release.data.decoded | gzip | base64 | base64`\n  - ConfigMap: `cat release.data.decoded | gzip | base64`\n- Замість значення властивості `data.release` у файлі розгорнутого релізу (`release.yaml`) вставте новий закодований обʼєкт релізу.\n- Застосуйте файл до простору імен: `kubectl apply -f release.yaml -n <release_namespace>`\n- Виконайте `helm upgrade` з версією чарта, яка підтримує версії API Kubernetes.\n- Додайте опис до оновлення, щось на зразок \"не виконувати відкат до версії Helm, що передує цій поточній версії\".\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: Дистрибутиви Kubernetes\ndescription: Містить інформацію про використання Helm у специфічних середовищах Kubernetes.\nsidebar_position: 10\n---\n\nHelm повинен працювати з будь-якою [відповідною версією Kubernetes](https://github.com/cncf/k8s-conformance) (сертифікованою чи ні).\n\nЦей документ містить інформацію про використання Helm у специфічних середовищах Kubernetes. Будь ласка, додайте більше деталей про будь-які дистрибутиви (відсортовано за алфавітом), якщо це потрібно.\n\n## AKS\n\nHelm працює з [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nHelm було протестовано і він працює на платформі Kubernetes Mesosphere DC/OS 1.11, і не вимагає додаткової конфігурації.\n\n## EKS\n\nHelm працює з Amazon Elastic Kubernetes Service (Amazon EKS):\n[Використання Helm з Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nХостингова платформа Kubernetes Google GKE відома своєю сумісністю з Helm і не потребує додаткової конфігурації.\n\n## `scripts/local-cluster` та Hyperkube {#scripts-local-cluster-and-hyperkube}\n\nHyperkube, налаштований через `scripts/local-cluster.sh`, відомий своєю сумісністю. Для чистого Hyperkube можливо, що знадобиться деяка ручна конфігурація.\n\n## IKS\n\nHelm працює з [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nHelm регулярно тестується з [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne\n\nHelm працює у кластерах, які налаштовані за допомогою KubeOne без обмежень.\n\n## Kubermatic\n\nHelm працює у кластерах користувачів, створених Kubermatic без обмежень. Оскільки кластер seed може бути налаштований по-різному, підтримка Helm залежить від їх конфігурації.\n\n## MicroK8s\n\nHelm можна активувати в [MicroK8s](https://microk8s.io) за допомогою команди:\n`microk8s.enable helm3`\n\n## Minikube\n\nHelm протестований і відомий своєю сумісністю з [Minikube](https://github.com/kubernetes/minikube). Додаткової конфігурації не потребує.\n\n## Openshift\n\nHelm працює без проблем на OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (версія >= 3.6) або OpenShift Origin (версія >= 3.6). Щоб дізнатися більше, прочитайте [цей блог](https://blog.openshift.com/getting-started-helm-openshift/).\n\n## Platform9\n\nHelm попередньо встановлений в [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).\n\n## Ubuntu з `kubeadm` {#ubuntu-with-kubeadm}\n\nKubernetes, налаштований за допомогою `kubeadm`, відомий своєю сумісністю з наступними дистрибутивами Linux:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nДеякі версії Helm (v2.0.0-beta2) вимагають від вас `export KUBECONFIG=/etc/kubernetes/admin.conf` або створення `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid\n\nHelm працює на 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).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: Бібліотечні чарти\ndescription: Описує бібліотечні чарти та приклади їх використання\nsidebar_position: 4\n---\n\nБібліотечний чарт — це тип [Helm чарту](/topics/charts.md), який визначає примітиви або визначення, що можуть бути спільно використані шаблонами Helm в інших чартах. Це дозволяє користувачам ділитися фрагментами коду, які можна повторно використовувати у різних чартах, уникаючи повторень та підтримуючи чарти [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) (Don't Repeat Yourself).\n\nБібліотечний чарт було представлено у Helm 3 для формального визнання загальних або допоміжних чартів, які використовувалися авторами чартів ще з Helm 2. Додавши його як тип чарту, він надає:\n\n- Спосіб чітко розрізняти загальні та чарти застосунків\n- Логіку, що запобігає встановленню загального чарту\n- Відсутність рендерингу шаблонів у загальному чарті, які можуть містити артефакти релізу\n- Дозвіл залежним чартам використовувати контекст імпортера\n\nАвтор чарту може визначити загальний чарт як бібліотечний чарт та бути впевненим, що Helm обробить чарт стандартним узгодженим способом. Це також означає, що визначення у прикладному чарті можуть бути спільно використані шляхом зміни типу чарту.\n\n## Створення простого бібліотечного чарту {#creating-a-simple-library-chart}\n\nЯк вже згадувалося раніше, бібліотечний чарт — це тип [Helm чарту](/topics/charts.md). Це означає, що ви можете почати зі створення шаблонного чарту:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nСпочатку видаліть усі файли в теці `templates`, оскільки ми будемо створювати власні визначення шаблонів у цьому прикладі.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nФайл значень (values.yaml) також не буде потрібен.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nПерш ніж перейти до створення загального коду, давайте швидко переглянемо деякі відповідні концепції Helm. [іменований шаблон](/chart_template_guide/named_templates.md) (іноді називають частковим або субшаблоном) — це просто шаблон, визначений у файлі та який має назву. У теці `templates/` будь-який файл, який починається з підкреслення (_), не призначений для виводу маніфесту Kubernetes. Тому зазвичай допоміжні шаблони та часткові шаблони розміщуються у файлах `_*.tpl` або `_*.yaml`.\n\nУ цьому прикладі ми створимо загальний ConfigMap, який створює пустий ресурс ConfigMap. Ми визначимо загальний ConfigMap у файлі `mylibchart/templates/_configmap.yaml` наступним чином:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nКонструкція ConfigMap визначена у шаблоні з назвою `mylibchart.configmap.tpl`. Це простий ConfigMap з пустим ресурсом `data`. У цьому файлі є ще один іменований шаблон назвою, назва якого `mylibchart.configmap`. Цей іменований шаблон включає інший іменований шаблон `mylibchart.util.merge`, який приймає 2 іменовані шаблони як аргументи: шаблон, що викликає `mylibchart.configmap` та `mylibchart.configmap.tpl`.\n\nДопоміжна функція `mylibchart.util.merge` є іменованим шаблоном у `mylibchart/templates/_util.yaml`. Це зручний інструмент з [Загального допоміжного чарту Helm](#the-common-helm-helper-chart), оскільки він обʼєднує 2 шаблони та перевизначає будь-які спільні частини в обох:\n\n```yaml\n{{- /*\nmylibchart.util.merge зʼєднує два YAML-шаблони та виводить результат.\nВін приймає масив із трьох значень:\n- контекст верхнього рівня\n- ім'я шаблону перевизначення (призначення)\n- ім'я шаблону бази (джерело)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nЦе важливо, коли чарт хоче використовувати загальний код, який йому потрібно налаштувати за допомогою своєї конфігурації.\n\nНарешті, змініть тип чарту на `library`. Це вимагає редагування файлу `mylibchart/Chart.yaml` наступним чином:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: Helm чарт для Kubernetes\n\n# Чарт може бути або 'application', або 'library'.\n#\n# Чарти застосунків є колекцією шаблонів, які можуть бути упаковані\n# у версійні архіви для розгортання.\n#\n# Бібліотечні чарти надають корисні утиліти або функції для розробника\n# чартів. Вони включаються як залежність прикладних чартів для вбудування\n# цих утиліт та функцій у процес рендерингу. Бібліотечні чарти не визначають\n# жодних шаблонів і тому не можуть бути розгорнуті.\n# type: application\ntype: library\n\n# Це версія чарту. Це номер версії повинен збільшуватися кожного разу,\n# коли ви вносите зміни в чарт і його шаблони, включаючи версію програми.\nversion: 0.1.0\n\n# Це номер версії програми, що розгортається. Цей номер версії повинен\n# збільшуватися кожного разу, коли ви вносите зміни в програму, і\n# рекомендується використовувати з лапками.\nappVersion: \"1.16.0\"\n```\n\nТепер бібліотечний чарт готовий до спільного використання, а його визначення ConfigMap — до повторного використання.\n\nПерш ніж продовжити, варто перевірити, чи розпізнає Helm чарт як бібліотечний:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Використання простого бібліотечного чарту {#use-a-simple-library-chart}\n\nНастав час використати бібліотечний чарт. Для цього створимо знову шаблонний чарт:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nЗнову очистимо файли шаблонів, оскільки ми хочемо створити лише ConfigMap:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nЯкщо ми хочемо створити простий ConfigMap у шаблоні Helm, він може виглядати приблизно так:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nОднак, ми будемо повторно використовувати загальний код, створений у `mylibchart`. ConfigMap можна створити у файлі `mychart/templates/configmap.yaml` наступним чином:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nВи бачите, що це спрощує нашу роботу, успадковуючи загальне визначення ConfigMap, яке додає стандартні властивості для ConfigMap. У нашому шаблоні ми додаємо конфігурацію, у цьому випадку ключ даних `myvalue` та його значення. Конфігурація перекриває пустий ресурс загального ConfigMap. Це можливо завдяки допоміжній функції `mylibchart.util.merge`, яку ми згадували у попередньому розділі.\n\nЩоб мати можливість використовувати загальний код, нам потрібно додати `mylibchart` як залежність. Додайте наступний код в кінець файлу `mychart/Chart.yaml`:\n\n```yaml\n# Мій загальний код у бібліотечному чарті\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nЦе включає бібліотечний чарт як динамічну залежність із файлової системи, яка знаходиться на тому самому рівні, що і наш прикладний чарт. Оскільки ми включаємо бібліотечний чарт як динамічну залежність, нам потрібно виконати `helm dependency update`. Це скопіює бібліотечний чарт у вашу теку `charts/`.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nТепер ми готові розгорнути наш чарт. Перш ніж встановлювати, варто перевірити спочатку рендеринг шаблону.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nЦе виглядає як ConfigMap, який ми хочемо, з перезаписуванням даних `myvalue: Hello World`. Встановімо його:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nМи можемо отримати реліз і побачити, що фактичний шаблон був завантажений.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\n## Переваги бібліотечних чартів {#library-chart-benefits}\n\nЗ огляду на те, що бібліотечні чарти не можуть працювати як самостійні чарти, вони можуть використовувати такі функції:\n\n- Об’єкт `.Files` посилається на шляхи файлів у головному чарті, а не на локальний шлях до бібліотечного чарту.\n- Об’єкт `.Values` є таким самим, як і в головному чарті, на відміну від [субчартів](/chart_template_guide/subcharts_and_globals.md) застосунків, які отримують розділ значень, налаштованих під їхнім заголовком у головному чарті.\n\n## Common Helm Helper Chart {#the-common-helm-helper-chart}\n\n```markdown\nПримітка: Репозиторій Common Helm Helper Chart на Github більше не підтримується, і репозиторій було визнано застарілим та зархівовано.\n```\n\nЦей [чарт](https://github.com/helm/charts/tree/master/incubator/common) був початковим зразком для спільних чартів. Він надає утиліти, які відображають найкращі практики розробки чартів Kubernetes. Найкраще, що ви можете використати його одразу, коли розробляєте свої чарти, щоб отримати корисний загальний код.\n\nОсь короткий спосіб його використання. Для отримання додаткових деталей перегляньте [README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nСтворіть знову шаблонний чарт:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nВикористаймо загальний код з helper chart. Спочатку відредагуйте файл deployment `demo/templates/deployment.yaml` наступним чином:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Вкажіть перевизначення для вашого ресурсу Deployment тут, наприклад\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nІ тепер файл сервісу, `demo/templates/service.yaml`, наступним чином:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Вкажіть перевизначення для вашого ресурсу Service тут, наприклад\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nЦі шаблони демонструють, як використання загального коду з helper chart спрощує ваше кодування до налаштування чи конфігурації ресурсів.\n\nЩоб мати можливість використовувати загальний код, нам потрібно додати `common` як залежність. Додайте наступне в кінець файлу `demo/Chart.yaml`:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nПримітка: вам потрібно буде додати `incubator` до списку репозиторіїв Helm (`helm repo add`).\n\nОскільки ми включаємо чарт як динамічну залежність, нам потрібно виконати `helm dependency update`. Це скопіює helper chart у вашу теку `charts/`.\n\nОскільки helper chart використовує деякі конструкції Helm 2, вам потрібно буде додати наступне до `demo/values.yaml`, щоб дозволити завантаження образу `nginx`, оскільки це було оновлено в шаблонному чарті Helm 3:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nВи можете перевірити, чи правильні шаблони чарту, перед розгортанням, використовуючи команди `helm lint` і `helm template`.\n\nЯкщо все добре, розгорніть чарт, використовуючи `helm install`!\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Управління правами доступу для SQL-сховища\ndescription: Дізнайтеся, як налаштувати права доступу при використанні SQL-сховища.\nsidebar_position: 16\n---\n\nЦей документ надає рекомендації користувачам щодо налаштування та управління правами доступу при використанні SQL-сховища.\n\n## Вступ {#introduction}\n\nДля керування правами доступу Helm використовує функцію RBAC (Role-Based Access Control) Kubernetes. Проте, коли використовується SQL-сховище, ролі Kubernetes не можуть бути використані для визначення, чи може користувач отримати доступ до певного ресурсу. У цьому документі описано, як створювати та керувати такими правами доступу.\n\n## Ініціалізація {#initialization}\n\nПри першому підключенні CLI Helm до вашої бази даних клієнт перевірить, чи було її попередньо ініціалізовано. Якщо ні, клієнт автоматично подбає про необхідне налаштування. Для цього ініціалізація потребує адміністративних привілеїв у схемі public або принаймні можливості:\n\n* створення таблиці;\n* надання привілеїв на схему public.\n\nПісля виконання міграції в базі даних всі інші ролі зможуть використовувати клієнт.\n\n## Надання привілеїв неадміністративному користувачеві в PostgreSQL {#grant-privileges-to-a-non-admin-user-in-postgresql}\n\nДля керування правами доступу драйвер SQL-сховища використовує функцію [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row-Level Security) PostgreSQL. RLS дозволяє всім користувачам читати/записувати в одну й ту ж таблицю, але без можливості маніпулювати однаковими рядками, якщо їм це не було явно дозволено. Стандартно будь-яка роль, яка не отримала відповідних привілеїв, завжди отримуватиме порожній список при виконанні команди `helm list` і не матиме змоги отримати або змінити будь-який ресурс у кластері.\n\nРозглянемо, як надати певній ролі доступ до конкретних просторів імен:\n\n```sql\nCREATE POLICY <назва> ON releases_v1 FOR ALL TO <роль> USING (namespace = 'default');\n```\n\nЦя команда надасть дозволи на читання та запис всіх ресурсів, які відповідають умові `namespace = 'default'`, для ролі `role`. Після створення цієї політики користувач, підключений до бази даних від імені ролі `role`, зможе бачити всі випуски в просторі імен `default` при виконанні команди `helm list`, а також змінювати та видаляти їх.\n\nПривілеї можна керувати детально за допомогою RLS, і можливо буде корисним обмежити доступ, залежно від різних стовпців таблиці:\n\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Втулки Helm\ndescription: Описує, як використовувати та створювати втулки для розширення функціональності Helm.\nsidebar_position: 12\n---\n\nВтулок Helm — це інструмент, до якого можна отримати доступ через CLI `helm`, але який не є частиною основного коду Helm.\n\nНаявні втулки можна знайти у [відповідному](/community/related#helm-plugins) розділі або шукаючи на [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).\n\nЦей посібник пояснює, як використовувати та створювати втулки.\n\n## Огляд {#an-overview}\n\nВтулки Helm є додатковими інструментами, які безперешкодно інтегруються з Helm. Вони надають спосіб розширення основного набору функцій Helm без потреби написання кожної нової функції на Go і додавання її до основного інструменту.\n\nВтулки Helm мають такі особливості:\n\n- Їх можна додавати та видаляти з установки Helm без впливу на основний інструмент Helm.\n- Вони можуть бути написані будь-якою мовою програмування.\n- Вони інтегруються з Helm і будуть відображатися в `helm help` та інших місцях.\n\nВтулки Helm знаходяться в `$HELM_PLUGINS`. Ви можете дізнатися поточне значення цієї змінної, включаючи стандартні значення, коли не задано в середовищі, за допомогою команди `helm env`.\n\nМодель втулків Helm частково моделюється на основі моделі втулків Git. Відповідно, іноді ви можете чути, що `helm` називають _porcelain_ шаром, а втулки — _plumbing_. Це скорочений спосіб зазначити, що Helm забезпечує користувацький досвід і верхній рівень обробки логіки, тоді як втулки виконують \"детальну роботу\" для виконання бажаної дії.\n\n## Встановлення втулка {#installing-a-plugin}\n\nВтулки встановлюються за допомогою команди `$ helm plugin install <path|url>`. Ви можете передати шлях до втулка у вашій локальній файловій системі або URL віддаленого репозиторію VCS. Команда `helm plugin install` клонуватиме або копіюватиме втулок за вказаним шляхом/URL у `$HELM_PLUGINS`.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nЯкщо у вас є дистрибутив втулка у форматі tar, просто розпакуйте втулок у теку `$HELM_PLUGINS`. Ви також можете встановлювати втулки tarball безпосередньо з URL, використовуючи `helm plugin install https://domain/path/to/plugin.tar.gz`.\n\n## Тестування локально створеного втулка {#testing-a-locally-built-plugin}\n\nСпочатку вам потрібно знайти шлях до `HELM_PLUGINS`, для цього виконайте наступну команду:\n\n```bash\nhelm env\n```\n\nЗмініть поточну теку на теку, в яку встановлено `HELM_PLUGINS`.\n\nТепер ви можете додати символічне посилання на збірку вашого втулка, у цьому прикладі ми зробили це для `mapkubeapis`.\n\n```bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Створення втулків {#building-a-plugin}\n\nЗ усіх боків втулок схожий на чарт. Кожен втулок має теку верхнього рівня, а також файл `plugin.yaml`.\n\n```none\n$HELM_PLUGINS/\n  |- last/\n      |\n      |- plugin.yaml\n      |- last.sh\n\n```\n\nУ наведеному прикладі втулок `last` міститься у теці, що називається `last`. Він має два файли: `plugin.yaml` (обовʼязковий) та виконуваний скрипт, `last.sh` (необовʼязковий).\n\nЯдро втулка — це простий YAML файл, названий `plugin.yaml`. Ось YAML для втулка, який допомагає отримати останню назву релізу:\n\n```yaml\nname: \"last\"\nversion: \"0.1.0\"\nusage: \"отримати останню назву релізу\"\ndescription: \"отримати останню назву релізу\"\nignoreFlags: false\ncommand: \"$HELM_BIN --host $TILLER_HOST list --short --max 1 --date -r\"\nplatformCommand:\n  - os: linux\n    arch: i386\n    command: \"$HELM_BIN list --short --max 1 --date -r\"\n  - os: linux\n    arch: amd64\n    command: \"$HELM_BIN list --short --max 1 --date -r\"\n  - os: windows\n    arch: amd64\n    command: \"$HELM_BIN list --short --max 1 --date -r\"\n```\n\n`name` — це імʼя втулка. Коли Helm виконує цей втулок, це імʼя буде використовуватися (наприклад, `helm NAME` викликає цей втулок).\n\n_`name` повинно відповідати імені теки._ У нашому прикладі втулок з `name: last` має бути поміщений у теку з назвою `last`.\n\nОбмеження для `name`:\n\n- `name` не може дублювати одну з наявних команд на верхньому рівні `helm`.\n- `name` має бути обмежено символами ASCII a-z, A-Z, 0-9, `_` та `-`.\n\n`version` — це версія втулка за SemVer 2. `usage` і `description` використовуються для створення тексту довідки команди.\n\nПеремикач `ignoreFlags` вказує Helm, що _не_ слід передавати прапорці втулку. Якщо втулок викликаний з `helm myplugin --foo` і `ignoreFlags: true`, тоді `--foo` буде мовчки відкинуто.\n\nНарешті, і найголовніше, `platformCommand` або `command` — це команда, яку цей втулок виконає, коли його викликають. Розділ `platformCommand` визначає специфічні для ОС/Архітектури варіації команди. Наступні правила застосовуються при визначенні, яку команду використовувати:\n\n- Якщо `platformCommand` присутній, він буде перевірений першим.\n- Якщо `os` та `arch` відповідають поточній платформі, пошук зупиниться, і команда буде використана.\n- Якщо `os` відповідає і немає більш специфічного `arch` відповідності, команда буде використана.\n- Якщо жодної відповідності `platformCommand` не знайдено, буде використана стандартна команда `command`.\n- Якщо жодної відповідності не знайдено в `platformCommand` і `command` не присутній, Helm завершить виконання з помилкою.\n\nЗмінні середовища підставляються перед виконанням втулка. Шаблон вище ілюструє рекомендований спосіб вказівки, де знаходиться програма втулка.\n\nЄ кілька стратегій для роботи з командами втулків:\n\n- Якщо втулок включає виконуваний файл, виконуваний файл для `platformCommand:` або `command:` має бути упакований у теку втулка.\n- Рядок `platformCommand:` або `command:` буде мати розширені змінні середовища перед виконанням. `$HELM_PLUGIN_DIR` вказуватиме на теку втулка.\n- Команда сама по собі не виконується в оболонці. Тому ви не можете використовувати однорядковий скрипт оболонки.\n- Helm вбудовує багато конфігурацій у змінні середовища. Ознайомтеся з середовищем, щоб дізнатися, яка інформація доступна.\n- Helm не робить припущень щодо мови втулка. Ви можете написати його будь-якою мовою, яка вам подобається.\n- Команди відповідають за реалізацію специфічного тексту допомоги для `-h` та `--help`. Helm використовуватиме `usage` та `description` для `helm help` та `helm help myplugin`, але не обробляє `helm myplugin --help`.\n\n## Завантажувач втулків {#downloader-plugins}\n\nСтандартно Helm здатен завантажувати чарти за допомогою HTTP/S. Починаючи з версії Helm 2.4.0, втулки можуть мати спеціальну можливість завантажувати чарти з довільних джерел.\n\nВтулки повинні оголосити цю спеціальну можливість у файлі `plugin.yaml` (на верхньому рівні):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nЯкщо такий втулок встановлений, Helm може взаємодіяти з репозиторієм, використовуючи вказану схему протоколу, викликавши `command`. Спеціальний репозиторій слід додати так само як і звичайні: `helm repo add favorite myprotocol://example.com/`. Правила для спеціальних репозиторіїв такі ж, як і для звичайних: Helm повинен бути здатен завантажити файл `index.yaml`, щоб виявити та зберегти список доступних чартів.\n\nВизначена команда буде викликана за схемою: `command certFile keyFile caFile full-URL`. Облікові відомості SSL беруться з визначення репозиторію, що зберігається в `$HELM_REPOSITORY_CONFIG` (тобто `$HELM_CONFIG_HOME/repositories.yaml`). Очікується, що команда завантажувача виведе сирий контент на stdout і повідомить про помилки на stderr.\n\nКоманда завантажувача також підтримує підкоманди або аргументи, що дозволяє, наприклад, вказати `bin/mydownloader subcommand -d` у `plugin.yaml`. Це корисно, якщо ви хочете використовувати один і той же виконуваний файл для основної команди втулка та команди завантажувача, але з різною підкомандою для кожної.\n\n## Змінні середовища {#environment-variables}\n\nКоли Helm виконує втулок, він передає зовнішнє середовище втулку та також вбудовує деякі додаткові змінні середовища.\n\nЗмінні, такі як `KUBECONFIG`, встановлюються для втулка, якщо вони встановлені у зовнішньому середовищі.\n\nГарантовано будуть встановлені такі змінні:\n\n- `HELM_PLUGINS`: Шлях до теки втулків.\n- `HELM_PLUGIN_NAME`: Імʼя втулка, яке використовується при виклику через `helm`. Тобто `helm myplug` матиме коротке імʼя `myplug`.\n- `HELM_PLUGIN_DIR`: Тека, що містить втулок.\n- `HELM_BIN`: Шлях до команди `helm` (як виконана користувачем).\n- `HELM_DEBUG`: Вказує, чи був встановлений прапорець налагодження.\n- `HELM_REGISTRY_CONFIG`: Місце для конфігурації реєстру (якщо використовується). Зазначте, що використання Helm з реєстрами є експериментальною функцією.\n- `HELM_REPOSITORY_CACHE`: Шлях до кеш-файлів репозиторіїв.\n- `HELM_REPOSITORY_CONFIG`: Шлях до файлу конфігурації репозиторію.\n- `HELM_NAMESPACE`: Простір імен, вказаний команді `helm` (зазвичай за допомогою прапорця `-n`).\n- `HELM_KUBECONTEXT`: Назва контексту конфігурації Kubernetes, наданого команді `helm`.\n\nКрім того, якщо конфігураційний файл Kubernetes був явно вказаний, він буде встановлений як змінна `KUBECONFIG`.\n\n## Примітка про парсинг прапорців {#note-on-flag-parsing}\n\nПри виконанні втулка Helm буде розбирати глобальні прапорці для власного використання. Жоден з цих пропорців не передається втулку.\n- `--burst-limit`: Це перетворюється в `$HELM_BURST_LIMIT`.\n- `--debug`: Якщо цей прапорець вказаний, `$HELM_DEBUG` встановлюється в `1`.\n- `--kube-apiserver`: Це перетворюється в `$HELM_KUBEAPISERVER`.\n- `--kube-as-group`: Ці перетворюються в `$HELM_KUBEASGROUPS`.\n- `--kube-as-user`: Це перетворюється в `$HELM_KUBEASUSER`.\n- `--kube-ca-file`: Це перетворюється в `$HELM_KUBECAFILE`.\n- `--kube-context`: Це перетворюється в `$HELM_KUBECONTEXT`.\n- `--kube-insecure-skip-tls-verify`: Це перетворюється в `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`.\n- `--kube-tls-server-name`: Це перетворюється в `$HELM_KUBETLS_SERVER_NAME`.\n- `--kube-token`: Це перетворюється в `$HELM_KUBETOKEN`.\n- `--kubeconfig`: Це перетворюється в `$KUBECONFIG`.\n- `--namespace` and `-n`: Це перетворюється в `$HELM_NAMESPACE`.\n- `--qps`: Це перетворюється в `$HELM_QPS`.\n- `--registry-config`: Це перетворюється в `$HELM_REGISTRY_CONFIG`.\n- `--repository-cache`: Це перетворюється в `$HELM_REPOSITORY_CACHE`.\n- `--repository-config`: Це перетворюється в `$HELM_REPOSITORY_CONFIG`.\n\nВтулки _повинні_ відображати текст довідки та виходити для `-h` та `--help`. У всіх інших випадках втулки можуть використовувати прапорці за потреби.\n\n## Надання автозавершення оболонки {#providing-shell-auto-completion}\n\nПочинаючи з Helm 3.2, втулок може додатково підтримувати автозавершення оболонки як частину наявного механізму автозавершення Helm.\n\n### Статичне автозавершення {#static-auto-completion}\n\nЯкщо втулок надає свої власні прапорці та/або підкоманди, він може сповістити Helm про них, маючи файл `completion.yaml`, розташований у кореневій теці втулка. Файл `completion.yaml` має форму:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nПримітки:\n1. Усі секції є необовʼязковими, але їх слід надати, якщо треба.\n1. Прапорці не повинні включати префікс `-` або `--`.\n1. Як короткі, так і довгі прапорці можуть і повинні бути вказані. Короткий прапорець не потребує асоціації з відповідною довгою формою, але обидві форми слід перерахувати.\n1. Прапорці не потрібно упорядковувати будь-яким чином, але їх слід перераховувати в правильному місці в ієрархії підкоманд файлу.\n1. Глобальні прапорці Helm вже обробляються механізмом автозавершення Helm, тому втулкам не потрібно вказувати наступні прапорці `--debug`, `--namespace` або `-n`, `--kube-context`, і `--kubeconfig`, або будь-які інші глобальні прапорці.\n1. Список `validArgs` надає статичний список можливих завершень для першого параметра після підкоманди. Можливо не завжди надати такий список заздалегідь (див. розділ [Динамічне завершення](#dynamic-completion) нижче), у цьому випадку розділ `validArgs` можна пропустити.\n\nФайл `completion.yaml` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати автозавершення оболонки для втулка (якщо не підтримується [Динамічне завершення](#dynamic-completion) втулком). Крім того, додавання файлу `completion.yaml` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm.\n\nЯк приклад, для втулка [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus), який не має підкоманд, але приймає ті ж прапорці, що й команда `helm status`, файл `completion.yaml` виглядає так:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nСкладніший приклад для втулка [`2to3`](https://github.com/helm/helm-2to3), має файл `completion.yaml` наступного вигляду:\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### Динамічне автозавершення {#dynamic-completion}\n\nПочинаючи з Helm 3.2, втулки можуть надавати динамічне автозавершення оболонки. Динамічне автозавершення забезпечує завершення значень параметрів або прапорців, які не можуть бути визначені заздалегідь. Наприклад, завершення імен Helm релізів, які наразі доступні в кластері.\n\nЩоб втулок підтримував динамічне автозавершення, він повинен надати **виконуваний** файл з назвою `plugin.complete` у своїй кореневій теці. Коли скрипт автозавершення Helm потребує динамічного завершення для втулка, він виконає файл `plugin.complete`, передаючи йому командний рядок, який потрібно завершити. Виконуваний файл `plugin.complete` повинен містити логіку для визначення правильних варіантів завершення та виводити їх на стандартний вихід, щоб їх можна було спожити скриптом автозавершення Helm.\n\nФайл `plugin.complete` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати динамічне автозавершення для втулка. Крім того, додавання файлу `plugin.complete` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm.\n\nВихідний результат скрипту `plugin.complete` повинен бути списком, розділеним новими рядками, наприклад:\n\n```none\nrel1\nrel2\nrel3\n```\n\nКоли `plugin.complete` викликаний, середовище втулка встановлено так само, як і при виклику основного скрипту втулка. Отже, змінні `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` та всі інші змінні втулка вже будуть встановлені, а відповідні глобальні прапорці будуть видалені.\n\nФайл `plugin.complete` може бути будь-якої виконуваної форми; це може бути shell-скрипт, програма на Go або будь-яка інша програма, яку Helm може виконати. Файл `plugin.complete` _**повинен**_ мати права на виконання для користувача. Файл `plugin.complete` _**повинен**_ завершитися з кодом успіху (значення 0).\n\nУ деяких випадках динамічне завершення вимагатиме отримання інформації з кластера Kubernetes. Наприклад, втулок `helm fullstatus` потребує імені релізу як вводу. У втулку `fullstatus`, щоб скрипт `plugin.complete` надав завершення для поточних імен релізів, він може просто виконати `helm list -q` і вивести результат.\n\nЯкщо ви бажаєте використовувати один і той же виконуваний файл для виконання втулка та для завершення втулка, скрипт `plugin.complete` може викликати основний виконуваний файл втулка з певним спеціальним параметром або прапорцем; коли основний виконуваний файл втулка виявляє спеціальний параметр або прапорець, він буде знати, що потрібно виконати завершення. У нашому прикладі `plugin.complete` може бути реалізований так:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" є всім командним рядком, який потребує завершення.\n# Важливо використовувати подвійні лапки в змінній \"$@\", щоб зберегти можливий пустий останній параметр.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nСправжній скрипт втулка `fullstatus` (`status.sh`) повинен тоді шукати прапорець `--complete` і, якщо знайде його, вивести правильні завершення.\n\n### Поради та підказки {#tips-and-tricks}\n\n1. Оболонка автоматично відфільтровує варіанти завершення, які не відповідають введенню користувача. Отже, втулок може повернути всі відповідні завершення без видалення тих, які не відповідають введенню користувача. Наприклад, якщо командний рядок `helm fullstatus ngin<TAB>`, скрипт `plugin.complete` може вивести _всі_ імена релізів (з простору імен `default`), а не лише ті, що починаються з `ngin`; оболонка зберігає лише ті, що починаються з `ngin`.\n2. Щоб спростити підтримку динамічного завершення, особливо якщо у вас складний втулок, ви можете налаштувати скрипт `plugin.complete`, щоб він викликав основний скрипт втулка і запитував варіанти завершення. Дивіться розділ [Динамічне завершення](#dynamic-completion) вище для прикладу.\n3. Для налагодження динамічного завершення та файлу `plugin.complete` можна виконати наступне, щоб побачити результати завершення:\n   - `helm __complete <pluginName> <arguments to complete>`. Наприклад:\n   - `helm __complete fullstatus --output js<ENTER>`,\n   - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: Підтвердження походження та цілісності в Helm\ndescription: Описує, як перевірити цілісність та походження чарту.\nsidebar_position: 5\n---\n\nHelm має інструменти підтвердження походження, які допомагають користувачам чартів перевіряти цілісність та походження пакета. Використовуючи інструменти на основі PKI, GnuPG та відомих менеджерів пакетів, Helm може створювати та перевіряти підписані файли.\n\n## Огляд {#overview}\n\nЦілісність встановлюється шляхом порівняння чарту з записом про походження. Записи про походження зберігаються у _файлах походження_, які зберігаються поряд з упакованим чартом. Наприклад, якщо чарти називаються `myapp-1.2.3.tgz`, то файл походження буде `myapp-1.2.3.tgz.prov`.\n\nФайли походження генеруються під час пакування (`helm package --sign ...`) і можуть бути перевірені кількома командами, зокрема `helm install --verify`.\n\n## Робочий процес {#the-workflow}\n\nЦей розділ описує можливий робочий процес ефективного використання даних походження.\n\nПередумови:\n\n- Дійсна пара ключів PGP у бінарному (не ASCII-зашифрованому) форматі\n- Інструмент командного рядка `helm`\n- Інструменти командного рядка GnuPG (необов’язково)\n- Інструменти командного рядка Keybase (необов’язково)\n\n**ПРИМІТКА:** Якщо ваш приватний ключ PGP має парольну фразу, вам буде запропоновано ввести її для будь-яких команд, які підтримують опцію `--sign`.\n\nСтворення нового чарту виконується так само як і раніше:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nКоли ви готові до пакування, додайте прапорець `--sign` до команди `helm package`. Також вкажіть ім’я, під яким відомий ключ підпису, і вʼязку ключів, що містить відповідний приватний ключ:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**Примітка:** Значення аргументу `--key` повинно бути субрядком бажаного `uid` ключа (виведеного командою `gpg --list-keys`), наприклад імʼя або електронна пошта. **Відбиток _не може_ бути використаний.**\n\n**ПОРАДА:** Для користувачів GnuPG ваша секретна вʼязка ключів знаходиться в `~/.gnupg/secring.gpg`. Ви можете використовувати команду `gpg --list-secret-keys`, щоб переглянути наявні ключі.\n\n**Попередження:** у GnuPG версії 2 ваша секретна вʼязка ключів зберігається у новому форматі `kbx` стандартно у `~/.gnupg/pubring.kbx`. Будь ласка, використовуйте такі команди, щоб перетворити свою вʼязку ключів у старий формат gpg:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nНа цьому етапі ви повинні побачити як `mychart-0.1.0.tgz`, так і `mychart-0.1.0.tgz.prov`. Обидва файли зрештою мають бути завантажені у ваш бажаний репозиторій чартів.\n\nВи можете перевірити чарт за допомогою команди `helm verify`:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nПриклад невдалої перевірки:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 сума не співпадає для topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nЩоб перевірити під час встановлення, використовуйте прапорець `--verify`.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nЯкщо вʼязка ключів, що містить публічний ключ, асоційований із підписаним чартом, не знаходиться в стандартному місці, можливо, вам доведеться вказати шлях до вʼязки ключів за допомогою `--keyring PATH`, як у прикладі з `helm package`.\n\nЯкщо перевірка не вдалася, встановлення буде перервано ще до того, як чарт буде навіть оброблено.\n\n### Використання облікових даних Keybase.io {#using-keybase-io-credentials}\n\nСервіс [Keybase.io](https://keybase.io) спрощує створення ланцюга довіри для криптографічної ідентичності. Облікові дані Keybase можуть бути використані для підписання чартів.\n\nПередумови:\n\n- Налаштований обліковий запис Keybase.io\n- Встановлений локально GnuPG\n- Встановлений локально CLI для Keybase\n\n#### Підписання пакетів {#signing-packages}\n\nПершим кроком є імпорт ваших ключів Keybase у вашу локальну вʼязку ключів GnuPG:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nЦе перетворить ваш ключ Keybase у формат OpenPGP і потім імпортує його локально у файл `~/.gnupg/secring.gpg`.\n\nВи можете перевірити це, виконавши команду `gpg --list-secret-keys`.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec 2048R/1FC18762 2016-07-25\nuidtechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb 2048R/D125E546 2016-07-25\n```\n\nЗверніть увагу, що ваш секретний ключ матиме рядок ідентифікатора:\n\n```none\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nЦе повне імʼя вашого ключа.\n\nДалі, ви можете упакувати та підписати чарт за допомогою `helm package`. Переконайтеся, що ви використовуєте хоча б частину цього рядка назви у `--key`.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nЯк результат, команда `package` має створити як файл `.tgz`, так і файл `.tgz.prov`.\n\n#### Перевірка пакетів {#verifying-packages}\n\nВи також можете використовувати аналогічний метод для перевірки чарту, підписаного ключем Keybase іншого користувача. Наприклад, ви хочете перевірити пакет, підписаний `keybase.io/technosophos`. Для цього скористайтесь інструментом `keybase`:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nПерша команда відстежує користувача `technosophos`. Далі, команда `keybase pgp pull` завантажує ключі OpenPGP всіх облікових записів, які ви відстежуєте, розміщуючи їх у вашій вʼязці ключів GnuPG (`~/.gnupg/pubring.gpg`).\n\nНа цьому етапі ви можете використовувати `helm verify` або будь-які команди з прапорцем `--verify`:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Причини, через які чарт може не пройти перевірку {#reasons-a-chart-may-not-verify}\n\nЦе поширені причини невдач.\n\n- Файл `.prov` відсутній або пошкоджений. Це вказує на те, що щось неправильно налаштовано або що початковий підтримувач не створив файл походження.\n- Ключ, використаний для підписання файлу, не знаходиться у вашій вʼязці ключів. Це означає, що особа, яка підписала чарт, не є тією, кому ви вже довіряєте.\n- Перевірка файлу `.prov` не пройшла. Це вказує на те, що щось не так із чартом або даними походження.\n- Хеші файлів у файлі походження не збігаються з хешем архівного файлу. Це свідчить про те, що архів було підроблено.\n\nЯкщо перевірка не пройшла, це є підставою для недовіри до пакета.\n\n## Файл походження {#the-provenance-file}\n\nФайл походження містить YAML файл чарту та кілька елементів верифікаційної інформації. Файли походження розроблені для автоматичної генерації.\n\nДодаються наступні частини даних походження:\n\n- Файл чарту (`Chart.yaml`) включається для зручного перегляду вмісту чарту як людьми, так і інструментами.\n- Підпис (SHA256, аналогічно до Docker) пакету чарту (файл `.tgz`) включається та може бути використаний для перевірки цілісності пакета чарту.\n- Весь зміст підписується за допомогою алгоритму OpenPGP (див. [Keybase.io](https://keybase.io) для спрощення процесу криптографічного підпису та перевірки).\n\nЦе надає користувачам такі гарантії:\n\n- Пакет не було підроблено (перевірка контрольної суми пакета `.tgz`).\n- Особа, яка випустила цей пакет, є відомою (через підпис GnuPG/PGP).\n\nФормат файлу виглядає приблизно так:\n\n```none\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nЗверніть увагу, що розділ YAML містить два документи (розділені `...\\n`). Перший файл — це вміст `Chart.yaml`. Другий — це контрольні суми, map імен файлів та SHA-256 дайджестів вмісту цього файлу на момент пакування.\n\nБлок підпису є стандартним підписом PGP, який забезпечує [стійкість до підробок](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Репозиторії чартів {#chart-repositories}\n\nРепозиторії чартів слугують як централізоване зібрання чартів Helm.\n\nРепозиторії чартів повинні забезпечувати можливість надання файлів походження через HTTP за певним запитом і повинні робити їх доступними за тим же шляхом URI, що й чарт.\n\nНаприклад, якщо базовий URL для пакета — `https://example.com/charts/mychart-1.2.3.tgz`, файл походження, якщо він існує, ПОВИНЕН бути доступний за адресою `https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nЗ погляду кінцевого користувача, команда `helm install --verify myrepo/mychart-1.2.3` повинна призвести до завантаження як чарту, так і файлу походження без додаткових налаштувань або дій користувача.\n\n### Підписи в OCI-реєстрах {#signatures-in-oci-based-registries}\n\nПри публікації чартів до [реєстру на основі 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` може бути використана для публікації файлів походження до незмінного прозорого логу.\n\n## Встановлення авторитету та автентичності {#establishing-authority-and-authenticity}\n\nУ системах ланцюга довіри важливо мати можливість встановити авторитет підписувача. Іншими словами, система залежить від того, що ви довіряєте особі, яка підписала чарт. Це означає, що вам потрібно довіряти публічному ключу підписувача.\n\nОдне з проєктних рішень щодо Helm полягало в тому, що проєкт Helm не буде вставляти себе в ланцюжок довіри як обовʼязкову сторону. Ми не хочемо бути \"центром сертифікації\" для всіх підписувачів чартів. Замість цього ми дуже підтримуємо децентралізовану модель, що є частиною причини, чому ми вибрали OpenPGP як нашу основну технологію. Тому, коли йдеться про встановлення авторитету, ми залишили цей крок більш-менш невизначеним у Helm 2 (рішення було перенесене у Helm 3).\n\nПроте, у нас є кілька порад і рекомендацій для тих, хто зацікавлений у використанні системи походження:\n\n- Платформа [Keybase](https://keybase.io) надає публічне централізоване сховище для інформації про довіру.\n  - Ви можете використовувати Keybase для зберігання своїх ключів або отримання публічних ключів інших.\n  - Keybase також має чудову документацію.\n  - Хоча ми не тестували це, функція \"захищений вебсайт\" Keybase може бути використана для сервісу чартів Helm.\n  - Основна ідея полягає в тому, що офіційний \"рецензент чартів\" підписує чарти своїм ключем, а отриманий файл походження потім завантажується в репозиторій чартів.\n  - Було зроблено деякі роботи над ідеєю, що список дійсних підписуючих ключів може бути включений у файл `index.yaml` репозиторію.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: Контроль доступу на основі ролей\ndescription: Пояснює, як Helm взаємодіє з контролем доступу на основі ролей Kubernetes.\nsidebar_position: 11\n---\n\nУ Kubernetes надання ролей користувачу або службовому обліковому запису, специфічному для застосунку, є найкращою практикою для забезпечення роботи вашого застосунку в межах, які ви визначили. Дізнайтеся більше про дозволи службових облікових записів [в офіційній документації Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nЗ версії Kubernetes 1.6 контроль доступу на основі ролей (RBAC) стандартно увімкнено. RBAC дозволяє вам визначати, які типи дій дозволені залежно від користувача та його ролі у вашій організації.\n\nЗ RBAC ви можете:\n\n- надавати привілейовані операції (створення ресурсів на рівні кластеру, таких як нові ролі) адміністраторам\n- обмежити можливість користувача створювати ресурси (pods, persistent volumes, deployments) до певних просторів імен або в межах кластера (квоти ресурсів, ролі, визначення власних ресурсів)\n- обмежити можливість користувача переглядати ресурси або в певних просторах імен, або в межах кластера.\n\nЦей посібник призначений для адміністраторів, які хочуть обмежити область доступу користувача до API Kubernetes.\n\n## Управління обліковими записами користувачів {#managing-user-accounts}\n\nУсі кластери Kubernetes мають дві категорії користувачів: службові облікові записи, керовані Kubernetes, та звичайні користувачі.\n\nПередбачається що звичайними користувачами керує зовнішній незалежний сервіс. Це може бути адміністратор, який розподіляє приватні ключі, сховище користувачів, таке як Keystone або Google Accounts, або навіть файл зі списком імен користувачів та паролів. У цьому відношенні Kubernetes не має обʼєктів, які представляють звичайні облікові записи користувачів. Звичайних користувачів не можна додати до кластера через API-запит.\n\nНа відміну від цього, службові облікові записи є користувачами, керованими API Kubernetes. Вони привʼязані до певних просторів імен і створюються автоматично API сервером або вручну через API-запити. службові Облікові записи привʼязані до набору облікових даних, які зберігаються як Secrets і монтуються в podʼи, що дозволяє процесам всередині кластера спілкуватися з API Kubernetes.\n\nAPI-запити привʼязані або до звичайного користувача, або до облікового запису служби, або розглядаються як анонімні запити. Це означає, що кожен процес всередині або зовні кластера, від людини, що набирає `kubectl` на робочій станції, до kubelets на вузлах, до членів панелі управління, повинен пройти автентифікацію при здійсненні запитів до API сервера або бути розглянутим як анонімний користувач.\n\n## Roles, ClusterRoles, RoleBindings та ClusterRoleBindings {#roles-clusterroles-rolebindings-and-clusterrolebindings}\n\nУ Kubernetes облікові записи користувачів і службові облікові записи можуть переглядати та редагувати лише ресурси, до яких їм надано доступ. Цей доступ надається за допомогою Roles і RoleBindings. Ролі та RoleBindings привʼязані до певного простору імен, надаючи користувачам можливість переглядати та/або редагувати ресурси в цьому просторі імен, до яких надає доступ Role.\n\nНа рівні кластера ці обʼєкти називаються ClusterRoles і ClusterRoleBindings. Надаючи користувачу ClusterRole, ви надаєте їм доступ до перегляду та/або редагування ресурсів по всьому кластеру. Це також необхідно для перегляду та/або редагування ресурсів на рівні кластера (простори імен, квоти ресурсів, вузли).\n\nClusterRoles можна привʼязати до певного простору імен через посилання в RoleBinding. `admin`, `edit` та `view` стандартні ClusterRoles часто використовуються таким чином.\n\nОсь кілька ClusterRoles, стандартно доступних у Kubernetes. Вони призначені для користувачів. До них відносяться суперкористувацькі ролі (`cluster-admin`) та ролі з більш детальним доступом (`admin`, `edit`, `view`).\n\n| Стандартна ClusterRole | Стандартна ClusterRoleBinding | Опис\n|-------------------------|--------------------------------|-------------\n| `cluster-admin`         | Група `system:masters`         | Дозволяє суперкористувацький доступ для виконання будь-якої дії над будь-яким ресурсом. При використанні в ClusterRoleBinding надає повний контроль над кожним ресурсом в кластері та у всіх просторах імен. При використанні в RoleBinding надає повний контроль над кожним ресурсом в просторі імен, що привʼязується до RoleBinding, включаючи сам простір імен.\n| `admin`                 | Немає                          | Дозволяє адміністративний доступ, призначений для надання всередині простору імен за допомогою RoleBinding. Якщо використовується в RoleBinding, дозволяє читання/запис доступу до більшості ресурсів у просторі імен, включаючи можливість створювати ролі та RoleBindings всередині простору імен. Не дозволяє записувати доступ до квоти ресурсів або до самого простору імен.\n| `edit`                  | Немає                          | Дозволяє читання/запис доступу до більшості обʼєктів у просторі імен. Не дозволяє переглядати або модифікувати ролі або RoleBindings.\n| `view`                  | Немає                          | Дозволяє доступ лише для читання, щоб побачити більшість обʼєктів у просторі імен. Не дозволяє переглядати ролі або RoleBindings. Не дозволяє переглядати secrets, оскільки це є ескалацією доступу.\n\n## Обмеження доступу облікових записів користувачів за допомогою RBAC {#restricting-a-users-accont-s-access-using-rbac}\n\nТепер, коли ми розуміємо основи контролю доступу на основі ролей, розглянемо, як адміністратор може обмежити область доступу користувача.\n\n### Приклад: Надання користувачу доступу для читання/запису в певного простору імен {#example-grnt-a-user-read-write-access-to-a-particular-namespace}\n\nЩоб обмежити доступ користувача до певного простору імен, можна використовувати роль `edit` або `admin`. Якщо ваші чарти створюють або взаємодіють з Roles і RoleBindings, ви захочете використовувати `admin` ClusterRole.\n\nКрім того, ви також можете створити RoleBinding з доступом `cluster-admin`. Надаючи користувачу доступ `cluster-admin` на рівні простору імен, ви надаєте повний контроль над кожним ресурсом у просторі імен, включаючи сам простір імен.\n\nДля цього прикладу ми створимо користувача з роллю `edit`. Спочатку створіть простір імен:\n\n```shell\n$ kubectl create namespace foo\n```\n\nТепер створіть RoleBinding у цьому просторі імен, надаючи користувачу роль `edit`.\n\n```shell\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Приклад: Надання користувачу доступу для читання/запису на рівні кластера {#example-grant-a-user-read-write-access-at-the-cluster-scope}\n\nЯкщо користувач хоче встановити чарт, який встановлює ресурси на рівні кластера (простори імен, ролі, визначення власних ресурсів тощо), їм знадобиться доступ для запису на рівні кластера.\n\nДля цього надайте користувачу доступ `admin` або `cluster-admin`.\n\nНадання користувачу доступу `cluster-admin` надає їм доступ до всіх ресурсів Kubernetes, включаючи доступ до вузлів з `kubectl drain` та інші адміністративні завдання. Рекомендується розглянути можливість надання користувачу доступу `admin`, або створити власну ClusterRole, адаптовану до їхніх потреб.\n\n```shell\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Приклад: Надання користувачу доступу лише для читання до певного простору імен {#example-grant-a-user-read-only-access-to-a-particular-namespace}\n\nВи могли помітити, що не існує ClusterRole, доступної для перегляду secrets. Роль `view` не надає користувачу доступ до Secrets через проблеми з ескалацією. Helm стандартно зберігає метадані релізів як Secrets.\n\nЩоб користувач міг виконати команду `helm list`, їм потрібно мати можливість читати ці секрети. Для цього ми створимо спеціальний `secret-reader` ClusterRole.\n\nСтворіть файл `cluster-role-secret-reader.yaml` і напишіть наступний вміст у файл:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nПотім створіть ClusterRole за допомогою:\n\n```shell\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nЯк тільки це буде зроблено, ми можемо надати користувачу доступ для читання до більшості ресурсів, а потім надати їм доступ до секретів:\n\n```shell\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Приклад: Надання користувачу доступу лише для читання на рівні кластера {#example-grant-a-user-read-only-access-at-the-cluster-scope}\n\nВ деяких випадках може бути корисно надати користувачу доступ на рівні кластера. Наприклад, якщо користувач хоче виконати команду `helm list --all-namespaces`, API вимагає, щоб користувач мав доступ для читання на рівні кластера.\n\nДля цього надайте користувачу як `view`, так і `secret-reader` доступ, як описано вище, але за допомогою ClusterRoleBinding.\n\n```shell\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Додатково {#additional-thoughts}\n\nВищезазначені приклади використовують стандартні ClusterRoles, надані Kubernetes. Для більш детального контролю над ресурсами, до яких користувачі мають доступ, ознайомтеся з [документацією Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) по створенню власних Roles і ClusterRoles.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: Використання реєстрів на основі OCI\ndescription: Описує, як використовувати OCI для розповсюдження чартів.\nsidebar_position: 7\n---\n\nПочинаючи з Helm 3, ви можете використовувати реєстри контейнерів з підтримкою [OCI](https://www.opencontainers.org/) для зберігання та обміну пакетами чартів. Починаючи з Helm v3.8.0, підтримка OCI є стандартно увімкнено.\n\n## Підтримка OCI до v3.8.0 {#oci-support-prior-to-v3.8.0}\n\nПідтримка OCI перейшла з експериментального статусу в загальну доступність з Helm v3.8.0. У попередніх версіях Helm підтримка OCI працювала інакше. Якщо ви використовували підтримку OCI до Helm v3.8.0, важливо зрозуміти, що змінилося в Helm.\n\n### Увімкнення підтримки OCI до v3.8.0 {#enabling-oci-support-prior-to-v3.8.0}\n\nДо Helm v3.8.0 підтримка OCI є *експериментальною* і має бути увімкнена вручну.\n\nЩоб увімкнути експериментальну підтримку OCI для версій Helm до v3.8.0, задайте `HELM_EXPERIMENTAL_OCI` у вашому середовищі. Наприклад:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### Визнання застарілою функції OCI та зміни поведінки з v3.8.0 {#oci-deprecation-and-behavior-changes-with-v3.8.0}\n\nЗ виходом [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) наступні функції та поведінка відрізняються від попередніх версій Helm:\n\n- При встановленні chart у залежностях як OCI, версію можна задати у вигляді діапазону, як і для інших залежностей.\n- Теги SemVer, які містять інформацію про збірку, можна публікувати та використовувати. Реєстри OCI не підтримують `+` як символ теґу. Helm перетворює `+` на `_`, коли він зберігається як теґ.\n- Команда `helm registry login` тепер дотримується тієї ж структури, що й Docker CLI для зберігання облікових даних. Те ж місце для конфігурації реєстру може бути передане як Helm, так і Docker CLI.\n\n### Визнання застарілою функції OCI та зміни поведінки з v3.7.0\n\nВипуск [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:\n\n- Субкоманда `helm chart` була видалена.\n- Кеш chart був видалений (немає `helm chart list` тощо).\n- Посилання на реєстри OCI тепер завжди починаються з `oci://`.\n- Базове імʼя посилання на реєстр має *завжди* відповідати імені chart.\n- Тег посилання на реєстр має *завжди* відповідати семантичній версії chart (тобто без тегів `latest`).\n- Тип медіа шару chart був змінений з `application/tar+gzip` на `application/vnd.cncf.helm.chart.content.v1.tar+gzip`.\n\n## Використання реєстру на основі OCI {#using-an-oci-based-registry}\n\n### Репозиторії Helm у реєстрах на основі OCI {#helm-repositories-in-oci-based-registries}\n\n[Репозиторій Helm](/topics/chart_repository.md) — це спосіб зберігання та розподілу упакованих Helm chart. Реєстр на основі OCI може містити нуль або більше репозиторіїв Helm, і кожен з цих репозиторіїв може містити нуль або більше упакованих Helm chart.\n\n### Використання послуг реєстрів {#use-hosted-registries}\n\nІснує кілька реєстрів контейнерів з підтримкою OCI, які ви можете використовувати для ваших Helm chart. Наприклад:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n\nЩоб створити та налаштувати реєстр з підтримкою OCI, дотримуйтесь документації постачальника реєстру контейнерів на хостингу.\n\n**Примітка:** Ви можете запускати [Docker Registry](https://docs.docker.com/registry/deploying/) або [`zot`](https://github.com/project-zot/zot), які є реєстрами на основі OCI, на вашому компʼютері для розробки. Запуск реєстру на основі OCI на вашому компʼютері, де відбувається розробка, слід використовувати лише для тестування.\n\n### Використання sigstore для підписування чартів на основі OCI {#using-sigstore-to-sign-oci-charts}\n\nВтулок [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) дозволяє використовувати [Sigstore](https://sigstore.dev/) для підписування Helm чартів тими ж інструментами, які використовуються для підписування контейнерних образів. Це є альтернативою [перевірки походження](/topics/provenance.md), що використовує GPD, яке підтримується класичними [репозиторіями чартів](/topics/chart_repository.md).\n\nДля отримання додаткової інформації про використання втулка `helm sigstore`, дивіться [документацію цього проєкту](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md).\n\n## Команди для роботи з реєстрами {#commands-for-working-with-registries}\n\n### Команда `registry` {#the-registry-subcommand}\n\n#### `login`\n\nВхід до реєстру (зручний варіант з ручним введенням пароля)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nВийти з реєстру\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### Команда `push` {#the-push-subcommand}\n\nЗавантажити чарт до реєстру на основі OCI:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nКоманда `push` може використовуватися тільки для `.tgz` файлів, створених заздалегідь за допомогою `helm package`.\n\nПри використанні `helm push` для завантаження чарту до реєстру OCI, посилання має починатися з `oci://` і не повинно містити базове імʼя або теґ.\n\nБазове імʼя посилання на реєстр визначається з імені чарту, а теґ визначається з семантичної версії чарту. Це наразі є строгими вимогами.\n\nДеякі реєстри вимагають, щоб репозиторій та/або простір імен (якщо вказано) були створені заздалегідь. В іншому випадку під час операції `helm push` буде згенеровано помилку.\n\nЯкщо ви створили [файл походження](/topics/provenance.md) (`.prov`), і він присутній поруч з файлом чарту `.tgz`, він автоматично буде завантажено до реєстру при виконанні `push`. Це призводить до появи додаткового шару у [маніфесті Helm chart](#helm-chart-manifest).\n\nКористувачі втулка [helm-push](https://github.com/chartmuseum/helm-push) (для завантаження chart до [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) можуть стикатися з проблемами, оскільки втулок конфліктує з новою вбудованою командою `push`. З версії v0.10.0 втулок був перейменований на `cm-push`.\n\n### Інші підкоманди {#other-subcommands}\n\nПідтримка протоколу `oci://` також доступна в різних інших підкомандах. Ось повний список:\n\n- `helm pull`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nБазове імʼя (імʼя chart) посилання на реєстр *включено* для будь-якого типу дії, що стосується завантаження chart (на відміну від `helm push`, де воно пропущене).\n\nОсь кілька прикладів використання наведених вище підкоманд для chart на основі OCI:\n\n```shell\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Вказання залежностей {#specifying-dependencies}\n\nЗалежності chart можна завантажити з реєстру за допомогою підкоманди `dependency update`.\n\n`repository` для певного запису в `Chart.yaml` вказується як посилання на реєстр без базового імені:\n\n```yaml\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\n\nЦе завантажить `oci://localhost:5000/myrepo/mychart:2.7.0`, коли виконується `dependency update`.\n\n## Маніфест Helm чарту {#helm-chart-manifest}\n\nПриклад маніфесту Helm чарту, представленого в реєстрі (зверніть увагу на поля `mediaType`):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nНаступний приклад містить [файл походження](/topics/provenance.md) (зверніть увагу на додатковий шар):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Міграція з репозиторіїв чартів\n\nМіграція з класичних [репозиторіїв чартів](/topics/chart_repository.md)\n(репозиторії на основі index.yaml) є простою: використовуйте `helm pull`, а потім `helm push`, щоб завантажити отримані файли `.tgz` до реєстру.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: Міграція з Helm v2 на Helm v3\ndescription: Дізнайтеся, як мігрувати з Helm v2 на v3.\nsidebar_position: 13\n---\n\nЦей посібник показує, як мігрувати з Helm v2 на Helm v3. Для цього необхідно мати встановлений Helm v2, який управляє релізами в одному або кількох кластерах.\n\n## Огляд змін у Helm 3 {#overview-of-helm-3-changes}\n\nПовний список змін між Helm 2 і 3 задокументований у [розділі FAQ](/faq/changes_since_helm2.md). Ось деякі з основних змін, про які слід знати перед і під час міграції:\n\n1. Видалення Tiller:\n   - Заміна архітектури клієнт/сервер на клієнт/бібліотека (тільки бінарний файл `helm`)\n   - Безпека тепер залежить від користувача (делеговано безпеці кластера Kubernetes)\n   - Релізи тепер зберігаються як секрети в кластері, а метадані обʼєкта релізу змінилися\n   - Релізи зберігаються на основі простору імен релізу, а не в просторі імен Tiller\n\n2. Оновлено репозиторій чартів:\n   - `helm search` тепер підтримує як локальні запити в репозиторії, так і запити до Artifact Hub\n\n3. Зміни у `apiVersion` чарту:\n   - Динамічно підключені залежності чартів переміщені до `Chart.yaml` (`requirements.yaml` видалено і requirements --> dependencies)\n   - Тепер можна додавати бібліотечні чарти (helper/common charts) як динамічно підключені залежності\n   - Чарти мають поле метаданих `type`, яке визначає, чи є чарт `application` чи `library`. Стандартно це `application`, що означає, що його можна рендерити та інсталювати\n   - Чарти Helm 2 (apiVersion=v1) все ще можна встановлювати\n\n4. Додано специфікацію теки XDG:\n   - Домівка Helm видалена і замінена специфікацією теки XDG для зберігання конфігураційних файлів\n   - Більше не потрібно ініціалізувати Helm\n   - `helm init` і `helm home` видалені\n\n5. Додаткові зміни:\n   - Установка/налаштування Helm спрощено:\n     - Тільки клієнт Helm (бінарний файл helm) (без Tiller)\n     - Парадигма \"run-as-is\"\n   - `local` або `stable` репозиторії стандартно не налаштовані\n   - Хук `crd-install` видалено і замінено на теку `crds` у чарті, де всі CRD, визначені в ній, будуть встановлені перед будь-яким рендерингом чарту\n   - Значення анотації хука `test-failure` видалене, а `test-success` застаріле. Використовуйте `test` замість\n   - Команди видалені/замінені/додані:\n       - delete --> uninstall : стандартно видаляє всю історію релізів за (раніше потрібно було `--purge`)\n       - fetch --> pull\n       - home (видалено)\n       - init (видалено)\n       - install: вимагає імʼя релізу або аргумент `--generate-name`\n       - inspect --> show\n       - reset (видалено)\n       - serve (видалено)\n       - template: аргумент `-x`/`--execute` перейменовано на `-s`/`--show-only`\n       - upgrade: Додано аргумент `--history-max`, який обмежує максимальну кількість збережених ревізій на реліз (0 - без обмежень)\n   - Бібліотека Helm 3 на Go зазнала значних змін і несумісна з бібліотекою Helm 2\n   - Бінарники Helm тепер розміщені на `get.helm.sh`\n\n## Сценарії міграції {#migration-use-cases}\n\nСценарії міграції такі:\n\n1. Helm v2 і v3 управляють одним кластером:\n   - Цей сценарій рекомендується тільки якщо ви плануєте поступове видалення Helm v2 і не потребуєте v3 для управління жодними релізами, розгорнутими v2. Усі нові релізи, що розгортаються, повинні виконуватися v3, а наявні релізи, розгорнуті v2, оновлюються/видаляються тільки v2\n   - Helm v2 і v3 можуть без проблем управляти одним кластером. Версії Helm можуть бути встановлені на одній або окремих системах\n   - Якщо ви встановлюєте Helm v3 на тій же системі, вам потрібно виконати додатковий крок, щоб обидві версії клієнтів могли співіснувати до того часу, поки ви не будете готові видалити клієнта Helm v2. Перейменуйте або помістіть бінарний файл Helm v3 в іншу теку, щоб уникнути конфліктів\n   - Інакше немає конфліктів між обома версіями через наступні відмінності:\n     - зберігання релізів (історії) v2 і v3 є незалежним один від одного. Зміни включають ресурс Kubernetes для зберігання та метадані обʼєкта релізу, що містяться в ресурсі. Релізи також будуть в просторі імен користувача, а не в просторі імен Tiller (наприклад, простір імен Tiller стандартно kube-system v2). v2 використовує \"ConfigMaps\" або \"Secrets\" у просторі імен Tiller і `TILLER` ownership. v3 використовує \"Secrets\" у просторі імен користувача і `helm` ownership. Релізи є інкрементальними в обох версіях v2 і v3\n     - Єдина проблема може бути, якщо ресурси кластера Kubernetes (наприклад, `clusterroles.rbac`) визначені в чарті. Розгортання v3 тоді буде невдалим, навіть якщо унікальне в просторі імен, оскільки ресурси будуть конфліктувати\n     - Конфігурація v3 більше не використовує `$HELM_HOME` і використовує специфікацію теки XDG замість цього. Вона також створюється на льоту за необхідності. Тому вона є незалежною від конфігурації v2. Це стосується тільки випадків, коли обидві версії встановлені на одній системі\n\n2. Міграція з Helm v2 на Helm v3:\n   - Цей сценарій застосовується, коли ви хочете, щоб Helm v3 управляв наявними релізами Helm v2\n   - Слід зазначити, що клієнт Helm v2:\n     - може управляти одним або кількома кластерами Kubernetes\n     - може підключатися до одного або кількох екземплярів Tiller для кластера\n   - Це означає, що ви повинні бути обізнані про це під час міграції, оскільки релізи розгортаються в кластери Tiller і його простір імен. Тому ви повинні бути обізнані про міграцію для кожного кластера та кожного екземпляра Tiller, який управляється екземпляром клієнта Helm v2\n   - Рекомендований шлях міграції даних такий:\n     1. Резервне копіювання даних v2\n     2. Міграція конфігурації Helm v2\n     3. Міграція релізів Helm v2\n     4. Коли ви впевнені, що Helm v3 управляє всіма даними Helm v2 (для всіх кластерів і екземплярів Tiller клієнта Helm v2) як очікується, очистіть дані Helm v2\n   - Процес міграції автоматизований втулком Helm v3 [2to3](https://github.com/helm/helm-2to3)\n\n## Посилання {#references}\n\n   - Втулок Helm v3 [2to3](https://github.com/helm/helm-2to3)\n   - [Блог пост](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) з поясненням використання втулка `2to3` з прикладами\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: Політика підтримки версій Helm\ndescription: Описує політику випуску патчів Helm, а також максимальну підтримувану різницю версій між Helm і Kubernetes.\nsidebar_position: 15\n---\n\nЦей документ описує максимальну підтримувану різницю версій між Helm і Kubernetes.\n\n## Підтримувані версії {#supported-versions}\n\nВерсії Helm виражаються у форматі `x.y.z`, де `x` — це основна версія, `y` — це мінорна версія, а `z` — це версія патчу, відповідно до [семантичного версіювання](https://semver.org/spec/v2.0.0.html).\n\nПроєкт Helm підтримує релізну гілку для останнього мінорного випуску. Застосовні виправлення, включаючи виправлення безпеки, додаються в релізну гілку залежно від їх серйозності та можливості впровадження. Більше деталей можна знайти в [політиці випусків Helm](/community/release_policy).\n\n## Підтримувана різниця версій {#supported-version-skew}\n\nКоли випускається нова версія Helm, вона компілюється з певною мінорною версією Kubernetes. Наприклад, Helm 3.0.0 взаємодіє з Kubernetes, використовуючи клієнт Kubernetes версії 1.16.2, тому він сумісний з Kubernetes 1.16.\n\nПочинаючи з Helm 3, вважається, що Helm сумісний з версіями Kubernetes до `n-3` відносно версії, з якою він був скомпільований. Через зміни в Kubernetes між мінорними версіями, політика підтримки Helm 2 є трохи більш суворою і передбачає сумісність з версіями Kubernetes до `n-1`.\n\nНаприклад, якщо ви використовуєте версію 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.\n\nНе рекомендується використовувати Helm з версією Kubernetes, яка є новішою за ту, з якою він був скомпільований, оскільки Helm не гарантує зворотної сумісності.\n\nЯкщо ви вирішите використовувати Helm з версією Kubernetes, яку він не підтримує, ви робите це на свій ризик.\n\nБудь ласка, зверніться до таблиці нижче, щоб визначити, яка версія Helm сумісна з вашим кластером.\n\n| Версія Helm | Підтримувані версії Kubernetes |\n|--------------|-------------------------------|\n| 3.19.x       | 1.34.x - 1.31.x               |\n| 3.18.x       | 1.33.x - 1.30.x               |\n| 3.17.x       | 1.32.x - 1.29.x               |\n| 3.16.x       | 1.31.x - 1.28.x               |\n| 3.15.x       | 1.30.x - 1.27.x               |\n| 3.14.x       | 1.29.x - 1.26.x               |\n| 3.13.x       | 1.28.x - 1.25.x               |\n| 3.12.x       | 1.27.x - 1.24.x               |\n| 3.11.x       | 1.26.x - 1.23.x               |\n| 3.10.x       | 1.25.x - 1.22.x               |\n| 3.9.x        | 1.24.x - 1.21.x               |\n| 3.8.x        | 1.23.x - 1.20.x               |\n| 3.7.x        | 1.22.x - 1.19.x               |\n| 3.6.x        | 1.21.x - 1.18.x               |\n| 3.5.x        | 1.20.x - 1.17.x               |\n| 3.4.x        | 1.19.x - 1.16.x               |\n| 3.3.x        | 1.18.x - 1.15.x               |\n| 3.2.x        | 1.18.x - 1.15.x               |\n| 3.1.x        | 1.17.x - 1.14.x               |\n| 3.0.x        | 1.16.x - 1.13.x               |\n| 2.16.x       | 1.16.x - 1.15.x               |\n| 2.15.x       | 1.15.x - 1.14.x               |\n| 2.14.x       | 1.14.x - 1.13.x               |\n| 2.13.x       | 1.13.x - 1.12.x               |\n| 2.12.x       | 1.12.x - 1.11.x               |\n| 2.11.x       | 1.11.x - 1.10.x               |\n| 2.10.x       | 1.10.x - 1.9.x                |\n| 2.9.x        | 1.10.x - 1.9.x                |\n| 2.8.x        | 1.9.x - 1.8.x                 |\n| 2.7.x        | 1.8.x - 1.7.x                 |\n| 2.6.x        | 1.7.x - 1.6.x                 |\n| 2.5.x        | 1.6.x - 1.5.x                 |\n| 2.4.x        | 1.6.x - 1.5.x                 |\n| 2.3.x        | 1.5.x - 1.4.x                 |\n| 2.2.x        | 1.5.x - 1.4.x                 |\n| 2.1.x        | 1.5.x - 1.4.x                 |\n| 2.0.x        | 1.4.x - 1.3.x                 |\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"Вступ\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"Як робити\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"Теми\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"Найкращі практики\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"Посібник з шаблонів чартів\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Команди Helm\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"Спільнота\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"Часті питання\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/MAINTAINERS.md",
    "content": "---\ntitle: Мейнтейнери Helm Org\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/MAINTAINERS.md\n-->\n\n* [Karen Chu](https://github.com/karenhchu)\n* [Matt Butcher](https://github.com/technosophos) (голова)\n* [Matt Farina](https://github.com/mattfarina)\n* [Reinhard Nägele](https://github.com/unguiculus)\n* [Scott Rigby](https://github.com/scottrigby)\n\n## Почесні {#emeritus}\n\n* [Adam Reese](https://github.com/adamreese)\n* [Adnan Abdulhussein](https://github.com/prydonius)\n* [Josh Dolitsky](https://github.com/jdolitsky)\n* [Martin Hickey](https://github.com/hickeyma)\n* [Matt Fisher](https://github.com/bacongobbler)\n* [Vic Iglesias](https://github.com/viglesiasce)\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/README.md",
    "content": "---\nsidebar_position: 1\ntitle: Спільнота Helm\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/README.md\n-->\n\nЛаскаво просимо до спільноти Helm!\n\nЦе відправна точка для того, щоб стати учасником проєкту Helm — вдосконалювати документацію, покращувати код, виступати з доповідями тощо.\n\n## Комунікація {#communicating}\n\nНа сторінці [комунікація](communication.md) перелічено канали комунікації, такі як чат, тікети, списки розсилки, зустрічі, конференції тощо.\n\n## Ресурси {#assets}\n\n- Логотипи Helm знаходяться за адресою [cncf/artwork](https://github.com/cncf/artwork/blob/master/examples/graduated.md#helm-logos)\n- Веб-сайт та документація Helm знаходяться за адресою [helm/helm-www](https://github.com/helm/helm-www)\n- Приклади та рекомендації щодо використання бренду Helm: [art](/community/art)\n- Шаблон презентації на тему Helm: [slides](https://github.com/helm/community/tree/main/slides)\n\n## Як я можу допомогти? {#how-can-i-help}\n\n#### Спочатку вам слід приєднатися до наших комунікаційних форумів: {#first-you-should-join-our-communication-forums}\n\n- Слідкуйте за нами на [Twitter](communication.md#social-media)\n- Приєднуйтесь до нас в [Slack](communication.md#slack)\n- Підпишіться на наші [списки розсилки](communication.md#mailing-lists)\n- Приєднуйтесь до [щотижневих зустрічей](communication.md#meetings)\n\n#### Далі, налаштуйте основи (якщо ви цього ще не зробили): {#next-get-set-up-with-the-basics-if-not-already-done-so}\n\n- [Документація](/docs/)\n- [Тікети](https://github.com/helm/helm/issues)\n- [PR](https://github.com/helm/helm/pulls)\n- [Як розпочати](/docs/intro/quickstart/)\n- [Посібник для розробників](./developers.md)\n\nТепер ви можете приступити до справи!\n\nХороший спосіб навчитися:\n\n- Перегляньте код і ознайомтеся з рецензіями коду. Документація та тести є частиною кодової бази.\n- Спробуйте відтворити проблеми та отримайте загальне уявлення про проблеми користувачів.\n- Поспілкуйтеся з людьми в Slack і поставте питання.\n\nОбласті, з яких можна почати роботу:\n\n- Документація (така як текст, який ви зараз читаєте) завжди може бути покращена!\n- Ми завжди можемо розширити тестове покриття.\n- Перегляньте відкриті PR. Додайте коментарі, відгуки або дайте LGTM!\n- Спробуйте виправити деякі прості баги, які можуть бути позначені теґом [good first issue][]\n- Просто попросіть [власників][owner] про пропозиції.\n\n#### І наостанок, ми дуже хотіли б дізнатися, що ви хочете бачити на [блозі Helm](/blog/). {#last-but-not-least-wed-love-to-know-what-you-want-to-see-on-the-helm-blog}\n\nНе соромтеся надсилати теми для блогу [тут](blog-topics.md).\n\n## Ваш перший внесок {#your-first-contribution}\n\nМи рекомендуємо вам попрацювати над наявними [проблемами][issues], перш ніж намагатися розробити нову функцію.\n\nЗнайдіть наявну проблему (наприклад, позначену як [good first issue], або просто попросіть [власників][owner] про пропозиції)\nі дайте відповідь у темі проблеми, висловивши зацікавленість у роботі над нею.\n\nЦе допоможе іншим людям дізнатися, що проблема є актуальною, і, сподіваємося, запобіжить дублюванню зусиль.\n\nКожен комміт повинен бути підписаний в git, як описано в\n[статті](/blog/helm-dco/),\n що описує перехід Helm на DCO.\n\nЯкщо ви хочете працювати з новою ідеєю відносно невеликого обсягу:\n\n  1. Подайте запит із описом запропонованих змін до відповідного репозиторію.\n  2. Власники репозиторію оперативно відреагують на ваш запит.\n  3. Якщо запропоновані зміни будуть прийняті, почніть роботу у своєму форку, підписуючи кожен комміт, як описано вище.\n  4. Надішліть [pull request][], що містить перевірені зміни.\n\n[good first issue]: https://github.com/helm/helm/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3A%22good+first+issue%22\n[issues]: https://github.com/helm/helm/issues\n[pull request]: https://github.com/helm/helm/blob/main/CONTRIBUTING.md#pull-requests\n[owner]: https://github.com/kubernetes/helm/blob/main/OWNERS\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/code-of-conduct.md",
    "content": "---\ntitle: Кодекс поведінки спільноти\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/code-of-conduct.md\n-->\n\nHelm дотримується [Кодексу поведінки CNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/communication.md",
    "content": "---\ntitle: Комунікація\n---\n\n<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: https://github.com/helm/community/blob/main/communication.md\n-->\n\nСпільнота Helm дотримується [Кодексу поведінки CNCF][CNCF code of conduct]. Ось витяг з нього:\n\n> _Як учасники та мейнтейнери цього проєкту, а також з метою сприяння розвитку відкритої та дружньої спільноти, ми зобовʼязуємося поважати всіх людей, які роблять свій внесок, повідомляючи про проблеми, публікуючи запити на нові функції, оновлюючи документацію, надсилаючи запити на виправлення або патчі, а також здійснюючи інші дії._\n\n## Соціальні мережі {#social-media}\n\n* [Twitter]\n* Ставте питання та допомагайте відповідати на них у [Slack] або [Stack Overflow].\n\n## Slack\n\nВи можете [запросити запрошення до Kubernetes Slack](https://slack.kubernetes.io/).\n\nБільшість дискусій у реальному часі відбувається в [#helm-users](https://kubernetes.slack.com/messages/C0NH30761) та [#charts](https://kubernetes.slack.com/messages/C6E3XH1ED).\n\nТакож є канал [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG) для обговорення розвитку Helm.\n\n## Тікети {#issues}\n\nТікети використовуються як основний метод відстеження всього, що стосується проєкту Helm.\n\nДивіться [посібник для учасників](https://github.com/kubernetes/helm/blob/main/CONTRIBUTING.md#issues) для отримання інформації про те, як [створити тікет][file an issue], якщо ви вважаєте, що знайшли помилку або маєте пропозицію щодо нової функції.\n\n## Списки розсилки {#mailing-lists}\n\nОголошення про розробку та обговорення зʼявляються у списку розсилки Helm [cncf-helm] (надсилайте листи на адресу `cncf-helm@lists.cncf.io`).\n\n## Зустрічі {#meetings}\n\nСпільнота 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).\n\nКожен четвер о 9:30 за тихоокеанським часом США ми проводимо [щотижневу нараду з питань розвитку], на яку запрошуються всі бажаючі.\n\nПереведіть це на ваш місцевий час за допомогою цієї [таблиці часових поясів][timezone table].\n\nМи ведемо нотатки з кожної зустрічі в цьому [документі](https://docs.google.com/document/d/1d-6xJEx0C78csIYSPKJzRPeWaHG_8W1Hjl72OJggwdc/edit?usp=sharing), де містяться підсумки нарад, обговорень та заходів, що необхідно вжити.\n\nВідео доступні в [плейлисті зустрічей спільноти Helm][Helm Community Meetings playlist].\n\n## Конференції {#conferences}\n\nHelm є одним із проектів, представлених на CloudNativeCon/KubeCon, що проводиться тричі на рік в Європі, Азії та Північній Америці. Інформація про ці та інші події спільноти доступна на сторінках [подій][events] CNCF.\n\nКрім того, спільнота Helm організовує захід, присвячений Helm, — [Helm Summit], перший з яких відбувся в Портленді, штат Орегон, у лютому 2018 року, [другий](https://events19.linuxfoundation.org/events/helm-summit-2019/) — в Європі (Амстердам, Нідерланди) 11-12 вересня 2019 року.\n\n[CNCF code of conduct]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md\n[cncf-helm]: https://lists.cncf.io/g/cncf-helm/topics\n[events]: https://www.cncf.io/events/\n[file an issue]: https://github.com/helm/helm/issues/new\n[kubernetes-sig-apps]: https://groups.google.com/forum/#!forum/kubernetes-sig-apps\n[Slack]: https://kubernetes.slack.com\n[Helm Summit]: https://helmsummitpdx-feb2018.splashthat.com/\n[Stack Overflow]: https://stackoverflow.com/questions/tagged/kubernetes-helm\n[timezone table]: https://www.google.com/search?q=0930+am+in+pst\n[Twitter]: https://twitter.com/helmpack\n[weekly development meeting]: https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09\n[Helm Community Meetings playlist]: https://www.youtube.com/playlist?list=PLVt9l4b66d5EY5Xs9OVJgvO5ss9WzrSY0\n[SIGs]: https://github.com/kubernetes/community/blob/master/sig-list.md\n[SIG-Apps]: https://github.com/kubernetes/community/tree/master/sig-apps\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/developers.md",
    "content": "---\ntitle: Посібник для розробників\ndescription: Інструкції щодо налаштування середовища для розробки Helm.\nsidebar_position: 2\n---\n\nЦей посібник пояснює, як налаштувати ваше середовище для розробки на Helm.\n\n## Попередні умови {#prerequisites}\n\n- Остання версія Go\n- Кластер Kubernetes з kubectl (необовʼязково)\n- Git\n\n## Збирання Helm {#building-helm}\n\nМи використовуємо Make для компіляції наших програм. Найпростіший спосіб почати:\n\n```console\n$ make\n```\n\nЯкщо потрібно, спочатку будуть встановлені залежності та перевірена конфігурація. Потім буде скомпільовано `helm` і розміщено у `bin/helm`.\n\nЩоб запустити Helm локально, ви можете запустити `bin/helm`.\n\n- Helm відомий тим, що працює на macOS та більшості дистрибутивів Linux, включаючи Alpine.\n\n## Запуск тестів {#running-tests}\n\nЩоб запустити всі тести, виконайте `make test`. Перед цим вам потрібно мати встановлений [golangci-lint](https://golangci-lint.run).\n\n## Запуск локально {#running-locally}\n\nВи можете оновити ваш шлях і додати шлях до локального виконуваного файлу Helm. В редакторі відкрийте файл конфігурації вашої оболонки. Додайте наступний рядок, замінивши `<path to your binary folder>` на шлях до вашої локальної теки `bin`.\n\n``` bash\nexport PATH=\"<path to your binary folder>:$PATH\"\n```\n\nЦе дозволить вам запускати локально створену версію Helm з вашого термінала.\n\n## Настанови щодо участі {#contribution-guidelines}\n\nМи раді вашій участі. Цей проєкт має деякі настанови, щоб забезпечити (а) високу якість коду, (б) послідовність проєкту, і (в) відповідність юридичним вимогам проєктів з відкритими сирцями. Наша мета не обтяжувати учасників, а побудувати елегантний та якісний відкритий код, щоб наші користувачі отримали користь.\n\nПереконайтеся, що ви прочитали та зрозуміли основний посібник щодо участі:\n\n<https://github.com/helm/helm/blob/main/CONTRIBUTING.md>\n\n### Структура коду {#structure-of-the-code}\n\nКод проєкту Helm організовано наступним чином:\n\n- Окремі програми знаходяться в `cmd/`. Код всередині `cmd/` не призначений для повторного використання у вигляді бібліотек.\n- Спільні бібліотеки зберігаються в `pkg/`.\n- Тека `scripts/` містить кілька скриптів утиліт. Більшість з них використовується конвеєром CI/CD.\n\nУправління залежностями Go змінюється, і, ймовірно, змінюватиметься протягом життєвого циклу Helm. Ми рекомендуємо розробникам _не_ намагатися вручну управляти залежностями. Натомість ми радимо покладатися на `Makefile` проєкту для цього. З Helm 3 рекомендується використовувати версію Go 1.13 або новішу.\n\n### Написання документації {#writing-documentation}\n\nЗ Helm 3 документація була перенесена в окремий репозиторій. При створені нових функцій, будь ласка, зробіть супутню документацію та надішліть її до репозиторію [helm-www](https://github.com/helm/helm-www).\n\nЄдине виключення: [вивід CLI Helm (англійською)](/docs/helm) генерується безпосередньо з бінарного файлу `helm`. Дивіться [Оновлення довідкових документів CLI Helm](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs) для інструкцій, як згенерувати цей вивід. Після перекладу, вивід CLI не генерується і може бути знайдений у `/content/<lang>/docs/helm`.\n\n### Домовленості Git {#git-conventions}\n\nМи використовуємо Git як нашу систему контролю версій. Гілка `main` є домом для поточного кандидата в розробці. Релізи позначаються теґами.\n\nМи приймаємо зміни до коду через Pull Requests (PRs) на GitHub. Робочий процес виглядає наступним чином:\n\n1. Зробіть форк репозиторія `github.com/helm/helm` у ваш обліковий запис GitHub\n2. Зробіть `git clone` цього форку у бажану локальну теку\n3. Створіть нову робочу гілку (`git checkout -b feat/my-feature`) і працюйте з цією гілкою.\n4. Коли ви будете готові до рецензування, залийте вашу гілку на GitHub, а потім відкрийте новий pull request в нашому репо.\n\nДля опису змін в комітах Git ми дотримуємося [Semantic Commit Messages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html):\n\n```commit\nfix(helm): add --foo flag to 'helm install'\n\nWhen 'helm install --foo bar' is run, this will print \"foo\" in the\noutput regardless of the outcome of the installation.\n\nCloses #1234\n```\n\nЗвичайні типи комітів:\n\n- fix: Fix a bug or error\n- feat: Add a new feature\n- docs: Change documentation\n- test: Improve testing\n- ref: refactor existing code\n\nЗвичайні області:\n\n- helm: CLI Helm\n- pkg/lint: Пакет lint. Дотримуйтеся аналогічної конвенції для будь-якого пакету\n- `*`: дві або більше областей\n\nДізнатись більше:\n\n- [Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md) були прикладом для цього розділу.\n- Karma Runner [визначає](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) ідею семантичного повідомлення коміту.\n\n### Домовленості Go {#go-conventions}\n\nМи дуже уважно дотримуємося стандартів стилю кодування Go. Зазвичай запуск `go fmt` зробить ваш код красивим для вас.\n\nМи також зазвичай дотримуємося рекомендацій `go lint` та `gometalinter`. Запустіть `make test-style`, щоб переконатися у відповідності стилю.\n\nДізнатись більше:\n\n- Effective Go [представляє форматування](https://golang.org/doc/effective_go.html#formatting).\n- Wiki Go має чудову статтю про [форматування](https://github.com/golang/go/wiki/CodeReviewComments).\n\nЯкщо ви запускаєте `make test`, будуть виконані не тільки юніт-тести, а й тести стилю. Якщо `make test` не пройде, навіть з причин стилю, ваш PR не буде вважатися готовим до злиття.\n\n## Усунення несправностей {#troubleshooting}\n\nЩоб усунути несправності та отримати допомогу від спільноти, знайдіть своє запитання у списку питань із позначкою [`question/support`](https://github.com/helm/helm/issues?q=is%3Aissue%20state%3Aopen%20label%3Aquestion%2Fsupport) у репозиторії Helm.\n\nЯкщо ви не можете знайти тікет, який відповідає вашому запитанню, створіть новий тікет або додайте коментар до відповідного тікету, щоб поділитися своїм досвідом. Для отримання додаткової інформації про участь та пошук тікетів у репозиторії helm див. розділ [Issues](https://github.com/helm/helm/blob/main/CONTRIBUTING.md#issues) у _Настановах щодо участі_.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/history.mdx",
    "content": "---\ntitle: Історія Проєкту\ndescription: Надає загальний огляд історії проєкту.\nsidebar_position: 5\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm є [проєктом](https://www.cncf.io/projects/) під [єгідою CNCF](/blog/celebrating-helms-cncf-graduation/).\n\nHelm почався як те, що тепер відоме як [Helm Classic](https://github.com/helm/helm-classic), проєкт Deis, розпочатий у 2015 році та представлений на перших KubeCon.\n\nУ січні 2016 року проєкт обʼєднався з інструментом GCS під назвою Kubernetes Deployment Manager, і проєкт було переведено під [Kubernetes](https://kubernetes.io). В результаті злиття кодових баз, Helm 2.0 був випущений пізніше того ж року. Ключова особливість Deployment Manager, яка збереглася в Helm 2, — це серверна компонента, перейменована з DM на Tiller для фінального релізу Helm 2.0.\n\nHelm був піднятий з підпроєкту Kubernetes до повноцінного проєкту CNCF у червні 2018 року. Helm сформував орган управління на вищому рівні, і кілька проєктів були інтегровані під парасолею проєкту Helm, включаючи Monocular, Helm Chart Repo, Chart Museum і пізніше Helm Hub.\n\nКоли розпочався цикл розробки Helm 3, Tiller було видалено, що наблизило Helm до його первісного бачення як клієнтського інструменту. Але Helm 3 продовжує відслідковувати релізи всередині кластеру Kubernetes, що дозволяє командам працювати разом над спільним набором релізів Helm. Helm 3 був випущений у листопаді 2019 року.\n\nHelm [випустився як проєкт CNCF у квітні 2020 року](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/).\n\n[CNCF Artifact Hub](https://artifacthub.io) замінив [Helm Hub](https://hub.helm.sh) у жовтні 2020 року.\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/localization.md",
    "content": "---\ntitle: Локалізація документації Helm\ndescription: Інструкції для локалізації документації Helm.\nsidebar_position: 6\n---\n\nЦей посібник пояснює, як локалізувати документацію Helm.\n\n## Початок роботи {#getting-started}\n\nВнесення змін у переклади використовує той самий процес, що й внесення змін у документацію. Переклади подаються через [пул-реквести](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) до репозиторію [helm-www](https://github.com/helm/helm-www), і пул-реквести перевіряються командою, яка управляє вебсайтом.\n\n### Дволітерний код мови {#two-letter-language-code}\n\nДокументація організована відповідно до стандарту [ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php) для мовних кодів. Наприклад, дволітерний код для корейської мови — `ko`, української — `uk`.\n\nУ контенті та конфігураціях ви знайдете використовувані мовні коди. Ось 3 приклади:\n\n- У теці `i18n` є підтеки для кожного коду мови. Локалізований вміст для мови знаходиться в кожній підтеці.\n- Локалізований вміст у кожній\n- Для кожної мови існує файл `code.json` з фразами, що використовуються на веб-сайті.\n\nАнглійська мова з кодом мови `en` є основною мовою та джерелом для перекладів.\n\n### Форк, Гілка, Зміна, Пул-Реквест {#fork-branch-change-pull-request}\n\nЩоб зробити переклад, почніть зі [створення форку](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) репозиторію [helm-www](https://github.com/helm/helm-www) на GitHub. Ви почнете з внесення змін у вашому форку.\n\nСтандартно ваш форк буде налаштовано на роботу з основною гілкою, відомою як `main`. Будь ласка, використовуйте гілки для розробки ваших змін та створення пул-реквестів. Якщо ви не знайомі з гілками, ви можете [прочитати про них у документації GitHub](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches).\n\nКоли у вас зʼявиться гілка, внесіть зміни для додавання перекладів та локалізації контенту потрібною мовою.\n\nЗверніть увагу, що 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).\n\nКоли ви будете готові, створіть [пул-реквест](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) з перекладом назад до репозиторію helm-www.\n\nПісля створення пул-реквесту один з підтримувачів перевірить його. Деталі цього процесу можна знайти у файлі [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md).\n\n## Переклад Контенту {#translating-content}\n\nЛокалізація всього вмісту Helm — це велике завдання. Можна почати з малого. Згодом переклади можна розширювати.\n\nНижче описано файли/теки, які використовуються для перекладу вмісту документів, вмісту блогу та елементів сайту в документації Helm:\n\n- `i18n/<language-code>` тека:\n  - `code.json` використовується для перекладу коду React на сайті (включно з лендінгом)\n  - `i18n/<language-code>/docusaurus-plugin-content-blog` тека з перекладами блогу\n  - `i18n/<language-code>/docusaurus-plugin-content-docs` тека з:\n  - Теки версій для перекладів вмісту документації (наприклад, `i18n/<код мови>/docusaurus-plugin-content-docs/version-3/`)\n- JSON-файли для кожної версії документації з перекладами категорій у бічній панелі (наприклад, `current.json`, `version-3.json` тощо)\n  - Тека `i18n/docusaurus-theme-classic` з файлами `footer.json` та `navbar.json` для перекладу тексту в навігаційній панелі та нижньому колонтитулі сайту\n- Ключі `i18n` у файлі `docusaurus.config.js` містять перелік усіх локалей та опції конфігурації для меню локалей у навігаційній панелі сайту\n\nДля отримання додаткової інформації див. [i18n - Вступ](https://docusaurus.io/docs/i18n/introduction) у документації Docusaurus.\n\n### Початок роботи з новою мовою {#starting-a-new-language}\n\nПосібник, який допоможе вам перекласти вміст сайту, див. [i18n - Tutorial](https://docusaurus.io/docs/i18n/tutorial) у документації Docusaurus.\n\nЩоб почати роботу з новою мовою:\n\n1. Якщо ви ще цього не зробили, встановіть залежності:\n\n   ```sh\n   yarn install --frozen-lockfile\n   ```\n\n1. Запустіть команду Docusaurus `write-translations`. Наприклад, щоб додати локаль `fr` (французька): `yarn write-translations -- --locale fr`. Це створить необхідну структуру текстових файлів для мови та ініціалізує файли перекладу JSON, необхідні для перекладу елементів сайту, таких як навігаційна панель, нижній колонтитул, цільова сторінка та бічна панель.\n\n    ```sh\n    yarn write-translations --locale <language-code>\n    ```\n\n1. Виконайте мінімальні переклади для нової мови:\n   1. Перекладіть файл `code.json`.\n   1. У теці `i18n/docusaurus-theme-classic` перекладіть файли `footer.json` та `navbar.json`.\n   1. У файлі `docusaurus-plugin-content-blog/options.json` перекладіть елементи блогу у файлі `options.json`.\n1. Додайте мову до ключа `i18n` файлу `docusaurus.config.js`, щоб вона зʼявилася у меню навігаційної панелі:\n\n    ```yaml\n    i18n: {\n      defaultLocale: 'en',\n      # додайте нову мову до цього списку локалей\n      locales: ['en', 'de', 'es', 'fr', 'gr', 'ja', 'ko', 'pt', 'ru', 'uk', 'zh'],\n      localeConfigs: {\n        en: {\n          htmlLang: 'en-us',\n          label: 'English',\n        },\n        de: {\n          label: 'Deutsch',\n        },\n      # new_lang {\n      #   label: 'Navbar label',\n      # }\n      },\n    },\n    ```\n\n1. (Опціонально) Перекладіть документи або вміст блогу. Див. розділ «Переклад» нижче.\n1. Перевірте зміни, запустивши локалізований сайт у режимі розробки, вказавши локаль:\n\n   ```sh\n   yarn start --locale fr\n   ```\n\n   :::note\n   Кожна локаль є окремою самостійним односторінковим застосунком. Ви можете переглянути лише одну локаль за раз. Неможливо переглянути всі локалі одночасно.\n   :::\n\n### Переклад {#translating}\n\nПерш ніж перекладати вміст документів, ознайомтеся з наступними рекомендаціями та вказівками:\n\n* У процесі перекладу можуть допомогти інструменти перекладу. До них належать і машинні переклади. Машинні переклади перед публікацією повинні бути відредаговані або перевірені носієм мови на предмет граматики та змісту.\n* Не додавайте неперекладену копію англійського файлу до `i18n/[LANG]/plugin-content-docs` або `i18n/[LANG]/plugin-content-blog`. Після того, як мова зʼявиться на сайті, будь-які неперекладені сторінки автоматично перенаправлятимуться на англійську. Переклад займає час, і ви завжди варто перекладати найактуальнішу версію документів, а не застарілу гілку.\n* Переконайтеся, що ви видалили всі рядки `aliases` із розділу заголовка. Рядок на зразок `aliases: [\"/docs/using_helm/\"]` не належить до перекладів. Це перенаправлення для старих посилань, які не існують для нових сторінок.\n* Додайте ідентифікатори анкорів до будь-яких заголовків, використовуючи формат `## Приклад заголовка {#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`.\n\nЩоб перекласти документи та вміст блогу:\n\n1. Переконайтеся, що цільова локаль існує в теці `i18n`. Якщо її немає, див. розділ «Початок роботи з новою мовою» вище.\n1. Скопіюйте один або кілька файлів markdown, які ви хочете перекласти, з `/docs` або `/versioned_docs` до відповідної папки версії в `i18n/<language-code>/docusaurus-plugin-content-docs`. Наприклад, щоб перекласти `versioned_docs/version-3/example.md` корейською мовою:\n\n   ```sh\n   cp versioned_docs/version-3/topics/example.md i18n/ko/docusaurus-plugin-content-docs/version-3/topics/example.md\n   ```\n\n1. Скопіюйте один або кілька файлів markdown, які ви хочете перекласти, з `/blog` до `i18n/<код мови>/docusaurus-plugin-content-blog`. Наприклад, щоб перекласти `blog/2025-09-09-path-to-helm-v4.md` корейською мовою:\n\n   ```sh\n   cp blog/2025-09-09-path-to-helm-v4.md i18n/ko/docusaurus-plugin-content-blog/2025-09-09-path-to-helm-v4.md\n   ```\n\n1. Якщо ви ще цього не зробили, встановіть залежності:\n\n   ```sh\n   yarn install --frozen-lockfile\n   ```\n\n1. Перевірте зміни, запустивши локалізований сайт у режимі розробки, вказавши локаль:\n\n   ```sh\n   yarn start --locale ko\n   ```\n\n   :::note\n   Кожна локаль є окремим самостійним односторінковим застосунком. Одночасно можна переглянути лише одну локаль. Неможливо переглянути всі локалі одночасно.\n   :::\n\n## Перехід між мовами {#navigating-between-languages}\n\nКористувачі переходять між мовами за допомогою випадаючого меню локалі в навігаційній панелі сайту.\nКлюч `i18n` у глобальному файлі сайту `docusaurus.config.js` — це місце, де налаштовується навігація між мовами.\nЩоб додати нову мову, додайте локаль, використовуючи [дволітерний\nкод мови](./localization/#two-letter-language-code), визначений вище. Приклад:\n\n```yaml\ni18n: {\n  defaultLocale: 'en',\n  # додайте нову мову до цього списку локалей\n  locales: ['en', 'de', 'es', 'fr', 'gr', 'ja', 'ko', 'pt', 'ru', 'uk', 'zh'],\n  localeConfigs: {\n    en: {\n        htmlLang: 'en-us',\n        label: 'English',\n    },\n    de: {\n        label: 'Deutsch',\n    },\n    # new_lang {\n    #   label: 'Navbar label',\n    # }\n  },\n},\n```\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/related.md",
    "content": "---\ntitle: Повʼязані проєкти та документація\ndescription: сторонні інструменти, втулки та документація, надані спільнотою!\nsidebar_position: 4\n---\n\nСпільнота Helm розробила безліч додаткових інструментів, втулків та документації про Helm. Нам завжди цікаво дізнатися про ці проєкти.\n\nЯкщо у вас є щось, що ви хочете додати до цього списку, будь ласка, відкрийте [issue](https://github.com/helm/helm-www/issues) або [pull request](https://github.com/helm/helm-www/pulls).\n\n## Втулки Helm {#helm-plugins}\n\n- [helm-adopt](https://github.com/HamzaZo/helm-adopt) — Втулок Helm v3 для включення поточних ресурсів k8s у нові згенеровані Helm чарти.\n- [helm-cel](https://github.com/idsulik/helm-cel) — Втулок, який використовує Common Expression Language (CEL) для перевірки значень.\n- [helm-chartsnap](https://github.com/jlandowner/helm-chartsnap) — Втулок для тестування знімків для Helm чартів.\n- [Helm Diff](https://github.com/databus23/helm-diff) — Попередній перегляд `helm upgrade` у вигляді кольорового diff.\n- [Helm Dt](https://github.com/vmware-labs/distribution-tooling-for-helm) — Втулок, який допомагає розподілити Helm чарти між OCI реєстрами та в середовищах Air gap.\n- [Helm Dashboard](https://github.com/komodorio/helm-dashboard) — GUI для Helm, візуалізація релізів та репозиторіїв, відмінності у маніфестах.\n- [helm-gcs](https://github.com/hayorov/helm-gcs) — Втулок для керування репозиторіями на Google Cloud Storage.\n- [helm-git](https://github.com/aslafy-z/helm-git) — Встановлює чарти та отримує файли значень з ваших Git репозиторіїв.\n- [helm-k8comp](https://github.com/cststack/k8comp) — Втулок для створення Helm чартів з hiera за допомогою k8comp.\n- [helm-mapkubeapis](https://github.com/helm/helm-mapkubeapis) — Оновлює метадані релізу Helm для заміни застарілих або видалених API Kubernetes.\n- [helm-migrate-values](https://github.com/OctopusDeployLabs/helm-migrate-values) — Втулок для перенесення вказаних користувачем значень між версіями чартів Helm, щоб впоратися зі змінами схеми у файлі `values.yaml`.\n- [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) — Втулок для моніторингу релізу та відкату на основі запиту Prometheus/ElasticSearch.\n- [helm-release-plugin](https://github.com/JovianX/helm-release-plugin) — Втулок для управління релізами, оновлення значень релізу, витягує (перестворює) Helm чарти з розгорнутих релізів, встановлює TTL релізу Helm.\n- [helm-s3](https://github.com/hypnoglow/helm-s3) — Втулок Helm, який дозволяє використовувати AWS S3 як [приватний] репозиторій чартів.\n- [helm-secrets](https://github.com/jkroepke/helm-secrets) — Втулок для безпечного керування та зберігання секретів (на основі [sops](https://github.com/mozilla/sops)).\n- [helm-sigstore](https://github.com/sigstore/helm-sigstore) — Втулок для Helm для інтеграції з екосистемою [sigstore](https://sigstore.dev/). Пошук, завантаження та перевірка підписаних Helm чартів.\n- [helm-tanka](https://github.com/Duologic/helm-tanka) — Втулок Helm для рендерингу Tanka/Jsonnet всередині Helm чартів.\n- [hc-unit](https://github.com/xchapter7x/hcunit) — Втулок для юніт-тестування чартів локально за допомогою OPA (Open Policy Agent) & Rego.\n- [helm-unittest](https://github.com/helm-unittest/helm-unittest)— Втулок для юніт-тестування чартів локально з YAML.\n- [helm-val](https://github.com/HamzaZo/helm-val) — Втулок для отримання значень з попереднього релізу.\n- [helm-external-val](https://github.com/kuuji/helm-external-val) — Втулок, який отримує значення helm з зовнішніх джерел (configMaps, Secrets тощо).\n- [helm-images](https://github.com/nikhilsbhat/helm-images) — Втулок Helm для отримання всіх можливих зображень з чарту перед розгортанням або з розгорнутого релізу.\n- [helm-drift](https://github.com/nikhilsbhat/helm-drift) — Втулок Helm, який виявляє конфігурацію, яка відрізняється від Helm чарту.\n- [helm-tui](https://github.com/pidanou/helm-tui) — Легкий інтерфейс для управління вашими ресурсами Helm без виходу з терміналу\n\nМи також заохочуємо авторів на GitHub використовувати теґ [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) у своїх репозиторіях втулків.\n\n## Додаткові інструменти {#additional-tools}\n\nІнструменти, які використовуються поверх Helm.\n\n- [Aptakube](https://aptakube.com) — Графічний інтерфейс для керування релізами Helm та Kubernetes.\n- [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) — Керування префіксованими релізами через різні Kubernetes простори імен, а також видалення завершених завдань для складних розгортань.\n- [avionix](https://github.com/zbrookle/avionix) — Інтерфейс Python для генерації Helm чартів та Kubernetes yaml, що дозволяє успадкування та зменшення дублювання коду.\n- [Botkube](https://botkube.io) — Виконання Helm команд безпосередньо з Slack, Discord, Microsoft Teams та Mattermost.\n- [Captain](https://github.com/alauda/captain) — Контролер Helm3, що використовує HelmRequest та Release CRD.\n- [Chartify](https://github.com/appscode/chartify) — Генерація Helm чартів з наявних ресурсів Kubernetes.\n- [ChartMuseum](https://github.com/helm/chartmuseum) — Репозиторій Helm Chart з підтримкою Amazon S3 та Google Cloud Storage.\n- [chart-registry](https://github.com/hangyan/chart-registry) — Хостинг Helm чартів на OCI Registry.\n- [Codefresh](https://codefresh.io) — Кластерна CI/CD платформа з UI панелями для управління Helm чартами та релізами.\n- ⁠[Cyclops](https://cyclops-ui.com) — Динамічний UI для Kubernetes на основі Helm чартів.\n- [Flux](https://fluxcd.io/docs/components/helm/) — Безперервна та прогресивна доставка з Git до Kubernetes.\n- [Helmfile](https://github.com/helmfile/helmfile) — Helmfile - це декларативна специфікація для розгортання Helm чартів.\n- [Helmper](https://github.com/ChristofferNissen/helmper) — Helmper допомагає імплементувати Helm чарти, включаючи всі OCI артефакти (образи) у ваші OCI реєстри. Helmper також полегшує сканування безпеки та застосування патчів до OCI образів. Helmper використовує Helm, Oras, Trivy, Copacetic та Buildkitd.\n- [Helmsman](https://github.com/Praqma/helmsman) — Helmsman, це інструмент helm-charts-as-code, який дозволяє встановлювати/оновлювати/захищати/переміщувати/видаляти релізи з версійно контрольованих файлів стану (описаних у простому форматі TOML).\n- [HULL](https://github.com/vidispine/hull) — Ця бібліотека чартів надає готовий інтерфейс для специфікації всіх обʼєктів Kubernetes безпосередньо у `values.yaml`. Вона усуває необхідність писати будь-які шаблони для ваших чартів і має багато додаткових функцій для спрощення створення та використання Helm чартів.\n- [K8Studio](https://k8studio.io) — Інтерфейс користувача для десктопів для управління кластерами Kubernetes з інтегрованим менеджером Helm.\n- [Konveyor Move2Kube](https://konveyor.io/move2kube/) — Генерація Helm чартів для ваших поточних проєктів.\n- [Landscaper](https://github.com/Eneco/landscaper/) — \"Landscaper бере набір посилань на Helm Chart зі значеннями (бажаний стан) і реалізує їх в кластері Kubernetes.\"\n- [Monocular](https://github.com/helm/monocular) — Веб UI для репозиторіїв Helm Chart.\n- [Monokle](https://monokle.io) — Десктопний інструмент для створення, налагодження та розгортання ресурсів Kubernetes та Helm чартів.\n- [Orkestra](https://azure.github.io/orkestra/) — Хмарна платформа оркестрування релізів та управління життєвим циклом (LCM) для повʼязаних груп Helm релізів та їх субчартів.\n- [Tanka](https://tanka.dev/helm) — Grafana Tanka налаштовує ресурси Kubernetes через Jsonnet з можливістю споживання Helm чартів.\n- [Terraform Helm Provider](https://github.com/hashicorp/terraform-provider-helm) — Провайдер Helm для HashiCorp Terraform дозволяє управління життєвим циклом Helm чартів з декларативним синтаксисом інфраструктури як коду. Провайдер Helm часто поєднується з іншими провайдерами Terraform, такими як провайдер Kubernetes, для створення спільного робочого процесу серед усіх інфраструктурних послуг.\n- [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) — Втулок VIM для Kubernetes та Helm.\n\n## Мають Helm {#helm-included}\n\nПлатформи, дистрибутиви та сервіси, що включають підтримку Helm.\n\n- [Kubernetic](https://kubernetic.com/) — Десктопний клієнт Kubernetes.\n- [Jenkins X](https://jenkins-x.io/) — Відкритий автоматизований CI/CD для Kubernetes, який використовує Helm для [просування](https://jenkins-x.io/docs/getting-started/promotion/) застосунків через середовища за допомогою GitOps.\n\n## Різне {#misc}\n\nКорисні речі для авторів чартів та користувачів Helm.\n\n- [Await](https://github.com/saltside/await) — Docker образ для \"очікування\" різних умов, особливо корисний для init контейнерів. [Детальніше](https://blog.slashdeploy.com/2017/02/16/introducing-await/).\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/release_checklist.md",
    "content": "---\ntitle: Перевірка випуску\ndescription: Чеклист для супровідників при випуску нової версії Helm.\nsidebar_position: 3\n---\n\n# Посібник для супровідників щодо випуску Helm\n\nЧас для нового випуску Helm! Як супровідник Helm, який випускає нову версію, ви є найкращою людиною, щоб оновити цей чеклист випуску у разі, якщо ваш досвід відрізняється від задокументованого тут.\n\nУсі випуски матимуть формат vX.Y.Z, де X — це основний номер версії, Y — це номер мінорної версії, а Z — це номер патч-релізу. Цей проєкт суворо дотримується [семантичного версіювання](https://semver.org/lang/uk/), тому дотримання цього етапу є критично важливим.\n\nHelm заздалегідь оголошує дату свого наступного мінорного випуску. Всі зусилля мають бути спрямовані на дотримання оголошеної дати. Крім того, під час запуску процесу випуску дату наступного випуску має бути обрано, оскільки вона буде використана в процесі випуску.\n\nЦі інструкції охоплюють початкову конфігурацію, а потім процес випуску для трьох різних типів випусків:\n\n* Основні випуски — випускаються рідше, містять кардинальні зміни\n* Мінорні випуски — випускаються кожні 3-4 місяці, не містять кардинальних змін\n* Патч-релізи — випускаються щомісяця, не потребують виконання всіх кроків цього посібника\n\n[Початкова конфігурація](#initial-configuration)\n\n1. [Створення гілки випуску](#1-create-the-release-branch)\n2. [Основні/Мінорні випуски: змініть номер версії в Git](#2-majorminor-releases-change-the-version-number-in-git)\n3. [Основні/Мінорні випуски: зафіксуйте і надішліть гілку випуску](#3-majorminor-releases-commit-and-push-the-release-branch)\n4. [Основні/Мінорні випуски: створіть кандидат у випуск](#4-majorminor-releases-create-a-release-candidate)\n5. [Основні/Мінорні випуски: повторіть на наступних кандидатах у випуск](#5-majorminor-releases-iterate-on-successive-release-candidates)\n6. [Завершення випуску](#6-finalize-the-release)\n7. [Написання приміток до випуску](#7-write-the-release-notes)\n8. [PGP-підписання завантажень](#8-pgp-sign-the-downloads)\n9. [Публікація випуску](#9-publish-release)\n10. [Оновлення документації](#10-update-docs)\n11. [Оповіщення спільноти](#11-tell-the-community)\n\n## Початкова конфігурація {#initial-configuration}\n\n### Налаштування віддаленого репозиторію Git {#set-up-git-remote}\n\nВажливо зазначити, що цей документ передбачає, що віддалений репозиторій у вашій копії, який відповідає <https://github.com/helm/helm>, називається \"upstream\". Якщо це не так (наприклад, якщо ви вирішили назвати його \"origin\" або щось подібне), обовʼязково змініть наведену інформацію відповідно до вашого локального середовища. Якщо ви не впевнені, як називається ваш upstream, використовуйте команду `git remote -v`, щоб дізнатися.\n\nЯкщо у вас немає [upstream remote](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork), ви можете додати його, використовуючи таку команду:\n\n```shell\ngit remote add upstream git@github.com:helm/helm.git\n```\n\n### Налаштування змінних середовища {#set-up-environment-variables}\n\nУ цьому документі також буде використано кілька змінних середовища, які ви можете налаштувати для зручності. Для основних/мінорних випусків використовуйте наступне:\n\n```shell\nexport RELEASE_NAME=vX.Y.0\nexport RELEASE_BRANCH_NAME=\"release-X.Y\"\nexport RELEASE_CANDIDATE_NAME=\"$RELEASE_NAME-rc.1\"\n```\n\nЯкщо ви створюєте патч-реліз, використовуйте наступне:\n\n```shell\nexport PREVIOUS_PATCH_RELEASE=vX.Y.Z\nexport RELEASE_NAME=vX.Y.Z+1\nexport RELEASE_BRANCH_NAME=\"release-X.Y\"\n```\n\n### Налаштування ключа підпису {#set-up-signing-key}\n\nМи також додамо безпеку та перевірку процесу випуску шляхом хешування бінарних файлів і надання файлів підпису. Ми виконуємо це, використовуючи [GitHub та GPG](https://help.github.com/en/articles/about-commit-signature-verification). Якщо у вас ще не налаштовано GPG, ви можете виконати такі кроки:\n\n1. [Встановіть GPG](https://gnupg.org/index.html)\n2. [Згенеруйте GPG ключ](https://help.github.com/en/articles/generating-a-new-gpg-key)\n3. [Додайте ключ до облікового запису GitHub](https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account)\n4. [Налаштуйте ключ підпису в Git](https://help.github.com/en/articles/telling-git-about-your-signing-key)\n\nПісля того, як у вас буде ключ підпису, вам потрібно додати його до файлу KEYS у кореневій теці репозиторію. Інструкції щодо додавання його до файлу KEYS містяться у файлі. Якщо ви ще не зробили цього, вам потрібно додати ваш публічний ключ до мережі keyserver. Якщо ви використовуєте GnuPG, ви можете дотримуватися [інструкцій, наданих Debian](https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver).\n\n## 1. Створення гілки випуску {#1-create-the-release-branch}\n\n### Основні/Мінорні випуски {#majorminor-releases}\n\nОсновні випуски включають нові функції та зміни в поведінці, *які порушують зворотну сумісність*. Мінорні випуски містять нові функції, які не порушують зворотну сумісність. Для створення основного або мінорного випуску почніть зі створення гілки `release-X.Y` від основної гілки (main).\n\n```shell\ngit fetch upstream\ngit checkout upstream/main\ngit checkout -b $RELEASE_BRANCH_NAME\n```\n\nЦя нова гілка буде основою для випуску, в якій ми будемо надалі працювати.\n\nПереконайтеся, що на GitHub існує [віха в helm/helm](https://github.com/helm/helm/milestones) для цього випуску (створіть її, за потреби). Переконайтеся, що PR та issues для цього випуску входять до цього етапу.\n\nДля основних і мінорних випусків переходьте до кроку 2: [Основні/Мінорні випуски: зміна номеру версії в Git](#2-majorminor-releases-change-the-version-number-in-git).\n\n### Патч-релізи {#patch-releases}\n\nПатч-релізи включають кілька критичних виправлень для поточних випусків. Почніть зі створення гілки `release-X.Y`:\n\n```shell\ngit fetch upstream\ngit checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME\n```\n\nЗвідси ми можемо вибрати коміти, які хочемо включити до патч-релізу:\n\n```shell\n# отримуємо ідентифікатори комітів, які хочемо вибрати\ngit log --oneline\n# вибираємо коміти, починаючи з найстарішого, без включення комітів злиття\ngit cherry-pick -x <commit-id>\n```\n\nПісля вибору комітів гілку випуску потрібно надіслати у віддалений репозиторій.\n\n```shell\ngit push upstream $RELEASE_BRANCH_NAME\n```\n\nНадсилання гілки викличе запуск тестів. Переконайтеся, що вони проходять перед створенням теґу. Цей новий теґ стане основою для патч-релізу.\n\nСтворення [віхи в helm/helm](https://github.com/helm/helm/milestones) є необов’язковим для патч-релізів.\n\nОбов’язково перевірте [GitHub Actions](https://github.com/helm/helm/actions), щоб переконатися, що випуск пройшов CI, перш ніж продовжити. Патч-релізи можуть пропустити кроки 2-5 і перейти до кроку 6 для [Завершення випуску](#6-finalize-the-release).\n\n## 2. Основні/Мінорні випуски: Зміна номера версії в Git {#2-majorminor-releases-change-the-version-number-in-git}\n\nПри виконанні основного або мінорного випуску переконайтеся, що оновили файл `internal/version/version.go` з новою версією випуску.\n\n```shell\n$ git diff internal/version/version.go\ndiff --git a/internal/version/version.go b/internal/version/version.go\nindex 712aae64..c1ed191e 100644\n--- a/internal/version/version.go\n+++ b/internal/version/version.go\n@@ -30,7 +30,7 @@ var (\n        // Збільшіть основний номер для додавання нових функцій та змін в поведінці.\n        // Збільшіть мінорний номер для виправлення помилок та підвищення продуктивності.\n        // Збільшіть номер патча для критичних виправлень в поточних версіях.\n-       version = \"v3.3\"\n+       version = \"v3.4\"\n\n        // metadata — це додаткові дані часу побудови\n        metadata = \"\"\n```\n\nОкрім оновлення версії у файлі `version.go`, вам також потрібно оновити відповідні тести, що використовують цей номер версії.\n\n* `cmd/helm/testdata/output/version.txt`\n* `cmd/helm/testdata/output/version-client.txt`\n* `cmd/helm/testdata/output/version-client-shorthand.txt`\n* `cmd/helm/testdata/output/version-short.txt`\n* `cmd/helm/testdata/output/version-template.txt`\n* `pkg/chartutil/capabilities_test.go`\n\n```shell\ngit add .\ngit commit -m \"bump version to $RELEASE_NAME\"\n```\n\nЦе оновить версію лише для гілки $RELEASE_BRANCH_NAME. Вам також потрібно буде інтегрувати ці зміни в основну гілку, щоб підготувати її до наступного випуску, як у [цьому прикладі з 3.2 до 3.3](https://github.com/helm/helm/pull/8411/files), та додати його до віхи наступного випуску.\n\n```shell\n# отримуємо ідентифікатор останнього коміта, тобто коміт для підвищення версії\ngit log --format=\"%H\" -n 1\n\n# створюємо нову гілку від основної гілки\ngit checkout main\ngit checkout -b bump-version-<release_version>\n\n# вибираємо коміт за допомогою ідентифікатора з першої команди\ngit cherry-pick -x <commit-id>\n\n# комітимо зміни\ngit push origin bump-version-<release-version>\n```\n\n## 3. Основні/Мінорні випуски: Коміт та збереження гілки релізу {#3-majorminor-releases-commit-and-push-the-release-branch}\n\nЩоб інші могли почати тестування, тепер можна надіслати гілку релізу в upstream і розпочати процес тестування.\n\n```shell\ngit push upstream $RELEASE_BRANCH_NAME\n```\n\nПереконайтеся, що перевірили [GitHub Actions](https://github.com/helm/helm/actions), щоб побачити, що реліз пройшов CI перед тим, як продовжити.\n\nЯкщо є можливість, дайте іншим перевірити гілку, перш ніж продовжувати, щоб переконатися, що всі необхідні зміни внесені та всі коміти для релізу присутні.\n\n## 4. Основні/Мінорні випуски: Створення реліз-кандидата {#4-majorminor-releases-create-a-release-candidate}\n\nТепер, коли гілку релізу створено та підготовлено, настав час почати створення та ітерацію реліз-кандидатів.\n\n```shell\ngit tag --sign --annotate \"${RELEASE_CANDIDATE_NAME}\" --message \"Helm release ${RELEASE_CANDIDATE_NAME}\"\ngit push upstream $RELEASE_CANDIDATE_NAME\n```\n\nGitHub Actions автоматично створить образ з теґом релізу та клієнтський бінарний файл для тестування.\n\nДля тестувальників процес початку тестування після завершення побудови артефактів GitHub Actions включає наступні кроки для отримання клієнта:\n\nLinux/amd64, використовуючи /bin/bash:\n\n```shell\nwget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz\n```\n\nDarwin/amd64, використовуючи Terminal.app:\n\n```shell\nwget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz\n```\n\nWindows/amd64, використовуючи PowerShell:\n\n```shell\nPS C:\\> Invoke-WebRequest -Uri \"https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz\" -OutFile \"helm-$ReleaseCandidateName-windows-amd64.tar.gz\"\n```\n\nПотім розпакуйте та перемістіть бінарний файл в теку, що знаходиться в $PATH, або перемістіть його в інше місце та додайте його до $PATH (наприклад, /usr/local/bin/helm для Linux/macOS, C:\\Program Files\\helm\\helm.exe для Windows).\n\n## 5. Основні/Мінорні випуски: Ітерація на наступних реліз-кандидатах {#5-majorminor-releases-iterate-on-successive-release-candidates}\n\nПротягом кількох днів активно інвестуйте час та ресурси, щоб спробувати виявити будь-які проблеми з Helm, документуючи всі важливі висновки для релізу. Цей час слід витратити на тестування та пошук способів, у яких реліз міг би викликати проблеми з різними функціями або середовищами оновлення, а не на написання коду. У цей період реліз перебуває в стані заморожування коду, і будь-які додаткові зміни коду будуть перенесені на наступний реліз.\n\nПротягом цієї фази гілка $RELEASE_BRANCH_NAME буде продовжувати розвиватися, оскільки ви будете створювати нові реліз-кандидати. Частота появи нових кандидатів залежить від менеджера релізу: використовуйте здоровий глузд, враховуючи серйозність виявлених проблем, доступність тестувальників та дату завершення релізу. Загалом, краще перенести реліз на пізніший термін, ніж випустити зламаний реліз.\n\nКожен раз, коли ви хочете створити нового реліз-кандидата, починайте з додавання комітів до гілки, використовуючи cherry-pick з main:\n\n```shell\ngit cherry-pick -x <commit_id>\n```\n\nТакож не забудьте надіслати гілку на GitHub та переконатися, що вона пройшла CI.\n\nПісля цього додайте теґ та повідомте користувачів про нового реліз-кандидата:\n\n```shell\nexport RELEASE_CANDIDATE_NAME=\"$RELEASE_NAME-rc.2\"\ngit tag --sign --annotate \"${RELEASE_CANDIDATE_NAME}\" --message \"Helm release ${RELEASE_CANDIDATE_NAME}\"\ngit push upstream $RELEASE_CANDIDATE_NAME\n```\n\nПісля того як теґ надіслано на GitHub, перевірте, чи успішно збирається гілка з цим тегом в CI.\n\nДалі просто повторюйте цей процес, постійно тестуючи, поки не будете задоволені реліз-кандидатом. Для реліз-кандидата повноцінні нотатки до релізу ще не пишуться, але можна підготувати [чернетку реліз-нотаток](#7-write-the-release-notes).\n\n## 6. Завершення релізу {#6-finalize-the-release}\n\nКоли ви нарешті задоволені якістю реліз-кандидата, можна переходити до створення остаточного релізу. Перевірте ще раз, чи все в порядку, а потім надішліть теґ релізу.\n\n```shell\ngit checkout $RELEASE_BRANCH_NAME\ngit tag --sign --annotate \"${RELEASE_NAME}\" --message \"Helm release ${RELEASE_NAME}\"\ngit push upstream $RELEASE_NAME\n```\n\nПереконайтеся, що реліз успішно пройшов на [GitHub Actions](https://github.com/helm/helm/actions). Якщо ні, вам доведеться виправити помилки та знову надіслати реліз.\n\nОскільки CI-завдання займе деякий час для виконання, ви можете перейти до написання реліз-нотаток, поки процес триває.\n\n## 7. Написання реліз-нотаток {#7-write-the-release-notes}\n\nМи автоматично створимо лог змін на основі комітів, які відбулися протягом циклу випуску, але для кінцевого користувача зазвичай корисніше, якщо реліз-нотатки будуть написані вручну людиною або командою маркетингу.\n\nЯкщо ви випускаєте мажорний або мінорний реліз, достатньо перерахувати помітні зміни, що впливають на користувачів. Для патч-релізів зробіть те саме, але також зазначте симптоми та на кого вони впливають.\n\nРеліз-нотатки повинні містити версію та заплановану дату наступного релізу.\n\nПриклад реліз-нотаток для мінорного релізу (переклад дано для наочності):\n\n```markdown\n## vX.Y.Z\n\nHelm vX.Y.Z — це реліз з новими функціями. Цього разу ми зосередилися на <вставте ключову тезу>. Користувачам рекомендується оновитися щоб мати найкращий досвід.\n\nСпільнота продовжує зростати, і ми були б раді бачити вас серед нас!\n\n- Приєднуйтеся до обговорення в [Kubernetes Slack](https://kubernetes.slack.com):\n  - `#helm-users` для запитань і просто для спілкування\n  - `#helm-dev` для обговорення PR, коду та багів\n- Відвідайте публічну зустріч розробників: щочетверга, 9:30 за тихоокеанським часом в [Zoom](https://zoom.us/j/696660622)\n- Тестуйте, налагоджуйте та робіть свій внесок у чарти: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0)\n\n## Важливі зміни\n\n- Додано підтримку Kubernetes 1.16, включаючи нові apiVersions для маніфестів.\n- Оновлено Sprig до версії 2.22.\n\n## Встановлення та оновлення\n\nЗавантажте Helm X.Y.Z. Бінарні файли для загальних платформ тут:\n\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n\n[Короткий посібник з налаштування](/intro/quickstart.md) допоможе вам розпочати роботу. Для інструкцій з оновлення або детальних нотаток з встановлення перегляньте [посібник з встановлення](/intro/install.md). Ви також можете використовувати [скрипт для встановлення](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3) на будь-якій системі з `bash`.\n\n## Що далі\n\n- vX.Y.Z+1 міститиме лише виправлення багів і планується на <вставте ДАТУ>.\n- vX.Y+1.0 — це наступний реліз з новими функціями, який планується на <вставте ДАТУ>. Цей реліз буде зосереджений на ...\n\n## Лог змін\n\n- chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese)\n- fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher)\n```\n\nЧастково заповнений набір реліз-нотаток, включаючи лог змін, можна створити за допомогою наступної команди:\n\n```shell\nexport VERSION=\"$RELEASE_NAME\"\nexport PREVIOUS_RELEASE=vX.Y.Z\nmake clean\nmake fetch-dist\nmake release-notes\n```\n\nЦе створить гарну базову версію реліз-нотаток, до яких вам потрібно буде лише додати розділи **Важливі зміни** та **Що далі**.\n\nНе соромтеся додавати свій стиль до реліз-нотаток; людям приємно думати, що ми не всі тут роботи.\n\nВи також повинні переконатися, що URL-адреси та контрольні суми правильні в автоматично згенерованих реліз-нотатках.\n\nПісля завершення перейдіть до [helm/helm releases](https://github.com/helm/helm/releases) на GitHub і відредагуйте реліз-нотатки для теґу релізу за допомогою написаних тут нотаток. Для цільової гілки встановіть $RELEASE_BRANCH_NAME.\n\nНа цьому етапі варто залучити інших людей для перегляду реліз-нотаток перед публікацією релізу. Надішліть запит у [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG) для перегляду. Це завжди корисно, оскільки легко щось пропустити.\n\n## 8. PGP Підпис файлів для завантаження {#8-pgp-sign-the-downloads}\n\nХоча хеші забезпечують підпис, що вміст завантажуваних файлів відповідає тому, що було згенеровано, підписані пакунки забезпечують простежуваність походження пакунка.\n\nЩоб це зробити, виконайте наступні команди `make`:\n\n```shell\nexport VERSION=\"$RELEASE_NAME\"\nmake clean\t\t# якщо ще не виконано\nmake fetch-dist\t# якщо ще не виконано\nmake sign\n```\n\nЦе створить файли підписів у форматі ascii armored для кожного з файлів, завантажених CI.\n\nУсі файли підписів (`*.asc`) необхідно завантажити до релізу на GitHub (додати до бінарних файлів).\n\n## 9. Оприлюднення релізу {#9-publish-release}\n\nЧас зробити реліз офіційним!\n\nПісля того, як реліз-нотатки збережено на GitHub, завершено збірку CI та додано файли підписів до релізу, можна натиснути \"Publish\" на сторінці релізу. Це опублікує реліз, позначивши його як \"latest\" (останній) та покаже його на головній сторінці репозиторію [helm/helm](https://github.com/helm/helm).\n\n## 10. Оновлення документації {#10-update-docs}\n\nРозділ документації на сайті [Helm](/docs) містить версії Helm. Необхідно оновити на сайті версії для major, minor і patch. Також потрібно оновити дату наступного minor релізу.\n\n:::note\nДо версії 4.00…\n\nЩоб це зробити, створіть 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`.\n:::\n\nЗакрийте [milestone](https://github.com/helm/helm/milestones) для релізу, якщо це прийнятно.\n\nОновіть [version skew](https://github.com/helm/helm-www/blob/main/content/en/docs/topics/version_skew.md) для major і minor релізів.\n\nОновіть календар релізів [тут](https://helm.sh/calendar/release):\n\n* створіть запис для наступного minor релізу з нагадуванням на цей день о 17:00 GMT\n* створіть запис для RC1 наступного minor релізу в понеділок тижня перед запланованим релізом, з нагадуванням на цей день о 17:00 GMT\n\n## 11. Сповістіть спільноту {#11-tell-the-community}\n\nВітаємо! Ви закінчили. Візьміть собі $DRINK_OF_CHOICE. Ви цього заслуговуєте.\n\nПісля того, як насолодитеся своїм $DRINK_OF_CHOICE, повідомте про новий реліз у Slack та Twitter з посиланням на [реліз на GitHub](https://github.com/helm/helm/releases).\n\nОпційно, напишіть блог пост про новий реліз і покажіть деякі з нових функцій там!\n"
  },
  {
    "path": "i18n/uk/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: Політика графіку нових випусків\ndescription: Описує політику графіку випусків Helm\n---\n\nДля зручності користувачів Helm визначає та оголошує дати випусків заздалегідь. Цей документ описує політику, що регулює графік випусків Helm.\n\n## Календар випусків {#release-calendar}\n\nПублічний календар із запланованими випусками Helm можна знайти [тут](https://helm.sh/calendar/release).\n\n## Семантичне версіювання {#semantic-versioning}\n\nВерсії Helm виражаються як `x.y.z`, де `x` — це основна версія, `y` — мінорна версія, а `z` — випуск патча, відповідно до термінології [семантичного версіювання](https://semver.org/lang/uk/spec/v2.0.0.html).\n\n## Випуски патчів {#patch-releases}\n\nВипуски патчів надають користувачам виправлення помилок і виправлення з безпеки. Вони не містять нових функцій.\n\nНовий випуск патча, що стосується останньої мінорної/основної версії, зазвичай здійснюється один раз на місяць, у другу середу кожного місяця.\n\nВипуск патча для виправлення пріоритетної регресії або проблеми безпеки може бути здійснений за потребою.\n\nВипуск патча буде скасовано з будь-якої з наступних причин:\n\n- якщо з моменту попереднього випуску не було додано нового вмісту;\n- якщо дата випуску патча припадає на тиждень до першого реліз-кандидата (RC1) майбутнього мінорного випуску;\n- якщо дата випуску патча припадає на чотири тижні після мінорного випуску.\n\n## Мінорні випуски {#minor-releases}\n\nМінорні випуски містять виправлення безпеки та помилок, а також нові функції. Вони є зворотно сумісними з API та використанням CLI.\n\nЩоб узгодитися з випусками Kubernetes, мінорний випуск Helm здійснюється кожні 4 місяці (3 випуски на рік).\n\nДодаткові мінорні випуски можуть здійснюватися за потреби, але це не вплине на графік оголошеного майбутнього випуску, якщо до нього не залишилося менше 7 днів.\n\nОдночасно з публікацією випуску буде оголошено дату наступного мінорного випуску, яка буде опублікована на головній вебсторінці Helm.\n\n## Основні випуски {#major-releases}\n\nОсновні випуски містять зміни, що порушують сумісність. Такі випуски є рідкісними, але іноді необхідні для подальшого важливого розвитку Helm.\n\nОсновні випуски можуть бути складними для планування. З огляду на це, остаточна дата випуску буде вибрана та оголошена лише після того, як буде доступна перша бета-версія такого випуску.\n"
  },
  {
    "path": "i18n/uk/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Проєкт Helm\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Чарти\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"Розробка\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"Спільнота\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"Вихідний код\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"Блог\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"Події\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"Кодекс поведінки\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"Вступ\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Поради та хитрощі для чартів\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"Розробка чартів\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"Пошук 800+ чартів\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"Як взяти участь\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"Мейнтейнери\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"Щотижневі зустрічі\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"Спільнота на GitHub\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"Ми є дипломованим проєктом <a href=\\\"https://www.cncf.io/\\\">Cloud Native Computing Foundation.</a><br/>© Автори Helm 2025. Документація поширюється на умовах ліцензії <a href=\\\"https://creativecommons.org/licenses/by/4.0/deed.uk\\\">CC-BY-4.0.</a><br/>© 2025 The Linux Foundation. Усі права застережено. The Linux Foundation має та використовує зареєстровані торгові марки. Для ознайомлення з переліком торгових марок The Linux Foundation, відвідайте <a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">сторінку використання торгових марок</a>.\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Логотип CNCF\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/uk/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Логотип Helm\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"Документація\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Чарти\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"Блог\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"Спільнота\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "i18n/zh/code.json",
    "content": "{\n  \"home.community.nextFeatureRelease\": {\n    \"message\": \"下一个功能版本\",\n    \"description\": \"Next Feature Release section title\"\n  },\n  \"home.community.nextFeatureRelease.version\": {\n    \"message\": \"版本：\",\n    \"description\": \"Version label\"\n  },\n  \"home.community.nextFeatureRelease.date\": {\n    \"message\": \"日期：\",\n    \"description\": \"Date label\"\n  },\n  \"home.community.nextFeatureRelease.calendar\": {\n    \"message\": \"发布日历\",\n    \"description\": \"Release Calendar link\"\n  },\n  \"home.community.upcomingEvents\": {\n    \"message\": \"即将举行的活动\",\n    \"description\": \"Upcoming Events section title\"\n  },\n  \"home.community.upcomingEventsSubtitle\": {\n    \"message\": \"即将举行的活动\",\n    \"description\": \"Upcoming Events subtitle\"\n  },\n  \"home.community.pastEventsSubtitle\": {\n    \"message\": \"过往活动\",\n    \"description\": \"Past Events subtitle\"\n  },\n  \"home.community.sigApps\": {\n    \"message\": \"SIG Apps\",\n    \"description\": \"SIG Apps section title\"\n  },\n  \"home.community.sigApps.description\": {\n    \"message\": \"他们{meetLink}来演示和讨论工具和项目。社区会议会被记录并{youtubeLink}。\",\n    \"description\": \"SIG Apps meeting description\"\n  },\n  \"home.community.sigApps.meetLink\": {\n    \"message\": \"每周聚会\",\n    \"description\": \"Link to SIG Apps meetings\"\n  },\n  \"home.community.sigApps.youtubeLink\": {\n    \"message\": \"分享到 YouTube\",\n    \"description\": \"Link to YouTube recordings\"\n  },\n  \"home.community.developerStandups\": {\n    \"message\": \"开发者站会\"\n  },\n  \"home.community.developerStandups.time\": {\n    \"message\": \"星期四 9:30-10am (PT)\",\n    \"description\": \"Developer Standups day and time\"\n  },\n  \"home.community.developerStandups.description\": {\n    \"message\": \"这些会议向所有人开放。查看{communityRepoLink}了解笔记和详情。\",\n    \"description\": \"Developer Standups description with community repo link\"\n  },\n  \"home.community.developerStandups.communityRepoLink\": {\n    \"message\": \"社区仓库\",\n    \"description\": \"Community repo link\"\n  },\n  \"home.community.slack.helmUsers.description\": {\n    \"message\": \"讨论使用 Helm、使用图表以及解决常见错误。\",\n    \"description\": \"helm-users slack channel description\"\n  },\n  \"home.community.slack.helmDevelopment.description\": {\n    \"message\": \"关于 Helm 开发、正在进行的 PR、发布等主题。\",\n    \"description\": \"helm-dev slack channel description\"\n  },\n  \"home.community.slack.charts.description\": {\n    \"message\": \"为 Helm Charts 用户和贡献者的讨论。\",\n    \"description\": \"charts slack channel description\"\n  },\n  \"home.community.slack.join\": {\n    \"message\": \"{slackLink}加入 Kubernetes Slack 团队。\",\n    \"description\": \"How to join the Kubernetes Slack team with slack link\"\n  },\n  \"home.community.slack.join.slackLink\": {\n    \"message\": \"在此请求访问权限\",\n    \"description\": \"Request access to slack link\"\n  },\n  \"home.community.contributing\": {\n    \"message\": \"贡献\",\n    \"description\": \"Contributing section title\"\n  },\n  \"home.community.contributing.description\": {\n    \"message\": \"Helm 始终欢迎对项目的新贡献！\",\n    \"description\": \"Contributing section description\"\n  },\n  \"home.community.contributing.whereToBegin\": {\n    \"message\": \"从哪里开始？\",\n    \"description\": \"Where to begin? section title\"\n  },\n  \"home.community.contributing.whereToBegin.description\": {\n    \"message\": \"Helm 是一个拥有众多用户和贡献者的大型项目。可能会有很多需要了解的内容！\",\n    \"description\": \"Where to begin? section description\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssues\": {\n    \"message\": \"如果你想提供帮助但不知道从哪里开始，我们有一个{goodFirstIssuesLink}列表。\",\n    \"description\": \"Good first issues sentence with link\"\n  },\n  \"home.community.contributing.whereToBegin.goodFirstIssuesLink\": {\n    \"message\": \"新手友好的问题\",\n    \"description\": \"Good first issues link\"\n  },\n  \"home.community.contributing.whatDoIDo\": {\n    \"message\": \"我该做什么？\",\n    \"description\": \"What do I do? section title\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuide\": {\n    \"message\": \"在贡献代码之前，请阅读我们的{contributionGuideLink}。它涵盖了创建和审查拉取请求的流程。\",\n    \"description\": \"What do I do? contribution guide description\"\n  },\n  \"home.community.contributing.whatDoIDo.contributionGuideLink\": {\n    \"message\": \"贡献指南\",\n    \"description\": \"Contribution Guide link\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommits\": {\n    \"message\": \"在编写一些代码后，请{signYourCommitsLink}以确保 Helm 遵守 {cncfLink} 使用的 {dcoLink} 协议。\",\n    \"description\": \"What do I do? sign your commits description\"\n  },\n  \"home.community.contributing.whatDoIDo.signYourCommitsLink\": {\n    \"message\": \"签署你的提交\",\n    \"description\": \"Sign your commits link\"\n  },\n  \"home.community.title\": {\n    \"message\": \"加入社区\",\n    \"description\": \"Join the Community title\"\n  },\n  \"home.community.subtitle\": {\n    \"message\": \"关于 Helm 项目的更多信息以及如何贡献。\",\n    \"description\": \"Join the Community subtitle\"\n  },\n  \"home.about.whatIsHelm\": {\n    \"message\": \"Helm 帮助你管理 Kubernetes 应用程序 — Helm Charts 帮助你定义、安装和升级即使是最复杂的 Kubernetes 应用程序。\",\n    \"description\": \"What is Helm? first paragraph\"\n  },\n  \"home.about.chartsDescription\": {\n    \"message\": \"Charts 易于创建、版本控制、共享和发布 — 所以开始使用 Helm，停止复制粘贴。\",\n    \"description\": \"What is Helm? charts paragraph\"\n  },\n  \"home.about.cncf\": {\n    \"message\": \"Helm 是 {cncfLink} 的毕业项目，由 {helmCommunityLink} 维护。\",\n    \"description\": \"What is Helm? CNCF Graduated Project paragraph\"\n  },\n  \"home.about.cncf.helmCommunityLink\": {\n    \"message\": \"Helm 社区\",\n    \"description\": \"Helm community link\"\n  },\n  \"home.about.learnMore\": {\n    \"message\": \"了解更多：\",\n    \"description\": \"Learn more label\"\n  },\n  \"home.about.learnMore.helmArchitectureLink\": {\n    \"message\": \"Helm 架构\",\n    \"description\": \"Helm Architecture link\"\n  },\n  \"home.about.learnMore.quickStartGuideLink\": {\n    \"message\": \"快速入门指南\",\n    \"description\": \"Quick Start Guide link\"\n  },\n  \"home.about.learnMore.videoLink\": {\n    \"message\": \"视频：Helm 简介\",\n    \"description\": \"Video: An Introduction to Helm link\"\n  },\n  \"home.about.title\": {\n    \"message\": \"什么是 Helm？\",\n    \"description\": \"What is Helm? title\"\n  },\n  \"home.gettingStarted.title\": {\n    \"message\": \"开始使用\",\n    \"description\": \"Getting started section title\"\n  },\n  \"home.gettingStarted.getHelmTitle\": {\n    \"message\": \"获取 Helm！\",\n    \"description\": \"Get Helm section title\"\n  },\n  \"home.gettingStarted.installHelm\": {\n    \"message\": \"使用包管理器安装 Helm，或{downloadLink}。\",\n    \"description\": \"Getting started install with package manager sentence with download link\"\n  },\n  \"home.gettingStarted.installHelm.downloadLink\": {\n    \"message\": \"下载二进制文件\",\n    \"description\": \"Download a binary link\"\n  },\n  \"home.gettingStarted.postInstall.instructions\": {\n    \"message\": \"安装后，解压 helm 二进制文件并将其添加到你的 PATH，然后就可以开始了！查看{docsLink}了解更多{installationLink}和{usageLink}。\",\n    \"description\": \"Instructions after installing Helm\"\n  },\n  \"home.gettingStarted.postInstall.docsLink\": {\n    \"message\": \"文档\",\n    \"description\": \"Link to installation docs\"\n  },\n  \"home.gettingStarted.postInstall.installationLink\": {\n    \"message\": \"安装\",\n    \"description\": \"Link to installation instructions\"\n  },\n  \"home.gettingStarted.postInstall.usageLink\": {\n    \"message\": \"使用说明\",\n    \"description\": \"Link to usage instructions\"\n  },\n  \"home.gettingStarted.getChartsTitle\": {\n    \"message\": \"获取 Chart\",\n    \"description\": \"Getting started get charts title\"\n  },\n  \"home.gettingStarted.artifactHub\": {\n    \"message\": \"访问 {artifactHubLink} 来探索来自众多公共仓库的 {helmChartsLink}。\",\n    \"description\": \"Artifact Hub link\"\n  },\n  \"home.gettingStarted.artifactHub.helmChartsLink\": {\n    \"message\": \"Helm 图表\",\n    \"description\": \"Helm charts link\"\n  },\n  \"home.features.manageComplexity\": {\n    \"message\": \"管理复杂性\",\n    \"description\": \"Manage Complexity section title\"\n  },\n  \"home.features.manageComplexity.description\": {\n    \"message\": \"Charts 描述了即使是最复杂的应用程序，提供可重复的应用程序安装，并充当单一权威来源。\",\n    \"description\": \"Manage Complexity section description\"\n  },\n  \"home.features.easyUpdates\": {\n    \"message\": \"轻松更新\",\n    \"description\": \"Easy Updates section title\"\n  },\n  \"home.features.easyUpdates.description\": {\n    \"message\": \"通过原地升级和自定义钩子，消除更新的痛苦。\",\n    \"description\": \"Easy Updates section description\"\n  },\n  \"home.features.simpleSharing\": {\n    \"message\": \"简单共享\",\n    \"description\": \"Simple Sharing section title\"\n  },\n  \"home.features.simpleSharing.description\": {\n    \"message\": \"Charts 易于版本控制、共享和托管在公共或私有服务器上。\",\n    \"description\": \"Simple Sharing section description\"\n  },\n  \"home.features.rollbacks\": {\n    \"message\": \"回滚\",\n    \"description\": \"Rollbacks section title\"\n  },\n  \"home.features.rollbacks.description\": {\n    \"message\": \"使用 {helmRollback} 可以轻松回滚到发布的旧版本。\",\n    \"description\": \"Rollbacks section description\"\n  },\n  \"home.features.title\": {\n    \"message\": \"功能特性\",\n    \"description\": \"Features section title\"\n  },\n  \"home.header.tagline\": {\n    \"message\": \"Kubernetes 的包管理器\",\n    \"description\": \"Helm tagline\"\n  },\n  \"home.header.subtitle\": {\n    \"message\": \"Helm 是查找、共享和使用为 Kubernetes 构建的软件的最佳方式\",\n    \"description\": \"Home page header subtitle\"\n  },\n  \"theme.ErrorPageContent.title\": {\n    \"message\": \"页面已崩溃。\",\n    \"description\": \"The title of the fallback page when the page crashed\"\n  },\n  \"theme.BackToTopButton.buttonAriaLabel\": {\n    \"message\": \"回到顶部\",\n    \"description\": \"The ARIA label for the back to top button\"\n  },\n  \"theme.blog.archive.title\": {\n    \"message\": \"历史博文\",\n    \"description\": \"The page & hero title of the blog archive page\"\n  },\n  \"theme.blog.archive.description\": {\n    \"message\": \"历史博文\",\n    \"description\": \"The page & hero description of the blog archive page\"\n  },\n  \"theme.blog.paginator.navAriaLabel\": {\n    \"message\": \"博文列表分页导航\",\n    \"description\": \"The ARIA label for the blog pagination\"\n  },\n  \"theme.blog.paginator.newerEntries\": {\n    \"message\": \"较新的博文\",\n    \"description\": \"The label used to navigate to the newer blog posts page (previous page)\"\n  },\n  \"theme.blog.paginator.olderEntries\": {\n    \"message\": \"较旧的博文\",\n    \"description\": \"The label used to navigate to the older blog posts page (next page)\"\n  },\n  \"theme.blog.post.paginator.navAriaLabel\": {\n    \"message\": \"博文分页导航\",\n    \"description\": \"The ARIA label for the blog posts pagination\"\n  },\n  \"theme.blog.post.paginator.newerPost\": {\n    \"message\": \"较新一篇\",\n    \"description\": \"The blog post button label to navigate to the newer/previous post\"\n  },\n  \"theme.blog.post.paginator.olderPost\": {\n    \"message\": \"较旧一篇\",\n    \"description\": \"The blog post button label to navigate to the older/next post\"\n  },\n  \"theme.tags.tagsPageLink\": {\n    \"message\": \"查看所有标签\",\n    \"description\": \"The label of the link targeting the tag list page\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.system\": {\n    \"message\": \"系统模式\",\n    \"description\": \"The name for the system color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.light\": {\n    \"message\": \"浅色模式\",\n    \"description\": \"The name for the light color mode\"\n  },\n  \"theme.colorToggle.ariaLabel.mode.dark\": {\n    \"message\": \"暗黑模式\",\n    \"description\": \"The name for the dark color mode\"\n  },\n  \"theme.colorToggle.ariaLabel\": {\n    \"message\": \"切换浅色/暗黑模式（当前为{mode}）\",\n    \"description\": \"The ARIA label for the color mode toggle\"\n  },\n  \"theme.docs.breadcrumbs.navAriaLabel\": {\n    \"message\": \"页面路径\",\n    \"description\": \"The ARIA label for the breadcrumbs\"\n  },\n  \"theme.docs.DocCard.categoryDescription.plurals\": {\n    \"message\": \"{count} 个项目\",\n    \"description\": \"The default description for a category card in the generated index about how many items this category includes\"\n  },\n  \"theme.docs.paginator.navAriaLabel\": {\n    \"message\": \"文件选项卡\",\n    \"description\": \"The ARIA label for the docs pagination\"\n  },\n  \"theme.docs.paginator.previous\": {\n    \"message\": \"上一页\",\n    \"description\": \"The label used to navigate to the previous doc\"\n  },\n  \"theme.docs.paginator.next\": {\n    \"message\": \"下一页\",\n    \"description\": \"The label used to navigate to the next doc\"\n  },\n  \"theme.docs.tagDocListPageTitle.nDocsTagged\": {\n    \"message\": \"{count} 篇文档带有标签\",\n    \"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)\"\n  },\n  \"theme.docs.tagDocListPageTitle\": {\n    \"message\": \"{nDocsTagged}「{tagName}」\",\n    \"description\": \"The title of the page for a docs tag\"\n  },\n  \"theme.docs.versions.unreleasedVersionLabel\": {\n    \"message\": \"此为 {siteTitle} {versionLabel} 版尚未发行的文档。\",\n    \"description\": \"The label used to tell the user that he's browsing an unreleased doc version\"\n  },\n  \"theme.docs.versions.unmaintainedVersionLabel\": {\n    \"message\": \"此为 {siteTitle} {versionLabel} 版的文档，现已不再积极维护。\",\n    \"description\": \"The label used to tell the user that he's browsing an unmaintained doc version\"\n  },\n  \"theme.docs.versions.latestVersionSuggestionLabel\": {\n    \"message\": \"最新的文档请参阅 {latestVersionLink} ({versionLabel})。\",\n    \"description\": \"The label used to tell the user to check the latest version\"\n  },\n  \"theme.docs.versions.latestVersionLinkLabel\": {\n    \"message\": \"最新版本\",\n    \"description\": \"The label used for the latest version suggestion link label\"\n  },\n  \"theme.docs.versionBadge.label\": {\n    \"message\": \"版本：{versionLabel}\"\n  },\n  \"theme.common.editThisPage\": {\n    \"message\": \"编辑此页\",\n    \"description\": \"The link label to edit the current page\"\n  },\n  \"theme.lastUpdated.atDate\": {\n    \"message\": \"于 {date} \",\n    \"description\": \"The words used to describe on which date a page has been last updated\"\n  },\n  \"theme.lastUpdated.byUser\": {\n    \"message\": \"由 {user} \",\n    \"description\": \"The words used to describe by who the page has been last updated\"\n  },\n  \"theme.lastUpdated.lastUpdatedAtBy\": {\n    \"message\": \"最后{byUser}{atDate}更新\",\n    \"description\": \"The sentence used to display when a page has been last updated, and by who\"\n  },\n  \"theme.common.headingLinkTitle\": {\n    \"message\": \"{heading}的直接链接\",\n    \"description\": \"Title for link to heading\"\n  },\n  \"theme.NotFound.title\": {\n    \"message\": \"找不到页面\",\n    \"description\": \"The title of the 404 page\"\n  },\n  \"theme.navbar.mobileVersionsDropdown.label\": {\n    \"message\": \"选择版本\",\n    \"description\": \"The label for the navbar versions dropdown on mobile view\"\n  },\n  \"theme.tags.tagsListLabel\": {\n    \"message\": \"标签：\",\n    \"description\": \"The label alongside a tag list\"\n  },\n  \"theme.AnnouncementBar.closeButtonAriaLabel\": {\n    \"message\": \"关闭\",\n    \"description\": \"The ARIA label for close button of announcement bar\"\n  },\n  \"theme.admonition.caution\": {\n    \"message\": \"警告\",\n    \"description\": \"The default label used for the Caution admonition (:::caution)\"\n  },\n  \"theme.admonition.danger\": {\n    \"message\": \"危险\",\n    \"description\": \"The default label used for the Danger admonition (:::danger)\"\n  },\n  \"theme.admonition.info\": {\n    \"message\": \"信息\",\n    \"description\": \"The default label used for the Info admonition (:::info)\"\n  },\n  \"theme.admonition.note\": {\n    \"message\": \"备注\",\n    \"description\": \"The default label used for the Note admonition (:::note)\"\n  },\n  \"theme.admonition.tip\": {\n    \"message\": \"提示\",\n    \"description\": \"The default label used for the Tip admonition (:::tip)\"\n  },\n  \"theme.admonition.warning\": {\n    \"message\": \"注意\",\n    \"description\": \"The default label used for the Warning admonition (:::warning)\"\n  },\n  \"theme.blog.sidebar.navAriaLabel\": {\n    \"message\": \"最近博文导航\",\n    \"description\": \"The ARIA label for recent posts in the blog sidebar\"\n  },\n  \"theme.DocSidebarItem.expandCategoryAriaLabel\": {\n    \"message\": \"展开侧边栏分类 '{label}'\",\n    \"description\": \"The ARIA label to expand the sidebar category\"\n  },\n  \"theme.DocSidebarItem.collapseCategoryAriaLabel\": {\n    \"message\": \"折叠侧边栏分类 '{label}'\",\n    \"description\": \"The ARIA label to collapse the sidebar category\"\n  },\n  \"theme.IconExternalLink.ariaLabel\": {\n    \"message\": \"(opens in new tab)\",\n    \"description\": \"The ARIA label for the external link icon\"\n  },\n  \"theme.NavBar.navAriaLabel\": {\n    \"message\": \"主导航\",\n    \"description\": \"The ARIA label for the main navigation\"\n  },\n  \"theme.NotFound.p1\": {\n    \"message\": \"我们找不到您要找的页面。\",\n    \"description\": \"The first paragraph of the 404 page\"\n  },\n  \"theme.NotFound.p2\": {\n    \"message\": \"请联系原始链接来源网站的所有者，并告知他们链接已损坏。\",\n    \"description\": \"The 2nd paragraph of the 404 page\"\n  },\n  \"theme.navbar.mobileLanguageDropdown.label\": {\n    \"message\": \"选择语言\",\n    \"description\": \"The label for the mobile language switcher dropdown\"\n  },\n  \"theme.TOCCollapsible.toggleButtonLabel\": {\n    \"message\": \"本页总览\",\n    \"description\": \"The label used by the button on the collapsible TOC component\"\n  },\n  \"theme.blog.post.readMore\": {\n    \"message\": \"阅读更多\",\n    \"description\": \"The label used in blog post item excerpts to link to full blog posts\"\n  },\n  \"theme.blog.post.readMoreLabel\": {\n    \"message\": \"阅读 {title} 的全文\",\n    \"description\": \"The ARIA label for the link to full blog posts from excerpts\"\n  },\n  \"theme.blog.post.readingTime.plurals\": {\n    \"message\": \"阅读需 {readingTime} 分钟\",\n    \"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)\"\n  },\n  \"theme.CodeBlock.wordWrapToggle\": {\n    \"message\": \"切换自动换行\",\n    \"description\": \"The title attribute for toggle word wrapping button of code block lines\"\n  },\n  \"theme.CodeBlock.copy\": {\n    \"message\": \"复制\",\n    \"description\": \"The copy button label on code blocks\"\n  },\n  \"theme.CodeBlock.copied\": {\n    \"message\": \"复制成功\",\n    \"description\": \"The copied button label on code blocks\"\n  },\n  \"theme.CodeBlock.copyButtonAriaLabel\": {\n    \"message\": \"复制代码到剪贴板\",\n    \"description\": \"The ARIA label for copy code blocks button\"\n  },\n  \"theme.docs.breadcrumbs.home\": {\n    \"message\": \"主页面\",\n    \"description\": \"The ARIA label for the home page in the breadcrumbs\"\n  },\n  \"theme.docs.sidebar.navAriaLabel\": {\n    \"message\": \"文档侧边栏\",\n    \"description\": \"The ARIA label for the sidebar navigation\"\n  },\n  \"theme.docs.sidebar.collapseButtonTitle\": {\n    \"message\": \"收起侧边栏\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.collapseButtonAriaLabel\": {\n    \"message\": \"收起侧边栏\",\n    \"description\": \"The title attribute for collapse button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.closeSidebarButtonAriaLabel\": {\n    \"message\": \"关闭导航栏\",\n    \"description\": \"The ARIA label for close button of mobile sidebar\"\n  },\n  \"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel\": {\n    \"message\": \"← 回到主菜单\",\n    \"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)\"\n  },\n  \"theme.docs.sidebar.toggleSidebarButtonAriaLabel\": {\n    \"message\": \"切换导航栏\",\n    \"description\": \"The ARIA label for hamburger menu button of mobile navigation\"\n  },\n  \"theme.docs.sidebar.expandButtonTitle\": {\n    \"message\": \"展开侧边栏\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.docs.sidebar.expandButtonAriaLabel\": {\n    \"message\": \"展开侧边栏\",\n    \"description\": \"The ARIA label and title attribute for expand button of doc sidebar\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.expandAriaLabel\": {\n    \"message\": \"展开下拉菜单\",\n    \"description\": \"The ARIA label of the button to expand the mobile dropdown navbar item\"\n  },\n  \"theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel\": {\n    \"message\": \"折叠下拉菜单\",\n    \"description\": \"The ARIA label of the button to collapse the mobile dropdown navbar item\"\n  },\n  \"theme.blog.post.plurals\": {\n    \"message\": \"{count} 篇博文\",\n    \"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)\"\n  },\n  \"theme.blog.tagTitle\": {\n    \"message\": \"{nPosts} 含有标签「{tagName}」\",\n    \"description\": \"The title of the page for a blog tag\"\n  },\n  \"theme.blog.author.pageTitle\": {\n    \"message\": \"{authorName} - {nPosts}\",\n    \"description\": \"The title of the page for a blog author\"\n  },\n  \"theme.blog.authorsList.pageTitle\": {\n    \"message\": \"作者\",\n    \"description\": \"The title of the authors page\"\n  },\n  \"theme.blog.authorsList.viewAll\": {\n    \"message\": \"查看所有作者\",\n    \"description\": \"The label of the link targeting the blog authors page\"\n  },\n  \"theme.blog.author.noPosts\": {\n    \"message\": \"该作者尚未撰写任何文章。\",\n    \"description\": \"The text for authors with 0 blog post\"\n  },\n  \"theme.contentVisibility.unlistedBanner.title\": {\n    \"message\": \"未列出页\",\n    \"description\": \"The unlisted content banner title\"\n  },\n  \"theme.contentVisibility.unlistedBanner.message\": {\n    \"message\": \"此页面未列出。搜索引擎不会对其索引，只有拥有直接链接的用户才能访问。\",\n    \"description\": \"The unlisted content banner message\"\n  },\n  \"theme.contentVisibility.draftBanner.title\": {\n    \"message\": \"草稿页\",\n    \"description\": \"The draft content banner title\"\n  },\n  \"theme.contentVisibility.draftBanner.message\": {\n    \"message\": \"此页面是草稿，仅在开发环境中可见，不会包含在正式版本中。\",\n    \"description\": \"The draft content banner message\"\n  },\n  \"theme.ErrorPageContent.tryAgain\": {\n    \"message\": \"重试\",\n    \"description\": \"The label of the button to try again rendering when the React error boundary captures an error\"\n  },\n  \"theme.common.skipToMainContent\": {\n    \"message\": \"跳到主要内容\",\n    \"description\": \"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation\"\n  },\n  \"theme.tags.tagsPageTitle\": {\n    \"message\": \"标签\",\n    \"description\": \"The title of the tag list page\"\n  }\n}\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-blog/options.json",
    "content": "{\n  \"title\": {\n    \"message\": \"博客\",\n    \"description\": \"The title for the blog used in SEO\"\n  },\n  \"description\": {\n    \"message\": \"博客\",\n    \"description\": \"The description for the blog used in SEO\"\n  },\n  \"sidebar.title\": {\n    \"message\": \"所有文章\",\n    \"description\": \"The label for the left sidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/current.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"4.0.0\",\n    \"description\": \"The label for version current\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics\": {\n    \"message\": \"Tutorial - Basics\",\n    \"description\": \"The label for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description\": {\n    \"message\": \"5 minutes to learn the most important Docusaurus concepts.\",\n    \"description\": \"The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Tutorial - Extras\": {\n    \"message\": \"Tutorial - Extras\",\n    \"description\": \"The label for category Tutorial - Extras in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-2.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"2.17.0\",\n    \"description\": \"The label for version 2\"\n  },\n  \"sidebar.tutorialSidebar.category.Using Helm\": {\n    \"message\": \"使用 Helm\",\n    \"description\": \"The label for category Using Helm in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Helm 命令\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The label for category Charts in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Developing Templates\": {\n    \"message\": \"开发模板\",\n    \"description\": \"The label for category Developing Templates in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"最佳实践\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: 一般惯例\ndescription: chart 的一般惯例。\nsidebar_position: 1\n---\n\n最佳实践指南的这部分介绍 chart 的一般惯例。\n\n## Chart 名称\n\nchart 名称必须是小写字母和数字。单词之间 _可以_ 使用横杠（`-`）分隔：\n\n示例：\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nchart 名称中不能使用大写字母或下划线，也不能使用点号。\n\n## 版本号\n\nHelm 尽可能使用 [SemVer 2](https://semver.org) 来表示版本号。（注意 Docker 镜像的 tag 不一定遵循 SemVer，因此被视为该规则的例外。）\n\n当 SemVer 版本存储在 Kubernetes 标签中时，我们通常把 `+` 字符改成 `_`，因为标签不允许使用 `+` 作为值。\n\n## 格式化 YAML\n\nYAML 文件应该使用 _两个空格_ 缩进（绝不要使用 tab 键）。\n\n## Helm 和 Chart 的用法\n\n以下是 _Helm_ 和 _helm_ 的几个惯用方法：\n\n- _Helm_ 是指整个项目\n- `helm` 是指客户端命令\n- `chart` 不是专有名词，不需要首字母大写\n- 但 `Chart.yaml` 需要首字母大写，因为文件名区分大小写\n\n若有疑问，使用 _Helm_（大写 'H'）。\n\n## Chart 模板和 namespace\n\n避免在 chart 模板的 `metadata` 部分定义 `namespace` 属性。渲染后的模板应该在调用 Kubernetes 客户端时通过 `--namespace` 参数指定要部署到的 namespace。Helm 会原样渲染模板并发送给 Kubernetes 客户端，无论是 Helm 本身还是其他程序（如 kubectl、flux、spinnaker 等）。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: 自定义资源定义\ndescription: 如何创建和使用 CRD。\nsidebar_position: 7\n---\n\n最佳实践指南的这部分介绍如何创建和使用自定义资源定义（CRD）对象。\n\n使用自定义资源定义（CRD）时，需要区分两个不同的部分：\n\n- CRD 的声明。这是一个 kind 为 `CustomResourceDefinition` 的 YAML 文件。\n- 使用 CRD 的资源。假设 CRD 定义了 `foo.example.com/v1`，那么任何 `apiVersion: example.com/v1` 且 kind 为 `Foo` 的资源都是使用该 CRD 的资源。\n\n## 在使用资源之前安装 CRD 声明\n\nHelm 被优化为尽可能快地将尽可能多的资源加载到 Kubernetes 中。按照设计，Kubernetes 可以获取一整套清单并将其全部上线（这称为协调循环）。\n\n但 CRD 有所不同。\n\n对于 CRD，声明必须在使用该 CRD 类型的任何资源之前完成注册。而注册过程有时需要几秒钟。\n\n### 方法1：让 `helm` 帮你完成\n\n随着 Helm 3 的到来，我们移除了旧的 `crd-install` 钩子，采用了更简单的方法。现在可以在 chart 中创建一个名为 `crds` 的特殊目录来存放 CRD。这些 CRD 不会被模板化，但在运行 `helm install` 时会默认安装。如果 CRD 已存在，会显示警告并跳过。如果希望跳过 CRD 安装步骤，可以使用 `--skip-crds` 参数。\n\n#### 注意事项（和说明）\n\n目前不支持使用 Helm 升级或删除 CRD。由于存在意外数据丢失的风险，这是经过多次社区讨论后做出的明确决定。目前社区对于如何处理 CRD 及其生命周期还没有达成共识。随着这一过程的演进，Helm 将逐步支持这些用例。\n\n`helm install` 和 `helm upgrade` 的 `--dry-run` 参数目前不支持 CRD。\"模拟运行\"的目的是验证 chart 输出在发送到服务器时是否真正有效。但 CRD 会修改服务器的行为。Helm 无法在模拟运行时安装 CRD，因此 discovery 客户端无法识别该自定义资源（CR），导致验证失败。你可以将 CRD 移动到单独的 chart 中，或者使用 `helm template` 代替。\n\n在讨论 CRD 支持时，另一个需要考虑的重要问题是模板渲染的处理方式。Helm 2 中使用 `crd-install` 方法的一个明显缺点是，由于 API 可用性的变化，无法正确验证 chart（CRD 实际上是向 Kubernetes 集群添加了另一个可用的 API）。如果 chart 安装了 CRD，`helm` 就不再拥有一组有效的 API 版本可供使用。这也是从 CRD 移除模板支持的原因。通过新的 `crds` 目录安装 CRD 的方法，我们现在可以确保 `helm` 拥有关于集群当前状态的完全有效的信息。\n\n### 方法2：独立 chart\n\n另一种方法是将 CRD 定义放在一个 chart 中，然后将使用该 CRD 的所有资源放在 _另一个_ chart 中。\n\n这种方法需要分别安装每个 chart。但是，对于拥有集群管理员访问权限的集群运维人员来说，这种工作流可能更有用。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: 依赖\ndescription: 涵盖 chart 依赖的最佳实践\nsidebar_position: 4\n---\n\n本节介绍在 `Chart.yaml` 中声明 `dependencies` 的最佳实践。\n\n## 版本\n\n尽可能使用版本范围而不是固定版本。建议默认使用补丁级别的版本匹配：\n\n```yaml\nversion: ~1.2.3\n```\n\n这会匹配 `1.2.3` 以及该版本的任何补丁。也就是说，`~1.2.3` 相当于 `>= 1.2.3, < 1.3.0`。\n\n完整的版本匹配语法请参阅 [semver 文档](https://github.com/Masterminds/semver#checking-version-constraints)。\n\n### 预发布版本\n\n上述版本约束不会匹配预发布版本。例如，`version: ~1.2.3` 会匹配 `version: ~1.2.4`，但不会匹配 `version: ~1.2.3-1`。\n以下写法可同时匹配预发布版本和补丁版本：\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### 仓库 URL\n\n尽可能使用 `https://` 仓库 URL，其次是 `http://` URL。\n\n如果仓库已添加到仓库索引文件中，可以使用仓库名称作为 URL 的别名。使用 `alias:` 或 `@` 后跟仓库名称。\n\n文件 URL（`file://...`）被视为一种\"特例\"，用于通过固定部署流水线组装的 chart。\n\n使用[下载器插件](../topics/plugins.md#downloader-plugins)时，URL 方案将特定于该插件。注意，chart 的用户需要安装支持该方案的插件才能更新或构建依赖。\n\n当 `repository` 字段为空时，Helm 无法执行依赖管理操作。此时 Helm 会假定依赖位于 `charts` 文件夹的子目录中，目录名称与依赖的 `name` 属性相同。\n\n## 条件和标签\n\n条件或标签应添加到任何**可选**的依赖中。注意，`condition` 的默认值为 `true`。\n\n条件的首选格式是：\n\n```yaml\ncondition: somechart.enabled\n```\n\n其中 `somechart` 是依赖 chart 的名称。\n\n当多个子 chart（依赖）共同提供可选或可替换的功能时，这些 chart 应共享相同的标签。\n\n例如，如果 `nginx` 和 `memcached` 共同为主应用提供性能优化功能，且启用该功能时需要两者同时存在，则它们都应包含如下标签：\n\n```yaml\ntags:\n  - webaccelerator\n```\n\n这样用户就可以通过一个标签来启用或禁用该功能。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx",
    "content": "---\ntitle: 最佳实践\nsidebar: true\nsidebar_position: 4\n---\n\n# Chart 最佳实践指南\n\n该指南覆盖了 Helm 团队能考虑到的创建 Chart 的最佳实践。\n聚焦于 Chart 应该如何构造。\n\n我们首要关注 Chart 公开部署的最佳实践。\n我们知道很多 Chart 只用于内部使用，而且这些 Chart 作者会越过这些建议使用他们的内部优化。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: 标签和注释\ndescription: 介绍在 chart 中使用标签和注释的最佳实践。\nsidebar_position: 5\n---\n\n最佳实践指南的这部分介绍在 chart 中使用标签和注释的最佳实践。\n\n## 是标签还是注释？\n\n满足以下条件时，元数据项应该使用标签：\n\n- Kubernetes 用它来识别资源\n- 便于运维人员查询系统\n\n例如，建议使用 `helm.sh/chart: NAME-VERSION` 作为标签，这样运维人员可以方便地找到特定 chart 的所有实例。\n\n如果元数据不用于查询，应该设置为注释。\n\nHelm hook 始终是注释。\n\n## 标准标签\n\n下表定义了 Helm chart 使用的通用标签。Helm 本身不强制要求任何特定标签。标记为 REC 的是推荐标签，**应该** 添加到 chart 中以保持全局一致性。标记为 OPT 的是可选标签，虽然常用且符合惯例，但在实际操作中并不经常依赖。\n\n名称|状态|描述\n----|----|----\n`app.kubernetes.io/name` | REC | 应用名称，反映整个应用。通常使用 `{{ template \"name\" . }}`。许多 Kubernetes 清单会使用这个标签，它不是 Helm 特有的。\n`helm.sh/chart` | REC | chart 的名称和版本：`{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`。\n`app.kubernetes.io/managed-by` | REC | 应始终设置为 `{{ .Release.Service }}`。用于查找所有由 Helm 管理的资源。\n`app.kubernetes.io/instance` | REC | 应设置为 `{{ .Release.Name }}`。有助于区分同一应用的不同实例。\n`app.kubernetes.io/version` | OPT | 应用版本，可设置为 `{{ .Chart.AppVersion }}`。\n`app.kubernetes.io/component` | OPT | 用于标记组件在应用中扮演的角色。例如 `app.kubernetes.io/component: frontend`。\n`app.kubernetes.io/part-of` | OPT | 当多个 chart 或软件组合成一个应用时使用。例如，应用程序和数据库共同构建一个网站。可设置为顶层支撑应用。\n\n关于以 `app.kubernetes.io` 为前缀的 Kubernetes 标签的更多信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pod 和 PodTemplate\ndescription: 讨论在 chart 清单中格式化 Pod 和 PodTemplate 部分。\nsidebar_position: 6\n---\n\n最佳实践指南的这部分讨论在 chart 清单中格式化 Pod 和 PodTemplate 部分。\n\n以下（非详尽的）资源列表使用 PodTemplate：\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## 镜像\n\n容器镜像应该使用固定的 tag 或镜像的 SHA。不应该使用 `latest`、`head`、`canary` 等标签或其他被设计为\"浮动的\"标签。\n\n镜像**可以**定义在 `values.yaml` 文件中，便于切换镜像。\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\n镜像和 tag **可以**在 `values.yaml` 中定义为两个独立的字段：\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## 镜像拉取策略\n\n`helm create` 通过以下方式在 `deployment.yaml` 中将 `imagePullPolicy` 默认设置为 `IfNotPresent`：\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\n以及 `values.yaml`：\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\n类似地，如果 Kubernetes 根本没有定义，默认会将 `imagePullPolicy` 设置为 `IfNotPresent`。如果想设置一个值而不是 `IfNotPresent`，只需在 `values.yaml` 中更新为需要的值即可。\n\n## PodTemplate 应该声明选择器\n\n所有的 PodTemplate 部分应该指定一个 selector。例如：\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\n这是一个很好的实践，因为它建立了资源集合和 Pod 之间的关系。\n\n但这一点对于 Deployment 等资源来说更加重要。如果没有指定选择器，系统会使用**所有**标签来匹配 Pod，当你使用了会变化的标签（比如版本或发布日期）时，这会导致匹配失败。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: 基于角色的访问控制\ndescription: 讨论在 chart 清单中创建和格式化 RBAC 资源。\nsidebar_position: 8\n---\n\n最佳实践指南的这部分讨论在 chart 清单中创建和格式化 RBAC 资源。\n\nRBAC 资源有：\n\n- ServiceAccount（namespaced）\n- Role（namespaced）\n- ClusterRole\n- RoleBinding（namespaced）\n- ClusterRoleBinding\n\n## YAML 配置\n\nRBAC 和 ServiceAccount 配置应该使用独立的 key。它们是独立的内容。在 YAML 中将这两个概念分开可以消除歧义，使其更加清晰。\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\n这个结构可以在更复杂的、需要多个 ServiceAccount 的 chart 中扩展。\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## RBAC 资源应该默认创建\n\n`rbac.create` 应该是布尔值，用于控制 RBAC 资源是否被创建。默认是 `true`。用户想自己管理 RBAC 访问控制时可以设置为 `false`（这种情况请参阅下文）。\n\n## 使用 RBAC 资源\n\n`serviceAccount.name` 要设置为由 chart 创建的访问控制资源的 ServiceAccount 的名称。如果 `serviceAccount.create` 是 true，则使用该名称的 ServiceAccount 会被创建。如果没有设置名称，则会使用 `fullname` 模板生成一个名称。如果 `serviceAccount.create` 是 false，则不会被创建，但仍然会与相同的资源关联，以便后续手动创建的引用它的 RBAC 资源可以正常工作。如果 `serviceAccount.create` 是 false 且没有指定名称，会使用默认的 ServiceAccount。\n\n以下辅助模板可用于 ServiceAccount。\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: 模板\ndescription: 进一步了解围绕模板的最佳实践。\nsidebar_position: 3\n---\n\n最佳实践指南的这部分聚焦于模板。\n\n## `templates/` 结构\n\n`templates/` 目录结构应该如下：\n\n- 如果生成 YAML 输出，模板文件应该有扩展名`.yaml`。\n  `.tpl` 扩展名可用于不生成格式化内容的模板文件。\n- 模板文件名称应该使用横杠符号(`my-example-configmap.yaml`)，不用驼峰记法。\n- 每个资源的定义应该在它自己的模板文件中。\n- 模板文件的名称应该反映名称中的资源类型。比如：`foo-pod.yaml`， `bar-svc.yaml`\n\n## 定义模板的名称\n\n定义的模板（在 `{{ define }}` 命令中定义的模板）是可全局访问的。这就意味着 chart 和所有的子 chart 都可以访问用 `{{ define }}` 创建的所有模板。\n\n因此， _所有定义的模板名称应该被命名空间化。_\n\n正确的：\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\n不正确的：\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\n\n强烈建议通过 `helm create` 命令创建新 chart，因为模板名称是根据此最佳实践自动定义的。\n\n## 格式化模板\n\n模板应该使用两个 _空格_ 缩进（永远不要用tab）。\n\n模板命令的大括号前后应该使用空格：\n\n正确的：\n\n```yaml\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\n不正确的：\n\n```yaml\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\n模板应尽可能裁剪空格：\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\n块（例如控制结构）可以缩进表示模板代码流。\n\n```yaml\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\n然而，因为 YAML 是面向空格的语言，代码缩进通常不可能遵守规范。\n\n## 生成模板中的空格\n\n最好在生成的模板中将空格量保持在最小值。尤其是大量的空行不应该相邻出现。但偶尔有空行（尤其在逻辑块之间）是没问题的。\n\n这样是最好的：\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\n这样也OK：\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\n但避免这样：\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## 注释 (YAML 注释 vs. 模板注释)\n\nYAML 和 Helm 模板都有注释标记符。\n\nYAML 注释：\n\n```yaml\n# This is a comment\ntype: sprocket\n```\n\n模板注释：\n\n```yaml\n{{- /*\nThis is a comment.\n*/}}\ntype: frobnitz\n```\n\n描述模板的特性时应当使用模板注释，比如解释一个定义的模板：\n\n```yaml\n{{- /*\nmychart.shortname provides a 6 char truncated version of the release name.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\n在模板中，当有益于 Helm 用户（可能）在调试时查看注释，可以使用 YAML 注释。\n\n```yaml\n# This may cause problems if the value is more than 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\n以上注释在用户执行`helm install --debug`时是可见的，而在`{{- /* */}}`部分指定注释不会显示。\n\n注意不要在包含某些模板函数可能需要的 Helm 值的模板部分添加 `#` YAML 注释。\n\n例如，如果在上面的示例中引入了 `required` 函数，并且 `maxMem` 未设置，那么 `#` YAML 注释将导致渲染错误。\n\n正确做法：`helm template` 不会渲染此代码块\n\n```yaml\n{{- /*\n# This may cause problems if the value is more than 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\n错误做法：`helm template` 返回 `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n\n```yaml\n# This may cause problems if the value is more than 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\n查看[调试模板](/chart_template_guide/debugging.md)了解更多关于 YAML 注释如何被保留的示例。\n\n## 在模板和模板输出中使用JSON\n\nYAML 是 JSON 的超集。在某些情况下，使用 JSON 语法比其他 YAML 表示更具可读性。\n\n比如，这个 YAML 更接近表示列表的普通 YAML 方法：\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\n但是折叠成JSON列表样式时会更易阅读:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\n使用 JSON 可以很好地提高易读性。然而，JSON 语法不应用于表示更复杂的结构。\n\n在处理嵌入到 YAML 中的纯 JSON 时（比如初始化容器配置），使用 JSON 格式当然是最合适的。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: Values\ndescription: 聚焦于如何构建和使用你的 values。\nsidebar_position: 2\n---\n\n最佳实践指南的这部分介绍 values 的使用。本节提供关于如何构建和使用 values 的建议，重点讨论 chart 的 `values.yaml` 文件设计。\n\n## 命名规范\n\n变量名称应以小写字母开头，单词之间使用驼峰命名法：\n\n正确：\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\n错误：\n\n```yaml\nChicken: true  # initial caps may conflict with built-ins\nchicken-noodle-soup: true # do not use hyphens in the name\n```\n\n注意 Helm 的所有内置变量都以大写字母开头，以便与用户定义的 values 区分：`.Release.Name`、`.Capabilities.KubeVersion`。\n\n## 扁平或嵌套的 Values\n\nYAML 是一种灵活的格式，值可以嵌套很深，也可以是扁平的。\n\n嵌套：\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\n扁平：\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\n大多数情况下，扁平结构优于嵌套结构。原因是对模板开发者和用户来说更简单。\n\n为了保证安全性，嵌套值的每一层都必须检查：\n\n```yaml\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\n每一层嵌套都必须进行存在性检查。但扁平配置可以跳过这些检查，使模板更易于阅读和使用。\n\n```yaml\n{{ default \"none\" .Values.serverName }}\n```\n\n当存在大量相关变量，且其中至少有一个是必填的时，可以使用嵌套值来提高可读性。\n\n## 明确类型\n\nYAML 的类型强制转换规则有时不太直观。例如，`foo: false` 和 `foo: \"false\"` 是不同的。大整数如 `foo: 12345678` 在某些情况下会被转换成科学计数法。\n\n避免类型转换错误最简单的方法是：字符串显式声明，其他类型隐式声明。简而言之，_给所有字符串加引号_。\n\n通常，为了避免整数转换问题，将整数也存储为字符串是个好做法，然后在模板中使用 `{{ int $value }}` 将字符串转回整数。\n\n大多数情况下，显式类型标记会被正确识别，因此 `foo: !!string 1234` 会将 `1234` 当作字符串处理。_但是_，YAML 解析器会消耗这些标记，因此类型数据在一次解析后会丢失。\n\n## 考虑用户如何使用 Values\n\nvalues 有三种潜在来源：\n\n- chart 的 `values.yaml` 文件\n- 由 `helm install -f` 或 `helm upgrade -f` 提供的 values 文件\n- 执行 `helm install` 或 `helm upgrade` 时通过 `--set` 或 `--set-string` 参数传递的值\n\n设计 values 结构时，要记住 chart 用户可能会通过 `-f` 参数或 `--set` 选项覆盖它们。\n\n由于 `--set` 的表达能力更有限，编写 `values.yaml` 文件的第一条准则是 _确保它易于被 `--set` 覆盖_。\n\n因此，使用 map 来构建 values 文件通常更好。\n\n难以配合 `--set` 使用：\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\n上述结构在 Helm `<=2.4` 中无法配合 `--set` 表达。在 Helm 2.5 中，访问 foo 的端口是 `--set servers[0].port=80`。这不仅让用户更难理解，而且如果以后 `servers` 的顺序发生变化，很容易出错。\n\n易于使用：\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\n这样访问 foo 的端口就很明显：`--set servers.foo.port=80`。\n\n## 给 `values.yaml` 写文档\n\n`values.yaml` 中定义的每个属性都应该有文档说明。文档字符串应该以它描述的属性名称开头，然后至少给出一句描述。\n\n错误：\n\n```yaml\n# the host name for the webserver\nserverHost: example\nserverPort: 9191\n```\n\n正确：\n\n```yaml\n# serverHost is the host name for the webserver\nserverHost: example\n# serverPort is the HTTP listener port for the webserver\nserverPort: 9191\n```\n\n在注释开头写上参数名称，便于整理文档，也能让文档工具可靠地将文档字符串与其描述的参数关联起来。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: 在模板内部访问文件\ndescription: 如何从模板中访问文件\nsidebar_position: 10\n---\n\n在上一节中，我们介绍了创建和访问命名模板的几种方法。这使得在模板之间相互导入变得很容易。但有时你需要导入的是一个**非模板文件**，并直接注入其内容，而不经过模板渲染引擎处理。\n\nHelm 通过 `.Files` 对象提供对文件的访问。不过在使用模板示例之前，有几点需要注意：\n\n- 可以在 chart 中添加额外的文件，这些文件会被一起打包。但要注意，由于 Kubernetes 对象的存储限制，chart 大小必须小于 1M。\n- 出于安全考虑，某些文件无法通过 `.Files` 对象访问：\n  - 无法访问 `templates/` 目录中的文件。\n  - 无法访问被 `.helmignore` 排除的文件。\n  - 无法访问 Helm 应用 [子 chart](./subcharts_and_globals.md) 之外的文件，包括父 chart 中的文件。\n- chart 不保留 UNIX 模式信息，因此文件级权限不会影响 `.Files` 对象对文件的可用性。\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [基本示例](#基本示例)\n- [路径辅助函数](#路径辅助函数)\n- [Glob 模式](#glob-模式)\n- [ConfigMap 和 Secret 实用函数](#configmap-和-secret-实用函数)\n- [编码](#编码)\n- [逐行读取](#逐行读取)\n\n<!-- tocstop -->\n\n## 基本示例\n\n了解了这些注意事项后，让我们编写一个模板，将三个文件读取到 ConfigMap 中。首先，在 chart 中添加三个文件，直接放在 `mychart/` 目录下。\n\n`config1.toml`：\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`：\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`：\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\n每个文件都是简单的 TOML 文件（类似于早期 Windows 的 INI 文件）。我们知道这些文件的名称，因此可以使用 `range` 函数遍历它们，并将内容注入到 ConfigMap 中。\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\n这个 ConfigMap 使用了前面章节讨论过的技术。例如，我们创建了一个 `$files` 变量来保存对 `.Files` 对象的引用，并使用 `tuple` 函数创建了要遍历的文件列表。然后打印每个文件名（`{{ . }}: |-`），接着通过 `{{ $files.Get . }}` 打印文件内容。\n\n执行这个模板会生成一个包含所有三个文件内容的 ConfigMap：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## 路径辅助函数\n\n处理文件时，对文件路径执行一些标准操作会很有用。为此，Helm 从 Go 的 [path](https://golang.org/pkg/path/) 包中导入了一些函数供你使用。这些函数使用与 Go 包相同的名称，但首字母小写。例如 `Base` 变成 `base`，以此类推。\n\n导入的函数包括：\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Glob 模式\n\n随着 chart 规模增长，你可能需要更好地组织文件。为此我们提供了 `Files.Glob(pattern string)` 方法，它支持使用 [glob 模式](https://godoc.org/github.com/gobwas/glob) 灵活地提取特定文件。\n\n`.Glob` 返回一个 `Files` 类型，因此你可以在返回的对象上调用任何 `Files` 方法。\n\n例如，假设有以下目录结构：\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\n使用 Glob 有多种方式：\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\n或者\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## ConfigMap 和 Secret 实用函数\n\n（Helm 2.0.2 及更高版本可用）\n\n将文件内容放入 ConfigMap 和 Secret 以便在运行时挂载到 Pod 是很常见的需求。为此，我们在 `Files` 类型上提供了一些实用方法。\n\n结合 `Glob` 方法使用这些方法可以更好地组织文件。\n\n使用上面 [Glob 模式](#glob-模式) 示例中的目录结构：\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## 编码\n\n你可以导入文件并使用 base64 编码，以确保传输成功：\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\n上面的模板使用之前的 `config1.toml` 文件并对其进行编码：\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## 逐行读取\n\n有时需要在模板中逐行访问文件内容。我们为此提供了便捷的 `Lines` 方法。\n\n你可以使用 `range` 函数遍历 `Lines`：\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\n在 `helm install` 过程中无法将 chart 外部的文件传入。因此，如果需要用户提供数据，必须使用 `helm install -f` 或 `helm install --set` 加载。\n\n本节总结了编写 Helm 模板所需工具和技术的深入讨论。下一节我们将介绍如何使用特殊文件 `templates/NOTES.txt` 向 chart 用户发送安装后说明。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: 内置对象\ndescription: 模板可用的内置对象\nsidebar_position: 3\n---\n\n对象可以通过模板引擎传递到模板中，你的代码也可以传递对象（使用 `with` 和 `range` 语句时会看到示例）。还有几种方式可以在模板中创建新对象，比如后面会介绍的 `tuple` 函数。\n\n对象可以是非常简单的，仅有一个值；也可以包含其他对象或方法。比如，`Release` 对象包含多个子对象（如 `Release.Name`），而 `Files` 对象则有一组方法。\n\n在上一节中，我们用 `{{ .Release.Name }}` 在模板中插入 release 名称。`Release` 是你可以在模板中访问的顶层对象之一。\n\n- `Release`：该对象描述 release 本身，包含以下子对象：\n  - `Release.Name`：release 名称\n  - `Release.Namespace`：release 的命名空间（如果 manifest 没有覆盖的话）\n  - `Release.IsUpgrade`：如果当前操作是升级或回滚，该值为 `true`\n  - `Release.IsInstall`：如果当前操作是安装，该值为 `true`\n  - `Release.Revision`：此次修订的版本号。安装时为 1，每次升级或回滚都会自增\n  - `Release.Service`：渲染当前模板的服务名称，在 Helm 中始终是 `Helm`\n- `Values`：从 `values.yaml` 文件和用户提供的文件传入模板的值，默认为空。\n- `Chart`：`Chart.yaml` 文件的内容。该文件中的所有数据都可以访问。例如 `{{ .Chart.Name }}-{{ .Chart.Version }}` 会输出 `mychart-0.1.0`\n  - 在 [Chart 指南](/topics/charts.md#the-chartyaml-file) 中列出了可用属性\n- `Subcharts`：提供对子 chart 作用域（.Values、.Charts、.Releases 等）的访问。例如 `.Subcharts.mySubChart.myValue` 可以访问 `mySubChart` chart 中的 `myValue`。\n- `Files`：在 chart 中提供访问所有非特殊文件的对象。你不能使用它访问模板，只能访问其他文件。请查看 [文件访问](./accessing_files.md) 部分了解更多信息。\n  - `Files.Get` 通过文件名获取文件的方法（`.Files.Get config.ini`）\n  - `Files.GetBytes` 以字节数组而非字符串形式获取文件内容的方法，对图片之类的文件很有用\n  - `Files.Glob` 用给定的 shell glob 模式匹配文件名并返回文件列表的方法\n  - `Files.Lines` 逐行读取文件内容的方法，迭代文件中每一行时很有用\n  - `Files.AsSecrets` 以 Base64 编码字符串形式返回文件内容的方法\n  - `Files.AsConfig` 以 YAML 格式返回文件内容的方法\n- `Capabilities`：提供关于 Kubernetes 集群支持功能的信息\n  - `Capabilities.APIVersions` 是一个版本集合\n  - `Capabilities.APIVersions.Has $version` 表示集群中某个版本（如 `batch/v1`）或资源（如 `apps/v1/Deployment`）是否可用\n  - `Capabilities.KubeVersion` 和 `Capabilities.KubeVersion.Version` 是 Kubernetes 版本号\n  - `Capabilities.KubeVersion.Major` Kubernetes 主版本号\n  - `Capabilities.KubeVersion.Minor` Kubernetes 次版本号\n  - `Capabilities.HelmVersion` 包含 Helm 版本详细信息的对象，与 `helm version` 的输出一致\n  - `Capabilities.HelmVersion.Version` 当前 Helm 版本（语义化版本格式）\n  - `Capabilities.HelmVersion.GitCommit` Helm 的 git sha1 值\n  - `Capabilities.HelmVersion.GitTreeState` Helm git 树的状态\n  - `Capabilities.HelmVersion.GoVersion` 使用的 Go 编译器版本\n- `Template`：包含当前正在执行的模板信息\n  - `Template.Name`：当前模板的命名空间文件路径（例如 `mychart/templates/mytemplate.yaml`）\n  - `Template.BasePath`：当前 chart 模板目录的路径（例如 `mychart/templates`）\n\n内置对象的名称都以大写字母开头，这符合 Go 的命名惯例。当你创建自己的名称时，可以按照团队约定自由设置。就像很多你在 [Artifact Hub](https://artifacthub.io/packages/search?kind=0) 中看到的 chart，其团队选择使用首字母小写将本地名称与内置对象区分开，本指南中我们也遵循该惯例。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: 流控制\ndescription: 模板中流结构的快速概述\nsidebar_position: 7\n---\n\n控制结构（在模板语言中称为\"actions\"）为模板作者提供了控制模板生成流程的能力。\nHelm的模板语言提供了以下控制结构：\n\n- `if`/`else`， 用来创建条件语句\n- `with`， 用来指定范围\n- `range`， 提供\"for each\"类型的循环\n\n除了这些之外，还提供了一些声明和使用命名模板的关键字：\n\n- `define` 在模板中声明一个新的命名模板\n- `template` 导入一个命名模板\n- `block` 声明一种特殊的可填充的模板块\n\n本节我们会讨论 `if`、`with` 和 `range`。其他内容会在本指南的“命名模板”部分说明。\n\n## If/Else\n\n第一个控制结构是在按照条件在一个模板中包含一个块文本。即`if`/`else`块。\n\n基本的条件结构看起来像这样：\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\n注意我们讨论的是 _管道_ 而不是值。这样做的原因是要清楚地说明控制结构可以执行整个管道，而不仅仅是计算一个值。\n\n如果是以下值时，管道会被设置为 _false_：\n\n- 布尔false\n- 数字0\n- 空字符串\n- `nil` (空或null)\n- 空集合(`map`, `slice`, `tuple`, `dict`, `array`)\n\n在所有其他条件下，条件都为true。\n\n让我们先在ConfigMap 中添加一个简单的条件。如果饮品是coffee会添加另一个配置：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\n由于我们在最后一个例子中注释了`drink: coffee`，输出中就不会包含`mug: \"true\"`标识。但如果将这行添加到`values.yaml`\n文件中，输入就会是这样：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## 控制空格\n\n查看条件时，我们需要快速了解一下模板中控制空白的方式，格式化之前的例子，使其更易于阅读：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\n初始情况下，看起来没问题。但是如果通过模板引擎运行时，我们将得到一个不幸的结果：\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\n发生了啥？因为空格导致生成了错误的YAML。\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug`的缩进是不对的。取消缩进重新执行一下：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\n这个就得到了合法的YAML，但是看起来还是有点滑稽：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\n注意在YAML中有一个空行，为什么？当模板引擎运行时，它 _移除了_ `{{` 和 `}}` 里面的内容，但是留下的空白完全保持原样。\n\nYAML认为空白是有意义的，因此管理空白变得很重要。幸运的是，Helm模板有些工具可以处理此类问题。\n\n首先，模板声明的大括号语法可以通过特殊的字符修改，并通知模板引擎取消空白。`{{- `(包括添加的横杠和空格)表示向左删除空白，\n而` -}}`表示右边的空格应该被去掉。 _注意！换行符也是空白字符！_\n\n> 要确保`-`和其他命令之间有一个空格。\n> `{{- 3 }}` 表示“删除左边空格并打印3”，而`{{-3 }}`表示“打印-3”。\n\n使用这个语法，我们就可修改我们的模板，去掉新加的空白行：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\n只是为了把这一点搞清楚，我们来调整上述内容，用一个`*`来代替每个遵循此规则被删除的空白，\n在行尾的`*`表示删除新行的字符：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\n记住这一点，我们可以通过Helm运行模板并查看结果：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n要注意这个删除字符的更改，很容易意外地出现情况：\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\n这样会变成`food: \"PIZZA\"mug:\"true\"`，因为这把两边的新行都删除了。\n\n> 关于模板中的空白控制，请查看[官方Go模板文档](https://godoc.org/text/template)\n\n最终，有时候告诉模板系统如何缩进会更容易，而不是试图控制模板指令间的间距。因此，你有时会发现使用 `indent` 函数（`{{ indent 2\n\"mug:true\" }}`）会很有用。\n\n## 使用 `with` 修改作用域\n\n下一个控制结构是`with`操作。这个用来控制变量范围。回想一下，`.`是对 _当前作用域_ 的引用。因此\n`.Values`就是告诉模板在当前作用域查找`Values`对象。\n\n`with`的语法与`if`语句类似：\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\n作用域可以被改变。`with`允许你为特定对象设定当前作用域(`.`)。比如，我们已经在使用`.Values.favorite`。\n修改ConfigMap 中的`.`的作用域指向`.Values.favorite`：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\n注意我们从之前的练习中移除了`if`条件，因为现在不需要了——`with`后面的块只有在 `PIPELINE` 的值不为空时才会执行。\n\n注意现在我们可以引用`.drink`和`.food`了，而不必限定他们。因为`with`语句设置了`.`指向`.Values.favorite`。\n`.`被重置为`{{ end }}`之后的上一个作用域。\n\n但是这里有个注意事项，在限定的作用域内，无法使用`.`访问父作用域的对象。错误示例如下：\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n这样会报错因为`Release.Name`不在`.`限定的作用域内。但是如果对调最后两行就是正常的，\n因为在`{{ end }}`之后作用域被重置了。\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\n或者，我们可以使用`$`从父作用域中访问`Release.Name`对象。当模板开始执行后`$`会被映射到根作用域，且执行过程中不会更改。\n下面这种方式也可以正常工作：\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\n在介绍了`range`之后，我们会看看模板变量，提供了上述作用域问题的另一种解决方案。\n\n## 使用`range`操作循环\n\n很多编程语言支持使用`for`循环，`foreach`循环，或者类似的方法机制。\n在Helm的模板语言中，在一个集合中迭代的方式是使用`range`操作符。\n\n开始之前，我们先在`values.yaml`文件添加一个披萨的配料列表：\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\n现在我们有了一个 `pizzaToppings` 列表（模板中称为切片）。修改模板把这个列表打印到 ConfigMap 中：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\n我们可以使用`$`从父作用域访问`Values.pizzaToppings`列表。当模板开始执行后`$`会被映射到根作用域，\n且执行过程中不会更改。下面这种方式也可以正常工作：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\n让我们仔细看看`toppings:`列表。`range`方法“涵盖”（迭代）`pizzaToppings`列表。但现在发生了有意思的事情。\n就像`with`设置了`.`的作用域，`range`操作符也做了同样的事。每一次循环，`.`都会设置为当前的披萨配料。\n也就是说，第一次`.`设置成了`mushrooms`，第二次迭代设置成了`cheese`，等等。\n\n我们可以直接发送`.`的值给管道，因此当我们执行`{{ . | title | quote }}`时，它会发送`.`到`title`然后发送到`quote`。\n如果执行这个模板，输出是这样的：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\n现在，我们已经处理了一些棘手的事情。`toppings: |-`行是声明的多行字符串。所以这个配料列表实际上不是YAML列表，\n而是一个大字符串。为什么要这样做？因为 ConfigMap 的 `data` 中的数据是由键值对组成，key 和 value 都是简单的字符串。\n要理解这个示例，请查看 [Kubernetes ConfigMap 文档](https://kubernetes.io/docs/concepts/configuration/configmap/)。\n但对于我们来说，这个细节并不重要。\n\n> 正如例子中所示，`|-`标识在YAML中是指多行字符串。这在清单列表中嵌入大块数据是很有用的技术。\n\n有时能在模板中快速创建列表然后迭代很有用，Helm模板的`tuple`可以很容易实现该功能。在计算机科学中，\n元组表示一个有固定大小的类似列表的集合，但可以是任意数据类型。这大致表达了`tuple`的用法。\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\n上述模板会生成以下内容：\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\n除了列表和元组，`range`可被用于迭代有键值对的集合（像`map`或`dict`）。我们会在下一部分介绍模板变量是看到它是如何应用的。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: 附录：Go 数据类型和模板\ndescription: 模板中变量的简单概述。\nsidebar_position: 16\n---\n\nHelm 模板语言是用强类型 Go 编程语言实现的。因此，模板中的变量是 _有类型的_。大多数情况下，变量将作为以下类型之一显示：\n\n- string：文本字符串\n- bool：`true` 或 `false`\n- int：整型值（包含 8 位、16 位、32 位和 64 位有符号及无符号整数）\n- float64：64 位浮点数（也有 8 位、16 位、32 位类型）\n- 字节切片（`[]byte`），常用于保存（可能的）二进制数据\n- struct：有属性和方法的对象\n- 上述某种类型的切片（索引列表）\n- 字符串键的 map（`map[string]interface{}`），值是上述某种类型\n\nGo 里面有很多其他类型，有时你需要在模板里进行转换。调试对象类型最简便的方式是在模板中传递给 `printf \"%T\"`，这样会打印类型。也可以使用 `typeOf` 和 `kindOf` 函数。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: 调试模板\ndescription: 对部署失败的 chart 进行故障排除。\nsidebar_position: 13\n---\n\n调试模板可能很棘手，因为渲染后的模板会发送给 Kubernetes API server，可能会因格式以外的原因拒绝 YAML 文件。\n\n以下命令有助于调试：\n\n- `helm lint` 是验证 chart 是否遵循最佳实践的首选工具。\n- `helm template --debug` 可在本地测试 chart 模板的渲染。\n- `helm install --dry-run --debug` 同样会在本地渲染 chart 而不实际安装，同时还会检查集群上是否存在冲突的资源。设置 `--dry-run=server` 会将 chart 中的任何 `lookup` 发送到服务器执行。\n- `helm get manifest`：这是查看服务器上已安装模板的好方法。\n\n当你的 YAML 文件解析失败，但你想知道生成了什么，一个简单的方式是注释掉模板中有问题的部分，然后重新运行 `helm install --dry-run --debug`：\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\n以上内容会被渲染，同时返回完整的注释：\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\n这样可以快速查看生成的内容，而不会被 YAML 解析错误阻塞。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: 模板函数列表\ndescription: Helm中模板函数变量的列表\nsidebar_position: 6\n---\n\nHelm 包含了很多可以在模板中利用的模板函数。以下列出了具体分类：\n\n* [Cryptographic and Security](#cryptographic-and-security-functions)\n* [Date](#date-functions)\n* [Dictionaries](#dictionaries-and-dict-functions)\n* [Encoding](#encoding-functions)\n* [File Path](#file-path-functions)\n* [Kubernetes and Chart](#kubernetes-and-chart-functions)\n* [Logic and Flow Control](#logic-and-flow-control-functions)\n* [Lists](#lists-and-list-functions)\n* [Math](#math-functions)\n* [Float Math](#float-math-functions)\n* [Network](#network-functions)\n* [Reflection](#reflection-functions)\n* [Regular Expressions](#regular-expressions)\n* [Semantic Versions](#semantic-version-functions)\n* [String](#string-functions)\n* [Type Conversion](#type-conversion-functions)\n* [URL](#url-functions)\n* [UUID](#uuid-functions)\n\n## Logic and Flow Control Functions\n\nHelm 包括了许多逻辑和流控制函数，包括[and](#and)、[coalesce](#coalesce)、[default](#default)、\n[empty](#empty)、[eq](#eq)、[fail](#fail)、[ge](#ge)、[gt](#gt)、[le](#le)、[lt](#lt)、\n[ne](#ne)、[not](#not)、[or](#or)和[required](#required)。\n\n### and\n\n返回两个或多个参数的布尔AND值（返回第一个空参数，或最后一个参数）。\n\n```yaml\nand .Arg1 .Arg2\n```\n\n### or\n\n返回两个参数的or布尔值。会返回第一个非空参数或最后一个参数。\n\n```yaml\nor .Arg1 .Arg2\n```\n\n### not\n\n返回参数的布尔求反。\n\n```yaml\nnot .Arg\n```\n\n### eq\n\n返回参数的布尔等式（比如， Arg1 == Arg2）。\n\n```yaml\neq .Arg1 .Arg2\n```\n\n### ne\n\n返回参数的布尔非等式（比如 Arg1 != Arg2）。\n\n```yaml\nne .Arg1 .Arg2\n```\n\n### lt\n\n如果第一参数小于第二参数，返回布尔真。否则返回假（比如， Arg1 < Arg2）。\n\n```yaml\nlt .Arg1 .Arg2\n```\n\n### le\n\n如果第一参数小于等于第二参数，返回布尔真，否则返回假（比如， Arg1 <= Arg2）。\n\n```yaml\nle .Arg1 .Arg2\n```\n\n### gt\n\n如果第一参数大于第二参数，返回布尔真，否则返回假（比如， Arg1 > Arg2）。\n\n```yaml\ngt .Arg1 .Arg2\n```\n\n### ge\n\n如果第一参数大于等于第二参数，返回布尔真，否则返回假。（比如， Arg1 >= Arg2）。\n\n```yaml\nge .Arg1 .Arg2\n```\n\n### default\n\n使用`default`设置一个简单的默认值。\n\n```yaml\ndefault \"foo\" .Bar\n```\n\n上述示例中，如果`.Bar`是非空值，则使用它，否则会返回`foo`。\n\n\"空\"定义取决于以下类型：\n\n* 整型: 0\n* 字符串: \"\"\n* 列表: `[]`\n* 字典: `{}`\n* 布尔: `false`\n* 以及所有的`nil` (或 null)\n\n对于结构体，没有空的定义，所以结构体从来不会返回默认值。\n\n### required\n\n使用 `required` 指定必须设置的值：\n\n```\nrequired \"A valid foo is required!\" .Bar\n```\n\n如果 `.Bar` 为空或未定义（参阅 [default](#default) 了解如何判断空值），模板将不会渲染，而是返回所提供的错误信息。\n\n### empty\n\n如果给定的值被认为是空的，则`empty`函数返回`true`，否则返回`false`。空值列举在`default`部分。\n\n```yaml\nempty .Foo\n```\n\n注意在Go模板条件中，空值是为你计算出来的。这样你很少需要 `if not empty .Foo` ，仅使用 `if .Foo` 即可。\n\n### fail\n\n无条件地返回带有指定文本的空 `string` 或者 `error`。这在其他条件已经确定而模板渲染应该失败的情况下很有用。\n\n```yaml\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\n`coalesce`函数获取一个列表并返回第一个非空值。\n\n```yaml\ncoalesce 0 1 2\n```\n\n上述会返回`1`。\n\n此函数用于扫描多个变量或值：\n\n```yaml\ncoalesce .name .parent.name \"Matt\"\n```\n\n上述示例会优先检查 `.name` 是否为空。如果不是，就返回值。如果 _是_ 空, 继续检查`.parent.name`。\n最终，如果 `.name` 和 `.parent.name` 都是空，就会返回 `Matt`。\n\n### ternary\n\n`ternary`函数获取两个值和一个test值。如果test值是true，则返回第一个值。如果test值是空，则返回第二个值。\n这和C或其他编程语言中的的ternary运算符类似。\n\n#### true test value\n\n```yaml\nternary \"foo\" \"bar\" true\n```\n\n或者\n\n```yaml\ntrue | ternary \"foo\" \"bar\"\n```\n\n上述返回 `\"foo\"`。\n\n#### false test value\n\n```yaml\nternary \"foo\" \"bar\" false\n```\n\n或者\n\n```yaml\nfalse | ternary \"foo\" \"bar\"\n```\n\n上述返回 `\"bar\"`.\n\n## String Functions\n\nHelm 包含了以下字符串函数： [abbrev](#abbrev),\n[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat),\n[contains](#contains), [hasPrefix](#hasprefix-and-hassuffix),\n[hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials),\n[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent),\n[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf),\n[println](#println), [quote](#quote-and-squote),\n[randAlpha](#randalphanum-randalpha-randnumeric-and-randascii),\n[randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii),\n[randAscii](#randalphanum-randalpha-randnumeric-and-randascii),\n[randNumeric](#randalphanum-randalpha-randnumeric-and-randascii),\n[repeat](#repeat), [replace](#replace), [shuffle](#shuffle),\n[snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr),\n[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall),\n[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc),\n[untitle](#untitle), [upper](#upper), [wrap](#wrap), 和 [wrapWith](#wrapwith)\n\n### print\n\n返回各部分组合的字符串。\n\n```yaml\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\n如果可能，非字符串类型会被转换成字符串。\n\n注意，当相邻两个参数不是字符串时会在它们之间添加一个空格。\n\n### println\n\n和[print](#print)效果一样，但会在末尾新添加一行。\n\n### printf\n\n返回参数按顺序传递的格式化字符串。\n\n```yaml\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\n占位符取决于传入的参数类型。这包括：\n\n一般用途：\n\n* `%v` 默认格式的值\n  * 当打印字典时，加号参数(`%+v`)可以添加字段名称\n* `%%` 字符百分号，不使用值\n\n布尔值：\n\n* `%t` true或false\n\n整型：\n\n* `%b` 二进制\n* `%c` the character represented by the corresponding Unicode code point\n* `%d` 十进制\n* `%o` 8进制\n* `%O` 带0o前缀的8进制\n* `%q` 安全转义的单引号字符\n* `%x` 16进制，使用小写字符a-f\n* `%X` 16进制，使用小写字符A-F\n* `%U` Unicode格式： U+1234; 和\"U+%04X\"相同\n\n浮点数和复杂成分\n\n* `%b` 指数二次幂的无小数科学计数法，比如 -123456p-78\n* `%e` 科学计数法，比如： -1.234456e+78\n* `%E` 科学计数法，比如： -1.234456E+78\n* `%f` 无指数的小数，比如： 123.456\n* `%F` 与%f同义\n* `%g` %e的大指数，否则是%f\n* `%G` %E的大指数，否则是%F\n* `%x` 十六进制计数法(和两个指数的十进制幂)，比如： -0x1.23abcp+20\n* `%X` 大写的十六进制计数法，比如： -0X1.23ABCP+20\n\n字符串和字节切片：\n\n* `%s` 未解析的二进制字符串或切片\n* `%q` 安全转义的双引号字符串\n* `%x` 十六进制，小写，每个字节两个字符\n* `%X` 十六进制，大写，每个字节两个字符\n\n切片：\n\n* `%p` 16进制的第0个元素的地址，以0x开头\n\n### trim\n\n`trim`函数移除字符串两边的空格：\n\n```yaml\ntrim \"   hello    \"\n```\n\n上述结果为： `hello`\n\n### trimAll\n\n从字符串中移除给定的字符：\n\n```yaml\ntrimAll \"$\" \"$5.00\"\n```\n\n上述结果为：`5.00` (作为一个字符串)。\n\n### trimPrefix\n\n从字符串中移除前缀：\n\n```yaml\ntrimPrefix \"-\" \"-hello\"\n```\n\n上述结果为：`hello`\n\n### trimSuffix\n\n从字符串中移除后缀：\n\n```yaml\ntrimSuffix \"-\" \"hello-\"\n```\n\n上述结果为： `hello`\n\n### lower\n\n将整个字符串转换成小写：\n\n```yaml\nlower \"HELLO\"\n```\n\n上述结果为： `hello`\n\n### upper\n\n将整个字符串转换成大写：\n\n```yaml\nupper \"hello\"\n```\n\n上述结果为： `HELLO`\n\n### title\n\n首字母转换成大写：\n\n```yaml\ntitle \"hello world\"\n```\n\n上述结果为： `Hello World`\n\n### untitle\n\n移除首字母大写：`untitle \"Hello World\"` 会得到 `hello world`.\n\n### repeat\n\n重复字符串多次：\n\n```yaml\nrepeat 3 \"hello\"\n```\n\n上述结果为： `hellohellohello`\n\n### substr\n\n获取字符串的子串，有三个参数：\n\n* start (int)\n* end (int)\n* string (string)\n\n```yaml\nsubstr 0 5 \"hello world\"\n```\n\n上述结果为： `hello`\n\n### nospace\n\n去掉字符串中的所有空格：\n\n```yaml\nnospace \"hello w o r l d\"\n```\n\n上述结果为： `helloworld`\n\n### trunc\n\n截断字符串。\n\n```yaml\ntrunc 5 \"hello world\"\n```\n\n上述结果为： `hello`.\n\n```yaml\ntrunc -5 \"hello world\"\n```\n\n上述结果为： `world`.\n\n### abbrev\n\n用省略号截断字符串 (`...`)\n\n参数：\n\n* 最大长度\n* 字符串\n\n```yaml\nabbrev 5 \"hello world\"\n```\n\n上述结果为： `he...`， 因为将省略号算进了长度中。\n\n### abbrevboth\n\n两边都省略\n\n```yaml\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\n上述结果为： `...5678...`\n\nIt takes:\n\n* 左侧偏移值\n* 最大长度\n* 字符串\n\n### initials\n\n截取给定字符串每个单词的首字母，并组合在一起。\n\n```yaml\ninitials \"First Try\"\n```\n\n上述结果为： `FT`\n\n### randAlphaNum, randAlpha, randNumeric, and randAscii\n\n这四个字符串生成加密安全的(使用 ```crypto/rand```)的随机字符串，但是字符集合不同：\n\n* `randAlphaNum` 使用 `0-9a-zA-Z`\n* `randAlpha` 使用 `a-zA-Z`\n* `randNumeric` 使用 `0-9`\n* `randAscii` 使用所有的可打印ASCII字符\n\n每个函数都需要一个参数：字符串的整型长度\n\n```yaml\nrandNumeric 3\n```\n\n上述会生成三个数字的字符串。\n\n### wrap\n\n以给定列数给文字换行。\n\n```yaml\nwrap 80 $someText\n```\n\n上述结果会以`$someText`在80列处换行。\n\n### wrapWith\n\n`wrapWith` 和 `wrap` 类似，但可以以指定字符串换行。(`wrap` 使用的是 `\\n`)\n\n```yaml\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\n上述结果为： `hello world` (其中空格是ASCII tab字符)\n\n### contains\n\n测试字符串是否包含在另一个字符串中：\n\n```yaml\ncontains \"cat\" \"catch\"\n```\n\n上述结果为： `true` 因为 `catch` 包含了 `cat`.\n\n### hasPrefix and hasSuffix\n\n`hasPrefix` 和 `hasSuffix` 函数测试字符串是否有给定的前缀或后缀：\n\n```yaml\nhasPrefix \"cat\" \"catch\"\n```\n\n上述结果为： `true` 因为 `catch` 有 `cat`.\n\n### quote and squote\n\n该函数将字符串用双引号(`quote`) 或者单引号(`squote`)括起来。\n\n### cat\n\n`cat` 函数将多个字符串合并成一个，用空格分隔：\n\n```yaml\ncat \"hello\" \"beautiful\" \"world\"\n```\n\n上述结果为： `hello beautiful world`\n\n### indent\n\n`indent` 以指定长度缩进给定字符串所在行，在对齐多行字符串时很有用：\n\n```yaml\nindent 4 $lots_of_text\n```\n\n上述结果会将每行缩进4个空格。\n\n### nindent\n\n`nindent` 函数和indent函数一样，但可以在字符串开头添加新行。\n\n```yaml\nnindent 4 $lots_of_text\n```\n\n上述结果会在字符串所在行缩进4个字符，并且在开头新添加一行。\n\n### replace\n\n执行简单的字符串替换。\n\n需要三个参数\n\n* 待替换字符串\n* 要替换字符串\n* 源字符串\n\n```yaml\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\n上述结果为： `I-Am-Henry-VIII`\n\n### plural\n\n字符串复数化。\n\n```yaml\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\n如上，如果字符串长度为1，则第一个参数会被打印(`one anchovy`）。否则，会打印第二个参数(`many anchovies`）。\n\n参数包括：\n\n* 单数字符串\n* 复数字符串\n* 整型长度\n\n注意： Helm 现在不支持多语言复杂的复数规则。`0`被认为是复数的因为英文中作为(`zero anchovies`) 对待。\n\n### snakecase\n\n将驼峰写法转换成蛇形写法。\n\n```yaml\nsnakecase \"FirstName\"\n```\n\n上述结果为： `first_name`.\n\n### camelcase\n\n将字符串从蛇形写法转换成驼峰写法。\n\n```yaml\ncamelcase \"http_server\"\n```\n\n上述结果为： `HttpServer`。\n\n### kebabcase\n\n将驼峰写法转换成烤串写法。\n\n```yaml\nkebabcase \"FirstName\"\n```\n\n上述结果为： `first-name`.\n\n### swapcase\n\n基于单词的算法切换字符串的大小写。\n\n转换算法：\n\n* 大写字符变成小写字母\n* 首字母变成小写字母\n* 空格后或开头的小写字母转换成大写字母\n* 其他小写字母转换成大写字母\n* 通过unicode.IsSpace(char)定义空格\n\n```yaml\nswapcase \"This Is A.Test\"\n```\n\n上述结果为： `tHIS iS a.tEST`.\n\n### shuffle\n\n对字符串进行洗牌。\n\n```yaml\nshuffle \"hello\"\n```\n\n上述`hello`的随机字符串可能会是`oelhl`。\n\n## Type Conversion Functions\n\nHelm提供了以下类型转换函数：\n\n* `atoi`: 字符串转换成整型。\n* `float64`: 转换成 `float64`。\n* `int`: 按系统整型宽度转换成`int`。\n* `int64`: 转换成 `int64`。\n* `toDecimal`: 将unix八进制转换成`int64`。\n* `toString`: 转换成字符串。\n* `toStrings`: 将列表、切片或数组转换成字符串列表。\n* `toJson` (`mustToJson`): 将列表、切片、数组、字典或对象转换成JSON。\n* `toPrettyJson` (`mustToPrettyJson`): 将列表、切片、数组、字典或对象转换成格式化JSON。\n* `toRawJson` (`mustToRawJson`): 将列表、切片、数组、字典或对象转换成HTML字符未转义的JSON。\n* `fromYaml`：将YAML字符串转化成对象。\n* `fromJson`: 将JSON字符串转化成对象。\n* `toYaml`: 将列表，切片，数组，字典或对象转换成已缩进的yaml，可以从任意源拷贝yaml块。该功能和Go的yaml.Marshal函数一样，文档详见：https://pkg.go.dev/gopkg.in/yaml.v2#Marshal\n\n只有`atoi`需要输入一个特定的类型。其他的会尝试将任何类型转换成目标类型。比如，`int64`可以把浮点数转换成整型，也可以把字符串转换成整型。\n\n### toStrings\n\n给定一个类列表集合，输出字符串切片。\n\n```yaml\nlist 1 2 3 | toStrings\n```\n\n上述会将`1`转成`\"1\"`，`2`转成`\"2\"`，等等，然后将其作为列表返回。\n\n### toDecimal\n\n给定一个unix八进制权限，转换成十进制。\n\n```yaml\n\"0777\" | toDecimal\n```\n\n上述会将 `0777` 转换成 `511` 并返回int64的值。\n\n### toJson, mustToJson\n\n`toJson`函数将内容编码为JSON字符串。如果内容无法被转换成JSON会返回空字符串。`mustToJson`会返回错误以防无法编码成JSON。\n\n```yaml\ntoJson .Item\n```\n\n上述结果为： `.Item`的JSON字符串表示。\n\n### toPrettyJson, mustToPrettyJson\n\n`toPrettyJson`函数将内容编码为好看的（缩进的）JSON字符串。\n\n```yaml\ntoPrettyJson .Item\n```\n\n上述结果为： `.Item`的已缩进的JSON字符串表示。\n\n### toRawJson, mustToRawJson\n\n`toRawJson` 函数将内容编码成包含非转义HTML字符的JSON字符串。\n\n```yaml\ntoRawJson .Item\n```\n\n上述结果为： `.Item`的非转义的JSON字符串表示。\n\n### fromYaml\n\n`fromYaml` 函数将YAML字符串转换成模板可用的对象。\n\n`文件位置: yamls/person.yaml`\n\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\n`fromJson` 函数将JSON字符串转换成模板可用的对象。\n\n`文件位置: jsons/person.json`\n\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJsonArray\n\n`fromJsonArray` 函数接受一个 JSON 数组并返回一个可在模板中使用的列表。\n\n`文件位置: jsons/people.json`\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml, toYamlPretty\n\n`toYaml` 和 `toYamlPretty` 函数将对象（列表、切片、数组、字典或对象）编码为缩进的 YAML 字符串。\n\n> 注意：`toYamlPretty` 功能相同，但会为列表元素添加额外的缩进\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\n`fromYamlArray` 函数接受一个 YAML 数组并返回一个可在模板中使用的列表。\n\n`文件位置: yamls/people.yml`\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n## Regular Expressions\n\nHelm 包含以下正则表达式函数 [regexFind(mustRegexFind)](#regexfindall-mustregexfindall),\n[regexFindAll(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch\n(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll\n(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall),\n[regexReplaceAllLiteral(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral),\n[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit)。\n\n### regexMatch, mustRegexMatch\n\n如果输入字符串包含可匹配正则表达式任意字符串，则返回true。\n\n```yaml\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\n上述结果为： `true`\n\n`regexMatch`有问题时会出错， `mustRegexMatch`有问题时会向模板引擎返回错误。\n\n### regexFindAll, mustRegexFindAll\n\n返回输入字符串匹配正则表达式的所有切片。最后一个参数表示要返回的子字符串的数量，-1表示返回所有。\n\n```yaml\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\n上述结果为： `[2 4 6 8]`\n\n`regexFindAll` 有问题时会出错， `mustRegexFindAll` 有问题时会向模板引擎返回错误。\n\n### regexFind, mustRegexFind\n\n返回输入字符串的第一个 (最左边的) 正则匹配。\n\n```yaml\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\n上述结果为： `d1`\n\n`regexFind` 有问题时会出错， `mustRegexFind` 有问题时会向模板引擎返回错误。\n\n### regexReplaceAll, mustRegexReplaceAll\n\n返回输入字符串的拷贝，用替换字符串替换Regexp的匹配项。在替换字符串里面，$ 标志被解释为扩展，因此对于实例来说 $1 表示第一个子匹配的文本。第一个参数是`<pattern>`，第二个是`<input>`，第三个是`<replacement>`。\n\n```yaml\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\n上述结果为： `-W-xxW-`\n\n`regexReplaceAll` 有问题时会出错， `mustRegexReplaceAll` 有问题时会向模板引擎返回错误。\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\n返回输入字符串的拷贝，用替换字符串替换Regexp的匹配项。匹配字符串直接替换而不是扩展。第一个参数是`<pattern>`，第二个是`<input>`，第三个是`<replacement>`。\n\n```yaml\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\n上述结果为： `-${1}-${1}-`\n\n`regexReplaceAllLiteral` 有问题时会出错，`mustRegexReplaceAllLiteral` 有问题时会向模板引擎返回错误。\n\n### regexSplit, mustRegexSplit\n\n将输入字符串切成有表达式分隔的子字符串，并返回表达式匹配项之间的切片。最后一个参数`n`确定要返回的子字符串数量，`-1`表示返回所有匹配。\n\n```yaml\nregexSplit \"z+\" \"pizza\" -1\n```\n\n上述结果为： `[pi a]`\n\n`regexSplit` 有问题时会出错，`mustRegexSplit` 有问题时会向模板引擎返回错误。\n\n## Cryptographic and Security Functions\n\nHelm提供了一些高级的加密函数。包括了 [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert),\n[decryptAES](#decryptaes), [derivePassword](#derivepassword),[encryptAES](#encryptaes),\n[genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert),\n[genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum)，以及 [sha256sum](#sha256sum)。\n\n### sha1sum\n\n`sha1sum`函数接收一个字符串，并计算它的SHA1摘要。\n\n```yaml\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\n`sha256sum` 函数接收一个字符串，并计算它的SHA256摘要。\n\n```yaml\nsha256sum \"Hello world!\"\n```\n\n上述语句会以“ASCII包装”格式计算SHA 256 校验和，并安全打印出来。\n\n### adler32sum\n\n`adler32sum`函数接收一个字符串，并计算它的Adler-32校验和。 \n\n```yaml\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\n`htpasswd` 函数使用`username` 和 `password` 生成一个密码的`bcrypt`哈希值。该结果可用于[Apache HTTP \nServer](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic) 的基础认证。\n\n```yaml\nhtpasswd \"myUser\" \"myPassword\"\n```\n\n注意，将密码直接存储在模板中并不安全。\n\n### randBytes\n\n`randBytes` 函数接受一个数量 N，生成一个加密安全的（使用 crypto/rand）N 字节随机序列。返回值为 base64 编码的字符串。\n\n```\nrandBytes 24\n```\n\n### derivePassword\n\n`derivePassword` 函数可用于基于某些共享的“主密码”约束得到特定密码。这方面的算法有[详细说明](https://spectre.app/spectre-algorithm.pdf)。\n\n```yaml\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\n注意，将这部分直接存储在模板中并不安全。\n\n### genPrivateKey\n\n`genPrivateKey` 函数生成一个编码成PEM块的新私钥。\n\n第一个参数会采用以下某个值：\n\n* `ecdsa`: 生成椭圆曲线 DSA key (P256)\n* `dsa`: 生成 DSA key (L2048N256)\n* `rsa`: 生成 RSA 4096 key\n\n### buildCustomCert\n\n`buildCustomCert` 函数允许自定义证书。\n\n会采用以下字符串参数：\n\n* base64 编码PEM格式证书\n* base64 编码PEM格式私钥\n\n返回包含以下属性的整数对象：\n\n* `Cert`:PEM编码证书\n* `Key`: PEM编码私钥\n\n示例：\n\n```yaml\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\n注意返回的对象可以使用这个CA传递给`genSignedCert`函数进行签名。\n\n### genCA\n\n`genCA` 函数生成一个新的，自签名的x509 证书机构。\n\n会采用以下参数：\n\n* 主体通用名 (cn)\n* 证书有效期（天）\n\n会返回一个包含以下属性的对象：\n\n* `Cert`: PEM编码证书\n* `Key`: PEM编码私钥\n\n示例：\n\n```yaml\n$ca := genCA \"foo-ca\" 365\n```\n\n注意返回的对象可以使用这个CA传递给`genSignedCert`函数进行签名。\n\n### genSelfSignedCert\n\nThe `genSelfSignedCert` 函数生成一个新的，自签名的x509 证书。\n\n会采用下列参数：\n\n* 主体通用名 (cn)\n* 可选IP列表；可以为空\n* 可选备用DNS名称列表；可以为空\n* 证书有效期（天）\n\n会返回一个包含以下属性的对象：\n\n* `Cert`: PEM编码证书\n* `Key`: PEM编码私钥\n\n示例：\n\n```yaml\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\n`genSignedCert` 通过指定的CA签名生成一个新的， x509证书\n\n会采用以下参数：\n\n* 主体通用名 (cn)\n* 可选IP列表；可以为空\n* 可选备用DNS名称列表；可以为空\n* 证书有效期（天）\n* CA (查看 `genCA`)\n\n示例：\n\n```yaml\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\n`encryptAES` 函数使用AES-256 CBC 加密文本并返回一个base64编码字符串。\n\n```yaml\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\n`decryptAES`函数接收一个AES-256 CBC编码的字符串并返回解密文本。\n\n```yaml\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Date Functions\n\nHelm 包含以下可以在模板中使用的函数：[ago](#ago), [date](#date), [dateInZone](#dateinzone),\n[dateModify(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration),\n[durationRound](#durationround), [htmlDate](#htmldate),\n[htmlDateInZone](#htmldateinzone), [now](#now),\n[toDate(mustToDate)](#todate-musttodate), and [unixEpoch](#unixepoch)。\n\n### now\n\n当前日期/时间。和其他日期函数一起使用。\n\n### ago\n\n`ago` 函数返回距time.Now的以秒为单位的间隔时间。\n\n```yaml\nago .CreatedAt\n```\n\n返回`time.Duration`的字符串格式\n\n```yaml\n2h34m7s\n```\n\n### date\n\n`date`函数格式化日期\n\n日期格式化为YEAR-MONTH-DAY：\n\n```yaml\nnow | date \"2006-01-02\"\n```\n\n日期格式化在Go中有[一些不同](https://pauladamsmith.com/blog/2011/05/go_time.html)。\n\n简言之，以此为基准日期：\n\n```yaml\nMon Jan 2 15:04:05 MST 2006\n```\n\n将其写成你想要的格式，上面的例子中，`2006-01-02` 是同一个日期，却是我们需要的格式。\n\n### dateInZone\n\n和 `date` 一样，但是和时区一起。\n\n```yaml\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\n将给定的秒数格式化为`time.Duration`。\n\n这会返回 1m35s。\n\n```yaml\nduration 95\n```\n\n### durationRound\n\n将给定时间舍入到最重要的单位。当`time.Time`计算为一个自某个时刻以来的时间，字符串和`time.Duration`被解析为一个时间段。\n\n这会返回2h\n\n```yaml\ndurationRound \"2h10m5s\"\n```\n\n这会返回3mo\n\n```yaml\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\n返回`time.Time`的unix时间戳。\n\n```yaml\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\n`dateModify` 给定一个修改日期并返回时间戳。\n\n从当前时间减去一个小时三十分钟：\n\n```yaml\nnow | date_modify \"-1.5h\"\n```\n\n如果修改格式错误， `dateModify`会返回日期未定义。而`mustDateModify`会返回错误。\n\n### htmlDate\n\n`htmlDate`函数用于格式化插入到HTML日期选择器输入字段的日期。\n\n```yaml\nnow | htmlDate\n```\n\n### htmlDateInZone\n\n和htmlDate一样，但多了个时区。\n\n```yaml\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\n`toDate` 将字符串转换成日期。第一个参数是日期格式，第二个参数是日期字符串。\n如果字符串无法转换就会返回0值。`mustToDate`以防无法转换会返回错误。\n\n这在你将日期字符串转换成其他格式时很有用（使用pipe）。下面的例子会将\"2017-12-31\" 转换成 \"31/12/2017\"。\n\n```yaml\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Dictionaries and Dict Functions\n\nHelm 提供了一个key/value存储类型称为`dict`（\"dictionary\"的简称，Python中也有）。`dict`是无序类型。\n\n字典的key **必须是字符串**。但值可以是任意类型，甚至是另一个`dict` 或 `list`。\n\n不像`list`， `dict`不是不可变的。`set`和`unset`函数会修改字典的内容。\n\nHelm 提供了以下函数支持使用字典：[deepCopy(mustDeepCopy)](#deepcopy-mustdeepcopy),\n[dict](#dict), [dig](#dig), [get](#get),[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge),\n[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite),\n[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset),和[values](#values)。\n\n### dict\n\n通过调用`dict`函数并传递一个键值对列表创建字典。\n\n下面是创建三个键值对的字典：\n\n```yaml\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\n给定一个映射和一个键，从映射中获取值。\n\n```yaml\nget $myDict \"name1\"\n```\n\n上述结果为： `\"value1\"`\n\n注意如果没有找到，会简单返回`\"\"`。不会生成error。\n\n### set\n\n使用`set`给字典添加一个键值对。\n\n```yaml\n$_ := set $myDict \"name4\" \"value4\"\n```\n\n注意`set` _返回字典_ (Go模板函数的一个要求)，因此你可能需要像上面那样使用使用`$_`赋值来获取值。\n\n### unset\n\n给定一个映射和key，从映射中删除这个key。\n\n```yaml\n$_ := unset $myDict \"name4\"\n```\n\n和`set`一样，需要返回字典。\n\n注意，如果key没有找到，这个操作会简单返回，不会生成错误。\n\n### hasKey\n\n`hasKey`函数会在给定字典中包含了给定key时返回`true`。\n\n```yaml\nhasKey $myDict \"name1\"\n```\n\n如果key没找到，会返回`false`。\n\n### pluck\n\n`pluck` 函数给定一个键和多个映射，并获得所有匹配项的列表：\n\n```yaml\npluck \"name1\" $myDict $myOtherDict\n```\n\n上述会返回的`list`包含了每个找到的值(`[value1 otherValue1]`)。\n\n如果key在映射中 _没有找到_ ，列表中的映射就不会有内容（并且返回列表的长度也会小于调用`pluck`的字典）。\n\n如果key是 _存在的_， 但是值是空值，会插入一个值。\n\nHelm模板中的一个常见用法是使用`pluck... | first` 从字典集合中获取第一个匹配的键。\n\n### dig\n\n`dig` 函数遍历嵌套的字典，从值列表中选择键。如果在关联的字典中找不到键，会返回默认值。\n\n```yaml\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\n给一个结构化的字典如下：\n\n```yaml\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\n那上述命令就会返回`\"curator\"`。 如果字典连`user`都没有，就会返回`\"guest\"`。\n\n如果你想避开保护规则，dig就很有用，特别是Go模板包的`and`没有快捷方式。譬如\n`and a.maybeNil a.maybeNil.iNeedThis`\n总是会描述为`a.maybeNil.iNeedThis`，如果 `maybeNil` 字段缺少 `a` 就会报错。\n\n`dig` 为了支持管道符会接受字典参数，比如：\n\n```yaml\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\n将两个或多个字典合并为一个， 目标字典优先：\n\n给出：\n\n```yaml\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\n会得到结果：\n\n```yaml\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n\n```yaml\n$newdict := merge $dest $source1 $source2\n```\n\n这是个深度合并操作，但不是深度拷贝操作。合并的嵌套对象是两个字典上的同一实例。如果想深度合并的同时进行深度拷贝，\n合并的时候同时使用`deepCopy`函数，比如：\n\n```yaml\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` 会返回错误，以防出现不成功的合并。\n\n### mergeOverwrite, mustMergeOverwrite\n\n合并两个或多个字典，优先按照 **从右到左**，在目标字典中有效地覆盖值：\n\n给定的：\n\n```yaml\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\n会生成：\n\n```yaml\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```yaml\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\n这是一个深度合并操作但不是深度拷贝操作。两个字典上嵌入的对象被合并到了同一个实例中。如果你想在合并的同时进行深度拷贝，\n使用`deepCopy`函数，比如：\n\n```yaml\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` 会返回错误，以防出现不成功的合并。\n\n### keys\n\n`keys`函数会返回一个或多个`dict`类型中所有的key的`list`。由于字典是 _无序的_，key不会有可预料的顺序。\n可以使用`sortAlpha`存储。\n\n```yaml\nkeys $myDict | sortAlpha\n```\n\n当提供了多个词典时，key会被串联起来。使用`uniq`函数和`sortAlpha`获取一个唯一有序的键列表。\n\n```yaml\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\n`pick`函数只从字典中选择给定的键，并创建一个新的`dict`。\n\n```yaml\n$new := pick $myDict \"name1\" \"name2\"\n```\n\n上述结果为： `{name1: value1, name2: value2}`\n\n### omit\n\n`omit`函数类似于`pick`，除它之外返回一个新的`dict`，所有的key _不_ 匹配给定的key。\n\n```yaml\n$new := omit $myDict \"name1\" \"name3\"\n```\n\n上述结果为： `{name2: value2}`\n\n### values\n\n`values`函数类似于`keys`，返回一个新的`list`包含源字典中所有的value(只支持一个字典)。\n\n```yaml\n$vals := values $myDict\n```\n\n上述结果为： `list[\"value1\", \"value2\", \"value 3\"]`。注意 `values`不能保证结果的顺序；如果你需要顺序，\n请使用`sortAlpha`。\n\n### deepCopy, mustDeepCopy\n\n`deepCopy` 和 `mustDeepCopy` 函数给定一个值并深度拷贝这个值。包括字典和其他结构体。 `deepCopy`有问题时会出错，\n而`mustDeepCopy`会返回一个错误给模板系统。\n\n```yaml\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### 字典的内部说明\n\n`dict` 在Go里是作为`map[string]interface{}`执行的。Go开发者可以传`map[string]interface{}`值给上下文，\n将其作为 `dict` 提供给模板。\n\n## Encoding functions\n\nHelm有以下编码和解码函数：\n\n* `b64enc`/`b64dec`: 编码或解码 Base64\n* `b32enc`/`b32dec`: 编码或解码 Base32\n\n## Lists and List Functions\n\nHelm 提供了一个简单的`list`类型，包含任意顺序的列表。类似于数组或切片，但列表是被设计用于不可变数据类型。\n\n创建一个整型列表：\n\n```yaml\n$myList := list 1 2 3 4 5\n```\n\n上述会生成一个列表 `[1 2 3 4 5]`。\n\nHelm 提供了以下列表函数： [append(mustAppend)](#append-mustappend), [compact\n(mustCompact)](#compact-mustcompact), [concat](#concat),\n[first(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial\n(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast),\n[prepend (mustPrepend)](#prepend-mustprepend), [rest\n(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse),\n[seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq\n(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), 和\n[without (mustWithout)](#without-mustwithout)。\n\n### first, mustFirst\n\n获取列表中的第一项，使用 `first`。\n\n`first $myList` 返回 `1`\n\n`first` 有问题时会出错，`mustFirst` 有问题时会向模板引擎返回错误。\n\n### rest, mustRest\n\n获取列表的尾部内容(除了第一项外的所有内容)，使用`rest`。\n\n`rest $myList` returns `[2 3 4 5]`\n\n`rest`有问题时会出错，`mustRest` 有问题时会向模板引擎返回错误。\n\n### last, mustLast\n\n使用`last`获取列表的最后一项：\n\n`last $myList` 返回 `5`。这大致类似于反转列表然后调用`first`。\n\n### initial, mustInitial\n\n通过返回所有元素 _但_ 除了最后一个元素来赞赏`last`。 `initial $myList` 返回 `[1 2 3 4]`。\n\n`initial`有问题时会出错，但是 `mustInitial` 有问题时会向模板引擎返回错误。\n\n### append, mustAppend\n\n在已有列表中追加一项，创建一个新的列表。\n\n```yaml\n$new = append $myList 6\n```\n\n上述语句会设置 `$new` 为 `[1 2 3 4 5 6]`。 `$myList`会保持不变。\n\n`append` 有问题时会出错，但 `mustAppend` 有问题时会向模板引擎返回错误。\n\n### prepend, mustPrepend\n\n将元素添加到列表的前面，生成一个新的列表。\n\n```yaml\nprepend $myList 0\n```\n\n上述语句会生成 `[0 1 2 3 4 5]`。 `$myList`会保持不变。\n\n`prepend` 有问题时会出错，但 `mustPrepend` 有问题时会向模板引擎返回错误。\n\n### concat\n\n将任意数量的列表串联成一个。\n\n```yaml\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\n上述语句会生成 `[1 2 3 4 5 6 7 8]`。 `$myList` 会保持不变。\n\n### reverse, mustReverse\n\n反转给定的列表生成一个新列表。\n\n```yaml\nreverse $myList\n```\n\n上述语句会生成一个列表： `[5 4 3 2 1]`。\n\n`reverse` 有问题时会出错，但 `mustReverse` 有问题时会向模板引擎返回错误。\n\n### uniq, mustUniq\n\n生成一个移除重复项的列表。\n\n```yaml\nlist 1 1 1 2 | uniq\n```\n\n上述语句会生成 `[1 2]`\n\n`uniq` 有问题时会出错，但 `mustUniq` 有问题时会向模板引擎返回错误。\n\n### without, mustWithout\n\n`without` 函数从列表中过滤内容。\n\n```yaml\nwithout $myList 3\n```\n\n上述语句会生成 `[1 2 4 5]`\n\n一个过滤器可以过滤多个元素：\n\n```yaml\nwithout $myList 1 3 5\n```\n\n这样会得到： `[2 4]`\n\n`without` 有问题时会出错，但 `mustWithout` 有问题时会向模板引擎返回错误。\n\n### has, mustHas\n\n验证列表是否有特定元素。\n\n```yaml\nhas 4 $myList\n```\n\n上述语句会返回 `true`, 但 `has \"hello\" $myList` 就会返回false。\n\n`has` 有问题时会出错，但 `mustHas` 有问题时会向模板引擎返回错误。\n\n### compact, mustCompact\n\n接收一个列表并删除空值项。\n\n```yaml\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` 会返回一个移除了空值(比如， \"\")的新列表。\n\n`compact` 有问题时会出错，但 `mustCompact` 有问题时会向模板引擎返回错误。\n\n### index\n\n使用`index list [n]`获取列表的第n个元素。使用`index list [n] [m] ...`获取多位列表元素。\n\n* `index $myList 0` 返回 `1`，同 `myList[0]`\n* `index $myList 0 1` 同 `myList[0][1]`\n\n### slice, mustSlice\n\n从列表中获取部分元素，使用 `slice list [n] [m]`。等同于 `list[n:m]`.\n\n* `slice $myList` 返回 `[1 2 3 4 5]`。 等同于 `myList[:]`。\n* `slice $myList 3` 返回 `[4 5]`等同于 `myList[3:]`。\n* `slice $myList 1 3` 返回 `[2 3]`等同于 `myList[1:3]`。\n* `slice $myList 0 3` 返回 `[1 2 3]`等同于 `myList[:3]`。\n\n`slice` 有问题时会出错，但 `mustSlice` 有问题时会向模板引擎返回错误。\n\n### until\n\n`until` 函数构建一个整数范围。\n\n```yaml\nuntil 5\n```\n\n上述语句会生成一个列表： `[0, 1, 2, 3, 4]`。\n\n对循环语句很有用： `range $i, $e := until 5`。\n\n### untilStep\n\n类似`until`， `untilStep` 生成一个可计数的整型列表。但允许你定义开始，结束和步长：\n\n```yaml\nuntilStep 3 6 2\n```\n\n上述语句会生成 `[3 5]`，从3开始，每次加2，直到大于等于6。类似于Python的 `range` 函数。\n\n### seq\n\n原理和bash的 `seq` 命令类似。\n\n* 1 单个参数  (结束位置) - 会生成所有从1到包含 `end` 的整数。\n* 2 多个参数 (开始， 结束) - 会生成所有包含`start` 和 `end` 的整数，递增或者递减。\n* 3 多个参数 (开始， 步长， 结束) - 会生成所有包含 `start` 和 `end` 按 `step`递增或递减的整数。\n\n```yaml\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\n使用 `chunk size list` 将列表拆分为指定大小的块。这对于分页很有用。\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\n上述语句会生成一个列表的列表 `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`。\n\n## Math Functions\n\n除非另外指定，否则所有的math函数都是操作 `int64` 的值。\n\n有以下math函数可用： [add](#add), [add1](#add1),\n[ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max),\n[min](#min), [mod](#mod), [mul](#mul), [round](#round), and [sub](#sub）。\n\n### add\n\n使用`add`求和。接受两个或多个输入。\n\n```yaml\nadd 1 2 3\n```\n\n### add1\n\n自增加1，使用 `add1`。\n\n### sub\n\n相减使用 `sub`。\n\n### div\n\n整除使用 `div`。\n\n### mod\n\n取模使用`mod`。\n\n### mul\n\n相乘使用`mul`。接受两个或多个输入。\n\n```yaml\nmul 1 2 3\n```\n\n### max\n\n返回一组整数中最大的整数。\n\n下列会返回`3`:\n\n```yaml\nmax 1 2 3\n```\n\n### min\n\n返回一组数中最小的数。\n\n`min 1 2 3` 会返回 `1`。\n\n### len\n\n返回参数的长度。\n\n```yaml\nlen .Arg\n```\n\n## Float Math Functions\n\n所有的数学函数使用`float64`格式。\n\n### addf\n\n使用`addf`求和\n\n下面的例子会返回`5.5`:\n\n```yaml\naddf 1.5 2 2\n```\n\n### add1f\n\n使用`add1f`递增1\n\n### subf\n\n相减使用`subf`\n\n下面例子相当于`7.5 - 2 - 3` 并返回 `2.5`:\n\n```yaml\nsubf 7.5 2 3\n```\n\n### divf\n\n使用`divf`实现整数除法\n\n以下相当于`10 / 2 / 4` 并返回 `1.25`:\n\n```yaml\ndivf 10 2 4\n```\n\n### mulf\n\n使用`mulf`做乘法\n\n以下会返回`6`:\n\n```yaml\nmulf 1.5 2 2\n```\n\n### maxf\n\n返回最大浮点数\n\n以下会返回`3`:\n\n```yaml\nmaxf 1 2.5 3\n```\n\n### minf\n\n返回最小浮点数\n\n以下会返回 `1.5`:\n\n```yaml\nminf 1.5 2 3\n```\n\n### floor\n\n返回小于等于输入值的最大浮点整数。\n\n`floor 123.9999` will return `123.0`。\n\n### ceil\n\n返回大于等于输入值的最小浮点整数。\n\n`ceil 123.001` will return `124.0`。\n\n### round\n\n返回一个四舍五入到给定小数位的数。\n\n`round 123.555555 3` will return `123.556`。\n\n## Network Functions\n\nHelm提供了一个网络函数： `getHostByName`.\n\n`getHostByName`接收一个域名返回IP地址。\n\n`getHostByName \"www.google.com\"`会返回对应的`www.google.com`的地址。\n\n## File Path Functions\n\nHelm模板函数没有访问文件系统的权限，提供了遵循文件路径规范的函数。包括[base](#base), [clean](#clean),\n[dir](#dir), [ext](#ext), 和 [isAbs](#isabs) 。\n\n### base\n\n返回最后一个元素路径。\n\n```yaml\nbase \"foo/bar/baz\"\n```\n\n返回 \"baz\"。\n\n### dir\n\n返回目录， 去掉路径的最后一部分。因此 `dir \"foo/bar/baz\"` 返回 `foo/bar`。\n\n### clean\n\n清除路径\n\n```yaml\nclean \"foo/bar/../baz\"\n```\n\n上述语句会清理 `..` 并返回`foo/baz`。\n\n### ext\n\n返回文件扩展。\n\n```yaml\next \"foo.bar\"\n```\n\n上述结果为： `.bar`.\n\n### isAbs\n\n检查文件路径是否为绝对路径，使用 `isAbs`。\n\n## Reflection Functions\n\nHelm 提供了基本的反射工具。这有助于高级模板开发者理解特定值的基本Go类型信息。Helm是由Go编写的且是强类型的。\n类型系统应用于模板中。\n\nGo 有一些原始 _类型_，比如 `string`, `slice`, `int64`, 和 `bool`。\n\nGo 有一个开放的 _类型_ 系统，允许开发者创建自己的类型。\n\nHelm 通过[kind functions](#kind-functions) 和 [type\nfunctions](#type-functions) 提供了一组函数。[deepEqual](#deepequal) 也可以用来比较值。\n\n### Kind Functions\n\n有两个类型函数： `kindOf` 返回对象类型。\n\n```yaml\nkindOf \"hello\"\n```\n\n上述语句返回 `string`。对于简单测试(比如在`if`块中)，`Kindis`函数可以验证值是否为特定类型：\n\n```yaml\nkindIs \"int\" 123\n```\n\n上述返回 `true`。\n\n### Type Functions\n\n类型处理起来稍微有点复杂，所以有三个不同的函数：\n\n* `typeOf` 返回值的基础类型： `typeOf $foo`\n* `typeIs` 类似 `kindIs`， 但针对type： `typeIs \"*io.Buffer\" $myVal`\n* `typeIsLike` 类似 `typeIs`，除非取消指针引用\n\n**注意：** 这些都不能测试是否实现了给定的接口，因为在这之前需要提前编译接口。\n\n### deepEqual\n\n 如果两个值相比是[\"deeply equal\"](https://golang.org/pkg/reflect/#DeepEqual)，`deepEqual`返回true。\n\n也适用于非基本类型 (相较于内置的 `eq`）。\n\n```yaml\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\n上述会返回 `true`。\n\n## Semantic Version Functions\n\n有些版本结构易于分析和比较。Helm提供了适用于[SemVer 2](http://semver.org) 版本的函数。包括[semver](#semver)和\n[semverCompare](#semvercompare)。下面你也能看到使用范围和比较的细节。\n\n### semver\n\n`semver`函数将字符串解析为语义版本：\n\n```yaml\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_如果解析失败，会由一个错误引起模板执行中断。_\n\n `$version`是一个指向`Version`对象的指针，包含了一下属性：\n\n* `$version.Major`: 主版本号 (上面的`1`)\n* `$version.Minor`: 次版本号 (上面的`2`)\n* `$version.Patch`: 补丁版本号 (上面的`3`)\n* `$version.Prerelease`: 预发布版本号 (上面的`alpha.1`)\n* `$version.Metadata`: 构建元数据 (上面的`123`)\n* `$version.Original`: 原始版本字符串\n\n另外，你可以使用`Compare`函数比较一个`Version`和另一个`version`：\n\n```yaml\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\n上面会返回 `-1`。\n\n返回值可以是：\n\n* `-1` 如果给定的版本大于`Compare`方法调用的版本\n* `1` 如果`Compare`调用的版本更大\n* `0` 如果版本相同\n\n(注意在语义版本中，`Metadata` 字段在版本比较时不比较)\n\n### semverCompare\n\n一个更健壮的比较函数是`semverCompare`。 这个版本支持版本范围：\n\n* `semverCompare \"1.2.3\" \"1.2.3\"` 检查精确匹配\n* `semverCompare \"~1.2.0\" \"1.2.3\"` 检查主要版本和次要版本，且补丁版本第二个版本是 _大于等于_ 第一个。\n\nSemVer函数使用[semver规划库](https://github.com/Masterminds/semver)，由Sprig作者创建。\n\n### 基本比较\n\n两个元素的比较。首先，比较字符串是以空格或逗号分隔的。然后以|| (OR)分隔。比如：`\">= 1.2 < 3.0.0 || >= 4.2.3\"`\n是要比较大于等于1.2且小于等于3.0.0 或者大于等于4.2.3的。\n\n基本比较符有：\n\n* `=`: 相等\n* `!=`: 不相等\n* `>`: 大于\n* `<`: 小于\n* `>=`: 大于等于\n* `<=`: 小于等于\n\n### 使用预发布版本\n\n预发布版本，对于那些不熟悉它们的人，是用于稳定版本或一般可用版本之前的软件版本。预发布版本的例子包括开发版、\nalpha版、beta版，和rc版本。稳定版`1.2.3`的预发布版本可能是`1.2.3-beta.1`，按照优先顺序，预发布版本在相关版本之前发布。\n比如：`1.2.3-beta.1 < 1.2.3` 。\n\n根据语义版本指定的预发布版本可能不与对应的发行版本兼容。\n\n> 预发布版本表示版本不稳定且可能不满足其相关正常版本所表示的预期兼容性要求。\n\n使用不带预发布版本比较器约束的语义版本的比较会跳过预发布版本。比如 `>=1.2.3` 会跳过预发布而`>=1.2.3-0`会计算并查找预发布版本。\n\n按照规范，上例中的`0`作为预发布的版本是因为预发布版本只能包含ASCII字母数字和连字符（以及`.`分隔符），并且排序按照ASCII排序顺序。在ASCII排序中，最小的字符是`0`(查看[ASCII表](http://www.asciitable.com/))。\n\n理解ASCII排序顺序很重要因为A-Z是在a-z之前，这意味着`>=1.2.3-BETA` 会返回 `1.2.3-alpha`。这里并不适合大小写敏感，因为是按照ASCII排序规范指定顺序。\n\n### 连字符范围比较\n\n有多个方法处理范围，首先是连字符范围。像这样：\n\n* `1.2 - 1.4.5` 等同于 `>= 1.2 <= 1.4.5`\n* `2.3.4 - 4.5` 等同于 `>= 2.3.4 <= 4.5`\n\n### 比较中通配符\n\n`x`, `X`, 和 `*` 可用于通配符。适用于所有比较运算符。当使用`=`运算符时，会返回补丁级别的比较。比如：\n\n* `1.2.x` 相当于 `>= 1.2.0, < 1.3.0`\n* `>= 1.2.x` 相当于 `>= 1.2.0`\n* `<= 2.x` 相当于 `< 3`\n* `*` 相当于 `>= 0.0.0`\n\n### 波浪符号范围比较 (补丁版本)\n\n波浪 (`~`) 比较运算符是补丁级别范围的比较，在指定次要版本和主要版本变化且没有次要版本时使，比如：\n\n* `~1.2.3` 相当于 `>= 1.2.3, < 1.3.0`\n* `~1` 相当于 `>= 1, < 2`\n* `~2.3` 相当于 `>= 2.3, < 2.4`\n* `~1.2.x` 相当于 `>= 1.2.0, < 1.3.0`\n* `~1.x` 相当于 `>= 1, < 2`\n\n### 插入符号比较 (主要版本)\n\n插入符(`^`)比较运算是主版本级别改变时使用。在1.0.0 发布之前，次要版本充当API稳定级别版本。\n当比较主要的API版本更改时，这很有用，比如：\n\n* `^1.2.3` 相当于 `>= 1.2.3, < 2.0.0`\n* `^1.2.x` 相当于 `>= 1.2.0, < 2.0.0`\n* `^2.3` 相当于 `>= 2.3, < 3`\n* `^2.x` 相当于 `>= 2.0.0, < 3`\n* `^0.2.3` 相当于 `>=0.2.3 <0.3.0`\n* `^0.2` 相当于 `>=0.2.0 <0.3.0`\n* `^0.0.3` 相当于 `>=0.0.3 <0.0.4`\n* `^0.0` 相当于 `>=0.0.0 <0.1.0`\n* `^0` 相当于 `>=0.0.0 <1.0.0`\n\n## URL Functions\n\nHelm 包含 [urlParse](#urlparse), [urlJoin](#urljoin), 和[urlquery](#urlquery) 函数可以用做处理URL。\n\n### urlParse\n\n解析URL的字符串并生成包含URL部分的字典。\n\n```yaml\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\n上述结果为： 包含URL对象的字典：\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\n这是使用Go标准库中的URL包实现的。更多信息，请查看 https://golang.org/pkg/net/url/#URL。\n\n### urlJoin\n\n将一个映射(由`urlParse`生成的)连接成URL字符串\n\n```yaml\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\n上述结果会生成以下字符串：\n\n```yaml\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\n返回作为参数传入的值的转义版本，这样就可以嵌入到URL的查询部分。\n\n```yaml\n$var := urlquery \"string for query\"\n```\n\n## UUID Functions\n\nHelm 可以生成UUID v4 通用唯一ID。\n\n```yaml\nuuidv4\n```\n\n上述结果为： 一个新的v4类型的UUID（随机生成）。\n\n## Kubernetes and Chart Functions\n\nHelm 包含了用于 Kubernetes的函数，包括[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas),\n[Files](#file-functions), 和 [lookup](#lookup)。\n\n### lookup\n\n`lookup` 用于在正在运行的集群中查找资源。当和`helm template`命令一起使用时会返回一个空响应。\n\n可以在 [lookup函数文档](./functions_and_pipelines.md#using-the-lookup-function)查看更多细节。\n\n### .Capabilities.APIVersions.Has\n\n返回API版本或资源是否在集群中可用。\n\n```yaml\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\n更多信息可查看 [内置对象文档](./builtin_objects.md)。\n\n### File Functions\n\n有几个函数能使您能够访问chart中的非特殊文件。比如访问应用配置文件。请查看[模板中访问文件](./accessing_files.md)。\n\n_注意，这里很多函数的文档是来自[Sprig](https://github.com/Masterminds/sprig)。Sprig是一个适用于Go应用的函数模板库。_\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: 模板函数和流水线\ndescription: 使用函数和管道\nsidebar_position: 5\n---\n\n到目前为止，我们已经知道了如何将信息传到模板中。 但这些信息会原样放入模板中。\n有时我们希望以一种更有用的方式来转换所提供的数据。\n\n让我们从一个最佳实践开始：当把 `.Values` 对象中的字符串注入到模板时，我们应该给这些字符串加上引号。可以通过在模板指令中调用 `quote` 函数来实现：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\n模板函数的语法是 `functionName arg1 arg2...`。在上面的代码片段中，`quote .Values.favorite.drink`调用了`quote`函数并传递了一个参数(`.Values.favorite.drink`)。\n\nHelm 有超过60个可用函数。其中有些通过[Go模板语言](https://godoc.org/text/template)本身定义。其他大部分都是[Sprig 模板库](https://masterminds.github.io/sprig/)。我们可以在示例看到其中很多函数。\n\n> 当我们讨论\"Helm模板语言\"时，感觉它是Helm专属的，实际上它是Go模板语言、一些额外的函数和用于向模板暴露某些对象的装饰器组合而成的。很多Go模板的资料也有助于你学习模板。\n\n## 管道符\n\n模板语言的一个强大功能是**管道**概念。借鉴 UNIX 的设计理念，管道是一种将多个模板命令紧凑串联起来的工具，用于表达一系列转换操作。换句话说，管道是按顺序完成一系列任务的高效方式。\n现在用管道符重写上述示例：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\n在这个示例中，并不是调用`quote 参数`，而是倒置了命令。使用管道符(`|`)将参数“发送”给函数：\n`.Values.favorite.drink | quote`。使用管道符可以将很多函数链接在一起：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> 倒置命令是模板中的常见做法。可以经常看到 `.val | quote` 而不是 `quote .val`。实际上两种操作都是可以的。\n\n模板会生成以下内容：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\n注意原有的`pizza`现在已经被转换成了`\"PIZZA\"`。\n\n当使用管道符传递参数时，第一个求值结果（`.Values.favorite.drink`）会作为函数的 _最后一个参数_ 传入。我们可以用一个接收两个参数的函数 `repeat COUNT STRING` 来修改上面的 drink 示例：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n`repeat` 函数会将给定字符串重复指定次数，因此输出如下：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## 使用`default`函数\n\n模板中频繁使用的一个函数是`default`： `default DEFAULT_VALUE GIVEN_VALUE`。\n这个函数允许你在模板中指定一个默认值，以防这个值被忽略。现在使用它修改上述示例：\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\n如果运行，会得到 `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\n现在，从`values.yaml`中移除设置：\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\n现在重新运行 `helm install --dry-run --debug fair-worm ./mychart` 会生成如下内容：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\n在实际的chart中，所有的静态默认值应该设置在 `values.yaml` 文件中，且不应该重复使用 `default` 命令\n(否则会出现冗余)。然而这个`default` 命令很适合计算值，其不能声明在`values.yaml`文件中，比如：\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\n有些场景，`if`条件比`default`更加适合。在下一章节我们就会看到。\n\n模板函数和管道符是转换信息然后将其插入到YAML中的强有力方式。但是有些时候我们需要插入一些内容之前进行一些逻辑判断，而不仅仅是插入一个字符串。\n下一章节，我们会看到模板语言提供的控制结构。\n\n## 使用`lookup`函数\n\n`lookup` 函数可以用于在运行的集群中 _查找_ 资源。lookup函数简述为查找 `apiVersion, kind, namespace,name -> 资源或者资源列表`。\n\n| parameter  | type   |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\n`name` 和 `namespace` 都是选填的，且可以传空字符串(`\"\"`)作为空。但如果你操作的是 namespace 作用域的资源，则 `name` 和 `namespace` 必须同时指定。\n\n以下是可能的参数组合：\n\n| 命令                                   | Lookup 函数                            |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\n当 `lookup` 返回一个对象时，它会返回一个字典。可以进一步导航这个字典来提取特定值。\n\n下面的例子将返回`mynamespace`对象的annotations属性：\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\n当`lookup`返回一个对象列表时，可以通过`items`字段访问对象列表：\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* do something with each service */}}\n{{ end }}\n```\n\n当对象未找到时，会返回空值。可以用来检测对象是否存在。\n\n`lookup` 函数使用 Helm 已有的 Kubernetes 连接配置查询 Kubernetes。当与 API 服务器交互时返回错误\n（比如缺少资源访问权限），Helm 的模板操作会失败。\n\n请记住，在执行 `helm template|install|upgrade|delete|rollback --dry-run` 操作时，Helm 不会连接 Kubernetes API 服务器。如果需要针对运行中的集群测试 `lookup`，应使用 `helm template|install|upgrade|delete|rollback --dry-run=server` 来允许集群连接。\n\n## 运算符也是函数\n\n对于模板来说，运算符(`eq`, `ne`, `lt`, `gt`, `and`, `or`等等) 都是作为函数来实现的。\n在管道符中，操作可以按照圆括号分组。\n\n现在我们可以从函数和管道符返回到条件控制流，循环和范围修饰符。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: 入门\ndescription: Chart 模板的快速指南。\nsidebar_position: 2\n---\n\n本节我们会创建一个 chart 并添加第一个模板。这里创建的 chart 会在后续指南中用到。\n\n接下来，让我们简单看一下 Helm chart。\n\n## Charts\n\n如 [Charts 指南](/topics/charts.md)所述，Helm chart 的结构如下：\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\n`templates/` 目录用于存放模板文件。当 Helm 处理 chart 时，会将 `templates/` 目录中的所有文件传递给模板渲染引擎，然后收集渲染结果并发送到 Kubernetes。\n\n`values.yaml` 文件对模板也很重要。这个文件包含 chart 的**默认值**。用户可以在执行 `helm install` 或 `helm upgrade` 时覆盖这些值。\n\n`Chart.yaml` 文件包含 chart 的描述信息，可以在模板中访问它。\n\n`charts/` 目录**可以**包含其他 chart（称为**子 chart**）。稍后我们会介绍它们在模板渲染时的工作方式。\n\n## 入门 Chart\n\n在本指南中我们会创建一个名为 `mychart` 的 chart，然后在其中创建一些模板。\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### 快速查看 `mychart/templates/`\n\n查看 `mychart/templates/` 目录，你会发现一些已有的文件：\n\n- `NOTES.txt`：chart 的\"帮助文本\"，用户执行 `helm install` 时会显示。\n- `deployment.yaml`：创建 Kubernetes [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 的基础清单\n- `service.yaml`：为 Deployment 创建 [Service](https://kubernetes.io/docs/concepts/services-networking/service/) 端点的基础清单\n- `_helpers.tpl`：存放可在整个 chart 中复用的模板辅助函数\n\n接下来我们要做的是……**把它们全部删掉！** 这样我们就可以从头开始学习。我们会在后续教程中创建自己的 `NOTES.txt` 和 `_helpers.tpl`。\n\n```console\n$ rm -rf mychart/templates/*\n```\n\n编写生产级别的 chart 时，保留这些基础文件会很有用。因此在日常开发中，你可能不会删除它们。\n\n## 第一个模板\n\n我们要创建的第一个模板是 ConfigMap。在 Kubernetes 中，ConfigMap 是一个用于存储配置数据的对象。其他组件（如 Pod）可以访问 ConfigMap 中的数据。\n\n因为 ConfigMap 是基础资源，很适合作为我们的起点。\n\n首先创建文件 `mychart/templates/configmap.yaml`：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**提示：** 模板名称没有严格的命名规范。不过建议 YAML 文件使用 `.yaml` 扩展名，辅助模板使用 `.tpl` 扩展名。\n\n上面的 YAML 文件是一个简单的 ConfigMap，包含了最基本的必需字段。由于该文件位于 `mychart/templates/` 目录中，它会经过模板引擎处理。\n\n将这样的普通 YAML 文件放在 `mychart/templates/` 目录中是完全可以的。当 Helm 读取这个模板时，会原样发送给 Kubernetes。\n\n有了这个简单的模板，现在我们有了一个可安装的 chart。安装方式如下：\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\n使用 Helm，我们可以检索 release 并查看实际加载的模板。\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n`helm get manifest` 命令接受一个 release 名称（`full-coral`），然后输出所有上传到服务器的 Kubernetes 资源。每个文件以 `---` 开头（表示 YAML 文档的开始），后面跟着自动生成的注释行，说明该 YAML 文档由哪个模板文件生成。\n\n从输出可以看到，YAML 数据正是我们在 `configmap.yaml` 文件中定义的内容。\n\n现在卸载 release：`helm uninstall full-coral`。\n\n### 添加简单的模板调用\n\n将 `name:` 硬编码到资源中不是好的做法。名称应该是唯一的，因此我们可能希望通过插入 release 名称来生成名称字段。\n\n**提示：** 由于 DNS 系统的限制，`name:` 字段长度限制为 63 个字符。因此 release 名称限制为 53 个字符。Kubernetes 1.3 及更早版本限制为 24 个字符（即名称为 14 个字符）。\n\n修改 `configmap.yaml`：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n主要变化是 `name:` 字段的值，现在是 `{{ .Release.Name }}-configmap`。\n\n> 模板指令用 `{{` 和 `}}` 括起来。\n\n模板指令 `{{ .Release.Name }}` 会将 release 名称注入模板。传递给模板的值可以理解为**命名空间对象**，用点（`.`）分隔各个命名空间元素。\n\n`Release` 前面的点表示从当前作用域的顶层命名空间开始（稍后会讨论作用域）。因此 `.Release.Name` 可以理解为\"从顶层命名空间开始，找到 `Release` 对象，然后在其中查找名为 `Name` 的对象\"。\n\n`Release` 是 Helm 的内置对象之一，稍后会深入讨论。现在只需要知道它可以显示分配给 release 的名称。\n\n现在安装资源，可以立即看到模板指令的效果：\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\n可以运行 `helm get manifest clunky-serval` 查看生成的完整 YAML。\n\n注意 Kubernetes 中的 ConfigMap 名称现在是 `clunky-serval-configmap`，而不是之前的 `mychart-configmap`。\n\n至此我们已经了解了最基本的模板：嵌入了 `{{` 和 `}}` 模板指令的 YAML 文件。下一部分我们会深入了解模板。但在继续之前，有一个小技巧可以加快模板开发速度：如果你想测试模板渲染结果但不实际安装，可以使用 `helm install --debug --dry-run goodly-guppy ./mychart`。这会渲染模板但不安装 chart，而是将渲染后的模板输出到控制台：\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\n使用 `--dry-run` 可以更方便地测试代码，但无法保证 Kubernetes 会接受你生成的模板。不要仅因为 `--dry-run` 正常运行就认为 chart 可以成功安装。\n\n在 [Chart 模板指南](/docs/chart_template_guide/index.mdx)中，我们会以这里定义的基础 chart 为例，详细介绍 Helm 模板语言。接下来从内置对象开始。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: .helmignore 文件\ndescription: \"`.helmignore` 文件用于指定不想包含在 Helm chart 中的文件。\"\nsidebar_position: 12\n---\n\n`.helmignore` 文件用于指定不想包含在 Helm chart 中的文件。\n\n如果该文件存在，`helm package` 命令会在打包应用时忽略所有匹配 `.helmignore` 文件中指定模式的文件。\n\n这有助于避免将不必要或敏感的文件及目录添加到 Helm chart 中。\n\n`.helmignore` 文件支持 Unix shell 通配符匹配、相对路径匹配以及取反匹配（以 ! 作为前缀）。每行只能指定一种模式。\n\n以下是一个 `.helmignore` 文件示例：\n\n```\n# comment\n\n# Match any file or path named .helmignore\n.helmignore\n\n# Match any file or path named .git\n.git\n\n# Match any text file\n*.txt\n\n# Match only directories named mydir\nmydir/\n\n# Match only text files in the top-level directory\n/*.txt\n\n# Match only the file foo.txt in the top-level directory\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt\na[b-d].txt\n\n# Match any file under subdir matching temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\n与 `.gitignore` 的一些显著差异：\n\n- 不支持 `**` 语法。\n- globbing 库使用的是 Go 的 `filepath.Match`，而非 fnmatch(3)\n- 末尾空格总会被忽略（不支持转义序列）\n- 不支持 `\\!` 作为特殊的前导序列。\n- 默认不会排除自身，需要显式添加 `.helmignore` 条目\n\n\n**我们需要你的帮助**，让这篇文档更加完善。如需添加、修正或删除信息，请[提交 issue](https://github.com/helm/helm-www/issues) 或发起 pull request。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx",
    "content": "---\ntitle: Chart 模板指南\nsidebar_position: 5\n---\n\n# Chart模板开发者指南\n\n该指南提供 Helm Chart 模板的介绍，重点强调模板语言。\n\n模板会生成 manifest 文件，使用 Kubernetes 可以识别的 YAML 格式描述。我们会看到模板是如何结构化的，\n它们如何被使用，如何编写 Go 模板，以及如何调试你们的工作内容。\n\n该指南聚焦于以下概念：\n\n- Helm 模板语言\n- values 值的使用\n- 使用模板工作的技术点\n\n该指南面向学习 Helm 模板语言的来龙去脉。其他指南提供介绍性资料，示例和最佳实践。\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: 命名模板\ndescription: 如何定义命名模板\nsidebar_position: 9\n---\n\n此时需要越过模板，开始创建其他内容了。该部分我们会看到如何在一个文件中定义\n_命名模板_，并在其他地方使用。_命名模板_ (有时称作一个 _部分_ 或一个\n_子模板_)仅仅是在文件内部定义的模板，并使用了一个名字。有两种创建方式和几种不同的使用方法。\n\n在[流控制](./control_structures.md)部分，\n我们介绍了三种声明和管理模板的方法：`define`，`template`，和`block`。在这部分，我们将使用这三种操作并介绍一种特殊用途的\n`include`方法，类似于`template`操作。\n\n命名模板时要记住一个重要细节：**模板名称是全局的**。如果你声明了两个相同名称的模板，哪个最后加载就使用哪个。\n因为在子chart中的模板和顶层模板一起编译，命名时要注意 _chart特定名称_。\n\n一个常见的命名惯例是用chart名称作为模板前缀：`{{ define \"mychart.labels\" }}`。使用特定chart名称作为前缀可以避免可能因为\n两个不同chart使用了相同名称的模板而引起的冲突。\n\n这个规则同样适用于chart的不同版本。如果有 `mychart` 的 `1.0.0`版本以一种方式定义了模板， `mychart` 的 `2.0.0`\n版本修改了已有的命名模板，那就会使用最后加载的版本。也可以在chart名称中添加版本来解决这个问题：\n`{{ define \"mychart.v1.labels\" }}` 和 `{{ define \"mychart.v2.labels\" }}`。\n\n## 局部的和`_`文件\n\n目前为止，我们已经使用了单个文件，且单个文件中包含了单个模板。但Helm的模板语言允许你创建命名的嵌入式模板，\n这样就可以在其他位置按名称访问。\n\n在编写模板细节之前，文件的命名惯例需要注意：\n\n* `templates/`中的大多数文件被视为包含Kubernetes清单\n* `NOTES.txt`是个例外\n* 命名以下划线(`_`)开始的文件则假定 _没有_ 包含清单内容。这些文件不会渲染为Kubernetes对象定义，但在其他chart模板中都可用。\n\n这些文件用来存储局部和辅助对象，实际上当我们第一次创建`mychart`时，会看到一个名为`_helpers.tpl`的文件，这个文件是模板局部的默认位置。\n\n## 用`define`和`template`声明和使用模板\n\n`define`操作允许我们在模板文件中创建一个命名模板，语法如下：\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # body of template here\n{{- end }}\n```\n\n比如我们可以定义一个模板封装Kubernetes的标签：\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\n现在我们将模板嵌入到了已有的配置映射中，然后使用`template`包含进来：\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\n当模板引擎读取该文件时，它会存储`mychart.labels`的引用直到`template \"mychart.labels\"`被调用。\n然后会按行渲染模板，因此结果类似这样：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\n注意：`define`不会有输出，除非像本示例一样用模板调用它。\n\n按照惯例，Helm chart将这些模板放置在局部文件中，一般是`_helpers.tpl`。把这个方法移到那里：\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\n按照惯例`define`方法会有个简单的文档块(`{{/* ... */}}`)来描述要做的事。\n\n尽管这个定义是在`_helpers.tpl`中，但它仍能访问`configmap.yaml`：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\n如上所述，**模板名称是全局的**。因此，如果两个模板使用相同名字声明，会使用最后出现的那个。由于子chart中的模板和顶层模板一起编译，\n最好用 _chart特定名称_ 命名你的模板。常用的命名规则是用chart的名字作为模板的前缀： `{{ define \"mychart.labels\" }}`。\n\n## 设置模板范围\n\n在上面定义的模板中，我们没有使用任何对象，仅仅使用了方法。修改定义好的模板让其包含chart名称和版本号：\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\n如果渲染这个，会得到以下错误：\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\n要查看渲染了什么，可以用`--disable-openapi-validation`参数重新执行：\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`。\n结果并不是我们想要的：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\n名字和版本号怎么了？没有出现在我们定义的模板中。当一个（使用`define`创建的）命名模板被渲染时，会接收被`template`调用传入的内容。\n在我们的示例中，包含模板如下：\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\n没有内容传入，所以模板中无法用`.`访问任何内容。但这个很容易解决，只需要传递一个范围给模板：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\n注意这个在`template`调用末尾传入的`.`，我们可以简单传入`.Values`或`.Values.favorite`或其他需要的范围。但我们需要的是顶层范围。在命名模板的上下文中，`$` 会引用你传入的范围，而不是某个全局范围。\n\n现在我们可以用`helm install --dry-run --debug plinking-anaco ./mychart`执行模板，然后得到：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\n现在`{{ .Chart.Name }}`解析为`mychart`，`{{ .Chart.Version }}`解析为`0.1.0`。\n\n## `include`方法\n\n假设定义了一个简单模板如下：\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\n现在假设我想把这个插入到模板的`labels:`部分和`data:`部分：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\n如果渲染这个，会得到以下错误：\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\n要查看渲染了什么，可以用`--disable-openapi-validation`参数重新执行：\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`。\n输出不是我们想要的：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\n注意两处的`app_version`缩进都不对，为啥？因为被替换的模板中文本是左对齐的。由于`template`是一个行为，不是方法，无法将\n`template`调用的输出传给其他方法，数据只是简单地按行插入。\n\n为了处理这个问题，Helm提供了一个`template`的可选项，可以将模板内容导入当前管道，然后传递给管道中的其他方法。\n\n下面这个示例，使用`indent`正确地缩进了`mychart.app`模板：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\n现在生成的YAML每一部分都可以正确缩进了：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> 相较于使用`template`，在 Helm 中使用`include`被认为是更好的方式，\n> 只是为了更好地处理YAML文档的输出格式\n\n有时我们需要导入内容，但不是作为模板，也就是按字面意义导入文件内容，可以通过使用`.Files`对象访问文件来实现，\n这将在下一部分展开描述。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: 创建 NOTES.txt 文件\ndescription: 如何向 chart 用户提供说明。\nsidebar_position: 10\n---\n\n本节介绍 Helm 为 chart 用户提供操作说明的工具。`helm install` 或 `helm upgrade` 完成后，Helm 可以打印一段对用户有帮助的信息，这些信息可以通过模板灵活自定义。\n\n要为 chart 添加安装说明，只需创建 `templates/NOTES.txt` 文件。这个文件是纯文本，但会像模板一样被处理，所有常规的模板函数和对象都可以使用。\n\n下面创建一个简单的 `NOTES.txt` 文件：\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\n现在运行 `helm install rude-cardinal ./mychart`，会在底部看到如下信息：\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\n通过 `NOTES.txt` 可以方便地向用户展示新安装 chart 的使用说明。虽然不是必须的，但强烈建议创建 `NOTES.txt` 文件。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: 子 chart 和全局值\ndescription: 与子 chart 以及全局值进行交互。\nsidebar_position: 11\n---\n\n到目前为止，我们只使用了一个 chart。但 chart 可以拥有依赖项，称为 _子 chart_，它们拥有自己的值和模板。本节我们会创建一个子 chart，并了解从模板中访问值的不同方式。\n\n在深入代码之前，需要了解一些关于子 chart 的重要细节：\n\n1. 子 chart 被认为是\"独立的\"，这意味着子 chart 永远不会显式依赖其父 chart。\n2. 因此，子 chart 无法访问父 chart 的值。\n3. 父 chart 可以覆盖子 chart 的值。\n4. Helm 有一个 _全局值_ 的概念，所有的 chart 都可以访问。\n\n> 这些限制不一定都适用于[库类型 chart（library charts）](/topics/library_charts.md)，它们专门用于提供标准化的辅助功能。\n\n浏览本节的示例之后，这些概念会变得更加清晰。\n\n## 创建子 chart\n\n在本练习中，我们从本指南开头创建的 `mychart/` 开始，在其中添加一个新 chart。\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\n注意，和之前一样，我们删除了所有基础模板，从头开始。本指南专注于模板的工作原理，而不是依赖管理。[Chart 指南](/topics/charts.md)提供了更多关于子 chart 运行机制的信息。\n\n## 在子 chart 中添加值和模板\n\n接下来，为 `mysubchart` 创建一个简单的模板和 values 文件。`mychart/charts/mysubchart` 中应该已经有一个 `values.yaml`，将其内容设置如下：\n\n```yaml\ndessert: cake\n```\n\n然后，在 `mychart/charts/mysubchart/templates/configmap.yaml` 中创建一个新的 ConfigMap 模板：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\n因为每个子 chart 都是 _独立的 chart_，可以单独测试 `mysubchart`：\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## 用父 chart 的值来覆盖\n\n原来的 chart `mychart` 现在成为了 `mysubchart` 的 _父 chart_。这种关系完全基于 `mysubchart` 位于 `mychart/charts` 目录中这一事实。\n\n因为 `mychart` 是父 chart，我们可以在 `mychart` 中指定配置，并将其推送到 `mysubchart`。例如，可以像这样修改 `mychart/values.yaml`：\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\n注意最后两行。`mysubchart` 部分内的所有指令都会发送到 `mysubchart` chart。因此，如果运行 `helm install --generate-name --dry-run --debug mychart`，会看到 `mysubchart` 的 ConfigMap：\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\n现在，顶层的值已经覆盖了子 chart 的值。\n\n这里有一个重要细节需要注意：我们并没有将 `mychart/charts/mysubchart/templates/configmap.yaml` 模板改为指向 `.Values.mysubchart.dessert`。从该模板的角度来看，值仍然位于 `.Values.dessert`。模板引擎传递值时会设置作用域，因此对于 `mysubchart` 的模板，`.Values` 中只会包含专门针对 `mysubchart` 的值。\n\n但有时你确实希望某些值能对所有模板可用。这可以通过全局 chart 值来实现。\n\n## 全局 Chart 值\n\n全局值是可以在任何 chart 或子 chart 中以完全相同的名字访问的值。全局值需要显式声明，不能把已有的非全局值当作全局值使用。\n\nValues 数据类型有一个保留部分叫 `Values.global`，可用于设置全局值。我们在 `mychart/values.yaml` 文件中设置一个全局值：\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\n由于全局值的工作方式，`mychart/templates/configmap.yaml` 和 `mysubchart/templates/configmap.yaml` 都可以通过 `{{ .Values.global.salad }}` 来访问该值。\n\n`mychart/templates/configmap.yaml`：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\n现在如果执行 dry run 安装，两个输出中会看到相同的值：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\n全局值在这种需要传递信息的场景下很有用，不过确实需要一些规划来确保配置了正确的模板使用全局值。\n\n## 与子 chart 共享模板\n\n父 chart 和子 chart 可以共享模板。在任意 chart 中定义的块在其他 chart 中也是可用的。\n\n例如，我们可以这样定义一个简单的模板：\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\n回想一下，模板中的标签是 _全局共享的_。因此，`labels` 模板可以从任何其他 chart 中引入。\n\n当 chart 开发者需要在 `include` 和 `template` 之间做选择时，使用 `include` 的一个优势是它可以动态引用模板：\n\n```yaml\n{{ include $mytemplate }}\n```\n\n上述代码会解引用 `$mytemplate`。而 `template` 函数只接受字符串字面量。\n\n## 避免使用块\n\nGo 模板语言提供了一个 `block` 关键字，允许开发者提供一个默认实现，之后可以被覆盖。在 Helm chart 中，块并不是最佳的覆盖工具，因为如果提供了同一个块的多个实现，无法预测哪个会被选中。\n\n建议改为使用 `include`。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Values 文件\ndescription: \"如何使用 --values 参数的说明\"\nsidebar_position: 4\n---\n\n在上一节中，我们了解了 Helm 模板提供的内置对象。其中一个是 `Values` 对象。该对象提供了访问传入 chart 的值的方式。其内容来自多个位置：\n\n- chart 中的 `values.yaml` 文件\n- 如果是子 chart，则是父 chart 中的 `values.yaml` 文件\n- 使用 `-f` 参数（`helm install -f myvals.yaml ./mychart`）传递给 `helm install` 或 `helm upgrade` 的 values 文件\n- 使用 `--set` 传递的单个参数（比如 `helm install --set foo=bar ./mychart`）\n\n以上列表按优先级排列：`values.yaml` 是默认值，可以被父 chart 的 `values.yaml` 覆盖，继而被用户提供的 values 文件覆盖，最后被 `--set` 参数覆盖。\n\nValues 文件是普通的 YAML 文件。接下来编辑 `mychart/values.yaml`，然后编辑我们的 ConfigMap 模板。\n\n删除 `values.yaml` 中的默认内容，仅设置一个参数：\n\n```yaml\nfavoriteDrink: coffee\n```\n\n现在可以在模板中使用它：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\n注意最后一行，我们将 `favoriteDrink` 作为 `Values` 的属性进行访问：`{{ .Values.favoriteDrink }}`。\n\n看看渲染结果：\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\n由于默认的 `values.yaml` 文件中将 `favoriteDrink` 的值设置为 `coffee`，这个值就显示在了模板中。我们可以在调用 `helm install` 时添加 `--set` 参数来轻松覆盖这个值：\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\n由于 `--set` 比默认的 `values.yaml` 文件优先级更高，模板就生成了 `drink: slurm`。\n\nValues 文件也可以包含更多结构化的内容。比如，我们可以在 `values.yaml` 文件中创建一个 `favorite` 部分，然后添加多个键：\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\n现在需要稍微修改一下模板：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\n虽然可以这样构造数据，但建议保持 values 树的浅层结构，尽量扁平化。当我们后续介绍如何给子 chart 赋值时，你会看到如何使用树结构为值命名。\n\n## 删除默认的键\n\n如果需要从默认值中删除某个键，可以将该键的值设置为 `null`，这样 Helm 会在合并覆盖值时移除这个键。\n\n比如，稳定版的 Drupal chart 允许在配置自定义镜像时配置活动探针。以下是默认值：\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\n如果你尝试使用 `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]` 将 livenessProbe 处理器从 `httpGet` 覆盖为 `exec`，Helm 会将默认键和覆盖键合并在一起，生成以下 YAML：\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\n但 Kubernetes 不允许声明多个 livenessProbe 处理器，这会导致部署失败。为了解决这个问题，可以通过将 `livenessProbe.httpGet` 设置为 null 来让 Helm 删除它：\n\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\n至此，我们已经了解了几个内置对象，并使用它们将信息注入到模板中。接下来我们将了解模板引擎的另一方面：函数和管道。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: 变量\ndescription: 在模板中使用变量。\nsidebar_position: 8\n---\n\n掌握了函数、管道符、对象和控制结构之后，我们来看看许多编程语言中更基本的概念之一：变量。在模板中，变量的使用频率较低，但我们会看到如何用它来简化代码，以及更好地配合 `with` 和 `range` 使用。\n\n在之前的例子中，我们看到下面的代码会失败：\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` 不在 `with` 块限制的作用域内。解决作用域问题的一种方法是：将对象赋值给一个变量，这样就可以在任何作用域中访问它。\n\n在 Helm 模板中，变量是对另一个对象的命名引用，格式为 `$name`。变量使用特殊的赋值运算符 `:=` 进行赋值。我们可以用一个变量来保存 `Release.Name`，重写上面的例子：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\n注意，在 `with` 块开始之前，我们先赋值 `$relname := .Release.Name`。这样在 `with` 块内部，`$relname` 变量仍然指向 release 名称。\n\n运行后会生成：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\n变量在 `range` 循环中特别有用。可以用于类似列表的对象，同时捕获索引和值：\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\n注意语法顺序：先是 `range`，然后是变量，然后是赋值运算符，最后是列表。这会将整数索引（从 0 开始）赋值给 `$index`，将值赋值给 `$topping`。运行后会生成：\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\n对于同时具有键和值的数据结构，可以使用 `range` 获取两者。例如，可以这样遍历 `.Values.favorite`：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\n第一次迭代时，`$key` 是 `drink`，`$val` 是 `coffee`；第二次迭代时，`$key` 是 `food`，`$val` 是 `pizza`。运行后会生成：\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\n变量通常不是\"全局的\"，它们的作用域限定在声明所在的块内。前面我们在模板顶层赋值了 `$relname`，因此该变量在整个模板中都有效。但在最后一个例子中，`$key` 和 `$val` 只在 `{{ range... }}{{ end }}` 块内有效。\n\n不过，有一个变量始终指向根上下文：`$`。当你在 `range` 循环中需要获取 chart 的 release 名称时，这会非常有用。\n\n示例如下：\n\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Many helm templates would use `.` below, but that will not work,\n    # however `$` will work here\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # I cannot reference .Chart.Name, but I can do $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Value from appVersion in Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\n到目前为止，我们只看了在单个文件中声明的单个模板。但 Helm 模板语言的一个强大特性是能够声明多个模板并组合使用。我们将在下一节讨论这个内容。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: 下一步\ndescription: 收尾——帮助你继续学习的相关文档资源。\nsidebar_position: 14\n---\n\n本指南帮助 chart 开发者深入理解 Helm 的模板语言，聚焦于模板开发的技术层面。\n\n不过，涉及 chart 日常开发实践的内容，本指南并未完全覆盖。以下是一些有用的文档资源，可以帮助你创建新的 chart：\n\n- CNCF 的 [Artifact Hub](https://artifacthub.io/packages/search?kind=0) 是查找 chart 的首选资源。\n- Kubernetes [文档](https://kubernetes.io/docs/home/)提供了各种资源类型的详细示例，\n  从 ConfigMaps 和 Secrets 到 DaemonSets 和 Deployments。\n- Helm [Charts 指南](/topics/charts.md)介绍了使用 chart 的工作流。\n- Helm [Chart 钩子指南](/topics/charts_hooks.md)说明了如何创建生命周期钩子。\n- Helm [Chart 提示与技巧](/howto/charts_tips_and_tricks.md)提供了编写 chart 时的实用技巧。\n- [Sprig 文档](https://github.com/Masterminds/sprig)介绍了超过 60 个模板函数。\n- [Go 模板文档](https://godoc.org/text/template)详细说明了模板语法。\n- [Schelm 工具](https://github.com/databus23/schelm)是调试 chart 的实用工具。\n\n有时直接请教有经验的开发者会更高效。最好的途径是加入 [Kubernetes Slack](https://kubernetes.slack.com) 的 Helm 相关频道：\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\n最后，如果你发现本文档有错误或遗漏，想要推荐新内容，或者想做出贡献，欢迎访问 [Helm 项目](https://github.com/helm/helm-www)。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"附录：YAML 技术\"\ndescription: 深入了解 YAML 规范及其在 Helm 中的应用。\nsidebar_position: 15\n---\n\n本指南大部分内容聚焦于模板语言的编写。这里我们来看看 YAML 格式。YAML 有一些实用的特性，作为模板作者，可以利用这些特性让模板更不易出错、更易阅读。\n\n## 标量和集合\n\n根据 [YAML 规范](https://yaml.org/spec/1.2/spec.html)，有两种集合类型和多种标量类型。\n\n两种集合类型分别是映射（map）和序列（sequence）：\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\n标量值是单个值（与集合相对）。\n\n### YAML 中的标量类型\n\n在 Helm 使用的 YAML 方言中，值的标量数据类型由一组复杂规则决定，包括 Kubernetes 资源定义的 schema。但在类型推断时，以下规则通常成立。\n\n如果整数或浮点数是不带引号的裸字，通常会被视为数字类型：\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\n但如果用引号括起来，则会被视为字符串：\n\n```yaml\ncount: \"1\" # <-- string, not int\nsize: '2.34' # <-- string, not float\n```\n\n布尔值也是如此：\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # string\n```\n\n空值的关键字是 `null`（不是 `nil`）。\n\n注意 `port: \"80\"` 是合法的 YAML，可以通过模板引擎和 YAML 解析器，但如果 Kubernetes 期望 `port` 是整数，则会失败。\n\n在某些场景中，可以使用 YAML 节点标签强制指定类型：\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\n上例中，`!!str` 告诉解析器 `age` 是字符串，即使它看起来像整数。而 `port` 虽然用引号括起来，也会被视为整数。\n\n## YAML 中的字符串\n\nYAML 文档中的大部分数据都是字符串。YAML 有多种表示字符串的方式。本节介绍这些方式并演示其中一些的用法。\n\n有三种\"内联\"方式声明字符串：\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\n所有内联样式必须在一行内。\n\n- 裸字不带引号，也不进行转义。因此，使用时需要注意字符的选择。\n- 双引号字符串可以使用 `\\` 转义特定字符。例如 `\"\\\"Hello\\\", she said\"`。可以用 `\\n` 转义换行。\n- 单引号字符串是\"字面\"字符串，不使用 `\\` 转义字符。唯一的转义序列是 `''`，表示单个 `'`。\n\n除了单行字符串，还可以声明多行字符串：\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\n上例会将 `coffee` 的值视为单个字符串，等同于 `Latte\\nCappuccino\\nEspresso\\n`。\n\n注意 `|` 后的第一行必须正确缩进。如果这样写就会破坏上面的示例：\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\n由于 `Latte` 缩进不正确，会遇到这样的错误：\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\n在模板中，为了避免上述错误，在多行文档中添加一个虚拟的\"第一行\"内容会更安全：\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\n注意无论第一行是什么，都会保留在字符串输出中。因此，如果你用这种技术将文件内容注入到 ConfigMap 中，注释应该是读取该条目的程序所期望的类型。\n\n### 控制多行字符串中的空格\n\n在上面的示例中，我们用 `|` 表示多行字符串。但注意字符串内容后面有一个尾随的 `\\n`。如果希望 YAML 处理器去掉尾随换行符，可以在 `|` 后添加 `-`：\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\n现在 `coffee` 的值是：`Latte\\nCappuccino\\nEspresso`（没有尾随的 `\\n`）。\n\n有时我们希望保留所有尾随空白。可以使用 `|+` 符号：\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\n现在 `coffee` 的值是 `Latte\\nCappuccino\\nEspresso\\n\\n\\n`。\n\n文本块内的缩进会被保留，换行符也会保留：\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\n上例中，`coffee` 的值是 `Latte\\n  12 oz\\n  16 oz\\nCappuccino\\nEspresso`。\n\n### 缩进和模板\n\n编写模板时，你可能想将文件内容注入到模板中。如前面章节所述，有两种方法：\n\n- 使用 `{{ .Files.Get \"FILENAME\" }}` 获取 chart 中的文件内容。\n- 使用 `{{ include \"TEMPLATE\" . }}` 渲染模板并将其内容放入 chart。\n\n将文件插入 YAML 时，理解上面的多行规则很重要。通常，插入静态文件最简单的方式是这样：\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\n注意上面的缩进方式：`indent 2` 告诉模板引擎将 \"myfile.txt\" 的每一行缩进两个空格。注意模板行本身没有缩进。因为如果缩进了，文件内容的第一行会被缩进两次。\n\n### 折叠多行字符串\n\n有时你想在 YAML 中用多行表示一个字符串，但希望解析时将其视为一个长行。这称为\"折叠\"。要声明折叠块，使用 `>` 代替 `|`：\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\n上例中 `coffee` 的值是：`Latte Cappuccino Espresso\\n`。注意除了最后一个换行符外，所有换行符都会转换为空格。可以将空白控制符与折叠文本标记组合使用，`>-` 会替换或去除所有换行符。\n\n注意在折叠语法中，缩进的文本会保留行。\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\n上例的结果是 `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`。注意空格和换行符都保留了。\n\n## 在一个文件中嵌入多个文档\n\n可以将多个 YAML 文档放在单个文件中。方法是在新文档前加 `---`，在文档结尾加 `...`：\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\n很多情况下，`---` 或 `...` 可以省略。\n\nHelm 中有些文件不能包含多个文档。例如，如果 `values.yaml` 文件中提供了多个文档，只会使用第一个。\n\n但模板文件可以有多个文档。这种情况下，文件（及其所有文档）在模板渲染时被视为一个对象。但生成的 YAML 在传给 Kubernetes 之前会被拆分成多个文档。\n\n我们建议只在确实需要时才在单个文件中使用多个文档。单个文件中有多个文档会难以调试。\n\n## YAML 是 JSON 的超集\n\n由于 YAML 是 JSON 的超集，任何合法的 JSON 文档 _都应该_ 是合法的 YAML。\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\n上面是以下内容的另一种表示方式：\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\n两者也可以混合使用（但要小心）：\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\n这三种写法都会解析为相同的内部表示。\n\n虽然这意味着 `values.yaml` 等文件可以包含 JSON 数据，但 Helm 不会将 `.json` 后缀的文件视为有效文件。\n\n## YAML 锚点\n\nYAML 规范提供了一种存储值引用、然后通过引用使用该值的方式。YAML 将此称为\"锚定\"：\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\n上例中，`&favoriteCoffee` 设置了对 `Cappuccino` 的引用。之后通过 `*favoriteCoffee` 使用该引用。这样 `coffees` 就变成了 `Latte, Cappuccino, Espresso`。\n\n锚点在某些场景中很有用，但有一个方面可能会导致微妙的 bug：第一次解析 YAML 时，引用会被展开然后丢弃。\n\n因此，如果我们解码再重新编码上面的示例，生成的 YAML 会是这样：\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\n由于 Helm 和 Kubernetes 经常读取、修改然后重写 YAML 文件，锚点会丢失。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/example/golang.md",
    "content": "# 基于GO语言的集成开发示例\n\n## 环境\n\n- go version 1.20.x\n- helm v3\n- kubernetes 1.24.x\n\n\n\n## 示例\n\n### 增加仓库\n\n- ``` go\n  package kubestore\n  \n  import (\n      \"fmt\"\n      \"helm.sh/helm/v3/pkg/cli\"\n      \"helm.sh/helm/v3/pkg/getter\"\n      \"helm.sh/helm/v3/pkg/repo\"\n      \"kube-store-operator/commons/logger\"\n  )\n  \n  // 添加一个仓库地址\n  // Helm 的添加仓库地就是将【仓库名+仓库地址】写到一个本地的repositories.yaml文件中\n  func add(entry *repo.Entry) error {\n      settings := cli.New()\n  \n      repoFile := settings.RepositoryConfig\n  \n      // 加载仓库配置文件\n      repositories, err := repo.LoadFile(repoFile)\n      // 如果文件不存在\n      if err != nil {\n          // 创建一个新的仓库配置对象\n          repositories = repo.NewFile()\n      }\n  \n      // 检查要添加的仓库是否已存在\n      if repositories.Has(entry.Name) {\n          return fmt.Errorf(\"仓库 %s 已存在\", entry.Name)\n      }\n  \n      // 添加仓库信息到仓库配置\n      repositories.Add(entry)\n  \n      // 保存更新后的仓库配置到文件\n      if err = repositories.WriteFile(repoFile, 0644); err != nil {\n          return fmt.Errorf(\"无法保存仓库配置文件：%s\", err)\n      }\n  \n      logger.Debugf(\"成功添加仓库地址：%s。\", entry.Name)\n      return nil\n  }\n  ```\n\n- > 此功能相当于: helm repo add 仓库名 https://xxx.com\n\n### 检索仓库\n\n- ``` go\n  package kubestore\n  \n  import (\n      \"fmt\"\n      \"helm.sh/helm/v3/pkg/cli\"\n      \"helm.sh/helm/v3/pkg/getter\"\n      \"helm.sh/helm/v3/pkg/repo\"\n      \"kube-store-operator/commons/logger\"\n  )\n  \n  // 查看仓库信息\n  func list() ([]*repo.Entry, error) {\n      settings := cli.New()\n  \n      // 加载仓库配置文件\n      repositories, err := repo.LoadFile(settings.RepositoryConfig)\n      if err != nil {\n          return nil, fmt.Errorf(\"无法保存仓库配置文件：%s\", err)\n      }\n      return repositories.Repositories, nil\n  }\n  ```\n\n- > 此功能相当于: helm repo list\n\n### 删除仓库\n\n- ``` go\n  package kubestore\n  \n  import (\n      \"fmt\"\n      \"helm.sh/helm/v3/pkg/cli\"\n      \"helm.sh/helm/v3/pkg/getter\"\n      \"helm.sh/helm/v3/pkg/repo\"\n      \"kube-store-operator/commons/logger\"\n  )\n  \n  // 删除一个仓库地址\n  // repoName 仓库名\n  func remove(repoName string) error {\n      settings := cli.New()\n  \n      repoFile := settings.RepositoryConfig\n  \n      // 加载仓库配置文件\n      repositories, err := repo.LoadFile(repoFile)\n      if err != nil {\n          return fmt.Errorf(\"无法加载仓库配置文件：%s\", err)\n      }\n  \n      // 检查要删除的仓库是否存在\n      if !repositories.Has(repoName) {\n          return fmt.Errorf(\"仓库 %s 不存在\", repoName)\n      }\n  \n      // 从仓库配置中删除仓库\n      result := repositories.Remove(repoName)\n  \n      // 保存更新后的仓库配置到文件\n      if err = repositories.WriteFile(repoFile, 0644); err != nil || !result {\n          return fmt.Errorf(\"无法保存仓库配置文件：%s\", err)\n      }\n  \n      logger.Debugf(\"成功删除仓库地址: %s。\", repoName)\n      return nil\n  }\n  ```\n\n- > 此功能相当于: helm repo remove 仓库名\n\n### 更新仓库\n\n- ``` go\n  package kubestore\n  \n  import (\n      \"fmt\"\n      \"helm.sh/helm/v3/pkg/cli\"\n      \"helm.sh/helm/v3/pkg/getter\"\n      \"helm.sh/helm/v3/pkg/repo\"\n      \"kube-store-operator/commons/logger\"\n  )\n  \n  // 更新仓库的Helm Chart仓库\n  func update() (string, error) {\n      settings := cli.New()\n      // 加载仓库配置文件\n      repositories, err := repo.LoadFile(settings.RepositoryConfig)\n      if err != nil {\n          return \"\", fmt.Errorf(\"无法加载仓库配置文件：%s\", err)\n      }\n  \n      // 遍历每个仓库\n      for _, repoEntry := range repositories.Repositories {\n          // 添加要检索的仓库\n          chartRepository, err := repo.NewChartRepository(repoEntry, getter.All(settings))\n          if err != nil {\n              return \"\", fmt.Errorf(\"无法添加仓库：%s\\n\", err)\n          }\n  \n          // 更新仓库索引信息\n          if _, err := chartRepository.DownloadIndexFile(); err != nil {\n              return \"\", fmt.Errorf(\"无法下载仓库索引：%s\\n\", err)\n          }\n  \n          logger.Debugf(\"...Successfully got an update from the %s chart repository\", repoEntry.Name)\n      }\n  \n      return \"Update Complete. ⎈Happy Helming!⎈\", nil\n  }\n  ```\n\n- > 此功能相当于: helm repo update\n\n\n\n### 检索指定仓库中的Chart信息\n\n- ``` go\n  package kubestore\n  \n  import (\n      \"fmt\"\n      \"helm.sh/helm/v3/pkg/cli\"\n      \"helm.sh/helm/v3/pkg/repo\"\n      \"kube-store-operator/commons/logger\"\n  )\n  \n  // 查看指定仓库中最新的Chart信息\n  // search(仓库名)\n  func search(repoName string) ([]*ChartListResponse, error) {\n      settings := cli.New()\n  \n      path := fmt.Sprintf(\"%s/%s-index.yaml\", settings.RepositoryCache, repoName)\n      // 加载 xxx-index.yaml 文件\n      indexFile, err := repo.LoadIndexFile(path)\n      if err != nil {\n          return nil, fmt.Errorf(\"仓库 %s 不存在\", repoName)\n      }\n  \n      var chartList []*ChartListResponse\n  \n      // 遍历指定仓库的 Chart 信息\n      for _, entry := range indexFile.Entries {\n          // 将每个 Chart 的最新信息提取出来\n          chart := &ChartListResponse{\n              ChartName:    entry[0].Name,\n              ChartVersion: entry[0].Version,\n              AppVersion:   entry[0].AppVersion,\n              Description:  entry[0].Description,\n          }\n          chartList = append(chartList, chart)\n      }\n  \n      // 指定仓库的Chart信息\n      logger.Debugf(\"%s\", chartList)\n      return chartList, nil\n  }\n  ```\n\n- > 此功能相当于: helm search repo 仓库名\n\n### 检索指定仓库中Chart的所有版本信息\n\n- ``` go\n  package kubestore\n  \n  import (\n      \"fmt\"\n      \"helm.sh/helm/v3/pkg/cli\"\n      \"helm.sh/helm/v3/pkg/repo\"\n      \"kube-store-operator/commons/logger\"\n  )\n  \n  // 查看指定仓库的Chart所有版本信息\n  // searchAll(仓库名, Chart名)\n  func searchAll(repoName, chartName string) ([]*ChartListResponse, error) {\n      settings := cli.New()\n  \n      path := fmt.Sprintf(\"%s/%s-index.yaml\", settings.RepositoryCache, repoName)\n      // 加载 xxx-index.yaml 文件\n      indexFile, err := repo.LoadIndexFile(path)\n      if err != nil {\n          return nil, fmt.Errorf(\"仓库 %s 不存在\", repoName)\n      }\n  \n      var chartList []*ChartListResponse\n  \n      // 遍历指定仓库的 Chart 信息\n      for _, entry := range indexFile.Entries[chartName] {\n          // 将每个 Chart 的主要信息提取出来\n          chart := &ChartListResponse{\n              ChartName:    entry.Name,\n              ChartVersion: entry.Version,\n              AppVersion:   entry.AppVersion,\n              Description:  entry.Description,\n          }\n          chartList = append(chartList, chart)\n      }\n  \n      // 指定仓库的Chart信息\n      logger.Debugf(\"%s\", chartList)\n      return chartList, nil\n  }\n  ```\n  \n- > 此功能相当于: helm search repo 仓库名 -l\n\n\n\n### 将Chart安装部署到kubernetes\n\n- ``` go\n  package kubestore\n  \n  import (\n      \"fmt\"\n      \"helm.sh/helm/v3/pkg/action\"\n      \"helm.sh/helm/v3/pkg/chart/loader\"\n      \"helm.sh/helm/v3/pkg/cli\"\n      \"kube-store-operator/commons/logger\"\n      \"os\"\n  )\n  \n  // 安装Helm Chart\n  func installChart(deployRequest *DeployRequest) error {\n  \n      settings := cli.New()\n  \n      actionConfig := new(action.Configuration)\n      if err := actionConfig.Init(settings.RESTClientGetter(), deployRequest.Namespace, os.Getenv(\"HELM_DRIVER\"), logger.Debugf); err != nil {\n          return fmt.Errorf(\"初始化 action 失败\\n%s\", err)\n      }\n  \n      install := action.NewInstall(actionConfig)\n      install.RepoURL = deployRequest.RepoURL\n      install.Version = deployRequest.ChartVersion\n      install.Timeout = 30e9\n      install.CreateNamespace = true\n      install.Wait = true\n      // kubernetes 中的配置\n      install.Namespace = deployRequest.Namespace\n      install.ReleaseName = deployRequest.ReleaseName\n  \n      chartRequested, err := install.ChartPathOptions.LocateChart(deployRequest.ChartName, settings)\n      if err != nil {\n          return fmt.Errorf(\"下载失败\\n%s\", err)\n      }\n  \n      chart, err := loader.Load(chartRequested)\n      if err != nil {\n          return fmt.Errorf(\"加载失败\\n%s\", err)\n      }\n  \n      _, err = install.Run(chart, nil)\n      if err != nil {\n          return fmt.Errorf(\"执行失败\\n%s\", err)\n      }\n  \n      return nil\n  }\n  ```\n\n- > 此功能相当于: helm install\n\n### 将Chart从kubernetes中卸载\n\n- ``` go\n  package kubestore\n  \n  import (\n      \"fmt\"\n      \"helm.sh/helm/v3/pkg/action\"\n      \"helm.sh/helm/v3/pkg/chart/loader\"\n      \"helm.sh/helm/v3/pkg/cli\"\n      \"kube-store-operator/commons/logger\"\n      \"os\"\n  )\n  \n  // 卸载Helm Chart\n  func uninstallChart(namespace, releaseName string) error {\n  \n      settings := cli.New()\n  \n      actionConfig := new(action.Configuration)\n      if err := actionConfig.Init(settings.RESTClientGetter(), namespace, os.Getenv(\"HELM_DRIVER\"), logger.Debugf); err != nil {\n          return fmt.Errorf(\"初始化 action 失败\\n%s\", err)\n      }\n  \n      uninstall := action.NewUninstall(actionConfig)\n      uninstall.Timeout = 30e9 // 设置超时时间300秒\n      uninstall.KeepHistory = false\n  \n      resp, err := uninstall.Run(releaseName)\n      if err != nil {\n          return fmt.Errorf(\"卸载失败\\n%s\", err)\n      }\n  \n      logger.Infof(\"%s 成功卸载\\n\", resp.Release.Name)\n      return nil\n  }\n  ```\n\n- > 此功能相当于: helm uninstall\n\n\n\n### 代码中用到的实体对象\n\n- ``` go\n  package kubestore\n  \n  // DeployRequest\n  /**\n   * 部署时用到的结构体\n   */\n  type DeployRequest struct {\n      RepoURL      string                 // 仓库地址\n      ChartName    string                 // Chart名称\n      ChartVersion string                 // Chart版本\n      Namespace    string                 // 命名空间\n      ReleaseName  string                 // 在kubernetes中的程序名\n      Values       map[string]interface{} // values.yaml 配置文件\n  }\n  \n  // ---------------------------------------------------------------\n  \n  // ChartListResponse\n  /**\n   * 返回指定仓库中的所有Chart信息\n   */\n  type ChartListResponse struct {\n      ChartName    string // Chart名称\n      ChartVersion string // Chart版本\n      AppVersion   string // 应用版本\n      Description  string // 描述\n  }\n  ```\n\n\n\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/example/index.mdx",
    "content": "---\ntitle: 集成开发\nsidebar_position: 10\n---\n\n# 集成开发\n\n\n\n此文档的需要对于`helm cli`的使用有一定的了解\n\n\n\n文档的目的是为了降低集成开发初学者的学习门槛，并提供有关开发Operator的指导。\n\n对于那些计划自己开发一个Operator的开发者，这份文档可能会提供宝贵的帮助和指引。\n\n它包含了关于如何集成SDK的实际案例，以及如何在开发Operator时有效地利用集成开发环境。\n\n通过这份文档，读者可以更轻松地理解和应用SDK集成封装案例，同时也能够掌握开发Operator的关键步骤和技巧。\n\n\n\nSDK集成开发案例：\n\n- [Golang](/example/golang.md)\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: Helm 2 以来的变化\nsidebar_position: 1\n---\n\n## Helm 2 以来的变化\n\n本文详细列出了 Helm 3 引入的所有主要变化。\n\n### 移除 Tiller\n\n在 Helm 2 的开发周期中，我们引入了 Tiller。Tiller 在团队共享集群时发挥了重要作用——它使多个不同的操作人员能够与同一组 release 交互。\n\n随着 Kubernetes 1.6 默认启用基于角色的访问控制（RBAC），在生产环境中锁定 Tiller 的使用变得更加困难。由于可能存在大量的安全策略配置，我们的立场是提供一个宽松的默认配置。这使得新用户无需深入了解安全控制就能开始尝试 Helm 和 Kubernetes。但遗憾的是，这种宽松的配置可能会赋予用户超出预期的广泛权限。DevOps 和 SRE 在多租户集群中安装 Tiller 时需要学习额外的操作步骤。\n\n在了解了社区成员在某些场景中如何使用 Helm 之后，我们发现 Tiller 的 release 管理系统不需要依赖集群内的操作器来维护状态或充当 Helm release 信息的中心枢纽。相反，我们可以直接从 Kubernetes API server 获取信息，在客户端渲染 chart，并在 Kubernetes 中存储安装记录。\n\nTiller 的主要功能可以在没有 Tiller 的情况下实现，因此我们在 Helm 3 中做出的首要决定之一就是完全移除 Tiller。\n\n移除 Tiller 后，Helm 的安全模型得到了根本简化。Helm 3 现在支持现代 Kubernetes 的所有安全、身份认证和授权功能。Helm 的权限通过 [kubeconfig 文件](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 进行评估。集群管理员可以根据需要在任意粒度上限制用户权限。release 仍然记录在集群内，Helm 的其余功能保持不变。\n\n### 改进的升级策略：三方战略合并补丁\n\nHelm 2 使用两方战略合并补丁。在升级过程中，它会比较最近一次 chart 的 manifest 与新 chart 的 manifest（即 `helm upgrade` 时提供的 manifest）。它通过比较这两个 chart 的差异来确定需要对 Kubernetes 中的资源进行哪些更改。如果通过带外方式对集群进行了更改（例如通过 `kubectl edit`），这些更改不会被考虑。这导致资源无法回滚到之前的状态：因为 Helm 只将最后应用的 chart manifest 视为当前状态，如果 chart 状态没有变化，实际运行状态也不会被修改。\n\n在 Helm 3 中，我们现在使用三方战略合并补丁。Helm 在生成补丁时会同时考虑旧的 manifest、实际运行状态和新的 manifest。\n\n#### 示例\n\n让我们通过几个常见示例来说明这一变化的影响。\n\n##### 实际运行状态已更改时的回滚\n\n你的团队刚刚使用 Helm 在 Kubernetes 上将应用部署到生产环境。chart 中的 Deployment 对象的副本数设置为三个：\n\n```console\n$ helm install myapp ./myapp\n```\n\n一位新开发人员加入了团队。在他们入职第一天观察生产集群时，发生了一起可怕的咖啡洒在键盘上的事故，他们不小心将生产 deployment 的副本数从三个 `kubectl scale` 到了零：\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\n团队中的另一位开发人员注意到生产站点宕机了，决定将 release 回滚到之前的状态：\n\n```console\n$ helm rollback myapp\n```\n\n会发生什么？\n\n在 Helm 2 中，它会比较旧 manifest 和新 manifest 来生成补丁。由于这是回滚，所以是同一个 manifest。Helm 会认为旧 manifest 和新 manifest 没有区别，因此无需更改。副本数继续保持为零。问题来了。\n\n在 Helm 3 中，补丁是使用旧 manifest、实际运行状态和新 manifest 生成的。Helm 识别出旧状态是三个副本，实际运行状态是零，而新 manifest 希望将其改回三个，因此它会生成一个补丁将状态改回三个副本。\n\n##### 实际运行状态已更改时的升级\n\n许多服务网格和其他基于控制器的应用会向 Kubernetes 对象注入数据。这可能是 sidecar、标签或其他信息。假设你有一个从 chart 渲染的 manifest：\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\n而实际运行状态已被另一个应用修改为：\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n现在，你想将 `nginx` 镜像标签升级到 `2.1.0`。于是你升级到一个包含以下 manifest 的 chart：\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\n会发生什么？\n\n在 Helm 2 中，Helm 会根据旧 manifest 和新 manifest 生成 `containers` 对象的补丁。在生成补丁时不会考虑集群的实际运行状态。\n\n集群的实际运行状态会被修改为：\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nsidecar 容器从实际运行状态中被移除。麻烦大了。\n\n在 Helm 3 中，Helm 会根据旧 manifest、实际运行状态和新 manifest 生成 `containers` 对象的补丁。它注意到新 manifest 将镜像标签更改为 `2.1.0`，同时实际运行状态包含一个 sidecar 容器。\n\n集群的实际运行状态会被修改为：\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### Release 名称现在限定在 namespace 范围内\n\n随着 Tiller 的移除，每个 release 的信息需要存储在某个地方。在 Helm 2 中，这些信息存储在与 Tiller 相同的 namespace 中。实际上，这意味着一旦某个名称被某个 release 使用，其他 release 就无法使用该名称，即使它部署在不同的 namespace 中。\n\n在 Helm 3 中，特定 release 的信息现在存储在与 release 本身相同的 namespace 中。这意味着用户现在可以在两个不同的 namespace 中分别 `helm install wordpress stable/wordpress`，并且可以通过切换当前 namespace 上下文来使用 `helm list` 查看各自的 release（例如 `helm list --namespace foo`）。\n\n由于与原生集群 namespace 更好地对齐，`helm list` 命令默认不再列出所有 release。相反，它只会列出当前 Kubernetes 上下文所在 namespace 中的 release（即运行 `kubectl config view --minify` 时显示的 namespace）。这也意味着你必须在 `helm list` 中提供 `--all-namespaces` 参数才能获得与 Helm 2 类似的行为。\n\n### Secrets 作为默认存储驱动\n\n在 Helm 3 中，Secrets 现在被用作[默认存储驱动](/topics/advanced.md#storage-backends)。Helm 2 默认使用 ConfigMaps 来存储 release 信息。在 Helm 2.7.0 中，实现了一个使用 Secrets 存储 release 信息的新存储后端，这在 Helm 3 中成为了默认设置。\n\n将 Secrets 作为 Helm 3 的默认设置，结合 Kubernetes 中 Secret 加密的发布，可以为保护 chart 提供额外的安全性。\n\n[静态加密 Secrets](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) 在 Kubernetes 1.7 中作为 Alpha 功能提供，并在 Kubernetes 1.13 中成为稳定版。这允许用户对 Helm release 元数据进行静态加密，因此这是一个很好的起点，以后可以扩展到使用 Vault 等工具。\n\n### Go 导入路径变更\n\n在 Helm 3 中，Helm 将 Go 导入路径从 `k8s.io/helm` 更改为 `helm.sh/helm/v3`。如果你打算升级到 Helm 3 Go 客户端库，请确保更改你的导入路径。\n\n### Capabilities\n\n在渲染阶段可用的 `.Capabilities` 内置对象已被简化。\n\n[内置对象](/chart_template_guide/builtin_objects.md)\n\n### 使用 JSONSchema 验证 Chart Values\n\n现在可以对 chart values 施加 JSON Schema。这确保用户提供的 values 符合 chart 维护者制定的 schema，在用户为 chart 提供不正确的 values 时提供更好的错误报告。\n\n当调用以下任何命令时会进行验证：\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\n有关更多信息，请参阅 [Schema 文件](/topics/charts.md#schema-files) 文档。\n\n### 将 `requirements.yaml` 合并到 `Chart.yaml`\n\nchart 依赖管理系统从 requirements.yaml 和 requirements.lock 迁移到了 Chart.yaml 和 Chart.lock。我们建议用于 Helm 3 的新 chart 使用新格式。但是，Helm 3 仍然可以理解 Chart API 版本 1（`v1`），并会加载现有的 `requirements.yaml` 文件。\n\n在 Helm 2 中，`requirements.yaml` 如下所示：\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\n在 Helm 3 中，依赖项以相同的方式表达，但现在位于 `Chart.yaml` 中：\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nchart 仍然会被下载并放置在 `charts/` 目录中，因此已经放入 `charts/` 目录的子 chart 将继续正常工作，无需修改。\n\n### 安装时现在必须提供名称（或 --generate-name）\n\n在 Helm 2 中，如果未提供名称，则会生成一个自动名称。在生产环境中，这被证明更多是一个麻烦而不是有用的功能。在 Helm 3 中，如果 `helm install` 未提供名称，Helm 将抛出错误。\n\n对于仍然希望自动生成名称的用户，可以使用 `--generate-name` 参数。\n\n### 推送 Chart 到 OCI 注册中心\n\n这是 Helm 3 中引入的实验性功能。要使用此功能，请设置环境变量 `HELM_EXPERIMENTAL_OCI=1`。\n\n从宏观角度来看，chart 仓库是存储和共享 chart 的地方。Helm 客户端将 Helm chart 打包并发布到 chart 仓库。简单来说，chart 仓库是一个托管了 index.yaml 文件和一些打包 chart 的基本 HTTP 服务器。\n\n虽然 chart 仓库 API 在满足最基本的存储需求方面有几个优点，但一些缺点已经开始显现：\n\n- chart 仓库很难抽象出生产环境中所需的大多数安全实现。在生产场景中，拥有一个标准的认证和授权 API 非常重要。\n- Helm 用于签名和验证 chart 完整性和来源的 chart 来源工具是 chart 发布流程中的可选部分。\n- 在多租户场景中，同一个 chart 可能被另一个租户上传，导致存储相同内容需要两倍的存储成本。更智能的 chart 仓库已经被设计来处理这个问题，但这不是正式规范的一部分。\n- 使用单个索引文件进行搜索、元数据信息和获取 chart，使得在安全的多租户实现中设计起来变得困难或笨拙。\n\nDocker 的 Distribution 项目（也称为 Docker Registry v2）是 Docker Registry 项目的继任者。许多主要云厂商都提供 Distribution 项目的产品，随着如此多的厂商提供相同的产品，Distribution 项目受益于多年的加固、安全最佳实践和实战测试。\n\n请查看 `helm help chart` 和 `helm help registry` 了解有关如何打包 chart 并推送到 Docker 注册中心的更多信息。\n\n有关更多信息，请参阅[此页面](/topics/registries.md)。\n\n### 移除 `helm serve`\n\n`helm serve` 在你的机器上运行一个本地 chart 仓库用于开发目的。然而，它作为开发工具并未获得太多采用，而且在设计上存在诸多问题。最终，我们决定移除它并将其拆分为一个插件。\n\n如需获得类似 `helm serve` 的体验，请查看 [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) 中的本地文件系统存储选项和 [servecm 插件](https://github.com/jdolitsky/helm-servecm)。\n\n### Library chart 支持\n\nHelm 3 支持一类称为\"library chart\"的 chart。这是一种被其他 chart 共享但本身不创建任何 release 产物的 chart。library chart 的模板只能声明 `define` 元素。全局作用域的非 `define` 内容会被忽略。这允许用户复用和共享可在多个 chart 中使用的代码片段，避免冗余并保持 chart 的 [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) 原则。\n\nlibrary chart 在 Chart.yaml 的 dependencies 指令中声明，并像任何其他 chart 一样进行安装和管理。\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\n我们非常期待看到此功能为 chart 开发者带来的用例，以及使用 library chart 时产生的最佳实践。\n\n### Chart.yaml apiVersion 升级\n\n随着 library chart 支持的引入以及 requirements.yaml 合并到 Chart.yaml，理解 Helm 2 包格式的客户端将无法理解这些新功能。因此，我们将 Chart.yaml 中的 apiVersion 从 `v1` 升级到 `v2`。\n\n`helm create` 现在会使用这种新格式创建 chart，因此默认的 apiVersion 也相应升级。\n\n希望支持两个版本 Helm chart 的客户端应该检查 Chart.yaml 中的 `apiVersion` 字段来了解如何解析包格式。\n\n### XDG 基础目录支持\n\n[XDG 基础目录规范](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) 是一个可移植的标准，定义了配置、数据和缓存文件应该存储在文件系统的哪个位置。\n\n在 Helm 2 中，Helm 将所有这些信息存储在 `~/.helm`（亲切地称为 `helm home`），可以通过设置 `$HELM_HOME` 环境变量或使用全局参数 `--home` 来更改。\n\n在 Helm 3 中，Helm 现在按照 XDG 基础目录规范遵循以下环境变量：\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nHelm 插件仍然会收到 `$HELM_HOME` 作为 `$XDG_DATA_HOME` 的别名，以便向后兼容那些将 `$HELM_HOME` 用作临时环境的插件。\n\n为了适应这一变化，还有几个新的环境变量被传递到插件环境中：\n\n- `$HELM_PATH_CACHE` 用于缓存路径\n- `$HELM_PATH_CONFIG` 用于配置路径\n- `$HELM_PATH_DATA` 用于数据路径\n\n希望支持 Helm 3 的 Helm 插件应该考虑使用这些新的环境变量。\n\n### CLI 命令重命名\n\n为了更好地与其他包管理器的用语保持一致，`helm delete` 被重命名为 `helm uninstall`。`helm delete` 仍然保留为 `helm uninstall` 的别名，因此两种形式都可以使用。\n\n在 Helm 2 中，要清除 release 记录，需要提供 `--purge` 参数。此功能现在默认启用。要保留之前的行为，请使用 `helm uninstall --keep-history`。\n\n此外，还有其他几个命令被重命名以适应相同的约定：\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\n这些命令也保留了旧名称作为别名，因此你可以继续使用任一形式。\n\n### 自动创建 namespace\n\n当在不存在的 namespace 中创建 release 时，Helm 2 会创建该 namespace。Helm 3 遵循其他 Kubernetes 工具的行为，如果 namespace 不存在则返回错误。如果你明确指定 `--create-namespace` 参数，Helm 3 会创建该 namespace。\n\n### .Chart.ApiVersion 发生了什么变化？\n\nHelm 遵循驼峰命名的典型约定，即将首字母缩写词大写。我们在代码的其他地方也这样做了，例如 `.Capabilities.APIVersions.Has`。在 Helm v3 中，我们纠正了 `.Chart.ApiVersion` 以遵循这一模式，将其重命名为 `.Chart.APIVersion`。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/faq/index.mdx",
    "content": "---\ntitle: 常见问答(FAQ)\nsidebar_position: 8\n---\n\n# 常见问答\n\n> Helm 2和Helm 3的主要区别是什么?  \n> 该页面为最常见的问题提供帮助。\n\n**我们喜欢您的帮助** 使得该文档变得更好。添加、修改或移除信息,\n [提问题](https://github.com/helm/helm-www/issues)或者向我们提交pull request。\n\n## 从Helm 2发生的变化\n\n这里会展示一个对Helm3主要引入的变化的详尽列表。\n\n### 移除了Tiller\n\n在Helm 2的开发周期中，我们引入了Tiller。Tiller在团队协作中共享集群时扮演了重要角色。\n它使得不同的操作员与相同的版本进行交互称为了可能。\n\nKubernetes 1.6默认使用了基于角色的访问控制（RBAC），在生产环境对Tiller的锁定使用变得难于管理。\n由于大量可能的安全策略，我们的立场是提供一个自由的默认配置。这样可以允许新手用户可以乐于尝试Helm\n和Kubernetes而不需要深挖安全控制。 不幸的是这种自由的配置会授予用户他们不该有的权限。DevOps和SRE\n在安装多用户集群时不得不去学习额外的操作步骤。\n\n在听取了社区成员在特定场景使用Helm之后，我们发现Tiller的版本管理系统不需要依赖于集群内部用户去维护\n状态或者作为一个Helm版本信息的中心hub。取而代之的是，我们可以简单地从Kubernetes API server获取信息，\n在Chart客户端处理并在Kubernetes中存储安装记录。\n\nTiller的首要目标可以在没有Tiller的情况下实现，因此针对于 Helm 3 我们做的首要决定之一就是完全移除Tiller。\n\n随着Tiller的消失，Helm的安全模块从根本上被简化。Helm 3 现在支持所有Kubernetes流行的安全、\n身份和授权特性。Helm的权限通过你的\n[kubeconfig文件](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)进行评估。\n集群管理员可以限制用户权限，只要他们觉得合适，\n无论什么粒度都可以做到。版本发布记录和Helm的剩余保留功能仍然会被记录在集群中。\n\n### 改进升级策略: 三路策略合并补丁\n\nHelm 2 使用了一种双路策略合并补丁。在升级过程中，会对比最近一次的chart manifest和提出的\nchart manifest(通过`helm upgrade`提供)。升级会对比两个chart的不同来决定哪些更改会应用到Kubernetes资源中。\n如果更改是集群外带的（比如通过`kubectl edit`），则不会被考虑。结果就是资源不会回滚到之前的状态：\n因为Helm只考虑最后一次应用的chart manifest作为它的当前状态，如果chart状态没有更改，则资源的活动状态不会更改。\n\n现在Helm 3中，我们使用一种三路策略来合并补丁。Helm在生成一个补丁时会考虑之前老的manifest的活动状态。\n\n#### 示例\n\n让我们通过一些常见的例子来看看变化带来的影响。\n\n##### 回滚已经改变的活动状态\n\n你的团队正好在Kubernetes上使用Helm部署了生产环境应用。chart包含了一个部署对象使用了三套副本：\n\n```console\n$ helm install myapp ./myapp\n```\n\n一个开发新人加入了团队。当他们第一点观察生产环境集群时，发生了一个像是咖啡洒在了键盘上一样的严重事故，\n他们使用 `kubectl scale` 对生产环境部署进行缩容，将副本数从3降到了0 。\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\n团队里面的另一个人看到线上环境已经挂了就决定回滚这个版本到之前的状态：\n\n```console\n$ helm rollback myapp\n```\n\n发生了什么？\n\n在Helm 2中，会生成一个补丁并对比老的manifest和新的manifest。因为这是一个回滚，manifest是一样的。\nHelm会认为新老manifest没有区别，因此没有需要更改的内容。副本统计数量继续保持为0。恐慌就接踵而至。\n\n在Helm 3中，是用老的manifest生成新的补丁，活动状态和新的manifest。\nHelm 意识到老的状态是3，而现有活动状态是0，并且新的manifest希望改回3，因此会生成一个补丁将状态改回3。\n\n##### 活动状态已更改的情况下升级\n\n很多服务网格和其他基于controller的应用向Kubernetes对象中注入数据。比如sidecar、label和其他信息。\n之前如果你从Chart渲染给定的manifest如下:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\n并且另一个应用修改活动状态如下：\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n现在你想升级`nginx`镜像到`2.1.0`。因此用指定的manifest升级chart：\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\n发生了什么？\n\n在Helm 2中，Helm 在新老manifest之间生成了一个`containers`对象的补丁。\n生成补丁的过程中不考虑集群的活动状态。\n\n集群的活动状态被修改成了这样:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nsidecar pod从活动状态中移除了。更多的恐慌袭来。\n\n在Helm 3中，Helm 在新的manifest、活动状态和老manifest之间生成了一个`containers`对象的补丁。\n会注意到新的manifest将镜像tag更新为`2.1.0`, 但是活动状态中包含了一个sidecar容器。\n\n集群的活动状态被修改成了下面这样：\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### 发布名称现在限制在namespace范围内\n\n随着Tiller的移除， 每个版本的信息需要保存在某个地方。\n在Helm 2中，是存储在Tiller相同的命名空间中。\n实际上这意味着一个发布版本使用一个名称，其他发布不能使用相同的名称，\n即使在不同的命名空间中也不行。\n\n在Helm 3中，特定的版本信息作为发布本身存储在相同的命名空间中。\n意味着用户现在可以在两个分开的命名空间中使用`helm install wordpress stable/wordpress`，\n并且每个都能使用 `helm list` 改变当前命名空间。 (例如 `helm list --namespace foo`)。\n\n与本地集群命名空间更好的一致性，使得 `helm list` 命令不再需要默认列出所有发布版本的列表。\n取而代之的是，仅仅会在命名空间中列出当前kubernetes上下文的版本。\n(也就是说运行`kubectl config view --minify`时会显示命名空间). 也就意味着您在执行`helm list`时必须提供\n `--all-namespaces` 标识才能获得和Helm 2同样的结果。\n\n### 作为默认存储器的密钥\n\n在 Helm 3中, 密钥被作为[默认存储驱动](/topics/advanced.md)使用。\nHelm 2默认使用ConfigMaps记录版本信息。在Helm 2.7.0中，新的存储后台使用密钥来存储版本信息，\n现在是Helm 3的默认设置。\n\nHelm 3默认允许更改密钥作为额外的安全措施在Kubernetes中和密钥加密一起保护chart。\n\n[静态加密密钥](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)\n在Kubernetes 1.7中作为alpha特性可以使用了，在Kubernetes 1.13中变成了稳定特性。\n这允许用户静态加密Helm的发布元数据，同时也是一个类似Vault的以后可扩展的良好起点。\n\n### 更改了Go的path导入\n\n在Helm 3中，Helm将Go的import路径从`k8s.io/helm`切换到了`helm.sh/helm/v3`。如果你打算\n升级到Helm 3的Go客户端库，确保你已经更改了import路径。\n\n### Capabilities\n\n`.Capabilities`内置对象会在已经简化的渲染阶段生效。\n\n[内置对象](/chart_template_guide/builtin_objects.md)\n\n### 使用Json格式验证Chart Values\n\nchart values现在可以使用JSON结构了。这保证用户提供value可以按照chart维护人员设置的结构排列，\n并且当用户提供了错误的chart value时会有更好错误提示。\n\n当调用以下命令时会进行JSON格式验证：\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\n查看 [格式文档](/topics/charts.md) 了解更多信息。\n\n### 将 `requirements.yaml` 合并到了 `Chart.yaml`\n\nChart依赖体系从 requirements.yaml 和 requirements.lock 移动到 Chart.yaml\n和 Chart.lock。我们推荐在Helm 3的新chart中使用新格式。不过Helm 3 依然可以识别\nChart API 版本1 (`v1`) 并且会加载已有的 `requirements.yaml` 文件。\n\nHelm 2中，`requirements.yaml` 看起来是这样的:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nHelm 3中， 依赖使用了同样的表达方式，现在`Chart.yaml`是这样的：\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nChart会依然下载和放置在 `charts/` 目录， 因此 `charts/` 目录中的子chart不作修改即可继续工作。\n\n### Name (或者 --generate-name) 安装时是必需的\n\nHelm 2中，如果没有提供名称， 会自动生成一个名称。在生产环境，这被证明是一个麻烦事而不是一个有用的特性。\n而在Helm 3中，如果 `helm install` 没有提供name，会抛异常。\n\n如果仍然需要一个自动生成的名称，您可以使用 `--generate-name` 创建。\n\n### 推送Chart到OCI注册中心\n\n这是一个Helm 3 中的实验性特性。使用时需要设置环境变量 `HELM_EXPERIMENTAL_OCI=1`。\n\nChart仓库在较高层次上是一个存储和分发Chart的地址。Helm客户端打包并将Chart推送到Chart仓库中。\n简单来说，Chart仓库就是一个基本的HTTP服务器用来存放index.yaml文件和打包的chart。\n\nChart 仓库API满足最基本的需求有一些好处，但是有些缺点开始显现出来：\n\n* Chart 仓库很难在生产环境抽象出大部分的安全性实现。在生产环境有一个认证和授权的标准API就显得格外重要。\n* Helm Chart的初始化工具用来签名和验证chart的完整性和来源，在chart的发布过程中是可选的。\n* 在多客户场景中，同一个chart可以被其他客户上传，同样的内容会被存储两次。chart仓库可以更加智能地处理\n这个问题，但并不是正式规范的一部分。\n* 在安全的多客户实现中使用单一的索引文件进行搜索、元数据信息存放和获取chart会变得困难和笨拙。\n\nDocker的分发项目（也称作Docker注册中心 v2）是Docker 注册项目的继承者。 很多主要的云供应商都提供项目\n分发，很多供应商都提供相同的产品， 这个分发项目得益于多年的强化、安全性实践和对抗测试。\n\n请查看 `helm help chart` 和 `helm help registry` 了解如何打包chart并推送到Docker注册中心的更多信息。\n\n更多信息请查看 [注册中心](https://docs.helm.sh/zh/docs/topics/registries/)页面。\n\n### 移除了`helm serve`\n\n`helm serve` 命令可以在你本地机器运行一个Chart仓库用于开发目的。\n然而作为一个开发工具并没有受到太多利用，并且设计上有很多问题。最终我们决定移除它，\n拆分成了一个插件。\n\n对于 `helm serve` 的类似经历，可以查看本地文件系统存储选项在\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\n和 [servecm plugin](https://github.com/jdolitsky/helm-servecm).\n\n### Library chart支持\n\nHelm 3 支持的一类chart称为 “library chart”。 这是一个被其他chart共享的chart，\n但是它自己不能创建发布组件。library chart的模板只能声明 `define` 元素。 全局范围\n内的非`define`内容会被简单忽略。这允许用户复用和共享可在多个chart中重复使用的代码片段。\n避免冗余和保留chart [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)。\n\nLibrary chart在 Chart.yaml的依赖指令中声明，安装和管理与其他chart一致。\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\n我们很高兴对开发者开放了这个特性的使用案例，以及library charts使用的最佳实践。\n\n### Chart.yaml api版本切换\n\n随着对library chart的支持以及requirements.yaml合并到Chart.yaml，客户端可以识别Helm 2的包格式而不理解\n这些新特性。因此我们将Chart.yaml的apiVersion从 `v1` 切换到了 `v2`。\n\n`helm create` 现在使用使用新格式创建chart，默认的apiVersion也切换到了这里。\n\n客户端希望同时支持两个版本，进而能够检查Chart.yaml的`apiVersion`字段去理解如何解析包格式。\n\n### XDG 基本目录支持\n\n[XDG 基本目录规范](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)\n是一个定义了配置、数据和缓存文件应该存储在文件系统什么位置的可移植标准。\n\nHelm 2中，Helm 将所有的信息存储在 `~/.helm` (被亲切地称为`helm home`)，可以通过设置 `$HELM_HOME`\n环境变量修改，或者使用全局参数 `--home`。\n\nHelm 3中，Helm现在遵守XDG 基本目录规范使用以下环境变量：\n\n* `$XDG_CACHE_HOME`\n* `$XDG_CONFIG_HOME`\n* `$XDG_DATA_HOME`\n\nHelm 插件仍然使用 `$HELM_HOME` 作为 `$XDG_DATA_HOME` 的别名，以便希望将`$HELM_HOME`作为过渡环境的变量来保证向后兼容性。\n\n一些新的环境变量也通过插件环境变量来兼容以下更改：\n\n* `$HELM_PATH_CACHE` 针对缓存路径\n* `$HELM_PATH_CONFIG` 针对配置路径\n* `$HELM_PATH_DATA` 针对data路径\n\n如果Helm插件期望支持Helm 3，建议使用新的环境变量。\n\n### CLI 命令重新命名\n\n为了更好地从包管理器中调整不当措辞，`helm delete`被重命名为`helm uninstall`。\n `helm delete` 依然作为 `helm uninstall` 的别名保留， 因此其他格式也能使用。\n\nHelm 2 中为了清除版本清单，必须提供`--purge`参数。这个功能现在是默认使用的。\n为保留之前的操作行为，要使用 `helm uninstall --keep-history`。\n\n另外，其他一些重命名的命令提供了以下约定：\n\n* `helm inspect` -> `helm show`\n* `helm fetch` -> `helm pull`\n\n这些命令都保留了老的动词作为别名，因此您能够使用任意一种格式。\n\n### 自动创建namespace\n\n当用命名空间创建版本时，命名空间不存在，Helm 2会创建一个命名空间。\nHelm 3中沿用了其他Kubernetes 工具的形式，如果命名空间不存在，就返回错误。\n如果您明确指定 `--create-namespace` 参数，Helm 3 会创建一个命名空间。\n\n### .Chart.ApiVersion是怎么回事?\n\nHelm针对缩略语遵循驼峰命名的典型惯例。我们已经在代码的其他位置做了处理，比如\n`.Capabilities.APIVersions.Has`。Helm v3中，我们将 `.Chart.ApiVersion`\n更正成了`.Chart.APIVersion`。\n\n## 安装\n\n### 为什么没有针对Fedora和其他Linux发行版的Helm原生包?\n\nHelm 项目不维护针对操作系统和环境的包。Helm 社区如果觉得需要提供原生包时，可以提供原生包。\n这是Homebrew 开始列出的方案。如果您有兴趣维护一个包，我们会很高兴的。\n\n### 为什么会提供 `curl ...|bash` 脚本?\n\n我们的仓库(`scripts/get-helm-3`)中有个脚本可以作为 `curl ..|bash` 脚本执行。\n使用HTTPS传输，The transfers are all protected by HTTPS, 并且这个脚本对它获取到包做一些审核。\n然而这个脚本有任何shell脚本的所有常见危险。\n\n我们提供这个脚本因为它很好用，但是我们建议用户先仔细阅读这个脚本。不过我们真正想要的是更好的Helm打包版本。\n\n### 我如何将Helm客户端文件放置在其他位置而不是默认位置?\n\nHelm 使用XDG结构存储文件。这些环境变量可以用来覆盖默认位置:\n\n* `$XDG_CACHE_HOME`: 设置另一个存储缓存文件的位置。\n* `$XDG_CONFIG_HOME`: 设置另一个存储Helm配置的位置。\n* `$XDG_DATA_HOME`: 设置另一个存储Helm数据的位置。\n\n注意，如果有已经存在的仓库，您需要使用 `helm repo add...` 重新添加。\n\n## 卸载\n\n### 我想删除我本地Helm. 全部文件在什么位置？\n\n连同 `helm` 二进制文件一起，Helm将文件存储在以下位置：\n\n* $XDG_CACHE_HOME\n* $XDG_CONFIG_HOME\n* $XDG_DATA_HOME\n\n下面这个表格按照操作系统给出了对应的默认文件夹位置：\n\n| Operating System | Cache Path                  | Configuration Path               | Data Path                 |\n|------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux            | `$HOME/.cache/helm`         | `$HOME/.config/helm`             | `$HOME/.local/share/helm` |\n| macOS            | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm`      |\n| Windows          | `%TEMP%\\helm`               | `%APPDATA%\\helm`                 | `%APPDATA%\\helm`          |\n\n## 故障排除\n\n### 在 GKE (Google Container Engine) 我遇到了 \"No SSH tunnels currently open\"\n\n```consol\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\n另一个错误消息的形式：\n\n```consol\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\n这个问题是说您本地的Kubernetes 配置文件需要有正确的证书。\n\n当你在GKE上创建集群时，它会为您提供一个证书，包括SSL证书和证书颁发机构。\n这些需要放在Kubernetes配置文件中（默认位置: `~/.kube/config`），保证 `kubectl` 和 `helm` 可以访问他们。\n\n### 从Helm 2迁移后， `helm list` 仅显示部分（或者不显示）我的发布版本\n\n您很可能忽略了一个事实：Helm 3 现在使用集群的命名空间来确定版本范围。 这意味着所有涉及版本的命令您都必须：\n\n* 在活动的kubernetes上下文中需要依赖当前的命名空间 (如 `kubectl config view --minify` 命令所述)，\n* 使用 `--namespace`/`-n` 参数指定正确命名空间，或者\n* 对于 `helm list` 命令，指定 `--all-namespaces`/`-A` 参数\n\n这适用于 `helm ls`、 `helm uninstall` 以及其他所有涉及版本的 `helm` 命令。\n\n### 为什么在macOS上`/etc/.mdns_debug`文件可以访问？\n\n我们了解到macOS上的一个案例是Helm会试图访问`/etc/.mdns_debug`文件。\n如果文件存在，Helm会在文件句柄执行的时候保持打开状态。\n\n这是因为macOS的 MDNS 库。它尝试去加载这个文件读取debug设置（如果已经启用）。\n这个文件句柄可能不会保持打开，且这个问题已经报告给了苹果。 然而这种行为是macOS导致的，并不是Helm。\n\n如果你不想让Helm加载这个文件，你可以将Helm编译成一个静态库而不使用主机网络堆栈。\n这样做会导致Helm的二进制文件大小膨胀，但是会阻止这个文件打开。\n\n这个问题最初被标记为潜在的安全问题。但后来已经确定，这种行为不存在任何缺陷或漏洞。\n\n### helm 仓库使用时添加仓库失败\n\n在Helm 3.3.1及之前版本，`helm repo add <reponame> <url>`在你添加已经存在的仓库时不会输入内容。\n如果仓库已经存在，`--no-update` 参数会报错。\n\n在Helm3.3.2及之后版本，试图添加一个已存在的仓库时会报以下错误：\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\n现在这个默认行为是相反的。`--no-update` 现在被忽略。当您想替换（覆盖）已有仓库时，您可以使用 `--force-update`。\n\n这是由于一个安全修复做出的重大更改，详情见[Helm 3.3.2 release notes](https://github.com/helm/helm/releases/tag/v3.3.2)。\n\n### 开启 Kubernetes 客户端日志\n\n调试Kubernetes客户端打印日志时，可以使用[klog](https://pkg.go.dev/k8s.io/klog) 参数。使用`-v`可以设置日志级别应用于大多数场景。\n\n例如：\n\n```consol\nhelm list -v 6\n```\n\n### Tiller停止安装且无法访问\n\nHelm 发布之前可以从 [https://storage.googleapis.com/kubernetes-helm/](https://storage.googleapis.com/kubernetes-helm/) 获取。如[\"Announcing\nget.helm.sh\"](https://helm.sh/blog/get-helm-sh/)中所述，官方地址2019年6月已变更。\n[GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller)\n可以获取所有旧的Tiller镜像。\n\n如果你想从原来的存储位置下载Helm旧版本，你会发现找不到了：\n\n```console\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\n[原有Tiller镜像地址](https://gcr.io/kubernetes-helm/tiller) 会在2021年8月开始删除镜像。我们已经增加了可用地址在\n[GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller)。\n比如下载v2.17.0，用\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` 替换\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\n使用Helm v2.17.0初始化：\n\n`helm init —upgrade`\n\n或者如果需要另一个版本，使用 --tiller-image 替换默认位置安装特定的Helm v2 版本：\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**注意** Helm维护人员建议迁移到当前支持的Helm版本。Helm v2.17.0 是Helm 2的最终版本；Helm\nv2自2020年11月起便不再支持，具体细节请查看[Helm 2 和 Charts Project 已不再支持](https://helm.sh/blog/helm-2-becomes-unsupported/)。\n自那以后，Helm已经被发现很多的CVE，这些漏洞已经在Helm v3修复，但不会再给Helm v2打补丁。现在查看\n[Helm当前已发布的建议列表](https://github.com/helm/helm/security/advisories?state=published)并计划\n[迁移到 Helm v3](https://helm.sh/docs/topics/v2_v3_migration/#helm)吧。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/faq/installing.md",
    "content": "---\ntitle: 安装\nsidebar_position: 2\n---\n\n## 安装\n\n### 为什么 Fedora 和其他 Linux 发行版没有 Helm 的原生软件包？\n\nHelm 项目不维护各操作系统和环境的软件包。Helm 社区可能会提供原生包，如果 Helm 项目得知这些包的存在，会将其列出。Homebrew formula 最初就是这样被创建并列出的。如果你有兴趣维护一个软件包，我们非常欢迎。\n\n### 为什么提供 `curl ...|bash` 脚本？\n\n我们的仓库中有一个脚本（`scripts/get-helm-3`）可以通过 `curl ..|bash` 方式执行。所有传输都受 HTTPS 保护，脚本会对获取的软件包进行一些审计。但是，该脚本与任何 shell 脚本一样存在常见风险。\n\n我们提供这个脚本是因为它很实用，但建议用户先仔细阅读脚本内容。不过，我们更希望能有更完善的 Helm 打包发行版。\n\n### 如何将 Helm 客户端文件存放在默认位置以外的地方？\n\nHelm 使用 XDG 结构存储文件。你可以使用以下环境变量覆盖这些位置：\n\n- `$XDG_CACHE_HOME`：设置缓存文件的替代存储位置。\n- `$XDG_CONFIG_HOME`：设置 Helm 配置的替代存储位置。\n- `$XDG_DATA_HOME`：设置 Helm 数据的替代存储位置。\n\n注意，如果你已有仓库，需要使用 `helm repo add...` 重新添加。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: 故障排查\nsidebar_position: 4\n---\n\n## 故障排查\n\n### 我收到\"Unable to get an update from the \"stable\" chart repository\"警告\n\n运行 `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` 提供，但不再接收更新。\n\n你可以运行以下命令修复仓库：\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\n`incubator` 仓库也是同样的情况，其归档版本在 https://charts.helm.sh/incubator。你可以运行以下命令修复：\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### 我收到警告 'WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.'\n\n旧的 Google Helm chart 仓库已被新的 Helm chart 仓库替代。\n\n运行以下命令可永久解决此问题：\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\n如果 `incubator` 出现类似错误，运行以下命令：\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### 添加 Helm 仓库时收到错误 'Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available'\n\nHelm 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。\n\n### 在 GKE（Google Container Engine）上收到 \"No SSH tunnels currently open\" 错误\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\n错误信息的另一种形式是：\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\n原因是本地 Kubernetes 配置文件必须具有正确的凭据。\n\n在 GKE 上创建集群时，会提供凭据（包括 SSL 证书和证书颁发机构）。这些信息需要存储在 Kubernetes 配置文件中（默认位置：`~/.kube/config`），以便 `kubectl` 和 `helm` 能够访问。\n\n### 从 Helm 2 迁移后，`helm list` 只显示部分（或不显示）release\n\n这很可能是因为 Helm 3 现在使用集群 namespace 来区分 release 的作用域。这意味着所有涉及 release 的命令必须满足以下条件之一：\n\n* 依赖当前 Kubernetes 上下文中的活动 namespace（使用 `kubectl config view --minify` 命令可查看）\n* 使用 `--namespace`/`-n` 参数指定正确的 namespace\n* 对于 `helm list` 命令，指定 `--all-namespaces`/`-A` 参数\n\n这适用于 `helm ls`、`helm uninstall` 以及所有涉及 release 的 `helm` 命令。\n\n### 在 macOS 上访问了文件 `/etc/.mdns_debug`，这是为什么？\n\n在 macOS 上存在一种情况：Helm 会尝试访问名为 `/etc/.mdns_debug` 的文件。如果该文件存在，Helm 会在执行期间保持文件句柄处于打开状态。\n\n这是由 macOS 的 MDNS 库导致的。该库会尝试加载此文件以读取调试设置（如果已启用）。文件句柄可能不应该保持打开状态，此问题已报告给 Apple。但这是 macOS 的行为，而非 Helm 导致的。\n\n如果你不希望 Helm 加载此文件，可以将 Helm 编译为不使用主机网络栈的静态库。这样做会增加 Helm 的二进制文件大小，但可以防止打开该文件。\n\n此问题最初被标记为潜在的安全问题，但后来确定此行为不会导致任何缺陷或漏洞。\n\n### helm repo add 失败，但以前可以正常使用\n\n在 Helm 3.3.1 及更早版本中，如果尝试添加已存在的仓库，`helm repo add <reponame> <url>` 命令不会有任何输出。使用 `--no-update` 参数时，如果仓库已注册则会报错。\n\n在 Helm 3.3.2 及更高版本中，尝试添加已存在的仓库会报错：\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\n现在默认行为已更改。`--no-update` 现在被忽略，如果要替换（覆盖）已存在的仓库，可以使用 `--force-update`。\n\n这是一项安全修复导致的破坏性更改，详见 [Helm 3.3.2 发布说明](https://github.com/helm/helm/releases/tag/v3.3.2)。\n\n### 启用 Kubernetes 客户端日志\n\n可以使用 [klog](https://pkg.go.dev/k8s.io/klog) 参数来启用 Kubernetes 客户端的调试日志消息输出。在大多数情况下，使用 `-v` 参数设置详细级别即可。\n\n例如：\n\n```\nhelm list -v 6\n```\n\n### Tiller 安装停止工作并且访问被拒绝\n\n以前可以从 <https://storage.googleapis.com/kubernetes-helm/> 获取 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 镜像。\n\n如果你尝试从过去使用的存储桶下载旧版本的 Helm，可能会发现它们已被移除：\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\n[旧版 Tiller 镜像位置](https://gcr.io/kubernetes-helm/tiller)从 2021 年 8 月开始移除镜像。我们已将这些镜像托管到 [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller)。例如，要下载 v2.17.0 版本，将：\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\n替换为：\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\n使用 Helm v2.17.0 初始化：\n\n`helm init —upgrade`\n\n或者如果需要其他版本，使用 --tiller-image 参数覆盖默认位置并安装特定的 Helm v2 版本：\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**注意：** 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)的计划。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: 卸载\nsidebar_position: 3\n---\n\n## 卸载\n\n### 我想删除本地的 Helm，它的文件存放在哪里？\n\n除了 `helm` 二进制文件之外，Helm 还将一些文件存储在以下位置：\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\n下表列出了各操作系统上这些目录的默认路径：\n\n| 操作系统 | 缓存路径                    | 配置路径                          | 数据路径                  |\n|----------|-----------------------------|---------------------------------|---------------------------|\n| Linux    | `$HOME/.cache/helm`         | `$HOME/.config/helm`             | `$HOME/.local/share/helm` |\n| macOS    | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm`      |\n| Windows  | `%TEMP%\\helm`               | `%APPDATA%\\helm`                 | `%APPDATA%\\helm`          |\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/glossary/index.mdx",
    "content": "---\ntitle: 术语表\ndescription: 用于描述Helm体系结构的组件。\nsidebar_position: 9\n---\n\n# 术语表\n\n## Chart\n\nHelm包涵盖了将Kubernetes资源安装到Kubernetes集群所需要的足够多的信息。\n\nCharts包含`Chart.yaml`文件和模板，默认值(`values.yaml`)，以及相关依赖。\n\nCharts开发设计了良好定义的目录结构，并且打包成了一种称为 _chart archive_ 文件格式。\n\n## Chart包\n\nChart包(_chart archive_)是被tar和gzip压缩(并且可选签名)的chart.\n\n## Chart依赖 (子chart)\n\nChart可以依赖于其他的chart。 依赖可能会以以下两种方式出现:\n\n- 软依赖： 如果另一个chart没有在集群中安装，chart可能会无法使用。Helm未对这个案例提供工具。\n这个案例中，依赖会被分别管理。\n- 硬依赖： 一个chart可以包含 (在它的`charts/`目录中) 另一个它所依赖的chart。这个案例中，\n安装chart的同时会安装所有依赖。chart和它的依赖会作为一个集合进行管理。\n\n当一个chart(通过`helm package`)打包时所有的依赖都会和它绑定。\n\n## Chart版本\n\nChart版本根据 [语义化版本2.0 细则](https://semver.org) 发布。每个chart都需要版本号。\n\n## Chart.yaml\n\nchart的信息说明被存储在一个特定文件`Chart.yaml`。每个chart都必须有这个文件。\n\n## Helm (以及helm)\n\nHelm 是Kubernetes的包管理器。作为一个操作系统包管理器，使其很容易在操作系统中安装工具。\nHelm使得Kubernetes集群中安装应用和资源变得异常简单。\n\n当 _Helm_ 是项目名称时, 命令行客户端也可以使用 `helm`。按照惯例，当指项目时，_Helm_ \n使用大写。当指命令行时, _helm_ 使用小写。\n\n## Helm配置文件 (XDG)\n\nHelm将配置文件存储在XDG目录中。`helm`第一次运行时这些目录会自动生成。\n\n## Kube 配置 (KUBECONFIG)\n\nHelm客户端会通过使用 _Kube config_ 文件格式来理解Kubernetes集群。\n默认情况下，Helm会尝试在 `kubectl` 创建的 (`$HOME/.kube/config`) 目录中查找这些文件。\n\n## 代码规范 (进行中)\n\n规范(_lint_) 一个chart是去验证其遵照Helm chart的标准规范和要求。\nHelm提供了工具来处理，尤其是`helm lint`命令。\n\n## 来源 (来源文件)\n\nHelm chart可以由来源文件(_provenance file_)提供chart的出处及它所包含的内容。\n\n来源文件是Helm安全故事的一部分。一个来源包含chart包文件的加密哈希值，Chart.yaml数据，\n和一个签名块（一个OpenPGP \"clearsign\" 块）。当再加上一个钥匙链时，可以为chart用户提供\n以下能力：\n\n- 验证chart被可信第三方签名\n- 验证chart文件没有被篡改\n- 验证chart的元数据内容(`Chart.yaml`)\n- 快速匹配chart的数据来源\n\n来源文件有`.prov`扩展名，可以由chart仓库服务器或其他HTTP服务器提供。\n\n## 发布版本\n\nchart安装之后，Helm库会创建一个 _release_ 来跟踪这个安装。\n\n单个chart可以在同一个集群中安装多次，并能创建多个不同的版本。例如，可以使用 `helm install` \n命令以不同的版本安装三个PostgreSQL 数据库三次。\n\n## 版本号\n\n单个版本号可以被升级多次。通过连续技术来跟踪升级发布版本。在第一次`helm install`之后，一个版本\n会有 _release number_ 1，每一次版本升级或回滚，版本号都会升级。\n\n## 回滚\n\n每一次发布会更新chart或者配置。当生成发布历史后，一次发布也可以被 _rolled back_ 之前的发布版本号。\n回滚使用 `helm rollback` 命令实现。\n\n重要的是, 每一次回滚版本会生成一个新的发布版本号。\n\n| 操作       | 版本号                                       |\n|------------|------------------------------------------------------|\n| install    | release 1                                            |\n| upgrade    | release 2                                            |\n| upgrade    | release 3                                            |\n| rollback 1 | release 4 (但使用release 1的配置) |\n\n上面的列表阐明了发布版本号是怎样通过安装，升级和回滚递增的。\n\n## Helm库 (或SDK)\n\nHelm库（或SDK）涉及到go代码，可以直接与Kubernetes API服务交互进行安装、升级、查询\n以及移除Kubernetes资源。可以被导入到项目中作为客户端库使用而不是用作CLI命令。\n\n## 仓库 (Repo, Chart Repository)\n\nHelm图标chart可以被存储在专用的HTTP服务器上，称之为 _chart 仓库_（_repositories_，或者就叫 _repos_）。\n\nchart仓库服务器就是一个简单的HTTP服务器，提供一个`index.yaml` 文件来描述一批chart，\n并且提供每个chart的下载位置信息。(很多chart仓库同时提供chart和 `index.yaml`文件。)\n\nHelm客户端可以指向0个或多个chart仓库。默认没有配置仓库。Chart仓库可以随时使用`helm repo add`命令添加。\n\n## Values (Values文件, values.yaml)\n\nValues 提供了一种使用您自己的信息覆盖模板默认值的方式。\n\nHelm Chart是\"参数化的\", 这意味着chart开发者可以在安装时显式配置。比如说，chart可以暴露`username`字段，\n允许为服务设置一个用户名。\n\n这些可暴露的变量在Helm用语中称为 _values_。\n\nValues可以在 `helm install`时和`helm upgrade`时设置，直接把它们传值进来，也可以使用`values.yaml`文件设置。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/_category_.json",
    "content": "{\n  \"link\": { \"type\": \"doc\", \"id\": \"helm-category\" }\n}\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\n针对 Kubernetes 的 Helm 包管理器。\n\n### 简介\n\nKubernetes 包管理器\n\nHelm 常用操作：\n\n- helm search:    搜索 chart\n- helm pull:      下载 chart 到本地目录查看\n- helm install:   安装 chart 到 Kubernetes\n- helm list:      列出 release\n\n环境变量：\n| 名称                               | 描述                                                                             |\n|------------------------------------|---------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | 设置一个存储缓存文件的可选位置                                                     |\n| $HELM_CONFIG_HOME                  | 设置一个存储Helm配置的可选位置                                                     |\n| $HELM_DATA_HOME                    | 设置一个存储Helm数据的可选位置                                                     |\n| $HELM_DEBUG                        | 表示Helm是否在Debug模式下运行                                                     |\n| $HELM_DRIVER                       | 设置后台存储驱动，可选值包括：configmap、secret、memory、sql                           |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | 设置 SQL 存储驱动使用的连接字符串                                                      |\n| $HELM_MAX_HISTORY                  | 设置 release 历史记录的最大数量                                                           |\n| $HELM_NAMESPACE                    | 设置用于helm操作的命名空间                                                         |\n| $HELM_NO_PLUGINS                   | 禁用插件，HELM_NO_PLUGINS=1 表示禁用插件                                           |\n| $HELM_PLUGINS                      | 设置插件目录路径                                                                  |\n| $HELM_REGISTRY_CONFIG              | 设置注册配置文件的路径                                                             |\n| $HELM_REPOSITORY_CACHE             | 设置仓库缓存目录路径                                                               |\n| $HELM_REPOSITORY_CONFIG            | 设置仓库文件的路径                                                                 |\n| $KUBECONFIG                        | 设置 Kubernetes 的备用配置文件（默认 \"~/.kube/config\"）                               |\n| $HELM_KUBEAPISERVER                | 设置用于身份认证的Kubernetes API服务端                                             |\n| $HELM_KUBECAFILE                   | 设置Kubernetes证书机构文件                                                         |\n| $HELM_KUBEASGROUPS                 | 使用逗号分隔的列表设置用于模拟的组                                                   |\n| $HELM_KUBEASUSER                   | 为操作设置要模拟的用户名                                                            |\n| $HELM_KUBECONTEXT                  | 设置kubeconfig上下文的名称                                                         |\n| $HELM_KUBETOKEN                    | 设置用于身份验证的 Bearer KubeToken                                                   |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | 设置 Kubernetes API 服务的证书验证是否跳过（不安全）                             |\n| $HELM_KUBETLS_SERVER_NAME          | 设置用于验证 Kubernetes API 服务器证书的服务器名称                                      |\n| $HELM_BURST_LIMIT                  | 设置当 Kubernetes 服务包含大量 CRD 时的默认突发上限值（默认 100，-1 表示禁用）                           |\n| $HELM_QPS                          | 设置当高频调用超出较高突发限制时的每秒查询数                                        |\n\nHelm 基于以下配置顺序存储缓存，配置和添加数据：\n\n- 如果设置了 HELM_*_HOME 环境变量，则使用该变量\n- 否则，在支持XDG基本目录规范的系统上，会使用XDG变量\n- 当没有设置其他位置时，将根据操作系统使用默认位置\n\n默认情况下，默认目录取决于操作系统，默认值如下：\n\n| 操作系统          | 缓存路径                  | 配置路径                        | 数据路径               |\n|------------------|---------------------------|--------------------------------|-------------------------|\n| Linux            | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm |\n| macOS            | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm      |\n| Windows          | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm          |\n\n### 可选项\n\n```shell\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n  -h, --help                            help for helm\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 另请参阅\n\n- [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本\n- [helm create](/helm/helm_create.md) - 使用给定的名称创建 chart\n- [helm dependency](/helm/helm_dependency.md) - 管理 chart 依赖\n- [helm env](/helm/helm_env.md) - Helm 客户端环境信息\n- [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息\n- [helm history](/helm/helm_history.md) - 获取 release 历史\n- [helm install](/helm/helm_install.md) - 安装 chart\n- [helm lint](/helm/helm_lint.md) - 验证 chart 是否存在问题\n- [helm list](/helm/helm_list.md) - 列出 release\n- [helm package](/helm/helm_package.md) - 将 chart 目录打包\n- [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件\n- [helm pull](/helm/helm_pull.md) - 从仓库下载 chart 并（可选）在本地目录中打开\n- [helm push](/helm/helm_push.md) - 推送 chart 到远程\n- [helm registry](/helm/helm_registry.md) - 登录或登出 registry\n- [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库\n- [helm rollback](/helm/helm_rollback.md) - 将 release 回滚到上一个版本\n- [helm search](/helm/helm_search.md) - 在 chart 中搜索关键字\n- [helm show](/helm/helm_show.md) - 显示 chart 信息\n- [helm status](/helm/helm_status.md) - 显示指定 release 的状态\n- [helm template](/helm/helm_template.md) - 本地渲染模板\n- [helm test](/helm/helm_test.md) - 运行 release 的测试\n- [helm uninstall](/helm/helm_uninstall.md) - 卸载 release\n- [helm upgrade](/helm/helm_upgrade.md) - 升级 release\n- [helm verify](/helm/helm_verify.md) - 验证给定路径的 chart 已经被签名且是合法的\n- [helm version](/helm/helm_version.md) - 打印客户端版本信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\n为指定的 shell 生成自动补全脚本\n\n### 简介\n\n为 Helm 生成针对指定 shell 的自动补全脚本。\n\n### 可选项\n\n```shell\n  -h, --help   completion 命令帮助\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器\n* [helm completion bash](/helm/helm_completion_bash.md) - 为 bash 生成自动补全脚本\n* [helm completion fish](/helm/helm_completion_fish.md) - 为 fish 生成自动补全脚本\n* [helm completion powershell](/helm/helm_completion_powershell.md) - 为 powershell 生成自动补全脚本\n* [helm completion zsh](/helm/helm_completion_zsh.md) - 为 zsh 生成自动补全脚本\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\n为 bash 生成自动补全脚本\n\n### 简介\n\n为 Helm 生成针对 bash shell 的自动补全脚本。\n\n在当前 shell 会话中加载自动补全：\n\n    source <(helm completion bash)\n\n为每个新的会话加载自动补全，执行一次：\n\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n```shell\nhelm completion bash [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help              bash 命令帮助\n      --no-descriptions   禁用补全描述\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\n为 fish 生成自动补全脚本\n\n### 简介\n\n为 Helm 生成针对 fish shell 的自动补全脚本。\n\n在当前 shell 会话中加载自动补全：\n\n    helm completion fish | source\n\n为每个新的会话加载自动补全，执行一次：\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\n你需要启动一个新的 shell 使其生效。\n\n```\nhelm completion fish [flags]\n```\n\n### 可选项\n\n```\n  -h, --help              fish 命令帮助\n      --no-descriptions   禁用补全描述\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\n为 powershell 生成自动补全脚本\n\n### 简介\n\n为 powershell 生成自动补全脚本。\n\n在当前 shell 会话中加载补全项：\n\n    PS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\n为每个新会话加载补全项，将上述命令的输出添加到你的 powershell profile 中。\n\n```shell\nhelm completion powershell [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help              powershell 命令帮助\n      --no-descriptions   禁用补全描述\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\n为 zsh 生成自动补全脚本\n\n### 简介\n\n为 Helm 生成针对 zsh shell 的自动补全脚本。\n\n在当前 shell 会话中加载自动补全：\n\n    source <(helm completion zsh)\n\n为每个新的会话加载自动补全，执行一次：\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n```shell\nhelm completion zsh [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help              zsh 命令帮助\n      --no-descriptions   禁用补全描述\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n\n使用给定名称创建新的 chart\n\n### 简介\n\n该命令创建 chart 目录和 chart 中常用的文件及目录。\n\n例如，`helm create foo` 会创建如下目录结构：\n\n```\nfoo/\n├── .helmignore   # 打包 Helm chart 时要忽略的文件模式\n├── Chart.yaml    # chart 的信息\n├── values.yaml   # 模板的默认值\n├── charts/       # 该 chart 依赖的 chart\n└── templates/    # 模板文件\n    └── tests/    # 测试文件\n```\n\n`helm create` 使用路径作为参数。如果给定路径中的目录不存在，Helm 会自动创建。如果给定目录已存在且其中有文件，冲突文件会被覆盖，其他文件保持不变。\n\n```shell\nhelm create NAME [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help             create 命令帮助\n  -p, --starter string   Helm starter scaffold 的名称或绝对路径\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_delete.md",
    "content": "---\nsection: 弃用\ntitle: helm delete\n---\n该命令被重命名。 请参考[helm uninstall](/helm/helm_uninstall.md).\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\n管理 chart 依赖\n\n### 简介\n\n管理 chart 依赖。\n\nHelm chart 将依赖存储在 'charts/' 目录中。对于 chart 开发者，在 'Chart.yaml' 中声明所有依赖通常更方便管理。\n\n依赖命令针对该文件进行操作，使得 'charts/' 目录中声明的依赖和实际存储的依赖之间轻松保持同步。\n\n例如，以下 Chart.yaml 声明了两个依赖：\n\n```yaml\n# Chart.yaml\ndependencies:\n- name: nginx\n  version: \"1.2.3\"\n  repository: \"https://example.com/charts\"\n- name: memcached\n  version: \"3.2.1\"\n  repository: \"https://another.example.com/charts\"\n```\n\n'name' 是 chart 名称，必须与该 chart 的 'Chart.yaml' 文件中的名称相匹配。\n\n'version' 字段应包含语义化版本号或版本范围。\n\n'repository' URL 应指向 Chart 仓库。Helm 会在 URL 后附加 '/index.yaml' 来获取 chart 仓库索引。注意：'repository' 可以是别名。别名必须以 'alias:' 或 '@' 开头。\n\n从 2.2.0 开始，仓库可以定义为本地存储的依赖 chart 的目录路径。路径需以 \"file://\" 开头，例如：\n\n```yaml\n# Chart.yaml\ndependencies:\n- name: nginx\n  version: \"1.2.3\"\n  repository: \"file://../dependency_chart/nginx\"\n```\n\n如果依赖 chart 从本地获取，则不需要通过 \"helm add repo\" 将仓库添加到 helm 中。此场景也支持版本匹配。\n\n### 可选项\n\n```shell\n  -h, --help   dependency 命令帮助\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n* [helm dependency build](/helm/helm_dependency_build.md) - 根据 Chart.lock 文件重新构建 charts/ 目录\n* [helm dependency list](/helm/helm_dependency_list.md) - 列出指定 chart 的依赖\n* [helm dependency update](/helm/helm_dependency_update.md) - 根据 Chart.yaml 内容更新 charts/ 目录\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\n基于 Chart.lock 文件重新构建 charts/ 目录\n\n### 简介\n\n从 Chart.lock 文件构建输出到 charts/ 目录。\n\n该命令用于将 chart 的依赖项重建为锁定文件中的指定状态。它不会像 'helm dependency update' 那样重新协商依赖。\n\n如果未找到锁定文件，'helm dependency build' 的行为将与 'helm dependency update' 相同。\n\n```shell\nhelm dependency build CHART [flags]\n```\n\n### 可选项\n\n```shell\n      --ca-file string             使用此 CA 证书包验证启用 HTTPS 的服务器证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n  -h, --help                       build 命令帮助\n      --insecure-skip-tls-verify   跳过 chart 下载时的 TLS 证书验证\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string             包含公钥的密钥环（默认 \"~/.gnupg/pubring.gpg\"）\n      --password string            chart 仓库密码，用于定位请求的 chart\n      --plain-http                 对 chart 下载使用不安全的 HTTP 连接\n      --skip-refresh               不刷新本地仓库缓存\n      --username string            chart 仓库用户名，用于定位请求的 chart\n      --verify                     对下载的包进行签名验证\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm dependency](/helm/helm_dependency.md) - 管理 chart 依赖\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\n列举指定 chart 的依赖\n\n### 简介\n\n列举 chart 中声明的所有依赖。\n\n此命令可以将 chart 包或 chart 目录作为输入，不会修改 chart 的内容。\n\n如果 chart 无法加载，会产生错误。\n\n```shell\nhelm dependency list CHART [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help                 list 命令帮助\n      --max-col-width uint   输出表格的最大列宽（默认 80）\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm dependency](/helm/helm_dependency.md) - 管理 chart 依赖\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\n根据 Chart.yaml 更新 charts/ 目录\n\n### 简介\n\n将磁盘上的依赖更新为 Chart.yaml 指定的状态。\n\n此命令验证 'Chart.yaml' 中指定的所需 chart 是否存在于 'charts/' 目录中且版本满足要求。它会拉取满足依赖的最新 chart，并清理旧依赖。\n\n成功更新后，会生成一个锁定文件，可用于将依赖重新构建到精确版本。\n\n依赖不一定需要在 'Chart.yaml' 中声明。因此，更新命令不会删除 chart，除非该 chart 在 Chart.yaml 中声明但版本不符。\n\n```shell\nhelm dependency update CHART [flags]\n```\n\n### 可选项\n\n```shell\n      --ca-file string             使用此 CA 证书包验证启用 HTTPS 的服务器证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n  -h, --help                       update 命令帮助\n      --insecure-skip-tls-verify   跳过 chart 下载时的 TLS 证书验证\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string             包含公钥的密钥环（默认 \"~/.gnupg/pubring.gpg\"）\n      --password string            chart 仓库密码，用于定位请求的 chart\n      --plain-http                 对 chart 下载使用不安全的 HTTP 连接\n      --skip-refresh               不刷新本地仓库缓存\n      --username string            chart 仓库用户名，用于定位请求的 chart\n      --verify                     对下载的包进行签名验证\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm dependency](/helm/helm_dependency.md) - 管理 chart 依赖\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\n显示 Helm 客户端的环境信息\n\n### 简介\n\n该命令打印 Helm 使用的所有环境信息。\n\n\n```\nhelm env [flags]\n```\n\n### 可选项\n\n```\n  -h, --help   env 的帮助信息\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\n下载指定 release 的扩展信息\n\n### 简介\n\n该命令由多个子命令组成，用于获取 release 的扩展信息，包括：\n\n- 用于生成该 release 的 values\n- 生成的清单文件\n- chart 提供的 NOTES\n- 与该 release 关联的 hook\n- 该 release 的元数据\n\n\n### 可选项\n\n```\n  -h, --help   get 的帮助信息\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n- [helm get all](/helm/helm_get_all.md) - 下载指定 release 的所有信息\n- [helm get hooks](/helm/helm_get_hooks.md) - 下载指定 release 的所有 hook\n- [helm get manifest](/helm/helm_get_manifest.md) - 下载指定 release 的清单\n- [helm get metadata](/helm/helm_get_metadata.md) - 获取指定 release 的元数据\n- [helm get notes](/helm/helm_get_notes.md) - 下载指定 release 的 NOTES\n- [helm get values](/helm/helm_get_values.md) - 下载指定 release 的 values 文件\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\n下载指定 release 的所有信息\n\n### 简介\n\n该命令打印指定 release 的可读信息集合，包括说明信息、hook、提供的 values 以及生成的清单文件。\n\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### 可选项\n\n```\n  -h, --help              all 的帮助信息\n      --revision int      获取指定 release 的某个修订版本\n      --template string   用于格式化输出的 Go 模板，例如：{{.Release.Name}}\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\n下载指定 release 的所有钩子\n\n### 简介\n\n该命令用于下载指定 release 的钩子。\n\n钩子被格式化为 YAML，并以 YAML 的 '---\\n' 分隔符分隔。\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### 可选项\n\n```\n  -h, --help           hooks 的帮助信息\n      --revision int   获取指定 release 的某个修订版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\n下载指定 release 的清单\n\n### 简介\n\n该命令用于获取指定 release 的生成清单。\n\n清单是由该 release 的 chart 生成的 Kubernetes 资源的 YAML 编码表示。如果 chart 依赖其他 chart，这些资源也会包含在清单中。\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### 可选项\n\n```\n  -h, --help           manifest 的帮助信息\n      --revision int   获取指定 release 的某个修订版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\n获取指定 release 的元数据\n\n### 简介\n\n该命令用于获取指定 release 的元数据信息。\n\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### 可选项\n\n```\n  -h, --help            metadata 的帮助信息\n  -o, --output format   以指定格式打印输出。允许的值：table、json、yaml（默认 table）\n      --revision int    指定 release 的修订版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\n下载指定 release 的说明信息\n\n### 简介\n\n该命令显示指定 release 的 chart 所提供的说明信息。\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### 可选项\n\n```\n  -h, --help           notes 的帮助信息\n      --revision int   获取指定 release 的某个修订版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\n下载指定 release 的 values 文件\n\n### 简介\n\n该命令下载指定 release 的 values 文件。\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### 可选项\n\n```\n  -a, --all             输出所有（计算后的）values\n  -h, --help            values 的帮助信息\n  -o, --output format   以指定格式打印输出。允许的值：table、json、yaml（默认 table）\n      --revision int    获取指定修订版本的 release\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\n检索 release 历史\n\n### 简介\n\n该命令打印指定 release 的历史修订记录。\n\n默认最多返回 256 个修订版本。设置 `--max` 可配置返回的修订列表最大长度。\n\n历史记录会以格式化表格形式打印，例如：\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### 可选项\n\n```\n  -h, --help            history 的帮助信息\n      --max int         包含在历史记录中的最大修订版本数（默认 256）\n  -o, --output format   以指定格式打印输出。允许的值：table、json、yaml（默认 table）\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_init.md",
    "content": "---\nsection: 弃用\ntitle: helm init\n---\n该命令不会出现在Helm 3中，遵循[移除的Tiller](https://helm.sh/zh/docs/faq/#移除了Tiller)。不再需要为使用helm而安装Tiller。\n\n如果您在使用Helm 2， 前往[v2.helm.sh](https://v2.helm.sh/docs/helm/#helm-init)\n查看[Helm初始化文档](https://v2.helm.sh/docs/helm/#helm-init)。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_inspect.md",
    "content": "---\nsection: 弃用\ntitle: helm inspect\n---\n该命令已被重命名，请参考[helm show](/helm/helm_show.md)。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\n安装 chart\n\n### 简介\n\n该命令用于安装 chart 包。\n\n安装参数必须是 chart 的引用，一个打包后的 chart 路径，未打包的 chart 目录或者是一个 URL。\n\n要重写 chart 中的值，使用 '--values' 参数传递一个文件或者使用 '--set' 参数在命令行传递配置，强制使用字符串要用 '--set-string'。当值本身对于命令行太长或者是动态生成的时候，可以使用 '--set-file' 设置独立的值。也可以在命令行使用 '--set-json' 参数设置 JSON 值（标量/对象/数组）。\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\n或者\n\n    $ helm install --set name=prod myredis ./redis\n\n或者\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\n或者\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\n或者\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\n你可以多次指定 '--values'/'-f' 参数。最右侧指定的文件优先级最高。比如，如果两个文件 myvalues.yaml 和 override.yaml 都包含名为 'Test' 的键，override.yaml 中的值优先：\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\n可以多次指定 '--set' 参数，最右边的参数优先级最高。比如，'bar' 和 'newbar' 都设置了一个名为 'foo' 的键，'newbar' 的值优先：\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\n类似地，下面的示例中 'foo' 被设置成了 '[\"four\"]'：\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\n下面的示例中，'foo' 被设置成了 '{\"key1\":\"value1\",\"key2\":\"bar\"}'：\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\n为了检测生成的清单，但并不安装 chart，可以将 '--debug' 和 '--dry-run' 组合使用。\n\n'--dry-run' 参数会输出所有生成的 chart 清单，包括可能包含敏感值的 Secret。如需隐藏 Kubernetes Secret，请使用 '--hide-secret' 参数。请谨慎考虑何时及如何使用这些参数。\n\n如果设置了 '--verify'，chart **必须**有出处文件，且出处文件**必须**通过所有的验证步骤。\n\n有六种不同的方式来标识需要安装的 chart：\n\n1. 通过 chart 引用：helm install mymaria example/mariadb\n2. 通过 chart 包路径：helm install mynginx ./nginx-1.2.3.tgz\n3. 通过未打包 chart 目录的路径：helm install mynginx ./nginx\n4. 通过 URL 绝对路径：helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. 通过 chart 引用和仓库 URL：helm install --repo https://example.com/charts/ mynginx nginx\n6. 通过 OCI 注册中心：helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\nCHART 引用\n\nchart 引用是在 chart 仓库中引用 chart 的一种方便方式。\n\n当你用仓库前缀（'example/mariadb'）引用 chart 时，Helm 会在本地配置查找名为 'example' 的 chart 仓库，然后会在仓库中查找名为 'mariadb' 的 chart，然后会安装这个 chart 最新的稳定版本，除非指定了 '--devel' 参数且包含了开发版本（alpha、beta 和候选发布版本），或者使用 '--version' 参数提供一个版本号。\n\n要查看仓库列表，使用 'helm repo list'。要在仓库中搜索 chart，使用 'helm search'。\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### 可选项\n\n```\n      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for install\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 请参阅\n\n* [helm](./helm.md)\t - Kubernetes 的 Helm 包管理器\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\n检查 chart 是否存在问题\n\n### 简介\n\n该命令使用一个 chart 路径并运行一系列测试来验证 chart 的格式是否正确。\n\n如果 linter 遇到会导致 chart 安装失败的情况，会输出 [ERROR] 信息。如果遇到违反惯例或建议的问题，会输出 [WARNING] 信息。\n\n\n```\nhelm lint PATH [flags]\n```\n\n### 可选项\n\n```\n  -h, --help                      lint 的帮助信息\n      --kube-version string       用于能力检测和弃用检查的 Kubernetes 版本\n      --quiet                     仅打印警告和错误\n      --set stringArray           在命令行上设置值（可以指定多个或用逗号分隔值：key1=val1,key2=val2）\n      --set-file stringArray      通过命令行从相应文件设置值（可以指定多个或用逗号分隔值：key1=path1,key2=path2）\n      --set-json stringArray      在命令行上设置 JSON 值（可以指定多个或用逗号分隔值：key1=jsonval1,key2=jsonval2）\n      --set-literal stringArray   在命令行上设置字面 STRING 值\n      --set-string stringArray    在命令行上设置 STRING 值（可以指定多个或用逗号分隔值：key1=val1,key2=val2）\n      --skip-schema-validation    如果设置，禁用 JSON schema 验证\n      --strict                    将 lint 警告视为失败\n  -f, --values strings            指定 YAML 文件或 URL 中的值（可以指定多个）\n      --with-subcharts            对依赖的 chart 进行 lint\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\n列举 release\n\n### 简介\n\n该命令列举指定 namespace 的所有 release（如果未指定 namespace，则使用当前 namespace 上下文）。\n\n默认情况下，只列举已部署或失败的 release。使用 `--uninstalled` 和 `--all` 等参数可以更改此行为。这些参数可以组合使用：`--uninstalled --failed`。\n\n默认情况下，列表按字母顺序排序。使用 `-d` 参数按发布日期排序。\n\n如果使用 `--filter` 参数，它将被作为过滤器使用。过滤器是应用于 release 列表的正则表达式（Perl 兼容）。只有匹配过滤器的项目会被返回。\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\n如果未找到结果，`helm list` 将返回退出码 0，但没有输出（或者在没有使用 `-q` 参数的情况下，只显示表头）。\n\n默认情况下，最多返回 256 项。使用 `--max` 参数限制数量。将 `--max` 设置为 0 不会返回所有结果，而是返回服务器默认值，可能比 256 更多。配合使用 `--max` 和 `--offset` 参数可以翻页显示结果。\n\n\n```\nhelm list [flags]\n```\n\n### 可选项\n\n```\n  -a, --all                  显示所有 release，不应用任何过滤器\n  -A, --all-namespaces       列举所有 namespace 中的 release\n  -d, --date                 按发布日期排序\n      --deployed             显示已部署的 release。如果未指定其他参数，此选项会自动启用\n      --failed               显示失败的 release\n  -f, --filter string        正则表达式（Perl 兼容）。匹配该表达式的 release 将包含在结果中\n  -h, --help                 list 的帮助信息\n  -m, --max int              获取的最大 release 数量（默认 256）\n      --no-headers           使用默认输出格式时不打印表头\n      --offset int           列表中下一个 release 的索引，用于从起始值偏移\n  -o, --output format        以指定格式打印输出。允许的值：table、json、yaml（默认 table）\n      --pending              显示待处理的 release\n  -r, --reverse              反转排序顺序\n  -l, --selector string      用于过滤的选择器（标签查询），支持 '='、'==' 和 '!='（例如 -l key1=value1,key2=value2）。仅适用于 secret（默认）和 configmap 存储后端\n  -q, --short                输出简短（静默）列表格式\n      --superseded           显示已被取代的 release\n      --time-format string   使用 golang 时间格式化程序格式化时间。示例：--time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          显示已卸载的 release（如果使用了 'helm uninstall --keep-history'）\n      --uninstalling         显示正在卸载中的 release\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\n将 chart 目录打包成 chart 归档文件\n\n### 简介\n\n该命令将 chart 打包成一个版本化的 chart 归档文件。如果给定路径，将会在该路径中查找 chart（必须包含 Chart.yaml 文件）然后将该目录打包。\n\n版本化的 chart 归档文件用于 Helm 包仓库。\n\n要签名一个 chart，使用 `--sign` 参数。在大多数场景中，还需要提供 `--keyring path/to/secret/keys` 和 `--key keyname`。\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\n如果未指定 `--keyring`，除非环境有其他配置，否则 Helm 通常会使用公共密钥环。\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### 可选项\n\n```\n      --app-version string         设置 chart 的 appVersion 为此版本\n      --ca-file string             使用此 CA 证书包验证启用 HTTPS 的服务器证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n  -u, --dependency-update          打包前从 \"Chart.yaml\" 更新依赖到 \"charts/\" 目录\n  -d, --destination string         chart 写入位置（默认 \".\"）\n  -h, --help                       package 命令帮助\n      --insecure-skip-tls-verify   跳过 chart 下载时的 TLS 证书检查\n      --key string                 签名时使用的密钥名称，在 --sign 为 true 时使用\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string             公共密钥环位置（默认 \"~/.gnupg/pubring.gpg\"）\n      --passphrase-file string     包含签名密钥密码短语的文件位置，使用 \"-\" 从标准输入读取\n      --password string            定位所请求 chart 的仓库密码\n      --plain-http                 chart 下载时使用不安全的 HTTP 连接\n      --sign                       使用 PGP 私钥签名此包\n      --username string            定位所请求 chart 的仓库用户名\n      --version string             设置 chart 的版本为此 semver 版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\n安装、列举或卸载 Helm 插件\n\n### 简介\n\n管理客户端 Helm 插件。\n\n### 可选项\n\n```shell\n  -h, --help   plugin 命令帮助\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n* [helm plugin install](/helm/helm_plugin_install.md) - 安装一个或多个 Helm 插件\n* [helm plugin list](/helm/helm_plugin_list.md) - 列举已安装的 Helm 插件\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - 卸载一个或多个 Helm 插件\n* [helm plugin update](/helm/helm_plugin_update.md) - 升级一个或多个 Helm 插件\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\n安装 Helm 插件\n\n### 简介\n\n该命令允许您从 VCS 仓库 URL 或本地路径安装插件。\n\n```shell\nhelm plugin install [options] <path|url> [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help             install 命令帮助\n      --version string   指定版本约束。如果未指定，将安装最新版本\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\n列举已安装的 Helm 插件\n\n```shell\nhelm plugin list [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help   list 命令帮助\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\n卸载一个或多个 Helm 插件\n\n```shell\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help   uninstall 命令帮助\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\n升级一个或多个 Helm 插件\n\n```shell\nhelm plugin update <plugin>... [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help   update 命令帮助\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\n从仓库下载 chart 并（可选）在本地目录解压\n\n### 简介\n\n从包仓库中检索包并下载到本地。\n\n此命令用于获取包以便检查、修改或重新打包。还可以用于在不安装 chart 的情况下对 chart 进行加密验证。\n\n下载 chart 后有解压选项，会为 chart 创建一个目录并解压到该目录中。\n\n如果指定了 `--verify` 参数，请求的 chart 必须有出处文件，且必须通过验证。任意部分的失败都会导致错误，且 chart 不会在本地保存。\n\n```shell\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### 可选项\n\n```shell\n      --ca-file string             使用此 CA 证书包验证启用 HTTPS 的服务器证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n  -d, --destination string         chart 写入位置。如果同时指定了 untardir，则 untardir 会附加到此路径（默认 \".\"）\n      --devel                      同时使用开发版本。等价于版本 '>0.0.0-0'。如果设置了 --version，则忽略此参数\n  -h, --help                       pull 命令帮助\n      --insecure-skip-tls-verify   跳过 chart 下载时的 TLS 证书验证\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string             用于验证的公钥位置（默认 \"~/.gnupg/pubring.gpg\"）\n      --pass-credentials           将凭据传递给所有域\n      --password string            chart 仓库密码\n      --plain-http                 对 chart 下载使用不安全的 HTTP 连接\n      --prov                       获取出处文件，但不执行验证\n      --repo string                chart 仓库 URL\n      --untar                      如果设置为 true，下载后解压 chart\n      --untardir string            如果指定了 untar，此参数指定 chart 解压到的目录名称（默认 \".\"）\n      --username string            chart 仓库用户名\n      --verify                     使用前验证包\n      --version string             指定 chart 版本约束。可以是特定标签（如 1.1.1）或有效范围（如 ^2.0.0）。如果未指定，使用最新版本\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器。\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\n将 chart 推送到远程\n\n### 简介\n\n上传 chart 到注册表。\n\n如果 chart 有关联的出处文件（provenance file），也会一起上传。\n\n```shell\nhelm push [chart] [remote] [flags]\n```\n\n### 可选项\n\n```shell\n      --ca-file string             使用此 CA 证书包验证启用 HTTPS 的服务器证书\n      --cert-file string           使用此 SSL 证书文件标识 registry 客户端\n  -h, --help                       push 命令帮助\n      --insecure-skip-tls-verify   跳过 chart 上传时的 TLS 证书验证\n      --key-file string            使用此 SSL 密钥文件标识 registry 客户端\n      --password string            chart 仓库密码\n      --plain-http                 对 chart 上传使用不安全的 HTTP 连接\n      --username string            chart 仓库用户名\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的用户组，可重复使用此参数指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接使用的证书颁发机构文件\n      --kube-context string             使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名\n      --kube-token string               用于身份验证的 bearer 令牌\n      --kubeconfig string               kubeconfig 文件路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求\n      --registry-config string          registry 配置文件路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器。\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n登录或登出注册表\n\n### 简介\n\n该命令由多个子命令组成，用于与注册表交互。\n\n### 可选项\n\n\n```\n  -h, --help   registry 的帮助信息\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n* [helm registry login](/helm/helm_registry_login.md) - 登录注册表\n* [helm registry logout](/helm/helm_registry_logout.md) - 登出注册表\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\n登录注册表\n\n### 简介\n\n向远程注册表进行身份验证。\n\n```\nhelm registry login [host] [flags]\n```\n\n### 可选项\n\n```\n      --ca-file string     使用此 CA 包验证启用 HTTPS 的服务器的证书\n      --cert-file string   使用此 SSL 证书文件标识注册表客户端\n  -h, --help               login 的帮助信息\n      --insecure           允许在没有证书的情况下连接 TLS 注册表\n      --key-file string    使用此 SSL 密钥文件标识注册表客户端\n  -p, --password string    注册表密码或身份令牌\n      --password-stdin     从标准输入读取密码或身份令牌\n      --plain-http         对 chart 上传使用不安全的 HTTP 连接\n  -u, --username string    注册表用户名\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm registry](/helm/helm_registry.md) - 登录或登出注册表\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n从注册表登出\n\n### 简介\n\n从远程注册表移除认证信息。\n\n```shell\nhelm registry logout [host] [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help   help for logout\n```\n\n### 从父命令继承的可选项\n\n```shell\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 请参阅\n\n* [helm registry](/helm/helm_registry.md) - 登录或登出注册表\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\n添加、列出、删除、更新和索引 chart 仓库\n\n### 简介\n\n该命令包含多个子命令，用于与 chart 仓库交互。\n\n可用于添加、删除、列举和索引 chart 仓库。\n\n### 可选项\n\n```\n  -h, --help   repo 的帮助信息\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n* [helm repo add](/helm/helm_repo_add.md) - 添加 chart 仓库\n* [helm repo index](/helm/helm_repo_index.md) - 基于包含打包 chart 的目录，生成索引文件\n* [helm repo list](/helm/helm_repo_list.md) - 列举 chart 仓库\n* [helm repo remove](/helm/helm_repo_remove.md) - 删除一个或多个仓库\n* [helm repo update](/helm/helm_repo_update.md) - 从 chart 仓库中更新本地可用 chart 的信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\n添加 chart 仓库\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### 可选项\n\n```\n      --allow-deprecated-repos     默认情况下，此命令不允许添加已被永久删除的官方仓库。此选项可禁用该行为\n      --ca-file string             使用此 CA 包验证启用 HTTPS 的服务器的证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n      --force-update               如果仓库已存在则替换（覆盖）\n  -h, --help                       add 的帮助信息\n      --insecure-skip-tls-verify   跳过仓库的 TLS 证书检查\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --no-update                  已忽略。以前用于禁用强制更新，现已被 force-update 取代\n      --pass-credentials           将凭据传递给所有域\n      --password string            chart 仓库密码\n      --password-stdin             从标准输入读取 chart 仓库密码\n      --timeout duration           等待索引文件下载完成的时间（默认 2m0s）\n      --username string            chart 仓库用户名\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\n基于包含打包 chart 的目录生成索引文件\n\n### 简介\n\n读取当前目录，根据找到的 chart 生成索引文件，并将结果写入当前目录下的 'index.yaml' 文件。\n\n这个工具用于为 chart 仓库创建 'index.yaml' 文件。使用 `--url` 参数可设置 chart 的绝对 URL。\n\n要将生成的索引与已有索引文件合并，使用 `--merge` 参数。此时，当前目录中找到的 chart 会合并到 `--merge` 指定的索引文件中，本地 chart 优先于已有 chart。\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### 可选项\n\n```\n  -h, --help           index 的帮助信息\n      --json           以 JSON 格式输出\n      --merge string   将生成的索引合并到指定的索引文件\n      --url string     chart 仓库的 URL\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\n列举 chart 仓库\n\n```\nhelm repo list [flags]\n```\n\n### 可选项\n\n```\n  -h, --help            list 的帮助信息\n  -o, --output format   以指定格式打印输出。允许的值：table、json、yaml（默认 table）\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\n删除一个或多个 chart 仓库\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### 可选项\n\n```\n  -h, --help   remove 的帮助信息\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\n从 chart 仓库中更新本地可用 chart 的信息\n\n### 简介\n\n此命令从各个 chart 仓库获取 chart 的最新信息。信息会缓存在本地，供 `helm search` 等命令使用。\n\n你可以指定需要更新的仓库列表。\n\n    $ helm repo update <repo_name> ...\n\n使用 `helm repo update` 更新所有仓库。\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### 可选项\n\n```\n      --fail-on-repo-update-fail   任一仓库更新失败则整体失败\n  -h, --help                       update 的帮助信息\n      --timeout duration           等待索引文件下载完成的时间（默认 2m0s）\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\n将 release 回滚到之前的修订版本\n\n### 简介\n\n该命令将 release 回滚到之前的修订版本。\n\n回滚命令的第一个参数是 release 的名称，第二个参数是修订（版本）号。如果省略此参数或设置为 0，将回滚到上一个修订版本。\n\n要查看修订号，运行 'helm history RELEASE'。\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### 可选项\n\n```\n      --cleanup-on-fail    允许在回滚失败时删除此次回滚中创建的新资源\n      --dry-run            模拟回滚\n      --force              如有需要，通过删除/重建策略强制更新资源\n  -h, --help               rollback 的帮助信息\n      --history-max int    限制每个 release 保存的最大修订版本数。使用 0 表示无限制（默认 10）\n      --no-hooks           阻止回滚期间运行钩子\n      --recreate-pods      如果适用，对资源执行 Pod 重启\n      --timeout duration   等待任何单个 Kubernetes 操作的时间（如钩子的 Jobs）（默认 5m0s）\n      --wait               如果设置，将等待所有 Pod、PVC、Service 以及 Deployment、StatefulSet 或 ReplicaSet 的最小 Pod 数处于就绪状态后才将 release 标记为成功。等待时间与 --timeout 一致\n      --wait-for-jobs      如果设置且启用了 --wait，将等待所有 Job 完成后才将 release 标记为成功。等待时间与 --timeout 一致\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发流量\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存的仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\n使用关键字搜索 chart\n\n### 简介\n\n该命令可以在多个位置搜索 Helm chart，包括 Artifact Hub 和你已添加的仓库。可以使用搜索子命令在不同位置搜索 chart。\n\n### 可选项\n\n```\n  -h, --help   search 的帮助信息\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含已缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n* [helm search hub](/helm/helm_search_hub.md) - 在 Artifact Hub 或你自己的 hub 实例中搜索 chart\n* [helm search repo](/helm/helm_search_repo.md) - 使用关键字搜索仓库中的 chart\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\n在 Artifact Hub 或自定义 hub 实例中搜索 chart\n\n### 简介\n\n在 Artifact Hub 或自定义 hub 实例中搜索 Helm chart。\n\nArtifact Hub 是一个基于 Web 的应用，支持查找、安装和发布 CNCF 项目的包和配置，包括公开发布的 Helm chart。它是 CNCF 的沙盒项目。可以访问 https://artifacthub.io/ 浏览。\n\n[KEYWORD] 参数接受关键字字符串或带引号的富查询字符串。富查询选项的文档，请参阅\nhttps://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n\n之前的 Helm 版本使用 Monocular 实例作为默认 `endpoint`，因此为了向后兼容，Artifact Hub 兼容 Monocular 搜索 API。类似地，设置 `endpoint` 参数时，指定的 endpoint 也必须实现兼容 Monocular 的搜索 API。\n注意，指定 Monocular 实例作为 `endpoint` 时，不支持富查询。更多 API 细节，请参阅 https://github.com/helm/monocular\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### 可选项\n\n```\n      --endpoint string      要查询 chart 的 hub 实例（默认 \"https://hub.helm.sh\"）\n      --fail-on-no-result    如果没有搜索结果则返回失败\n  -h, --help                 hub 的帮助信息\n      --list-repo-url        输出 chart 仓库的 URL\n      --max-col-width uint   输出表格的最大列宽（默认 50）\n  -o, --output format        以指定格式输出。允许的值：table、json、yaml（默认 table）\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm search](/helm/helm_search.md) - 在 chart 中搜索关键字\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\n使用关键字搜索仓库中的 chart\n\n### 简介\n\n该命令会读取系统上配置的所有仓库，并查找匹配项。搜索基于系统中存储的仓库元数据。\n\n该命令会显示找到的 chart 的最新稳定版本。如果指定了 `--devel` 参数，输出会包含预发布版本。如果要使用版本约束进行搜索，请使用 `--version`。\n\n示例：\n\n    # 搜索与关键字 \"nginx\" 匹配的稳定发布版本\n    $ helm search repo nginx\n\n    # 搜索与关键字 \"nginx\" 匹配的发布版本，包括预发布版本\n    $ helm search repo nginx --devel\n\n    # 搜索 nginx-ingress 主版本号为 1 的最新稳定版本\n    $ helm search repo nginx-ingress --version ^1.0.0\n\n仓库使用 `helm repo` 命令管理。\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### 可选项\n\n```\n      --devel                同时使用开发版本（alpha、beta 和候选发布版本）。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项\n      --fail-on-no-result    如果没有搜索结果则返回失败\n  -h, --help                 repo 的帮助信息\n      --max-col-width uint   输出表格的最大列宽（默认 50）\n  -o, --output format        以指定格式输出。允许的值：table、json、yaml（默认 table）\n  -r, --regexp               使用正则表达式搜索已添加的仓库\n      --version string       在已添加的仓库中使用语义化版本约束进行搜索\n  -l, --versions             在已添加的仓库中显示详细列表，每个 chart 的每个版本单独一行\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm search](/helm/helm_search.md) - 在 chart 中搜索关键字\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\n显示 chart 信息\n\n### 简介\n\n此命令包含多个子命令，用于查看 chart 信息\n\n### 可选项\n\n```\n  -h, --help   show 的帮助信息\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器\n- [helm show all](/helm/helm_show_all.md) - 显示 chart 的所有信息\n- [helm show chart](/helm/helm_show_chart.md) - 显示 chart 的定义\n- [helm show crds](/helm/helm_show_crds.md) - 显示 chart 的 CRD\n- [helm show readme](/helm/helm_show_readme.md) - 显示 chart 的 README\n- [helm show values](/helm/helm_show_values.md) - 显示 chart 的 values\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\n显示 chart 的所有信息\n\n### 简介\n\n该命令检查 chart（目录、文件或 URL）并显示所有内容\n（values.yaml、Chart.yaml、README）\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### 可选项\n\n```\n      --ca-file string             使用此 CA 包验证启用 HTTPS 的服务器的证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n      --devel                      同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项\n  -h, --help                       all 的帮助信息\n      --insecure-skip-tls-verify   跳过 chart 下载的 TLS 证书检查\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string             用于验证的公钥位置（默认 \"~/.gnupg/pubring.gpg\"）\n      --pass-credentials           将凭据传递给所有域\n      --password string            chart 仓库密码\n      --plain-http                 对 chart 下载使用不安全的 HTTP 连接\n      --repo string                chart 仓库 URL\n      --username string            chart 仓库用户名\n      --verify                     使用前验证此包\n      --version string             指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm show](/helm/helm_show.md) - 显示 chart 信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\n显示 chart 的定义\n\n### 简介\n\n该命令检查 chart（目录、文件或 URL）并显示 Chart.yaml 文件的内容\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### 可选项\n\n```\n      --ca-file string             使用此 CA 包验证启用 HTTPS 的服务器的证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n      --devel                      同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项\n  -h, --help                       chart 的帮助信息\n      --insecure-skip-tls-verify   跳过 chart 下载的 TLS 证书检查\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string             用于验证的公钥位置（默认 \"~/.gnupg/pubring.gpg\"）\n      --pass-credentials           将凭据传递给所有域\n      --password string            chart 仓库密码\n      --plain-http                 对 chart 下载使用不安全的 HTTP 连接\n      --repo string                chart 仓库 URL\n      --username string            chart 仓库用户名\n      --verify                     使用前验证此包\n      --version string             指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm show](/helm/helm_show.md) - 显示 chart 信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\n显示 chart 的 CRD\n\n### 简介\n\n该命令检查 chart（目录、文件或 URL）并显示 CustomResourceDefinition 文件的内容\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### 可选项\n\n```\n      --ca-file string             使用此 CA 包验证启用 HTTPS 的服务器的证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n      --devel                      同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项\n  -h, --help                       crds 的帮助信息\n      --insecure-skip-tls-verify   跳过 chart 下载的 TLS 证书检查\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string             用于验证的公钥位置（默认 \"~/.gnupg/pubring.gpg\"）\n      --pass-credentials           将凭据传递给所有域\n      --password string            chart 仓库密码\n      --plain-http                 对 chart 下载使用不安全的 HTTP 连接\n      --repo string                chart 仓库 URL\n      --username string            chart 仓库用户名\n      --verify                     使用前验证此包\n      --version string             指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm show](/helm/helm_show.md) - 显示 chart 信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\n显示 chart 的 README\n\n### 简介\n\n该命令检查 chart（目录、文件或 URL）并显示 README 文件的内容\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### 可选项\n\n```\n      --ca-file string             使用此 CA 包验证启用 HTTPS 的服务器的证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n      --devel                      同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项\n  -h, --help                       readme 的帮助信息\n      --insecure-skip-tls-verify   跳过 chart 下载的 TLS 证书检查\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string             用于验证的公钥位置（默认 \"~/.gnupg/pubring.gpg\"）\n      --pass-credentials           将凭据传递给所有域\n      --password string            chart 仓库密码\n      --plain-http                 对 chart 下载使用不安全的 HTTP 连接\n      --repo string                chart 仓库 URL\n      --username string            chart 仓库用户名\n      --verify                     使用前验证此包\n      --version string             指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm show](/helm/helm_show.md) - 显示 chart 信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\n显示 chart 的 values\n\n### 简介\n\n该命令检查 chart（目录、文件或 URL）并显示 values.yaml 文件的内容\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### 可选项\n\n```\n      --ca-file string             使用此 CA 包验证启用 HTTPS 的服务器的证书\n      --cert-file string           使用此 SSL 证书文件标识 HTTPS 客户端\n      --devel                      同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项\n  -h, --help                       values 的帮助信息\n      --insecure-skip-tls-verify   跳过 chart 下载的 TLS 证书检查\n      --jsonpath string            提供 JSONPath 表达式来过滤输出\n      --key-file string            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string             用于验证的公钥位置（默认 \"~/.gnupg/pubring.gpg\"）\n      --pass-credentials           将凭据传递给所有域\n      --password string            chart 仓库密码\n      --plain-http                 对 chart 下载使用不安全的 HTTP 连接\n      --repo string                chart 仓库 URL\n      --username string            chart 仓库用户名\n      --verify                     使用前验证此包\n      --version string             指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       操作时模拟的组，此参数可重复指定多个组\n      --kube-as-user string             操作时模拟的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm show](/helm/helm_show.md) - 显示 chart 信息\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\n显示指定 release 的状态\n\n### 简介\n\n该命令显示指定 release 的状态。\n状态包括：\n- 最后部署时间\n- release 所在的 Kubernetes namespace\n- release 状态（可以是：unknown、deployed、uninstalled、superseded、failed、uninstalling、pending-install、pending-upgrade 或 pending-rollback）\n- release 的修订版本号\n- release 的描述（可以是完成信息或错误信息，需要启用 --show-desc）\n- release 包含的资源列表（需要启用 --show-resources）\n- 最后一次测试套件运行的详细信息（如适用）\n- chart 提供的附加说明\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### 可选项\n\n```\n  -h, --help             status 的帮助信息\n  -o, --output format    以指定格式打印输出。允许的值：table、json、yaml（默认 table）\n      --revision int     如果设置，显示指定 release 对应修订版本的状态\n      --show-desc        如果设置，显示指定 release 的描述信息\n      --show-resources   如果设置，显示指定 release 的资源\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\n本地渲染模板\n\n### 简介\n\n本地渲染 chart 模板并显示输出。\n\n通常在集群中查找或检索到的任何值都会在本地模拟。另外，不会执行任何服务端对 chart 的有效性验证（例如检查某个 API 是否支持）。\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### 可选项\n\n```\n  -a, --api-versions strings                       用于 Capabilities.APIVersions 的 Kubernetes api 版本\n      --atomic                                     如果设置，安装过程在失败时删除已安装的内容。使用 --atomic 时会自动设置 --wait 参数\n      --ca-file string                             使用此 CA 包验证启用 HTTPS 的服务器的证书\n      --cert-file string                           使用此 SSL 证书文件标识 HTTPS 客户端\n      --create-namespace                           如果 release namespace 不存在则创建\n      --dependency-update                          如果缺少依赖项，在安装 chart 之前更新依赖项\n      --description string                         添加自定义描述\n      --devel                                      同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项\n      --disable-openapi-validation                 如果设置，安装过程不会根据 Kubernetes OpenAPI Schema 验证渲染的模板\n      --dry-run string[=\"client\"]                  模拟安装。如果设置 --dry-run 时未指定选项或指定为 '--dry-run=client'，则不会尝试连接集群。设置 '--dry-run=server' 允许尝试连接集群。\n      --enable-dns                                 在渲染模板时启用 DNS 查询\n      --force                                      通过替换策略强制更新资源\n  -g, --generate-name                              生成名称（并省略 NAME 参数）\n  -h, --help                                       template 的帮助信息\n      --hide-notes                                 如果设置，不在安装输出中显示 notes。不影响 chart 元数据中的存在\n      --include-crds                               在模板输出中包含 CRD\n      --insecure-skip-tls-verify                   跳过 chart 下载的 TLS 证书检查\n      --is-upgrade                                 设置 .Release.IsUpgrade 而不是 .Release.IsInstall\n      --key-file string                            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string                             用于验证的公钥位置（默认 \"~/.gnupg/pubring.gpg\"）\n      --kube-version string                        用于 Capabilities.KubeVersion 的 Kubernetes 版本\n  -l, --labels stringToString                      将添加到 release 元数据的标签。应以逗号分隔。（默认 []）\n      --name-template string                       指定用于命名 release 的模板\n      --no-hooks                                   阻止在安装过程中运行 hook\n      --output-dir string                          将执行的模板写入 output-dir 中的文件，而不是 stdout\n      --pass-credentials                           将凭据传递给所有域\n      --password string                            chart 仓库密码\n      --plain-http                                 使用不安全的 HTTP 连接下载 chart\n      --post-renderer postRendererString           用于后渲染的可执行文件路径。如果存在于 $PATH 中，将使用该二进制文件，否则将尝试在给定路径查找可执行文件\n      --post-renderer-args postRendererArgsSlice   后渲染器的参数（可多次指定）（默认 []）\n      --release-name                               在 output-dir 路径中使用 release 名称\n      --render-subchart-notes                      如果设置，与父级一起渲染子 chart 的 notes\n      --replace                                    重复使用给定名称，仅当该名称是仍保留在历史记录中的已删除 release 时。这在生产环境中不安全\n      --repo string                                chart 仓库 URL\n      --set stringArray                            在命令行上设置值（可以多次指定或用逗号分隔值：key1=val1,key2=val2）\n      --set-file stringArray                       通过命令行从相应文件设置值（可以多次指定或用逗号分隔值：key1=path1,key2=path2）\n      --set-json stringArray                       在命令行上设置 JSON 值（可以多次指定或用逗号分隔值：key1=jsonval1,key2=jsonval2）\n      --set-literal stringArray                    在命令行上设置字面 STRING 值\n      --set-string stringArray                     在命令行上设置 STRING 值（可以多次指定或用逗号分隔值：key1=val1,key2=val2）\n  -s, --show-only stringArray                      仅显示从给定模板渲染的清单\n      --skip-crds                                  如果设置，不会安装 CRD。默认情况下，如果 CRD 不存在则会安装\n      --skip-schema-validation                     如果设置，禁用 JSON schema 验证\n      --skip-tests                                 从模板输出中跳过测试\n      --take-ownership                             如果设置，安装将忽略 helm 注解检查并接管现有资源的所有权\n      --timeout duration                           等待任何单个 Kubernetes 操作（如 hook 的 Job）的时间（默认 5m0s）\n      --username string                            chart 仓库用户名\n      --validate                                   根据当前指向的 Kubernetes 集群验证清单。这与安装时执行的验证相同\n  -f, --values strings                             在 YAML 文件或 URL 中指定值（可多次指定）\n      --verify                                     使用前验证包\n      --version string                             指定要使用的 chart 版本约束。可以是特定标签（如 1.1.1）或有效范围（如 ^2.0.0）。如果未指定，使用最新版本\n      --wait                                       如果设置，将等待所有 Pod、PVC、Service 以及 Deployment、StatefulSet 或 ReplicaSet 的最小 Pod 数处于就绪状态，然后才将 release 标记为成功。等待时间与 --timeout 相同\n      --wait-for-jobs                              如果设置且启用了 --wait，将等待所有 Job 完成后才将 release 标记为成功。等待时间与 --timeout 相同\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认节流限制（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，则不会验证 Kubernetes API 服务器的证书有效性。这将使 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](./helm.md) - Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\n执行 release 的测试\n\n### 简介\n\ntest 命令执行 release 的测试。\n\n该命令的参数是已部署 release 的名称。要运行的测试在已安装的 chart 中定义。\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### 可选项\n\n```\n      --filter strings     通过属性（当前为 \"name\"）使用 attribute=value 语法指定测试，或使用 '!attribute=value' 排除测试（可指定多个或用逗号分隔值：name=test1,name=test2）\n  -h, --help               test 的帮助信息\n      --hide-notes         如果设置，不在测试输出中显示 notes。不影响 chart 元数据中的存在\n      --logs               转储测试 Pod 的日志（在所有测试完成后、清理之前运行）\n      --timeout duration   等待任何单个 Kubernetes 操作的时间（如钩子的 Jobs）（默认 5m0s）\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\n卸载 release\n\n### 简介\n\n该命令使用 release 名称卸载 release。\n\n会删除与该 release 最后一次部署的 chart 相关的所有资源，以及发布历史，释放以供将来使用。\n\n使用 `--dry-run` 参数查看哪些 release 将被卸载，而不实际执行卸载操作。\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### 可选项\n\n```\n      --cascade string       必须是 \"background\"、\"orphan\" 或 \"foreground\"。选择依赖资源的级联删除策略。默认是 background。\n      --description string   添加自定义描述\n      --dry-run              模拟卸载\n  -h, --help                 uninstall 的帮助信息\n      --ignore-not-found     将 \"release not found\" 视为卸载成功\n      --keep-history         删除所有关联资源并将 release 标记为已删除，但保留发布历史\n      --no-hooks             卸载时禁止钩子运行\n      --timeout duration     等待任何单个 Kubernetes 操作的时间（如钩子的 Jobs）（默认 5m0s）\n      --wait                 如果设置，将等待所有资源删除后再返回。等待时间与 --timeout 一致\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的命名空间范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n* [helm](./helm.md) - Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\n升级 release 版本\n\n### 简介\n\n该命令将 release 升级到新版本的 chart。\n\n升级参数必须是 release 和 chart。chart 参数可以是：chart 引用（'example/mariadb'）、chart 目录路径、打包的 chart 或者完整的 URL。对于 chart 引用，除非使用 '--version' 参数指定，否则会使用最新版本。\n\n要覆盖 chart 中的 values，使用 '--values' 参数传递一个文件，或者使用 '--set' 参数从命令行传递配置，要强制使用字符串值，使用 '--set-string'。当值本身对于命令行太长或者是动态生成的时候，可以使用 '--set-file' 设置单独的值。也可以在命令行使用 '--set-json' 参数设置 JSON 值（scalars/objects/arrays）。\n\n可以多次指定 '--values'/'-f' 参数。最后（最右边）指定的文件优先级最高。例如，如果 myvalues.yaml 和 override.yaml 同时包含了名为 'Test' 的 key，override.yaml 中的值会优先使用：\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\n可以多次指定 '--set' 参数。最后（最右边）指定的优先级最高。例如，如果 'bar' 和 'newbar' 都设置了名为 'foo' 的 key，'newbar' 的值会优先使用：\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\n你也可以使用此命令通过 '--reuse-values' 参数更新现有 release 的 values。'RELEASE' 和 'CHART' 参数应设置为原始参数，现有的 values 会与通过 '--values'/'-f' 或 '--set' 参数设置的任何值合并。新值优先。\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\n--dry-run 参数会输出所有生成的 chart 清单，包括可能包含敏感值的 Secret。要隐藏 Kubernetes Secret，请使用 --hide-secret 参数。请仔细考虑如何以及何时使用这些参数。\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### 可选项\n\n```\n      --atomic                                     如果设置，升级过程在失败时回滚所做的更改。使用 --atomic 时会自动设置 --wait 参数\n      --ca-file string                             使用此 CA 包验证启用 HTTPS 的服务器的证书\n      --cert-file string                           使用此 SSL 证书文件标识 HTTPS 客户端\n      --cleanup-on-fail                            允许在升级失败时删除此次升级中创建的新资源\n      --create-namespace                           如果设置了 --install，当 release namespace 不存在时创建它\n      --dependency-update                          如果缺少依赖项，在安装 chart 之前更新依赖项\n      --description string                         添加自定义描述\n      --devel                                      同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项\n      --disable-openapi-validation                 如果设置，升级过程不会根据 Kubernetes OpenAPI Schema 验证渲染的模板\n      --dry-run string[=\"client\"]                  模拟升级。如果设置 --dry-run 时未指定选项或指定为 '--dry-run=client'，则不会尝试连接集群。设置 '--dry-run=server' 允许尝试连接集群。\n      --enable-dns                                 在渲染模板时启用 DNS 查询\n      --force                                      通过替换策略强制更新资源\n  -h, --help                                       upgrade 的帮助信息\n      --hide-notes                                 如果设置，不在升级输出中显示 notes。不影响 chart 元数据中的存在\n      --hide-secret                                同时使用 --dry-run 参数时隐藏 Kubernetes Secret\n      --history-max int                            限制每个 release 保存的最大修订版本数。使用 0 表示无限制（默认 10）\n      --insecure-skip-tls-verify                   跳过 chart 下载的 TLS 证书检查\n  -i, --install                                    如果不存在同名的 release，则运行安装\n      --key-file string                            使用此 SSL 密钥文件标识 HTTPS 客户端\n      --keyring string                             用于验证的公钥位置（默认 \"~/.gnupg/pubring.gpg\"）\n  -l, --labels stringToString                      将添加到 release 元数据的标签。应以逗号分隔。原始 release 标签将与升级标签合并。可以使用 null 取消标签设置。（默认 []）\n      --no-hooks                                   禁用升级前/后的钩子\n  -o, --output format                              以指定格式打印输出。允许的值：table、json、yaml（默认 table）\n      --pass-credentials                           将凭据传递给所有域\n      --password string                            chart 仓库密码\n      --plain-http                                 对 chart 下载使用不安全的 HTTP 连接\n      --post-renderer postRendererString           用于后渲染的可执行文件路径。如果它存在于 $PATH 中，将使用该二进制文件，否则将尝试在给定路径查找可执行文件\n      --post-renderer-args postRendererArgsSlice   传递给后渲染器的参数（可指定多个）（默认 []）\n      --render-subchart-notes                      如果设置，与父 chart 一起渲染子 chart 的 notes\n      --repo string                                chart 仓库 URL\n      --reset-then-reuse-values                    升级时，将 values 重置为 chart 内置的值，应用上一次 release 的值，并通过命令行的 --set 和 -f 合并任何覆盖值。如果指定了 '--reset-values' 或 '--reuse-values'，则忽略此项\n      --reset-values                               升级时，将 values 重置为 chart 内置的值\n      --reuse-values                               升级时，重用上一次 release 的 values，并通过命令行的 --set 和 -f 合并任何覆盖值。如果指定了 '--reset-values'，则忽略此项\n      --set stringArray                            在命令行设置 values（可以指定多个或用逗号分隔值：key1=val1,key2=val2）\n      --set-file stringArray                       通过命令行从相应文件设置 values（可以指定多个或用逗号分隔值：key1=path1,key2=path2）\n      --set-json stringArray                       在命令行设置 JSON values（可以指定多个或用逗号分隔值：key1=jsonval1,key2=jsonval2）\n      --set-literal stringArray                    在命令行设置字面 STRING 值\n      --set-string stringArray                     在命令行设置 STRING values（可以指定多个或用逗号分隔值：key1=val1,key2=val2）\n      --skip-crds                                  如果设置，当启用 install 参数执行升级时不会安装 CRD。默认情况下，当启用 install 参数执行升级时，如果 CRD 不存在则会安装\n      --skip-schema-validation                     如果设置，禁用 JSON schema 验证\n      --take-ownership                             如果设置，升级将忽略 helm 注解检查并接管现有资源的所有权\n      --timeout duration                           等待任何单个 Kubernetes 操作的时间（如钩子的 Jobs）（默认 5m0s）\n      --username string                            chart 仓库用户名\n  -f, --values strings                             在 YAML 文件或 URL 中指定 values（可指定多个）\n      --verify                                     使用前验证包\n      --version string                             指定要使用的 chart 版本约束。此约束可以是特定标签（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，则使用最新版本\n      --wait                                       如果设置，将等待所有 Pod、PVC、Service 以及 Deployment、StatefulSet 或 ReplicaSet 的最小 Pod 数处于就绪状态后才将 release 标记为成功。等待时间与 --timeout 一致\n      --wait-for-jobs                              如果设置且启用了 --wait，将等待所有 Job 完成后才将 release 标记为成功。等待时间与 --timeout 一致\n```\n\n### 从父命令继承的选项\n\n```\n      --burst-limit int                 客户端默认限流值（默认 100）\n      --debug                           启用详细输出\n      --kube-apiserver string           Kubernetes API 服务器的地址和端口\n      --kube-as-group stringArray       模拟操作的组，此参数可以重复指定多个组\n      --kube-as-user string             模拟操作的用户名\n      --kube-ca-file string             Kubernetes API 服务器连接的证书颁发机构文件\n      --kube-context string             要使用的 kubeconfig 上下文名称\n      --kube-insecure-skip-tls-verify   如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全\n      --kube-tls-server-name string     用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名\n      --kube-token string               用于身份验证的 bearer token\n      --kubeconfig string               kubeconfig 文件的路径\n  -n, --namespace string                此请求的 namespace 范围\n      --qps float32                     与 Kubernetes API 通信时使用的每秒查询数，不包括突发\n      --registry-config string          registry 配置文件的路径（默认 \"~/.config/helm/registry/config.json\"）\n      --repository-cache string         包含缓存仓库索引的目录路径（默认 \"~/.cache/helm/repository\"）\n      --repository-config string        包含仓库名称和 URL 的文件路径（默认 \"~/.config/helm/repositories.yaml\"）\n```\n\n### 请参阅\n\n- [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\n验证给定路径的 chart 已经被签名且有效\n\n### 简介\n\n验证指定的 chart 有合法的来源文件。\n\n来源文件提供了加密验证，保证 chart 未被篡改，且由可信提供商打包。\n\n该命令用于验证本地 chart，其他一些命令提供 `--verify` 参数执行同样的验证。要生成一个签名包，使用 `helm package --sign` 命令。\n\n```shell\nhelm verify PATH [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help             help for verify\n      --keyring string   keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n```\n\n### 从父命令继承的选项\n\n```shell\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 请参阅\n\n- [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n打印客户端版本信息\n\n### 简介\n\n显示Helm的版本。\n\n该命令会打印Helm的版本描述，输出如下：\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\",\nGitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version 是 release 的语义化版本。\n- GitCommit 是构建此版本时的提交 SHA。\n- 如果构建二进制包时没有本地代码修改，GitTreeState 为 \"clean\"；否则为 \"dirty\"。\n- GoVersion 是编译 Helm 所用的 Go 版本。\n\n当使用 `--template` 参数时，下列属性在模板中可用：\n\n- `.Version` 包含 Helm 的语义化版本\n- `.GitCommit` 是 git 提交哈希\n- `.GitTreeState` 是 Helm 构建时的 git 树状态\n- `.GoVersion` 包含编译 Helm 所用的 Go 版本\n\n例如，`--template='Version: {{.Version}}'` 输出 `Version: v3.2.1`。\n\n```shell\nhelm version [flags]\n```\n\n### 可选项\n\n```shell\n  -h, --help              help for version\n      --short             print the version number\n      --template string   template for version string format\n```\n\n### 从父命令继承的命令\n\n```shell\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### 请参阅\n\n- [helm](./helm.md) - Kubernetes 的 Helm 包管理器\n\n###### 由 spf13/cobra 于 2026-01-14 自动生成\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/helm/index.mdx",
    "content": "---\ntitle: Helm 命令行\ndescription: helm CLI 命令行的全部文档内容。\nsidebar_position: 6\nid: helm-category\n---\n\n# Helm 命令行\n\n这里可以看到 Helm 命令行列表和使用帮助。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: 使用 Chart Releaser Action 自动发布 GitHub Pages Chart\ndescription: 介绍如何使用 Chart Releaser Action 通过 GitHub Pages 自动发布 chart。\nsidebar_position: 3\n---\n\n本指南介绍如何使用 [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 工具。\n\n## 仓库配置\n\n在你的 GitHub 组织下创建一个 Git 仓库。可以将仓库命名为 `helm-charts`，当然其他名称也可以。所有 chart 的源代码都放在 `main` 分支，chart 应该位于根目录下的 `/charts` 目录中。\n\n还需要另一个名为 `gh-pages` 的分支来发布 chart。该分支的内容会由 Chart Releaser Action 自动创建和更新。你也可以手动创建 `gh-pages` 分支并添加 `README.md` 文件，该文件会对访问页面的用户可见。\n\n你可以在 `README.md` 中添加 chart 的安装说明，例如（将 `<alias>`、`<orgname>` 和 `<chart-name>` 替换为实际值）：\n\n```\n## Usage\n\n[Helm](https://helm.sh) must be installed to use the charts.  Please refer to\nHelm's [documentation](https://helm.sh/docs) to get started.\n\nOnce Helm has been set up correctly, add the repo as follows:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nIf you had already added this repo earlier, run `helm repo update` to retrieve\nthe latest versions of the packages.  You can then run `helm search repo\n<alias>` to see the charts.\n\nTo install the <chart-name> chart:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nTo uninstall the chart:\n\n    helm uninstall my-<chart-name>\n```\n\n发布后的 chart 会托管在如下 URL：\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions 工作流\n\n在 `main` 分支创建 GitHub Actions 工作流文件 `.github/workflows/release.yml`：\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\n上述配置使用 [@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 上。\n\n上述示例使用的 Chart Releaser Action 版本号是 `v1.6.0`。你可以将其更改为[最新可用版本](https://github.com/helm/chart-releaser-action/releases)。\n\n注意：Chart Releaser Action 几乎总是与 [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) 和 [Kind Action](https://github.com/marketplace/actions/kind-cluster) 配合使用。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: 同步你的 Chart 仓库\ndescription: 介绍如何同步本地和远程 chart 仓库。\nsidebar_position: 2\n---\n\n*注意：该示例演示如何使用 Google Cloud Storage (GCS) bucket 托管 chart 仓库。*\n\n## 先决条件\n\n* 安装 [gsutil](https://cloud.google.com/storage/docs/gsutil) 工具。*我们非常依赖 gsutil rsync 功能*\n* 确保可以使用 Helm\n* _可选：建议为 GCS bucket 启用[对象版本控制](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)，以防不小心删除了文件。_\n\n## 设置本地 chart 仓库目录\n\n参考 [chart 仓库指南](/zh/docs/topics/chart_repository)创建本地目录，并将打包好的 chart 放在该目录中。\n\n例如：\n\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## 生成更新的 index.yaml\n\n使用 Helm 生成更新的 index.yaml 文件，将目录路径和远程仓库 URL 传递给 `helm repo index` 命令：\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\n\n这会生成更新的 index.yaml 文件并放在 `fantastic-charts/` 目录中。\n\n## 同步本地和远程仓库\n\n运行 `scripts/sync-repo.sh` 脚本将目录内容上传到 GCS bucket，传入本地目录名和 bucket 名称作为参数。\n\n例如：\n\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n\n## 更新你的 chart 仓库\n\n保留 chart 仓库的本地副本，或使用 `gsutil rsync` 将远程内容同步到本地目录。\n\n例如：\n\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\n相关链接：\n\n* [gsutil rsync 文档](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [Chart 仓库指南](/zh/docs/topics/chart_repository)\n* Google Cloud Storage 的[对象版本控制和并发控制](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Chart 开发提示和技巧\ndescription: 介绍 Helm chart 开发者在构建生产级 chart 时积累的一些提示和技巧。\nsidebar_position: 1\n---\n\n本指南介绍 Helm chart 开发者在构建生产级 chart 时积累的一些提示和技巧。\n\n## 了解模板函数\n\nHelm 使用 [Go 模板](https://godoc.org/text/template) 来渲染资源文件。Go 自带了一些内置函数，我们还额外添加了许多其他函数。\n\n首先，我们添加了 [Sprig 库](https://masterminds.github.io/sprig/) 中的所有函数，出于安全原因，`env` 和 `expandenv` 除外。\n\n我们还添加了两个特殊的模板函数：`include` 和 `required`。`include` 函数允许你引入另一个模板，并将结果传递给其他模板函数。\n\n例如，以下模板片段引入了名为 `mytpl` 的模板，然后将结果转为小写，并用双引号括起来：\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\n`required` 函数允许你声明模板渲染所需的特定值。如果该值为空，模板渲染将失败并显示用户指定的错误信息。\n\n以下 `required` 函数示例声明 `.Values.who` 条目是必需的，如果缺少该条目将打印错误信息：\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## 字符串要加引号，整数不要\n\n处理字符串数据时，用引号括起来总是更安全：\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\n但处理整数时，_不要加引号_。这在很多情况下会导致 Kubernetes 解析错误。\n\n```yaml\nport: {{ .Values.Port }}\n```\n\n这条规则不适用于环境变量值——即使表示整数，环境变量也应该是字符串：\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## 使用 'include' 函数\n\nGo 提供了一种使用内置 `template` 指令在模板中包含另一个模板的方法。但是，内置函数无法在 Go 模板管道中使用。\n\n为了包含模板并处理其输出，Helm 提供了特殊的 `include` 函数：\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\n上面的代码引入了名为 `toYaml` 的模板，将 `$value` 传递给它，然后将该模板的输出传递给 `indent` 函数。\n\n由于 YAML 对缩进级别和空白敏感，这是一种很好的方式来包含代码片段，同时在相关上下文中处理缩进。\n\n## 使用 'required' 函数\n\nGo 提供了一种设置模板选项的方法，用于控制当使用不存在的键索引 map 时的行为。通常使用 `template.Options(\"missingkey=option\")` 来设置，其中 `option` 可以是 `default`、`zero` 或 `error`。虽然将此选项设置为 error 会在遇到缺失键时停止执行并报错，但这会应用于 map 中的每个缺失键。在某些情况下，chart 开发者可能希望对 `values.yaml` 文件中的特定值强制执行此行为。\n\n`required` 函数允许开发者声明模板渲染必需的值条目。如果该条目在 `values.yaml` 中为空，模板将不会渲染，并返回开发者指定的错误信息。\n\n例如：\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\n上面的代码在 `.Values.foo` 有定义时会正常渲染模板，但如果 `.Values.foo` 未定义则会渲染失败并退出。\n\n## 使用 'tpl' 函数\n\n`tpl` 函数允许开发者在模板内部将字符串作为模板进行求值。这在将模板字符串作为值传递给 chart 或渲染外部配置文件时非常有用。语法：`{{ tpl TEMPLATE_STRING VALUES }}`\n\n示例：\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\n渲染外部配置文件：\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## 创建镜像拉取 Secret\n\n镜像拉取 Secret 本质上是 _registry_、_username_ 和 _password_ 的组合。在部署应用时可能需要它，但创建时需要多次运行 `base64`。我们可以编写一个辅助模板来生成 Docker 配置文件，作为 Secret 的数据载荷。示例如下：\n\n首先，假设凭据在 `values.yaml` 文件中定义如下：\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\n然后定义辅助模板：\n\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\n最后，在更大的模板中使用辅助模板来创建 Secret 清单：\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## 自动滚动更新 Deployment\n\nConfigMap 或 Secret 经常作为配置文件注入容器，或者存在其他外部依赖变更需要滚动更新 Pod。根据应用的不同，如果这些内容在后续 `helm upgrade` 时更新了，可能需要重启应用。但如果 Deployment spec 本身没有变化，应用会继续使用旧配置运行，导致部署不一致。\n\n可以使用 `sha256sum` 函数确保当其他文件发生变化时，Deployment 的注解部分会被更新：\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\n注意：如果要将此添加到库 chart 中，你将无法使用 `$.Template.BasePath` 访问你的文件。作为替代，可以使用 `{{ include (\"mylibchart.configmap\") . | sha256sum }}` 引用你的定义。\n\n如果你希望始终触发 Deployment 滚动更新，可以使用类似的注解方式，但用随机字符串替换，这样每次都会变化并触发滚动更新：\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\n每次调用模板函数都会生成唯一的随机字符串。这意味着如果需要同步多个资源使用的随机字符串，所有相关资源都需要放在同一个模板文件中。\n\n这两种方法都允许你的 Deployment 利用内置的更新策略逻辑来避免停机。\n\n注意：过去我们推荐使用 `--recreate-pods` 参数作为另一种选择。该参数在 Helm 3 中已被标记为弃用，请使用上面更具声明性的方法。\n\n## 告诉 Helm 不要卸载资源\n\n有时某些资源在 Helm 执行 `helm uninstall` 时不应该被卸载。chart 开发者可以在资源上添加注解来防止其被卸载。\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\n注解 `helm.sh/resource-policy: keep` 指示 Helm 在执行会导致资源删除的操作（如 `helm uninstall`、`helm upgrade` 或 `helm rollback`）时跳过该资源。_但是_，该资源会变成孤立状态。Helm 将不再以任何方式管理它。如果在已卸载但保留了资源的 release 上使用 `helm install --replace`，可能会导致问题。\n\n## 使用 Partial 和模板引用\n\n有时你想在 chart 中创建一些可复用的部分，无论是代码块还是模板片段。通常，将这些内容放在单独的文件中会更清晰。\n\n在 `templates/` 目录中，任何以下划线（`_`）开头的文件都不会输出 Kubernetes 清单文件。因此按照惯例，辅助模板和 partial 会放在 `_helpers.tpl` 文件中。\n\n## 包含多个依赖的复杂 Chart\n\nCNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) 中的许多 chart 是创建更高级应用的\"构建块\"。但 chart 也可能用于创建大规模应用的实例。在这种情况下，一个总体 chart 可能有多个子 chart，每个子 chart 都是整体的一部分。\n\n目前从离散组件组合复杂应用的最佳实践是：创建一个顶层总体 chart 来暴露全局配置，然后使用 `charts/` 子目录来嵌入各个组件。\n\n## YAML 是 JSON 的超集\n\n根据 YAML 规范，YAML 是 JSON 的超集。这意味着任何有效的 JSON 结构在 YAML 中也应该是有效的。\n\n好处是：有时模板开发者可能发现使用类 JSON 语法来表达数据结构比处理 YAML 的空白敏感性更容易。\n\n作为最佳实践，模板应遵循类 YAML 语法，_除非_ JSON 语法能显著降低格式问题的风险。\n\n## 生成随机值时要小心\n\nHelm 中有一些函数允许你生成随机数据、加密密钥等。这些函数用起来很方便。但要注意，在升级过程中模板会重新执行。当模板运行生成的数据与上次运行不同时，会触发该资源的更新。\n\n## 一条命令安装或升级 Release\n\nHelm 提供了将安装或升级合并为单个命令的方式。使用 `helm upgrade` 加上 `--install` 参数。这会让 Helm 检查该 release 是否已安装。如果没有，则执行安装。如果已存在，则升级现有 release。\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/howto/index.mdx",
    "content": "---\ntitle: 如何使用\nsidebar_position: 2\n---\n\n# 使用指引\n\n这里您可以找到简单的“我如何做...”类型问题的简短答案。这些使用指引不能覆盖主题的深度，你可以在 [主题指引](/topics/index.mdx) 中获得更多内容。然而这些指引可以帮助您快速完成一般任务。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/index.mdx",
    "content": "---\ntitle: \"文档首页\"\ndescription: \"您需要知道的关于文档如何组织的所有内容。\"\n---\n\n# 欢迎\n\n欢迎使用 [Helm](https://helm.sh/zh/) 文档。 Helm 是 Kubernetes 的包管理器，您也可以在 [CNCF Helm 项目过程报告](https://www.cncf.io/cncf-helm-project-journey/)阅读详细的背景信息。\n\n# 文档构成\n\nHelm 有大量的文档。高级组织概述会让您知道在哪里查找特定内容。\n\n- [教程](/intro/index.mdx) 如果您是新手，从这里开始，手把手带您通过一系列的步骤创建您的第一个 Helm chart。\n- [主题引导](/topics/index.mdx) 以相当高的水平讨论关键主题和概念并提供有用的背景信息和解释。\n- [社区引导](/community) 讨论围绕社区的相关话题。如果您想了解更多关于 Helm 本身的开发过程以及如何参与开发，从这里开始。\n- [如何做](/howto/index.mdx) 操作方法。 指引您按照步骤参与定位关键问题和使用案例。假定您对 Helm 工作原理有所了解的情况下，这些内容会比教程更加高级。\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: 速查表\ndescription: Helm 速查表\nsidebar_position: 4\n---\n\nHelm 速查表包含了通过 Helm 管理应用所需的所有命令。\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### 基本概念说明\n\nChart：\n- 如果 chart 已被拉取并解压，则为 chart 目录名称。\n- 如果仓库已添加但 chart 未被拉取，则为 <repo_name>/<chart_name>。\n- 也可以是指向 chart 的 URL 或绝对路径。\n\nName：\n- 为本次 chart 安装指定的名称。\n\nRelease：\n- 分配给某次安装实例的名称。\n\nRevision：\n- Helm history 命令返回的版本号。\n\nRepo-name：\n- 仓库名称。\n\nDIR：\n- 目录名称或路径。\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Chart 管理\n\n```bash\nhelm create <name>                      # Creates a chart directory along with the common files and directories used in a chart.\nhelm package <chart-path>               # Packages a chart into a versioned chart archive file.\nhelm lint <chart>                       # Run tests to examine a chart and identify possible issues:\nhelm show all <chart>                   # Inspect a chart and list its contents:\nhelm show values <chart>                # Displays the contents of the values.yaml file\nhelm pull <chart>                       # Download/pull chart\nhelm pull <chart> --untar=true          # If set to true, will untar the chart after downloading it\nhelm pull <chart> --verify              # Verify the package before using it\nhelm pull <chart> --version <number>    # Default-latest is used, specify a version constraint for the chart version to use\nhelm dependency list <chart>            # Display a list of a chart's dependencies:\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### 安装和卸载应用\n\n```bash\nhelm install <name> <chart>                           # Install the chart with a name\nhelm install <name> <chart> --namespace <namespace>   # Install the chart in a specific namespace\nhelm install <name> <chart> --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas)\nhelm install <name> <chart> --values <yaml-file/url>  # Install the chart with your specified values\nhelm install <name> <chart> --dry-run --debug         # Run a test installation to validate chart (p)\nhelm install <name> <chart> --verify                  # Verify the package before using it\nhelm install <name> <chart> --dependency-update       # update dependencies if they are missing before installing the chart\nhelm uninstall <name>                                 # Uninstalls a release from the current (default) namespace\nhelm uninstall <release-name> --namespace <namespace> # Uninstalls a release from the specified namespace\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### 应用升级和回滚\n\n```bash\nhelm upgrade <release> <chart>                            # Upgrade a release\nhelm upgrade <release> <chart> --rollback-on-failure      # If set, upgrade process rolls back changes made in case of failed upgrade.\nhelm upgrade <release> <chart> --dependency-update        # update dependencies if they are missing before installing the chart\nhelm upgrade <release> <chart> --version <version_number> # specify a version constraint for the chart version to use\nhelm upgrade <release> <chart> --values                   # specify values in a YAML file or a URL (can specify multiple)\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Set values on the command line (can specify multiple or separate valuese)\nhelm upgrade <release> <chart> --force                    # Force resource updates through a replacement strategy\nhelm rollback <release> <revision>                        # Roll back a release to a specific revision\nhelm rollback <release> <revision>  --cleanup-on-fail     # Allow deletion of new resources created in this rollback when rollback fails\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### 列出、添加、移除和更新仓库\n\n```bash\nhelm repo add <repo-name> <url>   # Add a repository from the internet:\nhelm repo list                    # List added chart repositories\nhelm repo update                  # Update information of available charts locally from chart repositories\nhelm repo remove <repo_name>      # Remove one or more chart repositories\nhelm repo index <DIR>             # Read the current directory and generate an index file based on the charts found.\nhelm repo index <DIR> --merge     # Merge the generated index with an existing index file\nhelm search repo <keyword>        # Search repositories for a keyword in charts\nhelm search hub <keyword>         # Search for charts in the Artifact Hub or your own hub instance\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Helm Release 监控\n\n```bash\nhelm list                       # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified\nhelm list --all                 # Show all releases without any filter applied, can use -a\nhelm list --all-namespaces      # List releases across all namespaces, we can use -A\nhelm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!='\nhelm list --date                # Sort by release date\nhelm list --deployed            # Show deployed releases. If no other is specified, this will be automatically enabled\nhelm list --pending             # Show pending releases\nhelm list --failed              # Show failed releases\nhelm list --uninstalled         # Show uninstalled releases (if 'helm uninstall --keep-history' was used)\nhelm list --superseded          # Show superseded releases\nhelm list -o yaml               # Prints the output in the specified format. Allowed values: table, json, yaml (default table)\nhelm status <release>           # This command shows the status of a named release.\nhelm status <release> --revision <number>   # if set, display the status of the named release with revision\nhelm history <release>          # Historical revisions for a given release.\nhelm env                        # Env prints out all the environment information in use by Helm.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### 下载 Release 信息\n\n```bash\nhelm get all <release>      # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release.\nhelm get hooks <release>    # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\\n' separator.\nhelm get manifest <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.\nhelm get notes <release>    # Shows notes provided by the chart of a named release.\nhelm get values <release>   # Downloads a values file for a given release. use -o to format output\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### 插件管理\n\n```bash\nhelm plugin install <path/url>      # Install plugins\nhelm plugin list                    # View a list of all installed plugins\nhelm plugin update <plugin>         # Update plugins\nhelm plugin uninstall <plugin>      # Uninstall a plugin\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/intro/index.mdx",
    "content": "---\ntitle: 介绍\nsidebar_position: 1\n---\n\n# Helm 介绍\n\nHelm 新手从这里开始。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/intro/install.md",
    "content": "---\ntitle: 安装 Helm\ndescription: 了解如何安装并运行 Helm。\nsidebar_position: 2\n---\n\n本指南介绍如何安装 Helm CLI。Helm 可以通过源码或预构建的二进制版本安装。\n\n## 通过 Helm 项目安装\n\nHelm 项目提供了两种获取和安装 Helm 的方式，这是官方提供的获取 Helm 发布版本的方法。此外，Helm 社区提供了通过不同包管理器安装 Helm 的方法，这些方法可以在下面的官方方法之后看到。\n\n### 通过二进制版本安装\n\n每个 Helm [版本](https://github.com/helm/helm/releases)都提供了各种操作系统的二进制版本，这些版本可以手动下载和安装。\n\n1. 下载[需要的版本](https://github.com/helm/helm/releases)\n2. 解压（`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`）\n3. 在解压目录中找到 `helm` 程序，移动到需要的目录中（`mv linux-amd64/helm /usr/local/bin/helm`）\n\n完成后，你可以运行客户端程序并[添加稳定仓库](./quickstart.md#初始化-helm-chart-仓库)：`helm help`。\n\n**注意：** Helm 的自动化测试仅在 GitHub Actions 构建和发布时针对 Linux AMD64 执行。其他操作系统的测试由对应平台的社区负责。\n\n### 使用脚本安装\n\nHelm 提供了一个安装脚本，可以自动拉取最新版本并[在本地安装](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3)。\n\n你可以下载这个脚本并在本地执行。脚本有详细的注释，建议在运行前阅读了解其功能。\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\n如果想直接执行安装，运行 `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`。\n\n## 通过包管理器安装\n\nHelm 社区提供了通过操作系统包管理器安装 Helm 的方式。但 Helm 项目不支持这些方式，且不认为是可信的第三方。\n\n### 使用 Homebrew (macOS)\n\nHelm 社区成员贡献了一种在 Homebrew 构建 Helm 的方案，这个方案通常是最新的。\n\n```console\nbrew install helm\n```\n\n（注意：还有一个 emacs-helm 的方案，当然这是另一个项目了。）\n\n### 使用 Chocolatey (Windows)\n\nHelm 社区成员贡献了一个 [Helm 包](https://chocolatey.org/packages/kubernetes-helm)在 [Chocolatey](https://chocolatey.org/) 中构建，该包通常是最新的。\n\n```console\nchoco install kubernetes-helm\n```\n\n### 使用 Scoop (Windows)\n\nHelm 社区成员贡献了一个针对 [Scoop](https://scoop.sh) 的 [Helm 包](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json)，该包通常是最新的。\n\n```console\nscoop install helm\n```\n\n### 使用 Winget (Windows)\n\nHelm 社区成员贡献了一个针对 [Winget](https://learn.microsoft.com/en-us/windows/package-manager/) 的 [Helm 包](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm)，该包通常是最新的。\n\n```console\nwinget install Helm.Helm\n```\n\n### 使用 Apt (Debian/Ubuntu)\n\nHelm 社区成员贡献了 Debian/Ubuntu 的 Apt 包，通常会保持最新。感谢 [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) 托管此仓库。\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### 使用 dnf/yum (Fedora)\n\n从 Fedora 35 开始，官方仓库可以使用 Helm 了，可以调用以下命令安装 Helm：\n\n```console\nsudo dnf install helm\n```\n\n### 使用 Snap\n\n[Snapcrafters](https://github.com/snapcrafters) 社区维护了 [Helm 包](https://snapcraft.io/helm)的 Snap 版本：\n\n```console\nsudo snap install helm --classic\n```\n\n### 使用 pkg (FreeBSD)\n\nFreeBSD 社区成员贡献了一个 [Helm 包](https://www.freshports.org/sysutils/helm)来构建 [FreeBSD 端口集](https://man.freebsd.org/ports)。该包通常是最新的。\n\n```console\npkg install helm\n```\n\n### 开发版本构建\n\n除了正式版本，你还可以下载和安装 Helm 的开发版本。\n\n### 使用 Canary 构建\n\n\"Canary\" 版本是从 Helm 最新的 `main` 分支构建的。这些不是官方版本，可能不稳定，但可以用于测试最新特性。\n\nCanary Helm 二进制包存储在 [get.helm.sh](https://get.helm.sh)。以下是常用构建的链接：\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [实验性 Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### 使用源码构建 (Linux, macOS)\n\n从源码构建 Helm 的工作要稍微多一点，但如果你想测试最新（预发布）的 Helm 版本，这是最好的方式。\n\n你必须有可用的 Go 环境。\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\n如果需要，会拉取依赖并缓存，然后验证配置。然后会编译 `helm` 并放在 `bin/helm`。\n\n## 总结\n\n大多数情况下，安装只需获取一个构建好的 `helm` 二进制包。本文档涵盖了一些进阶安装场景。\n\n一旦你成功安装了 Helm 客户端，就可以继续使用 Helm 管理 chart 和[添加稳定的仓库](./quickstart.md#初始化-helm-chart-仓库)。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: 快速入门指南\ndescription: 如何安装 Helm 并快速上手，包括发行版说明、常见问题和插件。\nsidebar_position: 1\n---\n\n本指南介绍如何快速开始使用 Helm。\n\n## 先决条件\n\n想要成功且安全地使用 Helm，需要以下前置条件：\n\n1. 一个 Kubernetes 集群\n2. 确定安装时需要应用的安全配置（如有）\n3. 安装和配置 Helm\n\n### 安装或者使用现有的 Kubernetes 集群\n\n- 使用 Helm，需要一个 Kubernetes 集群。对于 Helm 的最新版本，我们建议使用 Kubernetes 的最新稳定版，\n  通常是次新的 minor 版本。\n- 你还需要有一个本地已配置好的 `kubectl`。\n\n查看 Helm 和对应支持的 Kubernetes 版本，可以参考 [Helm 版本支持策略](../topics/version_skew.md)。\n\n## 安装 Helm\n\n你可以通过 `homebrew` 下载二进制 Helm client 安装包，也可以通过 [GitHub 官方发布页面](https://github.com/helm/helm/releases) 下载。\n\n更多安装方式请参阅 [安装指南](./install.md)。\n\n## 初始化 Helm Chart 仓库\n\n安装好 Helm 之后，你可以添加一个 chart 仓库。从 [Artifact Hub](https://artifacthub.io/packages/search?kind=0) 中查找可用的 Helm chart 仓库。\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\n添加完成后，你可以列出可安装的 chart：\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## 安装示例 Chart\n\n你可以通过 `helm install` 命令安装 chart。 Helm 可以通过多种途径查找和安装 chart，\n但最简单的是安装官方的 `bitnami` chart。\n\n```console\n$ helm repo update              # 确保获取最新的 chart 列表\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\n在上面的例子中，`bitnami/mysql` 这个 chart 被发布，名字是 `mysql-1612624192`\n\n运行 `helm show chart bitnami/mysql` 可以快速了解该 chart 的基本信息。\n运行 `helm show all bitnami/mysql` 可以获取该 chart 的所有信息。\n\n每当你执行 `helm install` 的时候，都会创建一个新的 release。\n所以一个 chart 可以在同一个集群里被安装多次，每一个都可以独立管理和升级。\n\n`helm install` 是一个拥有很多能力的强大的命令，更多信息详见 [使用 Helm](./using_helm.md)。\n\n## 关于 Release\n\n通过 Helm 你可以很容易看到哪些 chart 被发布了：\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\n`helm list`（或 `helm ls`）命令会列出所有已部署的 release。\n\n## 卸载 Release\n\n你可以使用 `helm uninstall` 命令卸载 release：\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\n该命令会从 Kubernetes 卸载 `mysql-1612624192`，删除该 release 相关的所有资源以及 release 历史。\n\n如果你在执行 `helm uninstall` 的时候提供 `--keep-history` 选项，Helm 将会保存 release 历史。\n你可以通过命令查看该 release 的信息：\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\n因为 `--keep-history` 选项会让 Helm 跟踪你的 release（即使你卸载了它们），所以你可以审计集群历史，甚至使用\n`helm rollback` 回滚 release。\n\n## 查看帮助信息\n\n如果你想了解更多可用的 Helm 命令，请使用 `helm help` 命令，或者在任意命令后添加 `-h` 选项：\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: 使用Helm\ndescription: 解释 Helm 的基础知识。\nsidebar_position: 3\n---\n\n本指南介绍了使用 Helm 来管理 Kubernetes 集群上的软件包的基础知识。本指南假定你已经[安装](./install.md)了 Helm 客户端。\n\n如果你仅对运行一些快速命令感兴趣，则不妨从[快速入门指南](./quickstart.md)开始。本章包含了\nHelm 命令的详细说明，并解释如何使用 Helm。\n\n## 三大概念\n\n*Chart* 代表着 Helm 包。它包含在 Kubernetes 集群内部运行应用程序，工具或服务所需的所有资源定义。你可以把它看作是\nHomebrew formula，Apt dpkg，或 Yum RPM 在Kubernetes 中的等价物。\n\n*Repository（仓库）* 是用来存放和共享 charts 的地方。它就像 Perl 的 [CPAN 档案库网络](https://www.cpan.org)\n或是 Fedora 的[软件包仓库](https://src.fedoraproject.org/)，只不过它是供 Kubernetes 包所使用的。\n\n*Release* 是运行在 Kubernetes 集群中的 chart 的实例。一个 chart 通常可以在同一个集群中安装多次。每一次安装都会创建一个新的\n_release_。以 MySQL chart为例，如果你想在你的集群中运行两个数据库，你可以安装该chart两次。每一个数据库都会拥有它自己的\n_release_ 和 _release name_。\n\n在了解了上述这些概念以后，我们就可以这样来解释 Helm：\n\nHelm 安装 _charts_ 到 Kubernetes 集群中，每次安装都会创建一个新的 _release_。你可以在 Helm 的\nchart _repositories_ 中寻找新的 chart。\n\n## 'helm search'：查找 Charts\n\nHelm 自带一个强大的搜索命令，可以用来从两种来源中进行搜索：\n\n- `helm search hub` 从 [Artifact Hub](https://artifacthub.io) 中查找并列出 helm charts。\n  Artifact Hub中存放了大量不同的仓库。\n- `helm search repo` 从你添加（使用 `helm repo add`）到本地 helm 客户端中的仓库中进行查找。该命令基于本地数据进行搜索，无需连接互联网。\n\n你可以通过运行 `helm search hub` 命令找到公开可用的charts：\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\n上述命令从 Artifact Hub 中搜索所有的 `wordpress` charts。\n\n如果不进行过滤，`helm search hub` 命令会展示所有可用的 charts。\n\n`helm search hub` 命令输出的 URL 指向 [artifacthub.io](https://artifacthub.io/) 上的页面位置，而非实际的 Helm 仓库地址。使用 `helm search hub --list-repo-url` 可以获取实际的 Helm 仓库 URL，这在你需要添加新仓库时非常有用：`helm repo add [NAME] [URL]`。\n\n使用 `helm search repo` 命令，你可以从你所添加的仓库中查找chart的名字。\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nHelm 搜索使用模糊字符串匹配算法，所以你可以只输入名字的一部分：\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\n搜索是用来发现可用包的一个好办法。一旦你找到你想安装的 helm 包，你便可以通过使用 `helm install` 命令来安装它。\n\n## 'helm install'：安装一个 helm 包\n\n使用 `helm install` 命令来安装一个新的 helm 包。最简单的使用方法只需要传入两个参数：你命名的release名字和你想安装的chart的名称。\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n\n```\n\n现在`wordpress` chart 已经安装。注意安装chart时创建了一个新的 _release_ 对象。上述发布被命名为 `happy-panda`。\n（如果想让Helm生成一个名称，删除发布名称并使用`--generate-name`。）\n\n在安装过程中，`helm` 客户端会打印一些有用的信息，其中包括：哪些资源已经被创建，release当前的状态，以及你是否还需要执行额外的配置步骤。\n\nHelm按照以下顺序安装资源：\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nHelm 客户端不会等到所有资源都运行才退出。许多 charts 需要大小超过 600M 的 Docker 镜像，可能需要很长时间才能安装到集群中。\n\n你可以使用 `helm status` 来追踪 release 的状态，或是重新读取配置信息：\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\n上述信息展示了 release 的当前状态。\n\n### 安装前自定义 chart\n\n上述安装方式只会使用 chart 的默认配置选项。很多时候，我们需要自定义 chart 来指定我们想要的配置。\n\n使用 `helm show values` 可以查看 chart 中的可配置选项：\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\n然后，你可以使用 YAML 格式的文件覆盖上述任意配置项，并在安装过程中使用该文件。\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\n上述命令将为 MariaDB 创建一个名称为 `user0` 的默认用户，并且授予该用户访问新建的 `user0db` 数据库的权限。chart 中的其他默认配置保持不变。\n\n安装过程中有两种方式传递配置数据：\n\n- `--values` (或 `-f`)：使用 YAML 文件覆盖配置。可以指定多次，优先使用最右边的文件。\n- `--set`：通过命令行的方式对指定项进行覆盖。\n\n如果同时使用两种方式，则 `--set` 中的值会被合并到 `--values` 中，但是 `--set` 中的值优先级更高。在`--set`\n中覆盖的内容会被保存在 Secret 中。可以通过 `helm get values <release-name>` 来查看指定 release 中\n`--set` 设置的值。也可以通过运行 `helm upgrade` 并指定 `--reset-values` 字段来清除 `--set` 中设置的值。\n\n#### `--set` 的格式和限制\n\n`--set` 选项使用0或多个 name/value 对。最简单的用法类似于：`--set name=value`，等价于如下 YAML 格式：\n\n```yaml\nname: value\n```\n\n多个值使用逗号分割，因此 `--set a=b,c=d` 的 YAML 表示是：\n\n```yaml\na: b\nc: d\n```\n\n支持更复杂的表达式。例如，`--set outer.inner=value` 被转换成了：\n\n```yaml\nouter:\n  inner: value\n```\n\n列表使用花括号（`{}`）来表示。例如，`--set name={a, b, c}` 被转换成了：\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\n某些name/key可以设置为`null`或者空数组，例如 `--set name=[],a=null` 由\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\n变成了\n\n```yaml\nname: []\na: null\n```\n\n从 2.5.0 版本开始，可以使用数组下标的语法来访问列表中的元素。例如 `--set servers[0].port=80` 就变成了：\n\n```yaml\nservers:\n  - port: 80\n```\n\n多个值也可以通过这种方式来设置。`--set servers[0].port=80,servers[0].host=example` 变成了：\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\n如果需要在 `--set` 中使用特殊字符，你可以使用反斜线来进行转义；`--set name=value1\\,value2` 就变成了：\n\n```yaml\nname: \"value1,value2\"\n```\n\n类似的，你也可以转义点\b序列（英文句号）。这可能会在 chart 使用 `toYaml` 函数来解析 annotations，labels，和\nnode selectors 时派上用场。`--set nodeSelector.\"kubernetes\\.io/role\"=master` 语法就变成了：\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\n深层嵌套的数据结构可能会很难用 `--set` 表达。我们希望 Chart 的设计者们在设计 `values.yaml` 文件的格式时，考虑到 `--set`\n的使用。（更多内容请查看 [Values 文件](/chart_template_guide/values_files.md)）\n\n### 更多安装方法\n\n`helm install` 命令可以从多个来源进行安装：\n\n- chart 的仓库（如上所述）\n- 本地 chart 压缩包（`helm install foo foo-0.1.1.tgz`）\n- 解压后的 chart 目录（`helm install foo path/to/foo`）\n- 完整的 URL（`helm install foo https://example.com/charts/foo-1.2.3.tgz`）\n\n## 'helm upgrade' 和 'helm rollback'：升级 release 和失败时恢复\n\n当你想升级到 chart 的新版本，或是修改 release 的配置，你可以使用 `helm upgrade` 命令。\n\n一次升级操作会使用已有的 release 并根据你提供的信息对其进行升级。由于 Kubernetes 的 chart\n可能会很大而且很复杂，Helm 会尝试执行最小侵入式升级。即它只会更新自上次发布以来发生了更改的内容。\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\n在上面的例子中，`happy-panda` 这个 release 使用相同的 chart 进行升级，但是使用了一个新的 YAML 文件：\n\n```yaml\nmariadb.auth.username: user1\n```\n\n我们可以使用 `helm get values` 命令来看看配置值是否真的生效了：\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\n`helm get` 是一个查看集群中 release 的有用工具。正如我们上面所看到的，`panda.yaml` 中的新值已经被部署到集群中了。\n\n现在，假如在一次发布过程中，发生了不符合预期的事情，也很容易通过 `helm rollback [RELEASE] [REVISION]` 命令回滚到之前的发布版本。\n\n```console\n$ helm rollback happy-panda 1\n```\n\n上面这条命令将我们的 `happy-panda` 回滚到了它最初的版本。release 版本其实是一个增量修订（revision）。\n每当发生了一次安装、升级或回滚操作，revision 的值就会加1。第一次 revision 的值永远是1。我们可以使用\n`helm history [RELEASE]` 命令来查看一个特定 release 的修订版本号。\n\n## 安装、升级、回滚时的有用选项\n\n你还可以指定一些其他有用的选项来自定义 Helm 在安装、升级、回滚期间的行为。请注意这并不是 cli 参数的完整列表。\n要查看所有参数的说明，请执行 `helm <command> --help` 命令。\n\n- `--timeout`：一个 [Go duration](https://golang.org/pkg/time/#ParseDuration) 类型的值，\n  用来表示等待 Kubernetes 命令完成的超时时间，默认值为 `5m0s`。\n- `--wait`：表示必须要等到所有的 Pods 都处于 ready 状态，PVC 都被绑定，Deployments 都至少拥有最小 ready 状态\n  Pods 个数（`Desired`减去 `maxUnavailable`），并且 Services 都具有 IP 地址（如果是`LoadBalancer`，\n  则为 Ingress），才会标记该 release 为成功。最长等待时间由 `--timeout` 值指定。如果达到超时时间，release 将被标记为\n  `FAILED`。注意：当 Deployment 的 `replicas` 被设置为1，但其滚动升级策略中的 `maxUnavailable`\n  没有被设置为0时，`--wait` 将返回就绪，因为已经满足了最小 ready Pod 数。\n- `--no-hooks`：不运行当前命令的钩子。\n- `--recreate-pods`（仅适用于 `upgrade` 和 `rollback`）：这个参数会导致重建所有的\n  Pod（deployment中的Pod 除外）。（在 Helm 3 中已被废弃）\n\n## 'helm uninstall'：卸载 release\n\n使用 `helm uninstall` 命令从集群中卸载一个 release：\n\n```console\n$ helm uninstall happy-panda\n```\n\n该命令将从集群中移除指定 release。你可以通过 `helm list` 命令看到当前部署的所有 release：\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\n从上面的输出中，我们可以看到，`happy-panda` 这个 release 已经被卸载。\n\n在上一个 Helm 版本中，当一个 release 被删除，会保留一条删除记录。而在 Helm 3 中，删除也会移除 release 的记录。\n如果你想保留删除记录，使用 `helm uninstall --keep-history`。使用 `helm list --uninstalled`\n只会展示使用了 `--keep-history` 删除的 release。\n\n`helm list --all` 会展示 Helm 保留的所有 release 记录，包括失败或删除的条目（指定了 `--keep-history`）：\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\n注意，因为现在默认会删除 release，所以你不再能够回滚一个已经被卸载的资源了。\n\n## 'helm repo'：使用仓库\n\nHelm 3 不再附带一个默认的 chart 仓库。`helm repo` 提供了一组命令用于添加、列出和移除仓库。\n\n使用 `helm repo list` 来查看配置的仓库：\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\n使用 `helm repo add` 来添加新的仓库：\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\n因为 chart 仓库经常在变化，在任何时候你都可以通过执行 `helm repo update` 命令来确保你的 Helm 客户端是最新的。\n\n使用 `helm repo remove` 命令来移除仓库。\n\n## 创建你自己的 charts\n\n[chart 开发指南](/topics/charts.md)介绍了如何开发你自己的 chart。但是你也可以通过使用\n`helm create` 命令来快速开始：\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\n现在，`./deis-workflow` 目录下已经有一个 chart 了。你可以编辑它并创建你自己的模版。\n\n在编辑 chart 时，可以通过 `helm lint` 验证格式是否正确。\n\n当准备将 chart 打包分发时，你可以运行 `helm package` 命令：\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\n然后这个 chart 就可以很轻松的通过 `helm install` 命令安装：\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\n打包好的 chart 可以上传到 chart 仓库中。查看 [Helm chart 仓库](/topics/chart_repository.md)获取更多信息。\n\n## 总结\n\n这一章介绍了 `helm` 客户端的基本使用方式，包括搜索，安装，升级，和卸载。也涵盖了一些有用的工具类命令，如`helm status`，\n`helm get`，和 `helm repo`。\n\n有关这些命令的更多信息，请查看 Helm 的内置帮助命令：`helm help`。\n\n在[下一章](/howto/charts_tips_and_tricks.md)中，我们来看一下如何开发 charts。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_install.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tinstallClient := action.NewInstall(actionConfig)\n\n\tinstallClient.DryRunOption = \"none\"\n\tinstallClient.ReleaseName = releaseName\n\tinstallClient.Namespace = settings.Namespace()\n\tinstallClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tinstallClient.CertFile,\n\t\tinstallClient.KeyFile,\n\t\tinstallClient.CaFile,\n\t\tinstallClient.InsecureSkipTLSverify,\n\t\tinstallClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tinstallClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tif chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil {\n\t\tif err := action.CheckDependencies(chart, chartDependencies); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !installClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tmanager := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          installClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t\tRegistryClient:   installClient.GetRegistryClient(),\n\t\t\t}\n\t\t\tif err := manager.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := installClient.RunWithContext(ctx, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run install: %w\", err)\n\t}\n\n\tlogger.Printf(\"release created:\\n%+v\", *release)\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_list.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runList(logger *log.Logger, settings *cli.EnvSettings) error {\n\n\tactionConfig, err := initActionConfigList(settings, logger, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tlistClient := action.NewList(actionConfig)\n\t// Only list deployed\n\t//listClient.Deployed = true\n\tlistClient.All = true\n\tlistClient.SetStateMask()\n\n\tresults, err := listClient.Run()\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run list action: %w\", err)\n\t}\n\n\tfor _, rel := range results {\n\t\tlogger.Printf(\"list result: %+v\", rel)\n\t}\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_main.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"bufio\"\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\t\"os\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/registry\"\n)\n\nvar helmDriver string = os.Getenv(\"HELM_DRIVER\")\n\nfunc initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) {\n\treturn initActionConfigList(settings, logger, false)\n}\n\nfunc initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) {\n\n\tactionConfig := new(action.Configuration)\n\n\tnamespace := func() string {\n\t\t// For list action, you can pass an empty string instead of settings.Namespace() to list\n\t\t// all namespaces\n\t\tif allNamespaces {\n\t\t\treturn \"\"\n\t\t}\n\t\treturn settings.Namespace()\n\t}()\n\n\tif err := actionConfig.Init(\n\t\tsettings.RESTClientGetter(),\n\t\tnamespace,\n\t\thelmDriver,\n\t\tlogger.Printf); err != nil {\n\t\treturn nil, err\n\t}\n\n\treturn actionConfig, nil\n}\n\nfunc newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) {\n\topts := []registry.ClientOption{\n\t\tregistry.ClientOptDebug(settings.Debug),\n\t\tregistry.ClientOptEnableCache(true),\n\t\tregistry.ClientOptWriter(os.Stderr),\n\t\tregistry.ClientOptCredentialsFile(settings.RegistryConfig),\n\t}\n\tif plainHTTP {\n\t\topts = append(opts, registry.ClientOptPlainHTTP())\n\t}\n\n\t// Create a new registry client\n\tregistryClient, err := registry.NewClient(opts...)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) {\n\tif certFile != \"\" && keyFile != \"\" || caFile != \"\" || insecureSkipTLSverify {\n\t\tregistryClient, err := registry.NewRegistryClientWithTLS(\n\t\t\tlogger.Writer(),\n\t\t\tcertFile,\n\t\t\tkeyFile,\n\t\t\tcaFile,\n\t\t\tinsecureSkipTLSverify,\n\t\t\tsettings.RegistryConfig,\n\t\t\tsettings.Debug)\n\n\t\tif err != nil {\n\t\t\treturn nil, err\n\t\t}\n\t\treturn registryClient, nil\n\t}\n\tregistryClient, err := newRegistryClient(settings, plainHTTP)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc main() {\n\n\tlogger := log.Default()\n\n\t// For convenience, initialize SDK setting via CLI mechanism\n\tsettings := cli.New()\n\n\t// Release name, chart and values\n\treleaseName := \"helm-sdk-example\"\n\tchartRef := \"oci://ghcr.io/stefanprodan/charts/podinfo\"\n\treleaseValues := map[string]interface{}{\n\t\t\"replicaCount\": \"2\",\n\t}\n\n\t// Pull the chart to the local filesystem\n\tif err := runPull(logger, settings, chartRef, \"6.4.1\"); err != nil {\n\t\tfmt.Printf(\"failed to run pull: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// Install the chart (from the pulled chart local archive)\n\tif err := runInstall(context.TODO(), logger, settings, releaseName, \"./podinfo-6.4.1.tgz\", \"\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run install: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart installed. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Upgrade to version 6.5.4, updating the replicaCount to three\n\treleaseValues[\"replicaCount\"] = \"3\"\n\tif err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, \"6.5.4\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run upgrade: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart upgraded. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Uninstall the chart\n\tif err := runUninstall(logger, settings, releaseName); err != nil {\n\t\tfmt.Printf(\"failed to run uninstall: %+v\", err)\n\t\tos.Exit(1)\n\t}\n}\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_pull.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tregistryClient, err := newRegistryClient(settings, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tactionConfig.RegistryClient = registryClient\n\n\tpullClient := action.NewPullWithOpts(\n\t\taction.WithConfig(actionConfig))\n\t// client.RepoURL = \"\"\n\tpullClient.DestDir = \"./\"\n\tpullClient.Settings = settings\n\tpullClient.Version = chartVersion\n\n\tresult, err := pullClient.Run(chartRef)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to pull chart: %w\", err)\n\t}\n\n\tlogger.Printf(\"%+v\", result)\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_uninstall.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tuninstallClient := action.NewUninstall(actionConfig)\n\tuninstallClient.DeletionPropagation = \"foreground\" // \"background\" or \"orphan\"\n\n\tresult, err := uninstallClient.Run(releaseName)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run uninstall action: %w\", err)\n\t}\n\tif result != nil {\n\t\tlogger.Printf(\"result: %+v\\n\", *result.Release)\n\t}\n\n\tlogger.Printf(\"release \\\"%s\\\" uninstalled\\n\", releaseName)\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_upgrade.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tupgradeClient := action.NewUpgrade(actionConfig)\n\n\tupgradeClient.Namespace = settings.Namespace()\n\tupgradeClient.DryRunOption = \"none\"\n\tupgradeClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tupgradeClient.CertFile,\n\t\tupgradeClient.KeyFile,\n\t\tupgradeClient.CaFile,\n\t\tupgradeClient.InsecureSkipTLSverify,\n\t\tupgradeClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"missing registry client: %w\", err)\n\t}\n\tupgradeClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to load chart: %w\", err)\n\t}\n\tif req := chart.Metadata.Dependencies; req != nil {\n\t\tif err := action.CheckDependencies(chart, req); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !upgradeClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tman := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          upgradeClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t}\n\t\t\tif err := man.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run upgrade action: %w\", err)\n\t}\n\n\tlogger.Printf(\"release: %+v\", release)\n\n\treturn nil\n}\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx",
    "content": "---\ntitle: 示例\ndescription: 演示 Helm SDK 的各项功能\nsidebar_position: 2\n---\n\nimport Install from './_install.mdx'\nimport List from './_list.mdx'\nimport Main from './_main.mdx'\nimport Pull from './_pull.mdx'\nimport Uninstall from './_uninstall.mdx'\nimport Upgrade from './_upgrade.mdx'\n\n本文档通过一系列示例来演示 Helm SDK 的使用方法，旨在展示各种 SDK 功能。\n\n最后一个示例展示了 `main.go` 驱动程序（详见[驱动示例](#driver)），该程序会执行下述操作，并包含所需的辅助函数。\n\n所有示例代码均位于 [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples) 目录下，并且可以完整运行。\n\n## 操作 {#actions}\n\n### 安装操作 {#install-action}\n\n此示例演示如何安装指定的 chart/release，支持指定版本和自定义 values：\n\n<Install />\n\n### 升级操作 {#upgrade-action}\n\n此示例演示如何使用指定的 chart、版本和 values 升级已有的 release：\n\n<Upgrade />\n\n### 卸载操作 {#uninstall-action}\n\n此示例演示如何卸载指定的 release：\n\n<Uninstall />\n\n### 列表操作 {#list-action}\n\n此示例会列出当前配置命名空间下的所有已发布 chart：\n\n<List />\n\n### 拉取操作 {#pull-action}\n\n此示例演示如何从 OCI 仓库拉取一个 chart：\n\n<Pull />\n\n## 驱动程序 {#driver}\n\n此处的驱动示例展示了 Helm SDK 各项操作所需的辅助函数，并演示了如何实际使用上述示例，从 OCI 仓库拉取、安装、升级和卸载 `podinfo` chart。\n\n<Main />\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: 介绍\ndescription: 介绍 Helm Go SDK\nsidebar_position: 1\n---\n\nHelm 的 Go SDK 使自定义软件能够利用 Helm chart 和 Helm 的功能来管理 Kubernetes 软件部署（事实上，Helm CLI 本质上就是这样一个工具！）。\n\n目前，SDK 已在功能上与 Helm CLI 分离。SDK 可以（并且正在）被独立工具使用。Helm 项目已承诺为 SDK 提供 API 稳定性。值得注意的是，SDK 在将 CLI 和 SDK 分离的初始工作中仍有一些未完善之处，Helm 项目旨在随着时间的推移逐步改进。\n\n完整的 API 文档可以在 [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3) 找到。\n\n下面简要概述一些主要的包，并提供一个简单示例。更多示例和更完整的示例程序，请参阅[示例](/sdk/examples.mdx)部分。\n\n## 主要包概览\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action)：包含执行 Helm 操作的主要\"客户端\"。这与 CLI 在底层使用的包相同。如果只需要从其他 Go 程序执行基本的 Helm 命令，可以使用这个包。\n- [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 的方法和辅助函数。\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) 及其子包：包含标准 Helm 环境变量的所有处理程序，其子包包含输出和 values 文件处理。\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release)：定义 `Release` 对象和状态。\n\n除了这些之外还有很多包，请查看文档以获取更多信息！\n\n### 简单示例\n\n这是使用 Go SDK 执行 `helm list` 的简单示例。更完整的示例请参阅[示例](/sdk/examples.mdx)部分。\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // 可以传递空字符串代替 settings.Namespace() 来列出所有命名空间\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // 仅列出已部署的\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n## 兼容性\n\nHelm SDK 明确遵循 Helm 向后兼容性保证：\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\n也就是说，破坏性更改只会在主要版本中进行。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/index.mdx",
    "content": "---\ntitle: Go SDK\nsidebar_position: 7\n---\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/advanced.md",
    "content": "---\ntitle: Helm 高级技术\ndescription: 为 Helm 高级用户说明各种高级特性\nsidebar_position: 9\n---\n\n本节介绍使用 Helm 的各种高级特性和技术。这些内容主要面向希望对 chart 和 release 进行高度自定义和操作的 Helm 高级用户。每个高级特性都有各自的权衡利弊，因此使用时需要具备深厚的 Helm 知识并谨慎操作。换言之，请谨记 [Peter Parker 原则](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)。\n\n## 后置渲染 {#post-rendering}\n\n后置渲染允许 chart 安装者在 Helm 安装渲染后的 manifest 之前，手动操作、配置或验证这些 manifest。这使得有高级配置需求的用户可以使用 [`kustomize`](https://kustomize.io) 等工具来应用配置更改，而无需 fork 公共 chart 或要求 chart 维护者为软件指定所有配置选项。此外，还有一些场景用于在企业环境中注入常用工具和 sidecar，或在部署前对 manifest 进行分析。\n\n### 前提条件\n\n- Helm 3.1+\n\n### 使用\n\n后置渲染器可以是任意可执行文件，只要能在 STDIN 接收渲染后的 Kubernetes manifest 并在 STDOUT 返回有效的 Kubernetes manifest 即可。遇到失败时应返回非零退出码。这是两个组件之间唯一的\"API\"，为后置渲染过程提供了极大的灵活性。\n\n后置渲染器可以与 `install`、`upgrade` 和 `template` 命令一起使用。使用后置渲染器时，通过 `--post-renderer` 参数指定渲染器可执行文件的路径：\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\n如果路径中不包含任何分隔符，会在 $PATH 中搜索；否则会将相对路径解析为完整路径。\n\n如果需要使用多个后置渲染器，可以在脚本中调用它们，或者在构建的二进制工具中组合调用。在 bash 中，只需像 `renderer1 | renderer2 | renderer3` 这样简单地串联即可。\n\n可以在[这里](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render)查看使用 `kustomize` 作为后置渲染器的示例。\n\n### 注意事项\n\n使用后置渲染器时，有几点需要注意。最重要的是，当使用后置渲染器时，所有修改该 release 的人**必须**使用相同的渲染器，以确保构建的可重复性。此功能允许用户切换或停止使用渲染器，但应谨慎操作，以避免意外修改或数据丢失。\n\n另一个重要注意事项是安全性。如果你使用后置渲染器，应确保它来自可信来源（任何可执行文件都应如此）。不建议使用不受信任或未经验证的渲染器，因为它们可以完全访问渲染后的模板，而这些模板通常包含敏感数据。\n\n### 自定义后置渲染器\n\n在 Go SDK 中使用时，后置渲染器可以提供更大的灵活性。任何后置渲染器只需实现以下 Go 接口：\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\n有关 Go SDK 的更多信息，请参阅 [Go SDK 部分](#go-sdk)。\n\n## Go SDK\n\nHelm 3 引入了全新重构的 Go SDK，为构建基于 Helm 的软件和工具提供更好的体验。完整文档可在 [Go SDK 部分](/zh/docs/sdk/gosdk/)查看。\n\n## 后端存储 {#storage-backends}\n\nHelm 3 将默认的 release 信息存储方式更改为存储在 release 所在命名空间中的 Secret。Helm 2 默认将 release 信息作为 ConfigMap 存储在 Tiller 实例所在的命名空间中。以下小节介绍如何配置不同的存储后端。配置基于 `HELM_DRIVER` 环境变量，可设置为以下值之一：`[configmap, secret, sql]`。\n\n### ConfigMap 后端存储\n\n要启用 ConfigMap 后端，需要将环境变量 `HELM_DRIVER` 设置为 `configmap`。\n\n可以在 shell 中如下设置：\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\n如果要从默认后端切换到 ConfigMap 后端，需要自行进行迁移。可以使用以下命令获取 release 信息：\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**生产环境说明**：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 后端，请注意这一点，因为它可能会暴露应用程序的敏感数据。\n\n### SQL 后端存储\n\n这是一个 ***beta*** 版本的 SQL 存储后端，将 release 信息存储在 SQL 数据库中。\n\n如果 release 信息超过 1MB，这种存储后端会特别有用（此时由于 Kubernetes 底层 etcd 键值存储的内部限制，无法存储在 ConfigMap/Secret 中）。\n\n要启用 SQL 后端，需要部署 SQL 数据库并将环境变量 `HELM_DRIVER` 设置为 `sql`。数据库详细信息通过环境变量 `HELM_DRIVER_SQL_CONNECTION_STRING` 设置。\n\n可以在 shell 中如下设置：\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> 注意：目前仅支持 PostgreSQL。\n\n**生产环境说明**：建议：\n- 确保数据库可用于生产环境。对于 PostgreSQL，请参阅 [Server Administration](https://www.postgresql.org/docs/12/admin.html) 文档了解更多详情\n- 启用[权限管理](/zh/docs/topics/permissions_sql_storage_backend/)，以镜像 Kubernetes RBAC 来控制 release 信息的访问权限\n\n如果要从默认后端切换到 SQL 后端，需要自行进行迁移。可以使用以下命令获取 release 信息：\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Helm 架构\ndescription: 从较高层面描述 Helm 架构。\nsidebar_position: 8\n---\n\n# Helm 架构\n\n本文从较高层面描述 Helm 的架构。\n\n## Helm 的用途\n\nHelm 是一个管理 Kubernetes 包的工具，这种包称为 _chart_。Helm 可以完成以下任务：\n\n- 从头创建新的 chart\n- 将 chart 打包成归档文件（tgz）\n- 与存储 chart 的仓库进行交互\n- 在现有的 Kubernetes 集群中安装和卸载 chart\n- 管理使用 Helm 安装的 chart 的 release 周期\n\nHelm 有三个重要概念：\n\n1. _chart_ 是创建 Kubernetes 应用实例所需的一组信息。\n2. _config_ 包含配置信息，可以合并到已打包的 chart 中，用于创建可发布的对象。\n3. _release_ 是 _chart_ 与特定 _config_ 结合后的运行实例。\n\n## 组件\n\nHelm 是一个可执行程序，由两个不同的部分组成：\n\n**Helm 客户端** 是面向终端用户的命令行客户端，负责以下工作：\n\n- 本地 chart 开发\n- 管理仓库\n- 管理 release\n- 与 Helm 库交互\n  - 发送要安装的 chart\n  - 发送升级或卸载现有 release 的请求\n\n**Helm 库** 提供执行所有 Helm 操作的逻辑。它与 Kubernetes API 服务器交互，并提供以下功能：\n\n- 将 chart 和配置结合以构建 release\n- 将 chart 安装到 Kubernetes 中，并提供相应的 release 对象\n- 通过与 Kubernetes 交互来升级和卸载 chart\n\n独立的 Helm 库封装了 Helm 逻辑，以便不同的客户端可以使用它。\n\n## 实现\n\nHelm 客户端和库使用 Go 编程语言编写。\n\n该库使用 Kubernetes 客户端库与 Kubernetes 通信。目前，该库使用 REST+JSON。它将信息存储在 Kubernetes 的 Secret 中，不需要自己的数据库。\n\n配置文件尽可能使用 YAML 编写。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: Chart 仓库指南\ndescription: 如何创建和使用 Helm chart 仓库。\nsidebar_position: 6\n---\n\n本节介绍如何创建和使用 Helm chart 仓库。从较高层面来说，chart 仓库是用来存储和共享打包好的 chart 的位置。\n\n社区的 Helm chart 仓库位于 [Artifact Hub](https://artifacthub.io/packages/search?kind=0)，欢迎参与贡献。不过 Helm 也支持创建和运行你自己的 chart 仓库。本指南将介绍如何操作。如果你正在考虑创建 chart 仓库，也可以考虑使用 [OCI 注册中心](/zh/docs/topics/registries/)作为替代方案。\n\n## 先决条件\n\n* 阅读[快速开始](/zh/docs/intro/quickstart/)指南\n* 阅读 [Charts](/zh/docs/topics/charts/) 文档\n\n## 创建 chart 仓库\n\n_chart 仓库_ 是一个配置了 `index.yaml` 文件和一些已打包 chart 的 HTTP 服务器。当你准备好分享 chart 时，最好的方式是将 chart 上传到 chart 仓库。\n\n从 Helm 2.2.0 开始，客户端支持对仓库进行 SSL 身份认证。其他身份验证协议可以通过插件提供。\n\n由于 chart 仓库可以是任何能够提供 YAML 和 tar 文件并响应 GET 请求的 HTTP 服务器，托管你自己的 chart 仓库时有很多选择。比如可以使用 Google Cloud Storage (GCS) bucket、Amazon S3 bucket、GitHub Pages，甚至创建你自己的 web 服务器。\n\n### chart 仓库结构\n\nchart 仓库由 chart 包和一个名为 `index.yaml` 的特殊文件组成，该文件包含了仓库中所有 chart 的索引。通常 `index.yaml` 所描述的 chart 也托管在同一服务器上，[来源文件](/zh/docs/topics/provenance/)也是如此。\n\n例如，仓库 `https://example.com/charts` 的布局可能是这样的：\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\n在这个例子中，index 文件包含了 Alpine 这一个 chart 的信息，并提供了下载地址 `https://example.com/charts/alpine-0.1.2.tgz`。\n\nchart 包不一定要与 `index.yaml` 文件放在同一服务器上，但这样做通常是最简单的。\n\n### index 文件\n\nindex 文件是一个名为 `index.yaml` 的 YAML 文件。它包含了 chart 包的一些元信息，包括 chart 的 `Chart.yaml` 文件内容。一个有效的 chart 仓库必须有 index 文件。index 文件包含了 chart 仓库中每个 chart 的信息。`helm repo index` 命令会基于给定的包含 chart 包的本地目录生成 index 文件。\n\n以下是一个 index 文件示例：\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## 托管 chart 仓库\n\n本部分介绍几种提供 chart 仓库服务的方法。\n\n### Google Cloud Storage\n\n第一步是**创建你的 GCS bucket**。我们将其命名为 `fantastic-charts`。\n\n![Create a GCS Bucket](/img/helm2/create-a-bucket.png)\n\n然后通过**编辑 bucket 权限**将其设为公开。\n\n![Edit Permissions](/img/helm2/edit-permissions.png)\n\n插入以下条目**将 bucket 设为公开**：\n\n![Make Bucket Public](/img/helm2/make-bucket-public.png)\n\n恭喜，现在你有了一个可以提供 chart 服务的空 GCS bucket！\n\n你可以使用 Google Cloud Storage 命令行工具或 GCS web 界面上传 chart 仓库。公开的 GCS bucket 可以通过简单的 HTTPS 地址访问：`https://bucket-name.storage.googleapis.com/`。\n\n### Cloudsmith\n\n你也可以使用 Cloudsmith 设置 chart 仓库。在[这里](https://help.cloudsmith.io/docs/helm-chart-repository)了解更多关于 Cloudsmith 配置 chart 仓库的信息。\n\n### JFrog Artifactory\n\n同样，你也可以使用 JFrog Artifactory 设置 chart 仓库。在[这里](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)了解更多关于 JFrog Artifactory 配置 chart 仓库的信息。\n\n### GitHub Pages 示例\n\n你可以用类似的方式使用 GitHub Pages 创建 chart 仓库。\n\nGitHub 允许你通过两种方式提供静态网页：\n\n- 配置项目以提供 `docs/` 目录的内容\n- 配置项目以提供特定分支的内容\n\n我们将采用第二种方式，不过第一种方式也很简单。\n\n第一步是**创建 gh-pages 分支**。你可以在本地创建：\n\n```console\n$ git checkout -b gh-pages\n```\n\n或者在 GitHub 仓库中通过 web 界面使用 **Branch** 按钮：\n\n![Create GitHub Pages branch](/img/helm2/create-a-gh-page-button.png)\n\n然后，确保将 **gh-pages branch** 设置为 GitHub Pages。点击仓库的 **Settings**，向下滚动到 **GitHub pages** 部分，按如下设置：\n\n![Create GitHub Pages branch](/img/helm2/set-a-gh-page.png)\n\n默认情况下，**Source** 通常设置为 **gh-pages branch**。如果没有默认设置，请手动选择。\n\n如果需要，你可以在这里使用**自定义域名**。\n\n然后确保勾选了 **Enforce HTTPS**，这样提供 chart 时会使用 **HTTPS**。\n\n在这种配置下，你可以使用默认分支存储 chart 代码，并使用 **gh-pages branch** 作为 chart 仓库，例如：`https://USERNAME.github.io/REPONAME`。演示仓库 [TS Charts](https://github.com/technosophos/tscharts) 可以通过 `https://technosophos.github.io/tscharts/` 访问。\n\n如果你想使用 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 仓库。\n\n### 普通 web 服务器\n\n配置普通 web 服务器来提供 Helm chart，你只需要执行以下操作：\n\n- 将 index 文件和 chart 放在服务器可以提供服务的目录中\n- 确保 `index.yaml` 文件可以无需认证即可访问\n- 确保 `yaml` 文件以正确的内容类型提供（`text/yaml` 或 `text/x-yaml`）\n\n例如，如果你想在 `$WEBROOT/charts` 提供 chart，确保 web 根目录下有一个 `charts/` 目录，并将 index 文件和 chart 放在该目录中。\n\n### ChartMuseum 仓库服务器\n\nChartMuseum 是一个用 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/)。\n\n你也可以使用 [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) 服务器从本地文件系统托管 chart 仓库。\n\n### GitLab Package Registry\n\n使用 GitLab 可以在项目的 Package Registry 中发布 Helm chart。在[这里](https://docs.gitlab.com/ee/user/packages/helm_repository/)了解更多关于使用 GitLab 设置 Helm 包仓库的信息。\n\n## 管理 chart 仓库\n\n现在你有了 chart 仓库，本指南的最后一部分将介绍如何在仓库中维护 chart。\n\n### 在 chart 仓库中存储 chart\n\n现在你有了 chart 仓库，让我们上传 chart 和 index 文件到仓库。chart 仓库中的 chart 必须打包（`helm package chart-name/`）且遵循正确的版本号规范（参照 [SemVer 2](https://semver.org/) 指南）。\n\n以下步骤构成一个示例工作流，但你可以使用任何你喜欢的工作流来存储和更新 chart 仓库中的 chart。\n\n准备好打包的 chart 后，创建一个新目录，然后将打包的 chart 移动到该目录中。\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\n最后一条命令获取刚创建的本地目录路径和远程 chart 仓库的 URL，并在给定的目录路径中生成 `index.yaml` 文件。\n\n现在你可以使用同步工具或手动方式将 chart 和 index 文件上传到 chart 仓库。如果使用 Google Cloud Storage，可以使用 gsutil 客户端查看[示例工作流](/zh/docs/howto/chart_repository_sync_example/)。对于 GitHub，你可以简单地将 chart 放在合适的目标分支中。\n\n### 向现有仓库添加新 chart\n\n每次你想向仓库添加新 chart 时，必须重新生成 index。`helm repo index` 命令会从头完全重建 `index.yaml` 文件，只包含它在本地找到的 chart。\n\n不过，你可以使用 `--merge` 参数增量添加新 chart 到现有的 `index.yaml` 文件中（在使用类似 GCS 的远程仓库时很有用）。运行 `helm repo index --help` 了解更多信息。\n\n确保修订后的 `index.yaml` 文件和 chart 都已上传。如果生成了来源文件，也要一并上传。\n\n### 与他人分享你的 chart\n\n当你准备好分享 chart 时，只需告诉别人你的仓库 URL 即可。\n\n用户可以通过 `helm repo add [NAME] [URL]` 命令将仓库添加到他们的 Helm 客户端，并使用任何他们想要的名称来引用该仓库。\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n如果 chart 使用 HTTP 基本认证，你也可以在这里提供用户名和密码：\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**注意：** 如果仓库不包含有效的 `index.yaml`，则无法添加。\n\n**注意：** 如果你的 Helm 仓库使用了自签名证书，你可以使用 `helm repo add --insecure-skip-tls-verify ...` 来跳过 CA 验证。\n\n之后，你的用户就可以搜索你的 chart 了。更新仓库后，他们可以使用 `helm repo update` 命令获取最新的 chart 信息。\n\n*在底层，`helm repo add` 和 `helm repo update` 命令会获取 index.yaml 文件并将其存储在 `$XDG_CACHE_HOME/helm/repository/cache/` 目录中。这是 `helm search` 功能查找 chart 信息的位置。*\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: Chart Tests\ndescription: 描述如何运行和测试你的 chart。\nsidebar_position: 3\n---\n\nchart 包含了多个协同工作的 Kubernetes 资源和组件。作为 chart 作者，你可能想编写一些测试来验证 chart 在安装时是否按预期工作。这些测试也可以帮助 chart 用户了解你的 chart 预期的功能。\n\nHelm chart 中的**测试**位于 `templates/` 目录下，是一个 Job 定义，指定了一个要运行给定命令的容器。容器应该成功退出（exit 0）才算测试通过。Job 定义必须包含 Helm 测试钩子注解：`helm.sh/hook: test`。\n\n注意在 Helm v3 之前，Job 定义需要包含以下 Helm 测试钩子注解之一：`helm.sh/hook: test-success` 或 `helm.sh/hook: test-failure`。`helm.sh/hook: test-success` 仍然作为 `helm.sh/hook: test` 的向后兼容替代方案被接受。\n\n测试示例：\n\n- 验证 values.yaml 文件中的配置是否被正确注入。\n  - 确保用户名和密码正确工作\n  - 确保错误的用户名和密码无法工作\n- 验证服务已启动且负载均衡正常\n- 等等。\n\n你可以使用 `helm test <RELEASE_NAME>` 命令对一个 release 运行 Helm 中预定义的测试。对于 chart 用户来说，这是检验他们的 chart release（或应用程序）是否按预期工作的好方法。\n\n## 测试示例\n\n[helm create](/zh/docs/helm/helm_create/) 命令会自动创建一些目录和文件。要尝试 Helm 测试功能，首先创建一个示例 Helm chart。\n\n```console\n$ helm create demo\n```\n\n你现在可以在 demo Helm chart 中看到以下结构。\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\n在 `demo/templates/tests/test-connection.yaml` 中，你会看到一个可以尝试的测试。可以在这里查看 Helm 测试 Pod 定义：\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## 对 Release 运行测试套件\n\n首先，将 chart 安装到集群中以创建一个 release。你可能需要等待所有 Pod 变为 active 状态；如果在安装后立即测试，可能会出现暂时性失败，届时你需要重新测试。\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## 注意事项\n\n- 可以在单个 yaml 文件中定义多个测试，也可以将测试分布在 `templates/` 目录下的多个 yaml 文件中。\n- 可以将测试套件嵌套放在 `tests/` 目录中（如 `<chart-name>/templates/tests/`）以获得更好的隔离。\n- 测试是一种 [Helm 钩子](/zh/docs/topics/charts_hooks/)，因此 `helm.sh/hook-weight` 和 `helm.sh/hook-delete-policy` 等注解也可以用于测试资源。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/charts.md",
    "content": "---\ntitle: Chart\ndescription: 阐述chart格式，并提供使用Helm构建chart的基本指导。\nsidebar_position: 1\n---\n\nHelm使用的包格式称为 _chart_。 chart就是一个描述Kubernetes相关资源的文件集合。单个chart可以用来部署一些简单的，\n类似于memcache pod，或者某些复杂的HTTP服务器以及web全栈应用、数据库、缓存等等。\n\nChart是作为特定目录布局的文件被创建的。它们可以打包到要部署的版本存档中。\n\n如果你想下载和查看一个发布的chart，但不安装它，你可以用这个命令： `helm pull chartrepo/chartname`。\n\n该文档解释说明了chart格式，并提供了用Helm构建chart的基本指导。\n\n## Chart 文件结构\n\nchart是一个组织在文件目录中的集合。目录名称就是chart名称（没有版本信息）。因而描述WordPress的chart可以存储在`wordpress/`目录中。\n\n在这个目录中，Helm 期望可以匹配以下结构：\n\n```text\nwordpress/\n  Chart.yaml          # 包含了chart信息的YAML文件\n  LICENSE             # 可选: 包含chart许可证的纯文本文件\n  README.md           # 可选: 可读的README文件\n  values.yaml         # chart 默认的配置值\n  values.schema.json  # 可选: 一个使用JSON结构的values.yaml文件\n  charts/             # 包含chart依赖的其他chart\n  crds/               # 自定义资源的定义\n  templates/          # 模板目录， 当和values 结合时，可生成有效的Kubernetes manifest文件\n  templates/NOTES.txt # 可选: 包含简要使用说明的纯文本文件\n```\n\nHelm保留使用 `charts/`，`crds/`， `templates/`目录，以及列举出的文件名。其他文件保持原样。\n\n## Chart.yaml 文件\n\n`Chart.yaml`文件是chart必需的。包含了以下字段：\n\n```yaml\napiVersion: chart API 版本 （必需）\nname: chart名称 （必需）\nversion: 语义化2 版本（必需）\nkubeVersion: 兼容Kubernetes版本的语义化版本（可选）\ndescription: 一句话对这个项目的描述（可选）\ntype: chart类型 （可选）\nkeywords:\n  - 关于项目的一组关键字（可选）\nhome: 项目home页面的URL （可选）\nsources:\n  - 项目源码的URL列表（可选）\ndependencies: # chart 必要条件列表 （可选）\n  - name: chart名称 (nginx)\n    version: chart版本 (\"1.2.3\")\n    repository: （可选）仓库URL (\"https://example.com/charts\") 或别名 (\"@repo-name\")\n    condition: （可选） 解析为布尔值的yaml路径，用于启用/禁用chart (e.g. subchart1.enabled )\n    tags: # （可选）\n      - 用于一次启用/禁用 一组chart的tag\n    import-values: # （可选）\n      - ImportValue 保存源值到导入父键的映射。每项可以是字符串或者一对子/父列表项\n    alias: （可选） chart中使用的别名。当你要多次添加相同的chart时会很有用\nmaintainers: # （可选）\n  - name: 维护者名字 （每个维护者都需要）\n    email: 维护者邮箱 （每个维护者可选）\n    url: 维护者URL （每个维护者可选）\nicon: 用做icon的SVG或PNG图片URL （可选）\nappVersion: 包含的应用版本（可选）。不需要是语义化，建议使用引号\ndeprecated: 不被推荐的chart （可选，布尔值）\nannotations:\n  example: 按名称输入的批注列表 （可选）.\n```\n\n从[v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2)，不再允许额外的字段。推荐的方法是在\n`annotations` 中添加自定义元数据。\n\n### Chart和版本控制\n\n每个chart都必须有个版本号。版本必须遵循 [语义化版本 2](https://semver.org/spec/v2.0.0.html) 标准。\n不像经典Helm， Helm v2以及后续版本会使用版本号作为发布标记。仓库中的包通过名称加版本号标识。\n\n比如 `nginx` chart的版本字段`version: 1.2.3`按照名称被设置为：\n\n```text\nnginx-1.2.3.tgz\n```\n\n更多复杂的语义化版本 2 名称也是支持的，比如 `version: 1.2.3-alpha.1+ef365`。但系统明确禁止非语义化版本名称。例外情况是格式为 `x` 或 `x.y` 的版本。例如，如果版本号带有前导 v 或者没有完整的三部分（如 v1.2），系统会尝试将其转换为有效的语义化版本（如 v1.2.0）。\n\n**注意：** 鉴于经典Helm和部署管理器在使用chart时都非常倾向于GitHub，Helm v2 和后续版本不再依赖或需要GitHub甚至是Git。\n因此，它完全不使用Git SHA进行版本控制。\n\n`Chart.yaml`文件中的`version`字段被很多Helm工具使用，包括CLI。当生成一个包时，\n`helm package`命令可以用`Chart.yaml`文件中找到的版本号作为包名中的token。\n系统假设chart包名中的版本号可以与`Chart.yaml`文件中的版本号匹配。如果不满足这一假设会导致错误。\n\n### `apiVersion` 字段\n\n对于至少需要Helm 3的chart，`apiVersion` 字段应该是 `v2`。Chart支持之前`apiVersion` 设置为 `v1` 的Helm 版本，\n并且在Helm 3中仍然可安装。\n\n`v1` 到 `v2`的改变：\n\n- `dependencies`字段定义了chart的依赖，针对于`v1` 版本的chart被放置在分隔开的`requirements.yaml` 文件中\n（查看 [Chart 依赖](#chart-dependency)).\n- `type`字段, 用于识别应用和库类型的chart（查看 [Chart 类型](#chart-types)).\n\n### `appVersion` 字段\n\n注意这个`appVersion`字段与`version`字段并不相关。这是指定应用版本的一种方式。比如，这个`drupal` chart可能有一个\n`appVersion: \"8.2.1\"`，表示包含在chart（默认）的Drupal的版本是`8.2.1`。此字段仅供参考，对chart版本计算没有影响。\n强烈建议使用引号将版本括起来。它强制YAML解析器将版本号视为字符串。不加引号在某些场景会出现解析问题。\n比如，YAML将`1.0`解释为浮点值，且git提交的SHA类似`1234e10`是科学计数法。\n\n从Helm v3.5.0开始，`helm create`会将默认的`appVersion`用引号括起来。\n\n### `kubeVersion` 字段\n\n可选的 `kubeVersion` 字段可以在支持的Kubernetes版本上定义语义化版本约束，Helm 在安装chart时会验证这个版本约束，\n并在集群运行不支持的Kubernetes版本时显示失败。\n\n版本约束可以包括空格分隔和比较运算符，比如：\n\n```yaml\n>= 1.13.0 < 1.15.0\n```\n\n或者它们可以用或操作符 `||` 连接，比如：\n\n```yaml\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\n\n这个例子中排除了 `1.14.0` 版本，如果确定某些版本中的错误导致chart无法正常运行，这一点就很有意义。\n\n除了版本约束外，使用运算符 `=` `!=` `>` `<` `>=` `<=` 支持一下速记符号：\n\n- 闭合间隔的连字符范围， `1.1 - 2.3.4` 等价于 `>= 1.1 <= 2.3.4`\n- 通配符 `x`， `X` 和 `*`， `1.2.x` 等价于 `>= 1.2.0 < 1.3.0`\n- 波浪符号~范围 （允许改变补丁版本）， `~1.2.3` 等价于 `>= 1.2.3 < 1.3.0`\n- 插入符号^范围 （允许改变次版本）， `^1.2.3` 等价于 `>= 1.2.3 < 2.0.0`\n\n支持的语义化版本约束的细节说明请查看 [Masterminds/semver](https://github.com/Masterminds/semver)\n\n### 已弃用的Chart\n\n在Chart仓库管理chart时，有时需要废弃一个chart。 `Chart.yaml` 中可选的`deprecated`字段可以用来标记已弃用的chart。\n如果**latest**版本被标记为已弃用，则所有的chart都会被认为是已弃用的。以后可以通过发布未标记为已弃用的新版本来重新使用chart名称。\n弃用chart的工作流是：\n\n1. 升级chart的 `Chart.yaml`  文件，将这个chart标记为已弃用， 并更改版本\n2. 在chart仓库中发布新版的chart\n3. 从源仓库中移除这个chart （比如用 git）\n\n### Chart Types\n\n`type`字段定义了chart的类型。有两种类型： `application` 和 `library`。 应用是默认类型，是可以完全操作的标准chart。\n [库类型 chart](http://helm.sh/zh/docs/topics/library_charts) 提供针对chart构建的实用程序和功能。\n 库类型chart与应用类型chart不同，因为它不能安装，通常不包含任何资源对象。\n\n**注意：** 应用类型chart 可以作为库类型chart使用。可以通过将类型设置为 `library`来实现。\n然后这个库就被渲染成了一个库类型chart，所有的实用程序和功能都可以使用。所有的资源对象不会被渲染。\n\n## Chart 许可证，自述和注释\n\nChart也可以包含描述安装，配置和使用文件，以及chart许可证。\n\n许可证（LICENSE）是一个包含了chart [license](https://en.wikipedia.org/wiki/Software_license)的纯文本文件。\nchart可以包含一个许可证，因为在模板里不只是配置，还可能有编码逻辑。如果需要，还可以为chart安装的应用程序提供单独的许可证。\n\nchart的自述文件README文件应该使用Markdown格式(README.md)，一般应包含：\n\n- chart提供的应用或服务的描述\n- 运行chart的先决条件或要求\n- `values.yaml`的可选项和默认值的描述\n- 与chart的安装或配置相关的其他任何信息\n\n`README.md` 文件会包含hub和用户接口显示的chart的详细信息。\n\nchart也会包含一个简短的纯文本 `templates/NOTES.txt` 文件，这会在安装后及查看版本状态时打印出来。\n这个文件会作为一个 [模板](#templates-and-values)来评估，并用来显示使用说明，后续步骤，或者其他chart版本的相关信息。\n比如，可以提供连接数据库的说明，web UI的访问。由于此文件是在运行`helm install`或`helm status`时打印到STDOUT的，\n因此建议保持内容简短，并指向自述文件以获取更多详细信息。\n\n## Chart dependency\n\nHelm 中，chart可能会依赖其他任意个chart。 这些依赖可以使用`Chart.yaml`文件中的`dependencies`\n字段动态链接，或者被带入到`charts/` 目录并手动配置。\n\n### 使用 `dependencies` 字段管理依赖\n\n当前chart依赖的其他chart会在`dependencies`字段定义为一个列表。\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- `name`字段是你需要的chart的名称\n- `version`字段是你需要的chart的版本\n- `repository`字段是chart仓库的完整URL。注意你必须使用`helm repo add`在本地添加仓库\n- 你可以使用仓库的名称代替URL\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\n一旦你定义好了依赖，运行 `helm dependency update` 就会使用你的依赖文件下载所有你指定的chart到你的`charts/`目录。\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\n当 `helm dependency update` 拉取chart时，会在`charts/`目录中形成一个chart包。因此对于上面的示例，会在chart目录中期望看到以下文件：\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### 依赖的别名字段\n\n除了上面的其他字段之外，每个需求项可以包含一个可选的字段 `alias`。\n为依赖chart添加一个别名，会使用别名作为新依赖chart的名称。\n需要使用其他名称访问chart时可以使用`alias`。\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\n上述例子中，我们会获得`parentchart`所有的3个依赖项：\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\n手动完成的方式是将同一个chart用不同的名称复制/粘贴多次到`charts/`目录中。\n\n#### 依赖中的tag和条件字段\n\n除了上面的其他字段外，每个需求项可以包含可选字段 `tags` 和 `condition`。\n\n所有的chart会默认加载。如果存在 `tags` 或者 `condition` 字段，它们将被评估并用于控制它们应用的chart的加载。\n\nCondition - 条件字段field 包含一个或多个YAML路径（用逗号分隔）。\n如果这个路径在上层values中已存在并解析为布尔值，chart会基于布尔值启用或禁用chart。\n只会使用列表中找到的第一个有效路径，如果路径为未找到则条件无效。\n\nTags - tag字段是与chart关联的YAML格式的标签列表。在顶层value中，通过指定tag和布尔值，可以启用或禁用所有的带tag的chart。\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\n在上面的例子中，所有带 `front-end`tag的chart都会被禁用，但只要上层的value中\n`subchart1.enabled` 路径被设置为 'true'，该条件会覆盖 `front-end`标签且 `subchart1` 会被启用。\n\n一旦 `subchart2`使用了`back-end`标签并被设置为了 `true`，`subchart2`就会被启用。\n也要注意尽管`subchart2` 指定了一个条件字段， 但是上层value没有相应的路径和value，因此这个条件不会生效。\n\n##### 使用带有标签和条件的CLI\n\n`--set` 参数一如既往可以用来设置标签和条件值。\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### 标签和条件的解析\n\n- **条件 （当设置在value中时）总是会覆盖标签** 第一个chart条件路径存在时会忽略后面的路径。\n- 标签被定义为 '如果任意的chart标签是true，chart就可以启用'。\n- 标签和条件值必须被设置在顶层value中。\n- value中的`tags:`键必须是顶层键。 全局和嵌套的`tags:`表现在不支持了。\n\n#### 通过依赖导入子Value\n\n在某些情况下，允许子chart的值作为公共默认传递到父chart中是值得的。使用\n`exports`格式的额外好处是它可是将来的工具可以自检用户可设置的值。\n\n被导入的包含值的key可以在父chart的 `dependencies` 中的 `import-values` 字段以YAML列表形式指定。\n列表中的每一项是从子chart中`exports`字段导入的key。\n\n导入`exports` key中未包含的值，使用[子-父](#using-the-child-parent-format)格式。两种格式的示例如下所述。\n\n##### 使用导出格式\n\n如果子chart的`values.yaml`文件中在根节点包含了`exports`字段，它的内容可以通过指定的可以被直接导入到父chart的value中，\n如下所示：\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\n只要我们再导入列表中指定了键`data`，Helm就会在子chart的`exports`字段查找`data`键并导入它的内容。\n\n最终的父级value会包含我们的导出字段：\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\n注意父级键 `data` 没有包含在父级最终的value中，如果想指定这个父级键，要使用'子-父' 格式。\n\n##### 使用子-父格式 {#using-the-child-parent-format}\n\n要访问子 chart 中未包含的 `exports` 键的值，你需要指定要导入的值的源键（`child`）和父 chart 中值的目标路径（`parent`）。\n\n下面示例中的`import-values` 指示Helm去拿到能在`child:`路径中找到的任何值，并拷贝到`parent:`的指定路径。\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\n上面的例子中，在subchart1里面找到的`default.data`的值会被导入到父chart的`myimports`键中，细节如下：\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\n父chart的结果值将会是这样：\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\n父chart中的最终值包含了从 subchart1中导入的`myint`和`mybool`字段。\n\n### 通过`charts/`目录手动管理依赖\n\n如果对依赖进行更多控制，通过将有依赖关系的chart复制到`charts/`目录中来显式表达这些依赖关系。\n\n依赖应该是一个解压的chart目录。但是名字不能以`_`或`.`开头，否则会被chart加载器忽略。\n\n比如，如果WordPress chart依赖于Apache chart，那么（正确版本的）Apache chart需要放在WordPress chart 的`charts/`目录中：\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\n上面的例子展示了WordPress chart 如何通过将这些chart包含在 `charts/` 目录中来表达它对Apache 和 MySQL的依赖。\n\n**提示：** _要将依赖放入`charts/`目录，使用 `helm pull` 命令_\n\n### 使用依赖的操作部分\n\n上面的部分说明如何指定chart的依赖，但是对使用 `helm install` 和 `helm upgrade` 安装chart有什么影响？\n\n假设有个chart \"A\" 创建了下面的Kubernetes对象：\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\n另外，A是依赖于chart B创建的对象：\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\n安装/升级chart A后，会创建/修改一个单独的Helm版本。这个版本会按顺序创建/升级以下所有的Kubernetes对象：\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\n这是因为当Helm安装/升级chart时，chart中所有的Kubernetes对象以及依赖会\n\n- 聚合成一个单一的集合；然后\n- 按照类型和名称排序；然后\n- 按这个顺序创建/升级。\n\n至此会为chart及其依赖创建一个包含所有对象的release版本。\n\nKubernetes类型的安装顺序会按照kind_sorter.go(查看 [Helm源文件](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go))中给出的枚举顺序进行。\n\n## Templates and Values\n\nHelm Chart 模板是按照[Go模板语言](https://golang.org/pkg/text/template/)书写，\n增加了50个左右的附加模板函数[来自 Sprig库](https://github.com/Masterminds/sprig)\n和一些其他[指定的函数](https://helm.sh/zh/docs/howto/charts_tips_and_tricks)。\n\n所有模板文件存储在chart的 `templates/` 文件夹。\n当Helm渲染chart时，它会通过模板引擎遍历目录中的每个文件。\n\n模板的Value通过两种方式提供：\n\n- Chart开发者可以在chart中提供一个命名为 `values.yaml` 的文件。这个文件包含了默认值。\n- Chart用户可以提供一个包含了value的YAML文件。可以在命令行使用 `helm install`命令时提供。\n\n当用户提供自定义value时，这些value会覆盖chart的`values.yaml`文件中value。\n\n### 模板文件\n\n模板文件遵守书写Go模板的标准惯例（查看[文本/模板 Go 包文档](https://golang.org/pkg/text/template/)了解更多）。\n模板文件的例子看起来像这样：\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n上面的例子，松散地基于[https://github.com/deis/charts](https://github.com/deis/charts)，\n是一个Kubernetes副本控制器的模板。可以使用下面四种模板值（一般被定义在`values.yaml`文件）：\n\n- `imageRegistry`: Docker镜像的源注册表\n- `dockerTag`: Docker镜像的tag\n- `pullPolicy`: Kubernetes的拉取策略\n- `storage`: 后台存储，默认设置为`\"minio\"`\n\n所有的值都是模板作者定义的。Helm不需要或指定参数。\n\n要了解更多chart的工作，请查阅CNCF的 [Artifact Hub](https://artifacthub.io/packages/search?kind=0)。\n\n### 预定义的Values\n\nValues通过模板中`.Values`对象可访问的`values.yaml`文件（或者通过 `--set` 参数)提供，\n但可以模板中访问其他预定义的数据片段。\n\n以下值是预定义的，对每个模板都有效，并且无法被覆盖。和所有值一样，名称 _区分大小写_。\n\n- `Release.Name`: 版本名称(非chart的)\n- `Release.Namespace`: 发布的chart版本的命名空间\n- `Release.Service`: 组织版本的服务\n- `Release.IsUpgrade`: 如果当前操作是升级或回滚，设置为true\n- `Release.IsInstall`: 如果当前操作是安装，设置为true\n- `Chart`: `Chart.yaml`的内容。因此，chart的版本可以从 `Chart.Version` 获得，\n  并且维护者在`Chart.Maintainers`里。\n- `Files`: chart中的包含了非特殊文件的类图对象。这将不允许你访问模板，\n  但是可以访问现有的其他文件（除非被`.helmignore`排除在外）。\n  使用`{{ index .Files \"file.name\" }}`可以访问文件或者使用`{{.Files.Get name }}`功能。\n  你也可以使用`{{ .Files.GetBytes }}`作为`[]byte`访问文件内容。\n- `Capabilities`: 包含了Kubernetes版本信息的类图对象。(`{{ .Capabilities.KubeVersion }}`)\n  和支持的Kubernetes API 版本(`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n**注意：** 任何未知的`Chart.yaml`字段会被抛弃。在`Chart`对象中无法访问。因此，\n`Chart.yaml`不能用于将任意结构的数据传递到模板中。不过values文件可用于此。\n\n### Values文件\n\n考虑到前面部分的模板，`values.yaml`文件提供的必要值如下：\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nvalues文件被定义为YAML格式。chart会包含一个默认的`values.yaml`文件。\nHelm安装命令允许用户使用附加的YAML values覆盖这个values：\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\n以这种方式传递值时，它们会合并到默认的values文件中。比如，`myvals.yaml`文件如下：\n\n```yaml\nstorage: \"gcs\"\n```\n\n当在chart中这个值被合并到`values.yaml`文件中时，生成的内容是这样：\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\n注意只有最后一个字段会覆盖。\n\n**注意：** chart包含的默认values文件 _必须_ 被命名为`values.yaml`。不过在命令行指定的文件可以是其他名称。\n\n**注意：** 如果`helm install`或`helm upgrade`使用了`--set`参数，这些值在客户端会被简单地转换为YAML。\n\n**注意：** 如果values 文件存在任何必需的条目，它们会在chart模板中使用['required'\n函数](https://helm.sh/zh/docs/howto/charts_tips_and_tricks) 声明为必需的。\n\n然后使用模板中的`.Values`对象就可以任意访问这些值了：\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### 范围，依赖和值\n\nValues文件可以声明顶级chart的值，以及`charts/`目录中包含的其他任意chart。\n或者换个说法，values文件可以为chart及其任何依赖项提供值。比如，上面示范的WordPress chart同时有\n`mysql` 和 `apache` 作为依赖。values文件可以为以下所有这些组件提供依赖：\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\n更高阶的chart可以访问下面定义的所有变量。因此WordPress chart可以用`.Values.mysql.password`访问MySQL密码。\n但是低阶的chart不能访问父级chart，所以MySQL无法访问`title`属性。同样也无法访问`apache.port`。\n\nValues 被限制在命名空间中，但是命名空间被删减了。因此对于WordPress chart，\n它可以用`.Values.mysql.password`访问MySQL的密码字段。但是对于MySQL chart，值的范围被缩减了且命名空间前缀被移除了，\n因此它把密码字段简单地看作`.Values.password`。\n\n#### 全局Values\n\n从2.0.0-Alpha.2开始，Helm 支持特殊的\"global\"值。设想一下前面的示例中的修改版本：\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\n上面添加了`global`部分和一个值`app: MyWordPress`。这个值以`.Values.global.app`在 _所有_ chart中有效。\n\n比如，`mysql`模板可以以`{{.Values.global.app}}`访问`app`，同样`apache`chart也可以访问。\n实际上，上面的values文件会重新生成为这样：\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\n这提供了一种和所有的子chart共享顶级变量的方式，这在类似label设置`metadata`属性时会很有用。\n\n如果子chart声明了一个全局变量，那这个变量会 _向下_ 传递（到子chart的子chart），但不会 _向上_ 传递到父级chart。\n子chart无法影响父chart的值。\n\n并且，父chart的全局变量优先于子chart中的全局变量。\n\n### 架构文件 {#schema-files}\n\n有时候，chart容器可能想基于它们的values值定义一个结构，这可以在`values.schema.json`文件中定义一个架构实现。\n架构使用[JSON 架构](https://json-schema.org/)表示。看起来像这样：\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\n这个架构会应用values值并验证它。当执行以下任意命令时会进行验证：\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\n一个符合此架构要求的`values.yaml`文件示例如下所示：\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\n注意这个架构被应用到了最终的 `.Values` 对象，而不仅仅是`values.yaml`文件。\n这意味着下面的`yaml`文件是有效的，给定的chart是用下面显示的适当的`--set`选项安装的：\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\n此外，最终的`.Values`对象是根据*所有的*子chart架构检查。 这意味着父chart无法规避子chart的限制。\n这也是逆向的——如果子 chart 的 `values.yaml` 文件无法满足需求，父 chart *必须*满足这些限制才能有效。\n\n可以通过以下选项禁用架构验证。这在离线环境中特别有用，尤其是当 chart 的 JSON Schema 文件包含远程引用时。\n\n```console\nhelm install --skip-schema-validation\n```\n\n### 参考\n\n在编写模板，值和架构文件时，有几个标准的参考可以帮助你。\n\n- [Go templates](https://godoc.org/text/template)\n- [Extra template functions](https://godoc.org/github.com/Masterminds/sprig)\n- [The YAML format](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## 用户自定义资源(CRD)\n\nKubernetes提供了一种声明Kubernetes新类型对象的机制。使用CustomResourceDefinition（CRD），\nKubernetes开发者可以声明自定义资源类型。\n\nHelm 3中,CRD被视为一种特殊的对象。它们被安装在chart的其他部分之前，并受到一些限制。\n\nCRD YAML文件应被放置在chart的`crds/`目录中。\n多个CRD(用YAML的开始和结束符分隔)可以被放置在同一个文件中。Helm会尝试加载CRD目录中 _所有的_ 文件到Kubernetes。\n\nCRD 文件 _无法模板化_，必须是普通的YAML文档。\n\n当Helm安装新chart时，会上传CRD，暂停安装直到CRD可以被API服务使用，然后启动模板引擎，\n渲染chart其他部分，并上传到Kubernetes。因为这个顺序，CRD信息会在Helm模板中的\n`.Capabilities`对象中生效，并且Helm模板会创建在CRD中声明的新的实例对象。\n\n比如，如果你的chart在`crds/`目录中有针对于`CronTab`的CRD，你可以在`templates/`目录中创建`CronTab`类型实例：\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\n`crontab.yaml`文件必须包含没有模板指令的CRD:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\n然后模板`mycrontab.yaml`可以创建一个新的`CronTab`（照例使用模板）：\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm在安装`templates/`内容之前会保证`CronTab`类型安装成功并对Kubernetes API可用。\n\n### CRD的限制\n\n不像大部分的Kubernetes对象，CRD是全局安装的。因此Helm管理CRD时会采取非常谨慎的方式。\nCRD受到以下限制：\n\n- CRD从不重新安装。 如果Helm确定`crds/`目录中的CRD已经存在（忽略版本），Helm不会安装或升级。\n- CRD从不会在升级或回滚时安装。Helm只会在安装时创建CRD。\n- CRD从不会被删除。自动删除CRD会删除集群中所有命名空间中的所有CRD内容。因此Helm不会删除CRD。\n\n希望升级或删除CRD的操作员应该谨慎地手动执行此操作。\n\n## 使用Helm管理Chart\n\n`helm`工具有一些命令用来处理chart。\n\n它可以为你创建一个新chart：\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\n编辑了chart之后，`helm`能为你把它打包成一个chart存档：\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\n你也可以使用`helm` 帮你找到chart的格式或信息的问题：\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Chart仓库\n\n_chart仓库_ 是一个HTTP服务器，包含了一个或多个打包的chart。当`helm`用来管理本地chart目录时，\n共享chart时，首选的机制就是使用chart仓库。\n\n任何可以服务于YAML文件和tar文件并可以响应GET请求的HTTP服务器都可以用做仓库服务器。\nHelm 团队已经测试了一些服务器，包括激活websit模组的Google Cloud 存储，以及使用website的S3。\n\n仓库的主要特征存在一个名为 `index.yaml` 的特殊文件，文件中包含仓库提供的包的完整列表，\n以及允许检索和验证这些包的元数据。\n\n在客户端，仓库使用`helm repo`命令管理。然而，Helm不提供上传chart到远程仓库的工具。\n这是因为这样做会给执行服务器增加大量的必要条件，也就增加了设置仓库的障碍。\n\n## Chart Starter 包\n\n`helm create` 命令可以附带一个可选的 `--starter` 选项让你指定一个 \"starter chart\"。此外，starter 选项还有一个短别名 `-p`。\n\n用法示例：\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nStarter 就只是普通 chart，但是被放置在 `$XDG_DATA_HOME/helm/starters`。作为一个 chart 开发者，你可以编写专门设计用作 starter 的 chart。设计此类 chart 应注意以下考虑因素：\n\n- `Chart.yaml`会被生成器覆盖。\n- 用户将希望修改此类chart的内容，所以文档应该说明用户如果做到这一点。\n- 所有出现的 `<CHARTNAME>` 都会被替换为指定的 chart 名称，以便 starter chart 可以作为模板使用，但某些变量文件除外。例如，如果你在 `vars` 目录中使用自定义文件或某些 `README.md` 文件，`<CHARTNAME>` 将不会在其中被替换。此外，chart 描述不会被继承。\n\n当前增加一个 chart 到 `$XDG_DATA_HOME/helm/starters` 的唯一方式就是手动复制到该目录。在你的 chart 文档中，你可能需要解释这个过程。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: Chart 钩子\ndescription: 描述如何使用 chart 钩子。\nsidebar_position: 2\n---\n\nHelm 提供了钩子（hook）机制，允许 chart 开发者在 release 生命周期的特定节点进行干预。例如，你可以使用钩子来：\n\n- 在安装过程中，于其他 chart 加载之前先加载一个 ConfigMap 或 Secret。\n- 在安装新 chart 之前执行一个 Job 来备份数据库，然后在升级完成后执行另一个 Job 来恢复数据。\n- 在删除 release 之前执行一个 Job，以便优雅地将服务从轮转中移除。\n\n钩子的工作方式与普通模板类似，但它们带有特殊的注解，使 Helm 以不同方式处理它们。本节介绍钩子的基本使用模式。\n\n## 可用的钩子\n\n定义了以下钩子：\n\n| 注解值           | 描述                                                                                            |\n| ---------------- | ----------------------------------------------------------------------------------------------- |\n| `pre-install`    | 在模板渲染后、Kubernetes 中创建任何资源之前执行                                                   |\n| `post-install`   | 在所有资源加载到 Kubernetes 后执行                                                               |\n| `pre-delete`     | 在删除请求时、从 Kubernetes 删除任何资源之前执行                                                  |\n| `post-delete`    | 在删除请求时、release 的所有资源已删除后执行                                                      |\n| `pre-upgrade`    | 在升级请求时、模板渲染后、任何资源更新之前执行                                                     |\n| `post-upgrade`   | 在升级请求时、所有资源升级完成后执行                                                              |\n| `pre-rollback`   | 在回滚请求时、模板渲染后、任何资源回滚之前执行                                                     |\n| `post-rollback`  | 在回滚请求时、所有资源修改完成后执行                                                              |\n| `test`           | 在调用 Helm test 子命令时执行（[查看 test 文档](/zh/docs/topics/chart_tests/)）                   |\n\n_注意：`crd-install` 钩子已在 Helm 3 中移除，改用 `crds/` 目录。_\n\n## 钩子和 Release 生命周期\n\n钩子允许 chart 开发者在 release 生命周期的关键节点执行操作。例如，考虑 `helm install` 的生命周期。默认情况下，生命周期如下：\n\n1. 用户运行 `helm install foo`\n2. 调用 Helm 库的安装 API\n3. 经过一些验证后，库渲染 `foo` 的模板\n4. 库将生成的资源加载到 Kubernetes\n5. 库将 release 对象（和其他数据）返回给客户端\n6. 客户端退出\n\nHelm 为 `install` 生命周期定义了两个钩子：`pre-install` 和 `post-install`。如果 `foo` chart 的开发者实现了这两个钩子，生命周期会变成这样：\n\n1. 用户运行 `helm install foo`\n2. 调用 Helm 库的安装 API\n3. 安装 `crds/` 目录中的 CRD\n4. 经过一些验证后，库渲染 `foo` 的模板\n5. 库准备执行 `pre-install` 钩子（将钩子资源加载到 Kubernetes）\n6. 库按权重对钩子排序（默认权重为 0），然后按资源类型排序，最后按名称升序排列\n7. 库先加载权重最小的钩子（从负到正）\n8. 库等待钩子进入 \"Ready\" 状态（CRD 除外）\n9. 库将生成的资源加载到 Kubernetes。注意，如果设置了 `--wait` 参数，库会等待所有资源进入就绪状态，并且在资源就绪之前不会执行 `post-install` 钩子。\n10. 库执行 `post-install` 钩子（加载钩子资源）\n11. 库等待钩子进入 \"Ready\" 状态\n12. 库将 release 对象（和其他数据）返回给客户端\n13. 客户端退出\n\n等待钩子就绪是什么意思？这取决于钩子中声明的资源类型。如果资源是 `Job` 或 `Pod` 类型，Helm 会等待它成功运行完成。如果钩子失败，release 也会失败。这是一个*阻塞操作*，因此 Helm 客户端会在 Job 运行期间暂停。\n\n对于其他类型的资源，一旦 Kubernetes 将资源标记为已加载（已添加或已更新），该资源就被视为 \"Ready\"。当一个钩子中声明了多个资源时，这些资源会串行执行。如果它们有钩子权重（见下文），则按权重顺序执行。从 Helm 3.2.0 开始，具有相同权重的钩子资源会按照与普通非钩子资源相同的顺序安装。否则，执行顺序不做保证。（在 Helm 2.3.0 及之后版本中，它们按字母顺序排序。但这一行为并非强制绑定，未来可能会改变。）最佳实践是添加钩子权重，如果权重不重要则设为 `0`。\n\n### 钩子资源不随对应 release 管理\n\n钩子创建的资源目前不作为 release 的一部分进行跟踪或管理。一旦 Helm 确认钩子已达到就绪状态，就不再管理该钩子资源。在未来的 Helm 3 版本中可能会添加删除对应 release 时的钩子资源垃圾回收功能，因此任何不能被删除的钩子资源都应该添加注解 `helm.sh/resource-policy: keep`。\n\n实际上，这意味着如果你在钩子中创建了资源，就不能依赖 `helm uninstall` 来删除这些资源。要销毁这些资源，你需要在钩子模板文件中[添加自定义的 `helm.sh/hook-delete-policy` 注解](#钩子删除策略)，或者[设置 Job 资源的生存时间（TTL）字段](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/)。\n\n## 编写钩子\n\n钩子就是在 `metadata` 部分带有特殊注解的 Kubernetes 清单文件。由于它们是模板文件，你可以使用所有常规的模板功能，包括读取 `.Values`、`.Release` 和 `.Template`。\n\n例如，下面这个存储在 `templates/post-install-job.yaml` 中的模板，声明了一个在 `post-install` 时运行的 Job：\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\n使这个模板成为钩子的是以下注解：\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\n一个资源可以实现多个钩子：\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\n同样，实现某个钩子的资源数量也没有限制。例如，可以同时将一个 Secret 和一个 ConfigMap 声明为 pre-install 钩子。\n\n当子 chart 声明钩子时，这些钩子也会被执行。顶级 chart 无法禁用子 chart 声明的钩子。\n\n可以为钩子定义权重，以帮助建立确定性的执行顺序。权重使用以下注解定义：\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\n钩子权重可以是正数或负数，但必须以字符串形式表示。当 Helm 开始执行特定类型的钩子时，会按升序对这些钩子进行排序。\n\n### 钩子删除策略\n\n可以定义策略来决定何时删除对应的钩子资源。钩子删除策略使用以下注解定义：\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\n你可以选择一个或多个已定义的注解值：\n\n| 注解值                 | 描述                                            |\n| ---------------------- | ----------------------------------------------- |\n| `before-hook-creation` | 在启动新钩子之前删除之前的资源（默认）             |\n| `hook-succeeded`       | 在钩子成功执行后删除资源                          |\n| `hook-failed`          | 如果钩子执行失败，删除资源                        |\n\n如果未指定钩子删除策略注解，则默认使用 `before-hook-creation` 行为。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/index.mdx",
    "content": "---\ntitle: 主题\nsidebar_position: 3\n---\n\n# 主题指引\n\n这里可以找到所有您想知道的Helm的关键部分说明。\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: \"弃用的 Kubernetes API\"\ndescription: \"介绍 Helm 中与 Kubernetes API 弃用相关的问题\"\n---\n\nKubernetes 是一个 API 驱动的系统，API 会随着时间推移而不断演进，以反映对问题理解的深入。这是系统及其 API 的常见做法。API 演进的一个重要组成部分是完善的弃用策略和通知机制，用于告知用户 API 的变更。换句话说，API 使用者需要提前知道在哪个版本中某个 API 会被移除或变更。这可以避免意外的破坏性变更对使用者造成影响。\n\n[Kubernetes 弃用策略](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)文档描述了 Kubernetes 如何处理 API 版本的变化。弃用策略规定了在发布弃用公告后，API 版本将被支持的时间范围。因此，关注弃用公告并了解 API 何时被移除非常重要，有助于将影响降到最低。\n\n以下是一个公告示例：[Kubernetes 1.16 中弃用的 API 版本](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/)，在该版本发布的几个月之前就已公布。在此之前，这些 API 版本可能已经被标记为弃用。这说明 Kubernetes 有一套良好的策略来通知使用者 API 版本的支持情况。\n\nHelm 模板在定义 Kubernetes 对象时需要指定一个 [Kubernetes API 组](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)，与 Kubernetes manifest 文件类似。API 版本在模板的 `apiVersion` 字段中指定，用于标识 Kubernetes 对象的 API 版本。这意味着 Helm 用户和 chart 维护者需要关注 Kubernetes API 版本的弃用时间，以及会在哪个 Kubernetes 版本中被移除。\n\n## Chart 维护者\n\n你应该审核 chart，检查是否使用了已弃用或已移除的 Kubernetes API 版本。如果发现不再支持的 API 版本，应更新为受支持的版本并发布新的 chart 版本。API 版本由 `kind` 和 `apiVersion` 字段定义。例如，以下是 Kubernetes 1.16 中被移除的 `Deployment` 对象 API 版本：\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Helm 用户\n\n你应该审核所使用的 chart（类似于 [chart 维护者](#chart-维护者)的做法），识别其中使用了已弃用或已移除 API 版本的 chart。对于这些 chart，需要检查是否有使用受支持 API 版本的新版本，或者自行更新。\n\n此外，你还需要审核已部署的 chart（即 Helm release），检查是否存在已弃用或已移除的 API 版本。可以使用 `helm get manifest` 命令获取 release 的详细信息。\n\n将 Helm release 更新为受支持的 API 版本，具体操作取决于你的发现：\n\n1. 如果只发现弃用（但尚未移除）的 API 版本：\n    - 执行 `helm upgrade`，使用包含受支持 Kubernetes API 版本的 chart\n    - 在升级描述中添加说明，提示不要回滚到此版本之前的 Helm release\n\n2. 如果发现在某个 Kubernetes 版本中已被移除的 API 版本：\n    - 如果你运行的 Kubernetes 版本中该 API 版本仍然可用（例如，你当前使用 Kubernetes 1.15，但发现使用的 API 将在 1.16 中被移除）：\n      - 按照步骤 1 的流程操作\n    - 否则（例如，你当前运行的 Kubernetes 版本中，`helm get manifest` 显示的某些 API 版本已不可用）：\n      - 需要编辑存储在集群中的 release manifest，将 API 版本更新为受支持的版本。详见[更新 release manifest 的 API 版本](#更新-release-manifest-的-api-版本)\n\n> 注意：在所有将 Helm release 更新为受支持 API 的场景中，都不应该将 release 回滚到包含受支持 API 版本的 release 之前的版本。\n\n> 建议：最佳实践是在升级到移除这些 API 的 Kubernetes 集群版本之前，先将使用弃用 API 版本的 release 升级为受支持的 API 版本。\n\n如果没有按照上述建议更新 release，在 API 版本已被移除的 Kubernetes 版本中尝试升级 release 时，会出现类似以下的错误：\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm 在这种情况下会失败，因为它尝试在当前已部署的 release（包含在此 Kubernetes 版本中已移除的 API）与你传入的使用更新/受支持 API 版本的 chart 之间创建差异补丁。失败的根本原因是：当 Kubernetes 移除某个 API 版本后，Kubernetes Go 客户端库将无法解析使用弃用 API 的对象，因此 Helm 在调用该库时会失败。不幸的是，Helm 无法从这种情况中恢复，也无法继续管理这样的 release。有关如何从这种情况中恢复的详细信息，请参阅[更新 release manifest 的 API 版本](#更新-release-manifest-的-api-版本)。\n\n## 更新 release manifest 的 API 版本\n\nmanifest 是 Helm release 对象的一个属性，存储在集群中 Secret（默认）或 ConfigMap 的 data 字段中。data 字段包含一个经过 gzip 压缩并使用 base64 编码的对象（如果是 Secret，还会有额外的一层 base64 编码）。在 release 所在的命名空间中，每个 release 版本/修订都对应一个 Secret 或 ConfigMap。\n\n你可以使用 Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) 插件来将 release 更新为受支持的 API。详情请查看该插件的 readme 文档。\n\n或者，你可以按照以下手动步骤更新 release manifest 的 API 版本。根据你的配置，选择 Secret 或 ConfigMap 后端对应的步骤。\n\n- 获取与最新部署的 release 关联的 Secret 或 ConfigMap 名称：\n  - Secret 后端：`kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - ConfigMap 后端：`kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- 获取最新部署 release 的详细信息：\n  - Secret 后端：`kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - ConfigMap 后端：`kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- 备份 release 以便出错时恢复：\n  - `cp release.yaml release.bak`\n  - 紧急情况下恢复：`kubectl apply -f release.bak -n\n    <release_namespace>`\n- 解码 release 对象：\n  - Secret 后端：`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - ConfigMap 后端：`cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- 修改 manifest 中的 API 版本。可以使用任意工具（如编辑器）进行修改。API 版本位于解码后的 release 对象 (`release.data.decoded`) 的 `manifest` 字段中\n- 编码 release 对象：\n  - Secret 后端：`cat release.data.decoded | gzip | base64 | base64`\n  - ConfigMap 后端：`cat release.data.decoded | gzip | base64`\n- 用新编码的 release 对象替换部署文件 (`release.yaml`) 中 `data.release` 属性的值\n- 将文件应用到命名空间：`kubectl apply -f release.yaml -n\n  <release_namespace>`\n- 使用包含受支持 Kubernetes API 版本的 chart 执行 `helm upgrade`\n- 在升级描述中添加说明，提示不要回滚到此版本之前的版本\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: Kubernetes 发行版指南\ndescription: 介绍在特定 Kubernetes 环境中使用 Helm 的相关信息。\nsidebar_position: 10\n---\n\nHelm 可以在任何[符合标准的 Kubernetes 版本](https://github.com/cncf/k8s-conformance)上运行（无论是否经过[认证](https://www.cncf.io/certification/software-conformance/)）。\n\n本文档介绍在特定 Kubernetes 环境中使用 Helm 的相关信息。如有需要，欢迎补充更多发行版的详细信息（按字母顺序排列）。\n\n\n## AKS\n\nHelm 可以在 [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm) 上使用。\n\n## DC/OS\n\nHelm 已在 Mesosphere DC/OS 1.11 Kubernetes 平台上测试通过，无需额外配置。\n\n## EKS\n\nHelm 可以在 Amazon Elastic Kubernetes Service (Amazon EKS) 上使用：[在 Amazon EKS 上使用 Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)。\n\n## GKE\n\nGoogle 的 GKE 托管 Kubernetes 平台可以正常使用 Helm，无需额外配置。\n\n## `scripts/local-cluster` 和 Hyperkube\n\n通过 `scripts/local-cluster.sh` 配置的 Hyperkube 可以正常使用。对于原始 Hyperkube，可能需要进行一些手动配置。\n\n## IKS\n\nHelm 可以在 [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm) 上使用。\n\n## KIND (Kubernetes IN Docker)\n\nHelm 会定期在 [KIND](https://github.com/kubernetes-sigs/kind) 上进行测试。\n\n## KubeOne\n\nHelm 可以在 KubeOne 配置的集群中正常使用，无需特殊配置。\n\n## Kubermatic\n\nHelm 可以在 Kubermatic 创建的用户集群中正常使用，无需特殊配置。由于种子集群的配置方式可能不同，Helm 的支持情况取决于具体配置。\n\n## MicroK8s\n\n可以使用以下命令在 [MicroK8s](https://microk8s.io) 中启用 Helm：`microk8s.enable helm3`\n\n## Minikube\n\nHelm 已在 [Minikube](https://github.com/kubernetes/minikube) 上测试通过，无需额外配置。\n\n## Openshift\n\nHelm 可以在 OpenShift Online、OpenShift Dedicated、OpenShift Container Platform（版本 >= 3.6）或 OpenShift Origin（版本 >= 3.6）上直接使用。更多信息请参阅[这篇博客文章](https://blog.openshift.com/getting-started-helm-openshift/)。\n\n## Platform9\n\nHelm 已预装在 [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)。\n\n## 使用 `kubeadm` 的 Ubuntu\n\n通过 `kubeadm` 引导的 Kubernetes 可以在以下 Linux 发行版上正常运行：\n\n- Ubuntu 16.04\n- Fedora release 25\n\n某些 Helm 版本（v2.0.0-beta2）需要执行 `export KUBECONFIG=/etc/kubernetes/admin.conf` 或创建 `~/.kube/config` 文件。\n\n## VMware Tanzu Kubernetes Grid\n\nHelm 可以在 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)部分。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: 库 chart\ndescription: 介绍库 chart 及其使用示例\nsidebar_position: 4\n---\n\n库 chart 是一种 [Helm chart](./charts.md)，用于定义可供其他 chart 中的 Helm 模板共享的 chart 原语或定义。这使用户可以共享可复用的代码片段，避免重复，保持 chart [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)。\n\n库 chart 在 Helm 3 中引入，正式承认了自 Helm 2 以来 chart 维护者一直使用的通用或辅助 chart。将其作为一种 chart 类型引入，可以提供：\n\n- 明确区分通用 chart 和应用 chart 的方法\n- 阻止安装通用 chart 的逻辑\n- 通用 chart 中的模板不会被渲染，这些模板可能包含 release 相关的内容\n- 允许依赖的 chart 使用导入者的上下文\n\nchart 维护者可以将通用 chart 定义为库，Helm 会以标准、一致的方式处理该 chart。这也意味着可以通过更改 chart 类型来共享应用 chart 中的定义。\n\n## 创建简单的库 chart\n\n如前所述，库 chart 是一种 [Helm chart](./charts.md) 类型。这意味着你可以从创建脚手架 chart 开始：\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\n首先删除 `templates` 目录中的所有文件，因为我们将在本示例中创建自己的模板定义。\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nvalues 文件也不需要。\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\n在创建通用代码之前，先快速回顾一些相关的 Helm 概念。[命名模板](../chart_template_guide/named_templates.md)（有时称为局部模板或子模板）是定义在文件中并赋予名称的简单模板。在 `templates/` 目录中，任何以下划线（_）开头的文件都不会输出 Kubernetes 清单文件。因此按照惯例，辅助模板和局部模板放在 `_*.tpl` 或 `_*.yaml` 文件中。\n\n在本示例中，我们将编写一个通用的 ConfigMap，用于创建空的 ConfigMap 资源。在 `mylibchart/templates/_configmap.yaml` 文件中定义如下：\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nConfigMap 结构定义在名为 `mylibchart.configmap.tpl` 的命名模板中。这是一个简单的 ConfigMap，`data` 为空资源。该文件中还有另一个命名模板 `mylibchart.configmap`，它包含另一个命名模板 `mylibchart.util.merge`，该模板接受 2 个命名模板作为参数：调用 `mylibchart.configmap` 的模板和 `mylibchart.configmap.tpl`。\n\n辅助函数 `mylibchart.util.merge` 是 `mylibchart/templates/_util.yaml` 文件中的一个命名模板。这是来自[通用 Helm 辅助 chart](#通用-helm-辅助-chart) 的实用工具，因为它可以合并两个模板并覆盖两者的公共部分：\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\n当 chart 需要使用通用代码并通过配置进行自定义时，这一点非常重要。\n\n最后，将 chart 类型更改为 `library`。需要按如下方式编辑 `mylibchart/Chart.yaml`：\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\n库 chart 现在可以共享了，其 ConfigMap 定义可以被复用。\n\n在继续之前，值得检查一下 Helm 是否将该 chart 识别为库 chart：\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## 使用简单的库 chart\n\n现在可以使用库 chart 了。这意味着需要再次创建一个脚手架 chart：\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n因为我们只想创建一个 ConfigMap，所以再次清空模板文件：\n\n```console\n$ rm -rf mychart/templates/*\n```\n\n在 Helm 模板中创建简单的 ConfigMap 时，看起来类似这样：\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\n然而，我们将复用已在 `mylibchart` 中创建的通用代码。可以在 `mychart/templates/configmap.yaml` 文件中创建 ConfigMap，如下所示：\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\n可以看到，通过继承为 ConfigMap 添加标准属性的通用定义，简化了我们的工作。在模板中添加了配置，本例中是数据键 `myvalue` 及其值。该配置会覆盖通用 ConfigMap 的空资源。这得益于我们在上一节中提到的辅助函数 `mylibchart.util.merge`。\n\n为了能使用通用代码，需要添加 `mylibchart` 作为依赖。在 `mychart/Chart.yaml` 文件末尾添加以下内容：\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\n这将库 chart 作为动态依赖包含进来，它位于文件系统中与应用 chart 相同的父路径下。由于将库 chart 作为动态依赖包含，需要运行 `helm dependency update`。它会将库 chart 复制到你的 `charts/` 目录。\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\n现在可以部署 chart 了。安装之前，值得先检查渲染后的模板。\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\n这看起来正是我们需要的 ConfigMap，数据已被覆盖为 `myvalue: Hello World`。现在安装它：\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\n我们可以检索该 release 并查看实际加载的模板。\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## 库 chart 的优势\n\n由于库 chart 无法作为独立 chart 使用，它们可以利用以下功能：\n\n- `.Files` 对象引用父 chart 的文件路径，而不是库 chart 的本地路径\n- `.Values` 对象与父 chart 相同，与应用[子 chart](../chart_template_guide/subcharts_and_globals.md) 不同（子 chart 接收在父 chart 中其标题下配置的值部分）\n\n## 通用 Helm 辅助 chart\n\n```markdown\n注意：GitHub 上的通用 Helm 辅助 chart 仓库已不再积极维护，该仓库已被弃用并归档。\n```\n\n这个 [chart](https://github.com/helm/charts/tree/master/incubator/common) 是通用 chart 的原始模式。它提供了反映 Kubernetes chart 开发最佳实践的实用工具。最棒的是，在开发 chart 时可以直接使用这些便捷的共享代码。\n\n以下是快速使用它的方法。更多详细信息，请查看 [README](https://github.com/helm/charts/blob/master/incubator/common/README.md)。\n\n再次创建一个脚手架 chart：\n\n```console\n$ helm create demo\nCreating demo\n```\n\n使用辅助 chart 中的通用代码。首先，按如下方式编辑 Deployment 文件 `demo/templates/deployment.yaml`：\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\n然后是 Service 文件 `demo/templates/service.yaml`，如下所示：\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\n这些模板展示了如何通过从辅助 chart 继承通用代码，将你的代码简化为仅包含资源的配置或自定义部分。\n\n为了能使用通用代码，需要添加 `common` 作为依赖。在 `demo/Chart.yaml` 文件末尾添加以下内容：\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\n注意：需要将 `incubator` 仓库添加到 Helm 仓库列表中（`helm repo add`）。\n\n由于将该 chart 作为动态依赖包含，需要运行 `helm dependency update`。这会将辅助 chart 复制到你的 `charts/` 目录。\n\n由于辅助 chart 使用了一些 Helm 2 的结构，需要在 `demo/values.yaml` 中添加以下内容，以便在 Helm 3 脚手架 chart 更新后能够加载 `nginx` 镜像：\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\n在部署之前，可以使用 `helm lint` 和 `helm template` 命令测试 chart 模板是否正确。\n\n如果一切正常，使用 `helm install` 进行部署！\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: \"SQL 存储后端的权限管理\"\ndescription: \"了解如何在使用 SQL 存储后端时设置权限\"\n---\n\n本文档旨在指导用户在使用 SQL 存储后端时如何设置和管理权限。\n\n## 介绍\n\nHelm 利用 Kubernetes 的 RBAC 特性来处理权限。但在使用 SQL 存储后端时，无法使用 Kubernetes 的角色来判断用户是否可以访问特定资源。本文档将展示如何创建和管理这些权限。\n\n## 初始化\n\nHelm CLI 首次连接数据库时，客户端会检查数据库是否已完成初始化。如果尚未初始化，客户端会自动完成必要的设置。初始化过程需要 public 模式（schema）的管理员权限，或者至少能够：\n\n* 创建表\n* 在 public 模式上授予权限\n\n数据库完成迁移后，其他角色就可以使用客户端了。\n\n## 在 PostgreSQL 中向非管理员用户授权\n\nSQL 后端驱动使用 PostgreSQL 的 [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)（行级安全）特性来管理权限。RLS 允许所有用户对同一张表进行读写操作，但在未获得明确授权的情况下，无法操作相同的行。默认情况下，未被明确授予相应权限的角色在运行 `helm list` 时会返回空列表，也无法检索或修改集群中的任何资源。\n\n下面介绍如何为指定角色授予访问特定命名空间的权限：\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\n此命令会将满足 `namespace = 'default'` 条件的所有资源的读写权限授予角色 `role`。创建该策略后，以角色 `role` 身份连接数据库的用户在运行 `helm list` 时就能看到 `default` 命名空间中的所有 release，并可以对其进行修改和删除。\n\nRLS 支持细粒度的权限管理。你可以根据表的不同列来限制访问权限：\n\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/plugins.md",
    "content": "---\ntitle: Helm 插件指南\ndescription: 介绍如何使用和创建插件来扩展 Helm 功能。\nsidebar_position: 12\n---\n\nHelm 插件是一个可以通过 `helm` CLI 访问的工具，但不是 Helm 的内置代码。\n\n已有插件可以在 [相关项目](/community/related#helm-plugins) 部分找到，也可以搜索 [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)。\n\n本指南介绍如何使用和创建插件。\n\n## 概述\n\nHelm 插件是与 Helm 无缝集成的附加工具。插件提供一种扩展 Helm 核心特性集的方法，但不需要每个新的特性都用 Go 编写并加入核心工具中。\n\nHelm 插件有以下特性：\n\n- 可以在不影响 Helm 核心工具的情况下添加和移除。\n- 可以用任意编程语言编写。\n- 与 Helm 集成，并展示在 `helm help` 和其他地方。\n\nHelm 插件位于 `$HELM_PLUGINS`。你可以使用 `helm env` 命令找到该变量的当前值，包括未在环境中设置时的默认值。\n\nHelm 插件模型部分基于 Git 的插件模型。为此，你有时可能听到 `helm` 被称为 _porcelain_ 层，而插件是 _plumbing_ 层。这是一种简写方式，表示 Helm 提供用户体验和顶层处理逻辑，而插件执行所需操作的\"细节工作\"。\n\n## 安装插件\n\n使用 `helm plugin install <path|url>` 命令安装插件。你可以传入本地文件系统上的插件路径或远程 VCS 仓库的 URL。`helm plugin install` 命令会将给定路径/URL 的插件克隆或复制到 `$HELM_PLUGINS`。如果从 VCS 安装，可以使用 `--version` 参数指定版本。\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\n如果是插件 tar 包，只需将插件解压到 `$HELM_PLUGINS` 目录。也可以直接从 URL 安装 tar 包插件：`helm plugin install https://domain/path/to/plugin.tar.gz`\n\n## 插件文件结构\n\n在很多方面，插件类似于 chart。每个插件都有一个包含 `plugin.yaml` 文件的顶级目录。可能存在其他文件，但只有 `plugin.yaml` 文件是必需的。\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## plugin.yaml 文件\n\nplugin.yaml 文件是插件的必需文件。它包含以下字段：\n\n```yaml\nname: 插件名称（必需）\nversion: SemVer 2 版本号（必需）\nusage: 在帮助中显示的单行使用说明\ndescription: 在 helm help 等位置显示的详细描述\nignoreFlags: 忽略从 Helm 传入的参数\nplatformCommand: # 根据平台配置要执行的命令\n  - os: 操作系统匹配，可以为空或省略以匹配所有操作系统\n    arch: 架构匹配，可以为空或省略以匹配所有架构\n    command: 要执行的插件命令\n    args: 插件命令参数\ncommand: （已弃用）插件命令，请改用 platformCommand\nplatformHooks: # 根据平台配置插件生命周期钩子\n  install: # 安装生命周期命令\n    - os: 操作系统匹配，可以为空或省略以匹配所有操作系统\n      arch: 架构匹配，可以为空或省略以匹配所有架构\n      command: 要执行的插件安装命令\n      args: 插件安装命令参数\n  update: # 更新生命周期命令\n    - os: 操作系统匹配，可以为空或省略以匹配所有操作系统\n      arch: 架构匹配，可以为空或省略以匹配所有架构\n      command: 要执行的插件更新命令\n      args: 插件更新命令参数\n  delete: # 删除生命周期命令\n    - os: 操作系统匹配，可以为空或省略以匹配所有操作系统\n      arch: 架构匹配，可以为空或省略以匹配所有架构\n      command: 要执行的插件删除命令\n      args: 插件删除命令参数\nhooks: # （已弃用）插件生命周期钩子，请改用 platformHooks\n  install: 安装插件的命令\n  update: 更新插件的命令\n  delete: 删除插件的命令\ndownloaders: # 配置下载器能力\n  - command: 要调用的命令\n    protocols:\n      - 支持的协议方案\n```\n\n### `name` 字段\n\n`name` 是插件的名称。当 Helm 执行此插件时使用此名称（例如，`helm NAME` 会调用此插件）。\n\n_`name` 应该匹配目录名称。_ 在上面的例子中，这意味着 `name: last` 的插件应该包含在名为 `last` 的目录中。\n\n`name` 的限制：\n\n- `name` 不能与现有的 `helm` 顶级命令重复。\n- `name` 的字符必须限制为 ASCII a-z、A-Z、0-9、`_` 和 `-`。\n\n### `version` 字段\n\n`version` 是插件的 SemVer 2 版本。`usage` 和 `description` 都用于生成命令的帮助文本。\n\n### `ignoreFlags` 字段\n\n`ignoreFlags` 开关告诉 Helm _不要_ 将参数传递给插件。因此，如果插件使用 `helm myplugin --foo` 调用且 `ignoreFlags: true`，那么 `--foo` 会被静默丢弃。\n\n### `platformCommand` 字段\n\n`platformCommand` 配置插件被调用时将执行的命令。你不能同时设置 `platformCommand` 和 `command`，否则会导致错误。以下规则用于决定使用哪个命令：\n\n- 如果 `platformCommand` 存在，它将被使用。\n  - 如果 `os` 和 `arch` 都匹配当前平台，搜索将停止并使用该命令。\n  - 如果 `os` 匹配且 `arch` 为空，将使用该命令。\n  - 如果 `os` 和 `arch` 都为空，将使用该命令。\n  - 如果没有匹配，Helm 会报错退出。\n- 如果 `platformCommand` 不存在但已弃用的 `command` 存在，将使用 `command`。\n  - 如果命令为空，Helm 会报错退出。\n\n### `platformHooks` 字段\n\n`platformHooks` 配置插件针对生命周期事件将执行的命令。你不能同时设置 `platformHooks` 和 `hooks`，否则会导致错误。以下规则用于决定使用哪个钩子命令：\n\n- 如果 `platformHooks` 存在，它将被使用，并处理生命周期事件的命令。\n  - 如果 `os` 和 `arch` 都匹配当前平台，搜索将停止并使用该命令。\n  - 如果 `os` 匹配且 `arch` 为空，将使用该命令。\n  - 如果 `os` 和 `arch` 都为空，将使用该命令。\n  - 如果没有匹配，Helm 将跳过该事件。\n- 如果 `platformHooks` 不存在但已弃用的 `hooks` 存在，将使用生命周期事件的命令。\n  - 如果命令为空，Helm 将跳过该事件。\n\n## 构建插件\n\n下面是一个简单插件的 YAML，用于获取最后一个 release 名称：\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\n插件可能需要额外的脚本和可执行文件。脚本可以包含在插件目录中，可执行文件可以通过钩子下载。以下是一个示例插件：\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\n环境变量会在插件执行前被插值。上述模式说明了表示插件程序所在位置的首选方法。\n\n### 插件命令\n\n以下是使用插件命令的一些策略：\n\n- 如果插件包含可执行文件，`platformCommand:` 的可执行文件应该打包在插件目录中或通过钩子安装。\n- `platformCommand:` 或 `command:` 行会在执行前展开所有环境变量。`$HELM_PLUGIN_DIR` 会指向插件目录。\n- 命令本身不是在 shell 中执行的。所以你不能写成一行 shell 脚本。\n- Helm 在环境变量中注入了大量配置。查看环境变量以了解可用信息。\n- Helm 对插件的语言不做任何假设。你可以用任何你喜欢的语言编写。\n- 命令负责实现 `-h` 和 `--help` 的特定帮助文本。Helm 会在 `helm help` 和 `helm help myplugin` 中使用 `usage` 和 `description`，但不会处理 `helm myplugin --help`。\n\n### 测试本地插件\n\n首先你需要找到你的 `HELM_PLUGINS` 路径，运行以下命令：\n\n``` bash\nhelm env\n```\n\n切换到 `HELM_PLUGINS` 设置的目录。\n\n现在你可以添加一个指向插件构建输出的符号链接，在这个例子中我们为 `mapkubeapis` 创建链接。\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## 下载器插件\n\n默认情况下，Helm 可以使用 HTTP/S 拉取 Chart。从 Helm 2.4.0 开始，插件有一种特殊能力可以从任意来源下载 Chart。\n\n插件应该在 `plugin.yaml` 文件（顶层）中声明这个特殊能力：\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\n如果安装了这样的插件，Helm 可以通过调用 `command` 使用指定的协议方案与仓库进行交互。特殊仓库的添加与常规仓库类似：`helm repo add favorite myprotocol://example.com/`。特殊仓库的规则与常规仓库相同：Helm 必须能够下载 `index.yaml` 文件以发现和缓存可用 Chart 的列表。\n\n已定义的命令将使用以下格式调用：`command certFile keyFile caFile full-URL`。SSL 证书来自仓库定义，存储在 `$HELM_REPOSITORY_CONFIG`（即 `$HELM_CONFIG_HOME/repositories.yaml`）。下载器插件应将原始内容输出到 stdout，并在 stderr 报告错误。\n\n下载器命令也支持子命令或参数，允许你在 `plugin.yaml` 中指定，例如 `bin/mydownloader subcommand -d`。如果你想为主插件命令和下载器命令使用相同的可执行文件，但每个使用不同的子命令，这将非常有用。\n\n## 环境变量\n\n当 Helm 执行插件时，会将外部环境传递给插件，并且会注入一些额外的环境变量。\n\n像 `KUBECONFIG` 这样的变量，如果在外部环境中设置了，则会为插件设置。\n\n以下变量保证会被设置：\n\n- `HELM_PLUGINS`：插件目录的路径。\n- `HELM_PLUGIN_NAME`：由 `helm` 调用的插件名称。所以 `helm myplug` 的短名称是 `myplug`。\n- `HELM_PLUGIN_DIR`：包含插件的目录。\n- `HELM_BIN`：`helm` 命令的路径（如用户执行的那样）。\n- `HELM_DEBUG`：表示 helm 是否设置了 debug 标志。\n- `HELM_REGISTRY_CONFIG`：注册表配置的位置（如果使用）。注意，Helm 与注册表的使用是实验性功能。\n- `HELM_REPOSITORY_CACHE`：仓库缓存文件的路径。\n- `HELM_REPOSITORY_CONFIG`：仓库配置文件的路径。\n- `HELM_NAMESPACE`：给 `helm` 命令的命名空间（通常使用 `-n` 标志）。\n- `HELM_KUBECONTEXT`：给 `helm` 命令的 Kubernetes 配置上下文名称。\n\n另外，如果明确指定了 Kubernetes 配置文件，它将被设置为 `KUBECONFIG` 变量。\n\n## 参数解析说明\n\n当执行插件时，Helm 会解析全局标志供自己使用。这些标志都不会传递给插件。\n- `--burst-limit`：转换为 `$HELM_BURST_LIMIT`\n- `--debug`：如果指定，`$HELM_DEBUG` 设置为 `1`\n- `--kube-apiserver`：转换为 `$HELM_KUBEAPISERVER`\n- `--kube-as-group`：转换为 `$HELM_KUBEASGROUPS`\n- `--kube-as-user`：转换为 `$HELM_KUBEASUSER`\n- `--kube-ca-file`：转换为 `$HELM_KUBECAFILE`\n- `--kube-context`：转换为 `$HELM_KUBECONTEXT`\n- `--kube-insecure-skip-tls-verify`：转换为 `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`\n- `--kube-tls-server-name`：转换为 `$HELM_KUBETLS_SERVER_NAME`\n- `--kube-token`：转换为 `$HELM_KUBETOKEN`\n- `--kubeconfig`：转换为 `$KUBECONFIG`\n- `--namespace` 和 `-n`：转换为 `$HELM_NAMESPACE`\n- `--qps`：转换为 `$HELM_QPS`\n- `--registry-config`：转换为 `$HELM_REGISTRY_CONFIG`\n- `--repository-cache`：转换为 `$HELM_REPOSITORY_CACHE`\n- `--repository-config`：转换为 `$HELM_REPOSITORY_CONFIG`\n\n插件 _应该_ 对 `-h` 和 `--help` 显示帮助文本然后退出。在所有其他情况下，插件可以根据需要使用参数。\n\n## 提供 shell 自动补全\n\n从 Helm 3.2 开始，作为 Helm 现有自动补全机制的一部分，插件可以选择性地提供 shell 自动补全支持。\n\n### 静态自动补全\n\n如果插件提供了自己的标志和/或子命令，可以通过在插件根目录中放置 `completion.yaml` 文件来通知 Helm。`completion.yaml` 文件格式如下：\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <以此类推，递归>\n```\n\n注意：\n\n1. 所有部分都是可选的，但应在适用时提供。\n2. 标志不应包含 `-` 或 `--` 前缀。\n3. 可以且应该指定短标志和长标志。短标志不需要与其对应的长格式关联，但两种形式都应列出。\n4. 标志不需要以任何方式排序，但需要列在文件子命令层次结构的正确位置。\n5. Helm 现有的全局标志已由 Helm 的自动补全机制处理，因此插件不需要指定以下标志：`--debug`、`--namespace` 或 `-n`、`--kube-context` 和 `--kubeconfig`，或任何其他全局标志。\n6. `validArgs` 列表提供了子命令后第一个参数的可能补全的静态列表。并非总是能事先提供这样的列表（参见下面的[动态补全](#动态补全)部分），在这种情况下可以省略 `validArgs` 部分。\n\n`completion.yaml` 文件是完全可选的。如果没有提供，Helm 将不会为插件提供 shell 自动补全功能（除非插件支持[动态补全](#动态补全)）。另外，添加 `completion.yaml` 文件是向后兼容的，不会影响在旧版 helm 中使用插件的行为。\n\n例如，对于 [`fullstatus 插件`](https://github.com/marckhouzam/helm-fullstatus)，它没有子命令但接受与 `helm status` 命令相同的标志，`completion.yaml` 文件是：\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\n一个更复杂的例子是 [`2to3 插件`](https://github.com/helm/helm-2to3)，它的 `completion.yaml` 文件是：\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### 动态补全\n\n同样从 Helm 3.2 开始，插件可以提供自己的动态 shell 自动补全。动态 shell 自动补全是对无法事先定义的参数值或标志值的补全。例如，补全集群中当前可用的 helm release 名称。\n\n对于支持动态自动补全的插件，必须在其根目录中提供一个名为 `plugin.complete` 的**可执行**文件。当 Helm 补全脚本需要插件的动态补全时，它将执行 `plugin.complete` 文件，传递需要补全的命令行。`plugin.complete` 可执行文件需要有逻辑来确定正确的补全选项，并将它们输出到标准输出以供 Helm 补全脚本使用。\n\n`plugin.complete` 文件是完全可选的。如果没有提供，Helm 将不会为插件提供动态自动补全。另外，添加 `plugin.complete` 文件是向后兼容的，不会影响在旧版 helm 中使用插件的行为。\n\n`plugin.complete` 脚本的输出应该是以换行分隔的列表，例如：\n\n```console\nrel1\nrel2\nrel3\n```\n\n当调用 `plugin.complete` 时，插件环境的设置与调用插件主脚本时相同。因此，变量 `$HELM_NAMESPACE`、`$HELM_KUBECONTEXT` 和所有其他插件变量都已设置，并且它们对应的全局标志会被移除。\n\n`plugin.complete` 文件可以是任何可执行形式；它可以是 shell 脚本、Go 程序或任何其他 Helm 可以执行的程序。`plugin.complete` 文件 ***必须*** 对用户具有可执行权限。`plugin.complete` 文件 ***必须*** 以成功代码（值 0）退出。\n\n在某些情况下，动态补全需要从 Kubernetes 集群获取信息。例如，`helm fullstatus` 插件需要 release 名称作为输入。在 `fullstatus` 插件中，它的 `plugin.complete` 脚本要提供当前 release 名称的补全，只需运行 `helm list -q` 并输出结果即可。\n\n如果希望插件执行和插件补全使用相同的可执行文件，可以让 `plugin.complete` 脚本使用某些特殊参数或标志调用主插件可执行文件；当主插件可执行文件检测到特殊参数或标志时，它就知道要运行补全。在我们的例子中，`plugin.complete` 可以这样实现：\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\n`fullstatus` 插件的实际脚本（`status.sh`）必须查找 `--complete` 标志，如果找到，则打印出正确的补全。\n\n### 提示和技巧\n\n1. Shell 会自动过滤掉与用户输入不匹配的补全选项。因此，插件可以返回所有相关的补全，而不需要移除与用户输入不匹配的选项。例如，如果命令行是 `helm fullstatus ngin<TAB>`，`plugin.complete` 脚本可以打印 *所有*（`default` 命名空间的）release 名称，而不仅仅是以 `ngin` 开头的；shell 只会保留以 `ngin` 开头的。\n2. 为了简化动态补全支持，特别是如果你有一个复杂的插件，你可以让 `plugin.complete` 脚本调用你的主插件脚本并请求补全选项。参见上面的[动态补全](#动态补全)部分的例子。\n3. 要调试动态补全和 `plugin.complete` 文件，可以运行以下命令查看补全结果：\n    - `helm __complete <pluginName> <arguments to complete>`。例如：\n    - `helm __complete fullstatus --output js<ENTER>`，\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/provenance.md",
    "content": "---\ntitle: Helm 来源和完整性\ndescription: 描述如何验证 chart 的完整性和来源。\nsidebar_position: 5\n---\n\nHelm 提供了来源验证工具，帮助 chart 用户验证包的完整性和来源。使用基于 PKI、GnuPG 及流行包管理器的行业标准工具，Helm 可以生成和验证签名文件。\n\n## 概述\n\n完整性是通过比较 chart 的来源记录来建立的。来源记录存储在 _来源文件_ 中，和打包好的 chart 放在一起。例如，如果有个名为 `myapp-1.2.3.tgz` 的 chart，则它的来源文件是 `myapp-1.2.3.tgz.prov`。\n\n来源文件会在打包时生成（`helm package --sign ...`），并可以通过多个命令进行检查，尤其是 `helm install --verify`。\n\n## 工作流\n\n本节描述如何有效使用来源数据的工作流。\n\n前置条件：\n\n- 有效的二进制格式（非 ASCII-armored）的 PGP 密钥对\n- `helm` 命令行工具\n- GnuPG 命令行工具（可选）\n- Keybase 命令行工具（可选）\n\n**注意：** 如果你的 PGP 私钥有密码，系统会提示你为所有支持 `--sign` 选项的命令输入密码。\n\n创建新的 chart 与之前一样：\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n准备好打包后，在 `helm package` 命令中添加 `--sign` 参数，并指定签名密钥的名称和包含相应私钥的密钥环：\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**注意：** `--key` 参数的值必须是对应密钥 `uid`（在 `gpg --list-keys` 输出中）的子字符串，例如名字或邮箱。**指纹码 _不能_ 使用。**\n\n**提示：** 对于 GnuPG 用户，你的私钥密钥环位于 `~/.gnupg/secring.gpg`。可以使用 `gpg --list-secret-keys` 列出你拥有的密钥。\n\n**警告：** GnuPG v2 在默认位置 `~/.gnupg/pubring.kbx` 使用新格式 `kbx` 存储密钥环。请使用以下命令将密钥环转换为传统的 gpg 格式：\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\n此时，你应该同时看到 `mychart-0.1.0.tgz` 和 `mychart-0.1.0.tgz.prov` 两个文件。这两个文件最终都会被上传到对应的 chart 仓库。\n\n可以使用 `helm verify` 验证 chart：\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\n验证失败的输出如下：\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\n在安装时同时验证，使用 `--verify` 参数：\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\n如果包含签名 chart 对应公钥的密钥环不在默认位置，需要使用 `--keyring PATH` 指定密钥环路径，与 `helm package` 示例类似。\n\n如果验证失败，chart 的安装会在渲染前中止。\n\n### 使用 Keybase.io 凭据\n\n[Keybase.io](https://keybase.io) 服务使得建立加密身份的信任链变得很容易。Keybase 凭据可以用于签名 chart。\n\n前置条件：\n\n- 已配置的 Keybase.io 账户\n- 本地已安装 GnuPG\n- 本地已安装 `keybase` CLI\n\n#### 对包签名\n\n第一步是将 Keybase 密钥导入本地的 GnuPG 密钥环：\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\n这会将你的 Keybase 密钥转换成 OpenPGP 格式，然后导入到本地的 `~/.gnupg/secring.gpg` 文件。\n\n可以运行 `gpg --list-secret-keys` 进行确认：\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\n注意你的密钥会有一个标识字符串：\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\n这是密钥的完整名称。\n\n然后，可以使用 `helm package` 打包和签名 chart。确保在 `--key` 参数中使用名称的一部分：\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\n`package` 命令会同时生成 `.tgz` 文件和 `.tgz.prov` 文件。\n\n#### 验证包\n\n你也可以使用类似的方法验证由其他 Keybase 密钥签名的 chart。例如，你要验证由 `keybase.io/technosophos` 签名的包，可以使用 `keybase` 工具：\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\n第一个命令会关注用户 `technosophos`。然后 `keybase pgp pull` 会下载你关注的所有账户的 OpenPGP 密钥，并将它们放入 GnuPG 密钥环（`~/.gnupg/pubring.gpg`）。\n\n此时，就可以使用 `helm verify` 或其他带 `--verify` 参数的命令：\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### chart 无法验证的原因\n\n验证失败通常有以下原因：\n\n- `.prov` 文件缺失或损坏。这说明配置有误，或者原始维护者没有创建来源文件。\n- 签名文件所用的密钥不在你的密钥环中。这说明签名 chart 的实体不是你已标记为信任的人。\n- `.prov` 文件验证失败。这说明 chart 或来源数据本身有问题。\n- 来源文件中的文件哈希与归档文件的哈希不匹配。这表明 chart 包已被篡改。\n\n如果验证失败，就有理由不信任该包。\n\n## 来源文件\n\n来源文件包含 chart 的 YAML 文件以及一些验证信息。来源文件会自动生成。\n\n会添加以下来源数据：\n\n* chart 文件（`Chart.yaml`）包含在内，让人和工具都可以方便地查看 chart 的内容。\n* chart 包（`.tgz` 文件）的签名（SHA256，类似 Docker）包含在内，可用于验证 chart 包的完整性。\n* 整个文件体使用 OpenPGP 算法签名（参见 [Keybase.io](https://keybase.io)，一种使加密签名和验证更简单的新方式）。\n\n这些内容的组合为用户提供以下保证：\n\n* 包本身没有被篡改（通过 `.tgz` 包的校验和）。\n* 发布该包的实体是可知的（通过 GnuPG/PGP 签名）。\n\n文件格式类似这样：\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\n注意 YAML 部分包含两个文档（用 `...\\n` 分隔）。第一个文档是 `Chart.yaml` 的内容。第二个是校验和，即打包时文件名到该文件内容 SHA-256 摘要的映射。\n\n签名块是标准的 PGP 签名，提供[防篡改](https://www.rossde.com/PGP/pgp_signatures.html)功能。\n\n## Chart 仓库\n\nChart 仓库是 Helm chart 的集中存储。\n\nChart 仓库必须能够通过 HTTP 请求提供来源文件，且来源文件必须与 chart 位于相同的 URI 路径下。\n\n例如，如果包的基础 URL 是 `https://example.com/charts/mychart-1.2.3.tgz`，那么来源文件（如果存在）必须可以通过 `https://example.com/charts/mychart-1.2.3.tgz.prov` 访问。\n\n从终端用户的角度来看，`helm install --verify myrepo/mychart-1.2.3` 应该同时下载 chart 和来源文件，无需额外的用户配置或操作。\n\n### 基于 OCI 的注册中心中的签名\n\n将 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` 命令将来源信息发布到不可变的透明日志中。\n\n## 建立权威和真实性\n\n在处理信任链系统时，建立签名者的权威性非常重要。简单来说，上述系统建立在你信任签名 chart 的人这一事实之上。这意味着你需要信任签名者的公钥。\n\nHelm 的一个设计决策是 Helm 项目不会作为信任链中的必要一方。我们不想成为所有 chart 签名者的\"证书颁发机构\"，而是更倾向于去中心化模型，这也是我们选择 OpenPGP 作为基础技术的原因之一。因此，在建立权威性方面，我们在 Helm 2 中基本没有定义这一步骤（这一决定在 Helm 3 中延续）。\n\n不过，对于有兴趣使用来源系统的人，我们有一些提示和建议：\n\n- [Keybase](https://keybase.io) 平台提供了一个公共的集中式信任信息仓库。\n  - 你可以使用 Keybase 存储你的密钥或获取其他人的公钥。\n  - Keybase 还有非常出色的文档。\n  - 虽然我们还没有测试过，但 Keybase 的\"安全站点\"功能可以用来托管 Helm chart。\n  - 基本思路是：官方\"chart 审核人\"使用他（她）的密钥签名 chart，然后将来源文件上传到 chart 仓库。\n  - 有人提出过一个想法：在仓库的 `index.yaml` 文件中包含有效签名密钥的列表。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/rbac.md",
    "content": "---\ntitle: 基于角色的访问控制\ndescription: 解释 Helm 如何与 Kubernetes 基于角色的访问控制交互。\nsidebar_position: 11\n---\n\n在 Kubernetes 中，向用户或应用程序特定的服务账户授予角色是确保应用程序在指定范围内运行的最佳实践。\n有关服务账户权限的更多信息，请查看[官方 Kubernetes 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions)。\n\n从 Kubernetes 1.6 开始，基于角色的访问控制默认是启用的。RBAC 允许你根据组织中的用户及其角色来指定允许的操作类型。\n\n有了 RBAC，你可以：\n\n- 授权特殊操作（创建集群范围内的资源，比如新角色）给管理员\n- 限制用户在指定命名空间创建资源的能力（Pod、持久卷、Deployment），或者在集群范围内创建资源的能力（资源配额、角色、自定义资源定义）\n- 限制用户在特定命名空间或集群范围内查看资源的能力\n\n本指南适用于希望限制用户与 Kubernetes API 交互范围的管理员。\n\n## 管理用户账户\n\n所有 Kubernetes 集群有两类用户：Kubernetes 管理的服务账户和普通用户。\n\n普通用户被认为是由外部独立服务管理的，例如管理员分发私钥、Keystone 或 Google 账户等用户存储、甚至是包含用户名和密码列表的文件。\n在这方面，Kubernetes 没有表示普通用户账户的对象。普通用户无法通过 API 调用添加到集群中。\n\n相反，服务账户是由 Kubernetes API 管理的用户。它们被绑定到指定的命名空间，并由 API 服务器自动创建或通过 API 调用手动创建。\n服务账户绑定到一组作为 Secret 存储的凭据。这些凭据被挂载到 Pod 中，允许集群内进程与 Kubernetes API 交互。\n\nAPI 请求要么绑定到普通用户或服务账户，要么被视为匿名请求。这意味着集群内或外部的每个进程——从人类用户在工作站上使用 `kubectl`，\n到节点上的 kubelet，再到控制平面的成员——向 API 服务器发送请求时都必须进行身份验证，否则被视为匿名用户。\n\n## Role、ClusterRole、RoleBinding 和 ClusterRoleBinding\n\n在 Kubernetes 中，用户账户和服务账户只能查看和编辑被授权访问的资源。访问权限通过 Role 和 RoleBinding 授予。\nRole 和 RoleBinding 绑定到特定的命名空间，授予用户查看和/或编辑该命名空间中 Role 允许访问的资源的能力。\n\n在集群范围内，它们被称为 ClusterRole 和 ClusterRoleBinding。授予用户 ClusterRole 后，用户可以查看和/或编辑整个集群的资源。\n查看和/或编辑集群范围的资源（命名空间、资源配额、节点）也需要 ClusterRole。\n\nClusterRole 可以通过在 RoleBinding 中引用来绑定到特定的命名空间。`admin`、`edit` 和 `view` 这些默认 ClusterRole 通常以这种方式使用。\n\nKubernetes 默认提供了一些 ClusterRole，它们旨在成为面向用户的角色。包括超级用户角色（`cluster-admin`）以及具有更细粒度访问权限的角色（`admin`、`edit`、`view`）。\n\n| 默认 ClusterRole | 默认 ClusterRoleBinding | 描述\n|---------------------|----------------------------|-------------\n| `cluster-admin`     | `system:masters` group     | 允许超级用户访问任意资源并执行任意操作。在 ClusterRoleBinding 中使用时，它提供对集群和所有命名空间中每个资源的完全控制。在 RoleBinding 中使用时，提供对该 RoleBinding 所在命名空间中每个资源的完全控制，包括命名空间本身。\n| `admin`             | 无                       | 允许管理员访问，旨在使用 RoleBinding 在命名空间中授权。如果在 RoleBinding 中使用，允许对命名空间中的大部分资源进行读写，包括在命名空间中创建 Role 和 RoleBinding。不允许对资源配额或命名空间本身进行写操作。\n| `edit`              | 无                       | 允许对命名空间中大部分对象进行读写。不允许查看或修改 Role 或 RoleBinding。\n| `view`              | 无                       | 允许对命名空间中大部分对象进行只读访问。不允许查看 Role 或 RoleBinding。由于存在权限升级风险，也不允许查看 Secret。\n\n## 使用 RBAC 限制用户账户的访问\n\n现在我们了解了基于角色的访问控制的基础知识，让我们讨论一下管理员如何限制用户的访问范围。\n\n### 示例：授予用户特定命名空间的读写权限\n\n要限制用户访问特定的命名空间，可以使用 `edit` 或 `admin` 角色。如果你的 chart 创建或使用 Role 和 RoleBinding，应该使用 `admin` ClusterRole。\n\n另外，也可以使用 `cluster-admin` 访问权限创建 RoleBinding。在命名空间范围内授予用户 `cluster-admin` 访问权限，可以提供对该命名空间内每个资源的完全控制，包括命名空间本身。\n\n在这个示例中，我们将使用 `edit` Role 创建一个用户。首先，创建一个命名空间：\n\n```console\n$ kubectl create namespace foo\n```\n\n现在在该命名空间中创建一个 RoleBinding，授予用户 `edit` 角色。\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### 示例：授予用户集群范围内的读写权限\n\n如果用户希望安装一个包含集群范围资源（命名空间、角色、自定义资源定义等）的 chart，则需要集群范围的写权限。\n\n这需要授予用户 `admin` 或 `cluster-admin` 访问权限。\n\n授予用户 `cluster-admin` 访问权限意味着他们可以访问 Kubernetes 中所有可用的资源，包括使用 `kubectl drain` 访问节点以及执行其他管理任务。\n强烈建议考虑使用 `admin` 权限代替，或者创建一个针对其需求量身定制的自定义 ClusterRole。\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### 示例：授予用户特定命名空间的只读权限\n\n你可能已经注意到没有用于查看 Secret 的 ClusterRole。出于权限升级的考虑，`view` ClusterRole 不允许用户读取 Secret。Helm 默认将 release 元数据存储为 Secret。\n\n为了让用户可以运行 `helm list`，他们需要能够读取这些 Secret。为此，我们需要创建一个特殊的 `secret-reader` ClusterRole。\n\n创建 `cluster-role-secret-reader.yaml` 文件并写入以下内容：\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\n然后使用以下命令创建该 ClusterRole：\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\n完成后，我们可以授予用户对大多数资源的读权限，然后再授予他们读取 Secret 的权限：\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### 示例：授予用户集群范围的只读权限\n\n在某些情况下，授予用户集群范围的访问权限是有益的。例如，如果用户想运行 `helm list --all-namespaces`，\nAPI 需要用户具有集群范围的读权限。\n\n可以按照上述方式授予用户 `view` 和 `secret-reader` 访问权限，但使用 ClusterRoleBinding。\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## 其他说明\n\n上述示例使用了 Kubernetes 提供的默认 ClusterRole。如需对用户授予更细粒度的资源访问控制，请查看 [Kubernetes 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)了解如何创建自定义的 Role 和 ClusterRole。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/registries.md",
    "content": "---\ntitle: 使用基于 OCI 的注册中心\ndescription: 描述如何使用 OCI 进行 chart 的分发。\nsidebar_position: 7\n---\n\n从 Helm 3 开始，可以使用具有 [OCI](https://www.opencontainers.org/)支持的容器注册中心来存储和共享 chart 包。从 Helm v3.8.0 开始，默认启用 OCI 支持。\n\n## v3.8.0 版本之前对 OCI 的支持\n\nOCI 支持在 Helm v3.8.0 版本从试验阶段过渡成为普遍可用。在之前版本中，OCI 支持会有不同的地方。如果你在 v3.8.0 之前的版本使用 OCI，需要着重了解不同Helm 版本之间 OCI 的变化。\n\n### 在 v3.8.0 之前的版本启用 OCI 支持\n\nHelm v3.8.0 版本之前，OCI 支持是*试验性*的且必须显式启用。\n\n为了在之前版本中启用 OCI 试验性支持，需要在环境变量中设置 `HELM_EXPERIMENTAL_OCI`，例如：\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### OCI 在 v3.8.0 中的弃用和行为变化\n\n[Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) 版本中，以下行为和特性与之前版本不同：\n\n- 在依赖中将 chart 设置为 OCI 时，版本号可以像其他依赖一样设置成范围。\n- 包含构建信息的SemVer tag 可以被推送和使用。OCI 注册中心的 tag 字符不支持 `+`。如果有，Helm 会将 `+` 转成 `_`。\n- `helm registry login` 命令现在采用与 Docker CLI 相同的结构存储凭证。Helm 和 Docker CLI 的注册表配置使用一样的路径。\n\n### OCI 在 v3.7.0 中的弃用和行为变化\n\n[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) 实现方案。因此以下行为和特性与之前版本不同：\n\n- 移除了 `helm chart` 子命令。\n- 移除了 chart 缓存（没有了 `helm chart list` 等等）。\n- OCI 注册引用现在需要以 `oci://` 开头。\n- 注册引用的基础名称*必须*和 chart 名称匹配。\n- 注册引用的tag*必须*和 chart 的语义版本匹配（比如没有 `latest` 这种 tag）。\n- chart 层的媒体类型从 `application/tar+gzip`转换成了 `application/vnd.cncf.helm.chart.content.v1.tar+gzip`。\n\n## 使用基于 OCI 的注册中心\n\n### 基于 OCI 注册中心的 Helm 仓库\n\n[Helm 仓库](./chart_repository.md)是一种制作和分发打包好的 Helm chart 的方式。基于 OCI 的注册中心包含零个或多个 Helm 仓库，且每个都会有零个或多个 Helm chart。\n\n### 使用托管的注册中心\n\n以下是几种 chart 可以使用的托管容器注册中心，都支持 OCI，例如：\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n\n参照托管平台提供的文档来创建和配置支持 OCI 的注册中心。\n\n**注意：** 你可以在开发电脑上运行基于 OCI 的注册中心 [Docker Registry](https://docs.docker.com/registry/deploying/) 或者 [`zot`](https://github.com/project-zot/zot)。在开发电脑上运行只能用于测试目的。\n\n### 使用 sigstore 签名基于 OCI 的 chart\n\n[`helm-sigstore`](https://github.com/sigstore/helm-sigstore) 插件支持使用 [Sigstore](https://sigstore.dev/) 签名 Helm chart，与签名容器镜像使用相同的工具。这为经典 [chart 仓库](./chart_repository.md)支持的[基于 GPG 的来源验证](./provenance.md)提供了替代方案。\n\n有关 `helm sigstore` 插件的详细用法，请参阅[该项目的文档](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md)。\n\n## 用于处理注册中心的命令\n\n### `registry` 子命令\n\n#### `login`\n\n登录到注册中心 (手动输入密码)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\n从注册中心注销\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### `push` 子命令\n\n上传 chart 到基于 OCI 的注册中心：\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\n`push` 子命令只能用于 `helm package` 提前创建的 `.tgz` 文件。\n\n使用 `helm push` 上传 chart 到 OCI 注册表时，引用必须以 `oci://` 开头，且不能包含基础名称或 tag。\n\n注册表引用的基础名称由 chart 名称推断而来，tag 由 chart 语义版本推断而来。这是强制要求。\n\n某些注册表（如果指定）要求事先创建仓库或者命名空间，或者两者都需要创建。否则，`helm push` 会出现错误。\n\n如果你已经创建了[来源文件](./provenance.md)（`.prov`），且与 `.tgz` 文件位于同一目录下，该文件会在 `push` 时自动上传到注册表，并在 [Helm chart manifest](#helm-chart-manifest) 中生成一个额外的层。\n\n[helm-push plugin](https://github.com/chartmuseum/helm-push) 用户（用于上传 chart 到 [ChartMuseum](./chart_repository.md#chartmuseum-repository-server)）可能会遇到问题，因为该插件与内置的新 `push` 命令有冲突。从 v0.10.0 版本开始，该插件已更名为 `cm-push`。\n\n### 其他命令\n\n对 `oci://` 协议的支持同样适用于很多其他子命令。以下是完整列表：\n\n- `helm pull`\n- `helm push`\n- `helm show`\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\n注册表的基础名称（chart name）*包含*了涉及 chart 下载的任意类型的操作（相对于 `helm push` 被省略的位置）。\n\n下面是一些基于 OCI 的 chart 使用上述子命令的示例：\n\n```console\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## 使用摘要安装 chart\n\n使用摘要安装 chart 比使用 tag 更安全，因为摘要是不可变的。摘要在 chart URI 中指定：\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## 指定依赖项\n\nchart 的依赖项可以从注册中心拉取，使用 `dependency update` 命令。\n\n`Chart.yaml` 中给定的 `repository` 被指定为不含基础名称的注册表引用：\n\n```yaml\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\n\n执行 `dependency update` 时会获取 `oci://localhost:5000/myrepo/mychart:2.7.0`。\n\n## Helm chart manifest\n\n以下是在注册表中表示的 Helm chart manifest 示例（注意 `mediaType` 字段）：\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\n下面的示例包含一个[来源文件](./provenance.md)（注意额外层）：\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## 从 chart 仓库迁移\n\n从经典 [chart 仓库](./chart_repository.md)（基于 index.yaml）的迁移非常简单，只需使用 `helm pull` 拉取 chart，然后使用 `helm push` 上传生成的 `.tgz` 文件到注册表即可。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: 从 Helm v2 迁移到 v3\ndescription: 了解如何将 Helm v2 迁移到 v3。\nsidebar_position: 13\n---\n\n本指南介绍如何将 Helm v2 迁移到 v3。在开始前，需要先安装 Helm v2 并在一个或多个集群中管理 release。\n\n## Helm 3 变更概述\n\nHelm 2 到 Helm 3 的完整变更列表请参阅 [FAQ 部分](/faq/changes_since_helm2.md)。以下是用户在迁移之前和迁移期间应该注意的一些变更概述：\n\n1. 移除了 Tiller：\n   - 用 client/library 架构（仅 `helm` 二进制文件）替换了 client/server 架构\n   - 安全性现在基于单个用户（委托给 Kubernetes 用户集群安全机制）\n   - release 现在作为集群内的 Secret 存储，且 release 对象的元数据格式也已更改\n   - release 现在按 release 命名空间持久化，不再存储在 Tiller 命名空间中\n2. 更新了 Chart 仓库：\n   - `helm search` 现在支持本地仓库搜索和对 Artifact Hub 的搜索查询\n3. Chart apiVersion 升级到 \"v2\"，以支持以下规范变更：\n   - 动态链接的 chart 依赖移至 `Chart.yaml`（移除了 `requirements.yaml`，requirements --> dependencies）\n   - Library chart（辅助/通用 chart）现在可以作为动态链接的 chart 依赖添加\n   - Chart 有一个 `type` 元数据字段，用于定义 chart 类型是 `application` 还是 `library`。默认是 application，即可渲染和安装\n   - Helm 2 chart（apiVersion=v1）仍然可以安装\n4. 添加了 XDG 目录规范：\n   - Helm home 目录被移除，改用 XDG 目录规范来存储配置文件\n   - 不再需要初始化 Helm\n   - 移除了 `helm init` 和 `helm home`\n5. 其他变更：\n   - Helm 安装/设置简化：\n     - 仅需 Helm 客户端（helm 二进制文件）（无需 Tiller）\n     - 开箱即用\n   - 不再默认设置 `local` 或 `stable` 仓库\n   - 移除了 `crd-install` hook，改用 chart 中的 `crds` 目录，其中定义的所有 CRD 将在渲染 chart 之前安装\n   - 移除了 `test-failure` hook 注解值，且 `test-success` 已弃用。请使用 `test` 代替\n   - 命令的删除/替换/新增：\n       - delete --> uninstall：默认删除所有发布历史（之前需要 `--purge`）\n       - fetch --> pull\n       - home（已删除）\n       - init（已删除）\n       - install：需要 release 名称或 `--generate-name` 参数\n       - inspect --> show\n       - reset（已删除）\n       - serve（已删除）\n       - template：`-x`/`--execute` 参数重命名为 `-s`/`--show-only`\n       - upgrade：添加了 `--history-max` 参数，用于限制每个 release 保存的最大修订版本数（0 表示不限制）\n   - Helm 3 Go 库经历了大量变更，与 Helm 2 库不兼容\n   - release 二进制文件现在托管在 `get.helm.sh`\n\n## 迁移用例\n\n迁移用例如下：\n\n1. Helm v2 和 v3 管理同一集群：\n   - 仅当你打算逐步淘汰 Helm v2 且不需要 v3 管理任何 v2 部署的 release 时，才建议使用此方案。所有新 release 都应通过 v3 部署，现有 v2 部署的 release 仅通过 v2 更新/删除\n   - Helm v2 和 v3 可以很好地管理同一集群。两个 Helm 版本可以安装在同一系统上，也可以安装在不同系统上\n   - 如果在同一系统上安装 Helm v3，需要执行额外步骤以确保两个客户端版本可以共存，直到准备好删除 Helm v2 客户端。重命名或将 Helm v3 二进制文件放在不同的文件夹中以避免冲突\n   - 除此之外，由于以下区别，两个版本之间不会产生冲突：\n     - v2 和 v3 的 release（历史）存储是相互独立的。变更包括用于存储的 Kubernetes 资源和资源中包含的 release 对象元数据。release 将按用户命名空间存储，而不是 Tiller 命名空间（例如，v2 默认的 Tiller 命名空间是 kube-system）。v2 在 Tiller 命名空间中使用 \"ConfigMaps\" 或 \"Secrets\"，所有权为 `TILLER`。v3 在用户命名空间中使用 \"Secrets\"，所有权为 `helm`。release 在 v2 和 v3 中都是增量的\n     - 唯一可能出现的问题是，如果 chart 中定义了 Kubernetes 集群范围的资源（例如 `clusterroles.rbac`）。即使资源在命名空间中是唯一的，v3 部署也会因为资源冲突而失败\n     - v3 配置不再使用 `$HELM_HOME`，改用 XDG 目录规范。它还会按需动态创建。因此它独立于 v2 配置。这仅适用于两个版本安装在同一系统上的情况\n\n2. 将 Helm v2 迁移到 Helm v3：\n   - 此用例适用于你希望用 Helm v3 管理现有 Helm v2 release 的情况\n   - 需要注意的是 Helm v2 客户端：\n     - 可以管理 1 个或多个 Kubernetes 集群\n     - 可以为一个集群连接 1 个或多个 Tiller 实例\n   - 这意味着在迁移时必须注意这一点，因为 release 是通过 Tiller 及其命名空间部署到集群中的。因此，你必须注意迁移 Helm v2 客户端实例所管理的每个集群和每个 Tiller 实例\n   - 推荐的数据迁移路径如下：\n     1. 备份 v2 数据\n     2. 迁移 Helm v2 配置\n     3. 迁移 Helm v2 release\n     4. 当确信 Helm v3 按预期管理所有 Helm v2 数据（针对 Helm v2 客户端实例的所有集群和 Tiller 实例）后，清理 Helm v2 数据\n   - 迁移过程可通过 Helm v3 的 [2to3](https://github.com/helm/helm-2to3) 插件自动完成\n\n## 参考\n\n- Helm v3 [2to3](https://github.com/helm/helm-2to3) 插件\n- [博客文章](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)：通过示例说明 `2to3` 插件的用法\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Helm版本支持策略\"\ndescription: \"描述Helm的补丁发布策略，以及Helm和Kubernetes之间支持的最大版本偏差\"\n---\n\n该文档描述了在Helm和Kubernetes之间支持的最大版本偏差。\n\n## 支持的版本\n\nHelm的版本用 `x.y.z` 描述，`x`是主版本，`y`是次版本，`z`是补丁版本，遵循\n[语义化版本](https://semver.org/spec/v2.0.0.html) 术语。\n\nHelm项目维护了一个针对最近次要版本的发布分支。适当的修复（包括安全修复）会根据严重程度和可行性被cherry-pick到发布分支。更多细节请查看 [Helm 发布策略](/community/release_policy)。\n\n## 可支持的版本偏差\n\n当一个Helm的新版本发布时，它是针对Kubernetes的一个特定的次版本编译的。比如，Helm 3.0.0\n与Kubernetes的1.16.2的客户端版本交互，因此可以兼容Kubernetes 1.16。\n\n从Helm 3开始，Helm编译时假定与`n-3`版本的Kubernetes兼容。由于Kubernetes各次版本之间存在变更，Helm 2的支持策略稍严格一些，假定与`n-1`版本的Kubernetes兼容。\n\n例如，如果您在使用一个针对Kubernetes 1.17客户端API版本编译的Helm 3版本，那么它应该可以安全地使用Kubernetes 1.17，\n1.16，1.15，以及1.14。如果您在使用一个针对Kubernetes 1.16客户端API版本编译的Helm 2版本，那么它应该可以安全地使用\nKubernetes 1.16 和 1.15。\n\n不推荐将Helm用于比编译它所依赖的版本更高的Kubernetes版本，因为Helm并没有做出任何向前兼容的保证。\n\n如果您选择将Helm用于不支持的Kubernetes版本，需自负风险。\n\n请参考下表来确定哪个版本的Helm与您的集群兼容。\n\n| Helm 版本    | 支持的 Kubernetes 版本         |\n|--------------|-------------------------------|\n| 3.20.x       | 1.35.x - 1.32.x               |\n| 3.19.x       | 1.34.x - 1.31.x               |\n| 3.18.x       | 1.33.x - 1.30.x               |\n| 3.17.x       | 1.32.x - 1.29.x               |\n| 3.16.x       | 1.31.x - 1.28.x               |\n| 3.15.x       | 1.30.x - 1.27.x               |\n| 3.14.x       | 1.29.x - 1.26.x               |\n| 3.13.x       | 1.28.x - 1.25.x               |\n| 3.12.x       | 1.27.x - 1.24.x               |\n| 3.11.x       | 1.26.x - 1.23.x               |\n| 3.10.x       | 1.25.x - 1.22.x               |\n| 3.9.x        | 1.24.x - 1.21.x               |\n| 3.8.x        | 1.23.x - 1.20.x               |\n| 3.7.x        | 1.22.x - 1.19.x               |\n| 3.6.x        | 1.21.x - 1.18.x               |\n| 3.5.x        | 1.20.x - 1.17.x               |\n| 3.4.x        | 1.19.x - 1.16.x               |\n| 3.3.x        | 1.18.x - 1.15.x               |\n| 3.2.x        | 1.18.x - 1.15.x               |\n| 3.1.x        | 1.17.x - 1.14.x               |\n| 3.0.x        | 1.16.x - 1.13.x               |\n| 2.16.x       | 1.16.x - 1.15.x               |\n| 2.15.x       | 1.15.x - 1.14.x               |\n| 2.14.x       | 1.14.x - 1.13.x               |\n| 2.13.x       | 1.13.x - 1.12.x               |\n| 2.12.x       | 1.12.x - 1.11.x               |\n| 2.11.x       | 1.11.x - 1.10.x               |\n| 2.10.x       | 1.10.x - 1.9.x                |\n| 2.9.x        | 1.10.x - 1.9.x                |\n| 2.8.x        | 1.9.x - 1.8.x                 |\n| 2.7.x        | 1.8.x - 1.7.x                 |\n| 2.6.x        | 1.7.x - 1.6.x                 |\n| 2.5.x        | 1.6.x - 1.5.x                 |\n| 2.4.x        | 1.6.x - 1.5.x                 |\n| 2.3.x        | 1.5.x - 1.4.x                 |\n| 2.2.x        | 1.5.x - 1.4.x                 |\n| 2.1.x        | 1.5.x - 1.4.x                 |\n| 2.0.x        | 1.4.x - 1.3.x                 |\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs/version-3.json",
    "content": "{\n  \"version.label\": {\n    \"message\": \"3.19.0\",\n    \"description\": \"The label for version 3\"\n  },\n  \"sidebar.tutorialSidebar.category.Introduction\": {\n    \"message\": \"介绍\",\n    \"description\": \"The label for category Introduction in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.How-to\": {\n    \"message\": \"操作指南\",\n    \"description\": \"The label for category How-to in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Topics\": {\n    \"message\": \"主题\",\n    \"description\": \"The label for category Topics in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Best Practices\": {\n    \"message\": \"最佳实践\",\n    \"description\": \"The label for category Best Practices in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Chart Template Guide\": {\n    \"message\": \"Chart 模板指南\",\n    \"description\": \"The label for category Chart Template Guide in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Helm Commands\": {\n    \"message\": \"Helm 命令\",\n    \"description\": \"The label for category Helm Commands in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Go SDK\": {\n    \"message\": \"Go SDK\",\n    \"description\": \"The label for category Go SDK in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Community\": {\n    \"message\": \"社区\",\n    \"description\": \"The label for category Community in sidebar tutorialSidebar\"\n  },\n  \"sidebar.tutorialSidebar.category.Frequently Asked Questions\": {\n    \"message\": \"常见问题\",\n    \"description\": \"The label for category Frequently Asked Questions in sidebar tutorialSidebar\"\n  }\n}\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs-community/current/developers.md",
    "content": "---\ntitle: 开发者指南\ndescription: 开发Helm的环境设置说明。\nsidebar_position: 1\n---\n\n该指南说明如何为开发Helm配置环境。\n\n## 先决条件\n\n- Go最新版本\n- Kubernetes集群及kubectl（可选）\n- Git\n\n## 构建 Helm\n\n我们使用Make构建程序。最简单的开始方式是：\n\n```console\n$ make\n```\n\n有必要的话要先安装依赖，并验证配置。然后会编译 `helm` 并将其放到 `bin/helm`。\n\n在本地执行Helm，可以执行 `bin/helm`。\n\n- Helm运行在 macOS 和大多数发行版上，包括 Alpine。\n\n## 执行测试\n\n要运行所有测试，执行 `make test`。作为先决条件，需要安装\n[golangci-lint](https://golangci-lint.run)。\n\n## 贡献指南\n\n我们欢迎你的贡献。 该项目已经设置了一些指南，为了保证 (a) 代码的高质量，(b) 保持项目一致，\n(c) 贡献遵循开源法律要求。我们的目的不是为贡献者增加负担，但是要构建优雅和高质量的开源代码，\n这样我们的用户才能从中受益。\n\n确保你已经阅读并理解主要贡献指南：\n\n<https://github.com/helm/helm/blob/main/CONTRIBUTING.md>\n\n### 代码结构\n\nHelm项目的代码组织如下：\n\n- 独立的程序位于 `cmd/`。`cmd/` 中的代码不是为库复用设计的。\n- 共享的库放在 `pkg/`。\n- `scripts/` 目录包含很多实用程序脚本。大多数用于CI/CD流水线。\n\nGo依赖管理在不断变化，而且在Helm生命周期中很可能发生变化。我们建议开发者 _不要_ 手动管理依赖。\n而是建议依靠项目的 `Makefile` 来处理。使用Helm 3时，建议使用Go 1.13及更新版本。\n\n### 编写文档\n\n从Helm 3开始，文档已经移动到了它自己的仓库中。当编制新特性时，请编写随附文档并提交到\n[helm-www](https://github.com/helm/helm-www) 仓库。\n\n有个例外：[Helm CLI 输出 (英文)](/docs/helm) 是 `helm` 程序自己生成的。\n查看 [更新Helm CLI参考文档](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs)\n来了解如何生成该输出。翻译后，不会生成CLI输出，但可以在 `/content/<lang>/docs/helm` 中找到。\n\n### Git 约定\n\n我们使用Git作为版本控制系统。 `main` 分支是当前开发候选分支。发布版本会打tag。\n\n我们通过GitHub的Pull Requests(PRs)接受更改。操作工作流如下：\n\n1. Fork `github.com/helm/helm` 仓库到自己的GitHub账户\n2. `git clone` 这个仓库到你想要的目录。\n3. 创建一个新分支(`git checkout -b feat/my-feature`) 并在新分支上开发。\n4. 当你准备好待审查代码时，将分支推送到GitHub，并开一个新的pull request 给我们。\n\n对于Git提交信息，我们遵循\n[语义化提交信息](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)：\n\n```shell\nfix(helm): add --foo flag to 'helm install'\n\nWhen 'helm install --foo bar' is run, this will print \"foo\" in the\noutput regardless of the outcome of the installation.\n\nCloses #1234\n```\n\n常见提交类型：\n\n- fix: 修复bug或错误\n- feat: 添加新特性\n- docs: 更新文档\n- test: 完善测试\n- ref: 重构现有代码\n\n通用范围：\n\n- helm: Helm CLI\n- pkg/lint: lint包。对任意包都遵循类似的约定\n- `*`: 两个或更多范围\n\n了解更多：\n\n- 灵感来源于 [Deis指南](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)。\n- Karma Runner\n  [定义](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) 了语义提交信息的观点。\n\n### Go 约定\n\n我们非常严格地遵守Go编码风格标准。典型方式是，执行 `go fmt` 可以让代码更加整洁。\n\n我们通常也通过`go lint` 和`gometalinter`遵循推荐的约定。执行 `make test-style` 来测试风格一致性。\n\n了解更多：\n\n- 有效的Go[引入格式](https://golang.org/doc/effective_go.html#formatting)。\n- Go Wiki有关于[formatting](https://github.com/golang/go/wiki/CodeReviewComments)很棒的文章。\n\n如果运行`make test`，不仅单元测试会执行，格式测试也会自执行。如果 `make test`失败，即使是因为格式方面的原因，\n你的PR也不会被合并。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs-community/current/history.mdx",
    "content": "---\ntitle: 项目历史\ndescription: 提供项目历史的高级概述。\nsidebar_position: 4\n---\n\nimport Helm4 from \"/docs/_v4-in-progress.mdx\"\n\n<Helm4/>\n\nHelm 是[CNCF](https://www.cncf.io/projects/)的[毕业项目](https://helm.sh/blog/celebrating-helms-cncf-graduation/)。\n\nHelm 开始时被称为[Helm Classic](https://github.com/helm/helm-classic)，始于2015年的Deis项目并在KubeCon会议中被提出。\n\n2016年1月，该项目与名为Kubernetes部署管理器的GCS工具合并，并移动到了[Kubernetes](https://kubernetes.io)中。\n由于代码的合并，Helm 2.0于当年晚些时候发布。在Helm 2中保留的部署管理的关键特性是服务端组件，\nHelm 2.0最终的发布版本中DM重命名为了Tiller。\n\nHelm于2018年6月从Kubernetes子项目晋升为CNCF的成熟项目。Helm组建了一个顶级的管理机构并在Helm项目中包含了几个子项目，\n包括Monocular，Helm Chart仓库，Chart博物馆，以及后来的Helm Hub。\n\n当Helm 3开发周期开始时，移除了Tiller，使其更接近于作为客户工具最初愿景。但Helm 3继续跟踪Kubernetes集群内部的版本，\n使团队可以共同完成一个公共的Helm发布版本。Helm 3于2019年11月发布。\n\nHelm [于2020年4月成为CNCF的毕业项目](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/)。\n\nCNCF的[Artifact Hub](https://artifacthub.io)在2020年10月份替换了[Helm Hub](https://hub.helm.sh)。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs-community/current/localization.md",
    "content": "---\ntitle: 本地化Helm文档\ndescription: 本地化Helm文档的说明。\nsidebar_position: 5\n---\n\n本指南介绍如何本地化Helm文档。\n\n## 入门\n\n翻译工作使用与文档稿件相同的过程。翻译通过[pull\nrequests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)\n提供给 [helm-www](https://github.com/helm/helm-www) 仓库并由管理站点的团队审查。\n\n### 双字母语言代码\n\n语言代码文档由[ISO 639-1标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)组织。\n比如，韩国的双字母代码是 `ko`。\n\n在内容和配置中可以找到使用的语音码。三个例子如下：\n\n- `content` 目录中的子目录以语言码命名且本地化内容在对应的目录中。 主要在每个语言码目录的 `docs`子目录中。\n- `i18n`目录包含一个网站使用的每种语言的配置文件。文件按照 `[LANG].toml` 形式命名，`[LANG]` 是双字母语言码。\n- 顶层`config.toml`文件中，有按语言码组织的导航和其他详细信息的配置。\n\n英文使用语言码 `en`，是翻译的默认语言和资源。\n\n### Fork, Branch, Change, Pull Request\n\n贡献翻译从[helm-www仓库](https://github.com/helm/helm-www)\n[创建fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo)开始。在你的fork中提交更改。\n\n默认情况下，fork将在名为master的默认分支上工作。请使用分支提交更改并创建pull requests。如果你不熟悉分支，可以\n[阅读GitHub文档](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches)。\n\n一旦有了分支，就可以添加翻译，将内容本地化为一种语言。\n\n注意，Helm使用一个[Developers Certificate of Origin](https://developercertificate.org/)。\n所有的提交需要signoff。提交时可以使用 `-s` 或 `--signoff` 参数使用你Git配置的用户和邮箱签署这个提交。\n更多细节请查看 [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work)\n文件。\n\n准备好之后，创建一个 [pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)\n将翻译提交到helm-www仓库。\n\n一旦创建了pull request，维护者会进行审查。过程细节查看 [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md)。\n\n## 翻译内容\n\n本地化所有的Helm内容是一项巨大的任务。开始很小的改动是可以的。翻译会随着时间扩展。\n\n### 开始一个新语言\n\n开始新语言时有些最低要求，包括：\n\n- 添加`content/[LANG]/docs`目录，包含`_index.md` 文件。这是顶层的文档落地页。\n- `[LANG].toml` 文件在`i18n`目录中。可以复制`en.toml`文件作为起点。\n- 在 `config.toml`文件中添加一部分用于展示新语言。可以用已有语言作为起点。\n\n### 翻译\n\n已翻译内容需要保留在 `content/[LANG]/docs` 目录中。应该有相同的URL作为英文源。\n比如，将intro翻译为韩文时拷贝英文是有用的：\n\n```sh\nmkdir -p content/ko/docs/intro\ncp content/en/docs/intro/install.md content/ko/docs/intro/install.md\n```\n\n这个新文件中的内容可以翻译成其他语言。\n\n不要在`content/[LANG]/`中添加未翻译的英文文件拷贝。语言存在之后，任何未翻译的页面\n都会自动重定向到英文。翻译需要时间，应该翻译最新版本的文档，而不是过时的fork。\n\n确保从头部删除`aliases`行。像 `aliases: [\"/docs/using_helm/\"]` 不属于翻译。\n这些是旧链接的重定向，新页面不存在这些链接。\n\n注意翻译工具可以帮助完成这个过程。包括机器翻译内容。机器翻译内容在发布之前应该由说母语的人编辑或者审查语法和语义。\n\n## 在语言之间切换\n\n![Screen Shot 2020-05-11 at 11 24 22\nAM](https://user-images.githubusercontent.com/686194/81597103-035de600-937a-11ea-9834-cd9dcef4e914.png)\n\n站点全局\n[config.toml](https://github.com/helm/helm-www/blob/main/config.toml#L83L89)\n文件可以配置语言导航。\n\n添加新语言，可以使用上面定义的双字母语言码添加一组参数。比如：\n\n```toml\n# Korean\n[languages.ko]\ntitle = \"Helm\"\ndescription = \"Helm - The Kubernetes Package Manager.\"\ncontentDir = \"content/ko\"\nlanguageName = \"한국어 Korean\"\nweight = 1\n```\n\n## 解析内部链接\n\n翻译的内容有时会包含跳转到其他页面的链接，但只存在于其他语言中。就会出现\n[build errors](https://app.netlify.com/sites/helm-merge/deploys)。比如：\n\n```shell\n12:45:31 PM: htmltest started at 12:45:30 on app\n12:45:31 PM: ========================================================================\n12:45:31 PM: ko/docs/chart_template_guide/accessing_files/index.html\n12:45:31 PM:   hash does not exist --- ko/docs/chart_template_guide/accessing_files/index.html --> #basic-example\n12:45:31 PM: ✘✘✘ failed in 197.566561ms\n12:45:31 PM: 1 error in 212 documents\n```\n\n为了解决这个问题，你需要检查翻译中的内部链接。\n\n- 锚点链接需要反映翻译的 `id` 值\n- 内部页面链接需要修复\n\n对于不存在的内部页， _(或者还未被翻译的)_，站点不会构建，直到修复错误。应急的话可以指向\n另一个已经存在的语言：\n\n`< relref path=\"/docs/topics/library_charts.md\" lang=\"en\" >`\n\n查看 [语言之间的交叉引用](https://gohugo.io/content-management/cross-references/#link-to-another-language-version)\n获取更多信息。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs-community/current/related.md",
    "content": "---\ntitle: 相关项目及文档\ndescription: 社区提供的第三方工具，插件以及文档！\nsidebar_position: 3\n---\n\nHelm社区已经创建了很多针对Helm的额外工具，插件和文档。我们乐于听到这些项目声音。\n\n如果你有什么需要补充到这里的话，请创建一个 [issue](https://github.com/helm/helm-www/issues) 或者\n[pull request](https://github.com/helm/helm-www/pulls)。\n\n## Helm 插件 {#helm-plugins}\n\n- [helm-adopt](https://github.com/HamzaZo/helm-adopt) - 将现有k8s资源转换成新生成的helm\nchart的helm v3插件。\n- [Helm Diff](https://github.com/databus23/helm-diff) - `helm upgrade`的彩色diff预览\n- [Helm Dashboard](https://github.com/komodorio/helm-dashboard) - Helm的GUI界面，可视化release、repository及manifest的差异\n- [helm-gcs](https://github.com/hayorov/helm-gcs) - 管理Google Cloud Storage中仓库的插件\n- [helm-git](https://github.com/aslafy-z/helm-git) - 从Git仓库中安装chart并检索values文件。\n- [helm-k8comp](https://github.com/cststack/k8comp) - 使用k8comp从hiera创建Helm Charts的插件\n- [helm-mapkubeapis](https://github.com/helm/helm-mapkubeapis) - 更新helm发布版本元数据用于替换过期或已移除的k8s API\n- [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - 基于\n  Prometheus/ElasticSearch的用于监控版本发布和回滚的插件\n- [helm-release-plugin](https://github.com/JovianX/helm-release-plugin) - 该插件用于管理已部署的release，更新release值，拉取（重建）helm chart，以及设置helm release TTL。\n- [helm-s3](https://github.com/hypnoglow/helm-s3) - 允许使用AWS S3作为[私有]chart仓库的插件\n- [helm-secrets](https://github.com/jkroepke/helm-secrets) - 安全存储密钥的插件\n  （基于[sops](https://github.com/mozilla/sops)）\n- [helm-sigstore](https://github.com/sigstore/helm-sigstore) - Helm集成[sigstore](https://sigstore.dev/)生态的插件。\n用于搜索、上传及验证已签名的Helm chart。\n- [helm-tanka](https://github.com/Duologic/helm-tanka) - 在Helm chart中渲染Tanka/Jsonnet的插件\n- [hc-unit](https://github.com/xchapter7x/hcunit) - 使用OPA (Open Policy Agent) 和 Rego本地进行chart单元测试的插件\n- [helm-unittest](https://github.com/helm-unittest/helm-unittest) - 使用YAML本地进行chart单元测试的插件\n- [helm-val](https://github.com/HamzaZo/helm-val) - 从之前的版本中获取值的插件\n- [helm-external-val](https://github.com/kuuji/helm-external-val) - 从外部资源（configMaps，\nSecrets等）获取Helm values的插件\n\n我们同样鼓励使用GitHub的各位使用[helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)\n给插件仓库打tag。\n\n## 额外工具\n\nHelm的顶层工具。\n\n- [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) - 管理各种Kubernetes命名空间中的前缀版本，并删除复杂部署的已完成作业\n- [avionix](https://github.com/zbrookle/avionix) - 生成Helm chart和Kubernetes yaml的Python接口，允许继承及更少的代码重复\n- [Botkube](https://botkube.io) - 直接从Slack,Discord, Microsoft Teams, 和Mattermost运行Helm命令。\n- [Captain](https://github.com/alauda/captain) - 使用HelmRequest和Release CRD的Helm 3控制器\n- [Chartify](https://github.com/appscode/chartify) - 从已经存在的Kubernetes资源中生成Helm chart。\n- [ChartMuseum](https://github.com/helm/chartmuseum) - 支持 Amazon S3 和Google云存储的Helm\nChart仓库\n- [chart-registry](https://github.com/hangyan/chart-registry) - 在OCI注册表上的Helm chart主机\n- [Codefresh](https://codefresh.io) - 带有UI界面的管理Helm chart和版本的Kubernetes原生CI/CD及管理平台\n- [Flux](https://fluxcd.io/docs/components/helm/) -  从Git到Kubernetes的连续和渐进交付\n- [Helmfile](https://github.com/helmfile/helmfile) - Helmfile是用于部署helm chart的声明性规范\n- [Helmsman](https://github.com/Praqma/helmsman) - Helmsman是helm-charts-as-code工具，\n  可以从版本控制所需的状态文件（以简单的TOML格式描述）安装、升级、保护、移动及删除发布版本。\n- [Terraform Helm\n  Provider](https://github.com/hashicorp/terraform-provider-helm) - 为HashiCorp Terraform提供Helm，\n  以声明性的结构作为代码的语法实现Helm Chart的生命周期管理。Helm提供者通常与其他Terraform提供者配对，\n  类似于Kubernetes提供者，创建一个横跨所有基础服务的通用工作流。\n- [K8Studio](https://k8studio.io) -\n  用于管理 Kubernetes 集群的桌面 UI，集成 Helm 管理器。\n- [Konveyor Move2Kube](https://konveyor.io/move2kube/) -为现有项目生成Helm chart。\n- [Landscaper](https://github.com/Eneco/landscaper/) - \"Landscaper获取一组具有值（所需状态）的Helm\nhart引用，并在Kubernetes集群中实现。\"\n- [Monocular](https://github.com/helm/monocular) - Helm仓库的WEB UI界面。\n- [Monokle](https://monokle.io) - 桌面工具，用于创建、调试和部署Kubernetes资源和Helm Chart。\n- [Orkestra](https://azure.github.io/orkestra/) - 针对一组相关的Helm版本及子chart的云原生编排和生命周期管理平台（LCM）。\n- [Tanka](https://tanka.dev/helm) - Grafana Tanka通过具有使用Helm Chart能力的Jsonnet配置Kubernetes资源\n- [Terraform Helm  Provider](https://github.com/hashicorp/terraform-provider-helm)\n- HashiCorp Terraform的Helm provider，支持使用声明性代码语法对Helm Chart进行生命周期管理。\n该Helm provider通常与其他Terraform provider配对，比如Kubernetes provider，用于创建跨越所有基础服务的通用工作流。\n- [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - Kubernetes和Helm的VIM插件\n\n## Helm 已含的\n\nHelm支持的平台，发行版本和服务。\n\n- [Kubernetic](https://kubernetic.com/) - Kubernetes桌面客户端\n- [Jenkins X](https://jenkins-x.io/) - 使用Helm的Kubernetes开源自动化CI/CD\n  [promoting](https://jenkins-x.io/docs/getting-started/promotion/) 通过GitOps实现的环境应用程序\n\n## Misc\n\n为Chart作者和Helm用户准备的一些有用的东西。\n\n- [Await](https://github.com/saltside/await) - Docker镜像“等待”不同的条件——对初始化容器尤其有用。\n  [更多信息](https://blog.slashdeploy.com/2017/02/16/introducing-await/)。\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs-community/current/release_checklist.md",
    "content": "---\ntitle: 版本 Checklist\ndescription: 维护人员在发布下一个Helm版本时的checklist。\nsidebar_position: 2\n---\n\n# 维护人员发布Helm指南\n\n是时候发布新的Helm了！作为Helm维护者发布版本，如果你的经验与这里的文档不同，那你就是\n更新版本checklist\n的最佳人选。\n\n所有版本都将采用vX.Y.Z的形式，X是主版本号，Y是次版本号，Z是补丁发布号。该项目严格遵守 [语义化版本](https://semver.org/)，\n因此遵循这一点非常重要。\n\nHelm会提前宣布下个次版本发布的日期。应尽一切努力遵守宣布的日期。此外，在开始发布过程时，应该选择下一个发布的日期在发布过程中使用。\n\n这些说明将涵盖三种不同版本的遵守发布过程的初始配置：\n\n- 主版本 - 发布频率较低 - 有重大更新时\n- 次版本 - 每3到4个月发布 - 无重大更新\n- 补丁版本 - 每月发布 - 不需要指南中的所有步骤\n\n[初始化配置](#initial-configuration)\n\n1. [创建发布分支](#1-create-the-release-branch)\n2. [主/次版本：在Git中更改版本号](#2-majorminor-releases-change-the-version-number-in-git)\n3. [主/次版本：提交并推送发布分支](#3-majorminor-releases-commit-and-push-the-release-branch)\n4. [主/次版本：创建一个候选发布](#4-majorminor-releases-create-a-release-candidate)\n5. [主/次版本：迭代连续的候选版本](#5-majorminor-releases-iterate-on-successive-release-candidates)\n6. [完成发布](#6-finalize-the-release)\n7. [编写发布日志](#7-write-the-release-notes)\n8. [PGP签名下载](#8-pgp-sign-the-downloads)\n9. [发布版本](#9-publish-release)\n10. [更新文档](#10-update-docs)\n11. [告知社区](#11-tell-the-community)\n\n## Initial Configuration\n\n### 设置远程Git\n\n需要注意的是该文档假设你的远程upstream仓库关联到了<https://github.com/helm/helm>。\n如果不是（比如，如果你选择了“origin”或其他类似的替代），请确保根据本地环境调整列出的代码段。\n如果你不确定使用了什么远程的upstream，使用`git remote -v`命令查看。\n\n如果你没有[上游远程](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork)，\n可以类似这样添加：\n\n```shell\ngit remote add upstream git@github.com:helm/helm.git\n```\n\n### 设置环境变量\n\n在该文档中，我们还会引用一些环境变量，更便于设置。针对主、次版本，使用以下选项：\n\n```shell\nexport RELEASE_NAME=vX.Y.0\nexport RELEASE_BRANCH_NAME=\"release-X.Y\"\nexport RELEASE_CANDIDATE_NAME=\"$RELEASE_NAME-rc.1\"\n```\n\n如果你在创建一个补丁版本，改用以下命令：\n\n```shell\nexport PREVIOUS_PATCH_RELEASE=vX.Y.Z\nexport RELEASE_NAME=vX.Y.Z+1\nexport RELEASE_BRANCH_NAME=\"release-X.Y\"\n```\n\n### 设置签名Key\n\n我们还会通过对二进制文件和提供的签名文件进行哈希计算增加发布过程的安全性和认证。\n使用[GitHub 和 GPG](https://help.github.com/en/articles/about-commit-signature-verification)来执行。\n如果还没设置GPG可以按照以下步骤操作：\n\n1. [安装 GPG](https://gnupg.org/index.html)\n2. [生成 GPG key](https://help.github.com/en/articles/generating-a-new-gpg-key)\n3. [将key添加到GitHub账户中](https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account)\n4. [在Git中设置签名密钥](https://help.github.com/en/articles/telling-git-about-your-signing-key)\n\n一旦你有了签名密钥，需要将其添加到仓库根目录中的KEYS文件中。文件中有添加密钥到KEY文件的说明。如果还没有，需要将公钥添加到keyserver。\n如果使用了GnuPG，可以参照[Debian提供的说明](https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver)。\n\n## 1. Create the Release Branch\n\n### 主、次版本\n\n主版本是为新特性及操作且*不具有向后兼容性*。次版本是为了不破坏向后兼容性的新特性。创建一个主版本或次版本，从主干分支创建`release-X.Y`分支。\n\n```shell\ngit fetch upstream\ngit checkout upstream/main\ngit checkout -b $RELEASE_BRANCH_NAME\n```\n\n这个新分支是发布版本的基础分支，会在后面不断迭代。\n\n为GitHub上已存在的版本验证[helm/helm里程碑](https://github.com/helm/helm/milestones)。\n确保针对这个版本的PR和issue都在这个里程碑中。\n\n针对主版本和次版本，跳转到 2: [主/次版本：在Git中更改版本号](#2-majorminor-releases-change-the-version-number-in-git)。\n\n### 补丁版本\n\n补丁版本是一些已有版本中严格的cherry-picked修复。以创建`release-X.Y`分支开始：\n\n```shell\ngit fetch upstream\ngit checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME\n```\n\n在这里可以cherry-pick出需要带到补丁版本中的提交：\n\n```shell\n# get the commits ids we want to cherry-pick\ngit log --oneline\n# cherry-pick the commits starting from the oldest one, without including merge commits\ngit cherry-pick -x <commit-id>\n```\n\n挑出提交之后这个版本分支需要被推送。\n\n```shell\ngit push upstream $RELEASE_BRANCH_NAME\n```\n\n推送分支会触发测试。创建tag之前确保测试是通过的。\n这个新tag将成为补丁版本的基础。\n\n针对补丁版本，创建[helm/helm里程碑](https://github.com/helm/helm/milestones)是可选的。\n\n继续之前确保[helm 在 GitHub Actions](https://github.com/helm/helm/actions)通过CI。补丁版本可以跳过2-5步，\n直接执行6 [完成发布](#6-finalize-the-release)。\n\n## 2. Major/Minor releases: Change the Version Number in Git\n\n当有主版本或次版本发布时，确保用新版本更新`internal/version/version.go`。\n\n```shell\n$ git diff internal/version/version.go\ndiff --git a/internal/version/version.go b/internal/version/version.go\nindex 712aae64..c1ed191e 100644\n--- a/internal/version/version.go\n+++ b/internal/version/version.go\n@@ -30,7 +30,7 @@ var (\n        // Increment major number for new feature additions and behavioral changes.\n        // Increment minor number for bug fixes and performance enhancements.\n        // Increment patch number for critical fixes to existing releases.\n-       version = \"v3.3\"\n+       version = \"v3.4\"\n\n        // metadata is extra build time data\n        metadata = \"\"\n```\n\n除了在`version.go`文件中更行版本，还需要更新使用了新版本的相关测试。\n\n- `cmd/helm/testdata/output/version.txt`\n- `cmd/helm/testdata/output/version-client.txt`\n- `cmd/helm/testdata/output/version-client-shorthand.txt`\n- `cmd/helm/testdata/output/version-short.txt`\n- `cmd/helm/testdata/output/version-template.txt`\n- `pkg/chartutil/capabilities_test.go`\n\n```shell\ngit add .\ngit commit -m \"bump version to $RELEASE_NAME\"\n```\n\n这只会对$RELEASE_BRANCH_NAME更新。也许要在下个版本更新时推送到主干分支，就像 [3.2 更新到\n3.3](https://github.com/helm/helm/pull/8411/files)，并将其添加到下一个版本的里程碑中。\n\n```shell\n# get the last commit id i.e. commit to bump the version\ngit log --format=\"%H\" -n 1\n\n# create new branch off main\ngit checkout main\ngit checkout -b bump-version-<release_version>\n\n# cherry pick the commit using id from first command\ngit cherry-pick -x <commit-id>\n\n# commit the change\ngit push origin bump-version-<release-version>\n```\n\n## 3. Major/Minor releases: Commit and Push the Release Branch\n\n为了让他人开始测试，我们可以推送发布分支到upstream并开始测试过程。\n\n```shell\ngit push upstream $RELEASE_BRANCH_NAME\n```\n\n继续之前确保 [helm 在GitHub Actions](https://github.com/helm/helm/actions)版本通过CI。\n\n如果有人可用，让其他人在确保所有更改都已正确处理且所有该版本的提交都已存在，并提前对分支进行同行评审。\n\n## 4. Major/Minor releases: Create a Release Candidate\n\n现在，发布分支已经准备好了，可以开始创建和迭代候选版本了。\n\n```shell\ngit tag --sign --annotate \"${RELEASE_CANDIDATE_NAME}\" --message \"Helm release ${RELEASE_CANDIDATE_NAME}\"\ngit push upstream $RELEASE_CANDIDATE_NAME\n```\n\nGitHub Actions 会自动创建一个打tag的发布镜像，同时测试客户端库。\n\n对测试人员来说，在GitHub Actions完成测试构建过程之后开始测试，包括以下步骤来获取客户端：\n\nlinux/amd64, 使用 /bin/bash:\n\n```shell\nwget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz\n```\n\ndarwin/amd64, 使用 Terminal.app:\n\n```shell\nwget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz\n```\n\nwindows/amd64, 使用 PowerShell:\n\n```shell\nPS C:\\> Invoke-WebRequest -Uri \"https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz\" -OutFile \"helm-$ReleaseCandidateName-windows-amd64.tar.gz\"\n```\n\n然后，将二进制包解压并移动到$PATH目录中，或者移动到某个位置并添加$PATH（比如linux/macOS的/usr/local/bin/helm，windows的\nC:\\Program Files\\helm\\helm.exe for Windows）。\n\n## 5. Major/Minor releases: Iterate on Successive Release Candidates\n\n花了几天时间和资源去尝试用各种方式破坏helm，将所有的相关发现都记录到发布中。这段时间应该花在测试和寻找发行版可能导致各种特性或升级环境出现问题的方法上，\n不要编码。这段时间发布版本应该冻结代码，且任何要添加的代码更新都推到下个发布版本中。\n\n这个阶段，$RELEASE_BRANCH_NAME 会随着你新产生的候选发布不断发展。新候选的频率取决于发布管理员：依据报告问题的严重性、\n测试人员效率和发布期限做出最佳判断。一般来说，即使跨过最后期限也不能发布坏版本。\n\n在每次创建新的候选发布时，需要以添加从主干分支检出的commit开始：\n\n```shell\ngit cherry-pick -x <commit_id>\n```\n\n你也需要推送这个分支到GitHub并保证通过CI。\n\n然后打tag并通知用户有新的候选版本了：\n\n```shell\nexport RELEASE_CANDIDATE_NAME=\"$RELEASE_NAME-rc.2\"\ngit tag --sign --annotate \"${RELEASE_CANDIDATE_NAME}\" --message \"Helm release ${RELEASE_CANDIDATE_NAME}\"\ngit push upstream $RELEASE_CANDIDATE_NAME\n```\n\n一旦推送到了GitHub，检查分支确保tag在CI中构建。\n\n从这里重复这个过程，持续测试直到你对候选发布满意为止。对于发布候选，我们不写完整的记录，但可以写一下\n[发布日志](#7-write-the-release-notes)。\n\n## 6. Finalize the Release\n\n当你最终对自己的候选发布的质量感到满意时，可以继续并创建一个真正的发布。 最后再检查一次确保一切正常，最后推送这个发布的tag。\n\n```shell\ngit checkout $RELEASE_BRANCH_NAME\ngit tag --sign --annotate \"${RELEASE_NAME}\" --message \"Helm release ${RELEASE_NAME}\"\ngit push upstream $RELEASE_NAME\n```\n\n在[GitHub Actions](https://github.com/helm/helm/actions)中验证发布是否成功。如果不行，需要修复这个版本并重新推送。\n\n由于CI作业需要运行一段时间，你可以在等待其完成时去写发布日志。\n\n## 7. Write the Release Notes\n\n我们会根据发布周期提交的记录自动生成一个更新日志，但是，如果发布说明是由人或市场团队手写的，通常对最终用户会更有利。\n\n如果你在发布一个主或次版本，一般列出值得注意的面向用户的特性就足够了。对于补丁版本同样，但要标记出问题和会受影响的人。\n\n发布日志应该包含版本号和下一个版本的计划发布日期。\n\n针对次要版本的发布日志示例如下：\n\n```markdown\n## vX.Y.Z\n\nHelm vX.Y.Z is a feature release. This release, we focused on <insert focal point>. Users are encouraged to upgrade for the best experience.\n\nThe community keeps growing, and we'd love to see you there!\n\n- Join the discussion in [Kubernetes Slack](https://kubernetes.slack.com):\n  - `#helm-users` for questions and just to hang out\n  - `#helm-dev` for discussing PRs, code, and bugs\n- Hang out at the Public Developer Call: Thursday, 9:30 Pacific via [Zoom](https://zoom.us/j/696660622)\n- Test, debug, and contribute charts: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0)\n\n## Notable Changes\n\n- Kubernetes 1.16 is now supported including new manifest apiVersions\n- Sprig was upgraded to 2.22\n\n## Installation and Upgrading\n\nDownload Helm X.Y. The common platform binaries are here:\n\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n- [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)\n\nThe [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`.\n\n## What's Next\n\n- vX.Y.Z+1 will contain only bug fixes and is planned for <insert DATE>.\n- vX.Y+1.0 is the next feature release and is planned for <insert DATE>. This release will focus on ...\n\n## Changelog\n\n- chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese)\n- fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher)\n```\n\n通过运行以下命令可以创建一组包括更新日志的部分完成的发行说明：\n\n```shell\nexport VERSION=\"$RELEASE_NAME\"\nexport PREVIOUS_RELEASE=vX.Y.Z\nmake clean\nmake fetch-dist\nmake release-notes\n```\n\n这回生成一个发行日志的良好基线，你仅仅需要填写 **Notable Changes** 和 **What's next** 部分。\n\n可以在发布日志中随意添加你想说的，对用户来说会很好而不至于感觉我们是机器人。\n\n你也需要再次检查自动生成的日志中的URL和校验和。\n\n完成之后，去GitHub的 [helm/helm releases](https://github.com/helm/helm/releases)\n中为已打tag的版本编辑发布说明。对于目标分支，设置$RELEASE_BRANCH_NAME。\n\n现在需要让其他人在发行版本发布之前看看发行说明。发一个request到\n[#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG)用于评审。发行日志很容易漏掉一些东西，因此评审总是有用的。\n\n## 8. PGP Sign the downloads\n\n哈希生成一个表明下载内容就是其生成内容的签名，签名包提供了包来自何处的可追溯性。\n\n为此，要执行以下 `make` 命令：\n\n```shell\nexport VERSION=\"$RELEASE_NAME\"\nmake clean\t\t# if not already run\nmake fetch-dist\t# if not already run\nmake sign\n```\n\n这会生成通过CI推送的每个文件的ascii封装的签名文件。\n\n所有的签名文件(`*.asc`)需要上传到GitHub中的发布版本（附件二级制文件）中。\n\n## 9. Publish Release\n\n是时候正式发布了！\n\n发布说明保存在GitHub之后，CI构建已经完成，并且已经添加了发布版本的签名文件，你可以在发布版本上点击 \"Publish\" 了。\n发布的版本，标记为\"latest\"，并在[helm/helm](https://github.com/helm/helm)仓库的首页显示这个发布版本。\n\n## 10. Update Docs\n\n[Helm站点文档部分](/docs)列出了Helm版本的文档。主、次及补丁版本需要更行到这个站点。\n下一个次要版本的发布日期也要发布出来且必须更新。这要创建一个pull request 到\n[helm-www仓库](https://github.com/helm/helm-www)。在 `config.toml` 文件中找到合适的\n`params.versions`部分并更新Helm版本，例如 [更新当前版本](https://github.com/helm/helm-www/pull/676/files)。\n在同一个`config.toml`文件中，更新`params.nextversion`部分。\n\n如果需要，关闭这个版本的[helm/helm 里程碑](https://github.com/helm/helm/milestones)。\n\n为主版本和次版本更新[version skew](https://github.com/helm/helm-www/blob/main/content/en/docs/topics/version_skew.md)。\n\n在[这里](https://helm.sh/calendar/release)更新版本日历：\n\n- 为下一个次要版本创建一个条目并在GMT下午5点设置提醒\n- 在计划发布的前一周的周一为下一个次要版本的RC1创建一个条目，设置GMT下午5点的提醒\n\n## 11. Tell the Community\n\n恭喜，你已经完成了。去喝一杯吧。这是你应得的。\n\n然后继续前进并在Slack和Twitter上宣布这个新分支，并链接到[GitHub发布版本](https://github.com/helm/helm/releases)。\n\n或者，写一篇新版本的blog并在上面展示一些新特性！\n"
  },
  {
    "path": "i18n/zh/docusaurus-plugin-content-docs-community/current/release_policy.md",
    "content": "---\ntitle: \"发布计划策略\"\ndescription: \"描述 Helm 的发布计划策略。\"\n---\n\n为了用户的利益，Helm 提前定义和宣布发布日期。本文档描述了 Helm 发布计划的策略。\n\n## 发布日历 {#release-calendar}\n\n可以在[这里](https://helm.sh/calendar/release)找到一份公开日历，显示即将发布的 Helm 版本。\n\n## 语义化版本 {#semantic-versioning}\n\nHelm 的版本格式为 `x.y.z`，其中 `x` 是主版本号，`y` 是次版本号，`z` 是补丁版本号，遵循[语义化版本](https://semver.org/spec/v2.0.0.html)规范。\n\n## 补丁发布 {#patch-releases}\n\n补丁版本为用户提供 bug 修复和安全修复，不包含新特性。\n\n与最新次要/主要版本相关的新补丁版本通常在每月的第二个星期三发布。\n\n如有需要修复高优先级回归问题或安全问题，可以随时发布补丁版本。\n\n以下情况会取消补丁发布：\n\n- 自上一个版本以来没有新内容\n- 补丁发布日期在即将发布的次版本第一个候选版本（RC1）之前的一周内\n- 补丁发布日期在次版本发布后的四周内\n- 主版本或次版本发布安排在同一个月\n\n## 次版本发布 {#minor-releases}\n\n次版本包含安全和 bug 修复以及新特性。它们在 API 和 CLI 使用方面向后兼容。\n\n为了与 Kubernetes 版本保持一致，Helm 次版本每四个月发布一次（一年三个版本）。\n\n如有需要，可以发布额外的次版本，但不会影响已宣布的未来版本的发布时间，除非距离该版本发布不到 7 天。\n\n版本发布的同时，会在 Helm 主页上宣布下一个次版本的发布日期。\n\n## 主版本发布 {#major-releases}\n\n主版本包含破坏性变更。这类发布很少见，但有时为了让 Helm 能够在重要的新方向上持续演进，这是必要的。\n\n主版本很难计划。因此，只有当第一个 beta 版本可用时，才会选择并宣布最终发布日期。\n"
  },
  {
    "path": "i18n/zh/docusaurus-theme-classic/footer.json",
    "content": "{\n  \"link.title.Helm Project\": {\n    \"message\": \"Helm 项目\",\n    \"description\": \"The title of the footer links column with title=Helm Project in the footer\"\n  },\n  \"link.title.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"The title of the footer links column with title=Charts in the footer\"\n  },\n  \"link.title.Development\": {\n    \"message\": \"开发\",\n    \"description\": \"The title of the footer links column with title=Development in the footer\"\n  },\n  \"link.title.Community\": {\n    \"message\": \"社区\",\n    \"description\": \"The title of the footer links column with title=Community in the footer\"\n  },\n  \"link.item.label.Source code\": {\n    \"message\": \"源代码\",\n    \"description\": \"The label of footer link with label=Source code linking to https://github.com/helm/helm\"\n  },\n  \"link.item.label.Blog\": {\n    \"message\": \"博客\",\n    \"description\": \"The label of footer link with label=Blog linking to blog\"\n  },\n  \"link.item.label.Events\": {\n    \"message\": \"活动\",\n    \"description\": \"The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/\"\n  },\n  \"link.item.label.Code of Conduct\": {\n    \"message\": \"行为准则\",\n    \"description\": \"The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\n  },\n  \"link.item.label.Introduction\": {\n    \"message\": \"简介\",\n    \"description\": \"The label of footer link with label=Introduction linking to docs/intro\"\n  },\n  \"link.item.label.Chart tips & tricks\": {\n    \"message\": \"Chart 提示与技巧\",\n    \"description\": \"The label of footer link with label=Chart tips & tricks linking to #\"\n  },\n  \"link.item.label.Developing Charts\": {\n    \"message\": \"开发 Charts\",\n    \"description\": \"The label of footer link with label=Developing Charts linking to #\"\n  },\n  \"link.item.label.Search 800+ Charts\": {\n    \"message\": \"搜索 800+ Charts\",\n    \"description\": \"The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/\"\n  },\n  \"link.item.label.Slack (#helm-dev)\": {\n    \"message\": \"Slack (#helm-dev)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG\"\n  },\n  \"link.item.label.Contribution Guide\": {\n    \"message\": \"贡献指南\",\n    \"description\": \"The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md\"\n  },\n  \"link.item.label.Maintainers\": {\n    \"message\": \"维护者\",\n    \"description\": \"The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS\"\n  },\n  \"link.item.label.Weekly Meetings\": {\n    \"message\": \"每周会议\",\n    \"description\": \"The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings\"\n  },\n  \"link.item.label.GitHub Community\": {\n    \"message\": \"GitHub 社区\",\n    \"description\": \"The label of footer link with label=GitHub Community linking to https://github.com/helm/community\"\n  },\n  \"link.item.label.Slack (#helm-users)\": {\n    \"message\": \"Slack (#helm-users)\",\n    \"description\": \"The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/\"\n  },\n  \"link.item.label.Stack Overflow\": {\n    \"message\": \"Stack Overflow\",\n    \"description\": \"The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm\"\n  },\n  \"link.item.label.X\": {\n    \"message\": \"X\",\n    \"description\": \"The label of footer link with label=X linking to https://x.com/helmpack\"\n  },\n  \"copyright\": {\n    \"message\": \"<a href=\\\"https://www.cncf.io/\\\">我们是云原生计算基金会的毕业项目。</a><br/>© Helm 作者 2025。文档在 <a href=\\\"https://creativecommons.org/licenses/by/4.0\\\">CC-BY-4.0</a> 下发布。<br/>© 2025 The Linux Foundation。保留所有权利。The Linux Foundation 拥有注册商标并使用商标。有关 The Linux Foundation 的商标列表，请参阅我们的<a href=\\\"https://www.linuxfoundation.org/trademark-usage/\\\">商标使用页面</a>。\",\n    \"description\": \"The footer copyright\"\n  },\n  \"logo.alt\": {\n    \"message\": \"CNCF 标志\",\n    \"description\": \"The alt text of footer logo\"\n  }\n}\n"
  },
  {
    "path": "i18n/zh/docusaurus-theme-classic/navbar.json",
    "content": "{\n  \"title\": {\n    \"message\": \"Helm\",\n    \"description\": \"The title in the navbar\"\n  },\n  \"logo.alt\": {\n    \"message\": \"Helm 标志\",\n    \"description\": \"The alt text of navbar logo\"\n  },\n  \"item.label.Docs\": {\n    \"message\": \"文档\",\n    \"description\": \"Navbar item with label Docs\"\n  },\n  \"item.label.Charts\": {\n    \"message\": \"Charts\",\n    \"description\": \"Navbar item with label Charts\"\n  },\n  \"item.label.Blog\": {\n    \"message\": \"博客\",\n    \"description\": \"Navbar item with label Blog\"\n  },\n  \"item.label.Community\": {\n    \"message\": \"社区\",\n    \"description\": \"Navbar item with label Community\"\n  }\n}\n"
  },
  {
    "path": "netlify-plugins/README.md",
    "content": "# Netlify Build Plugins\n\nCaches Docusaurus build directories to reduce ~11 minute builds to 2-4 minutes.\n\n## Quick Reference\n\n**Current plugin:** `cache-docusaurus-dirs-file` (stable)\n**Build command:** `make netlify-build` (preserves cache)\n\n## Configuration\n\n```toml\n# netlify.toml\n[[plugins]]\npackage = \"./netlify-plugins/cache-docusaurus-dirs-file\"\n  [plugins.inputs]\n  dirs = [\".docusaurus\", \"node_modules\", \"build\"]\n```\n\nAll caching behavior controlled by environment variables:\n- `CACHE_VERSION` - Manual cache busting per environment\n- `CACHE_PER_BRANCH` - Set to `\"false\"` for PR previews to share cache\n\n## Switching Plugins\n\nTo test beta Cache API (potentially 10x faster):\n```toml\npackage = \"./netlify-plugins/cache-docusaurus-dirs-api\"\n```\n"
  },
  {
    "path": "netlify-plugins/cache-docusaurus-dirs-api/index.js",
    "content": "// Netlify Core Build Plugin to cache directories using utils.cache.\n// - Docusaurus-friendly: cache \".docusaurus\", \"node_modules\", and \"build\"\n// - node_modules auto-invalidation via yarn.lock hash\n// - On-demand busting via CACHE_VERSION env var per environment\n// - Per-branch cache isolation by default\n\nconst path = require(\"path\");\nconst fs = require(\"fs\");\nconst crypto = require(\"crypto\");\n\nfunction dirExists(dirPath) {\n  try {\n    const stat = fs.statSync(dirPath);\n    return stat.isDirectory();\n  } catch {\n    return false;\n  }\n}\n\nfunction fileSha256(filePath) {\n  try {\n    const data = fs.readFileSync(filePath);\n    return crypto.createHash(\"sha256\").update(data).digest(\"hex\");\n  } catch {\n    return null;\n  }\n}\n\nfunction makeKey({ dir, repoRoot }) {\n  const cacheVersion = process.env.CACHE_VERSION || \"\";\n  const perBranch = process.env.CACHE_PER_BRANCH !== \"false\"; // default true\n  const branch = process.env.NETLIFY_BRANCH || process.env.BRANCH || \"unknown\";\n\n  let key = dir;\n\n  // Auto-invalidate node_modules with yarn.lock changes\n  if (dir === \"node_modules\") {\n    const yarnLockPath = path.join(repoRoot, \"yarn.lock\");\n    const hash = fileSha256(yarnLockPath);\n    if (hash) {\n      key = `${key}@yarn-${hash.slice(0, 16)}`;\n    }\n  }\n\n  // On-demand busting\n  if (cacheVersion) {\n    key = `${key}@cv-${cacheVersion}`;\n  }\n\n  // Per-branch isolation\n  if (perBranch) {\n    key = `${key}@${branch}`;\n  }\n  return key;\n}\n\nasync function restoreDir(utils, absPath, key) {\n  try {\n    const restored = await utils.cache.restore(absPath, { key });\n    utils.status.show({\n      title: restored ? `Cache restored: ${key}` : `No cache: ${key}`,\n      summary: `${restored ? \"Restored\" : \"No prior cache\"} into ${absPath}`,\n    });\n    return restored;\n  } catch (err) {\n    utils.status.show({\n      title: `Cache restore failed: ${key}`,\n      summary: err.message,\n    });\n    return false;\n  }\n}\n\nasync function saveDir(utils, absPath, key) {\n  try {\n    const saved = await utils.cache.save(absPath, { key });\n    utils.status.show({\n      title: saved ? `Cache saved: ${key}` : `Cache skipped: ${key}`,\n      summary: `${saved ? \"Saved\" : \"Skipped\"} from ${absPath}`,\n    });\n    return saved;\n  } catch (err) {\n    utils.status.show({\n      title: `Cache save failed: ${key}`,\n      summary: err.message,\n    });\n    return false;\n  }\n}\n\nmodule.exports = {\n\n  async onPreBuild({ inputs, utils }) {\n    const repoRoot = process.cwd();\n    const dirs = inputs.dirs;\n\n    for (const dir of dirs) {\n      const key = makeKey({ dir, repoRoot });\n      const abs = path.resolve(repoRoot, dir);\n\n      await restoreDir(utils, abs, key);\n\n      // Guidance for node_modules: ensure yarn.lock exists to keep cache fresh\n      if (dir === \"node_modules\") {\n        const yarnLockPath = path.join(repoRoot, \"yarn.lock\");\n        if (!fs.existsSync(yarnLockPath)) {\n          utils.status.show({\n            title: \"node_modules cache warning\",\n            summary:\n              \"yarn.lock not found. Caching node_modules without yarn.lock can lead to stale dependencies. Ensure yarn.lock is committed.\",\n          });\n        }\n      }\n    }\n  },\n\n  async onPostBuild({ inputs, utils }) {\n    const repoRoot = process.cwd();\n    const dirs = inputs.dirs;\n\n    for (const dir of dirs) {\n      const key = makeKey({ dir, repoRoot });\n      const abs = path.resolve(repoRoot, dir);\n\n      if (!dirExists(abs)) {\n        utils.status.show({\n          title: `Cache not saved (missing directory)`,\n          summary: `${abs} does not exist.`,\n        });\n        continue;\n      }\n\n      const hasFiles = fs.readdirSync(abs).length > 0;\n      if (!hasFiles) {\n        utils.status.show({\n          title: `Cache not saved (empty directory)`,\n          summary: `${abs} is empty.`,\n        });\n        continue;\n      }\n\n      await saveDir(utils, abs, key);\n    }\n  },\n};\n"
  },
  {
    "path": "netlify-plugins/cache-docusaurus-dirs-api/manifest.yml",
    "content": "name: cache-docusaurus-dirs-api\ninputs:\n  - name: dirs\n    description: Array of directories to cache (relative to repo root)\n    required: true\n"
  },
  {
    "path": "netlify-plugins/cache-docusaurus-dirs-file/index.js",
    "content": "// Netlify Build Plugin to cache directories using file-based caching (stable)\n// - Docusaurus-friendly: cache \".docusaurus\", \"node_modules\", and \"build\"\n// - node_modules auto-invalidation via yarn.lock hash\n// - On-demand busting via CACHE_VERSION env var per environment\n// - Per-branch cache isolation by default\n\nconst path = require(\"path\");\nconst fs = require(\"fs\");\nconst crypto = require(\"crypto\");\n\nfunction dirExists(dirPath) {\n  try {\n    const stat = fs.statSync(dirPath);\n    return stat.isDirectory();\n  } catch {\n    return false;\n  }\n}\n\nfunction fileSha256(filePath) {\n  try {\n    const data = fs.readFileSync(filePath);\n    return crypto.createHash(\"sha256\").update(data).digest(\"hex\");\n  } catch {\n    return null;\n  }\n}\n\nfunction makeKey({ dir, repoRoot }) {\n  const cacheVersion = process.env.CACHE_VERSION || \"\";\n  const perBranch = process.env.CACHE_PER_BRANCH !== \"false\"; // default true\n  const branch = process.env.NETLIFY_BRANCH || process.env.BRANCH || \"unknown\";\n\n  let key = dir;\n\n  // Auto-invalidate node_modules with yarn.lock changes\n  if (dir === \"node_modules\") {\n    const yarnLockPath = path.join(repoRoot, \"yarn.lock\");\n    const hash = fileSha256(yarnLockPath);\n    if (hash) {\n      key = `${key}@yarn-${hash.slice(0, 16)}`;\n    }\n  }\n\n  // On-demand busting\n  if (cacheVersion) {\n    key = `${key}@cv-${cacheVersion}`;\n  }\n\n  // Per-branch isolation\n  if (perBranch) {\n    key = `${key}@${branch}`;\n  }\n  return key;\n}\n\nasync function restoreDir(utils, absPath, key) {\n  try {\n    // File-based caching: check if cache exists, then restore\n    const cacheExists = await utils.cache.has(key);\n    if (!cacheExists) {\n      utils.status.show({\n        title: `No cache: ${key}`,\n        summary: `No prior cache for ${absPath}`,\n      });\n      return false;\n    }\n\n    const restored = await utils.cache.restore(key);\n    if (restored) {\n      // File-based caching often requires manual copy from cache location\n      // The exact implementation may vary based on Netlify's file-based API\n      utils.status.show({\n        title: `Cache restored: ${key}`,\n        summary: `Restored into ${absPath}`,\n      });\n    } else {\n      utils.status.show({\n        title: `Cache restore failed: ${key}`,\n        summary: `Failed to restore cache for ${absPath}`,\n      });\n    }\n    return restored;\n  } catch (err) {\n    utils.status.show({\n      title: `Cache restore failed: ${key}`,\n      summary: err.message,\n    });\n    return false;\n  }\n}\n\nasync function saveDir(utils, absPath, key) {\n  try {\n    // File-based caching: save directory to cache\n    const saved = await utils.cache.save(key, absPath);\n    utils.status.show({\n      title: saved ? `Cache saved: ${key}` : `Cache skipped: ${key}`,\n      summary: `${saved ? \"Saved\" : \"Skipped\"} from ${absPath}`,\n    });\n    return saved;\n  } catch (err) {\n    utils.status.show({\n      title: `Cache save failed: ${key}`,\n      summary: err.message,\n    });\n    return false;\n  }\n}\n\nmodule.exports = {\n  async onPreBuild({ inputs, utils }) {\n    const repoRoot = process.cwd();\n    const dirs = inputs.dirs;\n\n    for (const dir of dirs) {\n      const key = makeKey({ dir, repoRoot });\n      const abs = path.resolve(repoRoot, dir);\n\n      await restoreDir(utils, abs, key);\n\n      // Guidance for node_modules: ensure yarn.lock exists to keep cache fresh\n      if (dir === \"node_modules\") {\n        const yarnLockPath = path.join(repoRoot, \"yarn.lock\");\n        if (!fs.existsSync(yarnLockPath)) {\n          utils.status.show({\n            title: \"node_modules cache warning\",\n            summary:\n              \"yarn.lock not found. Caching node_modules without yarn.lock can lead to stale dependencies. Ensure yarn.lock is committed.\",\n          });\n        }\n      }\n    }\n  },\n\n  async onPostBuild({ inputs, utils }) {\n    const repoRoot = process.cwd();\n    const dirs = inputs.dirs;\n\n    for (const dir of dirs) {\n      const key = makeKey({ dir, repoRoot });\n      const abs = path.resolve(repoRoot, dir);\n\n      if (!dirExists(abs)) {\n        utils.status.show({\n          title: `Cache not saved (missing directory)`,\n          summary: `${abs} does not exist.`,\n        });\n        continue;\n      }\n\n      const hasFiles = fs.readdirSync(abs).length > 0;\n      if (!hasFiles) {\n        utils.status.show({\n          title: `Cache not saved (empty directory)`,\n          summary: `${abs} is empty.`,\n        });\n        continue;\n      }\n\n      await saveDir(utils, abs, key);\n    }\n  },\n};\n"
  },
  {
    "path": "netlify-plugins/cache-docusaurus-dirs-file/manifest.yml",
    "content": "name: cache-docusaurus-dirs-file\ninputs:\n  - name: dirs\n    description: Array of directories to cache (relative to repo root)\n    required: true\n"
  },
  {
    "path": "netlify.toml",
    "content": "# Build configs\n\n[build]\n  command = \"make netlify-build\"\n  publish = \"build\"\n\n\n# Cache Docusaurus internal cache (.docusaurus) with optional CACHE_VERSION per environment\n[[plugins]]\npackage = \"./netlify-plugins/cache-docusaurus-dirs-file\"\n\n  [plugins.inputs]\n  dirs = [\".docusaurus\", \"node_modules\", \"build\"]\n\n[context.production.environment]\n  SITE_URL = \"https://helm.sh\"\n  CACHE_VERSION = \"prod-v1\"\n\n[context.deploy-preview.environment]\n  CACHE_VERSION = \"preview-v1\"\n  CACHE_PER_BRANCH = \"false\"\n\n[context.branch-deploy.environment]\n  CACHE_VERSION = \"branch-v1\"\n\n# Go module import support handled by static HTML files in /static/\n# These paths serve HTML with go-import meta tags + client-side redirects\n\n# redirect Go package lookups\n[[redirects]]\n  from = \"/helm/v3/*\"\n  to = \"/helm/v3\"\n  status = 200\n\n[[redirects]]\n  from = \"/helm/v2/*\"\n  to = \"/helm/v2\"\n  status = 200\n\n# custom external redirects\n[[redirects]]\n  from = \"/calendar/release\"\n  to = \"https://calendar.google.com/calendar/u/0/embed?src=8tji8e0obp5skr2pval9g55ftk@group.calendar.google.com\"\n  status = 302\n\n[[redirects]]\n  from = \"/v4-launch-party-sponsorship\"\n  to = \"https://docs.google.com/document/d/10cyzggPiLeLz169cDF1UaUMmM4uZx6rO3Bw9rRQRjJA/edit?usp=sharing\"\n  status = 302\n\n# RSS feed alias\n[[redirects]]\n  from = \"/blog/index.xml\"\n  to = \"/blog/rss.xml\"\n  status = 200\n\n# docs.helm.sh to current domain\n[[redirects]]\n  from = \"https://docs.helm.sh/*\"\n  to = \"https://helm.sh/docs/:splat\"\n\n# v3 redirects\n\n[[redirects]]\n  from = \"/docs/topics/v2_v3_migration\"\n  to = \"/docs/v3/topics/v2_v3_migration\"\n\n[[redirects]]\n  from = \"/docs/faq/changes_since_helm2\"\n  to = \"/docs/v3/faq/changes_since_helm2\"\n\n[[redirects]]\n  from = \"/docs/faq/troubleshooting\"\n  to = \"/docs/v3/faq/troubleshooting\"\n\n# v2.helm.sh redirects\n# TODO: Change status codes below from 302 to 301 after Docusaurus cutover verification\n\n# v2.helm.sh to current domain\n[[redirects]]\n  from = \"https://v2.helm.sh/docs/*\"\n  to = \"https://helm.sh/docs/v2/:splat\"\n  status = 302\n\n# v2.helm.sh categories not present in v3 docs\n# Category-level redirects only (no wildcard) because v2.helm.sh did not have\n# sub-pages, only anchors to one combined category page\n# Note URL fragments are not supported by Netlify redirects\n[[redirects]]\n  from = \"/docs/using_helm/\"\n  to = \"/docs/v2/using_helm/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/developing_charts/\"\n  to = \"/docs/v2/developing_charts/\"\n  status = 302\n\n# v2.helm.sh categories with new corresponding v3 paths\n[[redirects]]\n  from = \"/docs/related/\"\n  to = \"/community/related/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/architecture/\"\n  to = \"/docs/topics/architecture/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/developers/\"\n  to = \"/community/developers/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/history/\"\n  to = \"/community/history/\"\n  status = 302\n\n# START - Hugo frontmatter aliases redirects, removed during Docusaurus migration\n[[redirects]]\n  from = \"/docs/advanced_helm_techniques\"\n  to = \"/docs/topics/advanced/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/chart_repository/\"\n  to = \"/docs/topics/chart_repository/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/chart_repository_sync_example/\"\n  to = \"/docs/howto/chart_repository_sync_example/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/chart_tests/\"\n  to = \"/docs/topics/chart_tests/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/charts_hooks/\"\n  to = \"/docs/topics/charts_hooks/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/charts_tips_and_tricks/\"\n  to = \"/docs/howto/charts_tips_and_tricks/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/gosdk\"\n  to = \"/docs/sdk/gosdk/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/install/\"\n  to = \"/docs/intro/install/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/kubernetes_distros/\"\n  to = \"/docs/topics/kubernetes_distros/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/localization/\"\n  to = \"/community/localization/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/permissions_sql_storage_backend/\"\n  to = \"/docs/topics/permissions_sql_storage_backend/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/plugins/\"\n  to = \"/docs/topics/plugins/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/provenance/\"\n  to = \"/docs/topics/provenance/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/quickstart/\"\n  to = \"/docs/intro/quickstart/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/rbac/\"\n  to = \"/docs/topics/rbac/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/registries/\"\n  to = \"/docs/topics/registries/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/chart_best_practices/\"\n  to = \"/docs/chart_best_practices/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/chart_best_practices/conventions/\"\n  to = \"/docs/chart_best_practices/conventions/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/chart_best_practices/custom_resource_definitions/\"\n  to = \"/docs/chart_best_practices/custom_resource_definitions/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/chart_best_practices/dependencies/\"\n  to = \"/docs/chart_best_practices/dependencies/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/chart_best_practices/labels/\"\n  to = \"/docs/chart_best_practices/labels/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/chart_best_practices/pods/\"\n  to = \"/docs/chart_best_practices/pods/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/chart_best_practices/rbac/\"\n  to = \"/docs/chart_best_practices/rbac/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/chart_best_practices/templates/\"\n  to = \"/docs/chart_best_practices/templates/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/chart_best_practices/values/\"\n  to = \"/docs/chart_best_practices/values/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/topics/faq/\"\n  to = \"/docs/faq/\"\n  status = 302\n\n[[redirects]]\n  from = \"/intro/getting_started/\"\n  to = \"/docs/chart_template_guide/getting_started/\"\n  status = 302\n\n[[redirects]]\n  from = \"/topics/chart_template_guide/\"\n  to = \"/docs/chart_template_guide/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/k8s_apis/\"\n  to = \"/docs/topics/kubernetes_apis/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/library_charts/\"\n  to = \"/docs/topics/library_charts/\"\n  status = 302\n# Additional redirects for Hugo frontmatter aliases removed during v3 migration\n[[redirects]]\n  from = \"/docs/developers/\"\n  to = \"/community/developers/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/history/\"\n  to = \"/community/history/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/related/\"\n  to = \"/community/related/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/faq/\"\n  to = \"/docs/faq/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/using_helm/\"\n  to = \"/docs/intro/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/architecture/\"\n  to = \"/docs/topics/architecture/\"\n  status = 302\n\n[[redirects]]\n  from = \"/docs/developing_charts/\"\n  to = \"/docs/topics/charts/\"\n  status = 302\n\n[[redirects]]\n  from = \"/developing_charts/\"\n  to = \"/docs/topics/charts/\"\n  status = 302\n\n# END - Hugo frontmatter aliases redirects\n\n\n# Moved to community section\n[[redirects]]\n  from = \"/docs/community/*\"\n  to = \"/community/:splat\"\n  status = 302\n\n# Community release policy\n[[redirects]]\n  from = '/docs/topics/release_policy'\n  to = '/community/release_policy'\n  status = 302\n\n[[redirects]]\n  from = '/docs/v3/topics/release_policy'\n  to = '/community/release_policy'\n  status = 302\n\n# Community release policy (i18n/ko)\n[[redirects]]\n  from = '/ko/docs/v3/topics/release_policy'\n  to = '/ko/community/release_policy'\n  status = 302\n\n# Community release policy (i18n/uk)\n[[redirects]]\n  from = '/uk/docs/topics/release_policy'\n  to = '/uk/community/release_policy'\n  status = 302\n\n[[redirects]]\n  from = '/uk/docs/v3/topics/release_policy'\n  to = '/uk/community/release_policy'\n  status = 302\n\n# Community release policy (i18n/zh)\n[[redirects]]\n  from = '/zh/docs/v3/topics/release_policy'\n  to = '/zh/community/release_policy'\n  status = 302\n"
  },
  {
    "path": "package.json",
    "content": "{\n  \"name\": \"helm-www\",\n  \"version\": \"0.0.0\",\n  \"private\": true,\n  \"scripts\": {\n    \"docusaurus\": \"docusaurus\",\n    \"start\": \"docusaurus start\",\n    \"build\": \"docusaurus build\",\n    \"swizzle\": \"docusaurus swizzle\",\n    \"deploy\": \"docusaurus deploy\",\n    \"clear\": \"docusaurus clear\",\n    \"serve\": \"docusaurus serve\",\n    \"write-translations\": \"docusaurus write-translations\",\n    \"write-heading-ids\": \"docusaurus write-heading-ids\",\n    \"migrate:v2\": \"node scripts/migrate-v2-docs.js\",\n    \"migrate:v3\": \"node scripts/migrate-v3-docs.js\",\n    \"download-remote-community\": \"docusaurus download-remote-community\",\n    \"clear-remote-community\": \"docusaurus clear-remote-community\"\n  },\n  \"dependencies\": {\n    \"@docusaurus/core\": \"3.9.2\",\n    \"@docusaurus/preset-classic\": \"3.9.2\",\n    \"@mdx-js/react\": \"^3.0.0\",\n    \"@octokit/rest\": \"^22.0.1\",\n    \"clsx\": \"^2.0.0\",\n    \"docusaurus-plugin-remote-content\": \"^4.0.0\",\n    \"js-yaml\": \"^4.1.1\",\n    \"ora\": \"^9.0.0\",\n    \"prism-react-renderer\": \"^2.3.0\",\n    \"raw-loader\": \"^4.0.2\",\n    \"react\": \"^19.0.0\",\n    \"react-dom\": \"^19.0.0\",\n    \"react-icons\": \"^5.5.0\",\n    \"simple-git\": \"^3.32.3\"\n  },\n  \"devDependencies\": {\n    \"@docusaurus/module-type-aliases\": \"3.9.2\",\n    \"@docusaurus/types\": \"3.9.2\",\n    \"baseline-browser-mapping\": \"^2.10.21\",\n    \"jsdom\": \"^27.0.1\"\n  },\n  \"browserslist\": {\n    \"production\": [\n      \">0.5%\",\n      \"not dead\",\n      \"not op_mini all\"\n    ],\n    \"development\": [\n      \"last 3 chrome version\",\n      \"last 3 firefox version\",\n      \"last 5 safari version\"\n    ]\n  },\n  \"engines\": {\n    \"node\": \">=20.0\"\n  },\n  \"resolutions\": {\n    \"gray-matter/js-yaml\": \"3.14.2\",\n    \"serialize-javascript\": \">=7.0.5\",\n    \"path-to-regexp\": \"0.1.13\",\n    \"minimatch\": \">=3.1.3\",\n    \"browserslist\": \"^4.28.1\"\n  }\n}\n"
  },
  {
    "path": "postcss.config.js",
    "content": "module.exports = {\n\tplugins: {\n\t\tautoprefixer: {}\n\t},\n}\n"
  },
  {
    "path": "remote-content_community.js",
    "content": "/**\n * Configuration for the \"community\" instance of docusaurus-plugin-remote-content\n * Imports documentation from the helm/community GitHub repository\n */\n\nmodule.exports = {\n  // Source repository information\n  sourceRepo: \"https://github.com/helm/community\",\n  sourceBaseUrl: \"https://raw.githubusercontent.com/helm/community/refs/heads/main/\",\n\n  // Files to import with their transformations\n  files: {\n    // Simple files with no modifications\n    \"blog-topics.md\": {},\n    \"code-of-conduct.md\": {},\n    \"communication.md\": {},\n    \"incubator.md\": {},\n    \"stable-repo-charts-new-locations.md\": {},\n    \"user-profiles.md\": {},\n\n    // Files with modifications\n    \"README.md\": {\n      meta: {\n        sidebar_position: 1,\n      },\n      links: {\n        \"https://github.com/helm/community/tree/main/art\": \"/community/art\",\n      },\n    },\n\n    \"MAINTAINERS.md\": {},\n\n    \"SECURITY.md\": {\n      meta: {\n        sidebar_label: \"Helm Security\",\n      },\n      links: {\n        \"README.md\": \"/community\",\n      },\n    },\n\n    \"governance/README.md\": {\n      meta: {\n        sidebar_label: \"Governance\",\n        title: \"Governance Introduction\",\n        id: \"helm-governance\",\n        sidebar_position: 9,\n      },\n      links: {\n        \"governance.md\": \"/community/governance/governance\",\n        \"../MAINTAINERS.md\": \"/community/MAINTAINERS\",\n      },\n    },\n\n    \"governance/governance.md\": {\n      meta: {\n        sidebar_label: \"Rules\",\n        title: \"Governance Rules\",\n        slug: \"governance\",\n      },\n    },\n\n    // Art files\n    \"art/readme.md\": {\n      meta: {\n        title: \"Styleguide\",\n      },\n    },\n\n    // Meeting notes - automatically converted from .txt to .md\n    \"meeting-notes/2017.txt\": {},\n    \"meeting-notes/2018.txt\": {},\n    \"meeting-notes/2019.txt\": {},\n    \"meeting-notes/2020.txt\": {},\n    \"meeting-notes/2021.txt\": {},\n\n    // HIPs\n    \"hips/README.md\": {},\n    \"hips/hip-0001.md\": {},\n    \"hips/hip-0002.md\": {},\n    \"hips/hip-0003.md\": {},\n    \"hips/hip-0004.md\": {},\n    \"hips/hip-0005.md\": {\n      links: {\n        \"https://github.com/helm/community/blob/master/governance/governance.md\": \"/community/governance/governance\",\n      },\n    },\n    \"hips/hip-0006.md\": {},\n    \"hips/hip-0007.md\": {\n      links: {\n        \"https://github.com/helm/community/blob/master/governance/governance.md\": \"/community/governance/governance\",\n        \"../maintainer-groups.yaml\": \"https://github.com/helm/community/blob/main/maintainer-groups.yaml\",\n      },\n    },\n    \"hips/hip-0008.md\": {},\n    \"hips/hip-0009.md\": {\n      links: {\n        \"../security.md\": \"../SECURITY.md\",\n      },\n    },\n    \"hips/hip-0010.md\": {},\n    \"hips/hip-0011.md\": {},\n    \"hips/hip-0012.md\": {\n      links: {\n        \"https://github.com/helm/community/blob/main/user-profiles.md\": \"/community/user-profiles\",\n      },\n    },\n    \"hips/hip-0014.md\": {\n      links: {\n        \"https://github.com/helm/community/tree/main/governance\": \"/community/governance/governance\",\n        \"https://github.com/helm/community/blob/main/Teams.md\": \"https://github.com/helm/community/blob/main/maintainer-groups.yaml\",\n      },\n    },\n    \"hips/hip-0015.md\": {},\n    \"hips/hip-0016.md\": {},\n    \"hips/hip-0017.md\": {},\n    \"hips/hip-0018.md\": {},\n    \"hips/hip-0019.md\": {},\n    \"hips/hip-0020.md\": {},\n    \"hips/hip-0021.md\": {},\n    \"hips/hip-0022.md\": {},\n    \"hips/hip-0023.md\": {},\n    \"hips/hip-0024.md\": {},\n    \"hips/hip-0025.md\": {\n      links: {\n        \"https://github.com/helm/community/blob/main/user-profiles.md\": \"/community/user-profiles\",\n      },\n    },\n    \"hips/hip-0026.md\": {\n      links: {\n        \"https://github.com/helm/community/blob/main/hips/hip-0012.md\": \"/community/hips/hip-0012\",\n        \"https://github.com/helm/community/blob/main/hips/archives/helm/distributed-search.md\": \"/community/hips/archives/helm/distributed-search\",\n      },\n    },\n\n    // HIP Archives\n    \"hips/archives/README.md\": {},\n    \"hips/archives/monocular/1.0-improvements.md\": {\n      links: {\n        \"https://github.com/helm/community/blob/master/proposals/distributed-search.md\": \"/community/hips/archives/helm/distributed-search\",\n      },\n    },\n    \"hips/archives/helm/distributed-search.md\": {},\n    \"hips/archives/helm/helm-v3/000-helm-v3.md\": {\n      links: {\n        \"../../../user-profiles.md\": \"../../../../user-profiles.md\",\n      },\n    },\n    \"hips/archives/helm/helm-v3/001-charts.md\": {},\n    \"hips/archives/helm/helm-v3/002-events.md\": {},\n    \"hips/archives/helm/helm-v3/003-state.md\": {},\n    \"hips/archives/helm/helm-v3/004-hooks.md\": {},\n    \"hips/archives/helm/helm-v3/005-plugins.md\": {},\n    \"hips/archives/helm/helm-v3/006-repositories.md\": {},\n    \"hips/archives/helm/helm-v3/007-security.md\": {},\n    \"hips/archives/helm/helm-v3/008-controller.md\": {},\n    \"hips/archives/helm/helm-v3/009-package_manager.md\": {},\n    \"hips/archives/helm/helm-v3/010-removed.md\": {},\n    \"hips/archives/helm/helm-v3/011-user_stories.md\": {\n      links: {\n        \"../user-profiles.md\": \"../../../../user-profiles.md\",\n      },\n    },\n    \"hips/archives/helm/helm-v3/012-chart-dev-stories.md\": {},\n    \"hips/archives/helm/helm-v3/research/package-manager-ux.md\": {},\n  },\n};\n"
  },
  {
    "path": "scripts/migrate-v2-docs.js",
    "content": "#!/usr/bin/env node\n\nconst { startFresh, restoreSourceContent, skaffoldMajorVersion } = require(\"./util/util-migration.js\");\nconst { copyV2DocsToDocusaurus } = require(\"./v2/copy-files.js\");\nconst path = require('path');\n\n/**\n * Master orchestrator for v2 docs migration\n * Simple migration that fetches v2 menu structure and copies files\n */\nasync function migrateV2Docs(majorVersion = 2) {\n  console.log(\"🚀 Starting v2 docs migration...\");\n\n  try {\n    // Step 1: Start with clean slate and restore source content\n    console.log(\"\\n📋 Step 1: Starting fresh...\");\n    startFresh(majorVersion);\n    restoreSourceContent(majorVersion);\n\n    // Step 2: Setup Docusaurus version structure (creates versioned_docs/version-2)\n    console.log(\"\\n📋 Step 2: Setting up Docusaurus version structure...\");\n    skaffoldMajorVersion(majorVersion);\n\n    // Step 3: Generate v2 menu structure\n    console.log(\"\\n📋 Step 3: Generating v2 menu structure...\");\n    const { fetchV2Navigation } = require(\"./v2/menu-generate.js\");\n    await fetchV2Navigation();\n\n    // Step 4: Copy v2 files using the structured menu\n    console.log(\"\\n📋 Step 4: Processing v2 files with Docusaurus structure...\");\n    copyV2DocsToDocusaurus();\n\n    // Step 5: Fix v2 href differences (link paths)\n    console.log(\"\\n📋 Step 5: Fixing v2 href differences...\");\n    const path = require('path');\n    const { processHrefDifferences } = require(\"./util/href-diffs-process.js\");\n    const differencesFile = path.join(__dirname, 'v2/href-diffs.json');\n    processHrefDifferences(majorVersion, differencesFile);\n\n    console.log(\"\\n🎉 v2 docs migration completed successfully!\");\n  } catch (error) {\n    console.error(\"❌ Migration failed:\", error.message);\n    console.error(\"Stack trace:\", error.stack);\n    process.exit(1);\n  }\n}\n\n// Run if called directly\nif (require.main === module) {\n  const majorVersion = process.argv[2] ? parseInt(process.argv[2]) : 2;\n  migrateV2Docs(majorVersion);\n}\n\nmodule.exports = { migrateV2Docs };\n"
  },
  {
    "path": "scripts/migrate-v3-docs.js",
    "content": "#!/usr/bin/env node\n\nconst { processHelmFiles } = require('./v3/process-helm-files.js');\nconst { removeAliasesFromFiles } = require('./v3/remove-aliases.js');\nconst { migrateSdkSection } = require(\"./v3/migrate-sdk-section.js\");\nconst { addNetlifyRedirects } = require(\"./v3/add-netlify-redirects.js\");\nconst {\n  startFresh,\n  restoreSourceContent,\n  skaffoldMajorVersion,\n  moveDocs,\n  deleteDeprecatedFiles,\n  renameIndexFilesToMdx,\n  replaceWeightWithSidebarPosition,\n  addMainIndexMetadata,\n  addDocsIndexLists,\n  renameCommandsToHelm,\n} = require(\"./util/util-migration.js\");\nconst { applyAllTextReplacements } = require(\"./util/util-text-replacements.js\");\nconst { convertRelativeLinksToAbsolute } = require(\"./util/util-docusaurus-links.js\");\nconst { processHrefDifferences } = require(\"./util/href-diffs-process.js\");\n\n/**\n * Master orchestrator for v3 docs migration\n * Replaces migrate-docs.sh with idiomatic Node.js\n */\nasync function migrateV3Docs(majorVersion = 3) {\n  console.log(\"🚀 Starting v3 docs migration...\");\n\n  try {\n    // Step 1: Start with clean slate (reset directories and restore from git main)\n    console.log(\"\\n📋 Step 1: Starting fresh...\");\n    startFresh(majorVersion);\n    restoreSourceContent(majorVersion);\n\n    // Step 2: Setup Docusaurus version structure (idempotent)\n    console.log(\"\\n📋 Step 2: Setting up Docusaurus version structure...\");\n    skaffoldMajorVersion(majorVersion);\n\n    // Step 3: Move docs from Hugo to Docusaurus structure\n    console.log(\"\\n📋 Step 3: Moving docs...\");\n    moveDocs(majorVersion);\n\n    // Step 4: Delete files with deprecated section\n    console.log(\"\\n📋 Step 4: Deleting deprecated files...\");\n    deleteDeprecatedFiles(majorVersion);\n\n    // Step 5: Rename index.md → index.mdx files\n    console.log(\"\\n📋 Step 5: Renaming index files...\");\n    renameIndexFilesToMdx(majorVersion);\n\n    // Step 6: Replace Hugo weight with Docusaurus sidebar_position\n    console.log(\"\\n📋 Step 6: Converting frontmatter...\");\n    replaceWeightWithSidebarPosition(majorVersion);\n\n    // Step 7: Add metadata to main index file\n    console.log(\"\\n📋 Step 7: Adding main index metadata...\");\n    addMainIndexMetadata(majorVersion);\n\n    // Step 8: Migrate SDK section (import Go files and apply transformations)\n    console.log(\"\\n📋 Step 8: Migrating SDK section...\");\n    migrateSdkSection(majorVersion);\n\n    // Step 9: Rename commands directories to helm in i18n\n    console.log(\"\\n📋 Step 9: Renaming commands to helm in i18n directories...\");\n    renameCommandsToHelm(majorVersion);\n\n    // Step 10: Apply text replacements (Hugo shortcodes and per-file rules)\n    console.log(\"\\n📋 Step 10: Applying text replacements...\");\n    applyAllTextReplacements(majorVersion);\n\n    // Step 11: Process Helm files (H2 → titles, add slug/id metadata)\n    console.log(\"\\n📋 Step 11: Processing Helm files...\");\n    processHelmFiles();\n\n    // Step 12: Remove all aliases from v3 files\n    console.log(\"\\n📋 Step 12: Removing aliases...\");\n    removeAliasesFromFiles();\n\n    // Step 13: Add DocCardList components to index pages\n    console.log(\"\\n📋 Step 13: Adding DocCardList components...\");\n    addDocsIndexLists(majorVersion);\n\n    // Step 14: Add netlify redirects for removed aliases\n    console.log(\"\\n📋 Step 14: Adding netlify redirects...\");\n    addNetlifyRedirects();\n\n    // Step 15: Process href differences (fix broken links)\n    console.log(\"\\n📋 Step 15: Processing href differences...\");\n    processHrefDifferences(majorVersion, `./scripts/v${majorVersion}/href-diffs.json`);\n\n    // Step 16: Convert all relative links to absolute Docusaurus paths\n    console.log(\"\\n📋 Step 16: Converting relative links to absolute paths...\");\n    convertRelativeLinksToAbsolute(majorVersion);\n\n    console.log(\"\\n🎉 v3 docs migration completed successfully!\");\n  } catch (error) {\n    console.error(\"❌ Migration failed:\", error.message);\n    console.error(\"Stack trace:\", error.stack);\n    process.exit(1);\n  }\n}\n\n// Main execution\nif (require.main === module) {\n  migrateV3Docs();\n}\n\nmodule.exports = { migrateV3Docs };\n"
  },
  {
    "path": "scripts/regenerate-cli-docs.mjs",
    "content": "#!/usr/bin/env node\n\nimport { execSync } from 'child_process';\nimport fs from 'fs';\nimport path from 'path';\nimport { fileURLToPath } from 'url';\nimport { tmpdir } from 'os';\n\n// ESM compatibility for __dirname\nconst __filename = fileURLToPath(import.meta.url);\nconst __dirname = path.dirname(__filename);\nconst PROJECT_ROOT = path.dirname(__dirname);\n\n/**\n * Extract major version from a version string (e.g., v3.19.0 -> 3, v4.0.0-alpha.1 -> 4)\n */\nfunction getMajorVersion(version) {\n  const match = version.match(/^v(\\d+)/);\n  return match ? match[1] : null;\n}\n\n/**\n * Get latest Helm version from get.helm.sh script\n */\nasync function getHelmLatest() {\n  try {\n    const response = await fetch('https://get.helm.sh');\n    const text = await response.text();\n    const match = text.match(/v\\d+\\.\\d+\\.\\d+/);\n    if (match) {\n      return match[0];\n    }\n    throw new Error('No version found in get.helm.sh script');\n  } catch (error) {\n    console.error('Error fetching latest Helm version:', error.message);\n    process.exit(1);\n  }\n}\n\n/**\n * Regenerate Helm CLI documentation\n */\nfunction regenerateDocs(helmVersion, versionDir) {\n  console.log('📦 Regenerating Helm CLI documentation...');\n\n  const tempDir = fs.mkdtempSync(path.join(tmpdir(), 'helm-'));\n\n  try {\n    // Download and install Helm\n    console.log(`  📥 Downloading Helm ${helmVersion}...`);\n    process.env.DESIRED_VERSION = helmVersion;\n    process.env.HELM_INSTALL_DIR = tempDir;\n\n    // Download helm binary directly\n    const arch = process.arch === 'x64' ? 'amd64' : process.arch === 'arm64' ? 'arm64' : 'amd64';\n    const platform = process.platform === 'darwin' ? 'darwin' : 'linux';\n    const helmUrl = `https://get.helm.sh/helm-${helmVersion}-${platform}-${arch}.tar.gz`;\n\n    execSync(`\n      cd \"${tempDir}\" && \\\n      curl -fsSL -o helm.tar.gz \"${helmUrl}\" && \\\n      tar -xzf helm.tar.gz && \\\n      mv ${platform}-${arch}/helm ./helm && \\\n      chmod +x ./helm\n    `, { stdio: 'inherit' });\n\n    // Set environment variables to match Linux defaults\n    process.env.HOME = '~';\n    process.env.HELM_CACHE_HOME = '~/.cache/helm';\n    process.env.HELM_CONFIG_HOME = '~/.config/helm';\n    process.env.HELM_DATA_HOME = '~/.local/share/helm';\n\n    // Create helm directory and generate docs\n    const helmDocsDir = path.join(PROJECT_ROOT, versionDir, 'helm');\n    fs.mkdirSync(helmDocsDir, { recursive: true });\n\n    console.log(`  📝 Generating documentation in ${versionDir}/helm/...`);\n    execSync(`\"${tempDir}/helm\" docs --type markdown --generate-headers`, {\n      cwd: helmDocsDir,\n      stdio: 'inherit'\n    });\n\n    console.log('  ✅ Documentation generated successfully');\n  } finally {\n    // Clean up temp directory\n    fs.rmSync(tempDir, { recursive: true, force: true });\n  }\n}\n\n/**\n * Delete deprecated files with 'section: deprecated' frontmatter\n */\nfunction deleteDeprecatedFiles(helmDir) {\n  console.log('🗑️  Removing deprecated files...');\n\n  const files = fs.readdirSync(helmDir).filter(file =>\n    file.endsWith('.md') && file !== 'index.md' && file !== 'index.mdx'\n  );\n\n  let deletedCount = 0;\n\n  files.forEach(fileName => {\n    const filePath = path.join(helmDir, fileName);\n    try {\n      const content = fs.readFileSync(filePath, 'utf8');\n\n      // Check for deprecated section in frontmatter\n      const frontmatterMatch = content.match(/^---\\n([\\s\\S]*?)\\n---/);\n      if (frontmatterMatch) {\n        const frontmatter = frontmatterMatch[1];\n        if (frontmatter.includes('section: deprecated')) {\n          fs.unlinkSync(filePath);\n          console.log(`    🗑️  Deleted: ${fileName}`);\n          deletedCount++;\n        }\n      }\n    } catch (error) {\n      console.warn(`    ⚠️  Error checking ${fileName}: ${error.message}`);\n    }\n  });\n\n  if (deletedCount > 0) {\n    console.log(`  ✅ Removed ${deletedCount} deprecated files`);\n  }\n}\n\n/**\n * Rename index files to .mdx format\n */\nfunction renameIndexFilesToMdx(helmDir) {\n  console.log('🔄 Renaming index files to .mdx...');\n\n  let renamedCount = 0;\n\n  // Check for _index.md or index.md\n  ['_index.md', 'index.md'].forEach(fileName => {\n    const oldPath = path.join(helmDir, fileName);\n    if (fs.existsSync(oldPath)) {\n      const newPath = path.join(helmDir, 'index.mdx');\n      fs.renameSync(oldPath, newPath);\n      console.log(`    🔄 Renamed: ${fileName} → index.mdx`);\n      renamedCount++;\n    }\n  });\n\n  if (renamedCount > 0) {\n    console.log(`  ✅ Renamed ${renamedCount} index files`);\n  }\n}\n\n/**\n * Create or update main index file\n */\nfunction createOrUpdateIndexFile(helmDir) {\n  console.log('📝 Creating/updating index.mdx file...');\n\n  const indexPath = path.join(helmDir, 'index.mdx');\n\n  // Create the index.mdx content\n  const indexContent = `---\ntitle: Helm Commands\ndescription: Documentation for the full list of helm CLI commands.\nsidebar_position: 6\nid: helm-category\n---\n\n# Helm Commands\n\nHere you'll find the list of CLI commands for Helm, with help info on their usage.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n`;\n\n  fs.writeFileSync(indexPath, indexContent);\n  console.log('  ✅ Index file created/updated');\n}\n\n/**\n * Process Helm command files - extract H2 title and set as frontmatter title\n */\nfunction processHelmFiles(helmDir) {\n  console.log('🔧 Processing Helm command files...');\n\n  const files = fs.readdirSync(helmDir).filter(file =>\n    file.endsWith('.md') && file !== 'index.md' && file !== 'index.mdx'\n  );\n\n  let processedCount = 0;\n\n  files.forEach(fileName => {\n    const filePath = path.join(helmDir, fileName);\n\n    try {\n      let content = fs.readFileSync(filePath, 'utf8');\n\n      // Find first H2 heading\n      const h2Match = content.match(/^## (.+)$/m);\n      if (h2Match) {\n        const title = h2Match[1];\n\n        // Remove the H2 line and any following blank line\n        content = content.replace(/^## .+\\n(\\n)?/m, '');\n\n        // Parse existing frontmatter if it exists\n        let frontmatter = {};\n        let restContent = content;\n\n        if (content.startsWith('---')) {\n          const frontmatterMatch = content.match(/^---\\n([\\s\\S]*?)\\n---\\n([\\s\\S]*)$/);\n          if (frontmatterMatch) {\n            // Parse existing frontmatter\n            const frontmatterText = frontmatterMatch[1];\n            frontmatterText.split('\\n').forEach(line => {\n              const match = line.match(/^(\\w+):\\s*(.*)$/);\n              if (match && match[1] !== 'title') {\n                // Keep all existing frontmatter except title\n                frontmatter[match[1]] = match[2].replace(/^[\"']|[\"']$/g, '');\n              }\n            });\n            restContent = frontmatterMatch[2];\n          }\n        }\n\n        // Set the title (lowercase, no quotes)\n        frontmatter.title = title;\n\n        // Special handling for helm.md - add slug\n        if (fileName === 'helm.md') {\n          frontmatter.slug = 'helm';\n        }\n\n        // Build new content with updated frontmatter\n        const frontmatterLines = Object.entries(frontmatter)\n          .map(([key, value]) => `${key}: ${value}`)\n          .join('\\n');\n\n        content = `---\n${frontmatterLines}\n---\n${restContent}`;\n\n        fs.writeFileSync(filePath, content);\n        console.log(`    ✅ Processed: ${fileName}`);\n        processedCount++;\n      }\n    } catch (error) {\n      console.error(`    ❌ Error processing ${fileName}: ${error.message}`);\n    }\n  });\n\n  console.log(`  ✅ Processed ${processedCount} files`);\n\n  // Create _category_.json with link to category doc\n  const categoryPath = path.join(helmDir, '_category_.json');\n  const categoryContent = {\n    link: { type: \"doc\", id: \"helm-category\" }\n  };\n\n  fs.writeFileSync(categoryPath, JSON.stringify(categoryContent, null, 2) + '\\n');\n  console.log('  ✅ Created _category_.json');\n}\n\n/**\n * Process href differences for helm files only\n */\nfunction processHelmHrefDifferences(helmDir) {\n  console.log('🔗 Fixing glossary references in helm files...');\n\n  const rules = [\n    {\n      fileName: 'helm_install.md',\n      before: 'docs/glossary/_index.md#chart-archive',\n      after: '../glossary/index.mdx#chart-archive'\n    },\n    {\n      fileName: 'helm_install.md',\n      before: 'docs/glossary/_index.md#linhagem-arquivo-de-linhagem',\n      after: '../glossary/index.mdx#linhagem-arquivo-de-linhagem'\n    }\n  ];\n\n  let fixedCount = 0;\n\n  rules.forEach(rule => {\n    const filePath = path.join(helmDir, rule.fileName);\n\n    if (fs.existsSync(filePath)) {\n      try {\n        let content = fs.readFileSync(filePath, 'utf8');\n\n        // Look for the exact text to replace\n        if (content.includes(rule.before)) {\n          content = content.replace(new RegExp(rule.before.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\$&'), 'g'), rule.after);\n          fs.writeFileSync(filePath, content);\n          console.log(`    🔗 Fixed: ${rule.fileName}`);\n          fixedCount++;\n        }\n      } catch (error) {\n        console.warn(`    ⚠️  Error processing ${rule.fileName}: ${error.message}`);\n      }\n    }\n  });\n\n  if (fixedCount > 0) {\n    console.log(`  ✅ Fixed ${fixedCount} glossary references`);\n  }\n}\n\n/**\n * Convert SEE ALSO links to absolute paths\n */\nfunction convertSeeAlsoLinksToAbsolute(helmDir) {\n  console.log('🔗 Converting SEE ALSO links to absolute paths...');\n\n  const files = fs.readdirSync(helmDir).filter(file =>\n    file.endsWith('.md') || file.endsWith('.mdx')\n  );\n\n  let totalFilesConverted = 0;\n\n  files.forEach(fileName => {\n    const filePath = path.join(helmDir, fileName);\n\n    try {\n      let content = fs.readFileSync(filePath, 'utf8');\n      let hasChanges = false;\n\n      // Pattern for markdown links to helm commands (relative links without path)\n      // Matches: [text](helm.md) or [text](helm_command.md)\n      const helmLinkPattern = /\\[([^\\]]+)\\]\\((helm[^/)]*\\.md)\\)/g;\n\n      content = content.replace(helmLinkPattern, (match, text, link) => {\n        hasChanges = true;\n        // Convert to absolute /helm/ links\n        return `[${text}](/helm/${link})`;\n      });\n\n      if (hasChanges) {\n        fs.writeFileSync(filePath, content);\n        console.log(`    🔗 Converted links in ${fileName}`);\n        totalFilesConverted++;\n      }\n    } catch (error) {\n      console.warn(`    ⚠️  Error processing ${fileName}: ${error.message}`);\n    }\n  });\n\n  if (totalFilesConverted > 0) {\n    console.log(`  ✅ Converted links in ${totalFilesConverted} files`);\n  }\n}\n\n/**\n * Main function\n */\nasync function main() {\n  // Check for help flag\n  if (process.argv[2] === '--help' || process.argv[2] === '-h') {\n    console.log(`Usage: node scripts/regenerate-cli-docs.mjs <helm-version> <target-directory>\n\nRegenerate Helm CLI documentation and apply post-processing.\n\nArguments:\n  helm-version      Required. Helm version to use (e.g., v3.19.0, v4.0.0-rc.1)\n  target-directory  Required. Directory to generate docs in (e.g., docs, versioned_docs/version-3)\n\nExamples:\n  node scripts/regenerate-cli-docs.mjs v3.16.4 versioned_docs/version-3\n  node scripts/regenerate-cli-docs.mjs v4.0.0-rc.1 docs\n  node scripts/regenerate-cli-docs.mjs v4.0.0 versioned_docs/version-4\n\nThe script will:\n1. Download and install the specified Helm version\n2. Generate CLI documentation using 'helm docs' in <target-directory>/helm/\n3. Delete deprecated files\n4. Convert index files to .mdx format\n5. Extract H2 titles as frontmatter\n6. Fix specific href references\n7. Convert relative links to absolute paths`);\n    process.exit(0);\n  }\n\n  // Validate required arguments\n  if (!process.argv[2] || !process.argv[3]) {\n    console.error('Error: Both helm version and target directory are required');\n    console.error('Usage: node scripts/regenerate-cli-docs.mjs <helm-version> <target-directory>');\n    console.error('Run with --help for more information');\n    process.exit(1);\n  }\n\n  // Get arguments\n  const helmVersion = process.argv[2];\n  const versionDir = process.argv[3];\n  const majorVersion = getMajorVersion(helmVersion);\n\n  console.log('===============================================');\n  console.log('Helm CLI Documentation Generator');\n  console.log(`Helm version: ${helmVersion}`);\n  console.log(`Major version: ${majorVersion}`);\n  console.log(`Documentation directory: ${versionDir}`);\n  console.log('===============================================\\n');\n\n  // Step 1: Regenerate docs\n  regenerateDocs(helmVersion, versionDir);\n\n  const helmDir = path.join(PROJECT_ROOT, versionDir, 'helm');\n\n  // Step 2: Delete deprecated files\n  deleteDeprecatedFiles(helmDir);\n\n  // Step 3: Rename index files to .mdx\n  renameIndexFilesToMdx(helmDir);\n\n  // Step 4: Create/update main index file\n  createOrUpdateIndexFile(helmDir);\n\n  // Step 5: Process Helm files (extract H2 titles)\n  processHelmFiles(helmDir);\n\n  // Step 6: Process helm-specific href differences\n  processHelmHrefDifferences(helmDir);\n\n  // Step 7: Convert SEE ALSO links to absolute paths\n  convertSeeAlsoLinksToAbsolute(helmDir);\n\n  console.log('\\n✅ Documentation regeneration complete!');\n}\n\n// Run the script\nmain().catch(error => {\n  console.error('Fatal error:', error);\n  process.exit(1);\n});\n"
  },
  {
    "path": "scripts/util/href-diffs-process.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\nconst { findFiles } = require('./util-file-operations.js');\n\n/**\n * Process href differences and apply link fixes to documentation files\n * Uses the specified href-diffs.json file to determine what href transformations to apply\n * @param {number} majorVersion - Version number (e.g., 2, 3)\n * @param {string} differencesFile - Path to the href-diffs.json file\n */\nfunction processHrefDifferences(majorVersion, differencesFile) {\n  console.log(`🔗 Processing v${majorVersion} href differences and applying link fixes...`);\n\n  let totalFilesProcessed = 0;\n  let totalFixesApplied = 0;\n\n  // Process main version docs\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n\n  if (!fs.existsSync(differencesFile)) {\n    console.warn('⚠️  Href differences file not found:', differencesFile);\n    console.log('Create the differences file first or check the path');\n    return;\n  }\n\n  // Load href differences\n  const hrefDifferences = JSON.parse(fs.readFileSync(differencesFile, 'utf8'));\n  console.log(`📋 Loaded ${hrefDifferences.length} v${majorVersion} href differences`);\n\n  if (fs.existsSync(versionDir)) {\n    console.log(`  📁 Processing main docs: ${versionDir}`);\n    const result = processHrefDifferencesInDirectory(versionDir, hrefDifferences, majorVersion);\n    totalFilesProcessed += result.filesProcessed;\n    totalFixesApplied += result.fixesApplied;\n  }\n\n  // Process translation docs (only for v3 and above)\n  if (majorVersion >= 3) {\n    const i18nDir = 'i18n';\n    if (fs.existsSync(i18nDir)) {\n      const languages = fs.readdirSync(i18nDir, { withFileTypes: true })\n        .filter(dirent => dirent.isDirectory())\n        .map(dirent => dirent.name);\n\n      languages.forEach(lang => {\n        const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`;\n        if (fs.existsSync(translationVersionDir)) {\n          console.log(`  🌐 Processing ${lang} translations: ${translationVersionDir}`);\n          const result = processHrefDifferencesInDirectory(translationVersionDir, hrefDifferences, majorVersion);\n          totalFilesProcessed += result.filesProcessed;\n          totalFixesApplied += result.fixesApplied;\n        }\n      });\n    }\n  }\n\n  console.log(`✅ Applied ${totalFixesApplied} href fixes across ${totalFilesProcessed} files`);\n}\n\n/**\n * Process href differences in a specific directory\n * @param {string} dirPath - Directory to process\n * @param {Array} hrefDifferences - Array of href difference objects\n * @param {number} majorVersion - Major version number\n * @returns {Object} - Results with filesProcessed and fixesApplied\n */\nfunction processHrefDifferencesInDirectory(dirPath, hrefDifferences, majorVersion) {\n  const files = findFiles(dirPath, ['.md', '.mdx']);\n\n  // Group transformations by target file\n  const fileTransforms = {};\n\n  hrefDifferences.forEach(diff => {\n    // Only process actual path hrefs (skip components and regex patterns)\n    if (!diff.after.includes('<') && !diff.after.includes('{{') &&\n        !diff.after.includes('\\\\(') && diff.after !== diff.before) {\n\n      // Group by fileName\n      if (!fileTransforms[diff.fileName]) {\n        fileTransforms[diff.fileName] = {};\n      }\n      fileTransforms[diff.fileName][diff.before] = diff.after;\n      console.log(`  ${diff.fileName}: ${diff.before} → ${diff.after}`);\n    }\n  });\n\n  const totalTransforms = Object.values(fileTransforms).reduce((sum, transforms) => sum + Object.keys(transforms).length, 0);\n  console.log(`📋 Found ${totalTransforms} path transformations for ${Object.keys(fileTransforms).length} files`);\n\n  let updatedCount = 0;\n  let totalFixes = 0;\n\n  files.forEach(filePath => {\n    try {\n      const relativePath = path.relative(dirPath, filePath);\n\n      // Only apply transformations specific to this file\n      if (!fileTransforms[relativePath]) {\n        return; // No transformations for this file\n      }\n\n      let content = fs.readFileSync(filePath, 'utf8');\n      let hasChanges = false;\n\n      // Apply transformations specific to this file\n      Object.entries(fileTransforms[relativePath]).forEach(([fromPath, toPath]) => {\n        // For v2: simple string replacement (no markdown link pattern matching needed)\n        // For v3: look for markdown links containing the old path\n        if (majorVersion === 2) {\n          // V2 uses simple path replacements\n          const beforeRegex = new RegExp(fromPath.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\$&'), 'g');\n          if (content.includes(fromPath)) {\n            content = content.replace(beforeRegex, toPath);\n            hasChanges = true;\n            totalFixes++;\n          }\n        } else {\n          // V3 uses markdown link pattern matching, but also handles raw text for special cases\n          if (fromPath.includes('<') && fromPath.includes('>') || toPath === '') {\n            // Special cases:\n            // 1. Raw text replacement for angle bracket URLs (MDX compilation fixes)\n            // 2. Text deletion (when toPath is empty string)\n            const beforeRegex = new RegExp(fromPath.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\$&'), 'g');\n            if (content.includes(fromPath)) {\n              content = content.replace(beforeRegex, toPath);\n              hasChanges = true;\n              totalFixes++;\n            }\n          } else {\n            // Standard V3 markdown link pattern matching\n            const escapedFrom = fromPath.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\$&');\n            const linkPattern = new RegExp(`(\\\\[[^\\\\]]+\\\\])\\\\(${escapedFrom}\\\\)`, 'g');\n\n            if (content.includes(`](${fromPath})`)) {\n              content = content.replace(linkPattern, `$1(${toPath})`);\n              hasChanges = true;\n              totalFixes++;\n            }\n          }\n        }\n      });\n\n      if (hasChanges) {\n        fs.writeFileSync(filePath, content);\n        console.log(`  🔗 Fixed hrefs: ${relativePath}`);\n        updatedCount++;\n      }\n\n    } catch (error) {\n      console.warn(`  ⚠️  Error processing ${filePath}: ${error.message}`);\n    }\n  });\n\n  return { filesProcessed: updatedCount, fixesApplied: totalFixes };\n}\n\nmodule.exports = {\n  processHrefDifferences\n};\n"
  },
  {
    "path": "scripts/util/util-docusaurus-links.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\n\n// Known categories in Helm docs (directories that should link to index.mdx)\nconst HELM_CATEGORIES = [\n  'intro',\n  'chart_best_practices',\n  'chart_template_guide',\n  'sdk',\n  'faq',\n  'howto',\n  'community',\n  'helm',\n  'topics',\n  'glossary'\n];\n\n/**\n * Check if a path refers to a category (should link to index.mdx)\n * @param {string} pathSegment - Path segment to check\n * @returns {boolean} - True if this is a category\n */\nfunction isCategory(pathSegment) {\n  // Remove trailing slash and leading ./\n  let cleanPath = pathSegment.replace(/\\/$/, '').replace(/^\\.\\//, '');\n\n  // Check if it's a known category\n  return HELM_CATEGORIES.includes(cleanPath);\n}\n\n/**\n * Convert category path to index.mdx path\n * @param {string} categoryPath - Category path\n * @param {number} currentDepth - Current file's depth\n * @param {string} relativePath - Current file's relative path\n * @returns {string} - Absolute path to category index\n */\nfunction convertCategoryPath(categoryPath, currentDepth, relativePath) {\n  // Handle anchors: category#anchor -> /category/index.mdx#anchor\n  let cleanPath = categoryPath;\n  let anchor = '';\n\n  if (cleanPath.includes('#')) {\n    const parts = cleanPath.split('#');\n    cleanPath = parts[0];\n    anchor = '#' + parts.slice(1).join('#');\n  }\n\n  // Remove trailing slash and leading ./\n  cleanPath = cleanPath.replace(/\\/$/, '').replace(/^\\.\\//, '');\n\n  // Convert to absolute category index path\n  const absolutePath = convertToAbsolutePath(cleanPath, currentDepth, relativePath);\n  return `${absolutePath}/index.mdx${anchor}`;\n}\n\n/**\n * Convert relative links to absolute Docusaurus paths\n * This addresses the Docusaurus bug: https://github.com/facebook/docusaurus/issues/10907\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction convertRelativeLinksToAbsolute(majorVersion) {\n  console.log('🔗 Converting relative links to absolute Docusaurus paths...');\n\n  // Process main version docs\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  let totalFilesProcessed = 0;\n  let totalLinksConverted = 0;\n\n  if (fs.existsSync(versionDir)) {\n    console.log(`  📁 Processing main docs: ${versionDir}`);\n    const result = processDirectoryLinks(versionDir);\n    totalFilesProcessed += result.filesProcessed;\n    totalLinksConverted += result.linksConverted;\n  }\n\n  // Process translation docs (only for v3 and above)\n  if (majorVersion >= 3) {\n    const i18nDir = 'i18n';\n    if (fs.existsSync(i18nDir)) {\n      const languages = fs.readdirSync(i18nDir, { withFileTypes: true })\n        .filter(dirent => dirent.isDirectory())\n        .map(dirent => dirent.name);\n\n      languages.forEach(lang => {\n        const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`;\n        if (fs.existsSync(translationVersionDir)) {\n          console.log(`  🌐 Processing ${lang} translations: ${translationVersionDir}`);\n          const result = processDirectoryLinks(translationVersionDir);\n          totalFilesProcessed += result.filesProcessed;\n          totalLinksConverted += result.linksConverted;\n        }\n      });\n    }\n  }\n\n  console.log(`\\n📊 Link conversion summary:`);\n  console.log(`  Files processed: ${totalFilesProcessed}`);\n  console.log(`  Links converted: ${totalLinksConverted}`);\n  console.log('✅ Relative links converted to absolute paths');\n}\n\n/**\n * Process links in a specific directory\n * @param {string} dirPath - Directory path to process\n * @returns {Object} - Results with filesProcessed and linksConverted\n */\nfunction processDirectoryLinks(dirPath) {\n  let filesProcessed = 0;\n  let linksConverted = 0;\n\n  /**\n   * Recursively process directory for .md and .mdx files\n   * @param {string} currentDir - Current directory to process\n   */\n  function processDirectory(currentDir) {\n    const entries = fs.readdirSync(currentDir, { withFileTypes: true });\n\n    entries.forEach(entry => {\n      const fullPath = path.join(currentDir, entry.name);\n\n      if (entry.isDirectory()) {\n        // Recursively process subdirectories\n        processDirectory(fullPath);\n      } else if (entry.isFile() && (entry.name.endsWith('.md') || entry.name.endsWith('.mdx'))) {\n        // Process markdown files\n        const result = processMarkdownFile(fullPath, dirPath);\n        if (result.modified) {\n          filesProcessed++;\n          linksConverted += result.linksConverted;\n        }\n      }\n    });\n  }\n\n  processDirectory(dirPath);\n\n  return { filesProcessed, linksConverted };\n}\n\n/**\n * Process a single markdown file for link conversion\n * @param {string} filePath - Full path to the file\n * @param {string} basePath - Base directory path for calculating relative positions\n * @returns {Object} - Results with modified flag and linksConverted count\n */\nfunction processMarkdownFile(filePath, basePath) {\n  try {\n    const content = fs.readFileSync(filePath, 'utf8');\n    let modifiedContent = content;\n    let linksConverted = 0;\n\n    // Get the current file's directory relative to the base path\n    const relativePath = path.relative(basePath, path.dirname(filePath));\n    const currentDepth = relativePath === '' ? 0 : relativePath.split(path.sep).length;\n\n    // Regex patterns for different link types\n    const patterns = [\n      // Standard markdown/mdx links: [text](file.md) or [text](../category/file.mdx)\n      // But skip URLs with schemes (http://, https://, etc.)\n      {\n        regex: /\\[([^\\]]*)\\]\\(([^)]+\\.mdx?(?:#[^)]*)?)\\)/g,\n        handler: (match, text, linkPath) => {\n          // Skip URLs with schemes\n          if (/^https?:\\/\\//.test(linkPath) || /^\\w+:\\/\\//.test(linkPath)) {\n            return match; // Return unchanged\n          }\n          return convertMarkdownLink(text, linkPath, currentDepth, relativePath);\n        }\n      },\n      // Hugo shortcode refs that weren't converted: {{< ref \"file.md\" >}}\n      {\n        regex: /\\{\\{<\\s*ref\\s+\"([^\"]+)\"\\s*>\\}\\}/g,\n        handler: (match, linkPath) => {\n          // Skip URLs with schemes\n          if (/^https?:\\/\\//.test(linkPath) || /^\\w+:\\/\\//.test(linkPath)) {\n            return match; // Return unchanged\n          }\n          return `[${path.basename(linkPath, '.md')}](${convertToAbsolutePath(linkPath, currentDepth, relativePath)})`;\n        }\n      },\n      // Doc links without .md extension: [text](/docs/path) -> should become [text](/path.md) or [text](/path/index.mdx]\n      // Handle anchors, trailing slashes, and categories properly\n      {\n        regex: /\\[([^\\]]*)\\]\\(\\/docs\\/([^)]+)\\)/g,\n        handler: (match, text, docPath) => {\n          // Skip URLs with schemes\n          if (/^https?:\\/\\//.test(docPath) || /^\\w+:\\/\\//.test(docPath)) {\n            return match; // Return unchanged\n          }\n\n          // Handle anchors: path#anchor -> path.md#anchor\n          let cleanPath = docPath;\n          let anchor = '';\n\n          if (cleanPath.includes('#')) {\n            const parts = cleanPath.split('#');\n            cleanPath = parts[0];\n            anchor = '#' + parts.slice(1).join('#');\n          }\n\n          // Remove trailing slash\n          cleanPath = cleanPath.replace(/\\/$/, '');\n\n          // Check if this is a category\n          if (isCategory(cleanPath)) {\n            return `[${text}](/${cleanPath}/index.mdx${anchor})`;\n          }\n\n          // Don't add .md if it already ends with .md or .mdx\n          if (cleanPath.endsWith('.md') || cleanPath.endsWith('.mdx')) {\n            return `[${text}](/${cleanPath}${anchor})`;\n          }\n\n          return `[${text}](/${cleanPath}.md${anchor})`;\n        }\n      },\n      // Blog links: [text](../blog/post) -> [text](/blog/post)\n      {\n        regex: /\\[([^\\]]*)\\]\\((\\.\\.\\/)*blog\\/([^)]+)\\)/g,\n        handler: (match, text, dots, blogPath) => `[${text}](/blog/${blogPath})`\n      },\n      // Links that don't end in .md but should: [text](../category/file) -> [text](/category/file.md)\n      // [text](file) -> [text](/current-category/file.md)\n      // But skip URLs with schemes and anchors only\n      {\n        regex: /\\[([^\\]]*)\\]\\(([^)]+)\\)/g,\n        handler: (match, text, linkPath) => {\n          // Skip URLs with schemes\n          if (/^https?:\\/\\//.test(linkPath) || /^\\w+:\\/\\//.test(linkPath)) {\n            return match; // Return unchanged\n          }\n\n          // Skip links that are just anchors (#something)\n          if (linkPath.startsWith('#')) {\n            return match; // Return unchanged\n          }\n\n          // Skip if already ends with .md or .mdx (already handled by first pattern)\n          if (linkPath.endsWith('.md') || linkPath.includes('.md#') ||\n              linkPath.endsWith('.mdx') || linkPath.includes('.mdx#')) {\n            return match; // Return unchanged\n          }\n\n          // Skip blog links (handled by previous pattern)\n          if (linkPath.includes('/blog/') || linkPath.match(/(\\.\\.\\/)*blog\\//)) {\n            return match; // Return unchanged\n          }\n\n          // Skip if starts with /docs/ (handled by previous pattern)\n          if (linkPath.startsWith('/docs/')) {\n            return match; // Return unchanged\n          }\n\n          // Handle anchors: path#anchor -> path.md#anchor or category#anchor -> /category/index.mdx#anchor\n          let cleanPath = linkPath;\n          let anchor = '';\n\n          if (cleanPath.includes('#')) {\n            const parts = cleanPath.split('#');\n            cleanPath = parts[0];\n            anchor = '#' + parts.slice(1).join('#');\n          }\n\n          // Remove trailing slash and ./\n          cleanPath = cleanPath.replace(/\\/$/, '').replace(/^\\.\\//, '');\n\n          // Check if this is a category (simple path without slashes)\n          if (!cleanPath.includes('/') && isCategory(cleanPath)) {\n            return `[${text}](${convertCategoryPath(linkPath, currentDepth, relativePath)})`;\n          }\n\n          // For relative category paths like ../category or ./category\n          const pathParts = cleanPath.split('/');\n          const lastSegment = pathParts[pathParts.length - 1];\n          if (isCategory(lastSegment)) {\n            return `[${text}](${convertCategoryPath(linkPath, currentDepth, relativePath)})`;\n          }\n\n          // Add .md extension for non-category files\n          cleanPath = cleanPath + '.md';\n\n          const absolutePath = convertToAbsolutePath(cleanPath, currentDepth, relativePath);\n          return `[${text}](${absolutePath}${anchor})`;\n        }\n      }\n    ];\n\n    // Apply each pattern\n    patterns.forEach(({ regex, handler }) => {\n      modifiedContent = modifiedContent.replace(regex, (...args) => {\n        const originalMatch = args[0];\n        const convertedLink = handler(...args);\n\n        if (convertedLink !== originalMatch) {\n          linksConverted++;\n        }\n\n        return convertedLink;\n      });\n    });\n\n    // Write file if modified\n    if (modifiedContent !== content) {\n      fs.writeFileSync(filePath, modifiedContent);\n      const relativePath = path.relative(basePath, filePath);\n      console.log(`    🔗 Updated links: ${relativePath} (${linksConverted} links)`);\n      return { modified: true, linksConverted };\n    }\n\n    return { modified: false, linksConverted: 0 };\n\n  } catch (error) {\n    console.warn(`  ⚠️  Error processing ${filePath}: ${error.message}`);\n    return { modified: false, linksConverted: 0 };\n  }\n}\n\n/**\n * Convert markdown link to absolute path\n * @param {string} text - Link text\n * @param {string} linkPath - Original link path\n * @param {number} currentDepth - Current file's depth in directory structure\n * @param {string} relativePath - Current file's relative path\n * @returns {string} - Converted markdown link\n */\nfunction convertMarkdownLink(text, linkPath, currentDepth, relativePath) {\n  // Handle anchors: file.md#anchor -> /path/file.md#anchor\n  let cleanPath = linkPath;\n  let anchor = '';\n\n  if (cleanPath.includes('#')) {\n    const parts = cleanPath.split('#');\n    cleanPath = parts[0];\n    anchor = '#' + parts.slice(1).join('#');\n  }\n\n  const absolutePath = convertToAbsolutePath(cleanPath, currentDepth, relativePath);\n  return `[${text}](${absolutePath}${anchor})`;\n}\n\n/**\n * Convert relative path to absolute Docusaurus path\n * @param {string} linkPath - Original link path (relative)\n * @param {number} currentDepth - Current file's depth in directory structure\n * @param {string} relativePath - Current file's relative path\n * @returns {string} - Absolute path for Docusaurus\n */\nfunction convertToAbsolutePath(linkPath, currentDepth, relativePath) {\n  // Handle different link patterns\n  if (linkPath.startsWith('/')) {\n    // Already absolute\n    return linkPath;\n  }\n\n  if (linkPath.startsWith('../')) {\n    // Parent directory references: ../category/file.md or ../file.md\n    const pathParts = linkPath.split('/');\n    const upLevels = pathParts.filter(part => part === '..').length;\n    const remainingPath = pathParts.slice(upLevels).join('/');\n\n    if (upLevels >= currentDepth) {\n      // Goes to root or beyond\n      return `/${remainingPath}`;\n    } else {\n      // Stays within subdirectories\n      const currentParts = relativePath.split(path.sep);\n      const targetParts = currentParts.slice(0, currentParts.length - upLevels);\n      return `/${targetParts.join('/')}${targetParts.length > 0 ? '/' : ''}${remainingPath}`;\n    }\n  } else {\n    // Same directory or subdirectory: file.md, ./file.md, or subdir/file.md\n    let cleanPath = linkPath;\n\n    // Normalize ./filename.md to filename.md\n    if (cleanPath.startsWith('./')) {\n      cleanPath = cleanPath.substring(2);\n    }\n\n    if (relativePath === '') {\n      // Root level\n      return `/${cleanPath}`;\n    } else {\n      // In subdirectory\n      return `/${relativePath}/${cleanPath}`;\n    }\n  }\n}\n\nmodule.exports = {\n  convertRelativeLinksToAbsolute\n};"
  },
  {
    "path": "scripts/util/util-file-operations.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\n\n/**\n * Recursively find all files matching extensions in a directory\n * @param {string} dir - Directory to search\n * @param {string[]} extensions - File extensions to match (e.g., ['.md', '.mdx'])\n * @returns {string[]} - Array of file paths\n */\nfunction findFiles(dir, extensions = ['.md', '.mdx']) {\n  const files = [];\n\n  function traverse(currentDir) {\n    const entries = fs.readdirSync(currentDir, { withFileTypes: true });\n\n    entries.forEach(entry => {\n      const fullPath = path.join(currentDir, entry.name);\n\n      if (entry.isDirectory()) {\n        traverse(fullPath);\n      } else if (entry.isFile()) {\n        const ext = path.extname(entry.name);\n        if (extensions.includes(ext)) {\n          files.push(fullPath);\n        }\n      }\n    });\n  }\n\n  if (fs.existsSync(dir)) {\n    traverse(dir);\n  }\n\n  return files;\n}\n\n/**\n * Move directory contents from source to destination\n * @param {string} sourceDir - Source directory\n * @param {string} destDir - Destination directory\n */\nfunction moveDirectoryContents(sourceDir, destDir) {\n  if (!fs.existsSync(sourceDir)) {\n    console.warn(`⚠️  Source directory not found: ${sourceDir}`);\n    return;\n  }\n\n  // Ensure destination directory exists\n  fs.mkdirSync(destDir, { recursive: true });\n\n  const entries = fs.readdirSync(sourceDir);\n  let movedCount = 0;\n\n  entries.forEach(entry => {\n    const sourcePath = path.join(sourceDir, entry);\n    const destPath = path.join(destDir, entry);\n\n    fs.renameSync(sourcePath, destPath);\n    movedCount++;\n  });\n\n  console.log(`📁 Moved ${movedCount} items from ${sourceDir} to ${destDir}`);\n}\n\n/**\n * Remove directory and all its contents\n * @param {string} dir - Directory to remove\n */\nfunction removeDirectory(dir) {\n  if (fs.existsSync(dir)) {\n    fs.rmSync(dir, { recursive: true, force: true });\n    console.log(`🗑️  Removed directory: ${dir}`);\n  }\n}\n\n/**\n * Create directory (and parent directories if needed)\n * @param {string} dir - Directory to create\n */\nfunction createDirectory(dir) {\n  fs.mkdirSync(dir, { recursive: true });\n  console.log(`📁 Created directory: ${dir}`);\n}\n\n/**\n * Copy file from source to destination\n * @param {string} sourceFile - Source file path\n * @param {string} destFile - Destination file path\n */\nfunction copyFile(sourceFile, destFile) {\n  // Ensure destination directory exists\n  const destDir = path.dirname(destFile);\n  fs.mkdirSync(destDir, { recursive: true });\n\n  fs.copyFileSync(sourceFile, destFile);\n  console.log(`📋 Copied: ${sourceFile} → ${destFile}`);\n}\n\n/**\n * Rename/move a file\n * @param {string} oldPath - Current file path\n * @param {string} newPath - New file path\n */\nfunction renameFile(oldPath, newPath) {\n  if (fs.existsSync(oldPath)) {\n    // Ensure destination directory exists\n    const destDir = path.dirname(newPath);\n    fs.mkdirSync(destDir, { recursive: true });\n\n    fs.renameSync(oldPath, newPath);\n    console.log(`🔄 Renamed: ${oldPath} → ${newPath}`);\n  } else {\n    console.warn(`⚠️  File not found for rename: ${oldPath}`);\n  }\n}\n\nmodule.exports = {\n  findFiles,\n  moveDirectoryContents,\n  removeDirectory,\n  createDirectory,\n  copyFile,\n  renameFile\n};\n"
  },
  {
    "path": "scripts/util/util-frontmatter.js",
    "content": "#!/usr/bin/env node\n\nconst yaml = require('js-yaml');\n\n/**\n * Parse frontmatter from content, returning both the YAML data and the rest of the content\n * @param {string} content - File content\n * @returns {Object} - { frontmatter: Object, restContent: string, hasFrontmatter: boolean }\n */\nfunction frontMatterFromYaml(content) {\n  const lines = content.split('\\n');\n\n  // Find frontmatter boundaries\n  let frontmatterStart = -1;\n  let frontmatterEnd = -1;\n  let dashCount = 0;\n\n  for (let i = 0; i < lines.length; i++) {\n    if (lines[i].trim() === '---') {\n      dashCount++;\n      if (dashCount === 1) {\n        frontmatterStart = i;\n      } else if (dashCount === 2) {\n        frontmatterEnd = i;\n        break;\n      }\n    }\n  }\n\n  if (frontmatterStart === -1 || frontmatterEnd === -1) {\n    // No frontmatter found\n    return {\n      frontmatter: {},\n      restContent: content,\n      hasFrontmatter: false\n    };\n  }\n\n  const frontmatterText = lines.slice(frontmatterStart + 1, frontmatterEnd).join('\\n');\n  const restContent = lines.slice(frontmatterEnd + 1).join('\\n');\n\n  try {\n    const frontmatter = yaml.load(frontmatterText) || {};\n    return {\n      frontmatter,\n      restContent,\n      hasFrontmatter: true\n    };\n  } catch (error) {\n    console.error('    ❌ Error parsing YAML frontmatter:', error.message);\n    return {\n      frontmatter: {},\n      restContent: content,\n      hasFrontmatter: false\n    };\n  }\n}\n\n/**\n * Convert YAML data back to frontmatter content\n * @param {Object} frontmatter - YAML data object\n * @param {string} restContent - The rest of the content after frontmatter\n * @returns {string} - Complete content with frontmatter\n */\nfunction frontMatterToYaml(frontmatter, restContent) {\n  if (!frontmatter || Object.keys(frontmatter).length === 0) {\n    // No frontmatter to add, return just the content\n    return restContent;\n  }\n\n  const frontmatterYaml = yaml.dump(frontmatter, {\n    indent: 2,\n    lineWidth: 120,\n    quotingType: '\"',\n    forceQuotes: false\n  }).trim();\n\n  return `---\\n${frontmatterYaml}\\n---\\n${restContent}`;\n}\n\nmodule.exports = {\n  frontMatterFromYaml,\n  frontMatterToYaml\n};\n"
  },
  {
    "path": "scripts/util/util-migration.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\nconst { execSync } = require('child_process');\nconst { findFiles, moveDirectoryContents, removeDirectory, createDirectory } = require('./util-file-operations.js');\nconst { frontMatterFromYaml, frontMatterToYaml } = require('./util-frontmatter.js');\n\n/**\n * Clean up version directory for fresh migration\n * @param {number} majorVersion - Version number (e.g., 2, 3)\n */\nfunction startFresh(majorVersion) {\n  console.log('🔄 Starting fresh migration...');\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n\n  // Remove version directory and recreate\n  removeDirectory(versionDir);\n  createDirectory(versionDir);\n\n  console.log('✅ Fresh migration setup completed');\n}\n\n/**\n * Restore source content for specified version to orig/ directory\n * @param {number} majorVersion - Version number (2 or 3)\n */\nfunction restoreSourceContent(majorVersion) {\n  console.log(`📥 Restoring v${majorVersion} source content...`);\n\n  // Clean and create orig directory structure\n  removeDirectory('orig');\n  execSync('mkdir -p orig', { stdio: 'inherit' });\n\n  if (majorVersion === 2) {\n    // Clone helm2 repository\n    console.log('📥 Cloning Helm v2 repository...');\n    try {\n      execSync('git clone --single-branch --branch release-2.17 https://github.com/helm/helm.git helm2', { stdio: 'inherit' });\n      execSync('mv helm2/docs orig/docs-v2', { stdio: 'inherit' });\n      removeDirectory('helm2');\n      console.log('✅ v2 source content restored to orig/docs-v2');\n    } catch (error) {\n      console.error('❌ Failed to clone Helm v2 repository:', error.message);\n      process.exit(1);\n    }\n  } else if (majorVersion === 3) {\n    // Restore content from git main\n    console.log('📥 Restoring v3 content from git main...');\n    execSync('git restore --source main -- content/en/docs', { stdio: 'inherit' });\n    execSync('mv content/en/docs orig/docs-v3', { stdio: 'inherit' });\n    removeDirectory('content/en');\n    console.log('✅ v3 source content restored to orig/docs-v3');\n  } else {\n    console.error(`❌ Unsupported major version: ${majorVersion}`);\n    process.exit(1);\n  }\n}\n\n/**\n * Setup Docusaurus versioned structure (idempotent)\n * Creates version in versions.json, versioned_docs, and versioned_sidebars\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction skaffoldMajorVersion(majorVersion = 3) {\n  console.log('📁 Setting up Docusaurus version structure...');\n\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n\n  if (!fs.existsSync(versionDir)) {\n    // Create Docusaurus version structure\n    execSync(`yarn docusaurus docs:version ${majorVersion}`, { stdio: 'inherit' });\n\n    // Empty the directory but keep the structure\n    const files = fs.readdirSync(versionDir);\n    files.forEach(file => {\n      const filePath = path.join(versionDir, file);\n      fs.rmSync(filePath, { recursive: true, force: true });\n    });\n\n    console.log('✅ Docusaurus version structure created');\n  } else {\n    console.log('⏭️  Docusaurus version structure already exists');\n  }\n}\n\n/**\n * Move content from Hugo structure to Docusaurus structure\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction moveDocs(majorVersion = 3) {\n  console.log('📦 Moving docs from Hugo to Docusaurus structure...');\n\n  const sourceDir = `orig/docs-v${majorVersion}`;\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n\n  if (fs.existsSync(sourceDir)) {\n    moveDirectoryContents(sourceDir, versionDir);\n    console.log('✅ Docs moved successfully');\n  } else {\n    console.warn('⚠️  Source docs directory not found');\n  }\n}\n\n/**\n * Delete files with 'section: deprecated' frontmatter\n * Hugo hid these files, Docusaurus doesn't have this feature\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction deleteDeprecatedFiles(majorVersion = 3) {\n  console.log('🗑️  Removing deprecated files...');\n\n  // Process main version docs\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  let deletedCount = 0;\n\n  if (fs.existsSync(versionDir)) {\n    console.log(`  📁 Processing main docs: ${versionDir}`);\n    const result = deleteDeprecatedFilesInDirectory(versionDir);\n    deletedCount += result.deletedCount;\n  }\n\n  // Process translation docs (only for v3 and above)\n  if (majorVersion >= 3) {\n    const i18nDir = 'i18n';\n    if (fs.existsSync(i18nDir)) {\n      const languages = fs.readdirSync(i18nDir, { withFileTypes: true })\n        .filter(dirent => dirent.isDirectory())\n        .map(dirent => dirent.name);\n\n      languages.forEach(lang => {\n        const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`;\n        if (fs.existsSync(translationVersionDir)) {\n          console.log(`  🌐 Processing ${lang} translations: ${translationVersionDir}`);\n          const result = deleteDeprecatedFilesInDirectory(translationVersionDir);\n          deletedCount += result.deletedCount;\n        }\n      });\n    }\n  }\n\n  console.log(`✅ Removed ${deletedCount} deprecated files`);\n}\n\n/**\n * Delete deprecated files in a specific directory\n * @param {string} dirPath - Directory path to process\n * @returns {Object} - Results with deletedCount\n */\nfunction deleteDeprecatedFilesInDirectory(dirPath) {\n  const files = findFiles(dirPath, ['.md', '.mdx']);\n  let deletedCount = 0;\n\n  files.forEach(filePath => {\n    try {\n      const content = fs.readFileSync(filePath, 'utf8');\n      const { frontmatter, hasFrontmatter } = frontMatterFromYaml(content);\n\n      if (hasFrontmatter && frontmatter.section === 'deprecated') {\n        fs.unlinkSync(filePath);\n        console.log(`    🗑️  Deleted: ${path.relative(dirPath, filePath)}`);\n        deletedCount++;\n      }\n    } catch (error) {\n      console.warn(`    ⚠️  Error checking ${filePath}: ${error.message}`);\n    }\n  });\n\n  return { deletedCount };\n}\n\n/**\n * Replace Hugo 'weight:' frontmatter with Docusaurus 'sidebar_position:'\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction replaceWeightWithSidebarPosition(majorVersion = 3) {\n  console.log('🔄 Converting weight → sidebar_position in frontmatter...');\n\n  // Process main version docs\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  let updatedCount = 0;\n\n  if (fs.existsSync(versionDir)) {\n    console.log(`  📁 Processing main docs: ${versionDir}`);\n    const result = replaceWeightInDirectory(versionDir);\n    updatedCount += result.updatedCount;\n  }\n\n  // Process translation docs (only for v3 and above)\n  if (majorVersion >= 3) {\n    const i18nDir = 'i18n';\n    if (fs.existsSync(i18nDir)) {\n      const languages = fs.readdirSync(i18nDir, { withFileTypes: true })\n        .filter(dirent => dirent.isDirectory())\n        .map(dirent => dirent.name);\n\n      languages.forEach(lang => {\n        const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`;\n        if (fs.existsSync(translationVersionDir)) {\n          console.log(`  🌐 Processing ${lang} translations: ${translationVersionDir}`);\n          const result = replaceWeightInDirectory(translationVersionDir);\n          updatedCount += result.updatedCount;\n        }\n      });\n    }\n  }\n\n  console.log(`✅ Updated ${updatedCount} files with sidebar_position`);\n}\n\n/**\n * Replace weight with sidebar_position in a specific directory\n * @param {string} dirPath - Directory path to process\n * @returns {Object} - Results with updatedCount\n */\nfunction replaceWeightInDirectory(dirPath) {\n  const files = findFiles(dirPath, ['.md', '.mdx']);\n  let updatedCount = 0;\n\n  files.forEach(filePath => {\n    try {\n      const content = fs.readFileSync(filePath, 'utf8');\n      const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content);\n\n      if (hasFrontmatter && frontmatter.hasOwnProperty('weight')) {\n        // Replace weight with sidebar_position\n        frontmatter.sidebar_position = frontmatter.weight;\n        delete frontmatter.weight;\n\n        const updatedContent = frontMatterToYaml(frontmatter, restContent);\n        fs.writeFileSync(filePath, updatedContent);\n\n        console.log(`    🔄 Updated: ${path.relative(dirPath, filePath)}`);\n        updatedCount++;\n      }\n    } catch (error) {\n      console.warn(`    ⚠️  Error processing ${filePath}: ${error.message}`);\n    }\n  });\n\n  return { updatedCount };\n}\n\n/**\n * Add metadata to main index file (_index.md → index.mdx)\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction addMainIndexMetadata(majorVersion = 3) {\n  console.log('📝 Adding metadata to main index file...');\n\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  const indexPath = path.join(versionDir, 'index.mdx');\n\n  if (fs.existsSync(indexPath)) {\n    const content = fs.readFileSync(indexPath, 'utf8');\n    const { frontmatter, restContent } = frontMatterFromYaml(content);\n\n    // Add required metadata (frontmatter only)\n    frontmatter.sidebar_position = 1;\n    if (!frontmatter.title) {\n      frontmatter.title = 'Documentation';\n    }\n\n    const updatedContent = frontMatterToYaml(frontmatter, restContent);\n    fs.writeFileSync(indexPath, updatedContent);\n\n    console.log('✅ Main index file metadata updated');\n  } else {\n    console.warn('⚠️  Main index file (index.mdx) not found');\n  }\n}\n\n/**\n * Add <DocCardList /> components to category index pages\n * Reproduces Hugo's automatic page listing functionality\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction addDocsIndexLists(majorVersion = 3) {\n  console.log('📋 Adding DocCardList components to index pages...');\n\n  // Process main version docs\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  let updatedCount = 0;\n\n  if (fs.existsSync(versionDir)) {\n    console.log(`  📁 Processing main docs: ${versionDir}`);\n    const result = addDocCardListInDirectory(versionDir);\n    updatedCount += result.updatedCount;\n  }\n\n  // Process translation docs (only for v3 and above)\n  if (majorVersion >= 3) {\n    const i18nDir = 'i18n';\n    if (fs.existsSync(i18nDir)) {\n      const languages = fs.readdirSync(i18nDir, { withFileTypes: true })\n        .filter(dirent => dirent.isDirectory())\n        .map(dirent => dirent.name);\n\n      languages.forEach(lang => {\n        const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`;\n        if (fs.existsSync(translationVersionDir)) {\n          console.log(`  🌐 Processing ${lang} translations: ${translationVersionDir}`);\n          const result = addDocCardListInDirectory(translationVersionDir);\n          updatedCount += result.updatedCount;\n        }\n      });\n    }\n  }\n\n  console.log(`✅ Added DocCardList to ${updatedCount} index pages`);\n}\n\n/**\n * Add DocCardList components in a specific directory\n * @param {string} dirPath - Directory path to process\n * @returns {Object} - Results with updatedCount\n */\nfunction addDocCardListInDirectory(dirPath) {\n  // Find all index.mdx files (category pages)\n  const indexFiles = [];\n  function findIndexFiles(dir) {\n    const entries = fs.readdirSync(dir, { withFileTypes: true });\n    entries.forEach(entry => {\n      if (entry.isDirectory()) {\n        const indexPath = path.join(dir, entry.name, 'index.mdx');\n        if (fs.existsSync(indexPath)) {\n          indexFiles.push(indexPath);\n        }\n        findIndexFiles(path.join(dir, entry.name));\n      }\n    });\n  }\n\n  findIndexFiles(dirPath);\n\n  // Also add the root index.mdx file if it exists\n  const rootIndexPath = path.join(dirPath, 'index.mdx');\n  if (fs.existsSync(rootIndexPath)) {\n    indexFiles.push(rootIndexPath);\n  }\n\n  let updatedCount = 0;\n\n  indexFiles.forEach(filePath => {\n    try {\n      const content = fs.readFileSync(filePath, 'utf8');\n\n      // Check if DocCardList is already present\n      if (!content.includes('DocCardList')) {\n        // Simply append import and component to the end\n        const updatedContent = content +\n          '\\n\\nimport DocCardList from \\'@theme/DocCardList\\';\\n\\n<DocCardList />\\n';\n\n        fs.writeFileSync(filePath, updatedContent);\n        console.log(`    📋 Added DocCardList: ${path.relative(dirPath, filePath)}`);\n        updatedCount++;\n      }\n    } catch (error) {\n      console.warn(`    ⚠️  Error processing ${filePath}: ${error.message}`);\n    }\n  });\n\n  return { updatedCount };\n}\n\n/**\n * Import SDK examples from .go files to .mdx files with code blocks\n * Also renames examples.md to examples.mdx and adds imports\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction importSDK(majorVersion = 3) {\n  console.log('💻 Importing SDK examples...');\n\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  const sdkDir = path.join(versionDir, 'sdk');\n  const examplesFile = path.join(sdkDir, 'examples.md');\n  const examplesFileNew = path.join(sdkDir, 'examples.mdx');\n  const sdkExamplesDir = 'sdkexamples';\n\n  if (!fs.existsSync(sdkExamplesDir)) {\n    console.warn('⚠️  SDK examples source directory not found');\n    return;\n  }\n\n  if (!fs.existsSync(sdkDir)) {\n    console.warn('⚠️  SDK docs directory not found');\n    return;\n  }\n\n  // Find all .go files in sdkexamples/\n  const goFiles = fs.readdirSync(sdkExamplesDir)\n    .filter(file => file.endsWith('.go'))\n    .filter(file => file !== 'main.go'); // Skip main.go\n\n  let importLines = [];\n  let processedCount = 0;\n\n  // Process each .go file\n  goFiles.forEach(goFile => {\n    try {\n      const name = path.basename(goFile, '.go');\n      const sourcePath = path.join(sdkExamplesDir, goFile);\n      const destPath = path.join(sdkDir, `_${name}.mdx`);\n\n      // Read the .go file content\n      const goContent = fs.readFileSync(sourcePath, 'utf8');\n\n      // Wrap in code block\n      const mdxContent = '```go\\n' + goContent + '\\n```\\n';\n\n      // Write to destination\n      fs.writeFileSync(destPath, mdxContent);\n\n      // Create import line with capitalized name\n      const capName = name.charAt(0).toUpperCase() + name.slice(1);\n      importLines.push(`import ${capName} from './_${name}.mdx'`);\n\n      console.log(`  💻 Processed: ${goFile} → _${name}.mdx`);\n      processedCount++;\n\n    } catch (error) {\n      console.warn(`  ⚠️  Error processing ${goFile}: ${error.message}`);\n    }\n  });\n\n  // Rename examples.md to examples.mdx and add imports\n  if (fs.existsSync(examplesFile)) {\n    try {\n      const content = fs.readFileSync(examplesFile, 'utf8');\n      const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content);\n\n      if (hasFrontmatter) {\n        // Add imports after frontmatter\n        const importsSection = importLines.join('\\n') + '\\n\\n';\n\n        // Remove any existing import lines from restContent\n        const cleanedContent = restContent.replace(/^import .* from '\\.\\/_.*.mdx';?\\n?/gm, '');\n\n        const newRestContent = importsSection + cleanedContent.trim();\n        const updatedContent = frontMatterToYaml(frontmatter, newRestContent);\n\n        fs.writeFileSync(examplesFileNew, updatedContent);\n        fs.unlinkSync(examplesFile); // Remove old file\n\n        console.log('  📝 Updated examples.mdx with imports');\n      }\n    } catch (error) {\n      console.warn(`  ⚠️  Error updating examples file: ${error.message}`);\n    }\n  }\n\n  console.log(`✅ Imported ${processedCount} SDK examples`);\n}\n\n/**\n * Rename Hugo _index.md files to Docusaurus index.mdx in preparation for DocCardList\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction renameIndexFilesToMdx(majorVersion = 3) {\n  console.log('🔄 Renaming Hugo _index.md → Docusaurus index.mdx files...');\n\n  // Process main version docs\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  let renamedCount = 0;\n\n  if (fs.existsSync(versionDir)) {\n    console.log(`  📁 Processing main docs: ${versionDir}`);\n    const result = renameIndexFilesInDirectory(versionDir);\n    renamedCount += result.renamedCount;\n  }\n\n  // Process translation docs (only for v3 and above)\n  if (majorVersion >= 3) {\n    const i18nDir = 'i18n';\n    if (fs.existsSync(i18nDir)) {\n      const languages = fs.readdirSync(i18nDir, { withFileTypes: true })\n        .filter(dirent => dirent.isDirectory())\n        .map(dirent => dirent.name);\n\n      languages.forEach(lang => {\n        const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`;\n        if (fs.existsSync(translationVersionDir)) {\n          console.log(`  🌐 Processing ${lang} translations: ${translationVersionDir}`);\n          const result = renameIndexFilesInDirectory(translationVersionDir);\n          renamedCount += result.renamedCount;\n        }\n      });\n    }\n  }\n\n  console.log(`✅ Renamed ${renamedCount} Hugo index files to Docusaurus .mdx`);\n}\n\n/**\n * Rename index files in a specific directory\n * @param {string} dirPath - Directory path to process\n * @returns {Object} - Results with renamedCount\n */\nfunction renameIndexFilesInDirectory(dirPath) {\n  // Find all _index.md and index.md files that should become index.mdx\n  const indexFiles = [];\n  function findIndexFiles(dir) {\n    const entries = fs.readdirSync(dir, { withFileTypes: true });\n    entries.forEach(entry => {\n      if (entry.isDirectory()) {\n        findIndexFiles(path.join(dir, entry.name));\n      } else if (entry.name === '_index.md' || entry.name === 'index.md') {\n        indexFiles.push(path.join(dir, entry.name));\n      }\n    });\n  }\n\n  findIndexFiles(dirPath);\n\n  let renamedCount = 0;\n  indexFiles.forEach(filePath => {\n    const newPath = filePath.replace(/(_index\\.md|index\\.md)$/, 'index.mdx');\n    fs.renameSync(filePath, newPath);\n    const originalName = path.basename(filePath);\n    console.log(`    🔄 Renamed: ${path.relative(dirPath, filePath)} → index.mdx`);\n    renamedCount++;\n  });\n\n  return { renamedCount };\n}\n\n/**\n * Rename commands directories to helm in i18n translations\n * This fixes structural inconsistencies in i18n directories where some languages\n * have a top-level \"commands\" directory instead of \"helm\"\n * @param {number} majorVersion - Major version number (e.g., 3)\n */\nfunction renameCommandsToHelm(majorVersion) {\n  console.log('🔧 Renaming commands directories to helm in i18n directories...');\n\n  const i18nDir = 'i18n';\n  if (!fs.existsSync(i18nDir)) {\n    console.log('  ⏭️  No i18n directory found, skipping');\n    return;\n  }\n\n  const languages = fs.readdirSync(i18nDir, { withFileTypes: true })\n    .filter(dirent => dirent.isDirectory())\n    .map(dirent => dirent.name);\n\n  let renamedCount = 0;\n\n  languages.forEach(lang => {\n    const commandsDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}/commands`;\n    const helmDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}/helm`;\n\n    if (fs.existsSync(commandsDir)) {\n      console.log(`  🔄 Renaming ${lang}: commands → helm`);\n\n      if (fs.existsSync(helmDir)) {\n        console.log(`  ⚠️  Warning: ${lang} has both commands and helm directories, merging...`);\n\n        // Move all files from commands to helm\n        const files = fs.readdirSync(commandsDir);\n        files.forEach(file => {\n          const oldPath = path.join(commandsDir, file);\n          const newPath = path.join(helmDir, file);\n          if (!fs.existsSync(newPath)) {\n            fs.renameSync(oldPath, newPath);\n          } else {\n            console.log(`    ⚠️  Skipping ${file} (already exists in helm directory)`);\n          }\n        });\n      } else {\n        // Simply rename commands to helm\n        fs.renameSync(commandsDir, helmDir);\n      }\n\n      // Remove empty commands directory if it still exists\n      if (fs.existsSync(commandsDir)) {\n        try {\n          fs.rmdirSync(commandsDir);\n        } catch (error) {\n          // Directory might not be empty, that's okay\n        }\n      }\n\n      renamedCount++;\n    }\n  });\n\n  if (renamedCount > 0) {\n    console.log(`✅ Renamed commands to helm in ${renamedCount} language(s)`);\n  } else {\n    console.log('  ✅ No commands directories found to rename');\n  }\n}\n\nmodule.exports = {\n  startFresh,\n  restoreSourceContent,\n  skaffoldMajorVersion,\n  moveDocs,\n  deleteDeprecatedFiles,\n  replaceWeightWithSidebarPosition,\n  addMainIndexMetadata,\n  addDocsIndexLists,\n  renameIndexFilesToMdx,\n  renameCommandsToHelm\n};\n"
  },
  {
    "path": "scripts/util/util-text-replacements.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\nconst { findFiles } = require('./util-file-operations.js');\n\n/**\n * Category A: Replace Hugo shortcodes with their content\n * Reliably converts: {{< ref \"path\" >}} → path\n * Also converts: {{< highlightexamplego file=\"path\" >}} → path\n * Handles multi-line shortcodes and escape characters\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction replaceHugoShortcodes(majorVersion = 3) {\n  console.log('🔗 Converting Hugo shortcodes...');\n\n  // Process main version docs\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  let updatedCount = 0;\n  let totalReplacements = 0;\n\n  if (fs.existsSync(versionDir)) {\n    console.log(`  📁 Processing main docs: ${versionDir}`);\n    const result = processHugoShortcodesInDirectory(versionDir);\n    updatedCount += result.updatedCount;\n    totalReplacements += result.totalReplacements;\n  }\n\n  // Process translation docs (only for v3 and above)\n  if (majorVersion >= 3) {\n    const i18nDir = 'i18n';\n    if (fs.existsSync(i18nDir)) {\n      const languages = fs.readdirSync(i18nDir, { withFileTypes: true })\n        .filter(dirent => dirent.isDirectory())\n        .map(dirent => dirent.name);\n\n      languages.forEach(lang => {\n        const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`;\n        if (fs.existsSync(translationVersionDir)) {\n          console.log(`  🌐 Processing ${lang} translations: ${translationVersionDir}`);\n          const result = processHugoShortcodesInDirectory(translationVersionDir);\n          updatedCount += result.updatedCount;\n          totalReplacements += result.totalReplacements;\n        }\n      });\n    }\n  }\n\n  console.log(`✅ Converted ${totalReplacements} Hugo shortcodes in ${updatedCount} files`);\n}\n\n/**\n * Process Hugo shortcodes in a specific directory\n * @param {string} dirPath - Directory to process\n * @returns {Object} - Results with updatedCount and totalReplacements\n */\nfunction processHugoShortcodesInDirectory(dirPath) {\n  const files = findFiles(dirPath, ['.md', '.mdx']);\n  let updatedCount = 0;\n  let totalReplacements = 0;\n\n  files.forEach(filePath => {\n    try {\n      let content = fs.readFileSync(filePath, 'utf8');\n      let hasChanges = false;\n      const originalContent = content;\n\n      // Find multiline Hugo shortcodes: {{< ref\\n\"path\" >}} and regular ones\n      let searchIndex = 0;\n      while (true) {\n        const startIndex = content.indexOf('{{<', searchIndex);\n        if (startIndex === -1) break;\n\n        // Find the matching closing >}}\n        const endIndex = content.indexOf('>}}', startIndex);\n        if (endIndex === -1) {\n          console.warn(`  ⚠️  Unclosed Hugo shortcode at position ${startIndex}`);\n          searchIndex = startIndex + 3;\n          continue;\n        }\n\n        // Extract the full shortcode\n        const shortcode = content.substring(startIndex, endIndex + 3);\n        let replacement = null;\n\n        // Handle ref shortcodes: {{< ref \"path\" >}} or {{< relref path=\"path\" lang=\"en\">}} → path\n        if (shortcode.includes('ref')) {\n          // Handle both ref and relref shortcodes\n          let pathMatch;\n\n          // Try relref pattern first: {{< relref path=\"/docs/path.md\" lang=\"en\">}}\n          if (shortcode.includes('relref') && shortcode.includes('path=')) {\n            pathMatch = shortcode.match(/path=\"([^\"]+)\"/);\n          } else {\n            // Standard ref pattern: {{< ref \"path\" >}}\n            pathMatch = shortcode.match(/\"([^\"]+)\"/);\n          }\n\n          if (pathMatch) {\n            replacement = pathMatch[1].replace(/[\\\\()]/g, ''); // Strip escape characters\n          }\n        }\n        // Handle highlightexamplego shortcodes: {{< highlightexamplego file=\"path\" >}} → path\n        else if (shortcode.includes('highlightexamplego')) {\n          const fileMatch = shortcode.match(/file=\"([^\"]+)\"/);\n          if (fileMatch) {\n            replacement = fileMatch[1].replace(/[\\\\()]/g, ''); // Strip escape characters\n          }\n        }\n\n        if (replacement !== null) {\n          // Replace the entire shortcode with the extracted path\n          content = content.substring(0, startIndex) + replacement + content.substring(endIndex + 3);\n          hasChanges = true;\n          totalReplacements++;\n\n          console.log(`    🔗 ${shortcode.replace(/\\n/g, '\\\\n').substring(0, 50)}... → ${replacement}`);\n\n          // Adjust search index since content length changed\n          searchIndex = startIndex + replacement.length;\n        } else {\n          // No replacement made, continue searching\n          searchIndex = endIndex + 3;\n        }\n      }\n\n      if (hasChanges) {\n        fs.writeFileSync(filePath, content);\n        console.log(`    🔗 Updated: ${path.relative(dirPath, filePath)}`);\n        updatedCount++;\n      }\n\n    } catch (error) {\n      console.warn(`    ⚠️  Error processing ${filePath}: ${error.message}`);\n    }\n  });\n\n  return { updatedCount, totalReplacements };\n}\n\n\n/**\n * Category C: Fix markdown link hrefs based on href differences\n * Uses the shared href processor to apply link fixes\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction fixMarkdownLinkHrefs(majorVersion = 3) {\n  const path = require('path');\n  const { processHrefDifferences } = require('./href-diffs-process.js');\n  const differencesFile = path.join(__dirname, `../v${majorVersion}/href-diffs.json`);\n  processHrefDifferences(majorVersion, differencesFile);\n}\n\n/**\n * Master function to handle all text replacements\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction applyAllTextReplacements(majorVersion = 3) {\n  console.log('📖 Applying all text replacements...');\n\n  // Step 1: Fix markdown link hrefs BEFORE Hugo shortcode conversion\n  // This allows href-diffs to catch /docs/ paths inside shortcodes\n  fixMarkdownLinkHrefs(majorVersion);\n\n  // Step 2: Convert Hugo shortcodes to standard content\n  replaceHugoShortcodes(majorVersion);\n\n  console.log('✅ All text replacements completed');\n}\n\nmodule.exports = {\n  replaceHugoShortcodes,\n  fixMarkdownLinkHrefs,\n  applyAllTextReplacements\n};\n"
  },
  {
    "path": "scripts/v2/copy-files.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\n\n/**\n * Copy script that uses menu.json with header extraction to find and copy files\n * Matches headers to local markdown files and creates proper Docusaurus structure\n */\n\nfunction copyV2DocsToDocusaurus() {\n  console.log('📋 Starting v2 docs copy to Docusaurus...');\n\n  // Read the menu.json structure\n  const structureFile = path.join(__dirname, 'menu.json');\n  if (!fs.existsSync(structureFile)) {\n    console.error('❌ menu.json not found. Run menu-generate.js first.');\n    process.exit(1);\n  }\n\n  const menuData = JSON.parse(fs.readFileSync(structureFile, 'utf8'));\n  const navigationStructure = menuData.navigationStructure;\n  const helm2DocsPath = path.join(__dirname, '..', '..', 'orig', 'docs-v2');\n  const outputPath = path.join(__dirname, '..', '..', 'versioned_docs', 'version-2');\n\n  if (!fs.existsSync(helm2DocsPath)) {\n    console.error('❌ orig/docs-v2 directory not found');\n    process.exit(1);\n  }\n\n  // Clean and create output directory\n  if (fs.existsSync(outputPath)) {\n    fs.rmSync(outputPath, { recursive: true, force: true });\n    console.log('🗑️ Cleaned existing version-2 directory');\n  }\n  fs.mkdirSync(outputPath, { recursive: true });\n\n  // Create index.mdx file\n  createIndexFile(outputPath);\n  console.log('📄 Created index.mdx file');\n\n  // Build file header mapping from orig/docs-v2\n  console.log('🔍 Building header-to-file mapping from local markdown files...');\n  const headerToFileMap = buildHeaderFileMap(helm2DocsPath);\n  console.log(`📊 Found ${Object.keys(headerToFileMap).size} headers in ${headerToFileMap._totalFiles} files`);\n\n  let topLevelPosition = 2; // Start at 2 since index.mdx takes position 1\n  let copiedFiles = 0;\n\n  navigationStructure.forEach(item => {\n    if (item.children && item.children.length > 0) {\n      // This is a category with children\n      const categoryName = extractCategoryFromUrlPath(item.link);\n      if (categoryName) {\n        copiedFiles += processCategoryWithChildren(item, categoryName, outputPath, helm2DocsPath, headerToFileMap, topLevelPosition);\n        topLevelPosition++;\n      }\n    } else {\n      // This is a top-level file without children\n      copiedFiles += processTopLevelFile(item, outputPath, helm2DocsPath, headerToFileMap, topLevelPosition);\n      topLevelPosition++;\n    }\n  });\n\n  console.log(`✅ Successfully copied ${copiedFiles} files to ${outputPath}`);\n  console.log('🚀 Ready for Docusaurus!');\n}\n\n/**\n * Build a mapping of headers to file paths by scanning all markdown files\n */\nfunction buildHeaderFileMap(docsPath) {\n  const headerMap = {};\n  let totalFiles = 0;\n\n  function scanDirectory(dir, relativePath = '') {\n    const items = fs.readdirSync(dir);\n\n    items.forEach(item => {\n      const fullPath = path.join(dir, item);\n      const stat = fs.statSync(fullPath);\n\n      if (stat.isDirectory()) {\n        scanDirectory(fullPath, path.join(relativePath, item));\n      } else if (item.endsWith('.md')) {\n        totalFiles++;\n        const relativeFilePath = path.join(relativePath, item);\n\n        try {\n          const content = fs.readFileSync(fullPath, 'utf8');\n          const header = extractHeaderFromContent(content);\n\n          if (!header) {\n            console.error(`❌ No H1 or H2 header found in ${relativeFilePath} - script halted`);\n            process.exit(1);\n          }\n\n          if (headerMap[header]) {\n            console.warn(`⚠️ Duplicate header found: \"${header}\" in both ${headerMap[header]} and ${relativeFilePath}`);\n          } else {\n            headerMap[header] = relativeFilePath;\n          }\n        } catch (error) {\n          console.warn(`⚠️ Error reading ${relativeFilePath}: ${error.message}`);\n        }\n      }\n    });\n  }\n\n  scanDirectory(docsPath);\n  headerMap._totalFiles = totalFiles;\n  return headerMap;\n}\n\n/**\n * Extract the primary header from markdown content: first H1, or first H2 if no H1 exists\n */\nfunction extractHeaderFromContent(content) {\n  const lines = content.split('\\n');\n\n  // First pass: look for H1\n  for (const line of lines) {\n    const h1Match = line.match(/^#\\s+(.+)$/);\n    if (h1Match) {\n      return h1Match[1].trim();\n    }\n  }\n\n  // Second pass: look for H2 if no H1 found\n  for (const line of lines) {\n    const h2Match = line.match(/^##\\s+(.+)$/);\n    if (h2Match) {\n      return h2Match[1].trim();\n    }\n  }\n\n  // No H1 or H2 found\n  return null;\n}\n\n/**\n * Extract category name from URL path like /docs/using_helm/ → using_helm\n */\nfunction extractCategoryFromUrlPath(urlPath) {\n  if (!urlPath) return null;\n  const match = urlPath.match(/\\/docs\\/([^\\/]+)\\//);\n  return match ? match[1] : null;\n}\n\n/**\n * Process a category (parent with children)\n */\nfunction processCategoryWithChildren(categoryItem, categoryName, outputPath, helm2DocsPath, headerToFileMap, categoryPosition) {\n  console.log(`📁 Processing category: ${categoryItem.label} (${categoryName})`);\n\n  const categoryDir = path.join(outputPath, categoryName);\n  fs.mkdirSync(categoryDir, { recursive: true });\n\n  let copiedCount = 0;\n  let childPosition = 1;\n\n  // First child becomes the index file for the category\n  const indexChild = categoryItem.children[0];\n\n  categoryItem.children.forEach((child, index) => {\n    const isIndex = index === 0;\n    const headerToMatch = child.header || child.label;\n\n    // Find the source file using header matching\n    const sourceFile = findSourceFileByHeader(headerToMatch, headerToFileMap);\n    if (!sourceFile) {\n      console.log(`  ⚠️ No source file found for header: \"${headerToMatch}\"`);\n      return;\n    }\n\n    const sourcePath = path.join(helm2DocsPath, sourceFile);\n    if (!fs.existsSync(sourcePath)) {\n      console.log(`  ⚠️ Source file not found: ${sourceFile}`);\n      return;\n    }\n\n    let targetFileName;\n    let sidebarPosition;\n\n    if (isIndex) {\n      // This is the index file - rename it to category/category.md\n      targetFileName = `${categoryName}.md`;\n      sidebarPosition = categoryPosition; // Use parent's position\n      console.log(`  📄 Index: ${child.label} → ${categoryName}/${targetFileName} (${sourceFile})`);\n    } else {\n      // Regular child file\n      const baseFileName = path.basename(sourceFile, '.md');\n      targetFileName = `${baseFileName}.md`;\n      sidebarPosition = childPosition++;\n      console.log(`  📄 Child: ${child.label} → ${categoryName}/${targetFileName} (${sourceFile})`);\n    }\n\n    const targetPath = path.join(categoryDir, targetFileName);\n\n    if (copyFileWithFrontmatter(sourcePath, targetPath, {\n      position: sidebarPosition,\n      label: isIndex ? categoryItem.label : child.label, // Use parent label for index\n      slug: isIndex ? undefined : undefined // Index files should have no slug\n    }, isIndex)) {\n      copiedCount++;\n    }\n  });\n\n  return copiedCount;\n}\n\n/**\n * Process a top-level file (no children)\n */\nfunction processTopLevelFile(item, outputPath, helm2DocsPath, headerToFileMap, position) {\n  console.log(`📄 Processing top-level: ${item.label}`);\n\n  // Special handling for \"Docs Home\" - already created\n  if (item.label === \"Docs Home\") {\n    console.log(`  ✅ Docs Home already created as index.mdx`);\n    return 0;\n  }\n\n  const headerToMatch = item.header || item.label;\n  const sourceFile = findSourceFileByHeader(headerToMatch, headerToFileMap);\n\n  if (!sourceFile) {\n    console.log(`  ⚠️ No source file found for header: \"${headerToMatch}\"`);\n    return 0;\n  }\n\n  const sourcePath = path.join(helm2DocsPath, sourceFile);\n  if (!fs.existsSync(sourcePath)) {\n    console.log(`  ⚠️ Source file not found: ${sourceFile}`);\n    return 0;\n  }\n\n  const targetFileName = path.basename(sourceFile);\n  const targetPath = path.join(outputPath, targetFileName);\n\n  console.log(`  📄 ${item.label} → ${targetFileName} (${sourceFile})`);\n\n  if (copyFileWithFrontmatter(sourcePath, targetPath, {\n    position: position,\n    label: item.label\n  }, false)) {\n    return 1;\n  }\n\n  return 0;\n}\n\n/**\n * Normalize smart quotes to regular quotes\n */\nfunction normalizeQuotes(text) {\n  return text\n    .replace(/[\"\"]/g, '\"')  // Smart double quotes (U+201C, U+201D) → regular double quotes\n    .replace(/['']/g, \"'\") // Smart single quotes (U+2018, U+2019) → regular single quotes\n    .replace(/\\u2019/g, \"'\") // Right single quotation mark (U+2019) → regular single quote\n    .replace(/\\u2018/g, \"'\") // Left single quotation mark (U+2018) → regular single quote\n    .replace(/\\u201C/g, '\"') // Left double quotation mark (U+201C) → regular double quote\n    .replace(/\\u201D/g, '\"'); // Right double quotation mark (U+201D) → regular double quote\n}\n\n/**\n * Find source file by matching header text\n */\nfunction findSourceFileByHeader(headerText, headerToFileMap) {\n  // Normalize smart quotes in the search text\n  const normalizedHeaderText = normalizeQuotes(headerText);\n\n  // Direct match first (try both original and normalized)\n  if (headerToFileMap[headerText]) {\n    return headerToFileMap[headerText];\n  }\n  if (headerToFileMap[normalizedHeaderText]) {\n    return headerToFileMap[normalizedHeaderText];\n  }\n\n  // Try case-insensitive match (with both original and normalized)\n  const lowerHeaderText = headerText.toLowerCase();\n  const lowerNormalizedHeaderText = normalizedHeaderText.toLowerCase();\n\n  for (const [header, file] of Object.entries(headerToFileMap)) {\n    if (header !== '_totalFiles') {\n      const lowerHeader = header.toLowerCase();\n      if (lowerHeader === lowerHeaderText || lowerHeader === lowerNormalizedHeaderText) {\n        return file;\n      }\n    }\n  }\n\n  // Try partial match for helm commands (remove \"helm\" prefix)\n  if (headerText.startsWith('helm ')) {\n    const commandOnly = headerText.substring(5); // Remove \"helm \"\n    for (const [header, file] of Object.entries(headerToFileMap)) {\n      if (header !== '_totalFiles' && header.toLowerCase().includes(commandOnly.toLowerCase())) {\n        return file;\n      }\n    }\n  }\n\n  return null;\n}\n\n/**\n * Copy file with proper Docusaurus frontmatter\n */\nfunction copyFileWithFrontmatter(sourcePath, targetPath, frontmatterData, isIndex = false) {\n  try {\n    let content = fs.readFileSync(sourcePath, 'utf8');\n\n    // Remove UTF-8 BOM if present\n    if (content.charCodeAt(0) === 0xFEFF || content.startsWith('\\\\uFEFF')) {\n      content = content.slice(1);\n    }\n    if (content.startsWith('\\\\xEF\\\\xBB\\\\xBF')) {\n      content = content.slice(3);\n    }\n\n    // Replace image paths from (images/ to (/img/helm2/\n    content = content.replace(/\\(images\\//g, '(/img/helm2/');\n\n    // Special processing for helm/*.md files - extract H2 title and remove heading\n    let h2Title = null;\n    if (sourcePath.includes('/helm/helm') && sourcePath.endsWith('.md')) {\n      h2Title = extractFirstH2Heading(content);\n      content = removeFirstH2Heading(content);\n    }\n\n    // Create frontmatter (include H2 title for helm commands)\n    const frontmatter = createFrontmatter({\n      ...frontmatterData,\n      title: h2Title // Add H2 title if extracted\n    }, isIndex);\n    const fullContent = frontmatter + content;\n\n    fs.writeFileSync(targetPath, fullContent);\n\n    const indexNote = isIndex ? ' [INDEX]' : '';\n    console.log(`    ✅ Copied (pos: ${frontmatterData.position})${indexNote}`);\n    return true;\n\n  } catch (error) {\n    console.log(`    ❌ Error copying: ${error.message}`);\n    return false;\n  }\n}\n\n/**\n * Create the index.mdx file for the version-2 docs\n */\nfunction createIndexFile(outputPath) {\n  const indexContent = `---\ntitle: \"Docs Home\"\nsidebar_position: 1\n---\n\nComplete documentation for Helm v2, the Kubernetes package manager. Learn how to install, configure, and use Helm to deploy applications to your Kubernetes cluster.\n\nimport DocCardList from \"@theme/DocCardList\";\n\n<DocCardList />\n\n`;\n\n  const indexPath = path.join(outputPath, 'index.mdx');\n  fs.writeFileSync(indexPath, indexContent);\n}\n\n/**\n * Extract the first H2 heading text from content\n */\nfunction extractFirstH2Heading(content) {\n  const lines = content.split('\\n');\n\n  for (let i = 0; i < lines.length; i++) {\n    if (lines[i].startsWith('## helm')) {\n      // Extract just the text after \"## \"\n      return lines[i].substring(3).trim();\n    }\n  }\n\n  return null;\n}\n\n/**\n * Remove the first H2 heading from helm command files\n */\nfunction removeFirstH2Heading(content) {\n  // Look for the first H2 heading (## helm...) and remove it along with any following empty lines\n  const lines = content.split('\\n');\n  let firstH2Index = -1;\n\n  for (let i = 0; i < lines.length; i++) {\n    if (lines[i].startsWith('## helm')) {\n      firstH2Index = i;\n      break;\n    }\n  }\n\n  if (firstH2Index !== -1) {\n    // Remove the H2 line\n    lines.splice(firstH2Index, 1);\n\n    // Remove any immediately following empty lines\n    while (firstH2Index < lines.length && lines[firstH2Index].trim() === '') {\n      lines.splice(firstH2Index, 1);\n    }\n  }\n\n  return lines.join('\\n');\n}\n\n/**\n * Create Docusaurus frontmatter\n */\nfunction createFrontmatter(data, isIndex = false) {\n  const frontmatterLines = ['---'];\n\n  // Add title if specified (for helm commands)\n  if (data.title) {\n    frontmatterLines.push(`title: \"${data.title}\"`);\n  }\n\n  // Add position\n  frontmatterLines.push(`sidebar_position: ${data.position}`);\n\n  // Add label\n  frontmatterLines.push(`sidebar_label: \"${data.label}\"`);\n\n  // Add slug if specified\n  if (data.slug) {\n    frontmatterLines.push(`slug: ${data.slug}`);\n  }\n\n  // Add index-specific metadata\n  if (isIndex) {\n    frontmatterLines.push('# This is the index/landing page for this section');\n  }\n\n  frontmatterLines.push('---');\n  frontmatterLines.push('');\n\n  return frontmatterLines.join('\\n');\n}\n\n// Main execution\nif (require.main === module) {\n  copyV2DocsToDocusaurus();\n}\n\nmodule.exports = { copyV2DocsToDocusaurus };\n"
  },
  {
    "path": "scripts/v2/href-diffs.json",
    "content": "[\n  {\n    \"fileName\": \"chart_template_guide/getting_started.md\",\n    \"before\": \"../charts.md\",\n    \"after\": \"../developing_charts/developing_charts.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/subcharts_and_globals.md\",\n    \"before\": \"../charts.md\",\n    \"after\": \"../developing_charts/developing_charts.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/wrapping_up.md\",\n    \"before\": \"../charts.md\",\n    \"after\": \"../developing_charts/developing_charts.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/wrapping_up.md\",\n    \"before\": \"../charts_hooks.md\",\n    \"after\": \"../developing_charts/charts_hooks.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/wrapping_up.md\",\n    \"before\": \"../charts_tips_and_tricks.md\",\n    \"after\": \"../developing_charts/charts_tips_and_tricks.md\"\n  },\n  {\n    \"fileName\": \"developing_charts/chart_repository.md\",\n    \"before\": \"quickstart.md\",\n    \"after\": \"../using_helm/using_helm.md\"\n  },\n  {\n    \"fileName\": \"developing_charts/chart_repository.md\",\n    \"before\": \"charts.md\",\n    \"after\": \"developing_charts.md\"\n  },\n  {\n    \"fileName\": \"using_helm/securing_installation.md\",\n    \"before\": \"provenance.md\",\n    \"after\": \"../developing_charts/provenance.md\"\n  },\n  {\n    \"fileName\": \"using_helm/kubernetes_apis.md\",\n    \"before\": \"developers#grpc-and-protobuf\",\n    \"after\": \"../developers.md#grpc-and-protobuf\"\n  },\n  {\n    \"fileName\": \"using_helm/install.md\",\n    \"before\": \"#kubernetes-distribution-guide\",\n    \"after\": \"kubernetes_distros.md\"\n  },\n  {\n    \"fileName\": \"using_helm/using_helm.md\",\n    \"before\": \"#Install-Helm\",\n    \"after\": \"install.md\"\n  }\n]\n"
  },
  {
    "path": "scripts/v2/menu-generate.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst https = require('https');\nconst { JSDOM } = require('jsdom');\n\nconst V2_DOCS_URL = 'https://v2.helm.sh/docs/';\n\n// DOM extraction function from user\nconst linksTree = (rootSel = 'nav.sidebar-nav ul.current.sidebar-main', document) => {\n  const ul = typeof rootSel === 'string' ? document.querySelector(rootSel) : rootSel;\n  if (!ul || ul.tagName !== 'UL') throw new Error('Target UL .current.sidebar-main not found under nav.sidebar-nav');\n\n  const parse = u => Array.from(u.children).flatMap(li => li.tagName === 'LI' ? [{\n    link: li.querySelector(':scope > a')?.href ?? null,\n    label: li.querySelector(':scope > a')?.textContent.trim() ?? null,\n    children: (() => { const cu = li.querySelector(':scope > ul'); return cu ? parse(cu) : []; })()\n  }] : []);\n\n  return parse(ul);\n};\n\n// Convert v2.helm.sh navigation structure to simplified format for copy script\nconst convertToSimplifiedFormat = async (navTree) => {\n  const results = [];\n\n  for (const item of navTree) {\n    // Skip external links (not on v2.helm.sh/docs domain)\n    if (item.link && !item.link.startsWith('/docs')) {\n      console.log(`🚫 Skipping external link: ${item.label} (${item.link})`);\n      continue;\n    }\n\n    const result = {\n      label: item.label,\n      link: item.link // Store full URL path for categories\n    };\n\n    // Extract header text for the main page (except for \"Docs Home\")\n    if (item.link && item.label !== \"Docs Home\") {\n      try {\n        const headerText = await extractHeaderText(`https://v2.helm.sh${item.link}`);\n        if (headerText) {\n          result.header = headerText;\n        }\n      } catch (error) {\n        console.warn(`Failed to extract header for ${item.link}: ${error.message}`);\n      }\n    } else if (item.label === \"Docs Home\") {\n      console.log(`📄 Skipping header extraction for Docs Home (handled by copy script)`);\n    }\n\n    // Only add children key if there are actual children\n    if (item.children.length > 0) {\n      result.children = [];\n\n      for (const child of item.children) {\n        const childResult = {\n          label: child.label,\n          anchor: extractAnchor(child.link) // Store just the anchor fragment\n        };\n\n        // Extract header text for child anchor\n        if (child.link && item.link) {\n          try {\n            const fullChildUrl = `https://v2.helm.sh${item.link}${child.link.startsWith('#') ? child.link : '#' + extractAnchor(child.link)}`;\n            const childHeaderText = await extractHeaderTextFromAnchor(`https://v2.helm.sh${item.link}`, extractAnchor(child.link));\n            if (childHeaderText) {\n              childResult.header = childHeaderText;\n            }\n          } catch (error) {\n            console.warn(`Failed to extract header for ${child.link}: ${error.message}`);\n          }\n        }\n\n        result.children.push(childResult);\n      }\n    }\n\n    results.push(result);\n  }\n\n  return results;\n};\n\n// Extract anchor fragment from relative URL\nconst extractAnchor = (link) => {\n  if (!link) return null;\n  const anchorIndex = link.indexOf('#');\n  return anchorIndex !== -1 ? link.substring(anchorIndex + 1) : null;\n};\n\n// Extract header text from a page following the pattern: div.content-wrap + empty h3 + next H1/H2\nconst extractHeaderText = (url) => {\n  return new Promise((resolve, reject) => {\n    console.log(`  🔍 Extracting header from: ${url}`);\n\n    https.get(url, (response) => {\n      let data = '';\n\n      response.on('data', (chunk) => {\n        data += chunk;\n      });\n\n      response.on('end', () => {\n        try {\n          const dom = new JSDOM(data);\n          const document = dom.window.document;\n\n          // Find div.content-wrap\n          const contentWrap = document.querySelector('div.content-wrap');\n          if (!contentWrap) {\n            console.log(`    ❌ No div.content-wrap found`);\n            resolve(null);\n            return;\n          }\n\n          // Look for empty h3 inside content-wrap\n          const emptyH3 = contentWrap.querySelector('h3');\n          if (!emptyH3 || emptyH3.textContent.trim() !== '') {\n            console.log(`    ❌ No empty h3 found inside content-wrap`);\n            resolve(null);\n            return;\n          }\n\n          // Find the next H1 or H2 after the empty h3\n          let nextElement = emptyH3.nextElementSibling;\n          while (nextElement && !['H1', 'H2'].includes(nextElement.tagName)) {\n            nextElement = nextElement.nextElementSibling;\n          }\n\n          if (nextElement) {\n            const headerText = nextElement.textContent.trim();\n            console.log(`    ✅ Found header: \"${headerText}\"`);\n            resolve(headerText);\n          } else {\n            console.log(`    ❌ No H1/H2 found after empty h3`);\n            resolve(null);\n          }\n        } catch (error) {\n          reject(error);\n        }\n      });\n    }).on('error', reject);\n  });\n};\n\n// Extract header text from anchor on a page\nconst extractHeaderTextFromAnchor = (baseUrl, anchor) => {\n  return new Promise((resolve, reject) => {\n    if (!anchor) {\n      resolve(null);\n      return;\n    }\n\n    console.log(`  🔍 Extracting anchor header from: ${baseUrl}#${anchor}`);\n\n    https.get(baseUrl, (response) => {\n      let data = '';\n\n      response.on('data', (chunk) => {\n        data += chunk;\n      });\n\n      response.on('end', () => {\n        try {\n          const dom = new JSDOM(data);\n          const document = dom.window.document;\n\n          // Find element with matching id\n          const targetElement = document.querySelector(`#${anchor}`);\n          if (targetElement) {\n            const headerText = targetElement.textContent.trim();\n            console.log(`    ✅ Found anchor header: \"${headerText}\"`);\n            resolve(headerText);\n          } else {\n            // Try to find by matching text in headings\n            const headings = document.querySelectorAll('h1, h2, h3, h4, h5, h6');\n            for (const heading of headings) {\n              const headingId = heading.id || '';\n              if (headingId === anchor || heading.textContent.toLowerCase().includes(anchor.replace(/-/g, ' '))) {\n                const headerText = heading.textContent.trim();\n                console.log(`    ✅ Found matching header: \"${headerText}\"`);\n                resolve(headerText);\n                return;\n              }\n            }\n            resolve(null);\n          }\n        } catch (error) {\n          reject(error);\n        }\n      });\n    }).on('error', reject);\n  });\n};\n\n// Fetch and parse the v2.helm.sh docs page\nconst fetchV2Navigation = () => {\n  return new Promise((resolve, reject) => {\n    console.log(`Fetching navigation from ${V2_DOCS_URL}...`);\n\n    https.get(V2_DOCS_URL, (response) => {\n      let data = '';\n\n      response.on('data', (chunk) => {\n        data += chunk;\n      });\n\n      response.on('end', () => {\n        try {\n          console.log('Parsing HTML and extracting navigation...');\n          const dom = new JSDOM(data);\n          const document = dom.window.document;\n\n          // Extract navigation using the provided function\n          const navTree = linksTree('nav.sidebar-nav ul.current.sidebar-main', document);\n\n          console.log(`Extracted ${navTree.length} top-level navigation items`);\n\n          resolve(navTree);\n        } catch (error) {\n          reject(new Error(`Failed to parse navigation: ${error.message}`));\n        }\n      });\n    }).on('error', (error) => {\n      reject(new Error(`Failed to fetch ${V2_DOCS_URL}: ${error.message}`));\n    });\n  });\n};\n\n// Count total items recursively\nconst countTotalItems = (items) => {\n  return items.reduce((count, item) => {\n    return count + 1 + countTotalItems(item.children || []);\n  }, 0);\n};\n\n// Add missing files that exist in orig/docs-v2 but aren't in the menu\nconst addMissingFilesToMenu = (navigationStructure) => {\n  console.log('🔍 Adding missing files to navigation menu...');\n\n  // Find the \"Helm Commands\" category\n  const helmCommandsCategory = navigationStructure.find(item =>\n    item.label === \"Helm Commands\" || (item.children && item.children.some(child =>\n      child.label && child.label.startsWith(\"Helm \")\n    ))\n  );\n\n  if (helmCommandsCategory && helmCommandsCategory.children) {\n    // Add \"helm get notes\" before \"helm get values\"\n    const getValuesIndex = helmCommandsCategory.children.findIndex(child =>\n      child.label === \"Helm Get Values\"\n    );\n\n    if (getValuesIndex > 0) {\n      helmCommandsCategory.children.splice(getValuesIndex, 0, {\n        label: \"Helm Get Notes\",\n        header: \"helm get notes\",\n        link: \"/docs/helm/helm_get_notes/\"\n      });\n      console.log('  ✅ Added \"Helm Get Notes\" before \"Helm Get Values\"');\n    }\n\n    // Add \"helm inspect readme\" before \"helm inspect values\"\n    const inspectValuesIndex = helmCommandsCategory.children.findIndex(child =>\n      child.label === \"Helm Inspect Values\"\n    );\n\n    if (inspectValuesIndex > 0) {\n      helmCommandsCategory.children.splice(inspectValuesIndex, 0, {\n        label: \"Helm Inspect Readme\",\n        header: \"helm inspect readme\",\n        link: \"/docs/helm/helm_inspect_readme/\"\n      });\n      console.log('  ✅ Added \"Helm Inspect Readme\" before \"Helm Inspect Values\"');\n    }\n  }\n};\n\n// Main execution\nconst main = async () => {\n  try {\n    const rawNavTree = await fetchV2Navigation();\n\n    console.log('\\n🔍 Extracting header texts from live site...');\n    const navigationStructure = await convertToSimplifiedFormat(rawNavTree);\n\n    // Add missing files that exist in orig/docs-v2 but aren't in the menu\n    addMissingFilesToMenu(navigationStructure);\n\n    // Write the simplified menu structure\n    const outputPath = './scripts/v2/menu.json';\n    const output = {\n      navigationStructure,\n      metadata: {\n        sourceUrl: V2_DOCS_URL,\n        method: 'DOM extraction with header text extraction from live site',\n        totalItems: countTotalItems(navigationStructure)\n      }\n    };\n\n    fs.writeFileSync(outputPath, JSON.stringify(output, null, 2));\n\n    console.log(`\\n✅ Successfully generated ${outputPath}`);\n    console.log(`📊 Extracted ${output.metadata.totalItems} total navigation items with header texts`);\n    console.log(`🔗 Source: ${V2_DOCS_URL}`);\n\n  } catch (error) {\n    console.error(`❌ Error: ${error.message}`);\n    process.exit(1);\n  }\n};\n\nif (require.main === module) {\n  main();\n}\n\nmodule.exports = { fetchV2Navigation, convertToSimplifiedFormat, linksTree };\n"
  },
  {
    "path": "scripts/v2/menu.json",
    "content": "{\n  \"navigationStructure\": [\n    {\n      \"label\": \"Docs Home\",\n      \"link\": \"/docs\"\n    },\n    {\n      \"label\": \"Using Helm\",\n      \"link\": \"/docs/using_helm/\",\n      \"header\": \"Quickstart Guide\",\n      \"children\": [\n        {\n          \"label\": \"Quickstart\",\n          \"anchor\": \"quickstart-guide\",\n          \"header\": \"Quickstart Guide\"\n        },\n        {\n          \"label\": \"Installing Helm\",\n          \"anchor\": \"installing-helm\",\n          \"header\": \"Installing Helm\"\n        },\n        {\n          \"label\": \"Deprecated Kubernetes APIs\",\n          \"anchor\": \"deprecated-kubernetes-apis\",\n          \"header\": \"Deprecated Kubernetes APIs\"\n        },\n        {\n          \"label\": \"Kubernetes Distro Notes\",\n          \"anchor\": \"kubernetes-distribution-guide\",\n          \"header\": \"Kubernetes Distribution Guide\"\n        },\n        {\n          \"label\": \"Install FAQ\",\n          \"anchor\": \"installation-frequently-asked-questions\",\n          \"header\": \"Installation: Frequently Asked Questions\"\n        },\n        {\n          \"label\": \"Using Helm\",\n          \"anchor\": \"using-helm\",\n          \"header\": \"Using Helm\"\n        },\n        {\n          \"label\": \"Plugins\",\n          \"anchor\": \"the-helm-plugins-guide\",\n          \"header\": \"The Helm Plugins Guide\"\n        },\n        {\n          \"label\": \"Role-Based Access Control\",\n          \"anchor\": \"role-based-access-control\",\n          \"header\": \"Role-based Access Control\"\n        },\n        {\n          \"label\": \"TLS/SSL for Helm and Tiller\",\n          \"anchor\": \"using-ssl-between-helm-and-tiller\",\n          \"header\": \"Using SSL Between Helm and Tiller\"\n        },\n        {\n          \"label\": \"Securing Helm\",\n          \"anchor\": \"securing-your-helm-installation\",\n          \"header\": \"Securing your Helm Installation\"\n        }\n      ]\n    },\n    {\n      \"label\": \"Helm Commands\",\n      \"link\": \"/docs/helm/\",\n      \"header\": \"helm\",\n      \"children\": [\n        {\n          \"label\": \"Helm\",\n          \"anchor\": \"helm\",\n          \"header\": \"helm\"\n        },\n        {\n          \"label\": \"Helm Completion\",\n          \"anchor\": \"helm-completion\",\n          \"header\": \"helm completion\"\n        },\n        {\n          \"label\": \"Helm Create\",\n          \"anchor\": \"helm-create\",\n          \"header\": \"helm create\"\n        },\n        {\n          \"label\": \"Helm Delete\",\n          \"anchor\": \"helm-delete\",\n          \"header\": \"helm delete\"\n        },\n        {\n          \"label\": \"Helm Dependency\",\n          \"anchor\": \"helm-dependency\",\n          \"header\": \"helm dependency\"\n        },\n        {\n          \"label\": \"Helm Dependency Build\",\n          \"anchor\": \"helm-dependency-build\",\n          \"header\": \"helm dependency build\"\n        },\n        {\n          \"label\": \"Helm Dependency List\",\n          \"anchor\": \"helm-dependency-list\",\n          \"header\": \"helm dependency list\"\n        },\n        {\n          \"label\": \"Helm Dependency Update\",\n          \"anchor\": \"helm-dependency-update\",\n          \"header\": \"helm dependency update\"\n        },\n        {\n          \"label\": \"Helm Fetch\",\n          \"anchor\": \"helm-fetch\",\n          \"header\": \"helm fetch\"\n        },\n        {\n          \"label\": \"Helm Get\",\n          \"anchor\": \"helm-get\",\n          \"header\": \"helm get\"\n        },\n        {\n          \"label\": \"Helm Get Hooks\",\n          \"anchor\": \"helm-get-hooks\",\n          \"header\": \"helm get hooks\"\n        },\n        {\n          \"label\": \"Helm Get Manifest\",\n          \"anchor\": \"helm-get-manifest\",\n          \"header\": \"helm get manifest\"\n        },\n        {\n          \"label\": \"Helm Get Notes\",\n          \"header\": \"helm get notes\",\n          \"link\": \"/docs/helm/helm_get_notes/\"\n        },\n        {\n          \"label\": \"Helm Get Values\",\n          \"anchor\": \"helm-get-values\",\n          \"header\": \"helm get values\"\n        },\n        {\n          \"label\": \"Helm History\",\n          \"anchor\": \"helm-history\",\n          \"header\": \"helm history\"\n        },\n        {\n          \"label\": \"Helm Home\",\n          \"anchor\": \"helm-home\",\n          \"header\": \"helm home\"\n        },\n        {\n          \"label\": \"Helm Init\",\n          \"anchor\": \"helm-init\",\n          \"header\": \"helm init\"\n        },\n        {\n          \"label\": \"Helm Inspect\",\n          \"anchor\": \"helm-inspect\",\n          \"header\": \"helm inspect\"\n        },\n        {\n          \"label\": \"Helm Inspect Chart\",\n          \"anchor\": \"helm-inspect-chart\",\n          \"header\": \"helm inspect chart\"\n        },\n        {\n          \"label\": \"Helm Inspect Readme\",\n          \"header\": \"helm inspect readme\",\n          \"link\": \"/docs/helm/helm_inspect_readme/\"\n        },\n        {\n          \"label\": \"Helm Inspect Values\",\n          \"anchor\": \"helm-inspect-values\",\n          \"header\": \"helm inspect values\"\n        },\n        {\n          \"label\": \"Helm Install\",\n          \"anchor\": \"helm-install\",\n          \"header\": \"helm install\"\n        },\n        {\n          \"label\": \"Helm Lint\",\n          \"anchor\": \"helm-lint\",\n          \"header\": \"helm lint\"\n        },\n        {\n          \"label\": \"Helm List\",\n          \"anchor\": \"helm-list\",\n          \"header\": \"helm list\"\n        },\n        {\n          \"label\": \"Helm Package\",\n          \"anchor\": \"helm-package\",\n          \"header\": \"helm package\"\n        },\n        {\n          \"label\": \"Helm Plugin\",\n          \"anchor\": \"helm-plugin\",\n          \"header\": \"helm plugin\"\n        },\n        {\n          \"label\": \"Helm Plugin Install\",\n          \"anchor\": \"helm-plugin-install\",\n          \"header\": \"helm plugin install\"\n        },\n        {\n          \"label\": \"Helm Plugin List\",\n          \"anchor\": \"helm-plugin-list\",\n          \"header\": \"helm plugin list\"\n        },\n        {\n          \"label\": \"Helm Plugin Remove\",\n          \"anchor\": \"helm-plugin-remove\",\n          \"header\": \"helm plugin remove\"\n        },\n        {\n          \"label\": \"Helm Plugin Update\",\n          \"anchor\": \"helm-plugin-update\",\n          \"header\": \"helm plugin update\"\n        },\n        {\n          \"label\": \"Helm Repo\",\n          \"anchor\": \"helm-repo\",\n          \"header\": \"helm repo\"\n        },\n        {\n          \"label\": \"Helm Repo Add\",\n          \"anchor\": \"helm-repo-add\",\n          \"header\": \"helm repo add\"\n        },\n        {\n          \"label\": \"Helm Repo Index\",\n          \"anchor\": \"helm-repo-index\",\n          \"header\": \"helm repo index\"\n        },\n        {\n          \"label\": \"Helm Repo List\",\n          \"anchor\": \"helm-rep-list\"\n        },\n        {\n          \"label\": \"Helm Repo Remove\",\n          \"anchor\": \"helm-repo-remove\",\n          \"header\": \"helm repo remove\"\n        },\n        {\n          \"label\": \"Helm Repo Update\",\n          \"anchor\": \"helm-repo-update\",\n          \"header\": \"helm repo update\"\n        },\n        {\n          \"label\": \"Helm Reset\",\n          \"anchor\": \"helm-reset\",\n          \"header\": \"helm reset\"\n        },\n        {\n          \"label\": \"Helm Rollback\",\n          \"anchor\": \"helm-rollback\",\n          \"header\": \"helm rollback\"\n        },\n        {\n          \"label\": \"Helm Search\",\n          \"anchor\": \"helm-search\",\n          \"header\": \"helm search\"\n        },\n        {\n          \"label\": \"Helm Serve\",\n          \"anchor\": \"helm-serve\",\n          \"header\": \"helm serve\"\n        },\n        {\n          \"label\": \"Helm Status\",\n          \"anchor\": \"helm-status\",\n          \"header\": \"helm status\"\n        },\n        {\n          \"label\": \"Helm Template\",\n          \"anchor\": \"helm-template\",\n          \"header\": \"helm template\"\n        },\n        {\n          \"label\": \"Helm Test\",\n          \"anchor\": \"helm-test\",\n          \"header\": \"helm test\"\n        },\n        {\n          \"label\": \"Helm Upgrade\",\n          \"anchor\": \"helm-upgrade\",\n          \"header\": \"helm upgrade\"\n        },\n        {\n          \"label\": \"Helm Verify\",\n          \"anchor\": \"helm-verify\",\n          \"header\": \"helm verify\"\n        },\n        {\n          \"label\": \"Helm Version\",\n          \"anchor\": \"helm-version\",\n          \"header\": \"helm version\"\n        }\n      ]\n    },\n    {\n      \"label\": \"Charts\",\n      \"link\": \"/docs/developing_charts/\",\n      \"header\": \"Charts\",\n      \"children\": [\n        {\n          \"label\": \"Intro to Charts\",\n          \"anchor\": \"charts\",\n          \"header\": \"Charts\"\n        },\n        {\n          \"label\": \"Chart Lifecycle Hooks\",\n          \"anchor\": \"hooks\",\n          \"header\": \"Hooks\"\n        },\n        {\n          \"label\": \"Charts Tips and Tricks\",\n          \"anchor\": \"chart-development-tips-and-tricks\",\n          \"header\": \"Chart Development Tips and Tricks\"\n        },\n        {\n          \"label\": \"Charts Repository Guide\",\n          \"anchor\": \"the-chart-repository-guide\",\n          \"header\": \"The Chart Repository Guide\"\n        },\n        {\n          \"label\": \"Syncing Your Chart Repo\",\n          \"anchor\": \"syncing-your-chart-repository\",\n          \"header\": \"Syncing Your Chart Repository\"\n        },\n        {\n          \"label\": \"Signing Charts\",\n          \"anchor\": \"helm-provenance-and-integrity\",\n          \"header\": \"Helm Provenance and Integrity\"\n        },\n        {\n          \"label\": \"Chart Tests\",\n          \"anchor\": \"chart-tests\",\n          \"header\": \"Chart Tests\"\n        },\n        {\n          \"label\": \"Chart Repository FAQ\",\n          \"anchor\": \"chart-repositories-frequently-asked-questions\",\n          \"header\": \"Chart Repositories: Frequently Asked Questions\"\n        }\n      ]\n    },\n    {\n      \"label\": \"Developing Templates\",\n      \"link\": \"/docs/chart_template_guide/\",\n      \"header\": \"The Chart Template Developer’s Guide\",\n      \"children\": [\n        {\n          \"label\": \"Intro\",\n          \"anchor\": \"the-chart-template-developer-s-guide\",\n          \"header\": \"The Chart Template Developer’s Guide\"\n        },\n        {\n          \"label\": \"Getting Started\",\n          \"anchor\": \"getting-started-with-a-chart-template\",\n          \"header\": \"Getting Started with a Chart Template\"\n        },\n        {\n          \"label\": \"Built-In Objects\",\n          \"anchor\": \"built-in-objects\",\n          \"header\": \"Built-in Objects\"\n        },\n        {\n          \"label\": \"Values Files\",\n          \"anchor\": \"values-files\",\n          \"header\": \"Values Files\"\n        },\n        {\n          \"label\": \"Template Functions and Pipelines\",\n          \"anchor\": \"template-functions-and-pipelines\",\n          \"header\": \"Template Functions and Pipelines\"\n        },\n        {\n          \"label\": \"Flow Control\",\n          \"anchor\": \"flow-control\",\n          \"header\": \"Flow Control\"\n        },\n        {\n          \"label\": \"Variables\",\n          \"anchor\": \"variables\",\n          \"header\": \"Variables\"\n        },\n        {\n          \"label\": \"Named Templates\",\n          \"anchor\": \"named-templates\",\n          \"header\": \"Named Templates\"\n        },\n        {\n          \"label\": \"Accessing Files Inside Templates\",\n          \"anchor\": \"accessing-files-inside-templates\",\n          \"header\": \"Accessing Files Inside Templates\"\n        },\n        {\n          \"label\": \"Creating a NOTES.txt File\",\n          \"anchor\": \"creating-a-notes-txt-file\",\n          \"header\": \"Creating a NOTES.txt File\"\n        },\n        {\n          \"label\": \"Subcharts and Global Values\",\n          \"anchor\": \"subcharts-and-global-values\",\n          \"header\": \"Subcharts and Global Values\"\n        },\n        {\n          \"label\": \"The .helmignore File\",\n          \"anchor\": \"the-helmignore-file\",\n          \"header\": \"The .helmignore file\"\n        },\n        {\n          \"label\": \"Debugging Templates\",\n          \"anchor\": \"debugging-templates\",\n          \"header\": \"Debugging Templates\"\n        },\n        {\n          \"label\": \"Next Steps\",\n          \"anchor\": \"wrapping-up\",\n          \"header\": \"Wrapping Up\"\n        },\n        {\n          \"label\": \"Appendix: YAML Techniques\",\n          \"anchor\": \"yaml-techniques\",\n          \"header\": \"YAML Techniques\"\n        },\n        {\n          \"label\": \"Appendix: Go Data Types and Templates\",\n          \"anchor\": \"appendix-go-data-types-and-templates\",\n          \"header\": \"Appendix: Go Data Types and Templates\"\n        }\n      ]\n    },\n    {\n      \"label\": \"Best Practices\",\n      \"link\": \"/docs/chart_best_practices/\",\n      \"header\": \"The Chart Best Practices Guide\",\n      \"children\": [\n        {\n          \"label\": \"Intro\",\n          \"anchor\": \"the-chart-best-practices-guide\",\n          \"header\": \"The Chart Best Practices Guide\"\n        },\n        {\n          \"label\": \"General Conventions\",\n          \"anchor\": \"general-conventions\",\n          \"header\": \"General Conventions\"\n        },\n        {\n          \"label\": \"Values\",\n          \"anchor\": \"values\",\n          \"header\": \"Values\"\n        },\n        {\n          \"label\": \"Templates\",\n          \"anchor\": \"templates\",\n          \"header\": \"Templates\"\n        },\n        {\n          \"label\": \"Requirements\",\n          \"anchor\": \"requirements-files\",\n          \"header\": \"Requirements Files\"\n        },\n        {\n          \"label\": \"Labels & Annotations\",\n          \"anchor\": \"labels-and-annotations\",\n          \"header\": \"Labels and Annotations\"\n        },\n        {\n          \"label\": \"Pods & PodTemplates\",\n          \"anchor\": \"pods-and-podtemplates\",\n          \"header\": \"Pods and PodTemplates\"\n        },\n        {\n          \"label\": \"Custom Resource Definitions\",\n          \"anchor\": \"custom-resource-definitions\",\n          \"header\": \"Custom Resource Definitions\"\n        },\n        {\n          \"label\": \"RBAC\",\n          \"anchor\": \"role-based-access-control\",\n          \"header\": \"Role-Based Access Control\"\n        }\n      ]\n    },\n    {\n      \"label\": \"Related Projects\",\n      \"link\": \"/docs/related/\",\n      \"header\": \"Related Projects and Documentation\"\n    },\n    {\n      \"label\": \"Architecture\",\n      \"link\": \"/docs/architecture/\",\n      \"header\": \"The Kubernetes Helm Architecture\"\n    },\n    {\n      \"label\": \"Developer Guide\",\n      \"link\": \"/docs/developers/\",\n      \"header\": \"Developers Guide\"\n    },\n    {\n      \"label\": \"History\",\n      \"link\": \"/docs/history/\",\n      \"header\": \"The History of the Project\"\n    },\n    {\n      \"label\": \"Glossary\",\n      \"link\": \"/docs/glossary/\",\n      \"header\": \"Helm Glossary\"\n    }\n  ],\n  \"metadata\": {\n    \"generatedAt\": \"2025-10-22T06:20:58.478Z\",\n    \"sourceUrl\": \"https://v2.helm.sh/docs/\",\n    \"method\": \"DOM extraction with header text extraction from live site\",\n    \"totalItems\": 100\n  }\n}\n"
  },
  {
    "path": "scripts/v3/add-netlify-redirects.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\n\n/**\n * Adds missing redirects to netlify.toml for Hugo frontmatter aliases that were removed\n */\nfunction addNetlifyRedirects() {\n  const netlifyTomlPath = path.join(__dirname, '..', '..', 'netlify.toml');\n  const removedAliasesPath = path.join(__dirname, 'removed-aliases.json');\n\n  console.log('📝 Adding missing redirects to netlify.toml...');\n\n  // Load removed aliases\n  if (!fs.existsSync(removedAliasesPath)) {\n    console.error('❌ removed-aliases.json not found. Run remove-aliases.js first.');\n    process.exit(1);\n  }\n\n  const removedAliases = JSON.parse(fs.readFileSync(removedAliasesPath, 'utf-8'));\n\n  // Read netlify.toml\n  if (!fs.existsSync(netlifyTomlPath)) {\n    console.error('❌ netlify.toml not found');\n    process.exit(1);\n  }\n\n  let netlifyContent = fs.readFileSync(netlifyTomlPath, 'utf-8');\n\n  // Define the redirects we need to add\n  const redirectsToAdd = [\n    {\n      from: \"/docs/developers/\",\n      to: \"/community/developers/\",\n      status: 302,\n      comment: 'Additional redirects for Hugo frontmatter aliases removed during v3 migration'\n    },\n    {\n      from: \"/docs/history/\",\n      to: \"/community/history/\",\n      status: 302,\n    },\n    {\n      from: \"/docs/related/\",\n      to: \"/community/related/\",\n      status: 302,\n    },\n    {\n      from: '/docs/faq/',\n      to: '/docs/faq/',\n      status: 302\n    },\n    {\n      from: '/docs/using_helm/',\n      to: '/docs/intro/',\n      status: 302\n    },\n    {\n      from: '/docs/architecture/',\n      to: '/docs/topics/architecture/',\n      status: 302\n    },\n    {\n      from: '/docs/developing_charts/',\n      to: '/docs/topics/charts/',\n      status: 302\n    },\n    {\n      from: '/developing_charts/',\n      to: '/docs/topics/charts/',\n      status: 302\n    }\n  ];\n\n  // Check if our section already exists\n  const startMarker =\n    \"# START - Hugo frontmatter aliases redirects, removed during docusaurus migration\";\n  const endMarker = \"# END - Hugo frontmatter aliases redirects\";\n\n  const startIndex = netlifyContent.indexOf(startMarker);\n  const endIndex = netlifyContent.indexOf(endMarker);\n\n  if (startIndex !== -1 && endIndex !== -1) {\n    console.log('  ⏭️  Redirects section already exists, replacing...');\n    // Remove existing section\n    netlifyContent = netlifyContent.substring(0, startIndex) + netlifyContent.substring(endIndex + endMarker.length);\n  } else if (startIndex !== -1) {\n    console.log('  ⚠️  Found start marker but no end marker. Cleaning up...');\n    netlifyContent = netlifyContent.substring(0, startIndex);\n  }\n\n  // Build new redirects section\n  let redirectsSection = `\\n${startMarker}\\n`;\n\n  redirectsToAdd.forEach(redirect => {\n    redirectsSection += `[[redirects]]\\n`;\n    redirectsSection += `  from = \"${redirect.from}\"\\n`;\n    redirectsSection += `  to = \"${redirect.to}\"\\n`;\n    redirectsSection += `  status = ${redirect.status}\\n`;\n    redirectsSection += `\\n`;\n  });\n\n  redirectsSection += `${endMarker}\\n`;\n\n  // Append the new section\n  netlifyContent = netlifyContent.trim() + redirectsSection;\n\n  // Write back to file\n  fs.writeFileSync(netlifyTomlPath, netlifyContent);\n\n  console.log(`✅ Added ${redirectsToAdd.length} redirects to netlify.toml`);\n  console.log('  📋 Redirects added:');\n  redirectsToAdd.forEach(redirect => {\n    console.log(`    ${redirect.from} → ${redirect.to}`);\n  });\n}\n\n// Run if called directly\nif (require.main === module) {\n  addNetlifyRedirects();\n}\n\nmodule.exports = { addNetlifyRedirects };\n"
  },
  {
    "path": "scripts/v3/href-diffs.json",
    "content": "[\n  {\n    \"fileName\": \"index.mdx\",\n    \"before\": \"topics\",\n    \"after\": \"topics/index.mdx\"\n  },\n  {\n    \"fileName\": \"index.mdx\",\n    \"before\": \"/docs/howto/charts_tips_and_tricks/_index.md\",\n    \"after\": \"../howto/charts_tips_and_tricks.md\"\n  },\n  {\n    \"fileName\": \"index.mdx\",\n    \"before\": \"community\",\n    \"after\": \"community/index.mdx\"\n  },\n  {\n    \"fileName\": \"index.mdx\",\n    \"before\": \"howto\",\n    \"after\": \"howto/index.mdx\"\n  },\n  {\n    \"fileName\": \"index.mdx\",\n    \"before\": \"../\",\n    \"after\": \"https://helm.sh/\"\n  },\n  {\n    \"fileName\": \"index.mdx\",\n    \"before\": \"- [开发案例](example) 如果您期望使用SDK做集成开发，这里有一些帮助案例。\",\n    \"after\": \"\"\n  },\n  {\n    \"fileName\": \"chart_best_practices/dependencies.md\",\n    \"before\": \"../topics/plugins#downloader-plugins\",\n    \"after\": \"../topics/plugins.md#downloader-plugins\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/accessing_files.md\",\n    \"before\": \"/docs/chart_template_guide/subcharts_and_globals.md\",\n    \"after\": \"subcharts_and_globals.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/builtin_objects.md\",\n    \"before\": \"/docs/topics/charts.md#the-chartyaml-file\",\n    \"after\": \"../topics/charts.md#the-chartyaml-file\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/builtin_objects.md\",\n    \"before\": \"/docs/chart_template_guide/accessing_files.md\",\n    \"after\": \"accessing_files.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/getting_started.md\",\n    \"before\": \"../../topics/charts\",\n    \"after\": \"../topics/charts\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/getting_started.md\",\n    \"before\": \"_index.md\",\n    \"after\": \"index.mdx\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/getting_started.md\",\n    \"before\": \"./\",\n    \"after\": \"index.mdx\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/subcharts_and_globals.md\",\n    \"before\": \"/docs/topics/library_charts.md\",\n    \"after\": \"../topics/library_charts.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/wrapping_up.md\",\n    \"before\": \"../../topics/charts/\",\n    \"after\": \"../topics/charts.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/wrapping_up.md\",\n    \"before\": \"../../topics/charts_hooks/\",\n    \"after\": \"../topics/charts_hooks.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/wrapping_up.md\",\n    \"before\": \"../../howto/charts_tips_and_tricks/\",\n    \"after\": \"../howto/charts_tips_and_tricks.md\"\n  },\n  {\n    \"fileName\": \"chart_template_guide/function_list.md\",\n    \"before\": \"functions_and_pipelines.md/#using-the-lookup-function\",\n    \"after\": \"functions_and_pipelines.md#using-the-lookup-function\"\n  },\n  {\n    \"fileName\": \"howto/chart_repository_sync_example.md\",\n    \"before\": \"/docs/topics/chart_repository.md\",\n    \"after\": \"../topics/chart_repository.md\"\n  },\n  {\n    \"fileName\": \"howto/chart_repository_sync_example.md\",\n    \"before\": \"/docs/topics/chart_repository.md\",\n    \"after\": \"../topics/chart_repository.md\"\n  },\n  {\n    \"fileName\": \"howto/index.mdx\",\n    \"before\": \"../topics\",\n    \"after\": \"../topics/index.mdx\"\n  },\n  {\n    \"fileName\": \"intro/using_helm.md\",\n    \"before\": \"/docs/howto/charts_tips_and_tricks/_index.md\",\n    \"after\": \"../howto/charts_tips_and_tricks.md\"\n  },\n  {\n    \"fileName\": \"intro/using_helm.md\",\n    \"before\": \"/docs/topics/chart_repository.md\",\n    \"after\": \"../topics/chart_repository.md\"\n  },\n  {\n    \"fileName\": \"intro/using_helm.md\",\n    \"before\": \"/docs/chart_template_guide/values_files/_index.md\",\n    \"after\": \"../chart_template_guide/values_files.md\"\n  },\n  {\n    \"fileName\": \"topics/advanced.md\",\n    \"before\": \"/docs/permissions_sql_storage_backend/\",\n    \"after\": \"permissions_sql_storage_backend.md\"\n  },\n  {\n    \"fileName\": \"topics/chart_repository.md\",\n    \"before\": \"/docs/topics/registries.md\",\n    \"after\": \"registries.md\"\n  },\n  {\n    \"fileName\": \"topics/chart_repository.md\",\n    \"before\": \"quickstart.md\",\n    \"after\": \"../intro/quickstart.md\"\n  },\n  {\n    \"fileName\": \"topics/chart_repository.md\",\n    \"before\": \"/docs/topics/charts.md\",\n    \"after\": \"charts.md\"\n  },\n  {\n    \"fileName\": \"topics/chart_repository.md\",\n    \"before\": \"/docs/howto/chart_releaser_action.md\",\n    \"after\": \"../howto/chart_releaser_action.md\"\n  },\n  {\n    \"fileName\": \"topics/chart_repository.md\",\n    \"before\": \"/docs/howto/chart_repository_sync_example.md\",\n    \"after\": \"../howto/chart_repository_sync_example.md\"\n  },\n  {\n    \"fileName\": \"topics/chart_tests.md\",\n    \"before\": \"/commands/helm_create.md\",\n    \"after\": \"../helm/helm_create.md\"\n  },\n  {\n    \"fileName\": \"topics/chart_tests.md\",\n    \"before\": \"/docs/helm/helm_create\",\n    \"after\": \"../helm/helm_create.md\"\n  },\n  {\n    \"fileName\": \"topics/chart_tests.md\",\n    \"before\": \"/docs/charts_hooks/\",\n    \"after\": \"charts_hooks.md\"\n  },\n  {\n    \"fileName\": \"topics/charts.md\",\n    \"before\": \"/docs/topics/library_charts.md\",\n    \"after\": \"library_charts.md\"\n  },\n  {\n    \"fileName\": \"topics/charts.md\",\n    \"before\": \"/docs/howto/charts_tips_and_tricks.md\",\n    \"after\": \"../howto/charts_tips_and_tricks.md\"\n  },\n  {\n    \"fileName\": \"topics/charts.md\",\n    \"before\": \"/docs/howto/charts_tips_and_tricks.md\",\n    \"after\": \"../howto/charts_tips_and_tricks.md\"\n  },\n  {\n    \"fileName\": \"topics/charts_hooks.md\",\n    \"before\": \"/docs/chart_tests/\",\n    \"after\": \"chart_tests.md\"\n  },\n  {\n    \"fileName\": \"topics/library_charts.md\",\n    \"before\": \"/docs/topics/charts.md\",\n    \"after\": \"charts.md\"\n  },\n  {\n    \"fileName\": \"topics/library_charts.md\",\n    \"before\": \"/docs/topics/charts.md\",\n    \"after\": \"charts.md\"\n  },\n  {\n    \"fileName\": \"topics/library_charts.md\",\n    \"before\": \"/docs/chart_template_guide/named_templates.md\",\n    \"after\": \"../chart_template_guide/named_templates.md\"\n  },\n  {\n    \"fileName\": \"topics/library_charts.md\",\n    \"before\": \"/docs/chart_template_guide/subcharts_and_globals.md\",\n    \"after\": \"../chart_template_guide/subcharts_and_globals.md\"\n  },\n  {\n    \"fileName\": \"topics/plugins.md\",\n    \"before\": \"related.md#helm-plugins\",\n    \"after\": \"../community/related.md#helm-plugins\"\n  },\n  {\n    \"fileName\": \"community/localization.md\",\n    \"before\": \"./localization/#two-letter-language-code\",\n    \"after\": \"#two-letter-language-code\"\n  },\n  {\n    \"fileName\": \"community/release_checklist.md\",\n    \"before\": \"https://docs.helm.sh/using_helm/#quickstart-guide\",\n    \"after\": \"../intro/quickstart.md\"\n  },\n  {\n    \"fileName\": \"community/release_checklist.md\",\n    \"before\": \"https://docs.helm.sh/using_helm/#installing-helm\",\n    \"after\": \"../intro/install.md\"\n  },\n  {\n    \"fileName\": \"community/release_checklist.md\",\n    \"before\": \"/docs\",\n    \"after\": \"../index.mdx\"\n  },\n  {\n    \"fileName\": \"faq/changes_since_helm2.md\",\n    \"before\": \"/docs/topics/advanced/#storage-backends\",\n    \"after\": \"../topics/advanced.md#storage-backends\"\n  },\n  {\n    \"fileName\": \"faq/troubleshooting.md\",\n    \"before\": \"https://helm.sh/docs/topics/v2_v3_migration/#helm\",\n    \"after\": \"../topics/v2_v3_migration.md\"\n  },\n  {\n    \"fileName\": \"intro/install.md\",\n    \"before\": \"https://helm.sh/docs/intro/quickstart/#initialize-a-helm-chart-repository\",\n    \"after\": \"quickstart.md#initialize-a-helm-chart-repository\"\n  },\n  {\n    \"fileName\": \"topics/v2_v3_migration.md\",\n    \"before\": \"https://v3.helm.sh/docs/faq/#changes-since-helm-2\",\n    \"after\": \"../faq/changes_since_helm2.md\"\n  },\n  {\n    \"fileName\": \"community/developers.md\",\n    \"before\": \"https://helm.sh/docs/helm/\",\n    \"after\": \"/helm/index.mdx\"\n  },\n  {\n    \"fileName\": \"community/developers.md\",\n    \"before\": \"/commands/index.mdx\",\n    \"after\": \"../helm/index.mdx\"\n  },\n  {\n    \"fileName\": \"helm/helm_install.md\",\n    \"before\": \"docs/glossary/_index.md#chart-archive\",\n    \"after\": \"../glossary/index.mdx#chart-archive\"\n  },\n  {\n    \"fileName\": \"helm/helm_install.md\",\n    \"before\": \"docs/glossary/_index.md#linhagem-arquivo-de-linhagem\",\n    \"after\": \"../glossary/index.mdx#linhagem-arquivo-de-linhagem\"\n  },\n  {\n    \"fileName\": \"faq/index.mdx\",\n    \"before\": \"<https://storage.googleapis.com/kubernetes-helm/>\",\n    \"after\": \"[https://storage.googleapis.com/kubernetes-helm/](https://storage.googleapis.com/kubernetes-helm/)\"\n  }\n]"
  },
  {
    "path": "scripts/v3/migrate-sdk-section.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\nconst { findFiles } = require('../util/util-file-operations.js');\nconst { frontMatterFromYaml, frontMatterToYaml } = require('../util/util-frontmatter.js');\n\n/**\n * Import SDK examples from .go files to .mdx files with code blocks\n * Also renames examples.md to examples.mdx and adds imports\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction importSdkExamplesFromGoFiles(majorVersion = 3) {\n  console.log('💻 Importing SDK examples from Go files...');\n\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  const sdkDir = path.join(versionDir, 'sdk');\n  const examplesFile = path.join(sdkDir, 'examples.md');\n  const examplesFileMdx = path.join(sdkDir, 'examples.mdx');\n  const examplesFileNew = path.join(sdkDir, 'examples.mdx');\n  const sdkExamplesDir = 'sdkexamples';\n\n  if (!fs.existsSync(sdkExamplesDir)) {\n    console.warn('⚠️  SDK examples source directory not found');\n    return;\n  }\n\n  if (!fs.existsSync(sdkDir)) {\n    console.warn('⚠️  SDK docs directory not found');\n    return;\n  }\n\n  // Find all .go files in sdkexamples/\n  const goFiles = fs.readdirSync(sdkExamplesDir)\n    .filter(file => file.endsWith('.go'));\n\n  let importLines = [];\n  let processedCount = 0;\n\n  // Process each .go file\n  goFiles.forEach(goFile => {\n    try {\n      const name = path.basename(goFile, '.go');\n      const sourcePath = path.join(sdkExamplesDir, goFile);\n      const destPath = path.join(sdkDir, `_${name}.mdx`);\n\n      // Read the .go file content\n      const goContent = fs.readFileSync(sourcePath, 'utf8');\n\n      // Wrap in code block\n      const mdxContent = '```go\\n' + goContent + '\\n```\\n';\n\n      // Write to destination\n      fs.writeFileSync(destPath, mdxContent);\n\n      // Create import line with capitalized name\n      const capName = name.charAt(0).toUpperCase() + name.slice(1);\n      importLines.push(`import ${capName} from './_${name}.mdx'`);\n\n      console.log(`  💻 Processed: ${goFile} → _${name}.mdx`);\n      processedCount++;\n\n    } catch (error) {\n      console.warn(`  ⚠️  Error processing ${goFile}: ${error.message}`);\n    }\n  });\n\n  // Process examples file (either .md or .mdx) and add imports\n  const examplesSourceFile = fs.existsSync(examplesFile) ? examplesFile :\n                            fs.existsSync(examplesFileMdx) ? examplesFileMdx : null;\n\n  if (examplesSourceFile) {\n    try {\n      const content = fs.readFileSync(examplesSourceFile, 'utf8');\n      const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content);\n\n      if (hasFrontmatter) {\n        // Add imports after frontmatter\n        const importsSection = importLines.join('\\n') + '\\n\\n';\n\n        // Remove any existing import lines from restContent\n        const cleanedContent = restContent.replace(/^import .* from '\\.\\/_.*.mdx';?\\n?/gm, '');\n\n        const newRestContent = importsSection + cleanedContent.trim();\n        const updatedContent = frontMatterToYaml(frontmatter, newRestContent);\n\n        fs.writeFileSync(examplesFileNew, updatedContent);\n        if (examplesSourceFile !== examplesFileNew) {\n          fs.unlinkSync(examplesSourceFile); // Remove old file if different\n        }\n\n        console.log('  📝 Updated examples.mdx with imports');\n      }\n    } catch (error) {\n      console.warn(`  ⚠️  Error updating examples file: ${error.message}`);\n    }\n  }\n\n  console.log(`✅ Imported ${processedCount} SDK examples`);\n}\n\n/**\n * Apply SDK href transformations from JSON differences file\n * Uses the sdk-href-diffs.json file to apply SDK-specific text changes\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction applySdkHrefTransformations(majorVersion = 3) {\n  console.log('🔗 Applying SDK href transformations...');\n\n  const versionDir = `versioned_docs/version-${majorVersion}`;\n  const sdkDiffsFile = 'scripts/v3/sdk-href-diffs.json';\n\n  if (!fs.existsSync(sdkDiffsFile)) {\n    console.warn('⚠️  SDK differences file not found:', sdkDiffsFile);\n    console.log('Run href-diffs-generate.js first to create the differences file');\n    return;\n  }\n\n  // Load SDK transformations\n  const sdkTransformations = JSON.parse(fs.readFileSync(sdkDiffsFile, 'utf8'));\n  console.log(`📋 Loaded ${sdkTransformations.length} SDK transformations`);\n\n  const files = findFiles(versionDir, ['.md', '.mdx']);\n\n  let updatedCount = 0;\n  let totalFixes = 0;\n\n  files.forEach(filePath => {\n    try {\n      let content = fs.readFileSync(filePath, 'utf8');\n      let hasChanges = false;\n\n      // Apply each SDK transformation\n      sdkTransformations.forEach(transform => {\n        const { fileName, before, after } = transform;\n\n        // Only apply transformations to the specific file\n        const relativePath = path.relative(versionDir, filePath);\n        if (relativePath === fileName) {\n          // Apply the transformation\n          if (content.includes(before)) {\n            content = content.replace(new RegExp(before.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\$&'), 'g'), after);\n            hasChanges = true;\n            totalFixes++;\n            console.log(`  🔗 Applied SDK transformation: ${before} → ${after}`);\n          }\n        }\n      });\n\n      if (hasChanges) {\n        fs.writeFileSync(filePath, content);\n        console.log(`  ✅ Updated SDK file: ${path.relative(versionDir, filePath)}`);\n        updatedCount++;\n      }\n\n    } catch (error) {\n      console.warn(`  ⚠️  Error processing ${filePath}: ${error.message}`);\n    }\n  });\n\n  console.log(`✅ Applied ${totalFixes} SDK transformations across ${updatedCount} files`);\n}\n\n/**\n * Complete SDK section migration\n * Orchestrates both importing Go files and applying href transformations\n * @param {number} majorVersion - Version number (e.g., 3)\n */\nfunction migrateSdkSection(majorVersion = 3) {\n  console.log('💻 Migrating SDK section...');\n\n  // Step 1: Import SDK examples from Go files to .mdx files\n  importSdkExamplesFromGoFiles(majorVersion);\n\n  // Step 2: Apply SDK href transformations\n  applySdkHrefTransformations(majorVersion);\n\n  console.log('✅ SDK section migration completed');\n}\n\n// Run if called directly\nif (require.main === module) {\n  const majorVersion = process.argv[2] ? parseInt(process.argv[2]) : 3;\n  migrateSdkSection(majorVersion);\n}\n\nmodule.exports = {\n  importSdkExamplesFromGoFiles,\n  applySdkHrefTransformations,\n  migrateSdkSection\n};\n"
  },
  {
    "path": "scripts/v3/migrate-sdk-section.json",
    "content": "[\n  {\n    \"line\": 26,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/install.go\",\n    \"after\": \"<Install />\"\n  },\n  {\n    \"line\": 27,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/upgrade.go\",\n    \"after\": \"<Upgrade />\"\n  },\n  {\n    \"line\": 28,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/uninstall.go\",\n    \"after\": \"<Uninstall />\"\n  },\n  {\n    \"line\": 29,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/list.go\",\n    \"after\": \"<List />\"\n  },\n  {\n    \"line\": 30,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/pull.go\",\n    \"after\": \"<Pull />\"\n  },\n  {\n    \"line\": 31,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/main.go\",\n    \"after\": \"<Main />\"\n  },\n  {\n    \"line\": 32,\n    \"fileName\": \"sdk/gosdk.md\",\n    \"before\": \"./examples.md\",\n    \"after\": \"examples.mdx\"\n  }\n]"
  },
  {
    "path": "scripts/v3/process-helm-files.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\nconst { frontMatterFromYaml, frontMatterToYaml } = require('../util/util-frontmatter.js');\n\n\n/**\n * Process Helm command files in version-3/helm/ and i18n directories\n * - Extract first H2 heading text and set as frontmatter title\n * - Remove the original H2 heading line\n * - Add special configurations for helm category\n */\nfunction processHelmFiles() {\n  console.log('🔧 Processing Helm v3 command files...');\n\n  // Process main docs\n  const mainHelmDir = path.join(__dirname, '..', '..', 'versioned_docs', 'version-3', 'helm');\n  if (fs.existsSync(mainHelmDir)) {\n    console.log('  📁 Processing main docs: versioned_docs/version-3/helm');\n    processHelmDirectory(mainHelmDir);\n  }\n\n  // Process i18n directories\n  const i18nDir = path.join(__dirname, '..', '..');\n  if (fs.existsSync(i18nDir)) {\n    const i18nPath = path.join(i18nDir, 'i18n');\n    if (fs.existsSync(i18nPath)) {\n      const languages = fs.readdirSync(i18nPath, { withFileTypes: true })\n        .filter(dirent => dirent.isDirectory())\n        .map(dirent => dirent.name);\n\n      languages.forEach(lang => {\n        const langHelmDir = path.join(i18nPath, lang, 'docusaurus-plugin-content-docs', 'version-3', 'helm');\n        if (fs.existsSync(langHelmDir)) {\n          console.log(`  🌐 Processing ${lang} translations: i18n/${lang}/docusaurus-plugin-content-docs/version-3/helm`);\n          processHelmDirectory(langHelmDir);\n        }\n      });\n    }\n  }\n\n  console.log('🎉 Helm files processing completed');\n}\n\n/**\n * Process Helm files in a specific directory\n * @param {string} helmDir - Path to helm directory\n */\nfunction processHelmDirectory(helmDir) {\n\n  const files = fs.readdirSync(helmDir).filter(file =>\n    file.endsWith('.md') && file !== 'index.md' && file !== 'index.mdx'\n  );\n\n  console.log(`    📄 Found ${files.length} Helm command files to process`);\n\n  let processedCount = 0;\n\n  // Process regular command files\n  files.forEach(fileName => {\n    const filePath = path.join(helmDir, fileName);\n\n    try {\n      const content = fs.readFileSync(filePath, 'utf8');\n      let processedContent = processHelmFile(content, fileName);\n\n      // Special handling for helm.md - add slug metadata\n      if (fileName === 'helm.md') {\n        const { frontmatter, restContent } = frontMatterFromYaml(processedContent);\n\n        // Add slug if it doesn't exist\n        if (!frontmatter.hasOwnProperty('slug')) {\n          frontmatter.slug = 'helm';\n          processedContent = frontMatterToYaml(frontmatter, restContent);\n          console.log(`    🔧 Added slug metadata to helm.md`);\n        }\n      }\n\n      if (processedContent !== content) {\n        fs.writeFileSync(filePath, processedContent);\n        console.log(`    ✅ Processed: ${fileName}`);\n        processedCount++;\n      } else {\n        console.log(`    ⏭️  Skipped: ${fileName} (no H2 found or already processed)`);\n      }\n    } catch (error) {\n      console.error(`    ❌ Error processing ${fileName}:`, error.message);\n    }\n  });\n\n  // Update index.mdx with id\n  updateIndexMdx(helmDir);\n\n  // Create _category_.json\n  createCategoryJson(helmDir);\n\n  console.log(`    🎉 Successfully processed ${processedCount} files`);\n}\n\n/**\n * Process a single Helm command file\n * @param {string} content - File content\n * @param {string} fileName - File name for logging\n * @returns {string} - Processed content\n */\nfunction processHelmFile(content, fileName) {\n  const lines = content.split('\\n');\n\n  // Find the frontmatter boundaries\n  let frontmatterStart = -1;\n  let frontmatterEnd = -1;\n  let dashCount = 0;\n\n  for (let i = 0; i < lines.length; i++) {\n    if (lines[i].trim() === '---') {\n      dashCount++;\n      if (dashCount === 1) {\n        frontmatterStart = i;\n      } else if (dashCount === 2) {\n        frontmatterEnd = i;\n        break;\n      }\n    }\n  }\n\n  if (frontmatterStart === -1 || frontmatterEnd === -1) {\n    console.warn(`    ⚠️  No frontmatter found in ${fileName}`);\n    return content;\n  }\n\n  // Find the first H2 heading after frontmatter\n  let h2LineIndex = -1;\n  let h2Text = null;\n\n  for (let i = frontmatterEnd + 1; i < lines.length; i++) {\n    const line = lines[i].trim();\n    if (line.startsWith('## ')) {\n      h2Text = line.substring(3).trim(); // Remove \"## \"\n      h2LineIndex = i;\n      break;\n    }\n  }\n\n  if (!h2Text || h2LineIndex === -1) {\n    // No H2 found, skip processing\n    return content;\n  }\n\n  // Remove the H2 line and any empty lines after it\n  const beforeFrontmatter = lines.slice(0, frontmatterStart);\n  const frontmatterLines = lines.slice(frontmatterStart, frontmatterEnd + 1);\n  const afterH2 = lines.slice(h2LineIndex + 1);\n\n  // Remove any empty lines immediately after the removed H2\n  while (afterH2.length > 0 && afterH2[0].trim() === '') {\n    afterH2.shift();\n  }\n\n  // Rebuild content without the H2 line\n  const contentWithoutH2 = [\n    ...beforeFrontmatter,\n    ...frontmatterLines,\n    ...afterH2\n  ].join('\\n');\n\n  // Add the title using general utilities\n  const { frontmatter, restContent } = frontMatterFromYaml(contentWithoutH2);\n  frontmatter.title = h2Text;\n  return frontMatterToYaml(frontmatter, restContent);\n}\n\n\n/**\n * Update index.mdx to add id: helm-category\n * @param {string} helmDir - Helm directory path\n */\nfunction updateIndexMdx(helmDir) {\n  const indexPath = path.join(helmDir, 'index.mdx');\n\n  if (!fs.existsSync(indexPath)) {\n    console.warn(`    ⚠️  index.mdx not found`);\n    return;\n  }\n\n  try {\n    const content = fs.readFileSync(indexPath, 'utf8');\n    const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content);\n\n    if (!hasFrontmatter) {\n      console.warn(`    ⚠️  No frontmatter found in index.mdx`);\n      return;\n    }\n\n    let needsUpdate = false;\n\n    // Add id field if missing\n    if (!frontmatter.hasOwnProperty('id')) {\n      frontmatter.id = 'helm-category';\n      needsUpdate = true;\n    }\n\n    // Remove slug field if present (Docusaurus handles helm/ directory slug automatically)\n    if (frontmatter.hasOwnProperty('slug')) {\n      delete frontmatter.slug;\n      needsUpdate = true;\n    }\n\n    if (needsUpdate) {\n      const updatedContent = frontMatterToYaml(frontmatter, restContent);\n      fs.writeFileSync(indexPath, updatedContent);\n      console.log(`    🔧 Updated index.mdx metadata`);\n    } else {\n      console.log(`    ⏭️  index.mdx already up to date`);\n    }\n\n  } catch (error) {\n    console.error(`    ❌ Error updating index.mdx:`, error.message);\n  }\n}\n\n/**\n * Create _category_.json file\n * @param {string} helmDir - Helm directory path\n */\nfunction createCategoryJson(helmDir) {\n  const categoryPath = path.join(helmDir, '_category_.json');\n\n  const categoryContent = `{\n  \"link\": { \"type\": \"doc\", \"id\": \"helm-category\" }\n}\n`;\n\n  try {\n    fs.writeFileSync(categoryPath, categoryContent);\n    console.log(`    📁 Created _category_.json`);\n  } catch (error) {\n    console.error(`    ❌ Error creating _category_.json:`, error.message);\n  }\n}\n\n// Main execution\nif (require.main === module) {\n  processHelmFiles();\n}\n\nmodule.exports = {\n  processHelmFiles\n};\n"
  },
  {
    "path": "scripts/v3/remove-aliases.js",
    "content": "#!/usr/bin/env node\n\nconst fs = require('fs');\nconst path = require('path');\nconst { frontMatterFromYaml, frontMatterToYaml } = require('../util/util-frontmatter.js');\n\n/**\n * Find and remove all aliases from v3 .md and .mdx files\n */\nfunction removeAliasesFromFiles() {\n  console.log('🔍 Finding and removing aliases from version-3 files...');\n\n  const v3DocsDir = path.join(__dirname, '..', '..', 'versioned_docs', 'version-3');\n  const i18nDir = path.join(__dirname, '..', '..', 'i18n');\n\n  if (!fs.existsSync(v3DocsDir)) {\n    console.error('❌ Version-3 docs directory not found:', v3DocsDir);\n    process.exit(1);\n  }\n\n  const aliasesFound = [];\n  let filesWithAliases = 0;\n  let aliasesRemoved = 0;\n\n  /**\n   * Recursively process directory for .md and .mdx files\n   * @param {string} dirPath - Directory to process\n   * @param {string} relativePath - Relative path for display\n   */\n  function processDirectory(dirPath, relativePath = '') {\n    const entries = fs.readdirSync(dirPath, { withFileTypes: true });\n\n    entries.forEach(entry => {\n      const fullPath = path.join(dirPath, entry.name);\n      const relativeFilePath = path.join(relativePath, entry.name);\n\n      if (entry.isDirectory()) {\n        // Recursively process subdirectories\n        processDirectory(fullPath, relativeFilePath);\n      } else if (entry.isFile() && (entry.name.endsWith('.md') || entry.name.endsWith('.mdx'))) {\n        // Process markdown files\n        processMarkdownFile(fullPath, relativeFilePath);\n      }\n    });\n  }\n\n  /**\n   * Process a single markdown file\n   * @param {string} filePath - Full path to the file\n   * @param {string} relativeFilePath - Relative path for display\n   */\n  function processMarkdownFile(filePath, relativeFilePath) {\n\n    try {\n      const content = fs.readFileSync(filePath, 'utf8');\n      const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content);\n\n      if (!hasFrontmatter) {\n        return; // Skip files without frontmatter\n      }\n\n      // Check if aliases exist\n      if (frontmatter.hasOwnProperty('aliases') && Array.isArray(frontmatter.aliases)) {\n        const aliases = [...frontmatter.aliases]; // Copy the array\n\n        // Only record aliases from main docs, not i18n docs\n        const isI18nFile = relativeFilePath.startsWith('i18n/');\n        if (!isI18nFile) {\n          aliasesFound.push({\n            file: relativeFilePath,\n            aliases: aliases\n          });\n        }\n\n        filesWithAliases++;\n        aliasesRemoved += aliases.length;\n\n        // Remove aliases from frontmatter\n        delete frontmatter.aliases;\n\n        // Write back the updated content\n        const updatedContent = frontMatterToYaml(frontmatter, restContent);\n        fs.writeFileSync(filePath, updatedContent);\n\n        console.log(`  ✅ Processed: ${relativeFilePath} (removed ${aliases.length} aliases)`);\n      }\n\n    } catch (error) {\n      console.error(`  ❌ Error processing ${relativeFilePath}:`, error.message);\n    }\n  }\n\n  // Start processing from v3 docs directory\n  processDirectory(v3DocsDir);\n\n  // Process i18n translation directories for v3\n  const languages = ['de', 'es', 'fr', 'ja', 'ko', 'zh'];\n  languages.forEach(lang => {\n    const i18nVersionDir = path.join(i18nDir, lang, 'docusaurus-plugin-content-docs', 'version-3');\n    if (fs.existsSync(i18nVersionDir)) {\n      console.log(`\\n🌍 Processing translation directory: ${lang}`);\n      processDirectory(i18nVersionDir, `i18n/${lang}/version-3`);\n    }\n  });\n\n  // Display results\n  console.log('\\n📊 Summary:');\n  console.log(`  Files with aliases: ${filesWithAliases}`);\n  console.log(`  Total aliases removed: ${aliasesRemoved}`);\n\n  if (aliasesFound.length > 0) {\n    console.log('\\n📋 Aliases found and removed:');\n    console.log('=====================================');\n\n    aliasesFound.forEach(({ file, aliases }) => {\n      console.log(`\\n📄 ${file}:`);\n      aliases.forEach((alias, index) => {\n        console.log(`  ${index + 1}. ${alias}`);\n      });\n    });\n\n    // Also write to a file for reference\n    const aliasesReport = {\n      summary: {\n        filesWithAliases,\n        aliasesRemoved\n      },\n      aliases: aliasesFound\n    };\n\n    const reportPath = path.join(__dirname, 'removed-aliases.json');\n    fs.writeFileSync(reportPath, JSON.stringify(aliasesReport, null, 2));\n    console.log(`\\n💾 Detailed report saved to: ${reportPath}`);\n\n  } else {\n    console.log('\\n✨ No aliases found in any files.');\n  }\n\n  console.log('\\n🎉 Aliases removal completed!');\n}\n\n// Main execution\nif (require.main === module) {\n  removeAliasesFromFiles();\n}\n\nmodule.exports = { removeAliasesFromFiles };\n"
  },
  {
    "path": "scripts/v3/removed-aliases.json",
    "content": "{\n  \"summary\": {\n    \"filesWithAliases\": 42,\n    \"aliasesRemoved\": 44\n  },\n  \"aliases\": [\n    {\n      \"file\": \"chart_best_practices/conventions.md\",\n      \"aliases\": [\n        \"/docs/topics/chart_best_practices/conventions/\"\n      ]\n    },\n    {\n      \"file\": \"chart_best_practices/custom_resource_definitions.md\",\n      \"aliases\": [\n        \"/docs/topics/chart_best_practices/custom_resource_definitions/\"\n      ]\n    },\n    {\n      \"file\": \"chart_best_practices/dependencies.md\",\n      \"aliases\": [\n        \"/docs/topics/chart_best_practices/dependencies/\"\n      ]\n    },\n    {\n      \"file\": \"chart_best_practices/index.mdx\",\n      \"aliases\": [\n        \"/docs/topics/chart_best_practices/\"\n      ]\n    },\n    {\n      \"file\": \"chart_best_practices/labels.md\",\n      \"aliases\": [\n        \"/docs/topics/chart_best_practices/labels/\"\n      ]\n    },\n    {\n      \"file\": \"chart_best_practices/pods.md\",\n      \"aliases\": [\n        \"/docs/topics/chart_best_practices/pods/\"\n      ]\n    },\n    {\n      \"file\": \"chart_best_practices/rbac.md\",\n      \"aliases\": [\n        \"/docs/topics/chart_best_practices/rbac/\"\n      ]\n    },\n    {\n      \"file\": \"chart_best_practices/templates.md\",\n      \"aliases\": [\n        \"/docs/topics/chart_best_practices/templates/\"\n      ]\n    },\n    {\n      \"file\": \"chart_best_practices/values.md\",\n      \"aliases\": [\n        \"/docs/topics/chart_best_practices/values/\"\n      ]\n    },\n    {\n      \"file\": \"chart_template_guide/getting_started.md\",\n      \"aliases\": [\n        \"/intro/getting_started/\"\n      ]\n    },\n    {\n      \"file\": \"chart_template_guide/index.mdx\",\n      \"aliases\": [\n        \"/topics/chart_template_guide/\"\n      ]\n    },\n    {\n      \"file\": \"community/developers.md\",\n      \"aliases\": [\n        \"/docs/developers/\"\n      ]\n    },\n    {\n      \"file\": \"community/history.md\",\n      \"aliases\": [\n        \"/docs/history/\"\n      ]\n    },\n    {\n      \"file\": \"community/localization.md\",\n      \"aliases\": [\n        \"/docs/localization/\"\n      ]\n    },\n    {\n      \"file\": \"community/related.md\",\n      \"aliases\": [\n        \"/docs/related/\"\n      ]\n    },\n    {\n      \"file\": \"faq/index.mdx\",\n      \"aliases\": [\n        \"/docs/topics/faq/\",\n        \"/docs/faq/\"\n      ]\n    },\n    {\n      \"file\": \"howto/chart_repository_sync_example.md\",\n      \"aliases\": [\n        \"/docs/chart_repository_sync_example/\"\n      ]\n    },\n    {\n      \"file\": \"howto/charts_tips_and_tricks.md\",\n      \"aliases\": [\n        \"/docs/charts_tips_and_tricks/\"\n      ]\n    },\n    {\n      \"file\": \"intro/index.mdx\",\n      \"aliases\": [\n        \"/docs/using_helm/\"\n      ]\n    },\n    {\n      \"file\": \"intro/install.md\",\n      \"aliases\": [\n        \"/docs/install/\"\n      ]\n    },\n    {\n      \"file\": \"intro/quickstart.md\",\n      \"aliases\": [\n        \"/docs/quickstart/\"\n      ]\n    },\n    {\n      \"file\": \"sdk/gosdk.md\",\n      \"aliases\": [\n        \"/docs/gosdk\"\n      ]\n    },\n    {\n      \"file\": \"topics/advanced.md\",\n      \"aliases\": [\n        \"/docs/advanced_helm_techniques\"\n      ]\n    },\n    {\n      \"file\": \"topics/architecture.md\",\n      \"aliases\": [\n        \"/docs/architecture/\"\n      ]\n    },\n    {\n      \"file\": \"topics/chart_repository.md\",\n      \"aliases\": [\n        \"/docs/chart_repository/\"\n      ]\n    },\n    {\n      \"file\": \"topics/chart_tests.md\",\n      \"aliases\": [\n        \"/docs/chart_tests/\"\n      ]\n    },\n    {\n      \"file\": \"topics/charts.md\",\n      \"aliases\": [\n        \"docs/developing_charts/\",\n        \"developing_charts\"\n      ]\n    },\n    {\n      \"file\": \"topics/charts_hooks.md\",\n      \"aliases\": [\n        \"/docs/charts_hooks/\"\n      ]\n    },\n    {\n      \"file\": \"topics/kubernetes_apis.md\",\n      \"aliases\": [\n        \"docs/k8s_apis/\"\n      ]\n    },\n    {\n      \"file\": \"topics/kubernetes_distros.md\",\n      \"aliases\": [\n        \"/docs/kubernetes_distros/\"\n      ]\n    },\n    {\n      \"file\": \"topics/library_charts.md\",\n      \"aliases\": [\n        \"docs/library_charts/\"\n      ]\n    },\n    {\n      \"file\": \"topics/permissions_sql_storage_backend.md\",\n      \"aliases\": [\n        \"/docs/permissions_sql_storage_backend/\"\n      ]\n    },\n    {\n      \"file\": \"topics/plugins.md\",\n      \"aliases\": [\n        \"/docs/plugins/\"\n      ]\n    },\n    {\n      \"file\": \"topics/provenance.md\",\n      \"aliases\": [\n        \"/docs/provenance/\"\n      ]\n    },\n    {\n      \"file\": \"topics/rbac.md\",\n      \"aliases\": [\n        \"/docs/rbac/\"\n      ]\n    },\n    {\n      \"file\": \"topics/registries.md\",\n      \"aliases\": [\n        \"/docs/registries/\"\n      ]\n    }\n  ]\n}"
  },
  {
    "path": "scripts/v3/sdk-href-diffs.json",
    "content": "[\n  {\n    \"line\": 26,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/install.go\",\n    \"after\": \"<Install />\"\n  },\n  {\n    \"line\": 27,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/upgrade.go\",\n    \"after\": \"<Upgrade />\"\n  },\n  {\n    \"line\": 28,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/uninstall.go\",\n    \"after\": \"<Uninstall />\"\n  },\n  {\n    \"line\": 29,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/list.go\",\n    \"after\": \"<List />\"\n  },\n  {\n    \"line\": 30,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/pull.go\",\n    \"after\": \"<Pull />\"\n  },\n  {\n    \"line\": 31,\n    \"fileName\": \"sdk/examples.mdx\",\n    \"before\": \"sdkexamples/main.go\",\n    \"after\": \"<Main />\"\n  },\n  {\n    \"line\": 32,\n    \"fileName\": \"sdk/gosdk.md\",\n    \"before\": \"./examples.md\",\n    \"after\": \"examples.mdx\"\n  }\n]"
  },
  {
    "path": "scripts/v4/changelog.mjs",
    "content": "#!/usr/bin/env node\n\nimport { execSync } from \"child_process\";\nimport fs from \"fs\";\nimport path from \"path\";\nimport { fileURLToPath } from \"url\";\nimport { Octokit } from \"@octokit/rest\";\nimport simpleGit from \"simple-git\";\nimport pLimit from \"p-limit\";\nimport ora from \"ora\";\n\n// ESM compatibility for __dirname\nconst __filename = fileURLToPath(import.meta.url);\nconst __dirname = path.dirname(__filename);\n\n// Configuration\nconst PARALLEL_LIMIT = 10; // Process 10 commits at a time\nconst RATE_LIMIT_THRESHOLD = 500;\nconst PROJECT_ROOT = path.resolve(__dirname, \"../..\");\nconst HELM_REPO_DIR = path.join(PROJECT_ROOT, \"orig/helm\");\n\n// Breaking changes and backported PRs (manually identified)\nconst BREAKING_CHANGES = new Set([\n  13617, 30586, 30589, 31081, 31165, 31216, 31225, 30812, 31030, 31142, 31194,\n  31145, 31146, 31172, 31174, 31176, 31196, 31217, 31218, 31219, 31220, 13629,\n  30982, 30749, 13573, 13611, 30567, 30580, 13494, 31023, 13458, 30686,\n]);\n\n// Parse command line arguments\nconst args = process.argv.slice(2);\n\n// Validate required arguments\nif (args.length < 2) {\n  console.error(\"Error: Missing required arguments\");\n  console.error(\"\");\n  console.error(\n    \"Usage: node scripts/v4/changelog.mjs <base-ref> <head-ref> [output-file]\"\n  );\n  console.error(\"\");\n  console.error(\"Examples:\");\n  console.error(\"  node scripts/v4/changelog.mjs v3.19.0 v4.0.0-rc.1\");\n  console.error(\"  node scripts/v4/changelog.mjs v4.0.0-beta.1 v4.0.0-beta.2\");\n  console.error(\n    \"  node scripts/v4/changelog.mjs v3.19.0 main docs/changelog.md\"\n  );\n  console.error(\"\");\n  console.error(\"Arguments:\");\n  console.error(\n    \"  base-ref    The starting ref (tag, branch, or commit) to compare from\"\n  );\n  console.error(\n    \"  head-ref    The ending ref (tag, branch, or commit) to compare to\"\n  );\n  console.error(\n    \"  output-file Optional output file path (default: docs/changelog.md)\"\n  );\n  process.exit(1);\n}\n\nconst BASE_REF = args[0];\nconst HEAD_REF = args[1];\nconst OUTPUT_FILE = args[2] || \"docs/changelog.md\";\n\n// Get GitHub token\nlet githubToken = process.env.GITHUB_TOKEN;\nif (!githubToken) {\n  try {\n    githubToken = execSync(\"gh auth token\", { encoding: \"utf8\" }).trim();\n  } catch (e) {\n    console.error(\"Error: GitHub authentication required\");\n    console.error(\"\");\n    console.error(\"Please authenticate using one of these methods:\");\n    console.error(\"  1. Run: gh auth login\");\n    console.error(\n      \"  2. Set environment variable: export GITHUB_TOKEN=<your-token>\"\n    );\n    console.error(\"\");\n    console.error(\n      \"You can create a token at: https://github.com/settings/tokens\"\n    );\n    process.exit(1);\n  }\n}\n\n// Initialize Octokit with auth token\nconst octokit = new Octokit({\n  auth: githubToken,\n  throttle: {\n    onRateLimit: (retryAfter, options) => {\n      console.log(`Rate limit hit, waiting ${retryAfter} seconds...`);\n      return true;\n    },\n    onSecondaryRateLimit: (retryAfter, options) => {\n      console.log(`Secondary rate limit hit, waiting ${retryAfter} seconds...`);\n      return true;\n    },\n  },\n});\n\nasync function setupHelmRepo() {\n  const spinner = ora(\"Setting up helm repository...\").start();\n\n  // Create orig directory if it doesn't exist\n  if (!fs.existsSync(path.join(PROJECT_ROOT, \"orig\"))) {\n    fs.mkdirSync(path.join(PROJECT_ROOT, \"orig\"), { recursive: true });\n  }\n\n  const git = simpleGit();\n\n  if (!fs.existsSync(HELM_REPO_DIR)) {\n    spinner.text = \"Cloning helm/helm repository...\";\n    await git.clone(\"https://github.com/helm/helm.git\", HELM_REPO_DIR);\n  } else {\n    spinner.text = \"Helm repository already exists, updating...\";\n  }\n\n  // Fetch latest tags\n  const helmGit = simpleGit(HELM_REPO_DIR);\n  spinner.text = \"Fetching latest tags...\";\n  await helmGit.fetch([\"--all\", \"--tags\"]);\n\n  // Verify tags exist\n  const tags = await helmGit.tags();\n  if (!tags.all.includes(BASE_REF)) {\n    spinner.fail(`Error: Tag ${BASE_REF} not found in helm repository`);\n    process.exit(1);\n  }\n  if (!tags.all.includes(HEAD_REF)) {\n    spinner.fail(`Error: Tag ${HEAD_REF} not found in helm repository`);\n    process.exit(1);\n  }\n\n  spinner.succeed(\"Helm repository ready\");\n  return helmGit;\n}\n\nasync function getCommits(git) {\n  const spinner = ora(\"Getting commits from git...\").start();\n\n  // Get all commits between refs\n  const revListOutput = await git.raw([\"rev-list\", `${BASE_REF}..${HEAD_REF}`]);\n  const allCommits = revListOutput.trim().split(\"\\n\").filter(Boolean);\n\n  spinner.text = `Found ${allCommits.length} commits, filtering merge commits...`;\n\n  // Filter out merge commits\n  const nonMergeCommits = [];\n  const limit = pLimit(20); // Check 20 commits in parallel\n\n  await Promise.all(\n    allCommits.map((sha) =>\n      limit(async () => {\n        const parentCount = (\n          await git.raw([\"show\", \"--no-patch\", \"--format=%P\", sha])\n        )\n          .trim()\n          .split(\" \").length;\n        if (parentCount < 2) {\n          nonMergeCommits.push(sha);\n        }\n      })\n    )\n  );\n\n  spinner.succeed(\n    `Found ${nonMergeCommits.length} non-merge commits (filtered ${\n      allCommits.length - nonMergeCommits.length\n    } merge commits)`\n  );\n  return nonMergeCommits;\n}\n\nasync function checkRateLimit() {\n  try {\n    const { data } = await octokit.rateLimit.get();\n    return data.rate.remaining;\n  } catch {\n    return 5000; // Default if can't check\n  }\n}\n\nasync function fetchPRForCommit(sha, git) {\n  try {\n    // Get PRs associated with this commit\n    const { data: prs } = await octokit.request(\n      \"GET /repos/{owner}/{repo}/commits/{commit_sha}/pulls\",\n      {\n        owner: \"helm\",\n        repo: \"helm\",\n        commit_sha: sha,\n      }\n    );\n\n    if (prs.length === 0) {\n      // Get commit info for commits without PRs\n      const commitInfo = await git.show([\"-s\", \"--format=%h %ai %an: %s\", sha]);\n      return { sha, commitInfo: commitInfo.trim(), prs: [] };\n    }\n\n    // Filter out dependabot and return PR details\n    const validPRs = prs.filter(\n      (pr) =>\n        pr.user.login !== \"dependabot\" && pr.user.login !== \"dependabot[bot]\"\n    );\n\n    return { sha, prs: validPRs };\n  } catch (error) {\n    console.error(`Error fetching PR for commit ${sha}:`, error.message);\n    return { sha, prs: [], error: true };\n  }\n}\n\nasync function fetchAllPRs(commits, git) {\n  const spinner = ora(\"Fetching PR associations...\").start();\n  const prCache = new Map();\n  const commitsWithoutPRs = [];\n  let processed = 0;\n  let dependabotSkipped = 0;\n\n  // Create a limited concurrent processor\n  const limit = pLimit(PARALLEL_LIMIT);\n\n  // Check initial rate limit\n  const remaining = await checkRateLimit();\n  if (remaining < RATE_LIMIT_THRESHOLD) {\n    console.warn(`⚠️  Low API rate limit: ${remaining} remaining`);\n  }\n\n  // Process all commits with concurrency limit\n  const results = await Promise.all(\n    commits.map((sha) =>\n      limit(async () => {\n        const result = await fetchPRForCommit(sha, git);\n        processed++;\n\n        // Update progress\n        const percentage = Math.round((processed / commits.length) * 100);\n        spinner.text = `Fetching PR associations... ${processed}/${commits.length} (${percentage}%) - Found ${prCache.size} unique PRs`;\n\n        // Process results\n        if (result.commitInfo) {\n          commitsWithoutPRs.push(result);\n        } else {\n          for (const pr of result.prs) {\n            if (!prCache.has(pr.number)) {\n              // Check for dependabot\n              if (\n                pr.user.login === \"dependabot\" ||\n                pr.user.login === \"dependabot[bot]\"\n              ) {\n                dependabotSkipped++;\n              } else {\n                prCache.set(pr.number, {\n                  number: pr.number,\n                  title: pr.title,\n                  mergedAt: pr.merged_at,\n                  author: { login: pr.user.login },\n                  labels: { nodes: pr.labels.map((l) => ({ name: l.name })) },\n                });\n              }\n            }\n          }\n        }\n\n        return result;\n      })\n    )\n  );\n\n  spinner.succeed(\n    `Fetched ${prCache.size} unique PRs (${dependabotSkipped} dependabot PRs skipped)`\n  );\n\n  // Report commits without PRs\n  if (commitsWithoutPRs.length > 0) {\n    console.log(\n      `\\nFound ${commitsWithoutPRs.length} commits without associated PRs:`\n    );\n    commitsWithoutPRs.forEach((commit, i) => {\n      console.log(`  ${i + 1}. ${commit.commitInfo}`);\n      console.log(`     SHA: ${commit.sha}`);\n    });\n  }\n\n  return Array.from(prCache.values());\n}\n\nfunction categorizePRs(prs) {\n  const categories = {\n    features: [],\n    bugs: [],\n    refactor: [],\n    other: [],\n    backported_features: [],\n    backported_bugs: [],\n    backported_refactor: [],\n    backported_other: [],\n  };\n\n  for (const pr of prs) {\n    const labels = pr.labels.nodes.map((n) => n.name);\n    // Check if backported either by manual list or by \"v3 port complete\" label\n    const isBackported = labels.includes(\"v3 port complete\");\n    const category = isBackported ? \"backported_\" : \"\";\n\n    // Add breaking change flag\n    if (BREAKING_CHANGES.has(pr.number)) {\n      pr.isBreaking = true;\n    }\n\n    if (labels.includes(\"feature\")) {\n      categories[`${category}features`].push(pr);\n    } else if (labels.includes(\"bug\")) {\n      categories[`${category}bugs`].push(pr);\n    } else if (labels.includes(\"refactor\")) {\n      categories[`${category}refactor`].push(pr);\n    } else {\n      categories[`${category}other`].push(pr);\n    }\n  }\n\n  return categories;\n}\n\nfunction formatPRRow(pr) {\n  const date = pr.mergedAt ? pr.mergedAt.split(\"T\")[0] : \"unknown\";\n  const author = pr.author.login || \"unknown\";\n  let title = pr.title;\n\n  if (pr.isBreaking) {\n    title = `<span class=\"breaking\">BREAKING CHANGE:</span> ${title}`;\n  }\n\n  return `| #${pr.number} | ${date} | ${author} | ${title} |`;\n}\n\nfunction sortByDate(prs) {\n  return prs.sort((a, b) => new Date(b.mergedAt) - new Date(a.mergedAt));\n}\n\nfunction generateMarkdown(categories, totalPRs) {\n  const backportedCount =\n    categories.backported_features.length +\n    categories.backported_bugs.length +\n    categories.backported_refactor.length +\n    categories.backported_other.length;\n\n  const v4OnlyCount = totalPRs - backportedCount;\n\n  let output = `---\nsidebar_position: 2\nsidebar_label: Full Changelog\n---\n\n# Helm 4 Full Changelog\n\n**Scope**: ${totalPRs} PRs from (\\`${HEAD_REF}\\`) compared to \\`${BASE_REF}\\`\n**v4-only**: ${v4OnlyCount} PRs (${backportedCount} backported to v3 excluded)\n\nSee the [Overview](/overview.md) for an actionable summary of these changes.\n\n`;\n\n  // New Features\n  if (categories.features.length > 0) {\n    output += `## New Features\n\nNew features in Helm 4 that were not backported to v3\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n${sortByDate(categories.features).map(formatPRRow).join(\"\\n\")}\n\n`;\n  }\n\n  // Bug Fixes\n  if (categories.bugs.length > 0) {\n    output += `## Bug Fixes\n\nFixes in Helm 4 that were not backported to v3\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n${sortByDate(categories.bugs).map(formatPRRow).join(\"\\n\")}\n\n`;\n  }\n\n  // Refactor/Cleanup\n  if (categories.refactor.length > 0) {\n    output += `## Refactor/Cleanup\n\nCode quality improvements and modernization\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n${sortByDate(categories.refactor).map(formatPRRow).join(\"\\n\")}\n\n`;\n  }\n\n  // Other\n  if (categories.other.length > 0) {\n    output += `## Other\n\nInfrastructure and project management improvements\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n${sortByDate(categories.other).map(formatPRRow).join(\"\\n\")}\n\n`;\n  }\n\n  // Backported section\n  output += `## v4 Changes Also Backported to v3\n\nThese PRs were included in v4 but were also backported to v3 releases\n\n`;\n\n  if (categories.backported_features.length > 0) {\n    output += `### New Features (Backported)\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n${sortByDate(categories.backported_features).map(formatPRRow).join(\"\\n\")}\n\n`;\n  }\n\n  if (categories.backported_bugs.length > 0) {\n    output += `### Bug Fixes (Backported)\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n${sortByDate(categories.backported_bugs).map(formatPRRow).join(\"\\n\")}\n\n`;\n  }\n\n  if (categories.backported_refactor.length > 0) {\n    output += `### Refactor/Cleanup (Backported)\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n${sortByDate(categories.backported_refactor).map(formatPRRow).join(\"\\n\")}\n\n`;\n  }\n\n  if (categories.backported_other.length > 0) {\n    output += `### Other (Backported)\n\n| PR | Date | Author | Title |\n|---|---|---|---|\n${sortByDate(categories.backported_other).map(formatPRRow).join(\"\\n\")}\n\n`;\n  }\n\n  return output;\n}\n\nasync function main() {\n  console.log(\"===============================================\");\n  console.log(\"Generating changelog with Node.js (ESM)\");\n  console.log(`Base: ${BASE_REF}`);\n  console.log(`Head: ${HEAD_REF}`);\n  console.log(\"===============================================\\n\");\n\n  const startTime = Date.now();\n\n  try {\n    // Step 1: Setup helm repository\n    const git = await setupHelmRepo();\n\n    // Step 2: Get commits\n    const commits = await getCommits(git);\n\n    // Step 3: Fetch all PRs in parallel\n    const prs = await fetchAllPRs(commits, git);\n\n    // Step 4: Categorize PRs\n    const spinner = ora(\"Categorizing PRs...\").start();\n    const categories = categorizePRs(prs);\n    spinner.succeed(\"PRs categorized\");\n\n    // Step 5: Generate markdown\n    spinner.text = \"Generating markdown...\";\n    const markdown = generateMarkdown(categories, prs.length);\n\n    // Step 6: Write to file\n    fs.writeFileSync(OUTPUT_FILE, markdown);\n    spinner.succeed(`Changelog written to ${OUTPUT_FILE}`);\n\n    // Summary\n    const elapsed = ((Date.now() - startTime) / 1000).toFixed(1);\n    console.log(\"\\n✅ Complete!\");\n    console.log(`Total time: ${elapsed} seconds`);\n    console.log(`Total PRs: ${prs.length}`);\n\n    const backportedCount =\n      categories.backported_features.length +\n      categories.backported_bugs.length +\n      categories.backported_refactor.length +\n      categories.backported_other.length;\n\n    console.log(`v4-only PRs: ${prs.length - backportedCount}`);\n    console.log(`Backported PRs: ${backportedCount}`);\n  } catch (error) {\n    console.error(\"Error:\", error);\n    process.exit(1);\n  }\n}\n\n// Run the script\nmain();\n"
  },
  {
    "path": "sdkexamples/.gitignore",
    "content": "podinfo-6.4.1.tgz\n"
  },
  {
    "path": "sdkexamples/Makefile",
    "content": ".PHONY: build\nbuild: $(BINDIR)/$(BINNAME)\n\tgo build ./...\n"
  },
  {
    "path": "sdkexamples/README.md",
    "content": "# Helm Go SDK examples\n\nThis directory implements various Go SDK examples and a \"driver\".\n\nThese examples are fully working, and can be run by:\n\n```\n# cd helm-www/sdkexamples\n$ go run ./...\n```"
  },
  {
    "path": "sdkexamples/go.mod",
    "content": "module github.com/helm/helm-www/sdkexamples\n\ngo 1.24.0\n\nrequire helm.sh/helm/v4 v4.0.0\n\nrequire (\n\tdario.cat/mergo v1.0.1 // indirect\n\tgithub.com/Azure/go-ansiterm v0.0.0-20250102033503-faa5f7b0171c // indirect\n\tgithub.com/BurntSushi/toml v1.5.0 // indirect\n\tgithub.com/MakeNowJust/heredoc v1.0.0 // indirect\n\tgithub.com/Masterminds/goutils v1.1.1 // indirect\n\tgithub.com/Masterminds/semver/v3 v3.4.0 // indirect\n\tgithub.com/Masterminds/sprig/v3 v3.3.0 // indirect\n\tgithub.com/Masterminds/squirrel v1.5.4 // indirect\n\tgithub.com/ProtonMail/go-crypto v1.3.0 // indirect\n\tgithub.com/asaskevich/govalidator v0.0.0-20230301143203-a9d515a09cc2 // indirect\n\tgithub.com/blang/semver/v4 v4.0.0 // indirect\n\tgithub.com/chai2010/gettext-go v1.0.2 // indirect\n\tgithub.com/cloudflare/circl v1.6.3 // indirect\n\tgithub.com/cyphar/filepath-securejoin v0.6.0 // indirect\n\tgithub.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc // indirect\n\tgithub.com/dylibso/observe-sdk/go v0.0.0-20240819160327-2d926c5d788a // indirect\n\tgithub.com/emicklei/go-restful/v3 v3.12.2 // indirect\n\tgithub.com/evanphx/json-patch/v5 v5.9.11 // indirect\n\tgithub.com/exponent-io/jsonpath v0.0.0-20210407135951-1de76d718b3f // indirect\n\tgithub.com/extism/go-sdk v1.7.1 // indirect\n\tgithub.com/fatih/color v1.18.0 // indirect\n\tgithub.com/fluxcd/cli-utils v0.36.0-flux.14 // indirect\n\tgithub.com/fxamacker/cbor/v2 v2.9.0 // indirect\n\tgithub.com/go-errors/errors v1.5.1 // indirect\n\tgithub.com/go-gorp/gorp/v3 v3.1.0 // indirect\n\tgithub.com/go-logr/logr v1.4.3 // indirect\n\tgithub.com/go-openapi/jsonpointer v0.21.1 // indirect\n\tgithub.com/go-openapi/jsonreference v0.21.0 // indirect\n\tgithub.com/go-openapi/swag v0.23.1 // indirect\n\tgithub.com/gobwas/glob v0.2.3 // indirect\n\tgithub.com/gogo/protobuf v1.3.2 // indirect\n\tgithub.com/google/btree v1.1.3 // indirect\n\tgithub.com/google/gnostic-models v0.7.0 // indirect\n\tgithub.com/google/go-cmp v0.7.0 // indirect\n\tgithub.com/google/uuid v1.6.0 // indirect\n\tgithub.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674 // indirect\n\tgithub.com/gosuri/uitable v0.0.4 // indirect\n\tgithub.com/gregjones/httpcache v0.0.0-20190611155906-901d90724c79 // indirect\n\tgithub.com/huandu/xstrings v1.5.0 // indirect\n\tgithub.com/ianlancetaylor/demangle v0.0.0-20240805132620-81f5be970eca // indirect\n\tgithub.com/inconshreveable/mousetrap v1.1.0 // indirect\n\tgithub.com/jmoiron/sqlx v1.4.0 // indirect\n\tgithub.com/josharian/intern v1.0.0 // indirect\n\tgithub.com/json-iterator/go v1.1.12 // indirect\n\tgithub.com/lann/builder v0.0.0-20180802200727-47ae307949d0 // indirect\n\tgithub.com/lann/ps v0.0.0-20150810152359-62de8c46ede0 // indirect\n\tgithub.com/lib/pq v1.10.9 // indirect\n\tgithub.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de // indirect\n\tgithub.com/mailru/easyjson v0.9.0 // indirect\n\tgithub.com/mattn/go-colorable v0.1.13 // indirect\n\tgithub.com/mattn/go-isatty v0.0.20 // indirect\n\tgithub.com/mattn/go-runewidth v0.0.9 // indirect\n\tgithub.com/mitchellh/copystructure v1.2.0 // indirect\n\tgithub.com/mitchellh/go-wordwrap v1.0.1 // indirect\n\tgithub.com/mitchellh/reflectwalk v1.0.2 // indirect\n\tgithub.com/moby/spdystream v0.5.1 // indirect\n\tgithub.com/moby/term v0.5.2 // indirect\n\tgithub.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect\n\tgithub.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee // indirect\n\tgithub.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00 // indirect\n\tgithub.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect\n\tgithub.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f // indirect\n\tgithub.com/opencontainers/go-digest v1.0.0 // indirect\n\tgithub.com/opencontainers/image-spec v1.1.1 // indirect\n\tgithub.com/peterbourgon/diskv v2.0.1+incompatible // indirect\n\tgithub.com/pkg/errors v0.9.1 // indirect\n\tgithub.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 // indirect\n\tgithub.com/rubenv/sql-migrate v1.8.0 // indirect\n\tgithub.com/russross/blackfriday/v2 v2.1.0 // indirect\n\tgithub.com/santhosh-tekuri/jsonschema/v6 v6.0.2 // indirect\n\tgithub.com/shopspring/decimal v1.4.0 // indirect\n\tgithub.com/spf13/cast v1.7.0 // indirect\n\tgithub.com/spf13/cobra v1.10.1 // indirect\n\tgithub.com/spf13/pflag v1.0.10 // indirect\n\tgithub.com/tetratelabs/wabin v0.0.0-20230304001439-f6f874872834 // indirect\n\tgithub.com/tetratelabs/wazero v1.9.0 // indirect\n\tgithub.com/x448/float16 v0.8.4 // indirect\n\tgithub.com/xlab/treeprint v1.2.0 // indirect\n\tgo.opentelemetry.io/proto/otlp v1.5.0 // indirect\n\tgo.yaml.in/yaml/v2 v2.4.2 // indirect\n\tgo.yaml.in/yaml/v3 v3.0.4 // indirect\n\tgolang.org/x/crypto v0.45.0 // indirect\n\tgolang.org/x/net v0.47.0 // indirect\n\tgolang.org/x/oauth2 v0.30.0 // indirect\n\tgolang.org/x/sync v0.18.0 // indirect\n\tgolang.org/x/sys v0.38.0 // indirect\n\tgolang.org/x/term v0.37.0 // indirect\n\tgolang.org/x/text v0.31.0 // indirect\n\tgolang.org/x/time v0.12.0 // indirect\n\tgoogle.golang.org/protobuf v1.36.6 // indirect\n\tgopkg.in/evanphx/json-patch.v4 v4.12.0 // indirect\n\tgopkg.in/inf.v0 v0.9.1 // indirect\n\tgopkg.in/yaml.v3 v3.0.1 // indirect\n\tk8s.io/api v0.34.1 // indirect\n\tk8s.io/apiextensions-apiserver v0.34.1 // indirect\n\tk8s.io/apimachinery v0.34.1 // indirect\n\tk8s.io/apiserver v0.34.1 // indirect\n\tk8s.io/cli-runtime v0.34.1 // indirect\n\tk8s.io/client-go v0.34.1 // indirect\n\tk8s.io/component-base v0.34.1 // indirect\n\tk8s.io/klog/v2 v2.130.1 // indirect\n\tk8s.io/kube-openapi v0.0.0-20250710124328-f3f2b991d03b // indirect\n\tk8s.io/kubectl v0.34.1 // indirect\n\tk8s.io/utils v0.0.0-20250604170112-4c0f3b243397 // indirect\n\toras.land/oras-go/v2 v2.6.0 // indirect\n\tsigs.k8s.io/controller-runtime v0.22.3 // indirect\n\tsigs.k8s.io/json v0.0.0-20241014173422-cfa47c3a1cc8 // indirect\n\tsigs.k8s.io/kustomize/api v0.20.1 // indirect\n\tsigs.k8s.io/kustomize/kyaml v0.20.1 // indirect\n\tsigs.k8s.io/randfill v1.0.0 // indirect\n\tsigs.k8s.io/structured-merge-diff/v6 v6.3.0 // indirect\n\tsigs.k8s.io/yaml v1.6.0 // indirect\n)\n"
  },
  {
    "path": "sdkexamples/go.sum",
    "content": "dario.cat/mergo v1.0.1 h1:Ra4+bf83h2ztPIQYNP99R6m+Y7KfnARDfID+a+vLl4s=\ndario.cat/mergo v1.0.1/go.mod h1:uNxQE+84aUszobStD9th8a29P2fMDhsBdgRYvZOxGmk=\nfilippo.io/edwards25519 v1.1.0 h1:FNf4tywRC1HmFuKW5xopWpigGjJKiJSV0Cqo0cJWDaA=\nfilippo.io/edwards25519 v1.1.0/go.mod h1:BxyFTGdWcka3PhytdK4V28tE5sGfRvvvRV7EaN4VDT4=\ngithub.com/AdaLogics/go-fuzz-headers v0.0.0-20230811130428-ced1acdcaa24 h1:bvDV9vkmnHYOMsOr4WLk+Vo07yKIzd94sVoIqshQ4bU=\ngithub.com/AdaLogics/go-fuzz-headers v0.0.0-20230811130428-ced1acdcaa24/go.mod h1:8o94RPi1/7XTJvwPpRSzSUedZrtlirdB3r9Z20bi2f8=\ngithub.com/Azure/go-ansiterm v0.0.0-20250102033503-faa5f7b0171c h1:udKWzYgxTojEKWjV8V+WSxDXJ4NFATAsZjh8iIbsQIg=\ngithub.com/Azure/go-ansiterm v0.0.0-20250102033503-faa5f7b0171c/go.mod h1:xomTg63KZ2rFqZQzSB4Vz2SUXa1BpHTVz9L5PTmPC4E=\ngithub.com/BurntSushi/toml v1.5.0 h1:W5quZX/G/csjUnuI8SUYlsHs9M38FC7znL0lIO+DvMg=\ngithub.com/BurntSushi/toml v1.5.0/go.mod h1:ukJfTF/6rtPPRCnwkur4qwRxa8vTRFBF0uk2lLoLwho=\ngithub.com/DATA-DOG/go-sqlmock v1.5.2 h1:OcvFkGmslmlZibjAjaHm3L//6LiuBgolP7OputlJIzU=\ngithub.com/DATA-DOG/go-sqlmock v1.5.2/go.mod h1:88MAG/4G7SMwSE3CeA0ZKzrT5CiOU3OJ+JlNzwDqpNU=\ngithub.com/MakeNowJust/heredoc v1.0.0 h1:cXCdzVdstXyiTqTvfqk9SDHpKNjxuom+DOlyEeQ4pzQ=\ngithub.com/MakeNowJust/heredoc v1.0.0/go.mod h1:mG5amYoWBHf8vpLOuehzbGGw0EHxpZZ6lCpQ4fNJ8LE=\ngithub.com/Masterminds/goutils v1.1.1 h1:5nUrii3FMTL5diU80unEVvNevw1nH4+ZV4DSLVJLSYI=\ngithub.com/Masterminds/goutils v1.1.1/go.mod h1:8cTjp+g8YejhMuvIA5y2vz3BpJxksy863GQaJW2MFNU=\ngithub.com/Masterminds/semver/v3 v3.4.0 h1:Zog+i5UMtVoCU8oKka5P7i9q9HgrJeGzI9SA1Xbatp0=\ngithub.com/Masterminds/semver/v3 v3.4.0/go.mod h1:4V+yj/TJE1HU9XfppCwVMZq3I84lprf4nC11bSS5beM=\ngithub.com/Masterminds/sprig/v3 v3.3.0 h1:mQh0Yrg1XPo6vjYXgtf5OtijNAKJRNcTdOOGZe3tPhs=\ngithub.com/Masterminds/sprig/v3 v3.3.0/go.mod h1:Zy1iXRYNqNLUolqCpL4uhk6SHUMAOSCzdgBfDb35Lz0=\ngithub.com/Masterminds/squirrel v1.5.4 h1:uUcX/aBc8O7Fg9kaISIUsHXdKuqehiXAMQTYX8afzqM=\ngithub.com/Masterminds/squirrel v1.5.4/go.mod h1:NNaOrjSoIDfDA40n7sr2tPNZRfjzjA400rg+riTZj10=\ngithub.com/ProtonMail/go-crypto v1.3.0 h1:ILq8+Sf5If5DCpHQp4PbZdS1J7HDFRXz/+xKBiRGFrw=\ngithub.com/ProtonMail/go-crypto v1.3.0/go.mod h1:9whxjD8Rbs29b4XWbB8irEcE8KHMqaR2e7GWU1R+/PE=\ngithub.com/armon/go-socks5 v0.0.0-20160902184237-e75332964ef5 h1:0CwZNZbxp69SHPdPJAN/hZIm0C4OItdklCFmMRWYpio=\ngithub.com/armon/go-socks5 v0.0.0-20160902184237-e75332964ef5/go.mod h1:wHh0iHkYZB8zMSxRWpUBQtwG5a7fFgvEO+odwuTv2gs=\ngithub.com/asaskevich/govalidator v0.0.0-20230301143203-a9d515a09cc2 h1:DklsrG3dyBCFEj5IhUbnKptjxatkF07cF2ak3yi77so=\ngithub.com/asaskevich/govalidator v0.0.0-20230301143203-a9d515a09cc2/go.mod h1:WaHUgvxTVq04UNunO+XhnAqY/wQc+bxr74GqbsZ/Jqw=\ngithub.com/beorn7/perks v1.0.1 h1:VlbKKnNfV8bJzeqoa4cOKqO6bYr3WgKZxO8Z16+hsOM=\ngithub.com/beorn7/perks v1.0.1/go.mod h1:G2ZrVWU2WbWT9wwq4/hrbKbnv/1ERSJQ0ibhJ6rlkpw=\ngithub.com/blang/semver/v4 v4.0.0 h1:1PFHFE6yCCTv8C1TeyNNarDzntLi7wMI5i/pzqYIsAM=\ngithub.com/blang/semver/v4 v4.0.0/go.mod h1:IbckMUScFkM3pff0VJDNKRiT6TG/YpiHIM2yvyW5YoQ=\ngithub.com/bshuster-repo/logrus-logstash-hook v1.0.0 h1:e+C0SB5R1pu//O4MQ3f9cFuPGoOVeF2fE4Og9otCc70=\ngithub.com/bshuster-repo/logrus-logstash-hook v1.0.0/go.mod h1:zsTqEiSzDgAa/8GZR7E1qaXrhYNDKBYy5/dWPTIflbk=\ngithub.com/cenkalti/backoff/v4 v4.3.0 h1:MyRJ/UdXutAwSAT+s3wNd7MfTIcy71VQueUuFK343L8=\ngithub.com/cenkalti/backoff/v4 v4.3.0/go.mod h1:Y3VNntkOUPxTVeUxJ/G5vcM//AlwfmyYozVcomhLiZE=\ngithub.com/cespare/xxhash/v2 v2.3.0 h1:UL815xU9SqsFlibzuggzjXhog7bL6oX9BbNZnL2UFvs=\ngithub.com/cespare/xxhash/v2 v2.3.0/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs=\ngithub.com/chai2010/gettext-go v1.0.2 h1:1Lwwip6Q2QGsAdl/ZKPCwTe9fe0CjlUbqj5bFNSjIRk=\ngithub.com/chai2010/gettext-go v1.0.2/go.mod h1:y+wnP2cHYaVj19NZhYKAwEMH2CI1gNHeQQ+5AjwawxA=\ngithub.com/cloudflare/circl v1.6.3 h1:9GPOhQGF9MCYUeXyMYlqTR6a5gTrgR/fBLXvUgtVcg8=\ngithub.com/cloudflare/circl v1.6.3/go.mod h1:2eXP6Qfat4O/Yhh8BznvKnJ+uzEoTQ6jVKJRn81BiS4=\ngithub.com/coreos/go-systemd/v22 v22.5.0 h1:RrqgGjYQKalulkV8NGVIfkXQf6YYmOyiJKk8iXXhfZs=\ngithub.com/coreos/go-systemd/v22 v22.5.0/go.mod h1:Y58oyj3AT4RCenI/lSvhwexgC+NSVTIJ3seZv2GcEnc=\ngithub.com/cpuguy83/go-md2man/v2 v2.0.6/go.mod h1:oOW0eioCTA6cOiMLiUPZOpcVxMig6NIQQ7OS05n1F4g=\ngithub.com/creack/pty v1.1.18 h1:n56/Zwd5o6whRC5PMGretI4IdRLlmBXYNjScPaBgsbY=\ngithub.com/creack/pty v1.1.18/go.mod h1:MOBLtS5ELjhRRrroQr9kyvTxUAFNvYEK993ew/Vr4O4=\ngithub.com/cyphar/filepath-securejoin v0.6.0 h1:BtGB77njd6SVO6VztOHfPxKitJvd/VPT+OFBFMOi1Is=\ngithub.com/cyphar/filepath-securejoin v0.6.0/go.mod h1:A8hd4EnAeyujCJRrICiOWqjS1AX0a9kM5XL+NwKoYSc=\ngithub.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=\ngithub.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=\ngithub.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc h1:U9qPSI2PIWSS1VwoXQT9A3Wy9MM3WgvqSxFWenqJduM=\ngithub.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=\ngithub.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f h1:lO4WD4F/rVNCu3HqELle0jiPLLBs70cWOduZpkS1E78=\ngithub.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f/go.mod h1:cuUVRXasLTGF7a8hSLbxyZXjz+1KgoB3wDUb6vlszIc=\ngithub.com/distribution/distribution/v3 v3.0.0 h1:q4R8wemdRQDClzoNNStftB2ZAfqOiN6UX90KJc4HjyM=\ngithub.com/distribution/distribution/v3 v3.0.0/go.mod h1:tRNuFoZsUdyRVegq8xGNeds4KLjwLCRin/tTo6i1DhU=\ngithub.com/distribution/reference v0.6.0 h1:0IXCQ5g4/QMHHkarYzh5l+u8T3t73zM5QvfrDyIgxBk=\ngithub.com/distribution/reference v0.6.0/go.mod h1:BbU0aIcezP1/5jX/8MP0YiH4SdvB5Y4f/wlDRiLyi3E=\ngithub.com/dlclark/regexp2 v1.11.0 h1:G/nrcoOa7ZXlpoa/91N3X7mM3r8eIlMBBJZvsz/mxKI=\ngithub.com/dlclark/regexp2 v1.11.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8=\ngithub.com/docker/docker-credential-helpers v0.8.2 h1:bX3YxiGzFP5sOXWc3bTPEXdEaZSeVMrFgOr3T+zrFAo=\ngithub.com/docker/docker-credential-helpers v0.8.2/go.mod h1:P3ci7E3lwkZg6XiHdRKft1KckHiO9a2rNtyFbZ/ry9M=\ngithub.com/docker/go-events v0.0.0-20190806004212-e31b211e4f1c h1:+pKlWGMw7gf6bQ+oDZB4KHQFypsfjYlq/C4rfL7D3g8=\ngithub.com/docker/go-events v0.0.0-20190806004212-e31b211e4f1c/go.mod h1:Uw6UezgYA44ePAFQYUehOuCzmy5zmg/+nl2ZfMWGkpA=\ngithub.com/docker/go-metrics v0.0.1 h1:AgB/0SvBxihN0X8OR4SjsblXkbMvalQ8cjmtKQ2rQV8=\ngithub.com/docker/go-metrics v0.0.1/go.mod h1:cG1hvH2utMXtqgqqYE9plW6lDxS3/5ayHzueweSI3Vw=\ngithub.com/dylibso/observe-sdk/go v0.0.0-20240819160327-2d926c5d788a h1:UwSIFv5g5lIvbGgtf3tVwC7Ky9rmMFBp0RMs+6f6YqE=\ngithub.com/dylibso/observe-sdk/go v0.0.0-20240819160327-2d926c5d788a/go.mod h1:C8DzXehI4zAbrdlbtOByKX6pfivJTBiV9Jjqv56Yd9Q=\ngithub.com/emicklei/go-restful/v3 v3.12.2 h1:DhwDP0vY3k8ZzE0RunuJy8GhNpPL6zqLkDf9B/a0/xU=\ngithub.com/emicklei/go-restful/v3 v3.12.2/go.mod h1:6n3XBCmQQb25CM2LCACGz8ukIrRry+4bhvbpWn3mrbc=\ngithub.com/evanphx/json-patch/v5 v5.9.11 h1:/8HVnzMq13/3x9TPvjG08wUGqBTmZBsCWzjTM0wiaDU=\ngithub.com/evanphx/json-patch/v5 v5.9.11/go.mod h1:3j+LviiESTElxA4p3EMKAB9HXj3/XEtnUf6OZxqIQTM=\ngithub.com/exponent-io/jsonpath v0.0.0-20210407135951-1de76d718b3f h1:Wl78ApPPB2Wvf/TIe2xdyJxTlb6obmF18d8QdkxNDu4=\ngithub.com/exponent-io/jsonpath v0.0.0-20210407135951-1de76d718b3f/go.mod h1:OSYXu++VVOHnXeitef/D8n/6y4QV8uLHSFXX4NeXMGc=\ngithub.com/extism/go-sdk v1.7.1 h1:lWJos6uY+tRFdlIHR+SJjwFDApY7OypS/2nMhiVQ9Sw=\ngithub.com/extism/go-sdk v1.7.1/go.mod h1:IT+Xdg5AZM9hVtpFUA+uZCJMge/hbvshl8bwzLtFyKA=\ngithub.com/fatih/color v1.18.0 h1:S8gINlzdQ840/4pfAwic/ZE0djQEH3wM94VfqLTZcOM=\ngithub.com/fatih/color v1.18.0/go.mod h1:4FelSpRwEGDpQ12mAdzqdOukCy4u8WUtOY6lkT/6HfU=\ngithub.com/felixge/httpsnoop v1.0.4 h1:NFTV2Zj1bL4mc9sqWACXbQFVBBg2W3GPvqp8/ESS2Wg=\ngithub.com/felixge/httpsnoop v1.0.4/go.mod h1:m8KPJKqk1gH5J9DgRY2ASl2lWCfGKXixSwevea8zH2U=\ngithub.com/fluxcd/cli-utils v0.36.0-flux.14 h1:I//AMVUXTc+M04UtIXArMXQZCazGMwfemodV1j/yG8c=\ngithub.com/fluxcd/cli-utils v0.36.0-flux.14/go.mod h1:uDo7BYOfbdmk/asnHuI0IQPl6u0FCgcN54AHDu3Y5As=\ngithub.com/foxcpp/go-mockdns v1.1.0 h1:jI0rD8M0wuYAxL7r/ynTrCQQq0BVqfB99Vgk7DlmewI=\ngithub.com/foxcpp/go-mockdns v1.1.0/go.mod h1:IhLeSFGed3mJIAXPH2aiRQB+kqz7oqu8ld2qVbOu7Wk=\ngithub.com/frankban/quicktest v1.14.6 h1:7Xjx+VpznH+oBnejlPUj8oUpdxnVs4f8XU8WnHkI4W8=\ngithub.com/frankban/quicktest v1.14.6/go.mod h1:4ptaffx2x8+WTWXmUCuVU6aPUX1/Mz7zb5vbUoiM6w0=\ngithub.com/fxamacker/cbor/v2 v2.9.0 h1:NpKPmjDBgUfBms6tr6JZkTHtfFGcMKsw3eGcmD/sapM=\ngithub.com/fxamacker/cbor/v2 v2.9.0/go.mod h1:vM4b+DJCtHn+zz7h3FFp/hDAI9WNWCsZj23V5ytsSxQ=\ngithub.com/go-errors/errors v1.5.1 h1:ZwEMSLRCapFLflTpT7NKaAc7ukJ8ZPEjzlxt8rPN8bk=\ngithub.com/go-errors/errors v1.5.1/go.mod h1:sIVyrIiJhuEF+Pj9Ebtd6P/rEYROXFi3BopGUQ5a5Og=\ngithub.com/go-gorp/gorp/v3 v3.1.0 h1:ItKF/Vbuj31dmV4jxA1qblpSwkl9g1typ24xoe70IGs=\ngithub.com/go-gorp/gorp/v3 v3.1.0/go.mod h1:dLEjIyyRNiXvNZ8PSmzpt1GsWAUK8kjVhEpjH8TixEw=\ngithub.com/go-logr/logr v1.4.3 h1:CjnDlHq8ikf6E492q6eKboGOC0T8CDaOvkHCIg8idEI=\ngithub.com/go-logr/logr v1.4.3/go.mod h1:9T104GzyrTigFIr8wt5mBrctHMim0Nb2HLGrmQ40KvY=\ngithub.com/go-logr/stdr v1.2.2 h1:hSWxHoqTgW2S2qGc0LTAI563KZ5YKYRhT3MFKZMbjag=\ngithub.com/go-logr/stdr v1.2.2/go.mod h1:mMo/vtBO5dYbehREoey6XUKy/eSumjCCveDpRre4VKE=\ngithub.com/go-logr/zapr v1.3.0 h1:XGdV8XW8zdwFiwOA2Dryh1gj2KRQyOOoNmBy4EplIcQ=\ngithub.com/go-logr/zapr v1.3.0/go.mod h1:YKepepNBd1u/oyhd/yQmtjVXmm9uML4IXUgMOwR8/Gg=\ngithub.com/go-openapi/jsonpointer v0.21.1 h1:whnzv/pNXtK2FbX/W9yJfRmE2gsmkfahjMKB0fZvcic=\ngithub.com/go-openapi/jsonpointer v0.21.1/go.mod h1:50I1STOfbY1ycR8jGz8DaMeLCdXiI6aDteEdRNNzpdk=\ngithub.com/go-openapi/jsonreference v0.21.0 h1:Rs+Y7hSXT83Jacb7kFyjn4ijOuVGSvOdF2+tg1TRrwQ=\ngithub.com/go-openapi/jsonreference v0.21.0/go.mod h1:LmZmgsrTkVg9LG4EaHeY8cBDslNPMo06cago5JNLkm4=\ngithub.com/go-openapi/swag v0.23.1 h1:lpsStH0n2ittzTnbaSloVZLuB5+fvSY/+hnagBjSNZU=\ngithub.com/go-openapi/swag v0.23.1/go.mod h1:STZs8TbRvEQQKUA+JZNAm3EWlgaOBGpyFDqQnDHMef0=\ngithub.com/go-sql-driver/mysql v1.8.1 h1:LedoTUt/eveggdHS9qUFC1EFSa8bU2+1pZjSRpvNJ1Y=\ngithub.com/go-sql-driver/mysql v1.8.1/go.mod h1:wEBSXgmK//2ZFJyE+qWnIsVGmvmEKlqwuVSjsCm7DZg=\ngithub.com/go-task/slim-sprig/v3 v3.0.0 h1:sUs3vkvUymDpBKi3qH1YSqBQk9+9D/8M2mN1vB6EwHI=\ngithub.com/go-task/slim-sprig/v3 v3.0.0/go.mod h1:W848ghGpv3Qj3dhTPRyJypKRiqCdHZiAzKg9hl15HA8=\ngithub.com/gobwas/glob v0.2.3 h1:A4xDbljILXROh+kObIiy5kIaPYD8e96x1tgBhUI5J+Y=\ngithub.com/gobwas/glob v0.2.3/go.mod h1:d3Ez4x06l9bZtSvzIay5+Yzi0fmZzPgnTbPcKjJAkT8=\ngithub.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q=\ngithub.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q=\ngithub.com/google/btree v1.1.3 h1:CVpQJjYgC4VbzxeGVHfvZrv1ctoYCAI8vbl07Fcxlyg=\ngithub.com/google/btree v1.1.3/go.mod h1:qOPhT0dTNdNzV6Z/lhRX0YXUafgPLFUh+gZMl761Gm4=\ngithub.com/google/gnostic-models v0.7.0 h1:qwTtogB15McXDaNqTZdzPJRHvaVJlAl+HVQnLmJEJxo=\ngithub.com/google/gnostic-models v0.7.0/go.mod h1:whL5G0m6dmc5cPxKc5bdKdEN3UjI7OUGxBlw57miDrQ=\ngithub.com/google/go-cmp v0.7.0 h1:wk8382ETsv4JYUZwIsn6YpYiWiBsYLSJiTsyBybVuN8=\ngithub.com/google/go-cmp v0.7.0/go.mod h1:pXiqmnSA92OHEEa9HXL2W4E7lf9JzCmGVUdgjX3N/iU=\ngithub.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg=\ngithub.com/google/pprof v0.0.0-20250630185457-6e76a2b096b5 h1:xhMrHhTJ6zxu3gA4enFM9MLn9AY7613teCdFnlUVbSQ=\ngithub.com/google/pprof v0.0.0-20250630185457-6e76a2b096b5/go.mod h1:5hDyRhoBCxViHszMt12TnOpEI4VVi+U8Gm9iphldiMA=\ngithub.com/google/uuid v1.6.0 h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0=\ngithub.com/google/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=\ngithub.com/gorilla/handlers v1.5.2 h1:cLTUSsNkgcwhgRqvCNmdbRWG0A3N4F+M2nWKdScwyEE=\ngithub.com/gorilla/handlers v1.5.2/go.mod h1:dX+xVpaxdSw+q0Qek8SSsl3dfMk3jNddUkMzo0GtH0w=\ngithub.com/gorilla/mux v1.8.1 h1:TuBL49tXwgrFYWhqrNgrUNEY92u81SPhu7sTdzQEiWY=\ngithub.com/gorilla/mux v1.8.1/go.mod h1:AKf9I4AEqPTmMytcMc0KkNouC66V3BtZ4qD5fmWSiMQ=\ngithub.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674 h1:JeSE6pjso5THxAzdVpqr6/geYxZytqFMBCOtn/ujyeo=\ngithub.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674/go.mod h1:r4w70xmWCQKmi1ONH4KIaBptdivuRPyosB9RmPlGEwA=\ngithub.com/gosuri/uitable v0.0.4 h1:IG2xLKRvErL3uhY6e1BylFzG+aJiwQviDDTfOKeKTpY=\ngithub.com/gosuri/uitable v0.0.4/go.mod h1:tKR86bXuXPZazfOTG1FIzvjIdXzd0mo4Vtn16vt0PJo=\ngithub.com/gregjones/httpcache v0.0.0-20190611155906-901d90724c79 h1:+ngKgrYPPJrOjhax5N+uePQ0Fh1Z7PheYoUI/0nzkPA=\ngithub.com/gregjones/httpcache v0.0.0-20190611155906-901d90724c79/go.mod h1:FecbI9+v66THATjSRHfNgh1IVFe/9kFxbXtjV0ctIMA=\ngithub.com/grpc-ecosystem/grpc-gateway/v2 v2.26.3 h1:5ZPtiqj0JL5oKWmcsq4VMaAW5ukBEgSGXEN89zeH1Jo=\ngithub.com/grpc-ecosystem/grpc-gateway/v2 v2.26.3/go.mod h1:ndYquD05frm2vACXE1nsccT4oJzjhw2arTS2cpUD1PI=\ngithub.com/hashicorp/golang-lru/arc/v2 v2.0.5 h1:l2zaLDubNhW4XO3LnliVj0GXO3+/CGNJAg1dcN2Fpfw=\ngithub.com/hashicorp/golang-lru/arc/v2 v2.0.5/go.mod h1:ny6zBSQZi2JxIeYcv7kt2sH2PXJtirBN7RDhRpxPkxU=\ngithub.com/hashicorp/golang-lru/v2 v2.0.5 h1:wW7h1TG88eUIJ2i69gaE3uNVtEPIagzhGvHgwfx2Vm4=\ngithub.com/hashicorp/golang-lru/v2 v2.0.5/go.mod h1:QeFd9opnmA6QUJc5vARoKUSoFhyfM2/ZepoAG6RGpeM=\ngithub.com/huandu/xstrings v1.5.0 h1:2ag3IFq9ZDANvthTwTiqSSZLjDc+BedvHPAp5tJy2TI=\ngithub.com/huandu/xstrings v1.5.0/go.mod h1:y5/lhBue+AyNmUVz9RLU9xbLR0o4KIIExikq4ovT0aE=\ngithub.com/ianlancetaylor/demangle v0.0.0-20240805132620-81f5be970eca h1:T54Ema1DU8ngI+aef9ZhAhNGQhcRTrWxVeG07F+c/Rw=\ngithub.com/ianlancetaylor/demangle v0.0.0-20240805132620-81f5be970eca/go.mod h1:gx7rwoVhcfuVKG5uya9Hs3Sxj7EIvldVofAWIUtGouw=\ngithub.com/inconshreveable/mousetrap v1.1.0 h1:wN+x4NVGpMsO7ErUn/mUI3vEoE6Jt13X2s0bqwp9tc8=\ngithub.com/inconshreveable/mousetrap v1.1.0/go.mod h1:vpF70FUmC8bwa3OWnCshd2FqLfsEA9PFc4w1p2J65bw=\ngithub.com/jmoiron/sqlx v1.4.0 h1:1PLqN7S1UYp5t4SrVVnt4nUVNemrDAtxlulVe+Qgm3o=\ngithub.com/jmoiron/sqlx v1.4.0/go.mod h1:ZrZ7UsYB/weZdl2Bxg6jCRO9c3YHl8r3ahlKmRT4JLY=\ngithub.com/josharian/intern v1.0.0 h1:vlS4z54oSdjm0bgjRigI+G1HpF+tI+9rE5LLzOg8HmY=\ngithub.com/josharian/intern v1.0.0/go.mod h1:5DoeVV0s6jJacbCEi61lwdGj/aVlrQvzHFFd8Hwg//Y=\ngithub.com/json-iterator/go v1.1.12 h1:PV8peI4a0ysnczrg+LtxykD8LfKY9ML6u2jnxaEnrnM=\ngithub.com/json-iterator/go v1.1.12/go.mod h1:e30LSqwooZae/UwlEbR2852Gd8hjQvJoHmT4TnhNGBo=\ngithub.com/kisielk/errcheck v1.5.0/go.mod h1:pFxgyoBC7bSaBwPgfKdkLd5X25qrDl4LWUI2bnpBCr8=\ngithub.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck=\ngithub.com/klauspost/compress v1.18.0 h1:c/Cqfb0r+Yi+JtIEq73FWXVkRonBlf0CRNYc8Zttxdo=\ngithub.com/klauspost/compress v1.18.0/go.mod h1:2Pp+KzxcywXVXMr50+X0Q/Lsb43OQHYWRCY2AiWywWQ=\ngithub.com/kr/pretty v0.3.1 h1:flRD4NNwYAUpkphVc1HcthR4KEIFJ65n8Mw5qdRn3LE=\ngithub.com/kr/pretty v0.3.1/go.mod h1:hoEshYVHaxMs3cyo3Yncou5ZscifuDolrwPKZanG3xk=\ngithub.com/kr/text v0.2.0 h1:5Nx0Ya0ZqY2ygV366QzturHI13Jq95ApcVaJBhpS+AY=\ngithub.com/kr/text v0.2.0/go.mod h1:eLer722TekiGuMkidMxC/pM04lWEeraHUUmBw8l2grE=\ngithub.com/lann/builder v0.0.0-20180802200727-47ae307949d0 h1:SOEGU9fKiNWd/HOJuq6+3iTQz8KNCLtVX6idSoTLdUw=\ngithub.com/lann/builder v0.0.0-20180802200727-47ae307949d0/go.mod h1:dXGbAdH5GtBTC4WfIxhKZfyBF/HBFgRZSWwZ9g/He9o=\ngithub.com/lann/ps v0.0.0-20150810152359-62de8c46ede0 h1:P6pPBnrTSX3DEVR4fDembhRWSsG5rVo6hYhAB/ADZrk=\ngithub.com/lann/ps v0.0.0-20150810152359-62de8c46ede0/go.mod h1:vmVJ0l/dxyfGW6FmdpVm2joNMFikkuWg0EoCKLGUMNw=\ngithub.com/lib/pq v1.10.9 h1:YXG7RB+JIjhP29X+OtkiDnYaXQwpS4JEWq7dtCCRUEw=\ngithub.com/lib/pq v1.10.9/go.mod h1:AlVN5x4E4T544tWzH6hKfbfQvm3HdbOxrmggDNAPY9o=\ngithub.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de h1:9TO3cAIGXtEhnIaL+V+BEER86oLrvS+kWobKpbJuye0=\ngithub.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de/go.mod h1:zAbeS9B/r2mtpb6U+EI2rYA5OAXxsYw6wTamcNW+zcE=\ngithub.com/mailru/easyjson v0.9.0 h1:PrnmzHw7262yW8sTBwxi1PdJA3Iw/EKBa8psRf7d9a4=\ngithub.com/mailru/easyjson v0.9.0/go.mod h1:1+xMtQp2MRNVL/V1bOzuP3aP8VNwRW55fQUto+XFtTU=\ngithub.com/mattn/go-colorable v0.1.13 h1:fFA4WZxdEF4tXPZVKMLwD8oUnCTTo08duU7wxecdEvA=\ngithub.com/mattn/go-colorable v0.1.13/go.mod h1:7S9/ev0klgBDR4GtXTXX8a3vIGJpMovkB8vQcUbaXHg=\ngithub.com/mattn/go-isatty v0.0.16/go.mod h1:kYGgaQfpe5nmfYZH+SKPsOc2e4SrIfOl2e/yFXSvRLM=\ngithub.com/mattn/go-isatty v0.0.20 h1:xfD0iDuEKnDkl03q4limB+vH+GxLEtL/jb4xVJSWWEY=\ngithub.com/mattn/go-isatty v0.0.20/go.mod h1:W+V8PltTTMOvKvAeJH7IuucS94S2C6jfK/D7dTCTo3Y=\ngithub.com/mattn/go-runewidth v0.0.9 h1:Lm995f3rfxdpd6TSmuVCHVb/QhupuXlYr8sCI/QdE+0=\ngithub.com/mattn/go-runewidth v0.0.9/go.mod h1:H031xJmbD/WCDINGzjvQ9THkh0rPKHF+m2gUSrubnMI=\ngithub.com/mattn/go-sqlite3 v1.14.22 h1:2gZY6PC6kBnID23Tichd1K+Z0oS6nE/XwU+Vz/5o4kU=\ngithub.com/mattn/go-sqlite3 v1.14.22/go.mod h1:Uh1q+B4BYcTPb+yiD3kU8Ct7aC0hY9fxUwlHK0RXw+Y=\ngithub.com/miekg/dns v1.1.57 h1:Jzi7ApEIzwEPLHWRcafCN9LZSBbqQpxjt/wpgvg7wcM=\ngithub.com/miekg/dns v1.1.57/go.mod h1:uqRjCRUuEAA6qsOiJvDd+CFo/vW+y5WR6SNmHE55hZk=\ngithub.com/mitchellh/copystructure v1.2.0 h1:vpKXTN4ewci03Vljg/q9QvCGUDttBOGBIa15WveJJGw=\ngithub.com/mitchellh/copystructure v1.2.0/go.mod h1:qLl+cE2AmVv+CoeAwDPye/v+N2HKCj9FbZEVFJRxO9s=\ngithub.com/mitchellh/go-wordwrap v1.0.1 h1:TLuKupo69TCn6TQSyGxwI1EblZZEsQ0vMlAFQflz0v0=\ngithub.com/mitchellh/go-wordwrap v1.0.1/go.mod h1:R62XHJLzvMFRBbcrT7m7WgmE1eOyTSsCt+hzestvNj0=\ngithub.com/mitchellh/reflectwalk v1.0.2 h1:G2LzWKi524PWgd3mLHV8Y5k7s6XUvT0Gef6zxSIeXaQ=\ngithub.com/mitchellh/reflectwalk v1.0.2/go.mod h1:mSTlrgnPZtwu0c4WaC2kGObEpuNDbx0jmZXqmk4esnw=\ngithub.com/moby/spdystream v0.5.1 h1:9sNYeYZUcci9R6/w7KDaFWEWeV4LStVG78Mpyq/Zm/Y=\ngithub.com/moby/spdystream v0.5.1/go.mod h1:xBAYlnt/ay+11ShkdFKNAG7LsyK/tmNBVvVOwrfMgdI=\ngithub.com/moby/term v0.5.2 h1:6qk3FJAFDs6i/q3W/pQ97SX192qKfZgGjCQqfCJkgzQ=\ngithub.com/moby/term v0.5.2/go.mod h1:d3djjFCrjnB+fl8NJux+EJzu0msscUP+f8it8hPkFLc=\ngithub.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=\ngithub.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd h1:TRLaZ9cD/w8PVh93nsPXa1VrQ6jlwL5oN8l14QlcNfg=\ngithub.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=\ngithub.com/modern-go/reflect2 v1.0.2/go.mod h1:yWuevngMOJpCy52FWWMvUC8ws7m/LJsjYzDa0/r8luk=\ngithub.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee h1:W5t00kpgFdJifH4BDsTlE89Zl93FEloxaWZfGcifgq8=\ngithub.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee/go.mod h1:yWuevngMOJpCy52FWWMvUC8ws7m/LJsjYzDa0/r8luk=\ngithub.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00 h1:n6/2gBQ3RWajuToeY6ZtZTIKv2v7ThUy5KKusIT0yc0=\ngithub.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00/go.mod h1:Pm3mSP3c5uWn86xMLZ5Sa7JB9GsEZySvHYXCTK4E9q4=\ngithub.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 h1:C3w9PqII01/Oq1c1nUAm88MOHcQC9l5mIlSMApZMrHA=\ngithub.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ=\ngithub.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f h1:y5//uYreIhSUg3J1GEMiLbxo1LJaP8RfCpH6pymGZus=\ngithub.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f/go.mod h1:ZdcZmHo+o7JKHSa8/e818NopupXU1YMK5fe1lsApnBw=\ngithub.com/onsi/ginkgo/v2 v2.23.4 h1:ktYTpKJAVZnDT4VjxSbiBenUjmlL/5QkBEocaWXiQus=\ngithub.com/onsi/ginkgo/v2 v2.23.4/go.mod h1:Bt66ApGPBFzHyR+JO10Zbt0Gsp4uWxu5mIOTusL46e8=\ngithub.com/onsi/gomega v1.37.0 h1:CdEG8g0S133B4OswTDC/5XPSzE1OeP29QOioj2PID2Y=\ngithub.com/onsi/gomega v1.37.0/go.mod h1:8D9+Txp43QWKhM24yyOBEdpkzN8FvJyAwecBgsU4KU0=\ngithub.com/opencontainers/go-digest v1.0.0 h1:apOUWs51W5PlhuyGyz9FCeeBIOUDA/6nW8Oi/yOhh5U=\ngithub.com/opencontainers/go-digest v1.0.0/go.mod h1:0JzlMkj0TRzQZfJkVvzbP0HBR3IKzErnv2BNG4W4MAM=\ngithub.com/opencontainers/image-spec v1.1.1 h1:y0fUlFfIZhPF1W537XOLg0/fcx6zcHCJwooC2xJA040=\ngithub.com/opencontainers/image-spec v1.1.1/go.mod h1:qpqAh3Dmcf36wStyyWU+kCeDgrGnAve2nCC8+7h8Q0M=\ngithub.com/peterbourgon/diskv v2.0.1+incompatible h1:UBdAOUP5p4RWqPBg048CAvpKN+vxiaj6gdUUzhl4XmI=\ngithub.com/peterbourgon/diskv v2.0.1+incompatible/go.mod h1:uqqh8zWWbv1HBMNONnaR/tNboyR3/BZd58JJSHlUSCU=\ngithub.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=\ngithub.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=\ngithub.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=\ngithub.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 h1:Jamvg5psRIccs7FGNTlIRMkT8wgtp5eCXdBlqhYGL6U=\ngithub.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=\ngithub.com/poy/onpar v1.1.2 h1:QaNrNiZx0+Nar5dLgTVp5mXkyoVFIbepjyEoGSnhbAY=\ngithub.com/poy/onpar v1.1.2/go.mod h1:6X8FLNoxyr9kkmnlqpK6LSoiOtrO6MICtWwEuWkLjzg=\ngithub.com/prometheus/client_golang v1.22.0 h1:rb93p9lokFEsctTys46VnV1kLCDpVZ0a/Y92Vm0Zc6Q=\ngithub.com/prometheus/client_golang v1.22.0/go.mod h1:R7ljNsLXhuQXYZYtw6GAE9AZg8Y7vEW5scdCXrWRXC0=\ngithub.com/prometheus/client_model v0.6.2 h1:oBsgwpGs7iVziMvrGhE53c/GrLUsZdHnqNwqPLxwZyk=\ngithub.com/prometheus/client_model v0.6.2/go.mod h1:y3m2F6Gdpfy6Ut/GBsUqTWZqCUvMVzSfMLjcu6wAwpE=\ngithub.com/prometheus/common v0.65.0 h1:QDwzd+G1twt//Kwj/Ww6E9FQq1iVMmODnILtW1t2VzE=\ngithub.com/prometheus/common v0.65.0/go.mod h1:0gZns+BLRQ3V6NdaerOhMbwwRbNh9hkGINtQAsP5GS8=\ngithub.com/prometheus/procfs v0.17.0 h1:FuLQ+05u4ZI+SS/w9+BWEM2TXiHKsUQ9TADiRH7DuK0=\ngithub.com/prometheus/procfs v0.17.0/go.mod h1:oPQLaDAMRbA+u8H5Pbfq+dl3VDAvHxMUOVhe0wYB2zw=\ngithub.com/redis/go-redis/extra/rediscmd/v9 v9.0.5 h1:EaDatTxkdHG+U3Bk4EUr+DZ7fOGwTfezUiUJMaIcaho=\ngithub.com/redis/go-redis/extra/rediscmd/v9 v9.0.5/go.mod h1:fyalQWdtzDBECAQFBJuQe5bzQ02jGd5Qcbgb97Flm7U=\ngithub.com/redis/go-redis/extra/redisotel/v9 v9.0.5 h1:EfpWLLCyXw8PSM2/XNJLjI3Pb27yVE+gIAfeqp8LUCc=\ngithub.com/redis/go-redis/extra/redisotel/v9 v9.0.5/go.mod h1:WZjPDy7VNzn77AAfnAfVjZNvfJTYfPetfZk5yoSTLaQ=\ngithub.com/redis/go-redis/v9 v9.7.3 h1:YpPyAayJV+XErNsatSElgRZZVCwXX9QzkKYNvO7x0wM=\ngithub.com/redis/go-redis/v9 v9.7.3/go.mod h1:bGUrSggJ9X9GUmZpZNEOQKaANxSGgOEBRltRTZHSvrA=\ngithub.com/rogpeppe/go-internal v1.13.1 h1:KvO1DLK/DRN07sQ1LQKScxyZJuNnedQ5/wKSR38lUII=\ngithub.com/rogpeppe/go-internal v1.13.1/go.mod h1:uMEvuHeurkdAXX61udpOXGD/AzZDWNMNyH2VO9fmH0o=\ngithub.com/rubenv/sql-migrate v1.8.0 h1:dXnYiJk9k3wetp7GfQbKJcPHjVJL6YK19tKj8t2Ns0o=\ngithub.com/rubenv/sql-migrate v1.8.0/go.mod h1:F2bGFBwCU+pnmbtNYDeKvSuvL6lBVtXDXUUv5t+u1qw=\ngithub.com/russross/blackfriday/v2 v2.1.0 h1:JIOH55/0cWyOuilr9/qlrm0BSXldqnqwMsf35Ld67mk=\ngithub.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM=\ngithub.com/santhosh-tekuri/jsonschema/v6 v6.0.2 h1:KRzFb2m7YtdldCEkzs6KqmJw4nqEVZGK7IN2kJkjTuQ=\ngithub.com/santhosh-tekuri/jsonschema/v6 v6.0.2/go.mod h1:JXeL+ps8p7/KNMjDQk3TCwPpBy0wYklyWTfbkIzdIFU=\ngithub.com/sergi/go-diff v1.2.0 h1:XU+rvMAioB0UC3q1MFrIQy4Vo5/4VsRDQQXHsEya6xQ=\ngithub.com/sergi/go-diff v1.2.0/go.mod h1:STckp+ISIX8hZLjrqAeVduY0gWCT9IjLuqbuNXdaHfM=\ngithub.com/shopspring/decimal v1.4.0 h1:bxl37RwXBklmTi0C79JfXCEBD1cqqHt0bbgBAGFp81k=\ngithub.com/shopspring/decimal v1.4.0/go.mod h1:gawqmDU56v4yIKSwfBSFip1HdCCXN8/+DMd9qYNcwME=\ngithub.com/sirupsen/logrus v1.9.3 h1:dueUQJ1C2q9oE3F7wvmSGAaVtTmUizReu6fjN8uqzbQ=\ngithub.com/sirupsen/logrus v1.9.3/go.mod h1:naHLuLoDiP4jHNo9R0sCBMtWGeIprob74mVsIT4qYEQ=\ngithub.com/spf13/cast v1.7.0 h1:ntdiHjuueXFgm5nzDRdOS4yfT43P5Fnud6DH50rz/7w=\ngithub.com/spf13/cast v1.7.0/go.mod h1:ancEpBxwJDODSW/UG4rDrAqiKolqNNh2DX3mk86cAdo=\ngithub.com/spf13/cobra v1.10.1 h1:lJeBwCfmrnXthfAupyUTzJ/J4Nc1RsHC/mSRU2dll/s=\ngithub.com/spf13/cobra v1.10.1/go.mod h1:7SmJGaTHFVBY0jW4NXGluQoLvhqFQM+6XSKD+P4XaB0=\ngithub.com/spf13/pflag v1.0.9/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=\ngithub.com/spf13/pflag v1.0.10 h1:4EBh2KAYBwaONj6b2Ye1GiHfwjqyROoF4RwYO+vPwFk=\ngithub.com/spf13/pflag v1.0.10/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=\ngithub.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=\ngithub.com/stretchr/objx v0.5.2 h1:xuMeJ0Sdp5ZMRXx/aWO6RZxdr3beISkG5/G/aIRr3pY=\ngithub.com/stretchr/objx v0.5.2/go.mod h1:FRsXN1f5AsAjCGJKqEizvkpNtU+EGNCLh3NxZ/8L+MA=\ngithub.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=\ngithub.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI=\ngithub.com/stretchr/testify v1.6.1/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=\ngithub.com/stretchr/testify v1.7.0/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=\ngithub.com/stretchr/testify v1.11.1 h1:7s2iGBzp5EwR7/aIZr8ao5+dra3wiQyKjjFuvgVKu7U=\ngithub.com/stretchr/testify v1.11.1/go.mod h1:wZwfW3scLgRK+23gO65QZefKpKQRnfz6sD981Nm4B6U=\ngithub.com/tetratelabs/wabin v0.0.0-20230304001439-f6f874872834 h1:ZF+QBjOI+tILZjBaFj3HgFonKXUcwgJ4djLb6i42S3Q=\ngithub.com/tetratelabs/wabin v0.0.0-20230304001439-f6f874872834/go.mod h1:m9ymHTgNSEjuxvw8E7WWe4Pl4hZQHXONY8wE6dMLaRk=\ngithub.com/tetratelabs/wazero v1.9.0 h1:IcZ56OuxrtaEz8UYNRHBrUa9bYeX9oVY93KspZZBf/I=\ngithub.com/tetratelabs/wazero v1.9.0/go.mod h1:TSbcXCfFP0L2FGkRPxHphadXPjo1T6W+CseNNY7EkjM=\ngithub.com/x448/float16 v0.8.4 h1:qLwI1I70+NjRFUR3zs1JPUCgaCXSh3SW62uAKT1mSBM=\ngithub.com/x448/float16 v0.8.4/go.mod h1:14CWIYCyZA/cWjXOioeEpHeN/83MdbZDRQHoFcYsOfg=\ngithub.com/xlab/treeprint v1.2.0 h1:HzHnuAF1plUN2zGlAFHbSQP2qJ0ZAD3XF5XD7OesXRQ=\ngithub.com/xlab/treeprint v1.2.0/go.mod h1:gj5Gd3gPdKtR1ikdDK6fnFLdmIS0X30kTTuNd/WEJu0=\ngithub.com/yuin/goldmark v1.1.27/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=\ngithub.com/yuin/goldmark v1.2.1/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=\ngo.opentelemetry.io/auto/sdk v1.1.0 h1:cH53jehLUN6UFLY71z+NDOiNJqDdPRaXzTel0sJySYA=\ngo.opentelemetry.io/auto/sdk v1.1.0/go.mod h1:3wSPjt5PWp2RhlCcmmOial7AvC4DQqZb7a7wCow3W8A=\ngo.opentelemetry.io/contrib/bridges/prometheus v0.57.0 h1:UW0+QyeyBVhn+COBec3nGhfnFe5lwB0ic1JBVjzhk0w=\ngo.opentelemetry.io/contrib/bridges/prometheus v0.57.0/go.mod h1:ppciCHRLsyCio54qbzQv0E4Jyth/fLWDTJYfvWpcSVk=\ngo.opentelemetry.io/contrib/exporters/autoexport v0.57.0 h1:jmTVJ86dP60C01K3slFQa2NQ/Aoi7zA+wy7vMOKD9H4=\ngo.opentelemetry.io/contrib/exporters/autoexport v0.57.0/go.mod h1:EJBheUMttD/lABFyLXhce47Wr6DPWYReCzaZiXadH7g=\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.58.0 h1:yd02MEjBdJkG3uabWP9apV+OuWRIXGDuJEUJbOHmCFU=\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.58.0/go.mod h1:umTcuxiv1n/s/S6/c2AT/g2CQ7u5C59sHDNmfSwgz7Q=\ngo.opentelemetry.io/otel v1.37.0 h1:9zhNfelUvx0KBfu/gb+ZgeAfAgtWrfHJZcAqFC228wQ=\ngo.opentelemetry.io/otel v1.37.0/go.mod h1:ehE/umFRLnuLa/vSccNq9oS1ErUlkkK71gMcN34UG8I=\ngo.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc v0.8.0 h1:WzNab7hOOLzdDF/EoWCt4glhrbMPVMOO5JYTmpz36Ls=\ngo.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc v0.8.0/go.mod h1:hKvJwTzJdp90Vh7p6q/9PAOd55dI6WA6sWj62a/JvSs=\ngo.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp v0.8.0 h1:S+LdBGiQXtJdowoJoQPEtI52syEP/JYBUpjO49EQhV8=\ngo.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp v0.8.0/go.mod h1:5KXybFvPGds3QinJWQT7pmXf+TN5YIa7CNYObWRkj50=\ngo.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.32.0 h1:j7ZSD+5yn+lo3sGV69nW04rRR0jhYnBwjuX3r0HvnK0=\ngo.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.32.0/go.mod h1:WXbYJTUaZXAbYd8lbgGuvih0yuCfOFC5RJoYnoLcGz8=\ngo.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp v1.32.0 h1:t/Qur3vKSkUCcDVaSumWF2PKHt85pc7fRvFuoVT8qFU=\ngo.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp v1.32.0/go.mod h1:Rl61tySSdcOJWoEgYZVtmnKdA0GeKrSqkHC1t+91CH8=\ngo.opentelemetry.io/otel/exporters/otlp/otlptrace v1.34.0 h1:OeNbIYk/2C15ckl7glBlOBp5+WlYsOElzTNmiPW/x60=\ngo.opentelemetry.io/otel/exporters/otlp/otlptrace v1.34.0/go.mod h1:7Bept48yIeqxP2OZ9/AqIpYS94h2or0aB4FypJTc8ZM=\ngo.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.34.0 h1:tgJ0uaNS4c98WRNUEx5U3aDlrDOI5Rs+1Vifcw4DJ8U=\ngo.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.34.0/go.mod h1:U7HYyW0zt/a9x5J1Kjs+r1f/d4ZHnYFclhYY2+YbeoE=\ngo.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.32.0 h1:cMyu9O88joYEaI47CnQkxO1XZdpoTF9fEnW2duIddhw=\ngo.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.32.0/go.mod h1:6Am3rn7P9TVVeXYG+wtcGE7IE1tsQ+bP3AuWcKt/gOI=\ngo.opentelemetry.io/otel/exporters/prometheus v0.54.0 h1:rFwzp68QMgtzu9PgP3jm9XaMICI6TsofWWPcBDKwlsU=\ngo.opentelemetry.io/otel/exporters/prometheus v0.54.0/go.mod h1:QyjcV9qDP6VeK5qPyKETvNjmaaEc7+gqjh4SS0ZYzDU=\ngo.opentelemetry.io/otel/exporters/stdout/stdoutlog v0.8.0 h1:CHXNXwfKWfzS65yrlB2PVds1IBZcdsX8Vepy9of0iRU=\ngo.opentelemetry.io/otel/exporters/stdout/stdoutlog v0.8.0/go.mod h1:zKU4zUgKiaRxrdovSS2amdM5gOc59slmo/zJwGX+YBg=\ngo.opentelemetry.io/otel/exporters/stdout/stdoutmetric v1.32.0 h1:SZmDnHcgp3zwlPBS2JX2urGYe/jBKEIT6ZedHRUyCz8=\ngo.opentelemetry.io/otel/exporters/stdout/stdoutmetric v1.32.0/go.mod h1:fdWW0HtZJ7+jNpTKUR0GpMEDP69nR8YBJQxNiVCE3jk=\ngo.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.32.0 h1:cC2yDI3IQd0Udsux7Qmq8ToKAx1XCilTQECZ0KDZyTw=\ngo.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.32.0/go.mod h1:2PD5Ex6z8CFzDbTdOlwyNIUywRr1DN0ospafJM1wJ+s=\ngo.opentelemetry.io/otel/log v0.8.0 h1:egZ8vV5atrUWUbnSsHn6vB8R21G2wrKqNiDt3iWertk=\ngo.opentelemetry.io/otel/log v0.8.0/go.mod h1:M9qvDdUTRCopJcGRKg57+JSQ9LgLBrwwfC32epk5NX8=\ngo.opentelemetry.io/otel/metric v1.37.0 h1:mvwbQS5m0tbmqML4NqK+e3aDiO02vsf/WgbsdpcPoZE=\ngo.opentelemetry.io/otel/metric v1.37.0/go.mod h1:04wGrZurHYKOc+RKeye86GwKiTb9FKm1WHtO+4EVr2E=\ngo.opentelemetry.io/otel/sdk v1.34.0 h1:95zS4k/2GOy069d321O8jWgYsW3MzVV+KuSPKp7Wr1A=\ngo.opentelemetry.io/otel/sdk v1.34.0/go.mod h1:0e/pNiaMAqaykJGKbi+tSjWfNNHMTxoC9qANsCzbyxU=\ngo.opentelemetry.io/otel/sdk/log v0.8.0 h1:zg7GUYXqxk1jnGF/dTdLPrK06xJdrXgqgFLnI4Crxvs=\ngo.opentelemetry.io/otel/sdk/log v0.8.0/go.mod h1:50iXr0UVwQrYS45KbruFrEt4LvAdCaWWgIrsN3ZQggo=\ngo.opentelemetry.io/otel/sdk/metric v1.34.0 h1:5CeK9ujjbFVL5c1PhLuStg1wxA7vQv7ce1EK0Gyvahk=\ngo.opentelemetry.io/otel/sdk/metric v1.34.0/go.mod h1:jQ/r8Ze28zRKoNRdkjCZxfs6YvBTG1+YIqyFVFYec5w=\ngo.opentelemetry.io/otel/trace v1.37.0 h1:HLdcFNbRQBE2imdSEgm/kwqmQj1Or1l/7bW6mxVK7z4=\ngo.opentelemetry.io/otel/trace v1.37.0/go.mod h1:TlgrlQ+PtQO5XFerSPUYG0JSgGyryXewPGyayAWSBS0=\ngo.opentelemetry.io/proto/otlp v1.5.0 h1:xJvq7gMzB31/d406fB8U5CBdyQGw4P399D1aQWU/3i4=\ngo.opentelemetry.io/proto/otlp v1.5.0/go.mod h1:keN8WnHxOy8PG0rQZjJJ5A2ebUoafqWp0eVQ4yIXvJ4=\ngo.uber.org/automaxprocs v1.6.0 h1:O3y2/QNTOdbF+e/dpXNNW7Rx2hZ4sTIPyybbxyNqTUs=\ngo.uber.org/automaxprocs v1.6.0/go.mod h1:ifeIMSnPZuznNm6jmdzmU3/bfk01Fe2fotchwEFJ8r8=\ngo.uber.org/goleak v1.3.0 h1:2K3zAYmnTNqV73imy9J1T3WC+gmCePx2hEGkimedGto=\ngo.uber.org/goleak v1.3.0/go.mod h1:CoHD4mav9JJNrW/WLlf7HGZPjdw8EucARQHekz1X6bE=\ngo.uber.org/multierr v1.11.0 h1:blXXJkSxSSfBVBlC76pxqeO+LN3aDfLQo+309xJstO0=\ngo.uber.org/multierr v1.11.0/go.mod h1:20+QtiLqy0Nd6FdQB9TLXag12DsQkrbs3htMFfDN80Y=\ngo.uber.org/zap v1.27.0 h1:aJMhYGrd5QSmlpLMr2MftRKl7t8J8PTZPA732ud/XR8=\ngo.uber.org/zap v1.27.0/go.mod h1:GB2qFLM7cTU87MWRP2mPIjqfIDnGu+VIO4V/SdhGo2E=\ngo.yaml.in/yaml/v2 v2.4.2 h1:DzmwEr2rDGHl7lsFgAHxmNz/1NlQ7xLIrlN2h5d1eGI=\ngo.yaml.in/yaml/v2 v2.4.2/go.mod h1:081UH+NErpNdqlCXm3TtEran0rJZGxAYx9hb/ELlsPU=\ngo.yaml.in/yaml/v3 v3.0.4 h1:tfq32ie2Jv2UxXFdLJdh3jXuOzWiL1fo0bu/FbuKpbc=\ngo.yaml.in/yaml/v3 v3.0.4/go.mod h1:DhzuOOF2ATzADvBadXxruRBLzYTpT36CKvDb3+aBEFg=\ngolang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=\ngolang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=\ngolang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=\ngolang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q=\ngolang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4=\ngolang.org/x/mod v0.2.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=\ngolang.org/x/mod v0.3.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=\ngolang.org/x/mod v0.29.0 h1:HV8lRxZC4l2cr3Zq1LvtOsi/ThTgWnUk/y64QSs8GwA=\ngolang.org/x/mod v0.29.0/go.mod h1:NyhrlYXJ2H4eJiRy/WDBO6HMqZQ6q9nk4JzS3NuCK+w=\ngolang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=\ngolang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=\ngolang.org/x/net v0.0.0-20200226121028-0de0cce0169b/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=\ngolang.org/x/net v0.0.0-20201021035429-f5854403a974/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=\ngolang.org/x/net v0.47.0 h1:Mx+4dIFzqraBXUugkia1OOvlD6LemFo1ALMHjrXDOhY=\ngolang.org/x/net v0.47.0/go.mod h1:/jNxtkgq5yWUGYkaZGqo27cfGZ1c5Nen03aYrrKpVRU=\ngolang.org/x/oauth2 v0.30.0 h1:dnDm7JmhM45NNpd8FDDeLhK6FwqbOf4MLCM9zb1BOHI=\ngolang.org/x/oauth2 v0.30.0/go.mod h1:B++QgG3ZKulg6sRPGD/mqlHQs5rB3Ml9erfeDY7xKlU=\ngolang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=\ngolang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=\ngolang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=\ngolang.org/x/sync v0.18.0 h1:kr88TuHDroi+UVf+0hZnirlk8o8T+4MrK6mr60WkH/I=\ngolang.org/x/sync v0.18.0/go.mod h1:9KTHXmSnoGruLpwFjVSX0lNNA75CykiMECbovNTZqGI=\ngolang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=\ngolang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=\ngolang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=\ngolang.org/x/sys v0.0.0-20210616094352-59db8d763f22/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=\ngolang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=\ngolang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=\ngolang.org/x/sys v0.38.0 h1:3yZWxaJjBmCWXqhN1qh02AkOnCQ1poK6oF+a7xWL6Gc=\ngolang.org/x/sys v0.38.0/go.mod h1:OgkHotnGiDImocRcuBABYBEXf8A9a87e/uXjp9XT3ks=\ngolang.org/x/term v0.37.0 h1:8EGAD0qCmHYZg6J17DvsMy9/wJ7/D/4pV/wfnld5lTU=\ngolang.org/x/term v0.37.0/go.mod h1:5pB4lxRNYYVZuTLmy8oR2BH8dflOR+IbTYFD8fi3254=\ngolang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=\ngolang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=\ngolang.org/x/text v0.31.0 h1:aC8ghyu4JhP8VojJ2lEHBnochRno1sgL6nEi9WGFGMM=\ngolang.org/x/text v0.31.0/go.mod h1:tKRAlv61yKIjGGHX/4tP1LTbc13YSec1pxVEWXzfoeM=\ngolang.org/x/time v0.12.0 h1:ScB/8o8olJvc+CQPWrK3fPZNfh7qgwCrY0zJmoEQLSE=\ngolang.org/x/time v0.12.0/go.mod h1:CDIdPxbZBQxdj6cxyCIdrNogrJKMJ7pr37NYpMcMDSg=\ngolang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=\ngolang.org/x/tools v0.0.0-20191119224855-298f0cb1881e/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=\ngolang.org/x/tools v0.0.0-20200619180055-7c47624df98f/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE=\ngolang.org/x/tools v0.0.0-20210106214847-113979e3529a/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA=\ngolang.org/x/tools v0.38.0 h1:Hx2Xv8hISq8Lm16jvBZ2VQf+RLmbd7wVUsALibYI/IQ=\ngolang.org/x/tools v0.38.0/go.mod h1:yEsQ/d/YK8cjh0L6rZlY8tgtlKiBNTL14pGDJPJpYQs=\ngolang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=\ngolang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=\ngolang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=\ngolang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=\ngoogle.golang.org/genproto/googleapis/api v0.0.0-20250303144028-a0af3efb3deb h1:p31xT4yrYrSM/G4Sn2+TNUkVhFCbG9y8itM2S6Th950=\ngoogle.golang.org/genproto/googleapis/api v0.0.0-20250303144028-a0af3efb3deb/go.mod h1:jbe3Bkdp+Dh2IrslsFCklNhweNTBgSYanP1UXhJDhKg=\ngoogle.golang.org/genproto/googleapis/rpc v0.0.0-20250303144028-a0af3efb3deb h1:TLPQVbx1GJ8VKZxz52VAxl1EBgKXXbTiU9Fc5fZeLn4=\ngoogle.golang.org/genproto/googleapis/rpc v0.0.0-20250303144028-a0af3efb3deb/go.mod h1:LuRYeWDFV6WOn90g357N17oMCaxpgCnbi/44qJvDn2I=\ngoogle.golang.org/grpc v1.72.1 h1:HR03wO6eyZ7lknl75XlxABNVLLFc2PAb6mHlYh756mA=\ngoogle.golang.org/grpc v1.72.1/go.mod h1:wH5Aktxcg25y1I3w7H69nHfXdOG3UiadoBtjh3izSDM=\ngoogle.golang.org/protobuf v1.36.6 h1:z1NpPI8ku2WgiWnf+t9wTPsn6eP1L7ksHUlkfLvd9xY=\ngoogle.golang.org/protobuf v1.36.6/go.mod h1:jduwjTPXsFjZGTmRluh+L6NjiWu7pchiJ2/5YcXBHnY=\ngopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=\ngopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c h1:Hei/4ADfdWqJk1ZMxUNpqntNwaWcugrBjAiHlqqRiVk=\ngopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c/go.mod h1:JHkPIbrfpd72SG/EVd6muEfDQjcINNoR0C8j2r3qZ4Q=\ngopkg.in/evanphx/json-patch.v4 v4.12.0 h1:n6jtcsulIzXPJaxegRbvFNNrZDjbij7ny3gmSPG+6V4=\ngopkg.in/evanphx/json-patch.v4 v4.12.0/go.mod h1:p8EYWUEYMpynmqDbY58zCKCFZw8pRWMG4EsWvDvM72M=\ngopkg.in/inf.v0 v0.9.1 h1:73M5CoZyi3ZLMOyDlQh031Cx6N9NDJ2Vvfl76EDAgDc=\ngopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw=\ngopkg.in/yaml.v2 v2.4.0 h1:D8xgwECY7CYvx+Y2n4sBz93Jn9JRvxdiyyo8CTfuKaY=\ngopkg.in/yaml.v2 v2.4.0/go.mod h1:RDklbk79AGWmwhnvt/jBztapEOGDOx6ZbXqjP6csGnQ=\ngopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=\ngopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA=\ngopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=\nhelm.sh/helm/v4 v4.0.0 h1:Ppai7cygdmyxSR+JR9djUoVrRmyMI/yY5P5TBd25oHs=\nhelm.sh/helm/v4 v4.0.0/go.mod h1:G1Y5AE+lJPQSAjh7nbXnhZrtGtxo+I6POSu9DruYiGI=\nk8s.io/api v0.34.1 h1:jC+153630BMdlFukegoEL8E/yT7aLyQkIVuwhmwDgJM=\nk8s.io/api v0.34.1/go.mod h1:SB80FxFtXn5/gwzCoN6QCtPD7Vbu5w2n1S0J5gFfTYk=\nk8s.io/apiextensions-apiserver v0.34.1 h1:NNPBva8FNAPt1iSVwIE0FsdrVriRXMsaWFMqJbII2CI=\nk8s.io/apiextensions-apiserver v0.34.1/go.mod h1:hP9Rld3zF5Ay2Of3BeEpLAToP+l4s5UlxiHfqRaRcMc=\nk8s.io/apimachinery v0.34.1 h1:dTlxFls/eikpJxmAC7MVE8oOeP1zryV7iRyIjB0gky4=\nk8s.io/apimachinery v0.34.1/go.mod h1:/GwIlEcWuTX9zKIg2mbw0LRFIsXwrfoVxn+ef0X13lw=\nk8s.io/apiserver v0.34.1 h1:U3JBGdgANK3dfFcyknWde1G6X1F4bg7PXuvlqt8lITA=\nk8s.io/apiserver v0.34.1/go.mod h1:eOOc9nrVqlBI1AFCvVzsob0OxtPZUCPiUJL45JOTBG0=\nk8s.io/cli-runtime v0.34.1 h1:btlgAgTrYd4sk8vJTRG6zVtqBKt9ZMDeQZo2PIzbL7M=\nk8s.io/cli-runtime v0.34.1/go.mod h1:aVA65c+f0MZiMUPbseU/M9l1Wo2byeaGwUuQEQVVveE=\nk8s.io/client-go v0.34.1 h1:ZUPJKgXsnKwVwmKKdPfw4tB58+7/Ik3CrjOEhsiZ7mY=\nk8s.io/client-go v0.34.1/go.mod h1:kA8v0FP+tk6sZA0yKLRG67LWjqufAoSHA2xVGKw9Of8=\nk8s.io/component-base v0.34.1 h1:v7xFgG+ONhytZNFpIz5/kecwD+sUhVE6HU7qQUiRM4A=\nk8s.io/component-base v0.34.1/go.mod h1:mknCpLlTSKHzAQJJnnHVKqjxR7gBeHRv0rPXA7gdtQ0=\nk8s.io/klog/v2 v2.130.1 h1:n9Xl7H1Xvksem4KFG4PYbdQCQxqc/tTUyrgXaOhHSzk=\nk8s.io/klog/v2 v2.130.1/go.mod h1:3Jpz1GvMt720eyJH1ckRHK1EDfpxISzJ7I9OYgaDtPE=\nk8s.io/kube-openapi v0.0.0-20250710124328-f3f2b991d03b h1:MloQ9/bdJyIu9lb1PzujOPolHyvO06MXG5TUIj2mNAA=\nk8s.io/kube-openapi v0.0.0-20250710124328-f3f2b991d03b/go.mod h1:UZ2yyWbFTpuhSbFhv24aGNOdoRdJZgsIObGBUaYVsts=\nk8s.io/kubectl v0.34.1 h1:1qP1oqT5Xc93K+H8J7ecpBjaz511gan89KO9Vbsh/OI=\nk8s.io/kubectl v0.34.1/go.mod h1:JRYlhJpGPyk3dEmJ+BuBiOB9/dAvnrALJEiY/C5qa6A=\nk8s.io/utils v0.0.0-20250604170112-4c0f3b243397 h1:hwvWFiBzdWw1FhfY1FooPn3kzWuJ8tmbZBHi4zVsl1Y=\nk8s.io/utils v0.0.0-20250604170112-4c0f3b243397/go.mod h1:OLgZIPagt7ERELqWJFomSt595RzquPNLL48iOWgYOg0=\noras.land/oras-go/v2 v2.6.0 h1:X4ELRsiGkrbeox69+9tzTu492FMUu7zJQW6eJU+I2oc=\noras.land/oras-go/v2 v2.6.0/go.mod h1:magiQDfG6H1O9APp+rOsvCPcW1GD2MM7vgnKY0Y+u1o=\nsigs.k8s.io/controller-runtime v0.22.3 h1:I7mfqz/a/WdmDCEnXmSPm8/b/yRTy6JsKKENTijTq8Y=\nsigs.k8s.io/controller-runtime v0.22.3/go.mod h1:+QX1XUpTXN4mLoblf4tqr5CQcyHPAki2HLXqQMY6vh8=\nsigs.k8s.io/json v0.0.0-20241014173422-cfa47c3a1cc8 h1:gBQPwqORJ8d8/YNZWEjoZs7npUVDpVXUUOFfW6CgAqE=\nsigs.k8s.io/json v0.0.0-20241014173422-cfa47c3a1cc8/go.mod h1:mdzfpAEoE6DHQEN0uh9ZbOCuHbLK5wOm7dK4ctXE9Tg=\nsigs.k8s.io/kustomize/api v0.20.1 h1:iWP1Ydh3/lmldBnH/S5RXgT98vWYMaTUL1ADcr+Sv7I=\nsigs.k8s.io/kustomize/api v0.20.1/go.mod h1:t6hUFxO+Ph0VxIk1sKp1WS0dOjbPCtLJ4p8aADLwqjM=\nsigs.k8s.io/kustomize/kyaml v0.20.1 h1:PCMnA2mrVbRP3NIB6v9kYCAc38uvFLVs8j/CD567A78=\nsigs.k8s.io/kustomize/kyaml v0.20.1/go.mod h1:0EmkQHRUsJxY8Ug9Niig1pUMSCGHxQ5RklbpV/Ri6po=\nsigs.k8s.io/randfill v1.0.0 h1:JfjMILfT8A6RbawdsK2JXGBR5AQVfd+9TbzrlneTyrU=\nsigs.k8s.io/randfill v1.0.0/go.mod h1:XeLlZ/jmk4i1HRopwe7/aU3H5n1zNUcX6TM94b3QxOY=\nsigs.k8s.io/structured-merge-diff/v6 v6.3.0 h1:jTijUJbW353oVOd9oTlifJqOGEkUw2jB/fXCbTiQEco=\nsigs.k8s.io/structured-merge-diff/v6 v6.3.0/go.mod h1:M3W8sfWvn2HhQDIbGWj3S099YozAsymCo/wrT5ohRUE=\nsigs.k8s.io/yaml v1.6.0 h1:G8fkbMSAFqgEFgh4b1wmtzDnioxFCUgTZhlbj5P9QYs=\nsigs.k8s.io/yaml v1.6.0/go.mod h1:796bPqUfzR/0jLAl6XjHl3Ck7MiyVv8dbTdyT3/pMf4=\n"
  },
  {
    "path": "sdkexamples/install.go",
    "content": "package main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v4/pkg/action\"\n\t\"helm.sh/helm/v4/pkg/chart\"\n\t\"helm.sh/helm/v4/pkg/chart/loader\"\n\t\"helm.sh/helm/v4/pkg/cli\"\n\t\"helm.sh/helm/v4/pkg/downloader\"\n\t\"helm.sh/helm/v4/pkg/getter\"\n)\n\nfunc runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tinstallClient := action.NewInstall(actionConfig)\n\n\tinstallClient.DryRunStrategy = \"none\"\n\tinstallClient.WaitStrategy = \"watcher\"\n\tinstallClient.ReleaseName = releaseName\n\tinstallClient.Namespace = settings.Namespace()\n\tinstallClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClient(\n\t\tsettings,\n\t\tinstallClient.CertFile,\n\t\tinstallClient.KeyFile,\n\t\tinstallClient.CaFile,\n\t\tinstallClient.InsecureSkipTLSverify,\n\t\tinstallClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tinstallClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\tcharter, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tchartAccessor, err := chart.NewDefaultAccessor(charter)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"error creating chart accessor: %w\", err)\n\t}\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tif chartDependencies := chartAccessor.MetaDependencies(); chartDependencies != nil {\n\t\tif err := action.CheckDependencies(charter, chartDependencies); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !installClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tmanager := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          installClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t\tRegistryClient:   installClient.GetRegistryClient(),\n\t\t\t}\n\t\t\tif err := manager.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif charter, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\t_, err = installClient.RunWithContext(ctx, charter, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run install: %w\", err)\n\t}\n\n\tlogger.Printf(\"release created\")\n\n\treturn nil\n}\n"
  },
  {
    "path": "sdkexamples/list.go",
    "content": "package main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v4/pkg/action\"\n\t\"helm.sh/helm/v4/pkg/cli\"\n)\n\nfunc runList(logger *log.Logger, settings *cli.EnvSettings) error {\n\n\tactionConfig, err := initActionConfigList(settings, logger, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tlistClient := action.NewList(actionConfig)\n\t// Only list deployed\n\t//listClient.Deployed = true\n\tlistClient.All = true\n\tlistClient.SetStateMask()\n\n\tresults, err := listClient.Run()\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run list action: %w\", err)\n\t}\n\n\tfor _, rel := range results {\n\t\tlogger.Printf(\"list result: %+v\", rel)\n\t}\n\n\treturn nil\n}\n"
  },
  {
    "path": "sdkexamples/main.go",
    "content": "package main\n\nimport (\n\t\"bufio\"\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\t\"net/http\"\n\t\"os\"\n\n\t\"helm.sh/helm/v4/pkg/action\"\n\t\"helm.sh/helm/v4/pkg/cli\"\n\t\"helm.sh/helm/v4/pkg/registry\"\n)\n\nvar helmDriver string = os.Getenv(\"HELM_DRIVER\")\n\nfunc initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) {\n\treturn initActionConfigList(settings, logger, false)\n}\n\nfunc initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) {\n\n\tactionConfig := new(action.Configuration)\n\n\tnamespace := func() string {\n\t\t// For list action, you can pass an empty string instead of settings.Namespace() to list\n\t\t// all namespaces\n\t\tif allNamespaces {\n\t\t\treturn \"\"\n\t\t}\n\t\treturn settings.Namespace()\n\t}()\n\n\tif err := actionConfig.Init(\n\t\tsettings.RESTClientGetter(),\n\t\tnamespace,\n\t\thelmDriver); err != nil {\n\t\treturn nil, err\n\t}\n\n\treturn actionConfig, nil\n}\n\nfunc newRegistryClient(settings *cli.EnvSettings, certFile, keyFile, caFile string, insecureSkipTLSVerify, plainHTTP bool) (*registry.Client, error) {\n\n\topts := []registry.ClientOption{\n\t\tregistry.ClientOptDebug(settings.Debug),\n\t\tregistry.ClientOptEnableCache(true),\n\t\tregistry.ClientOptWriter(os.Stderr),\n\t\tregistry.ClientOptCredentialsFile(settings.RegistryConfig),\n\t}\n\n\tif plainHTTP {\n\t\topts = append(opts, registry.ClientOptPlainHTTP())\n\t}\n\n\tif certFile != \"\" && keyFile != \"\" || caFile != \"\" || insecureSkipTLSVerify {\n\t\ttlsConf, err := NewTLSConfig(\n\t\t\tWithInsecureSkipVerify(insecureSkipTLSVerify),\n\t\t\tWithCertKeyPairFiles(certFile, keyFile),\n\t\t\tWithCAFile(caFile),\n\t\t)\n\t\tif err != nil {\n\t\t\treturn nil, fmt.Errorf(\"failed to load client TLS certs: %w\", err)\n\t\t}\n\n\t\topts = append(opts, registry.ClientOptHTTPClient(&http.Client{\n\t\t\tTransport: &http.Transport{\n\t\t\t\tTLSClientConfig: tlsConf,\n\t\t\t\tProxy:           http.ProxyFromEnvironment,\n\t\t\t},\n\t\t}))\n\t}\n\n\t// Create a new registry client\n\tregistryClient, err := registry.NewClient(opts...)\n\tif err != nil {\n\t\treturn nil, fmt.Errorf(\"failed to initialize registry client: %w\", err)\n\t}\n\n\treturn registryClient, nil\n}\n\nfunc main() {\n\n\tlogger := log.Default()\n\n\t// For convenience, initialize SDK setting via CLI mechanism\n\tsettings := cli.New()\n\n\t// Release name, chart and values\n\treleaseName := \"helm-sdk-example\"\n\tchartRef := \"oci://ghcr.io/stefanprodan/charts/podinfo\"\n\treleaseValues := map[string]interface{}{\n\t\t\"replicaCount\": \"2\",\n\t}\n\n\t// Pull the chart to the local filesystem\n\tif err := runPull(logger, settings, chartRef, \"6.4.1\"); err != nil {\n\t\tfmt.Printf(\"failed to run pull: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// Install the chart (from the pulled chart local archive)\n\tif err := runInstall(context.TODO(), logger, settings, releaseName, \"./podinfo-6.4.1.tgz\", \"\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run install: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart installed. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Upgrade to version 6.5.4, updating the replicaCount to three\n\treleaseValues[\"replicaCount\"] = \"3\"\n\tif err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, \"6.5.4\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run upgrade: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart upgraded. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Uninstall the chart\n\tif err := runUninstall(logger, settings, releaseName); err != nil {\n\t\tfmt.Printf(\"failed to run uninstall: %+v\", err)\n\t\tos.Exit(1)\n\t}\n}\n"
  },
  {
    "path": "sdkexamples/pull.go",
    "content": "package main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v4/pkg/action\"\n\t\"helm.sh/helm/v4/pkg/cli\"\n)\n\nfunc runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tpullClient := action.NewPull(action.WithConfig(actionConfig))\n\t// client.RepoURL = \"\"\n\tpullClient.DestDir = \"./\"\n\tpullClient.Settings = settings\n\tpullClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClient(\n\t\tsettings,\n\t\tpullClient.CertFile,\n\t\tpullClient.KeyFile,\n\t\tpullClient.CaFile,\n\t\tpullClient.InsecureSkipTLSverify,\n\t\tpullClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tactionConfig.RegistryClient = registryClient\n\n\tresult, err := pullClient.Run(chartRef)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to pull chart: %w\", err)\n\t}\n\n\tlogger.Printf(\"%+v\", result)\n\n\treturn nil\n}\n"
  },
  {
    "path": "sdkexamples/tlsutil.go",
    "content": "/*\nCopyright The Helm Authors.\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n    http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n*/\n\npackage main\n\nimport (\n\t\"crypto/tls\"\n\t\"crypto/x509\"\n\t\"fmt\"\n\t\"os\"\n\n\t\"errors\"\n)\n\ntype TLSConfigOptions struct {\n\tinsecureSkipTLSverify     bool\n\tcertPEMBlock, keyPEMBlock []byte\n\tcaPEMBlock                []byte\n}\n\ntype TLSConfigOption func(options *TLSConfigOptions) error\n\nfunc WithInsecureSkipVerify(insecureSkipTLSverify bool) TLSConfigOption {\n\treturn func(options *TLSConfigOptions) error {\n\t\toptions.insecureSkipTLSverify = insecureSkipTLSverify\n\n\t\treturn nil\n\t}\n}\n\nfunc WithCertKeyPairFiles(certFile, keyFile string) TLSConfigOption {\n\treturn func(options *TLSConfigOptions) error {\n\t\tif certFile == \"\" && keyFile == \"\" {\n\t\t\treturn nil\n\t\t}\n\n\t\tcertPEMBlock, err := os.ReadFile(certFile)\n\t\tif err != nil {\n\t\t\treturn fmt.Errorf(\"unable to read cert file: %q: %w\", certFile, err)\n\t\t}\n\n\t\tkeyPEMBlock, err := os.ReadFile(keyFile)\n\t\tif err != nil {\n\t\t\treturn fmt.Errorf(\"unable to read key file: %q: %w\", keyFile, err)\n\t\t}\n\n\t\toptions.certPEMBlock = certPEMBlock\n\t\toptions.keyPEMBlock = keyPEMBlock\n\n\t\treturn nil\n\t}\n}\n\nfunc WithCAFile(caFile string) TLSConfigOption {\n\treturn func(options *TLSConfigOptions) error {\n\t\tif caFile == \"\" {\n\t\t\treturn nil\n\t\t}\n\n\t\tcaPEMBlock, err := os.ReadFile(caFile)\n\t\tif err != nil {\n\t\t\treturn fmt.Errorf(\"can't read CA file: %q: %w\", caFile, err)\n\t\t}\n\n\t\toptions.caPEMBlock = caPEMBlock\n\n\t\treturn nil\n\t}\n}\n\nfunc NewTLSConfig(options ...TLSConfigOption) (*tls.Config, error) {\n\tto := TLSConfigOptions{}\n\n\terrs := []error{}\n\tfor _, option := range options {\n\t\terr := option(&to)\n\t\tif err != nil {\n\t\t\terrs = append(errs, err)\n\t\t}\n\t}\n\n\tif len(errs) > 0 {\n\t\treturn nil, errors.Join(errs...)\n\t}\n\n\tconfig := tls.Config{\n\t\tInsecureSkipVerify: to.insecureSkipTLSverify,\n\t}\n\n\tif len(to.certPEMBlock) > 0 && len(to.keyPEMBlock) > 0 {\n\t\tcert, err := tls.X509KeyPair(to.certPEMBlock, to.keyPEMBlock)\n\t\tif err != nil {\n\t\t\treturn nil, fmt.Errorf(\"unable to load cert from key pair: %w\", err)\n\t\t}\n\n\t\tconfig.Certificates = []tls.Certificate{cert}\n\t}\n\n\tif len(to.caPEMBlock) > 0 {\n\t\tcp := x509.NewCertPool()\n\t\tif !cp.AppendCertsFromPEM(to.caPEMBlock) {\n\t\t\treturn nil, fmt.Errorf(\"failed to append certificates from pem block\")\n\t\t}\n\n\t\tconfig.RootCAs = cp\n\t}\n\n\treturn &config, nil\n}\n"
  },
  {
    "path": "sdkexamples/uninstall.go",
    "content": "package main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v4/pkg/action\"\n\t\"helm.sh/helm/v4/pkg/cli\"\n)\n\nfunc runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tuninstallClient := action.NewUninstall(actionConfig)\n\tuninstallClient.DeletionPropagation = \"foreground\" // \"background\" or \"orphan\"\n\tuninstallClient.WaitStrategy = \"watcher\"\n\n\tresult, err := uninstallClient.Run(releaseName)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run uninstall action: %w\", err)\n\t}\n\tif result != nil {\n\t\tlogger.Printf(\"result: %+v\\n\", result.Info)\n\t}\n\n\tlogger.Printf(\"release \\\"%s\\\" uninstalled\\n\", releaseName)\n\n\treturn nil\n}\n"
  },
  {
    "path": "sdkexamples/upgrade.go",
    "content": "package main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v4/pkg/action\"\n\t\"helm.sh/helm/v4/pkg/chart\"\n\t\"helm.sh/helm/v4/pkg/chart/loader\"\n\t\"helm.sh/helm/v4/pkg/cli\"\n\t\"helm.sh/helm/v4/pkg/downloader\"\n\t\"helm.sh/helm/v4/pkg/getter\"\n)\n\nfunc runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tupgradeClient := action.NewUpgrade(actionConfig)\n\n\tupgradeClient.Namespace = settings.Namespace()\n\tupgradeClient.DryRunStrategy = \"none\"\n\tupgradeClient.Version = chartVersion\n\tupgradeClient.WaitStrategy = \"watcher\"\n\n\tregistryClient, err := newRegistryClient(\n\t\tsettings,\n\t\tupgradeClient.CertFile,\n\t\tupgradeClient.KeyFile,\n\t\tupgradeClient.CaFile,\n\t\tupgradeClient.InsecureSkipTLSverify,\n\t\tupgradeClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"missing registry client: %w\", err)\n\t}\n\tupgradeClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tcharter, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to load chart: %w\", err)\n\t}\n\n\tchartAccessor, err := chart.NewDefaultAccessor(charter)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"error creating chart accessor: %w\", err)\n\t}\n\n\tif chartDependencies := chartAccessor.MetaDependencies(); chartDependencies != nil {\n\t\tif err := action.CheckDependencies(charter, chartDependencies); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !upgradeClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tman := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          upgradeClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t}\n\t\t\tif err := man.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif charter, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := upgradeClient.RunWithContext(ctx, releaseName, charter, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run upgrade action: %w\", err)\n\t}\n\n\tlogger.Printf(\"release: %+v\", release)\n\n\treturn nil\n}\n"
  },
  {
    "path": "sidebars.js",
    "content": "// @ts-check\n\n// This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)\n\n/**\n * Creating a sidebar enables you to:\n - create an ordered group of docs\n - render a sidebar for each doc of that group\n - provide next/previous navigation\n\n The sidebars can be generated from the filesystem, or explicitly defined here.\n\n Create as many sidebars as you want.\n\n @type {import('@docusaurus/plugin-content-docs').SidebarsConfig}\n */\nconst sidebars = {\n  // By default, Docusaurus generates a sidebar from the docs folder structure\n  tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],\n\n  // But you can create a sidebar manually\n  /*\n  tutorialSidebar: [\n    'intro',\n    'hello',\n    {\n      type: 'category',\n      label: 'Tutorial',\n      items: ['tutorial-basics/create-a-document'],\n    },\n  ],\n   */\n};\n\nexport default sidebars;\n"
  },
  {
    "path": "sidebars_community.js",
    "content": "module.exports = {\n  communitySidebar: [\n    {\n      type: 'autogenerated',\n      dirName: '.',\n    },\n  ],\n};\n"
  },
  {
    "path": "src/client-modules/heroHeightCalculator.js",
    "content": "// Hero height calculator client module\nfunction initializeHeroHeightCalculation() {\n  // Only run in browser environment\n  if (typeof window === 'undefined' || typeof document === 'undefined') {\n    return;\n  }\n\n  // Move hero to outer scope so it's accessible by all functions\n  let hero = null;\n\n  function calculateHeroHeight() {\n    hero = document.querySelector(\".hero\");\n\n    if (!hero) {\n      // Retry after React components have rendered\n      setTimeout(calculateHeroHeight, 100);\n      return;\n    }\n\n    function updateHeroHeight() {\n      // Safety check - hero might have been removed from DOM\n      if (!hero) {\n        return;\n      }\n\n      const vh = window.innerHeight;\n      const navbar = document.querySelector(\".navbar\");\n      const navbarHeight = navbar ? navbar.offsetHeight : 0;\n\n      // Check for announcement bar\n      const announcementBar = document.querySelector(\n        \"div.theme-announcement-bar\"\n      );\n      let announcementBarHeight = 0;\n\n      if (announcementBar && announcementBar.offsetHeight > 0) {\n        // Only count it if it's visible and has height\n        announcementBarHeight = announcementBar.offsetHeight;\n      }\n\n      const heroHeight = vh - navbarHeight - announcementBarHeight;\n\n      // Apply the calculated height (with safety check)\n      if (hero && hero.style) {\n        hero.style.height = `${heroHeight}px`;\n        hero.style.minHeight = `${heroHeight}px`;\n        hero.style.maxHeight = `${heroHeight}px`;\n      }\n    }\n\n    // Throttled scroll and resize handler\n    let ticking = false;\n    function requestTick() {\n      if (!ticking) {\n        requestAnimationFrame(updateHeroHeight);\n        ticking = true;\n        setTimeout(() => (ticking = false), 16);\n      }\n    }\n\n    function handleResize() {\n      updateHeroHeight();\n    }\n\n    // Event listeners\n    window.addEventListener(\"resize\", handleResize);\n    window.addEventListener(\"orientationchange\", () => {\n      setTimeout(handleResize, 100);\n    });\n\n    // iOS Safari specific events\n    window.addEventListener(\"pageshow\", handleResize);\n\n    // Watch for announcement bar close button clicks\n    function observeAnnouncementBar() {\n      const announcementBar = document.querySelector(\"div.theme-announcement-bar\");\n      if (announcementBar) {\n        const closeButton = announcementBar.querySelector(\"button\");\n        if (closeButton) {\n          closeButton.addEventListener(\"click\", () => {\n            // Delay recalculation to allow DOM to update after close animation\n            setTimeout(handleResize, 300);\n          });\n        }\n      }\n    }\n\n    // Set up announcement bar observer\n    observeAnnouncementBar();\n\n    // Initial setup with multiple attempts for better compatibility\n    updateHeroHeight();\n    observeAnnouncementBar();\n\n    // Delayed recalculation for dynamic content\n    setTimeout(() => {\n      updateHeroHeight();\n      observeAnnouncementBar();\n    }, 100);\n    setTimeout(() => {\n      updateHeroHeight();\n      observeAnnouncementBar();\n    }, 500);\n  }\n\n  // Track if we've successfully applied styles\n  let stylesApplied = false;\n\n  function ensureHeroStylesApplied() {\n    if (!stylesApplied && hero && hero.style.height) {\n      stylesApplied = true;\n      return true;\n    }\n    return false;\n  }\n\n  // Initialize with multiple strategies to catch hydration\n  function initializeHero() {\n    calculateHeroHeight();\n\n    // Keep trying until styles are actually applied\n    let attempts = 0;\n    const checkInterval = setInterval(() => {\n      attempts++;\n      if (ensureHeroStylesApplied() || attempts > 20) {\n        clearInterval(checkInterval);\n      } else {\n        calculateHeroHeight();\n      }\n    }, 100);\n  }\n\n  // Initialize on page load\n  if (document.readyState === 'loading') {\n    document.addEventListener('DOMContentLoaded', initializeHero);\n  } else {\n    initializeHero();\n  }\n\n  // Also listen for React hydration completion\n  if (typeof window !== 'undefined') {\n    // React 18+ hydration\n    const reactRoot = document.getElementById('__docusaurus');\n    if (reactRoot) {\n      // Use MutationObserver to detect when React modifies the DOM\n      const observer = new MutationObserver((mutations) => {\n        if (window.location.pathname === '/' && !stylesApplied) {\n          calculateHeroHeight();\n          if (ensureHeroStylesApplied()) {\n            observer.disconnect();\n          }\n        }\n      });\n\n      observer.observe(reactRoot, {\n        childList: true,\n        subtree: true,\n        attributes: true,\n        attributeFilter: ['class', 'style']\n      });\n\n      // Disconnect after 5 seconds to prevent memory leaks\n      setTimeout(() => observer.disconnect(), 5000);\n    }\n  }\n\n  // Force scroll to top AFTER browser's scroll restoration\n  if (window.location.pathname === '/') {\n    // Disable scroll restoration for this page\n    if ('scrollRestoration' in history) {\n      history.scrollRestoration = 'manual';\n    }\n\n    // Multiple attempts to ensure we stay at top\n    window.scrollTo(0, 0);\n    setTimeout(() => window.scrollTo(0, 0), 0);\n    setTimeout(() => window.scrollTo(0, 0), 100);\n    setTimeout(() => window.scrollTo(0, 0), 300);\n  }\n\n  // Handle Docusaurus route changes\n  window.addEventListener('docusaurus:route-did-update', () => {\n    if (window.location.pathname === '/') {\n      stylesApplied = false;  // Reset for new navigation\n      setTimeout(initializeHero, 100);\n    }\n  });\n\n  // Handle client-side navigation (Docusaurus SPA routing)\n  const originalPushState = history.pushState;\n  const originalReplaceState = history.replaceState;\n\n  history.pushState = function() {\n    originalPushState.apply(history, arguments);\n    setTimeout(() => {\n      calculateHeroHeight();\n    }, 100);\n  };\n\n  history.replaceState = function() {\n    originalReplaceState.apply(history, arguments);\n    setTimeout(() => {\n      calculateHeroHeight();\n    }, 100);\n  };\n\n  window.addEventListener(\"popstate\", () => {\n    setTimeout(() => {\n      calculateHeroHeight();\n    }, 100);\n  });\n\n  // Handle hot module replacement during development\n  if (module.hot) {\n    module.hot.addStatusHandler((status) => {\n      if (status === 'idle') {\n        setTimeout(calculateHeroHeight, 200);\n      }\n    });\n  }\n\n  // Alternative: Listen for React's development mode updates\n  if (typeof window !== 'undefined' && window.__REACT_DEVTOOLS_GLOBAL_HOOK__) {\n    const hook = window.__REACT_DEVTOOLS_GLOBAL_HOOK__;\n    if (hook.onCommitFiberRoot) {\n      const originalOnCommitFiberRoot = hook.onCommitFiberRoot;\n      hook.onCommitFiberRoot = function() {\n        originalOnCommitFiberRoot.apply(this, arguments);\n        setTimeout(calculateHeroHeight, 100);\n      };\n    }\n  }\n}\n\n// Execute immediately when module is imported\ninitializeHeroHeightCalculation();"
  },
  {
    "path": "src/components/Boat/boat.css",
    "content": "/**\n * Helm boat animation styles.\n */\n\n@keyframes boat-bob {\n  0% {\n    bottom: max(1.5rem, 2vw);\n    transform: rotate(4deg);\n  }\n  50% {\n    bottom: max(2.1rem, 3.5vw);\n    transform: rotate(-6deg);\n  }\n  100% {\n    bottom: max(1.5rem, 2vw);\n    transform: rotate(4deg);\n  }\n}\n\n@keyframes boat-badge-bob {\n  0% {\n    top: 0.425vw;\n    transform: rotate(-4deg);\n  }\n  50% {\n    top: 0.75vw;\n    transform: rotate(2deg);\n  }\n  100% {\n    top: 0.425vw;\n    transform: rotate(-4deg);\n  }\n}\n\n@keyframes move-forever {\n  0% {\n    transform: translate3d(-90px, 0, 0);\n  }\n  100% {\n    transform: translate3d(85px, 0, 0);\n  }\n}\n\n/* override search bar to give more z-index room between the navbar and boat layers */\n/* Navbar is --ifm-z-index-fixed, and search was --ifm-z-index-fixed + 1 */\nbody .DocSearch-Container {\n  z-index: calc(var(--ifm-z-index-fixed) + 10);\n}\n\n.boat {\n  width: auto;\n  position: absolute;\n  top: auto;\n  bottom: 0;\n  left: 0;\n  right: 0;\n  min-height: 10vw;\n  z-index: calc(var(--ifm-z-index-fixed) + 5);\n  transition: all 0.5s ease-in-out;\n  /* Ensure boat is positioned relative to its parent and contained within borders */\n}\n\n.boat .boat-ship {\n  position: absolute;\n  margin-top: max(0.25rem, 0.5vw);\n  left: max(1.5rem, 3.25vw);\n  bottom: max(6rem, 2vw);\n  max-width: max(8rem, 15vw); /* Minimum 8rem boat, scales with viewport */\n  z-index: calc(var(--ifm-z-index-fixed) + 4);\n  animation: boat-bob 7s ease-in-out infinite;\n  transition: all 0.5s ease-in-out;\n}\n\n.boat:after {\n  content: \"ahoy!\";\n  font-family: var(--ifm-heading-font-family);\n  font-size: 0.75rem;\n  padding: 0.75em;\n  color: var(--navy);\n  background: var(--salmon);\n  position: absolute;\n  bottom: 8vw;\n  left: 13.5vw;\n  line-height: 1;\n  z-index: calc(var(--ifm-z-index-fixed) + 1);\n  opacity: 0;\n  transition: all 0.3s ease-in-out;\n  border-radius: 4px;\n}\n\n.boat:hover:after {\n  opacity: 1;\n  bottom: 11vw;\n}\n\n.boat .wave-wrapper {\n  position: absolute;\n  margin: 0;\n  left: 0;\n  right: 0;\n  bottom: 0;\n  height: max(3rem, 6vw); /* Just tall enough for waves */\n  overflow: visible;\n  z-index: calc(var(--ifm-z-index-fixed) + 2);\n  background-color: transparent;\n  transition: all 0.5s ease-in-out;\n}\n\n\n.boat .wave-wrapper:before {\n  position: absolute;\n  bottom: 0;\n  left: 0;\n  right: 0;\n  content: \" \";\n  height: max(1.8rem, 3.5vw); /* Scale down more to match boat */\n  width: 100%;\n  background: var(--blue-light);\n  transition: all 0.3s ease-in-out;\n}\n\n.boat .wave-wrapper .waves {\n  position: relative;\n  width: 100%;\n  height: max(1.2rem, 3vw); /* Scale down more to match boat */\n  transition: all 0.3s ease-in-out;\n}\n\n.boat .parallax > use {\n  animation: move-forever 25s ease-in-out infinite;\n}\n\n.boat .parallax > use:nth-child(1) {\n  animation-delay: -2s;\n  animation-duration: 7s;\n}\n\n.boat .parallax > use:nth-child(2) {\n  animation-delay: -3s;\n  animation-duration: 10s;\n}\n\n.boat .parallax > use:nth-child(3) {\n  animation-delay: -4s;\n  animation-duration: 13s;\n}\n\n.boat .parallax > use:nth-child(4) {\n  animation-delay: -5s;\n  animation-duration: 20s;\n}\n\n\n/* Boat fixed nav 'badge' mode */\n.boat.boat-badge {\n  position: fixed;\n  top: calc(var(--ifm-navbar-height) + 0.25rem);\n  left: 1rem;\n  width: 7.5vw;\n  height: 7.5vw;\n  z-index: calc(\n    var(--ifm-z-index-fixed) - 1\n  ); /* Lower z-index to stay below navbar */\n  max-width: 80px;\n  max-height: 80px;\n}\n\n.boat.boat-badge .boat-ship {\n  left: 0.636vw;\n  top: 0.2vw;\n  z-index: calc(var(--ifm-z-index-fixed) + 3);\n  max-width: 7vw;\n  animation: boat-badge-bob 7s ease-in-out infinite;\n  bottom: auto;\n  right: auto;\n}\n\n.boat.boat-badge .wave-wrapper {\n  width: 7.5vw;\n  height: 7.5vw;\n  border-radius: 50%;\n  border: 3px solid rgba(255, 255, 255, 0.05);\n  background-blend-mode: screen;\n  background: rgba(219, 225, 243, 0.5);\n  bottom: auto;\n  right: auto;\n  overflow: hidden;\n}\n\n.boat.boat-badge .wave-wrapper .waves {\n  margin-top: 3.75vw;\n  margin-bottom: -7px;\n  min-height: 0.25vw;\n  max-height: 1.5vw;\n}\n\n.boat.boat-badge .wave-wrapper:before {\n  width: 100%;\n  height: 3vw;\n  top: 5.25vw;\n  bottom: auto;\n  right: auto;\n}\n\n.boat.boat-badge:after {\n  display: none; /* Hide the tooltip in badge mode */\n}\n\n.boat.boat-badge:hover:after {\n  display: none;\n}\n\n/* Responsive adjustments for boat badge */\n@media screen and (max-width: 768px) {\n  /* Keep boat positioning absolute to stay at bottom of hero section */\n  .boat {\n    position: absolute; /* Keep absolute positioning */\n    bottom: 0; /* Stay at bottom */\n    width: 100vw;\n  }\n\n  .boat .boat-ship {\n    max-width: 15vw;\n    min-width: 100px; /* Add minimum size for mobile */\n  }\n\n  .boat.boat-badge {\n    width: 60px;\n    height: 60px;\n    max-width: 60px;\n    max-height: 60px;\n  }\n\n  .boat.boat-badge .boat-ship {\n    left: 0.3rem;\n    top: 0.1rem;\n    max-width: 60px;\n    min-width: 60px;\n  }\n\n  .boat.boat-badge .wave-wrapper {\n    width: 60px;\n    height: 60px;\n  }\n\n  .boat.boat-badge .wave-wrapper .waves {\n    margin-top: 30px;\n  }\n\n  .boat.boat-badge .wave-wrapper:before {\n    height: 25px;\n    top: 35px;\n  }\n}\n"
  },
  {
    "path": "src/components/Boat/index.js",
    "content": "import { useState, useEffect } from \"react\";\nimport \"./boat.css\";\n\nexport default function BoatComponent() {\n  const [isBadgeMode, setIsBadgeMode] = useState(false);\n\n  useEffect(() => {\n    const handleScroll = () => {\n      // Switch to badge mode when scrolled down more than the viewport height\n      const scrollPosition = window.scrollY;\n      const triggerPoint = window.innerHeight * 0.7; // Trigger at 70% of viewport height\n\n      setIsBadgeMode(scrollPosition > triggerPoint);\n    };\n\n    window.addEventListener(\"scroll\", handleScroll);\n    return () => window.removeEventListener(\"scroll\", handleScroll);\n  }, []);\n\n  return (\n    <div className={`boat ${isBadgeMode ? \"boat-badge\" : \"boat-full\"}`}>\n      <img src=\"/img/boat.svg\" alt=\"boat\" className=\"boat-ship\" />\n      <div className=\"wave-wrapper\">\n        <svg\n          className=\"waves\"\n          xmlns=\"http://www.w3.org/2000/svg\"\n          xmlnsXlink=\"http://www.w3.org/1999/xlink\"\n          viewBox=\"0 24 150 28\"\n          preserveAspectRatio=\"none\"\n          shapeRendering=\"auto\"\n        >\n          <defs>\n            <path\n              id=\"gentle-wave\"\n              d=\"M-160 44c30 0 58-18 88-18s 58 18 88 18 58-18 88-18 58 18 88 18 v44h-352z\"\n            />\n          </defs>\n          <g className=\"parallax\">\n            <use\n              xlinkHref=\"#gentle-wave\"\n              x=\"48\"\n              y=\"0\"\n              fill=\"rgba(27,83,194,0.7)\"\n            />\n            <use\n              xlinkHref=\"#gentle-wave\"\n              x=\"48\"\n              y=\"3\"\n              fill=\"rgba(27,83,194,0.5)\"\n            />\n            <use\n              xlinkHref=\"#gentle-wave\"\n              x=\"48\"\n              y=\"5\"\n              fill=\"rgba(27,83,194,0.3)\"\n            />\n            <use\n              xlinkHref=\"#gentle-wave\"\n              x=\"48\"\n              y=\"7\"\n              fill=\"rgba(27,83,194,1)\"\n            />\n          </g>\n        </svg>\n      </div>\n    </div>\n  );\n}\n"
  },
  {
    "path": "src/components/GetVersion.js",
    "content": "import { useVersions } from \"@docusaurus/plugin-content-docs/client\";\nimport Link from \"@docusaurus/Link\";\n\n/**\n * Component to find and return the label for a specific major version as a raw string.\n * @param {object} props\n * @param {string} props.majorVersion The major version number to find (e.g., \"4\")\n * @param {boolean} props.label Whether or not to return the configured Docusaurus label for this major version or just the SemVer string\n * @param {boolean} props.link Whether or not to wrap the version-or-label in the link to the GitHub release for this version\n */\nexport default function GetVersion({ majorVersion, label, link }) {\n  const versions = useVersions();\n\n  // Official SemVer 2.0.0 ECMA-compatible RegEx\n  // ref: https://semver.org/#is-there-a-suggested-regular-expression-regex-to-check-a-semver-string\n  // Example: a label like \"4.0.0-rc.1 🚧\" has a SemVer match array like:\n  // 0: \"4.0.0-rc.1\"\n  // 1: \"4\"\n  // 2: \"0\"\n  // 3: \"0\"\n  // 4: \"rc.1\"\n  const semverRegex =\n    /(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-]+)*))?/;\n\n  let SemVerMatch = null;\n  let ReturnValue = null;\n  const targetVersion = versions.find((version) => {\n    const match = version.label.match(semverRegex);\n\n    if (match) {\n      const extractedMajor = match[1];\n      if (extractedMajor === majorVersion) {\n        SemVerMatch = match[0];\n        return true;\n      }\n    }\n    return false;\n  });\n\n  if (!targetVersion) {\n    return `${majorVersion}.x (not found)`;\n  }\n\n  if (label) {\n    // Return the string value of the label\n    ReturnValue = targetVersion.label;\n  } else {\n    // Return only the SemVer\n    ReturnValue = `v${SemVerMatch}`;\n  }\n\n  if (link) {\n    return (\n      <Link href={`https://github.com/helm/helm/releases/tag/v${SemVerMatch}`}>\n        {ReturnValue}\n      </Link>\n    );\n  } else {\n    return ReturnValue;\n  }\n}\n"
  },
  {
    "path": "src/components/HomeAbout/index.js",
    "content": "import Heading from '@theme/Heading';\nimport clsx from 'clsx';\nimport styles from './styles.module.css';\nimport homeSections from '@site/src/css/home-sections.module.css';\nimport Translate from '@docusaurus/Translate';\n\nconst Pyramid = require(\"@site/static/img/helm-pyramid-solid.svg\").default;\n\nfunction About() {\n  return (\n    <div>\n      <p>\n        <Translate\n          id=\"home.about.whatIsHelm\"\n          description=\"What is Helm? first paragraph\">\n          Helm helps you manage Kubernetes applications — Helm Charts help you\n          define, install, and upgrade even the most complex Kubernetes\n          application.\n        </Translate>\n      </p>\n      <p>\n        <Translate\n          id=\"home.about.chartsDescription\"\n          description=\"What is Helm? charts paragraph\">\n          Charts are easy to create, version, share, and publish — so start using\n          Helm and stop the copy-and-paste.\n        </Translate>\n      </p>\n      <p>\n        <Translate\n          id=\"home.about.cncf\"\n          description=\"What is Helm? CNCF Graduated Project paragraph\"\n          values={{\n            cncfLink: (\n              <a href=\"https://www.cncf.io\">CNCF</a>\n            ),\n            helmCommunityLink: (\n              <a href=\"/community/governance/governance\">\n                <Translate\n                  id=\"home.about.cncf.helmCommunityLink\"\n                  description=\"Helm community link\"\n                >\n                  Helm community\n                </Translate>\n              </a>\n            ),\n          }}>\n          {'Helm is a graduated project in the {cncfLink} and is maintained by the {helmCommunityLink}.'}\n        </Translate>\n      </p>\n      <h3><Translate id=\"home.about.learnMore\" description=\"Learn more label\">Learn more:</Translate></h3>\n      <ul>\n        <li>\n          <a href=\"./docs/topics/architecture\">\n            <Translate id=\"home.about.learnMore.helmArchitectureLink\" description=\"Helm Architecture link\">Helm Architecture</Translate>\n          </a>\n        </li>\n        <li>\n          <a href=\"./docs/intro/quickstart\">\n            <Translate id=\"home.about.learnMore.quickStartGuideLink\" description=\"Quick Start Guide link\">Quick Start Guide</Translate>\n          </a>\n        </li>\n        <li>\n          <a href=\"https://www.youtube.com/watch?v=Zzwq9FmZdsU&t=2s\">\n            <Translate id=\"home.about.learnMore.videoLink\" description=\"Video: An Introduction to Helm link\">Video: An Introduction to Helm</Translate>\n          </a>\n        </li>\n      </ul>\n    </div>\n  );\n}\n\nexport default function HomeAbout() {\n  return (\n    <section className={clsx(homeSections.section, homeSections.sectionDark, styles.about)}>\n      <div className=\"container\">\n        <Pyramid className={styles.pyramid} role=\"img\" />\n        <Heading as=\"h2\"><Translate id=\"home.about.title\" description=\"What is Helm? title\">What is Helm?</Translate></Heading>\n        <About />\n      </div>\n    </section>\n  );\n}"
  },
  {
    "path": "src/components/HomeAbout/styles.module.css",
    "content": ".pyramid {\n  display: block;\n  margin: 0 auto 2rem;\n  height: 6rem;\n  width: auto;\n}"
  },
  {
    "path": "src/components/HomeCommunity/index.js",
    "content": "import React from \"react\";\nimport clsx from \"clsx\";\nimport Heading from \"@theme/Heading\";\nimport styles from \"./styles.module.css\";\nimport homeSections from \"@site/src/css/home-sections.module.css\";\nimport homeCards from \"@site/src/css/home-cards.module.css\";\nimport Translate from \"@docusaurus/Translate\";\nimport useDocusaurusContext from '@docusaurus/useDocusaurusContext';\nimport {\n  MdVideoCall,\n  MdForum,\n  MdSchedule,\n  MdCalendarToday,\n  MdRocketLaunch,\n  MdGroup,\n  MdVideoLibrary,\n  MdLogin,\n  MdCalendarMonth,\n} from \"react-icons/md\";\n\nfunction CustomDate({dateString, formatType, endDateString}) {\n  const {i18n} = useDocusaurusContext();\n  const date = new Date(dateString);\n\n  const formats = {\n    day: { day: 'numeric', month: 'short', year: 'numeric' },\n    month: { month: 'long', year: 'numeric' },\n  };\n\n  if (formatType === 'dayRange') {\n    const startDate = new Date(dateString);\n    const endDate = endDateString ? new Date(endDateString) : new Date(startDate.getTime() + 4 * 24 * 60 * 60 * 1000); // 4 days later if no endDate\n    const formatter = new Intl.DateTimeFormat(i18n.currentLocale, {\n      day: 'numeric',\n      month: 'short',\n    });\n    const yearFormatter = new Intl.DateTimeFormat(i18n.currentLocale, {\n      year: 'numeric'\n    });\n\n    const startFormatted = formatter.format(startDate);\n    const endFormatted = formatter.format(endDate);\n    const year = yearFormatter.format(startDate);\n\n    return (\n      <span suppressHydrationWarning>\n        {startFormatted} - {endFormatted}, {year}\n      </span>\n    );\n  } else {\n    const options = formats[formatType] || formats['day'];\n    const formatter = new Intl.DateTimeFormat(i18n.currentLocale, options);\n    return <span suppressHydrationWarning>{formatter.format(date)}</span>;\n  }\n}\n\nconst BlockList = [\n  {\n    title: (\n      <Translate\n        id=\"home.community.nextFeatureRelease\"\n        description=\"Next Feature Release section title\"\n      >\n        Next Feature Release\n      </Translate>\n    ),\n    description: (\n      <>\n        <dl>\n          <dt>\n            <MdRocketLaunch className={styles.icon} />\n            <Translate\n              id=\"home.community.nextFeatureRelease.version\"\n              description=\"Next Feature Release version\"\n            >\n              v4.2.0\n            </Translate>\n          </dt>\n          <dd>\n            <em><CustomDate dateString=\"2026-05-13\" formatType=\"month\" /></em>\n          </dd>\n\n          <dt>\n            <MdCalendarMonth className={styles.icon} />\n            <a href=\"calendar/release\">\n              <Translate\n                id=\"home.community.nextFeatureRelease.calendar\"\n                description=\"Release Calendar link\"\n              >\n                Release Calendar\n              </Translate>\n            </a>\n          </dt>\n        </dl>\n      </>\n    ),\n  },\n  {\n    title: (\n      <Translate id=\"home.community.events\" description=\"Events section title\">\n        Events\n      </Translate>\n    ),\n    description: (\n      <>\n        <dl>\n          <dt>\n            <MdSchedule className={styles.icon} />\n            <Translate\n              id=\"home.community.upcomingEventsSubtitle\"\n              description=\"Upcoming Events subtitle\"\n            >\n              Upcoming Events\n            </Translate>\n          </dt>\n          <dd>\n            <em><CustomDate dateString=\"2026-03-23\" endDateString=\"2026-03-26\" formatType=\"dayRange\" /></em> -{\" \"}\n            <a href=\"https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/\">\n              KubeCon Europe 2026\n            </a>\n          </dd>\n          <dt>\n            <MdCalendarToday className={styles.icon} />\n            <Translate\n              id=\"home.community.pastEventsSubtitle\"\n              description=\"Past Events subtitle\"\n            >\n              Past Events\n            </Translate>\n          </dt>\n          <dd>\n            <em><CustomDate dateString=\"2025-11-10\" endDateString=\"2025-11-13\" formatType=\"dayRange\" /></em> -{\" \"}\n            <a href=\"https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/\">\n              KubeCon North America 2025\n            </a>\n          </dd>\n          <dd>\n            <em><CustomDate dateString=\"2025-04-01\" endDateString=\"2025-04-04\" formatType=\"dayRange\" /></em> -{\" \"}\n            <a href=\"https://events.linuxfoundation.org/archive/2025/kubecon-cloudnativecon-europe/\">\n              KubeCon Europe 2025\n            </a>\n          </dd>\n          <dd>\n            <em><CustomDate dateString=\"2024-11-12\" endDateString=\"2024-11-15\" formatType=\"dayRange\" /></em> -{\" \"}\n            <a href=\"https://events.linuxfoundation.org/archive/2024/kubecon-cloudnativecon-north-america/\">\n              KubeCon North America 2024\n            </a>\n          </dd>\n        </dl>\n      </>\n    ),\n  },\n  {\n    title: (\n      <Translate\n        id=\"home.community.sigApps\"\n        description=\"SIG Apps section title\"\n      >\n        SIG Apps\n      </Translate>\n    ),\n    description: (\n      <>\n        <p>\n          <MdVideoLibrary className={styles.icon} />\n          <Translate\n            id=\"home.community.sigApps.description\"\n            description=\"SIG Apps meeting description\"\n            values={{\n              meetLink: (\n                <a href=\"https://github.com/kubernetes/community/blob/master/sig-apps/README.md\">\n                  <Translate\n                    id=\"home.community.sigApps.meetLink\"\n                    description=\"Link to SIG Apps meetings\"\n                  >\n                    meet each week\n                  </Translate>\n                </a>\n              ),\n              youtubeLink: (\n                <a href=\"https://www.youtube.com/results?search_query=kubernetes+sig+apps\">\n                  <Translate\n                    id=\"home.community.sigApps.youtubeLink\"\n                    description=\"Link to YouTube recordings\"\n                  >\n                    shared to YouTube\n                  </Translate>\n                </a>\n              ),\n            }}\n          >\n            {\n              \"They {meetLink} to demo and discuss tools and projects. Community meetings are recorded and {youtubeLink}.\"\n            }\n          </Translate>\n        </p>\n      </>\n    ),\n  },\n  {\n    title: (\n      <Translate id=\"home.community.developerStandups\">\n        Developer Standups\n      </Translate>\n    ),\n    description: (\n      <>\n        <p>\n          <MdVideoCall className={styles.icon} />\n          <a href=\"https://zoom.us/j/696660622\">\n            <Translate\n              id=\"home.community.developerStandups.time\"\n              description=\"Developer Standups day and time\"\n            >\n              Thursdays 9:30-10am (PT)\n            </Translate>\n          </a>\n        </p>\n        <p>\n          <MdGroup className={styles.icon} />\n          <Translate\n            id=\"home.community.developerStandups.description\"\n            description=\"Developer Standups description with community repo link\"\n            values={{\n              communityRepoLink: (\n                <a href=\"https://github.com/helm/community/blob/main/communication.md#meetings\">\n                  <Translate\n                    id=\"home.community.developerStandups.communityRepoLink\"\n                    description=\"Community repo link\"\n                  >\n                    community repo\n                  </Translate>\n                </a>\n              ),\n            }}\n          >\n            {\n              \"These meetings are open to all. Check the {communityRepoLink} for notes and details.\"\n            }\n          </Translate>\n        </p>\n      </>\n    ),\n  },\n  {\n    title: \"Slack\",\n    description: (\n      <>\n        <p>\n          <Translate\n            id=\"home.community.slack.join\"\n            description=\"How to join the Kubernetes Slack team with slack link\"\n            values={{\n              slackLink: (\n                <a href=\"https://slack.k8s.io/\">\n                  <Translate\n                    id=\"home.community.slack.join.slackLink\"\n                    description=\"Request access to slack link\"\n                  >\n                    Request access here\n                  </Translate>\n                </a>\n              ),\n            }}\n          >\n            {\"{slackLink} to join the Kubernetes Slack team.\"}\n          </Translate>\n        </p>\n        <dl>\n          <dt>\n            <MdForum className={styles.icon} />\n            <a href=\"https://kubernetes.slack.com/messages/helm-users\">\n              Helm Users\n            </a>\n          </dt>\n          <dd>\n            <Translate\n              id=\"home.community.slack.helmUsers.description\"\n              description=\"helm-users slack channel description\"\n            >\n              Discussion around using Helm, working with charts and solving\n              common errors.\n            </Translate>\n          </dd>\n\n          <dt>\n            <MdForum className={styles.icon} />\n            <a href=\"https://kubernetes.slack.com/messages/helm-dev\">\n              Helm Development\n            </a>\n          </dt>\n          <dd>\n            <Translate\n              id=\"home.community.slack.helmDevelopment.description\"\n              description=\"helm-dev slack channel description\"\n            >\n              Topics regarding Helm development, ongoing PRs, releases, etc.\n            </Translate>\n          </dd>\n\n          <dt>\n            <MdForum className={styles.icon} />\n            <a href=\"https://kubernetes.slack.com/messages/charts\">Charts</a>\n          </dt>\n          <dd>\n            <Translate\n              id=\"home.community.slack.charts.description\"\n              description=\"charts slack channel description\"\n            >\n              Discussion for users and contributors to Helm Charts.\n            </Translate>\n          </dd>\n        </dl>\n      </>\n    ),\n  },\n  {\n    title: (\n      <Translate\n        id=\"home.community.contributing\"\n        description=\"Contributing section title\"\n      >\n        Contributing\n      </Translate>\n    ),\n    description: (\n      <>\n        <p>\n          <Translate\n            id=\"home.community.contributing.description\"\n            description=\"Contributing section description\"\n          >\n            Helm always welcomes new contributions to the project!\n          </Translate>\n        </p>\n        <h3>\n          <Translate\n            id=\"home.community.contributing.whereToBegin\"\n            description=\"Where to begin? section title\"\n          >\n            Where to begin?\n          </Translate>\n        </h3>\n        <p>\n          <Translate\n            id=\"home.community.contributing.whereToBegin.description\"\n            description=\"Where to begin? section description\"\n          >\n            Helm is a big project with a lot of users and contributors. It can\n            be a lot to take in!\n          </Translate>\n        </p>\n        <p>\n          <Translate\n            id=\"home.community.contributing.whereToBegin.goodFirstIssues\"\n            description=\"Good first issues sentence with link\"\n            values={{\n              goodFirstIssuesLink: (\n                <a href=\"https://github.com/helm/helm/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3A%22good+first+issue%22\">\n                  <Translate\n                    id=\"home.community.contributing.whereToBegin.goodFirstIssuesLink\"\n                    description=\"Good first issues link\"\n                  >\n                    good first issues\n                  </Translate>\n                </a>\n              ),\n            }}\n          >\n            {\n              \"We have a list of {goodFirstIssuesLink} if you want to help but don't know where to start.\"\n            }\n          </Translate>\n        </p>\n\n        <h3>\n          <Translate\n            id=\"home.community.contributing.whatDoIDo\"\n            description=\"What do I do? section title\"\n          >\n            What do I do?\n          </Translate>\n        </h3>\n        <p>\n          <Translate\n            id=\"home.community.contributing.whatDoIDo.contributionGuide\"\n            description=\"What do I do? contribution guide description\"\n            values={{\n              contributionGuideLink: (\n                <a href=\"https://github.com/helm/helm/blob/main/CONTRIBUTING.md\">\n                  <Translate\n                    id=\"home.community.contributing.whatDoIDo.contributionGuideLink\"\n                    description=\"Contribution Guide link\"\n                  >\n                    Contribution Guide\n                  </Translate>\n                </a>\n              ),\n            }}\n          >\n            {\n              \"Before you contribute some code, please read our {contributionGuideLink}. It goes over the processes around creating and reviewing pull requests.\"\n            }\n          </Translate>\n        </p>\n        <p>\n          <Translate\n            id=\"home.community.contributing.whatDoIDo.signYourCommits\"\n            description=\"What do I do? sign your commits description\"\n            values={{\n              signYourCommitsLink: (\n                <a href=\"blog/helm-dco\">\n                  <Translate\n                    id=\"home.community.contributing.whatDoIDo.signYourCommitsLink\"\n                    description=\"Sign your commits link\"\n                  >\n                    sign your commits\n                  </Translate>\n                </a>\n              ),\n              dcoLink: <a href=\"https://developercertificate.org/\">DCO</a>,\n              cncfLink: <a href=\"https://www.cncf.io/\">CNCF</a>,\n            }}\n          >\n            {\n              \"After you write some code, please {signYourCommitsLink} to ensure Helm adheres to the {dcoLink} agreement used by the {cncfLink}.\"\n            }\n          </Translate>\n        </p>\n      </>\n    ),\n  },\n];\n\nfunction Block({ title, description }) {\n  return (\n    <div className={clsx(\"col col--4\", homeCards.col)}>\n      <div className={clsx(\"card\", homeCards.card)}>\n        <div className={clsx(\"card__header\", homeCards.card__header)}>\n          <Heading as=\"h3\">{title}</Heading>\n        </div>\n        <div className=\"card__body\">{description}</div>\n      </div>\n    </div>\n  );\n}\n\nexport default function HomeCommunity() {\n  return (\n    <section\n      className={clsx(\n        homeSections.section,\n        homeSections.sectionLight,\n        styles.community\n      )}\n    >\n      <div className=\"container\">\n        <Heading as=\"h2\"><Translate id=\"home.community.title\" description=\"Join the Community title\">Join the Community</Translate></Heading>\n        <p><Translate id=\"home.community.subtitle\" description=\"Join the Community subtitle\">More information about the Helm project, and how to contribute.</Translate></p>\n        <div className=\"row\">\n          {BlockList.map((props, idx) => (\n            <Block key={idx} {...props} />\n          ))}\n        </div>\n      </div>\n    </section>\n  );\n}\n"
  },
  {
    "path": "src/components/HomeCommunity/styles.module.css",
    "content": "/* Component has no specific styles - uses shared home module styles */\n\n/* Material Design Icon styling */\n.icon {\n  vertical-align: middle;\n  margin-right: 0.5rem;\n  font-size: 1.2em; /* Make React Icons larger to match other icon libraries */\n}\n"
  },
  {
    "path": "src/components/HomeFeatures/index.js",
    "content": "import clsx from 'clsx';\nimport Heading from '@theme/Heading';\nimport styles from './styles.module.css';\nimport homeSections from \"@site/src/css/home-sections.module.css\";\nimport homeCards from \"@site/src/css/home-cards.module.css\";\nimport Translate from '@docusaurus/Translate';\n\nconst FeatureList = [\n  {\n    title: <Translate id=\"home.features.manageComplexity\" description=\"Manage Complexity section title\">Manage Complexity</Translate>,\n    description: (\n      <>\n        <Translate id=\"home.features.manageComplexity.description\" description=\"Manage Complexity section description\">Charts describe even the most complex apps, provide repeatable\n        application installation, and serve as a single point of authority.</Translate>\n      </>\n    ),\n  },\n  {\n    title: <Translate id=\"home.features.easyUpdates\" description=\"Easy Updates section title\">Easy Updates</Translate>,\n    description: (\n      <>\n        <Translate id=\"home.features.easyUpdates.description\" description=\"Easy Updates section description\">Take the pain out of updates with in-place upgrades and custom hooks.</Translate>\n      </>\n    ),\n  },\n  {\n    title: <Translate id=\"home.features.simpleSharing\" description=\"Simple Sharing section title\">Simple Sharing</Translate>,\n    description: (\n      <>\n        <Translate id=\"home.features.simpleSharing.description\" description=\"Simple Sharing section description\">Charts are easy to version, share, and host on public or private servers.</Translate>\n      </>\n    ),\n  },\n  {\n    title: <Translate id=\"home.features.rollbacks\" description=\"Rollbacks section title\">Rollbacks</Translate>,\n    description: (\n      <>\n        <Translate\n          id=\"home.features.rollbacks.description\"\n          description=\"Rollbacks section description\"\n          values={{\n            helmRollback: (\n              <code>helm rollback</code>\n            ),\n          }}>\n          {'Use {helmRollback} to roll back to an older version of a release with ease.'}\n        </Translate>\n      </>\n    ),\n  },\n];\n\nfunction Feature({ title, description }) {\n  return (\n    <div className={clsx(\"col col--3\", homeCards.col)}>\n      <div className={clsx(\"card\", homeCards.card)}>\n        <div className={clsx(\"card__header\", homeCards.card__header)}>\n          <Heading as=\"h3\">{title}</Heading>\n        </div>\n        <div className=\"card__body\">\n          <p>{description}</p>\n        </div>\n      </div>\n    </div>\n  );\n}\n\nexport default function HomeFeatures() {\n  return (\n    <section\n      className={clsx(\n        homeSections.section,\n        homeSections.sectionLight,\n        styles.features\n      )}\n    >\n      <div className=\"container\">\n        <Heading as=\"h2\"><Translate id=\"home.features.title\" description=\"Features section title\">Features</Translate></Heading>\n        <div className=\"row\">\n          {FeatureList.map((props, idx) => (\n            <Feature key={idx} {...props} />\n          ))}\n        </div>\n      </div>\n    </section>\n  );\n}\n"
  },
  {
    "path": "src/components/HomeFeatures/styles.module.css",
    "content": "/* Component has no specific styles - uses shared home module styles */\n"
  },
  {
    "path": "src/components/HomeGettingStarted/index.js",
    "content": "import Heading from \"@theme/Heading\";\nimport clsx from \"clsx\";\nimport Tabs from \"@theme/Tabs\";\nimport TabItem from \"@theme/TabItem\";\nimport CodeBlock from \"@theme/CodeBlock\";\nimport styles from \"./styles.module.css\";\nimport homeSections from \"@site/src/css/home-sections.module.css\";\nimport homeCards from \"@site/src/css/home-cards.module.css\";\nimport Translate from '@docusaurus/Translate';\n\nexport default function HomeGettingStarted() {\n  return (\n    <section\n      className={clsx(\n        homeSections.section,\n        homeSections.sectionDark,\n        styles.gettingStarted\n      )}\n    >\n      <div className=\"container\">\n        <Heading as=\"h2\"><Translate id=\"home.gettingStarted.title\" description=\"Getting started section title\">Getting Started</Translate></Heading>\n        <div className=\"row\">\n          <div className={clsx(\"col col--6\", homeCards.col)}>\n            <div className={clsx(\"card\", homeCards.card)}>\n              <div className={clsx(\"card__header\", homeCards.card__header)}>\n                <Heading as=\"h3\"><Translate id=\"home.gettingStarted.getHelmTitle\" description=\"Get Helm section title\">Get Helm</Translate></Heading>\n              </div>\n              <div className=\"card__body\">\n                <p>\n                  <Translate\n                    id=\"home.gettingStarted.installHelm\"\n                    description=\"Getting started install with package manager sentence with download link\"\n                    values={{\n                      downloadLink: (\n                        <a href=\"https://github.com/helm/helm/releases/latest\">\n                          <Translate\n                            id=\"home.gettingStarted.installHelm.downloadLink\"\n                            description=\"Download a binary link\">\n                            download a binary\n                          </Translate>\n                        </a>\n                      ),\n                    }}>\n                    {'Install Helm with a package manager, or {downloadLink}.'}\n                  </Translate>\n                </p>\n\n                <Tabs>\n                  <TabItem value=\"homebrew\" label=\"Homebrew\" default>\n                    <CodeBlock language=\"bash\">brew install helm</CodeBlock>\n                  </TabItem>\n                  <TabItem value=\"chocolatey\" label=\"Chocolatey\">\n                    <CodeBlock language=\"bash\">\n                      choco install kubernetes-helm\n                    </CodeBlock>\n                  </TabItem>\n                  <TabItem value=\"scoop\" label=\"Scoop\">\n                    <CodeBlock language=\"bash\">scoop install helm</CodeBlock>\n                  </TabItem>\n                  <TabItem value=\"snap\" label=\"Snap\">\n                    <CodeBlock language=\"bash\">\n                      sudo snap install helm --classic\n                    </CodeBlock>\n                  </TabItem>\n                </Tabs>\n\n                <p>\n                  <Translate\n                    id=\"home.gettingStarted.postInstall.instructions\"\n                    description=\"Instructions after installing Helm\"\n                    values={{\n                      docsLink: (\n                        <a href=\"./docs/intro/install/\">\n                          <Translate\n                            id=\"home.gettingStarted.postInstall.docsLink\"\n                            description=\"Link to installation docs\">\n                            docs\n                          </Translate>\n                        </a>\n                      ),\n                      installationLink: (\n                        <a href=\"./docs/intro/install/\">\n                          <Translate\n                            id=\"home.gettingStarted.postInstall.installationLink\"\n                            description=\"Link to installation instructions\">\n                            installation\n                          </Translate>\n                        </a>\n                      ),\n                      usageLink: (\n                        <a href=\"./docs/intro/using_helm/\">\n                          <Translate\n                            id=\"home.gettingStarted.postInstall.usageLink\"\n                            description=\"Link to usage instructions\">\n                            usage instructions\n                          </Translate>\n                        </a>\n                      ),\n                    }}>\n                    {'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}.'}\n                  </Translate>\n                </p>\n              </div>\n            </div>\n          </div>\n\n          <div className={clsx(\"col col--6\", homeCards.col)}>\n            <div className={clsx(\"card\", homeCards.card)}>\n              <div className={clsx(\"card__header\", homeCards.card__header)}>\n                <Heading as=\"h3\">\n                  <Translate\n                    id=\"home.gettingStarted.getChartsTitle\"\n                    description=\"Getting started get charts title\">\n                    Get Charts\n                  </Translate>\n                </Heading>\n              </div>\n              <div className=\"card__body\">\n                <p>\n                  <Translate\n                    id=\"home.gettingStarted.artifactHub\"\n                    description=\"Artifact Hub link\"\n                    values={{\n                      artifactHubLink: (\n                        <a href=\"https://artifacthub.io\">Artifact Hub</a>\n                      ),\n                      helmChartsLink: (\n                        <a href=\"https://artifacthub.io/packages/search?kind=0\">\n                          <Translate\n                            id=\"home.gettingStarted.artifactHub.helmChartsLink\"\n                            description=\"Helm charts link\">\n                            Helm charts\n                          </Translate>\n                        </a>\n                      ),\n                    }}>\n                    {'Visit {artifactHubLink} to explore {helmChartsLink} from numerous public repositories.'}\n                  </Translate>\n                </p>\n\n                <a href=\"https://artifacthub.io/\">\n                  <img\n                    src=\"/img/artifact-hub.jpg\"\n                    alt=\"Artifact Hub\"\n                  />\n                </a>\n              </div>\n            </div>\n          </div>\n        </div>\n      </div>\n    </section>\n  );\n}\n"
  },
  {
    "path": "src/components/HomeGettingStarted/styles.module.css",
    "content": "\n.gettingStarted :global(.card) {\n  height: 100%;\n}\n\n.gettingStarted :global(.col) {\n  margin-bottom: 1rem;\n}\n\n/* Install Helm tabs */\n\n.gettingStarted :global(.tabs) {\n  /* Needed to wrap tabs. Wrap instead of horizontal overflow scrolling or scaling smaller */\n  flex-wrap: wrap;\n}\n\n/* Use standard Helm link color for tabs */\n.gettingStarted :global(.tabs__item) {\n  color: var(--ifm-color-white);\n  /* Needed to wrap tabs. Wrap instead of horizontal overflow scrolling or scaling smaller */\n  white-space: normal;\n}\n\n.gettingStarted :global(.tabs__item--active) {\n  color: var(--shade-green-bright);\n  border-bottom-color: var(--shade-green-bright);\n}\n\n.gettingStarted :global(.tabs__item):hover {\n  color: var(--shade-green-bright);\n}\n\n/* Ensure copy buttons are visible on mobile */\n@media (max-width: 996px) {\n  .gettingStarted :global(button.clean-btn) {\n    opacity: 1 !important;\n  }\n}\n"
  },
  {
    "path": "src/components/HomeHeader/index.js",
    "content": "// import useDocusaurusContext from \"@docusaurus/useDocusaurusContext\";\nimport Heading from \"@theme/Heading\";\nimport clsx from \"clsx\";\nimport styles from \"./styles.module.css\";\nimport Boat from \"@site/src/components/Boat\";\nimport Translate from '@docusaurus/Translate';\n\nexport default function HomeHeader() {\n  // const { siteConfig } = useDocusaurusContext();\n  return (\n    <header className={clsx(\"hero hero--primary\", styles.hero)}>\n      <div className={clsx(\"container\", styles.container)}>\n        <Heading as=\"h1\">\n          <Translate\n            id=\"home.header.tagline\"\n            description=\"Helm tagline\">\n            The package manager for Kubernetes\n          </Translate>\n        </Heading>\n        <h2>\n          <Translate\n            id=\"home.header.subtitle\"\n            description=\"Home page header subtitle\">\n            Helm is the best way to find, share, and use software built for\n          </Translate>\n          {\" \"}\n          <a href=\"https://kubernetes.io/\">Kubernetes</a>.\n        </h2>\n      </div>\n      <Boat />\n    </header>\n  );\n}\n"
  },
  {
    "path": "src/components/HomeHeader/styles.module.css",
    "content": ".hero {\n  padding: 4rem 0;\n  text-align: center;\n  position: relative;\n  overflow: hidden;\n  --ifm-hero-background-color: none;\n  --ifm-hero-text-color: var(--navy);\n  /* Prevent layout shift on page load/refresh by setting a reasonable default height */\n  /* Use 90vh to account for potential announcement bar and avoid exact match with JS calculation */\n  min-height: 90vh;\n}\n\n.container {\n  position: absolute;\n  top: 0;\n  left: 0;\n  right: 0;\n  bottom: max(3rem, 6vw); /* Above wave-wrapper, matches wrapper height */\n  display: flex;\n  flex-direction: column;\n  align-items: center;\n  justify-content: center;\n  padding: 2rem;\n  box-sizing: border-box;\n}\n\n@media screen and (max-width: 996px) {\n  .hero {\n    padding: 2rem;\n  }\n}\n\n.hero h1 {\n  font-size: clamp(1.8rem, 5vw, 2.5rem);\n  margin: 0;\n  line-height: 1.2;\n}\n\n.hero h2 {\n  font-size: clamp(1rem, 3vw, 1.5rem);\n  padding: clamp(1rem, 3vh, 2rem) clamp(0.75rem, 2vw, 1rem);\n  border: 5px solid var(--shade-light);\n  background: rgba(255, 255, 255, 0.67);\n  font-family: var(--ifm-font-family-base);\n  font-weight: unset;\n  display: inline-block;\n  margin: clamp(1.5rem, 4vh, 3rem) 0 0 0;\n  text-align: center;\n  line-height: 1.3;\n  max-width: 90%;\n}\n\n/* Side-by-side layout for very constrained heights */\n@media screen and (max-height: 380px) {\n  .container {\n    flex-direction: row;\n    align-items: center;\n    justify-content: center;\n    gap: clamp(0.5rem, 2vw, 2rem);\n    padding: 1rem;\n  }\n\n  .hero h1 {\n    font-size: clamp(1.6rem, 3.5vw, 2rem);\n    margin: 0;\n    flex: 1 1 50%; /* Equal 50/50 width, can shrink */\n    min-width: 0; /* Allow text to wrap/shrink */\n  }\n\n  .hero h2 {\n    font-size: clamp(1.1rem, 2vw, 1.2rem);\n    padding: clamp(0.75rem, 1.5vh, 1rem) clamp(0.5rem, 1vw, 0.75rem);\n    margin: 0;\n    flex: 1 1 50%; /* Equal 50/50 width, can shrink */\n    min-width: 0; /* Allow text to wrap/shrink */\n    max-width: none;\n    word-wrap: break-word;\n    hyphens: auto;\n  }\n}\n\n/* Extra constrained heights - further scaling */\n@media screen and (max-height: 400px) {\n  .container {\n    gap: clamp(0.25rem, 1vw, 1rem);\n    padding: 0.5rem;\n  }\n\n  .hero h1 {\n    font-size: clamp(1.3rem, 3vw, 1.5rem);\n  }\n\n  .hero h2 {\n    font-size: clamp(0.9rem, 1.8vw, 1rem);\n    padding: clamp(0.5rem, 1vh, 0.75rem) clamp(0.4rem, 0.8vw, 0.5rem);\n  }\n}\n"
  },
  {
    "path": "src/components/HomeSupport/index.js",
    "content": "import clsx from \"clsx\";\nimport Heading from \"@theme/Heading\";\nimport styles from \"./styles.module.css\";\nimport homeSections from \"@site/src/css/home-sections.module.css\";\nimport Translate from \"@docusaurus/Translate\";\n\nconst CompanyList = [\n  {\n    name: \"Bitnami\",\n    src: \"/img/logowall/bitnami.png\",\n    url: \"https://bitnami.com/\",\n  },\n  {\n    name: \"codecentric AG\",\n    src: \"/img/logowall/codecentric.png\",\n    url: \"https://www.codecentric.de/\",\n  },\n  {\n    name: \"Codefresh\",\n    src: \"/img/logowall/codefresh.png\",\n    url: \"https://codefresh.io/\",\n  },\n  {\n    name: \"Google\",\n    src: \"/img/logowall/google.png\",\n    url: \"https://cloud.google.com/\",\n  },\n  {\n    name: \"IBM\",\n    src: \"/img/logowall/ibm.png\",\n    url: \"https://www.ibm.com/\",\n  },\n  {\n    name: \"JetBrains\",\n    src: \"/img/logowall/jetbrains.png\",\n    url: \"https://www.jetbrains.com/\",\n  },\n  {\n    name: \"Microsoft\",\n    src: \"/img/logowall/microsoft.png\",\n    url: \"https://www.microsoft.com/\",\n  },\n  {\n    name: \"Montreal\",\n    src: \"/img/logowall/montreal.png\",\n    url: \"#\",\n  },\n  {\n    name: \"Red Hat\",\n    src: \"/img/logowall/redhat.png\",\n    url: \"https://www.redhat.com/\",\n  },\n  {\n    name: \"Replicated\",\n    src: \"/img/logowall/replicated.png\",\n    url: \"https://www.replicated.com/\",\n  },\n  {\n    name: \"Samsung SDS\",\n    src: \"/img/logowall/samsungsds.png\",\n    url: \"https://www.samsungsds.com/\",\n  },\n  {\n    name: \"SUSE\",\n    src: \"/img/logowall/suse.png\",\n    url: \"https://www.suse.com/\",\n  },\n  {\n    name: \"Ticketmaster\",\n    src: \"/img/logowall/tm.png\",\n    url: \"https://www.ticketmaster.com/\",\n  },\n];\n\nfunction CompanyLogo({ name, src, url }) {\n  const logoElement = (\n    <div className={styles.logoItem}>\n      <img src={src} alt={`${name} logo`} className={styles.logoImage} />\n    </div>\n  );\n\n  if (url === \"#\") {\n    return logoElement;\n  }\n\n  return (\n    <a href={url} target=\"_blank\" rel=\"noopener noreferrer\">\n      {logoElement}\n    </a>\n  );\n}\n\nexport default function HomeSupport() {\n  return (\n    <section className={clsx(homeSections.section, homeSections.sectionLight)}>\n      <div className=\"container\">\n        <div className=\"text--center\">\n          <Heading as=\"h2\">\n            <Translate\n              id=\"home.support.title\"\n              description=\"Community support section title\"\n            >\n              Supporters\n            </Translate>\n          </Heading>\n          <p>\n            <Translate\n              id=\"home.support.subtitle\"\n              description=\"Community support section subtitle\"\n            >\n              Helm is supported by and built with a community of over 400\n              developers.\n            </Translate>\n          </p>\n        </div>\n        <div className={styles.logoGrid}>\n          {CompanyList.map((props, idx) => (\n            <CompanyLogo key={idx} {...props} />\n          ))}\n        </div>\n        <div className=\"text--center\">\n          <p className={styles.maintainersText}>\n            <Translate\n              id=\"home.support.maintainers\"\n              description=\"Link to core maintainers\"\n              values={{\n                maintainersLink: (\n                  <a href=\"https://github.com/helm/helm/blob/main/OWNERS\">\n                    <Translate\n                      id=\"home.support.maintainersLink\"\n                      description=\"Core maintainers link text\"\n                    >\n                      many other wonderful helm core maintainers\n                    </Translate>\n                  </a>\n                ),\n              }}\n            >\n              {\"...and {maintainersLink}.\"}\n            </Translate>\n          </p>\n        </div>\n      </div>\n    </section>\n  );\n}\n"
  },
  {
    "path": "src/components/HomeSupport/styles.module.css",
    "content": "/* Component has no specific styles - uses shared home module styles */\n\n/* Maintainers text styling */\n.maintainersText {\n  font-size: 1.25rem;\n}\n\n/* Logo wall styling using flexbox with viewport-based sizing */\n.logoGrid {\n  display: flex;\n  flex-wrap: wrap;\n  justify-content: center;\n  align-items: center;\n  gap: max(1vw, 0.75rem);\n  margin: 2rem 0;\n}\n\n.logoItem {\n  display: flex;\n  align-items: center;\n  justify-content: center;\n  height: max(12vw, 120px);\n  width: max(18vw, 200px);\n  min-width: 200px;\n  flex: 0 0 max(18vw, 200px);\n  transition: transform 0.2s ease;\n}\n\n.logoItem:hover {\n  transform: scale(1.15);\n  z-index: 1;\n}\n\n.logoImage {\n  max-height: max(12vw, 120px);\n  max-width: max(18vw, 200px);\n  width: auto;\n  height: auto;\n  object-fit: contain;\n}\n\n/* Large desktop optimization */\n@media (min-width: 1400px) {\n  .logoGrid {\n    max-width: 1400px;\n    margin: 2rem auto;\n  }\n\n  .logoItem {\n    height: 160px;\n    width: 280px;\n    flex: 0 0 280px;\n  }\n\n  .logoImage {\n    max-height: 160px;\n    max-width: 280px;\n  }\n}\n\n/* Mobile optimization */\n@media (max-width: 768px) {\n  .logoGrid {\n    gap: max(2vw, 0.5rem);\n  }\n\n  .logoItem {\n    height: max(15vw, 100px);\n    width: max(40vw, 150px);\n    min-width: 150px;\n    flex: 0 0 max(40vw, 150px);\n  }\n\n  .logoItem:hover {\n    transform: scale(1.1);\n  }\n\n  .logoImage {\n    max-height: max(15vw, 100px);\n    max-width: max(40vw, 150px);\n  }\n}"
  },
  {
    "path": "src/css/announcement-bar.css",
    "content": ":root {\n  /* set custom var for announcement bar height because\n  --docusaurus-announcement-bar-height var is not properly overridden from here\n  during yarn build/serve, eve with !important. use this custom var in\n  announcement-bar.css until a better solution is found. */\n  --helm-announcement-bar-height: 5rem;\n}\n\n/* Position the announcement bar fixed below the navbar and keep it within the body border */\n.theme-announcement-bar {\n  position: fixed;\n  top: var(--ifm-navbar-height);\n  left: 0;\n  right: 0;\n  /* z-index 1 beneath boat badge */\n  z-index: calc(var(--ifm-z-index-fixed) - 2);\n  box-sizing: border-box;\n  /* Honor the site's body border visually */\n  margin-inline: var(--helm-body-border);\n  /* we must override the default announcement bar height here for yarn build/serve */\n  height: var(--helm-announcement-bar-height);\n}\n\n[class*=\"announcementBarContent\"] {\n  font-size: inherit;\n}\n\n/* Ensure the close button stays on the right and retains its padding */\n.theme-announcement-bar .close {\n  /* center the icon vertically within the button */\n  align-items: center;\n  opacity: 0.5;\n  padding: 1rem;\n  transition: opacity var(--ifm-transition-fast)\n    var(--ifm-transition-timing-default);\n  /* keep light, assuming announcement bar config will be a medium to dark color. eg, --navy: \"#0f1689\" */\n  color: var(--ifm-color-white);\n}\n\n.theme-announcement-bar .close:hover {\n  opacity: 1;\n}\n\n/* bump content down when announcement is present */\n.theme-announcement-bar + .navbar + .main-wrapper {\n  margin-top: var(--helm-announcement-bar-height);\n}\n\n/* offset the sidebar viewport when announcement is present */\n@media (min-width: 997px) {\n  #__docusaurus:has(.theme-announcement-bar) .theme-doc-sidebar-container {\n    margin-top: calc(-1 * calc(var(--ifm-navbar-height) + var(--helm-announcement-bar-height)));\n  }\n\n  /* target sidebar menu on both docs and blog with announcement bar */\n  #__docusaurus:has(.theme-announcement-bar) [class*=\"sidebarViewport\"] .thin-scrollbar {\n    padding-top: var(--ifm-navbar-height);\n  }\n\n  /* bottom of docs scrollbar when docusaurus adds this class with js */\n  #__docusaurus:has(.theme-announcement-bar) [class*=\"menuWithAnnouncementBar\"] {\n    margin-bottom: 0px;\n  }\n}\n\n/* bump TOC on desktop down when announcement is present */\n#__docusaurus:has(.theme-announcement-bar) .theme-doc-toc-desktop,\n#__docusaurus:has(.theme-announcement-bar) [class*=\"tableOfContents\"] {\n  top: calc(var(--ifm-navbar-height) + 1rem + var(--helm-announcement-bar-height));\n}\n\n#__docusaurus:has(.theme-announcement-bar) [class*=\"tableOfContents\"] {\n  max-height: calc(100vh - (var(--ifm-navbar-height) + 2rem + var(--helm-announcement-bar-height)));\n}\n\n/* fix headers visually cut off by announcement bar */\n#__docusaurus:has(.theme-announcement-bar) .anchor {\n  scroll-margin-top: calc(var(--ifm-navbar-height) + 2rem + var(--helm-announcement-bar-height));\n}\n"
  },
  {
    "path": "src/css/content.css",
    "content": "/* Float right with sensible sizing and margins; text wraps around */\n.float-right {\n  float: right;\n  margin: 0 0 1rem 1rem;\n  max-width: 420px;\n  width: 50%;\n}\n\n/* Float left variant */\n.float-left {\n  float: left;\n  margin: 0 1rem 1rem 0;\n  max-width: 420px;\n  width: 50%;\n}\n\n/* Mobile: disable float and make the image full-width for readability */\n@media (max-width: 768px) {\n  .float-right,\n  .float-left {\n    float: none;\n    display: block;\n    width: 100%;\n    max-width: 100%;\n    margin: 0 0 1rem 0;\n  }\n}\n\n/* Optional: ensure images don’t overflow their container */\n.float-right img,\n.float-left img {\n  max-width: 100%;\n  height: auto;\n}\n\n/* Optional clear utility: add where you want to stop wrapping below */\n.clear-wrap {\n  clear: both;\n}\n\n.breaking {\n  color: red;\n  font-weight: bold;\n}\n\n.breaking::before {\n  content: \"⚠️\";\n  margin-right: 0.25rem;\n}\n\n/* Target the \"Date\" column to fit content */\n.docs-doc-id-changelog table th:nth-child(2),\n.docs-doc-id-changelog table td:nth-child(2) {\n  white-space: nowrap; /* Prevent wrapping */\n  width: auto; /* Adjust width to fit content */\n}\n\n/* Target the \"Title\" column to wrap content */\n.docs-doc-id-changelog table th:nth-child(4),\n.docs-doc-id-changelog table td:nth-child(4) {\n  word-wrap: break-word; /* Allow long words to break */\n  white-space: normal; /* Allow normal wrapping */\n  width: 100%; /* Take up remaining available width */\n}\n"
  },
  {
    "path": "src/css/custom.css",
    "content": "/* Import component-specific stylesheets */\n@import './fonts.css';\n@import './main.css';\n@import './announcement-bar.css';\n@import './navbar.css';\n@import './content.css';\n@import './footer.css';\n\n/* You can override the default Infima variables here. */\n:root {\n  /* Helm style guide colors https://github.com/helm/community/tree/main/art */\n\n  /* Primary */\n  --navy: #0f1689;\n\n  /* Secondary */\n  --blue-dark: #090e6f;\n  --blue-light: #1b53c2;\n\n  /* Shades */\n  --shade-dark: #050843;\n  --shade-mid: #b7c2e9;\n  --shade-light: #dbe1f3;\n\n  /* Accents */\n  --accent-blue: #3b82bf;\n  --accent-green: #2f84a7;\n  --accent-red: #95297c;\n  --accent-yellow: #d1aa9b;\n\n  /* Additional colors not in style guide */\n  --light: #e5e5e5;\n  --grey: #4e4e4e;\n  --salmon: #f8dcdf;\n  --shade-green-bright: #2ba0d3;\n\n  --ifm-color-primary: var(--navy);\n  --ifm-color-primary-dark: var(--navy);\n  --ifm-color-primary-darker: var(--blue-dark);\n  --ifm-color-primary-darkest: var(--blue-dark);\n  --ifm-color-primary-light: var(--blue-light);\n  --ifm-color-primary-lighter: var(--blue-light);\n  --ifm-color-primary-lightest: var(--blue-light);\n\n  /* font */\n  --ifm-code-font-size: 95%;\n  --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);\n  --ifm-font-family-base: \"Public Sans\", Helvetica, Arial, sans-serif;\n  --ifm-heading-font-family: \"Space Mono\", \"Courier New\", monaco, monospace;\n  --ifm-heading-font-weight: 700;\n\n  /* links */\n  --ifm-link-color: var(--shade-green-bright);\n  --ifm-link-hover-color: var(--shade-green-bright);\n\n  /* headers */\n  --ifm-heading-color: var(--navy);\n\n  /* global navbar style (needed elsewhere) */\n  --ifm-navbar-height: 5.5rem;\n\n  /* custom site vars */\n  --helm-body-border: 8px;\n}\n"
  },
  {
    "path": "src/css/fonts.css",
    "content": "/* Local font declarations for Helm website */\n\n/* Space Mono - Regular */\n@font-face {\n  font-family: 'Space Mono';\n  src: url('/fonts/spacemono-regular-webfont.woff2') format('woff2'),\n       url('/fonts/spacemono-regular-webfont.woff') format('woff');\n  font-weight: 400;\n  font-style: normal;\n  font-display: swap;\n}\n\n/* Space Mono - Bold */\n@font-face {\n  font-family: 'Space Mono';\n  src: url('/fonts/spacemono-bold-webfont.woff2') format('woff2'),\n       url('/fonts/spacemono-bold-webfont.woff') format('woff');\n  font-weight: 700;\n  font-style: normal;\n  font-display: swap;\n}\n\n/* Public Sans - Regular */\n@font-face {\n  font-family: 'Public Sans';\n  src: url('/fonts/publicsans-regular-webfont.woff2') format('woff2'),\n       url('/fonts/publicsans-regular-webfont.woff') format('woff');\n  font-weight: 400;\n  font-style: normal;\n  font-display: swap;\n}\n\n/* Public Sans - Medium */\n@font-face {\n  font-family: 'Public Sans';\n  src: url('/fonts/publicsans-medium-webfont.woff2') format('woff2'),\n       url('/fonts/publicsans-medium-webfont.woff') format('woff');\n  font-weight: 500;\n  font-style: normal;\n  font-display: swap;\n}\n"
  },
  {
    "path": "src/css/footer.css",
    "content": ".footer--dark {\n  --ifm-footer-color: var(--shade-mid);\n  --ifm-footer-background-color: var(--navy);\n  --ifm-footer-link-color: var(--shade-green-bright);\n  --ifm-footer-link-hover-color: var(--shade-green-bright);\n}\n\n/* Enhanced background with blend mode for supported browsers */\n@supports (background-blend-mode: color-burn) {\n  @media screen and (min-width: 769px) {\n    .footer--dark {\n      background: url(\"/img/topography.png\"), var(--navy);\n      background-blend-mode: color-burn;\n      background-attachment: fixed;\n    }\n  }\n}\n\n.footer__links,\n.footer__title,\n.footer__bottom {\n  font-family: var(--ifm-heading-font-family);\n}\n\n.footer__bottom {\n    padding: 2rem 0;\n}\n"
  },
  {
    "path": "src/css/home-cards.module.css",
    "content": "/* Card styles shared by multiple home module components */\n\n/* Card column styling */\n.col {\n  margin-bottom: var(--ifm-card-vertical-spacing);\n}\n\n/* Card base styling */\n.card {\n  height: 100%;\n}\n\n/* Card header styling */\n.card__header {\n  text-align: center;\n}\n\n.card__header h3 {\n  font-size: 1.5rem;\n}\n\n/* Card images */\n.card img {\n  max-width: 100%;\n  height: auto;\n  border-radius: var(--ifm-global-radius);\n}\n"
  },
  {
    "path": "src/css/home-sections.module.css",
    "content": "/* Section styles shared by multiple home module components */\n\n/* Base section styling */\n.section {\n  padding: 2rem 0;\n  width: 100%;\n  display: flex;\n  align-items: center;\n}\n\n/* Section headers */\n.section h2 {\n  font-size: 2.25rem;\n  text-align: center;\n}\n\n.section h2 + div,\n.section h2 + p + div {\n  margin-top: 3rem;\n}\n\n.section h2 + p {\n  text-align: center;\n  font-size: 1.25rem;\n  margin-bottom: 1rem;\n}\n\n/* Light sections (pattern background, navy text) */\n.sectionLight {\n  color: var(--navy);\n}\n\n.sectionLight h2,\n.sectionLight h3,\n.sectionLight h4 {\n  color: var(--navy);\n}\n\n/* Dark sections (blue pattern background, white text) */\n.sectionDark {\n  background: var(--navy);\n  color: white;\n}\n\n/* Enhanced background with blend mode for supported browsers */\n@supports (background-blend-mode: color-burn) {\n  @media screen and (min-width: 769px) {\n    .sectionDark {\n      background: url(\"/img/topography.png\"), var(--navy);\n      background-blend-mode: color-burn;\n      background-attachment: fixed;\n    }\n  }\n}\n\n.sectionDark h2,\n.sectionDark h3,\n.sectionDark h4 {\n  color: var(--ifm-color-white);\n}\n\n.sectionDark :global(code) {\n  background-color: inherit;\n}\n\n/* Card styles for light sections */\n.sectionLight :global(.card) {\n  --ifm-card-background-color: var(--ifm-background-surface-color);\n  box-shadow: 0 5px 12px var(--ifm-color-secondary-dark);\n}\n\n/* Card styles for dark sections */\n.sectionDark :global(.card) {\n  --ifm-card-background-color: var(--shade-dark);\n  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.2);\n}\n"
  },
  {
    "path": "src/css/main.css",
    "content": "/**\n * Any CSS included here will be global. The classic template\n * bundles Infima by default. Infima is a CSS framework designed to\n * work well for content-centric websites.\n */\n\n@import url(\"https://fonts.googleapis.com/css2?family=Space+Mono:ital,wght@0,400;0,700;1,400;1,700&display=swap\");\n@import url(\"https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css\");\n\nbody {\n  /* needed for border to fit content instead of initial viewport */\n  height: fit-content !important;\n  border: var(--helm-body-border) solid var(--navy);\n}\n\n/* background image */\nbody::before {\n  content: \"\";\n  position: fixed;\n  top: 0;\n  left: 0;\n  width: 100%;\n  height: 100%;\n  background-image: url(\"/img/topography.png\");\n  background-repeat: repeat;\n  z-index: -1;\n  pointer-events: none;\n}\n\nmain:not(.home) {\n  background: white;\n}\n\n/* fix headers visually cut off by navbar */\n.anchor {\n  scroll-margin-top: calc(var(--ifm-navbar-height) + 2rem);\n}\n"
  },
  {
    "path": "src/css/navbar.css",
    "content": ".navbar--fixed-top {\n  /* Restore background image so content flows \"beneath\" it */\n  background-image: url(\"/img/topography.png\");\n  background-repeat: repeat;\n  /* To get -8px we have to use calc, because -var(--name) doesn't work */\n  background-position: calc(-1 * var(--helm-body-border)) calc(-1 * var(--helm-body-border));\n  margin-top: calc(-1 * var(--helm-body-border));\n  border-top: var(--helm-body-border) solid var(--navy);\n}\n\n/* logo */\n.navbar__logo {\n  height: 3.5rem;\n}\n\n.navbar__logo img {\n  transition: transform var(--ifm-transition-slow) ease-in-out;\n}\n\n.navbar__logo:hover img {\n  transform: rotateZ(180deg);\n}\n\n/* logo fix on iphone. otherwise stuck upside down on click */\n@media (hover: none) {\n  .navbar__logo:hover img {\n    /* stays upright */\n    transform: rotateZ(0deg);\n    /* avoid accidental sticky states */\n    transition: none;\n  }\n}\n\n/* hide title */\n/* TODO is there a better way to hide this? */\n.navbar__title {\n  display: none;\n}\n\n/* links */\n.navbar__link {\n  --ifm-navbar-link-color: var(--navy);\n  font-family: var(--ifm-heading-font-family);\n  font-weight: var(--ifm-heading-font-weight);\n}\n"
  },
  {
    "path": "src/pages/helm-4-release-party.js",
    "content": "import Layout from \"@theme/Layout\";\nimport clsx from \"clsx\";\nimport ReplicatedLogo from \"../../static/img/helm-4-release-party/replicated_logo_red.svg\";\nimport CNCFLogo from \"../../static/img/helm-4-release-party/cncf-color.svg\";\nimport styles from \"./party.module.css\";\nimport Link from \"@docusaurus/Link\";\nimport { MdLink, MdCalendarMonth } from \"react-icons/md\";\nimport Admonition from \"@theme/Admonition\";\n\nexport default function Party() {\n  return (\n    <Layout\n      title=\"Helm 4 Release Party\"\n      description=\"The Official Helm 4 Release Party! Presented by Replicated and CNCF at KubeCon Atlanta, 2025\"\n    >\n      <main className={styles.party}>\n        <div className=\"row\">\n          <div className={clsx(\"col col--6\", styles.col, styles.logocol)}>\n            <ReplicatedLogo className={styles.svgauto} />\n          </div>\n          <div className={clsx(\"col col--6\", styles.col, styles.logocol)}>\n            <CNCFLogo className={styles.svgauto} />\n          </div>\n        </div>\n        <div className=\"row\">\n          <div className={clsx(\"col\", styles.col)}>\n            <h2>Present:</h2>\n          </div>\n        </div>\n        <div className=\"row\">\n          <div className={clsx(\"col col--6\", styles.hazelcol)}>\n            <img\n              className={styles.hazel}\n              alt=\"Hazel 1\"\n              src=\"/img/helm-4-release-party/hazel_1.svg\"\n            />\n            <img\n              className={styles.hazel}\n              alt=\"Hazel 2\"\n              src=\"/img/helm-4-release-party/hazel_2.svg\"\n            />\n          </div>\n          <div className={clsx(\"col col--6\", styles.hazelcol)}>\n            <img\n              className={styles.hazel}\n              alt=\"Hazel 3\"\n              src=\"/img/helm-4-release-party/hazel_3.svg\"\n            />\n            <img\n              className={styles.hazel}\n              alt=\"Hazel 4\"\n              src=\"/img/helm-4-release-party/hazel_4.svg\"\n            />\n          </div>\n        </div>\n        <div className=\"row\">\n          <div className={clsx(\"col\", styles.col)}>\n            <h1>The Official Helm 4 Release Party!</h1>\n            <h2>Wed, Nov 12 from 6-9 PM</h2>\n            <h3>Max Lager’s Wood-fired Grill & Brewery</h3>\n            <h3>320 Peachtree Rd NE, Atlanta, GA 30308</h3>\n            <h3>(~1 mile from the conference)</h3>\n          </div>\n        </div>\n        <div className={clsx(\"row\", styles.bottomrow)}>\n          <div className={clsx(\"col col--6\", styles.col, styles.menucol)}>\n            <h2>Menu</h2>\n            <p>\n              Low-country Boil w/ Lobster, Shrimp, Beef Sausage, Corn on Cob,\n              Potatoes\n            </p>\n            <p>Pasta D’Avellino (vegetarian)</p>\n            <p>Premium Open Bar</p>\n          </div>\n          <div className={clsx(\"col col--6\", styles.col)}>\n            <h2>\n              <Link href=\"https://replicated.typeform.com/helmparty\">\n                <MdLink className={styles.icon} />\n                RSVP Required\n              </Link>\n            </h2>\n            <Link href=\"https://replicated.typeform.com/helmparty\">\n              <img\n                alt=\"Hazel 3\"\n                src=\"/img/helm-4-release-party/helm_qr_code.svg\"\n                className={styles.svgauto}\n              />\n            </Link>\n          </div>\n        </div>\n\n        <div className=\"row\">\n          <div className={clsx(\"col\", styles.col, styles.calendarcol)}>\n            <Admonition\n              className={styles.calendarlink}\n              type=\"info\"\n              title={null}\n              icon={null}\n            >\n              <h3>\n                <Link href=\"/blog/helm-at-kubecon-na-25\">\n                  <MdCalendarMonth className={styles.icon} />\n                  See the full list of Helm events @ KubeCon + CloudNativeCon NA\n                  '25\n                </Link>\n              </h3>\n            </Admonition>\n          </div>\n        </div>\n      </main>\n    </Layout>\n  );\n}\n"
  },
  {
    "path": "src/pages/index.js",
    "content": "import Link from \"@docusaurus/Link\";\nimport useDocusaurusContext from \"@docusaurus/useDocusaurusContext\";\nimport Layout from \"@theme/Layout\";\nimport HomeHeader from \"@site/src/components/HomeHeader\";\nimport HomeAbout from \"@site/src/components/HomeAbout\";\nimport HomeFeatures from \"@site/src/components/HomeFeatures\";\nimport HomeGettingStarted from \"@site/src/components/HomeGettingStarted\";\nimport HomeCommunity from \"@site/src/components/HomeCommunity\";\nimport HomeSupport from \"@site/src/components/HomeSupport\";\n\nexport default function Home() {\n  const { siteConfig } = useDocusaurusContext();\n  return (\n    <Layout title={`${siteConfig.title}`} description={`${siteConfig.tagline}`}>\n      <HomeHeader />\n      <main className=\"home\">\n        <HomeAbout />\n        <HomeFeatures />\n        <HomeGettingStarted />\n        <HomeCommunity />\n        <HomeSupport />\n      </main>\n    </Layout>\n  );\n}\n"
  },
  {
    "path": "src/pages/index.module.css",
    "content": "/**\n * CSS files with the .module.css suffix will be treated as CSS modules\n * and scoped locally.\n */\n"
  },
  {
    "path": "src/pages/markdown-page.md",
    "content": "---\ntitle: Markdown page example\n---\n\n# Markdown page example\n\nYou don't need React to write simple standalone pages.\n"
  },
  {
    "path": "src/pages/party.module.css",
    "content": "/**\n * CSS files with the .module.css suffix will be treated as CSS modules\n * and scoped locally.\n */\n\nmain.party {\n  padding: 2rem;\n}\n\nmain.party h1 {\n  font-size: 3rem;\n}\n\nmain.party h2,\n.col p {\n  font-size: 2rem;\n}\n\nmain.party h3 {\n  font-size: 1.5rem;\n}\n\n.svgauto {\n  width: 100%;\n  height: auto;\n}\n\n.col {\n  text-align: center;\n  padding: 2rem;\n}\n\n.logocol {\n  padding-bottom: 0;\n}\n\n.hazelcol {\n  padding-top: 0;\n  padding-bottom: 0;\n}\n\n.hazel {\n  width: 50%;\n  height: auto;\n}\n\n.menucol {\n  border: 2px solid var(--ifm-link-color);\n  border-radius: var(--ifm-card-border-radius);\n}\n\n.bottomrow {\n  margin-top: 1rem;\n}\n\n.bottomrow .col {\n  --ifm-col-width: 100%;\n}\n\n.calendarcol {\n  padding-top: 0;\n}\n\n.calendarlink {\n  margin-bottom: 0;\n}\n\n@media (min-width: 576px) {\n  .bottomrow .col {\n    --ifm-col-width: calc(6 / 12 * 100%);\n  }\n\n  .calendarcol {\n    padding-top: 2rem;\n  }\n\n  .calendarlink {\n    margin-top: 1rem;\n  }\n}\n\n/* See HomeCommunity component styles */\n.icon {\n  vertical-align: middle;\n  margin-right: 0.5rem;\n  font-size: 1.2em;\n}\n"
  },
  {
    "path": "src/theme/Blog/Pages/BlogAuthorsListPage/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport {\n  PageMetadata,\n  HtmlClassNameProvider,\n  ThemeClassNames,\n} from '@docusaurus/theme-common';\nimport {translateBlogAuthorsListPageTitle} from '@docusaurus/theme-common/internal';\nimport BlogLayout from '@theme/BlogLayout';\nimport SearchMetadata from '@theme/SearchMetadata';\nimport Heading from '@theme/Heading';\nimport Author from '@theme/Blog/Components/Author';\nimport BlogAuthorsListBreadcrumbs from '@theme/BlogAuthorsListBreadcrumbs';\nimport styles from './styles.module.css';\nfunction AuthorListItem({author}) {\n  return (\n    <li className={styles.authorListItem}>\n      <Author as=\"h2\" author={author} count={author.count} />\n    </li>\n  );\n}\nfunction AuthorsList({authors}) {\n  return (\n    <section className={clsx('margin-vert--lg', styles.authorsListSection)}>\n      <ul>\n        {authors.map((author) => (\n          <AuthorListItem key={author.key} author={author} />\n        ))}\n      </ul>\n    </section>\n  );\n}\nexport default function BlogAuthorsListPage({authors, sidebar}) {\n  const title = translateBlogAuthorsListPageTitle();\n  return (\n    <HtmlClassNameProvider\n      className={clsx(\n        ThemeClassNames.wrapper.blogPages,\n        ThemeClassNames.page.blogAuthorsListPage,\n      )}>\n      <PageMetadata title={title} />\n      <SearchMetadata tag=\"blog_authors_list\" />\n      <BlogLayout sidebar={sidebar}>\n        <BlogAuthorsListBreadcrumbs />\n        <Heading as=\"h1\">{title}</Heading>\n        <AuthorsList authors={authors} />\n      </BlogLayout>\n    </HtmlClassNameProvider>\n  );\n}\n"
  },
  {
    "path": "src/theme/Blog/Pages/BlogAuthorsListPage/styles.module.css",
    "content": ".authorListItem {\n  list-style-type: none;\n  margin-bottom: 2rem;\n}\n"
  },
  {
    "path": "src/theme/Blog/Pages/BlogAuthorsPostsPage/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport {\n  PageMetadata,\n  HtmlClassNameProvider,\n  ThemeClassNames,\n} from '@docusaurus/theme-common';\nimport {\n  useBlogAuthorPageTitle,\n  BlogAuthorsListViewAllLabel,\n  BlogAuthorNoPostsLabel,\n} from '@docusaurus/theme-common/internal';\nimport Link from '@docusaurus/Link';\nimport {useBlogMetadata} from '@docusaurus/plugin-content-blog/client';\nimport BlogLayout from '@theme/BlogLayout';\nimport BlogListPaginator from '@theme/BlogListPaginator';\nimport SearchMetadata from '@theme/SearchMetadata';\nimport BlogPostItems from '@theme/BlogPostItems';\nimport Author from '@theme/Blog/Components/Author';\nimport BlogAuthorsPostsBreadcrumbs from '@theme/BlogAuthorsPostsBreadcrumbs';\nfunction Metadata({author}) {\n  const title = useBlogAuthorPageTitle(author);\n  return (\n    <>\n      <PageMetadata title={title} />\n      <SearchMetadata tag=\"blog_authors_posts\" />\n    </>\n  );\n}\nfunction ViewAllAuthorsLink() {\n  const {authorsListPath} = useBlogMetadata();\n  return (\n    <Link href={authorsListPath}>\n      <BlogAuthorsListViewAllLabel />\n    </Link>\n  );\n}\nfunction Content({author, items, sidebar, listMetadata}) {\n  return (\n    <BlogLayout sidebar={sidebar}>\n      <BlogAuthorsPostsBreadcrumbs author={author} />\n      <header className=\"margin-bottom--xl\">\n        <Author as=\"h1\" author={author} />\n        {author.description && <p>{author.description}</p>}\n        <ViewAllAuthorsLink />\n      </header>\n      {items.length === 0 ? (\n        <p>\n          <BlogAuthorNoPostsLabel />\n        </p>\n      ) : (\n        <>\n          <hr />\n          <BlogPostItems items={items} />\n          <BlogListPaginator metadata={listMetadata} />\n        </>\n      )}\n    </BlogLayout>\n  );\n}\nexport default function BlogAuthorsPostsPage(props) {\n  return (\n    <HtmlClassNameProvider\n      className={clsx(\n        ThemeClassNames.wrapper.blogPages,\n        ThemeClassNames.page.blogAuthorsPostsPage,\n      )}>\n      <Metadata {...props} />\n      <Content {...props} />\n    </HtmlClassNameProvider>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogAuthorsListBreadcrumbs/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport Link from '@docusaurus/Link';\nimport useBaseUrl from '@docusaurus/useBaseUrl';\nimport {translate} from '@docusaurus/Translate';\nimport {ThemeClassNames} from '@docusaurus/theme-common';\nimport {translateBlogAuthorsListPageTitle} from '@docusaurus/theme-common/internal';\nimport {useBlogMetadata} from '@docusaurus/plugin-content-blog/client';\nimport IconHome from '@theme/Icon/Home';\nimport styles from './styles.module.css';\n\nexport default function BlogAuthorsListBreadcrumbs() {\n  const homeHref = useBaseUrl('/');\n  const {blogBasePath} = useBlogMetadata();\n\n  return (\n    <nav className={clsx(ThemeClassNames.docs.docBreadcrumbs, styles.breadcrumbsContainer)} aria-label=\"breadcrumbs\">\n      <ul className=\"breadcrumbs\" itemScope itemType=\"https://schema.org/BreadcrumbList\">\n        <li className=\"breadcrumbs__item\">\n          <Link\n            aria-label={translate({\n              id: 'theme.docs.breadcrumbs.home',\n              message: 'Home page',\n              description: 'The ARIA label for the home page in the breadcrumbs',\n            })}\n            className=\"breadcrumbs__link\"\n            href={homeHref}\n            itemProp=\"item\"\n          >\n            <IconHome className={styles.breadcrumbHomeIcon} />\n          </Link>\n          <meta itemProp=\"position\" content=\"1\" />\n        </li>\n        <li className=\"breadcrumbs__item\">\n          <Link\n            className=\"breadcrumbs__link\"\n            href={useBaseUrl(blogBasePath)}\n            itemProp=\"item\"\n          >\n            <span itemProp=\"name\">\n              {translate({\n                id: 'theme.blog.list.pageTitle',\n                message: 'Blog',\n                description: 'The word \"Blog\" in breadcrumbs'\n              })}\n            </span>\n          </Link>\n          <meta itemProp=\"position\" content=\"2\" />\n        </li>\n        <li className=\"breadcrumbs__item breadcrumbs__item--active\">\n          <span className=\"breadcrumbs__link\" itemProp=\"name\">\n            {translateBlogAuthorsListPageTitle()}\n          </span>\n          <meta itemProp=\"position\" content=\"3\" />\n        </li>\n      </ul>\n    </nav>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogAuthorsListBreadcrumbs/styles.module.css",
    "content": ".breadcrumbsContainer {\n  --ifm-breadcrumb-size-multiplier: 0.8;\n  margin-bottom: 0.8rem;\n}\n\n.breadcrumbHomeIcon {\n  position: relative;\n  top: 1px;\n  vertical-align: top;\n  height: 1.1rem;\n  width: 1.1rem;\n}\n"
  },
  {
    "path": "src/theme/BlogAuthorsPostsBreadcrumbs/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport Link from '@docusaurus/Link';\nimport useBaseUrl from '@docusaurus/useBaseUrl';\nimport {translate} from '@docusaurus/Translate';\nimport {ThemeClassNames} from '@docusaurus/theme-common';\nimport {translateBlogAuthorsListPageTitle} from '@docusaurus/theme-common/internal';\nimport {useBlogMetadata} from '@docusaurus/plugin-content-blog/client';\nimport IconHome from '@theme/Icon/Home';\nimport styles from './styles.module.css';\n\nexport default function BlogAuthorsPostsBreadcrumbs({author}) {\n  const homeHref = useBaseUrl('/');\n  const {blogBasePath, authorsListPath} = useBlogMetadata();\n\n  return (\n    <nav className={clsx(ThemeClassNames.docs.docBreadcrumbs, styles.breadcrumbsContainer)} aria-label=\"breadcrumbs\">\n      <ul className=\"breadcrumbs\" itemScope itemType=\"https://schema.org/BreadcrumbList\">\n        <li className=\"breadcrumbs__item\">\n          <Link\n            aria-label={translate({\n              id: 'theme.docs.breadcrumbs.home',\n              message: 'Home page',\n              description: 'The ARIA label for the home page in the breadcrumbs',\n            })}\n            className=\"breadcrumbs__link\"\n            href={homeHref}\n            itemProp=\"item\"\n          >\n            <IconHome className={styles.breadcrumbHomeIcon} />\n          </Link>\n          <meta itemProp=\"position\" content=\"1\" />\n        </li>\n        <li className=\"breadcrumbs__item\">\n          <Link\n            className=\"breadcrumbs__link\"\n            href={useBaseUrl(blogBasePath)}\n            itemProp=\"item\"\n          >\n            <span itemProp=\"name\">\n              {translate({\n                id: 'theme.blog.list.pageTitle',\n                message: 'Blog',\n                description: 'The word \"Blog\" in breadcrumbs'\n              })}\n            </span>\n          </Link>\n          <meta itemProp=\"position\" content=\"2\" />\n        </li>\n        <li className=\"breadcrumbs__item\">\n          <Link\n            className=\"breadcrumbs__link\"\n            href={useBaseUrl(authorsListPath)}\n            itemProp=\"item\"\n          >\n            <span itemProp=\"name\">\n              {translateBlogAuthorsListPageTitle()}\n            </span>\n          </Link>\n          <meta itemProp=\"position\" content=\"3\" />\n        </li>\n        <li className=\"breadcrumbs__item breadcrumbs__item--active\">\n          <span className=\"breadcrumbs__link\" itemProp=\"name\">\n            {author.name}\n          </span>\n          <meta itemProp=\"position\" content=\"4\" />\n        </li>\n      </ul>\n    </nav>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogAuthorsPostsBreadcrumbs/styles.module.css",
    "content": ".breadcrumbsContainer {\n  --ifm-breadcrumb-size-multiplier: 0.8;\n  margin-bottom: 0.8rem;\n}\n\n.breadcrumbHomeIcon {\n  position: relative;\n  top: 1px;\n  vertical-align: top;\n  height: 1.1rem;\n  width: 1.1rem;\n}\n"
  },
  {
    "path": "src/theme/BlogBreadcrumbs/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport Link from '@docusaurus/Link';\nimport useBaseUrl from '@docusaurus/useBaseUrl';\nimport {translate} from '@docusaurus/Translate';\nimport {useBlogPost} from '@docusaurus/plugin-content-blog/client';\nimport {ThemeClassNames} from '@docusaurus/theme-common';\nimport IconHome from '@theme/Icon/Home';\nimport styles from './styles.module.css';\n\nexport default function BlogBreadcrumbs() {\n  const {metadata} = useBlogPost();\n  const {title, permalink} = metadata;\n  const homeHref = useBaseUrl('/');\n\n  return (\n    <nav className={clsx(ThemeClassNames.docs.docBreadcrumbs, styles.breadcrumbsContainer)} aria-label=\"breadcrumbs\">\n      <ul className=\"breadcrumbs\" itemScope itemType=\"https://schema.org/BreadcrumbList\">\n        <li className=\"breadcrumbs__item\">\n          <Link\n            aria-label={translate({\n              id: 'theme.docs.breadcrumbs.home',\n              message: 'Home page',\n              description: 'The ARIA label for the home page in the breadcrumbs',\n            })}\n            className=\"breadcrumbs__link\"\n            href={homeHref}\n            itemProp=\"item\"\n          >\n            <IconHome className={styles.breadcrumbHomeIcon} />\n          </Link>\n          <meta itemProp=\"position\" content=\"1\" />\n        </li>\n        <li className=\"breadcrumbs__item\">\n          <Link\n            className=\"breadcrumbs__link\"\n            to=\"/blog\"\n            itemProp=\"item\"\n          >\n            <span itemProp=\"name\">\n              {translate({\n                id: 'theme.blog.list.pageTitle',\n                message: 'Blog',\n                description: 'The word \"Blog\" in breadcrumbs'\n              })}\n            </span>\n          </Link>\n          <meta itemProp=\"position\" content=\"2\" />\n        </li>\n        <li className=\"breadcrumbs__item breadcrumbs__item--active\">\n          <span className=\"breadcrumbs__link\" itemProp=\"name\">\n            {title}\n          </span>\n          <meta itemProp=\"position\" content=\"3\" />\n        </li>\n      </ul>\n    </nav>\n  );\n}"
  },
  {
    "path": "src/theme/BlogBreadcrumbs/styles.module.css",
    "content": ".breadcrumbsContainer {\n  --ifm-breadcrumb-size-multiplier: 0.8;\n  margin-bottom: 0.8rem;\n}\n\n.breadcrumbHomeIcon {\n  position: relative;\n  top: 1px;\n  vertical-align: top;\n  height: 1.1rem;\n  width: 1.1rem;\n}"
  },
  {
    "path": "src/theme/BlogLayout/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport Layout from '@theme/Layout';\nimport BlogSidebar from '@theme/BlogSidebar';\nimport {ThemeClassNames, useWindowSize} from '@docusaurus/theme-common';\nimport BackToTopButton from '@theme/BackToTopButton';\nimport TOC from '@theme/TOC';\nimport TOCCollapsible from '@theme/TOCCollapsible';\nimport styles from './styles.module.css';\n\n// Create mobile and desktop TOC like docs do\nfunction useBlogTOC(toc, frontMatter = {}) {\n  const windowSize = useWindowSize();\n  const hidden = frontMatter.hide_table_of_contents;\n  const canRender = !hidden && toc && toc.length > 0;\n\n  const mobile = canRender ? (\n    <TOCCollapsible\n      toc={toc}\n      minHeadingLevel={frontMatter.toc_min_heading_level}\n      maxHeadingLevel={frontMatter.toc_max_heading_level}\n      className={clsx(ThemeClassNames.docs.docTocMobile, styles.tocMobile)}\n    />\n  ) : undefined;\n\n  const desktop = canRender && (windowSize === 'desktop' || windowSize === 'ssr') ? (\n    <TOC\n      toc={toc}\n      minHeadingLevel={frontMatter.toc_min_heading_level}\n      maxHeadingLevel={frontMatter.toc_max_heading_level}\n    />\n  ) : undefined;\n\n  return { hidden, mobile, desktop };\n}\n\nexport default function BlogLayout(props) {\n  const {sidebar, toc, children, frontMatter, ...layoutProps} = props;\n  const hasSidebar = sidebar && sidebar.items.length > 0;\n  const blogTOC = useBlogTOC(toc, frontMatter);\n\n  return (\n    <Layout {...layoutProps}>\n      <div className={styles.docsWrapper}>\n        <BackToTopButton />\n        <div className={styles.docRoot}>\n          {hasSidebar && (\n            <aside\n              className={clsx(\n                ThemeClassNames.docs.docSidebarContainer,\n                styles.docSidebarContainer,\n              )}>\n              <div className={styles.sidebarViewport}>\n                <BlogSidebar sidebar={sidebar} />\n              </div>\n            </aside>\n          )}\n          <main\n            className={clsx(\n              styles.docMainContainer,\n              !hasSidebar && styles.docMainContainerEnhanced,\n            )}>\n            <div\n              className={clsx(\n                'container padding-top--md padding-bottom--lg',\n                styles.docItemWrapper,\n                !hasSidebar && styles.docItemWrapperEnhanced,\n              )}>\n              <div className={clsx('row', styles.docItemRow)}>\n                <div className={clsx('col', styles.docItemCol)}>\n                  {blogTOC.mobile}\n                  {children}\n                </div>\n                {blogTOC.desktop && (\n                  <div className={clsx('col col--3', styles.tocWrapper)}>\n                    {blogTOC.desktop}\n                  </div>\n                )}\n              </div>\n            </div>\n          </main>\n        </div>\n      </div>\n    </Layout>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogLayout/styles.module.css",
    "content": "/* Blog layout styles based on docs layout structure */\n\n:root {\n  --doc-sidebar-width: 300px;\n  --doc-sidebar-hidden-width: 30px;\n}\n\n.docRoot {\n  display: flex;\n  width: 100%;\n}\n\n.docsWrapper {\n  display: flex;\n  flex: 1 0 auto;\n}\n\n.docSidebarContainer {\n  display: none;\n}\n\n@media (min-width: 997px) {\n  .docSidebarContainer {\n    display: block;\n    width: var(--doc-sidebar-width);\n    margin-top: calc(-1 * var(--ifm-navbar-height));\n    border-right: 1px solid var(--ifm-toc-border-color);\n    will-change: width;\n    transition: width var(--ifm-transition-fast) ease;\n    clip-path: inset(0);\n  }\n\n  .sidebarViewport {\n    top: 0;\n    position: sticky;\n    height: 100%;\n    max-height: 100vh;\n    overflow-y: auto;\n    padding: var(--ifm-spacing-vertical) var(--ifm-spacing-horizontal);\n  }\n}\n\n.docMainContainer {\n  display: flex;\n  width: 100%;\n}\n\n@media (min-width: 997px) {\n  .docMainContainer {\n    flex-grow: 1;\n    max-width: calc(100% - var(--doc-sidebar-width));\n  }\n\n  .docMainContainerEnhanced {\n    max-width: calc(100% - var(--doc-sidebar-hidden-width));\n  }\n\n  .docItemWrapperEnhanced {\n    max-width: calc(\n      var(--ifm-container-width) + var(--doc-sidebar-width)\n    ) !important;\n  }\n}\n\n.docItemWrapper {\n  /* Additional spacing for blog content */\n}\n\n.docItemRow {\n  /* Row containing main content + TOC */\n}\n\n.docItemCol {\n  /* Main content column - always constrained to 75% like docs */\n}\n\n@media (min-width: 997px) {\n  .docItemCol {\n    max-width: 75% !important;\n  }\n}\n\n.tocWrapper {\n  /* TOC column styling */\n}\n\n.tocMobile {\n  /* Mobile TOC styling - hidden on desktop */\n}\n\n@media (min-width: 997px) {\n  .tocMobile {\n    display: none;\n  }\n}\n\n.docItemContainer header + *,\n.docItemContainer article > *:first-child {\n  margin-top: 0;\n}"
  },
  {
    "path": "src/theme/BlogListBreadcrumbs/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport Link from '@docusaurus/Link';\nimport useBaseUrl from '@docusaurus/useBaseUrl';\nimport {translate} from '@docusaurus/Translate';\nimport {ThemeClassNames} from '@docusaurus/theme-common';\nimport IconHome from '@theme/Icon/Home';\nimport styles from './styles.module.css';\n\nexport default function BlogListBreadcrumbs() {\n  const homeHref = useBaseUrl('/');\n\n  return (\n    <nav className={clsx(ThemeClassNames.docs.docBreadcrumbs, styles.breadcrumbsContainer)} aria-label=\"breadcrumbs\">\n      <ul className=\"breadcrumbs\" itemScope itemType=\"https://schema.org/BreadcrumbList\">\n        <li className=\"breadcrumbs__item\">\n          <Link\n            aria-label={translate({\n              id: 'theme.docs.breadcrumbs.home',\n              message: 'Home page',\n              description: 'The ARIA label for the home page in the breadcrumbs',\n            })}\n            className=\"breadcrumbs__link\"\n            href={homeHref}\n            itemProp=\"item\"\n          >\n            <IconHome className={styles.breadcrumbHomeIcon} />\n          </Link>\n          <meta itemProp=\"position\" content=\"1\" />\n        </li>\n        <li className=\"breadcrumbs__item breadcrumbs__item--active\">\n          <span className=\"breadcrumbs__link\" itemProp=\"name\">\n            {translate({\n              id: 'theme.blog.list.pageTitle',\n              message: 'Blog',\n              description: 'The word \"Blog\" in breadcrumbs'\n            })}\n          </span>\n          <meta itemProp=\"position\" content=\"2\" />\n        </li>\n      </ul>\n    </nav>\n  );\n}"
  },
  {
    "path": "src/theme/BlogListBreadcrumbs/styles.module.css",
    "content": ".breadcrumbsContainer {\n  --ifm-breadcrumb-size-multiplier: 0.8;\n  margin-bottom: 0.8rem;\n}\n\n.breadcrumbHomeIcon {\n  position: relative;\n  top: 1px;\n  vertical-align: top;\n  height: 1.1rem;\n  width: 1.1rem;\n}"
  },
  {
    "path": "src/theme/BlogListPage/StructuredData/index.js",
    "content": "import React from 'react';\nimport Head from '@docusaurus/Head';\nimport {useBlogListPageStructuredData} from '@docusaurus/plugin-content-blog/client';\nexport default function BlogListPageStructuredData(props) {\n  const structuredData = useBlogListPageStructuredData(props);\n  return (\n    <Head>\n      <script type=\"application/ld+json\">\n        {JSON.stringify(structuredData)}\n      </script>\n    </Head>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogListPage/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport useDocusaurusContext from '@docusaurus/useDocusaurusContext';\nimport {\n  PageMetadata,\n  HtmlClassNameProvider,\n  ThemeClassNames,\n} from '@docusaurus/theme-common';\nimport BlogLayout from '@theme/BlogLayout';\nimport BlogListPaginator from '@theme/BlogListPaginator';\nimport SearchMetadata from '@theme/SearchMetadata';\nimport BlogPostItems from '@theme/BlogPostItems';\nimport BlogListPageStructuredData from '@theme/BlogListPage/StructuredData';\nimport BlogListBreadcrumbs from '@theme/BlogListBreadcrumbs';\nfunction BlogListPageMetadata(props) {\n  const {metadata} = props;\n  const {\n    siteConfig: {title: siteTitle},\n  } = useDocusaurusContext();\n  const {blogDescription, blogTitle, permalink} = metadata;\n  const isBlogOnlyMode = permalink === '/';\n  const title = isBlogOnlyMode ? siteTitle : blogTitle;\n  return (\n    <>\n      <PageMetadata title={title} description={blogDescription} />\n      <SearchMetadata tag=\"blog_posts_list\" />\n    </>\n  );\n}\nfunction BlogListPageContent(props) {\n  const {metadata, items, sidebar} = props;\n  return (\n    <BlogLayout sidebar={sidebar}>\n      <BlogListBreadcrumbs />\n      <BlogPostItems items={items} />\n      <BlogListPaginator metadata={metadata} />\n    </BlogLayout>\n  );\n}\nexport default function BlogListPage(props) {\n  return (\n    <HtmlClassNameProvider\n      className={clsx(\n        ThemeClassNames.wrapper.docsPages, // Use docs wrapper instead of blog\n        ThemeClassNames.page.blogListPage,\n      )}>\n      <BlogListPageMetadata {...props} />\n      <BlogListPageStructuredData {...props} />\n      <BlogListPageContent {...props} />\n    </HtmlClassNameProvider>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogPostItem/index.tsx",
    "content": "import React, {type ReactNode} from 'react';\nimport clsx from 'clsx';\nimport {useBlogPost} from '@docusaurus/plugin-content-blog/client';\nimport BlogPostItemContainer from '@theme/BlogPostItem/Container';\nimport BlogPostItemHeader from '@theme/BlogPostItem/Header';\nimport BlogPostItemContent from '@theme/BlogPostItem/Content';\nimport BlogPostItemFooter from '@theme/BlogPostItem/Footer';\nimport BlogBreadcrumbs from '@theme/BlogBreadcrumbs';\nimport type {Props} from '@theme/BlogPostItem';\n\n// apply a bottom margin in list view\nfunction useContainerClassName() {\n  const {isBlogPostPage} = useBlogPost();\n  return !isBlogPostPage ? 'margin-bottom--xl' : undefined;\n}\n\nexport default function BlogPostItem({children, className}: Props): ReactNode {\n  const {isBlogPostPage} = useBlogPost();\n  const containerClassName = useContainerClassName();\n  return (\n    <BlogPostItemContainer className={clsx(containerClassName, className)}>\n      {isBlogPostPage && <BlogBreadcrumbs />}\n      <BlogPostItemHeader />\n      <BlogPostItemContent>{children}</BlogPostItemContent>\n      <BlogPostItemFooter />\n    </BlogPostItemContainer>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogPostPage/Metadata/index.js",
    "content": "import React from 'react';\nimport {PageMetadata} from '@docusaurus/theme-common';\nimport {useBlogPost} from '@docusaurus/plugin-content-blog/client';\nexport default function BlogPostPageMetadata() {\n  const {assets, metadata} = useBlogPost();\n  const {title, description, date, tags, authors, frontMatter} = metadata;\n  const {keywords} = frontMatter;\n  const image = assets.image ?? frontMatter.image;\n  return (\n    <PageMetadata\n      title={frontMatter.title_meta ?? title}\n      description={description}\n      keywords={keywords}\n      image={image}>\n      <meta property=\"og:type\" content=\"article\" />\n      <meta property=\"article:published_time\" content={date} />\n      {/* TODO double check those article meta array syntaxes, see https://ogp.me/#array */}\n      {authors.some((author) => author.url) && (\n        <meta\n          property=\"article:author\"\n          content={authors\n            .map((author) => author.url)\n            .filter(Boolean)\n            .join(',')}\n        />\n      )}\n      {tags.length > 0 && (\n        <meta\n          property=\"article:tag\"\n          content={tags.map((tag) => tag.label).join(',')}\n        />\n      )}\n    </PageMetadata>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogPostPage/StructuredData/index.js",
    "content": "import React from 'react';\nimport Head from '@docusaurus/Head';\nimport {useBlogPostStructuredData} from '@docusaurus/plugin-content-blog/client';\nexport default function BlogPostStructuredData() {\n  const structuredData = useBlogPostStructuredData();\n  return (\n    <Head>\n      <script type=\"application/ld+json\">\n        {JSON.stringify(structuredData)}\n      </script>\n    </Head>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogPostPage/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport {HtmlClassNameProvider, ThemeClassNames} from '@docusaurus/theme-common';\nimport {\n  BlogPostProvider,\n  useBlogPost,\n} from '@docusaurus/plugin-content-blog/client';\nimport BlogLayout from '@theme/BlogLayout';\nimport BlogPostItem from '@theme/BlogPostItem';\nimport BlogPostPaginator from '@theme/BlogPostPaginator';\nimport BlogPostPageMetadata from '@theme/BlogPostPage/Metadata';\nimport BlogPostPageStructuredData from '@theme/BlogPostPage/StructuredData';\nimport TOC from '@theme/TOC';\nimport ContentVisibility from '@theme/ContentVisibility';\nfunction BlogPostPageContent({sidebar, children}) {\n  const {metadata, toc} = useBlogPost();\n  const {nextItem, prevItem, frontMatter} = metadata;\n  const {\n    hide_table_of_contents: hideTableOfContents,\n    toc_min_heading_level: tocMinHeadingLevel,\n    toc_max_heading_level: tocMaxHeadingLevel,\n  } = frontMatter;\n  return (\n    <BlogLayout\n      sidebar={sidebar}\n      toc={toc}\n      frontMatter={frontMatter}>\n      <ContentVisibility metadata={metadata} />\n\n      <BlogPostItem>{children}</BlogPostItem>\n\n      {(nextItem || prevItem) && (\n        <BlogPostPaginator nextItem={nextItem} prevItem={prevItem} />\n      )}\n    </BlogLayout>\n  );\n}\nexport default function BlogPostPage(props) {\n  const BlogPostContent = props.content;\n  return (\n    <BlogPostProvider content={props.content} isBlogPostPage>\n      <HtmlClassNameProvider\n        className={clsx(\n          ThemeClassNames.wrapper.docsPages, // Use docs wrapper instead of blog\n          ThemeClassNames.page.blogPostPage,\n        )}>\n        <BlogPostPageMetadata />\n        <BlogPostPageStructuredData />\n        <BlogPostPageContent sidebar={props.sidebar}>\n          <BlogPostContent />\n        </BlogPostPageContent>\n      </HtmlClassNameProvider>\n    </BlogPostProvider>\n  );\n}\n"
  },
  {
    "path": "src/theme/BlogSidebar/Desktop/index.js",
    "content": "import React, {memo} from 'react';\nimport clsx from 'clsx';\nimport {translate} from '@docusaurus/Translate';\nimport {ThemeClassNames} from '@docusaurus/theme-common';\nimport {\n  useVisibleBlogSidebarItems,\n  BlogSidebarItemList,\n} from '@docusaurus/plugin-content-blog/client';\nimport BlogSidebarContent from '@theme/BlogSidebar/Content';\nimport styles from './styles.module.css';\nconst ListComponent = ({items}) => {\n  return (\n    <BlogSidebarItemList\n      items={items}\n      ulClassName={clsx(styles.sidebarItemList, ThemeClassNames.docs.docSidebarMenu, 'clean-list')}\n      liClassName={styles.sidebarItem}\n      linkClassName={styles.sidebarItemLink}\n      linkActiveClassName={styles.sidebarItemLinkActive}\n    />\n  );\n};\nfunction BlogSidebarDesktop({sidebar}) {\n  const items = useVisibleBlogSidebarItems(sidebar.items);\n  return (\n    <nav\n      className={clsx(styles.sidebar, 'thin-scrollbar')}\n      aria-label={translate({\n        id: 'theme.blog.sidebar.navAriaLabel',\n        message: 'Blog recent posts navigation',\n        description: 'The ARIA label for recent posts in the blog sidebar',\n      })}>\n      <div className={clsx(styles.sidebarItemTitle, 'margin-bottom--md')}>\n        {sidebar.title}\n      </div>\n      <BlogSidebarContent\n        items={items}\n        ListComponent={ListComponent}\n        yearGroupHeadingClassName={styles.yearGroupHeading}\n      />\n    </nav>\n  );\n}\nexport default memo(BlogSidebarDesktop);\n"
  },
  {
    "path": "src/theme/BlogSidebar/Desktop/styles.module.css",
    "content": ".sidebar {\n  max-height: calc(100vh - (var(--ifm-navbar-height) + 2rem));\n  overflow-y: auto;\n  position: sticky;\n  top: calc(var(--ifm-navbar-height) + 2rem);\n  padding: 0 var(--ifm-spacing-horizontal);\n}\n\n.sidebarItemTitle {\n  font-size: var(--ifm-h3-font-size);\n  font-weight: var(--ifm-font-weight-bold);\n}\n\n.sidebarItemList {\n  font-size: 0.9rem;\n}\n\n.sidebarItem {\n  margin-top: 0.7rem;\n}\n\n.sidebarItemLink {\n  color: var(--ifm-font-color-base);\n  display: block;\n}\n\n.sidebarItemLink:hover {\n  text-decoration: none;\n}\n\n.sidebarItemLinkActive {\n  color: var(--ifm-color-primary) !important;\n}\n\n@media (max-width: 996px) {\n  .sidebar {\n    display: none;\n  }\n}\n\n.yearGroupHeading {\n  margin-top: 1.6rem;\n  margin-bottom: 0.4rem;\n}\n"
  },
  {
    "path": "src/theme/DocBreadcrumbs/Items/Home/index.js",
    "content": "import React from 'react';\nimport Link from '@docusaurus/Link';\nimport useBaseUrl from '@docusaurus/useBaseUrl';\nimport {translate} from '@docusaurus/Translate';\nimport IconHome from '@theme/Icon/Home';\nimport styles from './styles.module.css';\nexport default function HomeBreadcrumbItem() {\n  const homeHref = useBaseUrl('/');\n  return (\n    <li className=\"breadcrumbs__item\">\n      <Link\n        aria-label={translate({\n          id: 'theme.docs.breadcrumbs.home',\n          message: 'Home page',\n          description: 'The ARIA label for the home page in the breadcrumbs',\n        })}\n        className=\"breadcrumbs__link\"\n        href={homeHref}>\n        <IconHome className={styles.breadcrumbHomeIcon} />\n      </Link>\n    </li>\n  );\n}\n"
  },
  {
    "path": "src/theme/DocBreadcrumbs/Items/Home/styles.module.css",
    "content": ".breadcrumbHomeIcon {\n  position: relative;\n  top: 1px;\n  vertical-align: top;\n  height: 1.1rem;\n  width: 1.1rem;\n}\n"
  },
  {
    "path": "src/theme/DocBreadcrumbs/StructuredData/index.js",
    "content": "import React from 'react';\nimport Head from '@docusaurus/Head';\nimport {useBreadcrumbsStructuredData} from '@docusaurus/plugin-content-docs/client';\nexport default function DocBreadcrumbsStructuredData(props) {\n  const structuredData = useBreadcrumbsStructuredData({\n    breadcrumbs: props.breadcrumbs,\n  });\n  return (\n    <Head>\n      <script type=\"application/ld+json\">\n        {JSON.stringify(structuredData)}\n      </script>\n    </Head>\n  );\n}\n"
  },
  {
    "path": "src/theme/DocBreadcrumbs/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport {ThemeClassNames} from '@docusaurus/theme-common';\nimport {useSidebarBreadcrumbs, useDocsVersion, useVersions} from '@docusaurus/plugin-content-docs/client';\nimport {useHomePageRoute} from '@docusaurus/theme-common/internal';\nimport Link from '@docusaurus/Link';\nimport {translate} from '@docusaurus/Translate';\nimport HomeBreadcrumbItem from '@theme/DocBreadcrumbs/Items/Home';\nimport DocBreadcrumbsStructuredData from '@theme/DocBreadcrumbs/StructuredData';\nimport styles from './styles.module.css';\n// TODO move to design system folder\nfunction BreadcrumbsItemLink({children, href, isLast}) {\n  const className = 'breadcrumbs__link';\n  if (isLast) {\n    return <span className={className}>{children}</span>;\n  }\n  return href ? (\n    <Link className={className} href={href}>\n      <span>{children}</span>\n    </Link>\n  ) : (\n    <span className={className}>{children}</span>\n  );\n}\n// TODO move to design system folder\nfunction BreadcrumbsItem({children, active}) {\n  return (\n    <li\n      className={clsx('breadcrumbs__item', {\n        'breadcrumbs__item--active': active,\n      })}>\n      {children}\n    </li>\n  );\n}\nexport default function DocBreadcrumbs() {\n  const breadcrumbs = useSidebarBreadcrumbs();\n  const homePageRoute = useHomePageRoute();\n  const docsVersion = useDocsVersion();\n  const versions = useVersions(docsVersion.pluginId);\n\n  // Find the current version in the full versions list to get the main doc path\n  const currentVersion = versions.find(v => v.name === docsVersion.version);\n  const versionMainDoc = currentVersion?.docs.find((doc) => doc.id === currentVersion.mainDocId);\n  const docsPath = versionMainDoc?.path || '/docs';\n\n  // Determine if we're in the community section and set the label/path accordingly\n  const isCommunitySection = docsVersion.pluginId === 'community';\n  const sectionLabel = isCommunitySection ? 'Community' : 'Docs';\n  const sectionPath = isCommunitySection ? '/community' : docsPath;\n\n  if (!breadcrumbs) {\n    return null;\n  }\n  return (\n    <>\n      <DocBreadcrumbsStructuredData breadcrumbs={breadcrumbs} />\n      <nav\n        className={clsx(\n          ThemeClassNames.docs.docBreadcrumbs,\n          styles.breadcrumbsContainer,\n        )}\n        aria-label={translate({\n          id: 'theme.docs.breadcrumbs.navAriaLabel',\n          message: 'Breadcrumbs',\n          description: 'The ARIA label for the breadcrumbs',\n        })}>\n        <ul className=\"breadcrumbs\">\n          {homePageRoute && <HomeBreadcrumbItem />}\n          {homePageRoute && (\n            <BreadcrumbsItem>\n              <BreadcrumbsItemLink href={sectionPath} isLast={false}>\n                {sectionLabel}\n              </BreadcrumbsItemLink>\n            </BreadcrumbsItem>\n          )}\n          {breadcrumbs.map((item, idx) => {\n            const isLast = idx === breadcrumbs.length - 1;\n            const href =\n              item.type === 'category' && item.linkUnlisted\n                ? undefined\n                : item.href;\n            return (\n              <BreadcrumbsItem key={idx} active={isLast}>\n                <BreadcrumbsItemLink href={href} isLast={isLast}>\n                  {item.label}\n                </BreadcrumbsItemLink>\n              </BreadcrumbsItem>\n            );\n          })}\n        </ul>\n      </nav>\n    </>\n  );\n}\n"
  },
  {
    "path": "src/theme/DocBreadcrumbs/styles.module.css",
    "content": ".breadcrumbsContainer {\n  --ifm-breadcrumb-size-multiplier: 0.8;\n  margin-bottom: 0.8rem;\n}\n"
  },
  {
    "path": "src/theme/TOCCollapsible/CollapseButton/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport Translate from '@docusaurus/Translate';\nimport styles from './styles.module.css';\nexport default function TOCCollapsibleCollapseButton({collapsed, ...props}) {\n  return (\n    <button\n      type=\"button\"\n      {...props}\n      className={clsx(\n        'clean-btn',\n        styles.tocCollapsibleButton,\n        !collapsed && styles.tocCollapsibleButtonExpanded,\n        props.className,\n      )}>\n      <Translate\n        id=\"theme.TOCCollapsible.toggleButtonLabel\"\n        description=\"The label used by the button on the collapsible TOC component\">\n        On this page\n      </Translate>\n    </button>\n  );\n}\n"
  },
  {
    "path": "src/theme/TOCCollapsible/CollapseButton/styles.module.css",
    "content": ".tocCollapsibleButton {\n  font-size: inherit;\n  display: flex;\n  justify-content: space-between;\n  align-items: center;\n  padding: 0.4rem 0.8rem;\n  width: 100%;\n}\n\n.tocCollapsibleButton::after {\n  content: '';\n  background: var(--ifm-menu-link-sublist-icon) 50% 50% / 2rem 2rem no-repeat;\n  filter: var(--ifm-menu-link-sublist-icon-filter);\n  height: 1.25rem;\n  width: 1.25rem;\n  transform: rotate(180deg);\n  transition: transform var(--ifm-transition-fast);\n}\n\n.tocCollapsibleButtonExpanded::after {\n  transform: none;\n}\n"
  },
  {
    "path": "src/theme/TOCCollapsible/index.js",
    "content": "import React from 'react';\nimport clsx from 'clsx';\nimport {useCollapsible, Collapsible} from '@docusaurus/theme-common';\nimport TOCItems from '@theme/TOCItems';\nimport CollapseButton from '@theme/TOCCollapsible/CollapseButton';\nimport styles from './styles.module.css';\nexport default function TOCCollapsible({\n  toc,\n  className,\n  minHeadingLevel,\n  maxHeadingLevel,\n}) {\n  const {collapsed, toggleCollapsed} = useCollapsible({\n    initialState: true,\n  });\n  return (\n    <div\n      className={clsx(\n        styles.tocCollapsible,\n        !collapsed && styles.tocCollapsibleExpanded,\n        className,\n      )}>\n      <CollapseButton collapsed={collapsed} onClick={toggleCollapsed} />\n      <Collapsible\n        lazy\n        className={styles.tocCollapsibleContent}\n        collapsed={collapsed}>\n        <TOCItems\n          toc={toc}\n          minHeadingLevel={minHeadingLevel}\n          maxHeadingLevel={maxHeadingLevel}\n        />\n      </Collapsible>\n    </div>\n  );\n}\n"
  },
  {
    "path": "src/theme/TOCCollapsible/styles.module.css",
    "content": ".tocCollapsible {\n  background-color: var(--ifm-menu-color-background-active);\n  border-radius: var(--ifm-global-radius);\n  margin: 1rem 0;\n}\n\n.tocCollapsibleContent > ul {\n  border-left: none;\n  border-top: 1px solid var(--ifm-color-emphasis-300);\n  padding: 0.2rem 0;\n  font-size: 15px;\n}\n\n.tocCollapsibleContent ul li {\n  margin: 0.4rem 0.8rem;\n}\n\n.tocCollapsibleContent a {\n  display: block;\n}\n\n.tocCollapsibleExpanded {\n  transform: none;\n}\n"
  },
  {
    "path": "src/utils/communityDocsHelpers.js",
    "content": "/**\n * Helper functions for processing community documentation configuration\n */\n\n/**\n * @typedef {Object} ProcessedConfig\n * @property {string} sourceBaseUrl - Base URL for fetching remote content\n * @property {string[]} documents - Array of document paths to fetch\n * @property {Object.<string, Object>} metaByPath - Metadata indexed by file path\n * @property {Object.<string, string>} slugByPath - Slug mappings indexed by file path\n * @property {Object.<string, Object.<string, string>>} linkExceptions - Link transformations indexed by file path\n */\n\n/**\n * Converts the simplified community config to the format needed by docusaurus-plugin-remote-content\n * @param {Object} config - The community docs configuration\n * @param {string} config.sourceBaseUrl - Base URL for remote content\n * @param {string} config.sourceRepo - GitHub repository URL\n * @param {Object.<string, {meta?: Object, links?: Object}>} config.files - File configurations\n * @returns {ProcessedConfig} Configuration for docusaurus-plugin-remote-content\n */\nfunction processConfig(config) {\n  const { sourceBaseUrl, files } = config;\n\n  // Extract file paths\n  const remoteDocPaths = Object.keys(files);\n\n  // Build metadata and link mappings\n  const metaByPath = {};\n  const linkExceptions = {};\n\n  for (const [filename, fileConfig] of Object.entries(files)) {\n    if (fileConfig.meta) {\n      metaByPath[filename] = fileConfig.meta;\n    }\n    if (fileConfig.links) {\n      linkExceptions[filename] = fileConfig.links;\n    }\n  }\n\n  // Build slug mapping (for files with slug in meta)\n  const slugByPath = {};\n  for (const [path, meta] of Object.entries(metaByPath)) {\n    if (meta.slug) {\n      slugByPath[path] = meta.slug;\n    }\n  }\n\n  return {\n    sourceBaseUrl,\n    documents: remoteDocPaths,\n    metaByPath,\n    slugByPath,\n    linkExceptions,\n  };\n}\n\n/**\n * Creates the edit URL function for community docs\n * @param {string} sourceRepo - The GitHub repository URL\n * @returns {Function} Edit URL function for Docusaurus\n */\nfunction createEditUrlFunction(sourceRepo) {\n  return function editUrl({ docPath }) {\n    // Convert .md back to .txt for meeting notes\n    const origPath = docPath.replace(/^meeting-notes\\/(\\d+)\\.md$/, 'meeting-notes/$1.txt');\n    return `${sourceRepo}/edit/main/${origPath}`;\n  };\n}\n\nmodule.exports = {\n  processConfig,\n  createEditUrlFunction,\n};\n"
  },
  {
    "path": "src/utils/communityDocsTransforms.js",
    "content": "const path = require(\"path\");\nconst yaml = require(\"js-yaml\");\n\n// Parse existing frontmatter and content\nfunction parseFrontMatterAndContent(rawContent) {\n  const frontMatterRegex = /^---\\n([\\s\\S]*?)\\n---\\n([\\s\\S]*)$/;\n  const match = rawContent.match(frontMatterRegex);\n\n  if (match) {\n    const frontMatterStr = match[1];\n    const content = match[2];\n\n    try {\n      // Use js-yaml to parse frontmatter properly\n      const frontMatter = yaml.load(frontMatterStr) || {};\n      return { frontMatter, content };\n    } catch (e) {\n      console.warn(`Failed to parse frontmatter YAML: ${e.message}`);\n      return { frontMatter: {}, content: rawContent };\n    }\n  }\n\n  return { frontMatter: {}, content: rawContent };\n}\n\n// Extract H1 title from content\nfunction extractH1Title(content) {\n  const h1Match = content.match(/^\\s*#\\s+([^\\n]+)\\n/);\n  return h1Match ? h1Match[1].trim() : null;\n}\n\n// Remove H1 from content (including the newline)\nfunction stripH1(content) {\n  // This removes the H1 and its trailing newline, but preserves any blank lines after it\n  return content.replace(/^\\s*#\\s+[^\\n]+\\n/, \"\");\n}\n\n// Build front matter from merged meta\nfunction buildFrontMatter(meta) {\n  if (!meta || Object.keys(meta).length === 0) return \"\";\n\n  // Filter out null/empty values\n  const cleanMeta = {};\n  for (const [key, value] of Object.entries(meta)) {\n    if (value != null && value !== \"\") {\n      cleanMeta[key] = value;\n    }\n  }\n\n  if (Object.keys(cleanMeta).length === 0) return \"\";\n\n  // Use js-yaml to properly dump the frontmatter\n  // This handles special characters, arrays, etc. correctly\n  const yamlStr = yaml.dump(cleanMeta, {\n    lineWidth: -1, // Don't wrap long lines\n    quotingType: '\"', // Use double quotes when needed\n    forceQuotes: false, // Only quote when necessary\n  });\n\n  return `---\\n${yamlStr}---\\n\\n`;\n}\n\n// Resolve relative link target against current file\nfunction resolveCanonicalTargetPath(currentFilePath, hrefPath) {\n  const currentDir = path.posix.dirname(currentFilePath);\n  return path.posix.normalize(path.posix.join(currentDir, hrefPath));\n}\n\n// Helper to process a link href (used by both inline and reference links)\nfunction processLinkHref(filename, href, linkExceptions, slugByPath) {\n  // Don't process anchors or mailto\n  if (href.startsWith(\"#\") || href.startsWith(\"mailto:\")) {\n    return href;\n  }\n\n  const m = href.match(/^([^?#]+)(\\?[^#]*)?(#.*)?$/);\n  if (!m) return href;\n  const [, pathPart, queryPart = \"\", hashPart = \"\"] = m;\n\n  // Check file-specific exceptions (works for both absolute and relative URLs)\n  const fileExceptions = linkExceptions[filename];\n  if (\n    fileExceptions &&\n    Object.prototype.hasOwnProperty.call(fileExceptions, pathPart)\n  ) {\n    const forced = fileExceptions[pathPart];\n    return `${forced}${queryPart}${hashPart}`;\n  }\n\n  // Otherwise, return the link as-is (don't strip .md or transform paths)\n  // Since we're keeping the same file structure, internal links should just work\n  return href;\n}\n\n// Rewrite relative markdown links using exceptions/slug when available, otherwise strip .md/.mdx\nfunction rewriteMarkdownLinks(filename, content, linkExceptions, slugByPath) {\n  // First, handle inline links: [text](url)\n  const inlineLinkRe = /!?\\[([^\\]]+)\\]\\(([^)\\s]+(?:\\s+\"[^\"]*\")?)\\)/g;\n\n  content = content.replace(inlineLinkRe, (full, text, hrefRaw) => {\n    if (full.startsWith(\"!\")) return full; // image\n\n    const mTitle = hrefRaw.match(/^([^\\s]+)(?:\\s+\"[^\"]*\")?$/);\n    const href = mTitle ? mTitle[1] : hrefRaw;\n\n    const processedHref = processLinkHref(filename, href, linkExceptions, slugByPath);\n\n    // Reconstruct with title if present\n    if (mTitle && mTitle[0] !== mTitle[1]) {\n      const title = mTitle[0].substring(mTitle[1].length);\n      return `[${text}](${processedHref}${title})`;\n    }\n    return `[${text}](${processedHref})`;\n  });\n\n  // Handle angle-bracket links: <http://example.com>\n  const angleBracketLinkRe = /<(https?:\\/\\/[^>]+)>/g;\n\n  content = content.replace(angleBracketLinkRe, (full, url) => {\n    const processedUrl = processLinkHref(filename, url, linkExceptions, slugByPath);\n    // If the URL was transformed, convert to markdown link format\n    if (processedUrl !== url && !processedUrl.startsWith('http')) {\n      return `[${processedUrl}](${processedUrl})`;\n    }\n    return `<${processedUrl}>`;\n  });\n\n  // Then, handle reference link definitions: [ref]: url\n  const refLinkDefRe = /^\\[([^\\]]+)\\]:\\s*(.+)$/gm;\n\n  content = content.replace(refLinkDefRe, (full, ref, url) => {\n    // Process the URL part (handle angle brackets in reference definitions too)\n    let cleanUrl = url.trim();\n    let isAngleBracket = false;\n\n    if (cleanUrl.startsWith('<') && cleanUrl.endsWith('>')) {\n      cleanUrl = cleanUrl.slice(1, -1);\n      isAngleBracket = true;\n    }\n\n    const processedUrl = processLinkHref(filename, cleanUrl, linkExceptions, slugByPath);\n\n    // Preserve angle brackets if they were there and URL wasn't transformed to internal link\n    if (isAngleBracket && processedUrl.startsWith('http')) {\n      return `[${ref}]: <${processedUrl}>`;\n    }\n    return `[${ref}]: ${processedUrl}`;\n  });\n\n  return content;\n}\n\n// Add import notice header\nfunction addImportNotice(filename) {\n  const sourceUrl = `https://github.com/helm/community/blob/main/${filename}`;\n\n  return `<!--\nTHIS FILE IS AUTOMATICALLY IMPORTED FROM THE HELM/COMMUNITY REPOSITORY\nDO NOT EDIT THIS FILE DIRECTLY - IT WILL BE OVERWRITTEN\n\nTO MAKE CHANGES:\n- Edit the source file at: ${sourceUrl}\n-->\n`;  // Removed extra newline here\n}\n\n// Format HIP sidebar_label with number prefix\nfunction formatHipSidebarLabel(meta, originalFrontmatter, filename) {\n  // Check if this is a HIP file (has hip field in original frontmatter)\n  const isHip = filename.startsWith('hips/') && originalFrontmatter && originalFrontmatter.hip;\n\n  if (isHip && originalFrontmatter.hip && meta.title) {\n    // Format hip number with leading zeros (4 digits)\n    const hipNum = String(originalFrontmatter.hip).padStart(4, '0');\n    // Add sidebar_label with HIP number prefix\n    meta.sidebar_label = `${hipNum}: ${meta.title}`;\n  }\n\n  return meta;\n}\n\n// Create markdown table from HIP frontmatter\nfunction createHipFrontmatterTable(originalFrontmatter, filename) {\n  // Only create table for HIP files\n  if (!filename.startsWith('hips/') || !originalFrontmatter.hip) {\n    return '';\n  }\n\n  // Define which fields to show and their display names\n  // Order matches HIP-0001 specification\n  const hipFields = [\n    { key: 'hip', label: 'HIP' },\n    { key: 'title', label: 'Title' },\n    { key: 'authors', label: 'Author(s)' },\n    { key: 'created', label: 'Created' },\n    { key: 'type', label: 'Type' },\n    { key: 'status', label: 'Status' },\n    { key: 'helm-version', label: 'Helm Version' },  // optional\n    { key: 'requires', label: 'Requires' },  // optional\n    { key: 'replaces', label: 'Replaces' },  // optional\n    { key: 'superseded-by', label: 'Superseded by' },  // optional\n  ];\n\n  // Collect fields that have values\n  const fieldsWithValues = [];\n  const values = [];\n\n  for (const field of hipFields) {\n    const value = originalFrontmatter[field.key];\n    if (value !== undefined && value !== null && value !== '') {\n      fieldsWithValues.push(field);\n\n      let displayValue;\n      // Handle arrays (like authors)\n      if (Array.isArray(value)) {\n        displayValue = value.join(', ');\n      } else {\n        displayValue = String(value);\n      }\n\n      // Escape pipe characters in values\n      displayValue = displayValue.replace(/\\|/g, '\\\\|');\n      values.push(displayValue);\n    }\n  }\n\n  if (fieldsWithValues.length === 0) {\n    return '';\n  }\n\n  // Build header row with field names\n  const headerRow = '| ' + fieldsWithValues.map(f => `**${f.label}**`).join(' | ') + ' |';\n\n  // Build separator row with correct number of columns\n  const separatorRow = '|' + fieldsWithValues.map(() => '---').join('|') + '|';\n\n  // Build data row with values\n  const dataRow = '| ' + values.join(' | ') + ' |';\n\n  return '\\n' + headerRow + '\\n' + separatorRow + '\\n' + dataRow + '\\n\\n';\n}\n\n// Extract title from .txt file (handles both Markdown and underline-style headers)\nfunction extractTxtTitle(content) {\n  // First try markdown-style H1\n  const h1Match = content.match(/^\\s*#\\s+([^\\n]+)\\n/);\n  if (h1Match) return { title: h1Match[1].trim(), contentWithoutTitle: content.replace(/^\\s*#\\s+[^\\n]+\\n/, \"\") };\n\n  // Then try underline-style header (text followed by ===)\n  const underlineMatch = content.match(/^\\s*([^\\n]+)\\n=+\\n/);\n  if (underlineMatch) {\n    return {\n      title: underlineMatch[1].trim(),\n      contentWithoutTitle: content.replace(/^\\s*[^\\n]+\\n=+\\n/, \"\")\n    };\n  }\n\n  return { title: null, contentWithoutTitle: content };\n}\n\n// Compose transforms per file\nfunction transformImportedContent(filename, rawContent, metaByPath, slugByPath, linkExceptions) {\n  // Check if this is a .txt file\n  const isTxtFile = filename.endsWith('.txt');\n\n  // For .txt files, handle them specially\n  if (isTxtFile) {\n    // Extract title from the content\n    const { title, contentWithoutTitle } = extractTxtTitle(rawContent);\n\n    // Build metadata\n    const meta = {\n      ...(metaByPath[filename] || {}),\n      ...(title ? { title } : {})\n    };\n\n    // Build frontmatter\n    const fm = buildFrontMatter(meta);\n\n    // Add import notice\n    const importNotice = addImportNotice(filename);\n\n    // Wrap the content in a code block\n    const wrappedContent = `\\`\\`\\`txt\\n${contentWithoutTitle.trim()}\\n\\`\\`\\`\\n`;\n\n    // Return transformed content with new filename\n    return {\n      content: `${fm}${importNotice}\\n${wrappedContent}`,\n      filename: filename.replace(/\\.txt$/, '.md')\n    };\n  }\n\n  // Original logic for non-.txt files\n  // 1) Parse existing frontmatter and content\n  const { frontMatter: existingFrontMatter, content: bodyWithH1 } = parseFrontMatterAndContent(rawContent);\n\n  // Keep original frontmatter for HIP table\n  const originalFrontmatter = { ...existingFrontMatter };\n\n  // 2) Extract H1 title and remove it from content\n  const h1Title = extractH1Title(bodyWithH1);\n  const bodyWithoutH1 = stripH1(bodyWithH1);\n\n  // 3) For HIPs, remove HIP-specific fields from merged frontmatter (they'll go in the table)\n  const hipSpecificFields = [\n    'hip',\n    'authors',\n    'created',\n    'type',\n    'status',\n    'helm-version',\n    'requires',\n    'replaces',\n    'superseded-by'\n  ];\n  const isHip = filename.startsWith('hips/') && existingFrontMatter.hip;\n\n  let mergedMeta;\n  if (isHip) {\n    // For HIPs, filter out HIP-specific fields from frontmatter\n    const filteredExisting = {};\n    for (const [key, value] of Object.entries(existingFrontMatter)) {\n      if (!hipSpecificFields.includes(key)) {\n        filteredExisting[key] = value;\n      }\n    }\n    mergedMeta = {\n      ...filteredExisting,\n      ...metaByPath[filename] || {}\n    };\n  } else {\n    // For non-HIPs, keep everything\n    mergedMeta = {\n      ...existingFrontMatter,\n      ...metaByPath[filename] || {}\n    };\n  }\n\n  // Add extracted H1 as title if no title is specified\n  if (h1Title && !mergedMeta.title) {\n    mergedMeta.title = h1Title;\n  }\n\n  // 4) Apply HIP-specific sidebar_label formatting\n  formatHipSidebarLabel(mergedMeta, originalFrontmatter, filename);\n\n  // 5) Build frontmatter (will always exist since we extract H1 or have config)\n  const fm = buildFrontMatter(mergedMeta);\n\n  // 6) Add import notice after frontmatter\n  const importNotice = addImportNotice(filename);\n\n  // 7) Create HIP frontmatter table if applicable\n  const hipTable = createHipFrontmatterTable(originalFrontmatter, filename);\n\n  // 8) Compose final content: frontmatter + import notice + HIP table + body\n  let content = `${fm}${importNotice}${hipTable}${bodyWithoutH1}`;\n\n  // 9) Rewrite links\n  content = rewriteMarkdownLinks(filename, content, linkExceptions, slugByPath);\n\n  // Return as object for consistency (even for non-.txt files)\n  return { content };\n}\n\nmodule.exports = {\n  parseFrontMatterAndContent,\n  extractH1Title,\n  stripH1,\n  buildFrontMatter,\n  resolveCanonicalTargetPath,\n  rewriteMarkdownLinks,\n  transformImportedContent,\n};\n"
  },
  {
    "path": "static/.nojekyll",
    "content": ""
  },
  {
    "path": "static/chartmuseum/index.html",
    "content": "<!doctype html><html lang=en><head><meta charset=utf-8><meta name=go-import content=\"helm.sh/chartmuseum git https://github.com/helm/chartmuseum\"><meta name=go-source content=\"helm.sh/chartmuseum git https://github.com/helm/chartmuseum https://github.com/helm/chartmuseum/tree/main{/dir} https://github.com/helm/chartmuseum/blob/main{/dir}/{file}#L{line}\"><meta http-equiv=refresh content=\"0; url=https://github.com/helm/chartmuseum\"></head><body>Nothing to see here; <a href=https://github.com/helm/chartmuseum>move along</a>.</body></html>"
  },
  {
    "path": "static/helm/index.html",
    "content": "<!doctype html><html lang=en><head><meta charset=utf-8><meta name=go-import content=\"helm.sh/helm git https://github.com/helm/helm\"><meta name=go-source content=\"helm.sh/helm git https://github.com/helm/helm https://github.com/helm/helm/tree/main{/dir} https://github.com/helm/helm/blob/main{/dir}/{file}#L{line}\"><meta http-equiv=refresh content=\"0; url=https://github.com/helm/helm\"></head><body>Nothing to see here; <a href=https://github.com/helm/helm>move along</a>.</body></html>"
  },
  {
    "path": "static/helm/v2/index.html",
    "content": "<!doctype html><html lang=en><head><meta charset=utf-8><meta name=go-import content=\"helm.sh/helm/v2 git https://github.com/helm/helm\"><meta name=go-source content=\"helm.sh/helm/v2 git https://github.com/helm/helm https://github.com/helm/helm/tree/dev-v2{/dir} https://github.com/helm/helm/blob/dev-v2{/dir}/{file}#L{line}\"><meta http-equiv=refresh content=\"0; url=https://github.com/helm/helm\"></head><body>Nothing to see here; <a href=https://github.com/helm/helm>move along</a>.</body></html>"
  },
  {
    "path": "static/helm/v3/index.html",
    "content": "<!doctype html><html lang=en><head><meta charset=utf-8><meta name=go-import content=\"helm.sh/helm/v3 git https://github.com/helm/helm\"><meta name=go-source content=\"helm.sh/helm/v3 git https://github.com/helm/helm https://github.com/helm/helm/tree/dev-v3{/dir} https://github.com/helm/helm/blob/dev-v3{/dir}/{file}#L{line}\"><meta http-equiv=refresh content=\"0; url=https://github.com/helm/helm\"></head><body>Nothing to see here; <a href=https://github.com/helm/helm>move along</a>.</body></html>"
  },
  {
    "path": "static/helm/v4/index.html",
    "content": "<!doctype html><html lang=en><head><meta charset=utf-8><meta name=go-import content=\"helm.sh/helm/v4 git https://github.com/helm/helm\"><meta name=go-source content=\"helm.sh/helm/v4 git https://github.com/helm/helm https://github.com/helm/helm/tree/main{/dir} https://github.com/helm/helm/blob/main{/dir}/{file}#L{line}\"><meta http-equiv=refresh content=\"0; url=https://github.com/helm/helm\"></head><body>Nothing to see here; <a href=https://github.com/helm/helm>move along</a>.</body></html>"
  },
  {
    "path": "style-guide.md",
    "content": "# Documentation Style Guide\n\nThis page lists writing style guidelines for the Helm documentation.\nThese are guidelines, not rules.\nUse your best judgement, and depart from these guidelines when doing so improves our content.\n\nBy default, the Helm docs use the Google Developer Docs Style Guide: https://developers.google.com/style/\n\nThis 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.\nRefer to the Google Developer Docs Style Guide for additional guidelines that are not covered here.\n\n## Helm Terminology\n\nFor a list of common Helm terms, see the [Glossary](https://helm.sh/docs/glossary/)\n\n## Markdown Features in Docusaurus\n\nOur static site generator, Docusaurus, has various built-in Markdown features that you can use when authoring content, such as:\n- Admonitions (notes, warnings, etc)\n- Code blocks\n- Tabs\n\nFor more information about how to format these and other elements, see [Markdown Features](https://docusaurus.io/docs/markdown-features) in the Docusaurus documentation.\n\n## Using Markdown and MDX\n\nThis site uses Docusaurus with `markdown.format: \"detect\"`. Files with the `.md` extension are parsed as CommonMark, but `.mdx`\nfiles 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.\n\n## Word Choice, Tone, and Voice\n\n- Use active voice\n- Use the second person \"you\" to address the reader.\nNever use \"let's\" or \"we\" to refer to an action that the user is doing\n- Use present tense (for example, use \"returns\" and not \"will return\")\n- Write in a friendly tone without using slang, jargon, or frivolous words\n- Avoid marketing language that is overly promotional\n- Avoid terms like \"simple\" or \"easy\"\n- Use common words. For example, don't use words like \"utilize\" or \"leverage\" when you mean \"use\".\nUsing common words makes the docs more suitable for a global audience\n- Avoid time-bound terminology like \"currently\", \"new\", \"at this time\", and \"now\".\nInstead, write timeless documentation that makes no assumptions about a reader's prior knowledge.\n- Avoid using the word \"should\". Instead, strive for more prescriptive documentation.\nFor 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\".\n\n## Readability\n\n- Break up walls of text to make content easier to scan\n- Try to use fewer than 26 words per sentence\n- Define acronyms and abbreviations on first usage\n- Procedural/how-to content must use numbered steps.\nFor one-step procedures, use a bullet point. See https://developers.google.com/style/procedures#single-step-procedures for examples.\n- Use semantic line breaks when authoring content.\nIn general, this means adding a line break after each sentence.\nFor longer sentences, you can also add a semantic line break in between clauses.\nUsing semantic line breaks makes content easier to edit and review, without altering the final rendered version seen by users.\n\n## Text Formatting\n\n- Use bold and italic text sparingly.\n  - Bold text is primarily used to identify UI elements. For example, \"Click **Save**.\" \n  - Do not use bold text to emphasize important content.\n  Instead, if discoverability is a concern, consider how the content could be reorganized or how you could use clearer headings.\n  - It's okay to use bold text for introducing an example (`**Example:**`) or for run-in headings in unordered lists (`* **Item 1:** Description`)\n- Use notes and asides sparingly.\nIn general, the user should be able to succeed even if they skip the information in the note.\n\n## Titles and Headings\n\n- Use title case for titles and headings\n- Use a bare infinitive verb form for titles and headings for how-to content.\nAs in, use \"Create a Release\" instead of \"Creating a Release\"\n- Don't skip levels in the heading hierarchy. For example, an h3 element must only appear after an h2\n\n## Cross References\n\n- Use descriptive link text. This is important to help improve both accessibility and readability.\nIn 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.\nFor example, `For more information about accessing values from within templates, see [Subcharts and Global Values](/chart_template_guide/subcharts_and_globals).`\n- Avoid vague link text like `\"click [here](link) for more information\"` or `\"see this [blog post](link)\"`\n"
  },
  {
    "path": "versioned_docs/version-2/architecture.md",
    "content": "---\nsidebar_position: 9\nsidebar_label: \"Architecture\"\n---\n# The Kubernetes Helm Architecture\n\nThis document describes the Helm architecture at a high level.\n\n## The Purpose of Helm\n\nHelm is a tool for managing Kubernetes packages called _charts_. Helm\ncan do the following:\n\n- Create new charts from scratch\n- Package charts into chart archive (tgz) files\n- Interact with chart repositories where charts are stored\n- Install and uninstall charts into an existing Kubernetes cluster\n- Manage the release cycle of charts that have been installed with Helm\n\nFor Helm, there are three important concepts:\n\n1. The _chart_ is a bundle of information necessary to create an\n   instance of a Kubernetes application.\n2. The _config_ contains configuration information that can be merged\n   into a packaged chart to create a releasable object.\n3. A _release_ is a running instance of a _chart_, combined with a\n   specific _config_.\n\n## Components\n\nHelm has two major components:\n\n**The Helm Client** is a command-line client for end users. The client\nis responsible for the following domains:\n\n- Local chart development\n- Managing repositories\n- Interacting with the Tiller server\n  - Sending charts to be installed\n  - Asking for information about releases\n  - Requesting upgrading or uninstalling of existing releases\n\n**The Tiller Server** is an in-cluster server that interacts with the\nHelm client, and interfaces with the Kubernetes API server. The server\nis responsible for the following:\n\n- Listening for incoming requests from the Helm client\n- Combining a chart and configuration to build a release\n- Installing charts into Kubernetes, and then tracking the subsequent\n  release\n- Upgrading and uninstalling charts by interacting with Kubernetes\n\nIn a nutshell, the client is responsible for managing charts, and the\nserver is responsible for managing releases.\n\n## Implementation\n\nThe Helm client is written in the Go programming language, and uses the\ngRPC protocol suite to interact with the Tiller server.\n\nThe Tiller server is also written in Go. It provides a gRPC server to\nconnect with the client, and it uses the Kubernetes client library to\ncommunicate with Kubernetes. Currently, that library uses REST+JSON.\n\nThe Tiller server stores information in ConfigMaps located inside of\nKubernetes. It does not need its own database.\n\nConfiguration files are, when possible, written in YAML.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_best_practices/chart_best_practices.md",
    "content": "---\nsidebar_position: 7\nsidebar_label: \"Best Practices\"\n# This is the index/landing page for this section\n---\n# The Chart Best Practices Guide\n\nThis guide covers the Helm Team's considered best practices for creating charts.\nIt focuses on how charts should be structured.\n\nWe focus primarily on best practices for charts that may be publicly deployed.\nWe know that many charts are for internal-use only, and authors of such charts\nmay find that their internal interests override our suggestions here.\n\n## Table of Contents\n\n- [General Conventions](conventions.md): Learn about general chart conventions.\n- [Values Files](values.md): See the best practices for structuring `values.yaml`.\n- [Templates](templates.md): Learn some of the best techniques for writing templates.\n- [Requirements](requirements.md): Follow best practices for `requirements.yaml` files.\n- [Labels and Annotations](labels.md): Helm has a _heritage_ of labeling and annotating.\n- Kubernetes Resources:\n\t- [Pods and Pod Specs](pods.md): See the best practices for working with pod specifications.\n\t- [Role-Based Access Control](rbac.md): Guidance on creating and using service accounts, roles, and role bindings.\n\t- [Custom Resource Definitions](custom_resource_definitions.md): Custom Resource Definitions (CRDs) have their own associated best practices.\n\n"
  },
  {
    "path": "versioned_docs/version-2/chart_best_practices/conventions.md",
    "content": "---\nsidebar_position: 1\nsidebar_label: \"General Conventions\"\n---\n# General Conventions\n\nThis part of the Best Practices Guide explains general conventions.\n\n## Chart Names\n\nChart names should use lower case letters and numbers, and start with a letter.\n\nHyphens (-) 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).\n\nHere are a few examples of good chart names from the [Helm Community Charts](https://github.com/helm/charts):\n\n```\ndrupal\ncert-manager\noauth2-proxy\n```\n\nNeither uppercase letters nor underscores should be used in chart names. Dots should not be used in chart names.\n\nThe 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.\n\n## Version Numbers\n\nWherever 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.)\n\nWhen 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.\n\n## Formatting YAML\n\nYAML files should be indented using _two spaces_ (and never tabs).\n\n## Usage of the Words Helm, Tiller, and Chart\n\nThere are a few small conventions followed for using the words Helm, helm, Tiller, and tiller.\n\n- Helm refers to the project, and is often used as an umbrella term\n- `helm` refers to the client-side command\n- Tiller is the proper name of the backend\n- `tiller` is the name of the binary run on the backend\n- The term 'chart' does not need to be capitalized, as it is not a proper noun.\n\nWhen in doubt, use _Helm_ (with an uppercase 'H').\n\n## Restricting Tiller by Version\n\nA `Chart.yaml` file can specify a `tillerVersion` SemVer constraint:\n\n```yaml\nname: mychart\nversion: 0.2.0\ntillerVersion: \">=2.4.0\"\n```\n\nThis constraint should be set when templates use a new feature that was not\nsupported in older versions of Helm. While this parameter will accept sophisticated\nSemVer rules, the best practice is to default to the form `>=2.4.0`, where `2.4.0`\nis the version that introduced the new feature used in the chart.\n\nThis feature was introduced in Helm 2.4.0, so any version of Tiller older than\n2.4.0 will simply ignore this field.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_best_practices/custom_resource_definitions.md",
    "content": "---\nsidebar_position: 7\nsidebar_label: \"Custom Resource Definitions\"\n---\n# Custom Resource Definitions\n\nThis section of the Best Practices Guide deals with creating and using Custom Resource Definition\nobjects.\n\nWhen working with Custom Resource Definitions (CRDs), it is important to distinguish\ntwo different pieces:\n\n- There is a declaration of a CRD. This is the YAML file that has the kind `CustomResourceDefinition`\n- Then there are resources that _use_ the CRD. Say a CRD defines `foo.example.com/v1`. Any resource\n  that has `apiVersion: example.com/v1` and kind `Foo` is a resource that uses the CRD.\n\n## Install a CRD Declaration Before Using the Resource\n\nHelm is optimized to load as many resources into Kubernetes as fast as possible.\nBy design, Kubernetes can take an entire set of manifests and bring them all\nonline (this is called the reconciliation loop).\n\nBut there's a difference with CRDs.\n\nFor a CRD, the declaration must be registered before any resources of that CRDs\nkind(s) can be used. And the registration process sometimes takes a few seconds.\n\n### Method 1: Separate Charts\n\nOne way to do this is to put the CRD definition in one chart, and then put any\nresources that use that CRD in _another_ chart.\n\nIn this method, each chart must be installed separately.\n\n### Method 2: Crd-install Hooks\n\nTo package the two together, add a `crd-install` hook to the CRD definition so\nthat it is fully installed before the rest of the chart is executed.\n\nNote that if you create the CRD with a `crd-install` hook, that CRD definition\nwill not be deleted when `helm delete` is run.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_best_practices/labels.md",
    "content": "---\nsidebar_position: 5\nsidebar_label: \"Labels & Annotations\"\n---\n# Labels and Annotations\n\nThis part of the Best Practices Guide discusses the best practices for using\nlabels and annotations in your chart.\n\n## Is it a Label or an Annotation?\n\nAn item of metadata should be a label under the following conditions:\n\n- It is used by Kubernetes to identify this resource\n- It is useful to expose to operators for the purpose of querying the system.\n\nFor example, we suggest using `helm.sh/chart: NAME-VERSION` as a label so that operators\ncan conveniently find all of the instances of a particular chart to use.\n\nIf an item of metadata is not used for querying, it should be set as an annotation\ninstead.\n\nHelm hooks are always annotations.\n\n## Standard Labels\n\nThe following table defines common labels that Helm charts use. Helm itself never requires that a particular label be present. Labels that are marked REC\nare 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.\n\nName|Status|Description\n-----|------|----------\n`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.\n`helm.sh/chart` | REC | This should be the chart name and version: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`.\n`app.kubernetes.io/managed-by` | REC | This should always be set to `{{ .Release.Service }}`. It is for finding all things managed by Tiller.\n`app.kubernetes.io/instance` | REC | This should be the `{{ .Release.Name }}`. It aids in differentiating between different instances of the same application.\n`app.kubernetes.io/version` | OPT | The version of the app and can be set to `{{ .Chart.AppVersion }}`.\n`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`.\n`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.\n\nYou 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/).\n"
  },
  {
    "path": "versioned_docs/version-2/chart_best_practices/pods.md",
    "content": "---\nsidebar_position: 6\nsidebar_label: \"Pods & PodTemplates\"\n---\n# Pods and PodTemplates\n\nThis part of the Best Practices Guide discusses formatting the Pod and PodTemplate\nportions in chart manifests.\n\nThe following (non-exhaustive) list of resources use PodTemplates:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Images\n\nA 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\".\n\n\nImages _may_ be defined in the `values.yaml` file to make it easy to swap out images.\n\n```\nimage: {{ .Values.redisImage | quote }}\n```\n\nAn image and a tag _may_ be defined in `values.yaml` as two separate fields:\n\n```\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` sets the `imagePullPolicy` to `IfNotPresent` by default by doing the following in your `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nAnd `values.yaml`:\n\n```yaml\npullPolicy: IfNotPresent\n```\n\nSimilarly, 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.\n\n\n## PodTemplates Should Declare Selectors\n\nAll PodTemplate sections should specify a selector. For example:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nThis is a good practice because it makes the relationship between the set and\nthe pod.\n\nBut this is even more important for sets like Deployment.\nWithout this, the _entire_ set of labels is used to select matching pods, and\nthis will break if you use labels that change, like version or release date.\n\n\n"
  },
  {
    "path": "versioned_docs/version-2/chart_best_practices/rbac.md",
    "content": "---\nsidebar_position: 8\nsidebar_label: \"RBAC\"\n---\n# Role-Based Access Control\n\nThis part of the Best Practices Guide discusses the creation and formatting of RBAC resources in chart manifests.\n\nRBAC resources are:\n\n- ServiceAccount (namespaced)\n- Role (namespaced)\n- ClusterRole \n- RoleBinding (namespaced)\n- ClusterRoleBinding\n\n## YAML Configuration\n\nRBAC 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.\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\nThis structure can be extended for more complex charts that require multiple ServiceAccounts.\n\n```yaml\nserviceAccounts:\n  client:\n    create: true\n    name:\n  server: \n    create: true\n    name:\n```\n\n## RBAC Resources Should be Created by Default\n\n`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).\n\n## Using RBAC Resources\n\n`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.\n\nThe following helper template should be used for the ServiceAccount.\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "versioned_docs/version-2/chart_best_practices/requirements.md",
    "content": "---\nsidebar_position: 4\nsidebar_label: \"Requirements\"\n---\n# Requirements Files\n\nThis section of the guide covers best practices for `requirements.yaml` files.\n\n## Versions\n\nWhere possible, use version ranges instead of pinning to an exact version. The suggested default is to use a patch-level version match:\n\n```yaml\nversion: ~1.2.3\n```\n\nThis 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`\n\nFor the complete version matching syntax, please see the [semver documentation](https://github.com/Masterminds/semver#checking-version-constraints)\n\n### Repository URLs\n\nWhere possible, use `https://` repository URLs, followed by `http://` URLs.\n\nIf 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.\n\nFile 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.\n\n## Conditions and Tags\n\nConditions or tags should be added to any dependencies that _are optional_.\n\nThe preferred form of a condition is:\n\n```yaml\ncondition: somechart.enabled\n```\n\nWhere `somechart` is the chart name of the dependency.\n\nWhen multiple subcharts (dependencies) together provide an optional or swappable feature, those charts should share the same tags.\n\nFor 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\ntags section like this:\n\n```\ntags:\n  - webaccelerator\n```\n\nThis allows a user to turn that feature on and off with one tag.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_best_practices/templates.md",
    "content": "---\nsidebar_position: 3\nsidebar_label: \"Templates\"\n---\n# Templates\n\nThis part of the Best Practices Guide focuses on templates.\n\n## Structure of templates/\n\nThe templates directory should be structured as follows:\n\n- Template files should have the extension `.yaml` if they produce YAML output. The\n  extension `.tpl` may be used for template files that produce no formatted content.\n- Template file names should use dashed notation (`my-example-configmap.yaml`), not camelcase.\n- Each resource definition should be in its own template file.\n- Template file names should reflect the resource kind in the name. e.g. `foo-pod.yaml`,\n  `bar-svc.yaml`\n\n## Names of Defined Templates\n\nDefined templates (templates created inside a `{{ define }} ` directive) are\nglobally accessible. That means that a chart and all of its subcharts will have\naccess to all of the templates created with `{{ define }}`.\n\nFor that reason, _all defined template names should be namespaced._\n\nCorrect:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nIncorrect:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\nIt is highly recommended that new charts are created via `helm create` command as the template names are automatically defined as per this best practice.\n\n## Formatting Templates\n\nTemplates should be indented using _two spaces_ (never tabs).\n\nTemplate directives should have whitespace after the opening  braces and before the\nclosing braces:\n\nCorrect:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nIncorrect:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nTemplates should chomp whitespace where possible:\n\n```\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nBlocks (such as control structures) may be indented to indicate flow of the template code.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}} \n```\n\nHowever, since YAML is a whitespace-oriented language, it is often not possible for code indentation to follow that convention.\n\n## Whitespace in Generated Templates\n\nIt is preferable to keep the amount of whitespace in generated templates to\na minimum. In particular, numerous blank lines should not appear adjacent to each\nother. But occasional empty lines (particularly between logical sections) is\nfine.\n\nThis is best:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nThis is okay:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nBut this should be avoided:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Resource Naming in Templates\n\nHard-coding the `name:` into a resource is usually considered to be bad practice.\nNames should be unique to a release. So we might want to generate a name field\nby inserting the release name - for example:\n\n```yaml\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{ .Release.Name }}-myservice\n```\n\nOr 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):\n\n```yaml\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{ template \"fullname\" . }}\n```\n\nHowever, there may be cases where it is known that there won't be naming conflicts from a fixed name.\nIn these cases a fixed name might make it easier for an application to find a resource such as a Service.\nIf 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:\n\n```yaml\napiVersion: v1\nkind: Service\nmetadata:\n  {{- if .Values.service.name }}\n    name: {{ .Values.service.name }}\n  {{- else }}\n    name: {{ template \"fullname\" . }}\n  {{- end }}\n```\n\n## Comments (YAML Comments vs. Template Comments)\n\nBoth YAML and Helm Templates have comment markers.\n\nYAML comments:\n```yaml\n# This is a comment\ntype: sprocket\n```\n\nTemplate Comments:\n```yaml\n{{- /*\nThis is a comment.\n*/ -}}\ntype: frobnitz\n```\n\nTemplate comments should be used when documenting features of a template, such as explaining a defined template:\n\n```yaml\n{{- /*\nmychart.shortname provides a 6 char truncated version of the release name.\n*/ -}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nInside of templates, YAML comments may be used when it is useful for Helm users to (possibly) see the comments during debugging.\n\n```\n# This may cause problems if the value is more than 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nThe comment above is visible when the user runs `helm install --debug`, while\ncomments specified in `{{- /* */ -}}` sections are not.\n\n## Use of JSON in Templates and Template Output\n\nYAML is a superset of JSON. In some cases, using a JSON syntax can be more\nreadable than other YAML representations.\n\nFor example, this YAML is closer to the normal YAML method of expressing lists:\n\n```yaml\narguments: \n  - \"--dirname\"\n  - \"/foo\"\n```\n\nBut it is easier to read when collapsed into a JSON list style:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nUsing JSON for increased legibility is good. However, JSON syntax should not\nbe used for representing more complex constructs.\n\nWhen dealing with pure JSON embedded inside of YAML (such as init container\nconfiguration), it is of course appropriate to use the JSON format.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_best_practices/values.md",
    "content": "---\nsidebar_position: 2\nsidebar_label: \"Values\"\n---\n# Values\n\nThis part of the best practices guide covers using values. In this part of the\nguide, we provide recommendations on how you should structure and use your\nvalues, with focus on designing a chart's `values.yaml` file.\n\n## Naming Conventions\n\nVariables names should begin with a lowercase letter, and words should be\nseparated with camelcase:\n\nCorrect:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nIncorrect:\n\n```yaml\nChicken: true  # initial caps may conflict with built-ins\nchicken-noodle-soup: true # do not use hyphens in the name\n```\n\nNote that all of Helm's built-in variables begin with an uppercase letter to\neasily distinguish them from user-defined values: `.Release.Name`,\n`.Capabilities.KubeVersion`.\n\n## Flat or Nested Values\n\nYAML is a flexible format, and values may be nested deeply or flattened.\n\nNested:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nFlat:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nIn most cases, flat should be favored over nested. The reason for this is that\nit is simpler for template developers and users.\n\n\nFor optimal safety, a nested value must be checked at every level:\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nFor every layer of nesting, an existence check must be done. But for flat\nconfiguration, such checks can be skipped, making the template easier to read\nand use.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\nWhen there are a large number of related variables, and at least one of them\nis non-optional, nested values may be used to improve readability.\n\n## Make Types Clear\n\nYAML's type coercion rules are sometimes counterintuitive. For example,\n`foo: false` is not the same as `foo: \"false\"`. Large integers like `foo: 12345678`\nwill get converted to scientific notation in some cases.\n\nThe easiest way to avoid type conversion errors is to be explicit about strings,\nand implicit about everything else. Or, in short, _quote all strings_.\n\nOften, to avoid the integer casting issues, it is advantageous to store your\nintegers as strings as well, and use `{{ int $value }}` in the template to convert\nfrom a string back to an integer.\n\nIn most cases, explicit type tags are respected, so `foo: !!string 1234` should\ntreat `1234` as a string. _However_, the YAML parser consumes tags, so the type\ndata is lost after one parse.\n\n## Consider How Users Will Use Your Values\n\nThere are four potential sources of values:\n\n- A chart's `values.yaml` file\n- A values file supplied by `helm install -f` or `helm upgrade -f`\n- The values passed to a `--set` or `--set-string` flag on `helm install` or `helm upgrade`\n- The content of a file passed to `--set-file` flag on `helm install` or `helm upgrade`\n\nWhen designing the structure of your values, keep in mind that users of your\nchart may want to override them via either the `-f` flag or with the `--set`\noption.\n\nSince `--set` is more limited in expressiveness, the first guidelines for writing\nyour `values.yaml` file is _make it easy to override from `--set`_.\n\nFor this reason, it's often better to structure your values file using maps.\n\nDifficult to use with `--set`:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nThe above cannot be expressed with `--set` in Helm `<=2.4`. In Helm 2.5, the\naccessing the port on foo is `--set servers[0].port=80`. Not only is it harder\nfor the user to figure out, but it is prone to errors if at some later time the\norder of the `servers` is changed.\n\nEasy to use:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nAccessing foo's port is much more obvious: `--set servers.foo.port=80`.\n\n## Document 'values.yaml'\n\nEvery 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.\n\nIncorrect:\n\n```\n# the host name for the webserver\nserverHost = example\nserverPort = 9191\n```\n\nCorrect:\n\n```\n# serverHost is the host name for the webserver\nserverHost = example\n# serverPort is the HTTP listener port for the webserver\nserverPort = 9191\n\n```\n\nBeginning 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.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/accessing_files.md",
    "content": "---\nsidebar_position: 8\nsidebar_label: \"Accessing Files Inside Templates\"\n---\n# Accessing Files Inside Templates\n\nIn 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.\n\nHelm 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:\n\n- 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.\n- Some files cannot be accessed through the `.Files` object, usually for security reasons.\n  - Files in `templates/` cannot be accessed.\n  - Files excluded using `.helmignore` cannot be accessed.\n- 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.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Basic example](#basic-example)\n- [Path helpers](#path-helpers)\n- [Glob patterns](#glob-patterns)\n- [ConfigMap and Secrets utility functions](#configmap-and-secrets-utility-functions)\n- [Encoding](#encoding)\n- [Lines](#lines)\n\n<!-- tocstop -->\n\n## Basic example\n\nWith 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.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nEach 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.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range list \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nThis 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 . }}`.\n\nRunning this template will produce a single ConfigMap with the contents of all three files:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Path helpers\n\nWhen working with files, it can be very useful to perform some standard\noperations on the file paths themselves. To help with this, Helm imports many of\nthe functions from Go's [path](https://golang.org/pkg/path/) package for your\nuse. They are all accessible with the same names as in the Go package, but\nwith a lowercase first letter. For example, `Base` becomes `base`, etc.\n\nThe imported functions are:\n\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Glob patterns\n\nAs your chart grows, you may find you have a greater need to organize your\nfiles more, and so we provide a `Files.Glob(pattern string)` method to assist\nin extracting certain files with all the flexibility of [glob patterns](https://godoc.org/github.com/gobwas/glob).\n\n`.Glob` returns a `Files` type, so you may call any of the `Files` methods on\nthe returned object.\n\nFor example, imagine the directory structure:\n\n```txt\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nYou have multiple options with Globs:\n\n```yaml\n{{ $root := . }}\n{{ range $path, $bytes := .Files.Glob \"**.yaml\" }}\n{{ $path }}: |-\n{{ $root.Files.Get $path }}\n{{ end }}\n```\n\nOr\n\n```yaml\n{{ $root := . }}\n{{ range $path, $bytes := .Files.Glob \"foo/*\" }}\n{{ base $path }}: '{{ $root.Files.Get $path | b64enc }}'\n{{ end }}\n```\n\n## ConfigMap and Secrets utility functions\n\n(Not present in version 2.0.2 or prior)\n\nIt is very common to want to place file content into both configmaps and\nsecrets, for mounting into your pods at run time. To help with this, we provide a\ncouple utility methods on the `Files` type.\n\nFor further organization, it is especially useful to use these methods in\nconjunction with the `Glob` method.\n\nGiven the directory structure from the [Glob](#glob-patterns) example above:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n  {{- (.Files.Glob \"foo/*\").AsConfig | nindent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n  {{- (.Files.Glob \"bar/*\").AsSecrets | nindent 2 }}\n```\n\n## Encoding\n\nYou can import a file and have the template base-64 encode it to ensure successful transmission:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nThe above will take the same `config1.toml` file we used before and encode it:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9IEhlbGxvIGZyb20gY29uZmlnIDEK\n```\n\n## Lines\n\nSometimes it is desirable to access each line of a file in your template. We\nprovide a convenient `Lines` method for this.\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nCurrently, 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`.\n\nThis 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.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/builtin_objects.md",
    "content": "---\nsidebar_position: 2\nsidebar_label: \"Built-In Objects\"\n---\n# Built-in Objects\n\nObjects 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.\n\nObjects 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.\n\nIn 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.\n\n- `Release`: This object describes the release itself. It has several objects inside of it:\n  - `Release.Name`: The release name\n  - `Release.Time`: The time of the release\n  - `Release.Namespace`: The namespace to be released into (if the manifest doesn't override)\n  - `Release.Service`: The name of the releasing service (always `Tiller`).\n  - `Release.Revision`: The revision number of this release. It begins at 1 and is incremented for each `helm upgrade`.\n  - `Release.IsUpgrade`: This is set to `true` if the current operation is an upgrade or rollback.\n  - `Release.IsInstall`: This is set to `true` if the current operation is an install.\n- `Values`: Values passed into the template from the `values.yaml` file and from user-supplied files. By default, `Values` is empty.\n- `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`.\n  - The available fields are listed in the [Charts Guide](https://github.com/helm/helm/blob/master/docs/charts.md#the-chartyaml-file)\n- `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.\n  - `Files.Get` is a function for getting a file by name (`.Files.Get config.ini`)\n  - `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.\n- `Capabilities`: This provides information about what capabilities the Kubernetes cluster supports.\n  - `Capabilities.APIVersions` is a set of versions.\n  - `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.\n  - `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`.\n  - `Capabilities.TillerVersion` provides a way to look up the Tiller version. It has the following values: `SemVer`, `GitCommit`, and `GitTreeState`.\n- `Template`: Contains information about the current template that is being executed\n  - `Name`: A namespaced filepath to the current template (e.g. `mychart/templates/mytemplate.yaml`)\n  - `BasePath`: The namespaced path to the templates directory of the current chart (e.g. `mychart/templates`).\n\nThe values are available to any top-level template. As we will see later, this does not necessarily mean that they will be available _everywhere_.\n\nThe 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.\n\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/chart_template_guide.md",
    "content": "---\nsidebar_position: 6\nsidebar_label: \"Developing Templates\"\n# This is the index/landing page for this section\n---\n# The Chart Template Developer's Guide\n\nThis guide provides an introduction to Helm's chart templates, with emphasis on\nthe template language.\n\nTemplates generate manifest files, which are YAML-formatted resource descriptions\nthat Kubernetes can understand. We'll look at how templates are structured,\nhow they can be used, how to write Go templates, and how to debug your work.\n\nThis guide focuses on the following concepts:\n\n- The Helm template language\n- Using values\n- Techniques for working with templates\n\nThis guide is oriented toward learning the ins and outs of the Helm template language. Other guides provide introductory material, examples, and best practices."
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/control_structures.md",
    "content": "---\nsidebar_position: 5\nsidebar_label: \"Flow Control\"\n---\n# Flow Control\n\nControl 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:\n\n- `if`/`else` for creating conditional blocks\n- `with` to specify a scope\n- `range`, which provides a \"for each\"-style loop\n\nIn addition to these, it provides a few actions for declaring and using named template segments:\n\n- `define` declares a new named template inside of your template\n- `template` imports a named template\n- `block` declares a special kind of fillable template area\n\nIn this section, we'll talk about `if`, `with`, and `range`. The others are covered in the \"Named Templates\" section later in this guide.\n\n## If/Else\n\nThe first control structure we'll look at is for conditionally including blocks of text in a template. This is the `if`/`else` block.\n\nThe basic structure for a conditional looks like this:\n\n```yaml\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\nNotice 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.\n\nA pipeline is evaluated as _false_ if the value is:\n\n- a boolean false\n- a numeric zero\n- an empty string\n- a `nil` (empty or null)\n- an empty collection (`map`, `slice`, `tuple`, `dict`, `array`)\n\nIn any other case, the condition is evaluated to _true_ and the pipeline is executed.\n\nLet's add a simple conditional to our ConfigMap. We'll add another setting if the drink is set to coffee:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if and .Values.favorite.drink (eq .Values.favorite.drink \"coffee\") }}mug: true{{ end }}\n```\n\nNote 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:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: true\n```\n\n## Controlling Whitespace\n\nWhile 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:\n\n```\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{if eq .Values.favorite.drink \"coffee\"}}\n    mug: true\n  {{end}}\n```\n\nInitially, this looks good. But if we run it through the template engine, we'll get an unfortunate result:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nWhat happened? We generated incorrect YAML because of the whitespacing above. \n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: true\n```\n\n`mug` is incorrectly indented. Let's simply out-dent that one line, and re-run:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{if eq .Values.favorite.drink \"coffee\"}}\n  mug: true\n  {{end}}\n```\n\nWhen we sent that, we'll get YAML that is valid, but still looks a little funny:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: true\n\n```\n\nNotice 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.\n\nYAML ascribes meaning to whitespace, so managing the whitespace becomes pretty important. Fortunately, Helm templates have a few tools to help.\n\nFirst, 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!_\n\n> 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\".\n\nUsing this syntax, we can modify our template to get rid of those new lines:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\"}}\n  mug: true\n  {{- end}}\n```\n\nJust 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\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\"}}\n  mug: true*\n**{{- end}}\n\n```\n\nKeeping that in mind, we can run our template through Helm and see the result:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: true\n```\n\nBe careful with the chomping modifiers. It is easy to accidentally do things like this:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: true\n  {{- end -}}\n\n```\n\nThat will produce `food: \"PIZZA\"mug:true` because it consumed newlines on both sides.\n\n> For the details on whitespace control in templates, see the [Official Go template documentation](https://godoc.org/text/template)\n\nFinally, 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\"}}`).\n\n## Modifying scope using `with`\n\nThe 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.\n\nThe syntax for `with` is similar to a simple `if` statement:\n\n```yaml\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\nScopes 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`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\n(Note that we removed the `if` conditional from the previous exercise)\n\nNotice 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 }}`.\n\nBut 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:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nIt 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}}`.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nAfter looking at `range`, we will take a look at template variables, which offers one solution to the scoping issue above.\n\n## Looping with the `range` action\n\nMany 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.\n\nTo start, let's add a list of pizza toppings to our `values.yaml` file:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n```\n\nNow we have a list (called a `slice` in templates) of `pizzaToppings`. We can modify our template to print this list into our ConfigMap:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nLet'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.\n\nWe 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:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n```\n\nNow, 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.\n\n> 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.\n\nSometimes 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`.\n\n```yaml\n  sizes: |-\n    {{- range list \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nThe above will produce this:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nIn 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.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/data_types.md",
    "content": "---\nsidebar_position: 15\nsidebar_label: \"Appendix: Go Data Types and Templates\"\n---\n# Appendix: Go Data Types and Templates\n\nThe 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:\n\n- string: A string of text\n- bool: a `true` or `false`\n- int: An integer value (there are also 8, 16, 32, and 64 bit signed and unsigned variants of this)\n- float64: a 64-bit floating point value (there are also 8, 16, and 32 bit varieties of this)\n- a byte slice (`[]byte`), often used to hold (potentially) binary data\n- struct: an object with properties and methods\n- a slice (indexed list) of one of the previous types\n- a string-keyed map (`map[string]interface{}`) where the value is one of the previous types\n\nThere 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."
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/debugging.md",
    "content": "---\nsidebar_position: 12\nsidebar_label: \"Debugging Templates\"\n---\n# Debugging Templates\n\nDebugging 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.\n\nThere are a few commands that can help you debug.\n\n- `helm lint` is your go-to tool for verifying that your chart follows best practices\n- `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.\n- `helm get manifest`: This is a good way to see what templates are installed on the server.\n\nWhen your YAML is failing to parse, but you want to see what is generated, one\neasy way to retrieve the YAML is to comment out the problem section in the template,\nand then re-run `helm install --dry-run --debug`:\n\n```yaml\napiVersion: v1\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\nThe above will be rendered and returned with the comments intact:\n\n```yaml\napiVersion: v1\n# some: problem section\n#  \"bar\"\n```\n\nThis provides a quick way of viewing the generated content without YAML parse\nerrors blocking.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/functions_and_pipelines.md",
    "content": "---\nsidebar_position: 4\nsidebar_label: \"Template Functions and Pipelines\"\n---\n# Template Functions and Pipelines\n\nSo 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.\n\nLet'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:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nTemplate 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.\n\nHelm 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.\n\n> 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.\n\n## Pipelines\n\nOne 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.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nIn 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:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Inverting the order is a common practice in templates. You will see `.val | quote` more often than `quote .val`. Either practice is fine.\n\nWhen evaluated, that template will produce this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nNote that our original `pizza` has now been transformed to `\"PIZZA\"`.\n\nWhen 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`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nThe `repeat` function will echo the given string the given number of times, so we will get this for output:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Using the `default` function\n\nOne 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:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nIf we run this as normal, we'll get our `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nNow, we will remove the favorite drink setting from `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nNow re-running `helm install --dry-run --debug ./mychart` will produce this YAML:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nIn 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:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nIn some places, an `if` conditional guard may be better suited than `default`. We'll see those in the next section.\n\nTemplate 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.\n\n## Operators are functions\n\nOperators 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.\n\n```yaml\n{{/* include the body of this if statement when the variable .Values.fooString exists and is set to \"foo\" */}}\n{{ if and .Values.fooString (eq .Values.fooString \"foo\") }}\n    {{ ... }}\n{{ end }}\n\n\n{{/* include the body of this if statement when the variable .Values.anUnsetVariable is set or .values.aSetVariable is not set */}}\n{{ if or .Values.anUnsetVariable (not .Values.aSetVariable) }}\n   {{ ... }}\n{{ end }}\n```\n\nNow we can turn from functions and pipelines to flow control with conditions, loops, and scope modifiers.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/getting_started.md",
    "content": "---\nsidebar_position: 1\nsidebar_label: \"Getting Started\"\n---\n# Getting Started with a Chart Template\n\nIn 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.\n\nTo get going, let's take a brief look at a Helm chart.\n\n## Charts\n\nAs described in the [Charts Guide](../developing_charts/developing_charts.md), Helm charts are structured like\nthis:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nThe `templates/` directory is for template files. When Tiller evaluates a chart,\nit will send all of the files in the `templates/` directory through the\ntemplate rendering engine. Tiller then collects the results of those templates\nand sends them on to Kubernetes.\n\nThe `values.yaml` file is also important to templates. This file contains the\n_default values_ for a chart. These values may be overridden by users during\n`helm install` or `helm upgrade`.\n\nThe `Chart.yaml` file contains a description of the chart. You can access it\nfrom within a template. The `charts/` directory _may_ contain other charts (which\nwe call _subcharts_). Later in this guide we will see how those work when it\ncomes to template rendering.\n\n## A Starter Chart\n\nFor this guide, we'll create a simple chart called `mychart`, and then we'll\ncreate some templates inside of the chart.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nFrom here on, we'll be working in the `mychart` directory.\n\n### A Quick Glimpse of `mychart/templates/`\n\nIf you take a look at the `mychart/templates/` directory, you'll notice a few files\nalready there.\n\n- `NOTES.txt`: The \"help text\" for your chart. This will be displayed to your users\n  when they run `helm install`.\n- `deployment.yaml`: A basic manifest for creating a Kubernetes [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n- `service.yaml`: A basic manifest for creating a [service endpoint](https://kubernetes.io/docs/concepts/services-networking/service/) for your deployment\n- `_helpers.tpl`: A place to put template helpers that you can re-use throughout the chart\n\nAnd 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.\n\n```console\n$ rm -rf mychart/templates/*.*\n```\n\nWhen 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.\n\n## A First Template\n\nThe first template we are going to create will be a `ConfigMap`. In Kubernetes,\na ConfigMap is simply a container for storing configuration data. Other things,\nlike pods, can access the data in a ConfigMap.\n\nBecause ConfigMaps are basic resources, they make a great starting point for us.\n\nLet's begin by creating a file called `mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**TIP:** Template names do not follow a rigid naming pattern. However, we recommend\nusing the suffix `.yaml` for YAML files and `.tpl` for helpers.\n\nThe YAML file above is a bare-bones ConfigMap, having the minimal necessary fields.\nIn virtue of the fact that this file is in the `templates/` directory, it will\nbe sent through the template engine.\n\nIt is just fine to put a plain YAML file like this in the `templates/` directory.\nWhen Tiller reads this template, it will simply send it to Kubernetes as-is.\n\nWith this simple template, we now have an installable chart. And we can install\nit like this:\n\n```console\n$ helm install ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\n\nRESOURCES:\n==> v1/ConfigMap\nNAME                DATA      AGE\nmychart-configmap   1         1m\n```\n\nIn the output above, we can see that our ConfigMap was created. Using Helm, we\ncan retrieve the release and see the actual template that was loaded.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nThe `helm get manifest` command takes a release name (`full-coral`) and prints\nout all of the Kubernetes resources that were uploaded to the server. Each file\nbegins with `---` to indicate the start of a YAML document, and then is followed\nby an automatically generated comment line that tells us what template file\ngenerated this YAML document.\n\nFrom there on, we can see that the YAML data is exactly what we put in our\n`configmap.yaml` file.\n\nNow we can delete our release: `helm delete full-coral`.\n\n### Adding a Simple Template Call\n\nHard-coding the `name:` into a resource is usually considered to be bad practice.\nNames should be unique to a release. So we might want to generate a name field\nby inserting the release name.\n\n**TIP:** The `name:` field is limited to 63 characters because of limitations to\nthe DNS system. For that reason, release names are limited to 53 characters.\nKubernetes 1.3 and earlier limited to only 24 characters (thus 14 character names).\n\nLet's alter `configmap.yaml` accordingly.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nThe big change comes in the value of the `name:` field, which is now\n`{{ .Release.Name }}-configmap`.\n\n> A template directive is enclosed in `{{` and `}}` blocks.\n\nThe 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.\n\nThe 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`\".\n\nThe `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.\n\nNow when we install our resource, we'll immediately see the result of using this template directive:\n\n```console\n$ helm install ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\n\nRESOURCES:\n==> v1/ConfigMap\nNAME                      DATA      AGE\nclunky-serval-configmap   1         1m\n```\n\nNote that in the `RESOURCES` section, the name we see there is `clunky-serval-configmap`\ninstead of `mychart-configmap`.\n\nYou can run `helm get manifest clunky-serval` to see the entire generated YAML.\n\nAt 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:\n\n```console\n$ helm install ./mychart --debug --dry-run\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart\nNAME:   goodly-guppy\nTARGET NAMESPACE:   default\nCHART:  mychart 0.1.0\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nUsing `--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.\n\nIn 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.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/helm_ignore_file.md",
    "content": "---\nsidebar_position: 11\nsidebar_label: \"The .helmignore File\"\n---\n# The .helmignore file\n\nThe `.helmignore` file is used to specify files you don't want to include in your helm chart.\n\nIf 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.\n\nThis can help in avoiding unnecessary or sensitive files or directories from being added in your helm chart.\n\nThe `.helmignore` file supports Unix shell glob matching, relative path matching, and negation (prefixed with !). Only one pattern per line is considered.\n\nHere is an example `.helmignore` file:\n\n```\n# comment\n.git\n*/temp*\n*/*/temp*\ntemp?\n```\n\n**We'd love your help** making this document better. To add, correct, or remove\ninformation, [file an issue](https://github.com/helm/helm/issues) or\nsend us a pull request.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/named_templates.md",
    "content": "---\nsidebar_position: 7\nsidebar_label: \"Named Templates\"\n---\n# Named Templates\n\nIt 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.\n\nIn 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.\n\nAn 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_.\n\nOne 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.\n\n## Partials and `_` files\n\nSo 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.\n\nBefore we get to the nuts-and-bolts of writing those templates, there is file naming convention that deserves mention:\n\n- Most files in `templates/` are treated as if they contain Kubernetes manifests\n- The `NOTES.txt` is one exception\n- 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.\n\nThese 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.\n\n## Declaring and using templates with `define` and `template`\n\nThe `define` action allows us to create a named template inside of a template file. Its syntax goes like this:\n\n```yaml\n{{ define \"MY.NAME\" }}\n  # body of template here\n{{ end }}\n```\n\nFor example, we can define a template to encapsulate a Kubernetes block of labels:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nNow we can embed this template inside of our existing ConfigMap, and then include it with the `template` action:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nWhen 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:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nConventionally, Helm charts put these templates inside of a partials file, usually `_helpers.tpl`. Let's move this function there:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nBy convention, `define` functions should have a simple documentation block (`{{/* ... */}}`) describing what they do.\n\nEven though this definition is in `_helpers.tpl`, it can still be accessed in `configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nAs 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\" }}`.\n\n## Setting the scope of a template\n\nIn 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:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nIf we render this, the result will not be what we expect:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\n    chart:\n    version:\n```\n\nWhat 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:\n\n```gotpl\n{{- template \"mychart.labels\" }}\n```\n\nNo 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:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nNote 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.\n\nNow when we execute this template with `helm install --dry-run --debug ./mychart`, we get this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\n    chart: mychart\n    version: 0.1.0\n```\n\nNow `{{ .Chart.Name }}` resolves to `mychart`, and `{{ .Chart.Version }}` resolves to `0.1.0`.\n\n## The `include` function\n\nSay we've defined a simple template that looks like this:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}+{{ .Release.Time.Seconds }}\"\n{{- end -}}\n```\n\nNow say I want to insert this both into the `labels:` section of my template, and also the `data:` section:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" .}}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nThe output will not be what we expect:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0+1478129847\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0+1478129847\"\n```\n\nNote 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.\n\nTo 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.\n\nHere's the example above, corrected to use `nindent` to indent the `mychart_app` template correctly:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{- include \"mychart.app\" . | nindent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n  {{- include \"mychart.app\" . | nindent 2 }}\n```\n\nNow the produced YAML is correctly indented for each section:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0+1478129987\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0+1478129987\"\n```\n\n> 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.\n\nSometimes 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.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/notes_files.md",
    "content": "---\nsidebar_position: 9\nsidebar_label: \"Creating a NOTES.txt File\"\n---\n# Creating a NOTES.txt File\n\nIn 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.\n\nTo 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.\n\nLet's create a simple `NOTES.txt` file:\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get {{ .Release.Name }}\n\n```\n\nNow if we run `helm install ./mychart` we will see this message at the bottom:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get rude-cardinal\n```\n\nUsing `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.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/subcharts_and_globals.md",
    "content": "---\nsidebar_position: 10\nsidebar_label: \"Subcharts and Global Values\"\n---\n# Subcharts and Global Values\n\nTo 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.\n\nBefore we dive into the code, there are a few important details to learn about subcharts.\n\n1. A subchart is considered \"stand-alone\", which means a subchart can never explicitly depend on its parent chart.\n2. For that reason, a subchart cannot access the values of its parent.\n3. A parent chart can override values for subcharts.\n4. Helm has a concept of _global values_ that can be accessed by all charts.\n\nAs we walk through the examples in this section, many of these concepts will become clearer.\n\n## Creating a Subchart\n\nFor 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.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*.*\n```\n\nNotice 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.\n\n## Adding Values and a Template to the Subchart\n\nNext, 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:\n\n```yaml\ndessert: cake\n```\n\nNext, we'll create a new ConfigMap template in `mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nBecause every subchart is a _stand-alone chart_, we can test `mysubchart` on its own:\n\n```console\n$ helm install --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Overriding Values of a Child Chart\n\nOur original chart, `mychart` is now the _parent_ chart of `mysubchart`. This relationship is based entirely on the fact that `mysubchart` is within `mychart/charts`.\n\nBecause `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:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nNote 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:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nThe value at the top level has now overridden the value of the subchart.\n\nThere'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`.\n\nSometimes, though, you do want certain values to be available to all of the templates. This is accomplished using global chart values.\n\n## Global Chart Values\n\nGlobal 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.\n\nThe 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.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nBecause 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}}`.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nNow if we run a dry run install, we'll see the same value in both outputs:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nGlobals are useful for passing information like this, though it does take some planning to make sure the right templates are configured to use globals.\n\n## Sharing Templates with Subcharts\n\nParent charts and subcharts can share templates. Any defined block in any chart is\navailable to other charts.\n\nFor example, we can define a simple template like this:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nRecall how the labels on templates are _globally shared_. Thus, the `labels` chart\ncan be included from any other chart.\n\nWhile chart developers have a choice between `include` and `template`, one advantage\nof using `include` is that `include` can dynamically reference templates:\n\n```yaml\n{{ include $mytemplate }}\n```\n\nThe above will dereference `$mytemplate`. The `template` function, in contrast,\nwill only accept a string literal.\n\n## Avoid Using Blocks\n\nThe Go template language provides a `block` keyword that allows developers to provide\na default implementation which is overridden later. In Helm charts, blocks are not\nthe best tool for overriding because if multiple implementations of the same block\nare provided, the one selected is unpredictable.\n\nThe suggestion is to instead use `include`.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/values_files.md",
    "content": "---\nsidebar_position: 3\nsidebar_label: \"Values Files\"\n---\n# Values Files\n\nIn 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:\n\n- The `values.yaml` file in the chart\n- If this is a subchart, the `values.yaml` file of a parent chart\n- A values file is passed into `helm install` or `helm upgrade` with the `-f` flag (`helm install -f myvals.yaml ./mychart`)\n- Individual parameters passed with `--set` (such as `helm install --set foo=bar ./mychart`)\n\nThe 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.\n\nValues files are plain YAML files. Let's edit `mychart/values.yaml` and then edit our ConfigMap template.\n\nRemoving the defaults in `values.yaml`, we'll set just one parameter:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nNow we can use this inside of a template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nNotice on the last line we access `favoriteDrink` as an attribute of `Values`: `{{ .Values.favoriteDrink }}`.\n\nLet's see how this renders.\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart\nNAME:   geared-marsupi\nTARGET NAMESPACE:   default\nCHART:  mychart 0.1.0\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nBecause `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`:\n\n```console\nhelm install --dry-run --debug --set favoriteDrink=slurm ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart\nNAME:   solid-vulture\nTARGET NAMESPACE:   default\nCHART:  mychart 0.1.0\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nSince `--set` has a higher precedence than the default `values.yaml` file, our template generates `drink: slurm`.\n\nValues 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:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nNow we would have to modify the template slightly:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nWhile 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.\n\n## Deleting a default key\n\nIf 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.\n\nFor example, the stable Drupal chart allows configuring the liveness probe, in case you configure a custom image. Here are the default values:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nIf 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:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nHowever, 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:\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nAt 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.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/variables.md",
    "content": "---\nsidebar_position: 6\nsidebar_label: \"Variables\"\n---\n# Variables\n\nWith 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`.\n\nIn an earlier example, we saw that this code will fail:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`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.\n\nIn 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`.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nNotice 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.\n\nRunning that will produce this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nVariables are particularly useful in `range` loops. They can be used on list-like objects to capture both the index and the value:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nNote 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:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nFor 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:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end}}\n```\n\nNow 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:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nVariables 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.\n\nHowever, 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.\n\nAn example illustrating this:\n```yaml\n{{- range .Values.tlsSecrets }}\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Many helm templates would use `.` below, but that will not work,\n    # however `$` will work here\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # I cannot reference .Chart.Name, but I can do $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Value from appVersion in Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n---\n{{- end }}\n```\n\nSo 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.\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/wrapping_up.md",
    "content": "---\nsidebar_position: 13\nsidebar_label: \"Next Steps\"\n---\n# Wrapping Up\n\nThis 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.\n\nBut 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:\n\n- 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.\n- 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.\n- The Helm [Charts Guide](../developing_charts/developing_charts.md) explains the workflow of using charts.\n- The Helm [Chart Hooks Guide](../developing_charts/charts_hooks.md) explains how to create lifecycle hooks.\n- The Helm [Charts Tips and Tricks](../developing_charts/charts_tips_and_tricks.md) article provides some useful tips for writing charts.\n- The [Sprig documentation](https://github.com/Masterminds/sprig) documents more than sixty of the template functions.\n- The [Go template docs](https://godoc.org/text/template) explain the template syntax in detail.\n- The [Schelm tool](https://github.com/databus23/schelm) is a nice helper utility for debugging charts.\n\nSometimes 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:\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nFinally, 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).\n"
  },
  {
    "path": "versioned_docs/version-2/chart_template_guide/yaml_techniques.md",
    "content": "---\nsidebar_position: 14\nsidebar_label: \"Appendix: YAML Techniques\"\n---\n# YAML Techniques\n\nMost of this guide has been focused on writing the template language. Here,\nwe'll look at the YAML format. YAML has some useful features that we, as\ntemplate authors, can use to make our templates less error prone and easier\nto read.\n\n## Scalars and Collections\n\nAccording to the [YAML spec](https://yaml.org/spec/1.2/spec.html), there are two\ntypes of collections, and many scalar types.\n\nThe two types of collections are maps and sequences:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nScalar values are individual values (as opposed to collections)\n\n### Scalar Types in YAML\n\nIn Helm's dialect of YAML, the scalar data type of a value is determined by a\ncomplex set of rules, including the Kubernetes schema for resource definitions.\nBut when inferring types, the following rules tend to hold true.\n\nIf an integer or float is an unquoted bare word, it is typically treated as\na numeric type:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nBut if they are quoted, they are treated as strings:\n\n```yaml\ncount: \"1\" # <-- string, not int\nsize: '2.34' # <-- string, not float\n```\n\nThe same is true of booleans:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # string\n```\n\nThe word for an empty value is `null` (not `nil`).\n\nNote that `port: \"80\"` is valid YAML, and will pass through both the\ntemplate engine and the YAML parser, but will fail if Kubernetes expects\n`port` to be an integer.\n\nIn some cases, you can force a particular type inference using YAML node tags:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nIn the above, `!!str` tells the parser that `age` is a string, even if it looks\nlike an int. And `port` is treated as an int, even though it is quoted.\n\n\n## Strings in YAML\n\nMuch of the data that we place in YAML documents are strings. YAML has more than\none way to represent a string. This section explains the ways and demonstrates\nhow to use some of them.\n\nThere are three \"inline\" ways of declaring a string:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nAll inline styles must be on one line.\n\n- Bare words are unquoted, and are not escaped. For this reason, you have to\n  be careful what characters you use.\n- Double-quoted strings can have specific characters escaped with `\\`. For\n  example `\"\\\"Hello\\\", she said\"`. You can escape line breaks with `\\n`.\n- Single-quoted strings are \"literal\" strings, and do not use the `\\` to\n  escape characters. The only escape sequence is `''`, which is decoded as\n  a single `'`.\n\nIn addition to the one-line strings, you can declare multi-line strings:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nThe above will treat the value of `coffee` as a single string equivalent to\n`Latte\\nCappuccino\\nEspresso\\n`.\n\nNote that the first line after the `|` must be correctly indented. So we could\nbreak the example above by doing this:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nBecause `Latte` is incorrectly indented, we'd get an error like this:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nIn templates, it is sometimes safer to put a fake \"first line\" of content in a\nmulti-line document just for protection from the above error:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nNote that whatever that first line is, it will be preserved in the output of the\nstring. So if you are, for example, using this technique to inject a file's contents\ninto a ConfigMap, the comment should be of the type expected by whatever is\nreading that entry.\n\n### Controlling Spaces in Multi-line Strings\n\nIn the example above, we used `|` to indicate a multi-line string. But notice\nthat the content of our string was followed with a trailing `\\n`. If we want\nthe YAML processor to strip off the trailing newline, we can add a `-` after the\n`|`:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nNow the `coffee` value will be: `Latte\\nCappuccino\\nEspresso` (with no trailing\n`\\n`).\n\nOther times, we might want all trailing whitespace to be preserved. We can do\nthis with the `|+` notation:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nNow the value of `coffee` will be `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nIndentation inside of a text block is preserved, and results in the preservation\nof line breaks, too:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nIn the above case, `coffee` will be `Latte\\n  12 oz\\n  16 oz\\nCappuccino\\nEspresso`.\n\n### Indenting and Templates\n\nWhen writing templates, you may find yourself wanting to inject the contents of\na file into the template. As we saw in previous chapters, there are two ways\nof doing this:\n\n- Use `{{ .Files.Get \"FILENAME\" }}` to get the contents of a file in the chart.\n- Use `{{ include \"TEMPLATE\" . }}` to render a template and then place its\n  contents into the chart.\n\nWhen inserting files into YAML, it's good to understand the multi-line rules above.\nOften times, the easiest way to insert a static file is to do something like\nthis:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nNote how we do the indentation above: `indent 2` tells the template engine to\nindent every line in \"myfile.txt\" with two spaces. Note that we do not indent\nthat template line. That's because if we did, the file content of the first line\nwould be indented twice.\n\n### Folded Multi-line Strings\n\nSometimes you want to represent a string in your YAML with multiple lines, but\nwant it to be treated as one long line when it is interpreted. This is called\n\"folding\". To declare a folded block, use `>` instead of `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nThe value of `coffee` above will be `Latte Cappuccino Espresso\\n`. Note that all\nbut the last line feed will be converted to spaces. You can combine the whitespace\ncontrols with the folded text marker, so `>-` will replace or trim all newlines.\n\nNote that in the folded syntax, indenting text will cause lines to be preserved.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nThe above will produce `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Note that\nboth the spacing and the newlines are still there.\n\n## Embedding Multiple Documents in One File\n\nIt is possible to place more than one YAML documents into a single file. This\nis done by prefixing a new document with `---` and ending the document with\n`...`\n\n```yaml\n\n---\ndocument:1\n...\n---\ndocument: 2\n...\n```\n\nIn many cases, either the `---` or the `...` may be omitted.\n\nSome files in Helm cannot contain more than one doc. If, for example, more\nthan one document is provided inside of a `values.yaml` file, only the first\nwill be used.\n\nTemplate files, however, may have more than one document. When this happens,\nthe file (and all of its documents) is treated as one object during\ntemplate rendering. But then the resulting YAML is split into multiple\ndocuments before it is fed to Kubernetes.\n\nWe recommend only using multiple documents per file when it is absolutely\nnecessary. Having multiple documents in a file can be difficult to debug.\n\n## YAML is a Superset of JSON\n\nBecause YAML is a superset of JSON, any valid JSON document _should_ be valid\nYAML.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nThe above is another way of representing this:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nAnd the two can be mixed (with care):\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nAll three of these should parse into the same internal representation.\n\nWhile this means that files such as `values.yaml` may contain JSON data, Helm\ndoes not treat the file extension `.json` as a valid suffix.\n\n## YAML Anchors\n\nThe YAML spec provides a way to store a reference to a value, and later\nrefer to that value by reference. YAML refers to this as \"anchoring\":\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappucino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nIn the above, `&favoriteCoffee` sets a reference to `Cappuccino`. Later, that\nreference is used as `*favoriteCoffee`. So `coffees` becomes\n`Latte, Cappuccino, Espresso`.\n\nWhile there are a few cases where anchors are useful, there is one aspect of\nthem that can cause subtle bugs: The first time the YAML is consumed, the\nreference is expanded and then discarded.\n\nSo if we were to decode and then re-encode the example above, the resulting\nYAML would be:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappucino\ncoffees:\n- Latte\n- Cappucino\n- Espresso\n```\n\nBecause Helm and Kubernetes often read, modify, and then rewrite YAML files,\nthe anchors will be lost.\n"
  },
  {
    "path": "versioned_docs/version-2/developers.md",
    "content": "---\nsidebar_position: 10\nsidebar_label: \"Developer Guide\"\n---\n# Developers Guide\n\nThis guide explains how to set up your environment for developing on\nHelm and Tiller.\n\n## Prerequisites\n\n- The latest version of Go\n- The latest version of Glide\n- A Kubernetes cluster w/ kubectl (optional)\n- The gRPC toolchain\n- Git\n\n## Building Helm/Tiller\n\nWe use Make to build our programs. The simplest way to get started is:\n\n```console\n$ make bootstrap build\n```\n\nNOTE: This will fail if not running from the path `$GOPATH/src/k8s.io/helm`. The\ndirectory `k8s.io` should not be a symlink or `build` will not find the relevant\npackages.\n\nThis will build both Helm and Tiller. `make bootstrap` will attempt to\ninstall certain tools if they are missing.\n\nTo run all the tests (without running the tests for `vendor/`), run\n`make test`. To run all tests in a containerized environment, run `make\ndocker-test`.\n\nTo run Helm and Tiller locally, you can run `bin/helm` or `bin/tiller`.\n\n- Helm and Tiller are known to run on macOS and most Linux distributions, including\n  Alpine.\n- Tiller must have access to a Kubernetes cluster. It learns about the\n  cluster by examining the Kube config files that `kubectl` uses.\n\n### Man pages\n\nMan pages and Markdown documentation are already pre-built in `docs/`. You may\nregenerate documentation using `make docs`.\n\nTo expose the Helm man pages to your `man` client, you can put the files in your\n`$MANPATH`:\n\n```\n$ export MANPATH=$GOPATH/src/k8s.io/helm/docs/man:$MANPATH\n$ man helm\n```\n\n## gRPC and Protobuf\n\nHelm and Tiller communicate using gRPC. To get started with gRPC, you will need to...\n\n- Install `protoc` for compiling protobuf files. Releases are\n  [here](https://github.com/google/protobuf/releases)\n- Run Helm's `make bootstrap` to generate the `protoc-gen-go` plugin and\n  place it in `bin/`.\n\nNote that you need to be on protobuf 3.2.0 (`protoc --version`). The\nversion of `protoc-gen-go` is tied to the version of gRPC used in\nKubernetes. So the plugin is maintained locally.\n\nWhile the gRPC and ProtoBuf specs remain silent on indentation, we\nrequire that the indentation style matches the Go format specification.\nNamely, protocol buffers should use tab-based indentation and rpc\ndeclarations should follow the style of Go function declarations.\n\n### The Helm API (HAPI)\n\nWe use gRPC as an API layer. See `pkg/proto/hapi` for the generated Go code,\nand `_proto` for the protocol buffer definitions.\n\nTo regenerate the Go files from the protobuf source, `make protoc`.\n\n## Docker Images\n\nTo build Docker images, use `make docker-build`.\n\nPre-build images are already available in the official Kubernetes Helm\nGCR registry.\n\n## Running a Local Cluster\n\nFor development, we highly recommend using the\n[Kubernetes Minikube](https://github.com/kubernetes/minikube)\ndeveloper-oriented distribution. Once this is installed, you can use\n`helm init` to install into the cluster. Note that version of tiller you're using for\ndevelopment may not be available in Google Cloud Container Registry. If you're getting\nimage pull errors, you can override the version of Tiller. Example:\n\n```console\nhelm init --tiller-image=ghcr.io/helm/tiller:2.17.0\n```\n\nOr use the latest version:\n\n```console\nhelm init --canary-image\n```\n\nFor developing on Tiller, it is sometimes more expedient to run Tiller locally\ninstead of packaging it into an image and running it in-cluster. You can do\nthis by telling the Helm client to use a local instance.\n\n```console\n$ make build\n$ bin/tiller\n```\n\nAnd to configure the Helm client, use the `--host` flag or export the `HELM_HOST`\nenvironment variable:\n\n```console\n$ export HELM_HOST=localhost:44134\n$ helm install foo\n```\n\n(Note that you do not need to use `helm init` when you are running Tiller directly)\n\nTiller should run on any >= 1.3 Kubernetes cluster.\n\n## Contribution Guidelines\n\nWe welcome contributions. This project has set up some guidelines in\norder to ensure that (a) code quality remains high, (b) the project\nremains consistent, and (c) contributions follow the open source legal\nrequirements. Our intent is not to burden contributors, but to build\nelegant and high-quality open source code so that our users will benefit.\n\nMake sure you have read and understood the main CONTRIBUTING guide:\n\nhttps://github.com/helm/helm/blob/master/CONTRIBUTING.md\n\n### Structure of the Code\n\nThe code for the Helm project is organized as follows:\n\n- The individual programs are located in `cmd/`. Code inside of `cmd/`\n  is not designed for library re-use.\n- Shared libraries are stored in `pkg/`.\n- The raw ProtoBuf files are stored in `_proto/hapi` (where `hapi` stands for\n  the Helm Application Programming Interface).\n- The Go files generated from the `proto` definitions are stored in `pkg/proto`.\n- The `scripts/` directory contains a number of utility scripts. Most of these\n  are used by the CI/CD pipeline.\n- The `rootfs/` folder is used for Docker-specific files.\n- The `docs/` folder is used for documentation and examples.\n\nGo dependencies are managed with\n[Glide](https://github.com/Masterminds/glide) and stored in the\n`vendor/` directory.\n\n### Git Conventions\n\nWe use Git for our version control system. The `master` branch is the\nhome of the current development candidate. Releases are tagged.\n\nWe accept changes to the code via GitHub Pull Requests (PRs). One\nworkflow for doing this is as follows:\n\n1. Go to your `$GOPATH/src/k8s.io` directory and `git clone` the\n   `github.com/helm/helm` repository.\n2. Fork that repository into your GitHub account\n3. Add your repository as a remote for `$GOPATH/src/k8s.io/helm`\n4. Create a new working branch (`git checkout -b feat/my-feature`) and\n   do your work on that branch.\n5. When you are ready for us to review, sign your commit, push your branch to GitHub, and\n   then open a new pull request with us.\n\nFor Git commit messages, we follow the [Semantic Commit Messages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html):\n\n```\nfix(helm): add --foo flag to 'helm install'\n\nWhen 'helm install --foo bar' is run, this will print \"foo\" in the\noutput regardless of the outcome of the installation.\n\nCloses #1234\n```\n\nCommon commit types:\n\n- fix: Fix a bug or error\n- feat: Add a new feature\n- docs: Change documentation\n- test: Improve testing\n- ref: refactor existing code\n\nCommon scopes:\n\n- helm: The Helm CLI\n- tiller: The Tiller server\n- proto: Protobuf definitions\n- pkg/lint: The lint package. Follow a similar convention for any\n  package\n- `*`: two or more scopes\n\nRead more:\n- The [Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)\n  were the inspiration for this section.\n- Karma Runner [defines](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) the semantic commit message idea.\n\n### Go Conventions\n\nWe follow the Go coding style standards very closely. Typically, running\n`go fmt` will make your code beautiful for you.\n\nWe also typically follow the conventions recommended by `go lint` and\n`gometalinter`. Run `make test-style` to test the style conformance.\nIf you do not want to install all the linters from `gometalinter` into your\nglobal Go environment, you can run `make docker-test-style` which will\nrun the same tests, but isolated within a docker container.\n\nRead more:\n\n- Effective Go [introduces formatting](https://golang.org/doc/effective_go.html#formatting).\n- The Go Wiki has a great article on [formatting](https://github.com/golang/go/wiki/CodeReviewComments).\n\n### Protobuf Conventions\n\nBecause this project is largely Go code, we format our Protobuf files as\nclosely to Go as possible. There are currently no real formatting rules\nor guidelines for Protobuf, but as they emerge, we may opt to follow\nthose instead.\n\nStandards:\n- Tabs for indentation, not spaces.\n- Spacing rules follow Go conventions (curly braces at line end, spaces\n  around operators).\n\nConventions:\n- Files should specify their package with `option go_package = \"...\";`\n- Comments should translate into good Go code comments (since `protoc`\n  copies comments into the destination source code file).\n- RPC functions are defined in the same file as their request/response\n  messages.\n- Deprecated RPCs, messages, and fields are marked deprecated in the comments (`// UpdateFoo\n  DEPRECATED updates a foo.`).\n"
  },
  {
    "path": "versioned_docs/version-2/developing_charts/chart_repository.md",
    "content": "---\nsidebar_position: 3\nsidebar_label: \"Charts Repository Guide\"\n---\n# The Chart Repository Guide\n\nThis section explains how to create and work with Helm chart repositories. At a\nhigh level, a chart repository is a location where packaged charts can be\nstored and shared.\n\nThe official chart repository is maintained by the\n[Helm Charts](https://github.com/helm/charts), and we welcome\nparticipation. But Helm also makes it easy to create and run your own chart\nrepository. This guide explains how to do so.\n\n## Prerequisites\n\n* Go through the [Quickstart](../using_helm/using_helm.md) Guide\n* Read through the [Charts](developing_charts.md) document\n\n## Create a chart repository\n\nA _chart repository_ is an HTTP server that houses an `index.yaml` file and\noptionally some packaged charts.  When you're ready to share your charts, the\npreferred way to do so is by uploading them to a chart repository.\n\n**Note:** For Helm 2.0.0, chart repositories do not have any intrinsic\nauthentication. There is an [issue tracking progress](https://github.com/helm/helm/issues/1038)\nin GitHub.\n\nBecause a chart repository can be any HTTP server that can serve YAML and tar\nfiles and can answer GET requests, you have a plethora of options when it comes\ndown to hosting your own chart repository. For example, you can use a Google\nCloud Storage (GCS) bucket, Amazon S3 bucket, Github Pages, or even create your\nown web server.\n\n### The chart repository structure\n\nA chart repository consists of packaged charts and a special file called\n`index.yaml` which contains an index of all of the charts in the repository.\nFrequently, the charts that `index.yaml` describes are also hosted on the same\nserver, as are the [provenance files](provenance.md).\n\nFor example, the layout of the repository `https://example.com/charts` might\nlook like this:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nIn this case, the index file would contain information about one chart, the Alpine\nchart, and provide the download URL `https://example.com/charts/alpine-0.1.2.tgz`\nfor that chart.\n\nIt is not required that a chart package be located on the same server as the\n`index.yaml` file. However, doing so is often the easiest.\n\n### The index file\n\nThe index file is a yaml file called `index.yaml`. It\ncontains some metadata about the package, including the contents of a\nchart's `Chart.yaml` file. A valid chart repository must have an index file. The\nindex file contains information about each chart in the chart repository. The\n`helm repo index` command will generate an index file based on a given local\ndirectory that contains packaged charts.\n\nThis is an example of an index file:\n\n```\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://k8s.io/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://k8s.io/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://k8s.io/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\nA generated index and packages can be served from a basic webserver. You can test\nthings out locally with the `helm serve` command, which starts a local server.\n\n```console\n$ helm serve --repo-path ./charts\nRegenerating index. This may take a moment.\nNow serving you on 127.0.0.1:8879\n```\n\nThe above starts a local webserver, serving the charts it finds in `./charts`. The\nserve command will automatically generate an `index.yaml` file for you during\nstartup.\n\n## Hosting Chart Repositories\n\nThis part shows several ways to serve a chart repository.\n\n### ChartMuseum\n\nThe Helm project provides an open-source Helm repository server called [ChartMuseum](https://chartmuseum.com) that you can host yourself.\n\nChartMuseum 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.\n\nIt can be deployed easily as a [Helm chart](https://github.com/helm/charts/tree/master/stable/chartmuseum):\n```\nhelm install stable/chartmuseum\n```\n\nand also as a [Docker image](https://hub.docker.com/r/chartmuseum/chartmuseum/tags):\n```\ndocker run --rm -it \\\n  -p 8080:8080 \\\n  -v $(pwd)/charts:/charts \\\n  -e DEBUG=true \\\n  -e STORAGE=local \\\n  -e STORAGE_LOCAL_ROOTDIR=/charts \\\n  chartmuseum/chartmuseum\n```\n\nYou can then add the repo to your local repository list:\n```\nhelm repo add chartmuseum http://localhost:8080\n```\n\nChartMuseum provides other features, such as an API for chart uploads. Please see the [README](https://github.com/helm/chartmuseum) for more info.\n\n### Google Cloud Storage\n\nThe first step is to **create your GCS bucket**. We'll call ours\n`fantastic-charts`.\n\n![Create a GCS Bucket](/img/helm2/create-a-bucket.png)\n\nNext, make your bucket public by **editing the bucket permissions**.\n\n![Edit Permissions](/img/helm2/edit-permissions.png)\n\nInsert this line item to **make your bucket public**:\n\n![Make Bucket Public](/img/helm2/make-bucket-public.png)\n\nCongratulations, now you have an empty GCS bucket ready to serve charts!\n\nYou may upload your chart repository using the Google Cloud Storage command line\ntool, or using the GCS web UI. This is the technique the official Kubernetes\nCharts repository hosts its charts, so you may want to take a\n[peek at that project](https://github.com/helm/charts) if you get stuck.\n\n**Note:** A public GCS bucket can be accessed via simple HTTPS at this address\n`https://bucket-name.storage.googleapis.com/`.\n\n### JFrog Artifactory\n\nYou can also set up chart repositories using JFrog Artifactory.\nRead more about chart repositories with JFrog Artifactory [here](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)\n\n### ProGet\n\nHelm 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.\n\n### Sonatype Nexus Repository Manager OSS Edition\n\nHelm repositories are available in Nexus Repository Manager OSS Edition. See [Helm Repositories](https://help.sonatype.com/repomanager3/formats/helm-repositories) for details!\n\n### Github Pages example\n\nIn a similar way you can create charts repository using GitHub Pages.\n\nGitHub allows you to serve static web pages in two different ways:\n\n- By configuring a project to serve the contents of its `docs/` directory\n- By configuring a project to serve a particular branch\n\nWe'll take the second approach, though the first is just as easy.\n\nThe first step will be to **create your gh-pages branch**.  You can do that\nlocally as.\n\n```console\n$ git checkout -b gh-pages\n```\n\nOr via web browser using **Branch** button on your Github repository:\n\n![Create Github Pages branch](/img/helm2/create-a-gh-page-button.png)\n\nNext, you'll want to make sure your **gh-pages branch** is set as Github Pages,\nclick on your repo **Settings** and scroll down to **Github pages** section and\nset as per below:\n\n![Create Github Pages branch](/img/helm2/set-a-gh-page.png)\n\nBy default **Source** usually gets set to **gh-pages branch**. If this is not set by default, then select it.\n\nYou can use a **custom domain** there if you wish so.\n\nAnd check that **Enforce HTTPS** is ticked, so the **HTTPS** will be used when\ncharts are served.\n\nIn such setup you can use **master branch** to store your charts code, and\n**gh-pages branch** as charts repository, e.g.:\n`https://USERNAME.github.io/REPONAME`. The demonstration [TS Charts](https://github.com/technosophos/tscharts)\nrepository is accessible at `https://technosophos.github.io/tscharts/`.\n\n### Ordinary web servers\n\nTo configure an ordinary web server to serve Helm charts, you merely need to do\nthe following:\n\n- Put your index and charts in a directory that the server can serve\n- Make sure the `index.yaml` file can be accessed with no authentication requirement\n- Make sure `yaml` files are served with the correct content type (`text/yaml` or\n  `text/x-yaml`)\n\nFor example, if you want to serve your charts out of `$WEBROOT/charts`, make sure\nthere is a `charts/` directory in your web root, and put the index file and\ncharts inside of that folder.\n\n\n## Managing Chart Repositories\n\nNow that you have a chart repository, the last part of this guide explains how\nto maintain charts in that repository.\n\n\n### Store charts in your chart repository\n\nNow that you have a chart repository, let's upload a chart and an index file to\nthe repository.  Charts in a chart repository must be packaged\n(`helm package chart-name/`) and versioned correctly (following\n[SemVer 2](https://semver.org/) guidelines).\n\nThese next steps compose an example workflow, but you are welcome to use\nwhatever workflow you fancy for storing and updating charts in your chart\nrepository.\n\nOnce you have a packaged chart ready, create a new directory, and move your\npackaged chart to that directory.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nThe last command takes the path of the local directory that you just created and\nthe URL of your remote chart repository and composes an `index.yaml` file inside the\ngiven directory path.\n\nNow you can upload the chart and the index file to your chart repository using\na sync tool or manually. If you're using Google Cloud Storage, check out this\n[example workflow](chart_repository_sync_example.md) using the gsutil client. For\nGitHub, you can simply put the charts in the appropriate destination branch.\n\n### Add new charts to an existing repository\n\nEach time you want to add a new chart to your repository, you must regenerate\nthe index. The `helm repo index` command will completely rebuild the `index.yaml`\nfile from scratch, including only the charts that it finds locally.\n\nHowever, you can use the `--merge` flag to incrementally add new charts to an\nexisting `index.yaml` file (a great option when working with a remote repository\nlike GCS). Run `helm repo index --help` to learn more,\n\nMake sure that you upload both the revised `index.yaml` file and the chart. And\nif you generated a provenance file, upload that too.\n\n### Share your charts with others\n\nWhen you're ready to share your charts, simply let someone know what the URL of\nyour repository is.\n\nFrom there, they will add the repository to their helm client via the `helm\nrepo add [NAME] [URL]` command with any name they would like to use to\nreference the repository.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nIf the charts are backed by HTTP basic authentication, you can also supply the\nusername and password here:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Note:** A repository will not be added if it does not contain a valid\n`index.yaml`.\n\nAfter that, your users will be able to search through your charts. After you've updated\nthe repository, they can use the `helm repo update` command to get the latest\nchart information.\n\n*Under the hood, the `helm repo add` and `helm repo update` commands are\nfetching the index.yaml file and storing them in the\n`$HELM_HOME/repository/cache/` directory. This is where the `helm search`\nfunction finds information about charts.*\n"
  },
  {
    "path": "versioned_docs/version-2/developing_charts/chart_repository_faq.md",
    "content": "---\nsidebar_position: 7\nsidebar_label: \"Chart Repository FAQ\"\n---\n# Chart Repositories: Frequently Asked Questions\n\nThis section tracks some of the more frequently encountered issues with using chart repositories.\n\n**We'd love your help** making this document better. To add, correct, or remove\ninformation, [file an issue](https://github.com/helm/helm/issues) or\nsend us a pull request.\n\n## Fetching\n\n**Q: Why do I get a `unsupported protocol scheme \"\"` error when trying to fetch a chart from my custom repo?**\n\nA: (Helm < 2.5.0) This is likely caused by you creating your chart repo index without specifying the `--url` flag.\nTry recreating your `index.yaml` file with a command like `helm repo index --url http://my-repo/charts .`,\nand then re-uploading it to your custom charts repo.\n\nThis behavior was changed in Helm 2.5.0.\n"
  },
  {
    "path": "versioned_docs/version-2/developing_charts/chart_repository_sync_example.md",
    "content": "---\nsidebar_position: 4\nsidebar_label: \"Syncing Your Chart Repo\"\n---\n# Syncing Your Chart Repository\n*Note: This example is specifically for a Google Cloud Storage (GCS) bucket which serves a chart repository.*\n\n## Prerequisites\n* Install the [gsutil](https://cloud.google.com/storage/docs/gsutil) tool. *We rely heavily on the gsutil rsync functionality*\n* Be sure to have access to the Helm binary\n* _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._\n\n## Set up a local chart repository directory\nCreate a local directory like we did in [the chart repository guide](chart_repository.md), and place your packaged charts in that directory.\n\nFor example:\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Generate an updated index.yaml\nUse 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:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\nThis will generate an updated index.yaml file and place in the `fantastic-charts/` directory.\n\n## Sync your local and remote chart repositories\nUpload 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.\n\nFor example:\n```console\n$ pwd\n/Users/funuser/go/src/github.com/helm/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## Updating your chart repository\nYou'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.\n\nFor example:\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\n\nHelpful Links:\n* Documentation on [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [The Chart Repository Guide](chart_repository.md)\n* Documentation on [object versioning and concurrency control](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) in Google Cloud Storage\n"
  },
  {
    "path": "versioned_docs/version-2/developing_charts/chart_tests.md",
    "content": "---\nsidebar_position: 6\nsidebar_label: \"Chart Tests\"\n---\n# Chart Tests\n\nA 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.\n\nA **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`.\n\nExample tests:\n- Validate that your configuration from the values.yaml file was properly injected.\n  - Make sure your username and password work correctly\n  - Make sure an incorrect username and password does not work\n- Assert that your services are up and correctly loadbalanced.\n- etc.\n\nYou can run the pre-defined tests in Helm on a release using the command `helm test <RELEASE_NAME>`. For a chart consumer, this is a great way to sanity check that their release of a chart (or application) works as expected.\n\n## A Breakdown of the Helm Test Hooks\n\nIn Helm, there are two test hooks: `test-success` and `test-failure`\n\n`test-success` indicates that test pod should complete successfully. In other words, the containers in the pod should exit 0.\n`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.\n\n## Example Test\n\nHere 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:\n\n```\nwordpress/\n  Chart.yaml\n  README.md\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-mariadb-connection.yaml\n```\nIn `wordpress/templates/tests/test-mariadb-connection.yaml`:\n```\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ .Release.Name }}-credentials-test\"\n  annotations:\n    \"helm.sh/hook\": test-success\nspec:\n  containers:\n  - name: {{ .Release.Name }}-credentials-test\n    image: {{ .Values.image }}\n    env:\n      - name: MARIADB_HOST\n        value: {{ template \"mariadb.fullname\" . }}\n      - name: MARIADB_PORT\n        value: \"3306\"\n      - name: WORDPRESS_DATABASE_NAME\n        value: {{ default \"\" .Values.mariadb.mariadbDatabase | quote }}\n      - name: WORDPRESS_DATABASE_USER\n        value: {{ default \"\" .Values.mariadb.mariadbUser | quote }}\n      - name: WORDPRESS_DATABASE_PASSWORD\n        valueFrom:\n          secretKeyRef:\n            name: {{ template \"mariadb.fullname\" . }}\n            key: mariadb-password\n    command: [\"sh\", \"-c\", \"mysql --host=$MARIADB_HOST --port=$MARIADB_PORT --user=$WORDPRESS_DATABASE_USER --password=$WORDPRESS_DATABASE_PASSWORD\"]\n  restartPolicy: Never\n```\n\n## Steps to Run a Test Suite on a Release\n1. `$ helm install stable/wordpress`\n```\nNAME:   quirky-walrus\nLAST DEPLOYED: Mon Feb 13 13:50:43 2017\nNAMESPACE: default\nSTATUS: DEPLOYED\n```\n\n2. `$ helm test quirky-walrus`\n```\nRUNNING: quirky-walrus-credentials-test\nSUCCESS: quirky-walrus-credentials-test\n```\n\n## Notes\n- 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\n- You are welcome to nest your test suite under a `tests/` directory like `<chart-name>/templates/tests/` for more isolation\n"
  },
  {
    "path": "versioned_docs/version-2/developing_charts/charts_hooks.md",
    "content": "---\nsidebar_position: 1\nsidebar_label: \"Chart Lifecycle Hooks\"\n---\n# Hooks\n\nHelm provides a _hook_ mechanism to allow chart developers to intervene\nat certain points in a release's life cycle. For example, you can use\nhooks to:\n\n- Load a ConfigMap or Secret during install before any other charts are\n  loaded.\n- Execute a Job to back up a database before installing a new chart,\n  and then execute a second job after the upgrade in order to restore\n  data.\n- Run a Job before deleting a release to gracefully take a service out\n  of rotation before removing it.\n\nHooks work like regular templates, but they have special annotations\nthat cause Helm to utilize them differently. In this section, we cover\nthe basic usage pattern for hooks.\n\nHooks are declared as an annotation in the metadata section of a manifest:\n\n```yaml\napiVersion: ...\nkind: ....\nmetadata:\n  annotations:\n    \"helm.sh/hook\": \"pre-install\"\n# ...\n```\n\n## The Available Hooks\n\nThe following hooks are defined:\n\n- pre-install: Executes after templates are rendered, but before any\n  resources are created in Kubernetes.\n- post-install: Executes after all resources are loaded into Kubernetes\n- pre-delete: Executes on a deletion request before any resources are\n  deleted from Kubernetes.\n- post-delete: Executes on a deletion request after all of the release's\n  resources have been deleted.\n- pre-upgrade: Executes on an upgrade request after templates are\n  rendered, but before any resources are loaded into Kubernetes (e.g.\n  before a Kubernetes apply operation).\n- post-upgrade: Executes on an upgrade after all resources have been\n  upgraded.\n- pre-rollback: Executes on a rollback request after templates are\n  rendered, but before any resources have been rolled back.\n- post-rollback: Executes on a rollback request after all resources\n  have been modified.\n- crd-install: Adds CRD resources before any other checks are run. This is used\n  only on CRD definitions that are used by other manifests in the chart.\n- test-success: Executes when running `helm test` and expects the pod to\n  return successfully (return code == 0).\n- test-failure: Executes when running `helm test` and expects the pod to\n  fail (return code != 0).\n\n## Hooks and the Release Lifecycle\n\nHooks allow you, the chart developer, an opportunity to perform\noperations at strategic points in a release lifecycle. For example,\nconsider the lifecycle for a `helm install`. By default, the lifecycle\nlooks like this:\n\n1. User runs `helm install foo`\n2. Chart is loaded into Tiller\n3. After some verification, Tiller renders the `foo` templates\n4. Tiller loads the resulting resources into Kubernetes\n5. Tiller returns the release name (and other data) to the client\n6. The client exits\n\nHelm defines two hooks for the `install` lifecycle: `pre-install` and\n`post-install`. If the developer of the `foo` chart implements both\nhooks, the lifecycle is altered like this:\n\n1. User runs `helm install foo`\n2. Chart is loaded into Tiller\n3. After some verification, Tiller renders the `foo` templates\n4. Tiller prepares to execute the `pre-install` hooks (loading hook resources into\n   Kubernetes)\n5. 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.\n6. Tiller then loads the hook with the lowest weight first (negative to positive)\n7. Tiller waits until the hook is \"Ready\" (except for CRDs)\n8. Tiller loads the resulting resources into Kubernetes. Note that if the `--wait`\nflag is set, Tiller will wait until all resources are in a ready state\nand will not run the `post-install` hook until they are ready.\n9. Tiller executes the `post-install` hook (loading hook resources)\n10. Tiller waits until the hook is \"Ready\"\n11. Tiller returns the release name (and other data) to the client\n12. The client exits\n\nWhat does it mean to wait until a hook is ready? This depends on the\nresource declared in the hook. If the resources is a `Job` kind, Tiller\nwill wait until the job successfully runs to completion. And if the job\nfails, the release will fail. This is a _blocking operation_, so the\nHelm client will pause while the Job is run.\n\nFor all other kinds, as soon as Kubernetes marks the resource as loaded\n(added or updated), the resource is considered \"Ready\". When many\nresources are declared in a hook, the resources are executed serially. If they\nhave hook weights (see below), they are executed in weighted order. Otherwise,\nordering is not guaranteed. (In Helm 2.3.0 and after, they are sorted\nalphabetically. That behavior, though, is not considered binding and could change\nin the future.) It is considered good practice to add a hook weight, and set it\nto `0` if weight is not important.\n\n\n### Hook resources are not managed with corresponding releases\n\nThe resources that a hook creates are not tracked or managed as part of the\nrelease. Once Tiller verifies that the hook has reached its ready state, it\nwill leave the hook resource alone.\n\nPractically speaking, this means that if you create resources in a hook, you\ncannot rely upon `helm delete` to remove the resources. To destroy such\nresources, you need to either write code to perform this operation in a `pre-delete`\nor `post-delete` hook or add `\"helm.sh/hook-delete-policy\"` annotation to the hook template file.\n\n## Writing a Hook\n\nHooks are just Kubernetes manifest files with special annotations in the\n`metadata` section. Because they are template files, you can use all of\nthe normal template features, including reading `.Values`, `.Release`,\nand `.Template`.\n\nFor example, this template, stored in `templates/post-install-job.yaml`,\ndeclares a job to be run on `post-install`:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{.Release.Name}}\"\n  labels:\n    app.kubernetes.io/managed-by: {{.Release.Service | quote }}\n    app.kubernetes.io/instance: {{.Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{.Chart.Name}}-{{.Chart.Version}}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{.Release.Name}}\"\n      labels:\n        app.kubernetes.io/managed-by: {{.Release.Service | quote }}\n        app.kubernetes.io/instance: {{.Release.Name | quote }}\n        helm.sh/chart: \"{{.Chart.Name}}-{{.Chart.Version}}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{default \"10\" .Values.sleepyTime}}\"]\n\n```\n\nWhat makes this template a hook is the annotation:\n\n```\n  annotations:\n    \"helm.sh/hook\": post-install\n```\n\nOne resource can implement multiple hooks:\n\n```\n  annotations:\n    \"helm.sh/hook\": post-install,post-upgrade\n```\n\nSimilarly, there is no limit to the number of different resources that\nmay implement a given hook. For example, one could declare both a secret\nand a config map as a pre-install hook.\n\nWhen subcharts declare hooks, those are also evaluated. There is no way\nfor a top-level chart to disable the hooks declared by subcharts.\n\nIt is possible to define a weight for a hook which will help build a\ndeterministic executing order. Weights are defined using the following annotation:\n\n```\n  annotations:\n    \"helm.sh/hook-weight\": \"5\"\n```\n\nHook weights can be positive or negative numbers but must be represented as\nstrings. 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.\n\nIt is also possible to define policies that determine when to delete corresponding hook resources. Hook deletion policies are defined using the following annotation:\n\n```\n  annotations:\n    \"helm.sh/hook-delete-policy\": hook-succeeded\n```\n\nYou can choose one or more defined annotation values:\n\n* `\"hook-succeeded\"` specifies Tiller should delete the hook after the hook is successfully executed.\n* `\"hook-failed\"` specifies Tiller should delete the hook if the hook failed during execution.\n* `\"before-hook-creation\"` specifies Tiller should delete the previous hook before the new hook is launched.\n\nBy default Tiller will wait for 60 seconds for a deleted hook to no longer exist in the API server before timing out. This\nbehavior can be changed using the `helm.sh/hook-delete-timeout` annotation. The value is the number of seconds Tiller\nshould wait for the hook to be fully deleted. A value of 0 means Tiller does not wait at all.\n\n### Defining a CRD with the `crd-install` Hook\n\nCustom Resource Definitions (CRDs) are a special kind in Kubernetes. They provide\na way to define other kinds.\n\nOn occasion, a chart needs to both define a kind and then use it. This is done\nwith the `crd-install` hook.\n\nThe `crd-install` hook is executed very early during an installation, before\nthe rest of the manifests are verified. CRDs can be annotated with this hook so\nthat they are installed before any instances of that CRD are referenced. In this\nway, when verification happens later, the CRDs will be available.\n\nHere is an example of defining a CRD with a hook, and an instance of the CRD:\n\n```yaml\napiVersion: apiextensions.k8s.io/v1beta1\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\n  annotations:\n    \"helm.sh/hook\": crd-install\nspec:\n  group: stable.example.com\n  version: v1\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n    shortNames:\n    - ct\n```\n\nAnd:\n\n```yaml\napiVersion: stable.example.com/v1\nkind: CronTab\nmetadata:\n  name: {{ .Release.Name }}-inst\n```\n\nBoth of these can now be in the same chart, provided that the CRD is correctly\nannotated.\n\n### Automatically delete hook from previous release\n\nWhen 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.\n\nA 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.\n\nIf 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\"`.\n\n\n"
  },
  {
    "path": "versioned_docs/version-2/developing_charts/charts_tips_and_tricks.md",
    "content": "---\nsidebar_position: 2\nsidebar_label: \"Charts Tips and Tricks\"\n---\n# Chart Development Tips and Tricks\n\nThis guide covers some of the tips and tricks Helm chart developers have\nlearned while building production-quality charts.\n\n## Know Your Template Functions\n\nHelm uses [Go templates](https://godoc.org/text/template) for templating\nyour resource files. While Go ships several built-in functions, we have\nadded many others.\n\nFirst, we added almost all of the functions in the\n[Sprig library](https://godoc.org/github.com/Masterminds/sprig). We removed two\nfor security reasons: `env` and `expandenv` (which would have given chart authors\naccess to Tiller's environment).\n\nWe also added two special template functions: `include` and `required`. The `include`\nfunction allows you to bring in another template, and then pass the results to other\ntemplate functions.\n\nFor example, this template snippet includes a template called `mytpl`, then\nlowercases the result, then wraps that in double quotes.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nThe `required` function allows you to declare a particular\nvalues entry as required for template rendering. If the value is empty, the template\nrendering will fail with a user submitted error message.\n\nThe following example of the `required` function declares an entry for .Values.who\nis required, and will print an error message when that entry is missing:\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\nWhen using the `include` function, you can pass it a custom object tree built from the current context by using the `dict` function:\n\n```yaml\n{{- include \"mytpl\" (dict \"key1\" .Values.originalKey1 \"key2\" .Values.originalKey2) }}\n```\n\n## Quote Strings, Don't Quote Integers\n\nWhen you are working with string data, you are always safer quoting the\nstrings than leaving them as bare words:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nBut when working with integers _do not quote the values._ That can, in\nmany cases, cause parsing errors inside of Kubernetes.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nThis remark does not apply to env variables values which are expected to be string, even if they represent integers:\n\n```yaml\nenv:\n  -name: HOST\n    value: \"http://host\"\n  -name: PORT\n    value: \"1234\"\n```\n\n## Using the 'include' Function\n\nGo provides a way of including one template in another using a built-in\n`template` directive. However, the built-in function cannot be used in\nGo template pipelines.\n\nTo make it possible to include a template, and then perform an operation\non that template's output, Helm has a special `include` function:\n\n```gotpl\n{{- include \"toYaml\" $value | nindent 2 }}\n```\n\nThe above includes a template called `toYaml`, passes it `$value`, and\nthen passes the output of that template to the `nindent` function. Using\nthe `{{- ... | nindent _n_ }}` pattern makes it easier to read the `include`\nin context, because it chomps the whitespace to the left (including the\nprevious newline), then the `nindent` re-adds the newline and indents\nthe included content by the requested amount.\n\nBecause YAML ascribes significance to indentation levels and whitespace,\nthis is one great way to include snippets of code, but handle\nindentation in a relevant context.\n\n## Using the 'required' function\n\nGo provides a way for setting template options to control behavior\nwhen a map is indexed with a key that's not present in the map. This\nis typically set with template.Options(\"missingkey=option\"), where option\ncan be default, zero, or error. While setting this option to error will\nstop execution with an error, this would apply to every missing key in the\nmap. There may be situations where a chart developer wants to enforce this\nbehavior for select values in the values.yml file.\n\nThe `required` function gives developers the ability to declare a value entry\nas required for template rendering. If the entry is empty in values.yml, the\ntemplate will not render and will return an error message supplied by the\ndeveloper.\n\nFor example:\n\n```gotpl\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nThe above will render the template when .Values.foo is defined, but will fail\nto render and exit when .Values.foo is undefined.\n\n## Using the 'tpl' Function\n\nThe `tpl` function allows developers to evaluate strings as templates inside a template.\nThis is useful to pass a template string as a value to a chart or render external configuration files.\nSyntax: `{{ tpl TEMPLATE_STRING VALUES }}`\n\nExamples:\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\nRendering a external configuration file:\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## Creating Image Pull Secrets\n\nImage 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:\n\nFirst, assume that the credentials are defined in the `values.yaml` file like so:\n\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n```\n\nWe then define our helper template as follows:\n\n```gotpl\n{{- define \"imagePullSecret\" }}\n{{- printf \"{\\\"auths\\\": {\\\"%s\\\": {\\\"auth\\\": \\\"%s\\\"}}}\" .Values.imageCredentials.registry (printf \"%s:%s\" .Values.imageCredentials.username .Values.imageCredentials.password | b64enc) | b64enc }}\n{{- end }}\n```\n\nFinally, we use the helper template in a larger template to create the Secret manifest:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Automatically Roll Deployments When ConfigMaps or Secrets change\n\nOften times configmaps or secrets are injected as configuration\nfiles in containers.\nDepending on the application a restart may be required should those\nbe updated with a subsequent `helm upgrade`, but if the\ndeployment spec itself didn't change the application keeps running\nwith the old configuration resulting in an inconsistent deployment.\n\nThe `sha256sum` function can be used to ensure a deployment's\nannotation section is updated if another file changes:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nSee also the `helm upgrade --recreate-pods` flag for a slightly\ndifferent way of addressing this issue.\n\n## Tell Tiller Not To Delete a Resource\n\nSometimes there are resources that should not be deleted when Helm runs a\n`helm delete`. Chart developers can add an annotation to a resource to prevent\nit from being deleted.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    \"helm.sh/resource-policy\": keep\n[...]\n```\n\n(Quotation marks are required)\n\nThe annotation `\"helm.sh/resource-policy\": keep` instructs Tiller to skip this\nresource during a `helm delete` operation. _However_, this resource becomes\norphaned. Helm will no longer manage it in any way. This can lead to problems\nif using `helm install --replace` on a release that has already been deleted, but\nhas kept resources.\n\nTo explicitly opt in to resource deletion, for example when overriding a chart's\ndefault annotations, set the resource policy annotation value to `delete`.\n\n## Using \"Partials\" and Template Includes\n\nSometimes you want to create some reusable parts in your chart, whether\nthey're blocks or template partials. And often, it's cleaner to keep\nthese in their own files.\n\nIn the `templates/` directory, any file that begins with an\nunderscore(`_`) is not expected to output a Kubernetes manifest file. So\nby convention, helper templates and partials are placed in a\n`_helpers.tpl` file.\n\n## Complex Charts with Many Dependencies\n\nMany of the charts in the [official charts repository](https://github.com/helm/charts)\nare \"building blocks\" for creating more advanced applications. But charts may be\nused to create instances of large-scale applications. In such cases, a single\numbrella chart may have multiple subcharts, each of which functions as a piece\nof the whole.\n\nThe current best practice for composing a complex application from discrete parts\nis to create a top-level umbrella chart that\nexposes the global configurations, and then use the `charts/` subdirectory to\nembed each of the components.\n\nTwo strong design patterns are illustrated by these projects:\n\n**SAP's [Converged charts](https://github.com/sapcc/helm-charts):** These charts\ninstall SAP Converged Cloud a full OpenStack IaaS on Kubernetes. All of the charts are collected\ntogether in one GitHub repository, except for a few submodules.\n\n**Deis's [Workflow](https://github.com/deis/workflow/tree/master/charts/workflow):**\nThis chart exposes the entire Deis PaaS system with one chart. But it's different\nfrom the SAP chart in that this umbrella chart is built from each component, and\neach component is tracked in a different Git repository. Check out the\n`requirements.yaml` file to see how this chart is composed by their CI/CD\npipeline.\n\nBoth of these charts illustrate proven techniques for standing up complex environments\nusing Helm.\n\n## YAML is a Superset of JSON\n\nAccording to the YAML specification, YAML is a superset of JSON. That\nmeans that any valid JSON structure ought to be valid in YAML.\n\nThis has an advantage: Sometimes template developers may find it easier\nto express a data structure with a JSON-like syntax rather than deal with\nYAML's whitespace sensitivity.\n\nAs a best practice, templates should follow a YAML-like syntax _unless_\nthe JSON syntax substantially reduces the risk of a formatting issue.\n\n## Be Careful with Generating Random Values\n\nThere are functions in Helm that allow you to generate random data,\ncryptographic keys, and so on. These are fine to use. But be aware that\nduring upgrades, templates are re-executed. When a template run\ngenerates data that differs from the last run, that will trigger an\nupdate of that resource.\n\n## Upgrade a release idempotently\n\nIn order to use the same command when installing and upgrading a release, use the following command:\n\n```shell\nhelm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "versioned_docs/version-2/developing_charts/developing_charts.md",
    "content": "---\nsidebar_position: 5\nsidebar_label: \"Charts\"\n# This is the index/landing page for this section\n---\n# Charts\n\nHelm uses a packaging format called _charts_. A chart is a collection of files\nthat describe a related set of Kubernetes resources. A single chart\nmight be used to deploy something simple, like a memcached pod, or\nsomething complex, like a full web app stack with HTTP servers,\ndatabases, caches, and so on.\n\nCharts are created as files laid out in a particular directory tree,\nthen they can be packaged into versioned archives to be deployed.\n\nThis document explains the chart format, and provides basic guidance for\nbuilding charts with Helm.\n\n## The Chart File Structure\n\nA chart is organized as a collection of files inside of a directory. The\ndirectory name is the name of the chart (without versioning information). Thus,\na chart describing WordPress would be stored in the `wordpress/` directory.\n\nInside of this directory, Helm will expect a structure that matches this:\n\n```\nwordpress/\n  Chart.yaml          # A YAML file containing information about the chart\n  LICENSE             # OPTIONAL: A plain text file containing the license for the chart\n  README.md           # OPTIONAL: A human-readable README file\n  requirements.yaml   # OPTIONAL: A YAML file listing dependencies for the chart\n  values.yaml         # The default configuration values for this chart\n  charts/             # A directory containing any charts upon which this chart depends.\n  templates/          # A directory of templates that, when combined with values,\n                      # will generate valid Kubernetes manifest files.\n  templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes\n```\n\nHelm reserves use of the `charts/` and `templates/` directories, and of\nthe listed file names. Other files will be left as they are.\n\n## The Chart.yaml File\n\nThe `Chart.yaml` file is required for a chart. It contains the following fields:\n\n```yaml\napiVersion: The chart API version, always \"v1\" (required)\nname: The name of the chart (required)\nversion: A SemVer 2 version (required)\nkubeVersion: A SemVer range of compatible Kubernetes versions (optional)\ndescription: A single-sentence description of this project (optional)\nkeywords:\n  - A list of keywords about this project (optional)\nhome: The URL of this project's home page (optional)\nsources:\n  - A list of URLs to source code for this project (optional)\nmaintainers: # (optional)\n  - name: The maintainer's name (required for each maintainer)\n    email: The maintainer's email (optional for each maintainer)\n    url: A URL for the maintainer (optional for each maintainer)\nengine: gotpl # The name of the template engine (optional, defaults to gotpl)\nicon: A URL to an SVG or PNG image to be used as an icon (optional).\nappVersion: The version of the app that this contains (optional). This needn't be SemVer.\ndeprecated: Whether this chart is deprecated (optional, boolean)\ntillerVersion: The version of Tiller that this chart requires. This should be expressed as a SemVer range: \">2.0.0\" (optional)\n```\n\nIf you are familiar with the `Chart.yaml` file format for Helm Classic, you will\nnotice that fields specifying dependencies have been removed. That is because\nthe new Chart format expresses dependencies using the `charts/` directory.\n\nOther fields will be silently ignored.\n\n### Charts and Versioning\n\nEvery chart must have a version number. A version must follow the\n[SemVer 2](https://semver.org/) standard. Unlike Helm Classic, Kubernetes\nHelm uses version numbers as release markers. Packages in repositories\nare identified by name plus version.\n\nFor example, an `nginx` chart whose version field is set to `version:\n1.2.3` will be named:\n\n```\nnginx-1.2.3.tgz\n```\n\nMore complex SemVer 2 names are also supported, such as\n`version: 1.2.3-alpha.1+ef365`. But non-SemVer names are explicitly\ndisallowed by the system.\n\n**NOTE:** Whereas Helm Classic and Deployment Manager were both\nvery GitHub oriented when it came to charts, Kubernetes Helm does not\nrely upon or require GitHub or even Git. Consequently, it does not use\nGit SHAs for versioning at all.\n\nThe `version` field inside of the `Chart.yaml` is used by many of the\nHelm tools, including the CLI and the Tiller server. When generating a\npackage, the `helm package` command will use the version that it finds\nin the `Chart.yaml` as a token in the package name. The system assumes\nthat the version number in the chart package name matches the version number in\nthe `Chart.yaml`. Failure to meet this assumption will cause an error.\n\n### The appVersion field\n\nNote that the `appVersion` field is not related to the `version` field. It is\na way of specifying the version of the application. For example, the `drupal`\nchart may have an `appVersion: 8.2.1`, indicating that the version of Drupal\nincluded in the chart (by default) is `8.2.1`. This field is informational, and\nhas no impact on chart version calculations.\n\n### Deprecating Charts\n\nWhen managing charts in a Chart Repository, it is sometimes necessary to\ndeprecate a chart. The optional `deprecated` field in `Chart.yaml` can be used\nto mark a chart as deprecated. If the **latest** version of a chart in the\nrepository is marked as deprecated, then the chart as a whole is considered to\nbe deprecated. The chart name can later be reused by publishing a newer version\nthat is not marked as deprecated. The workflow for deprecating charts, as\nfollowed by the [helm/charts](https://github.com/helm/charts)\nproject is:\n\n- Update chart's `Chart.yaml` to mark the chart as deprecated, bumping the version\n- Release the new chart version in the Chart Repository\n- Remove the chart from the source repository (e.g. git)\n\n## Chart LICENSE, README and NOTES\n\nCharts can also contain files that describe the installation, configuration, usage and license of a\nchart.\n\nA LICENSE is a plain text file containing the [license](https://en.wikipedia.org/wiki/Software_license)\nfor the chart. The chart can contain a license as it may have programming logic in the templates and\nwould therefore not be configuration only. There can also be separate license(s) for the application\ninstalled by the chart, if required.\n\nA README for a chart should be formatted in Markdown (README.md), and should generally\ncontain:\n\n- A description of the application or service the chart provides\n- Any prerequisites or requirements to run the chart\n- Descriptions of options in `values.yaml` and default values\n- Any other information that may be relevant to the installation or configuration of the chart\n\nThe chart can also contain a short plain text `templates/NOTES.txt` file that will be printed out\nafter installation, and when viewing the status of a release. This file is evaluated as a\n[template](#templates-and-values), and can be used to display usage notes, next steps, or any other\ninformation relevant to a release of the chart. For example, instructions could be provided for\nconnecting to a database, or accessing a web UI. Since this file is printed to STDOUT when running\n`helm install` or `helm status`, it is recommended to keep the content brief and point to the README\nfor greater detail.\n\n## Chart Dependencies\n\nIn Helm, one chart may depend on any number of other charts.\nThese dependencies can be dynamically linked through the `requirements.yaml`\nfile or brought in to the `charts/` directory and managed manually.\n\nAlthough manually managing your dependencies has a few advantages some teams need,\nthe preferred method of declaring dependencies is by using a\n`requirements.yaml` file inside of your chart.\n\n**Note:** The `dependencies:` section of the `Chart.yaml` from Helm\nClassic has been completely removed.\n\n### Managing Dependencies with `requirements.yaml`\n\nA `requirements.yaml` file is a simple file for listing your\ndependencies.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: http://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: http://another.example.com/charts\n```\n\n- The `name` field is the name of the chart you want.\n- The `version` field is the version of the chart you want.\n- The `repository` field is the full URL to the chart repository. Note\n  that you must also use `helm repo add` to add that repo locally.\n\nOnce you have a dependencies file, you can run `helm dependency update`\nand it will use your dependency file to download all the specified\ncharts into your `charts/` directory for you.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete.\nSaving 2 charts\nDownloading apache from repo http://example.com/charts\nDownloading mysql from repo http://another.example.com/charts\n```\n\nWhen `helm dependency update` retrieves charts, it will store them as\nchart archives in the `charts/` directory. So for the example above, one\nwould expect to see the following files in the charts directory:\n\n```\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\nManaging charts with `requirements.yaml` is a good way to easily keep\ncharts updated, and also share requirements information throughout a\nteam.\n\n#### Alias field in requirements.yaml\n\nIn addition to the other fields above, each requirements entry may contain\nthe optional field `alias`.\n\nAdding an alias for a dependency chart would put\na chart in dependencies using alias as name of new dependency.\n\nOne can use `alias` in cases where they need to access a chart\nwith other name(s).\n\n```yaml\n# parentchart/requirements.yaml\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nIn the above example we will get 3 dependencies in all for `parentchart`\n\n```\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nThe manual way of achieving this is by copy/pasting the same chart in the\n`charts/` directory multiple times with different names.\n\n#### Tags and Condition fields in requirements.yaml\n\nIn addition to the other fields above, each requirements entry may contain\nthe optional fields `tags` and `condition`.\n\nAll charts are loaded by default. If `tags` or `condition` fields are present,\nthey will be evaluated and used to control loading for the chart(s) they are applied to.\n\nCondition - The condition field holds one or more YAML paths (delimited by commas).\nIf this path exists in the parent's values and resolves to a boolean value,\nthe chart will be enabled or disabled based on that boolean value. Only the first\nvalid path found in the list is evaluated and if no paths exist then the condition \nhas no effect. For multiple level dependencies the condition is prependend by the \npath to the parent chart.\n\nTags - The tags field is a YAML list of labels to associate with this chart.\nIn the top parent's values, all charts with tags can be enabled or disabled by\nspecifying the tag and a boolean value.\n\n```yaml\n# parentchart/requirements.yaml\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# subchart2/requirements.yaml\ndependencies:\n  - name: subsubchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subsubchart.enabled\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\nsubchart2:\n  subsubchart:\n    enabled: false\ntags:\n  front-end: false\n  back-end: true\n```\n\nIn the above example all charts with the tag `front-end` would be disabled but since the\n`subchart1.enabled` path evaluates to 'true' in the parent's values, the condition will override the\n`front-end` tag and `subchart1` will be enabled.\n\nSince `subchart2` is tagged with `back-end` and that tag evaluates to `true`, `subchart2` will be\nenabled. Also note that although `subchart2` has a condition specified in `requirements.yaml`, there\nis no corresponding path and value in the parent's values so that condition has no effect.\n\n`subsubchart` is disabled by default but can be enabled by setting `subchart2.subsubchart.enabled=true`.\nHint: disabling `subchart2` via tag will also disable all sub-charts (even if overriding the value `subchart2.subsubchart.enabled=true`).\n\n##### Using the CLI with Tags and Conditions\n\nThe `--set` parameter can be used as usual to alter tag and condition values.\n\n````\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n````\n\n##### Tags and Condition Resolution\n\n- **Conditions (when set in values) always override tags.**\n- The first condition path that exists wins and subsequent ones for that chart are ignored.\n- Tags are evaluated as 'if any of the chart's tags are true then enable the chart'.\n- Tags and conditions values must be set in the top parent's values.\n- The `tags:` key in values must be a top level key. Globals and nested `tags:` tables\n    are not currently supported.\n\n#### Importing Child Values via requirements.yaml\n\nIn some cases it is desirable to allow a child chart's values to propagate to the parent chart and be\nshared as common defaults. An additional benefit of using the `exports` format is that it will enable future\ntooling to introspect user-settable values.\n\nThe keys containing the values to be imported can be specified in the parent chart's `requirements.yaml` file\nusing a YAML list. Each item in the list is a key which is imported from the child chart's `exports` field.\n\nTo import values not contained in the `exports` key, use the [child-parent](#using-the-child-parent-format) format.\nExamples of both formats are described below.\n\n##### Using the exports format\n\nIf a child chart's `values.yaml` file contains an `exports` field at the root, its contents may be imported\ndirectly into the parent's values by specifying the keys to import as in the example below:\n\n```yaml\n# parent's requirements.yaml file\n    ...\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n...\nexports:\n  data:\n    myint: 99\n```\n\nSince we are specifying the key `data` in our import list, Helm looks in the `exports` field of the child\nchart for `data` key and imports its contents.\n\nThe final parent values would contain our exported field:\n\n```yaml\n# parent's values file\n...\nmyint: 99\n\n```\n\nPlease note the parent key `data` is not contained in the parent's final values. If you need to specify the\nparent key, use the 'child-parent' format.\n\n##### Using the child-parent format\n\nTo access values that are not contained in the `exports` key of the child chart's values, you will need to\nspecify the source key of the values to be imported (`child`) and the destination path in the parent chart's\nvalues (`parent`).\n\nThe `import-values` in the example below instructs Helm to take any values found at `child:` path and copy them\nto the parent's values at the path specified in `parent:`\n\n```yaml\n# parent's requirements.yaml file\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nIn the above example, values found at `default.data` in the subchart1's values will be imported\nto the `myimports` key in the parent chart's values as detailed below:\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n\n```\n\nThe parent chart's resulting values would be:\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n\n```\n\nThe parent's final values now contains the `myint` and `mybool` fields imported from subchart1.\n\n### Managing Dependencies manually via the `charts/` directory\n\nIf more control over dependencies is desired, these dependencies can\nbe expressed explicitly by copying the dependency charts into the\n`charts/` directory.\n\nA dependency can be either a chart archive (`foo-1.2.3.tgz`) or an\nunpacked chart directory. But its name cannot start with `_` or `.`.\nSuch files are ignored by the chart loader.\n\nFor example, if the WordPress chart depends on the Apache chart, the\nApache chart (of the correct version) is supplied in the WordPress\nchart's `charts/` directory:\n\n```\nwordpress:\n  Chart.yaml\n  requirements.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nThe example above shows how the WordPress chart expresses its dependency\non Apache and MySQL by including those charts inside of its `charts/`\ndirectory.\n\n**TIP:** _To drop a dependency into your `charts/` directory, use the\n`helm fetch` command_\n\n### Operational aspects of using dependencies\n\nThe above sections explain how to specify chart dependencies, but how does this affect\nchart installation using `helm install` and `helm upgrade`?\n\nSuppose that a chart named \"A\" creates the following Kubernetes objects\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nFurthermore, A is dependent on chart B that creates objects\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nAfter installation/upgrade of chart A, a single Helm release is created/modified. The release will\ncreate/update all of the above Kubernetes objects in the following order:\n\n- A-Namespace\n- B-Namespace\n- A-StatefulSet\n- B-ReplicaSet\n- A-Service\n- B-Service\n\nThis is because when Helm installs/upgrades charts,\nthe Kubernetes objects from the charts and all its dependencies are\n\n- aggregated into a single set; then\n- sorted by type followed by name; and then\n- created/updated in that order.\n\nHence a single release is created with all the objects for the chart and its dependencies.\n\nThe install order of Kubernetes types is given by the enumeration InstallOrder in kind_sorter.go\n(see [the Helm source file](https://github.com/helm/helm/blob/master/pkg/tiller/kind_sorter.go#L26)).\n\n## Templates and Values\n\nHelm Chart templates are written in the\n[Go template language](https://golang.org/pkg/text/template/), with the\naddition of 50 or so add-on template\nfunctions [from the Sprig library](https://github.com/Masterminds/sprig) and a\nfew other [specialized functions](charts_tips_and_tricks.md).\n\nAll template files are stored in a chart's `templates/` folder. When\nHelm renders the charts, it will pass every file in that directory\nthrough the template engine.\n\nValues for the templates are supplied two ways:\n\n- Chart developers may supply a file called `values.yaml` inside of a\n  chart. This file can contain default values.\n- Chart users may supply a YAML file that contains values. This can be\n  provided on the command line with `helm install`.\n\nWhen a user supplies custom values, these values will override the\nvalues in the chart's `values.yaml` file.\n\n### Template Files\n\nTemplate files follow the standard conventions for writing Go templates\n(see [the text/template Go package documentation](https://golang.org/pkg/text/template/)\nfor details).\nAn example template file might look something like this:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{.Values.imageRegistry}}/postgres:{{.Values.dockerTag}}\n          imagePullPolicy: {{.Values.pullPolicy}}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{default \"minio\" .Values.storage}}\n```\n\nThe above example, based loosely on [https://github.com/deis/charts](https://github.com/deis/charts), is a template for a Kubernetes replication controller.\nIt can use the following four template values (usually defined in a\n`values.yaml` file):\n\n- `imageRegistry`: The source registry for the Docker image.\n- `dockerTag`: The tag for the docker image.\n- `pullPolicy`: The Kubernetes pull policy.\n- `storage`: The storage backend, whose default is set to `\"minio\"`\n\nAll of these values are defined by the template author. Helm does not\nrequire or dictate parameters.\n\nTo see many working charts, check out the [Helm Charts\nproject](https://github.com/helm/charts)\n\n### Predefined Values\n\nValues that are supplied via a `values.yaml` file (or via the `--set`\nflag) are accessible from the `.Values` object in a template. But there\nare other pre-defined pieces of data you can access in your templates.\n\nThe following values are pre-defined, are available to every template, and\ncannot be overridden. As with all values, the names are _case\nsensitive_.\n\n- `Release.Name`: The name of the release (not the chart)\n- `Release.Time`: The time the chart release was last updated. This will\n  match the `Last Released` time on a Release object.\n- `Release.Namespace`: The namespace the chart was released to.\n- `Release.Service`: The service that conducted the release. Usually\n  this is `Tiller`.\n- `Release.IsUpgrade`: This is set to true if the current operation is an upgrade or rollback.\n- `Release.IsInstall`: This is set to true if the current operation is an\n  install.\n- `Release.Revision`: The revision number. It begins at 1, and increments with\n  each `helm upgrade`.\n- `Chart`: The contents of the `Chart.yaml`. Thus, the chart version is\n  obtainable as `Chart.Version` and the maintainers are in\n  `Chart.Maintainers`.\n- `Files`: A map-like object containing all non-special files in the chart. This\n  will not give you access to templates, but will give you access to additional\n  files that are present (unless they are excluded using `.helmignore`). Files can be\n  accessed using `{{index .Files \"file.name\"}}` or using the `{{.Files.Get name}}` or\n  `{{.Files.GetString name}}` functions. You can also access the contents of the file\n  as `[]byte` using `{{.Files.GetBytes}}`\n- `Capabilities`: A map-like object that contains information about the versions\n  of Kubernetes (`{{.Capabilities.KubeVersion}}`, Tiller\n  (`{{.Capabilities.TillerVersion}}`, and the supported Kubernetes API versions\n  (`{{.Capabilities.APIVersions.Has \"batch/v1\"`)\n\n**NOTE:** Any unknown Chart.yaml fields will be dropped. They will not\nbe accessible inside of the `Chart` object. Thus, Chart.yaml cannot be\nused to pass arbitrarily structured data into the template. The values\nfile can be used for that, though.\n\n### Values files\n\nConsidering the template in the previous section, a `values.yaml` file\nthat supplies the necessary values would look like this:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nA values file is formatted in YAML. A chart may include a default\n`values.yaml` file. The Helm install command allows a user to override\nvalues by supplying additional YAML values:\n\n```console\n$ helm install --values=myvals.yaml wordpress\n```\n\nWhen values are passed in this way, they will be merged into the default\nvalues file. For example, consider a `myvals.yaml` file that looks like\nthis:\n\n```yaml\nstorage: \"gcs\"\n```\n\nWhen this is merged with the `values.yaml` in the chart, the resulting\ngenerated content will be:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nNote that only the last field was overridden.\n\n**NOTE:** The default values file included inside of a chart _must_ be named\n`values.yaml`. But files specified on the command line can be named\nanything.\n\n**NOTE:** If the `--set` flag is used on `helm install` or `helm upgrade`, those\nvalues are simply converted to YAML on the client side.\n\n**NOTE:** If any required entries in the values file exist, they can be declared\nas required in the chart template by using the ['required' function](charts_tips_and_tricks.md)\n\nAny of these values are then accessible inside of templates using the\n`.Values` object:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{.Values.imageRegistry}}/postgres:{{.Values.dockerTag}}\n          imagePullPolicy: {{.Values.pullPolicy}}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{default \"minio\" .Values.storage}}\n\n```\n\n### Scope, Dependencies, and Values\n\nValues files can declare values for the top-level chart, as well as for\nany of the charts that are included in that chart's `charts/` directory.\nOr, to phrase it differently, a values file can supply values to the\nchart as well as to any of its dependencies. For example, the\ndemonstration WordPress chart above has both `mysql` and `apache` as\ndependencies. The values file could supply values to all of these\ncomponents:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nCharts at a higher level have access to all of the variables defined\nbeneath. So the WordPress chart can access the MySQL password as\n`.Values.mysql.password`. But lower level charts cannot access things in\nparent charts, so MySQL will not be able to access the `title` property. Nor,\nfor that matter, can it access `apache.port`.\n\nValues are namespaced, but namespaces are pruned. So for the WordPress\nchart, it can access the MySQL password field as `.Values.mysql.password`. But\nfor the MySQL chart, the scope of the values has been reduced and the\nnamespace prefix removed, so it will see the password field simply as\n`.Values.password`.\n\n#### Global Values\n\nAs of 2.0.0-Alpha.2, Helm supports special \"global\" value. Consider\nthis modified version of the previous example:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nThe above adds a `global` section with the value `app: MyWordPress`.\nThis value is available to _all_ charts as `.Values.global.app`.\n\nFor example, the `mysql` templates may access `app` as `{{.Values.global.app}}`, and\nso can the `apache` chart. Effectively, the values file above is\nregenerated like this:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\nThis provides a way of sharing one top-level variable with all\nsubcharts, which is useful for things like setting `metadata` properties\nlike labels.\n\nIf a subchart declares a global variable, that global will be passed\n_downward_ (to the subchart's subcharts), but not _upward_ to the parent\nchart. There is no way for a subchart to influence the values of the\nparent chart.\n\nAlso, global variables of parent charts take precedence over the global variables from subcharts.\n\n### References\n\nWhen it comes to writing templates and values files, there are several\nstandard references that will help you out.\n\n- [Go templates](https://godoc.org/text/template)\n- [Extra template functions](https://godoc.org/github.com/Masterminds/sprig)\n- [The YAML format](https://yaml.org/spec/)\n\n## Using Helm to Manage Charts\n\nThe `helm` tool has several commands for working with charts.\n\nIt can create a new chart for you:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nOnce you have edited a chart, `helm` can package it into a chart archive\nfor you:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nYou can also use `helm` to help you find issues with your chart's\nformatting or information:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Chart Repositories\n\nA _chart repository_ is an HTTP server that houses one or more packaged\ncharts. While `helm` can be used to manage local chart directories, when\nit comes to sharing charts, the preferred mechanism is a chart\nrepository.\n\nAny HTTP server that can serve YAML files and tar files and can answer\nGET requests can be used as a repository server.\n\nHelm comes with built-in package server for developer testing (`helm\nserve`). The Helm team has tested other servers, including Google Cloud\nStorage with website mode enabled, and S3 with website mode enabled.\n\nA repository is characterized primarily by the presence of a special\nfile called `index.yaml` that has a list of all of the packages supplied\nby the repository, together with metadata that allows retrieving and\nverifying those packages.\n\nOn the client side, repositories are managed with the `helm repo`\ncommands. However, Helm does not provide tools for uploading charts to\nremote repository servers. This is because doing so would add\nsubstantial requirements to an implementing server, and thus raise the\nbarrier for setting up a repository.\n\n## Chart Starter Packs\n\nThe `helm create` command takes an optional `--starter` option that lets you\nspecify a \"starter chart\".\n\nStarters are just regular charts, but are located in `$HELM_HOME/starters`.\nAs a chart developer, you may author charts that are specifically designed\nto be used as starters. Such charts should be designed with the following\nconsiderations in mind:\n\n- The `Chart.yaml` will be overwritten by the generator.\n- Users will expect to modify such a chart's contents, so documentation\n  should indicate how users can do so.\n- All occurrences of `<CHARTNAME>` in files within the `templates` directory\n  will be replaced with the specified chart name so that starter charts can be\n  used as templates. Additionally, occurrences of `<CHARTNAME>` in\n  `values.yaml` will also be replaced.\n\nCurrently the only way to add a chart to `$HELM_HOME/starters` is to manually\ncopy it there. In your chart's documentation, you may want to explain that\nprocess.\n"
  },
  {
    "path": "versioned_docs/version-2/developing_charts/provenance.md",
    "content": "---\nsidebar_position: 5\nsidebar_label: \"Signing Charts\"\n---\n# Helm Provenance and Integrity\n\nHelm has provenance tools which help chart users verify the integrity and origin\nof a package. Using industry-standard tools based on PKI, GnuPG, and well-respected\npackage managers, Helm can generate and verify signature files.\n\n## Overview\n\nIntegrity is established by comparing a chart to a provenance record. Provenance\nrecords are stored in _provenance files_, which are stored alongside a packaged\nchart. For example, if a chart is named `myapp-1.2.3.tgz`, its provenance file\nwill be `myapp-1.2.3.tgz.prov`.\n\nProvenance files are generated at packaging time (`helm package --sign ...`), and\ncan be checked by multiple commands, notable `helm install --verify`.\n\n## The Workflow\n\nThis section describes a potential workflow for using provenance data effectively.\n\nPrerequisites:\n\n- A valid PGP keypair in a binary (not ASCII-armored) format\n- The `helm` command line tool\n- GnuPG >=2.1 command line tools (optional)\n- Keybase command line tools (optional)\n\n**NOTE:** If your PGP private key has a passphrase, you will be prompted to enter\nthat passphrase for any commands that support the `--sign` option. You can set the\nHELM_KEY_PASSPHRASE environment variable to that passphrase in case you don't want\nto be prompted to enter the passphrase.\n\n**NOTE:** The keyfile format for GnuPG changed in version 2.1. Prior to that release\nit was unnecessary to export keys out of GnuPG, and you could instead point Helm\nat your `*.gpg` files. With 2.1, the new `.kbx` format was introduced, and this\nformat is not supported by Helm.\n\nCreating a new chart is the same as before:\n\n```\n$ helm create mychart\nCreating mychart\n```\n\nOnce ready to package, add the `--sign` flag to `helm package`. Also, specify\nthe name under which the signing key is known and the keyring containing the corresponding private key:\n\n```\n$ helm package --sign --key 'helm signing key' --keyring path/to/keyring.secret mychart\n```\n\n**TIP:** for GnuPG users, your secret keyring is in `~/.gnupg/secring.kbx`. You can\nuse `gpg --list-secret-keys` to list the keys you have.\n\n**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:\n\n```\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nAt this point, you should see both `mychart-0.1.0.tgz` and `mychart-0.1.0.tgz.prov`.\nBoth files should eventually be uploaded to your desired chart repository.\n\nYou can verify a chart using `helm verify`:\n\n```\n$ helm verify mychart-0.1.0.tgz\n```\n\nA failed verification looks like this:\n\n```\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nTo verify during an install, use the `--verify` flag.\n\n```\n$ helm install --verify mychart-0.1.0.tgz\n```\n\nIf the keyring (containing the public key associated with the signed chart) is not in the default location, you may need to point to the\nkeyring with `--keyring PATH` as in the `helm package` example.\n\nIf verification fails, the install will be aborted before the chart is even pushed\nup to Tiller.\n\n### Using Keybase.io credentials\n\nThe [Keybase.io](https://keybase.io) service makes it easy to establish a chain of\ntrust for a cryptographic identity. Keybase credentials can be used to sign charts.\n\nPrerequisites:\n\n- A configured Keybase.io account\n- GnuPG installed locally\n- The `keybase` CLI installed locally\n\n#### Signing packages\n\nThe first step is to import your keybase keys into your local GnuPG keyring:\n\n```\n$ keybase pgp export -s > secring.gpg\n```\n\nThis will convert your Keybase key into the OpenPGP format, and then place it\nlocally into your `secring.gpg` file.\n\n> Tip: If you need to add a Keybase key to an existing keyring, you will need to\n> do `keybase pgp export -s | gpg --import && gpg --export-secret-keys --outfile secring.gpg`\n\nYour secret key will have an identifier string:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nThat is the full name of your key.\n\nNext, you can package and sign a chart with `helm package`. Make sure you use at\nleast part of that name string in `--key`.\n\n```\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nAs a result, the `package` command should produce both a `.tgz` file and a `.tgz.prov`\nfile.\n\n#### Verifying packages\n\nYou can also use a similar technique to verify a chart signed by someone else's\nKeybase key. Say you want to verify a package signed by `keybase.io/technosophos`.\nTo do this, use the `keybase` tool:\n\n```\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nThe first command above tracks the user `technosophos`. Next `keybase pgp pull`\ndownloads the OpenPGP keys of all of the accounts you follow, placing them in\nyour GnuPG keyring (`~/.gnupg/pubring.gpg`).\n\nAt this point, you can now use `helm verify` or any of the commands with a `--verify`\nflag:\n\n```\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Reasons a chart may not verify\n\nThese are common reasons for failure.\n\n- The prov file is missing or corrupt. This indicates that something is misconfigured\n  or that the original maintainer did not create a provenance file.\n- The key used to sign the file is not in your keyring. This indicate that the\n  entity who signed the chart is not someone you've already signaled that you trust.\n- The verification of the prov file failed. This indicates that something is wrong\n  with either the chart or the provenance data.\n- The file hashes in the provenance file do not match the hash of the archive file. This\n  indicates that the archive has been tampered with.\n\nIf a verification fails, there is reason to distrust the package.\n\n## The Provenance File\nThe provenance file contains a chart’s YAML file plus several pieces of\nverification information. Provenance files are designed to be automatically\ngenerated.\n\n\nThe following pieces of provenance data are added:\n\n\n* The chart file (Chart.yaml) is included to give both humans and tools an easy\n  view into the contents of the chart.\n* The signature (SHA256, just like Docker) of the chart package (the .tgz file)\n  is included, and may be used to verify the integrity of the chart package.\n* The entire body is signed using the algorithm used by PGP (see\n  [https://keybase.io] for an emerging way of making crypto signing and\n  verification easy).\n\nThe combination of this gives users the following assurances:\n\n* The package itself has not been tampered with (checksum package tgz).\n* The entity who released this package is known (via the GnuPG/PGP signature).\n\nThe format of the file looks something like this:\n\n```\n-----BEGIN PGP SIGNED MESSAGE-----\nname: nginx\ndescription: The nginx web server as a replication controller and service pair.\nversion: 0.5.1\nkeywords:\n  - https\n  - http\n  - web server\n  - proxy\nsource:\n- https://github.com/foo/bar\nhome: https://nginx.com\n\n...\nfiles:\n        nginx-0.5.1.tgz: “sha256:9f5270f50fc842cfcb717f817e95178f”\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.9 (GNU/Linux)\n\niEYEARECAAYFAkjilUEACgQkB01zfu119ZnHuQCdGCcg2YxF3XFscJLS4lzHlvte\nWkQAmQGHuuoLEJuKhRNo+Wy7mhE7u1YG\n=eifq\n-----END PGP SIGNATURE-----\n```\n\nNote that the YAML section contains two documents (separated by `...\\n`). The\nfirst is the Chart.yaml. The second is the checksums, a map of filenames to\nSHA-256 digests (value shown is fake/truncated)\n\nThe signature block is a standard PGP signature, which provides [tamper\nresistance](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Chart Repositories\n\nChart repositories serve as a centralized collection of Helm charts.\n\nChart repositories must make it possible to serve provenance files over HTTP via\na specific request, and must make them available at the same URI path as the chart.\n\nFor example, if the base URL for a package is `https://example.com/charts/mychart-1.2.3.tgz`,\nthe provenance file, if it exists, MUST be accessible at `https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nFrom the end user's perspective, `helm install --verify myrepo/mychart-1.2.3`\nshould result in the download of both the chart and the provenance file with no\nadditional user configuration or action.\n\n## Establishing Authority and Authenticity\n\nWhen dealing with chain-of-trust systems, it is important to be able to\nestablish the authority of a signer. Or, to put this plainly, the system\nabove hinges on the fact that you trust the person who signed the chart.\nThat, in turn, means you need to trust the public key of the signer.\n\nOne of the design decisions with Kubernetes Helm has been that the Helm\nproject would not insert itself into the chain of trust as a necessary\nparty. We don't want to be \"the certificate authority\" for all chart\nsigners. Instead, we strongly favor a decentralized model, which is part\nof the reason we chose OpenPGP as our foundational technology.\nSo when it comes to establishing authority, we have left this\nstep more-or-less undefined in Helm 2.0.0.\n\nHowever, we have some pointers and recommendations for those interested\nin using the provenance system:\n\n- The [Keybase](https://keybase.io) platform provides a public\n  centralized repository for trust information.\n  - You can use Keybase to store your keys or to get the public keys of others.\n  - Keybase also has fabulous documentation available\n  - While we haven't tested it, Keybase's \"secure website\" feature could\n    be used to serve Helm charts.\n- The [official Helm Charts project](https://github.com/helm/charts)\n  is trying to solve this problem for the official chart repository.\n  - There is a long issue there [detailing the current thoughts](https://github.com/helm/charts/issues/23).\n  - The basic idea is that an official \"chart reviewer\" signs charts with\n    her or his key, and the resulting provenance file is then uploaded\n    to the chart repository.\n  - There has been some work on the idea that a list of valid signing\n    keys may be included in the `index.yaml` file of a repository.\n\nFinally, chain-of-trust is an evolving feature of Helm, and some\ncommunity members have proposed adapting part of the OSI model for\nsignatures. This is an open line of inquiry in the Helm team. If you're\ninterested, jump on in.\n"
  },
  {
    "path": "versioned_docs/version-2/glossary.md",
    "content": "---\nsidebar_position: 12\nsidebar_label: \"Glossary\"\n---\n# Helm Glossary\n\nHelm uses a few special terms to describe components of the\narchitecture.\n\n## Chart\n\nA Helm package that contains information sufficient for installing a set\nof Kubernetes resources into a Kubernetes cluster.\n\nCharts contain a `Chart.yaml` file as well as templates, default values\n(`values.yaml`), and dependencies.\n\nCharts are developed in a well-defined directory structure, and then\npackaged into an archive format called a _chart archive_.\n\n## Chart Archive\n\nA _chart archive_ is a tarred and gzipped (and optionally signed) chart.\n\n## Chart Dependency (Subcharts)\n\nCharts may depend upon other charts. There are two ways a dependency may\noccur:\n\n- Soft dependency: A chart may simply not function without another chart\n  being installed in a cluster. Helm does not provide tooling for this\n  case. In this case, dependencies may be managed separately.\n- Hard dependency: A chart may contain (inside of its `charts/`\n  directory) another chart upon which it depends. In this case,\n  installing the chart will install all of its dependencies. In this\n  case, a chart and its dependencies are managed as a collection.\n\nWhen a chart is packaged (via `helm package`) all of its hard dependencies\nare bundled with it.\n\n## Chart Version\n\nCharts are versioned according to the [SemVer 2\nspec](https://semver.org). A version number is required on every chart.\n\n## Chart.yaml\n\nInformation about a chart is stored in a special file called\n`Chart.yaml`. Every chart must have this file.\n\n## Helm (and helm)\n\nHelm is the package manager for Kubernetes. As an operating system\npackage manager makes it easy to install tools on an OS, Helm makes it\neasy to install applications and resources into Kubernetes clusters.\n\nWhile _Helm_ is the name of the project, the command line client is also\nnamed `helm`. By convention, when speaking of the project, _Helm_ is\ncapitalized. When speaking of the client, _helm_ is in lowercase.\n\n## Helm Home (HELM_HOME)\n\nThe Helm client stores information in a local directory referred to as\n_helm home_. By default, this is in the `$HOME/.helm` directory.\n\nThis directory contains configuration and cache data, and is created by\n`helm init`.\n\n## Kube Config (KUBECONFIG)\n\nThe Helm client learns about Kubernetes clusters by using files in the _Kube\nconfig_ file format. By default, Helm attempts to find this file in the\nplace where `kubectl` creates it (`$HOME/.kube/config`).\n\n## Lint (Linting)\n\nTo _lint_ a chart is to validate that it follows the conventions and\nrequirements of the Helm chart standard. Helm provides tools to do this,\nnotably the `helm lint` command.\n\n## Provenance (Provenance file)\n\nHelm charts may be accompanied by a _provenance file_ which provides\ninformation about where the chart came from and what it contains.\n\nProvenance files are one part of the Helm security story. A provenance contains\na cryptographic hash of the chart archive file, the Chart.yaml data, and\na signature block (an OpenPGP \"clearsign\" block). When coupled with a\nkeychain, this provides chart users with the ability to:\n\n- Validate that a chart was signed by a trusted party\n- Validate that the chart file has not been tampered with\n- Validate the contents of a chart metadata (`Chart.yaml`)\n- Quickly match a chart to its provenance data\n\nProvenance files have the `.prov` extension, and can be served from a\nchart repository server or any other HTTP server.\n\n## Release\n\nWhen a chart is installed, Tiller (the Helm server) creates a _release_\nto track that installation.\n\nA single chart may be installed many times into the same cluster, and\ncreate many different releases. For example, one can install three\nPostgreSQL databases by running `helm install` three times with a\ndifferent release name.\n\n(Prior to 2.0.0-Alpha.1, releases were called _deployments_. But this\ncaused confusion with the Kubernetes _Deployment_ kind.)\n\n## Release Number (Release Version)\n\nA single release can be updated multiple times. A sequential counter is\nused to track releases as they change. After a first `helm install`, a\nrelease will have _release number_ 1. Each time a release is upgraded or\nrolled back, the release number will be incremented.\n\n## Rollback\n\nA release can be upgraded to a newer chart or configuration. But since\nrelease history is stored, a release can also be _rolled back_ to a\nprevious release number. This is done with the `helm rollback` command.\n\nImportantly, a rolled back release will receive a new release number.\n\nOperation | Release Number\n----------|---------------\ninstall   | release 1\nupgrade   | release 2\nupgrade   | release 3\nrollback 1| release 4 (but running the same config as release 1)\n\nThe above table illustrates how release numbers increment across\ninstall, upgrade, and rollback.\n\n## Tiller\n\nTiller is the in-cluster component of Helm. It interacts directly with\nthe Kubernetes API server to install, upgrade, query, and remove\nKubernetes resources. It also stores the objects that represent\nreleases.\n\n## Repository (Repo, Chart Repository)\n\nHelm charts may be stored on dedicated HTTP servers called _chart\nrepositories_ (_repositories_, or just _repos_).\n\nA chart repository server is a simple HTTP server that can serve an\n`index.yaml` file that describes a batch of charts, and provides\ninformation on where each chart can be downloaded from. (Many chart\nrepositories serve the charts as well as the `index.yaml` file.)\n\nA Helm client can point to zero or more chart repositories. By default,\nHelm clients point to the `stable` official Kubernetes chart\nrepository.\n\n## Values (Values Files, values.yaml)\n\nValues provide a way to override template defaults with your own\ninformation.\n\nHelm Charts are \"parameterized\", which means the chart developer may\nexpose configuration that can be overridden at installation time. For\nexample, a chart may expose a `username` field that allows setting a\nuser name for a service.\n\nThese exposed variables are called _values_ in Helm parlance.\n\nValues can be set during `helm install` and `helm upgrade` operations,\neither by passing them in directly, or by uploading a `values.yaml`\nfile.\n\n\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm.md",
    "content": "---\ntitle: \"helm\"\nsidebar_position: 4\nsidebar_label: \"Helm Commands\"\n# This is the index/landing page for this section\n---\nThe Helm package manager for Kubernetes.\n\n### Synopsis\n\nThe Kubernetes package manager\n\nTo begin working with Helm, run the 'helm init' command:\n\n\t$ helm init\n\nThis will install Tiller to your running Kubernetes cluster.\nIt will also set up any necessary local configuration.\n\nCommon actions from this point include:\n\n- helm search:    Search for charts\n- helm fetch:     Download a chart to your local directory to view\n- helm install:   Upload the chart to Kubernetes\n- helm list:      List releases of charts\n\nEnvironment:\n\n- $HELM_HOME:           Set an alternative location for Helm files. By default, these are stored in ~/.helm\n- $HELM_HOST:           Set an alternative Tiller host. The format is host:port\n- $HELM_NO_PLUGINS:     Disable plugins. Set HELM_NO_PLUGINS=1 to disable plugins.\n- $TILLER_NAMESPACE:    Set an alternative Tiller namespace (default \"kube-system\")\n- $KUBECONFIG:          Set an alternative Kubernetes configuration file (default \"~/.kube/config\")\n- $HELM_TLS_CA_CERT:    Path to TLS CA certificate used to verify the Helm client and Tiller server certificates (default \"$HELM_HOME/ca.pem\")\n- $HELM_TLS_CERT:       Path to TLS client certificate file for authenticating to Tiller (default \"$HELM_HOME/cert.pem\")\n- $HELM_TLS_KEY:        Path to TLS client key file for authenticating to Tiller (default \"$HELM_HOME/key.pem\")\n- $HELM_TLS_ENABLE:     Enable TLS connection between Helm and Tiller (default \"false\")\n- $HELM_TLS_VERIFY:     Enable TLS connection between Helm and Tiller and verify Tiller server certificate (default \"false\")\n- $HELM_TLS_HOSTNAME:   The hostname or IP address used to verify the Tiller server certificate (default \"127.0.0.1\")\n- $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\n\n\n\n### Options\n\n```\n      --debug                           Enable verbose output\n  -h, --help                            help for helm\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm completion](helm_completion.md)\t - Generate autocompletions script for the specified shell (bash or zsh)\n* [helm create](helm_create.md)\t - Create a new chart with the given name\n* [helm delete](helm_delete.md)\t - Given a release name, delete the release from Kubernetes\n* [helm dependency](helm_dependency.md)\t - Manage a chart's dependencies\n* [helm fetch](helm_fetch.md)\t - Download a chart from a repository and (optionally) unpack it in local directory\n* [helm get](helm_get.md)\t - Download a named release\n* [helm history](helm_history.md)\t - Fetch release history\n* [helm home](helm_home.md)\t - Displays the location of HELM_HOME\n* [helm init](helm_init.md)\t - Initialize Helm on both client and server\n* [helm inspect](helm_inspect.md)\t - Inspect a chart\n* [helm install](helm_install.md)\t - Install a chart archive\n* [helm lint](helm_lint.md)\t - Examines a chart for possible issues\n* [helm list](helm_list.md)\t - List releases\n* [helm package](helm_package.md)\t - Package a chart directory into a chart archive\n* [helm plugin](helm_plugin.md)\t - Add, list, or remove Helm plugins\n* [helm repo](helm_repo.md)\t - Add, list, remove, update, and index chart repositories\n* [helm reset](helm_reset.md)\t - Uninstalls Tiller from a cluster\n* [helm rollback](helm_rollback.md)\t - Rollback a release to a previous revision\n* [helm search](helm_search.md)\t - Search for a keyword in charts\n* [helm serve](helm_serve.md)\t - Start a local http web server\n* [helm status](helm_status.md)\t - Displays the status of the named release\n* [helm template](helm_template.md)\t - Locally render templates\n* [helm test](helm_test.md)\t - Test a release\n* [helm upgrade](helm_upgrade.md)\t - Upgrade a release\n* [helm verify](helm_verify.md)\t - Verify that a chart at the given path has been signed and is valid\n* [helm version](helm_version.md)\t - Print the client/server version information\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_completion.md",
    "content": "---\ntitle: \"helm completion\"\nsidebar_position: 1\nsidebar_label: \"Helm Completion\"\n---\nGenerate autocompletions script for the specified shell (bash or zsh)\n\n### Synopsis\n\n\nGenerate autocompletions script for Helm for the specified shell (bash or zsh).\n\nThis command can generate shell autocompletions. e.g.\n\n\t$ helm completion bash\n\nCan be sourced as such\n\n\t$ source <(helm completion bash)\n\n\n```\nhelm completion SHELL [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for completion\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_create.md",
    "content": "---\ntitle: \"helm create\"\nsidebar_position: 2\nsidebar_label: \"Helm Create\"\n---\nCreate a new chart with the given name\n\n### Synopsis\n\n\nThis command creates a chart directory along with the common files and\ndirectories used in a chart. It provides a basic example and is not\nmeant to cover all Kubernetes resources.\n\nFor example, 'helm create foo' will create a directory structure that looks\nsomething like this:\n\n\tfoo/\n\t  |\n\t  |- .helmignore        # Contains patterns to ignore when packaging Helm charts.\n\t  |\n\t  |- Chart.yaml         # Information about your chart\n\t  |\n\t  |- values.yaml        # The default values for your templates\n\t  |\n\t  |- charts/            # Charts that this chart depends on\n\t  |\n\t  |- templates/         # The template files\n\t  |\n\t  |- templates/tests/   # The test files\n\n'helm create' takes a path for an argument. If directories in the given path\ndo not exist, Helm will attempt to create them as it goes. If the given\ndestination exists and there are files in that directory, conflicting files\nwill be overwritten, but other files will be left alone.\n\nThe chart that is created by invoking this command contains a Deployment, Ingress\nand a Service. To use other Kubernetes resources with your chart, refer to\n[The Chart Template Developer's Guide](https://helm.sh/docs/chart_template_guide).\n\n\n```\nhelm create NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help             help for create\n  -p, --starter string   The name or absolute path to Helm starter scaffold\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 7-Jul-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_delete.md",
    "content": "---\ntitle: \"helm delete\"\nsidebar_position: 3\nsidebar_label: \"Helm Delete\"\n---\nGiven a release name, delete the release from Kubernetes\n\n### Synopsis\n\n\nThis command takes a release name, and then deletes the release from Kubernetes.\nIt removes all of the resources associated with the last release of the chart.\n\nUse the '--dry-run' flag to see which releases will be deleted without actually\ndeleting them.\n\n\n```\nhelm delete [flags] RELEASE_NAME [...]\n```\n\n### Options\n\n```\n      --description string    Specify a description for the release\n      --dry-run               Simulate a delete\n  -h, --help                  help for delete\n      --no-hooks              Prevent hooks from running during deletion\n      --purge                 Remove the release from the store and make its name free for later use\n      --timeout int           Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300)\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_dependency.md",
    "content": "---\ntitle: \"helm dependency\"\nsidebar_position: 4\nsidebar_label: \"Helm Dependency\"\n---\nManage a chart's dependencies\n\n### Synopsis\n\n\nManage the dependencies of a chart.\n\nHelm charts store their dependencies in 'charts/'. For chart developers, it is\noften easier to manage a single dependency file ('requirements.yaml')\nwhich declares all dependencies.\n\nThe dependency commands operate on that file, making it easy to synchronize\nbetween the desired dependencies and the actual dependencies stored in the\n'charts/' directory.\n\nA 'requirements.yaml' file is a YAML file in which developers can declare chart\ndependencies, along with the location of the chart and the desired version.\nFor example, this requirements file declares two dependencies:\n\n    # requirements.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\nThe 'name' should be the name of a chart, where that name must match the name\nin that chart's 'Chart.yaml' file.\n\nThe 'version' field should contain a semantic version or version range.\n\nThe 'repository' URL should point to a Chart Repository. Helm expects that by\nappending '/index.yaml' to the URL, it should be able to retrieve the chart\nrepository's index. Note: 'repository' can be an alias. The alias must start\nwith 'alias:' or '@'.\n\nStarting from 2.2.0, repository can be defined as the path to the directory of\nthe dependency charts stored locally. The path should start with a prefix of\n\"file://\". For example,\n\n    # requirements.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\nIf the dependency chart is retrieved locally, it is not required to have the\nrepository added to helm by \"helm repo add\". Version matching is also supported\nfor this case.\n\n\n### Options\n\n```\n  -h, --help   help for dependency\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n* [helm dependency build](helm_dependency_build.md)\t - Rebuild the charts/ directory based on the requirements.lock file\n* [helm dependency list](helm_dependency_list.md)\t - List the dependencies for the given chart\n* [helm dependency update](helm_dependency_update.md)\t - Update charts/ based on the contents of requirements.yaml\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_dependency_build.md",
    "content": "---\ntitle: \"helm dependency build\"\nsidebar_position: 5\nsidebar_label: \"Helm Dependency Build\"\n---\nRebuild the charts/ directory based on the requirements.lock file\n\n### Synopsis\n\n\nBuild out the charts/ directory from the requirements.lock file.\n\nBuild is used to reconstruct a chart's dependencies to the state specified in\nthe lock file.\n\nIf no lock file is found, 'helm dependency build' will mirror the behavior of\nthe 'helm dependency update' command. This means it will update the on-disk\ndependencies to mirror the requirements.yaml file and generate a lock file.\n\n\n```\nhelm dependency build [flags] CHART\n```\n\n### Options\n\n```\n  -h, --help             help for build\n      --keyring string   Keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --verify           Verify the packages against signatures\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm dependency](helm_dependency.md)\t - Manage a chart's dependencies\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_dependency_list.md",
    "content": "---\ntitle: \"helm dependency list\"\nsidebar_position: 6\nsidebar_label: \"Helm Dependency List\"\n---\nList the dependencies for the given chart\n\n### Synopsis\n\n\nList all of the dependencies declared in a chart.\n\nThis can take chart archives and chart directories as input. It will not alter\nthe contents of a chart.\n\nThis will produce an error if the chart cannot be loaded. It will emit a warning\nif it cannot find a requirements.yaml.\n\n\n```\nhelm dependency list [flags] CHART\n```\n\n### Options\n\n```\n  -h, --help   help for list\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm dependency](helm_dependency.md)\t - Manage a chart's dependencies\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_dependency_update.md",
    "content": "---\ntitle: \"helm dependency update\"\nsidebar_position: 7\nsidebar_label: \"Helm Dependency Update\"\n---\nUpdate charts/ based on the contents of requirements.yaml\n\n### Synopsis\n\n\nUpdate the on-disk dependencies to mirror the requirements.yaml file.\n\nThis command verifies that the required charts, as expressed in 'requirements.yaml',\nare present in 'charts/' and are at an acceptable version. It will pull down\nthe latest charts that satisfy the dependencies, and clean up old dependencies.\n\nOn successful update, this will generate a lock file that can be used to\nrebuild the requirements to an exact version.\n\nDependencies are not required to be represented in 'requirements.yaml'. For that\nreason, an update command will not remove charts unless they are (a) present\nin the requirements.yaml file, but (b) at the wrong version.\n\n\n```\nhelm dependency update [flags] CHART\n```\n\n### Options\n\n```\n  -h, --help             help for update\n      --keyring string   Keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --skip-refresh     Do not refresh the local repository cache\n      --verify           Verify the packages against signatures\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm dependency](helm_dependency.md)\t - Manage a chart's dependencies\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_fetch.md",
    "content": "---\ntitle: \"helm fetch\"\nsidebar_position: 8\nsidebar_label: \"Helm Fetch\"\n---\nDownload a chart from a repository and (optionally) unpack it in local directory\n\n### Synopsis\n\n\nRetrieve a package from a package repository, and download it locally.\n\nThis is useful for fetching packages to inspect, modify, or repackage. It can\nalso be used to perform cryptographic verification of a chart without installing\nthe chart.\n\nThere are options for unpacking the chart after download. This will create a\ndirectory for the chart and uncompress into that directory.\n\nIf the --verify flag is specified, the requested chart MUST have a provenance\nfile, and MUST pass the verification process. Failure in any part of this will\nresult in an error, and the chart will not be saved locally.\n\n\n```\nhelm fetch [flags] [chart URL | repo/chartname] [...]\n```\n\n### Options\n\n```\n      --ca-file string       Verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string     Identify HTTPS client using this SSL certificate file\n  -d, --destination string   Location to write the chart. If this and tardir are specified, tardir is appended to this (default \".\")\n      --devel                Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help                 help for fetch\n      --key-file string      Identify HTTPS client using this SSL key file\n      --keyring string       Keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string      Chart repository password\n      --prov                 Fetch the provenance file, but don't perform verification\n      --repo string          Chart repository url where to locate the requested chart\n      --untar                If set to true, will untar the chart after downloading it\n      --untardir string      If untar is specified, this flag specifies the name of the directory into which the chart is expanded (default \".\")\n      --username string      Chart repository username\n      --verify               Verify the package against its signature\n      --version string       Specific version of a chart. Without this, the latest version is fetched\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_get.md",
    "content": "---\ntitle: \"helm get\"\nsidebar_position: 9\nsidebar_label: \"Helm Get\"\n---\nDownload a named release\n\n### Synopsis\n\n\nThis command shows the details of a named release.\n\nIt can be used to get extended information about the release, including:\n\n  - The values used to generate the release\n  - The chart used to generate the release\n  - The generated manifest file\n\nBy default, this prints a human readable collection of information about the\nchart, the supplied values, and the generated manifest file.\n\n\n```\nhelm get [flags] RELEASE_NAME\n```\n\n### Options\n\n```\n  -h, --help                  help for get\n      --revision int32        Get the named release with revision\n      --template string       Go template for formatting the output, eg: {{.Release.Name}}\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n* [helm get hooks](helm_get_hooks.md)\t - Download all hooks for a named release\n* [helm get manifest](helm_get_manifest.md)\t - Download the manifest for a named release\n* [helm get notes](helm_get_notes.md)\t - Displays the notes of the named release\n* [helm get values](helm_get_values.md)\t - Download the values file for a named release\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_get_hooks.md",
    "content": "---\ntitle: \"helm get hooks\"\nsidebar_position: 10\nsidebar_label: \"Helm Get Hooks\"\n---\nDownload all hooks for a named release\n\n### Synopsis\n\n\nThis command downloads hooks for a given release.\n\nHooks are formatted in YAML and separated by the YAML '---\\n' separator.\n\n\n```\nhelm get hooks [flags] RELEASE_NAME\n```\n\n### Options\n\n```\n  -h, --help                  help for hooks\n      --revision int32        Get the named release with revision\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm get](helm_get.md)\t - Download a named release\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_get_manifest.md",
    "content": "---\ntitle: \"helm get manifest\"\nsidebar_position: 11\nsidebar_label: \"Helm Get Manifest\"\n---\nDownload the manifest for a named release\n\n### Synopsis\n\n\nThis command fetches the generated manifest for a given release.\n\nA manifest is a YAML-encoded representation of the Kubernetes resources that\nwere generated from this release's chart(s). If a chart is dependent on other\ncharts, those resources will also be included in the manifest.\n\n\n```\nhelm get manifest [flags] RELEASE_NAME\n```\n\n### Options\n\n```\n  -h, --help                  help for manifest\n      --revision int32        Get the named release with revision\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm get](helm_get.md)\t - Download a named release\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_get_notes.md",
    "content": "---\ntitle: \"helm get notes\"\nsidebar_position: 12\nsidebar_label: \"Helm Get Notes\"\n---\nDisplays the notes of the named release\n\n### Synopsis\n\n\nThis command shows notes provided by the chart of a named release.\n\n\n```\nhelm get notes [flags] RELEASE_NAME\n```\n\n### Options\n\n```\n  -h, --help                  help for notes\n      --revision int32        Get the notes of the named release with revision\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm get](helm_get.md)\t - Download a named release\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_get_values.md",
    "content": "---\ntitle: \"helm get values\"\nsidebar_position: 13\nsidebar_label: \"Helm Get Values\"\n---\nDownload the values file for a named release\n\n### Synopsis\n\n\nThis command downloads a values file for a given release.\n\n\n```\nhelm get values [flags] RELEASE_NAME\n```\n\n### Options\n\n```\n  -a, --all                   Dump all (computed) values\n  -h, --help                  help for values\n      --output string         Output the specified format (json or yaml) (default \"yaml\")\n      --revision int32        Get the named release with revision\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm get](helm_get.md)\t - Download a named release\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_history.md",
    "content": "---\ntitle: \"helm history\"\nsidebar_position: 14\nsidebar_label: \"Helm History\"\n---\nFetch release history\n\n### Synopsis\n\n\nHistory prints historical revisions for a given release.\n\nA default maximum of 256 revisions will be returned. Setting '--max'\nconfigures the maximum length of the revision list returned.\n\nThe historical release set is printed as a formatted table, e.g:\n\n    $ helm history angry-bird --max=4\n    REVISION   UPDATED                      STATUS           CHART        APP VERSION\tDESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  1.1\t\tInitial install\n    2           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  1.2\t\tUpgraded successfully\n    3           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  1.1\t\tRolled back to 2\n    4           Mon Oct 3 10:15:13 2016     DEPLOYED        alpine-0.1.0  1.3\t\tUpgraded successfully\n\n\n```\nhelm history [flags] RELEASE_NAME\n```\n\n### Options\n\n```\n      --col-width uint        Specifies the max column width of output (default 60)\n  -h, --help                  help for history\n      --max int32             Maximum number of revisions to include in history (default 256)\n  -o, --output string         Prints the output in the specified format (json|table|yaml) (default \"table\")\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_home.md",
    "content": "---\ntitle: \"helm home\"\nsidebar_position: 15\nsidebar_label: \"Helm Home\"\n---\nDisplays the location of HELM_HOME\n\n### Synopsis\n\n\nThis command displays the location of HELM_HOME. This is where\nany helm configuration files live.\n\n\n```\nhelm home [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for home\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_init.md",
    "content": "---\ntitle: \"helm init\"\nsidebar_position: 16\nsidebar_label: \"Helm Init\"\n---\nInitialize Helm on both client and server\n\n### Synopsis\n\n\nThis command installs Tiller (the Helm server-side component) onto your\nKubernetes Cluster and sets up local configuration in $HELM_HOME (default ~/.helm/).\n\nAs with the rest of the Helm commands, 'helm init' discovers Kubernetes clusters\nby reading $KUBECONFIG (default '~/.kube/config') and using the default context.\n\nTo set up just a local environment, use '--client-only'. That will configure\n$HELM_HOME, but not attempt to connect to a Kubernetes cluster and install the Tiller\ndeployment.\n\nWhen installing Tiller, 'helm init' will attempt to install the latest released\nversion. You can specify an alternative image with '--tiller-image'. For those\nfrequently working on the latest code, the flag '--canary-image' will install\nthe latest pre-release version of Tiller (e.g. the HEAD commit in the GitHub\nrepository on the master branch).\n\nTo dump a manifest containing the Tiller deployment YAML, combine the\n'--dry-run' and '--debug' flags.\n\n\n```\nhelm init [flags]\n```\n\n### Options\n\n```\n      --automount-service-account-token    Auto-mount the given service account to tiller (default true)\n      --canary-image                       Use the canary Tiller image\n  -c, --client-only                        If set does not install Tiller\n      --dry-run                            Do not install local or remote\n      --force-upgrade                      Force upgrade of Tiller to the current helm version\n  -h, --help                               help for init\n      --history-max int                    Limit the maximum number of revisions saved per release. Use 0 for no limit.\n      --local-repo-url string              URL for local repository (default \"http://127.0.0.1:8879/charts\")\n      --net-host                           Install Tiller with net=host\n      --node-selectors string              Labels to specify the node on which Tiller is installed (app=tiller,helm=rocks)\n  -o, --output OutputFormat                Skip installation and output Tiller's manifest in specified format (json or yaml)\n      --override stringArray               Override values for the Tiller Deployment manifest (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --replicas int                       Amount of tiller instances to run on the cluster (default 1)\n      --service-account string             Name of service account\n      --skip-refresh                       Do not refresh (download) the local repository cache\n      --skip-repos                         Skip adding the stable and local repositories\n      --stable-repo-url string             URL for stable repository (default \"https://charts.helm.sh/stable\")\n  -i, --tiller-image string                Override Tiller image\n      --tiller-tls                         Install Tiller with TLS enabled\n      --tiller-tls-cert string             Path to TLS certificate file to install with Tiller\n      --tiller-tls-hostname string         The server name used to verify the hostname on the returned certificates from Tiller\n      --tiller-tls-key string              Path to TLS key file to install with Tiller\n      --tiller-tls-verify                  Install Tiller with TLS enabled and to verify remote certificates\n      --tls-ca-cert string                 Path to CA root certificate\n      --upgrade                            Upgrade if Tiller is already installed\n      --use-deprecated-stable-repository   Use the old (googleapis) repository URL even though that URL is being shutdown.\n      --wait                               Block until Tiller is running and ready to receive requests\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 15-Oct-2020\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_inspect.md",
    "content": "---\ntitle: \"helm inspect\"\nsidebar_position: 17\nsidebar_label: \"Helm Inspect\"\n---\nInspect a chart\n\n### Synopsis\n\n\nThis command inspects a chart and displays information. It takes a chart reference\n('stable/drupal'), a full path to a directory or packaged chart, or a URL.\n\nInspect prints the contents of the Chart.yaml file and the values.yaml file.\n\n\n```\nhelm inspect [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string     Chart repository url where to locate the requested chart\n      --cert-file string   Verify certificates of HTTPS-enabled servers using this CA bundle\n      --devel              Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help               help for inspect\n      --key-file string    Identify HTTPS client using this SSL key file\n      --keyring string     Path to the keyring containing public verification keys (default \"~/.gnupg/pubring.gpg\")\n      --password string    Chart repository password where to locate the requested chart\n      --repo string        Chart repository url where to locate the requested chart\n      --username string    Chart repository username where to locate the requested chart\n      --verify             Verify the provenance data for this chart\n      --version string     Version of the chart. By default, the newest chart is shown\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n* [helm inspect chart](helm_inspect_chart.md)\t - shows inspect chart\n* [helm inspect readme](helm_inspect_readme.md)\t - shows inspect readme\n* [helm inspect values](helm_inspect_values.md)\t - shows inspect values\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_inspect_chart.md",
    "content": "---\ntitle: \"helm inspect chart\"\nsidebar_position: 18\nsidebar_label: \"Helm Inspect Chart\"\n---\nshows inspect chart\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the Charts.yaml file\n\n\n```\nhelm inspect chart [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string     Chart repository url where to locate the requested chart\n      --cert-file string   Verify certificates of HTTPS-enabled servers using this CA bundle\n      --devel              Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help               help for chart\n      --key-file string    Identify HTTPS client using this SSL key file\n      --keyring string     Path to the keyring containing public verification keys (default \"~/.gnupg/pubring.gpg\")\n      --password string    Chart repository password where to locate the requested chart\n      --repo string        Chart repository url where to locate the requested chart\n      --username string    Chart repository username where to locate the requested chart\n      --verify             Verify the provenance data for this chart\n      --version string     Version of the chart. By default, the newest chart is shown\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm inspect](helm_inspect.md)\t - Inspect a chart\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_inspect_readme.md",
    "content": "---\ntitle: \"helm inspect readme\"\nsidebar_position: 19\nsidebar_label: \"Helm Inspect Readme\"\n---\nshows inspect readme\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the README file\n\n\n```\nhelm inspect readme [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string     Chart repository url where to locate the requested chart\n      --cert-file string   Verify certificates of HTTPS-enabled servers using this CA bundle\n      --devel              Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help               help for readme\n      --key-file string    Identify HTTPS client using this SSL key file\n      --keyring string     Path to the keyring containing public verification keys (default \"~/.gnupg/pubring.gpg\")\n      --repo string        Chart repository url where to locate the requested chart\n      --verify             Verify the provenance data for this chart\n      --version string     Version of the chart. By default, the newest chart is shown\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm inspect](helm_inspect.md)\t - Inspect a chart\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_inspect_values.md",
    "content": "---\ntitle: \"helm inspect values\"\nsidebar_position: 20\nsidebar_label: \"Helm Inspect Values\"\n---\nshows inspect values\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the values.yaml file\n\n\n```\nhelm inspect values [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string     Chart repository url where to locate the requested chart\n      --cert-file string   Verify certificates of HTTPS-enabled servers using this CA bundle\n      --devel              Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help               help for values\n      --key-file string    Identify HTTPS client using this SSL key file\n      --keyring string     Path to the keyring containing public verification keys (default \"~/.gnupg/pubring.gpg\")\n      --password string    Chart repository password where to locate the requested chart\n      --repo string        Chart repository url where to locate the requested chart\n      --username string    Chart repository username where to locate the requested chart\n      --verify             Verify the provenance data for this chart\n      --version string     Version of the chart. By default, the newest chart is shown\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm inspect](helm_inspect.md)\t - Inspect a chart\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_install.md",
    "content": "---\ntitle: \"helm install\"\nsidebar_position: 21\nsidebar_label: \"Helm Install\"\n---\nInstall a chart archive\n\n### Synopsis\n\n\nThis command installs a chart archive.\n\nThe install argument must be a chart reference, a path to a packaged chart,\na path to an unpacked chart directory or a URL.\n\nTo override values in a chart, use either the '--values' flag and pass in a file\nor use the '--set' flag and pass configuration from the command line.  To force string\nvalues in '--set', use '--set-string' instead. In case a value is large and therefore\nyou want not to use neither '--values' nor '--set', use '--set-file' to read the\nsingle large value from file.\n\n\t$ helm install -f myvalues.yaml ./redis\n\nor\n\n\t$ helm install --set name=prod ./redis\n\nor\n\n\t$ helm install --set-string long_int=1234567890 ./redis\n\nor\n    $ helm install --set-file multiline_text=path/to/textfile\n\nYou can specify the '--values'/'-f' flag multiple times. The priority will be given to the\nlast (right-most) file specified. For example, if both myvalues.yaml and override.yaml\ncontained a key called 'Test', the value set in override.yaml would take precedence:\n\n\t$ helm install -f myvalues.yaml -f override.yaml ./redis\n\nYou can specify the '--set' flag multiple times. The priority will be given to the\nlast (right-most) set specified. For example, if both 'bar' and 'newbar' values are\nset for a key called 'foo', the 'newbar' value would take precedence:\n\n\t$ helm install --set foo=bar --set foo=newbar ./redis\n\n\nTo check the generated manifests of a release without installing the chart,\nthe '--debug' and '--dry-run' flags can be combined. This will still require a\nround-trip to the Tiller server.\n\nIf --verify is set, the chart MUST have a provenance file, and the provenance\nfile MUST pass all verification steps.\n\nThere are five different ways you can express the chart you want to install:\n\n1. By chart reference: helm install stable/mariadb\n2. By path to a packaged chart: helm install ./nginx-1.2.3.tgz\n3. By path to an unpacked chart directory: helm install ./nginx\n4. By absolute URL: helm install https://example.com/charts/nginx-1.2.3.tgz\n5. By chart reference and repo url: helm install --repo https://example.com/charts/ nginx\n\nCHART REFERENCES\n\nA chart reference is a convenient way of reference a chart in a chart repository.\n\nWhen you use a chart reference with a repo prefix ('stable/mariadb'), Helm will look in the local\nconfiguration for a chart repository named 'stable', and will then look for a\nchart in that repository whose name is 'mariadb'. It will install the latest\nversion of that chart unless you also supply a version number with the\n'--version' flag.\n\nTo see the list of chart repositories, use 'helm repo list'. To search for\ncharts in a repository, use 'helm search'.\n\n\n```\nhelm install [CHART] [flags]\n```\n\n### Options\n\n```\n      --atomic                   If set, installation process purges chart on fail, also sets --wait flag\n      --ca-file string           Verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string         Identify HTTPS client using this SSL certificate file\n      --dep-up                   Run helm dependency update before installing the chart\n      --description string       Specify a description for the release\n      --devel                    Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n      --dry-run                  Simulate an install\n  -h, --help                     help for install\n      --key-file string          Identify HTTPS client using this SSL key file\n      --keyring string           Location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -n, --name string              The release name. If unspecified, it will autogenerate one for you\n      --name-template string     Specify template used to name the release\n      --namespace string         Namespace to install the release into. Defaults to the current kube config namespace.\n      --no-crd-hook              Prevent CRD hooks from running, but run other hooks\n      --no-hooks                 Prevent hooks from running during install\n  -o, --output string            Prints the output in the specified format. Allowed values: table, json, yaml (default \"table\")\n      --password string          Chart repository password where to locate the requested chart\n      --render-subchart-notes    Render subchart notes along with the parent\n      --replace                  Re-use the given name, even if that name is already used. This is unsafe in production\n      --repo string              Chart repository url where to locate the requested chart\n      --set stringArray          Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-string stringArray   Set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --timeout int              Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300)\n      --tls                      Enable TLS for request\n      --tls-ca-cert string       Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string          Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string      The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string           Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify               Enable TLS for request and verify remote\n      --username string          Chart repository username where to locate the requested chart\n  -f, --values valueFiles        Specify values in a YAML file or a URL(can specify multiple) (default [])\n      --verify                   Verify the package before installing it\n      --version string           Specify the exact chart version to install. If this is not specified, the latest version is installed\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 24-Sep-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_lint.md",
    "content": "---\ntitle: \"helm lint\"\nsidebar_position: 22\nsidebar_label: \"Helm Lint\"\n---\nExamines a chart for possible issues\n\n### Synopsis\n\n\nThis command takes a path to a chart and runs a series of tests to verify that\nthe chart is well-formed.\n\nIf the linter encounters things that will cause the chart to fail installation,\nit will emit [ERROR] messages. If it encounters issues that break with convention\nor recommendation, it will emit [WARNING] messages.\n\n\n```\nhelm lint [flags] PATH\n```\n\n### Options\n\n```\n  -h, --help                     help for lint\n      --namespace string         Namespace to put the release into (default \"default\")\n      --set stringArray          Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-string stringArray   Set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --strict                   Fail on lint warnings\n  -f, --values valueFiles        Specify values in a YAML file (can specify multiple) (default [])\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_list.md",
    "content": "---\ntitle: \"helm list\"\nsidebar_position: 23\nsidebar_label: \"Helm List\"\n---\nList releases\n\n### Synopsis\n\n\nThis command lists all of the releases.\n\nBy default, it lists only releases that are deployed or failed. Flags like\n'--deleted' and '--all' will alter this behavior. Such flags can be combined:\n'--deleted --failed'.\n\nBy default, items are sorted alphabetically. Use the '-d' flag to sort by\nrelease date.\n\nIf an argument is provided, it will be treated as a filter. Filters are\nregular expressions (Perl compatible) that are applied to the list of releases.\nOnly items that match the filter will be returned.\n\n\t$ helm list 'ara[a-z]+'\n\tNAME            \tUPDATED                 \tCHART\n\tmaudlin-arachnid\tMon May  9 16:07:08 2016\talpine-0.1.0\n\nIf no results are found, 'helm list' will exit 0, but with no output (or in\nthe case of no '-q' flag, only headers).\n\nBy default, up to 256 items may be returned. To limit this, use the '--max' flag.\nSetting '--max' to 0 will not return all results. Rather, it will return the\nserver's default, which may be much higher than 256. Pairing the '--max'\nflag with the '--offset' flag allows you to page through results.\n\n\n```\nhelm list [flags] [FILTER]\n```\n\n### Options\n\n```\n  -a, --all                   Show all releases, not just the ones marked DEPLOYED\n  -c, --chart-name            Sort by chart name\n      --col-width uint        Specifies the max column width of output (default 60)\n  -d, --date                  Sort by release date\n      --deleted               Show deleted releases\n      --deleting              Show releases that are currently being deleted\n      --deployed              Show deployed releases. If no other is specified, this will be automatically enabled\n      --failed                Show failed releases\n  -h, --help                  help for list\n  -m, --max int               Maximum number of releases to fetch (default 256)\n      --namespace string      Show releases within a specific namespace\n  -o, --offset string         Next release name in the list, used to offset from start value\n      --output string         Output the specified format (json or yaml)\n      --pending               Show pending releases\n  -r, --reverse               Reverse the sort order\n  -q, --short                 Output short (quiet) listing format\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_package.md",
    "content": "---\ntitle: \"helm package\"\nsidebar_position: 24\nsidebar_label: \"Helm Package\"\n---\nPackage a chart directory into a chart archive\n\n### Synopsis\n\n\nThis command packages a chart into a versioned chart archive file. If a path\nis given, this will look at that path for a chart (which must contain a\nChart.yaml file) and then package that directory.\n\nIf no path is given, this will look in the present working directory for a\nChart.yaml file, and (if found) build the current directory into a chart.\n\nVersioned chart archives are used by Helm package repositories.\n\n\n```\nhelm package [flags] [CHART_PATH] [...]\n```\n\n### Options\n\n```\n      --app-version string   Set the appVersion on the chart to this version\n  -u, --dependency-update    Update dependencies from \"requirements.yaml\" to dir \"charts/\" before packaging\n  -d, --destination string   Location to write the chart. (default \".\")\n  -h, --help                 help for package\n      --key string           Name of the key to use when signing. Used if --sign is true\n      --keyring string       Location of a public keyring (default \"~/.gnupg/pubring.gpg\")\n      --save                 Save packaged chart to local chart repository (default true)\n      --sign                 Use a PGP private key to sign this package\n      --version string       Set the version on the chart to this semver version\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_plugin.md",
    "content": "---\ntitle: \"helm plugin\"\nsidebar_position: 25\nsidebar_label: \"Helm Plugin\"\n---\nAdd, list, or remove Helm plugins\n\n### Synopsis\n\n\nManage client-side Helm plugins.\n\n\n### Options\n\n```\n  -h, --help   help for plugin\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n* [helm plugin install](helm_plugin_install.md)\t - Install one or more Helm plugins\n* [helm plugin list](helm_plugin_list.md)\t - List installed Helm plugins\n* [helm plugin remove](helm_plugin_remove.md)\t - Remove one or more Helm plugins\n* [helm plugin update](helm_plugin_update.md)\t - Update one or more Helm plugins\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_plugin_install.md",
    "content": "---\ntitle: \"helm plugin install\"\nsidebar_position: 26\nsidebar_label: \"Helm Plugin Install\"\n---\nInstall one or more Helm plugins\n\n### Synopsis\n\n\nThis command allows you to install a plugin from a url to a VCS repo or a local path.\n\nExample usage:\n    $ helm plugin install https://github.com/technosophos/helm-template\n\n\n```\nhelm plugin install [options] <path|url>... [flags]\n```\n\n### Options\n\n```\n  -h, --help             help for install\n      --version string   Specify a version constraint. If this is not specified, the latest version is installed\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm plugin](helm_plugin.md)\t - Add, list, or remove Helm plugins\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_plugin_list.md",
    "content": "---\ntitle: \"helm plugin list\"\nsidebar_position: 27\nsidebar_label: \"Helm Plugin List\"\n---\nList installed Helm plugins\n\n### Synopsis\n\nList installed Helm plugins\n\n```\nhelm plugin list [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for list\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm plugin](helm_plugin.md)\t - Add, list, or remove Helm plugins\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_plugin_remove.md",
    "content": "---\ntitle: \"helm plugin remove\"\nsidebar_position: 28\nsidebar_label: \"Helm Plugin Remove\"\n---\nRemove one or more Helm plugins\n\n### Synopsis\n\nRemove one or more Helm plugins\n\n```\nhelm plugin remove <plugin>... [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for remove\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm plugin](helm_plugin.md)\t - Add, list, or remove Helm plugins\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_plugin_update.md",
    "content": "---\ntitle: \"helm plugin update\"\nsidebar_position: 29\nsidebar_label: \"Helm Plugin Update\"\n---\nUpdate one or more Helm plugins\n\n### Synopsis\n\nUpdate one or more Helm plugins\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for update\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm plugin](helm_plugin.md)\t - Add, list, or remove Helm plugins\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_repo.md",
    "content": "---\ntitle: \"helm repo\"\nsidebar_position: 30\nsidebar_label: \"Helm Repo\"\n---\nAdd, list, remove, update, and index chart repositories\n\n### Synopsis\n\n\nThis command consists of multiple subcommands to interact with chart repositories.\n\nIt can be used to add, remove, list, and index chart repositories.\nExample usage:\n    $ helm repo add [NAME] [REPO_URL]\n\n\n### Options\n\n```\n  -h, --help   help for repo\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n* [helm repo add](helm_repo_add.md)\t - Add a chart repository\n* [helm repo index](helm_repo_index.md)\t - Generate an index file given a directory containing packaged charts\n* [helm repo list](helm_repo_list.md)\t - List chart repositories\n* [helm repo remove](helm_repo_remove.md)\t - Remove a chart repository\n* [helm repo update](helm_repo_update.md)\t - Update information of available charts locally from chart repositories\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_repo_add.md",
    "content": "---\ntitle: \"helm repo add\"\nsidebar_position: 31\nsidebar_label: \"Helm Repo Add\"\n---\nAdd a chart repository\n\n### Synopsis\n\nAdd a chart repository\n\n```\nhelm repo add [flags] [NAME] [URL]\n```\n\n### Options\n\n```\n      --ca-file string     Verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string   Identify HTTPS client using this SSL certificate file\n  -h, --help               help for add\n      --key-file string    Identify HTTPS client using this SSL key file\n      --no-update          Raise error if repo is already registered\n      --password string    Chart repository password\n      --username string    Chart repository username\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm repo](helm_repo.md)\t - Add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_repo_index.md",
    "content": "---\ntitle: \"helm repo index\"\nsidebar_position: 32\nsidebar_label: \"Helm Repo Index\"\n---\nGenerate an index file given a directory containing packaged charts\n\n### Synopsis\n\n\nRead the current directory and generate an index file based on the charts found.\n\nThis tool is used for creating an 'index.yaml' file for a chart repository. To\nset an absolute URL to the charts, use '--url' flag.\n\nTo merge the generated index with an existing index file, use the '--merge'\nflag. In this case, the charts found in the current directory will be merged\ninto the existing index, with local charts taking priority over existing charts.\n\n\n```\nhelm repo index [flags] [DIR]\n```\n\n### Options\n\n```\n  -h, --help           help for index\n      --merge string   Merge the generated index into the given index\n      --url string     URL of the chart repository\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm repo](helm_repo.md)\t - Add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_repo_list.md",
    "content": "---\ntitle: \"helm repo list\"\nsidebar_position: 33\nsidebar_label: \"Helm Repo List\"\n---\nList chart repositories\n\n### Synopsis\n\nList chart repositories\n\n```\nhelm repo list [flags]\n```\n\n### Options\n\n```\n  -h, --help            help for list\n  -o, --output string   Prints the output in the specified format. Allowed values: table, json, yaml (default \"table\")\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm repo](helm_repo.md)\t - Add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 24-Sep-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_repo_remove.md",
    "content": "---\ntitle: \"helm repo remove\"\nsidebar_position: 34\nsidebar_label: \"Helm Repo Remove\"\n---\nRemove a chart repository\n\n### Synopsis\n\nRemove a chart repository\n\n```\nhelm repo remove [flags] [NAME]\n```\n\n### Options\n\n```\n  -h, --help   help for remove\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm repo](helm_repo.md)\t - Add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_repo_update.md",
    "content": "---\ntitle: \"helm repo update\"\nsidebar_position: 35\nsidebar_label: \"Helm Repo Update\"\n---\nUpdate information of available charts locally from chart repositories\n\n### Synopsis\n\n\nUpdate gets the latest information about charts from the respective chart repositories.\nInformation is cached locally, where it is used by commands like 'helm search'.\n\n'helm update' is the deprecated form of 'helm repo update'. It will be removed in\nfuture releases.\n\nYou can specify the name of a repository you want to update.\n\n\t$ helm repo update <repo_name>\n\nTo update all the repositories, use 'helm repo update'.\n\n\n\n```\nhelm repo update [REPO_NAME] [flags]\n```\n\n### Options\n\n```\n  -h, --help     help for update\n      --strict   Fail on update warnings\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm repo](helm_repo.md)\t - Add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 7-Jun-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_reset.md",
    "content": "---\ntitle: \"helm reset\"\nsidebar_position: 36\nsidebar_label: \"Helm Reset\"\n---\nUninstalls Tiller from a cluster\n\n### Synopsis\n\n\nThis command uninstalls Tiller (the Helm server-side component) from your\nKubernetes Cluster and optionally deletes local configuration in\n$HELM_HOME (default ~/.helm/)\n\n\n```\nhelm reset [flags]\n```\n\n### Options\n\n```\n  -f, --force                 Forces Tiller uninstall even if there are releases installed, or if Tiller is not in ready state. Releases are not deleted.)\n  -h, --help                  help for reset\n      --remove-helm-home      If set, deletes $HELM_HOME\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_rollback.md",
    "content": "---\ntitle: \"helm rollback\"\nsidebar_position: 37\nsidebar_label: \"Helm Rollback\"\n---\nRollback a release to a previous revision\n\n### Synopsis\n\n\nThis command rolls back a release to a previous revision.\n\nThe first argument of the rollback command is the name of a release, and the\nsecond is a revision (version) number. To see revision numbers, run\n'helm history RELEASE'. If you'd like to rollback to the previous release use\n'helm rollback [RELEASE] 0'.\n\n\n```\nhelm rollback [flags] [RELEASE] [REVISION]\n```\n\n### Options\n\n```\n      --cleanup-on-fail       Allow deletion of new resources created in this rollback when rollback failed\n      --description string    Specify a description for the release\n      --dry-run               Simulate a rollback\n      --force                 Force resource update through delete/recreate if needed\n  -h, --help                  help for rollback\n      --no-hooks              Prevent hooks from running during rollback\n      --recreate-pods         Performs pods restart for the resource if applicable\n      --timeout int           Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300)\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_search.md",
    "content": "---\ntitle: \"helm search\"\nsidebar_position: 38\nsidebar_label: \"Helm Search\"\n---\nSearch for a keyword in charts\n\n### Synopsis\n\n\nSearch reads through all of the repositories configured on the system, and\nlooks for matches.\n\nIt will display the latest stable versions of the charts found. If you\nspecify the --devel flag, the output will include pre-release versions.\nIf you want to search using a version constraint, use --version.\n\nExamples:\n\n    # Search for stable release versions matching the keyword \"nginx\"\n    helm search nginx\n\n    # Search for release versions matching the keyword \"nginx\", including pre-release versions\n    helm search nginx --devel\n\n    # Search for the latest stable release for nginx-ingress with a major version of 1\n    helm search nginx-ingress --version ^1.0.0\n\nRepositories are managed with 'helm repo' commands.\n\nTo look for charts with a particular name (such as stable/mysql), try\nsearching using vertical tabs (\\v). Vertical tabs are used as the delimiter\nbetween search fields. For example:\n\n    helm search --regexp '\\vstable/mysql\\v'\n\nTo search for charts using common keywords (such as \"database\" or\n\"key-value store\"), use\n\n    helm search database\n\nor\n\n    helm search key-value store\n\n\n```\nhelm search [keyword] [flags]\n```\n\n### Options\n\n```\n      --col-width uint   Specifies the max column width of output (default 60)\n      --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\n  -h, --help             help for search\n  -o, --output string    Prints the output in the specified format. Allowed values: table, json, yaml (default \"table\")\n  -r, --regexp           Use regular expressions for searching\n  -v, --version string   Search using semantic versioning constraints\n  -l, --versions         Show the long listing, with each version of each chart on its own line\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 30-Oct-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_serve.md",
    "content": "---\ntitle: \"helm serve\"\nsidebar_position: 39\nsidebar_label: \"Helm Serve\"\n---\nStart a local http web server\n\n### Synopsis\n\n\nThis command starts a local chart repository server that serves charts from a local directory.\n\nThe new server will provide HTTP access to a repository. By default, it will\nscan all of the charts in '$HELM_HOME/repository/local' and serve those over\nthe local IPv4 TCP port (default '127.0.0.1:8879').\n\nThis command is intended to be used for educational and testing purposes only.\nIt is best to rely on a dedicated web server or a cloud-hosted solution like\nGoogle Cloud Storage for production use.\n\nSee https://github.com/helm/helm/blob/master/docs/chart_repository.md#hosting-chart-repositories\nfor more information on hosting chart repositories in a production setting.\n\n\n```\nhelm serve [flags]\n```\n\n### Options\n\n```\n      --address string     Address to listen on (default \"127.0.0.1:8879\")\n  -h, --help               help for serve\n      --repo-path string   Local directory path from which to serve charts\n      --url string         External URL of chart repository\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_status.md",
    "content": "---\ntitle: \"helm status\"\nsidebar_position: 40\nsidebar_label: \"Helm Status\"\n---\nDisplays the status of the named release\n\n### Synopsis\n\n\nThis command shows the status of a named release.\nThe status consists of:\n- last deployment time\n- k8s namespace in which the release lives\n- state of the release (can be: UNKNOWN, DEPLOYED, DELETED, SUPERSEDED, FAILED or DELETING)\n- list of resources that this release consists of, sorted by kind\n- details on last test suite run, if applicable\n- additional notes provided by the chart\n\n\n```\nhelm status [flags] RELEASE_NAME\n```\n\n### Options\n\n```\n  -h, --help                  help for status\n  -o, --output string         Prints the output in the specified format. Allowed values: table, json, yaml (default \"table\")\n      --revision int32        If set, display the status of the named release with revision\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 6-Sep-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_template.md",
    "content": "---\ntitle: \"helm template\"\nsidebar_position: 41\nsidebar_label: \"Helm Template\"\n---\nLocally render templates\n\n### Synopsis\n\n\nRender chart templates locally and display the output.\n\nThis does not require Tiller. However, any values that would normally be\nlooked up or retrieved in-cluster will be faked locally. Additionally, none\nof the server-side testing of chart validity (e.g. whether an API is supported)\nis done.\n\nTo render just one template in a chart, use '-x':\n\n\t$ helm template mychart -x templates/deployment.yaml\n\n\n```\nhelm template [flags] CHART\n```\n\n### Options\n\n```\n  -a, --api-versions stringArray   Kubernetes api versions used for Capabilities.APIVersions\n  -x, --execute stringArray        Only execute the given templates\n  -h, --help                       help for template\n      --is-upgrade                 Set .Release.IsUpgrade instead of .Release.IsInstall\n      --kube-version string        Kubernetes version used as Capabilities.KubeVersion.Major/Minor (default \"1.14\")\n  -n, --name string                Release name (default \"release-name\")\n      --name-template string       Specify template used to name the release\n      --namespace string           Namespace to install the release into\n      --notes                      Show the computed NOTES.txt file as well\n      --output-dir string          Writes the executed templates to files in output-dir instead of stdout\n      --set stringArray            Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-string stringArray     Set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n  -f, --values valueFiles          Specify values in a YAML file (can specify multiple) (default [])\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 3-Oct-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_test.md",
    "content": "---\ntitle: \"helm test\"\nsidebar_position: 42\nsidebar_label: \"Helm Test\"\n---\nTest a release\n\n### Synopsis\n\n\nThe test command runs the tests for a release.\n\nThe argument this command takes is the name of a deployed release.\nThe tests to be run are defined in the chart that was installed.\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### Options\n\n```\n      --cleanup               Delete test pods upon completion\n  -h, --help                  help for test\n      --logs                  Dump the logs from test pods (this runs after all tests are complete, but before any cleanup\n      --max uint32            Maximum number of test pods to run in parallel (default 20)\n      --parallel              Run test pods in parallel\n      --timeout int           Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300)\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 8-Oct-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_upgrade.md",
    "content": "---\ntitle: \"helm upgrade\"\nsidebar_position: 43\nsidebar_label: \"Helm Upgrade\"\n---\nUpgrade a release\n\n### Synopsis\n\n\nThis command upgrades a release to a specified version of a chart and/or updates chart values.\n\nRequired arguments are release and chart. The chart argument can be one of:\n - a chart reference('stable/mariadb'); use '--version' and '--devel' flags for versions other than latest,\n - a path to a chart directory,\n - a packaged chart,\n - a fully qualified URL.\n\nTo customize the chart values, use any of\n - '--values'/'-f' to pass in a yaml file holding settings,\n - '--set' to provide one or more key=val pairs directly,\n - '--set-string' to provide key=val forcing val to be stored as a string,\n - '--set-file' to provide key=path to read a single large value from a file at path.\n\nTo edit or append to the existing customized values, add the\n '--reuse-values' flag, otherwise any existing customized values are ignored.\n\nIf no chart value arguments are provided on the command line, any existing customized values are carried\nforward. If you want to revert to just the values provided in the chart, use the '--reset-values' flag.\n\nYou can specify any of the chart value flags multiple times. The priority will be given to the last\n(right-most) value specified. For example, if both myvalues.yaml and override.yaml contained a key\ncalled 'Test', the value set in override.yaml would take precedence:\n\n\t$ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\nNote that the key name provided to the '--set', '--set-string' and '--set-file' flags can reference\nstructure elements. Examples:\n  - mybool=TRUE\n  - livenessProbe.timeoutSeconds=10\n  - metrics.annotations[0]=hey,metrics.annotations[1]=ho\n\nwhich sets the top level key mybool to true, the nested timeoutSeconds to 10, and two array values, respectively.\n\nNote that the value side of the key=val provided to '--set' and '--set-string' flags will pass through\nshell evaluation followed by yaml type parsing to produce the final value. This may alter inputs with\nspecial characters in unexpected ways, for example\n\n\t$ helm upgrade --set pwd=3jk$o2,z=f\\30.e redis ./redis\n\nresults in \"pwd: 3jk\" and \"z: f30.e\". Use single quotes to avoid shell evaluation and argument delimiters,\nand use backslash to escape yaml special characters:\n\n\t$ helm upgrade --set pwd='3jk$o2z=f\\\\30.e' redis ./redis\n\nwhich results in the expected \"pwd: 3jk$o2z=f\\30.e\". If a single quote occurs in your value then follow\nyour shell convention for escaping it; for example in bash:\n\n\t$ helm upgrade --set pwd='3jk$o2z=f\\\\30with'\\''quote'\n\nwhich results in \"pwd: 3jk$o2z=f\\30with'quote\".\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Options\n\n```\n      --atomic                   If set, upgrade process rolls back changes made in case of failed upgrade, also sets --wait flag\n      --ca-file string           Verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string         Identify HTTPS client using this SSL certificate file\n      --cleanup-on-fail          Allow deletion of new resources created in this upgrade when upgrade failed\n      --description string       Specify the description to use for the upgrade, rather than the default\n      --devel                    Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n      --dry-run                  Simulate an upgrade\n      --force                    Force resource update through delete/recreate if needed\n  -h, --help                     help for upgrade\n  -i, --install                  If a release by this name doesn't already exist, run an install\n      --key-file string          Identify HTTPS client using this SSL key file\n      --keyring string           Path to the keyring that contains public signing keys (default \"~/.gnupg/pubring.gpg\")\n      --namespace string         Namespace to install the release into (only used if --install is set). Defaults to the current kube config namespace\n      --no-hooks                 Disable pre/post upgrade hooks\n  -o, --output string            Prints the output in the specified format. Allowed values: table, json, yaml (default \"table\")\n      --password string          Chart repository password where to locate the requested chart\n      --recreate-pods            Performs pods restart for the resource if applicable\n      --render-subchart-notes    Render subchart notes along with parent\n      --repo string              Chart repository url where to locate the requested chart\n      --reset-values             When upgrading, reset the values to the ones built into the chart\n      --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.\n      --set stringArray          Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-string stringArray   Set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --timeout int              Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300)\n      --tls                      Enable TLS for request\n      --tls-ca-cert string       Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string          Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string      The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string           Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify               Enable TLS for request and verify remote\n      --username string          Chart repository username where to locate the requested chart\n  -f, --values valueFiles        Specify values in a YAML file or a URL(can specify multiple) (default [])\n      --verify                   Verify the provenance of the chart before upgrading\n      --version string           Specify the exact chart version to use. If this is not specified, the latest version is used\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 24-Sep-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_verify.md",
    "content": "---\ntitle: \"helm verify\"\nsidebar_position: 44\nsidebar_label: \"Helm Verify\"\n---\nVerify that a chart at the given path has been signed and is valid\n\n### Synopsis\n\n\nVerify that the given chart has a valid provenance file.\n\nProvenance files provide cryptographic verification that a chart has not been\ntampered with, and was packaged by a trusted provider.\n\nThis command can be used to verify a local chart. Several other commands provide\n'--verify' flags that run the same validation. To generate a signed package, use\nthe 'helm package --sign' command.\n\n\n```\nhelm verify [flags] PATH\n```\n\n### Options\n\n```\n  -h, --help             help for verify\n      --keyring string   Keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/helm/helm_version.md",
    "content": "---\ntitle: \"helm version\"\nsidebar_position: 45\nsidebar_label: \"Helm Version\"\n---\nPrint the client/server version information\n\n### Synopsis\n\n\nShow the client and server versions for Helm and tiller.\n\nThis will print a representation of the client and server versions of Helm and\nTiller. The output will look something like this:\n\nClient: &version.Version{SemVer:\"v2.0.0\", GitCommit:\"ff52399e51bb880526e9cd0ed8386f6433b74da1\", GitTreeState:\"clean\"}\nServer: &version.Version{SemVer:\"v2.0.0\", GitCommit:\"b0c113dfb9f612a9add796549da66c0d294508a3\", GitTreeState:\"clean\"}\n\n- SemVer is the semantic version of the release.\n- GitCommit is the SHA for the commit that this version was built from.\n- GitTreeState is \"clean\" if there are no local code changes when this binary was\n  built, and \"dirty\" if the binary was built from locally modified code.\n\nTo print just the client version, use '--client'. To print just the server version,\nuse '--server'.\n\n\n```\nhelm version [flags]\n```\n\n### Options\n\n```\n  -c, --client                Client version only\n  -h, --help                  help for version\n  -s, --server                Server version only\n      --short                 Print the version number\n      --template string       Template for version string format\n      --tls                   Enable TLS for request\n      --tls-ca-cert string    Path to TLS CA certificate file (default \"$HELM_HOME/ca.pem\")\n      --tls-cert string       Path to TLS certificate file (default \"$HELM_HOME/cert.pem\")\n      --tls-hostname string   The server name used to verify the hostname on the returned certificates from the server\n      --tls-key string        Path to TLS key file (default \"$HELM_HOME/key.pem\")\n      --tls-verify            Enable TLS for request and verify remote\n```\n\n### Options inherited from parent commands\n\n```\n      --debug                           Enable verbose output\n      --home string                     Location of your Helm config. Overrides $HELM_HOME (default \"~/.helm\")\n      --host string                     Address of Tiller. Overrides $HELM_HOST\n      --kube-context string             Name of the kubeconfig context to use\n      --kubeconfig string               Absolute path of the kubeconfig file to be used\n      --tiller-connection-timeout int   The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)\n      --tiller-namespace string         Namespace of Tiller (default \"kube-system\")\n```\n\n### SEE ALSO\n\n* [helm](helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 16-May-2019\n"
  },
  {
    "path": "versioned_docs/version-2/history.md",
    "content": "---\nsidebar_position: 11\nsidebar_label: \"History\"\n---\n## The History of the Project\n\nKubernetes Helm is the merged result of [Helm\nClassic](https://github.com/helm/helm) and the Kubernetes port of GCS Deployment\nManager. The project was jointly started by Google and Deis, though it\nis now part of the CNCF. Many companies now contribute regularly to Helm.\n\nDifferences from Helm Classic:\n\n- Helm now has both a client (`helm`) and a server (`tiller`). The\n  server runs inside of Kubernetes, and manages your resources.\n- Helm's chart format has changed for the better:\n  - Dependencies are immutable and stored inside of a chart's `charts/`\n    directory.\n  - Charts are strongly versioned using [SemVer 2](https://semver.org/spec/v2.0.0.html)\n  - Charts can be loaded from directories or from chart archive files\n  - Helm supports Go templates without requiring you to run `generate`\n    or `template` commands.\n  - Helm makes it easy to configure your releases -- and share the\n    configuration with the rest of your team.\n- Helm chart repositories now use plain HTTP(S) instead of Git/GitHub.\n  There is no longer any GitHub dependency.\n  - A chart server is a simple HTTP server\n  - Charts are referenced by version\n  - The `helm serve` command will run a local chart server, though you\n    can easily use object storage (S3, GCS) or a regular web server.\n  - And you can still load charts from a local directory.\n- The Helm workspace is gone. You can now work anywhere on your\n  filesystem that you want to work.\n"
  },
  {
    "path": "versioned_docs/version-2/index.mdx",
    "content": "---\ntitle: \"Docs Home\"\nsidebar_position: 1\n---\n\nComplete documentation for Helm v2, the Kubernetes package manager. Learn how to install, configure, and use Helm to deploy applications to your Kubernetes cluster.\n\nimport DocCardList from \"@theme/DocCardList\";\n\n<DocCardList />\n\n"
  },
  {
    "path": "versioned_docs/version-2/related.md",
    "content": "---\nsidebar_position: 8\nsidebar_label: \"Related Projects\"\n---\n# Related Projects and Documentation\n\nThe Helm community has produced many extra tools, plugins, and documentation about\nHelm. We love to hear about these projects. If you have anything you'd like to\nadd to this list, please open an [issue](https://github.com/helm/helm/issues)\nor [pull request](https://github.com/helm/helm/pulls).\n\n## Article, Blogs, How-Tos, and Extra Documentation\n\n- [Awesome Helm](https://github.com/cdwv/awesome-helm) - List of awesome Helm resources\n- [CI/CD with Kubernetes, Helm & Wercker ](https://www.slideshare.net/Diacode/cicd-with-kubernetes-helm-wercker-madscalability)\n- [Creating a Helm Plugin in 3 Steps](http://technosophos.com/2017/03/21/creating-a-helm-plugin.html)\n- [Deploying Kubernetes Applications with Helm](https://cloudacademy.com/blog/deploying-kubernetes-applications-with-helm/)\n- [GitLab, Consumer Driven Contracts, Helm and Kubernetes](https://medium.com/@enxebre/gitlab-consumer-driven-contracts-helm-and-kubernetes-b7235a60a1cb#.xwp1y4tgi)\n- [Honestbee's Helm Chart Conventions](https://gist.github.com/so0k/f927a4b60003cedd101a0911757c605a)\n- [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)\n- [The Missing CI/CD Kubernetes Component: Helm package manager](https://medium.com/@gajus/the-missing-ci-cd-kubernetes-component-helm-package-manager-1fe002aac680)\n- [Using Helm to Deploy to Kubernetes](https://daemonza.github.io/2017/02/20/using-helm-to-deploy-to-kubernetes/)\n- [Writing a Helm Chart](https://www.influxdata.com/packaged-kubernetes-deployments-writing-helm-chart/)\n- [A basic walk through Kubernetes Helm](https://github.com/muffin87/helm-tutorial)\n- [Tillerless Helm v2](https://rimusz.net/tillerless-helm/)\n- [Generating Certificate Authorities and Certificates using Terraform](https://github.com/jbussdieker/tiller-ssl-terraform)\n\n## Video, Audio, and Podcast\n\n- [CI/CD with Jenkins, Kubernetes, and Helm](https://www.youtube.com/watch?v=NVoln4HdZOY): AKA \"The Infamous Croc Hunter Video\".\n- [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.\n- [KubeCon2016: Delivering Kubernetes-Native Applications by Michelle Noorali](https://www.youtube.com/watch?v=zBc1goRfk3k&index=49&list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4)\n\n## Helm Plugins\n\n- [App Registry](https://github.com/app-registry/helm-plugin) - Plugin to manage charts via the [App Registry specification](https://github.com/app-registry/spec)\n- [helm-backup](https://github.com/maorfr/helm-backup) - Plugin which performs backup/restore of releases in a namespace to/from a file\n- [Helm Diff](https://github.com/databus23/helm-diff) - Preview `helm upgrade` as a coloured diff\n- [Helm Value Store](https://github.com/skuid/helm-value-store) - Plugin for working with Helm deployment values\n- [Technosophos's Helm Plugins](https://github.com/technosophos/helm-plugins) - Plugins for GitHub, Keybase, and GPG\n- [helm-convert](https://github.com/ContainerSolutions/helm-convert) - Plugin to convert charts into Kustomize compatible packages\n- [helm-cos](https://github.com/imroc/helm-cos) - Plugin to manage repositories on Tencent Cloud Object Storage\n- [helm-edit](https://github.com/mstrzele/helm-edit) - Plugin for editing release's values\n- [helm-env](https://github.com/adamreese/helm-env) - Plugin to show current environment\n- [helm-gcs](https://github.com/hayorov/helm-gcs) - Plugin to manage repositories on Google Cloud Storage\n- [helm-github](https://github.com/sagansystems/helm-github) - Plugin to install Helm Charts from Github repositories\n- [helm-hashtag](https://github.com/balboah/helm-hashtag) - Plugin for tracking docker tag hash digests as values\n- [helm-inject](https://github.com/maorfr/helm-inject) - Plugin for injecting additional configurations during release upgrade\n- [helm-k8comp](https://github.com/cststack/k8comp) - Plugin to create Helm Charts from hiera using k8comp\n- [helm-last](https://github.com/adamreese/helm-last) - Plugin to show the latest release\n- [helm-local](https://github.com/adamreese/helm-local) - Plugin to run Tiller as a local daemon\n- [helm-logs](https://github.com/maorfr/helm-logs) - Plugin to view changed releases over time\n- [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - Plugin to monitor a release and rollback based on Prometheus/ElasticSearch query\n- [helm-nexus](https://github.com/yisiqi/helm-nexus) - Plugin to use Sonatype Nexus OSS as your own charts repository.\n- [helm-nuke](https://github.com/adamreese/helm-nuke) - Plugin to destroy all releases\n- [helm-plugin-utils](https://github.com/maorfr/helm-plugin-utils) - Utility functions to be used within Helm plugins\n- [helm-restore](https://github.com/maorfr/helm-restore) - Plugin to restore a deployed release to its original state\n- [helm-secrets](https://github.com/futuresimple/helm-secrets) - Plugin to manage and store secrets safely\n- [helm-ssm](https://github.com/codacy/helm-ssm) - Plugin to inject values coming from AWS SSM parameters on the `values.yaml` file\n- [helm-stop](https://github.com/IBM/helm-stop) - Plugin for stopping a release pods\n- [helm-template](https://github.com/technosophos/helm-template) - Debug/render templates client-side\n- [helm-tiller](https://github.com/adamreese/helm-tiller) - Additional commands to work with Tiller\n- [helm-tiller-info](https://github.com/maorfr/helm-tiller-info) - Plugin which prints information about Tiller\n- [helm-unittest](https://github.com/lrills/helm-unittest) - Plugin for unit testing chart locally with YAML\n- [Tillerless Helm v2](https://github.com/rimusz/helm-tiller) - Helm plugin for using Tiller locally and in CI/CD pipelines\n\nWe also encourage GitHub authors to use the [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)\ntag on their plugin repositories.\n\n## Additional Tools\n\nTools layered on top of Helm or Tiller.\n\n- [AppsCode Swift](https://github.com/appscode/swift) - Ajax friendly Helm Tiller Proxy using [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway)\n- [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.\n- [ChartMuseum](https://github.com/chartmuseum/chartmuseum) - Helm Chart Repository with support for Amazon S3 and Google Cloud Storage\n- [Chartify](https://github.com/appscode/chartify) - Generate Helm charts from existing Kubernetes resources.\n- [Cloudsmith](https://cloudsmith.io/l/helm-repository/) - Fully managed SaaS offering private Helm Chart Repositories\n- [Codefresh](https://codefresh.io) - Kubernetes native CI/CD and management platform with UI dashboards for managing Helm charts and releases\n- [Cog](https://github.com/ohaiwalt/cog-helm) - Helm chart to deploy Cog on Kubernetes\n- [Drone.io Helm Plugin](http://plugins.drone.io/ipedrazas/drone-helm/) - Run Helm inside of the Drone CI/CD system\n- [Helm Chart Publisher](https://github.com/luizbafilho/helm-chart-publisher) - HTTP API for publishing Helm Charts in an easy way\n- [Helm.NET](https://github.com/qmfrederik/helm) - A .NET client for Tiller's API\n- [Helmfile](https://github.com/roboll/helmfile) - Helmfile is a declarative spec for deploying helm charts\n- [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).\n- [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.\"\n- [Monocular](https://github.com/helm/monocular) - Web UI for Helm Chart repositories\n- [Orca](https://github.com/nuvo/orca) - Advanced CI\\CD tool for Kubernetes and Helm made simple.\n- [Quay App Registry](https://coreos.com/blog/quay-application-registry-for-kubernetes.html) - Open Kubernetes application registry, including a Helm access client\n- [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.\n- [Rudder](https://github.com/AcalephStorage/rudder) - RESTful (JSON) proxy for Tiller's API\n- [Schelm](https://github.com/databus23/schelm) - Render a Helm manifest to a directory\n- [Shipper](https://github.com/bookingcom/shipper) - Multi-cluster canary or blue-green rollouts using Helm\n- [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - VIM plugin for Kubernetes and Helm\n\n## Helm Included\n\nPlatforms, distributions, and services that include Helm support.\n\n- [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.\n- [Fabric8](https://fabric8.io) - Integrated development platform for Kubernetes\n- [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)\n- [Kubernetic](https://kubernetic.com/) - Kubernetes Desktop Client\n- [Qstack](https://qstack.com)\n\n## Misc\n\nGrab bag of useful things for Chart authors and Helm users\n\n- [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/)\n"
  },
  {
    "path": "versioned_docs/version-2/using_helm/install.md",
    "content": "---\nsidebar_position: 1\nsidebar_label: \"Installing Helm\"\n---\n# Installing Helm\n\nThere are two parts to Helm: The Helm client (`helm`) and the Helm\nserver (Tiller). This guide shows how to install the client, and then\nproceeds to show two ways to install the server.\n\n**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).\n\n## Installing the Helm Client\n\nThe Helm client can be installed either from source, or from pre-built binary\nreleases.\n\n### From The Helm Project\n\nThe Helm project provides two ways to fetch and install Helm. These are the\nofficial methods to get Helm releases. In addition to that, the Helm community\nprovides methods to install Helm through different package managers. Installation\nthrough those methods can be found below the official methods.\n\n#### From the Binary Releases\n\nEvery [release](https://github.com/helm/helm/releases) of Helm\nprovides binary releases for a variety of OSes. These binary versions\ncan be manually downloaded and installed.\n\n1. Download your [desired version](https://github.com/helm/helm/releases)\n2. Unpack it (`tar -zxvf helm-v2.0.0-linux-amd64.tgz`)\n3. Find the `helm` binary in the unpacked directory, and move it to its\n   desired destination (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nFrom there, you should be able to run the client: `helm help`.\n\n#### From Script\n\nHelm now has an installer script that will automatically grab the latest version\nof the Helm client and [install it locally](https://git.io/get_helm.sh).\n\nYou can fetch that script, and then execute it locally. It's well documented so\nthat you can read through it and understand what it is doing before you run it.\n\n```\n$ curl -LO https://git.io/get_helm.sh\n$ chmod 700 get_helm.sh\n$ ./get_helm.sh\n```\n\nYes, you can `curl -L https://git.io/get_helm.sh | bash` that if you want to live on the edge.\n\n### Through Package Managers\n\nThe Helm community provides the ability to install Helm through operating system\npackage managers. These are not supported by the Helm project and are not considered\ntrusted 3rd parties.\n\n#### From Snap (Linux)\n\nThe Snap package for Helm is maintained by\n[Snapcrafters](https://github.com/snapcrafters/helm).\n\n```\nsudo snap install helm --classic\n```\n\n#### From Homebrew (macOS)\n\nMembers of the Helm community have contributed a Helm formula build to\nHomebrew. This formula is generally up to date.\n\n```\nbrew install kubernetes-helm\n```\n\n(Note: There is also a formula for emacs-helm, which is a different\nproject.)\n\n### #From Chocolatey or scoop (Windows)\n\nMembers of the Helm community have contributed a [Helm package](https://chocolatey.org/packages/kubernetes-helm) build to\n[Chocolatey](https://chocolatey.org/). This package is generally up to date.\n\n```\nchoco install kubernetes-helm\n```\n\nThe binary can also be installed via [`scoop`](https://scoop.sh) command-line installer.\n\n```\nscoop install helm\n```\n\n#### From Apt (Debian/Ubuntu)\n\nMembers of the Helm community have contributed a [Helm\npackage](https://helm.baltorepo.com/stable/debian/) for Apt. This package is generally up to date.\n\n```\ncurl https://baltocdn.com/helm/signing.asc | sudo apt-key add -\nsudo apt-get install apt-transport-https --yes\necho \"deb https://baltocdn.com/helm/stable/debian/ all main\" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list\nsudo apt-get update\nsudo apt-get install helm2\n```\n\n### Development Builds\n\nIn addition to releases you can download or install development snapshots of Helm.\n\n#### From Canary Builds\n\n\"Canary\" builds are versions of the Helm software that are built from\nthe latest master branch. They are not official releases, and may not be\nstable. However, they offer the opportunity to test the cutting edge\nfeatures.\n\nCanary Helm binaries are stored at [get.helm.sh](https://get.helm.sh).\nHere are links to the common builds:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n#### From Source (Linux, macOS)\n\nBuilding Helm from source is slightly more work, but is the best way to\ngo if you want to test the latest (pre-release) Helm version.\n\nYou must have a working Go environment with\n[glide](https://github.com/Masterminds/glide) installed.\n\n```console\n$ cd $GOPATH\n$ mkdir -p src/k8s.io\n$ cd src/k8s.io\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make bootstrap build\n```\n\nThe `bootstrap` target will attempt to install dependencies, rebuild the\n`vendor/` tree, and validate configuration.\n\nThe `build` target will compile `helm` and place it in `bin/helm`.\nTiller is also compiled, and is placed in `bin/tiller`.\n\n## Installing Tiller\n\nTiller, the server portion of Helm, typically runs inside of your\nKubernetes cluster. But for development, it can also be run locally, and\nconfigured to talk to a remote Kubernetes cluster.\n\n### Special Note for RBAC Users\n\nMost 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.\n\nCheck 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.\n\n### Easy In-Cluster Installation\n\nThe easiest way to install `tiller` into the cluster is simply to run\n`helm init`. This will validate that `helm`'s local environment is set\nup correctly (and set it up if necessary). Then it will connect to\nwhatever cluster `kubectl` connects to by default (`kubectl config\nview`). Once it connects, it will install `tiller` into the\n`kube-system` namespace.\n\nAfter `helm init`, you should be able to run `kubectl get pods --namespace\nkube-system` and see Tiller running.\n\nYou can explicitly tell `helm init` to...\n\n- Install the canary build with the `--canary-image` flag\n- Install a particular image (version) with `--tiller-image`\n- Install to a particular cluster with `--kube-context`\n- Install into a particular namespace with `--tiller-namespace`\n- Install Tiller with a Service Account with `--service-account` (for [RBAC enabled clusters](securing_installation.md#rbac))\n- Install Tiller without mounting a service account with `--automount-service-account false`\n\nOnce Tiller is installed, running `helm version` should show you both\nthe client and server version. (If it shows only the client version,\n`helm` cannot yet connect to the server. Use `kubectl` to see if any\n`tiller` pods are running.)\n\nHelm will look for Tiller in the `kube-system` namespace unless\n`--tiller-namespace` or `TILLER_NAMESPACE` is set.\n\n### Installing Tiller Canary Builds\n\nCanary images are built from the `master` branch. They may not be\nstable, but they offer you the chance to test out the latest features.\n\nThe easiest way to install a canary image is to use `helm init` with the\n`--canary-image` flag:\n\n```console\n$ helm init --canary-image\n```\n\nThis will use the most recently built container image. You can always\nuninstall Tiller by deleting the Tiller deployment from the\n`kube-system` namespace using `kubectl`.\n\n### Running Tiller Locally\n\nFor development, it is sometimes easier to work on Tiller locally, and\nconfigure it to connect to a remote Kubernetes cluster.\n\nThe process of building Tiller is explained above.\n\nOnce `tiller` has been built, simply start it:\n\n```console\n$ bin/tiller\nTiller running on :44134\n```\n\nWhen Tiller is running locally, it will attempt to connect to the\nKubernetes cluster that is configured by `kubectl`. (Run `kubectl config\nview` to see which cluster that is.)\n\nYou must tell `helm` to connect to this new local Tiller host instead of\nconnecting to the one in-cluster. There are two ways to do this. The\nfirst is to specify the `--host` option on the command line. The second\nis to set the `$HELM_HOST` environment variable.\n\n```console\n$ export HELM_HOST=localhost:44134\n$ helm version # Should connect to localhost.\nClient: &version.Version{SemVer:\"v2.0.0-alpha.4\", GitCommit:\"db...\", GitTreeState:\"dirty\"}\nServer: &version.Version{SemVer:\"v2.0.0-alpha.4\", GitCommit:\"a5...\", GitTreeState:\"dirty\"}\n```\n\nImportantly, even when running locally, Tiller will store release\nconfiguration in ConfigMaps inside of Kubernetes.\n\n## Upgrading Tiller\n\nAs of Helm 2.2.0, Tiller can be upgraded using `helm init --upgrade`.\n\nFor older versions of Helm, or for manual upgrades, you can use `kubectl` to modify\nthe Tiller image:\n\n```console\n$ export TILLER_TAG=v2.0.0-beta.1        # Or whatever version you want\n$ kubectl --namespace=kube-system set image deployments/tiller-deploy tiller=ghcr.io/helm/tiller:$TILLER_TAG\ndeployment \"tiller-deploy\" image updated\n```\n\nSetting `TILLER_TAG=canary` will get the latest snapshot of master.\n\n## Deleting or Reinstalling Tiller\n\nBecause Tiller stores its data in Kubernetes ConfigMaps, you can safely\ndelete and re-install Tiller without worrying about losing any data. The\nrecommended way of deleting Tiller is with `kubectl delete deployment\ntiller-deploy --namespace kube-system`, or more concisely `helm reset`.\n\nTiller can then be re-installed from the client with:\n\n```console\n$ helm init\n```\n\n## Advanced Usage\n\n`helm init` provides additional flags for modifying Tiller's deployment\nmanifest before it is installed.\n\n### Using `--node-selectors`\n\nThe `--node-selectors` flag allows us to specify the node labels required\nfor scheduling the Tiller pod.\n\nThe example below will create the specified label under the nodeSelector\nproperty.\n\n```\nhelm init --node-selectors \"beta.kubernetes.io/os\"=\"linux\"\n```\n\nThe installed deployment manifest will contain our node selector label.\n\n```\n...\nspec:\n  template:\n    spec:\n      nodeSelector:\n        beta.kubernetes.io/os: linux\n...\n```\n\n\n### Using `--override`\n\n`--override` allows you to specify properties of Tiller's\ndeployment manifest. Unlike the `--set` command used elsewhere in Helm,\n`helm init --override` manipulates the specified properties of the final\nmanifest (there is no \"values\" file). Therefore you may specify any valid\nvalue for any valid property in the deployment manifest.\n\n#### Override annotation\n\nIn the example below we use `--override` to add the revision property and set\nits value to 1.\n\n```\nhelm init --override metadata.annotations.\"deployment\\.kubernetes\\.io/revision\"=\"1\"\n```\nOutput:\n\n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  annotations:\n    deployment.kubernetes.io/revision: \"1\"\n...\n```\n\n#### Override affinity\n\nIn the example below we set properties for node affinity. Multiple\n`--override` commands may be combined to modify different properties of the\nsame list item.\n\n```\nhelm 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\"\n```\n\nThe specified properties are combined into the\n\"preferredDuringSchedulingIgnoredDuringExecution\" property's first\nlist item.\n\n```\n...\nspec:\n  strategy: {}\n  template:\n    ...\n    spec:\n      affinity:\n        nodeAffinity:\n          preferredDuringSchedulingIgnoredDuringExecution:\n          - preference:\n              matchExpressions:\n              - key: e2e-az-name\n                operator: \"\"\n            weight: 1\n...\n```\n\n### Using `--output`\n\nThe `--output` flag allows us skip the installation of Tiller's deployment\nmanifest and simply output the deployment manifest to stdout in either\nJSON or YAML format. The output may then be modified with tools like `jq`\nand installed manually with `kubectl`.\n\nIn the example below we execute `helm init` with the `--output json` flag.\n\n```\nhelm init --output json\n```\n\nThe Tiller installation is skipped and the manifest is output to stdout\nin JSON format.\n\n```\n\"apiVersion\": \"apps/v1\",\n\"kind\": \"Deployment\",\n\"metadata\": {\n    \"creationTimestamp\": null,\n    \"labels\": {\n        \"app\": \"helm\",\n        \"name\": \"tiller\"\n    },\n    \"name\": \"tiller-deploy\",\n    \"namespace\": \"kube-system\"\n},\n...\n```\n\n### Storage backends\nBy default, `tiller` stores release information in `ConfigMaps` in the namespace\nwhere it is running.\n\n#### Secret storage backend\nAs of Helm 2.7.0, there is now a beta storage backend that\nuses `Secrets` for storing release information. This was added for additional\nsecurity in protecting charts in conjunction with the release of `Secret`\nencryption in Kubernetes.\n\nTo enable the secrets backend, you'll need to init Tiller with the following\noptions:\n\n```shell\nhelm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'\n```\n\nCurrently, if you want to switch from the default backend to the secrets\nbackend, you'll have to do the migration for this on your own. When this backend\ngraduates from beta, there will be a more official path of migration\n\n#### SQL storage backend\nAs of Helm 2.14.0 there is now a beta SQL storage backend that stores release\ninformation in an SQL database (only postgres has been tested so far).\n\nUsing such a storage backend is particularly useful if your release information\nweighs more than 1MB (in which case, it can't be stored in ConfigMaps/Secrets\nbecause of internal limits in Kubernetes' underlying etcd key-value store).\n\nTo enable the SQL backend, you'll need to deploy a SQL database and init Tiller\nwith the following options:\n\n```shell\nhelm init \\\n  --override \\\n    'spec.template.spec.containers[0].args'='{--storage=sql,--sql-dialect=postgres,--sql-connection-string=postgresql://tiller-postgres:5432/helm?user=helm&password=changeme}'\n```\n\n**PRODUCTION NOTES**: it's recommended to change the username and password of\nthe SQL database in production deployments. Enabling SSL is also a good idea.\nLast, but not least, perform regular backups/snapshots of your SQL database.\n\nCurrently, if you want to switch from the default backend to the SQL backend,\nyou'll have to do the migration for this on your own. When this backend\ngraduates from beta, there will be a more official migration path.\n\n## Conclusion\n\nIn most cases, installation is as simple as getting a pre-built `helm` binary\nand running `helm init`. This document covers additional cases for those\nwho want to do more sophisticated things with Helm.\n\nOnce you have the Helm Client and Tiller successfully installed, you can\nmove on to using Helm to manage charts.\n"
  },
  {
    "path": "versioned_docs/version-2/using_helm/install_faq.md",
    "content": "---\nsidebar_position: 4\nsidebar_label: \"Install FAQ\"\n---\n# Installation: Frequently Asked Questions\n\nThis section tracks some of the more frequently encountered issues with installing\nor getting started with Helm.\n\n**We'd love your help** making this document better. To add, correct, or remove\ninformation, [file an issue](https://github.com/helm/helm/issues) or\nsend us a pull request.\n\n## Downloading\n\nI want to know more about my downloading options.\n\n**Q: I can't get to GitHub releases of the newest Helm. Where are they?**\n\nBinaries are stored at [get.helm.sh](https://get.helm.sh).\n\n**Q: Why aren't there native packages of Helm for Fedora and other Linux distros?**\n\nWe'd love to provide these or point you toward a trusted provider. If you're\ninterested in helping, we'd love it. This is how the Homebrew formula was\nstarted.\n\n**Q: Why do you provide a `curl ...|bash` script?**\n\nA: There is a script in our repository (`scripts/get`) that can be executed as\na `curl ..|bash` script. The transfers are all protected by HTTPS, and the script\ndoes some auditing of the packages it fetches. However, the script has all the\nusual dangers of any shell script.\n\nWe provide it because it is useful, but we suggest that users carefully read the\nscript first. What we'd really like, though, are better packaged releases of\nHelm.\n\n## Installing\n\nI'm trying to install Helm/Tiller, but something is not right.\n\n**Q: How do I put the Helm client files somewhere other than ~/.helm?**\n\nSet the `$HELM_HOME` environment variable, and then run `helm init`:\n\n```console\nexport HELM_HOME=/some/path\nhelm init --client-only\n```\n\nNote that if you have existing repositories, you will need to re-add them\nwith `helm repo add...`.\n\n**Q: How do I configure Helm, but not install Tiller?**\n\nA: By default, `helm init` will ensure that the local `$HELM_HOME` is configured,\nand then install Tiller on your cluster. To locally configure, but not install\nTiller, use `helm init --client-only`.\n\n**Q: How do I manually install Tiller on the cluster?**\n\nA: Tiller is installed as a Kubernetes `deployment`. You can get the manifest\nby running `helm init --dry-run --debug`, and then manually install it with\n`kubectl`. It is suggested that you do not remove or change the labels on that\ndeployment, as they are sometimes used by supporting scripts and tools.\n\n**Q: Why do I get `Error response from daemon: target is unknown` during Tiller install?**\n\nA: Users have reported being unable to install Tiller on Kubernetes instances that\nare using Docker 1.13.0. The root cause of this was a bug in Docker that made\nthat one version incompatible with images pushed to the Docker registry by\nearlier versions of Docker.\n\nThis [issue](https://github.com/docker/docker/issues/30083) was fixed shortly\nafter the release, and is available in Docker 1.13.1-RC1 and later.\n\n## Getting Started\n\nI successfully installed Helm/Tiller but I can't use it.\n\n**Q: Trying to use Helm, I get the error \"client transport was broken\"**\n\n```\nE1014 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.\n2016/10/14 02:26:32 transport: http2Client.notifyError got notified that the client transport was broken EOF.\nError: transport is closing\n```\n\nA: This is usually a good indication that Kubernetes is not set up to allow port forwarding.\n\nTypically, the missing piece is `socat`. If you are running CoreOS, we have been\ntold that it may have been misconfigured on installation. The CoreOS team\nrecommends reading this:\n\n- https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html\n\nHere are a few resolved issues that may help you get started:\n\n- https://github.com/helm/helm/issues/1371\n- https://github.com/helm/helm/issues/966\n\n**Q: Trying to use Helm, I get the error \"lookup XXXXX on 8.8.8.8:53: no such host\"**\n\n```\nError: Error forwarding ports: error upgrading connection: dial tcp: lookup kube-4gb-lon1-02 on 8.8.8.8:53: no such host\n```\n\nA: We have seen this issue with Ubuntu and Kubeadm in multi-node clusters. The\nissue is that the nodes expect certain DNS records to be obtainable via global\nDNS. Until this is resolved upstream, you can work around the issue as\nfollows. On each of the control plane nodes:\n\n1) Add entries to `/etc/hosts`, mapping your hostnames to their public IPs\n2) Install `dnsmasq` (e.g. `apt install -y dnsmasq`)\n3) Remove the k8s api server container (kubelet will recreate it)\n4) Then `systemctl restart docker` (or reboot the node) for it to pick up the /etc/resolv.conf changes\n\nSee this issue for more information: https://github.com/helm/helm/issues/1455\n\n**Q: On GKE (Google Container Engine) I get \"No SSH tunnels currently open\"**\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nAnother variation of the error message is:\n\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n\n```\n\nA: The issue is that your local Kubernetes config file must have the correct credentials.\n\nWhen you create a cluster on GKE, it will give you credentials, including SSL\ncertificates and certificate authorities. These need to be stored in a Kubernetes\nconfig file (Default: `~/.kube/config` so that `kubectl` and `helm` can access\nthem.\n\n**Q: When I run a Helm command, I get an error about the tunnel or proxy**\n\nA: Helm uses the Kubernetes proxy service to connect to the Tiller server.\nIf the command `kubectl proxy` does not work for you, neither will Helm.\nTypically, the error is related to a missing `socat` service.\n\n**Q: Tiller crashes with a panic**\n\nWhen I run a command on Helm, Tiller crashes with an error like this:\n\n```\nTiller is listening on :44134\nProbes server is listening on :44135\nStorage driver is ConfigMap\nCannot 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\npanic: runtime error: invalid memory address or nil pointer dereference\n[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8053d5]\n\ngoroutine 77 [running]:\npanic(0x1abbfc0, 0xc42000a040)\n        /usr/local/go/src/runtime/panic.go:500 +0x1a1\nk8s.io/helm/vendor/k8s.io/kubernetes/pkg/client/unversioned.(*ConfigMaps).Get(0xc4200c6200, 0xc420536100, 0x15, 0x1ca7431, 0x6, 0xc42016b6a0)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/k8s.io/kubernetes/pkg/client/unversioned/configmap.go:58 +0x75\nk8s.io/helm/pkg/storage/driver.(*ConfigMaps).Get(0xc4201d6190, 0xc420536100, 0x15, 0xc420536100, 0x15, 0xc4205360c0)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/storage/driver/cfgmaps.go:69 +0x62\nk8s.io/helm/pkg/storage.(*Storage).Get(0xc4201d61a0, 0xc4205360c0, 0x12, 0xc400000001, 0x12, 0x0, 0xc420200070)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/storage/storage.go:38 +0x160\nk8s.io/helm/pkg/tiller.(*ReleaseServer).uniqName(0xc42002a000, 0x0, 0x0, 0xc42016b800, 0xd66a13, 0xc42055a040, 0xc420558050, 0xc420122001)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:577 +0xd7\nk8s.io/helm/pkg/tiller.(*ReleaseServer).prepareRelease(0xc42002a000, 0xc42027c1e0, 0xc42002a001, 0xc42016bad0, 0xc42016ba08)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:630 +0x71\nk8s.io/helm/pkg/tiller.(*ReleaseServer).InstallRelease(0xc42002a000, 0x7f284c434068, 0xc420250c00, 0xc42027c1e0, 0x0, 0x31a9, 0x31a9)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:604 +0x78\nk8s.io/helm/pkg/proto/hapi/services._ReleaseService_InstallRelease_Handler(0x1c51f80, 0xc42002a000, 0x7f284c434068, 0xc420250c00, 0xc42027c190, 0x0, 0x0, 0x0, 0x0, 0x0)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/proto/hapi/services/tiller.pb.go:747 +0x27d\nk8s.io/helm/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690, 0xc420166150, 0x288cbe8, 0xc420250bd0, 0x0, 0x0)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:608 +0xc50\nk8s.io/helm/vendor/google.golang.org/grpc.(*Server).handleStream(0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690, 0xc420250bd0)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:766 +0x6b0\nk8s.io/helm/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc420124710, 0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690)\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:419 +0xab\ncreated by k8s.io/helm/vendor/google.golang.org/grpc.(*Server).serveStreams.func1\n        /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:420 +0xa3\n```\n\nA: Check your security settings for Kubernetes.\n\nA panic in Tiller is almost always the result of a failure to negotiate with the\nKubernetes API server (at which point Tiller can no longer do anything useful, so\nit panics and exits).\n\nOften, this is a result of authentication failing because the Pod in which Tiller\nis running does not have the right token.\n\nTo fix this, you will need to change your Kubernetes configuration. Make sure\nthat `--service-account-private-key-file` from `controller-manager` and\n`--service-account-key-file` from apiserver point to the _same_ x509 RSA key.\n\n\n## Upgrading\n\nMy Helm used to work, then I upgrade. Now it is broken.\n\n**Q: After upgrade, I get the error \"Client version is incompatible\". What's wrong?**\n\nTiller and Helm have to negotiate a common version to make sure that they can safely\ncommunicate without breaking API assumptions. That error means that the version\ndifference is too great to safely continue. Typically, you need to upgrade\nTiller manually for this.\n\nThe [Installation Guide](install.md) has definitive information about safely\nupgrading Helm and Tiller.\n\nThe rules for version numbers are as follows:\n\n- Pre-release versions are incompatible with everything else. `Alpha.1` is incompatible with `Alpha.2`.\n- Patch revisions _are compatible_: 1.2.3 is compatible with 1.2.4\n- Minor revisions _are not compatible_: 1.2.0 is not compatible with 1.3.0,\n  though we may relax this constraint in the future.\n- Major revisions _are not compatible_: 1.0.0 is not compatible with 2.0.0.\n\n## Uninstalling\n\nI am trying to remove stuff.\n\n**Q: When I delete the Tiller deployment, how come all the releases are still there?**\n\nReleases are stored in ConfigMaps inside of the `kube-system` namespace. You will\nhave to manually delete them to get rid of the record, or use ```helm delete --purge```.\n\n**Q: I want to delete my local Helm. Where are all its files?**\n\nAlong with the `helm` binary, Helm stores some files in `$HELM_HOME`, which is\nlocated by default in `~/.helm`.\n"
  },
  {
    "path": "versioned_docs/version-2/using_helm/kubernetes_apis.md",
    "content": "---\nsidebar_position: 2\nsidebar_label: \"Deprecated Kubernetes APIs\"\n---\n# Deprecated Kubernetes APIs\n\nKubernetes is an API-driven system and the API evolves over time to reflect\nthe evolving understanding of the problem space. This is common practice\nacross systems and their APIs. An important part of evolving APIs is a good\ndeprecation policy and process to inform users of how changes to APIs are\nimplemented. In other words, consumers of your API need to know in advance and\nin what release an API will be removed or changed. This removes the element of\nsurprise and breaking changes to consumers.\n\nThe [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\ndocuments how Kubernetes handles the changes to its API versions. The policy\nfor deprecation states the timeframe that API versions will be supported following\na deprecation announcement. It is therefore important to be aware of deprecation\nannouncements and know when API versions will be removed, to help minimize the\neffect.\n\nThis 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/)\nand was advertised a few months prior to the release. These API versions would\nhave been announced for deprecation prior to this again. This shows that there\nis a good policy in place which informs consumers of API version support. \n\nHelm templates specify a [Kubernetes API group](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)\nwhen defining a Kubernetes object, similar to a Kubernetes manifest file. It is\nspecified in the `apiVersion` field of the template and it identifies the API\nversion of the Kubernetes object. This means that Helm users and chart maintainers\nneed to be aware when Kubernetes API versions have been deprecated and in what\nKubernetes version they will be removed.\n\n## Chart Maintainers\n\nYou should audit your charts checking for Kubernetes API versions that are\ndeprecated or are removed in a Kubernetes version. The API versions found as\ndue to be or that are now out of support, should be updated to the supported\nversion and a new version of the chart released. The API version is defined by\nthe `kind` and `apiVersion` fields. For example, here is a removed `Deployment`\nobject API version in Kubernetes 1.16:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Helm Users\n\nYou should audit the charts that you use (similar to [chart maintainers](#chart-maintainers))\nand identify any charts where API versions are deprecated or removed in a\nKubernetes version. For the charts identified, you need to check for the latest\nversion of the chart (which has supported API versions) or update the chart\nyourself.\n\nAdditionally, you also need to audit any charts deployed (i.e. Helm releases)\nchecking again for any deprecated or removed API versions. This can be done by\ngetting details of a release using the `helm get manifest` command.\n\nThe means for updating a Helm release to supported APIs depends on your findings\nas follows:\n\n1. If you find deprecated API versions only then:\n  - Perform a `helm upgrade` with a version of the chart with supported Kubernetes\n  API versions\n  - Add a description in the upgrade, something along the lines to not perform a\n  rollback to a Helm version prior to this current version\n2.  If you find any API version(s) that is/are removed in a Kubernetes version\nthen:\n  - If you are running a Kubernetes version where the API version(s) are still\n  available (for example, you are on Kubernetes 1.15 and found you use APIs that\n  will be removed in Kubernetes 1.16):\n    - Follow the step 1 procedure\n  - Otherwise (for example, you are already running a Kubernetes version where\n  some API versions reported by `helm get manifest` are no longer available):\n    - You need to edit the release manifest that is stored in the cluster to\n    update the API versions to supported APIs. See\n    [Updating API Versions of a Release Manifest](#updating-api-versions-of-a-release-manifest)\n    for more details\n\n> Note: In all cases of updating a Helm release with supported APIs, you should\nnever rollback the release to a version prior to the release version with the\nsupported APIs.\n\n> Recommendation: The best practice is to upgrade releases using deprecated API\nversions to supported API versions, prior to upgrading to a kubernetes cluster\nthat removes those API versions. \n\nIf you don't update a release as suggested previously, you will have an error\nsimilar to the following when trying to upgrade a release in a Kubernetes version\nwhere its API version(s) is/are removed:\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm fails in this scenario because it attempts to create a diff patch between\nthe current deployed release (which contains the Kubernetes APIs that are removed\nin this Kubernetes version) against the chart you are passing with the\nupdated/supported API versions. The underlying reason for failure is that when\nKubernetes removes an API version, the Kubernetes Go client library can no longer\nparse the deprecated objects and Helm therefore fails when calling the library.\nHelm unfortunately is unable to recover from this situation and is no longer able\nto manage such a release.\nSee [Updating API Versions of a Release Manifest](#updating-api-versions-of-a-release-manifest)\nfor more details on how to recover from this scenario.\n\n## Updating API Versions of a Release Manifest\n\nThe manifest is a property of the Helm release object which is stored in the data\nfield of a ConfigMap (default) or Secret in the cluster. The data field contains\na gzipped [protobuf object](../developers.md#grpc-and-protobuf) which is base 64\nencoded (there is an additional base 64 encoding for a Secret). There is\na Secret/ConfigMap per release version/revision in the namespace of the release.\n\nYou can use the Helm [mapkubeapis](https://github.com/hickeyma/helm-mapkubeapis)\nplugin to perform the update of a release to supported APIs. Check out the\nreadme for more details.\n\nAlternatively, you can follow these manual steps to perform an update of the API\nversions of a release manifest. Depending on your configuration you will follow\nthe steps for the ConfigMap or Secret backend.\n\n- Prerequisites:\n  - HELM_PROTOBUF_SCHEMA: [Helm protobuf schema](https://github.com/helm/helm/tree/dev-v2/_proto)\n  - PROTOBUF_SCHEMA: [Protobuf base schema](https://github.com/protocolbuffers/protobuf/tree/master/src) \n- Get the name of the ConfigMap or Secret associated with the latest deployed release:\n  - ConfigMap backend: `kubectl get configmap -l OWNER=TILLER,STATUS=DEPLOYED,NAME=<release_name> --namespace <tiller_namespace> | awk '{print $1}' | grep -v NAME`\n  - Secrets backend: `kubectl get secret -l OWNER=TILLER,STATUS=DEPLOYED,NAME=<release_name> --namespace <tiller_namespace> | awk '{print $1}' | grep -v NAME`\n- Get latest deployed release details:\n  - ConfigMap backend: `kubectl get configmap <release_configmap_name> -n <tiller_namespace> -o yaml > release.yaml`\n  - Secrets backend: `kubectl get secret <release_secret_name> -n <tiller_namespace> -o yaml > release.yaml`\n- Backup the release in case you need to restore if something goes wrong:\n  - `cp release.yaml release.bak`\n  - In case of emergency, restore: `kubectl apply -f release.bak -n <tiller_namespace>`\n- Decode the release object: \n  - 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`\n  - 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`\n- Change API versions of the manifests. Can use any tool (e.g. editor) to make\nthe changes. This is in the `manifest` field of your decoded release\nobject (`release.data.decoded`)\n- Encode the release object:\n  - 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`\n  - 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`\n- Replace `data.release` property value in the deployed release file (`release.yaml`)\nwith the new encoded release object\n- Apply file to namespace: `kubectl apply -f release.yaml -n <tiller_namespace>`\n- Perform a `helm upgrade` with a version of the chart with supported Kubernetes\nAPI versions\n- Add a description in the upgrade, something along the lines to not perform a\nrollback to a Helm version prior to this current version\n\n> Note: Ensure to use the `protobuf schema` for the deployed Tiller version, otherwise the decoding might fail\n"
  },
  {
    "path": "versioned_docs/version-2/using_helm/kubernetes_distros.md",
    "content": "---\nsidebar_position: 3\nsidebar_label: \"Kubernetes Distro Notes\"\n---\n# Kubernetes Distribution Guide\n\nThis document captures information about using Helm in specific Kubernetes\nenvironments.\n\nWe are trying to add more details to this document. Please contribute via Pull\nRequests if you can.\n\n## MicroK8s\n\nHelm can be enabled in [MicroK8s](https://microk8s.io) using the command: `microk8s.enable helm`\n\n## MiniKube\n\nHelm is tested and known to work with [minikube](https://github.com/kubernetes/minikube).\nIt requires no additional configuration.\n\n## `scripts/local-cluster` and Hyperkube\n\nHyperkube configured via `scripts/local-cluster.sh` is known to work. For raw\nHyperkube you may need to do some manual configuration.\n\n## GKE\n\nGoogle'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.\n\nSee [Tiller and role-based access control](https://docs.helm.sh/using_helm/#role-based-access-control) for more information.\n\n## AKS\n\nHelm 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).\n\n## IKS\n\nHelm 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).\n\n## Ubuntu with 'kubeadm'\n\nKubernetes bootstrapped with `kubeadm` is known to work on the following Linux\ndistributions:\n\n- Arch Linux\n- Ubuntu 16.04\n- Fedora release 25\n\nSome versions of Helm (v2.0.0-beta2) require you to `export KUBECONFIG=/etc/kubernetes/admin.conf`\nor create a `~/.kube/config`.\n\n## Container Linux by CoreOS\n\nHelm 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.\n\n## Openshift\n\nHelm 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.\n\n## Platform9\n\nHelm 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).\n\n## DC/OS\n\nHelm (both client and server) has been tested and is working on Mesospheres DC/OS 1.11 Kubernetes platform, and requires\nno additional configuration.\n\n## Kubermatic\n\nHelm 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.\n\n## KubeOne\n\nHelm works in clusters that are set up by KubeOne without caveats.\n"
  },
  {
    "path": "versioned_docs/version-2/using_helm/plugins.md",
    "content": "---\nsidebar_position: 5\nsidebar_label: \"Plugins\"\n---\n# The Helm Plugins Guide\n\nHelm 2.1.0 introduced the concept of a client-side Helm _plugin_. A plugin is a\ntool that can be accessed through the `helm` CLI, but which is not part of the\nbuilt-in Helm codebase.\n\nExisting 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).\n\nThis guide explains how to use and create plugins.\n\n## An Overview\n\nHelm plugins are add-on tools that integrate seamlessly with Helm. They provide\na way to extend the core feature set of Helm, but without requiring every new\nfeature to be written in Go and added to the core tool.\n\nHelm plugins have the following features:\n\n- They can be added and removed from a Helm installation without impacting the\n  core Helm tool.\n- They can be written in any programming language.\n- They integrate with Helm, and will show up in `helm help` and other places.\n\nHelm plugins live in `$(helm home)/plugins`.\n\nThe Helm plugin model is partially modeled on Git's plugin model. To that end,\nyou may sometimes hear `helm` referred to as the _porcelain_ layer, with\nplugins being the _plumbing_. This is a shorthand way of suggesting that\nHelm provides the user experience and top level processing logic, while the\nplugins do the \"detail work\" of performing a desired action.\n\n## Installing a Plugin\n\nPlugins are installed using the `$ helm plugin install <path|url>` 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`\n\n```console\n$ helm plugin install https://github.com/technosophos/helm-template\n```\n\nIf you have a plugin tar distribution, simply untar the plugin into the\n`$(helm home)/plugins` directory.\n\nYou can also install tarball plugins directly from url by issuing `helm plugin install http://domain/path/to/plugin.tar.gz`\n\n## Building Plugins\n\nIn many ways, a plugin is similar to a chart. Each plugin has a top-level\ndirectory, and then a `plugin.yaml` file.\n\n```\n$(helm home)/plugins/\n  |- keybase/\n      |\n      |- plugin.yaml\n      |- keybase.sh\n\n```\n\nIn the example above, the `keybase` plugin is contained inside of a directory\nnamed `keybase`. It has two files: `plugin.yaml` (required) and an executable\nscript, `keybase.sh` (optional).\n\nThe core of a plugin is a simple YAML file named `plugin.yaml`.\nHere is a plugin YAML for a plugin that adds support for Keybase operations:\n\n```\nname: \"keybase\"\nversion: \"0.1.0\"\nusage: \"Integrate Keybase.io tools with Helm\"\ndescription: |-\n  This plugin provides Keybase services to Helm.\nignoreFlags: false\nuseTunnel: false\ncommand: \"$HELM_PLUGIN_DIR/keybase.sh\"\n```\n\nThe `name` is the name of the plugin. When Helm executes it plugin, this is the\nname it will use (e.g. `helm NAME` will invoke this plugin).\n\n_`name` should match the directory name._ In our example above, that means the\nplugin with `name: keybase` should be contained in a directory named `keybase`.\n\nRestrictions on `name`:\n\n- `name` cannot duplicate one of the existing `helm` top-level commands.\n- `name` must be restricted to the characters ASCII a-z, A-Z, 0-9, `_` and `-`.\n\n`version` is the SemVer 2 version of the plugin.\n`usage` and `description` are both used to generate the help text of a command.\n\nThe `ignoreFlags` switch tells Helm to _not_ pass flags to the plugin. So if a\nplugin is called with `helm myplugin --foo` and `ignoreFlags: true`, then `--foo`\nis silently discarded.\n\nThe `useTunnel` switch indicates that the plugin needs a tunnel to Tiller. This\nshould be set to `true` _anytime a plugin talks to Tiller_. It will cause Helm\nto open a tunnel, and then set `$TILLER_HOST` to the right local address for that\ntunnel. But don't worry: if Helm detects that a tunnel is not necessary because\nTiller is running locally, it will not create the tunnel.\n\nFinally, and most importantly, `command` is the command that this plugin will\nexecute when it is called. Environment variables are interpolated before the plugin\nis executed. The pattern above illustrates the preferred way to indicate where\nthe plugin program lives.\n\nThere are some strategies for working with plugin commands:\n\n- If a plugin includes an executable, the executable for a `command:` should be\n  packaged in the plugin directory.\n- The `command:` line will have any environment variables expanded before\n  execution. `$HELM_PLUGIN_DIR` will point to the plugin directory.\n- The command itself is not executed in a shell. So you can't oneline a shell script.\n- Helm injects lots of configuration into environment variables. Take a look at\n  the environment to see what information is available.\n- Helm makes no assumptions about the language of the plugin. You can write it\n  in whatever you prefer.\n- Commands are responsible for implementing specific help text for `-h` and `--help`.\n  Helm will use `usage` and `description` for `helm help` and `helm help myplugin`,\n  but will not handle `helm myplugin --help`.\n\n## Downloader Plugins\nBy default, Helm is able to fetch Charts using HTTP/S. As of Helm 2.4.0, plugins\ncan have a special capability to download Charts from arbitrary sources.\n\nPlugins shall declare this special capability in the `plugin.yaml` file (top level):\n\n```\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nIf such plugin is installed, Helm can interact with the repository using the specified\nprotocol scheme by invoking the `command`. The special repository shall be added\nsimilarly to the regular ones: `helm repo add favorite myprotocol://example.com/`\nThe rules for the special repos are the same to the regular ones: Helm must be able\nto download the `index.yaml` file in order to discover and cache the list of\navailable Charts.\n\nThe defined command will be invoked with the following scheme:\n`command certFile keyFile caFile full-URL`. The SSL credentials are coming from the\nrepo definition, stored in `$HELM_HOME/repository/repositories.yaml`. Downloader\nplugin is expected to dump the raw content to stdout and report errors on stderr.\n\nThe downloader command also supports sub-commands or arguments, allowing you to specify\nfor example `bin/mydownloader subcommand -d` in the `plugin.yaml`. This is useful\nif you want to use the same executable for the main plugin command and the downloader\ncommand, but with a different sub-command for each.\n\n## Environment Variables\n\nWhen Helm executes a plugin, it passes the outer environment to the plugin, and\nalso injects some additional environment variables.\n\nVariables like `KUBECONFIG` are set for the plugin if they are set in the\nouter environment.\n\nThe following variables are guaranteed to be set:\n\n- `HELM_PLUGIN`: The path to the plugins directory\n- `HELM_PLUGIN_NAME`: The name of the plugin, as invoked by `helm`. So\n  `helm myplug` will have the short name `myplug`.\n- `HELM_PLUGIN_DIR`: The directory that contains the plugin.\n- `HELM_BIN`: The path to the `helm` command (as executed by the user).\n- `HELM_HOME`: The path to the Helm home.\n- `HELM_PATH_*`: Paths to important Helm files and directories are stored in\n  environment variables prefixed by `HELM_PATH`.\n- `TILLER_HOST`: The `domain:port` to Tiller. If a tunnel is created, this\n  will point to the local endpoint for the tunnel. Otherwise, it will point\n  to `$HELM_HOST`, `--host`, or the default host (according to Helm's rules of\n  precedence).\n\nWhile `HELM_HOST` _may_ be set, there is no guarantee that it will point to the\ncorrect Tiller instance. This is done to allow plugin developer to access\n`HELM_HOST` in its raw state when the plugin itself needs to manually configure\na connection.\n\n## A Note on `useTunnel`\n\nIf a plugin specifies `useTunnel: true`, Helm will do the following (in order):\n\n1. Parse global flags and the environment\n2. Create the tunnel\n3. Set `TILLER_HOST`\n4. Execute the plugin\n5. Close the tunnel\n\nThe tunnel is removed as soon as the `command` returns. So, for example, a\ncommand cannot background a process and assume that process will be able\nto use the tunnel.\n\n## A Note on Flag Parsing\n\nWhen executing a plugin, Helm will parse global flags for its own use. Some of\nthese flags are _not_ passed on to the plugin.\n\n- `--debug`: If this is specified, `$HELM_DEBUG` is set to `1`\n- `--home`: This is converted to `$HELM_HOME`\n- `--host`: This is converted to `$HELM_HOST`\n- `--kube-context`: This is simply dropped. If your plugin uses `useTunnel`, this\n  is used to set up the tunnel for you.\n\nPlugins _should_ display help text and then exit for `-h` and `--help`. In all\nother cases, plugins may use flags as appropriate.\n"
  },
  {
    "path": "versioned_docs/version-2/using_helm/rbac.md",
    "content": "---\nsidebar_position: 6\nsidebar_label: \"Role-Based Access Control\"\n---\n# Role-based Access Control\n\nIn 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).\n\nBitnami 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.\n\nThis 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.\n\n## Tiller and Role-based Access Control\n\nYou can add a service account to Tiller using the `--service-account <NAME>` 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.\n\nOnce 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 <NAME>`\n\n### Example: Service account with cluster-admin role\n\nIn `rbac-config.yaml`:\n\n```yaml\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: tiller\n  namespace: kube-system\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n  name: tiller\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: ClusterRole\n  name: cluster-admin\nsubjects:\n  - kind: ServiceAccount\n    name: tiller\n    namespace: kube-system\n```\n\n_Note: The cluster-admin role is created by default in a Kubernetes cluster, so you don't have to define it explicitly._\n\n```console\n$ kubectl create -f rbac-config.yaml\nserviceaccount \"tiller\" created\nclusterrolebinding \"tiller\" created\n$ helm init --service-account tiller --history-max 200\n```\n\n### Example: Deploy Tiller in a namespace, restricted to deploying resources only in that namespace\n\nIn 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.\n\n```console\n$ kubectl create namespace tiller-world\nnamespace \"tiller-world\" created\n$ kubectl create serviceaccount tiller --namespace tiller-world\nserviceaccount \"tiller\" created\n```\n\nDefine a Role that allows Tiller to manage all resources in `tiller-world` like in `role-tiller.yaml`:\n\n```yaml\nkind: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n  name: tiller-manager\n  namespace: tiller-world\nrules:\n- apiGroups: [\"\", \"batch\", \"extensions\", \"apps\"]\n  resources: [\"*\"]\n  verbs: [\"*\"]\n```\n\n```console\n$ kubectl create -f role-tiller.yaml\nrole \"tiller-manager\" created\n```\n\nIn `rolebinding-tiller.yaml`,\n\n```yaml\nkind: RoleBinding\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n  name: tiller-binding\n  namespace: tiller-world\nsubjects:\n- kind: ServiceAccount\n  name: tiller\n  namespace: tiller-world\nroleRef:\n  kind: Role\n  name: tiller-manager\n  apiGroup: rbac.authorization.k8s.io\n```\n\n```console\n$ kubectl create -f rolebinding-tiller.yaml\nrolebinding \"tiller-binding\" created\n```\n\nAfterwards you can run `helm init` to install Tiller in the `tiller-world` namespace.\n\n```console\n$ helm init --service-account tiller --tiller-namespace tiller-world\n$HELM_HOME has been configured at /Users/awesome-user/.helm.\n\nTiller (the Helm server side component) has been installed into your Kubernetes Cluster.\n\n$ helm install stable/lamp --tiller-namespace tiller-world --namespace tiller-world\nNAME:   wayfaring-yak\nLAST DEPLOYED: Mon Aug  7 16:00:16 2017\nNAMESPACE: tiller-world\nSTATUS: DEPLOYED\n\nRESOURCES:\n==> v1/Pod\nNAME                  READY  STATUS             RESTARTS  AGE\nwayfaring-yak-alpine  0/1    ContainerCreating  0         0s\n```\n\n### Example: Deploy Tiller in a namespace, restricted to deploying resources in another namespace\n\nIn 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!\n\nFor example, let's install Tiller in the namespace `myorg-system` and allow Tiller to deploy resources in the namespace `myorg-users`.\n\n```console\n$ kubectl create namespace myorg-system\nnamespace \"myorg-system\" created\n$ kubectl create serviceaccount tiller --namespace myorg-system\nserviceaccount \"tiller\" created\n```\n\nDefine a Role that allows Tiller to manage all resources in `myorg-users` like in `role-tiller.yaml`:\n\n```yaml\nkind: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n  name: tiller-manager\n  namespace: myorg-users\nrules:\n- apiGroups: [\"\", \"batch\", \"extensions\", \"apps\"]\n  resources: [\"*\"]\n  verbs: [\"*\"]\n```\n\n```console\n$ kubectl create -f role-tiller.yaml\nrole \"tiller-manager\" created\n```\n\nBind the service account to that role. In `rolebinding-tiller.yaml`,\n\n```yaml\nkind: RoleBinding\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n  name: tiller-binding\n  namespace: myorg-users\nsubjects:\n- kind: ServiceAccount\n  name: tiller\n  namespace: myorg-system\nroleRef:\n  kind: Role\n  name: tiller-manager\n  apiGroup: rbac.authorization.k8s.io\n```\n\n```console\n$ kubectl create -f rolebinding-tiller.yaml\nrolebinding \"tiller-binding\" created\n```\n\nWe'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`:\n\n```yaml\nkind: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n  namespace: myorg-system\n  name: tiller-manager\nrules:\n- apiGroups: [\"\", \"extensions\", \"apps\"]\n  resources: [\"configmaps\"]\n  verbs: [\"*\"]\n```\n\n```console\n$ kubectl create -f role-tiller-myorg-system.yaml\nrole \"tiller-manager\" created\n```\n\nAnd the respective role binding. In `rolebinding-tiller-myorg-system.yaml`:\n\n```yaml\nkind: RoleBinding\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n  name: tiller-binding\n  namespace: myorg-system\nsubjects:\n- kind: ServiceAccount\n  name: tiller\n  namespace: myorg-system\nroleRef:\n  kind: Role\n  name: tiller-manager\n  apiGroup: rbac.authorization.k8s.io\n```\n\n```console\n$ kubectl create -f rolebinding-tiller-myorg-system.yaml\nrolebinding \"tiller-binding\" created\n```\n\n## Helm and Role-based Access Control\n\nWhen 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).\n\n### Example: Deploy Helm in a namespace, talking to Tiller in another namespace\n\nIn 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.\n\nIn `helm-user.yaml`:\n\n```yaml\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: helm\n  namespace: helm-world\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n  name: tiller-user\n  namespace: tiller-world\nrules:\n- apiGroups:\n  - \"\"\n  resources:\n  - pods/portforward\n  verbs:\n  - create\n- apiGroups:\n  - \"\"\n  resources:\n  - pods\n  verbs:\n  - list\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: tiller-user-binding\n  namespace: tiller-world\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: tiller-user\nsubjects:\n- kind: ServiceAccount\n  name: helm\n  namespace: helm-world\n```\n\n```console\n$ kubectl create -f helm-user.yaml\nserviceaccount \"helm\" created\nrole \"tiller-user\" created\nrolebinding \"tiller-user-binding\" created\n```\n"
  },
  {
    "path": "versioned_docs/version-2/using_helm/securing_installation.md",
    "content": "---\nsidebar_position: 8\nsidebar_label: \"Securing Helm\"\n---\n# Securing your Helm Installation\n\nHelm 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.\n\nThis 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.\n\n## Who Needs Security Configurations?\n\nFor 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.\n\n- 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.\n- Clusters that are for many people to use -- _multitenant_ clusters -- as a shared environment\n- Clusters that have access to or use high-value data or networks of any type\n\nOften, 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.\n\nTo configure your installation properly for your environment, you must:\n\n- Understand the security context of your cluster\n- Choose the Best Practices you should apply to your helm installation\n\nThe following assumes you have a Kubernetes configuration file (a _kubeconfig_ file) or one was given to you to access a cluster.\n\n## Understanding the Security Context of your Cluster\n\n`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.\n\nThere are four main areas to consider when securing a tiller installation:\n\n1. Role-based access control, or RBAC\n2. Tiller's gRPC endpoint and its usage by Helm\n3. Tiller release information\n4. Helm charts\n\n### RBAC\n\nRecent 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.\n\nHelm 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.\n\nSpecific 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).\n\n#### Tiller and User Permissions\n\nTiller 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.\n\nTo 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.\n\nThis 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.\n\n### The Tiller gRPC Endpoint\n\nIn 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.)\n\nThe following two sub-sections describe options of how to setup Tiller so there isn't an unauthenticated endpoint (i.e. gRPC) in your cluster.\n\n#### Enabling TLS\n\n(Note that out of the two options, this is the recommended one for Helm 2.)\n\nShared 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.\n\nFor 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).\n\nWhen 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.\n\n#### Running Tiller Locally\n\nContrary 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).\n\nSteps:\n\n- 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`.\n- \"Server\": Run `tiller --storage=secret`. (Note that `tiller` has a default value of \":44134\" for the `--listen` argument.)\n- 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.\n\n### Tiller's Release Information\n\nFor historical reasons, Tiller stores its release information in ConfigMaps. We suggest changing the default to Secrets.\n\nSecrets 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.\n\nEnabling 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.\n\n### Thinking about Charts\n\nBecause 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.\n\nAs 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.\n\nOnce vetted, you can use Helm's provenance tools to [ensure the provenance and integrity of charts](../developing_charts/provenance.md) that you use.\n\n### gRPC Tools and Secured Tiller Configurations\n\nMany 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.\n\n## Best Practices for Securing Helm and Tiller\n\nThe following guidelines reiterate the Best Practices for securing Helm and Tiller and using them correctly.\n\n1. Create a cluster with RBAC enabled\n2. Configure each Tiller gRPC endpoint to use a separate TLS certificate\n3. Release information should be a Kubernetes Secret\n4. Install one Tiller per user, team, or other organizational entity with the `--service-account` flag, Roles, and RoleBindings\n5. Use the `--tiller-tls-verify` option with `helm init` and the `--tls` flag with other Helm commands to enforce verification\n\nIf these steps are followed, an example `helm init` command might look something like this:\n```bash\n$ helm init \\\n--override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}' \\\n--tiller-tls \\\n--tiller-tls-verify \\\n--tiller-tls-cert=cert.pem \\\n--tiller-tls-key=key.pem \\\n--tls-ca-cert=ca.pem \\\n--service-account=accountname\n```\n\nThis 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.\n"
  },
  {
    "path": "versioned_docs/version-2/using_helm/tiller_ssl.md",
    "content": "---\nsidebar_position: 7\nsidebar_label: \"TLS/SSL for Helm and Tiller\"\n---\n# Using SSL Between Helm and Tiller\n\nThis document explains how to create strong SSL/TLS connections between Helm and\nTiller. The emphasis here is on creating an internal CA, and using both the\ncryptographic and identity functions of SSL.\n\n> Support for TLS-based auth was introduced in Helm 2.3.0\n\nConfiguring SSL is considered an advanced topic, and knowledge of Helm and Tiller\nis assumed.\n\n## Overview\n\nThe Tiller authentication model uses client-side SSL certificates. Tiller itself\nverifies these certificates using a certificate authority. Likewise, the client\nalso verifies Tiller's identity by certificate authority.\n\nThere are numerous possible configurations for setting up certificates and authorities,\nbut the method we cover here will work for most situations.\n\n> As of Helm 2.7.2, Tiller _requires_ that the client certificate be validated\n> by its CA. In prior versions, Tiller used a weaker validation strategy that\n> allowed self-signed certificates.\n\nIn this guide, we will show how to:\n\n- Create a private CA that is used to issue certificates for Tiller clients and\n  servers.\n- Create a certificate for Tiller\n- Create a certificate for the Helm client\n- Create a Tiller instance that uses the certificate\n- Configure the Helm client to use the CA and client-side certificate\n\nBy the end of this guide, you should have a Tiller instance running that will\nonly accept connections from clients who can be authenticated by SSL certificate.\n\n## Generating Certificate Authorities and Certificates\n\nOne way to generate SSL CAs is via the `openssl` command line tool. There are many\nguides and best practices documents available online. This explanation is focused\non getting ready within a small amount of time. For production configurations,\nwe urge readers to read [the official documentation](https://www.openssl.org) and\nconsult other resources.\n\nThere 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/).\n\n### Generate a Certificate Authority\n\nThe simplest way to generate a certificate authority is to run two commands:\n\n```console\n$ openssl genrsa -out ./ca.key.pem 4096\n$ openssl req -key ca.key.pem -new -x509 -days 7300 -sha256 -out ca.cert.pem -extensions v3_ca\nEnter pass phrase for ca.key.pem:\nYou are about to be asked to enter information that will be incorporated\ninto your certificate request.\nWhat you are about to enter is what is called a Distinguished Name or a DN.\nThere are quite a few fields but you can leave some blank\nFor some fields there will be a default value,\nIf you enter '.', the field will be left blank.\n-----\nCountry Name (2 letter code) [AU]:US\nState or Province Name (full name) [Some-State]:CO\nLocality Name (eg, city) []:Boulder\nOrganization Name (eg, company) [Internet Widgits Pty Ltd]:tiller\nOrganizational Unit Name (eg, section) []:\nCommon Name (e.g. server FQDN or YOUR name) []:tiller\nEmail Address []:tiller@example.com\n```\n\nNote that the data input above is _sample data_. You should customize to your own\nspecifications.\n\nThe above will generate both a secret key and a CA. Note that these two files are\nvery important. The key in particular should be handled with particular care.\n\nOften, you will want to generate an intermediate signing key. For the sake of brevity,\nwe will be signing keys with our root CA.\n\n### Generating Certificates\n\nWe will be generating two certificates, each representing a type of certificate:\n\n- One certificate is for Tiller. You will want one of these _per tiller host_ that\n  you run.\n- One certificate is for the user. You will want one of these _per helm user_.\n\nSince the commands to generate these are the same, we'll be creating both at the\nsame time. The names will indicate their target.\n\nFirst, the Tiller key:\n\n```console\n$ openssl genrsa -out ./tiller.key.pem 4096\nGenerating RSA private key, 4096 bit long modulus\n..........................................................................................................................................................................................................................................................................................................................++\n............................................................................++\ne is 65537 (0x10001)\nEnter pass phrase for ./tiller.key.pem:\nVerifying - Enter pass phrase for ./tiller.key.pem:\n```\n\nNext, generate the Helm client's key:\n\n```console\n$ openssl genrsa -out ./helm.key.pem 4096\nGenerating RSA private key, 4096 bit long modulus\n.....++\n......................................................................................................................................................................................++\ne is 65537 (0x10001)\nEnter pass phrase for ./helm.key.pem:\nVerifying - Enter pass phrase for ./helm.key.pem:\n```\n\nAgain, for production use you will generate one client certificate for each user.\n\nNext we need to create certificates from these keys. For each certificate, this is\na two-step process of creating a CSR, and then creating the certificate.\n\n```console\n$ openssl req -key tiller.key.pem -new -sha256 -out tiller.csr.pem\nEnter pass phrase for tiller.key.pem:\nYou are about to be asked to enter information that will be incorporated\ninto your certificate request.\nWhat you are about to enter is what is called a Distinguished Name or a DN.\nThere are quite a few fields but you can leave some blank\nFor some fields there will be a default value,\nIf you enter '.', the field will be left blank.\n-----\nCountry Name (2 letter code) [AU]:US\nState or Province Name (full name) [Some-State]:CO\nLocality Name (eg, city) []:Boulder\nOrganization Name (eg, company) [Internet Widgits Pty Ltd]:Tiller Server\nOrganizational Unit Name (eg, section) []:\nCommon Name (e.g. server FQDN or YOUR name) []:tiller-server\nEmail Address []:\n\nPlease enter the following 'extra' attributes\nto be sent with your certificate request\nA challenge password []:\nAn optional company name []:\n```\n\nAnd we repeat this step for the Helm client certificate:\n\n```console\n$ openssl req -key helm.key.pem -new -sha256 -out helm.csr.pem\n# Answer the questions with your client user's info\n```\n\n(In rare cases, we've had to add the `-nodes` flag when generating the request.)\n\nNow we sign each of these CSRs with the CA certificate we created (adjust the days parameter to suit your requirements):\n\n```console\n$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365\nSignature ok\nsubject=/C=US/ST=CO/L=Boulder/O=Tiller Server/CN=tiller-server\nGetting CA Private Key\nEnter pass phrase for ca.key.pem:\n```\n\nAnd again for the client certificate:\n\n```console\n$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in helm.csr.pem -out helm.cert.pem  -days 365\n```\n\nAt this point, the important files for us are these:\n\n```\n# The CA. Make sure the key is kept secret.\nca.cert.pem\nca.key.pem\n# The Helm client files\nhelm.cert.pem\nhelm.key.pem\n# The Tiller server files.\ntiller.cert.pem\ntiller.key.pem\n```\n\nNow we're ready to move on to the next steps.\n\n## Creating a Custom Tiller Installation\n\nHelm includes full support for creating a deployment configured for SSL. By specifying\na few flags, the `helm init` command can create a new Tiller installation complete\nwith all of our SSL configuration.\n\nTo take a look at what this will generate, run this command:\n\n```console\n$ 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\n```\n\nThe output will show you a Deployment, a Secret, and a Service. Your SSL information\nwill be preloaded into the Secret, which the Deployment will mount to pods as they\nstart up.\n\nIf you want to customize the manifest, you can save that output to a file and then\nuse `kubectl create` to load it into your cluster.\n\n> We strongly recommend enabling RBAC on your cluster and adding [service accounts](rbac.md)\n> with RBAC.\n\nOtherwise, you can remove the `--dry-run` and `--debug` flags. We also recommend\nputting Tiller in a non-system namespace (`--tiller-namespace=something`) and enable\na service account (`--service-account=somename`). But for this example we will stay\nwith the basics:\n\n```console\n$ 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\n```\n\nIn a minute or two it should be ready. We can check Tiller like this:\n\n```console\n$ kubectl -n kube-system get deployment\nNAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE\n... other stuff\ntiller-deploy   1         1         1            1           2m\n```\n\nIf there is a problem, you may want to use `kubectl get pods -n kube-system` to\nfind out what went wrong. With the SSL/TLS support, the most common problems all\nhave to do with improperly generated TLS certificates or accidentally swapping the\ncert and the key.\n\nAt this point, you should get a _failure_ when you run basic Helm commands:\n\n```console\n$ helm ls\nError: transport is closing\n```\n\nThis is because your Helm client does not have the correct certificate to authenticate\nto Tiller.\n\n## Configuring the Helm Client\n\nThe Tiller server is now running with TLS protection. It's time to configure the\nHelm client to also perform TLS operations.\n\nFor a quick test, we can specify our configuration manually. We'll run a normal\nHelm command (`helm ls`), but with SSL/TLS enabled.\n\n```console\nhelm ls --tls --tls-ca-cert ca.cert.pem --tls-cert helm.cert.pem --tls-key helm.key.pem\n```\n\nThis configuration sends our client-side certificate to establish identity, uses\nthe client key for encryption, and uses the CA certificate to validate the remote\nTiller's identity.\n\nTyping a line that is cumbersome, though. The shortcut is to move the key,\ncert, and CA into `$HELM_HOME`:\n\n```console\n$ cp ca.cert.pem $(helm home)/ca.pem\n$ cp helm.cert.pem $(helm home)/cert.pem\n$ cp helm.key.pem $(helm home)/key.pem\n```\n\nWith this, you can simply run `helm ls --tls` to enable TLS.\n\n### Troubleshooting\n\n*Running a command, I get `Error: transport is closing`*\n\nThis is almost always due to a configuration error in which the client is missing\na certificate (`--tls-cert`) or the certificate is bad.\n\n*I'm using a certificate, but get `Error: remote error: tls: bad certificate`*\n\nThis means that Tiller's CA cannot verify your certificate. In the examples above,\nwe used a single CA to generate both the client and server certificates. In these\nexamples, the CA has _signed_ the client's certificate. We then load that CA\nup to Tiller. So when the client certificate is sent to the server, Tiller\nchecks the client certificate against the CA.\n\n*If I use `--tls-verify` on the client, I get `Error: x509: certificate is valid for tiller-server, not localhost`*\n\nIf you plan to use `--tls-verify` on the client, you will need to make sure that\nthe host name that Helm connects to matches the host name on the certificate. In\nsome cases this is awkward, since Helm will connect over localhost, or the FQDN is\nnot available for public resolution.\n\n*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`*\n\nBy default, the Helm client connects to Tiller via tunnel (i.e. kube proxy) at 127.0.0.1. During the TLS handshake,\na target, usually provided as a hostname (e.g. example.com), is checked against the subject and subject alternative\nnames of the certificate (i.e. hostname verification). However, because of the tunnel, the target is an IP address.\nTherefore, to validate the certificate, the IP address 127.0.0.1 must be listed as an IP subject alternative name\n(IP SAN) in the Tiller certificate.\n\nFor example, to list 127.0.0.1 as an IP SAN when generating the Tiller certificate:\n\n```console\n$ echo subjectAltName=IP:127.0.0.1 > extfile.cnf\n$ 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\n```\n\nAlternatively, you can override the expected hostname of the tiller certificate using the `--tls-hostname` flag.\n\n*If I use `--tls-verify` on the client, I get `Error: x509: certificate has expired or is not yet valid`*\n\nYour 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)\n\nIf your tiller certificate has expired, you'll need to sign a new certificate, base64 encode it and update the Tiller Secret:\n`kubectl edit secret tiller-secret`\n\n## References\n\n- https://github.com/denji/golang-tls  \n- https://www.openssl.org/docs/\n- https://jamielinux.com/docs/openssl-certificate-authority/sign-server-and-client-certificates.html\n"
  },
  {
    "path": "versioned_docs/version-2/using_helm/using_helm.md",
    "content": "---\nsidebar_position: 3\nsidebar_label: \"Using Helm\"\n# This is the index/landing page for this section\n---\n# Quickstart Guide\n\nThis guide covers how you can quickly get started using Helm.\n\n## Prerequisites\n\nThe following prerequisites are required for a successful and properly secured use of Helm.\n\n1. A Kubernetes cluster\n2. Deciding what security configurations to apply to your installation, if any\n3. Installing and configuring Helm and Tiller, the cluster-side service.\n\n\n### Install Kubernetes or have access to a cluster\n- 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.\n- You should also have a local configured copy of `kubectl`.\n\nNOTE: Kubernetes versions prior to 1.6 have limited or no support for role-based access controls (RBAC).\n\nHelm will figure out where to install Tiller by reading your Kubernetes\nconfiguration file (usually `$HOME/.kube/config`). This is the same file\nthat `kubectl` uses.\n\nTo find out which cluster Tiller would install to, you can run\n`kubectl config current-context` or `kubectl cluster-info`.\n\n```console\n$ kubectl config current-context\nmy-cluster\n```\n\n### Understand your Security Context\n\nAs with all powerful tools, ensure you are installing it correctly for your scenario.\n\nIf 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).\n\nHowever, 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)\n\nIf your cluster has Role-Based Access Control (RBAC) enabled, you may want\nto [configure a service account and rules](rbac.md) before proceeding.\n\n## Install Helm\n\nDownload a binary release of the Helm client. You can use tools like\n`homebrew`, or look at [the official releases page](https://github.com/helm/helm/releases).\n\nFor more details, or for other options, see [the installation\nguide](install.md).\n\n## Initialize Helm and Install Tiller\n\nOnce you have Helm ready, you can initialize the local CLI and also\ninstall Tiller into your Kubernetes cluster in one step:\n\n```console\n$ helm init --history-max 200\n```\n\n**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.\n\nThis will install Tiller into the Kubernetes cluster you saw with\n`kubectl config current-context`.\n\n**TIP:** Want to install into a different cluster? Use the\n`--kube-context` flag.\n\n**TIP:** When you want to upgrade Tiller, just run `helm init --upgrade`.\n\nBy default, when Tiller is installed, it does not have authentication enabled.\nTo learn more about configuring strong TLS authentication for Tiller, consult\n[the Tiller TLS guide](tiller_ssl.md).\n\n## Install an Example Chart\n\nTo install a chart, you can run the `helm install` command. Helm has\nseveral ways to find and install a chart, but the easiest is to use one\nof the official `stable` charts.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install stable/mysql\nNAME:   wintering-rodent\nLAST DEPLOYED: Thu Oct 18 14:21:18 2018\nNAMESPACE: default\nSTATUS: DEPLOYED\n\nRESOURCES:\n==> v1/Secret\nNAME                    AGE\nwintering-rodent-mysql  0s\n\n==> v1/ConfigMap\nwintering-rodent-mysql-test  0s\n\n==> v1/PersistentVolumeClaim\nwintering-rodent-mysql  0s\n\n==> v1/Service\nwintering-rodent-mysql  0s\n\n==> v1beta1/Deployment\nwintering-rodent-mysql  0s\n\n==> v1/Pod(related)\n\nNAME                                    READY  STATUS   RESTARTS  AGE\nwintering-rodent-mysql-6986fd6fb-988x7  0/1    Pending  0         0s\n\n\nNOTES:\nMySQL can be accessed via port 3306 on the following DNS name from within your cluster:\nwintering-rodent-mysql.default.svc.cluster.local\n\nTo get your root password run:\n\n    MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default wintering-rodent-mysql -o jsonpath=\"{.data.mysql-root-password}\" | base64 --decode; echo)\n\nTo connect to your database:\n\n1. Run an Ubuntu pod that you can use as a client:\n\n    kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il\n\n2. Install the mysql client:\n\n    $ apt-get update && apt-get install mysql-client -y\n\n3. Connect using the mysql cli, then provide your password:\n    $ mysql -h wintering-rodent-mysql -p\n\nTo connect to your database directly from outside the K8s cluster:\n    MYSQL_HOST=127.0.0.1\n    MYSQL_PORT=3306\n\n    # Execute the following command to route the connection:\n    kubectl port-forward svc/wintering-rodent-mysql 3306\n\n    mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD}\n\n```\n\nIn the example above, the `stable/mysql` chart was released, and the name of\nour new release is `wintering-rodent`. You get a simple idea of the\nfeatures of this MySQL chart by running `helm inspect stable/mysql`.\n\nWhenever you install a chart, a new release is created. So one chart can\nbe installed multiple times into the same cluster. And each can be\nindependently managed and upgraded.\n\nThe `helm install` command is a very powerful command with many\ncapabilities. To learn more about it, check out the [Using Helm\nGuide](using_helm.md)\n\n## Learn About Releases\n\nIt's easy to see what has been released using Helm:\n\n```console\n$ helm ls\nNAME            \tREVISION\tUPDATED                 \tSTATUS  \tCHART       \tAPP VERSION\tNAMESPACE\nwintering-rodent\t1       \tThu Oct 18 15:06:58 2018\tDEPLOYED\tmysql-0.10.1\t5.7.14     \tdefault\n```\n\nThe `helm list` function will show you a list of all deployed releases.\n\n## Uninstall a Release\n\nTo uninstall a release, use the `helm delete` command:\n\n```console\n$ helm delete wintering-rodent\nrelease \"wintering-rodent\" deleted\n```\n\nThis will uninstall `wintering-rodent` from Kubernetes, but you will\nstill be able to request information about that release:\n\n```console\n$ helm status wintering-rodent\nLAST DEPLOYED: Thu Oct 18 14:21:18 2018\nNAMESPACE: default\nSTATUS: DELETED\n\nNOTES:\nMySQL can be accessed via port 3306 on the following DNS name from within your cluster:\nwintering-rodent-mysql.default.svc.cluster.local\n\nTo get your root password run:\n\n    MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default wintering-rodent-mysql -o jsonpath=\"{.data.mysql-root-password}\" | base64 --decode; echo)\n\nTo connect to your database:\n\n1. Run an Ubuntu pod that you can use as a client:\n\n    kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il\n\n2. Install the mysql client:\n\n    $ apt-get update && apt-get install mysql-client -y\n\n3. Connect using the mysql cli, then provide your password:\n    $ mysql -h wintering-rodent-mysql -p\n\nTo connect to your database directly from outside the K8s cluster:\n    MYSQL_HOST=127.0.0.1\n    MYSQL_PORT=3306\n\n    # Execute the following command to route the connection:\n    kubectl port-forward svc/wintering-rodent-mysql 3306\n\n    mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD}\n```\n\nBecause Helm tracks your releases even after you've deleted them, you\ncan audit a cluster's history, and even undelete a release (with `helm\nrollback`).\n\n## Reading the Help Text\n\nTo learn more about the available Helm commands, use `helm help` or type\na command followed by the `-h` flag:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "versioned_docs/version-3/chart_best_practices/conventions.md",
    "content": "---\ntitle: General Conventions\ndescription: General conventions for charts.\nsidebar_position: 1\n---\n\nThis part of the Best Practices Guide explains general conventions.\n\n## Chart Names\n\nChart names must be lower case letters and numbers. Words _may_ be separated\nwith dashes (-):\n\nExamples:\n\n```\ndrupal\nnginx-lego\naws-cluster-autoscaler\n```\n\nNeither uppercase letters nor underscores can be used in chart names. Dots\nshould not be used in chart names.\n\n## Version Numbers\n\nWherever possible, Helm uses [SemVer 2](https://semver.org) to represent version\nnumbers. (Note that Docker image tags do not necessarily follow SemVer, and are\nthus considered an unfortunate exception to the rule.)\n\nWhen SemVer versions are stored in Kubernetes labels, we conventionally alter\nthe `+` character to an `_` character, as labels do not allow the `+` sign as a\nvalue.\n\n## Formatting YAML\n\nYAML files should be indented using _two spaces_ (and never tabs).\n\n## Usage of the Words Helm and Chart\n\nThere are a few conventions for using the words _Helm_ and _helm_.\n\n- _Helm_ refers to the project as a whole\n- `helm` refers to the client-side command\n- The term `chart` does not need to be capitalized, as it is not a proper noun\n- However, `Chart.yaml` does need to be capitalized because the file name is\n  case sensitive\n\nWhen in doubt, use _Helm_ (with an uppercase 'H').\n\n## Chart templates and namespaces\n\nAvoid defining the `namespace` property in the `metadata` section of your chart\ntemplates. The namespace to apply rendered templates to should be\nspecified in the call to a Kubernetes client via the flag like `--namespace`.\nHelm is rendering your templates as-is and sending them off to the\nKubernetes client, whether it be Helm itself or another\nprogram (kubectl, flux, spinnaker, etc).\n"
  },
  {
    "path": "versioned_docs/version-3/chart_best_practices/custom_resource_definitions.md",
    "content": "---\ntitle: Custom Resource Definitions\ndescription: How to handle creating and using CRDs.\nsidebar_position: 7\n---\n\nThis section of the Best Practices Guide deals with creating and using Custom\nResource Definition objects.\n\nWhen working with Custom Resource Definitions (CRDs), it is important to\ndistinguish two different pieces:\n\n- There is a declaration of a CRD. This is the YAML file that has the kind\n  `CustomResourceDefinition`\n- Then there are resources that _use_ the CRD. Say a CRD defines\n  `foo.example.com/v1`. Any resource that has `apiVersion: example.com/v1` and\n  kind `Foo` is a resource that uses the CRD.\n\n## Install a CRD Declaration Before Using the Resource\n\nHelm is optimized to load as many resources into Kubernetes as fast as possible.\nBy design, Kubernetes can take an entire set of manifests and bring them all\nonline (this is called the reconciliation loop).\n\nBut there's a difference with CRDs.\n\nFor a CRD, the declaration must be registered before any resources of that CRDs\nkind(s) can be used. And the registration process sometimes takes a few seconds.\n\n### Method 1: Let `helm` Do It For You\n\nWith the arrival of Helm 3, we removed the old `crd-install` hooks for a more\nsimple methodology. There is now a special directory called `crds` that you can\ncreate in your chart to hold your CRDs. These CRDs are not templated, but will\nbe installed by default when running a `helm install` for the chart. If the CRD\nalready exists, it will be skipped with a warning. If you wish to skip the CRD\ninstallation step, you can pass the `--skip-crds` flag.\n\n#### Some caveats (and explanations)\n\nThere is no support at this time for upgrading or deleting CRDs using Helm. This\nwas an explicit decision after much community discussion due to the danger for\nunintentional data loss. Furthermore, there is currently no community consensus\naround how to handle CRDs and their lifecycle. As this evolves, Helm will add\nsupport for those use cases.\n\nThe `--dry-run` flag of `helm install` and `helm upgrade` is not currently\nsupported for CRDs. The purpose of \"Dry Run\" is to validate that the output of\nthe chart will actually work if sent to the server. But CRDs are a modification\nof the server's behavior. Helm cannot install the CRD on a dry run, so the\ndiscovery client will not know about that Custom Resource (CR), and validation\nwill fail. You can alternatively move the CRDs to their own chart or use `helm\ntemplate` instead.\n\nAnother important point to consider in the discussion around CRD support is how\nthe rendering of templates is handled. One of the distinct disadvantages of the\n`crd-install` method used in Helm 2 was the inability to properly validate\ncharts due to changing API availability (a CRD is actually adding another\navailable API to your Kubernetes cluster). If a chart installed a CRD, `helm` no\nlonger had a valid set of API versions to work against. This is also the reason\nbehind removing templating support from CRDs. With the new `crds` method of CRD\ninstallation, we now ensure that `helm` has completely valid information about\nthe current state of the cluster.\n\n### Method 2: Separate Charts\n\nAnother way to do this is to put the CRD definition in one chart, and then put\nany resources that use that CRD in _another_ chart.\n\nIn this method, each chart must be installed separately. However, this workflow\nmay be more useful for cluster operators who have admin access to a cluster\n"
  },
  {
    "path": "versioned_docs/version-3/chart_best_practices/dependencies.md",
    "content": "---\ntitle: Dependencies\ndescription: Covers best practices for Chart dependencies.\nsidebar_position: 4\n---\n\nThis section of the guide covers best practices for `dependencies` declared in\n`Chart.yaml`.\n\n## Versions\n\nWhere possible, use version ranges instead of pinning to an exact version. The\nsuggested default is to use a patch-level version match:\n\n```yaml\nversion: ~1.2.3\n```\n\nThis will match version `1.2.3` and any patches to that release.  In other\nwords, `~1.2.3` is equivalent to `>= 1.2.3, < 1.3.0`\n\nFor the complete version matching syntax, please see the [semver\ndocumentation](https://github.com/Masterminds/semver#checking-version-constraints).\n\n### Prerelease versions\n\nThe above versioning constraints will not match on pre-release versions.\nFor example `version: ~1.2.3` will match `version: ~1.2.4` but not `version: ~1.2.3-1`.\nThe following provides a pre-release as well as patch-level matching:\n\n```yaml\nversion: ~1.2.3-0\n```\n\n### Repository URLs\n\nWhere possible, use `https://` repository URLs, followed by `http://` URLs.\n\nIf the repository has been added to the repository index file, the repository\nname can be used as an alias of URL. Use `alias:` or `@` followed by repository\nnames.\n\nFile URLs (`file://...`) are considered a \"special case\" for charts that are\nassembled by a fixed deployment pipeline.\n\nWhen using [downloader plugins](/topics/plugins.md#downloader-plugins)\nthe URL scheme will be specific to the plugin. Note, a user of the chart will\nneed to have a plugin supporting the scheme installed to update or build the\ndependency.\n\nHelm cannot perform dependency management operations on the dependency when the\n`repository` field is left blank. In that case Helm will assume the dependency\nis in a sub-directory of the `charts` folder with the name being the same as the\n`name` property for the dependency.\n\n## Conditions and Tags\n\nConditions or tags should be added to any dependencies that _are optional_. Note that by default a `condition` is `true`.\n\nThe preferred form of a condition is:\n\n```yaml\ncondition: somechart.enabled\n```\n\nWhere `somechart` is the chart name of the dependency.\n\nWhen multiple subcharts (dependencies) together provide an optional or swappable\nfeature, those charts should share the same tags.\n\nFor example, if both `nginx` and `memcached` together provide performance\noptimizations for the main app in the chart, and are required to both be present\nwhen that feature is enabled, then they should both have a tags section like\nthis:\n\n```yaml\ntags:\n  - webaccelerator\n```\n\nThis allows a user to turn that feature on and off with one tag.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_best_practices/index.mdx",
    "content": "---\ntitle: Best Practices\nsidebar: true\nsidebar_position: 4\n---\n\n# The Chart Best Practices Guide\n\nThis guide covers the Helm Team's considered best practices for creating charts.\nIt focuses on how charts should be structured.\n\nWe focus primarily on best practices for charts that may be publicly deployed.\nWe know that many charts are for internal-use only, and authors of such charts\nmay find that their internal interests override our suggestions here.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/chart_best_practices/labels.md",
    "content": "---\ntitle: Labels and Annotations\ndescription: Covers best practices for using labels and annotations in your Chart.\nsidebar_position: 5\n---\n\nThis part of the Best Practices Guide discusses the best practices for using\nlabels and annotations in your chart.\n\n## Is it a Label or an Annotation?\n\nAn item of metadata should be a label under the following conditions:\n\n- It is used by Kubernetes to identify this resource\n- It is useful to expose to operators for the purpose of querying the system.\n\nFor example, we suggest using `helm.sh/chart: NAME-VERSION` as a label so that\noperators can conveniently find all of the instances of a particular chart to\nuse.\n\nIf an item of metadata is not used for querying, it should be set as an\nannotation instead.\n\nHelm hooks are always annotations.\n\n## Standard Labels\n\nThe following table defines common labels that Helm charts use. Helm itself\nnever requires that a particular label be present. Labels that are marked REC\nare recommended, and _should_ be placed onto a chart for global consistency.\nThose marked OPT are optional. These are idiomatic or commonly in use, but are\nnot relied upon frequently for operational purposes.\n\nName|Status|Description\n-----|------|----------\n`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.\n`helm.sh/chart` | REC | This should be the chart name and version: `{{ .Chart.Name }}-{{ .Chart.Version \\| replace \"+\" \"_\" }}`.\n`app.kubernetes.io/managed-by` | REC | This should always be set to `{{ .Release.Service }}`. It is for finding all things managed by Helm.\n`app.kubernetes.io/instance` | REC | This should be the `{{ .Release.Name }}`. It aids in differentiating between different instances of the same application.\n`app.kubernetes.io/version` | OPT | The version of the app and can be set to `{{ .Chart.AppVersion }}`.\n`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`.\n`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.\n\nYou can find more information on the Kubernetes labels, prefixed with\n`app.kubernetes.io`, in the [Kubernetes\ndocumentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/).\n"
  },
  {
    "path": "versioned_docs/version-3/chart_best_practices/pods.md",
    "content": "---\ntitle: Pods and PodTemplates\ndescription: Discusses formatting the Pod and PodTemplate portions in Chart manifests.\nsidebar_position: 6\n---\n\nThis part of the Best Practices Guide discusses formatting the Pod and\nPodTemplate portions in chart manifests.\n\nThe following (non-exhaustive) list of resources use PodTemplates:\n\n- Deployment\n- ReplicationController\n- ReplicaSet\n- DaemonSet\n- StatefulSet\n\n## Images\n\nA container image should use a fixed tag or the SHA of the image. It should not\nuse the tags `latest`, `head`, `canary`, or other tags that are designed to be\n\"floating\".\n\n\nImages _may_ be defined in the `values.yaml` file to make it easy to swap out\nimages.\n\n```yaml\nimage: {{ .Values.redisImage | quote }}\n```\n\nAn image and a tag _may_ be defined in `values.yaml` as two separate fields:\n\n```yaml\nimage: \"{{ .Values.redisImage }}:{{ .Values.redisTag }}\"\n```\n\n## ImagePullPolicy\n\n`helm create` sets the `imagePullPolicy` to `IfNotPresent` by default by doing\nthe following in your `deployment.yaml`:\n\n```yaml\nimagePullPolicy: {{ .Values.image.pullPolicy }}\n```\n\nAnd `values.yaml`:\n\n```yaml\nimage:\n  pullPolicy: IfNotPresent\n```\n\nSimilarly, Kubernetes defaults the `imagePullPolicy` to `IfNotPresent` if it is\nnot defined at all. If you want a value other than `IfNotPresent`, simply update\nthe value in `values.yaml` to your desired value.\n\n\n## PodTemplates Should Declare Selectors\n\nAll PodTemplate sections should specify a selector. For example:\n\n```yaml\nselector:\n  matchLabels:\n      app.kubernetes.io/name: MyName\ntemplate:\n  metadata:\n    labels:\n      app.kubernetes.io/name: MyName\n```\n\nThis is a good practice because it makes the relationship between the set and\nthe pod.\n\nBut this is even more important for sets like Deployment. Without this, the\n_entire_ set of labels is used to select matching pods, and this will break if\nyou use labels that change, like version or release date.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_best_practices/rbac.md",
    "content": "---\ntitle: Role-Based Access Control\ndescription: Discusses the creation and formatting of RBAC resources in Chart manifests.\nsidebar_position: 8\n---\n\nThis part of the Best Practices Guide discusses the creation and formatting of\nRBAC resources in chart manifests.\n\nRBAC resources are:\n\n- ServiceAccount (namespaced)\n- Role (namespaced)\n- ClusterRole\n- RoleBinding (namespaced)\n- ClusterRoleBinding\n\n## YAML Configuration\n\nRBAC and ServiceAccount configuration should happen under separate keys. They\nare separate things. Splitting these two concepts out in the YAML disambiguates\nthem and makes this clearer.\n\n```yaml\nrbac:\n  # Specifies whether RBAC resources should be created\n  create: true\n\nserviceAccount:\n  # Specifies whether a ServiceAccount should be created\n  create: true\n  # The name of the ServiceAccount to use.\n  # If not set and create is true, a name is generated using the fullname template\n  name:\n```\n\nThis structure can be extended for more complex charts that require multiple\nServiceAccounts.\n\n```yaml\nsomeComponent:\n  serviceAccount:\n    create: true\n    name:\nanotherComponent:\n  serviceAccount:\n    create: true\n    name:\n```\n\n## RBAC Resources Should be Created by Default\n\n`rbac.create` should be a boolean value controlling whether RBAC resources are\ncreated.  The default should be `true`.  Users who wish to manage RBAC access\ncontrols themselves can set this value to `false` (in which case see below).\n\n## Using RBAC Resources\n\n`serviceAccount.name` should be set to the name of the ServiceAccount to be used\nby access-controlled resources created by the chart.  If `serviceAccount.create`\nis true, then a ServiceAccount with this name should be created.  If the name is\nnot set, then a name is generated using the `fullname` template, If\n`serviceAccount.create` is false, then it should not be created, but it should\nstill be associated with the same resources so that manually-created RBAC\nresources created later that reference it will function correctly.  If\n`serviceAccount.create` is false and the name is not specified, then the default\nServiceAccount is used.\n\nThe following helper template should be used for the ServiceAccount.\n\n```yaml\n{{/*\nCreate the name of the service account to use\n*/}}\n{{- define \"mychart.serviceAccountName\" -}}\n{{- if .Values.serviceAccount.create -}}\n    {{ default (include \"mychart.fullname\" .) .Values.serviceAccount.name }}\n{{- else -}}\n    {{ default \"default\" .Values.serviceAccount.name }}\n{{- end -}}\n{{- end -}}\n```\n"
  },
  {
    "path": "versioned_docs/version-3/chart_best_practices/templates.md",
    "content": "---\ntitle: Templates\ndescription: A closer look at best practices surrounding templates.\nsidebar_position: 3\n---\n\nThis part of the Best Practices Guide focuses on templates.\n\n## Structure of `templates/`\n\nThe `templates/` directory should be structured as follows:\n\n- Template files should have the extension `.yaml` if they produce YAML output.\n  The extension `.tpl` may be used for template files that produce no formatted\n  content.\n- Template file names should use dashed notation (`my-example-configmap.yaml`),\n  not camelcase.\n- Each resource definition should be in its own template file.\n- Template file names should reflect the resource kind in the name. e.g.\n  `foo-pod.yaml`, `bar-svc.yaml`\n\n## Names of Defined Templates\n\nDefined templates (templates created inside a `{{ define }} ` directive) are\nglobally accessible. That means that a chart and all of its subcharts will have\naccess to all of the templates created with `{{ define }}`.\n\nFor that reason, _all defined template names should be namespaced._\n\nCorrect:\n\n```yaml\n{{- define \"nginx.fullname\" }}\n{{/* ... */}}\n{{ end -}}\n```\n\nIncorrect:\n\n```yaml\n{{- define \"fullname\" -}}\n{{/* ... */}}\n{{ end -}}\n```\nIt is highly recommended that new charts are created via `helm create` command\nas the template names are automatically defined as per this best practice.\n\n## Formatting Templates\n\nTemplates should be indented using _two spaces_ (never tabs).\n\nTemplate directives should have whitespace after the opening  braces and before\nthe closing braces:\n\nCorrect:\n```\n{{ .foo }}\n{{ print \"foo\" }}\n{{- print \"bar\" -}}\n```\n\nIncorrect:\n```\n{{.foo}}\n{{print \"foo\"}}\n{{-print \"bar\"-}}\n```\n\nTemplates should chomp whitespace where possible:\n\n```yaml\nfoo:\n  {{- range .Values.items }}\n  {{ . }}\n  {{ end -}}\n```\n\nBlocks (such as control structures) may be indented to indicate flow of the\ntemplate code.\n\n```\n{{ if $foo -}}\n  {{- with .Bar }}Hello{{ end -}}\n{{- end -}}\n```\n\nHowever, since YAML is a whitespace-oriented language, it is often not possible\nfor code indentation to follow that convention.\n\n## Whitespace in Generated Templates\n\nIt is preferable to keep the amount of whitespace in generated templates to a\nminimum. In particular, numerous blank lines should not appear adjacent to each\nother. But occasional empty lines (particularly between logical sections) is\nfine.\n\nThis is best:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: example\n  labels:\n    first: first\n    second: second\n```\n\nThis is okay:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n  labels:\n    first: first\n    second: second\n\n```\n\nBut this should be avoided:\n\n```yaml\napiVersion: batch/v1\nkind: Job\n\nmetadata:\n  name: example\n\n\n\n\n\n  labels:\n    first: first\n\n    second: second\n\n```\n\n## Comments (YAML Comments vs. Template Comments)\n\nBoth YAML and Helm Templates have comment markers.\n\nYAML comments:\n```yaml\n# This is a comment\ntype: sprocket\n```\n\nTemplate Comments:\n```yaml\n{{- /*\nThis is a comment.\n*/}}\ntype: frobnitz\n```\n\nTemplate comments should be used when documenting features of a template, such\nas explaining a defined template:\n\n```yaml\n{{- /*\nmychart.shortname provides a 6 char truncated version of the release name.\n*/}}\n{{ define \"mychart.shortname\" -}}\n{{ .Release.Name | trunc 6 }}\n{{- end -}}\n\n```\n\nInside of templates, YAML comments may be used when it is useful for Helm users\nto (possibly) see the comments during debugging.\n\n```yaml\n# This may cause problems if the value is more than 100Gi\nmemory: {{ .Values.maxMem | quote }}\n```\n\nThe comment above is visible when the user runs `helm install --debug`, while\ncomments specified in `{{- /* */}}` sections are not.\n\nBeware of adding `#` YAML comments on template sections containing Helm values that may be required by certain template functions.\n\nFor example, if `required` function is introduced to the above example, and `maxMem` is unset, then a `#` YAML comment will introduce a rendering error.\n\nCorrect: `helm template` does not render this block\n```yaml\n{{- /*\n# This may cause problems if the value is more than 100Gi\nmemory: {{ required \"maxMem must be set\" .Values.maxMem | quote }}\n*/ -}}\n```\n\nIncorrect: `helm template` returns `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`\n```yaml\n# This may cause problems if the value is more than 100Gi\n# memory: {{ required .Values.maxMem \"maxMem must be set\" | quote }}\n```\n\nReview [Debugging Templates](/chart_template_guide/debugging.md) for another example of this behavior of how YAML comments are left intact.\n\n## Use of JSON in Templates and Template Output\n\nYAML is a superset of JSON. In some cases, using a JSON syntax can be more\nreadable than other YAML representations.\n\nFor example, this YAML is closer to the normal YAML method of expressing lists:\n\n```yaml\narguments:\n  - \"--dirname\"\n  - \"/foo\"\n```\n\nBut it is easier to read when collapsed into a JSON list style:\n\n```yaml\narguments: [\"--dirname\", \"/foo\"]\n```\n\nUsing JSON for increased legibility is good. However, JSON syntax should not be\nused for representing more complex constructs.\n\nWhen dealing with pure JSON embedded inside of YAML (such as init container\nconfiguration), it is of course appropriate to use the JSON format.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_best_practices/values.md",
    "content": "---\ntitle: Values\ndescription: Focuses on how you should structure and use your values.\nsidebar_position: 2\n---\n\nThis part of the best practices guide covers using values. In this part of the\nguide, we provide recommendations on how you should structure and use your\nvalues, with focus on designing a chart's `values.yaml` file.\n\n## Naming Conventions\n\nVariable names should begin with a lowercase letter, and words should be\nseparated with camelcase:\n\nCorrect:\n\n```yaml\nchicken: true\nchickenNoodleSoup: true\n```\n\nIncorrect:\n\n```yaml\nChicken: true  # initial caps may conflict with built-ins\nchicken-noodle-soup: true # do not use hyphens in the name\n```\n\nNote that all of Helm's built-in variables begin with an uppercase letter to\neasily distinguish them from user-defined values: `.Release.Name`,\n`.Capabilities.KubeVersion`.\n\n## Flat or Nested Values\n\nYAML is a flexible format, and values may be nested deeply or flattened.\n\nNested:\n\n```yaml\nserver:\n  name: nginx\n  port: 80\n```\n\nFlat:\n\n```yaml\nserverName: nginx\nserverPort: 80\n```\n\nIn most cases, flat should be favored over nested. The reason for this is that\nit is simpler for template developers and users.\n\n\nFor optimal safety, a nested value must be checked at every level:\n\n```\n{{ if .Values.server }}\n  {{ default \"none\" .Values.server.name }}\n{{ end }}\n```\n\nFor every layer of nesting, an existence check must be done. But for flat\nconfiguration, such checks can be skipped, making the template easier to read\nand use.\n\n```\n{{ default \"none\" .Values.serverName }}\n```\n\nWhen there are a large number of related variables, and at least one of them is\nnon-optional, nested values may be used to improve readability.\n\n## Make Types Clear\n\nYAML's type coercion rules are sometimes counterintuitive. For example, `foo:\nfalse` is not the same as `foo: \"false\"`. Large integers like `foo: 12345678`\nwill get converted to scientific notation in some cases.\n\nThe easiest way to avoid type conversion errors is to be explicit about strings,\nand implicit about everything else. Or, in short, _quote all strings_.\n\nOften, to avoid the integer casting issues, it is advantageous to store your\nintegers as strings as well, and use `{{ int $value }}` in the template to\nconvert from a string back to an integer.\n\nIn most cases, explicit type tags are respected, so `foo: !!string 1234` should\ntreat `1234` as a string. _However_, the YAML parser consumes tags, so the type\ndata is lost after one parse.\n\n## Consider How Users Will Use Your Values\n\nThere are three potential sources of values:\n\n- A chart's `values.yaml` file\n- A values file supplied by `helm install -f` or `helm upgrade -f`\n- The values passed to a `--set` or `--set-string` flag on `helm install` or\n  `helm upgrade`\n\nWhen designing the structure of your values, keep in mind that users of your\nchart may want to override them via either the `-f` flag or with the `--set`\noption.\n\nSince `--set` is more limited in expressiveness, the first guidelines for\nwriting your `values.yaml` file is _make it easy to override from `--set`_.\n\nFor this reason, it's often better to structure your values file using maps.\n\nDifficult to use with `--set`:\n\n```yaml\nservers:\n  - name: foo\n    port: 80\n  - name: bar\n    port: 81\n```\n\nThe above cannot be expressed with `--set` in Helm `<=2.4`. In Helm 2.5,\naccessing the port on foo is `--set servers[0].port=80`. Not only is it harder\nfor the user to figure out, but it is prone to errors if at some later time the\norder of the `servers` is changed.\n\nEasy to use:\n\n```yaml\nservers:\n  foo:\n    port: 80\n  bar:\n    port: 81\n```\n\nAccessing foo's port is much more obvious: `--set servers.foo.port=80`.\n\n## Document `values.yaml`\n\nEvery defined property in `values.yaml` should be documented. The documentation\nstring should begin with the name of the property that it describes, and then\ngive at least a one-sentence description.\n\nIncorrect:\n\n```yaml\n# the host name for the webserver\nserverHost: example\nserverPort: 9191\n```\n\nCorrect:\n\n```yaml\n# serverHost is the host name for the webserver\nserverHost: example\n# serverPort is the HTTP listener port for the webserver\nserverPort: 9191\n```\n\nBeginning each comment with the name of the parameter it documents makes it easy\nto grep out documentation, and will enable documentation tools to reliably\ncorrelate doc strings with the parameters they describe.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/accessing_files.md",
    "content": "---\ntitle: Accessing Files Inside Templates\ndescription: How to access files from within a template.\nsidebar_position: 10\n---\n\nIn the previous section we looked at several ways to create and access named\ntemplates. This makes it easy to import one template from within another\ntemplate. But sometimes it is desirable to import a _file that is not a\ntemplate_ and inject its contents without sending the contents through the\ntemplate renderer.\n\nHelm provides access to files through the `.Files` object. Before we get going\nwith the template examples, though, there are a few things to note about how\nthis works:\n\n- It is okay to add extra files to your Helm chart. These files will be bundled.\n  Be careful, though. Charts must be smaller than 1M because of the storage\n  limitations of Kubernetes objects.\n- Some files cannot be accessed through the `.Files` object, usually for\n  security reasons.\n  - Files in `templates/` cannot be accessed.\n  - Files excluded using `.helmignore` cannot be accessed.\n  - Files outside of a Helm application [subchart](/chart_template_guide/subcharts_and_globals.md), including those of the parent, cannot be accessed\n- Charts do not preserve UNIX mode information, so file-level permissions will\n  have no impact on the availability of a file when it comes to the `.Files`\n  object.\n\n<!-- (see https://github.com/jonschlinkert/markdown-toc) -->\n\n<!-- toc -->\n\n- [Basic example](#basic-example)\n- [Path helpers](#path-helpers)\n- [Glob patterns](#glob-patterns)\n- [ConfigMap and Secrets utility functions](#configmap-and-secrets-utility-functions)\n- [Encoding](#encoding)\n- [Lines](#lines)\n\n<!-- tocstop -->\n\n## Basic example\n\nWith those caveats behind, let's write a template that reads three files into\nour ConfigMap. To get started, we will add three files to the chart, putting all\nthree directly inside of the `mychart/` directory.\n\n`config1.toml`:\n\n```toml\nmessage = \"Hello from config 1\"\n```\n\n`config2.toml`:\n\n```toml\nmessage = \"This is config 2\"\n```\n\n`config3.toml`:\n\n```toml\nmessage = \"Goodbye from config 3\"\n```\n\nEach of these is a simple TOML file (think old-school Windows INI files). We\nknow the names of these files, so we can use a `range` function to loop through\nthem and inject their contents into our ConfigMap.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  {{- $files := .Files }}\n  {{- range tuple \"config1.toml\" \"config2.toml\" \"config3.toml\" }}\n  {{ . }}: |-\n    {{ $files.Get . }}\n  {{- end }}\n```\n\nThis ConfigMap uses several of the techniques discussed in previous sections.\nFor example, we create a `$files` variable to hold a reference to the `.Files`\nobject. We also use the `tuple` function to create a list of files that we loop\nthrough. Then we print each file name (`{{ . }}: |-`) followed by the contents\nof the file `{{ $files.Get . }}`.\n\nRunning this template will produce a single ConfigMap with the contents of all\nthree files:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: quieting-giraf-configmap\ndata:\n  config1.toml: |-\n    message = \"Hello from config 1\"\n\n  config2.toml: |-\n    message = \"This is config 2\"\n\n  config3.toml: |-\n    message = \"Goodbye from config 3\"\n```\n\n## Path helpers\n\nWhen working with files, it can be very useful to perform some standard\noperations on the file paths themselves. To help with this, Helm imports many of\nthe functions from Go's [path](https://golang.org/pkg/path/) package for your\nuse. They are all accessible with the same names as in the Go package, but with\na lowercase first letter. For example, `Base` becomes `base`, etc.\n\nThe imported functions are:\n- Base\n- Dir\n- Ext\n- IsAbs\n- Clean\n\n## Glob patterns\n\nAs your chart grows, you may find you have a greater need to organize your files\nmore, and so we provide a `Files.Glob(pattern string)` method to assist in\nextracting certain files with all the flexibility of [glob\npatterns](https://godoc.org/github.com/gobwas/glob).\n\n`.Glob` returns a `Files` type, so you may call any of the `Files` methods on\nthe returned object.\n\nFor example, imagine the directory structure:\n\n```\nfoo/:\n  foo.txt foo.yaml\n\nbar/:\n  bar.go bar.conf baz.yaml\n```\n\nYou have multiple options with Globs:\n\n\n```yaml\n{{ $currentScope := .}}\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n    {{- with $currentScope}}\n        {{ .Files.Get $path }}\n    {{- end }}\n{{ end }}\n```\n\nOr\n\n```yaml\n{{ range $path, $_ :=  .Files.Glob  \"**.yaml\" }}\n      {{ $.Files.Get $path }}\n{{ end }}\n```\n\n## ConfigMap and Secrets utility functions\n\n(Available Helm 2.0.2 and after)\n\nIt is very common to want to place file content into both ConfigMaps and\nSecrets, for mounting into your pods at run time. To help with this, we provide\na couple utility methods on the `Files` type.\n\nFor further organization, it is especially useful to use these methods in\nconjunction with the `Glob` method.\n\nGiven the directory structure from the [Glob](#glob-patterns) example above:\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: conf\ndata:\n{{ (.Files.Glob \"foo/*\").AsConfig | indent 2 }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: very-secret\ntype: Opaque\ndata:\n{{ (.Files.Glob \"bar/*\").AsSecrets | indent 2 }}\n```\n\n## Encoding\n\nYou can import a file and have the template base-64 encode it to ensure\nsuccessful transmission:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .Release.Name }}-secret\ntype: Opaque\ndata:\n  token: |-\n    {{ .Files.Get \"config1.toml\" | b64enc }}\n```\n\nThe above will take the same `config1.toml` file we used before and encode it:\n\n```yaml\n# Source: mychart/templates/secret.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: lucky-turkey-secret\ntype: Opaque\ndata:\n  token: |-\n    bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo=\n```\n\n## Lines\n\nSometimes it is desirable to access each line of a file in your template. We\nprovide a convenient `Lines` method for this.\n\nYou can loop through `Lines` using a `range` function:\n\n```yaml\ndata:\n  some-file.txt: {{ range .Files.Lines \"foo/bar.txt\" }}\n    {{ . }}{{ end }}\n```\n\nThere is no way to pass files external to the chart during `helm install`. So if\nyou are asking users to supply data, it must be loaded using `helm install -f`\nor `helm install --set`.\n\nThis discussion wraps up our dive into the tools and techniques for writing Helm\ntemplates. In the next section we will see how you can use one special file,\n`templates/NOTES.txt`, to send post-installation instructions to the users of\nyour chart.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/builtin_objects.md",
    "content": "---\ntitle: Built-in Objects\ndescription: Built-in objects available to templates.\nsidebar_position: 3\n---\n\nObjects are passed into a template from the template engine. And your code can\npass objects around (we'll see examples when we look at the `with` and `range`\nstatements). There are even a few ways to create new objects within your\ntemplates, like with the `tuple` function we'll see later.\n\nObjects can be simple, and have just one value. Or they can contain other\nobjects or functions. For example, the `Release` object contains several objects\n(like `Release.Name`) and the `Files` object has a few functions.\n\nIn the previous section, we use `{{ .Release.Name }}` to insert the name of a\nrelease into a template. `Release` is one of the top-level objects that you can\naccess in your templates.\n\n- `Release`: This object describes the release itself. It has several objects\n  inside of it:\n  - `Release.Name`: The release name\n  - `Release.Namespace`: The namespace to be released into (if the manifest\n    doesn’t override)\n  - `Release.IsUpgrade`: This is set to `true` if the current operation is an\n    upgrade or rollback.\n  - `Release.IsInstall`: This is set to `true` if the current operation is an\n    install.\n  - `Release.Revision`: The revision number for this release. On install, this\n    is 1, and it is incremented with each upgrade and rollback.\n  - `Release.Service`: The service that is rendering the present template. On\n    Helm, this is always `Helm`.\n- `Values`: Values passed into the template from the `values.yaml` file and from\n  user-supplied files. By default, `Values` is empty.\n- `Chart`: The contents of the `Chart.yaml` file. Any data in `Chart.yaml` will\n  be accessible here. For example `{{ .Chart.Name }}-{{ .Chart.Version }}` will\n  print out the `mychart-0.1.0`.\n  - The available fields are listed in the [Charts Guide](/topics/charts.md#the-chartyaml-file)\n- `Subcharts`: This provides access to the scope (.Values, .Charts, .Releases etc.)\n  of subcharts to the parent. For example `.Subcharts.mySubChart.myValue` to access\n  the `myValue` in the `mySubChart` chart.\n- `Files`: This provides access to all non-special files in a chart. While you\n  cannot use it to access templates, you can use it to access other files in the\n  chart. See the section [Accessing Files](/chart_template_guide/accessing_files.md) for more.\n  - `Files.Get` is a function for getting a file by name (`.Files.Get\n    config.ini`)\n  - `Files.GetBytes` is a function for getting the contents of a file as an\n    array of bytes instead of as a string. This is useful for things like\n    images.\n  - `Files.Glob` is a function that returns a list of files whose names match\n    the given shell glob pattern.\n  - `Files.Lines` is a function that reads a file line-by-line. This is useful\n    for iterating over each line in a file.\n  - `Files.AsSecrets` is a function that returns the file bodies as Base 64\n    encoded strings.\n  - `Files.AsConfig` is a function that returns file bodies as a YAML map.\n- `Capabilities`: This provides information about what capabilities the\n  Kubernetes cluster supports.\n  - `Capabilities.APIVersions` is a set of versions.\n  - `Capabilities.APIVersions.Has $version` indicates whether a version (e.g.,\n    `batch/v1`) or resource (e.g., `apps/v1/Deployment`) is available on the\n    cluster.\n  - `Capabilities.KubeVersion` and `Capabilities.KubeVersion.Version` is the\n    Kubernetes version.\n  - `Capabilities.KubeVersion.Major` is the Kubernetes major version.\n  - `Capabilities.KubeVersion.Minor` is the Kubernetes minor version.\n  - `Capabilities.HelmVersion` is the object containing the Helm Version details, it is the same output of `helm version`.\n  - `Capabilities.HelmVersion.Version` is the current Helm version in semver format.\n  - `Capabilities.HelmVersion.GitCommit` is the Helm git sha1.\n  - `Capabilities.HelmVersion.GitTreeState` is the state of the Helm git tree.\n  - `Capabilities.HelmVersion.GoVersion` is the version of the Go compiler used.\n- `Template`: Contains information about the current template that is being\n  executed\n  - `Template.Name`: A namespaced file path to the current template (e.g.\n    `mychart/templates/mytemplate.yaml`)\n  - `Template.BasePath`: The namespaced path to the templates directory of the current\n    chart (e.g. `mychart/templates`).\n\nThe built-in values always begin with a capital letter. This is in keeping with\nGo's naming convention. When you create your own names, you are free to use a\nconvention that suits your team. Some teams, like many whose charts you may see\non [Artifact Hub](https://artifacthub.io/packages/search?kind=0), choose to use\nonly initial lower case letters in order to distinguish local names from those\nbuilt-in. In this guide, we follow that convention.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/control_structures.md",
    "content": "---\ntitle: Flow Control\ndescription: A quick overview on the flow structure within templates.\nsidebar_position: 7\n---\n\nControl structures (called \"actions\" in template parlance) provide you, the\ntemplate author, with the ability to control the flow of a template's\ngeneration. Helm's template language provides the following control structures:\n\n- `if`/`else` for creating conditional blocks\n- `with` to specify a scope\n- `range`, which provides a \"for each\"-style loop\n\nIn addition to these, it provides a few actions for declaring and using named\ntemplate segments:\n\n- `define` declares a new named template inside of your template\n- `template` imports a named template\n- `block` declares a special kind of fillable template area\n\nIn this section, we'll talk about `if`, `with`, and `range`. The others are\ncovered in the \"Named Templates\" section later in this guide.\n\n## If/Else\n\nThe first control structure we'll look at is for conditionally including blocks\nof text in a template. This is the `if`/`else` block.\n\nThe basic structure for a conditional looks like this:\n\n```\n{{ if PIPELINE }}\n  # Do something\n{{ else if OTHER PIPELINE }}\n  # Do something else\n{{ else }}\n  # Default case\n{{ end }}\n```\n\nNotice that we're now talking about _pipelines_ instead of values. The reason\nfor this is to make it clear that control structures can execute an entire\npipeline, not just evaluate a value.\n\nA pipeline is evaluated as _false_ if the value is:\n\n- a boolean false\n- a numeric zero\n- an empty string\n- a `nil` (empty or null)\n- an empty collection (`map`, `slice`, `tuple`, `dict`, `array`)\n\nUnder all other conditions, the condition is true.\n\nLet's add a simple conditional to our ConfigMap. We'll add another setting if\nthe drink is set to coffee:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}mug: \"true\"{{ end }}\n```\n\nSince we commented out `drink: coffee` in our last example, the output should\nnot include a `mug: \"true\"` flag. But if we add that line back into our\n`values.yaml` file, the output should look like this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\n## Controlling Whitespace\n\nWhile we're looking at conditionals, we should take a quick look at the way\nwhitespace is controlled in templates. Let's take the previous example and\nformat it to be a little easier to read:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n    mug: \"true\"\n  {{ end }}\n```\n\nInitially, this looks good. But if we run it through the template engine, we'll\nget an unfortunate result:\n\n```console\n$ helm install --dry-run --debug ./mychart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart\nError: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key\n```\n\nWhat happened? We generated incorrect YAML because of the whitespacing above.\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eyewitness-elk-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n    mug: \"true\"\n```\n\n`mug` is incorrectly indented. Let's simply out-dent that one line, and re-run:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{ if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{ end }}\n```\n\nWhen we sent that, we'll get YAML that is valid, but still looks a little funny:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: telling-chimp-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n\n  mug: \"true\"\n\n```\n\nNotice that we received a few empty lines in our YAML. Why? When the template\nengine runs, it _removes_ the contents inside of `{{` and `}}`, but it leaves\nthe remaining whitespace exactly as is.\n\nYAML ascribes meaning to whitespace, so managing the whitespace becomes pretty\nimportant. Fortunately, Helm templates have a few tools to help.\n\nFirst, the curly brace syntax of template declarations can be modified with\nspecial characters to tell the template engine to chomp whitespace. `{{- ` (with\nthe dash and space added) indicates that whitespace should be chomped left,\nwhile ` -}}` means whitespace to the right should be consumed. _Be careful!\nNewlines are whitespace!_\n\n> Make sure there is a space between the `-` and the rest of your directive.\n> `{{- 3 }}` means \"trim left whitespace and print 3\" while `{{-3 }}` means\n> \"print -3\".\n\nUsing this syntax, we can modify our template to get rid of those new lines:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"\n  {{- end }}\n```\n\nJust for the sake of making this point clear, let's adjust the above, and\nsubstitute an `*` for each whitespace that will be deleted following this rule.\nAn `*` at the end of the line indicates a newline character that would be\nremoved\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}*\n**{{- if eq .Values.favorite.drink \"coffee\" }}\n  mug: \"true\"*\n**{{- end }}\n\n```\n\nKeeping that in mind, we can run our template through Helm and see the result:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: clunky-cat-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  mug: \"true\"\n```\n\nBe careful with the chomping modifiers. It is easy to accidentally do things\nlike this:\n\n```yaml\n  food: {{ .Values.favorite.food | upper | quote }}\n  {{- if eq .Values.favorite.drink \"coffee\" -}}\n  mug: \"true\"\n  {{- end -}}\n\n```\n\nThat will produce `food: \"PIZZA\"mug: \"true\"` because it consumed newlines on both\nsides.\n\n> For the details on whitespace control in templates, see the [Official Go\n> template documentation](https://godoc.org/text/template)\n\nFinally, sometimes it's easier to tell the template system how to indent for you\ninstead of trying to master the spacing of template directives. For that reason,\nyou may sometimes find it useful to use the `indent` function (`{{ indent 2\n\"mug:true\" }}`).\n\n## Modifying scope using `with`\n\nThe next control structure to look at is the `with` action. This controls\nvariable scoping. Recall that `.` is a reference to _the current scope_. So\n`.Values` tells the template to find the `Values` object in the current scope.\n\nThe syntax for `with` is similar to a simple `if` statement:\n\n```\n{{ with PIPELINE }}\n  # restricted scope\n{{ end }}\n```\n\nScopes can be changed. `with` can allow you to set the current scope (`.`) to a\nparticular object. For example, we've been working with `.Values.favorite`.\nLet's rewrite our ConfigMap to alter the `.` scope to point to\n`.Values.favorite`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n```\n\nNote that we removed the `if` conditional from the previous exercise\nbecause it is now unnecessary - the block after `with` only executes\nif the value of `PIPELINE` is not empty.\n\nNotice that now we can reference `.drink` and `.food` without qualifying them.\nThat is because the `with` statement sets `.` to point to `.Values.favorite`.\nThe `.` is reset to its previous scope after `{{ end }}`.\n\nBut here's a note of caution! Inside of the restricted scope, you will not be\nable to access the other objects from the parent scope using `.`. This, for\nexample, will fail:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\nIt will produce an error because `Release.Name` is not inside of the restricted\nscope for `.`. However, if we swap the last two lines, all will work as expected\nbecause the scope is reset after `{{ end }}`.\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  release: {{ .Release.Name }}\n```\n\nOr, we can use `$` for accessing the object `Release.Name` from the parent\nscope. `$` is mapped to the root scope when template execution begins and it\ndoes not change during template execution. The following would work as well:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $.Release.Name }}\n  {{- end }}\n```\n\nAfter looking at `range`, we will take a look at template variables, which offer\none solution to the scoping issue above.\n\n## Looping with the `range` action\n\nMany programming languages have support for looping using `for` loops, `foreach`\nloops, or similar functional mechanisms. In Helm's template language, the way to\niterate through a collection is to use the `range` operator.\n\nTo start, let's add a list of pizza toppings to our `values.yaml` file:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n  - pineapple\n```\n\nNow we have a list (called a `slice` in templates) of `pizzaToppings`. We can\nmodify our template to print this list into our ConfigMap:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  {{- end }}\n  toppings: |-\n    {{- range .Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n\n```\n\nWe can use `$` for accessing the list `Values.pizzaToppings` from the parent\nscope. `$` is mapped to the root scope when template execution begins and it\ndoes not change during template execution. The following would work as well:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  toppings: |-\n    {{- range $.Values.pizzaToppings }}\n    - {{ . | title | quote }}\n    {{- end }}\n  {{- end }}\n```\n\nLet's take a closer look at the `toppings:` list. The `range` function will\n\"range over\" (iterate through) the `pizzaToppings` list. But now something\ninteresting happens. Just like `with` sets the scope of `.`, so does a `range`\noperator. Each time through the loop, `.` is set to the current pizza topping.\nThat is, the first time, `.` is set to `mushrooms`. The second iteration it is\nset to `cheese`, and so on.\n\nWe can send the value of `.` directly down a pipeline, so when we do `{{ . |\ntitle | quote }}`, it sends `.` to `title` (title case function) and then to\n`quote`. If we run this template, the output will be:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-dragonfly-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  toppings: |-\n    - \"Mushrooms\"\n    - \"Cheese\"\n    - \"Peppers\"\n    - \"Onions\"\n    - \"Pineapple\"\n```\n\nNow, in this example we've done something tricky. The `toppings: |-` line is\ndeclaring a multi-line string. So our list of toppings is actually not a YAML\nlist. It's a big string. Why would we do this? Because the data in ConfigMaps\n`data` is composed of key/value pairs, where both the key and the value are\nsimple strings. To understand why this is the case, take a look at the\n[Kubernetes ConfigMap docs](https://kubernetes.io/docs/concepts/configuration/configmap/).\nFor us, though, this detail doesn't matter much.\n\n> The `|-` marker in YAML takes a multi-line string. This can be a useful\n> technique for embedding big blocks of data inside of your manifests, as\n> exemplified here.\n\nSometimes it's useful to be able to quickly make a list inside of your template,\nand then iterate over that list. Helm templates have a function to make this\neasy: `tuple`. In computer science, a tuple is a list-like collection of fixed\nsize, but with arbitrary data types. This roughly conveys the way a `tuple` is\nused.\n\n```yaml\n  sizes: |-\n    {{- range tuple \"small\" \"medium\" \"large\" }}\n    - {{ . }}\n    {{- end }}\n```\n\nThe above will produce this:\n\n```yaml\n  sizes: |-\n    - small\n    - medium\n    - large\n```\n\nIn addition to lists and tuples, `range` can be used to iterate over collections\nthat have a key and a value (like a `map` or `dict`). We'll see how to do that\nin the next section when we introduce template variables.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/data_types.md",
    "content": "---\ntitle: \"Appendix: Go Data Types and Templates\"\ndescription: A quick overview on variables in templates.\nsidebar_position: 16\n---\n\nThe Helm template language is implemented in the strongly typed Go programming\nlanguage. For that reason, variables in templates are _typed_. For the most\npart, variables will be exposed as one of the following types:\n\n- string: A string of text\n- bool: a `true` or `false`\n- int: An integer value (there are also 8, 16, 32, and 64 bit signed and\n  unsigned variants of this)\n- float64: a 64-bit floating point value (there are also 8, 16, and 32 bit\n  varieties of this)\n- a byte slice (`[]byte`), often used to hold (potentially) binary data\n- struct: an object with properties and methods\n- a slice (indexed list) of one of the previous types\n- a string-keyed map (`map[string]interface{}`) where the value is one of the\n  previous types\n\nThere are many other types in Go, and sometimes you will have to convert between\nthem in your templates. The easiest way to debug an object's type is to pass it\nthrough `printf \"%T\"` in a template, which will print the type. Also see the\n`typeOf` and `kindOf` functions.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/debugging.md",
    "content": "---\ntitle: Debugging Templates\ndescription: Troubleshooting charts that are failing to deploy.\nsidebar_position: 13\n---\n\nDebugging templates can be tricky because the rendered templates are sent to the\nKubernetes API server, which may reject the YAML files for reasons other than\nformatting.\n\nThere are a few commands that can help you debug.\n\n- `helm lint` is your go-to tool for verifying that your chart follows best\n  practices\n- `helm template --debug` will test rendering chart templates locally.  \n- `helm install --dry-run --debug` will also render your chart locally without\ninstalling it, but will also check if conflicting resources are already running\non the cluster. Setting `--dry-run=server` will additionally execute any\n`lookup` in your chart towards the server.\n- `helm get manifest`: This is a good way to see what templates are installed on\n  the server.\n\nWhen your YAML is failing to parse, but you want to see what is generated, one\neasy way to retrieve the YAML is to comment out the problem section in the\ntemplate, and then re-run `helm install --dry-run --debug`:\n\n```yaml\napiVersion: v2\n# some: problem section\n# {{ .Values.foo | quote }}\n```\n\nThe above will be rendered and returned with the comments intact:\n\n```yaml\napiVersion: v2\n# some: problem section\n#  \"bar\"\n```\n\nThis provides a quick way of viewing the generated content without YAML parse\nerrors blocking.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/function_list.md",
    "content": "---\ntitle: Template Function List\ndescription: A list of template functions available in Helm\nsidebar_position: 6\n---\n\nHelm includes many template functions you can take advantage of in templates.\nThey are listed here and broken down by the following categories:\n\n* [Cryptographic and Security](#cryptographic-and-security-functions)\n* [Date](#date-functions)\n* [Dictionaries](#dictionaries-and-dict-functions)\n* [Encoding](#encoding-functions)\n* [File Path](#file-path-functions)\n* [Kubernetes and Chart](#kubernetes-and-chart-functions)\n* [Logic and Flow Control](#logic-and-flow-control-functions)\n* [Lists](#lists-and-list-functions)\n* [Math](#math-functions)\n* [Float Math](#float-math-functions)\n* [Network](#network-functions)\n* [Reflection](#reflection-functions)\n* [Regular Expressions](#regular-expressions)\n* [Semantic Versions](#semantic-version-functions)\n* [String](#string-functions)\n* [Type Conversion](#type-conversion-functions)\n* [URL](#url-functions)\n* [UUID](#uuid-functions)\n\n## Logic and Flow Control Functions\n\nHelm includes numerous logic and control flow functions including [and](#and),\n[coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq),\n[fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne),\n[not](#not), [or](#or), and [required](#required).\n\n### and\n\nReturns the boolean AND of two or more arguments\n(the first empty argument, or the last argument).\n\n```\nand .Arg1 .Arg2\n```\n\n### or\n\nReturns the boolean OR of two or more arguments\n(the first non-empty argument, or the last argument).\n\n```\nor .Arg1 .Arg2\n```\n\n### not\n\nReturns the boolean negation of its argument.\n\n```\nnot .Arg\n```\n\n### eq\n\nReturns the boolean equality of the arguments (e.g., Arg1 == Arg2).\n\n```\neq .Arg1 .Arg2\n```\n\n### ne\n\nReturns the boolean inequality of the arguments (e.g., Arg1 != Arg2)\n\n```\nne .Arg1 .Arg2\n```\n\n### lt\n\nReturns a boolean true if the first argument is less than the second. False is\nreturned otherwise (e.g., Arg1 < Arg2).\n\n```\nlt .Arg1 .Arg2\n```\n\n### le\n\nReturns a boolean true if the first argument is less than or equal to the\nsecond. False is returned otherwise (e.g., Arg1 <= Arg2).\n\n```\nle .Arg1 .Arg2\n```\n\n### gt\n\nReturns a boolean true if the first argument is greater than the second. False\nis returned otherwise (e.g., Arg1 > Arg2).\n\n```\ngt .Arg1 .Arg2\n```\n\n### ge\n\nReturns a boolean true if the first argument is greater than or equal to the\nsecond. False is returned otherwise (e.g., Arg1 >= Arg2).\n\n```\nge .Arg1 .Arg2\n```\n\n### default\n\nTo set a simple default value, use `default`:\n\n```\ndefault \"foo\" .Bar\n```\n\nIn the above, if `.Bar` evaluates to a non-empty value, it will be used. But if\nit is empty, `foo` will be returned instead.\n\nThe definition of \"empty\" depends on type:\n\n- Numeric: 0\n- String: \"\"\n- Lists: `[]`\n- Dicts: `{}`\n- Boolean: `false`\n- And always `nil` (aka null)\n\nFor structs, there is no definition of empty, so a struct will never return the\ndefault.\n\n### required\n\nSpecify values that must be set with `required`:\n\n```\nrequired \"A valid foo is required!\" .Bar\n```\n\nIf `.Bar` is empty or not defined (see [default](#default) on how this is \nevaluated), the template will not render and will return the error message \nsupplied instead.\n\n### empty\n\nThe `empty` function returns `true` if the given value is considered empty, and\n`false` otherwise. The empty values are listed in the `default` section.\n\n```\nempty .Foo\n```\n\nNote that in Go template conditionals, emptiness is calculated for you. Thus,\nyou rarely need `if not empty .Foo`. Instead, just use `if .Foo`.\n\n### fail\n\nUnconditionally returns an empty `string` and an `error` with the specified\ntext. This is useful in scenarios where other conditionals have determined that\ntemplate rendering should fail.\n\n```\nfail \"Please accept the end user license agreement\"\n```\n\n### coalesce\n\nThe `coalesce` function takes a list of values and returns the first non-empty\none.\n\n```\ncoalesce 0 1 2\n```\n\nThe above returns `1`.\n\nThis function is useful for scanning through multiple variables or values:\n\n```\ncoalesce .name .parent.name \"Matt\"\n```\n\nThe above will first check to see if `.name` is empty. If it is not, it will\nreturn that value. If it _is_ empty, `coalesce` will evaluate `.parent.name` for\nemptiness. Finally, if both `.name` and `.parent.name` are empty, it will return\n`Matt`.\n\n### ternary\n\nThe `ternary` function takes two values, and a test value. If the test value is\ntrue, the first value will be returned. If the test value is empty, the second\nvalue will be returned. This is similar to the ternary operator in C and other programming languages.\n\n#### true test value\n\n```\nternary \"foo\" \"bar\" true\n```\n\nor\n\n```\ntrue | ternary \"foo\" \"bar\"\n```\n\nThe above returns `\"foo\"`.\n\n#### false test value\n\n```\nternary \"foo\" \"bar\" false\n```\n\nor\n\n```\nfalse | ternary \"foo\" \"bar\"\n```\n\nThe above returns `\"bar\"`.\n\n## String Functions\n\nHelm includes the following string functions: [abbrev](#abbrev),\n[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat),\n[contains](#contains), [hasPrefix](#hasprefix-and-hassuffix),\n[hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials),\n[kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent),\n[nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf),\n[println](#println), [quote](#quote-and-squote),\n[randAlpha](#randalphanum-randalpha-randnumeric-and-randascii),\n[randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii),\n[randAscii](#randalphanum-randalpha-randnumeric-and-randascii),\n[randNumeric](#randalphanum-randalpha-randnumeric-and-randascii),\n[repeat](#repeat), [replace](#replace), [shuffle](#shuffle),\n[snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr),\n[swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall),\n[trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc),\n[untitle](#untitle), [upper](#upper), [wrap](#wrap), and [wrapWith](#wrapwith).\n\n### print\n\nReturns a string from the combination of its parts.\n\n```\nprint \"Matt has \" .Dogs \" dogs\"\n```\n\nTypes that are not strings are converted to strings where possible.\n\nNote, when two arguments next to each other are not strings a space is added\nbetween them.\n\n### println\n\nWorks the same way as [print](#print) but adds a new line at the end.\n\n### printf\n\nReturns a string based on a formatting string and the arguments to pass to it in\norder.\n\n```\nprintf \"%s has %d dogs.\" .Name .NumberDogs\n```\n\nThe placeholder to use depends on the type for the argument being passed in.\nThis includes:\n\nGeneral purpose:\n\n* `%v` the value in a default format\n  * when printing dicts, the plus flag (%+v) adds field names\n* `%%` a literal percent sign; consumes no value\n\nBoolean:\n\n* `%t` the word true or false\n\nInteger:\n\n* `%b` base 2\n* `%c` the character represented by the corresponding Unicode code point\n* `%d` base 10\n* `%o` base 8\n* `%O` base 8 with 0o prefix\n* `%q` a single-quoted character literal safely escaped\n* `%x` base 16, with lower-case letters for a-f\n* `%X` base 16, with upper-case letters for A-F\n* `%U` Unicode format: U+1234; same as \"U+%04X\"\n\n Floating-point and complex constituents:\n\n* `%b` decimal less scientific notation with exponent a power of two, e.g.\n  -123456p-78\n* `%e` scientific notation, e.g. -1.234456e+78\n* `%E` scientific notation, e.g. -1.234456E+78\n* `%f` decimal point but no exponent, e.g. 123.456\n* `%F` synonym for %f\n* `%g` %e for large exponents, %f otherwise.\n* `%G` %E for large exponents, %F otherwise\n* `%x` hexadecimal notation (with decimal power of two exponent), e.g.\n  -0x1.23abcp+20\n* `%X` upper-case hexadecimal notation, e.g. -0X1.23ABCP+20\n\nString and slice of bytes (treated equivalently with these verbs):\n\n* `%s` the uninterpreted bytes of the string or slice\n* `%q` a double-quoted string safely escaped\n* `%x` base 16, lower-case, two characters per byte\n* `%X` base 16, upper-case, two characters per byte\n\nSlice:\n\n* `%p` address of 0th element in base 16 notation, with leading 0x\n\n### trim\n\nThe `trim` function removes white space from both sides of a string:\n\n```\ntrim \"   hello    \"\n```\n\nThe above produces `hello`\n\n### trimAll\n\nRemoves the given characters from the front and back of a string:\n\n```\ntrimAll \"$\" \"$5.00\"\n```\n\nThe above returns `5.00` (as a string).\n\n### trimPrefix\n\nTrim just the prefix from a string:\n\n```\ntrimPrefix \"-\" \"-hello\"\n```\n\nThe above returns `hello`\n\n### trimSuffix\n\nTrim just the suffix from a string:\n\n```\ntrimSuffix \"-\" \"hello-\"\n```\n\nThe above returns `hello`\n\n### lower\n\nConvert the entire string to lowercase:\n\n```\nlower \"HELLO\"\n```\n\nThe above returns `hello`\n\n### upper\n\nConvert the entire string to uppercase:\n\n```\nupper \"hello\"\n```\n\nThe above returns `HELLO`\n\n### title\n\nConvert to title case:\n\n```\ntitle \"hello world\"\n```\n\nThe above returns `Hello World`\n\n### untitle\n\nRemove title casing. `untitle \"Hello World\"` produces `hello world`.\n\n### repeat\n\nRepeat a string multiple times:\n\n```\nrepeat 3 \"hello\"\n```\n\nThe above returns `hellohellohello`\n\n### substr\n\nGet a substring from a string. It takes three parameters:\n\n- start (int)\n- end (int)\n- string (string)\n\n```\nsubstr 0 5 \"hello world\"\n```\n\nThe above returns `hello`\n\n### nospace\n\nRemove all whitespace from a string.\n\n```\nnospace \"hello w o r l d\"\n```\n\nThe above returns `helloworld`\n\n### trunc\n\nTruncate a string\n\n```\ntrunc 5 \"hello world\"\n```\n\nThe above produces `hello`.\n\n```\ntrunc -5 \"hello world\"\n```\n\nThe above produces `world`.\n\n### abbrev\n\nTruncate a string with ellipses (`...`)\n\nParameters:\n\n- max length\n- the string\n\n```\nabbrev 5 \"hello world\"\n```\n\nThe above returns `he...`, since it counts the width of the ellipses against the\nmaximum length.\n\n### abbrevboth\n\nAbbreviate both sides:\n\n```\nabbrevboth 5 10 \"1234 5678 9123\"\n```\n\nthe above produces `...5678...`\n\nIt takes:\n\n- left offset\n- max length\n- the string\n\n### initials\n\nGiven multiple words, take the first letter of each word and combine.\n\n```\ninitials \"First Try\"\n```\n\nThe above returns `FT`\n\n### randAlphaNum, randAlpha, randNumeric, and randAscii\n\nThese four functions generate cryptographically secure (uses ```crypto/rand```)\nrandom strings, but with different base character sets:\n\n- `randAlphaNum` uses `0-9a-zA-Z`\n- `randAlpha` uses `a-zA-Z`\n- `randNumeric` uses `0-9`\n- `randAscii` uses all printable ASCII characters\n\nEach of them takes one parameter: the integer length of the string.\n\n```\nrandNumeric 3\n```\n\nThe above will produce a random string with three digits.\n\n### wrap\n\nWrap text at a given column count:\n\n```\nwrap 80 $someText\n```\n\nThe above will wrap the string in `$someText` at 80 columns.\n\n### wrapWith\n\n`wrapWith` works as `wrap`, but lets you specify the string to wrap with.\n(`wrap` uses `\\n`)\n\n```\nwrapWith 5 \"\\t\" \"Hello World\"\n```\n\nThe above produces `Hello World` (where the whitespace is an ASCII tab\ncharacter)\n\n### contains\n\nTest to see if one string is contained inside of another:\n\n```\ncontains \"cat\" \"catch\"\n```\n\nThe above returns `true` because `catch` contains `cat`.\n\n### hasPrefix and hasSuffix\n\nThe `hasPrefix` and `hasSuffix` functions test whether a string has a given\nprefix or suffix:\n\n```\nhasPrefix \"cat\" \"catch\"\n```\n\nThe above returns `true` because `catch` has the prefix `cat`.\n\n### quote and squote\n\nThese functions wrap a string in double quotes (`quote`) or single quotes\n(`squote`).\n\n### cat\n\nThe `cat` function concatenates multiple strings together into one, separating\nthem with spaces:\n\n```\ncat \"hello\" \"beautiful\" \"world\"\n```\n\nThe above produces `hello beautiful world`\n\n### indent\n\nThe `indent` function indents every line in a given string to the specified\nindent width. This is useful when aligning multi-line strings:\n\n```\nindent 4 $lots_of_text\n```\n\nThe above will indent every line of text by 4 space characters.\n\n### nindent\n\nThe `nindent` function is the same as the indent function, but prepends a new\nline to the beginning of the string.\n\n```\nnindent 4 $lots_of_text\n```\n\nThe above will indent every line of text by 4 space characters and add a new\nline to the beginning.\n\n### replace\n\nPerform simple string replacement.\n\nIt takes three arguments:\n\n- string to replace\n- string to replace with\n- source string\n\n```\n\"I Am Henry VIII\" | replace \" \" \"-\"\n```\n\nThe above will produce `I-Am-Henry-VIII`\n\n### plural\n\nPluralize a string.\n\n```\nlen $fish | plural \"one anchovy\" \"many anchovies\"\n```\n\nIn the above, if the length of the string is 1, the first argument will be\nprinted (`one anchovy`). Otherwise, the second argument will be printed (`many\nanchovies`).\n\nThe arguments are:\n\n- singular string\n- plural string\n- length integer\n\nNOTE: Helm does not currently support languages with more complex pluralization\nrules. And `0` is considered a plural because the English language treats it as\nsuch (`zero anchovies`).\n\n### snakecase\n\nConvert string from camelCase to snake_case.\n\n```\nsnakecase \"FirstName\"\n```\n\nThis above will produce `first_name`.\n\n### camelcase\n\nConvert string from snake_case to CamelCase\n\n```\ncamelcase \"http_server\"\n```\n\nThis above will produce `HttpServer`.\n\n### kebabcase\n\nConvert string from camelCase to kebab-case.\n\n```\nkebabcase \"FirstName\"\n```\n\nThis above will produce `first-name`.\n\n### swapcase\n\nSwap the case of a string using a word based algorithm.\n\nConversion algorithm:\n\n- Upper case character converts to Lower case\n- Title case character converts to Lower case\n- Lower case character after Whitespace or at start converts to Title case\n- Other Lower case character converts to Upper case\n- Whitespace is defined by unicode.IsSpace(char)\n\n```\nswapcase \"This Is A.Test\"\n```\n\nThis above will produce `tHIS iS a.tEST`.\n\n### shuffle\n\nShuffle a string.\n\n```\nshuffle \"hello\"\n```\n\nThe above will randomize the letters in `hello`, perhaps producing `oelhl`.\n\n## Type Conversion Functions\n\nThe following type conversion functions are provided by Helm:\n\n- `atoi`: Convert a string to an integer.\n- `float64`: Convert to a `float64`.\n- `int`: Convert to an `int` at the system's width.\n- `int64`: Convert to an `int64`.\n- `toDecimal`: Convert a unix octal to a `int64`.\n- `toString`: Convert to a string.\n- `toStrings`: Convert a list, slice, or array to a list of strings.\n- `toJson` (`mustToJson`): Convert list, slice, array, dict, or object to JSON.\n- `toPrettyJson` (`mustToPrettyJson`): Convert list, slice, array, dict, or\n  object to indented JSON.\n- `toRawJson` (`mustToRawJson`): Convert list, slice, array, dict, or object to\n  JSON with HTML characters unescaped.\n- `fromYaml`: Convert a YAML string to an object.\n- `fromJson`: Convert a JSON string to an object.\n- `fromJsonArray`: Convert a JSON array to a list.\n- `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\n- `toYamlPretty`: Convert list, slice, array, dict, or object to indented yaml. Equivalent to `toYaml` but will additionally indent lists by 2 spaces.\n- `toToml`: Convert list, slice, array, dict, or object to toml, can be used to copy chunks of toml from any source.\n- `fromYamlArray`: Convert a YAML array to a list.\n\nOnly `atoi` requires that the input be a specific type. The others will attempt\nto convert from any type to the destination type. For example, `int64` can\nconvert floats to ints, and it can also convert strings to ints.\n\n### toStrings\n\nGiven a list-like collection, produce a slice of strings.\n\n```\nlist 1 2 3 | toStrings\n```\n\nThe above converts `1` to `\"1\"`, `2` to `\"2\"`, and so on, and then returns them\nas a list.\n\n### toDecimal\n\nGiven a unix octal permission, produce a decimal.\n\n```\n\"0777\" | toDecimal\n```\n\nThe above converts `0777` to `511` and returns the value as an int64.\n\n### toJson, mustToJson\n\nThe `toJson` function encodes an item into a JSON string. If the item cannot be\nconverted to JSON the function will return an empty string. `mustToJson` will\nreturn an error in case the item cannot be encoded in JSON.\n\n```\ntoJson .Item\n```\n\nThe above returns JSON string representation of `.Item`.\n\n### toPrettyJson, mustToPrettyJson\n\nThe `toPrettyJson` function encodes an item into a pretty (indented) JSON\nstring.\n\n```\ntoPrettyJson .Item\n```\n\nThe above returns indented JSON string representation of `.Item`.\n\n### toRawJson, mustToRawJson\n\nThe `toRawJson` function encodes an item into JSON string with HTML characters\nunescaped.\n\n```\ntoRawJson .Item\n```\n\nThe above returns unescaped JSON string representation of `.Item`.\n\n### fromYaml\n\nThe `fromYaml` function takes a YAML string and returns an object that can be used in templates.\n\n`File at: yamls/person.yaml`\n```yaml\nname: Bob\nage: 25\nhobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n```yaml\n{{- $person := .Files.Get \"yamls/person.yaml\" | fromYaml }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n### fromJson\n\nThe `fromJson` function takes a JSON string and returns an object that can be used in templates.\n\n`File at: jsons/person.json`\n```json\n{\n  \"name\": \"Bob\",\n  \"age\": 25,\n  \"hobbies\": [\n    \"hiking\",\n    \"fishing\",\n    \"cooking\"\n  ]\n}\n```\n```yaml\n{{- $person := .Files.Get \"jsons/person.json\" | fromJson }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n  My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}.\n```\n\n\n### fromJsonArray\n\nThe `fromJsonArray` function takes a JSON Array and returns a list that can be used in templates.\n\n`File at: jsons/people.json`\n```json\n[\n { \"name\": \"Bob\",\"age\": 25 },\n { \"name\": \"Ram\",\"age\": 16 }\n]\n```\n```yaml\n{{- $people := .Files.Get \"jsons/people.json\" | fromJsonArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n### toYaml, toYamlPretty\n\nThe `toYaml` and `toYamlPretty` functions encode an object (list, slice, array, dict, or object) into an indented YAML string.\n\n> Note that `toYamlPretty` is functionally equivalent but will output YAML with additional indents for list elements\n\n```yaml\n# toYaml\n- name: bob\n  age: 25\n  hobbies:\n  - hiking\n  - fishing\n  - cooking\n```\n\n```yaml\n# toYamlPretty\n- name: bob\n  age: 25\n  hobbies:\n    - hiking\n    - fishing\n    - cooking\n```\n\n### fromYamlArray\n\nThe `fromYamlArray` function takes a YAML Array and returns a list that can be used in templates.\n\n`File at: yamls/people.yml`\n```yaml\n- name: Bob\n  age: 25\n- name: Ram\n  age: 16\n```\n```yaml\n{{- $people := .Files.Get \"yamls/people.yml\" | fromYamlArray }}\n{{- range $person := $people }}\ngreeting: |\n  Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old.\n{{ end }}\n```\n\n\n## Regular Expressions\n\nHelm includes the following regular expression functions: [regexFind\n(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll\n(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch\n(mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll\n(mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall),\n[regexReplaceAllLiteral\n(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral),\n[regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit).\n\n### regexMatch, mustRegexMatch\n\nReturns true if the input string contains any match of the regular expression.\n\n```\nregexMatch \"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\\\.[A-Za-z]{2,}$\" \"test@acme.com\"\n```\n\nThe above produces `true`\n\n`regexMatch` panics if there is a problem and `mustRegexMatch` returns an error\nto the template engine if there is a problem.\n\n### regexFindAll, mustRegexFindAll\n\nReturns a slice of all matches of the regular expression in the input string.\nThe last parameter n determines the number of substrings to return, where -1\nmeans return all matches\n\n```\nregexFindAll \"[2,4,6,8]\" \"123456789\" -1\n```\n\nThe above produces `[2 4 6 8]`\n\n`regexFindAll` panics if there is a problem and `mustRegexFindAll` returns an\nerror to the template engine if there is a problem.\n\n### regexFind, mustRegexFind\n\nReturn the first (left most) match of the regular expression in the input string\n\n```\nregexFind \"[a-zA-Z][1-9]\" \"abcd1234\"\n```\n\nThe above produces `d1`\n\n`regexFind` panics if there is a problem and `mustRegexFind` returns an error to\nthe template engine if there is a problem.\n\n### regexReplaceAll, mustRegexReplaceAll\n\nReturns a copy of the input string, replacing matches of the Regexp with the\nreplacement string replacement. Inside string replacement, $ signs are\ninterpreted as in Expand, so for instance $1 represents the text of the first\nsubmatch. The first argument is `<pattern>`, second is `<input>`,\nand third is `<replacement>`.\n\n```\nregexReplaceAll \"a(x*)b\" \"-ab-axxb-\" \"${1}W\"\n```\n\nThe above produces `-W-xxW-`\n\n`regexReplaceAll` panics if there is a problem and `mustRegexReplaceAll` returns\nan error to the template engine if there is a problem.\n\n### regexReplaceAllLiteral, mustRegexReplaceAllLiteral\n\nReturns a copy of the input string, replacing matches of the Regexp with the\nreplacement string replacement. The replacement string is substituted directly,\nwithout using Expand. The first argument is `<pattern>`, second is `<input>`,\nand third is `<replacement>`.\n\n```\nregexReplaceAllLiteral \"a(x*)b\" \"-ab-axxb-\" \"${1}\"\n```\n\nThe above produces `-${1}-${1}-`\n\n`regexReplaceAllLiteral` panics if there is a problem and\n`mustRegexReplaceAllLiteral` returns an error to the template engine if there is\na problem.\n\n### regexSplit, mustRegexSplit\n\nSlices the input string into substrings separated by the expression and returns\na slice of the substrings between those expression matches. The last parameter\n`n` determines the number of substrings to return, where `-1` means return all\nmatches\n\n```\nregexSplit \"z+\" \"pizza\" -1\n```\n\nThe above produces `[pi a]`\n\n`regexSplit` panics if there is a problem and `mustRegexSplit` returns an error\nto the template engine if there is a problem.\n\n## Cryptographic and Security Functions\n\nHelm provides some advanced cryptographic functions. They include\n[adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert),\n[decryptAES](#decryptaes), [derivePassword](#derivepassword),\n[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey),\n[genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert),\n[htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum), and\n[sha256sum](#sha256sum).\n\n### sha1sum\n\nThe `sha1sum` function receives a string, and computes it's SHA1 digest.\n\n```\nsha1sum \"Hello world!\"\n```\n\n### sha256sum\n\nThe `sha256sum` function receives a string, and computes it's SHA256 digest.\n\n```\nsha256sum \"Hello world!\"\n```\n\nThe above will compute the SHA 256 sum in an \"ASCII armored\" format that is safe\nto print.\n\n### adler32sum\n\nThe `adler32sum` function receives a string, and computes its Adler-32 checksum.\n\n```\nadler32sum \"Hello world!\"\n```\n\n### htpasswd\n\nThe `htpasswd` function takes a `username` and `password` and generates a\n`bcrypt` hash of the password. The result can be used for basic authentication\non an [Apache HTTP\nServer](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic).\n\n```\nhtpasswd \"myUser\" \"myPassword\"\n```\n\nNote that it is insecure to store the password directly in the template.\n\n### randBytes\n\nThe randBytes function accepts a count N and generates a cryptographically\nsecure (uses crypto/rand) random sequence of N bytes. The sequence is returned\nas a base64 encoded string.\n\n```\nrandBytes 24\n```\n\n### derivePassword\n\nThe `derivePassword` function can be used to derive a specific password based on\nsome shared \"master password\" constraints. The algorithm for this is [well\nspecified](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf).\n\n```\nderivePassword 1 \"long\" \"password\" \"user\" \"example.com\"\n```\n\nNote that it is considered insecure to store the parts directly in the template.\n\n### genPrivateKey\n\nThe `genPrivateKey` function generates a new private key encoded into a PEM\nblock.\n\nIt takes one of the values for its first param:\n\n- `ecdsa`: Generate an elliptic curve DSA key (P256)\n- `dsa`: Generate a DSA key (L2048N256)\n- `rsa`: Generate an RSA 4096 key\n\n### buildCustomCert\n\nThe `buildCustomCert` function allows customizing the certificate.\n\nIt takes the following string parameters:\n\n- A base64 encoded PEM format certificate\n- A base64 encoded PEM format private key\n\nIt returns a certificate object with the following attributes:\n\n- `Cert`: A PEM-encoded certificate\n- `Key`: A PEM-encoded private key\n\nExample:\n\n```\n$ca := buildCustomCert \"base64-encoded-ca-crt\" \"base64-encoded-ca-key\"\n```\n\nNote that the returned object can be passed to the `genSignedCert` function to\nsign a certificate using this CA.\n\n### genCA\n\nThe `genCA` function generates a new, self-signed x509 certificate authority.\n\nIt takes the following parameters:\n\n- Subject's common name (cn)\n- Cert validity duration in days\n\nIt returns an object with the following attributes:\n\n- `Cert`: A PEM-encoded certificate\n- `Key`: A PEM-encoded private key\n\nExample:\n\n```\n$ca := genCA \"foo-ca\" 365\n```\n\nNote that the returned object can be passed to the `genSignedCert` function to\nsign a certificate using this CA.\n\n### genSelfSignedCert\n\nThe `genSelfSignedCert` function generates a new, self-signed x509 certificate.\n\nIt takes the following parameters:\n\n- Subject's common name (cn)\n- Optional list of IPs; may be nil\n- Optional list of alternate DNS names; may be nil\n- Cert validity duration in days\n\nIt returns an object with the following attributes:\n\n- `Cert`: A PEM-encoded certificate\n- `Key`: A PEM-encoded private key\n\nExample:\n\n```\n$cert := genSelfSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365\n```\n\n### genSignedCert\n\nThe `genSignedCert` function generates a new, x509 certificate signed by the\nspecified CA.\n\nIt takes the following parameters:\n\n- Subject's common name (cn)\n- Optional list of IPs; may be nil\n- Optional list of alternate DNS names; may be nil\n- Cert validity duration in days\n- CA (see `genCA`)\n\nExample:\n\n```\n$ca := genCA \"foo-ca\" 365\n$cert := genSignedCert \"foo.com\" (list \"10.0.0.1\" \"10.0.0.2\") (list \"bar.com\" \"bat.com\") 365 $ca\n```\n\n### encryptAES\n\nThe `encryptAES` function encrypts text with AES-256 CBC and returns a base64\nencoded string.\n\n```\nencryptAES \"secretkey\" \"plaintext\"\n```\n\n### decryptAES\n\nThe `decryptAES` function receives a base64 string encoded by the AES-256 CBC\nalgorithm and returns the decoded text.\n\n```\n\"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=\" | decryptAES \"secretkey\"\n```\n\n## Date Functions\n\nHelm includes the following date functions you can use in templates:\n[ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify\n(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration),\n[durationRound](#durationround), [htmlDate](#htmldate),\n[htmlDateInZone](#htmldateinzone), [now](#now), [toDate\n(mustToDate)](#todate-musttodate), and [unixEpoch](#unixepoch).\n\n### now\n\nThe current date/time. Use this in conjunction with other date functions.\n\n### ago\n\nThe `ago` function returns duration from time. Now in seconds resolution.\n\n```\nago .CreatedAt\n```\n\nreturns in `time.Duration` String() format\n\n```\n2h34m7s\n```\n\n### date\n\nThe `date` function formats a date.\n\nFormat the date to YEAR-MONTH-DAY:\n\n```\nnow | date \"2006-01-02\"\n```\n\nDate formatting in Go is a [little bit\ndifferent](https://pauladamsmith.com/blog/2011/05/go_time.html).\n\nIn short, take this as the base date:\n\n```\nMon Jan 2 15:04:05 MST 2006\n```\n\nWrite it in the format you want. Above, `2006-01-02` is the same date, but in\nthe format we want.\n\n### dateInZone\n\nSame as `date`, but with a timezone.\n\n```\ndateInZone \"2006-01-02\" (now) \"UTC\"\n```\n\n### duration\n\nFormats a given amount of seconds as a `time.Duration`.\n\nThis returns 1m35s\n\n```\nduration \"95\"\n```\n\n### durationRound\n\nRounds a given duration to the most significant unit. Strings and\n`time.Duration` gets parsed as a duration, while a `time.Time` is calculated as\nthe duration since.\n\nThis return 2h\n\n```\ndurationRound \"2h10m5s\"\n```\n\nThis returns 3mo\n\n```\ndurationRound \"2400h10m5s\"\n```\n\n### unixEpoch\n\nReturns the seconds since the unix epoch for a `time.Time`.\n\n```\nnow | unixEpoch\n```\n\n### dateModify, mustDateModify\n\nThe `dateModify` takes a modification and a date and returns the timestamp.\n\nSubtract an hour and thirty minutes from the current time:\n\n```\nnow | dateModify \"-1.5h\"\n```\n\nIf the modification format is wrong `dateModify` will return the date\nunmodified. `mustDateModify` will return an error otherwise.\n\n### htmlDate\n\nThe `htmlDate` function formats a date for inserting into an HTML date picker\ninput field.\n\n```\nnow | htmlDate\n```\n\n### htmlDateInZone\n\nSame as htmlDate, but with a timezone.\n\n```\nhtmlDateInZone (now) \"UTC\"\n```\n\n### toDate, mustToDate\n\n`toDate` converts a string to a date. The first argument is the date layout and\nthe second the date string. If the string can't be convert it returns the zero\nvalue. `mustToDate` will return an error in case the string cannot be converted.\n\nThis is useful when you want to convert a string date to another format (using\npipe). The example below converts \"2017-12-31\" to \"31/12/2017\".\n\n```\ntoDate \"2006-01-02\" \"2017-12-31\" | date \"02/01/2006\"\n```\n\n## Dictionaries and Dict Functions\n\nHelm provides a key/value storage type called a `dict` (short for \"dictionary\",\nas in Python). A `dict` is an _unordered_ type.\n\nThe key to a dictionary **must be a string**. However, the value can be any\ntype, even another `dict` or `list`.\n\nUnlike `list`s, `dict`s are not immutable. The `set` and `unset` functions will\nmodify the contents of a dictionary.\n\nHelm provides the following functions to support working with dicts: [deepCopy\n(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get),\n[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge),\n[mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite),\n[omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), and\n[values](#values).\n\n### dict\n\nCreating dictionaries is done by calling the `dict` function and passing it a\nlist of pairs.\n\nThe following creates a dictionary with three items:\n\n```\n$myDict := dict \"name1\" \"value1\" \"name2\" \"value2\" \"name3\" \"value 3\"\n```\n\n### get\n\nGiven a map and a key, get the value from the map.\n\n```\nget $myDict \"name1\"\n```\n\nThe above returns `\"value1\"`\n\nNote that if the key is not found, this operation will simply return `\"\"`. No\nerror will be generated.\n\n### set\n\nUse `set` to add a new key/value pair to a dictionary.\n\n```\n$_ := set $myDict \"name4\" \"value4\"\n```\n\nNote that `set` _returns the dictionary_ (a requirement of Go template\nfunctions), so you may need to trap the value as done above with the `$_`\nassignment.\n\n### unset\n\nGiven a map and a key, delete the key from the map.\n\n```\n$_ := unset $myDict \"name4\"\n```\n\nAs with `set`, this returns the dictionary.\n\nNote that if the key is not found, this operation will simply return. No error\nwill be generated.\n\n### hasKey\n\nThe `hasKey` function returns `true` if the given dict contains the given key.\n\n```\nhasKey $myDict \"name1\"\n```\n\nIf the key is not found, this returns `false`.\n\n### pluck\n\nThe `pluck` function makes it possible to give one key and multiple maps, and\nget a list of all of the matches:\n\n```\npluck \"name1\" $myDict $myOtherDict\n```\n\nThe above will return a `list` containing every found value (`[value1\notherValue1]`).\n\nIf the given key is _not found_ in a map, that map will not have an item in the\nlist (and the length of the returned list will be less than the number of dicts\nin the call to `pluck`).\n\nIf the key is _found_ but the value is an empty value, that value will be\ninserted.\n\nA common idiom in Helm templates is to use `pluck... | first` to get the first\nmatching key out of a collection of dictionaries.\n\n### dig\n\nThe `dig` function traverses a nested set of dicts, selecting keys from a list\nof values. It returns a default value if any of the keys are not found at the\nassociated dict.\n\n```\ndig \"user\" \"role\" \"humanName\" \"guest\" $dict\n```\n\nGiven a dict structured like\n```\n{\n  user: {\n    role: {\n      humanName: \"curator\"\n    }\n  }\n}\n```\n\nthe above would return `\"curator\"`. If the dict lacked even a `user` field,\nthe result would be `\"guest\"`.\n\nDig can be very useful in cases where you'd like to avoid guard clauses,\nespecially since Go's template package's `and` doesn't shortcut. For instance\n`and a.maybeNil a.maybeNil.iNeedThis` will always evaluate\n`a.maybeNil.iNeedThis`, and panic if `a` lacks a `maybeNil` field.)\n\n`dig` accepts its dict argument last in order to support pipelining. For instance:\n```\nmerge a b c | dig \"one\" \"two\" \"three\" \"<missing>\"\n```\n\n### merge, mustMerge\n\nMerge two or more dictionaries into one, giving precedence to the dest\ndictionary:\n\nGiven:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nwill result in:\n\n```\nnewdict:\n  default: default\n  overwrite: me\n  key: true\n```\n```\n$newdict := merge $dest $source1 $source2\n```\n\nThis is a deep merge operation but not a deep copy operation. Nested objects\nthat are merged are the same instance on both dicts. If you want a deep copy\nalong with the merge, then use the `deepCopy` function along with merging. For\nexample,\n\n```\ndeepCopy $source | merge $dest\n```\n\n`mustMerge` will return an error in case of unsuccessful merge.\n\n### mergeOverwrite, mustMergeOverwrite\n\nMerge two or more dictionaries into one, giving precedence from **right to\nleft**, effectively overwriting values in the dest dictionary:\n\nGiven:\n\n```\ndest:\n  default: default\n  overwrite: me\n  key: true\n\nsrc:\n  overwrite: overwritten\n  key: false\n```\n\nwill result in:\n\n```\nnewdict:\n  default: default\n  overwrite: overwritten\n  key: false\n```\n\n```\n$newdict := mergeOverwrite $dest $source1 $source2\n```\n\nThis is a deep merge operation but not a deep copy operation. Nested objects\nthat are merged are the same instance on both dicts. If you want a deep copy\nalong with the merge then use the `deepCopy` function along with merging. For\nexample,\n\n```\ndeepCopy $source | mergeOverwrite $dest\n```\n\n`mustMergeOverwrite` will return an error in case of unsuccessful merge.\n\n### keys\n\nThe `keys` function will return a `list` of all of the keys in one or more\n`dict` types. Since a dictionary is _unordered_, the keys will not be in a\npredictable order. They can be sorted with `sortAlpha`.\n\n```\nkeys $myDict | sortAlpha\n```\n\nWhen supplying multiple dictionaries, the keys will be concatenated. Use the\n`uniq` function along with `sortAlpha` to get a unique, sorted list of keys.\n\n```\nkeys $myDict $myOtherDict | uniq | sortAlpha\n```\n\n### pick\n\nThe `pick` function selects just the given keys out of a dictionary, creating a\nnew `dict`.\n\n```\n$new := pick $myDict \"name1\" \"name2\"\n```\n\nThe above returns `{name1: value1, name2: value2}`\n\n### omit\n\nThe `omit` function is similar to `pick`, except it returns a new `dict` with\nall the keys that _do not_ match the given keys.\n\n```\n$new := omit $myDict \"name1\" \"name3\"\n```\n\nThe above returns `{name2: value2}`\n\n### values\n\nThe `values` function is similar to `keys`, except it returns a new `list` with\nall the values of the source `dict` (only one dictionary is supported).\n\n```\n$vals := values $myDict\n```\n\nThe above returns `list[\"value1\", \"value2\", \"value 3\"]`. Note that the `values`\nfunction gives no guarantees about the result ordering; if you care about this,\nthen use `sortAlpha`.\n\n### deepCopy, mustDeepCopy\n\nThe `deepCopy` and `mustDeepCopy` functions take a value and make a deep copy\nof the value. This includes dicts and other structures. `deepCopy` panics when\nthere is a problem, while `mustDeepCopy` returns an error to the template system\nwhen there is an error.\n\n```\ndict \"a\" 1 \"b\" 2 | deepCopy\n```\n\n### A Note on Dict Internals\n\nA `dict` is implemented in Go as a `map[string]interface{}`. Go developers can\npass `map[string]interface{}` values into the context to make them available to\ntemplates as `dict`s.\n\n## Encoding Functions\n\nHelm has the following encoding and decoding functions:\n\n- `b64enc`/`b64dec`: Encode or decode with Base64\n- `b32enc`/`b32dec`: Encode or decode with Base32\n\n## Lists and List Functions\n\nHelm provides a simple `list` type that can contain arbitrary sequential lists\nof data. This is similar to arrays or slices, but lists are designed to be used\nas immutable data types.\n\nCreate a list of integers:\n\n```\n$myList := list 1 2 3 4 5\n```\n\nThe above creates a list of `[1 2 3 4 5]`.\n\nHelm provides the following list functions: [append\n(mustAppend)](#append-mustappend), [chunk](#chunk), [compact\n(mustCompact)](#compact-mustcompact), [concat](#concat), [first\n(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial\n(mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast),\n[prepend (mustPrepend)](#prepend-mustprepend), [rest\n(mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse),\n[seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq\n(mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), and\n[without (mustWithout)](#without-mustwithout).\n\n### first, mustFirst\n\nTo get the head item on a list, use `first`.\n\n`first $myList` returns `1`\n\n`first` panics if there is a problem, while `mustFirst` returns an error to the\ntemplate engine if there is a problem.\n\n### rest, mustRest\n\nTo get the tail of the list (everything but the first item), use `rest`.\n\n`rest $myList` returns `[2 3 4 5]`\n\n`rest` panics if there is a problem, while `mustRest` returns an error to the\ntemplate engine if there is a problem.\n\n### last, mustLast\n\nTo get the last item on a list, use `last`:\n\n`last $myList` returns `5`. This is roughly analogous to reversing a list and\nthen calling `first`.\n\n### initial, mustInitial\n\nThis compliments `last` by returning all _but_ the last element. `initial\n$myList` returns `[1 2 3 4]`.\n\n`initial` panics if there is a problem, while `mustInitial` returns an error to\nthe template engine if there is a problem.\n\n### append, mustAppend\n\nAppend a new item to an existing list, creating a new list.\n\n```\n$new = append $myList 6\n```\n\nThe above would set `$new` to `[1 2 3 4 5 6]`. `$myList` would remain unaltered.\n\n`append` panics if there is a problem, while `mustAppend` returns an error to the\ntemplate engine if there is a problem.\n\n### prepend, mustPrepend\n\nPush an element onto the front of a list, creating a new list.\n\n```\nprepend $myList 0\n```\n\nThe above would produce `[0 1 2 3 4 5]`. `$myList` would remain unaltered.\n\n`prepend` panics if there is a problem, while `mustPrepend` returns an error to\nthe template engine if there is a problem.\n\n### concat\n\nConcatenate arbitrary number of lists into one.\n\n```\nconcat $myList ( list 6 7 ) ( list 8 )\n```\n\nThe above would produce `[1 2 3 4 5 6 7 8]`. `$myList` would remain unaltered.\n\n### reverse, mustReverse\n\nProduce a new list with the reversed elements of the given list.\n\n```\nreverse $myList\n```\n\nThe above would generate the list `[5 4 3 2 1]`.\n\n`reverse` panics if there is a problem, while `mustReverse` returns an error to\nthe template engine if there is a problem.\n\n### uniq, mustUniq\n\nGenerate a list with all of the duplicates removed.\n\n```\nlist 1 1 1 2 | uniq\n```\n\nThe above would produce `[1 2]`\n\n`uniq` panics if there is a problem, while `mustUniq` returns an error to the\ntemplate engine if there is a problem.\n\n### without, mustWithout\n\nThe `without` function filters items out of a list.\n\n```\nwithout $myList 3\n```\n\nThe above would produce `[1 2 4 5]`\n\n`without` can take more than one filter:\n\n```\nwithout $myList 1 3 5\n```\n\nThat would produce `[2 4]`\n\n`without` panics if there is a problem, while `mustWithout` returns an error to\nthe template engine if there is a problem.\n\n### has, mustHas\n\nTest to see if a list has a particular element.\n\n```\nhas 4 $myList\n```\n\nThe above would return `true`, while `has \"hello\" $myList` would return false.\n\n`has` panics if there is a problem, while `mustHas` returns an error to the\ntemplate engine if there is a problem.\n\n### compact, mustCompact\n\nAccepts a list and removes entries with empty values.\n\n```\n$list := list 1 \"a\" \"foo\" \"\"\n$copy := compact $list\n```\n\n`compact` will return a new list with the empty (i.e., \"\") item removed.\n\n`compact` panics if there is a problem and `mustCompact` returns an error to the\ntemplate engine if there is a problem.\n\n### index\n\nTo get the nth element of a list, use `index list [n]`. To index into \nmulti-dimensional lists, use `index list [n] [m] ...`\n- `index $myList 0` returns `1`. It is the same as `myList[0]`\n- `index $myList 0 1` would be the same as `myList[0][1]`\n\n### slice, mustSlice\n\nTo get partial elements of a list, use `slice list [n] [m]`. It is equivalent of\n`list[n:m]`.\n\n- `slice $myList` returns `[1 2 3 4 5]`. It is same as `myList[:]`.\n- `slice $myList 3` returns `[4 5]`. It is same as `myList[3:]`.\n- `slice $myList 1 3` returns `[2 3]`. It is same as `myList[1:3]`.\n- `slice $myList 0 3` returns `[1 2 3]`. It is same as `myList[:3]`.\n\n`slice` panics if there is a problem, while `mustSlice` returns an error to the\ntemplate engine if there is a problem.\n\n### until\n\nThe `until` function builds a range of integers.\n\n```\nuntil 5\n```\n\nThe above generates the list `[0, 1, 2, 3, 4]`.\n\nThis is useful for looping with `range $i, $e := until 5`.\n\n### untilStep\n\nLike `until`, `untilStep` generates a list of counting integers. But it allows\nyou to define a start, stop, and step:\n\n```\nuntilStep 3 6 2\n```\n\nThe above will produce `[3 5]` by starting with 3, and adding 2 until it is\nequal or greater than 6. This is similar to Python's `range` function.\n\n### seq\n\nWorks like the bash `seq` command.\n\n* 1 parameter  (end) - will generate all counting integers between 1 and `end`\n  inclusive.\n* 2 parameters (start, end) - will generate all counting integers between\n  `start` and `end` inclusive incrementing or decrementing by 1.\n* 3 parameters (start, step, end) - will generate all counting integers between\n  `start` and `end` inclusive incrementing or decrementing by `step`.\n\n```\nseq 5       => 1 2 3 4 5\nseq -3      => 1 0 -1 -2 -3\nseq 0 2     => 0 1 2\nseq 2 -2    => 2 1 0 -1 -2\nseq 0 2 10  => 0 2 4 6 8 10\nseq 0 -2 -5 => 0 -2 -4\n```\n\n### chunk\n\nTo split a list into chunks of given size, use `chunk size list`. This is useful for pagination.\n\n```\nchunk 3 (list 1 2 3 4 5 6 7 8)\n```\n\nThis produces list of lists `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`.\n\n## Math Functions\n\nAll math functions operate on `int64` values unless specified otherwise.\n\nThe following math functions are available: [add](#add), [add1](#add1),\n[ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max),\n[min](#min), [mod](#mod), [mul](#mul), [round](#round), and [sub](#sub).\n\n### add\n\nSum numbers with `add`. Accepts two or more inputs.\n\n```\nadd 1 2 3\n```\n\n### add1\n\nTo increment by 1, use `add1`.\n\n### sub\n\nTo subtract, use `sub`.\n\n### div\n\nPerform integer division with `div`.\n\n### mod\n\nModulo with `mod`.\n\n### mul\n\nMultiply with `mul`. Accepts two or more inputs.\n\n```\nmul 1 2 3\n```\n\n### max\n\nReturn the largest of a series of integers.\n\nThis will return `3`:\n\n```\nmax 1 2 3\n```\n\n### min\n\nReturn the smallest of a series of integers.\n\n`min 1 2 3` will return `1`.\n\n### len\n\nReturns the length of the argument as an integer.\n\n```\nlen .Arg\n```\n\n## Float Math Functions\n\nAll math functions operate on `float64` values.\n\n### addf\n\nSum numbers with `addf`\n\nThis will return `5.5`:\n\n```\naddf 1.5 2 2\n```\n\n### add1f\n\nTo increment by 1, use `add1f`\n\n### subf\n\nTo subtract, use `subf`\n\nThis is equivalent to `7.5 - 2 - 3` and will return `2.5`:\n\n```\nsubf 7.5 2 3\n```\n\n### divf\n\nPerform integer division with `divf`\n\nThis is equivalent to `10 / 2 / 4` and will return `1.25`:\n\n```\ndivf 10 2 4\n```\n\n### mulf\n\nMultiply with `mulf`\n\nThis will return `6`:\n\n```\nmulf 1.5 2 2\n```\n\n### maxf\n\nReturn the largest of a series of floats:\n\nThis will return `3`:\n\n```\nmaxf 1 2.5 3\n```\n\n### minf\n\nReturn the smallest of a series of floats.\n\nThis will return `1.5`:\n\n```\nminf 1.5 2 3\n```\n\n### floor\n\nReturns the greatest float value less than or equal to input value.\n\n`floor 123.9999` will return `123.0`.\n\n### ceil\n\nReturns the greatest float value greater than or equal to input value.\n\n`ceil 123.001` will return `124.0`.\n\n### round\n\nReturns a float value with the remainder rounded to the given number to digits\nafter the decimal point.\n\n`round 123.555555 3` will return `123.556`.\n\n## Network Functions\n\nHelm has a single network function, `getHostByName`.\n\nThe `getHostByName` receives a domain name and returns the ip address.\n\n`getHostByName \"www.google.com\"` would return the corresponding ip address of `www.google.com`.\n\nThis function requires the `--enable-dns` option to be passed on the helm command line.\n\n## File Path Functions\n\nWhile Helm template functions do not grant access to the filesystem, they do\nprovide functions for working with strings that follow file path conventions.\nThose include [base](#base), [clean](#clean), [dir](#dir), [ext](#ext), and\n[isAbs](#isabs).\n\n### base\n\nReturn the last element of a path.\n\n```\nbase \"foo/bar/baz\"\n```\n\nThe above prints \"baz\".\n\n### dir\n\nReturn the directory, stripping the last part of the path. So `dir\n\"foo/bar/baz\"` returns `foo/bar`.\n\n### clean\n\nClean up a path.\n\n```\nclean \"foo/bar/../baz\"\n```\n\nThe above resolves the `..` and returns `foo/baz`.\n\n### ext\n\nReturn the file extension.\n\n```\next \"foo.bar\"\n```\n\nThe above returns `.bar`.\n\n### isAbs\n\nTo check whether a file path is absolute, use `isAbs`.\n\n## Reflection Functions\n\nHelm provides rudimentary reflection tools. These help advanced template\ndevelopers understand the underlying Go type information for a particular value.\nHelm is written in Go and is strongly typed. The type system applies within\ntemplates.\n\nGo has several primitive _kinds_, like `string`, `slice`, `int64`, and `bool`.\n\nGo has an open _type_ system that allows developers to create their own types.\n\nHelm provides a set of functions for each via [kind functions](#kind-functions)\nand [type functions](#type-functions). A [deepEqual](#deepequal) function is\nalso provided to compare to values.\n\n### Kind Functions\n\nThere are two Kind functions: `kindOf` returns the kind of an object.\n\n```\nkindOf \"hello\"\n```\n\nThe above would return `string`. For simple tests (like in `if` blocks), the\n`kindIs` function will let you verify that a value is a particular kind:\n\n```\nkindIs \"int\" 123\n```\n\nThe above will return `true`.\n\n### Type Functions\n\nTypes are slightly harder to work with, so there are three different functions:\n\n- `typeOf` returns the underlying type of a value: `typeOf $foo`\n- `typeIs` is like `kindIs`, but for types: `typeIs \"*io.Buffer\" $myVal`\n- `typeIsLike` works as `typeIs`, except that it also dereferences pointers\n\n**Note:** None of these can test whether or not something implements a given\ninterface, since doing so would require compiling the interface in ahead of\ntime.\n\n### deepEqual\n\n`deepEqual` returns true if two values are [\"deeply\nequal\"](https://golang.org/pkg/reflect/#DeepEqual)\n\nWorks for non-primitive types as well (compared to the built-in `eq`).\n\n```\ndeepEqual (list 1 2 3) (list 1 2 3)\n```\n\nThe above will return `true`.\n\n## Semantic Version Functions\n\nSome version schemes are easily parseable and comparable. Helm provides\nfunctions for working with [SemVer 2](http://semver.org) versions. These include\n[semver](#semver) and [semverCompare](#semvercompare). Below you will also find\ndetails on using ranges for comparisons.\n\n### semver\n\nThe `semver` function parses a string into a Semantic Version:\n\n```\n$version := semver \"1.2.3-alpha.1+123\"\n```\n\n_If the parser fails, it will cause template execution to halt with an error._\n\nAt this point, `$version` is a pointer to a `Version` object with the following\nproperties:\n\n- `$version.Major`: The major number (`1` above)\n- `$version.Minor`: The minor number (`2` above)\n- `$version.Patch`: The patch number (`3` above)\n- `$version.Prerelease`: The prerelease (`alpha.1` above)\n- `$version.Metadata`: The build metadata (`123` above)\n- `$version.Original`: The original version as a string\n\nAdditionally, you can compare a `Version` to another `version` using the\n`Compare` function:\n\n```\nsemver \"1.4.3\" | (semver \"1.2.3\").Compare\n```\n\nThe above will return `-1`.\n\nThe return values are:\n\n- `-1` if the given semver is greater than the semver whose `Compare` method was\n  called\n- `1` if the version who's `Compare` function was called is greater.\n- `0` if they are the same version\n\n(Note that in SemVer, the `Metadata` field is not compared during version\ncomparison operations.)\n\n### semverCompare\n\nA more robust comparison function is provided as `semverCompare`. This version\nsupports version ranges:\n\n- `semverCompare \"1.2.3\" \"1.2.3\"` checks for an exact match\n- `semverCompare \"~1.2.0\" \"1.2.3\"` checks that the major and minor versions\n  match, and that the patch number of the second version is _greater than or\n  equal to_ the first parameter.\n\nThe SemVer functions use the [Masterminds semver\nlibrary](https://github.com/Masterminds/semver), from the creators of Sprig.\n\n### Basic Comparisons\n\nThere are two elements to the comparisons. First, a comparison string is a list\nof space or comma separated AND comparisons. These are then separated by || (OR)\ncomparisons. For example, `\">= 1.2 < 3.0.0 || >= 4.2.3\"` is looking for a\ncomparison that's greater than or equal to 1.2 and less than 3.0.0 or is greater\nthan or equal to 4.2.3.\n\nThe basic comparisons are:\n\n- `=`: equal (aliased to no operator)\n- `!=`: not equal\n- `>`: greater than\n- `<`: less than\n- `>=`: greater than or equal to\n- `<=`: less than or equal to\n\n### Working With Prerelease Versions\n\nPre-releases, for those not familiar with them, are used for software releases\nprior to stable or generally available releases. Examples of prereleases include\ndevelopment, alpha, beta, and release candidate releases. A prerelease may be a\nversion such as `1.2.3-beta.1`, while the stable release would be `1.2.3`. In the\norder of precedence, prereleases come before their associated releases. In this\nexample `1.2.3-beta.1 < 1.2.3`.\n\nAccording to the Semantic Version specification prereleases may not be API\ncompliant with their release counterpart. It says,\n\n> A pre-release version indicates that the version is unstable and might not\n> satisfy the intended compatibility requirements as denoted by its associated\n> normal version.\n\nSemVer comparisons using constraints without a prerelease comparator will skip\nprerelease versions. For example, `>=1.2.3` will skip prereleases when looking\nat a list of releases, while `>=1.2.3-0` will evaluate and find prereleases.\n\nThe reason for the `0` as a pre-release version in the example comparison is\nbecause pre-releases can only contain ASCII alphanumerics and hyphens (along\nwith `.` separators), per the spec. Sorting happens in ASCII sort order, again\nper the spec. The lowest character is a `0` in ASCII sort order (see an [ASCII\nTable](http://www.asciitable.com/))\n\nUnderstanding ASCII sort ordering is important because A-Z comes before a-z.\nThat means `>=1.2.3-BETA` will return `1.2.3-alpha`. What you might expect from\ncase sensitivity doesn't apply here. This is due to ASCII sort ordering which is\nwhat the spec specifies.\n\n### Hyphen Range Comparisons\n\nThere are multiple methods to handle ranges and the first is hyphens ranges.\nThese look like:\n\n- `1.2 - 1.4.5` which is equivalent to `>= 1.2 <= 1.4.5`\n- `2.3.4 - 4.5` which is equivalent to `>= 2.3.4 <= 4.5`\n\n### Wildcards In Comparisons\n\nThe `x`, `X`, and `*` characters can be used as a wildcard character. This works\nfor all comparison operators. When used on the `=` operator it falls back to the\npatch level comparison (see tilde below). For example,\n\n- `1.2.x` is equivalent to `>= 1.2.0, < 1.3.0`\n- `>= 1.2.x` is equivalent to `>= 1.2.0`\n- `<= 2.x` is equivalent to `< 3`\n- `*` is equivalent to `>= 0.0.0`\n\n### Tilde Range Comparisons (Patch)\n\nThe tilde (`~`) comparison operator is for patch level ranges when a minor\nversion is specified and major level changes when the minor number is missing.\nFor example,\n\n- `~1.2.3` is equivalent to `>= 1.2.3, < 1.3.0`\n- `~1` is equivalent to `>= 1, < 2`\n- `~2.3` is equivalent to `>= 2.3, < 2.4`\n- `~1.2.x` is equivalent to `>= 1.2.0, < 1.3.0`\n- `~1.x` is equivalent to `>= 1, < 2`\n\n### Caret Range Comparisons (Major)\n\nThe caret (`^`) comparison operator is for major level changes once a stable\n(1.0.0) release has occurred. Prior to a 1.0.0 release the minor versions acts\nas the API stability level. This is useful when comparisons of API versions as a\nmajor change is API breaking. For example,\n\n- `^1.2.3` is equivalent to `>= 1.2.3, < 2.0.0`\n- `^1.2.x` is equivalent to `>= 1.2.0, < 2.0.0`\n- `^2.3` is equivalent to `>= 2.3, < 3`\n- `^2.x` is equivalent to `>= 2.0.0, < 3`\n- `^0.2.3` is equivalent to `>=0.2.3 <0.3.0`\n- `^0.2` is equivalent to `>=0.2.0 <0.3.0`\n- `^0.0.3` is equivalent to `>=0.0.3 <0.0.4`\n- `^0.0` is equivalent to `>=0.0.0 <0.1.0`\n- `^0` is equivalent to `>=0.0.0 <1.0.0`\n\n## URL Functions\n\nHelm includes the [urlParse](#urlparse), [urlJoin](#urljoin), and\n[urlquery](#urlquery) functions enabling you to work with URL parts.\n\n### urlParse\n\nParses string for URL and produces dict with URL parts\n\n```\nurlParse \"http://admin:secret@server.com:8080/api?list=false#anchor\"\n```\n\nThe above returns a dict, containing URL object:\n\n```yaml\nscheme:   'http'\nhost:     'server.com:8080'\npath:     '/api'\nquery:    'list=false'\nopaque:   nil\nfragment: 'anchor'\nuserinfo: 'admin:secret'\n```\n\nThis is implemented used the URL packages from the Go standard library. For more\ninfo, check https://golang.org/pkg/net/url/#URL\n\n### urlJoin\n\nJoins map (produced by `urlParse`) to produce URL string\n\n```\nurlJoin (dict \"fragment\" \"fragment\" \"host\" \"host:80\" \"path\" \"/path\" \"query\" \"query\" \"scheme\" \"http\")\n```\n\nThe above returns the following string:\n```\nhttp://host:80/path?query#fragment\n```\n\n### urlquery\n\nReturns the escaped version of the value passed in as an argument so that it is\nsuitable for embedding in the query portion of a URL.\n\n```\n$var := urlquery \"string for query\"\n```\n\n## UUID Functions\n\nHelm can generate UUID v4 universally unique IDs.\n\n```\nuuidv4\n```\n\nThe above returns a new UUID of the v4 (randomly generated) type.\n\n## Kubernetes and Chart Functions\n\nHelm includes functions for working with Kubernetes including\n[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas),\n[Files](#file-functions), and [lookup](#lookup).\n\n### lookup\n\n`lookup` is used to look up resource in a running cluster. When used with the\n`helm template` command it always returns an empty response.\n\nYou can find more detail in the [documentation on the lookup\nfunction](/chart_template_guide/functions_and_pipelines.md#using-the-lookup-function).\n\n### .Capabilities.APIVersions.Has\n\nReturns if an API version or resource is available in a cluster.\n\n```\n.Capabilities.APIVersions.Has \"apps/v1\"\n.Capabilities.APIVersions.Has \"apps/v1/Deployment\"\n```\n\nMore information is available on the [built-in object\ndocumentation](/chart_template_guide/builtin_objects.md).\n\n### File Functions\n\nThere are several functions that enable you to get to non-special files within a\nchart. For example, to access application configuration files. These are\ndocumented in [Accessing Files Inside Templates](/chart_template_guide/accessing_files.md).\n\n_Note, the documentation for many of these functions come from\n[Sprig](https://github.com/Masterminds/sprig). Sprig is a template function\nlibrary available to Go applications._\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/functions_and_pipelines.md",
    "content": "---\ntitle: Template Functions and Pipelines\ndescription: Using functions in templates.\nsidebar_position: 5\n---\n\nSo far, we've seen how to place information into a template. But that\ninformation is placed into the template unmodified. Sometimes we want to\ntransform the supplied data in a way that makes it more useable to us.\n\nLet's start with a best practice: When injecting strings from the `.Values`\nobject into the template, we ought to quote these strings. We can do that by\ncalling the `quote` function in the template directive:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ quote .Values.favorite.drink }}\n  food: {{ quote .Values.favorite.food }}\n```\n\nTemplate functions follow the syntax `functionName arg1 arg2...`. In the snippet\nabove, `quote .Values.favorite.drink` calls the `quote` function and passes it a\nsingle argument.\n\nHelm has over 60 available functions. Some of them are defined by the [Go\ntemplate language](https://godoc.org/text/template) itself. Most of the others\nare part of the [Sprig template library](https://masterminds.github.io/sprig/).\nWe'll see many of them as we progress through the examples.\n\n> While we talk about the \"Helm template language\" as if it is Helm-specific, it\n> is actually a combination of the Go template language, some extra functions,\n> and a variety of wrappers to expose certain objects to the templates. Many\n> resources on Go templates may be helpful as you learn about templating.\n\n## Pipelines\n\nOne of the powerful features of the template language is its concept of\n_pipelines_. Drawing on a concept from UNIX, pipelines are a tool for chaining\ntogether a series of template commands to compactly express a series of\ntransformations. In other words, pipelines are an efficient way of getting\nseveral things done in sequence. Let's rewrite the above example using a\npipeline.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | quote }}\n```\n\nIn this example, instead of calling `quote ARGUMENT`, we inverted the order. We\n\"sent\" the argument to the function using a pipeline (`|`):\n`.Values.favorite.drink | quote`. Using pipelines, we can chain several\nfunctions together:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\n> Inverting the order is a common practice in templates. You will see `.val |\n> quote` more often than `quote .val`. Either practice is fine.\n\nWhen evaluated, that template will produce this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trendsetting-p-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nNote that our original `pizza` has now been transformed to `\"PIZZA\"`.\n\nWhen pipelining arguments like this, the result of the first evaluation\n(`.Values.favorite.drink`) is sent as the _last argument to the function_. We\ncan modify the drink example above to illustrate with a function that takes two\narguments: `repeat COUNT STRING`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink | repeat 5 | quote }}\n  food: {{ .Values.favorite.food | upper | quote }}\n```\n\nThe `repeat` function will echo the given string the given number of times, so\nwe will get this for output:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: melting-porcup-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffeecoffeecoffeecoffeecoffee\"\n  food: \"PIZZA\"\n```\n\n## Using the `default` function\n\nOne function frequently used in templates is the `default` function: `default\nDEFAULT_VALUE GIVEN_VALUE`. This function allows you to specify a default value\ninside of the template, in case the value is omitted. Let's use it to modify the\ndrink example above:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default \"tea\" | quote }}\n```\n\nIf we run this as normal, we'll get our `coffee`:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: virtuous-mink-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n```\n\nNow, we will remove the favorite drink setting from `values.yaml`:\n\n```yaml\nfavorite:\n  #drink: coffee\n  food: pizza\n```\n\nNow re-running `helm install --dry-run --debug fair-worm ./mychart` will produce\nthis YAML:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: fair-worm-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"tea\"\n  food: \"PIZZA\"\n```\n\nIn an actual chart, all static default values should live in the `values.yaml`,\nand should not be repeated using the `default` command (otherwise they would be\nredundant). However, the `default` command is perfect for computed values, which\ncannot be declared inside `values.yaml`. For example:\n\n```yaml\ndrink: {{ .Values.favorite.drink | default (printf \"%s-tea\" (include \"fullname\" .)) }}\n```\n\nIn some places, an `if` conditional guard may be better suited than `default`.\nWe'll see those in the next section.\n\nTemplate functions and pipelines are a powerful way to transform information and\nthen insert it into your YAML. But sometimes it's necessary to add some template\nlogic that is a little more sophisticated than just inserting a string. In the\nnext section we will look at the control structures provided by the template\nlanguage.\n\n## Using the `lookup` function\n\nThe `lookup` function can be used to _look up_ resources in a running cluster.\nThe synopsis of the lookup function is `lookup apiVersion, kind, namespace, name\n-> resource or resource list`.\n\n| parameter  | type   |\n|------------|--------|\n| apiVersion | string |\n| kind       | string |\n| namespace  | string |\n| name       | string |\n\nBoth `name` and `namespace` are optional and can be passed as an empty string\n(`\"\"`). However, if you're working with a namespace-scoped resource, both `name`\nand `namespace` must be specified.\n\nThe following combination of parameters are possible:\n\n| Behavior                               | Lookup function                            |\n|----------------------------------------|--------------------------------------------|\n| `kubectl get pod mypod -n mynamespace` | `lookup \"v1\" \"Pod\" \"mynamespace\" \"mypod\"`  |\n| `kubectl get pods -n mynamespace`      | `lookup \"v1\" \"Pod\" \"mynamespace\" \"\"`       |\n| `kubectl get pods --all-namespaces`    | `lookup \"v1\" \"Pod\" \"\" \"\"`                  |\n| `kubectl get namespace mynamespace`    | `lookup \"v1\" \"Namespace\" \"\" \"mynamespace\"` |\n| `kubectl get namespaces`               | `lookup \"v1\" \"Namespace\" \"\" \"\"`            |\n\nWhen `lookup` returns an object, it will return a dictionary. This dictionary\ncan be further navigated to extract specific values.\n\nThe following example will return the annotations present for the `mynamespace`\nobject:\n\n```go\n(lookup \"v1\" \"Namespace\" \"\" \"mynamespace\").metadata.annotations\n```\n\nWhen `lookup` returns a list of objects, it is possible to access the object\nlist via the `items` field:\n\n```go\n{{ range $index, $service := (lookup \"v1\" \"Service\" \"mynamespace\" \"\").items }}\n    {{/* do something with each service */}}\n{{ end }}\n```\n\nWhen no object is found, an empty value is returned. This can be used to check\nfor the existence of an object.\n\nThe `lookup` function uses Helm's existing Kubernetes connection configuration\nto query Kubernetes. If any error is returned when interacting with calling the\nAPI server (for example due to lack of permission to access a resource), Helm's\ntemplate processing will fail.\n\nKeep in mind that Helm is not supposed to contact the Kubernetes API Server during \na `helm template|install|upgrade|delete|rollback --dry-run` operation. To test `lookup` \nagainst a running cluster, `helm template|install|upgrade|delete|rollback --dry-run=server`\nshould be used instead to allow cluster connection.\n\n## Operators are functions\n\nFor templates, the operators (`eq`, `ne`, `lt`, `gt`, `and`, `or` and so on) are\nall implemented as functions. In pipelines, operations can be grouped with\nparentheses (`(`, and `)`).\n\nNow we can turn from functions and pipelines to flow control with conditions,\nloops, and scope modifiers.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/getting_started.md",
    "content": "---\ntitle: Getting Started\ndescription: A quick guide on Chart templates.\nsidebar_position: 2\n---\n\nIn this section of the guide, we'll create a chart and then add a first\ntemplate. The chart we created here will be used throughout the rest of the\nguide.\n\nTo get going, let's take a brief look at a Helm chart.\n\n## Charts\n\nAs described in the [Charts Guide](/topics/charts.md), Helm charts are\nstructured like this:\n\n```\nmychart/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  ...\n```\n\nThe `templates/` directory is for template files. When Helm evaluates a chart,\nit will send all of the files in the `templates/` directory through the template\nrendering engine. It then collects the results of those templates and sends them\non to Kubernetes.\n\nThe `values.yaml` file is also important to templates. This file contains the\n_default values_ for a chart. These values may be overridden by users during\n`helm install` or `helm upgrade`.\n\nThe `Chart.yaml` file contains a description of the chart. You can access it\nfrom within a template.\n\nThe `charts/` directory _may_ contain other charts\n(which we call _subcharts_). Later in this guide we will see how those work when\nit comes to template rendering.\n\n## A Starter Chart\n\nFor this guide, we'll create a simple chart called `mychart`, and then we'll\ncreate some templates inside of the chart.\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\n### A Quick Glimpse of `mychart/templates/`\n\nIf you take a look at the `mychart/templates/` directory, you'll notice a few\nfiles already there.\n\n- `NOTES.txt`: The \"help text\" for your chart. This will be displayed to your\n  users when they run `helm install`.\n- `deployment.yaml`: A basic manifest for creating a Kubernetes\n  [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n- `service.yaml`: A basic manifest for creating a [service\n  endpoint](https://kubernetes.io/docs/concepts/services-networking/service/) for your deployment\n- `_helpers.tpl`: A place to put template helpers that you can re-use throughout\n  the chart\n\nAnd what we're going to do is... _remove them all!_ That way we can work through\nour tutorial from scratch. We'll actually create our own `NOTES.txt` and\n`_helpers.tpl` as we go.\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nWhen you're writing production grade charts, having basic versions of these\ncharts can be really useful. So in your day-to-day chart authoring, you probably\nwon't want to remove them.\n\n## A First Template\n\nThe first template we are going to create will be a `ConfigMap`. In Kubernetes,\na ConfigMap is simply an object for storing configuration data. Other things,\nlike pods, can access the data in a ConfigMap.\n\nBecause ConfigMaps are basic resources, they make a great starting point for us.\n\nLet's begin by creating a file called `mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\n**TIP:** Template names do not follow a rigid naming pattern. However, we\nrecommend using the extension `.yaml` for YAML files and `.tpl` for helpers.\n\nThe YAML file above is a bare-bones ConfigMap, having the minimal necessary\nfields. By virtue of the fact that this file is in the `mychart/templates/`\ndirectory, it will be sent through the template engine.\n\nIt is just fine to put a plain YAML file like this in the `mychart/templates/`\ndirectory. When Helm reads this template, it will simply send it to Kubernetes\nas-is.\n\nWith this simple template, we now have an installable chart. And we can install\nit like this:\n\n```console\n$ helm install full-coral ./mychart\nNAME: full-coral\nLAST DEPLOYED: Tue Nov  1 17:36:01 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nUsing Helm, we can retrieve the release and see the actual template that was\nloaded.\n\n```console\n$ helm get manifest full-coral\n\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: mychart-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nThe `helm get manifest` command takes a release name (`full-coral`) and prints\nout all of the Kubernetes resources that were uploaded to the server. Each file\nbegins with `---` to indicate the start of a YAML document, and then is followed\nby an automatically generated comment line that tells us what template file\ngenerated this YAML document.\n\nFrom there on, we can see that the YAML data is exactly what we put in our\n`configmap.yaml` file.\n\nNow we can uninstall our release: `helm uninstall full-coral`.\n\n### Adding a Simple Template Call\n\nHard-coding the `name:` into a resource is usually considered to be bad\npractice. Names should be unique to a release. So we might want to generate a\nname field by inserting the release name.\n\n**TIP:** The `name:` field is limited to 63 characters because of limitations to\nthe DNS system. For that reason, release names are limited to 53 characters.\nKubernetes 1.3 and earlier limited to only 24 characters (thus 14 character\nnames).\n\nLet's alter `configmap.yaml` accordingly.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n```\n\nThe big change comes in the value of the `name:` field, which is now\n`{{ .Release.Name }}-configmap`.\n\n> A template directive is enclosed in `{{` and `}}` blocks.\n\nThe template directive `{{ .Release.Name }}` injects the release name into the\ntemplate. The values that are passed into a template can be thought of as\n_namespaced objects_, where a dot (`.`) separates each namespaced element.\n\nThe leading dot before `Release` indicates that we start with the top-most\nnamespace for this scope (we'll talk about scope in a bit). So we could read\n`.Release.Name` as \"start at the top namespace, find the `Release` object, then\nlook inside of it for an object called `Name`\".\n\nThe `Release` object is one of the built-in objects for Helm, and we'll cover it\nin more depth later. But for now, it is sufficient to say that this will display\nthe release name that the library assigns to our release.\n\nNow when we install our resource, we'll immediately see the result of using this\ntemplate directive:\n\n```console\n$ helm install clunky-serval ./mychart\nNAME: clunky-serval\nLAST DEPLOYED: Tue Nov  1 17:45:37 2016\nNAMESPACE: default\nSTATUS: DEPLOYED\nREVISION: 1\nTEST SUITE: None\n```\n\nYou can run `helm get manifest clunky-serval` to see the entire generated YAML.\n\nNote that the ConfigMap inside Kubernetes name is `clunky-serval-configmap`\ninstead of `mychart-configmap` previously.\n\nAt this point, we've seen templates at their most basic: YAML files that have\ntemplate directives embedded in `{{` and `}}`. In the next part, we'll take a\ndeeper look into templates. But before moving on, there's one quick trick that\ncan make building templates faster: When you want to test the template\nrendering, but not actually install anything, you can use `helm install --debug\n--dry-run goodly-guppy ./mychart`. This will render the templates. But instead\nof installing the chart, it will return the rendered template to you so you can\nsee the output:\n\n```console\n$ helm install --debug --dry-run goodly-guppy ./mychart\ninstall.go:149: [debug] Original chart version: \"\"\ninstall.go:166: [debug] CHART PATH: /Users/ninja/mychart\n\nNAME: goodly-guppy\nLAST DEPLOYED: Thu Dec 26 17:24:13 2019\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: goodly-guppy-configmap\ndata:\n  myvalue: \"Hello World\"\n\n```\n\nUsing `--dry-run` will make it easier to test your code, but it won't ensure\nthat Kubernetes itself will accept the templates you generate. It's best not to\nassume that your chart will install just because `--dry-run` works.\n\nIn the [Chart Template Guide](/chart_template_guide/index.mdx), we take the basic chart we defined\nhere and explore the Helm template language in detail. And we'll get started\nwith built-in objects.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/helm_ignore_file.md",
    "content": "---\ntitle: The .helmignore file\ndescription: The `.helmignore` file is used to specify files you don't want to include in your helm chart.\nsidebar_position: 12\n---\n\nThe `.helmignore` file is used to specify files you don't want to include in\nyour helm chart.\n\nIf this file exists, the `helm package` command will ignore all the files that\nmatch the pattern specified in the `.helmignore` file while packaging your\napplication.\n\nThis can help in avoiding unnecessary or sensitive files or directories from\nbeing added in your helm chart.\n\nThe `.helmignore` file supports Unix shell glob matching, relative path\nmatching, and negation (prefixed with !). Only one pattern per line is\nconsidered.\n\nHere is an example `.helmignore` file:\n\n```\n# comment\n\n# Match any file or path named .helmignore\n.helmignore\n\n# Match any file or path named .git\n.git\n\n# Match any text file\n*.txt\n\n# Match only directories named mydir\nmydir/\n\n# Match only text files in the top-level directory\n/*.txt\n\n# Match only the file foo.txt in the top-level directory\n/foo.txt\n\n# Match any file named ab.txt, ac.txt, or ad.txt\na[b-d].txt\n\n# Match any file under subdir matching temp*\n*/temp*\n\n*/*/temp*\ntemp?\n```\n\nSome notable differences from .gitignore:\n- The '**' syntax is not supported.\n- The globbing library is Go's 'filepath.Match', not fnmatch(3)\n- Trailing spaces are always ignored (there is no supported escape sequence)\n- There is no support for '\\!' as a special leading sequence.\n- It does not exclude itself by default, you have to add an explicit entry for `.helmignore`\n\n\n**We'd love your help** making this document better. To add, correct, or remove\ninformation, [file an issue](https://github.com/helm/helm-www/issues) or send us a\npull request.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/index.mdx",
    "content": "---\ntitle: Chart Template Guide\nsidebar_position: 5\n---\n\n# The Chart Template Developer's Guide\n\nThis guide provides an introduction to Helm's chart templates, with emphasis on\nthe template language.\n\nTemplates generate manifest files, which are YAML-formatted resource\ndescriptions that Kubernetes can understand. We'll look at how templates are\nstructured, how they can be used, how to write Go templates, and how to debug\nyour work.\n\nThis guide focuses on the following concepts:\n\n- The Helm template language\n- Using values\n- Techniques for working with templates\n\nThis guide is oriented toward learning the ins and outs of the Helm template\nlanguage. Other guides provide introductory material, examples, and best\npractices.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/named_templates.md",
    "content": "---\ntitle: Named Templates\ndescription: How to define named templates.\nsidebar_position: 9\n---\n\nIt is time to move beyond one template, and begin to create others. In this\nsection, we will see how to define _named templates_ in one file, and then use\nthem elsewhere. A _named template_ (sometimes called a _partial_ or a\n_subtemplate_) is simply a template defined inside of a file, and given a name.\nWe'll see two ways to create them, and a few different ways to use them.\n\nIn the [Flow Control](/chart_template_guide/control_structures.md) section we introduced three actions\nfor declaring and managing templates: `define`, `template`, and `block`. In this\nsection, we'll cover those three actions, and also introduce a special-purpose\n`include` function that works similarly to the `template` action.\n\nAn important detail to keep in mind when naming templates: **template names are\nglobal**. If you declare two templates with the same name, whichever one is\nloaded last will be the one used. Because templates in subcharts are compiled\ntogether with top-level templates, you should be careful to name your templates\nwith _chart-specific names_.\n\nOne popular naming convention is to prefix each defined template with the name\nof the chart: `{{ define \"mychart.labels\" }}`. By using the specific chart name\nas a prefix we can avoid any conflicts that may arise due to two different\ncharts that implement templates of the same name.\n\nThis behavior also applies to different versions of a chart. If you have\n`mychart` version `1.0.0` that defines a template one way, and a `mychart`\nversion `2.0.0` that modifies the existing named template, it will use the one\nthat was loaded last. You can work around this issue by also adding a version\nin the name of the chart: `{{ define \"mychart.v1.labels\" }}` and\n`{{ define \"mychart.v2.labels\" }}`.\n\n## Partials and `_` files\n\nSo far, we've used one file, and that one file has contained a single template.\nBut Helm's template language allows you to create named embedded templates, that\ncan be accessed by name elsewhere.\n\nBefore we get to the nuts-and-bolts of writing those templates, there is file\nnaming convention that deserves mention:\n\n* Most files in `templates/` are treated as if they contain Kubernetes manifests\n* The `NOTES.txt` is one exception\n* But files whose name begins with an underscore (`_`) are assumed to _not_ have\n  a manifest inside. These files are not rendered to Kubernetes object\n  definitions, but are available everywhere within other chart templates for\n  use.\n\nThese files are used to store partials and helpers. In fact, when we first\ncreated `mychart`, we saw a file called `_helpers.tpl`. That file is the default\nlocation for template partials.\n\n## Declaring and using templates with `define` and `template`\n\nThe `define` action allows us to create a named template inside of a template\nfile. Its syntax goes like this:\n\n```yaml\n{{- define \"MY.NAME\" }}\n  # body of template here\n{{- end }}\n```\n\nFor example, we can define a template to encapsulate a Kubernetes block of\nlabels:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nNow we can embed this template inside of our existing ConfigMap, and then\ninclude it with the `template` action:\n\n```yaml\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nWhen the template engine reads this file, it will store away the reference to\n`mychart.labels` until `template \"mychart.labels\"` is called. Then it will\nrender that template inline. So the result will look like this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: running-panda-configmap\n  labels:\n    generator: helm\n    date: 2016-11-02\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nNote: a `define` does not produce output unless it is called with a template,\nas in this example.\n\nConventionally, Helm charts put these templates inside of a partials file,\nusually `_helpers.tpl`. Let's move this function there:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n{{- end }}\n```\n\nBy convention, `define` functions should have a simple documentation block\n(`{{/* ... */}}`) describing what they do.\n\nEven though this definition is in `_helpers.tpl`, it can still be accessed in\n`configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nAs mentioned above, **template names are global**. As a result of this, if two\ntemplates are declared with the same name the last occurrence will be the one\nthat is used. Since templates in subcharts are compiled together with top-level\ntemplates, it is best to name your templates with _chart specific names_. A\npopular naming convention is to prefix each defined template with the name of\nthe chart: `{{ define \"mychart.labels\" }}`.\n\n## Setting the scope of a template\n\nIn the template we defined above, we did not use any objects. We just used\nfunctions. Let's modify our defined template to include the chart name and chart\nversion:\n\n```yaml\n{{/* Generate basic labels */}}\n{{- define \"mychart.labels\" }}\n  labels:\n    generator: helm\n    date: {{ now | htmlDate }}\n    chart: {{ .Chart.Name }}\n    version: {{ .Chart.Version }}\n{{- end }}\n```\n\nIf we render this, we will get an error like this:\n\n```console\n$ helm install --dry-run moldy-jaguar ./mychart\nError: 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]\n```\n\nTo see what rendered, re-run with `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`.\nThe result will not be what we expect:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: moldy-jaguar-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart:\n    version:\n```\n\nWhat happened to the name and version? They weren't in the scope for our defined\ntemplate. When a named template (created with `define`) is rendered, it will\nreceive the scope passed in by the `template` call. In our example, we included\nthe template like this:\n\n```yaml\n{{- template \"mychart.labels\" }}\n```\n\nNo scope was passed in, so within the template we cannot access anything in `.`.\nThis is easy enough to fix, though. We simply pass a scope to the template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  {{- template \"mychart.labels\" . }}\n```\n\nNote that we pass `.` at the end of the `template` call. We could just as easily\npass `.Values` or `.Values.favorite` or whatever scope we want. But what we want\nis the top-level scope. In the context of the named template, `$` will refer\nto the scope you passed in and not some global scope.\n\nNow when we execute this template with `helm install --dry-run --debug\nplinking-anaco ./mychart`, we get this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: plinking-anaco-configmap\n  labels:\n    generator: helm\n    date: 2021-03-06\n    chart: mychart\n    version: 0.1.0\n```\n\nNow `{{ .Chart.Name }}` resolves to `mychart`, and `{{ .Chart.Version }}`\nresolves to `0.1.0`.\n\n## The `include` function\n\nSay we've defined a simple template that looks like this:\n\n```yaml\n{{- define \"mychart.app\" -}}\napp_name: {{ .Chart.Name }}\napp_version: \"{{ .Chart.Version }}\"\n{{- end -}}\n```\n\nNow say I want to insert this both into the `labels:` section of my template,\nand also the `data:` section:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n    {{ template \"mychart.app\" . }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ template \"mychart.app\" . }}\n```\n\nIf we render this, we will get an error like this:\n\n```console\n$ helm install --dry-run measly-whippet ./mychart\nError: 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]\n```\n\nTo see what rendered, re-run with `--disable-openapi-validation`:\n`helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`.\nThe output will not be what we expect:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: measly-whippet-configmap\n  labels:\n    app_name: mychart\napp_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\napp_name: mychart\napp_version: \"0.1.0\"\n```\n\nNote that the indentation on `app_version` is wrong in both places. Why? Because\nthe template that is substituted in has the text aligned to the left. Because\n`template` is an action, and not a function, there is no way to pass the output\nof a `template` call to other functions; the data is simply inserted inline.\n\nTo work around this case, Helm provides an alternative to `template` that will\nimport the contents of a template into the present pipeline where it can be\npassed along to other functions in the pipeline.\n\nHere's the example above, corrected to use `indent` to indent the `mychart.app`\ntemplate correctly:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\n  labels:\n{{ include \"mychart.app\" . | indent 4 }}\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n{{ include \"mychart.app\" . | indent 2 }}\n```\n\nNow the produced YAML is correctly indented for each section:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: edgy-mole-configmap\n  labels:\n    app_name: mychart\n    app_version: \"0.1.0\"\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n  app_name: mychart\n  app_version: \"0.1.0\"\n```\n\n> It is considered preferable to use `include` over `template` in Helm templates\n> simply so that the output formatting can be handled better for YAML documents.\n\nSometimes we want to import content, but not as templates. That is, we want to\nimport files verbatim. We can achieve this by accessing files through the\n`.Files` object described in the next section.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/notes_files.md",
    "content": "---\ntitle: Creating a NOTES.txt File\ndescription: How to provide instructions to your Chart users.\nsidebar_position: 10\n---\n\nIn this section we are going to look at Helm's tool for providing instructions\nto your chart users. At the end of a `helm install` or `helm upgrade`, Helm can\nprint out a block of helpful information for users. This information is highly\ncustomizable using templates.\n\nTo add installation notes to your chart, simply create a `templates/NOTES.txt`\nfile. This file is plain text, but it is processed like a template, and has\nall the normal template functions and objects available.\n\nLet's create a simple `NOTES.txt` file:\n\n```\nThank you for installing {{ .Chart.Name }}.\n\nYour release is named {{ .Release.Name }}.\n\nTo learn more about the release, try:\n\n  $ helm status {{ .Release.Name }}\n  $ helm get all {{ .Release.Name }}\n\n```\n\nNow if we run `helm install rude-cardinal ./mychart` we will see this message at\nthe bottom:\n\n```\nRESOURCES:\n==> v1/Secret\nNAME                   TYPE      DATA      AGE\nrude-cardinal-secret   Opaque    1         0s\n\n==> v1/ConfigMap\nNAME                      DATA      AGE\nrude-cardinal-configmap   3         0s\n\n\nNOTES:\nThank you for installing mychart.\n\nYour release is named rude-cardinal.\n\nTo learn more about the release, try:\n\n  $ helm status rude-cardinal\n  $ helm get all rude-cardinal\n```\n\nUsing `NOTES.txt` this way is a great way to give your users detailed\ninformation about how to use their newly installed chart. Creating a `NOTES.txt`\nfile is strongly recommended, though it is not required.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/subcharts_and_globals.md",
    "content": "---\ntitle: Subcharts and Global Values\ndescription: Interacting with a subchart's and global values.\nsidebar_position: 11\n---\n\nTo this point we have been working only with one chart. But charts can have\ndependencies, called _subcharts_, that also have their own values and templates.\nIn this section we will create a subchart and see the different ways we can\naccess values from within templates.\n\nBefore we dive into the code, there are a few important details to learn about application subcharts.\n\n1. A subchart is considered \"stand-alone\", which means a subchart can never\n   explicitly depend on its parent chart.\n2. For that reason, a subchart cannot access the values of its parent.\n3. A parent chart can override values for subcharts.\n4. Helm has a concept of _global values_ that can be accessed by all charts.\n\n> These limitations do not all necessarily apply to [library charts](/topics/library_charts.md), which are designed to provide standardized helper functionality.\n\nAs we walk through the examples in this section, many of these concepts will\nbecome clearer.\n\n## Creating a Subchart\n\nFor these exercises, we'll start with the `mychart/` chart we created at the\nbeginning of this guide, and we'll add a new chart inside of it.\n\n```console\n$ cd mychart/charts\n$ helm create mysubchart\nCreating mysubchart\n$ rm -rf mysubchart/templates/*\n```\n\nNotice that just as before, we deleted all of the base templates so that we can\nstart from scratch. In this guide, we are focused on how templates work, not on\nmanaging dependencies. But the [Charts Guide](/topics/charts.md)\nhas more information on how subcharts work.\n\n## Adding Values and a Template to the Subchart\n\nNext, let's create a simple template and values file for our `mysubchart` chart.\nThere should already be a `values.yaml` in `mychart/charts/mysubchart`. We'll\nset it up like this:\n\n```yaml\ndessert: cake\n```\n\nNext, we'll create a new ConfigMap template in\n`mychart/charts/mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n```\n\nBecause every subchart is a _stand-alone chart_, we can test `mysubchart` on its\nown:\n\n```console\n$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart\nSERVER: \"localhost:44134\"\nCHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart\nNAME:   newbie-elk\nTARGET NAMESPACE:   default\nCHART:  mysubchart 0.1.0\nMANIFEST:\n---\n# Source: mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: newbie-elk-cfgmap2\ndata:\n  dessert: cake\n```\n\n## Overriding Values from a Parent Chart\n\nOur original chart, `mychart` is now the _parent_ chart of `mysubchart`. This\nrelationship is based entirely on the fact that `mysubchart` is within\n`mychart/charts`.\n\nBecause `mychart` is a parent, we can specify configuration in `mychart` and\nhave that configuration pushed into `mysubchart`. For example, we can modify\n`mychart/values.yaml` like this:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n```\n\nNote the last two lines. Any directives inside of the `mysubchart` section will\nbe sent to the `mysubchart` chart. So if we run `helm install --generate-name --dry-run --debug\nmychart`, one of the things we will see is the `mysubchart` ConfigMap:\n\n```yaml\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: unhinged-bee-cfgmap2\ndata:\n  dessert: ice cream\n```\n\nThe value at the top level has now overridden the value of the subchart.\n\nThere's an important detail to notice here. We didn't change the template of\n`mychart/charts/mysubchart/templates/configmap.yaml` to point to\n`.Values.mysubchart.dessert`. From that template's perspective, the value is\nstill located at `.Values.dessert`. As the template engine passes values along,\nit sets the scope. So for the `mysubchart` templates, only values specifically\nfor `mysubchart` will be available in `.Values`.\n\nSometimes, though, you do want certain values to be available to all of the\ntemplates. This is accomplished using global chart values.\n\n## Global Chart Values\n\nGlobal values are values that can be accessed from any chart or subchart by\nexactly the same name. Globals require explicit declaration. You can't use an\nexisting non-global as if it were a global.\n\nThe Values data type has a reserved section called `Values.global` where global\nvalues can be set. Let's set one in our `mychart/values.yaml` file.\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\npizzaToppings:\n  - mushrooms\n  - cheese\n  - peppers\n  - onions\n\nmysubchart:\n  dessert: ice cream\n\nglobal:\n  salad: caesar\n```\n\nBecause of the way globals work, both `mychart/templates/configmap.yaml` and\n`mysubchart/templates/configmap.yaml` should be able to access that value as\n`{{ .Values.global.salad }}`.\n\n`mychart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  salad: {{ .Values.global.salad }}\n```\n\n`mysubchart/templates/configmap.yaml`:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-cfgmap2\ndata:\n  dessert: {{ .Values.dessert }}\n  salad: {{ .Values.global.salad }}\n```\n\nNow if we run a dry run install, we'll see the same value in both outputs:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-configmap\ndata:\n  salad: caesar\n\n---\n# Source: mychart/charts/mysubchart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: silly-snake-cfgmap2\ndata:\n  dessert: ice cream\n  salad: caesar\n```\n\nGlobals are useful for passing information like this, though it does take some\nplanning to make sure the right templates are configured to use globals.\n\n## Sharing Templates with Subcharts\n\nParent charts and subcharts can share templates. Any defined block in any chart\nis available to other charts.\n\nFor example, we can define a simple template like this:\n\n```yaml\n{{- define \"labels\" }}from: mychart{{ end }}\n```\n\nRecall how the labels on templates are _globally shared_. Thus, the `labels`\nchart can be included from any other chart.\n\nWhile chart developers have a choice between `include` and `template`, one\nadvantage of using `include` is that `include` can dynamically reference\ntemplates:\n\n```yaml\n{{ include $mytemplate }}\n```\n\nThe above will dereference `$mytemplate`. The `template` function, in contrast,\nwill only accept a string literal.\n\n## Avoid Using Blocks\n\nThe Go template language provides a `block` keyword that allows developers to\nprovide a default implementation which is overridden later. In Helm charts,\nblocks are not the best tool for overriding because if multiple implementations\nof the same block are provided, the one selected is unpredictable.\n\nThe suggestion is to instead use `include`.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/values_files.md",
    "content": "---\ntitle: Values Files\ndescription: Instructions on how to use the --values flag.\nsidebar_position: 4\n---\n\nIn the previous section we looked at the built-in objects that Helm templates\noffer. One of the built-in objects is `Values`. This object provides access to\nvalues passed into the chart. Its contents come from multiple sources:\n\n- The `values.yaml` file in the chart\n- If this is a subchart, the `values.yaml` file of a parent chart\n- A values file is passed into `helm install` or `helm upgrade` with the `-f`\n  flag (`helm install -f myvals.yaml ./mychart`)\n- Individual parameters are passed with `--set` (such as `helm install --set foo=bar\n  ./mychart`)\n\nThe list above is in order of specificity: `values.yaml` is the default, which\ncan be overridden by a parent chart's `values.yaml`, which can in turn be\noverridden by a user-supplied values file, which can in turn be overridden by\n`--set` parameters.\n\nValues files are plain YAML files. Let's edit `mychart/values.yaml` and then\nedit our ConfigMap template.\n\nRemoving the defaults in `values.yaml`, we'll set just one parameter:\n\n```yaml\nfavoriteDrink: coffee\n```\n\nNow we can use this inside of a template:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favoriteDrink }}\n```\n\nNotice on the last line we access `favoriteDrink` as an attribute of `Values`:\n`{{ .Values.favoriteDrink }}`.\n\nLet's see how this renders.\n\n```console\n$ helm install geared-marsupi ./mychart --dry-run --debug\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: geared-marsupi\nLAST DEPLOYED: Wed Feb 19 23:21:13 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\nfavoriteDrink: coffee\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: geared-marsupi-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: coffee\n```\n\nBecause `favoriteDrink` is set in the default `values.yaml` file to `coffee`,\nthat's the value displayed in the template. We can easily override that by\nadding a `--set` flag in our call to `helm install`:\n\n```console\n$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm\ninstall.go:158: [debug] Original chart version: \"\"\ninstall.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart\n\nNAME: solid-vulture\nLAST DEPLOYED: Wed Feb 19 23:25:54 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\nfavoriteDrink: slurm\n\nCOMPUTED VALUES:\nfavoriteDrink: slurm\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: solid-vulture-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: slurm\n```\n\nSince `--set` has a higher precedence than the default `values.yaml` file, our\ntemplate generates `drink: slurm`.\n\nValues files can contain more structured content, too. For example, we could\ncreate a `favorite` section in our `values.yaml` file, and then add several keys\nthere:\n\n```yaml\nfavorite:\n  drink: coffee\n  food: pizza\n```\n\nNow we would have to modify the template slightly:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: {{ .Values.favorite.drink }}\n  food: {{ .Values.favorite.food }}\n```\n\nWhile structuring data this way is possible, the recommendation is that you keep\nyour values trees shallow, favoring flatness. When we look at assigning values\nto subcharts, we'll see how values are named using a tree structure.\n\n## Deleting a default key\n\nIf you need to delete a key from the default values, you may override the value\nof the key to be `null`, in which case Helm will remove the key from the\noverridden values merge.\n\nFor example, the stable Drupal chart allows configuring the liveness probe, in\ncase you configure a custom image. Here are the default values:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  initialDelaySeconds: 120\n```\n\nIf you try to override the livenessProbe handler to `exec` instead of `httpGet`\nusing `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm will\ncoalesce the default and overridden keys together, resulting in the following\nYAML:\n```yaml\nlivenessProbe:\n  httpGet:\n    path: /user/login\n    port: http\n  exec:\n    command:\n    - cat\n    - docroot/CHANGELOG.txt\n  initialDelaySeconds: 120\n```\n\nHowever, Kubernetes would then fail because you can not declare more than one\nlivenessProbe handler. To overcome this, you may instruct Helm to delete the\n`livenessProbe.httpGet` by setting it to null:\n```sh\nhelm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null\n```\n\nAt this point, we've seen several built-in objects, and used them to inject\ninformation into a template. Now we will take a look at another aspect of the\ntemplate engine: functions and pipelines.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/variables.md",
    "content": "---\ntitle: Variables\ndescription: Using variables in templates.\nsidebar_position: 8\n---\n\nWith functions, pipelines, objects, and control structures under our belts, we\ncan turn to one of the more basic ideas in many programming languages:\nvariables. In templates, they are less frequently used. But we will see how to\nuse them to simplify code, and to make better use of `with` and `range`.\n\nIn an earlier example, we saw that this code will fail:\n\n```yaml\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ .Release.Name }}\n  {{- end }}\n```\n\n`Release.Name` is not inside of the scope that's restricted in the `with` block.\nOne way to work around scoping issues is to assign objects to variables that can\nbe accessed without respect to the present scope.\n\nIn Helm templates, a variable is a named reference to another object. It follows\nthe form `$name`. Variables are assigned with a special assignment operator:\n`:=`. We can rewrite the above to use a variable for `Release.Name`.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- $relname := .Release.Name -}}\n  {{- with .Values.favorite }}\n  drink: {{ .drink | default \"tea\" | quote }}\n  food: {{ .food | upper | quote }}\n  release: {{ $relname }}\n  {{- end }}\n```\n\nNotice that before we start the `with` block, we assign `$relname :=\n.Release.Name`. Now inside of the `with` block, the `$relname` variable still\npoints to the release name.\n\nRunning that will produce this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: viable-badger-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"PIZZA\"\n  release: viable-badger\n```\n\nVariables are particularly useful in `range` loops. They can be used on\nlist-like objects to capture both the index and the value:\n\n```yaml\n  toppings: |-\n    {{- range $index, $topping := .Values.pizzaToppings }}\n      {{ $index }}: {{ $topping }}\n    {{- end }}\n\n```\n\nNote that `range` comes first, then the variables, then the assignment operator,\nthen the list. This will assign the integer index (starting from zero) to\n`$index` and the value to `$topping`. Running it will produce:\n\n```yaml\n  toppings: |-\n      0: mushrooms\n      1: cheese\n      2: peppers\n      3: onions\n```\n\nFor data structures that have both a key and a value, we can use `range` to get\nboth. For example, we can loop through `.Values.favorite` like this:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name }}-configmap\ndata:\n  myvalue: \"Hello World\"\n  {{- range $key, $val := .Values.favorite }}\n  {{ $key }}: {{ $val | quote }}\n  {{- end }}\n```\n\nNow on the first iteration, `$key` will be `drink` and `$val` will be `coffee`,\nand on the second, `$key` will be `food` and `$val` will be `pizza`. Running the\nabove will generate this:\n\n```yaml\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: eager-rabbit-configmap\ndata:\n  myvalue: \"Hello World\"\n  drink: \"coffee\"\n  food: \"pizza\"\n```\n\nVariables are normally not \"global\". They are scoped to the block in which they\nare declared. Earlier, we assigned `$relname` in the top level of the template.\nThat variable will be in scope for the entire template. But in our last example,\n`$key` and `$val` will only be in scope inside of the `{{ range... }}{{ end }}`\nblock.\n\nHowever, there is one variable that will always point to the root context: - `$` -.\nThis can be very useful when you are looping\nin a range and you need to know the chart's release name.\n\nAn example illustrating this:\n```yaml\n{{- range .Values.tlsSecrets }}\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {{ .name }}\n  labels:\n    # Many helm templates would use `.` below, but that will not work,\n    # however `$` will work here\n    app.kubernetes.io/name: {{ template \"fullname\" $ }}\n    # I cannot reference .Chart.Name, but I can do $.Chart.Name\n    helm.sh/chart: \"{{ $.Chart.Name }}-{{ $.Chart.Version }}\"\n    app.kubernetes.io/instance: \"{{ $.Release.Name }}\"\n    # Value from appVersion in Chart.yaml\n    app.kubernetes.io/version: \"{{ $.Chart.AppVersion }}\"\n    app.kubernetes.io/managed-by: \"{{ $.Release.Service }}\"\ntype: kubernetes.io/tls\ndata:\n  tls.crt: {{ .certificate }}\n  tls.key: {{ .key }}\n{{- end }}\n```\n\nSo far we have looked at just one template declared in just one file. But one of\nthe powerful features of the Helm template language is its ability to declare\nmultiple templates and use them together. We'll turn to that in the next\nsection.\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/wrapping_up.md",
    "content": "---\ntitle: Next Steps\ndescription: Wrapping up - some useful pointers to other documentation that will help you.\nsidebar_position: 14\n---\n\nThis guide is intended to give you, the chart developer, a strong understanding\nof how to use Helm's template language. The guide focuses on the technical\naspects of template development.\n\nBut there are many things this guide has not covered when it comes to the\npractical day-to-day development of charts. Here are some useful pointers to\nother documentation that will help you as you create new charts:\n\n- The CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) is an\n  indispensable source of charts.\n- The Kubernetes [Documentation](https://kubernetes.io/docs/home/) provides\n  detailed examples of the various resource kinds that you can use, from\n  ConfigMaps and Secrets to DaemonSets and Deployments.\n- The Helm [Charts Guide](/topics/charts.md) explains the workflow of using\n  charts.\n- The Helm [Chart Hooks Guide](/topics/charts_hooks.md) explains how to\n  create lifecycle hooks.\n- The Helm [Charts Tips and Tricks](/howto/charts_tips_and_tricks.md) article\n  provides some useful tips for writing charts.\n- The [Sprig documentation](https://github.com/Masterminds/sprig) documents more\n  than sixty of the template functions.\n- The [Go template docs](https://godoc.org/text/template) explain the template\n  syntax in detail.\n- The [Schelm tool](https://github.com/databus23/schelm) is a nice helper\n  utility for debugging charts.\n\nSometimes it's easier to ask a few questions and get answers from experienced\ndevelopers. The best place to do this is in the [Kubernetes\nSlack](https://kubernetes.slack.com) Helm channels:\n\n- [#helm-users](https://kubernetes.slack.com/messages/helm-users)\n- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)\n- [#charts](https://kubernetes.slack.com/messages/charts)\n\nFinally, if you find errors or omissions in this document, want to suggest some\nnew content, or would like to contribute, visit [The Helm\nProject](https://github.com/helm/helm-www).\n"
  },
  {
    "path": "versioned_docs/version-3/chart_template_guide/yaml_techniques.md",
    "content": "---\ntitle: \"Appendix: YAML Techniques\"\ndescription: A closer look at the YAML specification and how it applies to Helm.\nsidebar_position: 15\n---\n\nMost of this guide has been focused on writing the template language. Here,\nwe'll look at the YAML format. YAML has some useful features that we, as\ntemplate authors, can use to make our templates less error prone and easier to\nread.\n\n## Scalars and Collections\n\nAccording to the [YAML spec](https://yaml.org/spec/1.2/spec.html), there are two\ntypes of collections, and many scalar types.\n\nThe two types of collections are maps and sequences:\n\n```yaml\nmap:\n  one: 1\n  two: 2\n  three: 3\n\nsequence:\n  - one\n  - two\n  - three\n```\n\nScalar values are individual values (as opposed to collections)\n\n### Scalar Types in YAML\n\nIn Helm's dialect of YAML, the scalar data type of a value is determined by a\ncomplex set of rules, including the Kubernetes schema for resource definitions.\nBut when inferring types, the following rules tend to hold true.\n\nIf an integer or float is an unquoted bare word, it is typically treated as a\nnumeric type:\n\n```yaml\ncount: 1\nsize: 2.34\n```\n\nBut if they are quoted, they are treated as strings:\n\n```yaml\ncount: \"1\" # <-- string, not int\nsize: '2.34' # <-- string, not float\n```\n\nThe same is true of booleans:\n\n```yaml\nisGood: true   # bool\nanswer: \"true\" # string\n```\n\nThe word for an empty value is `null` (not `nil`).\n\nNote that `port: \"80\"` is valid YAML, and will pass through both the template\nengine and the YAML parser, but will fail if Kubernetes expects `port` to be an\ninteger.\n\nIn some cases, you can force a particular type inference using YAML node tags:\n\n```yaml\ncoffee: \"yes, please\"\nage: !!str 21\nport: !!int \"80\"\n```\n\nIn the above, `!!str` tells the parser that `age` is a string, even if it looks\nlike an int. And `port` is treated as an int, even though it is quoted.\n\n\n## Strings in YAML\n\nMuch of the data that we place in YAML documents are strings. YAML has more than\none way to represent a string. This section explains the ways and demonstrates\nhow to use some of them.\n\nThere are three \"inline\" ways of declaring a string:\n\n```yaml\nway1: bare words\nway2: \"double-quoted strings\"\nway3: 'single-quoted strings'\n```\n\nAll inline styles must be on one line.\n\n- Bare words are unquoted, and are not escaped. For this reason, you have to be\n  careful what characters you use.\n- Double-quoted strings can have specific characters escaped with `\\`. For\n  example `\"\\\"Hello\\\", she said\"`. You can escape line breaks with `\\n`.\n- Single-quoted strings are \"literal\" strings, and do not use the `\\` to escape\n  characters. The only escape sequence is `''`, which is decoded as a single\n  `'`.\n\nIn addition to the one-line strings, you can declare multi-line strings:\n\n```yaml\ncoffee: |\n  Latte\n  Cappuccino\n  Espresso\n```\n\nThe above will treat the value of `coffee` as a single string equivalent to\n`Latte\\nCappuccino\\nEspresso\\n`.\n\nNote that the first line after the `|` must be correctly indented. So we could\nbreak the example above by doing this:\n\n```yaml\ncoffee: |\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nBecause `Latte` is incorrectly indented, we'd get an error like this:\n\n```\nError parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key\n```\n\nIn templates, it is sometimes safer to put a fake \"first line\" of content in a\nmulti-line document just for protection from the above error:\n\n```yaml\ncoffee: |\n  # Commented first line\n         Latte\n  Cappuccino\n  Espresso\n\n```\n\nNote that whatever that first line is, it will be preserved in the output of the\nstring. So if you are, for example, using this technique to inject a file's\ncontents into a ConfigMap, the comment should be of the type expected by\nwhatever is reading that entry.\n\n### Controlling Spaces in Multi-line Strings\n\nIn the example above, we used `|` to indicate a multi-line string. But notice\nthat the content of our string was followed with a trailing `\\n`. If we want the\nYAML processor to strip off the trailing newline, we can add a `-` after the\n`|`:\n\n```yaml\ncoffee: |-\n  Latte\n  Cappuccino\n  Espresso\n```\n\nNow the `coffee` value will be: `Latte\\nCappuccino\\nEspresso` (with no trailing\n`\\n`).\n\nOther times, we might want all trailing whitespace to be preserved. We can do\nthis with the `|+` notation:\n\n```yaml\ncoffee: |+\n  Latte\n  Cappuccino\n  Espresso\n\n\nanother: value\n```\n\nNow the value of `coffee` will be `Latte\\nCappuccino\\nEspresso\\n\\n\\n`.\n\nIndentation inside of a text block is preserved, and results in the preservation\nof line breaks, too:\n\n```yaml\ncoffee: |-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nIn the above case, `coffee` will be `Latte\\n  12 oz\\n  16\noz\\nCappuccino\\nEspresso`.\n\n### Indenting and Templates\n\nWhen writing templates, you may find yourself wanting to inject the contents of\na file into the template. As we saw in previous chapters, there are two ways of\ndoing this:\n\n- Use `{{ .Files.Get \"FILENAME\" }}` to get the contents of a file in the chart.\n- Use `{{ include \"TEMPLATE\" . }}` to render a template and then place its\n  contents into the chart.\n\nWhen inserting files into YAML, it's good to understand the multi-line rules\nabove. Often times, the easiest way to insert a static file is to do something\nlike this:\n\n```yaml\nmyfile: |\n{{ .Files.Get \"myfile.txt\" | indent 2 }}\n```\n\nNote how we do the indentation above: `indent 2` tells the template engine to\nindent every line in \"myfile.txt\" with two spaces. Note that we do not indent\nthat template line. That's because if we did, the file content of the first line\nwould be indented twice.\n\n### Folded Multi-line Strings\n\nSometimes you want to represent a string in your YAML with multiple lines, but\nwant it to be treated as one long line when it is interpreted. This is called\n\"folding\". To declare a folded block, use `>` instead of `|`:\n\n```yaml\ncoffee: >\n  Latte\n  Cappuccino\n  Espresso\n\n\n```\n\nThe value of `coffee` above will be `Latte Cappuccino Espresso\\n`. Note that all\nbut the last line feed will be converted to spaces. You can combine the\nwhitespace controls with the folded text marker, so `>-` will replace or trim\nall newlines.\n\nNote that in the folded syntax, indenting text will cause lines to be preserved.\n\n```yaml\ncoffee: >-\n  Latte\n    12 oz\n    16 oz\n  Cappuccino\n  Espresso\n```\n\nThe above will produce `Latte\\n  12 oz\\n  16 oz\\nCappuccino Espresso`. Note that\nboth the spacing and the newlines are still there.\n\n## Embedding Multiple Documents in One File\n\nIt is possible to place more than one YAML document into a single file. This is\ndone by prefixing a new document with `---` and ending the document with\n`...`\n\n```yaml\n\n---\ndocument: 1\n...\n---\ndocument: 2\n...\n```\n\nIn many cases, either the `---` or the `...` may be omitted.\n\nSome files in Helm cannot contain more than one doc. If, for example, more than\none document is provided inside of a `values.yaml` file, only the first will be\nused.\n\nTemplate files, however, may have more than one document. When this happens, the\nfile (and all of its documents) is treated as one object during template\nrendering. But then the resulting YAML is split into multiple documents before\nit is fed to Kubernetes.\n\nWe recommend only using multiple documents per file when it is absolutely\nnecessary. Having multiple documents in a file can be difficult to debug.\n\n## YAML is a Superset of JSON\n\nBecause YAML is a superset of JSON, any valid JSON document _should_ be valid\nYAML.\n\n```json\n{\n  \"coffee\": \"yes, please\",\n  \"coffees\": [\n    \"Latte\", \"Cappuccino\", \"Espresso\"\n  ]\n}\n```\n\nThe above is another way of representing this:\n\n```yaml\ncoffee: yes, please\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nAnd the two can be mixed (with care):\n\n```yaml\ncoffee: \"yes, please\"\ncoffees: [ \"Latte\", \"Cappuccino\", \"Espresso\"]\n```\n\nAll three of these should parse into the same internal representation.\n\nWhile this means that files such as `values.yaml` may contain JSON data, Helm\ndoes not treat the file extension `.json` as a valid suffix.\n\n## YAML Anchors\n\nThe YAML spec provides a way to store a reference to a value, and later refer to\nthat value by reference. YAML refers to this as \"anchoring\":\n\n```yaml\ncoffee: \"yes, please\"\nfavorite: &favoriteCoffee \"Cappuccino\"\ncoffees:\n  - Latte\n  - *favoriteCoffee\n  - Espresso\n```\n\nIn the above, `&favoriteCoffee` sets a reference to `Cappuccino`. Later, that\nreference is used as `*favoriteCoffee`. So `coffees` becomes `Latte, Cappuccino,\nEspresso`.\n\nWhile there are a few cases where anchors are useful, there is one aspect of\nthem that can cause subtle bugs: The first time the YAML is consumed, the\nreference is expanded and then discarded.\n\nSo if we were to decode and then re-encode the example above, the resulting YAML\nwould be:\n\n```yaml\ncoffee: yes, please\nfavorite: Cappuccino\ncoffees:\n- Latte\n- Cappuccino\n- Espresso\n```\n\nBecause Helm and Kubernetes often read, modify, and then rewrite YAML files, the\nanchors will be lost.\n"
  },
  {
    "path": "versioned_docs/version-3/faq/changes_since_helm2.md",
    "content": "---\ntitle: Changes Since Helm 2\nsidebar_position: 1\n---\n\n## Changes since Helm 2\n\nHere's an exhaustive list of all the major changes introduced in Helm 3.\n\n### Removal of Tiller\n\nDuring the Helm 2 development cycle, we introduced Tiller. Tiller played an\nimportant role for teams working on a shared cluster - it made it possible for\nmultiple different operators to interact with the same set of releases.\n\nWith role-based access controls (RBAC) enabled by default in Kubernetes 1.6,\nlocking down Tiller for use in a production scenario became more difficult to\nmanage. Due to the vast number of possible security policies, our stance was to\nprovide a permissive default configuration. This allowed first-time users to\nstart experimenting with Helm and Kubernetes without having to dive headfirst\ninto the security controls. Unfortunately, this permissive configuration could\ngrant a user a broad range of permissions they weren’t intended to have. DevOps\nand SREs had to learn additional operational steps when installing Tiller into a\nmulti-tenant cluster.\n\nAfter hearing how community members were using Helm in certain scenarios, we\nfound that Tiller’s release management system did not need to rely upon an\nin-cluster operator to maintain state or act as a central hub for Helm release\ninformation. Instead, we could simply fetch information from the Kubernetes API\nserver, render the Charts client-side, and store a record of the installation in\nKubernetes.\n\nTiller’s primary goal could be accomplished without Tiller, so one of the first\ndecisions we made regarding Helm 3 was to completely remove Tiller.\n\nWith Tiller gone, the security model for Helm is radically simplified. Helm 3\nnow supports all the modern security, identity, and authorization features of\nmodern Kubernetes. Helm’s permissions are evaluated using your [kubeconfig\nfile](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/).\nCluster administrators can restrict user permissions at whatever granularity\nthey see fit. Releases are still recorded in-cluster, and the rest of Helm’s\nfunctionality remains.\n\n### Improved Upgrade Strategy: 3-way Strategic Merge Patches\n\nHelm 2 used a two-way strategic merge patch. During an upgrade, it compared the\nmost recent chart's manifest against the proposed chart's manifest (the one\nsupplied during `helm upgrade`). It compared the differences between these two\ncharts to determine what changes needed to be applied to the resources in\nKubernetes. If changes were applied to the cluster out-of-band (such as during a\n`kubectl edit`), those changes were not considered. This resulted in resources\nbeing unable to roll back to its previous state: because Helm only considered\nthe last applied chart's manifest as its current state, if there were no changes\nin the chart's state, the live state was left unchanged.\n\nIn Helm 3, we now use a three-way strategic merge patch. Helm considers the old\nmanifest, its live state, and the new manifest when generating a patch.\n\n#### Examples\n\nLet's go through a few common examples what this change impacts.\n\n##### Rolling back where live state has changed\n\nYour team just deployed their application to production on Kubernetes using\nHelm. The chart contains a Deployment object where the number of replicas is set\nto three:\n\n```console\n$ helm install myapp ./myapp\n```\n\nA new developer joins the team. On their first day while observing the\nproduction cluster, a horrible coffee-spilling-on-the-keyboard accident happens\nand they `kubectl scale` the production deployment from three replicas down to\nzero.\n\n```console\n$ kubectl scale --replicas=0 deployment/myapp\n```\n\nAnother developer on your team notices that the production site is down and\ndecides to rollback the release to its previous state:\n\n```console\n$ helm rollback myapp\n```\n\nWhat happens?\n\nIn Helm 2, it would generate a patch, comparing the old manifest against the new\nmanifest. Because this is a rollback, it's the same manifest. Helm would\ndetermine that there is nothing to change because there is no difference between\nthe old manifest and the new manifest. The replica count continues to stay at\nzero. Panic ensues.\n\nIn Helm 3, the patch is generated using the old manifest, the live state, and\nthe new manifest. Helm recognizes that the old state was at three, the live\nstate is at zero and the new manifest wishes to change it back to three, so it\ngenerates a patch to change the state back to three.\n\n##### Upgrades where live state has changed\n\nMany service meshes and other controller-based applications inject data into\nKubernetes objects. This can be something like a sidecar, labels, or other\ninformation. Previously if you had the given manifest rendered from a Chart:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n```\n\nAnd the live state was modified by another application to\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.0.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\nNow, you want to upgrade the `nginx` image tag to `2.1.0`. So, you upgrade to a\nchart with the given manifest:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nWhat happens?\n\nIn Helm 2, Helm generates a patch of the `containers` object between the old\nmanifest and the new manifest. The cluster's live state is not considered during\nthe patch generation.\n\nThe cluster's live state is modified to look like the following:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n```\n\nThe sidecar pod is removed from live state. More panic ensues.\n\nIn Helm 3, Helm generates a patch of the `containers` object between the old\nmanifest, the live state, and the new manifest. It notices that the new manifest\nchanges the image tag to `2.1.0`, but live state contains a sidecar container.\n\nThe cluster's live state is modified to look like the following:\n\n```yaml\ncontainers:\n- name: server\n  image: nginx:2.1.0\n- name: my-injected-sidecar\n  image: my-cool-mesh:1.0.0\n```\n\n### Release Names are now scoped to the Namespace\n\nWith the removal of Tiller, the information about each release had to go\nsomewhere. In Helm 2, this was stored in the same namespace as Tiller. In\npractice, this meant that once a name was used by a release, no other release\ncould use that same name, even if it was deployed in a different namespace.\n\nIn Helm 3, information about a particular release is now stored in the same\nnamespace as the release itself. This means that users can now `helm install\nwordpress stable/wordpress` in two separate namespaces, and each can be referred\nwith `helm list` by changing the current namespace context (e.g. `helm list\n--namespace foo`).\n\nWith this greater alignment to native cluster namespaces, the `helm list`\ncommand no longer lists all releases by default. Instead, it will list only the\nreleases in the namespace of your current kubernetes context (i.e. the namespace\nshown when you run `kubectl config view --minify`). It also means you must\nsupply the `--all-namespaces` flag to `helm list` to get behaviour similar to\nHelm 2.\n\n### Secrets as the default storage driver\n\nIn Helm 3, Secrets are now used as the [default storage\ndriver](/topics/advanced.md#storage-backends). Helm 2 used ConfigMaps by\ndefault to store release information. In Helm 2.7.0, a new storage backend that\nuses Secrets for storing release information was implemented, and it is now the\ndefault starting in Helm 3.\n\nChanging to Secrets as the Helm 3 default allows for additional security in\nprotecting charts in conjunction with the release of Secret encryption in\nKubernetes.\n\n[Encrypting secrets at\nrest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) became\navailable as an alpha feature in Kubernetes 1.7 and became stable as of\nKubernetes 1.13. This allows users to encrypt Helm release metadata at rest, and\nso it is a good starting point that can be expanded later into using something\nlike Vault.\n\n### Go import path changes\n\nIn Helm 3, Helm switched the Go import path over from `k8s.io/helm` to\n`helm.sh/helm/v3`. If you intend to upgrade to the Helm 3 Go client libraries,\nmake sure to change your import paths.\n\n### Capabilities\n\nThe `.Capabilities` built-in object available during the rendering stage has\nbeen simplified.\n\n[Built-in Objects](/chart_template_guide/builtin_objects.md)\n\n### Validating Chart Values with JSONSchema\n\nA JSON Schema can now be imposed upon chart values. This ensures that values\nprovided by the user follow the schema laid out by the chart maintainer,\nproviding better error reporting when the user provides an incorrect set of\nvalues for a chart.\n\nValidation occurs when any of the following commands are invoked:\n\n* `helm install`\n* `helm upgrade`\n* `helm template`\n* `helm lint`\n\nSee the documentation on [Schema files](/topics/charts.md#schema-files) for\nmore information.\n\n### Consolidation of `requirements.yaml` into `Chart.yaml`\n\nThe Chart dependency management system moved from requirements.yaml and\nrequirements.lock to Chart.yaml and Chart.lock. We recommend that new charts\nmeant for Helm 3 use the new format. However, Helm 3 still understands Chart API\nversion 1 (`v1`) and will load existing `requirements.yaml` files\n\nIn Helm 2, this is how a `requirements.yaml` looked:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nIn Helm 3, the dependency is expressed the same way, but now from your\n`Chart.yaml`:\n\n```yaml\ndependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https://charts.helm.sh/stable\n  condition: mariadb.enabled\n  tags:\n    - database\n```\n\nCharts are still downloaded and placed in the `charts/` directory, so subcharts\nvendored into the `charts/` directory will continue to work without\nmodification.\n\n### Name (or --generate-name) is now required on install\n\nIn Helm 2, if no name was provided, an auto-generated name would be given. In\nproduction, this proved to be more of a nuisance than a helpful feature. In Helm\n3, Helm will throw an error if no name is provided with `helm install`.\n\nFor those who still wish to have a name auto-generated for you, you can use the\n`--generate-name` flag to create one for you.\n\n### Pushing Charts to OCI Registries\n\nThis is an experimental feature introduced in Helm 3. To use, set the\nenvironment variable `HELM_EXPERIMENTAL_OCI=1`.\n\nAt a high level, a Chart Repository is a location where Charts can be stored and\nshared. The Helm client packs and ships Helm Charts to a Chart Repository.\nSimply put, a Chart Repository is a basic HTTP server that houses an index.yaml\nfile and some packaged charts.\n\nWhile there are several benefits to the Chart Repository API meeting the most\nbasic storage requirements, a few drawbacks have started to show:\n\n- Chart Repositories have a very hard time abstracting most of the security\n  implementations required in a production environment. Having a standard API\n  for authentication and authorization is very important in production\n  scenarios.\n- Helm’s Chart provenance tools used for signing and verifying the integrity and\n  origin of a chart are an optional piece of the Chart publishing process.\n- In multi-tenant scenarios, the same Chart can be uploaded by another tenant,\n  costing twice the storage cost to store the same content. Smarter chart\n  repositories have been designed to handle this, but it’s not a part of the\n  formal specification.\n- Using a single index file for search, metadata information, and fetching\n  Charts has made it difficult or clunky to design around in secure multi-tenant\n  implementations.\n\nDocker’s Distribution project (also known as Docker Registry v2) is the\nsuccessor to the Docker Registry project. Many major cloud vendors have a\nproduct offering of the Distribution project, and with so many vendors offering\nthe same product, the Distribution project has benefited from many years of\nhardening, security best practices, and battle-testing.\n\nPlease have a look at `helm help chart` and `helm help registry` for more\ninformation on how to package a chart and push it to a Docker registry.\n\nFor more info, please see [this page](/topics/registries.md).\n\n### Removal of `helm serve`\n\n`helm serve` ran a local Chart Repository on your machine for development\npurposes. However, it didn't receive much uptake as a development tool and had\nnumerous issues with its design. In the end, we decided to remove it and split\nit out as a plugin.\n\nFor a similar experience to `helm serve`, have a look at the local filesystem\nstorage option in\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\nand the [servecm plugin](https://github.com/jdolitsky/helm-servecm).\n\n\n### Library chart support\n\nHelm 3 supports a class of chart called a “library chart”. This is a chart that\nis shared by other charts, but does not create any release artifacts of its own.\nA library chart’s templates can only declare `define` elements. Globally scoped\nnon-`define` content is simply ignored. This allows users to re-use and share\nsnippets of code that can be re-used across many charts, avoiding redundancy and\nkeeping charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nLibrary charts are declared in the dependencies directive in Chart.yaml, and are\ninstalled and managed like any other chart.\n\n```yaml\ndependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io\n```\n\nWe’re very excited to see the use cases this feature opens up for chart\ndevelopers, as well as any best practices that arise from consuming library\ncharts.\n\n### Chart.yaml apiVersion bump\n\nWith the introduction of library chart support and the consolidation of\nrequirements.yaml into Chart.yaml, clients that understood Helm 2's package\nformat won't understand these new features. So, we bumped the apiVersion in\nChart.yaml from `v1` to `v2`.\n\n`helm create` now creates charts using this new format, so the default\napiVersion was bumped there as well.\n\nClients wishing to support both versions of Helm charts should inspect the\n`apiVersion` field in Chart.yaml to understand how to parse the package format.\n\n### XDG Base Directory Support\n\n[The XDG Base Directory\nSpecification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)\nis a portable standard defining where configuration, data, and cached files\nshould be stored on the filesystem.\n\nIn Helm 2, Helm stored all this information in `~/.helm` (affectionately known\nas `helm home`), which could be changed by setting the `$HELM_HOME` environment\nvariable, or by using the global flag `--home`.\n\nIn Helm 3, Helm now respects the following environment variables as per the XDG\nBase Directory Specification:\n\n- `$XDG_CACHE_HOME`\n- `$XDG_CONFIG_HOME`\n- `$XDG_DATA_HOME`\n\nHelm plugins are still passed `$HELM_HOME` as an alias to `$XDG_DATA_HOME` for\nbackwards compatibility with plugins looking to use `$HELM_HOME` as a scratchpad\nenvironment.\n\nSeveral new environment variables are also passed in to the plugin's environment\nto accommodate this change:\n\n- `$HELM_PATH_CACHE` for the cache path\n- `$HELM_PATH_CONFIG` for the config path\n- `$HELM_PATH_DATA` for the data path\n\nHelm plugins looking to support Helm 3 should consider using these new\nenvironment variables instead.\n\n### CLI Command Renames\n\nIn order to better align the verbiage from other package managers, `helm delete`\nwas re-named to `helm uninstall`. `helm delete` is still retained as an alias to\n`helm uninstall`, so either form can be used.\n\nIn Helm 2, in order to purge the release ledger, the `--purge` flag had to be\nprovided. This functionality is now enabled by default. To retain the previous\nbehavior, use `helm uninstall --keep-history`.\n\nAdditionally, several other commands were re-named to accommodate the same\nconventions:\n\n- `helm inspect` -> `helm show`\n- `helm fetch` -> `helm pull`\n\nThese commands have also retained their older verbs as aliases, so you can\ncontinue to use them in either form.\n\n### Automatically creating namespaces\n\nWhen creating a release in a namespace that does not exist, Helm 2 created the\nnamespace.  Helm 3 follows the behavior of other Kubernetes tooling and returns\nan error if the namespace does not exist.  Helm 3 will create the namespace if\nyou explicitly specify `--create-namespace` flag.\n\n### What happened to .Chart.ApiVersion?\n\nHelm follows the typical convention for CamelCasing which is to capitalize an\nacronym. We have done this elsewhere in the code, such as with\n`.Capabilities.APIVersions.Has`. In Helm v3, we corrected `.Chart.ApiVersion`\nto follow this pattern, renaming it to `.Chart.APIVersion`.\n\n"
  },
  {
    "path": "versioned_docs/version-3/faq/index.mdx",
    "content": "---\ntitle: Frequently Asked Questions\nsidebar_position: 9\n---\n\n# Frequently Asked Questions\n\n> This section provides help with the most common questions.\n\n**We'd love your help** making this document better. To add, correct, or remove\ninformation, [file an issue](https://github.com/helm/helm-www/issues) or send us\na pull request.\n\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/faq/installing.md",
    "content": "---\ntitle: Installing\nsidebar_position: 2\n---\n\n## Installing\n\n### Why aren't there native packages of Helm for Fedora and other Linux distros?\n\nThe Helm project does not maintain packages for operating systems and\nenvironments. The Helm community may provide native packages and if the Helm\nproject is made aware of them they will be listed. This is how the Homebrew\nformula was started and listed. If you're interested in maintaining a package,\nwe'd love it.\n\n### Why do you provide a `curl ...|bash` script?\n\nThere is a script in our repository (`scripts/get-helm-3`) that can be executed\nas a `curl ..|bash` script. The transfers are all protected by HTTPS, and the\nscript does some auditing of the packages it fetches. However, the script has\nall the usual dangers of any shell script.\n\nWe provide it because it is useful, but we suggest that users carefully read the\nscript first. What we'd really like, though, are better packaged releases of\nHelm.\n\n### How do I put the Helm client files somewhere other than their defaults?\n\nHelm uses the XDG structure for storing files. There are environment variables\nyou can use to override these locations:\n\n- `$XDG_CACHE_HOME`: set an alternative location for storing cached files.\n- `$XDG_CONFIG_HOME`: set an alternative location for storing Helm\n  configuration.\n- `$XDG_DATA_HOME`: set an alternative location for storing Helm data.\n\nNote that if you have existing repositories, you will need to re-add them with\n`helm repo add...`.\n\n"
  },
  {
    "path": "versioned_docs/version-3/faq/troubleshooting.md",
    "content": "---\ntitle: Troubleshooting\nsidebar_position: 4\n---\n\n## Troubleshooting\n\n### I am getting a warning about \"Unable to get an update from the \"stable\" chart repository\"\n\nRun `helm repo list`. If it shows your `stable` repository pointing to a `storage.googleapis.com` URL, you\nwill 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\n`https://charts.helm.sh/stable` but will no longer receive updates. \n\nYou can run the following command to fix your repository:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nThe same goes for the `incubator` repository, which has an archive available at https://charts.helm.sh/incubator.\nYou can run the following command to repair it:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### I am getting the warning 'WARNING: \"kubernetes-charts.storage.googleapis.com\" is deprecated for \"stable\" and will be deleted Nov. 13, 2020.'\n\nThe old Google helm chart repository has been replaced by a new Helm chart repository.\n\nRun the following command to permanently fix this:\n\n```console\n$ helm repo add stable https://charts.helm.sh/stable --force-update  \n```\n\nIf you get a similar error for `incubator`, run this command:\n\n```console\n$ helm repo add incubator https://charts.helm.sh/incubator --force-update  \n```\n\n### When I add a Helm repo, I get the error 'Error: Repo \"https://kubernetes-charts.storage.googleapis.com\" is no longer available'\n\nThe Helm Chart repositories are no longer supported after [a year-long deprecation period](https://github.com/helm/charts#deprecation-timeline). \nArchives 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\n`helm repo add` will not let you add the old URLs unless you specify `--use-deprecated-repos`.\n\n### On GKE (Google Container Engine) I get \"No SSH tunnels currently open\"\n\n```\nError: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user \"gke-[redacted]\"?\n```\n\nAnother variation of the error message is:\n\n\n```\nUnable to connect to the server: x509: certificate signed by unknown authority\n```\n\nThe issue is that your local Kubernetes config file must have the correct\ncredentials.\n\nWhen you create a cluster on GKE, it will give you credentials, including SSL\ncertificates and certificate authorities. These need to be stored in a\nKubernetes config file (Default: `~/.kube/config`) so that `kubectl` and `helm`\ncan access them.\n\n### After migration from Helm 2, `helm list` shows only some (or none) of my releases\n\nIt is likely that you have missed the fact that Helm 3 now uses cluster\nnamespaces throughout to scope releases. This means that for all commands\nreferencing a release you must either:\n\n* rely on the current namespace in the active kubernetes context (as described\n  by the `kubectl config view --minify` command),\n* specify the correct namespace using the `--namespace`/`-n` flag, or\n* for the `helm list` command, specify the `--all-namespaces`/`-A` flag\n\nThis applies to `helm ls`, `helm uninstall`, and all other `helm` commands\nreferencing a release.\n\n\n### On macOS, the file `/etc/.mdns_debug` is accessed. Why?\n\nWe are aware of a case on macOS where Helm will try to access a file named\n`/etc/.mdns_debug`. If the file exists, Helm holds the file handle open while it\nexecutes.\n\nThis is caused by macOS's MDNS library. It attempts to load that file to read\ndebugging settings (if enabled). The file handle probably should not be held open, and\nthis issue has been reported to Apple. However, it is macOS, not Helm, that causes this\nbehavior.\n\nIf you do not want Helm to load this file, you may be able to compile Helm to as\na static library that does not use the host network stack. Doing so will inflate the\nbinary size of Helm, but will prevent the file from being open.\n\nThis issue was originally flagged as a potential security problem. But it has since\nbeen determined that there is no flaw or vulnerability caused by this behavior.\n\n### helm repo add fails when it used to work\n\nIn helm 3.3.1 and before, the command `helm repo add <reponame> <url>` will give\nno output if you attempt to add a repo which already exists. The flag\n`--no-update` would raise an error if the repo was already registered.\n\nIn helm 3.3.2 and beyond, an attempt to add an existing repo will error:\n\n`Error: repository name (reponame) already exists, please specify a different name`\n\nThe default behavior is now reversed. `--no-update` is now ignored, while if you\nwant to replace (overwrite) an existing repo, you can use `--force-update`.\n\nThis is due to a breaking change for a security fix as explained in the [Helm\n3.3.2 release notes](https://github.com/helm/helm/releases/tag/v3.3.2).\n\n### Enabling Kubernetes client logging\n\nPrinting log messages for debugging the Kubernetes client can be enabled using\nthe [klog](https://pkg.go.dev/k8s.io/klog) flags. Using the `-v` flag to set\nverbosity level will be enough for most cases.\n\nFor example:\n\n```\nhelm list -v 6\n```\n\n### Tiller installations stopped working and access is denied\n\nHelm releases used to be available from <https://storage.googleapis.com/kubernetes-helm/>. 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.\n\n\nIf 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:\n\n```\n<Error>\n    <Code>AccessDenied</Code>\n    <Message>Access denied.</Message>\n    <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>\n</Error>\n```\n\nThe [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:\n\n`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz`\n\nwith:\n\n`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz`\n\nTo initialize with Helm v2.17.0:\n\n`helm init —upgrade`\n\nOr if a different version is needed, use the --tiller-image flag to override the default location and install a specific Helm v2 version:\n\n`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9`\n\n**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.\n"
  },
  {
    "path": "versioned_docs/version-3/faq/uninstalling.md",
    "content": "---\ntitle: Uninstalling\nsidebar_position: 3\n---\n\n## Uninstalling\n\n### I want to delete my local Helm. Where are all its files?\n\nAlong with the `helm` binary, Helm stores some files in the following locations:\n\n- $XDG_CACHE_HOME\n- $XDG_CONFIG_HOME\n- $XDG_DATA_HOME\n\nThe following table gives the default folder for each of these, by OS:\n\n| Operating System | Cache Path                  | Configuration Path               | Data Path                 |\n|------------------|-----------------------------|----------------------------------|---------------------------|\n| Linux            | `$HOME/.cache/helm `        | `$HOME/.config/helm `            | `$HOME/.local/share/helm` |\n| macOS            | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm `     |\n| Windows          | `%TEMP%\\helm  `             | `%APPDATA%\\helm `                | `%APPDATA%\\helm`          |\n\n"
  },
  {
    "path": "versioned_docs/version-3/glossary/index.mdx",
    "content": "---\ntitle: Glossary\ndescription: Terms used to describe components of Helm's architecture.\nsidebar_position: 10\n---\n\n# Glossary\n\n## Chart\n\nA Helm package that contains information sufficient for installing a set of\nKubernetes resources into a Kubernetes cluster.\n\nCharts contain a `Chart.yaml` file as well as templates, default values\n(`values.yaml`), and dependencies.\n\nCharts are developed in a well-defined directory structure, and then packaged\ninto an archive format called a _chart archive_.\n\n## Chart Archive\n\nA _chart archive_ is a tarred and gzipped (and optionally signed) chart.\n\n## Chart Dependency (Subcharts)\n\nCharts may depend upon other charts. There are two ways a dependency may occur:\n\n- Soft dependency: A chart may simply not function without another chart being\n  installed in a cluster. Helm does not provide tooling for this case. In this\n  case, dependencies may be managed separately.\n- Hard dependency: A chart may contain (inside of its `charts/` directory)\n  another chart upon which it depends. In this case, installing the chart will\n  install all of its dependencies. In this case, a chart and its dependencies\n  are managed as a collection.\n\nWhen a chart is packaged (via `helm package`) all of its hard dependencies are\nbundled with it.\n\n## Chart Version\n\nCharts are versioned according to the [SemVer 2 spec](https://semver.org). A\nversion number is required on every chart.\n\n## Chart.yaml\n\nInformation about a chart is stored in a special file called `Chart.yaml`. Every\nchart must have this file.\n\n## Helm (and helm)\n\nHelm is the package manager for Kubernetes. As an operating system package\nmanager makes it easy to install tools on an OS, Helm makes it easy to install\napplications and resources into Kubernetes clusters.\n\nWhile _Helm_ is the name of the project, the command line client is also named\n`helm`. By convention, when speaking of the project, _Helm_ is capitalized. When\nspeaking of the client, _helm_ is in lowercase.\n\n## Helm Configuration Files (XDG)\n\nHelm stores its configuration files in XDG directories. These directories are\ncreated the first time `helm` is run.\n\n## Kube Config (KUBECONFIG)\n\nThe Helm client learns about Kubernetes clusters by using files in the _Kube\nconfig_ file format. By default, Helm attempts to find this file in the place\nwhere `kubectl` creates it (`$HOME/.kube/config`).\n\n## Lint (Linting)\n\nTo _lint_ a chart is to validate that it follows the conventions and\nrequirements of the Helm chart standard. Helm provides tools to do this, notably\nthe `helm lint` command.\n\n## Provenance (Provenance file)\n\nHelm charts may be accompanied by a _provenance file_ which provides information\nabout where the chart came from and what it contains.\n\nProvenance files are one part of the Helm security story. A provenance contains\na cryptographic hash of the chart archive file, the Chart.yaml data, and a\nsignature block (an OpenPGP \"clearsign\" block). When coupled with a keychain,\nthis provides chart users with the ability to:\n\n- Validate that a chart was signed by a trusted party\n- Validate that the chart file has not been tampered with\n- Validate the contents of a chart metadata (`Chart.yaml`)\n- Quickly match a chart to its provenance data\n\nProvenance files have the `.prov` extension, and can be served from a chart\nrepository server or any other HTTP server.\n\n## Release\n\nWhen a chart is installed, the Helm library creates a _release_ to track that\ninstallation.\n\nA single chart may be installed many times into the same cluster, and create\nmany different releases. For example, one can install three PostgreSQL databases\nby running `helm install` three times with a different release name.\n\n## Release Number (Release Version)\n\nA single release can be updated multiple times. A sequential counter is used to\ntrack releases as they change. After a first `helm install`, a release will have\n_release number_ 1. Each time a release is upgraded or rolled back, the release\nnumber will be incremented.\n\n## Rollback\n\nA release can be upgraded to a newer chart or configuration. But since release\nhistory is stored, a release can also be _rolled back_ to a previous release\nnumber. This is done with the `helm rollback` command.\n\nImportantly, a rolled back release will receive a new release number.\n\n| Operation  | Release Number                                       |\n|------------|------------------------------------------------------|\n| install    | release 1                                            |\n| upgrade    | release 2                                            |\n| upgrade    | release 3                                            |\n| rollback 1 | release 4 (but running the same config as release 1) |\n\nThe above table illustrates how release numbers increment across install,\nupgrade, and rollback.\n\n## Helm Library (or SDK)\n\nThe Helm Library (or SDK) refers to the Go code that interacts directly with the\nKubernetes API server to install, upgrade, query, and remove Kubernetes\nresources. It can be imported into a project to use Helm as a client library\ninstead of a CLI.\n\n## Repository (Repo, Chart Repository)\n\nHelm charts may be stored on dedicated HTTP servers called _chart repositories_\n(_repositories_, or just _repos_).\n\nA chart repository server is a simple HTTP server that can serve an `index.yaml`\nfile that describes a batch of charts, and provides information on where each\nchart can be downloaded from. (Many chart repositories serve the charts as well\nas the `index.yaml` file.)\n\nA Helm client can point to zero or more chart repositories. By default, Helm\nclients are not configured with any chart repositories. Chart repositories can\nbe added at any time using the `helm repo add` command.\n\n## Chart Registry (OCI-based Registry)\n\nA 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/).\n\n## Values (Values Files, values.yaml)\n\nValues provide a way to override template defaults with your own information.\n\nHelm Charts are \"parameterized\", which means the chart developer may expose\nconfiguration that can be overridden at installation time. For example, a chart\nmay expose a `username` field that allows setting a user name for a service.\n\nThese exposed variables are called _values_ in Helm parlance.\n\nValues can be set during `helm install` and `helm upgrade` operations, either by\npassing them in directly, or by using a `values.yaml` file.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/helm/_category_.json",
    "content": "{\n  \"link\": {\n    \"type\": \"doc\",\n    \"id\": \"helm-category\"\n  }\n}\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm.md",
    "content": "---\ntitle: helm\nslug: helm\n---\n\nThe Helm package manager for Kubernetes.\n\n### Synopsis\n\nThe Kubernetes package manager\n\nCommon actions for Helm:\n\n- helm search:    search for charts\n- helm pull:      download a chart to your local directory to view\n- helm install:   upload the chart to Kubernetes\n- helm list:      list releases of charts\n\nEnvironment variables:\n\n| Name                               | Description                                                                                                |\n|------------------------------------|------------------------------------------------------------------------------------------------------------|\n| $HELM_CACHE_HOME                   | set an alternative location for storing cached files.                                                      |\n| $HELM_CONFIG_HOME                  | set an alternative location for storing Helm configuration.                                                |\n| $HELM_DATA_HOME                    | set an alternative location for storing Helm data.                                                         |\n| $HELM_DEBUG                        | indicate whether or not Helm is running in Debug mode                                                      |\n| $HELM_DRIVER                       | set the backend storage driver. Values are: configmap, secret, memory, sql.                                |\n| $HELM_DRIVER_SQL_CONNECTION_STRING | set the connection string the SQL storage driver should use.                                               |\n| $HELM_MAX_HISTORY                  | set the maximum number of helm release history.                                                            |\n| $HELM_NAMESPACE                    | set the namespace used for the helm operations.                                                            |\n| $HELM_NO_PLUGINS                   | disable plugins. Set HELM_NO_PLUGINS=1 to disable plugins.                                                 |\n| $HELM_PLUGINS                      | set the path to the plugins directory                                                                      |\n| $HELM_REGISTRY_CONFIG              | set the path to the registry config file.                                                                  |\n| $HELM_REPOSITORY_CACHE             | set the path to the repository cache directory                                                             |\n| $HELM_REPOSITORY_CONFIG            | set the path to the repositories file.                                                                     |\n| $KUBECONFIG                        | set an alternative Kubernetes configuration file (default \"~/.kube/config\")                                |\n| $HELM_KUBEAPISERVER                | set the Kubernetes API Server Endpoint for authentication                                                  |\n| $HELM_KUBECAFILE                   | set the Kubernetes certificate authority file.                                                             |\n| $HELM_KUBEASGROUPS                 | set the Groups to use for impersonation using a comma-separated list.                                      |\n| $HELM_KUBEASUSER                   | set the Username to impersonate for the operation.                                                         |\n| $HELM_KUBECONTEXT                  | set the name of the kubeconfig context.                                                                    |\n| $HELM_KUBETOKEN                    | set the Bearer KubeToken used for authentication.                                                          |\n| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indicate if the Kubernetes API server's certificate validation should be skipped (insecure)                |\n| $HELM_KUBETLS_SERVER_NAME          | set the server name used to validate the Kubernetes API server certificate                                 |\n| $HELM_BURST_LIMIT                  | set the default burst limit in the case the server contains many CRDs (default 100, -1 to disable)         |\n| $HELM_QPS                          | set the Queries Per Second in cases where a high number of calls exceed the option for higher burst values |\n\nHelm stores cache, configuration, and data based on the following configuration order:\n\n- If a HELM_*_HOME environment variable is set, it will be used\n- Otherwise, on systems supporting the XDG base directory specification, the XDG variables will be used\n- When no other location is set a default location will be used based on the operating system\n\nBy default, the default directories depend on the Operating System. The defaults are listed below:\n\n| Operating System | Cache Path                | Configuration Path             | Data Path               |\n|------------------|---------------------------|--------------------------------|-------------------------|\n| Linux            | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm |\n| macOS            | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm      |\n| Windows          | %TEMP%\\helm               | %APPDATA%\\helm                 | %APPDATA%\\helm          |\n\n\n### Options\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n  -h, --help                            help for helm\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n* [helm create](/helm/helm_create.md)\t - create a new chart with the given name\n* [helm dependency](/helm/helm_dependency.md)\t - manage a chart's dependencies\n* [helm env](/helm/helm_env.md)\t - helm client environment information\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n* [helm history](/helm/helm_history.md)\t - fetch release history\n* [helm install](/helm/helm_install.md)\t - install a chart\n* [helm lint](/helm/helm_lint.md)\t - examine a chart for possible issues\n* [helm list](/helm/helm_list.md)\t - list releases\n* [helm package](/helm/helm_package.md)\t - package a chart directory into a chart archive\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n* [helm pull](/helm/helm_pull.md)\t - download a chart from a repository and (optionally) unpack it in local directory\n* [helm push](/helm/helm_push.md)\t - push a chart to remote\n* [helm registry](/helm/helm_registry.md)\t - login to or logout from a registry\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n* [helm rollback](/helm/helm_rollback.md)\t - roll back a release to a previous revision\n* [helm search](/helm/helm_search.md)\t - search for a keyword in charts\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n* [helm status](/helm/helm_status.md)\t - display the status of the named release\n* [helm template](/helm/helm_template.md)\t - locally render templates\n* [helm test](/helm/helm_test.md)\t - run tests for a release\n* [helm uninstall](/helm/helm_uninstall.md)\t - uninstall a release\n* [helm upgrade](/helm/helm_upgrade.md)\t - upgrade a release\n* [helm verify](/helm/helm_verify.md)\t - verify that a chart at the given path has been signed and is valid\n* [helm version](/helm/helm_version.md)\t - print the client version information\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_completion.md",
    "content": "---\ntitle: helm completion\n---\n\ngenerate autocompletion scripts for the specified shell\n\n### Synopsis\n\n\nGenerate autocompletion scripts for Helm for the specified shell.\n\n\n### Options\n\n```\n  -h, --help   help for completion\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm completion bash](/helm/helm_completion_bash.md)\t - generate autocompletion script for bash\n* [helm completion fish](/helm/helm_completion_fish.md)\t - generate autocompletion script for fish\n* [helm completion powershell](/helm/helm_completion_powershell.md)\t - generate autocompletion script for powershell\n* [helm completion zsh](/helm/helm_completion_zsh.md)\t - generate autocompletion script for zsh\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_completion_bash.md",
    "content": "---\ntitle: helm completion bash\n---\n\ngenerate autocompletion script for bash\n\n### Synopsis\n\n\nGenerate the autocompletion script for Helm for the bash shell.\n\nTo load completions in your current shell session:\n\n    source <(helm completion bash)\n\nTo load completions for every new session, execute once:\n- Linux:\n\n      helm completion bash > /etc/bash_completion.d/helm\n\n- MacOS:\n\n      helm completion bash > /usr/local/etc/bash_completion.d/helm\n\n\n```\nhelm completion bash [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for bash\n      --no-descriptions   disable completion descriptions\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_completion_fish.md",
    "content": "---\ntitle: helm completion fish\n---\n\ngenerate autocompletion script for fish\n\n### Synopsis\n\n\nGenerate the autocompletion script for Helm for the fish shell.\n\nTo load completions in your current shell session:\n\n    helm completion fish | source\n\nTo load completions for every new session, execute once:\n\n    helm completion fish > ~/.config/fish/completions/helm.fish\n\nYou will need to start a new shell for this setup to take effect.\n\n\n```\nhelm completion fish [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for fish\n      --no-descriptions   disable completion descriptions\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_completion_powershell.md",
    "content": "---\ntitle: helm completion powershell\n---\n\ngenerate autocompletion script for powershell\n\n### Synopsis\n\n\nGenerate the autocompletion script for powershell.\n\nTo load completions in your current shell session:\nPS C:\\> helm completion powershell | Out-String | Invoke-Expression\n\nTo load completions for every new session, add the output of the above command\nto your powershell profile.\n\n\n```\nhelm completion powershell [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for powershell\n      --no-descriptions   disable completion descriptions\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_completion_zsh.md",
    "content": "---\ntitle: helm completion zsh\n---\n\ngenerate autocompletion script for zsh\n\n### Synopsis\n\n\nGenerate the autocompletion script for Helm for the zsh shell.\n\nTo load completions in your current shell session:\n\n    source <(helm completion zsh)\n\nTo load completions for every new session, execute once:\n\n    helm completion zsh > \"${fpath[1]}/_helm\"\n\n\n```\nhelm completion zsh [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for zsh\n      --no-descriptions   disable completion descriptions\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm completion](/helm/helm_completion.md)\t - generate autocompletion scripts for the specified shell\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_create.md",
    "content": "---\ntitle: helm create\n---\n\ncreate a new chart with the given name\n\n### Synopsis\n\n\nThis command creates a chart directory along with the common files and\ndirectories used in a chart.\n\nFor example, 'helm create foo' will create a directory structure that looks\nsomething like this:\n\n    foo/\n    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.\n    ├── Chart.yaml    # Information about your chart\n    ├── values.yaml   # The default values for your templates\n    ├── charts/       # Charts that this chart depends on\n    └── templates/    # The template files\n        └── tests/    # The test files\n\n'helm create' takes a path for an argument. If directories in the given path\ndo not exist, Helm will attempt to create them as it goes. If the given\ndestination exists and there are files in that directory, conflicting files\nwill be overwritten, but other files will be left alone.\n\n\n```\nhelm create NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help             help for create\n  -p, --starter string   the name or absolute path to Helm starter scaffold\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_dependency.md",
    "content": "---\ntitle: helm dependency\n---\n\nmanage a chart's dependencies\n\n### Synopsis\n\n\nManage the dependencies of a chart.\n\nHelm charts store their dependencies in 'charts/'. For chart developers, it is\noften easier to manage dependencies in 'Chart.yaml' which declares all\ndependencies.\n\nThe dependency commands operate on that file, making it easy to synchronize\nbetween the desired dependencies and the actual dependencies stored in the\n'charts/' directory.\n\nFor example, this Chart.yaml declares two dependencies:\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"https://example.com/charts\"\n    - name: memcached\n      version: \"3.2.1\"\n      repository: \"https://another.example.com/charts\"\n\n\nThe 'name' should be the name of a chart, where that name must match the name\nin that chart's 'Chart.yaml' file.\n\nThe 'version' field should contain a semantic version or version range.\n\nThe 'repository' URL should point to a Chart Repository. Helm expects that by\nappending '/index.yaml' to the URL, it should be able to retrieve the chart\nrepository's index. Note: 'repository' can be an alias. The alias must start\nwith 'alias:' or '@'.\n\nStarting from 2.2.0, repository can be defined as the path to the directory of\nthe dependency charts stored locally. The path should start with a prefix of\n\"file://\". For example,\n\n    # Chart.yaml\n    dependencies:\n    - name: nginx\n      version: \"1.2.3\"\n      repository: \"file://../dependency_chart/nginx\"\n\nIf the dependency chart is retrieved locally, it is not required to have the\nrepository added to helm by \"helm add repo\". Version matching is also supported\nfor this case.\n\n\n### Options\n\n```\n  -h, --help   help for dependency\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm dependency build](/helm/helm_dependency_build.md)\t - rebuild the charts/ directory based on the Chart.lock file\n* [helm dependency list](/helm/helm_dependency_list.md)\t - list the dependencies for the given chart\n* [helm dependency update](/helm/helm_dependency_update.md)\t - update charts/ based on the contents of Chart.yaml\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_dependency_build.md",
    "content": "---\ntitle: helm dependency build\n---\n\nrebuild the charts/ directory based on the Chart.lock file\n\n### Synopsis\n\n\nBuild out the charts/ directory from the Chart.lock file.\n\nBuild is used to reconstruct a chart's dependencies to the state specified in\nthe lock file. This will not re-negotiate dependencies, as 'helm dependency update'\ndoes.\n\nIf no lock file is found, 'helm dependency build' will mirror the behavior\nof 'helm dependency update'.\n\n\n```\nhelm dependency build CHART [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for build\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm dependency](/helm/helm_dependency.md)\t - manage a chart's dependencies\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_dependency_list.md",
    "content": "---\ntitle: helm dependency list\n---\n\nlist the dependencies for the given chart\n\n### Synopsis\n\n\nList all of the dependencies declared in a chart.\n\nThis can take chart archives and chart directories as input. It will not alter\nthe contents of a chart.\n\nThis will produce an error if the chart cannot be loaded.\n\n\n```\nhelm dependency list CHART [flags]\n```\n\n### Options\n\n```\n  -h, --help                 help for list\n      --max-col-width uint   maximum column width for output table (default 80)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm dependency](/helm/helm_dependency.md)\t - manage a chart's dependencies\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_dependency_update.md",
    "content": "---\ntitle: helm dependency update\n---\n\nupdate charts/ based on the contents of Chart.yaml\n\n### Synopsis\n\n\nUpdate the on-disk dependencies to mirror Chart.yaml.\n\nThis command verifies that the required charts, as expressed in 'Chart.yaml',\nare present in 'charts/' and are at an acceptable version. It will pull down\nthe latest charts that satisfy the dependencies, and clean up old dependencies.\n\nOn successful update, this will generate a lock file that can be used to\nrebuild the dependencies to an exact version.\n\nDependencies are not required to be represented in 'Chart.yaml'. For that\nreason, an update command will not remove charts unless they are (a) present\nin the Chart.yaml file, but (b) at the wrong version.\n\n\n```\nhelm dependency update CHART [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -h, --help                       help for update\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --skip-refresh               do not refresh the local repository cache\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the packages against signatures\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm dependency](/helm/helm_dependency.md)\t - manage a chart's dependencies\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_env.md",
    "content": "---\ntitle: helm env\n---\n\nhelm client environment information\n\n### Synopsis\n\n\nEnv prints out all the environment information in use by Helm.\n\n\n```\nhelm env [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for env\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_get.md",
    "content": "---\ntitle: helm get\n---\n\ndownload extended information of a named release\n\n### Synopsis\n\n\nThis command consists of multiple subcommands which can be used to\nget extended information about the release, including:\n\n- The values used to generate the release\n- The generated manifest file\n- The notes provided by the chart of the release\n- The hooks associated with the release\n- The metadata of the release\n\n\n### Options\n\n```\n  -h, --help   help for get\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm get all](/helm/helm_get_all.md)\t - download all information for a named release\n* [helm get hooks](/helm/helm_get_hooks.md)\t - download all hooks for a named release\n* [helm get manifest](/helm/helm_get_manifest.md)\t - download the manifest for a named release\n* [helm get metadata](/helm/helm_get_metadata.md)\t - This command fetches metadata for a given release\n* [helm get notes](/helm/helm_get_notes.md)\t - download the notes for a named release\n* [helm get values](/helm/helm_get_values.md)\t - download the values file for a named release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_get_all.md",
    "content": "---\ntitle: helm get all\n---\n\ndownload all information for a named release\n\n### Synopsis\n\n\nThis command prints a human readable collection of information about the\nnotes, hooks, supplied values, and generated manifest file of the given release.\n\n\n```\nhelm get all RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for all\n      --revision int      get the named release with revision\n      --template string   go template for formatting the output, eg: {{.Release.Name}}\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_get_hooks.md",
    "content": "---\ntitle: helm get hooks\n---\n\ndownload all hooks for a named release\n\n### Synopsis\n\n\nThis command downloads hooks for a given release.\n\nHooks are formatted in YAML and separated by the YAML '---\\n' separator.\n\n\n```\nhelm get hooks RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help           help for hooks\n      --revision int   get the named release with revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_get_manifest.md",
    "content": "---\ntitle: helm get manifest\n---\n\ndownload the manifest for a named release\n\n### Synopsis\n\n\nThis command fetches the generated manifest for a given release.\n\nA manifest is a YAML-encoded representation of the Kubernetes resources that\nwere generated from this release's chart(s). If a chart is dependent on other\ncharts, those resources will also be included in the manifest.\n\n\n```\nhelm get manifest RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help           help for manifest\n      --revision int   get the named release with revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_get_metadata.md",
    "content": "---\ntitle: helm get metadata\n---\n\nThis command fetches metadata for a given release\n\n```\nhelm get metadata RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help            help for metadata\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    specify release revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_get_notes.md",
    "content": "---\ntitle: helm get notes\n---\n\ndownload the notes for a named release\n\n### Synopsis\n\n\nThis command shows notes provided by the chart of a named release.\n\n\n```\nhelm get notes RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help           help for notes\n      --revision int   get the named release with revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_get_values.md",
    "content": "---\ntitle: helm get values\n---\n\ndownload the values file for a named release\n\n### Synopsis\n\n\nThis command downloads a values file for a given release.\n\n\n```\nhelm get values RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -a, --all             dump all (computed) values\n  -h, --help            help for values\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int    get the named release with revision\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm get](/helm/helm_get.md)\t - download extended information of a named release\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_history.md",
    "content": "---\ntitle: helm history\n---\n\nfetch release history\n\n### Synopsis\n\n\nHistory prints historical revisions for a given release.\n\nA default maximum of 256 revisions will be returned. Setting '--max'\nconfigures the maximum length of the revision list returned.\n\nThe historical release set is printed as a formatted table, e.g:\n\n    $ helm history angry-bird\n    REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION\n    1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install\n    2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully\n    3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2\n    4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully\n\n\n```\nhelm history RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help            help for history\n      --max int         maximum number of revision to include in history (default 256)\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_install.md",
    "content": "---\ntitle: helm install\n---\n\ninstall a chart\n\n### Synopsis\n\n\nThis command installs a chart archive.\n\nThe install argument must be a chart reference, a path to a packaged chart,\na path to an unpacked chart directory or a URL.\n\nTo override values in a chart, use either the '--values' flag and pass in a file\nor use the '--set' flag and pass configuration from the command line, to force\na string value use '--set-string'. You can use '--set-file' to set individual\nvalues from a file when the value itself is too long for the command line\nor is dynamically generated. You can also use '--set-json' to set json values\n(scalars/objects/arrays) from the command line.\n\n    $ helm install -f myvalues.yaml myredis ./redis\n\nor\n\n    $ helm install --set name=prod myredis ./redis\n\nor\n\n    $ helm install --set-string long_int=1234567890 myredis ./redis\n\nor\n\n    $ helm install --set-file my_script=dothings.sh myredis ./redis\n\nor\n\n    $ helm install --set-json 'master.sidecars=[{\"name\":\"sidecar\",\"image\":\"myImage\",\"imagePullPolicy\":\"Always\",\"ports\":[{\"name\":\"portname\",\"containerPort\":1234}]}]' myredis ./redis\n\n\nYou can specify the '--values'/'-f' flag multiple times. The priority will be given to the\nlast (right-most) file specified. For example, if both myvalues.yaml and override.yaml\ncontained a key called 'Test', the value set in override.yaml would take precedence:\n\n    $ helm install -f myvalues.yaml -f override.yaml  myredis ./redis\n\nYou can specify the '--set' flag multiple times. The priority will be given to the\nlast (right-most) set specified. For example, if both 'bar' and 'newbar' values are\nset for a key called 'foo', the 'newbar' value would take precedence:\n\n    $ helm install --set foo=bar --set foo=newbar  myredis ./redis\n\nSimilarly, in the following example 'foo' is set to '[\"four\"]':\n\n    $ helm install --set-json='foo=[\"one\", \"two\", \"three\"]' --set-json='foo=[\"four\"]' myredis ./redis\n\nAnd in the following example, 'foo' is set to '{\"key1\":\"value1\",\"key2\":\"bar\"}':\n\n    $ helm install --set-json='foo={\"key1\":\"value1\",\"key2\":\"value2\"}' --set-json='foo.key2=\"bar\"' myredis ./redis\n\nTo check the generated manifests of a release without installing the chart,\nthe --debug and --dry-run flags can be combined.\n\nThe --dry-run flag will output all generated chart manifests, including Secrets\nwhich can contain sensitive values. To hide Kubernetes Secrets use the\n--hide-secret flag. Please carefully consider how and when these flags are used.\n\nIf --verify is set, the chart MUST have a provenance file, and the provenance\nfile MUST pass all verification steps.\n\nThere are six different ways you can express the chart you want to install:\n\n1. By chart reference: helm install mymaria example/mariadb\n2. By path to a packaged chart: helm install mynginx ./nginx-1.2.3.tgz\n3. By path to an unpacked chart directory: helm install mynginx ./nginx\n4. By absolute URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz\n5. By chart reference and repo url: helm install --repo https://example.com/charts/ mynginx nginx\n6. By OCI registries: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx\n\nCHART REFERENCES\n\nA chart reference is a convenient way of referencing a chart in a chart repository.\n\nWhen you use a chart reference with a repo prefix ('example/mariadb'), Helm will look in the local\nconfiguration for a chart repository named 'example', and will then look for a\nchart in that repository whose name is 'mariadb'. It will install the latest stable version of that chart\nuntil you specify '--devel' flag to also include development version (alpha, beta, and release candidate releases), or\nsupply a version number with the '--version' flag.\n\nTo see the list of chart repositories, use 'helm repo list'. To search for\ncharts in a repository, use 'helm search'.\n\n\n```\nhelm install [NAME] [CHART] [flags]\n```\n\n### Options\n\n```\n      --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\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for install\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_lint.md",
    "content": "---\ntitle: helm lint\n---\n\nexamine a chart for possible issues\n\n### Synopsis\n\n\nThis command takes a path to a chart and runs a series of tests to verify that\nthe chart is well-formed.\n\nIf the linter encounters things that will cause the chart to fail installation,\nit will emit [ERROR] messages. If it encounters issues that break with convention\nor recommendation, it will emit [WARNING] messages.\n\n\n```\nhelm lint PATH [flags]\n```\n\n### Options\n\n```\n  -h, --help                      help for lint\n      --kube-version string       Kubernetes version used for capabilities and deprecation checks\n      --quiet                     print only warnings and errors\n      --set stringArray           set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray      set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray   set a literal STRING value on the command line\n      --set-string stringArray    set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --skip-schema-validation    if set, disables JSON schema validation\n      --strict                    fail on lint warnings\n  -f, --values strings            specify values in a YAML file or a URL (can specify multiple)\n      --with-subcharts            lint dependent charts\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_list.md",
    "content": "---\ntitle: helm list\n---\n\nlist releases\n\n### Synopsis\n\n\nThis command lists all of the releases for a specified namespace (uses current namespace context if namespace not specified).\n\nBy default, it lists only releases that are deployed or failed. Flags like\n'--uninstalled' and '--all' will alter this behavior. Such flags can be combined:\n'--uninstalled --failed'.\n\nBy default, items are sorted alphabetically. Use the '-d' flag to sort by\nrelease date.\n\nIf the --filter flag is provided, it will be treated as a filter. Filters are\nregular expressions (Perl compatible) that are applied to the list of releases.\nOnly items that match the filter will be returned.\n\n    $ helm list --filter 'ara[a-z]+'\n    NAME                UPDATED                                  CHART\n    maudlin-arachnid    2020-06-18 14:17:46.125134977 +0000 UTC  alpine-0.1.0\n\nIf no results are found, 'helm list' will exit 0, but with no output (or in\nthe case of no '-q' flag, only headers).\n\nBy default, up to 256 items may be returned. To limit this, use the '--max' flag.\nSetting '--max' to 0 will not return all results. Rather, it will return the\nserver's default, which may be much higher than 256. Pairing the '--max'\nflag with the '--offset' flag allows you to page through results.\n\n\n```\nhelm list [flags]\n```\n\n### Options\n\n```\n  -a, --all                  show all releases without any filter applied\n  -A, --all-namespaces       list releases across all namespaces\n  -d, --date                 sort by release date\n      --deployed             show deployed releases. If no other is specified, this will be automatically enabled\n      --failed               show failed releases\n  -f, --filter string        a regular expression (Perl compatible). Any releases that match the expression will be included in the results\n  -h, --help                 help for list\n  -m, --max int              maximum number of releases to fetch (default 256)\n      --no-headers           don't print headers when using the default output format\n      --offset int           next release index in the list, used to offset from start value\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pending              show pending releases\n  -r, --reverse              reverse the sort order\n  -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.\n  -q, --short                output short (quiet) listing format\n      --superseded           show superseded releases\n      --time-format string   format time using golang time formatter. Example: --time-format \"2006-01-02 15:04:05Z0700\"\n      --uninstalled          show uninstalled releases (if 'helm uninstall --keep-history' was used)\n      --uninstalling         show releases that are currently being uninstalled\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_package.md",
    "content": "---\ntitle: helm package\n---\n\npackage a chart directory into a chart archive\n\n### Synopsis\n\n\nThis command packages a chart into a versioned chart archive file. If a path\nis given, this will look at that path for a chart (which must contain a\nChart.yaml file) and then package that directory.\n\nVersioned chart archives are used by Helm package repositories.\n\nTo sign a chart, use the '--sign' flag. In most cases, you should also\nprovide '--keyring path/to/secret/keys' and '--key keyname'.\n\n  $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg\n\nIf '--keyring' is not specified, Helm usually defaults to the public keyring\nunless your environment is otherwise configured.\n\n\n```\nhelm package [CHART_PATH] [...] [flags]\n```\n\n### Options\n\n```\n      --app-version string         set the appVersion on the chart to this version\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -u, --dependency-update          update dependencies from \"Chart.yaml\" to dir \"charts/\" before packaging\n  -d, --destination string         location to write the chart. (default \".\")\n  -h, --help                       help for package\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key string                 name of the key to use when signing. Used if --sign is true\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of a public keyring (default \"~/.gnupg/pubring.gpg\")\n      --passphrase-file string     location of a file which contains the passphrase for the signing key. Use \"-\" in order to read from stdin.\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --sign                       use a PGP private key to sign this package\n      --username string            chart repository username where to locate the requested chart\n      --version string             set the version on the chart to this semver version\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_plugin.md",
    "content": "---\ntitle: helm plugin\n---\n\ninstall, list, or uninstall Helm plugins\n\n### Synopsis\n\n\nManage client-side Helm plugins.\n\n\n### Options\n\n```\n  -h, --help   help for plugin\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm plugin install](/helm/helm_plugin_install.md)\t - install a Helm plugin\n* [helm plugin list](/helm/helm_plugin_list.md)\t - list installed Helm plugins\n* [helm plugin uninstall](/helm/helm_plugin_uninstall.md)\t - uninstall one or more Helm plugins\n* [helm plugin update](/helm/helm_plugin_update.md)\t - update one or more Helm plugins\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_plugin_install.md",
    "content": "---\ntitle: helm plugin install\n---\n\ninstall a Helm plugin\n\n### Synopsis\n\n\nThis command allows you to install a plugin from a url to a VCS repo or a local path.\n\n\n```\nhelm plugin install [options] <path|url> [flags]\n```\n\n### Options\n\n```\n  -h, --help             help for install\n      --version string   specify a version constraint. If this is not specified, the latest version is installed\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_plugin_list.md",
    "content": "---\ntitle: helm plugin list\n---\n\nlist installed Helm plugins\n\n```\nhelm plugin list [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for list\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_plugin_uninstall.md",
    "content": "---\ntitle: helm plugin uninstall\n---\n\nuninstall one or more Helm plugins\n\n```\nhelm plugin uninstall <plugin>... [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for uninstall\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_plugin_update.md",
    "content": "---\ntitle: helm plugin update\n---\n\nupdate one or more Helm plugins\n\n```\nhelm plugin update <plugin>... [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for update\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm plugin](/helm/helm_plugin.md)\t - install, list, or uninstall Helm plugins\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_pull.md",
    "content": "---\ntitle: helm pull\n---\n\ndownload a chart from a repository and (optionally) unpack it in local directory\n\n### Synopsis\n\n\nRetrieve a package from a package repository, and download it locally.\n\nThis is useful for fetching packages to inspect, modify, or repackage. It can\nalso be used to perform cryptographic verification of a chart without installing\nthe chart.\n\nThere are options for unpacking the chart after download. This will create a\ndirectory for the chart and uncompress into that directory.\n\nIf the --verify flag is specified, the requested chart MUST have a provenance\nfile, and MUST pass the verification process. Failure in any part of this will\nresult in an error, and the chart will not be saved locally.\n\n\n```\nhelm pull [chart URL | repo/chartname] [...] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n  -d, --destination string         location to write the chart. If this and untardir are specified, untardir is appended to this (default \".\")\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.\n  -h, --help                       help for pull\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --prov                       fetch the provenance file, but don't perform verification\n      --repo string                chart repository url where to locate the requested chart\n      --untar                      if set to true, will untar the chart after downloading it\n      --untardir string            if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default \".\")\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_push.md",
    "content": "---\ntitle: helm push\n---\n\npush a chart to remote\n\n### Synopsis\n\n\nUpload a chart to a registry.\n\nIf the chart has an associated provenance file,\nit will also be uploaded.\n\n\n```\nhelm push [chart] [remote] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify registry client using this SSL certificate file\n  -h, --help                       help for push\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart upload\n      --key-file string            identify registry client using this SSL key file\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart upload\n      --username string            chart repository username where to locate the requested chart\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_registry.md",
    "content": "---\ntitle: helm registry\n---\n\nlogin to or logout from a registry\n\n### Synopsis\n\n\nThis command consists of multiple subcommands to interact with registries.\n\n\n### Options\n\n```\n  -h, --help   help for registry\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm registry login](/helm/helm_registry_login.md)\t - login to a registry\n* [helm registry logout](/helm/helm_registry_logout.md)\t - logout from a registry\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_registry_login.md",
    "content": "---\ntitle: helm registry login\n---\n\nlogin to a registry\n\n### Synopsis\n\n\nAuthenticate to a remote registry.\n\n\n```\nhelm registry login [host] [flags]\n```\n\n### Options\n\n```\n      --ca-file string     verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string   identify registry client using this SSL certificate file\n  -h, --help               help for login\n      --insecure           allow connections to TLS registry without certs\n      --key-file string    identify registry client using this SSL key file\n  -p, --password string    registry password or identity token\n      --password-stdin     read password or identity token from stdin\n      --plain-http         use insecure HTTP connections for the chart upload\n  -u, --username string    registry username\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm registry](/helm/helm_registry.md)\t - login to or logout from a registry\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_registry_logout.md",
    "content": "---\ntitle: helm registry logout\n---\n\nlogout from a registry\n\n### Synopsis\n\n\nRemove credentials stored for a remote registry.\n\n\n```\nhelm registry logout [host] [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for logout\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm registry](/helm/helm_registry.md)\t - login to or logout from a registry\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_repo.md",
    "content": "---\ntitle: helm repo\n---\n\nadd, list, remove, update, and index chart repositories\n\n### Synopsis\n\n\nThis command consists of multiple subcommands to interact with chart repositories.\n\nIt can be used to add, remove, list, and index chart repositories.\n\n\n### Options\n\n```\n  -h, --help   help for repo\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm repo add](/helm/helm_repo_add.md)\t - add a chart repository\n* [helm repo index](/helm/helm_repo_index.md)\t - generate an index file given a directory containing packaged charts\n* [helm repo list](/helm/helm_repo_list.md)\t - list chart repositories\n* [helm repo remove](/helm/helm_repo_remove.md)\t - remove one or more chart repositories\n* [helm repo update](/helm/helm_repo_update.md)\t - update information of available charts locally from chart repositories\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_repo_add.md",
    "content": "---\ntitle: helm repo add\n---\n\nadd a chart repository\n\n```\nhelm repo add [NAME] [URL] [flags]\n```\n\n### Options\n\n```\n      --allow-deprecated-repos     by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --force-update               replace (overwrite) the repo if it already exists\n  -h, --help                       help for add\n      --insecure-skip-tls-verify   skip tls certificate checks for the repository\n      --key-file string            identify HTTPS client using this SSL key file\n      --no-update                  Ignored. Formerly, it would disabled forced updates. It is deprecated by force-update.\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password\n      --password-stdin             read chart repository password from stdin\n      --timeout duration           time to wait for the index file download to complete (default 2m0s)\n      --username string            chart repository username\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_repo_index.md",
    "content": "---\ntitle: helm repo index\n---\n\ngenerate an index file given a directory containing packaged charts\n\n### Synopsis\n\n\nRead the current directory, generate an index file based on the charts found\nand write the result to 'index.yaml' in the current directory.\n\nThis tool is used for creating an 'index.yaml' file for a chart repository. To\nset an absolute URL to the charts, use '--url' flag.\n\nTo merge the generated index with an existing index file, use the '--merge'\nflag. In this case, the charts found in the current directory will be merged\ninto the index passed in with --merge, with local charts taking priority over\nexisting charts.\n\n\n```\nhelm repo index [DIR] [flags]\n```\n\n### Options\n\n```\n  -h, --help           help for index\n      --json           output in JSON format\n      --merge string   merge the generated index into the given index\n      --url string     url of chart repository\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_repo_list.md",
    "content": "---\ntitle: helm repo list\n---\n\nlist chart repositories\n\n```\nhelm repo list [flags]\n```\n\n### Options\n\n```\n  -h, --help            help for list\n  -o, --output format   prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_repo_remove.md",
    "content": "---\ntitle: helm repo remove\n---\n\nremove one or more chart repositories\n\n```\nhelm repo remove [REPO1 [REPO2 ...]] [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for remove\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_repo_update.md",
    "content": "---\ntitle: helm repo update\n---\n\nupdate information of available charts locally from chart repositories\n\n### Synopsis\n\n\nUpdate gets the latest information about charts from the respective chart repositories.\nInformation is cached locally, where it is used by commands like 'helm search'.\n\nYou can optionally specify a list of repositories you want to update.\n\t$ helm repo update <repo_name> ...\nTo update all the repositories, use 'helm repo update'.\n\n\n```\nhelm repo update [REPO1 [REPO2 ...]] [flags]\n```\n\n### Options\n\n```\n      --fail-on-repo-update-fail   update fails if any of the repository updates fail\n  -h, --help                       help for update\n      --timeout duration           time to wait for the index file download to complete (default 2m0s)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm repo](/helm/helm_repo.md)\t - add, list, remove, update, and index chart repositories\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_rollback.md",
    "content": "---\ntitle: helm rollback\n---\n\nroll back a release to a previous revision\n\n### Synopsis\n\n\nThis command rolls back a release to a previous revision.\n\nThe first argument of the rollback command is the name of a release, and the\nsecond is a revision (version) number. If this argument is omitted or set to\n0, it will roll back to the previous release.\n\nTo see revision numbers, run 'helm history RELEASE'.\n\n\n```\nhelm rollback <RELEASE> [REVISION] [flags]\n```\n\n### Options\n\n```\n      --cleanup-on-fail    allow deletion of new resources created in this rollback when rollback fails\n      --dry-run            simulate a rollback\n      --force              force resource update through delete/recreate if needed\n  -h, --help               help for rollback\n      --history-max int    limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --no-hooks           prevent hooks from running during rollback\n      --recreate-pods      performs pods restart for the resource if applicable\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --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\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_search.md",
    "content": "---\ntitle: helm search\n---\n\nsearch for a keyword in charts\n\n### Synopsis\n\n\nSearch provides the ability to search for Helm charts in the various places\nthey can be stored including the Artifact Hub and repositories you have added.\nUse search subcommands to search different locations for charts.\n\n\n### Options\n\n```\n  -h, --help   help for search\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm search hub](/helm/helm_search_hub.md)\t - search for charts in the Artifact Hub or your own hub instance\n* [helm search repo](/helm/helm_search_repo.md)\t - search repositories for a keyword in charts\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_search_hub.md",
    "content": "---\ntitle: helm search hub\n---\n\nsearch for charts in the Artifact Hub or your own hub instance\n\n### Synopsis\n\n\nSearch for Helm charts in the Artifact Hub or your own hub instance.\n\nArtifact Hub is a web-based application that enables finding, installing, and\npublishing packages and configurations for CNCF projects, including publicly\navailable distributed charts Helm charts. It is a Cloud Native Computing\nFoundation sandbox project. You can browse the hub at https://artifacthub.io/\n\nThe [KEYWORD] argument accepts either a keyword string, or quoted string of rich\nquery options. For rich query options documentation, see\nhttps://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search\n\nPrevious versions of Helm used an instance of Monocular as the default\n'endpoint', so for backwards compatibility Artifact Hub is compatible with the\nMonocular search API. Similarly, when setting the 'endpoint' flag, the specified\nendpoint must also be implement a Monocular compatible search API endpoint.\nNote that when specifying a Monocular instance as the 'endpoint', rich queries\nare not supported. For API details, see https://github.com/helm/monocular\n\n\n```\nhelm search hub [KEYWORD] [flags]\n```\n\n### Options\n\n```\n      --endpoint string      Hub instance to query for charts (default \"https://hub.helm.sh\")\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for hub\n      --list-repo-url        print charts repository URL\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm search](/helm/helm_search.md)\t - search for a keyword in charts\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_search_repo.md",
    "content": "---\ntitle: helm search repo\n---\n\nsearch repositories for a keyword in charts\n\n### Synopsis\n\n\nSearch reads through all of the repositories configured on the system, and\nlooks for matches. Search of these repositories uses the metadata stored on\nthe system.\n\nIt will display the latest stable versions of the charts found. If you\nspecify the --devel flag, the output will include pre-release versions.\nIf you want to search using a version constraint, use --version.\n\nExamples:\n\n    # Search for stable release versions matching the keyword \"nginx\"\n    $ helm search repo nginx\n\n    # Search for release versions matching the keyword \"nginx\", including pre-release versions\n    $ helm search repo nginx --devel\n\n    # Search for the latest stable release for nginx-ingress with a major version of 1\n    $ helm search repo nginx-ingress --version ^1.0.0\n\nRepositories are managed with 'helm repo' commands.\n\n\n```\nhelm search repo [keyword] [flags]\n```\n\n### Options\n\n```\n      --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\n      --fail-on-no-result    search fails if no results are found\n  -h, --help                 help for repo\n      --max-col-width uint   maximum column width for output table (default 50)\n  -o, --output format        prints the output in the specified format. Allowed values: table, json, yaml (default table)\n  -r, --regexp               use regular expressions for searching repositories you have added\n      --version string       search using semantic versioning constraints on repositories you have added\n  -l, --versions             show the long listing, with each version of each chart on its own line, for repositories you have added\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm search](/helm/helm_search.md)\t - search for a keyword in charts\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_show.md",
    "content": "---\ntitle: helm show\n---\n\nshow information of a chart\n\n### Synopsis\n\n\nThis command consists of multiple subcommands to display information about a chart\n\n\n### Options\n\n```\n  -h, --help   help for show\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n* [helm show all](/helm/helm_show_all.md)\t - show all information of the chart\n* [helm show chart](/helm/helm_show_chart.md)\t - show the chart's definition\n* [helm show crds](/helm/helm_show_crds.md)\t - show the chart's CRDs\n* [helm show readme](/helm/helm_show_readme.md)\t - show the chart's README\n* [helm show values](/helm/helm_show_values.md)\t - show the chart's values\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_show_all.md",
    "content": "---\ntitle: helm show all\n---\n\nshow all information of the chart\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays all its content\n(values.yaml, Chart.yaml, README)\n\n\n```\nhelm show all [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for all\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_show_chart.md",
    "content": "---\ntitle: helm show chart\n---\n\nshow the chart's definition\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the Chart.yaml file\n\n\n```\nhelm show chart [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for chart\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_show_crds.md",
    "content": "---\ntitle: helm show crds\n---\n\nshow the chart's CRDs\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the CustomResourceDefinition files\n\n\n```\nhelm show crds [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for crds\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_show_readme.md",
    "content": "---\ntitle: helm show readme\n---\n\nshow the chart's README\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the README file\n\n\n```\nhelm show readme [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for readme\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_show_values.md",
    "content": "---\ntitle: helm show values\n---\n\nshow the chart's values\n\n### Synopsis\n\n\nThis command inspects a chart (directory, file, or URL) and displays the contents\nof the values.yaml file\n\n\n```\nhelm show values [CHART] [flags]\n```\n\n### Options\n\n```\n      --ca-file string             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string           identify HTTPS client using this SSL certificate file\n      --devel                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n  -h, --help                       help for values\n      --insecure-skip-tls-verify   skip tls certificate checks for the chart download\n      --jsonpath string            supply a JSONPath expression to filter the output\n      --key-file string            identify HTTPS client using this SSL key file\n      --keyring string             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --pass-credentials           pass credentials to all domains\n      --password string            chart repository password where to locate the requested chart\n      --plain-http                 use insecure HTTP connections for the chart download\n      --repo string                chart repository url where to locate the requested chart\n      --username string            chart repository username where to locate the requested chart\n      --verify                     verify the package before using it\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm show](/helm/helm_show.md)\t - show information of a chart\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_status.md",
    "content": "---\ntitle: helm status\n---\n\ndisplay the status of the named release\n\n### Synopsis\n\n\nThis command shows the status of a named release.\nThe status consists of:\n- last deployment time\n- k8s namespace in which the release lives\n- state of the release (can be: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade or pending-rollback)\n- revision of the release\n- description of the release (can be completion message or error message, need to enable --show-desc)\n- list of resources that this release consists of (need to enable --show-resources)\n- details on last test suite run, if applicable\n- additional notes provided by the chart\n\n\n```\nhelm status RELEASE_NAME [flags]\n```\n\n### Options\n\n```\n  -h, --help             help for status\n  -o, --output format    prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --revision int     if set, display the status of the named release with revision\n      --show-desc        if set, display the description message of the named release\n      --show-resources   if set, display the resources of the named release\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_template.md",
    "content": "---\ntitle: helm template\n---\n\nlocally render templates\n\n### Synopsis\n\n\nRender chart templates locally and display the output.\n\nAny values that would normally be looked up or retrieved in-cluster will be\nfaked locally. Additionally, none of the server-side testing of chart validity\n(e.g. whether an API is supported) is done.\n\n\n```\nhelm template [NAME] [CHART] [flags]\n```\n\n### Options\n\n```\n  -a, --api-versions strings                       Kubernetes api versions used for Capabilities.APIVersions\n      --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\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --create-namespace                           create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -g, --generate-name                              generate the name (and omit the NAME parameter)\n  -h, --help                                       help for template\n      --hide-notes                                 if set, do not show notes in install output. Does not affect presence in chart metadata\n      --include-crds                               include CRDs in the templated output\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n      --is-upgrade                                 set .Release.IsUpgrade instead of .Release.IsInstall\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n      --kube-version string                        Kubernetes version used for Capabilities.KubeVersion\n  -l, --labels stringToString                      Labels that would be added to release metadata. Should be divided by comma. (default [])\n      --name-template string                       specify template used to name the release\n      --no-hooks                                   prevent hooks from running during install\n      --output-dir string                          writes the executed templates to files in output-dir instead of stdout\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --release-name                               use release name in the output-dir path.\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production\n      --repo string                                chart repository url where to locate the requested chart\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n  -s, --show-only stringArray                      only show manifests rendered from the given templates\n      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --skip-tests                                 skip tests from templated output\n      --take-ownership                             if set, install will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n      --validate                                   validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_test.md",
    "content": "---\ntitle: helm test\n---\n\nrun tests for a release\n\n### Synopsis\n\n\nThe test command runs the tests for a release.\n\nThe argument this command takes is the name of a deployed release.\nThe tests to be run are defined in the chart that was installed.\n\n\n```\nhelm test [RELEASE] [flags]\n```\n\n### Options\n\n```\n      --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)\n  -h, --help               help for test\n      --hide-notes         if set, do not show notes in test output. Does not affect presence in chart metadata\n      --logs               dump the logs from test pods (this runs after all tests are complete, but before any cleanup)\n      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_uninstall.md",
    "content": "---\ntitle: helm uninstall\n---\n\nuninstall a release\n\n### Synopsis\n\n\nThis command takes a release name and uninstalls the release.\n\nIt removes all of the resources associated with the last release of the chart\nas well as the release history, freeing it up for future use.\n\nUse the '--dry-run' flag to see which releases will be uninstalled without actually\nuninstalling them.\n\n\n```\nhelm uninstall RELEASE_NAME [...] [flags]\n```\n\n### Options\n\n```\n      --cascade string       Must be \"background\", \"orphan\", or \"foreground\". Selects the deletion cascading strategy for the dependents. Defaults to background. (default \"background\")\n      --description string   add a custom description\n      --dry-run              simulate a uninstall\n  -h, --help                 help for uninstall\n      --ignore-not-found     Treat \"release not found\" as a successful uninstall\n      --keep-history         remove all associated resources and mark the release as deleted, but retain the release history\n      --no-hooks             prevent hooks from running during uninstallation\n      --timeout duration     time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --wait                 if set, will wait until all the resources are deleted before returning. It will wait for as long as --timeout\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_upgrade.md",
    "content": "---\ntitle: helm upgrade\n---\n\nupgrade a release\n\n### Synopsis\n\n\nThis command upgrades a release to a new version of a chart.\n\nThe upgrade arguments must be a release and chart. The chart\nargument can be either: a chart reference('example/mariadb'), a path to a chart directory,\na packaged chart, or a fully qualified URL. For chart references, the latest\nversion will be specified unless the '--version' flag is set.\n\nTo override values in a chart, use either the '--values' flag and pass in a file\nor use the '--set' flag and pass configuration from the command line, to force string\nvalues, use '--set-string'. You can use '--set-file' to set individual\nvalues from a file when the value itself is too long for the command line\nor is dynamically generated. You can also use '--set-json' to set json values\n(scalars/objects/arrays) from the command line.\n\nYou can specify the '--values'/'-f' flag multiple times. The priority will be given to the\nlast (right-most) file specified. For example, if both myvalues.yaml and override.yaml\ncontained a key called 'Test', the value set in override.yaml would take precedence:\n\n    $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis\n\nYou can specify the '--set' flag multiple times. The priority will be given to the\nlast (right-most) set specified. For example, if both 'bar' and 'newbar' values are\nset for a key called 'foo', the 'newbar' value would take precedence:\n\n    $ helm upgrade --set foo=bar --set foo=newbar redis ./redis\n\nYou can update the values for an existing release with this command as well via the\n'--reuse-values' flag. The 'RELEASE' and 'CHART' arguments should be set to the original\nparameters, and existing values will be merged with any values set via '--values'/'-f'\nor '--set' flags. Priority is given to new values.\n\n    $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis\n\nThe --dry-run flag will output all generated chart manifests, including Secrets\nwhich can contain sensitive values. To hide Kubernetes Secrets use the\n--hide-secret flag. Please carefully consider how and when these flags are used.\n\n\n```\nhelm upgrade [RELEASE] [CHART] [flags]\n```\n\n### Options\n\n```\n      --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\n      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle\n      --cert-file string                           identify HTTPS client using this SSL certificate file\n      --cleanup-on-fail                            allow deletion of new resources created in this upgrade when upgrade fails\n      --create-namespace                           if --install is set, create the release namespace if not present\n      --dependency-update                          update dependencies if they are missing before installing the chart\n      --description string                         add a custom description\n      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored\n      --disable-openapi-validation                 if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema\n      --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.\n      --enable-dns                                 enable DNS lookups when rendering templates\n      --force                                      force resource updates through a replacement strategy\n  -h, --help                                       help for upgrade\n      --hide-notes                                 if set, do not show notes in upgrade output. Does not affect presence in chart metadata\n      --hide-secret                                hide Kubernetes Secrets when also using the --dry-run flag\n      --history-max int                            limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)\n      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download\n  -i, --install                                    if a release by this name doesn't already exist, run an install\n      --key-file string                            identify HTTPS client using this SSL key file\n      --keyring string                             location of public keys used for verification (default \"~/.gnupg/pubring.gpg\")\n  -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 [])\n      --no-hooks                                   disable pre/post upgrade hooks\n  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)\n      --pass-credentials                           pass credentials to all domains\n      --password string                            chart repository password where to locate the requested chart\n      --plain-http                                 use insecure HTTP connections for the chart download\n      --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\n      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])\n      --render-subchart-notes                      if set, render subchart notes along with the parent\n      --repo string                                chart repository url where to locate the requested chart\n      --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\n      --reset-values                               when upgrading, reset the values to the ones built into the chart\n      --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\n      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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)\n      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)\n      --set-literal stringArray                    set a literal STRING value on the command line\n      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)\n      --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\n      --skip-schema-validation                     if set, disables JSON schema validation\n      --take-ownership                             if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources\n      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)\n      --username string                            chart repository username where to locate the requested chart\n  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)\n      --verify                                     verify the package before using it\n      --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\n      --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\n      --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\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_verify.md",
    "content": "---\ntitle: helm verify\n---\n\nverify that a chart at the given path has been signed and is valid\n\n### Synopsis\n\n\nVerify that the given chart has a valid provenance file.\n\nProvenance files provide cryptographic verification that a chart has not been\ntampered with, and was packaged by a trusted provider.\n\nThis command can be used to verify a local chart. Several other commands provide\n'--verify' flags that run the same validation. To generate a signed package, use\nthe 'helm package --sign' command.\n\n\n```\nhelm verify PATH [flags]\n```\n\n### Options\n\n```\n  -h, --help             help for verify\n      --keyring string   keyring containing public keys (default \"~/.gnupg/pubring.gpg\")\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/helm_version.md",
    "content": "---\ntitle: helm version\n---\n\nprint the client version information\n\n### Synopsis\n\n\nShow the version for Helm.\n\nThis will print a representation the version of Helm.\nThe output will look something like this:\n\nversion.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n\n- Version is the semantic version of the release.\n- GitCommit is the SHA for the commit that this version was built from.\n- GitTreeState is \"clean\" if there are no local code changes when this binary was\n  built, and \"dirty\" if the binary was built from locally modified code.\n- GoVersion is the version of Go that was used to compile Helm.\n\nWhen using the --template flag the following properties are available to use in\nthe template:\n\n- .Version contains the semantic version of Helm\n- .GitCommit is the git commit\n- .GitTreeState is the state of the git tree when Helm was built\n- .GoVersion contains the version of Go that Helm was compiled with\n\nFor example, --template='Version: {{.Version}}' outputs 'Version: v3.2.1'.\n\n\n```\nhelm version [flags]\n```\n\n### Options\n\n```\n  -h, --help              help for version\n      --short             print the version number\n      --template string   template for version string format\n```\n\n### Options inherited from parent commands\n\n```\n      --burst-limit int                 client-side default throttling limit (default 100)\n      --debug                           enable verbose output\n      --kube-apiserver string           the address and the port for the Kubernetes API server\n      --kube-as-group stringArray       group to impersonate for the operation, this flag can be repeated to specify multiple groups.\n      --kube-as-user string             username to impersonate for the operation\n      --kube-ca-file string             the certificate authority file for the Kubernetes API server connection\n      --kube-context string             name of the kubeconfig context to use\n      --kube-insecure-skip-tls-verify   if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure\n      --kube-tls-server-name string     server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used\n      --kube-token string               bearer token used for authentication\n      --kubeconfig string               path to the kubeconfig file\n  -n, --namespace string                namespace scope for this request\n      --qps float32                     queries per second used when communicating with the Kubernetes API, not including bursting\n      --registry-config string          path to the registry config file (default \"~/.config/helm/registry/config.json\")\n      --repository-cache string         path to the directory containing cached repository indexes (default \"~/.cache/helm/repository\")\n      --repository-config string        path to the file containing repository names and URLs (default \"~/.config/helm/repositories.yaml\")\n```\n\n### SEE ALSO\n\n* [helm](/helm/helm.md)\t - The Helm package manager for Kubernetes.\n\n###### Auto generated by spf13/cobra on 14-Jan-2026\n"
  },
  {
    "path": "versioned_docs/version-3/helm/index.mdx",
    "content": "---\ntitle: Helm Commands\ndescription: Documentation for the full list of helm CLI commands.\nsidebar_position: 6\nid: helm-category\n---\n\n# Helm Commands\n\nHere you'll find the list of CLI commands for Helm, with help info on their usage.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/howto/chart_releaser_action.md",
    "content": "---\ntitle: Chart Releaser Action to Automate GitHub Page Charts\ndescription: Describe how to use Chart Releaser Action to automate releasing charts through GitHub pages.\nsidebar_position: 3\n---\n\nThis guide describes how to use [Chart Releaser\nAction](https://github.com/marketplace/actions/helm-chart-releaser) to automate\nreleasing charts through GitHub pages.  Chart Releaser Action is a GitHub Action\nworkflow to turn a GitHub project into a self-hosted Helm chart repo, using\n[helm/chart-releaser](https://github.com/helm/chart-releaser) CLI tool.\n\n## Repository Changes\n\nCreate a Git repository under your GitHub organization.  You could give the name\nof the repository as `helm-charts`, though other names are also acceptable.  The\nsources of all the charts can be placed under the `main` branch.  The charts\nshould be placed under `/charts` directory at the top-level of the directory\ntree.\n\nThere should be another branch named `gh-pages` to publish the charts.  The\nchanges to that branch will be automatically created by the Chart Releaser\nAction described here.  However, you can create that `gh-branch` and add\n`README.md` file, which is going to be visible to the users visiting the page.\n\nYou can add instruction in the `README.md` for charts installation like this\n(replace `<alias>`, `<orgname>`, and `<chart-name>`):\n\n```\n## Usage\n\n[Helm](https://helm.sh) must be installed to use the charts.  Please refer to\nHelm's [documentation](https://helm.sh/docs) to get started.\n\nOnce Helm has been set up correctly, add the repo as follows:\n\n  helm repo add <alias> https://<orgname>.github.io/helm-charts\n\nIf you had already added this repo earlier, run `helm repo update` to retrieve\nthe latest versions of the packages.  You can then run `helm search repo\n<alias>` to see the charts.\n\nTo install the <chart-name> chart:\n\n    helm install my-<chart-name> <alias>/<chart-name>\n\nTo uninstall the chart:\n\n    helm uninstall my-<chart-name>\n```\n\nThe charts will be published to a website with URL like this:\n\n    https://<orgname>.github.io/helm-charts\n\n## GitHub Actions Workflow\n\nCreate GitHub Actions workflow file in the `main` branch at\n`.github/workflows/release.yml`\n\n```\nname: Release Charts\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  release:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Configure Git\n        run: |\n          git config user.name \"$GITHUB_ACTOR\"\n          git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n      - name: Run chart-releaser\n        uses: helm/chart-releaser-action@v1.6.0\n        env:\n          CR_TOKEN: \"${{ secrets.GITHUB_TOKEN }}\"\n```\n\nThe above configuration uses\n[@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) to\nturn your GitHub project into a self-hosted Helm chart repo.  It does this -\nduring every push to main - by checking each chart in your project, and whenever\nthere's a new chart version, creates a corresponding GitHub release named for\nthe chart version, adds Helm chart artifacts to the release, and creates or\nupdates an `index.yaml` file with metadata about those releases, which is then\nhosted on GitHub pages.\n\nThe Chart Releaser Action version number used in the above example is `v1.6.0`.\nYou can change it to the [latest available\nversion](https://github.com/helm/chart-releaser-action/releases).\n\nNote: The Chart Releaser Action is almost always used in tandem with the [Helm Testing\nAction](https://github.com/marketplace/actions/helm-chart-testing) and [Kind\nAction](https://github.com/marketplace/actions/kind-cluster).\n"
  },
  {
    "path": "versioned_docs/version-3/howto/chart_repository_sync_example.md",
    "content": "---\ntitle: Syncing Your Chart Repository\ndescription: Describes how to synchronize your local and remote chart repositories.\nsidebar_position: 2\n---\n\n*Note: This example is specifically for a Google Cloud Storage (GCS) bucket\nwhich serves a chart repository.*\n\n## Prerequisites\n* Install the [gsutil](https://cloud.google.com/storage/docs/gsutil) tool. *We\n  rely heavily on the gsutil rsync functionality*\n* Be sure to have access to the Helm binary\n* _Optional: We recommend you set [object\n  versioning](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)\n  on your GCS bucket in case you accidentally delete something._\n\n## Set up a local chart repository directory\nCreate a local directory like we did in [the chart repository guide](/topics/chart_repository.md), and place your packaged charts in that\ndirectory.\n\nFor example:\n```console\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n```\n\n## Generate an updated index.yaml\nUse Helm to generate an updated index.yaml file by passing in the directory path\nand the url of the remote repository to the `helm repo index` command like this:\n\n```console\n$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com\n```\nThis will generate an updated index.yaml file and place it in the\n`fantastic-charts/` directory.\n\n## Sync your local and remote chart repositories\nUpload the contents of the directory to your GCS bucket by running\n`scripts/sync-repo.sh` and pass in the local directory name and the GCS bucket\nname.\n\nFor example:\n```console\n$ pwd\n/Users/me/code/go/src/helm.sh/helm\n$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts\nGetting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts\nVerifying Prerequisites....\nThumbs up! Looks like you have gsutil. Let's continue.\nBuilding synchronization state...\nStarting synchronization\nWould copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz\nWould copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml\nAre you sure you would like to continue with these changes?? [y/N]} y\nBuilding synchronization state...\nStarting synchronization\nCopying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]...\nUploading   gs://fantastic-charts/alpine-0.1.0.tgz:              740 B/740 B\nCopying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]...\nUploading   gs://fantastic-charts/index.yaml:                    347 B/347 B\nCongratulations your remote chart repository now matches the contents of fantastic-charts/\n```\n## Updating your chart repository\nYou'll want to keep a local copy of the contents of your chart repository or use\n`gsutil rsync` to copy the contents of your remote chart repository to a local\ndirectory.\n\nFor example:\n```console\n$ gsutil rsync -d -n gs://bucket-name local-dir/    # the -n flag does a dry run\nBuilding synchronization state...\nStarting synchronization\nWould copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz\nWould copy gs://bucket-name/index.yaml to file://local-dir/index.yaml\n\n$ gsutil rsync -d gs://bucket-name local-dir/       # performs the copy actions\nBuilding synchronization state...\nStarting synchronization\nCopying gs://bucket-name/alpine-0.1.0.tgz...\nDownloading file://local-dir/alpine-0.1.0.tgz:                        740 B/740 B\nCopying gs://bucket-name/index.yaml...\nDownloading file://local-dir/index.yaml:                              346 B/346 B\n```\n\nHelpful Links:\n* Documentation on [gsutil\n  rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description)\n* [The Chart Repository Guide](/topics/chart_repository.md)\n* Documentation on [object versioning and concurrency\n  control](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)\n  in Google Cloud Storage\n"
  },
  {
    "path": "versioned_docs/version-3/howto/charts_tips_and_tricks.md",
    "content": "---\ntitle: Chart Development Tips and Tricks\ndescription: Covers some of the tips and tricks Helm chart developers have learned while building production-quality charts.\nsidebar_position: 1\n---\n\nThis guide covers some of the tips and tricks Helm chart developers have learned\nwhile building production-quality charts.\n\n## Know Your Template Functions\n\nHelm uses [Go templates](https://godoc.org/text/template) for templating your\nresource files. While Go ships several built-in functions, we have added many\nothers.\n\nFirst, we added all of the functions in the [Sprig\nlibrary](https://masterminds.github.io/sprig/), except `env` and `expandenv`, for security reasons.\n\nWe also added two special template functions: `include` and `required`. The\n`include` function allows you to bring in another template, and then pass the\nresults to other template functions.\n\nFor example, this template snippet includes a template called `mytpl`, then\nlowercases the result, then wraps that in double quotes.\n\n```yaml\nvalue: {{ include \"mytpl\" . | lower | quote }}\n```\n\nThe `required` function allows you to declare a particular values entry as\nrequired for template rendering.  If the value is empty, the template rendering\nwill fail with a user submitted error message.\n\nThe following example of the `required` function declares an entry for\n`.Values.who` is required, and will print an error message when that entry is\nmissing:\n\n```yaml\nvalue: {{ required \"A valid .Values.who entry required!\" .Values.who }}\n```\n\n## Quote Strings, Don't Quote Integers\n\nWhen you are working with string data, you are always safer quoting the strings\nthan leaving them as bare words:\n\n```yaml\nname: {{ .Values.MyName | quote }}\n```\n\nBut when working with integers _do not quote the values._ That can, in many\ncases, cause parsing errors inside of Kubernetes.\n\n```yaml\nport: {{ .Values.Port }}\n```\n\nThis remark does not apply to env variables values which are expected to be\nstring, even if they represent integers:\n\n```yaml\nenv:\n  - name: HOST\n    value: \"http://host\"\n  - name: PORT\n    value: \"1234\"\n```\n\n## Using the 'include' Function\n\nGo provides a way of including one template in another using a built-in\n`template` directive. However, the built-in function cannot be used in Go\ntemplate pipelines.\n\nTo make it possible to include a template, and then perform an operation on that\ntemplate's output, Helm has a special `include` function:\n\n```\n{{ include \"toYaml\" $value | indent 2 }}\n```\n\nThe above includes a template called `toYaml`, passes it `$value`, and then\npasses the output of that template to the `indent` function.\n\nBecause YAML ascribes significance to indentation levels and whitespace, this is\none great way to include snippets of code, but handle indentation in a relevant\ncontext.\n\n## Using the 'required' function\n\nGo provides a way for setting template options to control behavior when a map is\nindexed with a key that's not present in the map. This is typically set with\n`template.Options(\"missingkey=option\")`, where `option` can be `default`,\n`zero`, or `error`. While setting this option to error will stop execution with\nan error, this would apply to every missing key in the map. There may be\nsituations where a chart developer wants to enforce this behavior for select\nvalues in the `values.yaml` file.\n\nThe `required` function gives developers the ability to declare a value entry as\nrequired for template rendering. If the entry is empty in `values.yaml`, the\ntemplate will not render and will return an error message supplied by the\ndeveloper.\n\nFor example:\n\n```\n{{ required \"A valid foo is required!\" .Values.foo }}\n```\n\nThe above will render the template when `.Values.foo` is defined, but will fail\nto render and exit when `.Values.foo` is undefined.\n\n## Using the 'tpl' Function\n\nThe `tpl` function allows developers to evaluate strings as templates inside a\ntemplate. This is useful to pass a template string as a value to a chart or\nrender external configuration files. Syntax: `{{ tpl TEMPLATE_STRING VALUES }}`\n\nExamples:\n\n```yaml\n# values\ntemplate: \"{{ .Values.name }}\"\nname: \"Tom\"\n\n# template\n{{ tpl .Values.template . }}\n\n# output\nTom\n```\n\nRendering an external configuration file:\n\n```yaml\n# external configuration file conf/app.conf\nfirstName={{ .Values.firstName }}\nlastName={{ .Values.lastName }}\n\n# values\nfirstName: Peter\nlastName: Parker\n\n# template\n{{ tpl (.Files.Get \"conf/app.conf\") . }}\n\n# output\nfirstName=Peter\nlastName=Parker\n```\n\n## Creating Image Pull Secrets\nImage pull secrets are essentially a combination of _registry_, _username_, and\n_password_.  You may need them in an application you are deploying, but to\ncreate them requires running `base64` a couple of times.  We can write a helper\ntemplate to compose the Docker configuration file for use as the Secret's\npayload.  Here is an example:\n\nFirst, assume that the credentials are defined in the `values.yaml` file like\nso:\n```yaml\nimageCredentials:\n  registry: quay.io\n  username: someone\n  password: sillyness\n  email: someone@host.com\n```\n\nWe then define our helper template as follows:\n```\n{{- define \"imagePullSecret\" }}\n{{- with .Values.imageCredentials }}\n{{- printf \"{\\\"auths\\\":{\\\"%s\\\":{\\\"username\\\":\\\"%s\\\",\\\"password\\\":%s,\\\"email\\\":\\\"%s\\\",\\\"auth\\\":\\\"%s\\\"}}}\" .registry .username (.password | quote) .email (printf \"%s:%s\" .username .password | b64enc) | b64enc }}\n{{- end }}\n{{- end }}\n```\n\nFinally, we use the helper template in a larger template to create the Secret\nmanifest:\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: myregistrykey\ntype: kubernetes.io/dockerconfigjson\ndata:\n  .dockerconfigjson: {{ template \"imagePullSecret\" . }}\n```\n\n## Automatically Roll Deployments\n\nOften times ConfigMaps or Secrets are injected as configuration files in\ncontainers or there are other external dependency changes that require rolling\npods. Depending on the application a restart may be required should those be\nupdated with a subsequent `helm upgrade`, but if the deployment spec itself\ndidn't change the application keeps running with the old configuration resulting\nin an inconsistent deployment.\n\nThe `sha256sum` function can be used to ensure a deployment's annotation section\nis updated if another file changes:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        checksum/config: {{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}\n[...]\n```\n\nNOTE: If you're adding this to a library chart you won't be able to access your\nfile in `$.Template.BasePath`. Instead you can reference your definition with\n`{{ include (\"mylibchart.configmap\") . | sha256sum }}`.\n\nIn the event you always want to roll your deployment, you can use a similar\nannotation step as above, instead replacing with a random string so it always\nchanges and causes the deployment to roll:\n\n```yaml\nkind: Deployment\nspec:\n  template:\n    metadata:\n      annotations:\n        rollme: {{ randAlphaNum 5 | quote }}\n[...]\n```\n\nEach invocation of the template function will generate a unique random string.\nThis means that if it's necessary to sync the random strings used by multiple\nresources, all relevant resources will need to be in the same template file.\n\nBoth of these methods allow your Deployment to leverage the built in update\nstrategy logic to avoid taking downtime.\n\nNOTE: In the past we recommended using the `--recreate-pods` flag as another\noption. This flag has been marked as deprecated in Helm 3 in favor of the more\ndeclarative method above.\n\n## Tell Helm Not To Uninstall a Resource\n\nSometimes there are resources that should not be uninstalled when Helm runs a\n`helm uninstall`. Chart developers can add an annotation to a resource to\nprevent it from being uninstalled.\n\n```yaml\nkind: Secret\nmetadata:\n  annotations:\n    helm.sh/resource-policy: keep\n[...]\n```\n\nThe annotation `helm.sh/resource-policy: keep` instructs Helm to skip deleting\nthis resource when a helm operation (such as `helm uninstall`, `helm upgrade` or\n`helm rollback`) would result in its deletion. _However_, this resource becomes\norphaned. Helm will no longer manage it in any way. This can lead to problems if\nusing `helm install --replace` on a release that has already been uninstalled,\nbut has kept resources.\n\n## Using \"Partials\" and Template Includes\n\nSometimes you want to create some reusable parts in your chart, whether they're\nblocks or template partials. And often, it's cleaner to keep these in their own\nfiles.\n\nIn the `templates/` directory, any file that begins with an underscore(`_`) is\nnot expected to output a Kubernetes manifest file. So by convention, helper\ntemplates and partials are placed in a `_helpers.tpl` file.\n\n## Complex Charts with Many Dependencies\n\nMany of the charts in the CNCF [Artifact\nHub](https://artifacthub.io/packages/search?kind=0) are \"building blocks\" for\ncreating more advanced applications. But charts may be used to create instances\nof large-scale applications. In such cases, a single umbrella chart may have\nmultiple subcharts, each of which functions as a piece of the whole.\n\nThe current best practice for composing a complex application from discrete\nparts is to create a top-level umbrella chart that exposes the global\nconfigurations, and then use the `charts/` subdirectory to embed each of the\ncomponents.\n\n## YAML is a Superset of JSON\n\nAccording to the YAML specification, YAML is a superset of JSON. That means that\nany valid JSON structure ought to be valid in YAML.\n\nThis has an advantage: Sometimes template developers may find it easier to\nexpress a datastructure with a JSON-like syntax rather than deal with YAML's\nwhitespace sensitivity.\n\nAs a best practice, templates should follow a YAML-like syntax _unless_ the JSON\nsyntax substantially reduces the risk of a formatting issue.\n\n## Be Careful with Generating Random Values\n\nThere are functions in Helm that allow you to generate random data,\ncryptographic keys, and so on. These are fine to use. But be aware that during\nupgrades, templates are re-executed. When a template run generates data that\ndiffers from the last run, that will trigger an update of that resource.\n\n## Install or Upgrade a Release with One Command\n\nHelm provides a way to perform an install-or-upgrade as a single command. Use\n`helm upgrade` with the `--install` command. This will cause Helm to see if the\nrelease is already installed. If not, it will run an install. If it is, then the\nexisting release will be upgraded.\n\n```console\n$ helm upgrade --install <release name> --values <values file> <chart directory>\n```\n"
  },
  {
    "path": "versioned_docs/version-3/howto/index.mdx",
    "content": "---\ntitle: How-to\nsidebar_position: 2\n---\n\n# How-to Guides\n\nHere you’ll find short answers to “How do I….?” types of questions. These how-to\nguides don’t cover topics in depth – you’ll find that material in the [Topic\nGuides](/topics/index.mdx). However, these guides will help you quickly accomplish\ncommon tasks.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/index.mdx",
    "content": "---\ntitle: Docs Home\ndescription: Everything you need to know about how the documentation is organized.\nsidebar_position: 1\n---\n\n# Welcome\n\nWelcome to the [Helm](https://helm.sh/) documentation. Helm is the package\nmanager for Kubernetes, and you can read detailed background information in the\n[CNCF Helm Project Journey\nreport](https://www.cncf.io/cncf-helm-project-journey/).\n\n# How the documentation is organized\n\nHelm has a lot of documentation. A high-level overview of how it’s organized\nwill help you know where to look for certain things:\n\n- [Tutorials](/chart_template_guide/getting_started.md) take you by the hand through a series of steps to create\n  your first Helm chart. Start here if you’re new to Helm.\n- [Topic guides](/topics/index.mdx) discuss key topics and concepts at a fairly high level\n  and provide useful background information and explanation.\n- [Community Guides](/community) discuss topics centered around Helm’s community.\n  Start here if you want to learn more about the development process of Helm\n  itself and how you can contribute.\n- [How-to guides](/howto/index.mdx) are recipes. They guide you through the steps involved\n  in addressing key problems and use-cases. They are more advanced than\n  tutorials and assume some knowledge of how Helm works.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/intro/CheatSheet.md",
    "content": "---\ntitle: Cheat Sheet\ndescription: Helm cheatsheet\nsidebar_position: 4\n---\n\nHelm cheatsheet featuring all the necessary commands required to manage an application through Helm.\n\n-----------------------------------------------------------------------------------------------------------------------------------------------\n### Basic interpretations/context\n\nChart:\n- It is the name of your chart in case it has been pulled and untarred.\n- It is <repo_name>/<chart_name> in case the repository has been added but chart not pulled.\n- It is the URL/Absolute path to the chart.\n\nName:\n- It is the name you want to give to your current helm chart installation.\n\nRelease:\n- Is the name you assigned to an installation instance.\n\nRevision:\n- Is the value from the Helm history command\n\nRepo-name:\n- The name of a repository.\n\nDIR:\n- Directory name/path\n\n------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Chart Management\n\n```bash\nhelm create <name>                      # Creates a chart directory along with the common files and directories used in a chart.\nhelm package <chart-path>               # Packages a chart into a versioned chart archive file.\nhelm lint <chart>                       # Run tests to examine a chart and identify possible issues:\nhelm show all <chart>                   # Inspect a chart and list its contents:\nhelm show values <chart>                # Displays the contents of the values.yaml file\nhelm pull <chart>                       # Download/pull chart\nhelm pull <chart> --untar=true          # If set to true, will untar the chart after downloading it\nhelm pull <chart> --verify              # Verify the package before using it\nhelm pull <chart> --version <number>    # Default-latest is used, specify a version constraint for the chart version to use\nhelm dependency list <chart>            # Display a list of a chart’s dependencies:\n```\n--------------------------------------------------------------------------------------------------------------------------------------------------\n\n### Install and Uninstall Apps\n\n```bash\nhelm install <name> <chart>                           # Install the chart with a name\nhelm install <name> <chart> --namespace <namespace>   # Install the chart in a specific namespace\nhelm install <name> <chart> --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas)\nhelm install <name> <chart> --values <yaml-file/url>  # Install the chart with your specified values\nhelm install <name> <chart> --dry-run --debug         # Run a test installation to validate chart (p)\nhelm install <name> <chart> --verify                  # Verify the package before using it\nhelm install <name> <chart> --dependency-update       # update dependencies if they are missing before installing the chart\nhelm uninstall <name>                                 # Uninstalls a release from the current (default) namespace\nhelm uninstall <release-name> --namespace <namespace> # Uninstalls a release from the specified namespace\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### Perform App Upgrade and Rollback\n\n```bash\nhelm upgrade <release> <chart>                            # Upgrade a release\nhelm upgrade <release> <chart> --rollback-on-failure      # If set, upgrade process rolls back changes made in case of failed upgrade.\nhelm upgrade <release> <chart> --dependency-update        # update dependencies if they are missing before installing the chart\nhelm upgrade <release> <chart> --version <version_number> # specify a version constraint for the chart version to use\nhelm upgrade <release> <chart> --values                   # specify values in a YAML file or a URL (can specify multiple)\nhelm upgrade <release> <chart> --set key1=val1,key2=val2  # Set values on the command line (can specify multiple or separate valuese)\nhelm upgrade <release> <chart> --force                    # Force resource updates through a replacement strategy\nhelm rollback <release> <revision>                        # Roll back a release to a specific revision\nhelm rollback <release> <revision>  --cleanup-on-fail     # Allow deletion of new resources created in this rollback when rollback fails\n```\n------------------------------------------------------------------------------------------------------------------------------------------------\n### List, Add, Remove, and Update Repositories\n\n```bash\nhelm repo add <repo-name> <url>   # Add a repository from the internet:\nhelm repo list                    # List added chart repositories\nhelm repo update                  # Update information of available charts locally from chart repositories\nhelm repo remove <repo_name>      # Remove one or more chart repositories\nhelm repo index <DIR>             # Read the current directory and generate an index file based on the charts found.\nhelm repo index <DIR> --merge     # Merge the generated index with an existing index file\nhelm search repo <keyword>        # Search repositories for a keyword in charts\nhelm search hub <keyword>         # Search for charts in the Artifact Hub or your own hub instance\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Helm Release monitoring\n\n```bash\nhelm list                       # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified\nhelm list --all                 # Show all releases without any filter applied, can use -a\nhelm list --all-namespaces      # List releases across all namespaces, we can use -A\nhelm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!='\nhelm list --date                # Sort by release date\nhelm list --deployed            # Show deployed releases. If no other is specified, this will be automatically enabled\nhelm list --pending             # Show pending releases\nhelm list --failed              # Show failed releases\nhelm list --uninstalled         # Show uninstalled releases (if 'helm uninstall --keep-history' was used)\nhelm list --superseded          # Show superseded releases\nhelm list -o yaml               # Prints the output in the specified format. Allowed values: table, json, yaml (default table)\nhelm status <release>           # This command shows the status of a named release.\nhelm status <release> --revision <number>   # if set, display the status of the named release with revision\nhelm history <release>          # Historical revisions for a given release.\nhelm env                        # Env prints out all the environment information in use by Helm.\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Download Release Information\n\n```bash\nhelm get all <release>      # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release.\nhelm get hooks <release>    # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\\n' separator.\nhelm get manifest <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.\nhelm get notes <release>    # Shows notes provided by the chart of a named release.\nhelm get values <release>   # Downloads a values file for a given release. use -o to format output\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n### Plugin Management\n\n```bash\nhelm plugin install <path/url>      # Install plugins\nhelm plugin list                    # View a list of all installed plugins\nhelm plugin update <plugin>         # Update plugins\nhelm plugin uninstall <plugin>      # Uninstall a plugin\n```\n-------------------------------------------------------------------------------------------------------------------------------------------------\n"
  },
  {
    "path": "versioned_docs/version-3/intro/index.mdx",
    "content": "---\ntitle: Introduction\nsidebar_position: 1\n---\n\n# Introduction to Helm\n\nAre you new to Helm? This is the place to start!\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/intro/install.md",
    "content": "---\ntitle: Installing Helm\ndescription: Learn how to install and get running with Helm.\nsidebar_position: 2\n---\n\nThis guide shows how to install the Helm CLI. Helm can be installed either from\nsource, or from pre-built binary releases.\n\n## From The Helm Project\n\nThe Helm project provides two ways to fetch and install Helm. These are the\nofficial methods to get Helm releases. In addition to that, the Helm community\nprovides methods to install Helm through different package managers.\nInstallation through those methods can be found below the official methods.\n\n### From the Binary Releases\n\nEvery [release](https://github.com/helm/helm/releases) of Helm provides binary\nreleases for a variety of OSes. These binary versions can be manually downloaded\nand installed.\n\n1. Download your [desired version](https://github.com/helm/helm/releases)\n2. Unpack it (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)\n3. Find the `helm` binary in the unpacked directory, and move it to its desired\n   destination (`mv linux-amd64/helm /usr/local/bin/helm`)\n\nFrom there, you should be able to run the client and [add the stable\nchart repository](/intro/quickstart.md#initialize-a-helm-chart-repository):\n`helm help`.\n\n**Note:** Helm automated tests are performed for Linux AMD64 only during\nGitHub Actions builds and releases. Testing of other OSes are the responsibility of\nthe community requesting Helm for the OS in question.\n\n### From Script\n\nHelm now has an installer script that will automatically grab the latest version\nof Helm and [install it\nlocally](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3).\n\nYou can fetch that script, and then execute it locally. It's well documented so\nthat you can read through it and understand what it is doing before you run it.\n\n```console\ncurl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3\nchmod 700 get_helm.sh\n./get_helm.sh\n```\n\nYes, you can `curl\nhttps://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` if\nyou want to live on the edge.\n\n## Through Package Managers\n\nThe Helm community provides the ability to install Helm through operating system\npackage managers. These are not supported by the Helm project and are not\nconsidered trusted 3rd parties.\n\n### From Homebrew (macOS)\n\nMembers of the Helm community have contributed a Helm formula build to Homebrew.\nThis formula is generally up to date.\n\n```console\nbrew install helm\n```\n\n(Note: There is also a formula for emacs-helm, which is a different project.)\n\n### From Chocolatey (Windows)\n\nMembers of the Helm community have contributed a [Helm\npackage](https://chocolatey.org/packages/kubernetes-helm) build to\n[Chocolatey](https://chocolatey.org/). This package is generally up to date.\n\n```console\nchoco install kubernetes-helm\n```\n\n### From Scoop (Windows)\n\nMembers of the Helm community have contributed a [Helm\npackage](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) build to [Scoop](https://scoop.sh). This package is generally up to date.\n\n```console\nscoop install helm\n```\n\n### From Winget (Windows)\n\nMembers of the Helm community have contributed a [Helm\npackage](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.\n\n```console\nwinget install Helm.Helm\n```\n\n### From Apt (Debian/Ubuntu)\n\nMembers of the Helm community have contributed an Apt package for Debian/Ubuntu. This package is\ngenerally up to date. Thanks to [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) for hosting the repo.\n\n```console\nsudo apt-get install curl gpg apt-transport-https --yes\ncurl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null\necho \"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\nsudo apt-get update\nsudo apt-get install helm\n```\n\n### From dnf/yum (fedora)\nSince Fedora 35, Helm is available on the official repository.\nYou can install Helm by invoking:\n\n```console\nsudo dnf install helm\n```\n\n### From Snap\n\nThe [Snapcrafters](https://github.com/snapcrafters) community maintains the Snap\nversion of the [Helm package](https://snapcraft.io/helm):\n\n```console\nsudo snap install helm --classic\n```\n\n### From pkg (FreeBSD)\n\nMembers of the FreeBSD community have contributed a [Helm\npackage](https://www.freshports.org/sysutils/helm) build to the\n[FreeBSD Ports Collection](https://man.freebsd.org/ports).\nThis package is generally up to date.\n\n```console\npkg install helm\n```\n\n### Development Builds\n\nIn addition to releases you can download or install development snapshots of\nHelm.\n\n### From Canary Builds\n\n\"Canary\" builds are versions of the Helm software that are built from the latest\n`main` branch. They are not official releases, and may not be stable. However,\nthey offer the opportunity to test the cutting edge features.\n\nCanary Helm binaries are stored at `get.helm.sh`. Here are\nlinks to the common builds:\n\n- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)\n- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)\n- [Experimental Windows\n  AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)\n\n### From Source (Linux, macOS)\n\nBuilding Helm from source is slightly more work, but is the best way to go if\nyou want to test the latest (pre-release) Helm version.\n\nYou must have a working Go environment.\n\n```console\n$ git clone https://github.com/helm/helm.git\n$ cd helm\n$ make\n```\n\nIf required, it will fetch the dependencies and cache them, and validate\nconfiguration. It will then compile `helm` and place it in `bin/helm`.\n\n## Conclusion\n\nIn most cases, installation is as simple as getting a pre-built `helm` binary.\nThis document covers additional cases for those who want to do more\nsophisticated things with Helm.\n\nOnce you have the Helm Client successfully installed, you can move on to using\nHelm to manage charts and [add the stable\nchart repository](/intro/quickstart.md#initialize-a-helm-chart-repository).\n"
  },
  {
    "path": "versioned_docs/version-3/intro/quickstart.md",
    "content": "---\ntitle: Quickstart Guide\ndescription: How to install and get started with Helm including instructions for distros, FAQs, and plugins.\nsidebar_position: 1\n---\n\nThis guide covers how you can quickly get started using Helm.\n\n## Prerequisites\n\nThe following prerequisites are required for a successful and properly secured\nuse of Helm:\n\n1. A Kubernetes cluster\n2. Deciding what security configurations to apply to your installation, if any\n3. Installing and configuring Helm.\n\n### Install Kubernetes or have access to a cluster\n\n- You must have Kubernetes installed. For the latest release of Helm, we\n  recommend the latest stable release of Kubernetes, which in most cases is the\n  second-latest minor release.\n- You should also have a local configured copy of `kubectl`.\n\nSee the [Helm Version Support Policy](https://helm.sh/docs/topics/version_skew/) for the maximum version skew supported between Helm and Kubernetes.\n\n## Install Helm\n\nDownload a binary release of the Helm client. You can use tools like `homebrew`,\nor look at [the official releases page](https://github.com/helm/helm/releases).\n\nFor more details, or for other options, see [the installation guide](/intro/install.md).\n\n## Initialize a Helm Chart Repository\n\nOnce you have Helm ready, you can add a chart repository. Check [Artifact\nHub](https://artifacthub.io/packages/search?kind=0) for available Helm chart\nrepositories.\n\n```console\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n```\n\nOnce this is installed, you will be able to list the charts you can install:\n\n```console\n$ helm search repo bitnami\nNAME                             \tCHART VERSION\tAPP VERSION  \tDESCRIPTION\nbitnami/bitnami-common           \t0.0.9        \t0.0.9        \tDEPRECATED Chart with custom templates used in ...\nbitnami/airflow                  \t8.0.2        \t2.0.0        \tApache Airflow is a platform to programmaticall...\nbitnami/apache                   \t8.2.3        \t2.4.46       \tChart for Apache HTTP Server\nbitnami/aspnet-core              \t1.2.3        \t3.1.9        \tASP.NET Core is an open-source framework create...\n# ... and many more\n```\n\n## Install an Example Chart\n\nTo install a chart, you can run the `helm install` command. Helm has several\nways to find and install a chart, but the easiest is to use the `bitnami`\ncharts.\n\n```console\n$ helm repo update              # Make sure we get the latest list of charts\n$ helm install bitnami/mysql --generate-name\nNAME: mysql-1612624192\nLAST DEPLOYED: Sat Feb  6 16:09:56 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES: ...\n```\n\nIn the example above, the `bitnami/mysql` chart was released, and the name of\nour new release is `mysql-1612624192`.\n\nYou get a simple idea of the features of this MySQL chart by running `helm show\nchart bitnami/mysql`. Or you could run `helm show all bitnami/mysql` to get all\ninformation about the chart.\n\nWhenever you install a chart, a new release is created. So one chart can be\ninstalled multiple times into the same cluster. And each can be independently\nmanaged and upgraded.\n\nThe `helm install` command is a very powerful command with many capabilities. To\nlearn more about it, check out the [Using Helm Guide](/intro/using_helm.md).\n\n## Learn About Releases\n\nIt's easy to see what has been released using Helm:\n\n```console\n$ helm list\nNAME            \tNAMESPACE\tREVISION\tUPDATED                             \tSTATUS  \tCHART      \tAPP VERSION\nmysql-1612624192\tdefault  \t1       \t2021-02-06 16:09:56.283059 +0100 CET\tdeployed\tmysql-8.3.0\t8.0.23\n```\n\nThe `helm list` (or `helm ls`) function will show you a list of all deployed releases.\n\n## Uninstall a Release\n\nTo uninstall a release, use the `helm uninstall` command:\n\n```console\n$ helm uninstall mysql-1612624192\nrelease \"mysql-1612624192\" uninstalled\n```\n\nThis will uninstall `mysql-1612624192` from Kubernetes, which will remove all\nresources associated with the release as well as the release history.\n\nIf the flag `--keep-history` is provided, release history will be kept. You will\nbe able to request information about that release:\n\n```console\n$ helm status mysql-1612624192\nStatus: UNINSTALLED\n...\n```\n\nBecause Helm tracks your releases even after you've uninstalled them, you can\naudit a cluster's history, and even undelete a release (with `helm rollback`).\n\n## Reading the Help Text\n\nTo learn more about the available Helm commands, use `helm help` or type a\ncommand followed by the `-h` flag:\n\n```console\n$ helm get -h\n```\n"
  },
  {
    "path": "versioned_docs/version-3/intro/using_helm.md",
    "content": "---\ntitle: Using Helm\ndescription: Explains the basics of Helm.\nsidebar_position: 3\n---\n\nThis guide explains the basics of using Helm to manage packages on your\nKubernetes cluster. It assumes that you have already [installed](/intro/install.md) the Helm client.\n\nIf you are simply interested in running a few quick commands, you may wish to\nbegin with the [Quickstart Guide](/intro/quickstart.md). This chapter\ncovers the particulars of Helm commands, and explains how to use Helm.\n\n## Three Big Concepts\n\nA *Chart* is a Helm package. It contains all of the resource definitions\nnecessary to run an application, tool, or service inside of a Kubernetes\ncluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an\nApt dpkg, or a Yum RPM file.\n\nA *Repository* is the place where charts can be collected and shared. It's like\nPerl's [CPAN archive](https://www.cpan.org) or the [Fedora Package\nDatabase](https://src.fedoraproject.org/), but for Kubernetes packages.\n\nA *Release* is an instance of a chart running in a Kubernetes cluster. One chart\ncan often be installed many times into the same cluster. And each time it is\ninstalled, a new _release_ is created. Consider a MySQL chart. If you want two\ndatabases running in your cluster, you can install that chart twice. Each one\nwill have its own _release_, which will in turn have its own _release name_.\n\nWith these concepts in mind, we can now explain Helm like this:\n\nHelm installs _charts_ into Kubernetes, creating a new _release_ for each\ninstallation. And to find new charts, you can search Helm chart _repositories_.\n\n## 'helm search': Finding Charts\n\nHelm comes with a powerful search command. It can be used to search two\ndifferent types of source:\n\n- `helm search hub` searches [the Artifact Hub](https://artifacthub.io), which\n  lists helm charts from dozens of different repositories.\n- `helm search repo` searches the repositories that you have added to your local\n  helm client (with `helm repo add`). This search is done over local data, and\n  no public network connection is needed.\n\nYou can find publicly available charts by running `helm search hub`:\n\n```console\n$ helm search hub wordpress\nURL                                                 CHART VERSION APP VERSION DESCRIPTION\nhttps://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart\nhttps://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...\n```\n\nThe above searches for all `wordpress` charts on Artifact Hub.\n\nWith no filter, `helm search hub` shows you all of the available charts.\n\n`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\nadd [NAME] [URL]`.\n\nUsing `helm search repo`, you can find the names of the charts in repositories\nyou have already added:\n\n```console\n$ helm repo add brigade https://brigadecore.github.io/charts\n\"brigade\" has been added to your repositories\n$ helm search repo brigade\nNAME                          CHART VERSION APP VERSION DESCRIPTION\nbrigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...\nbrigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...\nbrigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade\nbrigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes\nbrigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project\nbrigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nHelm search uses a fuzzy string matching algorithm, so you can type parts of\nwords or phrases:\n\n```console\n$ helm search repo kash\nNAME            CHART VERSION APP VERSION DESCRIPTION\nbrigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes\n```\n\nSearch is a good way to find available packages. Once you have found a package\nyou want to install, you can use `helm install` to install it.\n\n## 'helm install': Installing a Package\n\nTo install a new package, use the `helm install` command. At its simplest, it\ntakes two arguments: A release name that you pick, and the name of the chart you\nwant to install.\n\n```console\n$ helm install happy-panda bitnami/wordpress\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nNow the `wordpress` chart is installed. Note that installing a chart creates a\nnew _release_ object. The release above is named `happy-panda`. (If you want\nHelm to generate a name for you, leave off the release name and use\n`--generate-name`.)\n\nDuring installation, the `helm` client will print useful information about which\nresources were created, what the state of the release is, and also whether there\nare additional configuration steps you can or should take.\n\nHelm installs resources in the following order:\n\n- Namespace\n- NetworkPolicy\n- ResourceQuota\n- LimitRange\n- PodSecurityPolicy\n- PodDisruptionBudget\n- ServiceAccount\n- Secret\n- SecretList\n- ConfigMap\n- StorageClass\n- PersistentVolume\n- PersistentVolumeClaim\n- CustomResourceDefinition\n- ClusterRole\n- ClusterRoleList\n- ClusterRoleBinding\n- ClusterRoleBindingList\n- Role\n- RoleList\n- RoleBinding\n- RoleBindingList\n- Service\n- DaemonSet\n- Pod\n- ReplicationController\n- ReplicaSet\n- Deployment\n- HorizontalPodAutoscaler\n- StatefulSet\n- Job\n- CronJob\n- Ingress\n- APIService\n- MutatingWebhookConfiguration\n- ValidatingWebhookConfiguration\n\nHelm does not wait until all of the resources are running before it exits. Many\ncharts require Docker images that are over 600MB in size, and may take a long\ntime to install into the cluster.\n\nTo keep track of a release's state, or to re-read configuration information, you\ncan use `helm status`:\n\n```console\n$ helm status happy-panda\nNAME: happy-panda\nLAST DEPLOYED: Tue Jan 26 10:27:17 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n** Please be patient while the chart is being deployed **\n\nYour WordPress site can be accessed through the following DNS name from within your cluster:\n\n    happy-panda-wordpress.default.svc.cluster.local (port 80)\n\nTo access your WordPress site from outside the cluster follow the steps below:\n\n1. Get the WordPress URL by running these commands:\n\n  NOTE: It may take a few minutes for the LoadBalancer IP to be available.\n        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'\n\n   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template \"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}\")\n   echo \"WordPress URL: http://$SERVICE_IP/\"\n   echo \"WordPress Admin URL: http://$SERVICE_IP/admin\"\n\n2. Open a browser and access WordPress using the obtained URL.\n\n3. Login with the following credentials below to see your blog:\n\n  echo Username: user\n  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath=\"{.data.wordpress-password}\" | base64 --decode)\n```\n\nThe above shows the current state of your release.\n\n### Customizing the Chart Before Installing\n\nInstalling the way we have here will only use the default configuration options\nfor this chart. Many times, you will want to customize the chart to use your\npreferred configuration.\n\nTo see what options are configurable on a chart, use `helm show values`:\n\n```console\n$ helm show values bitnami/wordpress\n## Global Docker image parameters\n## Please, note that this will override the image parameters, including dependencies, configured to use the global value\n## Current available global Docker image parameters: imageRegistry and imagePullSecrets\n##\n# global:\n#   imageRegistry: myRegistryName\n#   imagePullSecrets:\n#     - myRegistryKeySecretName\n#   storageClass: myStorageClass\n\n## Bitnami WordPress image version\n## ref: https://hub.docker.com/r/bitnami/wordpress/tags/\n##\nimage:\n  registry: docker.io\n  repository: bitnami/wordpress\n  tag: 5.6.0-debian-10-r35\n  [..]\n```\n\nYou can then override any of these settings in a YAML formatted file, and then\npass that file during installation.\n\n```console\n$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml\n$ helm install -f values.yaml bitnami/wordpress --generate-name\n```\n\nThe above will create a default MariaDB user with the name `user0`, and grant\nthis user access to a newly created `user0db` database, but will accept all the\nrest of the defaults for that chart.\n\nThere are two ways to pass configuration data during install:\n\n- `--values` (or `-f`): Specify a YAML file with overrides. This can be\n  specified multiple times and the rightmost file will take precedence\n- `--set`: Specify overrides on the command line.\n\nIf both are used, `--set` values are merged into `--values` with higher\nprecedence. Overrides specified with `--set` are persisted in a Secret.\nValues that have been `--set` can be viewed for a given release with `helm get\nvalues <release-name>`. Values that have been `--set` can be cleared by running\n`helm upgrade` with `--reset-values` specified.\n\n#### The Format and Limitations of `--set`\n\nThe `--set` option takes zero or more name/value pairs. At its simplest, it is\nused like this: `--set name=value`. The YAML equivalent of that is:\n\n```yaml\nname: value\n```\n\nMultiple values are separated by `,` characters. So `--set a=b,c=d` becomes:\n\n```yaml\na: b\nc: d\n```\n\nMore complex expressions are supported. For example, `--set outer.inner=value`\nis translated into this:\n```yaml\nouter:\n  inner: value\n```\n\nLists can be expressed by enclosing values in `{` and `}`. For example, `--set\nname={a, b, c}` translates to:\n\n```yaml\nname:\n  - a\n  - b\n  - c\n```\n\nCertain name/key can be set to be `null` or to be an empty array `[]`. For example, `--set name=[],a=null` translates\n\n```yaml\nname:\n  - a\n  - b\n  - c\na: b\n```\n\nto\n\n```yaml\nname: []\na: null\n```\n\nAs of Helm 2.5.0, it is possible to access list items using an array index\nsyntax. For example, `--set servers[0].port=80` becomes:\n\n```yaml\nservers:\n  - port: 80\n```\n\nMultiple values can be set this way. The line `--set\nservers[0].port=80,servers[0].host=example` becomes:\n\n```yaml\nservers:\n  - port: 80\n    host: example\n```\n\nSometimes you need to use special characters in your `--set` lines. You can use\na backslash to escape the characters; `--set name=value1\\,value2` will become:\n\n```yaml\nname: \"value1,value2\"\n```\n\nSimilarly, you can escape dot sequences as well, which may come in handy when\ncharts use the `toYaml` function to parse annotations, labels and node\nselectors. The syntax for `--set nodeSelector.\"kubernetes\\.io/role\"=master`\nbecomes:\n\n```yaml\nnodeSelector:\n  kubernetes.io/role: master\n```\n\nDeeply nested data structures can be difficult to express using `--set`. Chart\ndesigners are encouraged to consider the `--set` usage when designing the format\nof a `values.yaml` file  (read more about [Values Files](/chart_template_guide/values_files.md)).\n\n### More Installation Methods\n\nThe `helm install` command can install from several sources:\n\n- A chart repository (as we've seen above)\n- A local chart archive (`helm install foo foo-0.1.1.tgz`)\n- An unpacked chart directory (`helm install foo path/to/foo`)\n- A full URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)\n\n## 'helm upgrade' and 'helm rollback': Upgrading a Release, and Recovering on Failure\n\nWhen a new version of a chart is released, or when you want to change the\nconfiguration of your release, you can use the `helm upgrade` command.\n\nAn upgrade takes an existing release and upgrades it according to the\ninformation you provide. Because Kubernetes charts can be large and complex,\nHelm tries to perform the least invasive upgrade. It will only update things\nthat have changed since the last release.\n\n```console\n$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress\n```\n\nIn the above case, the `happy-panda` release is upgraded with the same chart,\nbut with a new YAML file:\n\n```yaml\nmariadb.auth.username: user1\n```\n\nWe can use `helm get values` to see whether that new setting took effect.\n\n```console\n$ helm get values happy-panda\nmariadb:\n  auth:\n    username: user1\n```\n\nThe `helm get` command is a useful tool for looking at a release in the cluster.\nAnd as we can see above, it shows that our new values from `panda.yaml` were\ndeployed to the cluster.\n\nNow, if something does not go as planned during a release, it is easy to roll\nback to a previous release using `helm rollback [RELEASE] [REVISION]`.\n\n```console\n$ helm rollback happy-panda 1\n```\n\nThe above rolls back our happy-panda to its very first release version. A\nrelease version is an incremental revision. Every time an install, upgrade, or\nrollback happens, the revision number is incremented by 1. The first revision\nnumber is always 1. And we can use `helm history [RELEASE]` to see revision\nnumbers for a certain release.\n\n## Helpful Options for Install/Upgrade/Rollback\n\nThere are several other helpful options you can specify for customizing the\nbehavior of Helm during an install/upgrade/rollback. Please note that this is\nnot a full list of cli flags. To see a description of all flags, just run `helm\n<command> --help`.\n\n- `--timeout`: A [Go duration](https://golang.org/pkg/time/#ParseDuration) value\n  to wait for Kubernetes commands to complete. This defaults to `5m0s`.\n- `--wait`: Waits until all Pods are in a ready state, PVCs are bound,\n  Deployments have minimum (`Desired` minus `maxUnavailable`) Pods in ready\n  state and Services have an IP address (and Ingress if a `LoadBalancer`) before\n  marking the release as successful. It will wait for as long as the `--timeout`\n  value. If timeout is reached, the release will be marked as `FAILED`. Note: In\n  scenarios where Deployment has `replicas` set to 1 and `maxUnavailable` is not\n  set to 0 as part of rolling update strategy, `--wait` will return as ready as\n  it has satisfied the minimum Pod in ready condition.\n- `--no-hooks`: This skips running hooks for the command\n- `--recreate-pods` (only available for `upgrade` and `rollback`): This flag\n  will cause all pods to be recreated (with the exception of pods belonging to\n  deployments). (DEPRECATED in Helm 3)\n\n## 'helm uninstall': Uninstalling a Release\n\nWhen it is time to uninstall a release from the cluster, use the `helm\nuninstall` command:\n\n```console\n$ helm uninstall happy-panda\n```\n\nThis will remove the release from the cluster. You can see all of your currently\ndeployed releases with the `helm list` command:\n\n```console\n$ helm list\nNAME            VERSION UPDATED                         STATUS          CHART\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\n```\n\nFrom the output above, we can see that the `happy-panda` release was\nuninstalled.\n\nIn previous versions of Helm, when a release was deleted, a record of its\ndeletion would remain. In Helm 3, deletion removes the release record as well.\nIf you wish to keep a deletion release record, use `helm uninstall\n--keep-history`. Using `helm list --uninstalled` will only show releases that\nwere uninstalled with the `--keep-history` flag.\n\nThe `helm list --all` flag will show you all release records that Helm has\nretained, including records for failed or deleted items (if `--keep-history` was\nspecified):\n\n```console\n$  helm list --all\nNAME            VERSION UPDATED                         STATUS          CHART\nhappy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0\ninky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0\nkindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0\n```\n\nNote that because releases are now deleted by default, it is no longer possible\nto rollback an uninstalled resource.\n\n## 'helm repo': Working with Repositories\n\nHelm 3 no longer ships with a default chart repository. The `helm repo` command\ngroup provides commands to add, list, and remove repositories.\n\nYou can see which repositories are configured using `helm repo list`:\n\n```console\n$ helm repo list\nNAME            URL\nstable          https://charts.helm.sh/stable\nmumoshu         https://mumoshu.github.io/charts\n```\n\nAnd new repositories can be added with `helm repo\nadd [NAME] [URL]`:\n\n```console\n$ helm repo add dev https://example.com/dev-charts\n```\n\nBecause chart repositories change frequently, at any point you can make sure\nyour Helm client is up to date by running `helm repo update`.\n\nRepositories can be removed with `helm repo remove`.\n\n## Creating Your Own Charts\n\nThe [Chart Development Guide](/topics/charts.md) explains how\nto develop your own charts. But you can get started quickly by using the `helm\ncreate` command:\n\n```console\n$ helm create deis-workflow\nCreating deis-workflow\n```\n\nNow there is a chart in `./deis-workflow`. You can edit it and create your own\ntemplates.\n\nAs you edit your chart, you can validate that it is well-formed by running `helm\nlint`.\n\nWhen it's time to package the chart up for distribution, you can run the `helm\npackage` command:\n\n```console\n$ helm package deis-workflow\ndeis-workflow-0.1.0.tgz\n```\n\nAnd that chart can now easily be installed by `helm install`:\n\n```console\n$ helm install deis-workflow ./deis-workflow-0.1.0.tgz\n...\n```\n\nCharts that are packaged can be loaded into chart repositories. See the\ndocumentation for [Helm chart\nrepositories](/topics/chart_repository.md) for more details.\n\n## Conclusion\n\nThis chapter has covered the basic usage patterns of the `helm` client,\nincluding searching, installation, upgrading, and uninstalling. It has also\ncovered useful utility commands like `helm status`, `helm get`, and `helm repo`.\n\nFor more information on these commands, take a look at Helm's built-in help:\n`helm help`.\n\nIn the [next chapter](/howto/charts_tips_and_tricks.md), we look at the process of developing charts.\n"
  },
  {
    "path": "versioned_docs/version-3/sdk/_install.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tinstallClient := action.NewInstall(actionConfig)\n\n\tinstallClient.DryRunOption = \"none\"\n\tinstallClient.ReleaseName = releaseName\n\tinstallClient.Namespace = settings.Namespace()\n\tinstallClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tinstallClient.CertFile,\n\t\tinstallClient.KeyFile,\n\t\tinstallClient.CaFile,\n\t\tinstallClient.InsecureSkipTLSverify,\n\t\tinstallClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tinstallClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tif chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil {\n\t\tif err := action.CheckDependencies(chart, chartDependencies); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !installClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tmanager := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          installClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t\tRegistryClient:   installClient.GetRegistryClient(),\n\t\t\t}\n\t\t\tif err := manager.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := installClient.RunWithContext(ctx, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run install: %w\", err)\n\t}\n\n\tlogger.Printf(\"release created:\\n%+v\", *release)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "versioned_docs/version-3/sdk/_list.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runList(logger *log.Logger, settings *cli.EnvSettings) error {\n\n\tactionConfig, err := initActionConfigList(settings, logger, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tlistClient := action.NewList(actionConfig)\n\t// Only list deployed\n\t//listClient.Deployed = true\n\tlistClient.All = true\n\tlistClient.SetStateMask()\n\n\tresults, err := listClient.Run()\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run list action: %w\", err)\n\t}\n\n\tfor _, rel := range results {\n\t\tlogger.Printf(\"list result: %+v\", rel)\n\t}\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "versioned_docs/version-3/sdk/_main.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"bufio\"\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\t\"os\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/registry\"\n)\n\nvar helmDriver string = os.Getenv(\"HELM_DRIVER\")\n\nfunc initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) {\n\treturn initActionConfigList(settings, logger, false)\n}\n\nfunc initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) {\n\n\tactionConfig := new(action.Configuration)\n\n\tnamespace := func() string {\n\t\t// For list action, you can pass an empty string instead of settings.Namespace() to list\n\t\t// all namespaces\n\t\tif allNamespaces {\n\t\t\treturn \"\"\n\t\t}\n\t\treturn settings.Namespace()\n\t}()\n\n\tif err := actionConfig.Init(\n\t\tsettings.RESTClientGetter(),\n\t\tnamespace,\n\t\thelmDriver,\n\t\tlogger.Printf); err != nil {\n\t\treturn nil, err\n\t}\n\n\treturn actionConfig, nil\n}\n\nfunc newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) {\n\topts := []registry.ClientOption{\n\t\tregistry.ClientOptDebug(settings.Debug),\n\t\tregistry.ClientOptEnableCache(true),\n\t\tregistry.ClientOptWriter(os.Stderr),\n\t\tregistry.ClientOptCredentialsFile(settings.RegistryConfig),\n\t}\n\tif plainHTTP {\n\t\topts = append(opts, registry.ClientOptPlainHTTP())\n\t}\n\n\t// Create a new registry client\n\tregistryClient, err := registry.NewClient(opts...)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) {\n\tif certFile != \"\" && keyFile != \"\" || caFile != \"\" || insecureSkipTLSverify {\n\t\tregistryClient, err := registry.NewRegistryClientWithTLS(\n\t\t\tlogger.Writer(),\n\t\t\tcertFile,\n\t\t\tkeyFile,\n\t\t\tcaFile,\n\t\t\tinsecureSkipTLSverify,\n\t\t\tsettings.RegistryConfig,\n\t\t\tsettings.Debug)\n\n\t\tif err != nil {\n\t\t\treturn nil, err\n\t\t}\n\t\treturn registryClient, nil\n\t}\n\tregistryClient, err := newRegistryClient(settings, plainHTTP)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\treturn registryClient, nil\n}\n\nfunc main() {\n\n\tlogger := log.Default()\n\n\t// For convenience, initialize SDK setting via CLI mechanism\n\tsettings := cli.New()\n\n\t// Release name, chart and values\n\treleaseName := \"helm-sdk-example\"\n\tchartRef := \"oci://ghcr.io/stefanprodan/charts/podinfo\"\n\treleaseValues := map[string]interface{}{\n\t\t\"replicaCount\": \"2\",\n\t}\n\n\t// Pull the chart to the local filesystem\n\tif err := runPull(logger, settings, chartRef, \"6.4.1\"); err != nil {\n\t\tfmt.Printf(\"failed to run pull: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// Install the chart (from the pulled chart local archive)\n\tif err := runInstall(context.TODO(), logger, settings, releaseName, \"./podinfo-6.4.1.tgz\", \"\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run install: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart installed. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Upgrade to version 6.5.4, updating the replicaCount to three\n\treleaseValues[\"replicaCount\"] = \"3\"\n\tif err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, \"6.5.4\", releaseValues); err != nil {\n\t\tfmt.Printf(\"failed to run upgrade: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t// List installed charts\n\tif err := runList(logger, settings); err != nil {\n\t\tfmt.Printf(\"failed to run list: %+v\", err)\n\t\tos.Exit(1)\n\t}\n\n\t//\n\tfmt.Print(\"Chart upgraded. Press 'Return' to continue...\")\n\tbufio.NewReader(os.Stdin).ReadBytes('\\n')\n\n\t// Uninstall the chart\n\tif err := runUninstall(logger, settings, releaseName); err != nil {\n\t\tfmt.Printf(\"failed to run uninstall: %+v\", err)\n\t\tos.Exit(1)\n\t}\n}\n\n```\n"
  },
  {
    "path": "versioned_docs/version-3/sdk/_pull.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tregistryClient, err := newRegistryClient(settings, false)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to created registry client: %w\", err)\n\t}\n\tactionConfig.RegistryClient = registryClient\n\n\tpullClient := action.NewPullWithOpts(\n\t\taction.WithConfig(actionConfig))\n\t// client.RepoURL = \"\"\n\tpullClient.DestDir = \"./\"\n\tpullClient.Settings = settings\n\tpullClient.Version = chartVersion\n\n\tresult, err := pullClient.Run(chartRef)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to pull chart: %w\", err)\n\t}\n\n\tlogger.Printf(\"%+v\", result)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "versioned_docs/version-3/sdk/_uninstall.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error {\n\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tuninstallClient := action.NewUninstall(actionConfig)\n\tuninstallClient.DeletionPropagation = \"foreground\" // \"background\" or \"orphan\"\n\n\tresult, err := uninstallClient.Run(releaseName)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run uninstall action: %w\", err)\n\t}\n\tif result != nil {\n\t\tlogger.Printf(\"result: %+v\\n\", *result.Release)\n\t}\n\n\tlogger.Printf(\"release \\\"%s\\\" uninstalled\\n\", releaseName)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "versioned_docs/version-3/sdk/_upgrade.mdx",
    "content": "```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\n\t\"helm.sh/helm/v3/pkg/action\"\n\t\"helm.sh/helm/v3/pkg/chart/loader\"\n\t\"helm.sh/helm/v3/pkg/cli\"\n\t\"helm.sh/helm/v3/pkg/downloader\"\n\t\"helm.sh/helm/v3/pkg/getter\"\n)\n\nfunc runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error {\n\tactionConfig, err := initActionConfig(settings, logger)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to init action config: %w\", err)\n\t}\n\n\tupgradeClient := action.NewUpgrade(actionConfig)\n\n\tupgradeClient.Namespace = settings.Namespace()\n\tupgradeClient.DryRunOption = \"none\"\n\tupgradeClient.Version = chartVersion\n\n\tregistryClient, err := newRegistryClientTLS(\n\t\tsettings,\n\t\tlogger,\n\t\tupgradeClient.CertFile,\n\t\tupgradeClient.KeyFile,\n\t\tupgradeClient.CaFile,\n\t\tupgradeClient.InsecureSkipTLSverify,\n\t\tupgradeClient.PlainHTTP)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"missing registry client: %w\", err)\n\t}\n\tupgradeClient.SetRegistryClient(registryClient)\n\n\tchartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tproviders := getter.All(settings)\n\n\t// Check chart dependencies to make sure all are present in /charts\n\tchart, err := loader.Load(chartPath)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to load chart: %w\", err)\n\t}\n\tif req := chart.Metadata.Dependencies; req != nil {\n\t\tif err := action.CheckDependencies(chart, req); err != nil {\n\t\t\terr = fmt.Errorf(\"failed to check chart dependencies: %w\", err)\n\t\t\tif !upgradeClient.DependencyUpdate {\n\t\t\t\treturn err\n\t\t\t}\n\n\t\t\tman := &downloader.Manager{\n\t\t\t\tOut:              logger.Writer(),\n\t\t\t\tChartPath:        chartPath,\n\t\t\t\tKeyring:          upgradeClient.ChartPathOptions.Keyring,\n\t\t\t\tSkipUpdate:       false,\n\t\t\t\tGetters:          providers,\n\t\t\t\tRepositoryConfig: settings.RepositoryConfig,\n\t\t\t\tRepositoryCache:  settings.RepositoryCache,\n\t\t\t\tDebug:            settings.Debug,\n\t\t\t}\n\t\t\tif err := man.Update(); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t\t// Reload the chart with the updated Chart.lock file.\n\t\t\tif chart, err = loader.Load(chartPath); err != nil {\n\t\t\t\treturn fmt.Errorf(\"failed to reload chart after repo update: %w\", err)\n\t\t\t}\n\t\t}\n\t}\n\n\trelease, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to run upgrade action: %w\", err)\n\t}\n\n\tlogger.Printf(\"release: %+v\", release)\n\n\treturn nil\n}\n\n```\n"
  },
  {
    "path": "versioned_docs/version-3/sdk/examples.mdx",
    "content": "---\ntitle: Examples\ndescription: Examples various features if the Helm SDK\nsidebar_position: 2\n---\nimport Install from './_install.mdx'\nimport List from './_list.mdx'\nimport Main from './_main.mdx'\nimport Pull from './_pull.mdx'\nimport Uninstall from './_uninstall.mdx'\nimport Upgrade from './_upgrade.mdx'\n\nThis document runs though a series of examples of using the Helm SDK.\nIntended to document various SDK functionalities.\n\nThe final example shows `main.go` driver ([link](#driver)). That runs the below actions and includes necessary helper functions.\n\nThe code for the examples lives in the [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples) directory.\nAnd is intended to be fully functional.\n\n## Actions\n\n\n### Install Action\n\nThis example installs the given chart/release, for the given version and values:\n\n<Install />\n\n### Upgrade Action\n\nThis example upgrades the given release, with the given chart, version and values:\n\n<Upgrade />\n\n### Uninstall Action\n\nThis example uninstalls the given release\n\n<Uninstall />\n\n### List Action\n\nThis example lists all released charts (in the currently configured namespace)\n\n<List />\n\n### Pull Action\n\nThis example pulls a chart from an OCI repository\n\n<Pull />\n\n## Driver\n\nThe 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.\n\n<Main />"
  },
  {
    "path": "versioned_docs/version-3/sdk/gosdk.md",
    "content": "---\ntitle: Introduction\ndescription: Introduces the Helm Go SDK\nsidebar_position: 1\n---\nHelm's Go SDK enables custom software to leverage Helm charts and Helm's functionality for managing Kubernetes software deployment\n(In fact, the Helm CLI is effectively just one such tool!)\n\nCurrently, the SDK has been functionally separated from the Helm CLI.\nAnd the SDK can (and is) used by standalone tooling.\nThe Helm project has committed to API stability for the SDK.\nAs 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.\n\nFull API documentation can be found at [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3).\n\nA brief overview of some of the main types of packages and a simple example follows below.\nSee the [Examples](/sdk/examples.mdx) section for more examples and a more full featured 'driver'.\n\n## Main package overview\n\n- [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action):\n  Contains the main “client” for performing Helm actions.\n  This is the same package that the CLI is using underneath the hood.\n  If you just need to perform basic Helm commands from another Go program, this package is for you\n- [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil):\n  Methods and helpers used for loading and manipulating charts\n- [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) and its subpackages:\n  Contains all the handlers for the standard Helm environment variables and its subpackages contain output and values file handling\n- [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release):\n  Defines the `Release` object and statuses\n\nThere are many more packages besides these, so go check out the documentation for more information!\n\n### Simple example\nThis is a simple example of doing a `helm list` using the Go SDK.\nSee the [Examples](/sdk/examples.mdx) section for more full featured examples.\n\n```go\npackage main\n\nimport (\n    \"log\"\n    \"os\"\n\n    \"helm.sh/helm/v3/pkg/action\"\n    \"helm.sh/helm/v3/pkg/cli\"\n)\n\nfunc main() {\n    settings := cli.New()\n\n    actionConfig := new(action.Configuration)\n    // You can pass an empty string instead of settings.Namespace() to list\n    // all namespaces\n    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv(\"HELM_DRIVER\"), log.Printf); err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    client := action.NewList(actionConfig)\n    // Only list deployed\n    client.Deployed = true\n    results, err := client.Run()\n    if err != nil {\n        log.Printf(\"%+v\", err)\n        os.Exit(1)\n    }\n\n    for _, rel := range results {\n        log.Printf(\"%+v\", rel)\n    }\n}\n\n```\n\n\n## Compatibility\n\nThe Helm SDK explicitly follows the Helm backwards compatibility guarantees:\n\n<https://github.com/helm/community/blob/main/hips/hip-0004.md>\n\nThat is, break changes will only be made over major versions.\n"
  },
  {
    "path": "versioned_docs/version-3/sdk/index.mdx",
    "content": "---\ntitle: Go SDK\nsidebar_position: 7\n---\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/topics/advanced.md",
    "content": "---\ntitle: Advanced Helm Techniques\ndescription: Explains various advanced features for Helm power users\nsidebar_position: 9\n---\n\nThis section explains various advanced features and techniques for using Helm.\nThe information in this section is intended for \"power users\" of Helm that wish\nto do advanced customization and manipulation of their charts and releases. Each\nof these advanced features comes with their own tradeoffs and caveats, so each\none must be used carefully and with deep knowledge of Helm. Or in other words,\nremember the [Peter Parker\nprinciple](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)\n\n## Post Rendering\nPost rendering gives chart installers the ability to manually manipulate,\nconfigure, and/or validate rendered manifests before they are installed by Helm.\nThis allows users with advanced configuration needs to be able to use tools like\n[`kustomize`](https://kustomize.io) to apply configuration changes without the\nneed to fork a public chart or requiring chart maintainers to specify every last\nconfiguration option for a piece of software. There are also use cases for\ninjecting common tools and side cars in enterprise environments or analysis of\nthe manifests before deployment.\n\n### Prerequisites\n- Helm 3.1+\n\n### Usage\nA post-renderer can be any executable that accepts rendered Kubernetes manifests\non STDIN and returns valid Kubernetes manifests on STDOUT. It should return an\nnon-0 exit code in the event of a failure. This is the only \"API\" between the\ntwo components. It allows for great flexibility in what you can do with your\npost-render process.\n\nA post renderer can be used with `install`, `upgrade`, and `template`. To use a\npost-renderer, use the `--post-renderer` flag with a path to the renderer\nexecutable you wish to use:\n\n```shell\n$ helm install mychart stable/wordpress --post-renderer ./path/to/executable\n```\n\nIf the path does not contain any separators, it will search in $PATH, otherwise\nit will resolve any relative paths to a fully qualified path\n\nIf you wish to use multiple post-renderers, call all of them in a script or\ntogether in whatever binary tool you have built. In bash, this would be as\nsimple as `renderer1 | renderer2 | renderer3`.\n\nYou can see an example of using `kustomize` as a post renderer\n[here](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).\n\n### Caveats\nWhen using post renderers, there are several important things to keep in mind.\nThe most important of these is that when using a post-renderer, all people\nmodifying that release **MUST** use the same renderer in order to have\nrepeatable builds. This feature is purposefully built to allow any user to\nswitch out which renderer they are using or to stop using a renderer, but this\nshould be done deliberately to avoid accidental modification or data loss.\n\nOne other important note is around security. If you are using a post-renderer,\nyou should ensure it is coming from a reliable source (as is the case for any\nother arbitrary executable). Using non-trusted or non-verified renderers is NOT\nrecommended as they have full access to rendered templates, which often contain\nsecret data.\n\n### Custom Post Renderers\nThe post render step offers even more flexibility when used in the Go SDK. Any\npost renderer only needs to implement the following Go interface:\n\n```go\ntype PostRenderer interface {\n    // Run expects a single buffer filled with Helm rendered manifests. It\n    // expects the modified results to be returned on a separate buffer or an\n    // error if there was an issue or failure while running the post render step\n    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)\n}\n```\n\nFor more information on using the Go SDK, See the [Go SDK section](#go-sdk)\n\n## Go SDK\nHelm 3 debuted a completely restructured Go SDK for a better experience when\nbuilding software and tools that leverage Helm. Full documentation can be found\nin the [Go SDK Section](/sdk/gosdk.md).\n\n## Storage backends\n\nHelm 3 changed the default release information storage to Secrets in the\nnamespace of the release. Helm 2 by default stores release information as\nConfigMaps in the namespace of the Tiller instance. The subsections which follow\nshow how to configure different backends. This configuration is based on the\n`HELM_DRIVER` environment variable. It can be set to one of the values:\n`[configmap, secret, sql]`.\n\n### ConfigMap storage backend\n\nTo enable the ConfigMap backend, you'll need to set the environmental variable\n`HELM_DRIVER` to `configmap`.\n\nYou can set it in a shell as follows:\n\n```shell\nexport HELM_DRIVER=configmap\n```\n\nIf you want to switch from the default backend to the ConfigMap backend, you'll\nhave to do the migration for this on your own. You can retrieve release\ninformation with the following command:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n\n**PRODUCTION NOTES**: The release information includes the contents of charts and\nvalues files, and therefore might contain sensitive data (like\npasswords, private keys, and other credentials) that needs to be protected from\nunauthorized access. When managing Kubernetes authorization, for instance with\n[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), it is\npossible to grant broader access to ConfigMap resources, while restricting\naccess to Secret resources. For instance, the default [user-facing\nrole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\n\"view\" grants access to most resources, but not to Secrets. Furthermore, secrets\ndata can be configured for [encrypted\nstorage](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).\nPlease keep that in mind if you decide to switch to the ConfigMap backend, as it\ncould expose your application's sensitive data.\n\n### SQL storage backend\n\nThere is a ***beta*** SQL storage backend that stores release information in an SQL\ndatabase.\n\nUsing such a storage backend is particularly useful if your release information\nweighs more than 1MB (in which case, it can't be stored in ConfigMaps/Secrets\nbecause of internal limits in Kubernetes' underlying etcd key-value store).\n\nTo enable the SQL backend, you'll need to deploy a SQL database and set the\nenvironmental variable `HELM_DRIVER` to `sql`. The DB details are set with the\nenvironmental variable `HELM_DRIVER_SQL_CONNECTION_STRING`.\n\nYou can set it in a shell as follows:\n\n```shell\nexport HELM_DRIVER=sql\nexport HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme\n```\n\n> Note: Only PostgreSQL is supported at this moment.\n\n**PRODUCTION NOTES**: It is recommended to:\n- Make your database production ready. For PostgreSQL, refer to the [Server Administration](https://www.postgresql.org/docs/12/admin.html) docs for more details\n- Enable [permission management](/topics/permissions_sql_storage_backend.md) to\nmirror Kubernetes RBAC for release information\n\nIf you want to switch from the default backend to the SQL backend, you'll have\nto do the migration for this on your own. You can retrieve release information\nwith the following command:\n\n```shell\nkubectl get secret --all-namespaces -l \"owner=helm\"\n```\n"
  },
  {
    "path": "versioned_docs/version-3/topics/architecture.md",
    "content": "---\ntitle: Helm Architecture\ndescription: Describes the Helm architecture at a high level.\nsidebar_position: 8\n---\n\n# Helm Architecture\n\nThis document describes the Helm architecture at a high level.\n\n## The Purpose of Helm\n\nHelm is a tool for managing Kubernetes packages called _charts_. Helm can do the\nfollowing:\n\n- Create new charts from scratch\n- Package charts into chart archive (tgz) files\n- Interact with chart repositories where charts are stored\n- Install and uninstall charts into an existing Kubernetes cluster\n- Manage the release cycle of charts that have been installed with Helm\n\nFor Helm, there are three important concepts:\n\n1. The _chart_ is a bundle of information necessary to create an instance of a\n   Kubernetes application.\n2. The _config_ contains configuration information that can be merged into a\n   packaged chart to create a releasable object.\n3. A _release_ is a running instance of a _chart_, combined with a specific\n   _config_.\n\n## Components\n\nHelm is an executable which is implemented into two distinct parts:\n\n**The Helm Client** is a command-line client for end users. The client is\nresponsible for the following:\n\n- Local chart development\n- Managing repositories\n- Managing releases\n- Interfacing with the Helm library\n  - Sending charts to be installed\n  - Requesting upgrading or uninstalling of existing releases\n\n**The Helm Library** provides the logic for executing all Helm operations. It\ninterfaces with the Kubernetes API server and provides the following capability:\n\n- Combining a chart and configuration to build a release\n- Installing charts into Kubernetes, and providing the subsequent release object\n- Upgrading and uninstalling charts by interacting with Kubernetes\n\nThe standalone Helm library encapsulates the Helm logic so that it can be\nleveraged by different clients.\n\n## Implementation\n\nThe Helm client and library is written in the Go programming language.\n\nThe library uses the Kubernetes client library to communicate with Kubernetes.\nCurrently, that library uses REST+JSON. It stores information in Secrets located\ninside of Kubernetes. It does not need its own database.\n\nConfiguration files are, when possible, written in YAML.\n"
  },
  {
    "path": "versioned_docs/version-3/topics/chart_repository.md",
    "content": "---\ntitle: The Chart Repository Guide\ndescription: How to create and work with Helm chart repositories.\nsidebar_position: 6\n---\n\nThis section explains how to create and work with Helm chart repositories. At a\nhigh level, a chart repository is a location where packaged charts can be stored\nand shared.\n\nThe distributed community Helm chart repository is located at\n[Artifact Hub](https://artifacthub.io/packages/search?kind=0) and welcomes\nparticipation. But Helm also makes it possible to create and run your own chart\nrepository. This guide explains how to do so. If you are considering creating a\nchart repository, you may want to consider using an\n[OCI registry](/topics/registries.md) instead.\n\n## Prerequisites\n\n* Go through the [Quickstart](/intro/quickstart.md) Guide\n* Read through the [Charts](/topics/charts.md) document\n\n## Create a chart repository\n\nA _chart repository_ is an HTTP server that houses an `index.yaml` file and\noptionally some packaged charts.  When you're ready to share your charts, the\npreferred way to do so is by uploading them to a chart repository.\n\nAs of Helm 2.2.0, client-side SSL auth to a repository is supported. Other\nauthentication protocols may be available as plugins.\n\nBecause a chart repository can be any HTTP server that can serve YAML and tar\nfiles and can answer GET requests, you have a plethora of options when it comes\ndown to hosting your own chart repository. For example, you can use a Google\nCloud Storage (GCS) bucket, Amazon S3 bucket, GitHub Pages, or even create your\nown web server.\n\n### The chart repository structure\n\nA chart repository consists of packaged charts and a special file called\n`index.yaml` which contains an index of all of the charts in the repository.\nFrequently, the charts that `index.yaml` describes are also hosted on the same\nserver, as are the [provenance files](/topics/provenance.md).\n\nFor example, the layout of the repository `https://example.com/charts` might\nlook like this:\n\n```\ncharts/\n  |\n  |- index.yaml\n  |\n  |- alpine-0.1.2.tgz\n  |\n  |- alpine-0.1.2.tgz.prov\n```\n\nIn this case, the index file would contain information about one chart, the\nAlpine chart, and provide the download URL\n`https://example.com/charts/alpine-0.1.2.tgz` for that chart.\n\nIt is not required that a chart package be located on the same server as the\n`index.yaml` file. However, doing so is often the easiest.\n\n### The index file\n\nThe index file is a yaml file called `index.yaml`. It contains some metadata\nabout the package, including the contents of a chart's `Chart.yaml` file. A\nvalid chart repository must have an index file. The index file contains\ninformation about each chart in the chart repository. The `helm repo index`\ncommand will generate an index file based on a given local directory that\ncontains packaged charts.\n\nThis is an example of an index file:\n\n```yaml\napiVersion: v1\nentries:\n  alpine:\n    - created: 2016-10-06T16:23:20.499814565-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz\n      version: 0.2.0\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Deploy a basic Alpine Linux pod\n      digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727\n      home: https://helm.sh/helm\n      name: alpine\n      sources:\n      - https://github.com/helm/helm\n      urls:\n      - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz\n      version: 0.1.0\n  nginx:\n    - created: 2016-10-06T16:23:20.499543808-06:00\n      description: Create a basic nginx HTTP server\n      digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff\n      home: https://helm.sh/helm\n      name: nginx\n      sources:\n      - https://github.com/helm/charts\n      urls:\n      - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz\n      version: 1.1.0\ngenerated: 2016-10-06T16:23:20.499029981-06:00\n```\n\n## Hosting Chart Repositories\n\nThis part shows several ways to serve a chart repository.\n\n### Google Cloud Storage\n\nThe first step is to **create your GCS bucket**. We'll call ours\n`fantastic-charts`.\n\n![Create a GCS Bucket](/img/helm2/create-a-bucket.png)\n\nNext, make your bucket public by **editing the bucket permissions**.\n\n![Edit Permissions](/img/helm2/edit-permissions.png)\n\nInsert this line item to **make your bucket public**:\n\n![Make Bucket Public](/img/helm2/make-bucket-public.png)\n\nCongratulations, now you have an empty GCS bucket ready to serve charts!\n\nYou may upload your chart repository using the Google Cloud Storage command\nline tool, or using the GCS web UI. A public GCS bucket can be accessed via\nsimple HTTPS at this address: `https://bucket-name.storage.googleapis.com/`.\n\n### Cloudsmith\n\nYou can also set up chart repositories using Cloudsmith. Read more about\nchart repositories with Cloudsmith\n[here](https://help.cloudsmith.io/docs/helm-chart-repository)\n\n### JFrog Artifactory\n\nSimilarly, you can also set up chart repositories using JFrog Artifactory. Read more about\nchart repositories with JFrog Artifactory\n[here](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)\n\n### GitHub Pages example\n\nIn a similar way you can create charts repository using GitHub Pages.\n\nGitHub allows you to serve static web pages in two different ways:\n\n- By configuring a project to serve the contents of its `docs/` directory\n- By configuring a project to serve a particular branch\n\nWe'll take the second approach, though the first is just as easy.\n\nThe first step will be to **create your gh-pages branch**.  You can do that\nlocally as.\n\n```console\n$ git checkout -b gh-pages\n```\n\nOr via web browser using **Branch** button on your GitHub repository:\n\n![Create GitHub Pages branch](/img/helm2/create-a-gh-page-button.png)\n\nNext, you'll want to make sure your **gh-pages branch** is set as GitHub Pages,\nclick on your repo **Settings** and scroll down to **GitHub pages** section and\nset as per below:\n\n![Create GitHub Pages branch](/img/helm2/set-a-gh-page.png)\n\nBy default **Source** usually gets set to **gh-pages branch**. If this is not\nset by default, then select it.\n\nYou can use a **custom domain** there if you wish so.\n\nAnd check that **Enforce HTTPS** is ticked, so the **HTTPS** will be used when\ncharts are served.\n\nIn such setup you can use your default branch to store your charts code, and\n**gh-pages branch** as charts repository, e.g.:\n`https://USERNAME.github.io/REPONAME`. The demonstration [TS\nCharts](https://github.com/technosophos/tscharts) repository is accessible at\n`https://technosophos.github.io/tscharts/`.\n\nIf you have decided to use GitHub pages to host the chart repository, check out\n[Chart Releaser Action](/howto/chart_releaser_action.md).\nChart Releaser Action is a GitHub Action workflow to turn a GitHub project into\na self-hosted Helm chart repo, using\n[helm/chart-releaser](https://github.com/helm/chart-releaser) CLI tool.\n\n### Ordinary web servers\n\nTo configure an ordinary web server to serve Helm charts, you merely need to do\nthe following:\n\n- Put your index and charts in a directory that the server can serve\n- Make sure the `index.yaml` file can be accessed with no authentication\n  requirement\n- Make sure `yaml` files are served with the correct content type (`text/yaml`\n  or `text/x-yaml`)\n\nFor example, if you want to serve your charts out of `$WEBROOT/charts`, make\nsure there is a `charts/` directory in your web root, and put the index file and\ncharts inside of that folder.\n\n### ChartMuseum Repository Server\n\nChartMuseum is an open-source Helm Chart Repository server written in Go\n(Golang), with support for cloud storage backends, including [Google Cloud\nStorage](https://cloud.google.com/storage/), [Amazon\nS3](https://aws.amazon.com/s3/), [Microsoft Azure Blob\nStorage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba\nCloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object\nStorage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud\nInfrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud\nBOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object\nStorage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean\nSpaces](https://www.digitalocean.com/products/spaces/),\n[Minio](https://min.io/), and [etcd](https://etcd.io/).\n\nYou can also use the\n[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)\nserver to host a chart repository from a local file system.\n\n### GitLab Package Registry\n\nWith GitLab you can publish Helm charts in your project’s Package Registry.\nRead more about setting up a helm package repository with GitLab [here](https://docs.gitlab.com/ee/user/packages/helm_repository/).\n\n## Managing Chart Repositories\n\nNow that you have a chart repository, the last part of this guide explains how\nto maintain charts in that repository.\n\n\n### Store charts in your chart repository\n\nNow that you have a chart repository, let's upload a chart and an index file to\nthe repository.  Charts in a chart repository must be packaged (`helm package\nchart-name/`) and versioned correctly (following [SemVer 2](https://semver.org/)\nguidelines).\n\nThese next steps compose an example workflow, but you are welcome to use\nwhatever workflow you fancy for storing and updating charts in your chart\nrepository.\n\nOnce you have a packaged chart ready, create a new directory, and move your\npackaged chart to that directory.\n\n```console\n$ helm package docs/examples/alpine/\n$ mkdir fantastic-charts\n$ mv alpine-0.1.0.tgz fantastic-charts/\n$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com\n```\n\nThe last command takes the path of the local directory that you just created and\nthe URL of your remote chart repository and composes an `index.yaml` file inside\nthe given directory path.\n\nNow you can upload the chart and the index file to your chart repository using a\nsync tool or manually. If you're using Google Cloud Storage, check out this\n[example workflow](/howto/chart_repository_sync_example.md)\nusing the gsutil client. For GitHub, you can simply put the charts in the\nappropriate destination branch.\n\n### Add new charts to an existing repository\n\nEach time you want to add a new chart to your repository, you must regenerate\nthe index. The `helm repo index` command will completely rebuild the\n`index.yaml` file from scratch, including only the charts that it finds locally.\n\nHowever, you can use the `--merge` flag to incrementally add new charts to an\nexisting `index.yaml` file (a great option when working with a remote repository\nlike GCS). Run `helm repo index --help` to learn more,\n\nMake sure that you upload both the revised `index.yaml` file and the chart. And\nif you generated a provenance file, upload that too.\n\n### Share your charts with others\n\nWhen you're ready to share your charts, simply let someone know what the URL of\nyour repository is.\n\nFrom there, they will add the repository to their helm client via the `helm repo\nadd [NAME] [URL]` command with any name they would like to use to reference the\nrepository.\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\nIf the charts are backed by HTTP basic authentication, you can also supply the\nusername and password here:\n\n```console\n$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password\n$ helm repo list\nfantastic-charts    https://fantastic-charts.storage.googleapis.com\n```\n\n**Note:** A repository will not be added if it does not contain a valid\n`index.yaml`.\n\n**Note:** If your helm repository is e.g. using a self signed\ncertificate, you can use `helm repo add --insecure-skip-tls-verify ...` in order\nto skip the CA verification.\n\nAfter that, your users will be able to search through your charts. After you've\nupdated the repository, they can use the `helm repo update` command to get the\nlatest chart information.\n\n*Under the hood, the `helm repo add` and `helm repo update` commands are\nfetching the index.yaml file and storing them in the\n`$XDG_CACHE_HOME/helm/repository/cache/` directory. This is where the `helm\nsearch` function finds information about charts.*\n"
  },
  {
    "path": "versioned_docs/version-3/topics/chart_tests.md",
    "content": "---\ntitle: Chart Tests\ndescription: Describes how to run and test your charts.\nsidebar_position: 3\n---\n\nA chart contains a number of Kubernetes resources and components that work\ntogether. As a chart author, you may want to write some tests that validate that\nyour chart works as expected when it is installed. These tests also help the\nchart consumer understand what your chart is supposed to do.\n\nA **test** in a helm chart lives under the `templates/` directory and is a job\ndefinition that specifies a container with a given command to run. The container\nshould exit successfully (exit 0) for a test to be considered a success. The job\ndefinition must contain the helm test hook annotation: `helm.sh/hook: test`.\n\nNote that until Helm v3, the job definition needed to contain one of these helm\ntest hook annotations: `helm.sh/hook: test-success` or `helm.sh/hook: test-failure`.\n`helm.sh/hook: test-success` is still accepted as a backwards-compatible\nalternative to `helm.sh/hook: test`.\n\nExample tests:\n\n- Validate that your configuration from the values.yaml file was properly\n  injected.\n  - Make sure your username and password work correctly\n  - Make sure an incorrect username and password does not work\n- Assert that your services are up and correctly load balancing\n- etc.\n\nYou can run the pre-defined tests in Helm on a release using the command `helm\ntest <RELEASE_NAME>`. For a chart consumer, this is a great way to check that\ntheir release of a chart (or application) works as expected.\n\n## Example Test\n\nThe [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. \n\n```console\n$ helm create demo\n```\n\nYou will now be able to see the following structure in your demo helm chart.\n\n```\ndemo/\n  Chart.yaml\n  values.yaml\n  charts/\n  templates/\n  templates/tests/test-connection.yaml\n```\n\nIn `demo/templates/tests/test-connection.yaml` you'll see a test you can try. You can see the helm test pod definition here:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: \"{{ include \"demo.fullname\" . }}-test-connection\"\n  labels:\n    {{- include \"demo.labels\" . | nindent 4 }}\n  annotations:\n    \"helm.sh/hook\": test\nspec:\n  containers:\n    - name: wget\n      image: busybox\n      command: ['wget']\n      args: ['{{ include \"demo.fullname\" . }}:{{ .Values.service.port }}']\n  restartPolicy: Never\n\n```\n\n## Steps to Run a Test Suite on a Release\n\nFirst, install the chart on your cluster to create a release. You may have to\nwait for all pods to become active; if you test immediately after this install,\nit is likely to show a transitive failure, and you will want to re-test.\n\n```console\n$ helm install demo demo --namespace default\n$ helm test demo\nNAME: demo\nLAST DEPLOYED: Mon Feb 14 20:03:16 2022\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE:     demo-test-connection\nLast Started:   Mon Feb 14 20:35:19 2022\nLast Completed: Mon Feb 14 20:35:23 2022\nPhase:          Succeeded\n[...]\n```\n\n## Notes\n\n- You can define as many tests as you would like in a single yaml file or spread\n  across several yaml files in the `templates/` directory.\n- You are welcome to nest your test suite under a `tests/` directory like\n  `<chart-name>/templates/tests/` for more isolation.\n- A test is a [Helm hook](/topics/charts_hooks.md), so annotations like\n  `helm.sh/hook-weight` and `helm.sh/hook-delete-policy` may be used with test\n  resources.\n"
  },
  {
    "path": "versioned_docs/version-3/topics/charts.md",
    "content": "---\ntitle: Charts\ndescription: Explains the chart format, and provides basic guidance for building charts with Helm.\nsidebar_position: 1\n---\n\nHelm uses a packaging format called _charts_. A chart is a collection of files\nthat describe a related set of Kubernetes resources. A single chart might be\nused to deploy something simple, like a memcached pod, or something complex,\nlike a full web app stack with HTTP servers, databases, caches, and so on.\n\nCharts are created as files laid out in a particular directory tree. They can be\npackaged into versioned archives to be deployed.\n\nIf you want to download and look at the files for a published chart, without\ninstalling it, you can do so with `helm pull chartrepo/chartname`.\n\nThis document explains the chart format, and provides basic guidance for\nbuilding charts with Helm.\n\n## The Chart File Structure\n\nA chart is organized as a collection of files inside of a directory. The\ndirectory name is the name of the chart (without versioning information). Thus,\na chart describing WordPress would be stored in a `wordpress/` directory.\n\nInside of this directory, Helm will expect a structure that matches this:\n\n```text\nwordpress/\n  Chart.yaml          # A YAML file containing information about the chart\n  LICENSE             # OPTIONAL: A plain text file containing the license for the chart\n  README.md           # OPTIONAL: A human-readable README file\n  values.yaml         # The default configuration values for this chart\n  values.schema.json  # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file\n  charts/             # A directory containing any charts upon which this chart depends.\n  crds/               # Custom Resource Definitions\n  templates/          # A directory of templates that, when combined with values,\n                      # will generate valid Kubernetes manifest files.\n  templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes\n```\n\nHelm reserves use of the `charts/`, `crds/`, and `templates/` directories, and\nof the listed file names. Other files will be left as they are.\n\n## The Chart.yaml File\n\nThe `Chart.yaml` file is required for a chart. It contains the following fields:\n\n```yaml\napiVersion: The chart API version (required)\nname: The name of the chart (required)\nversion: The version of the chart (required)\nkubeVersion: A SemVer range of compatible Kubernetes versions (optional)\ndescription: A single-sentence description of this project (optional)\ntype: The type of the chart (optional)\nkeywords:\n  - A list of keywords about this project (optional)\nhome: The URL of this projects home page (optional)\nsources:\n  - A list of URLs to source code for this project (optional)\ndependencies: # A list of the chart requirements (optional)\n  - name: The name of the chart (nginx)\n    version: The version of the chart (\"1.2.3\")\n    repository: (optional) The repository URL (\"https://example.com/charts\") or alias (\"@repo-name\")\n    condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )\n    tags: # (optional)\n      - Tags can be used to group charts for enabling/disabling together\n    import-values: # (optional)\n      - 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.\n    alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times\nmaintainers: # (optional)\n  - name: The maintainers name (required for each maintainer)\n    email: The maintainers email (optional for each maintainer)\n    url: A URL for the maintainer (optional for each maintainer)\nicon: A URL to an SVG or PNG image to be used as an icon (optional).\nappVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.\ndeprecated: Whether this chart is deprecated (optional, boolean)\nannotations:\n  example: A list of annotations keyed by name (optional).\n```\n\nAs of [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), additional\nfields are not allowed.\nThe recommended approach is to add custom metadata in `annotations`.\n\n### Charts and Versioning\n\nEvery chart must have a version number. A version should follow the [SemVer\n2](https://semver.org/spec/v2.0.0.html) standard but it is not strictly enforced. Unlike Helm Classic, Helm v2\nand later uses version numbers as release markers. Packages in repositories are\nidentified by name plus version.\n\nFor example, an `nginx` chart whose version field is set to `version: 1.2.3`\nwill be named:\n\n```text\nnginx-1.2.3.tgz\n```\n\nMore complex SemVer 2 names are also supported, such as `version:\n1.2.3-alpha.1+ef365`. But non-SemVer names are explicitly disallowed by the\nsystem. Subject to exception are versions in format `x` or `x.y`.\nFor 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).\n\n**NOTE:** Whereas Helm Classic and Deployment Manager were both very GitHub\noriented when it came to charts, Helm v2 and later does not rely upon or require\nGitHub or even Git. Consequently, it does not use Git SHAs for versioning at\nall.\n\nThe `version` field inside of the `Chart.yaml` is used by many of the Helm\ntools, including the CLI. When generating a package, the `helm package` command\nwill use the version that it finds in the `Chart.yaml` as a token in the package\nname. The system assumes that the version number in the chart package name\nmatches the version number in the `Chart.yaml`. Failure to meet this assumption\nwill cause an error.\n\n### The `apiVersion` Field\n\nThe `apiVersion` field should be `v2` for Helm charts that require at least Helm\n3. Charts supporting previous Helm versions have an `apiVersion` set to `v1` and\nare still installable by Helm 3.\n\nChanges from `v1` to `v2`:\n\n- A `dependencies` field defining chart dependencies, which were located in a\n  separate `requirements.yaml` file for `v1` charts (see [Chart\n  Dependencies](#chart-dependencies)).\n- The `type` field, discriminating application and library charts (see [Chart\n  Types](#chart-types)).\n\n### The `appVersion` Field\n\nNote that the `appVersion` field is not related to the `version` field. It is a\nway of specifying the version of the application. For example, the `drupal`\nchart may have an `appVersion: \"8.2.1\"`, indicating that the version of Drupal\nincluded in the chart (by default) is `8.2.1`. This field is informational, and\nhas 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.\n\nAs of Helm v3.5.0, `helm create` wraps the default `appVersion` field in quotes.\n\n### The `kubeVersion` Field\n\nThe optional `kubeVersion` field can define semver constraints on supported\nKubernetes versions. Helm will validate the version constraints when installing\nthe chart and fail if the cluster runs an unsupported Kubernetes version.\n\nVersion constraints may comprise space separated AND comparisons such as\n```\n>= 1.13.0 < 1.15.0\n```\nwhich themselves can be combined with the OR `||` operator like in the following\nexample\n```\n>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0\n```\nIn this example the version `1.14.0` is excluded, which can make sense if a bug\nin certain versions is known to prevent the chart from running properly.\n\nApart from version constrains employing operators `=` `!=` `>` `<` `>=` `<=` the\nfollowing shorthand notations are supported\n\n * hyphen ranges for closed intervals, where `1.1 - 2.3.4` is equivalent to `>=\n   1.1 <= 2.3.4`.\n * wildcards `x`, `X` and `*`, where `1.2.x` is equivalent to `>= 1.2.0 <\n   1.3.0`.\n * tilde ranges (patch version changes allowed), where `~1.2.3` is equivalent to\n   `>= 1.2.3 < 1.3.0`.\n * caret ranges (minor version changes allowed), where `^1.2.3` is equivalent to\n   `>= 1.2.3 < 2.0.0`.\n\nFor a detailed explanation of supported semver constraints see\n[Masterminds/semver](https://github.com/Masterminds/semver).\n\n### Deprecating Charts\n\nWhen managing charts in a Chart Repository, it is sometimes necessary to\ndeprecate a chart. The optional `deprecated` field in `Chart.yaml` can be used\nto mark a chart as deprecated. If the **latest** version of a chart in the\nrepository is marked as deprecated, then the chart as a whole is considered to\nbe deprecated. The chart name can be later reused by publishing a newer version\nthat is not marked as deprecated. The workflow for deprecating charts is:\n\n1. Update chart's `Chart.yaml` to mark the chart as deprecated, bumping the\n   version\n2. Release the new chart version in the Chart Repository\n3. Remove the chart from the source repository (e.g. git)\n\n### Chart Types\n\nThe `type` field defines the type of chart. There are two types: `application`\nand `library`. Application is the default type and it is the standard chart\nwhich can be operated on fully. The [library chart](/topics/library_charts.md) provides utilities or functions for the\nchart builder. A library chart differs from an application chart because it is\nnot installable and usually doesn't contain any resource objects.\n\n**Note:** An application chart can be used as a library chart. This is enabled\nby setting the type to `library`. The chart will then be rendered as a library\nchart where all utilities and functions can be leveraged. All resource objects\nof the chart will not be rendered.\n\n## Chart LICENSE, README and NOTES\n\nCharts can also contain files that describe the installation, configuration,\nusage and license of a chart.\n\nA LICENSE is a plain text file containing the\n[license](https://en.wikipedia.org/wiki/Software_license) for the chart. The\nchart can contain a license as it may have programming logic in the templates\nand would therefore not be configuration only. There can also be separate\nlicense(s) for the application installed by the chart, if required.\n\nA README for a chart should be formatted in Markdown (README.md), and should\ngenerally contain:\n\n- A description of the application or service the chart provides\n- Any prerequisites or requirements to run the chart\n- Descriptions of options in `values.yaml` and default values\n- Any other information that may be relevant to the installation or\n  configuration of the chart\n\nWhen hubs and other user interfaces display details about a chart that detail is\npulled from the content in the `README.md` file.\n\nThe chart can also contain a short plain text `templates/NOTES.txt` file that\nwill be printed out after installation, and when viewing the status of a\nrelease. This file is evaluated as a [template](#templates-and-values), and can\nbe used to display usage notes, next steps, or any other information relevant to\na release of the chart. For example, instructions could be provided for\nconnecting to a database, or accessing a web UI. Since this file is printed to\nSTDOUT when running `helm install` or `helm status`, it is recommended to keep\nthe content brief and point to the README for greater detail.\n\n## Chart Dependencies\n\nIn Helm, one chart may depend on any number of other charts. These dependencies\ncan be dynamically linked using the `dependencies` field in `Chart.yaml` or\nbrought in to the `charts/` directory and managed manually.\n\n### Managing Dependencies with the `dependencies` field\n\nThe charts required by the current chart are defined as a list in the\n`dependencies` field.\n\n```yaml\ndependencies:\n  - name: apache\n    version: 1.2.3\n    repository: https://example.com/charts\n  - name: mysql\n    version: 3.2.1\n    repository: https://another.example.com/charts\n```\n\n- The `name` field is the name of the chart you want.\n- The `version` field is the version of the chart you want.\n- The `repository` field is the full URL to the chart repository. Note that you\n  must also use `helm repo add` to add that repo locally.\n- You might use the name of the repo instead of URL\n\n```console\n$ helm repo add fantastic-charts https://charts.helm.sh/incubator\n```\n\n```yaml\ndependencies:\n  - name: awesomeness\n    version: 1.0.0\n    repository: \"@fantastic-charts\"\n```\n\nOnce you have defined dependencies, you can run `helm dependency update` and it\nwill use your dependency file to download all the specified charts into your\n`charts/` directory for you.\n\n```console\n$ helm dep up foochart\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"local\" chart repository\n...Successfully got an update from the \"stable\" chart repository\n...Successfully got an update from the \"example\" chart repository\n...Successfully got an update from the \"another\" chart repository\nUpdate Complete. Happy Helming!\nSaving 2 charts\nDownloading apache from repo https://example.com/charts\nDownloading mysql from repo https://another.example.com/charts\n```\n\nWhen `helm dependency update` retrieves charts, it will store them as chart\narchives in the `charts/` directory. So for the example above, one would expect\nto see the following files in the charts directory:\n\n```text\ncharts/\n  apache-1.2.3.tgz\n  mysql-3.2.1.tgz\n```\n\n#### Alias field in dependencies\n\nIn addition to the other fields above, each requirements entry may contain the\noptional field `alias`.\n\nAdding an alias for a dependency chart would put a chart in dependencies using\nalias as name of new dependency.\n\nOne can use `alias` in cases where they need to access a chart with other\nname(s).\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-1\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    alias: new-subchart-2\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n```\n\nIn the above example we will get 3 dependencies in all for `parentchart`:\n\n```text\nsubchart\nnew-subchart-1\nnew-subchart-2\n```\n\nThe manual way of achieving this is by copy/pasting the same chart in the\n`charts/` directory multiple times with different names.\n\n#### Tags and Condition fields in dependencies\n\nIn addition to the other fields above, each requirements entry may contain the\noptional fields `tags` and `condition`.\n\nAll charts are loaded by default. If `tags` or `condition` fields are present,\nthey will be evaluated and used to control loading for the chart(s) they are\napplied to.\n\nCondition - The condition field holds one or more YAML paths (delimited by\ncommas). If this path exists in the top parent's values and resolves to a\nboolean value, the chart will be enabled or disabled based on that boolean\nvalue.  Only the first valid path found in the list is evaluated and if no paths\nexist then the condition has no effect.\n\nTags - The tags field is a YAML list of labels to associate with this chart. In\nthe top parent's values, all charts with tags can be enabled or disabled by\nspecifying the tag and a boolean value.\n\n```yaml\n# parentchart/Chart.yaml\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart1.enabled,global.subchart1.enabled\n    tags:\n      - front-end\n      - subchart1\n  - name: subchart2\n    repository: http://localhost:10191\n    version: 0.1.0\n    condition: subchart2.enabled,global.subchart2.enabled\n    tags:\n      - back-end\n      - subchart2\n```\n\n```yaml\n# parentchart/values.yaml\n\nsubchart1:\n  enabled: true\ntags:\n  front-end: false\n  back-end: true\n```\n\nIn the above example all charts with the tag `front-end` would be disabled but\nsince the `subchart1.enabled` path evaluates to 'true' in the parent's values,\nthe condition will override the `front-end` tag and `subchart1` will be enabled.\n\nSince `subchart2` is tagged with `back-end` and that tag evaluates to `true`,\n`subchart2` will be enabled. Also note that although `subchart2` has a condition\nspecified, there is no corresponding path and value in the parent's values so\nthat condition has no effect.\n\n##### Using the CLI with Tags and Conditions\n\nThe `--set` parameter can be used as usual to alter tag and condition values.\n\n```console\nhelm install --set tags.front-end=true --set subchart2.enabled=false\n```\n\n##### Tags and Condition Resolution\n\n- **Conditions (when set in values) always override tags.** The first condition\n  path that exists wins and subsequent ones for that chart are ignored.\n- Tags are evaluated as 'if any of the chart's tags are true then enable the\n  chart'.\n- Tags and conditions values must be set in the top parent's values.\n- The `tags:` key in values must be a top level key. Globals and nested `tags:`\n  tables are not currently supported.\n\n#### Importing Child Values via dependencies\n\nIn some cases it is desirable to allow a child chart's values to propagate to\nthe parent chart and be shared as common defaults. An additional benefit of\nusing the `exports` format is that it will enable future tooling to introspect\nuser-settable values.\n\nThe keys containing the values to be imported can be specified in the parent\nchart's `dependencies` in the field `import-values` using a YAML list. Each item\nin the list is a key which is imported from the child chart's `exports` field.\n\nTo import values not contained in the `exports` key, use the\n[child-parent](#using-the-child-parent-format) format. Examples of both formats\nare described below.\n\n##### Using the exports format\n\nIf a child chart's `values.yaml` file contains an `exports` field at the root,\nits contents may be imported directly into the parent's values by specifying the\nkeys to import as in the example below:\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart\n    repository: http://localhost:10191\n    version: 0.1.0\n    import-values:\n      - data\n```\n\n```yaml\n# child's values.yaml file\n\nexports:\n  data:\n    myint: 99\n```\n\nSince we are specifying the key `data` in our import list, Helm looks in the\n`exports` field of the child chart for `data` key and imports its contents.\n\nThe final parent values would contain our exported field:\n\n```yaml\n# parent's values\n\nmyint: 99\n```\n\nPlease note the parent key `data` is not contained in the parent's final values.\nIf you need to specify the parent key, use the 'child-parent' format.\n\n##### Using the child-parent format\n\nTo access values that are not contained in the `exports` key of the child\nchart's values, you will need to specify the source key of the values to be\nimported (`child`) and the destination path in the parent chart's values\n(`parent`).\n\nThe `import-values` in the example below instructs Helm to take any values found\nat `child:` path and copy them to the parent's values at the path specified in\n`parent:`\n\n```yaml\n# parent's Chart.yaml file\n\ndependencies:\n  - name: subchart1\n    repository: http://localhost:10191\n    version: 0.1.0\n    ...\n    import-values:\n      - child: default.data\n        parent: myimports\n```\n\nIn the above example, values found at `default.data` in the subchart1's values\nwill be imported to the `myimports` key in the parent chart's values as detailed\nbelow:\n\n```yaml\n# parent's values.yaml file\n\nmyimports:\n  myint: 0\n  mybool: false\n  mystring: \"helm rocks!\"\n```\n\n```yaml\n# subchart1's values.yaml file\n\ndefault:\n  data:\n    myint: 999\n    mybool: true\n```\n\nThe parent chart's resulting values would be:\n\n```yaml\n# parent's final values\n\nmyimports:\n  myint: 999\n  mybool: true\n  mystring: \"helm rocks!\"\n```\n\nThe parent's final values now contains the `myint` and `mybool` fields imported\nfrom subchart1.\n\n### Managing Dependencies manually via the `charts/` directory\n\nIf more control over dependencies is desired, these dependencies can be\nexpressed explicitly by copying the dependency charts into the `charts/`\ndirectory.\n\nA dependency should be an unpacked chart directory but its name cannot start \nwith `_` or `.`. Such files are ignored by the chart loader.\n\nFor example, if the WordPress chart depends on the Apache chart, the Apache\nchart (of the correct version) is supplied in the WordPress chart's `charts/`\ndirectory:\n\n```yaml\nwordpress:\n  Chart.yaml\n  # ...\n  charts/\n    apache/\n      Chart.yaml\n      # ...\n    mysql/\n      Chart.yaml\n      # ...\n```\n\nThe example above shows how the WordPress chart expresses its dependency on\nApache and MySQL by including those charts inside of its `charts/` directory.\n\n**TIP:** _To drop a dependency into your `charts/` directory, use the `helm\npull` command_\n\n### Operational aspects of using dependencies\n\nThe above sections explain how to specify chart dependencies, but how does this\naffect chart installation using `helm install` and `helm upgrade`?\n\nSuppose that a chart named \"A\" creates the following Kubernetes objects\n\n- namespace \"A-Namespace\"\n- statefulset \"A-StatefulSet\"\n- service \"A-Service\"\n\nFurthermore, A is dependent on chart B that creates objects\n\n- namespace \"B-Namespace\"\n- replicaset \"B-ReplicaSet\"\n- service \"B-Service\"\n\nAfter installation/upgrade of chart A a single Helm release is created/modified.\nThe release will create/update all of the above Kubernetes objects in the\nfollowing order:\n\n- A-Namespace\n- B-Namespace\n- A-Service\n- B-Service\n- B-ReplicaSet\n- A-StatefulSet\n\nThis is because when Helm installs/upgrades charts, the Kubernetes objects from\nthe charts and all its dependencies are\n\n- aggregated into a single set; then\n- sorted by type followed by name; and then\n- created/updated in that order.\n\nHence a single release is created with all the objects for the chart and its\ndependencies.\n\nThe install order of Kubernetes types is given by the enumeration InstallOrder\nin kind_sorter.go (see [the Helm source\nfile](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)).\n\n## Templates and Values\n\nHelm Chart templates are written in the [Go template\nlanguage](https://golang.org/pkg/text/template/), with the addition of 50 or so\nadd-on template functions [from the Sprig\nlibrary](https://github.com/Masterminds/sprig) and a few other [specialized\nfunctions](/howto/charts_tips_and_tricks.md).\n\nAll template files are stored in a chart's `templates/` folder. When Helm\nrenders the charts, it will pass every file in that directory through the\ntemplate engine.\n\nValues for the templates are supplied two ways:\n\n- Chart developers may supply a file called `values.yaml` inside of a chart.\n  This file can contain default values.\n- Chart users may supply a YAML file that contains values. This can be provided\n  on the command line with `helm install`.\n\nWhen a user supplies custom values, these values will override the values in the\nchart's `values.yaml` file.\n\n### Template Files\n\nTemplate files follow the standard conventions for writing Go templates (see\n[the text/template Go package\ndocumentation](https://golang.org/pkg/text/template/) for details). An example\ntemplate file might look something like this:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\nThe above example, based loosely on\n[https://github.com/deis/charts](https://github.com/deis/charts), is a template\nfor a Kubernetes replication controller. It can use the following four template\nvalues (usually defined in a `values.yaml` file):\n\n- `imageRegistry`: The source registry for the Docker image.\n- `dockerTag`: The tag for the docker image.\n- `pullPolicy`: The Kubernetes pull policy.\n- `storage`: The storage backend, whose default is set to `\"minio\"`\n\nAll of these values are defined by the template author. Helm does not require or\ndictate parameters.\n\nTo see many working charts, check out the CNCF [Artifact\nHub](https://artifacthub.io/packages/search?kind=0).\n\n### Predefined Values\n\nValues that are supplied via a `values.yaml` file (or via the `--set` flag) are\naccessible from the `.Values` object in a template. But there are other\npre-defined pieces of data you can access in your templates.\n\nThe following values are pre-defined, are available to every template, and\ncannot be overridden. As with all values, the names are _case sensitive_.\n\n- `Release.Name`: The name of the release (not the chart)\n- `Release.Namespace`: The namespace the chart was released to.\n- `Release.Service`: The service that conducted the release.\n- `Release.IsUpgrade`: This is set to true if the current operation is an\n  upgrade or rollback.\n- `Release.IsInstall`: This is set to true if the current operation is an\n  install.\n- `Chart`: The contents of the `Chart.yaml`. Thus, the chart version is\n  obtainable as `Chart.Version` and the maintainers are in `Chart.Maintainers`.\n- `Files`: A map-like object containing all non-special files in the chart. This\n  will not give you access to templates, but will give you access to additional\n  files that are present (unless they are excluded using `.helmignore`). Files\n  can be accessed using `{{ index .Files \"file.name\" }}` or using the\n  `{{.Files.Get name }}` function. You can also access the contents of the file\n  as `[]byte` using `{{ .Files.GetBytes }}`\n- `Capabilities`: A map-like object that contains information about the versions\n  of Kubernetes (`{{ .Capabilities.KubeVersion }}`) and the supported Kubernetes\n  API versions (`{{ .Capabilities.APIVersions.Has \"batch/v1\" }}`)\n\n**NOTE:** Any unknown `Chart.yaml` fields will be dropped. They will not be\naccessible inside of the `Chart` object. Thus, `Chart.yaml` cannot be used to\npass arbitrarily structured data into the template. The values file can be used\nfor that, though.\n\n### Values files\n\nConsidering the template in the previous section, a `values.yaml` file that\nsupplies the necessary values would look like this:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"s3\"\n```\n\nA values file is formatted in YAML. A chart may include a default `values.yaml`\nfile. The Helm install command allows a user to override values by supplying\nadditional YAML values:\n\n```console\n$ helm install --generate-name --values=myvals.yaml wordpress\n```\n\nWhen values are passed in this way, they will be merged into the default values\nfile. For example, consider a `myvals.yaml` file that looks like this:\n\n```yaml\nstorage: \"gcs\"\n```\n\nWhen this is merged with the `values.yaml` in the chart, the resulting generated\ncontent will be:\n\n```yaml\nimageRegistry: \"quay.io/deis\"\ndockerTag: \"latest\"\npullPolicy: \"Always\"\nstorage: \"gcs\"\n```\n\nNote that only the last field was overridden.\n\n**NOTE:** The default values file included inside of a chart _must_ be named\n`values.yaml`. But files specified on the command line can be named anything.\n\n**NOTE:** If the `--set` flag is used on `helm install` or `helm upgrade`, those\nvalues are simply converted to YAML on the client side.\n\n**NOTE:** If any required entries in the values file exist, they can be declared\nas required in the chart template by using the ['required' function](/howto/charts_tips_and_tricks.md)\n\nAny of these values are then accessible inside of templates using the `.Values`\nobject:\n\n```yaml\napiVersion: v1\nkind: ReplicationController\nmetadata:\n  name: deis-database\n  namespace: deis\n  labels:\n    app.kubernetes.io/managed-by: deis\nspec:\n  replicas: 1\n  selector:\n    app.kubernetes.io/name: deis-database\n  template:\n    metadata:\n      labels:\n        app.kubernetes.io/name: deis-database\n    spec:\n      serviceAccount: deis-database\n      containers:\n        - name: deis-database\n          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}\n          imagePullPolicy: {{ .Values.pullPolicy }}\n          ports:\n            - containerPort: 5432\n          env:\n            - name: DATABASE_STORAGE\n              value: {{ default \"minio\" .Values.storage }}\n```\n\n### Scope, Dependencies, and Values\n\nValues files can declare values for the top-level chart, as well as for any of\nthe charts that are included in that chart's `charts/` directory. Or, to phrase\nit differently, a values file can supply values to the chart as well as to any\nof its dependencies. For example, the demonstration WordPress chart above has\nboth `mysql` and `apache` as dependencies. The values file could supply values\nto all of these components:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nCharts at a higher level have access to all of the variables defined beneath. So\nthe WordPress chart can access the MySQL password as `.Values.mysql.password`.\nBut lower level charts cannot access things in parent charts, so MySQL will not\nbe able to access the `title` property. Nor, for that matter, can it access\n`apache.port`.\n\nValues are namespaced, but namespaces are pruned. So for the WordPress chart, it\ncan access the MySQL password field as `.Values.mysql.password`. But for the\nMySQL chart, the scope of the values has been reduced and the namespace prefix\nremoved, so it will see the password field simply as `.Values.password`.\n\n#### Global Values\n\nAs of 2.0.0-Alpha.2, Helm supports special \"global\" value. Consider this\nmodified version of the previous example:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  port: 8080 # Passed to Apache\n```\n\nThe above adds a `global` section with the value `app: MyWordPress`. This value\nis available to _all_ charts as `.Values.global.app`.\n\nFor example, the `mysql` templates may access `app` as `{{\n.Values.global.app}}`, and so can the `apache` chart. Effectively, the values\nfile above is regenerated like this:\n\n```yaml\ntitle: \"My WordPress Site\" # Sent to the WordPress template\n\nglobal:\n  app: MyWordPress\n\nmysql:\n  global:\n    app: MyWordPress\n  max_connections: 100 # Sent to MySQL\n  password: \"secret\"\n\napache:\n  global:\n    app: MyWordPress\n  port: 8080 # Passed to Apache\n```\n\nThis provides a way of sharing one top-level variable with all subcharts, which\nis useful for things like setting `metadata` properties like labels.\n\nIf a subchart declares a global variable, that global will be passed _downward_\n(to the subchart's subcharts), but not _upward_ to the parent chart. There is no\nway for a subchart to influence the values of the parent chart.\n\nAlso, global variables of parent charts take precedence over the global\nvariables from subcharts.\n\n### Schema Files\n\nSometimes, a chart maintainer might want to define a structure on their values.\nThis can be done by defining a schema in the `values.schema.json` file. A schema\nis represented as a [JSON Schema](https://json-schema.org/). It might look\nsomething like this:\n\n```json\n{\n  \"$schema\": \"https://json-schema.org/draft-07/schema#\",\n  \"properties\": {\n    \"image\": {\n      \"description\": \"Container Image\",\n      \"properties\": {\n        \"repo\": {\n          \"type\": \"string\"\n        },\n        \"tag\": {\n          \"type\": \"string\"\n        }\n      },\n      \"type\": \"object\"\n    },\n    \"name\": {\n      \"description\": \"Service name\",\n      \"type\": \"string\"\n    },\n    \"port\": {\n      \"description\": \"Port\",\n      \"minimum\": 0,\n      \"type\": \"integer\"\n    },\n    \"protocol\": {\n      \"type\": \"string\"\n    }\n  },\n  \"required\": [\n    \"protocol\",\n    \"port\"\n  ],\n  \"title\": \"Values\",\n  \"type\": \"object\"\n}\n```\n\nThis schema will be applied to the values to validate it. Validation occurs when\nany of the following commands are invoked:\n\n- `helm install`\n- `helm upgrade`\n- `helm lint`\n- `helm template`\n\nAn example of a `values.yaml` file that meets the requirements of this schema\nmight look something like this:\n\n```yaml\nname: frontend\nprotocol: https\nport: 443\n```\n\nNote that the schema is applied to the final `.Values` object, and not just to\nthe `values.yaml` file. This means that the following `yaml` file is valid,\ngiven that the chart is installed with the appropriate `--set` option shown\nbelow.\n\n```yaml\nname: frontend\nprotocol: https\n```\n\n```console\nhelm install --set port=443\n```\n\nFurthermore, the final `.Values` object is checked against *all* subchart\nschemas. This means that restrictions on a subchart can't be circumvented by a\nparent chart. This also works backwards - if a subchart has a requirement that\nis not met in the subchart's `values.yaml` file, the parent chart *must* satisfy\nthose restrictions in order to be valid.\n\nSchema validation can be disabled by setting the option shown below.\nThis is particularly useful in air-gapped environments when a chart's JSON Schema file contains remote references.\n```console\nhelm install --skip-schema-validation\n```\n\n### References\n\nWhen it comes to writing templates, values, and schema files, there are several\nstandard references that will help you out.\n\n- [Go templates](https://godoc.org/text/template)\n- [Extra template functions](https://godoc.org/github.com/Masterminds/sprig)\n- [The YAML format](https://yaml.org/spec/)\n- [JSON Schema](https://json-schema.org/)\n\n## Custom Resource Definitions (CRDs)\n\nKubernetes provides a mechanism for declaring new types of Kubernetes objects.\nUsing CustomResourceDefinitions (CRDs), Kubernetes developers can declare custom\nresource types.\n\nIn Helm 3, CRDs are treated as a special kind of object. They are installed\nbefore the rest of the chart, and are subject to some limitations.\n\nCRD YAML files should be placed in the `crds/` directory inside of a chart.\nMultiple CRDs (separated by YAML start and end markers) may be placed in the\nsame file. Helm will attempt to load _all_ of the files in the CRD directory\ninto Kubernetes.\n\nCRD files _cannot be templated_. They must be plain YAML documents.\n\nWhen Helm installs a new chart, it will upload the CRDs, pause until the CRDs\nare made available by the API server, and then start the template engine, render\nthe rest of the chart, and upload it to Kubernetes. Because of this ordering,\nCRD information is available in the `.Capabilities` object in Helm templates,\nand Helm templates may create new instances of objects that were declared in\nCRDs.\n\nFor example, if your chart had a CRD for `CronTab` in the `crds/` directory, you\nmay create instances of the `CronTab` kind in the `templates/` directory:\n\n```text\ncrontabs/\n  Chart.yaml\n  crds/\n    crontab.yaml\n  templates/\n    mycrontab.yaml\n```\n\nThe `crontab.yaml` file must contain the CRD with no template directives:\n\n```yaml\nkind: CustomResourceDefinition\nmetadata:\n  name: crontabs.stable.example.com\nspec:\n  group: stable.example.com\n  versions:\n    - name: v1\n      served: true\n      storage: true\n  scope: Namespaced\n  names:\n    plural: crontabs\n    singular: crontab\n    kind: CronTab\n```\n\nThen the template `mycrontab.yaml` may create a new `CronTab` (using templates\nas usual):\n\n```yaml\napiVersion: stable.example.com\nkind: CronTab\nmetadata:\n  name: {{ .Values.name }}\nspec:\n   # ...\n```\n\nHelm will make sure that the `CronTab` kind has been installed and is available\nfrom the Kubernetes API server before it proceeds installing the things in\n`templates/`.\n\n### Limitations on CRDs\n\nUnlike most objects in Kubernetes, CRDs are installed globally. For that reason,\nHelm takes a very cautious approach in managing CRDs. CRDs are subject to the\nfollowing limitations:\n\n- CRDs are never reinstalled. If Helm determines that the CRDs in the `crds/`\n  directory are already present (regardless of version), Helm will not attempt\n  to install or upgrade.\n- CRDs are never installed on upgrade or rollback. Helm will only create CRDs on\n  installation operations.\n- CRDs are never deleted. Deleting a CRD automatically deletes all of the CRD's\n  contents across all namespaces in the cluster. Consequently, Helm will not\n  delete CRDs.\n\nOperators who want to upgrade or delete CRDs are encouraged to do this manually\nand with great care.\n\n## Using Helm to Manage Charts\n\nThe `helm` tool has several commands for working with charts.\n\nIt can create a new chart for you:\n\n```console\n$ helm create mychart\nCreated mychart/\n```\n\nOnce you have edited a chart, `helm` can package it into a chart archive for\nyou:\n\n```console\n$ helm package mychart\nArchived mychart-0.1.-.tgz\n```\n\nYou can also use `helm` to help you find issues with your chart's formatting or\ninformation:\n\n```console\n$ helm lint mychart\nNo issues found\n```\n\n## Chart Repositories\n\nA _chart repository_ is an HTTP server that houses one or more packaged charts.\nWhile `helm` can be used to manage local chart directories, when it comes to\nsharing charts, the preferred mechanism is a chart repository.\n\nAny HTTP server that can serve YAML files and tar files and can answer GET\nrequests can be used as a repository server. The Helm team has tested some\nservers, including Google Cloud Storage with website mode enabled, and S3 with\nwebsite mode enabled.\n\nA repository is characterized primarily by the presence of a special file called\n`index.yaml` that has a list of all of the packages supplied by the repository,\ntogether with metadata that allows retrieving and verifying those packages.\n\nOn the client side, repositories are managed with the `helm repo` commands.\nHowever, Helm does not provide tools for uploading charts to remote repository\nservers. This is because doing so would add substantial requirements to an\nimplementing server, and thus raise the barrier for setting up a repository.\n\n## Chart Starter Packs\n\nThe `helm create` command takes an optional `--starter` option that lets you\nspecify a \"starter chart\". Also, the starter option has a short alias `-p`.\n\nExamples of usage:\n\n```console\nhelm create my-chart --starter starter-name\nhelm create my-chart -p starter-name\nhelm create my-chart -p /absolute/path/to/starter-name\n```\n\nStarters are just regular charts, but are located in\n`$XDG_DATA_HOME/helm/starters`. As a chart developer, you may author charts that\nare specifically designed to be used as starters. Such charts should be designed\nwith the following considerations in mind:\n\n- The `Chart.yaml` will be overwritten by the generator.\n- Users will expect to modify such a chart's contents, so documentation should\n  indicate how users can do so.\n- All occurrences of `<CHARTNAME>` 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, `<CHARTNAME>` will NOT override inside them. Additionally, the chart description is not inherited.\n\nCurrently the only way to add a chart to `$XDG_DATA_HOME/helm/starters` is to\nmanually copy it there. In your chart's documentation, you may want to explain\nthat process.\n"
  },
  {
    "path": "versioned_docs/version-3/topics/charts_hooks.md",
    "content": "---\ntitle: Chart Hooks\ndescription: Describes how to work with chart hooks.\nsidebar_position: 2\n---\n\nHelm provides a _hook_ mechanism to allow chart developers to intervene at\ncertain points in a release's life cycle. For example, you can use hooks to:\n\n- Load a ConfigMap or Secret during install before any other charts are loaded.\n- Execute a Job to back up a database before installing a new chart, and then\n  execute a second job after the upgrade in order to restore data.\n- Run a Job before deleting a release to gracefully take a service out of\n  rotation before removing it.\n\nHooks work like regular templates, but they have special annotations that cause\nHelm to utilize them differently. In this section, we cover the basic usage\npattern for hooks.\n\n## The Available Hooks\n\nThe following hooks are defined:\n\n| Annotation Value | Description                                                                                           |\n| ---------------- | ----------------------------------------------------------------------------------------------------- |\n| `pre-install`    | Executes after templates are rendered, but before any resources are created in Kubernetes             |\n| `post-install`   | Executes after all resources are loaded into Kubernetes                                               |\n| `pre-delete`     | Executes on a deletion request before any resources are deleted from Kubernetes                       |\n| `post-delete`    | Executes on a deletion request after all of the release's resources have been deleted                 |\n| `pre-upgrade`    | Executes on an upgrade request after templates are rendered, but before any resources are updated     |\n| `post-upgrade`   | Executes on an upgrade request after all resources have been upgraded                                 |\n| `pre-rollback`   | Executes on a rollback request after templates are rendered, but before any resources are rolled back |\n| `post-rollback`  | Executes on a rollback request after all resources have been modified                                 |\n| `test`           | Executes when the Helm test subcommand is invoked ([view test docs](/topics/chart_tests.md))              |\n\n_Note that the `crd-install` hook has been removed in favor of the `crds/`\ndirectory in Helm 3._\n\n## Hooks and the Release Lifecycle\n\nHooks allow you, the chart developer, an opportunity to perform operations at\nstrategic points in a release lifecycle. For example, consider the lifecycle for\na `helm install`. By default, the lifecycle looks like this:\n\n1. User runs `helm install foo`\n2. The Helm library install API is called\n3. After some verification, the library renders the `foo` templates\n4. The library loads the resulting resources into Kubernetes\n5. The library returns the release object (and other data) to the client\n6. The client exits\n\nHelm defines two hooks for the `install` lifecycle: `pre-install` and\n`post-install`. If the developer of the `foo` chart implements both hooks, the\nlifecycle is altered like this:\n\n1. User runs `helm install foo`\n2. The Helm library install API is called\n3. CRDs in the `crds/` directory are installed\n4. After some verification, the library renders the `foo` templates\n5. The library prepares to execute the `pre-install` hooks (loading hook\n   resources into Kubernetes)\n6. The library sorts hooks by weight (assigning a weight of 0 by default), \n   by resource kind and finally by name in ascending order.\n7. The library then loads the hook with the lowest weight first (negative to\n   positive)\n8. The library waits until the hook is \"Ready\" (except for CRDs)\n9. The library loads the resulting resources into Kubernetes. Note that if the\n   `--wait` flag is set, the library will wait until all resources are in a\n   ready state and will not run the `post-install` hook until they are ready.\n10. The library executes the `post-install` hook (loading hook resources)\n11. The library waits until the hook is \"Ready\"\n12. The library returns the release object (and other data) to the client\n13. The client exits\n\nWhat does it mean to wait until a hook is ready? This depends on the resource\ndeclared in the hook. If the resource is a `Job` or `Pod` kind, Helm will wait\nuntil it successfully runs to completion. And if the hook fails, the release\nwill fail. This is a _blocking operation_, so the Helm client will pause while\nthe Job is run.\n\nFor all other kinds, as soon as Kubernetes marks the resource as loaded (added\nor updated), the resource is considered \"Ready\". When many resources are\ndeclared in a hook, the resources are executed serially. If they have hook\nweights (see below), they are executed in weighted order. \nStarting from Helm 3.2.0 hook resources with same weight are installed in the same \norder as normal non-hook resources. Otherwise, ordering is\nnot guaranteed. (In Helm 2.3.0 and after, they are sorted alphabetically. That\nbehavior, though, is not considered binding and could change in the future.) It\nis considered good practice to add a hook weight, and set it to `0` if weight is\nnot important.\n\n### Hook resources are not managed with corresponding releases\n\nThe resources that a hook creates are currently not tracked or managed as part\nof the release. Once Helm verifies that the hook has reached its ready state, it\nwill leave the hook resource alone. Garbage collection of hook resources when\nthe corresponding release is deleted may be added to Helm 3 in the future, so\nany hook resources that must never be deleted should be annotated with\n`helm.sh/resource-policy: keep`.\n\nPractically speaking, this means that if you create resources in a hook, you\ncannot rely upon `helm uninstall` to remove the resources. To destroy such\nresources, you need to either [add a custom `helm.sh/hook-delete-policy`\nannotation](#hook-deletion-policies) to the hook template file, or [set the time\nto live (TTL) field of a Job\nresource](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/).\n\n## Writing a Hook\n\nHooks are just Kubernetes manifest files with special annotations in the\n`metadata` section. Because they are template files, you can use all of the\nnormal template features, including reading `.Values`, `.Release`, and\n`.Template`.\n\nFor example, this template, stored in `templates/post-install-job.yaml`,\ndeclares a job to be run on `post-install`:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n  name: \"{{ .Release.Name }}\"\n  labels:\n    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n    app.kubernetes.io/instance: {{ .Release.Name | quote }}\n    app.kubernetes.io/version: {{ .Chart.AppVersion }}\n    helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n  annotations:\n    # This is what defines this resource as a hook. Without this line, the\n    # job is considered part of the release.\n    \"helm.sh/hook\": post-install\n    \"helm.sh/hook-weight\": \"-5\"\n    \"helm.sh/hook-delete-policy\": hook-succeeded\nspec:\n  template:\n    metadata:\n      name: \"{{ .Release.Name }}\"\n      labels:\n        app.kubernetes.io/managed-by: {{ .Release.Service | quote }}\n        app.kubernetes.io/instance: {{ .Release.Name | quote }}\n        helm.sh/chart: \"{{ .Chart.Name }}-{{ .Chart.Version }}\"\n    spec:\n      restartPolicy: Never\n      containers:\n      - name: post-install-job\n        image: \"alpine:3.3\"\n        command: [\"/bin/sleep\",\"{{ default \"10\" .Values.sleepyTime }}\"]\n\n```\n\nWhat makes this template a hook is the annotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install\n```\n\nOne resource can implement multiple hooks:\n\n```yaml\nannotations:\n  \"helm.sh/hook\": post-install,post-upgrade\n```\n\nSimilarly, there is no limit to the number of different resources that may\nimplement a given hook. For example, one could declare both a secret and a\nconfig map as a pre-install hook.\n\nWhen subcharts declare hooks, those are also evaluated. There is no way for a\ntop-level chart to disable the hooks declared by subcharts.\n\nIt is possible to define a weight for a hook which will help build a\ndeterministic executing order. Weights are defined using the following\nannotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook-weight\": \"5\"\n```\n\nHook weights can be positive or negative numbers but must be represented as\nstrings. When Helm starts the execution cycle of hooks of a particular Kind it\nwill sort those hooks in ascending order.\n\n### Hook deletion policies\n\nIt is possible to define policies that determine when to delete corresponding\nhook resources. Hook deletion policies are defined using the following\nannotation:\n\n```yaml\nannotations:\n  \"helm.sh/hook-delete-policy\": before-hook-creation,hook-succeeded\n```\n\nYou can choose one or more defined annotation values:\n\n| Annotation Value       | Description                                                          |\n| ---------------------- | -------------------------------------------------------------------- |\n| `before-hook-creation` | Delete the previous resource before a new hook is launched (default) |\n| `hook-succeeded`       | Delete the resource after the hook is successfully executed          |\n| `hook-failed`          | Delete the resource if the hook failed during execution              |\n\nIf no hook deletion policy annotation is specified, the `before-hook-creation`\nbehavior applies by default.\n"
  },
  {
    "path": "versioned_docs/version-3/topics/index.mdx",
    "content": "---\ntitle: Topics\nsidebar_position: 3\n---\n\n# Topic Guides\n\nHere you’ll find introductions to all the key parts of Helm you’ll need or want\nto know.\n\n\nimport DocCardList from '@theme/DocCardList';\n\n<DocCardList />\n"
  },
  {
    "path": "versioned_docs/version-3/topics/kubernetes_apis.md",
    "content": "---\ntitle: Deprecated Kubernetes APIs\ndescription: Explains deprecated Kubernetes APIs in Helm\n---\n\nKubernetes is an API-driven system and the API evolves over time to reflect the\nevolving understanding of the problem space. This is common practice across\nsystems and their APIs. An important part of evolving APIs is a good deprecation\npolicy and process to inform users of how changes to APIs are implemented. In\nother words, consumers of your API need to know in advance and in what release\nan API will be removed or changed. This removes the element of surprise and\nbreaking changes to consumers.\n\nThe [Kubernetes deprecation\npolicy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\ndocuments how Kubernetes handles the changes to its API versions. The policy for\ndeprecation states the timeframe that API versions will be supported following a\ndeprecation announcement. It is therefore important to be aware of deprecation\nannouncements and know when API versions will be removed, to help minimize the\neffect.\n\nThis is an example of an announcement [for the removal of deprecated API\nversions in Kubernetes\n1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) and was\nadvertised a few months prior to the release. These API versions would have been\nannounced for deprecation prior to this again. This shows that there is a good\npolicy in place which informs consumers of API version support.\n\nHelm templates specify a [Kubernetes API\ngroup](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)\nwhen defining a Kubernetes object, similar to a Kubernetes manifest file. It is\nspecified in the `apiVersion` field of the template and it identifies the API\nversion of the Kubernetes object. This means that Helm users and chart\nmaintainers need to be aware when Kubernetes API versions have been deprecated\nand in what Kubernetes version they will be removed.\n\n## Chart Maintainers\n\nYou should audit your charts checking for Kubernetes API versions that are\ndeprecated or are removed in a Kubernetes version. The API versions found as due\nto be or that are now out of support, should be updated to the supported version\nand a new version of the chart released. The API version is defined by the\n`kind` and `apiVersion` fields. For example, here is a removed `Deployment`\nobject API version in Kubernetes 1.16:\n\n```yaml\napiVersion: apps/v1beta1\nkind: Deployment\n```\n\n## Helm Users\n\nYou should audit the charts that you use (similar to [chart\nmaintainers](#chart-maintainers)) and identify any charts where API versions are\ndeprecated or removed in a Kubernetes version. For the charts identified, you\nneed to check for the latest version of the chart (which has supported API\nversions) or update the chart yourself.\n\nAdditionally, you also need to audit any charts deployed (i.e. Helm releases)\nchecking again for any deprecated or removed API versions. This can be done by\ngetting details of a release using the `helm get manifest` command.\n\nThe means for updating a Helm release to supported APIs depends on your findings\nas follows:\n\n1. If you find deprecated API versions only then:\n  - Perform a `helm upgrade` with a version of the chart with supported\n    Kubernetes API versions\n  - Add a description in the upgrade, something along the lines to not perform a\n    rollback to a Helm version prior to this current version\n2.  If you find any API version(s) that is/are removed in a Kubernetes version\n    then:\n  - If you are running a Kubernetes version where the API version(s) are still\n    available (for example, you are on Kubernetes 1.15 and found you use APIs\n    that will be removed in Kubernetes 1.16):\n    - Follow the step 1 procedure\n  - Otherwise (for example, you are already running a Kubernetes version where\n    some API versions reported by `helm get manifest` are no longer available):\n    - You need to edit the release manifest that is stored in the cluster to\n      update the API versions to supported APIs. See [Updating API Versions of a\n      Release Manifest](#updating-api-versions-of-a-release-manifest) for more\n      details\n\n> Note: In all cases of updating a Helm release with supported APIs, you should\nnever rollback the release to a version prior to the release version with the\nsupported APIs.\n\n> Recommendation: The best practice is to upgrade releases using deprecated API\nversions to supported API versions, prior to upgrading to a kubernetes cluster\nthat removes those API versions.\n\nIf you don't update a release as suggested previously, you will have an error\nsimilar to the following when trying to upgrade a release in a Kubernetes\nversion where its API version(s) is/are removed:\n\n```\nError: UPGRADE FAILED: current release manifest contains removed kubernetes api(s)\nfor this kubernetes version and it is therefore unable to build the kubernetes\nobjects for performing the diff. error from kubernetes: unable to recognize \"\":\nno matches for kind \"Deployment\" in version \"apps/v1beta1\"\n```\n\nHelm fails in this scenario because it attempts to create a diff patch between\nthe current deployed release (which contains the Kubernetes APIs that are\nremoved in this Kubernetes version) against the chart you are passing with the\nupdated/supported API versions. The underlying reason for failure is that when\nKubernetes removes an API version, the Kubernetes Go client library can no\nlonger parse the deprecated objects and Helm therefore fails when calling the\nlibrary. Helm unfortunately is unable to recover from this situation and is no\nlonger able to manage such a release. See [Updating API Versions of a Release\nManifest](#updating-api-versions-of-a-release-manifest) for more details on how\nto recover from this scenario.\n\n## Updating API Versions of a Release Manifest\n\nThe manifest is a property of the Helm release object which is stored in the\ndata field of a Secret (default) or ConfigMap in the cluster. The data field\ncontains a gzipped object which is base 64 encoded (there is an additional base\n64 encoding for a Secret). There is a Secret/ConfigMap per release\nversion/revision in the namespace of the release.\n\nYou can use the Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis)\nplugin to perform the update of a release to supported APIs. Check out the\nreadme for more details.\n\nAlternatively, you can follow these manual steps to perform an update of the API\nversions of a release manifest. Depending on your configuration you will follow\nthe steps for the Secret or ConfigMap backend.\n\n- Get the name of the Secret or Configmap associated with the latest deployed\n  release:\n  - Secrets backend: `kubectl get secret -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n  - ConfigMap backend: `kubectl get configmap -l\n    owner=helm,status=deployed,name=<release_name> --namespace\n    <release_namespace> | awk '{print $1}' | grep -v NAME`\n- Get latest deployed release details:\n  - Secrets backend: `kubectl get secret <release_secret_name> -n\n    <release_namespace> -o yaml > release.yaml`\n  - ConfigMap backend: `kubectl get configmap <release_configmap_name> -n\n    <release_namespace> -o yaml > release.yaml`\n- Backup the release in case you need to restore if something goes wrong:\n  - `cp release.yaml release.bak`\n  - In case of emergency, restore: `kubectl apply -f release.bak -n\n    <release_namespace>`\n- Decode the release object:\n  - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d\n    | base64 -d | gzip -d > release.data.decoded`\n  - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64\n    -d | gzip -d > release.data.decoded`\n- Change API versions of the manifests. Can use any tool (e.g. editor) to make\n  the changes. This is in the `manifest` field of your decoded release object\n  (`release.data.decoded`)\n- Encode the release object:\n  - Secrets backend: `cat release.data.decoded | gzip | base64 | base64`\n  - ConfigMap backend: `cat release.data.decoded | gzip | base64`\n- Replace `data.release` property value in the deployed release file\n  (`release.yaml`) with the new encoded release object\n- Apply file to namespace: `kubectl apply -f release.yaml -n\n  <release_namespace>`\n- Perform a `helm upgrade` with a version of the chart with supported Kubernetes\n  API versions\n- Add a description in the upgrade, something along the lines to not perform a\n  rollback to a Helm version prior to this current version\n"
  },
  {
    "path": "versioned_docs/version-3/topics/kubernetes_distros.md",
    "content": "---\ntitle: Kubernetes Distribution Guide\ndescription: Captures information about using Helm in specific Kubernetes environments.\nsidebar_position: 10\n---\n\nHelm should work with any [conformant version of\nKubernetes](https://github.com/cncf/k8s-conformance) (whether\n[certified](https://www.cncf.io/certification/software-conformance/) or not).\n\nThis document captures information about using Helm in specific Kubernetes\nenvironments. Please contribute more details about any distros (sorted\nalphabetically) if desired.\n\n\n## AKS\n\nHelm works with [Azure Kubernetes\nService](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm).\n\n## DC/OS\n\nHelm has been tested and is working on Mesospheres DC/OS 1.11 Kubernetes\nplatform, and requires no additional configuration.\n\n## EKS\n\nHelm works with Amazon Elastic Kubernetes Service (Amazon EKS):\n[Using Helm with Amazon\nEKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html).\n\n## GKE\n\nGoogle's GKE hosted Kubernetes platform is known to work with Helm, and requires\nno additional configuration.\n\n## `scripts/local-cluster` and Hyperkube\n\nHyperkube configured via `scripts/local-cluster.sh` is known to work. For raw\nHyperkube you may need to do some manual configuration.\n\n## IKS\n\nHelm works with [IBM Cloud Kubernetes\nService](https://cloud.ibm.com/docs/containers?topic=containers-helm).\n\n## KIND (Kubernetes IN Docker)\n\nHelm is regularly tested on [KIND](https://github.com/kubernetes-sigs/kind).\n\n## KubeOne\n\nHelm works in clusters that are set up by KubeOne without caveats.\n\n## Kubermatic\n\nHelm works in user clusters that are created by Kubermatic without caveats.\nSince seed cluster can be set up in different ways Helm support depends on their\nconfiguration.\n\n## MicroK8s\n\nHelm can be enabled in [MicroK8s](https://microk8s.io) using the command:\n`microk8s.enable helm3`\n\n## Minikube\n\nHelm is tested and known to work with\n[Minikube](https://github.com/kubernetes/minikube). It requires no additional\nconfiguration.\n\n## Openshift\n\nHelm works straightforward on OpenShift Online, OpenShift Dedicated, OpenShift\nContainer Platform (version >= 3.6) or OpenShift Origin (version >= 3.6). To\nlearn more read [this\nblog](https://blog.openshift.com/getting-started-helm-openshift/) post.\n\n## Platform9\n\nHelm is pre-installed with [Platform9 Managed\nKubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes).\nPlatform9 provides access to all official Helm charts through the App Catalog UI\nand native Kubernetes CLI. Additional repositories can be manually added.\nFurther details are available in this [Platform9 App Catalog\narticle](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes).\n\n## Ubuntu with `kubeadm`\n\nKubernetes bootstrapped with `kubeadm` is known to work on the following Linux\ndistributions:\n\n- Ubuntu 16.04\n- Fedora release 25\n\nSome versions of Helm (v2.0.0-beta2) require you to `export\nKUBECONFIG=/etc/kubernetes/admin.conf` or create a `~/.kube/config`.\n\n## VMware Tanzu Kubernetes Grid\n\nHelm runs on VMware Tanzu Kubernetes Grid, TKG, without needing configuration changes.\nThe Tanzu CLI can manage installing packages for [helm-controller](https://fluxcd.io/flux/components/helm/) allowing for declaratively managing Helm chart releases.\nFurther 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).\n"
  },
  {
    "path": "versioned_docs/version-3/topics/library_charts.md",
    "content": "---\ntitle: Library Charts\ndescription: Explains library charts and examples of usage\nsidebar_position: 4\n---\n\nA library chart is a type of [Helm chart](/topics/charts.md)\nthat defines chart primitives or definitions which can be shared by Helm\ntemplates in other charts. This allows users to share snippets of code that can\nbe re-used across charts, avoiding repetition and keeping charts\n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n\nThe library chart was introduced in Helm 3 to formally recognize common or\nhelper charts that have been used by chart maintainers since Helm 2. By\nincluding it as a chart type, it provides:\n- A means to explicitly distinguish between common and application charts\n- Logic to prevent installation of a common chart\n- No rendering of templates in a common chart which may contain release\n  artifacts\n- Allow for dependent charts to use the importer's context\n\nA chart maintainer can define a common chart as a library chart and now be\nconfident that Helm will handle the chart in a standard consistent fashion. It\nalso means that definitions in an application chart can be shared by changing\nthe chart type.\n\n## Create a Simple Library Chart\n\nAs mentioned previously, a library chart is a type of [Helm chart](/topics/charts.md). This means that you can start off by creating a\nscaffold chart:\n\n```console\n$ helm create mylibchart\nCreating mylibchart\n```\n\nYou will first remove all the files in `templates` directory as we will create\nour own templates definitions in this example.\n\n```console\n$ rm -rf mylibchart/templates/*\n```\n\nThe values file will not be required either.\n\n```console\n$ rm -f mylibchart/values.yaml\n```\n\nBefore we jump into creating common code, lets do a quick review of some\nrelevant Helm concepts. A [named template](/chart_template_guide/named_templates.md) (sometimes called a partial\nor a subtemplate) is simply a template defined inside of a file, and given a\nname.  In the `templates/` directory, any file that begins with an underscore(_)\nis not expected to output a Kubernetes manifest file. So by convention, helper\ntemplates and partials are placed in a `_*.tpl` or `_*.yaml` files.\n\nIn this example, we will code a common ConfigMap which creates an empty\nConfigMap resource. We will define the common ConfigMap in file\n`mylibchart/templates/_configmap.yaml` as follows:\n\n```yaml\n{{- define \"mylibchart.configmap.tpl\" -}}\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata: {}\n{{- end -}}\n{{- define \"mylibchart.configmap\" -}}\n{{- include \"mylibchart.util.merge\" (append . \"mylibchart.configmap.tpl\") -}}\n{{- end -}}\n```\n\nThe ConfigMap construct is defined in named template `mylibchart.configmap.tpl`.\nIt is a simple ConfigMap with an empty resource, `data`. Within this file there\nis another named template called `mylibchart.configmap`. This named template\nincludes another named template `mylibchart.util.merge` which will take 2 named\ntemplates as arguments, the template calling `mylibchart.configmap` and\n`mylibchart.configmap.tpl`.\n\nThe helper function `mylibchart.util.merge` is a named template in\n`mylibchart/templates/_util.yaml`. It is a handy util from [The Common Helm\nHelper Chart](#the-common-helm-helper-chart) because it merges the 2 templates\nand overrides any common parts in both:\n\n```yaml\n{{- /*\nmylibchart.util.merge will merge two YAML templates and output the result.\nThis takes an array of three values:\n- the top context\n- the template name of the overrides (destination)\n- the template name of the base (source)\n*/}}\n{{- define \"mylibchart.util.merge\" -}}\n{{- $top := first . -}}\n{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}\n{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}\n{{- toYaml (merge $overrides $tpl) -}}\n{{- end -}}\n```\n\nThis is important when a chart wants to use common code that it needs to\ncustomize with its configuration.\n\nFinally, lets change the chart type to `library`. This requires editing\n`mylibchart/Chart.yaml` as follows:\n\n```yaml\napiVersion: v2\nname: mylibchart\ndescription: A Helm chart for Kubernetes\n\n# A chart can be either an 'application' or a 'library' chart.\n#\n# Application charts are a collection of templates that can be packaged into versioned archives\n# to be deployed.\n#\n# Library charts provide useful utilities or functions for the chart developer. They're included as\n# a dependency of application charts to inject those utilities and functions into the rendering\n# pipeline. Library charts do not define any templates and therefore cannot be deployed.\n# type: application\ntype: library\n\n# This is the chart version. This version number should be incremented each time you make changes\n# to the chart and its templates, including the app version.\nversion: 0.1.0\n\n# This is the version number of the application being deployed. This version number should be\n# incremented each time you make changes to the application and it is recommended to use it with quotes.\nappVersion: \"1.16.0\"\n```\n\nThe library chart is now ready to be shared and its ConfigMap definition to be\nre-used.\n\nBefore moving on, it is worth checking if Helm recognizes the chart as a library\nchart:\n\n```console\n$ helm install mylibchart mylibchart/\nError: library charts are not installable\n```\n\n## Use the Simple Library Chart\n\nIt is time to use the library chart. This means creating a scaffold chart again:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nLets clean out the template files again as we want to create a ConfigMap only:\n\n```console\n$ rm -rf mychart/templates/*\n```\n\nWhen we want to create a simple ConfigMap in a Helm template, it could look\nsimilar to the following:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: {{ .Release.Name | printf \"%s-%s\" .Chart.Name }}\ndata:\n  myvalue: \"Hello World\"\n```\n\nWe are however going to re-use the common code already created in `mylibchart`.\nThe ConfigMap can be created in the file `mychart/templates/configmap.yaml` as\nfollows:\n\n```yaml\n{{- include \"mylibchart.configmap\" (list . \"mychart.configmap\") -}}\n{{- define \"mychart.configmap\" -}}\ndata:\n  myvalue: \"Hello World\"\n{{- end -}}\n```\n\nYou can see that it simplifies the work we have to do by inheriting the common\nConfigMap definition which adds standard properties for ConfigMap. In our\ntemplate we add the configuration, in this case the data key `myvalue` and its\nvalue. The configuration override the empty resource of the common ConfigMap.\nThis is feasible because of the helper function `mylibchart.util.merge` we\nmentioned in the previous section.\n\nTo be able to use the common code, we need to add `mylibchart` as a dependency.\nAdd the following to the end of the file `mychart/Chart.yaml`:\n\n```yaml\n# My common code in my library chart\ndependencies:\n- name: mylibchart\n  version: 0.1.0\n  repository: file://../mylibchart\n```\n\nThis includes the library chart as a dynamic dependency from the filesystem\nwhich is at the same parent path as our application chart. As we are including\nthe library chart as a dynamic dependency, we need to run `helm dependency\nupdate`. It will copy the library chart into your `charts/` directory.\n\n```console\n$ helm dependency update mychart/\nHang tight while we grab the latest from your chart repositories...\n...Successfully got an update from the \"stable\" chart repository\nUpdate Complete. ⎈Happy Helming!⎈\nSaving 1 charts\nDeleting outdated charts\n```\n\nWe are now ready to deploy our chart. Before installing, it is worth checking\nthe rendered template first.\n\n```console\n$ helm install mydemo mychart/ --debug --dry-run\ninstall.go:159: [debug] Original chart version: \"\"\ninstall.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart\n\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:48:47 2020\nNAMESPACE: default\nSTATUS: pending-install\nREVISION: 1\nTEST SUITE: None\nUSER-SUPPLIED VALUES:\n{}\n\nCOMPUTED VALUES:\naffinity: {}\nfullnameOverride: \"\"\nimage:\n  pullPolicy: IfNotPresent\n  repository: nginx\nimagePullSecrets: []\ningress:\n  annotations: {}\n  enabled: false\n  hosts:\n  - host: chart-example.local\n    paths: []\n  tls: []\nmylibchart:\n  global: {}\nnameOverride: \"\"\nnodeSelector: {}\npodSecurityContext: {}\nreplicaCount: 1\nresources: {}\nsecurityContext: {}\nservice:\n  port: 80\n  type: ClusterIP\nserviceAccount:\n  annotations: {}\n  create: true\n  name: null\ntolerations: []\n\nHOOKS:\nMANIFEST:\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n```\n\nThis looks like the ConfigMap we want with data override of `myvalue: Hello\nWorld`. Lets install it:\n\n```console\n$ helm install mydemo mychart/\nNAME: mydemo\nLAST DEPLOYED: Tue Mar  3 17:52:40 2020\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\n```\n\nWe can retrieve the release and see that the actual template was loaded.\n\n```console\n$ helm get manifest mydemo\n---\n# Source: mychart/templates/configmap.yaml\napiVersion: v1\ndata:\n  myvalue: Hello World\nkind: ConfigMap\nmetadata:\n  labels:\n    app: mychart\n    chart: mychart-0.1.0\n    release: mydemo\n  name: mychart-mydemo\n  ```\n\n## Library Chart Benefits\nBecause of their inability to act as standalone charts, library charts can leverage the following functionality:\n- The `.Files` object references the file paths on the parent chart, rather than the path local to the library chart\n- 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.\n\n\n## The Common Helm Helper Chart\n\n```markdown\nNote: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived.\n```\n\nThis [chart](https://github.com/helm/charts/tree/master/incubator/common) was\nthe original pattern for common charts. It provides utilities that reflect best\npractices of Kubernetes chart development. Best of all it can be used off the\nbat by you when developing your charts to give you handy shared code.\n\nHere is a quick way to use it. For more details, have a look at the\n[README](https://github.com/helm/charts/blob/master/incubator/common/README.md).\n\nCreate a scaffold chart again:\n\n```console\n$ helm create demo\nCreating demo\n```\n\nLets use the common code from the helper chart. First, edit deployment\n`demo/templates/deployment.yaml` as follows:\n\n```yaml\n{{- template \"common.deployment\" (list . \"demo.deployment\") -}}\n{{- define \"demo.deployment\" -}}\n## Define overrides for your Deployment resource here, e.g.\napiVersion: apps/v1\nspec:\n  replicas: {{ .Values.replicaCount }}\n  selector:\n    matchLabels:\n      {{- include \"demo.selectorLabels\" . | nindent 6 }}\n  template:\n    metadata:\n      labels:\n        {{- include \"demo.selectorLabels\" . | nindent 8 }}\n\n{{- end -}}\n```\n\nAnd now the service file, `demo/templates/service.yaml` as follows:\n\n```yaml\n{{- template \"common.service\" (list . \"demo.service\") -}}\n{{- define \"demo.service\" -}}\n## Define overrides for your Service resource here, e.g.\n# metadata:\n#   labels:\n#     custom: label\n# spec:\n#   ports:\n#   - port: 8080\n{{- end -}}\n```\n\nThese templates show how inheriting the common code from the helper chart\nsimplifies your coding down to your configuration or customization of the\nresources.\n\nTo be able to use the common code, we need to add `common` as a dependency. Add\nthe following to the end of the file `demo/Chart.yaml`:\n\n```yaml\ndependencies:\n- name: common\n  version: \"^0.0.5\"\n  repository: \"https://charts.helm.sh/incubator/\"\n```\n\nNote: You will need to add the `incubator` repo to the Helm repository list\n(`helm repo add`).\n\nAs we are including the chart as a dynamic dependency, we need to run `helm\ndependency update`. It will copy the helper chart into your `charts/` directory.\n\nAs helper chart is using some Helm 2 constructs, you will need to add the\nfollowing to `demo/values.yaml` to enable the `nginx` image to be loaded as this\nwas updated in Helm 3 scaffold chart:\n\n```yaml\nimage:\n  tag: 1.16.0\n```\n\nYou can test that the chart templates are correct prior to deploying using the `helm lint` and `helm template` commands.\n\nIf it's good to go, deploy away using `helm install`!\n\n"
  },
  {
    "path": "versioned_docs/version-3/topics/permissions_sql_storage_backend.md",
    "content": "---\ntitle: Permissions management for SQL storage backend\ndescription: Get to know how to setup permissions when using SQL storage backend.\n---\n\nThis document aims to provide guidance to users for setting up and managing\npermissions when using the SQL storage backend.\n\n## Introduction\n\nTo handle permissions, Helm leverages the RBAC feature of Kubernetes. When using\nthe SQL storage backend, Kubernetes' roles can't be used to determine whether or\nnot an user can access a given resource. This document shows how to create and\nmanage these permissions.\n\n## Initialization\n\nThe first time the Helm CLI will make connect to your database, the client will\nmake sure that it was previously initialized. If it is not, it will take care of\nthe necessary setup automatically. This initialization requires admin privileges\non the public schema, or at least to be able to:\n\n* create a table\n* grant privileges on the public schema\n\nAfter the migration was run against your database, all the other roles can use\nthe client.\n\n## Grant privileges to a non admin user in PostgreSQL\n\nTo manage permissions, the SQL backend driver leverages the\n[RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)(Row Security\nLevel) feature of PostgreSQL. RLS allows all users to be able to read/write\nfrom/to the same table, without being able to manipulate the same rows if they\nare not explicitly allowed to. By default, any role that has not been\nexplicitly granted with the right privileges will always return an empty list\nwhen running `helm list` and will not be able to retrieve or modify any resource\nin the cluster.\n\nLet's see how to grant a given role access to specific namespaces:\n\n```sql\nCREATE POLICY <name> ON releases_v1 FOR ALL TO <role> USING (namespace = 'default');\n```\n\nThis command will grant the permissions to read and write all resources that\nmeet the `namespace = 'default'` condition to the role `role`. After creating\nthis policy, the user being connected to the database on the behalf of the role\n`role` will therefore be able to see all the releases living in the `default`\nnamespace when running `helm list`, and to modify and delete them.\n\nPrivileges can be managed granularly with RLS, and one might be interested in\nrestraining access given the different columns of the table:\n* key\n* type\n* body\n* name\n* namespace\n* version\n* status\n* owner\n* createdAt\n* modifiedAt\n"
  },
  {
    "path": "versioned_docs/version-3/topics/plugins.md",
    "content": "---\ntitle: The Helm Plugins Guide\ndescription: Introduces how to use and create plugins to extend Helm's functionality.\nsidebar_position: 12\n---\n\nA Helm plugin is a tool that can be accessed through the `helm` CLI, but which\nis not part of the built-in Helm codebase.\n\nExisting plugins can be found on [related](/community/related#helm-plugins) section or by searching\n[GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).\n\nThis guide explains how to use and create plugins.\n\n## An Overview\n\nHelm plugins are add-on tools that integrate seamlessly with Helm. They provide\na way to extend the core feature set of Helm, but without requiring every new\nfeature to be written in Go and added to the core tool.\n\nHelm plugins have the following features:\n\n- They can be added and removed from a Helm installation without impacting the\n  core Helm tool.\n- They can be written in any programming language.\n- They integrate with Helm, and will show up in `helm help` and other places.\n\nHelm plugins live in `$HELM_PLUGINS`. You can find the current value of this,\nincluding the default value when not set in the environment, using the\n`helm env` command.\n\nThe Helm plugin model is partially based on Git's plugin model. To that end,\nyou may sometimes hear `helm` referred to as the _porcelain_ layer, with plugins\nbeing the _plumbing_. This is a shorthand way of suggesting that Helm provides\nthe user experience and top level processing logic, while the plugins do the\n\"detail work\" of performing a desired action.\n\n## Installing a Plugin\n\nPlugins are installed using the `$ helm plugin install <path|url>` command. You\ncan pass in a path to a plugin on your local file system or a url of a remote\nVCS repo. The `helm plugin install` command clones or copies the plugin at the\npath/url given into `$HELM_PLUGINS`. If you are installing from a VCS you can specify\nthe version with the `--version` argument.\n\n```console\n$ helm plugin install https://github.com/adamreese/helm-env\n```\n\nIf you have a plugin tar distribution, simply untar the plugin into the\n`$HELM_PLUGINS` directory. You can also install tarball plugins\ndirectly from url by issuing `helm plugin install\nhttps://domain/path/to/plugin.tar.gz`\n\n## The Plugin File Structure\n\nIn many ways, a plugin is similar to a chart. Each plugin has a top-level\ndirectory containing a `plugin.yaml` file. Additional files may be present but\nonly the `plugin.yaml` file is required.\n\n```console\n$HELM_PLUGINS/\n  |- last/\n      |- plugin.yaml\n```\n\n## The plugin.yaml File\n\nThe plugin.yaml file is required for a plugin. It contains the following fields:\n\n```yaml\nname: The name of the plugin (REQUIRED)\nversion: A SemVer 2 version (REQUIRED)\nusage: Single line usage text shown in help\ndescription: Long description shown in places like helm help\nignoreFlags: Ignore flags passed in from Helm\nplatformCommand: # Configure command to run based on the platform\n  - os: OS match, can be empty or omitted to match all OS'\n    arch: Architecture match, can be empty or omitted to match all architectures\n    command: Plugin command to execute\n    args: Plugin command arguments\ncommand: (DEPRECATED) Plugin command, use platformCommand instead\nplatformHooks: # Configure plugin lifecycle hooks based on the platform\n  install: # Install lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin install command to execute\n      args: Plugin install command arguments\n  update: # Update lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin update command to execute\n      args: Plugin update command arguments\n  delete: # Delete lifecycle commands\n    - os: OS match, can be empty or omitted to match all OS'\n      arch: Architecture match, can be empty or omitted to match all architectures\n      command: Plugin delete command to execute\n      args: Plugin delete command arguments\nhooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead\n  install: Command to install plugin\n  update: Command to update plugin\n  delete: Command to delete plugin\ndownloaders: # Configure downloaders capability\n  - command: Command to invoke\n    protocols:\n      - Protocol schema supported\n```\n\n### The `name` Field\n\nThe `name` is the name of the plugin. When Helm executes this plugin, this is\nthe name it will use (e.g. `helm NAME` will invoke this plugin).\n\n_`name` should match the directory name._ In our example above, that means the\nplugin with `name: last` should be contained in a directory named `last`.\n\nRestrictions on `name`:\n\n- `name` cannot duplicate one of the existing `helm` top-level commands.\n- `name` must be restricted to the characters ASCII a-z, A-Z, 0-9, `_` and `-`.\n\n### The `version` Field\n\nThe `version` is the SemVer 2 version of the plugin. `usage` and `description` are\nboth used to generate the help text of a command.\n\n### The `ignoreFlags` Field\n\nThe `ignoreFlags` switch tells Helm to _not_ pass flags to the plugin. So if a\nplugin is called with `helm myplugin --foo` and `ignoreFlags: true`, then\n`--foo` is silently discarded.\n\n### The `platformCommand` Field\n\nThe `platformCommand` configures the command that the plugin will execute when\nit is called. You can't set both `platformCommand` & `command` as this will result\nin an error. The following rules will apply in deciding which command to use:\n\n- If `platformCommand` is present, it will be used.\n  - If both `os` and `arch` match the current platform, search will stop and the\n  command will be used.\n  - If `os` matches and `arch` is empty, the command will be used.\n  - If `os` and `arch` are both empty, the command will be used.\n  - If there is no match, Helm will exit with an error.\n- If `platformCommand` is not present and the deprecated `command` is present\nit will be used.\n  - If the command is empty, Helm will exit with an error.\n\n### The `platformHooks` Field\n\nThe `platformHooks` configures the commands that the plugin will execute for lifecycle\nevents. You can't set both `platformHooks` & `hooks` as this will resultin an error.\nThe following rules will apply in deciding which hook command to use:\n\n- If `platformHooks` is present, it will be used and the commands for the lifecycle\nevent will be processed.\n  - If both `os` and `arch` match the current platform, search will stop and the\n  command will be used.\n  - If `os` matches and `arch` is empty, the command will be used.\n  - If `os` and `arch` are both empty, the command will be used.\n  - If there is no match, Helm will skip the event.\n- If `platformHooks` is not present and the deprecated `hooks` is present the command\nfor the lifecycle event will be used.\n  - If the command is empty, Helm will skip the event.\n\n## Building a Plugin\n\nHere is the plugin YAML for a simple plugin that helps get the last release name:\n\n```yaml\nname: last\nversion: 0.1.0\nusage: get the last release name\ndescription: get the last release name\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_BIN}\n    args:\n      - list\n      - --short\n      - --max=1\n      - --date\n      - -r\n```\n\nPlugins may require additional scripts and executables.\nScripts can be included in the plugin directory and executables can be downloaded\nvia a hook. The following is an example plugin:\n\n```console\n$HELM_PLUGINS/\n  |- myplugin/\n    |- scripts/\n      |- install.ps1\n      |- install.sh\n    |- plugin.yaml\n```\n\n```yaml\nname: myplugin\nversion: 0.1.0\nusage: example plugin\ndescription: example plugin\nignoreFlags: false\nplatformCommand:\n  - command: ${HELM_PLUGIN_DIR}/bin/myplugin\n  - os: windows\n    command: ${HELM_PLUGIN_DIR}\\bin\\myplugin.exe\nplatformHooks:\n  install:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n  update:\n    - command: ${HELM_PLUGIN_DIR}/scripts/install.sh\n      args:\n        - -u\n    - os: windows\n      command: pwsh\n      args:\n        - -c\n        - ${HELM_PLUGIN_DIR}\\scripts\\install.ps1\n        - -Update\n```\n\nEnvironment variables are interpolated before the plugin is executed. The\npattern above illustrates the preferred way to indicate where the plugin program\nlives.\n\n### Plugin Commands\n\nThere are some strategies for working with plugin commands:\n\n- If a plugin includes an executable, the executable for a `platformCommand:` or\n  should be packaged in the plugin directory or installed via a hook.\n- The `platformCommand:` or `command:` line will have any environment variables\n  expanded before execution. `$HELM_PLUGIN_DIR` will point to the plugin\n  directory.\n- The command itself is not executed in a shell. So you can't oneline a shell\n  script.\n- Helm injects lots of configuration into environment variables. Take a look at\n  the environment to see what information is available.\n- Helm makes no assumptions about the language of the plugin. You can write it\n  in whatever you prefer.\n- Commands are responsible for implementing specific help text for `-h` and\n  `--help`. Helm will use `usage` and `description` for `helm help` and `helm\n  help myplugin`, but will not handle `helm myplugin --help`.\n\n### Testing a Local Plugin\n\nFirst you need to find your `HELM_PLUGINS` path to do it run the following command:\n\n``` bash\nhelm env\n```\n\nChange your current directory to the director that `HELM_PLUGINS` is set to.\n\nNow you can add a symbolic link to your build output of your plugin in this example\nwe did it for `mapkubeapis`.\n\n``` bash\nln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis\n```\n\n## Downloader Plugins\n\nBy default, Helm is able to pull Charts using HTTP/S. As of Helm 2.4.0, plugins\ncan have a special capability to download Charts from arbitrary sources.\n\nPlugins shall declare this special capability in the `plugin.yaml` file (top\nlevel):\n\n```yaml\ndownloaders:\n- command: \"bin/mydownloader\"\n  protocols:\n  - \"myprotocol\"\n  - \"myprotocols\"\n```\n\nIf such plugin is installed, Helm can interact with the repository using the\nspecified protocol scheme by invoking the `command`. The special repository\nshall be added similarly to the regular ones: `helm repo add favorite\nmyprotocol://example.com/` The rules for the special repos are the same to the\nregular ones: Helm must be able to download the `index.yaml` file in order to\ndiscover and cache the list of available Charts.\n\nThe defined command will be invoked with the following scheme: `command certFile\nkeyFile caFile full-URL`. The SSL credentials are coming from the repo\ndefinition, stored in `$HELM_REPOSITORY_CONFIG`\n(i.e., `$HELM_CONFIG_HOME/repositories.yaml`). A Downloader plugin\nis expected to dump the raw content to stdout and report errors on stderr.\n\nThe downloader command also supports sub-commands or arguments, allowing you to\nspecify for example `bin/mydownloader subcommand -d` in the `plugin.yaml`. This\nis useful if you want to use the same executable for the main plugin command and\nthe downloader command, but with a different sub-command for each.\n\n## Environment Variables\n\nWhen Helm executes a plugin, it passes the outer environment to the plugin, and\nalso injects some additional environment variables.\n\nVariables like `KUBECONFIG` are set for the plugin if they are set in the outer\nenvironment.\n\nThe following variables are guaranteed to be set:\n\n- `HELM_PLUGINS`: The path to the plugins directory.\n- `HELM_PLUGIN_NAME`: The name of the plugin, as invoked by `helm`. So `helm\n  myplug` will have the short name `myplug`.\n- `HELM_PLUGIN_DIR`: The directory that contains the plugin.\n- `HELM_BIN`: The path to the `helm` command (as executed by the user).\n- `HELM_DEBUG`: Indicates if the debug flag was set by helm.\n- `HELM_REGISTRY_CONFIG`: The location for the registry configuration (if\n  using). Note that the use of Helm with registries is an experimental feature.\n- `HELM_REPOSITORY_CACHE`: The path to the repository cache files.\n- `HELM_REPOSITORY_CONFIG`: The path to the repository configuration file.\n- `HELM_NAMESPACE`: The namespace given to the `helm` command (generally using\n  the `-n` flag).\n- `HELM_KUBECONTEXT`: The name of the Kubernetes config context given to the\n  `helm` command.\n\nAdditionally, if a Kubernetes configuration file was explicitly specified, it\nwill be set as the `KUBECONFIG` variable\n\n## A Note on Flag Parsing\n\nWhen executing a plugin, Helm will parse global flags for its own use. None of\nthese flags are passed on to the plugin.\n- `--burst-limit`: This is converted to `$HELM_BURST_LIMIT`\n- `--debug`: If this is specified, `$HELM_DEBUG` is set to `1`\n- `--kube-apiserver`: This is converted to `$HELM_KUBEAPISERVER`\n- `--kube-as-group`: These are converted to `$HELM_KUBEASGROUPS`\n- `--kube-as-user`: This is converted to `$HELM_KUBEASUSER`\n- `--kube-ca-file`: This is converted to `$HELM_KUBECAFILE`\n- `--kube-context`: This is converted to `$HELM_KUBECONTEXT`\n- `--kube-insecure-skip-tls-verify`: This is converted to `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`\n- `--kube-tls-server-name`: This is converted to `$HELM_KUBETLS_SERVER_NAME`\n- `--kube-token`: This is converted to `$HELM_KUBETOKEN`\n- `--kubeconfig`: This is converted to `$KUBECONFIG`\n- `--namespace` and `-n`: This is converted to `$HELM_NAMESPACE`\n- `--qps`: This is converted to `$HELM_QPS`\n- `--registry-config`: This is converted to `$HELM_REGISTRY_CONFIG`\n- `--repository-cache`: This is converted to `$HELM_REPOSITORY_CACHE`\n- `--repository-config`: This is converted to `$HELM_REPOSITORY_CONFIG`\n\nPlugins _should_ display help text and then exit for `-h` and `--help`. In all\nother cases, plugins may use flags as appropriate.\n\n## Providing shell auto-completion\n\nAs of Helm 3.2, a plugin can optionally provide support for shell\nauto-completion as part of Helm's existing auto-completion mechanism.\n\n### Static auto-completion\n\nIf a plugin provides its own flags and/or sub-commands, it can inform Helm of\nthem by having a `completion.yaml` file located in the plugin's root directory.\nThe `completion.yaml` file has the form:\n\n```yaml\nname: <pluginName>\nflags:\n- <flag 1>\n- <flag 2>\nvalidArgs:\n- <arg value 1>\n- <arg value 2>\ncommands:\n  name: <commandName>\n  flags:\n  - <flag 1>\n  - <flag 2>\n  validArgs:\n  - <arg value 1>\n  - <arg value 2>\n  commands:\n     <and so on, recursively>\n```\n\nNotes:\n\n1. All sections are optional but should be provided if applicable.\n1. Flags should not include the `-` or `--` prefix.\n1. Both short and long flags can and should be specified. A short flag need not\n   be associated with its corresponding long form, but both forms should be\n   listed.\n1. Flags need not be ordered in any way, but need to be listed at the correct\n   point in the sub-command hierarchy of the file.\n1. Helm's existing global flags are already handled by Helm's auto-completion\n   mechanism, therefore plugins need not specify the following flags `--debug`,\n   `--namespace` or `-n`, `--kube-context`, and `--kubeconfig`, or any other\n   global flag.\n1. The `validArgs` list provides a static list of possible completions for the\n   first parameter following a sub-command.  It is not always possible to\n   provide such a list in advance (see the [Dynamic\n   Completion](#dynamic-completion) section below), in which case the\n   `validArgs` section can be omitted.\n\nThe `completion.yaml` file is entirely optional.  If it is not provided, Helm\nwill simply not provide shell auto-completion for the plugin (unless [Dynamic\nCompletion](#dynamic-completion) is supported by the plugin).  Also, adding a\n`completion.yaml` file is backwards-compatible and will not impact the behavior\nof the plugin when using older helm versions.\n\nAs an example, for the [`fullstatus\nplugin`](https://github.com/marckhouzam/helm-fullstatus) which has no\nsub-commands but accepts the same flags as the `helm status` command, the\n`completion.yaml` file is:\n\n```yaml\nname: fullstatus\nflags:\n- o\n- output\n- revision\n```\n\nA more intricate example for the [`2to3\nplugin`](https://github.com/helm/helm-2to3), has a `completion.yaml` file of:\n\n```yaml\nname: 2to3\ncommands:\n- name: cleanup\n  flags:\n  - config-cleanup\n  - dry-run\n  - l\n  - label\n  - release-cleanup\n  - s\n  - release-storage\n  - tiller-cleanup\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: convert\n  flags:\n  - delete-v2-releases\n  - dry-run\n  - l\n  - label\n  - s\n  - release-storage\n  - release-versions-max\n  - t\n  - tiller-ns\n  - tiller-out-cluster\n- name: move\n  commands:\n  - name: config\n    flags:\n    - dry-run\n```\n\n### Dynamic completion\n\nAlso starting with Helm 3.2, plugins can provide their own dynamic shell\nauto-completion. Dynamic shell auto-completion is the completion of parameter\nvalues or flag values that cannot be defined in advance.  For example,\ncompletion of the names of helm releases currently available on the cluster.\n\nFor the plugin to support dynamic auto-completion, it must provide an\n**executable** file called `plugin.complete` in its root directory. When the\nHelm completion script requires dynamic completions for the plugin, it will\nexecute the `plugin.complete` file, passing it the command-line that needs to be\ncompleted.  The `plugin.complete` executable will need to have the logic to\ndetermine what the proper completion choices are and output them to standard\noutput to be consumed by the Helm completion script.\n\nThe `plugin.complete` file is entirely optional.  If it is not provided, Helm\nwill simply not provide dynamic auto-completion for the plugin.  Also, adding a\n`plugin.complete` file is backwards-compatible and will not impact the behavior\nof the plugin when using older helm versions.\n\nThe output of the `plugin.complete` script should be a new-line separated list\nsuch as:\n\n```console\nrel1\nrel2\nrel3\n```\n\nWhen `plugin.complete` is called, the plugin environment is set just like when\nthe plugin's main script is called. Therefore, the variables `$HELM_NAMESPACE`,\n`$HELM_KUBECONTEXT`, and all other plugin variables will already be set, and\ntheir corresponding global flags will be removed.\n\nThe `plugin.complete` file can be in any executable form; it can be a shell\nscript, a Go program, or any other type of program that Helm can execute. The\n`plugin.complete` file ***must*** have executable permissions for the user. The\n`plugin.complete` file ***must*** exit with a success code (value 0).\n\nIn some cases, dynamic completion will require to obtain information from the\nKubernetes cluster.  For example, the `helm fullstatus` plugin requires a\nrelease name as input. In the `fullstatus` plugin, for its `plugin.complete`\nscript to provide completion for current release names, it can simply run `helm\nlist -q` and output the result.\n\nIf it is desired to use the same executable for plugin execution and for plugin\ncompletion, the `plugin.complete` script can be made to call the main plugin\nexecutable with some special parameter or flag; when the main plugin executable\ndetects the special parameter or flag, it will know to run the completion. In\nour example, `plugin.complete` could be implemented like this:\n\n```sh\n#!/usr/bin/env sh\n\n# \"$@\" is the entire command-line that requires completion.\n# It is important to double-quote the \"$@\" variable to preserve a possibly empty last parameter.\n$HELM_PLUGIN_DIR/status.sh --complete \"$@\"\n```\n\nThe `fullstatus` plugin's real script (`status.sh`) must then look for the\n`--complete` flag and if found, printout the proper completions.\n\n### Tips and tricks\n\n1. The shell will automatically filter out completion choices that don't match\n   user input. A plugin can therefore return all relevant completions without\n   removing the ones that don't match the user input.  For example, if the\n   command-line is `helm fullstatus ngin<TAB>`, the `plugin.complete` script can\n   print *all* release names (of the `default` namespace), not just the ones\n   starting with `ngin`; the shell will only retain the ones starting with\n   `ngin`.\n1. To simplify dynamic completion support, especially if you have a complex\n   plugin, you can have your  `plugin.complete` script call your main plugin\n   script and request completion choices.  See the [Dynamic\n   Completion](#dynamic-completion) section above for an example.\n1. To debug dynamic completion and the `plugin.complete` file, one can run the\n   following to see the completion results :\n    - `helm __complete <pluginName> <arguments to complete>`.  For example:\n    - `helm __complete fullstatus --output js<ENTER>`,\n    - `helm __complete fullstatus -o json \"\"<ENTER>`\n"
  },
  {
    "path": "versioned_docs/version-3/topics/provenance.md",
    "content": "---\ntitle: Helm Provenance and Integrity\ndescription: Describes how to verify the integrity and origin of a Chart.\nsidebar_position: 5\n---\n\nHelm has provenance tools which help chart users verify the integrity and origin\nof a package. Using industry-standard tools based on PKI, GnuPG, and\nwell-respected package managers, Helm can generate and verify signature files.\n\n## Overview\n\nIntegrity is established by comparing a chart to a provenance record. Provenance\nrecords are stored in _provenance files_, which are stored alongside a packaged\nchart. For example, if a chart is named `myapp-1.2.3.tgz`, its provenance file\nwill be `myapp-1.2.3.tgz.prov`.\n\nProvenance files are generated at packaging time (`helm package --sign ...`),\nand can be checked by multiple commands, notably `helm install --verify`.\n\n## The Workflow\n\nThis section describes a potential workflow for using provenance data\neffectively.\n\nPrerequisites:\n\n- A valid PGP keypair in a binary (not ASCII-armored) format\n- The `helm` command line tool\n- GnuPG command line tools (optional)\n- Keybase command line tools (optional)\n\n**NOTE:** If your PGP private key has a passphrase, you will be prompted to\nenter that passphrase for any commands that support the `--sign` option.\n\nCreating a new chart is the same as before:\n\n```console\n$ helm create mychart\nCreating mychart\n```\n\nOnce ready to package, add the `--sign` flag to `helm package`. Also, specify\nthe name under which the signing key is known and the keyring containing the\ncorresponding private key:\n\n```console\n$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart\n```\n\n**Note:** The value of the `--key` argument must be a substring of the desired\nkey's `uid` (in the output of `gpg --list-keys`), for example the name or email.\n**The fingerprint _cannot_ be used.**\n\n**TIP:** for GnuPG users, your secret keyring is in `~/.gnupg/secring.gpg`. You\ncan use `gpg --list-secret-keys` to list the keys you have.\n\n**Warning:**  the GnuPG v2 store your secret keyring using a new format `kbx` on\nthe default location  `~/.gnupg/pubring.kbx`. Please use the following command\nto convert your keyring to the legacy gpg format:\n\n```console\n$ gpg --export >~/.gnupg/pubring.gpg\n$ gpg --export-secret-keys >~/.gnupg/secring.gpg\n```\n\nAt this point, you should see both `mychart-0.1.0.tgz` and\n`mychart-0.1.0.tgz.prov`. Both files should eventually be uploaded to your\ndesired chart repository.\n\nYou can verify a chart using `helm verify`:\n\n```console\n$ helm verify mychart-0.1.0.tgz\n```\n\nA failed verification looks like this:\n\n```console\n$ helm verify topchart-0.1.0.tgz\nError: sha256 sum does not match for topchart-0.1.0.tgz: \"sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7\" != \"sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a\"\n```\n\nTo verify during an install, use the `--verify` flag.\n\n```console\n$ helm install --generate-name --verify mychart-0.1.0.tgz\n```\n\nIf the keyring containing the public key associated with the signed chart is not\nin the default location, you may need to point to the keyring with `--keyring\nPATH` as in the `helm package` example.\n\nIf verification fails, the install will be aborted before the chart is even\nrendered.\n\n### Using Keybase.io credentials\n\nThe [Keybase.io](https://keybase.io) service makes it easy to establish a chain\nof trust for a cryptographic identity. Keybase credentials can be used to sign\ncharts.\n\nPrerequisites:\n\n- A configured Keybase.io account\n- GnuPG installed locally\n- The `keybase` CLI installed locally\n\n#### Signing packages\n\nThe first step is to import your keybase keys into your local GnuPG keyring:\n\n```console\n$ keybase pgp export -s | gpg --import\n```\n\nThis will convert your Keybase key into the OpenPGP format, and then import it\nlocally into your `~/.gnupg/secring.gpg` file.\n\nYou can double check by running `gpg --list-secret-keys`.\n\n```console\n$ gpg --list-secret-keys\n/Users/mattbutcher/.gnupg/secring.gpg\n-------------------------------------\nsec   2048R/1FC18762 2016-07-25\nuid                  technosophos (keybase.io/technosophos) <technosophos@keybase.io>\nssb   2048R/D125E546 2016-07-25\n```\n\nNote that your secret key will have an identifier string:\n\n```\ntechnosophos (keybase.io/technosophos) <technosophos@keybase.io>\n```\n\nThat is the full name of your key.\n\nNext, you can package and sign a chart with `helm package`. Make sure you use at\nleast part of that name string in `--key`.\n\n```console\n$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart\n```\n\nAs a result, the `package` command should produce both a `.tgz` file and a\n`.tgz.prov` file.\n\n#### Verifying packages\n\nYou can also use a similar technique to verify a chart signed by someone else's\nKeybase key. Say you want to verify a package signed by\n`keybase.io/technosophos`. To do this, use the `keybase` tool:\n\n```console\n$ keybase follow technosophos\n$ keybase pgp pull\n```\n\nThe first command above tracks the user `technosophos`. Next `keybase pgp pull`\ndownloads the OpenPGP keys of all of the accounts you follow, placing them in\nyour GnuPG keyring (`~/.gnupg/pubring.gpg`).\n\nAt this point, you can now use `helm verify` or any of the commands with a\n`--verify` flag:\n\n```console\n$ helm verify somechart-1.2.3.tgz\n```\n\n### Reasons a chart may not verify\n\nThese are common reasons for failure.\n\n- The `.prov` file is missing or corrupt. This indicates that something is\n  misconfigured or that the original maintainer did not create a provenance\n  file.\n- The key used to sign the file is not in your keyring. This indicate that the\n  entity who signed the chart is not someone you've already signaled that you\n  trust.\n- The verification of the `.prov` file failed. This indicates that something is\n  wrong with either the chart or the provenance data.\n- The file hashes in the provenance file do not match the hash of the archive\n  file. This indicates that the archive has been tampered with.\n\nIf a verification fails, there is reason to distrust the package.\n\n## The Provenance File\n\nThe provenance file contains a chart’s YAML file plus several pieces of\nverification information. Provenance files are designed to be automatically\ngenerated.\n\nThe following pieces of provenance data are added:\n\n* The chart file (`Chart.yaml`) is included to give both humans and tools an\n  easy view into the contents of the chart.\n* The signature (SHA256, just like Docker) of the chart package (the `.tgz`\n  file) is included, and may be used to verify the integrity of the chart\n  package.\n* The entire body is signed using the algorithm used by OpenPGP (see\n  [Keybase.io](https://keybase.io) for an emerging way of making crypto\n  signing and verification easy).\n\nThe combination of this gives users the following assurances:\n\n* The package itself has not been tampered with (checksum package `.tgz`).\n* The entity who released this package is known (via the GnuPG/PGP signature).\n\nThe format of the file looks something like this:\n\n```\nHash: SHA512\n\napiVersion: v2\nappVersion: \"1.16.0\"\ndescription: Sample chart\nname: mychart\ntype: application\nversion: 0.1.0\n\n...\nfiles:\n  mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92\n-----BEGIN PGP SIGNATURE-----\n\nwsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd\nnvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI\nmYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2\ncR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi\nhZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D\nqtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8=\n=aHfz\n-----END PGP SIGNATURE-----\n```\n\nNote that the YAML section contains two documents (separated by `...\\n`). The\nfirst file is the content of `Chart.yaml`. The second is the checksums, a map of\nfilenames to SHA-256 digests of that file's content at packaging time.\n\nThe signature block is a standard PGP signature, which provides [tamper\nresistance](https://www.rossde.com/PGP/pgp_signatures.html).\n\n## Chart Repositories\n\nChart repositories serve as a centralized collection of Helm charts.\n\nChart repositories must make it possible to serve provenance files over HTTP via\na specific request, and must make them available at the same URI path as the\nchart.\n\nFor example, if the base URL for a package is\n`https://example.com/charts/mychart-1.2.3.tgz`, the provenance file, if it\nexists, MUST be accessible at\n`https://example.com/charts/mychart-1.2.3.tgz.prov`.\n\nFrom the end user's perspective, `helm install --verify myrepo/mychart-1.2.3`\nshould result in the download of both the chart and the provenance file with no\nadditional user configuration or action.\n\n### Signatures in OCI-based registries\n\nWhen publishing charts to an [OCI-based registry](/topics/registries.md), the\n[`helm-sigstore` plugin](https://github.com/sigstore/helm-sigstore/) can be used \nto publish provenance to [sigstore](https://sigstore.dev/).  [As described in the\ndocumentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), the\nprocess of creating provenance and signing with a GPG key are common, but the\n`helm sigstore upload` command can be used to publish the provenance to an\nimmutable transparency log.\n\n## Establishing Authority and Authenticity\n\nWhen dealing with chain-of-trust systems, it is important to be able to\nestablish the authority of a signer. Or, to put this plainly, the system above\nhinges on the fact that you trust the person who signed the chart. That, in\nturn, means you need to trust the public key of the signer.\n\nOne of the design decisions with Helm has been that the Helm project would not\ninsert itself into the chain of trust as a necessary party. We don't want to be\n\"the certificate authority\" for all chart signers. Instead, we strongly favor a\ndecentralized model, which is part of the reason we chose OpenPGP as our\nfoundational technology. So when it comes to establishing authority, we have\nleft this step more-or-less undefined in Helm 2 (a decision carried forward in\nHelm 3).\n\nHowever, we have some pointers and recommendations for those interested in using\nthe provenance system:\n\n- The [Keybase](https://keybase.io) platform provides a public centralized\n  repository for trust information.\n  - You can use Keybase to store your keys or to get the public keys of others.\n  - Keybase also has fabulous documentation available\n  - While we haven't tested it, Keybase's \"secure website\" feature could be used\n    to serve Helm charts.\n  - The basic idea is that an official \"chart reviewer\" signs charts with her or\n    his key, and the resulting provenance file is then uploaded to the chart\n    repository.\n  - There has been some work on the idea that a list of valid signing keys may\n    be included in the `index.yaml` file of a repository.\n\n"
  },
  {
    "path": "versioned_docs/version-3/topics/rbac.md",
    "content": "---\ntitle: Role-based Access Control\ndescription: Explains how Helm interacts with Kubernetes' Role-Based Access Control.\nsidebar_position: 11\n---\n\nIn Kubernetes, granting roles to a user or an application-specific service\naccount is a best practice to ensure that your application is operating in the\nscope that you have specified. Read more about service account permissions [in\nthe official Kubernetes\ndocs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).\n\nFrom Kubernetes 1.6 onwards, Role-based Access Control is enabled by default.\nRBAC allows you to specify which types of actions are permitted depending on the\nuser and their role in your organization.\n\nWith RBAC, you can\n\n- grant privileged operations (creating cluster-wide resources, like new roles)\n  to administrators\n- limit a user's ability to create resources (pods, persistent volumes,\n  deployments) to specific namespaces, or in cluster-wide scopes (resource\n  quotas, roles, custom resource definitions)\n- limit a user's ability to view resources either in specific namespaces or at a\n  cluster-wide scope.\n\nThis guide is for administrators who want to restrict the scope of a user's\ninteraction with the Kubernetes API.\n\n## Managing user accounts\n\nAll Kubernetes clusters have two categories of users: service accounts managed\nby Kubernetes, and normal users.\n\nNormal users are assumed to be managed by an outside, independent service. An\nadministrator distributing private keys, a user store like Keystone or Google\nAccounts, even a file with a list of usernames and passwords. In this regard,\nKubernetes does not have objects which represent normal user accounts. Normal\nusers cannot be added to a cluster through an API call.\n\nIn contrast, service accounts are users managed by the Kubernetes API. They are\nbound to specific namespaces, and created automatically by the API server or\nmanually through API calls. Service accounts are tied to a set of credentials\nstored as Secrets, which are mounted into pods allowing in-cluster processes to\ntalk to the Kubernetes API.\n\nAPI requests are tied to either a normal user or a service account, or are\ntreated as anonymous requests. This means every process inside or outside the\ncluster, from a human user typing `kubectl` on a workstation, to kubelets on\nnodes, to members of the control plane, must authenticate when making requests\nto the API server, or be treated as an anonymous user.\n\n## Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings\n\nIn Kubernetes, user accounts and service accounts can only view and edit\nresources they have been granted access to. This access is granted through the\nuse of Roles and RoleBindings. Roles and RoleBindings are bound to a particular\nnamespace, which grant users the ability to view and/or edit resources within\nthat namespace the Role provides them access to.\n\nAt a cluster scope, these are called ClusterRoles and ClusterRoleBindings.\nGranting a user a ClusterRole grants them access to view and/or edit resources\nacross the entire cluster. It is also required to view and/or edit resources at\nthe cluster scope (namespaces, resource quotas, nodes).\n\nClusterRoles can be bound to a particular namespace through reference in a\nRoleBinding. The `admin`, `edit` and `view` default ClusterRoles are commonly\nused in this manner.\n\nThese are a few ClusterRoles available by default in Kubernetes. They are\nintended to be user-facing roles. They include super-user roles\n(`cluster-admin`), and roles with more granular access (`admin`, `edit`,\n`view`).\n\n| Default ClusterRole | Default ClusterRoleBinding | Description\n|---------------------|----------------------------|-------------\n| `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.\n| `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.\n| `edit`              | None                       | Allows read/write access to most objects in a namespace. It does not allow viewing or modifying roles or rolebindings.\n| `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.\n\n## Restricting a user account's access using RBAC\n\nNow that we understand the basics of Role-based Access Control, let's discuss\nhow an administrator can restrict a user's scope of access.\n\n### Example: Grant a user read/write access to a particular namespace\n\nTo restrict a user's access to a particular namespace, we can use either the\n`edit` or the `admin` role. If your charts create or interact with Roles and\nRolebindings, you'll want to use the `admin` ClusterRole.\n\nAdditionally, you may also create a RoleBinding with `cluster-admin` access.\nGranting a user `cluster-admin` access at the namespace scope provides full\ncontrol over every resource in the namespace, including the namespace itself.\n\nFor this example, we will create a user with the `edit` Role. First, create the\nnamespace:\n\n```console\n$ kubectl create namespace foo\n```\n\nNow, create a RoleBinding in that namespace, granting the user the `edit` role.\n\n```console\n$ kubectl create rolebinding sam-edit\n    --clusterrole edit \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Example: Grant a user read/write access at the cluster scope\n\nIf a user wishes to install a chart that installs cluster-scope resources\n(namespaces, roles, custom resource definitions, etc.), they will require\ncluster-scope write access.\n\nTo do that, grant the user either `admin` or `cluster-admin` access.\n\nGranting a user `cluster-admin` access grants them access to absolutely every\nresource available in Kubernetes, including node access with `kubectl drain` and\nother administrative tasks. It is highly recommended to consider providing the\nuser `admin` access instead, or to create a custom ClusterRole tailored to their\nneeds.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n### Example: Grant a user read-only access to a particular namespace\n\nYou might've noticed that there is no ClusterRole available for viewing secrets.\nThe `view` ClusterRole does not grant a user read access to Secrets due to\nescalation concerns. Helm stores release metadata as Secrets by default.\n\nIn order for a user to run `helm list`, they need to be able to read these\nsecrets. For that, we will create a special `secret-reader` ClusterRole.\n\nCreate the file `cluster-role-secret-reader.yaml` and write the following\ncontent into the file:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1​\nkind: ClusterRole​\nmetadata:​\n  name: secret-reader​\nrules:​\n- apiGroups: [\"\"]​\n  resources: [\"secrets\"]​\n  verbs: [\"get\", \"watch\", \"list\"]\n```\n\nThen, create the ClusterRole using\n\n```console\n$ kubectl create -f clusterrole-secret-reader.yaml​\n```\n\nOnce that's done, we can grant a user read access to most resources, and then\ngrant them read access to secrets:\n\n```console\n$ kubectl create namespace foo\n\n$ kubectl create rolebinding sam-view\n    --clusterrole view \\​\n    --user sam \\​\n    --namespace foo\n\n$ kubectl create rolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam \\​\n    --namespace foo\n```\n\n### Example: Grant a user read-only access at the cluster scope\n\nIn certain scenarios, it may be beneficial to grant a user cluster-scope access.\nFor example, if a user wants to run the command `helm list --all-namespaces`,\nthe API requires the user has cluster-scope read access.\n\nTo do that, grant the user both `view` and `secret-reader` access as described\nabove, but with a ClusterRoleBinding.\n\n```console\n$ kubectl create clusterrolebinding sam-view\n    --clusterrole view \\​\n    --user sam\n\n$ kubectl create clusterrolebinding sam-secret-reader\n    --clusterrole secret-reader \\​\n    --user sam\n```\n\n## Additional Thoughts\n\nThe examples shown above utilize the default ClusterRoles provided with\nKubernetes. For more fine-grained control over what resources users are granted\naccess to, have a look at [the Kubernetes\ndocumentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) on\ncreating your own custom Roles and ClusterRoles.\n"
  },
  {
    "path": "versioned_docs/version-3/topics/registries.md",
    "content": "---\ntitle: Use OCI-based registries\ndescription: Describes how to use OCI for Chart distribution.\nsidebar_position: 7\n---\n\nBeginning 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. \n\n\n## OCI support prior to v3.8.0\n\nOCI 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.\n\n### Enabling OCI support prior to v3.8.0\n\nPrior to Helm v3.8.0, OCI support is *experimental* and must be enabled.\n\nTo enable OCI experimental support for Helm versions prior to v3.8.0, set `HELM_EXPERIMENTAL_OCI` in your environment. For example:\n\n```console\nexport HELM_EXPERIMENTAL_OCI=1\n```\n\n### OCI feature deprecation and behavior changes with v3.8.0\n\nThe 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:\n\n- When setting a chart in the dependencies as OCI, the version can be set to a range like other dependencies.\n- 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.\n- 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.\n\n### OCI feature deprecation and behavior changes with v3.7.0\n\nThe 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:\n\n- The `helm chart` subcommand has been removed.\n- The chart cache has been removed (no `helm chart list` etc.).\n- OCI registry references are now always prefixed with `oci://`.\n- The basename of the registry reference must *always* match the chart's name.\n- The tag of the registry reference must *always* match the chart's semantic version (i.e. no `latest` tags).\n- The chart layer media type was switched from `application/tar+gzip` to `application/vnd.cncf.helm.chart.content.v1.tar+gzip`.\n\n\n## Using an OCI-based registry\n\n### Helm repositories in OCI-based registries\n\nA [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.\n\n### Use hosted registries\n\nThere are several hosted container registries with OCI support that you can use for your Helm charts. For example:\n\n- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)\n- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact)\n- [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository)\n- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/)\n- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts)\n- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/)\n- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts)\n- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories)\n- [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support)\n  \n\nFollow the hosted container registry provider's documentation to create and configure a registry with OCI support. \n\n**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.\n\n### Using sigstore to sign OCI-based charts\n\nThe [`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).\n\nFor more details on using the `helm sigstore` plugin, see [that project's documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md).\n\n## Commands for working with registries\n\n### The `registry` subcommand\n\n#### `login`\n\nlogin to a registry (with manual password entry)\n\n```console\n$ helm registry login -u myuser localhost:5000\nPassword:\nLogin succeeded\n```\n\n#### `logout`\n\nlogout from a registry\n\n```console\n$ helm registry logout localhost:5000\nLogout succeeded\n```\n\n### The `push` subcommand\n\nUpload a chart to an OCI-based registry:\n\n```console\n$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts\nPushed: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723\n```\n\nThe `push` subcommand can only be used against `.tgz` files\ncreated ahead of time using `helm package`.\n\nWhen using `helm push` to upload a chart an OCI registry, the reference\nmust be prefixed with `oci://` and must not contain the basename or tag.\n\nThe registry reference basename is inferred from the chart's name,\nand the tag is inferred from the chart's semantic version. This is\ncurrently a strict requirement.\n\nCertain registries require the repository and/or namespace (if specified)\nto be created beforehand. Otherwise, an error will be produced during the\n `helm push` operation.\n\nIf you have created a [provenance file](/topics/provenance.md) (`.prov`), and it is present next to the chart `.tgz` file, it will\nautomatically be uploaded to the registry upon `push`. This results in\nan extra layer on [the Helm chart manifest](#helm-chart-manifest).\n\nUsers of the [helm-push plugin](https://github.com/chartmuseum/helm-push) (for uploading charts to [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server))\nmay experience issues, since the plugin conflicts with the new, built-in `push`.\nAs of version v0.10.0, the plugin has been renamed to `cm-push`.\n\n### Other subcommands\n\nSupport for the `oci://` protocol is also available in various other subcommands.\nHere is a complete list:\n\n- `helm pull`\n- `helm push`\n- `helm show `\n- `helm template`\n- `helm install`\n- `helm upgrade`\n\nThe basename (chart name) of the registry reference *is*\nincluded for any type of action involving chart download\n(vs. `helm push` where it is omitted).\n\nHere are a few examples of using the subcommands listed above against\nOCI-based charts:\n\n```\n$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0\nPulled: localhost:5000/helm-charts/mychart:0.1.0\nDigest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff\n\n$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0\napiVersion: v2\nappVersion: 1.16.0\ndescription: A Helm chart for Kubernetes\nname: mychart\n...\n\n$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\n---\n# Source: mychart/templates/serviceaccount.yaml\napiVersion: v1\nkind: ServiceAccount\n...\n\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n\n$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0\nRelease \"myrelease\" has been upgraded. Happy Helming!\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:12:05 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 2\nNOTES:\n...\n```\n\n## Installing charts with digest\n\nInstalling a chart with a digest is more secure than a tag because digests are immutable.\nThe digest is specified in the chart URI:\n\n```\n$ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79\nNAME: myrelease\nLAST DEPLOYED: Wed Oct 27 15:11:40 2021\nNAMESPACE: default\nSTATUS: deployed\nREVISION: 1\nNOTES:\n...\n```\n\n## Specifying dependencies\n\nDependencies of a chart can be pulled from a registry using the `dependency update` subcommand.\n\nThe `repository` for a given entry in `Chart.yaml` is specified as the registry reference without the basename:\n\n```\ndependencies:\n  - name: mychart\n    version: \"2.7.0\"\n    repository: \"oci://localhost:5000/myrepo\"\n```\nThis will fetch `oci://localhost:5000/myrepo/mychart:2.7.0` when `dependency update` is executed.\n\n## Helm chart manifest\n\nExample Helm chart manifest as represented in a registry\n(note the `mediaType` fields):\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    }\n  ]\n}\n```\n\nThe following example contains a\n[provenance file](/topics/provenance.md)\n(note the extra layer):\n\n```json\n{\n  \"schemaVersion\": 2,\n  \"config\": {\n    \"mediaType\": \"application/vnd.cncf.helm.config.v1+json\",\n    \"digest\": \"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\",\n    \"size\": 117\n  },\n  \"layers\": [\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.content.v1.tar+gzip\",\n      \"digest\": \"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\",\n      \"size\": 2487\n    },\n    {\n      \"mediaType\": \"application/vnd.cncf.helm.chart.provenance.v1.prov\",\n      \"digest\": \"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\",\n      \"size\": 643\n    }\n  ]\n}\n```\n\n## Migrating from chart repos\n\nMigrating from classic [chart repositories](/topics/chart_repository.md)\n(index.yaml-based repos) is as simple using `helm pull`, then using `helm push` to upload the resulting `.tgz` files to a registry.\n\n\n"
  },
  {
    "path": "versioned_docs/version-3/topics/v2_v3_migration.md",
    "content": "---\ntitle: Migrating Helm v2 to v3\ndescription: Learn how to migrate Helm v2 to v3.\nsidebar_position: 13\n---\n\nThis guide shows how to migrate  Helm v2 to v3. Helm v2 needs to be installed\nand managing releases in one or more clusters.\n\n## Overview of Helm 3 Changes\n\nThe full list of changes from Helm 2 to 3 are documented in the [FAQ\nsection](/faq/changes_since_helm2.md). The following is a\nsummary of some of those changes that a user should be aware of before and\nduring migration:\n\n1. Removal of Tiller:\n   - Replaces client/server with client/library architecture (`helm` binary\n     only)\n   - Security is now on per user basis (delegated to Kubernetes user cluster\n     security)\n   - Releases are now stored as in-cluster secrets and the release object\n     metadata has changed\n   - Releases are persisted on a release namespace basis and not in the Tiller\n     namespace anymore\n2. Chart repository updated:\n   - `helm search` now supports both local repository searches and making search\n     queries against Artifact Hub\n3. Chart apiVersion bumped to \"v2\" for following specification changes:\n   - Dynamically linked chart dependencies moved to `Chart.yaml`\n     (`requirements.yaml` removed and  requirements --> dependencies)\n   - Library charts (helper/common charts) can now be added as dynamically\n     linked chart dependencies\n   - Charts have a `type` metadata field to define the chart to be of an\n     `application` or `library` chart. It is application by default which means\n     it is renderable and installable\n   - Helm 2 charts (apiVersion=v1) are still installable\n4. XDG directory specification added:\n   - Helm home removed and replaced with XDG directory specification for storing\n     configuration files\n   - No longer need to initialize Helm\n   - `helm init` and `helm home` removed\n5. Additional changes:\n   - Helm install/set-up is simplified:\n     - Helm client (helm binary) only (no Tiller)\n     - Run-as-is paradigm\n   - `local` or `stable` repositories are not set-up by default\n   - `crd-install` hook removed and replaced with `crds` directory in chart\n     where all CRDs defined in it will be installed before any rendering of the\n     chart\n   - `test-failure` hook annotation value removed, and `test-success`\n     deprecated. Use `test` instead\n   - Commands removed/replaced/added:\n       - delete --> uninstall : removes all release history by default\n         (previously needed `--purge`)\n       - fetch --> pull\n       - home (removed)\n       - init (removed)\n       - install: requires release name or `--generate-name` argument\n       - inspect --> show\n       - reset (removed)\n       - serve (removed)\n       - template: `-x`/`--execute` argument renamed to `-s`/`--show-only`\n       - upgrade: Added argument `--history-max` which limits the maximum number\n         of revisions saved per release (0 for no limit)\n   - Helm 3 Go library has undergone a lot of changes and is incompatible with\n     the Helm 2 library\n   - Release binaries are now hosted on `get.helm.sh`\n\n## Migration Use Cases\n\nThe migration use cases are as follows:\n\n1. Helm v2 and v3 managing the same cluster:\n   - This use case is only recommended if you intend to phase out Helm v2\n     gradually and do not require v3 to manage any releases deployed by v2. All\n     new releases being deployed should be performed by v3 and existing v2\n     deployed releases are updated/removed by v2 only\n   - Helm v2 and v3 can quite happily manage the same cluster. The Helm versions\n     can be installed on the same or separate systems\n   - If installing Helm v3 on the same system, you need to perform an additional\n     step to ensure that both client versions can co-exist until ready to remove\n     Helm v2 client. Rename or put the Helm v3 binary in a different folder to\n     avoid conflict\n   - Otherwise there are no conflicts between both versions because of the\n     following distinctions:\n     - v2 and v3 release (history) storage are independent of each other. The\n       changes include the Kubernetes resource for storage and the release\n       object metadata contained in the resource. Releases will also be on a per\n       user namespace instead of using the Tiller namespace (for example, v2\n       default Tiller namespace kube-system). v2 uses \"ConfigMaps\" or \"Secrets\"\n       under the Tiller namespace and `TILLER`ownership. v3 uses \"Secrets\" in\n       the user namespace and `helm` ownership. Releases are incremental in both\n       v2 and v3\n     - The only issue could be if Kubernetes cluster scoped resources (e.g.\n       `clusterroles.rbac`) are defined in a chart. The v3 deployment would then\n       fail even if unique in the namespace as the resources would clash\n     - v3 configuration no longer uses `$HELM_HOME` and uses XDG directory\n       specification instead. It is also created on the fly as need be. It is\n       therefore independent of v2 configuration. This is applicable only when\n       both versions are installed on the same system\n\n2. Migrating Helm v2 to Helm v3:\n   - This use case applies when you want Helm v3 to manage existing Helm v2\n     releases\n   - It should be noted that a Helm v2 client:\n     - can manage 1 to many Kubernetes clusters\n     - can connect to 1 to many Tiller instances for  a cluster\n   - This means that you have to be aware of this when migrating as releases\n     are deployed into clusters by Tiller and its namespace. You have to\n     therefore be aware of migrating for each cluster and each Tiller instance\n     that is managed by the Helm v2 client instance\n   - The recommended data migration path is as follows:\n     1. Backup v2 data\n     2. Migrate Helm v2 configuration\n     3. Migrate Helm v2 releases\n     4. When confident that Helm v3 is managing all Helm v2 data (for all\n        clusters and Tiller instances of the Helm v2 client instance) as\n        expected, then clean up Helm v2 data\n   - The migration process is automated by the Helm v3\n     [2to3](https://github.com/helm/helm-2to3) plugin\n\n## Reference\n\n   - Helm v3 [2to3](https://github.com/helm/helm-2to3) plugin\n   - Blog [post](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)\n     explaining `2to3` plugin usage with examples\n"
  },
  {
    "path": "versioned_docs/version-3/topics/version_skew.md",
    "content": "---\ntitle: \"Helm Version Support Policy\"\ndescription: \"Describes Helm's patch release policy as well as the maximum version skew supported between Helm and Kubernetes.\"\n---\n\nThis document describes the maximum version skew supported between Helm and\nKubernetes.\n\n## Supported Versions\n\nHelm versions are expressed as `x.y.z`, where `x` is the major version, `y` is\nthe minor version, and `z` is the patch version, following [Semantic\nVersioning](https://semver.org/spec/v2.0.0.html) terminology.\n\nThe Helm project maintains a release branch for the most recent minor release.\nApplicable fixes, including security fixes, are cherry-picked into the release\nbranch, depending on severity and feasibility. More details can be found in\n[Helm's release policy](/community/release_policy).\n\n## Supported Version Skew\n\nWhen a new version of Helm is released, it is compiled against a particular\nminor version of Kubernetes. For example, Helm 3.0.0 interacts with Kubernetes\nusing the Kubernetes 1.16.2 client, so it is compatible with Kubernetes 1.16.\n\nAs of Helm 3, Helm is assumed to be compatible with `n-3` versions of Kubernetes\nit was compiled against. Due to Kubernetes' changes between minor versions, Helm\n2's support policy is slightly stricter, assuming to be compatible with `n-1`\nversions of Kubernetes.\n\nFor example, if you are using a version of Helm 3 that was compiled against the\nKubernetes 1.17 client APIs, then it should be safe to use with Kubernetes 1.17,\n1.16, 1.15, and 1.14. If you are using a version of Helm 2 that was compiled\nagainst the Kubernetes 1.16 client APIs, then it should be safe to use with\nKubernetes 1.16 and 1.15.\n\nIt is not recommended to use Helm with a version of Kubernetes that is newer\nthan the version it was compiled against, as Helm does not make any forward\ncompatibility guarantees.\n\nIf you choose to use Helm with a version of Kubernetes that it does not support,\nyou are using it at your own risk.\n\nPlease refer to the table below to determine what version of Helm is compatible\nwith your cluster.\n\n| Helm Version | Supported Kubernetes Versions |\n|--------------|-------------------------------|\n| 3.20.x       | 1.35.x - 1.32.x               |\n| 3.19.x       | 1.34.x - 1.31.x               |\n| 3.18.x       | 1.33.x - 1.30.x               |\n| 3.17.x       | 1.32.x - 1.29.x               |\n| 3.16.x       | 1.31.x - 1.28.x               |\n| 3.15.x       | 1.30.x - 1.27.x               |\n| 3.14.x       | 1.29.x - 1.26.x               |\n| 3.13.x       | 1.28.x - 1.25.x               |\n| 3.12.x       | 1.27.x - 1.24.x               |\n| 3.11.x       | 1.26.x - 1.23.x               |\n| 3.10.x       | 1.25.x - 1.22.x               |\n| 3.9.x        | 1.24.x - 1.21.x               |\n| 3.8.x        | 1.23.x - 1.20.x               |\n| 3.7.x        | 1.22.x - 1.19.x               |\n| 3.6.x        | 1.21.x - 1.18.x               |\n| 3.5.x        | 1.20.x - 1.17.x               |\n| 3.4.x        | 1.19.x - 1.16.x               |\n| 3.3.x        | 1.18.x - 1.15.x               |\n| 3.2.x        | 1.18.x - 1.15.x               |\n| 3.1.x        | 1.17.x - 1.14.x               |\n| 3.0.x        | 1.16.x - 1.13.x               |\n| 2.16.x       | 1.16.x - 1.15.x               |\n| 2.15.x       | 1.15.x - 1.14.x               |\n| 2.14.x       | 1.14.x - 1.13.x               |\n| 2.13.x       | 1.13.x - 1.12.x               |\n| 2.12.x       | 1.12.x - 1.11.x               |\n| 2.11.x       | 1.11.x - 1.10.x               |\n| 2.10.x       | 1.10.x - 1.9.x                |\n| 2.9.x        | 1.10.x - 1.9.x                |\n| 2.8.x        | 1.9.x - 1.8.x                 |\n| 2.7.x        | 1.8.x - 1.7.x                 |\n| 2.6.x        | 1.7.x - 1.6.x                 |\n| 2.5.x        | 1.6.x - 1.5.x                 |\n| 2.4.x        | 1.6.x - 1.5.x                 |\n| 2.3.x        | 1.5.x - 1.4.x                 |\n| 2.2.x        | 1.5.x - 1.4.x                 |\n| 2.1.x        | 1.5.x - 1.4.x                 |\n| 2.0.x        | 1.4.x - 1.3.x                 |\n"
  },
  {
    "path": "versioned_sidebars/version-2-sidebars.json",
    "content": "{\n  \"tutorialSidebar\": [\n    {\n      \"type\": \"autogenerated\",\n      \"dirName\": \".\"\n    }\n  ]\n}\n"
  },
  {
    "path": "versioned_sidebars/version-3-sidebars.json",
    "content": "{\n  \"tutorialSidebar\": [\n    {\n      \"type\": \"autogenerated\",\n      \"dirName\": \".\"\n    }\n  ]\n}\n"
  },
  {
    "path": "versions.json",
    "content": "[\"3\", \"2\"]\n"
  }
]